>> 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>?
>
> ???

Eu xa digo que primeiro hai que ver que é o que nos fai falta. Pero
primeiro mirar o que nos fai falta a nivel de ir fixando as cousas e
despois o que nos fai falta para cando estamos traducindo (nesta parte
poderiase ocultar moita información irrelevante).

Por exemplo penso que ao tradutor lle sería útil saber como é o plural
de "cartafol", ou o xénero de "bricolaxe"; a veces podelle ser dificil
decidirse entre dúas traducións se non ten claro en que ámbito se
aplica cada unha... Despois o de ter traducións prohibidas ou
recomendadas... penso que para o tradutor case é mellor ver só o que
está recomendado e pasar de ver as outras opcións que poden confundilo
(ou non)...

>> 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