This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

"The main reason that the merger backlog includes more than ten thousand articles is because the people who support the merger neglect to undertake this final step. Any editor, including you, is permitted to perform mergers in accordance with consensus. Merging pages does not require intervention from an administrator."
No wonder people "neglect" to undertake the final step: actually performing the merger is way too complicated for the average editor. Can't it be simplified for the zillions of technically-impaired editors? Or at the very least, there should be an example of a simple merging using two pages with fictitious names and proceed to merge them lowly and patiently for most of us to understand...--Lubiesque (talk) 02:34, 9 December 2018 (UTC)

I'm of the personal opinion of that if you !vote merge - [1] - then you do it yourself [2]. (I usually do this, however I sometimes miss out when not watching the discussion page or if the discussion closes while I'm on a semi-wikibreak / busy for a few days). A merger usually isn't technically complex - the complexity is often the need to understand the subject matter - and deciding what's irrelevant (and can be tossed away) and what is redundant (already described in a better form, all bet it in different words, in the target article). A merge may also impact the target article's structure significantly (though - in some simple cases - all you do is paste a new section in, and a little bit of intro text... The complex cases are when the two (or more) articles get interleaved together). In short - I don't think the gap is technical. Icewhiz (talk) 07:19, 11 December 2018 (UTC)

When I tried to proceed with my first merge I was definitely taken aback by the length here. So while the technical gap is maybe not the main reason, I do believe it's a significant factor. In general that's a point that has been raised e.g. even by WMF executive director Sue Gardner in an interview back in 2011 that has been recently recalled in the Signpost; "she singled out two areas [as possible solutions to improve user retention]: the first is behavioral problems, and the second the sheer quantity of policy and instructional text, 'simplifying it would help everyone' ". For merging specifically, my last few edits here were precisely to cut down the cruft (you can compare before and after to see that all the meaningful content is still there). But I didn't touch the "How to merge" section yet. It's nonsense now, it presents almost the same instructions three times in a row. There's still room for improvement in the other sections as well. Tokenzero (talk) 08:49, 11 December 2018 (UTC)

So... "A merger is the process of uniting two or more pages into a single page", but I want to propose taking the contents of 1 article (The Second Trio) and putting it into two articles (Moon Beams and How My Heart Sings!). This is because the 1st album is a reissue that combined the others, but there's nothing of note about the reissue. I'm tempted just to convert The Second Trio into a redirect (perhaps picking one of the others at random as the target), but thought it might be better to make an official proposal. So... is moving the contents of 1 article into 2 others a merger? If not, what is it? If so, what's the procedure? EddieHugh (talk) 00:45, 17 January 2019 (UTC)

Well, what you're referring to is the opposite of a merge, it's a split. It's got the mirror image of the merge procedures, templates, formats, ropes and pulleys: Wikipedia:Splitting. You could follow the procedures and all, but given how tiny the article is and how it's been tagged for notability since 2011, I don't think it will be out of process if you simply went ahead and did the split yourself. Though if The Second Trio|the article]] is to become a redirect, wouldn't the album's entry in Bill Evans discography be a more suitable target? – Uanfala (talk) 01:42, 17 January 2019 (UTC)

Right, most of the Bill Evans discography § Compilations aren't notable, so I would just redirect to that. – wbm1058 (talk) 01:50, 17 January 2019 (UTC)

(edit conflict) See WP:Splitting and WP:Summary style. But, if there's nothing of note about the reissue, as indicated by the ((notability)) tag on the top of it, that implies sending it to WP:Articles for deletion, not forcing the content into two articles where it already exists or doesn't belong. – wbm1058 (talk) 01:46, 17 January 2019 (UTC)

Thanks. I didn't conceptualise it as a split, as the same information would go to both articles (in reality, it'll be a short sentence simply stating that the compilation was released). I'll do that and redirect to the compilations section of the BE discography, as that has links to the two original albums. EddieHugh (talk) 12:25, 17 January 2019 (UTC)

The instructions say "Check for non-free images (or other files)." but I have no idea how to do that. Could someone edit this article to explain how? Or better could there be a bot to do it for us and do step 3. too?Chidgk1 (talk) 14:31, 9 July 2019 (UTC)

I don't believe there's any tool for that, unfortunately. For images, I'd click one by one to the image description page, and if the summary is one big box titled "Non-free media information and use rationale" (like here), then the |Article= parameter may need changing. (I'll update the article to add this). Typical images are free, so you only need to bother about articles whose topic is something copyrightable and look for small depictions of that topic (like book covers), or logos, because that cover almost all allowed non-free uses. As for the 3. point, the templates ((merged-from)) and ((copied)) are almost never there, while if you just copy the WikiProject templates, someone will eventually fix their parameters anyway. Tokenzero (talk) 15:42, 9 July 2019 (UTC)

I'm contemplating different (proposed) options for merging articles that are quite broad in scope. To be specific, I'm seeking advice pertinent to these two merges:

• renewable energy and sustainable energy
• climate change (general concept) and climate system.

These four topics are all big enough to easily fill an article encylopedic article. In the first case, I think the overlap is about 70/80%. In common parlance the two terms are used as synonyms and I would say that a strong case can be made for merging. In the second case, I think climate change is only about 1/3 of the content of climate system. Both topics have separate books written about them and I wouldn't want to merge. What percentage overlap (in secondary sources preferable) are we typically looking for in such a case? My gut says 75%, but I have no experience in this. Femke Nijsse (talk) 11:37, 26 October 2019 (UTC)

Is there a standard template for proposing a merge on the article's talk page? If not, I think one would be helpful for starting discussions. Thanks. - BilCat (talk) 21:50, 24 December 2018 (UTC)

Hmm, how would that help? A merger proposal is basically just "== Merger proposal == I propose to merge [[Foo]] into [[Bar]]. <rationale...>". Tokenzero (talk) 22:01, 24 December 2018 (UTC)

You'd be surprised how often that is flubbed. (I can provide examples if needed.) I think standardizing the layout would be helpful, as is done now with Template:RM, along with some simple guidelines and instructions. - BilCat (talk) 22:07, 24 December 2018 (UTC)

Indeed. I periodically patrol for misplaced ((merge)) templates on talk pages, which are reported to me by my Merge bot in its console reports. See #FIX? : Instructs in use of obsolete/inferior templates. – wbm1058 (talk) 23:33, 10 January 2020 (UTC)

