Security, Middleware, Appliances
RSalz 2700011QK0 309 Visits
RSalz 2700011QK0 468 Visits
The mechanisms for doing globalization of XSLT are clunky. Here's some ideas on what I think is a better way. First, have XSLT become aware of the standard locale and message catalog stuff.
Add an "xsl:locale" attribute. This is an AVT attribute that can appear on the xsl:stylesheet element. Also, add an xsl:catgets function. The calling sequence is
xsl:catgets(msgid, "default text"[, "locale"]) -> stringThe msgid is an integer, the default text is obvious, and the locale lets you retrieve messages from any locale, defaulting to the gloal one.
More interesting is how to handle messages with parameters. To handle this, extend the semantics of xsl:message in the following backward-compatible (I think) way. Allow
In the normal case, they are equivalent to
For example, suppose msgid 1123 has "El %2$s %1$s." And that $foo is "white". The legacy way:
<xsl:message>The <xsl:value-of select="$foo"/> <xsl:value-of select="'house'"/></xsl:message>To i18n-ify:
<xsl:message>The <xsl:param select="$foo"/> <xsl:param select="'house'"/></xsl:message> <xsl:message tns:msgid=1123>The <xsl:param select="$foo"/> <xsl:param select="'house'"/></xsl:message>The first line would be equivalent to the legacy way. The second line could result in output like
El house blancoin a spanish locale, and would result in
The white housein the English (or default if not catalog exists) locale.[Read More]