Re: [xsl] XSLT (2) namespace safe i18n patterns

[Andrew Welch <andrew.j.welch@xxxxxxxxx>]

>> I would group the translations by area, with a suitable suffix
>> (just like Java :)
>
>  You can do that with @xml:lang too.

I would group them by area, such as "help page", "welcome page" etc
into separate files, with a suitable suffix.  So within
"helppage_de_DE.xml" you would have the key/value pairs needed for the
help page in the German language.  In the XML that drives the help
page, there would be the keys used to do the lookup.

I'm can't see how you would do that with xml:lang, without also
writing some code to select the appropriate file?   At which point,
using @xml:lang becomes no different to @whatever.

xml:lang is all about mixing languages in the same file, however that
often causes more problems than in solves, and far better to have one
language per file.


>> for example:
>
>> helppage_en_GB.xml
>> helppage_de_DE.xml
>
>  Well, you're not using a @lang anymore here :-)

No, the solution I mentioned there and above doesn't need an
attribute.  If you really did have to indicate a particular bit or
markup belonged a certain language, thats when I would use @lang or
similar, but never @xml:lang.  In the above, there's no need to embed
the translations in the XML, so no need for the attribute.

>  Of course, in a particular context, there can be plenty of
> reasons to use something else than an attribute, or something
> else than BCP 47.  And there is no reason trying to stick with
> @xml:lang just to use @xml:lang.  But if you create an attribute
> to set a BCP 47 tag, then just use @xml:lang...

mmm we will have to disagree on this one :)    @xml:lang doesn't
really give you that much and limits what you can do compared to a
custom @lang attribute... perhaps a bit like the id() function,
ultimately more hassle than its worth, and I reckon will probably be
gone in a future slimmed down XML.



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