El problema con la Localización de software para múltiples plataformas

Adobe tiene una larga historia de desarrollo de productos para múltiples plataformas, ya se trate de aplicaciones de escritorio como nuestras aplicaciones de Creative Suite insignia o aplicaciones táctiles más recientes, como Photoshop Touch. La mayoría de nuestras aplicaciones de escritorio se han construido para Windows y Mac y las aplicaciones más recientes continuar en esta tendencia con soporte para iOS y Android incluyendo Tablet y teléfono factores de forma para ambos.

Por supuesto, esto no habría sido posible sin los cuidadosos esfuerzos del equipo de ingeniería para mantener en gran medida una base de código único para todas las plataformas.

Mientras que tener una sola base de código tiene beneficios obvios, en la capa de interfaz de usuario a menudo es importante tener variaciones específicas de la plataforma para una mejor usabilidad. Cada plataforma tiene generalmente un convenio específico para referirse a los menús del sistema, atajos de teclado y elementos de interfaz de usuario. Por ejemplo en una plataforma Windows una cadena UI podría ser – “Seleccione un archivo multimedia mediante el botón Examinar o escriba una ruta de acceso válida.” y de la misma cadena para la plataforma Mac podría ser – “Seleccione un archivo multimedia a través del botón Seleccionar o escriba una ruta de acceso válida.”

Esto significa que las cadenas traducibles de interfaz de usuario pueden tener muchas variaciones en la lengua fuente, dependiendo de qué plataforma están destinados a. Esto es lo que nuestro grupo por lo general se refiere a la globalización como 'Plataforma Varianza’. Cadenas localizables son esencialmente entidades de varios valores. Cada cadena localizable tiene un identificador de valores asociados y múltiples, cada uno de los cuales se pueden seleccionar sobre la base de ciertos criterios. Los criterios más evidentes y de uso común es la configuración regional de la interfaz de usuario de la aplicación, pero no tienen por qué ser el único. Plataforma también puede decidir el valor de una cadena.

Apoyo varianza plataforma no es sólo útil para el tratamiento de las diferencias de terminología para referirse a los elementos de la interfaz de usuario del sistema, también ayuda a adaptarse cuerdas para diferentes tamaños de pantalla. Aplicación de modernos están diseñados para soportar dispositivos múltiples factores de forma como tableta y teléfono con la interfaz de usuario está ajustado para cada plataforma para la mejor experiencia de usuario. Varianza Plataforma en este caso puede ser utilizado para apoyar cadenas más largas para la vista de la tableta y las cadenas más cortas para la vista Phone.

Otra área donde el apoyo varianza plataforma podría ser útil es en tener diferentes valores localizables para una versión Pro frente a una versión de consumo de la aplicación.

Sin embargo, Traducir cadenas con datos variante de la plataforma es un problema. El problema es dos veces, uno está en la gestión de los procesos y el calendario del proyecto para permitir la localización ágil y despacho simultáneo a todas las plataformas de destino. El segundo aspecto está apoyando técnicamente la varianza plataforma en ambas bibliotecas de programación y herramientas de traducción. Muchas de las herramientas y las bibliotecas suponen un valor único para una fuente y una cadena de destino, pero en caso de variación de la plataforma no sólo no puede ser fuente de múltiples y valores objetivo para una cadena no es necesario establecer una relación uno a uno entre los valores de origen y destino. Puede haber múltiples variantes de la plataforma para una cadena de origen que puede ser necesario traducir de manera diferente sobre la base de la plataforma de mapa en el mismo valor / target traducida o una cadena de origen para la configuración regional de destino. Por ejemplo:

  • es_ES: “Por favor, cierre el cuadro de diálogo y volver a empezar.”
  • fr_FR default: “Cierre el diálogo y vuelva a intentarlo.”
  • Ventanas fr_FR: “Cierre el diálogo y vuelva a intentarlo.”

Puesto que soy parte del equipo de herramientas de la globalización aquí en Adobe, el resto de este post que describe el problema más de unos instrumentos técnicos y la perspectiva de las bibliotecas, dibujo de mi experiencia. El problema proceso también es bastante complejo y probablemente tomaría un puesto mucho más tiempo el blog para discutir. De hecho hay una idea afín ya en este blog, ver – enlace.

Plataforma de Apoyo varianza en las Bibliotecas

