W3C home > Mailing lists > Public > public-i18n-its-ig@w3.org > February 2009

Re: Comments on Nov-14 WD for ITS IG also Re: POWDER comments: multiple/alternate displaytext strings? (eg. different languages/scripts)

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 04 Feb 2009 08:34:12 +0900
Message-ID: <4988D474.1060607@w3.org>
To: Phil Archer <phil@philarcher.org>
CC: public-powderwg@w3.org, public-i18n-its-ig@w3.org, Dan Brickley <danbri@danbri.org>

Hello Phil, all,

Phil Archer さんは書きました:
> Yves, Dan,
> Over the last week or so I've been working through all the comments 
> we've received (again, double checking everything before we go to PR) 
> and looked again at those you sent [1, 2], both of which relate to 
> language/translation issues. I realised that there was more to do...
> Initial lack of support for xml:lang was an omission. I've now 
> implemented support for it in the relevant elements in the POWDER 
> Processor I've been working on [3] and it's already supported in the 
> other tools we have.
> For example [4] shows you the output of a processor given a POWDER doc 
> that makes it very plain that anything on example.com or example.org 
> is red in multiple languages.
> I've also amended the relevant documentation to make it clear that 
> xml:lang attributes are appropriate for use on the displaytext, 
> comment and label elements. See the change log at [5] for pointers to 
> the relevant text.
> Although xml:lang attributes may be added to tag elements, we don't 
> recommend it for the reasons shown in the new section on localisation.
> Regretfully, it does not appear to be possible to include the ITS tag 
> set. This is because although POWDER is encoded in XML, it transports 
> RDF and can be transformed into RDF/OWL. Therefore, although it looks 
> like XML, one really has to think of POWDER as RDF which interprets 
> XML attributes as datatype properties. This means that they can only 
> appear in node elements and things like its:translate do not have the 
> desired semantics within POWDER.
> Therefore, unless there is a way to use ITS with RDF, we can't 
> integrate it as Yves has suggested.

The idea of ITS is to be available for localization and 
internationalization of XML formats. Some specifications, like Powder, 
define XML only as one serialization for their data model. That 
restricts the possibilities for ITS, but IMO it does not make them 
impossible. The important bit here is that ITS-processing is independent 
of Powder processing. As Yves said:
"The idea is that the rules document is available to whoever needs to 
localize or *preform* some linguistic-related tasks on the
document. "
So one could say "If a user needs to localize Powder documents, ITS 
provides a means to achieve this within the XML serialization of Powder".

I agree that currently there is no way to use ITS within RDF on the data 
model, serialization-independent level of RDF, and that this would be 
desireable, though probably hard to achieve in a timely fashion. 
Nevertheless I am not aware of any other means to express localization 
requirements on the data model level of RDF. Hence, ITS would solve the 
problem at least for one serialization.



> If you have any further comments, or if you disagree with our action 
> here, do please let us know.
> Thanks
> Phil.
> [1] http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0046.html
> [2] http://lists.w3.org/Archives/Public/public-powderwg/2009Jan/0020.html
> [3] http://i-sieve.com/cgi-bin/processor.cgi
> [4] http://tinyurl.com/c62tsn
> [5] http://philarcher.org/powder/dr/20090203-diff.html#sincelc1
> Yves Savourel wrote:
>> Hi Phil,
>>> OK, now I'm being a little lazy - because I'm trying to expedite 
>>> this ASAP and I admit to only having seen the ITS doc for the first 
>>> time this afternoon. You've kindly sent us an ITS rules file - is 
>>> the idea that every POWDER doc should link to this? Or at least, 
>>> every POWDER doc that includes localised tags? Or should we embed 
>>> the rules in the schema?
>> The idea is that the rules document is available to whoever needs to 
>> localize or preform some linguistic-related tasks on the
>> document.
>> It is certainly not necessary to have the rules in every document 
>> instance.
>> Including them in the schema could be a good way to make sure it's 
>> readily accessible.
>> Or it could be a separate document (with a link to it in the spec). 
>> From the view point of the ITS processor it doesn't really
>> matter.
>> -yves
Received on Tuesday, 3 February 2009 23:35:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:11:27 UTC