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

Hi Arle,

Some corrections and amendments for #1:

(1) A text is defective in ways the defy categorization, ... => A text 
is defective in ways to defy categorization, ...

(2) (e.g., a translation shows severe grammatical defects and appears 
unrelated to the source material) => (e.g., a translation shows an 
unintelligible result and/or appears unrelated to the source material)

Cheers -- Jörg

On Dec 12, 2012 at 09:21 (UTC+1), Arle Lommel wrote:
> If we take this approach, here is a pass at the information needed for
> #1 with changes in *red bold*
>
> *Value*
>
>     uncategorized
>
> *Description*
>
>     The issue *either *has not been categorized *or cannot be categorized*
>
> *Example*
>
>   * A new version of a tool returns information on an issue that has not
>     been previously checked and that is not yet classified.
>   * *A text is defective in ways the defy categorization, such as the
>     appearance of nonsense garbled text of unknown origin (e.g., a
>     translation shows severe grammatical defects and appears unrelated
>     to the source material)*
>
> *Scope*
>
>     S or T
>
> *Notes*
>
>     This category has two *the following* uses:
>
>       * A tool can use it to pass through quality data from another tool
>         in cases where the issues from the other tool are not classified
>         (for example, a localization quality assurance tool interfaces
>         with a third-party grammar checker).
>       * A tool's issues are not yet assigned to categories, and, until
>         an updated assignment is made, they may be
>         listed asuncategorized. In this case it is recommended that
>         issues be assigned to appropriate categories as soon as possible
>         since uncategorized does not foster interoperability.
>       * *Uncategorized can be used where a portion of text is defective
>         in a way that defies assignment to a category in either the
>         originating system or in any other ITS localization quality
>         markup to indicate that it is uncategorizable.*
>
> #2 would come along next year.
>
> #3 probably wouldn't need much update at this point since their is only
> a slight expansion of meaning in this category. However, when QTLP's
> tool develops I could add it in. This would again be next year.
>
> My guess, by the way, is that this can be seen as clarification of
> usage, rather than a substantive change, but we can see what others think…
>
> -Arle
>
>
>
> On 2012 Dec 12, at 06:17 , Felix Sasaki <fsasaki@w3.org
> <mailto:fsasaki@w3.org>> wrote:
>
>> Thank you, Jörg. Going the "stability path" seems also reasonable
>> given this positive development
>> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Dec/0061.html
>>
>> So the actions needed would be
>>
>> 1) clarification of "uncategorized"
>> 2) having an example that demonstrates the usage in the MT scenario -
>> not necessarily in the spec, but as part of best practices and to see
>> the annotation the qt launchpad project would produce
>> 3) update
>> http://www.w3.org/International/its/wiki/Tool_specific_mappings#Mappings_for_Localization_Quality_Issue_Type
>> http://www.w3.org/International/its/ig/its20-tool-specific-mappings.html
>>
>> Arle, would that work for you? If yes, when could you do 1-3?
>>
>> With regards to Phil's mail at
>> http://lists.w3.org/Archives/Public/public-multilingualweb-lt-comments/2012Dec/0010.html
>> I see this as a different topic, but would prefer not to add values or
>> attributes at this time, like with issue-60. Phil, if you still need
>> this please create a seperate comment.
>>
>> Best,
>>
>> Felix
>>
>> Am 11.12.12 20:57, schrieb Jörg Schütz:
>>> That's a very good solution to avoid a possible type value tsunami
>>> and additional LC (if this is really the case with such an addition).
>>>
>>> By the way, your "1862" example is a candidate for the
>>> "mistranslation" type.
>>>
>>> Cheers -- Jörg
>>>
>>> On Dec 11, 2012 at 18:31 (UTC+1), Arle Lommel wrote:
>>>> 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
>>>> <mailto: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
>>>>> <mailto: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

Received on Wednesday, 12 December 2012 13:47:19 UTC