Wikipedia talk:Merging

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)

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 and also states when  is required, but it requires reading between the lines for the intermediate case. 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 and it restates the point before the uninvolved editor case: . 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:
 * The result is obvious (to everyone involved in the discussion), so "any user" can close it, or
 * 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)

Short text is not the same as insufficient notability
The description for short text gives an example of a person who is not independently notable, but this seems like a poor example as you could have a notable topics where not much can be said about it, but it could easily be a subtopic of a broader article, and you could potentially write a lot of text about a non-notable person. Should this reason be split into two: Short text and Insufficient notability? --Ahecht (TALK PAGE ) 21:36, 30 April 2024 (UTC)
 * You're absolutely right; there are two separate point here: Short text and Insufficient notability. I agree that the short text example should include an example where the subject is notable. For example, there's a current proposal to merge a series of cars, the Dallara F308, Dallara F312 and Dallara F317 into one page for the series (short text and context); each might meet notability if independently assessed. So, we could give an examples such as "merging a series of race cars with a shared developmental history into one page for the series".
 * For the insufficient notability notability criterion, this is already policy through the AfD proposal route, many of which end with an AfD-merge outcome as an alternative to deletion (WP:DISCUSSAFD). We already have many editors using AfD as a surrogate for getting a merge done, and it would be procedurally simpler if they could do this directly through a merge proposal with greater policy support form this project. Klbrain (talk) 08:59, 5 May 2024 (UTC)
 * I think this is a good idea. @Klbrain, would you implement it? WhatamIdoing (talk) 01:14, 15 June 2024 (UTC)
 * Texto corto: Se refiere a la longitud del texto. Un texto corto es pequeño, especialmente en cuanto a la longitud, duración o extensión1. No necesariamente implica una falta de contenido o calidad, sino simplemente que es breve.
 * Notabilidad insuficiente: Esto se refiere a la calidad del contenido y su relevancia. Un contenido con notabilidad insuficiente es aquel que no cumple con los criterios necesarios para ser considerado significativo o relevante dentro de su contexto1. No tiene que ver con la longitud del texto, sino con su importancia o impacto.
 * Es importante destacar que un texto puede ser corto y aún así tener notabilidad, mientras que un texto largo podría carecer de notabilidad si su contenido no es relevante o significativo. La clave está en el valor del contenido más que en su extensión. 189.216.28.204 (talk) 04:35, 15 June 2024 (UTC)
 * Thank you for the suggested Spanish text that might work in translation. Klbrain (talk) 05:58, 15 June 2024 (UTC)
 * I've added this as the new 4th criterion, splitting the former 3rd. Klbrain (talk) 06:22, 15 June 2024 (UTC)

The see also section?
I think a link to the 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)

AfD-merge to
Template:Afd-merge to states it will be replaced by a bot when the merge is complete. This is not covered in our instructions here, which state to handle all the tags manually. Can this exception be added with its relevant instructions? CMD (talk) 10:09, 6 June 2024 (UTC)
 * Agree. Perhaps a subsection explaining this case be added to Merging explaining how the process differs in this case. Klbrain (talk) 06:17, 8 June 2024 (UTC)

Earlier into later?
When merging, is it a rule that the article created earlier should stand and the later created article be redirected into later? Or it doesn't matter? I'd support the above rule to avoid disputes, but I can't find it anywhere. . VR (Please ping on reply) 17:54, 13 July 2024 (UTC)


 * In Nuseirat case, there are currently two articles, one about the rescue and one about the attendant massacre. Lots of back and forth on that one but no final resolution as yet. If the two articles are about the same thing then yes, later into earlier but they should clearly be about the same thing so that the later is in effect a fork. Selfstudier (talk) 17:59, 13 July 2024 (UTC)
 * Yes; see WP:REDUNDANTFORK. BilledMammal (talk) 18:42, 13 July 2024 (UTC)
 * @BilledMammal thanks! VR (Please ping on reply) 19:08, 13 July 2024 (UTC)

Best option for merging two articles into a new (third) title?
Hi all, seeking clarification on the best or normal practice for merging two articles into a completely new title. Should we: I hope the question is clear. If helpful, the context is this discussion (where neither of the two articles is the primary or more general topic, so there's no obvious direction to merge into and the merged topic would need a new title either way). Thank you for any advice, R Prazeres (talk) 19:22, 15 July 2024 (UTC)
 * 1) Create a third article with the new title and copy content from the older two articles into it.
 * 2) Pick one of the existing two articles (e.g. maybe the older or more visited one), merge the other article into it, and then move the merged topic to the new title.

PAGE]]) 19:27, 15 July 2024 (UTC)
 * @R Prazeres I would copy content from Emirate of Córdoba into Caliphate of Córdoba, since the latter has significantly more edit history (292 edits dating back to 2006 vs 973 edits dating back to 2004). --Ahecht ([[User talk:Ahecht|TALK
 * Great, thanks! R Prazeres (talk) 19:33, 15 July 2024 (UTC)