Da Tradução Automática à Tradução Assistida

Durante a última década do século XX começou a difundir-se a ideia de que a tradução automática, disciplina que tinha suscitado tantas esperanças, não conseguiria tornar-se o instrumento definitivo para a solução de problemas de comunicação entre diferentes línguas. As características da linguagem natural, num determinado momento da análise, convertiam-se em obstáculos invencíveis para o processamento automático; a ciência da engenharia linguística assumia que, para as traduções serem minimamente aceitáveis, era indispensável a intervenção do tradutor humano.

Como consequência desta percepção, iniciou-se a exploração nos diferentes campos mais desenvolvidos até ao momento. Em especial, o conceito da tradução automática foi derivando, em muitos grupos de trabalho, no conceito da tradução assistida por computador; já não se pretendia que o computador fizesse o trabalho todo, mas que facilitasse o trabalho do tradutor humano, o simplificasse e, ao mesmo tempo, o fortalecesse. Desta maneira, a tradução automática deu lugar ao modelo que mais se difundiu entre os tradutores dos últimos tempos e que mais esperanças concita para um futuro próximo: as Memórias de Tradução .

Memórias de tradução

A ideia em que se baseiam as Memórias de Tradução (em diante MT) é muito simples: trata-se de permitir a possibilidade de reutilizar e aproveitar as traduções já efectuadas pelo próprio tradutor ou por uma outra pessoa, para que sirvam como ajuda nos subsequentes projectos de tradução. Utilizando as MT, quando um tradutor tem de traduzir uma frase que já traduziu anteriormente, o programa que utiliza pode apresentá-la para que não precise de traduzi-la de novo, com o risco de perder a homogeneidade. A partir daqui abrem-se imensas possibilidades, que não detalharemos neste artigo.

Durante esta década foi surgindo um grande número de aplicações de gestão das MT. A IBM liderou durante algum tempo o mercado com o seu Translation Manager, mas essa posição foi logo superada pela Trados, uma empresa participada pela Microsoft, graças à especial adaptação do seu Translator's Workbench ao programa Microsoft Word. O Transit, da Star, é um outro aplicativo que se mantém numa boa posição, atrás do TW, especialmente pela potência do seu gestor de terminologia; por último, o Déjà Vu é um software espanhol que está a conseguir uma grande aceitação no mercado pelo seu grande serviço e pelo seu reduzido custo, superando o Transit, que durante os últimos anos ocupava a segunda posição nas listas de preferência dos tradutores mundiais (embora a hegemonia da Trados continue sem ser discutida). Em qualquer dos casos, estas são algumas das muitas aplicações de gestão das MT que podem ser encontradas no mercado.

A proliferação de ferramentas fez com que surgisse um problema. A incompatibilidade entre elas proporcionava que a partir do momento em que um tradutor começasse a recompilar uma MT num determinado programa, encontrava-se circunscrito a esse programa e não podia abandoná-lo e usar outro diferente sem perder toda a informação recompilada na sua MT. Essa situação era muito problemática para muitos tradutores que, por exigências dos seus clientes, deviam usar diferentes ferramentas, e viam-se assim impossibilitados de compartilhar a sua MT entre todas elas.

Dessa maneira, logo se percebeu a necessidade de um método de intercâmbio de memórias de tradução entre as diferentes aplicações. Assim, em 1988, o consórcio LISA lançou o Translation Memory eXchange (TMX).

Translation Memory eXchange

O TMX é uma linguagem que cumpre as especificações do XML e cujo objectivo é proporcionar um padrão para o intercâmbio das memórias de tradução. Quando se está a trabalhar com uma aplicação e se deseja trabalhar com outra mantendo a MT que se tinha recompilado, apenas será preciso exportá-la em formato TMX e importá-la na nova aplicação. Para isso é necessário que todas as aplicações suportem o mesmo formato: no ano de 2001, pode-se dizer que essa situação já foi superada, uma vez que as ferramentas mais importantes do mercado passaram a admitir a importação e exportação de memórias em TMX, embora de maneiras diferentes.

