Páxina sen traducir completamente!
Introducción
A finalidade de esta páxina non é explicar como funciona Rosetta (ou «Launchpad Translations» como se chama agora), senón dar a coñecer unha limitación actual do sistema e a maneira que os membros do equipo de tradución poden atallar o problema que comporta esta limitación.
Este problema está relacionado con este informe de erro, o cal ten efecto (polo caso que nos ocupa) é que ao subir un ficheiro .po con un «Published upload», as traducións que xa están en Rosetta non se substituídas polas novas traducións que se fixeron.
Hai diferentes maneiras a traverso das cales se poden traducir aplicativos, as cales se describen a continuación. Nota: isto só é una pequena introdución. Para máis información vexa a páxina de inicio do equipo de traducción de Ubuntu e as PMF do Rosetta.
1. Directamente coa interface web do Rosetta Só recomendábel para paquetes específicos de Ubuntu (é dicir, onde «upstream» sexa Ubuntu), software onde o «upstream» utiliza Rosetta como sistema de xestión das traduccións, ou ben cadeas individuais que son específicas de Ubuntu. As cadeas traducidas a través da interface web son marcadas do mesmo modo que un «User upload». Aquí só se aceptarán traducións dos membros do equipo de tradución.
2. Localmente, editando un fichero .po exportado de Rosetta Neste caso, calquera persona pode baixarse un fichero .po e tras informalo na rolda tradúceo con un editor de texto ou especializado. Unha vez traducido e revisado (sempre a través da rolda), un dos membros do equipo de tradución encargarase de subilo a Rosetta. Para facelo hai dúas opcións:
2.1. User Upload nesta opción as cadeas do Rosetta serán reemprazadas polas cadeas do ficheiro que subiu. Ademais, serán marcadas como «cadenas de usuario», é dicir, cadeas de Ubuntu que terán preferencia sobre as que haxa en upstream. Isto quere dicir que a próxima vez que se importen automaticamente as cadeas de upstream, estas non serán utilizadas, senón que se usarán as que se foran inseridas como «user upload». Polo tanto, non é recomendábel utilizar esta opción a non ser que saiba que está facendo (aínda que o mensaxe que mostra Rosetta ao subir un fichero diga o contrario). Hoxe por hoxe (ata que non sexa solucionado o erro), esta é a única maneira (a parte da interface web) de reemplazar cadeas ao Rosetta.
2.2. Published Upload Con esta opción as cadeas subidas ao Rosetta serán marcadas como cadeas as cales poden ser reemprazadas polas de upstream cando estas últimas se importen de maneira automática. Esta opción é a que se debería usar sempre para os paquetes onde a tradución non é directamente xestionada en Rosetta (como antes: os do Gnome, KDE, XFCE, etc.). Hoxe por hoxe (ata que non fora solucionado o error), se sube unha tradución a través de esta opción as cadeas xa traducidas en Rosetta non serán reemprazadas polas que subiu.
3. Fai falta tamén mencionar os paquetes en que (idealmente) as traducións son importadas automaticamente Este sería o caso dos paquetes que forman parte, por exemplo, do proxecto Gnome o KDE, onde as traducións de «upstream» van a parar directamente a Ubuntu sen necesidade de modificalas. Cando isto non funciona, ou ben se deben facer retoques, o/a tradutor/a deberá usar os métodos descritos en 1. e 2. O problema que nos ocupa afecta a «published upload» (2.2), onde en teoría cando se suban traducións que xa están feitas en Rosetta as traducións novas (subidas) deberán substituír ás vellas (as de Rosetta), cousa que non é o caso. Cicáis é mellor explicalo con un par de exemplos típicos:
Exemplo 1
Xoan é traductor do Gnome e de Ubuntu e encargase da tradución do Epiphany. Epiphany está traducido ao 100% en Gnome e importouse automáticamente a Ubuntu sen problemas.
Tras uns cantos meses da liberación de Ubuntu, un usuario comunicalle a Xoan que hai un erro na traducción de Epiphany. Xoan corríxeo e enviallo á rolda de traducción de Gnome, onde se aproba a corrección e móntase no svn de Gnome. Seguidamente, baixase a tradución da Ubuntu e aplícalle a corrección que xa aplicó en Gnome.
Despois sube a traducción como «published upload» a Ubuntu e ao cabo dunhas cantas horas recibe a confirmación que a importación tivo éxito. Como sempre, os cambios non se verán ata a próxima actualización dos paquetes de idioma.
O día da liberación dos paquetes de idioma o mesmo usuario informa Xoan que o Epiphany segue tendo o mesmo erro que lle comentou fai tempo.
Xoan se baixase a tradución da Ubuntu e efectivamente comproba que a cadea que corrixiu non reemplazou a do Rosetta debido a que subiu o fichero como «published upload» e Rosetta non se comporta como esperaba.
Exemplo 2
Clara tamén é membro dos equipos de tradución de Gnome e de Ubuntu e encárgase da traducción do gnome-terminal. Tras a liberación do Feisty (que inclúe o gnome-terminal 2.18) ve que a importación das cadenas do Gnome non funciou ben e que o Feisty todavía ten algunhas traduccións do gnome-terminal 2.16.
O que fai é baixarse as traducións de Gnome e de Feisty para o gnome-terminal 2.18 e fai un
msgmerge gnome-terminal.gnome-2-18.ca.po ca.rosetta.po > ca.upload.po
tras examinar o ficheiro resultante da fusión e corrixir calquera problema que houbera, súbeo a Rosetta como «published upload». Ao recibir a confirmación que o fichero foi importado, báixao para comprobar que todo funcionara e asegúrase que as cadeas antigas foran reemprazadas.
Solución: subida do ficheiro en dous pasos
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.
O que fai falla facer é simplemente subir o ficheiro en dous pasos:
Subilo como «user upload» de forma que as traducións novas reempracen as de Rosetta.
- Esperar a recibir a confirmación por correo de que a importación funcionou.
- Descargarse a traducción e comparala coa que se subiu antes.
Se todo é correcto, o que queda por facer é subir de novo o fichero obtido no paso 3 como «published upload». De este modo todas as cadeas marcaranse como «published» e poderán ser reemprazadas polas de upstream na próxima importación automática. É dicir, cando comece o ciclo de desarrollo da versión seguinte da Ubuntu.
Conversa no IRC con un dos desenvolvedores de Rosetta na canle #launchpad
Para acabar de aclarar o procedemento, ver que é (hoxe por hoxe) tecnicamente correcto e coñecer a opinión de un dos desenvolvedores de Rosetta sobre este tema, vexa a continuación o rexistro da conversa con Carlos Perelló, reproducida aquí co seu permiso.
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