* 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>
This commit adds the website_visitor model that will be used
to track website visitor activity (page viewed, number of visits and
more general info about the visitor (country, lang, etc..)
This model will, in later commit, be used to send chat requests
and push notification from the operators (or backend users)
directly to the visitor.
- A website_visitor is created once the visitor is requesting
a website.page that is tracked.
- A website_visitor is considered as connected if his last tracked
website_page request is within the last 5 minutes.
- The number of visits for a website_visitor is incremented
if his last tracked website_page request was at least 8 hours ago.
- A website_visitor is only handled by the system. Users cannot
create, edit or delete a website_visitor.
- A unique website_visitor is created per website.
That means that the same real person can triggers multiple visitor
creation if visits multiple websites.
This is because, for livechat purpose on later commit, for example,
the chat request can be created on the correct livecaht channel
(linked to the correct website)
- The visitor is recognized via his cookie (visitor_id). So if the visitor
flush his cookies, a new visitor will be created the next time he will
request a tracked website_page.
- Link user's res.partner to website.visitor.
If a website_visitor log in
(a visitor that has visitor_id in his cookie),
the website_visitor is linked to the res.partner.
The website visitor name is than adapted to match the name of
the first res.partner linked to the visitor.
A visitor can have multiple partners as the same session
can be used by multiple person (one PC for a team for example).
To keep a detailed history of the visitor page views,
we add a website.visitor.page model that makes the link
between visitor and website.page but that keeps the visit date.
So that we can see if a visitor went mulitple times
on the same page and when. It's usefull to see his last page views.
Task ID : 2028059
PR #34624
The line number was only indicative and was not used by the system.
When the translations source were updated, a big part of the diff was
only about the line numbers.
Ignore the given res_id value and export the line at 0
When reading the po file, the res_id from the file is still read and
stored in database but should be ignored
closesodoo/odoo#35582
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Introduces the method _lt
The translation method is now evaluated lazily.
It allows to declare global variables with translatable content
e.g. this code will now work:
LABEL = _lt("User")
def _compute_label(self):
context = {'lang': self.partner_id.lang}
self.user_label = LABEL
Using api.constrains should be used instead
Simply leave a warning in case a model uses a non-empty attribute
`_constraints`.
closesodoo/odoo#34679
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Store the SQL constraint message directly in the field `message` of the
corresponding `ir.model.constraint` record, and manage translations from
there. Those records are given an XML id in order to be tracked in PO
files. The translation type 'sql_constraint` is removed.
if an POEntry has an occurrence with a 0 res_id
>>> entry.occurrences.append(("selection:report.paper,format", 0))
>>> str(entry)
#: selection:report.paperformat,format
...
Use the string '0' to bypass this
Xavier Morel