Re: URL internationalization!
Jonathan Rosenne <[email protected]> Sat, 22 Feb 1997 10:25:40 -0500
| Newsgroups | gmane.ietf.url |
|---|---|
| Message-ID | <[email protected]> |
Masataka Ohta wrote: >> There is no standard for representing Arabic or any other non-Latin script >> in English, much less in international ASCII. > >It is of course, impossible to represent Arabic language in >English, because Arabic language and English are different >languages. > >Instead, there are formal and/or informal ways to represent >English in Latin script, Arabic language in Latin script, >English in Arabic script or Arabic language in Arabic script. I doubt there is a useful way to represent Arabic in ASCII. There isn't for Hebrew, which is a much simpler case. One method which is being used is character substitution. There are two ways: - by keyboard position, i.e. Alef becomes T, Bet becomes C etc., but then ';' '.' and ',' need to be alphabetic characters. - by sequence, i.e. Bet becomes A, Gimel becomes B etc., but since Hebrew has 27 letters the Alef must be mapped to a symbol and there is no agreement to which, and in any case again it would not be recognized as alphabetic. Another possibility is transliteration, but there is no agreed scheme at all, and those proposed often use diacritics so they are not ASCII. On the internet, we should cater also for the native speaker who does not even recognize the English letters. He should be able to enter a URL in his own script, to be transformed by software into an ASCII string. Therefor we need a formal scheme which must also be reversible, i.e. one to one. A major disadvantage of 2022 is its statefulness. If the user was to cut and paste bits and pieces of the URL the software must analize the situation and insert all those escape sequences. With the proposal, if the URL is presented as is and the user grabs part of a %HH it is 1) possible to detect the error by the software and 2) a visible and obvious error. Jonathan