[SHR] illume predictive keyboard is too slow
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Tue Feb 3 06:34:40 CET 2009
On Mon, 02 Feb 2009 15:26:50 +0100 Helge Hafting <helge.hafting at hist.no> said:
> Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 30 Jan 2009 14:43:39 +0100 Helge Hafting <helge.hafting at hist.no>
> > said:
> >> Carsten Haitzler (The Rasterman) wrote:
> >>> On Thu, 29 Jan 2009 14:32:48 +0100 Helge Hafting <helge.hafting at hist.no>
> >>> said:
> >>>> I hope things like this will be possible, if a new dictionary format is
> >>>> realized. It is ok if typing "for" suggests "fôr" as an alternative, but
> >>>> "før" should not come up unless the user types "f" "ø" "r". In which
> >>>> case "o" must not be suggested...
> >>> ok - how do you romanise norwegian then? example. in german ö -> oe, ü ->
> >>> ue, ß -> ss, etc. - there is a set of romanisation rules that can convert
> >>> any such char to 1 or more roman letters. i was hoping to be even more
> >>> lenient with ö -> o being valid too for the lazy :) japanese has
> >>> romanisation rules - so does chinese... norwegian must (eg æ -> ae for
> >>> example).
> >> Usually, one doesn't romanize Norwegian. There are some rules: æ->ae,
> >> ø->oe, å->aa. They are next to useless, because ae and oe occur
> >> naturally in many words where æ or ø does not belong, and these double
> >> vowels are pronounced differently as well. A Norwegian seeing "oe" in a
> >> word may be able to figure out if this means "ø" or if it really is
> >> supposed to be "oe", but this may need a context of several words. And
> >> it looks funny/wrong - similar to how it looks silly transcribing "x" as
> >> "ks" and write "ksylophone".
> > oh thats not bad! then it's just like english! (you get used to the vague
> > insanity of it all sooner or later!) :)
> > but seriously - if your name is nønæn, and you move to japan, and have to
> > fill out a form for your bank account name - they will see the ø and æ and
> > go "ummm. we can't do that - can you please use normal roman text?"
> Sure, in that case, it is ø->oe, æ->ae and å->aa. (Or some will go ø->o
> and å->a because their name looks less mangled that way.) While this may
> be ok for opening a bank account in japan, it is not something ordinary
> people will want to consider for typing text messages on a phone.
> Simple phones have had æøå in the T9 system for ages. (with "æ" and "å"
> on the same key as "a", and "ø" on the same key as "o")
sure! yes. thats why i allowed for keys to be 'ø' and 'æ' etc. etc. - already
done. i was hoping to have a way of also doing it just with plain qwerty. so
there is a way of reducing it :)
> > just like my example above - but i guess i was being stricter. the stodgey
> > old banking system isn't going to go adapt like modern sports data
> > systenms. its "go roman - or go home". :)
> Sure. I just hope the freerunner doesn't evolve into a "stodgey old
> thing" as far as keyboards are considered. Looks like it doesn't, so
> I'll be fine. :-)
unlike the banking system. the users CAN have a say in fixing it... if they
just do some code :) if they just sit and wait for people to do it for them for
free - they may have to wait a while until it becomes a priority for those
doing the code. :)
> > hmm. how interesting. i have always been baffled why there is a UK qwerty
> > layout vs US - thre UK is the only place that uses it... all other english
> > speaking countries i know use US qwerty (and if UK qwerty was nicely killed
> > off.. it wouldn't need to be US qwerty - just qwerty) :)
> Surely this is because of the £-sign? (And € too, in later standards.)
> I don't think they are ready to give up the pound.
hmm no - they moved the a-z letters around. symbols i can understand. but what
play with a-z layout... beats me...
> > ok - but there is a way to do this. when stuck on your friends pc when
> > visiting them in california, and they dont have compose-modes enabled...
> > how do you type æ and ø etc. that was basically the q - there must be some
> > accepted mechanism for decimation/conversion. seemingly it's the obvious: æ
> > -> ae, ø -> o etc.
> My preferred way is to open a webpage and paste the special characters I
> need. These days, any pc seems to support æøå even if the keyboard
> itself doesn't. In a situation where æøå cannot be entered (such as the
> sms app in SHR which erroneously filter out non-ascii), I write my
> sentences very carefully avoiding these letters. For I don't want to
> spell wrong deliberately, not even transcriptions. Those that care a lot
> less about spelling use more transcriptions - and might even use
> transcriptions on a phone that has æøå, because their phone is badly
> adapted to Norwegian and have æøå in weird places. (Because the
> manufacturers aren't really into adding a couple of extra _hardware_
> keys.) Software keyboards are great!
yeah. this is one reason i want toi understand how it works without ø, æ etc. -
one day there will be a phone with a kbd.. and it wont have a version per
language because the # of users in norway are too small to warrant a special
production run for them - same for germany, france etc. etc. - until you have
the sales numbers to justify that.. you need a way to either work around it by
ignoring them - or have software correct it. so software that works eventually
with a hw kbd and inserts the right ø, æ etc. based off normal a-z typing...
would be useful.
indeed a software kbd here rules - u can adapt it for a small market of 10
people - as its really just a bit of config, not a new hardware run. but i just
wanted to know how it'd be solved when you cant modify the kbd layout in
software anymore... :) solve that in principle once with a vkbd - and you can
solve it for hw kbd's too.
> >> Excellent!
> >> So if I have a wordlist and make a keyboard, then a dictionary can be
> >> synthesized so there will be no unnecessary confusion between o and ø,
> >> because both letters exists as keys?
> > correct. as long as the dict matching doesnt drop extra info - ie normalize
> > o -> ø. currently it does. but the rest o the code doesn't. it's just the
> > dict matching engine - which as we have been discussing... needs work. :)
> The dictionary file problably need to have some metadata anyway - such
> as what language it is for. It could also have a list of what non-ascii
> letters to use as-is. And assume standard romanization rules for the rest.
i just want to understand the constraints of the languages i don't know - and
how they are used. it gives me insight into how to solve the problem on a wider
picture. thanks for the info.
so i do know now that
1. norwegian does allow for conversion to roman-only text. there are rules much
2. this conversion isn't used much and is a "last resort" thing.
3. only a few "special" letters are needed for common use cases in addition to
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the community