openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <1053970@xxxxxxxxxxxxxxxxxx>]

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.

** Changed in: openobject-server
   Importance: Undecided => Low

** Changed in: openobject-server
       Status: New => Confirmed

** Changed in: openobject-server
    Milestone: None => 7.0

** Changed in: openobject-server
     Assignee: OpenERP Publisher's Warranty Team (openerp-opw) => OpenERP's Framework R&D (openerp-dev-framework)

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/1053970

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

Status in OpenERP Server:
  Confirmed

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/1053970/+subscriptions