[6.1/trunk] Translations: creation of a record does not generate translation lines

[Guewen Baconnier @ Camptocamp]

Hello,

Actually, the original behavior for the translations is quite strange.
Here it is:
    I'm logged in with en_US language.
    I create a record, with a (translatable) title 'My title'
    I check the source in database (table of the object), that's 'My title'
    I check the translation lines for the en_US language, no line
    I write on my record the title 'My title updated'
    I check the source in database, that's 'My title updated'
    I check the translation lines for the en_US language, no line

    I'm logged in with fr_FR language
    I create a record, with a (translatable) title 'Mon titre'
    I check the source in database (table of the object), that's 'Mon titre'
    I check the translation lines for the fr_FR language, no line
    I write on my record the title 'Mon titre mis à jour'
    I check the source in database, that's 'Mon titre' (unchanged)
    I check the translation lines for the fr_FR language, I have a line with 'Mon titre mis à jour'

OpenERP assumes that the en_US is the reference
language, so lets assume it completely, and generate the french
translation line directly when we enter the value.

As we can see, the write method creates translation lines for other
languages than en_US, that's correct.
The create method does not, it has to do it.

That's weird, because, if I create a record in french, the source
will be the french value (of course), but programmatically, we do not
have any means to know that someone entered a french translation.

A simple scenario where the bug will occurs:

    User A is logged in with fr_FR
    User A creates a product with a name 'Marteau'
    User B is logged in with en_US
    User B modifies the product 'Marteau' to be 'Hammer'
    => The french translation is lost.

It won't occurs in this slightly modified scenario:

    User A is logged in with fr_FR
    User A creates a product with a name 'Martea' (typo)
    User A modifies the product 'Martea' to be 'Marteau'
    User B is logged in with en_US
    User B modifies the product 'Marteau' to be 'Hammer'
    => The french translation isn't lost, because the write has
    correctly generated the french translation line

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

Screencast with a simple scenario

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

Hi,

I agree that the behavior of create() vs write() is not quite consistent at the moment. The original reason for the way create() works was probably to avoid having useless duplicate entries in ir.translation for databases that are working exclusively in a non-en_US language.

However for all practical purposes this is an implementation detail, and the system will properly manage translations even for multilingual teams. Therefore this behavior should not be modified in stable versions: it would break the stable policy due to a very low benefit/risk ratio [1].

Your scenario does describe one case where one "translation" might be lost indeed, however I think you will agree that this is a borderline case: both the fr_FR and the en_US users completely ignored the fact that they are working in a multilingual database. Obviously when you see a field that is wrongly translated in a multilingual database, your reaction should be to open the translation popup to double-check the translations, rather than directly change the value. Ignoring this rather obvious rule means you *will* eventually get in trouble with the translations. One classical example is when duplicating records, which requires extra care.

So there's a branch with a fix for 6.1 attached to the bug: feel free to apply it for your 6.1 customers, but let's not merge it in 6.1, and let's instead work on streamlining this for 7.0 (e.g. avoid duplicating the code in create() and write(), avoiding multiple read()/write() calls, etc.)
=> Bug Confirmed/Low for trunk, branch abandoned for 6.1.

Thanks for reporting this issue with all the care needed!

[1] High risk because it requires modifying the core create() API method, and calling write() multiple times in the process, for starters (-> see also the attached branch). Quite low benefit, because it only fixes borderline scenarios for users who don't properly care for translations in a multilingual db.

[Xavier ALT (dex-phx)]

Hi,

FYI, in v6.1 we've merged this branch: lp:~openerp-dev/openerp-web/6.1-opw-579638-cpa.

This force "TranslationDialog" to save all translations of field if a least one translation of that field has been modified. This partially fixes the problem and we don't loose translation in case the record was not created with "English" language.

Note, that this make web behaviour consistent with what the GTK client.