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?