Hi Peter
Apologies, I plan to publish some detailed guidelines for how to use the i18n framework. Let me explain briefly how the framework works and what's involved.
There are two main parts to the i18n framework both of which react to a new link in the default EV3 header that enables the user to select the language for Essential Viewer:
- i18n for instances in the repository. Translations for any element in the repository are captured using the Synonyms instances, which allows you to provide translations for the name and the description of the element. The language that is being used for the translation is defined against each Synonym, by selecting from a list of Language instances. Within Essential Viewer, the latest Viewer Engine can select which name and description to render, in the selected language, for the instance. The mechanism for this requires no action on the user's part beyond defining the Synonyms for an instance.
- i18n for the View 'chrome'. Translations for all the 'static' content on the Essential Viewer pages. An XSL function is available as part of the framework and this is used by sending the default language text (e.g. in English) to the function. The function then looks up the translation for the selected language and renders the translation or the default (e.g. English) text if no translation is found. So, imagine we have a static paragraph:
Code: Select all
<p>Welcome to Essential Viewer</p>
we modify the View Template XSL to make the 'chrome' translate-able as follows:
Code: Select all
<p><xsl:value-of select="eas:i18n('Welcome to Essential Viewer')"/></p>
Note that if strings with the ' character are required, you can swap the " and ' in the select statement to include it in the string, e.g.
Code: Select all
<p><xsl:value-of select='eas:i18n("Welcome to Essential Viewer")'/></p>
Translations are defined by defining translation XML documents, one for each language that is available. These simple XML documents contain each static string and the relevant translation. We have a simple XSL tool that can rip the translate-able static content (the parameters for the eas:i18n() functions) from the View XSL and produces XML snippets that can be pasted into the relevant language XML documents. Of course, static content can be re-used, so we can easily have a single XML document for all the static content for all the Views for each language.
The language documents look something like (please excuse any poor French translations... ).
The language file is named as per the standard language identifier e.g., fr-fr.xml:
Code: Select all
<dateformat>[D1o] [MNn], [Y]</dateformat>
<numberformat>#</numberformat>
<strings>
<message>
<name>Hello World</name>
<value>Bonjour tout le monde</value>
</message>
<message>
<name>Home</name>
<value>Accueil</value>
</message>
<message>
<name>Empty Tag</name>
<value/>
</message>
</strings>
</language>
In terms of what is involved in translating the static content and the tools required, it is relatively simple. Obviously, the static content needs to be translated from our default English but to summarise:
1. Add the function calls [eas:i18n() ] around the static text to be translated in all the Views. We've been looking at creating a suitable search/replace pattern to quickly apply this to all text in all our OOTB Views. Oxygen XML is proving helpful here.
2. Run the 'getChromeText.xsl' on the updated View XSLs (e.g. in an XML tool that can run XSLT) to produce the XML language documents, ready to be translated.
3. Provide the required translations in the XML language document.
I'll get the relevant software components shared in the 'Share' section of the site and post back.
Hopefully, this helps to give some idea of how the framework works and what's required.
Jonathan