Quoting Kathy:

Quote:
I've read these discussions many times over the years. I understand and can appreciate both sides of the issue.

Same here.

Quote:
I clearly see what each side has to say - I don't think those points to be brought to the table any more.

True.

Quote:
But, and please correct me if I'm wrong, it seems that the solution is not in our hands.

That depends what solution you're looking for. Within the constraints of the program as it stands today, Ken already provided a solution. Keep in mind that this discussion is not about a new problem that needs to be fixed, it's about a problem that Ken already provided a solution for - a solution that someone isn't happy with. That doesn't make the discussion any less worth having, I'm not saying that, but we do need to see it for what it is.

Quote:
Because the only solutions presented here that has the ability to satisfy both sides of this issue seems to require an overhaul of Ken's database.

True. Within the constraints of the program we have now, I feel that Ken has already made the one and only right decision. Wat Yves wants, can never work within the current system, which is why his request boils down to the wish for a complete program overhaul. I could support that as well, but it's something entirely different than tinkering with the rules for the current system. That, IMHO, can never work, while I do see possibilities with a complete program overhaul.

Quote:
Until that happens, the continual rehashing of the same arguments seems to me to be a waste of time and energy.

It is indeed.

Quote:
Is there a solution that satisfies both sides?

No. Certainly not without a complete program overhaul.

Quote:
Try and come up with one looking at it from others point of view.

I've been trying to look at the "bigger picture" from day one - years ago. Others, unfortunately, seem to be stuck on a few specific examples in their own profiles that they'd like to be able to handle differently, and tend to forget about the ramifications for the half a million other profiles in the database.

Quote:
I know what everyone wants - please work on the solution.

Again: there isn't one - except the solution that Ken already gave us, of course. Within the constraints of the current program, it can't be done - not succesfully, that is - any other way, IMHO.

Quoting RHo:

Quote:
Quoting CharlieM:

Quote:
And exactly how do you propose to issue a rule that can be consistently applied by all people across  "50 different languages"?

The same way we do it for title capitalisation or name parsing? Use your knowledge and document changes.

The problem with this solution is, parsing and capitalization are ignored by the CLT.  The CLT uses the 'credited as' name, which has no parsing.  FRANCOIS, Francois, francois and FrAnCoIs are all treated as the same name by the CLT.  Francois and François, for reasons only Ken knows, are not.

Quoting Kathy:

Quote:

I know what everyone wants - please work on the solution.

Antolod proposed two texts in the Rules Committee forum, that allow people non familiar to other languages to contribute without any problem, and also allow the correct spelling of names. I can agree with both of them, but nobody, except me, gave his opinion on those texts.

Quoting TheMadMartian:

Quote:
Quoting RHo:

Quote:
Quoting CharlieM:

Quote:
And exactly how do you propose to issue a rule that can be consistently applied by all people across  "50 different languages"?

The same way we do it for title capitalisation or name parsing? Use your knowledge and document changes.

The problem with this solution is, parsing and capitalization are ignored by the CLT.  The CLT uses the 'credited as' name, which has no parsing.  FRANCOIS, Francois, francois and FrAnCoIs are all treated as the same name by the CLT.  Francois and François, for reasons only Ken knows, are not.

The CLT could be changed to ignore accents. But IMO the linking system is broken beyond the CLT.

Quoting DJ Doena:

Quote:
Quoting TheMadMartian:

Quote:
Francois and François, for reasons only Ken knows, are not.

A lower-case upper-case conversion functions comes with every current programming language, just as a comparer that can ignore casing.

But to recognize that C = ç needs a comparer based on a specific culture (French, Spanish). For example, in Russian what looks like a c and a p are actually an s and an r, hence CCCP = SSSR (Soyuz Sovetskikh Sotsialisticheskikh Respublik) -> USSR (Union of Soviet Socialist Republics).

It's just very complicated and nearly impossible to program when you have to consider all languages at the same time.

The Cyrillic alphabet is beyond the scope of profiler. But for Latin characters a comparison function which ignores accents is easy to implement.

P.S. Even if profiler would support Cyrillic characters via Unicode, your example would be wrong, because the Cyrillic characters are different to the Latin ones even if they have the same look.

Quoting TheMadMartian:

Quote:

Ken was given these options.  More than a few of us agreed with them.  In fact, as surfeur often points out, Gerri agreed with them.  Ken, however, did not and, rather quickly, came in and went the other way.  That is the main reason, at least in my opinion, that people don't bother discussing a rule change...because Ken has already made the decision.

Then, in my opinion, the matter is settled.

Quoting surfeur51:

Quote:
Quoting T!M:

Quote:

It does not. Not at all. Virtually every name that consists of more than two parts have separate, non-linking entries for the same person in the database.

And virtually every accented name have separate, non-linking entries for the same person in the database. ...

Just to be complete, the problem is not just for accented names, it's the same with:
- names with different used spellings
- names with middle initials
- names with Nickname parts
...

Consequence is for all the same.