OpenL logo

Como Localizar um Aplicativo Móvel

OpenL Team 3/14/2026

TABLE OF CONTENTS

Se você está pesquisando como localizar um aplicativo móvel, geralmente não precisa de “dicas de tradução”. Você precisa de um fluxo de trabalho seguro para lançamento que cubra strings do app, layout, regras de plural, suporte a escrita da direita para a esquerda, capturas de tela e metadados da loja sem quebrar o produto.

Essa é a distinção fundamental: localização de aplicativos móveis não é apenas traduzir texto. É adaptar o app, a página do produto e o processo de QA para cada mercado-alvo. A Apple afirma que a App Store está disponível em 175 regiões e 40 idiomas, enquanto o Android 13 introduziu preferências de idioma por aplicativo em nível de sistema. Em outras palavras, ambas as principais plataformas agora assumem que a escolha de idioma é uma experiência central do produto, não algo secundário.

Este guia percorre os passos práticos para equipes de iOS e Android.

Visão geral:

  • Separe a localização dentro do app da localização na App Store e Google Play.
  • Externalize as strings antes de traduzir qualquer coisa.
  • Trate plurais, variáveis, datas, moedas e RTL desde o início.
  • Teste com pseudo-idiomas antes de publicar traduções reais.
  • Localize capturas de tela e ativos da loja, não apenas descrições.

O Que a Localização de Aplicativos Móveis Realmente Inclui

O trabalho de localização geralmente se divide em duas frentes.

1. Localização dentro do app

Este é o produto em si:

  • Strings de interface
  • Mensagens de erro e textos de onboarding
  • Datas, horários, números, moedas e unidades
  • Strings sensíveis a plurais e gênero
  • Expansão de layout e comportamento da direita para a esquerda
  • Imagens ou ícones que contêm texto ou significado direcional

A Apple recomenda explicitamente o uso de Xcode, APIs do Foundation, Auto Layout, suporte a Unicode, catálogos de ativos localizados e símbolos sensíveis à direção para preparar apps para mercados globais. O Android recomenda de forma semelhante recursos sensíveis à localidade, suporte a idioma do app e layouts preparados para RTL em vez de texto e posicionamento fixos no código.

2. Localização da listagem na loja

É assim que os usuários descobrem seu app:

  • Nome do app
  • Subtítulo ou descrição curta
  • Descrição completa
  • Palavras-chave
  • Capturas de tela
  • Prévias do app ou vídeos promocionais

Trate isso como uma entrega separada. Um app bem localizado ainda pode ter baixo desempenho se a página do produto for genérica, não traduzida ou visualmente desalinhada para o mercado-alvo.

Comece com Internacionalização, Não com Tradução

A tradução é o último passo em um pipeline que começa com a estrutura.

Externalize strings e mantenha uma localidade padrão completa

No Android, o Google alerta que seu arquivo padrão res/values/strings.xml deve definir todas as strings que seu app precisa. Se o arquivo padrão estiver incompleto e o dispositivo estiver usando uma localidade não suportada, o app pode falhar ao carregar e mostrar um erro com um botão Force Close. É por isso que a localização começa com a higiene dos recursos, não com a seleção de idiomas.

Para iOS, a Apple recomenda separar texto e imagens visíveis ao usuário do código executável para que possam ser localizados como arquivos de recursos. Em fluxos de trabalho modernos da Apple, catálogos de strings são a abordagem recomendada no Xcode 15 e posteriores para strings que contêm plurais.

Regra prática:

  • nunca coloque texto de interface fixo em views ou controllers
  • mantenha um único idioma-fonte canônico
  • certifique-se de que toda string visível ao usuário tenha uma chave estável, contexto e fallback
  • inclua comentários para tradutores em strings ambíguas

Um pequeno exemplo torna isso mais fácil de visualizar.

O Android geralmente começa com um arquivo padrão strings.xml:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Então sua interface lê o recurso em vez de codificar inglês diretamente:

Text(text = stringResource(R.string.checkout_cta))

Em plataformas Apple, o Xcode 15+ geralmente gerencia a mesma ideia em um catálogo de strings. Um trecho simplificado de Localizable.xcstrings pode se parecer com isto:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

