[G11n] Gcompris listo para remitir?

[Gonçalo Cordeiro]

Fran Diéguez escreveu:
> Ola Gonçalo,
>
> vexo fixeches modificacións no ficheiro 
> http://l10n.gnome.org/vertimus/gcompris/gcomprixogoo/po/gl
>
> estes días estou marcando os ficheiros que estean listos para remitir 
> como por exemplo http://l10n.gnome.org/vertimus/anjuta/master/po/gl.
>
> Pregunta: Está o gcompris preparado para remitir ou queres que o deixe 
> sen remitir porque precisa revisión?
>
> consello: remite os ficheiros do gcompris mediante o procedemento 
> "Reservar para traducir" e "Enviar nova tradución" no lugar de 
> "Anexalo como un comentario".
>
desculpa Fran, a que te refires exactamente com o de "Enviar nova 
tradución", digo-o porque estando conectado no Damned Lies, essa opçom 
nom me sai no menú, só estám disponhíveis as outras duas.
> saúdos
>

[G11n] glosario gl en TBX para Virtaal

[Gonçalo Cordeiro]

Leandro Regueiro escreveu:
> A ver, para comezar penso que en vez de adaptarnos nós ao que fan os
> desenvolvedores, que a veces non son moi conscientes do que fai falta,
> é mellor dicirlles claramente que é o que nos fai falta, para que
> fagan algo que lles sexa útil a milleiros de tradutores. A min o de
> usar ntig para a tradución de SL parécemevos algo innecesario, por
> exemplo, e non sei se nunha proba que se fixera con axuda de Marce
> conseguiramos que o Lokalize tragara un ficheiro que só tiña tig.
>
> Se lles fan falta exemplos de TBX (incluíndo o de Mancomún):
> http://ghicho.iespana.es/ E non vexo problemas en enviarlles o que hai
> na forxa, no cal a xente de Tagen Ata (se non lembro mal) realizou un
> gran traballo, aínda que evidentemente é mellorable.
>   
 Ok, mándolles entón o enlace ao proxecto da Forxa do glosario. Se algún
 día
 desaparece, xa lles mandaremos outro.
 
>>> Paréceme ben, excepto polo feito de que no glosario de Mancomún non
>>> están tódalas etiquetas que pensamos usar nos futuros glosarios. Igual
>>> era boa idea coller e facer un TBX cunha ducia de entradas e os campos
>>> que nos interesan...
>>>   
>> Pois, é boa ideia. A ver se melhoram o suporte a TBX no TTK e no Virtaal,
>> porque agora mesmo só aceita termo+equivalência (só 1)+comentário
>> (=definiçom).
>> 
>
> E con iso non imos a ningures. Vexo necesario ter definición (quizais
> por idioma), varias traducións posibles para cada idioma, estado de
> tradución (recomendada, prohibida...), xénero ... non sigo que non
> lembro máis.
>
>   
>> Por certo que tanto Shaforostoff como Illich em seus desenvolvimentos
>> (Lokalize e DiverGloss) utilizam a versom alargada do estándar TBX, nom o
>> TBX-Basic, por isso nom som compatíveis. Portanto, se se utiliza o
>> TBX-Basic, haverá que ver se hai algumha ferramenta compatível em SL, o que
>> até onde eu sei nom existe.
>> 
>
> A min dame igual que sexa TBX ou TBX-basic, ou máis ben non, debería
> ser TBX xa que hai cousas que considero necesarias que non están en
> TBX-basic, pero aínda así podemos pasar de usar ntig que complica
> bastante a lectura do ficheiro, tanto por seres humanos como por
> programas, e aínda por riba o ficheiro TBX ocupa máis espazo.
>
>   
Bom, creio que levas razom, o importante nom é a versom que se escolha.

