lunes, 21 de diciembre de 2015

Retrocesos en la traducción de un programa, o avances mal documentados

Al lanzarse este año la beta de JAWS 17, el lector de pantalla para Windows de Freedom Scientific, se hablaba de mejoras en el proceso de traducción, y ya en las novedades no sólo se incluía una nota dando cuenta de la imposibilidad de importar automáticamente configuración de versiones anteriores debido a la reestructuración de carpetas producto de estas mejoras, sino también de un modo de compatibilidad para que los scripts compilados en JAWS 17 funcionasen en versiones anteriores. Esos datos eran muy genéricos y todo lo relativo a la traducción de programas informáticos me apasiona, de modo que bajé la beta a fin de echarle un vistazo a este aspecto.
El producto final se lanzó en octubre y en noviembre se publicó una actualización que entre otras cosas resolvió un problema de aceleradores traducidos que con el nuevo sistema de traducción habían dejado de estarlo sin que se diera cuenta de ello en los menús pero, hay interrogantes importantes que todavía el fabricante no se dignó a responder. Aprovechando la última entrada de Pablo Muñoz Sánchez en su blog Algo Más Que Traducir, titulada «Investiga. Experimenta. Traduce. Aprende.», que es precisamente lo que estamos teniendo que hacer los usuarios de comunidades tiflotécnicas involucrados en la traducción de scripts para este lector de pantalla ante la falta de información técnica más allá del mensaje publicitario de las mejoras en el proceso de localización, hoy comparto con ustedes lo que fui encontrándome en esta odisea desde que bajé la beta para un somero vistazo hasta ahora que, salida la versión final, me es importante ir entendiéndola.

Traducción hasta la versión 16 inclusive

Los ejecutables incluían recursos en inglés y, para otros idiomas, en la misma carpeta que los archivos ejecutables había archivos DLL con la extensión de cada idioma que contenían recursos estándar de Windows (dialogs, menus, stringtables etc.), incluso aceleradores traducidos en aras a la coherencia con el material didáctico incluido que enseña a manejar Windows. Había además sendas carpetas Help y Manuals, con subcarpetas para cada idioma y los archivos correspondientes.
Hasta aquí no hay nada que el más aficionado de los traductores no conozca, pues casi cualquier programa dispone de archivos DLL con recursos, algunos manuales en formatos de texto o Word y/o ayuda en HTML compilada con extensión .CHM de esas cuyo visor en Windows muestra el contenido a la izquierda y el tema seleccionado en forma de página web a la derecha.