O objectivo deste trabalho é proporcionar um guia para o formato TMX, fornecendo uma descrição das suas especificações e de como podem localizar-se em http://lisa.org/tmx, esclarecendo alguns dos pontos que possam estar menos claros na sua página oficial. Desta forma, o nosso objectivo é mais de divulgação do que científico. Não pretendemos realizar profundas análises sobre cada um dos elementos ou atributos: indicamos unicamente a forma como se relacionam entre si e com a própria memória de tradução e facultamos um guia para a geração de novas MT etiquetadas neste formato e já prontas para serem importadas por qualquer aplicação. A discussão das questões mais técnicas ficam para próximos artigos.

A descrição do formato que vamos apresentar está baseada na versão 1.3 do TMX, com data de 29 de Agosto de 2001.

TMX: características gerais

Já referimos que o TMX cumpre com as especificações do XML. Assim, utiliza os padrões ISO para datas, para códigos de línguas e para códigos de países. Todos os seus elementos se escrevem em minúsculas, para evitar disfunções causadas pela distinção que o XML faz entre maiúsculas e minúsculas. O formato em que se escrevem deve ser o Unicode: UCS-2, UTF-8 ou ISO-646.

Para os arquivos de 7 bites, os caracteres não ASCII devem ser representados em hexadecimais, como &#225; para "á". Contudo, admitem-se poucas entidades de caracteres: &lt; para "<", &gt; para ">", &amp; para "&", ou &quot; para as aspas duplas.

Tudo isto deve ficar especificado no arquivo de alguma forma, que se faz com a Declaração XML, que é <?xml version="1.0" ?>, seguida de uma declaração DOCTYPE, que corresponde a <!DOCTYPE tmx SYSTEM "tmx12.dtd">, se se quiser que o documento seja validado face ao DTD próprio do TMX. Estas duas declarações deverão aparecer nas duas primeiras linhas de qualquer arquivo TMX.

Uma memória de tradução deverá começar sempre com uma etiqueta que a identifique como tmx e que, além do mais, indique a versão da linguagem que estiver a ser utilizada; assim, normalmente a MT será aberta com < tmx version="1.3" > e será fechada com </ tmx >

Como costuma acontecer, o <xml> será dividido em duas únicas partes: um <header> e um <body>. Ambas as etiquetas poderão ter atributos e incluir outros elementos. Vamos começar por explicar qual a informação que deve ser encontrada dentro do cabeçalho e posteriormente explicaremos quais os elementos próprios do corpo.

Header: um cabeçalho para saber quem somos

<header> é uma etiqueta que requer vários atributos e proporciona informação sobre o arquivo TMX e sua forma de criação. Os atributos obrigatórios de <header> são os seguintes:

• creationtool: O programa com o qual foi criado o arquivo TMX. É obrigatório, porque não se trata de um formato desenhado para ser criado manualmente, mas em geral será criado por diferentes aplicações. A respectiva aplicação deve ser especificada com este atributo.
  
  
• creationtoolversion: Sucede o mesmo com a versão concreta do programa com o qual foi criado o arquivo TMX.
  
  
• segtype: Este atributo especifica o tipo de segmentação que será aplicado às unidades de tradução. Se fraccionarmos o nosso texto frase por frase, este atributo terá o valor phrase. Não obstante, podemos decidir separar o texto por parágrafos, por blocos ou por orações; nesses casos o atributo terá o valor paragraph, block ou sentence. Trataremos deste aspecto mais adiante.
  
  
• o-tmf: Significa "Original Translation Memory Format", ou seja, "Formato da Memória de Tradução Original" a partir do qual foi criado o TMX. As especificações não esclarecem o que deve ser feito no caso de se ter criado o TMX a partir de corpus paralelos e não duma MT anterior: neste caso a nossa opção é deixá-lo em branco.
  
  
• adminlang: Indica-se aqui o código da língua em que serão redigidas as notas (elementos <note>) ou o valor do elemento <prop>; ambos serão vistos mais adiante. Pode-se dizer, em poucas palavras, que se trata da língua de trabalho do programador. Deverá ser uma das línguas especificadas por um atributo xml:lang, como veremos.
  
  
• srclang: Aqui devemos especificar o código da língua de origem. Em qualquer memória de tradução existe uma língua de origem e uma ou várias de destino. Neste atributo deve-se especificar a língua de origem, embora exista a possibilidade de se conferir a este atributo o valor "*all*" (sem as aspas, mas com os asteriscos) para indicar que se pode usar qualquer combinação de línguas.
  
  
• datatype: Por último, neste atributo especifica-se o tipo de dados contidos num elemento. Por defeito o seu valor será "unknown" (desconhecido), mas outros valores recomendados podem ser "rtf", "transit", "plaintext", "xml", "html", "winres" (recursos Windows), e vários outros que podem ser consultados em http://www.lisa.org/tmx/tmxnotes.htm.
  
  