Lo ideal sería que las bibliotecas de la globalización / API utilizadas en el código para manejar cadenas externalizados y los formatos de almacenamiento correspondientes a los datos externalizados deben tener una noción de un valor variante de la plataforma para cada cadena. Debe haber una manera de solicitar un valor de cadena para una configuración regional y plataforma específica, junto con una disposición a caer de nuevo a un valor por defecto en caso de que no se especifica un valor específico de la plataforma.

Como un ejemplo, la API de Java ResourceBundle apoya la selección de un conjunto de 'Configuración regional', no se hace mención explícita de una "Plataforma", pero la "Configuración regional’ en sí es extensible para apoyar variantes. El mecanismo de la variante en la 'Configuración regional’ se puede utilizar para el apoyo a diferentes plataformas y también hay un mecanismo de repliegue. En Adobe tenemos una biblioteca multiplataforma desarrollada personalizada denominada ZString para la gestión de cadenas externalizados con el apoyo explícito de varianza plataforma.

Plataforma de Apoyo varianza en las Herramientas de Traducción

La mayoría de los sistemas de gestión de traducción (TMS) tener un uno-a-un modelo de cadenas de código coincidentes con cadenas traducidas para cada localidad. Esta suposición está detrás de la arquitectura de los algoritmos de correspondencia TM, así como el diseño de la mesa de trabajo de traducción. Un banco de trabajo de traducción típica por lo general ofrece una vista de lado a lado de origen y de destino cuerdas, pero sólo apoyar una sola cadena de origen que corresponde a un único valor traducido.

Typical Translation Workbench

Un equipo típico de la vista lateral de la fuente y el contenido de destino en una herramienta de traducción

Todavía estamos buscando la solución ideal a este problema. Para la gestión de las memorias de una posible solución con los sistemas existentes es tener entradas duplicadas en la memoria de traducción (TM) o una TM separado para cada plataforma.

Sin embargo, traductores todavía se ven limitadas por la visión presentada por el banco de trabajo de traducción. Una posible solución para permitir que proveedores de traducción para proporcionar traducciones específicos de la plataforma es de duplicar todas las cadenas de origen para cada posible plataforma de destino. El valor de la fuente de la plataforma por defecto se puede utilizar como el valor de origen para todos los demás plataforma si la interfaz de usuario de la aplicación ya especifica un valor para una plataforma específica, en cuyo caso que se utiliza. Ahora el traductor puede proporcionar diferentes traducciones para cada plataforma, si es necesario. Esta solución sin embargo, parece haber una gran cantidad de trabajo adicional para los traductores. Algunos de optimización es posible gracias a la traducción de una sola plataforma de primera y el aprovechamiento de traducciones para todas las otras plataformas.

En un escenario ideal, el banco de trabajo de traducción proporcionaría un lado a la vista lateral de todas las variantes de la plataforma para la cadena de origen y de destino de las cuerdas. Con la capacidad para el traductor para eliminar las variantes de la cadena traducida en los que no se requieren y proponer variantes para la cadena traducida incluso si la cadena de origen no tiene ningún. Esto permitiría a los traductores a trabajar a través del contenido de código en una sola pasada, edición de traducciones apalancadas, proporcionando nuevas traducciones cuando resulte necesario y proponer valores traducidos específicos de la plataforma, según corresponda.

Una aproximación a esta visión ideal es una hoja de cálculo de Excel con cada cadena de origen que se representa en una fila y tiene una columna separada para cada plataforma, tanto para las cadenas de origen y destino. Con valores en blanco en una columna de la plataforma que significa que la traducción del defecto se utilizará para esa plataforma y las entradas de la plataforma no están en blanco que se utiliza para las traducciones específicas de la plataforma.

Ideal Translation Workbench

Una vista workbench traducción propuesta que permite la traducción simultánea para múltiples plataformas

Todavía estamos experimentando para encontrar la mejor solución para nuestras necesidades, que ofrece flexibilidad a los traductores y sin embargo, aprovecha la inversión en herramientas y procesos de traducción existentes. El objetivo es ser capaz de soportar ciclos de lanzamiento más rápido ágiles con todas las versiones de la plataforma sucediendo simultáneamente.

Creo que este es un buen foro para pedir a nuestros lectores del blog, si se han enfrentado a problemas similares y las soluciones que se han desarrollado para tratar con él.