Lessons From Linguistics: i18n Best Practices for Front-End Developers

Summary

Front-end internationalization can fail when code encodes English assumptions about word order, punctuation, pluralization, gender, or text layout. The post uses an image-status example to show why a complete sentence should be translated as a whole, then examines interpolation through a reusable status bar whose file-type and count values vary across languages. It explains that plural categories can include zero, one, two, few, many, and other, with Polish examples showing why numeric rules should not be hardcoded, and that gender can affect articles and adjectives, as in French. Its recommended practices include keeping linguistic decisions in translation strings, avoiding code-level text construction and elaborate styled layouts, and letting i18n libraries select plural forms from quantities; complex promo layouts may need simplification or language-specific images.

Context

Applications serving multiple languages can produce grammatical errors or garbled sentences when English-language assumptions are preserved in code and translated strings are handled piecemeal. The source identifies differences in punctuation, word order, pluralization, grammatical gender, and text layout as recurring causes.

Approach / What changed

The post demonstrates whole-string translation and interpolation with reusable components, examines plural and gender differences using English, Polish, and French examples, and recommends delegating plural-form selection to i18n libraries. It also advises avoiding code-level text construction and simplifying elaborate styled layouts or providing language-specific images.

Takeaways

• Translation strings should contain the complete sentence when word order or punctuation can vary between languages; interpolated values can then be placed appropriately by each translation.
• CLDR plural categories include zero, one, two, few, many, and other, and Polish number endings demonstrate why selecting forms with rules such as count === 1 is insufficient.
• i18n libraries can select the appropriate plural form from a quantity, so application code should pass the count rather than directly choosing categories such as many.

Related reading