ios8 - ¿Un buen flujo de trabajo de localización usando Xcode 6, iOS 8, Storyboards y xliff?

localization xcode6 (1)

Hemos recurrido a conectar cada etiqueta a un @IBOutlet y configurar su traducción en viewDidLoad () con NSLocalizedString.

Lo estás haciendo bien. Seriamente. Envuelva su proceso de desarrollo a su alrededor y obtendrá mucho mejor que tratar de adoptar el desorden en el que evolucionó la localización del Guión Gráfico.

Resuelve pt.4: tú decides lo que pones en Localizable.strings

Resuelve pt.5: los comentarios están allí por defecto, para todo lo que decida que sea localizable. Ahora, para ser honesto, XCode7 ha agregado la posibilidad de agregar notas a los recursos . No lo uses Por alguna razón conocida solo por Apple, no está disponible para todos los tipos de recursos. No se pueden anotar, por ejemplo, encabezados de tablas y pies de página. Más sobre eso más tarde.

Recomiendo hacer su propio contenedor (macro) NSBundle.localizedStringForKey que proporciona el value . NSLocalizedString establece el value en una cadena vacía, esencialmente forzando que la key se use como contenido de traducción alternativo. De todas las macros cuestionables ya existentes, NSLocalizedStringWithDefaultValue toma el value pero también los otros 4 parámetros necesarios, algo que no le gustaría usar a menudo.

El paso 10 se debe a que intentas importar una localización base; el hecho de que sea inglés no hace ninguna diferencia. Si desea "traducir inglés" (es decir, corrección profesional), debe agregar el inglés como otra localización independiente en la parte superior de la base. Técnicamente, se reduce a la base xliff faltan <file target-language> y <target xml:lang> . Debido a un extraño lío xliff similar al tuyo, tuve que agregarlos una vez manualmente. No quieres hacer eso :)

Problema de apostrophe: la localización de iOS es un jardín irreal de maravillas, pero estoy seguro de que no es tan irreal :) Intente abrir el archivo en algún editor de visualización de hexcodes: lo que XCode representa puede ser bastante diferente de lo que realmente contiene el archivo.

... incluso algo basado en la web

Eso es Crowdin para nosotros y muestra muy bien todo lo que está mal con la idea de Apple de la localización de Storyboard. Los traductores necesitan 3 cosas para hacer su trabajo profesionalmente: contexto, contexto y contexto. Apple parece pensar que los traductores instalarán gustosamente la aplicación, jugarán con ella y harán preguntas para obtener el contexto. Porque, de forma predeterminada, no hay contexto humano en la exportación xliff . Ahora, con Xcode7, puedes agregar notas, pero extrañamente no en todas partes. Incluso donde pueda, su nota se agrega al final de una cadena ya larga <note> con el contexto de la máquina, comprensiblemente necesaria para la coincidencia de importación de guiones gráficos, pero inútil y obstructiva para el traductor. Además, en realidad, el traductor es una agencia profesional o un entusiasta de la lengua. Incluso si tuvo suerte con un entusiasta adecuadamente equipado, o si pagó la prima de la agencia por obtener un servicio de atención al cliente adicional, ingresa a las Opciones de distribución hostil del desierto de Beta . La divertida reencarnación de Testflight de Apple necesitará que el traductor se registre como desarrollador de Apple o que espere la revisión de la versión beta de Apple, dependiendo de qué tan temprano en la vida de la aplicación necesita la traducción.

Por cierto me gusta tu blog. A veces tengo ganas de deshacerme de mi amargura y también de fatiga, pero nunca llegué tan lejos como tú :)

Esto es idealmente lo que me gustaría hacer:

