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