Translations export has no fixed order

[Xavier Fernandez http://www.smile.fr]

1- export a .po using the Administration > Translations > Import/Export, export a file for a module,
2- add some fields on any object of the module:
'test_translation': fields.boolean('Test translation'),
'test_translation2': fields.boolean('Test translation2'),
for example
3- reexport the .po exported in step 1

You will get 2 files containing the same data (with the exception of the new fields to translate) BUT in a totally different order making the difference between this two files enormous while just one line should have changed...

This is only because of the use of dictionnary in the export function and the fact that dictionnaries' keys are not sorted in python:

changing only some lines from:
for src, row in grouped_rows.items():
to:
for src in sorted(grouped_rows):
    row = grouped_rows[src]

makes sure the translation are always exported in the same order making the historization of the translations way easier/clearer.

[Vishal Parmar(Open ERP) (vpa-openerp)]

Hello Xavier Fernandez ,

I have checked your issue with the latest code of 6.1 but I didn't face any problem as you have describe in bug specification. So would you please elaborate more on this issue like, which version you did check this issue, revision number and give proper steps with video what you did at your end ?

Would you please tried with latest code and informed us where you faced the problem.

Thanks and waiting for your reply.

[Xavier Fernandez http://www.smile.fr (xav-fernandez)]

This is True for at least 6.0 and trunk.

No need for video, just reading the code in translate.py:

            grouped_rows = {}

            ...

            for src, row in grouped_rows.items():
                writer.write(row['modules'], row['tnrs'], src, row['translation'])

and knowing that python dictionnary do not respect any order:
"The keys() method of a dictionary object returns a list of all the keys used in the dictionary, in arbitrary order (if you want it sorted, just apply the sorted() function to it). To check whether a single key is in the dictionary, use the in keyword."
cf http://docs.python.org/tutorial/datastructures.html#dictionaries

lead to the conclusion that to have a predictable export, the use of sorted() (or any other sorting function) is necessary.

[Numérigraphe (numerigraphe)]

This is indeed annoying when you add strings to an existing translations, because it generates a huge diff, and subsequent merges naturally produce many more conflicts than they ought to.
Lionel Sausin.

[Numérigraphe (numerigraphe)]

I can confirm that the patch attached by Xavier Fernandez resolves the problem at my end.

Please note that the existing po files can be fixed using bash and the standard gettext tools :
   find addons -regex '.*\.po[t]?$' | while read i; do mv $i $i.old ; msgcat --sort-output $i.old>$i; done
That should be done on the official addons if the patch is accepted.

Lionel.

[Ravi Gohil (OpenERP) (rgo-openerp)]

Hello Lionel,

The patch provided by Xavier in comment #1 could be useful if contents in all the .po files are in sorted order. So, this requires modification in all the .po files which is not suggested for stable versions.

Such changes should be done in trunk only, hence I will mark this bug as `Won't Fix` for stable V6.0.

Thanks.

[Xavier Fernandez http://www.smile.fr (xav-fernandez)]

Hello,

why does it not affect 6.1 ?
The code is still there (at least in revision 4296):

            for src, row in grouped_rows.items(): <=============== STILL NO SORTING
                if newlang:
                    row['translation'] = ''
                elif not row.get('translation'):
                    row['translation'] = src
                writer.write(row['modules'], row['tnrs'], src, row['translation'])

And concerning the stable 6.0, fixing the export order does not mean you'll have to reexport all .po for all languages and addons.
It only means that future export will be ordered.

Xavier

[Numérigraphe (numerigraphe)]

Ported to v7.0 and trunk, please review the merge proposal.

[Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives)]

Unfortunately, this is still not merged into v8...
The branch is called "v7.0" but it does merge cleanly into trunk at this time. Maybe the R&D team would be so kind as to examine it now?

Apart from that, I made a proposal to merge into OCB v7.0.

[Olivier Dony (Odoo) (odo-openerp)]

This has finally been fixed in server trunk (v8) at revision [1], thanks to Lionel's merge proposal!

[1] 5140 rev-id <email address hidden>