In the Debian Installer, when a user selects a non-latin keyboard, we automatically add a US variant, for the user to be able to type latin stuff. For now the list of non-latin keyboards is hardcoded in our scripts, and updating it is not done automatically. The problem is that apparently that list is not exposed in a really parseable way. Could the fact that a layout has latin symbols be e.g. exposed in the xml file?
Let's discuss this a bit.. First, please define "latin". Only latin alphabet? Or at least some latin letters? Or more than 50% letters (in the main section) are latin? Or what? Actually, every layout/variant these days have "language" attribute. Would it be better to hardcode a list of languages, so every layout for these languages would automatically be considered as "latin"?
Ah, I forgot to say: currently Debian just uses the $nonlatin list from rules/base.lists.part (but not automatically). I do not know precisely what is meant by "latin". Apparently, the thing is being able to log in at gdm banner. Starting from languages would be some way, but that still needs a list. And actually that wouldn't be what we want: there could be some layouts that already provide latin letters, and for which we thus do not want to add US as second group (I shouldn't have said "variant" in my original post btw).
> Ah, I forgot to say: currently Debian just uses the $nonlatin list from > rules/base.lists.part (but not automatically). I understand (using it automatically would not be easy). > I do not know precisely what is meant by "latin". Apparently, the > thing is being able to log in at gdm banner. I never tried - are you sure one cannot use, say, Cyrillic name (or password)? > Starting from languages would be some way, but that still needs a > list. Yes, sure, it just would mean maintaining attributes on per-language basis, instead of per-layout/per-variant. It could be a bit easier - and, more important, it would guarantee that, for example, any new variant for English or French would automatically be considered as "latin". > And actually that wouldn't be what we want: there could be some > layouts that already provide latin letters, I know, that is why I asked to define "latin". Will we have some exact definition - or should we walk through the full list of layouts/variants (or, I'd still prefer languages) setting that attribute? It could be very time-consuming (and would make further maintenance problematic - for every new contribution I'd have to make that decision again and again). > and for which we thus do > not want to add US as second group (I shouldn't have said "variant" in > my original post btw). You're actually right saying "variant". The difference between layout and variant is very small - a layout is just a "default variant".
> > I do not know precisely what is meant by "latin". Apparently, the > > thing is being able to log in at gdm banner. > I never tried - are you sure one cannot use, say, Cyrillic name (or password)? adduser refuses it. > > And actually that wouldn't be what we want: there could be some > > layouts that already provide latin letters, > I know, that is why I asked to define "latin". Will we have some exact > definition - or should we walk through the full list of layouts/variants (or, > I'd still prefer languages) setting that attribute? It could be very > time-consuming (and would make further maintenance problematic - for every new > contribution I'd have to make that decision again and again). Maybe we could have a precise definition indeed: if one can not type ASCII then it'd be considered a non-latin variant. That makes it automatizable. I'll see with the Debian team what they think. > > and for which we thus do > > not want to add US as second group (I shouldn't have said "variant" in > > my original post btw). > You're actually right saying "variant". Well, more precisely I wanted to express "add a US variant as second group".
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/120.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.