The current pricing is with a . (dot). Here in the Netherlands we use , (comma) is separator. Is this option configuration-ready? I’ve searched the groovy file but didn’t find any setting for this.
Chaging the locale to “nl” should have handled this, but if not then we probably need to make a code change to use the correct locale with the number / currency formatter.
As I think I mentioned before we have an internalization / localization project we are hoping to work on this year so thank you for uncovering these issues as we will be able to add them to our scope of work. Keep them coming.
Did not change it 
Does changing it resolve the issue?
I’ve set these settings in .groovy:
openboxes.locale.custom.enabled = true
openboxes.locale.defaultLocale = ‘nl’
openboxes.locale.supportedLocales = [‘en’,‘nl’]
But I did not see any changes in the currency being changed from . (dot) to , (comma)
I changed some settings in the .gsp files. Now the output is correct but when I update an product price the storage to the database is wrong.
I think this is hardcoded in the .class files? Or is it a java config setting?
This is a display issue only. The value saved to the database should not have any grouping (,) / decimal (.) characters. It should be saved with the number unformatted. When we display the value back to the user it should be displayed in the user’s preferred locale. It seems like that might not be happening in some cases so we’ll have to look into it as part of the localization project I spoke about.
Edit: Just to clarify, saving the unformatted number to the database might include a decimal point (so 292.349 would be saved) but when we display the number to the user, that is where the grouping and decimal characters might be different. And it seems that the number formatter is using dot (.) for decimal and comma (,) for grouping regardless of the locale.
Correct me if I’m wrong, but it seems that we need to be able handle the following two cases
- Display all read-only values in the desired locale (with the preferred grouping / decimal characters)
- Handle the case where the input field includes a locale-specific formatting (e.g. comma for decimal, period for grouping). For example, input field handles “19,50” and the system saves it to the database as “19.50” but displays it back to the user as “19,50”.
I went a bit deeper into it.
If I set the price (in the pricefield) for example like: 19.50.
Then it gets stored correctly into the database and the output is with a comma, so: 19,50.
However, we input the pricing with a comma. So I assume everyone is going to do that. If I input the price like: 19,50
And then hit save it comes out as: 1.950,00
If I go over to the database I see then that it’s stored like:
I know from PHP programming that you have to replace comma before insert/update into the database. So I think we have the same issue here because MySQL only handles . (dot) not a comma. So somewhere there has to be the UPDATE into the table script where we can format_number into the correct way.
And then hit save it comes out as: 1.950,00
Yes, this is how I understand it as well. This is because 19,50 is treated as 1950.
I know from PHP programming that you have to replace comma before insert/update into the database. So I think we have the same issue here because MySQL only handles . (dot) not a comma. So somewhere there has to be the UPDATE into the table script where we can format_number into the correct way.
Just to make it clear. I don’t have time to work on this right now, but I’ll try to explain the mechanism(s) at work.
In Spring / Grails, with an issue like this we’re dealing with Grails data binding mechanism, not the database. A post request comes in from a browser, handled by spring mvc, gets delegated to the controller, controller action binds the data to domain object (Product) and then we indicate to Grails / GORM that we’re ready to persist the data. Here’s a very rudimentary looking controller action.
def update = {
// find the product
Product product = Product.get([params.id](http://params.id))
// data bind request parameters to domain
product.properties = params
// tell gorm to save the product to the database
// hibernate will generate the appropriate update statement
product.save()
redirect(action: "show", id: [params.id](http://params.id))
}
It’s likely the data binding mechanism that needs to be told to handle numbers in a special way.
Justin
Here’s a github issue for Grails that suggests that it works properly in Grails 2+.
I don’t see LocaleAwareNumberConverter was added in Grails 2.3
https://grails.github.io/grails2-doc/2.4.3/api/org/grails/databinding/converters/web/LocaleAwareNumberConverter.html
So I’m not sure how it was handled in Grails 1.3.9, but one solution you could explore would be to override whathever PropertyEditor is being used to handle decimal fields.
I don’t see any good examples of how to do that, but here’s a blog post that shows the general approach
And here is code used to register custom property editors
You could write your own property editor to handle number parsing in a locale-specific way.
Justin
Thanks for the work I will look into it! 