This is a post I wrote for the official blog a few weeks back. I’m posting it here too since I personally found the whole topic interesting and useful.

Link to the original post here.

One of the decisions we, like almost every application, had to make, is how to structure our user data. Specifically, international names.

Many fledgling projects will just create their users database table with first_name and last_name fields without much thought. However, many names around the world will simply not fit into this structure.

Being a company focusing on internationalization, here are some things we considered when we thought about how to handle names.

Fallacies about names

Patrick McKenzie’s (of Patio11/Kalzumeus fame) now famous post, Falsehoods Programmers Believe About Names, is a great breakdown of how tricky names can be. Here are a few selected fallacies:

  • “People have last names, family names, or anything else which is shared by folks recognized as their relatives.”
  • “People have, at this point in time, exactly one canonical full name.”
  • “People’s names are all mapped in Unicode code points.”

Names are complicated. So much so, that the W3C Internationalization Guide has a long section about how names around the world work:

  • “Spanish-speaking people will commonly have two family names.”
  • “Russians use patronymics (father’s or ancestor’s name) as their middle name but also use family names, in the order givenName-patronymic-familyName.”
  • “In Thailand people have a nickname, that is usually not related to their actual name, and will generally use this name to address each other in non-formal situations.”

It is practically impossible to come up with a universal structure for storing international names.

Effects on application design

So how do we deal with name if we cannot enforce any structure? How do we send our users nice emails with their “first name” in the heading? How do we display the user’s full name if we cannot join a “last name” to a “first name”?

We deal with this by having two name fields for a user:

Display Name

The purpose of a display name is to have something we can call a user in non-formal situations. “What do your friends call you?”. The key here is that there is no enforcement on structure on this display name.

But how do you make sure users use real names?

You don’t. If a user wants to call themselves McFooBall456, that is fine. They decide how we address them, and can change the name later if they wish.

Full Name

You sometimes want to be able to use the user’s full name. We like to add an official name to any receipts we send for example.

Again, we don’t need to enforce structure. The user can add their compelete full name - including family names, titles, middle names, generational names, patronymics, or whatever they wish.

Let’s say a user has an official title in their name. If you have a title selector without their specific title, they will feel unwelcome and neglected. Having one single full name text field allows users to write their name however it is appropriate in their culture. (Alternatively put all the titles in a dropdown and watch your UX expert cry. Also see this great talk by Alice Bartlett about designing websites and forms for humans.)

Making users happy

It is easy to just build your application assuming everyone is just like you. But your users come from all around the world, from a wide varied of backgrounds and cultures. Small details like how you store names can help you delight them and make them feel welcome.