translating foreign data

[Richard Damon]

From: Richard Damon <Richard at Damon-Family.org>

On 6/23/18 11:27 AM, Steven D'Aprano wrote:
> On Sat, 23 Jun 2018 09:42:29 -0400, Richard Damon wrote:
>
>> On 6/23/18 9:05 AM, Marko Rauhamaa wrote:
>>> Ok. Here's a value for you:
>>>
>>>     100ΓΘ¼
>>>
>>> I see '1', '0', '0', 'ΓΘ¼'. What do you see in your locale (LC_MONETARY)?
>> If I processed that on my system I would either get $100, or an error of
>> wrong currency symbol depending on the error checking.
> Then your system is so unbelievably broken that it should be nuked from
> orbit, just to be sure.
>
> The data you were given was 100 Euros. If your system is incapable of
> reading that as 100 Euros, and errors out, then at least to know that it
> is brain-damaged and useless.
>
> But if instead it silently changes the data to $100 (US dollars?
> Australian dollars? Zimbabwe dollars? the gods only know what a system
> that broken might do...) then it is not only broken but *dangerously*
> broken.
>
Locale based currency transformations are defined as a number to/from a text
string.

The number CAN'T say 100 Euros (can you give me what bit pattern you would use
for such a number).
The currency is encoded in the locale used for the conversion, so if it is
using en-US, the currency value would ALWAYS be US$ (which the general locale
format is just $). As such 100ΓΘ¼ is an invalid input to a system getting a
Locale based input for a currency if the locale is not one from a country that
uses the euro. What the input sees is '1', '0',
'0',Γ  some funny character (or maybe 2 of them). A poorly designed
input, or one being intentionally generous on input acceptance would return
100, which would be implied US Dollars. A better error checking routine would
give an error. It is IMPOSSIBLE for it to return a number that would be 100
euros. I suppose a very smart system might see that it was in a different
currency and try to convert it, but unless time reference point to use for the
currency, you are likely to get a wrong answer, but in any case, the answer
will NOT be 100 euros, but some equivalent value in Dollars.

Now, if you want to define a perhaps more general currency input routine that
tries to detect a pan-locale currency input, and returned both a value and a
currency type, that could be more useful in some contexts. But you then run
into the interesting (and difficult) problem that if you see the input of
123.456ΓΘ¼ what is that value, is it a value around a hundred euros specified
to 3 decimal places, or is it a number just over 100 thousand euros.
>
> [...]
>> Locale predates UCS-2, it was the early attempt to provide
>> internationalization to C code so even programmers who didn't think
>> about it could add the line setlocale(LC_ALL, "") and make their code
>> work at least mostly right in more places. A single global was quick and
>> simple, and since threads didn't exist, not an issue.
> Threads were first used in 1967, five years before C even existed.
>
> https://en.wikipedia.org/wiki/Thread_%28computing%29#History
>
Threads did NOT exist (at least to the Standard) in C when locales were added,
and the C language did nothing to support threading at that time. Looking back,
 it was perhaps a regrettable decision to implement locales globally the way
there were, but it is what it is.

--
Richard Damon

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)