Before: while upgrading to 16.0, the PO file is loaded before migrating
ir_translate. As a result, old translations from ir_translation
override the new translations imported by new PO files.
After: translations imported by the PO file take priority over the
translations migrated from the ir_translation table.
X-original-commit: 178270eff48221537a4efba1ad8fa0b53a1516f2
Part-of: odoo/odoo#103031
Previous versions of spreadsheet files don't have a name
for list and pivot datasources.
The spreadsheet template "pipeline dashboard" in `document_spreadsheet_crm`
is such a file.
As a consequence, exporting the source terms from this module fails
with a `KeyError: 'name'`
Part-of: odoo/odoo#101659
This commit extract translatable content from spreadsheet data.
- chart titles and description
- pivot and list names
- argument of _t() functions
- labels of links
X-original-commit: d210a55f48b316fdf38fcbe5ae5a70cf0e2c3814
Part-of: odoo/odoo#101120
Nodes like
<attribute name="t-on-dragenter.stop.prevent">() => state.dropzoneVisible = true</attribute>
should not be exported in the translations files but
<attribute name="string">Hello World</attribute>
should be kept
It was already the case in the xml processing method for server side
templates.
Since 16.0, client side QWeb views also use the same inheritance
mechanism than the one on the server side so the exception needs to be
replicated.
X-original-commit: e05d1192481935b2cd7aae7e939f98e60e002899
Part-of: odoo/odoo#101053
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The issue has been introduced by 1fe4b0cc1981382cc3d944ec44276f0aee90945d.
A simple example is an element with attribute "string" like
<field name="foo" string=" "/>
When the translation process is parsing the value of the attribute as
some HTML fragment html.from_string(" "), it raises an exception. This
was not a problem before the commit above, but it now is. For instance,
updating the view "event.view_event_form" triggers the error.
closesodoo/odoo#84144
X-original-commit: 5ffc1704162d8918985964b08f4b2b49e6054958
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
When comparing existing translations to new source value
html tag would invalidate existing translations.
The html tags used for styling (coloring, italic, ...) should not
invalidate the translation as the meaning of the text as not changed.
Changed the logic to compare translations based on textual content only.
+ add some tests.
task-2667950
closesodoo/odoo#83895
X-original-commit: 1fe4b0cc1981382cc3d944ec44276f0aee90945d
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
Co-authored-by: xmo-odoo <xmo@odoo.com>
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This hook automatically generates custom tooltips (instead of
native ones) for all elements with the "data-tooltip" attribute
set, inside the component using it. The optional attribute
"data-tooltip-position" can be used to enforce a specific tooltip
position.
This commit also makes the WebClient use this hook.
Part-of: odoo/odoo#73311
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
As the descriptions of the donation snippet will be in hidden inputs,
we added the possibility to translate these inputs in translate mode.
PR-63133
task-2398403
Part-of: odoo/odoo#63133
before this commit: create_text was passed in node options and due to which it
was not parsed by translate.py, pass add-label as attribute on field so that
translate.py parse it and it is translated.
after this commit: create_text will be passed as field attribute instead of
node options.
task-1923433
closesodoo/odoo#59713
Related: odoo/enterprise#19418
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
58d3b670221b3 was not correctly forward ported, it misses the `''` fallback part
of the original commit dc20ab9c02
Without this, traceback is shown.
Step to reproduce:
- Open HTML Editor (or edit a backend view)
- Add an input with no class but a value attribute (no type or type text)
closesodoo/odoo#73057
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The 'class' attribute was not safely accessed using get. Since this attribute is not always
present the condition evaluation failed in some cases.
task-2276724
closesodoo/odoo#72894
X-original-commit: 58d3b670221b37c5c4c67ee53fbc545f6fb70395
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
It seems some terms are no translatable so purpose of the task is
to find those terms ans update to make them translatable.
So in this commit, translate the text attribute when the node is field
tag and this node contains widget='url' in its attributes. and
also make the project name as translatable.
closesodoo/odoo#71406
Taskid: 2487710
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: xavierbol <xbo@odoo.com>
Correct small typo that the module when exporting translations as CSV
file might have been the wrong module because we used variable from
previous loop.
This did not seem to cause any issue since in this given case in import
we got the module from the part before . in XML ID ({module}.{name})
that was right.
found when working on opw-2439029
closesodoo/odoo#68297
X-original-commit: 62e7b161d39e5f5f6751cf87826fa6f7b729f83d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When importing transtlation from CSV, we:
- cut at `:` character to get the model
- used a model for types other than model and model_terms
This caused error that do not happen in PO import because:
- the model is before the `,` character
- the imd_model column is constrained to 64 characters, and a name that
is not a model could be over that size.
With this changeset, the CSV import match better current PO import.
opw-2439029
closesodoo/odoo#68266
X-original-commit: cff91c6acbb7ef6a884d4dc4170574b83ff6e4cb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The former algorithm was recreating a full etree from scratch, while
parsing the content to translate. Instead, we parse the etree and
update only the content that to be translated.
Before:
| In [2]: %timeit views.invalidate_cache(); views.mapped('arch_db')
| 578 ms ± 7.83 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
After:
| In [2]: %timeit views.invalidate_cache(); views.mapped('arch_db')
| 208 ms ± 2.79 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
Reading a view is 2.63x faster: from 504 ms, to 191 ms (sum of all the
1345 views, when installing website_sale). Large views, like web pages
goes up to 3x-4x faster; small views are ~2x faster.
As views are cached, it only impact the loading to put in cache, but all
XML/HTML fields get the same performance gain.
closesodoo/odoo#68182
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
To reproduce:
1. take a translatable record with an external id
2. delete the record but keep the ir.model.data (sql)
3. export the translations of the module linked to the orphan
ir.model.data
-> Error while formating the message
This commit fixes three issues:
- %d instead of %s to construct the string
- wrong order to identify the missing records
- display the external ids instead of the ids (which may not be very
helpful to debug)
Courtesy of Yannick Brant
closesodoo/odoo#67530
X-original-commit: a2a45539ca4056eb3b3d5d6bafbfb63c10255843
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
* = web_editor
Add support for default values on website form
Compatible fields are: textarea, text, number, date, datetime, unique
checkox, multiple checkboxes, radio buttons, select.
Part of: https://github.com/odoo/odoo/pull/47949
task-2011583
The parsing of external ids was made with the regexp `(\w+)\.([\w-]+)`.
This regexp is inadequate for external ids that contain non-alphanumeric
characters like. We have such a use-case with the selections of field
`rating_operator` in module `sale_subscription` that uses the values
`">"` and `"<"`.
The fix consists in replacing the regexp by `(\w+)\.([^ ]+)`.
closesodoo/odoo#63017
X-original-commit: 52bf0e331fb9230423b76b9014bb13d490930e76
Related: odoo/enterprise#15189
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Since 14.0, the javascript code of snippets is moved inside a
/static/src/snippets directory.
With owl, the components are defined in static/src/components
Some other modules were using more exotic path and ended up with no
translations.
opw-2381030
X-original-commit: f1d403723d59b8e53b00cf2d26bd9d3d54437803
In order to ease the usage of lazy translation, add the possibility to
add the _lt objects together and with strings.
Adding two _lt objects together or to a string will execute their
translation, so these operations still must be done once the user's
language has been defined.
For example, this is now possible:
MESSAGES = {
1: _lt("Hello, world!"),
2: _lt("Lorem ipsum"),
}
def get_text(code):
return _("Text is: ") + MESSAGES[code]
closesodoo/odoo#60844
X-original-commit: c4596664e5514018c565eaf14b93e000d972bd30
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
When trying to generate translation for a model that is not present in
the registry (leftover of migration?), the code used to return
self.browse(), expecting an empty recordset.
self was however a TranslationModuleReader that has no browse method
return empty recordset with no model specified
closesodoo/odoo#55574
X-original-commit: c004f00bdec83b7c56664425011db53db85da53a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Avoid returning False if, for any reason, the return is falsy (False,
None,...)
Following the discussion in odoo/odoo#53254, the root cause was a call in the form
_(foo)
where foo was equal False
While nothing else than a string should be the argument of _, it's
still technically possible to pass something else and get a bad return
value.
Fallback on empty string to be consistent.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Mimic the syntax of logging to use placeholders in translatable
message.
The main advantage is to be able to fallback on the source term if the
translation can not be formatted properly.
It is very common to have errors in translations with missing
placeholders or badly translated (ie. the source
"%(subject)s" -> "%(sujet)s").
Instead of blocking the execution of the code, fallback on source
string.
Task-id: 1853119
Before this commit trying to reimport csv of a translation failed.
The reason was that before 632fa044c3 the parsing was common
between po and csv while now it's split in two different parsers.
The res_id column of the CSV is the external id of the record and is
handled by IrTranslationImport.
Use DictReader instead of csv_reader to easily add new keys and still
be flexible on the given csv files.
Match the POReader format with a imd_model and imd_name column.
As for the PoFileReader, the code translations are unique and must be
discarded in case of duplicate.
Correct the error message if the imported file is not correct (was
missing an argument)
Fixesodoo/odoo#50975closesodoo/odoo#51468
X-original-commit: 3cedadb5ba606e156f52e70ed08b25ac2df8d58b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Have a static template of the form:
```xml
<div t-name="ComponentA">
<ComponentB title="no export" />
</div>
```
To be used by OWL (github.com/odoo/owl)
In this context, the title in the attributes of ComponentB
should not be considered as *the* title attribute of HTML
but as a sort of variable declaration
Before this commit, the string contained in the value of this
title attribute was exported. It was not translated at runtime,
but we want to export as less stuff as possible in PO files
So, after this commit, none of the attributes held by a OWL directive
are exported
This commit relies on OWL Syntax, which makes mandatory
for a component directive's first letter to be capitalized
https://github.com/odoo/owl/blob/master/doc/reference/component.md#composition
Also, it relies on the good practice and widespread convention to have
every HTML node lower cased
https://www.w3schools.com/html/html5_syntax.aspclosesodoo/odoo#46191
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In 12.0 9de1bc0e aria-label translation was added for python views, but:
- aria-label attribute are not exported
- aria-label are not translated for JS view rendering
So by default, aria-label would only be translated for python views that
had the same aria-label term in a translatable element (eg. "title"
attribute).
opw-2222504
closes#48255closesodoo/odoo#48275
X-original-commit: 6b6b11ea2f8391f1f195bd1650531f77b6bed729
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, the export of translations was incorrect for code
and model translations:
For code translations, the field 'name' was used for the matching
while the _() method explicitly use None in the _get_source call to
only use the field 'src' for the search.
For model translations, the field 'res_id' was not used when searching
for a translation.
For instance, if a ir.model.fields did not have translated label,
exporting the translations was using the translations of the first
field having the same source.
While this could be convient during the import (to be discussed),
doing so in an export of translation is clearly an unexpected
side-effect.
closesodoo/odoo#40909
X-original-commit: 4534181f106cf5aa50c65c942c260eeec122d3d2
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
No justification, commit message not linked to the diff.
If there is an issue in the line_number extraction it must be
investigated.
I suspect an outdated polib version.
closesodoo/odoo#40684
X-original-commit: 0f92dae8eb76a47326bd2bb8924df8fa09645145
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Instead of previous long methods, use a class to clarify what the
export actually does.
The TranslationModuleReader is written to copy the API of the
TranslationFileWriter.
This way, exporting translations is reduced to:
1. create a reader that will fetch all module translations (either
from db or from static files)
2. create a writer in a specific format (po or csv)
3. export the content from the reader to the writer
Simplify the writer by deducing modules from exported translations
instead of fetching it again in a oneliner (this way can benefit from
yield operations)
Remove the 'all_installed' possibility in modules as it was not
working (creating query with 2 WHERE clause).
The new methode _get_translatable_records works on a per model basis.
This will allow a big performance gain as the previous code was
making a .exists() for each record individually.
In the future, this method could be removed as the main goal is to
test the presence of the rare attribute _translate=False.
It was misleading as only forced for translations of type 'code' but
for the other translations, it was retrieved from the imported file
(the comment in a .po file or column in a .csv)
This will allow another optimisation in the next commit, moving to a
TranslationModuleReader instance
Instead of relying on the context content, pass explicit values for
overwrite and create_empty_translations
applu this to trans_load and trans_load_data
Adapt the test that was trying to create empty translations.
load_lang was a kind of hybrid method trying to active or creating a
language if not found. This was error prone.
Instead rely on two methods with clear purpose:
ResLang._create_lang(lang, lang_name=None)
- create a new res.lang entry using the locale of the server
return the res.lang record to match the API of _activate_lang
ResLang._active_lang(code)
- activate the given code lang
Most of the time, _active_lang is what is expected
tools.trans_load_data and IrTranslation._load_module_terms no longer
activate the language if not active.
Loading the translations should be explicit on an activated language,
it is too error prone to silently activate/create a language if not
found.
Remove lang_name from trans_load_data as no longer needed.
* walksymlinks is useless, os.walk got followlinks in 2.6
* tempdir is redundant with tempfile.TemporaryDirectory added in 3.2
* listdir(recursive=False) is just os.listdir (I guess recursive=True
is somewhat useful)
* zip_dir is *not* redundant with shutil.make_archive:
- zip_dir handles the archived root differently
- zip_dir sorts files, make_archive sorts directories
- make_archive explicitly adds entries for directories (including
empty), sorts directories, doesn't sort files; zip_dir sorts
files (including with a custom key function) but ignores directories
- zip_dir filters out a bunch of trash files
closesodoo/odoo#39573
Signed-off-by: Christophe Simonis <chs@odoo.com>
Do not return a boolean but skip bad translations
Introduced at 19e50ea374Fixesodoo/odoo#39001
At least fix the error that is thrown, however, this does not solve
the initial error of trying to export the terms of a record that is no
longer present in the database.
As this issue is no longer reproducable, just log a warning as it was
expected.
closesodoo/odoo#39122
X-original-commit: 5c0677bf2fbf6d18978989f1ee70e4a0946da035
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
[PEP-594] is deprecating the `imp` module, that module is used in
`module.py` in order to dynamically import addons using any of the
`odoo.addons` or `openerp.addons` import anchor.
We are deprecating `openerp` module/addons imports in v13 in order to
remove the support in v14 and greatly simplify how modules/addons are
loaded. If you are still using the old `import openerp` or `import
openerp.addons`, `import odoo` and `import odoo.addons` are drop-in
replacements.
The `odoo.modules.module.ad_paths` addon paths list has been deprecated
too. The list is now accessible on `odoo.addons.__path__` where they
are now directly loaded [2].
See also:
[PEP-594]: https://python.org/dev/peps/pep-0594/
[2]: https://packaging.python.org/guides/packaging-namespace-packages/closesodoo/odoo#36597
Task: 2003936
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If a model is tagged with _translate=False, it should not be translated.
A special case was made for ir.model.fields but not ir.model.fields.selection
Before this commit, the selections of web_editor.converter.test were translated
closesodoo/odoo#36576
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When a selection field has a dash the parsing was failing only returning the
begining of this selection, leading to a mismatch fot the ir_model_fields_selection.
This was discovered because "iot.trigger" add multiple selection fields element with name
only differing by the post dash part:
print
print-op
print-slip
This was leading to a failure of the ON CONFLICT DO UPDATE (ir_translation line 120)
since multiple EXCLUDED where similar in mrp_workorder_iot/i18n/fr.po(same res_id).
closesodoo/odoo#36347
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Babel is already taking the language into account while
formating a time delta into a readable string like '2 minutes ago'.
_format_time_ago was put in translate.py file to be able to use
the _ translate class. But it can be placed in misc like other
format function already using babel.
This fix the PR #34624
and is linked to Task ID : 2028059
Task ID: 2055847
Closes PR #35806
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The selection values of a selection field are now stored in database in the
model ir.model.fields.selection
This will allow to have a modular approche on selections and each selection
is now linked to the module that declared it.
Previously to this change, the selections were linked to the field, meaning
uninstalling a module had no impact on the selections stored on database.
With this change, the selections will now be translated in the correct module
(having an external id) and the records having a used selection will now be
reset to null.
closesodoo/odoo#30228
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
Chong Wang (cwg)