How not to be a rookie and let your users use their localised domains

In the previous article, it’s explained why you don’t want to use a localized e-mail address. This article explains the opposite – how to implement IDN in your app.

Why even bother?

You might ask, why implement something for a small fraction of users?

It is true, that in most cases it would not make a lot of sense to please someone, maybe.

But if your app targets a broad audience in many different countries, then you still might want to support people who happen to work for this company: http://中国互联网络信息中心.中国 and maybe want to sign up for your services.

The majority of the world population do not speak English. A huge number of people might not even have or like English keyboard.

Additionally, supporting it on your side is plain simple.

Web app

As mentioned in the previous article, html email validation doesn’t allow users to put localized e-mail as an input.

That might be a blocker in the registration process since not everyone is using Chrome and now everyone can convert Unicode to punycode ASCII by hand.

To fix that, simply add novalidate attribute to your <form> element. You have a server validation and your sign up form is very simple, so it won’t harm the user experience, right?

Server

Server implementation is even simpler. You just need to sanitize incoming email address by converting a right hand side (domain name) into punycode.

There is not risk of double encoding since punycode will not encode ASCII into anything else.

Second step is to make sure whenever the e-mail is shown in the UI, it would be converted to unicode again.

It can be done right before user data is sent to an app for display purposes. Ideally not sooner.

In general, it’s better to use ASCII when communicating between machines.

Further reads

http://unicode.org/faq/idn.html 
Some day browsers will implement correct email validation.

Why you don’t want e-mail in internationalised domain

1. Looks good, but not everyone can type it

You might think that “my-wörk.de” is a cool name for your website and hä[email protected]örk.de is even better (Unicode in username is currently not available), but the problem is that not everyone knows how to type umlauts.

Some people say it’s possible on Windows with an English keyboard, but I think it’s just an urban legend.

2. Sooner or later you will not register an account (or log in)

The browser support for IDN (Internationalized Domain Name) is awesome… when typing a website address in the URL bar. It’s a completely different story when speaking about forms.

Firefox and Safari send email input as a raw string (wörk stays wörk). Chrome converts the domain name to Punycode on the fly (wörk is sent to a server as “xn--wrk-sna”).

For websites which don’t support Punycode domains on the server, it’s possible to register an account using Chrome. It will be possible to log using Chrome. Except you try to log in using Chrome on iOS (it uses Safari webview).

Additionally, you might not even register an account as well if a website uses an email input type.

3. HTML “email validation” specification

In short words: HTML defines a regex for email validation. This regex doesn’t implement IDN. You will not be able to put your e-mail in an e-mail sign up form. If a website uses <input type="email" /> (which is very, very common).

Again, this doesn’t apply to Chrome on a desktop and Android which converts it on the fly.

4. Many websites and servers are not prepared for it

Even though IDN 2008 specification is made in… 2008, it’s very common that developers don’t bother supporting it. Managers don’t bother even more since it’s not common to see such domains (or 🇵🇱.to) and it’s not likely that someone would complain (except some wild external QA team).