German translation patch 20100728

Bug #611048 reported by Ferdinand
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Invalid
Low
OpenERP's Framework R&D

Bug Description

please apply ASAP and give feed back if we can proceed this way as suggested
in <email address hidden>
which seems to work reasonable well and would allow to translate some 50-100 terms/day
************************ My Question *****************
AFAIK it is not possible to download ALL ~400 modules at once to do an
offline translation which is much faster then doing it online
any hint available how to get translations for one language for all
modules at once?
************************ XRG Answer ****************
On Monday 26 July 2010, you wrote:
> Am Montag 26 Juli 2010, 08:21:08 schrieben Sie:
> Thanks
> Actually not
> 1) I probably do not have commit rights in trunk
If you send a patch with the updated translations, that would be welcome, of
course.
And I think this is a much better procedure, than blindly accepting anonymous
translation strings through LP. There should be a human at the end of the
procedure, that will do a quick check on the strings being submitted, and
perhaps resolve merges of multiple translations (supported by the gettext file
standard).

> 2) IMHO for efficient and coherent translation it would be helpful to get
> ONE big po file with all modules.
Not really. One .po file would be too large, and would also multiply the danger
of having different context strings merged (example the "State" string that has
two meanings).
Since many translation editors are familiar with "project structure", I have a
little bash script that will symbolic link all the translation files into one
directory like ./de/account.po ./de/crm.po etc. That directory will be
recognized by the local editor and help you translate all modules at once.

> of course this could be achieved by loading all modules (whenever there are
> no conflicts), exporting all translations into ONE po file - translation -
> importing - exporting per module - committing - but this takes extra
> hours.
>
> @xrg - IIRC you mentioned another way to translate efficiently ?
>
All of the scripts I'm referring to are at my "openerp" base repo, under the
mandriva dir:
http://git.hellug.gr/?p=xrg/openerp;a=tree;f=mandriva;hb=HEAD

Revision history for this message
Ferdinand (office-chricar) wrote :
Changed in openobject-addons:
status: New → Triaged
Changed in openobject-addons:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Low
status: Triaged → Confirmed
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Hello Ferdinand,

I'm afraid this will not work, because Launchpad may override the translations with new ones from Rosetta at any time of the day.
This means that by the time you finish working on the translations and generate the patch, there is a chance that it won't be applicable on the trunk anymore, because it was overwritten (not necessarily preserving order or anything)
The same issue would occur with a merge proposal, that would have a great chance to be obsolete before it can be submitted or merged. (The attached patch cannot be applied anymore, but even a fresh one has a great chance of failing...)

You can instead upload the PO files you translated via the corresponding Launchpad page, so that Rosetta does the work of merging the PO terms with its translation database. Unfortunately, as you know, this must be done module per module at the moment, e.g.:
     https://translations.launchpad.net/openobject-addons/trunk/+pots/account/de/+upload

Maybe it would possible to automate the call to submit the PO files via this API?
If someone wrote a script to automatically upload all PO files for a given language it would probably be very useful for localization teams that prefer to work offline. (I'm keeping a note about it for R&D, if no-one does it before)

Changed in openobject-addons:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.