I wanted to quickly discuss how we want to approach fixing, or not fixing OLMIS-5665 (https://openlmis.atlassian.net/browse/OLMIS-5665)
To summarize the reported bug: on some of the screens (not all) if one uses a translation plug-in (in this case - Google Translate, but the same may be valid for any other as well) the numbers/data that is displayed in our grids may become incorrect. The reason for that is that those plugins modify the HTML markup of the page, what is causing some of our calculations to get lost.
There’s a potential fix for this issue: adding notranslate class to the element that is not meant to be translated. This works fine for Google Translate, but it will likely not solve the problems for other translation plugins. Also, for this change to make sense we would need to go over all our UI screens and add this class to all the cells that contain numeric/calculated values or other stuff that is not meant to be translated.
OpenLMIS currently uses Transifex to support translations, but of course, the content needs to be translated by someone first, which is a downside comparing it to the translation plugins.
I wanted to get your feedback on whether we should invest time to fix the problem with external plugins, likely not all, but at least the most popular Google translate should work as expected. I’d estimate this to be a few days of work at a minimum. On the other hand, we could just state that we don’t support translation plugins and encourage to provide translations via Transifex.
What do you think?
First of all, we should investigate how many people are affected by this issue and why they are not using Portuguese translations from the Transifex. Are they incomplete? Are users unaware that the translations exist? Is project configured incorrectly?
If the result suggests we should cover this issue then I think we should consider using the “notranslate” class. However, I would like you to be aware that this might not help with numbers that are passed as parameters to the translatable messages (like “Showing X items out of Y total” in our pagination component) as we would have to add the class to the element storing the whole message. This scenario needs to be validated still.
What we could do about that is either admitting that the plugin is supported partially or change the way we’re dealing with displaying the numbers inside strings. We could do that by splitting the message into multiple parts and then placing them (and the numbers) in separate elements. This approach, however, would make our markup less semantic. Using our pagination as an example, we would have three separate messages - “Showing”, “items our of”, “total”.
I agree that in this specific case the recommendation should be to just use the OpenLMIS’ built-in translations. I’m assuming that there may be a case when the user wants to translate to a language we don’t have any translation for yet. I’m not sure how likely is that though.
It’s worth bringing up to the product committee, though my gut feeling is that this is internal enterprise software - national scale implementations will spring for making sure the translations are right in the first place, before they go to the great expense of training users on them. For smaller implementations, demos, etc though there might be a case, though I’d imagine only a small case for ensuring google translate works with the tables.
I’ve brought that up on the Product Committee yesterday and learned that:
- Angola is not encouraging users to use Google Translate
- Users just happen to have Google Translate installed and working for all the sites they are browsing
- They are likely using OpenLMIS with Google Translate unknowingly
Due to the above, the decision we have made is to turn off all translations from Google Translate, to make sure that they do not mess up any data on OpenLMIS UI. We have an easy way to tell Google Translate to skip translating the whole site. The recommendation is to use OLMIS built-in translations.