Before this commit escape was needed to use a Markup object as a
parameter, hence loosing the fallback mechanism in translations
>>> escape(_("Order %s has been confirmed")) % Markup("<a>%s</a>") % order.name
Markup("Order <a>SO42</a> has been confirmed")
Now it is possible to explictly give a Markup object to the gettext call
>>> _("Order %s has been confirmed", Markup("<a>%s</a>") % order.name)
Markup("Order <a>SO42</a> has been confirmed")
Part-of: odoo/odoo#139316
Currently, bulk-importing translations for non-module loaded data is hard
1. PO file import works fine, but exporting a PO template for non-module loaded
data is near impossible (since PO exports will only export entire modules)
2. Import of translated values during csv/excel file import is not supported
This commit fix the issue by improve 1 which reuses the translation export
wizard for modules to export translations for non-module records. So that user
can export translations for selected records with a domain and import the po
file after translating
[DEBUG MODE] Settings -> Translations -> Export translations -> Export Type
("model") -> Select `Model to Export` and `Model Domain` -> Export
The framework will
1. create external ids for records without external ids
2. export translations for stored translated and inherited translated fields
closesodoo/odoo#138531
Task: 3463505
Signed-off-by: Raphael Collet <rco@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
this commit improves the performance of importing translations by
1. groupup udpating data for different languages and different modules
2. read model_terms translations data directly with xmlid to get rid of fetching
data from ir_model_data
for modules:sale_management, point_of_sale, industry_fsm, helpdesk, mrp, mrp_plm
(62 installed modules)
time for test_language_install is 45.14% less
for all modules:
time for test_language_install is 68.03% less
closesodoo/odoo#107332
X-original-commit: 727ef9e0a2ca93089b472eb1313117fee8dc876d
Signed-off-by: Raphael Collet <rco@odoo.com>
before this commit:
If a translation is used for web client, the translation has comment
'openerp-web'.
after this commit:
If a translation is used for web client, the translation has comment
'odoo-javascript'
If a translation is used for python, the translation has comment
'odoo-python'
PO/POT files with old comments still works. The only overhead is: translation
only for web client will also be stored as code translation for python.
closesodoo/odoo#105764
X-original-commit: 13a5fa56ac7a102ad38f7ecc11874786bdb2fe85
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
before the commit: web client code translations cannot be exported in the po.
If a web client only translation (not used for python translation and has
comment openerp-web) has its translation in the po file of /i18n, when it is
exported in a po file from Settings -> Translations -> Export Translation,
its corresponding translation is missing.
after this commit: web client code translations can be exported in the po.
X-original-commit: c2bf7665363b988d7c7e8bff43e71b7b1097ad84
Part-of: odoo/odoo#105764
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
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Because method _read() no longer updates existing values in memory,
those values in memory must be consistent with the database.
On the other hand, if pending updates are not performed on the database
before fetching values, it means that the corresponding database values
cannot be put in cache. This implies that one cannot empty the cache
without flushing the corresponding fields.
In order to avoid mistakes, flush automatically before invalidating the
cache. This makes the invalidation methods safe by default, and avoids
cargo-culting which would systematically associate invalidation to
flushing, which may eventually be less performant.
Part-of: odoo/odoo#66938
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@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 license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
- Currently all menus are out of order in app switcher.
- For example, Sales app is 16 menu away from Accounting,
Social Marketing app is 25 menu away from Email Marketing, etc.
So, all menus should be reordered.
- This commit will reorder the menus of the app switcher in order to reduce
the distance between correlated applications,
and bring the most common apps upward.
- And in this commit we have left gap of 5 subsequent sequence for further new menus.
PR: #69984
TASK ID: 2513082
Related: odoo/enterprise#17989
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
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>
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>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
To be able to detect issues in .pot like at #41364 due to bad .pot
file (cf fix at #41650)
closesodoo/odoo#41778
Related: odoo/enterprise#7200
Original-signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
X-original-commit: ba39590b004655df55d5d182c4ad50caa7f583c1
Signed-off-by: Martin Trigaux (mat) <mat@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>
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.
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>
FP request: hide the field from the view as too technical
MAT analysis: it should be true by default as most expected behaviour
(it was the reason why it was displayed in the first place)
closesodoo/odoo#35679
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
get_installed and _lang_get_id are both ormcached and correctly check
the context
Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation
closesodoo/odoo#35504
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
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
export.selection.withdefault and export.selection both have a selection field
with Foo and Bar as possible selections.
When doing
self.env["base.update.translations"].create({'lang': 'fr_FR'}).act_update()
the base.update.translations wizard exports the translations of ALL modules,
including the ones of the test_impex module.
The generate po entry is something like:
#. modules: test_impex, test_translation_import
#: selection:export.selection,value:0
#: selection:export.selection.withdefault,value:0
#: selection:test.translation.import,import_type:0
msgid "Bar"
msgstr "Bar in french"
but may also be
#. modules: test_translation_import, test_impex
#: selection:export.selection,value:0
#: selection:export.selection.withdefault,value:0
#: selection:test.translation.import,import_type:0
msgid "Bar"
msgstr "Bar in french"
(not sure where the indeterminism comes from)
which creates 3 translation entries that are sometimes linked to the module
test_impex (ignored when exporting the translations of test_translation_import)
but are sometimes linked to the module test_translation_import instead
In the second case, this makes 3 more translations that is was supposed to
exist.
This commit hides the symptom by making sure there is no longer a clash
when exporting the translations of the module test_translation_import.
A real fix to avoid creating unnecessary translations during an execution of
the base.update.translations wizard must also be made in the future.
It is assumed the unnecessary translations problem was already present before
a7621137cb but polib introduced the indeterminism
making the test fails from time to time.
closesodoo/odoo#33958
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This test also fails before the module extraction commit as the code
translations like the one for 'Ijkl' have no 'module' value during the reimport
and are ignored by the following search
closesodoo/odoo#32022
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When a single po file is processed (i.e. direct po import, not read from a i18n
directory inside a module), there was no module information on code translations
The module information is important for web translations where the list of
modules is given in the call to the route '/website/translations' and
'/web/webclient/translations' and only the web translations of these specific
modules is retrieved and used.
To manually import the translations of a custom module (e.g. openerp_enterprise),
the base.language.import wizard is typically used and the give .po file is
directly imported.
For model and model_terms, the module information is easily deducted from the
the record external id (<module>.<reference>) but for code translation, we
relied on the global variable module_name.
The .po file do contain the module information but this information was ignored.
Real example:
#. module: openerp_enterprise
#. openerp-web
#: code:addons/openerp_enterprise/static/src/js/odoo_enterprise_start_trial.js:249
#, python-format
msgid "Please choose your domain name"
msgstr "Veuillez choisir votre nom de domaine"
Before this commit, the above translation was imported without the module and
was not retrieved in the '/website/translations' call on the /trial page
The global module_name is still used when set for backward compatibility.
Co-authored-by: Raphael Collet <rco@odoo.com>
With 12.0's (#28297) empty translations were no longer added by default
with the idea that if needed the "Generate Missing Terms" wizard should
be used.
But that wizard itself used what was modified so also did not added
empty translation.
With this changeset, empty translations are added when using the
"Generate Missing Terms" wizard.
fixes#29184closes#30037
When there is a language and its base language translation files in a
module, in 12.0 an empty translation in the language translation file
will not fallback on the base language.
eg.
fr.po : {'one': 'un', 'seventy': 'soixante-dix'}
fr_BE.po: {'one': '', 'seventy': 'septante'}
=> the translation in fr_BE will be {'one': '', 'seventy': 'septante'}
but before 7288b477 it would have been {'one': 'un', 'seventy': 'septante'}
With this commit, an empty translation is no longer created so does not
override base language.
Also the intention of d84b795b0a that was also lost is restored by
upserting only noupdate==false translation, and inserting the other
ones.
opw-1904638
closes#28297
Due to fccfd36 and 4ba7fbb the translations were only imported, considering the
.pot as the reference.
During import or a manual csv or po file, there is no pot file.
Add tests with Klingon and Dothraki
Fixes#27044
In the first attempt at #26134, the pot_targets was cleared after creating
the pot_rows object.
Since the rows not present in the pot_targets are now skipped, clearing the pot
should not be done.
Still use a temporary list pot_rows to avoid modifying the list we are iterating
on.
Update the .po test file to match the new file format
Closes#26881
Martin Trigaux