FormatNumber should respect the locale settings, and what about FormatCurrency?

[NicTheQuick]

The function `FormatNumber` uses static default values for the 1000s separator and the decimal point.
Instead it would make way more sense to respect the locale settings. Here are just a few example on how that would look like with different language settings:

Code: Select all

US English    123,456.789
French        123 456,789
German        123.456,789
Hindi         1,23,456.789

As you can see there are even differences in the 1000s separations (Hindi) that can not represented with the current implementation of `FormatNumber`.

Please make it possible to format the number by a locale string like `de_DE` or something like that. And if the argument was not provided just use the settings set by the environment variables. In my case there is the environment variable `LANG=de_DE.UTF-8` and therefore numbers should be formatted like this: "123.456,789".

Since we are talking about localization it would also be nice to have a function like `FormatCurrency` which is able to set the currency symbol to the right place, depending on the currency and the localization settings.

In the past I worked a lot with the `locale` library of Pyhon3 for a few multi language projects. You can get inspiration there if you need it: https://docs.python.org/3/library/locale.html
I am sure there is also something similar available in C or some dynamic library on each operating system that can just be wrapped by a convenient Purebasic function.

[juergenkulow]

Stringgadget für Währung (und andere Einheiten)

[NicTheQuick]

Stringgadget für Währung (und andere Einheiten)

I don't want to reinvent the wheel. I just want to have the possibility to use the functionality the operating system already has.
Surely you can write a small wrapper for each operating system and put it in a module or just standalone, but I really would prefer a native Purebasic command here.

[wilbert]

The function `FormatNumber` uses static default values for the 1000s separator and the decimal point.
Instead it would make way more sense to respect the locale settings.

FormatNumber does allow you to specify what to use

Code: Select all

FormatNumber(Number.d [, NbDecimals [, DecimalPoint$ [, ThousandSeparator$]]])

Isn't that enough ?

If using locale makes more sense or not is just how you look at it.
Imagine I have two objects.
One weighs 1,234 kg and the other one 2.345 kg.
Which one is heavier ?

[NicTheQuick]

The function `FormatNumber` uses static default values for the 1000s separator and the decimal point.
Instead it would make way more sense to respect the locale settings.

FormatNumber does allow you to specify what to use

Code: Select all

FormatNumber(Number.d [, NbDecimals [, DecimalPoint$ [, ThousandSeparator$]]])

Isn't that enough ?

No, it's not enough. Why should I create my own mapping from country/language to decimal point and thousand separator if it already exists within the operating system?
If a user starts my program he/she should be able to read all the values in his/her language settings, depending on his/her environment.

[wilbert]

Why should I create my own mapping from country/language to decimal point and thousand separator if it already exists within the operating system?

I'm not saying you should and I'm not against local support but your request was to change the behavior of the current FormatNumber procedure to use the LANG environment variable as default if nothing is specified with the argument that that makes more sense.
To me that doesn't make more sense. A procedure which gives the same output on all OS and all languages is very useful.
From my point of view it would be better to leave the current procedure as it is and have an additional procedure with the word locale inside the procedure name like FormatNumberLocale .

[NicTheQuick]

From my point of view it would be better to leave the current procedure as it is and have an additional procedure with the word locale inside the procedure name like FormatNumberLocale .

That's a valid option.

The we could also add stuff like FormatCurrencyLocale and ParseNumberLocale and similar things.