Not exactly.
I’ve been using variations of this approach for about 3 years now, and the approach has evolved and been refined with each new App that I’ve implemented it in. The current approach works as follows:
- I have a separate “Strings” table. This table has one row for each text snippet that is used anywhere in the App.
- I have a JSON column that contains the translations for each supported language. It looks something like this:
{
"translations": {
"zh": "输入总工作时间",
"ms": "Masukkan Jumlah Jam bekerja",
"ta": "வேலை செய்த மொத்த நேரத்தை உள்ளிடவும்"
}
}
- I use a JavaScript column to extract the appropriate translated value, based on the Users preferred language, which is stored in the User Profile.
- In my User Profile table, I create a series of Single Value columns - one for each row in my Strings table. Each one takes
Nfrom start from the Strings table, beginning at zero. - I then reference those Single Value columns where ever I need them in component settings.
So a typical component configuration might look something like:
In the above example, each of the Field Component Labels (and the Title) takes a value from User Profile → s/number
The most tedious part is creating all the Single Value columns in the User Profile (I have one App that has almost 300 of them), but the naming convention that I use makes it pretty easy to quickly duplicate/edit/save. And once it’s done, it’s very easy to manage.
You might ask the question - why not use an integration to dynamically translate on the fly? I have done this in one App, using Google Translate, and the cost skyrocketed. And because this is all static text that never changes, dynamic translation is really overkill.