How can i keep my code changes and text localizations synchronized?

Question

For a localized service or application, whenever one is checking in code with new strings, it implies that localization for those strings is needed. Now, I need to ensure that there are no unlocalized strings in the code OR how can I easily find out which strings are not localized.

Here are some thoughts on my question:

1. When a code is ready and has non-translated string, the PR will be blocked until the translators also add/update the translations in the same PR.

2. The alternative is messy. Before the release, we will have to run some tool to see which strings are present in the default (probably English localized) file, and missing from any other localization. This means that then we will be blocked from our daily or weekly release until localization is complete OR we will have to create reverts .

Is there any better process?

Answer 1

You can use feature toggles to decouple feature activation from your deployments (e.g. described here https://www.martinfowler.com/articles/feature-toggles.html ). This way you can push a feature that is ready in code, but doesn't have all the translations. You can also have a test version in which you can turn on the feature so translations can be tested without having to rebuild the application or a version that only has English translations can be demoed.

Then you can test whether all translations for the new feature are present, before you activate it.

Feature toggles are a powerful tool that is not too hard to implement; and they not only useful for dealing with translations, so they should be worth the investment.

Answer 2

Let’s say you changed the order of two buttons and instead of “press the first button” you want to say “press the second button”. In that case enter “xxxxxxpress the second button” as the translation. Now you can continue. French, German, Italian versions can only be shipped if a search for “xxxxxx” in the translation files finds nothing. And the translators know immediately what new translations are needed.

You define the state of your project as “ok” if all missing translations are clearly marked.

Now if you are looking at an entirely new feature, then language-dependent feature flags also help. So you can ship a product in some language with a feature enabled or disabled. There’s a problem if the user picks the language at runtime, so the code for the feature would always be present, but you’d decide based on the language if the feature is present in the UI. Or your code looking up translations just removes the xxxxxx in a translation if found.