Description of problem: In locales which default keymap does not contain non-ASCII characters, it should be prepended by US keymap. So, for example default keymap settings for russian locale should be "us,ru" and not "ru,us" like it is now. This is needed because almost everything that should be typed during installation is ASCII-only. That is like "1G" for partition sizes, user logins, user passwords, hostnames, etc... And the most annoying thing is need to switch layout before entering password in DM. I believe almost everybody who knows does this change during installation or after.
I tested every switchable 'legacy' layout I could find in kbd. Every single one has US as the 'default' and native as the 'variant' layout - when you first load them, you're typing in US, and you have to hit the switcher combo to type the 'native' characters. So that strongly indicates Alexey is correct, and our default for X should be the same: US layout first, 'native' second.
If the fix for this is sufficiently simple I'd like it if we could do it for F20 final; it'd be nice to get as much keymap stuff right as we can for F20, we're already doing a lot better than 18 and 19. And obviously, anaconda behaviour can't be fixed post-release.
One-line patch posted to anaconda-patches, but I'm not very eager to push it because I know bugzilla is full of complaints that in F18/F19 people expected to type with e.g. russian layout when they chose russian language without the need of switching layouts.
hmm, really? do you have references? obviously we want to respect what the majority of users would expect...
If one does want to type in russian layout after login without switching then he need to set ru,us in his DE and have us,ru system-wide - because otherwise he should switch to type his username and/or password.
This bug was fixed many years ago in rhpl (yeah, http://koji.fedoraproject.org/koji/buildinfo?buildID=103687), but patches was not pushed to git. So problem is still relevant. If it will be fixed, I think it will be a greate gift for Christmas:).
vpodzime: I had a look through bugzilla and could not find any bug where a native user asserted that they expect the default ordering to be native,us , but I'll keep looking through old bugs. Also marking this bug 'i18n': people who use layouts of this kind, it would be very helpful if you could provide input here, say whether you'd usually expect the first layout in the list to be your native layout or US.
Discussed in 2013-12-09 Blocker Review meeting [1]. Voted an AcceptedFreezeException. A fix will be considered past freeze, but we should double-check with more native users of affected languages that this is what they expect. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-09/
Everything began from this bug: https://bugzilla.redhat.com/show_bug.cgi?id=473056 and this patch: https://git.fedorahosted.org/cgit/rhpl.git/commit/?id=e0dbbeccc3c7d2bbc07c51e683bb1918a78ea72e Also for Russian this issue was reverted https://git.fedorahosted.org/cgit/rhpl.git/commit/?id=64a108764c746362d9afdd24b380c61c9bad3fac But then last commit has not appeared in system-config-keyboard.
+1 FE
I agree. US should be first in the list.
+1 I agree. US should be first in the list.
+1 I agree!!!
Agree with this too
I agree with Arkady L. Shane — it really will be a greate gift for Christmas and NY. +1.
+1 US must be first.
Could we please hardcode LANG=C keyboard layout as the first one on systems with several locale layouts forever? If remember correctly the issue was "fixed" few times, then revived again (patches were not applied, or dropped later). This is really annoying and should be fixed ultimately. Btw I don't know anyone who configured "ru,us" as a locale order. Not a representative sample but anyway - you asked for it.
arkady: none of that is relevant, rhpl is not used in Fedora any more. We already know the change that is needed to change this, it's just a question of doing it. This relates to xkb layouts, btw, not kbd ones.
peter: we completely changed how keyboard layouts happen in Fedora between F17 and F20...several times. that's why things appear somewhat chaotic. system-setup-keyboard doesn't exist any more, anaconda gives all xkb layouts as options and relies on localed to pick matching kbd layouts, langtable is a thing now, and in f20, we have a set of kbd layouts generated from xkb layouts. It's a lot to keep track of. But I and vpodzime know how it all works, all we need on this bug is input from users to confirm that the order ought to be us,native not native,us; we can only rely on user feedback to know which is right.
(In reply to Adam Williamson from comment #18) > arkady: none of that is relevant, rhpl is not used in Fedora any more. We > already know the change that is needed to change this, it's just a question > of doing it. This relates to xkb layouts, btw, not kbd ones. Sure I know it. I only said when this trouble has appeared as your could get more information.
Hi, I am russian-speaking, and I espose this bug. My default layout in whole system is 'us'. This is the only comfortable setting to work, especially in the setup.
+1. I am russian-speaking and I also can confirm that US layout should be the first in the list - it is the most convenient way. I also don`t know anybody who use "ru, us" order of layouts.
Received another confirmation from G+, from Jonathan Dieter: "FWIW, here in Lebanon, most of our users prefer the English interface and keyboard layout, and only switch to the Arabic layout if they're wanting to type in Arabic. Don't know if that helps at all."
Hum, just thought of a possible consequence if we change this: would you always wind up with just plain US (rather than a legacy switchable layout) as the console layout from localed, if we put US ahead of the 'native' layout in the X config anaconda writes?
(In reply to Adam Williamson from comment #24) > Hum, just thought of a possible consequence if we change this: would you > always wind up with just plain US (rather than a legacy switchable layout) > as the console layout from localed, if we put US ahead of the 'native' > layout in the X config anaconda writes? Yes, you'd do. And while that could probably be fixed, because xlayouts and vckeymap are now separate kickstart options [1] and thus can simply be set separately from the installer's GUI, I'm not sure that would work for all languages. Do all legacy switchable console keymaps work as the us keymap by default? Cause if we make the 'us' layout default in the GUI and people will use it for entering LUKS password, they'd need the same layout/keymap as the console keymap on boot.
[1] https://fedoraproject.org/wiki/Anaconda/Kickstart#keyboard
"Do all legacy switchable console keymaps work as the us keymap by default?" See comment #1. Still, given c#24 and c#25 this sounds more like F21 stuff, unfortunately :( I really wanted to try and get everything as right as possible in F20. Never mind.
The more I think about this one, the ickier it gets. We could probably make it work for cases where the user just accepts whatever layout we decide: we can configure X so the order is 'us,native' and then go 'behind the scenes' and set the console layout to 'native'. Okay. Fine. But what about cases where the user actually picks some keyboard layout configuration? Say you're Russian, but you want to install in English (I think this is quite common for techies). You might go into the Keyboard spoke and add the Russian and US English layouts, with US English first. Would we give you 'ru' layout on the console? Probably not. But we would if you installed in Russian and just accepted your layout, and the Keyboard spoke would visually appear exactly identical in the two cases! Because we'd be doing some 'secret behind the scenes' stuff in the 'default layout' case, the behaviour of the installer would no longer be easily predictable based on what the user can see in the UI. So...I'm no longer confident this is hugely easy to fix, unfortunately. We could fix it anyway and live with the inconsistency that people who manually configured a set of X layouts with US at the top would just get plain 'US' as their console layout, I guess. It's not _horrible_. But I wanted to make sure we think it through in advance...
dropping f20 fe status as f20 has shipped, adding commonbugs.
Adam, what do you think about adding some "Use as console keymap" radio button to the keyboard configuration screen? That way we could leave the decision and rewview to users. I'm thinking about a two-part keyboard configuration screen with an upper part providing keyboard layouts grouped by languages (same way we now provide locales) and a lower part serving as a "shopping cart" for layouts where users could also mark the default/console one, change order etc. Do you think that could work? CC'ing Máirín to get an expert opinion.
In technical/code terms I think it's a viable approach, I'm not sure whether Mo would think it's too scary in UI terms. It also raises the question of to what extent we allow people to shoot themselves in the foot - do we let them choose converted X layouts with no ASCII capability as the console layout? I'd say no, but that likely adds some code complexity and possibly some UI complexity.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
We've never done anything to address this AFAIK, re-opening.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
I believe langtable has data for this too so it should be easy to do. Probably Mike Fabian can confirm my memory serves me correctly?
I assume this still applies to F24 Rawhide?
(In reply to Jens Petersen from comment #36) > I believe langtable has data for this too so it should be easy to do. > Probably Mike Fabian can confirm my memory serves me correctly? Yes, langtable has data for whether a layout suports ASCII.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Don't think anyone did anything about this.
(In reply to Jens Petersen from comment #36) > I believe langtable has data for this too so it should be easy to do. > Probably Mike Fabian can confirm my memory serves me correctly? Yes, langtable has data for this. $ python3 Python 3.8.3 (default, May 29 2020, 00:00:00) [GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import langtable >>> langtable.supports_ascii('us') True >>> langtable.supports_ascii('ru') False >>> langtable.supports_ascii('de(nodeadkeys)') True >>> langtable.supports_ascii('ge(os)') False >>> >>> langtable.supports_ascii('foobar') True The last example ('foobar') shows that for keyboard not yet in the langtable data, True is returned, i.e. unknown layouts are assumed to support ASCII. Maybe I should return None in that case ... 🤔?
Somehow this bug is linked with bz1158370 and bz1626901. I guess, this could be achieved in 3/4 steps: [Step 1] change the keyboard layout ordering to "US, native"; PR https://github.com/rhinstaller/anaconda/pull/2782 [Step 2] create a list of default keyboard layouts (with the help of langtable) as explained in https://bugzilla.redhat.com/show_bug.cgi?id=1626901#c3 and prepend to keyboard layouts for newLayoutStoreSort. or, tweak the sorting (https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/ui/gui/spokes/keyboard.py#L92) a bit. So, default ones will be top in the order and rest of all shall be after a separator. Hence lesser scroll for users. for example: >>> from langtable import list_keyboards >>> list_keyboards(languageId="pt", show_weights=True) [['br', 600], ['pt', 400]] >>> list_keyboards(languageId="zh", show_weights=True) [['cn', 1000]] >>> list_keyboards(languageId="fr", show_weights=True) [['fr(oss)', 600], ['ca', 300], ['ch(fr)', 100]] >>> list_keyboards(languageId="de", show_weights=True) [['de(nodeadkeys)', 700], ['de(deadacute)', 100], ['at(nodeadkeys)', 50], ['ch', 49], ['be(oss)', 1]] say for 4 lang_id(s): pt, zh, fr, de -- (presorted - before GtkTreeIterCompareFunc) keyboard layout list would look something like: 'br' 'cn' 'fr(oss)' 'de(nodeadkeys)' ---------------- 'pt' 'ca' 'ch(fr)' 'de(deadacute)' 'at(nodeadkeys)' 'ch' 'be(oss)' Or, a rework/refactor to prepare keyboard layouts list using langtable altogether. [Step 3] UI redesign. Something on the lines of https://bugzilla.redhat.com/show_bug.cgi?id=1039185#c30 like grouping of layouts by language_id. (with the preference to the selected one) This would need further discussion on what could be the design/ui components/navigation scheme for maintaining fewer clicks and eliminating confusion. Just wanted to discuss about the approach a bit before moving to step 2.
As [Step 1] could suffice this bug; let's continue the discussion on bz1158370.
The fix has been shipped with anaconda-34.3-1 built for f34 https://koji.fedoraproject.org/koji/buildinfo?buildID=1604195.
So sorry that I only noticed this now, but I think the fix for this broke something: it broke the *console* layout configured for the installed system with the relevant languages. Check the Russian install test from 20200831.n.0 (before this change): https://openqa.fedoraproject.org/tests/652608#step/disk_guided_encrypted_postinstall/1 and the test from 20200902.n.1 (after this change): https://openqa.fedoraproject.org/tests/653618#step/disk_guided_encrypted_postinstall/1 That's plymouth handily showing us what console layout is in use during disk decryption. Before this change it was ru, which is correct. After this change it is us, which is not correct. I've known the Russian install was broken for a couple of months but never got around to figuring out why until now, sorry :(
Filed https://bugzilla.redhat.com/show_bug.cgi?id=1912609 for the new issue.
I guess we can close this bug, though, because the change requested here was definitely made. It just broke something else.