Re: gLabels - dúbidas

2010-07-13 Conversa mvillarino
> Si, certo. Pero o OmegaT só ten implementado que se poidan meter pares
> orixe-traducido nun só idioma. Ou polo menos até cando eu o usaba a
> miúdo. Agora só emprego o Gtranslator xa que nas últimas versións de
> desenvolvemento melloraron moitísimo o das memorias de tradución
> posibilitando metelo nunha base de datos, mysql, sqlite, ou whatever.

Entón ten/tiña un problemón.
Entendo que queres dicir que ese programa limitaba o uso de tmx no
sentido de admitir só aquelas  onte houbese unha relación 1 a 1 de
 para  e de 1 a 1 de  para , non admitindo que houbese por
súa vez outros .
Isto limita as posibilidades.


Re: gLabels - dúbidas

2010-07-13 Conversa mvillarino
>> A única razón pola que podo recomendar OmegaT para os principiantes é a
>> compatibilidade de ficheiros TMX e TBX.
>
> Algo que tamén ten o Lokalize.

Pois si, de feito melloraron moito o soporte de tbx (agora analisa a
nivel dom, como fai cos xlf). Ademais, internamente pasa os tmx a
sqlite.


Re: gLabels - dúbidas

2010-07-13 Conversa Leandro Regueiro
2010/7/13 Fran Diéguez :
>> >
>> > A forma de solucionar isto é traducir directamente o pofile, xa que este
>> > non atende a (cadeas orixe iguais = cadeas traducidas iguais).
>>
>> Non debería esto ser xusto do revés ?
>>
> O omegat propaga automaticamente as cadeas que son iguais en orixe, por
> iso eu recomendo empregar un programa adicado a pofiles, véxase Lokalize
> ou Gtranslator.
>
> A única razón pola que podo recomendar OmegaT para os principiantes é a
> compatibilidade de ficheiros TMX e TBX.

Algo que tamén ten o Lokalize.

>> En TMX (ollo, translation MEMORY exchange), cada  pode conter
>> varias  co mesmo atributo xml:lang, deste xeito, pode recollerse
>> para un mesmo texto nun idioma as diferentes traducións a outro(s)
>> idiomas)
>
> Si, certo. Pero o OmegaT só ten implementado que se poidan meter pares
> orixe-traducido nun só idioma. Ou polo menos até cando eu o usaba a
> miúdo. Agora só emprego o Gtranslator xa que nas últimas versións de
> desenvolvemento melloraron moitísimo o das memorias de tradución
> posibilitando metelo nunha base de datos, mysql, sqlite, ou whatever.
>
> Saúdos
>
> ___
> Proxecto mailing list
> Proxecto en trasno.net
> http://listas.trasno.net/listinfo/proxecto
>


Re: gLabels - dúbidas

2010-07-13 Conversa mvillarino
> Pois non é un erro, é unha feature... o OmegaT traballa ESTRITAMENTE
> como o estándar TMX é dicir pares de cadeas orixe-traducida. Isto é, se
> dúas cadeas son a mesma entón teñen a mesma tradución.
> Para solucionar isto deberían estar en dominios ou espazos de nomes
> distintos.
>
> A forma de solucionar isto é traducir directamente o pofile, xa que este
> non atende a (cadeas orixe iguais = cadeas traducidas iguais).

Non debería esto ser xusto do revés ?

Nos ficheiros po, as varias unidades de tradución non poden ter o
mesmo par de orixe (texto, comentario); veñode arranxar unha batería
destes erros nun par de ficheiros de kde (erros inseridos por min,
shemari). E esta é unha das críticas clásicas ao uniforum.

En TMX (ollo, translation MEMORY exchange), cada  pode conter
varias  co mesmo atributo xml:lang, deste xeito, pode recollerse
para un mesmo texto nun idioma as diferentes traducións a outro(s)
idiomas)


Re: gLabels - dúbidas

2010-07-13 Conversa Leandro Regueiro
2010/7/12 Fran Diéguez :
> O Lun, 12-07-2010 ás 21:34 +0200, Miguel Branco escribiu:
>>
>> Non entendo moi ben porque o OmegaT fai iso, a verdade. Será un bug
>> do
>> programa máis ca un erro de internacionalización?. Abre o .po cun
>> editor de
>> texto calquera e cambia como vexas. Os de pt_PT e pt_BR fixeron o
>> seguinte:
>
> Pois non é un erro, é unha feature... o OmegaT traballa ESTRITAMENTE
> como o estándar TMX é dicir pares de cadeas orixe-traducida. Isto é, se
> dúas cadeas son a mesma entón teñen a mesma tradución.
>
> Para solucionar isto deberían estar en dominios ou espazos de nomes
> distintos.
>
> A forma de solucionar isto é traducir directamente o pofile, xa que este
> non atende a (cadeas orixe iguais = cadeas traducidas iguais).
>
> Se vos animades o próximo xoves ou venres estará un dos autores do
> Gtranslator na GUADEC e se podo asistir tenho varias cousas que
> comentarlle para que o implementen:
>
>  -  Compatibilidade para glosarios TBX
>  -  Compatibilidade para memorias de tradución TMX
>  - Remisión de traducións a repositorios de forma automatizada.
>    * Git
>    * Svn
>
> e algunha cousa máis que me deixo no tinteiro.

Eu tamén intentarei estar alí para facer algo semellante :)

Respecto ao de "Carta de US" pode que veña de aquí:
http://wiki.trasno.net/Formatos_de_papel_anglosax%C3%B3ns


Re: gLabels - dúbidas

2010-07-13 Conversa mvillarino
> Si, certo. Pero o OmegaT só ten implementado que se poidan meter pares
> orixe-traducido nun só idioma. Ou polo menos até cando eu o usaba a
> miúdo. Agora só emprego o Gtranslator xa que nas últimas versións de
> desenvolvemento melloraron moitísimo o das memorias de tradución
> posibilitando metelo nunha base de datos, mysql, sqlite, ou whatever.

Entón ten/tiña un problemón.
Entendo que queres dicir que ese programa limitaba o uso de tmx no
sentido de admitir só aquelas  onte houbese unha relación 1 a 1 de
 para  e de 1 a 1 de  para , non admitindo que houbese por
súa vez outros .
Isto limita as posibilidades.
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto


Re: gLabels - dúbidas

2010-07-13 Conversa mvillarino
>> A única razón pola que podo recomendar OmegaT para os principiantes é a
>> compatibilidade de ficheiros TMX e TBX.
>
> Algo que tamén ten o Lokalize.

Pois si, de feito melloraron moito o soporte de tbx (agora analisa a
nivel dom, como fai cos xlf). Ademais, internamente pasa os tmx a
sqlite.
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto


Re: gLabels - dúbidas

2010-07-13 Conversa Leandro Regueiro
2010/7/13 Fran Diéguez :
>> >
>> > A forma de solucionar isto é traducir directamente o pofile, xa que este
>> > non atende a (cadeas orixe iguais = cadeas traducidas iguais).
>>
>> Non debería esto ser xusto do revés ?
>>
> O omegat propaga automaticamente as cadeas que son iguais en orixe, por
> iso eu recomendo empregar un programa adicado a pofiles, véxase Lokalize
> ou Gtranslator.
>
> A única razón pola que podo recomendar OmegaT para os principiantes é a
> compatibilidade de ficheiros TMX e TBX.

Algo que tamén ten o Lokalize.

>> En TMX (ollo, translation MEMORY exchange), cada  pode conter
>> varias  co mesmo atributo xml:lang, deste xeito, pode recollerse
>> para un mesmo texto nun idioma as diferentes traducións a outro(s)
>> idiomas)
>
> Si, certo. Pero o OmegaT só ten implementado que se poidan meter pares
> orixe-traducido nun só idioma. Ou polo menos até cando eu o usaba a
> miúdo. Agora só emprego o Gtranslator xa que nas últimas versións de
> desenvolvemento melloraron moitísimo o das memorias de tradución
> posibilitando metelo nunha base de datos, mysql, sqlite, ou whatever.
>
> 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


Re: gLabels - dúbidas

2010-07-13 Conversa Fran Diéguez
> >
> > A forma de solucionar isto é traducir directamente o pofile, xa que este
> > non atende a (cadeas orixe iguais = cadeas traducidas iguais).
> 
> Non debería esto ser xusto do revés ?
> 
O omegat propaga automaticamente as cadeas que son iguais en orixe, por
iso eu recomendo empregar un programa adicado a pofiles, véxase Lokalize
ou Gtranslator.

A única razón pola que podo recomendar OmegaT para os principiantes é a
compatibilidade de ficheiros TMX e TBX.


> En TMX (ollo, translation MEMORY exchange), cada  pode conter
> varias  co mesmo atributo xml:lang, deste xeito, pode recollerse
> para un mesmo texto nun idioma as diferentes traducións a outro(s)
> idiomas)

Si, certo. Pero o OmegaT só ten implementado que se poidan meter pares
orixe-traducido nun só idioma. Ou polo menos até cando eu o usaba a
miúdo. Agora só emprego o Gtranslator xa que nas últimas versións de
desenvolvemento melloraron moitísimo o das memorias de tradución
posibilitando metelo nunha base de datos, mysql, sqlite, ou whatever.

Saúdos

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


Re: gLabels - dúbidas

2010-07-13 Conversa mvillarino
> Pois non é un erro, é unha feature... o OmegaT traballa ESTRITAMENTE
> como o estándar TMX é dicir pares de cadeas orixe-traducida. Isto é, se
> dúas cadeas son a mesma entón teñen a mesma tradución.
> Para solucionar isto deberían estar en dominios ou espazos de nomes
> distintos.
>
> A forma de solucionar isto é traducir directamente o pofile, xa que este
> non atende a (cadeas orixe iguais = cadeas traducidas iguais).

Non debería esto ser xusto do revés ?

Nos ficheiros po, as varias unidades de tradución non poden ter o
mesmo par de orixe (texto, comentario); veñode arranxar unha batería
destes erros nun par de ficheiros de kde (erros inseridos por min,
shemari). E esta é unha das críticas clásicas ao uniforum.

En TMX (ollo, translation MEMORY exchange), cada  pode conter
varias  co mesmo atributo xml:lang, deste xeito, pode recollerse
para un mesmo texto nun idioma as diferentes traducións a outro(s)
idiomas)
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto


Re: gLabels - dúbidas

2010-07-13 Conversa Fran Diéguez
Ola rapaces,

estou un pouco alleo ao de "Carta de US" xa que non lembro que pasara
por diante minha. De todas formas cando haxa un consenso tento buscar no
GNOME para  corrixir se procede.

Saúdos

O Mar, 13-07-2010 ás 12:39 +0200, Leandro Regueiro escribiu:
> 2010/7/12 Fran Diéguez :
> > O Lun, 12-07-2010 ás 21:34 +0200, Miguel Branco escribiu:
> >>
> >> Non entendo moi ben porque o OmegaT fai iso, a verdade. Será un bug
> >> do
> >> programa máis ca un erro de internacionalización?. Abre o .po cun
> >> editor de
> >> texto calquera e cambia como vexas. Os de pt_PT e pt_BR fixeron o
> >> seguinte:
> >
> > Pois non é un erro, é unha feature... o OmegaT traballa ESTRITAMENTE
> > como o estándar TMX é dicir pares de cadeas orixe-traducida. Isto é, se
> > dúas cadeas son a mesma entón teñen a mesma tradución.
> >
> > Para solucionar isto deberían estar en dominios ou espazos de nomes
> > distintos.
> >
> > A forma de solucionar isto é traducir directamente o pofile, xa que este
> > non atende a (cadeas orixe iguais = cadeas traducidas iguais).
> >
> > Se vos animades o próximo xoves ou venres estará un dos autores do
> > Gtranslator na GUADEC e se podo asistir tenho varias cousas que
> > comentarlle para que o implementen:
> >
> >  -  Compatibilidade para glosarios TBX
> >  -  Compatibilidade para memorias de tradución TMX
> >  - Remisión de traducións a repositorios de forma automatizada.
> >* Git
> >* Svn
> >
> > e algunha cousa máis que me deixo no tinteiro.
> 
> Eu tamén intentarei estar alí para facer algo semellante :)
> 
> Respecto ao de "Carta de US" pode que veña de aquí:
> http://wiki.trasno.net/Formatos_de_papel_anglosax%C3%B3ns
> ___
> Proxecto mailing list
> Proxecto@trasno.net
> http://listas.trasno.net/listinfo/proxecto


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


