Software y servicios en español que no deciden qué tipo de usuarios tienen

Siempre que encaramos una conversación oral o la escritura de correspondencia, por el medio que sea, los hispanohablantes evaluamos, aunque sólo sea superficial o inicialmente y lo resultante pueda irse modificando, la (in)formalidad del registro a emplear dependiendo de factores como edad de la otra persona, puesto en una escala jerárquica, cortesía y hasta a veces la clase social. El software y su documentación, no ajenos a esta peculiaridad si sus desarrolladores quieren presencia en el ámbito hispánico y en consecuencia encaran la traducción de sus productos, no es ajeno a la evaluación que, para el caso, no será de un interlocutor sino de una audiencia mayoritaria: No es igual, por ejemplo, el modo en que se dirige al usuario un producto o servicio relacionado con redes sociales al que emplean, verbigracia, herramientas de contabilidad enfocadas íntegramente a funciones productivas —sean estas en ámbitos empresariales o público-administrativos— y es más, seguro recordarán que desde hace 10 años a esta parte son numerosos los servicios (vía web y SaaS) que progresivamente se informalizaron.

Como la penetración que los dispositivos electrónicos están teniendo en nuestras vidas y que para actividades orientadas al consumo la frontera entre computadoras, tabletas y teléfonos inteligentes es difusa en cuanto los dos últimos ofrecen funciones antaño circunscritas a la PC, la falta de uniformidad en el lenguaje de algunos componentes, producto de replanteamientos de aspectos sin modificarse desde hace por lo menos treinta años, hace notorio el requerimiento de que tal uniformidad vuelva a existir.
Pongamos el caso de Windows y Office, productos estrella de Microsoft:

A lo largo de los años, logramos acostumbrarnos a que estos productos nos ustedearan, lo cual desde 2012 empezó a cambiar; cada vez es más corriente ver tanto temas de ayuda como interfaces en estos productos que nos tutean. No es mi intención pronunciarme sobre qué tan bien está que los programas informáticos se informalicen porque, además de haber oído posturas a favor y en contra, la concepción de que el tuteo es informal y el ustedeo formal no es unánime en todo el ámbito hispanoamericano, y ello sin mencionar que en un sentido amplio el formalismo o informalismo no se reduce a esa diferenciación pues abarca otros aspectos como la rigurosidad conceptual para transmitir la información; empero, sea cual sea la que se opte por seguir, considero indispensable que su elección tenga consistencia, profundizando procedimientos de revisión si fuere menester:
Para el caso de Word 2013, en el grupo Revisión de la pestaña Revisar podemos encontrar, entre otras, opciones con estos consejos informativos o, si utilizamos la terminología propia de Office sobre el particular, información en pantalla:

Definir

¿No está seguro del significado de una palabra? Descúbralo.

Sinónimos

¿Te has quedado sin palabras? Deja que te sugiramos otra forma de expresar lo que quieres decir.

Basten estos dos ejemplos reales (no tengo intención, al menos por el momento:D, de realizar cual programa de archivo una recopilación de inconsistencias del registro lingüístico que pueden hallarse en los productos actuales de Microsoft) para ilustrar el aludido fenómeno de inconsistencia. Es comprensible que las áreas cuya funcionalidad no se ha visto afectada hayan sido objeto de soslayo en la «modernización informalizadora» de los textos, pero la alternancia del registro en áreas totalmente nuevas me parece que refleja, más que desatención o desinterés de los equipos de traductores, un dilema que hasta incluso va más allá del idioma español: ¿En qué audiencia se debe pensar para productos que, además de no limitarse ya a grandes corporaciones, gozan en el terreno del consumidor de aceptación y utilización por diferentes generaciones que en otros aspectos se siguen diferenciando? En otras palabras, ¿los productos enfocados a diferentes mercados han de hablar a sus usuarios cual si estos fueran empresarios importantes, consumidores ancianos o consumidores jóvenes tratados como amigos? Puede decirse que se tiende a buscar maneras de expresión neutras pero, toda vez que la total neutralidad en el idioma sin forzarlo es utópica, reflexionar lo anterior será más que interesante.

Si en el contexto de un único producto vimos relucir este problema, más espinoso aún resulta en navegadores web y los contenidos —a menudo dinámicos— que éstos nos entregan: al registro lingüístico que emplea cada navegador debemos sumar el que caracteriza a los sitios web que visitamos y, con frecuencia, al de los programas (CMS, foro, wiki, sistema de comentarios etc.) automáticos que dirigen la interacción y la administración de contenidos sin tener que lidiar con los lenguajes de marcado detrás de lo generado. A modo de ejemplo, veamos cómo pueden entrar en conflicto el registro de un navegador y el de un sitio web determinado en una confirmación de cierre, todo en un mismo cuadro de diálogo:

