-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-03-21 a las 00:55 +0100, Roberto Antolin escribió:
El Miércoles, 21 de Marzo de 2007 00:13, Carlos E. R. escribió:
El truco es lo de "_()", que no se si es una macro o una función de c, pero lo que hace es devolver ese mismo string en el idioma local del usuario, con la particularidad de que se puede traducir y añadir idiomas sin mayor colaboración de los desarrolladores que el haber puesto incialmente los "_()" y linkado la librería.
Creo recordar que es una macro. Y por cierto, lo de la "colaboración" por parte de los desarrolladores poniendo dicha macro es un eufemismo. A mi, como desarrollador de grass me "obligan" a ponerlo. Claro que después como traductor lo agradezco :P
ji, ji O:-) Y estás en ambos bandos :-)
Lo que sucede es que si un programa o librería, al arrancarse, la parte de inicialización de gettext mira si existe el .mo correspondiente, y en caso afirmativo interceptará todos los strings originales cambiandolos al vuelo por su equivalente traducido.
¿capishi?
Non più di tanto, ma funziona ;)
Mi italiano no llega a tanto...
Bueno, pues yo no capsihi, no del todo. Es una especie de chapuza, que se aplica a posteriori de haber desarrollado una aplicación con cambios mínimos. Ahora ya se aplica a priori, durante el desarrollo, porque es conveniente, pero el origen es una alteración del programa por no haber pensado desde el principio como soportar varios idiomas. A estas alturas, se ha convertido en el sistema de elección de todos los programas en linux. Tiene sus ventajas...
No es tan mal método creo yo. De todas maneras qué es lo que entiendes por "a posteriori" y por "a priori"
Verás. Cuando se empieza un programa, no piensas en internacionalizarlo: lo haces en tu idioma. Pero llega un momento en que el linux se hace popular, y hay que traducirlo... Hay varias maneras de hacer que los mensajes salgan en varios idiomas. Una es tener un array de dos dimensiones: una el idioma, otra el mensaje. Con cambiar el indice de idioma, cambias de idioma al vuelo. Pero para cambiar un programa ya hecho tienes que ir moviendo todos los mensajes uno a uno de donde están a otro sitio para definir el array, y eso es bastante pesado. Para añadir un nuevo idioma hay que recompilar, y los tiene que añadir el desarrollador. Otra variación es usar no constantes o variables, sino funciones: se llama a una función con un número, y devuelve un string adecuado. La función ya se las arreglará, pero puede cargar los mensajes de diversos ficheros externos según los varios idiomas. Es más fácil para los traductores, pero el paso inicial de crear los mensajes aparte es igualmente pesado para los desarrolladores. Es decir, partes de: printf("Hello World.\n"); y lo tienes que cambiar por algo como esto en dos ficheros: #define MSG_1 "Hello World.\n" y: printf(MSG_1); o con funciones: #define MSG_Hello 1 y printf(_(MSG_Hello)); Más la función _() que no he definido. En cualquier caso, tienes que ir cortando y copiando los textos de un fichero a otro, que es pesado, y los programadores no querrán - salvo que se haya hecho el programa así desde el principio. La solución gettext es sencilla de aplicar por el programador, porque se cambia: printf("Hello World.\n"); en printf(_("Hello World.\n")); que es muy fácil de cambiar. El truco es que el índice ya no es un número, ¡sino el propio string! Es más pesado computacionalmente, pero se puede aplicar bien en un programa ya terminado. De ahí lo de "a posteriori". En windows hay, o había (en 3.11 estaba) un sistema que llamaban "de recursos". Era (o es, no se si se sigue usando) un anexo pegado al final del ejecutable con diversos datos: strings, menus, dialogos, datos en crudo... El programa los referencia mediante un indice numérico y los carga. Hay cosas muy majas, como poder definir una caja de diálogo en un editor gráfico, o cambiarla después de entregado el programa. Pero no se prestaba muy bien a la internacionalización en gran escala, por no tener doble indice (idioma, recurso). Se tendía a publicar distintos programas para cada idioma: el traductor podía ver la caja de diálogo o el menú resultante sin ejecutar el programa. Luego el desarrollador compilaba pegando distintos recursos según el idioma pagado. No se como lo hacen ahora mismo.
Bueno, pues kbabel es un programa especializado en facilitar la traducción del .po ese. Incluso hace una traducción automática con lógica borrosa, pero es demasiado borrosa para mi gusto.
Tienes toda la razón. La lógica borrosa dichosa deja algo que desear X-P
¡Algo! Caray... lástima de no haber guardado las barbaridades que me traduce.
Como no, la otra posibilidad es... ¡el emacs! Me he enterado hoy.
Hay otro programa que permite hacerlo: poEdit ;)
Se me olvidó ese. Lo probé hace un año. Y el gtranslator de gnome, pero lleva parado dos años, creo.
Sí... bueno, los programas no, hay que hacerlo con los .po por narices; si hay facilidades como cvs y listas y webs de apoyo, pues mejor.
Nosotros tenemos el glosario en el wiki (que cambiamos cada dos por tres :S) y después nos solemos comunicar por listas de correo.
No está mal. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGAIlhtTMYHG2NR9URAh28AJ9XrDcTi0ZQPiBeprsTjx1Xqvk5AACfQJNc 9Lu3W8mZfYRFrc5Ez+eDh+8= =YQG4 -----END PGP SIGNATURE-----