# General Translation Knowledge Base: ¿Qué son los códigos de configuración regional, como en-US y en-GB? URL: https://generaltranslation.com/es/kb/locale-codes.mdx Docs index: https://generaltranslation.com/llms.txt Description: Un código de configuración regional identifica un idioma y, cuando es relevante, su sistema de escritura y su región, como en-US para el inglés de Estados Unidos o zh-Hant-TW para el chino tradicional de Taiwán. La mayoría del software usa etiquetas BCP 47 basadas en códigos ISO. General Translation usa códigos BCP 47 para las configuraciones regionales de origen y de destino en gt.config.json. Category: Formato según la configuración regional Last updated: 2026-10-28 Authors: General Translation Team Published: 2026-10-28 Un código de configuración regional designa un idioma y, cuando es relevante, el sistema de escritura en el que se escribe y la región en la que se usa. `en-US` es el inglés de Estados Unidos, `en-GB` es el inglés del Reino Unido y `zh-Hant-TW` es el chino escrito con caracteres tradicionales que se usa en Taiwán. Los navegadores, HTTP, HTML y las API `Intl` de JavaScript siguen el mismo estándar para estos códigos, BCP 47, así que el código que elijas determina qué traducción, formato de fecha y reglas de pluralización recibe cada usuario. ## Cómo se construye una etiqueta BCP 47 [BCP 47](https://www.rfc-editor.org/info/bcp47) es el estándar del IETF para etiquetas de idioma. Combina [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646.html), que define la sintaxis, con [RFC 4647](https://www.rfc-editor.org/rfc/rfc4647.html), que define cómo hacer coincidir las etiquetas. Una etiqueta es una secuencia de subetiquetas separadas por guiones, siempre en este orden: | Subetiqueta | Formato | Origen | Ejemplos | | -------------------- | --------------------------------------------- | --------------------------------------- | ------------------------------------------ | | Idioma (obligatorio) | 2 o 3 letras | ISO 639, el código más corto disponible | `en`, `zh`, `gsw` | | Sistema de escritura | 4 letras | ISO 15924 | `Hant`, `Hans`, `Latn`, `Cyrl` | | Región | 2 letras o 3 dígitos | ISO 3166-1 alpha-2 o UN M.49 | `GB`, `BR`, `419` | | Variante | De 5 a 8 caracteres, o un dígito seguido de 3 | Registrada en la IANA | `de-1901` (ortografía alemana tradicional) | | Extensión | Una sola letra seguida de sus subetiquetas | `u` está definida por Unicode | `ar-EG-u-nu-latn` | | Uso privado | `x` seguida de tus propias subetiquetas | Tú | `en-CA-x-ca` | Todas las subetiquetas válidas figuran en el [IANA Language Subtag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry), la referencia única para consultar cualquier código. Su edición de septiembre de 2026 recoge 8.276 subetiquetas de idioma y 305 de región, y marca los códigos retirados con el código que los sustituye. Combinando estas piezas puedes expresar exactamente lo que necesitas. `sr-Latn-RS` es el serbio escrito en sistema de escritura latino tal como se usa en Serbia. `es-419` es el español de Latinoamérica y el Caribe, donde `419` es un código UN M.49 que designa una región formada por varios países. RFC 5646 ofrece un ejemplo más sutil: `de-CH` es el alemán tal como se usa en Suiza (alto alemán suizo), mientras que el alemán suizo (Schweizerdeutsch) es un idioma distinto con su propio código, `gsw-CH`. ### Las extensiones cambian el formato, no el idioma La extensión `-u-`, definida en la [RFC 6067](https://www.rfc-editor.org/rfc/rfc6067.html) y cuyas claves se enumeran en la [especificación LDML de Unicode](https://unicode.org/reports/tr35/), contiene preferencias de formato. `-u-nu-` selecciona el sistema de numeración; `-u-hc-`, el ciclo horario; `-u-ca-`, el calendario, y `-u-co-`, el orden de clasificación. `en-US-u-hc-h23` sigue siendo inglés de EE. UU.; solo que muestra `14:05` en lugar de `2:05 PM`. El ejemplo que aparece más abajo muestra ambos casos. ## Mayúsculas, guiones y guiones bajos Las etiquetas no distinguen entre mayúsculas y minúsculas, así que `EN-gb` y `en-GB` significan lo mismo. Aun así, el RFC 5646 [recomienda una convención](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1.1): el idioma en minúsculas, el sistema de escritura con la inicial en mayúscula y la región en mayúsculas, como en `zh-Hant-TW`. Normaliza el código a esa forma antes de usarlo en un nombre de archivo o en una URL, para que `/en-gb/` y `/en-GB/` no acaben siendo dos rutas distintas. BCP 47 separa las subetiquetas con guiones. Varias plataformas usan sus propios formatos, así que haz la conversión en el punto de intercambio con cada sistema: | Sistema | Formato | Ejemplo | | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------- | | Web (HTML `lang`, `hreflang`, `Accept-Language`, `Intl`) | BCP 47 con guiones | `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/) e identificadores de configuración regional de ICU | Guiones bajos; también se aceptan guiones | `en_US` | | [Java](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Locale.html) | `toString()` devuelve guiones bajos; `toLanguageTag()` devuelve BCP 47 | `en_US`, `en-US` | | [Recursos de Android](https://developer.android.com/guide/topics/resources/providing-resources) | `r` antes de la región, o `b+` para etiquetas BCP 47 (Android 7.0 y posteriores) | `values-en-rUS`, `values-b+es+419` | JavaScript rechaza la forma con guion bajo: `Intl.getCanonicalLocales('en_US')` lanza un `RangeError`. ## Errores comunes * **`en-UK` en lugar de `en-GB`.** El código de región ISO del Reino Unido es `GB`, y `UK` no figura en el registro de la IANA. Unicode CLDR trata `UK` como un alias, por lo que JavaScript convierte sin avisar `en-UK` en `en-GB`, pero [Google ignora](https://developers.google.com/search/docs/specialty/international/localized-versions) `UK` en hreflang. Escribe `en-GB`. * **Un código de país en la posición del idioma.** `jp`, `cn`, `gr`, `dk` y `cz` no son códigos de idioma: el japonés es `ja`, el chino `zh`, el griego `el`, el danés `da` y el checo `cs`. Algunos códigos de país corresponden a idiomas completamente distintos: `se` es sami septentrional (el sueco es `sv`), `kr` es kanuri (el coreano es `ko`), `uk` es ucraniano y `be` es bielorruso. Las comprobaciones de sintaxis dan por bueno `jp` porque tiene dos letras, así que consulta los códigos en lugar de fiarte de que se analicen sin errores. * **`zh-CN` cuando lo que quieres es chino simplificado.** En chino, el sistema de escritura cambia el texto escrito, y la región solo implica un sistema de escritura: `zh-TW` se expande a `zh-Hant-TW` y `zh-SG` a `zh-Hans-SG`. Si una misma traducción en chino simplificado sirve para China continental y Singapur, etiquétala como `zh-Hans`; usa `zh-Hant` para el tradicional y añade una región, como `zh-Hant-HK`, cuando la redacción difiera. * **Códigos retirados.** `iw` (hebreo), `in` (indonesio) y `ji` (yidis) quedaron obsoletos en 1989 en favor de `he`, `id` y `yi`. Las versiones de Java anteriores a la 17 seguían generando las formas antiguas, así que todavía aparecen en datos antiguos. La canonicalización los sustituye. * **Etiquetas que dicen demasiado.** `en-Latn-US` añade un sistema de escritura que el inglés casi siempre usa. La RFC 5646 [recomienda](https://www.rfc-editor.org/rfc/rfc5646.html#section-4.1) omitir las subetiquetas que no aportan información distintiva, y señala que, con el filtrado básico, una solicitud de `en-US` no coincidirá con contenido etiquetado como `en-Latn-US`. * **Códigos válidos que un consumidor no admite.** `es-419` es un código BCP 47 válido, pero el hreflang de Google solo acepta regiones ISO 3166-1, así que anota esas páginas como `es` o con países concretos. (Consulta [¿Qué es hreflang?](/kb/what-is-hreflang)). ## Código genérico o regional: ¿cuál conviene usar? La recomendación del W3C sobre [cómo elegir etiquetas de idioma](https://www.w3.org/International/questions/qa-choosing-language-tags) es que las etiquetas sean lo más cortas posible y añadir una región solo cuando aporte información que necesites. Llevado a la práctica, esto se traduce en una regla para cada configuración regional: * **Usa solo el idioma** (`fr`, `de`, `ja`) cuando una única traducción sirva para todas las regiones donde se habla. * **Añade una región** cuando la ortografía, el vocabulario o los textos legales difieran y vayas a mantener traducciones separadas: `en-US` y `en-GB`, `pt-BR` y `pt-PT`, `es-MX` y `es-ES`, `fr-CA`. * **Elige primero el sistema de escritura para el chino, el serbio y otros idiomas que usan varios**: `zh-Hans` y `zh-Hant`, `sr-Cyrl` y `sr-Latn`. * **Usa un código regional para el formato aunque la traducción sea compartida.** Un texto traducido una sola vez como `en` puede dar formato a las fechas según la configuración `en-GB` del visitante, que escribe 28/10/2026 donde `en-US` escribe 10/28/2026. Para el software, un código sin región no deja de tener región. Los datos de subetiquetas probables (likely subtags) de CLDR completan el sistema de escritura y la región más probables, de modo que `pt` se expande a `pt-Latn-BR` y `zh` a `zh-Hans-CN`. Si tu traducción `pt` está en portugués europeo, etiquétala como `pt-PT`. Cuando la configuración regional de un usuario no está entre las que admites, el software recurre a una alternativa. La [búsqueda](https://www.rfc-editor.org/rfc/rfc4647.html#section-3.4) de RFC 4647 elimina subetiquetas desde el final hasta encontrar una coincidencia (`zh-Hant-HK`, luego `zh-Hant`, luego `zh`), y otros algoritmos de coincidencia también prueban regiones hermanas. En [cómo detectar el idioma del navegador de un usuario](/kb/detect-user-language) se explica cómo leer las preferencias del navegador y elegir entre esos algoritmos. ## Normalizar códigos en JavaScript [`Intl.getCanonicalLocales`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales) corrige el uso de mayúsculas y minúsculas y sustituye las subetiquetas obsoletas o que son alias, mientras que [`Intl.Locale`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale) puede completar el sistema de escritura y la región más probables: ```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 { // Canonicalizar: corregir mayúsculas y minúsculas y reemplazar subetiquetas obsoletas o alias const [canonical] = Intl.getCanonicalLocales(tag); // Añadir el sistema de escritura y la región probables 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}`); } } // Una extensión -u- cambia el formato, no el idioma 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}`); } ``` Salida de `node locale-codes.mjs` en 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 م ``` Hay dos líneas que vale la pena revisar con más detalle. `jp` supera la canonicalización y se devuelve sin nombre para mostrar, porque la comprobación evalúa la sintaxis, no si el idioma existe. Por su parte, `ar-EG-u-nu-latn` mantiene el texto en árabe, pero usa dígitos occidentales. ## Cómo usa General Translation los códigos de configuración regional General Translation utiliza códigos BCP 47 en todas partes. En `gt.config.json`, [`defaultLocale`](/docs/cli/reference/config#default-locale) es la configuración regional en la que está escrito tu contenido de origen (`en` de forma predeterminada), y [`locales`](/docs/cli/reference/config#locales) enumera las configuraciones regionales de destino: ```json title="gt.config.json" { "defaultLocale": "en-US", "locales": ["en-GB", "fr-CA", "pt-BR", "zh-Hant"] } ``` La CLI comprueba estos códigos antes de traducir nada. Se detiene si encuentra un código no válido, y también cuando `defaultLocale` es más amplio que una configuración regional de destino: traducir de `en` a `en-GB` falla, por lo que un proyecto que añade inglés británico establece su origen en `en-US`, como se muestra arriba. La plataforma traduce a las configuraciones regionales incluidas en su lista de [configuraciones regionales compatibles](/docs/platform/dashboard/reference/supported-locales). Por lo general, General Translation trata los códigos equivalentes como una sola configuración regional: `fr`, `fr-FR` y `fr-Latn-FR` recibirían la misma traducción, y `ja` y `ja-JP` actualizan la misma traducción almacenada. (Consulta [Entender los códigos de configuración regional](/docs/platform/core/guides/locale-codes)). Para usar un código que no corresponde a un idioma registrado, como `cn` en tus URL, [`customMapping`](/docs/cli/reference/config#custom-mapping) de General Translation lo define como alias de un código estándar (`cn` a `zh`) y puede reemplazar su nombre para mostrar. Para hreflang, la [guía de SEO para alias de configuración regional](/docs/react/nextjs/locale-alias-seo) vuelve a asociar el alias con `zh`. La biblioteca Core `generaltranslation` exporta funciones auxiliares de configuración regional como funciones independientes que no requieren una clave de API. Los siguientes valores de retorno corresponden a `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) corrige el uso de mayúsculas y minúsculas, [`isValidLocale`](/docs/platform/core/reference/utility-functions/locales/is-valid-locale) rechaza las formas con guion bajo y códigos como `jp` que `Intl` deja pasar, [`getLocaleName`](/docs/platform/core/reference/utility-functions/locales/get-locale-name) devuelve un nombre para mostrar en un selector de idioma y [`determineLocale`](/docs/platform/core/reference/utility-functions/locales/determine-locale) elige la coincidencia admitida que mejor se ajusta a las preferencias del usuario; en este ejemplo, ofrece tu traducción `fr` a un usuario francocanadiense. ## Preguntas frecuentes ### ¿Cuál es la diferencia entre un código de idioma y un código de configuración regional? Un código de idioma consta de una sola subetiqueta, como `en` o `pt`. Un código de configuración regional puede incluir además un sistema de escritura y una región, como `pt-BR`, por lo que también determina el formato de fechas, números y monedas. ### ¿Es en-GB o en-UK? `en-GB`. `GB` es el código ISO 3166-1 del Reino Unido; `UK` no es una subetiqueta de región registrada y Google la ignora en hreflang. ### ¿Debo usar zh-CN o zh-Hans? Usa `zh-Hans` para texto en chino simplificado destinado a más de una región, y `zh-CN` solo cuando el contenido sea específico de China continental. Ambos se resuelven al sistema de escritura simplificado. ### ¿Los códigos de configuración regional distinguen entre mayúsculas y minúsculas? No. `en-us` y `en-US` son la misma etiqueta, pero usa `en-US` para que los nombres de archivo, las URL y las claves sean coherentes. ## Puntos clave * Un código de configuración regional BCP 47 consta de una subetiqueta de idioma seguida de subetiquetas opcionales de sistema de escritura, región, variante y extensión, en ese orden y separadas por guiones: `zh-Hant-TW`, `es-419`, `en-US-u-hc-h23`. * Consulta los códigos en el registro de la IANA: `en-GB`, no `en-UK`; `ja`, no `jp`; `he`, no `iw`. * Usa etiquetas cortas, añade una región solo cuando el contenido varíe según la región y, en el caso del chino, elige primero el sistema de escritura. * Convierte los códigos en los límites del sistema: POSIX, ICU y `toString()` de Java usan guiones bajos, y Android usa `values-b+es+419`. * General Translation lee los códigos BCP 47 de `defaultLocale` y `locales` en `gt.config.json`, rechaza una configuración regional de origen más amplia que una de destino y admite alias mediante `customMapping`. ## Related questions - [¿Cómo detecto el idioma del navegador de un usuario?](https://generaltranslation.com/es/kb/detect-user-language.mdx): Lee la lista ordenada de idiomas del navegador (navigator.languages en JavaScript o la cabecera Accept-Language en el servidor), ordenada por valor q, y busca la coincidencia con tus configuraciones regionales compatibles, con una configuración regional de respaldo. Safari y el modo incógnito de Chrome solo indican un idioma, y la geolocalización por IP revela la ubicación, no el idioma. - [¿Qué es hreflang y cómo se configura?](https://generaltranslation.com/es/kb/what-is-hreflang.mdx): Hreflang le indica a Google qué URL son versiones de la misma página en otros idiomas o regiones, para que pueda mostrar la adecuada en los resultados de búsqueda. Agrégalo con etiquetas link de HTML, cabeceras HTTP Link o un mapa del sitio, asegúrate de que todos los enlaces sean recíprocos y usa códigos válidos como en-GB, no en-UK. - [Internacionalización vs. localización (i18n vs. l10n)](https://generaltranslation.com/es/kb/internationalization-vs-localization.mdx): La internacionalización (i18n) es el trabajo de código y diseño que permite que un mismo producto admita muchas configuraciones regionales; por ejemplo, dar formato a fechas con Intl o admitir texto right-to-left. La localización (l10n) lo adapta a una configuración regional concreta, lo que abarca la traducción, pero también la moneda, los formatos de fecha, las unidades, el tono y los aspectos legales. - [¿Cómo doy formato a números, fechas y monedas para cada configuración regional?](https://generaltranslation.com/es/kb/format-numbers-dates-currencies.mdx): Da formato a cada valor cuando se renderiza la página, con la configuración regional del lector y la API Intl de JavaScript, y mantenlo fuera de la oración traducida. Los componentes ``, ``, `` y `` de General Translation hacen ambas cosas dentro de un ``, de modo que una sola traducción sirve para cualquier valor. - [Subdirectorio vs. subdominio vs. ccTLD para SEO multilingüe](https://generaltranslation.com/es/kb/multilingual-url-structure.mdx): Usa subdirectorios como example.com/de/ cuando un mismo producto comparte sitio y proceso de lanzamiento. Solo un ccTLD indica un país, los subdominios permiten un alojamiento independiente, Google desaconseja los parámetros ?lang= y trata los dominios personalizados como .io y .ai como genéricos. ## Previous and next questions - Previous question: [¿Qué es la memoria de traducción y sigue siendo necesaria con la IA?](https://generaltranslation.com/es/kb/what-is-translation-memory.mdx) - Next question: [Alternativas a DeepL: General Translation vs. DeepL](https://generaltranslation.com/es/kb/general-translation-vs-deepl.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/es/kb/sitemap.md) for every article.