Uma mensagem de erro chega ao usuário em um momento difícil: um arquivo não carrega, um formulário não é enviado ou uma operação é interrompida inesperadamente. Em outro idioma, a mensagem ainda precisa explicar o problema e oferecer uma próxima etapa adequada. Traduzir as palavras com precisão é apenas parte da tarefa. As orientações também devem corresponder ao que o software sabe, ao que o usuário pode fazer e ao que o aplicativo fará em seguida.
O design da linguagem de mensagens de erro reúne essas decisões. Para os gestores de localização e equipes de produto, isso significa fornecer aos tradutores contexto suficiente para preservar a intenção, ao mesmo tempo que torna a redação natural e prática. A Terralíngua oferece serviços de localização de interface de software e tradução de documentação técnica, incluindo notificações, conteúdo de ajuda e instruções de solução de problemas. No entanto, os desenvolvedores e proprietários do produto ainda mantêm a responsabilidade pelo comportamento descrito pela linguagem traduzida.
Serviços de localização de software e tecnologia da Terralíngua
Como iniciar o design da mensagem de erro com o estado do produto
Antes de discutir o tom ou a extensão das frases, estabeleça o que aconteceu. A solicitação foi rejeitada antes do processamento, parcialmente concluída ou concluída sem que a confirmação chegasse ao usuário? O aplicativo sabe a causa, ou apenas que a operação não foi concluída? Essas distinções afetam se a recomendação da mensagem deve ser a de editar uma entrada, verificar um resultado, aguardar ou entrar em contato com o suporte.
A mensagem "tente de novo" só é útil quando tentar novamente é uma ação aprovada. Ela não deve ser adicionada como um final amigável a todas as mensagens de erro. Um tradutor não consegue determinar, a partir de uma string isolada, se uma nova tentativa pode criar uma solicitação duplicada ou se as alterações do usuário foram preservadas. A equipe de desenvolvimento deve fornecer esses dados e aprovar qualquer alteração proposta na redação da cláusula de recuperação.
Classifique as mensagens de acordo com a decisão que elas apoiam. A ausência de um campo obrigatório exige um tratamento linguístico diferente devido a uma restrição de permissão ou à indisponibilidade do serviço. Uma notificação sobre uma operação ainda em andamento não deve soar como uma confirmação de falha. Descreva o gatilho, o resultado conhecido e a próxima etapa permitida no resumo da fonte, para que cada idioma parta do mesmo entendimento.
Como dar aos tradutores mais do que um simples arquivo de exportação de texto
Um arquivo de texto exportado preserva o texto a ser traduzido, mas raramente explica toda a interação. Adicione contexto que conecte cada mensagem à sua respectiva tela e à ação do usuário. Capturas de tela, gravações curtas ou acesso a uma versão de referência podem mostrar se o texto aparece ao lado de um campo, em uma caixa de diálogo ou em uma notificação temporária. Também é útil identificar a versão relevante do produto e o público-alvo pretendido para o processo de localização.
- Chave de recurso estável e texto fonte, com o gatilho e a finalidade da mensagem.
- Captura de tela ou referência à tela, incluindo rótulos próximos e ações disponíveis.
- Definições e valores de exemplo para variáveis, além de proteção a códigos de erro e sintaxe de formatação.
- Limitações conhecidas quanto ao comprimento, linhas ou tempo de exibição, distinguindo limitações técnicas de preferências.
- Instruções de recuperação aprovadas, destino da ajuda e quaisquer requisitos de acesso.
- Pessoa de contato do produto que pode esclarecer dúvidas sobre o comportamento e aprovar revisões do texto original.
Explique se uma mensagem é compartilhada entre várias situações. Reutilizar o texto pode parecer eficiente, mas uma frase idêntica em inglês, por exemplo, pode exigir uma gramática diferente ou um outro rótulo de ação em outro lugar. Se uma mensagem compartilhada não funcionar corretamente em todos os contextos, o tradutor deverá comunicar o conflito ao responsável pelo conteúdo do produto do cliente. A equipe de produto decide então se deve separar os recursos ou revisar a interação. A localização também não deve alterar o significado da interação para que ela caiba na tela.
Como separar o problema e a próxima etapa
Uma mensagem de erro útil informa ao leitor o que não funcionou e, quando conhecido e apropriado, como proceder. Evite traduzir terminologia interna como uma ação. A mensagem “Falha na validação” identifica um evento de software, mas pode não explicar qual entrada precisa de atenção. Uma instrução específica sobre o campo afetado é mais útil quando o aplicativo consegue identificar o problema de forma confiável.
Por exemplo, considere um formulário de upload de arquivos que aceite apenas PDFs. Em vez de “Formato inválido”, uma mensagem de origem aprovada poderia exibir: “Escolha um arquivo PDF para fazer o upload”. Essa formulação é apropriada porque explica a falha em relação ao tipo de arquivo. No entanto, se o problema for a indisponibilidade do serviço de upload, a mesma instrução direcionaria os usuários para uma correção que não resolveria o problema.
A explicação do World Wide Web Consortium (W3C) sobre o critério 2.2 das Diretrizes de Acessibilidade para Conteúdo Web (WCAG), seção 3.3.3, aborda os erros de entrada detectados automaticamente. A recomendação é que sejam fornecidas sugestões de correção conhecidas, a menos que elas comprometam a segurança ou a finalidade do conteúdo. Este é um critério específico de acessibilidade, não uma regra para divulgar todas as causas técnicas. Os responsáveis pelo produto e pela segurança devem decidir quais detalhes de recuperação podem ser exibidos; e os tradutores devem preservar esse limite aprovado.
Orientações da W3C sobre sugestões de correção de erros
Mantenha a ação próxima ao problema, sempre que a interface o permitir. Quando um botão abre o seletor de arquivos, a etiqueta “Escolher um arquivo” é mais clara do que “OK”. O rótulo, a mensagem e a ação implementada devem ser iguais em cada idioma. Não interprete um botão de confirmação como um comando de recuperação quando sua única função é fechar a caixa de diálogo.
Como manter os identificadores de erro estáveis e as explicações legíveis
Diferencie a chave de recurso usada pelos desenvolvedores, o código de erro exibido aos usuários ou ao suporte e a explicação destinada ao leitor. Esses itens servem a propósitos diferentes. Proteja as chaves de recursos e os identificadores de diagnóstico aprovados durante o processo de tradução. Traduza a explicação e os rótulos ao redor, quando necessário, mantendo o código exato que corresponde ao que as instruções esperam.
Neste exemplo, “Código de referência: "UP-204" pode vir acompanhado de uma explicação localizada. O rótulo pode mudar de idioma; porém, UP-204 deve permanecer inalterado de acordo com as regras acordadas. Preserve as maiúsculas e minúsculas, a pontuação e os dígitos. Caso seja possível incluir um código em uma solicitação de suporte, os desenvolvedores devem verificar se a interação ainda copia o identificador pretendido, em vez de adicionar texto traduzido extra.
Um código por si só não explica o que os usuários devem fazer. Por outro lado, substituir um código por um texto abreviado pode eliminar a informação necessária para o suporte. Alinhe quais identificadores são visíveis para o usuário e onde eles aparecem. Os desenvolvedores também decidem qual conteúdo diagnóstico é apropriado para o público-alvo. Observe que os tradutores não devem expor detalhes internos nem inventar explicações para códigos desconhecidos.
Como tratar as variáveis como parte da mensagem
As variáveis podem inserir conteúdo dinâmico no projeto, como referências a arquivos, valores numéricos ou limites de tamanho. Documente as restrições e os aspectos a serem considerados em relação aos marcadores de posição (placeholders), incluindo a formatação. Proteja a sintaxe necessária, mas permita que a ordem das palavras siga as convenções do idioma-alvo, sempre que o formato da mensagem o suportar. A documentação do International Components for Unicode (ICU) recomenda a tradução de mensagens completas em vez de fragmentos, para que os tradutores possam organizar os elementos variáveis em frases naturais.
O tratamento do plural também requer considerações sobre o estilo da linguagem antes da implementação. O ICU descreve a seleção de variantes de mensagens conforme as regras de plural do idioma. O par singular-plural do inglês não é um modelo universal para todos os idiomas. Confirme o formato suportado pelo aplicativo e forneça mensagens completas para os casos exigidos. Os desenvolvedores devem validar os recursos resultantes no aplicativo de formato de mensagem real.
Documentação do Unicode ICU sobre formatação de mensagens traduzíveis
Considere este exemplo de mensagem sobre limite de tamanho: "Escolha um arquivo menor que {limit}". Ela é ambígua até que a equipe explique se {limit} contém um número, um tamanho formatado com sua unidade ou algo mais. Confirme se o limite inclui todo o conteúdo. Traduzir “menor que” como “até” poderia alterar a regra estabelecida. O responsável pelo produto deve confirmar o significado original antes que o texto seja traduzido para outros idiomas.
Utilize valores de amostra representativos durante a revisão. Um nome de arquivo curto pode ser adequado, enquanto um nome longo obscurece o texto da ação. Uma variável pode estar vazia, conter pontuação ou misturar instruções de escrita com o texto circundante. A equipe linguística pode identificar problemas de legibilidade; os desenvolvedores controlam a renderização, o escape e o comportamento do layout. Não resolva um problema técnico excluindo o marcador necessário da tradução, pois isso pode afetar a funcionalidade.
Como usar um tom profissional
Exponha o problema de forma clara e evite atribuir a culpa ao erro do leitor. “Informe a data no formato indicado” é mais útil do que simplesmente dizer “A data informada está incorreta”, desde que o formato esperado esteja claro. Um breve pedido de desculpas pode ser suficiente para corrigir uma falha no serviço, mas desculpas repetidas não devem ofuscar a ação correta. O humor e as expressões idiomáticas podem ser especialmente inadequados quando os usuários estão preocupados com perder o trabalho feito.
Forneça aos tradutores um guia de estilo e tom que permita uma linguagem local natural, em vez de exigir padrões de frases literais. Explique o nível de familiaridade técnica do público e o nível de formalidade esperado. As convenções de cortesia podem variar, mas os fatos essenciais devem permanecer os mesmos: o que aconteceu, o que se sabe sobre o resultado e qual ação está disponível. Um tom ameno não deve atenuar uma restrição necessária nem exagerar a severidade de uma correção menor.
Considere as mensagens tranquilizadoras como afirmações factuais. Afirmações como “As alterações foram salvas”, “Nenhum pagamento foi efetuado” e “Isso levará apenas alguns instantes” precisam ser confirmadas pelo produto. Caso o sistema não consiga determinar o resultado, o original deve comunicar essa incerteza e orientar os usuários para o método aprovado de verificação. Os tradutores não devem acrescentar certeza simplesmente por soar mais reconfortante.
Como conectar mensagens às instruções de recuperação aprovadas
As orientações de recuperação localizadas podem ir além da própria mensagem. Uma notificação curta pode conter um link para um procedimento com capturas de tela ou várias etapas. Identifique o artigo aprovado exato e a versão do produto aplicável e, em seguida, confirme se existe um procedimento no idioma de destino. Não presuma que substituir o segmento de idioma em um URL resultará em um destino válido.
As instruções anexadas devem ser adequadas à situação que motivou a mensagem. Um usuário sem permissões de administrador pode não conseguir seguir um procedimento restrito a administradores. Se uma página de ajuda exigir login, verifique se alguém que esteja enfrentando um erro de login consegue acessá-la. Quando uma página localizada não estiver disponível, defina uma alternativa e explique no idioma-alvo, quando apropriado, em vez de sugerir que existe ajuda traduzida.
Traduza o artigo de recuperação utilizando a interface e a mensagem atuais, que estarão disponíveis como referência. Preserve a sequência de ações, as condições e as consequências estabelecidas. Se as instruções incluírem a remoção de dados ou a alteração de configurações, essas etapas precisam de aprovação do produto; a equipe linguística deve consultar os contatos corretos, e não simplificar uma condição que altere o resultado. Atribua a responsabilidade pela confirmação do conteúdo com verificação de links e procedimentos quando o produto for alterado.
Como revisar o contexto das notificações do software na interface
O contexto de notificação do software inclui o que os usuários estavam fazendo para receber uma mensagem e quanto dela eles podem visualizar em diferentes etapas. Uma caixa de diálogo estreita para dispositivos móveis, uma mensagem de validação embutida e uma notificação temporária para desktop proporcionam diferentes condições de leitura. Analise a tradução na apresentação pretendida, incluindo um texto mais extenso na língua de destino. Uma planilha pode mostrar a redação correta, ocultando ao mesmo tempo uma frase truncada ou uma ação que ficou fora da área de visualização.
A explicação do World Wide Web Consortium (W3C) sobre o critério 2.2 das Diretrizes de Acessibilidade para Conteúdo Web (WCAG), seção 3.3.1, afirma que os erros de entrada detectados automaticamente devem identificar o item afetado e descrever o erro em texto. Uma mudança de cor ou ícone por si só não substitui a descrição. Isso torna o texto traduzido importante, ao mesmo tempo que deixa a implementação e avaliação mais ampla de acessibilidade a cargo da equipe de produto.
Orientações da W3C sobre como identificar erros de entrada em texto
Inclua o uso do teclado e de tecnologias assistivas no plano de testes do cliente, sempre que relevante. Os linguistas podem revisar as palavras apresentadas ou anunciadas, mas uma tradução aprovada não garante que a notificação seja feita no momento certo ou associada ao campo correto. Da mesma forma, um texto legível da direita para a esquerda não prova que identificadores ou controles com leitura em direções mistas se comportem corretamente. Atribua essas verificações a testadores de produtos qualificados.
Como validar a mensagem e o caminho de recuperação em conjunto
Utilize uma matriz de revisão que conecte cada recurso a um cenário reproduzível. Registre o gatilho, a mensagem esperada, a ação disponível, as amostras de variáveis, o destino da ajuda e o revisor responsável. Priorize situações pouco claras ou com consequências significativas durante uma revisão inicial, ao mesmo tempo que define o processo de abrangência da revisão para o conjunto completo de mensagens. Algumas capturas de tela bem feitas não comprovam que todos os erros e estados foram verificados.
Como no nosso exemplo fictício de upload de PDF, o revisor deve provocar propositalmente uma rejeição do tipo de arquivo, ler as instruções traduzidas e testar a ação oferecida. Em seguida, simule um estado de serviço indisponível e confirme se ele produz a orientação correta e apropriada. Essa comparação testa a conexão entre linguagem e condição. Isso pode revelar um erro de mapeamento mesmo quando ambas as traduções, individualmente, estão corretas.
- Aceitação linguística: a redação preserva o significado aprovado, distingue incerteza e falha e oferece apenas ações autorizadas.
- Aceitação dos recursos: as chaves, códigos, marcadores de posição e sintaxe de formatação necessários são preservados e passam na validação do desenvolvedor.
- Aceitação da apresentação: o texto e as ações permanecem legíveis nas telas, idiomas e casos de variáveis representativas acordados.
- Aceitação da recuperação: o link de ação e ajuda leva ao resultado aprovado ou às instruções para a função do usuário e a versão do produto.
- Registro de aprovação: as dúvidas sobre o produto foram resolvidas e os responsáveis aprovaram a liberação do arquivo.
Mantenha a revisão linguística separada da aprovação funcional. Os tradutores devem registrar os problemas com uma chave de recurso, perguntas específicas sobre o idioma, capturas de tela relacionadas e uma explicação das dificuldades encontradas. Os desenvolvedores devem confirmar o comportamento e implementar as alterações. Em seguida, o responsável pelo produto do cliente deve resolver as divergências sobre a experiência pretendida. Caso a redação original seja alterada após a revisão, avalie quais versões linguísticas e documentos de recuperação também precisam ser revisados e confirmados.
Como planejar as entregas e o cronograma de revisão
Defina o escopo da tarefa considerando o conjunto completo da mensagem e seu contexto, e não apenas a contagem de palavras. Muitas sequências curtas podem exigir esclarecimentos substanciais. Variáveis, múltiplas condições de erro, ambientes de revisão restritos e destinos de ajuda não traduzidos afetam o esforço. Uma amostra representativa deve incluir mensagens complexas e suas respectivas telas, para que a linguagem necessária e as responsabilidades de teste possam ser discutidas antes da produção.
Alinhe os entregáveis finais, como o formato aprovado para arquivos de recursos localizados, artigos de recuperação traduzidos aprovados, decisões confirmadas sobre terminologia e tom, e um registro de consultas ou problemas. Inclua tempo na programação para respostas sobre o produto, integração e revisão contextualizada. Defina a versão atual do código-fonte e o processo de alteração aprovado. Observe que estes são controles de projeto propostos, e não uma afirmação de que a tradução por si só garante uma versão de software testada ou acessível.
Perguntas frequentes
Podemos traduzir as mensagens antes que as telas sejam finalizadas?
Sim, desde que a equipe forneça um contexto confiável e identifique os comportamentos não resolvidos. Utilize capturas de tela ou descrições provisórias e, depois, agende a revisão na interface implementada. Considere as alterações posteriores em ações, variáveis ou etapas de recuperação como possíveis alterações de tradução futuras a serem confirmadas, em vez de presumir que a redação original ainda se encaixará nos arquivos finais.
Cada erro deve incluir um link de suporte?
Não. Um erro de entrada direta pode precisar apenas de correção com uma instrução clara. Adicione um canal de suporte ou ajuda quando ele oferecer uma próxima etapa apropriada e verifique se o usuário afetado consegue acessá-lo. A equipe de produto deve aprovar o caminho de escalonamento.
E se o texto traduzido exceder o limite de caracteres?
Primeiro, confirme se o limite é tecnicamente imposto ou se é uma preferência de projeto. O linguista pode propor a aprovação de uma redação mais curta que preserve o significado. Caso as orientações essenciais não se ajustem após a modificação, a equipe de produto deve considerar a estrutura da apresentação ou da mensagem, em vez de remover a condição necessária.
Como preparar suas mensagens de erro para localização
Os serviços de localização de software com certificação ISO e de documentação técnica multilíngue da Terralíngua podem dar suporte a qualquer idioma que os usuários encontrem nas notificações do sistema e nas instruções relacionadas. A abordagem publicada utiliza o contexto do produto, referências de clientes e terminologia do setor. Durante a fase de orçamento, discutam juntos as strings de interface e o conteúdo de recuperação, além de designar os desenvolvedores responsáveis pela integração de recursos, comportamento do aplicativo e aprovação da versão.
Para avaliação, forneça uma exportação de recursos representativa, capturas de tela ou uma versão de referência, os idiomas-alvo necessários, as definições de espaços reservados e as instruções de recuperação aprovadas. Inclua a versão do produto, as restrições técnicas, o contato para revisão, os entregáveis necessários e o prazo. Com essas informações definidas, o trabalho de localização pode abordar as decisões do usuário em vez de traduzir uma mensagem de erro isoladamente.
Solicite um orçamento para localização de software e tradução de documentação técnica