Configura un proyecto en Xcode usando una localización base de inglés. En última instancia, quiero inglés y digamos versiones holandesas de mis Localizable.strings y Storyboards
Externalizar cadenas en código con NSLocalizedString , usando claves de la forma fooViewController.barLabel , siendo diligente y agregando comentarios de contexto apropiados con cada clave
Agregue una localización holandesa a mis archivos Storyboard
Marque etiquetas específicas en el Guión gráfico como marcadores de posición que se establecerán en tiempo de ejecución y no requieren traducciones
Agregue comentarios para las etiquetas en el guión gráfico que requieren traducción
Exportar el archivo xliff "lenguaje de desarrollo" (haga clic en Proyecto, Editor / Exportar para localización ..., elija "Solo idioma de desarrollo")
Abra el archivo xliff en inglés en una herramienta como Counterparts o Xliffie o incluso algo basado en web
Añada traducciones reales en inglés junto con las teclas fooViewController.barLabel , y vuelva a guardar el en.xliff
Cree un archivo nl.xliff del en.xliff original y agregue traducciones holandesas
Importe los dos archivos xliff a Xcode y xliff que creen los archivos .strings apropiados tanto en holandés como en inglés, tanto para las claves definidas en el código como para las del Storyboard; cometer los nuevos archivos .strings en mi repositorio de origen
En algún momento futuro, una vez que se hayan agregado, eliminado y cambiado las claves en mi fuente y Storyboards, exporte el "Idioma de desarrollo" en.xliff nuevamente como la fuente de la verdad.
Actualice los archivos en.xliff y nl.xliff con las traducciones actuales, con una herramienta que resalta las teclas que se agregaron o eliminaron
Importe esos archivos xliff nuevamente a Xcode que actualiza los archivos .strings que luego puedo revisar en mi repositorio de origen

¿Esto tiene sentido? ¿Es esto algo razonable que quieras hacer? Creo que sí, pero no funciona.

Aquí están los problemas que encontré:

Xcode no admite el paso 4: el formato xliff puede marcar una clave como translate=no , pero no hay forma de anotar eso en Xcode (idealmente, Xcode no exportaría las teclas marcadas como marcadores de posición).
Xcode no admite el paso 5: no hay forma de establecer un comentario del traductor para una etiqueta. Ni siquiera hay una forma de establecer la clave independiente del texto de marcador de posición que coloque en la etiqueta del Guión gráfico, lo cual es un gran dolor si encuentra que llenar las etiquetas con Lorem Ipsum es útil cuando establece sus puntos de vista.
Cuando llega al paso 10, Xcode se queja de que no hay un idioma de destino especificado en el archivo en.xliff . Hay una forma de cambiar el idioma de destino (o, al menos, crear un nuevo archivo con el idioma de destino establecido en EN ) en Counterparts, pero no pude encontrar ninguna forma de hacerlo con Xliffie.
Al intentar reexportar el archivo en.xliff con las claves actualizadas, Xcode me dijo "Localization failed reading "[...]/Supporting Files/en.lproj/Localizable.strings, Please address the issue at file location 782" en qué ubicación del carácter encontré ... un apóstrofo. Xcode no puede exportar un archivo xliff si el archivo .strings origen contiene un apóstrofo. ¿Qué hay en la F ... ?
Los pasos 12 y 13 se pusieron raros y no entiendo lo que estaba pasando. Tanto Counterparts como Xliffie habían reemplazado mis claves originales fooViewController.barLabel con las traducciones al inglés y parecía que intentaban decirme que no tenía traducciones al inglés. Al tratar de importar el en.xliff nuevo a Xcode, me dijo que no tenía traducciones para todas las claves, excepto las nuevas, y cuando lo hice en.lproj/Localization.strings las traducciones existentes del archivo en.lproj/Localization.strings .

Esto es un desastre.

La traducción de etiquetas en Storyboards sin poder configurar manualmente sus claves, agregar comentarios del traductor o marcar etiquetas particulares como marcadores de posición no para traducción simplemente no funciona. Hemos recurrido a conectar cada etiqueta a un @IBOutlet y configurar su traducción en viewDidLoad() con NSLocalizedString .

Xcode se ahoga cuando intenta exportar un archivo .strings que contiene una creencia de mendigos apóstrofes.

También parece que hay una suposición subyacente de que si el "lenguaje de desarrollo" en Xcode es el inglés, entonces los desarrolladores están a cargo de la traducción al inglés. No puedo imaginar ningún contexto fuera del de una tienda de desarrolladores indie para una sola persona donde esto sea cierto.

Finalmente, también parece que me falta algo sobre cómo las herramientas que he intentado usar estructuran sus flujos de trabajo. Si alguien me pudiera iluminar estaría muy agradecido.

¿Alguien ha logrado construir un flujo de trabajo de localización viable donde los desarrolladores no tienen el último control de edición sobre el "lenguaje de desarrollo" y los archivos .strings registrados en el repositorio son la fuente de la verdad?