C O NST R UC CI ÓN D E BLOQ UES B ÁS IC OS PA R A

T R AD U CTO RES EN HER R A MIE NTA S TA O /T PO

Durante los años 70 y 80, la investigación llevada a cabo en el campo de la

traducción automática (TA) se centró en el desarrollo de los denominados sistemas de

«segunda generación». Estos sistemas trataban de traducir el texto mediante un

procesado lingüístico basado en reglas dividido en tres fases: análisis sintáctico-

semántico del texto fuente, transferencia bilingüe a un nivel de representación de mayor

o menor abstracción y la generación del texto meta a partir de la representación

sintáctica. Durante ese mismo período, desde un punto de vista práctico, surgieron

muchos debates que trataban de dilucidar cómo los sistemas diseñados con esta

arquitectura podrían utilizarse para proporcionar una traducción razonablemente

aceptable y que pudiese ser utilizada por usuarios reales. Una mayor acogida tuvieron

otras propuestas que pretendían bien restringir la entrada (enfoques basados en

sublenguajes y lenguajes controlados), bien involucrar al usuario en las fases de pre- y

postedición. Asimismo, se abogó por lo que se conoce como TA interactiva, donde el

usuario y la máquina cooperarían a la hora de tomar decisiones y resolver casos de

ambigüedad.

A comienzos de los años 90, con todas estas propuestas e ideas bien asentadas, e incluso

empezando a quedar anticuadas, la investigación en TA sufrió un golpe con el apogeo

de un nuevo paradigma donde, en especial, la dependencia en sistemas basados en

reglas lingüísticas iba a ser reemplazada (al menos parcialmente) por el uso de un

corpus de ejemplos ya traducidos, que el sistema de TA utilizaría como modelos en los

que basar nuevas traducciones. Este enfoque al que se denominó «traducción automática

basada en ejemplos» (Example-Based MT, EBMT) había sido propuesto por primera

vez diez años antes, en 1981.

Aproximadamente por esa misma fecha, algunos diseñadores de sistemas empezaron

a hablar de una nueva herramienta diseñada para los traductores. Al igual que en la

EBMT, esta herramienta se servía de un corpus de ejemplos previamente traducidos,

que serían utilizados como modelos para la nueva traducción. Sin embargo, en este caso

eran los propios usuarios, y no la máquina, quienes debían determinar con exactitud

cómo hacer uso de estos ejemplos a la hora de generar una nueva traducción. Esta

herramienta está ahora ampliamente reconocida con el nombre de sistema de memoria

de traducción (Translation Memory System, TMS).

Existe una tendencia generalizada a considerar que la EBMT y los TMSs son una

misma cosa y, de hecho, algunos de los logros conseguidos en ambos enfoques han

producido un acercamiento entre ambos. No obstante, es preciso reconocer que existen

ciertas similitudes, y que el énfasis por perfeccionar los TMSs hace que éstos se ase-

mejen cada vez más a los sistemas basados en la EBMT.

La idea original de una memoria de traducción suele atribuirse a Martin Kay, tal y

como se recoge en su famoso artículo «Proper Place» (1980), si bien los detalles son

sugeridos de una manera indirecta:

Curiosamente, Kay mostró cierto pesimismo en sus ideas, llegando a afirmar que su

Translator's Amanuensis no sería implementado. Sin embargo, las observaciones de

Kay habían sido apuntadas con anterioridad por Peter Arthern (1978), quien sugirió la

idea de que los traductores podían beneficiarse de un acceso en línea a documentos

similares ya traducidos. En un segundo artículo, las propuestas de Arthern recogen ya

claramente la idea de lo que hoy se conoce como un sistema de memoria de traducción

(TMS):

Alan Melby (1995: 225 y sigs.), por su parte, sugiere que la idea podría haberse

originado dentro de su grupo de investigación de la universidad Brigham Young (BYU)

allá por los años 70. Lo que sabemos con certeza es que la idea se incorporó, de una

forma muy limitada, alrededor del año 1981 en ALPS, uno de los primeros TMSs

disponibles en el mercado y desarrollados por el personal de BYU. Esta herramienta,

denominada Repetitions Processing, se limitaba a encontrar equivalencias exactas de

cadenas de caracteres alfanuméricas con la función módulo. El nombre mucho más

original de memoria de traducción no parece haberse utilizado hasta mucho después.

Los primeros TMSs realmente implementados, con la excepción de la bastante

inflexible herramienta ALPS, parecen haber sido la herramienta ETOC (Easy TO

Consult) de Sumita y Tsutsumi (1988) y el Bilingual Knowledge Bank de Sadler y

Vendelman (1990), predatando así al trabajo realizado en alineación de corpus, lo cual,

de acuerdo con Hutchins (1998), constituía un prerrequisito para implementar de una

manera eficiente la idea de una memoria de traducción. Asimismo, Kugler et al. (1991)

analizan el trabajo en este campo realizado por Keck (1989), quien explota los métodos

estadísticos en el contexto de un proyecto de investigación ESPRIT. Resulta difícil

señalar el momento en el que los investigadores dedicados a los estudios de traducción

y los traductores en general tomaron conciencia plena de los TMSs. Brian Harris, quien

introdujo la noción de «bi-texto» en una revista de traductores, propone algo parecido a

una memoria de traducción, pero sin llegar a utilizar dicho término (Harris, 1988: 9):

una base de datos de traducciones emparejadas, que puede consultarse bien utilizando

palabras aisladas, bien utilizando «una unidad de traducción completa», en cuyo caso se

recuperarían más unidades similares que idénticas. Cave (1988) respondió a ese artículo

con el anuncio de que Logos estaba ya lanzando al mercado dicho producto. En un

artículo sin firmar, publicado en 1991, la revista Language International anunciaba que

los «bancos de texto» acababan de efectuar su aparición:

El artículo va más allá y explica la noción de «fuzzymatch» (sic), haciendo

referencia a aquellos casos en los que no se encuentra una equivalencia exacta.

Las actas representativas de la conferencia anual de Aslib de la serie Translating and

the Computer no se hacen eco de las memorias de traducción hasta 1992, año en el que

aparecen tres artículos distintos aludiendo a las mismas (Freibott, 1992; Le-Hong, et al.,

1992; Svanholm, 1992), en uno de los casos (Le-Hong, et al.) sin siquiera sentir la

necesidad de definir el término. Brace (1992) anunciaba el desarrollo de una

herramienta de memoria de traducción desarrollada por Trados, al igual que se hacía

dentro del marco del proyecto ESPRIT, mencionado anteriormente, y los proyectos de

IBM «European Language Services» (Dinamarca) y «the Official Languages and

Translation sector of the Canadian Department of the Secretary of State» en Ottawa.

La idea de la EBMT comparte una cronología similar, con las primeras ideas surgiendo

a principios de los años 80 (el artículo presentado por Makoto Nagao en una conferencia

de 1981 no se publicó hasta tres años más tarde -Nagao, 1984). Sin embargo, los

primeros descubrimientos no empezaron a citarse hasta los años 90. La esencia de la

EBMT, denominada «machine translation by example-guided inference, or machine

translation by the analogy principie» según Nagao, queda recogida de una manera

sucinta en su ampliamente citada declaración:

Nagao identificó correctamente los tres componentes fundamentales de la EBMT:

comparación de fragmentos con una base de datos de ejemplos reales, identificación de

los fragmentos de traducción correspondientes y una posterior recombinación de

fragmentos para generar el texto meta. La EBMT conlleva claramente dos pasos

importantes y difíciles más allá de la tarea de producir emparejamientos que comparte

con los TMSs.

La idea de la EBMT despegó realmente a principios de los años 90, al producirse un

aumento significativo en la presentación de artículos para congresos que hacían

referencia a este enfoque. Los pioneros se ubicaban principalmente en Japón,

incluyendo Sato y Nagao (1990) y Sumita et al. (1990). Es preciso mencionar a su vez,

la labor realizada por el grupo DLT en Utrecht, a menudo ignorado en los foros de

discusión en torno a la EBMT, pero que datan aproximadamente de la misma época que

el trabajo de Nagao (y probablemente sin el conocimiento de dicho trabajo). La técnica

de equivalencias propuesta por Nagao conlleva medir la proximidad semántica de las

palabras, utilizando para ello un tesauro. Una idea similar es la que propone DLT con su

Linguistic Knowledge Bank constituido por frases ejemplo, recogida en Pappegaaij et al.

(1986a,b) y Schubert (1986:137 y sigs.). El Bilingual Knowledge Bank de Sadler (1991)

se engloba claramente en el paradigma de la EBMT.

Durante este primer período, los investigadores en el campo utilizaron nombres

alternativos, tal vez con el propósito de aportar alguna diferencia crucial que

distinguiese sus propios enfoques: case-based (Collins and Cunningham, 1996),

analogy-based (Nagao, 1984), y experience-guided (Zhao and Tsujii, 1999) representan

algunos de los términos más utilizados. El primero de ellos recuerda algunas propuestas

dentro del campo del razonamiento automático conocidas como case-based reasoning

(Riesbeck y Schank, 1989), así como a otros enfoques relacionados. Otro término

utilizado es memory-based translation (Sato y Nagao, 1990; Kitano, 1993), uso que ha

debido de resultar clave para sugerir afinidades entre la EBMT y los TMSs.

La EBMT y los TMSs tienen en común el uso de una base de datos de traducciones

anteriores, «la memoria» o «la base de ejemplos» así como el primer paso básico que

ambas han de llevar a cabo y que consiste en que, dado un fragmento de texto a traducir,

se ha de encontrar o localizar en la base de datos la(s) mejor(es) equivalencia(s) para ese

texto. Una vez hallada la equivalencia, las dos técnicas empiezan a divergir. Sin

embargo, sería incorrecto asumir que lo único que ambos métodos tienen en común es

la técnica empleada para localizar equivalencias, o incluso que los enfoques para es-

tablecer las equivalencias en ambos campos son muy parecidos. La utilización de una

base de datos conlleva una serie de procesos que tienen que ver con el diseño, el

contenido y el mantenimiento de la base de datos y que han de ser considerados.

En los TMSs, la base de datos puede construirse de tres formas distintas. El método más

simple, aunque el más costoso, denominado Interactive translation por Bowker (2002:

108 s.) consiste en crear una memoria de traducción desde cero, es decir, se trata de ir

almacenando en la memoria cada segmento o unidad de traducción a medida que se va

traduciendo. El segundo método, muy respaldado por los diseñadores de sistemas, al

que Bowker (2002: 109) se refiere como post-translation alignment, consiste en extraer

la memoria de traducción a partir de textos previamente traducidos, proceso que

conllevaría la alineación de los textos fuente y meta, tarea que puede resultar bastante

fastidiosa (cf. Macdonald, 2001). La abundante literatura en el tema describe los

distintos métodos de alineación, que varían en grado de sofisti-cación (lingüística) (cf.

Manning y Schütze, 1999: 466-486 o Wu, 2000a). O'Brien, por su parte, concluye:

Finalmente nos podemos encontrar con memorias de traducción ya existentes, que

serían importadas por el sistema. El consenso entre los fabricantes a la hora de utilizar

un formato de intercambio de datos ha facilitado enormemente esta tarea, en especial

gracias al formato desarrollado por LISA (Localisation Industry Standards Association,

cf. Melby, 1998, 2000 y Topping, 2000), conocido como TMX {Translation Memory

Exchange).

Otro aspecto importante tiene que ver con el tamaño de la memoria de traducción.

