Default language for "model" values hardcoded as 'en_US' should be configurable

Ruud Riem-Vis wrote a detailed use-case for this misbehavior in bug #426653:
"
First create a clean database using the minimal profile using french (or another non-english language) and use all the default values.
Then add the module "product".
Now do the following (in the non-english language):
Go to "Products->Configuration->Product Categories"
Clic "New" and give the name "aa", then clic "Save".
Clic "New" and give the name "bb", then clic "Save".
Clic "Form->Duplicate" (one the top menu) and give the name "cc", then clic "Save".
Clic "Form->Duplicate" (one the top menu) and give the name "dd", then clic "Save".
Now clic on "List", you will have the product categorie "aa", "bb", "cc" and "dd".
Double clic on"aa" and clic on the flag to see the translations. You will see "aa" for the non-english language and "aa" for english.
Clic "Next" to select the next record and clic on the flag to see the translations. You will see "bb" for the non-english language and "bb" for english.
Clic "Next" to select the next record and clic on the flag to see the translations. You will see "cc" for the non-english language and "bb" for english!
Clic "Next" to select the next record and clic on the flag to see the translations. You will see "dd" for the non-english language and "cc" for english!!!

Apparently the duplicate action does not duplicate the translated version but puts the non-english value into the english entry of the duplicate.

It is also very misleading that the english translation follows the non-english original until the first "Save " action, after which it is frozen. Any modification made afterwards will not be taken into account although you haven't done any translation.

Now for each record change the name as follows "aa" becomes "aaa", "bb" becomes "bbb", "cc" becomes "ccc" and "dd" becomes "ddd". Look at the translations, only the non-english version has changed.

Now change the user language preference to english and look at the "Product Categories" list. You will see "aa", "bb", "bb" and "cc"!

This behavior is very disturbing as it all happens behind the scenes. In fact, the english names (or even the names for all installed languages) should "follow" the non-english naming as long as there is no explicit translation entered. A correct duplicate action should copy the entire record information (and not take the non-english source for the english duplicate), but the side effect in this case can be very misleading.
The worse situation occurs when you switch your language (for example to report bugs), and modify sometimes in English, sometimes in the non-English language. In that case, you get a real mess..."
Lionel

Hello Lionel and Ruud Riem-Vis,

I agree that this happens while copying object with non-english language. set as preference.

Can you please check with the applied patch and let us know ?

Thank You.

Hi sme,

I've applied the patch but if you duplicate a product category using for example French as the user language preference, the copied record will still keep the english version of the orginal and will not change when modifying the french name of the object. If you switch to English then, you will have two objects with the same name.
If you create a new object using new, the english translation is identical to the french orginal one.
If however, you remodify the french name of a new object, the english name will not be modified.

Ruud

Hello Ruud Riem-Vis,

        Whenever you copy any record, the new record will have the data same as the original. Now when you modify the french name of the object it does not automatically change the the english version. you need to change it manually.

Thank You.

Ok, but still it is not consistent that when you create a new record, that the english name will follow the french name only until the first save. It would be more logical to have the translation follow the name of the selected locale until an explicit translation is provided.

Hello,

        Please apply the updated patch attached herewith.

Thank You.

> It would be more logical to have the translation follow the name of the selected locale until an explicit translation is provided.
I agree, that would be far better IMHO.

@sme : the solution you propose could be a workaround for bug #426653 but not for this bug.
If you wish, feel free to mark bug #426653 as NOT beeing a duplicate of this one and mark it fixed.
But more generally, why impose en_US as the standard ?
My customers are French people, to them the original name is the French one. Most of them don't speak English in the first place.
The point is : they don't want an English name at all, but the system will force them to use it. If we could change that default, they wouldn't use the translations at all and all would be much much simpler.

I invalidate this bug. It's important for us to have a clean approach on being fully multi-languages. Everything must be in english and the server send translated versions to the client.

It's the same for dates, floats, ... Example: dates are stored in SQL format but the format is adapted at the client side depending on the user. For sentences, everything in the base module and fields are in english and the client send/receive translations according to the user.

Translating text string is totally different to translating dates or numbers.

This bug is not about the interface, object definition and such. Of course they have to be in English.
It's about data strings - OpenERP forces uses to manage English data and that's wrong.
Even if there were no bugs and the English strings never showed up (but believe me they do), it just makes no sense even in an multi-language setup. For example a Spanish company doing business in China does not care about English data, and don't want to have to maintain it.
It's like we had to to maintain a double accounting, both in our currency and in US Dollar, just for the sake of having a "standard" currency in the database.

You may close this bug if it's not clear enough what is wrong in OpenERP, I'll try to make a clearer point when time permits.

Lionel

Renewing this bug report, because the issue is still present, the solution does not seem complex and no workaround was offered by any supporting channel (paid or community).
I'll try to propose a patch to illustrate that OpenERP should be able to work without English.

I've just browsed the server code a bit, and of course there are places where 'en_US' must be retained as the default language because (as Fabien stated) it's the base language for reports, field names, help texts etc.
However, it seems that we could easily tweak the server to make ir_translations having type='model' refer to another language but en_US.
That would allow users to store data in the company's language without the server dispatching strings to ir_translations at all, and so it would not impose them a fake translation process.
Lionel

I made good progress to add this feature, but my branches change lots of portions and will need a lot of testing, so this won't be proposed for v6.
Lionel.

Assigning to you, Lionel, as you seem to wish to keep working on this. No guarantee that will we accept any such patch at any point though.
If anything, you must absolutely try to:
- keep it simple (KISS)
- keep international usage in mind and avoid special cases for some locales

Thanks Olivier,
My users need this feature, so I'll commit to it. I'll trying hard to KISS, and make it merge-able too.

There are 2 parts in this work :
- some existing code has to be cleaned up, so "international usage" will actually improve
- then I can implement the feature cleanly.
Maybe I can propose a cleanup/refactoring branch for merging when v6 is released?
Then I can propose a feature branch for testing and review later on.

The re-factoring effort itself is not huge but a bit subtle. The main idea is to split translations of bundled strings (fields, help...) from user-entered strings.
I think I have a clear idea of what's needed. I can file a blueprint to explain my implementation plan if you are interested.

Lionel.

One example of code cleanup is Bug #590659 - I pushed a branch and I'm still waiting for a review.
Lionel.

The following related bug is already improved in current trunk code:
https://bugs.launchpad.net/openobject-client/+bug/590659

Thanks.

Unfortunately my work on this topic has stalled, but good progress was made in v5.
I'll try to focus on v6 later on.
Contritions are welcome.

As a workaround for v5 where this bug can't be fixed, I just pushed a module to let the administrator copy all the translations from one language to English.
I'll probably push it to v6 sometime later too, I think it should work as-is in v6.

Anyone willing to review the module is weclome at https://code.launchpad.net/~numerigraphe/openobject-addons/extra-base-translation-copy/+merge/67418 .
Lionel Sausin.

We solve this [here](https://code.launchpad.net/~eoc/openobject-server/6.1-overwrite_changes_translatable_fields) with a different approach:

With the patch, all changes (calls to ``write`` method) made in no 'en_US' language will be written in 'en_US' too (in the table model). Anyway, the behavior is not activated by default, you must be activate it adding this key-value in the ``openerp-server.conf`` file:

    override_translated = True