Boas,

Douvos conta dos fundamentos e da metodoloxía que se viñan seguindo dende
que o goberno do PP retirou o finanzamento para a localizació de software.
Debe quedar claro que non é nin o único xeito de facer as cousas nin 
tampouco necesariamente o mellor; responde en todo caso ao intento de
normalizar os fluxos de traballo buscando a converxencia de esforzos e a
mellora da calidade.

Son unhas instrucións moi exhaustivas; prefiro resolver calquera dúbida que
xurda a traverso da rolda que mediante reunións, xa que así toda a xente
interesada no proceso pode enterarse e saber como funcionan as cousas. En
todo caso, se fora preciso xuntarse para o que fora, podedes contar comigo.

- O marco metodolóxico de referencia é o que fora definidos a raíz dos
  consensos do g11n [1] de cara a permitir a integración de empresas,
  voluntariado e administracións públicas. A última formalización desta
  metodoloxía é o método de galeguización onde concretamos o fluxo de
  traballo [2] incluindo os distintos procesos e os distintos roles.

  [1] http://repositorio.g11n.net/l10n/doc/estratexias/
  [2] 
http://repositorio.g11n.net/l10n/doc/estratexias/imaxes/fluxograma_g11n.png

- Partindo desa referencia teórica xeral, válida para todos os proxectos 
  de galeguización, buscouse o xeito de concretalo mediante ferramentas
  informáticas específicas. Para esto houbo unha serie de contactos 
  personais e reunións con personas expertas do ámbito profesional, que
  despois se complementaron cunha posta en común pública [5]. A conclusión
  foi que existían dous modelos distintos e traballo: por unha parte o de
  tradución profisional caracterizado básicamente polo uso dunha
  combinación de interfazes de tradución xunto con ferramentas específicas
  de conversión entre formatos traballando en local e publicando por lotes
  a tradución; e por outra parte o de tradución amateur caracterizado por
  unha preferencia ao traballo sobre recursos remotos (interfaces, recursos
  lingüísticos e orixes/destinos dos datos).

  [5] http://foros.g11n.net/viewforum.php?f=6

  Sobre ferramentas de conversión bidireccional:
  http://foros.g11n.net/viewtopic.php?f=6&t=32#p133

  * Para facilitar o acceso á vía profisional, optouse polo uso de OmegaT en
    combinación con ferramentas de conversión. Para esto elaborouse unha guía
    pensada para facilitarlle aos coordenadores das grandes aplicacións a
    distribución e organización do traballo mediante a plataforma g11n.net. 

    http://repositorio.g11n.net/l10n/doc/omegat/

  * Para facilitar a incorporación do perfil amateur, optouse polo uso de
    Pootle, deixando a criterio da persona que asumira a coordenación de
    cada proxecto o xeito de distribuir ou asignar os proxectos.

    http://traduce.g11n.net/

  Debido aos seus maiores requerimentos de calidade, para os grandes 
  aplicativo considerouse mais apropriado optar pola vía profesionalizante,
  deixando o Pootle para os proxectos de menor envergadura onde o control 
  de calidade podía ser exercido directamente.
  
- Compría poñer en práctica a metodoloxía polo que iniciamos dúas vías de
  traballo paralelas: por un lado aplicar o sistema profesional a algún
  subconxunto dun proxecto grande, e por outro aplicar o sistema amateur a
  algún aplicativo menor. Para o primeiro optouse pola documentación de
  Mozilla (OpenOffice estaba producindo a 3.2 nese momento e en GNOME os
  requerimentos de calidade son bastante menores) e naquel momento estaba
  traducindose a documentación do Fennec, polo que este foi o proxecto
  escollido. Para o segundo optouse polo IdeaTorrent, que se subiu ao
  Pootle.

- O resultado foi de éxito no caso do Fennec (Manuel e mais Jesus poden
  descrebervos en detalle o proceso). No caso de Pootle a experiencia
  levounos a pensar en reforzar o aspecto remoto delegando á nube o
  mantenemento da ferramenta.

Descrito o marco xeral, para o caso concreto de Mozilla:

