Talk:IDNwiki

From IDNwiki

Jump to: navigation, search

Contents

[edit] Using this discussion page

Note: Please do not use this page for personal communications to other users. The sidebar article on contacting others explains how to do that. Personal notes posted on this page will be moved to the recipient's own discussion page.

If you want to contribute to a topic that is already in progress, click on the edit link next to the topic heading. Start your own text on a new line, and indent it with a colon — : — at the beginning. If you are following someone else's comments that are already indented, you can use additional colons to indent further. If you want to start a new topic of discussion, click on the tab at the top of this page that is labeled with a +. Don't forget to sign your contributions after the text by clicking on the signature icon, second from the right end of the icon bar above, or by typing four tildes ~~~~ .. --WikiSysop 07:45, 20 October 2007 (UTC)

[edit] WOW! It works for me!

I am on an Intel-based Macintosh (iMac), using the Safari browser. I get great results (full native language, non-ASCII symbols for the entire page) for Japanese, Yiddish, Greek and Cyrillic...EXCEPT for residual punycode in the Russian and Greek pages' address bar URLs: http://xn--e1afmkfd.xn--80akhbyknj4f/Заглавная_страница, and http://xn--hxajbheg2az3al.xn--jxalpdlp/Αρχική_σελίδα, respectively. I have not tried the other scripts, mainly because I cannot read them. This is a development that we have all been hoping for for some time, the first globally visible step along the path to full implementation of IDNs in the global DNS. Congratulations to the ICANN IDN team! --Steve Goldstein (ICANN Board member) 15:22, 29 September 2007 (UTC)

If you are referring to the URLs in the first column of the table, the A-labels (xn-- form of an IDN) are a deliberate part of the way they are notated, and the way they are displayed in a browser depends on its own notion of how such things are to be done. If you haven't already done so, you may wish to take a look at the relevant headings in the article on IDN basics. If anything there is unclear, please do ask further questions either on this discussion page or the one direct coupled to the other article. --Cary 17:31, 15 October 2007 (UTC)
If he said "address bar", I presume he did indeed mean the address bar at the top of the browser window. Some IDN-aware browsers will deliberately leave the address bar in Punycode (xn-- ) for domains where the browser's authors didn't trust the registry to keep out names with odd homoglyphs - typically names with mixed character sets that look deceptively similar. For instance this line of text contains both the "Раураl" and "Тоуѕ 'Я Uѕ" trademarks written in a weird mix of Western and Cyrillic fonts - can you spot which characters are the Cyrillic ones? If not, there's a risk that displaying Unicode for such a name could easily disguise a phishing site. This behaviour is therefore by design, although very browser-dependent. --Carlb 08:05, 21 October 2007 (UTC)

[edit] Typo

Hi, I noticed a typo: Hirigana should be Hiragana. Rog 15:44, 29 September 2007 (UTC)

[edit] OOPS!

One more nit: will people still have to enter "http://" in ASCII? --SteveG 16:27, 29 September 2007 (UTC)

The answer is both YES and NO.
The http is not being "internationalized" as it is specifying the protocol.
However, in all places and all browsers I have seen and tried it is not necessary to actually type in "http://" - you type in the domain name and the browser will automatically prefix with "http://".
Now this becomes a problem if you want to for example "ftp" instead of "http". This is as far as I am aware still an open question in regards to internationalization. --Tina 18:18, 15 October 2007 (UTC)
Given that most users are browsing web sites, I believe this is a minor problem. To solve it would require internationalizing the letters http and the colon and slashes. Anyone trying to access FTP using a browser type-in would certainly know enough to type ftp://, don't you think? --Burnsinternet 17:54, 17 October 2007
The greatest confusion that results from omitting the protocol designator in a URL is not with ftp — although that is not a trivial issue. It lies in the distinction between http and https, where the full and correct indication of the latter is a fundamental aspect of user security. --Cary 07:49, 18 October 2007 (UTC)

[edit] RTL scripts URL directionality problem (arabic for instance)

http://مثال.إختبار/عربي/

look at this URL (in arabic). in my computer it looks a bit awkward. it looks like :

http://path/example.test/

but it works.

