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