← Back to team overview

openerp-i18n-de team mailing list archive

Re: FW: how to go on....

 

Hallo Ferdinand,

technisch wäre das von Dir skizzierte Vorgehen sicher der Idealzustand. Was
die offensichtlichen Fehler angeht:
Jedes Teammitglied sollte diese dann ruhig direkt auf Launchpad beheben,
solange wir vorerst keine andere
Lösung haben.

Viele Grüsse
Thorsten Vocks

2011/2/17 Ferdinand Gassauer <ferdinand.gassauer@xxxxxxxxxxxxxx>

> On Thursday, February 17, 2011 Thorsten Vocks wrote:
> Hallo!
> Zunächst besten Dank an die guten Geister, die an der Übersetzung
> gearbeitet
> haben, die natürlich an einigen Punkten verbesserungswürdig ist, aber
> mitlerweile doch eine recht ansehnliche Quaität hat.
> Ich werde und muss meinen Beitrag zu Übersetzungen zukünfig auf die
> Ausbesserungen von offensichtlichen Fehlern (Tippfehler - die meisten
> wahrscheinlich eh von mir, Kontext Fehler) beschränken, da ich jetzt
> schwerpunktmäßig am Debuggen der  v6 im Zuge der Umstellung meiner eigenen
> Firmen bin (seit Montag in Produktion). Da gibts noch einige Probleme die
> ich
> lieber nicht beim Kunden sehen und ausbessern möchte - insbesondere
> base_contact und Berechtigungen.
>
> Zur Methodik der Übersetzung habe ich seinerzeit einen Vorschlag gemacht,
> launchpad ist ja ungeeignet
> ***********
> may be the scripts can be packed into a base_translate module (a new tab on
> module form) with exactly this workflow so that every operation is done out
> of
> and controlled by OpenERP
>
> workflow
> * download po/pot from bzr
> * translate (using a GUI tool like poedit, lokalize)
> * import
> * proof read
> * export (must be ordered by msg_id !?)
> * upload to bzr
>
> -> translate button is only available if state is download or export
>
> the tab should show personal translation statistics of the workflow
> * workflow name, datetime, user (proof read might be done by some else)
>
> the download could/should set  a flag/file in the bzr directory
> de_DE.po.<user>  or de_DE.po.lock (with name + mail + date inside)
> which is removed by the upload.
> so we would know who is translating a module.
> All translators will know the consequences breaking this lock
> An automatic mail should be send to the former lock-holder.
>
> compared with the mess we have now it seems a simple solution
>
> If translation is not comfortable it won't be done
> ***************
>