What is Locale?

Anatomy of a language tag

Web standards express locales as BCP 47 language tags, defined in RFC 5646. A tag is made of hyphen-separated subtags: the language first, an optional script, then the region.

By convention the language is lowercase, the script is title case (ISO 15924) and the region uppercase (ISO 3166-1); the standard itself treats tags as case-insensitive. The separator is always a hyphen. The en_US.UTF-8 form you see in operating systems and some server languages is POSIX notation; in HTML, HTTP and JavaScript the equivalent is en-US.

Same data, different locale

Formatting is where a locale shows most. The built-in Intl API in JavaScript hands these rules to the browser or Node.js:

new Intl.NumberFormat("en-US").format(1234567.5);   // "1,234,567.5"
new Intl.NumberFormat("tr-TR").format(1234567.5);   // "1.234.567,5"

new Intl.NumberFormat("en-US", { style: "currency", currency: "USD" })
  .format(1499.9);                                  // "$1,499.90"

const d = new Date("2026-10-03T12:00:00Z");
new Intl.DateTimeFormat("en-US", { dateStyle: "long" }).format(d);  // "October 3, 2026"
new Intl.DateTimeFormat("en-US", { dateStyle: "short" }).format(d); // "10/3/26"
new Intl.DateTimeFormat("en-GB", { dateStyle: "short" }).format(d); // "03/10/2026"

The same short date reads as 3 October in London and 10 March to anyone who assumes US order, which is why dates in interfaces should never be formatted by hand. Turkish adds the classic case-mapping trap: "istanbul".toUpperCase() gives "ISTANBUL", while "istanbul".toLocaleUpperCase("tr-TR") correctly returns "İSTANBUL". Sorting differs too: default string sorting pushes "ç" and "ı" to the end, whereas Intl.Collator("tr") follows the Turkish alphabet. The working rule: use locale-aware functions for text people read, and locale-independent conversions for technical identifiers such as URL slugs and database keys.

How the browser states a preference

Browsers send an Accept-Language HTTP header with every request, listing languages in order of preference with optional weights (q):

Accept-Language: en-US,en;q=0.9,tr-TR;q=0.8,tr;q=0.7

It is a hint, not a decision. MDN stresses that servers should never override an explicit user choice with it and should offer a language selector; for privacy reasons some browsers send only a single language. If the user's choice lives only in a cookie, it is lost on shared links and for bots, so carrying the locale in the URL is more robust. A locale is also not a time zone or a currency: someone living in Berlin may want en-US formatting while seeing times in Europe/Berlin and prices in euros.

Locales and SEO: the link to hreflang

Hreflang values are a narrowed subset of BCP 47. Google accepts an ISO 639-1 language code, an optional ISO 3166-1 Alpha 2 region code and, where needed, an ISO 15924 script code. A country code on its own is invalid, and en-UK is a common mistake for en-GB. Numeric regions such as es-419 are valid BCP 47 but fall outside the format Google defines for hreflang. The <html lang="en"> attribute takes a BCP 47 tag as well and matters for screen readers pronouncing text correctly, yet Google determines a page's language with its own algorithms rather than from lang or hreflang.

A single URL that changes content by locale, a so-called locale-adaptive page, is risky for search. Google says Googlebot sends requests without an Accept-Language header and that its default IP addresses appear to be based in the USA, so it may only ever see one version. Google's recommendation is a separate URL per locale, connected with hreflang annotations, a choice that shapes the whole international SEO setup. Details are in Google's documentation on locale-adaptive pages.