Quoting EnryWiki:

Quote:
I hope that these guide lines would make everybody happy.

Not those which argue over Courteney//Cox Arquette contra Courteney/Cox/Arquette.

Quoting Unicus69:

Quote:
We have similar situations in the U.S.  'Marry Ann', 'Betty Sue', 'Peggy Sue' & 'Peggy Sue', just to name a few.  The fact that they are usually fixed double first names, however, does not mean they are always double first names.

Sure, Ann in Marry Ann can be a middle name as well. But if we know that Mary Ann is usually a fixed double first name, why should we not put Marry Ann into the first name field as a starting point?

Quoting Unicus69:

Quote:
Quoting EnryWiki:

Quote:
For an Italian  Cast/Crew member, the A/B/C parsing is most likely inaccurate (unless you can really prove it!). On the contrary, there is a number of fixed double first names that you can safely assume as such (e.g., actors Enrico Maria // Salerno, Maria Grazia // Cucinotta, and  so on), unless proven otherwise.

We have similar situations in the U.S.  'Marry Ann', 'Betty Sue', 'Peggy Sue' & 'Peggy Lee', just to name a few.  The fact that they are usually fixed double first names, however, does not mean they are always double first names.

OK.

Quote:
EDIT:  Edited for typo...I listed 'Peggy Sue' twice. 

I just love those Southern double names, BTW. 

Quote:

Quote:
Again, I am not saying that you are supposed to know about foreign names and double names all around the world!  All I am saying is that if someone else does have a clue, you leave them make use of it.

Again, I don't think anybody has a problem with that position. 

Would you also agree with those guide lines of mine, in the other post?

Quote:
The sticking point, seems to be, should those people be required to document it.

Yes, they need to document it, but strictly speaking you should document the A/B/C parsing as well.
If there is no definitive proof either way, I would go with the most likely parsing, taking into account local and national usages as well.

Quoting skipnet50:

Quote:
We have established a siimple method, Enry.

Do we? Some may agree, others disagree. Or are you talking about a different we?

Quoting skipnet50:

Quote:
We have established a siimple method, Enry. No I will not agree. Go with the simplest method and document beyond that. Just as with other such issues you and or surfeur have brought up, you seem overly concerned about stroking a nationalistic ego, I am concerned with what is EASY to entere for EVERY user EVERY time, your answer does not provide that. A/B/C is eneterable for EVERY user EVERY time and then if we can document something different we do it.<sheeeesh>

Skip

Npw that I have some timne Enry. Let me take this from the top. and I will explain my view of your position so be prepared.

My position and the position most of us have been using is A/B/C. Why...because as I have outlined it is a simple position which EVERY user can cope with EVERY time.

Am I saying not to parse it differently...absoiutely NOT!!!!!!!!!!!! I am saying that under any circumstance if you want to dep[art from the data standard, fine simply document it. Why...in the interest of ACCURACY and to provide a history which can be referred to should someone try and change it back to A/B/C. And documentation is not she's Italian so it works like this. It'ws a simple process and SHOULD satisfy everyybody while allowing ALL users to participate no matter what. That is called a compromise in the interest of the database and the Community

The position I see you & Rho saying is NO we should parse it correctly to begin with, This requires research which some users may not be real good at doing or that some others simply aren't interested in. Your position represents absolutely no compromise. Because of this I am left with two possible conclusions, (1)nationalistic ego issues or the ugly altternative (2) laziness, you want accurate data that you can download from the database but you aren't willing to provide the documentation. You either don't want to document it or you want somebody else to do it.

I frankly don't have any idea why you adopt the position that you do, because YOU are covered in the what we have been doing and BTW the reason i use nationalistic ego is because it less offensive to me than simply calling you lazy. 

Skip

       

Quoting hal9g:

Quote:
So start a poll! 

The problem is that I'm fairly sure that at least 90% of all users doesn't ever read the forums. Even if such a consensus was reached, it would really need to be addressed through a rules update, and preferably through a program update, possibly even followed by an official Invelos mailing to all users.

I've said before, and I'll say it again: I feel that as long as the fields are called "first name", "middle name" and "last name", you're going to have a lot of users that will fill those fields what what they feel are the appropriate values. If your cultural background results in you not recognising that word in the middle as a "middle name", then you won't enter it into that field. I know all the arguments against that, but it seems we're stuck with it: those field names don't really support mindless word counting. Combined with the simple fact that it's basically impossible to document "correct parsing" except for a few well-know actors, I really don't see a way out of this that a forum consensus - providing we could even actually reach one - could bring about.

We want all users to get on the same page: today, user A and user B could submit largely identical profiles for their local version of the same movie, with just a difference in parsing of a certain actor name. Result: two different entries for the same person. With no documentation available, how do I "correct" either one of these profiles? I can't prove that user A is wrong, neither can I prove that user B is wrong, so it would seem like both entries remain in the database for years to come. I really would like some input from Invelos on this.