Re: English locale for Europe ? en_150

[Eidur Eidsson <eidurkr@outlook.com>]

I don't want to start a spat. All we are talking about is whether to make an externally
defined locale available to users. Our personal opinions on how it should look are
irrelevant. In a perfect world, everyone would use ISO dates, and every human language
and every programming language used the same decimal separator. But this is not the
case, which is why we have locales in the first place.

The locale in question, en_150, is not fully ISO compliant and probably not meant to be.
It cannot suit everyone, but for some users, it may be close enough to what they prefer.
It is easier to change one or two variables to "C" than to set up an intricate mix of en_US,
en_GB (which oddly import from one another), and other languages.

Most users have no desire to build their own locales; they just want to select one of the
included ones and move on.

Best regards
ee

>> Well, the default values in ISO 30112 are not associated with any language, so
>> the i18n file cannot be used with locale-gen as far as I've tried.
> why not? I used a similar locale to build many national locales, incl da_DK
> for my own language - Danish, and about 60 other.
>> A regional locale is useful for those who want to quickly apply language-specific
>> features while skipping most country-specific features. There are two English
>> language CLDR locales for a region rather than a country: en_001 (world) and
>> en_150 (Europe). Most importantly, they use a point as a decimal separator,
>> which is not the case with i18n.
> The comma is the most widely used decimal separator, only a number of English speeking countries deviate,
> actually many countries use a non breaking space, which i find error prone, and I have not seen it
> used in monetary environments - banks etc.
>> They also don't display the ISO 8601 date format.
> That is in my eyes an error, iso 8601 is a standard in most countries of the world, inc Britain.
> if you speak english in a non-natively English country, iso 8601 is the most likely format
> to be well understood. Also with the y2k problem, many international organisations decided to use iso 8601
> in the future.
> keld