RE: I18N-ISSUE-217: Missing support for localizable items that are not translatable [ITS-20]

Felix, Norbert,

I've added my opinion on this discussion inline (marked [Des>])

Regards
Des


-----Original Message-----
From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: 18 January 2013 09:35
To: Norbert Lindenberg
Cc: public-multilingualweb-lt-comments@w3.org; www-international@w3.org
Subject: Re: I18N-ISSUE-217: Missing support for localizable items that are not translatable [ITS-20]

Am 18.01.13 10:29, schrieb Norbert Lindenberg:
> On Jan 18, 2013, at 1:06 , Felix Sasaki wrote:
>
>> Am 18.01.13 01:35, schrieb Internationalization Working Group Issue Tracker:
>>> I18N-ISSUE-217: Missing support for localizable items that are not 
>>> translatable [ITS-20]
>>>
>>> http://www.w3.org/International/track/issues/217
>>>
>>> Raised by: Norbert Lindenberg
>>> On product: ITS-20
>>>
>>> ITS 2.0 is missing support for marking up items that are localizable but not translatable.
>> You can achieve that via combining "locale filter" with "translate", e.g..
>>
>> <book xmlns:its="http://www.w3.org/2005/11/its" its:version="2.0">
>>   <info>
>>     <its:rules version="2.0">
>>       <its:localeFilterRule
>>         selector="//legalnotice[@role='Canada']"
>>         localeFilterList="en-CA, fr-CA"/>
>>         <its:translateRule selector="//legalnotice[@role='Canada']" translate="no"/>
>>     </its:rules>
>>     <legalnotice role="Canada">
>>       <para>This legal notice is only for English and French Canadian locales.</para>
>>     </legalnotice>
>>   </info>
>> </book>
> The locale filter rule only says that the legal notice needs to be present for en-CA and fr-CA, and omitted from all other languages. It doesn't say that the content of the legal notice may have to change, which is what I mean by "localizable", as indicated in the examples below.

The current definition of locale filter says http://www.w3.org/TR/2012/WD-its20-20121206/#LocaleFilter
"The Locale Filter data category specifies that a node is only applicable to certain locales."
which covers the "needs to be present" part. I understand your "needs to be localizable or not" requirement - but if you say "it may have to change", why not expressing <its:translateRule selector="//legalnotice[@role='Canada']" 
translate="yes"/>
that means: change the content.

>
>>> Translatable items can easily be identified with the "translate" attribute; there's no equivalent attribute "localize".
>> There is no need for an equivalent. It is a design principle for ITS1 and ITS2 that the data categories are distinct items and that an application can combine them freely, see above.
> Except that the combination above doesn't fully express "localizable".

Why can't you interpret "translatabe" as "localizable" in the combination and in your envisaged application? What other application would be disturbed by that interpretation?

Best,

Felix
[Des>]  I agree with Nortbert here and believe the scenario he cites is valid.  In fact for our own software localisation systems differentiate translatable and localisable elements in exactly this way.  In most cases they are applied to different types of localisable data.  E.g. image dimensions in a UI cannot be 'translated' but they can vary in a locale-dependent way.

[Des>]In localisation workflows therefore, they are treated differently.  'Translatable' data can be reused (leveraged) from version to version and can also be sent to into a translator to be translated.   'localisable' data should not be sent to a translator to be translated BUT it can - in fact it should- be reused (leveraged) from version to version of the software.   We tag content as either localisable and/or translatable. That metadata enables our automation to determine which processes should act upon that content.

[Des>] So in theory, content marked as 'translatable' would enter into a translation workflow as normal, while content marked as localisable would be not be eligible for the same workflow.  In most cases the 'localisable' flag would be limited to the CMS only to flag source and target content appropriately. There may be a case for it being transmitted into XLIFF or some other interchange format, but I think this is an edge case.

[Des>] Because in most cases the localisable flag is associated with particular localisable data types (E.g. Images, dialogue box geometries, font definitions etc) , a workaround could be to create an its:translateRule based on mime-type for the content. This would  assume that each translatable  element is  appropriately tagged with a  valid mime-type.

Received on Friday, 18 January 2013 11:02:57 UTC