Cinco reglas de oro para lograr la localización Agile

Ilustraciones de Julia Feng (OhISeeItNow.com)

Agile_Loc_LogoDurante la última década, muchos equipos de desarrollo de software han cambiado su metodología de desarrollo de un modelo de cascada a algo mucho más ágiles como Scrum. A través de esta transición, sus expectativas hacia otros equipos, tales como localización han cambiado y estos equipos han tenido que mejorar su agilidad también.

En Adobe, tenemos un grupo de localización centralizada que soporta actualmente 135 producto y equipos funcionales. La mayoría de estos equipos han adoptado algún tipo de metodologías ágiles de desarrollo y han reducido su ciclo de desarrollo de 18-24 meses y al año, trimestral, mensual y, estos días, comunicados quincenales. Un par de los equipos de producto de Adobe y otras empresas están incluso lanzando versiones actualizadas de sus productos varias veces al día, por lo que es imprescindible para la localización de seguir mejorando su agilidad.

Elaboración propia a partir de nuestra experiencia, Este artículo presenta Cinco reglas de oro que deberán cumplirse para lograr la localización ágil óptima.

Regla 1 - "Somos un equipo!"

Dentro de muchas empresas, Adobe incluye, La localización es una función centralizada al servicio de todos los productos y funcional (e.g. Mercadeo, Venta, Legal, etc) equipos. Esta estructura tiene sentido porque la localización es un campo especializado, por lo tanto, los recursos (personas, instrumentos) y los procesos se pueden aprovechar en toda la empresa. Sin embargo, localización aún debe ser preocupación de todos. El equipo de localización puede llegar a muchas soluciones, pero los mejores se originan cuando hay una verdadera colaboración entre los equipos de producto / funcional y localización.

We're one team!

Somos un equipo!

Los equipos más ágiles Tratar al personal de localización, como si fuera parte de su propio equipo.

Un aspecto central de Scrum es incluir a todos los conjuntos de habilidades, incluyendo la localización, necesarios para ofrecer un producto a los usuarios. Por lo tanto, Los miembros del equipo de localización deben ser incluidos en todos los aspectos de desarrollo – de la revisión retrospectiva de atraso – para que pudieran planificar y abordar los problemas internacionales desde el principio. Asociaciones fuertes también es necesario establecer con los proveedores de localización cuando las empresas, , como Adobe, colaborar con socios y proveedores para su traducción y actividades de prueba.

Compromiso con el cliente es un aspecto clave de las metodologías ágiles ya que valida la calidad y utilidad de los trabajos realizados hasta el momento. Se recomienda acudir con los clientes internacionales también, debido a que sus problemas aumentan conciencia en torno a la internacionalización.

En resumen, todas las partes interesadas (equipos de desarrollo, equipos funcionales que incluyen la localización, proveedores y clientes) que colaborar estrechamente con el fin de lograr una gran agilidad.

Regla 2 - "La internacionalización es el rey"

En nuestra La globalización de la serie Myth, definimos Internacionalización (comúnmente abreviado como i18n) como un ejercicio de ingeniería enfocada en la generalización de un producto para que pueda manejar múltiples idiomas, las secuencias de comandos y las convenciones culturales (moneda, Las reglas de ordenación, número, Fecha y hora formatos ...) sin necesidad de rediseño.

Internationalization is King

En otras palabras, la mejor internacionalizado una aplicación es, más fácil será para localizar.

En el modelo de cascada, equipos podían solucionar algunas de las deficiencias de internacionalización debido a los ciclos de desarrollo más largos. Desafortunadamente, en el mundo ágil, no hay tiempo suficiente para buscar soluciones solución alternativa más. El código debe ser internacionalizado desde el primer momento.

Existen varios enfoques para mejorar la internacionalización en una empresa, que incluye las siguientes:

  • I18n_EducationEducación: Desarrolladores principales de entrenamiento es una manera eficaz de reducir el número de problemas de internacionalización de un producto. Al exponer a los ingenieros a los problemas de localización e internacionalización, que adquieren una perspectiva más amplia sobre el impacto de su código y evitar algunos de los escollos de internacionalización clásicos.

 

  • I18n_LibrariesBibliotecas de internacionalización: Aprovechando las bibliotecas de internacionalización de código abierto, tales como la UCI o JavaScript i18n, es otra buena práctica. En lugar de volver a inventar la rueda, ingenieros pueden reutilizar el código que ya ha sido validado por los demás. También, bibliotecas i18n generalmente apoyan 100+ locales, que requieren una cantidad significativa de tiempo de investigación y desarrollo. Va a ser difícil para un solo equipo o incluso la empresa para apoyar a tantos lugares.
  • Peer_ReviewLa revisión de código: La práctica de revisiones por pares es un método eficaz para reducir los defectos de internacionalización en un producto. Dado que los desarrolladores saben que su código será revisado, prestan más atención a su calidad (efecto de la presión de grupo) por lo que también beneficia a la internacionalización. Algunas empresas incluso automatizar este proceso de revisión utilizando herramientas como Globalyzer.
  • Globalization Report Card: Productos Benchmarking contra una arquitectura ideal ayuda a mejorar la internacionalización también. Como parte de nuestro programa de World-Readiness, hemos creado un sistema de Boleta globalización para evaluar el grado de preparación para el mundo en cada producto de Adobe. Este cuadro de mando mide productos con un conjunto de criterios de internacionalización (capacidad de caracteres internacionales de entrada, mostrar los formatos de fecha, traducir la interfaz de usuario, y así sucesivamente ...). Es una forma eficaz de seguimiento de los progresos realizados por cada equipo con el tiempo e incluso puede crear una competencia sana entre los equipos de producto. Estos equipos están motivados para estar en la cima de las listas de i18n!

Globalization Report Card

Regla 3 - "Integrar la localización en el Proceso de Desarrollo"

Para lanzar un nuevo producto, equipos de desarrollo tienen muchas tareas de alta prioridad y por lo general prefieren no tener que preocuparse por la localización hasta que sea necesario. Como consecuencia de ello, cuestiones aptitud de localización se descubren a menudo demasiado tarde y se encuentran con el riesgo de ser aplazado hasta una próxima versión. Equipos de productos no siempre anticipan el impacto de una tarea / función especial en la localización, y muy a menudo, el equipo de localización puede no ser capaz de influir en el diseño o desarrollo hasta que la característica ya está implementada.

En un proceso ágil, funciones y tareas de desarrollo se realiza un seguimiento de una cartera de pedidos y crítica al principio de cada carrera. Para eliminar los efectos secundarios de la "throw-over-the wall-" modelo descrito anteriormente, es fundamental incluir a representantes de localización durante estas reuniones de planificación de Sprint para una mayor visibilidad e importancia se les da a las tareas de localización. Esto también proporciona un gran valor educativo para todos los interesados ​​que a continuación se puede entender el impacto de sus decisiones en el proceso de localización. Localización o un proxy también deben asistir a las reuniones diarias de sprint para mantenerse al día con el ritmo y las decisiones de desarrollo. Al asistir a estas reuniones, Los miembros del equipo de localización pueden ser mucho más proactivos e influyentes.

Localization Process Integration

Adobe Revel y Photoshop.com son ejemplos de equipos que integran la localización en su proceso de desarrollo. También priorizan localización funciones intensivas / tareas iniciales - talla suficiente tiempo para que el equipo de localización para ejecutar sus procesos y ofrecer versiones localizadas de alta calidad.

En un reciente Localization World evento, Amrit Singh (Director del Programa Internacional para nuestras tecnologías de instalación) presentado LocBan (Kanban aplicada para la localización). Al igual que en una fábrica de Toyota, el equipo de localización mantiene una junta "para hacer", "Trabajo en curso" y "Done" tareas que proporciona una gran visibilidad de la localización "cinta transportadora". Del mismo modo, sería beneficioso para mantener juntas Kanban para cada traductor. En el modelo de cascada, traductores solían recibir kits de localización grandes, que tuvieron que luchar para terminar en el plazo. En el mundo ágil, traductores son ahora capaces de "sacar" el trabajo como su ancho de banda se abre.

Localization Kanban

Mediante el uso de un tablero Kanban integrado, todo el mundo tiene una idea clara de las diversas dependencias y responsabilidades, lo que resulta en una colaboración más fuerte y una mayor tasa de éxito.

Regla 4 - "Reducir, Reutilizar y Reciclar "

La localización puede generar una gran cantidad de residuos si no se planifica adecuadamente. Así, que es la clave para convertirse en "verde" con el fin de ser más "ágil".

Reduce, Reuse, Recycle

Reducir

Es evidente que la reducción del esfuerzo de localización tendrá un impacto positivo en la agilidad de un equipo. Esto se podría lograr en 2 formas: mediante la validación del alcance de localización y mediante la reducción de los residuos traducción generado durante el proceso de localización.

  • La reducción de localización Alcance

