7 tips to make your localization work more productive

Did you find out a smart way to handle i18n, and it didn't work again? See our 7 tips how to make your localization better and easy to maintain. We worked for over 4 years with many companies on their i18n localization systems. Now we are sharing our experience with the audience!

Use unique translation keys

For each translation, use a separate translation key. Do not try to cheat the system. This may result with changing translation in multiple places, which may not fit everywhere. It's hard to discover such problems later. Try to keep one i18n key per translation. This allows you to precisely edit content in place where you want.

Don’t capitalize with CSS

When you try to cheat the system using one key in multiple places, you will notice that in some places you need capitalized translation, and somewhere else you don’t want to use this. The solution is to use unique translation keys for every place, and capitalize it properly. Remember that different languages have different grammar rules. Not in every language we capitalize the days of the week. Many users will easily notice the grammar issues, and this can cause they won't stick with your application for a long.

Use same translation keys in buttons

If some action in your service does the same thing, then you should use the same translation key every button. This is one of few places where you should use the same translation key. Thanks to that, you will always keep the context. The same wording will help your users to understand what they are doing. Be consistent, users will thank you and more easily understand the system.

Don’t nest translations

How many times did you tried to create fancy directory structure to get everything clean and tidy? Probably many. After a few days, you end up with the same mess which you had because instead of searching the correct directory, you just put files to ‘temporary’ directory. It looks like the same with the translations.

In many i18n libraries, it’s a common approach to use nested translations like the following:

{
  "nav": {
    "buttons":
        {
          "get-started": "Get Started"
        }
  }
}

Don’t do this, this tidiness is artificial, and it won’t help. Imagine that your app will evolve because the only constant in software development is change. Moving translations around will be a nightmare. After some time, the translation key may not belong anymore to some parent node. Then you will have to choose which key should go to another nested group.

Keep flat structure

If you think that keeping translation in 'groups' is a good idea, then consider using prefixes. In some scenarios, it is a good idea, for example for navigation keys, or buttons. You can use category for each translation keys like following: nav-product-solution or nav.product-solution

It makes sens because you will exactly know which translation will be changed.

Consider i18n management

Translation management is being more and more important topic when your project grows. Many i18n libraries use JSON files to keep translation files. The structure varies, but in general, all of them looks similar. The biggest i18n problem is that it’s very hard to handle without a proper tools. Image that every of translations are packed into separate json file named: "en.json", "de.json", "fr.json", "it.json" and every file contains structure like this:

{
  "sign-in": "Sign In",
  "get-started": "Get Started",
  "register": "Register",
  "logout": "Logout",
  "close": "Close"
}

Adding a translation to many files can be frustrating and slow down the development process. Now you need to send it to translator or translate it on your own using ChatGPT from OpenAI, DeepL, Google Translate, or Microsoft Translate. Creating localized apps or games can be really annoying in such conditions. That is why we created SimpleLocalize. Clean, simple, and user-friendly system for handling i18n. We provide many i18n library integrations including i18next, FormatJS, Android and iOS. Translation keys can be easily extracted from the projects, uploaded to translation editor. Our localization command-line tool can simplify this process. Watch our Quick Start Guide on YouTube to see how your life can be easier with the SimpleLocalize!

Finding unused translation keys

One of the biggest issues in agile teams is that system changes and evolving fast! That causes a problem with translations which must keep up with a product evolving. It’s easy to add a new translation in code and ping translators. But what happens when your product now contains 10x times more translations keys than the beginning? Many of them are still useful but not used, the key has been changed, but the meaning is still valid, so it’s hard to say if we can remove it or no. The solution is SimpleLocalize system, which will help you in finding out which translation keys are not used in the code. Integrate your project with our translation management service and sort translation keys by last occurrence! To extract translation keys from the project files, you can use our Localization CLI Tool. It’s open source, so it can be used in an enterprise project.

Conclusions

App localization is not the easy topic. Many people tried to find out the new smart way of handling it, many of them failed due to over-engineering stuff. How about keeping everything simple, and clean? Try to always follow the KISS rule, every professional software developer will tell you that!