Locale Configuration

Origin & evolution

Locale configuration is a software convention rather than a named theory, but it has a clear lineage. The Unicode Common Locale Data Repository (CLDR) is the de facto source of this data: it ships the formatting rules, calendar conventions, and pluralisation tables that platforms read at runtime. Browser and runtime APIs such as Intl lean directly on CLDR, which is why a date renders one way for en-GB and another for en-US without any application code changing.

The thinking matured as teams learned that a locale tag alone underspecifies behaviour. en-GB tells you the language and region; it does not tell you whether prices show in pounds, whether the week starts on Monday, or which locale to fall back to when a key is untranslated. Modern internationalisation practice separates these concerns: the locale is an identifier, and the config is the resolved bundle of settings keyed to it. The fallback chain is the part teams most often get wrong, because a naive default to English erases a careful regional setup the moment one string is missing.

How it works in practice

A SaaS product launches in Quebec. It already supports fr-FR, so the team assumes fr-CA is cheap. The locale config says otherwise. Quebec uses the same French language but a different currency (CAD, not EUR), a different date order in some contexts, and a fallback chain that must read fr-FR before en so that an untranslated string lands in French before it lands in English. The team encodes one locale config: currency CAD, decimal comma, week starting Sunday, RTL off, fallback fr-CA → fr-FR → en. When a new feature⭐FeatureProduct SpecificationA product capability or featureView reference → ships three untranslated strings, users see French placeholder copy, not English, because the chain caught them. The locale itself never changed; the config did the work.

Locale config vs. its neighbours

• Locale is the identifier (fr-CA, ar-EG); the locale config is the resolved settings that identifier maps to. One is the key, the other is the value.
• Translation bundle🈂️Translation BundleLocalisationA bundle of translation keysView reference → holds the actual strings for a locale; the locale config holds the rules for formatting and fallback around those strings. A bundle answers "what does this say in French?"; the config answers "how is the date written and what happens when the string is absent?".
• Regional pricing💴Regional PricingLocalisationLocation-based pricingView reference → sets what a market pays; the locale config sets how that price is displayed (currency symbol, separator, position). Pricing is a commercial decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →; display is a formatting one, and conflating them produces correct prices shown in the wrong currency glyph.

In the graph

In the Unified Product Graph, a locale config sits in the localisation region as the settings layer beneath a locale🌎LocaleLocalisationA supported locale (language + region)View reference →. A product🧬ProductStrategyThe product being created, the root of the graphView reference → connects to its configs through product_configured_via_locale_configProductconfigured viaLocale Confighierarchy, and each locale🌎LocaleLocalisationA supported locale (language + region)View reference → ties to its bundle through locale_configured_via_locale_configLocaleconfigured viaLocale Confighierarchy. Modelling the config as its own node keeps the locale identifier clean and makes the settings queryable: a team can ask which locales lack a fallback chain, or which still default to English, without parsing the formatting rules out of the locale itself. Neighbours such as translation_bundle🈂️Translation BundleLocalisationA bundle of translation keysView reference → and regional_pricing💴Regional PricingLocalisationLocation-based pricingView reference → then attach where they belong, so display, content, and commercial concerns stay distinct.