iso_en ? That sounds smart... English for most of the world that aren't necessarily native English speakers? https://en.wikipedia.org/wiki/International_English Use ISO dates and stuff, and pick a random spelling. As a Canadian, I'm pretty sure about colour, but unclear about whether we should standardize on disc. Dates should be iso, even better if it used UTC as the timezone. This would be a default that would include US keyboard bindings (by default.) as the easiest thing to default to during installation, etc.. but perhaps I should be disqualified, being both a unix greybeard, and a recovering ntp admin.
On Thu, Feb 7, 2019 at 8:06 AM Adam Borowski <kilob...@angband.pl> wrote: > On Thu, Feb 07, 2019 at 02:55:33PM +0500, Roman Mamedov wrote: > > So for those of us (the entire world), who have been relying on this > behavior: > > > > > * en_US (.UTF-8) is used as the default English locale for all places > that > > > don't have a specific variant (and often even then). Generally, > technical > > > users use English as a system locale > > > > How do we roll-back what you have done here, and still get en_US.UTF-8 > while > > retaining the proper 24-hour time? > > > dpkg-reconfigure locales does not list "C.UTF-8" in the main "locales to > > generate" list, but does offer it on the next screen as "Default locale > for the > > system environment". After selecting it, we get: > > > > # locale > > LANG=C.UTF-8 > > LANGUAGE= > > LC_TIME="en_US.UTF-8" > > LC_ALL=en_US.UTF-8 > > > > But still: > > > > # date > > Thu 07 Feb 2019 09:53:47 AM UTC > > The root of this issue is worth raising on debian-devel: > > The en_US.UTF-8 locale has two purposes: > • a locale for a silly country with weird customs (such as time going in > four discontinuous segments during the day, writing date in a > middle-endian format, an unit being shorter on land than surveyed but > longer than that in the air, or another unit changing when measuring wet > vs dry vs slightly moist things) > • base locale for the most of the world save for a few places (UK, AU, ...) > that have their specific locale -- and often even they use en_US for > consistency reasons. > > > So I wonder what would be the best solution? I can think of: > • promoting C.UTF-8 in our user interfaces (allowing to select it in d-i, > making dpkg-reconfigure locales DTRT, making it the d-i default) > -- nice for Unix greybeards, but some users might want case-insensitive > sort, etc > • inventing a new locale "en" without a country bias > -- good in the long term but problematic a month before freeze > -- could be good to have it anyway but not use it until after buster > • ask glibc maintainers to revert the cherry-pick in #877900 for buster, > then pick a long-term solution > > > One particular regression caused by this change is sorting no longer > working: "12:01am" "1:01am" "12:01pm" "1:01pm" will be ordered wrong. > > On one hand, leftpondians may be entitled to their own locale. On the > other, let's punish the bastards for imperialism and imposing their own > settings on the rest of the world. :p > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands > ⢿⡄⠘⠷⠚⠋⠀ for Privacy. > ⠈⠳⣄⠀⠀⠀⠀ > >
