openerp-expert-framework team mailing list archive

["P. Christeas" <xrg@xxxxxxxxx>]

On Friday 16 July 2010, Ana Juaristi wrote:
> Hi:
> 
> Today I was trying to translate to spanish a few modules needed for a
> customer. These are portal modules and a few more about stocks and so on...
> but I couldn't do it on right branche on launchpad.
> 
> For 5.0 I can find only 44 modules allowed to be translated
> For trunk I can find 288 but I'm not sure if translation made on trunk are
> applying to 5.0
> 
> I also can see that there is a lot of missing translations on official
> addons to spanish on 6.0 comparing to 5.0, so I don't know if a lot of
>  terms have been changed or these translations haven't been migrated to
>  6.0.
> 
> There is another branche I have translated almost completly to spanish, the
> training one. I could not find a way to upload properly the translations to
> launchpad so any help would be very appreciated.
> 
FYI my strategy is to avoid Launchpad for translations, and instead do them at 
the po files, directly.
One main reason is that Launchpad screws the work of translators. It does not 
track their commits, nor does it attribute the work to the people that really 
made it. It would also blindly overwrite the translations, once a new 
translator comes in and changes things (no revision control).

Anyway, one point is that you can translate in the source branches.

Second is, you might want to sync the translations. This procedure would 
involve producing recent template files from a running instance of the database 
(clean one, preferably). I have some scripts for that, in my "openerp" git 
repo. 

After getting the template files and working on the .po files, it is better to 
use the gettext tools (msgcat, msgmerge) so that you update the work on 
different branches etc. That is the correct way, it preserves the data (unlike 
Launchpad).

I am doing an attempt to setup translation services in Transifex ( 
http://www.transifex.net/projects/p/openerp/). It has many advantages over LP, 
one of them being that it records the commits, and also that it can simply 
send the translation differences (=work) back to teams for revision. At the 
moment, I cannot see the most efficient way to put all the modules in a nice-
structured way, and I am talking with their team about that.

The final goal is a translation system, which will enable ALL of LP, Transifex 
and direct translations, to be merged and revised by the appropriate people 
(ones that really know the context meaning of strings, see eg. of "State", or 
"Open Accounts" strings).