Alphabetizing surnames--time for a change?

[Uncle Buddy]

EDIT: This rant was largely retracted in the post below it...

I haven't spent much time thinking about this, but I've seen strong opinions from good people on both sides.

Does Dick van Dyke's surname start with a v or a D? How should it be alphabetized?

Traditionally, it seems the right way is to enter the surname as "van Dyke" but alphabetize it under D.

But the modern way in English is to alphabetize surnames the way a computer would do it if you told the computer the surname was "van Dyke" (which is correct) and didn't add a bunch of code to complicate the issue. Now that we are using computers and not index cards, it's no longer just as easy either way. It's a lot harder to alphabetize the name by "D" if the surname starts with a "v".

But how hard it is to make the code work is not the issue. The issue for me is that I'm not writing a program for Dutch genealogists. In the Dutch tradition, it's correct to alphabetize a name like this under "D". In English this tradition is passing. I say let it pass.

Then there are those who argue that a name should be alphabetized by the prefix if people tend to say it that way (no one says "Dyke" if referring to Dick van Dyke by his last name), but if people tend to say the surname without the prefix, (the way Americans say "Beethoven" for Ludwig von Beethoven), then it should be alphabetized by the main part of the surname and not the prefix. This doesn't make sense if you think about it. For one thing, Ludwig's countrymen probably said the whole name whenever referring to him by his last name. I'm just guessing. The point is that from one country to another, the tradition will be different.

To me the part that matters is consistency, and if you want consistency there has to be one simple rule that works for everything. Capitalize surnames letter by letter, ignoring spaces, apostrophes, etc. This is how Treebard will do it. It's how all modern bibliographers do it in the English language. If you have to know the national origin of the name and research how it's done in that country, then you should rightfully have to write a letter to the person who wrote the reference you're adding to the bibliography and ask him if he's an American or whether his grandparents were immigrants and from what country... get it? Having more than one rule is wrong.

If I was Dutch I'd probably swing the other way, but trying to write code that will alphabetize names properly can be straightforward. The more exceptions are made to the "one simple rule" guideline, the more people are not gonna find the name when looking for it. Which is contrary to the purpose of alphabetizing things. So why not make it straightforward? Traditions change and computers are changing traditions. Writing complex code on purpose to try and freeze time in the age of typewriters and index cards doesn't seem like a good idea.

[Uncle Buddy]

Treebard as it stands has a functioning Person Search dialog that I created when I was using a display name created by the user. One full name with which the person would be identified. I eventually got rid of this since the user should not be creating a name by which his persons are called, and because there's already a unique ID number for each person. But the code was pretty easy and the functionality was good.

Upon axing the user-defined display name I created first/middle/last/suffix fields instead and now I have a headache. In wandering the internet for ideas I came across this idea: go back to using the full name. But obviously not user-defined, that's wrong. The right way to handle names is the simplest, least restrictive way, because every culture organizes names and name parts differently. Saying that Treebard is for English speakers would be sort of a cop-out but the real problem with that stance is that whether it's true or not, Treebard would have to be re-structured for each language or set of customs--which is a terrible idea--if it were not designed flexibly from the start.

The immediate practical problem for me is that the code is bloating up and the queries are getting complicated since I stopped using a single field to store the whole name. So based on the suggestions in the w3.org link below and some issues raised by Mr. Tamura Jones' genealogy blog, here is my new plan. (The link at the bottom is for fun but it's kinda serious too. Trying to write code that manipulates name parts correctly with every name is wrong because it's impossible.)

Treebard will have a single name input for the full name and a single name input for each alternate name, spelling variation, nickname, etc. Each of the inputs that gets used will generate a sort-order input by attempting to place the parts of the input name into the right order for alphabetization. The user can use arrow keys to re-sort the auto-sort guess any way they want. The only things stored in the database will be a single full name for each name that the user inputs, and a single full sorted name for the purposes of alphabetization. But alphabetized lists will look like this...

Freda Johnson
Fred Johnston
Freddy Johnston

... instead of putting the last name first. Because some cultures don't have first/middle/last names and some cultures put them in different orders and some cultures alphabetize by the first name, etc. Flexibility is the name of the game here.

Treebard will never change anyone's capitalization from what the user input, so old-fashioned genealogists who insist on using ALL CAPS FOR SURNAMES can do so... but this is an outdated practice that I'd ban outright, except who knows, maybe there's one person in the world whose name is supposed to be written in all caps?

With this new plan I hope to eliminate any concern for punctuation inside names, whether "van" is part of the surname or a surname prefix, whether someone has two first names or two middle names, etc. etc. It's not my name so I guess it should not be my problem.

It's important that genieware does not make rules for users to follow based on how things are done in the USA, or England, or Iceland, or China, or Thailand, or Kamchatka. The only way to make a friendly portable app that everyone can use is to provide a simple user experience for most cases while allowing the user to customize input with great flexibility so that the user can define his own ways of dealing with edge cases. In this way, I don't have to guess what people are going to want to do.

My real reason for wanting separate name fields for first/middle/last names was that I had a program I liked but it wouldn't search by middle names. This was frustrating and encouraged me to list Robert Evan Jones as both Robert Evan Jones and Evan Robert Jones, which is wrong if there's no evidence that he used both name orders himself. But since my person search utility searches by any character in the name including the digits in his Treebard ID or his social security number, there's every reason I can think of to not pretend to know what a human name really is. Let the user decide.

The issue or pseudo-issue of what should be done with name parts eventually leads to the temptation to store the same name both ways in the database, first as parts and then as a computed or concatenated full name. Computed and persisted database columns are not beyond my ability but I'm going to put off learning about them as long as possible. The GPS version of Treebard is supposed to be oriented to the needs of avid genealogists who dabble in code, not avid coders who dabble in genealogy. I'll keep it that way as long as possible, while continuing to look into how Treebard Version 0+ projects should be carried out. (Not written in Python...)

www.w3.org/International/questions/qa-personal-names
www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/