translating foreign data

[Richard Damon]

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

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

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