pain: manual translation management

[samuelstroschein]

Problem

Managing translations by editing JSON files manually is tedious.

Possible Solutions

• dashboard to manage translations

[ivanhofer]

Hi,
a dashboard is necessary for bigger projects because the translations probably will come from non-technical persons, that don't know how to use git. I found a few services that can handle the translation-process:

• https://locize.com/
• https://simplelocalize.io/
• https://lokalise.com/

You then have to ping their API and get the texts from there.

But in my opinion the ground-truth (what translations exist) should be located in the code itself and not on an external service.
I find your approach really good because you tell the dashboard what the application needs :)

[samuelstroschein]

I found a few services that can handle the translation-process:

Are you using or have used any of them? If yes, what is the feature that brings the most value for your i18n pipeline. If not, why not?

[ivanhofer]

I haven't used any of them yet. I have used webtranslateit for a kotlin-project at work. I didn't really played around with the service that much, but I think it is the same as the others, just with a not so modern design.

[ivanhofer]

My problem with theses services is that they don't offer that much validation. (As far as I can see from their product pages)

[ivanhofer]

I just wonder: you auto-detect translations and then make HTTP-calls to the dashboard. I assume these HTTP-calls will only execute when that part of the application is being accessed in the browser. That would mean in a bigger application I would need to visit to each page at least once in order to let the dashboard know what translations I still need. Conditional logic makes this process even harder e.g. if (user.role === 'editor') else if (user.role === 'guest')

[samuelstroschein]

That would mean in a bigger application I would need to visit to each page at least once in order to let the dashboard know what translations I still need.

Correct. This mechanism exists because of the very first proof of concept. I initially thought, "why do I need translation json's in my code? I can just fetch the translations from a server via SSR.". To avoid the "which translation (keys) do exist?" problem, the client (browser) would simply inform the dashboard that this specific key was missing. Since the client was using the remote translations, the translations were instantly updated without mingling around in JSON files or changing any code. Therefore, I suspected the problem of visiting each page to not be too problematic. Even if a translation is missing, the first user to hit that specific site would "alert" me that there is a missing translation; and this could be fixed in a matter of seconds.

That approach had the big downside of relying on SSR which I experienced 3 weeks later while developing an embeddable widget where no SSR was possible.

[ivanhofer]

You either need to analyze the whole code-base for i18n text (maybe as an CI process) or to have a single source of truth. JSON-files or like in the case of typesafe-i18n a base translation.
Ideally the process of checking missing translations is NOT done during run-time. Before it even hits the first user. (It is good that you get an alert, but what if you are sleeping or on vacation for a week. So the text would take a while to update. Automatic translations would be a good first step, but knowing possible errors before they happen is superior to having to wait for an possible error to occur)