Re: Fwd: I-D Action: draft-msporny-d-langtag-ext-00.txt
Mark Davis ☕️ <[email protected]> Mon, 27 May 2019 21:07:28 +0200
| Newsgroups | gmane.ietf.languages |
|---|---|
| Message-ID | <CAJ2xs_GiwkqHPxsoW91ZbA82o1oosXNb=Hm2XOuKuEkMMcNBhA@mail.gmail.com> |
--===============2464292825189242224== Content-Type: multipart/alternative; boundary="00000000000024a81d0589e343ce" --00000000000024a81d0589e343ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Below On Mon, May 27, 2019 at 7:07 PM Doug Ewell <[email protected]> wrote: > Mark Davis wrote: > > > 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 > > to trunk, just so people can read the file easily; one would use the > > latest release.) > > Yes, all right, if you are a text process that renders or formats text, > but you don't know that the Arabic script is RTL, then fine, use CLDR to > tell you that. OK. > > > 2. But let's suppose that you have just "ar". Since the script is not > > explicit, the best way to get it is also CLDR. You can use > > > https://github.com/unicode-org/cldr/blob/master/common/supplemental/likel= ySubtags.xml > , > > which has a mapping from language or language+region to default > > language-script-region. So "ar" =3D> "ar_Arab_EG", from which we get th= e > > script "Arab", and then use step 1. Or from "fr" you'd get "Latn" and > > map it to RTL=3DNO. > > You don't need CLDR for this step. The BCP 47 Language Subtag Registry > could have told you that: > > Type: language > Subtag: ar > Description: Arabic > Added: 2005-10-16 > Suppress-Script: Arab =E2=86=90 THIS > Scope: macrolanguage > > I mean, jeez, that's why we invented Suppress-Script in the first place. > (Well, sort of. We invented it to go the other way, when you're *creating= * > a tag, so when you're tempted to write "ar-Arab" you can stop and just > write "ar" instead. But this scenario works just as well.) > If you have a more complex matching scenario in mind, involving region an= d > variant subtags, or crossing over from Breton to French or whatever, then > go ahead and use CLDR. Or, I suppose, you can also use it here if you > already didn't know Arabic was a RTL script in #1 and you had to have CLD= R > available for that anyway. > > This is a lot like RFC 4647 matching: it isn't good enough for all > scenarios, so you might need customized or more ambitious matching > algorithms for those, but for many simpler cases it's just fine. But it > DOES exist and there's no need to pretend it doesn't and invent another > basic scheme. > There are Suppress-Script values for 134 languages, while there are 1,320 language-script values in CLDR; plus it has cases where the best script depends not only on both the language and the region (eg az-IQ). If someone wants to limit their usage to what's in Suppress-Script, it is up to them. But my advice (which is what I was providing) would be to use the more complete set in CLDR. > > > 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. > > It still doesn't sound as though inserting 'ltr' or 'rtl' into the > language tab would solve this problem. We have Unicode bidi controls for > this. (I know HTML has its own tags for this, which are preferred in that > context, but the GitHub thread indicates this isn't mostly about HTML.) > It wouldn't, and as I said (how did you miss this?), I agree that having -d- is a bad idea. What I was explaining was that "what rendering process is likely to display Arabic left-to-right?" is not the right issue. You don't need to know the paragraph embedding level to display pure Arabic. If you are curious about the BIDI algorithm, you can consult the spec, or better yet, the W3C page on it. > >> 4. Scripts exist in other directionalities besides LTR and RTL... > > > > While this is true, for the [v]ast 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. > > Today, yes. N years from now, when these specialized text processing > systems become mainstream, maybe it will be a different story. You don't > want to lock out that possibility by hard-coding the set of allowable > values into the RFC for all time. > Again, -d- is a bad idea anyway, whether or not there is a registry, or that there are more values at the onset. There are bigger fish to fry. > > > 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. > > Agreed, obviously. > > What we need to do is get together with the folks on the GitHub thread an= d > explain the situation to them, how this proposed solution is neither > necessary nor sufficient, and show them the right way(s) to do what they > need. > I think Addison and Manu will probably be taking feedback from this list back into the GitHub thread. > -- > Doug Ewell | Thornton, CO, US | ewellic.org > > > --00000000000024a81d0589e343ce 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">Below</div><div><div dir=3D"ltr" class=3D"g= mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><d= iv dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div= dir=3D"ltr"><div dir=3D"ltr"><div><div><font face=3D"'times new roman&= #39;, serif"><i><span style=3D"font-style:normal"><i></i></span><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 7:07 PM Doug Ewell <<a href=3D"m= ailto:[email protected]">[email protected]</a>> wrote:<br></div><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex">Mark Davis wrote:<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> > which has a mapping from script to direction (RTL=3DYES). (I'm poi= nting<br> > to trunk, just so people can read the file easily; one would use the<b= r> > latest release.)<br> <br> Yes, all right, if you are a text process that renders or formats text, but= you don't know that the Arabic script is RTL, then fine, use CLDR to t= ell you that. OK.<br> <br> > 2. But let's suppose that you have just "ar". Since the = script is not<br> > explicit, the best way to get it is also CLDR. You can use<br> > <a href=3D"https://github.com/unicode-org/cldr/blob/master/common/supp= lemental/likelySubtags.xml" rel=3D"noreferrer" target=3D"_blank">https://gi= thub.com/unicode-org/cldr/blob/master/common/supplemental/likelySubtags.xml= </a>,<br> > which has a mapping from language or language+region to default<br> > language-script-region. So "ar" =3D> "ar_Arab_EG&quo= t;, from which we get the<br> > script "Arab", and then use step 1. Or from "fr" y= ou'd get "Latn" and<br> > map it to RTL=3DNO.<br> <br> You don't need CLDR for this step. The BCP 47 Language Subtag Registry = could have told you that:<br> <br> Type: language<br> Subtag: ar<br> Description: Arabic<br> Added: 2005-10-16<br> Suppress-Script: Arab=C2=A0 =C2=A0 =C2=A0 =E2=86=90 THIS<br> Scope: macrolanguage<br> <br> I mean, jeez, that's why we invented Suppress-Script in the first place= .. (Well, sort of. We invented it to go the other way, when you're *crea= ting* a tag, so when you're tempted to write "ar-Arab" you ca= n stop and just write "ar" instead. But this scenario works just = as well.)<span style=3D"font-family:"times new roman",serif">=C2= =A0</span></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> If you have a more complex matching scenario in mind, involving region and = variant subtags, or crossing over from Breton to French or whatever, then g= o ahead and use CLDR. Or, I suppose, you can also use it here if you alread= y didn't know Arabic was a RTL script in #1 and you had to have CLDR av= ailable for that anyway.<br> <br> This is a lot like RFC 4647 matching: it isn't good enough for all scen= arios, so you might need customized or more ambitious matching algorithms f= or those, but for many simpler cases it's just fine. But it DOES exist = and there's no need to pretend it doesn't and invent another basic = scheme.<br></blockquote><div><br></div><div class=3D"gmail_default" style= =3D"font-family:"times new roman",serif">There are Suppress-Scrip= t values for 134 languages, while there are 1,320 language-script values in= CLDR; plus it has cases where the best script depends not only on both the= language and the region (eg az-IQ).=C2=A0</div><div class=3D"gmail_default= " style=3D"font-family:"times new roman",serif"><br></div><div cl= ass=3D"gmail_default" style=3D"font-family:"times new roman",seri= f">If someone wants to limit their usage to what's in Suppress-Script, = it is up to them. But my advice (which is what I was providing) would be to= use the more complete set in CLDR.=C2=A0</div><div class=3D"gmail_default"= style=3D"font-family:"times new roman",serif"><span style=3D"fon= t-family:Arial,Helvetica,sans-serif">=C2=A0</span><br></div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-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<b= r> > mixed text. Look at the following example, using the convention that<b= r> > lowercase =3D English and uppercase=3DArabic. The majority of the text= and<br> > the first strong character are both English, but the sentence is meant= <br> > to be used in an Arabic environment, so the default paragraph<br> > embedding level needs to be RTL.<br> <br> It still doesn't sound as though inserting 'ltr' or 'rtl= 9; into the language tab would solve this problem. We have Unicode bidi con= trols for this. (I know HTML has its own tags for this, which are preferred= in that context, but the GitHub thread indicates this isn't mostly abo= ut HTML.)<br></blockquote><div><span class=3D"gmail_default" style=3D"font-= family:"times new roman",serif"></span></div><div><span class=3D"= gmail_default" style=3D"font-family:"times new roman",serif">It w= ouldn't, and as I said (how did you miss this?), I agree that having -d= - is a bad idea.</span></div><div><span class=3D"gmail_default" style=3D"fo= nt-family:"times new roman",serif"><br></span></div><div><span cl= ass=3D"gmail_default" style=3D"font-family:"times new roman",seri= f">What I was explaining was that "</span>what rendering process is li= kely to display Arabic left-to-right?<span class=3D"gmail_default" style=3D= "font-family:"times new roman",serif">" is not the right iss= ue. You don't need to know the paragraph embedding level to display pur= e Arabic. If you are curious about the BIDI algorithm, you can consult the = spec, or better yet, the W3C page on it.</span></div><div><span class=3D"gm= ail_default" style=3D"font-family:"times new roman",serif"><br></= span></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> >> 4. Scripts exist in other directionalities besides LTR and RTL...<= br> ><br> > While this is true, for the [v]ast majority of cases, LTR and RTL are<= br> > the important issues. Most computer systems don't really handle<br= > > 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> Today, yes. N years from now, when these specialized text processing system= s become mainstream, maybe it will be a different story. You don't want= to lock out that possibility by hard-coding the set of allowable values in= to the RFC for all time.<br></blockquote><div><br></div><div class=3D"gmail= _default" style=3D"font-family:"times new roman",serif">Again, -d= - is a bad idea anyway, whether or not there is a registry, or that there a= re more values at the onset. There are bigger fish to fry.</div><div class= =3D"gmail_default" style=3D"font-family:"times new roman",serif">= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"> <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 complicate= <br> > implementer's lives to no good end.<br> <br> Agreed, obviously.<br> <br> What we need to do is get together with the folks on the GitHub thread and = explain the situation to them, how this proposed solution is neither necess= ary nor sufficient, and show them the right way(s) to do what they need.<br= ></blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-fam= ily:"times new roman",serif">I think Addison and Manu will probab= ly be taking feedback from this list back into the GitHub thread.</div><div= class=3D"gmail_default" style=3D"font-family:"times new roman",s= erif"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> --<br> Doug Ewell | Thornton, CO, US | <a href=3D"http://ewellic.org" rel=3D"noref= errer" target=3D"_blank">ewellic.org</a><br> <br> <br> </blockquote></div></div> --00000000000024a81d0589e343ce-- --===============2464292825189242224== 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 --===============2464292825189242224==--