Help talk:Merging pages

Keep Ancestral File Numbers [17 April 2009]

Amelia just added the following to the Help page:

"(But do keep Ancestral File numbers or other universal ID numbers, as they can be used to identify duplicates or find that individual in the AF.)"

I just want to say "oops!" and apologize for deleting these in the past. Sowwy. -- jillaine 12:37, 17 April 2009 (EDT)

Merging Sources [9 February 2009]

First off, how does one do it? There is no "view duplicates" when looking at Sources, so I presume this is still a manual procedure. And when do you do it and when do you not? I seem to recall -- somewhere -- a discussion about multiple editions of a single source, but I don't remember where, nor do I recall what the final word on that was. I'm did a search for [Winthrop Fleet in Sources]. As you'll see there are three different versions of this-- the original 1930 publication, the 1961 re-issue, and then a 1989 edition (none of which by the way have any pages linking to them). Do we really need THREE? Couldn't we have just one, and the person citing it could put the edition in their citation instead of having three different sources?

And if we do decide that having one is okay, can I just request speedy deletes on two of the above three since no one is linking to them?

Thanks!

-- jillaine 19:50, 7 February 2009 (EST)

Well I found the answer to the 2nd question. I hadn't looked closely enough at the Help page. See How to Merge Place & Source Pages. But my first question still stands. jillaine 19:53, 7 February 2009 (EST)

No, we don't need three. If they are all substantially the same (i.e. the differences are in formatting or maybe in a forward, at most), then they all go on the same page, and you explain in the notes section the differing versions. The information on the original goes in the official fields. Put the Family History Links on three different lines in the repository section. (It is often the case that the FHL has multiple versions also because one is a filming of the original book -- there aren't actually even multiple versions.)

If one or more is a supplement or redo of the original (rewriting or adding to sections), then they get separate pages. If the titles are the same add "(19XX Edition)" or whatever to the end to distinguish. Preferably link the original to the supplement and vice versa.

I find it handy to also search for an Ancestry.com version of the source and link that one at the same time, since there often is one. Then redirect the ones you don't need any more to the new one. Or, you're right that if no one is linking to them, you can just ask that they be deleted.--Amelia 20:47, 7 February 2009 (EST)

Cool. Thanks, Amelia. jillaine 21:45, 7 February 2009 (EST)

It's still a manual process unfortunately (so many things to do; that's what makes genealogy fun, right? :-) --Dallan 10:47, 9 February 2009 (EST)

Consistency in Merging Practice (is it POSSIBLE?) [24 November 2008]

I was reading a discussion elsewhere here (don't now remember-- watercooler? no, it was solveig's talk page) about what to keep and what not to keep when merging. One volunteer mergerette was talking about deleting any source that was insufficiently backed up or that insufficiently conveyed FACT. This included when there are discrepancies-- if the divergence isn't sufficiently backed up with fact, then the theory is deleted.

I gotta say, I don't like such a practice. When I'm merging, I'm including the divergent information even if poorly sourced, figuring we can work out later what's really so, or what the sources are for the divergence (unless I have really good data to back it up, that I am personally familiar with). But as a volunteer mergerette, I'm hesitant to delete any data that might provide a clue to more accurate research, even if it's "insufficient" in someone else's mind.

So there's that, but then it also made me realize that we have divergent approaches to merging, and if we're not all following at least some sort of default set of activities, seems like we could be making quite a mess out there.

Thoughts?

-- jillaine 15:28, 21 November 2008 (EST)

I added some guidelines to merging pages at Help:Merging_pages#Merging_guidelines. I would appreciate your edits and additional instructions. Thanks --sq 23:26, 24 November 2008 (EST)

What happens to a person who was merged INTO someone else? [20 November 2008]

I'm seeing cases of "redirected from..." on person pages; for example this one: Person:Anna_Rice_(5). And then if you click on the link you get a "this person has been redirected to..." Is that what we're leaving around the wiki when we merge? Or is this a left-over from before the merge tool was completed and merging was done manually with redirects? Thanks! -- jillaine 20:42, 19 November 2008 (EST)

Yes, that's exactly what's being left when we merge. It just automates the formerly manual process.--Amelia 23:17, 19 November 2008 (EST)

Ugh. I cannot IMAGINE doing this manually. Well, more accurately: even the IDEA of IMAGINING doing this manually is horrific. I'm so glad he wrote a tool for this. -- jillaine 14:01, 20 November 2008 (EST)

Use of Personal Coding in Person Names [23 December 2008]

Please look at: http://werelate.org/wiki/Family:John_Gay_and_Joanna_Gay_%281%29

Notice that on each of the parents and one of the children, the GEDCOM contributor has used "(X)" as a prefix. I am guessing that this is the contributors way of identifying a direct-line ancestry through a tree. What do we do when we encounter such usage? The same can be applied to my own uploaded GEDCOM where I use UPPER CASE in a surname to distinguish direct-liners from others. Thanks. jillaine 23:39, 16 November 2008 (EST)

