Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Linux y la lengua japonesa

jorginius's Diary
Por jorginius
departamento nihongo wo benkyoushimasu , Sección Diarios
Puesto a las Mon Oct 6th, 2003 at 01:34:12 AM CET
Por motivos académicos, llevo un par de días investigando en qué estado se encuentra en Linux el soporte para la escritura japonesa, especialmente en las X y, en líneas generales, estoy muy gratamente sorprendido: por la sencillez de configuración y por su eficacia.

Si deseas saber más, sigue leyendo.

 


Nota: Parece ser que el scoop es un kbron de mucho cuidado y me ha chafado todos los bonitos caracteres japoneses. Como Murphy existe, no me he dado cuenta hasta darle al "Preview" después de escribir la entrada entera y me da pena tirar este tocho a la basura. Así que la posteo tal cual y en "Linux y la lengua japonesa" la tenéis tal y como debió aparecer en Libertonia.

... Y ya de paso ¡Campaña por una Libertonia en utf-8 ya! :-).

Ahora sí, la entrada:

Mi objetivo era tener un sistema bilingüe español-japonés, de tal forma que todas las aplicaciones tuvieran como lenguaje base el español pero qué, llegado el caso, pudiese escribir un correo o un documento en el mismo KMail o LyX, o mantener una conversación por el MS Messenger o Jabber con Kopete en japonés.

La primera piedra en el camino son las fuentes: la representación correcta de los caracteres japoneses en pantalla, junto a el resto de menús e información localizada en español.

La descripción del problema es la siguiente: si queremos que nuestro sistema siga "españolizado" no basta con que instalemos fuentes adicionales japonesas. Necesitamos que en una misma aplicación se representen el alfabeto occidental (con su "ñ", sus vocales acentuadas y demás) junto a los kanjis y los kana japoneses.

Una solución es usar fuentes que engloben los dos juegos de signos (y muchos más). Por ejemplo la "Arial MS Unicode" (24 MB de fuente truetype) aunque, por desgracia, esta fuente ya no está disponible para su descarga en la web de Microsoft (si bien se puede encontrar aún en otros servidores ftp de la red, o en el cd del MS Office 2000).

La otra solución, la solución "moderna", es confiar en la potencia de Pango y de Qt. Ambos permiten mezclar distintas fuentes en la misma ventana, de manera que no te obligan a cargar una fuente de 24 MB como la anterior y además te permiten seguir con tus bonitas fuentes y no sufrir la espartana Arial por todo el escritorio. El resultado práctico es que tanto Gnome 2.0 como KDE no tienen ningún problema para representar caracteres japoneses mientras el resto del interfaz continua localizado a nuestro gusto. El resto de aplicaciones, sean Xlib, Gtk1.x o Motif no tienen tanta suerte.

Evidentemente, para que el sistema mezcle las fuentes, la codificación de entrada que definamos es importante, pero aquí de nuevo uno puede ponerse en manos de los adelantos de la técnica y no preocuparse de nada más :-): KDE usa en la mayoría de las distribuciones utf-8 como codificación predeterminada, así que este problema está resuelto de antemano. RedHat configura todo el sistema por defecto en utf-8 y en Mandrake, con su localedrake, no pone pegas. Podéis comprobar ahora si vuestro sistema representa correctamente el japonés visitando la página de nuestros tocayos LILO (Linux Install Learning Osaka).

Ahora llegamos al quid de la cuestión: ¿cómo leches escribo japonés con este teclado? :-) y la respuesta es: "casi igual que como lo haría un japones". La orientación del texto no es problema porque, aunque tradicionalmente el japonés de arriba a abajo y de derecha a izquierda, no hay mayor problema en escribirlo de izquierda a derecha y de arriba a abajo (como el español, vamos) y, por otro lado, para escribir los kana y los kanji en un ordenador con un interfaz de entrada universal (el teclado) habitualmente occidental (Estadounidense), los japoneses recurren a un pequeño ayudante: el IME o "Input Method Editor". MS Windows tiene dos versiones de su "Global IME": una para el MS Office XP y otra el MS Outlook y MS Internet Explorer, disponibles para su descarga en la Sección Global IME de la web de MS IExplorer.

Las X, que son lo que nos interesa, tienen desde antaño infraestructura para "enchufar" nuevos métodos de entrada: el XIM (que está apunto de ser reemplazado por el superior IIIMF que permite, entre otras cosas, seleccionar el método de entrada "en caliente"). De hecho, este protocolo ha servido de "inspiración" a Microsoft en el desarrollo de su soporte para IME.

