On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote:
Obviously, this is an abuse, but that's the cost of being the default. If we had C.UTF-8 as a first-class locale, this wouldn't be that much an argument, but currently d-i falls back to en_US for English for most countries.
The decision belongs to the maintainer (I'm reassigning), but per the above reasoning, I expect wontfix.
No, this is a nonsense argument. The en_US.UTF-8 locale must reflect the actual usage in the US. "Well, systems use it as a default, so we're going to overload it" would be idiotic.
There's also no reason to believe that's actually what has happened here.
C.UTF-8 *is* a first-class locale, and if any installers are using en_US.UTF-8 when they should use C.UTF-8, those installers must be fixed.
Furthermore, the only bug I'm aware of in this area is the fact that, when
no locale is configured in the environment, glibc falls back to C instead of to C.UTF-8, despite the fact that this is shipped prebuilt in the libc package and is always available.
As to the actual bug, I don't know if this represents a deliberate change or if it's accidental. Speaking for myself as an American, I can confirm the described behavior... and can say that it completely escaped my notice, because I prefer 24h time whenever given the option. Nevertheless, if this bug is to be deemed 'wontfix', it must be done solely with respect to what
is correct for the *US* locale.
Control: reassign -1 locales
On Fri, Oct 06, 2017 at 05:29:20PM -0400, debianuser2017_ wrote:
When Debian 9 is installed with the en-us locale selected, the clock defaults
to 24 hour time in the resulting install. This is odd because the normal means
of representing the time in the area covered by en-us is to separate the day
into two 12-hour segments. (localization issue)
Obviously, this is an abuse, but that's the cost of being the default. If
we had C.UTF-8 as a first-class locale, this wouldn't be that much an argument, but currently d-i falls back to en_US for English for most countries.
The decision belongs to the maintainer (I'm reassigning), but per the above reasoning, I expect wontfix.
* 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 as translations of computing terms
tend to be a horror show: for example, in Polish even such a basic term
as "file" has two versions ("zbiór" — correct, and "plik" — Microsoftese)
that are not intelligible between some groups of people. Anything more
complex gets bad enough that no one bothers translating advanced technical
documentation or running servers (rather than user-facing systems) in
pl_PL locale. And as far as I know, same applies to most languages.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 72:34:30 |
Calls: | 6,657 |
Calls today: | 3 |
Files: | 12,203 |
Messages: | 5,332,304 |
Posted today: | 1 |