W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2005

RE: Other possible areas to cover under ITS

From: Tim Foster <Tim.Foster@Sun.COM>
Date: Tue, 01 Mar 2005 12:07:09 +0000
To: "Richard, Francois" <francois.richard@hp.com>
Cc: Martin Duerst <duerst@w3.org>, Yves Savourel <yves@opentag.com>, public-i18n-its@w3.org
Message-id: <1109678829.1185.17.camel@cuprum>

Hey Francois,

On Tue, 2005-03-01 at 11:15, Richard, Francois wrote:
> Pieces of content that within the same XML file do not necessarily
> follow the same rules (syntax, segmentation, ...). And for which in
> most cases, dtd or schema have not been defined.

Yep, I know that feeling. Very awkward to deal with alright -
thankfully, we only have one group sending such stuff to our tools at
Sun, but it would be really nice to "re-educate" them (with something
other than a baseball bat ;-)

> I personally would benefit from being reminded what is the distinction
> between localization directives/tag set vs. localization properties.

I think the thing we were trying to describe was :

* localisation directive:

Some means by which a file itself can declare the sections of
localisable content within the content of the file : in our case, we
were suggesting namespaces for this purpose.

eg. a translatable file "tim.xhtml" would include namespaces to markup
the fact that <p> elements contain translatable text, <strong> and <em>
are inline elements that shouldn't cause segmentation, <code> should not
be segmented, etc.)

* localisation properties:

A separate configuration file, per XML type, which describes the
localisable content of a given XML input file.

eg. "tim.xhtml" would need the special properties file 

xhtml-type.properties may look something like :


(of course, you would probably want to write that properties file in
XML, I'm just putting it this way for brevity)

-- so, if you think about it, for localisation directives, no extra work
should be needed on behalf of the tools writer to extract localisable
content from the input file to be translated.

For localisation properties, the tools writer needs to have a
pre-configured localisation properties file tailored for the input file
type. If one doesn't exist, the tools writer would have to get access to
the xml dtd/schema in order to create one.

Hope this helps,


> >>-----Original Message-----
> >>From: Martin Duerst [mailto:duerst@w3.org] 
> >>Sent: Friday, February 25, 2005 8:50 AM
> >>To: Richard, Francois; public-i18n-its@w3.org
> >>Subject: Re: Other possible areas to cover under ITS
> >>
> >>
> >>Hello Francois,
> >>
> >>Some very interesting ideas. A few comments below.
> >>
> >>At 23:37 05/02/23, Richard, Francois wrote:
> >> >
> >> >Hello,
> >> >
> >> >Here are some areas that are not exactly covered in  
> >>>http://people.w3.org/rishida/localizable-dtds/ or could be 
> >>added to some  
> >>>sections. I am not sure if all of these fall in the scope of 
> >>ITS, but here  
> >>>is the list I came up with:  
> >>>
> >> >- Preview information such as XSLT, specific XML editor.
> >> >It useful when it is necessary to preview the XML content 
> >>in an effort of  
> >>>display context info to help in the l10n of the content.
> >>
> >>I'm not sure I understand this. There is the stylesheet PI 
> >>for XSLT (http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/).
> >>Would that do the job, or do you mean something else?
> >>
> >> >- Font information to indicate either that the element 
> >>carries a font  
> >>>information (to be l10ed) or to indicate which specific font 
> >>to use to  
> >>>render l10ed content.
> >>
> >>Why should font information be in the document? Are the 
> >>stylesheet languages we have (CSS, XSL-FO) not good enough?
> >>
> >> >- Substitution rules: It help in define automatic 
> >>substitution. For  
> >>>instance for unit of measure, URL l10n (http://.../en/US/... 
> >> ->  >http://.../fr/CA/...). The list is long and it would be 
> >>nice to be able to  
> >>>embedded the rules themselves. It could be part of 2.19
> >>
> >>Should the rules be embedded in the actual documents?
> >>I think it might be better to have a pointer to such rules, 
> >>external to the document, because such rules are likely the 
> >>same for a lot of documents. Also, quite some part of such 
> >>rules could be expressed in XSLT (in particular XSLT 2.0).
> >>
> >> >- Element syntax: Some elements need to follow certain 
> >>syntax. I am  
> >>>thinking about a coma-delimited list for instance.
> >>
> >>This is much more general than just localization. XML Schema 
> >>has regular expressions (patterns) for this. I don't think we 
> >>should do anything more in this area, because there is quite 
> >>some contention; some people consider using commas,... as bad 
> >>XML design.
> >>
> >> >- Targeted country: With the limitation of locale, it is 
> >>useful to be able  
> >>>to specify a country for which the content is targeted. This 
> >>might be in  
> >>>2.12 already.
> >>
> >>Is that before the localization, or after? Before, there
> >>are potentially very many targets. Afterwards, it may indeed 
> >>make sense to have some kind of indication e.g. to say 
> >>"measures in this document are in locale X". If we want to do 
> >>something in this direction, it is crucial to coordinate with 
> >>the I18N Core WG, because they have some work items in this 
> >>direction (locale identification,..., in particular for Web Services).
> >>
> >> >- Segmentation rules. Some element could follow a specific 
> >>segmentation  
> >>>that needs to be specified.
> >>
> >>Again, the question is whether the actual rules should be in 
> >>the document, or just a pointer.
> >>
> >>Regards,    Martin. 
> >>
> >>
Tim Foster - Tools Engineer, Software Globalisation
http://sunweb.ireland/~timf http://blogs.sun.com/timf
Received on Tuesday, 1 March 2005 12:08:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:04 UTC