Template talk:Merge/Archive3-to-Jan2007

From Wikipedia, the free encyclopedia

Archive 3 Template talk:Merge

[edit] Content

Archive of Merge/Archive3-to-Jan2007 
spanning the period from November 2005 through 9 January 2007 // FrankB 20:48, 7 April 2007 (UTC)

[edit] Other archives

Archive
Archives
  1. Archive 1
  2. Archive 2
  3. Voting archive
  4. "Mergewith" (superseded) discussion archive
  5. Template_talk:Merge/Archive3-to-Jan2007 (here)


Contents

[edit] thousands of pages

Original long title line of this section
"no need to place the editor's note on thousands of pages" trimmed on archive date // FrankB 21:03, 7 April 2007 (UTC)

Huh? Unless substitution is performed — which isn't (and shouldn't be) done with this template — the only code that appears is {{merge|Other item}}. —Lifeisunfair 18:58, 29 November 2005 (UTC)

"{{merge|Other item}}" appears in the wikitext, but it is expanded into the content of the template in articles, of course ("It has been suggested that this article..."). The HTML comment will not be visible on the page, but it will be extra bytes of comment code unnecessarily, and meaninglessly in that context, transmitted along with the web page's code. It's not a big deal, but since Wikipedia is one of the busiest sites on the Internet, we can be environmentally responsible by not pushing out extra bytes needlessly. I moved the HTML comment to the <noinclude> section of the template, so it will appear to editors of the template, but will not be included in Wikipedia articles. —Michael Z. 2005-11-29 20:56 Z
You're mistaken. Such comments are not transcluded; they do not appear in the HTML source of articles containing the template. —Lifeisunfair 21:09, 29 November 2005 (UTC)
Does the Wikimedia template mechanism strip comments during expansion? I did not know that, but it would make sense. Sorry to force a rebuild. —Michael Z. 2005-11-29 21:30 Z
"Does the Wikimedia template mechanism strip comments during expansion?"
Yes, the comments are automatically omitted. (See for yourself.)
"I did not know that, but it would make sense. Sorry to force a rebuild."
No problem. :) —Lifeisunfair 22:03, 29 November 2005 (UTC)
To be clear, this isn't template-specific; the MediaWiki software never includes such comments in the HTML code (irrespective of namespace). —Lifeisunfair 22:21, 29 November 2005 (UTC)

[edit] discussion links

Original very long title line
i just added optional parameters for changing the discussion links to mergefrom and mergeto

i did this to allow for a large block of very similar mergers to be discussed together. Plugwash 00:09, 9 January 2006 (UTC)

[edit] svg images

I just created svg versions of the merge images. Image:Mergeto.svg Feel free to switch to them. I would have done it myself, but the templates are protected. --Easyas12c 20:53, 15 January 2006 (UTC)

No offense intended, but...
1. Your versions contain alpha transparencies, which render improperly for most users. (Note the gray background.)
2. Your versions are simplified in appearance. (They lack the intersecting red and blue lines that ensure that neither arrow/diamond is in front of the other.)
3. While potentially useful in another context, your versions offer no apparent technical advantages for this application.
—David Levy 21:19, 15 January 2006 (UTC)
1. Damn I always tend to forget how badly IE sucks, because I stopped caring about that a long time ago. If software is broken I don't see a reason for supporting its bugs, specially when they are only cosmetic. But I do understand Wikipedia in general may think otherwise.
2. This simplicity is a bad thing?
3. Better compatibility for different user specific themes and browser default stylings, and also posibility to choose the display size and even specifying it relatively against display device and screen resolution, without blurring the image.
--Easyas12c 19:43, 16 January 2006 (UTC)
1. I don't like IE any more than you do, but we certainly shouldn't punish its users.
2. I'm not saying that the simplicity is bad, but I prefer the interlinking design to the superimposed design. I also prefer 100% opacity. Of course, I designed the icons, so I'm not exactly impartial.
3. Could you cite an example of such an implementation?
—David Levy 03:02, 17 January 2006 (UTC)
1. We should not make it unusable in IE, but if it just looks ugly, then it is a fair punishment (earned by using IE).
2. I did it that way just because it was easier to do it that way in svg. I created these along with three images for Wikipedia:Requested copyright examinations (1, 2 and 3). I wanted them to look consistent with the merge symbols, but I wanted them to be SVG, so I could not use the current ones. Thats why I created the new ones.
3. Using Wikipedia with firefox is such implementation. First firefox has its default styling (different from IE). I can also use my own style sheet as my default Firefox style (with dark background for example). Media wiki does the rendering, so it can render the images to different sizes.
--Easyas12c 23:07, 20 January 2006 (UTC)

I do like the look of Easyas12c's arrows. Would re-creating the SVG files with solid white backgrounds be the solution? Out of curiosity, does PNG transparency work in the latest IE7 beta?

Anyone know why Wikipedia's SVG renderer retains transparency, if it isn't desirable? —Michael Z. 2006-01-17 03:09 Z

Would re-creating the SVG files with solid white backgrounds be the solution?
No, solid white backgrounds would be no better. The current icons have transparent backgrounds.
Out of curiosity, does PNG transparency work in the latest IE7 beta?
PNG transparency works in IE6, but only with 8-bit files. The current icons could be converted from GIFs to 8-bit PNGs, but the size difference would be negligible (and some other browsers—such as older versions of IE, Opera and Netscape Navigator—display 8-bit PNGs improperly).
I would assume that IE7 handles all PNG files correctly, but IE6 will remain commonly used for years to come.
Anyone know why Wikipedia's SVG renderer retains transparency, if it isn't desirable?
The alternative (assigning a background color) would cause the image to display improperly in all browsers (including those that can handle alpha transparencies). —David Levy 03:21, 17 January 2006 (UTC)

