Charles Prévot (Prevot), SV/PROG - Record of Alternative Data After Merges

Sharon for the sake of not having a lot of merges again can we please go without the "strepie on the e please. Or else those who know how to will put it the one way and others the other way.

but Prevost I will say Prevot and in the name field
" spelled spelled Provo, Prevost.

Juds, in the Big Tree it is asked that you use the closest spelling of the name at the time, and if you can import (cut and paste from Wikipedia etc) the correct strepie from the original language, then you do it.

me, I can't make my keyboard put it in (don't know how) - but whenever I can find it correctly written on Google, or (as in this case) by someone here, I cut and paste it or preference it, with the thought that it only has to happen 51% of the time until bietjie vir bietjie that version 'takes over'.

Tell me about it initiating lots of new merges? I don't think I understand? Won't the merge ins happen anyway - regardless of the name difference?
Isn't it just a matter of setting the MP's one to the 'most correct' spelling, so that the Data Conflicts are more likely to be resolved in its favour? (We can lock the name field if it helps, although I would only do that if someone looked like they were deliberately messing with it.)

I added the Prevost into the aka (also know as/ alternative names field) as you and Private User were suggesting that we stick to one name (in the case of alternative spellings in that pewrson's lifetime) on the Profile Name Details - when I queried this last week. I don't mind the /Provo/Prevost alternatives put into the main name either - but I think you gals were thinking more of the appearance on Gedcoms?

I do think we need to use Prévot - the é makes no difference to searches or merges - just as long as we keep the MP as accurate as we can. I do not think of Gedcoms at all - wherever possible I do as Sharon does - copy and paste the accented name.

I think alternate names need to be added to a curator note - I don't see the point of repeating a person's Family History there - it is for helping in merges and that information is already on the profile.

Just as I see no point in adding a display name unless it needs a prefix such as Sir, Major etc.- the de Villiers numbers go into the suffix field as we asked for that field to be editable. People can select their preference for displaying names - I don't like to ignore display names because otherwise I don't see prefixes.

Yes, I use display names for that reason too, but also for a more succinct version of the name if it has become very ingewikkeld by filling in all the relevant historical data on the Profile Fields. (And, as you know - I'm a big one for those fields being filled in with historical accuracy :-)

I leave the de Villiers Palma numbers (in the suffix field) off the Display Name Versions because they don't apply to the Big Tree.

When people tag the de Villiers Palma numbers onto the surnames searches don't pick them up.

Don't pick up the surnames at all, you mean?

This was a problem recently when the numbers were added to Grundling names - they caused problems in searches.

Hopwever -I have just done an exercise with Catharina Johanna Jansen van Rensburg

I have tried adding her numbers to

1 - her surname field - ie her married name and

2 - her birth-name field - Catharina Johanna Beetge b1c5d7e7f5g1h1

The search (with out numbers) found her in both instances! So I was wrong.
Sorry!

My personal preference is still to not use the display name for this, and to use the suffix field.

Thanks for the ground-level experiment, June. It helps to know.

(The search facility has been improved recently - so that's probably why. It also means that using the middle name field for middle names, now produces perfectly good search results too.)

I agree about keeping the number in the suffix field.

I hope that the improved search also migrates to the matching - I ignore my matches list largely because I am so tired of removing matches that are so obviously wrong - different parents etc.

Good news about the middle names - I will adjust the reference page accordingly but will probably continue to add all names to the first name field as it is quicker!

Until I have confirmation that the middle names are taken into account with matches I will continue to place all names in the first name field!

Mike has told me twice now that that has changed. And I seem to recall trying it out to check that it had.

As to the matching - I agree, It's almost always a waste of time