Cada término del glosario, texto de voz de marca, regla y configuración de modelo se guarda para un idioma. Cuando el motor procesa una solicitud de traducción, resuelve qué entradas guardadas aplican al idioma de la solicitud: hace match con códigos exactos, hereda entre variantes regionales y recurre a fallback cuando no existe una entrada exacta. La misma 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 funciona en ambos sentidos a través del límite del subtag: un idioma almacenado se aplica a una solicitud cuando uno coincide exactamente con el otro o es ancestro del otro. Dos formas de escribir el mismo idioma también coinciden cuando ninguno es ancestro del otro, pero la región define la escritura: las formas con solo región y con escritura especificada son equivalentes (zh-CN ≡ zh-Hans-CN, zh-TW ≡ zh-Hant-TW).
| 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) |
zh-CN | zh-CN, zh-Hans-CN, zh | zh-TW, zh-Hant-TW (escritura distinta) |
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 |
Priorizar vs. seleccionar#
La prioridad anterior define el orden para las superficies que se combinan, y el resultado ganador para las superficies que eligen una sola opción:
| Superficie | Qué hace la prioridad |
|---|---|
| Glosario | Se puede recuperar cada término coincidente; la relevancia semántica decide qué llega al prompt |
| Reglas | Se incluye cada regla coincidente, primero la del idioma con mejor match |
| Voz de marca | Gana el único texto con mejor match: se aplica un texto de voz de marca por solicitud |
| Configuraciones de modelo | La mejor coincidencia se convierte en el modelo principal; el resto forma la cadena de fallback |
Seguridad de escritura#
Hay una regla adicional que aplica solo a los elementos del glosario custom_translation, cuyo texto está ligado a una ortografía específica. Un idioma base con escritura ambigua, como sr (cirílica o latina) o zh (simplificada o tradicional), debe quedar definido con una escritura al guardarse, ya sea con una escritura explícita (zh-Hans, sr-Cyrl) o con una región que la determine (zh-CN → simplificada, sr-RS → cirílica, según CLDR). Solo se rechaza un código verdaderamente genérico, sin escritura ni región. Al leer, estas formas definidas son equivalentes: un término guardado como zh-Hans-CN aplica a una solicitud de zh-CN y viceversa. Pero una solicitud genérica de zh, cuya escritura es desconocida, no toma una fila definida con una escritura, así que envía una escritura o región explícita para obtener resultados predecibles. 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 tal cual, 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 los términos del glosario, el texto de voz de marca y las reglas 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 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 endpoint. El motor relaciona el sourceLocale y el targetLocale de la solicitud con los términos del glosario, los textos de voz de marca, las reglas y las configuraciones de modelo que aplica; no hace falta ningún parámetro adicional.
