translating foreign data

[Richard Damon]

On 6/23/18 5:31 PM, Ben Finney wrote:
> Richard Damon <Richard at Damon-Family.org> writes:
>
>> On 6/23/18 11:27 AM, Steven D'Aprano wrote:
>>>> On 6/23/18 9:05 AM, Marko Rauhamaa wrote:
>>>>> Richard Damon wrote:
>>>>>> Data presented to the user should normally use his locale
>>>>>> (unless he has specified something different).
>>>>> Ok. Here's a value for you:
>>>>>
>>>>>     100€
>>>>>
>>> […]
>>> 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.
>>>
>> […]
>>
>> The number CAN'T say 100 Euros (can you give me what bit pattern you
>> would use for such a number).
> That is (I believe) the point being made: The data is *not* a number. It
> is a value that must encapsulate more than only the number 100, but also
> and simultaneously the curency “Euro”.
If you have more than just a number representing a value in the locale
currency, you can't ask the locale how to present/accept it.
>
>> 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.
> The value is 100 Euro, a quantity of a particular currency and not
> something trivially converted to US$ (for many reasons, including the
> obvious one that we don't know the exact exchange rate to use, and it
> will be different at a different time).
>
> You appear to be arguing that this value must either be arbitrarily
> converted to the user's local currency, something we agree is impossible
> to do given the data, or the value is simply invalid.
>
> So the rule you assert – “Data presented to the user should normally use
> his locale” – fails to usefuly handle the very normal case of data that
> represents a quantity of some foreign currency. Any system following
> your asserted rule will give either the wrong answer, or an error. We
> had better hope the rule you assert is not in effect.
>
If the user wants to talk in Euro using software that uses locales, then
he should specify a locale that uses Euros.

If you have a field to enter a foreign currency, then you can NOT make
that a LC_CURRENCY field, or you need to make that field use a different
locale than the local locale. This isn't the fault of locales, but in a
misuse of the system.

This original question came when it was asked what do I see with 100€ in
MY locale LC_CURRENCY, well MY locale doesn't have a LC_CURRENCY that is
euros, so it can't express that. It is a bit like asking how to draw a
circle with 4 straight lines or get to the moon in a boat. It is a
question with an improper premise.

-- 
Richard Damon