[Tradutores-Ubuntu] Planificación

Leandro Regueiro leandro.regueiro at gmail.com
Mon Nov 9 12:01:23 GMT 2009


2009/11/9 Leandro Regueiro <leandro.regueiro at gmail.com>:
>>>>>> Ándame dando voltas pola cabeza ultimamente unha idea, que pode soar a
>>>>>> tolemia, pero que penso que pode ser interesante tratar. En resumo,
>>>>>> sería deixar de traballar xa en Karmic (salvo correccións de erros e
>>>>>> así), e ir pensando xa en... Lucid? Lucid Lynx, non?
>>>>>
>>>>> Bo comezo
>>>>>
>>>>>> Cousas que apoiarían esta decisión:
>>>>>> - Será unha LTS
>>>>>> - Teremos máis tempo para traballar e organizarnos, e pulir detalles
>>>>>> de homoxeneización, calidade, etc, etc
>>>>>
>>>>> Hurra!
>>>>>
>>>>>> Cousas que poderiamos facer se empezamos canto antes:
>>>>>> - Sacar unha nota en cantos máis sitios mellor, pedindo colaboracións,
>>>>>> expoñendo o "plan", e mencionando as vantaxes de empezar canto antes e
>>>>>> bla bla bla. Aproveitar mentres exista Mancomún, jejeje
>>>>>
>>>>> Estou de acordo
>>>>>
>>>>>> - Traballar sobre todo no upstream, con tempo de ter en conta as
>>>>>> importacións/conxelacións/como lle chamen a iso.
>>>>>
>>>>> Aleluia non son o único que o dí!
>>>>>
>>>>>> - Organizar "miniequipos": se cadra resulta interesante ter xente que
>>>>>> se ocupe de "aplicativos en consola", "aplicativos multimedia",
>>>>>> "mensaxería". Aínda que fósemos os mesmos en todos os equipos,
>>>>>> poderíamos, eu que sei, dedicarlle unha semana a unha cousa, poñerse
>>>>>> de acordo en termos (falando no mesmo ámbito, sería máis fácil),
>>>>>
>>>>> Moi boa idea JMCS! Coido que o esquema que seguen os de ubuntu con
>>>>> "Ubuntu Bug Squad" que adica unha semana a unha sección en concreto para
>>>>> atopar e resolver bugs é moi produtivo.
>>>>>
>>>>> Nese sentido podemos aplicar o mesmo.
>>>>>
>>>>>> Cousas que seguramente resultarían máis complicadas:
>>>>>> - Seguramente habería máis traballo de coordinación. Non é o mesmo
>>>>>> estar pendentes de datas de importacións, traballar no upstream,
>>>>>> sincronizar os "miniequipos (se os houbera)... que coller o que haxa
>>>>>> en Launchpad, e traducilo alí repartindo o traballo "al vuelo"...
>>>>>
>>>>> Como intúo podes saber, en gnome estamos a facer (Viva Méixome) unha
>>>>> revisión completa. Pensamos que debemos priorizar a calidade das
>>>>> traducións fronte á cantidade e por iso non imos comezar coa
>>>>> documentación ata ter este primeiro paso feito.
>>>>>
>>>>>> Total. o de sempre: opinións? estou dicindo unha burrada outra vez?
>>>>>> Comentarios?
>>>>>
>>>>> Totalmente de acordo. Temos que ver primeiro cales son as datas de
>>>>> conxelación de todos os proxectos... GNOME, firefox, etc etc... para ir
>>>>> adecuando o noso calendario a ditos fitos.
>>>>> O seguinte paso é crear grupos de traballo, que como ben dis imos estar
>>>>> moita xente en varios, e grupos de aplicativos (consola, multimedia,
>>>>> etc) para asignar consecuentemente recursos de persoal a cada sección.
>>>>>
>>>>> Eu o da redacción da nota de prensa non me gustaría levalo, aka se podo
>>>>> escaquearme xenial, pola contra mirar un pouco o dos grupos de
>>>>> aplicativos a priorizar e ir estudando a planificación si o podo facer e
>>>>> se me pode dar ben.
>>>>>
>>>>> Suxestións?
>>>>
>>>> Perdodade que faga Top Posting, pero como no vou a replicar a nada do
>>>> dito, xa que concordo con todo, senon que quero engadir.
>
> Quizais non se debería facer máis. Dificulta un chisco seguir o fío.
>
>>>> Comecei estes días a revisar, liña por liña, palabra por palabra, os
>>>> paquetes actualmente en karmic seguindo a orde de prioridade que
>>>> estabelece Ubuntu.
>>>> Revixei xa:
>>>> bootloader - 76 liñas
>>>> e estou a rematar (faltanme +/- 400)
>>>> debian-instaler - 1596 liñas
>>>>
>>>> Unha vez que remate esta revisión pasareilla a marce para que a suba a
>>>> debian coas modificacións que ten unha respecto da outra.
>>>>
>>>> Aquí é onde está un dos problemas máis grandes nas traducións actualmete,
>>>> a falta de consistencia, xa que nesta última atopei o que deu pé ó fío que
>>>> abrin resprcto de "Afacer cocido", así como que dentro dese mesmo
>>>> ficheiro se emprega de xeito aleatorio cousas como
>>>> atopar-achar-encontrar
>>>> buscar-procurar-pescudar
>>>> mostrar-amosar
>>>> trocar-cambiar-mudar
>>>> arrancar-arrincar (as veces as dúas na mesma liña)
>>>>
>>>> Sei que este traballo debe dar pé a determinadas consultas lingüisticas,
>>>> así que tocarános "muxir" :-) ben a Antón.
>
> Moi boa :) Cres que nos dará bo leite?
>
>>>> Outra das cousas que atopei é unha construcción do máis barroco, non
>>>> incorrecto, pero de complexa lectura, utización até o paroxismo de formas
>>>> verbais compostas
>>>> LILO ha tomar o control completo
>>>> Para se defender contra isto
>>>> o sistema instalado non se ha iniciar
>>>> Pode ser porque decidiu non o facer
>>>> Cando o ordenador arranque, ha poder iniciar un destes sistemas
>>>> modificar o sector mestre de arranque ha facer que, de xeito temporal
>>>> Ao rematar a instalación, o sistema hase reiniciar.
>>>> Só ha ter que facer isto unha vez. Isto halle permitir empregar
>>>> Esta información hase empregar
>>>> Ha ter que indicar un contrasinal para
>>>> que "root" se conecte hase crear unha conta de usuario que ha ter a
>>>> posibilidade de se facer root
>>>>
>>>> Isto anterior, ainda que correcto, cando forma parte o groso da
>>>> tradución, este emprego de formas con infinitivo desespera a ún (alomenos
>>>> a min) e fanse cousas como:
>>>>
>>>> paquetes estándar para o instalar. Este software ten varias licenzas que
>>>> poden impedirlle empregalo, modificalo ou compartilo.
>>>>
>>>> o lóxico sería ... para instalalo. Este....
>>>>
>>>> ou ... impedirlle o empregar, o modificar, ou o compartir
>>>>
>>>> Queda claro que neste caso optouse por ser máis lóxico na frase final xa
>>>> que senón a construcción notase moi artificial. Pois iso é o que lle noto eu
>>>> a estas traduccións, que son moi forzadas, pouco naturais e se iso devira
>>>> nunha construcción rica, literariamente falando, benvida, pero resultame
>>>> moi de "papa mira lo que aprendí en el cole". :)
>>>>
>>>> Polo que propoño que exista un "equipiño" para ir así, con paciencia,
>>>> revisando estas cousas.
>>>
>>> Moi interesante a mensaxe, levanta debates moi interesante. En todo
>>> caso a min paréceme que mestura cuestións de distinta orde:
>>>
>>> 1) Consistencia na denominación de accións frecuentes, que deberían
>>> estar estandarizadas:
>>>
>>>> atopar-achar-encontrar
>>>> buscar-procurar-pescudar
>>>> mostrar-amosar
>>>> trocar-cambiar-mudar
>>>> arrancar-arrincar (as veces as dúas na mesma liña)
>>>
>>> Nada que obxectar á proposta de fixalas. Supoño que non será fácil se
>>> as traducións veñen de proxectos distintos...
>
> Se mal non lembro xa se discutirá a tradución de "show" que tiña dúas
> posibilidades: "mostrar" e "amosar" as dúas totalmente correctas. De
> feito é un caso semellante ao de "window", pero a diferencia destoutro
> caso decidirase primar "mostrar" en vez de "amosar"... a ver se atopo
> dita mensaxe.

