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

Re: ([I18N, USABILITY] configure keyboard dialogs)

Anton Zinoviev, le Mon 15 Nov 2010 13:38:50 +0200, a écrit :
> >  +		db_set keyboard-configuration/layoutcode "$layout"
> >  +		db_fset keyboard-configuration/layout seen true
> >  +		db_set keyboard-configuration/variantcode "$variant"
> >  +		db_fset keyboard-configuration/variant seen true
> What is the point of db_setting layoutcode and variantcode here?  Won't 
> these be overwritten in step 4?

Ah, yes, of course.

> >  +			db_input high keyboard-configuration/toggle || true
> >  +			db_input medium keyboard-configuration/switch || true
> >  +		    db_input medium keyboard-configuration/altgr || true
> >  +		    db_input medium keyboard-configuration/compose || true
> These questions (or at least one of them) must be asked by d-i.  Notice 
> the high priority of the keyboard-configuration/toggle question for the 
> non-latin languages.

Well, that question was never asked before for console-data, even for
non-latin keymaps. But it's probably one of the very few candidates to
keep, indeed.

> >  +Template: keyboard-configuration/xkb-keymap
> >  +Type: select
> >  +Choices-C: us, by, be, br(abnt2), br, gb, bg(bds), ca, ca(multi), 
> >  hr, cz, dk, nl, us(dvorak), ee, fi(fi), fr(latin9), de, gr, il, hu, 
> >  is, it, jp, kg, latam, lv, lt, mk, no, pl, pt, ro, ru, rs(latin), sk, 
> >  si, es, se(basic), ch(fr), ch(de), th, tr(f), tr, ua
> This list is missing the various Indian layouts, Georgian, Hebrew, 
> Arabic, Chinese, etc.

Yes, that's on purpose: as I said in my mail, for now I just kept
the equivalents of the existing console-data layouts, so that no new
translation gets added.  The ones you mention can then be added on top
of that, but as I first step I wanted to get an exact equivalent support
as console-data.

> For Bulgarian it is imperative to add 'bg(phonetic)'.

Ah? The console-data to xkb translation code was using just us,bg, and
then append bds, that's why I used bds since that's what people are
getting in the migration path. But the fix is as simple as that, yes,
possibly adding bg(bds) as an alternative too (we can easily add the
translation by just appending the (bds) suffix to all of them.

> >   	3)
> >  -	    if \
> >  +	    if [ -f /usr/share/console-setup-mini/keyboard ]; then
> >  +		# ask simplified layout question in Debian installer
> >
> > [...]
> >
> >  +	    elif \
> >   		[ "$unsupported_layout" = yes \
> >   		-o "$default_variant" != other ]
> >   	    then
> This simplified question is going to be asked not only in d-i but also 
> by keyboard-configuration if console-setup-mini is installed

Err, no, console-setup-mini doesn't provide

> (and in general this is ok because it would help if one is able to
> test the udeb as a standalone package also).

For testing, I just touch 

> The problems: 1. the layout in /etc/default/keyboard
> will be overwritten if it is not included in the list of
> keyboard-configuratin/xkb-keymap.

Not a problem if we consider that testing is done by hand-creating the
abovementioned file, while keeping console-setup-mini's full power.

> 2. the same can happen in the udeb if the user uses preseeding.

I don't understant this.

> It would help partially to skip this question when the layout is not 
> supported (i.e. to swap the if's of the quoted code above).

That's not supposed to happen: default choices generated from the locale
should all be supported :)

> Even then the problem will remain for layouts that are supported by
> console-setup but not by the new simplified question.

That's for the installed system, where the code doesn't get run.


Reply to: