If you are searching for how to translate BCP 47 language tags, how to handle ISO 639 language codes, how to translate ISO 15924 script codes, or how to preserve language, script and region identifiers such as en-GB, en-SG, zh-Hant, sr-Latn-RS or es-419, the first rule is that a locale tag is structured identity data. Translate the human-readable language name around it; do not translate the tag itself into target-language words or replace its subtags merely because the interface language changes.
This matters in website localization, mobile apps, APIs, translation-management systems, multilingual databases, HTML language metadata, subtitles, product catalogues, content negotiation, language selectors, file pipelines, translation memories and internationalized software. A translation can be linguistically excellent and still route users to the wrong content if a tag changes from one region or script to another, if separators are altered, or if a platform-specific locale ID is mistaken for a BCP 47 tag.
This guide explains how to translate around BCP 47 and related ISO codes without changing locale identity. It separates language, script, region, variant, extension and private-use subtags; explains why BCP 47 is not the same thing as “whatever locale string a platform accepts”; and provides a production workflow for preserving metadata while human-facing language changes.
1. A tag is a routing identifier, not just a label
In ordinary prose, English, Portuguese, Chinese, Serbian and Spanish are words that can be translated. In software, en, pt-BR, zh-Hant, sr-Latn-RS and es-419 are identifiers that may control resource loading, fallback, formatting, indexing and analytics. Their job is partly linguistic and partly computational.
Translation control: Keep the display name and machine value in separate fields. A French interface can display a French label for “English (United Kingdom)” while the underlying value remains en-GB. Quality assurance: Select the option in every supported interface language and confirm the same underlying resource loads.
2. BCP 47 is the language-tag framework
BCP 47 is the IETF Best Current Practice for language tags. RFC 5646 defines the syntax and registry model, while RFC 4647 covers language-range matching. It combines registered subtags into a hyphen-separated identifier rather than treating every locale-looking string as equivalent.
Translation control: Before changing a value, identify whether the field actually requires BCP 47 or a proprietary, legacy or platform-specific locale convention. Quality assurance: Reject undocumented normalization. A string such as en_US may be valid for a particular platform while not being BCP 47 syntax.
3. The language subtag comes first
A language tag normally starts with a language subtag associated through the IANA registry with identifiers such as en, fr, ja or sr. The code is not a translated abbreviation. It remains stable even when the visible name for that language is localized into dozens of interface languages.
Translation control: Translate “English,” “French” or “Japanese” as a label; preserve en, fr or ja as the machine value. Quality assurance: Compare supported language codes against the application configuration and the current IANA registry.
4. Script and language are different dimensions
A four-letter script subtag can identify a writing system using codes associated with ISO 15924. Latn, Cyrl, Hans and Hant describe scripts, not languages. This matters for languages that can be written in more than one script and for products that maintain script-specific resources.
Translation control: Do not translate Latn into a target-language abbreviation or replace Cyrl because the surrounding UI changes language. Quality assurance: Test that script-qualified resources such as sr-Latn and sr-Cyrl load different intended content where the product supports both.
5. Region is not nationality and not language ownership
A region subtag can use a two-letter ISO 3166-1 code or an appropriate three-digit UN M.49 code. en-GB, en-US and en-SG are all English tags with regional qualification. The region says something about the targeted content context; it does not define the identity of the user.
Translation control: Add or remove a region only because the content architecture requires it, not because a translator assumes where speakers belong. Quality assurance: Verify product requirements for each regional resource rather than inferring them from the target language alone.
6. Subtag order is structural
BCP 47 has an ordered grammar: language comes first, followed when applicable by script, region, variants, extensions and private use. Human language can reorder the description of those concepts, but the tag itself is not rewritten to mimic target-language syntax.
Translation control: Translate a label such as “Serbian, Latin script, Serbia” naturally while keeping sr-Latn-RS unchanged. Quality assurance: Run syntax validation rather than relying on visual plausibility.
7. Hyphens are part of BCP 47 syntax
BCP 47 uses hyphens between subtags. Underscore forms such as en_US appear in software ecosystems and legacy locale conventions, but an underscore string should not be casually corrected inside a system whose contract expects it. Schema migration and translation are separate operations.
Translation control: Preserve the source separator unless the project explicitly authorizes migration to a new locale syntax. Quality assurance: Integration tests should confirm that renamed locale resources are still found by the build and runtime.
8. Case is conventional, but production paths can be case-sensitive
BCP 47 matching is case-insensitive, while conventional casing improves readability: language is commonly lowercase, script title case and region uppercase, as in sr-Latn-RS. File systems, deployment pipelines or application lookup code can still behave case-sensitively around resource names.
Translation control: Do not rename files merely because a tag can be normalized theoretically. Quality assurance: Test actual runtime lookup after any canonicalization change.
9. zh-Hans and zh-Hant describe script distinctions
Chinese localization often uses Hans and Hant to distinguish Simplified and Traditional Han script environments. Region-qualified tags such as zh-CN, zh-SG, zh-HK and zh-TW encode a different dimension. Script and region can correlate operationally without being interchangeable.
Translation control: Do not mechanically rewrite zh-Hans as zh-CN or zh-Hant as zh-TW unless the product architecture explicitly defines that mapping. Quality assurance: Inspect the supported-locale matrix rather than guessing from common market practice.
10. pt-BR and pt-PT should not be collapsed casually
Brazilian Portuguese and Portugal-targeted Portuguese resources can differ in vocabulary, spelling, tone, formatting and regulatory wording. A system that deliberately carries both pt-BR and pt-PT is expressing a product distinction, even though both are Portuguese.
Translation control: Do not merge them to pt simply to increase translation-memory reuse or simplify a selector. Quality assurance: Review resource ownership, terminology and fallback before any consolidation.
11. es-419 demonstrates numeric region subtags
BCP 47 can use numeric region subtags based on UN M.49. es-419 is widely used for Spanish content targeted broadly at Latin America and the Caribbean. It does not identify one country and should not be expanded into a country code during translation.
Translation control: Localize the human label for the region while preserving es-419 as the routing value. Quality assurance: Confirm analytics, search and resource loading all treat the numeric region as expected.
12. Variants are registered distinctions, not free-form adjectives
Variant subtags can encode recognized linguistic or orthographic distinctions. They are not an invitation to append arbitrary English words such as formal, school, easy or marketing. Product-specific content profiles belong in application metadata unless a registered variant legitimately applies.
Translation control: Check the IANA registry before introducing a variant subtag. Quality assurance: Reject invented tags that merely look structurally plausible.
13. Extensions carry additional structured information
BCP 47 permits extension sequences introduced by singleton subtags. The Unicode locale extension under u can express certain locale-related preferences in ecosystems that support it. Extension characters are data, not prose and should not be translated or reordered by a language tool.
Translation control: Lock extension-bearing tags from machine translation and editing unless localization engineering explicitly owns the change. Quality assurance: Validate both syntax and platform support because a syntactically possible extension may still be unsupported by the product.
14. Private use is local by design
The x singleton introduces private-use material. A private-use tag can solve an internal routing problem, but its semantics are not globally interoperable. Another organization is not expected to know what an internal suffix such as x-training or x-client42 means.
Translation control: Document private-use conventions in the project specification and never infer their meaning from the token spelling alone. Quality assurance: Test that external integrations do not incorrectly treat private tags as public standards.
15. The IANA registry is the operational source of truth
BCP 47 draws on standards including ISO 639, ISO 15924 and ISO 3166, but the IANA Language Subtag Registry records the subtags used by BCP 47 together with deprecations, preferred values, prefixes and other metadata. An old spreadsheet can therefore be syntactically neat and still be out of date.
Translation control: Verify registry questions against the current IANA data, not a copied list from a previous project. Quality assurance: Record the validation date when locale metadata is release-critical.
16. Deprecated values require controlled migration
A subtag can be deprecated and may have a preferred value. Replacing it can affect URLs, caches, stored preferences, translation memories, external integrations and analytics. A migration can be desirable without being a routine translator correction.
Translation control: Flag deprecated values and route changes through localization engineering or product ownership. Quality assurance: Preserve historical tags in archival translations when faithful reproduction is the purpose.
17. Grandfathered tags need registry-aware tools
Some historical language tags predate the current generative syntax and are grandfathered. Simple code that assumes every valid tag can be rebuilt from language, script and region pieces may mishandle them. Translators should not normalize unfamiliar historical tags by intuition.
Translation control: Use standards-aware validation libraries or registry lookup for edge cases. Quality assurance: Maintain exception tests so rare but valid tags are not rejected during import.
18. Locale is broader than language
Software locales can influence dates, numbers, currency, collation, calendars, measurement conventions and other behavior in addition to language. A BCP 47 tag can participate in that selection, but full locale behavior depends on the runtime and locale-data system.
Translation control: Do not assume changing en-US to en-GB changes only spelling. Coordinate locale changes with internationalization engineering. Quality assurance: Regression-test formats, sorting and input behavior as well as translated strings.
19. Language identity is not translation direction
A tag identifies content or a linguistic environment. It does not mean translate from this language to that language. Translation jobs need separate source and target metadata, often with their own tags. Ad hoc strings such as en-fr can be ambiguous outside a documented pair schema.
Translation control: Keep sourceLocale, targetLocale and languagePair concepts distinct in data models. Quality assurance: QA should detect when one field accidentally contains two unrelated locale values.
20. Tags should not be used as proxies for personal identity
A person can choose a language that differs from citizenship, residence, ancestry or device region. Language preference is a content and product setting, not reliable evidence of ethnicity or nationality. Technical systems become both less respectful and less accurate when they conflate these concepts.
Translation control: Route content from explicit preferences or documented product rules rather than demographic assumptions. Quality assurance: Test multilingual users who change language without changing region.
21. Do not infer region just because a language spans many places
A bare tag such as fr, en, es or ar can be appropriate when content is intentionally region-neutral. Adding a country code makes the identifier more specific but not automatically more correct. False precision can split resources without a real content distinction.
Translation control: Add a region only when regional targeting changes content or product behavior. Quality assurance: Review whether each region-specific resource has a documented reason to exist.
22. Do not infer script merely to make a tag look complete
Some languages use multiple scripts; others have a dominant script that need not be repeated in ordinary tags. Registry metadata such as suppress-script helps standards-aware tooling reason about customary usage. Extra subtags should carry information, not decoration.
Translation control: Follow the supported-locale specification instead of maximizing tag length. Quality assurance: Flag unnecessary script additions that create duplicate resources.
23. Fallback is an application policy
A product might fall back from fr-CA to fr, or from sr-Latn-RS to sr-Latn, but the exact chain belongs to the application. BCP 47 identifies language resources; it does not automatically define every product’s missing-translation behavior.
Translation control: Document fallback explicitly and keep it separate from the list of supported locales. Quality assurance: Simulate missing keys and verify actual runtime behavior.
24. Default locale and fallback locale are not necessarily the same
The default locale may be the experience chosen for a new user, whereas a fallback locale may fill gaps when a resource key is absent. Confusing the two can hide incomplete translations or expose unexpected language content.
Translation control: Store and document default and fallback settings separately. Quality assurance: Release QA should identify fallback text rather than mistaking it for intentionally untranslated content.
25. HTML language metadata uses identifiers, not display phrases
Web content can use language metadata so browsers, assistive technologies and other software understand the language of a page or passage. The machine value should be an appropriate language tag, not a human phrase such as English Singapore.
Translation control: Let selectors display localized names while metadata preserves values such as en-SG. Quality assurance: Inspect rendered HTML and accessibility output, not only visible page copy.
26. Selectors need stable values and localized labels
A language menu may display English, anglais, 英語 or Inglés depending on the interface. If the translated label itself is used as the database key, switching UI language can break preference persistence. Stable machine values avoid that coupling.
Translation control: Use the tag as the stored value and localize only the visible name. Quality assurance: Change the interface language and verify the saved preference remains identical.
27. Locale-bearing filenames can be build contracts
Files named messages.en-GB.json or strings.fr-FR.xlf may be discovered automatically by build tooling. Renaming the locale token during translation can cause the resource to disappear from a release or load under the wrong language.
Translation control: Treat locale segments in paths and filenames as protected code. Quality assurance: Run the build and confirm every supported bundle is present after translation import.
28. Translation memory locale metadata must stay exact
Translation memories often distinguish regional or script variants. Collapsing en-GB into en-US or zh-Hant into zh-Hans can produce superficially fluent but inappropriate reuse. The target text may differ in terminology, orthography or regulatory context.
Translation control: Configure sharing rules deliberately rather than rewriting locale IDs to increase match rates. Quality assurance: Audit matches crossing locale boundaries and measure whether they are genuinely safe.
29. XLIFF and interchange formats contain structural language metadata
XLIFF, TMX and related localization formats can carry source and target language identifiers in attributes or metadata. Editing those files as plain prose risks translating or corrupting the identifiers as well as the XML structure.
Translation control: Use localization tools that protect markup and structural attributes. Quality assurance: Validate the exported file and re-open it in the consuming platform before release.
30. APIs should separate locale codes from display names
An API can return a stable languageTag such as en-SG and a displayName that each client localizes. This avoids making translated labels part of the identity contract and allows many interfaces to share one backend resource model.
Translation control: Keep keys and enum values language-neutral; translate presentation strings at the UI layer. Quality assurance: Contract tests should compare machine values across interface languages.
31. Databases need controlled locale fields
A free-text field invites English, ENG, en_US, EN-us and en-Singapore to coexist. A constrained schema can validate supported identifiers and map legacy aliases deliberately. Silent heuristic cleanup often creates more ambiguity than it removes.
Translation control: Use an enum or validated canonical field plus a separate display-name table where appropriate. Quality assurance: Reject unknown values during import and resolve them explicitly.
32. Analytics can fragment when tags drift
If one release logs en-us, another en-US and another en_US, analytics may split one audience into several categories even when the intended locale is identical. Canonicalization can solve this, but it should be centralized rather than performed by translators ad hoc.
Translation control: Define one analytics representation and map incoming aliases before reporting. Quality assurance: Check dashboards for duplicate locale categories after migrations.
33. Search systems may depend on accurate language metadata
Multilingual search can use language metadata to choose tokenization, stemming, analyzers or ranking behavior. A page can read perfectly to a human yet perform poorly in search if the metadata says the wrong language or script.
Translation control: Treat locale metadata as part of retrieval QA, not as invisible implementation detail. Quality assurance: Index test pages and confirm they enter the intended language pipeline.
34. Audio, subtitle and caption tracks also need stable language metadata
Media players can label and select audio or subtitle tracks using language identifiers. The visible track title can be localized independently. Guessing a region from an accent or speaker identity can misrepresent the production’s intended language version.
Translation control: Use production metadata as the authority for track language and regional targeting. Quality assurance: Switch player UI languages and confirm track identity remains stable.
35. Script tags do not replace font and character testing
A script-qualified locale can guide resource selection, but real content may contain brand names, quotations, symbols, digits and characters from more than one script. Font fallback must support the text actually present rather than assuming every character matches the tag.
Translation control: Do not strip, transliterate or normalize characters merely to make them resemble the dominant script. Quality assurance: Run glyph-coverage and rendering tests on representative content.
36. Transliteration is not the same operation as editing a tag
Changing Serbian text from Cyrillic to Latin can justify a script-specific resource, but changing sr-Cyrl to sr-Latn without changing the content simply mislabels the file. Metadata should describe the resource, not wish it into another form.
Translation control: Coordinate transliteration output and locale metadata updates in one controlled workflow. Quality assurance: Compare representative text with the declared script before publishing.
37. Machine translation should never own locale tags
Translation engines often leave strings such as en-GB alone, but they can change punctuation, case or hyphens, especially inside prose or configuration comments. Locale values should be masked or locked whenever they pass through a language model.
Translation control: Restore tags from the source-controlled data layer after translation. Quality assurance: Compare source and target tag sets automatically and flag any addition, removal or mutation.
38. Generative AI can suggest, but not invent, the supported-locale architecture
A model can explain likely tags from language names, yet edge cases involving deprecations, scripts, private use and application support require registry and product validation. A syntactically plausible tag may still have no resource bundle in the product.
Translation control: Use AI for explanation and review support, not as the source of truth for production locale lists. Quality assurance: Diff suggested tags against the owned configuration before accepting anything.
39. Screenshots do not prove backend locale identity
A screenshot saying English (UK) reveals the visible label but not necessarily the stored code. The application might use en-GB, a numeric enum or a proprietary locale ID. OCR therefore cannot establish machine identity by itself.
Translation control: Retrieve configuration, API output or source code when the identifier matters. Quality assurance: Distinguish evidence about presentation from evidence about backend state.
40. Right-to-left layout is related to, but separate from, locale identity
Arabic and Hebrew products often use right-to-left layout, yet direction handling also depends on mixed scripts, embedded numbers and components. A broken bidi implementation should not be fixed by changing the language tag.
Translation control: Keep directionality settings and language metadata as separate tested concerns. Quality assurance: Verify cursor behavior, selection, number ordering and mixed-language content in the final UI.
41. Browser language preferences are not a command to overwrite user choice
Browsers can send language preferences that applications use for negotiation. Those preferences may contain ordered language ranges and quality values rather than one definitive locale identity. A returning user may also have an explicit product-language preference that should take precedence according to product policy.
Translation control: Treat browser negotiation as one input to routing, not as permission to rewrite stored locale metadata during translation. Quality assurance: Test first visit, signed-in preference, changed browser settings and unsupported languages separately.
42. Content negotiation needs a documented supported set
A server may receive a broad request such as fr-CA while the product supports only fr. Another product may maintain a dedicated fr-CA resource. The correct response depends on the supported-locale set and matching policy, not on a translator’s intuition about linguistic similarity.
Translation control: Document matching and fallback rules alongside the locale inventory. Quality assurance: Use automated request tests to show which resource is selected for representative language ranges.
43. Canonicalization must preserve intended distinctions
Standards-aware libraries may canonicalize casing or replace certain deprecated forms, but canonicalization should not erase a meaningful script, region or variant. Two strings that look similar can represent deliberately separate content resources in a product.
Translation control: Run canonicalization centrally and review every many-to-one mapping before migrating production data. Quality assurance: Compare resource counts, user preferences and analytics categories before and after the change.
44. SEO language-region metadata is not a substitute for content localization
Sites can expose language and regional targeting metadata to search systems, but correct tags cannot rescue a page whose visible content belongs to the wrong language or market. Conversely, excellent localized copy can be misrouted if metadata points at the wrong version.
Translation control: Keep content ownership and language-region metadata synchronized from the same locale matrix. Quality assurance: Crawl representative pages and compare visible language, canonical URL relationships and declared locale metadata.
45. Unicode normalization and BCP 47 normalization solve different problems
Unicode normalization concerns character sequences in text. BCP 47 canonicalization concerns language-tag representation and registry relationships. They should not be conflated merely because both are called normalization in engineering discussions.
Translation control: Apply text normalization to content only under its own specification and locale-tag canonicalization to metadata under another. Quality assurance: Log which normalization process changed which field so debugging remains possible.
46. Locale IDs in third-party systems require explicit crosswalks
A vendor, operating system, database or translation platform can expose identifiers that resemble BCP 47 while using its own accepted aliases or legacy forms. A crosswalk should map those values deliberately rather than assuming string equality across every system.
Translation control: Store the external value and canonical internal value separately when round-trip fidelity matters. Quality assurance: Round-trip a sample through every connected system and confirm no locale collapses into another unexpectedly.
47. English for Singapore: a worked example
A product supports en-SG as a Singapore-targeted English resource. A Japanese interface can display the selector option using a Japanese translation of English (Singapore), but the stored preference remains en-SG and the same resource bundle loads.
Translation control: The label changes with the menu language; the routing key does not. Quality assurance: Inspect the saved preference and resource requests while switching interface languages.
48. Serbian scripts: a worked example
A publisher maintains sr-Cyrl and sr-Latn editions. Both are Serbian but the scripts differ. English documentation can describe them as Serbian in Cyrillic and Serbian in Latin, while another target language uses different human labels. The tags remain stable.
Translation control: Update the script tag only when the resource itself is the corresponding script version. Quality assurance: Check representative strings for script consistency and verify separate bundles.
49. Chinese script and region: a worked example
A platform maintains zh-Hans, zh-Hant-HK and zh-Hant-TW. Flattening them all to Chinese at the data layer would erase intentional distinctions, even though a high-level menu category may group them for usability.
Translation control: Keep grouping logic in the UI while preserving full identifiers in resource metadata. Quality assurance: Test both script rendering and region-specific content differences.
50. Legacy underscore migration: a worked example
An older system stores pt_BR while a new API requires pt-BR. The team maps all supported legacy IDs, updates file names, integrations, caches and tests, and deploys the migration deliberately. Translators do not perform partial substitutions inside random content files.
Translation control: Treat separator conversion as an engineering change with versioned mappings. Quality assurance: Run compatibility tests for stored user preferences and external API clients.
51. Private use: a worked example
A company uses en-x-legaltraining for an internal corpus. Because x marks private use, the team documents the meaning and prevents external partners from assuming it is a globally standardized variety of legal English.
Translation control: Keep private semantics in project documentation and avoid exporting them as universal taxonomy. Quality assurance: Verify that external systems either preserve the string or map it through an agreed interface.
52. Vocabulary and grammar around tags still matter
Language, locale, dialect, script, region, variant, translation, transliteration, localization and internationalization are often blurred in ordinary discussion. Precise definitions help teams decide whether they are changing content, metadata, writing system, regional targeting or software behavior.
Translation control: Use the Vocabulary Learning Hub and How English Works ecosystem for the language layer while preserving this page’s narrower locale-identity scope. Quality assurance: Review terminology in specifications before developers and linguists implement different meanings for the same word.
53. Use RFC 5646 for syntax and registry rules
RFC 5646 is the core reference for BCP 47 language-tag syntax and the Language Subtag Registry model. It is more reliable than informal lists of country-language codes because it explains how the pieces combine and how registry metadata participates in validity and maintenance.
Translation control: Use the RFC 5646 reference and standards-aware tooling. Quality assurance: Recheck assumptions when a locale edge case falls outside the simple language-region pattern.
54. Use the current IANA Language Subtag Registry
The registry provides the operational inventory of BCP 47 subtags and metadata, including descriptions, deprecations, preferred values and prefixes. It should be consulted when a team encounters an unfamiliar tag or plans a canonicalization change.
Translation control: Use the IANA Language Subtag Registry instead of an undated copied table. Quality assurance: Record the source and review date for release-critical locale mappings.
55. Connect to the master architecture without creating a new hub
This specialist article belongs beneath eduKateSG’s Master Art of Translation — Technical Translation System. The master owns specifications, terminology, standards, QA and change control; this page owns the narrower question of preserving locale identifiers while language changes.
Translation control: Link upward for system-level practice rather than repeating the master architecture here. Quality assurance: Keep search intent specific to language tags, locale codes and multilingual routing.
56. Release checklist
Before release, identify the schema for every locale-like field; preserve BCP 47 tags and platform IDs exactly unless a migration is explicitly authorized; distinguish language, script and region; keep display names separate from machine values; validate registered subtags; review deprecated, grandfathered and private-use values; test routing, content negotiation, fallback, filenames, HTML metadata, APIs, translation memories and interchange files; and compare source-target tag sets automatically.
Then review the visible labels for clarity, natural target-language wording and consistency. Linguistic QA and locale-metadata QA are separate passes because a product can pass one while failing the other.
57. Final rule: translate the label, preserve the locale identity
A multilingual product works when people can read natural language while software can still tell exactly which language, script and regional resource it is handling. BCP 47 and related standards give the machine layer stable identifiers. Good localization translates the prose around those identifiers, validates them against the correct authority and tests that every resource still reaches the users and systems it was designed to serve.