For names like Amy MacDonald since a while the program ignores the different cases: So If in a profile is Amy Macdonald, but I have her local as Amy MacDonald the name in profile gets change to the local variant. (with "D")

I would like to see it the same way for different parsings.
Til now it can happen I have got (for example)
Sheri Moon Zombie//
Sheri/Moon/Zombie
Sheri//Moon Zombie
in my database, because of the different ways someone entered it in a profile. For every different variant in a profile I download, the program adds a new variant in the local database.

I would like the program would change the variant in profile to what I have in database.
So if I have Sheri//Moon Zombie in database and I download a profile with Sheri/Moon/Zombie the entry should change to my local variant (Sheri//Moon Zombie) and not an adition of a new entry which doesn't link correct.

I think if the string of a three fields together would get compared from local to profile variant and based on that, the change would be made, could work.

I think the pro can everyone imagine, but as always there is also a con:
For different actors that really just are different because of the parsing we would need to add a Birth Year to distinguish. (But I think we do this already)
As I don't know an existing example, a fake example: Two actors with the name Hans Hermann Meier.
One parsed Hans/Hermann/Meier correctly.
Second parsed Hans//Hermann Meier correctly.
With the new system we can't make different entries for them. (Just with BY)

Second con gets the prob of Ken: To get this new feature working some kind of Tool is needed to get the local database cleaned up of the different variants. (Not every users removes those variants always or every variant)

Because I often heard of the idea of just one name field for complete name: With my suggested option we still would be able to have the different fields (sorting, ...) and we could have it local as everyone personal thinks it is correct.

Edit: Would wonder if this would have never been suggested.

Quoting T!M:

Quote:
Quoting VirusPil:

Quote:
For every different variant in a profile I download, the program adds a new variant in the local database.

No, it doesn't. Instead, if you already have the person in your database, any new profile you download with that person in it will automatically use the same parsing that you had in your database already.
...

Do you say if I have got profile A with Franky G// in database and I would download a profile B made by you with a Franky//G it doesn't add a new variant and uses also Franky G// in my local database?
This is what I meant and I do suggest.

Quoting T!M:

Quote:
Quoting VirusPil:

Quote:
Do you say if I have got profile A with Franky G// in database and I would download a profile B made by you with a Franky//G it doesn't add a new variant and uses also Franky G// in my local database?

That's exactly how it works, yeah. So if that's your feature request, you're in luck - it already works that way since quite a while.

As I said, that doesn't eliminate the parsing problems, though. It helps for our local databases, but not for online purposes. What we need is to have the contribution system ignore parsing differences.

What would then be a big reason to do such things?

Til it never will influence my local database, the voting and online prob isn't this big. (Since we will often don't know the correct way)

Wow, now I see a sence in cleaning up my local database. 

Many thanks for the information. 

Quoting T!M:

Quote:
Quoting VirusPil:

Quote:
What would then be a big reason to do such things?

Because of, again, the fact that the contribution system doesn't ignore parsing differences, and many users will vote against contributions because of parsing differences - with both parties claiming their way is "correct" and no way to actually reach an agreement. That's why.

I understand this, but why should this bother me if this doesn't influence my database?

With a good explanation a parsing change gets also in online database and if not (Which will often happen): This doesn't influence the users local database. So why should I waste my time with argueing then?

That's why I did this feature request: I wanted to have one point less of argueing.

Well, I voted for Other. Because I find name parsing totally useless and a complete waste of time, I want a single name field only.

Quoting surfeur51:

Quote:
Quoting VirusPil:

Quote:

So the online database parsing does just influence our local database at the first addition of a cast/crew member.

That is not exact, as I demonstrated in this post. In your local, you may have two different parsings for the same actor.
...

But in your example it was a manual addition in your local database. Not the addition of an actor made by the program.
Edit: If it was an addition by downloading a profile with a different parsing variant, then I have to go back to my original request.

Quote:
In fact, I hate everything that automatically decides at my place what has to be in my database.

The program should just change to the variant you have in database. So you'll get the parsing variant which you decide is the correct.

Quoting VirusPil:

Quote:

But in your example it was a manual addition in your local database. Not the addition of an actor made by the program.

If you have already both actors in your database, which one is chosen ? You forget that old versions of DVD profiler allowed to download differently parsed names, and, if you have not cleaned your database, you may have kept them from old profiles.

Quoting surfeur51:

Quote:
Quoting VirusPil:

Quote:

But in your example it was a manual addition in your local database. Not the addition of an actor made by the program.

If you have already both actors in your database, which one is chosen ? You forget that old versions of DVD profiler allowed to download differently parsed names, and, if you have not cleaned your database, you may have kept them from old profiles.

I know, but still thanks for the hint. I need to do a clean-up of my local database to get this working properly. (That's why I suggested in op a tool which helps me before the new system would be introduced, seems this wasn't made  )

I guess if yóu have two variants in local database it links the downloaded to the exactly matching. But I have no idea what would happen with a third variant.