Date: Wed, 26 Feb 1997 11:48:11 +0100 (MET) From: "Martin J. Duerst" <email@example.com> To: Larry Masinter <firstname.lastname@example.org> Cc: email@example.com Subject: Re: URL internationalization! In-Reply-To: <331366F6.40E0@parc.xerox.com> Message-Id: <Pine.SUN.3.95q.970226113552.245F-100000@enoshima> On Tue, 25 Feb 1997, Larry Masinter wrote: > As long as we're worring about URL internationalization, > can we do something about the "http://www." prefix too? > If some users can only type in greek characters or kana/kanji, > they will not be able to type in those 7 initial latin > letters. > > When I tell people that I worked on the URL standard, they > usually complain to me about "http://www", especially about > how hard it is to pronounce. Good point, indeed. I assume that it's also English speaking people that complain about "http://www". So here the problem of internationalization is secondary. The "www" part can go away as soon as SVR DNS records are deployed. So we don't have to worry about it. Also, as soon as internationalized domain names will become possible, local conventions for "www" can develop. Also, it's interesting to note that for "www", the English are at a particular disadvantage. It's much easier to pronouce in German, for example :-). The "://" part is not a problem for those scripts that use these symbols, and for most others, it can be solved by collapsing the local equivalent of them (e.g. the full-width version in Japan). This applies for other occurences of syntax characters in URLs. The remaining "http" can be solved by omission (as many browsers do, though not a general solution, because you cannot omit both http and ftp, for example). Other solutions are to make it available via a menu, or to define local equivalents that get translated by the browser. As "http" is an opaque string even to most English speakers, it would be sufficient to define one string per script, and not per language. Regards, Martin.