Daniel Pocock writes ("Bug#900849: allowing alternative country lists on a
Debian host/installer"):
> I've been thinking about technical solutions to help the country list
> bug[1] and the following possibility came to mind:
>
> - define a virtual package with a name like "country-codes"
I have read through the "country list bug" (#872867) and my analysis
of this problem is as follows:
* The purpose of the installer's "country list" is to provide helpful
defaults for a lot of configuration settings that vary from one
place to another.
* To serve this purpose, it is not necessary or desirable for the
installer's list to contain only "countries" (whatever that might
mean). This is because:
- Different people have different views about what counts
as a country (or what the name of a country might be).
Debian is ill-equipped to resolve these questions.
- Sometimes the configuration might need to be different
for different parts of the same "country" anyway.
- Even if we had an agreed list of countries, their
official names not provide the most helpful choice for users.
* In some cases a generally-recognised country will have so many
regions that it is not sensible to provide a top-level menu entry
for them. Eg, the states of the USA. In that case a submenu
will be appropriate.
* If iso country codes are used internally, that is an implementation
detail. Where a region which ought to appear in the list does not
have an iso country code, a different technical solution should be
adopted.
* It is not desirable to try to solve this problem by providing some
kind of alternative country code list for use by custom installers.
Of course local derivatives with different installer defaults may
make sense, but Debian upstream installers should work properly for
everyone.
I conclude that:
* The description of the list should be changed from "countries" to
"regions and countries".
* An entry should be provided in this list (specifically, a region
should be broken out from any possible parent(s)) when any of the
following are true:
(i) The region wants to have different configuration or
different defaults;
(ii) Users may not recognise the parent region name(s) as
applicable to them
This also applies when the region is not strictly speaking bounded
geographically. For example, it applies when considering different
different political alignments (or, perhaps cultural, religious or
or ethnic groups) of people within a single geogrpahic region.
* If there would otherwise be a large number of entries for a
particular region or country, use of a submenu is appropriate.
* Names should be primarily chosen so that users know what entry to
pick in the menu; but it is reasonable to try to avoid giving
offence.
Some worked examples:
* Kosovo obviously needs to have its own entry.
* Taiwan and the PRC need to be different entries. The Taiwan one
should probably be labelled "Taiwan (ROC)", and the PRC one "China
(PRC)" because those will be recognised by more people and give
less offence.
* In principle, there should be an entry for Uyghurs in Xinjiang who
wish to use the region's unofficial timezone (which is more suited
to local solar time than official PRC time), and the Uyghur
language. But in practice actually selecting such an option in
one's computer configuration is likely to be very dangerous[1]
so we might be doing Uyghur users a disservice by offering them
this option. This is a difficult case.
* I think it will be necessary to have separate options in Bosnia
for the Federation of Bosnia and Herzegovina on the one hand,
and for the Republika Srpska on the other.
* Belgium needs two entries. AIUI the keyboards as well as the
languages are different.
* AIUI it would not be necessary to provide any entries for Kashmir;
the user can select India or Pakistan as appropriate.
I could be wrong about the details above.
Ian.
[1] see eg
https://www.economist.com/briefing/2018/05/31/china-has-turned-xinjiang-into-a-police-state-like-no-other