Re: gLabels - dúbidas

2010-07-13 Conversa Leandro Regueiro
2010/7/12 Fran Diéguez :
> O Lun, 12-07-2010 ás 21:34 +0200, Miguel Branco escribiu:
>>
>> Non entendo moi ben porque o OmegaT fai iso, a verdade. Será un bug
>> do
>> programa máis ca un erro de internacionalización?. Abre o .po cun
>> editor de
>> texto calquera e cambia como vexas. Os de pt_PT e pt_BR fixeron o
>> seguinte:
>
> Pois non é un erro, é unha feature... o OmegaT traballa ESTRITAMENTE
> como o estándar TMX é dicir pares de cadeas orixe-traducida. Isto é, se
> dúas cadeas son a mesma entón teñen a mesma tradución.
>
> Para solucionar isto deberían estar en dominios ou espazos de nomes
> distintos.
>
> A forma de solucionar isto é traducir directamente o pofile, xa que este
> non atende a (cadeas orixe iguais = cadeas traducidas iguais).
>
> Se vos animades o próximo xoves ou venres estará un dos autores do
> Gtranslator na GUADEC e se podo asistir tenho varias cousas que
> comentarlle para que o implementen:
>
>  -  Compatibilidade para glosarios TBX
>  -  Compatibilidade para memorias de tradución TMX
>  - Remisión de traducións a repositorios de forma automatizada.
>    * Git
>    * Svn
>
> e algunha cousa máis que me deixo no tinteiro.

Eu tamén intentarei estar alí para facer algo semellante :)

Respecto ao de "Carta de US" pode que veña de aquí:
http://wiki.trasno.net/Formatos_de_papel_anglosax%C3%B3ns
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto


Re: gLabels - dúbidas

2010-07-13 Conversa Gonçalo Cordeiro

Em 12-07-2010 20:52, Carlos Real escreveu:

Ola:

Case teño rematada a tradución do gLabels pero atopei algúns problemass
que preciso consultar con vos.

1/ Hai unhas etiquetas nunha xanela que están feitas de tres pezas, así:

1   2   3
5.  Horiz.  waste (overprint allowed)
5.  Desperdicio horizontal (permítese a sobreimpresión)

6.  Vert.   waste (overprint allowed)
6.  Desperdicio vertical (permítese a sobreimpresión)

Modificando o texto das etiquetas 2 e 3 arránxase o problema pero
resulta que a etiqueta seguinte é igual, cambiando  vertical por
horizontal. O problema aparece ó querer cambiar as dúas etiquetas porque
o OmegaT recoñece que as dúas partes 3 son iguais en inglés e ao poñelas
en galego cambia unha delas automaticamente, polo que quedan dúas
etiquetas iguais. Non vexo xeito de evitar este cambio en OmegaT, así
que supoño que terei que facer o cambio a man no .po con calquera
procesador de textos. É correcto?
   
Nom sei se entendo correctamente o problema, sem ver como estám escritas 
as cadeias no PO, mas talvez poderias tentar desactivar a "propagaçom 
automática" de traduçons no OmegaT. Se tes activada esta opçom, o 
aplicativo reconhece umha coincidência se ela já foi traduzida 
anteriormente no mesmo ficheiro ou projecto.
Entendo que está relacionado com esta memória temporal, e nom com a 
aplicaçom da TMX; porém, a TMX que se gerará a partir desta traduçom 
manterá esta inconsistência. Umha soluçom seria o que sinala Fran: 
contactar com as pessoas desenvolvedoras para que resegmentem estes 
fragmentos.


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


Re: gLabels - dúbidas

2010-07-12 Conversa marcoslansgarza
A miña experiencia pequena co omegaT ensinoume que polo de agora non é
un aplicativo indicado para traballar con ficheiros po.

