At 2009-02-16 18:12 +0000, Andrew Welch wrote:
> 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.
In my case that would have a Belgian stylesheet fragment import a
French stylesheet fragment which imports the English stylesheet. Any
absent Belgian strings might be caught by French strings, if present,
or at the least by English strings which are all present.
For example, given
the key "page.title" and the locale "fr_BE" (Belgian French) then it
should return the value for "fr_BE".
You may wish to stick to xml:lang values "fr-BE" and "fr" according to XML:
http://www.w3.org/TR/2008/REC-xml-20081126/#sec-lang-tag
If one doesn't exist it should
return less specific French one (fr_FR... I think)
That would be "French as used in France", as opposed to generic "French".
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
Yes, which is what my users accept ... they just pick which
stylesheet they want ... seems to make more sense than an extra
invocation parameter.
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.
So the stylesheets would support all languages? How would the user
communicate the desired language?
> 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.
Not necessarily ... I took from your original post the use of an
external XML file with the strings. A global variable at the start
of the stylesheet could build the "language tree" of strings, and
your function could work with that in advance of the apply-templates.
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.
Yes, I agree ... I can't think quickly of a "drop in and use" other
than an importing stylesheet fragment that has all the language
definitions and a single import statement. But that would be
stylesheet-specific, not generic as you are looking for. And I can't
use that for my UNLK work because the one language file is being used
both for PDF and HTML.
XSLT 2 could read a text list of URI strings pointing to language
files, but that still requires the list to be edited, not just having
the file dropped in.
Perhaps if your URI resolver interpreted opening a subdirectory by
returning an XML or text document listing the directory contents,
then having dropped a new language file into the directory your
language tree initialization could make sense of the files present.
. . . . . . . . . . Ken
--
Upcoming hands-on XQuery, XSLT, UBL & code list training classes:
Brussels, BE 2009-03; Prague, CZ 2009-03, http://www.xmlprague.cz
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--