internationalization / localization of th viwer

Post Reply
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

We plan to do i18n/l10n work on the stylesheets.
Do you think saxon-gettext (http://xmlguru.cz/2006/10/saxon-gettext) would be a sensible way ?
An alternative would be to use some purely xml-ish way but we think that the first solution should perform more efficiently.
The main impact of the choice will be on the protégé side :
  • with gettext L10n messages will be kept in "po" files and not formatted in xml. So it will be more difficult (will need some coding) to manage these message in protégé.
What do you think ?

J.-M.
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

Whatever solution we choose, we will have first to extract the literal strings embedded in the stylesheets.

How may I submit these extractions to the project ?
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi, thanks for these posts.

I think that Saxon Gettext solution looks very interesting. We are also working on i18n in Essential Viewer and this solution is something that we will certainly be looking at. We would be very interested in hearing any experience that you have with it.

On the modelling side (in Protege), we manage i18n/l10n using the Synonym instances. Any element in the repository can have one or more Synonyms and we can use this to define Synonyms that provide alternative language for the name and description of that element. We then classify that Synonym using a 'Language' Taxonomy Term (e.g. 'English', 'French, 'Spanish', etc) to capture which language that Synonym uses.
We haven't defined the 'Language' Taxonomy in the out-of-the-box baseline repository but we will formalise this shortly.

In terms of submitting the text extracts to the Project, that would be excellent. Our standard process is for you to complete the Contribute form and we will set things up to enable you to share those extracts. We certainly appreciate the help from the Community in terms of translating the 'static' page content.

Jonathan
Essential Project Team
jmk
Posts: 137
Joined: 31 May 2012, 12:08
Location: France

Jonathan,
my inital post was mainly about the static translation of the stylesheet but I do appreciate your informations about the synonym slot.

I did not try to use saxon-gettext yet and I'll have a look on the contribute page next ...

J.-M.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Yes. We are currently working on a framework that will handle both static page content i18n and i18n for the content in the repository.

Thanks again for pointing out the Saxon GetText. We plan to use that for managing the static page content. I'll post back when we have some more details.

Jonathan.
Essential Project Team
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Just wanted to post a quick update on this.

We've taken a look at the Saxon Gettext (which looks nice) but there are some complexities - e.g. compiling - the language files. We've put together a pure XML/XSL solution for i18n/l10n that covers both the Viewer and the repository content and we plan to move forward with that and we do not expect it to take much time to produce a beta version.

There will be a simple framework for managing the translations of the Viewer static content in XML files (very much similar approach to Saxon Gettext) and rendering this dynamically based on the selected language.

Jonathan
Essential Project Team
peter.fuzi
Posts: 11
Joined: 30 Jul 2012, 08:52
Location: Telki, Hungary
Contact:

One more mate in Central-Europe checked into the queue waiting for sorting out this localization issue.

Should you need some assistance, I offer my contribution to the end-user testing phase.
Thanks with regards, Peter
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Thanks Peter.

We have implemented the framework for managing this and we're packaging up the components of it for a release shortly (meta model and Viewer)
We certainly would appreciate help producing the language packs for Viewer.

Jonathan
Essential Project Team
peter.fuzi
Posts: 11
Joined: 30 Jul 2012, 08:52
Location: Telki, Hungary
Contact:

Please, provide me with some guidance on the relevant details (literals/messages to be translated + technology) to the localization effort so I can understand the scope of the needed work.

Thank you, Peter
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

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
Essential Project Team
Post Reply