Did you find out a smart way to handle i18n, and it didn't work again? Checkout 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 separate translation key. do not try to cheat the system. This may result with changing translation in multiple places which may not fit in all places. It's hard to discover such problems later. Try to keep one i18n key per translation. This will allow 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 you don’t want to use this. 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 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 the one of a few places where you should use the same translation key. Thanks to that you will always keep the context. Same wording will help you 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 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 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 uses 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 contain 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 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 and downloaded back on local disk. Our localization command-line tool can simplify this process. Book a demo with me to see how your life can be easier with the SimpleLocalize!

Finding unused translation keys

One of the biggest problems in agile teams is that system changes and evolving fast! That causes problem with the 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 is 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 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!

This post has been originally posted on SimpleLocalize Blog. Link: https://simplelocalize.io/blog/posts/easy-localization/