Organização em conformidade com o GDPR
Organização certificada ISO 27001
Organização em conformidade com o SOC II
Encontre os erros linguísticos que um build aprovado não detecta. O Smartcat combina a pontuação de qualidade de tradução com IA à revisão por falantes nativos, para que sua equipe corrija instruções confusas, termos inconsistentes e textos que não cabem antes do release.
Mais de 80 das maiores empresas do mundo escolheram o Smartcat
Os testes de localização verificam se um produto traduzido é preciso, compreensível e utilizável em um idioma e em uma região específicos. Eles combinam a revisão linguística com verificações do layout do texto, do contexto cultural e de formatos locais, como datas, números e moedas.
A garantia de qualidade linguística, ou LQA, é a parte desse processo focada no idioma. Os revisores registram os erros de acordo com categorias e níveis de gravidade combinados, dando à sua equipe uma base clara para aceitar uma tradução ou devolvê-la para correção. Saiba mais sobre garantia de qualidade linguística.
Uma string tecnicamente válida ainda pode confundir o usuário. Em inglês, “Save” pode significar salvar uma configuração ou resgatar alguém. Uma tradução de “Next” pode estar certa no dicionário, mas errada para a ação que um botão realiza. Os testes conectam o texto à tarefa que o usuário está tentando concluir.
Os problemas de localização ficam mais caros de coordenar quando surgem depois que o release foi aprovado. Um revisor precisa do build certo, um desenvolvedor precisa de um relatório reproduzível e a string corrigida precisa de mais uma verificação em todas as telas afetadas.
Os usuários hesitam
Um rótulo traduzido muda de sentido e deixa as pessoas sem saber se estão confirmando um pagamento ou salvando um rascunho.
Os layouts quebram
Uma tradução mais longa se sobrepõe a um ícone ou desaparece atrás de um botão de largura fixa.
O suporte repete a explicação
O conteúdo de ajuda usa um termo de produto diferente do da interface, o que torna difícil acompanhar um artigo que, de resto, está correto.
A aprovação perde o sentido
A versão que o linguista revisou é diferente da versão incluída no build.
Combine a versão da origem, as localidades de destino e os critérios de aceitação antes de começar os testes. Assim, cada problema se torna acionável e cada aprovação fica rastreável até um release.
Idioma, contexto e comportamento do produto exigem verificações diferentes. O Smartcat oferece suporte ao QA de tradução e acesso a especialistas em idiomas; as verificações de tela usam as capturas ou o ambiente de testes fornecidos pela sua equipe.
| Tipo de teste | O que verificar | Exemplo | Responsabilidade |
|---|---|---|---|
| Linguístico | Sentido, gramática, termos do glossário e tom | “Save” traduzido com o sentido errado | Avaliação de qualidade com IA e um revisor nativo |
| Cultural | Exemplos, referências, imagens e adequação ao público | Uma promoção sazonal que não faz sentido no mercado-alvo | Um revisor que conhece o mercado |
| Texto na interface | Cortes, quebras de linha, expansão e ordem de leitura | Um rótulo de configurações em alemão escondido atrás de um ícone | Um testador verifica suas telas ou seu build |
| Formatos da localidade | Datas, números, moedas, unidades e endereços | Uma data numérica ambígua em uma confirmação de reserva | Sua equipe de QA e um revisor da localidade |
| Integridade dos recursos | Variáveis, marcação, chaves ausentes e comportamento de plurais | Um argumento %1$s ausente ou uma forma de quantidade incorreta | Verificações de arquivos, testes do aplicativo e revisão linguística |
Sua equipe de engenharia continua responsável pelos testes funcionais, pelos dispositivos e pelo comportamento do release. Uma pontuação de qualidade da tradução não comprova que um fluxo de pagamento, um teclado ou um leitor de tela funcionam corretamente no aplicativo.
Comece com um release e um conjunto definido de idiomas. Mantenha a tradução, a revisão e a resolução de problemas conectadas ao mesmo material de origem.
Importe recursos de software compatíveis ou conecte uma integração adequada. Dê aos revisores descrições das chaves, capturas de tela e acesso ao build relevante quando necessário. Inclua o idioma, a plataforma e a versão no briefing de testes.
Traduza com seu glossário e sua memória de tradução. Explique os termos do produto, os nomes protegidos e o tom pretendido antes que os revisores comecem a tomar decisões individuais.
O Quality Assurance Coworker identifica problemas de tradução, classifica seu tipo e gravidade e gera uma pontuação de qualidade. Ele avalia o texto sem editá-lo.
Designe seus próprios especialistas nativos ou especialistas em LQA do Marketplace. Peça que verifiquem o texto com base nas telas fornecidas e sinalizem os problemas com contexto suficiente para reproduzi-los.
Os linguistas ou o Reviewer Coworker melhoram a tradução. Os desenvolvedores corrigem defeitos de recursos ou de layout. Teste novamente o conteúdo alterado e os fluxos de usuário afetados; verificar apenas as palavras alteradas não cobre todas as regressões.
Sua equipe decide se as constatações resolvidas atendem ao nível de qualidade combinado. Exporte os recursos aprovados, valide-os no build e guarde o registro do release para a próxima atualização.
O guia de configuração da localização de software explica coleções, importações e exportações. O processo via API e CLI atende equipes que querem conectar essas etapas ao seu processo de release.
As verificações automáticas ajudam os revisores a encontrar problemas de forma consistente. A revisão humana acrescenta o julgamento de produto e de mercado necessário para decidir se uma tradução é adequada no uso real.
O Quality Assurance Coworker mede a qualidade. Ele não edita a tradução.
Seus revisores, o Reviewer Coworker e seu processo de release decidem quando o conteúdo corrigido está pronto para ser lançado.
Os testes de internacionalização verificam se seu produto foi projetado para suportar diferentes idiomas e convenções regionais. Os testes de localização verificam se uma versão localizada específica está correta. Os dois importam: uma tradução não consegue corrigir textos em inglês fixos no código ou um layout que pressupõe texto da esquerda para a direita.
| Testes de internacionalização | Testes de localização | |
|---|---|---|
| Pergunta principal | Este produto consegue suportar as localidades necessárias? | Esta localidade funciona para seus usuários? |
| Momento típico | Durante o desenvolvimento, antes e junto com a tradução | Depois da tradução e durante a validação do release |
| Verificações típicas | Strings externalizadas, Unicode, layouts flexíveis, formatação sensível à localidade | Sentido, terminologia, layout, convenções regionais e links localizados |
A pseudolocalização é uma verificação inicial útil: substitua o texto por versões visivelmente alteradas ou expandidas para revelar strings fixas no código e suposições de layout. Ela ajuda a identificar problemas de engenharia antes de você pagar para traduzir a interface inteira. Ela não substitui a revisão por alguém que entende o idioma de destino.
Use um checklist compartilhado e registre as exceções. Um release pode conter tanto problemas linguísticos resolvidos quanto defeitos funcionais não resolvidos; relate-os separadamente para que o aprovador entenda o risco.
Defina o escopo primeiro e, depois, verifique o texto onde os usuários vão lê-lo.
Os testes de localização de apps móveis conectam arquivos de recursos a uma tela pequena e a um release em constante mudança. Revise o onboarding, as explicações de permissões, o checkout, as notificações e os estados de erro com o mesmo cuidado da navegação principal e teste os textos da página na loja em relação ao produto que os usuários realmente vão baixar. Conheça a localização de apps móveis.
Aplique a revisão linguística e cultural a diálogos, menus, tutoriais e textos da loja. Dê aos revisores informações sobre os personagens, o contexto narrativo e os limites de tamanho. Os testes linguísticos podem detectar uma instrução confusa ou um nome de personagem inconsistente; o equilíbrio da jogabilidade, o desempenho e a cobertura de dispositivos continuam fazendo parte do seu programa de QA de jogos.
O Smartcat reúne ativos de tradução, avaliação de qualidade com IA e revisão humana no mesmo processo. Você pode começar com seus revisores atuais, adicionar especialistas para idiomas que não consegue avaliar internamente e manter a terminologia aprovada disponível para os próximos releases.
298
projetos em 29 países
A equipe da Topcon entregou 298 projetos de tradução em dois anos, em 31 idiomas, depois de consolidar oito fornecedores de tradução em um único espaço de trabalho no Smartcat.
O caso publicado da Topcon descreve a consolidação de oito fornecedores de tradução em uma única plataforma. É uma evidência sobre a gestão de operações de tradução, e não uma afirmação de que o Smartcat elimina defeitos de software. Leia o caso de sucesso da Topcon.
O custo dos testes de localização depende dos idiomas, do volume de texto, da profundidade da revisão e do acesso de que os revisores precisam. O uso da plataforma e o trabalho de especialistas externos são partes separadas do escopo. Confira os planos atuais do Smartcat e solicite um orçamento específico do projeto aos linguistas que você escolher.
Selecione um release, telas representativas e um pequeno conjunto de fluxos importantes. Combine as categorias de erro, as responsabilidades dos revisores e o aprovador final. Compare as constatações e o esforço com o seu processo atual antes de ampliar a cobertura.
Os testes de localização verificam a precisão linguística, a usabilidade e a adequação ao mercado de um produto traduzido. Eles incluem terminologia, contexto cultural, layout do texto e convenções da localidade. Os revisores precisam das strings relevantes e do contexto do produto; o QA do aplicativo continua necessário para confirmar que o build localizado se comporta corretamente.
LQA significa garantia de qualidade linguística: uma avaliação estruturada do texto traduzido com base em critérios combinados. Um revisor classifica problemas como precisão, terminologia e estilo, atribui a gravidade e registra as constatações. É uma parte dos testes de localização, e não um substituto para os testes funcionais ou de dispositivos.
Os testes de internacionalização verificam a capacidade do produto de suportar diferentes localidades. Os testes de localização verificam uma versão de idioma e região específica. As verificações de engenharia podem revelar um formato de data fixo no código antes da tradução; depois, um revisor nativo pode confirmar se a redação e a apresentação finais fazem sentido naquele mercado.
Algumas partes podem ser automatizadas, incluindo a validação de recursos e as verificações de qualidade da tradução. O QA Coworker do Smartcat avalia problemas de tradução e gera uma pontuação de qualidade. Revisores nativos e testadores do aplicativo ainda precisam avaliar contexto, adequação cultural, layout e comportamento. Combine essas verificações de acordo com o risco do conteúdo e os requisitos do release.
O Smartcat oferece suporte à parte de revisão linguística da localização de apps móveis e jogos. Você pode usar revisores nativos para avaliar o texto com base em capturas de tela ou em um ambiente de testes fornecido por você. Defina o escopo dos testes de dispositivos, desempenho, jogabilidade e funcionalidade com sua equipe de engenharia ou com um fornecedor especializado em testes; essas são responsabilidades separadas.
O preço depende dos pares de idiomas, do volume de conteúdo, das telas, da profundidade da revisão e dos prazos exigidos. Confira o plano da plataforma e solicite orçamentos para a revisão especializada separadamente. Um briefing de testes claro ajuda os revisores a estimar o trabalho e evita que uma verificação barata de strings seja confundida com um QA completo do aplicativo.
Use o Smartcat para os ativos de tradução, a revisão linguística e a avaliação de qualidade e, depois, conecte o resultado aprovado ao seu processo de build e testes. Defina como as constatações chegam ao seu sistema de controle de issues e quem verifica as correções. Confirme durante a configuração qualquer automação necessária de exportação de issues, em vez de presumir que ela faz parte de todas as integrações.
Comece pelos fluxos em que um mal-entendido tem as maiores consequências: onboarding, pagamentos, acesso à conta, recuperação de erros e instruções do produto. Combine a revisão linguística com verificações de layout, variáveis e formatos da localidade. Amplie a cobertura à medida que descobrir quais telas e idiomas geram mais problemas; uma única pontuação de qualidade não substitui um plano de testes baseado em risco.
Não encontrou sua resposta? Fale com um especialista em localização
Traga um conjunto de strings e o contexto do produto. Veja como a avaliação de qualidade com IA e a revisão por falantes nativos se encaixam no seu processo de release.