Cada entrada de glosario, voz de marca, instrucción y configuración de modelo se almacena para un idioma. Cuando el motor procesa una solicitud de traducción, determina qué entradas almacenadas se aplican al idioma de la solicitud: busca coincidencias exactas, hereda entre variantes regionales y recurre a un fallback 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 introducirse, y después se almacenan y devuelven en ese formato. Se corrigen las mayúsculas, minúsculas y los delimitadores; los subtags se conservan.
| Introduces | Se almacena como |
|---|---|
EN | en |
en_US | en-US |
sr_Latn-RS | sr-Latn-RS |
zh-cn | zh-CN |
La coincidencia es bidireccional a ambos lados del límite del subtag: un idioma almacenado se aplica a una solicitud cuando coincide exactamente con ella o cuando uno 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 genérica de de es el patrón más habitual en la práctica: 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 resuelven varias coincidencias#
Cuando se aplica más de una entrada almacenada, el motor las ordena por prioridad y usa la mejor:
- Primero, coincidencia exacta o predeterminada del idioma. Para una solicitud de
de, se prefierede-DE(la región predeterminada de CLDR para el alemán) y después eldegenérico. - Después, la más específica, como criterio de desempate.
- Cualquier otra región que coincida se mantiene como fallback: un cliente cuya única entrada sea
de-CHseguirá recibiéndola para una solicitud dedecuando no haya nada mejor, para que la configuración nunca quede huérfana.
| Solicitud | Preferida | También se aplica (fallback) | 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 las entradas de glosario custom_translation, cuyo texto está vinculado a una ortografía concreta. Un idioma base con una escritura ambigua —sr (cirílico o latino), zh (simplificado o tradicional)— debe especificar una escritura (sr-Cyrl, sr-Latn, zh-Hans, zh-Hant) al guardarse. Los idiomas con una sola escritura, como de, no necesitan especificarla y resuelven de a de-DE con normalidad. Las entradas non_translatable se transfieren independientemente de 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
frrecoge el glosario, la voz de marca y las instrucciones defr-FR, priorizados como 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 recogenb-NO.noynbson subtags de idioma distintos, no un par regional; usanbcomo destino.
Uso de la resolución de idiomas con la API#
La resolución se produce automáticamente cuando llamas al endpoint localize. El motor hace coincidir el sourceLocale y el targetLocale de la solicitud con los glosarios, las voces de marca, las instrucciones y las configuraciones de modelo almacenados; no hace falta ningún parámetro adicional.
