- From: Felix Sasaki <fsasaki@w3.org>
- Date: Fri, 29 Mar 2013 12:37:06 +0100
- 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 http://www.w3.org/2013/03/28-i18n-minutes#item04 and the line-break type issue http://www.w3.org/2013/03/28-i18n-minutes#item05 forward. Yves volunteered to rephrase the passages in question for both issues http://www.w3.org/International/track/issues/246 http://www.w3.org/International/track/issues/247 So he'll probably take this thread and the other one http://lists.w3.org/Archives/Public/www-international/2013JanMar/0396.html 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 http://htmlpreview.github.com/?https://raw.github.com/finnle/ITS-2.0-Testsuite/master/its2.0/testSuiteDashboard.html 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. Best, Felix 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:41 UTC