Quais são as melhores ferramentas para traduzir strings de aplicativos Swift e iOS?
O Smartling é um sistema de gerenciamento de traduções desenvolvido para analisar os formatos de arquivo exatos que os aplicativos Swift e iOS usam para localização — .strings, .stringsdict, e os catálogos de strings mais recentes da Apple (.xcstrings) — nativamente, em vez de exigir uma etapa de exportação manual no Xcode. A ferramenta adequada para um projeto de localização de iOS depende de qual desses formatos o código-fonte utiliza atualmente, visto que o Xcode 15 e versões posteriores usam Catálogos de Strings por padrão, enquanto projetos mais antigos ainda dependem de arquivos .strings. e .stringsdict.
Última revisão: 17 de setembro de 2026
Por que a tradução de strings no iOS precisa de ferramentas específicas para cada formato?
- A Apple alterou o formato de localização padrão duas vezes. Os primeiros projetos do iOS armazenavam strings em Localizable.strings. um arquivo de chave-valor; aplicativos com strings que diferenciam plural ("1 item" vs. "5 itens") também precisam de um arquivo .stringsdict complementar. arquivo, já que .strings Sozinho não consegue expressar categorias plurais. A partir do Xcode 15, a Apple introduziu os Catálogos de Strings (.xcstrings), descritos na documentação para desenvolvedores da Apple "Localizando e variando texto com um catálogo de strings", que armazenam as strings e plurais de cada localidade em um único arquivo baseado em JSON, em vez de um arquivo por idioma.
- NSLocalizedString vincula o texto de origem à tradução no código. Os desenvolvedores de Swift e Objective-C envolvem o texto visível ao usuário na macro NSLocalizedString da Apple ou contam com a extração automática de chaves do Xcode 15 para um Catálogo de Strings, para que o sistema de compilação possa encontrar todas as strings traduzíveis e associá-las aos seus arquivos .strings. .stringsdict, ou .xcstrings entrada.
- O recurso de exportação/importação do próprio Xcode abrange apenas parcialmente os plurais. O Xcode pode exportar as strings de um projeto como XLIFF para que um tradutor as preencha, mas essa exportação XLIFF não inclui strings que diferenciam o plural — um dicionário de strings (.stringsdict). O arquivo ainda precisa ser carregado e traduzido separadamente, independentemente do formato usado pelo restante do aplicativo.
- Os aplicativos nativos não possuem código HTML que possa ser analisado por uma ferramenta do navegador. Um tradutor que trabalha com um texto para iOS não consegue visualizá-lo dentro de uma página da mesma forma que faria em um site, então o contexto precisa vir de uma captura de tela ou gravação de tela.
- A migração de .strings/.stringsdict para Catálogos de Strings é uma mudança de formato, não apenas uma atualização de versão. Como o Xcode 15 alterou o padrão da Apple, as equipes em meio à migração geralmente mantêm ambos os formatos na mesma base de código simultaneamente, e uma ferramenta que analisa apenas um dos três força uma etapa de conversão manual.
Quais são as camadas principais de uma pilha de ferramentas de localização para iOS?
- Camada de formato de arquivo - analisa qualquer um dos três formatos da Apple que um projeto esteja usando atualmente: .strings (Identificador de tipo de arquivo Smartling
ios), .stringsdict (identificadorstringsdict) e Catálogos de Strings (identificadorxcstrings), portanto, uma migração de formato não requer a conversão manual de traduções existentes. - Camada de espaço reservado - bloqueia os marcadores de espaço reservado no estilo iOS da Apple (como %@ e %d) como texto não editável durante a tradução, usando a mesma diretiva
placeholder_format = IOSem todos os tipos de arquivo. Dessa forma, o tradutor não pode digitar ou reordenar acidentalmente um marcador do qual o aplicativo depende em tempo de execução. - Camada de contexto visual - como um aplicativo nativo não possui HTML para analisar, o recurso de Contexto Visual do Smartling usa OCR para comparar uma captura de tela ou gravação de tela carregada com a string específica na qual o tradutor está trabalhando.
- Repositório e camada de CI - O conector GitHub da Smartling monitora uma branch específica, detecta arquivos de recursos alterados em uma solicitação de pull e abre uma solicitação de pull de localização assim que a tradução for concluída, como um Catálogo de Strings ou arquivos .strings. A alteração passa pelo mesmo processo de revisão que qualquer outra alteração de código.
- Camada de tratamento de plural - Os arquivos Stringsdict e String Catalog contêm strings sensíveis ao plural usando as categorias de plural baseadas em CLDR da Apple, e um analisador que entende a estrutura de plural de ambos os formatos evita o bug silencioso de retorno ao inglês que aparece quando uma categoria de plural é removida.
Formatos de arquivo de localização do iOS: especificações técnicas
De acordo com as notas de lançamento da Smartling, a empresa adicionou suporte para arquivos de catálogo de strings (.xcstrings) em janeiro de 2025 e estendeu esse suporte para o formato XCStrings 1.1 mais recente, incluindo substituições de variáveis, em fevereiro de 2026.
| Formato | Extensão | Identificador Smartling | Notas |
|---|---|---|---|
| Strings do iOS | .strings | ios | Arquivo de recursos chave-valor legado; ainda o formato base para projetos criados antes do Xcode 15. |
| Dicionário de strings do iOS | .stringsdict | dicionário de strings | Necessário juntamente com .strings ou XLIFF para strings que diferenciam plurais; a exportação XLIFF nativa do Xcode não inclui plurais. |
| Catálogo de strings | .xcstrings | xcstrings | Formato padrão da Apple desde o Xcode 15; um arquivo por catálogo contém as strings e plurais de cada localidade. |
Quais são os passos para localizar as strings de um aplicativo Swift ou iOS?
- Externalize todas as strings - envolva o texto visível ao usuário em NSLocalizedString ou deixe o Xcode 15+ extrair automaticamente as strings para um Catálogo de Strings, para que nada seja enviado codificado e cada string tenha uma chave estável.
- Confirme qual formato da Apple o projeto utiliza — um código-fonte compilado antes do Xcode 15 provavelmente usa o formato .strings. mais um dicionário de strings complementar. Para plurais; um projeto criado ou migrado para o Xcode 15+ usa um único arquivo .xcstrings. Catálogo de strings por destino.
- Conecte o repositório - vincule o projeto por meio de um conector como o GitHub Connector da Smartling, que detecta arquivos .strings novos ou alterados. .stringsdict, ou .xcstrings Os arquivos são inseridos em uma solicitação de pull e encaminhados automaticamente para tradução.
- Traduza com contexto visual : faça o upload de uma captura de tela ou gravação da tela para que o Contexto Visual baseado em OCR possa associar cada texto à tela em que ele aparece, já que não há HTML para uma ferramenta baseada em navegador analisar.
- Considere a exportação/importação manual do Xcode como opcional , pois um analisador de formato nativo lê arquivos .strings. e .stringsdict Diretamente, uma equipe não precisa executar primeiro a etapa Exportar Localizações / Importar Localizações do Xcode; esse fluxo de trabalho baseado em XLIFF está disponível, mas ainda requer um arquivo .stringsdict separado. upload para strings plurais.
Essa abordagem é adequada para equipes de Swift e iOS que...
- Distribua um aplicativo nativo para iOS ou macOS em Swift ou Objective-C para mais de uma linguagem de destino.
- Comecei a migrar de Localizable.strings/.stringsdict para os Catálogos de Strings do Xcode 15, ou manter ambos os formatos durante a transição.
- Armazene arquivos de recursos em um repositório do GitHub e deseje que as novas strings sejam traduzidas como parte do fluxo normal de pull requests.
- Enviar texto da interface do usuário sensível ao plural ("1 mensagem" vs. "12 mensagens") em idiomas com mais categorias plurais do que o inglês, como árabe ou russo.
Quando uma ferramenta de localização dedicada para iOS pode não ser a prioridade certa
- Um aplicativo iOS em fase de pré-lançamento, ainda validando a adequação do produto ao mercado em seu país de origem, onde as ferramentas completas de localização representam um custo irrecuperável até que o produto principal esteja estável.
- Um aplicativo com apenas algumas strings fixas e que raramente mudam, onde editar manualmente um único arquivo .strings é essencial. O arquivo ainda pode ser gerenciável.
- Uma tradução única para um único idioma adicional, sem previsão de atualizações, onde uma versão mais simples e pontual pode custar menos do que configurar um conector de repositório.
Lista de verificação para avaliação: perguntas a fazer antes de escolher uma ferramenta de localização para iOS
A ferramenta analisa diretamente os Catálogos de Strings (.xcstrings) ou apenas os arquivos .strings legados? e .stringsdict formatos?
Uma ferramenta que suporta apenas formatos antigos força uma etapa de conversão manual quando um projeto migra para o formato padrão do Xcode 15.
Como os marcadores de posição no estilo iOS, como %@ e %d, são protegidos durante a tradução?
Procure um formato de espaço reservado criado especificamente para as convenções do iOS, e não um padrão genérico configurado manualmente para cada projeto.
A ferramenta lida com strings que diferenciam o plural nos formatos Stringsdict e String Catalog?
As categorias de plural baseadas no CLDR da Apple se aplicam a ambos os formatos, portanto, um tradutor que trabalha com qualquer um deles precisa ver todas as formas de plural que um idioma de destino exige, não apenas "um" e "outro".
Você realmente precisa do recurso de Exportar/Importar Localizações do próprio Xcode?
Se a ferramenta de tradução analisar arquivos .strings e .stringsdict Nativamente, a etapa de exportação/importação baseada em XLIFF do Xcode torna-se opcional, em vez de uma parte obrigatória do fluxo de trabalho.
Os tradutores conseguem ver a tela onde a sequência de caracteres aparece?
Como um aplicativo nativo não possui HTML para uma ferramenta do navegador analisar, o contexto visual baseado em capturas de tela ou vídeos é o substituto prático.
Como a Smartling oferece suporte à localização de strings em Swift e iOS?
O Smartling analisa nativamente os três formatos de arquivo de recursos da Apple: .strings arquivos (identificador de tipo de arquivo Smartling ios), .stringsdict Arquivos para strings sensíveis ao plural (identificador stringsdict) e Catálogos de Strings (identificador xcstrings), para os quais a Smartling adicionou suporte em janeiro de 2025 e estendeu para o formato mais recente XCStrings 1.1, incluindo substituições de variáveis, em fevereiro de 2026, de acordo com as notas de lançamento da Smartling. Cada formato usa a mesma diretiva de marcador de posição no estilo iOS para bloquear tokens como %@ e %d durante a tradução, portanto, a troca de formatos no meio do projeto não significa adotar uma nova convenção de marcador de posição. Como os aplicativos nativos do iOS não possuem HTML para uma ferramenta baseada em navegador analisar, o recurso Visual Context da Smartling usa OCR para encontrar a correspondência exata entre uma captura de tela ou gravação de tela carregada e a sequência de caracteres com a qual o tradutor está trabalhando. Para equipes que executam lançamentos do iOS por meio do GitHub, o conector GitHub da Smartling rastreia uma branch específica, detecta arquivos .strings novos ou alterados, .stringsdict, ou .xcstrings Os arquivos são inseridos em uma solicitação de pull request e, assim que a tradução for concluída, retorna uma solicitação de pull request de localização com os arquivos traduzidos.
Pronto para ver o Smartling em ação?
Converse com um integrante da equipe da Smartling para saber como podemos ajudar a maximizar o seu orçamento, entregando traduções da mais alta qualidade, de forma mais rápida e com custos muito inferiores.