¿Está seguro de que desea salir de esta página?
Si abandonas esta página, no se cargarán tus archivos.

Con la creación de Chrome a la medida de sus productos podría decirse que Google ha alcanzado en tal sentido una uniformidad casi total, pero crear un navegador web cuando existen múltiples alternativas competidoras y cuando encima el contenido tendrá que codificarse es, en una relación costo-beneficio, matar moscas a cañonazos, con lo que definitivamente no es en absoluto una solución.

Con la amalgama de contenidos introducidos a mano con otros de carácter automático, la sensación de que se está hablando a un usuario diferente no culmina en los navegadores. Así, por ejemplo, podemos encontrarnos con sitios dedicados a videojuegos que naturalmente tutean y en los que, simultáneamente, podríamos encontrar de la mano de sistemas automáticos frases como Inicie sesión o regístrese para enviar comentarios y, cuando las herramientas implicadas no sean de código abierto, no siempre los propietarios administradores de los sitios web correspondientes podrán subsanarlo.

En el ámbito de la traducción sé por experiencia [de aficionado] propia que a veces la elección se nos complica. Para el caso, todas las veces que traduzco programas tuteando pero de pronto tengo que agregar textos personalizados a instaladores cuyos estándares son de usted dudo: ¿lo traduzco tuteando de modo que parezca parte del programa específico, o, por el contrario, ustedeando porque no deja de ser parte del instalador que en última instancia no pertenece al programa principal y durante todo el proceso nos viene tratando de usted? Lo mismo me pregunto, sin que la solución que termino adoptando me acabe de parecer totalmente satisfactoria, cuando traduzco scripts para JAWS hechos por terceros que hago que tuteen y, de pronto, aparece algún mensaje destinado a integrarse con los predeterminados de este lector de pantalla que, para mi desgracia en aquellos momentos, ustedean.

Se sabe que la tecnología de consumo está mutando y, si no es que ha pasado, nos encontramos ante un estado de transición. Sobre multitud de aspectos se está planteando el mejor camino para seguir a futuro, y el rumbo del lenguaje de dicha tecnología no debería ser ajeno a la deliberación: los involucrados en los procesos de traducción deben consensuar, en aras a algo mercadotécnicamente tan importante como es que el usuario siempre sienta que lo que le muestran se dirige a aquel, sobre el registro unívoco de cada producto. Esperemos que, a medida que los vestigios de eras pasadas van desvaneciéndose, la uniformidad idiomática de otrora se vuelva a afianzar.

Problema de género al traducir Checked y Unchecked que indican el estado (des)activado de un control

Una marca de verificación dentro de un rectángulo, un cuadro vacío o relleno, un círculo relleno o no con otro más pequeño y simples marcas de verificación a la izquierda de los elementos en algunas listas, como artificios que posibilitan las interfaces gráficas, son cualitativa y cuantitativamente más que suficientes para indicar, por sí solos, si un control dentro de un programa informático está o no activado; el inequívoco significado de estos gráficos harían innecesario, naturalmente, preocuparse de conceptualizarlos de manera rigurosa.
A veces se decide indicar estos estados de forma textual con On y Off que, como explicara hace tiempo Pablo Muñoz Sánchez, ocasionalmente plantean problemas de traducción al haber únicamente dos cadenas genéricas para todos los casos, pero sirviendo como último recurso echar mano de Sí y No. En cualquier caso, esta aproximación suele estar circunscrita al contexto de una aplicación o juego determinado, ¿pero qué sucede cuando los escenarios en que se emplearán las cadenas escapan incluso al control de los propios desarrolladores?
Tal es el caso de los lectores de pantalla, cuyos fabricantes pueden construirlos previendo el comportamiento de un sistema operativo y la compatibilidad especial con un cúmulo de aplicaciones de uso extendido, pero en ningún caso la variedad de software que a cada usuario podría ocurrírsele utilizar. Así pues, resulta que a los gráficos que aparentemente se expresaban por sí solos es necesario asignarles equivalentes orales y en braille que, por su puesto, han de traducirse.
Exceptuando al Narrador de Windows —aun con la gracia que causa en Vista y 7 con La casilla Tal está comprobado o La casilla Tal está sin comprobar al referirse a casillas de verificación activadas o desactivadas, evidente falta de contexto al traducir que se corrigió en Windows 8—, la mayoría de lectores de pantalla tiene sendas cadenas para Checked y Unchecked que se utilizan para el estado tanto de casillas de verificación, botones de opción/radio, elementos de menú y elementos de listas. Mientras para botones de opción/de radio/circulares el género masculino en (no) marcado o (no) verificado por el que están traducidas las cadenas es adecuado, no lo es tanto cuando se trata de hacer referencia al estado de casillas de verificación o, incluso, cuando en una lista alguna aplicación trate a los elementos con una denominación menos genérica que pueda ser femenina (carpetas, vistas, impresoras, características, funciones, etiquetas, canciones, imágenes, actualizaciones, plantillas, citas, tareas, reuniones, notas, páginas, ciudades y un inacabable etc.).
La solución ideal, obviamente, sería que en todos los lectores de pantalla populares hubiera cadenas para el estado de diferentes controles y así poder traducir el estado con el género correcto. Desafortunadamente no podría optarse en este caso por la solución de Sí o No que propone Pablo Muñoz Sánchez y que es muy buena para cuando el texto acompaña a las opciones, porque con frecuencia se responden preguntas por sí o por no a través de botones de radio, a modo de que lo elegido no se tome hasta no confirmarlo con un botón ordinario como Aceptar o Siguiente.
Quedaría entonces buscar una alternativa para describir estos estados en que no importe el género del control. Examinemos, dada su popularidad, las descripciones físicas que da sobre estos controles verificables el lector de pantalla JAWS for Windows en su programa de carácter didáctico HJPad, concretamente en el «Árbol de controles de Windows»:

