Quoting hal9g:

Quote:
Quoting EnryWiki:

Quote:
Quoting skipnet50:

Quote:
Smee:

For those of you know the answer let smee deal with it. I have addressed the HBC point. Try somebody you never heard of.

Three words Lavaun Vondale Elzay

Skip

That could be anything.

Yes, I think that is the point.

With two name fields, would it be Lavaun Vondale/Elzay or Lavaun/Vondale Elzay?

We solve nothing by going to two fields! 

Let alone naming them Given Name and Family Name.

Paul

But we gain going to one field then? There would be no need to parse at all

Quoting hal9g:

Quote:
With two name fields, would it be Lavaun Vondale/Elzay or Lavaun/Vondale Elzay?

One guess is as good as the other. AB/C might wrong, A/BC might wrong, and A/B/C might be wrong as well.

Quote:
We solve nothing by going to two fields! 

Well, that would make a point for going to 1 field 

However, we do not solve this case by going to two fields. But we solve other cases. At least we solve the middle name vs. double first name dilemmmas. As a bonus, we don't lose the sorting by last name. 

Quoting skipnet50:

Quote:
Three pieces of data, three fields A/B/C, more data is in the Rules.

It's just a convention, as good as any other convention.
If we get a "First Name + Middle Name" field, that A/B/C of yours would translate to AB/C, as default choice for three pieces of data (when there is no documentation and we don't have a clue).

Quoting 8ballMax:

Quote:
Quoting ya_shin:

Quote:
But we gain going to one field then? There would be no need to parse at all

True...but we lose the ability to sort on last name...win/lose

Like we can do that now, when we don't even have a clear definition of what a last name is... Some want to use the family name, some want to use the position on screen disregarding any cultural differences etc. 

I see going to 1 field as a win/win.

I like the idea of being able to have one field for the name but I don't like the idea of not being able to sort by the last name.  The arguments presented here against two name fields are quite valid - it would solve nothing.

So I'll vote to leave it as it is.

Food for thought - parsing out the first word in the name into the first name field and the last word in the name into the last name field and everything else into the middle name field would solve a lot of debates - until we run into a Von Doom that is.

Quoting EnryWiki:

Quote:
Quoting skipnet50:

Quote:
Three pieces of data, three fields A/B/C, more data is in the Rules.

It's just a convention, as good as any other convention.
If we get a "First Name + Middle Name" field, that A/B/C of yours would translate to AB/C, as default choice for three pieces of data (when there is no documentation and we don't have a clue).

Again you aren't paying attention Enry. I am not calling A/B/C anything oyther than a convention but it is a convention trhat easy to be implemented by EVERY user 100% of the time because it is simply based on the data AS DISPLAYED, Your convention does not rely on data, it relies on a cultural convention which ALL users will not have the knowledge necessary to implement and they therefore will not Contribute. I don't understand why you don't understand that problem you are tryting to create.

It's too bad you can't take disagreement, Enry. I have shot your convention full of holes repeatedly, because the A//B/C answer is based on data. Your convention coimes down to one thing and it is not based on the data, it is based on how things are done within your culture, which is fine but that is not simply based on data and requires more knowledge than simply looking at the data On screen.

For example. Let's use a famous example and forget for a moment that we all know who she is

Helena Bonham Carter via A/B/C for a user who doesn't know her (if there is such a person) she is H/B/C, and we have to fix it, by the cultural method using your two name field and this she could HB/C or H/BC. This mythical user doesn't have the information needed to solve the puzzle, he may not therefore Contribute the data at all, there is NOTHING in the On Screen data to supply him with the answer. Now apply this to someone that is near or totally unknown, what clues do we have in the data to parse it culturally.....NONE. WE DO have three fields and three pieces of data A/B/C, so we can start there simply by looking at the screen...done, nothing needed other than what is On Screen. Someone who might have information to make it A//BC or AB//C......wonderful, marvelous simply document it and we are good to go.

Skip

Quoting Martin_Zuidervliet:

Quote:
Yes, the intention of my poll is exactly that. My second option in fact suggests to merge the first and middle names, not to throw all the existing information in the middle away, and after that the remaining fields should be renamed to the names you mentioned and some database name entries need to be corrected.

Ah, then in that case I absolutely support the second option.

Any system that results in a database where the same field on some occasions contains a person's given name and on other occasions may instead contain the same person's family name (or vice versa) is inherently broken in my opinion. It completely destroys data integrity. That's what the "as shown on screen" first/middle/last system gives us.

I think that any slight complications involved in determining someone's given/family names (and I do believe it would only be very few cases where this was an issue) are far outweighed by the huge gains the change would give to database consistency.