2013/3/6 mvillarino <mvillar...@kde-espana.es>

> > OASIS está dando os últimos pasos para a publicación. Servirá para algo?
>
> No software libre, non. Por dous motivos:
> a) libintl en determinados sistemas forma parte de libc (entre outros,
> en sistemas tan irrelevantes como Ubuntu e Debian). Así que aínda que
> aos desenvolventes de gettext lles dese un ataque que sensatez e
> fixesen unha nova gettext que usase este formato de ficheiro, habería
> unha forte barreira para a popularización.
> b) No fondo, o sistema escollido polo actual gettext está concebido
> para que a internacionalización teña moi pouco custo para o equipo
> desenvolvente. Vamos, para que non se poida dicir que é traballosa
> para non internacionalizar.
> Isto maniféstase en que a base de datos que é o ficheiro po/mo ten
> como chave primaria a dupla "mensaxe orixinal"/"contexto" (onde algún
> elemento pode estar nulo. E esta alternativa escolleuse en contra do
> outro sistema que había para escoller: catgets, que por resumir, é o
> que fai o resto do universo: meter no código unha identificación da
> mensaxe, e que o sistema de i18n vaia buscar o texto a un ficheiro de
> recursos sempre.
> A vantaxe destoutro sistema é que ten moi pouco custo que cada texto,
> aínda que igual que outros, vaia na súa propia unidade de tradución.
> Daquela (1995) podía argumentarse a favor de gettext tal e como a
> coñecemos que era barata de popularizar, e de localizar (non había
> memorias de tradución aínda, non non esquezamos, e mesmo hoxe en día
> non sempre se fai propagación automática).
>
> Vaia ladrillo que me saiu.
>

Excelente, canto sabes mestre!


>
> Ao que estabamos: non vai servir de moito porque a) non hai unha
> libintl que use do xliff,


Vale pero esa barreira pode desaparecer


> b) usalo como formato intermedio non quita
> do problema de ter varias mensaxes metidas nunha unidade de tradución
> se o programa usa gettext, e c) mete fases no fluxo de traballo aínda
> que o programa use ficheiros de recursos ou propiedades.
>
> Onde si vale o formato xliff 2? Pois onde as memorias de tradución
> sexan segredas, dado que pode conter candidatos (ver apéndice b da
> especificación), e onde os glosarios sexan de obrigado cumprimento,
> porque permite meter un glosario sinxelo, pero eficaz, dentro do
> ficheiro xliff. É dicir, aló onde un provedor subcontrate, pague por
> palabra (e suponse que menos se o texto orixe da unidade de tradución
> casa co que xa teña presente nunha memoria) e obrigue a cumprir cun
> glosario.
> E claro, que un par de etapas máis ou menos, automatizábeis, de
> conversión de formato do ficheiro, non importen moito.
>

Supoño que o obxectivo de OASIS é precisamente estandarizar no posible un
formato industrial, que sexa compatible cos procesos da empresas de
tradución e tentar impoñerse como algo que deban recoller os
desenvolvedores de ferramentas CAT. Nese contexto, a idiosincrasia da
tradución de software libre pode ser case marxinal. Se fose así, sería un
avance de todas maneiras, pola extensión dun estándar que non estea en mans
privativas e tamén resulta accesible, cos procesos de conversión (mediante
as ferramentas) que xa indicas ti, para todos os demais.

Visto doutra maneira, se as ferramentas de código libre implementan eses
fluxos serían tamén válidas para o ámbito profesional. E iso si que pode
atraer unha grande masa crítica de usuarios.

Quizais Lucía nos podería falar algo desde esa perspectiva.


Saúdos







> _______________________________________________
> Proxecto mailing list
> Proxecto@trasno.net
> http://listas.trasno.net/listinfo/proxecto
>
_______________________________________________
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto

Responderlle a