Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Currency fails validating and/or saving if locale != en_US #2050

jyrkij opened this Issue · 10 comments

9 participants


Or at least it seems to be so. Haven't tested any other locales than fi_FI and en_US.
The test case is a DataObject with Price => Currency field.
Branch is 3.1.

  1. Start with a new installation with fi_FI locale or set Interface Language to fi_FI.
  2. Try setting the Price with Finnish format (1234,56). It'll validate but the resulting Price is empty.
  3. Setting the field to 1234.56 fails validating. It's not valid Finnish format.
  4. Setting the field to 1234 (without any decimals) will validate & save correctly. But the rendering of the field is 1234.56!

Setting the locales/languages to en_US makes field validate & save with value 1234.56.


this might relate to this: #1806


Hi, it is the same for de_DE Price Values. When setting the Backend to en_US, I'm able to enter the value by 10.90 but when setting the backend to de_DE, entering 10.90 will not validate, as it is no german format, 10,90 validates, but results in an empty value too.

I only checked that on a DataObject/ModelAdmin combnation in the Backend. Don't know if it is the same for the frontend.


CHecked again, this Issue exists on all floating point Attributes (Currency, Decimal, Float).
Each time the Backend Language is set to a language that is using the comma for the decimal point, the input fields within ModelAdmin react with the described error.


This behavior is really strange, I can't find any setlocale call in CMS code. @chillu where we can have a look for trying solve this issue?


Hi again, is anyone working on this, or can anyone give a hint, on where this might could be fixed? I tried to locate the Problem within the formfields and fieldtypes, but without any success. I'd really appreciate, if I can help here, but I need some Information on where to start (is there simply some coding missing?).


Also there is some further locale issues noted at #2606. See my comment on #1806 (comment)


Here is a solution #2161

will it go into the next stable 3.1.3 release?

@simonwelsh simonwelsh added the 3.1 label

Unfortunately this is still an issue ..


And it is still an issue on 3.1.8 with ru_RU locale :(


#3008 almost certainly fixes this issue as it has tests that appear to me to test the issue reported here.

#2161 appears to be a duplicate of this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.