Cada entrada de glosario, voz de marca, instrucción y configuración de modelo se guarda para un idioma. Cuando el motor procesa una solicitud de traducción, resuelve qué entradas almacenadas se aplican al idioma de la solicitud: hace coincidir códigos exactos, hereda entre variantes regionales y recurre a una alternativa cuando no existe una entrada exacta. La misma lógica de resolución se aplica a las cuatro superficies de configuración.
Cómo funciona#
Los idiomas se normalizan a una forma canónica al ingresarlos, y luego se almacenan y devuelven en esa misma forma. Se corrigen el uso de mayúsculas y minúsculas y los delimitadores; los subtags se conservan.
| Ingresas | Se guarda como |
|---|---|
EN | en |
en_US | en-US |
sr_Latn-RS | sr-Latn-RS |
zh-cn | zh-CN |
La coincidencia es bidireccional a través del límite entre subtags: un idioma almacenado se aplica a una solicitud cuando uno coincide exactamente o es ancestro del otro.
| Almacenado | Se aplica a | No se aplica a |
|---|---|---|
de | de, de-DE, de-AT, de-CH | - |
de-DE | de-DE, de | de-AT, de-CH (hermanos) |
Herencia inversa
Que un de-DE almacenado responda a una solicitud base de de es el patrón más común en el mundo real: la mayoría de los motores se configuran con códigos regionales completos, pero reciben solicitudes con códigos base. Se admiten ambas direcciones.
Cómo se resuelve cuando hay varias coincidencias#
Cuando se aplica más de una entrada almacenada, el motor las ordena y elige la mejor:
- Primero, coincidencia exacta o idioma predeterminado. Para una solicitud de
de, se prefierede-DE(la región predeterminada de CLDR para el alemán), y después eldebase. - Después, la más específica, como criterio de desempate.
- Cualquier otra región coincidente se mantiene como alternativa: un cliente cuya única entrada es
de-CHigual la recibe para una solicitud dedecuando no hay una mejor coincidencia, así que la configuración nunca queda huérfana.
| Solicitud | Preferida | También se aplica (alternativa) | Excluida |
|---|---|---|---|
de | de-DE, luego de | de-CH, de-AT | - |
de-DE | de-DE, luego de | - | de-AT, de-CH |
de-AT | de-AT, luego de | - | de-DE, de-CH |
Seguridad de escritura#
Hay una regla adicional que solo se aplica a los elementos de glosario custom_translation, cuyo texto está ligado a una ortografía específica. Un idioma base con escritura ambigua —sr (cirílica o latina), zh (simplificada o tradicional)— debe definir una escritura (sr-Cyrl, sr-Latn, zh-Hans, zh-Hant) al momento de guardarse. Los idiomas con una sola escritura, como de, no necesitan especificarla y resuelven de a de-DE con normalidad. Los elementos de non_translatable pasan sin importar la escritura.
Ejemplo#
Un motor configurado con códigos regionales (en-US a fr-FR, de-DE, nb-NO) que recibe solicitudes con códigos base (fr, de, no):
- Un destino
frtoma el glosario, la voz de marca y las instrucciones defr-FR; se clasifica como el valor predeterminado parafr, no como último recurso, porquefr-FRes la región predeterminada de CLDR para el francés. - Un origen
encoincide con entradasen-US; la coincidencia es bidireccional. - Un destino
nono tomanb-NO.noynbson subtags de idioma distintos, no un par regional; usanbcomo destino.
Uso de la resolución de idioma con la API#
La resolución ocurre automáticamente cuando llamas al endpoint localize. El motor hace coincidir el sourceLocale y el targetLocale de la solicitud con los glosarios, voces de marca, instrucciones y configuraciones de modelo almacenados; no hace falta agregar parámetros adicionales.