Glad this discussion was revived. When an article move is proposed, it is normally proposed on the talk page, using Template:RM, AKA Template:Requested move, and that's it, right? It seems so; its error message, "Template:Requested move must be used in a TALKSPACE," even 'enforces' it. The standardization BilCat proposes is sensible. It's the case now that templates for highlighting/fostering/tracking discussion of any type of proposal typically go on talk pages, not article pages. Thus, when an article merge is proposed, its consistent with that that the proposal be made on the talk page of the articles, NOT on the article pages themselves. Which is what I did below, and wbm says was misplacement. Currently, the existing templates are equally fit for use in each place. This documentation page says, "Tag the relevant pages." That is, it isn't explicit about whether the proposal goes on the talk page of the articles, or on the article pages themselves (AFAIK). (I don't mind being corrected. If I indeed misplaced, I was wrong, OK. I'm even happy to cede, for argument's sake, that I was, according to what they currently say.) But, where should the rules say templates for highlighting/fostering/tracking discussion of any type of proposal go? The rules largely say: on talk pages, not article pages. It seems to me that we haven't and don't need to make an exception for merges. Exceptions clearly make our rules unnecessarily complex, and should be avoided unless there's a clear, large benefit. So Merge bot should flag the other use -- use on article pages. IMVHO. --50.201.195.170 (talk) 09:39, 17 January 2020 (UTC)

This page doesn't talk about the categories at all. Lets say a non notable company is merged to its notable founder's bio. What happens to the category of the company ? This must be clarified in some way. --⋙–DBigXrayᗙ 21:59, 23 February 2020 (UTC)

That's covered at WP:Categories for discussion (as mentioned near the top of the section Wikipedia:Merging#Proposing a merger). Klbrain (talk) 21:48, 24 February 2020 (UTC)

It seems obvious that ((Merge to|OtherPage)) (figures out 'from' automatically) is better than ((Mergeto<requires more args>)). So the documentation here should be about the former, not the latter. Consensus? Improvements? --50.201.195.170 (talk) 17:01, 30 October 2019 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

