We have members who follow western naming conventions as well as members following common asian naming conventions.
Turns out there can be alot of variation on what is the convention.
https://www.asiamediacentre.org.nz/features/a-guide-to-using-asian-names
How would you handle different naming conventions, so users see their name in the order they would like?
Family, Given Given, Family
As an Asian person, don’t overthink this.
Just have fields for family name and given name to distinguish between the two.
Sure, when there’s a text field saying hello “first name last name” it might be flipped but this shouldn’t be a deal breaker or offensive in any capacity.
Worst case is you can have a toggle they can click but from a developer standpoint, that might be over engineering for something that might cause headaches later.
Good luck designing your system! Sorry I don't have any advice.
Then think about what are the requirements your system needs when it comes to names.
Does the app need to know what a user's name is at all or is a username enough? Does it need to distinguish the family part of their name for anything?
A thing I think is the most general is to just have a Full Name field (min length 1 and either John Doe or something cute as default) And a Nickname or Display Name field if your app needs to show something on screen.
But:
https://github.com/kamranahmedse/design-patterns-for-humans#...
https://www.postgresql.org/docs/current/datatype-enum.html
I'd have multiple classes handling each one a use-case, and a enum on user's record in order to specify which class to use for each, so that you can compute it from the nationality, but you could also potentially give each user the chance to set it for themselves
Though it it also may be just "given - family", as well as any other variation informally. So you wouldn't make a mistake with UI
If you truly want to cater to all kinds, just have one field for name and another for what they’d like to be addressed as.
[1]: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
One field.
Also, don't use type=number fields... the browser UX is terrible across many devices. Just make everything type=text and be done with it.
- Label the fields FAMILY, GIVEN, MIDDLE (then put them in the order you desire) - Or simply put NAME
For a LOT of use cases, FULL NAME side-steps the issue and works out great. Sure your emails that go out are "Hi {{ full_name }}," but that's okay.
I think this is to make sorting easier, since names are sorted in alphabetical order by surname then given names.
I happen to be handing that data over to airlines, which has some of the less forgiving, yet fragmented name requirements. If you handle this incorrectly, your customer can't fly, even after they paid for the flight. And for those who say that this doesn't matter as much: It absolutely does. I've seen people losing an entire trip that they saved for, all because of unclear naming requirements.
The way I deal with this is to provide a country and locale specific name fields. You don't have to detect the geolocation or track the user for this, just let them choose whatever locale setting they want, and give them the "sensible" layout. Here are some examples: - In Vietnam, we use last name then first name. - In Indonesia, we use first name, then last name, but also give an option to declare that the person doesn't have a last name. - In Singapore, we use a single field to input the first name and last name.
Even when you've handled the layout convention carefully, the 3rd party you're handing the data to, if one exists, might not give the same care and attention that you do. In my case: some airlines just haven't gotten around the idea that some people simply don't have last names. When a person with a single name wants to fly, airlines want the customer to use the name for both first and last name (e.g. If the person's name is David, then the airline expects "David David"). If you require First Name and Last Name as the input, and don't elaborate on how to fill them, the customer might simply fill the last name with a dot (".") character. The airlines / any other 3rd party won't accept that. For this, I suggest to detail out the ways in which you handle the data and go talk to your providers, if any.
All in all, it's a pretty tough challenge, and the wisdom around this isn't going to fit inside a single HN post. I do commend you for actually thinking about this problem. Good Luck.
It's common to hear "How should I address you?" This is equivalent to the people here suggesting a "nickname" field (good idea).
There are people with only one name. Don't make them double it (Ananda Ananda).
There are people with several given names. But they may only want to be called by the first, or the first two, or the last.
There are people who wish to be called by their full name. They may find it jarring to be addressed by just one piece of their name.
Finally there are people who go by a name which is not part of their legal name at all. Short forms like Bob instead of Robert, but also freeform names for various reasons, perhaps the most sensitive being that some government official may have determined their legal name contrary to their own wishes. Imagine your mother named you Sue but someone decided that must be short for Susan and put that on your government documents.
Related: when people want to show which part of their name is the family name, they either make it all uppercase or underline it. You can see this on some CVs but it happens elsewhere too when a full name is going to be read by people who don't know the addressee.
But the question sounds like there are already substantial asian users in divergent conventions without frictions. If that is what your app is trying to fix, I'm not completely sure how it will work out.
At least it should be consistent across the app.
Indian name: Sathiavelllu Arunachalam, known as SA or Seth
SE Asian ethnic Chinese names: Harry Lee Kuan Yew, (English name) (Surname) (Given name). Hated the name Harry and got it removed, though many Chinese are referred to by an English name.
Indonesian name: Fatimah Azzahra (given name only)
Malaysian name: Sharifah Azizah binti Syed Ahmad Tarmizi, (honorific surname: Sharifah) (given name: Azizah) (patronym) (father's honorific surname: Syed) (father's given name: Ahmad Tarmizi)
But still. There are often hard requirements that are impossible to reconcile with the "just store one name" idea. As an example: you need to produce alphabetically sorted lists. It would rarely be acceptable to produce lists of people sorted by their given names in Western Europe for example. So as an example if you really do need to have BOTH "Doe, John" and "John Doe" what do you do in case you know at least 99% of users will have names following this format? Do you force people to enter their name twice? In that situation I would:
- Store it as a single name column, with more columns as required (greeting, sortable, ).
- Present a UX that is appropriate for the region of 99% users. So for western Europe show a "first name", "last name", but don't store that: just set the name column to "$firstname $lastname" and the index name column to "$lastname, $firstname" and greeting to "$firstname" for example. That way I at least let 99% of your users only input the name once.
- But (and this is important) offer an alternative way of specifying it for those who don't have a name that conforms to the format. You let just that small fraction of users enter a name/indexname/greeting instead.
And yes: the above ONLY applies if it's really a hard requirement to separate them, because the last name sorting was really ya requirement. Of course there are other requirements that force other solutions. The "just one input" is the correct solution for all the cases where it is possible.
But the tl;dw is to do this:
I don't know what kind of app you're building, but unless it's 100% impossible (from a business perspective) not to separate people's names into multiple fields, you really should just make it one field.
If it's a true requirement for the business—due to a third-party vendor's requirements, for example—then I suppose you could simply ask the user which order they prefer and display their name accordingly.
Why not just have one name field, and let people type what they want in it?
Or better yet, have one field for “what should I print as the name when I send you a package or letter”, and “what would you like me to call you?” (e.g. preferred name)
Another is that my spoken/given name is after my "middle" name. Especially American forms don't deal well with that. In Sweden, you usually underline the given name, since it's used to address the person. Now I see a comment here saying that's a thing in the Philippines. That's interesting.
Not to forget the special case that people may only have one name (for which some immigration offices had to invent the rule to repeat the single name twice, as first and last name, to comply with online and offline forms that have these often mandatory fields). So we may add two patterns to your pattern list:
Only, Only
Only
Localization is tricky, not just for names, e.g. postcodes (GB) and zip codes (US) come after the city ("London SW4 0AF", "Beverly Hill, CA 90210"), in many other places before (e.g. FR, DE, e.g. "91054 Erlangen").
Do you need their legal name? As in, actually legally need it?
Realise that you'll probably need several name fields in different places depending on what you're doing, i.e. an e-commerce app may have a name to address someone by, a name on a billing address, a name on a shipping address, a name on a payment method... all of which can vary for the same person.
If all you need is a way to address them, just a single name field.
But since nobody else seems to have done so, I will. Globally, names don't follow any common format or concept at all that you can reduce to a formula. My takeaway is that it's best to have a free-format "full name" field, and another "preferred name" field so you can allow people to choose how to be referred to.
https://developer.apple.com/documentation/foundation/personn...
Sort order:
- By First Name
- By Last Name
Display order:
- First, Last
- Last, First
Obviously, users can input names in a multitude of ways. But the convention is to offer at least two distinct fields, "First name" and "Last name". The sort order determines if the items are ordered by first name or last name. And the display order determines if the full name for each item is displayed as First name and then or last name, or the other way around.And finally, set a default based by the user's locale and region.
But even in our country Firstname Lastname is prevalent among many regions and central government.
I grew up in the 90s and simply resigned that I will always be Givenname Familyname in most systems and documents.
After school I never bothered writing / typing / filling my Familyname first anywhere.
By simply staying consistent with this (wrong) way, I ensured that all my documents perfectly agree with each other. That peace of mind and lack of hassle is worth any "sacrifice" for me. Others may place different value on keeping their conventional names and must also have real reasons to do so too. I was lucky maybe, not to have those hurdles.
Here in Brazil, it is very common to have "compound names" which are just... two given names you have to use together, for example "Ana Maria", AND it is also common to have "middle names" which are neither family names, nor given. My name, for example, is Leonardo Giovanni Scur, but "Leonardo" is my given name that I respond and expect people to call me by, and "Scur" is the family name. "Giovanni" only exists in documents, basically.
So, the first question is, what are you using their names for? If you are a paid service that identifies users to other users by name, ask for a "billing name" for your legal/policy needs, and a "display name" for identification, don't attribute any structure to it. If you don't need a legally identifying name, just ask for the "display name", and let people name themselves "Sir Bearington of Nunya Biznis".
How will your app handle people with a single name? My wife's mother splits her name in two based on syllables, but that's not exactly right.
I think two fields, one mandatory -- "name" -- and other optional -- "preferred name" -- is the way to go.
You should also consider how to handle people changing names, in the events of marriage, sex change, religious conversion, or what have you.
I remember Amazon.co.jp having two name fields when you registered a new user, and in English they were called "Your name" and "Your name again", because a name pronounciation field probably makes little sense as a concept to most non-Japanese speakers.
The Indian name situation, going by initials instead, is particularly interesting. There is a famous professor I know who goes by initials because his second name is forty letters long.
https://github.com/kdeldycke/awesome-falsehood#human-identit...
1. Full legal name (as it appears in a passport, e.g. William Robert Smith)
2. Full formal name (this is how you want to be addressed and/or referred in a formal context, e.g. Dr. Professor William R. Smith, MP".
3. Abbreviated formal name (e.g. W. R. Smith)
4. Informal name (how you want to be referred/addressed in less formal context, e.g. Bill Smith)
5. Highly informal name (how you want to be addressed in close circles, e.g. Bill)
6. Nickname (e.g. Chuck)
It seems that (more or less European) convention of having first name(s) and a last/family seems have this goal: being able to store just one variant and to generate other variants (except the nickname) according to fixed rules, in other words, automatically.
Of course you should ask a user only of what you need. So if the only reason you ask for a name is to be able to address them in messages, you should ask "how you would like me to call you?" or something like this.
You can give users an option to, say a check box, to indicate their names follow the "European" convention, and then give them the fields that allow to auto-generate name variants, allowing them to override if necessary.
Just my 2 cents :-)
Also, often names in Sri Lanka look like this: Rajapaksha Mudiyanselage Siril Ariyaratna. Two family names and one or two given names. Regardless of the number of fields used, displaying long names like that needs some special considerations.
Just considering other countries and languages (and not doing obviously American/English only) has made the effort considerably easier, even when other countries aren't in the radar at the time
If you need to split first, middle and last name for US government form entry you can just ask for those when you need them individually.
Full name field. (Optional) Title field. (Optional) Display name preference. (Super optional) Allow the user to duplicate ALL of these fields for EACH IANA/ISO language, eg. many people may have a Chinese or Thai name and also a separate English name with zero relation.
Read https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... and note there is an unwritten set of similar fallacies regarding signatures.