2025-02-22 18-27-01
Alfaro
 
MVP
Set Multilingual Translations in Runtime
405
Views
3
Comments
New
Other

Hello,

We would like to be able to set the Multilingual Translations in Runtime, without having to edit the modules and republish - this would be good for in-production fast corrections.

This feature was previously available when using the Multilingual Mobile Component.

Thank you.

Hi Carlos,

That is a good idea and we might evolve the product in that direction in the future.

Although currently it's not possible to change translations in runtime, Service Studio has 2 command lines options that let you automate the exporting and importing of multilingual resources.

  • -export <eSpace.oml> <directory> xls|xlsx|resX [<output>]
  • -import <eSpace.oml> <resources.xls>|<resources.xlsx>|<resources.resX> [<output>]

This might come handy if anyone wants to automate the process of integrating translations done by external providers.

Cheers,
Tiago Simões

Thanks Tiago for your post. Nice to know those commands

Regards

+1

Translations are a pain because we need to constantly exchange excels between stakeholders and corrections take a long time to be implemented as the people who actually translate resources do not have access nor know or want to use service studio. Besides, having translations as part of development cycle is cumbersome, as we either need to push the code upstream because of a small wrong translation error outside the control of the dev team or perform an hotfix, with all associated risks.

I get why you changed to this method, but imo, this method is inferior and very painful to the developers. Translations should not impact the development tlifecycle nor should they be so cumbersome to the dev team.

With the previous react method I was able to make translations painless by modifying this component in a way that developers would just add resources and the different stakeholders were able to translate on-the-fly and push translations upstream with the push of a button and completely outside and without impacting the development lifecycle. With the new method, I can't do thisusing supported actions.

So, in short, I beg you reconsider and integrate two small changes into the product:

* Being able to add locales dynamically
* Being able to add resources and translations dynamically

Ideally, OutSystems would even provide some kind of translation app that would allow runtime translations out-of-the-box, but having the methods that allow us to build that application would be a good start.


This will allow bigger projects with a lot of different languages, resources and stakeholders to automate and delegate translations, greatly reducing the overhead and the stress on the development team.