O Lun, 12-07-2010 ás 22:23 +0200, Fran Diéguez escribiu:
> O Lun, 12-07-2010 ás 21:34 +0200, Miguel Branco escribiu:
> > 
> > Non entendo moi ben porque o OmegaT fai iso, a verdade. Será un bug
> > do 
> > programa máis ca un erro de internacionalización?. Abre o .po cun
> > editor de 
> > texto calquera e cambia como vexas. Os de pt_PT e pt_BR fixeron o
> > seguinte: 
> 
> Pois non é un erro, é unha feature... o OmegaT traballa ESTRITAMENTE
> como o estándar TMX é dicir pares de cadeas orixe-traducida. Isto é, se
> dúas cadeas son a mesma entón teñen a mesma tradución.
> 
> Para solucionar isto deberían estar en dominios ou espazos de nomes
> distintos.
> 
> A forma de solucionar isto é traducir directamente o pofile, xa que este
> non atende a (cadeas orixe iguais = cadeas traducidas iguais).
> 
> Se vos animades o próximo xoves ou venres estará un dos autores do
> Gtranslator na GUADEC e se podo asistir tenho varias cousas que
> comentarlle para que o implementen:
> 
>  -  Compatibilidade para glosarios TBX
>  -  Compatibilidade para memorias de tradución TMX
>  - Remisión de traducións a repositorios de forma automatizada.
> * Git
> * Svn
> 
> e algunha cousa máis que me deixo no tinteiro.
> 
> 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


Re: gLabels - dúbidas

2010-07-12 Conversa Fran Diéguez
O Lun, 12-07-2010 ás 21:34 +0200, Miguel Branco escribiu:
> 
> Non entendo moi ben porque o OmegaT fai iso, a verdade. Será un bug
> do 
> programa máis ca un erro de internacionalización?. Abre o .po cun
> editor de 
> texto calquera e cambia como vexas. Os de pt_PT e pt_BR fixeron o
> seguinte: 

Pois non é un erro, é unha feature... o OmegaT traballa ESTRITAMENTE
como o estándar TMX é dicir pares de cadeas orixe-traducida. Isto é, se
dúas cadeas son a mesma entón teñen a mesma tradución.

Para solucionar isto deberían estar en dominios ou espazos de nomes
distintos.

A forma de solucionar isto é traducir directamente o pofile, xa que este
non atende a (cadeas orixe iguais = cadeas traducidas iguais).

Se vos animades o próximo xoves ou venres estará un dos autores do
Gtranslator na GUADEC e se podo asistir tenho varias cousas que
comentarlle para que o implementen:

 -  Compatibilidade para glosarios TBX
 -  Compatibilidade para memorias de tradución TMX
 - Remisión de traducións a repositorios de forma automatizada.
* Git
* Svn

e algunha cousa máis que me deixo no tinteiro.

Saúdos.

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


Re: gLabels - dúbidas

2010-07-12 Conversa Miguel Branco
O Luns 12 Xullo 2010 20:52:03 Carlos Real escribiu:

> Modificando o texto das etiquetas 2 e 3 arránxase o problema pero
> resulta que a etiqueta seguinte é igual, cambiando  vertical por
> horizontal. O problema aparece ó querer cambiar as dúas etiquetas porque
> o OmegaT recoñece que as dúas partes 3 son iguais en inglés e ao poñelas
> en galego cambia unha delas automaticamente, polo que quedan dúas
> etiquetas iguais. Non vexo xeito de evitar este cambio en OmegaT, así
> que supoño que terei que facer o cambio a man no .po con calquera
> procesador de textos. É correcto?

Non entendo moi ben porque o OmegaT fai iso, a verdade. Será un bug do 
programa máis ca un erro de internacionalización?. Abre o .po cun editor de 
texto calquera e cambia como vexas. Os de pt_PT e pt_BR fixeron o seguinte: 

> #: ../data/glade/template-designer.glade.h:14
> msgid "4. Horiz. waste (overprint allowed):"
> msgstr "4. Desperdício horizontal (impressão sobreposta permitida):"
> 
> #: ../data/glade/template-designer.glade.h:15
> msgid "5. Vert. waste (overprint allowed):"
> msgstr "5. Desperdício vertical (impressão sobreposta permitida):"


