Archives

Archive 1 Archive 2 Voting archive "Mergewith" (superseded) discussion archive Template_talk:Merge/Archive3-to-Jan2007

This talk page is for the discussion of the following templates:

• {{merge}}
• {{mergeto}}
• {{mergefrom}}
• {{merging}}

Please be clear in your comments which template you are referring to.

Only some of these templates have been protected. But since these templates should work similarly, please discuss any changes on this talk page first. Any user can edit the documentation, add interwikis and categories, since as usual the /doc sub-pages are not protected.

I honestly don't understand why the {{merge}} template exists. It could easily be superseded by {{mergeto}} and {{mergefrom}}, both of which direct merge discussions to a specific talk page, easing the process and allowing consensus to be reached much faster. This template could be changed to guide users to use one or the other. I was just about to place {{tfd|merge}} onto this page, but it's protected. If anyone with more power than me agrees, could you please comment here or finish what I can't? Thankyou :) Jack · talk · 13:46, Sunday, 25 February 2007

To use {{mergeto}} and {{mergefrom}} is to say that article A should be merged into B (as opposed to merging B into A), i.e. it gives the two articles different "status", which is not always what we want to do. Brian Jason Drake 03:16, 27 March 2007 (UTC)[reply]

Further to my previous comment , see #Reverse merger proposals above. Brian Jason Drake 03:27, 27 March 2007 (UTC)[reply]

It's far simpler than that... it's a tool some are comfortable with, and who are you to steal a tool from a person's toolbox, costing them time and effort to learn something new, when the outcome is identical. Have the stuff proposed at TFD shouldn't be as it's impolite to ask others such things, and it's hardly an imposition on the systems memory to keep an template around that someone (anyone) finds useful. The biggest problem with most tool templates is that they aren't well documented and easy for laypeople to understand those which are documented. That's what WP:TSP is aimed at fixing. Best regards // FrankB 20:32, 7 April 2007 (UTC)[reply]

Not sure where the appropriate place to put this is, but I found the following line in Mass-energy equivalence, which obviously doesn't render very well:

