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

[Syd Bauman <Syd_Bauman@xxxxxxxxx>]

My gut instinct is that it is a less than optimal solution to try to
use namespaces to differentiate natural languages. That's what
xml:lang= is for, after all.

  <z>
    <canonical>MD</canonical>
    <name xml:lang="en">medical doctor</name>
    <name xml:lang="fr">midecin</name>
    <name xml:lang="zh-TW">...</name>
  </z>

> namespace, (XML) namespaces seemed designed to support localization
> (e.g. i18n).  Namespace safety seems to damper that somewhat, and I am
> looking for an optimal pattern.  Many list members here have worked
> extensively with internationalization and namespaces, can anyone help me
> find an optimal pattern to handle this:.
>
> In a large XSLT2 project with lots of rich display vocabulary and
> languages, we have (many different) elements that can include
> display attributes like <z name="Displayed Name" .../>
>
> To support i18n for those names, it seems natural to define
> namespaces for each supported language, using the 2-letter
> localization codes, as:
>
> <global-element
>     xmlns:fr="http://www.somedomain.com/fr";
>     xmlns:en="http://www.somedomain.com/fr";
>     xmlns:de="http://www.somedomain.com/fr";
>     more-attributes=". . ."
>  >
>
> <!-- . . . -->
>
> <!-- and creating corresponding attributes in the displayed elements,
> like: -->
>      <z name="MD" fr:name="Midecin" en:name="Medical Doctor"
> more-attributes-and-content=". . ." />
>
> <!-- . . . -->
>
> <!-- as well as having other "context setting" elements that can define
> locale, like: -->
> <person lang="fr" more-attributes-and-content=". . ." />
>
> <!-- and at display time, using the @lang attribute from the context
> element (e.g. person) to match and select the "name" attribute from the
> displayed element (e.g. z), in the proper namespace (e.g. fr), for
> example.  Directly matching localization codes with namespace prefixes,
> could provide great i18n flexibility and simplicity. -->
>
> </global-element>
>
> Localization codes are stable, but namespace prefixes may not be.
> Changing prefixes can seriously break this scheme. What could/should be
> the best way/pattern to manage this in a (namespace) safe way?