>>>>> Á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. >> 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! -- Ubuntu-l10n-gl mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-l10n-gl
