Hi Ken,

> I'm supporting fourteen languages for the United Nations Layout Key for
> Invoice, using 14 differently-named top-level stylesheets:
...
> Of course everything is modular and I use the stylesheet importation to
> override the English base strings with whatever strings are available in the
> given language

It's the fallback behaviour that I'm looking for.  For example, given
the key "page.title" and the locale "fr_BE" (Belgian French) then it
should return the value for "fr_BE".  If one doesn't exist it should
return less specific French one (fr_FR... I think) and if that doesn't
exist then a default value (usually the English translation or even
the key itself)

We almost get that using a specific stylesheet and import precedence,
but you need either a) a specific stylesheet for every locale or b)
the host language to pick the appropriate specific stylesheet for any
given locale.  I really want to avoid relying on the host language and
have a pure xslt solution.


> What benefit are you looking for by which improvement could be measured?

Usability improvements.  For example, in Java there are "Resource
Bundles" - to support a new language you just drop an appropriately
named properties files into the right place and that's it.

In JavaFX, it's the same but inbuilt into the syntax itself.

In XSLT we should be able to implement localisation support without
relying on extensions (and keeping the 1 file per locale approach)...
With the template matching example I posted, it gives us the the
fallback mechanism, but (assuming the templates are suitably separated
into files and then included) relies on all the includes being
explicitly included in the primary stylesheet.  This means adding
support for a new locale requires modification of the primary
stylesheet as well dropping the locale specific file into the right
place.... not awful but not great either.



-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/