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

Norbert, Des, Felix,
I think in fact ITS already recognises the distinction between words 
passed to translators and other features Norbert identifies are being 
addressed by localisation engineers. The data category selection section 
(3.3) states "selection of the ITS data categories applies to *textual 
values* contained within element or attribute nodes" so the content of 
images, CSS values or strings in script languages are not intended to be 
in scope of the specification.

So, with the exception of currency and date formats hardcoded in 
translatable text (which translators are probably already equipped to 
deal with without additional instruction) addressing localisation 
instructions in addition to the current transaltion instructions, would 
in my view be a large scope enlargement for ITS2.0, so I'd agree with 
Felix that we should not try and address this here.

I would however encourage the WG to start capturing this issue as one 
not addressed in ITS2.0 as Felix suggests. Certainly, to really support 
multilingual HTML5 we need to be able to properly manage the translation 
and localisation of CSS3 and Javascript. Though this was deemed out of 
scope for ITS2.0 its interoperability should be on the broader plan for 
the W3C I18N group I feel.

cheers,
Dave

On 19/01/2013 07:39, Felix Sasaki wrote:
> Hi Norbert, Des, all,
>
> thank you for your clarifications. I understand your point about the 
> difference between translation and localization. However I'm not sure 
> whether the MLW-LT WG can take the time to add the "localization data 
> category". It would not only mean a normative change =  another last 
> call period, but also time to discuss the requirement in more detail 
> than in this thread.
>
> So my personal response is to reject the comment because of timing, 
> but let's see what the WG says.
> FYI, I have created a product in the MLW-LT tracker "Requirement not 
> addressed in ITS2"
> https://www.w3.org/International/multilingualweb/lt/track/products/9
> and we would keep track of this requirement via that product.
>
> Best,
>
> Felix
>
> Am 19.01.13 07:50, schrieb Norbert Lindenberg:
>> On Jan 18, 2013, at 1:35 , Felix Sasaki wrote:
>>
>>> 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.
>>>>>> 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?
>> As I said in the original comment, and Des has explained in more 
>> detail, you want to keep non-translatable but localizable items 
>> separate from translatable ones because they can't be handled in the 
>> normal translation process. Large companies commonly spend millions 
>> of dollars or euros a year on translation and therefore work hard to 
>> make that process as efficient as possible. In the end, translators 
>> get paid cents per word. You can't feed image URLs, date format 
>> patterns, CSS color identifiers, or UI element coordinates into that 
>> process and hope that translators will realize what they are, learn 
>> the appropriate syntax, and provide the correct localization. They 
>> have to keep going translating words. The other localizable data, 
>> which usually is a small fraction of the total volume, gets handled 
>> by localization engineers.
>>
>> Norbert
>>
>>
>
>