Re: [whatwg] Input and spell check/keyboard settings
Florian Rivoal wrote: If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. The principle of least surprise argues against this. Most mobile phones support many more languages and keyboard layouts than their users know how to use. Users typically configure layouts for which they have a use, and they learn how to use then and switch between them. Desktop operating systems include optional keyboard shortcuts for switching languages. Most mobile devices include a globe or the ability to press and hold the space bar to switch. Some keyboards support multilingual input. Some are even smart enough to perform spell checking against multiple languages. But if I've only configured Hebrew and English and a web page has an input with lang=ru or manages to specify an IME which is totally foreign to me, I'm going to panic. (For the prototypical user anyway, I'm odd in that I've probably used the input method before.) Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). On multi user desktops, the existence of IME support doesn't indicate that all users of the computer are remotely comfortable with each IME. Not sure if any spec change is needed for that. Keyboard layout and IME should be opaque to browser content, so this sort of thing should be something where browser vendors are free to experiment and discover that it's just not worth it (because language tagging is wrong more often than it's right).
Re: [whatwg] Input and spell check/keyboard settings
On 24 Jun 2015, at 13:07, timeless timel...@gmail.com wrote: Florian Rivoal wrote: If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. The principle of least surprise argues against this. Most mobile phones support many more languages and keyboard layouts than their users know how to use. Users typically configure layouts for which they have a use, and they learn how to use then and switch between them. I meant you would only be switched between the ones the user has activated and can manually switch between. Desktop operating systems include optional keyboard shortcuts for switching languages. Most mobile devices include a globe or the ability to press and hold the space bar to switch. Some keyboards support multilingual input. Some are even smart enough to perform spell checking against multiple languages. But if I've only configured Hebrew and English and a web page has an input with lang=ru or manages to specify an IME which is totally foreign to me, I'm going to panic. (For the prototypical user anyway, I'm odd in that I've probably used the input method before.) In my case, it's French, English, Japanese and Chinese. I wouldn't be too happy to see a Russian keyboard pop up either. But there is a set of keyboards I'm happy to use and would prefer to have the most appropriate one shown. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). On multi user desktops, the existence of IME support doesn't indicate that all users of the computer are remotely comfortable with each IME. In theory, you're right, but in practice, IME only tent to be installed/activated on computers of countries where needing one is normal. There can certainly be some that don't fix expectations, but that's the exception rather than the norm. Not sure if any spec change is needed for that. Keyboard layout and IME should be opaque to browser content, so this sort of thing should be something where browser vendors are free to experiment and discover that it's just not worth it (because language tagging is wrong more often than it's right). Chicken and egg. Language tagging is often wrong because the consequences of getting it wrong are limited. The more it is used, the more important it will be to get right, and so authors would pay more attention. I don't think that we need to do much more than point out that the UA should display the most appropriate input system given the information it has about the content and the user's expectation. It could be reasonable to spec that if the user explicitely sets the language of the spell checker, or of the virtual keyboard, or similar, then the UA should update the lang attribute of the focused element accordingly. - Florian
Re: [whatwg] Input and spell check/keyboard settings
On 18 Jun 2015, at 13:07, Jonny Rein Eriksen jon...@opera.com wrote: On 18.06.2015 12:01, Florian Rivoal wrote: 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. This is another part of the problem. There is currently no way to set which keyboard you would like to use on iOS/Android if I understand correctly. We could maybe get a standardized API which could solve this. Having support in desktop browsers first for handling spell check better would probably help in achieving this though. If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). Not sure if any spec change is needed for that. - Florian
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 del...@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, cha...@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@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:%20del...@segonquart.net [3] skype:segonquart [4] http://segonquart.net [5] http://delfiramirez.info
Re: [whatwg] Input and spell check/keyboard settings
On 18.06.2015 12:01, Florian Rivoal wrote: On 18 Jun 2015, at 10:58, cha...@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@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… So the browser could re-use lang and when the user either manually sets spell checker or the system automatically detects language being written it could set the lang attribute on a textarea element. And when the form is submitted it could be stored by the web server in the right context and served again with the form the next time I am writing in the same context (Ie. writing to the same friend in webmail or fb)? Or did I misunderstand this? 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. This is another part of the problem. There is currently no way to set which keyboard you would like to use on iOS/Android if I understand correctly. We could maybe get a standardized API which could solve this. Having support in desktop browsers first for handling spell check better would probably help in achieving this though. 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
Re: [whatwg] Input and spell check/keyboard settings
Hello All:Same solution than before. I knew there a library in the spec of Adobe and its scripting languages ( a derivative of ECMA/DOM) that implemented IME as well. Like a charm. For virtual kybrds , specially. As before, It would be nice that someone at Adobe Inc. could introduce us to this possible solution . Cheers --- Delfi Ramirez My digital signature [1] +34 633 589231 del...@segonquart.net [2] twitter: delfinramirez IRC: segonquart Skype: segonquart [3] http://segonquart.net [4] http://delfiramirez.info [5] On 2015-06-18 13:17, Florian Rivoal wrote: On 18 Jun 2015, at 13:07, Jonny Rein Eriksen jon...@opera.com wrote: On 18.06.2015 12:01, Florian Rivoal wrote: 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. This is another part of the problem. There is currently no way to set which keyboard you would like to use on iOS/Android if I understand correctly. We could maybe get a standardized API which could solve this. Having support in desktop browsers first for handling spell check better would probably help in achieving this though. If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). Not sure if any spec change is needed for that. - Florian Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] skype:segonquart [4] http://segonquart.net [5] http://delfiramirez.info
Re: [whatwg] Input and spell check/keyboard settings
On 18 Jun 2015, at 10:58, cha...@yandex-team.ru wrote: - jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@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
[whatwg] Input and spell check/keyboard settings
The problem: When writing messages on Facebook, in web-mail, in discussion forums and so on, we often end up switching languages for the spell-checker in the desktop browser and on phones we switch which keyboard we use. Typically I will write in English in messages to my English friends and Norwegian to my Norwegian friends. But since spell-check and keyboard are always global settings in browsers we end up having to switch keyboard and spell-checker whenever we switch between who we are writing messages to. Of course this is only a problem if you communicate in multiple languages. 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. The idea being that this context attribute would be connected to each entity you were communicating with. In general I would have a default spell-checker/keyboard. Since I set it to English last time I talked to an English friend on Facebook and if Facebook supported this context ID the browser would remember this and auto-switch to English next time I started writing a message to him. We would need to define an attribute for the input field so that web sites could supply such a context ID. Looking at Textarea there are related settings: Id, Spell check and input mode are the most obvious, but nothing I can find that would solve this issue, IE. a context ID that could be set per user, or group of users you are writing to. Or did I miss something? My question then: Is this interesting for this group? Jonny Rein Eriksen Opera Software
Re: [whatwg] Input and spell check/keyboard settings
- jonnyr@ 18.06.2015, 09:59, Jonny Rein Eriksen jon...@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… har det bra Chaals -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
