Um product tour escrito em inglês e exibido para um usuário que trabalha em alemão não é um tour que ajuda pela metade. É uma interrupção. O usuário fecha o tour e, como a maioria dos fluxos de onboarding só aparece uma vez, nunca mais vê aquela orientação, em idioma nenhum.
A maioria dos produtos SaaS localiza a interface muito antes de localizar a camada de onboarding, o que gera um resultado curioso: um aplicativo totalmente traduzido, envolto em tooltips em inglês. É uma lacuna barata de fechar e cara de manter aberta, porque o onboarding é a única parte do produto em que entender não é opcional.
Este guia mostra como decidir quais idiomas oferecer, como detectar o idioma certo, os problemas específicos de interface que a tradução cria em tooltips e modais, e como evitar que a orientação localizada fique desatualizada.
A expansão de texto é a falha que aparece em produção, e não na revisão.
Principais conclusões
- Onboarding sem tradução é pior do que nenhum. Um tour fechado raramente volta, então uma primeira impressão ruim custa o fluxo inteiro.
- Siga a configuração do usuário, não a do navegador. O idioma explícito do produto vence sempre o idioma deduzido.
- Reserve 35% a mais de largura do que o inglês. Alemão e finlandês quebram com frequência layouts pensados para textos em inglês.
- Traduza também a lógica de disparo. Seletores de elementos e URLs de páginas costumam mudar entre idiomas e quebram os tours sem aviso.
- As capturas de tela também precisam ser localizadas. Um tooltip traduzido apontando para uma captura em inglês confunde mais do que cada um sozinho.
- Versione o original, não as traduções. Toda edição em inglês precisa invalidar as traduções, ou seus idiomas vão divergir sem que ninguém perceba.
Por que o onboarding localizado importa mais do que a interface localizada
Um usuário experiente consegue navegar por uma interface parcialmente em inglês reconhecendo o layout e os ícones. Um usuário novo não consegue, porque ainda não tem nenhum modelo mental do produto, e o onboarding é justamente o momento em que cada palavra carrega todo o peso.
Daí vêm três consequências, e elas se somam:
- Fechar é definitivo. Os fluxos de onboarding geralmente aparecem uma vez. Quem fecha um tour incompreensível não o adiou: perdeu.
- A carga de suporte muda de lugar. Perguntas que a orientação in-app teria respondido chegam a um canal onde custam dinheiro de verdade, e muitas vezes em um idioma que seu time de suporte também não cobre.
- Seus dados de ativação mentem para você. Diferenças regionais de ativação são atribuídas ao product-market fit ou ao preço, quando a causa é que metade do mercado passou pelo onboarding em um idioma que não usa no trabalho.
O diagnóstico que vale a pena rodar antes de qualquer coisa: segmente as taxas de ativação e de conclusão do onboarding por idioma do usuário. Se os segmentos que não falam inglês ficam bem atrás enquanto o engajamento deles no produto principal é comparável, você tem um problema de localização, não de mercado, e ele é bem mais barato de resolver.
Como escolher quais idiomas oferecer
Localizar o onboarding não sai de graça: cada idioma multiplica o custo de manutenção de cada fluxo. A decisão deve ser guiada por dados, não por ambição.
| Sinal | O que analisar | Por que importa |
|---|---|---|
| Base de usuários atual | Distribuição de idiomas das contas ativas | Os ganhos mais baratos estão nos usuários que você já tem e atende mal. |
| Diferença de ativação | Taxas de conclusão por segmento de idioma | Aponta o idioma em que a localização mais muda o comportamento. |
| Concentração de receita | ARR por região | Poucos usuários podem representar uma receita desproporcional. |
| Carga de suporte | Volume de tickets por conta e por região | Muitos tickets e pouco engajamento com a orientação são um sinal de tradução. |
| Pipeline de vendas | Negócios travados por exigências de idioma | Em alguns mercados, compradores enterprise tratam isso como requisito de compra. |
Uma regra pragmática de priorização: comece pelos dois idiomas em que você já tem usuários, não pelos dez em que espera ter. O custo de manutenção da localização do onboarding se acumula, e um par bem mantido vale mais do que seis idiomas que ficam desatualizados em um trimestre.
Como detectar o idioma certo
Errar na detecção desfaz todo o trabalho de tradução: um usuário francês que recebe orientação em alemão fica pior do que um que a recebe em inglês. Use esta ordem de prioridade:
Uma preferência de idioma explícita no perfil do usuário
O idioma em que a interface do aplicativo está sendo exibida
Um padrão definido no nível da conta ou do workspace
O idioma do navegador, como último recurso
Um idioma de fallback definido, nunca uma tela em branco
Por que o idioma do navegador é um sinal principal fraco
O idioma do navegador reflete onde a máquina foi configurada, não como a pessoa trabalha. Desenvolvedores e funcionários de multinacionais usam com frequência sistemas operacionais em inglês enquanto trabalham em outro idioma, e máquinas compartilhadas ou com imagem corporativa informam um idioma que ninguém escolheu. Se o seu produto já tem uma configuração de idioma, a resposta é essa configuração: ela é uma declaração explícita de preferência, e não uma dedução.
Defina sempre um fallback
Um usuário cujo idioma não tem tradução deve ver o idioma de fallback, e não um tooltip vazio ou uma chave de tradução bruta. Escolha o fallback de forma deliberada e garanta que um texto ausente nunca seja exibido como nada: um espaço em branco silencioso é muito mais difícil de notar nos testes do que um texto visivelmente em inglês no meio de um fluxo em francês.
Os problemas de interface que a tradução cria
Localizar o onboarding não é só uma tarefa de conteúdo. As camadas de orientação ficam ancoradas a uma interface ao vivo, e a tradução muda essa interface.
1. A expansão de texto quebra layouts fixos
Traduzidos do inglês, alemão e finlandês costumam ficar 30–35% mais longos, e o francês cerca de 20–25%. Um tooltip dimensionado para "Save changes" vai cortar "Änderungen speichern".
Escreva o texto do onboarding pensando no seu idioma mais longo, deixe os contêineres crescerem na vertical e nunca fixe a altura de um tooltip. A disciplina complementar é simplesmente escrever um texto original mais curto: as mesmas regras de microcopy que tornam boa a orientação em inglês fazem com que ela sobreviva à tradução.
2. Posições de elementos e seletores mudam
Esta é a falha que mais passa despercebida. Os tours se ancoram em elementos específicos e, se um seletor depende de texto visível (o rótulo de um botão, um rótulo ARIA, um atributo data derivado do texto), ele não vai corresponder em outro idioma. O tour então aponta para o nada ou simplesmente não inicia, sem nenhum aviso.
Ancore em atributos estáveis e independentes do idioma, como IDs ou atributos data dedicados, e teste cada tour em cada idioma, em vez de supor que o texto traduzido é a única diferença.
Cada etapa de um tour fica ancorada a um elemento ao vivo, e é exatamente isso que a tradução desloca.
3. Capturas de tela e vídeos também precisam ser localizados
Um tooltip traduzido apontando para uma captura de tela em inglês confunde mais do que um tooltip em inglês apontando para uma captura em inglês, porque agora os dois se contradizem. Localize as imagens ou crie uma orientação que não dependa delas; para tarefas feitas pela primeira vez, um walkthrough interativo da interface real, já traduzida, elimina o problema por completo.
4. Formatos e convenções são diferentes
Datas, números, moedas e a ordem dos nomes variam. Um texto de onboarding que diz "insira a data no formato MM/DD/AAAA" está errado na maior parte do mundo. Faça referência ao formato que o produto realmente exibe naquele idioma, em vez de fixar um exemplo no texto.
5. Direita para a esquerda é uma mudança de layout, não uma tradução
Árabe e hebraico espelham o layout inteiro: âncoras dos tooltips, direção das setas, indicadores de progresso e o próprio sentido de "próximo". Se RTL está no seu roadmap, confirme que sua camada de orientação suporta a troca de direção antes de se comprometer; adaptar isso depois é bem mais difícil do que traduzir.
Como evitar que o onboarding traduzido apodreça
A falha previsível não é a tradução inicial. É o sétimo mês, quando o fluxo em inglês já foi editado quatro vezes e a versão em alemão ainda descreve uma tela que não existe mais.
Os quatro hábitos que evitam a defasagem
- Trate um idioma como fonte da verdade. Todas as edições acontecem nele, e as traduções derivam dele. Editar os idiomas de forma independente garante a divergência.
- Versione o texto original. Quando o original muda, as traduções são marcadas automaticamente como desatualizadas; esse único mecanismo evita a maior parte da defasagem.
- Inclua a localização no checklist de release. Uma funcionalidade não está lançada quando o tour em inglês entra no ar; ela está lançada quando todos os idiomas oferecidos entram.
- Revise na interface real, não em uma planilha. Tradutores que trabalham a partir de uma lista de textos não conseguem ver que um botão agora está 40 pixels estreito demais.
O que traduzir, e o que não traduzir
✅ Traduza
- Todo o texto de tooltips, modais e checklists
- Rótulos de botões e CTAs
- Perguntas de pesquisas e opções de resposta
- Títulos e textos de anúncios
- Textos de estados vazios
- Mensagens de erro e de validação nos fluxos guiados
❌ Não mexa
- Nomes de produtos e funcionalidades que você não localizou na interface
- Seletores de elementos e identificadores internos
- Nomes de segmentos e rótulos internos de fluxos
- Qualquer coisa que se refira a um texto da interface sem tradução
- Exemplos de código e referências de API
A regra da consistência: o texto da orientação deve usar exatamente as palavras que a interface usa naquele idioma. Se a sua interface em alemão rotula um botão como "Speichern", o tooltip em alemão precisa dizer "Speichern", e não um sinônimo que o tradutor preferiu. Uma orientação que nomeia um controle de forma diferente do próprio controle é pior do que nenhuma orientação, porque o usuário passa a procurar algo que não existe.
Onboarding multilíngue com o Kompassify
O motivo habitual para a localização do onboarding ser adiada é que ela significa mais um projeto de engenharia. Uma camada de orientação no-code muda isso: os fluxos e suas traduções ficam fora do código, então adicionar um idioma não exige um release.
- Um fluxo, vários idiomas. Crie um product tour uma única vez e mantenha as traduções junto com ele, para que a lógica nunca divirja entre os idiomas.
- Segmentação por idioma. Exiba a versão certa com base no idioma do produto do usuário, em vez de adivinhar a partir do navegador.
- Checklists e tooltips localizados, para que toda a camada de onboarding fale um só idioma, e não apenas a maior parte dela.
- Anúncios traduzidos, para que os lançamentos de funcionalidades cheguem a todos os mercados ao mesmo tempo.
- Analytics por idioma, para confirmar que o fluxo localizado realmente fechou a diferença de conclusão.
O Kompassify é uma plataforma de adoção digital no-code para times de SaaS. Gratuito até 100 usuários ativos mensais, planos pagos a partir de $129/mês, em conformidade com o GDPR e com hospedagem na UE.
Faça o onboarding de cada usuário no idioma dele
Crie o fluxo uma vez, mantenha as traduções junto com ele e exiba a versão certa automaticamente, sem precisar de um release.
Comece grátis →Perguntas frequentes
Por que o onboarding precisa ser localizado se a interface já é?
Porque o onboarding é o momento em que cada palavra carrega todo o peso. Um usuário experiente consegue navegar por uma interface parcialmente em inglês reconhecendo o layout e os ícones, mas um usuário novo ainda não tem nenhum modelo mental do produto. Pior: os fluxos de onboarding geralmente aparecem uma única vez, então quem fecha um tour incompreensível não o adiou, perdeu de vez.
Para quais idiomas devo localizar meu onboarding primeiro?
Comece pelos idiomas em que você já tem usuários, e não pelos mercados em que espera entrar. Analise a distribuição de idiomas das contas ativas, a diferença de ativação por segmento de idioma, a concentração de receita por região e o volume de tickets de suporte. Cada idioma a mais multiplica o custo de manutenção, então dois idiomas bem mantidos valem mais do que seis que ficam desatualizados em um trimestre.
Como devo detectar qual idioma exibir?
Use esta ordem de prioridade: uma preferência de idioma explícita no perfil do usuário, depois o idioma em que a interface do aplicativo está sendo exibida, depois um padrão da conta ou do workspace e, só então, o idioma do navegador. O idioma do navegador é um sinal principal fraco, porque reflete como a máquina foi configurada, não como a pessoa trabalha. Defina sempre um idioma de fallback para que uma tradução ausente exiba um texto legível, e não um tooltip em branco ou uma chave bruta.
O que quebra quando você traduz a orientação in-app?
Cinco coisas. A expansão de texto, já que alemão e finlandês costumam ser 30-35% mais longos que o inglês e cortam tooltips de largura fixa. Seletores de elementos que dependem do texto visível, que deixam de corresponder em outros idiomas e quebram os tours sem aviso. Capturas de tela que ainda mostram a interface em inglês. Convenções de data, número e moeda citadas no texto. E idiomas da direita para a esquerda, que espelham o layout inteiro em vez de apenas trocar as palavras.
Quanto espaço extra devo prever para o texto de onboarding traduzido?
Reserve cerca de 35% a mais de largura do que a versão em inglês, o que cobre alemão e finlandês, os idiomas que mais expandem. O francês costuma ser 20-25% mais longo. Escreva o texto pensando no idioma mais longo que você oferece, deixe os contêineres crescerem na vertical e nunca fixe a altura de um tooltip. Escrever um texto original mais curto é a solução mais barata disponível.
Como evitar que o onboarding traduzido fique desatualizado?
Quatro hábitos evitam quase toda a defasagem. Trate um idioma como fonte da verdade, para que todas as edições aconteçam nele. Versione o texto original, para que qualquer alteração marque automaticamente as traduções como desatualizadas. Inclua a localização no checklist de release, para que uma funcionalidade só seja considerada lançada quando todos os idiomas oferecidos estiverem no ar. E revise as traduções na interface real, e não em uma planilha, porque um tradutor que trabalha a partir de uma lista de textos não consegue ver que um botão ficou estreito demais.
O que não deve ser traduzido nos fluxos de onboarding?
Nomes de produtos e funcionalidades que você não localizou na interface, seletores de elementos e identificadores internos, nomes de segmentos e rótulos internos de fluxos, exemplos de código e referências de API, e tudo o que se refere a um texto da interface que continua sem tradução. A regra que manda é a consistência: o texto da orientação deve usar exatamente as palavras que a interface usa naquele idioma, porque um tooltip que nomeia um controle de forma diferente do próprio controle faz o usuário procurar algo que não existe.
Preciso de trabalho de engenharia para localizar product tours?
Não, se a camada de orientação ficar fora do seu código. O motivo habitual para a localização do onboarding ser adiada é que ela é tratada como mais um projeto de engenharia. Com uma plataforma de adoção digital no-code, os fluxos e suas traduções são mantidos lado a lado, então adicionar um idioma não exige um release e a lógica não tem como divergir entre os idiomas.