En la primera entrega de esta serie hemos hablado de la tecnología gettext; ahora es el momento de resumir sus ventajas pero también de señalar sus defectos. Qué triste sería el artículo si no pudiéramos hablar también de las soluciones, de las alternativas... Por Juan Rafael Fernández García.
Historial de versiones | ||
---|---|---|
Revisión 0.2 | 2007-03-01 | jrf |
Correcciones técnicas (css). | ||
Revisión 0.1 | 2007-01-01 | jrf |
Primera versión CC 2.0 del artículo de Linux Magazine. |
Está usted leyendo Los problemas de PO y el abrazo fuerte, segundo de una serie de cinco artículos sobre la traducción en el mundo del software libre publicado por primera vez en el número 20 de la revista Linux Magazine, de octubre de 2006 (pero escrito en agosto de 2006) con el nombre de «Trabajo en equi/PO». La versión pdf del artículo puede descargarse en el enlace http://www.linux-magazine.es/issue/20/.
La versión «canónica» del artículo, la única mantenida por el autor, se encuentra en http://people.ofset.org/jrfernandez/edu/n-c/traducc_2/index.html. Está publicada por contrato con la editorial bajo licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.0 (-sa-by-nc 2.0).
Índice de la segunda parte
I. Los problemas de PO
II. Conversores de documentación a PO
III. OmegaT
IV. Y en el próximo número...
Cuadro 1: Cómo se calculan las coincidencias difusas
Imágenes
Notas
Una oPOrtunidad de colaborar
(Primera parte del artículo)
Memorias compartidas
(Tercera parte del artículo)
¿El momento de cambiar de herramientas?
(Cuarta parte del artículo)
Cerrando el ciclo
(Quinta parte del artículo)
Referencias a los artículos sobre
traducción
¡Veinte artículos! Esta modesta sección de educación llega a su entrega número veinte, es el momento quizás de hacer un pequeño balance. Si desde el principio quisimos darle una orientación práctica, creo que ha primado el carácter exploratorio de los artículos: hemos presentado herramientas no muy conocidas por el público, o aspectos novedosos de las mismas. La única justificación está en la psicología del autor: quizás confunda la obligación de no aburrir con la de no aburrirse. Aun a riesgo de ser un tanto demasiado oscuro, o técnico, o conciso (tengo una justificación, las entregas tienen que caber en cuatro o cinco páginas).
Hemos querido cubrir un amplio espectro de destinatarios, con artículos con herramientas para Infantil (que alegan ser los grandes olvidados de la formación en TIC), especializadas para materias específicas, plataformas de colaboración, buscadores de recursos educativos, exploraciones del estado de la atención a la diversidad... artículos para un lector que se defiende informáticamente y busca orientación en el campo del uso pedagógico. No sé si ese destinatario existe o si está en construcción, como tampoco sé si hemos logrado el difícil equilibrio entre el tono educativo y el que corresponde a una revista de informática.
Creo que esta mínima reflexión basta en ausencia de feedback. Sirva como introducción a un nuevo cambio de nivel: en esta ocasión vamos a analizar con detalle una tecnología, y volveremos a la eventual aplicación a las aulas en una próxima entrega. ¿Que por qué? Porque es necesario, en este caso puedo afirmarlo con rotundidad.
Decíamos el mes pasado que la tecnología gettext y el formato PO habían logrado un nivel de madurez y eficacia considerables, y permitían la traducción de las interfaces de usuario de los programas a la gran mayoría de los idiomas y escrituras del mundo. También hacían fácil el trabajo de actualización por parte del traductor de sus traducciones, a la vez que protegía el código de manos no técnicas separando las fuentes y los ficheros con las cadenas que deben traducirse. Finalmente, en el balance de lo positivo, es una tecnología adaptada a los lenguajes de programación más usados, y las herramientas actualmente disponibles permiten el uso de diccionarios y memorias de traducción.
Sin embargo tanto la tecnología como el formato presentan una serie de problemas que vamos a enumerar, junto con varios intentos de responder a ellos. Hay que decir de todas formas que algunos de los problemas que señalamos aquí se dan en todos los sistemas de traducción ayudada por ordenador; pero mal de muchos... no dejan de ser nuestros problemas.
Problema 1. Gettext extrae las cadenas que hay que traducir de los ficheros de código. ¿Qué ocurre con el resto (la gran mayoría) de los documentos: ficheros de texto, html, de Open Office o MS Word, LaTeX o el cada vez más usado DocBook (xml)? ¿cómo traducir los ficheros man de ayuda, en formato groff, los Readme.txt o los info? ¿Y los textos contenidos en los archivos gráficos como svg o dia (que también son xml) o Impress? Los recursos con texto que traducir (subtítulos, interfaces verbales...) están cada vez más presentes.
Gettext no se inventó para traducir documentación. Ahora bien, en la práctica real, y aunque nadie la lea, ésta cada vez es más extensa y necesaria. Los usuarios tienen la tendencia a comprobar si existe, y a protestar si está en un idioma que no comprenden. Es obvio que puede utilizarse cualquier editor de textos, es cuestión de paciencia... se abren dos ventanas, con el texto original y el destino, y se trabaja ¿cuál es el problema entonces? No estamos hablando sólo de que no podemos utilizar nuestras herramientas habituales; la verdadera dificultad está en la imposibilidad de automatizar la reutilización de lo ya traducido cuando es necesario enfrentarse a una nueva versión. Sólo hay que imaginarse revisando frase por frase y palabra por palabra las posibles modificaciones, inserciones, eliminaciones o para nuestra total confusión cambios de lugar para darse cuenta de que necesitamos una solución mejor y generalizable. Necesitamos un programa que al igual que gettext separe lo que hay que traducir de lo que es marca o información no traducible (en ``<h1>Hello <strong>Dolly</strong></h1>'' sólo hay que traducir ``Hello'' y saber que ``Dolly'' es mejor no tocarla), que extraiga las cadenas con las que vamos a trabajar del fichero original (marcando donde estaban) y genere finalmente un fichero destino equivalente pero traducido.
Problema 2. Un segundo problema nos desafía, en este caso de carácter técnico. Los mensajes de una interfaz de usuario, los textos de un menú... son por esencia cortos. Ahora nos encontramos ante largos párrafos. Sin embargo la reutilización y la construcción de memorias de traducción se basan en las coincidencias dentro de un mismo segmento. Si la unidad de segmentación es el párrafo las coincidencias prácticamente desaparecerán. Es necesario resolver el problema de la segmentación de los textos. ¿Es la oración la unidad de traducción óptima? No tan rápido, amigo, que nos precipitamos. En primer lugar la definición algorítmica de lo que es una oración no es trivial (el punto, ``.'', no siempre separa oraciones, ¿verdad? -hay por tanto que agotar los casos en que sí o en que no), en segundo lugar lo que en una lengua se expresa naturalmente mediante una oración puede requerir de varias en otra. Estamos en ese fácil momento en el que sólo nos corresponde ser destructivos, sigamos pues con la lista de problemas.
Del anterior deducimos el problema relacionado de las coincidencias parciales (fuzzies, problema 3). ¿Cómo se detectan estas coincidencias difusas? Hay que ponerse un poco más técnicos aún: mediante la función fstrcmp (de ``comparación difusa de cadenas''). Ya lo preguntamos en la lista de distribución de LuCAS ¡en el año 2003! y tuvimos la suerte de que Santiago Vila nos contestara (ver el cuadro). Por supuesto, técnico o no, el tema reaparece una y otra vez, porque de estas traducciones dudosas propuestas depende gran parte de la utilidad de la informatización de la traducción. La forma de cuantificar las coincidencias de cadenas es expresar el tanto por ciento de caracteres coincidentes; pero entonces el carácter más o menos dudoso de una traducción propuesta depende de la longitud en caracteres de sus palabras.
Es preciso un sistema que determine claramente las palabras que constituyen la cadena de texto que va a traducirse. La solución de este problema está lejos de ser evidente: hay que hacer ver que en el ejemplo anterior ``Dolly'' y ``<strong>Dolly</strong>'' son la misma palabra, que ``Dol.ly'' sería una única palabra catalana, y determinar si ``strawman'' (o ``matter-of-fact'' o ``Weltanschauung'') se miden como una palabra o como dos.
Un problema adicional, el problema 4 se da en contextos multilenguaje: PO se creó para traducir de un lenguaje a otro lenguaje. ¿Qué ocurre si el texto fuente está escrito en varios idiomas (por ejemplo si contiene citas en latín)? Peor aún, ¿qué pasa si las codificaciones entre los distintos idiomas (Big5, cirílico) no son compatibles?
Nuestro problema 5 tiene que ver con el detalle del formato PO. La especificación es imprecisa. Intencionalmente imprecisa. ¿Cómo y quién especifica el formato? Un mensaje de Bruno Haible del 3 de abril de 2006 a la lista Translation-i18n nos da todas las claves:
«Esta cierta falta de claridad en la especificación [está respondiendo a una crítica] se usa para la evolución del formato. En los últimos seis años hemos hecho más estricto el reconocimiento de los mensajes obsoletos; hemos añadido nuevos campos a los cabecera PO; añadimos la posibilidad de fusionar la cabecera de distintos ficheros en uno solo usando msgcat; hemos añadido nuevas tipos de comentarios #,; se añadió una nueva palabra clave msgctxt... En el futuro es posible que se sigan añadiendo nuevos tipos de comentarios o campos en la cabecera. Clarificar la especificación ahora y después reeescribirla de forma incompatible no sería de ayuda para nadie.»
Esta imprecisión ocasiona que los autores de herramientas tengan que tomar decisiones. Sólo pondré un ejemplo, que repito siempre (es una de mis pesadillas recidivantes). El robot del Proyecto de Traducción Libre asume con tal rigidez sus reglas sobre lo que es una cabecera PO correcta (y rechaza el mensaje en tal caso, una y otra vez, sin cansancio ni piedad) que estoy seguro de que pocos, muy pocos de los ficheros PO propios de los proyectos GNOME o KDE pasarían la prueba. La prueba, la figura 1. El fichero no era aceptable para el robot, a pesar de que era válido para msgfmt.
Este problema tiene su corolario: es difícil determinar la validez de un fichero PO.
Problema 6: el contexto es indeterminado. Todos sabemos que la misma expresión puede tener un sentido totalmente distinto, y por tanto exigir una traducción diferente, dependiendo del contexto. El problema de nuestro sistema (y de las memorias de traducción sin contexto) es que la misma expresión traducida una vez se dará por traducida en sus siguientes apariciones.
Como no es del todo seguro que tratemos en estos artículos de asuntos marginales, y como entre entrega y entrega transcurre su tiempo, ocurre que tenemos nueva versión, y precisamente pertinente. El 24 de julio de 2006 el mismo Bruno Haible vuelve a dirigirse a la lista Translation-i18n anunciando la versión 0.15 de gettext, con entre otras la siguiente importante novedad:
Los ficheros PO pueden ahora contener mensajes limitados a un determinado contexto. Casi siempre dicho contexto será la identificación de un menú, de un diálogo o de un panel. La sintaxis es
msgctxt "contexto" msgid "original" msgstr "traducción"
Por supuesto, a falta de usos creativos, esta es una solución sólo parcial al problema general del contexto. Y también seguimos ante un formato que proporciona al traductor una información estructural deficiente.
Problema 7: la interpersonalidad de los equipos de traducción. Aunque frecuentemente una sociedad de más de dos personas es una multitud y por lo tanto un problema, no nos referimos a eso. Tal como la hemos visto hasta ahora, el proceso de traducción ha sido una tarea individual. Una persona asume la responsabilidad de traducir un fichero, envía su traducción, y ahí acaba todo. Pero esta descripción está lejos de ser adecuada para el flujo real de trabajo de un equipo eficaz de traducción. En dos sentidos principales. Primeramente, porque para que tengan un mínimo de calidad (casi diríamos de inteligibilidad) las terminologías utilizadas deben ser coherentes (se traducirán los mismos términos de forma igual por parte de todos los traductores del grupo), se deberán compartir las memorias de traducción, etc.
En un segundo sentido, problema 8, porque las personas que intervienen en el proceso son más. Para un correcto flujo de trabajo son necesarios un coordinador, un sistema de asignación o reserva de tareas, uno o varios traductores para cada fichero, revisores de las traducciones, personas que se encarguen de las terminologías y de las memorias de traducción así como del estudio, adecuación y actualización de las herramientas utilizadas, etc. De todos estos pasos debe quedar constancia, así como de las conclusiones de las discusiones. Teniendo en cuenta que el proceso es cíclico, continuamente se producen nuevas versiones y se incorporan nuevos ficheros al sistema. Las soluciones a este problema deberán ser externas, quizás aprovechando los datos que nos ofrece el formato PO en su cabecera: último traductor, grupo... quizás convenga para tomar siquiera conciencia del grado de detenimiento con el que la industria de la traducción ha analizado el problema, examinar la figura 2[1].
Este problema trae de cabeza a los coordinadores de los grupos. Por un lado el perfil típico clásico del traductor voluntario es el de un estudiante de ingeniería (esto lo vamos a corregir, ¿verdad?, ¡a partir de ahora serán profesores de idiomas!), con un conocimiento limitado del inglés, y que tampoco domina las decisiones terminológicas a las que se haya podido llegar en el grupo. Por uno que persiste, varios picotean (son voluntarios), y cuando el coordinador señala los errores cometidos suelen desaparecer. ¿Cómo conciliar la necesidad de facilitar el trabajo a los nuevos traductores, ofreciéndoles interfaces intuitivas, orientación terminológica, etc., con la de elevar el nivel de calidad de las traducciones? Profesionalizando el flujo de trabajo, para poder exigir.
Del problema 3 concluimos que es necesario determinar de manera objetiva el número de palabras que constituyen un texto (nuestro problema 9º). De la importancia del problema para la industria de la traducción (que no puede aceptar que cada herramienta dé un resultado distinto, la facturación por palabras es una cuestión seria) da cuenta la creación de un grupo de trabajo para la redacción de un estándar[2]. Una ilustración bastará, gedit informaba de que este documento antes de incluir esta frase contenía 2709 palabras. Un previo es_ES wc -w traducc_2.txt daba como salida 2464 traducc_2.txt.
Problema 10: la mayoría de los traductores profesionales y estudiantes de traducción usan herramientas comerciales que no aceptan el formato PO; es el fenómeno que vamos a llamar aislamiento de las comunidades. Sería un problema menor si este formato fuera manifiestamente superior, pero el problema se agrava si existe un formato abierto y aceptado por la industria para la misma función, XLIFF, y otro para el intercambio de memorias de traducción, TMX.
Recordemos de la anterior entrega que PO es el formato con el que trabajan las herramientas de traducción disponibles clásicamente[3]. Por tanto la primera opción es crear un conversor del formato de los documentos a PO. En el mundo del software libre, y que se me perdone la exageración, sólo hay cuatro formatos de texto que cuentan: el odt de OpenOffice, DocBook, html y LaTeX. Es curioso que los tres primeros sean hoy formas de XML, es la señal del éxito de esta tecnología.
Bien, comencemos por el principio: XML DocBook es el formato en el que está escrita la documentación de la gran mayoría de los proyectos de software libre (sí, la de KDE y la de GNOME...) y la de muchas empresas de alta tecnología. Los primeros que se enfrentaron públicamente al problema de la convergencia de herramientas entre la traducción de la interfaz de usuario y de la documentación fue el equipo de traducción de KDE, en un documento con unos cuantos años ya: el KDE Translation HOWTO[4]. La clave está en el uso de las utilidades xml2pot, que crea la plantilla POT, transxx, que crea el fichero PO en blanco y, finalmente, po2xml, todas del paquete poxml . O bien, si ya tenemos alguna versión de los ficheros en supongamos inglés y castellano:
split2po english.xml español.xml > en-es.po
No debemos confundir poxml (¡ni xml2pot!) con xml2po de Danilo Segan (parte de gnome-doc-utils)[5], la inevitable respuesta de GNOME.
Ahora la plantilla se crearía así:
xml2po -o ejemplo.pot ejemplo-en.xml
Terminada la traducción se procedería a generar el fichero XML destino
xml2po -p es.po ejemplo-en.xml > ejemplo-es.xml
Como sabemos que aún hay irreductibles que no usan DocBook para hacer la lista de la compra ni para escribir sus exámenes, es el momento de ver si hay conversores para el resto de los formatos. El proyecto PO for Anything (paquete po4a), de Denis Barbier and Martin Quinson, generaliza el procedimiento de ida y vuelta (formato -> PO y PO -> formato).
El proyecto ha creado un conjunto de filtros (exactamente módulos perl) que convierten a y de PO a cada vez más formatos, y varias aplicaciones de línea de órdenes que los aplican. Para averiguar los formatos que convierte la versión instalada, basta lanzar (po4a-gettextize es el programa que convierte a PO)
po4a-gettextize --help-format
La versión 0.27.2, de 8 de agosto de 2006 (en el cvs de alioth se está preparando la versión 0.29), trabaja con nroff (para los man), pod, sgml, xml, docbook, dia, info, latex, html... aunque no todos los módulos tienen el mismo nivel de madurez). En su momento hice mis pruebas con la conversión de fuentes LaTeX. Lo hacía así
TEXINPUTS=/usr/share/texmf/tex/latex/base \ po4a-gettextize -f latex \ -m $1 -M iso-8859-1 \ -p $file.pot \ -o exclude_include=content-es:application-es
¿Por qué es importante po4a? Porque desde hace tiempo es la herramienta que se utiliza en proyectos como Debian para muchas de sus tareas internas de traducción (por ejemplo para los mensajes de las ventanas de configuración de debconf, o para el proyecto renacido de traducir las descripciones de las aplicaciones). En la jerga, po4a es una de las aplicaciones básicas no esenciales de la cadena de herramientas de Debian congelada recientemente para preparar la estabilidad de Etch. Además, al ser un conjunto de aplicaciones de línea de órdenes ejecutables en tandas más un conjunto modular de filtros puede ser utilizado por otras aplicaciones que presenten interfaces de usuario más amigables.
Por último tenemos los filtros esta vez en python del proyecto Translate, el Translate Toolkit[6] (paquete translate-toolkit, pofilter --version nos señala la versión 0.9.1). Nos proporciona las siguientes utilidades de nombres transparentes: oo2po, sxw2po, moz2po, csv2po, ts2po, txt2po, html2po, xliff2po, tiki2po y sus inversas. Sobre este proyecto y sobre pootle hablaremos largo y tendido en la siguiente entrega.
Volviendo a nuestras reflexiones iniciales sobre los problemas que la tecnología de la traducción libre debe resolver, vemos que hemos avanzado únicamente en la solución de la primera dificultad (gettext no se creó para traducir documentación o recursos). Sin embargo hemos puesto las bases también, mediante la creación de filtros de conversión, para que herramientas de nivel superior permitan mejores interfaces de cooperación y control (las veremos en la siguiente entrega).
Por otro lado ya vimos que el tema de las traducciones dudosas no estaba tan verde como nos había parecido en su momento (a falta de una solución de segmentación y alineamiento adecuados).
Una solución alternativa, aunque también se base en el uso de filtros, nos la ofrece OmegaT, una herramienta gráfica escrita en java. ¿Qué es exactamente OmegaT? Como muy bien resume Jean-Christophe Helary en la propuesta de actualización de la documentación que fue enviando a la lista de OmegaT@yahoogroups.com a lo largo del mes de mayo de 2006
«OmegaT es una herramienta de traducción asistida por ordenador. Toma nota de tus traducciones mientras las tecleas y te recuerda la traducción anterior cuando encuentra un texto similar.
OmegaT ayuda al traductor recordándole tres cosas:
1. cómo el mismo traductor ha traducido una oración similar a la que está traduciendo
2. cómo alguien distinto tradujo en su momento una oración similar
3. el modo en que deben traducirse los términos incluidos en un glosario.»
Los dos primeros puntos se refieren a las memorias de traducción, el tercero introduce el concepto de terminología.
Aunque la versión actual (agosto 2006) es 1.6.0 RC12a, al parecer la versión más estable es la RC10, que carece por supuesto de algunas de las nuevas características de las versiones más recientes[7]. Mi experiencia actual es con la versión RC8 (ver figura 4; no conviene cambiar de versión durante el proceso de realización de una traducción).
¿Qué aporta la OmegaT 1.6.0 RC8 sobre las antiguas versiones 1.4.X?
OmegaT procede de un mundo ajeno a gettext y al formato PO, más cercano a las herramientas usadas en el mundo de la traducción comercial, con las que se mide. Sorpresivamente usa el formato estándar de intercambio de memorias de traducción TMX como su formato interno de trabajo (un texto se convierte en memoria para trabajar con él).
La figura 5 nos muestra en pleno proceso de traducción, frase por frase, y la memoria de traducción creada nos ofrece una ayuda a la traducción actual. No hemos creado ningún glosario en este caso (según la documentación se crearía mediante un fichero de extensión y codificación .utf8, que incluiría tres columnas separadas por tabulaciones: la palabra -o expresión- de la lengua original, la palabra o expresión de la lengua destino y algún posible comentario, útil para ayudar a la traducción).
¿Con qué formatos trabaja OmegaT? Depende de la versión (se van incorporando nuevos filtros continuamente): texto plano, html y xhtml, sx? y od? (las distintas aplicaciones de las suites de OpenOffice), un incipiente módulo PO ¡!
Para terminar no tenemos más que pulsar la opción Generar los documentos destino del menú. Mis pruebas con html son satisfactorias. Una pega: volvemos al aislamiento de las comunidades en su faceta inversa: ¿qué hacemos con nuestros compendios PO? ¿Hay alguna forma de que OmegaT los acepte o podamos convertirlos al formato TMX?
Estudiaremos con detalle las soluciones para lo que hemos llamado la «interpersonalidad de los grupos de traducción»: las posibilidad de compartir memorias de traducción, las interfaces web (nos detendremos en pootle)...
Cómo se calculan las coincidencias difusas |
Rectificar es de sabios, y de sus imitadores (y un autor de artículos, picoteando en cien sitios, no puede dejar de ser patético en ocasiones). Durante bastante tiempo sostuve (y dejé escrito) que la base de la búsqueda de coincidencias de gettext no debía ser más que un diff(). Hasta que tuve la humildad de preguntarlo. Este es un extracto del mensaje de respuesta de alguien que sí sabe, Santiago Vila, a la lista de distribución de LuCAS, 1 de octubre de 2003: «Las comparaciones de una cadena con otra se hacen con la función fstrcmp que está en gettext-tools/lib/fstrcmp.c [aquí remite a la lectura del código fuente de la función, que incluye un esbozo de manual de uso...] Al principio [del fichero] se lee lo siguiente: Derived from GNU diff 2.7, analyze.c et al. The basic algorithm is described in: ``An O(ND) Difference Algorithm and its Variations'', Eugene Myers, Algorithmica Vol. 1 No. 2, 1986, pp. 251-266; see especially section 4.2, which describes the variation used below. The basic algorithm was independently discovered as described in: ``Algorithms for Approximate String Matching'', E. Ukkonen, Information and Control Vol. 64, 1985, pp. 100-118. Unless the `minimal' flag is set, this code uses the TOO_EXPENSIVE heuristic, by Paul Eggert, to limit the cost to O(N 1.5 log N) at the price of producing suboptimal output for large inputs with many differences. Modified to work on strings rather than files by Peter Miller <pmiller@agso.gov.au>, October 1995.» El 13 de marzo de 2006, en el hilo msgmerge fuzzy-search de la lista Translation-i18n, discuten Bruno Haible y Danilo Segan la posibilidad de ir más allá en el desarrollo de gettext añadiendo nuevos (o mejores) algoritmos de búsqueda de coincidencias difusas. Una de la posibilidades que se plantea Haible: «algoritmos basados en palabras, como ignorar los signos de puntuación o las marcas HTML, podrían sustituir a fstrcmp() en determinadas situaciones». |
[1] Esta imagen es propiedad de i18n inc. y tiene los derechos reservados.
[2] GMX-V (http://www.lisa.org/standards/gmx/) está hasta el 16 de septiembre de 2006 en fase de revisión pública, a la espera de la aprobación oficial como un estándar de OSCAR.
[3] Estudiando el wiki del proyecto Translate (http://translate.sourceforge.net/wiki/guide/tools/comparison) hemos encontrado la comparativa de la figura 3.
[4] Nos referimos al capítulo 4 de http://l10n.kde.org/docs/translation-howto/. Poxml (http://cia.navi.cx/stats/project/kde/kdesdk/poxml) es obra de Stephan Kulow y Peter Wells.
[5] Xml2po está documentado por Lars Trieloff en http://weblogs.goshaky.com/weblogs/page/lars/20040823.
[6] http://translate.sourceforge.net/wiki/translatetoolkit?DokuWiki=864df61fcbfaceb8a765a56333b837fa.
[7]
La información más actualizada sobre OmegaT puede encontrarse en
http://www.omegat.org/omegat/omegat.html. Existe
también un sitio que reúne al grupo de usuarios y desarrolladores
(http://groups.yahoo.com/group/OmegaT/). Para
descargar OmegaT se visitará SourceForge:
http://sourceforge.net/projects/omegat.
¿Qué versión descargar? Depende de nuestras necesidades (las nuevas versiones incorporan nuevas
funcionalidades, pero también están menos probadas). Las resumimos:
Para la segmentación en OmegaT consultar http://sourceforge.net/support/tracker.php?aid=1053692 (las reglas de segmentación están en el fichero $home/.omegat/segmentation.conf); aunque hace su aparición en la versión 1.4.6 Beta 2 (junio de 2005), no es utilizable hasta las 1.6. Respecto a la importación y exportación de TMX, remitimos a http://sourceforge.net/support/tracker.php?aid=1031139.
[8] Para aclararse con el tema de las versiones y los niveles de TMX no hay nada mejor que leer este mensaje de Rodolfo M. Raya a la lista de distribución de OmegaT de fecha 2 de junio de 2005:
There are several versions of TMX DTD: * 1.1 * 1.2 * 1.3 * 1.4 * 1.4a * 1.4b All of them have different elements and attributes. Most CAT tools work with version 1.4 and its variants. OmegaT still works with version 1.1 of TMX DTD. TMX Levels are a different thing. There are only two Levels and their definitions are the same across all versions of TMX DTD. * Level 1: only text without formatting information is stored in the TMX file. * Level 2: text with formatting information properly encapsulated inside special elements is stored in the translation memory.
La limitación al nivel 1 implica que la encapsulación del marcado que realizan otras aplicaciones se pierde.