{{Merge|E%3Dmc%C2%B2|date=February 2007|Talk:E%3Dmc%C2%B2#Merge_with_Mass-energy_equivalence}}

Is this correct usage of this template?

Brian Jason Drake 03:19, 27 March 2007 (UTC)[reply]

• "E%3Dmc%C2%B2" is because the magic words used are full url friendly vice people friendly. See the magic word forms with the double 'EE' suffixes. It is however, no problem, save for the strangeness to look at as the links work. Looks like a consensus exists to merge those two pages now, if someone has time and is into physics or science. Best regards // FrankB 20:41, 7 April 2007 (UTC)[reply]

• • Huh (didn't understand a word of that, except for the last sentence)? Brian Jason Drake 08:28, 9 April 2007 (UTC)[reply]

Please remove the Template:Wikivar variable from the categories as we now have the Template:Wikivar to take care of it on article pages. I'd also like to request that Template:Wikivar be added in the noinclude section of the template as well. Dread Lord CyberSkull ✎☠ 07:56, 29 March 2007 (UTC)[reply]

As I understand it, defaultsort sets a default sort key and is appropriate for articles like Paul Cohen (mathematician), which is often alphabetized under C. This is perfect for homogeneous categories like Category:Mathematicians. But in heterogeneous maintenance categories like these, it is the actual ASCII name of the page that is of interest; I wouldn't expect to have the category sorted by last name because not all articles are about people. So I would expect Paul Cohen's article to be sorted under P.

So, if anything, I would like to see the opposite: we should explicitly override defaultsort for maintenance categories to make it easier to find pages in the list. I believe that this is currently what the PAGENAME variables are doing. CMummert · talk 20:57, 29 March 2007 (UTC)[reply]

{{editprotected}}. I'm removing this for now; if it becomes clear that there is consensus to change the template, please add another one and I will be glad to make the changes. CMummert · talk 18:26, 30 March 2007 (UTC)[reply]

I think there should be a centralized doc at Template:Merge/doc that covers all usage. It's inefficient to have to duplicate every edit across the different /docs. If this is a good idea, please edit the templates to transclude {{Merge/doc}} instead of {{/doc}}. I'll add sample usage for {{merge-multiple}}, {{mergesection}} etc. as well. –Pomte 15:16, 31 March 2007 (UTC)[reply]

Editprotected edit needed

{{editprotected}}

• I concurred with above back in January when I changed and fixed up the usage... just got back around now to implement such when I tripped over it again.

• Hence, please change all three Template:merge, Template:mergeto, Template:mergefrom templates with the explicit inclusion of the combined usage page now in {{merge/doc}} so that the line in each of the three:
  
  {{/doc}} reads instead: {{merge/doc}}

• Note that per my changes, Template:mergeto/doc, Template:mergefrom/doc are currently redirect templates and so all is working okay and there is no hurry.

• If there is an easy way to combine talk page and or the /doc page histories, it may not be a bad idea to XFD the two orphaned /doc pages. The whatlinkshere for the templates themselves will serve to show where each is applied. Best regards // FrankB 20:18, 7 April 2007 (UTC)[reply]

I updated the templates. If there is interest, I should be able to merge the histories and delete the old doc pages, but I don't see why they can't stay as they are. CMummert · talk 12:31, 8 April 2007 (UTC)[reply]

The template image should be changed to Image:Merge Arrow.svg, a vector version that scales better. Crotalus horridus (TALK • CONTRIBS) 17:19, 15 April 2007 (UTC)[reply]

There's been some discussion regarding this at Template talk:Merge/Archive3-to-Jan2007#svg images. Just FYI. – Luna Santin (talk) 19:48, 15 April 2007 (UTC)[reply]

Exactly how long do we intend to support IE6? It's an obsolete and dangerous browser. At this point, I think it's reasonable to tell IE6 users to either: (1) upgrade to IE7, (2) use Firefox instead, (3) use the monobook workaround for PNG transparency, or (4) put up with the blue background. Crotalus horridus (TALK • CONTRIBS) 22:59, 15 April 2007 (UTC)[reply]

1. I'm still waiting for someone to cite a single advantage to using the SVG icon in this template. Forget about not affecting IE6 users. Just tell me what the rest of us stand to gain.

If you actually bother to look, you'll see that the scaled 50px version looks worse than the native raster version does (particularly where the arrows intersect).

2. The SVGs for the other merger icons are highly inaccurate reproductions that don't match the originals or Image:Merge Arrow.svg. —David Levy 13:50, 16 April 2007 (UTC)[reply]

Do you know anyone who still uses any version of Internet Explorer? I certainly don't. — CharlotteWebb 07:06, 16 April 2007 (UTC)[reply]

85% of the internet? We're doing this for everyone, not just each other. Luigi30 (Taλk) 13:15, 16 April 2007 (UTC)[reply]

I'm using IE6 at the moment (not through choice!); I don't have the rights to install new software on the computer I'm on, and IE6 is the only browser available. I suspect many other people are in a similar situation. --ais523 13:44, 16 April 2007 (UTC)

Indeed, that describes my situation as well. I use Firefox at home, but I'm forced to use IE6 at school. My sister is forced to use it at work. —David Levy 13:50, 16 April 2007 (UTC)[reply]

Since there doesn't seem to be clear consensus, I'm going to remove the editprotected tag. By the way, it was mistakenly substituted; that template should not be substituted. CMummert · talk 00:34, 18 April 2007 (UTC)[reply]

There is a problem with {{mergeto}}. When the user places this template message in a page (A) to the merge-target page (B), but the merge-target page (B) is moved to a better article name (C), the merge-target talk page (B) doesn´t moves to the C page, nor appear a message in the C talk page . --Altermike 16:24, 6 May 2007 (UTC)[reply]

There isn't a problem. As has been discussed at length on your talk page, you accidentally capitalized a word, created a merge debate at Talk:Vehicle Engineering (with a capital 'E') and then presumably only checked Talk:Vehicle engineering (with a small 'e') before making the merge, hence why you erroneously thought that "the comments [against a merge] appeared after the merging".

{{mergeto}} functions just fine as long as you are aware of the case-sensitivity of pages. --DeLarge 17:39, 6 May 2007 (UTC)[reply]

I'm suggesting a merge from an article in the main namespace to one in the Wikipedia namespace using mergefrom, and it inserts the Wikipedia: prefix before the name of the main namespace article, thereby making it a nonexistent link. Don't have time to figure out how to fix. (For current example (as of this date & time), see Wikipedia:WikiProject Dog breeds/Templates.) Elf | Talk 04:07, 17 May 2007 (UTC)[reply]

The template shouldn't assume that merging is always between one namespace, and users may not expect it to fill in the namespace for them. In the case of {{Mergefrom}}, [[:{{NAMESPACE}}:{{{1}}}|{{{1}}}]] can be changed to [[:{{{1}}}]]. But this will ruin other current uses, so I'll subst your particular merge proposal to make it work in the meantime. –Pomte 04:42, 17 May 2007 (UTC)[reply]

Could someone add an interwiki link to the Irish version of this template at ga:Teimpléad:DéanCumascLe? --Kwekubo 11:24, 2 June 2007 (UTC)[reply]

Strike that - just noticed the links are transcluded from Template:Merge/doc. --Kwekubo 11:27, 2 June 2007 (UTC)[reply]

{{editprotected}} Please link Template:Mergeto with es:Plantilla:Fusionar en. --Pasajero 11:32, 21 June 2007 (UTC)[reply]

Whenever you want to add interwikis you should see if the docs are transcluded, because if they are then no admin intervention is needed. In this case, the interwiki needed to go in [[1]]. I put it in. — Carl (CBM · talk) 01:07, 22 June 2007 (UTC)[reply]

I'm trying to get a better understanding of templates by looking at the code of some of them. Please forgive me if I'm not understanding something, but is it the case that there are too many 'E's at the end of PAGENAME in this template? Right now it says:

   ...{{#if:{{NAMESPACE}}|{{NAMESPACE}}:}}{{{1}}}]]''. ([[{{{2|:{{NAMESPACE}} talk:{{PAGENAMEE}}}}}|Discuss]])

It seems to me it would make more sense for it to be:

  ...{{#if:{{NAMESPACE}}|{{NAMESPACE}}:}}{{{1}}}]]''. ([[{{{2|:{{NAMESPACE}} talk:{{PAGENAME}}}}}|Discuss]])

Does this warrant an {{editprotected}} Thanks! Momazona 02:32, 23 June 2007 (UTC)[reply]

PAGENAMEE is documented at Help:Magic words. It is just a URL encoded version of PAGENAME. I can't see why it's needed; PAGENAME should work fine in internal links. But PAGENAMEE works too. — Carl (CBM · talk) 03:24, 23 June 2007 (UTC)[reply]

I have changed to change Template:Mergefrom-multiple to use Image:Mergefrom.svg instead of Image:Mergefrom.gif. Here are my reasons for doing so:

1. It would encourage use of SVG or at least PNG on the web, either of which are much more desirable than GIF.
2. The only advantage to using the GIF version is support for the obsolete IE6, and IE6 is dying out off the web. See [2] and [3].
3. The remaining IE6 users would be encouraged to upgrade to IE7 or Firefox, decreasing our need to deal with IE6's many rendering bugs.
4. No one has complained that their ability to use Wikipedia would be impeded by switched to the SVG copy.

—Remember the dot ^(talk) 18:41, 2 July 2007 (UTC)[reply]

I have reverted. Here are my reasons for doing so:

1. GIF is now a 100% free format worldwide, so there no longer is any reason to discourage its use.
2. No, IE6 compatibility isn't the only advantage to using the GIF version. In case you didn't notice, the SVG is an inaccurate (and inferior) rendition of the icon. We don't have a matching set of SVGs, and the one accurate SVG icon of the bunch is rendered by MediaWiki with significantly inferior quality.
3. It isn't our job to dictate what browsers people use, let alone by deliberately breaking things for absolutely no benefit to the rest of us. We shouldn't allow such concerns to hold us back from making improvements, but this change isn't an improvement. It accomplishes nothing other than making the site worse. Furthermore, I seriously doubt that many users would even realize that their use of a particular browser was causing the problem, so they wouldn't switch because of it. They'd simply have a broken icon.
4. Your last claim is false. If you read through the past discussions (in which there has never been consensus for the SVGs' use), you'll see that I work with visually impaired people who depend on these icons to identify the tags with greater ease. Your change makes the image more difficult to recognize. —David Levy 19:26, 2 July 2007 (UTC)[reply]

1. PNG is usually superior to GIF in compression and quality. We use PNGs whenever possible and discourage the use of GIFs. See Wikipedia:Preparing images for upload.
2. I looked but could not see any difference between the GIF copy and the SVG copy. What difference are you referring to?
3. Having only one copy of an image to work with is significantly simpler and easier than maintaining both a vector and a raster copy. If someone wanted to adapt or modify the image, it would be faster and easier to get at the copy they need if we only worried about the SVG.
4. Why can't the people you worked with upgrade their browser? Doing so is free and simple, and IE6 is dying out anyway.

—Remember the dot ^(talk) 19:37, 2 July 2007 (UTC)[reply]

1. Firstly, that page was written when the GIF format still had patent issues. It really should be updated, but this isn't urgent; we can employ common sense instead of following the rules purely for the sake of following the rules. Secondly, in the absence of alpha transparency and more than 256 colors, there is absolutely no quality difference between the GIF and PNG formats. In this case, the use of an SVG encourages the bad practice of using 24-bit PNGs for 8-bit applications. Thirdly, when dealing with images this small, any difference in file size between a GIF and a PNG is negligible.
2. I designed the icons to have interlocking points. Image:Merge-arrow.svg and Image:Mergefrom.svg have non-interlocking points, and all three of the elements (the rectangle, the triangle and the diamond) have different proportions. (The creator told me that she would correct these disparities, but she never did.) Image:Merge-arrows.svg is a reasonably accurate reproduction of the original GIF, but MediaWiki doesn't scale it to this size very well.
3. If you look at the description page for any of these graphics (as someone who wishes to adapt or modify an image certainly should), you'll see that all of the GIFs and SVGs are prominently displayed/linked (along with an explanation of why both formats exist). No one should have any difficulty finding the version that he/she desires.
4. I do make sure that these people (who are elderly, incidentally) switch over to Firefox. I'm citing them as examples of the individuals whose ability to use Wikipedia is affected by the icons' appearance (many of whom don't have someone like me to help them). —David Levy 20:11, 2 July 2007 (UTC)[reply]

I've fixed Image:Mergefrom.svg to be pretty close to Image:Mergefrom.gif. Even elderly people receive the IE7 update automatically, and installation is straightforward. But even with an opaque background, the symbol would still be readable. Since it doesn't severely impact IE6 users' ability to use Wikipedia and upgrading is quite easy, I don't think it's necessary to cater to those using obsolete software. —Remember the dot ^(talk) 23:42, 2 July 2007 (UTC)[reply]

1. I have IE6 installed on my system (and use it for occasional compatibility testing), and there has been no automatic update. In fact, every public computer that I've used (at college and in libraries) is running IE6 (with no alternative options available).
2. Software installation seems straightforward to you and me, but my grandmother (and many people her age) can't do it. Heck, even my parents can't do it.
3. I specifically tested to see what difference the white background made, and almost all of these elderly people (with and without major visual impairments) told me that it made the icon more difficult to recognize.
4. No, we shouldn't cater to users of "obsolete" software, nor should we go out of our way to make things worse for them. The GIF renders correctly in all graphical browsers, so the rest of us lose nothing by retaining it.
5. Thanks very much for updating the SVG (which certainly has legitimate applications). Could you please update Image:Merge-arrows.svg and Image:Merge-arrow.svg to match? I'd sincerely appreciate it. —David Levy 00:10, 3 July 2007 (UTC)[reply]

If you have automatic updates enabled, then you should have had a dialog pop up that said a new version of Internet Explorer is ready to install. If you do not have automatic updates enabled, then you are leaving your computer quite vulnerable as security holes in Windows are discovered.

Yes, the GIF is not going to look quite as good on IE6 because it will be on a white background. But IE6 is obsolete. If users find their inability to view web pages without quirks then they can just upgrade. We might as well leave the GIF copy behind and encourage use of SVG; there's no need to worry about the IE6 users. Installation of IE7 truly is point-and-click. Anyone, most likely even your parents and grandparents, could do it. —Remember the dot ^(talk) 01:29, 3 July 2007 (UTC)[reply]

1. I don't have automatic updates enabled. I manually install security updates. (Many people install no updates, unfortunately.)
2. Again, I wouldn't argue that we should withhold improvements for the sake of accommodating IE6 users (and users of the other browsers for whom the SVGs pose problems). This isn't an improvement. Switching to the SVG for this purpose provides no significant advantage to anyone.
3. My parents and grandmother can barely manage to access websites and send e-mail (and I frequently have to assist them with the minor issues that arise). Performing a software update seems trivially easy to you and me, but many people simply aren't good with computers.
4. Thank you for updating Image:Merge-arrow.svg. If you could also update Image:Merge-arrows.svg (which is isn't quite as good as your versions), that would be great. —David Levy 10:31, 3 July 2007 (UTC)[reply]

Why do you say this is an '8 bit application'? Using alpha transparency along those diagonal lines renders better because it can be used on backgrounds of different colors without having to anticipate the background color and generate a different GIF. Also, for my money, the SVGs actually do look better. I totally buy the case for hand-optimized pixel artwork at these kinds of sizes, but in the GIFs the horizontal and vertical lines are not pixel-aligned, and so they do not look very crisp. This suggests that they were not prepared specifically for this resolution. The SVG does have such crisp lines, impressively. As for accessibility, I agree we need to be sensitive to these kinds of issues, but transparent PNGs from SVGs are already in wide use on the site, and the worst common rendering problem is that they have a white matte instead of transparency. Given the color of the merge templates this is a pretty minor problem. — brighterorange (talk) 23:43, 2 July 2007 (UTC)[reply]

I don't see the difference that you describe, and I assure you that I created the icons at this precise resolution. They can, of course, be adjusted to precisely match the SVGs' appearance (when displayed with the standard merger template background color) to the pixel. —David Levy 00:10, 3 July 2007 (UTC)[reply]

Well, obviously they can be fixed, but my comment still applies. I'm surprised you don't see the difference (here's the GIF):

The gif clearly shows pink around the red shaft of the arrow, making this horizontal line look blurry. The SVG shows crisp horizontal and vertical lines even at small resolutions:

(Of course I can't scale up the pixel rendering like with the GIF, so you'll have to pull out the screen magnifier if you want to see it close up.) — brighterorange (talk) 14:02, 3 July 2007 (UTC)[reply]

Okay, I didn't understand what you were referring to. That's a design element, not an unintentional artifact. If you zoom in on the scaled SVG, you'll clearly see that the arrow's trunk contains the image's only "crisp" edges (due to the anti-aliasing present throughout the remainder). I deliberately softened them to match the rest of the icon. I personally prefer this style, but it's entirely optional; it doesn't stem from a limitation of the GIF format, so the GIFs don't have to look like that. We have no control, conversely, over how MediaWiki scales the SVGs. —David Levy 17:23, 3 July 2007 (UTC)[reply]

But only some of the other vertical lines (i.e., not the back edge of the arrow's stem)? Weird. Well, okay, maybe it is deliberate but I think the SVGs look better. — brighterorange (talk) 19:01, 3 July 2007 (UTC)[reply]

I did a great deal of experimenting and felt that this configuration looked the best. My opinion, of course, is far from sacrosanct. —David Levy 20:07, 3 July 2007 (UTC)[reply]

I agree that Internet Explorer sucks, 7 slightly less than 6. I much prefer png to gif images (even better, svg, if it works for the audience).

But I have to call B.S. on Remember's statement that "there's no need to worry about the IE6 users." His own cited links ([4] and [5]) show that IE6 is the single most popular browser at W3Schools.com and Webreference.com's web sites. Claims that "IE6 is dying out off the web", "remaining IE6 users would be encouraged to upgrade", and "upgrading is quite easy" are not only irrelevant strawman arguments for abandoning what works in most people's web browsers, they are an arrogant slap in the face for the single largest audience group at two technically-oriented web sites, and possibly a much larger group of users on the Web in general.

I say make it continue to look right for everybody. I like better technology too, but we should only use it where it works without degrading the experience for literally millions of readers of Wikipedia. —Michael Z. 2007-07-03 17:19 Z

By the way, a couple of much wider-ranging sources confirm that IE 6 is still (unfortunately) the most common browser by far:

• TheCounter.com's top three browsers in June 2007, from 66,557,181 visits:[6]
  1. IE6 54%
  2. IE7 16%
  3. Firefox 12%
• W3counter.com, top three in last 25,000 page views in June 2007, from 4,863 sites:[7]
  1. IE6 49.12%
  2. IE7 17.08%
  3. Firefox 2.0 14.95%

 —Michael Z. 2007-07-03 18:19 Z

BTW, is there a reason that wikipedia doesn't use "pngfix.js" that makes the alpha channel work in IE5 and 6? It doesn't work in every case, but it does work for this one. — brighterorange (talk) 19:01, 3 July 2007 (UTC)[reply]

It might be because it's just better for everyone if users just upgrade their browsers. —Remember the dot ^(talk) 19:59, 3 July 2007 (UTC)[reply]

Sure, that would be better, but we don't live in a perfect world. We work for our readers (not the reverse), and we don't get to decide what browsers they use. —David Levy 20:07, 3 July 2007 (UTC)[reply]

What is pngfix.js? We could certainly add it to Common.js if it fixed something. — Omegatron 02:23, 7 September 2007 (UTC)[reply]

It's something along the lines of this, but the script should only be applied if the user is browsing with IE <= 6. If you know how to implement this on Wikipedia, that would be awesome. —Remember the dot ^(talk) 04:13, 7 September 2007 (UTC)[reply]

Actually, I'll tell you what. I ought to be able to tweak the script myself and provide you with the tweaked copy. —Remember the dot ^(talk) 04:16, 7 September 2007 (UTC)[reply]

Be patient. It'll take me a day or two. —Remember the dot ^(talk) 04:23, 7 September 2007 (UTC)[reply]

Many times people say "where is this merge being discussed!!?" I propose that the "Discuss" link point to a specific section of the talk page, based on the template parameter? Like "#Merge of x". And if there's already a discussion section or if there's more than one thing being discussed at once, someone can just add an anchor tag within that section to attract the clicks. — Omegatron 02:18, 7 September 2007 (UTC)[reply]

{{editprotected}}

Please remove

<noinclude><!--PNG images containing transparencies do not display properly for some users. Please consider this fact before replacing the already tiny GIF file.--></noinclude>

from this template and change [[Image:Merge-arrows.gif|left]] to [[Image:Merge-arrows.svg|left]]. Now that a workaround has been implemented for PNG transparency in Internet Explorer 5.5 and 6, there is no reason to continue to use the less scalable GIF copy. —Remember the dot ^(talk) 04:42, 11 September 2007 (UTC)[reply]

I've removed the outdated message and will switch to the SVG when it's been updated to match the other merger template icons (as the GIF already does). —David Levy 05:13, 11 September 2007 (UTC)[reply]

This template is displaying badly on University of Hull (as an be seen by previewing the article with just the template removed) but I don't know how to fix it. Timrollpickering 22:31, 14 September 2007 (UTC)[reply]

Someone apparently decided to change the general format of all the organization templates, that's fine, except that they aren't working. Places ALL OVER that are using SVG graphics just aren't showing the image, the images still exist, but something isn't working right, and this is far far beyond the scope of what I'm able to fix. Really, this needs to be dealt with. -Theanphibian ^{(talk • contribs)} 05:14, 16 September 2007 (UTC)[reply]

There is a known image issue on the Wikimedia sites. The timing apparently is an unfortunate coincidence. —David Levy 05:22, 16 September 2007 (UTC)[reply]

Sorry to break the subject, but the "updated" template looks awful. Please revert to the stable version. --Ghirla^-трёп- 13:25, 18 September 2007 (UTC)[reply]

The ending of the Mergefrom template, "this page or section", is a bit lame. Can someone add a parameter to distinguish between merging into "this section" from merging into"this article." Of course, not everyone will use the parameter, but at least it will be there for those who do use it. If there is consensus, please add an {{editprotected}} tag at the top of this section. Thanks. Finell (Talk) 18:29, 28 October 2007 (UTC)[reply]

Would an admin mind fixing the "merged" link in these templates? On May 30, Wikipedia:Merging and moving pages was moved to Help:Merging and moving pages. This is a well-used/important template and I don't think links in it should lead to redirects. It probably creates a little extra server strain and we should point people to where the page actually is. Jason McHuff 07:55, 4 December 2007 (UTC) {{editprotected}}[reply]

 Done.—Random832 15:02, 4 December 2007 (UTC)[reply]

In the Merge page guidelines it suggests using the {{mergefrom-multiple}} template and placing it on the destination page (rather than a single {{mergeto}} template on each page), however, when I did this on Meiko Scientific there is now no notice on the proposed merge pages Meiko Computing Surface and MeikOS. Unless I am missing something shouldn't this template do that automatically? If not what needs to go on those pages, wouldn't {{mergeto}} cause category sorting problems if both templates were used?Awotter (talk) 20:55, 11 December 2007 (UTC)[reply]

Each article must be tagged individually. The {{mergefrom-multiple}} template is a substitute for two transclusions of the {{mergefrom}} template on the same page, not for the two separate transclusions of the {{mergeto}} template. I've tagged the articles for you. —David Levy 21:19, 11 December 2007 (UTC)[reply]

Thank you!Awotter (talk) 22:10, 11 December 2007 (UTC)[reply]

{{editprotected}}

I don't mean to nitpick, but Wikipedia:Merging and moving pages redirects to Help:Merging and moving pages.

In other words, change
[[Wikipedia:Merging and moving pages|merged]]
to
[[Help:Merging and moving pages|merged]]

This should changed on the following templates:
Template:Mergeto
Template:Mergefrom
Template:Mergefrom-multiple
Template:Mergesection
Template:Mergesections
Template:Merging
Template:Mergeto-multiple
Template:Mergetomultiple-with

Thanks. lightsup55 ( T | C ) 02:13, 4 January 2008 (UTC)[reply]

N Not done - Wikipedia:Redirect#Do not change links to redirects that are not broken Harryboyles 05:28, 6 January 2008 (UTC)[reply]

Right, we shouldn't edit articles just to update links to redirects. However, these are templates so I think that the reasons stated at Wikipedia:Redirect#Do not "fix" links to redirects that are not broken do not apply.

So I agree with Lightsup55 and disagree with Harryboyles.

However, the real question is: Shouldn't Help:Merging and moving pages be moved back to Wikipedia:Merging and moving pages? I see it was moved to the help namespaces without any discussion. But I think that how-to pages for the English Wikipedia should be placed in the Wikipedia namespace. Among other things to avoid future name collisions with help pages from Meta. And it makes the shortcut + search box suggest system work better if both the shortcuts to a page and the page itself is in the Wikipedia namespace.

--David Göthberg (talk) 13:27, 6 April 2009 (UTC)[reply]

I tried to post the same comment on Template talk:Mergeto that appears on this talk page, but it seems to have disappeared somehow. Maybe it has something to do with the fact the Template talk:Mergeto page redirects here, so when I clicked the "new section" link from the "View Source" tab on Template:Mergeto (which has the "can be edited only by administrators" blah blah blah... box) on Template talk:Mergeto, it didn't actually get posted. Is this a bug or what?

Thanks. lightsup55 ( T | C ) 02:22, 4 January 2008 (UTC)[reply]

That talk page redirects here (see its first #REDIRECT line), as all discussion about merge templates are better organized in one location. –Pomte 02:26, 4 January 2008 (UTC)[reply]

I understand that, but shouldn't the comment automatically get posted into the article/page that it is redirected to? Or has this never been a feature of the software that is used on Wikipedia? lightsup55 ( T | C ) 02:37, 4 January 2008 (UTC)[reply]

You edited Template talk:Mergeto directly, and the most intuitive result should be that changes get made to Template talk:Mergeto, not Template talk:Merge (the 2 pages have nothing to do with each other directly; one simply has code telling it to redirect to the other). If all edits to Template talk:Mergeto get moved to this page automatically, there would be no way to edit Template talk:Mergeto directly (in case the redirect needs to be changed, for example). I'm guessing you got there by the small (Redirected from Template talk:Mergeto) at the top of the page, which isn't usually done except to edit that page. –Pomte 05:36, 6 January 2008 (UTC)[reply]

No, I actually got there from the "view source" tab (which normally appears as "edit this page" when a page is not edit protected) on Template:Mergeto.

On the "view source" tab, it said:

This page is currently protected, and can be edited only by administrators. Some templates and site interface pages are permanently protected due to visibility. Occasionally, articles are temporarily protected because of editing disputes. This template has a documentation page – Template:Mergeto/doc – which may be freely edited. The reason for protection can be found in the protection log. You can discuss this page with others. If you have noticed an error or have a suggestion for a simple change, start a new section and insert the text {{editprotected}} followed by your request. An administrator may then make the change on your behalf. You may request unprotection of the page.

The link in the text above that I have bolded is the link I clicked on when I tried to edit the template at http://en.wikipedia.org/w/index.php?title=Template:Mergeto&action=edit which only showed the source and that table above I have shown.

{{editprotected}} THE PAGE PROTECTION TEMPLATE SHOULD BE AT THE TOP of the "merge" template, never at the bottom. Or try having a small version of that protection template instead. You can find it in the Template messages/Maintenance section. This is for the "merge" template. Your "guide" is in this page. iaNLOPEZ1115 TaLKBaCK Vandalize it UBX 11:46, 15 January 2008 (UTC)[reply]

Moved to the top. עוד מישהו Od Mishehu 12:41, 15 January 2008 (UTC)[reply]

Should the date be the date the merge was proposed, or the date the template is being added (in cases where someone suggested a merge but didn't add the template, or added the template to one article but not the other)? I went with the latter at Unageing and Ageless#Media and fiction. --DocumentN (talk) 18:38, 9 February 2008 (UTC)[reply]

The template {{merging}} should simply say that the page in question is being merged with another. That the one in question is being merged into another article should be an option, but there is no template for the other case where the article in question is the one the other is being merged into (i.e. it is the destination). I think it should be kept as a single template, with the option of adding something to identify which situation applies to a given article. Richard001 (talk) 08:40, 6 March 2008 (UTC)[reply]

I'm going to take a stab at this since there seem to be no objections. Adam McCormick (talk) 03:04, 1 June 2008 (UTC)[reply]

I've made the change and added some documentation. I also fixed the common merge documentation at Wikipedia:Template messages/Merging and splitting/List while I was at it. Please let me know if there are any issues. Adam McCormick (talk) 14:29, 4 June 2008 (UTC)[reply]

I suggest mergeing {{Mergeto}} into {{merge}} as they are effectively the same template. Simply south (talk) 16:23, 8 March 2008 (UTC)[reply]

{{editprotected}} Could someone add merge tags to {{Mergeto}} and {{Merge}} to show the suggested merger of one into the other? (probably with <noinclude></noinclude> things to not mess up any others). Simply south (talk) 16:27, 8 March 2008 (UTC)[reply]

You're mistaken regarding the existence of redundancy.

Template:Mergeto is used to suggest that a page's content be moved from the page on which it's placed to another page (with the former becoming a redirect to the latter). This is done in conjunction with Template:Mergefrom, which is placed on the page to which the person believes that the content should be moved.

Template:Merge does not indicate a suggested direction for the merger. It's placed on two or more pages when the person believes that they should be merged but doesn't know which page should be retained and which page(s) should be redirected.

If you still want to insert merger tags, I'll do so. —David Levy 19:51, 8 March 2008 (UTC)[reply]

Maybe they could be reworded to show thi. It is not always clear. Simply south (talk) 19:58, 8 March 2008 (UTC)[reply]

The wording ("merged with" / "merged into") seems clear to me, and we have have an explanatory page, but you're welcome to suggest different wording. —David Levy 20:26, 8 March 2008 (UTC)[reply]

I can see this is a slight misunderstanding, but couldn't we still do this? Why not just add an optional field to say 'to' of 'from', then just merge both into the 'parent' template? It might create problems for people used to using the more specific templates though, assuming they wouldn't be compatible via redirect. Richard001 (talk) 05:49, 10 March 2008 (UTC)[reply]

Is this a serious proposal or a Malkovitch moment? I was going to suggest either splitting the merge template, or perhaps merging the {{Split}} template into this one. If I actually had something productive to say I am a little concerned that merge templates sit around forever. Mabybe a bot could round them up and delete them after a few months, kind of like the bot that closes old RfC discussions.Wikidemo (talk) 10:45, 20 August 2008 (UTC)[reply]

The "Discuss" link in this template is broken. I would fix it, but it's protected. — NRen2k5^(TALK), 23:43, 20 March 2008 (UTC)[reply]

How/where is it broken? Can you link to an example? —David Levy 23:46, 20 March 2008 (UTC)[reply]

For example, the Embedded Application Binary Interface uses the "mergeto" template to suggest merging it into Application Binary Interface. I expected the "discuss" link generated by this template to create a link to Talk:Application binary interface. Alas, currently the "discuss" link on Embedded Application Binary Interface is a redlink, to the non-existent "Talk:Application_Binary_Interface". --68.0.124.33 (talk) 14:06, 31 May 2008 (UTC)[reply]

Fixed. (at least this specific case). Fixed by editing "Embedded Application Binary Interface" to suggest merging it into the "real" article name application binary interface -- rather than the redirect page "Application Binary Interface". Now the "discuss" link on "Embedded Application Binary Interface" sends me to the correct page ("Talk:Application binary interface"). Does that fix the problem that NRen2k5 noticed? --68.0.124.33 (talk) 14:06, 31 May 2008 (UTC)[reply]

{{editprotected}} Could you please replace the text "This page is" with "This page or section is", in Template:Merging (following the usage in Template:Merge). As an example for the need for it, please see this.

 Not done You can't merge a section into an article - that's called splitting :D. Seriously I can't think of a legitimate situation in which the disambiguation would be required. Happy‑melon 22:50, 22 March 2008 (UTC)[reply]

Usage understood and fixed, thanks. —Preceding unsigned comment added by 99.251.254.165 (talk) 21:11, 23 March 2008 (UTC)[reply]

{{editprotected}}

 Done PeterSymonds (talk) 15:16, 26 June 2008 (UTC)[reply]

<noinclude>{{pp-template|small=yes}}
</noinclude><!--{{Merge|{{{1}}}|date={{{date|}}}}} begin-->{{ambox
| type  = merge
| image = [[Image:Merge-arrows.svg|Merge arrows]]
| text  =  It has been suggested that this {{#if:{{NAMESPACE}}|page|article}} or section be [[Help:Merging and moving pages|merged]] with ''[[:{{NAMESPACE}}:{{{1}}}|{{#if:{{NAMESPACE}}|{{NAMESPACE}}:}}{{{1}}}]]''. ([[{{{discuss|{{{2|:{{NAMESPACE}} talk:{{PAGENAMEE}}}}}}}}|Discuss]])}}<includeonly>{{
#switch:{{NAMESPACE}}
|Help|Help talk|Portal|Portal talk|Wikipedia|Wikipedia talk=[[Category:Items to be merged|{{PAGENAME}}]]
|Category|Category talk|Image|Image talk|MediaWiki|MediaWiki talk|Template|Template talk|User|User talk=
|#default=[[Category:All articles to be merged]]{{#if: {{{category|}}}||[[Category:Articles to be merged{{#if: {{{date|}}} |  since {{{date}}} }}|{{PAGENAME}}]]
}}}}</includeonly><!--{{Merge}} end--><noinclude>{{documentation}}</noinclude>

Could you please update the template to the version above (the only thing that was added is [[Category:All articles to be merged]]) so that the template puts all articles into the same category (its for a bot).  Atyndall93 | talk  12:16, 26 June 2008 (UTC)[reply]

{{Editprotected}}

Shouldn't the type switch be move instead of merge so it keeps it's purple colour. And according to Mbox (which this template uses) there is no type called merge. Peachey88 ^{(Talk Page | Contribs)} 09:57, 21 August 2008 (UTC)[reply]

+1, see {{ambox}}. In addition, the categorization in {{ambox}} is bogus (line break). This produces horrible ouput (I come from List of constructed languages where it is visible) Mro (talk) 12:58, 21 August 2008 (UTC)[reply]

This was just noted on the Village Pump; it certainly affects every page where the template is used. --—— Gadget850 (Ed) ^talk - 14:33, 21 August 2008 (UTC)[reply]

Y Done and Y Done - See my response at Wikipedia:Village pump (technical)#Phantom words found on two articles. It was my fault.

--David Göthberg (talk) 19:16, 21 August 2008 (UTC)[reply]

{{mergedto}} should redirect to {{merged-to}} not {{mergeto}}. Stevage 04:37, 16 September 2008 (UTC)[reply]

Y Done - I agree. And {{mergedto}} wasn't transcluded anywhere currently so I fixed it. And I fixed the docs listing it in some places. Note that none of the pages involved where protected and as I said it was unused so you could have done it yourself.

--David Göthberg (talk) 12:17, 16 September 2008 (UTC)[reply]

Whoops, my mistake. {{mergeto}} is protected, which meant that it looked like {{mergedto}} was protected, hence...mumble...Stevage 04:46, 17 September 2008 (UTC)[reply]

{{editprotected}}

Please add the tracking category Category:All articles to be merged to {{mergeto}}. MER-C 12:52, 24 September 2008 (UTC)[reply]

Normally a sloppy editprotected request like this would be denied. You need to provide the exact source code you want to add, not just a general statement like that. Most admins are not advanced template programmers, and this case was pretty tricky. But this template happened to be on my watchlist.

Does anyone know why these templates don't add pages from some namespaces to any category? These are the namespaces: Category, Category talk, Image, Image talk, MediaWiki, MediaWiki talk, Template, Template talk, User, User talk. Shouldn't such pages be categorised to Category:Items to be merged ?

--David Göthberg (talk) 15:29, 24 September 2008 (UTC)[reply]

Please add this interwiki to Template:Mergeto: ro:Format:Uneşte cu (can't add it into the documentation template because it's transcluded from other template's (Template:Merge) documentation). Ark25 (talk) 20:57, 5 October 2008 (UTC)[reply]

Now I figured how to do it: it has 3 interwiki sections, in the same template doc — Template:Merge/doc. Ark25 (talk) 21:17, 5 October 2008 (UTC)[reply]

Someone created a user subpage titled "Herbert Jay Stern". I added a mergeto tag, proposing merger into the already-existing article Herbert Jay Stern. It was a red link and when I clicked on it, the new page to be created was "user:Herbert Jay Stern".

That should be considered a bug in this template, IMO. Michael Hardy (talk) 16:53, 10 March 2009 (UTC)[reply]

Seemed a glaring omission.--Cerejota (talk) 02:56, 14 March 2009 (UTC)[reply]

How? Template:Mergeto refers to "this article or section," so such a situation already is covered. We previously had a separate tag for sections (Template:Mergesectionto), and it was merged into Template:Mergeto in 2006 (as part of a larger effort to minimize confusion by reducing the number of templates). You must have noticed this, because you just changed the resultant redirect to point to Template:Mergeto-section. —David Levy 16:39, 14 March 2009 (UTC)[reply]

Can we then recode? "article or section" is being moved to specialized versions using specific syntax. It is needlessly ambiguous as it stands, when we have the option of not making it so.--Cerejota (talk) 00:50, 15 March 2009 (UTC)[reply]

There are templates for which "article or section" is ambiguous, but I don't see how that's remotely the case here. Any transclusion at the top of the page should apply to the entire article (because there's no reason to merge the lead section on its own), and any transclusion elsewhere on the page obviously refers to the specific section in which it's located. Where is the ambiguity? —David Levy 03:26, 15 March 2009 (UTC)[reply]

The date field doesn't seem to work.--Yannick (talk) 22:52, 4 April 2009 (UTC)[reply]

Yes, I fixed it and was promptly reversed by a bureaucrat, see below. — The Little Blue Frog (ribbit) 16:24, 5 April 2009 (UTC)[reply]

1. I am not a Wikipedia bureaucrat. If you meant that in the pejorative sense, please refrain from engaging in personal attacks.

2. The insertion date is intentionally not displayed, as there is longstanding consensus to keep these tags as small as possible. (Your edits added an additional line for many users.)

The merger categories are divided by date to make them more manageable. If we decide that these dates should be displayed in the articles, we can simply make the categories visible at the bottoms of pages. —David Levy 16:39, 5 April 2009 (UTC)[reply]

1) For the record: there is no personal attack, my use of "bureaucrat" was neither literal nor pejorative but merely descriptive. I used it because you felt the need to mass-revert everything I did in good faith before you even started this discussion, when my minor fix didn't warrant such hasty undoing. Most of those templates are only semi-protected so that we can be bold and fix or improve them without tons of red tape and bureaucracy; or just be frank and fully protect them.

2) For the issue:

• The template's documentation neither says it's supposed to be "intentionaly disabled" nor explains where and when this was discussed and a former consensus reached. You can't expect us to know that if you don't document it, and anyone filling the date parameter will eventually wonder why it doesn't work here as with all other tags. I wasted a quarter hour testing a fix code and applying it to 10+ templates for naught because you didn't document alleged consensus for a non-standard tag bahavior, so I think this should eventually be documented on the template's page about the "date" parameter (a short sentence and a link will do), whichever new conclusion is reached.
• All other tag templates display the date. I see those merger templates lingering for months or years without reason or discussion because the tagging date isn't displayed and people don't realize it's not fresh. Having a small hidden category at the bottom wouldn't replace the visible date within the header, as with the other tags.
• I do not think that adding "Proposed since April 2009" makes the template bloated. Furthermore these templates are not supposed to be permanent so their size is a very secondary issue.
• On my talk page you suggested a bot could automatically remove these tags after some time. It would be a useful feature but not necessarily linked to whether the date should be displayed or not. — The Little Blue Frog (ribbit) 20:38, 5 April 2009 (UTC)[reply]

Adding the date certainly seems like a good idea, and makes sense given similar tags. A bot to remove old ones is probably not a good idea, as 1) there is no time limit on performing a merge and 2) a bot can't reliably deduce how old the merge discussion is - it could still be continuing even after a year. OrangeDog (talk • edits) 02:31, 6 April 2009 (UTC)[reply]

I fully agree that deploying a bot to remove old merger tags would be a bad idea. What The Little Blue Frog views as "a useful feature" was not an actual suggestion on my part. My point was precisely what you wrote above; suggested mergers have no time limit and the insertion date has no bearing on the discussion (if any) that has taken place (and should be checked). Otherwise, we would just have a bot remove old merger tags. —David Levy 04:12, 6 April 2009 (UTC)[reply]

But those points apply to any tag template. I understood that the point of seeing the date was similar to why the date is added to the template anyway. OrangeDog (talk • edits) 23:52, 7 April 2009 (UTC)[reply]

1. As an example, {{cleanup}} indicates a perceived problem (or problems) with the article's actual content. While I've never regarded the insertion date's display as particularly useful, that's why the relevant information is considered more urgent (and time-sensitive), and that's why the community is far less concerned with those tags' size (which already is larger and is less likely to be substantially increased by the date's inclusion).

2. I don't know what you mean by "I understood that the point of seeing the date was similar to why the date is added to the template anyway." Could you please clarify/elaborate? —David Levy 22:09, 8 April 2009 (UTC)[reply]

1a. Your use of the word "bureaucrat" was name-calling. Please don't engage in such conduct.

1b. At no point have I suggested that you were not acting in good faith. I have no doubt that you were (and are).

1c. Please see WP:BRD. Note that it isn't called WP:BDR. It's fine to boldly edit pages in an attempt to improve them, but if someone objects, the standard procedure is to revert to the stable versions and discuss the proposed changes. To refer to this as "red tape and bureaucracy" is to suggest that it's unreasonable to even question your changes (and that I've done so not because of actual concerns, but because of some sort of silly technicality).

1d. Describing your edits as a "minor fix" implies that the templates' code was broken. This is not so. It's entirely reasonable to argue that the addition of a visible date is an improvement, but please stop trying to portray it as the correction of an unintended deficiency.

2a. Why did you place the phrase "intentionaly disabled" [sic] in quotation marks? That isn't what I wrote. "Disabled" would mean that the date's display within the tag is a default behavior that has been suppressed. On the contrary, it's one that must be added (and has not been). It isn't that there was a decision to remove the date; it's that there has not been a decision to add it.

The merger tags long predate the widespread adoption of such a feature, which never spread here because of longstanding consensus that the merger tags should be kept as small as possible (which is a compromise between users who want them to be more prominent and users who don't even want them to be displayed in articles).

You say that the addition doesn't bloat the template, but it adds an entire extra line for many users. (What you see at your resolution is not what everyone sees.) You say that "size is a very secondary issue," but it was among the most hotly contested elements. (See the older archives.)

2b. Why are you again referring to a "hidden category" (after I've already clarified on your talk page that I'm referring to the option to unhide the date-specific category at the bottom of the page). And why, in your opinion, would that be insufficient?

2c. As noted above, I was not actually suggesting that we deploy a bot to remove old merger tags. My point was that if the matter were as simple as you make it out to be, that's what we would do. But it isn't. —David Levy 04:12, 6 April 2009 (UTC)[reply]

Please enable date display

{{editprotected}}

Could you please change all the merge and split templates so that the date of proposal is displayed, as per all other such templates? I had done so and was reverted by User:David Levy who said to take it here, asking "Was this discussed somewhere?": I can see on this talk page that it was asked or reported as a bug many times already.

It is just a small snippet to append to the end of the sentence, to change this:

|Discuss]])

into this:

|Discuss]]){{#if:{{{date<includeonly>|</includeonly>}}}|<small>'' Proposed since {{{date<includeonly>|</includeonly>}}}.''</small>}}

You can see the change here[8] and its display here.[9]

Note: be sure to insert after the parenthesis in ]]) and not after ])}} – It will display Proposed since April 2009. after the sentence. (The includonly stuff is so that the template's documentation page will show us how {{{date}}} will be used.) This should be performed on all the 11+6 merge and split templates as listed in the summary box on the doc template. Thank you, — The Little Blue Frog (ribbit) 16:18, 5 April 2009 (UTC)[reply]

1. Please see the above discussion.

2. Please use the {{editprotected}} template strictly to request uncontroversial edits or edits for which consensus has been established. —David Levy 16:39, 5 April 2009 (UTC)[reply]

Well, OK, fine, sorry for opening a can of worms. May I propose documenting the fact that merge tags, unlike other tags, don't display the date? Maybe with a link to the discussion where this was decided? Or maybe it's time to compile a FAQ for merge templates? Because otherwise, all we know is that someone came by and declared this shall not be, and had more authority than the rest of us. Thanks.--Yannick (talk) 21:12, 5 April 2009 (UTC)[reply]

No one is declaring any such thing. The date display is something that must be added, not a default behavior that must be removed. Heretofore, consensus has been to keep the merger tags as small as possible, and there has been no discussion in which it was decided to reverse course by adding the date.

If you believe that the lack of a displayed date should be noted in the templates' documentation, you're welcome to add such a notation yourself. —David Levy 04:21, 6 April 2009 (UTC)[reply]

I myself was confused by this when I used the merge templates for the first time ("The date's not showing up... Did I do something wrong? Is it called something else? Is it being used at all?"). So I've added a note to the documentation. --LarryGilbert (talk) 18:20, 16 December 2009 (UTC)[reply]

The Little Blue Frog: The way you suggest to add the date is not the standard way. You suggested this:

(Discuss) Proposed since April 2009

But the cleanup templates that do show the date (but mind you, not all of them do), show it like this:

(Discuss) (April 2009)

But having two things with parenthesis directly after each other looks weird, so perhaps like this is better?:

(Discuss) April 2009

However, I think that even if the short date display form is used, then it will unnecessary bloat the display of these message boxes. The date is only relevant to sort the pages into different categories. The date is not relevant to the merge discussion itself and there is no time limit to how long a merge box can be on a page, thus there is no need to show the date. For the same reasons some other cleanup boxes do not show the dates. Thus I am opposed to displaying the date.

--David Göthberg (talk) 14:12, 6 April 2009 (UTC)[reply]

I've got to say, I've always wondered where the date field went to in this template, and would support enabling it, with the output suggested by The Little Blue Frog - I think it would be useful for editors to see how long a discussion has been running, plus it keeps a uniform setup for all templates if the field were enabled. Colds7ream (talk) 17:17, 13 April 2009 (UTC)[reply]

• I Support adding date to display on merge templates. In my opinion dates help to encourage action where it is needed. Jeepday (talk) 22:29, 14 April 2009 (UTC)[reply]

• Support a change similar to this. As above, this is useful to editors considering what to do when faced with the tag. It would be helpful if David Levy could give links to the previous consensus that he says existed. AndrewRT(Talk) 23:21, 15 April 2009 (UTC)[reply]

Again, The Little Blue Frog misinterpreted what I wrote. The consensus to which I referred is that the template should be small; the specific issue of whether to include the insertion date has not been widely discussed. —David Levy 02:31, 17 April 2009 (UTC)[reply]

Then you don't have a consensus at all, do you? Colds7ream (talk) 10:57, 17 April 2009 (UTC)[reply]

A consensus against adding the inclusion date? I never claimed that such a consensus existed. I cited the only relevant consensus thus far (to keep these tags as compact as possible) to refute The Little Blue Frog's assertion that this was an uncontroversial "minor fix" that I was a "bureaucrat" for reverting.

Contrary to The Little Blue Frog's apparent misunderstanding, this is a relatively new function that has not been added to these tags (not a default function that has been actively suppressed). The onus isn't on opponents to point to a discussion in which it was decided not to add the function to these templates. There must be consensus for such a change.

An appropriate discussion (this one) is now ongoing. We need more community feedback, but it currently appears that consensus for the date's addition might be reached. However, as David Göthberg noted, The Little Blue Frog's specific implementation could be significantly improved upon (something that is wise to discuss before editing numerous templates en masse). —David Levy 15:48, 17 April 2009 (UTC)[reply]

• Suppport I see eveyone is supporting it here. So, why is it not done yet? Fleet Command (talk) 08:14, 29 May 2011 (UTC)[reply]
• Support This is an uncontroversial edit, even if somebody would have protested it, because it is absolutely standard for maintenance templates. Debresser (talk) 10:36, 29 May 2011 (UTC)[reply]

The behaviour of the {{Mergefrom}} template has changed, since the default for the second parameter (the talk page/section) defaults to the front-page of the current article .. not the talk page. See an example at Wasteland, where the "(Discuss)" is bold since the target is Wasteland, not Talk:Wasteland. As I mentioned, this behaviour is different from before. Could it be restored such that the default behaviour of the second parameter uses the talk page? Thanks. +mt 19:30, 18 August 2009 (UTC)[reply]

The template has not been changed and is not broken. The problem was that Wasteland (not Talk:Wasteland) was manually specified as the "Discuss" target via the optional second parameter. I've corrected the transclusion by removing the superfluous text. (The tag now links to Talk:Wasteland, which is the default behavior.)

If you see any other pages on which this problem exists, the same solution should apply. —David Levy 20:06, 18 August 2009 (UTC)[reply]

Yikes~! Good thing I just refreshed my coffee. Thanks. +mt 21:12, 18 August 2009 (UTC)[reply]

Six months ago the 2nd positional parameter used to be the talk page see doc. I see that a backwards incompatible change has occurred in the mean time: now the discussion page must be preceded by "discuss=", and multiple pages can be proposed for merger with one tag using positional parameters. I do not see this change discussed here. Has anyone thought to fix the potential problems in articles that were already using the template with a 2nd parameter after this change? Pcap ping 15:56, 7 September 2009 (UTC)[reply]

It appears a bot has been fixing them, but I don't recall discussion, either. — Arthur Rubin (talk) 16:43, 7 September 2009 (UTC)[reply]

{{editprotected}} Could somebody please remove the old and incorrect protection template {{pp-semi-template}} from Template:Mergefrom (the talkpage of which redirects here)? Debresser (talk) 00:10, 10 September 2009 (UTC)[reply]

 Done Thanks. Skier Dude (talk) 03:20, 10 September 2009 (UTC)[reply]

Both {{Mergeto}} and {{Mergefrom}} say "By default, the (Discuss) link on the template links to the top of the tagged page's talk page." This means that the default behaviour is to discuss the suggested merge in two separate places. This is dumb. The default |discuss= page should be different in the two templates so that they point to the same Talk page. It probably makes more sense that this be the Talk page for the article which is going to disappear, meaning that {{Mergefrom}} needs to be changed. An example of this situation is Gaussian filter and Gaussian blur. HairyWombat (talk) 15:39, 15 September 2009 (UTC)[reply]

The guidelines, at least used to be, that discussion is to be in the remaining article, so that {{Mergeto}} would need to be changed. — Arthur Rubin (talk) 17:19, 15 September 2009 (UTC)[reply]

For years, the default behavior was for both templates' "Discuss" links to lead to the proposed destination article's talk page. This makes the most sense for two reasons:

1. The proposed destination article is more likely to receive traffic.

2. This accommodates cases in which a proposal involves merging several articles into another (as the destination article is the common link).

It appears that Template:Mergeto's default function was changed on 2 September with this edit. As you noted above, this is problematic.

I'm unsure of how to reconcile this with the other changes made by Harej (which appear to have been carried without discussion here and minimal discussion at Wikipedia talk:Proposed mergers), so I've directed Harej to this thread. —David Levy 17:29, 15 September 2009 (UTC)[reply]

Changing the (Discuss) link was an accident, as I was not aware that it linked to the right place. I will fix that. @harej 19:32, 15 September 2009 (UTC)[reply]

Okay, I wasn't sure whether the change was necessitated by one of the other modifications. Thanks! —David Levy 06:11, 16 September 2009 (UTC)[reply]

{{Mergeto}} now points to the target's talk page. The vanilla {{Move}} template should not, in my opinion, as then you get the situation where two pages are pointing at each other. @harej 19:48, 15 September 2009 (UTC)[reply]

I assume that you meant to type {{Merge}}. Indeed, as no proposed destination article is specified, the default behavior always has been (and should be) to point to the corresponding talk page. —David Levy 06:11, 16 September 2009 (UTC)[reply]

I still think the should point the other way around, but if it has been this way for years, so be it. The important point is that it was broken, and now it is fixed. This means I can add the really cute green tick ...  Done HairyWombat (talk) 05:45, 16 September 2009 (UTC)[reply]

Did the latest edit to the template break something? Example: Umatilla Indian Reservation. When I remove the template and "show preview" the problem goes away. Katr67 (talk) 21:57, 18 September 2009 (UTC)[reply]

{{editprotected}}

It's the {{mergefrom}} template, this edit broke it. Could an admin add two closing curly brackets }} just before "{{Merge partner", and remove one of the two pipes before "#default"? — jwillbur 22:00, 18 September 2009 (UTC)[reply]

 Done @harej 22:11, 18 September 2009 (UTC)[reply]

Actually, it's not been done. —Farix (t | c) 22:33, 18 September 2009 (UTC)[reply]

Many tahanks. Rich Farmbrough, 22:34, 18 September 2009 (UTC).[reply]

Ok I'll sort it. Rich Farmbrough, 22:34, 18 September 2009 (UTC).[reply]

Looks like it was just caching and harej's fix is good. I reverted mergeto as I was told that is a problem, but at the moment it looks fine. Drop a note to my talk page with any problem pages. I am around for a while. Rich Farmbrough, 22:42, 18 September 2009 (UTC).[reply]

Ah no harej went to "merge" first. That's the trouble with sharing a talk page. Rich Farmbrough, 22:43, 18 September 2009 (UTC).[reply]

OK all fixed and we now have sandbox and testcases for mergeto. Always a bonus. Rich Farmbrough, 22:53, 18 September 2009 (UTC).[reply]

For categorization, {{Mergeto}} uses {{DMC}}, whereas {{Merge}} uses {{DMCA}}. What's the difference? @harej 06:53, 19 September 2009 (UTC)[reply]

You already changed that to {{DMC}}. And rightly so. Thanks. Debresser (talk) 23:48, 26 September 2009 (UTC)[reply]

{{editprotected}} In Category:Items to be merged I found 110 categories that were tagged with various merge templates. As we all know, the right place to go for categories is on Wikipedia:Categories for discussion (wp:cfd). Guys at wp:cfd, me included, are still busy nominating these incorrectly tagged categories according to the right procedures.

To prevent this in the future I have added a warning to the documentation page:

Note: If you want to propose merging a category, you must do so at Wikipedia:Categories for discussion.

In addition I would like to add the following code (tested and all) to the template, to display a warning in case this template is used on categories.

{{#ifeq:{{NAMESPACE}}|Category|<span class="error">For categories please use the templates available at [[wp:cfd]].</span>}}

What are your opinions? Debresser (talk) 23:41, 26 September 2009 (UTC)[reply]

Well, since it works, and it is clearly a change for the best, I shall add {{editprotected}}. Debresser (talk) 14:11, 30 September 2009 (UTC)[reply]

 Done — Martin (MSGJ · talk) 15:00, 30 September 2009 (UTC)[reply]

{{mergeto}} and {{mergefrom}} seem to have problems when used on templates; see {{Infobox magazine}} and {{Infobox journal}} - or am I doing something wrong? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 07:09, 1 October 2009 (UTC)[reply]

Fixed. The problem was that you added "Template:". The merge templates add that themselves. I shall clarify this in the documentation. Debresser (talk) 08:59, 1 October 2009 (UTC)[reply]

 Done. Debresser (talk) 11:20, 1 October 2009 (UTC)[reply]

Actually, this is one problem of the merge templates I noticed before. And you are definitely not the first to have this problem. It would be best to take care of this inside the merge templates. Let me think of something. Debresser (talk) 09:03, 1 October 2009 (UTC)[reply]

I though of something. Change in {{Pagelist}} from

-->{{#if:{{{3|}}}|{{#if:{{{4|}}}|,| and}} {{{delim|}}}[[:{{{nspace|{{NAMESPACE}}}}}:{{{3}}}|{{{3}}}]]{{{edelim|{{{delim|}}}}}}<!--

to

-->{{#if:{{{3|}}}|{{#if:{{{4|}}}|,| and}} {{{delim|}}}[[:{{{nspace|{{NAMESPACE}}}}}:{{PAGENAME:{{{3}}}}}|{{{3}}}]]{{{edelim|{{{delim|}}}}}}<!--

. And not only for 3, but for all numbers from 1 to 20 there. I think that should solve the problem precisely.

Any admin here who is willing to try it out? You only need to do number 1 to test it. Then nominate the sandbox for merging with something and write the prefix Wikipedia: in front of that something ({{Merge|Wikipedia:Copyrights}}). If you get a nice blue link, that means it worked. Debresser (talk) 03:18, 2 October 2009 (UTC)[reply]

The test went perfectly! I used {{Pagelist/sandbox}} for the improved {{Pagelist}}, and {{Pagelist/testcases}} for a copy of {{Merge}} using that improved version of pagelist. {{Pagelist/testcases|Wikipedia:Copyrights}} and {{Pagelist/testcases|Copyrights}} both rendered a nice blue link to Wikipedia:Copyrights. I shall now make the edit request on {{Pagelist}}. Debresser (talk) 06:26, 4 October 2009 (UTC)[reply]

 Done. Debresser (talk) 17:36, 4 October 2009 (UTC)[reply]

Currently, the merge templates seem to check to make sure they are not used on category pages (recommending instead that the categories be addressed at WP:CFD). However, there is currently a mergefrom template on List of Dragon Ball soundtracks suggesting a merge from Category:Dragon Ball soundtrack albums as a shorthand alternative for placing a mergeto template on every article in the category. But, the template currently escapes mergefrom input so that it links to the nonexistent article Dragon Ball soundtrack albums while displaying the text ":Category:Dragon Ball soundtrack albums". Can this behavior be easily fixed, and is this an acceptable use of the merge templates? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:36, 6 October 2009 (UTC)[reply]

It is not, and therefore shouldn't be fixed. The merge templates can take up to 20 article names. In this case even that won't be enough. But then again, I'd say merging a whole 74 pages category isn't a thing you do every day. Just add a few sample articles to the template, and mention in the discussion that you possibly want to merge all the others as well. I noticed that no discussion section has been created. That is not good. So that is the best way out. Debresser (talk) 19:54, 6 October 2009 (UTC)[reply]

All right, I had a sneaking suspicion this type of usage wouldn't be acceptable, but you can certainly understand why it's being used as such in this particular case...? ;) As to discussion, some brief discussion has taken place at WT:ANIME (I think it's been archived by now though), but it has consensus - there's just so much to do, no one feels like starting it (and all the work done so far has been some source gathering on the talk page by User:KrebMarkt and some minor list cleanup by User:Sarujo). --Dinoguy1000 (talk · contribs) as 208.124.86.54 (talk) 00:47, 7 October 2009 (UTC)[reply]

The merge template contains a link "Discuss". Press it, and on the page it opens create a section named "Merge proposal", or something like that. Either use that section for the discussion, or provide a link there to the discussion at WT:ANIME. And the best of luck! Debresser (talk) 01:39, 7 October 2009 (UTC)[reply]

There's really not much to discuss in this case - almost all of the individual albums are utterly non-notable, and the only thing that can really be done with their articles is either merging or deleting. Any that actually are notable can be easily enough re-split once the cleanup is done. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:35, 7 October 2009 (UTC)[reply]

BTW, I have updated that merge template a little. At least it now leads to the disucussion. And to the category as well. Just that it looks a little awkward, but I am still working on that. Debresser (talk) 18:23, 7 October 2009 (UTC)[reply]

Yep, I saw, and added a hidden comment to hopefully head off any questions or anyone trying to "fix" it (and also replied to part of your comment on the talk page, in case you're not watching the list). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:53, 7 October 2009 (UTC)[reply]

{{editprotected}} The documentation in Template:Merge/doc should not be transcluded into Template:Mergefrom and Template:Mergeto, because then all three templates are forced to share the interwikis related to Template:Merge only. For example, the Portuguese wiki has also three templates Fusão/Fusão de/Fusão com, but I can't associate "Fusão de" with "Mergefrom" because "Mergefrom" doesn't have its proper Template:Mergefrom/doc where I can add the interwiki to. Template:Mergefrom/doc and Template:Mergeto/doc could be very simple pages that just host the interwikis and instruct users to read the instructions at Template:Merge. —Capmo (talk) 06:57, 8 October 2009 (UTC)[reply]

Hm. Is this really a problem? Any other solutions? We could, of course, make three documentation pages again (copying and slightly modifying the present page). Debresser (talk) 10:18, 8 October 2009 (UTC)[reply]

Of course this could be fixed, but I tend to agree that it is preferable that the doc pages to be centralised, and I don't think this is a big problem. I think Debresser was also thinking about merging these templates sometime, in which case there would be even less reason. — Martin (MSGJ · talk) 11:52, 8 October 2009 (UTC)[reply]

I am. But even with my growing experience with templates, I don't feel up to that yet. Want to make a draft? Debresser (talk) 13:55, 8 October 2009 (UTC)[reply]

Please don't attempt to merge these templates before reaching a wide consensus on the subject. I particularly use templates mergeto/mergefrom much more often than merge itself. —Capmo (talk) 17:03, 8 October 2009 (UTC)[reply]

What is the problem? Obviously, if they were to be merged, the result would have to have the functionalities of all three templates. And redirects would take care of everything. Debresser (talk) 17:09, 8 October 2009 (UTC)[reply]

" No one is proposing for merge/mergeto/mergefrom to be merged. @harej 19:31, 8 October 2009 (UTC)[reply]

But admit it would be a good idea. Debresser (talk) 19:45, 8 October 2009 (UTC)[reply]

For anyone who's curious about one way this can be fixed, the individual doc subpages for each component of {{Infobox animanga}} use a hacked system preventing interwikis from being transcluded onto the central template page (which merely acts as a centralized documentation page). Not very pretty, and definitely not bot-friendly, but it gets the job done. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:57, 8 October 2009 (UTC)[reply]

I am not so sure this is a problem at all. I have seen at least one case where this problem was resolved with a simple {{{#ifeq:{{PAGENAME}}|whatever#1|interwiki#1}}{{#ifeq:{{PAGENAME}}|whatever#2|interwiki#2}}. It's a little messy, but it is better for uniformity, which is the more important consideration in long term. Debresser (talk) 19:45, 8 October 2009 (UTC)[reply]

Even simpler:

{{#switch: {{{FULLPAGENAME}}}
| case Template:Merge = interwiki interwiki
| case Template:Mergefrom = interwiki interwiki
| case Template:Mergeto = interwiki interwiki
}}

@harej 22:49, 8 October 2009 (UTC)[reply]

Very nice. Didn't know that "case" thing. Let's do that then. Could you add the interwiki's that were mentioned above? Debresser (talk) 00:24, 9 October 2009 (UTC)[reply]

Uh-oh, only now did I realize that the formula system is already implemented on the doc page, I just didn't understand well how it worked. Will add the missing interwikis there them. Sorry for the mess! Capmo (talk) 02:54, 9 October 2009 (UTC)[reply]

Actually, I don't think "case" will actually do anything but break the usage - the markup is simpler than you're making it out to be:

{{#switch: {{FULLPAGENAME}}
| Template:Merge = interwiki interwiki
| Template:Mergefrom = interwiki interwiki
| Template:Mergeto = interwiki interwiki
| #default = <!-- hahaha nothing will ever reach me! (famous last words) -->
}}

ParserFunctions don't rely on magic words except for the actual names of the functions (#if, #ifeq, #switch, #expr...). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:26, 9 October 2009 (UTC)[reply]

I knew that, actually. (Really!) The "case" bit must have been a typo or something. @harej 19:05, 9 October 2009 (UTC)[reply]

You'd probably been doing some C programming. I thought it looked a bit wrong/right all at the same time --Redrose64 (talk) 19:14, 9 October 2009 (UTC)[reply]

Thank you for assuming I write in C! I actually write in PHP, which is C's bastard step-nephew or something. But yes, in PHP you have to write case "foo": and then the operation (and then break;). @harej 19:23, 9 October 2009 (UTC)[reply]

*listens to "real" programmers talking about coding in "real" languages in awe* Blah, all I know is HTML/CSS, MediaWiki markup, TI-BASIC of the 89 Titanium variety, and a miserly amount of JavaScript... =D 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:25, 9 October 2009 (UTC)[reply]

Harej may have made confusion with the syntax of the template switch:

{{switch | {{{FULLPAGENAME}}}
| case: Template:Merge = interwiki interwiki
| case: Template:Mergefrom = interwiki interwiki
| case: Template:Mergeto = interwiki interwiki
}}

I used this syntax a lot before I discovered its ParserFunctions counterpart. :) —Capmo (talk) 02:50, 10 October 2009 (UTC)[reply]

Never heard of that template until now. @harej 02:56, 10 October 2009 (UTC)[reply]

Last month, a user inserted the rule that all merge proposals for categories and templates "must" go through XfD (with this and subsequent edits). I am not aware that there has been any discussion about this. I am opposed to this change since it is silly to impose bureaucracy to something that is by default a minor edit, such as the change of a category.

I took this to be a bold move and changed it to a compromise, but the same user engaged in a revert war without providing any reasons other than his POV that "that is a real must"[10]. Since I pledged 1RR, I will not stoop down to a revert war, but I appeal to the user to follow WP:BRD and agree with reverting to the original version. — Sebastian 22:45, 27 October 2009 (UTC)[reply]

Before addressing the issue I want to protest the accusation of engaging in an edit war. Reverting once is not "engaging in an edit war". Especially since I provided an explanatory edit summary: "No "instruction creep" that is a real must. If nominated at the wrong place, they should be administratively closed right away." Which is considerably more than Sebastian claims I wrote. Not nice. Not nice at all. Debresser (talk) 22:54, 27 October 2009 (UTC)[reply]

You're right, I'm taking the term "edit war" back. And you're right about "more": What I wanted to point out was that your summary was begging the question, but I now see that it didn't come out that way. My apologies. — Sebastian 23:05, 27 October 2009 (UTC)[reply]

No problem. I have looked around a little, but didn't find anything explicit. So I have asked at Cfd and Tfd if anybody can help find a guideline to this effect. I do know it is common practise to nominate categories/templates at Cfd/Tfd. Likewise I am convinced that it is reasonable. I remember I wrote it after some discussion on one of those pages. I'll try to find it. Debresser (talk) 23:15, 27 October 2009 (UTC)[reply]

Right. I came from Wikipedia_talk:Categories_for_discussion/Archive_2009#Items_to_be_merged. There I describe that I found templates and categories nominated for merging in a category called Category:Items to be merged. Some had been tagged in 2007! While Tfd and Cfd work through all nominations in one week. And have a look there if you see any categories or templates. Two pretty strong arguments to make the requirement I wrote. Even if I were the one to make it up. Debresser (talk) 23:19, 27 October 2009 (UTC)[reply]

Ah, I see that you brought it up then. I understand that your intentions were good, but I still don't see the necessity for this additional rule. The existing system seems to have worked just fine: We have a Category:Items to be merged, and if someone just checks it once in a blue moon, as you did, then we have no problem. — Sebastian 23:31, 27 October 2009 (UTC)[reply]

Although I don't know if "must" is exactly the correct wording, I believe Debresser is on the right track in guiding people away from just putting a standard {{Merge}} template onto a category or template page, because such merge efforts often flounder in the face of technical difficulties. Merging an article is relatively easy: combine the material into the target article and turn the other one into a redirect. Merging categories and templates is often not so simple. Category redirects don't work the same way article redirects do (there's an open RfC right now about changing how category redirects work, but even if approved they won't be the same as articles), so a full merge may require deleting the "merged" category. In theory a template can be redirected just as easily as an article, but if the fields are not an exact match between the redirected template and its target, the redirect is likely to be broken. This may not rise to the standard of being a "must", it is strongly advisable for anyone who isn't already an expert in these areas to go through Categories for Discussion or Templates for Discussion so that any complications can be discussed and an admin can assist with completing the merger. The instructions here ought to reflect that. --RL0919 (talk) 23:34, 27 October 2009 (UTC)[reply]

Funny you should bring up template parameters matching up when merging templates. This was a big issue when I merged the merge templates to simplify the system. While a single-merge did not use a named discussion-page parameter, multi-merge templates did. In order to successfully merge the templates without any glitches, I had to make the single-merge templates take on the parameters of the multi-merge templates. After hundreds of automated edits, that was finally accomplished and I merged the templates without no obvious side-effects and no lynchmobs on my talk page. Really remarkable how that turned out, since I was dealing with prolific templates that were full-protected so that people wouldn't accidentally break them. My point is, as an administrator with a bot account, I was able to take a gargantuan template merge operation and pull it off. For other editors, it may be more difficult to do. By encouraging people to talk it out before merging templates, we may be preventing the need to partake in epic cleanup jobs. @harej 00:02, 28 October 2009 (UTC)[reply]

That was basically my rationale. Apart from the fact that checking Category:Items to be merged once every two years is not serious. This is in reply to Sebastian.

If the issue is uing the word "must" or "should", then that is a minor issue and I can agree with "should" also. But the requirement in and of itself seems reasonable. Debresser (talk) 00:04, 28 October 2009 (UTC)[reply]

I don't think it's instruction creep to deal with category merges through CfD, since "merging" categories isn't like merging articles, you may need to edit hundreds of articles, and delete a category. Changing categories are also an "invisible" change, so such changes which may cause problems might not be noticed for quite a while. Templates... well not so much, since a template can be reformulated as an intermediate template that renames parameters to pass on to the "merged" template... though that would hit performance of Wikipedia servers... 70.29.209.91 (talk) 20:04, 29 October 2009 (UTC)[reply]

Current set:

Proposed set:

While some icons will always be flat, most of them (the broom, circles with symbols in them) have gently fading gradients. A while back i made a set of move icons in this style, which were not adopted, but I'd like to give it another go. I think the new set is generally more stylistically consistent with other icons (see example) and makes these icons a little less harsh. It's a subtle change; the icons are easily recognizable as refreshed versions, not new ideas. I thought I would ask for community feedback and, if it is positive, I would love to put this new set into use. Thanks, HereToHelp ^{(talk to me)} 18:00, 24 December 2009 (UTC)[reply]

• The proposed icons seem a bit too busy to me, so I prefer the current set. But as the design's creator, I'm as hopelessly partial as you are.  :) —David Levy 18:29, 24 December 2009 (UTC)[reply]
• Nice difference but don't see anything wrong with the current set. Simply south (talk) 18:41, 24 December 2009 (UTC)[reply]
• I agree with both previous reactions. Debresser (talk) 18:58, 24 December 2009 (UTC)[reply]

I too think the old set should be kept. The new set is graphically very nice, but has to much details so the templates would look too busy. Here is an example:

And the colours of the new images doesn't match very well with the purple ambox move border. Sorry HereToHelp.

--David Göthberg (talk) 04:11, 25 December 2009 (UTC)[reply]

I find the new icons more aesthetically pleasing, but this is really just the colour of the bike shed. --Swift (talk) 05:09, 25 December 2009 (UTC)[reply]

Right now if placed on books such as Book:Pokémon, the template reads as

"It has been suggested that this page or section be [[Wikipedia:Merging|merged]] into [[Book:Pokémon]]. ([[Book talk:Book:Pokémon|Discuss]])"

It should instead read as

"It has been suggested that this book be [[Wikipedia:Merging|merged]] into [[Book:Pokémon]]. ([[Book talk:Pokémon|Discuss]])"

Headbomb {talk / contribs / physics / books} 06:32, 16 April 2010 (UTC)[reply]

The same thing happens when targeting any page not in the main space. For example, a merge tag with a target of Wikipedia:Manual of Style (words to watch) will point the discussion at Wikipedia talk:Wikipedia:Manual of Style (words to watch) (which isn't a redlink because I created a redirect to get around this bug). ~Amatulić (talk) 04:00, 16 June 2010 (UTC)[reply]

Wikipedia books are created on-wiki as pages, so while the language is generic, it isn't wrong. If someone wants to put in additional namespace handling to make the language more specific, that would be a nice enhancement, but there isn't any strong need for it. --RL0919 (talk) 12:59, 16 June 2010 (UTC)[reply]

See Dividers. The merge message says "be merged into Caliper#Divider_caliper" but the link actually goes to the article Caliper rather than the relevant section. Is there a neat way to have the message point to the section that makes best sense? __ Just plain Bill (talk) 16:38, 2 July 2010 (UTC)[reply]

Seems to be the {{pagelist}} template, which uses the {{PAGENAME:}} magic word to strip off everything after the "#". --Redrose64 (talk) 17:06, 2 July 2010 (UTC)[reply]

I am here to complain about this problem too. It is not constructive to the purpose of this template. Fleet Command (talk) 07:23, 20 July 2010 (UTC)[reply]

The question becomes: is there a suitable fix replacement for {{pagelist}}? harej 12:55, 20 July 2010 (UTC)[reply]

Could someone change the templates so that they give a warning if used on talk pages (like template:afd does if you nominate it elsewhere)? I've been removing the merger template usages on talk pages but it's clear there are still hundreds out there. Beyond the problem of linking and the problem of people actually knowing what's going on, some proposals get archived and overstate the backlog (which is bad enough on its own without this). -- Ricky81682 (talk) 02:18, 8 July 2010 (UTC)[reply]

Ie. the (discuss) link should be changed. -Stevertigo (w | t | e) 20:51, 20 July 2010 (UTC)[reply]

Actually, consistency and previous documentation when {{mergeto}} and {{mergefrom}} were distinct templates, suggest it should link to the "to" article's talk page, but the change is probably as indicated, for the mostpart. However, the "Merge somewhere" tags may require more work. The problem is the discuss links on a family of {{merge}} tags should all point to the same talk page, which is difficult to automate. — Arthur Rubin (talk) 21:00, 20 July 2010 (UTC)[reply]

Appears to be already possible via: {{mergefrom|Article A|discuss=Talk:Article A#Section |date=July 2010}}. I have no comment on the more general idea of unifying discussions through clever use of targeting. -Stevertigo (w | t | e) 21:04, 20 July 2010 (UTC)[reply]

The proposed destination article's talk page was made the default discussion location for two reasons:
1. It likely receives more traffic than a proposed source article's talk page does.
2. More importantly, this setup accommodates the proposed merger of more than two articles (e.g. the merger of articles A, B, C, D and E into article F). —David Levy 21:46, 9 August 2010 (UTC)[reply]

I often run into situations when I use the 'merge to' and 'merge from' templates when 'redirect to' and 'redirect from' would be more appropriate. To cite an example, I would like to propose redirecting Djahanshah Aghssa to Anti-Nowhere League, because the artist has no notability outside of the band. Using the 'merge' templates at the top of the two pages really isn't necessary because there really is no content to merge, the redirect would be enough. Is there a template to add to the top of pages that I just can't find? Anyone agree (or disagree) that one should be made? Thanks J04n(talk page) 18:31, 9 August 2010 (UTC)[reply]

If there is nothing to merge, then just create the redirects yourself. harej 20:19, 9 August 2010 (UTC)[reply]

{{editprotected}} See for example the tag on Civil confinement, which displays the section correctly, but doesn't link to it. Can this be fixed? Tijfo098 (talk) 21:19, 20 October 2010 (UTC)[reply]

This is due to the coding of Template:Pagelist which uses the PAGENAME magic word. The reason for using this is explained in the #Problem when using with templates discussion above. However it will not preserve the anchors. So if this feature is really needed (and I question whether it is) we would need to rethink the solution. I'm disabling the request for now because further thought is required. — Martin (MSGJ · talk) 15:18, 21 October 2010 (UTC)[reply]

The template currently does not facilitate what is so common on maintenance templates, i.e. the option of specifying in the template parameters either "article" or "section". Shouldn't this be implemented (and documented) with these templates also? __meco (talk) 15:39, 9 December 2010 (UTC)[reply]

I don't think it makes sense to do so except in the {{mergefrom}} form; if information is to be merged into the article, it's almost certainly not in a single existing section. — Arthur Rubin (talk) 16:29, 9 December 2010 (UTC)[reply]

Then what about {{mergefrom}} which is the actual template I come from when making this request? __meco (talk) 16:48, 9 December 2010 (UTC)[reply]

@User:Arthur Rubin, but why exclude it as an option? Evidently the need arises every now and again. Such a need has arisen at an article I'm involved in now. Having the option to designate the parameter as "section" would have been helpful.—Biosketch (talk) 09:03, 20 March 2011 (UTC)[reply]

Describe the proposed format, noting that just having "article" or "section" as an unnamed parameter is not an option, and we'll discuss it. I don't see it as harmful as long as it's done through a named parameter. — Arthur Rubin (talk) 09:15, 20 March 2011 (UTC)[reply]

You mean start a new section here on the Discussion page? Also, I'm not that familiar with template syntax and don't know what it means that unnamed parameters aren't an option.—Biosketch (talk) 20:20, 20 March 2011 (UTC)[reply]

{{mergeto|section|Article to merge to}} or {{mergeto|section|Article to merge to#Section to merge to}} would not work, because it would prevent a proposed merge into the Wikipedia article section, as unlikely as that might seem. If you could find a similar template which had "type=", "locale=", "locus=", or something similar, I see no harm in adding the option, as there shouldn't be an enormous number of instances which have to be updated. However, a developer or someone familiar with the development interface should comment about whether this change could cause a problem. — Arthur Rubin (talk) 22:44, 20 March 2011 (UTC)[reply]

I agree that the "article" or "section" option is needed. For example, some articles such as Pillow fight flash mob, are of questionable notability as a separate article, so a {{merge to}} such as:

It has been suggested that this article merged into Flash mob. (Discuss)

would be clearer, more concise, and as Meco (talk · contribs) initially noted, more consistent with similar other templates. 67.100.125.43 (talk) 19:02, 18 April 2011 (UTC)[reply]

This message is to inform people monitoring this talk page that there is an "editprotected" request involving this and several other templates at Template talk:! cymru.lass ^{(hit me up)}⁄_{(background check)} 20:23, 28 December 2010 (UTC)[reply]

I noticed that this template puts articles using it into two categories. See for example Chris-Craft, which is in both Category:Articles to be merged from February 2010 and Category:All articles to be merged. Since the relevant Wikipedia guideline Wikipedia:Categorization says in part in the "Categorizing pages" section Pages are not placed directly into every possible category, only into the most specific one in any branch. This means that if a page belongs to a subcategory of C (or a subcategory of a subcategory of C, and so on) then it is not normally placed directly into C. I was wondering what the rationale for such double categorization is. Thanks, Ruhrfisch _><>°^° 15:40, 9 February 2011 (UTC)[reply]

Many maintenance categories have such a general "All articles that need..." category. These are supposed to help bots work through them. Of course they are not really needed, but an attempt to get rid of all of them was unsuccessful. Debresser (talk) 20:15, 9 February 2011 (UTC)[reply]

Thanks - I figured it was something like that (assume most users never even see the hidden cats). Ruhrfisch _><>°^° 21:46, 9 February 2011 (UTC)[reply]