The high-risk template protection has only been applied to Template:Template list not the other merge templates.

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 pages:

• Template:Merge
• Template:Mergeto
• Template:Mergefrom
• Template:Mergefrom-multiple
• Template:Mergesection
• Template:Mergesections
• Template:Merging

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

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 Template:Mta 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 pagename variable from the categories as we now have the defaultsort to take care of it on article pages. I'd also like to request that defaultsort 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:Template list templates with the explicit inclusion of the combined usage page now in {{merge/doc}} so that the line in each of the three:
  Unexpected use of template {{2}} - see Template:2 for details.{{/doc}} reads instead: {{merge/doc}}

• Note that per my changes, Template:Template list 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]

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]