+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.