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)
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.
Assignee | ||
Comment 1•12 years ago
|
||
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
Assignee | ||
Comment 2•12 years ago
|
||
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.
Assignee | ||
Comment 3•12 years ago
|
||
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.
Assignee | ||
Updated•12 years ago
|
Whiteboard: approval-mozilla-aurora?
Assignee | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Assignee | ||
Updated•12 years ago
|
Whiteboard: [LOE:S]
Comment 5•12 years ago
|
||
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)
Assignee | ||
Comment 7•12 years ago
|
||
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
Assignee | ||
Comment 10•12 years ago
|
||
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.
Assignee | ||
Comment 11•12 years ago
|
||
Fixed by https://github.com/mozilla-b2g/gaia/pull/6007
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•