Hi,
I have problems with selecting the decimal separator character for my numerical input fields. I am on a Swedish system that uses “,” (comma) as decimal separator but perspective automatically choose “.” (dot).
How can I change this so that the user can input values like 123,45 instead of 123.45?
I have set the “Project locale” to swedish in the perspective project properties but that does not change anything. I have also tried to set the “locale” session property to “sv-SE” but that does not help either. I am working in the designer on the server and language settings are set to Swedish. There is the same issue in designer as in the browser.
I have put a label on a test view that binds to session/props/locale and when I run that in the browser it displays “sv”.
I have also tried to add “Swedish” in the Translator manager just in case… but that does not help either.
I have Ignition version 8.1.7 installed on the server and from the documentation it seems as there were some support added for locale on numerical entry fields in version 8.1.2 but I don’t see where to set it.
Oddly, we have no special delimiters registered for the sv locale, which were brought in from the Numeral.js library (Numeral.js). I will create a ticket to add the delimiters. We do however have them defined for neighboring countries if by chance that might be an acceptable workaround.
Thanks a lot for your reply. I can try to change locale to a neighboring country for the moment. How do I know when this is resolved for the sv locale?
If you choose any language that has a comma as decimal separator, when you want to input the number, you can’t even press the comma on the keyboard (well, yes you can, but it gets ignored).
So how can I recommend Perspective to the customers, if they can’t use it in their native language… for a simple task such as inputting a number…
For users who use the Swedish locale:
What is the correct thousands separator? This thread suggests ., yet I also see online documentation for a space.
Noted.
Besides Swedish and Norwegian, are any users encountering issues with any other locales not behaving properly? It's best to fix them all at once.
Okay, thank you, @SBL_MC . Also, I do see everything I would expect in our code for the Norwegian locale; was the issue you encountered that the locale was not working at all, or was the issue that the locale was using an incorrect delimiter in some way?
Ah, right, so your issue was that the number could not be entered into the field correctly because of the comma-based decimal delimiter. That will be resolved as a separate issue (IGN-6943, for reference).
Right because the Numeric Entry Field improperly handles the comma, not understanding that it is the decimal delimiter. That will be fixed separately as part of IGN-6943.
We should have support for the sv-SE locale starting in 8.1.24, hopefully. I'll update this thread when the content is merged.
The Swedish locale [sv, sv-SE] should be included starting with tomorrow's nightly. We encountered a related bug with the LEDDisplay where this locale and other locales don't display like they should; this new bug will be resolved as part of a yet a third effort.
Hi!
I have now tested this in 8.1.25.
Now the numeric input field displays a comma as decimal separator when swedish locale is selected.
But, there is still not possible to enter a comma. The input field does not accept it.
Also found some other components that displays a dot instead of comma.
The Label is a string value (NOT numeric) run through string translations/localization. As such, it will never display numeric localization unless you perform that localization through an expression as part of the binding.
The thermometer is one of several components we're aware of which don't apply localization as expected, and will hopefully be included with the fix for the LED Display I mentioned previously (IGN-6959).
The inability to supply commas within inputs is also an issue we're aware of as part of yet another issue. This will not be resolved as part of the LED Display/Thermometer fix, but we are aware of the limitations (see posts 8 and 14 above) in not being able to use a comma as expected in numeric input fields (IGN-6943).
