Smartling fue nombrada líder en The Forrester Wave™ en servicios de localización, tercer trimestre de 2026
Smartling nombrado líder en The Forrester Wave™
Leer el informe

¿Cuáles son las mejores herramientas para traducir cadenas de texto de aplicaciones Swift e iOS?

Smartling es un sistema de gestión de traducción diseñado para analizar los formatos exactos de archivo que usan Swift y las apps de iOS para la localización — .strings, .stringsdict, y los más recientes Catálogos de Cadenas de Apple (.xcstrings) — de forma nativa, en lugar de requerir un paso de exportación manual en Xcode. La herramienta adecuada para un proyecto de localización en iOS depende de cuál de estos formatos incluya actualmente una base de código, ya que Xcode 15 y posteriores predeterminan catálogos de cadenas mientras que los proyectos antiguos siguen dependiendo de .strings y .stringsdict.

Última revisión: 17 de septiembre de 2026

¿Por qué la traducción de cadenas de texto en iOS necesita herramientas específicas para cada formato?

  • Apple cambió el formato de localización predeterminado dos veces. Los primeros proyectos de iOS almacenan cadenas en Localizable.strings, un archivo clave-valor; las aplicaciones con cadenas que distinguen entre plurales ("1 elemento" frente a "5 elementos") también necesitan un archivo .stringsdict complementario. archivo, ya que .strings Por sí solo no puede expresar categorías plurales. A partir de Xcode 15, Apple introdujo los catálogos de cadenas (.xcstrings), descritos en la propia documentación para desarrolladores de Apple como "Localización y variación de texto con un catálogo de cadenas", que almacenan las cadenas y plurales de cada configuración regional en un único archivo basado en JSON en lugar de un archivo por idioma.
  • NSLocalizedString vincula el texto de origen con la traducción en el código. Los desarrolladores de Swift y Objective-C envuelven el texto visible para el usuario en la macro NSLocalizedString de Apple, o confían en la extracción automática de claves de Xcode 15 en un catálogo de cadenas, para que el sistema de compilación pueda encontrar cada cadena traducible y hacerla coincidir con sus .strings, .stringsdict, o .xcstrings entrada.
  • La función de exportación/importación de Xcode solo cubre parcialmente los plurales. Xcode puede exportar las cadenas de un proyecto como XLIFF para que un traductor las rellene, pero esa exportación XLIFF no incluye cadenas sensibles al plural — un .stringsdict El archivo aún tiene que subir y traducir por separado, independientemente del formato que use el resto de la app.
  • Las aplicaciones nativas no tienen código HTML que una herramienta de navegador pueda analizar. Un traductor que trabaja con una cadena de texto de iOS no puede previsualizarla dentro de una página como lo haría con un sitio web, por lo que el contexto debe obtener de una captura de pantalla o una grabación de pantalla.
  • La migración de .strings/.stringsdict a catálogos de cadenas supone un cambio de formato, no solo una actualización de versión. Debido a que Xcode 15 cambió la configuración predeterminada de Apple, los equipos que están migrando a menudo mantienen ambos formatos en el mismo código base a la vez, y una herramienta que solo analiza uno de los tres obliga a realizar un paso de conversión manual.

