Cada item de glossário, voz da marca, instrução e configuração de modelo é armazenado em um idioma. Quando o engine processa uma solicitação de tradução, ele determina quais entradas armazenadas se aplicam ao idioma da solicitação — fazendo correspondência com códigos exatos, herdando entre variantes regionais e recorrendo a fallback quando não há uma entrada exata. A mesma lógica de resolução vale para essas quatro camadas de configuração.
Como funciona#
Os idiomas são normalizados para uma forma canônica no momento da entrada e, depois, armazenados e retornados nesse formato. Maiúsculas, minúsculas e delimitadores são ajustados; os subtags são preservados.
| Você informa | Armazenado como |
|---|---|
EN | en |
en_US | en-US |
sr_Latn-RS | sr-Latn-RS |
zh-cn | zh-CN |
A correspondência é bidirecional na fronteira entre subtags — um idioma armazenado se aplica a uma solicitação 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ãs) |
Herança reversa
Um de-DE armazenado atendendo a uma solicitação genérica de de é o padrão mais comum no mundo real: a maioria dos engines é configurada com códigos regionais completos, mas recebe solicitações com código-base. As duas direções são compatíveis.
Como resolver várias correspondências#
Quando mais de uma entrada armazenada se aplica, o engine faz um ranqueamento e usa a melhor:
- Correspondência exata ou padrão do idioma primeiro. Para uma solicitação
de,de-DE(a região padrão do CLDR para o alemão) tem prioridade, seguido dodegenérico. - A mais específica vem em seguida, como critério de desempate.
- Qualquer outra região correspondente continua valendo como fallback — um cliente cuja única entrada é
de-CHainda a recebe para uma solicitaçãodequando nada melhor corresponde, para que nenhuma configuração fique órfã.
| Solicitação | Preferido | Também se aplica (fallback) | Excluído |
|---|---|---|---|
de | de-DE, seguido de de | de-CH, de-AT | - |
de-DE | de-DE, seguido de de | - | de-AT, de-CH |
de-AT | de-AT, seguido de de | - | de-DE, de-CH |
Segurança de escrita#
Há uma regra extra que se aplica apenas a itens de glossário custom_translation, cujo texto está vinculado a uma ortografia específica. Um idioma base com escrita ambígua — sr (cirílica ou latina), zh (simplificada ou tradicional) — precisa definir 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 dessa definição e resolvem de para de-DE normalmente. Itens non_translatable passam independentemente da escrita.
Exemplo#
Um engine configurado com códigos regionais (en-US para fr-FR, de-DE, nb-NO) recebendo solicitações com código-base (fr, de, no):
- Um destino
frherda o glossário, a voz da marca e as instruções defr-FR— classificados como padrão parafr, e não como último recurso, porquefr-FRé a região padrão do CLDR para o francês. - Uma origem
encorresponde a entradasen-US— a correspondência é bidirecional. - Um destino
nonão herdanb-NO.noenbsão subtags de idioma diferentes, não um par regional; usenbcomo destino.
Usando a resolução de idioma com a API#
A resolução acontece automaticamente quando você chama o endpoint localize. O engine associa o sourceLocale e o targetLocale da solicitação aos glossários, vozes da marca, instruções e configurações de modelo armazenados — sem necessidade de parâmetros adicionais.