this is because in arabic you read/write right to left. but it would look better if displayed :

http://عربي/مثال.إختبار

but it does not work.

IMHO, it's more readable when you preserve the left to right directionality of the path (the slashes order).

[edit] questions

  • is it the same thing in hebrew?
  • does look ugly for all arabic readers or is it just me? (cultural)
  • how is it supposed to look like in the specs? maybe it's juste a firefox2 bug (on ubuntu with a french locale)

--Slim 17:43, 15 October 2007 (UTC)

The slashes in a URL do not influence its directional properties, and any attempt to override them is asking for one form of trouble or another. I would have thought that members of right-to-left script communities would expect to see text presented in that fashion. The effect you are commenting also also appears with Hebrew script. In both cases, the protocol identifier (for example, http://) at the far left of a URL is determined by the protocol itself. --Cary 21:48, 15 October 2007 (UTC)

we should beware that is a evaluation of domain names written in other script not of all path written in arabic or hebrew. and I think that pattern http://idn.com as http://مثال.إختبار begin with protocol http is needed for insuring that url remain unifrom and avoid conflict cases. ---Rafik

Perhaps part of the issue with these is that you are mixing left-to-right text (http://) with right-to-left text (the middle-eastern domain text) in the same line of print. That always is ugly to try to edit. Translating http:// though would be a task for the browser's manufacturer, as the protocol name isn't part of the registered domain in the domain name servers. --Carlb 08:11, 21 October 2007 (UTC)

One way to sove the problem cleanly would be to have standardized protocol prefixes just transliterated into RTL scripts (currently possible for Arabic, Hebrew, Aramaic, Thaana) for at least the most common protocols; the translation should be based on an internationally approved transliteration scheme (such as UNGEGN):
http, ftp, file and mailto (these last two however are not technical acronyms but would probably need to be translated rather than just transliterated; however there's still no emergency, because email addresses have another problem: the user name part is not supposed to be handled with IDN, and not even to the UTF-8 encoding like in paths of hierarchical URI schemes).
This way, the full URI could remain written in a single direction (the slashes and colons are directionally neutral).
But there will remain the supplementary problem of paths that will still frequently need to embed parts in Latin script (notably the "file extension" part at end of the path, if it gets exposed by default on a server); however this does require a standard, as each domain/server admin can take his own local decisions about the path naming scheme, without being dependant on utI schemes. (It will be more difficult for the "username"/identity part of email addresses, due to other constraints in user registration and authentication methods or protocols, and limitations in the implementation of servers.
However I am convinced that allowing multiple ways to display the same URL would be a problem some time in the future, if this rendering of URIs depends on hosted page style (confusability by permuting labels could be used to turn users into following some malicious links).
I won't certainly propose to change anything here: the existing BiDi algorithms (as specified by Unicode) are there, and changing it would add even more problems than now.
All that is needed however is to allow proper rendering and use of parts of URLs that are not directly in control of side admins. So defining standard aliases for each script would certainly be helpful, and getting these aliases supporte officially in browsers could be done by registering them in the IANA database of URI schemes (just encode them in Unicode, using nameprep; possibly also add their Punycode'd representation, if this is technically possible for URI schemes, i.e. if they accept the presence of "--" in a protocol identifier).
Those are the good questions to submit to IANA and its participants: Can we have aliases for protocol names standardized in the database of URI schemes? Will IANA accept non Latin characters in URI schemes? How many RFCs must be updated to reflect the accepted non Latin characters? If only Latin is supported in some protocols or applications, is Punycode also suitable to bypass such ASCII-only limitation? What work will be needed in OS'es before they accept such URI scheme extension? What is the consequence for the unfinished work on IRIs?
former user deleted his own comment
Note that this is not a problem that occurs when displaying rich-text formats (like HTML/XHTML) where the presentation can be easily adapted. It will have consequences in the way plain-text formats are handled (for example in plain-text emails or documents, where the detection and presentation of an URL should remain consistant with Unicode BiDi requirements, including with linewraps if they occur). Verdy p 21:36, 29 January 2008 (UTC)
Another suggestion to avoid the mabiguous presentation of URLs: why not having alternate RTL encodings for syntaxic separator punctuation signs that have weak (context-dependant) directionality? Could existing protocols be extended so that they will accept strong-RTL versions of dot, slash, colon, percent (and also for the query parts of URLs, used in HTTP forms submitted with GET: interrogation point, equal sign, ampersand and plus)? Having to using BiDi controls in URLs seems really the worst solution. On the opposite, the protocols using these punctuations could treat them internally as equivalent aliases (which will be turned internally to ASCII, even if they are presented using strong RTL characters to match the expected semantic order required by the protocols in hierarchical URI schemes). Then why not encoding a strong-RTL version of basic ASCII? (question to ask to the Unicode TC and to ISO/IEC 10646 WG2). Verdy p 21:54, 29 January 2008 (UTC)
A more elegant solution would be a single unicode character (or symbol, or glyph, I'm not fluent in unicode) representing a protocol. the character would be directionally neutral, could be used in every script and can even be culturally neutral (ex. a globe for http). we would also get rid of "://" --Slim 17:09, 24 February 2008 (UTC)

[edit] relevant documentation

in the example above it's clear that there are two alternatives : the logical representation (in black) and the visual representation (in red) which both suit Bidi readers needs (and make my point) --Slim 23:31, 19 November 2007 (UTC)

[edit] What to use ?

http://مثال.إختبار or إختبار.مثال//:http or ثال.إختبار//:http

I can’t read it but //:http is used for example here (Scroll up to see it not down). The strange thing is they say مثال.إختبار//:http and not إختبار.مثال//:http. Time will tell but why not be more clear about it now.

The 3 possibilities:

مثال.إختبار//:http إختبار.مثال//:http http://مثال.إختبار

more on this blog --Broerse 19:21, 15 October 2007

i agree. that would solve the problem for me either (see #RTL scripts URL directionality problem (arabic for instance) previous paragraph) --Slim 19:52, 15 October 2007 (UTC)

[edit] It Sure works

Netscape 9 handles the links better than IE 6. I could click through all links in both columns with Netscape 8, but only could click through the first column with IE 6. Maybe IE 7 would behave differently.

I then copied the entire examples to Word. It recognizes the links. I then created a PDF file form the Word document. The links works fine in PDF also. I copied the links again into a Gmail message and sent it to my yahoo account. The results weren't too good: It all came out gibberish. The underlying links still worked though. Could be the mail servers could not handle the internationalized characters. The same problem I had with Spanish accented words. Some mail servers would not recognize them. Of course one needs to install international fonts to be able to view the pages correctly. That shouldn't be a problem for the people in the countries involved as they have already those fonts installed anyway.

Internationalized domains is the way forward, we should not fear. They will be hurdles to overcome, but the technology is already available to tackle these problems. Some voice their concerns of possible fraudsters using IDNs to dupe unwary internet users(English speakers I guess), but the same can also be said of some English language sites that dupe internet users, including English speakers --Finolait 04:18, 17 October 2007 (UTC)

[edit] Broken Link

The link http://gr.idn.icann.org goes to a 404 page. Should it be http://el.idn.icann.org? That does not resolve, either. --Burnsinternet 17:47, 17 October 2007

http://el.idn.icann.org is both correct and functional. --Cary 18:08, 17 October 2007 (UTC)

[edit] Invalid XHTML 1.0

former user deleted his own comments

Is there another document type that we should be declaring? (We've just been trusting MediaWiki.) We can't rewrite the href= attributes without completely revising the focus and purpose of the trial. Or can we? --Cary 13:21, 18 October 2007 (UTC)

former user deleted his own comments

The anticipated lifespan of the example.test names may not justify the creation of a public identifier, but there is probably good reason to provide this for the U-labeled production TLDs that are expected to appear during the course of next year. We'll discuss all aspects of this during the impending ICANN meeting and pick up the discussion accordingly. Thank you very much for the assistance! --Cary 09:25, 25 October 2007 (UTC)

former user deleted his own comments

[edit] Aliasing?

If the purpose of the IDN.IDN test is to prove that it can 'technically' work, does this mean that every language will have its own version of .COM, .NET, and .ORG? Or will each language version of the gTLD simply 'work' as an alias.

For example, if the domain name was in Japanese but the extension was the Russian version of .COM, would it be the same as the domain name with ascii or idn .COM: (e.g. ドメイン.ком = ドメイン.com)?

More simply, would a Russian domain name with the Russian version of .COM extension be the same as the same domain name with the ascii extension .COM (e.g. веб-сайт.ком = веб-сайт.com)?

--Burnsinternet 21:58, 19 October 2007 (UTC)

[edit] Which Language is First?

Assuming that all goes well with this test, what are the plans for gTLD? Will equivalant extensions in each chosen language be released at the same time? Or will the language extensions be released as they are approved? --Burnsinternet 00:12, 20 October 2007 (UTC)

[edit] My observations

Not sure if this is the correct place for test results, please move this if it's misplaced...

I tried the test wikis from a couple of browsers - Firefox 2 seems to handle the new URL's reasonably well, but MSIE6 in Win2000 (even with Verisign's IDNnow plugin) fails to resolve them at all. I'm also seeing some characters (depending on installed fonts) in the individual page text appear correctly in Firefox but as a series of small boxes in MSIE6.

MSIE7 isn't Win2k-compatible; I didn't try it.

I tried a few known IDN URL's in existing gTLD's including http://偽基百科.biz (uncyclopedia.tw) and http://伪基百科.biz (uncyclopedia.wikia.com), http://백괴사전.org (ko.uncyclopedia.info), http://アンサイクロペディア.com (ansaikuropedia.org) and http://ไร้สาระนุกรม.com (th.uncyclopedia.info); all of these seem to work in both of the browsers (Firefox or MSIE6+IDNnow plugin).

It would seem that Verisign's IDNnow.com plugin does *not* like the new .test domains?

I notice that Firefox's address bar displays the punycode (instead of Unicode characters) for most of these names, with the notable exception of gTLD's with the most cautious and restrictive IDN policies such as the Afilias-based .info and .org - something that predictably doesn't happen with Verisign's plugin (Verisign seems to trust .com domains for some reason). The MSIE6 plugin either displays the URL as full Unicode or refuses to resolve the address at all, no middle ground.

Including Unicode URL's in the body of an e-mail message doesn't work properly in either Thunderbird 1 or MS Outhouse Express 6 (even with the IDNnow.com plugin). The URL's look like clickable links, but clicking them gives addresses like www.%e4%be%8b%e5%ad%90.%e6%b8%ac%e8%a9%a6 (Unicode bytes all converted to hexadecimal in URL's) in Thunderbird (version 1 or 2) and www.例子.測試 (Unicode bytes misdisplayed as some other character set, likely ISO-8859, therefore unusable) from MS Outlook Express 6. Has anyone tried these with newer versions (or different manufacturers) of e-mail software?

Is there any possibility of an e-mail autoresponder being installed on any of these test domains? Without it, I see no sure way to know if I can send and receive e-mail with IDN's in the from: or to: addresses.

I'm also seeing tabs for multiple language variants on the http://例子.测试 (zh-simplified) test wiki; I presume $wgLanguage needs to be changed from "zh" to "zh-cn" in LocalSettings.php to turn off the tabs for zh-tw (Taiwan, traditional regular-script) if that's not intended to be part of the China 例子.测试 version of example.test? --Carlb 07:47, 21 October 2007 (UTC)

In brief response to two of the points made here — 1) The VeriSign plug-in for IE6 supports IDN, but that functionality has disabled for top-level labels. An alternative plugin that adds the requisite support for IDN labels on all levels is available at http://idn.isc.org/. I will add something about this to the article on IDN-aware software and will also ask the developers of both of the plug-ins if they would be interested in adding further documentation, themselves. 2) We are currently setting up e-mail reflectors in the example.test domains and expect to make them available in the next day or two. --Cary 07:18, 21 October 2007 (PDT)

[edit] E-mail test

I tried sending to one of the @example.test autoresponders from Mozilla Thunderbird 2; looks like it's not supporting IDN.

I just get an SMTP error "513 - 8-bit character in mailbox address" and my local ISP fails the outbound message - a sign that the e-mail client is sending this with U-labels still in place instead of doing any Punycode conversion on outbound.

Sending to a Punycode address instead of a human-readable Unicode equivalent gets a response, in which the return address displays as Punycode. It would appear this app knows nothing of IDN's? --Carlb 10:43, 22 October 2007 (PDT)

[edit] Outfoxing Firefox: IDN whitelisting

FYI: Firefox 2's default behaviour is to display the addresses in the address bar as Unicode only for domains that it trusts (by default, .org .info and several individual ccTLD's) and display the rest in Punycode (xn--...). This is user-configurable according to this guide.

Go to about:config in the Firefox browser. It displays a long list of settings. The ones of interest are those beginning with network.IDN.whitelist. Add to this list by right-clicking anywhere on the list and selecting "New -> Boolean". For the names, use these (one entry at a time, unfortunately) and for the values, select 'true' for each:

Preference Name Status Type Value
network.IDN.whitelist.xn--kgbechtv user set boolean true
network.IDN.whitelist.xn--0zwm56d user set boolean true
network.IDN.whitelist.xn--g6w251d user set boolean true
network.IDN.whitelist.xn--jxalpdlp user set boolean true
network.IDN.whitelist.xn--11b5bs3a9aj6g user set boolean true
network.IDN.whitelist.xn--zckzah user set boolean true
network.IDN.whitelist.xn--9t4b11yi5a user set boolean true
network.IDN.whitelist.xn--hgbk6aj7f53bba user set boolean true
network.IDN.whitelist.xn--80akhbyknj4f user set boolean true
network.IDN.whitelist.xn--hlcj6aya9esc7a user set boolean true
network.IDN.whitelist.xn--deba0ad user set boolean true

This will cause the إختبار, .测试, .測試, .δοκιμή, .परीक्षा, .テスト, .테스트, . آزمایشی, .испытание, .பரிட்சை and טעסט. test domains (respectively) to display in the Firefox addressbar as proper Unicode text. --Carlb 11:06, 21 October 2007 (PDT)

An article about configuring Firefox, written by its developers, has been on the IDNwiki from the outset. --Cary 11:37, 21 October 2007 (PDT)
Good explanation there, I'd missed that one because the only link to the page from within this wiki is in a paragraph that says "The test TLDs are being added to a whitelist of fully supported domains and can be accessed until then, but will be displayed as A-labels." --Carlb 12:01, 21 October 2007 (PDT)

[edit] Adding another language?

I'd like to add Kannada (ಕನ್ನಡ) language to the list of languages being tried out. How do I do this?--Kiranbr 07:01, 21 October 2007 (PDT)

[edit] experience with Hangul IDN

First, there are differences between Hangul IE7 and Firefox2 in terms of output of status bar and address window.

If there is "http://xn--9n2bp8q.xn--9t4b11yi5a/" as a link in web page source(html), IE7 shows "http://실례.테스트/" at status bar. That is, IE7 translates "xn--9n2bp8q" to "실례" and "xn--9t4b11yi5a" to "테스트". And then it show the translated result at status bar. But in case of Firefox2, it shows "http://xn--9n2bp8q.xn--9t4b11yi5a/" correctly at status bar.

If there is "http://실례.테스트/" as a link in web page source, IE7 show "http://실례.테스트/" correctly at status bar. But in case of Firefox2, it shows "http://xn--9n2bp8q.xn--9t4b11yi5a/" at status bar. That is, Firefox2 translates "실례" to "xn--9n2bp8q" and "테스트" to "xn--9t4b11yi5a". And then it shows the translated result at status bar.

In case that I go site "http://실례.테스트/", IE7 shows "http://실례.테스트" at address bar. But Firefox2 shows ""http://xn--9n2bp8q.xn--9t4b11yi5a/" at address bar.

If there is "http://xn--9n2bp8q.xn--9t4b11yi5a/" as a link in web page source(html, both IE7 and Firefox2 shows "http://실례.테스트/" as a output of the web page.

Second, some applications which I tested for IDN don't support IDN perfectly. The applications are Microsoft Office PowerPoint 2007, Word 2007, Outlook 2007, Hangul2005(this is the mist famous word proccessor in Korea except MS Word). For example, if I enter and copy/paste "http://실례.테스트" in PowerPoint2007, Word2007 and Outlook2007, it is interpreted as a plain text. In case of Hangul2005, only "http://" is interpreted as a clickable link and remaining part is interpreted as a plain text.

But if I enter and copy/paste "http://실례.테스트/" in all above applications, it is interpreted as a clickable link.

Finaly, there is an issue related to Hangul code. "실례.테스트" cab be written in a code for South Korea and in a code for North Korea. Can "실례.테스트" be connected to right site whatever codes are used? There are similar issues in other contries. For exmaple, 會社 can be written in a code for Chinese, in a code for Taiwanese and in a code for Japanese. --Yuyeongjae 05:31, 22 October 2007

Can you please explain what the two different Korean encoding systems are. The only character encoding that the IDN protocol uses is Unicode. Numerous other systems are in use but all need to be converted to and from Unicode before they can be applied to IDNs. Is this what you mean? If so, the necessary conversion can only be done by the respective software application (either program by program, or in a localized operating system). --Cary 23:43, 21 October 2007 (PDT)
IDN TLDs are not in the Firefox2's whitelist by default. You can find the solution on previous (above) discussion titled Outfoxing Firefox: IDN whitelisting. -- Yoshiro 17:30, 22 Octover 2007 (JST)


[edit] IDN without Africa!

Hi People! I think it's a great step that ICANN took with this project. However, once again, Africa is out of ride. None of the African languages is in the list of the 12 test languages. I don't understand why. My point should not be kept as a complain, but just as a fact! Thanks for your comments about this. Cheers --Jboko 17:30, 22 October 2007

former user deleted his own comments

It is disappointing not to see Africa's oldest alphabet (Ethiopic) included in ICANN's tests. Ethiopic (U1200-U1370) is an alphabet widely used in Ethiopia, one of the third most populous country in Africa with over 77 million inhabitants. Over 60% of the population uses this alphabet either as mother tongue or second langage. More at http://www.cyberethiopia.com/home/content/view/23/

Could you kindly include Ethiopic in the test phase? I would be more than happy to participate in the tests. example.test = ምሳሌ.ሙከራ --Kitaw 14:07, 16 November 2007

The example.test initiative was planned to include approximately two dozen test domains. This was a rough estimate based on doubling the number of scripts that had figured in the previous discussion of IDNs. The project plan was posted for public commentary in the specific expectation that language communities that had not previously been involved in preparations for the introduction of IDN on the top-level of the Domain Name System, would express their interest in participating in the current evaluation. The scripts that were included in the plan, as it was first posted, had not been selected solely on the basis of the extent of their use and cultural significance. The decisive factor was there being prior experience in use of these scripts for IDNs on lower levels of the DNS. Its top-level is not the place for the initial testing of anything — the example.test action is a technical trial and there is absolutely no assurance that any of the scripts included in it will subsequently appear in top-level domains in actual production. Similarly, scripts that do not appear here may very well appear in the production environment.
Had a request for the inclusion of Ethiopic — or any other script that does not appear here — been made during the period when the plan was open for public discussion, it would certainly have been considered very carefully. There was African representation in the various working groups that prepared the plan and Ethiopic was, in fact, one of the scripts that was considered. However, since no documentation about its use for IDNs could be found, it was deferred until the missing information could be provided, again, with every expectation that this could be part of the public feedback.
It is no longer possible to add new example.test domains to the test roster. We would, however, gladly support the communities that use Ethiopic script by establishing an area in the IDNwiki named as the other domains listed under the heading "evaluation" in the sidebar. I assume that this might take the form አማርኛ.idn.icann.org. The Amharic community would need to support the maintenance of this area of the IDNwiki under the same terms as all of the other local facets — by designating a moderator who is willing and able to assist in the translation of the parent texts which are initially prepared in English, who will track the local discussion pages to facilitate their use and reverse any vandalism, and participate in the coordinated discussion among all of the moderators to refine and evaluate the progress of the project. --Cary 11:12, 25 November 2007 (UTC)

[edit] REPORT : IDN URL Test

Firstly, I have tried three IDN links according to your instruction. I used IE 7.0 and Mozilla Firefox 2 for the test, my testing IDNs worked successfully on these browsers.

When I typed “http://실례.테스트” on the IE 7.0, it redirected to the different URL with additional URL-encoded queries: “http://실례.테스트/%ED%86%A0%EB%A1%A0:%EB%8C%80%EB%AC%B8”


But, one thing we have to pay attention to is the format of IDN URLs. In case an IDN URL is sent by qmail (eg. http://실례.테스트), the URL doesn’t always work properly on IE 7.0. Therefore, I guess that IDN still has a limitation on the specific software or computer environments.


Moreover, I wonder if IDN with sub-URL (/) or without dot (.) can meet the user’s taste and inclination.

In this respect, much should be said about comparative analysis between IDN and Netpia’s Native Language Internet Address system which is a keyword typing URL address without dot (.)

When the IDN for http://idn.icann.org is http://실례.테스트, only typing 실례 on the address bar can be redirected to the same URL in Netpia technology.

This indicates that Netpia solution not only covers the NXDOMAIN for IDN, but also handles any type of NXMOMAIN.

--Sean Kang 22:34, 23 October 2007 (PDT)Sean Kang

[edit] Russian domain (пример.испытание) fell down

Why? Is it ok? I'm very interested in Russian domains (I'm from Russia) and I would like to ask you to give us more informstion about when Russian domains become possible to registrate, how much it will cost and if there will be unregistraible domains? It will be cool, to get the answers on my e-mail (yo {dog] xalva.ru). --Eugene

There are plenty of places to register IDNs in most languages. IDNs have been available for many years. Email me with any questions, Eugene. --Burnsinternet 07:11, 26 October 2007 (UTC)
Could you tell me your e-mail here or write to yo {dog] xalva.ru? --Eugene 20:19, 2 November 2007

[edit] Delimeters

There is the conventional English/Latin(?) dot "." in the internationalized domain names, e.g. ABC.TLD to separate different levels of addresses. A local langauge keyboard may not have it as the dot is not part of every language. Is it possible to use any other delimeters as well. For Arabic script U+06D4 could be used, e.g. ABC۔TLD. --سرمد حسین October 31 2007, 14:08

Arabic full stop (U+06D4) is not treated as delimiter (label separator) in IDNA (RFC 3490). Label separators other than full stop (U+002E) defined in IDNA are ideographic full stop (U+3002), fullwidth full stop (U+FF0E), halfwidth ideographic full stop (U+FF61). Please refer to section 3 of IDNA (RFC 3490). There is IDNA update work in IETF [[1]] and you can join. -- yone 02:34, 1 November 2007 (UTC)

[edit] They all worked on Mac OSX

Hello there,

Congratulations guys.

This is a great project you guys are doing and I really hope it works out OK. Could you please email me when it's going to go live please.

I should say from the outset that I am totally a non techie so if anything goes wrong I can't usually fix it myself. But it worked beautifully for me on my Mac.

OK, first off, I have two PC's and I can write Japanese and Simplified Chinese on both of them.

1 - Mac OSX v.10.3.9 fitted with Safari browser 1.3.2 (v312.6)

2 - Windows 98SE fitted with IE6


MacResults

The links did everything perfectly on my Mac, I can click on all 33 of your links and they work, I can open new windows with all 22 links that are in the table at the bottom of your Welcome page and where I know the characters for the languages that I can write, ie, Japanese and Simplified Chinese, I can write these myself in an address bar, ie, not using your links, ie, 　例え．テスト　for Japanese and 　例子。测试　for S.Chinese and they open their respective pages pronto without me even adding in the http://www. bit. At least, that is, once I had previously opened those pages using the links from your page so I guess my writing probably found the path that had previously been opened by your links. Then I tried pasting your links into hotmail and sending mail to my hotmail and googlemail accounts and both of those operated the links from inside their respective received mails just fine.

The only thing with the Mac that didn't work was in my word processor which is called Pages. I don't know if you're familiar with this, I think it's a Mac product but it's not compatible with MS WORD and though it will usually make URL's live inside a document so that they are clickable and accessible from inside that doc, when I paste any of your links into a Pages doc they dont go live and they aren't clickable at all. I've never used another browser on the Mac so I can't comment on that, sorry.


Windows PC results.

Nothing worked here, not in the browser, not in my version of MS WORD, which is 2004, and not from either of my email accounts either. I guess this machine is just too old to support this stuff or else it's pretty well fubar. I only mainly use it for watching movies and writing stuff in WORD now cos it's had some horrendous crashes in the past.

I hope that helps and that your project works fine.

--Flagrantedelicto 23:10, 14 November 2007 (UTC)

[edit] Darshi Sen IDN Test Results

[edit] Darshi Sen's IDN Testing on Microsoft Windows

I only had the opportunity to test on a Windows XP machine using two browsers, IE v6 and Firefox v2. Here are my results:

I.E. v6

  1. Clicking on links resolve to target - PASS
  2. Address bar shows resolved link in ASCII character set. - FAIL
  3. Hover over links show characters in ASCII character set in the status bar - FAIL
  4. Hover over links show characters in ASCII character set in tool tip / link description - FAIL
  5. Links on 'Evaluation' section of left navigation bar had same results - FAIL

Firefox v2

  1. Clicking on links resolve to target - PASS
  2. Address bar shows resolved link in ASCII character set. - FAIL
  3. Hover over links show characters in ASCII character set in the status bar - FAIL
  4. Hover over links show characters in ASCII character set in tool tip / link description - FAIL
  5. Links on 'Evaluation' section on left navigation bar had better results.
    1. Address bar showed resolved link in International character set - PASS
    2. Hover over links shows character in International character set - PASS

Things seem to be moving in the right direction. Adoption will be largely dependent on browser support, operating system support, font support, and character set standardization. That being said, support from all these areas seem to be getting better.

[edit] Detailed report about evaluating the Arabic test domain name against many applications in different OSs

The technical committee for the "Arabic Domain Name Pilot Project" (www.arabic-domains.org) has published a comprehensive report for evaluating the Arabic "example.test" (مثال.إختبار) domain name against many applications and in different operating systems.

The report is in English and can be found at this link [2]

for more information or clarification about the report please contact me: rfayez (at) citc . gov . sa

--Raed 05:45, 8 January 2008 (UTC)


[edit] Japanese, Korean, Simplified and Traditional Chinese example.test report

CNNIC, JPRS, NIDA and TWNIC have made a report on example.test IDN TLDs. It can be found here

Please contact Yoshiro for questions.

--Malin 10:27, 4 April 2008 (UTC)

For your convenience, JPRS put test case HTML, evaluation results record sheet template and detailed evaluation results for Japanese applications on its web site.
Japanese applications
test case HTML web browsers mail clients
results record sheet template web browsers mail clients
detailed results web browsers mail clients
-- yone 09:49, 11 April 2008 (UTC)

[edit] When can I register domain names under IDN TLDs? & "IDN ccTLD" fast track

ICANN hears this question all the time at meetings, events, in different online forums, on this wiki, and in emails and phone calls. The great challenge is it the answer isn’t the specific “as of this date” answer so many people want to hear. Because of the nature of some critical functions that still needs to be finalized, such as for example the policy process, we’re only able to provide an estimate. See more on this post at the ICANN blog at http://blog.icann.org/?p=272

--Tina 21:41, 6 February 2008 (UTC)


[edit] HINDI

IE7 Under Windows Vista, Windows Live Mail Under Windows Vista, Word 2007

Web

1) Clicking on the link - IE7 warned about a missing language. On addition of Hindi as a language it did nothing. On closing IE7 and reloading and reclicking the link, it displayed the link in correct Hindi. In both the cases the text following "/" after domain name did not display in Hindi. In both the cases it went to the correct web page.

2) Cut and Paste the link - did not show the text following "/" after domain name correctly. It went to the right page.

Email Total Failure except that on cut and paste it displayed proper Hindi. It just refused to send mail. Also it did not recognize it in the body.

Microsoft Word 2007 Total failure here. Both email and web link are not recognized.

Retrieved from "http://idn.icann.org/User_talk:Samirsshah"

--Samirsshah 08:34, 18 February 2008 (UTC)

Retrieved from "http://idn.icann.org/Talk:IDNwiki"
Personal tools