RE: issue-60 (Re: Comment on ITS 2.0 specification WD)

I agree with Arle, I think that there is no need of having tons of
categories but polishing the existing ones.

 

Cheers,

Pablo.

 

The other alternative is that we expand the semantics of "uncategorized"
slightly to allow for a more naturalistic interpretation such that it
doesn't mean "we haven't categorized it" to "we haven't or can't categorize
it". That would be satisfactory as well, I think, and less of a change.

 

-Arle

 

 

On 2012 Dec 11, at 18:27 , Arle Lommel <arle.lommel@dfki.de> wrote:





Jörg is correct here that nothing has this already. This is really looking
forward to QT Launchpad work. If saying "nobody has implemented this so far"
disqualifies it, then we would be forced to use "uncategorized" and add some
custom markup. That wouldn't be the end of the world for us, but it would be
nice to have.

 

However, see my last mail about how I see this as different.

 

(I can say, up front, that if this isn't accepted I won't hold anything up
over it, so the moment this causes real problems, we can drop it.)

 

-Arle

On 2012 Dec 11, at 18:15 , Jörg Schütz <joerg@bioloom.de> wrote:





Hi Felix,

Since an additional value doesn't actually harm the type list which
certainly can be seen as open ended (but still backward compatible), the
need for a subsequent LC is questionable.

Nevertheless, the proposed quality type value "unintelligible" for the
described output case might be controversial because it does not
indicate/reflect a quality consideration as the other types in the list do.
The QT Launchpad project should therefore consider to use "uncategorized"
because this value might indicate the "trashy" quality.

And TMK, I'm not aware of any language proofing technology that uses
"unintelligible" has a quality value.

Cheers -- Jörg