Teste Visual de Sites Multilingues: Detetar as Regressões i18n Que Ninguém Verifica
Teste visual multilingue: processo de verificação automatizada da integridade visual de um site web ou aplicação no conjunto das suas versões linguísticas, detetando regressões específicas da internacionalização — transbordamentos de texto, quebras de layout RTL, problemas de espaçamento tipográfico, truncamentos e inconsistências visuais entre idiomas.
Operamos um site em 9 idiomas. Não é um argumento de marketing — é uma realidade operacional diária que nos ensinou algo que a maioria das equipas descobre demasiado tarde: cada idioma quebra a sua interface de uma forma diferente.
A internacionalização (i18n) é um problema técnico bem documentado do lado do desenvolvimento. Os frameworks modernos gerem corretamente os ficheiros de tradução, o routing por locale, os formatos de datas e números. O que não está bem documentado — e ainda menos bem testado — é o impacto visual de cada idioma na maquetação.
Segundo o W3C Internationalization Working Group, o comprimento do texto pode variar de 50% a 300% entre idiomas para o mesmo conteúdo. Um botão que exibe "Submit" em inglês exibe "Absenden" em alemão e "Enviar" em português. O botão tem o mesmo CSS. O texto não tem a mesma largura. E é aí que os problemas começam.
Porquê os sites multilingues são um pesadelo visual
A maioria das equipas de desenvolvimento concedem e testam a sua interface num único idioma — geralmente inglês. O design é validado em inglês. Os testes funcionais correm em inglês. A demo ao cliente faz-se em inglês. E quando as traduções chegam, são injetadas na interface sem verificação visual sistemática.
É o equivalente de construir uma casa com móveis de determinado tamanho, e depois substituir esses móveis por outros de tamanhos diferentes sem verificar se passam pelas portas.
O problema do comprimento do texto
O alemão é a besta negra dos designers de interface. A palavra inglesa "settings" torna-se "Einstellungen" em alemão — 60% mais longa. "User management" torna-se "Benutzerverwaltung". "Download now" torna-se "Jetzt herunterladen".
Isto não é anedótico. Segundo os dados do W3C, a expansão média do texto do inglês para o alemão é de 30% para frases e pode ultrapassar 200% para palavras isoladas (como labels de botões e elementos de navegação). O finlandês, o neerlandês e o grego apresentam expansões semelhantes.
O resultado concreto: botões cujo texto transborda em duas linhas e quebra o layout. Menus de navegação onde os itens se sobrepõem. Títulos truncados com reticências onde a versão inglesa se exibe integralmente. Cartões de produto cuja altura varia de um idioma para outro, criando grelhas desalinhadas.
O problema dos idiomas RTL
O árabe, o hebraico, o persa e o urdu escrevem-se da direita para a esquerda (RTL — Right To Left). Não é apenas texto invertido — é um layout inteiro que deve ser espelhado. A navegação está à direita, a barra de pesquisa à esquerda, as listas com marcadores começam à direita, os ícones direcionais (setas, chevrons) devem ser invertidos.
O CSS fez progressos consideráveis com as propriedades lógicas (margin-inline-start em vez de margin-left, padding-inline-end em vez de padding-right). Mas na prática, muitos sites ainda utilizam propriedades físicas que não se invertem automaticamente em RTL. E mesmo com propriedades lógicas, certos elementos necessitam de tratamento específico — sombras, degradês direcionais, cantos arredondados assimétricos.
Os bugs RTL típicos incluem texto que começa no bordo errado do seu contentor, elementos que se sobrepõem porque as margens estão na direção errada, ícones direcionais que apontam no sentido contrário, formulários cujos labels e campos não estão alinhados, e conteúdo misto (texto árabe com termos técnicos em inglês) que produz resultados de exibição imprevisíveis.
O problema dos sistemas de escrita CJK
O chinês, o japonês e o coreano (CJK) introduzem desafios tipográficos únicos. Os caracteres CJK são de largura fixa (cada caráter ocupa um quadrado de igual largura), o que produz um espaçamento visualmente diferente do texto latino. As regras de quebra de linha são diferentes — o chinês pode quebrar entre quaisquer caracteres, o japonês tem regras complexas sobre os caracteres de pontuação no início e fim de linha.
A renderização de fontes CJK é mais complexa. Os ficheiros de fonte são significativamente mais pesados (uma fonte chinesa completa cobre milhares de caracteres), o que pode impactar o tempo de carregamento e produzir um flash de fonte invisível (FOIT) ou um flash de fonte não estilizada (FOUT) que não existe com os idiomas latinos.
Um efeito secundário frequentemente ignorado: os caracteres CJK têm uma altura de linha natural diferente dos caracteres latinos. Um line-height: 1.5 que produz um texto arejado e legível em inglês pode parecer demasiado apertado ou demasiado largo em chinês. Ajustar o line-height especificamente para cada idioma é possível, mas raramente feito.
O problema dos scripts complexos
O tailandês, o hindi (Devanagari), o bengali e outros idiomas utilizam scripts complexos onde os caracteres se combinam, se empilham verticalmente ou mudam de forma conforme a sua posição na palavra. A renderização destes scripts depende fortemente do motor de renderização do navegador e da fonte utilizada.
Um texto hindi com caracteres combinados pode necessitar de mais altura de linha do que o esperado. Um texto tailandês, que não separa as palavras com espaços, pode produzir quebras de linha inesperadas. Estes problemas são invisíveis se a sua equipa não lê estes idiomas — e frequentemente é o caso.
Porquê o teste visual é a única resposta escalável
Face a estes desafios, as abordagens clássicas falham.
O teste manual por falantes nativos é a abordagem mais intuitiva e menos escalável. Encontrar um tester nativo para cada um dos seus idiomas, formá-lo para verificar sistematicamente cada página, e repetir a cada release — é um luxo que a maioria das equipas não pode permitir-se. E mesmo com testers nativos, a verificação manual falha em detetar regressões subtis (uma alteração de espaçamento de 4 pixels não é visível a olho nu numa única passagem).
Os testes funcionais automatizados verificam que o conteúdo traduzido se exibe, mas não como se exibe. Um teste Playwright que verifica que page.locator('.hero-title').textContent() contém texto não vazio passará mesmo que esse texto transborde do seu contentor e cubra o botão CTA abaixo.
A revisão de design por screenshot é uma prática comum mas não sistemática. Alguém tira screenshots da versão alemã, envia-os num canal Slack, um designer olha entre duas reuniões. É melhor que nada. Está longe de ser suficiente.
O teste visual automatizado resolve o problema à escala porque faz exatamente o que nenhum outro método faz de forma fiável: compara sistematicamente a renderização visual de cada página, em cada idioma, a cada release. Um texto alemão que transborda é detetado. Um layout RTL que se quebra é detetado. Um espaçamento chinês que muda é detetado. Sem intervenção humana, sem falante nativo, sem revisão manual.
O que o teste visual multilingue deteta concretamente
Eis as categorias de regressões que o teste visual apanha sistematicamente nos sites multilingues.
Os transbordamentos de texto
O cenário mais frequente. Um contentor CSS tem uma largura fixa ou um max-width que funciona para o inglês mas não para o alemão ou o finlandês. O texto transborda do seu contentor, sobrepõe-se a outros elementos ou é truncado de forma não intencional.
O teste visual deteta-o porque o transbordamento altera a posição ou a visibilidade de elementos na página. É uma diferença mensurável entre o baseline (onde o texto não transbordava) e a captura atual (onde transborda).
As quebras de layout RTL
Um componente que se exibe corretamente em LTR mas cujo layout está partido em RTL. Um flexbox cuja direção não se inverte. Um position: absolute; right: 10px que deveria ser left: 10px em RTL mas não o é. Um padding assimétrico que cria espaço no sítio errado.
Estes bugs são particularmente traiçoeiros porque a equipa de desenvolvimento, que trabalha geralmente em LTR, nunca os vê no seu workflow diário. O teste visual torna-os visíveis sem que ninguém precise de mudar o seu idioma de trabalho.
As inconsistências de altura de componentes
Numa grelha de cartões, se um cartão tem um título mais longo em alemão do que em inglês, a sua altura aumenta — o que desalinha a grelha inteira. O mesmo problema produz-se com os botões, os elementos de navegação, as linhas de tabela e os elementos de lista.
O teste visual capta estas inconsistências porque compara a estrutura visual da página completa, não elementos isolados. Uma grelha desalinhada é uma diferença detetável.
As fontes em falta ou mal renderizadas
O seu site utiliza uma fonte web que cobre os caracteres latinos mas não os caracteres árabes ou chineses. O navegador faz um fallback para uma fonte do sistema, o que altera a aparência global da página para esses idiomas. Ou pior, certos caracteres exibem-se como retângulos vazios (os famosos "tofu").
O teste visual deteta estas alterações de renderização tipográfica porque o baseline em inglês utiliza a fonte correta, e se o fallback produz um resultado visualmente diferente noutro idioma, a comparação assinala-o.
Os problemas de imagens e ícones localizados
Alguns sites localizam as suas imagens — capturas de ecrã do produto no idioma local, banners de marketing traduzidos, ícones adaptados ao mercado. Se uma imagem localizada tem as dimensões erradas, o rácio errado ou um texto truncado, o teste visual deteta-o tal como qualquer outra alteração visual.
A nossa experiência com 9 idiomas
Operamos o delta-qa.com em 9 idiomas. Não por vaidade, mas porque o nosso mercado é internacional e acreditamos que cada utilizador merece uma experiência no seu idioma.
Esta experiência ensinou-nos lições que teríamos preferido aprender de outra forma.
Cada adição de idioma revela bugs nos idiomas existentes. Quando adicionámos a versão árabe (RTL), descobrimos que certos componentes tinham margens codificadas (margin-left: 16px em vez de margin-inline-start: 16px) que não causavam problemas em LTR mas quebravam o layout em RTL. Corrigir estes componentes melhorou a qualidade do código para todos os idiomas.
As traduções chegam em contínuo, não de uma vez. Um site multilingue nunca está "terminado". Cada novo conteúdo, cada modificação de texto, cada atualização de documentação deve ser traduzida. E cada tradução é um risco de regressão visual — um texto mais longo que transborda, uma tradução em falta que exibe uma chave técnica, uma formatação que se perde.
A verificação manual de 9 idiomas é uma fantasia. Verificar visualmente cada página em 9 idiomas após cada deploy representa um volume de trabalho proibitivo. Se o seu site tem 30 páginas, são 270 verificações por deploy, sem contar os viewports mobile e tablet. O teste visual automatizado é a única abordagem realista.
Os bugs multilingues são os últimos a serem corrigidos. Na hierarquia de prioridades, um bug que só afeta a versão finlandesa ou japonesa é sistematicamente relegado para o fundo da pilha. O teste visual automatizado força a visibilidade destes bugs detetando-os e reportando-os ao mesmo nível que os bugs da versão inglesa.
Como estruturar o teste visual multilingue
Se gere um site multilingue e quer integrar o teste visual, eis a abordagem que recomendamos.
Defina a sua matriz de cobertura
Provavelmente não precisa de testar cada página em cada idioma a cada release. Identifique as combinações críticas.
Idiomas de alto risco: os idiomas com a maior expansão de texto (alemão, finlandês), os idiomas RTL (árabe, hebraico) e os idiomas CJK (chinês, japonês, coreano). Estes idiomas produzem as regressões mais frequentes e visíveis.
Páginas de alto risco: as páginas com muito texto curto em contentores restringidos (navegação, botões, formulários, cartões de produto). As páginas com conteúdo longo (artigos, documentação) são menos arriscadas porque o texto flui naturalmente.
A matriz prioritária é a interseção das duas: teste as suas páginas de alto risco nos seus idiomas de alto risco. É aí que encontrará 80% das regressões.
Capture baselines por idioma
Cada idioma tem o seu próprio baseline. A versão alemã da sua página inicial é um baseline distinto da versão inglesa. Quando compara, compara a versão alemã de hoje com a versão alemã da última release — não com a versão inglesa.
É uma distinção importante. O teste visual multilingue não compara os idiomas entre si (supõe-se que sejam diferentes). Compara cada idioma consigo mesmo ao longo do tempo, para detetar regressões.
Automatize a mudança de idioma
Para capturar eficientemente as diferentes versões linguísticas, a sua ferramenta de teste deve poder navegar para cada versão. Com uma ferramenta no-code como o Delta-QA, simplesmente navega para o URL de cada versão linguística (por exemplo /de/, /ar/, /zh/) e a ferramenta captura a renderização correspondente.
Gira os conteúdos dinâmicos traduzidos
Certos conteúdos mudam legitimamente entre capturas — datas, preços, promoções. Configure a sua ferramenta para excluir estas zonas dinâmicas da comparação, caso contrário cada captura desencadeará falsos positivos sobre conteúdos que mudam naturalmente.
Integre o teste visual no workflow de tradução
O momento mais arriscado para um site multilingue não é o deploy de código — é a atualização das traduções. Um novo ficheiro de tradução com strings mais longas, uma formatação diferente ou chaves em falta pode quebrar a interface. Lance o teste visual após cada atualização de tradução, não apenas após os deploys de código.
As ferramentas disponíveis
A escolha de uma ferramenta de teste visual para um site multilingue depende do seu contexto técnico e do seu volume de idiomas.
O Delta-QA é particularmente adaptado porque a abordagem no-code permite capturar qualquer versão linguística simplesmente navegando para ela. O algoritmo estrutural é insensível às diferenças de renderização de fontes entre idiomas — compara propriedades CSS, não pixels. É uma vantagem maior quando testa idiomas com sistemas de escrita diferentes, onde a renderização tipográfica varia fortemente.
O Playwright oferece capacidades de screenshot testing que podem ser parametrizadas por locale, mas cada asserção visual deve ser codificada, e a gestão de baselines por idioma num repositório Git torna-se rapidamente complexa com um grande número de combinações idioma/página/viewport.
O Percy e o Applitools gerem o multilingue via o seu cloud, com capacidades de agrupamento por idioma. O seu modelo de tarifação por snapshot pode encarecer quando o número de combinações idioma/página/viewport multiplica as capturas.
FAQ
Como gerir os textos que transbordam em certos idiomas?
O teste visual deteta o transbordamento, mas a correção é um trabalho de design e desenvolvimento. As soluções técnicas incluem a utilização de contentores flexíveis (min-width em vez de width fixo), de overflow-wrap: break-word para palavras muito longas, e de classes CSS condicionais por idioma para ajustar tamanhos de fonte ou espaçamentos quando necessário. A abordagem mais robusta é conceber para o idioma mais longo desde o início — se o design aguenta em alemão, aguenta em todo o lado.
É preciso testar todos os idiomas a cada release?
Não, se tem muitos idiomas. Priorize testando sistematicamente os idiomas de alto risco (alemão, árabe, chinês) e as páginas de alto risco (navegação, formulários, cartões). Faça um teste completo de todos os idiomas em todas as páginas de forma periódica — por exemplo uma vez por mês — e a cada atualização maior de traduções.
Como testar idiomas RTL quando ninguém na equipa lê árabe?
É precisamente a força do teste visual automatizado: não precisa de ler o idioma para detetar regressões. A ferramenta compara a versão RTL atual com o baseline RTL anterior. Se o layout mudou, se um elemento se deslocou, se um texto transbordou — é detetado independentemente do idioma. Não precisa de ler árabe para constatar que um bloco de texto transbordou do seu contentor.
Como distinguir um bug i18n de uma alteração intencional de tradução?
Seguindo o workflow de validação standard: quando o teste visual assinala uma diferença, examina a causa. Se a diferença corresponde a uma atualização de tradução documentada, atualiza o baseline. Se aparece sem alteração de tradução prevista, é uma regressão — uma alteração de CSS que impactou um idioma específico, ou uma chave de tradução em falta que exibe um valor por defeito.
Qual é o impacto SEO de um site multilingue visualmente partido?
Significativo. O Google avalia a experiência de utilizador por idioma via os seus Core Web Vitals e os seus sinais de qualidade de página. Um layout partido em alemão com texto que transborda e elementos que se sobrepõem degrada os sinais de qualidade para a versão alemã, independentemente da qualidade da versão inglesa. Cada versão linguística é avaliada separadamente. Um teste visual sistemático garante que a qualidade é homogénea no conjunto das versões.
O Delta-QA gere as fontes CJK e os scripts complexos?
O Delta-QA compara as propriedades CSS calculadas em vez dos pixels, o que o torna insensível às diferenças de renderização tipográfica entre idiomas. Quer a sua página utilize caracteres latinos, chineses, árabes ou devanagari, o algoritmo estrutural analisa as mesmas propriedades — dimensões, posições, cores, espaçamentos. Se um caráter chinês faz alterar a altura de um elemento ou se uma palavra árabe faz transbordar um contentor, a alteração é detetada pelas propriedades estruturais, não pela comparação de pixels.
Conclusão
Um site multilingue não é um site traduzido. É um produto diferente em cada idioma — com restrições visuais, tipográficas e de maquetação que variam radicalmente. Testar unicamente a versão inglesa e esperar que os outros idiomas sigam é ignorar a realidade da internacionalização.
O teste visual automatizado é o único meio escalável de manter a qualidade visual no conjunto das suas versões linguísticas. Deteta o que ninguém verifica — os transbordamentos alemães, as quebras RTL árabes, as inconsistências CJK — e fá-lo a cada release, sem falante nativo, sem revisão manual, sem compromisso.
Cada um dos seus utilizadores, qualquer que seja o seu idioma, merece uma interface que funcione visualmente. O teste visual multilingue é a forma de o garantir.