
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 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.


![localization progress](/blog/localization-progress.jpg)

## 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:
```json
{
  "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](https://medium.com/skiplist-publication/software-principle-11-the-only-constant-is-change-5c3be83c9ec5). 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](/translation-editor) 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:

```json
{ 
  "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](https://www.deepl.com/home), [Google Translate](https://translate.google.pl/) or [Microsoft Translate](https://www.microsoft.com/translator/). 
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](https://simplelocalize.io). We provide many i18n library
integrations including [i18next](/docs/integrations/i18next/), [FormatJS](/docs/integrations/format-js/), Android and iOS. [Translation keys can be easily extracted](/docs/cli/get-started/) from the projects,
uploaded to [translation editor](/translation-editor/). Our localization command-line tool can simplify this
process. [Book a demo with me](mailto:contact@simplelocalize.io) to see how your life can be easier with the SimpleLocalize!

![easy localization progress](/blog/localization-progress-bonjour.jpg)

## 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](/docs/cli/get-started/). [It’s open source](https://github.com/simplelocalize/simplelocalize-cli), so it can be
used in enterprise project.

## Conclusions

[App localization](/react-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! 



Translation Hosting

SimpleLocalize CLI

REST API

Customer-specific translations

Posts tagged with `easy-internationalization`

Easy Internationalization: 7 tips to make your work faster