For instance, when a context was passed to a method, but no lang was defined in the context, it did not tried to fallback to other places where we could have find the user language.
When the addons_path config contained the
default path, the system was working with
an empty addons_path in the middle of the
other paths. This empty one matched for all
files, making all files appear to belong to
the root path component, e.g. `home` if the
root path is in /home.
Refactored a bit to avoid duplicates and
redundant path calculations.
On Launchpad, as commented on bug 933496, PO entries (and their comments) are
shared between series. This mean that e.g. the 7.0 series can have the wrong
`reference` comments (those beginning with #:) as they would be copied from say
the trunk series. Those `reference` comments are used to import translations
and look them up.
This patch adds a few lines of code to tools.translate so that targets
defined in the POT `reference` comments are used in addition to those from the
PO file.
Also adds a test module to validate the new behavior.
This patch stems from:
- the 6.1 branch by Vo Minh Thu:
https://code.launchpad.net/+branch/~openerp-dev/openobject-server/6.1-fix-po-targets-933496-vmt
- the 7.0 port by Numerigraphe:
https://code.launchpad.net/~numerigraphe-team/openobject-server/7.0-fix-po-targets-933496-vmt
Fixes the translation term import/export logic to
support terms inside QWeb templates.
Refactored a bit the export code so the babel-based
QWeb terms extractor for ./static/src/*.xml files
uses the same logic as the regular extractor for
ir.ui.views with type QWeb.
Server-side QWeb rendering uses a mix of the native
view inheritance mechanism and the template inclusion
(t-call) mechanism. During rendering the translations
are only applied at "template" level, *after* the
view inheritance has already been resolved.
As a result translations are local to a template,
not to the inherited view in which they are actually
written.
In terms of exporting PO[T] files, this is done by
resolving the "root" QWeb template a view belongs
to, and using it as the location of the translated term.
During import there is one extra quirk for QWeb
terms: they need to be linked to the `website` model
rather than the actual `ir.ui.view` model they
are really pointing to, so the rendering phase can
properly recognize them.
Can be defined to False in any model to completely
disable translations for this model, when they are
irrelevant. This is useful e.g. for test classes
that use attributes that would normally be translatable.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
When re-loading a translation (with 'Overwrite Existing Terms') we need to
empty the translation cache to ensure overwritten terms get their new values.
bzr revid: xal@openerp.com-20131217145738-9oy2fjhbc46yzonq
Either use openerp.modules.registry.RegistryManager when the full
new() signature is needed, or use openerp.registry().
Replaced also some pool.get() with pool[] because KeyErrors
are better than AttributeErrors on None.
bzr revid: vmt@openerp.com-20130327111014-2i0hlvpy5y5ku7hm