Locale Konvertierener Guide
Learn how to convert locale identifiers between BCP 47 tags, POSIX locale strings, ICU-style locale values, and Accept-Language headers. Includes practical examples for HTML, JavaScript Intl, APIs, and server environments.
BCP 47 vs POSIX Locale Strings
Web platforms usually expect BCP 47 locale tags like en-US, fr-CA, or zh-Hans-CN. POSIX locale strings such as en_US.UTF-8 are still common on servers, shells, and older backend workflows. A locale converter bridges these formats so your browser, templates, and infrastructure all receive the representation they expect.
Where Accept-Language Fits
Accept-Language headers describe user language preferences, often with multiple values and quality weights. They are not always the exact locale you should store or display. In practice, you usually extract the primary requested locale, canonicalize it, and then map it to your supported locale list.
Common Locale Conversion Rules
- Replace underscores with dashes when moving from POSIX to browser-facing locale tags.
- Keep script subtags when they change rendering behavior, such as zh-Hans versus zh-Hant.
- Remove encoding suffixes like .UTF-8 for HTML and Intl usage, but keep them for server locale environment variables if needed.
- Treat modifiers like @latin as script hints that often map to subtags such as -Latn.
Practical Output Targets
- HTML: use canonical BCP 47 values in the lang attribute.
- JavaScript Intl: use canonical locale tags when calling Intl.Locale, Intl.NumberFormat, or Intl.DateTimeFormat.
- Backend and shell environments: keep POSIX-compatible values only where the runtime expects them.
- HTTP negotiation: keep the full Accept-Language header for request handling, but normalize individual locales for storage and analytics.
Real Locale Conversion Beispiele
en_US.UTF-8
Target
en-US
Konvertieren POSIX locale strings into BCP 47 tags before using them in HTML or JavaScript Intl APIs.
zh_Hans_CN
Target
zh-Hans-CN
Preserve the script subtag when you need explicit Simplified Chinese formatting behavior.
Accept-Language: fr-CA,fr;q=0.9,en;q=0.8
Target
fr-CA
Use the first requested locale as the primary preference, then apply your own supported-locale fallback rules.
Example: Mapping Locale Input for Browser and Server Use
$raw = 'en_US.UTF-8';
$browserLocale = str_replace('_', '-', preg_replace('/\..*$/', '', $raw));
$htmlLang = $browserLocale; // en-US
$serverLocale = $raw; // en_US.UTF-8
$header = 'Accept-Language: fr-CA,fr;q=0.9,en;q=0.8';
$primaryLocale = preg_replace('/^Accept-Language:\s*/i', '', $header);
$primaryLocale = trim(explode(',', $primaryLocale)[0]);
// fr-CAHäufig gestellte Fragen
Use BCP 47 tags like en-US or zh-Hans-CN in HTML lang attributes, JavaScript Intl APIs, browser settings, and most modern localization frameworks.
Use POSIX locale strings like en_US.UTF-8 in Linux environments, shell configuration, server processes, and some backend libraries that expect underscore-separated locale identifiers plus an encoding suffix.
An Accept-Language header can contain multiple requested locales with quality scores. In many cases you first extract the primary requested locale, then map it to your supported locale list or a canonical BCP 47 tag.
Some languages require an explicit script subtag to avoid ambiguity. For example, zh-Hans-CN and zh-Hant-TW point to different written forms, and sr-Latn-RS differs from sr-Cyrl-RS.
Test Locale Conversion With Live Intl Output
Use the interactive locale converter to inspect canonical output, fallback chains, and browser-resolved locales before you wire a locale into production templates or localization code.