i18n
- An introduction into how to run i18n validation checks on the CI to ensure your translation are in sync.
- Designing user interfaces that can adapt to internationalization requirements by considering how the user interface can break and ways to prevent it.
- Most development areas have seen an increased focus on the developer experience, resulting in better solutions and tooling. I18n is a development area that doesn’t have the same developer experience. This post tries to uncover the complexities around i18n and developer experience.
- In this second part of our i18n checklist we cover more aspects like Unicode, right-to-left languages, testing and validating your localization, device sizes, and conditional text and grammar.
- Localization is more than just replacing a couple of strings. It requires us to think about aspects like date and time, numbers, pluralization, grammar and many more locale-specific requirements. Find out more in the first part of our i18n checklist.
- With TypeScript being the de-facto standard way to write React applications it only makes sense to expand type-checking to translations. In this post we explore the tradeoffs of type-safe translation keys.
- In this post we introduce i18n-check: a tool that tries to compare your secondary languages to the base language files and report missing, broken or invalid translation keys.
