[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: xslt and i18n
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/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|