Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0003093Openbravo ERPA. Platformpublic2006-11-23 16:502009-05-22 19:34
user11 
iciordia 
normalminoralways
acknowledgedopen 
5
 
 
Core
No
0003093: User level locale
Currently the local is set for the system and all users have the same locale (numbering and date formats). For SaaS this is not a valid option.
ReleaseCandidate
Issue History
2008-06-16 16:33pjuvaraNote Added: 0007742
2008-06-16 16:33pjuvaraStatusnew => acknowledged
2008-06-16 16:33pjuvaraSummaryLocale information should be configurable for every user => User level locale
2008-06-16 16:33pjuvaraDescription Updated
2008-06-16 16:33pjuvaraTag Attached: ReleaseCandidate
2008-06-23 17:31pjuvaraCategoryC. Security => A. Platform (WAD, XmlEngine, SQLC)
2008-11-16 07:44pjuvaraAssigned Toiciordia => pjuvara
2009-05-22 19:34pjuvaraAssigned Topjuvara => iciordia

Notes
(0006682)
user71   
2005-06-01 00:00   
(edited on: 2008-06-12 09:43)
This bug was originally reported in SourceForge bug tracker and then migrated to Mantis.

You can see the original bug report in:
https://sourceforge.net/support/tracker.php?aid=1601831 [^]
(0003760)
user11   
2006-11-24 15:20   
(edited on: 2008-06-12 09:26)
Logged In: YES
user_id=1505407
Originator: YES

See also people having problems with data formats:

http://sourceforge.net/forum/forum.php?thread_id=1612666&forum_id=549511 [^]

Jordi,
(0007742)
pjuvara   
2008-06-16 16:33   
Hi folks,

Right now the decimal and hundred separators are hardcoded in XmlEngine.

In complex systems like operating systems we usually have:

- Locale information (also called regional settings).
- Language translations of the user interface.

Think of the following scenarios:

a) You have a central OB server with users operating from different countries (international offices). A user from the American office expects the "." as decimal separator and a user from the French office expects the ",".

b) A user may be based in Spain works with a Spanish locale but using the English translation.

There are a few approaches to fix this:

a) We use the locale settings for a region when a user logs in with its language (locale settings and translations work as a single unit).

b) We set the locale settings per server

c) We allow users to set their language and the locale that they want to work with.

I'm in favour of option C.

We should take into account the number formatting, date formatting and probably currency.

Jordi Mas
jmas@openbravo.com