[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1026231: debian-policy: document droppage of support for legacy locales



On Fri, Jan 20, 2023 at 7:27 AM Wouter Verhelst <wouter@debian.org> wrote:
>
> On Thu, Jan 19, 2023 at 11:47:42AM +0000, Simon McVittie wrote:
> > Preferring to use Unicode does seem to be the direction that all of
> > computing is going in, as a simplifying assumption - for example W3C
> > advice for HTML is "You should always use the UTF-8 character encoding"[1]
> > - and as we know, things that aren't tested usually don't work. So I
> > think the level of functionality for non-UTF-8 locales and encodings in
> > the software we package is going to decline over time, whether Debian
> > wants it to or not.
>
> If the world's most populous country uses something that is not UTF-8, I
> think it's safe to say it's being tested, if only by people who will
> file bugs when things go awry.
>
> If the PRC government *requires* a non-UTF-8 encoding for things sold to
> them, we would be doing our users who want to sell a product containing
> Debian to the PRC government a disservice by dropping support for it
> altogether.
>
> We don't have to ensure it works perfectly out of the box; just that
> support is achievable with a reasonable amount of work.

Thank you Wouter!  That is exactly my thought, although after my
initial message, I have been told that "zh_CN.GB18030 as system
locale" may not be a strict requirement, and thus an explicit UI for
selecting zh_CN.GB18030 as system locale may not be necessary.  A
fellow Chinese DD suggested that some documentation on how to edit
/etc/locale.gen to enable zh_CN.GB18030 or other non-UTF-8 encodings
would likely be sufficient.

That said, if the testing authorities do want zh_CN.GB18030 to be
easily selectable), I think we can always sneak "zh_CN.GB18030" into
the locales configuration interface in a point release.  <grin, duck,
run>

Cheers,
Anthony


Reply to: