Frontend Internationalization Readiness Checklist
A readiness checklist for frontend internationalization. It covers string externalization, message formatting, locale-aware data, right-to-left support, text expansion, and translation workflows.
When to Use This Checklist
Use this checklist when preparing a web application to support multiple languages and locales (internationalization, or i18n). Run it before entering new markets or when adding right-to-left language support. Retrofitting i18n into an app that assumed a single language is far harder than building it in, so plan the work carefully.
How to Use This Checklist
Start by externalizing every UI string into resource files; hardcoded text is the root blocker for translation. Choose an i18n library and a message-format standard that handles pluralization, gender, and interpolation, because naive string concatenation breaks in languages with different grammar and word order.
Localize data, not just words. Dates, numbers, and currencies need locale-aware formatting, and the document language and direction attributes must be set per locale. Right-to-left support means mirroring directional UI, not just translating text, so plan for it explicitly.
Design for variability. Translations are often much longer than the source, so verify layouts tolerate text expansion without breaking. Establish a translation workflow, ideally with a translation management system, and use pseudo-localization in tests to surface hardcoded strings and layout problems before real translations arrive.
What Good Looks Like
All strings are externalized, pluralization and interpolation are handled by a proper i18n library, and dates, numbers, and currencies are locale-aware. Right-to-left layouts mirror correctly, layouts tolerate text expansion, and document language and direction are set per locale. A translation workflow and pseudo-localization testing are in place.
Common Pitfalls
The biggest pitfall is concatenating strings, which produces broken grammar in many languages. Teams forget text expansion and ship layouts that break in German or Finnish. Right-to-left support is often reduced to translation while directional UI stays unmirrored. Hardcoded strings linger until pseudo-localization or real translators expose them.
Related Resources
Pair this with the frontend internationalization practice, responsive web design for expansion and RTL, and WCAG 2.2 for language attributes. Building i18n into a design system keeps it consistent.