openerp-expert-localization team mailing list archive

[Peter Langenberg <peter.langenberg@xxxxxxxxxxxxx>]

Hello,

I did the merge in my addons and a quick setup of a new database, but I
still have the problem, the translation is not done.

https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-lan10multi-remove-forcewrite-mat/+merge/193213

Peter



2013/10/30 Nicolas Bessi <nicolas.bessi@xxxxxxxxxxxxxx>

> 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
> --
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-localization
> Post to     : openerp-expert-localization@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-localization
> More help   : https://help.launchpad.net/ListHelp
>