Decimal separator settings: were is stored?

I was tormented to look for where System Preferences stores the current setting for decimal separator character of numbers and currencies.

It would be even better to know about the existence of a shell command that returns these settings.

I founded the answer just now, but I am not sure it is correct, because System Preferences shows other settings. For example, my System Preferences shows comma instead of period (which is returned by 2nd script bellow:

-- get current numbers formatting setting:
do shell script "locale -k LC_NUMERIC"
--> decimal_point="."
-- thousands_sep=""
-- grouping="0"
-- get current decimal separator for numbers: 
do shell script "locale decimal_point" -- THIS
--> "."
-- get current thousands separator for numbers:
do shell script "locale thousands_sep"
--> "" (empty text)
-- get current grouping setting for numbers:
do shell script "locale grouping"
--> "0"

Damn it, this is starting to get annoying.

I just tried specifying the current locale ID to the do shell script command explicitly. The result is the same as in the 1st script of post #2.

set localID to do shell script "defaults read 'Apple Global Domain' AppleLocale"
--> "en_GR"

do shell script "export LANG=\"" & localID & ".UTF-8\";locale -k LC_NUMERIC"
--> decimal_point="."
-- thousands_sep=""
-- grouping="0"

But it is different from what System Preferences shows in the Advanced tab of the Language & Region panel!!! And in this tab, I have so far used only the default settings, so as not to complicate even more what is already difficult to understand.

Hi KniazidisR.

The way we used to get the user’s preferred decimal separator in the old days was some variation on any of these:

middle character of (0 as real as text)
middle character of (0.0 as text)
middle character of (0 / 2 as text)

The thousands separator would have to be inferred from the result though — ie. something which wasn’t the decimal separator.

This works for me (and has worked for years):

set localID to do shell script "defaults read 'Apple Global Domain' AppleLocale"

do shell script "LANG=" & localID & ".UTF-8 locale -k LC_NUMERIC"

my locale is nl_NL, and I get a comma for the separator, as expected.

Thank you. As I have just checked, it still works correctly today. I tried changing the setting in System Preferences and your script always returns the correct setting

Apparently, I’m too new to this site, because for the first time I meet such a way to determine the decimal separator. :smiley:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions

current application's NSLocale's currentLocale()'s decimalSeparator() as text

Thanks to everyone who answered here. @Nigel Garvey already realized which decimal separator I was asking for - it is one that the Advanced tab in the Language & Region panel of System Preferences shows. That is, user preferred decimal separator. It is used when converting text to decimal.

For example on Greece location computer with English language (“en-GR”) user preferred decimal separator (by default setting) is comma, but locale decimal separator is period. So, I can do following coercion:

return "3,14" as number --> Result: 3.14

As you can see, the text contains comma to be able to be coerced to real number which in the result contains period.

is that not what my script returns there?

Oh @Shane, I have to apologize for the sloppy check. Your script does indeed return the correct result.

I wonder why the locale shell command does not produce the same correct result for me.

Is it a different shell/environment issue? Does the locale command produce the same result for you when run in Terminal?

The same wrong result in the Terminal.

Interesting. When I run the ‘do shell’ (first item in your first post), I get the following:

[format]“decimal_point="."
thousands_sep=
grouping="0"”[/format]

But when I use the terminal, I get the following (which matches my system prefs):

[format]% locale -k LC_NUMERIC
decimal_point=“.”
thousands_sep=“,”
grouping=“3;3”[/format]

I ran the command locale - a which lists the locales known to that command.

I didn’t find “en-GR” in this list, which is the current locale on my Mac. This is (most likely) the reason why the output of the command is incorrect on my Mac, whether I use do shell script or Terminal.

@alastor933, your locale “nl_NL” is present in list of locales known to command locale. This should be the reason command locale works properly for you, but doesn’t work properly for me.

While it doesn’t change anything, I think that it might be alastor933 who is in the NL region. I am set to en-CA.

[format]LC_NUMERIC=“en_CA.UTF-8”[/format]

I think you are right. Looking at the available locales, I guess it would only work for you if you were set to el_GR. Not sure that there are any obvious ways around this.

alastor933’s script in post #5 works for me, and produces the results KniazidisR wants, if I hard-code localID as “el_GR” or one of its variants. Unlike KniazidisR’s script in post #3, it doesn’t contain the word “export” and — perhaps more importantly — doesn’t have a semicolon between the “LANG” environment setting and the “locale” command.

Yes. My form runs the command with that LANG setting.
Kniazidis’s version sets an ENV variable, and then runs a 2nd command that’s supposed to look at those settings. It seems the variable is not set in the shell that the 2nd command is running in.
Maybe any shell command will run in the default shell, unless explicitly told otherwise (i.e. by setting LANG as shown above).

Side note: in a previous discussion on this subject, Shane noted that the higher layers of the OS may know locales that the UNIX foundation does not have.

The whole point is to automatically determine the identifier of the current locale and then automatically determine the current setting for the decimal separator.

So the need to hard-code the locale to something “like this” makes me completely abandon the use of the shell’s locale command.

I will remove from my posts the confusion I expressed that this outdated command created for me.