El trabajo de localización del gerente es asegurar que la compañía se localiza el producto y el contenido adecuado en el conjunto de idiomas. En Adobe, hemos tenido situaciones en las que estábamos localizando demasiado contenido. Por ejemplo, uso Digital Marketing Suite de Adobe, descubrimos que los clientes rusos prefieren la lectura de documentación de desarrollo (tales como descripciones de las API) en Inglés en lugar de en ruso. Hemos sido capaces de ahorrar mucho tiempo y dinero mediante la eliminación de este componente de nuestros requisitos de localización.

Del mismo modo, a través de estudios de mercado, descubrimos que la mayoría de los clientes de Oriente Medio Creative Suite prefieren utilizar una interfaz de usuario Inglés con el árabe o el hebreo documentación. Esta combinación hace que el contenido Inglés como vídeos y tutoriales más accesibles para ellos.

En breve, seguimiento de analítica web y la participación con los clientes, los usuarios de energía, probadores de la versión preliminar y GEOS constituyen una buena forma de validar los requisitos de localización y mejorar la agilidad.

  • La reducción de residuos Localización

Una vez que se confirman los requisitos de localización, es clave para limitar los residuos traducción generado durante el proceso de localización. Obviamente, esto afecta el trabajo de los traductores, sino también el ancho de banda de la plantilla de localización.

Sweep Away Waste!Una forma efectiva de reducir el desperdicio de localización es en la comprensión de su causa. En Adobe, clasificamos todos los defectos de localización a través de un conjunto de palabras clave, que nos da una buena idea de los problemas que enfrentan todos los productos. Podemos desarrollar soluciones para reducir, si no eliminar, estos defectos.

Residuos localización a veces se origina en Inglés cadenas de asumir Inglés es el idioma de origen. En realidad, traducciones creadas antes de cadenas en inglés quedar finalizadas deberán ser revisadas y probablemente genera algunos residuos.

En el mundo ágil, no nos podemos permitir ese tiempo extra, por lo que es importante validar el contenido Inglés antes de entregarla fuera de los traductores. Hacer algo tan simple como la corrección ortográfica puede ayudar a reducir la cantidad de residuos de localización. En un producto como InDesign, sobre 3% de las cadenas de la interfaz de usuario en inglés se actualizan una vez que se revisaron los errores de ortografía y gramaticales. Para un producto que se localiza en 25 idiomas, esto representa una pérdida equivalente a 75% de un solo ámbito idioma!

También, muchas de las actividades de pruebas de localización de software son necesarios debido a la localización que está sucediendo fuera de contexto. Resolver ese problema tremendamente puede acelerar el proceso de localización. En un mundo ideal, localización debería ser una característica del producto que permite a los traductores para traducir la interfaz de usuario en contexto. Facebook hizo un gran trabajo en esta área, permitiendo traductores (en este caso, su comunidad de usuarios) traducir y dar retroalimentación dentro de la propia aplicación. Alternativamente, traductores deben proporcionar información de contexto a través construye, imágenes y la información de metadatos (e.g. comentarios de los desarrolladores, nombre de la función, plazo de expedición previsto, etc).

Para reducir los residuos, también se recomienda que los localizadores desarrollar glosarios, guías de estilo y herramientas que aprovechan localizaciones anteriores.

Al final, es fundamental para los traductores para validar su trabajo, ya que se traducen. De esta manera, actividades en la línea de producción pueden ser eliminadas o reducidas, lo que hace que todo el proceso sea más ágil.

Reutilización

Reuse when it makes sense!Reutilización de cadenas a veces puede ser una fuente de defectos difíciles de localización de software, por lo que tiene que ser manejado cuidadosamente. Por ejemplo, la cadena de Inglés "none" se puede traducir como "aucun" o "aucune" en francés basado en el género del sustantivo al que se refiere.

Dicho esto, reutilización de cadenas - en el mismo contexto – También podría ayudar a mejorar la agilidad, ya que no tendrán que ser traducido varias veces estas cadenas.

Un área en la que Adobe ha tenido resultados positivos con la reducción y la reutilización de contenidos Inglés está en nuestro contenido educativo. En la documentación, Adobe se basa en Acrolinx para controlar la calidad del Inglés (fuente) contenido. Los autores deben usar un cierto estilo de edición (e.g. oraciones más cortas) y se les anima a aprovechar los actuales párrafos (e.g. avisos legales). Esto mejora la consistencia en la documentación de Inglés y tiene la gran ventaja de reducir la carga de trabajo de localización también.

