Server don't preserve translation on update

[Joël Grand-Guillaume @ camptocamp]

Hi,

Version : Last stable branch

As for the security access rules on object, I think that custom translation from user should be preserved on update. This is not the case actually, test it with the following procedure:

1. Take a DB with more than english languages installed

2. Translate a text on the invoice for example (I try with field description)

3. Ask to update module account and apply changes

4. Go back to look at your field : translation were restored from po file of the module !!

I think this should not append ! You must preserve user setting in that case, or at least let it choose !

I suggest here an well tested solution, and provide a patch for that :)

a) I add a new boolean field (always_update) on res_lang, allowing the user to choose if he want this languages to be updated from po file when making an update or not.

b) I change the translate.py and the module.py in order to take care on the value of this field (always_update), and respect the user choice.

c) I make this field (always_update) tick by default, so if user do nothing, it preserve the same comportment as it was before that patch.

d) I even add a check to know if the field "always_update" exists in the res_lang object, so even if you forget to make an update=all when upgrading your server with this patch, you will not have trouble and crash your server :) !

So, I ask : Could you please release this into the stable branch ? It's definitely boring to see our customers translations erased on each update...

My2Cents,

Regards,

Joël

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

(If accepted, please report it on the trunk branch too !)

[Numérigraphe (numerigraphe)]

IMHO this should not be changed on v5.0. The changelog for v5.0 could reference this as a known limitation and give the URL of this patch - this way interested people can patch their install.

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

@Numerigraphe

I agree with you on the principle... But this patch introduce no regressions and no differences in term of usability. This is totally transparent and don't change anything unless you untick the box...

Anyway, if people agree with you, I will do it in our own branch... But I think this is important and will serve everybody..

Regards,

Joël

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello all,

please read the following blueprint:
https://blueprints.launchpad.net/openobject-server/+spec/keep-custom-setting
At Akretion we have already been using a custom script for more than 6
months to handle this for migrating customers in productions.
Unfortunately we had no time to package it in a reusable manner. Now it
should be possible we can do it, before say 5.2 freeze in december,
especially if you or CampToCamp team up. It will fix this along with a few
other edge cases that currently suck when migrating.

On Tue, Oct 27, 2009 at 5:33 AM, Jay (Open ERP) <email address hidden> wrote:

> ** Changed in: openobject-server
> Importance: Undecided => Wishlist
>
> --
> Server don't preserve translation on update
> https://bugs.launchpad.net/bugs/450360
> You received this bug notification because you are subscribed to
> OpenObject Server.
>
> Status in OpenObject Server: New
>
> Bug description:
> Hi,
>
> Version : Last stable branch
>
> As for the security access rules on object, I think that custom translation
> from user should be preserved on update. This is not the case actually, test
> it with the following procedure:
>
> 1. Take a DB with more than english languages installed
>
> 2. Translate a text on the invoice for example (I try with field
> description)
>
> 3. Ask to update module account and apply changes
>
> 4. Go back to look at your field : translation were restored from po file
> of the module !!
>
> I think this should not append ! You must preserve user setting in that
> case, or at least let it choose !
>
> I suggest here an well tested solution, and provide a patch for that :)
>
> a) I add a new boolean field (always_update) on res_lang, allowing the user
> to choose if he want this languages to be updated from po file when making
> an update or not.
>
> b) I change the translate.py and the module.py in order to take care on the
> value of this field (always_update), and respect the user choice.
>
> c) I make this field (always_update) tick by default, so if user do
> nothing, it preserve the same comportment as it was before that patch.
>
> d) I even add a check to know if the field "always_update" exists in the
> res_lang object, so even if you forget to make an update=all when upgrading
> your server with this patch, you will not have trouble and crash your server
> :) !
>
> So, I ask : Could you please release this into the stable branch ? It's
> definitely boring to see our customers translations erased on each update...
>
> My2Cents,
>
> Regards,
>
> Joël
>

[Jay Vora (Serpent Consulting Services) (jayvora)]

Can you update the code and check again?

Recently translation related problems might have helped this to disappear.

Thanks.

[Nhomar - Vauxoo (nhomar)]

I try this in V5 all steps described by Joel, on records translatable and act_windows.

-- It is doesn't working.
revno: 2143 on server

I try this in V6 all steps described by Joel, on records translatable and act_windows.

-- It is doesn't working.
revno: 2888 on server-trunk

[Fabien (Open ERP) (fp-tinyerp)]

Hello,

Thank you for the patch and reporting. I couldn't use the patch, because I think most of the users will forge to tick the checkbox to not overwrite the custom translation. So, I added a checkbox in the wizard that loads a translation. By default in trunk, it does not overwrite translations.

Fix released in trunk r2891, it's better to not change the stable version because the patch requires to update the schema/views. Our policy is to only apply bugfixes in a stable branch.