Skip to Content
Menu
This question has been flagged
2 Replies
8630 Views

I am surprised to find out that almost regardless of the language you install (unlike what happened until 6.1 and possibly 7.0) you always get the US date format and decimal separator.

Yes, it is simple to change in Settings > Languages but I feel it is a "soft" bug ... like, well, we do not have time so let the users take care of that. 

Besides, even though I have a Thousands separator (and this is regardless of the language), the separator is not shown. While I would like to see 1.000,23 I still see 1000,23 

Is this a bug or is it working as designed?

PS: I have tried with en_US, en_UK, es_ES, es_AR and nb_NO

Avatar
Discard
Best Answer

Hi Luis

It seems that Odoo takes by default the dateformat %m/%d/%Y. You can see this in misc.py under /odoo/odoo-server/openerp/tools/ (https://github.com/odoo/odoo/blob/8.0/openerp/tools/misc.py)
However this is a rather small and annoying thing I honestly find this a bug. But Odoo probably thinks otherwise about this. You can always report a bug if you'd wish, its worth the try. You can do that here: https://github.com/odoo/odoo/issues

To fix this you have two options.
1) Simply go to settings > Languages and modify it for every language
2) Create a .yml file where you automaticly install and configure the language as you'd like. I've created a lang_preferences.yml file under the module base (as this is default installed) and simply added this code:

-
  Set NL as default lang
-
  !python {model: res.lang}: |
    if self.search(cr, uid, [('code', '=', 'nl_NL')], limit=1):
      value_obj = self.pool.get('ir.values')
      ids = value_obj.search(cr, uid, [
        ('name', '=', 'lang'),
        ('key', '=', 'default'),
        ('model', '=', 'res.partner'),
      ], limit=1, context=context)
      vals = {
        'name': 'lang',
        'key': 'default',
        'key2': False,
        'model': 'res.partner',
        'object': False,
        'value_unpickle': 'nl_NL',
      }
      if ids:
        value_obj.write(cr, uid, ids, vals, context)
      else:
        value_obj.create(cr, uid, vals, context)
-
  custom date and time format.
-
  !python {model: res.lang}: |
    lang_ids = self.search(cr, uid, [('code', '=', 'nl_NL')], limit=1)
    if lang_ids:
      self.write(cr, uid, lang_ids, {
        'date_format': '%d/%m/%Y',
        'time_format': '%H:%M:%S',
      }, context)
 

This will by default install the Dutch language, set it as the active language and set the dateformat to %d/%m/%Y and will do this for every database you ever create.
NOTE: Be sure to also add the new .yml file in your __openerp__.py file or it will not be loaded/used.

As for your seperator and format, you could probably do something sortlike with the field decimal seperation mark? I'm not sure about that part so I'll leave that to somebody else to be sure.

Hope this helps you!
Yenthe

Avatar
Discard

thumb up :)

Thanks Bole! You gave me a good example to understand yml files so thanks again for that :)

and thumb up is for using it :)

Author Best Answer

Thank you, Yenthe ...

Yes, I am aware of the simple GUI change and I have done it already. I am tempted to believe the attitude was "It is so simple and we are so pressed for time that we will not do it ... let the users do it". On top of that, assuming that the US format is the standard everyone should adopt is something I would have never expected from a European company (even though I understand that the lure of the US market is almost imposssible to resist).

Having to write a specific module is an option (even cutting and pasting) but somehow that is a tad beyond the point. (On top of that I am no programmer so even cutting and pasting would not be good for me since I do not have access to the server). 

I have solved the thousands separator issue, though. Apart form choosing a separtor character (normally, a period for Europeans, but can also be a blank) you have to set the separator format which by default shows as a mere pair of square brackets ( [] ) to [3,0] and 5432,12 will read, for example, as 5.432,12 or 5 432,12.

Avatar
Discard

@Luis I agree that the current behaviour and setup isn't too great. They seem to be having some problems with dateformats, timeformats, translations & seperators anyways. There are a number of things that still aren't ideal but I'd assume they will look into this for V9? There is no official response about these things though.

Related Posts Replies Views Activity
1
Jan 25
17240
1
Jan 20
3382
1
Dec 19
5554
1
Dec 19
16596
3
Apr 18
4694