Locale
A tag like en, en-GB, or pt-BR (region optional) that decides which words, date order, decimal mark, and sort order the app uses.
See it
What it is
A locale is the identifier that tells every formatting decision what 'correct' means here. The standard shape is a BCP 47 tag: language, optional script, optional region, like 'en', 'en-GB', 'pt-BR', or 'zh-Hant-TW'. The region half is optional, so a bare 'en' or 'de' is a perfectly good locale. Hand the tag to Intl or to your i18n library and it selects that locale's conventions (date order, decimal separator, plural categories, sort order) plus which catalog variant to load, because the underlying data comes from Unicode CLDR. It does not hand you translations or a currency: those you still supply.
Pick one on first load through language negotiation (the Accept-Language header, or the URL if you use locale routing), then let the user override it and store the choice. Keep it as one value that flows through the whole request, rather than reading the browser language in one component and a cookie in another.
Gotcha: locale is not country, not timezone, and not currency, however much they correlate. A Berlin user may want an English UI, German number formats, prices in EUR, and Europe/Berlin time, and those are four independent settings. Guessing locale from IP is the classic sin: it strands travellers and expats in a language they cannot read, with no visible switcher.
Ask AI for it
Add locale handling to this app. Represent the active locale as a single BCP 47 tag (for example 'en-US', 'de-DE', 'pt-BR') resolved once per request in this order: URL segment, saved user preference cookie, Accept-Language header, then a default. Pass it through context to every component, and use it for all Intl.DateTimeFormat, Intl.NumberFormat, and Intl.Collator calls. Never infer the locale from IP geolocation, keep timezone and currency as separate settings, and render a language switcher that lists each locale in its own language (Deutsch, not German).