Community: Framework mailing list archives

Re: [patch] ir_translation non-deterministic on duplicates

- 03/26/2015 14:05:58
On Tue, Mar 24, 2015 at 08:48:15AM -0000, Lionel Sausin wrote:
> Le 23/03/2015 23:14, Neels Hofmeyr a écrit :
> > Hi Odoo,
> >
> > we have had quite a few problems with non-deterministic behavior of
> > translations. (...)
> > To make ir_translation a) deterministic, b) filter away empty entries and
> > c) warn the developer of conflicts, I have come up with the attached patch
> > for odoo 8.
> >
> > I would appreciate some thoughts on this patch, and possibly you might
> > like to adopt it upstream.
> Thanks a lot for your proposal.
> If you want proper comments about it, you must register to,
> fork odoo/odoo and make a "Pull Request" there.
> Be sure to include "@odony" in the description of your proposal. That
> will bring it to the attention of Olivier Dony, a fine person at Odoo's
> who has experience with this part of the code.

Thanks for your feedback!
I'll try on github then.

> > I also have a patch for odoo 7, if anyone is interested. It is quite
> > similar. Just ask :)
> If both are similar, your best move is to propose the one for v7. The
> R&D team will port it to v8 anyway.
> Or they may decide it's not fit for stable releases and ask for a PR
> against "master".

The v7 patch is semantically similar, but the function in question has
been split up into two. So the patch looks different at first sight.

> > There's also a second source of .po trouble, not related to above patch.
> > If two .po files provide differing translations for the same
> > ir_translation key, whichever .po is installed last wins.
> This may (or not) be on purpose. We've once used this "feature" to
> override official translations with our home-jargon.

Some may find it acceptable to rename a field from another module (it
feels weird to me though, should rather change the name in the original
module). If that is intended, something has to make sure that one of the
two conflicting .po is always loaded after the other. So the new module
has to depend on the old module; I guess/hope that way the old module's po
is usually loaded first. But it is still possible to load a po manually

  openerp-server --i18n-overwrite --i18n-import path/to/the.po [...]

which does not heed the dependencies between modules. So renaming fields
from another module is IMHO not a good practice, at least from the
ir_translation table standpoint...

This kind of i18n overlay functionality seems more circumstantial than
intended or properly handled. So I think it's more of a bug :)