W3C home > Mailing lists > Public > public-multilingualweb-lt-comments@w3.org > March 2013

Re: I18N-ISSUE-246: Clarify character encoding behavior when calculating storage size [ITS-20]

From: Felix Sasaki <fsasaki@w3.org>
Date: Fri, 29 Mar 2013 12:37:06 +0100
Message-ID: <51557CE2.80900@w3.org>
To: Anne van Kesteren <annevk@annevk.nl>
CC: Jirka Kosek <jirka@kosek.cz>, "Phillips, Addison" <addison@lab126.com>, Arle Lommel <arle.lommel@dfki.de>, Stephan Walter <stephan.walter@cocomore.com>, Norbert Lindenberg <w3@norbertlindenberg.com>, Yves Savourel <ysavourel@enlaso.com>, "public-multilingualweb-lt-comments@w3.org" <public-multilingualweb-lt-comments@w3.org>, www-international <www-international@w3.org>
Hi all,

FYI, Yves and I yesterday joined the i18n call to move this issue
and the line-break type issue
forward. Yves volunteered to rephrase the passages in question for both 

So he'll probably take this thread and the other one
into account.

What took some time during the call was discussion about the purpose of 
ITS (1 or 2) in general: ITS is meant to transport metadata *values* to 
consuming applications. Here it is useful to have default values like 
"utf-8". But ITS does not define what the applications *do* with the 
values. You will see that with other metadata items as well. E.g. a 
"translate" attribute is not necessarily used for translation, but for 
creating pseudo text or an XLIFF package.

"Directionality" is another example of this: none of ITS processors 
mentioned at
don't render bidi text - they just transport the directionality values 
to e.g. an XLIFF package. This has also implications for testing, btw.: 
for directionality we don't test rendering, but just whether the correct 
identification of metadata values has been done. That is the 
pre-requisite for transporting the values.

This "metadata transport" function of ITS is quite useful IMO: it helps 
to create workflows with many tools: browser, various authoring tools, 
CMSs, translation mgmt tools etc. But you then cannot formulate 
something like "in an ITS processor implementing storage size, utf-8 
support is required", since the processor just conveys the information 
to whatever tool consumes it.



Am 29.03.13 11:56, schrieb Anne van Kesteren:
> On Fri, Mar 29, 2013 at 10:32 AM, Jirka Kosek <jirka@kosek.cz> wrote:
>> Rationale for this change is reflecting hopefully all raised concerns:
>> -- UTF-8 encoding is a default value of storageEncoding attribute, so
>> there is no need to repeat this in a note
>> -- It has been pointed out that storage size mechanism is targeted for
>> generating output resources that are loaded into various components and
>> devices. Many of such devices are legacy and do not support UTF-8 so
>> requiring UTF-8 support will not be aligned with the reality and will be
>> artificial requirement.
> Nevertheless, you could still add a note that encourages using it as
> it's the only encoding that's non-problematic going forward and ports
> across a wide variety of platforms. If there are still systems that do
> not support utf-8, they better start figuring out a migration story.
Received on Friday, 29 March 2013 11:37:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:32 UTC