Elementos verificados en menús

El gráfico de una marca de verificación aparece a la izquierda del elemento de menú que está verificado. Este gráfico está contenido dentro de un rectángulo.

Casilla de verificación

Un pequeño cuadro a la izquierda de una opción y, cuando la casilla de verificación está activada, una marca de verificación o una X aparece en dicho cuadro. Cuando el elemento no está verificado, el cuadro está vacío.

Botón de opción

Tiene la apariencia de un círculo vacío si no está marcado. Cuando lo está, este círculo contiene un círculo relleno más pequeño. Los botones de opción se encuentran a la izquierda de la opción que representan.

Con diferentes variantes, en todos los casos se advierte que la verificación implica visualmente el relleno de alguna figura. Da lugar a pensar que podrían indicarse estos estados como con relleno y sin relleno, pero en programas de cierta naturaleza visual como pueden ser los ocupados a la hora de crear presentaciones se prevé la noción de relleno para aplicar a las formas; ¿qué pensaría un usuario no experimentado, independientemente de lo gramaticalmente correcto que resultarían casilla de verificación sin relleno y botón de opción sin relleno, si en PowerPoint oye al lector decir Sin relleno botón de opción con relleno? Desgraciadamente llevaría a confusión, ergo la propuesta queda descartada.
Algo similar ocurriría si nos decantáramos por con marca y sin marca. Aparte de que ya un programa del popular Microsoft Office como es Outlook ya se vale del término marca como significante del signo asignable a elementos como tareas o mensajes de correo electrónico para destacarlos, seguirlos o hasta filtrarlos, de decidir esta alternativa confundiríamos a quienes se avoquen a la creación de contenidos protegibles con marcas de agua.
Con verificación y sin verificación no acarrearían ningún problema de ambigüedad ni gramatical pero, aunque tengo curiosidad por sus opiniones al respecto, personalmente creo que en boca de los sintetizadores de voz suena un tanto forzado.
Tal como en ocasiones se ha visto que nombran quienes han localizado estas descripciones en JAWS, podría llamarse a las casillas de verificación cuadros. Entendido en el contexto informático tal nombre solucionaría los problemas de índole lingüística que surgen en español al respecto, pero hoy día la traducción casilla de verificación está más que arraigada en ayudas y manuales.

¿Y entonces?

En vista de no existir alternativa perfecta, habrá que conformarse con «la más mejor». Las indicaciones visuales hacen los conceptos de programación transparentes al usuario, pero lo cierto es que si tomamos a botones, casillas y demás como tipos de controles y la situación en que se encuentren (verificados/marcados, abiertos etc.) como estados de los mismos, al final el género masculino no es tan improcedente. Aunque no sea común a todos los lectores de pantalla ni menester de esta entrada exponer el procedimiento para hacerlo en cuanto se halla documentado, JAWS permite a través de sus esquemas de voces y sonidos definir sonidos de reemplazo para distintos estados y tipos de controles, lo que aparte de la mayor velocidad de navegación supone, para los controles discutidos, eliminar toda posible incorrección gramatical o ambivalencia.

El caradurismo del amplio uso de las comillas inglesas

En español, como muchos ya sabrán, se utilizan esencialmente tres tipos de comillas diferentes: las «angulares/latinas/francesas/españolas», las “inglesas/curvas” y las "rectas" que son más propias de máquinas de escribir. El Diccionario también nombra las ‘comillas simples’.
En el Diccionario Panhispánico de Dudas, la RAE comenta que, para textos impresos, en primera instancia se recomienda utilizar las angulares. ¿Qué nos dice al respecto la Guía de estilo de Microsoft para español? Echémosle un vistazo.