> 2/ Alguén sabe ou ten idea de como se chama en galego ás carpetas con
> aneis de ferro para meter nelas follas furadas? Eu sempre falei de
> "carpeta de anillas" ou de "archivadores" (estas que van moitas veces
> dentro dunha caixa e poden conter unha cantidade de follas grande), pero
> isto é castelán, evidentemente. O nome portugués é "pastas de arquivo" e
> me parece que non se entendería ben. Algunha suxestión?

Supoño que simplemente "arquivador", como di Adrián.  O digalego di:
>s m Moble ou caixa utilizada para gardar documentos, fichas ou outros papeis.

> 3/ Vexo que no Gnome tradúcense os nomes dos formatos de papel
> americanos así:
> US Letter -> Carta de US
> 
> ¿A abreviatura de Estados Unidos déixase así sempre?
Si, semella un erro. Como di Adrián, ou EE.UU ou EUA. Eu prefiro o segundo 
anacrónico, que é máis fidedigno ao orixinal ianqui USA, ademais de ser 
específico, son os "estados unidos" pero dalgún lado, "de América". 

Só unha nota, o par ¿? xa non se usa na nova norma, só ? ao remate, bardante 
de que se o contexto faga difícil ao lector distinguila dunha enunciativa, 
nese caso si, recorrese ao ¿?. 


signature.asc
Description: This is a digitally signed message part.
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto


Re: gLabels - dúbidas

2010-07-12 Conversa Adrián Chaves Fernández
> 3/ Vexo que no Gnome tradúcense os nomes dos formatos de papel
> americanos así:
> US Letter -> Carta de US
> 
> ¿A abreviatura de Estados Unidos déixase así sempre?

Sospeito que se trata dun erro. US → EE.UU. (pode confirmalo alguén?)


signature.asc
Description: This is a digitally signed message part.
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto


Re: gLabels - dúbidas

2010-07-12 Conversa Adrián Chaves Fernández
> 2/ Alguén sabe ou ten idea de como se chama en galego ás carpetas con
> aneis de ferro para meter nelas follas furadas? Eu sempre falei de
> "carpeta de anillas" ou de "archivadores" (estas que van moitas veces
> dentro dunha caixa e poden conter unha cantidade de follas grande), pero
> isto é castelán, evidentemente. O nome portugués é "pastas de arquivo" e
> me parece que non se entendería ben. Algunha suxestión?

Arquivadores?


signature.asc
Description: This is a digitally signed message part.
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto


Re: gLabels - dúbidas

2010-07-12 Conversa Adrián Chaves Fernández
> 1/ Hai unhas etiquetas nunha xanela que están feitas de tres pezas, así:
> 
> 1 2   3
> 5.Horiz.  waste (overprint allowed)
> 5.Desperdicio horizontal (permítese a sobreimpresión)
> 
> 6.Vert.   waste (overprint allowed)
> 6.Desperdicio vertical (permítese a sobreimpresión)
> 
> Modificando o texto das etiquetas 2 e 3 arránxase o problema pero
> resulta que a etiqueta seguinte é igual, cambiando  vertical por
> horizontal. O problema aparece ó querer cambiar as dúas etiquetas porque
> o OmegaT recoñece que as dúas partes 3 son iguais en inglés e ao poñelas
> en galego cambia unha delas automaticamente, polo que quedan dúas
> etiquetas iguais. Non vexo xeito de evitar este cambio en OmegaT, así
> que supoño que terei que facer o cambio a man no .po con calquera
> procesador de textos. É correcto?

Sospeito que o cambio hai que facelo no ficheiro orixinal en inglés. Coido que 
terás que informar aos desenvolvedores (encargados da internacionalización) de
que na túa lingua se traducen distinto, para que o internacionalicen 
correctamente (e o novo POT simplemente terḉas que mesturalo co teu PO 
actual).

Falo asumindo que se traducen distinto, que realmente non o sei.


signature.asc
Description: This is a digitally signed message part.
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto