[electroly]

It's no joke, really. I worked on a product (B2B, not consumer software) that was primarily sold in the US and Germany. Not only did we leave the product in American English, but the Germans requested that we force all numeric inputs/outputs to use American formatting (period for decimal point, comma for thousands separator, even on computers configured for German formatting). To them, it was American software and thus it made sense for it to be in American English. Their English was certainly better than our German.

[soperj]

In most of my interactions with Germans, their English is also better than my English.

[jannesblobel]

TLDR: i18n is more than just using translation tools; it requires collaboration among developers, translators, and designers. Developers need good DX tools, translators need TMS or CAT tools, and designers need translation visibility in Figma. Proper i18n is a continuous process and should be integrated from the beginning to avoid major issues.

Disclaimer: I have a connection to one of these companies, just want to share some knowledge. I strive to be as neutral as possible.

Fun fact: I'm German and know the challenges with the UI. It's a love/hate relationship!

The problem with i18n (internationalization) is that many developers and product owners believe it’s only about implementing a library and letting Google Translate, DeepL, or even ChatGPT do the rest. As most of you already know, that approach doesn't work well for German speakers. My language will break/destroy your UI design.

The real issue with i18n is that it involves many stakeholders throughout the process. Here are the most important ones to start with:

Developers: These folks need to implement a library and want a good DX (Developer Experience). It means You should choose a library with an IDE extension (e.g., VS Code's Sherlock i18n, i18n Ally). - Libraries: Please use something that utilizes .json files. Formats like .po are cumbersome and will cause many issues. - Use tooling that supports an ecosystem around it, like lint rules, to save time and effort.

Translators: Ideally, your preferred solution includes a TMS (Translation Management System) or a CAT (Computer-Assisted Translation) tool.

Designers: If your designers can't see the translations in tools like Figma, your UI will break, and users will complain. Figma plugins like Parrot, Phrase, or Weblate can help (just search for 'i18n' in Figma's marketplace).

All the apps mentioned are just a few examples among many tools available.

Conclusion: The important stakeholders in this process are Developers, Translators, and Designers. i18n is an ongoing process, not a one-time task. If you start your app or project with i18n from the beginning, the annoying parts are manageable, and it won’t cost you all your nerves.