La literatura especializada no dice mucho más al respecto que «cuanto mayor mejor»,

siempre y cuando el procesador lo permita. Bowker (2002: 108) aconseja que el tamaño

no debe ir nunca en detrimento de la organización, sugiriendo la creación de distintas

memorias para distintos campos temáticos o para distintos clientes, lo que evitaría

además la recuperación de falsas equivalencias provocadas por fenómenos como la

homonimia. Bowker añade lo siguiente:

Para Heyn (1998) una memoria de traducción «grande» debe oscilar entre 100.000 y un

millón de unidades de traducción, algo que es posible gracias a los últimos avances

tecnológicos.

Por su parte, la literatura relacionada con la EBMT describe los tamaños de las bases

de ejemplos oscilando en un margen más amplio, constituyendo la mayor base una de

aproximadamente 0,73 millones unidades de traducción y la más pequeña representada

por tan sólo 7 (cf. Somers, 1999: 120). Obviamente, los sistemas con bases de datos tan

pequeñas constituyen meros experimentos, mientras que los sistemas más serios

contendrán miles (más que cientos) de ejemplos.

Los manuales de los TMSs aconsejan revisar las bases de datos con cierta frecuencia

con el fin de eliminar ejemplos inútiles. Por inútiles se entiende «no utilizados», más

que ejemplos «engañosos» (cf. Heyn, 1998: 131). Resulta sencillo imaginar cómo un

TMS podría incorporar un método que midiese los ejemplos no utilizados, simplemente

contando el acceso a la base de datos. Para medir los ejemplos engañosos sería

necesario saber qué hace el traductor con la equivalencia propuesta por el sistema.

La idoneidad de los ejemplos en el contexto de la EBMT ha sido contemplada por

distintos investigadores. Nomiyama (1992) introduce el concepto de exceptional

examples, una idea desarrollada más tarde por Watanabe (1994). Según parece, se

consideran ejemplos de excepción aquellos que al ser utilizados inducen a un error. De

ahí que surja la necesidad de crear un término más sistemático.

Como es bien sabido, una misma frase puede traducirse de distintas formas dependiendo

de las circunstancias. Fenómenos como la anáfora, la elipsis o la variación estilística

contribuyen a ello. Así pues, ejemplos distintos pueden contemplarse como equivalentes

en cierto sentido. Por otro lado, el significado subyacente de una frase puede variar

dependiendo del contexto. Somers et al. (1990: 274) muestran cómo en una

conversación una expresión tan sencilla como OK puede ser traducida al japonés de

todas las siguientes formas: wakarimashita 'Comprendo', iidesu yo 'Estoy de acuerdo',

ijô desu 'cambiemos de tema'.

Otro aspecto que se debe considerar es el de la granularidad. Existe un equilibrio

entre la longitud y la similitud de los ejemplos. Mientras mayores sean las unidades de

traducción almacenadas como ejemplos, menor será la probabilidad de encontrar una

equivalencia exacta, y a su vez, mientras más pequeñas sean las unidades, mayor será la

probabilidad de que se produzca una ambigüedad (múltiples equivalencias creando

conflictos), que irá en detrimento de la calidad de la traducción propuesta. Nirenburg et

al. (1993: 48) hacen referencia a este problema como passage boundary friction and

incorrect chunking. La unidad de traducción más obvia e intuitiva para almacenar ejem-

plos, a juzgar por la mayoría de los TMSs y la EBMT resulta ser la oración, a pesar de

que existen indicios de lo contrario (Gerloff, 1987; McTait et al., 1999): los traductores

humanos procesan el texto en unidades sintácticas naturales y espontáneas naturally-

occurring syntactic units, existiendo poco procesamiento a nivel oracional «generally

there is very little processing at sentence level» (McTait et al., 1999). Según Bennett,

«there are good reasons for keeping the U[nit of] T[ranslation] (in the sense of

translation atom) in MT as small —and henee as manageable— as possible. Adopting a

larger UT may be less efficient, and is not guaranteed to improve translation quality.»

(Bennett, 1994: 18); el translation atom constituye el segmento más pequeño que puede

traducirse como un todo.

Tanto los TMSs como los sistemas basados en la EBMT podrían mejorarse si se

centrasen en ofrecer una visión más flexible de la unidad de equivalencia/traducción, así

como en explotar fragmentos de texto más pequeños que las oraciones (Cranias et al.,

1994: 100). En los TMSs esta idea está ya contemplada, en cierta medida, con las

búsquedas terminológicas que forman parte integral de la herramienta, a pesar de que en

la mayoría de los casos las herramientas de terminología se implementan siguiendo un

método basado más en el léxico que en la memoria.

De acuerdo con Bowker,

En la misma línea, Esselink (2000: 362 y ss.) concluye:

En los TMSs, los ejemplos se almacenan principalmente en forma de texto sencillo, a

veces con alguna otra información relacionada con el formato. Los sistemas se

distinguen entre sí a la hora de tratar las características de formato (es decir, los tipos de

letra, las mayúsculas/minúsculas, etc.), información que resulta potencialmente útil

cuando se establecen equivalencias (veáse a continuación). Austermühl (2002: 138)

comenta que

De lo que se deduce que los segmentos siempre mantienen sus características de

formato cuando se almacenan.

Otra cuestión tiene que ver con la manera en que los TMSs tratan las marcas de

etiquetado y otros tipos de formato. En la actualidad, las herramientas de ayuda a la

traducción están cobrando relevancia en la industria de la localización. Por este motivo,

la nueva generación de TMSs, entre los que destacan Trados, Transit y Deja Vu, viene

equipada con una amplia gama de filtros que permiten convertir archivos de un formato

a otro. A su vez, los TMSs se diseñan para soportar todo tipo de formatos. Esselink

exponía lo siguiente en el año 2000:

Las últimas versiones que han aparecido en el mercado en el año 2003 han ampliado

