Re: [whatwg] Proposal in supporting the writing of "Arabizi"

2012-05-10 Thread Ian Hickson
On Thu, 10 May 2012, Sami Eljabali wrote:
> On Thu, May 10, 2012 at 12:38 PM, Ian Hickson  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"

2012-05-10 Thread Sami Eljabali
Will do!

Thanks for the feedback,
-Sami

On Thu, May 10, 2012 at 1:41 PM, Maciej Stachowiak  wrote:

>
> On May 10, 2012, at 12:00 PM, Sami Eljabali  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  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"

2012-05-10 Thread Maciej Stachowiak

On May 10, 2012, at 12:00 PM, Sami Eljabali  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  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"

2012-05-10 Thread Ryosuke Niwa
On Thu, May 10, 2012 at 1:28 PM, Sami Eljabali  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"

2012-05-10 Thread Sami Eljabali
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  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"

2012-05-10 Thread Ian Hickson
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"

2012-05-10 Thread Sami Eljabali
On Tue, May 8, 2012 at 2:38 PM, Ian Hickson  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 
> > 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:  > type="text" lang="arabizi"> to interpret
> > Arabizias Arabic.
> > Should a browser not support it, then the  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
> > , 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"

2012-05-08 Thread Ian Hickson
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  
> 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:  type="text" lang="arabizi"> to interpret 
> Arabizias Arabic. 
> Should a browser not support it, then the  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 
> , 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"

2011-12-04 Thread Glenn Maynard
On Sun, Dec 4, 2011 at 11:05 PM, 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.
>

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"

2011-12-04 Thread Ryosuke Niwa
On Sun, Dec 4, 2011 at 8:05 PM, 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.
>

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"

2011-12-04 Thread Sami Eljabali
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 wrote:

> 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"

2011-12-04 Thread Mark Callow
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"

2011-12-04 Thread Sami Eljabali
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 wrote:

> 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 
> wrote:
> > [snip]
> >> *Proposal:*
> >>
> >> Have the interpreter described above be embedded within browsers and
> >> enabled when users click and focus on text fields defined as:  >> type="text" lang="arabizi"> to interpret
> >> Arabizias Arabic.
> >> Should a browser not support it, then the  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
> > , 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"

2011-12-01 Thread Ryosuke Niwa
On Thu, Dec 1, 2011 at 10:28 PM, Mark Callow wrote:
>
> 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


Re: [whatwg] Proposal in supporting the writing of "Arabizi"

2011-12-01 Thread Mark Callow
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  wrote:
> [snip]
>> *Proposal:*
>>
>> Have the interpreter described above be embedded within browsers and
>> enabled when users click and focus on text fields defined as: > type="text" lang="arabizi"> to interpret
>> Arabizias Arabic.
>> Should a browser not support it, then the  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
> , 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"

2011-12-01 Thread Tab Atkins Jr.
On Thu, Dec 1, 2011 at 1:07 AM, Sami Eljabali  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:  type="text" lang="arabizi"> to interpret
> Arabizias Arabic.
> Should a browser not support it, then the  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
, 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"

2011-12-01 Thread Sergiusz Wolicki
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  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  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:  type="text" lang="arabizi"> to interpret
> Arabizias Arabic.
> Should a browser not support it, then the  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
> or 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
>


[whatwg] Proposal in supporting the writing of "Arabizi"

2011-12-01 Thread Sami Eljabali
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  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:  to interpret
Arabizias Arabic.
Should a browser not support it, then the  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
or 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