> O problema mais habitual já nom é incompatibilidade, mas um suporte débil do
> estándar, que nom permite muitas das vezes tirar todo o partido das
> especificaçons.
>>
>> O gran problema e que o Lokalize, descoñezo o Virtaal, non seguia o
>> estándar e había que facer varias barrabasadas para que o puidera ler.
>>
> Francisco: é umha única "barrabasada" (multiplicada n vezes, claro): mudar
> os <langSet> para conterem <termGroup>, o que realmente é umha das
> posibilidades do estándar.
>
> O assunto é que sem modificá-lo o Lokalize nom o le.

Se queredes, podo emitir un RFE (Request For Enhancement) no bugzilla
de kde, pero claro, preciso unha descrición de onde queredes chegar:
-A facer máis amigábel para o usuario a identificación do código de
idioma, de tal xeito que cando apareza "gl_ES" no canto de "gl" ou
viceversa, ou mesmo "es_AR" no canto de "es_ES", que emita un aviso e
que permita escoller a lingua termo ?
-A empregar indistintamente un <tig> ou o primeiro contido dun <ntig> ?
-A poder meter definicións das traducións, e non só do <termEntry>? (A
sinonimia, évos moi traizoeira)
-A poder adicionar máis informacións administrativas tanto a nível
<termEntry> como <langSet><[n]tig>?

???

> Sim, claro. Polo que sei do TTK (perguntava se alguem trabalhou com o
> Virtaal), nom se contempla a posibilidade de que um <langSet> contenha mais
> de um <term>. Isto é assi, por exemplo, para o csv2tbx, de maneira que para
> solventar problemas do estilo "position=cargo|posiçom" ou
> "abort=cancelar|interromper" deve-se escrever tantos <termEntry> como
> <terms> existam dentro do mesmo.

Penso que non sería complicado tirar de xquery para automatizar esta
filtraxe e aplanamento do tbx (non, non teño tempo)

Responderlle a