For starters, I propose: s/((mergefrom|SOURCEPAGE|discuss=Talk:DESTINATION PAGE#Merger proposal))/((merge from|SOURCEPAGE))/

--50.201.195.170 (talk) 19:14, 30 October 2019 (UTC)

 Not done for now: please establish a consensus for this alteration before using the ((edit semi-protected)) template. Eggishorn (talk) (contrib) 22:04, 7 November 2019 (UTC)

Proposed in October. No disagreement. It's now January. Hence my first question below. --50.201.195.170 (talk) 10:07, 17 January 2020 (UTC)

1. Apropos the above edit request to Wikipedia:Merging from November: (When) Can I consider consensus to have been reached? If not, please provide opinions on my specific request and larger proposal.--50.201.195.170 (talk) 00:49, 5 January 2020 (UTC)

   See WP:MERGECLOSE for guidance. Since I just recently placed the appropriate merge templates at the top of Total dissolved solids, Total suspended solids and TDS meter, you may want to wait another week or more before closing it, if there are still no objections. wbm1058 (talk) 16:28, 11 January 2020 (UTC)

   You clearly misread my question/misplaced your answer. You're answering this as if it's my third question, when it's about something completely different. It's a good answer to my third question - I agree re waiting and appreciate the move, even though I changed my mind re the necessity thereof. --50.201.195.170 (talk) 10:11, 17 January 2020 (UTC)

   @50.201.195.170: I apologise for the extremely belated response. If I understand correctly, in the instructions at Wikipedia:Merging#Step 2: Tag the relevant pages, it says to put on the destination page the template: ((mergefrom|SOURCEPAGE|discuss=Talk:DESTINATION PAGE#Merger proposal)). You want to shorten that to just ((mergefrom|SOURCEPAGE)) implying that you think specifying |discuss=Talk:DESTINATION PAGE#Merger proposal is unnecessary. I don't understand why you think that. It is always better to include a link to the discussion if there is one. There should (ideally) be only one discussion, and the same link to the same discussion should be included in both the ((merge from)) and ((merge to)) templates. – wbm1058 (talk) 15:43, 29 May 2020 (UTC)

   @Wbm1058: Actually, please reread my first sentence: "It seems obvious that ((Merge to|OtherPage)) (figures out 'from' automatically) is better than ((Mergeto<requires more args>))." If you understand it, it should help the rest make sense...by the END of this comment. Does my first sentence make sense to you? No? Then compare:

   It has been suggested that SOURCEPAGE be merged into this page. (Discuss)

   It has been suggested that SOURCEPAGE be merged into this page. (Discuss)

   It has been suggested that this page be merged into SOURCEPAGE. (Discuss)

   It has been suggested that this page be merged into SOURCEPAGE. (Discuss)

   Now look at the source. See, the last one is smart (figures out 'from' automatically).

   I (?re-) propose: s/((mergeto|SOURCEPAGE|discuss=Talk:DESTINATION PAGE#Merger proposal))/((merge to|SOURCEPAGE))/

   -and I think that must be what I proposed or meant to propose originally.

   --50.201.195.170 (talk) 08:45, 12 June 2020 (UTC)

2. Could someone with template editing experience take a look at fixing the bug in ((Merge to)) demonstrated and commented on here?50.201.195.170 (talk) 01:20, 5 January 2020 (UTC)

   You haven't clearly indicated what the bug is. If there's a bug in these templates, it's that they let you put them on talk pages without reporting that this is an ((error)). I occasionally patrol for these and fix them. This problem is on my radar; see also #Talk page template. Making the article-merging processes easier to use and run more timely and smoothly remains on my longer-term to-do list. See also the discussions starting at WT:WikiProject Merge/Archive 3#Proposal to reduce incomplete merge proposals. That was the last time I implemented significant improvements. I only work at this part-time. wbm1058 (talk) 16:28, 11 January 2020 (UTC)

   Thanks. ... I've further clarified/extended my thoughts there and above. HTH. --50.201.195.170 (talk) 10:07, 17 January 2020 (UTC)

3. Per https://en.wikipedia.org/wiki/Wikipedia:Merging#Step_4:_Close_the_merger_discussion_and_determine_consensus, I suppose I could close the merge discussion on the merge of Total suspended solids and TDS meter into Total dissolved solids, but I think it'd be better if it was an uninvolved party, since there's been no input since I opened it. Since you're here looking at the above 2 requests, anyway please consider this one too. Update: I see I posted on each of the 3 talk pages, but I didn't post on the article pages - probably as a result of encountering the template bug noted above, but still - another reason to get at least some input before doing the merge. Struck because it's unclear whether they're for article or talk pages. Agree there's consensus and/or a strong case for the merge?50.201.195.170 (talk) 01:20, 5 January 2020 (UTC)

   I would be a neutral closer, but this is an area where you are more knowledgeable than I am. Maybe in a week or two I will take another look. – wbm1058 (talk) 16:28, 11 January 2020 (UTC)

I have made an edit to bypass redirects. Template:Mergefrom redirects to Template:Merge from and Template:Mergeto redirects to Template:Merge to. These were the old names of the templates from over ten years ago. – wbm1058 (talk) 11:07, 12 June 2020 (UTC)

"It seems obvious that ((Merge to|OtherPage)) (figures out 'from' automatically) is better than ((Mergeto<requires more args>))." — Sorry, no, I still do not understand what you are saying here. – wbm1058 (talk) 11:21, 12 June 2020 (UTC)

As an unregistered user you cannot change Wikipedia:Merging – hence the edit request here – but you should be able to read the source code of the page. Please open the page in read-only mode, then copy the portion(s) you want to change and paste them below. First paste the current source, then below that paste it again and edit the second copy to make the changes you propose so I can (hopefully) understand what you are saying. – wbm1058 (talk) 11:28, 12 June 2020 (UTC)

1. ((Merge to|OtherPage)) (figures out 'from' automatically)."

   Yes, 'from' is the title of the page the template is placed on. So, on this page the proposed merge is Wikipedia talk:Merging into OtherPage

2. ((Mergeto<requires more args>))."

   Yes, ((Mergeto)) (an alias for ((Merge to))) reguires at least one argument – the title of the OtherPage page that the proposer wants to merge Wikipedia talk:Merging into. That cannot be "automatically guessed".

I don't follow how "obvious" point 1 connects to the different point 2. – wbm1058 (talk) 11:16, 13 June 2020 (UTC)

"It seems obvious that ((Merge to|OtherPage)) (figures out 'from' automatically)black is better than ((Mergeto<requires more args>))white." —

No. Black is not better than white, nor is white better than black. They are just different colors. – wbm1058 (talk) 11:26, 13 June 2020 (UTC)

The ink is black. The page is white But it is not "obvious" that the ink is better than the page, because its not. wbm1058 (talk) 11:37, 13 June 2020 (UTC)

Seeing as many approved page mergers don't get completed, explicitly incorporating the ((Merging)) tag into the process would signal to other users that they can help merge the articles. Where in the process should this step be added? In my opinion, editors should immediately slap ((Merging)) onto a page in step 4 unless they plan to finish the merger themselves. Qzekrom (talk) 16:14, 17 February 2019 (UTC)

The problem with adding the merging template is that it suggests that someone else is dealing with the completition of the merge, so it might actually dissuade engagement. My view is that it is better to keep the proposal templates in place until the merge is completed, and that this is just as likely to engage interested participants. The other issues is that it lists the page in Category:Items to be merged, which at present seems to contain non-article space pages. So, perhaps it is better to keep that template for such non-article space pages. Klbrain (talk) 17:02, 17 February 2019 (UTC)

What if we added "You can help" to the ((Merging)) template? Qzekrom (talk) 23:05, 17 February 2019 (UTC)

Yes; that might work. Would be fine with me (also, retracted one of points above - must have been drinking some simple organic compound). Klbrain (talk) 20:12, 18 February 2019 (UTC)

In my opinion, maybe I'm in the minority here, but people shouldn't close merger discussions unless they also plan to actually complete the merger. Otherwise, there is no need to determine consensus yet and the discussion should remain open until someone else decides there is consensus and they're prepared to complete the merge. And, use of the ((Merging)) template should be used to signal to other editors that someone is in the process of completing a complicated merger and that it would be helpful to not have competing edits, and content edits should wait until the merger is completed (signaled by removal of the ((Merging)) template). I just don't see how it would be possible to beneficially have multiple editors completing a merger - too many cooks in the kitchen. Ideally a merge itself is two edits, blanking/redirecting of the source page and content added to the target page, followed by inevitable cleanup of the target page after the merge itself, in which all editors can participate. Mdewman6 (talk) 23:58, 11 September 2020 (UTC)

I've found that when I've proposed articles to be merged, there's not a flurry of people wanting to join in on the discussion. I'm not super happy saying "well there's no discussion so that's consensus by default". So instead I've started promoting the discussion on related project pages. I've started work on a short template for this: ((merge being discussed)). Do you think that promoting the merge discussion (not just to project pages, but to creator's user pages etc) should be a recommended part of the merge process? — Preceding unsigned comment added by Paul Carpenter (talk • contribs) 13:14, 1 October 2020 (UTC)

Some projects already automatically list merger proposals (and RMs/AFDs) on the project pages, though I don't think all do. I think it would be helpful for more projects to do so, though I have no idea how this is done. If a page is deeply related to a WikiProject and it's not automatically listed I try to post on the Talk Page linking to the discussion, which perhaps your template could assist with, though I haven't found this to be too productive in generating discussion. Personally, in general I think anyone with great interest in a page will be Watchlisting it and will voice opposition to the page being merged, and if this doesn't happen it can be taken as consensus. I don't generally support doing Bold merges without discussion, but on the other hand, I don't think we need a process akin to AFD or RM that unnecessarily involves other editors who are not involved with the particular page. What's crazy is that there is no discussion process for blank and redirects, which is what my Request for Comment is about above (and I can't even get anyone to comment on that!). Please comment! Mdewman6 (talk) 03:22, 2 October 2020 (UTC)

I can see the motivation for the proposal, but there is a bot for that! Organized projects, like Wikiproject Medicine, use AAlertBot to construct lists of proposal relevant to the project. For Wikiproject Medicine, for example, this creates a listed at Wikipedia:WikiProject Medicine/Article alerts, linked from elsewhere on the project pages, that can be used by project member to see relevant proposals. Projects that haven't set up such a system also aren't usually organized enough to have anyone respond. I've tried manually going to project talk pages to stimulate merge discussion, and my hit rate is about 1/5 for the promotion of any discussion at all (although 100% success at WikiProject Australia). I also wouldn't make merge proposals more complicated, so wouldn't add the requirement for additional notifications. We have enough problems with people only tagging one page, or not starting a discussion. Prompting those who started pages to engage in merge discussion is also not helpful, as it tends to promote unhelpful defensiveness (WP:OWNERSHIP); in this sense, page creators could be argued to have a conflict of interest in the discussion, and hence the voices independent of them are more helpful. Overall, my view is that we need more action (merging) rather than more talk (gesta non verba). In many cases, there is no discussion because the case is obvious, and if is not obvious then its probably not worth doing. So, where a merge is well-justified, obvious, with consensus, or uncontested (over a month or so), then I suggest being WP:BOLD yet ready for WP:BRD. If there is no case made, and the case isn't obvious, close without merging. Klbrain (talk) 08:49, 3 October 2020 (UTC)

More info at WP:AALERTS, you can see which WikiProjects subscribe at WP:AALERTS/LIST. --Redrose64 🌹 (talk) 18:59, 3 October 2020 (UTC)

A discussion is taking place to address the redirect Wkipedia:Merge. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 January 15#Wkipedia:Merge until a consensus is reached, and readers of this page are welcome to contribute to the discussion.

It's been a while since I've done this, so looking for advice on how to tag articles that are subject to a merge discussion where the proposed destination is a page that does not yet exist. (In this case, a possible merger of Michael Spavor and Michael Kovrig into Detention of Michael Spavor and Michael Kovrig or similar. Any help is appreciated. TheBlueCanoe 23:27, 4 July 2020 (UTC)

Use ((merge|Michael Spavor|target=Detention of Michael Spavor and Michael Kovrig|discuss=Talk:Michael Kovrig)) on the Michael Kovrig page and ((merge|Michael Kovrig|target=Detention of Michael Spavor and Michael Kovrig|discuss=Talk:Michael Kovrig)) or similar on the Michael Spavor page. You could use either of the talk pages for the discussion, as long as the merge templates both point to it. Klbrain (talk) 12:54, 5 July 2020 (UTC)

Thank you!TheBlueCanoe 14:15, 27 July 2020 (UTC)

The directions described above indeed work, whereas the ones actually described here at the project page did not. I updated and expanded the directions based on Klbrain's guidance here. I think I did it right. Mdewman6 (talk) 01:29, 1 December 2020 (UTC)

Those changes to the page look fine to me; thanks. Klbrain (talk) 08:48, 2 December 2020 (UTC)

The instructions say this should be done but is there not a bot to do it? If not is there an easy way to check which could be explained in the instructions? Chidgk1 (talk) 18:20, 18 October 2020 (UTC)

I agree that this check of non-free images is a routine maintenance task that shouldn't be included in the merge implementation; it is a separate process than can/should take place independently before/after merges by any editor. Any objections to deleting that action? It's currently point 6 at Wikipedia:Merging#How to merge. Klbrain (talk) 11:57, 16 November 2020 (UTC)

Support removing this step from instructions. This is not something specific to merging and not necessarily the merger's responsibility, as non-free images are an issue both pre- and post-merge. Users conducting merges should focus efforts on the merge itself. Mdewman6 (talk) 23:16, 16 November 2020 (UTC)

Wait, how is this supposed to work if not part of the merge process? If the merged content contains a non-free file, this file's description will need to be updated to point to the merge target. Other the file won't have a valid rationale and may get deleted. – Uanfala (talk) 18:04, 19 November 2020 (UTC)

I see Uanfala's point. However, the non-free-content designation is primarily a matter for the image page rather than the article. A concern for the use of non-free-content might be WP:NFCCP point 8, contextual significance, but it would be a strange case where contextual significance was valid for the initial page but not for the merged page. Regarding enforcement, concerned readers can trace image history back through the merged from templates, so there is a traceable path to historic justifications should that be necessary. Furthermore, challenges to images from time to time is probably a healthy process, as it forces us to reassess whether the justification remains valid; for example, contextual significance isn't a permanent attribute and it would be reasonable to challenge it from time to time. Klbrain (talk) 21:05, 19 November 2020 (UTC)

Well, it was my impression that when a file lacks a fair-use rationale, it's more likely to get automatically deleted than see people carefully assessing its ongoing contextual significance. I'm not offering any positions here because I don't have experience – I really only have to deal with fair-use images about once a year, but one case I remember was when I performed some simple topic restructuring while omitting to update the file page, with the result that the file got deleted by one of JJMC89's bots. If that's what normally happens, then the performer of the merge is the only person who can be expected to deal with the fair-use rationale. This may seem too niche, but isn't – it's part of the statutory cleanup after page moves, and it's one of the very few things that you'll see mentioned in the little message you get after moving a page. – Uanfala (talk) 21:28, 19 November 2020 (UTC)
Also clarifying – what's at stake in the instructions is not some overall big-picture evaluation of fair use, it's the very simple act of updating the title of the article mentioned in a file's fair use rationale, and that is expected to happen whenever that article title changes – say, when the article is moved, or when it's merged. – Uanfala (talk) 21:34, 19 November 2020 (UTC)

If a merge is carried out properly, a redirect from each of the older names should be left behind. If the FUR on the file description page has a link to the article for which fair use is claimed (and it should have one, per WP:NFCCP#10c), the link can be the abovementioned redirect, which means that the FUR still links to the page where the image is used, albeit indirectly (which is allowed by WP:NOTBROKEN). --Redrose64 🌹 (talk) 09:35, 20 November 2020 (UTC)

What if the talk pages of two pages need to be merged, for example to centralize discussion, but not the subject pages? What if one or both talk pages have archives? JsfasdF252 (talk) 00:12, 16 November 2020 (UTC)

You've given several reasons why talk pages shouldn't be merged. Centralizing discussion is therefore best done by adding, onto on of the pages, "Please discuss at <link to other talk page>. Klbrain (talk) 11:53, 16 November 2020 (UTC)

I have found two examples of talk pages for biography articles which need to be merged (two talk pages for one article). In both cases, it looks like the articles had different titles between the time they were created and now.

1) Talk:Diana Pullein-Thompson and Talk:Diana Pullein-Thompson (writer); if you click on the article link attached to the talk page for the one with the writer qualifier, it redirects to the article title without the qualifier; yet there are still two talk pages.

2) Talk:Augustus Lord Soule and Talk:Augustus Soule; similar situation, though in this case, one talk page uses a fuller form of the person's name.

Also, I have a list of talk pages which redirect to different people (usually two different people) and likely need separate talk pages. If anyone can help me with those, I can send that list separately.

Any help to solve these would be appreciated. Is there a documented procedure on how to fix these talk pages? Thank you.--FeanorStar7 (talk) 08:55, 2 January 2021 (UTC)

Feel free to add to, comment on, add problems you've observed, suggest solutions, or whatever:

The merge backlog has been growing shorter since 2012. It is now less than half (approximately 12+/- months) than it was in 2012 (regularly over 2 1/2 years). This is a big accomplishment, although it seems very slow in the actualization. The problem is man-power. What can we do to get more actors?

• Merging isn't the easiest thing to do and get right. Experienced editors interested in merging seem to be hard to come by. They are preferred–and almost mandatory–in the cases of:
  • merging and integrating the longer article(s), a more time-consuming process;
  • merging the more controversial subject(s), which make for a more complex and nuanced merge process, regardless of length.

To that end, can/will the experienced people at the Guild of Copy Editors be able to get more involved with the merging process? A sister-project relationship if you will.

• The people requesting merges may not always be the right ones to carry the merge out. Some people can really make a mess of things doing this. (See related wording discussion above.)
• We are left holding the bag sometimes in the case of merge requests arising out of AfD discussions. They send a lot of slop to us just because they are reluctant to pull the trigger on an article that really just needed to go away (some without one citation or even any sources), and decide merging is a valid option. Those generally just get deleted by "merge" because, well, there's nothing cited to get merged. Can some AfD discussion closers address this?

These are the major concerns I see at the moment. Suggestions are welcome. GenQuest ^"scribble" 16:14, 31 May 2021 (UTC)

Solution: fold the merge process into RFC, and allow the wider community to help address it. Currently, any attempt to bring in the wider community with an RFC, is reverted as WP:RFCNOT (which isn't even a policy or guideline) by well-meaning, but entirely misguided editors who believe upholding informal rules that don't work is the way forward. If you want to solve the backlog and bring a wider sample of the community to bear on the problem, allow RFCs to advertise the merge requests. Viriditas (talk) 21:59, 17 June 2021 (UTC)

It's been there for more than two years now (see discussion). Basically: if the thing you want to discuss has its own set of tagging templates that put pages into a dedicated set of categories, cause an entry to be added to a noticeboard, or both, then RfC is not suitable because it would bypass the established process. In this case there are ((merge)), ((merge from)) and ((merge to)) together with categories like Category:Articles to be merged from June 2021 and Category:All articles to be merged. --Redrose64 🌹 (talk) 19:18, 18 June 2021 (UTC)

Case in point. You completely avoided my point about getting more eyes on a merge proposal by using the RFC process. RFCNOT is neither a policy nor a guideline, and may not reflect the consensus of the community, as the tag at the top explicitly states. Viriditas (talk) 20:12, 18 June 2021 (UTC)

If you think consensus is something different from what is written in WP:RfC, please explain. The fact that someone put the rule against using RfC for merges there and others suffered it to stay, suggests consensus is for the rule, at least generally. You're opposed to applying rules in an information page that don't work, which you say includes this rule, but it looks to me like it's working the way it's supposed to.

The theory of the WP:RFCNOT rule is that people who want to help with merges do so via the merge-proposed categories. If there aren't as many people interested in working on merges as you would like, you cannot rightly command the attention of more people by enlisting the RfC process. RfC commenters are people who are interested in helping to establish consensus on page content by offering additional viewpoints. Lack of viewpoints does not seem to be what is causing the merge backlog, so I don't see how RfC is an appropriate way to increase the number of contributors. Bryan Henderson (giraffedata) (talk) 19:54, 20 June 2021 (UTC)

I'm sorry, what? You wrote, "If there aren't as many people interested in working on merges as you would like, you cannot rightly command the attention of more people by enlisting the RfC process." Well, that's exactly wrong. You can rightly command the attention of more people, particularly so-called knowledge experts in their respective subtopics, using the RFC process, and that's exactly how it is currently used today. For example, if there is a merge request sitting on the talk page of negative space, advertising it under the arts and related topic as an RFC, would bring in many dozens of users with knowledge and expertise and time to address the merge. It's amazing how much time and energy is spent by people on Wikipedia opposing real change and progress. It's just unbelievable. When was the main page last redesigned, 2004? Unbelievable. Viriditas (talk) 20:44, 21 June 2021 (UTC)

To partially address Viriditas's concerns, note that the current merge process can already alert projects to the need for more eyes. For example, the is a merge article for negative space on the Visual Arts Article Alert; see Wikipedia:WikiProject_Visual_arts#Article_alerts (just two down from Requests for comments). Furthermore, I see much bigger backlogs for other maintenance tasks; so as much as it would be nice to have more people involved, the effort of volunteers might be better spent elsewhere. Progress on merges has also been underestimated; the 2012 backlog was around 15,000 articles, and now the average over the last year has been around 3,0000 articles. So, while the backlog duration has reduced, the number of pending articles under discussion has decreased even more significantly. Klbrain (talk) 12:02, 22 June 2021 (UTC)

I agree with many of the comments above. I actually think the merge procedures have the potential to work fairly well, the problem is that most people don't follow them. I agree the underlying cause for that is that there are more users who want to see merges happen than those who are actually willing and capable of carrying them out. I have seen many tagging pages for merge discussions who don't actually start a discussion to formally propose the merge. I guess this is semi-helpful in that it indicates at least 1 editor supports a merge and maybe another user with the ambition to merge will come along and BOLDly do the merge, seizing this two-editor consensus and bypassing the discussion step. Others forget to close discussions before doing the merge, or only tag one of the pages, etc. One potential solution is to create a centralized discussion base akin to requested moves, but isn't this what WP:Proposed mergers is for? I have never used that, and the merge procedures here barely mention it. Perhaps better integrating that would address some of the participation concerns, like automatically listing merge discussions there (like requested move discussions are at RM). Perhaps this would require substituted templates? I'm not the one to address this.

As for merges coming from AfD, I think AfD discussions need to clearly differentiate between a merge and a blank and redirect. If there is content that should be merged, the discussion ideally should identify what content, or at least establish that indeed there is content that is worth transferring to the target article. If not, the outcome should be a simple blank and redirect that the closer can easily complete without punting over to the merge process. Perhaps the AfD guidelines should be edited to make this clear? The closing instructions could be edited to indicate that any consensus for a AfD:merge should default as a BLAR unless the discussion clearly articulates there is content that should be merged. Post BLAR, any user is then free to boldly merge content from the blanked page into the target, or start a merge discussion about whether or not to do so, or go back to AfD with a more refined question. I think BLARs and merges need to be much better differentiated and handled on WP, but my thoughts were largely shot down in the RfC above.

I certainly share Viriditas's sentiments about the community being resistant to fixing things (again, like the RfC above), but I agree that the RfC process is not the answer to solving the merge backlog. Again, I am not familiar with WP:proposed mergers, but I would imagine that it likely can be leveraged to both gain more visibility for merge discussions and also to enlist those willing to complete merges. But I think this is already the case, and the backlog is what it is. I propose many merges and usually close the discussions myself and perform the merges myself, but I realize that makes me neither the problem nor part of the solution. Many WikiProjects automatically track related merge discussions with a bot (as noted above) and more projects should do so. Merge discussions can also be manually advertised to projects or specific editors. The tools are there, we just need more people to use them, and perhaps better integrate them to facilitate their use.

Lastly a minor issue, but as I've noted before, I think the directions here misstate the purpose of ((being merged)). The directions imply it can supposedly be used to recruit someone to "help" with the merge, but really, one user should complete at least the initial merge steps, otherwise it can become an unbelievable mess. I think really the only purpose this template serves is the opposite, saying someone is working on the merge, so please don't edit these pages at the moment. Do others agree or are similarly confused? Should we edit the merge directions here to clarify the use of this template? I think this template gets little use, but perhaps it can serve a better purpose. Mdewman6 (talk) 20:58, 22 June 2021 (UTC)

I guess the template text does imply the former interpretation, but again I don't see the value in it and believe it could be counter-productive. Perhaps the template should be edited so the opposite use I mentioned could be realized, but that would require a specific discussion and would likely (again) meet resistance. Mdewman6 (talk) 21:06, 22 June 2021 (UTC)

I propose changing the second paragraph to something like the following:

Any editor can perform a merger. No permission or discussion is needed if you think the merge is uncontroversial; just be bold and do it (but it might get reverted). If you think the merger would be controversial consider starting a discussion first as detailed below. Even if a merger is potential controversial it is allowed and often faster to implement the merger first and discuss it on the talk page if anyone objects to or reverts the merger.

This emphasizes that users are free to be bold and implement mergers without prior discussion as long as they are willing to discus if objections are raised.

Current version for reference.

Any editor can perform a merger. No permission or discussion is needed if you think the merge is uncontroversial; just do it (but it might get reverted). Otherwise, the merge should be first proposed and discussed, as detailed below.

Thoughts? --Trialpears (talk) 17:59, 6 May 2021 (UTC)

• Oppose. Doing merges on a bold-revert-discuss cycle is messy, because two pages are affected. A bold merge could be made and reverted days, weeks, or months later, making a mess of the merge target because there have likely been edits to the page post-merge. Thus, a bold merge is very different from a bold blank and redirect, which more or less only affects one page and can more easily be returned to the status quo ante. I think that tagging the pages for a week and starting a section on the talk page explaining your plans and rationale to check for consensus/objections is a good idea in most cases to try to avoid reversions. Then there is a record of how things proceeded. Bold merges are called for when merges are obviously an improvement, like when a stub is a clear content fork. Mdewman6 (talk) 18:48, 6 May 2021 (UTC)

  My main goal with this change would be decreasing the backlog. I know reverting mergers can be quite messy, but I feel, with no evidence, that the negatives from slightly clumsier reverting of mergers would be less than the positives of more good and uncontroversial mergers being implemented in a timely fashion.

  Another approach I've been thinking about would be having a bot notify users that it's fine to implement a merger if their proposal gets no comments in say two weeks. Of course such a message would have to be well crafted and not have false positives, but I think it could have a not insignificant impact. --Trialpears (talk) 20:04, 6 May 2021 (UTC)

I agree that failing to close merge discussions and actually follow through with the merge is a significant problem. Also, sometimes pages are tagged for merging without a discussion being started on talk, or only 1 or no pages are tagged. Perhaps this page should be edited to emphasize that those starting merge discussions can close them and perform the merge themselves? I think some users think it is like a RM discussion and they are not allowed to perform a close/merge for a merge proposal they initiated.

I think a bot would be a great help. Ideally, there would be something at Twinkle developed to setup the merge proposal and discussion too. Both of these would help with the process being completed. Mdewman6 (talk) 20:27, 6 May 2021 (UTC)

• Oppose - The existing advice is simpler. I don't think WP:BRD works well with mergers. If the goal is to decrease backlog, a wider discussion would be more appropriate. ~Kvng (talk) 13:52, 9 May 2021 (UTC)
• Support but merging by Twinkle would be better I am fed up with the tedious merge procedure which should have been automated years ago. I have done lots of merges and the only one that was reverted was one where I had started a discussion and no one replied. Months later someone objected and reverted the merge. If I had done it without discussion it would have been a lot less work for me. Chidgk1 (talk) 15:34, 10 May 2021 (UTC)
• Weak oppose: existing wording is better, encouraging discussion, but if a proposal is uncontested for many months then I agree that merging when there are no objections is fine. However, I think that it's right to give page-watchers and passers-by fair warning of an impending merge, and the reasons for it. Regarding bold actions, we already have If the need for a merge is obvious, editors can be bold and simply do it, which I think covers the barn-door cases. Klbrain (talk) 11:53, 12 May 2021 (UTC)

Given comments by Chidgk1, I'll share my recommendation for easy-merge as a helpful script for semi-automated merging; I'm a regular user ... Klbrain (talk) 11:53, 12 May 2021 (UTC)

Thanks to whoever wrote that, BTW. GenQuest ^"scribble" 16:14, 31 May 2021 (UTC)

To be clear, the current protocol is to wait at least 7 days to allow for discussion, at which time discussions with no participation can be closed as consensus to merge per WP:CONSENSUSWP:MERGECLOSE and WP:SILENT. I believe discussions are a good move in a majority of cases, but no need to delay a merge for more than a week if there is no discussion. Tagging the pages and waiting a week will catch opposition from the most likely to revert a merge after the fact, such as an article creator who is watchlisting the page.

As I mentioned above, I do think we should tweak the wording to make clear that those starting merge discussions can close them and complete the merge. I think this is a major hangup in the system, as some people may treat them like requested move discussions. If there are no objections, I will make a change. Mdewman6 (talk) 17:40, 12 May 2021 (UTC)

• Weak Oppose on the wording change per above statements. I also think more discussion should be encouraged and is needed around here. Granted, some requests get little to no participation anyway (especially in the minimum 7 days), but waiting 7–21 days (or even longer in some cases) on closing a merge request will not break Wikipedia. What breaks the merge process is that the approved merges (especially the complex or very big ones) don't immediately happen, often for a very long time. I do think a broader discussion is needed in the project directed towards finding and retaining mergists to do that work. (See below.) GenQuest ^"scribble" 16:14, 31 May 2021 (UTC)
• Oppose. I don't trust that this would work well, if at all. Aiming Guides (talk) 09:06, 29 June 2021 (UTC)

The suggested wording for starting a merger discussion is itself a bit wordy:

I propose to merge [[Foo]] into [[Bar]]. I think that the content in the Foo article can easily be explained in the context of Bar, and the Bar article is of a reasonable size that the merging of Foo will not cause any problems as far as article size is concerned.

I would suggest:

I propose merging [[Foo]] into [[Bar]]. I think the content in Foo can easily be explained in the context of Bar, and a merger would not cause any article-size problems in Bar.

Shenrichs (talk) 21:44, 10 September 2021 (UTC)

I support making the phrasing more concise. I don't think it's terribly important, as it's just an example of how to start a discussion. Unfortunately a lot of users just fling the merge templates on to pages without actually doing this step of starting a discussion to propose why they think the merge should occur... Mdewman6 (talk) 00:28, 11 September 2021 (UTC)

Support the simplification. It does appear on many proposal, so is worth improving. Klbrain (talk) 11:57, 11 September 2021 (UTC)

I've made some further improvements to avoid duplicate talk page headings and mention WP:UNDUE. ~Kvng (talk) 17:05, 14 September 2021 (UTC)

@Crouch, Swale: I reverted your edit on process, where you added a step requiring Wikidata editing as part of the merge process. I can see that this would be helpful, but we have trouble enough getting editors to complete steps 1-7, and so adding an 8th step (and a rather complicated one) is undue. My specific concerns are that:

1. It requires an additional action on a sister project, whereas the Wikipedia merge process should be aimed at resolving problems on Wikipedia
2. The claimed basis of the merge is incomplete (and something that I've fallen foul of in the past when proposing a Wikidata merge). A merge on English Wikipedia is not sufficient to warrant a Wikidata merge; it requires an agreed merge on all language Wikipedias. We don't extend the merge process on en.wiki to all other languages, and so we also shouldn't add a Wikidata merge step.

Klbrain (talk) 07:48, 26 October 2021 (UTC)

OK, that's fine. Crouch, Swale (talk) 08:13, 26 October 2021 (UTC)

I propose there be one Wikipedia Info page and this be merged into it. Ilovehugging (talk) 23:31, 4 February 2022 (UTC)

Oppose, on the grounds of WP:TOOBIG. I imagine that this counts as inappropriate humor, of perhaps someone feeling hurt. I suggests that Ilovehugging gives themselves a big hug and gets on with constructively editing. Klbrain (talk) 20:03, 6 February 2022 (UTC)

Thanks! I didn't know WP:TOOBIG even existed until now. Ilovehugging (talk) 22:41, 6 February 2022 (UTC)

I proposed a merger of Differential (infinitesimal) into Differential (mathematics) and created User:Chatul/Sandbox/Differential (Mathematics) as a talking point, with the intention of copying it after making suggested changes. Was that appropriate and how do I solicit comments on the merged version. If that was not appropriate, what is the best way to maintain usability of the to article will doing an extended series of updates? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:35, 4 March 2022 (UTC)

Interested to hear other's perspectives, but I think this is fine but must be done carefully. I think it's fine to copy stuff as a "test" merge, and then link to it in a discussion to get feedback. However, when actually executing the merge, it's essential that the merge take place from the current version of the source to the current version of the target page (in other words, carefully heed WP:Copying within Wikipedia). If there have been any intervening edits since adding the content to the sandbox, those edits need to be reflected when executing the merge; for this reason it will usually be best to repeat all the work you did in your sandbox with the actual pages. Per WP:MERGE, it is best to merge the content into the target page as one edit, then cleanup/rearrange as necessary in subsequent edits, to make the history cleaner and less confusing, even if the actual process is messier and makes the pages temporarily messy. So, do the merge first, then do whatever updating/cleanup is necessary to the merged page separately, and that point, other editors can help too since the merge part is done. Hopefully all that makes at least some sense...basically, use your sandbox as a tool if it is helpful, but make sure to still follow the rules for attribution at WP:Copying within Wikipedia and WP:MERGE. Mdewman6 (talk) 01:21, 4 March 2022 (UTC)

This is good advice. WP:CWW applies to all pages, so the sandbox is currently an unattributed copy that should be repaired per WP:Copying within Wikipedia#Repairing insufficient attribution. XOR'easter edited the sandbox, so they must be attributed when it is merged. The best method in this case is in an edit summary as described by WP:Copying within Wikipedia#List of authors. Flatscan (talk) 05:32, 5 March 2022 (UTC)

What is the appropriate time to remove the ((Old merge full)) template from the source talk page? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:34, 8 March 2022 (UTC)

I think that it's permanent. --Redrose64 🌹 (talk) 17:00, 8 March 2022 (UTC)

I want to merge Quimbaya artifacts with Quimbaya, but what do I do with Talk:Quimbaya artifacts which I should presumably merge with Talk:Quimbaya? I don't find the explanation clear enough to implement. Thanks. Doug Weller talk 14:47, 17 May 2022 (UTC)

Generally speaking, talk pages are not merged, instead they become the talk page of the redirect, and any old discussions can remain there as an archive. It is a good idea to reconcile the WikiProjects (WP:PROMERGE step 3). In this case, for Talk:Quimbaya artifacts, I would remove the photo request banner, since redirects cannot have photos, and change the class of the wikiprojects from "stub" to "redirect". You could also add one of the copied templates (step 4), but this is optional as long as you leave appropriate edit summaries, saying what was merged where. Hope that helps. Mdewman6 (talk) 20:59, 17 May 2022 (UTC)

If, instead of changing the class from "stub" to "redirect", you simply blank out the parameter, as in |class= (or remove it entirely), most WikiProject banners will autodetect it as a redirect. The only one that won't do this is ((WikiProject Military history)) which requires an explicit |class=redirect - even the commonly-used contraction |class=redir won't work. The advantage to using the autodetect feature is that should the subject page ever be altered from a redirect to an actual content page, the WikiProject banners will spot this and change to Unassessed automatically. --Redrose64 🌹 (talk) 23:04, 17 May 2022 (UTC)

 You are invited to join the discussion at Wikipedia:Village pump (idea lab) § Merge reform. ((u|Sdkb)) ^talk 16:58, 10 July 2022 (UTC)

Should I redirect Talk:2022 Minnesota’s 1st congressional district special election to Talk:2022 Minnesota's 1st congressional district special election (difference in apostrophe), as the prior article was a duplicate of the latter article, and has been merged? This page isn't very clear about what to do with talk pages of duplicate articles that have been merged. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 07:31, 20 February 2022 (UTC)

I believe generally talk pages are not redirected following a merge, the talk page of the source page is kept as the talk page of the redirect. This is to preserve the history of that talk page. However, any categories/wikiprojects, etc.. that would apply to the target page should be added to the talk page of the target page, and deleted from the talk page of the redirect if they no longer apply. I agree we should probably say something about this in the merge procedures. Mdewman6 (talk) 17:58, 20 February 2022 (UTC)

CX Zoom, This is discussed in the above see also link. Talk-pages that have never been used for discussion are redirected to the target article Talk-page; A talk-page that has discussion content, should have the following template placed on the first line (without removing the old discussions, but replacing all other templates—including most project assessment templates (some projects want to keep these; they will correct as necessary). The exception is any Archive Index:

((merged-to|~destination page name~|date= )) ~~~~ That renders as (sample):

The contents of the Wikipedia:Merging/Archive 3 page were merged into Jimmy Wales on July 2, 2100. For the contribution history and old versions of the merged article please see its history.

Regards, GenQuest ^"scribble" 22:44, 21 August 2022 (UTC)

Thank you GenQuest, thank you Mdewman6. This was very helpful. —CX Zoom[he/him] ^{(let's talk • {C•X})} 23:36, 21 August 2022 (UTC)

There is a merge request at Talk:London#Merger proposal which you might want to check. Right now, there doesn't seem to be consensus for the move, but I am hoping with more participants that might change. The discussion only started two days ago. One thing that might help attract more participation is adding a merge notice at London. I added it, but it was repeatedly removed. Should the merge notice be added back since the discussion is still ongoing? Thanks. Vpab15 (talk) 22:29, 29 July 2022 (UTC)

Closed, no merge ~Kvng (talk) 13:54, 24 August 2022 (UTC)

There are two sets of articles about the same village: https://www.wikidata.org/wiki/Q2453151 and https://www.wikidata.org/wiki/Q20858800 How can one merge them? --Bero231 (talk) 17:24, 21 September 2022 (UTC)

Pinging: @Trialpears:, @Paine Ellsworth:, @Klbrain: and/or @Wbm1058:. GenQuest ^"scribble" 18:37, 21 September 2022 (UTC)

See wikidata:Help:Merge. – wbm1058 (talk) 18:57, 21 September 2022 (UTC)

I suggest adding Wikipedia:Semi-duplicate as one of the reasons at WP:MERGEREASON. Crouch, Swale (talk) 20:31, 27 August 2022 (UTC)

• I have the same objection David Eppstein did. This looks like an essay roughly describing content forks. Protonk (talk) 22:20, 27 August 2022 (UTC)

  Its quite different in that a semi-duplicate may not be a content fork due to information specifically about it not largely duplicating the other page on the other hand you may have 2 very distinct topics but information is duplicated but this should be resolved by removing the content for the other topic instead of merging. Crouch, Swale (talk) 16:35, 28 August 2022 (UTC)

  If what distinguishes it is the resolution being editing and not merging, why are you proposing it be added to a reason to merge? Protonk (talk) 16:56, 28 August 2022 (UTC)

  Because its useful in the sense of pages that shouldn't be separate regardless of the quality of the articles in question and giving examples of topics that are generally combined. Crouch, Swale (talk) 19:36, 28 August 2022 (UTC)

  @Protonk: Wikipedia:Semi-duplicate#Difference between semi-duplicates and other problems provides more explanation on this. Crouch, Swale (talk) 19:00, 5 September 2022 (UTC)

  Thanks for adding some color on that. I was hoping that someone else other than you or me would pop by and have some comment. I don't know that we need to add it to the page, and if we do I'd rather we add it somewhere other than an explicit reason to merge. However, I am not an active enough maintainer of this page to feel like my objection is dispositive. So if you want maybe you could add it to the page and see if that brings anyone out to object who might otherwise not notice the talk page discussion. Protonk (talk) 16:37, 6 September 2022 (UTC)

  @Protonk: I've added it as suggested to see if there is any other comments/objections. Maybe it could instead be covered in the "Overlap" part but I'd suggest it can have its own part. Crouch, Swale (talk) 17:14, 6 September 2022 (UTC)

Oppose: I think that overlap is sufficient, and that semi-duplication is an unnecessary, ah, duplication. Klbrain (talk) 11:40, 29 December 2022 (UTC)

Would it be better to combine it with "Overlap"? Crouch, Swale (talk) 07:15, 5 January 2023 (UTC)

Oppose: as Klbrain says above. GenQuest ^"scribble" 02:41, 5 January 2023 (UTC)

@Crouch, Swale: combining semi-duplication with overlap, using the long-standing overlap as the key concept would be fine, although given the arguments made above I don't think that it's necessary. However, if you wanted to link your essay to in the overlap point I'd have no objection. Klbrain (talk) 18:42, 5 January 2023 (UTC)

@Klbrain: How about I just add "Just like topics with the same or similar name that would normally be expected to be covered in a single article for example Greenland deals with both the country and island (which have similar boundaries) thus a Greenland (island) can be merged with the "Greenland" country article, see Wikipedia:Semi-duplicate." Would that work as it avoids potential redundancy but I think the essay is helpful and it includes references to islands which also references User:Seav/Islands and administrative units created by another uses back in 2014. Crouch, Swale (talk) 18:47, 5 January 2023 (UTC)

@Klbrain, GenQuest, and Protonk: I've merged the "Semi-duplicate" entry into the "Overlap" one. Crouch, Swale (talk) 19:37, 20 February 2023 (UTC)

Is there such a thing as a tool that can identify identical or substantially similar references? I am merging two articles that were content forked 10 years ago and they both use very similar source material, but my human brain can't spot the redundant sources among the 113 footnotes. Schierbecker (talk) 02:38, 10 January 2023 (UTC)

Leave it for a WP:GNOME? It takes a village. ~Kvng (talk) 14:17, 26 February 2023 (UTC)

refill will consolidate duplicates that are identical, but not those that are 'similar'. Klbrain (talk) 11:06, 27 February 2023 (UTC)