However, with the widespread use of English texts and translations, that generally use the English soft text as the basis for the new translated text, curly quotes (“”) are seen in Spanish printed material. In Microsoft Spanish documentation, curly or smart quotes will be used in normal text.

Lisa y llanamente me parece un disparate, y aparte de que aun en traducciones veo en los libros las comillas angulares con más frecuencia de lo que implícitamente se sugiere en esta guía, procedo a explicar por qué:
Ya que hablan de widespread use, abordemos ese supuesto uso extendido primero. Que lo afirmen ellos es un tanto caradura, pues sin duda es una costumbre que potenció (si no generó) el reemplazo predeterminado que desde tiempos inmemoriales realiza Word en nuestro idioma, producto esta vez no de un tema programático sino de desatención del primer equipo que preparara las herramientas de corrección en español, en cuanto al trabajar en otros idiomas como alemán, francés o griego sí se emplean las comillas adecuadas. Cual si fuera poco, ¿por qué se ha terminado por recomendar que el juego de caracteres ISO8859-1 se parsee como si en realidad fuese Windows-1252?

Detengámonos ahora en qué tan (im)posible es en el caso del software emplear las comillas angulares. Es una perogrullada, pero todas las variantes de Unicode tienen por supuesto estos caracteres; los estándares ISO8859-1, ISO8859-15 y Windows-1252 también. A no ser que se desee proporcionar compatibilidad hacia atrás con componentes que sólo admiten un conjunto Ascii limitado de 7 bits (léase sin caracteres internacionales), el único problema real que quedaría es el de las fuentes: Por supuesto que habrá algunas que carezcan de las comillas angulares, pero es tan factible como encontrarse con las que no tienen letras acentuadas, la ñ y caracteres como los signos de interrogación y admiración de apertura, sin que por ello se haya optado en ninguna traducción de software seria desde los 90 para acá (algunos recordarán casos de otrora como los juegos para Spectrum) por omitir los acentos y cambiar la ñ por ni. En todo caso, la mayoría de sistemas operativos actuales son capaces de buscar una fuente compatible con lo que haya que mostrar.

Las raíces de esta problemática de la mano de Microsoft a la que aludí tiene más de 20 años. A sabiendas de no ser sino una expresión de deseo, espero que a la Real Academia se le dé, en algún momento y aprovechando que tiene ciertos acuerdos con esta empresa, debatir el tópico con Microsoft. Roguemos que ocurra antes de que, como para el caso de solidaridad que magistralmente ha explicado Valentín García Yebra, sea demasiado tarde.

Mito de las mayúsculas no acentuadas en el Nokia E5

Todo hispanohablante, en algún momento de su vida, ha creído o escuchado mencionar que las letras en mayúscula van sin tilde, al punto de que actualmente no sorprende verlo. Tal afirmación tenía justificación en el siglo XIX y antes de fines del 20, en que las máquinas de escribir «imprimían» mediante martillos y al intentar acentuar letras mayúsculas, por la distribución de los mecanismos éstos se atascaban produciendo una grafía cuanto menos retorcida; hoy, que este problema no ataña a los soportes magnéticos y que la disponibilidad de fuentes y juegos de caracteres no supone un inconveniente, no es más que un mito del que hasta la propia Real Academia Española ha tenido a bien dar cuenta.

Con lo obsesivo que soy en lo que concierne a escribir correctamente, me gusta que este celular que tengo posea en su teclado QWERTY teclas específicas para el acento (que hasta para las diéresis se comporta igual que en el teclado de la PC), la ñ y hasta para abrir admiración o interrogación, todo ello sin acudir a ningún menú de símbolos. Empero, me desilusionó un comportamiento en línea con el mito que comento: Si la siguiente letra a escribir será en mayúscula, al pulsar la tecla del acento se imprime el carácter ´ y luego la letra en mayúscula normal (p. ej. ´E), debiendo si quiero acentuar correctamente una letra en mayúscula recurrir al botón CHR o el menú de símbolos cual si tales caracteres no estuvieran en el teclado. Considerando que la tecla está me resisto a creer que sea un problema de desarrollo sino más bien del equipo que implementó la escritura en español, pero por otro lado las opciones con letra acentuada inicial en este sentido están bien escritas, tal como se aprecia en estas capturas:

A todo esto, veo que nos hallamos en el preocupante panorama de que el mito sigue fomentándose desde sectores profesionales a través de implementaciones como esta, lo cual no ayuda a erradicarlo. ¿Vieron ustedes, leales lectores, casos similares en los teclados físicos o virtuales de algún celular, tableta, agenda electrónica o cualquier otro aparato afín del que hayan dispuesto? ¿Cómo lo resuelven? ¡Anímense a comentarlo!