Como criar um glossário de tradução que tradutores e IA conseguem realmente usar

Para criar um glossário de tradução, escolha os conceitos que precisam de uma redação controlada, defina o que cada um significa no seu documento, aprove um termo de destino para cada idioma e contexto e atribua um responsável pela manutenção dessas decisões. Depois, teste as entradas em passagens reais antes de as entregar a tradutores ou a uma ferramenta de tradução.

A distinção mais útil é entre o glossário principal que regista as suas decisões e a exportação mais pequena que uma ferramenta consegue consumir. Um ficheiro de importação com duas colunas pode ser necessário, mas não substitui o contexto, as evidências e o histórico de aprovação que tornaram essas duas colunas fiáveis.

Comece com o modelo de glossário em branco e o exemplo de glossário preenchido. Ambos são ficheiros CSV em UTF-8. O exemplo usa um produto fictício e decisões ilustrativas de inglês para francês; não é uma lista de terminologia certificada, um projeto de cliente nem uma predefinição de importação pronta a usar no BookTranslator.

Mantenha o glossário mais pequeno do que o dicionário

Inclua um termo quando uma escolha inconsistente ou ambígua alteraria o significado, confundiria a navegação, enfraqueceria uma distinção importante ou causaria trabalho de revisão evitável. Não recolha todos os substantivos só porque o software os extraiu.

Uma passagem de seleção útil pergunta:

• Este conceito repete-se em secções, ficheiros ou contribuidores?
• A palavra de origem tem mais do que um significado relevante?
• A organização, o autor ou a área temática exigem uma forma de destino específica?
• Uma escolha diferente tornaria um aviso, uma instrução, uma interface ou um argumento mais difícil de seguir?
• O termo é novo, está em discussão ou sabe-se que já causou uma correção neste projeto?

Um termo raro mas consequente pode merecer uma entrada antes de uma palavra comum frequente. Um termo padrão sem ambiguidade real pode não precisar de entrada nenhuma.

O guia de introdução à gestão de terminologia para tradução da COTSOES recomenda terminologia relevante para a organização e responsabilidades de validação explícitas. Também alerta que o número de entradas, por si só, não estabelece a qualidade. Estes princípios importam aqui mais do que a idade dos seus exemplos de software.

A extração de candidatos é apenas a caixa de entrada. Uma frase extraída torna-se terminologia útil quando sabe o que significa, quando se aplica e quem aprovou a redação de destino.

Construa um registo em torno de um significado

Não dê à cadeia de origem a propriedade exclusiva do registo. A palavra inglesa “charge” pode descrever uma propriedade elétrica ou um valor faturado. Uma linha que mapeasse todas as ocorrências para uma única palavra francesa codificaria um erro, não consistência.

Atribua a cada conceito um identificador estável e depois acrescente a decisão específica do idioma. Numa folha de cálculo simples, use uma linha por par de conceito e local de origem/destino. Duas linhas podem partilhar a grafia de origem sem representarem o mesmo conceito.

O modelo contém estes campos:

Uma referência de contexto deve permitir que um revisor volte a encontrar a passagem: uma versão e secção de ficheiro, um registo terminológico autoritativo ou outra fonte duradoura. «Da internet» não é suficiente. Para um conceito original definido pelo autor, a própria definição do manuscrito pode ser a evidência relevante.

Mantenha a definição separada do contexto de origem. A definição diz o que o conceito é; o contexto mostra como é utilizado. Uma frase como «Selecione a área de trabalho» ilustra a utilização, mas não explica o que uma área de trabalho contém nem em que difere de um projeto.

Corrigir cinco entradas de glossário comuns

As correções seguintes pertencem ao exemplo fictício descarregável. Ilustram decisões editoriais, não regras universais de terminologia francesa. As passagens de exemplo fornecem o texto circundante.

1. Uma palavra polissémica com um único destino forçado

Entrada fraca: charge → charge

Correção: criar conceitos separados:

• Propriedade elétrica: origem charge; destino charge électrique; domínio «eletrónica introdutória»; contexto «The capacitor stores electric charge.»
• Montante faturado: origem charge; destino frais; domínio «faturação»; contexto «The delivery charge is shown before payment.»

Isto não significa que qualquer dos mapeamentos deva sobrepor-se a todas as ocorrências de «charge». O domínio e o contexto da entrada fazem parte da decisão. Se a ferramenta escolhida não os conseguir distinguir, utilize exportações de projeto separadas, uma frase mais longa e inequívoca ou revisão humana em vez de uma substituição global.

2. Um termo sem a sua classe gramatical

Entrada fraca: seal → sceller

Correção: distinguir o verbo do componente:

• «Selar o envelope»: um verbo, com o alvo ilustrativo sceller neste projeto.
• «Substituir o vedante de borracha»: um substantivo que designa um componente, com o alvo joint.

A folha de cálculo descreve agora dois conceitos em vez de sugerir que um componente de borracha é uma ação. Num documento técnico real, peça ao revisor da área que valide o significado do componente e o termo preferido.

3. Duas traduções aceitáveis sem preferência do projeto

Entrada fraca: workspace → espace de travail / zone de travail

Correção: aprove espace de travail para o contentor nomeado da aplicação fictícia. Registe zone de travail como variante rejeitada para este conceito de interface, não como francês incorreto em geral. Acrescente uma nota de utilização indicando que a flexão gramatical normal é permitida.

Uma variante rejeitada precisa de um motivo e de um âmbito. Caso contrário, um revisor pode «corrigir» uma expressão perfeitamente válida num contexto diferente.

4. Um nome de produto protegido apenas por implicação

Entrada fraca: LeafDeck → LeafDeck

Correção: defina do_not_translate=true, identifique-o como o nome do produto fictício, preserve as maiúsculas e cite a decisão de nomenclatura do projeto de demonstração. Indique que a regra não se aplica a palavras não relacionadas numa descrição comum.

A mera correspondência entre o texto de origem e o de destino não explica se a retenção é intencional ou simplesmente trabalho inacabado. Utilize o guia de decisão sobre o que não traduzir para a lista de exclusão mais ampla.

5. Uma decisão preliminar apresentada como aprovada

Entrada fraca: sync → synchroniser / mettre à jour, sem responsável nem estado.

Correção: defina primeiro a ação. Para o comando fictício que sincroniza a biblioteca do dispositivo, aprove synchroniser como verbo e registe a alternativa como inadequada para este comando em particular. Atribua um responsável e uma fonte de decisão com data.

Mantenha um rótulo separado de substantivo proposto em draft até que o revisor o resolva. O CSV de exemplo inclui deliberadamente essa linha em rascunho. Uma folha de cálculo com bom aspeto não é prova de que todas as linhas estão aprovadas.

Utilize um critério de qualidade de entrada, não uma pontuação decorativa

Antes de aprovar uma entrada, faça seis perguntas de sim ou não:

1. Significado: outra pessoa consegue distinguir este conceito dos conceitos próximos?
2. Evidência: consegue encontrar a fonte de apoio ou a decisão do autor?
3. Língua: a forma de destino funciona para o locale, a gramática e a área especificados?
4. Âmbito: sabe onde a regra se aplica e onde não se aplica?
5. Responsabilidade: existe um responsável pela resolução de alterações?
6. Utilização: a entrada foi verificada numa frase representativa?

Uma resposta por resolver significa que a entrada permanece em rascunho. Trata-se de uma grelha de aceitação editorial, não de uma medida numérica validada da qualidade da tradução.

Divida o trabalho por especialidade. O autor ou especialista no tema confirma o conceito; o revisor da língua de destino confirma o uso; o responsável pela terminologia registra a decisão e distribui a versão aprovada. Uma pessoa pode desempenhar vários papéis num projeto pequeno, mas as perguntas ainda precisam de respostas.

Se um revisor contestar uma entrada, registre as escolhas concorrentes e o trecho que expõe o conflito. Siga o fluxo de trabalho de consultas do tradutor em vez de permitir que mensagens privadas se tornem exceções não documentadas.

Exporte para a ferramenta de destino somente após a aprovação

O seu glossário mestre e o dicionário de um motor têm propósitos diferentes. O mestre explica decisões às pessoas. Um arquivo de importação deve seguir o esquema e o comportamento de correspondência de uma ferramenta específica.

Para uma ferramenta que suporta importação de glossários:

1. Selecione o par de idiomas de origem/destino necessário e o domínio do projeto.
2. Exclua entradas draft e deprecated.
3. Resolva strings de origem duplicadas que a ferramenta de destino não consegue desambiguar.
4. Mapeie apenas os campos suportados para o formato de importação atual da ferramenta.
5. Confirme como ela trata maiúsculas e minúsculas, flexões, termos com várias palavras e texto protegido.
6. Teste uma pequena entrada representativa e inspecione a tradução retornada.

Por exemplo, o formato CSV unidirecional documentado do Google Cloud Translation usa pares origem/destino sem cabeçalho, enquanto o CSV de conjunto de termos equivalentes usa cabeçalhos de idioma. A correspondência de glossário é sensível a maiúsculas e minúsculas por padrão, e algumas entradas de palavras vazias são ignoradas. Essas são regras do Google Cloud, não regras gerais de CSV ou capacidades do BookTranslator. Consulte a documentação atual do glossário do Google Cloud antes de preparar uma exportação para esse serviço.

