Hi! [ Mostly trying to clarify some of my earlier comments. ]
On Fri, 2024-06-07 at 17:20:29 +0100, Simon McVittie wrote: > On Fri, 07 Jun 2024 at 14:32:14 +0200, Guillem Jover wrote: > > I'm a non-native speaker, who has been involved > > in l10n for a long time, while at the same time I've pretty much > > always run my systems with either LANG=C.UTF-8 or before that LANG=C, > > LC_CTYPE=ca_ES.UTF-8 and LC_COLLATE=ca_ES.UTF-8. > > So diagnostic messages in your non-English language are so important to > you that you ... set your locale environment variables to values that > result in you seeing diagnostic messages in English instead? I'm not > sure I understand the point you're making here :-) Ah, sorry, I see how my sentence might not be obvious to fully unpack. :) I know enough people in my locale surroundings that either do not have a good enough command of English for whom output messages by default in English would be a significant barrier to entry, or people who while having a good command of English still feel more comfortable (or just prefer) output messages to be in their native locale (to reduce mental load for example). I've set my locale to C.UTF-8 or variants (in most of my devices), in most part as a locale immersion device (so that I could improve my English skills), while at the same time I'd consider myself an exception in my locale group. My involvement in l10n has been to try to help those groups of people, in addition to help me retain some usage of my native language, and as a side effect to spot weird or wrong constructs I might make in English strings too, which tend to become obvious once you try to translate them. :) > If your point is that people-who-are-not-you place a higher value on > having diagnostic messages come out in their non-English language than > you personally do, then, yes, that's certainly a valid thing for those > people to want. More or less, the point I was trying to make was that while emitting messages by default in English would not really affect me, I still think it would be a significant problem (not just a preference) or a barrier to entry for a big enough group of people. > But I'm not sure that our current package set actually achieves that - > increasingly many of our packages overwrite the locale with "C.UTF-8" > in some layer of their build system, because they cannot guarantee that > the locale they inherit from the environment is anything reasonable (in > particular, it might be "C", which often breaks tools that want to work > with non-ASCII filenames, inputs or outputs). In the enumeration from > my earlier message, you want (1.), but increasingly, what you actually > get is (2½.) instead, and that results in neither you nor Giole getting > the results you would hope for. > > The compromise that Alexandre suggested elsewhere in the thread - > requiring the locale to be *something* UTF-8, but leaving it unspecified > exactly which UTF-8 locale, so that a French-speaking developer can ask > for fr_FR.UTF-8 and get their compiler warnings in French - seems like > something that might actually give you what you want in more cases than > the status quo does? If we mandate a UTF-8 locale, then stack layers like > debhelper's meson plugin could probably stop forcing C.UTF-8. Ideally, yes. I think the situation now is a bit better with the recent dpkg uploads, but I'll expand in the thread from Alexandre's suggestion. > > we make lots of l10n work rather pointless > > Surely only if that l10n work was done on tools that are only ever run > from package builds, and never interactively? A lot of localization is > done for end-user-facing tools (GUI, TUI or CLI) which are never relevant > during a package build anyway. > > Even for compilers and similar non-interactive development tools, if > a French-speaking developer runs gcc in the fr_FR.UTF-8 locale during > their upstream development, they'll still benefit from its warnings being > localized into French, even if they would never see those same warnings > during a Debian package build of the same software. > > (Analogous: I similarly benefit from gcc having ANSI colour highlights > in its output, even though my Debian package build logs don't have those.) Sorry, right, my comment was specifically in the context of the dpkg tooling (and surrounding scaffolding and helpers). If dpkg is always forcing output messages in English from say dpkg-buildpackage, the are going to be a set of tools that will pretty much never see any of their output in localized form. > > and if no one is running with different locales then l10n > > bugs might easily creep in > > If no one is running (their interactive sessions) with a particular > locale, why do we even support that locale? This comment was in the context where the tooling forces a specific locale, so users cannot have the chance of using it even if they want. Thanks, Guillem
