Going Global

Internationalization (i18n) is engineering your application to support multiple languages and locales without code changes. Localization (l10n) is adapting the content for a specific locale — translating text, formatting dates and numbers, and adjusting cultural references. At Nexis Limited, our SaaS products serve clients across multiple countries, requiring comprehensive i18n support.

Architecture for i18n

String Externalization

Never hardcode user-facing strings in your source code. Extract all text into translation files (JSON, YAML, or PO files) organized by locale. Use a library like next-intl, react-i18next, or vue-i18n to load translations at runtime based on the user's locale.

Translation Key Design

Design translation keys that are descriptive and hierarchical. Use keys like "dashboard.welcome.title" and "shipment.status.delivered" rather than generic keys like "text1" or "label_42." Good keys help translators understand context and help developers find translations in the codebase.

Locale-Specific Formatting

Dates and Times

Date formats vary dramatically: MM/DD/YYYY (US), DD/MM/YYYY (most of the world), YYYY-MM-DD (ISO/East Asia). Use the Intl.DateTimeFormat API or libraries like date-fns with locale support. Always store dates in UTC and convert to the user's timezone for display.

Numbers and Currency

Number formatting varies: 1,234.56 (US/UK), 1.234,56 (Germany/Brazil), 1 234,56 (France). Currency formatting includes symbol placement, decimal precision, and grouping. Use Intl.NumberFormat for automatic locale-aware formatting.

Pluralization

Pluralization rules differ across languages. English has two forms (1 item, 2 items). Arabic has six plural forms. Russian has three. Your i18n library should support ICU MessageFormat or similar pluralization systems that handle language-specific rules.

Right-to-Left (RTL) Support

Arabic, Hebrew, Urdu, and Farsi are written right-to-left. Supporting RTL requires:

  • Setting the dir="rtl" attribute on the HTML element.
  • Using CSS logical properties (margin-inline-start instead of margin-left).
  • Mirroring layout — sidebars and navigation move to the right side.
  • Testing thoroughly — RTL issues are subtle and easy to miss.

Translation Workflow

  • Extract new strings from code into translation files during development.
  • Send translation files to translators (professional translators or translation management platforms like Crowdin or Lokalise).
  • Review translations in context — translations that look correct in a spreadsheet may be too long or contextually wrong in the UI.
  • Implement a fallback chain — if a translation is missing, fall back to the default language rather than showing a translation key.

Database and Content

User-generated content and database records may need localization support:

  • Store text in UTF-8 to support all character sets.
  • Consider multi-language content fields for structured data (product names, descriptions).
  • Handle locale-specific search and sorting with database collation settings.

Conclusion

Internationalization is easiest to implement from the start and expensive to retrofit. Even if you launch in one language, architect for i18n from day one — externalize strings, use locale-aware formatting, and test with long translations (German strings are typically 30% longer than English). When expansion time comes, the infrastructure is already in place.

Building a global product? Our team builds internationalized applications for diverse markets.