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

Dave, All,

While I think we are agreed the requirement has validity, I also agree that it was raised a bit late in the IT'S2 process, to really make it into the spec. So I think as long as it is tracked as you suggest Dave, then that is probably the most appropriate approach.


Sent from my HTC

----- Reply message -----
From: "Dave Lewis" <>
To: "Felix Sasaki" <>
Cc: "Norbert Lindenberg" <>, "" <>, "" <>
Subject: I18N-ISSUE-217: Missing support for localizable items that are not translatable [ITS-20]
Date: Tue, Jan 22, 2013 6:57 pm

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.


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"
and we would keep track of this requirement via that product.



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]

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.


Received on Tuesday, 22 January 2013 19:44:41 UTC