El IME clásico de las X es kinput2 que, a través de XIM, permite que escribamos en japonés en todas las aplicaciones (bueno, casi todas: por desgracia el LyX no, pero hay un CJK-LyX paralelo y ahora que se basa en Qt es de esperar que lo soporte de serie en breve), de forma transparente: sin tener que modificar una línea de código o una línea de configuración en las mismas. Para usarlo necesitaremos un servidor XIM apropiado, como Canna o FreeWnn, que hagan la conversión romaji a kana y kana a kanji. El servidor Canna incluye soporte, además de para kinput2, para otras aplicaciones que lo usan directamente como Vim o Emacs (Mule).

Kinput2 es una aplicación Xlib y, como tal, se configura completamente desde un farragoso archivo de recursos (p.ej /etc/X11/app-defaults/Kinput2). Es interesante que incluyáis en ese archivo, en los locales "permitidos" para kinput2, vuestro local habitual, de manera que podáis usarlo sin tener que fijar el LANG y el LC_ALL a algo como ja_JP. Después, para utilizarlo debéis seguir estos pasos:

  1. Aseguraos de que tenéis el servidor XIM corriendo
  2. Arrancad el kinput2 (se puede hacer en el Xclients o en cualquier momento). Por ejemplo, si usais el servidor Canna:
    $ kinput2 -canna &
  3. Fijad la variable de entorno XMODIFIERS adecuadamente. Por ejemplo con:
    $ export XMODIFIERS="@im=kinput2"
  4. Arrancad la aplicación en la que queráis trabajar en japonés.

Otra forma de hacerlo es con un pequeño script lanzador de aplicaciones en japonés. Si vais a usar sólo muy de vez en cuando el soporte de japonés, podéis escribir este script "japo":

#!/bin/sh
XMODIFIERS="@im=kinput2" LANG=ja_JP LC_ALL=ja_JP ${1+"$@"}

Y luego arrancar la aplicación que queramos con: "japo editor &", por ejemplo.

Sea como sea, una vez dentro de la aplicación el uso de kinput2 es muy sencillo. Para empezar, se activa y se desactiva con Shift-Espacio o C-Kanji si tienes un teclado japonés de 106 teclas (siendo este atajo configurable en el archivo de recursos). Se indica que nos encontramos modo de entrada japones por una pequeña ventana emergente que contiene una "a" (la vocal "a" en hiragana: "?"), que aparece ligeramente por debajo del cursor. A partir de ahí, podemos escribir el japonés en romaji y veremos como nuestras pulsaciones se traducen en los símbolos del silabario hiragana. Si en algún momento queremos transcribir esa palabra en katakana o con su kanji podemos o bien pulsar Control-n, que selecciona directamente la siguiente transcripción posible con esa fonética, sin los kanji (katakana y romaji) o pulsar Espacio y se nos muestra en otra ventana modal todas las posibles transcripciones, incluyendo los kanji. Para validar una transcripción simplemente la seleccionamos con los cursores y pulsamos Enter.

Una relación completa de los atajos de kinput2 la podéis consultar en esta guía de kinput2 en la web de Mozilla.

Mencionar que hay otras propuestas para los métodos de entrada en Linux. Gtk-2 tiene su propia infraestructura (independiente de las X) y el im-ja es un IME compatible con ella. Incluye incorporada además una versión adaptada del kanjipad (un widget de reconocimiento de escritura de kanji muy efectivo, por la disciplina que exige la escritura de kanji. Recordemos que los programas de reconocimiento de escritura manual no reconcen el símbolo completo sino que se guian del orden de dibujado de los trazos). Las ventajas de usarlo son que es independiente de las X (funciona igual en DirectFB o en Windows, por decir algo) y el aspecto visual es mejor. La desventaja es que sólo funciona con las aplicaciones Gtk 2. También hay una versión experimental de un servidor de entrada IIIMF: el iiimf-skk. En ambos casos, la mécanica de cara al usuario, a la hora de escribir, es casi la misma que con kinput2.

A lo mejor te estás preguntando si este sistema de entrada tan complicado, con tantos atajos, funciona. Pues sí, funciona y es ágil. Te permite escribir japonés bastante deprisa... O al menos, más rápido de lo que tarda en pensar en japonés un ?? (gaijin :-)).

Para poner algún ejemplo, esta noticia la estoy escribiendo en Konqueror y esta sería la transcripción del departamento usando escritura japonesa y kinput2, con muy poquitas pulsaciones:

???????????

También se pueden escribir otras verdades fundamentales (para los usuarios de Linux de la túnica naranja). Esa frase mezcla katakana, kanji e hiragana:

??????????

Si no visualizas correctamente los ejemplos, puede que no tengas instaladas las fuentes o puede que vuestro navegador no entienda utf-8 (espero que scoop sí lo soporte. Nota a posteriori: pues no, este pequeño bastardo no lo soporta, ...). En ese caso, forzad la codificación de la página (en Konqueror se hace desde el menú "Ver", ignoro en otros navegadores cómo).

