[FIX] web: html_frame field and lang vs onchange

[nle-odoo]

In mass mailing there is several possibilities of states when rendering
the widget with a possibly new value:

1. we are not in edition
   a. we are in same language than user language => the editor content
   can be updated
   b. we are in a different language => the content cannot be updated

2. we are in edition
   a. we are editing translation : the editor content cannot be updated
   b. we are not editing translation (editor language == en_US)
   i. we are requesting editor update (by having magic value
   on_change_model_and_list) => the editor can be updated
   ii. we are in same language than user language => the editor content
   can be updated
   iii. we are in a different language => the editor content cannot be
   updated

In summary:

• if language is the same than the user, we can update the value
• if value is magic on_change_model_and_list and we are not translating,
  we can update the editor

Before this commit, this worked as expected but for 2.a.ii. which if the
user language was not en_US would for example prevent editor updating.

closes #15414
opw-708032

inspired by a27e24c

note: the fix is a fix for 8.0 and saas-6.

[yajo]

No runbot here?

[nle-odoo]

I guess the push needs to be done after the PR is opened to have runbot notification here

The runbot is there: 9.0-mass-mailing-lang-template-update-nle@runbot

[yajo]

I think you missed the version. 8.0 is a complete mess, but this issue happened in 9.0+

[nle-odoo]

yes till 10.0 (in which the system is completely changed)

[yajo]

Thanks, I tested runbot now. Answering to #15414 (comment)...

it is not possible to edit translation of mail.template in the mass mailing module: this is not changed by my patch, and without my patch when we were editing a translation we saw english, with my patch we see spanish (but still can't translate)

OK, so I get the idea is to have a limited version of mail templates for mass mailings that simply avoids these problems. However, if we really want to not look buggy to the user, I think we should remove the language dropdown. Displaying it to the user but not letting him translate can be easily perceived as a bug:

So, IMHO it's better to just drop the language selector from that view if possible, and force it to display always only the English version. User will not see it, and he will not perceive the bug.

OTOH, following steps from #15414 (comment), the bug itself is certainly fixed.

Since fixing this revealed many problems on multi-language templates, I'm going to open an issue when we finish this patch, summarizing all problems; to have at least a meeting point on this problem and be able to fix it.