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

Re: Reducing the complication of choices in console-setup udeb config: first thought



Christian Perrier, le Mon 29 Jun 2009 06:58:21 +0200, a écrit :
> My point was *not* about showing a different list to users depending
> on the language they selected.
> 
> It was just about building *one* list that would offer users all
> "reasonable" choices.

Ah. I'm still afraid that's not very scalable (you already announced
~70 choices, and I expect to see the list still growing, as there are
something like a hundred scripts in Unicode, latin being just one while
accounting for a lot of already existing keymaps...). When the default
choice is correct, that should be ok, but for borderline cases, it will
not be convenient for the user to browse it.

> > > Here is what I come with (to be completed...I stopped at Kazakh):
> > 
> > No need to do it by hand, it can be automated from xkeyboard-config's
> > data.  Any divergence from a hand-written version is just a bug in
> > xkeyboard-config.
> 
> I don't really see how such a list could be derived from
> xkeyboard-config.

With your point of view, that may be different indeed.

> What there does tell me that I need a keymap for fr_FR, another for
> fr_BE and fr_CH or fr_CA....while de_DE and de_AT are happy with the
> same one?

Thanks to the language/country tags attached to layouts and variants.
The FR layout has a fra language tag, the BE layout has ger and a fra
tags, the CH layout has ger and gsw tags, while its fr variant has a fra
tag, the CA layout has a fra tag, the DE layout has a ger tag. There
is no AT layout, but upstream will be happy to include one that just
includes the DE one (and not the CH one). Yes, it would wear a different
name than the DE one, but that's probably an opportunity to make the
name clearer for the user. Yes, thus the list would get very long, and
that's why I proposed to show several size-increasing versions.

My point is: why should Debian maintain that information while it should
already be in the xkb database?

> > > probably around 70 for i386|amd64 and much much less for
> > > arches where there is a need for a dedicated list
> > 
> > Why a dedicated list?
> 
> Because I see this as the only way to keep things simple. We would
> then have to just maintain that "selection" of "common" keymaps.

Why only the common keymaps? To mimic Franc's way of asking: aren't
people using uncommon keymaps allowed to install Debian?

I do agree that we should blacklist exotic keymaps like "my keymap with
a lot of stuff to type unicode arrows" in d-i, but there are keymaps for
a lot of languages, and you are proposing to handle additions by hand,
that's a pain.

Samuel


Reply to: