Closed Bug 687184 Opened 14 years ago Closed 13 years ago

Change the "first name" and last name fields to more international labels like "Personal name" and "family name"

Categories

(Participation Infrastructure :: Phonebook, defect, P3)

Product:
Participation Infrastructure
Component:
Phonebook
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Tobbi, Assigned: giorgos)

References

Details

(Whiteboard: [l10n impact][UX])

No description provided.
We should change the labels accordingly and also make the user specify which his preferred name is.
Summary: Change the "first name → Change the "first name" and last name fields to more international labels like "Personal name" and "family name"
Would this be fixed via localization? en-US can be 'First Name'. Also... the profile name info is a very nuanced and complicated issue. http://www.w3.org/International/questions/qa-personal-names
(In reply to Austin King [:ozten] from comment #2) > Would this be fixed via localization? > en-US can be 'First Name'. > > Also... the profile name info is a very nuanced and complicated issue. > http://www.w3.org/International/questions/qa-personal-names Yeah, that would work as well. Cc'ing stas and milos here for their input.
Milos, Stas: ping?
Priority: -- → P3
Target Milestone: --- → 1.0
Aakash, We solved this last night on IRC with Chelsea, cmoore and mkelly. I think mkelly already pushed changes. We agreed on Full name.
The solution that mkelly went for that I found a good one was to have two fields: 'full name' and 'display name' (a.k.a. 'what should we call you?' field). One disadvantage is sorting by what in the Western cultures we call the last name. How important would sorting be in our usecase?
Target Milestone: 1.0 → 1.1
We'll be going with first and last name for 1.0 due to scheduling. This'll be on the docket for 1.1 or later depending on the solution that's figured out. Some notes: * Not having first and last name makes it harder to support portable contacts and other standards (which are English centric) * First and Last name are pretty rigid in the LDAP schema * Using a single field for name will allow other cultures and naming schemas to easily parse through information compared to First/Last.
We're code frozen and string frozen for 1.1; moving this to 1.2.
Target Milestone: 1.1 → 1.2
Whiteboard: [l10n impact]
We can totally parse out spaces in "full names" for contact purposes, but I really dislike the Western-ness of "first and last name", especially as I use my middle name all the time -- where do I put that? Or do we add another "middle name" field? I'd like to migrate everyone's first/last name into "Full name" (which would be, in LDAP, "Last name") and use "first name" as "Display name" which could also encompass nicks. That's cool, yeah? If so, I'll change the strings and write a migration for 1.2.
Assignee: nobody → tofumatt
I asked the events folks and people who deal with spreadsheet work: the feedback is that it's preferable to separate them out, but its really not that much work to separate names out by space via excel. So, using a single "full name" field works just fine and will open up more flexibility to that middle use case as well as folks with more than 3 separate words (or special characters) in their names.
<3 I love "Full name" fields. Doing right now.
Scratch that... it will take me some time to do an LDAP data migration. Moving to 1.3.
Target Milestone: 1.2 → 1.3
Whiteboard: [l10n impact] → [l10n impact][UX]
I believe Owen's already done this in the bootstrap code.
Assignee: tofumatt → owen
Aakash - actually this is not there however a lot of the back end is in place to make this easy. Once bootsrap lands we can queue this for development.
Component: mozillians.org → Phonebook
Product: Websites → Community Tools
QA Contact: mozillians-org → phonebook
Target Milestone: 1.3 → ---
Version: unspecified → other
@aakash - I remember you saying that this was a wontfix for the time being eh?
Assignee: owen → nobody
(In reply to Owen Coutts [:tallOwen] from comment #17) > @aakash - I remember you saying that this was a wontfix for the time being > eh? Nah, that was in relation to putting this into a single "full name" field. The labels should be changed to Personal and Family name.
Sorry for coming late to the discussion, but if the fields are Personal and Family name, how should the display operate for contacts lists on (say) a UK or US locale machine which contains names for people from a range of cultures with different name conventions? Applying the convention for the machine locale would not be appropriate, and having to also store a display convention flag for each contact seems far too fiddly/obscure a UI element. Other than LDAP (etc.) compatibility, is there really a need to split the name into components? -- e.g. interactive completion could be based on matching any of the words in the display name separately. Andy
Please update with final decision.
Flags: needinfo?(mozaakash)
Let's go with a full name field. Reasons are: * Mozillians are worldwide and many have names that are 3-4 words long * First/Last name columns add a step of work when trying to siphon them into other spreadsheets and lists * There's no clear benefit to separating the name for the Events or Community Management teams.
Flags: needinfo?(mozaakash)
See my comment in Bug 690510 for background on why this should be a single name field.
OK I added this to our shortlist of next tasks. We need to do this soon, it impacts fields in the API.
We now use 'display_name' in the code as a concat of first and last name. Since we are transitioning to one full name field, should we allow users to pick their own display name (i.e. how we should call them)? Example: Full Name: Joe van Hope Display Name: Joe
We already have username as a user entered field... I wound not want: Fullname Username DisplayName So I think we can convert to Full Name and use that where we currently use display_name in the code. From a user perspective nothing would change. William can you approve or add your comments?
Flags: needinfo?(williamr)
We already have username as a user entered field... I wound not want: Fullname Username DisplayName So I think we can convert to Full Name and use that where we currently use display_name in the code. From a user perspective nothing would change. William can you approve or add your comments?
+ what's the plan for the API? This change will affect the 'first_name' and 'last_name' fields of API v1. Possible solutions: * Introduce (already!) a v2 of the API with a full_name field. For v1 of the API first_name and last_name fields return the same data (or first_name contains the first word of full_name and last_name what's left) * Break the v1 of the API, remove first_name and last_name and introduce full_name.
Assignee: nobody → giorgos
Status: NEW → ASSIGNED
According to the wiki the API supports searching for first_name & last_name but does not return those specific fields, it should return display_name. Except I don't think thats currently working :) If i do an api request for myself I do not see display_name returned. I think we should adjust the API - removing first_name and last_name as search params - add full_name (note I am assuming display_name is not returned currently) - keep this a v1 api We only have 2 API users and I can let them know of the change. I think this is an exceptional change due to the bug for this being old and was not brought to our attention.
OK adding fullname in the exported data and as a search parameter.
Commits pushed to master at https://github.com/mozilla/mozillians https://github.com/mozilla/mozillians/commit/073f957c4fa019d512916530e6645157a823d85b [fix bug 687184] Concat first_name and last_name into last_name. https://github.com/mozilla/mozillians/commit/c76a10526c924edd7b4fa132a8ac1efb07618fe0 Merge pull request #366 from glogiotatidis/687184 [bug 687184] Concat first_name and last_name into last_name.
Testing this on stage. - Site works - API return tests fine Found problem searching via api. If I specify full_name=Pascal I get back what looks like un searched results. Its the same as if I did not specify this as a search.
Flags: needinfo?(williamr)
Thanks for testing Ben. Try searching with 'name' instead of full_name. I'll update the api docs to reflect this.
ok tested with 'name' works as expected
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.