- Para a documentación, a aproximación profesional mediante OmegaT +
  ferramentas de conversión demostrou funcionar correctamente. Nesta
  aproximación a persona que xestiona o repositorio obtén os ficheiros
  HTML, convírteos a XLIFF empregando os conversores da súa preferencia
  (nós optamos polo Okapi Framework) e depositaos na plataforma para a súa
  distribución. Elabórase e públicase o chamamento -é necesario dar aviso
  na rolda oficial- faise a distribución, os tradutores traducen, os
  revisores revisan a tradución, e unha vez validada a tradución polos
  revisores, o coordenador realiza a conversión inversa, fai as
  comprobacións técnicas precisas, remíteas ao repositorio e fecha o bug.

  Os fontes da documentación está no repositorio SVN, é preciso fazer un 
  checkout inicial:

  checkout
  svn co https://svn.mozilla.org/projects/mozilla.com/trunk/gl .

  Para subir os ficheiros, é preciso enviarllos primeiro a Pascal, quen
  despois vos axudará a xestionar unha conta con permisos de escritura.
  
- Para a gui, empregaríase tamén o sistema profesional; se ben a opción de
  conversión estaría pendente de se concretar, o proceso sería semellante
  ao da documentación no que se refire ao proceso de intercambios de
  ficheiros. Porén, debido a que os distintos aplicativos están ubicados en
  repositorios distintos e son xestionados por equipos que, mesmo estando
  todos integrados dentro da estructura social da Fundación Mozilla, teñen
  certas variacións que se reflexan na organización dos repositorios, as
  planificacións e os tempos de resposta. En todo caso, o proceso sería
  o seguinte. Xunto ligazóns útiles informativas:


        0. Comprobar integridade da localización 
        1. Clonar/ Actualizar repositorio local
        2. Traducir/ Comprobar integridade
        3. Actualizar repositorio central 

CLONAR/ ACTUALIZAR REPOSITORIO LOCAL
------------------------------------
Sobre branches:


https://wiki.mozilla.org/L10n:Branches

É preciso configurar o SCV en función da release coa que vaiamos traballar. 
Actualmente hai dúas releases activas, nomeadas en función da versión Gecko 
empregada:

        comm-1.9.1     -> para tb30x, sea20x, sunbird10x (provén de 
comm-central)
        mozilla-1.9.2  -> para fx36x (provén de mozilla-central)

e dúas inactivas
        mozilla-1.9.1  -> para fx35
        mozilla1.9.0   -> para fx30x (inactiva)
        mozilla1.8.0   -> para fx20x (inactiva)

tamén está central, onde se fai o desenvolvemento:
        central        -> para fx32x, fennec

Para traballar coas releases activas, é preciso empregar HG, configurando o
ficheiro de forma similar ao ~/.hgrc como sigue:

BOF
[ui]
username = Enrique Estevez <eu en keko.me>

[paths]
default = http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/gl/
default-push = ssh://hg.mozilla.org/releases/l10n-mozilla-1.9.2/gl/

[diff]
git = 1

[defaults]
diff=-p -U 8
EOF

Debemos traballar alomenos coas árbores l10n (de localización) en-US 
(orixinal) e gl (tradución ao galego), ademais da traducións que tomemos como 
referencia (pt-BR para transliteración).

En caso de que non teñamos ningunha copia previa, será preciso clonar a 
última versión das existentes dende o repositorio central (esto faise só a 
primeira vez):
- Clonar repositorio da release (que contén a árbore l10n orixinal en-US):
        hg clone http://hg.mozilla.org/releases/mozilla-1.9.2
        
- Clonar repositorio dunha árbore l10n traducida. Para o caso gl:
        hg clone http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/gl/

        * No caso de que non exista árbore l10n da aplicación correspondente,
          unha estratexia moi efectiva é descargar pt-BR e transliterar 
comparando
          con en-US. 

        * No caso de que haxa mais dunha release para un mesmo aplicativo, a
          árbore l10n de cada release debe manterse por separado, baixo o nome 
da
          release. Neste caso hai dúas releases para Firefox, e por tanto 
deberá
          haber dous directorios de traballo distintos nomeados igual que a 
release.

- Clonar repositorio dun módulo novo (por exemplo, mobile-firefox)
        hg clone http://hg.mozilla.org/mobile-firefox
        
        * Será necesario mover o repositorio do módulo ao interior do 
repositorio
          correspondente e nomeal do mesmo xeito en que apareza na árbore l10n 
traducida.


Unha vez teñamos clonadas as árbores de localización correspondentes, xa 
será posibel iniciar o traballo de traducción.

Antes de iniciar cada sesión de tradución será preciso actualizar os 
repositorios locais. Para esto será preciso executar dende cada un dos 
directorios que conteña a árbore de localización correspondente:

        hg pull -u
        hg update


