When I fill in the price of a product, if it's not an integer price, I use naturally either a "," (in France mostly) or either a "."
In OFN, in the product list, the prices are displayed with a "."
if I put a ".", trying to be consistent, when I fill in the the price of a new variant, when I clic on "save", the price is multiplied either by 10 (if one figure in front of the .) either by 100 (if 2 figures)
See images:
Before "saving":

After "saving":

Before saving (2 figures):

After saving (2 figures)

If I fill in the price with a ",", which seems contradictory to what I see, then when I save, the "," transforms in a "." correctly, without changing the price.
Before saving:

After saving:

This is really not intuitive, I was doing hotline with beta-testeurs and they were fighting to manage to fill in their prices, the system kept changing them!
Ideally, we should allow people to fill in the price either with a "," or a "."
@daniellemoorhead, @blancnic I just tested on the Austrlian staging and it seems the problem is exactly the opposite in Australia, if you fill in a price with a "." it works ok, and with a "," then it multiplies the price by 10 or 100... Indication to solve the problem I guess ;-)
Same problem in Norway btw ;-)
Ok i'm going to take a look on it
First idea, we should keep in back office the . but displays in front the price with , instead. Agree with that?
In India, we use "." to differentiate the decimal part, and "," is used in some cases to separate thousands, lakhs etc.
For e.g. "One thousand Five hundred thirty two rupees and Sixty Paisa(cents)" is denoted as "1,532.60" or "1532.60"
We don't use "," comma here for the decimal part of the currency.
Ahaha, interesting internationaliation issue ;-) I am wondering, to avoid any confusion, if we shoudn't have two fields instead of on, one before the decimal part, one after, as it happen in lots of forms, and the use of a "." or a "," to seperate decimals can be customized at the instance level in the configuration panel?
Or we can us a "vertical line", like here:
For example on my bank interface, here is how amounts appear:

So that in the backoffice there is no confusion, but anyway we need to know from the configuration if the prices should be displayed with a "." or a "," and probably also in this configuration we need to ask the instance manager to set up the way to display seperation between 000 (is it just a space, or a "," like in the Indian case?)
Ping @mkllnk for info about international :-)
You can configure spree to use . or , as the separator. In Australia, we use .. The comma is ignored, because it denotes only a visual separator as in 100,00.00, one hundred thousands. If you tell Spree to use a comma, you will be able to write 10,50 for ten Euro fifty cents. But 10.50 will then be seen as 1050.
In the Admin panel you can click on Configuration. On that page is a section Currency Settings where you can set the Currency decimal mark and the Currency thousands separator.
Does that help or did you do that already and it's still wrong?
Thanks a lot @mkllnk ! It seems that works yes, I didn't know we could configure that... I close the issue then, problem solved very easily thanks to you :-)
Hum, in fact there is still one thing not clear. People have different habits, and some people in France may put a "." instead of a "," for the decimal. In that case, I tested and it interprets the "." strangely, for example I put 4.2 as a price and it then changed it into 42.00 (displayed with a .). I think more generally it's a bit confusing that the prices are displayed with a "." in certain pages even if you fill in a "," and also when you go in the products detail it's displayed with a ",", not a "." and all that is pretty confusing for the user... I reopen the issue as I think that's to review on the internationalisation dimension. The prices should be displayed as they are filled in (ans specified in configuration) to avoid confusion. And if a price is filled in wrongly, a message error should appear (as in my case, I could not have noticed there was an error)
I think more generally it's a bit confusing that the prices are displayed with a "." in certain pages even if you fill in a ","
That is a bug. If you change the separator to comma, it should always display the comma as decimal separator. Can you tell us which pages still display the dot?
Supporting multiple separators for input sounds like a new feature to me. We should open a new issue for that. It would be interesting what newer versions of Spree do in that case.
@mkllnk in the product list, when I display all the variants, it appears with a ".", but if I clic to edit the variant it appears with a ","


Issue created for the multiple seperator #853
Hey @myriamboure and @daniellemoorhead - I am just doing some organising of spree upgrade as we're going to be moving lots of things through - yay! This issue is labelled Spree Upgrade, so two questions:
Thanks!!
@kirstenalarsen I don't think it's connected, the solution seems to have been found here: https://github.com/openfoodfoundation/openfoodnetwork/issues/853
So yes it's connected to the work done there :-)
I just don't close it to keep the example, but if you think we should close please do.
February 2016 when it was labelled was a long time ago, and it was probably labelled as such because the view was that upgrading Spree would resolve it. If as @myriamboure says it's been fixed elsewhere then it's good to close :)
It's not yet been fixed, it is being fixed at the moment, but not yet done ;-)
Hey @myriamboure @ltrls any news on this one? It's become one of our top-most priorities.
I think it's ready for stage and test here #1831 @sauloperez
I think it's ready for stage and test here #1831
Slight correction on that update - it's been tested, now we await a response to @myriamboure's question.
which question @daniellemoorhead ?
I think it's the last comment on #1831 @sauloperez
Yes @sauloperez , @ltrls is working on fixing the inventory thing and making the format update dynamic. He wi also try to integrate some "unvalid format" rules (like if there is an amount with two digit between two "." =invalid format") hopefully he will be done today so I can test tomorrow on the French staging and we can quickly push again ;-)