i18n
- The blog post explains how to validate react-intl applications and ensure that all keys are in a valid state and no keys are missing or broken for all translations.
- Localizing your React application requires more than replacing strings, it has to consider date and time, numbers, pluralization, grammar and other requirements. This checklist should help with getting started with your internationalization efforts and avoid pitfalls and blockers.
- 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.
