<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!DOCTYPE article SYSTEM "/usr/share/sgml/docbook/dtd/xml/4.2/docbookx.dtd"[
<!ENTITY percnt "&#x0025;">
<!ENTITY mdash "&#x2014;">
<!ENTITY hellip "&#x2026;">
<!ENTITY lsquo "&#x2018;">
<!ENTITY rsquo "&#x2019;">
<!ENTITY ldquo "&#x201C;">
<!ENTITY rdquo "&#x201D;">
]>


<article lang="es">

  <articleinfo>
    <title>Un paso adelante</title>
    <subtitle>
      Plan de tecnologías lingüísticas libres
    </subtitle>
    <edition>0.7</edition>
    <pubdate>
      $Id: un-paso-adelante.xml,v 1.3 2003/09/08 21:42:57 juanfernandez Exp $ 
    </pubdate>
    <author>
      <personname>
	<firstname>Juan Rafael</firstname>
	<surname>Fernández García</surname>
      </personname>
      <email>juanrafael.fernandez@hispalinux.es</email>
      <address>
	<affiliation>
	  <jobtitle>
	    Coordinador responsable de herramientas lingüísticas
	  </jobtitle>
	  <orgname>TLDP-ES</orgname>
	</affiliation>
	<contrib>
	</contrib>
      </address>
    </author>
    <copyright>
      <year>2003</year>
      <holder>Juan Rafael Fernández García</holder>
    </copyright>
    <legalnotice>
      <para>
	Permission is granted to copy, distribute and/or modify this
        document under the terms of the <acronym>GNU</acronym> Free
        Documentation License, Version 1.1 or any later version
        published by the Free Software Foundation.
      </para>
    </legalnotice>		

    <revhistory>
      <revision>
	<revnumber>0.7</revnumber>
	<date>2003-09-07</date>
	<authorinitials>jrf</authorinitials>
	<revremark>Versión enviada al VI Congreso Hispalinux</revremark>
      </revision>
      <revision>
         <revnumber>0.6</revnumber>
         <date>2003-03-17</date>
         <authorinitials>jrf</authorinitials>
         <revremark>Superada tortura de xmllint, victorioso</revremark>
      </revision>
      <revision>
         <revnumber>0.5</revnumber>
         <date>2003-02-26</date>
         <authorinitials>jrf</authorinitials>
         <revremark>La información pasa a doc-traduccion-libre</revremark>
      </revision>
      <revision>
         <revnumber>0.4</revnumber>
         <date>2003-02-25</date>
         <authorinitials>jrf</authorinitials>
         <revremark>Modificaciones menores del marcado</revremark>
      </revision>
      <revision>
         <revnumber>0.3</revnumber>
         <date>2003-02-24</date>
         <authorinitials>jrf</authorinitials>
         <revremark>Revisión del xml</revremark>
      </revision>
      <revision>
         <revnumber>0.2</revnumber>
         <date>2003-02-20</date>
         <authorinitials>io</authorinitials>
         <revremark>Primera versión xml</revremark>
      </revision>
      <revision>
         <revnumber>0.1</revnumber>
         <date>2002-17-12</date>
         <authorinitials>jrf</authorinitials>
         <revremark>Versión inicial (txt)</revremark>
      </revision>
   </revhistory>
									       
    <abstract>
      <para>
	<emphasis>
	  Notas previas para una especificación de requisitos de
	  las herramientas lingüísticas de TLDP
	</emphasis> 
	(La comprensión plena de este documento requiere familiaridad
	con las herramientas lingüísticas o la lectura previa de 
	doc-traducción-libre &mdash;<ulink
	  url="http://es.tldp.org/Articulos/0000otras/doc-traduccion-libre/">
	  http://es.tldp.org/Articulos/0000otras/doc-traduccion-libre/
	</ulink>&mdash;, documento producido en el seno de
	<emphasis>TLDP-ES)</emphasis>
      </para>
      <para>
	En este artículo el autor presenta y justifica sus propuestas
	con respecto a la adopción de estándares libres de marcado e
	intercambio de información lingüística y el desarrollo de
	herramientas libres de ayuda a la escritura y traducción,
	de manera que puedan someterse a discusión pública y adoptarse
	como especificaciones de TLDP. Es en cierto modo un apéndice
	ejecutivo, las conclusiones de la exposición realizada en el
	documento anterior. 
      </para>
      <para>
	<itemizedlist>
	  <listitem>
	    <para>
	      Última versión:
	      <ulink
		url="http://es.tldp.org/especificaciones/herramientas-linguisticas/herramientas-linguisticas/">
		http://es.tldp.org/especificaciones/herramientas-linguisticas/herramientas-linguisticas/
	      </ulink> 
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Fuente:
	      <ulink
		url="http://cvs.hispalinux.es/cgi-bin/cvsweb/esp-herramientas-linguisticas/un-paso-adelante.xml">
		http://cvs.hispalinux.es/cgi-bin/cvsweb/esp-herramientas-linguisticas/un-paso-adelante.xml
	      </ulink>
	    </para>
	  </listitem>
	</itemizedlist>
      </para>
    </abstract>

  </articleinfo>

  <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
  <sect1 id="parte_introduccion">
    <title>Introducción</title>

    <para>
      La temática de este documento es lo que en la jerga de la 
      industria se llama <foreignphrase>localization</foreignphrase> 
      (no me atrevo yo a traducir «localización»), 
      directamente relacionada 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 
      &lsquo;spirits sold here&rsquo;? ¿cómo puede un humilde
      corrector ortográfico distinguir &lsquo;a&rsquo; de 
      &lsquo;ha&rsquo;?
    </para>

    <para>
      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 <acronym>CAT</acronym>, 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.
    </para>

    <para>Dice Ismael Olea, hablando del desarrollo de TLDP,</para>

    <blockquote>
      <para>Hay dos niveles de objetivos a cumplir:

	<itemizedlist>
	  <listitem>
	    <para>
	      herramientas para el fácil mantenimiento y 
	      traducción de nuestra documentación
	    </para>
	  </listitem>

	  <listitem>
	    <para>herramientas lingüísticas de calidad</para>
	  </listitem>
	</itemizedlist>
      </para>
    </blockquote>
	
    <para>
      Empezar a trabajar en la  segunda opción no debe suponer 
      merma de la primera.
    </para>

    <!-- %%%%%%%%%% -->
    <sect2 id="sec_por_que"><title>¿Por qué?</title>

      <para>
        Pensando sobre el esquema de Ismael Olea &lsquo;Arquitectura
	para reproducción y publicación&rsquo; del borrador de 
        <citetitle pubwork="article">
	  LuCAS v4: creando el sistema de publicación de TLDP-ES
	</citetitle>
	(<ulink
	url="http://cvs.hispalinux.es/cgi-bin/cvsweb/doc-conf-creando-lucasv4/herramientas-reproduccion-publicacion.png">
	http://cvs.hispalinux.es/cgi-bin/cvsweb/doc-conf-creando-lucasv4/herramientas-reproduccion-publicacion.png
	</ulink>),
	creo que es el momento &mdash;intentaré explicar por
	qué&mdash; 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. 
      </para>

      <para>
        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
        <application>DSpace</application> 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.
      </para>

      <para>
        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 &mdash;¿quizás alguna universidad?&mdash; 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.
      </para>

      <para>
        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 
	<acronym>TLDP</acronym> o de <acronym>FSF</acronym> 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&hellip;) 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.
      </para>

      <!-- %%% -->
      <sect3 id="introduccion_propuesta">
	<title>La crisis: más allá de los ficheros .po</title>

	<!-- 
	<para>Nuestras herramientas de traducción:
	<application>kbabel</application>,
	<application>gtranslator</application> y
	<application>emacs</application> con extensiones
	<application>gettext-el</application>.</para>
	-->
	<para>
	    No 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 (<foreignphrase>fuzzy</foreignphrase>)
	    o no existe, y el informe automático del número de cadenas
	    traducidas&hellip;</para>

	<para>
	    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:
	</para>

	<itemizedlist>
	  <listitem>
	    <para>
	      <emphasis><application>doc-i18n-tool</application></emphasis>
	      (<ulink
		url="http://mail.gnome.org/archives/gnome-doc-list/2001-October/msg00034.html">
		http://mail.gnome.org/archives/gnome-doc-list/2001-October/msg00034.html
	      </ulink>)
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      <emphasis><application>poxml</application></emphasis> 
	      (de KDE)
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      <emphasis><application>po-debiandoc</application></emphasis>
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      <emphasis><application>po-pod</application></emphasis>,nuevo
	      miembro de la familia de utilidades
	      <application>po-for-everything (po4a)</application>, tal
	      como se presenta en la Debian Weekly News del 3 de dic. de 2002:
	    </para>
	    <para>
	      <quote>
		The goal of po-pod is to allow
		translators to work only with well known po files 
		when translating pod documentation. The goal of po4a is
		to ease translations (and more interestingly, the 
		maintainance of translations) by using gettext tools on 
		areas where they were not yet
		expected. 
	      </quote>
	      (<ulink url="http://lists.debian.org/debian-i18n-0211/msg00009.html">
		http://lists.debian.org/debian-i18n-0211/msg00009.html</ulink>)
	    </para>
	    <para>
		La referencia es 
		<ulink url="http://www.ens-lyon.fr/~mquinson/deb.html#po-pod">
		http://www.ens-lyon.fr/~mquinson/deb.html#po-pod</ulink>.
	    </para>
	  </listitem>
	</itemizedlist>

	<para>
	  Llevo tiempo preguntándome si estos tímidos intentos van bien
	  encaminados. Mis objeciones son las siguientes:
	<itemizedlist>
	  <listitem>
	    <para>
		.po no es un formato bien marcado (me refiero,
		cualquiera que haya luchado con el Robot del Proyecto de 
		Traducción Libre me entenderá, a que quede claro que
		en la tercera línea debe ir el
		<foreignphrase>e-mail</foreignphrase> del traductor y
		el <foreignphrase>copyright</foreignphrase>, por
		ejemplo)
	      </para>
	    </listitem>
	    <listitem>
	      <para>
		Me temo que .po no permite granularidad en la
		descomposición del párrafo/cadena en sus
		componentes. Cuando reconoce una cadena como
		<foreignphrase>fuzzy</foreignphrase> está actuando
		únicamente al nivel de
		<foreignphrase>grep</foreignphrase>. 
	      </para>
	    </listitem>
	  </itemizedlist>
	</para>

	<para>
	  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).
	</para>
	<para>
	  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. 
	</para>

      </sect3>
    </sect2>

    <!-- %%%%%%%%%% -->
    <!-- 
    Aquí había una sección dedicada a definir los términos (corpus,
    memoria de traducción, etc.
    Pasado a doc-traduccion-libre
    -->

  </sect1>

<!-- 
Aquí había un amplio capítulo exploratorio sobre lo que puede
encontrarse en la red de lingüística computacional.
Pasado a doc-traduccion-libre.
-->

  <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
  <sect1 id="parte_al_grano">
    <title>Al grano</title>

    <para>
      En 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.
    </para>

    <para>
      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 
      <ulink
	url="http://es.tldp.org/Articulos/0000otras/doc-traduccion-libre/">
	http://es.tldp.org/Articulos/0000otras/doc-traduccion-libre/
      </ulink>. Es el momento de una revisión detallada y de tomar
      decisiones. 
    </para>

    <!-- %%%%%%%%%% -->
    <sect2 id="sec_propuesta_lineas_generales">
      <title>Propuesta: Líneas generales</title>

      <para>
	En TLDP se usarán estándares libres y abiertos: DocBook, TEI,
	XCES&hellip; y cuando se utilice uno propio
	se crearán mecanismos para la importación/conversión
	(recordemos por ejemplo la utilidad incorporada a
	<application>Mimers brunn</application> como conversor de .po a
	TMX). 
      </para>

      <para>
	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.
      </para>

      <para>
	La codificación UTF-8 es lógica en un proyecto con ambiciones
	de universalidad.
      </para>

      <!-- 
      <para>[Eliminada sección sobre bibliotecas electrónicas]</para>
      -->
    </sect2>

    <!-- %%%%%%%%%% -->
    <sect2 id="sec_diccionarios"><title>Diccionarios</title>

      <para>
	En primer lugar evitemos una confusión generalizada,
	<foreignphrase>de verba non est disputandum</foreignphrase>.
	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<footnote>
	  <para>Basta consultar la clasificación de dos páginas del
	    término «diccionario» que hace Martínez De Sousa 
	    <citetitle pubwork="book">
	      Diccionario de lexicografía práctica
	    </citetitle> para llegar a la conclusión de que lo
	    importante no es cómo se llama sino qué clase de diccionario
	    queremos.</para>
	</footnote>. 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&hellip;). 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?
      </para>

      <!-- %%% -->
      <sect3 id="sec_diccionarios_discusion">
	<title>Discusión</title>

	<para>
	  Estamos en LuCAS-desarrollo reimpulsando nuestro propio
	  diccionario inglés-español de informática 
	  <application>Giait</application><footnote>
	    <para>
	  <ulink
	  url="http://cvs.hispalinux.es/cgi-bin/cvsweb/rl-dicc/">
	    http://cvs.hispalinux.es/cgi-bin/cvsweb/rl-dicc/</ulink>.</para>
	  </footnote> Por otro
	  lado estamos intentando crear el mayor lemario del 
	  español<footnote>
	    <para><ulink url="http://lemarios.olea.org">
		http://lemarios.olea.org</ulink></para>
	  </footnote>. Y periódicamente nos planteamos
	  qué sentido tendría reclamar la liberación del diccionario
	  de la <acronym>RAE</acronym> (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).
	</para>

	<para>
	  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.
	</para>

	<!--  -->
	<sect4 id="sec_tei_p4"><title>Sobre TEI P4</title>
	  <para>
	    La versión XML de las 
	    <citetitle pubwork="book">TEI P4 Guidelines</citetitle><footnote>
	      <para>
		(<ulink
		  url="http://www.tei-c.org/Guidelines2/index.html">
		  http://www.tei-c.org/Guidelines2/index.html</ulink>. 
		El documento puede
		descargarse comprimido como
		<ulink
		  url="http://www.tei-c.org/Guidelines2/p4html.tar.gz">
		  http://www.tei-c.org/Guidelines2/p4html.tar.gz</ulink>
	      </para>
	    </footnote>, en su
	    capítulo 13 &lsquo;Terminological Databases&rsquo;, advierte
	  </para>

	  <blockquote>
	    <para>
	      Since its first publication, this chapter has been rendered
	      obsolete in several respects, chiefly as a result of the
	      publication of ISO 12200, and a variant of it 
	      (<acronym>TBX</acronym>) which
	      has been recently adopted by LISA. Work is currently ongoing
	      in the ISO community to define a generic platform for
	      terminological markup (ISO CD 16642, 
	      <acronym>TMF</acronym>: Terminological
	      Markup Framework), in the light of which it is anticipated
	      that the recommendations of the present chapter will be
	      substantially revised.
	    </para>
	  </blockquote>

	  <para>
	    Sí nos interesa el capítulo 12 
	    &lsquo;Print Dictionaries&rsquo;.
	  </para>

	  <blockquote>
	    <para>A simple dictionary entry may contain
	      information about the form of the word treated, its
	      grammatical characterization, its definition, synonyms, or
	      translation equivalents, its etymology, cross-references to
	      other entries, usage information, and examples.
	    </para>
	  </blockquote>

	  <para>
	    Interesante parece estudiar como ejemplo de aplicación de TEI
	    <ulink
	      url="http://www.human.toyogakuen-u.ac.jp/~acmuller/articles/ddb-ebti2001.htm">
	      http://www.human.toyogakuen-u.ac.jp/~acmuller/articles/ddb-ebti2001.htm
	    </ulink>
	  </para>

	</sect4>

	<!--  -->
	<sect4 id="sec_wordnet"><title>Sobre WordNet</title>
	  <para>
	    Princeton WordNet
	    (<ulink
	      url="http://www.cogsci.princeton.edu/~wn/w3wn.html">
	      http://www.cogsci.princeton.edu/~wn/w3wn.html</ulink>)
	  </para>

	  <para><userinput>man wndb</userinput> ó</para>

	  <para>
	    <ulink
	      url="http://www.cogsci.princeton.edu/~wn/man1.7.1/wndb.5WN.html">
	      http://www.cogsci.princeton.edu/~wn/man1.7.1/wndb.5WN.html
	    </ulink>
	  </para>

	  <para>
	    EuroWordNet
	    (<ulink url="http://www.illc.uva.nl/EuroWordNet/">
	      http://www.illc.uva.nl/EuroWordNet/</ulink>). EuroWordNet 
	    was a
	    European resources and development project (LE-2 4003
	    &amp; LE-4 8328) supported by the Human Language
	    Technology sector of the Telematics Applications
	    Programme, 1996-1999
	  </para>

	  <para> 
	    <warning>
	      <title>Problema</title>
	      <para>
		Me temo que la versión europea de wn tiene carácter
		no libre y sus herramientas son no libres
		(editor Polaris; el visor Periscope solamente es
		freeware)
	      </para>
	    </warning>
	  </para>

	</sect4>
      </sect3>

      <!-- %%% -->
      <sect3 id="sec_diccionarios_propuesta">
	<title>Propuesta</title>

	<orderedlist>
	  <listitem>
	    <para>
	      El formato estándar para la distribución de
	      diccionarios es .dict (un éxito, multiplicado casi por
	      cuatro desde la primera redacción de
	      <ulink
		url="http://es.tldp.org/Articulos/0000otras/doc-traduccion-libre/">
		doc-traduccion-libre</ulink>)
	    </para>
	  </listitem>

	  <listitem>
	    <para>Para consultas el estándar es la red 
	      <application>dict</application>, mediante
	      clientes específicos o interfaz 
	      <foreignphrase>web</foreignphrase>
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Otro tema es cómo escribir diccionarios: propongo con
	      dudas adoptar TEI
	      P4 como la DTD de nuestros diccionarios específicos. En
	      este sentido, es necesario también completar el
	      desarrollo de Giait y 
	      desarrollar herramientas generales que puedan utilizarse
	      para el desarrollo de nuevos diccionarios
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      La gran pregunta, que normalmente no se hace cuando se
	      está haciendo un diccionario, es qué información debe
	      contener. Si queremos poder utilizar herramientas
	      avanzadas de ayuda a la traducción nuestro diccionario
	      debe tener información gramatical leíble por
	      máquinas. Propongo el uso de XCES.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Cómo incorporar términos a los diccionarios: ¿modelo
	      ORCA? (contribuciones públicas, revisadas por un moderador) 
	      ¿modelo lista spanglish? (discusiones inter pares)
	    </para>
	    <para>
	      Utilizar herramientas de confección de
	      glosarios. Debemos ir hacia
	      diccionarios basados en 
	      <foreignphrase>corpus</foreignphrase>, con herramientas
	      de extracción terminológica que cubren de forma
	      exhaustiva un campo (y nos señalan fehacientemente qué
	      términos faltan por definir) y abandonar el método
	      manual de adición de entradas.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Cómo garantizar la calidad de las incorporaciones:
	      Crear sistema de mantenimiento de calidad (incluir entre
	      las marcas de cada término autor, fecha,
	      revisión&hellip;)
	    </para>
	  </listitem>
	</orderedlist>
<!-- 
	<warning><para> ¿Es estable passivetex?</para>
	</warning>
 -->
	<note>
	  <para> Será necesario adaptar
	    TEItools (<ulink url="http://xtalk.msk.su/SGML/TEItools">
	      http://xtalk.msk.su/SGML/TEItools</ulink>)
	    &mdash; son para TEI Lite, no para TEI P4.
	  </para>
	</note>
      </sect3>


      <!-- %%% -->
      <sect3 id="sec_un_caso_practico"><title>Un caso práctico</title>

	<para>
	  Las dos primeras entradas de la letra «a» 
	  en las fuentes del diccionario
	  <application>Giait</application> 
	  son
	</para>

	<programlisting>
@@ING A, Ampere, Amps 
@@CAS Ampère (amperio), amperios. 
@@DIC Vocablo definido únicamente para el Diccionario
@@FIN

@@ING A Programming Language", APL 
@@CAS Lenguaje de Programación APL 
@@GLO APL es la sigla de "A Programming Language" (Un Lenguaje de 
@@GLO Programación), que fue un libro escrito en 1962 por el credor del 
@@GLO lenguaje, Kenneth E. Iverson. Basado en lo que antes se había conocido 
@@GLO como la Nomenclatura Iverson, el APL es un lenguaje de programación 
@@GLO extremadamente conciso, diseñado para el manejo de los arreglos 
@@GLO (arrays). Los arreglos pueden ser escalares, vectoriales, tablas o 
@@GLO matrices de dos o más dimensiones, pudiendo estar compuestos de 
@@GLO información numérica o alfanumérica. Bajo la conducción de Iverson, 
@@GLO IBM introdujo en 1966 el APL\360. 
@@GLO Como el APL evita la introducción de las computadoras personales, 
@@GLO originalmente se lo empleó unicamente en mainframes. Desde 1983, han 
@@GLO estado disponibles las versiones de APL para las PC. Debido a su 
@@GLO conjunto de caracteres especiales expandidos, el APL requiere un 
@@GLO teclado especial, o el uso de macros, para el ingreso de datos. 
@@GLO Las versiones actuales de APL para mainframes y PC se denominan
@@GLO APL2.
@@GLO
@@FIN
</programlisting>

	<para>
	  Convertidas a formato .dict (descomprimido) actualmente
	  quedan así:
	</para>

	<para>A, Ampere, Amps Ampère (amperio), amperios.</para>

	<para>
	  A Programming Language", APL Lenguaje de
	  Programación APL
	</para>

	<para>
	  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&hellip;)
	</para>

	<para>¿Cómo aparece?</para> 

<programlisting>
<computeroutput>11262928 23 n 03 ampere 0 amp 0 A 0 003 @ 11259168 n
0000 #p 11263273 n 0000 %p 11263164 n 0000 | the basic unit of
electric current adopted under the System International d'Unites;
"a typical household circuit carries 15 to 50 amps"
</computeroutput>
</programlisting>

	<para>
	  ¿Cómo quedaría todo esto en TEI P4? Crearemos el fichero
	  ejemplo.tei.xml (el siguiente fragmento de texto está en
	  UTF-8)
	</para>

<programlisting>
<![CDATA[
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%% empieza ejemplo.tei.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE TEI.2 PUBLIC "-//TEI P4//DTD Main Document Type//EN" 
  "/usr/local/share/sgml/tei/dtd/tei2.dtd" [
  <!ENTITY % TEI.XML          'INCLUDE' >
  <!ENTITY % TEI.dictionaries 'INCLUDE' >
  ]>

<body>
    <div0 type='dictionary'>
	<!-- English-espaÃ±ol -->
	<entry>
	    <form type="abbrev">
		<orth>A</orth>
	    </form>
	    <form type="full">
	        <lbl>abbreviation for</lbl>
		    <orth>AmpÃ¨re</orth>
	        <trans>
		    <tr>A</tr>
		</trans>
	    </form>
	</entry>

	<entry>
	    <form>
		<orth>AmpÃ¨re</orth>
	    </form>
	    <gramGrp>
		<pos>n</pos>
	    </gramGrp>
	    <def></def>
	    <trans>
		<tr>Amperio</tr>
		<gen>m</gen>
	    </trans>
	</entry>

	<entry>
	    <form type="abbrev">
		<orth>APL</orth>
	    </form>
	    <form type="full">
	        <lbl>abbreviation for</lbl>
		    <orth>A Programming Language</orth>
	        <trans>
		    <tr>APL</tr>
		</trans>
	    </form>
	</entry>

	<entry>
	    <form>
		<orth>A Programming Language</orth>
	    </form>
	    <gramGrp>
		<pos>n</pos>
	    </gramGrp>
	    <def>
		APL es la sigla de "A Programming Language" (Un Lenguaje de 
		ProgramaciÃ³n), que fue un libro escrito en 1962 por el credor del 
		lenguaje, Kenneth E. Iverson. Basado en lo que antes se habÃ­a conocido 
		como la Nomenclatura Iverson, el APL es un lenguaje de programaciÃ³n 
		extremadamente conciso, diseÃ±ado para el manejo de los arreglos 
		(arrays). Los arreglos pueden ser escalares, vectoriales, tablas o 
		matrices de dos o mÃ¡s dimensiones, pudiendo estar compuestos de 
		informaciÃ³n numÃ©rica o alfanumÃ©rica. Bajo la conducciÃ³n de Iverson, 
		IBM introdujo en 1966 el APL\360.
		Como el APL evita la introducciÃ³n de las computadoras personales, 
		originalmente se lo empleÃ³ unicamente en mainframes. Desde 1983, han 
		estado disponibles las versiones de APL para las PC. Debido a su 
		conjunto de caracteres especiales expandidos, el APL requiere un 
		teclado especial, o el uso de macros, para el ingreso de datos.
		Las versiones actuales de APL para mainframes y PC se denominan
		APL2.
	    </def>
	    <trans>
		<tr>Lenguaje de ProgramaciÃ³n APL</tr>
		<gen>m</gen>
	    </trans>
	</entry>
  </div0>
</body>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%% acaba ejemplo.tei.xml -->
]]>
</programlisting>

	<para>
	  ¿Cómo convertir esta fuente en un documento
	  distribuible? Utilizaremos 
	  <application>lib-saxon-java</application>, 
	  <application>passivetex</application> y las
	  hojas de estilo XSL creadas por Sebastian Rahtz
	  (<ulink url="http://www.tei-c.org/Stylesheets/teixsl.html">
	    http://www.tei-c.org/Stylesheets/teixsl.html</ulink>). 
	  Lo siguiente
	  depende de la instalación de cada uno; yo utilizo en estos
	  momentos una Debian Sarge. Passivetex es un paquete
	  <foreignphrase>apt-gettable</foreignphrase>; 
	  descargo las DTD's TEI y las hojas de estilo
	  y las instalo en 
	  <filename class="directory">/usr/local/share/sgml/tei/</filename> 
	</para>

	<para>
	  La conversión a fichero .pdf me da errores; teóricamente
	  se haría
	</para>

	<para>
<programlisting>
java -classpath /usr/share/java/saxon.jar \
com.icl.saxon.StyleSheet -o ejemplo.tei.fo ejemplo.tei.xml \
/usr/local/share/sgml/tei/xsl/fo/tei.xsl

pdfxmltex ejemplo.tei.fo 

pdfxmltex ejemplo.tei.fo
</programlisting>
	</para>

	<para>
	  Para generar el fichero
	  <filename>ejemplo.resultado.html</filename>
	</para>

	<para>
<programlisting>
java -classpath /usr/share/java/saxon.jar \
com.icl.saxon.StyleSheet ejemplo.tei.xml \
/usr/local/share/sgml/tei/xsl/html/teihtml.xsl
</programlisting>
	</para>

	<para>Este es el fichero generado:</para>

<programlisting>
<![CDATA[
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%% empieza ejemplo.resultado.html -->
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html
  PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<div class="teidiv">
   <h2><a name="ej.utf8-div0-d0e3"></a>1. 
   </h2>
   	
   	
   	    
   		A
   	    
   	    
   	        abbreviation for
   		    Amp&egrave;re
   	        
   		    A
   		
   	    
   	
   
   	
   	    
   		Amp&egrave;re
   	    
   	    
   		n
   	    
   	    
   	    
   		Amperio
   		m
   	    
   	
   
   	
   	    
   		APL
   	    
   	    
   	        abbreviation for
   		    A Programming Language
   	        
   		    APL
   		
   	    
   	
   
   	
   	    
   		A Programming Language
   	    
   	    
   		n
   	    
   	    
   		APL es la sigla de "A Programming Language" (Un Lenguaje de 
   		Programaci&oacute;n), que fue un libro escrito en 1962 por el credor del 
   		lenguaje, Kenneth E. Iverson. Basado en lo que antes se hab&iacute;a conocido 
   		como la Nomenclatura Iverson, el APL es un lenguaje de programaci&oacute;n 
   		extremadamente conciso, dise&ntilde;ado para el manejo de los arreglos 
   		(arrays). Los arreglos pueden ser escalares, vectoriales, tablas o 
   		matrices de dos o m&aacute;s dimensiones, pudiendo estar compuestos de 
   		informaci&oacute;n num&eacute;rica o alfanum&eacute;rica. Bajo la conducci&oacute;n de Iverson, 
   		IBM introdujo en 1966 el APL\360.
   		Como el APL evita la introducci&oacute;n de las computadoras personales, 
   		originalmente se lo emple&oacute; unicamente en mainframes. Desde 1983, han 
   		estado disponibles las versiones de APL para las PC. Debido a su 
   		conjunto de caracteres especiales expandidos, el APL requiere un 
   		teclado especial, o el uso de macros, para el ingreso de datos.
   		Las versiones actuales de APL para mainframes y PC se denominan
   		APL2.
   	    
   	    
   		Lenguaje de Programaci&oacute;n APL
   		m
   	    
   	
     
</div>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%% acaba ejemplo.resultado.html -->
]]>
</programlisting>

      </sect3>
    </sect2>

    <!-- %%%%%%%%%% -->
    <sect2 id="sec_correctores_ortograficos">
      <title>Correctores ortográficos</title>

      <para>
	Tema relacionado con el de los diccionarios en tanto que
	listas de palabras.
      </para>

      <para>
        «Nuestro» proyecto es el 
	<emphasis>COES</emphasis>: Herramientas para
        Procesamiento de Lenguaje Natural en Español
        (<ulink url="http://www.datsi.fi.upm.es/~coes/">
	http://www.datsi.fi.upm.es/~coes/</ulink>), de 
	Santiago Rodríguez &amp;
        Jesús Carretero, que se distribuye como software de libre
        disposición desde finales de 1994.
      </para>

      <para>
        COES consta de un diccionario de unos 53.000 términos y un
        corrector ortográfico integrado en la utilidad Unix 
	<application>ispell</application> y desarrollos derivados
	(<application>aspell</application>). 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.
      </para>

      <para>
        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 &mdash; acabaremos necesitando un mínimo
        análisis morfológico y sintáctico.
      </para>

    </sect2>

    <!-- %%%%%%%%%% -->
    <sect2 id="sec_correctores_ortotipograficos">
      <title>Correctores ortotipográficos</title>

      <para>
	Estudiar la implementación de OpenOffice.
      </para>
    </sect2>


    <!-- %%%%%%%%%% -->
    <sect2 id="sec_terminologia">
      <title>
	    Terminologías y herramientas de gestión terminológica 
	(<acronym>TMS</acronym>)
      </title>

      <!-- %%% -->
      <sect3 id="sec_terminologia_o_mt">
	<title>¿Terminología o Memorias de traducción?</title>

	<para>
	  Discutido en
	  <ulink
	    url="http://www.lisa.org/sigs/phpBB/viewtopic.php?topic=22&amp;forum=1&amp;4">
	    http://www.lisa.org/sigs/phpBB/viewtopic.php?topic=22&amp;forum=1&amp;4
	  </ulink>
	</para>

	<para>Responde Kara Warburton: </para>
	<blockquote>
	  <para>
	    There are many differences between Terminology and 
	    Translation Memory. The first that comes to mind is 
	    that terminology management must occur in the source
	    language to ensure high quality source texts before a
	    translation memory even exists. Inconsistency and
	    inappropriate terms in the source language is an
	    increasing and costly problem especially for global
	    companies. And if the inconsistency is unchecked, then
	    it breaks the TM &mdash; there will be no match with
	    previous texts which are &quot;supposed&quot; to be the
	    same. A second difference is that terminology management
	    can document features of words in a much more granular
	    fashion than translation memory which only records
	    strings of text. Definitions, contexts, usage notes,
	    references to related terms, and so forth can assist
	    translators to select an appropriate target term when
	    the TM does not suggest one. And if there is an exact TM
	    match, what if the meaning is different which can
	    frequently occur)? Then the TM match is incorrect and
	    the translator has to think more carefully about the
	    terms. In this case, having a terminology system can
	    provide the translator with the required information to
	    correct the TM. In addition, grammatical information can
	    be recorded which can provide data to more advanced
	    systems down the road, such as search engines and
	    machine translation engines.
	  </para>
	</blockquote>

	<para>
	  Ingrid Haussteiner lo confirma: 
	  <blockquote>
	    <para>
	      I think your question is very interesting and I
	      think from a translator's perspective this is not an
	      either-or thing but rather a question of many ifs.
	    </para>

	    <para>
	      If you can choose, I would implement a terminology 
	      management system first, have people test and hone their
	      discipline and raise their awareness of the
	      difficulties involved in using consistent terminology
	      (even more so if it is multilingual), analyzing
	      choices and making suggestions 
	      (descriptive terminology work).
	    </para> 
	    <para>
	      If you implement a translation memory system after
	      some time, you might see that people slack off a bit
	      as far as terminology work is concerned. The big
	      argument is that the TM system integrates with the
	      TMS.
	    </para> 
	    <para>
	      You most certainly know that EBMT (Example-Based
	      Machine Translation) seems to be one of the buzzwords
	      in the industry. Some translation software already support
	      something like &quot;assembling&quot;, others are keen
	      to do so. So, in the future, when working with TM
	      technology, it will be an invaluable asset to have
	      quality terminology as the TM also assembles from
	      there where it finds no exact or fuzzy matches.
	    </para>
	  </blockquote>
	</para>

	<para>
	  Mark D. Childress remacha: 
	  <blockquote>
	    <para>
	      I've heard this discussion at a conference or two
	      recently. It seems to me all terminologists shudder at
	      the thought but some have problems communicating why the
	      sole use of translation memories is Not A Good Thing,
	      whereas their use together with term databases is.
	    </para>
	    <para>
	      The simplest way to explain to those people not
	      familiar with either, but who make the decisions
	      whether to support terminology management or not:
	    </para> 

	    <itemizedlist>
	      <listitem>
		<para>
		  Translation memory: Descriptive &mdash; The way
		  things are
		</para>
	      </listitem>

	      <listitem>
		<para>
		  Terminology database: Prescriptive &mdash; The way
		  things should be
		</para>
	      </listitem>
	    </itemizedlist>

	    <para>
	      Then ask them: Should one use a term that is
	      (potentially) incorrect, simply because that's the way
	      it is? Because if that's so, a term use error
	      continues to multiply because there's no prescriptive
	      ruling to use as a reference to standardize the
	      term. As Kara mentioned in her post, it will
	      ultimately make the translation memory useless.
	    </para>

	    <para>
	      Alternately, one can correct the problem each time it
	      appears in &quot;reality&quot; and count the cost of
	      correction, whereas defining the &quot;ideal&quot;
	      goes a long way towards reducing the occurrence of the
	      problem to begin with. Basic quality rule: Get it
	      right the first time, and reduce your follow-on costs.
	    </para>
	  </blockquote>
	</para>

      </sect3>


      <!-- %%% -->
      <sect3 id="sec_terminologia_propuesta">
	<title>Propuesta</title>

	<para>
	  El tema es complicado. Si tenemos problemas para terminar
	  un diccionario, ¿podemos ponernos a soñar en bases de
	  datos terminológicos? 
	  Cuando las herramientas estén maduras (pienso en los
	  desarrollos deseables de gtranslator y kbabel) implementar
	  bases de datos terminológicos en OLIF2 o TBX.
	</para>
      </sect3>
    </sect2>


    <!-- %%%%%%%%%% -->
    <sect2 id="sec_correctores_gramaticales">
      <title>Correctores gramaticales y de estilo</title>

      <para>
	¿Tengo que explicar que un corrector gramatical 
	necesita una gramática?
      </para>

      <para>
	Estudiar <emphasis><application>diction</application></emphasis>. 
	Aplicarlo al español.
      </para>

    </sect2>

    <!-- %%%%%%%%%% -->
    <sect2 id="sec_corpora_mono"><title>Corpora monolingües</title>

      <!-- %%% -->
      <sect3 id="section_corpora_mono_discusion"><title>Discusión</title>

	<para>
	  Según Catherine Ball
	  (<ulink url="http://www.georgetown.edu/cball/corpora/">
	    http://www.georgetown.edu/cball/corpora/</ulink>):
	</para>
	<blockquote>
	  <para>
	    To create a rudimentary <emphasis>concordancer</emphasis> 
	    is a simple
	    programming task: it is a matter of indexing words to
	    lines, sorting the words alphabetically, and displaying
	    each word in a fixed amount of context. However, most of
	    the generally-available concordancers have many additional
	    features, including options for producing full or partial
	    concordances, sorting in a variety of orders, searching
	    for collocations, and producing basic text statistics.
	  </para>
	</blockquote>


      </sect3>

      <!-- %%% -->
      <sect3 id="sec_corpora_mono_propuesta"><title>Propuesta</title>

	<orderedlist>
	  <listitem>
	    <para>
	      <emphasis>Herramientas estadísticas</emphasis>. 
	      Como traductor opino que necesitamos concordancias, 
	      colocaciones, 
	      análisis de patrones léxicos y agrupaciones de palabras
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      <emphasis>Anotaciones</emphasis>. Mediante 
	      etiquetado XCES si pretendemos
	      avanzar en el campo de la traducción automática.
	      Desarrollar/liberar herramientas de desambiguación
	    </para>
	  </listitem>
	</orderedlist>

      </sect3>
    </sect2>

    <!-- %%%%%%%%%% -->
    <sect2 id="sec_corpora_multi">
      <title>Corpora paralelos y multilingües</title>

      <!-- %%% -->
      <sect3 id="section_corpora_multi_discusion">
	<title>Discusión</title>

	<para>
	  Es evidente el interés de estas herramientas. Condiciones
	  previas son
	</para>

	<orderedlist>
	  <listitem>
	    <para>la <emphasis>segmentación</emphasis> y</para>
	  </listitem>

	  <listitem>
	    <para>
	      el <emphasis>alineado</emphasis> de los textos paralelos, 
	      en una primera fase a nivel de párrafo (insuficiente)
	    </para>
	  </listitem>
	</orderedlist>

	<itemizedlist>
	  <listitem>
	    <para>
	      WA Gale y KW Church sientan las bases teóricas
	      (estadísticas) sobre el alineado de texto en 
	      <citetitle pubwork="article">A Program
	      for Aligning Sentences in Bilingual Corpora</citetitle>, 
	      de 1993 
	      (<ulink url="http://citeseer.nj.nec.com/gale93program.html">
	      http://citeseer.nj.nec.com/gale93program.html</ulink>; el
	      documento incluye la fuente del programa)
	    </para>
	  </listitem>

	  <listitem>
	    <para>Aportaciones del proyecto MULTEXT</para>
	  </listitem>

	  <listitem>
	    <para>
	      Desarrollos matemáticos a la última que escapan a mi
	      comprensión actual,
	    </para>

	    <para>
	      en las páginas de Dan Melamed
	      (<ulink
	      url="http://www.cs.nyu.edu/~melamed/interests.html">
		http://www.cs.nyu.edu/~melamed/interests.html</ulink>)
	    </para>
	  </listitem>
	</itemizedlist>

	<para>
	  Melamed ha creado también gran número de utilidades libres.
	</para>

      </sect3>

      <!-- %%% -->
      <sect3 id="sec_corpora_multi_propuesta"><title>Propuesta</title>

	<para>
	  Segmentación y alineado a nivel de párrafo están 
	  favorecidos por el marcado DocBook de nuestros documentos.
	</para>

	<para>
	  Si logramos resolver el tema del alineado de textos por
	  otras vías en las TM no es prioritario el trabajo en este
	  campo (pero dicen los profesionales que el alineado a
	  nivel de párrafo no es suficiente).
	</para>

      </sect3>
    </sect2>



    <!-- %%%%%%%%%% -->
    <sect2 id="sec_memorias"><title>Memorias de traducción</title>

      <!-- %%% -->
      <sect3 id="section_memorias_discusion"><title>Discusión</title>

	<para>
	  Las TM contribuyen a la calidad de las traducciones en dos
	  aspectos: su coherencia y su exactitud.
	</para>
      </sect3>

      <!-- %%% -->
    <sect3 id="sec_memorias_propuesta"><title>Propuesta</title>

	<para>
	  gtranslator y kbabel utilizan de forma natural MT cuando
	  trabajan con ficheros .po.
	</para>

	<para>
	  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.
	</para>

	<para>
	  Ambos proyectos deben trabajar (o al menos ser capaces de
	  importar y exportar) el formato <acronym>TMX</acronym>.
	</para>

      </sect3>
    </sect2>

  </sect1>
</article>

<!-- 
Local variables:
mode: xml
encoding: iso8859-1
End: 
-->
