Quoting lmoelleb:

Quote:

Looks like a serious question to me. The Internet makes it pretty standard to target the entire world even for small programs. Targeting the "home" market only for a program distributed over the internet would be a rather odd choice in my opinion.

What, exactly, do you base this opinion on?  I encounter this situation all the time.  Just last month I was looking for some software.  After doing some research, I found the best rated one was produced by a German software company.  I went to their site, which did have an english version, and found the product I wanted.  Much to my delight, they offered the software I wanted, bundled with another title I didn't know I wanted, at a very good price.  When I tried to purchase this bundle, I was told it wasn't available to me, because I lived in the US, and the second program was only available to German customers.  So here we have a company, not only targeting their home market, but selling only to their home market, over the internet.

While you may think it is odd, it is actually quite common.  Just because something is on the Internet, doesn't mean it is designed to be sold to the whole world.

Quote:

But besides this:
1) How do you know what Ken's intended market was at release? Did I miss a comment somewhere?
2) Do you know what his intended market is now (as it is as such completely irrelevant what it was originally - it's what it is now that matters)?

1) Deductive reasoning.  Did Ken write a version in German?  French?  Mandarin?  No, he wrote it in English using American standards.  Not only in the name fields, but also in the crew credits...or have you missed all the "UK credits don't match the credits to include table" discussions?

2) Clearly Ken is willing to sell to anybody that wants to purchase his program.  That does not mean, however, that he should cater to every possible standard out there.  I guess you can expect him to, but it isn't a reasonable expectation.  JMHO

Quoting m.cellophane:

Quote:
For the record, I don't support the feature request to move from 3 fields to 1 field. And since we moved from 1 field years ago to 3 fields, I doubt that we'll go back.

With that said, I don't understand how the English/American standard argument has anything to do with this. None of us know Ken's initial intentions were with the program, but he's given every indication that he's willing and able to incorporate as much as he can in terms of other standards.

I never claimed to 'know' Ken's initial intentions.  Unless otherwise stated, what I write is simply my opinion.  This particular opinion is based on 15+ years of dealing with small software developers, but an opinion nonetheless.  I guess I will have to start adding that disclaimer to every single post I make. 

Quote:
The request can be made, as has been done by surfeur, but it's really up to Ken to decide if it's within his desire to accommodate it. But having us deduce whether it's in his intended market seems futile.

Yes, a request can be made...have I said otherwise?  But, by the same token, can't arguments against the request also be made?  I haven't asked anybody to deduce Ken's intended market.  That is something I did, based on my experience, and included as part of my argument.  If you don't agree, that is fine, but why should it matter that I chose to do so? 

Disclaimer:  The preceding statements are my opinion and, unless otherwise stated, should not be confused with a statement of fact. 

Quoting m.cellophane:

Quote:
With that said, I don't understand how the English/American standard argument has anything to do with this. None of us know Ken's initial intentions were with the program, but he's given every indication that he's willing and able to incorporate as much as he can in terms of other standards.

One of his most recent developmental posts concerns upcoming developments for expanding ratings to the standards of other localities. He has a forum here dedicated to translations. Whether he should "cater to every possible standard out there" or whether we can expect him to do it seem secondary to the fact that he does generally try to do it, based on his previous actions in this regard.

Providing translations of the existing program or adding ratings for other localities is one thing.  Modifying the structure of the database to suit the whims of a particular group is something else again.  This group expresses an arrogance that "Since I don't need or understand the concept of middle name, Ken should delete it from the database."  It's the attitude that bothers me more than the merits of the discussion.  Saying "It's only of use or interest in the US so let's get rid of it," isn't a way to convince me to buy into the new system.

Especially since no one has given a satisfactory explanation of why the problems which people are experiencing with the current structure will be improved by replacing 3 fields with 2.  Clearly the problem is with people not using the existing stucture correctly -- and it has precious little to do with how many fields there are.

Quoting Unicus69:

Quote:
Every data field has to have a label. That label has to be based on a standard of some kind.  Ken chose, not surprisingly, the American standard.  Why should he be expected to change that standard now?  Why does he have to change the program?

Maybe Ken started out with a program designed for American users and designed to American standards. Things develop... and sometimes turn out not the way they were intended to be. I am convinced Ken, and he is the only one relevant in this aspect, will listen, understand and make his decision. 

Quoting Unicus69:

Quote:
It seems I misunderstood most of your post, for that I apologize. 

[snip]

I hope that helps explain why I think, the fact that this is an American product, is relevant to this particular request.

No worries. I understand your position now. Thanks.

Quoting kdh1949:

Quote:
Providing translations of the existing program or adding ratings for other localities is one thing.  Modifying the structure of the database to suit the whims of a particular group is something else again.  This group expresses an arrogance that "Since I don't need or understand the concept of middle name, Ken should delete it from the database."  It's the attitude that bothers me more than the merits of the discussion.  Saying "It's only of use or interest in the US so let's get rid of it," isn't a way to convince me to buy into the new system.

Especially since no one has given a satisfactory explanation of why the problems which people are experiencing with the current structure will be improved by replacing 3 fields with 2.  Clearly the problem is with people not using the existing stucture correctly -- and it has precious little to do with how many fields there are.

I completely agree with your 2nd paragraph. That's exactly where I'm at on this topic too. None of the double-barreled non-hyphenated last names get fixed with the 2 field name. There will still be arguments on those. Who wants to do a big name conversion if we still have those battles? I don't.

So I have another idea to add to the mix. I use a genealogy program (Family Tree Maker). There's a convention that is used in that program which has just occurred to me could be useful here. In FTM, the last word of a name is assumed to be the surname for sorting purposes, etc. If it's a non-standard name and you need to identify the surname specifically, you put slashes around the surname, hence:

Helena /Bonham Carter/
John /Boone/ Junior
Gael /García Bernal/
EDIT: I forgot /Chow/ Yun-Fat

It's a one-field name with slashes to designate non-standard surnames. That could work for us, but until then, I prefer the 3 names we have now.

I think the checkbox idea could work to solve the problems with Asian names (and others) so I'd go with it. And I agree with northbloke that James' FTM suggestion is worth investigating, too.

Quoting northbloke:

Quote:
To summarize (cos after 15 pages it's getting pretty messy), I think it's safe to say that Surfeur's idea of removing the middle name field is unpopular and would only reduce parsing problems, not really fix them.

However, I can't remember reading any arguments against the checkbox telling the system to sort by first, not last name. That, in my opinion, is a good idea and should be investigated further.

Edit: James's suggestion of adding a special character to define the family name is also interesting.

Who want's to sort by first name, when Unicus69 tells us (and I agree) that last name means surname? The name fields are not positional.

I thought of a way to modify what I proposed (using all three fields) with the current checkbox idea.

Instead of the checkbox reversing the names, put a checkbox next to each field, with the checkbox used to represent the surname.  This allows us to keep everything the way it is, yet sort no matter where the surname is.  It even allows for those odd Chinese names that have an English first name as well.  For example, Tony Leung Chiu-wai and Tony Leung Ka-Fai.  Leung can be put in the Middle field, yet with a checkbox, sorted as the surname.  If someone has a stage name, put the check next to it.  If the Asian name goes first, put a check next to it.

When the system is implemented, we can default at the current last name (which handles most of the cast and crew) and only fix the checkboxes on those who need it.