AnsweredAssumed Answered

Proper handling of decimal dot/comma, independent of regional settings?

Question asked by Roger Palmen on Dec 18, 2018

Hi All,

Recently ran into a localization issue in AF (tested in 2018)

 

  • The setup: i have a table that contains values in string attributes. These are imported from an external source, and therefore i can't do any conversions on that data, and need to take in these values as-is. As-is, in this case being using a decimal dot as the data is from a global source for a US-based company.
  • The problem: Now i run a client PSE session using Dutch regional settings, and thus using a decimal comma. As a result the decimal dot is interpreted as a thousands-separator symbol, and hence my values are off by powers of 10.

My application in AF is accessed from various places around the world, and thus various locale settings.

 

Example:

  • Create a table with a string column "Name" and a string column "Value"
  • Create two rows: Name=Dot; Value=123.456 and Name=Comma; Value=123,456
  • Create two table lookup attributes, reading the value from the table
  • Result when using US locale: comma=123456; dot=123.456
  • Result in PSE when using Dutch locale: comma=123,456; dot=123456

 

What are your ideas to mitigate this?

The best true solution i can think of is being able to set the locale to apply to a column in the table definition, in the same way that you currently can specify the timezone.

The best workaround i can think of is some trickery with the string builder to determine the current locale decimal separator and thousands separator (aka grouping symbol), and use that to transcode the strings into strings matching the current locale, before converting to a number. Yes, that looks horrific...

Outcomes