Re: Branched languagechooser
Quoting Joey Hess (joeyh@debian.org):
> I gave it a try. I really like the new language chooser, it feels clean
> and simple. I don't know whether the country codes on the left column
> (and especially the "C") will puzzle users who are not familiar with
> that convention.
This came from some threads here about "how to sort the screen". The
conclusion I had was using the ISO codes. The one who suggested this
(no more idea who it was) just mentioned that "this way, users will
have little more chance to know their own country code".
The "C" is a trick. I wanted to keep English at the top of the list,
so using the default locale convention was a good way to do this.
This may be a bit confusing as this does not trigger the "C" locale
but indeed "en" as language code and "US" as default country (before
countrychooser)
> countrychooser does not support backing up, and if I choose English, I
> get "Andorra" as a default country, which is not the best default. If I
> hit "u" for "US", it goes down one line the the UAE. I hit it again and
> it jumped all the way down to the rest of the u's. Minor outlying
> islands of the US are listed before the main country.
>
> For some reason, after choosing United States, kbd-chooser defaulted me
> to a Bulgarian keyboard. Why? Well, in the shell, debconf-get
> debian-installer/country says "UM". Not "US". I'm sure I did not pick
> the outlying islands; I went back and tried it again and still got UM.
> Probably a substring match bug.
>
> Of course I doubt that residents of the Midway Islands use Bulgarian
> keyboards either.. ;-)
There is some bad coding there, as far as I have seen while testing. I
wanted to clean this up a bit yesterday but some discussions about
timezones as wellas several contacts with translators prevented me to
do so.
> In the code: Is sourcing these countrycodemap, countrymap, programs
> really necessary? I would write these as subroutines. It would also save
> space to move the countrychooser program into the package's postinst.
No, the code is not optimal at all. The sourcing is copied from
languagechooser as well as the program being a standalone program.
Clean code is far from being my best quality, even for sheel scripts,
which are the only ones I'm really able to write.
So, making all this cleaner is really needed, but I would appreciate
if someone does it : otherwise, I would lose a lot of time trying to
do so, without real efficiency.
So, I will currently only fix the errors above....at least for today.
Reply to: