Adding Languages
Background
There are two categories of objects in Servigistics InService:
• XML source that contains many locales for specific attributes (for example: PL, Part, and BOM)
• Objects that are authored in various locales (for example PDFs and IEXMLs)
Px bundles have a mandatory artifact called translation.xml that maps keys to strings of the target language. The XML source will always be published in the authored language, but the target language strings will be supplied in translation.xml. This XML contains the translated value of a given string along with its authored locale.
In example below, the authored language is en and ja translations are present in translation.xml.
Translations from this XML are stored in a database table called SC_DICTIONARY. This contains transid, locale, the authored locale, and actual translations.
When a single object document is transformed, all the available translations from SC_DICTIONARY are merged. See the following example of a parts list after the transform of English and Japanese bundles.
Here, the name of the parts list is available in en and ja, and the authored language of this string is en. When the user interface requests either of these two languages, the corresponding translation is provided. However, if the user interface requests a different language, the translation matching AuthoredDoclang is provided. In other words, the language fallback behavior is to deliver the content in the authored language when the user language preference cannot be met.
You can use the EXSLT extension function select-lang in the view stylesheet to provide selected language data as shown below.
To get the preference language variables lang1 to lang6, you need to import langSlitter.xsl as shown below.
| “x” is the generic language indicator if no language is specified. This is added in the transform in locations where the content is expected to be multilingual, but no such content was found (it was not localized). You will not see a mix of actual language codes and “x” language code. The select-lang extension function above retrieves the first language it finds according to its parameter list in left to right order of priority. |
Adding a Language
For existing types, no TAL customization work is needed. However, you do need to configure the user interface. Refer to Customizing the InService User Interface in the Servigistics InService Customization Guide
You also need to do TAL customization to add a language to a new type or attribute. For ML bundles, translations.xml is processed once before performing any form of transformation. The processed file is available at the following location for further reference in transformation:
INS_WORK/Applications/ContentManager/Work/PreProcessing/TAL/TransformationDriver/TaskId
Following is part of the translation.xml file:
To use this file, you must add an additional input parameter named translationXML as shown below.
You can look up this file for the actual translated value based on the translation ID and populate the language information along with its value in the transformed XML by following these steps:
1. Process the input file as a document.
2. Define the keys:
3. For each translation attribute, look up the translated values for all desired languages based on the translation ID:
4. Populate the translation language and its values based on your requirement.
Following is sample output of Desc in the en-US and ja locales:
