Wikipedia talk:Merging/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Alternative to deletion

Merging is a recognized alternative to deletion (WP:ATD-M), and yet this doesn't form part of the set of merge reasons here. While it is quite possible to call an AfD first (resulting in a merge), if the nominator thinks that a merge would be the best outcome, then it seems best to discuss this as a merge proposal. In practice, this is what often happens, but I have on several occasions come against the argument that notability is not relevant to a merge discussion. However, notability is relevant to deletion, and so is a warranted consideration as part of a merge discussion; that is, an article not reaching WP:GNG can be proposed for a merge. So, I therefore propose that we add to WP:MERGEREASON a 6th point: General notability guidelines not met (linking to WP:ATD-M). Of course, this would not prevent notable topics being merged for one of the other 5 very good reasons. Klbrain (talk) 11:36, 29 December 2022 (UTC)

Support but I expect we're going to see some pushback from verification extremists claiming that if something isn't notable enough for a standalone article, it shouldn't be included in any article. Do we want to invite that discussion? ~Kvng (talk) 15:09, 8 January 2023 (UTC)

Comments

This is often seen as an AfD aftermath. These discussions take place regarding unsourced or under-sourced articles, and AfD participants can't quite pull the trigger and delete the thing, so they dump it on us. The result: we merge the unsourced material to the designated target, and it is quickly challenged and deleted — A lot of work with no payback. I have merged hundreds of these, careful to merge only that which is sourced (even if with a bad source), and then am questioned on why the majority of the [unsourced] content was not moved over. This has even involved administrators a time or two (people who should know better). It's a failing of the AfD process, but we get burdened with the cleanup. I'm all for keeping anything that is well sourced, however, if an article can't pass GNG, then that content is likely to dilute the merge target and/or be removed entirely from it after the merge takes place. Instead of adding lack of notability to MERGEREASON, I think we need to address this at the AfD project-end of the process. In other words, If an article can't pass GNG, it can't be "Merge and Redirected", only: "Deleted" entirely, or simply "Redirected." Perhaps specific instructions to that end need to be added to the directions at AfD through an RfC. I really hate doing work twice on these articles. Regards, GenQuest ^"scribble" 18:46, 8 January 2023 (UTC)

Merging only sourced material is one school of thought. I beleive longstanding unsourced material that has been seen by a lot of readers and editors over time is valuable. We don't delete stuff just because it is unsourced, we delete stuff that has been challenged and can't be verified. I don't expect we will all agree on how to handle this material (other than, "it depends") so I don't think we can apply the same process to all of it for everybody all the time. Just expect WP:BRD and ongoing rehash of these arguments :( ~Kvng (talk) 14:16, 26 February 2023 (UTC)

Removing the unsourced material IS challenging it, long-term or not. To add it back, you'll need to take the time to add sources, something not all volunteers here have the time or inclination to do. This is all policy. I've found long-term vandalism in tens if not hundreds of articles, some read by thousands of people in the meantime. Have you never come across hoax entries here? I have. Both of those only last long in the encyclopedia when we become complacent about holding wiki-voiced statements to a high level of scrutiny. It's a win-win for the article. Merging unsourced material is a time waster. If the article is being watched, that content is going to be removed, sometimes immediately following the merge. There's no point to it. GenQuest ^"scribble" 16:02, 26 February 2023 (UTC)

I think there should be more to a challenge than this is uncited therefore I challenge - What specifically looks off about the material? Have you searched for sources? Why doesn't WP:BLUE apply? I also think it is better to start with {{cn}}, {{hoax}} or some such for questionable material than boldly deleting it. These principles work well for existing article content and so I suggest they be applied to materiel involved in a merge. ~Kvng (talk) 15:02, 2 March 2023 (UTC)

Your quote: "...I think there should be more to a challenge than "this is uncited therefore I challenge...": –You would need a general RfC for that. The rest are editing issues that any competent editor would take into consideration for each of their edits, whether in a merge or just general editing. As a volunteer project, it is incumbent upon the person who wishes to add statements of fact to verify and cite their additions. It is not, however, incumbent upon an editor who challenges that statement to do anything other than protect the "Wikipedia voice" of our articles, and quickly remove such content. See Bicholim Conflict for starters. GenQuest ^"scribble" 00:41, 3 March 2023 (UTC)

I started the sentence with I think... because I realize that different editors have different positions on these questions and policy is broad enough to contain most of them. You've made assertions in the above reply that I disagree with and I doubt there is policy support for. In summary, we disagree and there isn't going to be someone riding in here credibly telling either of us that we are wrong. ~Kvng (talk) 22:31, 13 March 2023 (UTC)

Hoping a bot or gnome might fix language links

I just merged into REDD and REDD+ but there are no drop down language links yet. Only Spanish and Norwegian have 2 articles. I cannot find anything in these instructions so hoping I don’t have to do anything Chidgk1 (talk) 13:56, 11 May 2023 (UTC)

Multiple options to resolve multiple overlapping WP:REDUNDANTFORKs

For context: Wikipedia:Articles for deletion/Royal descendants of John William Friso (3rd nomination) just closed as merge into John William Friso, more specifically John William Friso#Tree of royal descendants. (I proceeded to put the tree into a template which I also put on his wife's page, since they obviously.... procreated together).

Now I find a very similar situation, which has all the same issues as the one above, plus a lot more, namely WP:REDUNDANTFORKs everywhere, and no obvious single target for the merger.

Source pages that probably should be merged per WP:REDUNDANTFORK, WP:NOTDIRECTORY, WP:LISTCRUFT, WP:OR, WP:SYNTH, WP:UNSOURCED, WP:V, WP:RS

• Royal descendants of Queen Victoria and of King Christian IX
• Descendants of Queen Victoria

Possible target pages

• Queen Victoria#Family
• Albert, Prince Consort#Issue
• Christian IX of Denmark#Issue
• Louise of Hesse-Kassel#Children

I'm not sure where to even start nominating, so I was hoping someone could give me advice on how to proceed. Cheers, Nederlandse Leeuw (talk) 19:27, 12 May 2023 (UTC)

"Merge" instead of "Merger"

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Support to prefer use of "merge" instead of "merger" to describe the process of merging pages. No objections to the proposal in over 1 month. Mdewman6 (talk) 21:05, 2 July 2023 (UTC)

---

It seems like the noun typically used to describe the topic is a "merge" and not a "merger". As such, I propose to update the page here to use the term "merge" instead of "merger". If there are any objections, let me know. Mdewman6 (talk) 21:34, 25 May 2023 (UTC)

Merger is used as a noun in a business context (Mergers and acquisitions). Elsewhere, merge sounds better. No objection, just background. ~Kvng (talk) 13:02, 20 June 2023 (UTC)

Support the change to "merge". Klbrain (talk) 11:59, 24 June 2023 (UTC)

I am going to formally close the discussion and make the appropriate changes. Mdewman6 (talk) 21:05, 2 July 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Semi-protected edit request on 13 October 2023

Replace the redlink in step #6 of "How to Move" ("a logo") with File:Stade Lavallois logo.png, or any of the other 163724 files in Category:All non-free logos. 2603:8001:4542:28FB:4487:B54E:7615:4938 (talk) 00:38, 13 October 2023 (UTC) (Please place talk page messages here instead)

 Note: Not sure if this suggested logo - for a football club - is an acceptable replacement, given that the last one was deleted with the comment, "Unused non-free media file", and the proposed one has a non-free license as well. But the link really should be pointed at some logo. -- Pinchme123 (talk) 04:16, 13 October 2023 (UTC)

The whole point of that link is to illustrate a non-free logo (the rest of the sentence is 6. Check for non-free images (or other files). Examples: .... But at any rate, I just picked a random one as an example; if you'd rather you could try this one instead. 2603:8001:4542:28FB:5D4C:58E2:FE57:26F7 (talk) 06:09, 13 October 2023 (UTC) (Please place talk page messages here instead)

See? I'm just a dense moron. Disregard me here! --Pinchme123 (talk) 14:53, 13 October 2023 (UTC)

 Done. I replaced it with a different space agency logo. Anon126 (notify me of responses! / talk / contribs) 14:37, 17 October 2023 (UTC)

Merging clusters of articles in different languages

I have encountered problems while trying to merge'' Q3326454 with Q264251. Both clusters of languages deal with the same topic (''anatomical terms of motion'') and I am neither able to add languge links in the old vector legacy (2010) skin (probably due to the fact, that both object are already clusters of more than one language) nor edit language links in the new Vector (2022) skin. Merging the articles with the MergeItems tool and the MergeLexemes tool resultet only in error messages. What am I doing wrong and how to solve this problem in the future? (I have already encountered this problem very often, so I hope that I will be able to contribute better to wikipedia in the future if someone explained me how address that issue ;) ) Mikulicz (talk) 14:29, 1 July 2023 (UTC)

It sounds like you have a question about Wikidata items. You should ask those at d:Wikidata:Project chat. WhatamIdoing (talk) 17:16, 29 November 2023 (UTC)

Talk page archives

Is there any consensus on the best way to handle merging talk pages? After making the talk page of a long-merged article redirect to the new location,[1] I've added the pre-merge talk page as an archive with a decimal number. This is now searchable from an archive template, but won't show a hyperlink (positive integers only). If I had done this at the time of merging (instead of seven years later) I could have just moved the pre-merge talk page to Talk: <new article>/Archive <n + 1> and incremented the arching counter to "n + 2". I used a generic {{ombox}} to explain that the talk page had come from elsewhere because I don't see any kind of standard template for this. This all seems like the kind of thing a script could do, but after searching I don't think such a script exists. Rjjⁱⁱⁱ (talk) 20:06, 4 January 2024 (UTC)

Rjjiii: From step five of the Merging Procedure:

The Destination (target) Talk-Page is tagged with (optional): {{merged-from|~source page~|date= }}'' –or– {{Copied|~source page~|date=}}

The Source Talk-Page that has discussion content, should have the following template placed: {{merged-to|~destination page~|date= }}'' (without removing the old discussions, but replacing all other templates; including most project assessment templates (some projects want to keep these—they will correct if necessary); the exception is the archive index).

PS. To clarify: TalkPages with discussion content should not use the normal #REDIRECT [[<talk:target article>]] template at all, but must still have an attribution link to the target TalkPage in the edit summary. ~GQ

Most mergers do not involve articles with well-used TalkPages featuring archives. For the few that do, I like the idea of preserving the archived comments of the Source Article TalkPages where they would be more accessible to the readers. Perhaps by merging them to the archives of the target article: Talk:{target article}/Archive_0 maybe? Just throwing that out there. Ideas anyone? GenQuest ^"scribble" 14:20, 12 January 2024 (UTC)

That sounds like a lot of work so I doubt it will happen reliably. Perhaps better to improve {{merged-from}} to add links to the old talk page archives if such exist (it already has a link to the old talk page). ~Kvng (talk) 13:27, 15 January 2024 (UTC)

Maybe so. The easier a solution is, the more likely folks are to use it.

I'll post a few examples below of places where I have tried to include the old talk page into the merge target's archives. This is likely not necessary for most merges, but especially on templates I think this is sometimes really useful to be able to search the full discussion history.

• Moved old talk page to "Talk:Target/Archive n+1": Template talk:Unbulleted list citebundle/Archive 1 (from {{multiref}})
• Moved old talk page to "Talk Target/Archive 0": Template talk:Cite comic/Archive 0 (from {{comic strip reference}})
• Moved old talk page to "Talk Target/Archive n.1": Talk:Roswell incident/Archive 1.1

Rjjⁱⁱⁱ (talk) 17:08, 15 January 2024 (UTC)

@User:Rjjiii it looks like you've done WP:CUTPASTE moves here. Leaving history of the talk page at the original location is sub optimal. To avoid creating confusion about where the original discussion occurred, I think it is best to not move these pages. To make editors aware of these, I support adding links to the original archives to the top of the talk page of the talk page of the merge destination. ~Kvng (talk) 15:17, 21 January 2024 (UTC)

Thanks for the feedback; I have already realized that I can keep the talk page history using page moves.[2] I may try adding links in the future. Rjjⁱⁱⁱ (talk) 02:42, 22 January 2024 (UTC)

WP:MERGECLOSE is opaque when it doesn't need to be

This section of the guideline is opaque, confusing, and badly written. It explicitly covers the closing requirements for Any user, including the user who first proposed the merge and also states when an editor who is neutral and not directly involved in the merge proposal or the discussion is required, but it requires reading between the lines for the intermediate case. I restructured and clarified part of the text to be readable without changing the meaning. If there is consensus to make this change, I would like to reinstate the edit. Daniel Quinlan (talk) 22:25, 5 February 2024 (UTC)

How is it confusing? In cases where either nobody has commented, or there is unanimous support for the merge, then any user, including the proposer, can close the discussion. In all other cases, i.e. at least one user has opposed the proposal, an uninvolved user should determine consensus (or lack thereof). The reason for my revert, though, was that you did change the meaning, in that you changed the text to say that in some cases, an involved user may close the discussion, but not the original proposer. Mdewman6 (talk) 23:57, 5 February 2024 (UTC)

Uncontroversial and unanimous are different things, so I think the current wording could be more clear than it currently is. Hey man im josh (talk) 00:41, 6 February 2024 (UTC)

I'm unable to interpret the text the same way. At best, it's self-contradictory and very ambiguous. The current text states that closings of uncontroversial merge discussions by involved users are allowed and it restates the point before the uninvolved editor case: In more unclear, controversial cases. If unanimity was required, the current text makes no sense.

I think the core question is what the current guideline means for uninvolved editors if there is a clear and uncontroversial consensus that is lacking unanimity. For example, let's say there's a merge proposal to merge a new article into an existing article. 10 people say "yes, merge it", but the author of the new article disagrees, or maybe the dissenter is an already banned sockpuppet. Is a decision to merge controversial or unclear?

I have no problem removing the second bullet and changing the third bullet to start "Otherwise, the determination that a consensus..." if I'm the only person reading it this way. Daniel Quinlan (talk) 01:01, 6 February 2024 (UTC)

Yeah I think anyone can close if there is silence or if it's unaminous, which comprise most merge discussions. If there is any dissent at all, then the normal guidelines for determining consensus apply, and the discussion should be closed by an uninvolved user. Feel free to edit that section to make this more clear. Mdewman6 (talk) 01:46, 6 February 2024 (UTC)

Anyone can close if there is silence, unanimity, or the result is clear.

There are only two situations that we care about:

1. The result is obvious (to everyone involved in the discussion), so "any user" can close it, or
2. The result is not obvious (e.g., to anyone; alternatively, to that one argumentative editor who thinks his reasoning is far stronger than anyone else's), in which case you need to go get a "neutral" editor.

There is no intermediate situation, in which I get to summarize your merge proposal my way, but you don't get to summarize your proposal exactly the same way. All participants in the discussion are treated equally.

In particular, if "the user who first proposed the merge" finds that there is unexpected opposition, the ideal case is for that editor to say "Thanks, all! I really appreciate your input, and I'm closing this as not-merged". We really don't want the OP in that case to say, "Oh, but it's not unanimous, so I'm not allowed to admit the obvious." WhatamIdoing (talk) 06:12, 6 February 2024 (UTC)

Optionality of tag indicating a merge

On 20:23, 9 January 2024, I made an edit with the rationale "this should not be emphasized as being optional, as a tag of merge is certainly necessary for example to know the reason of any discrepancies or other situations about the pages". But on 16:12, 10 January 2024, User:Klbrain made a revert, with the rationale, "Take it to talk if you want a policy change like this; the Edit summary should already provide the information this template includes, so this step is duplication of work".

I have to point out that an edit summary is provided sometimes with an edit, whose diff is among often many other diffs found in the page history. Therefore, certainly an edit summary of a merge is in no way a useful substitution of a prominent indefinite tag indicating there was a merge. Regards, Thinker78 (talk) 22:12, 10 January 2024 (UTC)

To clarify: the proposal from Thinker78 relates to the currently-optional use of template:merged from on the talk page of the merge target, to make this an essential part of the process. Its something I'm against making compulsory, even though its use is helpful (I regularly use it). The edit summary mentioning the merge is an essential part of the merge process step 1; the talk-page template duplicates this information. My view is that the small proportion of readers who actually know to use talk pages will also be quite confident with page histories. I'd like to not discourage editors from competing merges by adding another required step; keep the merge process simple! Klbrain (talk) 23:39, 10 January 2024 (UTC)

the small proportion of readers who actually know to use talk pages will also be quite confident with page histories. Last time I spent a significant amount of time looking for the diff of a merge/move of a page from a link provided by an editor. If the merge or move template had been in the header of the talk page, it would have saved me a lot of work. Regardless, given that Wikipedia:Merging is only an information page, removing the wording "optional" doesn't make compulsory the guidance, only removes the emphasis on optional. Sincerely, Thinker78 (talk) 23:47, 10 January 2024 (UTC)

Last time I spent a significant amount of time looking for the diff of a merge/move of a page from [Wikipedia:Categorization of people#By place] provided by an editor. This is easily solved by doing a search of "merg" on the TP. Note: If an old merge hasn't been noted or attributed in a past edit summary, you should do so at that time and refer back to the actual merge date in the edit summary; that keeps things legal. Regards, GenQuest ^"scribble" 12:57, 12 January 2024 (UTC)

• I agree with Kilbain; the operative guideline here is WP:Copying within Wikipedia, which states that when copying content between pages, the minimum requirement is to state where the content originated with a link in the edit summary. The directions for merging here (a how-to page) should reflect the operative guideline. If there is desire to make notices on talk pages mandatory, then the guideline should be changed first. Mdewman6 (talk) 23:47, 10 January 2024 (UTC)
• That's the right call. The placing of a notice on TPs is redundant, cluttering, and unneeded. Making it mandatory only furthers the complexity of an already complex process. The attribution rules/laws (copyright requirements) are already covered by the edit summary entry. Why then would a notice on the Talk Pages (that are already suffering from loads of growing bloat that have shown no signs of abatement through the years) even be helpful? GenQuest ^"scribble" 12:57, 12 January 2024 (UTC)

  But I didn't say mandatory, I simply removed the emphasis on optional. Regards, Thinker78 (talk) 18:43, 12 January 2024 (UTC)

  If you make a list of steps in a page like this, and you don't very clearly label optional steps as being optional, then someone will declare that the step is absolutely mandatory and the result is invalidated due to outrageous violations of Wikipedia's Sacred™ Process. (This person will probably also tell you that their concern about the process violation is purely disinterested, no matter how much WP:BLUDGEONING they did in the merge discussion.) Wikilawyers who don't get their way on the merits of their original arguments are not exactly known for knowing WP:How to lose.

  Additionally, in this case, we can realistically (*sigh*) predict that eventually some poor person will be honestly concerned that the failure to place that tag on some page violates the CC-BY-SA license and/or Terms of Use, and multiple editors will have to reassure them that the tag is not actually necessary (or even helpful, depending on the exact circumstances) and that nothing has been done wrong and nobody's going to get sued by anybody over that template. If we say "Optionally" right up front, then we significantly reduce the likelihood of making that conscientious editor worry in the first place, and we have a quick and easy way to handle their question if they worry anyway. WhatamIdoing (talk) 06:25, 6 February 2024 (UTC)

  Interesting. I made a similar argument (abuse and misuse) against the WP:BLUDGEONING essay. Strange coincidence. So I can understand your concerns. Although my point was simply as a convenience to editors looking in pages histories. Regards, Thinker78 (talk) 20:40, 6 February 2024 (UTC)

The see also section?

I think a link to the Wikipedia:Merge what? essay may be useful, but the see also section is focused on guides, not related links. Thoughts on how this should be incorporated or if it should not be? Clovermoss🍀 (talk) 06:06, 5 May 2024 (UTC)

That page is targetted at those working on AfDs, not really at those proposing merging directly. I think that a naive reader linked from this project page would be confused by the text there, as it's arguing against merge recommendations in a specific context that is not the core business of this project. Klbrain (talk) 09:06, 5 May 2024 (UTC)