Automatic language → keyboard selection is broken when selecting some languages
- As discovered on
Bug #16838and Bug #15161, selecting Arabic language leads to an English (US) keyboard being selected.
- As discovered on
Bug #12547#note-5, selecting some languages (lang codes: ayc, bhb, brx, cmn, hak, hne, lij, lzh, mhr, nan, nhn, quz, sgs, shs, tcy, the, unm, wae, yue) confuses the algorithm, triggers an exception (invisibly to the user), so English (US) layout is picked by default, and then:
- one can still choose their preferred keyboard layout by hand, and it’ll be applied as expected;
- if one selects another language/region, then the previously set keyboard layout is not updated accordingly.
Related to Tails -
|Related to Tails - Bug #12598: Afghani keyboard selected in Greeter if typing fast||Confirmed||2017-05-25|
|Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements||In Progress||2018-08-31|
|Related to Tails - Bug #16481: Tails in Indonesian starts with Arabic keyboard (and rtl)||Confirmed||2019-02-22|
Has duplicate Tails -
Has duplicate Tails -
|Blocks Tails - Feature #16209: Core work: Foundations Team||Confirmed|
#5 Updated by intrigeri 2017-06-07 13:51:10
- Assignee changed from intrigeri to alant
- % Done changed from 0 to 10
- QA Check changed from Ready for QA to Info Needed
I’m open to merging something to fix this bug if it’s ready in time for the 3.0 hard freeze (currently June 9, 15:00 CEST; https://tails.boum.org/contribute/calendar/ might be updated later). But at this very late stage, for bugs whose impact is very limited like this one, I would like:
- targetted fixes only, rather than branches that mix refactoring wit bug fixes;
- to know what kind of testing has been done already on the proposed code.
- I don’t understand what’s the purpose of commit c711741e409209cb7b5010c778849a6ccbed2c1d. It looks like a mere refactoring, but the commit message suggests it adds support for something that I don’t see used anywhere, so I’m wondering.
- Do we need commit fff9214f0837e2db2aa05a1d9c9bb33f06580012 to fix this bug, or is it merely refactoring?
- What did you already test yourself?
If I don’t get answers in time, I’ll postpone to 3.1 and bertagaz can review the whole thing at once :)
#7 Updated by intrigeri 2017-06-12 15:28:27
- Assignee changed from bertagaz to alant
- QA Check changed from Ready for QA to Dev Needed
During the 3.0 manual testing session today, we noticed a similar problem: the effect is the same (it matches the title of this ticket), but the root cause is different. If you prefer I’ll move this report to a dedicated ticket.
So, here’s what happens: when selecting Arabic (Egypt), a US keyboard layout is picked.
_layouts_for_language: got 11 layouts for ar set_default: Language ar layouts: ['dz+ar', 'iq', 'ara', 'ara+buckwalter', 'ara+azerty_digits', 'ara+qwerty_digits', 'ara+digits', 'ara+mac', 'pk+ara', 'ara+azerty', 'ara+qwerty'] _layouts_for_country: got 0 layouts for EG set_default: Country EG layouts:  set_default: Intersection of language ar and country EG: set() set_default: Empty intersection of language and country, filter by country EG only:  set_default: List still empty, filter by language ar only:  set_default: List still empty, use all language ar layouts: ['dz+ar', 'iq', 'ara', 'ara+buckwalter', 'ara+azerty_digits', 'ara+qwerty_digits', 'ara+digits', 'ara+mac', 'pk+ara', 'ara+azerty', 'ara+qwerty'] _filter_layouts: Filter by variant: ['iq', 'ara'] _filter_layouts: Filter by country EG:  _filter_layouts: Filter by language ar:  set_default: Still not 1 layouts. Try again using all country EG layouts:  set_default: Using us as fallback default layout
Same problem e.g. for Arabic (Saudi Arabia), Arabic (Sudan), Arabic (Kuwait).
I’m fully aware that’s how the algorithm is supposed to work, but from a user-centric perspective, well, it doesn’t quite do the right thing :) Maybe it’s time to start using a hard-coded mapping (taken from some Linux distro’s installer?), that we can use when the clever algorithm fails. Or we can perhaps instead add another heuristic: when we find more than one candidate, but no exact match, before falling back to US we can look among candidate layouts for those whose name starts with the language name: in this case, ‘ara’ would be selected because it’s the only candidate whose name starts with ‘ar’. What do you think?
#9 Updated by bertagaz 2017-08-07 12:49:58
> This was reported only once since the 3.0 release, so at the help desk / foundations team meeting today, we deemed this ticket as low priority => dropping target version.
And as expected, this was observed during the 3.1 manual testing session. I’m adding a known issues entry for that sorry. :/
Should we target that for 3.2?
#12 Updated by georg 2017-09-28 11:25:28
This affects many (all?) people using “German” as their keyboard layout. IMHO, this is a serious bug and should be fixed rather sooner than later. People are running into this especially if setting up Tails for the first time, creating a persistent volume, and using special chars in their passphrases. The passphrase won’t work at the next boot, as the layout is different.
#13 Updated by intrigeri 2017-09-30 10:10:19
> This affects many (all?) people using “German” as their keyboard layout.
I cannot reproduce this bug when I select “Deutsch (German)” in the Greeter. I suspect you meant to comment on
Bug #12543 (that I intend to work on during the current dev cycle) instead. If I’m guessing wrong: what keyboard layout is selected in the Greeter when you choose German language?
#14 Updated by georg 2017-09-30 10:18:24
> I cannot reproduce this bug when I select “Deutsch (German)” in the Greeter. I suspect you meant to comment on
Bug #12543 (that I intend to work on during the current dev cycle) instead.
I’m able to help and debug further, if needed. (Note: I didn’t test this with 3.2, yet, but could do, if this is of any help.)
I’m not sure if I’m aware of the difference(s) between these two issues, but you’re right, maybe.
> If I’m guessing wrong: what keyboard layout is selected in the Greeter when you choose German language?
Could you elaborate? Language selected in the greeter or after login in the top panel on the right?
In the greeter “German” is choosen, in the panel it’s “en”. The later is also the one in effect. After switching again via the panel, it works finally.
#15 Updated by georg 2017-09-30 10:22:19
> I’m not sure if I’m aware of the difference(s) between these two issues, but you’re right, maybe.
After reading the descriptions again I’m pretty sure you’re right. Sorry for the noise, should have read better the first time.. Feel free to move my comments, if possible and applicable.
Note: The “sometimes” in the subject of the correct issue is misleading, at least for the cases I’m aware of: It’s happening every time.
#23 Updated by alant 2018-01-15 22:33:22
- Assignee deleted (
- QA Check changed from Dev Needed to Info Needed
> Any news on this one? Maybe for 3.6?
It’s unclear to me what should be done. This ticket has a branch proposed, then questions about it, then various other issues discussed. Do you want me to reply to https://labs.riseup.net/code/issues/12638#note-5 ?
#24 Updated by intrigeri 2018-01-16 07:37:18
- Assignee set to alant
- QA Check changed from Info Needed to Dev Needed
> It’s unclear to me what should be done. This ticket has a branch proposed, then questions about it, then various other issues discussed. Do you want me to reply to https://labs.riseup.net/code/issues/12638#note-5 ?
Yes, please address the questions raised when this branch was reviewed :)
#35 Updated by intrigeri 2019-09-29 15:35:27
Feature #16095 is done, we don’t have any three-letter language codes anymore, so we won’t be affected by this anymore.
Unfortunately, it’s not quite the case: the ticket description is outdated. Since this ticket was created, it was repurposed to cover other buggy behavior that fits in the ticket title, such as the problems reported in
Bug #16838 and Bug #15161, that were marked as duplicate.