Los principios de documentación y localización, o cómo obtener una buena localización a un costo mínimo.

Hola a todos!

Me llamo Denisov Alexander. Trabajo para Naumen y soy responsable de documentar y localizar el producto de software Naumen Contact Center (NCC).

En este artículo hablaré sobre los problemas que encontramos al localizar NCC en inglés y alemán y cómo resolvimos estos problemas. Por supuesto, hoy hemos resuelto lejos de todas nuestras tareas, y lo más probable es que este proceso sea generalmente interminable. El artículo considera la visión de todo el proceso en su conjunto y los principios a los que intentamos adherirnos o que estamos empezando a aplicar. El material será útil para aquellos que recién comienzan a diseñar software, planean localizarlo o ya enfrentan problemas, pero aún no saben cómo resolverlos.

Introduccion

A menudo, una empresa piensa en la localización del software cuando el producto está listo y la documentación se ha escrito para ello. Y a menudo también es demasiado tarde para hacer algo con el fin de obtener una buena localización en poco tiempo y no gastar una gran cantidad de recursos en ello.

Es imposible escribir en detalle sobre todos los problemas y dificultades en un artículo, por lo que hablaré un poco sobre las principales etapas de documentación y localización y tocaré varios, en mi opinión, los temas más importantes:

• ¿Qué etapas del ciclo de vida del desarrollo de software afectan la calidad de la documentación y la localización?
• ¿Qué y cuándo hacer en cada etapa?
• ¿Qué enfoques, capacidades de herramientas se pueden usar para resolver problemas y problemas de cada etapa?
• Como una org. ¿La estructura afecta la documentación y la localización?
• ¿Cómo organizar la recepción de comentarios de los usuarios de la documentación?
• ¿Cómo ahorrar tiempo y costos financieros en cada etapa?

Según mis muchos años de experiencia en la documentación y localización de NCC, intentaré responder estas preguntas.

Características de NCC y el proceso de desarrollo.

Naumen Contact Center es un sofisticado software para organizar grandes centros de contacto corporativos o de outsourcing.

¿Cuál es la dificultad de documentar y localizar este sistema?

1. El sistema no está nublado.
2. Configuración compleja, muchas integraciones con varios sistemas.
3. Soporte para múltiples versiones.
4. Como resultado de los párrafos 1-3, tenemos implementaciones y actualizaciones complejas. Cada cliente tiene su propia versión, su propia configuración e integración con varios sistemas.
5. El sistema no es masivo; solo lo usan las grandes empresas. Por lo tanto, el número de clientes no es muy grande en comparación con los pequeños productos en masa.
6. Una gran cantidad de términos específicos.
7. Modelo multi-rol. Y esto significa que la documentación y la interfaz deben adaptarse a las características de cada rol (nivel de conocimiento y características de las tareas).
8. Las interfaces del sistema contienen aproximadamente 30,000 líneas de texto y se escriben alrededor de 3,000 páginas de documentación técnica compleja.
9. Los lanzamientos se lanzan 2-3 veces al año.
10. Después de cada versión, aproximadamente el 10% del texto y la documentación de la interfaz se actualizan y complementan.
11. 3 idiomas: ruso (fuente), inglés y alemán.

Ciclo de vida del desarrollo

Echemos un vistazo al ciclo de vida del desarrollo de software y seleccione solo las etapas que se relacionan con la documentación y la localización:

• Desarrollo de características. Como parte de esta fase, se desarrollan textos para la interfaz.
• Documentación Como parte de esta fase, se desarrolla la documentación, incluida la creación de capturas de pantalla y otras imágenes.
• Localización de la interfaz en varios idiomas.
• Traducción de documentación a otros idiomas, incluida la localización de capturas de pantalla y otras imágenes.

Ahora imaginemos que se cometió un error menor en la interfaz. Se aplica automáticamente a cada etapa, a varias versiones e idiomas.



Pueden aparecer errores adicionales en cada etapa, es decir, como resultado, podemos obtener una gran cantidad de errores. Los errores menores de la interfaz probablemente nunca se solucionarán; siempre hay tareas más importantes. Y si los edita, el costo de estas ediciones será muy alto, ya que nuevamente tendrá que pasar por toda la cadena, todas las versiones y los idiomas. Y cuantas más versiones e idiomas, más caro.

