Quoting TheFly:

Quote:
Quoting skipnet50:

Quote:
No it's not Fly, we tell you which set of credits to use, so you are applying an interpretation that would be against the Rules.

Please point me to the line in the rules that says "Where credits are in the film's native language but an English translation is provided, credits should only be taken from the English translation". Because I can't find it.

The Rules say to enter the credits EXACTLY.

Since they are in an alphabet that cannot be replicated in DVDP, they cannot be entered EXACTLY, therefore, they cannot be entered at all.

Your translation of those credits is just that....your translation.  It is not "exactly as credited".

Obviously, if there are no English on-screen credits, using a "translation" is certainly a better solution than leaving them blank, although technically, it is against the Rules.

Quoting hal9g:

Quote:
Enter the English credits exactly as on screen, and enter the rest that appear on screen in the native language translating them as you think right.  If you're wrong, someone else will come along to challenge you.

Quote:
Since the foreign language credits cannot be entered, exactly how do you propose to enter them?

There seems to be a contradiction here. First you say to translate the credits that are in a foreign language and enter them, then you say they cannot be entered.

There are romanisation systems for every language that uses non-roman character sets which dictate how the names are correctly expressed in the English alphabet. (Of course, in some languages there are multiple systems, but that's a different debate). This does not make any difference to the issue of name order though.

Quoting TheFly:

Quote:
Quoting Unicus69:

Quote:
I assume you mean, "where is it stated by Invelos?"  It isn't, and I never claimed it was, but Ken is a US programmer and those are normal US terms.  It took me all of 2 seconds to type 'define: middle name' in to google to find the definition.

I'm really struggling to understand how you can make a statement like the above and yet not then understand what the problem is. You have to remember that a large proportion of Profiler's userbase is not American. How can they be expected to know what a term means in the context of DVD Profiler if it is not either (a) a universally understood term like "Family Name", or (b) written in the rules?

I understand that a large portion of the userbase is not American, but they purchased an American porgram.  As such, they should adapt to the programs format.  If I purchase a Japanese program over the internet, that is written in Japanese, should I expect them to change their program so that it fits my standards?  I don't think I should.

I can't speak for other people, I can only tell you what I would do.  If it were me, and I didn't understand the concept of a 'middle name'...and let's be honest here, in the context of the program, 'middle' refers to 'middle name'...I would look it up.  If I couldn't find it here, which I really wouldn't expect to, I would look on the internet.  When I did, I came up with this definition:

Many people's names include one or more middle names, placed between the first given name and the surname. In the West, a middle name is effectively a second given name. ...

As I said before, it took me all of 2 seconds.

Quote:
Another important point is that there are users here who would argue that your defintions of First/Middle/Last are wrong, and that they do not refer to given/given/family but strictly to the order things are displayed on screen. I don't agree with this but you can't claim that your definition of those fields is something that is universally accepted here.

That is why I said, back on page 5, that we would tell people what the fields meant.  If Ken does that, this becomes a non-issue.

Quote:

Quote:
If all you get is a tickbox, and you enter the name as I outlined above, ticking the box would give you a name displayed as  'Last Name/ First Name/ Middle Name.'

But what if someone's put half of a family name into the middle name box, since it appeared "in the middle"? Then you could end up with Family/Given/Family. If you name the fields Given/Family from the start, it's clear what has to go in what box and you eliminate the data entry issue.

Again, this can be solved by a simple change to the rules indicating what each field means.  I am not a database programmer, but I am fairly certain this would require less work that it will remove a field and merge the data.

Quote:

Quote:
You have it backwards.  When you want to make a change, you don't ask what benefit is gained from keeping it the way it is.  You outline the benefits gained by making the change.  You haven't done that.

You should examine both - what are the benefits of changing, and what are the problems caused by keeping things as they are. I believe that's what I've done.

I will give you that, but I prefer to look for the simple solution.  All your 'problems' can be solved by a simple addition to the rules.  There is no need for a program change.

Quote:

Quote:
I understand that this is how you want it, and that is fine, but I will always argue against change for the sake of change...which is what I believe this to be.  But that's just me. 

I suspect we may just have to agree to disagree since we seem to be going round in circles (though isn't it good that we can discuss this without resorting to insulting each other, unlike certain others?). Yes, clearly this change is how I want it to be or I wouldn't be arguing for it, but the reason I want it like this is to provide consistency for ALL Profiler users, not just the English speakers or those in the US, or those who only ever deal with American DVD releases.

Yes, we can agree to disagree and no, I do not wish to insult you.  I have fallen into that trap in the past and it doesn't do any good.  So, yes, I agree that it is a good thing. 

Quoting Addicted2DVD:

Quote:
I don't think there is an answer to solve all problems with cast and crew names.Whether there is 2 fields or 3 fields we will have parsing problems. Some middle /2nd-3rd (and so on) given names (whatever you want to call them) can look like last/Surnames. I know some women that has legally changed their last name to their middle name so not to lose it... I also have known parents to give their child (male or female) the mother's maiden name as their middle name. When it comes to a person name there is no rule on how it can be done. So I don't see how changing to only 2 fields will help with this matter whether the names of the field is changed or not. You will still have the same data entry problems and not know for sure where to put which names for a lot of the cast/crew.

I think... if it was my program and was up to me how I personally would do it is...

1. Single Name Field... with a single name field there is no question what name goes into what field. No need to try to figure out what is the first middle or last name.

2. Rules for use... simply type what you see in the credits... as credited. If the name is not written with the English alphabet (i.e. Chinese) You write it as it is read in Chinese... if it reads as Chow Yun-Fat... that is how you put it in profiler. If it reads as Yun-Fat Chow... then that is how you put it into profiler. If you have some movies credits that reads one way... and some that read the other way... then you use the CLT to determine which is the "common name" and use the "credited As" field as needed.

I know this solution would not make as many people happy... as you would lose the ability to have names listed Last Name, First Name... but in this case I think ease of entry would be more important. Which if I am not mistaken is something even Ken said he has to stride for at times... and I personally think this is one of the places that it would be best to consider that line of thinking.

That's my on the matter for what it is worth.

I couldn't agre more. One field so you just enter what's on screen. If the Name is ABC on screen you enter that, if it's bca and you can document it's the same person use the CLT to detemine the common name and use credited as.

In my humble opinion it's the easiest solution and at the same time would terminate a lot of double entries in the DB (a/b/c = ab/c =a/bc) so you'd have  even more "linked" actor's in the DB.

Paul

Quoting Giga Wizard:

Quote:
sorry, i did not take anything out of context, You may then have noticed that:
Quoting surfeur51:

Quote:
We are in the request forum. If the request is accepted,rules will have to be changed.

I'm sorry but are you doing this simply because of the person who said it?
Did you happen to miss the "If the request is accepted" bit of the sentence?
A lot of the feature requests made would require rule changes - are you saying they're all out to destroy the rules too?

I've been trying to think of another alternative and came up with another variation that might work.

Three fields in a row, with the middle field representing the surname/family name/sorting name.  Anything that comes in front of it goes in the first field and anything after it goes into the last field.  Some examples:

Jet/Li/(blank)
Mel/Gibson/(blank)
Helena/Bonham Carter/(blank)
(blank)/Chow/Yun-fat
(blank)/Cedric the Entertainer/(blank)
Tony/Leung/Chiu-wai
Robert/Downey/Jr.
P.T./Anderson/(blank)
Sarah Michelle/Gellar/(blank)

This way, the surname has its own field, but it can be in front or behind the rest of the name without the use of a checkbox.  It also would allow us to handle Chinese names properly, since it would include the English name and the Chinese name without affecting the surname at all.

Quoting pauls42:

Quote:
Well at least you are sorry.

So much for my lame attempt at sarcasm.  Actually, I am not the least bit sorry.  I'm tired of people thinking that their way of doing things is far superior to mine -- when they have not shown any evidence that this is true.  And I'm tired of being sniped at by some angry Frenchman who doesn't like -- or intend to follow -- rules -- and then claims he is being abused when he is called out for it.  

Quoting skipnet50:

Quote:
Again, synner this undoes hundreds of thousands of man-hours work it took to get here.

Why is this a valid argument? I don't get it - we must work towards a better program and better data, and yes - that might mean replacing data with better data. If we get so attached to data that has been entered we will never move on.

Notice I am NOT arguing this specific feature request should be implemented, I am simply saying I do not agree with this specific argument used against it.