Localização — a essência, adaptação de conteúdo ao idioma e região

O que é Localização (l10n) e como difere de i18n?

Localização (abreviada como l10n — 10 letras entre “l” e “n”) é o processo de adaptar um aplicativo a um idioma e região específicos. Se i18n é a base arquitetural, então l10n é o conteúdo. i18n torna a tradução possível, l10n a executa. A localização inclui: traduzir todos os textos da interface, adaptar formatos de data e número, substituir imagens culturalmente sensíveis, ajustar textos legais (política de privacidade, EULA), configurar sistemas de pagamento para a região e testar em dispositivos alvo.

ROI de negócio — a localização impacta diretamente a conversão. Segundo a CSA Research (2023), 76% dos usuários preferem comprar em aplicativos no seu idioma nativo e 40% nunca compram em um idioma estrangeiro. A localização para japonês de um aplicativo de varejo aumenta a conversão em média 150% (Google, 2022). Aplicativos localizados recebem de 2 a 3 vezes mais instalações orgânicas nas App Store e Google Play regionais graças ao ASO regional (palavras-chave no idioma alvo).

i18n vs l10n — dois lados do mesmo processo. i18n: extrair strings para recursos, suporte RTL, formatação de números. Feito uma vez pelos desenvolvedores. l10n: traduzir strings, adaptar conteúdo, testes locais. Feito repetidamente por tradutores e QA para cada local. Na IT Sectr, alocamos 20–30% do tempo da sprint para localização de cada novo idioma — isso inclui tradução, revisão, testes em dispositivos e correção de bugs.

Localização no iOS: Localizable.strings e Base Internationalization

Localizable.strings — o arquivo principal para armazenar traduções no iOS. Cada local tem sua própria pasta .lproj: en.lproj/Localizable.strings, ru.lproj/Localizable.strings, de.lproj/Localizable.strings. Formato: “chave” = “valor”; (com ponto e vírgula). A Apple usa Base Internationalization: Storyboard e XIB são criados uma vez (Base.lproj), e as strings da interface são exportadas para Localizable.strings para cada idioma. Isso elimina a necessidade de criar cópias do XIB para cada local.

// en.lproj/Localizable.strings
// "settings.title" = "Configurações";
// "profile.greeting" = "Olá, %@!";
// "items.count" = "%d item(ns)";

// ru.lproj/Localizable.strings
// "settings.title" = "Configurações";
// "profile.greeting" = "Olá, %@!";
// "items.count" = "%d item(ns)";

// Carregar string por chave
navigationItem.title = NSLocalizedString(
    "settings.title",
    comment: "Título da tela de configurações"
)

// String com parâmetro
let name = "Ana"
greetingLabel.text = String.localizedStringWithFormat(
    NSLocalizedString("profile.greeting", comment: ""), name
)

// Importação XLIFF (Xcode → Editor → Importar localizações)
// Atualiza automaticamente os arquivos .lproj após o trabalho do tradutor

Base Internationalization — a abordagem da Apple onde a interface (Storyboard, XIB) é criada uma vez em Base.lproj. Ao adicionar um idioma, o Xcode exporta strings do Base para um arquivo XLIFF. O tradutor traduz o XLIFF. Após a importação, o Xcode cria .lproj com as strings traduzidas. Vantagem: não é necessário duplicar o XIB para cada idioma. Limitação: para idiomas RTL (árabe, hebraico), pode ser necessário um XIB separado com layout espelhado.

InfoPlist.strings e localização de metadados

InfoPlist.strings — arquivo para localizar o nome do aplicativo (CFBundleDisplayName), permissões de câmera/microfone (NSCameraUsageDescription) e outros valores do Info.plist. Criado em .lproj: ru.lproj/InfoPlist.strings. Formato: CFBundleDisplayName = “Meu App”; NSCameraUsageDescription = “O aplicativo precisa de acesso à câmera para tirar fotos”;. Sem a localização do InfoPlist.strings, os diálogos do sistema estarão em inglês.

Localização no Android: values-ru e recursos localizados

Recursos Android para localização são organizados através de qualificadores nos nomes dos diretórios. Para russo — res/values-ru/, para alemão — res/values-de/, para português brasileiro — res/values-pt-rBR/. O Android suporta mais de 160 locais. O sistema seleciona automaticamente os recursos com base no idioma do dispositivo (Locale.getDefault()). Se um local exato não for encontrado, os recursos de values/ (local base, geralmente en) são usados.

// res/values/strings.xml (base — inglês)
<string name="settings_title">Settings</string>
<string name="greeting">Hello, %s!</string>

// res/values-ru/strings.xml (russo)
<string name="settings_title">Configurações</string>
<string name="greeting">Olá, %s!</string>

// res/values-de/strings.xml (alemão)
<string name="settings_title">Einstellungen</string>
<string name="greeting">Hallo, %s!</string>

// Kotlin — código unificado para todos os idiomas
textView.text = getString(R.string.settings_title)

// String com parâmetro
val greeting = getString(R.string.greeting, userName)

// Imagens localizadas
// res/drawable-ru/flag.png — bandeira para a versão russa
// res/drawable/flag.png — bandeira padrão

// Localização de layouts (para idiomas RTL)
// res/layout-ar/activity_main.xml — versão árabe

Localização além das strings — o Android permite localizar imagens (res/drawable-ru/), cores (res/values-ru/colors.xml), dimensões (res/values-ru/dimens.xml), animações, menus e até layouts inteiros. Para idiomas com diferentes comprimentos de palavras (o alemão é 30–40% mais longo que o inglês), use dimens.xml localizados com larguras de botão aumentadas. Para regiões com diferente simbolismo de cores (branco é luto na China), use colors.xml localizados.

Teste de localização no dispositivo

Teste — alterne o idioma do dispositivo para o idioma alvo através de Configurações → Sistema → Idioma. Verifique: todas as strings estão traduzidas, as datas estão formatadas corretamente, os números exibem com o separador adequado, as imagens correspondem à região, o layout não quebra com strings longas. Para automação, use Espresso com LocaleTestRule (Android Testing Library) — permite executar testes com diferentes locais sem alterar o idioma manualmente.

Adaptação cultural: o que traduzir além do texto

Características culturais — a localização não se limita a traduzir strings. O simbolismo das cores varia: vermelho é sorte na China, perigo nos EUA, luto na África do Sul. Branco é pureza na Europa, luto na China. Ícones de gestos: polegar para cima é positivo nos EUA, um insulto no Oriente Médio. Imagens de pessoas: em países árabes, imagens de mulheres de biquíni são inaceitáveis. Símbolos religiosos: cruz, crescente, estrela de Davi devem ser usados apenas no contexto apropriado.

Requisitos legais — cada país tem suas próprias leis sobre produtos digitais. GDPR (UE) — consentimento obrigatório para cookies e processamento de dados. CCPA (Califórnia) — direito de excluir dados. Lei de Dados Pessoais (Rússia, 152-FZ) — armazenamento de dados em servidores russos. LGPD (Brasil) — equivalente ao GDPR. Pagamentos: na China são necessários Alipay/WeChat Pay, na Índia — UPI, no Brasil — Boleto e PIX. Configure o gateway de pagamento para a região antes de lançar a localização.

Exemplos e conteúdo — adapte os exemplos à região. Para localização alemã, use o sistema métrico (kg, km), para americana — imperial (lb, mi). Números de telefone, códigos postais, endereços — tudo é formatado de forma diferente. Exemplos de moeda: ¥1000 no Japão, $9.99 nos EUA, 999 ₽ na Rússia. Imagens de comida, roupas e interiores devem corresponder aos padrões regionais. Na IT Sectr, recomendamos contratar consultores locais para verificar a adaptação cultural.

Processo de localização: ferramentas, tradutores, CI/CD

Ferramentas de localização — plataformas profissionais automatizam o processo: Lokalise, Crowdin, POEditor, Smartling, Phrase. Elas se integram ao repositório, importam automaticamente novas strings, rastreiam mudanças (Delta updates — apenas strings alteradas são traduzidas), fornecem Memória de Tradução (TM — armazenamento de frases traduzidas anteriormente) e Glossário. Custo médio de tradução profissional: $0.08–0.15 por palavra (dependendo do idioma).

Processo — (1) O desenvolvedor adiciona chaves i18n ao código, envia ao repositório. (2) CI/CD (GitHub Actions / GitLab CI) envia automaticamente novas chaves à plataforma de localização. (3) Tradutores recebem notificação, traduzem e salvam. (4) Arquivos traduzidos criam automaticamente um PR no repositório. (5) QA verifica a localização em dispositivos. (6) Lançamento. Ciclo para um local: 2–5 dias úteis (dependendo do volume). Para 10 locais: 5–15 dias com trabalho paralelo de tradutores.

Tradução automática + revisão humana — o padrão moderno. A tradução por rede neural (DeepL, Google Translate, GPT-4) oferece 80–90% de qualidade para pares de idiomas populares. Um tradutor humano verifica: terminologia, contexto (palavras podem ter significados diferentes em telas diferentes), adaptação cultural. Na IT Sectr, usamos uma abordagem híbrida: tradução por ML + revisão por falante nativo. Para strings críticas (legais, pagamento) — apenas tradução profissional. Economia: até 60% do custo mantendo a qualidade.