El mundo debía ser Unicode
La mayoría de software está desarrollado por estadounidenses o al menos angloparlantes (cada menos, pero no se nota demasiado), y como ellos se creen el ombligo del mundo y creen que son únicos olvidan frecuentemente cuando programan dos aspectos muy importantes como localización e internacionalización (vistas por ahí como l10n e i18n, tanto las desprecian que sólo les interesa el número de letras de en medio).
Las personas que trabajan en el Proyecto Nave lo saben muy bien. Los desarrolladores del navegador Firefox no diseñaron el navegador con idea a traducirlo (son canadienses y estadounidenses, ¿para qué iban a preocuparse?) y sacar cada versión de Firefox traducida a la lengua de Cervantes (o a otra lengua) es una pequeña odisea. Es muy extraño porque el “hermano mayor”, Mozilla Suite, está perfectamente preparado.
Personalmente la mayoría de veces que programo sigo la misma vía que los desarrolladores estadounidenses: programo el código fuente en inglés para que todo el mundo lo entienda (a veces los comentarios van en castellano) y la interfaz del programa en inglés (a veces no, depende de a quien piense dárselo), pero a diferencia de ellos siempre tengo en mente las posibilidades de modificar la interfaz del programa a diferentes idiomas… casi nunca lo he hecho.
De todas formas siempre que escribo código fuente (o un simple archivo de texto, o una página web, o…) lo guardo desde hace tiempo en Unicode para que cualquiera que lo vea a lo largo y ancho del mundo y tenga un editor que soporte Unicode pueda ver nuestra querida eñe, nuestros acentos y nuestras cedillas, y también para que si un francés o un alemán deciden escribir en su idioma en ese archivo con sus símbolos diacríticos sin problemas. Pero no sólo franceses y alemanes (eso se podía hacer con codificaciones como el Windows CP1250 o el ISO-8859-1) sino también caracteres griegos (αβγδ), braille (â Žâ ?â ?â ¯), japonés (五肆í??킱킚) o coreano (턿턼턶텎) (se está considerando la inclusión de los símbolos élficos de escritura, sin embargo los símbolos klingon fueron desestimados). Una ventaja evidente ¿no?
La mayoría de sistemas operativos modernos son compatibles con Unicode (sí, incluso Windows, por dentro guarda las cosas codificadas en UTF-16) pero las aplicaciones y programas no tan modernos dejan bastante que desear respecto a su soporte internacional, normalmente soportarán el ASCII o quizás algún modo de codificación de 8 bits si eres afortunado (la mayoría de aplicaciones caen “por defecto” en este grupo). El sistema operativo que peor soporta el Unicode y la internacionalización (a mi parecer) es Unix y sus derivados.
Los terminales y consolas de Unix siempre han sido el “fuerte” de esos sistemas pero su soporte para caracteres por encima de los 7 bits deja bastante que desear. Principalmente esta falta de soporte se debe a que se basan en sistemas muy antiguos en los que almacenar un byte de más significaba gastar más dólares. Y programados además en C. C (junto con su primo feo C++) no soportan las cadenas como tipo básico del lenguaje y cuando soportan operaciones “sobre cadenas” reza para que soporte codificaciones de más de 7 bits (ahora casi siempre, pero hace unos años era raro el compilador que te dejase compilar con acentos en el código fuente, Python sigue protestando si no le indicas la codificación que quieres utilizar, por ejemplo). Desde la especificación del ANSI C se soporta un tipo wchar_t destinado a almacenar caracteres multibyte pero nadie lo utiliza y es dependiente de la implementación (el antiguo tipo char es, según el mismo estándar, de 8 bits, lo que permite utilizar superconjuntos del ASCII). Pero parece que nadie hace caso a los intentos de globalización del lenguaje (son tipos chapados a la antigua).
¿A que viene esta protesta? El Terminal (o el iTerm) de Mac OS X no me deja teclear acentos y aunque está puesto por defecto para interpretar UTF-8 la salida del ls es basura cuando hay ficheros con acentos en el nombre, el autocompletado transforma los acentos escapándolos, y el cat muestra el contenido de los archivos UTF-8 perfectamente (pero no el less o el more). Todo el sistema en UTF-8 (incluso el sistema de archivos y metadatos) y el shell del terminal no soporta UTF-8 correctamente… desesperante (el widget WordpressDash tampoco soporta Unicode… asco, pero creo que se puede cambiar).
Nota: Esta página funciona en UTF-8 por lo que puedo poner acentos y demás caracteres sin problemas, por eso también algunos de los artículos antiguos (guardados en ISO-8859-1) no se ven correctamente, aunque los arreglo si los veo ;).
