Template talk:Merge/Archive 4
This is an archive of past discussions about Template:Merge. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | Archive 6 |
Created {{Mergeto-section}}
Seemed a glaring omission.--Cerejota (talk) 02:56, 14 March 2009 (UTC)
- 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)
- 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)
- 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)
Date field broken
The date field doesn't seem to work.--Yannick (talk) 22:52, 4 April 2009 (UTC)
- Yes, I fixed it and was promptly reversed by a bureaucrat, see below. — The Little Blue Frog (ribbit) 16:24, 5 April 2009 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
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[1] and its display here.[2]
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Then you don't have a consensus at all, do you? Colds7ream (talk) 10:57, 17 April 2009 (UTC)
- 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)
- Suppport I see eveyone is supporting it here. So, why is it not done yet? Fleet Command (talk) 08:14, 29 May 2011 (UTC)
- 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)
Discuss target default broken in Mergefrom
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)
- 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)
- Yikes~! Good thing I just refreshed my coffee. Thanks. +mt 21:12, 18 August 2009 (UTC)
"discuss="
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)
- It appears a bot has been fixing them, but I don't recall discussion, either. — Arthur Rubin (talk) 16:43, 7 September 2009 (UTC)
Old protection template
{{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)
- Done Thanks. Skier Dude (talk) 03:20, 10 September 2009 (UTC)
Template:Mergeto and Template:Mergefrom have different default Discuss pages
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)
- 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)
- 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)
- 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)
- 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)
- {{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)
- 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)
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)
Something broken?
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)
- {{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)
- Done @harej 22:11, 18 September 2009 (UTC)
- Actually, it's not been done. —Farix (t | c) 22:33, 18 September 2009 (UTC)
- Many tahanks. Rich Farmbrough, 22:34, 18 September 2009 (UTC).
- Ok I'll sort it. Rich Farmbrough, 22:34, 18 September 2009 (UTC).
- 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).
- Ah no harej went to "merge" first. That's the trouble with sharing a talk page. Rich Farmbrough, 22:43, 18 September 2009 (UTC).
- OK all fixed and we now have sandbox and testcases for mergeto. Always a bonus. Rich Farmbrough, 22:53, 18 September 2009 (UTC).
- Ah no harej went to "merge" first. That's the trouble with sharing a talk page. Rich Farmbrough, 22:43, 18 September 2009 (UTC).
- 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).
- Done @harej 22:11, 18 September 2009 (UTC)
Difference?
For categorization, {{Mergeto}} uses {{DMC}}, whereas {{Merge}} uses {{DMCA}}. What's the difference? @harej 06:53, 19 September 2009 (UTC)
- You already changed that to {{DMC}}. And rightly so. Thanks. Debresser (talk) 23:48, 26 September 2009 (UTC)
Merge templates on categories
{{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)
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)
- Done — Martin (MSGJ · talk) 15:00, 30 September 2009 (UTC)
Problem when using with templates
{{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)
- 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)
- Done. Debresser (talk) 11:20, 1 October 2009 (UTC)
- 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)
- 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.
- I though of something. Change in {{Pagelist}} from
- 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)
- 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
- 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)- Done. Debresser (talk) 17:36, 4 October 2009 (UTC)
- 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.
Merging from categories
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
Documentation pages
{{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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- " No one is proposing for merge/mergeto/mergefrom to be merged. @harej 19:31, 8 October 2009 (UTC)
- But admit it would be a good idea. Debresser (talk) 19:45, 8 October 2009 (UTC)
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)
- 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)- 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)
- 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)
- @harej 22:49, 8 October 2009 (UTC)
- 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)
- 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)
- I knew that, actually. (Really!) The "case" bit must have been a typo or something. @harej 19:05, 9 October 2009 (UTC)
- 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)
- 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)- *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)
- 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
- 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)
- I knew that, actually. (Really!) The "case" bit must have been a typo or something. @harej 19:05, 9 October 2009 (UTC)
- Harej may have made confusion with the syntax of the template switch:
- 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)
{{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)
- Never heard of that template until now. @harej 02:56, 10 October 2009 (UTC)
- I used this syntax a lot before I discovered its ParserFunctions counterpart. :) —Capmo (talk) 02:50, 10 October 2009 (UTC)
Instruction creep
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"[3]. 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)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
New icons?
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)
- 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)
- Nice difference but don't see anything wrong with the current set. Simply south (talk) 18:41, 24 December 2009 (UTC)
- I agree with both previous reactions. Debresser (talk) 18:58, 24 December 2009 (UTC)
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)
- 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)
Update to handle books.
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)
- 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)
- 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)
Merging to a section
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)
- 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)- 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)
- The question becomes: is there a suitable fix replacement for
{{pagelist}}
? harej 12:55, 20 July 2010 (UTC)
- The question becomes: is there a suitable fix replacement for
- 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)
Usage on talk page
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)
To unify merge discussion, mergefrom "discuss" link should link to the "from" article's talk page
Ie. the (discuss) link should be changed. -Stevertigo (w | t | e) 20:51, 20 July 2010 (UTC)
- 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)
- 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)
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)
Proposed redirect
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)
- If there is nothing to merge, then just create the redirects yourself. harej 20:19, 9 August 2010 (UTC)
Link to section doesn't work
{{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)
- 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)
Article or Section
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)
- 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)
- Then what about {{mergefrom}} which is the actual template I come from when making this request? __meco (talk) 16:48, 9 December 2010 (UTC)
- @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)
- 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)
- 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)
{{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)
- 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)
- 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)
- @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)
- Then what about {{mergefrom}} which is the actual template I come from when making this request? __meco (talk) 16:48, 9 December 2010 (UTC)
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)
Editprotected request involving this template
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)
Why two categories?
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)
- 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)
- Thanks - I figured it was something like that (assume most users never even see the hidden cats). Ruhrfisch ><>°° 21:46, 9 February 2011 (UTC)