[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT (2) namespace safe i18n patterns

Subject: Re: XSLT (2) namespace safe i18n patterns
From: Syd Bauman <Syd_Bauman@xxxxxxxxx>
Date: Sun, 22 Nov 2009 23:41:26 -0500
Re:  XSLT (2) namespace safe i18n patterns
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.

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

> 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?

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.