significativamente el número de filtros que incorporan sus sistemas, de manera que

cualquier tipo de documento, ya sea una página web, una presentación o un archivo

gráfico, pueda ser importado en una memoria de traducción. Así, Transit XV incorpora

toda una gama de filtros para tratar cualquier tipo de archivo de texto, así como los

formatos de archivos generados con programas como Excel, Powerpoint, QuarkXPress,

PageMaker, FrontMaker y AutoCAD, entre otros. Las últimas soluciones presentadas en

el mercado por las marcas Trados y Déjá Vu, Trados 6.5 y DéjáVu X respectivamente,

vienen igualmente equipadas con filtros que permiten que las memorias de traducción

puedan importar y exportar archivos con cualquier tipo de formato.

Progresivamente, los diseñadores de TMSs están adquiriendo conciencia de la

necesidad de incorporar anotaciones (mark-ups) en sus sistemas. Se trata de incluir no

sólo características de formato, sino también anotaciones lingüísticas como son las

etiquetas de las partes del discurso (part-of-speech tags). En este sentido, Planas (1999:

8) afirma que su sistema, Xerox XMS Memory Manager, es una herramienta

lingüísticamente motivada, y que, por consiguiente, es capaz de recuperar mejores

equivalencias que los sistemas basados en caracteres. Para Planas, esto viene a

confirmar el papel tan importante que desempeña la información lingüística en la

recuperación de equivalencias aproximadas (fuzzy matches) de una base de datos «this

shows the crucial importance of using linguistic data for enabling more precise retrieval

of the closest sentence in the datábase». Sin embargo, su sistema se encuentra aún en

una fase experimental. Planas y Furuse (1999) proponen una estrategia más elaborada,

donde los ejemplos se representan en un retículo de múltiples niveles, que combina

información tipográfica, ortográfica, léxica y sintáctica, entre otras.

A pesar de las ventajas que supone incorporar información lingüística en una

memoria de traducción para recuperar las mejores equivalencias, los sistemas más

comerciales no incorporan aún anotaciones de este tipo en sus programas.

Obviamente, los métodos utilizados para almacenar y buscar equivalencias están

relacionados intrínsecamente.

Por su parte, los sistemas basados en la EBMT han propuesto muchos formatos para

almacenar ejemplos. Teniendo en cuenta sus orígenes, una variedad de TA basada en

reglas, los primeros sistemas de EBMT suponían que los ejemplos debían almacenarse

en forma de estructuras de árboles alineadas.

Desafortunadamente, este tipo de representación conlleva una serie de problemas

relacionados con el almacenamiento, el análisis durante la fase de procesamiento y la

comprobación de estructuras, una crítica que debe extenderse a la propuesta de Planas y

Furuse. La dependencia en el proceso de análisis u otros procesos complejos basados en

el conocimiento ha sido probada como una desventaja. Sin embargo, dada la recurrencia

de este tipo de representaciones en las primeras propuestas de sistemas de EBMT, suele

pensarse que constituyen una característica necesaria para el desarrollo de estos

sistemas, planteamiento harto incorrecto. Posteriores sistemas de EBMT proponen es-

quemas de representación menos ambiciosos, en concreto, texto superficialmente

anotado, donde las palabras están acompañadas de etiquetas correspondientes a las

partes del discurso y/o los resultados del proceso de lematización (es decir, análisis

morfológico para identificar la raíz e interpretar las terminaciones parcialmente).

La Traducción asistida por computadora puede ser tan sencilla como una única

herramienta que preste su apoyo para una única actividad de traducción, o tan compleja

como todo un entorno que abarque «herramientas», una base de datos, personas,

hardware, una red, sistemas operativos, estándares, y otros mil componentes más. Los

bloques de construcción de TAO podemos comprobarlos en la siguiente figura:

SCHEMA Bloque de herramientas TAO

(Fuente: M. Marcos sobre versión de R. S. Pressman Documentación e ingeniería para traductores, 2011:2)

Cada bloque de construcción forma el fundamento del siguiente, estando las

herramientas situadas en la parte superior de la pirámide. Es interesante tener en cuenta

que el fundamento de los entornos TAO efectivos tiene relativamente poco que ver con

las herramientas de ingeniería del software en sí. Más bien, los entornos para la TAO se

construyen con éxito sobre una arquitectura de entornos que abarca un hardware y un

software de sistema adecuados. Además, la arquitectura del entorno deberá tener en

cuenta los patrones dé trabajo humano que se aplicarán durante el proceso de ingeniería

de la Traducción.

Las arquitecturas del entorno, que constan de una plataforma hardware y de un

soporte de sistema operativo (incluyendo software de red, gestión de la base de datos y

servicios de gestión de objetos), establece los cimientos para un entorno TAO. Pero el

entorno TAO en sí requiere otros bloques de construcción. Existe un conjunto de

servicios de portabilidad que proporciona un puente entre las herramientas TAO, su

marco de integración y la arquitectura del entorno. El marco de integración es un grupo

de programas especializados que permiten a cada una de las herramientas comunicarse

entre sí, para crear una base de datos del proyecto, y para mostrar el mismo aspecto al

usuario final (el ingeniero del software). Los servicios de portabilidad permiten que las

herramientas TAO y su marco de integración migren entre distintas plataformas del

hardware y sistemas operativos sin un mantenimiento adaptativo significativo. (véase

como ejemplo las TL del OESI)

Los bloques de construcción representados en la Figura representan un fundamento

completo para la integración de herramientas TAO. Sin embargo, la mayor parte de las

herramientas TAO que se utilizan en la actualidad no han sido construidas empleando

todos los bloques de construcción anteriormente descritos. De hecho, algunas

herramientas siguen siendo las «soluciones puntuales». Esto es, una herramienta se

