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, determina qué entradas guardadas 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 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 funciona en ambos sentidos a través del límite de subetiqueta: un idioma almacenado se aplica a una solicitud cuando uno coincide exactamente con el otro o es ancestro del otro. Dos grafías de un mismo idioma también coinciden cuando ninguno es ancestro del otro, pero una región determina la escritura: las formas con solo región y las que especifican la escritura 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 (distinta escritura) |
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 |
Ordenar o seleccionar#
La clasificación anterior determina el orden en las superficies que combinan varias entradas, y la ganadora en las que eligen solo una:
| Superficie | Qué hace la clasificación |
|---|---|
| Glosario | Todos los términos que coinciden se pueden recuperar; la relevancia semántica decide cuáles llegan al prompt |
| Reglas | Se incluyen todas las reglas coincidentes, primero la del idioma que mejor encaja |
| Voz de marca | Gana el único texto que mejor encaja: 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 alternativas |
Seguridad de escritura#
Hay una regla adicional que solo se aplica a los elementos del glosario custom_translation, cuyo texto está ligado a una ortografía concreta. Un idioma base con una escritura ambigua, como sr (cirílico o latino) o zh (simplificado o tradicional), debe quedar definido con una escritura al guardarlo, ya sea como escritura explícita (zh-Hans, sr-Cyrl) o como una región que la determine (zh-CN → simplificado, sr-RS → cirílico, según CLDR). Solo se rechaza un código completamente genérico, sin escritura ni región. Al leer, estas formas definidas son equivalentes: un término guardado como zh-Hans-CN se aplica a una solicitud zh-CN y viceversa, pero una solicitud genérica zh, cuya escritura es desconocida, no recupera una fila definida con una escritura, así que envía una escritura o una región explícitas para obtener resultados predecibles. Los idiomas con una única escritura, como de, no necesitan escritura y resuelven de a de-DE con normalidad. Los elementos non_translatable se aplican 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
frrecupera los términos del glosario, el texto de voz de marca y las reglas defr-FR, clasificados 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 endpoint. El motor hace coincidir 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 se aplican, sin necesidad de parámetros adicionales.