Para completar, haré una referencia rápida a algunas aplicaciones que merecen la pena si estamos haciendo nuestros pinitos en esto del japonés.

  • Kiten: un decente diccionario Japonés-Inglés, Inglés-Japonés para KDE, con búsqueda de kanjis por grado, radicales y número de trazos, que "desconjuga" los verbos y adjetivos y que permite personalizar tests de kanji para su estudio.
  • Kanatest: un sencillísima aplicación para aprender los silabarios hiragana y katakana. Se muestran los símbolos y tienes que transcribirlos en romaji. Guarda nuestras estadísitcas y las horas que le hemos dedicado.
  • JWPce: ésta es una aplicación para Windows, pero la incluyo porque es soft libre y porque usa exclusivamente el api Win32, así que compilarla contra Wine es sencillo. Se trata de un editor de texto en japonés con funciones de diccionario y otras ayudas.
  • Aunque no sea una aplicación, es un enlace interesante: Linux-nihongo HOWTO. El Howto de Linux en japonés (afortunadamente en inglés :-)).
  • Etc. Echad un vistazo en freshmeat, vagos :-)

Fdo. ??? ;-)

< Jornada sobre Dependencia Tecnológica organizada por la Cámara de Comercio de Gipuzkoa (3 comments) | Sistema de fax con herramientas libres (13 comments) >
Enlaces Relacionados
· Scoop
· Freshmeat
· "Linux y la lengua japonesa"
· KMail
· LyX
· otros servidores ftp de la red
· LILO (Linux Install Learning Osaka)
· Sección Global IME de la web de MS IExplorer
· CJK-LyX
· Canna
· FreeWnn
· guía de kinput2 en la web de Mozilla
· im-ja
· iiimf-skk
· Kiten
· Kanatest
· JWPce
· Linux-nihongo HOWTO
· freshmeat
· More on jorginius's Diary
· Also by jorginius

Encuesta
Estudiar japones es...
· ¡Guay! puedo leer todo el manga que no editan por aquí 37%
· Útil en mi trabajo. Estoy echando curriculums en Japón 22%
· Una estupidez. Yo me centro en la única lengua del futuro: el klingon 17%
· ¿Para qué?: no hay rubias en japón 22%

Votos: 40
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Linux y la lengua japonesa | 6 comentarios (6 temáticos, editoriales, 0 ocultos)
utf-8, navegadore y otras hierbas (4.00 / 1) (#1)
por ridiculum a las Mon Oct 6th, 2003 at 02:25:14 AM CET
(Información Usuario)

Algunas notas sobre el soporte utf-8 de algunas apliacaciones (jorginius, creo que ya las conoces, las sufrimos en su momento cuando estuvimos montando el bloxsom.)

Konqueror, que yo recuerde era bastante habil en este asunto del charset y me suena que si veia charset=utf-8, sabia lo que habia que hacer y pintaba bien la página. Recuerdo vagamente una opcion que te permitia decirle que seleccionara el charset de forma automatica asi que la cosa estaba bastante bien resuelta.

Galeon (1 y 2) era otra historia. Si veia charset=iso-8859-15 o similares, de puta madre, lo pinta sin problemas.
Incluso pinta bien la página en japones que apunta jorginius, que tiene esto: charset=iso-2022-jp, sino tener que configurar nada en especial.
Pero hay amigo si la web es uft-8. Por algun motivo oculto, pasa del tema y no lo muestra bien.

Si buscamos en el menu ver->codificacion encontramos la opcion de utf-8. La seleccionamos, et voilá, todo bien.

En Editar->preferencias->idioma podemos elegir el charset predeterminado y tambien aparece una opcion que pone "autodeteccion" pero no es un "checkbox" como podiamos esperar. Es un menu deplegable con las opciones de chino, ucraniano, coreano, japones y ruso.La verdad es que no se muy bien que elegir :))

Mozilla se comporta exactamente igual que galeon y presenta los mismos menus.

Me da a mi que esto del utf-8 aun no ha calado.



