[5.0] Incorrect locale code in server and addons for some languages

[Miran Gombač]

DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"
web server revno: 2760
openerp server revno: 1886

Importing official translation for Slovenian language and than selecting it and browsing forms causes the web client - babel to throw unknown locale 'sl_SL' error.

Workaround:
There in fact is no sl_SL locale because on Ubuntu locales for Slovenia are defined with SI country code e.g. sl_SI. I was able to solve this by creating a link to sl_SI.dat under /usr/lib/python2.5/site-packages/Babel-0.9.4-py2.5.egg/babel/localedata/ with the name sl_SL.dat.

For Openerp to be able to use other Slovenian locale formats (date, currency....) it is necessary to create locale definition fro Slovenian with sl_SL code instead of default sl_SI. This can be achieved through creating another link this time for /usr/share/i18n/locales/sl_SI
with the name sl_SL and then regenerating locale definitions with sudo dpkg-reconfigure locales.

I am not sure how other distributions are treating locale codes for Slovenia.

Since SI is the official country code for Slovenia it would be for the best to change the locale code for Slovenia in Openerp to avoid further problems.

Take care

Miran

[Matevž Turk (matevz-turk)]

The web client explodes when using the Slovenian locale. E.g., you cannot even get through the 'Guided Tour' section of the book.
Also, the GTK Client behaves funny, as it does not understand dates, etc.
Impossible to get anything done at all.
Please use the correct locale for Slovenian: sl_SI.

[Olivier Dony (Odoo) (odo-openerp)]

Confirmed, but this is actually a server-side bug, not directly caused by the clients, even though that's were it appears.

[Olivier Dony (Odoo) (odo-openerp)]

And also affects openobject-addons where most PO files are found.

[Olivier Dony (Odoo) (odo-openerp)]

Indeed, sl_SI is the correct code for Slovenia. Obviously a very common mistake, but SL is the code for Sierra Leone, in which Slovenian is obviously not an official language ;-)

The good news is that this problem is fixed in trunk for next version, since we switched to the short codes for PO files, as required by Launchpad's Rosetta (so that's just sl.po for Slovenia)

The bad news is that changing this in stable would somewhat break existing installations (losing current translations), but not much, and not in a way worse than the current state, I must say. But still, it could require a sort of migration step. I will try to propose branches with a fix, and ask the opinion of the quality team on this.

[Olivier Dony (Odoo) (odo-openerp)]

BTW, the same problem exists for Danish language in Denmark, which should be da_DK instead of da_DA. And this is definitely not an issue with Ubuntu or babel, so I'll update the title.

[Olivier Dony (Odoo) (odo-openerp)]

Branches for addons and server stable commited.
Going to propose the merge now.

[Matjaž Godec (matjaz-godec)]

Hello, there ar 2 problems with Slovenian locales:

1. Renaming of files from sl_SL ro sl_SI and modifying bin/tools/misc.py (will attach patches)

2. Date problem. Date validation does not work for Slovenian locales. The problem is caused by the fact, that Slovenian locale has defined date as:
%d. %m. %Y
instead
%d.%m.%Y

Validation code seems not to cope with spaces in locale date defintion.
The biggest problem seems to be, that validation is done by the code of python packet:
python-egenix-mx-base
And not directly by openERP code.

From forum posts I can see that many locales have this problem.
Will post patch for quick and dirty fix for this problem in next comments.

[Matjaž Godec (matjaz-godec)]

Patch for sl_SI locale defintion to server?field.comment=Patch for sl_SI locale defintion to server

[Matjaž Godec (matjaz-godec)]

Patch for sl_SI locale defintion to addons

[Matjaž Godec (matjaz-godec)]

Patch for quick and dirty fix for date problem in Slovenian locale.
This is not proper fix, but it makes possible to test openERP with Slovenian locale.

[Matjaž Godec (matjaz-godec)]

After long hours I found real problem with date entry in gtk client.

in widget/view/form_gtk/calendar.py You limit string length:

date1 = DT.strptime(str[:10], self.format)

Which is wrong, since You donw know what the format is.

Patch is attached.

[Stephane Wirtel (OpenERP) (stephane-openerp)]

Olivier Dony (OpenERP),
Matjaž Godec,

Question, Can we check your patches and apply them for the release candidate for the next monday ?

If these patches are included, they will be in the 5.0.7 of the March 1st.

I wait for your confirmations.

Stephane

[Matjaž Godec (matjaz-godec)]

Of course.
Everything me or my comany does is open source and usabel by all :)

We are in process of translation updates, but will not be ready till
monday. But I will post them (is bzr send OK?) when ready.

 lp

On 19. 02. 2010 08:44, Stephane (Open ERP) wrote:
> Olivier Dony (OpenERP),
> Matjaž Godec,
>
> Question, Can we check your patches and apply them for the release
> candidate for the next monday ?
>
> If these patches are included, they will be in the 5.0.7 of the March
> 1st.
>
> I wait for your confirmations.
>
> Stephane
>
> ** Changed in: openobject-addons/5.0
> Milestone: None => 5.0.7
>
>

--

Matjaž Godec, CTO

Predlog! Obiscite prenovljeno spletno stran http://www.agenda.si

ODPRTA KODA IN LINUX
STORITVE : POSLOVNE RESITVE : UPRAVLJANJE IT : INFRASTRUKTURA IT : IZOBRAZEVANJE : PROGRAMSKA OPREMA

Visit our updated web page at http://www.agenda.si

OPEN SOURCE AND LINUX
SERVICES : BUSINESS SOLUTIONS : IT MANAGEMENT : IT INFRASTRUCTURE : TRAINING : SOFTWARE

[Ivan Gudym (igudym)]

Try to revert tools/misc.py to 1976
I face similar bug with ukrainian, bug come from 1977 revision

[Christophe Simonis (OpenERP) (kangol)]

branches merged

[Matjaž Godec (matjaz-godec)]

Hello,

Just checked out latest openerp-client.
Most important patch (date related) is still not included.

Please test:
export LANG=sl_SI; openerp-client
Go to any date field (e.g. Fiscal Year).
On save You still get red and empty date fields.

Im attaching proper fix again in file openerp-client.diff.gz

Problem iz in bin/widget/view/form_gtk/calendar.py, where OpenERP makes assumption of date field length, which is completly wrong since one can't know for each locale how date is represented:

- date1 = DT.strptime(str[:10], self.format)
+ date1 = DT.strptime(str, self.format)

Please, please add this fix before release 5.0.7 because without it OpenERP is useless for all who has locale date representation longer than 10 digits.