Attaching the xml and the js for hsb and dsb (both very active localizations). Jan, could you please do the 'magic' from here on? Once they're in the mockup, I will ask milupo to test.

what's the question? ;)

No question, just putting it in my queue

Hi, the dictionary for hsb seems to be excessive in size. It's 3 times as big as the English wordlist. Any clue where that comes from? For testing: 1. Grab https://raw.githubusercontent.com/mozilla-b2g/gaia/master/apps/keyboard/js/imes/latin/dictionaries/xml2dict.py and store it on your computer 2. Run python xml2dict.py hsb_wordlist.xml -o hsb.dict 3. You now have the .dict & the .js file 4. Go to http://janjongboom.com/gaia-keyboard-demo/ and select the dict & js file 5. Profit! This should make it easier for you to get feedback and play around with the layouts yourself. Let me know if all is OK and I'll make it into a PR.

Oh nevermind about the size. Misread the size of english at the moment.

That half-worked ;) I created the hsb.dict and loaded both into the demo but it - comes up with Spanish & English - does not offer hsb in the Settings list of languages I tried to longpress to see if the keyboard works, but that for some reason it has bunched all longpress letters into one 'cell' so when you select one, it enters them all at once.

Next time, can you please set ni? flag. I don't read all my bug mail. :-)

The reason the preview thing didn't work is because you're missing shortLabel in your layout files (see the JS Console). TypeError: layout.shortLabel is undefined If you add it it should be fine, can ignore the weird behavior of longpress for now. Don't know what I did wrong there :p

Ok, fixed that in both js files and uploaded the new versions. You fixed the merged longpress letters but is it possible you broke something else in the progress? When I load the files into the demo, it now shows hsb but the word prediction does not work. When I longpress the shortLabel field, it shows that I'm looking at English and Spanish. If I manually add or remove languages, it displays the shortLabel as hsb no matter what I pick (tried German and Gaelic).

It works for different autocorrect dictionaries, so something funky is going on there. Let me investigate.

So haven't found the root cause of this yet. It's a valid dictionary format and it processes most items but for some reason decides that no match is ever good enough...

I'm not sure if it will help but any chance it has something to do with line endings? I'm racking my brains about where it happened but I think we had a very hard to track down problem like that once which hinged on something stupid like Linux vs MS line endings or something.

Hello Jan, hello Michael. I tested Michael's hsb.js from comment 11 and created the hsb.dict with Python 2.7. The issue seems to be that after loading the keyboard the caps lock key is active (highlighted blue). Therefore the letter group prediction does not work. I have to deactivate the caps lock key that I can see the prediction of the keyboard layout. Default should be inactive caps lock. hsb.dict contains this text only: FxOSDICT Is that correct or shouldn't it contain the word list?

No, it should contain the serialized word list. It also does when I generate the dictionary (python3 though)...

I tested hsb and dsb again but this time with Python 3.4.1. Now the prediction is shown although it is not displayed correctly anyhow. When I press the character "ž" in the dsb keyboard, "t", "u" and "to" are shown in the prediction line, text that doesn't contain the character "ž". Only when I press a second "ž" the words appear that begin with the character "ž". For hsb it is similar: When I press ž the first time, to, tu, te are shown instead of a word that begins with "ž". And it is annoying that I have to disable the caps lock that I can use the Sorbian characters every time.

I'm temporary less available, Rudy can you look into this?

Let's submit the patches one by one, for example, here is a pull request to add hsb layout and dictionary.

(In reply to Michael Wolf from comment #19) > I tested hsb and dsb again but this time with Python 3.4.1. Now the > prediction is shown although it is not displayed correctly anyhow. When I > press the character "ž" in the dsb keyboard, "t", "u" and "to" are shown in > the prediction line, text that doesn't contain the character "ž". Only when > I press a second "ž" the words appear that begin with the character "ž". > > For hsb it is similar: When I press ž the first time, to, tu, te are shown > instead of a word that begins with "ž". > It is possible even in English, for example, you type 'y' and then one of the suggestion is 'to'. After checking hsb wordlist, to is with very high frequency, 211, and tu is 175, so this could be a reasonable explanation for the result. Could you give more examples about whether we need to tweak the algorithm for word suggestion, or we can land the layout and dictionary first and then fine-tune the dictionary or algorithm as follow-ups? > And it is annoying that I have to disable the caps lock that I can use the > Sorbian characters every time. I am not sure I understand what the problem is, can Michael Bauer help on this? --- I submitted an example pull request (pr) as an attachment, please help create your own pr if you need to modify anything.

I think we should land first. It might just be that in the live system it actually works ok and that we're just getting messed around by something buggy in the test systems.

(In reply to Rudy Lu [:rudyl] from comment #22) > > And it is annoying that I have to disable the caps lock that I can use the > > Sorbian characters every time. > I am not sure I understand what the problem is, can Michael Bauer help on > this? Hi Rudy, sorry that I respond to the overdue messages so late. I mean that - starting the demo keyboard - the caps lock key of the demo keyboard is activated (blue highlightened). I have to deactivate it that I can use the Upper Sorbian resp. Lower Sorbian keyboard.

Closing this, as OS is no longer in development