Melhores práticas de localização de software: 10 passos com exemplos

Este guia orienta você pelo processo de localização de software do início ao fim, com melhores práticas e exemplos de código reais.

Seu aplicativo acabou de ser lançado na França. As inscrições estão chegando e, de repente, os tickets de suporte começam a inundar sua caixa de entrada. Os usuários não conseguem clicar no botão “Comprar agora” porque ele foi cortado. Os menus de navegação estão quebrando em duas linhas. Sua UI cuidadosamente projetada parece completamente quebrada.

É isso que acontece quando você pula direto para a tradução sem localizar seu software adequadamente. O texto é traduzido, mas o aplicativo não foi construído para lidar com isso.

Este guia cobre tudo o que você precisa para acertar na localização de software. Você aprenderá:

• O que é localização de software
• A diferença entre localização, tradução e internacionalização
• Como se preparar para o processo de localização de software
• Melhores práticas para conteúdo dinâmico, expansão de texto, formatação específica de locale e testes
• O custo da localização de software
• Como configurar um fluxo de trabalho de localização que não quebra a cada lançamento

O que é localização de software?

A localização de software é o processo de adaptar seu software para um mercado específico. Isso vai além de traduzir texto. Significa ajustar tudo o que afeta a forma como os usuários no mercado de destino vivenciam seu software: formatos de data e número, moeda, layout de UI, imagens e referências culturais.

O objetivo é fazer com que seu software pareça ter sido construído para aquele mercado desde o início.

Aqui está um exemplo que mostra como a mesma data pode significar duas coisas diferentes dependendo de onde seu usuário está:

Esse é um pequeno exemplo do que a localização de software abrange. Multiplique isso por datas, moedas, formatos e referências culturais, e você começa a ver o escopo do trabalho.

Localização de software vs. Tradução vs. Internacionalização

Muitas pessoas usam esses três termos de forma intercambiável, mas eles significam coisas diferentes e acontecem em estágios diferentes do desenvolvimento.

O processo de localização de software

A localização de software não é um passo único que você conclui antes do lançamento. É um processo contínuo que ocorre junto com o desenvolvimento. Aqui está uma visão geral de como ele normalmente se divide:

A maioria das equipes executa o processo de uma destas três maneiras:

1. Cascata (Waterfall) A localização começa após a conclusão do desenvolvimento. Você termina a construção e depois entrega tudo para tradução em um único lote. É simples de gerenciar, mas atrasa seu lançamento em outros idiomas e torna a correção de bugs cara nesse estágio.
2. Localização ágil A localização ocorre junto com o desenvolvimento. Em vez de um grande lote no final, você envia strings para tradução ao longo do ciclo de desenvolvimento. O tempo é melhor, mas o processo ainda é manual. Alguém da sua equipe precisa exportar as strings, gerenciar as entregas e importar as traduções de volta.
3. Localização contínua A localização é totalmente automatizada. Seu repositório se conecta diretamente à sua ferramenta de tradução, então, quando uma string muda, ela é enviada para tradução automaticamente. Quando a tradução está pronta, ela é mesclada de volta automaticamente.

Melhores práticas de localização de software

Cada projeto é diferente, e suas necessidades de localização dependerão da sua stack, dos seus mercados-alvo e da sua equipe. Esta lista cobre o essencial do que faz a localização de software funcionar.

Armazene todo o seu texto traduzível em arquivos separados

Quando você insere texto hardcoded diretamente no seu código-fonte, as ferramentas de tradução não conseguem encontrá-lo. Essas ferramentas funcionam escaneando arquivos de recursos como JSON, PO ou YAML em busca de strings para traduzir. Se o seu texto estiver enterrado dentro dos seus arquivos JavaScript, PHP ou Ruby, a varredura voltará vazia.

Esse é o motivo mais comum para o fracasso de projetos de localização. As equipes só descobrem o problema quando tentam traduzir e percebem que precisam refatorar milhares de strings primeiro.