O que nom sei é se nos estamos a referir ao mesmo: á recolha e fixaçom 
terminológica ou á interacçom com umha ferramenta dada (ou às 2 cousas, 
claro). Vamos, que vejo importante definir este aspecto e concretar os 
campos para utilizar (no estándar TBX 
(http://www.lisa.org/TBX-Specification.33.0.html) ou na versom Basic 
(http://www.lisa.org/TBX-Basic.926.0.html)) para que o trabalho despois 
seja reutiliz'avel na prática. Por isso pergunto por onde se está a 
tirar. Se se quere que as persoas desenvolvedoras melhorem o suporte a 
TBX para o podermos utilizar, haverá que especificar-lhes alguns destes 
pormenores. Como podo saber que especificaçom e que componhentes e 
atributos vam ser utilizados para as entradas terminológicas?

Por outra parte, sabendo isto, poderase contrastar as 2 versons de TBX e 
ver qual se axusta melhor aos requirimentos, tendo em conta que no 
TBX-Basic estám precisados os elementos mínimos obrigatórios e os 
recomendados para a interacçom com ferramentas CAT. Aliás, se o que se 
procura é a simplicidade, parece que o TBX-Basic seria umha boa escolha. 
Mas depende, como digo, da orientaçom que lhe esteas a dar...
> Ata logo,
>Leandro Regueiro
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20091109/c37c2fc0/attachment.vcf
 

[G11n] glosario gl en TBX para Virtaal

[Gonçalo Cordeiro]

Leandro Regueiro escreveu:
>>> Ola,
>>> non miro o correo en dous días e xa me soltades todo isto.
>>>
>>> A ver, para comezar penso que en vez de adaptarnos nós ao que fan os
>>> desenvolvedores, que a veces non son moi conscientes do que fai falta,
>>> é mellor dicirlles claramente que é o que nos fai falta, para que
>>> fagan algo que lles sexa útil a milleiros de tradutores. A min o de
>>> usar ntig para a tradución de SL parécemevos algo innecesario, por
>>> exemplo, e non sei se nunha proba que se fixera con axuda de Marce
>>> conseguiramos que o Lokalize tragara un ficheiro que só tiña tig.
>>>
>>> Se lles fan falta exemplos de TBX (incluíndo o de Mancomún):
>>> http://ghicho.iespana.es/ E non vexo problemas en enviarlles o que hai
>>> na forxa, no cal a xente de Tagen Ata (se non lembro mal) realizou un
>>> gran traballo, aínda que evidentemente é mellorable.
>>>   
>> Ok, mándolles entón o enlace ao proxecto da Forxa do glosario. Se algún día
>> desaparece, xa lles mandaremos outro.
>> 
>
> Paréceme ben, excepto polo feito de que no glosario de Mancomún non
> están tódalas etiquetas que pensamos usar nos futuros glosarios. Igual
> era boa idea coller e facer un TBX cunha ducia de entradas e os campos
> que nos interesan...
>   
Pois, é boa ideia. A ver se melhoram o suporte a TBX no TTK e no 
Virtaal, porque agora mesmo só aceita termo+equivalência (só 
1)+comentário (=definiçom).
Por certo que tanto Shaforostoff como Illich em seus desenvolvimentos 
(Lokalize e DiverGloss) utilizam a versom alargada do estándar TBX, nom 
o TBX-Basic, por isso nom som compatíveis. Portanto, se se utiliza o 
TBX-Basic, haverá que ver se hai algumha ferramenta compatível em SL, o 
que até onde eu sei nom existe.
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20091109/73e33374/attachment.vcf
 

[G11n] glosario gl en TBX para Virtaal

[Gonçalo Cordeiro]

Manuel Souto Pico escreveu:
> Ola, 
>
> 2009/11/7 Gonçalo Cordeiro  <mailto:gonzalo en tagenata.com>>
>
> Manuel Souto Pico escreveu:
>
> Ola,
> Alguén está na lista de Translate Toolkit & Pootle?
> (translate-devel en lists.sourceforge.net
> <mailto:translate-devel en lists.sourceforge.net>
> <mailto:translate-devel en lists.sourceforge.net
> <mailto:translate-devel en lists.sourceforge.net>>) Supoño que
> máis dunha persoa...
> Están pedindo glosarios de l10n para Virtaal. Entendo que o
> que necesitan é un URL.
> Simplemente quería perguntar cal é o ficheiro TBX do noso
> glosario que é máis actual e que se mantén e se alguén llelo
> pode mandar. Podo mandarllo eu pero quería cerciorarme
> primeiro, non sei se o mellor é mandarlles a ligazón á páxina
> na Forxa ou que, tal como están as cousas e sen saber canto
> vai durar iso aí (ao final non lembro se xa temos un
> repositorio alternativo).
>
> Un saúdo, Manuel
> 
> 
>
>  
>
> eu tampuco creio que haja nengum problema em enviar o da forxa, mas:
>
>
> Xa sei que non hai problema en enviar o link á Forxa. O que pregunto é 
> se esa é a versión máis actual ou que se actuliza máis regularmente ou 
> se hai un repositorio ou un espello/réplica alternativo que non se 
> vaia fechar... Leandro?
>
> alguém já experimentou um TBX no Virtaal?
> igual que se tivo que adaptar o formato para o Lokalize, é
> provável que o haja que fazer para o Virtaal.
> Vendo o ficheiro de terminologia do Pootle e o csv2tbx, tampouco
> parece que suporte nem o TBX-basic.
>
>
> Eu non entendo isto. Se un glosario é conforme ao estándar TBX (en 
> calquera das súas variedades, e entendo que o TBX-basic é conforme co 
> TBX a secas), non entendo porque o que hai que adaptar é o glosario e 
> non a ferramenta que non o admite. Non sería lóxico que, se o Virtaal 
> ou o Lokalize non conseguen importar un TBX perfectamente ben formado, 
> sexan esas propias ferramentas as que se melloren para facelas 100% 
> compatíbeis co estándar en vez de adaptar o glosario ás limitacións 
> desas ferramentas?
>
> Alguén pode ilustrar qué foi o que houbo que mudar no glosario para 
> poder importalo en Lokalize? 
>  
>
> Aplicando isto aos ficheiros tbx disponíveis, haveria talvez que
> escrever todas as correspondências múltiplas para um termo em
> linhas únicas, por exemplo; mas depende de como estea indo o
> suporte a TBX neste aplicativo.
>
>
> Gonçalo, poderías explicar isto? Con exemplos (código), quero dicir. 
> Se non é de interese para a lista, pódesme escribir a min en 
> privado. Non estou seguro de que queres dicir con "correspondencias 
> múltiplas" ou "linhas únicas" ...  
>
>
> Noutra orde de cousas, nom hai negum TBX de referência que se
> poida recomendar para utilizar como base (até onde eu sei). Ou bem
> nom estám verificados nas soluçons, ou na parte filolóxica ou a
> discusom terminológica está aberta na comunidade. O único que tem
> certas garantias é um subconjunto do glossario na forxa de
> Mancomún, feito durante a revisom do Gnome e "validado" polo Termigal.
>
>
> Se o que queres é un modelo, sempre podes crear un rexistro completo 
> nalgunha ferramenta de xestión terminolóxica, e despois exportalo como 
> TBX e ver que pinta ten. 
>
Despois de jogar um bocado co Virtaal, podo confirmar que o suporte ao 
estándar TBX é mínimo e apenas contempla a possibilidade de 
Orige:Destino:Comentários, o que é compatível com o suporte disponível 
no csv2tbx do próprio Toolkit.
Isto obriga a refazer os materiais para trabalhar com ele, adaptando, 
por exemplo as unidades que contenham mais de umha equivalência 
(desfazendo-as em 2, por exemplo).
É interesante o modo de sugestom de alternativas para a traduçom 
(OpenTran, Google, glossários em .tbx e .po etc.) mas o suporte no 
Lokalize continua a ser mais alargado.

Cumprimentos,
Gonçalo
> Cumprimentos, 
> Manuel 
>
>
> Cumprimentos,
> Gonçalo
>
> ___
> G11n mailing list
> G11n en mancomun.org <mailto:G11n en mancomun.org>
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>
> 
>
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>   


-- 
TAGEN ATA LIN

[G11n] glosario gl en TBX para Virtaal

[Gonçalo Cordeiro]

Fran Dieguez escreveu:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>   
>> Eu non entendo isto. Se un glosario é conforme ao estándar TBX (en
>> calquera das súas variedades, e entendo que o TBX-basic é conforme co
>> TBX a secas), non entendo porque o que hai que adaptar é o glosario e
>> non a ferramenta que non o admite. Non sería lóxico que, se o Virtaal ou
>> o Lokalize non conseguen importar un TBX perfectamente ben formado,
>> sexan esas propias ferramentas as que se melloren para facelas 100%
>> compatíbeis co estándar en vez de adaptar o glosario ás limitacións
>> desas ferramentas?
>> 
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.
>
>   
tanto como barrabasadas... parece-me um pouco excessivo mas:
este é um exemplo do formato original:



access key




tecla de acceso




e este o do equivalente na versom adaptada para o lokalize:




access key






tecla de acceso





Francisco: é umha única "barrabasada" (multiplicada n vezes, claro): 
mudar os  para conterem , o que realmente é umha das 
posibilidades do estándar.

O assunto é que sem modificá-lo o Lokalize nom o le.
>> Gonçalo, poderías explicar isto? Con exemplos (código), quero dicir. Se
>> non é de interese para a lista, pódesme escribir a min en privado. Non
>> estou seguro de que queres dicir con "correspondencias múltiplas" ou
>> "linhas únicas" ...  
>> 
>
>   
Sim, claro. Polo que sei do TTK (perguntava se alguem trabalhou com o 
Virtaal), nom se contempla a posibilidade de que um  contenha 
mais de um . 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  como 
 existam dentro do mesmo.
Tampouco tenho claro, por isso pergunto, se aceita algum dos outros 
atributos do TBX-Basic.
> O glosario que está en mancomún ten grandes deficiencias que habería que
> solventar. Unha das principais é que mostra todas as suxestións posíbeis
>  aínda que para un termo dado houbera unha recomendad/fixada.
>
> Isto fai que haxa que voltar a mirar o glosario e actualizalo de acordo
> a consensos.
>
> O glosario de Mancomún foi un bo medio para chegar a un fin. Fin que
> teremos que acadar pronto importando novos termos fixados e eliminando
> os anteriores.
>
>   
Bom, quase nom concordo com nada, apenas com a parte dos objectivos, que 
creio que deveria ter ficado clara tempo atrás. O objecto dessa 
compilaçom foi o de fazer umha primeira amostra (acho que o 
suficientemente representativa) de que soluçons se estavam a adoptar nos 
principais projectos (veja-se a cabeceira dos TBX na forxa). O que 
Francisco refere como "deficiência" é antes umha característica, entendo eu.
Naquela altura (ainda nesta) as tais soluçons fixadas están aonde? Se 
existem e estám trabalhada num TBX, é justamente o que Javier perguntava...
Num segundo passo, excluíu-se toda a informaçom ortográfica ou 
morfologicamente incorrecta, mas nem se pretendia nem se terminou um 
passo posterior de discusom, unificaçom e formalizaçom de terminologia. 
Simplesmente, isto nom existe a dia de hoje (até onde eu sei). Essa é 
sim, umha "deficiência" a preencher considerando os objectivos que 
Francisco aponta.

Bom, se conseguimos esse ficheiro representativo e correctamente 
formado, haverá que ir vendo como o Virtaal implementa o TBX na prática.

Cumprimentos,
Gonçalo
> Saúdos
>
> - --
> Fran Diéguez
> http://www.mabishu.com - listas en mabishu.com
> GPG: 43DD 1B00 035F A764 4986  E695 98BB 6626 A2A4 F9B8
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEUEARECAAYFAkr1ve8ACgkQmLtmJqKk+bgQMQCeKK//VMSjTETlTITCu/E9SWhD
> vxsAl2ov0qS+f6DD+YuRifdYdgcR2ok=
> =uRE/
> -END PGP SIGNATURE-
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/piper

[G11n] glosario gl en TBX para Virtaal

[Gonçalo Cordeiro]

Manuel Souto Pico escreveu:
> Ola, 
>
> Alguén está na lista de Translate Toolkit & Pootle? 
> (translate-devel en lists.sourceforge.net 
> ) Supoño que máis dunha 
> persoa... 
>
> Están pedindo glosarios de l10n para Virtaal. Entendo que o que 
> necesitan é un URL. 
>
> Simplemente quería perguntar cal é o ficheiro TBX do noso glosario que 
> é máis actual e que se mantén e se alguén llelo pode mandar. Podo 
> mandarllo eu pero quería cerciorarme primeiro, non sei se o mellor é 
> mandarlles a ligazón á páxina na Forxa ou que, tal como están as 
> cousas e sen saber canto vai durar iso aí (ao final non lembro se xa 
> temos un repositorio alternativo).
>
> Un saúdo, Manuel
> 
>
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>   
eu tampuco creio que haja nengum problema em enviar o da forxa, mas:
alguém já experimentou um TBX no Virtaal?
igual que se tivo que adaptar o formato para o Lokalize, é provável que 
o haja que fazer para o Virtaal.
Vendo o ficheiro de terminologia do Pootle e o csv2tbx, tampouco parece 
que suporte nem o TBX-basic.
Aplicando isto aos ficheiros tbx disponíveis, haveria talvez que 
escrever todas as correspondências múltiplas para um termo em linhas 
únicas, por exemplo; mas depende de como estea indo o suporte a TBX 
neste aplicativo.

Noutra orde de cousas, nom hai negum TBX de referência que se poida 
recomendar para utilizar como base (até onde eu sei). Ou bem nom estám 
verificados nas soluçons, ou na parte filolóxica ou a discusom 
terminológica está aberta na comunidade. O único que tem certas 
garantias é um subconjunto do glossario na forxa de Mancomún, feito 
durante a revisom do Gnome e "validado" polo Termigal.

Cumprimentos,
Gonçalo
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20091107/00f56d48/attachment.vcf
 

[G11n] [terminoloxía] enigmail

[Gonçalo Cordeiro]

Leandro Regueiro escreveu:
> 2009/11/5 Gonçalo Cordeiro :
>   
>>>>> pd: o meu seguinte paso é enterarme das dinámicas de mantemento dunha
>>>>> tradución, que non teño nin idea. como aprobeito o traballo que teño
>>>>> feito
>>>>> con enigmail cando saquen a próxima versión? veño de descubrir omegaT e
>>>>> paréceme que ten un bo sistema para facer isto..pero... moito me queda
>>>>> por
>>>>> investigar. moitas gracias, de novo.
>>>>>
>>>>>   
>>>> Aproveitarase todo o que fixeches porque calquera aplicativo máis ou
>>>> menos estándar para localización de software que empregues permite
>>>> incorporar o ficheiro po da tradución anterior, á parte de que a nova
>>>> versión xa che virá coa túa tradución anterior incorporada se o envías
>>>> agora ao proxecto para que o recollan.
>>>>
>>>> 
>>> Sendo un proxecto que use Gettext si, pero o Enigmail é unha extensión
>>> para algún dos produtos de Mozilla e alí usan outro formato. O
>>> traballo con eses formatos non o teño moi explorado, pero dalgún xeito
>>> se foron reutilizando as tradución de Firefox e familia...
>>>
>>>   
>> Se o que queres é utilizar umha memoria de traduçom baseada em TMX, podes
>> utilizar como dis o OmegaT, ou dar-lhe umha oportunidade ao Lokalize,
>> Virtaal, Open Language Tools e outros com soporte a este formato.
>> Com aplicativos como o Gtranslator, pode-se basear esta memória no formato
>> PO, bem mediante conjuntos de ficheiros ou incorporados num único
>> "compendio" de traduçom. Podes experimentar co msmerge e demais utilidades
>> Gettext.
>>
>> De todos modos, o que se consegue com isto é reaproveitar trabalho anterior
>> (próprio ou doutros/as colegas), o que normalmente é mais rendível utilizado
>> interactivamente, mediante umha ferramenta de traduçom que vaia sugerindo
>> alternativas e coincidências com traduçons anteriores.
>>
>> Os problemas podem vir se o que se pretende aplicar um conjunto de traduçons
>> prévias a um ou mais ficheiros, porque é difícil solucionar a ambiguidade.
>> Por exemplo, se se utiliza umha memória do Gnome, em qualquer das suas
>> formas, aplicada em seu conjunto a um PO em concreto, umha coincidência do
>> 100% numha memória para umha mensagem cuja traduçom é dependente do
>> contexto, é necessária a intervençom da persoa tradutora para adoptar umha
>> soluçom. Quer dizer, nem sempre é factível aplicar automaticamente umha
>> memória, independentemente do formato, e dar por válida a pretraduçom. Claro
>> que isto é mais factível quando se aplica a um ficheiro de dimensons
>> reduzidas umha memória consistente unicamente numha versom anterior do mesmo
>> ficheiro.
>>
>> Outra estratégia possível é basear o processo em XLIFF e ir vendo como
>> proceder com as actualizaçons. Para isto hai alternativas como as
>> OpenLanguageTools ou o Lokalize. Ambos trabalham com TMX e XLIFF, e o
>> Lokalize ademais soporta o formato TBX. O desenvolvedor do Lokalize escreveu
>> um script XLIFFmerge.py que pode ser de grande ajuda para implementar um
>> processo de actualizaçom com certas garantias. De facto, umha das opçons é a
>> de manipulaçom de IDs nom coincidentes e nom apenas baseado num source
>> tomado como ID.
>>
>> Para combinar estas funcionalidades, é necessário, para além da ferramentas
>> mencionadas, utilizar por exemplo o TranslateToolkit para as conversons
>> TMX<---PO,Properties etc.--->. Tem algum bug com a manipulaçom dos escapes,
>> mas pode-se experimentar com ele.
>>
>> Vamos, que depende da ferramenta utilizada e as opçons que permita, mas
>> depende mais ainda da estratégia e necessidades que se tenham que enfrentar.
>> 
>
> Creo que ao que se refiria era a tendo unha versión traducida como se
> fai para traducir a nova sen ter que traducir outra vez de cero o que
> xa estaba traducido, é dicir, o que en Gettext sería actualizar cun
> novo POT.
>   
O do POT de onde o tiras? Achei que se falava em enigmail...
gostavas era da resposta curta?
vai: co enigmail, chungo; com projectos grandes difícil, em Gettext 
já hai ferramentas...
creio que nom me esqueceu nada...
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20091105/46677b1c/attachment-0001.vcf
 

[G11n] [terminoloxía] enigmail

[Gonçalo Cordeiro]

>>> pd: o meu seguinte paso é enterarme das dinámicas de mantemento dunha
>>> tradución, que non teño nin idea. como aprobeito o traballo que teño feito
>>> con enigmail cando saquen a próxima versión? veño de descubrir omegaT e
>>> paréceme que ten un bo sistema para facer isto..pero... moito me queda por
>>> investigar. moitas gracias, de novo.
>>>   
>> Aproveitarase todo o que fixeches porque calquera aplicativo máis ou
>> menos estándar para localización de software que empregues permite
>> incorporar o ficheiro po da tradución anterior, á parte de que a nova
>> versión xa che virá coa túa tradución anterior incorporada se o envías
>> agora ao proxecto para que o recollan.
>> 
>
> Sendo un proxecto que use Gettext si, pero o Enigmail é unha extensión
> para algún dos produtos de Mozilla e alí usan outro formato. O
> traballo con eses formatos non o teño moi explorado, pero dalgún xeito
> se foron reutilizando as tradución de Firefox e familia...
>   
Se o que queres é utilizar umha memoria de traduçom baseada em TMX, 
podes utilizar como dis o OmegaT, ou dar-lhe umha oportunidade ao 
Lokalize, Virtaal, Open Language Tools e outros com soporte a este formato.
Com aplicativos como o Gtranslator, pode-se basear esta memória no 
formato PO, bem mediante conjuntos de ficheiros ou incorporados num 
único "compendio" de traduçom. Podes experimentar co msmerge e demais 
utilidades Gettext.

De todos modos, o que se consegue com isto é reaproveitar trabalho 
anterior (próprio ou doutros/as colegas), o que normalmente é mais 
rendível utilizado interactivamente, mediante umha ferramenta de 
traduçom que vaia sugerindo alternativas e coincidências com traduçons 
anteriores.

Os problemas podem vir se o que se pretende aplicar um conjunto de 
traduçons prévias a um ou mais ficheiros, porque é difícil solucionar a 
ambiguidade. Por exemplo, se se utiliza umha memória do Gnome, em 
qualquer das suas formas, aplicada em seu conjunto a um PO em concreto, 
umha coincidência do 100% numha memória para umha mensagem cuja traduçom 
é dependente do contexto, é necessária a intervençom da persoa tradutora 
para adoptar umha soluçom. Quer dizer, nem sempre é factível aplicar 
automaticamente umha memória, independentemente do formato, e dar por 
válida a pretraduçom. Claro que isto é mais factível quando se aplica a 
um ficheiro de dimensons reduzidas umha memória consistente unicamente 
numha versom anterior do mesmo ficheiro.

Outra estratégia possível é basear o processo em XLIFF e ir vendo como 
proceder com as actualizaçons. Para isto hai alternativas como as 
OpenLanguageTools ou o Lokalize. Ambos trabalham com TMX e XLIFF, e o 
Lokalize ademais soporta o formato TBX. O desenvolvedor do Lokalize 
escreveu um script XLIFFmerge.py que pode ser de grande ajuda para 
implementar um processo de actualizaçom com certas garantias. De facto, 
umha das opçons é a de manipulaçom de IDs nom coincidentes e nom apenas 
baseado num source tomado como ID.

Para combinar estas funcionalidades, é necessário, para além da 
ferramentas mencionadas, utilizar por exemplo o TranslateToolkit para as 
conversons TMX<---PO,Properties etc.--->. Tem algum bug com a 
manipulaçom dos escapes, mas pode-se experimentar com ele.

Vamos, que depende da ferramenta utilizada e as opçons que permita, mas 
depende mais ainda da estratégia e necessidades que se tenham que enfrentar.
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20091105/3bca4036/attachment.vcf
 

[G11n] Tradución de Branch => Galla ??

[Gonçalo Cordeiro]

Antón Méixome escreveu:
> Gonçalo Cordeiro escribiu:
>   
>> talvez um seguinte passo nos glossários seria pensar em criar tbx 
>> específicos utilizando origens como as que indicas, neste caso para 
>> termos terminologia específica de manipulaçom de CVS ou o que for.
>> 
> Paréceme unha idea interesante pero habería que facer unha especie de 
> "mapa de materias", o que non é doado precisamente, para saber cal sería 
> o glosario acaído.
>
>
>   
nom vejo a necessidade dessa exaustividade, nem muito menos...
para que se entenda, antes de ir a um aspecto tam específico como o que 
comentas, talvez seria bom pensar em ter glossários de aplicaçons, do 
Pidgin ou o Empathy para MI (o os casos que comentavas de Bazaar ou a de 
GForge) para procurar termos de umha área em concreto.
isto, pensando no suporte que alguns editores oferecem a o formato TBX: 
se alguém está traduzindo ou actualizando o Pidgin, ponho por caso, 
poderia juntar um tbx deste e do Empathy para servir de ajuda durante o 
trabalho.

-- 
TAGEN ATA LINGUA E COMUNICACIÓN S. COOP. GALEGA (Rúa de Ponferrada, 8 
entreplanta B 15707. Santiago de Compostela), infórmao/a de que o seu enderezo 
de correo electrónico e o resto dos datos de carácter persoal que nos facilite 
serán obxecto de tratamento automatizado nos nosos ficheiros, co fin de 
xestionar a axenda de contactos da nosa empresa e para o envío de comunicacións 
comerciais e/ou persoais por vía electrónica. Vostede poderá, en calquera 
momento, exercer o dereito de acceso, rectificación, cancelación ou oposición 
nos termos establecidos na Lei orgánica 15/1999, de protección de datos de 
carácter persoal (LOPD 15/1999), dirixindo un escrito ao enderezo antes 
nomeado. Tamén lle comunicamos que a información incluída neste correo 
electrónico é confidencial pois é para uso exclusivo da persoa destinataria 
arriba mencionada. Se vostede le esta mensaxe e non é a persoa destinataria, 
informámolo/a de que está totalmente prohibida calquera utilización, 
divulgación, distribución e/ou reprodución desta comunicación sen autorización 
expresa en virtude da lexislación vixente. Se recibiu esta mensaxe por erro, 
pregámoslle que nolo notifique inmediatamente por esta mesma vía e proceda á 
súa eliminación.

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20091009/cc3c29ca/attachment.vcf
 

[G11n] Tradución de Branch => Galla ??

[Gonçalo Cordeiro]

Antón Méixome escreveu:
> Podo lembrar que no Glosario de localización (que como sabedes non 
> inventa nada senón que recolle o que hai), dise:
>
> "branch"#"ramificación"#"galla"#
> "branch"#"ramificar"##
>
> Aínda así o glosario non é nin moito menos exhaustivo xa que non recolle 
> outras fontes como por exemplo a tradución de Bazaar ou a de GForge onde 
> se utilizou tamén "rama".
>
>   
nom, claro, porque nom se trata de umha questom de exaustividade (nem 
muito menos, embora o número de fontes fosse considerável); trata-se 
antes de umha questom de representatividade do corpus seleccionado e o 
tratamento estatístico para a extracçom de léxico bilingüe.
talvez um seguinte passo nos glossários seria pensar em criar tbx 
específicos utilizando origens como as que indicas, neste caso para 
termos terminologia específica de manipulaçom de CVS ou o que for.
> Parece recomendábel tender a "ramificación".
>
>
>
>
> Fran Dieguez escribiu:
>   
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>   
>> 
>>> Ola,
>>> eu persoalmente prefiro póla. Todos entende de que se fala.
>>> 
>>>   
>> Como digo moitas veces me resulta fora de contexto póla. Póla asócioo
>> sempre á flora.
>>   
>> 
>>> O de PMS pode provocar ataques de risa se se viu TBBT.
>>> 
>>>   
>> JEJEJE
>>   
>> 
>>> Dise "parabéns".
>>> 
>>>   
>> jalejo coloquial
>>   
>> 
>>> Aproveito para indicar que eu tamén teño un ou dous ficheiros que
>>> están pendentes da fixación da terminoloxía referente a este ámbito.
>>> 
>>>   
>> home coido que se se pode agardar ao sistema de terminoloxía que facedes
>> mellor que mellor
>>   
>> 
>>> Ata logo,
>>>  Leandro Regueiro
>>> ___
>>> G11n mailing list
>>> G11n en mancomun.org
>>> http://listas.mancomun.org/mailman/listinfo/g11n
>>> 
>>>   
>> - --
>> Fran Diéguez
>> http://www.mabishu.com - listas en mabishu.com
>> GPG: 43DD 1B00 035F A764 4986  E695 98BB 6626 A2A4 F9B8
>>
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkrODjsACgkQmLtmJqKk+bhMGwCfe/2yrhxQ7z1Mr0UftE0VFKZw
>> zc0AnRRxMOF5vHWbIl4Hq36O+5MzCmF+
>> =X2Gx
>> -END PGP SIGNATURE-
>> ___
>> G11n mailing list
>> G11n en mancomun.org
>> http://listas.mancomun.org/mailman/listinfo/g11n
>>
>>   
>> 
>
>
>   


-- 
TAGEN ATA LINGUA E COMUNICACIÓN S. COOP. GALEGA (Rúa de Ponferrada, 8 
entreplanta B 15707. Santiago de Compostela), infórmao/a de que o seu enderezo 
de correo electrónico e o resto dos datos de carácter persoal que nos facilite 
serán obxecto de tratamento automatizado nos nosos ficheiros, co fin de 
xestionar a axenda de contactos da nosa empresa e para o envío de comunicacións 
comerciais e/ou persoais por vía electrónica. Vostede poderá, en calquera 
momento, exercer o dereito de acceso, rectificación, cancelación ou oposición 
nos termos establecidos na Lei orgánica 15/1999, de protección de datos de 
carácter persoal (LOPD 15/1999), dirixindo un escrito ao enderezo antes 
nomeado. Tamén lle comunicamos que a información incluída neste correo 
electrónico é confidencial pois é para uso exclusivo da persoa destinataria 
arriba mencionada. Se vostede le esta mensaxe e non é a persoa destinataria, 
informámolo/a de que está totalmente prohibida calquera utilización, 
divulgación, distribución e/ou reprodución desta comunicación sen autorización 
expresa en virtude da lexislación vixente. Se recibiu esta mensaxe por erro, 
pregámoslle que nolo notifique inmediatamente por esta mesma vía e proceda á 
súa eliminación.

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20091009/243d46ec/attachment.vcf
 

[G11n] Paste > colar

[Gonçalo Cordeiro]

+ 1 para colar

-os significados de colar e pegar som coincidentes, vendo os 
significados no dicionário da RAG (e outros como o Digalego, por 
exemplo) que o definem como unir mediante umha substáncia.
-colar tem a vantagem de ser mais harmónica com a soluçom do português;

em qualquer caso nom vejo o problema de utilizar umha soluçom válida; o 
que se desprende do glossário que mencionava Antón é que as variaçons de 
estilo som muitas entre projectos, mas cada um guarda umha certa unidade 
na selecçom de termos.

Leandro Regueiro escreveu:
>>> Pois vaia, que me aburrín xa de ver no Firefox et al. 'colar' por 'paste' 
>>> (en)
>>> así que abro o debate. Fágoo, porqué onte ou así miña irmá usando o firefox
>>> saltou sorprendida -'colar'!? , isto é 'pegar', non?- . Tranquilos, non é a
>>> primeira que se pregunta o mesmo.
>>>
>>> Parece moda crecente en Gnome usar colar porque aparece 6 veces en 
>>> evolution,
>>> 9 veces máis no portaretallos... mentras que en KDE está 'apegar/pegar', en
>>> 'inkscape' idem... é dicir, somos máis clásicos ;)
>>>
>>> Segundo o digalego:
>>> colar v.
>>>   
 v t Unir dúas cousas con cola.
 
>>>   >SIN:   encolar.
>>>   >ANT:   descolar, desencolar, despegar.
>>>
>>> e esta non é a acepción da que falamos. Nas si que se cola é nas 
>>> carpinterias
>>> xa que alí péganse as táboas con cola. En todo caso, colar refírese a pegar
>>> con pegamento ou cola, non a unir dous elemento con tal de que queden 
>>> xuntos.
>>>
>>> (cambridge online)
>>> paste:
>>>   
 paste
 verb
 1 [T usually + adverb or preposition] to stick something to something,
 especially with paste: You can make your own distorting mirror by pasting a
 sheet of kitchen foil to a piece of thin cardboard.

 2 [I or T] to move a piece of text to a particular place in a computer
 document: Cut that paragraph and then paste it at the end of the page.
 
>>> véxase:
>>>
>>> pegar (var. apegar):
>>>   >   1v t
>>>   
  1   Unir unha cousa a outra por medio dunha substancia 
 adhesiva.
  2   Unir unha substancia dúas cousas de xeito que non se 
 separen. Tm
 abs.
 
>>> que para o que me importa, amplia o concepto: xuntar, unir varias cousas. 
>>> Esta
>>> si que me parece unha tradución correcta: Paste > pegar/apegar.
>>>
>>> 'Pegar' é un concepto xa introducido na lingua e que todo o mundo emprega.
>>> Pégase un cartel, unha pegatina... No caso de preteder cambialo por que en
>>> portugués ou noutras linguas se empregue 'colar' por 'paste'... eu non son
>>> quen de lle atopar xustificación. Colar e pegar son patrimoniais, pegar ten 
>>> un
>>> sentido máis amplo así como un uso máis extendido para 'unir, ligar varios
>>> elementos'. Colar en portugués ten matices algo diferentes, conceptualmente 
>>> é
>>> mais amplo etc . Así que, que motivo hai para escoller 'colar'?
>>>   
>> Todo o que pasa pola miña man vai con pegar.
>>
>> Colar non resulta axeitado para o significado que se lle pretende dar na
>> informática.
>> 
>
> Eu tamén traduzo sempre como "pegar". "Colar" sóame raro, e cando
> mirara no dicionario non me pareceu que "pegar" fora incorrecto. En
> todo caso estaría disposto a usar "colar" sempre que haxa boas razóns
> para usalo e non usar "pegar".
>
> Ata logo,
> Leandro Regueiro
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090706/8eb426de/attachment-0001.vcf
 

[G11n] Fwd: Lokalize & xliff

[Gonçalo Cordeiro]

voltando ao assunto, e ligando com um fio aberto por Méixome na lista de 
Gnome, em: (http://listas.mancomun.org/pipermail/gnome/2009-May/000151.html)

esta última versom do Lokalize oferece o suporte a roles de persoa 
usuária (tradutor, revisor, aprovador), a estados das mensages e a 
control das fases. Todo isto é de grande interese em relaçom ao fio 
aberto na lista de Gnome, sobre o control das revisons e minimizar as 
tarefas de actualizaçom dos projectos.

Marce:
-tenho ainda que fazer mais testes da aplicaçom, para ir vendo também a 
gestom que se pode fazer a partir dos metadados que guarda; mais adiante 
poderia-se ir falando com o desenvolvedor... Por exemplo, umha persoa 
tradutora (o rol) nom tem acceso em nengum momento aos atributos 
, de maneira que nom pode marcar determinadas cadeias para que 
algúem com um rol de revisom se detenha em determinadas mensagens.
-com o que sim tenho algum problema é com a gestom da(s) MT, 
concretamente com a importaçom (de TMX e a baseada em PO); como primeira 
sugestom, falta talvez um modo ou indicaçons para eliminar as MT que nom 
se querem mais.
-o ícone que incorporou para o código gl nom é o correcto, 
poderia-se-lhe fazer chegar o adequado.

um saúdo,
Gonçalo


mvillarino escreveu:
> Boa tarde,
>
> a discusión acerca do xliff en lokalize continúa na lista de correo de
> kde-i18n-doc, e cada vez está máis interesante, agora entrou Caslav
> Illic no allo e fai unhas preguntas interesantes interesantes.
>
> O motivo de reenviar tamén esta mensaxe é que é precisa axuda de
> tradutores que teñan experiencia con traballo empregando xliff.
>
> Por favor, quen estexa interesado en ter o mellor soporte posíbel de
> xliff en Lokalize, e experiencia, que achegue algunha información
> referente ao que se comenta en baixo.
>
> -- Forwarded message --
> From: Chusslove Illich 
> Date: 2009/5/15
> Subject: Re: Lokalize & xliff
> To: KDE i18n-doc 
>
>
>   
>> [: Nick Shaforostoff :]
>> On the other hand, xliffmerge is designed in such way that it simply can't
>> loose any metadata (because it operates directly on DOM). So I believe
>> xliffmerge must become such convention.
>> 
>
> Within the apparent circumstances, that seems reasonable; just like there
> are Gettext tools as reference for maintaining translations based on PO.
>
> What makes me feel odd, though, is that these details are not covered by
> whatever would be considered practice guides or referent tools in support of
> the XLIFF format, considering its richness. Instead, when it comes to
> workflow and maintenance, from this it appears it's each tool for itself.
>
> If you happen to know some pricey tools with "good support for XLIFF"
> (whatever that means in light of the above), it would be interesting to hear
> how they handle the workflow and maintenance. In hope there's something to
> be learned from them.
>
> So, while we're in the wilderness...
>
>   
>> final flags will disappear. most changed units will typically have 'new'
>> flag. (except for markup and -- in future -- punctuation only change)
>> 
>
> In general, I would advise automatic distinction of changes, in any context,
> being strictly optional and with caution notes in documentation. What is not
> a relevant markup/interpunction change for one language, may be for another;
> what is not relevant for one translator, may be for another.
>
> Instead, by default, I'd treat all changes equivalently, and focus on
> thorough represenation of diffs. While the diff is displayed, there *could*
> be a side indicator confirming if the changes are only in markup or in
> punctuation; that would in no way invite shoddiness, unlike possibly letting
> such changes through silently.
>
>   
>> Currently Lokalize doesn't offer removing alt-trans entries at all (i
>> didn't manage to do this in time for string freeze). And xliffmerge script
>> preserves alt-trans entries too.
>>
>> Actually, (optionally) enabling diff for target is nice idea, i will
>> implement it.
>> 
>
> My idea about review process is the following.
>
> First, taking again single translator and single reviewer. Translator
> happily goes about translating, updating (merging), translating, merging...
> For a given version (as in VCS revision) of a catalog, reviewer comes along
> and reviews some or all units in it, recording that he did so. Translator
> again goes spinning. When reviewer comes about, after any number of merging-
> translating cycles, he should be able to:
>
> * go only through units which had "changed" or were added since his last
>  review, and
>
> * for all changed units, see the diffs of all "important" parts of a unit,
>  from his last review to the current version.
>
> Here, I define a unit being "changed" if at least one "important" element of
> it has been changed; and "important" elements are not merely original and
> translation, but, e.g. in PO sense, also msgctxt and translator comments
> (# ...).
>
> T

[G11n] [glosario] hard-coded

[Gonçalo Cordeiro]

mvillarino escreveu:
> 2009/6/1 Gonçalo Cordeiro :
>   
>> se é no módulo de i18n, esta-se a procurar os valores literais «embedded» no
>> código?
>>
>> +1 para "Introducidas no código"
>>
>> -"incorporadas no código" ? (no glossário embed=incrustado/incorporado)
>> 
>
> Veña ho, o de non por embebido (=enchoupado, metido en) e no entanto
> meter incorporado (= built in) non vos é moi aló.
>
>   
foi por mencionar alternativas, mas concordo em que deve ser nesse sentido
> Con "hard coded" hai que pensar que á máis de textos "this is not
> intended 2b tr'ed" poden ser rotas "/var/lib/mydaemon/pid", e a
> escolle debería valer para ambas as dúas.
>
> E xa postos, Gonçalo, déchelle outro tento ao Lokalize: Nicolás ten
> binarios compilados de trunk  para o Windows.
>   
dim, engadindo:
deb http://ppa.launchpad.net/kubuntu-ppa/experimental/ubuntu jaunty main
ao source.list e mediando um par de apt-get -f install

> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090601/4f13ebee/attachment.vcf
 

[G11n] [glosario] hard-coded

[Gonçalo Cordeiro]

se é no módulo de i18n, esta-se a procurar os valores literais 
«embedded» no código?

+1 para "Introducidas no código"

-"incorporadas no código" ? (no glossário embed=incrustado/incorporado)


Fran Dieguez escreveu:
> mmm non sei se será axeitado porque se pensamos un pouco e facendo
> analoxía con gettext.
>
> _("isto é unha cadea")
>
> "isto é unha cadea"
>
> non están as dúas cadeas "introducidas no código"
>
> Saúdos
>
> mvillarino escribiu:
>   
>> 2009/6/1 Fran Dieguez :
>> 
>>> Boas rapaces,
>>>
>>> que algunha opinión para o termo que poño no asunto, o contexto é o
>>> seguinte:
>>>
>>> "No more hard-coded strings found."
>>>
>>> Atópase no módulo de internacionalización de java.
>>>   
>> Introducidas no códido?
>> ___
>> G11n mailing list
>> G11n en mancomun.org
>> http://listas.mancomun.org/mailman/listinfo/g11n
>> 
>
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090601/67e25672/attachment.vcf
 

[G11n] versom modificada das Open Language Tools

[Gonçalo Cordeiro]

Olá a todas/os,

Para que as OLTools (https://open-language-tools.dev.java.net/) podam 
trabalhar com os ficheiros no formato XLIFF, gerados com o Pootle v. 
1.2, em:
http://wiki.services.openoffice.org/wiki/Pootle_Issue_List#Pootle_1.2_Feedback
informam de que está disponhível umha versom modificada do TransEditor.jar.

Pode-se descarregar esta versom, o pacote de idioma em galego e a 
traduçom do manual em:
http://repositorio.tagenata.net/doku.php?id=open_language_tools

um saúdo,
Gonçalo
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090522/db0182d4/attachment.vcf
 

[G11n] [Dúbidas]XLIFF

[Gonçalo Cordeiro]

Onde si creio que hai um erro é nas traduçons dos menus para a inserçom 
de resultados da MT/Glossário/WEB:

por exemplo em:

msgctxt "@action:inmenu"
msgid "Insert TM suggestion # %1"
msgstr "Inserir a %1ª tradución alternativa" --> "Inserir a tradución 
alternativa nº %1"

%1 é umha variável que se expande por todos os submenús anteriores 
fazendo equivaler %1 às ocorrências 0 a 9.

Estám corregidas na versom enviada, mas vera-se melhor no teste sobre a 
aplicaçom.


Antón Méixome escreveu:
> Desculpade se me metín no medio pero como Marce preguntaba sobre 
> terminoloxía estándar da terminoloxía pareceume oportuno intervir 
> porque teño aquí á man Terminoloxía da tradución, na versión en galego 
> que fixo a Univ. de Vigo.
>
> Especialmente chamo a atención sobre "target" > termo. Non nego que en 
> moitos casos sexa máis natural a tradución como "destino" pero o 
> estándar en terminoloxía internacional é falar de "termo", tamén para 
> o galego.
>
> Sobre unificación de "idioma" e "lingua"
> É certo que non é correcto que se mesturen ambos termos no mesmo 
> ficheiro de localización, tamén é certo que nos aplicativos galego 
> predomina "idioma" pero non considero necesario que a regularización 
> vaia alén. "Idioma" é máis un termo sociolingüístico e "lingua" é un 
> termo máis filolóxico. Así que é nomral que en terminoloxía da 
> tradución se escolla "lingua" pero que cando un programa pregunta ao 
> usuario, se prefira o uso de "idioma", no noso contexto social polo 
> menos.
>
> Do resto
> approved/repproved
>
> Desde logo "reprobada" non é aceptábel porque significa "condenada", 
> "suspendida". Unha outra opción sería aprobada/desaprobada pero 
> realmente creo que funcionaría mellor validada/invalidada porque 
> permite contar tamén co rol "validador", a acción "validación", etc. 
> cousa que con "aprobar" resulta moi forzada.
>
> Gonçalo, poderías compilar unha lista de fases, estados, roles, 
> marcas, etc de XLIFF para tomar unha decisión sistémica do estándar ?
>
> Respecto dos femininos que comentas, viches algún caso de erro claro ?
>
> Antón
>
>
>
>
>
>
> Gonçalo Cordeiro escribiu:
>> Vai o ficheiro revisado e traduzido;
>> deixei todas as mensages revistas ou  traduzidas como «fuzzy» (no 
>> Lokalize mostram-se como «Nom aprovadas»).
>>
>> Haveria que unificar o uso de «idioma» e «lingua» que aparecem 
>> mesturados no conjunto do .po (idioma é a traduçom mais estendida nas 
>> aplicaçons em galego de SL).
>>
>> Sem ver como ficam as mensages na própria aplicaçom nom creio que 
>> seja possível traduzir várias das cadeias.
>> Em concreto, todo o que se refire ao controlo das fases de 
>> localizaçom e roles de persoa usuária (fluxo de trabalho em XLIFF) 
>> esta-se a implementar de umha maneira particular no Lokalize. Em 
>> parte o problema é o uso da marca de aprovaçom/reprovaçom (validaçom) 
>> de modo interactivo durante o processo de localizaçom, além de ser em 
>> parte equivalente ao estado duvidoso de umha mensagem ao estilo 
>> Gettext. Quer dizer que o de aprovada/reprovada (validada) nom é umha 
>> boa traduçom para como realmente funciona: nom hai umha aprovaçom 
>> explícita da mensage traduzida, aprova-se automaticamente ao 
>> modificá-la. Sendo assi, o rol de «aprovador» tem o problema de nom 
>> estar associado a umha funçom accessível através da IU (ao contrário 
>> do papel de revisor/corrector), ainda que suponho que é aonde caminha 
>> o desenvolvimento recente do Lokalize: as «fases» recolhem informaçom 
>> sobre o trabalho feito polas persoas com um papel específico e 
>> vai-se-lhes associando estados às mensages traduzidas.
>>
>> Haveria que considerar as marcas de estado aplicadas às unidades de 
>> traduçom (final, signed-off e demais) para propor soluçons válidas 
>> (ver a ligaçom ao estándar XLIFF 1.2 enviada num correio anterior). 
>> Entre as traduçons primeiras (e também neste ficheiro enviado por 
>> Mancomún) hai cadeias referidos a estados que tenhem que estar em 
>> feminino (lista, vista e semelhantes).
>>
>> Binari units = unidades binárias --> todas som unidades de traduçom e 
>> as binárias podem estar para serem traduzidas ou nom.
>>
>> Sobre Target > Termo creio que houvo algumha discusom anterior.
>>
>> Creio que assi é mais coerente co desenvolvimento do estándar.
>>
>> Gonçalo Cordeiro.
>>
>>
>> Antón Méixome escreveu:
>>> Marce Villarino 

[G11n] [Dúbidas]XLIFF

[Gonçalo Cordeiro]

nslation.
rejected-grammar Indicates that the item has been rejected because of 
incorrect grammar.
rejected-inaccurate Indicates that the item has been rejected because it 
is incorrect.
rejected-length Indicates that the item has been rejected because it is 
too long or too short.
rejected-spelling Indicates that the item has been rejected because of 
incorrect spelling.
tm-suggestion Indicates the translation is suggested by translation memory.

> Respecto dos femininos que comentas, viches algún caso de erro claro ?
>
algum havia; talvez o melhor é que Marce faga um diff sobre os 2 PO 
enviados e decida vendo os contextos msgctxt e ao funcionamento da 
traduçom no próprio aplicativo (nom os tenho recolhidos e arrumados).
> Antón
>
>
>
>
>
>
> Gonçalo Cordeiro escribiu:
>> Vai o ficheiro revisado e traduzido;
>> deixei todas as mensages revistas ou  traduzidas como «fuzzy» (no 
>> Lokalize mostram-se como «Nom aprovadas»).
>>
>> Haveria que unificar o uso de «idioma» e «lingua» que aparecem 
>> mesturados no conjunto do .po (idioma é a traduçom mais estendida nas 
>> aplicaçons em galego de SL).
>>
>> Sem ver como ficam as mensages na própria aplicaçom nom creio que 
>> seja possível traduzir várias das cadeias.
>> Em concreto, todo o que se refire ao controlo das fases de 
>> localizaçom e roles de persoa usuária (fluxo de trabalho em XLIFF) 
>> esta-se a implementar de umha maneira particular no Lokalize. Em 
>> parte o problema é o uso da marca de aprovaçom/reprovaçom (validaçom) 
>> de modo interactivo durante o processo de localizaçom, além de ser em 
>> parte equivalente ao estado duvidoso de umha mensagem ao estilo 
>> Gettext. Quer dizer que o de aprovada/reprovada (validada) nom é umha 
>> boa traduçom para como realmente funciona: nom hai umha aprovaçom 
>> explícita da mensage traduzida, aprova-se automaticamente ao 
>> modificá-la. Sendo assi, o rol de «aprovador» tem o problema de nom 
>> estar associado a umha funçom accessível através da IU (ao contrário 
>> do papel de revisor/corrector), ainda que suponho que é aonde caminha 
>> o desenvolvimento recente do Lokalize: as «fases» recolhem informaçom 
>> sobre o trabalho feito polas persoas com um papel específico e 
>> vai-se-lhes associando estados às mensages traduzidas.
>>
>> Haveria que considerar as marcas de estado aplicadas às unidades de 
>> traduçom (final, signed-off e demais) para propor soluçons válidas 
>> (ver a ligaçom ao estándar XLIFF 1.2 enviada num correio anterior). 
>> Entre as traduçons primeiras (e também neste ficheiro enviado por 
>> Mancomún) hai cadeias referidos a estados que tenhem que estar em 
>> feminino (lista, vista e semelhantes).
>>
>> Binari units = unidades binárias --> todas som unidades de traduçom e 
>> as binárias podem estar para serem traduzidas ou nom.
>>
>> Sobre Target > Termo creio que houvo algumha discusom anterior.
>>
>> Creio que assi é mais coerente co desenvolvimento do estándar.
>>
>> Gonçalo Cordeiro.
>>
>>
>> Antón Méixome escreveu:
>>> Marce Villarino escribiu:
>>>> O Domingo 10 Maio 2009 19:23:12 Gonçalo Cordeiro escribiu:
>>>>  
>>>>> Creio que o Lokalize é o único aplicativo nom privativo com 
>>>>> soporte das
>>>>> fases e estados das mensages en XLIFF.
>>>>> 
>>>> [...]
>>>>  
>>>>> Reviewer --> pessoa revisora, correctora;
>>>>> Approver --> coincide com o que se costumamos ver como umha tarefa de
>>>>> revisom, mas estritamente «approved» indica um estado final de umha
>>>>> mensage num fluxo de traduçom (feita por umha pessoa que dá a 
>>>>> «aprovaçom»):
>>>>> /Approved/ - Indicates whether a translation is final or has 
>>>>> passed its
>>>>> final review.
>>>>> Binary units --> unidades binárias:
>>>>> 
>>>>
>>>> Istooo, e que tal se lle pasades un ollo ao Lokalize?
>>>> Estou a achar termos de terminoloxía e iso sumado aos relativos ao 
>>>> procedemento de traballo (workflow) é un cristo, e sodes as únicas 
>>>> persoas con experiencia no traballo con XLIFF.
>>>> ___
>>>> G11n mailing list
>>>> G11n en mancomun.org
>>>> http://listas.mancomun.org/mailman/listinfo/g11n
>>>> file:///home/meixome/Documentos/Traducion/Lokalize/lokalize.po
>>>>
>>>>   
>>> Acabo de actualizar a tradución e revisión 

[G11n] [Dúbidas]XLIFF

[Gonçalo Cordeiro]

Vai o ficheiro revisado e traduzido;
deixei todas as mensages revistas ou  traduzidas como «fuzzy» (no 
Lokalize mostram-se como «Nom aprovadas»).

Haveria que unificar o uso de «idioma» e «lingua» que aparecem 
mesturados no conjunto do .po (idioma é a traduçom mais estendida nas 
aplicaçons em galego de SL).

Sem ver como ficam as mensages na própria aplicaçom nom creio que seja 
possível traduzir várias das cadeias.
Em concreto, todo o que se refire ao controlo das fases de localizaçom e 
roles de persoa usuária (fluxo de trabalho em XLIFF) esta-se a 
implementar de umha maneira particular no Lokalize. Em parte o problema 
é o uso da marca de aprovaçom/reprovaçom (validaçom) de modo interactivo 
durante o processo de localizaçom, além de ser em parte equivalente ao 
estado duvidoso de umha mensagem ao estilo Gettext. Quer dizer que o de 
aprovada/reprovada (validada) nom é umha boa traduçom para como 
realmente funciona: nom hai umha aprovaçom explícita da mensage 
traduzida, aprova-se automaticamente ao modificá-la. Sendo assi, o rol 
de «aprovador» tem o problema de nom estar associado a umha funçom 
accessível através da IU (ao contrário do papel de revisor/corrector), 
ainda que suponho que é aonde caminha o desenvolvimento recente do 
Lokalize: as «fases» recolhem informaçom sobre o trabalho feito polas 
persoas com um papel específico e vai-se-lhes associando estados às 
mensages traduzidas.

Haveria que considerar as marcas de estado aplicadas às unidades de 
traduçom (final, signed-off e demais) para propor soluçons válidas (ver 
a ligaçom ao estándar XLIFF 1.2 enviada num correio anterior). Entre as 
traduçons primeiras (e também neste ficheiro enviado por Mancomún) hai 
cadeias referidos a estados que tenhem que estar em feminino (lista, 
vista e semelhantes).

Binari units = unidades binárias --> todas som unidades de traduçom e as 
binárias podem estar para serem traduzidas ou nom.

Sobre Target > Termo creio que houvo algumha discusom anterior.

Creio que assi é mais coerente co desenvolvimento do estándar.

Gonçalo Cordeiro.


Antón Méixome escreveu:
> Marce Villarino escribiu:
>> O Domingo 10 Maio 2009 19:23:12 Gonçalo Cordeiro escribiu:
>>  
>>> Creio que o Lokalize é o único aplicativo nom privativo com soporte das
>>> fases e estados das mensages en XLIFF.
>>> 
>> [...]
>>  
>>> Reviewer --> pessoa revisora, correctora;
>>> Approver --> coincide com o que se costumamos ver como umha tarefa de
>>> revisom, mas estritamente «approved» indica um estado final de umha
>>> mensage num fluxo de traduçom (feita por umha pessoa que dá a 
>>> «aprovaçom»):
>>> /Approved/ - Indicates whether a translation is final or has passed its
>>> final review.
>>> Binary units --> unidades binárias:
>>> 
>>
>> Istooo, e que tal se lle pasades un ollo ao Lokalize?
>> Estou a achar termos de terminoloxía e iso sumado aos relativos ao 
>> procedemento de traballo (workflow) é un cristo, e sodes as únicas 
>> persoas con experiencia no traballo con XLIFF.
>> ___
>> G11n mailing list
>> G11n en mancomun.org
>> http://listas.mancomun.org/mailman/listinfo/g11n
>> file:///home/meixome/Documentos/Traducion/Lokalize/lokalize.po
>>
>>   
> Acabo de actualizar a tradución e revisión dese ficheiro que vos vai 
> anexo para que o miredes tamén.
>
> En concreto
>
> Approver  > Validador/a
> Source > Orixe
> Reviewer > Corrector... pero review > revisar, revisión
> Target > Termo
> Language > Lingua
>
> Creo que así é coherente coa terminoloxía de tradución segundo a FIT 
> (Federación Internacional dos Tradutores)
>
> Antón Méixome
>
>
>
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : lokalize.po
Tipo   : text/x-gettext-translation
Tamaño : 96791 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090511/cf1de3d4/attachment-0001.bin
 
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090511/cf1de3d4/attachment-0001.vcf
 

[G11n] [Dúbidas]XLIFF

[Gonçalo Cordeiro]

Gostaria imenso de lhe dar umha vista de olhos ao Lokalize, de facto 
estou a seguí-lo, mas nom consigo compilar a última versom, que é a que 
inclui o soporte de PHASE e estados das mensages. Algumha sugestom para 
a instalaçom?

O que si poderiamos ver é o ficheiro de localizaçom do Lokalize e 
sugerir algumha traduçom.

Marce Villarino escreveu:
> O Domingo 10 Maio 2009 19:23:12 Gonçalo Cordeiro escribiu:
>   
>> Creio que o Lokalize é o único aplicativo nom privativo com soporte das
>> fases e estados das mensages en XLIFF.
>> 
> [...]
>   
>> Reviewer --> pessoa revisora, correctora;
>> Approver --> coincide com o que se costumamos ver como umha tarefa de
>> revisom, mas estritamente «approved» indica um estado final de umha
>> mensage num fluxo de traduçom (feita por umha pessoa que dá a «aprovaçom»):
>> /Approved/ - Indicates whether a translation is final or has passed its
>> final review.
>> Binary units --> unidades binárias:
>> 
>
> Istooo, e que tal se lle pasades un ollo ao Lokalize?
> Estou a achar termos de terminoloxía e iso sumado aos relativos ao 
> procedemento de traballo (workflow) é un cristo, e sodes as únicas persoas 
> con 
> experiencia no traballo con XLIFF.
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090510/82f03fdc/attachment.vcf
 

[G11n] [Dúbidas]XLIFF

[Gonçalo Cordeiro]

O grao de implementaçom do estándar XLIFF noutras ferramentas de 
traduçom é ainda débil.
As Open Language Tools (que trabalham com XLIFF 1.0) som ainda um bom 
exemplo da implementaçom de marcas de estado nas mensages, para poder 
estabelecer um fluxo de trabalho.
Creio que o Lokalize é o único aplicativo nom privativo com soporte das 
fases e estados das mensages en XLIFF.
Um bom exemplo (privativo, com  versom de teste) é o Swordfish.

Marce Villarino escreveu:
> Olá,
>
> pois que despois de ver os últimos screencasts do Shafforo, e aproveitando 
> que 
> respondeu a outro erro que lle enviara, pois deille outro tento ao 
> Lokalize... 
> e que ostia, moito avanzou.
>
> A ver, pois que me mete termos do XLIFF polo medio (lóxico, é a onde quere 
> levar o programa). Estas son as dúbidas:
>
>   
O ponto é que a terminologia nom é a habitual no SL, mas a da indústria 
de localizaçom.
Reviewer --> pessoa revisora, correctora;
Approver --> coincide com o que se costumamos ver como umha tarefa de 
revisom, mas estritamente «approved» indica um estado final de umha 
mensage num fluxo de traduçom (feita por umha pessoa que dá a «aprovaçom»):
/Approved/ - Indicates whether a translation is final or has passed its 
final review.
Binary units --> unidades binárias:
etiqueta  que indica a presença de um elemento binário, 
traduzível ou nom.
em: http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html

> -Roles:
>   - Translator -> Tradutor
>   - Reviewer -> Crítico (?)
>   - Approver -> ? (Autorizador/Aprobador) (*)
>
> -Binary units ->  Unidades de tradución binarias (?)
>
>
> * Prefiro non facer referencia a «aprobar» na tradución deste cargo porque 
> xurde un conflito: Con gettext, quen lle quita a marca de dúbida á mensaxe, 
> pásaa ao estado final, en xliff pódense definir fases, cada unha delas 
> realízaa 
> un cargo/papel/rol, e a cuestión é que para que unha mensaxe se sinale como 
> apta para a seguinte fase hai un botón, que por desgraza leva o mesmo texto 
> con independencia do papel da persoa no procedemento de traballo: aprobada.
>
> Como está a cousa en outros programas?
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>   

 próxima parte 
Borrouse un adxunto en formato HTML...
URL: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090510/9662d3cd/attachment.htm
 
 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090510/9662d3cd/attachment.vcf
 

[G11n] Erros corrector Hunspell - resultado

[Gonçalo Cordeiro]

Tomás Fernández Pena escreveu:
> mvillarino escribiu:
>   
>> 2009/1/28 Antón Méixome :
>>   
>> 
 http://wiki.mancomun.org/index.php/Discusión:Corrector_ortográfico_para_OpenOffice.org
   
 
>> daemon: acrónimo de Disk Activity and Exchange MONitor, polo que
>> "demoño" non é válido no eido da ciencia da computación e tecnoloxía
>>
>> da información.
>>   
>> 
> O nome daemon  (proceso que se executa en segundo plano) non deriva en
> principio dun acrónimo, senón que deriva directamente de "demon", do
> latín /Dæmon/ ou do grego daimôn. En castelán usase habitualmente
> "demonio" así que creo que demoño ou demo pode ser perfectamente válido.
>   
concordo com o que comenta Tomás; contodo, semelha que nem sempre 
«daemon» e «demon» som equivalentes, de maneira que poderia ser 
conveniente manté-los diferenciados:

em foldoc.org:

daemon
http://foldoc.org/contents/operatingsystem.html>/> 
/day'mn/ or /dee'mn/ (From the mythological meaning, later rationalised 
as the acronym "Disk And Execution MONitor")
[...]
Daemon and demon  are often used 
interchangeably, but seem to have distinct connotations (see demon 
). The term "daemon" was introduced to 
computing by CTSS  people (who pronounced it 
/dee'mon/) and used it to refer to what ITS  
called a dragon .

demon
1. http://foldoc.org/contents/operatingsystem.html>/> (Often used 
equivalently to daemon , especially in the 
Unix  world, where the latter spelling and 
pronunciation is considered mildly archaic). A program or part of a 
program which is not invoked explicitly, but that lies dormant waiting 
for some condition(s) to occur.
At MIT  they use "demon" for part of a program 
and "daemon" for an operating system 
 process.

>> Tipografía:
>> kerning ?
>> ___
>> G11n mailing list
>> G11n en mancomun.org
>> http://listas.mancomun.org/mailman/listinfo/g11n
>>   
>> 
>
>
>   
> 
>
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>   

 próxima parte 
Borrouse unha mensaxe que non está en formato texto plano...
Nome : gonzalo.vcf
Tipo   : text/x-vcard
Tamaño : 324 bytes
Descrición: non dispoñible
Url: 
http://listas.mancomun.org/pipermail/g11n/attachments/20090129/216fcef7/attachment.vcf
 

[G11n] WordForge Editor

[Gonçalo Cordeiro]

O WordForge parece ser máis unha ruptura do que unha evolución, en 
relación ao Pootling.
Polo que sabemos, o desenvolvemento do Pootling foi conxelado durante o 
2007, coincidindo cunha maior implicación (ou apoio) do na altura 
presidente da WordForge Foundation, Javier Solá, no proxecto KhemerOs ( 
http://www.khmeros.info/drupal/ ).

Parece, porque si é certo que se mantén aínda agora certa confusión 
entre os desenvolvementos do Pootle/Virtaal/TToolkit e os da 
WFFoundation, que houbo unha ruptura: o proxecto KhmerOs continuou co 
desenvolvemento dun cliente local e a outra parte centrouse no 
TTK/Pootle. Isto pódese apreciar nas webs dispoñíbeis: a páxina do 
Pootle mudou a certa altura o título, eliminando a referencia á 
WordForge, por exemplo. É significativo o feito de que o proxecto do 
WordForge Editor se nutre fundamentalmente das TTK.

O cliente Virtaal, que é bastante máis recente, pretende solucionar a 
cuestión do achegamento inicial á localización, simplificando o proceso 
todo o posíbel, na liña do propio Pootle.

Ambos clientes son similares, porque utilizan o TTK para as operacións 
básicas e están programados en Python. Contodo, a orientación e 
funcionalidades de ambos os aplicativos difiren grandemente.

O WordForge Editor, na versión que se anunciou, incorpora todas as 
funcionalidades que se foron colocando no 2º G11n como cliente.

O Virtaal implementa a maior parte delas (non todas, como o soporte de 
Hunspell) nunha interface gráfica que procura sobre todo a simplicidade 
da tarefa, mais que perde por iso mesmo parte do atractivo.

Ambas as aplicacións son compatíveis dentro dun mesmo fluxo de traballo, 
claro.


Felipe Gil Castiñeira escreveu:
> Curioso e confuso... (Xabier, non me refiro ao teu correo, que foi claro
> e conciso  ;-) ).
>
> Acabo de comprobar que o editor Wordforge [1] é a evolución do que fora
> a ferramenta Pootling, feita polo "Translate project" (creadores de
> Pootle e o Translate toolkit).
>
> O que me resulta chocante é que o "Translate project" abandonou Pootling
> para desenvolver a ferramenta Virtaal [3], que polo menos sobre o papel
> ten unhas características [4] que son similares ás que indica Xabier que
> ten o WordForge Editor. Ademais o "Translate project" foi durante
> bastante tempo financiado polo proxecto Wordforge.
>
> ¿Sabe alguén a que se debe esta ruptura/duplicidade?. Sería interesante
> se desde Tagen Ata puidésedes comparar as dúas ferramentas (Wordforge
> Editor e Virtaal) e comentásedes o resultado.
>
> Un saúdo!
> Felipe.
>
>
> [1] http://www.khmeros.info/drupal/?q=en/download/Translation_Editor
> [2] http://translate.sourceforge.net/wiki/pootling/index
> [3] http://translate.sourceforge.net/wiki/virtaal/index
> [4] http://translate.sourceforge.net/wiki/virtaal/features
>
>
>
>
> Xabier Seixo escribiu:
>   
>> A WordForge Foundation ( http://worforgefoundation.org ) ven de publicar
>> a versión 0.5beta1 do WordForge Editor.
>>
>> Entre as funcionalidades máis destacadas están o soporte dos formatos
>> XLIFF, TMX e TBX, ademais dun sistema de verificación ortográfica
>> baseado no Hunspell (é necesario instalar o Hunpell en local).
>>
>> En Tagen Ata estivemos avaliando as novas funcionalidades que incorpora
>> esta beta, ademais do soporte dos estándares durante esta mañá.
>>
>> Xa iremos comentando os resultados.
>>
>> Para máis información:
>> --
>> Project: wordforge  (wordforge2)
>> Package: WordForge
>> Date   : 2008-11-14 10:31
>>
>> Project "wordforge" ('wordforge2') has released the new version of
>> package
>> 'WordForge'. You can download it from SourceForge.net by following this
>> link:
>> https://sourceforge.net/project/showfiles.php?group_id=206007&release_id=595420
>>
>>
>> or browse Release Notes and ChangeLog by visiting this link:
>>
>> https://sourceforge.net/project/shownotes.php?release_id=595420
>>  
>>
>>   
>> 
>
>
> ___
> G11n mailing list
> G11n en mancomun.org
> http://listas.mancomun.org/mailman/listinfo/g11n
>
>