Re: [whatwg] Input and spell check/keyboard settings

 

Hello all: 

On language detection and allowing the device to serve your needs: 

"lang" and "hreflang" work well inside the data , but -- as far as I
have tested it -- they do not interact with the OS language, neither the
browser ( not to mention keyboards or peripherals) 

I guess it was Adobe, who has this _System.capanilities.language_
implementation, a ECMAScript variane, used in software for the web.
Excellent, by the way. 

Would'nt it be nice to polyfill it ( this is, to adopt the class as a
native object for devices/browsers) to implement it, not as an applet or
plugin but as a standard for futures specs? 

Anyone here in this list from Adobe that would like to bring some light
on the matter? 

Cheers 

---

Delfi Ramirez

My digital signature [1]

+34 633 589231
 delfin@segonquart.net [2] 

twitter: delfinramirez

 IRC: segonquart Skype: segonquart [3]

http://segonquart.net [4]

http://delfiramirez.info
 [5]

On 2015-06-18 12:01, Florian Rivoal wrote: 

> On 18 Jun 2015, at 10:58, chaals@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, "Jonny Rein Eriksen" <jonnyr@opera.com>: A possible solution: If we had support for setting a standardized context attribute on the input element, the browser could keep a small database with configured settings per context. There is an attribute called "lang" that probably has what you want, if you set up the spellcheck etc to read it. The HTML code in a web page doesn't know what the context is, until you script up something to make that happen. At which point, you may as well change the lang attribute as anything else. Note that some systems auto-detect language being entered - for example both yandex.translate and MacOS do this for me, and I suspect that the future tends that way rather than trying to guess whether I should write to you in english or norwegian...

Would it make sense to add an 'auto' value to the lang attribute,
explicitly instructing the UA to try and guess what language is being
entered? Remembering what was used last time being a legitimate way to
guess, but looking at what keyboard you're using, or at the content of
what you're typing being others. UAs that don't know how to guess would
be no worse off than today, but for those that do, you'd get the
benefits that Jonny was talking about, plus any language dependent css
being applied correctly...

The mechanics of it aren't hard to polifyll, so maybe leaving it up to
author provided js is good enough, but a js implementation would have
access to less information to base its guess on. For instance, if you're
using a typical mobile on-screen keyboard, it wouldn't know which
language the keyboard is in, which provides a big clue as to what you're
typing.

Also, good language detection isn't that trivial, so any random author
would probably have a hard time pulling this off, but that's probably
not a showstopper, since nothing's stopping them form using third party
libraries or services to do the job.

 - Florian

 

Links:
------
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20delfin@segonquart.net
[3] skype:segonquart
[4] http://segonquart.net
[5] http://delfiramirez.info

Received on Thursday, 18 June 2015 11:14:26 UTC