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/