Re: [whatwg] Proposal in supporting the writing of Arabizi
On Tue, May 8, 2012 at 2:38 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Dec 2011, Sami Eljabali wrote: There's a need for phonetic based keyboard support for Arabic speaking users on today's internet. There are two primary reasons for this: 1) Many Arabic speaking users don't surf in Arabic. A good portion of them are in non-arabic speaking countries, hence more often than not have non-arabic keyboards therefore finding it difficult to write Arabic on the internet. There are on the contrary, virtual Arabic keyboards on the OS level, as well as on sites like Google http://www.google.ae/ addressing this, however phonetically spelling out a word, and seeing a list of words containing the one you were trying to spell out is dramatically more effective than the counterpart. 2) It vastly aids those with lacking a thorough Arabic education to properly to spell out what they phonetically know, hence allows a greater audience including non-natives to write in Arabic. *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. As far as I can tell, nothing stops a Web browser or operating system from implementing this kind of thing today. No need for the specification to say anything special. On Thu, 1 Dec 2011, Tab Atkins Jr. wrote: We are looking into something like this for many languages. I've attempted to record this as a use-case on http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control, but I can't figure out how to upload images yet. Once I do, I'll add screenshots, an explanation, and a link to this thread. Supporting this kind of thing is definitely on the table, but as you hint above, it needs more research first. On Sun, 4 Dec 2011, Sami Eljabali wrote: I feel more thought could be put in swaying IME's off OSs, as it is limiting in availability for all. I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. On Sun, 4 Dec 2011, Sami Eljabali wrote: By not moving IME's off OSes, you're asking every OS connecting to the internet to support this feature. Netbooks for example, may just have a native web browser on it. Would its OS then need to implement its own IME for a few languages for their entry? Instead its web browser could just support the input field, given they can render them. On Sun, 4 Dec 2011, Ryosuke Niwa wrote: Why would implementing IME for such an OS be harder than implementing one for the web browser? Indeed. From the spec's point of view, they're more or less equivalent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, 10 May 2012, Sami Eljabali wrote: I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Why would Apple and Microsoft be any more likely to think it worth implementing in their browser than in their operating system? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal in supporting the writing of Arabizi
Because then they wouldn't be HMTL5 compliant vs not having a nifty feature. How would you push this forward being adopted? I'm mostly likely not thinking creatively enough. On Thu, May 10, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Sami Eljabali wrote: I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Why would Apple and Microsoft be any more likely to think it worth implementing in their browser than in their operating system? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, May 10, 2012 at 1:28 PM, Sami Eljabali seljab...@gmail.com wrote: Because then they wouldn't be HMTL5 compliant vs not having a nifty feature. How would you push this forward being adopted? I'm mostly likely not thinking creatively enough. Why would it be a part of HTML5 if vendors don't want to implement it? Just because something has been proposed to be added to HTML5 doesn't mean it will be supported by all browsers. In fact, if some vendors strongly oppose, then we're going to remove it from the spec. What you need to do first is to convince Microsoft and Apple that this is a valuable feature they want to have instead of trying to circumvent the process. Quite frankly, I would be opposed to adding this feature to WebKit / Chromium as well although I can't speak for my employer or the boarder WebKit or Chromium open source communities. - Ryosuke
Re: [whatwg] Proposal in supporting the writing of Arabizi
On May 10, 2012, at 12:00 PM, Sami Eljabali seljab...@gmail.com wrote: Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Mac OS X supports Arabic, Arabic - PC and Arabic - QWERTY input methods. If none of these provide the functionality of Arabizi then please file a bug at http://bugreport.apple.com/ and we can consider adding it for the whole OS. Mac OS X also supports third-party downloadable input methods. We are unlikely to support a browser-specific form of input methods. Regards, Maciej
Re: [whatwg] Proposal in supporting the writing of Arabizi
Will do! Thanks for the feedback, -Sami On Thu, May 10, 2012 at 1:41 PM, Maciej Stachowiak m...@apple.com wrote: On May 10, 2012, at 12:00 PM, Sami Eljabali seljab...@gmail.com wrote: Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Mac OS X supports Arabic, Arabic - PC and Arabic - QWERTY input methods. If none of these provide the functionality of Arabizi then please file a bug at http://bugreport.apple.com/ and we can consider adding it for the whole OS. Mac OS X also supports third-party downloadable input methods. We are unlikely to support a browser-specific form of input methods. Regards, Maciej
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, 10 May 2012, Sami Eljabali wrote: On Thu, May 10, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Sami Eljabali wrote: I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. Good luck pushing Apple Microsoft in implementing this. If we create this as a tag then we'd push every OS vendor to support it. Why would Apple and Microsoft be any more likely to think it worth implementing in their browser than in their operating system? Because then they wouldn't be HMTL5 compliant vs not having a nifty feature. How would you push this forward being adopted? I'm mostly likely not thinking creatively enough. Ah, I see the source of confusion. We have no ability in this work to force browser vendors to implement something they don't want to support. So adding it to the spec does nothing if they don't want to implement it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, 1 Dec 2011, Sami Eljabali wrote: There's a need for phonetic based keyboard support for Arabic speaking users on today's internet. There are two primary reasons for this: 1) Many Arabic speaking users don't surf in Arabic. A good portion of them are in non-arabic speaking countries, hence more often than not have non-arabic keyboards therefore finding it difficult to write Arabic on the internet. There are on the contrary, virtual Arabic keyboards on the OS level, as well as on sites like Google http://www.google.ae/ addressing this, however phonetically spelling out a word, and seeing a list of words containing the one you were trying to spell out is dramatically more effective than the counterpart. 2) It vastly aids those with lacking a thorough Arabic education to properly to spell out what they phonetically know, hence allows a greater audience including non-natives to write in Arabic. *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. As far as I can tell, nothing stops a Web browser or operating system from implementing this kind of thing today. No need for the specification to say anything special. On Thu, 1 Dec 2011, Tab Atkins Jr. wrote: We are looking into something like this for many languages. I've attempted to record this as a use-case on http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control, but I can't figure out how to upload images yet. Once I do, I'll add screenshots, an explanation, and a link to this thread. Supporting this kind of thing is definitely on the table, but as you hint above, it needs more research first. On Sun, 4 Dec 2011, Sami Eljabali wrote: I feel more thought could be put in swaying IME's off OSs, as it is limiting in availability for all. I don't understand. Everybody has an operating system. Why would putting things in the operating system limit availability? Operating systems and their GUIs are responsible for almost everything that a browser does, at one level or another. On Sun, 4 Dec 2011, Sami Eljabali wrote: By not moving IME's off OSes, you're asking every OS connecting to the internet to support this feature. Netbooks for example, may just have a native web browser on it. Would its OS then need to implement its own IME for a few languages for their entry? Instead its web browser could just support the input field, given they can render them. On Sun, 4 Dec 2011, Ryosuke Niwa wrote: Why would implementing IME for such an OS be harder than implementing one for the web browser? Indeed. From the spec's point of view, they're more or less equivalent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal in supporting the writing of Arabizi
Thanks Mark for the clarification, and thanks all for the feedback. To the valid point however, regarding the result of bloated web browsers storing each language's dictionary, I feel more thought could be put in swaying IME's off OSs, as it is limiting in availability for all. That said, couldn't we have have 'dictionary look-ups' be served as a service? It could follow the search services model available today, where users choose their provider to be used by the browser itself. This would allow room for providers to even emerge given possible incentives or others including noting trends circulating via users speaking x,y, or z languages. Worst case, one could look into a peer-to-peer solution, where users donate their bandwidth/cpu for others. Your thoughts on this are appreciated. Thanks for your time, -Sami On Thu, Dec 1, 2011 at 10:28 PM, Mark Callow callow_m...@hicorp.co.jpwrote: I think what is being requested by the OP is very very different from the things being requested in the W3C bugs linked from the below referenced wiki page (which seem like good ideas, but please ensure that '+' can be entered in phone numbers). As Sergiusz Wolicki pointed the OP is requesting an IME and IMEs already exist for several languages. The corollary of this is that hooks for IMEs exist in all major operating systems. As Sergiusz also pointed out, users will want this functionality available in any text field. I think it would be better to develop an Arabic IME for the OS rather than embedding it in browsers. Maybe such a thing already exists. Have you any idea of the size of the dictionary and supporting data needed for the Japanese IME? It is quite large. I do not think browser vendors will want to bloat their products with large IME dictionaries for even one language so any browser-based IMEs will inevitably become separate downloads. In which case there is no benefit compared to a separately downloaded OS-based IME and the disadvantage that it can't be used with any text field on the system. Regards -Mark On 02/12/2011 03:36, Tab Atkins Jr. wrote: On Thu, Dec 1, 2011 at 1:07 AM, Sami Eljabali seljab...@gmail.com wrote: [snip] *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. We are looking into something like this for many languages. I've attempted to record this as a use-case on http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control, but I can't figure out how to upload images yet. Once I do, I'll add screenshots, an explanation, and a link to this thread.
Re: [whatwg] Proposal in supporting the writing of Arabizi
Why do you feel it is necessary to sway IME's off OSes? As far as I know the OS ones are all freely downloadable or included in OS distributions. The downloadable ones are not even as hard to find as they used to be. They're needed for all text input fields across the system. They're complicated enough that I wouldn't want to have to learn different ones in different applications. I quite agree about the dictionaries and not just for IMEs. I have a ridiculous number of English dictionaries installed on my system, e.g., one in Thunderbird, one in Firefox, one in MS Office, one in XMLMind, one in Foxit Reader plus a host of others. I also have separate copies of the _same_ Japanese dictionaries in Thunderbird and Firefox for use by the Rikaichan plug-in. However having dictionary look-up only available as a network service is a very dangerous way to go from the perspective of civil rights and liberties. It needs to be a service available locally perhaps with an option to go to the network. Regards -Mark On 05/12/2011 07:42, Sami Eljabali wrote: Thanks Mark for the clarification, and thanks all for the feedback. To the valid point however, regarding the result of bloated web browsers storing each language's dictionary, I feel more thought could be put in swaying IME's off OSs, as it is limiting in availability for all. That said, couldn't we have have 'dictionary look-ups' be served as a service? It could follow the search services model available today, where users choose their provider to be used by the browser itself. This would allow room for providers to even emerge given possible incentives or others including noting trends circulating via users speaking x,y, or z languages. Worst case, one could look into a peer-to-peer solution, where users donate their bandwidth/cpu for others. Your thoughts on this are appreciated.
Re: [whatwg] Proposal in supporting the writing of Arabizi
By not moving IME's off OSes, you're asking every OS connecting to the internet to support this feature. Netbooks for example, may just have a native web browser on it. Would its OS then need to implement its own IME for a few languages for their entry? Instead its web browser could just support the input field, given they can render them. On Sun, Dec 4, 2011 at 5:17 PM, Mark Callow callow_m...@hicorp.co.jpwrote: Why do you feel it is necessary to sway IME's off OSes? As far as I know the OS ones are all freely downloadable or included in OS distributions. The downloadable ones are not even as hard to find as they used to be. They're needed for all text input fields across the system. They're complicated enough that I wouldn't want to have to learn different ones in different applications. I quite agree about the dictionaries and not just for IMEs. I have a ridiculous number of English dictionaries installed on my system, e.g., one in Thunderbird, one in Firefox, one in MS Office, one in XMLMind, one in Foxit Reader plus a host of others. I also have separate copies of the _same_ Japanese dictionaries in Thunderbird and Firefox for use by the Rikaichan plug-in. However having dictionary look-up only available as a network service is a very dangerous way to go from the perspective of civil rights and liberties. It needs to be a service available locally perhaps with an option to go to the network. Regards -Mark On 05/12/2011 07:42, Sami Eljabali wrote: Thanks Mark for the clarification, and thanks all for the feedback. To the valid point however, regarding the result of bloated web browsers storing each language's dictionary, I feel more thought could be put in swaying IME's off OSs, as it is limiting in availability for all. That said, couldn't we have have 'dictionary look-ups' be served as a service? It could follow the search services model available today, where users choose their provider to be used by the browser itself. This would allow room for providers to even emerge given possible incentives or others including noting trends circulating via users speaking x,y, or z languages. Worst case, one could look into a peer-to-peer solution, where users donate their bandwidth/cpu for others. Your thoughts on this are appreciated.
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Sun, Dec 4, 2011 at 8:05 PM, Sami Eljabali seljab...@gmail.com wrote: By not moving IME's off OSes, you're asking every OS connecting to the internet to support this feature. Netbooks for example, may just have a native web browser on it. Would its OS then need to implement its own IME for a few languages for their entry? Instead its web browser could just support the input field, given they can render them. Why would implementing IME for such an OS be harder than implementing one for the web browser? - Ryosuke
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Sun, Dec 4, 2011 at 11:05 PM, Sami Eljabali seljab...@gmail.com wrote: By not moving IME's off OSes, you're asking every OS connecting to the internet to support this feature. Netbooks for example, may just have a native web browser on it. Would its OS then need to implement its own IME for a few languages for their entry? Instead its web browser could just support the input field, given they can render them. Input methods are the job of the operating system, just like file access and networking; it's a component of user input. If a system wants to run only a browser, it's still the *system's* responsibility to provide input methods; they should no more be moved to browsers than should ext4 or TCP/IP. I can also guarantee that actual users don't want browsers to use a different input method for complex scripts like Japanese, any more than they want browsers to have their own built-in filesystems or networking protocols. They (which includes myself) want input methods to act the same way in Firefox as they do in Office and Photoshop and terminal windows and everything else. -- Glenn Maynard
Re: [whatwg] Proposal in supporting the writing of Arabizi
What you are proposing is not a HTML feature but an O/S- or browser-specific functionality equivalent to East Asian IMEs. East Asian IMEs (input method editors = complex keyboard processors), which often use a similar phonetic method to enter ideographic or syllabic characters, can be activated by a keyboard sequence in any text field, not only INPUT fields. It would be nice to have the mentioned functionality in each browsers, but each Chinese user would like something like this for Chinese as well. As a Polish, I would like a way to insert Polish characters easily in any browser as well. The proposed feature is therefore not a matter of HTML or even browsers but rather of the operating systems. Also, the lang= attribute is already well defined for any HTML element. You cannot specify lang=arabizi because there is no such language in the relevant ISO standard (ISO 639). Arabizi is a pseudo-script but it is also not in the relevant ISO standard (ISO 15924). Therefore, ar-Arabizi is also illegal. You could theoretically say lang=x-arabizi (private tag) but then you would not be able to properly specify the actual language, for example for a spellchecker. Thanks Sergiusz On Thu, Dec 1, 2011 at 10:07 AM, Sami Eljabali seljab...@gmail.com wrote: Hello, I apologize if this an incorrect forum to propose new html features in which case you may disregard this email, however should you know a more appropriate forum then please let me know, else I ask you to please entertain this email. :) There's a need for phonetic based keyboard support for Arabic speaking users on today's internet. There are two primary reasons for this: 1) Many Arabic speaking users don't surf in Arabic. A good portion of them are in non-arabic speaking countries, hence more often than not have non-arabic keyboards therefore finding it difficult to write Arabic on the internet. There are on the contrary, virtual Arabic keyboards on the OS level, as well as on sites like Google http://www.google.ae/ addressing this, however phonetically spelling out a word, and seeing a list of words containing the one you were trying to spell out is dramatically more effective than the counterpart. 2) It vastly aids those with lacking a thorough Arabic education to properly to spell out what they phonetically know, hence allows a greater audience including non-natives to write in Arabic. * * *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. * * *Advantages of a Browser Implementation* 1) Guaranteed availability and ease of use for users continually relying on this feature, opposed to using third party service http://www.yamli.comor installed software. 2) Exposure to the majority of users in need of this capability. Furthermore, we believe the lang attribute opens doors in supporting other languages. Even showing a virtual keyboard for most spoken languages, and its variations, would ultimately ensure the ability everyone to express themselves in their language(s) of choosing on the internet. Your feedback is more than appreciated. Thank you for your time, Sami Eljabali Daniel Bates
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, Dec 1, 2011 at 1:07 AM, Sami Eljabali seljab...@gmail.com wrote: Hello, I apologize if this an incorrect forum to propose new html features in which case you may disregard this email, however should you know a more appropriate forum then please let me know, else I ask you to please entertain this email. :) There's a need for phonetic based keyboard support for Arabic speaking users on today's internet. There are two primary reasons for this: [snip] *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. We are looking into something like this for many languages. I've attempted to record this as a use-case on http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control, but I can't figure out how to upload images yet. Once I do, I'll add screenshots, an explanation, and a link to this thread. Thanks! ~TJ
Re: [whatwg] Proposal in supporting the writing of Arabizi
I think what is being requested by the OP is very very different from the things being requested in the W3C bugs linked from the below referenced wiki page (which seem like good ideas, but please ensure that '+' can be entered in phone numbers). As Sergiusz Wolicki pointed the OP is requesting an IME and IMEs already exist for several languages. The corollary of this is that hooks for IMEs exist in all major operating systems. As Sergiusz also pointed out, users will want this functionality available in any text field. I think it would be better to develop an Arabic IME for the OS rather than embedding it in browsers. Maybe such a thing already exists. Have you any idea of the size of the dictionary and supporting data needed for the Japanese IME? It is quite large. I do not think browser vendors will want to bloat their products with large IME dictionaries for even one language so any browser-based IMEs will inevitably become separate downloads. In which case there is no benefit compared to a separately downloaded OS-based IME and the disadvantage that it can't be used with any text field on the system. Regards -Mark On 02/12/2011 03:36, Tab Atkins Jr. wrote: On Thu, Dec 1, 2011 at 1:07 AM, Sami Eljabali seljab...@gmail.com wrote: [snip] *Proposal:* Have the interpreter described above be embedded within browsers and enabled when users click and focus on text fields defined as: input type=text lang=arabizi to interpret Arabizihttp://en.wikipedia.org/wiki/Arabic_chat_alphabetas Arabic. Should a browser not support it, then the input type=text would be the fallback attribute leaving users writing in a plain text field. We are looking into something like this for many languages. I've attempted to record this as a use-case on http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control, but I can't figure out how to upload images yet. Once I do, I'll add screenshots, an explanation, and a link to this thread.
Re: [whatwg] Proposal in supporting the writing of Arabizi
On Thu, Dec 1, 2011 at 10:28 PM, Mark Callow callow_m...@hicorp.co.jpwrote: As Sergiusz Wolicki pointed the OP is requesting an IME and IMEs already exist for several languages. The corollary of this is that hooks for IMEs exist in all major operating systems. As Sergiusz also pointed out, users will want this functionality available in any text field. I think it would be better to develop an Arabic IME for the OS rather than embedding it in browsers. Maybe such a thing already exists. There are Arabic IMEs. I use them all the time on Windows and OS X to test bidi support. Have you any idea of the size of the dictionary and supporting data needed for the Japanese IME? It is quite large. I do not think browser vendors will want to bloat their products with large IME dictionaries for even one language so any browser-based IMEs will inevitably become separate downloads. In which case there is no benefit compared to a separately downloaded OS-based IME and the disadvantage that it can't be used with any text field on the system. Well said. - Ryosuke
