Go Global or Die Trying (A Guide on How Not to Actually Die Trying)

So, you're developing a product, and suddenly it turns out that most of the users are not from an English-speaking country.

Not a problem, but you've hard-coded all the text or kept it in an unorganized JSON file.

Now, instead of delegating it to some translator or using some AI to translate it fast, you are going to be implementing every single translation, and most likely, the translation will be out of context, and you will be in an infinite loop of fixing it after getting complaints from confused users.

🏃‍♂️ Don’t want to become an errand boy or girl for the customer support and localization team?

⏰ Here is how to save your future time:

Localization Nightmare

Maybe, even as a user, you have sometimes experienced parts of the UI in a foreign language and found it confusing?

I have had complaints from Chinese users that, apparently, the Chinese version we were providing was not the right Chinese language they had chosen. What was supposed to make the app accessible made it confusing and impossible to use…

The Excel/CSV workflow turns into a nightmare for version control. It may be nice when you just started development, but before you know it, you realize that you don’t know what is even going on now.

Contextless translations and the soul-crushing manual labor of copying strings between files soon will be your new best friend if you don’t optimize it :)

Translators work blindly without visual context, developers waste hours synchronizing code with translation files, and the worst part is discovering missing translations only when users report them. So, what can you do now to avoid ending up in this hell?

At What Point Should You Even Start Localizing?

The ideal time to incorporate localization is during your initial planning of the architecture. Even date formats and UI layouts that weren't designed with language expansion in mind can be a huge problem! Think of those things in advance. Localization is not just translation.

How dates and times are written, in what order the names are written, and whether the text is written left to right or right to left are some basic questions to keep in mind when building your app. Are you ever guilty of not considering any of those?

Excel at code, not at Excel

Escaping Excel might not be easy when you are so used to it. Modern localization management platforms have come to help you fight Excel madness. They centralize where developers, translators, and project managers collaborate, so that everything is up to date together with the code. Instead of thinking about translation as a static file exchange, these platforms treat localization as a process that evolves with your codebase. Examples of such platforms are: Tolgee, Crowin, or Phrase

Key Features That Will Save Your Sanity

1. Translation context preservation

Editing translations within your app interface is like a jump from using Notepad to VS Code. In-context translation means that translators can see exactly where and how their translations will appear. This way, words would not get lost out of context. Imagine if someone was localizing to English and suddenly your “Shopping Cart” is now called “Trash Can” because it is the same word in another language.

// en.json
{
  "welcome_message": "Welcome to our app!",
  "items_count": "{count} items found" // How is this used? No one knows!
}

When using visual editing that preserves context, translators click directly on UI elements in the actual app and translate with perfect context. No more guessing how long the text can be and what it refers to (especially relevant to languages like German).

Tolgee JS and React: https://tolg.ee/kgt1pp

1. Automatic Detection of Missing Translations

"We're launching in Spanish tomorrow,”

but nobody noticed that 40% of the new features that we added are actually untranslated...

When utilizing a localization platform, it tracks your translation and automatically flags missing or outdated translations before they become production emergencies. This way you prevent fires before you have to put them out.

1. CLI

The CLI (Command Line Interface) helps manage your project from the command line. Pushing and pulling strings is the most basic way to work with strings using the CLI. It helps to download strings to your system or to upload the strings after changes. It is almost like using Git, so it doesn’t require a lot of getting used to if you are familiar with Git.

Example from Tolgee that has an open-source CLI :

tolgee pull [options]

Example usage:
   tolgee pull --path ./i18n

tolgee push [options]

Example usage:
   tolgee push --force-mode OVERRIDE

1. Developer-friendly Workflows

To help you integrate everything seamlessly, these platforms are not just a visual playground for translators. They also provide:

• Git-like branching for translations alongside code features
• CLI tools for extraction and synchronization
• Figma and Browser plugins like the ones from Tolgee
• IDE plugins that highlight missing translations
• Preview environments for testing translations before release

What are the options?

If you are looking for an open-source, developer-friendly option, you can try Tolgee and find it on GitHub: https://tolg.ee/0qmbt7

Popular options:

1. Tolgee
2. Crowdin
3. Lokalise
4. Phrase

Conclusion

Step one after your MVP should be thinking strategically about how you will operate at scale. Think of the localization of different features, starting with dates and time, ending with text width and size. Integrate translation keys into your code and ensure they are named properly. Try open-source alternatives and features, such as plugins for Chrome and Figma, to simplify work for everyone.