Localization and Locale-Sensitive Data
Localization combines language, formatting, direction and product meaning. Keep messages translatable, choose plural forms through locale-aware rules, and preserve dates, instants and monetary units as data rather than preformatted strings. A locale is not a substitute for a timezone or a currency-conversion rule.
Test real user workflows in supported languages and layouts. Correctly formatting one date in a server runtime is useful evidence, but it does not establish translation quality, input parsing, accessibility or right-to-left browser behavior.
TL;DR
- Localization combines language, formatting, text direction, and product meaning.
- Keep messages translatable, and choose plural forms with locale-aware rules (
Intl.PluralRulesor ICU message formats), not English suffixes. - Store dates, instants, and money as data, and format them at display time.
- A locale is not a time zone, and formatting a currency is not converting it.
- Test real workflows in supported languages, including right-to-left layouts and accessibility, in real browsers.
Quick Example
The assertions depend on the runtime's Intl and ICU data, so output can differ between runtimes with different ICU versions. They check plural categories, a time-zone-dependent day boundary, and a currency-formatted part.
The same instant falls on January first in UTC and December thirty-first in Los Angeles. The plural API selects categories rather than writing a complete translated sentence. The currency formatter displays an amount as USD; it performs no conversion from another currency. The checks do not assert one exact punctuation string across all runtimes.
Core Concepts
Translate messages as meaningful units
Keep a complete message and its variable placeholders together so translators can adapt word order and grammar. Concatenating several English fragments can make a sentence difficult to translate correctly. Explain what each variable means and whether it is text, a count or a formatted value.
Distinguish translated content from user-provided content and identifiers that should remain stable. A document title, product code or person's name may need different handling from interface text. Avoid applying broad transformations without considering the meaning and source of the value.
Plural categories are locale rules
Intl.PluralRules supplies a locale-dependent category that a message system can use. Languages differ in their cardinal and ordinal categories; an English singular/plural branch is not a complete model for every supported language. PluralRules documentation
Provide the translated message forms required by the selected message system and locale. The category two is not itself an Arabic sentence. Test zero, one, two, larger counts and relevant fractional values with qualified language review rather than assuming integer examples cover every grammatical case.
The matrix is an editorial review framework. Only the stated Intl formatting behavior was executed in this example.
Locale and timezone answer different questions
Intl.DateTimeFormat supports locale-specific presentation with an explicit timezone. That lets the application represent the same instant differently according to the selected display context. The correct timezone still depends on the user's task. DateTimeFormat documentation
Keep a calendar-only date distinct from a timestamped instant. A birthday or reporting date may not mean midnight UTC. Converting every date through an instant can shift its displayed day when the product intended a date without timezone semantics. Specify the data model before choosing the formatter.
Currency display preserves a unit
Intl.NumberFormat can format numbers using a chosen currency style and locale. The caller still supplies the amount and currency meaning. Formatting twelve and a half as USD does not establish a corresponding amount in EUR or the accounting precision needed by a financial workflow. NumberFormat documentation
Keep storage, calculation and display rounding decisions explicit. A localized display string should not become the machine-readable source for later calculations. If input is locale-sensitive, use a defined parser and validation process; formatting APIs do not automatically provide the inverse parser.
Text direction is a structural concern
W3C guidance describes the dir attribute for base text direction and recommends setting the document direction for a predominantly right-to-left page. Mixed-direction inline content can need its own treatment. Direction is not solved by translating words while leaving every layout assumption unchanged. W3C direction guidance
Review navigation, tables, forms, icons with directional meaning, focus order and embedded identifiers in the actual browser. Mirror only what should mirror. A media-control symbol or technical identifier may have semantics that differ from the surrounding interface direction.
Best Practices
Maintain supported locale and fallback policies. Decide what happens when a translation key or category is missing and test that behavior. An interface that silently mixes languages may remain technically usable while confusing the user about an important action.
Use formatting and message APIs at the presentation boundary while preserving typed underlying data. Include locale and timezone in the relevant user or task context rather than depending on an accidental server default. Record runtime support when tests rely on installed locale data.
Test long strings, small screens, keyboard navigation and mixed-direction text with real language review. Pseudolocalization can expose layout limits, but it does not validate grammar or cultural meaning. Automated assertions and human review contribute different evidence.
Avoid exact-string tests that accidentally depend on one spacing or punctuation implementation unless that exact presentation is the contract. The example checks semantic format parts where appropriate. Review the displayed result separately when typography or accessibility matters.
Reverse a generic locale strategy when the data model or workflow requires a specific timezone, calendar or unit. A user's interface language does not automatically determine the currency of a transaction or the timezone of a scheduled operation. Let the actual task supply those meanings.
Common Mistakes
Appending an English plural suffix
Treating locale as time zone
Treating currency formatting as conversion
Declaring localization done after formatter tests
FAQ
Does Intl.PluralRules translate a sentence?
No. It selects a category for a locale. A message system and reviewed translations must supply the actual wording and placeholders.
Does formatting money convert its currency?
No. The amount's currency and any conversion policy must be handled explicitly. Formatting chooses presentation for the supplied value and unit.
How do I test right-to-left layouts?
Test in real browsers with an RTL locale and dir="rtl": check mirrored layout, mixed-direction text, icons that imply direction, and keyboard focus order. Formatter checks on a server can't show any of that, and native speakers should review the language itself.