Uma atualização de software altera apenas algumas linhas da documentação do cliente e, ainda assim, gera um problema relevante de tradução. A correção se aplica a todas as instalações ou apenas a uma versão específica? Essa funcionalidade já está disponível, está sendo implementada gradualmente ou ainda é uma versão prévia? O artigo de suporte descreve a interface antiga ou a que o cliente verá após a atualização?
Notas de versão e artigos de suporte traduzidos exigem mais do que uma redação fluida. É preciso preservar as limitações descritas com precisão, usar a terminologia reconhecida do produto e manter uma relação clara com a versão do software. Para as empresas que publicam atualizações recorrentes, a tradução de TI e a edição em língua nativa devem trabalhar a partir de um conjunto de conteúdo controlado, com um método de revisão adequado à importância de cada alteração.
Como diferenciar o materiais entre notas de versão e artigos de suporte
As notas de versão informam aos leitores o que mudou e se eles precisam fazer algo. Um artigo de suporte explica como concluir uma tarefa, diagnosticar um problema ou aplicar uma solução alternativa aprovada. Embora possam se referir à mesma mudança, esses materiais atendem a necessidades diferentes. Traduzir um não atualiza automaticamente o outro.
Inclua títulos e resumos no escopo, não apenas o texto principal. O título do suporte pode conter o sintoma que os clientes reconhecem, enquanto um resumo da versão pode ser reutilizado em um e-mail ou notificação. Identifique o conteúdo reutilizado em todas as áreas e estabeleça limites de caracteres. Caso contrário, o artigo pode estar atualizado corretamente, enquanto uma descrição mais curta, porém ainda visível, pode conter informações desatualizadas ou inconsistentes.
Mapeie cada item de versão para o material voltado ao cliente que foi afetado. Um comando renomeado pode exigir alterações no procedimento de solução de problemas, capturas de tela e links relacionados. Um problema resolvido pode exigir uma ressalva em uma solução alternativa antiga em vez da exclusão completa do artigo, pois os clientes que utilizam uma versão anterior ainda podem precisar das instruções. Pergunte ao responsável pelo produto quais versões ainda estão dentro do escopo.
Construa o pacote de localização em torno da relação necessária. Inclua as notas de lançamento, as seções de suporte afetadas, as alterações de terminologia aprovadas e o contexto relevante do produto. Isso mantém o trabalho centrado no impacto do conteúdo da publicação, em vez de enviar traduções de frases isoladas, cujo significado depende de informações externas.
Como preparar o conteúdo essencial para o cliente antes da tradução
As atualizações internas geralmente pressupõem conhecimento compartilhado. Um tíquete intitulado "tentativa de correção por trás de um sinalizador" pode ser suficiente para os desenvolvedores, mas deixa os usuários sem as condições, o efeito ou a ação necessária. Antes da tradução, peça ao responsável que transforme a linguagem abreviada interna em uma explicação aprovada para o público-alvo.
Certifique-se de que os tradutores saibam quais materiais são para referência e quais estão dentro do escopo da tradução para publicação. Discussões internas sobre problemas podem ajudar a esclarecer uma alteração, mas podem conter causas ainda não confirmadas, detalhes específicos de clientes ou planos ainda não finalizados. Identifique claramente quais são as informações de contexto e forneça o material aprovado para o público. Os tradutores não devem decidir quais comentários técnicos a empresa pretende divulgar aos clientes.
A geração automática de notas de versão também requer seleção editorial. O GitHub, por exemplo, documenta as notas com base em pull requests incorporados ao projeto e em outras informações sobre a versão, além de incluir uma etapa de revisão antes da publicação. Isso pode ajudar a estabelecer um ponto de partida, mas é o responsável pelo conteúdo quem precisa decidir o que é adequado para o usuário final pretendido.
Documentação do GitHub sobre como revisar notas de versão geradas automaticamente
O texto original deve responder estas quatro perguntas: O que mudou? Quem foi afetado? Em quais condições? O que o leitor deve fazer? Nem todas as notas precisam de quatro frases separadas, mas a falta de respostas deve ser levada em consideração. Fornecer um texto original claro evita que a tradução se torne uma tarefa não planejada de investigação do produto.
Como preservar os termos que limitam as afirmações
Expressões curtas podem ser essenciais para preservar o sentido. Palavras como "pode", "apenas", "antes" e "depois" determinam se uma instrução é opcional, restrita ou obrigatória. Uma tradução mais fluida, porém que amplia o escopo da afirmação, não é uma melhoria. Analise essas relações explicitamente, especialmente em correções, limitações e avisos de migração.
Imagine este texto: “Na versão 5.4, os administradores podem tentar refazer as exportações com falha, sem precisar criar uma nova solicitação de exportação.” Uma versão abreviada como "As exportações não falham mais" introduziria uma garantia que o original nunca ofereceu. A revisão precisa preservar a versão, a função de usuário permitida, a ação disponível e a condição sob a qual a ação é relevante.
Da mesma forma, “reduz a probabilidade de ocorrer um tempo limite” não equivale a “impede que ocorram tempos limite”. Uma funcionalidade que está "disponível para contas selecionadas" não está disponível para todos. Quando o texto original for ambíguo, busque esclarecimentos com o responsável pelo produto em vez de esperar que o tradutor resolva o problema escolhendo a tradução que soe mais confiante.
As diretrizes globais de escrita da Microsoft recomendam estruturar as frases de forma simples e usar com cuidado modificadores como “apenas”. Aplique essa disciplina ao conteúdo original antes da tradução. Mantenha a condição próxima ao comportamento que ela se aplica e use o mesmo termo de forma consistente para cada recurso.
Orientações da Microsoft sobre como escrever conteúdo para tradução
Como especificar as referências à versão e à disponibilidade
Considere os identificadores de versão como dados do produto. Mantenha o formato exato, a menos que o responsável forneça uma versão diferente e aprovada. Um identificador de software como 5.4.0 não deve ser reformatado como um número decimal comum. Não considere a compatibilidade ou o tamanho da revisão apenas com base no número; utilize a aplicabilidade declarada pela equipe do produto.
Registre a plataforma, edição, canal de distribuição e restrições de implementação relevantes quando as instruções forem afetadas. Uma correção para desktop pode não incluir o aplicativo web. Uma funcionalidade pode depender de uma configuração de administrador ou de uma assinatura. Incorpore essas distinções no conteúdo traduzido, em vez de tratá-las como detalhes opcionais de contexto.
Substitua as expressões vagas sobre tempo no conteúdo original aprovado sempre que possível. A expressão “a partir de amanhã” fica confusa quando uma tradução é publicada posteriormente. Uma data específica, com fuso horário quando necessário, é mais fácil de manter. A data de lançamento do produto deve ficar separada da data de tradução ou revisão do artigo para que os leitores não confundam uma atualização editorial com uma nova versão do software.
Mantenha a distinção entre funcionalidades obsoletas, desativadas e removidas. Um aviso de descontinuação não significa necessariamente que o recurso deixou de funcionar. Solicite ao responsável que especifique o comportamento atual, a ação recomendada e qualquer prazo aprovado. A equipe de tradução deve seguir as políticas estabelecidas, e não inventar um cronograma de remoção ou uma promessa de migração.
Como estabelecer termos de produto consistentes
Forneça ao seu parceiro de tradução uma lista de terminologia que diferencie nomes de produtos, nomes de recursos, rótulos de interface e textos descritivos comuns. Estabeleça quais nomes permanecem inalterados (não traduza, “DNT”) e quais possuem uma forma aprovada no idioma-alvo. Uma versão pode introduzir um novo nome de recurso antes que toda a documentação relacionada tenha sido atualizada. Forneça aos revisores diretrizes para decisão definitivas em relação aos termos, em vez de pedir que eles deduzam os conceitos a partir de páginas mais antigas.
Para procedimentos de suporte, o rótulo deve ajudar os leitores a encontrar o controle na interface do usuário. Se a interface do aplicativo estiver traduzida, forneça os rótulos aprovados no idioma de destino para essa versão. Caso a interface permaneça no idioma de origem, defina como o artigo deve referenciar esses rótulos ao explicar o procedimento no idioma-alvo.
Mantenha as strings executáveis ou pesquisáveis separadas do conteúdo explicativo. Comandos, chaves de configuração, caminhos de arquivos, identificadores de API e códigos de erro podem precisar ser preservados com exatidão. Defina regras para os comentários ou valores de exemplo que acompanham o código, em vez de aplicar uma instrução genérica para traduzir tudo dentro de um exemplo de código. Uma alteração que melhora uma frase pode quebrar um comando.
As mensagens de erro merecem atenção especial. Se os usuários pesquisarem pela mensagem exibida, o artigo deverá usar a terminologia adequada do produto, com uma explicação quando necessário. Não crie uma tradução profissional de uma mensagem de erro como se fosse a experiência da interface do usuário se o software exibe algo diferente.
Como enviar alterações com contexto suficiente
Uma publicação periódica nem sempre exige a tradução repetida de todos os artigos. É necessário identificar o que mudou e fornecer contexto suficiente para avaliar a mudança. Forneça identificadores estáveis para artigos e seções, a revisão aprovada do conteúdo original e a tradução aprovada anteriormente, quando disponível. Marque claramente o que foi adicionado, editado, excluído e movido.
Inclua o texto circundante e capturas de tela relevantes com os trechos afetados. Um título revisado pode alterar o significado de um parágrafo que, de outra forma, permaneceria inalterado abaixo dele. Um aviso movido pode agora reger um conjunto diferente de etapas. Analisar apenas as palavras destacadas pode levar à perda desses efeitos, mesmo quando a tradução dessas palavras estiver correta.
Reutilize traduções aprovadas, mas atente-se ao contexto. A memória de tradução armazena segmentos do texto de origem e suas traduções para possível reutilização. Uma correspondência próxima é uma referência útil, não uma prova de que o novo conteúdo tenha o mesmo significado. Garanta a verificação de alterações em números, palavras de negação, permissões e escopo do produto, mesmo quando a maior parte de uma frase se repete.
Defina uma data limite para alterações no conteúdo original em cada lote de entrega e um procedimento para lidar com mudanças posteriores. Caso a equipe de produto altere o original durante a revisão, identifique as passagens e os idiomas afetados. Evite substituir o arquivo que os tradutores estão usando sem aviso prévio. Um pequeno registro de revisões costuma ser mais útil do que vários anexos, todos nomeados como "final".
Como escolher o fluxo de trabalho de acordo com o conteúdo e as necessidades de revisão
A tradução humana com revisão e a tradução assistida por IA com pós-edição humana são abordagens de produção diferentes. Selecione entre as opções disponíveis usando o material, o par de idiomas, a terminologia e o escopo de revisão necessário. O volume recorrente, por si só, não é motivo suficiente para se utilizar um processo de revisão menos intensivo.
Para compor uma amostra representativa, inclua uma nota sobre um recurso de uso comum, um trecho de solução de problemas e uma alteração que envolva limitações importantes. Avalie se o fluxo de trabalho proposto preserva as condições, os identificadores e o tom, e quanta correção o rascunho requer. Isso fornece uma base mais útil para discussão do que presumir que textos curtos relacionados a software sejam fáceis de traduzir.
Instruções direcionadas ao cliente sobre acesso à conta, tratamento de dados ou ações irreversíveis exigem atenção especial. O responsável pelo produto deve identificar as consequências de um possível mal-entendido e aprovar o conteúdo técnico. A revisão em língua nativa pode melhorar a clareza e a naturalidade, mas não garante que um procedimento funcione ou que o produto se comporte conforme descrito.
Caso seja proposta uma edição limitada para uma atualização interna, defina o que está ou não incluído, bem como a forma como o resultado poderá ser utilizado. Uma versão preliminar criada para distribuição interna não deve se tornar automaticamente uma orientação de apoio público. Reavalie as necessidades de revisão ou reformulação antes de alterar o público-alvo ou o status de publicação.
Confirme as ferramentas permitidas e os procedimentos para manuseio do material não liberado antes do início do processamento. Forneça apenas o conteúdo de referência necessário para a tradução e remova as informações específicas do cliente quando não forem necessárias. Essas decisões pertencem ao escopo de trabalho acordado. Não presuma que todas as opções com assistência de IA utilizam as mesmas configurações ou arranjos de dados.
Solicite que o orçamento inclua a separação de conteúdo novo, a revisão do conteúdo existente, a edição e qualquer revisão inicial. Lotes pequenos e frequentes exigem uma coordenação considerável, mesmo quando o número de palavras é baixo. O número de idiomas, a estabilidade do original, o volume de esclarecimentos solicitados e a disponibilidade de revisores afetam o esforço. Alinhe como as correções urgentes e os acréscimos posteriores serão tratados e precificados.
Como revisar a mensagem final
Planeje duas verificações complementares: uma revisão linguística, comparando a tradução com o original aprovado, e uma revisão do produto por alguém autorizado a confirmar o comportamento dele. Forneça aos avaliadores de produtos perguntas específicas sobre aplicabilidade, etapas e terminologia. Solicite correções relacionadas aos identificadores de artigo e seção para auxiliar o linguista, de modo que o revisor linguístico possa resolvê-las de forma consistente, em vez de receber reescritas conflitantes.
Consulte a pré-visualização localizada na central de ajuda ou no modelo de publicação. Verifique títulos, listas, avisos, capturas de tela, links e formatação de código. Uma tradução pode estar correta no arquivo entregue, mas aparecer sob o título errado ou perder o estilo de aviso após a importação. Quando fizer parte do escopo acordado, a revisão na língua materna deve incluir o resultado visível.
Forneça capturas de tela ou acesso controlado ao produto que corresponda à versão documentada. Ao verificar uma versão anterior, um revisor pode sinalizar o rótulo correto da nova versão como um erro. Ao enviar feedback, registre a versão de referência usada para validação e diferencie as preferências de idioma das discrepâncias confirmadas do produto.
Use um mapa de links para identificar os destinos dos links de suporte traduzidos. Confirme se cada link deve direcionar para um artigo traduzido, uma página aprovada no idioma original ou uma referência específica de determinada versão. O fato de o texto de um link estar traduzido não significa que a página de destino também tenha sido traduzida. Verifique se o destino existe e é aplicável à versão relevante antes do lançamento.
- Significado: preserve a alteração, o público afetado, as condições e a ação necessária sem adicionar reivindicações.
- Referências do produto: verifique a correspondência entre nomes, identificadores, rótulos de interface e limites de versão aprovados.
- Estrutura: mantenha a ordem das etapas, os avisos, os exemplos e a relação entre os títulos e o conteúdo.
- Apresentação: verifique a página renderizada, os links, as capturas de tela e as strings técnicas protegidas.
- Aprovação da versão: confirme a revisão correta do original e registre a decisão de publicação do responsável para cada idioma.
Como controlar as atualizações e as correções de publicações
Defina a transição entre o trabalho linguístico da tradução e a editoração eletrônica. O material entregue deve identificar o artigo, a variante linguística, a revisão do original, o status da revisão e quaisquer questões não resolvidas. Confirme o formato necessário com a equipe receptora. Um arquivo de tradução aprovado não comprova que ele foi carregado, visualizado ou tornado público.
Para lançamentos por etapas em diferentes idiomas, registre qual versão cada artigo publicado representa. Decida quem autoriza a publicação caso o original seja alterado antes que todos os idiomas estejam prontos. A solução pode ser atualizar as traduções afetadas, suspender o lançamento ou publicar uma versão com escopo específico. Essa é uma decisão do responsável pelo conteúdo, não algo que o tradutor deva presumir com base no prazo.
Quando for necessária uma correção, identifique todos os idiomas afetados e o conteúdo relacionado, incluindo trechos reutilizados. Mantenha a correção vinculada à sua justificativa e à redação aprovada. Para soluções alternativas antigas, registre se elas ainda são válidas para versões anteriores antes de removê-las. Isso preserva o histórico de suporte útil e evita instruções conflitantes para os usuários atuais.
Quando a tradução estiver pronta para publicação, encaminhe os comentários linguísticos relevantes para atualização dos registros mantidos de conteúdo-fonte, terminologia ou traduções aprovadas, conforme apropriado. Corrigir apenas a página em funcionamento pode fazer com que o próximo pacote de atualização mantenha a redação antiga. Defina quem são os responsáveis por esses registros e como as correções serão inseridas no próximo lote.
Como a Terralíngua auxilia a gestão de atualizações recorrentes
A Terralíngua oferece tradução profissional de TI e documentação de software, conhecimento especializado no idioma nativo e opções de fluxo de trabalho com tradução humana ou assistida por IA. Nossa experiência comprovada garante precisão e clareza na tradução contínua de notas de versão e conteúdos de suporte técnico. A Terralíngua pode fornecer um orçamento de tradução e revisão a partir de material representativo, caso a documentação final não esteja disponível.
Basta fornecer uma amostra da nota de versão com o artigo de suporte relacionado e as referências terminológicas. Avalie suas necessidades de edição em idioma nativo, responsabilidades de revisão de produtos, formatos de entrega e padrões de atualização esperados. Um processo recorrente pode ser organizado com trocas de arquivos e pontos de revisão previamente acordados. Importante: a integração com sistemas de publicação ou ferramentas de localização contínua não deve ser presumida, mas pode ser discutida.
Conheça a experiência em tradução técnica e de TI da Terralíngua
Analise as opções de fluxo de trabalho humano e assistido por IA da Terralíngua
Perguntas frequentes
Podemos enviar apenas as linhas que foram alteradas?
Você pode identificar essas linhas como sendo o escopo da tradução, mas inclua o conteúdo circundante, a revisão do original e a tradução previamente aprovada. Os revisores precisam verificar se um título, uma condição ou um parágrafo movido altera o seu significado. Defina quais verificações contextuais devem ser incluídas, mas não presuma que um texto inalterado não precisa de atenção.
Devemos traduzir os títulos dos tíquetes internos?
Somente se forem adequados ao público-alvo e aprovados para esse uso. As atualizações voltadas para o cliente geralmente precisam de uma explicação sobre o efeito e a aplicabilidade, e não de abreviações técnicas sem contexto. Solicite ao responsável pelo conteúdo que prepare ou aprove o conteúdo original público antes da tradução, mantendo o contexto interno claramente identificado como referência.
O que acontece quando o nome de uma funcionalidade muda no meio do lançamento?
Determine a decisão de nomenclatura aprovada e identifique os conteúdos afetados, como notas, seções de suporte, capturas de tela e versões de idioma. Confirme qual nome aparece na interface atual. Atualize a memória de tradução, o glossário, o guia de estilo e a referência terminológica. Compare as entregas em andamento com a nova versão, para que uma tradução mais antiga não reintroduza o nome anterior.
O provedor de tradução pode publicar as atualizações automaticamente?
A entrega da tradução e a publicação são responsabilidades distintas, a menos que um acordo específico seja estabelecido. Confirme o formato do arquivo, o método de importação, as verificações de pré-visualização e o responsável pela publicação. Não presuma que um serviço de tradução inclua acesso à sua central de ajuda ou uma conexão automatizada ao seu processo de lançamento.
Comece com um conteúdo representativo
Para discutir um projeto com a Terralíngua, compartilhe uma amostra da nota de versão, um artigo de suporte afetado, os idiomas de destino, o contexto do produto e da versão, a terminologia e o cronograma de lançamento previsto. É útil incluir o original e os formatos de entrega, além de identificar o revisor do produto antes da aprovação do trabalho. Essas informações contribuem para uma discussão prática sobre tradução, edição na língua nativa e seleção de fluxo de trabalho antes da preparação do próximo lote.
Solicite um orçamento para notas de versão de software e conteúdo de suporte