# General Translation Knowledge Base: Что такое коды локалей, например en-US и en-GB? URL: https://generaltranslation.com/ru/kb/locale-codes.mdx Docs index: https://generaltranslation.com/llms.txt Description: Код локали обозначает язык, а при необходимости — его письменность и регион, например en-US для английского языка в США или zh-Hant-TW для традиционного китайского на Тайване. Большинство программ используют теги BCP 47, составленные из кодов ISO. General Translation использует коды BCP 47 для исходной и целевых локалей в gt.config.json. Category: Форматирование с учётом локали Last updated: 2026-10-28 Authors: General Translation Team Published: 2026-10-28 Код локали обозначает язык, а при необходимости — письменность, на которой он записывается, и регион, где он используется. `en-US` — это английский язык в США, `en-GB` — английский язык в Великобритании, а `zh-Hant-TW` — китайский язык в традиционной иероглифической записи, принятый на Тайване. Браузеры, HTTP, HTML и API `Intl` в JavaScript используют для этих кодов единый стандарт — BCP 47, поэтому именно от выбранного кода зависит, какой перевод, формат даты и правила множественного числа увидит пользователь. ## Как устроен тег BCP 47 [BCP 47](https://www.rfc-editor.org/info/bcp47) — стандарт IETF для языковых тегов. Он объединяет [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646.html), где определён синтаксис, и [RFC 4647](https://www.rfc-editor.org/rfc/rfc4647.html), где описано сопоставление тегов. Тег — это последовательность подтегов, разделённых дефисами и всегда идущих в следующем порядке: | Подтег | Формат | Источник | Примеры | | --------------------- | --------------------------------------------- | ------------------------------------------ | -------------------------------------------- | | Язык (обязательно) | 2 или 3 буквы | ISO 639, самый короткий из доступных кодов | `en`, `zh`, `gsw` | | Письменность | 4 буквы | ISO 15924 | `Hant`, `Hans`, `Latn`, `Cyrl` | | Регион | 2 буквы или 3 цифры | ISO 3166-1 alpha-2 или UN M.49 | `GB`, `BR`, `419` | | Вариант | От 5 до 8 символов либо цифра и ещё 3 символа | Регистрируется в IANA | `de-1901` (традиционная немецкая орфография) | | Расширение | Одна буква, затем её подтеги | `u` определено Unicode | `ar-EG-u-nu-latn` | | Частное использование | `x`, затем ваши собственные подтеги | Вы | `en-CA-x-ca` | Все допустимые подтеги перечислены в [реестре языковых подтегов IANA](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) — это единственный источник, по которому стоит сверять коды. В редакции за сентябрь 2026 года в нём 8 276 языковых подтегов и 305 подтегов регионов, а для устаревших кодов указаны коды, которые их заменяют. Сочетая эти части, можно точно выразить нужное значение. `sr-Latn-RS` — сербский язык на латинице в том виде, в каком он используется в Сербии. `es-419` — испанский язык Латинской Америки и Карибского бассейна, где `419` — код UN M.49 для региона из нескольких стран. В RFC 5646 приводится более тонкий пример: `de-CH` — немецкий язык в том виде, в каком он используется в Швейцарии (швейцарский литературный немецкий), тогда как швейцарский немецкий (Schweizerdeutsch) — отдельный язык со своим кодом `gsw-CH`. ### Расширения меняют форматирование, а не язык Расширение `-u-` определено в [RFC 6067](https://www.rfc-editor.org/rfc/rfc6067.html), а его ключи перечислены в [спецификации Unicode LDML](https://unicode.org/reports/tr35/). Оно передаёт настройки форматирования: `-u-nu-` задаёт систему счисления, `-u-hc-` — 12- или 24-часовой формат времени, `-u-ca-` — календарь, а `-u-co-` — порядок сортировки. `en-US-u-hc-h23` по-прежнему обозначает американский английский — просто время отображается как `14:05` вместо `2:05 PM`. Оба варианта показаны в примере ниже. ## Регистр, дефисы и подчёркивания Теги не чувствительны к регистру, поэтому `EN-gb` и `en-GB` означают одно и то же. Тем не менее RFC 5646 [рекомендует соглашение](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1.1): язык — строчными буквами, письменность — с заглавной буквы, регион — прописными, как в `zh-Hant-TW`. Приводите код к этой форме, прежде чем использовать его в имени файла или URL, чтобы `/en-gb/` и `/en-GB/` не превратились в два разных пути. В BCP 47 подтеги разделяются дефисами. Ряд платформ использует собственные форматы, поэтому выполняйте преобразование на границе систем: | Система | Формат | Пример | | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ---------------------------------- | | Веб (HTML `lang`, `hreflang`, `Accept-Language`, `Intl`) | BCP 47 с дефисами | `en-US`, `zh-Hant-TW` | | [POSIX](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html) (`LANG`, `LC_*`) | `language[_territory][.codeset][@modifier]` | `en_US.UTF-8` | | [Unicode CLDR](https://unicode.org/reports/tr35/) и идентификаторы локалей ICU | Подчёркивания; дефисы тоже допускаются | `en_US` | | [Java](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Locale.html) | `toString()` возвращает форму с подчёркиванием, `toLanguageTag()` — BCP 47 | `en_US`, `en-US` | | [Ресурсы Android](https://developer.android.com/guide/topics/resources/providing-resources) | `r` перед регионом или `b+` для тегов BCP 47 (Android 7.0 и новее) | `values-en-rUS`, `values-b+es+419` | JavaScript не принимает форму с подчёркиванием: `Intl.getCanonicalLocales('en_US')` выбрасывает исключение `RangeError`. ## Распространённые ошибки * **`en-UK` вместо `en-GB`.** Код региона ISO для Великобритании — `GB`, а `UK` в реестре IANA нет. Unicode CLDR считает `UK` алиасом, поэтому JavaScript молча превращает `en-UK` в `en-GB`, но [Google игнорирует](https://developers.google.com/search/docs/specialty/international/localized-versions) `UK` в hreflang. Пишите `en-GB`. * **Код страны на месте кода языка.** `jp`, `cn`, `gr`, `dk` и `cz` — это не коды языков: японский — `ja`, китайский — `zh`, греческий — `el`, датский — `da`, чешский — `cs`. Некоторые коды стран и вовсе обозначают другие языки: `se` — северносаамский (шведский — `sv`), `kr` — канури (корейский — `ko`), `uk` — украинский, а `be` — белорусский. Синтаксическая проверка пропускает `jp`, ведь код состоит из двух букв, поэтому сверяйте коды со справочником, а не полагайтесь на то, что они проходят разбор. * **`zh-CN` там, где имеется в виду упрощённый китайский.** В китайском от письменности зависит сам текст, а регион лишь косвенно указывает на письменность: `zh-TW` разворачивается в `zh-Hant-TW`, а `zh-SG` — в `zh-Hans-SG`. Если один перевод на упрощённый китайский предназначен и для материкового Китая, и для Сингапура, присвойте ему тег `zh-Hans`; для традиционного используйте `zh-Hant`, а если формулировки различаются, добавьте регион, например `zh-Hant-HK`. * **Устаревшие коды.** `iw` (иврит), `in` (индонезийский) и `ji` (идиш) были объявлены устаревшими ещё в 1989 году и заменены на `he`, `id` и `yi`. Java до версии 17 по-прежнему выдавала старые формы, поэтому они встречаются в старых данных. Канонизация заменяет их. * **Избыточные теги.** `en-Latn-US` указывает письменность, которой английский записывается практически всегда. RFC 5646 [рекомендует](https://www.rfc-editor.org/rfc/rfc5646.html#section-4.1) опускать подтеги, не несущие различительной информации, и отмечает, что при базовой фильтрации запрос `en-US` не совпадёт с контентом, помеченным тегом `en-Latn-US`. * **Корректные коды, которые не поддерживаются потребителем.** `es-419` — корректный код BCP 47, но hreflang в Google принимает только регионы ISO 3166-1, поэтому размечайте такие страницы как `es` или с указанием конкретных стран. (См. [Что такое hreflang?](/kb/what-is-hreflang).) ## Общий или региональный: какой код выбрать? W3C в рекомендациях по [выбору языковых тегов](https://www.w3.org/International/questions/qa-choosing-language-tags) советует делать теги как можно короче и добавлять регион, только если он несёт нужную вам информацию. На практике это сводится к правилу для каждой локали: * **Используйте только код языка** (`fr`, `de`, `ja`), если один перевод подходит для всех регионов, где говорят на этом языке. * **Добавляйте регион**, если различаются орфография, лексика или юридические тексты и вы будете поддерживать отдельные переводы: `en-US` и `en-GB`, `pt-BR` и `pt-PT`, `es-MX` и `es-ES`, `fr-CA`. * **Для китайского, сербского и других языков с несколькими системами письма сначала выберите письменность**: `zh-Hans` и `zh-Hant`, `sr-Cyrl` и `sr-Latn`. * **Используйте региональный код для форматирования, даже если перевод общий.** Текст, один раз переведённый как `en`, всё равно может форматировать даты по локали посетителя `en-GB`, где пишут 28/10/2026, тогда как в `en-US` — 10/28/2026. Для программ код без региона вовсе не означает отсутствие региона. Данные CLDR о вероятных подтегах (likely subtags) подставляют наиболее вероятные письменность и регион, поэтому `pt` разворачивается в `pt-Latn-BR`, а `zh` — в `zh-Hans-CN`. Если ваш перевод `pt` сделан на европейском португальском, присвойте ему тег `pt-PT`. Если локаль пользователя не поддерживается, программа переходит к запасному варианту. Алгоритм [lookup](https://www.rfc-editor.org/rfc/rfc4647.html#section-3.4) из RFC 4647 отбрасывает подтеги с конца, пока не найдётся совпадение (`zh-Hant-HK`, затем `zh-Hant`, затем `zh`), а другие алгоритмы сопоставления проверяют ещё и соседние регионы. О том, как считывать языковые предпочтения браузера и выбирать между этими алгоритмами, рассказывается в статье [как определить язык браузера пользователя](/kb/detect-user-language). ## Нормализация кодов в JavaScript [`Intl.getCanonicalLocales`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales) исправляет регистр букв и заменяет устаревшие подтеги и подтеги-алиасы, а [`Intl.Locale`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale) умеет подставлять наиболее вероятные письменность и регион: ```js title="locale-codes.mjs" const names = new Intl.DisplayNames(['en'], { type: 'language' }); for (const tag of ['EN-gb', 'zh-tw', 'iw-IL', 'en-UK', 'jp', 'es-419', 'en_US']) { try { // Канонизация: исправляем регистр букв и заменяем устаревшие подтеги и подтеги-алиасы на актуальные const [canonical] = Intl.getCanonicalLocales(tag); // Добавляем наиболее вероятные письменность и регион const maximized = new Intl.Locale(canonical).maximize().toString(); console.log(`${tag} -> ${canonical} (${maximized}): ${names.of(canonical)}`); } catch (error) { console.log(`${tag} -> ${error.name}: ${error.message}`); } } // Расширение -u- меняет форматирование, а не язык const time = new Date(Date.UTC(2026, 9, 28, 14, 5)); for (const tag of ['en-US', 'en-US-u-hc-h23', 'ar-EG', 'ar-EG-u-nu-latn']) { const formatted = new Intl.DateTimeFormat(tag, { hour: 'numeric', minute: '2-digit', timeZone: 'UTC', }).format(time); console.log(`${tag}: ${formatted}`); } ``` Вывод команды `node locale-codes.mjs` в Node.js 24.19.0: ```text title="Output" EN-gb -> en-GB (en-Latn-GB): British English zh-tw -> zh-TW (zh-Hant-TW): Chinese (Taiwan) iw-IL -> he-IL (he-Hebr-IL): Hebrew (Israel) en-UK -> en-GB (en-Latn-GB): British English jp -> jp (jp): jp es-419 -> es-419 (es-Latn-419): Latin American Spanish en_US -> RangeError: Incorrect locale information provided en-US: 2:05 PM en-US-u-hc-h23: 14:05 ar-EG: ٢:٠٥ م ar-EG-u-nu-latn: 2:05 م ``` На две строки стоит взглянуть внимательнее. Код `jp` проходит канонизацию, но возвращается без отображаемого имени: проверяется только синтаксис, а не существование языка. А `ar-EG-u-nu-latn` оставляет текст на арабском, но переключает цифры на западные. ## Как General Translation использует коды локалей General Translation везде использует коды BCP 47. В `gt.config.json` параметр [`defaultLocale`](/docs/cli/reference/config#default-locale) задаёт локаль, на которой написано ваше исходное содержимое (по умолчанию `en`), а [`locales`](/docs/cli/reference/config#locales) содержит список целевых локалей: ```json title="gt.config.json" { "defaultLocale": "en-US", "locales": ["en-GB", "fr-CA", "pt-BR", "zh-Hant"] } ``` CLI проверяет эти коды до начала перевода. Работа прерывается, если код недействителен, а также если `defaultLocale` шире целевой локали: перевод с `en` на `en-GB` завершится ошибкой, поэтому в проекте, куда добавляется британский английский, в качестве источника указывается `en-US`, как показано выше. Платформа переводит на локали из списка [поддерживаемых локалей](/docs/platform/dashboard/reference/supported-locales). Как правило, General Translation считает эквивалентные коды одной локалью: `fr`, `fr-FR` и `fr-Latn-FR` получат одинаковый перевод, а `ja` и `ja-JP` обновляют один и тот же сохранённый перевод. (См. [Понимание кодов локалей](/docs/platform/core/guides/locale-codes).) Чтобы использовать код, не соответствующий зарегистрированному языку (например, `cn` в URL-адресах), задайте параметр [`customMapping`](/docs/cli/reference/config#custom-mapping): он делает такой код алиасом стандартного кода (`cn` для `zh`) и позволяет переопределить его отображаемое имя. Для hreflang [руководство по SEO для алиасов локалей](/docs/react/nextjs/locale-alias-seo) сопоставляет алиас обратно с `zh`. Основная библиотека `generaltranslation` экспортирует вспомогательные функции для работы с локалями в виде автономных функций, которым не нужен ключ API. Приведённые ниже возвращаемые значения получены в `generaltranslation` 9.5.8: ```js title="check-locales.mjs" import { standardizeLocale, isValidLocale, getLocaleName, determineLocale, } from 'generaltranslation'; standardizeLocale('EN-gb'); // 'en-GB' isValidLocale('en_US'); // false isValidLocale('jp'); // false getLocaleName('pt-BR', 'en'); // 'Brazilian Portuguese' determineLocale(['fr-CA', 'en-US'], ['en', 'fr', 'zh-Hant']); // 'fr' ``` [`standardizeLocale`](/docs/platform/core/reference/utility-functions/locales/standardize-locale) исправляет регистр букв, [`isValidLocale`](/docs/platform/core/reference/utility-functions/locales/is-valid-locale) отклоняет варианты с подчёркиванием и коды вроде `jp`, которые пропускает `Intl`, [`getLocaleName`](/docs/platform/core/reference/utility-functions/locales/get-locale-name) возвращает отображаемое имя для элемента выбора языка, а [`determineLocale`](/docs/platform/core/reference/utility-functions/locales/determine-locale) подбирает из поддерживаемых локалей ту, что лучше всего соответствует предпочтениям пользователя, — в данном примере пользователь с канадским французским получит ваш перевод `fr`. ## Часто задаваемые вопросы ### Чем код языка отличается от кода локали? Код языка состоит из одного подтега, например `en` или `pt`. Код локали может также включать письменность и регион, например `pt-BR`, поэтому он определяет ещё и форматирование дат, чисел и валют. ### Как правильно: en-GB или en-UK? `en-GB`. `GB` — это код Великобритании в стандарте ISO 3166-1, а `UK` не является зарегистрированным подтегом региона, поэтому Google игнорирует его в hreflang. ### Что использовать: zh-CN или zh-Hans? Используйте `zh-Hans` для текста на упрощённом китайском, рассчитанного на несколько регионов, а `zh-CN` — только если контент предназначен исключительно для материкового Китая. Оба кода разрешаются в упрощённую письменность. ### Чувствительны ли коды локалей к регистру? Нет. `en-us` и `en-US` — это один и тот же тег, но лучше писать `en-US`, чтобы имена файлов, URL-адреса и ключи были единообразными. ## Ключевые выводы * Код локали BCP 47 состоит из языкового подтега и необязательных подтегов письменности, региона, варианта и расширения — именно в таком порядке, через дефис: `zh-Hant-TW`, `es-419`, `en-US-u-hc-h23`. * Сверяйте коды с реестром IANA: `en-GB`, а не `en-UK`; `ja`, а не `jp`; `he`, а не `iw`. * Используйте короткие теги, добавляйте регион только для контента, который зависит от региона, а для китайского языка в первую очередь определяйтесь с письменностью. * Преобразуйте коды на границах систем: POSIX, ICU и метод `toString()` в Java используют подчёркивания, а Android — формат `values-b+es+419`. * General Translation считывает коды BCP 47 из `defaultLocale` и `locales` в `gt.config.json`, отклоняет исходную локаль, если она более общая, чем целевая, и поддерживает алиасы через `customMapping`. ## Related questions - [Как определить язык браузера пользователя?](https://generaltranslation.com/ru/kb/detect-user-language.mdx): Прочитайте упорядоченный список языков браузера (navigator.languages в JavaScript или заголовок Accept-Language на сервере с сортировкой по q-значению) и сопоставьте его с поддерживаемыми локалями, предусмотрев резервный вариант. Safari и Chrome в режиме инкогнито сообщают только один язык, а геолокация по IP указывает на местоположение, а не на язык. - [Что такое hreflang и как его настроить?](https://generaltranslation.com/ru/kb/what-is-hreflang.mdx): Hreflang сообщает Google, какие URL являются языковыми или региональными версиями одной и той же страницы, чтобы в результатах поиска показывалась нужная. Добавьте его с помощью HTML-тегов link, HTTP-заголовков Link или карты сайта, сделайте все ссылки взаимными и используйте корректные коды, например en-GB, а не en-UK. - [Интернационализация и локализация (i18n и l10n)](https://generaltranslation.com/ru/kb/internationalization-vs-localization.mdx): Интернационализация (i18n) — это работа над кодом и дизайном, благодаря которой один продукт может поддерживать множество локалей: например, форматировать даты с помощью Intl и отображать текст с направлением right-to-left. Локализация (l10n) адаптирует продукт под конкретную локаль: это перевод, а также валюта, форматы дат, единицы измерения, тон и правовые нюансы. - [Как форматировать числа, даты и валюты для каждой локали?](https://generaltranslation.com/ru/kb/format-numbers-dates-currencies.mdx): Форматируйте каждое значение при рендеринге страницы с учётом локали читателя с помощью JavaScript Intl API и не включайте его в переводимое предложение. Компоненты General Translation ``, ``, `` и `` делают и то и другое внутри ``, поэтому один перевод подходит для любого значения. - [Подкаталог, поддомен или ccTLD для многоязычного SEO](https://generaltranslation.com/ru/kb/multilingual-url-structure.mdx): Используйте подкаталоги вида example.com/de/, если один продукт работает на общем сайте с единым процессом релизов. На страну указывает только ccTLD, поддомены позволяют размещать версии на отдельном хостинге, параметры ?lang= Google не рекомендует, а «имиджевые» домены вроде .io и .ai считает общими. ## Previous and next questions - Previous question: [Лучшие инструменты ИИ-перевода для разработчиков: API или платформы локализации](https://generaltranslation.com/ru/kb/best-ai-translation-tools.mdx) - Next question: [Что такое память переводов и нужна ли она в эпоху ИИ?](https://generaltranslation.com/ru/kb/what-is-translation-memory.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ru/kb/sitemap.md) for every article.