Languagechooser/countrychooser design (was: Re: Definition of COUNTRY (Was: Resignation)
This is first a followup on a specific topic, which further derives in
more general design considerations. Please followup to -boot.
Quoting Steve Langasek (firstname.lastname@example.org):
> ... which is a problem, because what you really want is
> 1) Choose Brazilian Portuguese
> 2) Be presented a list of countries associated with this language (pt_BR):
> 3) Choose Other, then choose "Japan"
Yeah, I agree. But the problem here is that "Brazilian Portuguese" is
currently represented by "pt_BR" while it should be something like
"pt@brazilian" while "Classical" portuguese should be "pt" or
This one particular issue is really difficult to solve as long as
pt_BR is used for representing "Brazilian Portuguese".
Brazilian Portuguese is, according to what I've read from both
Brazilians and Portugueses, different enough from Portuguese that:
-it should be called "Brazilian"
-it should have its own ISO-639 code
> One more reason why I think the current behavior, where some
> languagechooser entries list a country and some do not, is a terrible
> inconsistent mess that needs to be fixed.
I agree. The current choice was a compromise at the time we introduced
the countrychooser/languagechooser dichotomy.
My first idea when I proposed it (which was quickly supported by
Steve) was that we needed both things:
-support all possible configurations (this means choosing all possible
es_*, en_* and others locales)
-make no "a priori" choices about which countries were mentioned and
I was quickly supported by Steve on that matter and this is how
countrychooser came in.
However, some voices objected that we indeed added one new screen (and
sometimes two) while one of the major d-i guidelines has been to
reduce the amount of user interaction involved. Petter Reinholdtsen
was among those voices (though not alone). As I deeply respect
Petter's work and give his opinion a high credit, a discussion then a
This compromise is what is now in Debian Installer.
However, we now see some more objections raised to this scheme (there
are others such as the verbosity of the presented choices).
So I think it's time we finally reconsider this and decide whether we
keep the current scheme, with its defaults....and qualities (it is now
well tested and quite solid)....or make a final move towards the
"language then area/country" scheme, including changes to the language