The primary purpose of namespaces is to provide distinction between
the vocabulary of different application domains. Language can be
viewed as a facet of the presentation layer and should be treated
separately.
Having all translations within a document, presumably with many
repetitions, is not attractive. A translation service might very well
be defined on top of the essential XML structure, with XPath
expressions being used to identify the items that are subject to
translation, either content or attribute values. Another approach is
to add markup to the basic document (e.g.
http://wiki.zope.org/zope3/ZPTInternationalizationSupport).
Perhaps an XML centered user list is a better forum for this discussion.
-W
On 11/23/09, ac <ac(_at_)hyperbase(_dot_)com> wrote:
Hi Syd,
Thank you for your quick response. Yes xml:lang was defined for i18n.
Aren't "natural" languages a reference model for namespaces?
I use xml:lang for translation dictionary applications, but it does not
seem to apply well here. I was looking for something more optimal for
this context. Restricting i18n to xml:lang seems to also mean that
(sizable) applications are either initially designed for i18n or not at
all, and that attributes cannot be internationalized. I think and hope
that we can do better.
If you have 1M elements, for example with 2 different display attributes
each, the xml:lang approach would imply 2M more elements for each
supported language (e.g. 5 languages would mean 10M additional nodes, 10
times more), more elaborate processing (over, let's say 25K lines of
XSLT), changing document structure and content as well as most attribute
processing to element processing, a design "made for "i18n" (e.g.
translation dictionary) rather than a design optimized for the
application at stake.
Comparatively, managing namespaces with discipline and maintaining a
stable environment so that prefixes do not effectively change, does not
seem so bad, yet I still hope to do better. Any help appreciated.
Thank you.
Cheers,
ac
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">médecin</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="Médecin" 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?
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--