Estes são os atributos que o cabeçalho <header> deve conter. Mas existem outros atributos que são opcionais e que proporcionam informação adicional. São os seguintes:

• o-encoding: Todos os arquivos TMX estão em Unicode, como já foi mencionado; mas às vezes é interessante saber qual o código usado para codificar o texto antes de ser convertido para Unicode. Este atributo especifica o código original (daí vem o "o-") em que estava o texto, para que se alguma aplicação tiver de o converter de Unicode para outro formato, se saiba em que formato é preferível reescrevê-lo. A proposta é que o seu valor seja um dos identificadores do IANA, em http://www.iana.org/assignments/character-sets.
  
  
• creationdate: Marca a data de criação dos arquivos em TMX. O seu formato deve ser o seguinte: AAAAMMDDThhmmssZ, correspondendo AAAA ao ano em quatro dígitos, MM o mês em dois dígitos, DD o dia em dois dígitos, hh as horas, mm os minutos e ss os segundos, tudo em dois dígitos (isto é, adicionando um "0" à esquerda se for necessário). T é a própria letra T, que serve para marcar o início do elemento "tempo" e o final do elemento "data" e Z é a própria letra Z e indica que o tempo é dado em UTC (Tempo Universal Coordenado, ou seja, o horário de Greenwich). Um exemplo pode ser "20010504T164220Z".
  
  
• creationid: Aqui é indicado o utilizador que criou o arquivo em TMX.
  
  
• changedate: Especifica-se neste atributo a data da última modificação do arquivo. O valor deve estar no mesmo formato que creationdate.
  
  
• changeid: Deve indicar-se o nome da pessoa que realizou a última modificação no arquivo.
  
  

Um cabeçalho com todos os atributos obrigatórios poderia corresponder ao seguinte:

<header creationtool="corp2tmx.pl" creationtoolversion="beta" datatype=
"plaintext" segtype="sentence" adminlang="EU" srclang="ES" o-tmf="">

Elementos do cabeçalho: a informação geral

Os cabeçalhos podem estar vazios e não conter nenhum elemento dentro de <header> (obviamente com excepção dos atributos obrigatórios). No entanto, também podem conter algum destes três tipos de elementos: <note>, <prop> e <ude>.

<note> usa-se para os comentários. Um <note> dentro do <head> implica que o comentário se refira a todo o arquivo TMX . Pode incluir o atributo o-encoding, já anteriormente tratado, e que marca o formato do texto original com que foi escrito, ou o atributo xml:lang, do qual falaremos a seguir, e que indica a linguagem em que se escreveu a nota. Não contém nenhum outro elemento dentro dele.

<prop>, quando está dentro do <header>, marca as propriedades do arquivo TMX que não são padronizadas e que dependem da ferramenta que tenha sido utilizada. Estas propriedades não estão definidas pelo padrão TMX e por isso pode tratar-se de qualquer tipo de dados que a nossa ferramenta queira processar. Deve ser acompanhado do atributo type, que marca o tipo de dados que o <prop> conterá. Pode ser utilizado, por exemplo, para introduzir uma série de instruções que deverá ter em consideração a ferramenta utilizada.

Além do o-encoding, já explicado, <prop> também pode ser definido com o atributo xml:lang. Este atributo especifica a linguagem em que estão escritos os dados, tanto de um comentário <note> como de um <prop>. Por defeito, o valor deste atributo é o mesmo que o valor de adminlang. O seu valor deve ser um código dos identificadores de linguagem de ISO, de duas ou de três letras (como aparecem em http://www.unicode.org/unicode/onlinedat/languages.html) ou os identificadores de país (http://www.unicode.org/unicode/onlinedat/countries.html); para o espanhol, por exemplo, dever-se-ia definir xml:lang="es", e para o basco, xml:lang = "eu".

Por último, os cabeçalhos podem incluir também o elemento <ude>, User-Defined Encoding, ou "Codificação Definida pelo Utilizador". Este elemento marca um conjunto de caracteres definidos pelo utilizador, de que o texto precisará para a sua correcta interpretação. Deve ser definido através de um atributo name, com o nome desse subconjunto de caracteres e deve conter um ou vários elementos <map/>.

Analisemos estes elementos <map/>. Trata-se de elementos vazios que transmitem informação por meio de atributos. Nesse caso, cada <map/> marca um carácter definido pelo utilizador, de cuja informação o programa necessitará. Deve levar o atributo unicode, que será o valor Unicode em hexadecimal do carácter; e como mínimo um destes três: ent (que indica o nome da entidade do carácter), subst (que informa sobre uma sequência de caracteres alternativa que pode ser usada para esse carácter, em ASCII), ou code (que especifica o "point-code", isto é, o "ponto de codificação", em hexadecimal). Se o <map/> leva um atributo code, o elemento <ude> deverá levar um atributo base, que especificará o conjunto de códigos em que está baseada a codificação definida pelo utilizador.

Em resumo: o cabeçalho <header> dá informação sobre o conjunto do arquivo TMX. Esta informação pode ser de vários tipos:

• Contextual, como a ferramenta com que foi criado o arquivo (atributos obrigatórios creationtool e creationtoolversion), a sua data de criação e o seu autor (atributos opcionais creationdate e creationid) ou da última modificação (atributos changedate e changeid), e a língua usada para as anotações (atributo obrigatório adminlang).
  
  
• De formato, seja o formato original em que foi escrito o texto (atributo obrigatório o-tmf) ou a codificação original usada (atributo opcional o-encoding), a língua original em que foi redigido (atributo obrigatório srclang), o tipo de dados que contém (atributo obrigatório datatype) ou o tipo de segmentação que foi escolhido para dividir o texto em unidades de tradução (atributo obrigatório segtype).
  
  
• Comentários que se referem a todo o arquivo (elemento opcional <note>, com os seus atributos xml:lang para marcar a língua do comentário e o-encoding para marcar a codificação original em que foi escrito o comentário).
  
  
• Propriedades não padronizadas do arquivo que podem ser utilizadas pela nossa ferramenta (elemento opcional <prop>, com os seus atributos type, que marca o tipo de dados que contém o prop, o-encoding e xml:lang).
  
  
• Informação sobre os caracteres não padronizados do arquivo TMX (elemento opcional <ude>, com um atributo name que lhe dá o nome, e um ou vários elementos <map\>, um para cada carácter definido pelo utilizador).
  
  

Agora vamos analisar, como teste, um cabeçalho criado pelo programa Transit, depois de ter exportado uma memória de tradução para o TMX :

Vê-se que o TMX foi gerado pelo programa Transit 3.0, num tipo de dados próprio do Transit, que o texto está segmentado em blocos, que a língua dos comentários é o inglês, que a língua do original é o inglês britânico, que o formato original é o próprio do Transit, que foi criado no dia 7 de Maio de 2001 às 8:35 no horário de Greenwich pelo cliente "XTRA-Bi", que originariamente estava codificado em Unicode e que existe uma propriedade não padronizada chamada "Project" que tem como valor "Tradução teste".

Como se pode verificar, foi incluída toda a informação possível excepto "changeid" e "changedate", que não eram relevantes por ser um arquivo de nova criação; nos comentários "note" não se quis definir nenhum novo subconjunto de caracteres através do "ude".

Depois de observarmos o funcionamento do cabeçalho e a informação que este nos oferece, passamos ao cerne do arquivo: como se organiza a Memória de Tradução.

Unidade de Tradução (TU, Translation Unit): é construída por unidades

Além do <header>, o arquivo TMX consta de um <body> no qual estará incluída toda a informação da memória de tradução. Este body conterá unicamente elementos <tu>.

TU significa "unidade de tradução". Se remontarmos ao funcionamento das MT, observamos que os programas que as usam devem informar o tradutor quando encontram na tradução alguma coisa que já tenha sido traduzida anteriormente. Essa "coisa" pode ser uma frase, uma oração, um bloco ou um parágrafo, dependendo de se quisermos que o programa traduza frase por frase, oração por oração, bloco por bloco ou parágrafo por parágrafo. Deve lembrar-se de que tudo isto terá sido definido no atributo segtype.

Nesse caso, e imaginando que tenhamos dado a segtype, por exemplo, o valor "phrase", a memória de tradução constará de um grande número de frases, cada uma das quais terá a sua tradução ou as suas traduções associadas a uma ou a várias línguas. A unidade de tradução, a TU constitui portanto o conjunto de uma frase e a sua tradução ou traduções. A frase original e cada uma das suas traduções estarão contidas em elementos <tuv>, isto é, Translation Unit Variants, ou Variantes da Unidade de Tradução. Estas variantes deverão especificar, como é lógico, a língua a que pertencem, por meio do atributo xml:lang. E o texto em concreto dessa versão estará dentro do elemento <seg>.

Para utilizar um exemplo que pode ser conhecido, uma unidade de tradução típica poderia ser:

Desta forma, quando o tradutor receber a frase "Olá, mundo", saberá que não precisa de a traduzir de novo; ou se preferir, poderá inclusive pedir à sua aplicação para a traduzir automaticamente, para adiantar o trabalho.

Tanto as TU quanto as TUV têm um bom número de atributos opcionais, que dão informação concreta sobre essa frase (ou parágrafo, ou o que for). Já conhecemos alguns destes atributos, como o-encoding, datatype, creationtool, creationversion, creationdate, creationid, changedate, changeid, segtype, o-tmf e srclang. Esta informação pode ser relevante no caso de a nossa memória de tradução ter sido realizada em diferentes programas e de termos acumulado nela o resultado de trabalhos diversos.

Só há dois atributos que ainda não conhecemos. O usagecount , que informa sobre o número de vezes que o programa gestor de MT acedeu especificamente a essa TU ou TUV, o que nos permite saber quais são as partes da memória de tradução que podem ser úteis e quais não vale a pena conservar. De igual modo, o lastusagedata informa quando foi a última vez que o programa acedeu a essa TU ou TUV, no mesmo formato usado em "creationdate". Também são atributos opcionais.

Por último, cada TU poderá ter um identificador, chamado tuid, cujo valor poderá ser o que o utilizador preferir (como <tu tuid="frase1">, ou simplesmente <tu tuid="12">, ou como for mais conveniente).

Para organizar a tradução: elementos da TU

Cada uma das TU pode conter vários elementos acessórios. Um deles é o <note>, que permite introduzir comentários unicamente referentes à TU (embora se esse <note> fosse colocado no cabeçalho, entender-se-ia que os comentários faziam referência ao arquivo completo).

Outro é o <prop>. Colocado dentro do <tu>, este elemento funciona de forma um pouco diferente de quando se encontra colocado dentro do <header>. Aqui, apesar de proporcionar informação de "propriedades não padronizadas", a sua função principal será a de agrupar diferentes TUs num grupo lógico. Incluindo um <prop type="projecto">25-A-30</prop> em cada uma das TUs referentes a esse projecto saber-se-á que pertencem ao grupo "25-A-30". Como o TMX não tem em consideração a noção de "ordem" entre suas unidades de tradução, esta será a única forma de reorganizar as frases uma vez criada a MT.

Ao nível das TUVs também podem aparecer os "note" ou os "prop", que terão a mesma função. Contudo, uma TUV deverá incluir também um elemento <seg> que, como já foi referido, terá a versão de cada língua do segmento a ser traduzido.

Porém, não é necessário que este texto esteja unicamente em ASCII. Para permitir uma maior flexibilidade, e não perder a informação dos códigos nativos, dentro de <seg> poderá haver outros elementos que permitam recuperar a informação do formato original, caso assim o desejemos.

Como recuperar o formato: etiquetas

Os diferentes processadores de texto que existem usam "etiquetas" (ou "tags") para indicar a informação de formato. Em geral, estas etiquetas possuem "Início de etiqueta" e "Fim de etiqueta", e o seu formato deve aplicar-se ao texto que há entre ambas. Para manter esta informação, o TMX consta de dois elementos:

<bpt> (Begin Paired Tag, ou Início de Etiqueta Emparelhada) e
<ept> (End Paired Tag, ou Fim de Etiqueta Emparelhada).

Cada um deles marca uma sequência de códigos nativos que se usam no texto original para definir o início ou o fim das etiquetas de formato. Por exemplo: numa linha típica de HTML, a informação em "negrito" é marcada com as etiquetas "<b>" e "</b>"; o negrito aplica-se ao texto que há entre ambas. No TMX, "<b>" modificaria um elemento <bpt>, e "</bpt>" um elemento <ept>.

HTML: "Isto é só um teste de uma frase em <b>negrito</b>"
TMX: "Isto é só um teste de uma frase em <bpt><b></bpt> negrito<ept><\b></ept>"

Se esta frase estiver em RTF v.1, teremos "só uma frase em {\b negrito}", e quando passar para o TMX, converter-se-á em "só uma frase em <bpt>{\b<\bpt> negrito <ept>}</ept>".

Pode incluir-se mais informação nos elementos <bpt> e <ept>. Por exemplo, pode indicar-se o tipo de etiqueta em questão, utilizando o elemento type (como <bpt type="bold">). Além do "bold" recomendam-se outros como "italic", "ulined" (sublinhado), "scaps" (small caps, versaletes), "link" (texto com hiperligação) entre outros.

Também se poderá definir o modo como devem ficar emparelhados, já que muitas vezes se encontra um fechamento de etiqueta mas não é evidente qual a etiqueta referida. Para isso é usado o atributo identificador i, como em <bpt i="1">. Assim, uma linha em HTML como por exemplo:

HTML: Há <b>negrito, <i>negrito e itálico, </b>e só itálico </i>

na qual se fecha antes a etiqueta de negrito sem ter sido fechada a do itálico, seria no TMX:

TMX: Há <bpt i="1"><b></bpt> negrito, <bpt i="2"><i></bpt> negrito e itálico, <ept i="1"></b></ept> e só itálico <ept i="2"></i></ept>

Por vezes também pode ser interessante emparelhar as diferentes etiquetas de distintas TUVs. Em certas ocasiões, numa frase em castelhano pode haver um segmento em negrito e outro em itálico e que, por causa da diferente sintaxe de duas línguas (por exemplo em basco) podem ter de ficar ordenados de forma diferente, primeiro o itálico e depois o negrito. Mas podemos querer que o programa reconheça as suas verdadeiras equivalências: para isso existe o atributo x.

Os atributos x e i são muito parecidos, mas enquanto o i emparelha etiquetas dentro do mesmo segmento, o x emparelha-as dentro das distintas TUVs de uma TU. Um exemplo típico poderia ser:

Se o atributo x não estiver presente, o programa pode emparelhar a etiqueta de itálico da primeira TUV com a de negrito da segunda. Assim, o emparelhamento produz-se correctamente.

Por vezes surgem problemas com as etiquetas, já que, por exemplo, devido à segmentação, é possível que uma etiqueta seja aberta num segmento e fechada noutro posterior. Por exemplo, pode haver uma etiqueta de "abrir negrito" numa linha, mas pode acontecer que não fique fechada até várias linhas depois. Estas etiquetas que aparecem isoladas num segmento indicam-se com o elemento <it>, que quer dizer "isolated tag" ou "etiqueta isolada". Funciona como as <btp> ou as <ept>, mas precisa de mais um atributo, pos, que indique que se trata de uma etiqueta de início (pos="begin") ou de fim (pos="end").

Uma outra situação possível é que surjam elementos sozinhos, como por exemplo as notas de rodapé, as imagens, etc. Não se trata de etiquetas emparelhadas que ficaram isoladas, mas de etiquetas que por sua natureza se utilizam sozinhas. Para este tipo de objectos utiliza-se o elemento <ph> que significa "place holder". Pode levar o atributo type (para o qual se recomenda usar valores como "image" para imagem, "fnote" para nota de rodapé, "enote" para nota no final, "alt" para texto alternativo, e outros), o atributo x, que serve para o emparelhar com outros de distintas TUVs dentro da própria TU, como já foi visto, e um atributo novo, assoc, que informará se este elemento deve ser associado ao texto precedente (neste caso, o seu valor será "p", de "previous"), ao texto seguinte (neste caso, o valor será "f", de "following") ou a ambos (neste caso, o seu valor será "b", de "both").

Este elemento <ph> contém um elemento <sub> que tem bastante importância. O <sub> pode aparecer em qualquer elemento das etiquetas anteriores, e tem como função marcar o texto que se encontra dentro das etiquetas. No caso de uma <ph type ="fnote">, uma nota de rodapé, será neste elemento <sub> que ficará inserido o texto da nota.

Para dar um exemplo, apresentamos o que aparece na documentação:

Existe também um elemento <ut>, que significa "unknown tag", e que se utiliza para as "etiquetas desconhecidas". Só pode levar o atributo x, já conhecido.

E, por último, devemos citar mais um elemento, <hi>, de "highlight", "destacar", cuja função é marcar porções de segmentos para qualquer propósito definido pelo utilizador. Podem levar o atributo x ou o type.

Com estes elementos, um arquivo TMX pode manter não só o texto dos arquivos originais, mas também as suas marcas de formato e a relação entre elas.

Três níveis de informação, três níveis de implantação

Quando se fala na implantação do formato TMX nas diferentes ferramentas de gestão de memórias de tradução, diz-se que esse formato está implementado "no nível 1", "no nível 2" ou "no nível 3". As páginas web das diferentes aplicações não deixam claro o nível em que implementam o TMX, excepto algumas como o TRADOS ou o SDLX, que reconhecem uma implementação no nível 2.

O que querem dizer estes "níveis"?

Simplesmente o reconhecimento dos diferentes códigos de formato e de etiquetas.

• O nível 1 é aquele em que não são tidos em consideração nem os códigos de formato nem as etiquetas. Apenas se reconhece o texto que aparece dentro de cada elemento <seg>, sem anotações de conteúdo. É a opção menos eficaz, embora seja a que oferece melhores resultados na busca de equivalências entre textos, já que a comparação textual não se vê perturbada por nenhum código.
• O nível 2 é aquele em que se têm em consideração as etiquetas no seu formato TMX; isto é, o aparecimento de <btp> e <etp>, ou de <ph>, mas sem incluir os códigos nativos dessas etiquetas.
• O nível 3 assume tanto as etiquetas TMX como o código nativo que aparece em cada elemento do formato. Com este nível não se perde nenhuma informação e a recuperação dos formatos originais torna-se simples.

Estes códigos funcionam junto das declarações do formato original (o o-encoding do cabeçalho e o datatype do cabeçalho, TU, TUV e sub).

Resumo: o que pode e não pode ser transmitido

Em resumo, o que pode ser transmitido numa memória de tradução dentro de um <body> é o seguinte:

• Unidades de tradução (<tu>), com as suas possíveis anotações e as suas propriedades específicas, e com variantes da unidade de tradução (<tuv>) para cada língua. Haverá informação contextual sobre a frase tanto nas TUVs como nas TUs. No caso da TU, há também um identificador de unidade, um TUID.
• Dentro de cada TUV haverá um SEG, que conterá o texto e as etiquetas de formato, que poderão ser etiquetas de início e de fim dum formato (<bpt> e <ept>), emparelhadas ou isoladas (nesse caso serão <it>,com um atributo que informa se é de início ou de fim); etiquetas individuais (<ph>, associadas ao texto anterior, ao posterior ou a ambos); ou etiquetas desconhecidas. Estas etiquetas estarão relacionadas entre si, cada início com seu fim, e entre as diferentes TUVs, para garantir o correcto alinhamento entre elas. Também poderão ser marcadas porções de segmentos para posteriores propósitos

Esta é basicamente a estrutura dos arquivos TMX, com a respectiva informação guardada e que permite o intercâmbio de memórias de tradução (TM). Apresentamos aqui uma tradução e a exposição de dois documentos básicos do TMX. "TMX Format: Specifications", http://lisa.org/tmx/tmx.htm, e "TMX Format: Implementation Notes", http://lisa.org/tmx/tmxnotes.htm . Nestas duas fontes poderão esclarecer qualquer dúvida ou quaisquer dados técnicos que tenham sido mencionados por alto.