Wikipedia talk:Merging

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
WikiProject iconMerge
WikiProject iconThis page is within the scope of WikiProject Merge, an attempt to reduce the articles to be merged backlog and improve the merging process. If you wish to help, you can edit the page attached to this talk page, or visit the project page, where you can join the project and/or contribute to the discussion.
WikiProject iconWikipedia Help B‑class Mid‑importance
WikiProject iconThis page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
BThis page does not require a rating on the project's quality scale.
MidThis page has been rated as Mid-importance on the project's importance scale.

Multiple options to resolve multiple overlapping WP:REDUNDANTFORKs[edit]

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
Possible target pages

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)[reply]

"Merge" instead of "Merger"[edit]

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)[reply]

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)[reply]

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)[reply]
Support the change to "merge". Klbrain (talk) 11:59, 24 June 2023 (UTC)[reply]

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

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.

Merging clusters of articles in different languages[edit]

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)[reply]

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)[reply]

Semi-protected edit request on 13 October 2023[edit]

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)[reply]

 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)[reply]
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)[reply]
See? I'm just a dense moron. Disregard me here! --Pinchme123 (talk) 14:53, 13 October 2023 (UTC)[reply]
 Done. I replaced it with a different space agency logo. Anon126 (notify me of responses! / talk / contribs) 14:37, 17 October 2023 (UTC)[reply]

Talk page archives[edit]

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. Rjjiii (talk) 20:06, 4 January 2024 (UTC)[reply]

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)[reply]
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)[reply]
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.
Rjjiii (talk) 17:08, 15 January 2024 (UTC)[reply]
@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)[reply]
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. Rjjiii (talk) 02:42, 22 January 2024 (UTC)[reply]

Optionality of tag indicating a merge[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    But I didn't say mandatory, I simply removed the emphasis on optional. Regards, Thinker78 (talk) 18:43, 12 January 2024 (UTC)[reply]
    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)[reply]
    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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]