Introducció
La finalitat d'aquesta pàgina no és explicar com funciona el Rosetta (o «Launchpad Translations», com s'anomena ara), sinó donar a conèixer una limitació actual d'aquest sistema i la manera com els membres de l'equip de traducció poden solucionar el problema que comporta aquesta limitació.
Aquest problema està relacionat amb aquest informe d'error, l'efecte del qual (per al cas que ens ocupa) és que en pujar un fitxer .po com a «Published upload», les traduccions que ja són al Rosetta no seran substituïdes per les noves traduccions d'aquest fitxer.
Hi ha diferents maneres a través de les quals es poden traduir aplicacions, les quals es descriuen breument a continuació.
Nota: això només és una petita introducció. Per a més informació vegeu la pàgina d'inici de l'equip de traducció de l'Ubuntu i les PMF del Rosetta.
1. Directament amb la interfície web del Rosetta Només recomanable per a paquets específics de l'Ubuntu (és a dir, on l'«upstream» és Ubuntu), programari on «upstream» utilitza el Rosetta com a sistema de gestió de les traduccions, o bé cadenes individuals que són específiques de l'Ubuntu. Les cadenes traduïdes a través de la interfície web són marcades de la mateixa manera que un «User upload». Aquí només s'acceptaran traduccions dels membres de l'equip de traducció.
2. Localment, editant un fitxer .po exportat de Rosetta En aquest cas, qualsevol persona pot baixar-se un fitxer .po i després de coordinar-ho a la llista traduir-lo amb un editor de text. Un cop traduït i revisat (sempre a través de la llista), un dels membres de l'equip de traducció s'encarregarà de pujar-ho al Rosetta. Per a fer-ho hi ha dues opcions:
2.1. User Upload En triar aquesta opció les cadenes del Rosetta seran reemplaçades per les cadenes del fitxer que pugeu. A més a més, seran marcades com a «cadenes d'usuari», és a dir, cadenes de l'Ubuntu que tindran preferència sobre les que hi hagi a upstream. Això vol dir que la propera vegada que s'importin automàticament les cadenes d'upstream, aquestes no seran utilitzades, sinó que es faran servir les que s'hagin entrat com a «user upload». Per tant, no és recomanable utilitzar aquesta opció a no ser que sabeu què esteu fent (tot i que en des del missatge que presenta el Rosetta en pujar un fitxer es digui el contrari). Avui per avui (fins que no s'hagi solucionat l'error), aquesta és la única manera (a banda de la interfície web) de reemplaçar cadenes al Rosetta.
2.2. Published Upload Amb aquesta opció les cadenes pujades al Rosetta seran marcades com a cadenes les quals poden ser reemplaçades per les d'upstream quan aquestes últimes s'importin de manera automàtica. Aquesta opció és la que s'hauria de fer servir sempre per als paquets on la traducció no és directament gestionada al Rosetta (com abans: els del Gnome, KDE, XFCE, etc.). Avui per avui (fins que no s'hagi solucionat l'error), si pugeu una traducció a través d'aquesta opció les cadenes ja traduïdes al Rosetta no seran reemplaçades per les que pugeu.
3. Cal també esmentar els paquets en què (idealment) les traduccions són importades automàticament Aquest seria el cas dels paquets que formen part, per exemple, del projecte Gnome o KDE, on les traduccions d'«upstream» van a parar directament a l'Ubuntu sense necessitat de modificar-les. Quan això no funciona, o bé s'han de fer retocs, el/la traductor/a haurà de fer servir els mètodes descrits a 1. i 2.
El problema que ens ocupa afecta el «published upload» (2.2), on en teoria quan es pugen traduccions que ja estan fetes al Rosetta les traduccions noves (pujades) haurien de substituir les velles (les del Rosetta), cosa que no és el cas.
Potser és millor explicar-ho amb un parell d'exemples típics:
Exemple 1
En Joan és traductor del Gnome i de l'Ubuntu i s'encarrega de la traducció de l'Epiphany. L'Epiphany està traduït al 100% al Gnome i es va importar automàticament a l'Ubuntu sense problemes.
Després d'uns quants mesos de l'alliberament de l'Ubuntu, un usuari li comunica a en Joan que hi ha un error a la traducció de l'Epiphany. En Joan ho corregeix i ho envia a la llista de traducció del Gnome, on s'aprova la correcció i es munta a l'svn del Gnome. Seguidament, es baixa la traducció de l'Ubuntu i hi aplica la correcció que ja va aplicar a la del Gnome.
Després puja la traducció com a «published upload» a l'Ubuntu i al cap d'unes quantes hores rep la confirmació que la importació ha tingut èxit. Com sempre, els canvis no es veuran fins la propera actualització dels paquets d'idioma.
El dia de l'alliberament dels paquets d'idioma el mateix usuari informa en Joan que l'Epiphany segueix tenint el mateix error que li va comentar fa temps.
En Joan es baixa la traducció de l'Ubuntu i efectivament comprova que la cadena que va corregir no va reemplaçar la del Rosetta degut al fet que va pujar el fitxer com a «published upload» i el Rosetta no es comporta com s'esperava.
Exemple 2
La Clara també és membre dels equips de traducció del Gnome i de l'Ubuntu i s'encarrega de la traducció del gnome-terminal. Després de l'alliberament del Feisty (que inclou el gnome-terminal 2.18) veu que la importació de les cadenes del Gnome no ha funcionat bé i que el Feisty encara té algunes traduccions del gnome-terminal 2.16.
El que fa és baixar-se les traduccions del Gnome i del Feisty per al gnome-terminal 2.18 i fa un
msgmerge gnome-terminal.gnome-2-18.ca.po ca.rosetta.po > ca.upload.po
després d'examinar el fitxer resultant de la fusió i corregir qualsevol problema que hi hagi pogut haver, el puja al Rosetta com a «published upload». En rebre la confirmació que el fitxer ha estat importat, se'l baixa per a comprovar que tot hagi funcionat i se n'adona que cap de les cadenes antigues han estat reemplaçades.
Solució: pujada del fitxer en dos passos
Nota: cal dir que aquest procediment no rebrà cap suport dels desenvolupadors del Launchpad ni tampoc prometen que puguin desfer els canvis ocasionats per la pujada de fitxers malmesos o incorrectes (vegeu el registre de la conversa per IRC amb un d'ells a la secció final). De totes maneres, aquesta és la única manera de modificar traduccions que es vulguin mantenir com a «published» fins que no es resolgui l'error esmentat abans. Un cop s'hagi solucionat, es considerarà innecessari (i no recomanable) fer servir aquest procediment.
El que cal fer és simplement pujar el fitxer en dos passos:
Pujar-lo com a «user upload» de manera que les traduccions noves reemplacin les del Rosetta.
- Esperar a rebre la confirmació per correu que la importació ha funcionat.
- Descarregar-se la traducció i comparar-la amb la que s'ha pujat abans.
Si tot és correcte, el que queda per fer és pujar de nou el fitxer obtingut en el pas 3 com a «published upload». D'aquesta manera totes les cadenes es marcaran com a «published» i podran ser reemplaçades per les d'upstream en la propera importació automàtica. És a dir, quan comenci el cicle de desenvolupament de la versió següent de l'Ubuntu.
Conversa per IRC amb un dels desenvolupadors del Rosetta al canal #launchpad
Per a acabar d'aclarir el procediment, veure que és (ara per ara) tècnicament correcte i conèixer la opinió d'un dels desenvolupadors del Rosetta sobre aquest tema, vegeu a continuació el registre de la conversa amb en Carlos Perelló, reproduïda aquí amb el seu permís.
mai 17 12:03:50 <dpm> hi, what's the correct way to import translations from the gnome translation project (GTP) which have changed after the Feisty release?
mai 17 12:03:57 <dpm> what I've been doing on a module basis is 1) get the (newer) translation from the GTP, 2) get the (older) translation from Rosetta 3) msgmerge 4) Upload the resulting file as a 'User upload' 5) After receiving the e-mail confirmation of a successful import, upload the same file again, but as a 'Published upload'.
mai 17 12:04:08 <dpm> I do step 4) because it is the only way to overwrite the strings in Rosetta. Then I do step 5) because it is my understanding (I was told on this channel) that in this way the status of all strings gets reverted to 'Published upload', as it should be for gnome packages.
mai 17 12:04:19 <dpm> However, I wanted to check if this is correct or if there is an easier way, since this is a tedious process (you have to upload translations twice and wait several hours until confirmation of the import to do the second upload)
mai 17 12:26:38 <carlos> dpm: if you want to undo any change done in Rosetta that is different from what official GNOME has
mai 17 12:26:53 <carlos> dpm: what you did is a good workaround to some missing functionality we have
mai 17 12:27:54 <carlos> dpm: usually, if you upload it directly as a published file, the translations in Launchpad/Ubuntu that matches the one in GNOME will follow any change done in GNOME
mai 17 12:28:24 <carlos> and if there is any untranslated, Launchpad will activate automatically the one coming from GNOME
mai 17 12:30:05 <dpm> carlos: no, that's why I started doing steps 4) and 5). I noticed that if I only upload as published the newer strings from gnome were not replaced in Rosetta
mai 17 12:30:38 <dpm> for already translated strings
mai 17 12:31:05 <carlos> dpm: please, subscribe to https://bugs.launchpad.net/rosetta/+bug/60029 so you know when you could stop doing it that way
mai 17 12:31:06 <ubotu> Launchpad bug 60029 in rosetta "Should always be possible to view/revert to upstream translation" [Medium,Confirmed]
mai 17 12:31:48 <carlos> once we fix that bug, you could do a direct upload as 'published' and then select to revert changes in Launchpad
mai 17 12:32:00 <carlos> and the system will do it for you automatically
mai 17 12:32:09 <dpm> carlos: I was already subscribed
mai 17 12:32:14 <carlos> ok
mai 17 12:34:36 <dpm> carlos: in any case, just to be sure: until the bug is fixed, the correct (and only) way to do this is the procedure I've described before (i.e. steps 4 and 5), isn't it?
mai 17 12:37:25 <carlos> dpm: it's a workaround, yes
mai 17 12:37:56 <carlos> not really what should be done, because you are not supposed to have to do it
mai 17 12:38:13 <carlos> but the only way to do that until the bug is fixed
mai 17 12:38:46 <dpm> ok, thanks, I understand. I'll keep doing this with a clear conscience, then ;-).
mai 17 12:40:04 <dpm> carlos: may I reproduce the log of this conversation on our Translation Team Wiki?
mai 17 12:40:39 <dpm> just for the reference for other translators on the team
mai 17 12:47:21 <carlos> dpm: sure, you can, but add also a note saying that we don't support that so if someone breaks something doing that, we cannot promise to be able to revert it
mai 17 12:50:55 <dpm> carlos: ok, thanks. I'll add that (scary) note. In any case, from a technical point of view there shouldn't be any breakage, shouldn't it? It is nothing more than the usual upload procedure, albeit twice (and having waited for the first import to have been completed).
mai 17 12:51:50 <carlos> dpm: technically, is safe, but if you do any mistake in the external process and provide broken data, we don't have a way to detect that and block such action
mai 17 12:52:20 <carlos> that's why we don't document that procedure as it's working as a side effect of the way the system works
mai 17 12:52:35 <carlos> not because we wanted to cover such use case
mai 17 12:52:54 <dpm> I understand, I'm just asking to be sure of what I'm doing
mai 17 12:54:44 <dpm> carlos: but that (to provide broken data) can always happen, even if you do a single (user or published) upload, can't it? What I mean is, there is nothing particular in the, let's call it "upload twice" procedure, isn't there?
mai 17 12:56:16 <carlos> indeed, but with normal work flow, you don't need to do a msgmerge and get two file together and change most of the metadata we have in our database
mai 17 12:57:08 <carlos> if you change only launchpad translations or published translations, there is a chance to fix some breakages, doing the procedure you described, you change everything so it's harder to undo
mai 17 12:57:30 <carlos> dpm: I'm not against doing it that way, I'm just pointing that you should be careful
mai 17 12:57:53 <carlos> I will be against doing it once we provide you with the required tools so you don't need to do it anymore
mai 17 12:58:50 <dpm> yes, I understand, it is only a temporary workaround. I'll stress that on our team's wiki.
mai 17 12:59:12 <dpm> carlos: thank you very much for your support
mai 17 12:59:26 <carlos> dpm: you are welcome