utiliza para prestar apoyo en una actividad de ingeniería de Traducción concreta (por

ejemplo, modelado de análisis terminológico o sistema de procesamiento del lenguaje

natural)), pero esta herramienta no se comunica directamente con otras, no está unida a

una base de datos del proyecto, y no forma parte de un entorno integrado TAO (I-

TAO/TPO)

Aunque esta situación no es la ideal, se puede utilizar una herramienta TAO bastante

eficiente, aunque se trate de una solicitud puntual.

Opciones no integradas (Fuente MM idem)

Opciones integradas (Fuente MM idem)

Los niveles relativos de integración TAO se muestran en la figura. En el extremo

inferior del espectro de integración se encuentra la herramienta individual (solución

puntual). Cuando las herramientas individuales proporcionan servicios para el

intercambio de datos (como lo hacen la mayoría), el nivel de integración mejora

ligeramente. Estas herramientas producen su salida en un formato estándar que deberá

ser compatible con otras herramientas que sean capaces de leer ese formato. En algunos

casos, los constructores de herramientas TAO /TPO complementarias trabajan juntos

para formar un puente entre herramientas (por ejemplo, una herramienta de análisis y

diseño que se enlaza con un generador de código y segmentación). Mediante la

utilización de este enfoque, la sinergia entre herramientas puede producir unos

resultados finales que serían difíciles de crear empleando cada una de las herramientas

por separado. La integración de fuente única se produce cuando un único vendedor de

herramientas TAO O TPO integra una cierta cantidad de herramientas distintas y las

vende en forma de paquete (véase SDL). Aunque este enfoque es bastante eficiente, la

arquitectura cerrada de la mayoría de los entornos de fuente única evita añadir

fácilmente herramientas procedentes de otros fabricantes.

En el extremo superior del espectro de integración se encuentra el entorno de apoyo

integrado a proyectos integrado (EAIP). Se han creado estándares en cada uno de los

bloques de construcción descritos anteriormente. Los fabricantes de herramientas TAO /

TPO utilizan los estándares EAIP para construir herramientas que sean compatibles con

el EAIP, y que por tanto sean compatibles entre sí.

Acceder a una memoria de traducción o base de ejemplos conlleva emparejar o

buscar una correspondencia o equivalencia entre una unidad de traducción nueva y

alguna de las unidades de traducción que han sido previamente almacenadas. Las

primeras implementaciones de TMSs sólo podían tratar casos de equivalencias exactas,

aunque también se permitían sustituciones alfanuméricas como éstas.

Bowker introduce la distinción entre una equivalencia exacta y una equivalencia

completa.

Los elementos variables o sustituibles (placeables) de Bowker han recibido distintas

etiquetas. Gaussier et al. (1992) los definen como transwords, mientras que

Macklovitch y Russell (2000) los denominan non-translatables. Por otra parte, nos

encontramos con el término named entities, tomado del campo de la recuperación de

información. Tal y como señalan Macklovitch y Russell, estas entidades son tratadas en

la traducción de una manera transparente, o bien porque no se traducen, o bien porque

están sujetas a unas convenciones específicas, y son, en cualquier caso, independientes

del contexto. Para un TMS los efectos de estos elementos variables son dobles. En un

primer nivel, deseamos que se produzcan emparejamientos que los ignoren, de manera

que sean recuperados como equivalencias exactas. A su vez, en un TMS más

sofisticado (así como en la EBMT), estas entidades constituyen elementos básicos en la

generación automática de posibles traducciones para un determinado texto.

Algunos TMSs defienden el uso de sofisticados algoritmos de emparejamiento

(Trados, por poner un ejemplo, reivindica el uso de redes neuronales) y Heyn alega que

Sin embargo, hasta el momento todos los indicios hacen pensar que el método más

empleado por los TMSs para hallar equivalencias se basa en una implementación directa

de la distancia de edición basada en caracteres (character-based edit distance), es decir,

la ampliamente conocida y empleada medida de similitud de una cadena que computa el

número mínimo de sustituciones, inserciones y eliminaciones que son necesarias para

convertir una cadena en otra.

Al igual que Planas y Furuse (1999) y Macklovitch y Russell (2000), Rapp (2002)

propone un nuevo mecanismo de búsqueda de equivalencias que tenga en cuenta

información de tipo sintáctico y/o semántico. El algoritmo de búsqueda de Rapp tiene

en cuenta la información que proporcionan las partes del discurso, con el objeto de

localizar equivalencias más coherentes. Cranias et al. (1997), por su parte, proponen un

modelo válido tanto para los TMSs como para la EBMT que explota el uso de las

palabras con contenido y las etiquetas de las partes del discurso, y que localiza lemas en

vez de cadenas.

Resulta interesante saber que en la EBMT siempre se asumió que los

emparejamientos se producirían siguiendo una técnica más elaborada o perfeccionada.

Las primeras propuestas (por ejemplo, Nagao, 1984; Sumita et al., 1990; Sumita y Iida,

1991) conllevaban el uso de un tesauro para medir la proximidad semántica de las

estructuras.

Otros diseñadores de sistemas basados en la EBMT (como Cranias et al., 1997) han

planteado la posibilidad de utilizar etiquetas de las partes del discurso o tratar las

palabras con contenido de un modo especial (Furuse y Iida 1994; Véale y Way 1997).

En el sistema de motor múltiple Pangloss, el proceso de emparejamiento «relaja» sus

requisitos progresivamente hasta que encuentra una equivalencia (Nirenburg et al.,

1993): el proceso comienza con una búsqueda de equivalencias exactas, a continuación

se permiten ciertas inserciones o eliminaciones, después diferencias en el orden de las

palabras, posteriormente variantes morfológicas y finalmente diferencias en las etique-

tas de las partes del discurso, cada relajación provocando una penalización mayor.

Chatterjee (2001) propone un modelo de evaluación donde una serie de rasgos, con

distintos valores, se combinan para dar una puntuación que refleja la equivalencia a

varios niveles: léxico, morfológico, sintáctico, semántico y pragmático. La fuerza de la

EBMT, especialmente para pares de lenguas muy diferentes, radica en el uso de

ejemplos con un significado similar, más que con una estructura similar, de manera que

los rasgos semánticos y pragmáticos, que todavía pueden rescatarse sobre la base de

sencillos rasgos morfosintácticos (por ejemplo, si el sujeto del verbo es animado)

reciben un porcentaje de peso muy significativo.

Las primeras propuestas de sistemas basados en la EBMT, y aquellas otras

propuestas que integran la EBMT dentro de un enfoque más tradicional de TA,

asumieron que los ejemplos se almacenarían en forma de estructura de objetos, proceso

que conlleva un emparejamiento arbóreo bastante más complejo (por ejemplo,

Maruyama y Watanabe, 1992; Matsumoto et al., 1993). Sin embargo, no existe mucho

debate acerca de la implementación de este procedimiento (cf. Maruyama y Watanabe,

1992; Al-Adhaileh y Tang, 1998). Además, este tipo de procesos conlleva un coste

computacional considerable, lo que probablemente representa un paso demasiado lejano

para los TMSs.

TAXONOMÍA DE HERRAMIENTAS

Existe un cierto número de riesgos que son inherentes siempre que se intenta efectuar

una categorización de las herramientas TAO. Existe una sutil implicación que consiste

en que para crear un entorno TAO/TPO efectivo se deberán implementar todas las

categorías de herramientas —esto no es ni sencillo, ni cierto—. Cuando hay personas

que creen que una herramienta pertenece a una categoría, se puede crear cierta

confusión (o contradicción) al ubicar una herramienta específica dentro de otra cate-

goría. Es posible que algunos lectores piensen que se ha omitido una categoría completa

—eliminando por tanto un conjunto de herramientas completo e incluirlo así en el

entorno TAO/TPO global—. Además, una categorización sencilla tiende a ser plana —

esto es, no se muestra la interacción jerárquica de las herramientas o las relaciones que

existen entre ellas—. A pesar de estos riesgos, es necesario crear una taxonomía de

herramientas TAO/TPO —para comprender mejor la amplitud de TAO/TPO y para

apreciar mejor en donde se pueden aplicar estas herramientas dentro del proceso del

software—.

Las herramientas TAO/TPO se pueden clasificar por su función, por su papel como

instrumentos para administradores o personal técnico, por su utilización en los distintos

pasos del proceso de ingeniería del software, por la arquitectura del entorno (hardware y

software) que les presta su apoyo, o incluso por su origen o coste. La taxonomía que se

presenta a continuación utiliza como criterio principal la función.

Herramientas de TAO/TPO de procesos de negocio. Al modelar los requisitos de

información estratégica de una organización, las herramientas de ingeniería de procesos

de negocios proporcionan un «metamodelo» del cual se derivan sistemas de

información específicos. En lugar de centrarse en los requisitos de una aplicación

específica, estas herramientas TAO/TPO modelan la información de negocio cuando

ésta se transfiere entre distintas entidades organizativas en el seno de una compañía. El

objetivo primordial de las herramientas de esta categoría consiste en representar objetos

de datos de negocio, sus relaciones y la forma en que fluyen estos objetos de datos entre

distintas zonas de negocio en el seno de la compañía.

Modelado de procesos y herramientas de gestión.

Si una agencia de traducción trabaja por mejorar un proceso de negocio (o de software)

lo primero que debe hacer es entenderlo. Las herramientas de modelado de procesos en

traducción o para la traducción (llamadas también herramientas de tecnología de pro-

cesos lingüísticos) se utilizan para representar los elementos clave del proceso de

manera que sea posible entenderlo mejor. Estas herramientas también pueden

proporcionar vínculos con descripciones de procesos que ayuden a quienes estén

implicados en el proceso de comprender las tareas que se requieren para llevar a cabo

ese proceso. Además, las herramientas de gestión de procesos pueden proporcionar

vínculos con otras herramientas que proporcionan un apoyo para las actividades de

proceso ya definidas.

Herramientas de planificación de proyectos.

Las herramientas de esta categoría se centran en dos áreas primordiales: estimación de

costes y de esfuerzos del proyecto de traducción y planificación de proyectos. Las

herramientas de estimación calculan el esfuerzo estimado, la duración del proyecto y el

número de personas recomendado para el proyecto. Las herramientas de planificación

de proyectos hacen posible que el gestor defina todas las tareas del proyecto (la

estructura de desglose de tareas), que cree una red de tareas (normalmente empleando

una entrada gráfica), que represente las interdependencias entre tareas y que modele la

cantidad de paralelismo que sea posible para ese proyecto.

Herramientas de análisis de riesgos.

La identificación de posibles riesgos y el desarrollo de un plan para mitigar,

monitorizar y gestionar esos riesgos tiene una importancia fundamental en los proyectos

grandes. Las herramientas de análisis de riesgos hacen posible que el gestor del

proyecto construya una tabla de riesgos proporcionando una guía detallada en la

identificación y análisis de riesgos.

Herramientas de gestión de proyectos.

La planificación del proyecto y el plan del proyecto deberán ser rastreados y

monitorizados de forma continua. Además, el gestor deberá utilizar las herramientas que

recojan métricas que en última instancia proporcionen una indicación de la calidad del

producto del software. Las herramientas de esta categoría suelen ser extensiones de

herramientas de planificación de proyectos.

Herramientas de seguimiento de requisitos.

Cuando se desarrollan grandes sistemas, las cosas «se derrumban». Es decir, el sistema

proporcionado suele no satisfacer los requisitos especificados por el cliente. El objetivo

de las herramientas de seguimiento es proporcionar) un enfoque sistemático para el

