Quoting skipnet50:

Quote:
They are proposing that in such a cast list, that special RULES should apply to Chow Yun Fat, even though the name appears in identical format to the the Anglican names. And they set up all sorts of straw men to support their argument.Their suggestion, however, does not apply to ALL oriental names, Bruce Li would not be Li//Bruce. The answer as I have stated is for them to deal with the issue locally in ANY way they wish, but for the Online simply follow the Rules. What is this about? They are making a big fuss about the APPEARRANCE of the name, however the Online database cannot be sorted by Actors at this time and I don't see any real need t ever be able to do that. They simply wnat it to appear culturally correct and the place for that is LOCALLY.

No, the issue as I understand it is not to fuss over the appearance of the name, but to try to standardise the online database so that each actor has one and only one entry (with "Credited As" used whenever they are credited differently, per the rules).

The only way to standardise the different naming orders is to drop the use of First/Middle/Last and rename to Given/Family. Both Western and Asian people have given and family names and it is easy to work out which is which. If the field names were changed then hopefully there could be no argument as to what goes in which field. As I've said before, an additional tickbox could then be used to indicate whether the name should be displayed as Given/Family or Family/Given.

For any profiles where the on-screen credit does not match the usual form (whether it be a different name order or a misspelling or whatever) then "Credited As" is used, as stated in the rules.

Quoting skipnet50:

Quote:
Enry:

I have also explained this before.

You make no cultural interpretation you enter Smith//John. or Doe//John.

If the credits are entirely "backwards", which I understand was being referred to, then of course we would enter John//Smith credited as Smith John. Anything else would be against the intended function.

The second paragraph posted is a tricky issue and therefore unfortunately can indeed only be handled locally at this time.

Quoting Addicted2DVD:

Quote:
Except for Ken himself has stated that the common name is not necessarily the real name... it is the most commonly credited name.

Quoting Ken Cole:

Quote:
The lookup tool is not to be blindly trusted, however it does outweigh other sources, including autographs.  The common name is not intended to always reflect the "real name", but the most commonly credited name.

However, if a user documents errors in the database where the credit is not entered properly, that can and should be considered.  Better yet, correct the entries, assuming you own the discs in question, thereby correcting the lookup results.

bold by me..
So I read that to mean it don't matter how the real name is... it matters how the person is credited the most.

Of course. This is a very important statement in regards to stage names and other aliases!

Quoting skipnet50:

Quote:
Fly:

Its why I say I am culturally blind relative to the data, or my culture is the film credits and what they say...it is all that is relevant.
Skip

It doesn't really help you are "culturally blind" when the database you enter the data in isn't.

Quoting skipnet50:

Quote:
It certainly is, Lars.

Skip

Sorry, it isn't. But that's just my opinion - and after all, I was only responsible for software localization and internationalization close to 8 years in a pretty large software company, so what would I know about that?

Quoting skipnet50:

Quote:
We don't standardize names, (...)

Yes, we do to some extent. E.g. we do standardise capitalisation of names in all caps and we do leave out affiliations.

Quoting skipnet50:

Quote:
Liike i said I recently had the occassion to have one of my foreign films come up audit and I copi4ed the credits as i saw them, I did not try to translate what i saw, nor whine about the way the filmmaker handled the names, I simply entered what I saw, diacriticals that were used and all. That is all that needs to be done..,.nothing more or less. It is a very simple procedure unless you want to make it difficult.

Except, of course, that due to the lack of support for extended character sets entering exactly what you see is impossible when the credits are in a language which doesn't use the roman alphabet, e.g. Japanese, Korean, Arabic, many of the eastern-European languages or any of the Chinese languages.

Quoting ya_shin:

Quote:

If the credits are entirely "backwards", which I understand was being referred to, then of course we would enter John//Smith credited as Smith John. Anything else would be against the intended function.

I would only enter John//Smith, id est the name on screen entered in the appropriate name fields ("Smith" in the Last name field, and so on),

not John//Smith credited as Smith John.
EDIT: The latter, by the way, would be conflicting with the CLT system.

This has got to be one of the most troubling issues we have.  It comes up time and time again, and we can never come to a common consensus on how we think it should be handled.

Getting rid of the multiple fields and going to a single field would eliminate some of the arguing we are seeing, but would generate a whole new set of arguments.  There are many reasons to have the names available in separate fields, the biggest reason for having "Last Name" separate is for sorting.  The fact that the program specifically allows for changing the displayed sequence of the names seems to support this.

One solution for this would be to add one additional field to store the actor (or crew) name in a single field exactly as displayed on the screen.  This would allow the data to be entered into that field exactly as seen on the screen with not interpretation and no parsing making it very easy to create and enforce rules.  We would still need the multiple fields so that users of the program can sort by last name.

We would still have the same challenges on how to parse the names into First, Middle and Last name fields.  But, that would only affect those users who want to make use of these fields.  If a user only cares about what is on screen, the multiple fields of the name do not have to be used or displayed.  They could also lock these fields and not worry about any ping-pong that might occur.


As I see it, we will never come to a consensus on how to parse the names and the rules are not as straightforward as some say they are.  So, this might be a reasonable compromise that wouldn't be TOO difficult for Ken to develop for us.