For example, in the above example, you could just have:
<name>medical_doctor</name>
where "medical_doctor" is the key for a lookup into your
translations, which are held in separate files.
That's a good pattern I think, but I guess there is room for
several approaches, depending on the real problems. But even
there, in order to "lookup into your translations", you need to
tag them with their respective languages.
I would group the translations by area, with a suitable suffix (just
like Java :) for example:
helppage_en_GB.xml
helppage_de_DE.xml
Then you can easily distribute the relevant files to each translator
at the same time, add/remove them as needed, edit individual files
without fear of affecting the others, fall back to the appropriate or
default file when a translation is missing etc... all lots of benefits
over storing everything in a single file.
I cannot see why @lang
would be better than @xml:lang.
The reason is that with xml:lang you must adhere to that spec, with
@lang you are free to do what's best for your situation. You could
have @lang="en_GB", or you could have @lang="English" or @lang="1",
whatever best suits the situation it is being used for. It's the same
argument for using proprietary markup to describe links betweens
documents, rather than using xlink.
--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/
--~------------------------------------------------------------------
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>
--~--