Merge lp:~numerigraphe/openobject-server/6.0-translations-lost-933496-odo into lp:openobject-server/6.0

Proposed by Numérigraphe
Status: Rejected
Rejected by: Olivier Dony (Odoo)
Proposed branch: lp:~numerigraphe/openobject-server/6.0-translations-lost-933496-odo
Merge into: lp:openobject-server/6.0
Diff against target: 36 lines (+9/-7)
1 file modified
bin/addons/base/ir/ir_translation.py (+9/-7)
To merge this branch: bzr merge lp:~numerigraphe/openobject-server/6.0-translations-lost-933496-odo
Reviewer Review Type Date Requested Status
Olivier Dony (Odoo) Pending
OpenERP Core Team Pending
Review via email: mp+129157@code.launchpad.net

Description of the change

This branch fixes an issue in translations, that makes translations unavailable in stable releases when the strings are removed from the trunk.
It is based on a patch by Olivier Dony, with an additional correction to actually fix the issue.
Lionel Sausin.

To post a comment you must log in.
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Thanks a lot for finishing my proof-of-concept patch, Lionel. The patch seems to work but after thinking about it more we think it might create really weird bugs, due to the way our translation entries are matched (name and/or source).
As you noticed, a simple change in the results ordering can give completely incomprehensible results to the user, and the same could happen when the matching translations are deleted for any reason -> the system would fallback to incorrect matches. Therefor it seems safer and more correct to use the comments that are in the PO templates, and which are not subject to alteration by Launchpad.
The patch Thu implemented in lp:~openerp-dev/openobject-server/6.1-fix-po-targets-933496-vmt is a little bit longer but should be completely low-risk. It also comes with a proper testcase (a test module for trunk - included in 6.1 for documentation purpose), have a look at it and feel free to ask for more cases to be covered if you don't feel confident with it. Backporting it to 6.0 should be simple enough if you really need to do so.

I hope you don't me closing your merge proposals to indicate that we prefer the safer solution. Sorry for having lead you towards an imperfect solution - it can still be used as a temporary fix.

Revision history for this message
Numérigraphe (numerigraphe) wrote :

Thanks Olivier,
That's fine. I've been following Thu's work and using your patch as a temporary fix indeed.

Unmerged revisions

3312. By Numerigraphe - Lionel Sausin <email address hidden>

[FIX] Correct previous patch by selecting only the best translation

3311. By Olivier Dony

[FIX] Mismatching PO comments cause translation issues: translations present in PO not visible in GUI

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'bin/addons/base/ir/ir_translation.py'
2--- bin/addons/base/ir/ir_translation.py 2011-01-07 15:17:35 +0000
3+++ bin/addons/base/ir/ir_translation.py 2012-10-11 11:23:44 +0000
4@@ -155,23 +155,25 @@
5 if isinstance(types, basestring):
6 types = (types,)
7 if source:
8- query = """SELECT value
9+ query = """SELECT value,
10+ CASE WHEN type in %s THEN 1 ELSE 0 END as priority
11 FROM ir_translation
12 WHERE lang=%s
13- AND type in %s
14 AND src=%s"""
15- params = (lang or '', types, tools.ustr(source))
16+ params = (types, lang or '', tools.ustr(source))
17 if name:
18 query += " AND name=%s"
19 params += (tools.ustr(name),)
20+ query += " ORDER BY priority DESC FETCH FIRST ROW ONLY"
21 cr.execute(query, params)
22 else:
23- cr.execute("""SELECT value
24+ cr.execute("""SELECT value,
25+ CASE WHEN type in %s THEN 1 ELSE 0 END as priority
26 FROM ir_translation
27 WHERE lang=%s
28- AND type in %s
29- AND name=%s""",
30- (lang or '', types, tools.ustr(name)))
31+ AND name=%s
32+ ORDER BY priority DESC FETCH FIRST ROW ONLY""",
33+ (types, lang or '', tools.ustr(name)))
34 res = cr.fetchone()
35 trad = res and res[0] or u''
36 if source and not trad: