- From: Felix Sasaki <fsasaki@w3.org>
- Date: Tue, 21 Oct 2008 15:02:15 +0900 (JST)
- To: "Yves Savourel" <ysavourel@translate.com>
- Cc: public-i18n-its-ig@w3.org
Hi Yves, all, Many thanks for your review. I have no additional comments, but I think we should at least make the SML WG aware of what you said about the localization related functionality. Felix > > Hi all, > > I had the action item to look at SML from the viewpoint of ITS. > > SML's Sep-12 Working Draft is here: > http://www.w3.org/TR/2008/WD-sml-20080912/ > > As far as I can tell SML is more like a vocabulary that is meant to be > used inside schemas written in XSD or Schematron, or inside > other XML documents. > > With this in mind there is very little that seems related to localization > and internationalization as most of the language-dependant > content is actually hold in the host format. > > There is however one mechanism provided that is related to localization: > > The sml:locid attribute allows you to define the translation location for > the text content of the containing element. > > For example: In this snippet of Schematron code, sml:locid hold the > location of the translated text for the message of the > assertion. > > <sch:assert test="smlfn:deref(.)[starts-with(u:ID,'99')]" > sml:locid="lang:StudentIDErrorMsg"> > The specified ID <sch:value-of select="string(u:ID)"/> does not begin > with 99. > </sch:assert> > > While this is a nice feature. The implementation of it is application > specific. SML does not define how the substitution should be > don, nor what naming mechanism should be used, nor in what format the > translation repository should be written in. > > There is an appendix here > http://www.w3.org/TR/2008/WD-sml-20080912/#Localization_Sample that > illustrate how sml:locid could work. > > There are a number of issue with the example, but they are not directly > related to ITS. > > --- The value of the sml:locid attribute is a QName. In the example the > namespace part is used to point to a directory where the > translated files are located, and the local part is the ID of the message > to read. The name of the file itself is made of the > language tag a character underline, and the word "lang" (or the prefix of > the namespace, the example is unclear if the fact that > both are the same is accidental or not). > > --- The translation files are properties-like text file, where each entry > can contains XML markup. This means to translate such > file, one would have to > > It would be better for the translation to be stored in an XML document, so > its content could be annotated with ITS, and process more > easily. Having XML entries in a properties file makes thing difficult for > most translation tools. > > --- There is an error/typo in the French message: "L'identifieur specifie" s > hould be "L'identifieur specifi? (an accent is > missing). > > > Overall, I'm not sure hat we should provide for feedback aside from the > typo. Is there a generic way to associate language tag with > a file name so the filename could be automatically inferred? I guess the > Java properties names is something similar. > > Any ideas, suggestions? > > Cheers, > -yves > > >
Received on Tuesday, 21 October 2008 06:02:51 UTC