Del mismo modo, DITA (leer Reducir, Reutilizar y Reciclar: El desarrollo de una estrategia de reutilización de DITA) y sistemas de gestión de contenidos como Adobe Experience Manager (anteriormente conocido como el Día de CQ) están diseñados para reutilizar / compartir contenido a través de múltiples canales y publicaciones.

Reciclar

El reciclaje es el proceso de transformación de materiales existentes (o residuos) de tal manera que podrían ser reutilizados de nuevo - a veces para un propósito totalmente diferente. Creación de vellón polar a partir de botellas de plástico usadas o aislar paredes con viejos jeans son ejemplos clásicos de reciclaje.

Estas transformaciones se pueden aplicar a las traducciones demasiado. Los traductores no tienen que traducir cada frase desde el principio. Tecnologías de traducción, tales como memorias de traducción y los motores de traducción automática pueden ayudar a los traductores reciclar traducciones anteriores y acelerar el proceso de traducción. En Adobe, hemos experimentado dramáticos aumentos de productividad cuando utilizamos estas tecnologías. En general, un traductor con el apoyo de estas tecnologías entregará en una hora lo que otros traductores entregarían en un día. Estos son los impresionantes logros que contribuyen a la agilidad de localización también.

Regla 5 – Automatizar, Automatizar, Automatizar

El último requisito para lograr la localización ágil es la automatización. Con agilidad, usted no puede permitirse el lujo de enviar solicitudes de traducción a través de e-mails o cortar y pegar cadenas de una hoja de cálculo en un archivo de origen. Toda traducción traspasos debe ser automatizado y gestionado a través de un sistema centralizado. A través de los años, Equipo de la globalización de Adobe ha desarrollado una plataforma. Este sistema es capaz de conectar con varios sistemas de control de código fuente, administrar los trabajos de traducción, aprovechar las traducciones ya existentes a través de proyectos y tipos de contenido y proporcionar los motores de traducción automática. En el La globalización Mito 4 artículo, Guta Ribeiro presentó Aeropuerto, nuestro nuevo sistema se conecte automáticamente con nuestros proveedores y nos ayudan a marchar hacia nuestra meta traducción noble de una hora.

Automate

Más allá de la traducción, también es importante para automatizar otros aspectos del proceso de localización, tales como construir, aseguramiento de la calidad, corrección de errores, capturas de pantalla y distribución de las versiones localizadas. Sólo podemos ir tan rápido como el componente más lento, por lo que es fundamental para automatizar todos los aspectos del proceso de localización.

Conclusión

Agilidad localización se puede lograr siempre y cuando todos los interesados ​​trabajen como un equipo unificado. Es muy importante para los ingenieros principales para desarrollar código bien internacionalizado desde el primer momento. Esto se puede lograr a través de la formación, las revisiones de código, uso de (Open Source) bibliotecas de internacionalización y boletas de calificaciones globalización.

El proceso de localización debe estar plenamente integrada dentro del proceso general de desarrollo de manera que todas las dependencias y responsabilidades son claras. Recomendamos el uso de tableros Kanban (a través de herramientas como Trello) para aumentar esta visibilidad. Para llegar a ser ágil, también es importante actuar "verde" (i.e. reducir, reutilizar y reciclar). Si lo hace, representa una forma efectiva para controlar la generación de residuos antes y durante el proceso de localización. Finalmente, deben hacerse todos los esfuerzos para automatizar todo el proceso de localización ágil.

En Adobe, no todos los proyectos de localización se manejan con gran agilidad - sin embargo,! Algunos proyectos son más ágiles que otros. Sin embargo, basada en nuestra experiencia, creemos que la agilidad se puede lograr mediante la adopción de estos Cinco reglas de oro:

  1. "Somos un equipo!"
  2. "La internacionalización es el rey"
  3. "Integrar la localización en el Proceso de Desarrollo"
  4. "Reducir, Reutilizar y Reciclar "
  5. "Automatizar, Automatizar, Automatizar "

 

Un agradecimiento especial a Rob Jaworski, Amrit Pal Singh, Ashish Saxena, Janice Campbell, Leandro Reis, Peter Green, Julia Feng Le y Quynn por su valiosa retroalimentación sobre este artículo.

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.