É por isso que é melhor mover todo o texto voltado para o usuário para arquivos de recursos dedicados desde o início. Isso inclui tudo o que seus usuários podem ver:

• Rótulos de UI, botões e itens de menu
• Mensagens de erro e texto de validação
• Modelos de e-mail e notificações
• Texto de ajuda, tooltips e texto de placeholder
• Mensagens de sucesso e confirmação

Qual formato de arquivo você usa depende do seu framework:

Aqui está um antes e depois para cada um dos principais frameworks.

React:

Antes

<button>Submit</button>

Depois, usando react-i18next

<button>{t('submit_button')}</button>

WordPress:

Antes

echo 'Submit';

Depois, i18n do WordPress

echo __( 'Submit', 'your-textdomain' );

Ruby on Rails:

Antes

flash[:notice] = "Profile updated successfully"

Depois, usando I18n do Rails:

flash[:notice] = t('profile.update_success')

Também é importante dar às suas strings chaves claras e descritivas. Uma chave chamada checkout.submit_button diz ao tradutor exatamente onde essa string aparece e o que ela faz. Por outro lado, string_147 não diz nada a eles, o que leva a traduções incorretas. Chaves descritivas também facilitam para a sua própria equipe rastrear quais strings foram externalizadas e identificar qualquer coisa que esteja faltando.

Use placeholders para nomes, números e datas

Quando seu texto inclui dados variáveis, como o nome de um usuário ou um número de pedido, é tentador construir a frase juntando pedaços de texto no seu código. Isso quebra em outros idiomas.

Veja o porquê:

const message = 'Hello, ' + name + '!';

Este exemplo divide a frase em três fragmentos. Em inglês, a ordem das palavras funciona. Mas em idiomas como o japonês, o nome vem em uma posição diferente na frase. Seus tradutores não podem reordenar os fragmentos, então a frase acaba ficando gramaticalmente incorreta.

Os placeholders resolvem isso mantendo a frase inteira. Seus tradutores ou ferramenta de tradução recebem a frase completa para trabalhar, incluindo um marcador que mostra onde a variável entra. Eles podem colocar esse marcador onde a gramática do idioma deles exigir.

Veja como os placeholders se parecem em diferentes formatos de arquivo:

JSON:

{ "greeting": "Hello, {name}!" }

YAML:

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

A sintaxe varia de acordo com o formato, mas o princípio é o mesmo.

Construa sua UI para lidar com textos mais longos

A maioria dos idiomas é mais longa que o inglês. Um botão que se encaixa perfeitamente na sua UI em inglês frequentemente será cortado em alemão, francês ou espanhol. Se você construiu seu layout em torno de larguras fixas, você terá uma UI quebrada em cada idioma que adicionar.

Estas são as taxas de expansão típicas com as quais você está trabalhando:

Palavras individuais podem se expandir muito mais do que essas médias. “FAQ” se torna “Preguntas frecuentes” em espanhol — isso é um aumento de 567%.

A solução é construir layouts flexíveis em vez de fixos. Em vez de definir uma largura fixa em um botão, deixe-o crescer com seu conteúdo:

Antes — a largura fixa quebra em idiomas mais longos

button { width: 120px; }

Depois — cresce com o texto traduzido

button {
  min-width: 120px;
  width: auto;
  padding: 8px 16px;
}

Pense nisso na fase de design. Se você projetar para o inglês primeiro e traduzir depois, passará mais tempo depurando problemas de layout em cada idioma do que teria gasto construindo flexibilidade desde o início.

Escreva textos que sejam fáceis de traduzir

A forma como você escreve seu texto de origem afeta a qualidade da tradução. Frases vagas, expressões idiomáticas e jogos de palavras inteligentes frequentemente produzem traduções confusas ou incorretas.

Os problemas mais comuns a evitar:

Frases incompletas

Uma string como “No items” pode significar várias coisas. Não há itens no carrinho? Uma pesquisa não retornou resultados? Seu tradutor tem que adivinhar, e um palpite errado significa uma tradução incorreta.

Escreva frases completas com um sujeito e verbo claros.

