Subject: Re: [xsl] xslt and i18n From: Vyacheslav Sedov <vyacheslav.sedov@xxxxxxxxx> Date: Tue, 17 Feb 2009 01:25:54 +0300 |
to my mind the best way is to use "metaprogramming magic" - just generate proper XSLT (one for each language-location) from localization file(s) and some kind of "dummy XSLT", it also can allow some freedom about not only text translation (images, links, UI behavior, dates & currency, items order and so on) and can help to solve some performance problems On Tue, Feb 17, 2009 at 12:46 AM, Florent Georges <lists@xxxxxxxxxxxx> wrote: > > Andrew Welch wrote: > >> The key ("page.title" here) and the locale is passed in as >> a parameter. The localised values are stored as >> templates. The key and locale are converted into >> elements, and then the apply-templates call is made on >> that temporary tree... and then the rest is taken care of. > >> This covers using specific matches, falling back to the >> general language when the country specific isn't available >> (eg falling back to French when a fr_BE value isn't there) >> and falling back to a default when no other exists at all. > > Hi there ;-) > >> The drawback is of course that the translations are hidden >> within templates, rather than simple properties files. > >> Any ideas on how to improve this? > > In my humble opinion, this technique has two main > benefits: it solves the dispatch between languages and it > provides complex formatting features by using full sequence > constructors. > > But I don't think we often need the power of full sequence > ctors in localizations. Especially given that people > writing translations can know very few of XSLT; in this case > this is even a good thing to limit what can be done in l10n > entries and force the developer of the stylesheet to deal > with the logic. > > I think the format of those entries are primordial, more > than the way they are resolved and formatted. I used > something like the following in a former project: > > <dico lang="fr"> > <entry id="bread">Le prix du pain est de <price/>.</entry> > ... > </dico> > <dico lang="en"> > <entry id="bread">The price of bread is <price/>.</entry> > ... > </dico> > > The set of functions and templates of the i18n module got > the right entry, formatted the parameters (like 'price') and > applied templates on the entry in a particular mode to > resolve parameters. But it could also have been translated > to the kind of stylesheets you described after all. > > I had to deal with some business people to translate > languages and with the customer's lawyer to review all > sentences (the system generated invoices and contracts.) I > wrote a little transformation from those to ODF, back and > forth, to communicate with them. While that was just quick > and dirty stuff, and it didn't eliminate the need for an > XSLT developer to integrate the changes, it helped a lot the > communication and synchronization. That's even kind of > ad-hoc reporting. I doubt that would have been as easy if > some logic was embedded into templates. > > But I think the key was really to apply templates to > entries. That solves the positioning of parameters in an > elegant way, letting the translator to re-order them in an > intuitive way without using format string. For instance, > the following sentence: > > The total is <total/>, incl. the guarantee of <guar-amount/>. > > could be translated into: > > En tenant compte de la garantie de <guar-amount/>, le > total s'eleve a <total/>. > > I think that the important part is to define such a > format, depending on your needs. Then to have a simple way > to communicate entries in that format with translators on > the one hand, and a set of tools to use them in your > stylesheets on the other hand. The later could be based on > stylesheet modules like you described, generated from the > dictionaries, or being accessed as XML documents (I don't > think that using either keys or match patterns should make a > big difference though.) > > Regards, > > -- > Florent Georges > http://www.fgeorges.org/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xslt and i18n, Florent Georges | Thread | Re: [xsl] xslt and i18n, Florent Georges |
Re: [xsl] xslt and i18n, Florent Georges | Date | Re: [xsl] separate white space and , himanshu padmanabhi |
Month |