¿Cuáles son las capas principales de una pila de herramientas de localización para iOS?

  • Capa de formato de archivo - analiza el formato de Apple que emplea actualmente un proyecto: .strings (Identificador iosde tipo de archivo Smartling), .stringsdict (identificador stringsdict), y Catálogos de Cadenas (identificador xcstrings), por lo que una migración de formato no requiere convertir manualmente las traducciones existentes.
  • Capa de marcador de posición: bloquea los tokens de marcador al estilo iOS de Apple (como%@ y%d) como texto no editable durante la traducción usando la misma placeholder_format = IOS directiva entre tipos de archivo, de modo que un traductor no pueda reescribir o reordenar accidentalmente un token del que depende la app en tiempo de ejecución.
  • Capa de contexto visual : dado que una aplicación nativa no tiene HTML para escanear, la función de Contexto Visual de Smartling emplea OCR para hacer coincidir una captura de pantalla subida o grabación de pantalla con la cadena específica en la que está trabajando el traductor.
  • Repositorio y capa CI - El GitHub Connector de Smartling vigila una rama especificada, detecta archivos de recursos modificados en una pull request y abre una solicitud de localización una vez completada la traducción, así que un Catálogo de Cadenas o .strings El cambio pasa por el mismo proceso de revisión que cualquier otro cambio de código.
  • Capa de manejo de plurales : tanto los archivos Stringsdict como String Catalog contienen cadenas sensibles al plural mediante las categorías de plural basadas en CLDR de Apple, y un analizador que comprende la estructura de plural de ambos formatos evita el error silencioso de conversión a inglés que aparece cuando se omite una categoría de plural.

Formatos de archivo de localización para iOS: especificaciones técnicas

Smartling agregó soporte para archivos String Catalog (.xcstrings) en enero de 2025 y amplió ese soporte al formato más reciente XCStrings 1.1, incluyendo sustituciones variables, en febrero de 2026, según las propias notas de lanzamiento de Smartling.

FormatoExtensiónIdentificador SmartlingNotas
Cadenas de iOS.cuerdasiosArchivo de recurso clave-valor heredado; sigue siendo el formato base para proyectos creados antes de Xcode 15.
Diccionario de cadenas de iOS.stringsdictstringsdictObligatorio junto con .strings o XLIFF para cadenas sensibles al plural; la exportación XLIFF propia de Xcode no incluye plurales.
Catálogo de cadenas.xcstringsxcstringsFormato predeterminado de Apple desde Xcode 15; un archivo por catálogo contiene las cadenas de texto y los plurales de cada configuración regional.

¿Cuáles son los pasos para localizar las cadenas de texto de una aplicación Swift o iOS?

  1. Externaliza cada cadena : envuelve el texto visible para el usuario en NSLocalizedString o deja que Xcode 15+ extraiga automáticamente las cadenas en un catálogo de cadenas, de modo que nada se envíe codificado de forma fija y cada cadena tenga una clave estable.
  2. Confirma qué formato de Apple emplea el proyecto : un código fuente creado antes de Xcode 15 probablemente emplee el formato .strings. más un diccionario de cadenas complementario. para plurales; un proyecto creado en o migrado a Xcode 15+ emplea un único archivo .xcstrings Catálogo de cadenas por destino en su lugar.
  3. Conecta el repositorio : enlaza el proyecto a través de un conector como el GitHub Connector de Smartling, que detecta .strings nuevos o modificados, .stringsdict, o .xcstrings Archivo en una pull request y los reenvía automáticamente para su traducción.
  4. Traduce con contexto visual : sube una captura de pantalla o grabación de pantalla para que Visual Context basado en OCR pueda coincidir cada cadena con la pantalla en la que aparece, ya que no hay HTML para escanear en un navegador.
  5. Considera la exportación/importación manual de Xcode como opcional , ya que un analizador de formato nativo lee archivos .strings. y .stringsdict Directamente, un equipo no tiene que ejecutar primero el paso Exportar localizaciones / Importar localizaciones de Xcode; ese flujo de trabajo basado en XLIFF está disponible, pero aún necesita un .stringsdict separado. subir para cadenas plurales.

Este enfoque se adapta a los equipos de Swift e iOS que...

  • Publica una aplicación nativa para iOS o macOS escrita en Swift u Objective-C en más de un lenguaje de destino.
  • Comenzamos la migración desde Localizable.strings/.stringsdict a los catálogos de cadenas de Xcode 15, o mantener ambos formatos durante la transición.
  • Almacenar archivos de recursos en un repositorio de GitHub y querer que las nuevas cadenas se traduzcan como parte del flujo normal de pull request.
  • Envía texto de interfaz sensible al plural ("1 mensaje" vs. "12 mensajes") en idiomas con más categorías plurales que el inglés, como el árabe o el ruso.

