XPost: linux.debian.bugs.dist

On Sat, Oct 07, 2017 at 01:47:30PM -0700, Steve Langasek wrote:

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.

This is what d-i does, thus such overloading is really widespread at
present. I'm not claiming this is a good idea, merely describing status
quo. A thoughtless change would risk breaking systems that rely on times
being sortable, fitting within current field width, etc.

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.

d-i allows selecting C as locale, but that's real 7-bit C rather than
C.UTF-8. As such, it's not really usable in most contexts.

Furthermore, if your location is not UK, Ireland or a few others, d-i will default to en_US.UTF-8.

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.

I agree here, that would be the natural thing to do. I've even submitted a patch implementing this (#874160), however it hasn't been accepted as the maintainer doesn't want a divergence with upstream. Upstream glibc already
has a proposal with this change -- I've tried contacting its proposer but
did not receive an answer. I don't know glibc upstream's politics well
enough to drive it forward.

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.

You should have considering this before invading! :p


Meow.
--
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities. -- whitroth on /.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote:

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)

<snip irrelevant exposition>

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.

--
Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]

-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJZ2T1bAAoJEFaNMPMhshM9p1YP/02m83GSc7o4N+zee1kkEj/H bo91HWgblUIhiZtpBthyGQZQtzIZigkIE8Th0R8ogvEPw2LHrt7Rd2jUH6ev8Cpg yeLbqrVRZ8sYEh6UCQ4S0yU0TzkuxjiykJJBYLc4Oc8hK4jRiF5uEHMgPCLDfogu xiqKxeoK9bYv5wUZC9RkLzO0X1NWhqQj9c0k8bMNZhwF01qRLT0zrUrJRvoqDWqU BU62CMfy29z59owfZxTbcz6HFBPnEN8j3NjqW5W3cwmx6ERv5iz5DKHMQwwaa/DE QrLqQhYYWZWwIcLsBzudpQSCQ0tJETVCx6KKKyM23Qyon2gcLtz3eYMxOWhiqV39 Wmc2IufFM6/Gq0qwPynHJHDnDNc4cOoZZKPV52Op9kjyXwmocL/rw+p995uQmXjw 7XDShRmyTF/OjB0fgGmi1D0WuH646HnO3+T71oJ6plYfyjAjrMSGOzBJlJEyZiUF opkXRg3zIhEjWjMfxkrASv1dCdiotW89x4nloF3XmiRVo6WxwgWHnwezaPyA80ns Yr2HOShoe8IDUptLayRQwgHd3Fd8L33ZBlmng7VutJRQHX9xgeQtLEW2j9p60ABT STfQHvTzkFxnU0JXIqmn

XPost: linux.debian.bugs.dist

On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote:
[time formats]

* 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.

Yes, but this bug is about time formats, not about messages -- i.e.,
it's about LC_TIME, not about LC_MESSAGES. It's perfectly possible to
set LC_TIME to pl_PL, and LC_MESSAGES to en_US if that's what you want.

(same with other things, like LC_PAPER or LC_MONETARY, that would differ between those regions)

Meanwhile, I think that indeed setting LC_TIME to en_US should result in
the time format most common in the region served by that locale.

--
Could you people please use IRC like normal people?!?

-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)