Automatic capitalization of profile LNAB's

Question

I just had to create a new sibling profile with the correct spelling of the LNAB ( http://www.wikitree.com/wiki/Van_der_Nest-28 ) in order to correct (by eventually proposing to merge into it) the existing profile ( http://www.wikitree.com/wiki/Van_Der_Nest-26 ) according to the custom as it exists in South-Africa and the Netherlands (and a few some other countries as well) when the new father profile ( http://www.wikitree.com/wiki/Van_Der_Nest-29 ) was automatically made according to the American / International custom of spelling surnames. The parent father profile of the existing wrongly spelled profile ( http://www.wikitree.com/wiki/Van_Der_Nest-26 ) was originally [[private father]] (unless I was seeing things).

A few questions / remarks: can this automatic capitalization be avoided? Is it neccessary when no parents exist to automatically create a father profile with no birth / death data? How will this affect the patromic system of deep ancestors? (see for example http://www.wikitree.com/wiki/Lieuwes-17 ).

Comments

I'll leave the question of the automatic capitalisation for Chris to answer, since he's the one who can change these sorts of back-end things. But regarding the rest of your question, creating a new profile is not the way to change the spelling of an LNAB. That can be changed from the edit page. Adding a sibling instead has created an unnecessary duplicate for the time being, as well as creating an unnecessary Unknown Father profile.

The Unknown Father profile has to be created automatically when adding a sibling to a profile with no parents, because WikiTree does not track sibling relationships directly. Siblings are defined by sharing at least one parent, so there can be no siblings without a parent.

---

When one edits the LNAB one loses the whole history of the changes (the changes TAB is whiped clean). I was taught that merging into a duplicate was the only way unless there have been few changes in the past. When working with merged proflles (as many as two - ten or more) it is not recommended to edit the LNAB into a new LNAB. Chris had to solve a LNAB for me that went wrong when a manager tried that (editing the LNAB) with a multiple merged profile - it got stuck in a loop ...

---

About the last part of your answer: ''Siblings are defined by sharing at least one parent, so there can be no siblings without a parent.'' It still poses the problem of profiles of adopted children, illigitimate children, and the patronymic system ...

---

And it is besides a question of improvements really that old issue of automatic capitalization which I realize is not a WikiTree problem (it probably existed before WikiTree) but it is causing false LN'sAB. Imagine if it would automatically change vowels as well, say for example ''Lavoie'' into ''LVoIE'' ...

---

Editing the LNAB is no different than creating a new profile and then merging into it. They actually do the exact same thing, but changing the LNAB does it all at once. It's true that ideally you wouldn't want to change the LNAB after merging multiple profiles, but the same is true for your method of merging into another profile. What should be done is that the LNAB should be figured out before any merging, and then all profiles merged into the correct LNAB.

I agree that the changes in capitalisation should be fixed. The "improvements" tag is the one Chris looks at to see suggestions for changes, which is why I applied it to this question.

I'm not sure what you mean about the problems with illegitimate children, etc. If you want more control over the parent profiles, the best thing to do is only edit parent-child relationships rather than adding a sibling.

---

Is there some reason all surnames are not completely capitalized automatically? Iwas taught to fill out charts that way before computers.

---

Actually Lianne most of the time after having looked for an already existing duplicate profile with the correctly spelled LNAB (maybe just one of the pro's of multiple unwanted GEDCOM's) and not finding it, we HAVE to either merge into a new purposely made duplicate sibling profile with the correct spelling or edit the correct spelling if there haven't been too many changes. Your suggestion of figuring out the LNAB ''before'' any merging just isn't viable in the project I'm working in because of the sheer staggering numbers of variations in LN'sAB in duplicate profiles ... it is a question of AND and AND - doing as much research as well as merging as much in a sensible way as possible and even when a baptismal record is found often the LNAB must be merged into another profile. Thanks for clearing up the improvements tag! @Sharon - I do not understand your comment - it is precisely because I would say most surnames are capitalised (first character of a word) that I have this problem. I do not see capitalization of the entire surname as a solution either.

---

If there are a bunch of duplicates and none of them have the correct LNAB, the proper procedure is:

1) Change the LNAB (through the edit screen) on one of the profiles to the correct LNAB.

2) Merge all other duplicates directly into that profile.

No new duplicates need be created.

I disagree that it's impossible to identify the correct LNAB before merging. Many projects have the problem of variable spellings. We just have to determine the correct name, then do the merging. I don't see how merging and then determining the correct name is any easier.

---

If you edit the LNAB in the profile itself you are in fact creating a new duplicate. The only difference is that you are whiping the changes tab.

I'm not saying that it is impossible to identify the correct LNAB before merging, I'm stating that the whole process is a dynamic proces involving thousands and thousands of profiles and variations (just within one project) and many managers and it is a logistic operation (I use spread sheets to keep track of everything). Taking time to research extensively each and every profile is an near impossible and daunting task, especially if one cannot keep up with the dupliates being created already by GEDCOM or otherwise. I do not agree that no new duplicates need to be created. Only when not otherwise to be avoided sometimes one has to create new duplicates.

---

"If you edit the LNAB in the profile itself you are in fact creating a new duplicate. The only difference is that you are whiping the changes tab."

I realise this creates a duplicate. The difference is that that duplicate is instantly merged. Your duplicate van der Nest profile is still there.

There is no difference regarding the changes tab. Neither method whipes the changes. Both methods will result in a changes tab with little in it, and in both cases you can access earlier changes by navigating to the changes of the merged-away profile. The end result is the same.

---

---

---

Before I roll whatever that means - as I said explicitly - the duplicate is solely created for the wrongly spelled LNAB to be merged into ... If what you are implying is true (that they do not go anywhere but sort of exist 'in limbo' - I can picture that being a librarian myself working with catalogue records) - there must be duplicates all over the place even after merging - for example: http://www.wikitree.com/wiki/Des_Prez-16 or http://www.wikitree.com/wiki/Bergh-143 (as regards to your remark about 'in both cases earlier changes [will be visible] by navigating to the changes of the merged away profile - I must agree to disagree and leave it at that).

My point is that merging or any duplication would become much less of an issue if surnames weren't automatically capitalized when that is not the way they were spelled on the baptismal records.

---

You're both right about the Changes record of a profile that has its LNAB field edited. Before you edit a LNAB field, copy the URL for the Changes tab & include that link in the biography. When you edit the LNAB field, the changes for the old name/WikiTree ID are not deleted from WikiTree, but finding them can be a problem if you don't remember what the previous WikiTree ID was, because the Changes page for the new profile doesn't tell you (at least it didn't in the last profile I changed the name for).

Cheers,
Liz

P.S. to Philip - Yes, a single profile should be selected before any merging: even if it may not be the best LNAB, just pick one & merge all the duplicates directly into it until you figure out what the LNAB should be. When you do, change the LNAB to it. That gives only two redirects for most profiles: one redirect for all the duplicates into the chosen target profile and then a second redirect for them when the LNAB is changed.