aislamiento de los requisitos, comenzando por el RFP del cliente o por la especificación.

Las herramientas típicas de seguimiento de requisitos combinan una evaluación de tex-

tos por interacción humana, con un sistema de gestión de bases de datos que almacena y

categoriza todos y cada uno de los requisitos del sistema que se «analizan» a partir de la

RFP o especificación original.

Herramientas de métricas y de gestión. Las métricas del software mejoran la

capacidad del gestor para controlar y coordinar el proceso de ingeniería del software y

la capacidad del ingeniero para mejorar la calidad del software que se produce. Las

métricas o herramientas de medidas actuales se centran en características de procesos y

productos. Las herramientas orientadas a la gestión se sirven de métricas específicas del

proyecto (por ejemplo, LDC/persona-mes, defectos por punto de función) que

proporcionan una indicación glo: bal de productividad o de calidad. Las herramientas

con orientación técnica determinan las métricas técnicas que proporcionan una mejor

visión de la calidad del diseño o del código.

Herramientas de documentación. Las herramientas de producción de documentos y

de autoedición pres tan su apoyo a casi todos los aspectos de la ingeniería del software,

y representan una importante oportunidad de «aprovechamiento» para todos los que

desarrollan software. La mayoría de las organizaciones dedicadas al desarrollo de

software invierten una cantidad de tiempo considerable en el desarrollo de documentos,

y en muchos casos el proceso de documentación en sí resulta bastante deficiente. Es

frecuente que una organización de desarrollo de software invierta en la documentación

hasta un 20 o un 30 por 100 de su esfuerzo global de desarrollo de software. Por esta

razón, las herramientas de documentación suponen una oportunidad importante para

mejorar la productividad.

Herramientas de software de sistema. TAO/TPO/TA es una tecnología de estaciones

de trabajo. Por tanto, el entorno TDTA deberá adaptarse a un software de sistema en red

de alta calidad, al correo electrónico, a los tablones de anuncios electrónicos y a otras

posibilidades de comunicarse.

Herramientas de control de calidad. La mayor parte de las herramientas

TAO/TPO/TA que afirman tener como principal interés el control de calidad son en rea-

lidad herramientas de métricas que hacen una auditoría del código fuente para

determinar si se ajusta o no a ciertos estándares del lenguaje. Otras herramientas extraen

métricas técnicas en un esfuerzo por extrapolar la calidad del software que se está

construyendo.

Herramientas de gestión de bases de datos. El software de gestión de bases de datos

sirve como fundamento para establecer una base de datos TAO/TPO/TA (repositorio),

que también se denominará base de datos del proyecto. Dada la importancia de los

objetos de configuración, las herramientas de gestión de bases de datos para

TAO/TPO/TA pueden evolucionar a partir de los sistemas de gestión de bases de datos

relaciónales (SGBDR) para transformarse en sistemas de gestión de bases de datos

orientadas a objetos (SGBDOO).

Herramientas de gestión de configuración de software. La gestión de configuración

de software (GCS) se encuentra en el núcleo de todos los entornos TAO/TPO/TA. Las

herramientas pueden ofrecer su asistencia en las cinco tareas principales de GCS —

identificación, control de versiones, control de cambios, auditoría y contabilidad de

estados—. La base de datos TAO/TPO/TA proporciona el mecanismo de identificar

todos los elementos de configuración y de relacionarlo con otros elementos; el proceso

de control de cambios se puede implementar con ayuda de las herramientas

especializadas; un acceso sencillo a los elementos de configuración individuales facilita

el proceso de auditoría; y las herramientas de comunicación TAO/TPO/TA pueden

mejorar enormemente la contabilidad de estados (ofreciendo información acerca de los

cambios a todos aquellos que necesiten conocerlos).

Herramientas de análisis y diseño. Las herramientas de análisis y diseño hacen

posible que el ingeniero del software cree modelos del sistema que vaya a construir. Los

modelos contienen una representación de los datos, función y comportamiento (en el

nivel de análisis), así como caracterizaciones del diseño de datos, de arquitectura, a

nivel de componentes e interfaz. Al efectuar una comprobación de consistencia y

validez de los modelos, las herramientas de análisis y diseño proporcionan al ingeniero

del software un cierto grado de visión en lo tocante a la representación del análisis, y le

ayudan a eliminar errores antes de que se propaguen al diseño, o lo que es peor, a la

propia implementación.

Herramientas PRO/SIM. Las herramientas PRO/SEVI (de construcción de prototipos

y simulación) proporcionan al Traductor la capacidad de predecir el comportamiento de

un sistema en tiempo real antes de llegar a construirlo. Además, también le capacitan

para desarrollar simulaciones del sistema de tiempo real, lo que permitirá que el cliente

obtenga ideas acerca de su funcionamiento, comportamiento y respuesta antes de la

verdadera implementación.

Herramientas de desarrollo y diseño de interfaz. Las herramientas de desarrollo y

diseño de interfaz son en realidad un conjunto de herramientas de componentes de pro-

gramas (clases) tales como menús, botones, estructuras de ventanas, iconos,

mecanismos de desplazamiento de la pantalla, controladores de dispositivos, etc. Sin

embargo, estos conjuntos de herramientas se están viendo sustituidos por herramientas

de construcción de prototipos de interfaz que permiten una rápida creación en pantalla

de interfaces de usuario sofisticadas, que se ajustan al estándar de interfaz que se haya

adoptado para el software.

Herramientas de construcción de prototipos. Se puede utilizar toda una gama de

herramientas de construcción de prototipos. Los generadores de pantallas permiten al

ingeniero del software definir rápidamente la disposición de la pantalla para

aplicaciones interactivas. Otras herramientas de prototipos TAO/TPO/TA más

sofisticadas permiten la creación de un diseño de datos, acompañado por diseños e

informes de la pantalla. Muchas herramientas de análisis y diseño son más extensas y