Anda la pera (none / 0) (#2)
por man ls a las Mon Oct 6th, 2003 at 08:42:59 AM CET
(Información Usuario)

Con razón, yo dale que te pego en el curro metiendo UTF-8s por todos los lados (en la declaración de xml y en el tag meta), y Mozilla pasando de mí. Pensaba que era error mío, ¡he perdido la capacidad de desconfiar de él!

Nota informativa: Hasefroch Exploder hace exactamente lo mismo, ignora la codificación UTF-8.

[ Padre ]


Parece ser que Apache tb tiene algo que ver... (none / 0) (#3)
por jorginius ("jorginius" en Google Mail) a las Mon Oct 6th, 2003 at 08:51:27 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Lo seguiré mirando después, pero parece que Apache se empeña en decir, en la config por defecto, que de utf-8 nada de nada. Probad con este enlace, a ver si lo coge bien el utf-8 sin forzarlo.

[ Padre ]


Lo hace... (none / 0) (#4)
por ridiculum a las Mon Oct 6th, 2003 at 02:57:35 PM CET
(Información Usuario)

bien.

Galeon 1.3.9 y Mozilla 1.4.

Intuyo que el Firebird y demas tambien se comportaran del modo correcto.

[ Padre ]


Sí, ahora sí sale (none / 0) (#5)
por man ls a las Mon Oct 6th, 2003 at 06:51:25 PM CET
(Información Usuario)

Entonces de qué va esto, ¿es que el header Content-Type está por encima de la declaración del documento? Ya decía yo que no había que desconfiar de Mozilla...

[ Padre ]


Creo que ya sabemos por qué es (5.00 / 1) (#6)
por jorginius ("jorginius" en Google Mail) a las Mon Oct 6th, 2003 at 08:17:48 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Por lo visto nuestro Apache estaba empeñado en decir que estaba sirviendo:

Content-Type: text/html; charset=iso-8859-1


A pesar de que el html estaba escrito en utf-8.

Lo curioso del tema (y lo que nos despistó por completo) es que en Konqueror el texto se representaba correctamente (como utf-8) y en Mozilla y MS IExplorer los caracteres por encima de los 7 bits salían bailados (intentan visualizarlo como iso-8859-1). ¿Por qué ocurre esto?. Bueno, pues parece ser que Konqueror tiene en cuenta la codificación de la página, la que se indica en el html, aún cuando el servidor se la ha dicho de antemano, mientras que Mozilla y MS IExplorer se fían de lo que dice el servidor y sólo la leen del html si aquel no les dice nada. Si ni el servidor ni la página fijan el código de caracteres, entonces los tres tiran de su configuración por defecto

¿Por qué el servidor decía siempre que "charset=iso-8859-1"?. Porque la opción "AddCharsetDefault" está puesta a "on" (coge iso-8859-1 si no se especifica otra) en el archivo de configuración del paquete de apache-ssl que estamos usando (el paquete de Debian Woody). Si lo tienes activo, ese "CharsetDefault" se usa siempre (se ignora la codificación real de las páginas), excepto en los archivos con la terminación que definas con el mod_mime. Por ejemplo, en el segundo ejemplo, hice un enlace de "linuxjap.html" a "linuxjap.html.utf8" y escribí en la sección de "mod_mime" del httpd.conf:

AddCharset UTF-8 .utf8


Con eso, todos los archivos *.utf8, apache los servirá como "Content-type: */*; charset=utf-8"

Si te fijas, en la página japonesa que puse de ejemplo LILO (Linux Install Learning Osaka) (no confundir con nosotros: LILO :-)) usan algo parecido: su "index.html" es "index.html.ja", imagino que porque tienen definido en su httpd.conf que todo lo que termine en *.ja debe usar codificación japonesa.

Y todo esto para llegar a la solución final por la que hemos optado: poner el "AddCharsetDefault" a "off".

AddChasetDefault off


De manera que Apache ya no dice nada del charset en sus respuestas (bueno, según que virtualhost sí que dice algo o no, pero esa es otra historia) y todos los navegadores tienen que sacar la codificación (buena) de la página.

¿Por qué está puesto por defecto eso a "on"?. Pues imagino que para que las páginas mal escritas que no especifican su charset. Como ya dije, mi Konqueror usa utf-8 por defecto y ridiculum me confirma que su Galeon también. Si el servidor no dice nada y en la página tampoco se especifica, esos navegadores sobreentienden que se trata de utf-8. Por ejemplo, al desactivarlo nosotros hemos tenido problemas con AWStats: la plantilla de traducción al español de las páginas que genera no dice nada del charset (que es iso-8859-1) y, si el servidor tampoco dice nada, en un navegador con utf-8 por defecto u otra se ve de pena.

Sospecho que esta configuración, de charset por defecto distinto del charset de las páginas, es muy "popular" (que la traiga el paquete de Debian de Apache "de serie" ayuda). Navego con Konqueror precisamente porque veo a menudo páginas en las que "se ven mal" los caracteres con Mozilla (una codificación que no es la apropiada). La causa podría ser ésta, que el servidor "miente" sobre la codificación.

[ Padre ]


 
Linux y la lengua japonesa | 6 comentarios (6 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda