Merge lp:~savoirfairelinux-openerp/ocb-addons/7.0_mail_thread_translate_bug1262000 into lp:ocb-addons

[Sandy Carter (http://www.savoirfairelinux.com)]

Fix for bug #1262000 in which OEChatter's mail_thread widget does not translate the object's _description field resulting in half-translated messages posted in the mail thread.

Simple line change which translates self._description when invoked here.

[Pedro Manuel Baeza (pedro.baeza)]

Very good catch! I have experienced this trouble in my installations.

Please attach the branch to the bug report and track the status for the OCB branch.

Regards.

review: Approve (code review)

[Stefan Rijnhart (Opener) (stefan-opener)]

Hi Sandy, thanks for picking this up.

I'm afraid that your solution does not work in every case. Calling _() on a variable does not really make sense as it will be a matter of coincidence if the translation can be found. You see, internally this call gets translated to

    pool.get('ir.translation')._get_source(cr, SUPERUSER_ID, None, ('code','sql_constraint'), lang, source)

so it will only work if there happens to be an existing code or constraint translation with the name of the model. This is the case for Invoice, but not for Incoming Shipment for example.

I don't know of any easier way to get the model name in the user's language than a search+read on the ir.model pool.

review: Needs Fixing

[Sandy Carter (http://www.savoirfairelinux.com) (sandy-carter)]

@Stefan, I am not sure I understand you.

I have been using this patch on my own projects and it will always translate the created object as long as _() has been put around the _description of the model and the required translation has been exported.

as for stock_picking_in in stock/stock.py, the problem should be resolved by putting _() around the description text and updating the .po/.pot files:
    _description = _("Incoming Shipments")

[Stefan Rijnhart (Opener) (stefan-opener)]

> as long as _() has been put around the _description of the model and the required translation has been exported

Yes, you could put it this way because this requirement is not fulfilled
for any model by default. So your solution does not work for anyone
else, except by chance. That is why I suggested you do something like

- search model_id
- browse model_id with context with user language
- use this browse record's name field which is guaranteed to be in the
user's language

This would work for everyone.

[Stefan Rijnhart (Opener) (stefan-opener)]

> as long as _() has been put around the _description of the model and the required translation has been exported
Or you make it a part of the patch that this be updated in every model.
You should discuss with Olivier Dony cause this would solve the problem
in other places as well.

[Sandy Carter (http://www.savoirfairelinux.com) (sandy-carter)]

Stefan, how about this following patch?

It will add the _description of any module having its translations exported regardless of _() around the description in the model declaration.

=== modified file 'openerp/tools/translate.py'
--- openerp/tools/translate.py 2014-02-06 10:51:41 +0000
+++ openerp/tools/translate.py 2014-02-26 21:37:49 +0000
@@ -656,6 +656,11 @@
             return s.encode('utf8')
         return s

+ for module in modules:
+ obj = pool.get(module.replace('_', '.'))
+ if obj:
+ push_translation(module, 'code', '_description', 0, obj._description)
+
     for (xml_name,model,res_id,module) in cr.fetchall():
         module = encode(module)
         model = encode(model)

[Sandy Carter (http://www.savoirfairelinux.com) (sandy-carter)]

launchpad has taken out the indentation after +...

[Sandy Carter (http://www.savoirfairelinux.com) (sandy-carter)]

Here we go:
https://code.launchpad.net/~savoirfairelinux-openerp/ocb-server/7.0_mail_thread_translate_bug1262000/+merge/208488

[Leonardo Pistone (lepistone)]

Thanks for your work. Is that one superseded?

[Stefan Rijnhart (Opener) (stefan-opener)]

You seem to turn module names into models here, that does not seem correct. But there are indeed ways of finding all models within the context of their modules using a join on ir.model.data and ir.model. Instanciating them and pushing their _description's translation would solve the problem for custom models, but not for the official addons unless the change was adopted in lp:openobject-server. Otherwise the translations won't show up in Launchpad Translations.

But let's go for that then and we can merge this change for custom models and in anticipation of the server change.

review: Approve

[Holger Brunn (Therp) (hbrunn)]

review: Approve (code review)

=== modified file 'mail/mail_thread.py'
--- mail/mail_thread.py	2014-02-13 11:59:22 +0000
+++ mail/mail_thread.py	2014-02-24 18:20:20 +0000
@@ -251,7 +251,7 @@
 
         # automatic logging unless asked not to (mainly for various testing purpose)
         if not context.get('mail_create_nolog'):
-            self.message_post(cr, uid, thread_id, body=_('%s created') % (self._description), context=context)
+            self.message_post(cr, uid, thread_id, body=_('%s created') % (_(self._description)), context=context)
 
         # auto_subscribe: take values and defaults into account
         create_values = dict(values)