[edit] Please add category sort key

This template is protected. It needs a sort key added to the category link, so

[[Category:Wikipedia maintenance templates]]

needs to change to

[[Category:Wikipedia maintenance templates|{{PAGENAME}}]]

– Doug Bell talk•contrib 01:11, 24 January 2006 (UTC

Done. —David Levy 13:56, 25 January 2006 (UTC)
Why? That is the default behaviour, surely. Rich Farmbrough, 21:00 30 December 2006 (GMT).
Adding Merge/Archive3-to-Jan2007 will, for example, sort this page under "Merge" instead of "Template talk:Merge". Brian Jason Drake 03:38, 27 March 2007 (UTC)

[edit] New graphic

Can someone please replace the existing GIF image with Image:Merge Arrow.svg? This should be identical in form to the previous image, but as a vector graphic, it's much more scalable and won't pixelate if we want to change the resolution. The page is protected so I can't edit it. Crotalus horridus (TALK • CONTRIBS) 08:07, 26 January 2006 (UTC)

Please see the "svg images" discussion above. —David Levy 00:52, 6 February 2006 (UTC)

[edit] Like AFD

Why not make a voting thing to merge like in V/AFD --FlareNUKE 00:16, 6 February 2006 (UTC)

As I explained on your talk page, no formal approval process is needed; editors may boldly merge and split pages as they see fit. In the event of uncertainty or disagreement, a simple discussion (and possibly a straw poll) is the appropriate course of action. —David Levy 00:52, 6 February 2006 (UTC)

[edit] Why do these go on articles, not talk pages?

Just a question. Why do the mergeto/mergefrom/etc templates go on the article page, not on the talk page? I guess it's a tradeoff between being visible and not, but I would have thought the talk page was more appropriate? Regards, Ben Aveling 12:44, 8 February 2006 (UTC)

This was the subject of some debate, and the prevailing sentiment was that it's important to alert readers (not merely editors), particularly given the fact that the other article might contain the information that they seek. —David Levy 12:50, 8 February 2006 (UTC)

[edit] More info in templates

I suggest adding a line

"Please also consider to take a look at Wikipedia:Proposed mergers for more comments and opinions on the proposed merger."

Most users proposing mergers add reasons for their proposal there. --Abdull 13:20, 21 February 2006 (UTC)

Actually, no, most users proposing mergers do not do so at WP:PM. Currently, fewer than 200 page titles are listed there, while Category:Articles to be merged contains roughly 7,000.
Furthermore, WP:PM serves not as a primary discussion forum, but as a means of informing readers of merger proposals and directing them to the articles' talk pages for discussion (just as the merger tags do). —David Levy 13:40, 21 February 2006 (UTC)

[edit] Interlanguage links

Please replace [[de:Vorlage:Doppeleintrag]] with [[de:Vorlage:Mehrfacheintrag]] and please add [[el:Πρότυπο:Συγχώνευση]] (this took me quite a while to find yesterday when I needed it!)

Thanks, --19:10, 5 March 2006 (UTC)

Done. —David Levy 20:59, 5 March 2006 (UTC)
Thanks! --22:46, 5 March 2006 (UTC)

[edit] Tag date

Could we add an optional paramater to the Merge templates that displays the date on which the merge was suggested? For example:

It has been suggested that this article or section be merged into Article Name. (Discuss) This change was suggested on March 6, 2006.

Now implemented. Rich Farmbrough, 21:02 30 December 2006 (GMT).

that doesn't show up on for example mergeto on Bismarck Chase. GraemeLeggett 16:22, 3 March 2007 (UTC)

[edit] Change the text

Can anyone change the text to "Discuss this issue on the [[:Template talk talk:{{{1}}}|talk page]], or if the article is ready for merging - you may perform the merging." Please see sv:Mall:Infoga. --221.251.102.59 09:46, 18 March 2006 (UTC)

The wording was debated (and even voted upon), and we arrived at a compromise between maximum brevity ("This article should be merged with _____.") and maximum specificity (something along the lines of your text, which is far longer than what our consensus dictates). We do, however, link to Wikipedia:Merging and moving pages, which describes the merger process in great detail. —David Levy 16:00, 18 March 2006 (UTC)

[edit] In regards with {{tfm}}

I found Template:tfm, but it needs to be noticed in this article as well as needing another category for that template. What are other plans for this? —69.227.173.21 11:31, 31 March 2006 (UTC)

[edit] More reasons to switch to svg

Copied from WP:IUP, emphasis added:

Drawings, icons (...) are preferably uploaded in SVG format (...) Images with large, simple, and continuous blocks of color which are not available as SVG should be in PNG format.
In general, if you have a good image that is in the wrong format, convert it to the correct format before uploading...

--Fibonacci 17:19, 16 April 2006 (UTC)

There are exceptions to every rule. Instead of arguing that the above instructions should be followed for the sake of following them, please cite a significant advantage to using an SVG icon for this particular application. I've already cited a significant disadvantage. —David Levy 17:36, 16 April 2006 (UTC)
1. My version does not render improperly to most users, just IE users. Even Konqueror users see it right.
Over 80% of website visitors use IE. By definition, that qualifies as "most users."
How many Wikipedia visitors use IE?
I'm unable to locate an up-to-date statistic, but it's almost certainly a majority.
Why?
Wikipedia probably has an above average percentage of tech-savvy users (who are more likely to use alternative browsers), but most of our visitors constitute a cross-sampling similar to that of typical websites. In fact, as Wikipedia has entered the mainstream, the percentage of visitors using IE may actually have increased.
But what difference does it make? Even if the figure were a small minority, you've yet to cite a practical advantage to using SVG versions of the icons.
Ease of editing.
Editing what? What requires editing?
In fact, 8-bit PNG versions would display properly for most users. In this instance, however, they hold very little advantage over their GIF counterparts.
Size.
When dealing with images this tiny, the size difference is negligible. Of course, an optimized 8-bit PNG would be slightly smaller than the 24-bit PNG derived from your SVG. It also would display properly for most users (though not quite as many as the GIF version).
Therefore, there's very little justification for switching over (despite the fact that only a small number of visitors would be adversely affected).
In addition to asking "What do we stand to lose," one must ask "What do we stand to gain?".
2. My version is not simplified.
How is it superior? What practical benefit would we gain by using it?
You complained that the previous SVG versions were "simplified in appearance". Mine is not.
I understand that, but you aren't answering my question. Your version isn't worse (when displayed properly), but how is it better? If it isn't better, why should we use it? (I've already explained why we shouldn't.)
What about GIF patent problems?
For us, there are no such problems. The Wikimedia Foundation is governed by the laws of the United States, where the LZW compression patents (which arguably didn't even apply to decompression) expired in 2003. It's believed that the last remaining patents in the world will expire in August of this year.
Of course, if there were GIF patent problems, we could simply use 8-bit PNGs. —David Levy 04:24, 20 April 2006 (UTC)
3. My version follows the guidelines, which is certainly an advantage.
--Fibonacci 02:49, 17 April 2006 (UTC)
Again, our guidelines provide general advice, none of which applies to every situation. Wikipedia is not a bureaucracy, and we do not blindly follow the "rules" for the sake of following them; there's absolutely no "advantage" in that. —David Levy 03:10, 17 April 2006 (UTC)
See below. --Fibonacci 21:40, 19 April 2006 (UTC)
Ditto. —David Levy 00:38, 20 April 2006 (UTC)


How is this image the exception?

None of the usual advantages to using SVGs (scalability, higher quality, significantly decreased file size) apply to these templates. In this instance, the only major difference is that the SVG displays improperly for most users.
And that the SVG shapes are easier to edit. --Fibonacci 00:56, 20 April 2006 (UTC)
When/why would we need to edit the icons? —David Levy 04:24, 20 April 2006 (UTC)

It seems to me that you are challenging the entire guideline. You're in the wrong place then. --MarSch 07:58, 19 April 2006 (UTC)

No, I'm not challenging the guideline; I'm challenging the absurd, misguided notion that we're supposed to bureaucratically follow it purely for the sake of following it (even when it makes absolutely no sense to do so). —David Levy 00:38, 20 April 2006 (UTC)
Why are we even using anything other than plaintext, even if tables, images, and many other things are rendered incorrectly to Lynx users? --Fibonacci 21:40, 19 April 2006 (UTC)
Such enhancements improve the site's appearance for most users, hopefully without substantially worsening it for the handful of people using text-based browsers.
I've tried it with Lynx. Superscripts on footnotes (for example) render improperly with a ^ character before the superscript. --Fibonacci 00:56, 20 April 2006 (UTC)
What's your point?
Conversely, your setup improves the site's appearance for no one, but it worsens it for a majority of users. And even if the number of IE6 users were anywhere near as low as the number of Lynx users (which, of course, it isn't), the fact would remain that your setup improves the site's appearance for no one. —David Levy 00:38, 20 April 2006 (UTC)
Templates, for example, improve the site's appearance for no one, yet they are still widely used. --Fibonacci 00:56, 20 April 2006 (UTC)
Templates have several practical benefits. Your proposed setup has none. —David Levy 04:24, 20 April 2006 (UTC)


So basically, because the image is small the guideline doesn't apply? --MarSch 12:28, 20 April 2006 (UTC)

The size is a major factor, but that's an oversimplification.
Very few of our policies/guidelines are etched in stone. If the application of a rule doesn't make sense, the correct course of action is to ignore it. This must be determined on a case-by-case basis. —David Levy 17:12, 20 April 2006 (UTC)

We at German Wikipedia also use the png arrow, and noone worries about IE users. (And: they'd deserve much more punishment ;-)) --MarianSigler 15:31, 2 May 2006 (UTC)

[edit] Guideline on template substitution

What is the guideline on whether the merge templates should be subst:'d or not? Should they be always, or never, be substituted?

In any case, this guideline ought to be documented clearly on both the template pages and WP:SUBST. --Pkchan 16:22, 21 April 2006 (UTC)

Never. Rich Farmbrough, 21:05 30 December 2006 (GMT).

[edit] interwiki

as the page is protected, i'd like to ask a sysop to add the portuguese interwiki, pt:Predefinição:Fusão

Waldir 21:26, 24 April 2006 (UTC)

Done. —David Levy 21:34, 24 April 2006 (UTC)

Add bg:Шаблон:Сливане as well, please. --V111P 21:59, 27 April 2006 (UTC)

Done. —David Levy 22:34, 27 April 2006 (UTC)

[edit] time limit

We need to impose a time limit on the length of time a merge template can remain on a page. I've come across a couple lately that have been sitting on pages for months. In one case the issue was discussed and died out without a consensus in October 2005. Yet it still sat on the page. In another case, one user continually adds in a merge tag that is over a year old whenever it is removed (coupled with abusive edit summaries to anyone who dares remove his template). At no stage in the year has anyone discussed it, let alone support it.

We need to require a decision relatively quickly, say, within 2 weeks. If after two weeks no-one supports the merge, the tag should automatically be removed. If the debate fizzles out without a decision, two weeks after the end of the debate the tag should be removed. It looks ridiculous to have these tags sitting there for months and months, ignored by everyone and not debated. The template should include a specific date of installation so we know when the debate period starts, and a date stating when it ends. Constant reinposition of the template when it has already been discussed should be treated as vandalism. Right now the rules for using these tags are undefined and need definition. The current mess cannot continue. FearÉIREANN\(caint) 20:09, 6 May 2006 (UTC)

I strongly disagree that any automatic time limit should be imposed. The merger tags are more similar to {{cleanup}} notices than they are to {{afd}} announcements. Your impression that their insertion signals the start of a "debate period" is incorrect. It's merely an optional suggestion of a reversible act that can be carried out without prior discussion (but probably shouldn't in potentially controversial cases).
When prominent articles are involved, a substantial amount of discussion usually occurs. A very large number of tagged pages, however, are seldom-read stubs, so it's understandable when little or no discussion formulates. It's common for mergers to be completed months after the templates are inserted, simply because of the pages' relative obscurity. Someone might stumble upon an article with a merger tag, see that no opposition has been expressed (even if no support has been expressed either), and simply perform the suggested merger. This is an intended function of the tags.
In the interim, no harm is caused by a template that few people see. Removing it due to inactivity would be tantamount to the removal of a cleanup tag on a page that no one noticed or bothered to improve. In such cases, these messages typically are added not because of controversy, but because the users don't feel comfortable performing the necessary edits themselves. The problems that they're reporting don't somehow resolve themselves because an arbitrary amount of time has elapsed.
You cited contrary situations in which it would be appropriate to remove the tags. If a merger discussion has concluded without consensus, the merger notice should be removed (unless the discussion is renewed, in which case it should be retained or restored). If a clear consensus opposing the merger has been reached, it is inappropriate to reinsert the tag. If, however, no discussion whatsoever has occurred, the appropriate remedy is to initiate a discussion. If someone opposes the merger, this should be expressed on the article's talk page. Otherwise, the tag's inserter might view its removal as vandalism. —David Levy 21:57, 6 May 2006 (UTC)
Unfortunately it doesn't work that way, David. (I wish it did.) The reason why no-one discusses that merger is because it is simply a game from a user who wrote his own article and goes ballistic if any other article even in passing mentions the topic in more than one line. His attitude is that his article alone is the place where all mention should be. (He then stands guard over it and removes any edits his dislikes!). He slaps merger tags on anywhere the topic is mentioned. At this stage no one pays the slightest heed to his antics because if they get in debate they'll only be subjected to personal attacks and no matter what the result he'll still keep his merger in place. So everyone simply ignores him.
The problem is, without an explicit cut off point, he can keep inserting these tags indefinitely and screaming censorship if they are removed. There has to some indication of agreement to justify keeping a tag in place. The onus isn't on those who oppose the mergers to indicate opposition, but on those proposing a merger to show that it isn't a one-person crusade. Until we set minimum requirements (a number of these merge tags are being placed at ridiculous locations) as to support for the proposal, and a requirement within a timeframe to act, we'll simply have ungoing edit wars with everytime a completely unused old tag being removed the installer putting it back ad nausaum. Right now they keep saying "where does it say that it has to removed even if it has no support and generated no debate whatsoever?" FearÉIREANN\(caint) 22:11, 6 May 2006 (UTC)
Firstly, the onus is on those who oppose a merger to indicate opposition. A merger is an ordinary type of article revision, so no advance approval is required; only active opposition justifies its disallowance or reversal.
Secondly, I would appreciate some diff links, but you seem to describe a highly unusual situation in which the merger tags are being deliberately abused in a disruptive fashion. This is a problem in and of itself, not a symptom of a larger problem.
All bad faith edits should be reverted, and the bad faith insertion of project tags is no exception; this is entirely permissible under the current system, and instruction creep is both unnecessary and counterproductive. —David Levy 22:40, 6 May 2006 (UTC)

[edit] Namespaces

I put {{merge|Help:Table}} on Wikipedia:How to use tables, and it links to Wikipedia:Help:Table. Am I missing something? — Omegatron 14:12, 16 May 2006 (UTC)

The current setup doesn't accommodate (relatively rare) cross-namespace mergers. As you figured out, the solution is to substitute the appropriate code. I'm going to investigate the possibility of implementing a more advanced setup via the use of ParserFunctions. —David Levy 18:30, 16 May 2006 (UTC)

[edit] Vertical space

This is pretty minor, but irritating. The <noinclude> opening tag is on a new line, meaning the template has one more newline after it than it should. It should be on the same line as the </div>. Hairy Dude 10:54, 2 June 2006 (UTC)

Done (#Request whitespace edit below). Brian Jason Drake 03:29, 27 March 2007 (UTC)

[edit] Add to 'See Also'

Duplicate of request for Admin Action on Wikipedia:Requests_for_page_protection See section='Template:Merge (edit|talk|links|history|watch)'

Actually just need this added to its See also section: '* Template:MergeVfD'; this template calls merge, and it's talk page was the oldest item on the merge backlog list, now gone. Thanks fer doin' me 'light work' (<g>) // FrankB 14:29, 6 June 2006 (UTC)

The {{mergeVfD}} template is obsolete. VfD no longer exists under that name, and we now have {{afd-mergeto}} and {{afd-mergefrom}} for this purpose. —David Levy 15:22, 6 June 2006 (UTC)

[edit] Reverse merger proposals

Earlier today, I placed {{mergeto}} and {{mergefrom}} templates on MV Val de Loire and MS King of Scandinavia respectively. Another user took exception to this, believing that the "to" and "from" should be reversed. His approach to this was to add {{mergefrom}} and {{mergeto}} templates as well, so each article had both! I took the decision to remove the second ones for the sake of avoiding confusion and splitting the merger discussion, given the default targets of the "Discuss" links.

The other user is now claiming I was wrong to remove his reverse proposal, despite me giving the above reason in the discussion. Please could somebody help me here: have I done anything inappropriate? --RFBailey 00:01, 9 June 2006 (UTC)

You should have replaced the tags with {{merge}} (which is used when the direction of the merger is undetermined or disputed). I took care of this, and I redirected the previously nonexistent Talk:MV Val de Loire to Talk:MS King of Scandinavia. If the merger occurs in the manner proposed by the other user, Talk:MS King of Scandinavia can be moved to Talk:MV Val de Loire. If no merger occurs, the redirect can simply be removed or deleted. —David Levy 17:19, 9 June 2006 (UTC)
Yes you were wrong to remove the reverse tags, it is considered unappropriate and bad Wiketiquette to remove notices from article talk pages and user talk pages especially if you have placed one and another user, disagreeing places another one, am I correct ? The then discussion no longer refers to the one proposal, but both. Captain Scarlet and the Mysterons 10:07, 11 June 2006 (UTC)
I apologise for my error: I should have remembered the {{merge}} template. Thanks to David Levy for putting me straight. --RFBailey 14:31, 11 June 2006 (UTC)

[edit] Images for {{mergefrom}} and {{mergeto}}

{{mergefrom}}
{{mergefrom}}
{{mergeto}}
{{mergeto}}

Although the image for {{merge}} itself is great, the images for the mergefrom and mergeto templates have always been somewhat confusing to me. The significance of their icons is not exactly intuitive: it depends entirely on whether you assume that "left" equates with "this article" and "right" with "that article", which, though perhaps more reasonable than the alternative, is still unfortunately ambiguous. I think a more useful image would involve a large diamond (or circle, or whatever), a smaller diamond in the "background" (i.e. shrink and elevate it a bit to give the illusion of depth; maybe even blur it slightly?), and an arrow pointing from one to the other (from the foreground to the background for "merge from", from the background to the foreground for "merge to"). Alternatively, if a simpler image is preferred, "merge from" could be conveyed by simply having an arrow point down from the diamond, thus clearly representing a merge into the text of this article (since the template is placed at the top of the page), and this would also clear up some of the ambiguity of "merge from" by making it less similar-looking to "merge to". -Silence 10:19, 11 June 2006 (UTC)

  • Also, the 'Discuss' link in the tag is rather counter-intuitive. As it currently stands, the link points to the talk page of the destination entry. When I click on the link, I expect it to take me to the talk page of the entry which has been tagged for possible assimilation. --Folajimi 20:07, 13 June 2006 (UTC)
    What about putting the Talk links inline? "It has been proposed that Article 1 (Talk page) be merged into Article 2 (Talk page)." -- nae'blis (talk) 19:30, 27 June 2006 (UTC)
    Will that require manual manipulation, or would that be a feature that is built into the template? --Folajimi 19:58, 27 June 2006 (UTC)
    The current setup was designed to discourage fragmented discussions (by directing readers to the potential destination article's talk page). In some cases, it's proposed that several articles all be merged into one page, so the opposite wouldn't work. Also, the above code would generate one of the attempted article links as plain text (because it otherwise would point to the page on which the template has been placed). —David Levy 20:52, 27 June 2006 (UTC)
    It seems that the solution, perhaps inadvertently, created another problem while trying to solve one. Folajimi 00:14, 28 June 2006 (UTC).
    The templates' behavior defies your expectation, but said expectation is entirely arbitrary. For others, the opposite seems more intuitive. Of the two, only one accommodates multi-article mergers (without encouraging problematically fragmented discussions). If someone is proposing that articles "A," "B," "C," "D" and "E" all be merged into article "F," the logical discussion venue is the talk page of article "F." Otherwise, it will be split five ways. —David Levy 00:29, 28 June 2006 (UTC)

[edit] image format re-etc.-revisited

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

Bzzzt, PNG images with alpha transparency are not rendered properly by some browsers (basically just Internet Explorer), 8-bit PNG images (like Image:Merge-arrows.png render fine just like GIF.

...and then there's SVG... The problem (they say) with SVG is that right now all SVGs are rendered into PNG images with alpha transparency, thereby making them look less than perfect in IE. Of course, 'less than perfect' means a light gray background instead of a transparent one (the arrows are still be perfectly distinguishable). OH MY GOSH, NO! Say it isn't so! We wouldn't want tasteless IE-users to have a gray background on some images, would we? We wouldn't want them to think their browser is an anicent piece of dung, would we? That'd just be wrong. :p

We should use SVG, but barring that, there is zero reason to not at least use PNG. ¦ Reisio 20:45, 18 June 2006 (UTC)

Bzzzt! As I've explained on several occasions, some older versions of various browsers (including IE, Opera and Netscape Navigator) render all PNG transparencies (including the 8-bit variety) improperly.
We're dealing with 1KB GIFs here, so the difference in file size between them and their PNG counterparts is negligible.
FYI, the gray background makes this particular image very difficult to distinguish on some displays (mainly because of its small dimensions).
Apart from satisfying your apparent desire to punish "tasteless" users, what, in this case, do we stand to gain by switching to SVGs? —David Levy 21:06, 18 June 2006 (UTC)
I'm not masochistic enough to install really old versions of Opera or Netscape, but I happen to have Internet Explorer 5, 5.5, and 6 installed, and they all handle 8-bit PNG transparency fine. There's no way to be sure how many people are using what browser, either, but it's a safe bet I think that an incredibly small amount of people are using a graphical browser other than IE 5, 5.5, 6, IE 5 (Mac), or a version of Mozilla, Firefox (etc.), Opera, Safari, Konqueror, or Netscape from the past couple years - all of which will render 8-bit PNG fine. Reisio 13:15, 19 June 2006 (UTC)
Yes, I'm sure that the number of affected users is small. So what? As minimal a disadvantage this would be, you've yet to cite a significant advantage to switching from the GIF files (which are the most compatible of all). —David Levy 20:44, 19 June 2006 (UTC)
What do we gain by switching to SVG? For the same filesize (usually smaller, really), we get support for alpha transparency, infinite scalability, and the flexibility that comes with an image that is merely markup...and the diminished but still neat lack of patent evil. ¦ Reisio 13:15, 19 June 2006 (UTC)
I explicitly asked what we stand to gain "in this case." I'm well aware of the benefits that SVGs provide in general, but none of the above advantages apply. In this case, the SVG files are larger, and alpha-transparency/scalability/flexibility are unneeded. (And of course, SVG images are displayed as 24-bit PNGs, the transparencies of which render improperly for most users.) Your "patent evil" argument is just plain silly. —David Levy 20:44, 19 June 2006 (UTC)
"We're dealing with 1KB GIFs here, so the difference in file size between them and their PNG counterparts is negligible."
By the same logic, there's no point in keeping people from switching to PNG. If someone wants to spend their time switching out GIF images for PNG images with smaller filesizes, why should you care. ¦ Reisio 13:15, 19 June 2006 (UTC)
It depends upon the situation. In this instance, I oppose the idea of messing up the templates' appearance for some users (however few) without any significant benefit. —David Levy 20:44, 19 June 2006 (UTC)
Welcome to WP:LAME, friends. Stifle (talk) 14:30, 29 June 2006 (UTC)
Given the fact that I've personally dealt with visually impaired people whose ability to differentiate between meta-content and article prose is enhanced by these icons (the recognizably of which is significantly reduced by non-transparent backgrounds), I disagree with your assertion that this is a petty, comical issue. —David Levy 14:56, 29 June 2006 (UTC)
I agree with David. SVG is a good ideal, but support for it is sketchy right now, the replacement images are NOT exact replicas, and the 24-bit PNG hack causes real problems for real users, whatever some people would say about their 'tastes' (nice bait-and-switch, by the way). These images are also up for debate on Commons; I'm not sure if this is a proxy battle for what's going on here, or what. But this SVG-crusade is misguided in this instance. -- nae'blis (talk) 15:16, 29 June 2006 (UTC)

[edit] Protected

I've protected on the m:Wrong Version until disputes on the talk page here are resolved. Mackensen (talk) 16:27, 27 June 2006 (UTC)

[edit] Downgrade of Template:Mergeto

Please restore a GIF version working with any visual browser. See also a corresponding section on this and my talk page, and an explanation on WT:Image use policy. -- Omniplex 10:19, 29 June 2006 (UTC)

Please see the relevant discussion on Freakofnurture's talk page. Recalling your recent notation of this issue, I e-mailed you on a related matter. —David Levy 11:33, 29 June 2006 (UTC)
The protecting admin unprotected the template, and an anon reverted to the GIF icon. —David Levy 02:51, 30 June 2006 (UTC)
Good, the "editprotected" here wasn't ideal for this situation. -- Omniplex 03:18, 30 June 2006 (UTC)

[edit] Distinguishing non-article namespace

Change the obvious place:

[[Category:{{#if:{{NAMESPACE}}|Items|Articles}} to be merged|{{PAGENAME}}]]

and add:

[[Category:Templates using ParserFunctions|{{PAGENAME}}]]

before existing:

[[Category:Wikipedia maintenance templates|{{PAGENAME}}]]

Very annoying that this is still protected!

--William Allen Simpson 22:37, 2 July 2006 (UTC)
I've implemented the requested changes. The template is protected because it's been deemed high-risk. —David Levy 23:44, 2 July 2006 (UTC)

Thank you. Of course, had not things gotten so far behind, it shouldn't be on anywhere near this many pages. Oh, well, I'm trying to clean up non-articles, like Categories, that should never use it.

--William Allen Simpson

[edit] Broken talk link

See the mergeto link on Bugnes - the word "Discuss" for some reason links to Talk page - it should instead link to the correct talk page. How did this happen? Stevage 08:43, 17 August 2006 (UTC)

The person who added the merge tag put it that way by using {{mergeto|Beignet|talk page}} Had the editor used {{mergeto|Beignet}}, it would have defaulted to Talk:Beignet. The optional parameter is there in case you want to differently direct discussion. DoubleBlue (Talk) 20:31, 17 August 2006 (UTC)
Ah, thanks. I didn't know it was possible to use the merge template incorrectly :) Stevage 09:32, 18 August 2006 (UTC)

[edit] Merge *-multiple templates

I suggest that we merge Template:Merge-multiple and Template:Mergefrom-multiple into Template:Merge and Template:Mergefrom, respectively, by changing [[:Template talk:{{{1}}}|{{{1}}}]] to {{{1}}} in Merge and Mergefrom.

The rationale is that there is no real need for the extra templates with more complicated features and simplicity is a Good Thing. By taking the features that introduce commas and "and" to the list, we simplify the templates while increasing their versitility without making them any more difficult to use. It is in similar vain as when Template:See was deprecated in favor of Template:Further.

Unfortunately, this change isn't backwards compatible since the usage changes from

{{merge|<otherpage>}}
{{merge-multiple|<otherpage>|<secondpage>}}

to

{{merge|[[<otherpage]]}}
{{merge|[[<otherpage>]] and [[<secondpage>]]}}

As a measure of the task at hand:

Template Number of transclusions (21:44, 17 August 2006 (UTC))
Whatlinkshere/Template:Merge ca. 3800
Whatlinkshere/Template:Mergefrom ca. 2800
Whatlinkshere/Template:Merge-multiple 40
Whatlinkshere/Template:Mergefrom-multiple 25

The change would require the use of a bot to fix the transclusions, the use of a temporary template while the old ones are being deprecated, or both. --Swift 21:44, 17 August 2006 (UTC)

Is there a template/parser function that can detect whether a parameter has ['s around it or not? If so, it could just add them if none are supplied, working in both cases. Stevage 09:33, 18 August 2006 (UTC)
Hmmm ... the choice between backwards compatibility and simplicity ...
But, yes. It is possible to do by using
{{ #ifexist: {{{1}}} | [[{{{1}}}]] | {{{1}}} }}
If the brackets are already there, the conditional won't recognise it as an article. --Swift 16:37, 18 August 2006 (UTC)
Cool. I'm not sure what "choice" there is - it will be "simple" for the end user, and backwards compatible, no? Stevage 20:52, 20 August 2006 (UTC)
Well, I think unnecessary choice does little but confuse the user. Having to use brackets is hardly an extra burden on editors. It is versitile (adding the second page will obviously need extra brackets if the first one has them) and reduces the complexity of the template (both easier on the server and template editors unfamiliar with ParserFunctions).
Moving to a single syntax is possible by updating template calls with a bot. But, as mentioned, not strictly necessary. Perhaps I'm just being too much of a puritan here? --Swift 07:46, 21 August 2006 (UTC)
The main merger templates are far too well-established to realistically expect people to alter the manner in which they're iused. Even if a bot were to replace every existing instance, there would be no practical means of informing users to adopt the new syntax, so countless broken transclusions would continue to appear indefinitely.
Furthermore, there isn't a great deal of demand for the added functionality in question. Multi-article mergers are relatively uncommon, and they can be handled via the use of multiple templates, substitution/manual editing, or the specialty templates cited above. —David Levy 08:07, 21 August 2006 (UTC)
Excellent point! Backwards compatibility is quite the must. How about making the "new" syntax the standard, phase out the old so that it may be removed when the useage has changed?
True, multiple mergers aren't very common. This is the reason why I don't see the need for an extra template when one is enough. --Swift 22:24, 21 August 2006 (UTC)

No-one has really come out against the merger. I'm on the verge of being WP:BOLD, merging the templates in a backwards compatible fashion. --Swift 22:24, 21 August 2006 (UTC)

[edit] Extra param

I would suggest to add into all "merge" templates an additional parameter, the section in the talk page where merge is discussed, to reach it in a single click on the "Discuss" link.

It is especially useful for templates mergefropm/to, because when they suggest to merge into an old page (quite often), the talk page is very long, sometimes with previous merge discussions, and it may be quite confusing where the suppposed merge talk is located.

The parameter may have a default value, e.g., "Merge proposal" What do you think? `'mikka (t) 16:09, 25 August 2006 (UTC)

It is possible to link to a specific section via the existing optional parameter. (This was missing from {{merge}}, but I just added it.) Simply use the following syntax (ideally replacing "merge" with "mergeto" and "mergefrom"):
{{merge|Other article|Talk:Talk page name#Section title}}
The inclusion of a default section title has been suggested before. Please see Template talk:Merge/archive2#Discuss link for an explanation of why this wasn't implemented. —David Levy 16:41, 25 August 2006 (UTC)

[edit] Usage: Exact location

Do these templates go at the very top of the article before any maintenance templates, hatnotes or anything else?

Joe Llywelyn Griffith Blakesley talk contrib 01:30, 30 August 2006 (UTC)

There are no explicit rules, so use your best judgement. Personally, I think I'd put it in most cases right at the top. --Swift 00:14, 31 August 2006 (UTC)

[edit] Make A New Template

It has been suggested that the section Random Trivia from the page Marques Houston be merged into this page or section. (Discuss)

I found out there's no corresponding template that would say

It has been suggested that this article or section be the section merged into Random Trivia from the article Marques Houston. (Discuss)

You know what I mean? I mean there should be to tags.100110100 03:34, 7 September 2006 (UTC)

[edit] Request whitespace edit

The template has a following <noinclude> block that starts on a new line. This is wrong, as it introduces extra vertical space in articles where there need be none. The opening <noinclude> tag should be on the same line as the end of the template. Hairy Dude 01:52, 20 September 2006 (UTC)

Done.--Konstable 06:42, 20 September 2006 (UTC)


[edit] Expanding existing templates

Original section title line
Template:Mergeto-date Expanding existing templates trimmed on archival date // FrankB 21:06, 7 April 2007 (UTC)

Might it be better to expand the date functionality to {{mergeto}}? --Swift 04:06, 27 September 2006 (UTC)

[edit] Template:Mergeto-date Discuss

{{Mergeto}} has the discuss linking to the target page. This doesn't. That risks messing up a lot of discussions. -- Beardo 06:00, 27 September 2006 (UTC)

Agreed. Lets just fix it. --Hroðulf (or Hrothulf) (Talk) 14:53, 27 September 2006 (UTC)
I seem to have successfully fixed it as you suggested. --Hroðulf (or Hrothulf) (Talk) 15:26, 27 September 2006 (UTC)

[edit] Merge-date templates

Original long section title
Template:Mergeto-date and Template:Mergefrom-date date trimmed on archive date // FrankB 21:05, 7 April 2007 (UTC)

A few hours ago, David Levy deleted the text This article has been given this tag since from both the dated templates, as "unnecessary". I assume this is because you expect editors to scroll to the bottom of the page to read the category link. That is fine by me, but I would like to register my concern that this template is being substituted on a wholesale basis without any documentation here, let alone discussing features and wording. --Hroðulf (or Hrothulf) (Talk) 08:44, 29 September 2006 (UTC)

[edit] Date functionality

I just discovered that David Levy shares my concern, and he has had an amicable discussion with the operator of the bot (at User_talk:Alphachimp#merge by month.) David has also retrofitted a date function to {{merge}}, {{mergefrom}} and {{mergeto}}, though there is no documentation at #Usage yet. I will drop him a note and ask him to update the docs here.

Note that the template adds the article to a category that may not exist yet. I suspect we need a template wizard to come up with something that quickly transcludes onto each new Category:Articles to be merged since page. Is there a Special page that finds category redlinks?

As David said, there seems to have been no harm done; only help. My thanks to David Levy and Alphachimp.

--Hroðulf (or Hrothulf) (Talk) 09:08, 29 September 2006 (UTC)

Hi! I thought that we might wait until Alphachimp's bot has changed over the articles before adding the documentation (so as not to confuse people). In the interim, the changes to the templates have absolutely no effect on their use. —David Levy 20:13, 29 September 2006 (UTC)

[edit] Deutsch (German)

de:Vorlage:Mehrfacheintrag should be replaced by de:Vorlage:Redundanz 62.245.161.54 21:33, 31 October 2006 (UTC)

I Am not quite shure, are you? --Nolanuss 02:41, 9 November 2006 (UTC)

[edit] czech interwiki cs:Šablona:Sloučit

Please add czech interwiki cs:Šablona:Sloučit . --Nolanuss 02:41, 9 November 2006 (UTC)

[edit] Single-template Proposal

I have come up with one template that I think might be useful as it would replace all the different merge templates with one. It can be found right now at User:Timrem/Template:Merge. It can be used just like the merge template currently works (aka {{merge|PAGENAME}}, or rather {{User:Timrem/Template:Merge|PAGENAME}}), but also works by using "to", "from", "section", etc. as parameters, such as {{User:Timrem/Template:Merge|to|PAGENAME}}, {{User:Timrem/Template:Merge|from|PAGENAME}}, etc. I made a full usage table at User talk:Timrem/Template:Merge. I'm open to comments as to if this is a good idea or not and to suggestions as to how to make this function better. Let me know what you think about replacing the current templates with mine. Thanks. --Timrem 21:14, 10 November 2006 (UTC)

Can't really say I like it. It makes the syntax more complex to use, and it's not like {{mergeto}} and {{mergefrom}} are all that difficult to remember. If you want to change their underlying wikicode, fine, but leave the mnemonic names alone. --Gwern (contribs) 04:46, 12 November 2006 (UTC)

[edit] Metadata

I'm pretty sure this qualifies as metadata (not suitable for printing) and would like to see "metadata" added to the CLASS (see my change at {{Mergefrom}}). I'm also not entirely certain why this template is even protected. —Locke Cole • t • c 09:00, 3 December 2006 (UTC)

"I'm also not entirely certain why this template is even protected."
AFAIK it's largely due to widespread ignorance regarding image formats other than GIF conflicting with less-widespread enlightenment. ¦ Reisio 09:51, 3 December 2006 (UTC)
{{editprotected}} request done. I also separated the in-page documentation to Template:Merge/doc —Doug Bell talk 09:54, 3 December 2006 (UTC)
As to the protection, it's because of the large number (over 3,000) of articles that translude this template. —Doug Bell talk 09:57, 3 December 2006 (UTC)

[edit] Interwiki

Please, add sl:Predloga:Združi. Thanks a lot. --Eleassar my talk 11:34, 9 January 2007 (UTC)

Done, but it didn't involve editing a protected page. The interwikis are at Template:Merge/doc. Kusma (討論) 16:45, 9 January 2007 (UTC)