Re: Fwd: I-D Action: draft-msporny-d-langtag-ext-00.txt
Mark Davis ☕️ <[email protected]> Tue, 28 May 2019 06:05:05 +0200
| Newsgroups | gmane.ietf.languages |
|---|---|
| Message-ID | <CAJ2xs_EeeF=S1Z3JNe55fDC2c6y7W4n97+GML365Us5V1+MmLA@mail.gmail.com> |
--===============8387122578102954580== Content-Type: multipart/alternative; boundary="000000000000c51fe50589eac5e4" --000000000000c51fe50589eac5e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mark On Mon, May 27, 2019 at 10:10 PM Manu Sporny <[email protected]> wrote: > On 5/27/19 9:52 AM, Mark Davis =E2=98=95=EF=B8=8F wrote: > > I think what they are trying to do is shoehorn in a parameter that > > lets them set the paragraph embedding level > > (https://unicode.org/reports/tr9/#BD4) for the Bidi Algorithm. > > Hmm, no, I don't think that's it... Here's some background, Mark: > > https://github.com/w3c/rdf-dir-literal/issues/3#issuecomment-496004819 > > ... and why we're having this discussion: > > https://github.com/w3c/rdf-dir-literal/issues/3#issuecomment-496006350 > > ... and what the current proposed spec text in the Verifiable > Credentials Data Model specification regarding i18n states: > > > https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/641.html#inter= nationalization-considerations > > > 1. So from the tag "ar-Arab", we get the script "Arab". Then use > > > https://github.com/unicode-org/cldr/blob/master/common/properties/scriptM= etadata.txt > , > > > > > > > > > which has a mapping from script to direction (RTL=3DYES). (I'm pointing t= o > > trunk, just so people can read the file easily; one would use the > > latest release.) > > What about for something like this, where BiDi doesn't work? > > HTML =D9=88 CSS: =D8=AA=D8=B5=D9=85=D9=8A=D9=85 =D9=88 =D8=A5=D9=86=D8=B4= =D8=A7=D8=A1 =D9=85=D9=88=D8=A7=D9=82=D8=B9 =D8=A7=D9=84=D9=88=D9=8A=D8=A8 > I assume that by the phrase "BiDi doesn't work" you mean that the original author's intended display is not achieved. It would help if you clearly provided examples of the source text, and what is desired. While the paragraph direction is important, it is often *not* enough to get exactly the right display, such as when there are neutral characters on the boundaries between RTL and LTR text that shouldn't follow the paragraph direction. For that the author needs finer-grained control over the direction. That can be achieved using the bidi control characters in Unicode, or by markup in higher-level languages (such as HTML/CSS). The markup approach is cleaner, where possible. Where the environment does not permit markup, the Unicode characters can be used to exactly control the bidi display. It appears that your use case has extremely limited markup, just the language tag, and just for a whole paragraph, and that you don't have the ability to add any further markup, and are driven to overloading the language tag for that purpose. Even assuming that, you have not made it clear why simply the language tag of "ar" =E2=80=94 *from which the paragra= ph direction could be derived* =E2=80=94 is not sufficient for your use case o= f setting the paragraph direction. > > It isn't that Arabic would be displayed left to right, it is what > > establishes the paragraph ordering. The problem arises when you have > > mixed text. Look at the following example, using the convention that > > lowercase =3D English and uppercase=3DArabic. The majority of the text > > and the first strong character are both English, but the sentence is > > meant to be used in an Arabic environment, so the default paragraph > > embedding level needs to be RTL. > > Yep. > > > 3. I also agree with Martin that the definition "automatically > > detected" for subtag 'auto' is not adequate. How does it differ from > > leaving off the D extension altogether? > > > > Agreed, not well specified. But -d- is not needed in the first place, > > so moot. > > Folks have argued against `auto`, happy to remove it if that's what > folks in this group think we should do. > > It was meant to achieve the same thing this achieves: > > https://www.w3.org/TR/string-meta/#dom-localizable-dir > > > While this is true, for the fast majority of cases, LTR and RTL are > > the important issues. Most computer systems don't really handle > > vertical natively; one needs to have more specialized text processing > > systems, and that is not, I imagine, the target for this syntax. > > We're happy to add other directionalities that folks in this group think > we should add. > > > 5. Given #4, the lack of a registry for the proposed extension, or > > even the mention of one, is a significant problem. The set of exactly > > 3 values associated with this extension ('ltr', 'rtl', and 'auto') > > would be fixed; adding to it would require updating the RFC, which is > > much more work than updating a registry. > > > > Agreed, that would be a major drawback. But -d- is not needed in > > the first place, so moot. > > Sure, we can add a registry, I can make that change in the next version > once it becomes clear that the proposal has merit and won't be rejected > by this or the W3C i18n community. > > > Without these issues being addressed in a satisfactory way, I would > > lobby IETF not to approve this I-D. > > > > I don't see that there is any reason to approve it, given that it is, > > as far as I can tell, completely unnecessary and would just > > complicate implementer's lives to no good end. > > Given the new information above (links to use cases, background > discussion), are you still of the opinion that there is no need for the > extension? > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Veres One Decentralized Identifier Blockchain Launches > https://tinyurl.com/veres-one-launches > --000000000000c51fe50589eac5e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:times new roman,serif"><br clear=3D"all"></div><div><div dir=3D"lt= r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D= "ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir= =3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><font face=3D"'times new rom= an', serif"><div style=3D"background-color:transparent;margin-top:0px;m= argin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div><div st= yle=3D"background-color:transparent;margin-top:0px;margin-left:0px;margin-b= ottom:0px;margin-right:0px">Mark</div></font><div><div><font face=3D"'t= imes new roman', serif"><i><span style=3D"font-style:normal"><i></i></s= pan><i></i></i></font></div></div></div></div></div></div></div></div></div= ></div></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Mon, May 27, 2019 at 10:10 PM Manu Sporny = <<a href=3D"mailto:[email protected]">[email protected]<= /a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O= n 5/27/19 9:52 AM, Mark Davis =E2=98=95=EF=B8=8F wrote:<br> > I think what they are trying to do is shoehorn in a parameter that <br= > > lets them set the paragraph embedding level <br> > (<a href=3D"https://unicode.org/reports/tr9/#BD4" rel=3D"noreferrer" t= arget=3D"_blank">https://unicode.org/reports/tr9/#BD4</a>) for the Bidi Alg= orithm.<br> <br> Hmm, no, I don't think that's it... Here's some background, Mar= k:<br> <br> <a href=3D"https://github.com/w3c/rdf-dir-literal/issues/3#issuecomment-496= 004819" rel=3D"noreferrer" target=3D"_blank">https://github.com/w3c/rdf-dir= -literal/issues/3#issuecomment-496004819</a><br> <br> .... and why we're having this discussion:<br> <br> <a href=3D"https://github.com/w3c/rdf-dir-literal/issues/3#issuecomment-496= 006350" rel=3D"noreferrer" target=3D"_blank">https://github.com/w3c/rdf-dir= -literal/issues/3#issuecomment-496006350</a><br> <br> .... and what the current proposed spec text in the Verifiable<br> Credentials Data Model specification regarding i18n states:<br> <br> <a href=3D"https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/641.h= tml#internationalization-considerations" rel=3D"noreferrer" target=3D"_blan= k">https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/641.html#inte= rnationalization-considerations</a><br> <br> > 1. So from the tag "ar-Arab", we get the script "Arab&q= uot;. Then use <br> > <a href=3D"https://github.com/unicode-org/cldr/blob/master/common/prop= erties/scriptMetadata.txt" rel=3D"noreferrer" target=3D"_blank">https://git= hub.com/unicode-org/cldr/blob/master/common/properties/scriptMetadata.txt</= a>,<br> ><br> ><br> ><br> > <br> which has a mapping from script to direction (RTL=3DYES). (I'm pointing= to<br> > trunk, just so people can read the file easily; one would use the <br> > latest release.)<br> <br> What about for something like this, where BiDi doesn't work?<br> <br> HTML =D9=88 CSS: =D8=AA=D8=B5=D9=85=D9=8A=D9=85 =D9=88 =D8=A5=D9=86=D8=B4= =D8=A7=D8=A1 =D9=85=D9=88=D8=A7=D9=82=D8=B9 =D8=A7=D9=84=D9=88=D9=8A=D8=A8<= br></blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"f= ont-family:"times new roman",serif">I assume that by the phrase &= quot;BiDi doesn't work" you mean that the original author's in= tended display is not achieved.</div><div class=3D"gmail_default" style=3D"= font-family:"times new roman",serif"><br></div><div class=3D"gmai= l_default" style=3D"font-family:"times new roman",serif">It would= help if you clearly provided examples of the source text, and what is desi= red. While the paragraph direction is important, it is often *not* enough t= o get exactly the right display, such as when there are neutral characters = on the boundaries between RTL and LTR text that shouldn't follow the pa= ragraph direction. For that the author needs finer-grained control over the= direction. That can be achieved using the bidi control characters in Unico= de, or by markup in higher-level languages (such as HTML/CSS). The markup a= pproach is cleaner, where possible. Where the environment does not permit m= arkup, the Unicode characters can be used to exactly control the bidi displ= ay.</div><div class=3D"gmail_default" style=3D"font-family:"times new = roman",serif"><br></div><div class=3D"gmail_default" style=3D"font-fam= ily:"times new roman",serif">It appears that your use case has ex= tremely limited markup, just the language tag, and just for a whole paragra= ph, and that you don't have the ability to add any further markup, and = are driven to overloading the language tag for that purpose. Even assuming = that, you have not made it clear why simply the language tag of "ar&qu= ot; =E2=80=94 <i>from which the paragraph direction could be derived</i> = =E2=80=94 is not sufficient for your use case of setting the paragraph dire= ction.</div><div class=3D"gmail_default" style=3D"font-family:"times n= ew roman",serif"><br></div></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex"> <br> > It isn't that Arabic would be displayed left to right, it is what = <br> > establishes the paragraph ordering. The problem arises when you have <= br> > mixed text. Look at the following example, using the convention that <= br> > lowercase =3D English and uppercase=3DArabic. The majority of the text= <br> > and the first strong character are both English, but the sentence is<b= r> >=C2=A0 meant to be used in an Arabic environment, so the default paragr= aph<br> >=C2=A0 embedding level needs to be RTL.<br> <br> Yep.<br> <br> > 3. I also agree with Martin that the definition "automatically <b= r> > detected" for subtag 'auto' is not adequate. How does it = differ from <br> > leaving off the D extension altogether?<br> > <br> > Agreed, not well specified. But -d- is not needed in the first place,<= br> > so moot.<br> <br> Folks have argued against `auto`, happy to remove it if that's what<br> folks in this group think we should do.<br> <br> It was meant to achieve the same thing this achieves:<br> <br> <a href=3D"https://www.w3.org/TR/string-meta/#dom-localizable-dir" rel=3D"n= oreferrer" target=3D"_blank">https://www.w3.org/TR/string-meta/#dom-localiz= able-dir</a><br> <br> > While this is true, for the fast majority of cases, LTR and RTL are <b= r> > the important issues. Most computer systems don't really handle <b= r> > vertical natively; one needs to have more specialized text processing<= br> > systems, and that is not, I imagine, the target for this syntax.<br> <br> We're happy to add other directionalities that folks in this group thin= k<br> we should add.<br> <br> > 5. Given #4, the lack of a registry for the proposed extension, or <br= > > even the mention of one, is a significant problem. The set of exactly<= br> > 3 values associated with this extension ('ltr', 'rtl',= and 'auto')<br> > would be fixed; adding to it would require updating the RFC, which is<= br> > much more work than updating a registry.<br> > <br> > Agreed, that would be a major drawback.=C2=A0 But -d- is not needed in= <br> > the first place, so moot.<br> <br> Sure, we can add a registry, I can make that change in the next version<br> once it becomes clear that the proposal has merit and won't be rejected= <br> by this or the W3C i18n community.<br> <br> > Without these issues being addressed in a satisfactory way, I would <b= r> > lobby IETF not to approve this I-D.<br> > <br> > I don't see that there is any reason to approve it, given that it = is,<br> > as far as I can tell, completely unnecessary and would just <br> > complicate implementer's lives to no good end.<br> <br> Given the new information above (links to use cases, background<br> discussion), are you still of the opinion that there is no need for the<br> extension?<br> <br> -- manu<br> <br> -- <br> Manu Sporny (skype: msporny, twitter: manusporny)<br> Founder/CEO - Digital Bazaar, Inc.<br> blog: Veres One Decentralized Identifier Blockchain Launches<br> <a href=3D"https://tinyurl.com/veres-one-launches" rel=3D"noreferrer" targe= t=3D"_blank">https://tinyurl.com/veres-one-launches</a><br> </blockquote></div></div> --000000000000c51fe50589eac5e4-- --===============8387122578102954580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-languages mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-languages --===============8387122578102954580==--