Antes — ambíguo

"No items"

Depois — significado claro

"You have no items in your cart."

Expressões idiomáticas

“This is a piece of cake” (Isso é moleza) faz sentido para um falante nativo de inglês. Traduzido literalmente para o alemão, seus usuários vão se perguntar por que seu aplicativo está falando sobre sobremesa. A maioria das expressões só funciona no idioma em questão, então é melhor evitá-las completamente.

Vocabulário complexo

Palavras simples são traduzidas de forma mais confiável. Escreva “remove” em vez de “eliminate” e “use” em vez de “utilize”. Na dúvida, escolha a palavra mais curta e comum.

Lide com datas, números e moedas corretamente

Os formatos de data e número variam significativamente entre os locales. Fazer o hardcoding desses formatos causa o mesmo problema que fazer o hardcoding de texto: funciona em um mercado e quebra em outros.

Use os utilitários de localização integrados do seu framework para formatá-los automaticamente com base no locale do usuário.

JavaScript:

Antes

const price = '$' + amount.toFixed(2);

Depois

const price = new Intl.NumberFormat(userLocale, {
  style: 'currency',
  currency: currencyCode
}).format(amount);

Ruby on Rails:

Antes

"$#{price}"

Depois

number_to_currency(price, locale: I18n.locale)

Dessa forma, o mesmo código lida com a formatação corretamente para cada locale que você suporta.

Planeje para o locale, não apenas para o idioma

Idioma e locale não são a mesma coisa. Espanhol é um idioma. Espanhol mexicano (es-MX), espanhol da Espanha (es-ES) e espanhol argentino (es-AR) são locales. As diferenças entre eles vão além do vocabulário. Formatos de data, moeda, referências culturais e tom podem variar.

Se você especificar apenas um código de idioma sem um locale, corre o risco de mostrar o conteúdo errado para usuários em regiões específicas.

Tome o francês como exemplo:

Ao configurar seus arquivos de recursos, use códigos de locale completos em vez de apenas códigos de idioma. Isso lhe dá a flexibilidade de servir conteúdo diferente para regiões diferentes sem reestruturar sua configuração mais tarde.

Dê aos tradutores o contexto de que precisam

Se você decidir trabalhar com tradutores humanos, tenha em mente que eles trabalham diretamente a partir dos seus arquivos de recursos. Sem informações adicionais, tudo o que eles veem é a própria string. Eles não têm como saber onde ela aparece na UI, a que se refere ou em quanto espaço a tradução precisa caber.

Uma string como “Cancel” pode se referir ao cancelamento de um pedido, de uma assinatura ou do envio de um formulário. Cada um desses casos pode ser traduzido de forma diferente dependendo do idioma.

Adicione comentários aos seus arquivos de recursos para explicar o que cada string faz e onde ela aparece:

JSON com comentários de contexto

{
  // Button in the checkout flow. Cancels the current order. Keep short.
  "checkout.cancel_button": "Cancel",

  // Error message shown when login fails. Followed by a link to reset password.
  "auth.login_error": "Incorrect email or password."
}

Se você usar uma ferramenta de tradução, a maioria das plataformas permite anexar capturas de tela que mostram onde essas strings aparecem. Isso permite que as ferramentas de tradução produzam traduções significativamente mais precisas do que quando trabalham apenas com texto.

Configure a detecção de idioma

Uma vez que suas strings estão em arquivos de recursos e sua UI é flexível, você precisa mostrar a cada usuário o idioma certo automaticamente. A maioria dos frameworks lida com isso usando bibliotecas i18n integradas.

React com react-i18next:

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources,
    fallbackLng: 'en',
    detection: {
      order: ['navigator', 'localStorage']
    }
  });

Ruby on Rails:

before_action :set_locale

def set_locale
  I18n.locale = extract_locale_from_accept_language_header || I18n.default_locale
end

Sempre defina um idioma de fallback. Quando um arquivo de tradução está faltando ou uma string ainda não foi traduzida, seu aplicativo mostra o fallback em vez de uma chave quebrada como auth.login_error.

Para aplicativos web, você também pode permitir que os usuários substituam o idioma detectado manualmente. Armazene a escolha deles para que ela persista entre as sessões:

// Save the user's choice
localStorage.setItem('userLanguage', selectedLanguage);

// Check for a saved choice first, then fall back to the browser language
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

Aplicativos móveis geralmente não precisam de um seletor de idiomas. Os usuários esperam que os aplicativos móveis sigam as configurações do dispositivo.

Escolha uma ferramenta de localização

Um fluxo de trabalho de localização manual se parece mais ou menos com isto: exportar strings para uma planilha, enviá-la para um tradutor, esperar vários dias, recebê-la de volta, copiar as traduções para seus arquivos, descobrir que você esqueceu 12 strings e começar tudo de novo. Isso não escala.

Uma ferramenta de localização de software gerencia todo o fluxo de trabalho para você. Uma boa ferramenta irá:

• Conectar-se ao seu repositório, detectar strings novas e alteradas e manter as traduções atualizadas continuamente
• Dar à sua equipe um local central para gerenciar todas as traduções
• Incluir recursos de CAT integrados, como memória de tradução, detecção de limite de comprimento e gerenciamento de terminologia

A PTC faz tudo isso. Além disso, o teste cobre suas primeiras 20.000 palavras em 2 idiomas, e começar leva menos de 5 minutos.

Saiba como a PTC lida com a localização de software

Teste cada versão localizada antes do lançamento

A tradução não é o passo final. Antes de publicar uma versão localizada, teste-a da mesma forma que você testaria qualquer outro lançamento.

Layout: O texto se encaixa sem ser cortado? A navegação ainda funciona ou você está vendo um estouro?

Funcionalidade: Os formulários são enviados corretamente? As mensagens de erro aparecem no idioma certo? A pesquisa lida com caracteres acentuados como é, ñ e ü?

Formatação: As datas estão no formato certo para o locale? Os números e as moedas estão formatados corretamente? O símbolo da moeda está na posição certa?

Idiomas da direita para a esquerda: Se você suporta árabe ou hebraico, teste todo o layout RTL separadamente. O suporte a RTL afeta mais do que a direção do texto. Ele afeta todo o layout da sua UI.

Integre os testes de localização ao seu processo de QA desde o início. Encontrar um fluxo de checkout quebrado em alemão através de avaliações de usuários é significativamente mais caro do que detectá-lo antes do lançamento.

Quanto custa a localização de software?

Uma boa localização de software não precisa ser cara. O maior fator no seu orçamento não é quantos idiomas você suporta. É como você traduz.

A tradução humana profissional para software geralmente custa entre $ 0,10 e $ 0,30 por palavra. Para um aplicativo de tamanho médio com 15.000 palavras, isso representa de $ 1.500 a $ 4.500 por idioma, antes de você considerar testes, gerenciamento de projetos ou atualizações futuras toda vez que seu produto mudar.

A tradução por IA com uma ferramenta como a PTC custa uma fração disso:

Após o teste, a PTC funciona em um modelo Pay-As-You-Go. Suas primeiras 500 palavras de cada mês são gratuitas. Quanto mais você traduz, menor é a sua tarifa por palavra e, uma vez que você atinge uma tarifa menor, você a mantém por três meses, mesmo que seu volume caia.

Para obter um valor exato para o seu projeto, use a calculadora de custos da PTC ou faça o upload do seu arquivo de recursos diretamente para ver o custo antes de se comprometer.

Calcule seu custo de tradução

Configure seu processo de localização de software em 3 passos

As melhores práticas de localização de software acima cobrem muito terreno. Algumas delas, como escrever textos traduzíveis ou planejar para o locale, exigem decisões deliberadas da sua equipe. Mas grande parte do trabalho técnico, como detectar alterações de strings, gerenciar arquivos de tradução, sinalizar problemas de comprimento e manter as traduções sincronizadas, pode ser automatizada com a ferramenta certa.

