Help Requested - Language Files for Essential Viewer

[neil.walsh]

Hi,

We're looking for the community's support to help with the translation of Essential Viewer. We have a XML translation files for the following languages

• ar-sa.xml
• da-da.xml
• da-dk.xml
• de-de.xml
• en-gb.xml
• en-us.xml
• es-es.xml
• fr-fr.xml
• lt-lt.xml
• pt-br.xml
• pt-pt.xml

If you can help in any way, then please repost the updated files in this post and we will look to add these to future releases.

Thanks

Neil Walsh
The Essential Project Team

[jmk]

Hi neil.
See below, some thoughts about your call to translate :

Discussion point 1 : use a "standard' file format for translation file exchanges ?
As the former initiator of the French translation, I must confess that working from essential files is not the best way to maintain a translation project, as this file format precludes the use of a translation memory capability or even the use of a simple multilang editor.
Could it be possible for you to use a "well known" file format for interchange of such files ? I previously used gnu gettext format for my translation tasks but a more xmlish --- such as "TMX" or "xliff" --- could be possible as XML based file formats would ease round-trip operations.

Discussion point 2 : could it be possible to split the translation tasks from the viewer github repository ?
Separating translation artifacts in another project would be preferable as it could be then possible to work on the translation tasks without interfering with the open-source distribution ones and maybe, in the future, easing its migration to a Translation Saas platform.

Discussion point 3 : Translation is not the only i18n tasks for an application (aka "an English report is better than no report at all")

Essential has a serious problem when it comes to non English string processing in JSON/Javascript : my first message about lack of display for some reports is from 10 years ago and there are still display defects in some reports now.
Maybe you could devise some test platform (using python/java embedded JS interpreter) to get rid of these problems ?

Your thoughts ?

Regards,
Jean-Marie.

[neil.walsh]

Hi Jean Marie,

1. This is mostly an artefact of the original implementation of multi-language capabilities for Essential. We are looking at this for other parts of the overall Essential platform and will adopt more standard approaches in those components. Once we have some experience in those "green field" applications, we will hope to bring that experience back to Viewer. We know the Viewer i18n implementation is not ideal but in terms of Viewer development priority we are looking to spend our development resources on other things such as performance and UI modernisation. Once Viewer is in a better place in that regard, we will return to i18n support.

2. We have done this already. You can find the project here. https://github.com/essentialproject/ess ... iewer-i18n

3. I didn't follow this. Can you expand a little on this point?

We're constantly working on improvements to non-english string processing. This is more complex than it may seem as Essential utilises many different programming languages concurrently. In Viewer for example, you may have to escape text one way in XSL and then subsequently in JS or JSON. Newer Views tend to be more robust in this regard, but we are working our way through the older views to either patch or rewrite as we go. We believe we have improved significantly in the past year or so but if you are still experiencing issues with specific Views then do let us know.

Thanks for taking the time to feedback.

Neil

[jmk]

Hi Neil,

1: My intent was not to imply that you should change the DTD for i18n translation files, it was more about the choice of an intermediary format that translators could use to ease their work.

2: I missed this recent github repository dedicated to translations well done ...

3: About JSON/JS string repeating problems : My principal concern here is that, since many years, display of several reports simply fails when French is used to populate the repository. Root causes of these defects are mainly because of bad string handling in JS/JSON. Be these JS/JSON strings produced statically in reports or accessed through the API. Moreover it also remind me of some regression problems where reports were fixed in a revision but were defecting again in a new one.

IMHO, if EAS is to take seriously i18n into account, 1) work should not be on translation first but rather, an higher priority should be given to these string handling problems and 2) some automated tests should be used to check that problems of this kind are not occurring again and again.

J.-M.

[JohnM]

Hi J-M,

I've spoken to the team and we're looking to move to using XSL3 and the serialize function (noted from one of your other posts) to prevent the character issues. The challenge is the impact, and how to update all the views, which we're working through (note a number of reports will be deprecated).

We're testing a replacement for the functions such as renderMultLanguageInstance, which will work for the newer style JSON based views where the JSON is created inline, we have some of those and we are aware of people building reports who do this. Some of the older views will probably remain on the old version (where we have a set of characters we escape and update as we see new character issues). The data marts will need to be rewritten - we have a major update coming soon that impacts the marts and will try and roll the changes into those at the same time, depending team capacity.

It is on the stack to do, and please keep the feedback coming.

John