El vie, 26-09-2003 a las 02:32, Christian Rose escribió: > For all intents and purposes, PO format is what we already use, and > using PO format also for the docs translations would allow us to > seemelessly integrate it into our existing translation infrastructure > and translation process. PO has been demostrated its ability with programs, but for further solutions we should better know how the profesional translation world works. There are a lot of issues that we, as amateur translators becoming more profesional each day, maybe unknown. Thats the reason some people we are trying to get that info, part of them in Spanish and other in English. I add to this message a very interesting article. It's in Spanish, so I wish you could understand something. Another point of information (most of the links are in English) https://bugzilla.hispalinux.es/show_bug.cgi?id=44 and a extremely interesting article about translation and the XLIFF format you'd probably enjoy: http://developers.sun.com/dev/gadc/technicalpublications/articles/xliff.html > Works fine with the Red Hat Anaconda (the RH installer) online help. You > can have a look at it in action at > http://www.menthos.com/po/redhat/anaconda-online-help-gui/ . They use > some perl script to do this though. You didn't lost any text with xml2pot? Some of my test seems to do that :-? > In GNOME we have "doc-i18n-tool", which is an XML-aware C application, > in the "intltool" CVS module. It hasn't gotten any serious testing > though, probably because it seems it doesn't get built with and > distributed with intltool. doc-i18n-tool is useful now? For months I didn't hear nothing about it. -- A.Ismael Olea González mailto:ismael olea org http://www.olea.org http://aduaneros.olea.org, la ONG sin futuro. El mundo debe empezar a tener miedo a un planeta OLEATitle: Un paso adelante
Un paso adelantePlan de tecnologías lingüísticas libresCopyright © 2003 por Juan Rafael Fernández García
IntroducciónLa temática de este documento es lo que en la jerga de la industria se llama «localización» o incluso «globalización», directamente relacionadas con la traducción y sus herramientas. Me he esforzado en atenerme a desarrollos posibles a corto y medio plazo, pero continuamente me ha asaltado la tentación de entrar en el tema de la traducción automática. Queremos, a corto plazo, que las máquinas nos ayuden a traducir; a medio plazo el objetivo es que traduzcan por nosotros. Lo que pasa es que los dos objetivos convergen en dotar de inteligencia a las máquinas. Pienso que cualquier asistente a la traducción necesita reglas: morfológicas, sintácticas, semánticas, necesita una gramática y un «conocimiento del mundo». ¿Cómo traduciría un programa sin inteligencia oraciones como ‘spirits sold here’? ¿cómo puede un humilde corrector ortográfico distinguir ‘e implementado’ de ‘he implementado’? Es la hora de que el software libre llegue a la madurez. Eso implica también que conozcamos las tendencias de la industria y adoptemos y trabajemos con los estándares. Este documento trata de señalar el camino para el desarrollo de nuestras herramientas de CAT, con el ojo puesto en el desarrollo futuro de herramientas de traducción más o menos automática. Ahora hay que ponerse técnicos y me temo que la lectura no va a ser fácil; no soy un experto y escribo mientras aprendo así que es probable que se encuentren inexactitudes que será conveniente corregir. De todos modos no pretendo más de plantear unas perspectivas y unas posibles líneas de desarrollo; está claro que LuCAS y TLDP son ejemplos de éxito como modelos de cooperación libre y que el actual proceso de creación de la editorial libre y la conversión de la documentación a DocBook XML son grandes ideas. Dice Ismael Olea, hablando del ciclo de desarrollo de TLDP,
Empezar a trabajar en la segunda opción no debe suponer merma de la primera. ¿Por qué?Pensando sobre el esquema de Ismael Olea ‘Arquitectura para reproducción y publicación’ del borrador de " LuCAS v4: creando el sistema de publicación de TLDP-ES " ( http://cvs.hispalinux.es/cgi-bin/cvsweb/doc-conf-creando-lucasv4/herramientas-reproduccion-publicacion.png ), creo que es el momento —intentaré explicar por qué— de integrar en el esquema las herramientas lingüísticas y dar el paso de adoptar los estándares y potencialidades de la ingeniería lingüística actual. Dependiendo de cómo nos planteemos la realidad de nuestro fondo documental, podemos pensar en él como en una gran biblioteca electrónica, como un repositorio digital (como el DSpace del MIT) o como un gran corpus lingüístico. Cada punto de vista plantea posibilidades distintas: en tanto que biblioteca, debemos escuchar las aportaciones de los bibliotecónomos. Debemos también acordar los metadata y el formato de registro de los documentos, para que las búsquedas sean cada vez más eficaces. Yo, como lingüista, propongo que lo miremos con un nuevo enfoque: somos un gran equipo de traductores y redactores de documentación. Una de nuestras prioridades debe ser mejorar nuestras herramientas de ayuda a la escritura. Disponemos de un fondo de varios cientos de megas de documentación técnica, en proceso de transcripción a DocBook XML, en su mayor parte traducciones de obras o documentación de tema informático que también son de licencia libre y disponemos además de las traducciones a multitud de idiomas. Ninguna empresa —¿quizás alguna universidad?— dispone de un fondo documental como el nuestro para la elaboración de terminologías específicas, para la confección de un corpus tan completo de la materia ni para la creación de memorias de traducción. Ninguna empresa dispone del número de traductores de que dispone la comunidad GNU Linux. Y sin embargo las características de esta comunidad (en su mayor parte estudiantes y profesionales de la informática) hace que el modo de trabajar y las herramientas estén a años luz de las posibilidades que presenta la investigación actual. No se conocen las experiencias que se realizan en la Unión Europea ni las herramientas que se utilizan, ignoramos los proyectos universitarios y los intentos de estandarización que está realizando la industria. Y la distancia con respecto a la evolución del software propietario, lamentablemente, se amplía en lugar de acortarse. La comunidad, bajo el nombre de HispaLinux, o de TLDP o de FSF o del que sea, debe funcionar como una entidad y personarse y participar en los foros donde se están creando estándares (LISA, ISLE…) y en los proyectos financiados por la Unión Europea (debemos aspirar a recibir financiación de las instituciones y de las empresas). Es la hora de preguntarse si el modelo de voluntarios a tiempo parcial es eficaz para los objetivos que nos proponemos. La crisis: más allá de los ficheros .poNo podemos olvidar que gettext y .po resuelven algunos de los problemas con los que tiene que enfrentarse todo software de traducción: la extracción de las cadenas que deben ser traducidas, la segmentación y la referencia al lugar en el código al que pertenece la cadena, la alineación entre texto fuente y texto traducido, la capacidad de reutilizar traducciones cuando el fichero original ha cambiado, marcando las cadenas equivalentes y aquellas en las que la traducción es sólo aproximada (fuzzy) o no existe, y el informe automático del número de cadenas traducidas… Existen varios intentos de ampliar el uso de nuestras herramientas a textos libres (ficheros no .po, xml sobre todo), mediante el procedimiento de convertir de alguna manera los documentos a ficheros .po:
Segunda visita a KDELa segunda y más novedosa parte del «The KDE Translation HOWTO» es el capítulo titulado «Doc Translation». [1]
Los traductores del proyecto tienen la ayuda de las herramientas proporcionadas por el paquete poxml: fixsgml, xml2pot, split2po y por xmlizer y checkXML, de kdelibs3-bin. PropuestaLlevo tiempo preguntándome si estos tímidos intentos van bien encaminados. Mis objeciones son las siguientes:
Aunque a efectos del resultado sería indiferente el formato que utilizara internamente una utilidad de traducción, en nuestro análisis debemos considerar si el formato elegido es adecuado para nuestras necesidades (ya no la traducción de cadenas en tanto que mensajes de un programa informático, sino de documentación). Quizás el camino no esté en convertir los ficheros xml en ficheros .po para poder traducirlos, sino por el contrario mantener gettext y el proceso de extracción de mensajes, que funciona bien y es estable, convertirlos en ficheros xml bien formados, y aplicar herramientas generalizadas que puedan utilizarse sobre cualquier fichero xml. Lo que propondría sería una especie de .po con marcas, utilizable además para texto libre. Un proyecto paralelo: Okapi FrameworkEl proyecto del Marco de trabajo Okapi ( http://okapi.sourceforge.net/ ) tiene licencia modelo MIT.
Propone XLIFF 1.0 para la extracción de texto, TMX 1.3 para intercambiar TMs, TBX para el intercambio de terminologías y OLIF para el de lexicones (glosarios para sistemas de MT). Al granoEn las secciones que restan de este documento vamos a seguir el procedimiento de discutir brevemente las necesidades y herramientas libres conocidas y acabaremos por hacer una propuesta, bien de adopción de un estándar o desarrollo de una aplicación, bien de estudio previo a tomar una decisión. Son de varios géneros las utilidades de ayuda a la escritura y al traductor: diccionarios, concordancias, memorias de traducción, analizadores de todas clases. No hay espacio en este artículo para volver a hacer lo que como decíamos en el resumen inicial ya está hecho: subyace a todas las referencias la familiaridad tácita con las herramientas o con http://es.tldp.org/Articulos/0000otras/doc-traduccion-libre/ . Es el momento de una revisión detallada y de tomar decisiones. Propuesta: Líneas generalesEn TLDP se usarán estándares libres y abiertos: DocBook, TEI, XCES… y cuando se utilice uno propio se crearán mecanismos para la importación/conversión (recordemos por ejemplo la utilidad incorporada a Mimers brunn como conversor de .po a TMX). El formato de los documentos será preferentemente DocBook XML, porque permite la separación lógica entre los niveles semántico y de presentación y da pie a desarrollos relacionados con la web semántica, y las herramientas trabajarán sobre XML. La codificación UTF-8 es lógica en un proyecto con ambiciones de universalidad. Diccionarios desde el punto de vista lexicográficoEn primer lugar evitemos una confusión generalizada, de verba non est disputandum. Diccionarios son listas de palabras de un idioma, entradas léxicas con su definición, tablas de equivalencias entre dos o más lenguas y cualesquiera otras variaciones que se nos planteen; nomenclatura, glosario, lexicón, lemario etc. son términos que se usan de manera no estable en la literatura y no deben impedir que nos entendamos[3]. Mucho más interesante es plantearnos el campo de realidad cubierto por el diccionario y la información que proporciona (morfológica, de uso, terminológica…). Por último, distinguiremos diccionarios destinados a ser usados por humanos (en forma de libro o como consultas a través de una interfaz) de aquellos creados para ser usados por máquinas. También deberemos distinguir los que tienen una ambición descriptiva y verbal de los diccionarios terminológicos, que son como sabemos normativos y su objeto son los conceptos de un campo. Al fin y al cabo por lo pronto sólo queremos traducir documentación informática ¿o no? DiscusiónEstamos en LuCAS-desarrollo reimpulsando nuestro propio diccionario inglés-español de informática Giait[4] Por otro lado estamos intentando crear el mayor lemario del español[5]. Y periódicamente nos planteamos qué sentido tendría reclamar la liberación del diccionario de la RAE (probablemente muy escaso). Pero todos estos son pequeños pasos. Ponernos a escribir diccionarios nos convierte en lexicógrafos; pero escribir un diccionario técnico nos obliga a plantearnos los problemas de la terminología. Además, si logramos crear una estructura para la confección de terminologías (partiendo de nuestro corpus de informática pero no quedándonos ahí) podremos crear glosarios y diccionarios, presentar colocaciones y listas de ejemplos. Y hacer un uso normativo (estandarizado, coherente) de nuestra terminología. Estaremos por ejemplo en condiciones de definir como término informático el que aparece en nuestro fondo documental y no aparece recogido en nuestro diccionario general de español (por ahora inexistente). Pero vayamos poco a poco: un diccionario pensado para su impresión en papel o en pantalla, destinado a ser consultado por humanos, no es lo mismo que una base de datos terminológicos (un lexicón computacional), pensada para su utilización en la traducción automática. Sobre TEI P4La versión XML de las TEI P4 Guidelines[6], en su capítulo 13 ‘Terminological Databases’, advierte
Sí nos interesa el capítulo 12 ‘Print Dictionaries’.
Interesante parece estudiar como ejemplo de aplicación de TEI http://www.human.toyogakuen-u.ac.jp/~acmuller/articles/ddb-ebti2001.htm Sobre WordNetInformación en Princeton WordNet ( http://www.cogsci.princeton.edu/~wn/w3wn.html) ó man wndb WordNet es “an online lexical reference system whose design is inspired by current psycholinguistic theories of human lexical memory”. EuroWordNet ( http://www.illc.uva.nl/EuroWordNet/). EuroWordNet was a European resources and development project (LE-2 4003 & LE-4 8328) supported by the Human Language Technology sector of the Telematics Applications Programme, 1996-1999
Propuesta
Será necesario adaptar TEItools ( http://xtalk.msk.su/SGML/TEItools/index-en.html). Un caso prácticoLas dos primeras entradas de la letra «a» en las fuentes del diccionario Giait son
Convertidas a formato .dict (descomprimido) actualmente quedan así: A, Ampere, Amps Ampère (amperio), amperios. A Programming Language", APL Lenguaje de Programación APL Vemos que, aparte de errores tipográficos que habrá que corregir, se ha perdido la información de glosario y el marcado (lo que es inglés, castellano, comentario, glosario…) ¿Cómo aparece?
¿Cómo quedaría todo esto en TEI P4? Crearemos el fichero ejemplo.tei.xml (el siguiente fragmento de texto está en UTF-8)
¿Cómo convertir esta fuente en un documento distribuible? Utilizaremos lib-saxon-java, passivetex y las hojas de estilo XSL creadas por Sebastian Rahtz ( http://www.tei-c.org/Stylesheets/teixsl.html). Lo siguiente depende de la instalación de cada uno; yo utilizo en estos momentos una Debian Sarge. Passivetex es un paquete apt-gettable; descargo las DTD's TEI y las hojas de estilo y las instalo en /usr/local/share/sgml/tei/ La conversión a fichero .pdf me da errores; teóricamente se haría
Para generar el fichero ejemplo.resultado.html
Este es el fichero generado:
Correctores ortográficosTema relacionado con el de los diccionarios en tanto que listas de palabras. «Nuestro» proyecto es el COES: Herramientas para Procesamiento de Lenguaje Natural en Español ( http://www.datsi.fi.upm.es/~coes/), de Santiago Rodríguez & Jesús Carretero, que se distribuye como software de libre disposición desde finales de 1994. COES consta de un diccionario de unos 53.000 términos y un corrector ortográfico integrado en la utilidad Unix ispell y desarrollos derivados (aspell). Hay que señalar que se ha ampliado el conjunto de herramientas lingüísticas con un diccionario de sinónimos/antónimos. Su particularidad es ser sensible a las reglas morfológicas de las palabras y no sólo a las raíces. Un corrector ortográfico «inteligente» tiene que hacer algo más que comparar las palabras del texto con una lista de palabras correctas; para distinguir «a» de «ha» tiene que tener reglas — acabaremos necesitando un mínimo análisis morfológico y sintáctico. Terminologías y herramientas de gestión terminológica (TMS)DiscusiónLas ventajas que ofrece la utilización de terminologías son evidentes: uniformidad entre las traducciones, corrección y reusabilidad. Debemos también en el seno de TLDP clarificar los problemas ante los que se enfrenta toda terminología:
Terminología y Memorias de traducciónDiscutido en http://www.lisa.org/sigs/phpBB/viewtopic.php?topic=22&forum=1&4 Responde Kara Warburton:
PropuestaEl proceso que ha iniciado Javier Fernández Serrador de unificación de las terminologías de los distintos proyectos de traducción de interfaces de usuario (Gnome, KDE, es li, LuCAS) es fundamental. Propone la creación de una base de datos que incluya las traducciones consensuadas de los términos, y aquellas que se consideren incorrectas. Cuando las herramientas estén maduras para utilizarlas (pienso en los desarrollos deseables de gtranslator y kbabel) implementar bases de datos terminológicos en TBX. Correctores gramaticales y de estilo¿Tengo que explicar que un corrector gramatical necesita una gramática? Estudiar diction. Aplicarlo al español. Corpora monolingüesDiscusiónSegún Catherine Ball ( http://www.georgetown.edu/cball/corpora/):
Propuesta
Corpora paralelos y multilingüesDiscusiónEs evidente el interés de estas herramientas. Condiciones previas son
Melamed ha creado también gran número de utilidades libres. PropuestaSegmentación y alineado a nivel de párrafo están favorecidos por el marcado DocBook de nuestros documentos. El alineado a nivel de párrafo no es suficiente. Ver SRX, de Oscar/LISA. Nuestro problema es definir las Unidades de Traducción. Creación de memorias de traducción: «un corpus alineado y anotado constituye una memoria de traducción» (Abaitua, Tradumática 0, 2001). Memorias de traducciónDiscusiónLas TM contribuyen a la calidad de las traducciones en dos aspectos: su coherencia y su exactitud. Propuestagtranslator y kbabel utilizan de forma natural MT cuando trabajan con ficheros .po. Deben extenderse para utilizar MT cuando trabajen con documentación y textos libres. Para ello es necesario haber resuelto los problemas de la segmentación, alineación y marcado. Los proyectos deben trabajar (o al menos ser capaces de importar y exportar) el formato TMX. Notas
|