Closed Bug 1046036 Opened 10 years ago Closed 8 years ago

Can't set different auto completion language without changing keyboard layout

Categories

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Keyboard
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: hub, Unassigned)

References

Details

(Keywords: feature, foxfood)

I can't set different autocompletion language wihtout changing layout. This is quite annoying when I try to type French with my default settings. And switching to French autocompletion change to a weird "azerty" layout. Solution: 1. Offer Canadian French layout. It would be good enough, that what Android do 2. Offer to keep the current layout while changing autocompletion.
I'm running 2.0 on Flame
Filed bug 1046036 as a workaround for my specific need.
Blocks: fxos-papercuts
Summarizing from the duplicate bug 1049514 for clarity: It should be possible to lock the keyboard to one user-chosen *layout* for all Latin-script languages so that the user can pick a list of *dictionaries* to be used with the layout such that the on-keyboard language switcher switches *dictionaries* instead of switching *layouts* for Latin-script languages.
Hubert, the right resolution is indeed create a new Canadian French layout. Our keyboard/layout management is organized into 1-level and labelled as "Language (Layout)", so we can't do Qwerty *and* switch between languages. Would you like to contribute? Should we just copy English layout and change the auto correct language? What kind of additional long-press chars does French need?
Flags: needinfo?(hub)
Summary: Can't set different autocompletion language wihtout changing layout. → Canadian French layout
(I believe the alternative is explored and explained in bug 1049514 so I am changing the summary of this bug to make the action item more specific.)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #5) > Hubert, the right resolution is indeed create a new Canadian French layout. > Our keyboard/layout management is organized into 1-level and labelled as > "Language (Layout)", so we can't do Qwerty *and* switch between languages. No we need to dissociate layout and language completion. Really that what THIS bug is about. Restoring the title. > Would you like to contribute? Should we just copy English layout and change > the auto correct language? What kind of additional long-press chars does > French need? See bug 1055026 for the French Canadian keyboard. It is already in r?. But it is not to fix this. This is to work around in *in my case*. I'm sure Henri who filed bug 1049514 has different language needs. (comment #2 I really meant bug 1055026 as the workaround bug) (In reply to Henri Sivonen (:hsivonen) from comment #4) > Summarizing from the duplicate bug 1049514 for clarity: > > It should be possible to lock the keyboard to one user-chosen *layout* for > all Latin-script languages so that the user can pick a list of > *dictionaries* to be used with the layout such that the on-keyboard language > switcher switches *dictionaries* instead of switching *layouts* for > Latin-script languages. Exactly.
Flags: needinfo?(hub)
Summary: Canadian French layout → Can't set different autocompletion language wihtout changing layout.
(In reply to Hubert Figuiere [:hub] from comment #7) Make sense. Sorry about didn't realizing there is bug 1055026. In this case I will ping UX to make some judgement on what makes the most sense.
Flags: needinfo?(ofeng)
For "QWERTY + French dictionary" case, the best way is providing a new layout for each request (for example, a new Canadian French layout). For "one layout + multiple dictionaries" case, the best way is analyzing the context and use the correct dictionary automatically, but it seems hard to implement. (see here for more details: https://bugzilla.mozilla.org/show_bug.cgi?id=1049514#c5)
Flags: needinfo?(ofeng)
(In reply to Omega Feng [:Omega] [:馮於懋] (PTO until 8/22) from comment #9) > For "QWERTY + French dictionary" case, the best way is providing a new > layout for each request (for example, a new Canadian French layout). I provided a French Canadian layout. See bug 1055026. > For "one layout + multiple dictionaries" case, the best way is analyzing the > context and use the correct dictionary automatically, but it seems hard to > implement. (see here for more details: > https://bugzilla.mozilla.org/show_bug.cgi?id=1049514#c5) No. Look at what iOS is doing. And just do that. It is way simpler than you think.
Summary: Can't set different autocompletion language wihtout changing layout. → Can't set different autocompletion language wihtout changing keyboard layout.
(In reply to Omega Feng [:Omega] [:馮於懋] (PTO until 8/22) from comment #9) > For "QWERTY + French dictionary" case, the best way is providing a new > layout for each request (for example, a new Canadian French layout). I think it doesn't make sense to solve this with a new layout for each combination. It doesn't scale. There are languages that need keys that aren't on the English keyboard (my personal interest is Finnish, but geographically neighboring Swedish, Danish and Norwegian are also examples--this isn't about qwerty vs. azerty: these Nordic keyboards are all qwerty but have a different number of keys per row compared to en-US qwerty). A substantial subset of people who need a layout that facilitates the input of these languages also *routinely* input text in English. This is *not* a marginal use case. For these people (including me), it's bad for the exact position of the a-z keys to change depending on which language they write. The obvious and reasonable solution is to let these uses stick to the *layout* they need for non-English purposes and to make the language switcher switch dictionaries. Then it might as well be generalized to Latin-script languages sharing a layout without English being special UI-wise.
(In reply to Hubert Figuiere [:hub] from comment #10) > No. Look at what iOS is doing. And just do that. It is way simpler than you > think. :hub, I didn't know you were simply looking at iOS :) but I thought iOS does not scale either. To recap, we currently keep an one-to-one mapping to language-region-layout and keep the selections one-level. If one {language|region|layout} has more {locale|language|layout}, we would have to create another entry for that combination, for example, French and French (Canada) or Turkish F and Turkish Q. The iOS model is language-region/input method at first level, and layout at second, which restricts user from 1) Using two layouts for the same language-region at the same time. 2) Using any layout (some might no make sense though), for the desired language-region. If that's the two use case we don't want to fulfill, I am fine with it. Particularly for (2), I don't know if that's the liberty :hsivonen is asking for. Once I understand what is really wanted here, I can try to come up with a UI proposal to Omega, on top of bug 1029951.
Flags: needinfo?(hub)
Flags: needinfo?(hsivonen)
Summary: Can't set different autocompletion language wihtout changing keyboard layout. → Can't set different auto completion language without changing keyboard layout
We could limit what layout we can use based on the language. Not sure for example if a cyrillic locale make sense with a latin keyboard. Or Chinese (I'm not very familiar with these input methods but it is my understanding they are very different to latin). But on overall any latin script should be usable with any latin keyboard layout. So I should be able to type German, Italian, Spanish, French, English, Portuguese, Finnish, Swedish, etc. with a QWERTY layout as use by the English locale - it allows entering diacriticals. Or with the AZERTY layout used for French (France). We should be able to determine a set of heuristics that work. As it stands now, the "French Canadian" keyboard I added solve my specific issue, but I don't think it solves Henri.
Flags: needinfo?(hub)
Is there any valid use case involve (1)? Chinese IMEs, for example, are being put on the first level in iOS because using two IMEs at the same time is a valid case in for Asian languages. User enable handwriting and phonetic-based IMEs because they could write the characters or spell the characters (if the characters is hard to write, or hard to remember how to pronounce.) I wonder if there is a use case for Latin alphabet-based languages to use two layouts at the same time.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #12) > If that's the two use case we don't want to fulfill, I am fine with it. > Particularly for (2), I don't know if that's the liberty :hsivonen is asking > for. The case I want to work is using the Finnish keyboard layout for writing both Finnish and English. (Because I don't want the positions of the letters a-z to shift on the screen depending on language.) (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #14) > Is there any valid use case involve (1)? ... > I wonder if there is a use case for Latin alphabet-based languages to use > two layouts at the same time. If you write two languages so that one language is either Finnish or Swedish and the other is Danish or Norwegian, there is, especially if you have to take action toggle something anyway to toggle dictionaries.
Flags: needinfo?(hsivonen)
Wait, I am entirely confused. (In reply to Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2015-01-07) from comment #15) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #12) > > If that's the two use case we don't want to fulfill, I am fine with it. > > Particularly for (2), I don't know if that's the liberty :hsivonen is asking > > for. > > The case I want to work is using the Finnish keyboard layout for writing > both Finnish and English. (Because I don't want the positions of the letters > a-z to shift on the screen depending on language.) We don't have a Finish layout in the tree -- only the unreferenced dictionary. The Swedish (qwerty) layout refer to Swedish dictionary. All languages you referred here are using Qwerty keyboards and Qwerty only -- the position of the letters never changes. Or, you are referring to the position changes in 2nd (long press) level? We can definitely improve on that. I simply want to know if the iOS model fits your use case as well, or if it does not scale enough to cover your use case either. Please read comment 12 point (1). > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #14) > > Is there any valid use case involve (1)? > ... > > I wonder if there is a use case for Latin alphabet-based languages to use > > two layouts at the same time. > > If you write two languages so that one language is either Finnish or Swedish > and the other is Danish or Norwegian, there is, especially if you have to > take action toggle something anyway to toggle dictionaries. I was asking if it's possible for, say, a French speaker, to _enable_ both Qwerty and Qwertz for French at the same time. If there is no such use case we can simply accept (1) as a restriction.
Flags: needinfo?(hsivonen)
> I was asking if it's possible for, say, a French speaker, to _enable_ both > Qwerty and Qwertz for French at the same time. If there is no such use case > we can simply accept (1) as a restriction. French is AZERTY. On iOS you select a language, then you select the layout: Native, QWERTY, AZERTY, QWERTZ. You can't select the same language variant twice so it is always a settings with a combination of language/layout. I don't think it is useful to have more than that. The goal is to not switch layout when switching language, at least in latin scripts. Like you don't change physical keyboard: out of habit you know how to type on it. Note that typically, a French (from France) user would use the AZERTY layout to type English - albeit shouldn't be forced to.
(In reply to Hubert Figuiere [:hub] - on PTO 'til 2015 from comment #17) > French is AZERTY. Right, my mistake.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #16) > We don't have a Finish layout in the tree -- only the unreferenced > dictionary. The Swedish (qwerty) layout refer to Swedish dictionary. That we don't have a Finnish layout in the tree is a separate bug. It's trivial to fix by making a copy of the Swedish layout and changing the metadata say it's Finnish. The reason why I haven't done this myself already is that I got very demotivated after I found out that the Swedish layout already existed in the tree but wasn't being built. So I figured that at this time if I made a Finnish layout, it would be left unbuilt, too. So instead of trying to push for stuff to get built by default first, I figured I'd push for this bug first, because the reasons why things aren't getting built don't seem to block fixing this bug. > All languages you referred here are using Qwerty keyboards and Qwerty only > -- the position of the letters never changes. This is incorrect (or at least was last I checked; my Flame is in an unbootable state at the moment). Even though the languages I referred to us QWERTY, the *on-screen* positions do change compared to English (on the 1st level!), because the software keyboard tries to space the keys evenly but the Nordic languages have a different number of keys on the first and second rows compared to English. Specifically, compared to English, there is an extra key to the right of 'p' on the first row and two extra keys to the right of 'l' on the second row. This shifts the on-screen positions of 'q' through 'p' on the first row and 'a' through 'l' on the second row due to both rows getting squeezed sideways compared to English. More importantly, this makes both the first and second row have the same number of keys, so positions of second-row letters relative to first-row letters change! > I simply want to know if the iOS model fits your use case as well, or if it > does not scale enough to cover your use case either. Please read comment 12 > point (1). The use case I'm personally interested in involves using *one layout* (in my case Finnish; to be added to the codebase by trivially copying the Swedish layout and changing metadata) with *two languages* (in my case Finnish and English). I'm noting that this might not satisfy everyone else's use cases, but until someone shows up asking to be able to write Swedish and English with the Swedish layout but Norwegian with the Norwegian layout, it's probably not worth designing for that complication. But you *could* if you allowed the user to assign a layout for each language. (I.e. the user would assign the Swedish layout to Swedish and English and the Norwegian layout to Norwegian.)
Flags: needinfo?(hsivonen)
Sorry for the really late reply. (In reply to Henri Sivonen (:hsivonen) from comment #19) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #16) > > We don't have a Finish layout in the tree -- only the unreferenced > > dictionary. The Swedish (qwerty) layout refer to Swedish dictionary. > > That we don't have a Finnish layout in the tree is a separate bug. It's > trivial to fix by making a copy of the Swedish layout and changing the > metadata say it's Finnish. The reason why I haven't done this myself already > is that I got very demotivated after I found out that the Swedish layout > already existed in the tree but wasn't being built. So I figured that at > this time if I made a Finnish layout, it would be left unbuilt, too. So > instead of trying to push for stuff to get built by default first, I figured > I'd push for this bug first, because the reasons why things aren't getting > built don't seem to block fixing this bug. FWIW, I am working on bug 1128396 to get these layouts built by default. > > All languages you referred here are using Qwerty keyboards and Qwerty only > > -- the position of the letters never changes. > > This is incorrect (or at least was last I checked; my Flame is in an > unbootable state at the moment). Even though the languages I referred to us > QWERTY, the *on-screen* positions do change compared to English (on the 1st > level!), because the software keyboard tries to space the keys evenly but > the Nordic languages have a different number of keys on the first and second > rows compared to English. > > Specifically, compared to English, there is an extra key to the right of 'p' > on the first row and two extra keys to the right of 'l' on the second row. > This shifts the on-screen positions of 'q' through 'p' on the first row and > 'a' through 'l' on the second row due to both rows getting squeezed sideways > compared to English. More importantly, this makes both the first and second > row have the same number of keys, so positions of second-row letters > relative to first-row letters change! > ic. > > I simply want to know if the iOS model fits your use case as well, or if it > > does not scale enough to cover your use case either. Please read comment 12 > > point (1). > > The use case I'm personally interested in involves using *one layout* (in my > case Finnish; to be added to the codebase by trivially copying the Swedish > layout and changing metadata) with *two languages* (in my case Finnish and > English). > > I'm noting that this might not satisfy everyone else's use cases, but until > someone shows up asking to be able to write Swedish and English with the > Swedish layout but Norwegian with the Norwegian layout, it's probably not > worth designing for that complication. But you *could* if you allowed the > user to assign a layout for each language. (I.e. the user would assign the > Swedish layout to Swedish and English and the Norwegian layout to Norwegian.) The reason of the late reply is because I am having trouble understanding what you really want. Re-read your comment I will take your opinion as "No, the iOS model does not fit my use case because the we can't make sure the positions of the keys never change between Finish layout and English layout, even when they are both Qwerty-based.". In this case, I don't have a proposal for you at the moment. Let me think of any possible solution before further commenting on the bug.
There's already a lot of comments here, so sorry if this has already been stated, but I could not find it. I suggest we should simply decouple the layout from the dicts being used so that user can set exactly what he wants. And we can keep a default set of layout and dict that makes sense. That is the behavior I have on my Android device, and it's much more comfortable than the current B2G situation where everytime I need to switch languages I have to change the layout. That is not very practical.
Flags: needinfo?(firefoxos-ux-bugzilla)
Keywords: foxfood
My quick UX proposal: Let's just keep the one-to-one language-region-layout mappings. It's too complex to change that. Add a [Advanced] panel under Keyboard Settings. The [Advanced] panel will have one checkbox reads "Suggests words in the following languages in any keyboard". When the checkbox is checked, the list of applicable languages will show up. The list will consist the dictionary of language-region available. Each of the language-region will have a checkbox available. Check that box will make keyboard app do that the user wants. On the very bottom, there will be a description text reads "Install more keyboards to get more languages. You don't need to enable the installed keyboard to make the language available here.", so to suggest user to go back to the original one-to-one language-region-layout list to get the dictionary. == The technical detail will involve firing up N instances of Prediciton.js. Shouldn't be hard but might be complex. The patch will be non-trivial since it involves a management UI, but it's doable.
(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni? to queue) from comment #22) > Add a [Advanced] panel under Keyboard Settings. FWIW, we could also hide the menu item to Advanced panel and only show it when an switch in Developers menus is turned on.
Adding feature to whiteboard. Thanks for pinging the UX team!
Flags: needinfo?(firefoxos-ux-bugzilla)
Whiteboard: feature
Whoops! Should have added to Keyword.
Keywords: feature
Whiteboard: feature
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.