Lo más interesante en la traducción de este programa son sin embargo los scripts, tanto en el conjunto de archivos Default que controlan el comportamiento del lector en todo el sistema como los específicos de aplicaciones. Y es que además de lo poco estándar del procedimiento de localización, son los que a efectos de traducción contienen los mensajes a verbalizar, explicaciones de las combinaciones de teclas que proporcionan, pronunciaciones específicas por ejemplo de conjuntos de símbolos para leer los emoticonos que representan, y dependiendo de cada caso las asignaciones de teclas de determinados scripts para ejecutar sus funciones, que no siempre se traducen.
Explicar el funcionamiento de JAWS en una entrada de blog sería complejo, pero veamos para ponernos en perspectiva qué pasos se seguirían para traducir un conjunto de scripts para una aplicación específica:

  1. Colocamos los archivos del conjunto de scripts en la carpeta, ya sea de nuestro usuario o compartida, Freedom Scientific\JAWS\Versión —p. ej. 16.0—\Settings\código_de_idioma —p. ej. esn para español—. Se llaman igual que el ejecutable de la aplicación cuyo uso con JAWS mejoran, con una serie de extensiones que empiezan con J; existe un archivo especial llamado ConfigNames.ini para incluir nombres de scripts más significativos que el de los ejecutables (p. ej. para poder llamar a los archivos de un script Microsoft Word en vez de Winword, pero rara vez se utiliza con scripts distintos de los que vienen con JAWS y, por ende, no es menester que lo tratemos aquí.
  2. En el conjunto de archivos que acabamos de copiar, procederemos a ver si hay uno o más con extensión .JSM (JAWS Script Messages), que contienen los mensajes a verbalizar y en ocasiones mostrar en pantalla por los scripts, además de nombres de ventanas o cualquier otra información, visible en pantalla o no, que proveniente de las aplicaciones usen los scripts para comparar cadenas a efectos de funcionalidad que las aplicaciones no permiten de manera programática. Esto puede estar en los mismos archivos .JSS (JAWS Script Source) que constituyen el código fuente, pero que esté separado permite realizar la traducción sin necesidad de modificar el código, referenciando este último en las funciones los identificadores de mensajes del archivo .JSM. Estos archivos estarán asociados al Asistente de Scripts de JAWS, pero se pueden modificar con cualquier editor de texto y de hecho para su edición, a diferencia de lo que ocurre al modificar o crear el código fuente, el Asistente de Scripts de JAWS no proporciona funcionalidad específica relevante para el trabajo con este tipo de archivos. Además de lo puramente necesario (@msg_identificador (a veces seguido de _l o _s para leer un mensaje en versión larga o corta a fin de prever ambas configuraciones sobre los mensajes), salto de línea, cuerpo del mensaje (incluyendo marcadores de posición a reemplazarse en tiempo de ejecución con valores de variables o devueltos por funciones), salto de línea y @@ para cada mensaje, un archivo JSM bien diseñado contiene comentarios (que empiezan con punto y coma) sobre el cometido de los marcadores de posición, ante qué circunstancias se generará un mensaje, qué cadenas deben traducirse exactamente como las muestra la aplicación para no estropear la funcionalidad y, cuando uno se halla ante un archivo de lujo, cadenas on y off distintas para cada opción que permitan hacer honor al género y número de cada configuración. Para poner un ejemplo de cadena que ha de traducirse igual a como está en la aplicación, en Skype la lista de mensajes de una conversación se llama Lista del contenido del chat; aunque Lista de contenidos del chat no sería del todo incorrecto como traducción de Chat content list, si tradujéremos Lista de contenidos del chat las funciones que ejecutan los comandos de estos scripts para leer los últimos mensajes o la opción para leer automáticamente los que van llegando no funcionarían, pues buscarían una lista llamada Lista de contenidos del chat que no existe y, de hecho, los comandos para lectura manual de mensajes dirían el mensaje No estás en una ventana de conversación.
  3. Si lo hay, abrimos el archivo con extensión .JSD (JAWS Script Documentation), que de cada script contiene sinopsis, descripción y a veces el nombre a mostrar en el Buscador de Comandos, una herramienta introducida en JAWS 16 para evitar tener que leer ayudas extensas cuando uno se olvida de la combinación de teclas para alguna operación; la sinopsis y la descripción se emplearán en el modo Ayuda de Teclado, aquel en el que el lector no ejecuta acciones sino que, al pulsar teclas o combinaciones de las mismas, las verbaliza e informa de para qué sirven. En este archivo también se documentan funciones, pero al no verbalizarse salvo que el usuario active herramientas de desarrollo, es costumbre dejar su información sin traducir.
  4. De haber un archivo con extensión .QSM (Quick Settings Messages), lo abriremos y modificaremos con cualquier editor de texto; extrañamente, no está entre los tipos de archivo que el Asistente de Scripts reconoce. Su cometido es que se agreguen al árbol de Configuración Rápida, una utilidad de JAWS 13 y superiores para cambiar ajustes sobre la marcha, las opciones específicas de los scripts que se están traduciendo, además de sus descripciones a mostrarse en el lado derecho de esta ventana. Más allá de su extensión exótica, se trata de un archivo XML estándar sin sorpresa alguna para ningún traductor ni aficionado acostumbrado a estos menesteres. Sí conviene cerciorarse de que la codificación declarada coincida con la real, pues de lo contrario al abrir Configuración Rápida con INSERT+V, se generarán errores al «parsear» aquellos puntos del archivo en que aparezcan caracteres internacionales como pueden ser la ñ o las letras acentuadas.
  5. Si quisiéramos cambiar la tecla o combinación de teclas asignada a alguno de los scripts del conjunto, sea porque en la aplicación para la que son los atajos de teclado están traducidos y/o para tornar más intuitivo algún atajo específico de la «accesibilización» medio difícil de recordar y que en inglés tiene algún componente asociativo, lo haremos en el archivo con extensión .JKM (JAWS Key Map). Si los cambios son complejos será mejor abrirlo en algún editor de texto como el mismo Asistente de Scripts de JAWS, pero si los cambios no involucran secuencias de comandos complicadas será más fácil realizarlos con el Asistente de Teclado de JAWS, un programa para lidiar con estos archivos que para editar las combinaciones de teclas ofrece una interfaz gráfica.
  6. A este punto, estamos en condiciones de compilar los scripts y probar qué tal funcionan. Para ello, abriremos en el Asistente de Scripts el archivo con extensión .JSS y pulsaremos CTRL+G. Si utilizamos otro editor de texto, será menester configurarlo para que el comando de compilación llame a %programfiles%\Freedom Scientific\JAWS\Versión\scompile.exe y le pase el nombre del o los archivos que se van a compilar.
  7. En ocasiones, se puede incluir un archivo con extensión .JDF (JAWS Dictionary File). No hacen al funcionamiento de los scripts, pero estos archivos contienen reglas de pronunciación para palabras o expresiones. ¿Por qué se incluirían de serie con un conjunto de scripts si el usuario suele personalizar la pronunciación de las palabras que le interesan en el diccionario predeterminado? Las causas pueden ser varias, pero el ejemplo más sencillo sería el dirigido a un cliente de mensajería instantánea en aras a que los conjuntos de símbolos relevantes no se lean en sí, diciéndose en su lugar la descripción de los emoticonos que representan, por ejemplo, cara triste o mueca de disgusto. Se pueden modificar con cualquier editor de texto, pero afortunadamente el Asistente de Diccionario de JAWS constituye una interfaz gráfica que minimiza la posibilidad de cometer errores editando a mano, sobre todo ante operaciones avanzadas como incluir en el mismo archivo pronunciaciones para varios idiomas de la voz o crear reglas que distingan entre mayúsculas y minúsculas.
  8. Si miramos nuevamente los archivos de que disponemos, advertiremos que se ha modificado (o creado si no disponíamos de él) un archivo con extensión .JSB (JAWS Script Binary). Es el resultado de compilar el archivo .JSS, que contiene a su vez los .JSM y otros que en el JSS se agreguen con una sentencia include, por supuesto, como su nombre indica, binariamente de forma que se puedan utilizar a nivel máquina.

La desventaja de este enfoque es que debe disponerse de todos los archivos en todas las carpetas de idioma, inclusive de aquellos que no hay necesidad de traducir. Así, por ejemplo, en JAWS en español que también incluye versión en inglés, se tienen las carpetas ESN y ENU con archivos JSS idénticos, que pesan unos 9 MB en cada carpeta. Si a eso sumamos archivos de audio y otros como QS y JCF que tampoco se traducen, no es extraño que los instaladores de versiones de JAWS traducidas doblen en tamaño a los originales en inglés un centenar y algo más de MB.
Para los traductores, por otra parte, el trabajo de tener que ocuparse no sólo de traducir los ejecutables y las ayudas como en cualquier software, sino también de los archivos de scripts mencionados para cada aplicación de la que se prevén adaptaciones específicas, y eso sin contar el conjunto de scripts con nombre Default destinados a funcionar en todo el sistema supletoriamente a los scripts específicos de aplicaciones, sin duda es arduo.

La traducción en JAWS 17: de la irrupción de Gettext

En la carpeta de archivos de programa ya no hay archivos DLL separados para cada idioma, ni carpetas de ayudas y manuales. Todo ello se ha movido a la carpeta de JAWS en Programdata.
Nada cambió en cuanto a manuales y ayudas, pero ya casi nada es igual en cuanto a traducción del programa y los scripts.
La carpeta Settings continúa existiendo, pero en la escena de carpetas compartidas su protagonismo es menor, porque hay una carpeta separada Scripts, que es en la que comienzan las sorpresas.

En la carpeta Scripts hay subcarpetas con cada código de idioma, las cuales de los scripts que vienen con el producto contienen los archivos de asignaciones de teclas que como vimos a veces se traducen, de diccionario que considerando que pueden contener reglas en varios idiomas bien podrían haberse dejado en la carpeta raíz, archivos de documentación y en algunos casos de braille; en la carpeta raíz, de estos mismos conjuntos, están los códigos fuente, los binarios compilados y ¡un momento!, ¿por qué hay aquí archivos JSM y QSM que no están en las carpetas de cada idioma? Si los abrimos descubrimos su contenido en inglés, pero algo tiene que haber pues gran parte de su contenido se nos muestra traducido en tiempo de ejecución. Es aquí donde entra Gettext con los archivos PO y MO, tan comunes en el software libre:
Fuera de la carpeta Scripts, ahora existe una Locale con subcarpetas para cada idioma. En la perteneciente al inglés sólo hallamos Help, Manuals y Resources, esta última con archivos que antes eran recursos de tipo BITMAP y WAVE dentro de los archivos de idioma; no hay aquí archivos que traduzcan la interfaz, naturalmente, por cuanto los recursos para ello están en los propios ejecutables. Para otros idiomas como el español, sin embargo, encontramos además dos carpetas adicionales, a saber:

DialogLayouts
Los diálogos que antes se debían redimensionar en los archivos de recursos de cada idioma, ahora se redimensionan a través de archivos .JSON con información de las medidas de cada diálogo de cada ejecutable que se debe traducir.
LC_MESSAGES
Quien haya colaborado en proyectos de software libre ya habrá adivinado lo que es esta carpeta. Pues sí, contiene archivos jaws.po y el compilado jaws.mo, cuyo papel será el tema central de lo que queda de la entrada.

En este catálogo hay cadenas de (casi) todos los ejecutables para los que antes había DLL de idiomas y, lo más interesante, de los archivos JSM y QSM de todos los scripts de fábrica. A primera vista la ventaja para los traductores parece innegable, pues se reduce considerablemente el trabajo de ocuparse de tantos archivos, y eso sin perjuicio de que todavía no se alcanzó en un grado ideal, pues los archivos JKM y JSD todavía se deben traducir por separado y, los de diccionario donde los haya, también. Para el usuario también es una ventaja el hecho de no tener que volver a compilar los archivos de scripts después de modificar los JSM por ejemplo a efectos de corregir un mensaje, lo que resulta de mucha importancia al editar contenido de Common.jsm al que remite Default.jss, pues antes si se cometía un error y se compilaba Default.jss, la compilación fallaba y dejaba a JAWS inutilizable, mientras que ahora con programas como Poedit uno puede buscar la cadena que le interesa y, tras editada y guardado/compilado el catálogo, cerrar y volver a cargar JAWS para estar surtiendo efecto.
Si hubiera scripts de JAWS para Poedit que permitieran leer las notas para traductores de una cadena sin necesidad de navegar manualmente por la jerarquía de objetos, traducir mensajes de los archivos JSM en Poedit sería casi tan cómodo como hacerlo en el Asistente de Scripts pudiendo ver los comentarios de cada cadena, e incluso de varias líneas antes donde se explica el funcionamiento de una serie de tres o cuatro mensajes que va a comenzar. Más aún, editores especializados como éste son capaces de informar sobre falta de marcadores de posición de variables en las traducciones o traducciones dudosas y, aunque sea comprensible que al ser la primera versión se hayan trasladado automáticamente incluso cadenas con errores de los que comento, por ejemplo una que en la edición traducida le falta un %1 y por lo tanto si uno no la arregla dice menú pero sin anunciar el nombre del menú, es de esperar que su posterior detección y corrección futura sea más sencilla.

El problema realmente gordo aparece con scripts de terceros, porque aparte de que ninguna ayuda da cuenta de la nueva estructura de carpetas ni siquiera en lo atinente a los scripts compartidos que puede agregar el usuario, el material tanto didáctico como de referencia para desarrolladores no se actualizó y en las novedades sólo se nos dice esto:

By default, scripts compiled using the Script Manager or the scompile.exe command line tool in JAWS 17 will not work with prior versions of JAWS. This is due to changes in JAWS 17 to improve the localization process. In order to compile scripts that will work in JAWS 17 as well as prior versions, the following line must be added to the JSS file before compiling your scripts.

;#pragma usePoFile 0

If this line is not included, scripts will be compiled using the new localization model and will only work with JAWS 17 and later.

Ante la falta de más información, y dado que de recompilar scripts para versiones anteriores si uno no agrega esta línea los caracteres internacionales no se procesan correctamente, muchos autores están optando por agregar la línea antedicha y que continuemos traduciendo como hasta ahora, lo cual se sigue admitiendo y no ha dado problemas. Siendo no obstante el nuevo un comportamiento predeterminado, tanta negligencia a la hora de documentar el cambio me parece inadecuado. Por dar algunos ejemplos, estas preguntas que me hice no se responden en ningún lado y los autores de scripts ajenos a Freedom Scientific, pobres, están tan perdidos como yo:

  • ¿Se pueden guardar catálogos modificados en la carpeta del usuario para que surtan efecto? Probé y no se puede, pero no se informa en ninguna documentación.
  • Si uno quisiera traducir scripts de terceros utilizando el nuevo modelo, ¿debe crear catálogos con los nombres de archivo de los scripts y guardarlo en la subcarpeta de cada idioma, o actualizar el integrado jaws.po para que se agreguen las cadenas de los conjuntos de scripts adicionales que se copiaron?
  • Si hay que actualizar el catálogo de JAWS y no pudiéndose guardar catálogos en la carpeta del usuario, ¿no interferiría modificar el catálogo con la instalación de actualizaciones que a fin de evitar descargar un instalador completo sólo se decargan parcialmente y se realiza el parcheo? Y aun si no interfiriera, ¿no se corre al actualizar el producto el riesgo de que las traducciones de los scripts que agregó el usuario desaparezcan de un plumazo?
  • Si como algunos insinúan este modelo de traducción actualmente sólo es compatible con scripts de la propia Freedom Scientific, ¿por qué no programaron el compilador para que de no existir la línea de compatibilidad mencionada se la tome como si tuviese valor 0? ¿No sería más práctico eso si este modelo sólo se va a utilizar en la empresa?

Conclusión

Por años nos hemos quejado de que cada vez más se acumulaban desperfectos en las traducciones de JAWS que, salvo honrosas excepciones, pasaban versiones y seguían sin solucionarse, aun cuando bastantes de ellos los podíamos solucionar los propios usuarios conociendo un poco el funcionamiento de los scripts y en general la arquitectura modular de JAWS. Así, recibí con emoción la noticia de que se estuvieran efectuando cambios para la mejora del proceso de localización y, sin perjuicio de que siempre sea necesaria una buena comunicación entre desarrolladores y equipos de traducción, la materialización de esta declaración en una incipiente transición a un formato como los catálogos Gettext mucho más estándares que el cúmulo de archivos de que les hablaba al explicarles someramente la traducción de scripts para JAWS 16 y anteriores, en la medida que requerirá menos trabajo de familiarización con formatos nuevos y menos archivos separados de que ocuparse, me parece prometedora pues debería redundar en traducciones más cuidadas, amén de que ante la sensación de haber menos material habrá más tiempo de revisión.
Ahora bien: las mejoras para traductores profesionales involucrados en el software en sí no deberían implicar quebraderos de cabeza para los usuarios, máxime cuando el avanzado lenguaje de scripts para personalizar y adaptar el comportamiento del programa fue siempre una de las características de que Freedom Scientific y antaño Henter Joice han hecho gala a la hora de resaltar las virtudes del producto. La introducción allá por 2003 de los archivos JSM en JAWS 4.51 para permitir traducir scripts sin trastear con el código fuente fue un gran avance. La transición a Gettext tiene potencial de serlo, pero mientras no se documente bien su alcance y aprovechamiento por creadores de scripts, en seguida se presenta como un retroceso, amplificado si cabe por la falta de adaptaciones específicas en forma de scripts de JAWS para Poedit que, aun sin ser el único, es el editor especializado en Gettext que más se utiliza en Windows. Mientras no existan scripts para esta pieza de software, a un usuario ciego le seguirá resultando más cómodo la antigua aproximación de trabajar sobre los archivos JSM por ir viendo los comentarios a medida que aparecen, en lugar de explorar manualmente la jerarquía de objetos de la interfaz de PoEdit para encontrar las notas para traductores sobre una cadena, a veces incluso sin una clara idea de en qué sección del archivo al que pertenece está, pues no hay ninguna manera de aprovechar usando el teclado el agrupamiento que Poedit puede hacer de las cadenas según el archivo del que sean. Ojalá Freedom Scientific vuelva paulatinamente a viejas usanzas o, mejor aún, documente con más diligencia las prometedoras que empezó a implementar.

viernes, 11 de diciembre de 2015

De la (falta de) traducción de aceleradores

De la (falta de) traducción de aceleradores

Desde que me empecé a interesar por la traducción de software, me llama la atención que casi ninguna compañía adopte, ni siquiera en el software para Windows, la decisión de localizar los aceleradores. Como hablar de teclas rápidas sería poco preciso, recordemos que los aceleradores, a diferencia de las teclas de acceso que aparecen subrayadas sobre opciones que se ven en pantalla para llegar a ellas más rápido, son aquellas combinaciones de teclas que ejecutan una operación o alternan la selección de un comando sin tener que pasar por menús o cuadros de diálogo, en especial desde el área de trabajo de una aplicación. Por dar dos ejemplos conocidos de estas últimas para ponernos en perspectiva, ¿quién va para abrir una nueva pestaña en cualquier navegador web —sin importar que sea de los que se consideran prestigiosos, el denostado Internet Explorer en versión 7 o superior o el incipiente Microsoft Edge— al menú archivo para elegir la opción pertinente en lugar de simplemente presionar CTRL+T? ¿Acaso hay usuarios de Word más o menos avezados que para interlinear un párrafo en 1,5 y a su vez justificarlo no hayan pulsado CTRL+J y CTRL+5 en vez de ir a menús o la cinta para configurar esos valores frecuentes de forma manual? Y eso por no nombrar algunos de utilidad mnemotécnica como en cualquier programa de Office CTRL+S para subrayado o CTRL+G para guardar, cuya falta de coincidencia con versiones en inglés ocupará esta humilde entrada.

 

¿Los traducimos o no?

Windows comenzó su andadura de llevar interfaz gráfica al ecosistema de PC en 1985, pero es bien sabido que la versión que terminó de popularizarlo en el gran público, sin perjuicio del gran paso que representó al respecto Windows 3.1 en 1992, fue Windows 95.

Como ante factores como la falta de acceso a Internet, la dificultad que para muchos representaba aprender el manejo de un sistema operativo de texto como lo fue MS-DOS y que inclusive tareas hoy tan triviales como instalar un dispositivo externo no lo eran tanto, no es exagerado destacar el rol familiarizador con la informática que esta versión de Windows y aun posteriores como la 98 tuvieron para muchos. A tal efecto, no sorprende que hubiera disponible documentación de calidad y en cantidad: archivos Léame explicando en detalle métodos de instalación y problemas conocidos, ayuda categorizada con solucionadores de problemas hasta de arranque, videotutoriales, menús que mostraban en la parte inferior de la ventana una breve explicación del comando sobre el que se estaba antes de activarlo y, el que desde que desapareció en Windows Vista añoro, el comando ¿Qué es esto? que documentaba casi cada opción que uno tuviera a su alcance.

 

La abundante documentación no lo fue todo, de ahí pues los distintos métodos en las propias interfaces para efectuar tareas de maneras intuitivas y entre ellos los aceleradores de teclado. Algunos se diseñaron pensando en la cercanía de comandos afines en teclados QWERTY, como los que acompañados de la tecla CTRL van de izquierda a derecha desde la Z (Deshacer) a la V (Pegar) inclusive; otros en cambio persiguieron una finalidad más de carácter mnemotécnico que físico a fin de facilitar su aprendizaje, tales como CTRL+F, CTRL+S o CTRL+O.

 

Y he aquí uno de los debates a este respecto que me planteé varias veces, si traducirlos o dejarlos como están:

Si atendemos a la necesidad antes expuesta de que la gente común se interiorizara sobre el uso de computadoras y al mismo tiempo consideramos que la localización de software trasciende la mera traducción de cadenas de texto para en cambio reproducir la experiencia del software original lo más adaptada posible a las peculiaridades lingüístico-culturales de una determinada audiencia, el hecho de que se hayan adaptado varios de estos s combinaciones de teclas más estándares fue un acierto, porque trasladó a nuestro idioma la facilidad (no casual) que el público angloparlante tiene de recordar los comandos pensando en «la F de find o la S de save». ¿Acaso a la larga no es más fácil, para quien no sabe inglés, recordar que el acelerador de un comando que lee como Ir a... sea CTRL+I en vez de CTRL+G?

 

Por otro lado, y sobre todo ahora con la ingente cantidad de dispositivos con distintos sistemas operativos, que en Microsoft traduzcan estas combinaciones de teclas tan comunes en cualquier aplicación entorpece la productividad cuando se quiere o necesita usar las aplicaciones en otros idiomas y, en aplicaciones de consola donde la línea divisoria entre la entrada de teclado que recibe el SO y la procesada por la aplicación es finísima, puede llegar a impedir funcionalidad que depende de aceleradores libres en un sistema en inglés mas reservado en español por haberse cambiado para otra función. Y hasta aquí lo decidible exclusivamente en Microsoft, pues veremos que los terceros complicaron el panorama más que contribuir.

 

La incomprensible preocupación de otras empresas cuando desarrollan para Windows

Aunque no faltan aplicaciones para Windows impregnadas por completo de su «look and feel» a expensas de los controles y diseños convencionales, son muchísimas las que para evitar reinventar la rueda pudiendo echar mano de librerías del propio sistema y/o que el usuario no deba esforzarse demasiado en entenderlas, no sólo recurren a controles estándares, sino que, además, respetan la disposición que se podría denominar de una ventana de aplicación típica. En estas ventanas me interesan a los efectos de lo que estoy explicando las barras de menús:

Archivo y Edición son, sin duda, dos menús que trascienden a los procesadores de texto. Teniendo en cuenta que por ejemplo Abrir y Guardar en Archivo o Buscar y Seleccionar todo en Edición son comandos también comunes a muchas aplicaciones de naturalezas poco afines, no me entra en la cabeza cómo es que casi ninguna compañía (y digo bien casi, porque más allá de lo que quieran sus fabricantes y equipos de traducción se han de atener, por la naturaleza de estos programas tan ligados al sistema operativo, a los aceleradores de este último) se molesta, con lo que hace años se habla de localización más que mera traducción, en adaptar estas combinaciones de teclas estándares en sus productos para que, al igual que el público angloparlante, los hispanohablantes sin conocimientos del inglés se puedan beneficiar del aprendizaje mnemotécnico realizado con los programas del sistema operativo y otros de Microsoft. ¿Es que ningún traductor contratado por estos grandes terceros como Adobe o Corel usó jamás ninguna versión de Windows en nuestro idioma?

Lo que pregunto no parece concebible, con lo que bien puede ocurrir que los clientes de los traductores no den importancia a este aspecto. Ahora bien, ¿ninguno plantea la problemática a los clientes, como otras menos importantes desde el punto de vista funcional como las mayúsculas en títulos de controles y cuadros de diálogo, con la esperanza de que excepcionalmente algún cliente la entienda? Desafortunadamente sería la palabra de un único traductor contra las guías de diseño de aceleradores que hay en MSDN que a diferencia de las llamadas teclas de acceso afirman que no han de localizarse, lo que nos lleva al siguiente apartado sobre las idas y vueltas de Microsoft.

 

Retractación de Microsoft desordenada

Como veíamos, casi ninguna otra compañía siguió a Microsoft en esta estrategia de localización, lo que incluye el ejemplo, a mi entender bochornoso, del modo de Corel Word Perfect, que hasta la versión X3 para Windows inclusive se traducía al español, pensado para facilitar la transición desde Office 2000 pero que, en español, no refleja el hecho de que en los programas de Office las combinaciones de teclas sí están traducidas. Mala imagen, pues, habrá quedado a algún aventurado consumidor que, confiando en las prometedoras facilidades de transición, haya intentado activar la negrita con CTRL+N (recordemos que para un gran número de usuarios los programas de Office son más una herramienta que una «pieza tecnológica» de las que se exploran y critican con pasión de aficionado) para sólo conseguir un documento en blanco adicional.

Ante este panorama, aparte de convenciones de estilo para desarrolladores que indican que los aceleradores no deben localizarse, Microsoft está poco a poco deshaciéndose de las combinaciones de teclas traducidas.

Aunque yo preferiría que se llegara a un acuerdo de localizaciones únicas de ciertas combinaciones de teclas comunes como lo son para seleccionar todo, abrir, buscar o guardar, la postura que está adoptando Microsoft con Satya Nadella parece la que importa menos costos porque, aunque sea el fabricante del sistema operativo sobre el que se ejecutan muchos programas de los que emplean este modo de interacción en aras a la productividad, la compañía a adaptarse a las demás es una sola.

Pero el problema objetivo no es tanto ese, sino el hecho de que no parece estar habiendo la necesaria comunicación entre traductores, desarrolladores y administradores de proyectos. Y es que en los archivos de recursos, además de las tablas de aceleradores en sí, a no ser que el programa al que pertenecen permita personalizar los atajos de teclado y para mostrarlos en menús se consulten las tablas de aceleradores por las que se reemplazaron las originales en tiempo de ejecución, los comandos de menú incluyen las combinaciones de teclas con que se activan al lado del nombre de la opción, ora seguido ora tabulación —representada por la secuencia de escape \t— de por medio. Microsoft, supongo que por la falta de comunicación a la que achaco este problemón, empezó en Windows 10 a cambiar en programas dirigidos a usuarios avanzados como Información del Sistema y el Editor del Registro, las combinaciones de teclas traducidas por las originales en inglés mas sin dar cuenta de ello en los menús, que siguen haciendo eco de las traducidas de toda la vida.

En efecto, cualquiera que ya tenga Windows 10 (sea la compilación 10240 primera en lanzarse al público en general o la Versión 10511 distribuida en noviembre a través de Windows Update y de la que también ya existen ISO oficiales), puede ingresar al menú Edición en el Editor del Registro y comprobar la coincidencia entre el acelerador mostrado para Buscar y el que en verdad funciona, al igual que en Información del Sistema con este mismo comando y otros en Archivo como lo son Abrir o Guardar; lo mismo podrán hacer en Internet Explorer 11, para cuyo uso no necesariamente hay que tener Windows 10 u 8, con comandos por el estilo y otros más específicos como el empleado para abrir la ventana de la lista de descargas.

 

La nueva consola, caso aparte

Otro componente hubiera sido un buen agregado en los comentarios por habérmelo olvidado o no conocerlo, pero eso no va para la consola, por una razón sencilla:

En Windows 10 la misma está y es plenamente funcional si uno la activa pero, al ser el Símbolo del Sistema una ¿interfaz? a la que hoy en día sólo suelen recurrir los profesionales de TI y usuarios avanzados (un usuario medio la llega a emplear cuando debe resolver un problema que lo requiere, y aun así sólo con instrucciones muy específicas sobre qué debe escribir), se trata de una novedad a la que naturalmente se le dio más publicidad en TechNet como de Windows Server 2016 que en la escena de usuarios «clientes». Las combinaciones de teclas que introduce para interactuar con el texto generado en las ventanas de manera similar a como se hace en aplicaciones con interfaz gráfica no están traducidas, lo cual habida cuenta del público al que se dirige la consola tiene sentido porque, aun sin demasiada destreza en el manejo del idioma inglés, el entendimiento de los comandos que escriben en la ventana del Símbolo del Sistema (aquí me permito nombrarlo en sentido amplio y entender incluido Windows Power Shell, sin perjuicio de la inexactitud técnica de asimilarlos producto de que el último interpreta un lenguaje de scripts) hace presumible que conocen lo necesario de inglés para resolver los problemas que plantea la informática y que, por lo mismo, comprenden perfectamente que para buscar se tenga que usar CTRL+F en lugar de CTRL+B o CTRL+A en lugar de CTRL+E.

 

Ahora bien, lo cierto es que aun si para ventanas de la consola quisiera optarse por traducir aceleradores en pro del factor mnemotécnico, por muy a favor que se esté de esa postura se crearía un problema funcional. Efectivamente, si en programas con interfaz gráfica hay combinaciones de teclas que se deben evitar por hallarse reservadas a funciones del sistema, en el Símbolo del Sistema es más importante lo contrario: el Procesador de Comandos de Windows viene a ser una suerte de puente entre interfaces actuales y las primitivas basadas en línea de comandos, a tal punto que aún en Windows se puede, sin perjuicio de limitaciones de acceso al hardware que hacen la esencia del núcleo NT, ejecutar aplicaciones para MS-DOS. Como debido a esa suerte de puente que constituye la consola ésta recibe las (combinaciones de) teclas que se presionan y las envía a la aplicación que se esté ejecutando, y si a eso le sumamos que ni los programas antiguos ni los propios de 16 bits que todavía trae Windows admiten tecnologías de «glocalización» de Windows actuales como MUI o NLS, traducir combinaciones de teclas de las ventanas de la consola podría aumentar la probabilidad de aceleradores propios del programa en ejecución que no funcionen, lo cual a su vez se agrava en programas antiguos que no han vuelto a compilarse o portarse en plataformas modernas.

 

Y finalmente…

 


Mi opinión

Una vez analizados los aspectos que creo más importantes de este tema cuya información disponible es poca, he preparado el terreno para cerrar afirmando que la decisión de Microsoft de localizar las combinaciones de teclas es la que entiendo más adecuada, por cuanto traslada a nuestro idioma la facilidad que se da al público angloparlante de recordar combinaciones de teclas por la letra inicial —o una cercana a ésta cuando es compartida por otro comando—. Esa postura del pasado hoy resulta problemática porque los productos de otras compañías no tienen atajos localizados, pero sólo porque los traductores no le dieron la merecida importancia intentando generar consenso sobre combinaciones de teclas universales para comandos como Buscar, Abrir, Guardar o Seleccionar todo que, independientemente de la inmensa variedad de software, son comunes a programas de distintas disciplinas y en inglés comparten aceleradores.

La idea de Microsoft de ir desterrando los métodos abreviados de teclado traducidos en favor de los originales en inglés, independientemente de no suscribirla pues como dije preferiría consenso en torno a aceleradores traducidos, no está siendo lo ordenada que debería. Sea cual sea la postura por que se decanten, tienen que dejársela clara al usuario procurando que los métodos abreviados de teclado mostrados en interfaces y ayudas se correspondan con los reales y, no menos necesario, que coincidan entre distintos productos. Situaciones como que en Windows Live Writer tenga que pensar que la negrita se activa con CTRL+B aun cuando en Word de la misma empresa es CTRL+N desde tiempos inmemoriales son inaceptables, tanto desde la perspectiva de un usuario cuya productividad se ve entorpecida como desde el punto de vista del traductor de un tercero que, al enfrentarse a referencias a combinaciones de teclas de software de Microsoft, no puede estar seguro de si debe traducirlas o no, ya no sólo por una política incoherente entre productos, sino por listados que en la ayuda especifican una cosa y en las interfaces otra. Para colmo de males, si ante la inexactitud de la información y la realidad la adivinanza del localizador no sale bien, el primer impulso de cualquier usuario será tirar la bronca a los traductores, cuando probablemente éstos no habrán tomado la decisión sin reparar en la misma ineficiencia que en ese momento sufre el usuario.

 

Y ahora sí, lectores; les toca a ustedes: ¿Envían a este respecto informes a través del formulario para enviar comentarios sobre las traducciones de Microsoft? ¿Han sugerido alguna vez a otra empresa que en sus programas traducidos adapten las combinaciones de teclas en consonancia con Microsoft? ¿Personalizan, cuando es posible, estos atajos comunes para ponerlos en español?

 

lunes, 12 de enero de 2015

Idioma para programas no Unicode en Windows, un espectro innecesariamente abarcativo

Desde Windows 2000 o puede que incluso NT 4, al estar íntegramente basados en Unicode, por razones de compatibilidad hacia atrás con programas diseñados para sistemas anteriores con juegos de caracteres distintos según el idioma (en la práctica la línea de Windows domésticos hasta aparecido XP que de alguna manera buscó unificar ese mercado y el empresarial), en la configuración regional existe una configuración regional del sistema hoy llamada Idioma para programas no Unicode que, precisamente, permite especificar el juego de caracteres al que habrán de recurrir estos programas.

Tanto por la posibilidad que supone de usar muchos programas antiguos como por las ventajas que dicha retrocompatibilidad representa si un desarrollador desea reciclar código, no me opongo a su existencia. ¿Pero es en verdad necesario un espectro de variantes idiomáticas tan amplio? En cuanto a formatos, ese espectro procura ofrecer predefinidas las configuraciones de cómo expresar o separar horas, fechas, monedas, medidas etc. según el país que se escoja; las alfabetizaciones tradicional e internacional existentes para nuestro idioma, por otra parte, establecen el modo de ordenación alfabética al incluir o no el dígrafo /ch como letra independiente antes de la d. Para el caso del idioma para programas no Unicode cuya selección incide en el juego de caracteres que se emplea para éstos, no obstante, tanta disponibilidad de variantes no tiene sentido sino en unos pocos idiomas entre los que no está el español.

Incluso en las épocas en que Windows no estaba basado en Unicode o dicho más propiamente la rama NT estaba tan solo enfocada a las empresas, la versión en español era una sola. A pesar de la existencia de la Compatibilidad multilingüe cual componente de instalación opcional para mostrar textos en idiomas con otros juegos de caracteres (p. ej. de alfabetos no latinos), el juego de caracteres base estaba definido por el idioma en que se instalaba el SO. Entre la inexistencia de MUI y la mencionada disponibilidad de una única versión en español, el idioma para el caso que nos ocupa siempre era español (España, alfab. internacional) y, como para la mayoría de idiomas europeo-occidentales, el juego de caracteres Windows-1252.
Comprendido esto, configurar en los Windows actuales este idioma en una variante de español distinta de la predeterminada (Argentina, Bolivia, Chile, Ecuador, Estados Unidos o cualquier otra) no importa sino problemas, porque ningún programa no Unicode en español que además de en la familia NT pretenda funcionar desde el punto de vista idiomático igual de bien que en Windows 9x/ME podrá hacerlo con una configuración distinta de la alfabetización internacional. Desconozco a qué conjunto(s) de caracteres dirigen las otras variantes, porque para el caso del inglés cualquiera que se seleccione es completamente compatible con las otras y, si nos ponemos a pensar en que los caracteres del español son los mismos en todo el mundo y por lo tanto no precisan de múltiples juegos de caracteres, nuestras variantes también deberían serlo.

Para ejemplificar el problema con algo que podemos ver a diario, no hay nada mejor que los archivos de ayuda en HTML compilados que incluyen muchos programas, aquellos famosos con la extensión .chm que a la izquierda ofrecen los contenidos y a la derecha, con diseño cual página web (por algo es ayuda en HTML). Es un formato que viene de arrastre desde Windows 98 del que Microsoft ha intentado deshacerse, pese a lo cual continúa siendo harto utilizado. El problema que ataña al tópico que nos ocupa es que, al no ser su visualizador completamente compatible con Unicode, para que los títulos y otras peculiaridades menos importantes se muestren bien al ser en idiomas diferentes del inglés, se deben haber creado en el mismo idioma que el establecido en el sistema del usuario para programas no Unicode. Como la inmensa mayoría se crea por todo lo discutido en español internacional, quien tenga este valor establecido en otra variante sólo verá como título HTML Help.
Desde el punto de vista de traductores y creadores de contenido, el programa HTML Help Workshop de la propia Microsoft y gratuito que crea archivos en este formato establece por omisión el idioma del proyecto en el establecido en la configuración regional para los formatos que, como se ve en el propio diálogo de Windows, nada tiene que ver con el estudiado en esta entrada. ¿Qué pasa entonces si el contenido lo crea o traduce un argentino cuyo sistema usa formatos de aquel país y antes de compilar se olvida de cambiar en las opciones del proyecto el idioma a español internacional? Pues que los usuarios de otros países, sea que tengan el idioma para programas no Unicode en español internacional o en el propio de sus países, no verán el título y otras cosas fuera del contenido HTML no se les mostrarán correctamente.

Reflexionado esto, resulta claro que para la mayoría de idiomas sería más adecuado que al establecer esta configuración aparezcan sin variantes, lo cual además de facilitar la búsqueda del deseado evitaría problemas de compatibilidad. Ofrecer variantes para escoger el idioma de esta configuración sólo tiene sentido respecto de idiomas que por tener diferentes alfabetos requieren múltiples juegos de caracteres, tales como el servio que puede tener alfabeto latino o cirílico, o los chinos simplificado y tradicional. Ni siquiera es necesario ofrecer variantes portuguesa y brasileña para el portugués porque, si bien por las diferencias ortográficas se ofrecen traducciones de las interfaces en las dos, los caracteres y por ende el juego de caracteres que se utilizan son los mismos.

Mi consejo, pues, es que si cambiaron esta configuración la vuelvan a establecer en español con alfabetización internacional. Hacerlo, por fortuna, no incide en las configuraciones ordinarias de ubicación y formatos. Es cierto que Windows peca de servicial y si no la tenemos agrega una distribución de teclado del idioma que elegimos, pero de no necesitarse se quita sin más, ya que en realidad lo que se haga con las distribuciones de teclado y demás métodos de entrada no afecta en nada a otras configuraciones.