Cada item de glossário, voz da marca, instrução e configuração de modelo fica associado a um idioma. Quando o motor processa um pedido de tradução, determina quais das entradas armazenadas se aplicam ao idioma pedido — fazendo corresponder códigos exatos, herdando entre variantes regionais e recorrendo a fallback quando não existe uma entrada exata. A mesma lógica de resolução aplica-se às quatro superfícies de configuração.
Como funciona#
Os idiomas são normalizados para uma forma canónica à entrada e depois armazenados e devolvidos nesse formato. As maiúsculas/minúsculas e os delimitadores são corrigidos; os subtags são preservados.
| Introduz | Armazenado como |
|---|---|
EN | en |
en_US | en-US |
sr_Latn-RS | sr-Latn-RS |
zh-cn | zh-CN |
A correspondência é bidirecional ao longo da fronteira do subtag — um idioma armazenado aplica-se a um pedido quando há uma correspondência exata ou quando um é ancestral do outro.
| Armazenado | Aplica-se a | Não se aplica a |
|---|---|---|
de | de, de-DE, de-AT, de-CH | - |
de-DE | de-DE, de | de-AT, de-CH (irmãos) |
Herança inversa
Um de-DE armazenado que responde a um pedido genérico de de é o padrão mais comum no mundo real: a maioria dos motores está configurada com códigos regionais completos, mas recebe pedidos com o código base. Ambos os sentidos são suportados.
Resolução entre várias correspondências#
Quando se aplica mais do que uma entrada armazenada, o motor ordena-as e utiliza a melhor:
- Correspondência exata ou predefinição do idioma em primeiro lugar. Para um pedido
de,de-DE(a região predefinida do CLDR para alemão) é preferido, seguido dedesem região. - A mais específica vem a seguir, como critério de desempate.
- Qualquer outra região correspondente mantém-se como fallback — um cliente cuja única entrada é
de-CHcontinua a recebê-la para um pedidodequando não há correspondência melhor, para que a configuração nunca fique órfã.
| Pedido | Preferido | Também se aplica (fallback) | Excluído |
|---|---|---|---|
de | de-DE, depois de | de-CH, de-AT | - |
de-DE | de-DE, depois de | - | de-AT, de-CH |
de-AT | de-AT, depois de | - | de-DE, de-CH |
Segurança de escrita#
Aplica-se uma regra adicional apenas aos itens de custom_translation do glossário, cujo texto está associado a uma ortografia específica. Um idioma base com escrita ambígua — sr (cirílico ou latino), zh (simplificado ou tradicional) — tem de indicar explicitamente uma escrita (sr-Cyrl, sr-Latn, zh-Hans, zh-Hant) no momento da gravação. Idiomas com uma única escrita, como de, não precisam de escrita e resolvem de para de-DE normalmente. Os itens non_translatable passam sempre, independentemente da escrita.
Exemplo#
Um motor configurado com códigos regionais (en-US para fr-FR, de-DE, nb-NO) que recebe pedidos com o código base (fr, de, no):
- Um destino
frherda o glossário, a voz da marca e as instruções defr-FR— classificados como a predefinição parafr, e não como último recurso, porquefr-FRé a região predefinida do CLDR para francês. - Uma origem de
encorresponde a entradasen-US— a correspondência é bidirecional. - Um destino
nonão herdanb-NO.noenbsão subtags de idioma diferentes, não um par de regiões; usenbcomo destino.
Usar a resolução de idiomas com a API#
A resolução acontece automaticamente quando chama o endpoint localize. O motor faz corresponder o sourceLocale e o targetLocale do pedido aos glossários, vozes da marca, instruções e configurações de modelo armazenados — não são necessários parâmetros adicionais.
