What if a last name is actually the first name? Localizing a person’s name in software
If your organization is just now dipping a toe into the global market, you may have a software product that doesn’t support Non-English users… yet. Supporting user interfaces in Spanish and Chinese is important, but it’s just one piece of localization. Your software might also need to support different date/time units, time zones, units of measurement, currencies, and identifying people by their Name.
Do you have a Surname? Or a nickname? What about a Milk Name?
Scenario
Let’s imagine your online training solution needs to capture the Name of a user to personalize the experience, but also to help a user’s supervisor track progress.
From an American standpoint (en-US), most citizens have at least two personal identifiers:
- First Name: John
- Last Name: Doe
In United Kingdom (en-GB) and Europe, these identifiers can be called:
- Given Name: John
- Surname: Doe
“OK, so different text labels for the same field, right? Cool, I’ll just localize those fields for European folks!”
That might work for many users, but it’s not without drawbacks. Instead, let’s think about a typical Mexican (es-MX) name, which can have two surnames:
- Given Name: John
- Father’s First Surname: Dorado
- Mother’s First Surname: Gonzalez
“OK, I just provide an optional field for a second Surname.”
What about Portuguese (pt-PT) and Brazilian (pt-BR) folks? For instance, footballer Cristiano Ronaldo dos Santos Aveiro!
- Given Name: Cristiano Ronaldo (?)
- Mother’s First Surname: dos Santos (?)
- Father’s First Surname: Aveiro
“OK, I’ll just provide an extra Full Name field in addition to an optional second surname.
“I’ll also add an extra Preferred Name field to handle nicknames, stage names, and maiden names! I’ve got this!”
Perhaps that will satisfy many more Western users. If the person were born into a Chinese (zh) family, there could be even more names:
- Official Name: 孫德明
- Milk Name: 孫帝象
- Courtesy Name: 孫載之
- Romanized Name: Syun Yahtsan
- Posthumous Name: 國父
“Wow! I can see the list of fields is getting bigger… How is the UI going to look?”
A new standard
You can imagine a massive list of database fields: Middle Name, Maiden Name, Prefixes, Suffixes, Pronouns… eek!
With the advent of coded character sets, anti-pattern naming will become more common. Think of the recent gender pronoun revolution.
However, there is a way to solve many problems at once.
Instead of offering the “standard” First Name and Last Name, consider two new standard fields:
- Legal Full Name — this is the opportunity for a user to input the official info they can to help distinguish them from others.
- Preferred Friendly Name — this is the opportunity for a user to input an alternate spelling, a nickname, or a professional name that differs from the legal. This field is optional.
On a web form, it would look like this:
If you had to choose one more extra field, I would recommend a Notes field for the user to type a large amount of info about their name with context. This is where personal pronoun info can go (if there isn’t another option). Keep in mind that the text might not be in English!
Consider also Name Pronunciation (because speaking a name can look vastly different from the written form). Making an audio recording tool could be a cool feature to give your users personalization!
I’ve provided an example on GitHub if you’re a developer seeking inspiration. Enjoy!
Last tips
Allow the user to input dashes, spaces, apostrophes, and all other Unicode special characters. There should be a large character limit (think 500 or more). Keep the minimum limit very very small — some people have only one character for a name: 名
As always, ask your users what problems they have with their names. This will prevent overbuild. Otherwise, your database will be filled with cruft!
Acknowledgement
I must mention the great W3 writeup by Richard Ishida: Personal Names Around the World. This is the inspiration for this article. The l10n/i18n rabbit hole only goes deeper. 🌐