proporcionan opciones de construcción de prototipos. Las herramientas PRO/SIM

generan un diseño esquemático de código fuente en Ada y C para las aplicaciones de

ingeniería lingüística (en tiempo real). Por último, una gama amplia de herramientas de

cuarta generación poseen también características de construcción de prototipos.

Herramientas de programación. La categoría de herramientas de programación abarca

los compiladores, editores y depuradores disponibles para apoyar a la mayoría de los

lenguajes de programación convencionales todos ellos empleados en las TL y en las

memorias de traducción. Además, en esta categoría también residen los entornos de

programación orientados a objetos (00), los lenguajes de cuarta generación, los entornos

de programación gráfica, los generadores de aplicaciones y los lenguajes de consulta de

bases de datos.

Herramientas de desarrollo de Webs. Las actividades asociadas a la Localización

Web y al mercado de traducción actual están apoyadas por una variedad de

herramientas de desarrollo de WebApps. Entre estas herramientas se incluyen las que

prestan ayuda en la generación de texto, gráficos, formularios, guiones, applets y otros

elementos de una página Web.

Herramientas de integración y pruebas. En el directorio de herramientas de pruebas

de software del Software Quality Engineering Applied. Linguistic (SQEAL), se definen

las categorías de herramientas de pruebas siguientes:

adquisición de datos: herramientas que adquieren los datos que se utilizarán durante la

prueba;

medida estática: herramientas que analizan el código fuente sin ejecutar casos de prueba

medida dinámica: herramientas que analizan el código fuente durante la ejecución;

simulación: herramientas que simulan las funciones del hardware o de otros elementos

externos;

gestión de pruebas: herramientas que prestan su asistencia en la planificación,

desarrollo y control de las pruebas;

herramientas de funcionalidad cruzada: se trata de herramientas que atraviesan los

límites de las categorías anteriores.

Herramientas de procesamiento de lenguaje.

Lenguaje natural

Lenguaje especializado Herramientas adaptadas a la asimilación lingüística del lenguaje

ya sea de entorno natural o construido: Documentales, de especialización,

Terminológico, Corpus, etc.

Debería tenerse en cuenta que muchas de las herramientas de prueba poseen

características que abarcan dos categorías o más de las anteriormente mencionadas.

Herramientas de análisis estático. Las herramientas de análisis estático prestan su

asistencia al ingeniero del software a efectos de derivar casos prácticos. En la industria

se utilizan tres tipos distintos de herramientas estáticas de prueba: herramientas de

prueba basadas en código; lenguajes de prueba especializados y herramientas de prueba

basadas en requisitos. Las herramientas de prueba basadas en código admiten un

código fuente (o LDP) como entrada, y llevan a cabo varios análisis de los que se

obtiene la generación de casos de prueba. Los lenguajes de prueba especializados (por

ejemplo, ATLAS) hacen posible que el ingeniero del software escriba especificaciones

de prueba detalladas para describir todos los casos de prueba y la logística de su

ejecución. Las herramientas de prueba basadas en requisitos aíslan los requisitos del

usuario y sugieren los casos de prueba (o clases de prueba) que ejercitarán esos

requisitos.

Herramientas de análisis dinámico. Las herramientas de análisis dinámico

interactúan con el programa que se esté ejecutando, prueban la cobertura de rutas,

prueban las afirmaciones acerca del valor de variables específicas e instrumentan por

otro lado el flujo de ejecución del programa. Las herramientas dinámicas pueden ser

intrusivas, o no intrusivas. Las herramientas intrusivas modifican el software que hay

que comprobar mediante la inserción de sondas (instrucciones • adicionales) y que

efectúan las actividades mencionadas anteriormente. Las herramientas de prueba no

intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el

procesador que contiene el programa que se está probando.

Herramientas de gestión de pruebas. Las herramientas de gestión de pruebas se

utilizan para controlar y coordinar las pruebas del software por todos y cada uno de los

pasos principales de las pruebas. Las herramientas de esta categoría gestionan y

coordinan las pruebas de regresiones, efectúan comparaciones que determinan las

diferencias entre la salida real y la esperada y realizan pruebas por lotes de programas

con interfaces hombre-máquina interactivas. Además de las funciones indicadas

anteriormente, muchas herramientas de gestión de pruebas sirven también como

controladores de pruebas genéricos. Un controlador de pruebas lee uno o más casos de

prueba de algún archivo de pruebas, aplica formato a los datos de prueba para que se

ajusten a las necesidades del software que se está probando, e invoca entonces al

software que es preciso probar.

Herramientas de pruebas cliente/servidor. El entorno C/S exige unas herramientas

de pruebas especializadas que ejerciten la interfaz gráfica de usuario y los requisitos de

comunicaciones en red para el cliente y el servidor.

Herramientas de reingeniería. Las herramientas para el software heredado abarca

un conjunto de actividades de mantenimiento que actualmente absorben un porcentaje

significativo de todo el esfuerzo relacionado con el software. La categoría de

herramientas de reingeniería se puede subdividir en las funciones siguientes:

• herramientas de ingeniería inversa para producir especificaciones: se toma el

código fuente como entrada y se generan modelos gráficos de análisis y diseño

estructurados, listas de utilización y más información sobre el diseño;

• herramientas de reestructuración y análisis de código: se analiza la sintaxis del

programa, se genera una gráfica de control de flujo y se genera automáticamente un

programa estructurado; y

• herramientas de reingeniería para sistemas on-line: se utilizan para modificar

sistemas de bases de datos on-line (por ejemplo, para convertir archivos IDMS o

DB2 en un formato de entidades y relaciones).

Muchas de las herramientas anteriores se ven limitadas a lenguajes de programación

específicos (aunque abarcan la mayoría de los lenguajes principales) y requieren un

cierto grado de interacción con el ingeniero del software.