Uma plataforma em nuvem pode ser difícil de explicar, mesmo quando o autor e o leitor compartilham o mesmo idioma. Entre mercados internacionais, o desafio aumenta: um termo técnico familiar pode ter várias traduções, uma abreviação pode não significar nada para um cliente e declarações de segurança concisas podem se tornar enganosas caso as condições sejam omitidas. A fluência no idioma, por si só, não resolve esses problemas.
Para quem contrata serviços de localização, a tarefa é preservar o significado técnico, ao mesmo tempo que se fornece a cada leitor contexto suficiente para compreendê-lo. Isso pode envolver a tradução de uma visão geral da arquitetura, a edição de uma explicação ou a localização de um guia do administrador. Os serviços de tradução da Terralíngua para documentos técnicos, científicos e de documentação de software dão suporte a esse trabalho linguístico utilizando as referências do cliente e a terminologia acordada. O ponto de partida é fornecer uma explicação técnica aprovada e uma definição clara do público-alvo.
Como definir o que cada leitor precisa
Evite descrever o público-alvo simplesmente como clientes internacionais. Um gerente de compras, um especialista em implementação e um funcionário que utiliza um serviço podem ter necessidades e interfaces diferentes. O nível de familiaridade deles com a terminologia técnica em inglês também pode variar dentro do mesmo mercado. Defina o papel do leitor, seu conhecimento prévio e a decisão pretendida antes de determinar o nível de explicação necessário para um documento traduzido.
- Os avaliadores de negócios precisam de uma descrição clara do que a tecnologia faz, seu uso pretendido e as limitações relevantes para sua avaliação.
- Os administradores precisam de descrições precisas dos comportamentos compatíveis, dos pré-requisitos, das dependências e das configurações ou referências relacionadas às tarefas sob sua responsabilidade.
- Os usuários finais precisam de termos reconhecíveis, mensagens claras e explicações que conectem a tecnologia à sua experiência imediata.
- Os revisores especializados precisam de detalhes suficientes para confirmar se as definições, condições e alegações correspondem à documentação aprovada do produto.
Essas diferenças afetam tanto a estrutura quanto o vocabulário. Uma visão geral pode apresentar um conceito antes de nomear seus componentes, enquanto uma página de referência pode começar com uma configuração específica. Decida se a tarefa é uma tradução para o mesmo público (por exemplo, os EUA) ou uma adaptação autorizada para outro público (como a Europa). Reorganizar ou expandir conteúdo técnico requer um escopo editorial definido e a aprovação do cliente.
Para cada documento, escreva uma breve declaração sobre o público-alvo. Por exemplo: esta visão geral ajuda a equipe de compras a entender os limites do serviço antes de uma avaliação técnica, sem a necessidade de realizar qualquer configuração. Essa descrição informa à equipe linguística por que comandos detalhados podem ser desnecessários, embora uma limitação continue sendo essencial. Isso também oferece aos revisores uma base para avaliar a clareza sem exigir que cada documento atenda a todos os leitores.
Como manter a estabilidade do significado técnico
Elabore uma declaração conceitual concisa que deve ser capaz de sobreviver a todas as adaptações de idioma e público. Identifique o que o recurso faz e o que não faz, as condições aplicáveis e os termos aprovados que o descrevem. Este material de referência pode evitar traduções diferentes sobre o mesmo produto, especialmente quando os tradutores não têm acesso direto para testar a interface.
Considere um exemplo fictício de serviço em nuvem. O original aprovado afirma que administradores autorizados podem acessar registros de atividades por um período específico quando uma determinada opção de serviço está habilitada. Uma análise geral feita por um avaliador pode explicar a disponibilidade e a finalidade desses registros. Um documento administrativo pode identificar a opção e vinculá-la à referência relevante. Nenhuma das versões deve dar a entender que todos os usuários têm acesso, que os registros são mantidos indefinidamente ou que a opção está sempre habilitada.
O objetivo deste exemplo é uma consideração linguística, não uma recomendação sobre registro ou retenção de dados. O dono do produto determina o comportamento real e a linguagem aceitável. Os tradutores precisam dessas decisões porque palavras como "pode", "deve", "disponível" e "automático" expressam condições diferentes. Uma frase mais curta não é uma melhoria se ela transforma um recurso disponível sob determinadas condições em uma promessa válida em qualquer situação. Considere usar uma linguagem técnica, como as diretrizes do Inglês Técnico Simplificado (STE, na sigla em inglês).
Uma explicação em camadas pode servir a públicos diversos: apresente o conceito em linguagem simples, forneça seu nome técnico aprovado e, em seguida, direcione os leitores especializados para os detalhes apropriados. Mantenha a ressalva próxima da alegação que ela limita. Mover uma condição importante para uma nota distante pode fazer com que o parágrafo principal pareça mais abrangente do que o pretendido, especialmente quando os leitores o encontram por meio de um resultado de pesquisa ou um trecho reutilizado.
Verifique se um trecho também aparecerá fora do documento original. Um slide de vendas ou um trecho de apoio pode perder a definição apresentada na página anterior. Identifique os locais de reutilização de conteúdo e inclua contexto suficiente para que cada um seja compreensível de forma independente. O mesmo conceito aprovado pode sustentar diversas explicações, mas os limites da alegação devem permanecer visíveis onde quer que ela apareça.
Como construir um glossário em torno de conceitos, não de palavras isoladas
Uma lista de palavras bilíngue é útil, mas tecnologias complexas geralmente exigem mais contexto. Para cada conceito importante, forneça uma definição, um original aprovado, uma frase de exemplo e quaisquer restrições específicas do produto. Registre se um termo é de uso geral no setor, um recurso da marca, um rótulo de interface ou um identificador que deve permanecer inalterado. Essas categorias podem exigir tratamento diferenciado na tradução.
A palavra "chave" ilustra esse problema. Dependendo do contexto, pode se referir a um dispositivo de segurança física, a um conceito criptográfico ou a um elemento nomeado em uma estrutura de dados. O tradutor não deve selecionar um único equivalente na língua de destino e aplicá-lo em todos os casos. Uma fotografia, uma definição ou uma referência ao componente relevante do produto podem estabelecer qual significado é pretendido antes que a terminologia seja aprovada.
Decida como as abreviações desconhecidas serão apresentadas para cada público. Uma abreviatura inglesa já estabelecida pode continuar sendo útil em outro idioma, mas os leitores ainda podem precisar de uma explicação no idioma local. Evite criar uma sigla traduzida que o produto ou seus usuários não reconheçam. Registre a forma aprovada para a primeira ocorrência e a forma a ser usada nas ocorrências seguintes, garantindo que as páginas de visão geral e a documentação de apoio tratem o conceito de maneira consistente.
Utilize referências terminológicas públicas para compreender uma área, e depois confirme se elas se adequam ao produto. Uma definição genérica não é suficiente para esclarecer o significado de um recurso exclusivo. As diretrizes de estilo para desenvolvedores do Google também tratam as escolhas terminológicas como dependentes do domínio e dos leitores, recomendando uma documentação oficial para definições técnicas. Um glossário de projeto aprovado deve definir essas decisões, em vez de deixá-las a cargo de cada tradutor, de forma independente.
Diretrizes da documentação para desenvolvedores do Google sobre terminologia e definições técnicas
Como resolver a ambiguidade do original antes que ela se multiplique
A revisão antes da tradução pode revelar questões ocultas por meio de expressões familiares em inglês. Por exemplo: “Considere a instrução como ilustrativa e revise a política após a atualização”. Qual política, qual atualização e quem deve revisá-la? Uma língua com diferentes exigências gramaticais pode obrigar o tradutor a escolher uma interpretação que o original nunca estabeleceu. Peça ao autor do conteúdo que esclareça a relação em vez de tornar a frase mais categórica na tradução.
Verifique sequências longas de substantivos, pronomes com mais de um referente possível e frases que combinem uma condição, uma ação e uma exceção. Divida as informações quando isso facilitar a compreensão, mas mantenha a relação entre os segmentos de texto. As diretrizes da Microsoft para conteúdo global recomendam frases simples, modificadores precisos e palavras de ligação para ajudar leitores e tradutores a interpretar a estrutura. Estas são recomendações de escrita, não um substituto para uma revisão técnica.
Sempre que possível, substitua declarações vagas sobre benefícios por explicações aprovadas. Palavras como "perfeito", "inteligente" ou "seguro" podem não informar aos leitores o que um recurso realmente faz. A equipe linguística pode sinalizar as incertezas e propor uma linguagem mais clara, mas o cliente deve comprovar as alegações sobre o produto. Não adicione garantias, certificações ou implicações de desempenho simplesmente para tornar uma explicação mais persuasiva em outro mercado.
Defina como as alterações editoriais serão aprovadas. Caso o original deva permanecer inalterado, documente separadamente as perguntas e os esclarecimentos autorizados. Caso haja edição do texto original, aprove a versão editada antes de utilizá-la como base para a tradução. Caso contrário, diferentes idiomas podem apresentar respostas diferentes para a mesma pergunta. Em revisões posteriores, isso exigiria comparar textos originais inconsistentes com uma tradução confirmada.
Como fornecer referências técnicas
Materiais de referência úteis explicam o produto abordado no conteúdo, e não apenas o setor em que ele se insere. Forneça as especificações atuais ou as descrições de produto aprovadas, explicações relevantes sobre a arquitetura, decisões terminológicas e capturas de tela representativas. Identifique a versão e a configuração de serviço às quais o material se aplica. Classifique os documentos mais antigos como referências históricas para que não sejam confundidos com a versão atual.
- Público-alvo e finalidade: identifique as funções dos leitores, o conhecimento prévio esperado, as decisões pretendidas e os idiomas-alvo ou variantes regionais.
- Original aprovado: forneça documentos editáveis ou exportações estruturadas, informações de versão e o responsável pelas questões técnicas não resolvidas.
- Referências conceituais: inclua definições aprovadas, descrições de recursos, diagramas e exemplos que expliquem terminologia desconhecida ou de uso exclusivo.
- Conteúdo preservado: identifique nomes de produtos, comandos, parâmetros, espaços reservados, elementos de código e outros materiais que não devem ser traduzidos.
- Escopo editorial: especifique se o trabalho inclui tradução, edição do texto original, adaptação ao público-alvo, diagramação ou revisão no ambiente de entrega.
- Aceitação e entrega: indique os nomes dos revisores, os formatos exigidos, as etapas de aprovação e o prazo, incluindo quaisquer dependências de alterações no produto.
Estabeleça qual referência prevalece quando os materiais divergirem. Uma especificação recente pode substituir uma apresentação, enquanto um rótulo de interface aprovado pode diferir de um termo genérico do glossário. Peça ao cliente para resolver o conflito e registre a resposta com seu escopo. As restrições de acesso também devem ser discutidas antes de compartilhar informações de arquitetura não publicadas, exemplos de clientes ou documentação interna com os colaboradores do projeto.
Como localizar explicações e preservar elementos técnicos
Separe as explicações legíveis dos elementos literais do sistema que possam ter um requisito de não tradução (DNT). O nome de um comando, parâmetro ou marcador de posição pode estar inserido em instruções traduzidas sem que ele próprio seja traduzido. Informe à equipe linguística quais exemplos são ilustrativos e quais devem permanecer executáveis ou estruturalmente intactos, como prompts de comando ou tags. Os especialistas de produto devem confirmar a validade técnica, pois uma revisão linguística por si só não garante que um exemplo de código ou configuração funcionará.
Torne as referências utilizáveis no contexto do leitor. Se um console de administração permanecer no idioma original, as instruções traduzidas podem precisar manter os rótulos visíveis e adicionar uma explicação. Se o console estiver traduzido, forneça os rótulos e as capturas de tela correspondentes. Isso é particularmente importante quando um termo conceitual e um controle de interface usam palavras diferentes: os leitores precisam entender a ideia e localizar o recurso em si.
Consulte os diagramas e as legendas como parte da explicação. Forneça capturas de tela traduzidas ou imagens editáveis quando os rótulos exigirem localização. Identifique legendas ou informações adicionais armazenadas fora do documento principal. Verifique se os rótulos traduzidos ainda se encaixam no texto traduzido expandido e se as conexões permanecem claras. Uma versão abreviada do rótulo deve preservar o conceito aprovado, em vez de se tornar uma abreviação desconhecida apenas para caber no espaço original.
Leitura complementar: como alinhar a localização do software e a documentação do usuário
Como fazer revisões de precisão e controle de qualidade
Atribua as decisões técnicas e linguísticas a revisores e funções apropriados. O especialista de produto do cliente confirma o comportamento, as limitações e a terminologia da versão relevante. O revisor linguístico verifica se a tradução comunica esse significado de forma natural e consistente. Um revisor editorial pode avaliar a estrutura e o nível de leitura em relação ao público-alvo. A aprovação de uma única pessoa não deve ser considerada suficiente para abranger todas as responsabilidades.
Peça aos revisores que respondam a perguntas concretas. O leitor pretendido consegue explicar a finalidade do conceito depois de ler a introdução? Os pré-requisitos e as exceções ainda estão vinculados às alegações corretas? O exemplo ilustra o mesmo comportamento que a referência? Os termos desconhecidos são introduzidos antes de serem usados para explicar outro termo desconhecido? Essas perguntas são mais úteis do que perguntar se a tradução soa profissional.
Para projetos de grande porte, defina uma seção representativa para revisão antes de traduzir todo o conjunto de documentos. Escolha um trecho que contenha um conceito difícil, uma ressalva e um exemplo realista, em vez da introdução mais simples. Revise o documento no formato pretendido e resolva questões de terminologia e aprofundamento das explicações logo no início. Uma amostra ajuda a estabelecer o processo e as expectativas, mas não substitui a revisão de diferentes conceitos em outras etapas do projeto.
Defina antecipadamente os critérios de aceitação, como: garantir que o significado e as condições sejam preservados; que a terminologia aprovada seja usada adequadamente; que os elementos técnicos protegidos permaneçam intactos; que as referências cruzadas levem ao material pretendido; e que o layout entregue permaneça legível. Registre as questões técnicas e suas respectivas soluções. Caso um problema não possa ser resolvido antes da entrega, documente-o para consideração futura, em vez de interpretar a ausência de comentários como aprovação técnica.
Utilize um registro de comentários compartilhado que identifique o idioma, o trecho, o problema, a correção proposta e o responsável pela decisão. Separe uma correção técnica de uma preferência estilística para que a equipe entenda quais trechos podem ser afetados. Quando os revisores discordarem, resolva primeiro a definição subjacente ou a expectativa do público. A substituição repetida de palavras sem resolver o problema central pode produzir revisões inconsistentes entre os idiomas.
Como especificar os arquivos entregáveis e viabilizar a manutenção deles
O resultado pode ser a tradução de documentos originais, conteúdo de ajuda localizado, texto editado com controle de alterações, um registro terminológico ou arquivos de publicação revisados. Indique quais destes são obrigatórios e como serão utilizados. Um PDF finalizado não oferece as mesmas opções de manutenção que um pacote com arquivos originais editáveis. Da mesma forma, o texto aprovado ainda precisa ser implementado se o destino for um site de documentação.
O cronograma de entrega depende de mais fatores do que apenas a contagem de palavras. Uma breve explicação de um conceito exclusivo do produto pode exigir várias decisões do cliente, enquanto um trecho mais longo sobre um assunto conhecido pode ser simples de traduzir. Múltiplas versões para diferentes públicos, diagramas complexos, arquivos fragmentados e disponibilidade limitada de revisores podem aumentar o tempo de coordenação. Compartilhe amostras representativas e identifique as dependências de aprovação, para que a avaliação do tempo reflita o trabalho necessário para produzir material multilíngue de qualidade.
Após a aprovação, registre as dependências, a revisão do material original, as decisões terminológicas e as respostas técnicas relevantes junto com os arquivos entregues. Quando uma funcionalidade for alterada, identifique quais explicações e versões para o público dependem dela. Uma definição atualizada pode afetar uma visão geral, um guia e um diagrama, mesmo que utilizem uma redação diferente. Reutilize traduções anteriores quando apropriado, mas verifique se elas ainda se aplicam à nova versão.
Na etapa de entrega, diferencie os arquivos aprovados para publicação das cópias de referência e dos rascunhos não finalizados. Inclua o registro da terminologia acordada e quaisquer exceções autorizadas. Isso ajuda a equipe editorial a implementar a versão pretendida e fornece aos futuros tradutores o raciocínio por trás de escolhas que, de outra forma, poderiam parecer sem importância.
Perguntas frequentes
Devemos remover os termos técnicos para leitores da área de negócios?
Inclua os termos que os leitores precisam reconhecer, mas explique-os com a profundidade adequada. Remover um termo pode dificultar a conexão entre uma visão geral e uma proposta ou referência de produto. O cliente deve aprovar quais detalhes podem ser simplificados e quais condições devem ser mantidas. A clareza depende da explicação, e não simplesmente do uso de menos palavras técnicas.
E se não houver tradução existente para um novo conceito?
Forneça uma definição aprovada e exemplos, e em seguida solicite opções de terminologia com suas respectivas justificativas. O revisor do cliente pode aprovar uma preferência terminológica, optar por manter o termo no idioma original ou usar uma frase explicativa adequada ao público-alvo. Registre a decisão e suas limitações. Evite apresentar uma nova expressão não aprovada como um padrão estabelecido do setor.
Uma única tradução pode servir tanto para administradores quanto para usuários finais?
Às vezes, se o original for deliberadamente estruturado para ambos os grupos e separar claramente as suas necessidades. Caso contrário, definam versões ou seções distintas. A tradução não deve omitir detalhes do administrador nem adicionar instruções para o usuário final. Essas são decisões de conteúdo que exigem um escopo de adaptação aprovado e um revisor que entenda o público-alvo.
Como planejar conteúdos multilíngues claros com a Terralíngua
A Terralíngua traduz material técnico e científico utilizando especialistas no assunto, referências de clientes e terminologia acordada, e também localiza documentação de software, como guias do usuário e conteúdo de ajuda. Para tecnologias complexas, recomenda-se uma discussão para analisar como a tradução e a documentação funcionarão em conjunto com eventuais edições ou adaptações para o público-alvo. Confirme quaisquer tarefas adicionais no escopo solicitado, incluindo a validação técnica. Note que a aprovação das alegações relativas ao produto ou à segurança permanecerá a cargo do cliente.
Comece com um documento representativo, referências técnicas aprovadas e uma definição de cada grupo de leitores. Inclua a versão original, os idiomas-alvo, os formatos exigidos, as expectativas editoriais, os revisores disponíveis e o prazo. Essas informações fornecem à Terralíngua uma base prática para avaliar o trabalho linguístico e identificar questões que devem ser resolvidas antes do início da produção.
Converse sobre tradução técnica e científica com a Terralíngua
Conheça os serviços de localização de software e tecnologia da Terralíngua