- Moved the web *.po files to /i18n to be consistent
with the addons convention. Using /po was considered
for a while because it played better with LP's auto-
detection of PO Templates, but that is not necessary
anymore, we now have full control on LP templates.
- In order to support addons that contain translations
for both the web addon and the regular addon part,
both kinds of translations are now merged in a single
addon/i18n/addon.pot file. Terms that are used by
the web part are now marked with a PO annotation:
#. openerp-web
so the web client can recognize them and only load
the relevant translations in the browser memory.
This is important because a complete PO file can
be rather large, e.g. account/i18n/de.po = 400KB.
- The web translation export scripts were updated to
behave properly for addons that have a non-web
part, and will merge the web translation in the
original POT file, annotating the web translations
as needed. These scripts are Unix-only and meant
to be used by OpenERP packagers when needed.
- The GetText spec says that PO auto-comments indicating
the source location have this form:
#: /path/to/file:lineno
However OpenERP's POT export system defaults to a modified
version of this format with an extra 'type' field:
#: type:/path/to/file:lineno
The babel extractors we use have the GetText format
hardcoded so a small patch is needed on the server
to make it more lenient and accept the standard
source annotation, defaulting to 'code' type.
This does not matter for openerp-web, but makes sure
the server will not fail to load the new PO files
that contain openerp-web translations with standard
annotations.
The patch for making the server more lenient was
checked in trunk at revision 4002
rev-id odo@openerp.com-20120202143210-05p1w24t6u77cyv8
- The existing translation sync and export wizards for
regular addons have not been updated to consider
web addons, so for the time being we will have
to export regular addons terms first, and run the
web export script (gen_translations.sh) on the
addons directory afterwards. This could be improved
later.
As soon as this change is merged we will have to
perform a full update of addons translation
templates in order to include the web terms as well.
bzr revid: odo@openerp.com-20120202145603-ffo0il0qnfp3r6gt
When providing values to the autocomplete, there are two keys used by
the autocomplete system itself:
* A mandatory label
* An optional value
If the value is not specified, the autocomplete will use the label
*but* it will htmlescape the label's value before setting it on the
input, while the provided label is raw HTML.
While this protects the input, if the label was already htmlescaped
(because it's user-provided data and may contain e.g. ampersands) in
order not to break the autocompletion list, it will end up
double-escaped with e.g. `&` characters replaced by `&` in
user-visible text.
The fix is to use the `value` key and set it to unescaped text data,
the widget will escape it before setting it on the field yielding the
correct user-facing result.
lp bug: https://launchpad.net/bugs/922666 fixed
bzr revid: xmo@openerp.com-20120131090226-8r64u4w3bb36se7n
dragging any other row than the first one in a sortable table (table with sequences)
has the row going way to the right of the table, in both editable list views (e.g.
tasks) and relational fields (e.g. Accounting > Configuration > Financial Accounting
> Taxes > Taxes[form] > Child Tax Accounts
bzr revid: xmo@openerp.com-20120127091938-z79e7aj6wjcmfmmz
Deferreds can't "go through" al callbacks, so even when searchviews
correctly wait on this.on_clear it can't get the information on when
the other view is done clearing, and it lauches two concurrent views.
In this precise case though, there's no need to launch a search after
this clear, just want to remove all searchview state.
bzr revid: xmo@openerp.com-20120126092304-fe79ulj6txkgy411
Olivier Dony
Launchpad Translations on behalf of openerp
Fabien Meghazi
Florent Xicluna
Xavier Morel
Antony Lesuisse
niv-openerp
Vaibhav (OpenERP)