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/