Rho:

I don't care about you being happy. There are things that we do that I am not happy about, or results that are yielded that I amy not be entirely pleased with but....that's the way it is, mi amigo.

Skip

Quoting Gadgeteer:

Quote:
This is ridiculous.

We cannot base the parsing of names on: "Some countries usually use this convention" or "I think it should be part of the 1st name" etc

I've said it before and I'll say it again.
This is DVD Profiler NOT Family Tree profiler.

We must come up with a standard starting point for parsing names that EVERYONE can comprehend without guesswork.

The simplest and easiest to follow is: First Name\Anything Inbetween\Last Name

If there's documentation that proves that the parsing should not be the default as above, then fine, parse it as the documentation proves. But under no circumstances should we leave parsing to guesswork. We must have a 'Standard' start point.

Please remember that a 'good' 'common' name should link the roles and be found easily when using the actor filter. No other criteria (eg Cultural Conventions) are relevant as far as the intended function of names within DVDProfiler are concerned.

If you want proper family names and forenames etc, then I suggest you look around for "Gene Profiler"

Clear, concise and 100% correct.

Two simple examples to demonstrate how easy (sometimes) it is to determine correct parsing:

The original contributor to Band of Brothers correctly entered Toby Ross Bryant as T/R/B using word counting. When auditing it, the cast list is alphabetical, by last name. Logically you would expect to find Toby Ross Bryant under the B's. Not the case, since his correct last name is Ross Bryant. T//RB is how I entered him.

The second example is Peter Youngblood Hills who is in the alphabetical cast list at the end P//YH.

Obviously, not all film cast lists are alphabetical, but that is another method of determining if the last name is indeed double-barreled.

There is no need to rename the fields in the program to correctly parse the names using either the proposed "default" parsing, or to correctly document and parse any names that can be found to be exceptions to the word counting method.

My two cents.

Quoting RHo:

Quote:
Quoting Rifter:

Quote:
Nearly everybody has a middle name

I know a lot of people which have only one given name and one family name (none of these is double barrelled).

How about quoting ALL of what I said?  Its time to get over this cultural liability.  I couldn't care less what your culture says it is.  We're talking about Profiler.  If Profiler defines it as everything in the middle then that's what it is.  You guys get all hung up over the "meaning" of 'middle name' and then turn right around and try to impose YOUR meaning on it.  It's laughable.

It is whatever we decide it is, and whatever meaning we give it in the rules.  End of story.

I've stated a discussion in the Contribution Rules Committee forum HERE to develop a rule for this.

Quoting Rifter:

Quote:
Quoting tlevel:

Quote:
I've said it before, and I'll say it again. Ken needs to make the program recognize that Rupert/Henry Penrose/Smith = Rupert/Henry/Penrose/Smith = Rupert Henry/Penrose/Smith etc. LOCALLY. Then this particular problem can go away. There for if you have it parsed as Rupert/Henry Penrose/Smith in your local database and a new profile come along with Rupert/Henry/Penrose/Smith the new parsed name won't replace the local parsed name.

And as long as people can pick whatever name they want to put in as the common name, that will never happen.  And it doesn't matter a fig in a fruit bowl if everybody somehow decided to agree on one version, that would only last until some clueless newbie comes along and tries to change it.

You didn't understand what I was getting at then. This is different than common name selection. If the program recongized that the two names were the same and only one could be added locally, then whatever you have set locally would stay as your perference.