Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
The ir_translations were pretty slow to load, this was mainly caused by
the condition in variable 'find_expr' and the import of po values in the
temporary table.
To improve the load performance, we made two improvement:
1. Insert the row in the temporary table by batch instead of making an
insertion for each record.
2. Replacing the condition in the variable 'find_expr' by partial unique
index. To perform such a thing, we had to separate the type model in
two types, 'model' and 'model_terms' because it wasn't possible to
create a partial unique index on type 'model' because the type was
used for two different use cases. The type model is now used for
fields that have have a value not callable for the attribute
translate, these field can only have one record for the same field,
model, res_id and language. And the type 'model_terms' is used for
the fields callable, because they can have multiple sources for the
same res_id.
We also removed the deprecated types 'report', 'help', 'view', 'field'.
Thanks to @rco-odoo for the improvement of the first point.
When generating new translations (e.g. 'edit translations' button on a view or
on a translatable field), the new generated translations have the source as
translation value.
Set the state to 'to_translate' as it is the default value
This change requires to add a fallback in web_editor when computing translated
dom
When a translation has no value, there is a fallback done in the different
translation method (e.g. xml_translate) but, as the node was manually created
in edit_translation_mapping, the fallback was missing
closesodoo/odoo#24391
The html_translate fields (e.g. website_descripton on product.product) were not
serialised and the raw value from the web_editor was saved as a translation.
This was an issue in case of special characters that may be present in the
translation. A translation containing non-breaking space was sent in html
(`foo bar`) while lxml converts such characters to unicode (`foo\xa0bar`).
When writing a translation, the value is checked against incorrect format using
```
value0 = field.translate(lambda term: None, record[fname])
value1 = field.translate({trans.src: trans.value}.get, value0)
value2 = field.translate({trans.value: trans.src}.get, value1)
if value2 != value0:
raise ValidationError(_("Translation is not valid:\n%s") % trans.value)
```
As value1 is the unicode version of the translation and `trans.value` is the
html version of the translation, the last substitution in the callback method
was never made and the ValidationError was raised.
This commit forces the serialisation through lxml to be sure the compared
strings are using the same parser instead of comparing value from summernote and
lxml that may be both valid but still different.
opw-675767
There is a logic on the front-end to escape translated text content when
saving them as ir.translation record.
This logic was in part base on html elements and if these element were
not coming from an html field other than "ir.ui.view" arch_db's field.
This logic was introduced in 8.0, and something similar was later
introduced in 9.0 with f5acea7, but in this instance, the information
[data-oe-model] on nodes was not available. Thus some html field from
other model than ui.ui.view would have their translation escaped
erroneously.
This commit adds a data-oe-model attribute on to-be-translated nodes
which will then be available to the frontend.
closes#10420
first-part-of: opw-659772
Adrian Torres