Closed Bug 799013 Opened 12 years ago Closed 12 years ago

[keyboard] enable word suggestions for keyboards and languages other than english

Categories

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

x86
macOS
defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: djf, Assigned: djf)

References

Details

(Whiteboard: [LOE:S])

Need to turn on suggestions for other latin-based languages.  Just add     suggestionEngine: 'latin' to the layout data in apps/keyboard/js/layout.js.  Right now the english layout is the only one that has it, which means that we don't offer portuguese suggestions, even though we have a portuguese dictionary.
Turns out that it takes a little more than setting suggestionEngine on the keyboard layout. We'll also have to modify the code to figure out if there is a dictionary for the user's langauge.  Currently, if there is not a dictionary (for spanish, e.g.) we offer english suggestions, which is worse than useless.

I'm going to edit the bug title so it is about language and keyboard.
Summary: [keyboard] enabled latin suggestion engine for keyboards other than english → [keyboard] enable word suggestions for keyboards and languages other than english
The current code in controller.js hardcodes en-US as a default language and always loads that dictionary first. That's a total waste for locales that are immediately going to override it.

Need to change the initialization logic to wait for the language setting before loading the dictionary.
The code is more complicated than it needs to be because it uses the SettingsListener utility, and combines the initial settings query with settings change notifications.  

What I want is to query all the settings that the keyboard needs before doing any initialization. (and also handle settings changes properly).  But there are just too many race conditions trying to set up the keyboard if we may or may not have gotten our initial settings value.

Unfortunately, mozSettings.createLock().get() still only queries one setting at a time, so to avoid serializing settings queries that should go in parallel, I'll have to write a settings utility to do what the API should do.
Whiteboard: approval-mozilla-aurora?
whoops wrong tab.
Whiteboard: approval-mozilla-aurora?
blocking-basecamp: --- → ?
Whiteboard: [LOE:S]
Spanish and Portuguese are required for the initial target markets. -> blocking+
blocking-basecamp: ? → +
Priority: -- → P1
Isn't this a dup of bug 796636?
Flags: needinfo?(dietrich)
It is a dup. Thanks for noticing.  This one is newer, but is already assigned to me and in my metabug tree, so I'm going to keep this one open and close the other
clearing the needinfo
Flags: needinfo?(dietrich)
This is fixed as part of the keyboard refactor I'm doing on a github branch.  See https://github.com/davidflanagan/gaia/tree/keyboard/apps/keyboard/js

Its not ready to land yet. I think I'll roll a number of other bug fixes into this refactor and try to get them all reviewed and landed together.
Fixed by https://github.com/mozilla-b2g/gaia/pull/6007
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reviewed and verified on "Unagi" device
Status: RESOLVED → VERIFIED
Status: VERIFIED → RESOLVED
Closed: 12 years ago12 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.