Você não precisa memorizar o formato do arquivo. A lição operacional é mais simples: toda string visível ao usuário precisa de uma fonte única de verdade, contexto suficiente para os tradutores e um fallback seguro quando uma localidade está incompleta.

Se seu app também envia arquivos de idioma estruturados, nosso guia sobre Melhores Tradutores JSON em 2026 pode ajudá-lo a pensar em automação e preservação de formato.

Se você quer uma opção direta de ferramenta para arquivos de recursos de apps, o OpenL JSON Translator vale a pena conferir. Ele é projetado para traduzir arquivos .json sem quebrar chaves ou estrutura, que é exatamente o que você precisa quando as strings do app estão armazenadas em arquivos de localização legíveis por máquina. O fluxo de trabalho é simples: faça upload do JSON exportado do seu app, CMS ou pipeline de localização, escolha o idioma de destino e baixe um arquivo JSON traduzido com a mesma estrutura. De acordo com a página do produto, ele suporta mais de 100 idiomas e arquivos de até 50 MB, tornando-o uma ferramenta prática de primeira passagem para equipes de localização de apps que lidam com conteúdo estruturado.

Suporte à seleção de idioma no nível do app

Os usuários esperam cada vez mais poder escolher o idioma do app separadamente do idioma do dispositivo.

Em plataformas Apple, os usuários podem selecionar seu idioma preferido para um app independentemente do idioma do dispositivo. No Android, o Android 13 adicionou uma configuração centralizada de idioma por app, e o Google recomenda habilitar o suporte automático de idioma por app ou conectar seu seletor às APIs oficiais.

Isso importa para produtos reais. Usuários bilíngues e multilíngues podem manter o telefone em inglês, mas preferir um app de compras, banco ou entrega em outro idioma. Se seu app impõe um único modelo de idioma, você está criando atrito antes mesmo que a qualidade da tradução se torne uma questão.

Use a stack de localização da plataforma

Resista à tentação de inventar um sistema de localização paralelo, a menos que realmente precise de um.

Para a maioria das equipes, a stack padrão da plataforma é suficiente:

  • iOS: catálogos de strings, Localizable.strings, .stringsdict, formatadores do Foundation, Auto Layout
  • Android: res/values/, pastas de recursos específicas por localidade, LocaleConfig, setApplicationLocales(), supportsRtl

Infraestrutura de localização personalizada faz sentido em escala muito grande, mas adiciona sobrecarga operacional. Comece com o sistema nativo e amplie apenas onde sentir dor real.

Localize as Partes Que a Maioria das Equipes Deixa Passar

As equipes frequentemente traduzem frases visíveis e perdem a mecânica do produto ao redor delas.

Plurais, variáveis e gramática

Regras de plural não são universais. As regras de plural do Unicode CLDR definem categorias como zero, one, two, few, many e other, e diferentes idiomas usam diferentes subconjuntos. A Apple observa que em fluxos de trabalho mais antigos com .stringsdict, other é a única categoria obrigatória, mas pular categorias específicas do idioma ainda pode produzir saídas gramaticalmente incorretas. Android e iOS dependem de tratamento de plural sensível à localidade por um motivo.

É aqui que a tradução automática ingênua falha:

  • 1 file vs 2 files é fácil em inglês
  • Idiomas eslavos frequentemente precisam de mais de duas formas de plural
  • Alguns idiomas alteram substantivos, verbos ou palavras adjacentes juntos

Nunca construa interface pluralizada concatenando fragmentos como "You have " + count + " messages". Use recursos de plural da plataforma em vez disso.

Aqui está a forma mínima disso em cada plataforma.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>
Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

Exemplo legado de .stringsdict no iOS:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

No Xcode 15 e posteriores, a Apple recomenda tratar plurais em catálogos de strings em vez disso, mas o princípio permanece o mesmo: dê à plataforma um padrão de mensagem e deixe-a escolher a forma correta do idioma.

Para salvaguardas mais profundas no fluxo de trabalho em torno de placeholders e strings estruturadas, consulte Como Traduzir Documentação Técnica Sem Quebrar o Código.

Datas, números, moedas e unidades

A Apple recomenda explicitamente o uso de APIs do Foundation para formatar datas, comprimentos, pesos, preços e símbolos de moeda em diferentes localidades. O mesmo princípio se aplica no Android: formate dados com APIs sensíveis à localidade em vez de codificar pontuação, marcadores decimais ou ordem de unidades.

Falhas típicas incluem:

  • 03/04/2026 significando coisas diferentes em diferentes regiões
  • Sinais de dólar fixos no código para mercados que não usam USD
  • 1,234.56 exibido incorretamente em localidades que usam vírgulas como separadores decimais
  • Unidades de medida mostradas no sistema errado

Se seu app contém agendamento, cobrança, janelas de entrega ou análises, isso faz parte da localização, não do polimento.

Expansão de layout e suporte à escrita da direita para a esquerda

O inglês geralmente é compacto. O alemão fica mais longo. O árabe e o hebraico invertem a direção de leitura. Um layout que parece bom em inglês pode quebrar seriamente em outras localidades.

A Apple recomenda testar com pseudo-idiomas, incluindo um pseudo-idioma da direita para a esquerda e um pseudo-idioma de comprimento duplo, antes mesmo de importar traduções reais. O Android recomenda usar start e end em vez de left e right, habilitar android:supportsRtl="true" e testar layouts RTL no dispositivo com Force RTL.

Sua checklist aqui é simples:

  • Permita que botões e rótulos cresçam
  • Evite contêineres de texto com largura fixa para interface importante
  • Espelhe interface direcional quando apropriado
  • Verifique ícones, setas, fluxos de progresso e carrosséis em RTL
  • Teste texto com direção mista, como interface em árabe com nomes de produtos ou códigos de cupom em latim

Imagens, ícones, capturas de tela e vídeo

A orientação de localização da Apple faz um ponto importante que muitas equipes ignoram: imagens também podem ser localizadas. Isso inclui conjuntos de imagens, conjuntos de símbolos e direcionalidade para símbolos personalizados. Se sua captura de tela contém interface em inglês, texto em inglês em banners ou setas da esquerda para a direita, então a captura de tela em si não está localizada.

Isso é especialmente importante para telas de onboarding, cartões de tutorial e ativos da App Store. Os usuários não separam mentalmente “visuais de marketing” de “idioma do produto”. Eles julgam toda a experiência de uma vez.

Localize Suas Páginas da App Store e Google Play Separadamente

É aqui que muitas equipes perdem instalações mesmo depois de fazer bem o trabalho dentro do app.

Requisitos da App Store para planejar

A Apple recomenda localizar metadados no App Store Connect, incluindo a descrição do app, palavras-chave, prévias do app e capturas de tela. A Apple também diz que você pode exibir até 10 capturas de tela na sua página de produto, e até 3 prévias do app por tamanho de dispositivo e idioma suportados. As prévias do app podem ter até 30 segundos de duração, e as capturas de tela importam ainda mais quando nenhuma prévia está presente porque as primeiras uma a três capturas de tela podem aparecer nos resultados de busca.

Isso tem duas implicações:

  1. Suas primeiras capturas de tela são ativos de descoberta, não apenas documentação.
  2. Você deve localizar capturas de tela e prévias para os mercados prioritários em vez de reutilizar ativos em inglês em todos os lugares.

Requisitos do Google Play para planejar

O Google Play trata a localização de listagens como seu próprio fluxo de trabalho também. O Play Console permite adicionar texto localizado, capturas de tela no idioma local e ativos gráficos localizados. Se você adicionar traduções de texto sem ativos gráficos localizados, o Google diz que os visuais do idioma padrão ainda serão exibidos.

O Google também observa que se você não adicionar suas próprias traduções de listagem da loja, os usuários podem ver uma tradução automatizada com um aviso de que foi gerada automaticamente. Isso é útil como fallback, mas não é uma estratégia forte de entrada no mercado.

Um recurso atual especialmente relevante: o Play Console diz que pode traduzir continuamente strings do app usando modelos Gemini sem custo. Mais especificamente, o Google diz que isso se aplica a strings do app de strings.xml em pacotes de app enviados para lançamentos em rascunho, e que você pode pré-visualizar as traduções geradas em um emulador integrado antes de publicar. Essa é uma maneira eficaz de acelerar a cobertura da primeira passagem, mas ainda deve ser seguida por revisão humana para fluxos críticos.

Construa um Fluxo de Trabalho de Lançamento e QA

Um bom processo de localização é menos sobre traduzir mais rápido e mais sobre entregar menos surpresas.

Passo 1. Escolha localidades-alvo deliberadamente

Não comece com “traduzir tudo para 20 idiomas”.

Comece com:

  • Seu mix atual de downloads
  • Países que você suporta ativamente
  • Cobertura de cobrança, jurídica e suporte ao cliente
  • Se você consegue localizar tanto o app quanto a listagem da loja juntos

Entregar um mercado de ponta a ponta geralmente supera entregar cinco mercados pela metade.

Passo 2. Crie ativos prontos para localização

Antes de a tradução começar, congele e prepare:

  • Strings-fonte com contexto
  • Lista de capturas de tela por localidade
  • Glossário e regras de nomes de produto
  • Regras de placeholders
  • Orientação de limite de caracteres para textos da loja
  • Responsáveis por revisão específicos por localidade

Se o app usa repositórios separados ou múltiplos formatos de arquivo, padronize nomenclatura e extração cedo.

Passo 3. Teste com pseudolocalização primeiro

Em plataformas Apple, use pseudo-idiomas de comprimento duplo e da direita para a esquerda. No Android, teste localidades não suportadas, Force RTL e configurações de idioma do app. Isso detecta:

  • Botões truncados
  • Cabeçalhos cortados
  • Texto oculto
  • Alinhamento errado
  • Strings não localizadas
  • Suposições fixas de esquerda/direita

Essa é uma das passagens de QA mais baratas que você pode executar.

Passo 4. Execute QA linguístico em dispositivos reais

Depois que as traduções chegarem:

  • Teste fluxos críticos em cada idioma-alvo
  • Compare o comportamento do idioma do sistema e do idioma do app
  • Verifique o comportamento de plurais e placeholders
  • Confira pagamentos, datas e endereços
  • Revise capturas de tela e listagens da loja no mercado

Se um bug afetar onboarding, checkout, verificação de identidade ou notificações, trate-o como bloqueador de lançamento.

Uma checklist para o primeiro sprint de localização

Se este é seu primeiro lançamento sério, mantenha o sprint pequeno o suficiente para terminar de forma limpa:

  • Escolha 1 localidade-alvo, não 10.
  • Congele as strings-fonte para um branch de lançamento.
  • Exporte todas as strings de onboarding, checkout, conta e notificações com comentários de contexto.
  • Capture as capturas de tela que você deseja localizar para a App Store e Google Play.
  • Execute uma passagem de pseudolocalização antes de enviar texto real para tradutores.
  • Traduza strings do app e texto da listagem da loja no mesmo sprint.
  • Reimporte traduções e teste a troca de idioma do app tanto no iOS quanto no Android.
  • Faça QA das 5 principais jornadas de usuário em dispositivos reais.
  • Atualize capturas de tela, prévias do app e metadados da loja para a mesma localidade.
  • Publique primeiro no TestFlight ou em uma faixa interna, depois monitore tickets de suporte e relatórios de falhas.

Essa checklist é intencionalmente enxuta. Uma localidade com uma experiência de app limpa e ativos da loja sincronizados ensina muito mais do que um lançamento apressado em muitos mercados.

Exemplos do Mundo Real

As ideias centrais acima não são teóricas.

DoorDash construiu tradução como um problema de plataforma

Em 2022, a DoorDash disse que já havia traduzido mais de um milhão de strings em quatro idiomas e reduziu a integração de novos idiomas de horas de esforço de desenvolvimento para um único comando em um minuto. A lição interessante não é apenas escala. É estrutura: a DoorDash separou strings estáticas e dinâmicas, adicionou suporte a glossário e guia de estilo, e construiu salvaguardas para impedir que strings não traduzidas escapassem.

Em uma publicação no blog da DoorDash de 2 de fevereiro de 2026, a empresa disse que sua plataforma de onboarding reconstruída agora alimenta cadastros em todos os mercados da DoorDash e suporta lançamentos internacionais rápidos com localização perfeita. Isso é exatamente como a localização madura se parece: fluxos de trabalho reutilizáveis, flexibilidade regional e menos gambiarras pontuais.

Meta tratou localização tanto como um problema de idioma quanto de tamanho do app

A Meta diz que cerca de 57% dos usuários do Facebook para Android e 49% dos usuários do Facebook para iOS usam o app em um idioma diferente do inglês. No mesmo artigo, a Meta diz que remover arquivos de tradução embutidos economizou até 16,6 MB no app iOS e permitiu ao Android adicionar quase uma dúzia de idiomas a mais sem aumentar o tamanho do app.

A conclusão é útil mesmo para equipes menores: localização tem consequências de engenharia. Ela afeta o tamanho do binário, carregamento em tempo de execução, entrega de traduções e mecânica de lançamento, não apenas redação.

Checklist Final Antes de Publicar

Use isto como uma última verificação:

  • Todas as strings visíveis ao usuário estão externalizadas.
  • Os recursos de fallback padrão estão completos.
  • Plurais e placeholders usam suporte de localização nativo da plataforma.
  • Datas, horários, números, moedas e unidades são sensíveis à localidade.
  • Layouts RTL e texto com direção mista foram testados.
  • O texto da listagem da loja está localizado para os mercados-alvo.
  • Capturas de tela e prévias estão localizadas para os idiomas prioritários.
  • A seleção de idioma dentro do app funciona como esperado no iOS e Android.
  • O QA linguístico cobriu as jornadas de usuário mais importantes.

Considerações Finais

A maneira mais simples de pensar sobre localização de aplicativos móveis é esta: traduza o produto, localize a experiência e teste o lançamento.

Se você está fazendo isso pela primeira vez, não busque cobertura global perfeita no primeiro dia. Escolha uma ou duas localidades estratégicas, localize o app e a página da loja juntos, execute uma passagem séria de QA e aprenda com o uso real. Se você já gerencia arquivos de recursos e conteúdo voltado para desenvolvedores, combine este fluxo de trabalho com Como Traduzir Documentação Técnica Sem Quebrar o Código e Melhores Tradutores JSON em 2026.

Se você só puder tomar uma ação esta semana, faça isto: escolha 1 localidade, execute 1 passagem de pseudolocalização e localize 1 listagem correspondente na App Store ou Google Play. Esse teste em três partes vai dizer mais sobre sua prontidão do que traduzir vinte localidades em paralelo.

Se você precisa de uma primeira passagem rápida para textos do app, capturas de tela ou arquivos de idioma estruturados, use automação para acelerar o rascunho e depois mantenha uma etapa de QA humano antes do lançamento. Essa é a parte que protege a confiança do usuário e previne um lançamento “traduzido, mas não verdadeiramente localizado”.

Referências

Tags

i18n how to
Share this post on:
Share this post on X Share this post on Facebook Share this post via WhatsApp

Related Posts

Como Traduzir Listagens da Amazon para Mercados Globais

Como Traduzir Listagens da Amazon para Mercados Globais

Aprenda a traduzir listagens da Amazon seguindo as próprias regras da plataforma, incluindo a política de títulos, Brand Analytics, Conteúdo A+ e QA antes do lançamento.

2026/3/24
Como Traduzir uma Certidão de Nascimento

Como Traduzir uma Certidão de Nascimento

Um guia passo a passo para traduzir certidões de nascimento para imigração, pedidos de visto e uso legal, incluindo exigências de tradução juramentada ou certificada por país e erros comuns que levam à rejeição.

2026/3/6
Como Traduzir um Diploma

Como Traduzir um Diploma

Precisa de uma tradução certificada de diploma para imigração, universidade ou trabalho no exterior? Veja como funcionam a certificação, a autenticação e os apostilamentos—além de regras específicas de cada país e dicas para evitar rejeições.

2026/1/25