Resolução de idiomas

Cada termo do glossário, texto de voz da marca, regra e configuração de modelo é armazenado para um idioma. Quando o motor processa um pedido de tradução, determina que entradas armazenadas se aplicam ao idioma do 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.

A correspondência é bidirecional entre subtags — um idioma armazenado aplica-se a um pedido quando um é uma correspondência exata ou um ancestral do outro. Duas grafias do mesmo idioma também correspondem quando nenhuma é ancestral da outra, mas a região determina a escrita: as formas apenas com região e as formas com escrita explícita são equivalentes (zh-CN ≡ zh-Hans-CN, zh-TW ≡ zh-Hant-TW).

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 de de sem 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-CH continua a recebê-la para um pedido de quando não há correspondência melhor, para que a configuração nunca fique órfã.

Ordenação vs. seleção#

A ordenação acima define a sequência das superfícies que combinam e o vencedor das superfícies que escolhem apenas uma:

Segurança de escrita#

Há uma regra adicional que se aplica apenas aos itens do glossário custom_translation, cujo texto está associado a uma ortografia específica. Um idioma base com escrita ambígua — sr (cirílica ou latina), zh (simplificada ou tradicional) — tem de especificar uma escrita ao gravar, seja como escrita explícita (zh-Hans, sr-Cyrl) ou como uma região que a determine (zh-CN → simplificada, sr-RS → cirílica segundo o CLDR). Só um código verdadeiramente simples, sem escrita e sem região, é rejeitado. Na leitura, estas formas especificadas são equivalentes — um termo armazenado como zh-Hans-CN aplica-se a um pedido zh-CN e vice-versa — mas um pedido simples zh, cuja escrita é desconhecida, não recupera uma linha especificada com escrita, por isso envie uma escrita ou região explícita para obter resultados previsíveis. 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 fr recupera os termos do glossário, o texto de voz da marca e as regras de fr-FR — classificados como a predefinição para fr, e não como último recurso, porque fr-FR é a região predefinida do CLDR para francês.
• Uma origem de 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 de regiões; use nb como 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 termos do glossário, textos de voz da marca, regras e configurações de modelo aplicáveis — não são necessários parâmetros adicionais.

Próximos passos#