Cart
[Home] [By Thread] [By Date] [Recent Entries]
I think one of the issues in the internationalisation of SGML/XML/HTML is as follows. Internationalising a document means creating it so that subsequently is very convenient to be localised. That implies if I give my SGML product documentation to a professional translators to be translated into German say, how do they know which parts to be translated and which to be left alone? for example if one of them finds <select name="transport"> <option value="car">Car</option> <option value="bus">Bus<//option> </select> <input type="submit" name="Submit" value="Submit"> <address street ="Transport Street, 234</address> How does he or she know to translate "Car" and "Bus" but not "transport"., "car" ,"bus" or "Transport Street"? Which "submit" does he or she translate? We need some kind of annotation. This annotation could or should be have SGML syntax so that high powered SGML authoring tools can present the text to be translated, and protect the text which must be left alone. In an XML scenario one possible option is that you leave the XML data as it is and provide localised style sheets to present the data according to the locale. Using xsl:define-constant to define localisable strings like this. <!-- Please Localise values (but not names!!)--> <xsl:define-constant name="Car" value="Car"/> <xsl:define-constant name="Bus" value="Bus"/> <xsl:define-constant name="Transport" value="Transport"/> <xsl:define-constant name="Submit" value="Submit"/> <!-- in the sense of sending a form off"--> <!-- End Localise --> Then the translator at least knows what he has to do. Nigel W. O. Hutchison Technical Consultant Software AG Germany mailto:nwoh@s... Tel +49 (0)6151 92 1207 * xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
