¿Cómo podemos realizar un seguimiento de los cambios en las traducciones dentro de nuestro proyecto?

Trabajo en una empresa de desarrollo de juegos con alrededor de 100 empleados. Cada uno de ellos puede agregar texto para traducir. Hay mucho texto para traducir, por lo que hacer un seguimiento de todo el texto es problemático. Antes de enviar texto a los traductores, alguien necesita encontrar todo el texto que se agregó o cambió, y esto es una gran pérdida de tiempo.

¿De qué manera podemos simplificar este proceso? ¿Cómo podemos realizar un seguimiento de los cambios en los archivos que contienen texto?

Respuestas (4)

Comience con el control de fuente

Recomendar herramientas específicas está fuera de tema aquí, pero desde el punto de vista de la gestión de proyectos de software (e incluso desde el punto de vista de la ingeniería), es probable que la respuesta correcta sea usar un control de fuente efectivo.

Un sistema de administración de código fuente (SCM) como Subversion o Git está diseñado para hacer exactamente lo que está tratando de hacer: realizar un seguimiento de los cambios en los archivos de texto dentro de un proyecto. Los buenos SCM incluso facilitan la lista de cambios recientes, la comparación de archivos o la comparación de versiones del mismo archivo.

Implementar la internacionalización y la localización

Proceso

Una vez que haya implementado el control de código fuente, probablemente querrá desarrollar procesos y prácticas de ingeniería para la internacionalización y la localización. Su proceso de gestión de proyectos debe incluir los siguientes subprocesos:

  1. internacionalización
  2. Localización
  3. Seguro de calidad

Ingenieria

Sus prácticas de ingeniería deben incluir una forma coherente de gestionar los mensajes globalizados. Según Wikipedia :

La práctica [de ingeniería] predominante actualmente es que las aplicaciones coloquen texto en cadenas de recursos que se cargan durante la ejecución del programa según sea necesario.

Los métodos de ingeniería específicos están fuera del alcance de un sitio centrado en la gestión de proyectos. Sin embargo, esto debería brindarle una base sólida para explorar las necesidades de su proyecto y desarrollar sus propias prácticas de ingeniería.

Mantenga todos los fragmentos de texto juntos en un solo archivo (o más bien, un archivo por idioma). Cuando necesite usar ese texto, sáquelo del archivo.

De esta manera, al mantener todo el texto junto, es mucho más fácil visualizarlo todo. También se vuelve mucho más fácil ver los cambios en ese archivo, especialmente si está utilizando el control de código fuente: simplemente compare la versión más reciente de ese archivo con la versión de hace X días, y verá todos los cambios que alguien ha realizado en el texto de ese idioma. .

Esto también hace que sea mucho más fácil cambiar entre idiomas: simplemente cambia el archivo que se está utilizando.

Así es, más o menos, cómo lo manejamos en este momento. También tenemos archivos separados por propósito, cada idioma tiene pocos archivos (como con diálogos u opciones). Con alrededor de 5 idiomas y unos pocos miles de registros por idioma, realmente no es fácil de rastrear.
@Derag Ese es el problema. Debe tener UN archivo por idioma. No pocos archivos por idioma. Si todo está en un solo archivo, se vuelve mucho más fácil realizar un seguimiento de los cambios.

Veo esto como una solución basada en herramientas en lugar de una solución basada en la gestión. Ya está utilizando archivos de recursos y

También tenemos archivos separados por propósito, cada idioma tiene pocos archivos (como con diálogos u opciones). Con alrededor de 5 idiomas y unos pocos miles de registros por idioma, realmente no es fácil de rastrear.

Entonces, su problema (tal como lo veo) es determinar cuándo se cambian los textos de los recursos y qué trabajo se debe hacer para arreglar todos los recursos para los otros idiomas.

Mi primer pensamiento fue crear un programa para extraer todos los textos de recursos a un archivo plano con campos como

Source-File
Resource-Name
Resource-Language
Resource-Text

... y luego ordenarlo y diferenciar el archivo plano actual con una versión anterior. Ahora puede ver los recursos modificados y corregirlos manualmente.

Por supuesto, las nuevas entradas de sus traductores aparecerán en las diferencias y deberán ignorarse.

Pero su situación (100 empleados) me parece una oportunidad para crear una herramienta mucho mejor que mejoraría el desarrollo de software en sus próximos proyectos. Aquí hay un concepto de herramienta más complejo:

Cree un programa para extraer todos los textos de recursos a una tabla de base de datos con campos como

Source-File
Resource-Name
Resource-Language
Resource-Text
Last-Change-Date
From-Resource-File-Flag
Translator-Name

El programa se agregaría a esta tabla con recursos modificados, es decir, si el idioma y el texto son iguales, la fila no se actualizaría. Si el idioma/texto es diferente a la fila actual, agregue ese recurso como una nueva fila.

Por lo tanto, la tabla contendría todas las versiones del recurso por fecha. From-Resource-File-Flag indicaría que el origen de esta fila es de un cambio de desarrollador a un archivo de recursos.

Debido a que la tabla está en SQL, podrá ejecutar consultas. Podrá identificar los cambios realizados por los desarrolladores que deberían traducirse. También podría localizar recursos que no están traducidos; por ejemplo, hay una versión en inglés y francés, pero no una versión en español.

Pero la mejor parte es que ahora sería posible una herramienta separada (o sitio web) para que pueda repartir los cambios de traducción sin demasiada supervisión humana. Un traductor iniciaría sesión y vería una lista de textos que deben traducirse; la traducción se agregaría a la base de datos y luego se propagaría al archivo de recursos con otro programa.

Como dije, más una solución basada en herramientas. Una solución basada en la gestión podría fallar si las personas no son diligentes. Habría más pruebas para garantizar que todos los recursos se tradujeran (ya que si un recurso no se traduce, el texto del recurso se generaría en el idioma incorrecto).

La idea con SQL suena genial, pero es demasiado trabajo para nuestras necesidades. Mantener el historial de cambios es una idea interesante.

Si no es posible reducir la cantidad de personas que pueden cambiar el texto, entonces encontrar una herramienta para detectar cambios automáticamente y crear una cola de pedidos de traducción para usted podría ser el camino a seguir.

No tengo ninguna experiencia personal con los sistemas de gestión de traducción empresarial (p. ej., Transifex ), pero he usado sistemas fáciles de usar como WebTranslateIt y OneSky . Ambos tienen herramientas de desarrollo y API que se pueden integrar en su flujo de trabajo de tal manera que sincronizan el estado más reciente de sus archivos de recursos de texto en sus portales.

Los traductores pueden acceder a herramientas como esa y albergar todo el proceso de traducción. Si un cambio se sincroniza más recientemente que el último estado de una traducción en un idioma en particular, se marca mensaje por mensaje, idioma por idioma. Los traductores pueden filtrarlos fácilmente y los paneles ayudan a los gerentes a realizar un seguimiento del progreso.

Hay un campo bastante amplio de servicios como este últimamente. Depende de si gestiona usted mismo a los lingüistas, tiene una relación con un proveedor al que envía kits según sea necesario, colabora con las traducciones o cualquiera que sea su día a día actual.