Hello,
AFAK we do not encounter this problem as we have automatized our
instance setup.
But the behavior you describe in your bug is effectively incorrect and
sould be fixed. Setup should not replace original terms but provide
translations for each language per account, journal etc...
Our main concern is more when we duplicate account when l10n_multilang
is installed.
Regards
Nicolas
Le Wed Oct 30 12:27:48 2013, Martin Trigaux a écrit :
Dear community and translators,
We have noticed an problematic behaviour in the l10n_multilang module. We would like to resolve it in 7.0 and wanted to warn you about the impact it could have on the translation of your multilang modules.
The goal of the l10n_multilang is to allow having custom translations for accounting data in countries with more than one official language (without getting .po files for every possible translation). This dependency is used by l10n_ch and recently by l10n_be (cf bug lp:1189865, dependency added in trunk for stability reason).
The problem is that, when installing your localisation module, the original name of the accounts are replaced by the language of the user. For instance, after installing l10n_ch with an administrator whose language is German, every account name will be in German. We overwrite the original term and users whose language is French or Italian will see the German term (as no translation German -> Italian defined). We consider this is not real multilingual support.
Our plan (fix in 7.0) is to keep the original untranslated-term (for l10n_ch and l10n_be it means having the accounts name in French) and adding translations for these terms. The name of the accounts will then change according to the user language if a translation is available.
This will have an impact only when a new chart of accounts is installed (not impacting already deployed companies).
Before integrating the change (probably in a few days), we would like to hear if some of you (especially l10n_ch users) have already encountered this issue and how you have dealt with it.
If you have suggestions, objections or fears about the impact of this change, please share it.
I have created a merge proposal that will change this behaviour if you want technical details.
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-lan10multi-remove-forcewrite-mat/+merge/193213 <https://code.launchpad.net/%7Eopenerp-dev/openobject-addons/7.0-lan10multi-remove-forcewrite-mat/+merge/193213>
Regards
--
Martin Trigaux
OpenERP Enterprise Services
OpenERP sa
Chaussée de Namur, 40
1367 Grand-Rosière
Tel: +32 81 81 37 00
http://openerp.com
--
Nicolas Bessi
Senior ERP consultant
Business Solution technical manager
Camptocamp SA
PSE A
CH-1015 Lausanne
http://openerp.camptocamp.com
Phone: +41 21 619 10 26
Office: +41 21 619 10 10
Fax: +41 21 619 10 00
--
