Have you thought about " Mixed language URLs " with language tags, for example:
www.zh-china/mo-mogolia/zh-county/mybusiness.com shall be able to work? Liana On Sun, 25 Nov 2001 22:56:02 +0200 <[EMAIL PROTECTED]> writes: > From a bidi perspective, URLs are not structured. A present day all > ASCII URL will be presented left-to-right, because all the > non-letters > contained within it, such as periods and slashes, are neutral and > the > directionality of the surrounding letters, i.e. LTR. Trailing digits > work out correctly too. > > When the URL, in the future when it is possible, will be entirely in > Hebrew, it will display correctly with components going from right > to > left. > > Mixed language URLs may cause some unexpected results. > > See http://www.qsm.co.il/Hebrew/HebrewTest/url.htm > > Jony Rosenne > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > On Behalf Of Eric A. Hall > > Sent: Sunday, November 25, 2001 7:43 PM > > To: liana Ye > > Cc: [EMAIL PROTECTED] > > Subject: Re: Combining characters (was: Re: [idn] hostname > > historyhell) > > > > > > > > liana Ye wrote: > > > > > I'd like to propose a more specific layering of IDN symbols: > > > > > > From the top where the user input buffer offers: > > > > > > Layer 3: label seperators and label order normalizing > > > > > > Layer 2: Bidi label normalizing (or verticle label normalizing) > > > > What is the current display order for unstructured and > > structured data in right-to-left display systems? Does > > unstructured data ("the files are on > > server1") typically flow RTL, while URLs and other structured > > data display as LTR? > > > > It seems that these questions are for the structured data > > groups to handle when they decide on an output presentation > > mechanism. But if URLs and other structured types will > > display RTL then that may affect us as well (your Layer 3 > > label ordering in particular). > > > > > Layer 1.5: diacritic marks and combining symbol normalizing > > > > > > Layer 1: IDN identifier matching or whatever comes out > > > of [nameprep]. > > > > > > The reason for Layer 1.5 is that these symbols can be > > > treated in a similar way with Han characters depending on what > > > architecture we end up with, and what ACE will be our focus. > > > > -- > > Eric A. Hall > http://www.ehsco.com/ > Internet Core Protocols > http://www.oreilly.com/catalog/coreprot/ > > >
