Re: [Pology] varias cuestións sobre as regras
2012/3/8 mvillarino mvillar...@kde-espana.es: /home/leo/Escritorio/bash-4.2.gl.po:2645(#486) #: builtins.c:525 msgid Define local variables.\n msgstr Define variábeis locais.\n [note] rule [id=PT-2011-gl_bel] == terminación en -bel Falla no plural. Creo que isto é moi importante arranxalo porque se da moitas veces Anótoma. Verei de modificala. Non falla por ese variábeis, senón por un visibles que hai máis abaixo nesa mensaxe (a de builtins.c:525) Xa, é que acurtei un pouco os textos para non sobrecargar a mensaxe. O texto completo é este: /home/leo/Escritorio/bash-4.2.gl.po:2645(#486) #: builtins.c:525 msgid Define local variables.\n \n Create a local variable called NAME, and give it VALUE. OPTION can\n be any option accepted by `declare'.\n \n Local variables can only be used within a function; they are visible\n only to the function where they are defined and its children.\n \n Exit Status:\n Returns success unless an invalid option is supplied, an error occurs,\n or the shell is not executing a function. msgstr Define variábeis locais.\n \n Crea unha variábel local chamada NOME, e dalle un VALOR. OPCIÓN pode\n ser calquera opción aceptada por `declare'.\n \n As variábeis locais só se pueden usar nunha función; son visibles\n só na función onde se definen e os seus fillos.\n \n Estado de Saída:\n Devolve con éxito a menos que se dea unha opción non válida, se produza\n un erro, ou o shell non estea executando unha función. [note] rule [id=PT-2011-gl_bel] == terminación en -bel E si que canta por «variábeis». Esta regra cántame 10 fallos, pero sete deles con en textos que parecen non traducíbeis. Creo que nesta regra vai ser mellor que dea falsos positivos para evitar que se escape algún -ble ou -bles. Deica ___ Proxecto mailing list Proxecto@trasno.net http://listas.trasno.net/listinfo/proxecto
Re: [Pology] varias cuestións sobre as regras
2012/3/9 Leandro Regueiro leandro.regue...@gmail.com: Creo que nesta regra vai ser mellor que dea falsos positivos para evitar que se escape algún -ble ou -bles. Tal vez non. Hoxe estou algo canso e non hei mirar nada á noite, pero penso que abonda con admitir os casos nos que o texto que case coa regra á vez cumpra que non conteña caracteres outros que letras con ou sen trazos polo medio (algo como que \b[\w\-]+bles? deba cumprir á vez algo como isto: # Prefírese a terminación en bel [\b[\w\-]+bles?\s]i valid span=(fe|ca|dou|tre|ipta)bles? valid !span=[^\-_]+ # aquí comprobar que non contén - nin _ id=leandroTest hint=terminación en -bel e para probala terás que metela nun ficheiro que teña o nome acadado en .rules, e ao correr o posieve check-rules engadir a opción -srulerx:leandroTest. ___ Proxecto mailing list Proxecto@trasno.net http://listas.trasno.net/listinfo/proxecto
Re: [Pology] varias cuestións sobre as regras
En Wed, 07 Mar 2012 20:45:49 +0100, Leandro Regueiro leandro.regue...@gmail.com escribió: Olá, Xesús: teño un usuario ! As regras están, algunhas, un pouco coma o carallo debido ao anterior: como non hai resposta (máis aló de Fran a cada e cando) pois faigo o que me vai parecendo. Se a iso sumamos que non hai, que eu saiba, un documento oficial non modificábel que resuma os acordos _sólidos_ acadados, pois resulta en que as regras sexan en moita medida inexactas. Porén, á medida que fun aprendendo a usar o equip-header a cousa mellorou. Recomendo(che/vos) que equipedes as vosas cabeceiras, supoño que co campo de ambiente gnome ou algo así. Agora vou comentando: /home/leo/Escritorio/bash-4.2.gl.po:2645(#486) #: builtins.c:525 msgid Define local variables.\n msgstr Define variábeis locais.\n [note] rule [id=PT-2011-gl_bel] == terminación en -bel Falla no plural. Creo que isto é moi importante arranxalo porque se da moitas veces Anótoma. Verei de modificala. Mándame o ficheiro para poder probala. /home/leo/Escritorio/bash-4.2.gl.po:385(#75) #: builtins/exit.def:88 msgid not login shell: use `exit' msgstr non é un shell de entrada: use `exit' [note] rule [id=noPT-2011_quit] == «quit», «exit» tradúcense como «saír» A veces «quit» e «exit» non se deben traducir. Creo que aquí habería que facer o mesmo que se fixo coa regra de «window» Ás veces non se debe traducir, como é o caso de nomes de ordes e funcións de programación. Pero é extremadamente difícil recoñecer estes casos, de feito non se me ocurre como poder facelo. Entón, só teño dúas solucións (e maliñas): ou silenciar o pology (ver documentación) para esta mensaxe e regra, ou aceptar un pouco de ruído de falsos positivos. /home/leo/Escritorio/bash-4.2.gl.po:463(#91) #: builtins/help.def:337 #, c-format msgid Type `help name' to find out more about the function `name'.\n msgstr Teclee `help nome' para saber máis sobre a función `nome'.\n [note] rule [id=noPT-2010_find] == «find» tradúcese como «atopar», ou «buscar» cando aparece «find out» no texto orixinal salta esta regra, e non debería Motivo: o phrasal find out non debe seguir a regra xeral de find-atopar/buscar. Podo, se tal, meter unha regra específica para find out, pero: a) ou é para un ambiente concreto (kde, gnome, bittorrent, ...), i.e., é unha escolla específica dun proxecto, b) ou se acorda unha tradución para find out nunha trasnada. /home/leo/Escritorio/bash-4.2.gl.po:551(#107) #: builtins/mapfile.def:354 msgid array variable support required msgstr requírese a compatibilidade de variábel de matriz [note] rule [id=noPT-2011_support] == «support» tradúcese como «asistencia técnica», «ser compatíbel con», «admitir», «permitir utilizar», «incluír» Aínda que é certo que se nos pasou incluír «compatibilidade» ao discutir, creo que todos estamos máis ou menos de acordo con isto Bu, a regra de support... mira, póñaa como a poña, ha petar. Anótome pór compatibilidade, pero polo amor de quen queirades: limitai as opcións, porque a efeitos práticos está case que a converterse en calquera cousa traduce a support. /home/leo/Escritorio/bash-4.2.gl.po:1589(#309) #: siglist.c:87 msgid Killed msgstr Matado [note] rule [id=PT-2011_kill] == «kill» tradúcese como «matar» Creo que é evidente o que falla Anótoma. Ademais mirando mensaxes de fíos que tiña pendentes de ler atopei cousas que se deberían arranxar, pero que non sei se se arranxaron xa: msgid Ico_nify msgstr Ico_nificar [note] rule [id=PT-2011_icon] == «icon» tradúcese como «icona» Esta regra non debería aplicarse Penso que a modifiquei para que non salte se atopa icon antes de if+algo. Creo que é aceptable incluír «compatibilidade» e «compatíbel» Vid supra. [note] rule [id=noPT-2011_font] == «font» tradúcese como «letra» (e «fonte tipográfica» Que eu saiba as únicas traducións acordadas son «tipo de letra» ou «letra» (para tradución interpretativa) Míramo, anda, que é posíbel que me comese algo nesta regra (falta un paréntese ao final do ==, e penso que puido haber un fallo ao cortar e apegar. [note] rule [id=noPT-2010_hide] == «hide» tradúcese como «acochar» Isto aínda non se decidiu. Aínda que xa o puxen para discutilo (outra vez) na seguinte Trasnada. [note] rule [id=noPT-2011_support] == «support» tradúcese como «asistencia técnica», «ser compatíbel con», «admitir», «permitir utilizar», «incluír» As opcións acordadas non son todas esas: http://trasno.net/ficheiros/upload/resultados_trasnadas/glosario_trasnada11.1_so_recomendadas.tbx Só asistencia técnica e compatibilidade ? Por min macanudo! [note] rule [id=noPT-2010_locate] == «locate» tradúcese como «atopar», «buscar», «situar» ou «colocar» As opcións
Re: [Pology] varias cuestións sobre as regras
2012/3/7 Xosé xoseca...@gmail.com: [note] rule [id=noPT-2010_hide] == «hide» tradúcese como «acochar» Isto aínda non se decidiu. Aínda que xa o puxen para discutilo (outra vez) na seguinte Trasnada. Eu penso que se acordou que fose «agochar», que «acochar» é cando o porco fai a cama e, de facto, estíveno a modificar ultimamente. Repito. Discutiuse, non se chegou a nada definitivo en dúas Trasnadas e téñoo anotado como posposto. Iso si, como na seguinte non cheguemos a un acordo xa é preocupante. Levádea preparada que xa vos estou avisando con tempo suficiente de que «hide/show/print/display» entra seguro. Deica ___ Proxecto mailing list Proxecto@trasno.net http://listas.trasno.net/listinfo/proxecto
Re: [Pology] varias cuestións sobre as regras
2011/11/24 mvillarino mvillar...@gmail.com: En Wed, 07 Mar 2012 20:45:49 +0100, Leandro Regueiro leandro.regue...@gmail.com escribió: Olá, Xesús: teño un usuario ! As regras están, algunhas, un pouco coma o carallo debido ao anterior: como non hai resposta (máis aló de Fran a cada e cando) pois faigo o que me vai parecendo. Se a iso sumamos que non hai, que eu saiba, un documento oficial non modificábel que resuma os acordos _sólidos_ acadados, pois resulta en que as regras sexan en moita medida inexactas. Como documento oficial non modificábel tes o ficheiro TBX: http://trasno.net/ficheiros/upload/resultados_trasnadas/glosario_trasnada11.1_so_recomendadas.tbx Entendo que un bastante dificil como documento de consulta para un humano e para ese caso por agora está o documento https://docs.google.com/document/d/1GPgi9VTsEqT2G5VeI0VLJO4xSBih1kUndyEEaqBeX5Y/edit?authkey=CPG9uaIG onde está a lista dos termos a discutir no futuro e PARTE dos acordos aos que se chegou. Teño pendente xerar un documento ODT que resuma todos os acordos, porque incluso na segunda Trasnada aceptei algúns acordos adoptados posteriormente na rolda de correo. O certo é que tería que escribir algúns scripts para facilitarme a vida ao pasar os acordos das Trasnadas, buscar cales serían os termos que sería mellor incluír polo seu maior impacto (o da conflitividade e máis subxectivo), e para obter un TBX que xunte os acordos das Trasnadas co anterior glosario de Trasno eliminando as entradas deste último que se trataron nas Trasnadas. Se me poño tamén é probábel que faga outro script para pasar o TBX das Trasnadas a outro formato máis lexíbel. Porén, á medida que fun aprendendo a usar o equip-header a cousa mellorou. Recomendo(che/vos) que equipedes as vosas cabeceiras, supoño que co campo de ambiente gnome ou algo así. Agora vou comentando: /home/leo/Escritorio/bash-4.2.gl.po:2645(#486) #: builtins.c:525 msgid Define local variables.\n msgstr Define variábeis locais.\n [note] rule [id=PT-2011-gl_bel] == terminación en -bel Falla no plural. Creo que isto é moi importante arranxalo porque se da moitas veces Anótoma. Verei de modificala. Mándame o ficheiro para poder probala. http://translationproject.org/PO-files/gl/bash-4.2.gl.po /home/leo/Escritorio/bash-4.2.gl.po:385(#75) #: builtins/exit.def:88 msgid not login shell: use `exit' msgstr non é un shell de entrada: use `exit' [note] rule [id=noPT-2011_quit] == «quit», «exit» tradúcense como «saír» A veces «quit» e «exit» non se deben traducir. Creo que aquí habería que facer o mesmo que se fixo coa regra de «window» Ás veces non se debe traducir, como é o caso de nomes de ordes e funcións de programación. Pero é extremadamente difícil recoñecer estes casos, de feito non se me ocurre como poder facelo. Entón, só teño dúas solucións (e maliñas): ou silenciar o pology (ver documentación) para esta mensaxe e regra, ou aceptar un pouco de ruído de falsos positivos. Outra opción. A ver se me explico. Na primeira Trasnada acordouse que «window» se traduciria como «xanela». Uns días despois fixeches a regra correspondente para o Pology. Eu probei o Pology e vin que daba moitos falsos positivos por cadeas como «Microsoft Windows» ou «X Window» e decidimos que na regra tamén aceptaría a posibilidade de que «window» ou «windows» apareceran sen traducir na tradución ao galego. Ben. O que che estaba indicando é que se podía facer o mesmo para «quit» e «exit» que a veces poden aparecer traducidos e outras veces pode que aparezan sen traducir, por exemplo por ser ordes, parámetros para unha orde ou funcións de programación como dixeches. Deste xeito a veces non detectará que non se traduciu cando se debeu ter traducido, pero creo que serán poucos menos casos que de veces que non se debe traducir e salta a regra tocando as narices. /home/leo/Escritorio/bash-4.2.gl.po:463(#91) #: builtins/help.def:337 #, c-format msgid Type `help name' to find out more about the function `name'.\n msgstr Teclee `help nome' para saber máis sobre a función `nome'.\n [note] rule [id=noPT-2010_find] == «find» tradúcese como «atopar», ou «buscar» cando aparece «find out» no texto orixinal salta esta regra, e non debería Motivo: o phrasal find out non debe seguir a regra xeral de find-atopar/buscar. Podo, se tal, meter unha regra específica para find out, pero: a) ou é para un ambiente concreto (kde, gnome, bittorrent, ...), i.e., é unha escolla específica dun proxecto, b) ou se acorda unha tradución para find out nunha trasnada. E non se podería facer que a regra só se aplique cando aparece «find» pero sen estar seguido de «out»? /home/leo/Escritorio/bash-4.2.gl.po:551(#107) #: builtins/mapfile.def:354 msgid array variable support required msgstr requírese a compatibilidade
Re: [Pology] varias cuestións sobre as regras
En Thu, 08 Mar 2012 14:23:25 +0100, Leandro Regueiro
leandro.regue...@gmail.com escribió:
Entendo que un bastante dificil como documento de consulta para un
humano e para ese caso por agora está o documento
...
para comprender mellor o problema explico o meu procedemento:
- imprimo en papel o documento coas cousas a engadir ás regras
- á medida que vou metendo unha regra, risco a parte do impreso que
corresponda
- cando todo ten o risco que indica feito, pois paso a probar as regras
sobre algúns ficheiros.
- cando algunha regra dá a lata, por exemplo polo mítico problema da
polisemia, márcoa como noPT-ano_word. Ese noPT indica que non segue
estritamente o acordado, pero que se tentou, polo menos.
- despois vou metendo as porcalladas, é dicir, os casos valid
env=.
De aí que me sexa de tanta utilidade ter un ficheiro co acordado nunha
trasnada (sen discusións nin óstias, só o final), e outro para cando
coincida revisar que se adapte ao acordado.
...
http://translationproject.org/PO-files/gl/bash-4.2.gl.po
OK.
Outra opción. A ver se me explico. Na primeira Trasnada acordouse que
«window» se traduciria como «xanela». Uns días despois fixeches a
regra correspondente para o Pology. Eu probei o Pology e vin que daba
moitos falsos positivos por cadeas como «Microsoft Windows» ou «X
Window» e decidimos que na regra tamén aceptaría a posibilidade de que
«window» ou «windows» apareceran sen traducir na tradución ao galego.
Ben. O que che estaba indicando é que se podía facer o mesmo para
«quit» e «exit» que a veces poden aparecer traducidos e outras veces
pode que aparezan sen traducir, por exemplo por ser ordes, parámetros
para unha orde ou funcións de programación como dixeches. Deste xeito
a veces non detectará que non se traduciu cando se debeu ter
traducido, pero creo que serán poucos menos casos que de veces que non
se debe traducir e salta a regra tocando as narices.
Brrr, se non hai outra, pois faise.
E digo b porque o ideal sería que os textos na orixe (source code)
viñesen con etiquetado semántico, de tal xeito que o que son ordes,
nomes de ficheiros, marcas comerciais e cousas así estivesen entre
oquesexa e oquesexa/. Resulta que pology pode preprocesar os textos (e
faino), de xeito que estas cousas poden ser suprimidas ou substituídas
antes de pasar as regras.
E non se podería facer que a regra só se aplique cando aparece «find»
pero sen estar seguido de «out»?
Si, pero a ver, en case todos os casos estamos a falar do mesmo caso:
- Nas trasnadas acórdanse termos (puntos dun erre dous que ten nun erre o
conxunto de palabras e no outro erre o de definicións), pero o pology
traballa con secuencias de caracteres.
Entón, para un de nós é moi doado ver X Windows e recoñecer que se está
a referir a unha marca rexistrada para un protocolo de servizo gráfico, e
non a unha xanela.
As regras pódense pór con cantos casos concretos faiga falla. Funcionará.
Pero non deixa de ser pouco elegante. Estes casos excepcionais, polo
menos aqueles que non sexan por nomes comerciais, deberían ser tratados
tamén na trasnada (por quitar algún noPT, non por outra cousa).
# «icon» tradúcese como «icona»
{\bicon}i
valid before=if.
id=PT-2011_icon
valid msgstr=\bicon(a|iz)
hint=«icon» tradúcese como «icona»
Se non entendo mal vale que a tradución teña «icona» ou «iconiz»
(supoño que por «iconizar»). Preferiría que houbera dúas regras, unha
para «icon» e outra para «iconify». Por certo, «iconify» é algo que
aínda non se tratou, polo que para ser xustos non debería ter regra
con identificador PT.
Entendiche ven. O de meter o if. aquí é para que esta regra non se
aplique ao verbo iconify, se algún día hai unha regra para este, pois
haberá que meter unha regra nova.
Eu poríaa así (revisar por se metín a zoca na sintaxe):
# «font» tradúcese como «letra»
{\bfont}i
id=noPT-2011_font
valid msgstr=\btipo\sde\sletra == \btipos?\sde\sletra, para que
colla o plural.
--
BRGDS
Marce Villarino
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto
Re: [Pology] varias cuestións sobre as regras
2011/11/24 mvillarino mvillar...@gmail.com:
En Thu, 08 Mar 2012 14:23:25 +0100, Leandro Regueiro
leandro.regue...@gmail.com escribió:
Entendo que un bastante dificil como documento de consulta para un
humano e para ese caso por agora está o documento
...
para comprender mellor o problema explico o meu procedemento:
- imprimo en papel o documento coas cousas a engadir ás regras
- á medida que vou metendo unha regra, risco a parte do impreso que
corresponda
- cando todo ten o risco que indica feito, pois paso a probar as regras
sobre algúns ficheiros.
- cando algunha regra dá a lata, por exemplo polo mítico problema da
polisemia, márcoa como noPT-ano_word. Ese noPT indica que non segue
estritamente o acordado, pero que se tentou, polo menos.
- despois vou metendo as porcalladas, é dicir, os casos valid
env=.
De aí que me sexa de tanta utilidade ter un ficheiro co acordado nunha
trasnada (sen discusións nin óstias, só o final), e outro para cando
coincida revisar que se adapte ao acordado.
Vou intentar facelo. Levarame algún tempo.
...
http://translationproject.org/PO-files/gl/bash-4.2.gl.po
OK.
Outra opción. A ver se me explico. Na primeira Trasnada acordouse que
«window» se traduciria como «xanela». Uns días despois fixeches a
regra correspondente para o Pology. Eu probei o Pology e vin que daba
moitos falsos positivos por cadeas como «Microsoft Windows» ou «X
Window» e decidimos que na regra tamén aceptaría a posibilidade de que
«window» ou «windows» apareceran sen traducir na tradución ao galego.
Ben. O que che estaba indicando é que se podía facer o mesmo para
«quit» e «exit» que a veces poden aparecer traducidos e outras veces
pode que aparezan sen traducir, por exemplo por ser ordes, parámetros
para unha orde ou funcións de programación como dixeches. Deste xeito
a veces non detectará que non se traduciu cando se debeu ter
traducido, pero creo que serán poucos menos casos que de veces que non
se debe traducir e salta a regra tocando as narices.
Brrr, se non hai outra, pois faise.
E digo b porque o ideal sería que os textos na orixe (source code)
viñesen con etiquetado semántico, de tal xeito que o que son ordes, nomes
de ficheiros, marcas comerciais e cousas así estivesen entre oquesexa e
oquesexa/. Resulta que pology pode preprocesar os textos (e faino), de
xeito que estas cousas poden ser suprimidas ou substituídas antes de pasar
as regras.
E non se podería facer que a regra só se aplique cando aparece «find»
pero sen estar seguido de «out»?
Si, pero a ver, en case todos os casos estamos a falar do mesmo caso:
- Nas trasnadas acórdanse termos (puntos dun erre dous que ten nun erre o
conxunto de palabras e no outro erre o de definicións), pero o pology
traballa con secuencias de caracteres.
Entón, para un de nós é moi doado ver X Windows e recoñecer que se está a
referir a unha marca rexistrada para un protocolo de servizo gráfico, e non
a unha xanela.
As regras pódense pór con cantos casos concretos faiga falla. Funcionará.
Pero non deixa de ser pouco elegante. Estes casos excepcionais, polo menos
aqueles que non sexan por nomes comerciais, deberían ser tratados tamén na
trasnada (por quitar algún noPT, non por outra cousa).
# «icon» tradúcese como «icona»
{\bicon}i
valid before=if.
id=PT-2011_icon
valid msgstr=\bicon(a|iz)
hint=«icon» tradúcese como «icona»
Se non entendo mal vale que a tradución teña «icona» ou «iconiz»
(supoño que por «iconizar»). Preferiría que houbera dúas regras, unha
para «icon» e outra para «iconify». Por certo, «iconify» é algo que
aínda non se tratou, polo que para ser xustos non debería ter regra
con identificador PT.
Entendiche ven. O de meter o if. aquí é para que esta regra non se aplique
ao verbo iconify, se algún día hai unha regra para este, pois haberá que
meter unha regra nova.
Eu poríaa así (revisar por se metín a zoca na sintaxe):
# «font» tradúcese como «letra»
{\bfont}i
id=noPT-2011_font
valid msgstr=\btipo\sde\sletra == \btipos?\sde\sletra, para que
colla o plural.
Si, con plural tamén.
Deica
___
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto
Re: [Pology] varias cuestións sobre as regras
/home/leo/Escritorio/bash-4.2.gl.po:2645(#486) #: builtins.c:525 msgid Define local variables.\n msgstr Define variábeis locais.\n [note] rule [id=PT-2011-gl_bel] == terminación en -bel Falla no plural. Creo que isto é moi importante arranxalo porque se da moitas veces Anótoma. Verei de modificala. Non falla por ese variábeis, senón por un visibles que hai máis abaixo nesa mensaxe (a de builtins.c:525) Esta regra cántame 10 fallos, pero sete deles con en textos que parecen non traducíbeis. ___ Proxecto mailing list Proxecto@trasno.net http://listas.trasno.net/listinfo/proxecto
[Pology] varias cuestións sobre as regras
Ola, acabo de descargar a última versión de Pology e paseillo a un ficheiro. Detectou unha chea de erros pero hai certas regras que creo que se poderían retocar un chisco: [note] rule [id=clGL-modling_aria] == prefírese a terminación en -aría Non lembro que se teña decidido que esa terminación era a preferida. /home/leo/Escritorio/bash-4.2.gl.po:2645(#486) #: builtins.c:525 msgid Define local variables.\n msgstr Define variábeis locais.\n [note] rule [id=PT-2011-gl_bel] == terminación en -bel Falla no plural. Creo que isto é moi importante arranxalo porque se da moitas veces /home/leo/Escritorio/bash-4.2.gl.po:385(#75) #: builtins/exit.def:88 msgid not login shell: use `exit' msgstr non é un shell de entrada: use `exit' [note] rule [id=noPT-2011_quit] == «quit», «exit» tradúcense como «saír» A veces «quit» e «exit» non se deben traducir. Creo que aquí habería que facer o mesmo que se fixo coa regra de «window» /home/leo/Escritorio/bash-4.2.gl.po:463(#91) #: builtins/help.def:337 #, c-format msgid Type `help name' to find out more about the function `name'.\n msgstr Teclee `help nome' para saber máis sobre a función `nome'.\n [note] rule [id=noPT-2010_find] == «find» tradúcese como «atopar», ou «buscar» cando aparece «find out» no texto orixinal salta esta regra, e non debería /home/leo/Escritorio/bash-4.2.gl.po:551(#107) #: builtins/mapfile.def:354 msgid array variable support required msgstr requírese a compatibilidade de variábel de matriz [note] rule [id=noPT-2011_support] == «support» tradúcese como «asistencia técnica», «ser compatíbel con», «admitir», «permitir utilizar», «incluír» Aínda que é certo que se nos pasou incluír «compatibilidade» ao discutir, creo que todos estamos máis ou menos de acordo con isto /home/leo/Escritorio/bash-4.2.gl.po:1589(#309) #: siglist.c:87 msgid Killed msgstr Matado [note] rule [id=PT-2011_kill] == «kill» tradúcese como «matar» Creo que é evidente o que falla Ademais mirando mensaxes de fíos que tiña pendentes de ler atopei cousas que se deberían arranxar, pero que non sei se se arranxaron xa: msgid Ico_nify msgstr Ico_nificar [note] rule [id=PT-2011_icon] == «icon» tradúcese como «icona» Esta regra non debería aplicarse msgid Enable NRG image support msgstr Activar compatibilidade coas imaxes NRG [note] rule [id=noPT-2011_support] == «support» tradúcese como «asistencia técnica», «ser compatíbel con», «admitir», «permitir utilizar», «incluír» msgid All Supported Images msgstr Todas as imaxes compatíbeis [note] rule [id=noPT-2011_support] == «support» tradúcese como «asistencia técnica», «ser compatíbel con», «admitir», «permitir utilizar», «incluír» Creo que é aceptable incluír «compatibilidade» e «compatíbel» [note] rule [id=noPT-2011_font] == «font» tradúcese como «letra» (e «fonte tipográfica» Que eu saiba as únicas traducións acordadas son «tipo de letra» ou «letra» (para tradución interpretativa) [note] rule [id=noPT-2010_hide] == «hide» tradúcese como «acochar» Isto aínda non se decidiu. Aínda que xa o puxen para discutilo (outra vez) na seguinte Trasnada. [note] rule [id=noPT-2011_support] == «support» tradúcese como «asistencia técnica», «ser compatíbel con», «admitir», «permitir utilizar», «incluír» As opcións acordadas non son todas esas: http://trasno.net/ficheiros/upload/resultados_trasnadas/glosario_trasnada11.1_so_recomendadas.tbx [note] rule [id=noPT-2010_locate] == «locate» tradúcese como «atopar», «buscar», «situar» ou «colocar» As opcións acordadas non son todas esas: http://trasno.net/ficheiros/upload/resultados_trasnadas/glosario_trasnada11.1_so_recomendadas.tbx [note] rule [id=PT-2011_keyword] == «keyword» tradúcese como «palabra clave» (buscas) ou «palabra chave» (acceso) As opcións acordadas non son todas esas: http://trasno.net/ficheiros/upload/resultados_trasnadas/glosario_trasnada11.1_so_recomendadas.tbx [note] rule [id=noPT-2011_path] == «Path» tradúcese como «ruta» (ou secuencia de vértices) O da «secuencia de vértices» pódese quitar Deica ___ Proxecto mailing list Proxecto@trasno.net http://listas.trasno.net/listinfo/proxecto
Re: [Pology] varias cuestións sobre as regras
[note] rule [id=noPT-2010_hide] == «hide» tradúcese como «acochar» Isto aínda non se decidiu. Aínda que xa o puxen para discutilo (outra vez) na seguinte Trasnada. Eu penso que se acordou que fose «agochar», que «acochar» é cando o porco fai a cama e, de facto, estíveno a modificar ultimamente. Xosé ___ Proxecto mailing list Proxecto@trasno.net http://listas.trasno.net/listinfo/proxecto
