Dot-test localized TLDs (ie. the Persian one: ".آزمایشی" /dot-aazmaayeshi/) has been on the root servers for a while. Currently there's only one domain under this TLD, which is "مثال" /mesaal/. Now consider that we have a domain name, which is two of that word in a row: "مثال‌مثال" /mesaal-mesaal/. As you can see, we separate words in domain names with ZWNJ. This is something like Camel-Case in Latin script. We use ASCII dash too, but it doesn't look good for more than a couple of words. (same as English domain names, right?) OTOH, Shift+Space, the old standard way to input ZWNJ in Iranian/Persian applications, doesn't work in Windows. So, almost 99% of Iranians use Space instead of ZWNJ. (This is originally a MS disease. More info at http://zwnj.org/labels/microsoft.html ). BTW, when Iranian users want to type that address, "مثال‌مثال.آزمایشی" /mesaal-mesaal-dot-aazmaayeshi/, they use SPACE between two words that makes Firefox to start a search, instead of handling space. As Firefox wouldn't turn that "I'm Feeling Lucky" address-bar search off by default, I wanna propose to do some regex on entered URL, and make a replacement for some TLDs, like replacing SPACE with ZWNJ, *iff* there's a ".آزمایشی" or ".ir" in the URL... And here are what IRI RFC says (p12): """ Systems accepting IRIs MAY also deal with the printable characters in US-ASCII that are not allowed in URIs, namely "<", ">", '"', space, "{", "}", "|", "\", "^", and "`", in step 2 above. If these characters are found but are not converted, then the conversion SHOULD fail. """ So, I'm asking to handle space in another special way for Iranian/Persian users (maybe useful for other languages using Arabic script), based on the TLD. The regex for checking this case and/or applying the change seems so easy though. IE7's behavior when address-bar search is: ON: Starts searching if it cannot resolve the first label (before first SPACE) OFF: Makes an alert that says """Address Bar: Windows cannot find 'مثال مثال.آزمایشی'. Check the spelling and try again. [ OK ]""", which means it doesn't handle it at all, and fails.

I don't think that we want to detect the language of URL components and behave differently based on the language context in terms of how we display spaces etc. WONTFIX for now, please reopen if you disagree.