WordPress.org

Make WordPress Core

Opened 12 years ago

Last modified 8 weeks ago

#6148 reopened enhancement

Internationalization of personal names

Reported by: aradams Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Users Keywords: 2nd-opinion needs-design-feedback has-patch has-screenshots needs-refresh
Focuses: ui Cc:
PR Number:

Description

(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."

And:

"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 (8)

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 months ago.
Integrates name fields into full_name and add extra filters.
full-name-field.png (20.7 KB) - added by azaozz 3 months ago.
An idea/example of how the "grandfathering" of First Name and Last Name fields may look in the UI
full-name-field-add-new-user.png (37.1 KB) - added by deapness 2 months ago.
All new users will only have the "Full Name" field.
full-name-field-edit-user-with-previous-settings.png (35.7 KB) - added by deapness 2 months ago.
This will only be shown for users who have data inside either first_name or last_name.
full-name-field-edit-user-without-previous-settings.png (22.0 KB) - added by deapness 2 months ago.
This is how all newly added users will look as well as users with no data inside either first_name or last_name.

Download all attachments as: .zip

Change History (33)

#1 @ninjaWR
12 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
12 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>
</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>
</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.


4 years ago

@arealnobrainer
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 ?

Version 0, edited 2 years ago by arealnobrainer (next)

#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 months ago

#47522 was marked as a duplicate.

#12 @azaozz
5 months 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 personal names: 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.

Last edited 5 months ago by azaozz (previous) (diff)

#13 follow-up: @knutsp
5 months 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 months 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 months ago

@Takahashi_Fumiki
5 months ago

Integrates name fields into full_name and add extra filters.

#16 @Takahashi_Fumiki
5 months 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 months ago by azaozz (previous) (diff)

#17 @azaozz
5 months 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.

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


3 months ago

#19 follow-up: @kjellr
3 months ago

  • Keywords needs-screenshots added

👋 Would someone mind sharing a screenshot of the changes? That will help the design team weigh in on the update.

I think the patch may need an update as well — its failing to apply cleanly at the moment. Thanks!

#20 @Mista-Flo
3 months ago

  • Keywords has-patch added; needs-patch removed

#21 in reply to: ↑ 19 @azaozz
3 months ago

Replying to kjellr:

I think the patch may need an update as well

Looking at it again, it is a solid start and fixes several issues. On the other hand thinking it would be more beneficial in the long run if we go with @johnbillion's suggestion (from #47522) and the recommendations from the W3 article about having a single "Name" field.

A bit more background:

  • In WordPress the first_name and last_name fields are optional. The users may choose to not add their name at all, or to use only one of their names.
  • In addition to the "personal" name there are three other name related settings:
    • user_login, required, non-changeable,
    • nickname, required, initially set to user_login,
    • display_name, optional, set from the user's first and last names if present, falls back to user_login.

As both first_name and last_name are optional, backwards compatibility looks straightforward. The only UI decision would be how to "show" the users that they can switch to one field for their full name. We can probably "grandfather" the two fields and show the single "Full Name" field as an alternative.

  • If both first_name and last_name are used, keep the fields and show a "Full Name" field under them as an option.
  • If only first_name or last_name is used, just show the value in the "Full Name" field.

Switching to a single "Full Name" field would also affect the display_name. The current UI there offers combinations of the first_name, last_name, and nickname fields, but would be straightforward to update to only use the value from the "Full Name" field and let the user edit it. The other name related settings remain unchanged.

In the back-end the most backwards-compatible transition would be to save the full name in first_name. As last_name is optional this would ensure all uses of the user's "formal name" (as opposed to display_name or nickname) will continue to work. Alternatively the full name can be stored in new meta but in this case all themes and plugins that use the users "formal" name(s) would need updating.

Last edited 3 months ago by azaozz (previous) (diff)

#22 @azaozz
3 months ago

Looking more at this, specifically at the transition/back-compat for existing users: perhaps best would be to add new user meta, full_name and keep showing the first_name and last_name fields in the UI as long as they are used (i.e. "gracefully" grandfather them). Any "automatic" reuse of name fields would bring edge cases. Best to let themes and plugins that use the "formal" names decide on how to use the full name instead.

For the settings UI thinking it would need a (visually separate) area where the old settings are shown.

@azaozz
3 months ago

An idea/example of how the "grandfathering" of First Name and Last Name fields may look in the UI

@deapness
2 months ago

All new users will only have the "Full Name" field.

@deapness
2 months ago

This will only be shown for users who have data inside either first_name or last_name.

@deapness
2 months ago

This is how all newly added users will look as well as users with no data inside either first_name or last_name.

#23 @deapness
2 months ago

(this is my first comment on WP Trac!)

Attached above are three screenshots to show each scenario of switching to a single "Full Name" field as @azaozz has described.

Last edited 2 months ago by deapness (previous) (diff)

#24 @desrosj
8 weeks ago

  • Keywords has-screenshots needs-refresh added; needs-screenshots removed
  • Milestone changed from 5.3 to Future Release

This one still needs design feedback and a patch refresh. I'm going to punt since the 5.3 beta deadline is only 4 days away.

#25 @azaozz
8 weeks ago

Yes, it is a large change with many usability and back-compat considerations. Perhaps there is still time to do "something" here? Maybe can still add changing of the first/last name order by a translatable string. That'd need a patch but should be quite straightforward.

Note: See TracTickets for help on using tickets.