Atopada: http://listas.mancomun.org/pipermail/g11n/2009-August/002352.html

>>> 2) Construcións barrocas ou inusuais. Aquí o terreo é máis esvaradizo.
>>> De acordo que ás veces nos pasamos facendo frases enrevesadas que eu
>>> atribúo moitas veces a facer calcos do inglés (esas infumables
>>> construcións en pasiva que sempre se nos colan aínda que esteamos
>>> atentos...) ou reproducir traducións literais do inglés cando a
>>> redacción en inglés xa é penosa.
>>>
>>> Outra cousa é chamarlle raro ao uso de haber + infintivo ou haber +
>>> preposición + infinitivo para indicar futuro. Iso non é raro, é
>>> galego. O mesmo se podería dicir cando introducimos o uso do
>>> infinitivo flexionado ou do futuro de subxuntivo.
>>>
>>> Aquí hai dous elementos que están en tensión: modelo de lingua e
>>> naturalidade e equilibrio na expresión. Eu apoio un modelo de lingua
>>> rico onde teñen cabida eses trazos diferenciais do galego. Dito isto
>>> non hai que pasarse e ser naturais, na mesma oración poden mesturarse
>>> varias destas formas sen que pase nada. Exemplo:
>>>
>>> * Só ha ter que facer isto unha vez. Isto halle permitir empregar
>>> * Só ha ter que facer isto unha vez. Isto permitiralle empregar
>>>
>>> Reflexión final: non deberíamos caer na tentación de sistematizar a
>>> tradución igual que se sistematiza a programación. Non é o mesmo
>>> traducir que codificar.
>>>
>>> Conclusión: ben polo da equipa de revisión pero ollo cos criterios!!!!!
>>
>> Precisamente!!!
>>
>> Esa é razón do meu comentario, tratar de achegar criterios que non fagan da
>> interface de Ubuntu un catálogo de estilos literarios ou de modismos zonais,
>> se ben é certo que a riqueza da linguaxe debe ser alta, debemos ter en conta
>> a quen vai dirixido o traballo de tradución. Isto lévame a que adoecemos
>> dunha cultura de emprego do galego nas cousas técnicas e que si facemos unha
>> escritura (que será unha lectura/comprensión) complexa, afastaremos a moita
>> xente "novicia" do galego nas cousas tecnoloxicas por non teren feito unha
>> tradución máis comprensible.
>>
>> Outra cousa a ter en conta, por exemplo con mostrar/amosar ou
>> buscar/procurar pareceme ben que se usen as dúas, pero non no mesmo
>> aplicativo. O que estou a facer cando corrixo e ver cal é a maioritaria
>> dentro do aplicativo en cuestión e corrixir de xeito que dentro dese
>> aplicativo sempre se use a mesma voz.
>>
>> Ademáis temos os modismos, como exemplo un caso do equipo de ubuntu-es,
>> decidíuse non empregar o til en "video" xa que. ademáis de ser correcto no
>> castelán de españa é mairitario no castelán de sur américa. Isto lévame a
>> que procuremos unhas traducións o máis neutras e alonxadas dos modismos ou
>> de "xeitos" persoais, como empregar termos mariñeiros xa que é o que se fala
>> no meu pueblo ou termos agro-gandeiros, xa que eu son da montaña lucense....
>>
>> Xa que isto é un equipo... abrimos o debate!
>



More information about the Ubuntu-l10n-gl mailing list