Resolução de idioma

Cada termo do glossário, texto de voz da marca, regra e configuração de modelo é armazenado em um idioma. Quando o engine processa uma solicitação de tradução, ele determina quais entradas salvas se aplicam ao idioma solicitado — fazendo correspondência com 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 vale para as quatro superfícies 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.

A correspondência é bidirecional na fronteira da subtag: um idioma armazenado se aplica a uma solicitação quando há correspondência exata ou quando o idioma armazenado é ancestral da solicitação. Duas grafias do mesmo idioma também correspondem quando nenhuma é ancestral da outra, mas a região define a escrita: as formas apenas com região e as qualificadas por escrita são equivalentes (zh-CN ≡ zh-Hans-CN, zh-TW ≡ zh-Hant-TW).

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 do de gené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-CH ainda a recebe para uma solicitação de quando nada melhor corresponde, para que nenhuma configuração fique órfã.

Classificação x seleção#

A classificação acima define a ordem nas superfícies que combinam entradas e escolhe a vencedora nas superfícies que selecionam apenas uma:

Segurança de escrita#

Uma regra extra se aplica apenas a itens de glossário custom_translation, cujo texto fica 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 no momento da gravação, seja com uma escrita explícita (zh-Hans, sr-Cyrl) ou com uma região que a determine (zh-CN → simplificada, sr-RS → cirílica, segundo o CLDR). Apenas um código realmente genérico, sem escrita e sem região, é rejeitado. Na leitura, essas formas com escrita definida são equivalentes — um termo armazenado como zh-Hans-CN se aplica a uma solicitação zh-CN e vice-versa — mas uma solicitação genérica zh, cuja escrita é desconhecida, não recupera uma entrada com escrita definida. Envie uma escrita ou região explícita para ter resultados previsíveis. Idiomas com uma única escrita, como de, não precisam de escrita 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 fr herda os termos do glossário, o texto de voz da marca e as regras de fr-FR — classificados como padrão de fr, não como último recurso — porque fr-FR é a região padrão do CLDR para o francês.
• Uma origem en corresponde a entradas en-US — a correspondência é bidirecional.
• Um destino no não herda nb-NO. no e nb são subtags de idioma diferentes, não um par regional; use nb como destino.

Usando a resolução de idioma com a API#

A resolução acontece automaticamente quando você chama o endpoint localize. O engine relaciona o sourceLocale e o targetLocale da solicitação aos termos do glossário, textos de voz da marca, regras e configurações de modelo aplicáveis — sem precisar de parâmetros adicionais.

Próximos passos#