Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

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

Open
jyrkij opened this Issue · 10 comments

9 participants

@jyrkij

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.

@ivoba

this might relate to this: #1806

@andrelohmann

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.

@andrelohmann

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.

@g4b0

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?

@andrelohmann

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?).

@tractorcow
Collaborator

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

@andrelohmann

Here is a solution #2161

will it go into the next stable 3.1.3 release?

@simonwelsh simonwelsh added the 3.1 label
@jurriaan

Unfortunately this is still an issue ..

@promotion

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

@dhensby
Collaborator

#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.