A package for presenting person names
robinvdvleuten.nlTrying to derive names is basically an impossible problem. I highly recommend the following both as arbitrary text fields:
1. Ask for "Legal Name" if you need it.
2. Ask "what would you like us to call you?"
If you are displaying users' names to others then you have infinite choices but they all boil down to "what would you like us to show in this context". The simplest is just a global name but you could have different display names towards different users/groups.
This. I can only upvote once, so I did, but this. There are about two input fields to take a name: Anything more starts making assumptions, actually, it's an assumption that everyone has one.
Your real name: Your shown name: [leave empty to use your real name]
I would be interested in seeing a "level of compliance table" of this piece of software (or its Ruby ancestor) against each of the falsehoods programmers believe about names [1]
[1] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
Seeing as it has the following code sample I'm going to guess "not well".
I mean it could be doing silly things like returning an empty last_name but why bother the user with two fields then?new PersonName($this->first_name, $this->last_name);
I think trying to split names into such parts is a losing battle. If you need to split it up ideally I think the user should have a say on how their name is presented.
Is `$name->sorted` incorrect? I would have thought it sorted on family name, not middle name?
For example, "Alice Betty Cass" should be sorted as "Cass, Alice Betty". The example given would sort it as "Betty Cass, Alice". That would only make sense if the surname was double-barrelled. e.g. Alice Betty-Cass.
...unless "Betty Cass" is a two-word, non-hyphenated surname. Yes, they also exist.
e.g. most surnames in written in Irish or Scottish Gaelic (Mac Dara) or literally any Spanish-speaking country. They exist and are extremely common.
This package is a complete waste of time, I'm sorry to say.
I'd only use something like this to fill out default name variants, and allow users to edit those variants (or have it be editable by an admin, if you're storing customer names in something that isn't directly customer-facing), considering these: https://duckduckgo.com/?q=falsehoods+programmers+believe+abo...
Already failing for East Asian names. They must start with the family name, but there's no input field for East Asian. So full is wrong.
Seems to assume a lot from https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... unfortunately. It's probably a good idea to flag it as language-specific.
Interesting that you as a Dutchman did not model Tussenvoegsel, which is unique to Anglosaksian names and in particular Dutch, Belgian and German names. Handling of them is unique within these cultures. It should also not be confused with infix.
You are totally right! But it would make the logic way more complex than it is right now. I have as "tussenvoegsel" already two words, but how to handle also last names containing two words as well.
Most of the time a distinct between first and last name is already enough for presentational purposes.
First names are not given names. Family names are not last names.
Given names are not familiar names. Given and family names are not legal names.
Please do not use 'abstractions' this broken. The appearance of patterns you're trying to abstract here are cultural windows, not global truths.
Clearly this seems to vary by the 'we' you're referring to.
The simplest solution to storing people's names is a standard character field of reasonable length. Perhaps another one for "legal name" if needed. Maintaining a `tzdata` equivalent for names is a losing battle IMHO
Ah, you poor guy, Francis Umar Cabbage Knight, your name is offensive because the machine.
I always thought his full name was David Heinemeier Hansson Jingleheimer Schmidt.