TRADUCIR
--------
O proceso de traducción consiste en editar (modificar, engadir ou borrar)
os ficheiros indicados pola comprobación de integridade. O mais idóneo aquí
sería que exista unha persona (coordenación do proxecto) que se encargue de
distrbuir os ficheiros fonte en inglés a traverso da plataforma para que as
personas interesadas en colaborar traducindo e revisando poidan concorrer
ao traballo colectivo. Facendo así as cousas pode delegarse ao criterio das
personas tradutoras e revisoras o uso dunhas ou doutras ferramentas, se ben 
o uso da guía de OmegaT pode servir para simplificar o soporte a utentes e
aumentar o número de personas. 

Un adecuado esquema de tradución permitiría a incorporación de empresas, no 
caso de que a persona coordenadora teña capacidade para obter a financiación 
suficiente e xestionar as ferramentas administrativas precisas a estes efectos. 

Unha vez traducidas e revisadas as traducións, a persona que coordene a
tradución deberá recollelas mediante o sistema que teña definido, realizar
a conversión inversa (no caso de empregar formatos estándar profesionais
como XLIFF) e realizar unha comprobación de integridade previa á súa
remisión aos repositorios. 


COMPROBAR INTEGRIDADE
---------------------
Existen dous métodos para a comprobación da integridade da árbore l10n 
traducida:

- En local. Dende o repositorio local da release correspondente (o que contén 
a árbore l10n en-US) executar:
   compare-locales <modulo>/locales/l10n.ini . ../../gl/<release>/

   onde <modulo> é:
        para Firefox       -> mozilla/browser
        para Thunderbird   -> mail
        para Sunbird       -> calendar
        para Seamonkey     -> suite

   onde <release> é:
        para fx31x, tb30x, sunbird10x e sea20x) -> mozilla-1.9.1
        para fx32x, fennec                      -> central

- En remoto. Este ten a vantaxe de que amosa visualmente cunha soa operación o
  o estado da localización de todas as aplicacións, e que o compare-locales 
se 
  se executa no proprio servidor sobre o repositorio máis actualizado. Mais ten
  a desavantaxe de que a comprobación de integridade non sempre se visualiza 
  inmediatamente despois de actualizar o repositorio central, polo que só se
  recomenda o seu uso para monitorizar o estado xeral da localización dos 
  aplicativos no seu conxunto.

        http://l10n.mozilla.org/dashboard/?locale=gl
        As filas coa cela da coluna "Tree" vermella identifican as 
localizacións
        incompletas. Para un aplicativo dado, na súa fila:
        Premer en "C" na coluna "Stats". Na xanela que se abre:
        Premer no Buider <nº> correspondente. Na xanela que se abre:
        Premer no "stdio" do moz_comparelocales que fallara ("failed")
        Amosará a saída dun compare-locales executado no servidor 
identificando
        os ficheiros que é preciso editar.

ACTUALIZAR REPOSITORIO CENTRAL
------------------------------

Para remitir as traducións de gui ao repositorio oficial, será preciso
primeiro enviarllas a Axel en formato zip, quen despois vos irá dando
indicacións para que vos dea permisos de escritura no repositorio. Unha vez
teñades permisos:

Dende a árbore l10n da <release> correspondente:
        hg commit -m "comentario en inglés"
        hg push (para fx31x, tb30x, sunbird10x e sea20x)
  ou
        hg push central (para fx32x)

        * Se a primeira vez que se fai o push aparece unha mensaxe de erro 
será necesario engadir a opción -f (non facer o merge que suxire a mensaxe de 
erro)
        * lembrar fazer o hg addremove cando se engadan/quiten ficheiros.

En todo caso, quero facer notar que todo o anterior é un intento de
xeneralización nun fluxo de traballo cheo de excepcións e sometido a
cambios continuos: cambian os nomes dos repositorios, a ubicación dos
ficheiros, os procesos de validación... con certa frecuencia (un par de
veces ao ano hai algún cambio significativo aproximadamente) polo que é
fundamental algo no que insisto: o importante é a dimensión social do
proxecto, que é a que explica a continuidade deste proxecto de código
aberto ao longo desta década, e o que lle queda. Non se trata de ocultar
información, senón de compartila. Non se trata de competir, senón de
cooperar. Trátase de levarse ben coa xente: os oportunistas e os ineptos 
teñen moi poucas posibilidades de integrarse nunha comunidade como esta.

A este respecto, sería importante completar un paso que melloraría moito a
calidade final dos productos, como xa viñamos facendo con OpenOffice, para
evitar problemas como o do Thunderbird. Este é o único punto que non
experimentou ningún avanze dende o abandono por parte da Xunta, sendo como
xa era entón bastante precario o que tiñamos. Por tanto, sinalar a
importancia de que, dende o principio, vos integredes no equipo de calidade
da Fundación Mozilla e que sometades as novas traducións aos tests que irán
disponibilizando:

Web do equipo: http://quality.mozilla.org/
Web do litmus: https://litmus.mozilla.org/

Como vedes, hai traballo de sobra para que todo o mundo poida integrarse,
liñas paralelas de traballo e distintos roles para todos os gustos. 

Ánimo pois. 

Esta outra información pode ser útil; porén como xa dixen son informacións
que cambian, polo que é importante estar nas roldas e nos grupos que vos
irán indicando. En todo caso, a información mais útil sempre é a que se
pode obter dende o IRC e en contacto directo coas personas responsabeis.

DOCS
----

Estado da localización dos idiomas
        http://l10n.mozilla.org/dashboard/

Instrucións repositorios
        
http://groups.google.com/group/mozilla.dev.l10n/browse_frm/thread/a49e49518480c022?pli=1

Changelog de actualizacións
        http://hg.mozilla.org/releases/l10n-<release>/gl

        (Excepción: Para a release central -fx32x, fennec- eiquí <release> é 
"../central")

Binarios
        
ftp://ftp.mozilla.org/pub/mozilla.org/<modulo>/nightly/latest-<release>-l10n/
        (Excepción: Para a release central -fx32x e fennec- eiquí <release> 
é "mozilla-central")



Instalación de compare-locales
------------------------------

sudo apt-get install python-setuptools
sudo easy_install compare_locales-0.6.1-py2.5.egg


Axuda con HG
------------

https://developer.mozilla.org/en/Mercurial_FAQ


--
CC BY-NC suso.baleato em gmail.com
--


Enrique Estévez Fernández escrebeu:
> Ola a tod en s.
> 
> Son keko, o novo coordinador do equipo galego de tradución dos
> produtos de Mozilla.
> 
> Suso Baleato, o anterior coordinador xa me presentou na rolda como
> poidestes ver. Estou a espera de contestarlles porque me estaba a ler
> toda a documentación para saber por onde comezar e xa aproveitar para
> pedir o que necesite deles.
> 
> Non sei exactamente cal é o proceso que seguía o anterior coordinador
> e o seu equipo para realizar as traducións. Eu levo pedido que mo
> expliquen pero por agora non tivemos tempo para quedar, así que vou
> investigando e hai máis dunha posibilidade. Soamente lle estou
> prestando atención a dúas:
> 
> 1. Descargar todo o repositorio dos produtos de Mozilla. Converter os
> ficheiros de tradución a .po e traducir. Facer as probas técnicas
> mediante un script que teñen e cando teña permiso reimitir todo ao seu
> repositorio (pero antes teño que pedir conta).
> 
> 2. Traducir mediante web, teñen unha especie de Pootle chamado Narro.
> Pensei que xa non o empregaban xa que fai un ano que non sacan nova
> versión do mesmo e o blog do proxecto tampouco volveu a ter novas
> entradas contando os seus progresos. Esta fin de semana un grupo de
> Aragón solicitou traducir desde ahí e xa lle activaron a conta.
> 
> Como coordinador gustaríame máis a primeira opción xa que así podo
> levar un control máis exacto de todo e podemos traballar en local.
> Tería que dividir os ficheiros a traducir entre aqueles que queiran
> participar e cando os rematedes nun tempo prefixado por todos,
> realizar un revisión para comprobar que se siguen os mesmos criterios,
> polo menos en canto se refire ao estilo que apliquemos. Pasar
> corrector ortográfico e detección de falsos amigos.
> 
> A outra opción sería pedir que nos activen a tradución mediante web e
> acabaríanse moitos problemas que podemos ter relacionados coa parte
> técnica. Vou copiar este correo a Suso por se el sabe algo con
> respecto a tradución mediante Narro que desaconselle o seu uso, pero
> visto o visto non debería ser así.
> 
> Tamén vos podo decir que Suso xa cambiou os datos aquí:
> 
> https://wiki.mozilla.org/L10n:Teams:gl
> 
> Eu xa me rexistrei na wiki de Mozilla e tamén no Bugzilla. Aparte dos
> dous grupos de mozilla.dev que me indicaron cando Suso me presentou.
> Soamente me falta realizar a miña presentación e pedirlles axuda no
> mínimo para comezar a traballar xa. Espero as vosas respostas xa, urxe
> mover isto.
> 
> Un saúdo.

-- 
http://susinho.pagina.de/

Responderlle a