Delete it. Same with UID's, reference numbers, and other "personal" marks. They have no place on a wiki collaborative page.--Amelia 23:51, 16 November 2008 (EST)

Oooh, really? delete UIDs, too? all that stuff? Really? I don't like seeing them, but I've refrained from deleting them because I feared that they might mess up someone's GEDCOM download when that becomes available. jillaine 09:59, 17 November 2008 (EST)

I think it's contrary to the goal of WeRelate to let users mess up common pages just so their downloads might work better in the mythical future when gedcom downloads are made available. Since most people don't use them, I would imagine that the download will have a mechanism to work without it, but even if they didn't, the goal of clean and readable pages trumps the goal of useful downloads. Now if I actually ran across an active WeRelate user who cared, I might reconsider, but I never have.--Amelia 10:10, 17 November 2008 (EST)

Cool. I'm with ya. I'll start deleting all that stuff when merging. (I'm trying to do spend about an hour an evening merging (more on weekends)-- I have to say I get a bit bleary-eyed after the first few.) jillaine 10:18, 17 November 2008 (EST)

Don't worry about removing UIDs. Even if you remove them from the wiki page (I agree that they don't belong on the page), they're retained in a separate file so they'll be available for GEDCOM downloads. (Sorry that's taking longer than I expected.)--Dallan 01:19, 24 December 2008 (EST)

Question about merging children [17 November 2008]

When I'm merging one or more family pages into a target, sometimes the target has fewer children listed than the "from" pages. When this happens, the pull-down menu default on the left from pages is "Do not merge". If I take this literally, and leave that selection alone, what happens to those children on the left-hand side? Do they become orphans. And if I *do* want them to "go along" to the target, do I then select "Merge with child [#]" even if the target "[#]" in the right column is blank? Thanks. jillaine 21:33, 15 November 2008 (EST)

Yes, they are merged into the new merged family. It just means there is no similarly named child to merge with.--Amelia 23:52, 16 November 2008 (EST)

Thanks for responding, Amelia. Okay, then, um, what happens if I child #1 on both sides (from and target) is a dupe, but child #2 only has someone in the From column, *and* I select "Merge with #2" for this #2 "from" child? (Which is what I was doing because I was afraid I'd get orphans otherwise.) jillaine 09:58, 17 November 2008 (EST)

Nothing, as far as I know (i.e #2 just gets added to the new family like normal).--Amelia 10:12, 17 November 2008 (EST)

Okay, so both options ("do not merge" and "merge with child #n") have the same effect. Thanks for the clarification. I feel better now. jillaine 10:19, 17 November 2008 (EST)

Old Stuff

Item #3 says "Delete the duplicate page(s). If you are the only one watching a person or family page, you can delete the page by clicking on the green Delete box at the top of the screen. Otherwise, follow these instructions."

First, following the link doesn't provide any new instructions that I can tell. Secondly, here's a situation where two families are about to be merged, but the other user does not appear to be active on the site. I don't really want to delete his/her pages do I? Everything is being copied over to my set of pages for the family because they appeared to have more source documentation. Would a "redirect" from their Family page to my Family page work? Would each child or person page have to be redirected as well? What if a non-active user comes back one day, are they going to still be watching the pages that have been merged or is it going to look like their pages have just vanished? The family I'm working on has multiple versions for parents/children with probably four or more different users having connections to this one family. The family really does need to be merged. --Ronni 09:07, 17 June 2007 (MDT)

This is a follow-up to my previous questions. I can see where redirecting pages instead of deleting them would cause a lot of confusion. Person:John Doe(1) would be redirected to Person:John Doe(3) and in the search list it would look like there were a lot more John Does than there really are. The family I'm currently working would be a mess in that respect and to make matters worse, the same given names were used over and over again, sometimes even within the same immediate family. So yes, I see where deleting the pages after a merge has taken place would be better. Now, having said that, how will the non-active user, who isn't aware of a merge going on, find the new merge pages when/if they log back on? How are they notified that the previous pages they were watching have now been deleted? And how do we delete pages that others are watching? Or should we even do that? Sorry for all the questions. I love the idea of merging and it's what attracted me to WeRelate. Merging leads to collaboration and collaboration leads to source documentation, correcting of errors, brick walls coming down, etc. I know Dallan is working on a merging "program" and maybe all these questions and circumstances have been worked out already and I just need to be patient perhaps. :) --Ronni 11:51, 17 June 2007 (MDT)

You're right. Redirecting the old page is better than deleting it. The redirected page will remain in the other user's watchlist, and they'll get notified of the edit that you make to their page to redirect it to your page. When they click on the "changes" link in their email, they'll see that your edit has caused their information to be replaced with a redirect to your page. They could then follow the redirect and add your page to their watchlist and edit it if they wanted to. Or they could "unmerge" by editing the old version of their page (prior to your edit) and saving it on top of your redirected version.

Unmerging after multiple people and families have been merged is more complicated because you may have to edit some pages after unmerging to make sure they link correctly to the newly-unmerged pages. In the future I need to create an "unmerge screen" to handle this.

As for the redirecting pages cluttering things up, I was trying to avoid that with the instruction to delete the old pages, but I think the benefits of having the pages remain in people's watchlists outweighs this. What I need to do is omit redirected pages from search results. That should help.

Unfortunately, you'll have to merge every person and family by hand at this point. I'm thinking that the "merge screen" that I'm planning to write in a few months would let you merge everyone in a family, and maybe multiple families, at once, but until that's ready you've got to do it by hand.

I've updated the instructions to tell people to redirect instead of delete the duplicate pages.--Dallan 13:36, 20 June 2007 (MDT)

When I merge pages by putting in a redirect, the watchers of the redirected page do not appear in the watch list on the page to which they are redirected --User:Lrsears 20:40, 12 May 2008

Lrsears, has the "watchers" shown up yet on the page? Sometimes it does take a few minutes, but I have yet to see it fail completely. If the watchers haven't appeared yet, then we should let Dallan know. Also make sure your browser is looking at the latest page. Occasionally, caching problems will creep in. --Ronni 00:20, 13 May 2008 (EDT)

Nope, no merge of watchers yet. For example, check http://www.werelate.org/wiki/Person:Richard_Sears_%2813%29 which has watcher DrewWalkerski and then look at the redirect http://www.werelate.org/wiki/Person:Richard_Sears_%289%29 Walkerski doesn't show up as a watcher. My IE browser cache is set to refresh on every visit to a page? Maybe I didn't do the redirect correctly? --User:Lrsears 07:36, 13 May 2008

Yep, that's the problem. To redirect, use the title not the url link. For example, it should be: #redirect [[Person:Richard Sears (9)]] and NOT #redirect [[Person:Richard_Sears_%289%29]]. I was going to fix it for ya, but I want you to see how the page should look after a redirect and how watchers just magically show up. :) If you still have problems, let us know. --Ronni 10:43, 13 May 2008 (EDT)

Thanks, now I see them!--User:Lrsears 21:25, 14 May 2008

Not a Match [6 May 2009]

I am having trouble understanding how the "Not a Match" and nomerge are supposed to work. Yesterday I did some duplicate work on the Smith family (John Smith and Unknown - what a trip!). I marked several families as "not a match". I was puzzled to see that the "nomerge" was only applied to the low numbered family, not to all of them. Today two of them are back on my duplicates list:

John Smith and Margaret Unknown (1) and John Smith and Margaret Unknown (4)

When I look at the merge page the (1) family is clearly marked "Do not merge with (4)" Does the duplicate finder not look at the "no merge"? Does marking only one of the pair work? --Judy (jlanoux) 09:54, 23 April 2009 (EDT)

Oops, marking only one of the pair is supposed to work, but there was a bug in the duplicate finder that caused it to ignore the nomerge tag every once in awhile. I fixed the bug a few days ago; would you please let me know if it's still happening?--Dallan 11:27, 6 May 2009 (EDT)

So far, it seems to be fixed. The Smiths have gone from my duplicate list. Thanks, I was getting tired of them. --Judy (jlanoux) 15:42, 6 May 2009 (EDT)

Merging duplicates with "exact information" (that isn't) [11 May 2009]

This may be a little picky, but anyway. I was reviewing and merging the duplicates that resulted from my recent GEDCOM import, and I noticed something. When you're looking at the two sets of information side-by-side, a green box means the info is identical between the two. (Yellow means partly so, red means different.) But in this case, there was a difference between green boxes. The person's name (in this case) was identical -- but one side had a couple of sources for that name and the other side had none. To me, citing a source means there's a definite "difference" in the information asserted. Especially since WR is trying to encourage the addition of sources to the pages. I wonder if perhaps this ought to result in the boxes being colored yellow? Or whether there ought to be an additional color that means "No Sources"? --Mike (mksmith) 07:20, 10 May 2009 (EDT)

As long as the sources are checked, they should automatically attach themselves to the corresponding event in the merge target. So even though the event itself is "green" and doesn't need to be copied over, the sources for the event should get copied over automatically if they remain checked. Does that sound ok? If this isn't happening would you please let me know? Also, if you're ok with this behavior but it needs to be made clearer in the help pages, would you mind making it clearer?--Dallan 23:08, 11 May 2009 (EDT)

Deleting Someone [27 December 2009]

How do I delete a person? I added people to a family based on the family information I had, only to learn that my ancestor was not married to her daughter's father, and that all the other children were by my ancestor's later husband. All these children are fully covered on another family page, so a merge would not add any information at all.--Mitzymoo 18:57, 27 December 2009 (EST)

For pages where you are the only editor, use the delete link under the more menu. If there are other editors, type "{{Speedy Delete|the reason you want to delete the page}}" on its own line at the top of the text box. Hope this helps.  :) --sq 19:19, 27 December 2009 (EST)