When you have an application with an intended international audience, you are likely to run into issues with names. The W3C has some interesting documentation on names, but I'm not sure how good it is UX wise to follow their suggestions.

  • The simplest option is to just force everyone to enter their display name in a Latin script. Simple and fine for people whose names are given in Latin script anyway, I can imagine this being anything from problematic (when people are for example reading the Thai version of the website), to just plain offensive to some people.

  • Another option is to allow people to enter their display name in any script that they like. While this is now simpler in not offending people, it would make it difficult for other people using the application to understand the non-Latin names. For example, most people will struggle to see the difference between "กานดา" and "กุหลาบ" (both Thai names).

  • An option which I tend to lean towards is allowing people to enter their display name in a non-Latin script, but require them to provide a Latin-script transliteration to be included into the displayed name. Using the example before, that would be like comparing "กานดา (Kanda)" and "กุหลาบ (Kulap)". The problem then becomes having many fields to be filled in when someone is creating an account, as well as having to explain what a Latin-script is in the first place.

The best option is going to be some trade-off, but without much experience in internationalised applications I would only be making a best guess given my perspective.

How would you handle this?
What experience do you have with using names in a non-Latin script?
What are some examples of how other applications have handled this?

Edit: The application itself will be international in multiple translations, but the content from all translations will be visible on every translation.

Edit 2: I'm talking about a non-unique display name here, not a username. So it's fine if there are duplicates.

  • 2
    Don't forget the threat of spoofing, the good old fashioned ՅankofAmerica.com trick. unicode characters unfortunately make it extremely easy to create an almost or exactly visually identical but distinct name, which can result in fake names, URLS ect. No easy solution but it is a complication.
    – Ben Brocka
    Oct 18, 2011 at 14:45
  • @BenBrocka This isn't for unique names, so exact duplicate names are fine (just like in Facebook or LinkedIn). But a good point if it were for unique usernames.
    – JohnGB
    Oct 18, 2011 at 14:47
  • 1
    If that's the case then I'm not sure why your second point is an issue; presumably mostly people familiar with Thai names are going to be looking at those example names, I don't think it should particularly matter if there's ambiguous names when there could also be identical names, in that case it comes down to actually knowing the person.
    – Ben Brocka
    Oct 18, 2011 at 14:53
  • @BenBrocka: Because for the app that I talking about, users create content that has their name on it. Also, a list of users will likely be shown (like the one on this site). Just because someone has a non-Latin name doesn't make them irrelevant to people with Latin-script names.
    – JohnGB
    Oct 18, 2011 at 15:24
  • 1
    It doesn't make them irrelevant, but it makes them extremely difficult to interact with, doesn't it? People that don't speak Thai will be unable to search for กานดา without having already known the name, plus it's meaningless to them, and finally almost no one has a keyboard that has access to non-latin characters for any language but their own. Keeping to latin characters vastly simplifies searching even for non-latin character users because almost none of us have the ability to easily use characters not on our keyboard or OS.
    – Ben Brocka
    Oct 18, 2011 at 20:41

5 Answers 5


I would go for the Latin and Local characters version:

  • As @slugster already mentioned, non-latin languages forced people already to choose latin usernames for interacting with English websites. Actually people are used to.
  • Another point is, that most people have westernized nicknames, because we can't pronounce Thai, Chinese, Indian correct.
  • If you know them already, how could you find them? A European is trying to identify and type a Chinese character? If the app is social, finding people is important.
  • And due to the fact, that PC-keyboards were invented in the western in many countries western keyboard layouts are used. Often there are plugins, which enable people to transfer latin characters into native characters, as I've seen in China and Thailand. ( Btw Modern Chinese is a written language in Latin characters, invented in 1950's, because of the huge amout of Chinese traditional letters - a typewriter would have hundreds of keys.)
  • You want to emphasise the local character of your app (otherwise you wouldn't ask this question) and for this goal I think having just one input field more is it worth. Call it Nickname and most people will go instinctively for Latin characters in an international app.

You haven't specified whether the app itself is international or whether it's just the users, which may make a difference in how this should be handled. Here's how I might approach it with just international users:

  • Allow any name, Latin or otherwise. Depending on the makeup of your site, I don't know that you'll run into too many conflicts where a name is incomprehensible to your users as they will tend to have contacts and interact in their own language. If, for example, your site is only in English, that will act as a filter in and of itself, so I don't think you'll have too many problems with this.

However, if you still feel like it's an issue:

  • Use something like the Google Translate API to translate the non-Latin version of the name into a Latin version. You can whitelist the Latin characters and anything that isn't in the whitelist automatically gets translated. The translated usernames can then appear like this: "กานดา (Kanda)".
  • Don't require a Latin version of the name on signup. You'll hurt your registration conversions by doing that. However, allow them to edit the automatically translated name or even turn it off. As an alternative approach, you could also do the whitelist check/translation automatically on registration through an AJAX call and allow them to edit it or turn it off immediately.

If your app is in multiple languages, again, I don't think it will be much of a problem. Users will tend to stick to their languages and if they do use another language, usually they will conform to that language's conventions. However, you could show the translated name only when they use a version of the site that isn't in their default language.

So, in short, because people generally adopt a language's practices when using that language, I don't think this is a large problem to be solved. You can translate it like I mentioned above, but I would be cautious in doing so as it just introduces additional confusion and complexity into your application. I would recommend just allowing any name by default, without the translation, automatic or otherwise.

  • Good point. The app itself will be international, which I should have stated on the question. I'll add an edit.
    – JohnGB
    Oct 19, 2011 at 21:12
  • It's an absolutely terrible idea to attempt to translate (or even transliterate which may be what you meant) people's names. You could easily end up translating into something offensive, for instance -- not to mention that the whole idea is frankly cultural imperialism. Aug 24, 2014 at 18:29

If you only ship in Latin derivative languages, then require the name to be entered in a Latin script.


In my experience, people who are proficient enough in a language to use it will adopt (or use) a name that is based on the characters of that language.

For example, think of all the Chinese or Indian people you may have worked with. When interacting with an English website, they will have an Anglicised name that they use. Even if they have kept their original name, they will have a phonetically Anglicised version of it.

Another thing to consider is whether you have people dealing with the data that is entered by the international user. If no-one is ever going to see the data (i.e. it is a login so the user can save their preferred settings) then allow them to use whatever script they like. If you will have real humans dealing with the data then it needs to be in something that they are capable of dealing with.

  • Also, it's not just people with non-latin names that use a nominative handle in Anglicised form. I've known lots of English/Australian/American people whose full name is something unwieldy and so they go by a simpler handle. Like "Enija" instead of "Eugenica".
    – Erics
    Oct 20, 2011 at 6:16

Good answers so far, but I will offer one point: in some cultures and languages, I believe it's possible to render the same names and words in multiple scripts. Unless your application can understand that two strings of completely different characters are actually identical, that might lead to duplicate or mismatched records.

But, on the other hand, if you force international users to parse non-Latin strings in the English alphabet, it's also possible for them to produce multiple transliterations (think 'Mohammed' vs 'Muhammed'). Research the practices of your user base carefully.


I would go with the "allow people to enter their display name in any script" option. You provided an example with two Thai names that look similar, but how likely is that to happen on your site.

I would guess that most international users will enter their display name in Latin characters. I always do.

You mentioned that the contnt will be translated into multiple languages. How will that translation happen? Can you use the same tool/approach for romanization (translation) of international names?

  • I didn't say that the content would be translated. Just that the application would be. The content within the application that customers create will be visible to all versions no matter what the language.
    – JohnGB
    Oct 20, 2011 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.