En este contexto, no se puede hablar solo de la calidad de localización de la interfaz o de la calidad de la documentación traducida, ya que el resultado del trabajo de cada etapa es la base de la siguiente. Es por eso que es muy importante hacer todo bien de inmediato en cada etapa. Y es por eso que vale la pena considerar el desarrollo de software, la documentación y la localización como etapas de un único proceso inextricable.

Organización del texto en la interfaz.

Cuando nuestros programadores comenzaron a localizar el sistema, no estaba preparado para esto. El texto de la interfaz se almacenó en el código, y el deseo de la administración era: "hacer todo rápidamente". Los programadores escribieron un guión que extrajo todo el texto del código y lo arrojó a los archivos de recursos, y al día siguiente entregaron los archivos de recursos al primer empleado que sabía inglés, que rápidamente tradujo todo al bloc de notas. Lo que vino de esto se puede ver a continuación.



La imagen muestra un botón simple, abre un formulario con parámetros, donde estos parámetros se pueden cambiar. Hay docenas de tales botones en el sistema. En ruso, había 3 opciones para dicho botón; la localización al inglés ya contenía 7 opciones.

En esta situación, inmediatamente existe un gran deseo de limpiar las líneas de la interfaz. Para hacer esto, propongo aplicar las siguientes reglas:

• División de todas las líneas en grupos.
  
  Todas las líneas deben dividirse en grupos según el tipo de elementos de la interfaz. Incluso si las líneas tienen el mismo texto, pueden aplicarse diferentes reglas de traducción para diferentes grupos. Por ejemplo, la regla de mayúsculas para la primera letra de cada palabra en inglés. Para algunos tipos de elementos de interfaz, se usa, para otros no.
• Eliminando duplicados.
  
  En cada grupo, tiene sentido eliminar todas las líneas duplicadas, es decir, líneas con el mismo texto. Luego habrá la única opción tanto en ruso como en otros idiomas. Esto ahorra costos de traducción. Observo que lo más probable es que las líneas repetidas permanezcan, ya que en algunos casos el contexto puede ser diferente. Además, tales líneas con el mismo texto fuente pueden traducirse de diferentes maneras. Por ejemplo, la palabra Nombre , en el contexto del nombre de una persona, se puede traducir como Nombre y, en el contexto del nombre de un archivo, simplemente Nombre .
• Agregar contexto a los identificadores de línea.
  
  El identificador de línea puede consistir en el identificador de la línea misma y el grupo al que pertenece la línea. Esto es necesario para que el traductor pueda usar el identificador para seleccionar una regla de localización. Si tenemos esos identificadores correctos, entonces el proceso de verificar y corregir los mismos errores de capitalización puede automatizarse fácilmente.

Desafortunadamente, la aplicación de estas reglas a todas las 30,000 líneas existentes a la vez lleva mucho tiempo. Aquí estamos en la etapa inicial y gradualmente ordenamos las líneas repetidas con mayor frecuencia y desarrollamos reglas para nuevas líneas. Pero debes admitir, ¡sería estupendo si todas las reglas se explicaran e implementaran de inmediato!

Documentación y proceso de localización

Echemos un vistazo a la documentación basada en el tiempo y al proceso de localización. Si comienza a documentar y localizar antes de que finalice el desarrollo de la característica, tendrá que rehacer todo (quizás varias veces).

Lo mismo con la traducción de documentación.

Y si entrega la documentación a los usuarios antes de que finalicen todas las ediciones, puede contar con un montón de comentarios. Lo más probable es que algunos de estos comentarios se corrijan en las últimas etapas de desarrollo, pero tendrá que dedicar más tiempo para procesarlos.



Si los procesos no están coordinados, y no hacemos un seguimiento de todos los cambios a tiempo, entonces "nada-nada-en ninguna parte" no se corresponderá.

La documentación no coincidirá con la interfaz. Las capturas de pantalla no coincidirán con la interfaz y el texto de la documentación.



Lo mismo con la localización. El texto de la interfaz y la documentación en el idioma de origen no coincidirá con el texto de la interfaz y la documentación en otros idiomas.



Decidimos que en este momento podemos permitirnos comenzar cada nueva etapa solo después de haber terminado la anterior.



Sí, nuestra documentación y localización llegan tarde después del lanzamiento. Y hablando de localización, ya hemos asegurado la posibilidad de localización continua, pero no usamos esta oportunidad y hacemos toda la localización en un solo paso al final del lanzamiento. Un par de días como parte de un lanzamiento semestral es una etapa muy pequeña.

Mientras nuestro producto no sea masivo, no tenemos una necesidad urgente de documentación y localización para aparecer el mismo día. Tenemos lanzamientos largos, grandes clientes corporativos, de los cuales no hay muchos en comparación con productos pequeños y más masivos, y no comienzan inmediatamente a instalar una nueva versión del producto ni a actualizarlo. Los costos de la remodelación constante se reducen notablemente.

Problemas terminológicos

En la etapa de documentación y localización, constantemente enfrentamos problemas con la terminología:

• Las mismas entidades se llamaron de manera diferente, y las diferentes entidades se llamaron igual.
• Los mismos términos se tradujeron de diferentes maneras, y diferentes términos se tradujeron de la misma manera.
• Una entidad podría equipararse con sus entidades secundarias en las que consiste, o entidades principales.
• Se eligieron términos incorrectos o incorrectos para denotar una entidad.

El proceso de desarrollo para nosotros por algún tiempo se veía así:

• Los analistas están escribiendo una producción.
• Los probadores prueban la producción.
• Código de desarrolladores.
• Los probadores prueban el resultado.

Y cuando intentamos meternos en este proceso con terminología, recibimos tales excusas:

• Ralentizarás todo el proceso.
• Esto generalmente no es tan importante.
• Tienes las herramientas, puedes arreglar todo más tarde.

Pero "más tarde" resultó que no podemos arreglarlo todo. Por ejemplo, hubo situaciones en las que, debido a una terminología incorrecta, los objetos del sistema se ubicaron en los niveles de jerarquía incorrectos o se combinaron en grupos incorrectos.

Ahora estamos comprobando los términos y el texto de la interfaz en paralelo con las pruebas de configuración. Es decir, mientras los evaluadores escriben sus comentarios, nosotros escribimos los nuestros.



Lo que hacemos durante las pruebas de producción:

• Revelamos nuevos términos.
• Verifique el texto de la interfaz: para el uso correcto de los términos, el cumplimiento de la guía de estilo y el cumplimiento de los roles.
• Identificamos líneas existentes para no hacer duplicados.
• Estamos de acuerdo en la necesidad de localización, ya que algunas partes de la interfaz solo se pueden usar en un país.

Al revelar nuevos términos, los agregamos al glosario, mientras que:

• Agregar una definición o contexto.
• Indicamos la relación con otros términos (indicar términos padre e hijo).
• Estamos tratando de indicar de inmediato el significado en inglés, ya que después de elegir el nombre en inglés, a veces queda claro que el ruso no se elige correctamente.

Podemos decir que debido a la coordinación de la terminología y los textos de la interfaz en la etapa de aprobación de la configuración, comenzamos a ahorrar mucho tiempo en múltiples correcciones en las etapas posteriores.

Documentación

Los principios a los que nos adherimos al documentar:

• Utilizando un sistema de fuente única.
• Usando el glosario.
• Usa la guía de estilo.
• División de la documentación en documentos pequeños y fácilmente enajenables.
  Vale la pena hacerlo, incluso si el formato principal es la Web. Si es necesario, no puede traducir toda la documentación, sino solo los documentos más importantes, o hacerlo por etapas.

Ahora hablaré sobre algunos de los aspectos más importantes del proceso de documentación.

Reutilizar texto

En la mayoría de los sistemas de fuente única, se pueden usar variables. Por lo tanto, desarrollamos scripts que convierten automáticamente los archivos de recursos de la interfaz en archivos variables. En el proceso de desarrollar documentación, no escribimos textos de elementos de interfaz, sino que insertamos variables en el texto. Por lo tanto, en la versión rusa, las líneas rusas se incorporan automáticamente, en la versión inglesa, inglés, en alemán alemán.



¿Cuáles son los beneficios?

• Los errores en el texto de los elementos de la interfaz se excluyen si se mencionan en la documentación. Los textos de los elementos de la interfaz en la documentación son siempre idénticos a los textos en la interfaz.
• Si las líneas de texto han cambiado en la interfaz, cambian automáticamente en la documentación.
• Los errores se excluyen al traducir textos de elementos de interfaz en la documentación.
• Un traductor pasa menos tiempo trabajando.

Hay muchas oraciones duplicadas en la documentación. Por ejemplo, una oración como: "Haga clic en el botón Guardar ". En sistemas de fuente única, dicha propuesta se puede colocar en un fragmento. Un fragmento es un archivo tan pequeño que se puede insertar en otras páginas de la documentación.



Como puede ver, el texto del botón Guardar en el fragmento también se sustituye de la variable.

Esto proporciona los siguientes beneficios:

• Las oraciones de significado idéntico son idénticas en todas partes, lo que significa que aumenta la uniformidad del texto.
• El costo de desarrollar documentación a través de la reutilización se reduce.
• Dichas oraciones se traducen solo 1 vez. Esto reduce el costo del traductor.

Capturas de pantalla y otras imágenes.

En nuestra documentación, a menudo utilizamos capturas de pantalla y otras imágenes que pueden contener texto.

Para tomar capturas de pantalla en diferentes idiomas por nuestra cuenta, debajo de cada captura de pantalla escribimos el texto que se utiliza en ella. Este texto está etiquetado y no aparece en la documentación terminada. Antes de traducir la documentación, traducimos textos para capturas de pantalla. Y durante la traducción de la documentación tomamos capturas de pantalla por escritores técnicos sin conocimiento del idioma.

Usando capturas de pantalla, hay otras dificultades. Por ejemplo, ¿cómo rastrear todos los cambios si la interfaz cambia una línea de texto, que se usa en 50 lugares?

¿Cómo encontrar todas las capturas de pantalla de estos 50 lugares para reemplazarlos en la documentación?

Para resolver este problema, utilizamos la herramienta QVisual que desarrollamos en Tinkoff. El proceso de trabajar con él se ve así:

1. Durante el desarrollo de la documentación, debajo de cada captura de pantalla hacemos un enlace al soporte donde se toma esta captura de pantalla.
2. En cierto punto, preparamos una lista de todos los enlaces.
3. Cargamos la lista recibida en QVisual.
4. QVisual ejecuta una versión del producto y toma una serie de capturas de pantalla.
5. A continuación, tomamos la nueva versión del producto y QVisual la ejecuta utilizando los mismos enlaces.
6. QVisual luego compara 2 conjuntos de capturas de pantalla y genera un informe. En el informe, gráficamente, puede ver las diferencias entre las dos versiones. Un ejemplo está abajo. Puede ver de inmediato que en la nueva versión de la captura de pantalla aparece un campo adicional Idioma de la interfaz de usuario .
7. A continuación, repetimos el procedimiento de comparación (p. 1-6) para cada idioma.
8. Tomamos los informes y revisamos las capturas de pantalla en la documentación.

Por lo tanto, reducimos el costo de numerosas comprobaciones manuales de capturas de pantalla. Además, manualmente no siempre es posible identificar todos los errores, simplemente puede pasar por alto algo.

Es cierto que no todas las ventanas se pueden abrir mediante enlaces y esto solo funciona para la interfaz basada en la Web, pero aún elimina algunos de los problemas con la actualización de capturas de pantalla.

Localización de la interfaz

Antes de localizar la interfaz, si esto aún no se ha hecho, debe traducir todos los términos del glosario.

Cuando se traduce el glosario, puede comenzar la localización. En este proceso, nos adherimos a los siguientes principios:

• Usa el glosario.
• Usamos la memoria de traducción.
• Usamos la guía de estilo.
• Usamos un contexto.
• Utilizamos el control de calidad automático (QA).

Observo que el contexto puede tener una mayor prioridad para tomar una decisión de traducción que tener la misma línea ya traducida en la memoria de traducción. Además, según el contexto, pueden aplicarse ciertas reglas de traducción que se especifican en la guía de estilo.

Puede haber varias formas de proporcionar contexto:

• Como escribí anteriormente, el contexto se puede establecer en el identificador de cadena o en campos adicionales de archivos de recursos (si el formato lo permite).
• Se pueden agregar capturas de pantalla. Por el momento, podemos agregar capturas de pantalla manualmente a líneas particularmente complejas.
• Proporcionar stands y documentación en el idioma fuente. Como muestra la práctica, este método no funciona. Los traductores generalmente no utilizan los materiales y soportes que se les proporcionan. Quizás porque el tiempo que lleva traducir una línea aumenta muchas veces.

Traducción de documentación

Los principios que tratamos de cumplir al traducir la documentación:

• Primero, traducimos textos para capturas de pantalla y otras imágenes. Como escribí anteriormente, las capturas de pantalla se toman en paralelo con la traducción de la documentación. Esto se hace en el stand utilizando textos traducidos para capturas de pantalla.
• Traducimos solo líneas cambiadas y nuevas. Las líneas traducidas previamente con una coincidencia del 100% simplemente no se ven. Sí, puede volver a leer toda la documentación de cada versión, pero teniendo en cuenta el hecho de que cada versión se actualiza aproximadamente el 10% del texto, restar el 90% restante del texto es un costo injustificado.
• Usa el glosario. El glosario debe traducirse antes, en la etapa de localización de la interfaz.
• Usamos la documentación de traducción de memoria.
• Usamos la interfaz de traducción de memoria.
• Usamos la guía de estilo.
• Utilizamos control de calidad automático (QA).

Estructura organizacional y retroalimentación

Diré algunas palabras sobre la estructura organizativa de la empresa. Es diferente para todos, pero imagine un caso en el que cada departamento tiene su propio departamento.



La retroalimentación de un departamento al anterior en esta versión será difícil, la interacción entre empleados de diferentes departamentos es difícil. La solución de todos los problemas a través de la cabeza también es un "cuello estrecho". Cada líder tiene su propia visión, objetivos y prioridades. Se puede gastar mucho tiempo en aprobaciones adicionales.

En mi opinión, un departamento debería ser responsable de todos los textos en todos los idiomas.

Con esta distribución de responsabilidad, cada versión del producto es un proyecto separado de varias etapas, y la calidad de la implementación de este proyecto debe ser respondida como un todo. Es más fácil establecer comentarios, comprender rápidamente cualquier problema, hacer una retrospectiva y encontrar la causa raíz del problema.

Daré un ejemplo.

Debido al hecho de que nuestros propios escritores técnicos verifican las traducciones usando QA, vimos docenas, si no cientos, de errores de inconsistencia.

Resultó que el traductor ve las oraciones que tienen un significado idéntico, pero de diferentes maneras, y hace la misma traducción para ellas. Iniciamos la tarea y el escritor técnico reemplazó todas las versiones diferentes del mismo texto en el sentido de un fragmento. Ahora no habrá tales errores repetidos. Los profesionales no tendrán que perder tiempo analizándolos, y la traducción a nuevos idiomas será más fácil en el futuro.



En el caso general, si el traductor tiene preguntas durante la traducción, entonces para nosotros ya es una "campana" que algo está mal en las primeras etapas y tenemos que hacer la tarea de corrección.

¿Qué documentación de calidad se necesita?

Antes de intentar hacer una documentación perfecta en todos los idiomas, ¿vale la pena considerar qué calidad se necesita? Preguntas adicionales ayudarán a responder esta pregunta:

• ¿Quiénes son los usuarios de la documentación?
  Si la documentación es de dominio público y los clientes toman la decisión de comprar el producto, entonces la calidad debe ser casi la ideal. ( ), . , . , : , , . .
• ?
  , , . . ? , , .

:

• .
  
  , , -50 , . - 1-2 , .
• .
  
  CAT-. , (, ), .
• , , , .
• , .

Web- . , , .

. , .

. . , .

:

• .
  
  - , . . , Ctrl+Enter . . .
• .
  
  , . , , .
• .
  
  , , . , ( ), . , . .

, , , . , , .

Conclusiones

, -, .

, , .

. .

, ! !

, !