[fpc-devel] Regionalisation (Was ThousandSeparator)

[peter green]

Hans-Peter Diettrich wrote:
> 2) Formatted numbers, as enterd by the user (maybe by copy&paste from 
> other applications), can have various encodings. Before a conversion 
> into binary values I'd remove all unexpected characters, except for 
> the last (rightmost) '.' or ',', which then becomes the decimal 
> separator as expected by the decoding function (RTL provided).
I don't see any reason why thousand seperators can't/shouldn't be to the 
right of the decimal seperator, nor any reason why a number with a 
thousand seperator also has to have a decimal seperator. So your 
algorithm would produce wrong answers in many cases.

Which brings us to the root of the problem, some numbers are simply 
ambiguous without knowing the conventions used by the people who wrote 
them. is 1,000 one or one thousand?

This isn't a problem limited to programming, when doing electronic 
design I often find myself dealing with datasheets where the authors 
have translated the text into english but have not translated the 
numbers to the english conventions. Ususally a human can make an 
educated guess based on the expected magnitude of the number but it 
still throws you at first.
>
> 3) For all other (non-GUI) purposes a unique string format is used, 
> according to the conversion functions used by the compiler. This means 
> no thousands separator, and a '.' decimal separator.
Which for an existing program means digging through your code to find 
every single decimal conversion and making the judgement call as to 
whether it's UI related or storage related and deal with the awkward 
situation that some scenarios (for example reading data from text files 
whose format is designed by others or which were written by previous 
versions of your program before you started taking this seriously) may 
require special handling or even asking the user which interpretion is 
correct.

I'm not surprised some programmers give up and tell users to set their 
systems to english mode and follow english conventions. Mainland 
europeans (which afaict are the main case which causes ambiguity) are a 
fairly significant market but losing them is probablly not a deal 
breaker for many developers
>
>
> But back to the original problem: I managed to create another user, 
> whose number format settings match the expections of the Ez-Builder, 
> while using my German keyboard. For Linux users this may sound like an 
> easy job, but adding and configuring users in Win8 turned out as kind 
> of a nightmare :-(
> Win8 requires an eMail address for every new user, but entering a fake 
> address only allows to create the account, without any chance to log 
> in subsequently. Probably the requested password has to be established 
> by mail, at least I found no way to disable or specify or reset the 
> password for the new account.
> Fortunately I had retained an Guest account, could log in and adjust 
> the format settings as prescribed, and then could successfully start 
> Ez-Builder.
>
> After all I hope that these problems are due to the cheap (Premium?) 
> version of my Win8, that is *intentionally* crippled in several ways.
 From what i've heard there is a way to create a local only user in win8 
but it's fairly hidden.

> Conclusion:
> Proper handling of separators in formatted numbers is essential, or 
> else users may run into so big trouble, that they will drop your 
> program as unusable.
The problem is proper handling is HARD.