Cuando una herramienta dedicada de localización para iOS puede no ser la prioridad adecuada

  • Una aplicación para iOS en fase previa a su lanzamiento que aún está validando su adecuación al mercado en su mercado de origen, donde las herramientas de localización completas representan un costo irrecuperable hasta que el producto principal sea estable.
  • Una aplicación con solo un puñado de cadenas codificadas en fija, que rara vez cambian, donde editaba manualmente una sola .strings Puede que aún sea manejable.
  • Una traducción única a un único idioma adicional sin una cadencia de actualización planeada, donde una pasada ligera y puntual puede costar menos que configurar un conector de repositorio.

Lista de verificación de evaluación: preguntas que debes hacer antes de elegir una herramienta de localización para iOS

¿La herramienta analiza directamente los Catálogos de Cadenas (.xcstrings), o solo las antiguas .strings y .stringsdict ¿formatos?
Una herramienta que solo soporta los formatos antiguos obliga a un paso de conversión manual una vez que un proyecto migra al formato predeterminado de Xcode 15.

¿Cómo se protegen los marcadores de posición al estilo iOS como%@ y%d durante la traducción?
Busque un formato de marcador de posición diseñado específicamente para las convenciones de iOS, no un patrón genérico configurado manualmente para cada proyecto.

¿La herramienta admite cadenas que distinguen entre plurales tanto en formato Stringsdict como en formato String Catalog?
Las categorías de plural basadas en CLDR de Apple se aplican a ambos formatos, por lo que un traductor que trabaje con cualquiera de ellos necesita ver todas las formas de plural que requiere el idioma de destino, no solo "uno" y "otro".

¿Realmente necesitas la función propia de Exportación/Importación de Localizaciones de Xcode?
Si la herramienta de traducción analiza .strings y .stringsdict De forma nativa, el paso de exportación/importación basado en XLIFF de Xcode se convierte en una opción en lugar de una parte obligatoria del flujo de trabajo.

¿Pueden los traductores ver la pantalla en la que aparece una cadena de texto?
Dado que una aplicación nativa no tiene HTML para una herramienta de exploración en el navegador, el contexto visual basado en capturas de pantalla o video es el sustituto práctico.

¿Cómo soporta Smartling la localización de cadenas de Swift e iOS?

Smartling analiza nativamente los tres formatos de archivos de recurso de Apple: .strings archivos (identificador iosde tipo de archivo Smartling), .stringsdict archivos para cadenas sensibles al plural (identificador stringsdict), y Catálogos de Cadenas (identificador xcstrings), que Smartling agregó soporte en enero de 2025 y extendió al formato más reciente XCStrings 1.1, incluyendo sustituciones variables, en febrero de 2026, según las notas de lanzamiento de Smartling. Cada formato emplea la misma directiva de marcador de posición estilo IOS para bloquear tokens como%@ y%d durante la traducción, por lo que cambiar de formato a mitad de proyecto no significa adoptar una nueva convención de marcador de posición. Como las aplicaciones nativas de iOS no tienen HTML para que una herramienta basada en navegador pueda escanear, la función Visual Context de Smartling emplea OCR para hacer coincidir una captura de pantalla subida o grabación de pantalla con la cadena exacta en la que trabaja un traductor. Para los equipos que ejecutan versiones de iOS a través de GitHub, el GitHub Connector de Smartling rastrea una rama específica, detecta .strings nuevos o modificados, .stringsdict, o .xcstrings en una pull request, y devuelve una pull request de localización con archivos traducidos una vez completada la traducción.

Preguntas relacionadas

¿Listo para ver a Smartling en acción?

Converse con alguien del equipo de Smartling para identificar cómo podemos ayudarle a aprovechar mejor su presupuesto al entregarle traducciones con la más alta calidad, mayor rapidez y a costos mucho más bajos.

Solicitar una reunión