Coding for the world, part 5: What’s in a name?

Today we cut right to the chase. In the US we are mainly on a first-name basis, but is this true for other countries, regions, and cultures? 

Customers and users are addressed, for example, in emails and welcomed on webpages. We see name fields in forms, such as contacts, and we add names to log entries. Using names seems to be straightforward and easy, but when you finish reading this post you will know better.

Naming standards vary across the globe. In some cultures, a person’s first name comes first, whereas in other cultures the last name comes first, or they have multiple first and last names. In some languages it is considered impolite to address a person by their first name, and not everyone has a middle name.

In Japanese business culture, people typically avoid using first names, even if they’ve known each other for a long time; and they add honorifics the same way one might use “sir“ or “ma’am”, but it’s not that simple. Most Spanish people have two last names, usually the first inherited from the father and the second from the mother. 

Languages are sometimes very different. In some languages names are inflected to be grammatically correct, which makes it almost impossible to code them right.

For name entry fields, many things can go wrong. Here are only a few of them: 

  • not using different UI for different cultures 
  • only allowing ASCII
  • not allowing numbers
  • setting a character limit
  • making all caps, or mid-word capitalization, invalid 

For addressing customers, you can offer the translators two variables, one for first name and another for last name. Let the localization team know if the variable can be safely removed. The linguist can then decide what to keep and how to sort them in accordance with their culture.

A fair solution:

"WelcomeHomePageFirstLast": "Welcome, {{FirstName}} {{LastName}}.",

However, this solution has risks and bears potential issues. Most translation platforms in which the translation projects are handled have strict rules applied on whether linguists are allowed to remove placeholder values. This is for obvious reasons, so that we do keep all placeholders within the translated string. The best practice to be sure is to have separate strings and apply those strings through code depending on the locale. 

Best solution: 

"WelcomeHomePageNoName": "Welcome",
"WelcomeHomePageFirstName": "Welcome, {{FirstName}}",
"WelcomeHomePageLastName": "Welcome, {{LastName}}",
"WelcomeHomePageFirstNameLastName": "Welcome, {{FirstName}} {{LastName}}",

As already mentioned, in some languages names are inflected depending on their grammatical case, such as Czech. The Czech language has seven cases (nominative, genitive, dative, accusative, vocative, locative, and instrumental). Depending on which case is used, the American tennis player Marcos Giron, for example, reads in Czech as Marcosi Gironovi or Marcosem Gironem. For those kinds of languages the NoName string would be used to eliminate friction.

Another solution could be to use the account name or the email address to address a user—or simply ask the user on how they like to be addressed.

There is no right or wrong when labeling the name entry fields, but it needs to be consistent throughout the experience: first name, given name, forename, last name, family name, surname. A thing of the past is “maiden name“, a more gender neutral term is “previous last name”: who is to say that only maids change their names?

You don’t need to reinvent the wheel, there are free tools you can use or perhaps you have a specialized team in your company that can help you.

See you in the next part when we talk about Time, money and arrangements. Until then, sunny greetings from the linguist that you can trust!

Note: Thanks to Carlos Barbero-Cortés of Docusign for consultation and feedback.

Additional resources

Bettina Becker
Bettina Becker
Sr. Language Manager
Related Topics