Não carregue o CSV ricamente anotado deste artigo num diálogo de importação aleatório. Ele é um mestre de trabalho. Por outro lado, não descarte as suas definições e histórico de aprovação só porque uma ferramenta aceita apenas duas colunas.

Ao usar um sistema de IA com um campo de instrução suportado, forneça um subconjunto relevante e aprovado, além do contexto necessário para distinguir significados. Uma instrução pode solicitar terminologia; ela não estabelece que a saída a seguiu. Inspecione o resultado. Se o sistema não oferecer entrada de glossário suportada, mantenha o mestre como referência para revisores em vez de inventar uma forma de importá-lo.

Para organizações com equipes multilíngues na linha de frente, a consistência terminológica também importa após a tradução. Materiais de treinamento, políticas e comunicações operacionais podem precisar chegar aos funcionários nos idiomas de sua preferência, preservando a redação aprovada. O iTacit explica como a comunicação multilíngue apoia a informação no local de trabalho em diferentes idiomas, países e culturas.

Adicione idiomas sem apagar decisões locais

Reutilize o ID do conceito ao adicionar outro idioma de destino, mas dê a esse idioma o seu próprio destino, status, responsável e evidência. A aprovação em francês não aprova um equivalente em alemão. Um destino em branco significa “não resolvido”, não “use a origem automaticamente”.

A mesma disciplina aplica-se dentro de um idioma. Divida decisões específicas de localidade quando elas diferirem materialmente. Não crie linhas duplicadas apenas para adicionar rótulos regionais que não mudam nada.

Mantenha estes estados simples:

• Rascunho: uma decisão candidata ou contestada; não faz parte de uma exportação aprovada.
• Aprovado: aceito para o escopo e a versão declarados.
• Obsoleto: mantido para histórico e detecção, mas não recomendado para novos trabalhos.

Para uma alteração substancial, registre a forma antiga, a nova forma, o motivo, a versão efetiva, o responsável e os locais de origem afetados. Reconstrua a exportação relevante e informe aos tradutores quais trechos exigem reconsideração. Não substitua um termo silenciosamente no meio do projeto e espere que os capítulos já traduzidos se atualizem sozinhos.

Revise as entradas quando o produto, o manuscrito de origem, a norma ou o uso aceito mudarem. Um lembrete de calendário pode ajudar, mas uma definição alterada é o gatilho mais forte.

Valide o glossário em passagens antes de o expandir

Um glossário pode estar internamente organizado e, ainda assim, falhar numa frase. Utilize um pequeno conjunto de passagens que inclua deliberadamente:

• uma palavra de origem ambígua com dois significados;
• um termo como título e no corpo do texto;
• uma variação gramatical no singular, no plural ou outra;
• um nome protegido junto de linguagem comum; e
• um termo numa tabela, legenda, instrução ou outra estrutura importante do documento.

O exemplo para transferência associa «delivery charge» a «electric charge» e inclui «seal» como substantivo e como verbo. Estes casos demonstram porque é que a substituição sem âmbito é o teste de aceitação errado.

Para cada passagem, registe a origem, a versão do glossário, o resultado final, a decisão do revisor e a correção, se necessária. Se testar efetivamente um serviço de tradução, acrescente o serviço/modelo, a data, as configurações e o resultado em bruto. Os exemplos neste artigo não afirmam que esse teste de serviço foi realizado.

Depois de o documento completo estar traduzido, avance para a revisão da consistência terminológica. A construção do glossário estabelece a política; a revisão do resultado determina se o texto entregue a segue sem se tornar artificial.

Entregue um registo de decisões, não apenas uma lista de palavras

A entrega final deve conter a versão de origem, o glossário principal aprovado, a exportação para a ferramenta de destino, se aplicável, o registo de consultas por resolver e exemplos representativos. Quem faz a tradução deve saber qual é o ficheiro vinculativo e a quem perguntar sobre conflitos.

Para um livro completo ou documento longo compatível, o fluxo de trabalho de tradução de ficheiros do BookTranslator pode fornecer um rascunho para revisão posterior. Mantenha o seu glossário aprovado junto desse rascunho. A folha de cálculo aqui apresentada é uma referência editorial externa, não uma afirmação de que o BookTranslator importa glossários CSV geridos pelo utilizador ou aplica todas as entradas.

Comece com alguns conceitos relevantes, torne as decisões inspecionáveis e expanda a partir de ambiguidades genuínas ou de conclusões da revisão. O objetivo é haver menos decisões por resolver no documento seguinte — não o glossário mais extenso.