Nathan Young (natyoung) escribió:
Andrew:
We have two approaches currently in use. One is quite similar to the one used
by the cocoon project, with the exception that the translation itself is done
by an XSLT rather than by a java SAX filter (which sounds like what you'll end
up doing?).
The other is much like the one people are talking about in this thread, where
the XSL pulls in localized values at runtime. We initially used this second
approach because at that time the first solution didn't support a couple of key
processing features:
- what I've been calling the "mini templates" problem (in the cocoon doc, the section
referred to by the heading "Translation with param substitution")
- what I've been calling the "repeating values" problem where locales not only
have different values for items but actually different numbers of those items (this one
isn't referred to from the cocoon docs).
We are moving away from this since it needs to be coded into each XSL that
needs to use it. Instead we're building onto our first solution so that it
supports the cases we needed it to and can be used in a wider range of
situations.
Probably this won't work for you, but on the off chance it will you might look
at the XUL localization which has a dtd for each locale that defines custom
entities for translated terms:
http://www.mozilla.org/projects/l10n/xul-l10n.html
-------------->Nathan
Thanks for the info Nathan, I will look into it.
BTW: I am trying to achieve an XSL solution, not a SAX filter.
Andrew [ knocte ]
--
--~------------------------------------------------------------------
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>
--~--