The post processor has built-in support for localization of the configuration script. The translation API allows the post configuration to be separated from its translation. Arbitrary messages can be translated into a specific language using the localize() function. When invoked localize() will lookup the specified message in a translation file (known as locale) which must accompany the configuration script. The path of the translation file is derived from the path of the configuration script by substituting the extension with the selected country code (see setLangId()) and adding '.lang'). For instance, if the path of the configuration script is 'C:\posts\genericiso.cps' and the language id is 'de' then the translation file path will be 'C:\posts\genericiso.de.lang'. The post processor will also try to load the translation file 'common.?.lang' (where ? is substituted with the country code). This allows several post configurations to be translated using a single translation file. The translation files are prioritized such that the last loaded file takes percedence over the other files.
The following line would write out "; Werkzeug" if used with the translation file listed below.
The translation file is an XML file which could look something like the following.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <?xml-stylesheet type='text/xsl' href='locale.xsl'?> <locale xmlns="http://www.hsmworks.com/xml/2008/locale"> <!--The content of this document may be covered by copyright--> <description>German</description> <country>de</country> <message name="Tool">Werkzeug</message> <message name="Level">Niveau</message> </locale>
This translation file will map the text "Tool" into "Werkzeug" and "Level" into "Niveau". All other text will not be translated unless another translation file maps the text.