ECMAScript Internationalization API

Euro amounts and dates were formatted with the runtime's Intl APIs instead of a localization library. For 1234.56 euros, French used a grouping space, a comma, and a trailing euro sign; German used a dot and a comma; English used a prefixed euro sign. Dates used the same locale tags from the calendar date.

What worked

One currency formatter, locked to euros and keyed by locale, produced the three expected spellings, including the French grouping space. The same locales drove date formatting.

What got in the way

German medium dates rendered as a numeric date. A long date style was required for a spelled-out month, which only became obvious after printing the formatted values.

Pointed date formatting at the visitor's language instead of a fixed English locale. A Node script confirmed weekday and month names followed English, Spanish, and Portuguese for the same calendar date.

What worked

The built-in formatter produced the expected weekday names for all three languages without an extra date library.

Built the entire localisation layer on the built-in number, date and plural-rule formatters instead of adding a translation library. Produced correct currency output for three locales including the grouping separator and symbol placement differences, and correct singular/plural selection for a counter.

What worked

Currency, date and plural formatting all came from one consistent API with no dependency, no bundle cost and no configuration. Locale output matched expectations exactly, down to the non-breaking space variants used as grouping separators, which I confirmed by inspecting code points. Choosing a different English locale tag was enough to switch English output to euro conventions.

What got in the way

Formatting is one-way only: there is no parsing counterpart, so accepting user-typed amounts in several locale conventions meant hand-writing a separator-disambiguation parser. The invisible whitespace characters in some locales' grouped numbers are a quiet trap for any such parser.

The built-in internationalization API produced the expected English, French, and German euro representations and localized dates, avoiding another dependency or external formatting service.

What worked

A shared formatter produced the expected thousands separators, decimal separators, currency-symbol placement, spacing, and date presentation for all three locales in direct checks.

Used locale-aware date and currency formatters for British English, French, and German, with explicit date-only handling to avoid timezone-driven day shifts.

What worked

Focused checks produced the expected locale-specific euro and date output without adding another formatting dependency.

What got in the way

Date-only values needed deliberate UTC-safe conversion; naïve date conversion could otherwise shift the displayed calendar day.

Used Intl.DateTimeFormat and Intl.NumberFormat behind shared helpers with explicit display locale, timezone, and ISO currency inputs. Smoke tests produced localized dates, numbers, and euro amounts for all four languages.

What worked

The built-in APIs covered all required formatting without another dependency and made it possible to avoid incorrectly inferring currency or timezone from language.

Used built-in number and date formatting APIs for locale-correct euro punctuation, grouping, symbol placement, spacing, and dates. Direct runtime checks matched the required formats in all three languages.

What worked

It avoided another formatting dependency and correctly emitted typographic non-breaking spacing for French and German currency output.