Make WordPress Core

Opened 11 years ago

Last modified 5 weeks ago

#6148 reopened enhancement

Internationalization of personal names

Reported by: aradams Owned by:
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Users Keywords: needs-patch 2nd-opinion needs-design-feedback
Focuses: ui Cc:


(Please excuse if this ticket lacks technical details. I am not a developer, merely an interested user.)

WordPress currently allows users to register using the fields "first name" and "last name." These terms, and the limitation of only two fields, do not allow for the differences in naming conventions worldwide. The assumptions made by WP's design not only affect its use in its base English-language version, but also hampers localization efforts.

Richard Ishida http://rishida.net/blog/?p=100 says:

"People who create web forms, databases, or ontologies in English-speaking countries are often unaware how different people’s names can be in other countries. They build their forms or databases in a way that assumes too much on the part of foreign users."


"If you do still feel you need to ask for constituent parts of a name separately, try to avoid using the labels ‘first name’ and ‘last name’, since these can be confusing for people who normally write their family name followed by given names."

Matthew Sachs also writes on this subject here: http://zevils.com/2007/12/28/internationalization-of-names/

One possible approach to internationalization of personal names might be something like this:

-- Allow for multiple name fields in user registration

-- Remove culturally-specific labels like "first name" and "last name"

-- Use the existing "display name publicly as" dropdown list to allow the user to specify the proper phrasing of his/her name

-- Allow user name sorting flexibility. Currently author lists are sorted by first name, alphabetically, which is incorrect for English and many European names. Adding a "sort name by" dropdown list would allow for more flexible sorting of names within such applications as wp_list_authors.

Attachments (4)

6148.patch (5.5 KB) - added by arealnobrainer 2 years ago.
Patch for extra user field other_name
6148.2.patch (21.6 KB) - added by arealnobrainer 2 years ago.
6148.3.patch (21.6 KB) - added by arealnobrainer 2 years ago.
6148.4.patch (15.7 KB) - added by Takahashi_Fumiki 5 weeks ago.
Integrates name fields into full_name and add extra filters.

Download all attachments as: .zip

Change History (21)

#1 @ninjaWR
11 years ago

For the first approach: what other name fields could be asked for? First, Last, and Nickname are already there, and there is also the user name, which is specified when registering (the others need to be filled in after logging in).

For the third approach: current choices (assuming each of the name fields is filled in) are 'Username', 'Nickname', 'First', 'First Last', and 'Last First'. Any suggestions for other methods that can be talked about?

For the second appraoch: 'First Name', 'Last Name', 'Nickname', and 'Display name publicly as' all use _e(), so they are translatable if someone takes the time to to so. See Translating WordPress and WordPress in Your Language for more details on that.

The fourth approach might be better in its own ticket, since it doesn't deal strictly with i18n.

#2 @aradams
11 years ago

Rather than reinvent the wheel, might we look to the hcard Microformat for ways to handle name structures? Specifically, using the n, fn, nickname, and sort-string properties:

n type:

<span class="n">
 <span class="honorific-prefix">Mr.</span>
 <span class="given-name">John</span>
 <span class="additional-name">Quinlan</span>
 <span class="family-name">Public</span>, 
 <span class="honorific-suffix">Esq.</span>

fn type:

<span class="fn">Mr. John Q. Public, Esq.</span>

nickname type:

<span class="nickname">Jim</span>, 
<span class="nickname">Jimmie</span>

sort-string type:

<span class="fn n">
 <span class="additional-name">Robert</span>
 <span class="family-name sort-string">Pau</span>
 <span class="given-name">Shou Chang</span>

I disagree that name sorting doesn't relate to i18n; one can find abundant examples of confusion arising due to cultural differences in the ways people are named. For example, with my full name: Adrienne Rice Adams. My "first" name is my given name, my "middle" name is my "maiden" name, and my "last" name is my father's family name. I live in the US, and when people find out that I kept my maiden name they want to hyphenate it so: Rice-Adams. In that case my name would sort by "R" -- but I go by Adams, so I want to be sorted by "A." In the UK, compound last names are often not hyphenated, so in the UK I could be Adrienne Rice Adams (sorted R) OR Adrienne Rice Adams (sorted A). No one but I know how to properly sort my last name, so why not ask me?

Same thing with nicknames and display names. Some people go by a nickname that has no relation to their "family" or "given" names. Some people change their name informally but not legally. In some countries the legal name is different from the everyday name. In all cases, one could easily err in assuming which names are "first," "last," the order in which they should display, and which name should be used as the sort key. Flexibility is essential.

#3 @pishmishy
11 years ago

  • Milestone 2.6 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

A colleague of mine spent a lot of time working on an international standard that included name fields. He felt that the best compromise you could come up with was "given name" and "family name" but even that won't come close to satisfying everyone. I can't think of a flexible6

I'm pretty sure that everything you want can either be done through the existing translation mechanisms (which aren't at all difficult for a non-technical user to get to grips with) or through the use of a plugins and themes. I'm pretty sure it wouldn't be difficult to simplify down to a single field if that's what you wanted.

This ticket was mentioned in Slack in #core by dshanske. View the logs.

3 years ago

2 years ago

Patch for extra user field other_name

#5 @arealnobrainer
2 years ago

  • Component changed from I18N to Users
  • Keywords bias removed
  • Resolution wontfix deleted
  • Severity changed from normal to trivial
  • Status changed from closed to reopened
  • Version set to trunk

#6 follow-ups: @johnbillion
2 years ago

  • Keywords has-patch added; personal names internationalization cultural removed
  • Version trunk deleted

@arealnobrainer It looks like you generated your patch in reverse. Could you check it, please?

Can you also provide some more information about your approach?

#7 in reply to: ↑ 6 @arealnobrainer
2 years ago

Replying to johnbillion:

@arealnobrainer It looks like you generated your patch in reverse. Could you check it, please?

Followed the description here to generate the patch... Shall check it.

Disclaimer: Havn't used git and the patch method before for submitting changes. Used to the merge request method.

Can you also provide some more information about your approach?

Disclaimer: 1st patch I ever submitted. Not used to working with the WP core files and what they contains.

As for how. I looked around too see which files contained contained the first_name, last_name fields and added a new field other_name in between. I ain't to sure I all things because the patch was generated in less than 40 minutes yesterday when attending wordcamp copenhagen 2017.

Will go through my patch later today.

#8 in reply to: ↑ 6 @arealnobrainer
2 years ago

Replying to johnbillion:

@arealnobrainer It looks like you generated your patch in reverse. Could you check it, please?

Fixed now.

Can you also provide some more information about your approach?

My way of doing it has been to look for all the possible places where is could find the field first_name and add the additional field other_name described as Additional names when described in comments etc.


Is the patch any good ?


If the patch is close to acceptable. I will be happy to write as many of the unit test to it, as I can.

Last edited 2 years ago by arealnobrainer (previous) (diff)

#9 @SergeyBiryukov
2 years ago

  • Milestone set to Awaiting Review

#10 @SergeyBiryukov
2 years ago

  • Severity changed from trivial to normal

#11 @Takahashi_Fumiki
5 weeks ago

#47522 was marked as a duplicate.

#12 @azaozz
5 weeks ago

  • Focuses ui added
  • Keywords needs-patch 2nd-opinion needs-design-feedback added; has-patch removed
  • Milestone changed from Awaiting Review to 5.3

As mentioned on #47522:

A great resource about handling personal names in forms: https://www.w3.org/International/questions/qa-personal-names.

I'd like to see the first and last name fields removed and replaced by a single field for the user's name.

A big +1 on having a single field for user's name. Makes it much simpler and clearer for all countries/locales/cultures.

Backwards compatibility can be handled by concatenating the current first-name + last-name fields, and not displaying the last-name field any more. If that "feels" too intrusive, lets change it for new users only and "grandfather" the last-name field for existing users (only if used).

Setting this tentatively for 5.3 pending a design review.

Version 2, edited 5 weeks ago by azaozz (previous) (next) (diff)

#13 follow-up: @knutsp
5 weeks ago

As long as we still will be able to:

  • Greet users by first name
  • Sort users primarily by last name, then first_name etc.

There is already two single name fields, nickname and display_name.

If the order of First name and Last name fields on the profile page are allowed to be swapped, and nickname allowed in between these for the display name option list, we are a long way to the goal, without this.

#14 in reply to: ↑ 13 @azaozz
5 weeks ago

Replying to knutsp:

Greeting people by first name is considered friendly in some cultures, but can be unacceptable, rude in others. Having the "nickname" field is great for this, would probably need a bit better explanation of how/where it is used.

Sorting is also locale specific and can get pretty complicated in some cases.

That's very well explained in the W3 article linked above :)

This ticket was mentioned in Slack in #design by azaozz. View the logs.

5 weeks ago

5 weeks ago

Integrates name fields into full_name and add extra filters.

#16 @Takahashi_Fumiki
5 weeks ago

I send a patch:

  • As sent in #47522, the user name will be generated with name parts.
  • To fix the main focus of this ticket, default name parts will be full_name.
  • Default options for display_name changed.

There still remain:

  • Non UI codes with assumptions that users must have first_name and last_name(e.g. REST API)
  • The priority of names. At least, users have nickname and display_name.
  • How to handle backward compatibility. We can update user_meta on upgrading process, but it can be brutal to generate user's full_name with first_name and last_name. Some WordPress sites have worked well with names with 2 parts.
Last edited 5 weeks ago by azaozz (previous) (diff)

#17 @azaozz
5 weeks ago

Thanks for the patch :)

it can be brutal to generate user's full_name with first_name and last_name.

Yeah, agree. Thinking the other option is better: to leave the names of existing users as they are now, but show only one name field for new users (and new installs).

Then will need some way for existing users to change/update their name, i.e. switch from two name fields to one full_name field. I've asked few people from different (non English speaking) parts of the world and most said they would update their name if they could.

This is also an opportunity to explain what the nickname is and how to use it. People that update their full names would probably be glad to learn this :)

Thinking the next step would be to decide how to handle the back-compat, and any UI for that. Then tweak the patch a bit to support it if needed.

I urge everybody that's reading this to also check the W3 article: https://www.w3.org/International/questions/qa-personal-names. It has a lot of info and some very good advice on how to properly handle personal names.

Note: See TracTickets for help on using tickets.