Veja como estabelecer um processo de localização funcional com a PTC.

Cadastre-se na PTC

Crie um projeto na PTC, faça o upload dos seus arquivos de recursos e selecione seus idiomas de tradução. Durante o teste, você pode selecionar 2 idiomas.

A PTC gera automaticamente uma descrição do seu aplicativo com base no arquivo enviado. Revise a descrição e mantenha-a ou edite-a. Você também pode fazer o upload de traduções pré-existentes e adicionar um glossário de termos que devem ser sempre traduzidos de uma maneira específica, como nomes de produtos ou terminologia técnica.

Toda a configuração leva menos de 5 minutos.

Visualize e refine as traduções

Quando as traduções estiverem prontas, em vez de editar strings individuais manualmente ou adicionar membros à equipe para lidar com revisões em idiomas específicos, você pode fazer uma revisão de tradução por IA com a PTC.

O AI Visual QA leva o processo padrão de revisão por string mais além, examinando sua UI real em cada idioma de destino.

O que você para de fazer:

• Abrir manualmente seu produto em cada idioma de destino para verificar problemas de exibição
• Coordenar revisores de QA que falam os idiomas de destino
• Descobrir layouts quebrados ou strings faltando após um lançamento

O que você ganha em vez disso:

• A PTC revisa sua UI traduzida visualmente e encontra problemas que a inspeção de strings não consegue detectar
• Problemas encontrados nas traduções geradas pela PTC são corrigidos automaticamente
• Cada idioma é revisado antes do lançamento, em minutos em vez de horas

Para começar, vá para a aba AI Visual QA no seu painel. Dependendo do tipo de software que você está traduzindo, você poderá fazer o upload de capturas de tela da sua UI ou usar a extensão do navegador Visual QA da PTC para gravar as telas para revisão.

A PTC fará uma varredura em busca de problemas que só aparecem quando seu aplicativo está em execução. Ela corrige automaticamente problemas no nível da tradução, como frases estranhas, tom errado ou texto que não se encaixa no contexto. Problemas no nível do código, como chaves ausentes, strings hardcoded e bugs de formatação, são sinalizados para sua equipe resolver no código-fonte.

Conecte seu fluxo de trabalho de desenvolvimento

Quando você estiver confortável com o funcionamento da PTC, faça o upgrade para o Pay-As-You-Go para acessar os recursos Pro, como conectar a PTC ao seu repositório do GitHub, GitLab ou Bitbucket. Com essa integração, a PTC detecta strings novas e alteradas automaticamente e mantém suas traduções atualizadas sem uploads manuais de arquivos.

Se você quiser ir além, a API da PTC permite integrar a tradução diretamente no seu pipeline de CI/CD, para que as versões localizadas estejam sempre prontas para publicar junto com o idioma de origem.

Comece a usar a PTC por 30 dias

Exemplo de localização de software: Traduzindo o WPML com a PTC

O WPML é um dos plugins multilíngues mais usados para WordPress. Mantê-lo traduzido em 23 idiomas não é opcional. Faz parte de todo lançamento.

Por anos, a equipe fez isso da maneira tradicional: contratando tradutores humanos profissionais, gerenciando arquivos de glossário e coordenando atualizações entre os idiomas para cada lançamento. A cada vez, eles tinham que reexplicar o produto, a terminologia e as expectativas do zero. O custo variava de $ 1.000 a $ 8.000 por lançamento.

Eles tentaram alternativas: crowdsourcing, fluxos de trabalho automatizados e modelos híbridos. Nada resolveu o problema.

Desde a mudança para a PTC, os lançamentos saem no prazo. As traduções são completas, precisas e consistentes em todos os 23 idiomas, sem congelamento de strings, sem sobrecarga de coordenação e sem atrasos.

Antes da PTC

Depois da PTC

Comece a localizar seu software hoje mesmo

O teste da PTC cobre suas primeiras 20.000 palavras em 2 idiomas. Começar leva menos de 5 minutos.

Comece seu teste