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 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
>
>
> Buffff, 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.

# «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.


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

Acabo de actualizar a copia local do repositorio e a regra está así:

# «font» tradúcese como «letra»
{\bfont}i
id="noPT-2011_font"
valid msgstr="\bletra"
valid msgstr="\bfonte\stipográfica"
hint="«font» tradúcese como «letra» (e «fonte tipográfica»"

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"
valid msgstr="\bletra"
hint="«font» tradúcese como «tipo de letra», ou como «letra» cando
sexa necesario"


>> [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!

Os acordos das Trasnadas foron «asistencia técnica», «ser compatíbel»,
«admitir», «permitir»

Ademais está pendente de debater na seguinte Trasnada
«compatibilidade» e que é case seguro que se vai aceptar. Méixome
indicou que «dispoñibilidade» tamén sería de agradecer, aínda que
agora mesmo non vexo para que é necesario.


>> [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
>
>
> Colocar engadínno por algún motivo.
>
> Nota: mira o ficheiro README que acompaña as regras.

Mireino e non vin a razón. Heino volver ler.


>> [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
>
>
> A min vádesme matar: o de buscas/acceso non o inventei eu, saqueino da
> rolda.

Iso está ben.

> Adicionar o de palabra reservada heino facer.

Ok, este era o fallo, que faltaba «palabra reservada».


>> [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
>
>
> Non. Está aí para cando se use nun programa de debuxo vectorial. Pero a
> regra está incompleta:
> # «Path» tradúcese como «ruta».
> {\bpath(\b|\s|s)}i
> valid after="trust\s"
> valid after="<" before=">"
> id="noPT-2011_path"
> valid msgstr="\bruta"
> valid msgstr="\bsecuencias?\sde\svértices"
> hint="«Path» tradúcese como «ruta» (ou secuencia de vértices)"

Pon a regra así:

# «Path» tradúcese como «ruta».
{\bpath(\b|\s|s)}i
valid after="trust\s"
valid after="<" before=">"
id="noPT-2011_path"
valid msgstr="\bruta"
hint="«Path» tradúcese como «ruta» (falta por debater «path» de debuxo
vectorial)"


> A penúltima liña debera ser:
> valid env="svg" msgstr="\bseucuencias?\sde\svértices"
>
> de xeito que só se admita esa tradución en ficheiros que usen termos de
> "svg" (vale, de deseño vectorial)
>
> A ver logo, mándame os ficheiros que che pido e irei modificando as
> regras... pero insisto: un documento non modificábel, listo para imprimir,
> unitario no seu contido (que reúna todos os acordos de tódalas trasnadas)
> había axudar moito.
>
> Para rematar, por agora, repítome: o check-rules, para tirarlle o máximo de
> proveito, é lixeiramente intrusivo no ficheiro. Usar con sentidiño o
> equip-header e o mecanismo de aceptación forzada de regras mellora os
> resultados.
>
> --
> BRGDS
> Marce Villarino
>
> _______________________________________________
> Proxecto mailing list
> Proxecto@trasno.net
> http://listas.trasno.net/listinfo/proxecto
_______________________________________________
Proxecto mailing list
Proxecto@trasno.net
http://listas.trasno.net/listinfo/proxecto

Responderlle a