Quoting madacid:

Quote:
Quoting Dr Pavlov:

Quote:
Mad:

How are you suggesting this would display Online. based on what I am reading, the data would not match the credit and therefore is not consistent with the Rulkes or the intent to be representative of the ACTUAL credits.

Skip

sure it would

That is not an answer. So Iwill interpret your comment as I thought, the display would funadmentally change the appearance of the data so that it does not represent the ACTUAL On Screen data, there is no such credit that I have ever seen which appears as Yun_Fat Chow, it is always Chow Yun-Fat, therefore a violation of the Rules and the intent of the Program to generate a representative appearance to the ACTUAL data, NOT an interpretation. Therefore, NO!. I am against it.

Skip

Skip

So would a simple association, surfeur. I will have to give your theory some thought, but my initial reaction that a simple association would be far more efficient. It will deal with far more than just your cultural imperative.

Skip

As I understand your tick box, surfeur, it very narrowly focused on name display.
Which doesn't help anything else.

Simple association would be used for ALL actors like the CLT. except that it is primarily a local operation, and does not impact the way the data woukld be displayed AT ALL. It would still be duisplayed consitent with the ACTUAL credited data

Ideally the data would sharable in some form but the actual linking would be done on strcitly a local level. For example a User could set up the following association

Chow Yun Fat=Chow Yun-Fat=Chow Yun Fatt=Yun-Fat Chow

If the data were Contributable of course the name of Yun-Fat Chow would have to be documented.

But once the asscociation is setup no matter which of the names the user searched on he would get the exact same set of films in his database. These could be setup to be prioritized in a number of different ways.

The checkbox however as i understand it could only be purely local as it would take the data and display it a way which is typically, not consistent with the displayed data.

As I noted in another thread this kind of reminds of arguments that could be had oover date formatting, time any argument that one might choose. Your view of a correct date is absolutely correct, but it may differ from the date standard that Program A has decided to use. Or you may like Military time while a program might use "Civilian" time. BOTH are correct, but one is the standard for the use in the Program or wherever. The standard for profiler is to list the credits EXACTLY as they appear in the credits and in the same order (this I am not referring to parsing). Thus you are correct about Yun-Fat Chow but that is not the Standard of the program, so while you are correct you are also wrong.

I am all for coming up with something that allows for the various cultural imperatives where we can, but if you are wanting to display the data in some form OTHER than the form it appears On screen then I am dead set against it and always will be because that is not the standard for Profiler. So, where are we now are we trying to come up with a way, or are we still trying to change Profiler to use the surfeur standard, not trying to insulting Yves, simply wanting to know whether we are working together or NOT.<shrugs>

Skip

As you picture indicates, yves. That is not a problem and thank you. Sometimes I have a hard time trying to visualiz what you are describing, not your fault, but that helped. As long as the data looks like it does ON Screen, that is all I want.

Skip

Quoting Dr Pavlov:

Quote:
...
That is not an answer. So Iwill interpret your comment as I thought, the display would funadmentally change the appearance of the data so that it does not represent the ACTUAL On Screen data, there is no such credit that I have ever seen which appears as Yun_Fat Chow, it is always Chow Yun-Fat, therefore a violation of the Rules and the intent of the Program to generate a representative appearance to the ACTUAL data, NOT an interpretation. Therefore, NO!. I am against it.

Skip

Skip

You misunderstood , skip.
Making it contributable makes it also in the online-DB "as on-screen". maybe you understand this fact with surfeur51's illustration.

Quoting paulb_99:

Quote:
My problem with this is you still expect people to know which name is the first name (Zhang (first name field) Ziyi (last anem field) vs Zhang (last name filed) Ziyi (first name field) (in reverse order).

So you'll still end up with different name variants with different parsing. So mu yopninio remains that a single name field crediting exactly as on screen is the best  and easiest solution.

Paul

I agree

Quoting paulb_99:

Quote:
My problem with this is you still expect people to know which name is the first name (Zhang (first name field) Ziyi (last anem field) vs Zhang (last name filed) Ziyi (first name field) (in reverse order).l

I already answered this in a previous page. For people who don't know which is the first name, they act exactly as now, and get the same result. But other users that want a correct display for asian names would be able to get it, which is not the case presently.

= no change for  users who are happy with present situation
= a major improvement for those who want a correct display for asian names.

Quoting paulb_99:

Quote:
My problem with this is you still expect people to know which name is the first name (Zhang (first name field) Ziyi (last anem field) vs Zhang (last name filed) Ziyi (first name field) (in reverse order).

If he or she contributes incorrectly (wrong flag) it either comes up in the voting process or another user will later contribute a correction. As it is with all data.