Bug#691666: installation-reports: please propose french bépo keyboard layout during installation
Fred, le Sun 28 Oct 2012 15:01:54 +0100, a écrit :
> Le dim. 28 oct. 2012 12:08:25 CET,
> Samuel Thibault <sthibault@debian.org> a écrit :
>
> > And it was discussed again in #630575, with the same conclusion: that
> > conflicts with the goal of simplicity & small size of the installer,
> > we don't really want to double the amount of layouts proposed in the
> > debian installer (yes, if we propose bepo, we should also propose all
> > kinds of dvorak layouts for each and every country, even the US dvorak
> > is questionable).
>
> I didn't saw this bug report.
Did you read the discussion there?
> Meanwhile, the simplicity shouldn't go against usability, no ?
See the discussion there. It is still considered that doubling the
amount of choices in an already very long list hurts more than having to
type with the layout that is used in the vast rest of one's own country.
> What I see is that such a keymap is about 2,5 kb
That's for just bépo. There is no reason why we should include
bépo but not all other dvorak layouts. You are also forgetting the
translations of the layout name, etc. etc. All that amounts to way more
than 2.5KiB.
> we can also build it
> dynamically from Xorg definitions using console-setup and xkb-data (these packages
> are already in the debian-wheezy-DI-b3-amd64-i386-netinst.iso),
That won't work for a network installation, for which you'd have to type
things before getting access to these packages.
> From my understand of debian-installer, these keyboard layouts are
> stored in the initrd.gz, isn't it ? but I didn't find exactly where).
They are, from the console-setup-pc-ekmap package, but also the
layout translations in console-setup-udeb.
> On the contrary, doing the Debian system installation without the
> correct keyboard mapping turns this operation more difficult
We have still not been convinced by that. Is there really *no* azerty
keyboard near you that you could just plug or look at? Doubling the
number of choices and adding several hundred KiBs (thus posing size
issues) just for that issue still seems too costly.
> setting the right layout after installation isn't the easiest
> task, depending on the target desktop.
That is another bug, which can be solved without impacting d-i.
> The user experience & simplicity should be prefered if possible from
> tool simplicity, isn't it ?
There's a balance to find. For now we have failed to find a really
convincing argument.
Samuel
Reply to: