Durante a localização de um software, é fácil negligenciar a relação da linguagem da interface com o manual correspondente. Por exemplo, se o nome de uma funcionalidade no menu for diferente do guia do usuário, pode ser difícil determinar se os dois termos se referem à mesma coisa. Um artigo de apoio pode apresentar um terceiro termo. Embora cada tradução pareça correta, a inconsistência da terminologia entre a interface do produto e a documentação pode dificultar a conclusão de uma tarefa simples. Para as equipes de produto, o desafio é garantir que os usuários vejam a mesma informação em todos os pontos de contato com a funcionalidade.
A localização de interfaces de software e a tradução de documentação técnica se beneficiam de um briefing compartilhado. Os serviços de tradução técnica da Terralíngua incluem interfaces de software, manuais do usuário, especificações técnicas e documentação de TI. Reunir todos os materiais relacionados em um único idioma ajuda a estabelecer uma terminologia consistente para os produtos e as instruções que dependem dela. A implementação de técnica e os testes funcionais devem ser definidos separadamente como um requisito do projeto, em vez de serem considerados parte do escopo linguístico.
A questão prática não é apenas quantas palavras precisam ser traduzidas. Trata-se de identificar a versão do produto à qual essas palavras se aplicam, o que os usuários localizados podem selecionar e quem aprova a relação entre a interface e o conteúdo de suporte. As etapas de preparação abaixo ajudam a transformar um conjunto de arquivos em um projeto de localização coerente.
Como mapear uma funcionalidade em todo o conteúdo
Comece pelo inventário das funcionalidades. Identifique os rótulos da interface, as mensagens de diálogo, os procedimentos do guia do usuário, as notas de versão e os artigos de suporte que descrevem a mesma função. Inclua as mensagens de boas-vindas e as instruções para download quando elas fizerem parte da versão planejada. Isso revela dependências que podem facilmente passar despercebidas nas solicitações separadas.
Por exemplo, em um aplicativo fictício de relatórios, uma funcionalidade chamada "Visualizações salvas" pode aparecer no menu de navegação, no guia de configuração e em artigos de solução de problemas. Se a tradução do menu for aprovada após a conclusão do guia, ele poderá citar para os usuários um termo que não existe mais. Estabelecer o nome da funcionalidade compartilhada comunica essa dependência antes do início da tradução.
Diferencie o conteúdo para diferentes públicos. Um guia de configuração para administradores tem mais detalhes técnicos do que os artigos de ajuda voltados ao usuário final, mas ambos devem usar o mesmo nome aprovado para a interface. Descreva o público-alvo e, quando relevante, as permissões necessárias para acessar a funcionalidade. Um revisor de localização não pode avaliar com precisão uma instrução sem saber se o leitor pretendido consegue acessar a tela descrita.
Como definir o escopo da versão e do idioma
Especifique a versão ou compilação do produto representada nos arquivos originais e nas telas de referência. Indique se a interface e a documentação serão lançadas em conjunto e identifique qualquer material que descreva intencionalmente uma versão anterior. Uma exportação das strings atuais combinada com capturas de tela desatualizadas não é um pacote de arquivo original confiável, a menos que as diferenças estejam documentadas.
Defina os idiomas de destino e as variantes regionais, incluindo se a própria interface estará disponível nesses idiomas. Um manual traduzido para um aplicativo disponível apenas em inglês precisa de uma abordagem clara para se referir aos controles da interface. Um aplicativo totalmente localizado precisa que a documentação corresponda à interface localizada aprovada. São atribuições com requisitos diferentes, mesmo quando a origem do manual é a mesma.
Defina uma autoridade terminológica quando várias versões de um produto coexistirem. Se um produto antigo usa um nome legado para a funcionalidade, simplesmente substituí-lo pelo termo mais recente pode tornar sua documentação imprecisa. Registre onde o texto antigo ainda é válido. Ter consistência significa preservar a relação correta com a versão relevante do produto, e não forçar todos os documentos antigos a usar o rótulo mais recente.
Como dar contexto suficiente às strings curtas
Uma string de interface é um trecho de texto gerenciado pelo aplicativo, como o rótulo de um botão ou uma mensagem de erro. Textos curtos podem ser difíceis de traduzir com precisão porque o contexto envolvido geralmente não consta no arquivo de tradução. "Open" pode ser uma instrução ou um status. "Archive" pode designar um destino ou uma ação que move um item para lá.
Forneça um identificador estável, uma descrição da função da string e uma captura de tela ou caminho de referência quando for útil. Explique o que acontece antes e depois da mensagem aparecer. Para mensagens de erro, identifique o problema e a ação de recuperação disponível no produto. A ausência de informações de apoio gera atrasos na tradução devido à necessidade de esclarecimentos ou, caso haja um prazo a cumprir, as traduções serão genéricas em vez de específicas para a ação ou funcionalidade.
Sempre que possível, forneça acesso a um ambiente de teste aprovado usando dados de amostra. Caso o acesso não esteja disponível, uma demonstração guiada gravada ou um documento de referência com anotações podem fornecer um contexto útil. Inclua ocorrências menos comuns, como resultados vazios, restrições de permissão e operações com falha. Uma mensagem importante para o usuário pode aparecer somente quando algo dá errado. Agendar reuniões regulares com a equipe de tradução e os responsáveis pelos materiais para compartilhar informações por videochamada pode ajudar a esclarecer dúvidas, inclusive sobre os itens a seguir.
- Vinculação de identificadores de string com texto original aprovado.
- Contexto da tela, do componente ou da funcionalidade em que a string aparece.
- Finalidade, público-alvo e comportamento relevante do produto.
- Captura de tela ou caminho de referência mostrando o conteúdo ao redor.
- Limites de comprimento, placeholders e restrições de formatação.
- Requisitos para uma seção relacionada do guia do usuário ou artigo de suporte, quando aplicável.
Como separar as restrições de idioma das limitações do produto
Informe ao fornecedor de serviços linguísticos quais limites são fixos e como eles são mensurados. O limite de caracteres em um campo do banco de dados é diferente de um botão estreito que pode ser redimensionado. Identifique se uma restrição diz respeito a caracteres, bytes, linhas ou espaço visível e se um engenheiro pode contorná-la. A expressão “manter o texto curto” não fornece informações suficientes para determinar como a tradução deve ser adaptada.
Não solicite que todas as strings traduzidas correspondam à contagem de caracteres do original. Os idiomas expressam a mesma ideia de maneiras diferentes, e a adequação visual depende da fonte, do layout e do tamanho do texto. Diferentes idiomas também podem precisar de mais ou de menos espaço para comunicar o mesmo conceito. Solicite uma linguagem concisa dentro das restrições informadas, mas forneça um alternativa para quando o espaço disponível impedir uma instrução clara. Abreviações não devem ser a solução padrão para um problema de layout sem explicação.
Esclareça os placeholders, que são valores inseridos pelo aplicativo no momento da execução, como um nome de arquivo ou de conta. Informe o significado, forneça valores de exemplo e especifique se eles podem ser reposicionados dentro da frase. Esclareça qual sintaxe deve permanecer inalterada. A equipe de engenharia deve confirmar o formato do arquivo e as convenções das mensagens, para evitar que a localização altere acidentalmente a sintaxe executável ou os identificadores de recursos.
Como sinalizar mensagens que precisam de decisões de engenharia
Alguns problemas de localização não podem ser resolvidos apenas pela escolha de palavras diferentes. Uma mensagem montada a partir de fragmentos separados pode seguir a ordem das palavras do idioma original e não soar natural em outra língua. O Consórcio World Wide Web (W3C) fornece orientações sobre internacionalização e os riscos de montar mensagens em linguagem natural a partir de fragmentos separados de texto. A resposta prática para um briefing de produto é sinalizar essas mensagens para que a engenharia revise, em vez de pedir aos tradutores que façam com que fragmentos incompatíveis sejam lidos naturalmente. Considere também os limites de caracteres e o comprimento das strings, reconhecendo que o tamanho do texto pode variar entre os idiomas.
Diretrizes do W3C sobre internacionalização e strings em linguagem natural
Mensagens envolvendo quantidade também precisam de uma estrutura correta. O Common Locale Data Repository (CLDR) da Unicode fornece regras e categorias de plural específicas para cada idioma, já que o par singular/plural do inglês não é um modelo universal para todas as línguas. Consulte a equipe de engenharia para saber qual sistema de mensagens e quais regras de localidade o produto utiliza e, em seguida, forneça aos tradutores as formas aceitas pelo sistema e dê contexto suficiente para uma tradução correta.
Diretrizes do CLDR da Unicode sobre regras de plural
O fornecedor pode identificar um problema linguístico, mas implementar o tratamento de plurais, alterar um layout ou modificar o comportamento no tempo de execução é uma responsabilidade à parte. Registre quem fará essas alterações e como as strings revisadas retornarão à equipe linguística para revisão. Não permita que uma limitação conhecida do produto seja confundida com um comentário de tradução não resolvido até o prazo de lançamento.
Como aprovar a terminologia antes de aplicá-la em todo o conteúdo
Um registro terminológico útil inclui mais do que apenas um termo no idioma original e sua tradução. Recomenda-se a criação de um glossário com a terminologia aprovada antes do início da tradução. Defina o conceito, identifique a área do produto relevante e registre o tradução aprovada do termo. Observe se o termo é um controle visível, o nome de uma funcionalidade ou uma explicação geral. Adicione palavras proibidas somente quando houver um motivo claro para evitá-las. Informe se há limitações de espaço para os termos traduzidos.
Identifique os nomes que devem permanecer inalterados, como marcas de produtos ou identificadores técnicos. Diferencie esses nomes da linguagem descritiva comum. Se o uso de maiúsculas ou abreviações for importante na interface, documente como isso deve ser tratado. Essas decisões ajudam os tradutores a preservar o sistema de nomenclatura do produto sem incorporar desnecessariamente as convenções do idioma de origem em todas as frases.
Aprove os termos com revisores que entendam tanto a funcionalidade quanto o usuário do idioma de destino. Um termo pode soar natural, mas implicar um comportamento errado, o que pode gerar confusão ou preocupações com a segurança em alguns contextos. Após a aprovação, aplique a decisão de forma consistente na interface, nos manuais e no conteúdo de suporte. As memórias de tradução, que armazenam segmentos traduzidos anteriormente, podem ser reutilizadas, mas a redação anterior ainda deve ser avaliada em relação à versão atual do produto e ao contexto.
Como garantir que as instruções do manual correspondam à interface
Forneça documentos originais editáveis e identifique o formato esperado da entrega. Inclua ilustrações, tabelas, referências cruzadas e qualquer conteúdo condicional que varie conforme a edição do produto. Um PDF pode servir como referência visual, mas o orçamento deve indicar claramente se há arquivos originais editáveis disponíveis ou se será necessário reconstruí-los. Como os recursos de formatação multilíngue e recriação de documentos variam entre os fornecedores, confirme se o seu fornecedor de serviços linguísticos é capaz de lidar com o formato necessário. Por exemplo, a Terralíngua possui décadas de experiência comprovada em editoração eletrônica multilíngue e recriação de documentos.
Estabeleça como as instruções devem fazer referência aos controles da interface. Um procedimento deve utilizar o rótulo aprovado para o idioma e a versão do produto. Nos casos em que a interface permanecer no idioma original, decida se deseja manter o rótulo original com uma explicação traduzida. O leitor deve ser capaz de conectar as instruções com o que aparece na tela, e não simplesmente entender a frase isoladamente.
Atribua um status de revisão próprio às capturas de tela. Identifique se elas mostram a versão final localizada, uma referência no idioma original ou uma imagem temporária. Atribua uma pessoa responsável por capturar as substituições e verificá-las conforme as instruções correspondentes. Recortar uma imagem para ocultar um rótulo desatualizado também pode remover o contexto necessário para o leitor. Portanto, resolva a incompatibilidade de versões de forma consciente.
O conteúdo de suporte merece o mesmo cuidado. Os termos de pesquisa, títulos de artigos e descrições de produtos podem usar uma linguagem informal que difere do nome formal de uma funcionalidade. Mantenha as explicações úteis, sem deixar de identificar claramente o produto pelo seu nome oficial. Um artigo de suporte pode explicar o que uma funcionalidade faz sem precisar renomear o controle que os usuários devem selecionar para acessá-la.
Como verificar o pacote de conteúdo
Defina o formato para troca dos arquivos antes de exportá-los. Inclua apenas os campos destinados à tradução e proteja claramente identificadores, URLs, exemplos de código e outros materiais não traduzíveis ou que não devem ser traduzidos (DNT). Alguns exemplos podem precisar de adaptação linguística sem alterar a sintaxe técnica. Deixe que o responsável pela documentação defina os limites, em vez de aplicar uma regra geral a tudo que pareça técnico.
Forneça um pacote de arquivos originais com um registro de revisões e um contato específico para esclarecimento de dúvidas. Mantenha uma lista de alterações pendentes em vez de misturar os textos aprovados com os provisórios sem explicação. Identifique os rótulos da interface que ainda estão em aberto antes de traduzir as seções do guia que dependem deles. Isso permite que a revisão se concentre nas decisões que, de outra forma, poderiam gerar retrabalho em várias entregas.
Solicite uma pequena amostra representativa quando os formatos ou restrições forem desconhecidos. Inclua um rótulo curto da interface, uma mensagem parametrizada e um procedimento de documentação que faça referência a ambos. Utilize a amostra para confirmar a compatibilidade da importação e rever as expectativas. Esta é uma verificação prática do escopo, não uma evidência de que o produto completo tenha sido testado funcionalmente.
Como atribuir responsabilidades de revisão e teste
A revisão linguística verifica o significado, a terminologia, a naturalidade e a consistência com o briefing acordado. Uma revisão contextual verifica como o conteúdo traduzido aparece na interface ou no documento. Os testes funcionais verificam se o software se comporta conforme o esperado. Essas atividades podem revelar questões relacionadas, mas não devem ser tratadas como serviços equivalentes.
Especifique quem deve importar os recursos traduzidos, criar a versão de revisão e corrigir os erros do produto. Defina se a Terralíngua analisará as telas renderizadas ou apenas o texto fornecido e alinhe qualquer trabalho de layout da documentação incluído no escopo. As equipes de produto e de engenharia do cliente devem manter a responsabilidade pelo comportamento do software e pelas decisões de lançamento, a menos que o contrato atribua tarefas específicas a outra equipe de forma explícita.
Forneça aos revisores uma maneira consistente de relatar problemas, incluindo como localizar o identificador da string ou o local no documento, o número da versão, uma captura de tela, a explicação da alteração e as instruções para enviar uma correção proposta. Diferencie um erro de tradução de uma alteração no texto original ou de um defeito do produto. Isso torna o feedback mais prático e ajuda a evitar que um desenvolvedor encurte uma tradução aprovada sem entender o impacto na documentação relacionada.
Como definir critérios de aceitação para todos os entregáveis
Alinhe como uma mudança de terminologia será tratada durante a revisão. Suponha que, em um aplicativo fictício de relatórios, os revisores substituam a tradução de "Visualizações salvas" após revisarem o menu de navegação. O registro de alterações deve identificar os trechos afetados no guia e nos artigos de suporte, e não apenas na string da interface. Dessa forma, o responsável pode aprovar uma correção coordenada, em vez de deixar que cada revisor descubra as consequências de forma independente.
A revisão de aceitação deve juntar os materiais, e não simplesmente aprovar cada arquivo separadamente. Selecione tarefas representativas dos usuários e compare os rótulos exibidos com as instruções correspondentes. Verifique tanto o caminho normal quanto o caminho de recuperação. Um guia que descreve com precisão os controles indisponíveis ainda precisa de atenção, mesmo quando a linguagem em si está correta. Os critérios de aceitação podem envolver muitos elementos para garantir uma localização bem-sucedida.
- Todas as strings e seções da documentação acordadas devem ser consideradas.
- Os nomes aprovados das funcionalidades devem estar consistentes em toda a interface e nas instruções relacionadas.
- Os placeholders e os identificadores protegidos devem manter a sintaxe correta.
- O texto deve ser revisado quanto à adequação e legibilidade nos ambientes acordados.
- As capturas de tela e os procedimentos devem descrever a mesma versão do produto.
- Os responsáveis designados devem resolver problemas de idioma e defeitos do produto antes da aprovação da versão.
Defina os ambientes de destino e a disponibilidade dos revisores no briefing para cotação. Múltiplas versões de plataforma, alterações tardias na interface e falta de capturas de tela podem afetar a quantidade de esforço de tradução necessário, bem como o impacto no cronograma. Textos que se repetem podem permitir a reutilização, mas as mesmas palavras em contextos diferentes podem exigir outro tratamento. A contagem bruta de palavras não abrange todo o trabalho necessário para manter o alinhamento entre o produto e a documentação.
Como manter as atualizações após o lançamento
Para atualizações, envie as strings alteradas com seus identificadores e explique quaisquer mudanças no comportamento da funcionalidade. Um rótulo pode permanecer o mesmo, mas com significado diferente, o que exigirá uma revisão. Identifique as seções da documentação e os artigos de suporte afetados para que uma pequena atualização da interface não resulte em instruções que descrevam um fluxo de trabalho anterior.
Mantenha a terminologia aprovada e registre a versão do produto em que cada decisão entrou em vigor. Atribua a função de conciliar o feedback recebido pelo suporte com o conteúdo oficial. Uma solução improvisada em uma resposta de suporte não documentada não deve se tornar o texto usado em um manual posterior sem a aprovação do produto.
Garanta que os arquivos de recursos entregues e os originais da documentação possam ser rastreados até a versão aprovada. Caso uma equipe regional edite um guia traduzido localmente, estabeleça como essas alterações serão registradas no registro compartilhado do projeto. Caso contrário, uma atualização posterior da tradução poderá sobrescrever uma correção importante ou reintroduzir um termo obsoleto. Notas de transferência sucintas, identificando os arquivos aprovados, as pendências e os responsáveis, podem tornar o processo mais gerenciável.
Perguntas frequentes
Os rótulos da interface devem ser aprovados antes da tradução do manual do usuário?
É uma boa prática aprovar todos os rótulos e termos antes do início de um projeto de tradução. Aprove os nomes de funcionalidades compartilhadas e os controles principais o mais cedo possível, pois isso garante a consistência da experiência do usuário. O trabalho pode prosseguir em paralelo se os termos provisórios estiverem claramente definidos e houver um responsável pela atualização. Antes do lançamento, compare as instruções traduzidas com a interface aprovada para a mesma versão e idioma. A falta de consistência na experiência do usuário pode causar atrasos e recalls se não for corrigida antes da localização.
O manual pode ser traduzido mesmo se o software permanecer no idioma original?
Sim, mas defina como os controles no idioma original serão identificados nas instruções. Manter o rótulo visível juntamente com uma explicação traduzida entre parênteses pode ajudar os usuários a encontrar o item correto. Forneça telas de referência e uma política de terminologia alinhada para que os tradutores não criem nomes de controles que não serão exibidos no aplicativo para os usuários.
Uma exportação das strings e a contagem total de palavras são suficientes para definir o escopo da localização?
São um ponto de partida. Inclua identificadores de string, contexto, telas representativas, placeholders, restrições de comprimento real e documentação relacionada. Um rótulo curto pode precisar de esclarecimentos, enquanto uma frase repetida pode ter significados diferentes em telas diferentes. Esses detalhes ajudam a distinguir o trabalho de tradução das questões que exigem uma decisão de produto ou de engenharia.
A tradução da interface inclui o teste do aplicativo?
Não de forma automática. Defina a revisão linguística, a revisão da interface em execução e os testes funcionais como tarefas separadas no escopo. Atribua responsáveis pela importação dos recursos, pela elaboração de uma versão de revisão e pela correção de defeitos do produto. A revisão final também deve confirmar se os manuais e as capturas de tela correspondem à interface traduzida para a versão pretendida.
Briefing da Terralíngua sobre o escopo completo de idiomas
Os serviços de tradução e localização técnica da Terralíngua incluem interfaces de software, manuais do usuário, especificações técnicas e documentação de TI. Quando a mesma funcionalidade aparece na interface e no conteúdo de suporte, um briefing linguístico coordenado ajuda a manter a terminologia e o escopo consistentes. Confirme os formatos específicos dos recursos, os arquivos finais da documentação e as tarefas de revisão do seu projeto, em vez de presumir que o desenvolvimento de aplicativos ou os testes funcionais estejam incluídos nos serviços linguísticos.
Conheça os serviços de tradução de documentação técnica e de software da Terralíngua
Para solicitar um orçamento, forneça uma exportação representativa das strings, a seção relevante do guia, telas de referência, os idiomas de destino e o prazo de lançamento. Inclua a terminologia aprovada, as restrições conhecidas e os formatos necessários para entrega final. Identifique quem é o responsável pela implementação e aprovação. Essas informações permitem que a discussão tenha como ponto de partida a experiência real do usuário e os materiais localizados necessários para oferecer suporte.
Solicite um orçamento para localização de software e tradução de documentação