Wikipedia:Village pump (miscellaneous)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VPM)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The miscellaneous section of the village pump is used to post messages that do not fit into any other category. Please post on the policy, technical, or proposals pages, or – for assistance – at the help desk, rather than here, if at all appropriate. For general knowledge questions, please use the reference desk.
« Older discussions, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Note: entries for inactive discussions, closed or not, should be moved to the archive.

Category:Pages using deprecated coordinates format[edit]

Category:Pages using deprecated coordinates format is being applied (to 14,801 pages, at the time of writing) by coordinate templates, despite there having been no discussion about deprecating the formats concerned. My proposal to delete the category was - after a low traffic discussion - closed, with the comment "Mayhaps you may want to have a discussion at the Village pump so that it's available for a broader forum.". In that discussion, I asked User:Jackmcbarn for a list of the edits where he applied the category, but he did not provide one.

An example of a page placed in this category, whose coordinates are applied in a manner to be expected, which was arrived at after long discussion and which has long-standing consensus, is Aiguille Aqueduct.

I will place a pointer to this discussion, at other VPs and relevant talk pages.Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:48, 2 August 2016 (UTC)

Most odd. Aiguille Aqueduct appears to employ a most orthodox use of {{coord}} within an infobox. I see nothing which would suggest this is a deprecated method. I hope we'll be getting an explanation here from whoever put this deprecation business afoot, and pointers to the discussions which led to a consensus to do this. I have not seen a discussion of this on WP:GEO nor any of the pumps. Most odd. --Tagishsimon (talk) 12:55, 2 August 2016 (UTC)
Seems like (according to the Category Talk page) the issue is that these formats cannot be used in infobox maps, thus any page with that coordinate format either a) cannot have a map or b) needs to have coordinates twice, creating the possibility of error and extra maintenance. Jo-Jo Eumerus (talk, contributions) 13:04, 2 August 2016 (UTC)
That's certainly an issue, but not one that explains the unilateral and sans discussion "deprecation" of an established method. --Tagishsimon (talk) 13:21, 2 August 2016 (UTC)
From reading the same discussion, it also raises the possibility of inconsistant infoboxs where the two co-ords not being the same place. Only in death does duty end (talk) 13:25, 2 August 2016 (UTC)
Perhaps Module:String could be used on the |coordinates= parameter to find text such as 43.2304°N 2.6086°E, <span class="latitude">43°13′49″N</span> <span class="longitude">2°36′31″E</span> or 43.2304_N_2.6086_E/43_13_49_N_2_36_31_E, all of which {{Coord}} outputs; and the values could then be put into the infobox map. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 14:20, 2 August 2016 (UTC)
There should be one set of coordinates, which can be used for both pushpin map and title coords. It's also not difficult to provide for things like |region: etc. - I did both of those in this edit four years ago. --Redrose64 (talk) 14:48, 2 August 2016 (UTC)
It'd probably be much easier to put a module into the infobox templates (so that {{Coord}} transclusions can have their coordinates extracted), than to play whack-a-mole with more than 10,000 pages which have {{Coord}} in their infobox… Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 15:20, 2 August 2016 (UTC)
Not to mention retraining thousands of editors. Deprecating something like this without public discussion and consensus is a significant overapplication of WP:BOLD and/or WP:IAR. ―Mandruss  16:19, 2 August 2016 (UTC)
I had some trouble identifying the wikitext causing this behavior. It is this which is near the bottom of {{Infobox bridge}} (I have inserted spaces to show it here.)
{{Main other| <!-- causes following to work only if in an article, not any other namespace -->
    [[Category:Articles using Template:Infobox bridge with clearance]]}}
    [[Category:Pages using deprecated coordinates format]]}}
    [[Category:Pages using Infobox bridge with extra]]}}
    [[Category:Pages using Infobox bridge with deprecated parameters]]}}
So any use of the coordinates= parameter is apparently deprecated. This test was added 2014-09-23 by Frietjes (talk · contribs). Perhaps she will join in this discussion. —EncMstr (talk) 17:25, 2 August 2016 (UTC)
that was a long time ago. probably related to this section of the documentation. basically, avoid duplicate coordinate specifications and use the specification which is compatible with the location map. Frietjes (talk) 17:55, 2 August 2016 (UTC)
I don't see how that documentation argues for deprecation; in fact, it appears to argue against it. "Usually not necessary to use" is not "deprecated". Even if it argues for deprecation, it was itself changed without public consensus. Overreach will usually come back to bite us, even if it's years later.
Had this been more widely discussed years ago, we might well have implemented the software solution described by Jc86035 and skipped the individual infobox parameters, which would have been the far simpler solution for everybody except (maybe) the infobox developers. It would have been completely transparent to editors. If anything should be deprecated, it should be those parameters, in my view. ―Mandruss  19:21, 2 August 2016 (UTC) ―Mandruss  19:06, 2 August 2016 (UTC)
When I am editing infoboxes that support both ways, I tend to use {{{coordinates|...coord...}}} if I do not want a map, and {{{latd}}} etc if I do want a map. That's editor's choice at the article level. I generally would not include the coordinates twice, nor find the "don't show the map" parameter if I use the parameters that make it appear. --Scott Davis Talk 13:19, 3 August 2016 (UTC)
@ScottDavis, Pigsonthewing, Frietjes, and Mandruss: Purely as a proof of concept, I've added a function to Module:Coordinates/sandbox which returns the coordinates in a {{Coord}} transclusion – {{#invoke:Coordinates/sandbox|coord2text|long|{{Coord|24|56|35|N|101|3|26|W}}}} returns "-101.05722". ({{Coord}} always returns coordinates in both formats, one of them invisible.) Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 14:10, 3 August 2016 (UTC)
Thanks for the effort, Jc86035.
Since we are only about halfway to finishing the conversion to the individual parameters, I feel it costs roughly the same to move in either direction. Back to the best solution, or forward to something significantly less than best. We should opt for the former, unless (1) someone more knowledgeable can show that that is substantially more work, and (2) we collectively decide that that cost exceeds the benefit. ―Mandruss  17:15, 3 August 2016 (UTC)

I'll say again what I said before: the deprecated coordinates format has no advantages (if I'm wrong about this, please tell me what the advantages are), but it has the major disadvantage that it doesn't support location maps. I see no reason to not deprecate an option in favor of a completely superior one. Jackmcbarn (talk) 01:46, 4 August 2016 (UTC)

All coordinates-related data concisely in one place, on one line. Individual elements can't get moved around and separated. Easier to see if an element is missing, and very difficult to duplicate one. Learn one parameter name, not ~10. No need to retrain editors who are familiar with {{coord}} but have never worked with location maps. Works in all articles including those that do not have infoboxes. "Doesn't support location maps" was a good argument until it was shown that it could support them, and without an excessive effort. Now it's largely a non-argument. I don't think "completely superior" is accurate. ―Mandruss  03:02, 4 August 2016 (UTC)
Okay, you do have some good points. If/when "could support location maps" becomes "does support location maps", then I'll be all for removing this category. But until that's actually done, there's the chance that we discover while doing it that it's not actually feasible. Jackmcbarn (talk) 15:47, 4 August 2016 (UTC)
Then it looks like the next step is to produce an actual working example. I take it you lack either the tech skills or the will to do that, so we're entirely dependent on Jc86035 (or Andy?) to move this forward. ―Mandruss  15:54, 4 August 2016 (UTC)
@Mandruss: It's basically ready. Move contents of Module:Coordinates/sandbox into Module:Coordinates; then, in any infobox containing a |coordinates= parameter and {{Location map}} (like Template:Infobox building), then replace (for example – from Infobox building)
 |lat     = {{#if:{{{latm|}}}{{{latNS|}}}| | {{#if:{{{latitude|}}}|{{{latitude}}}|{{{latd|}}}}} }}
 |long    = {{#if:{{{longm|}}}{{{longEW|}}}| | {{#if:{{{longitude|}}}|{{{longitude}}}|{{{longd|}}}}} }}
 |lat     = {{#if:{{{latm|}}}{{{latNS|}}}| | {{#if:{{{latitude|}}}|{{{latitude}}}|{{{latd|{{#invoke:Coordinates|lat|{{{coordinates|}}}}} }}}}} }}
 |long    = {{#if:{{{longm|}}}{{{longEW|}}}| | {{#if:{{{longitude|}}}|{{{longitude}}}|{{{longd|{{#invoke:Coordinates|long|{{{coordinates|}}}}} }}}}} }}
(This adds the value from parameter |coordinates= only if parameters |latitude=, |longitude=, |latd= and |longd= aren't present.) —Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 16:10, 4 August 2016 (UTC)
@Jackmcbarn: Does that satisfy you as to feasibility? ―Mandruss  16:15, 4 August 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Mandruss: To answer your question of 15:54 (UTC), it is quite clear that the format in question has never been deprecated. I have not wavered from my intention to revert Jackmcbarn's edits categorising it as such, so that the community can discuss the way forward, from a position of status quo, per WP:BRD, but he has failed to acknowledge my request that he reveal where he made those edits (it would appear that multiple infoboxes are involved), thereby presenting us with a fait acompli (rather, several of them). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:31, 4 August 2016 (UTC)

@Pigsonthewing: - I have a formal proposal worked up for WP:VPR, proposing elimination of the new parameters and a return to {{Coord}} in infoboxes. Such a highly-public proposal will eventually be needed, lest we repeat the failure to collaborate that we're complaining about. Just not sure we're ready for it yet. I could sandbox it if anyone wants to look at it. ―Mandruss  19:41, 4 August 2016 (UTC)
Crickets? Does anyone agree or disagree that this would be a worthwhile proposal? ―Mandruss  19:37, 6 August 2016 (UTC)
It seems like the right answer to me. The proposal is to use ene set of coordinates which are reused by the template to do all the right stuff, right? —EncMstr (talk) 19:50, 6 August 2016 (UTC)
What are the "new parameters"? Jo-Jo Eumerus (talk, contributions) 20:03, 6 August 2016 (UTC)
@Jo-Jo Eumerus: Template:Infobox building#Map and coordinates is an example. "New parameters" refers to all the named parameters that have equivalent positional parameters in {{Coord}}. I would propose to deprecate those named parameters and use only |coordinates={{Coord}}, even when there is a {{Location map}}. ―Mandruss  20:20, 6 August 2016 (UTC)
@EncMstr: Not ignoring you. With any luck I have answered your question above. ―Mandruss  20:29, 6 August 2016 (UTC)
As in, remove the |coordinates= parameter? So that the other parameters (e.g |lat_degrees=) are instead passed on to {{Coord}}? Jo-Jo Eumerus (talk, contributions) 20:31, 6 August 2016 (UTC)
@Jo-Jo Eumerus: No. Keep |coordinates=, deprecate |latd= and all the other named parameters that have equivalent positional parameters in {{Coord}} (roughly ten parameters). Modify {{Coord}} and the infoboxes to pass latitude and longitude from {{Coord}} to {{Location map}}. From above discussion, it seems Jc86035 has already sandboxed the changes to Module:Coordinates, and they have detailed the necessary changes to infoboxes above. In other words, one common way to code all coordinates-related data in any article, whether the article has an infobox or not, and whether the infobox uses {{Location map}} or not. ―Mandruss  20:56, 6 August 2016 (UTC)
@Mandruss: While my proposed implementation above extracts the coordinates out of {{Coord}}, we could simply pull coordinates from Wikidata (as {{Location map}} already seems to do). I haven't checked what the result of the RFC pertaining to pulling infobox parameters from Wikidata was, but whatever it was we could modify |coordinates= to toggle on/off Wikidata info based on a yes/no value (displaying all other values as usual). Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 07:06, 7 August 2016 (UTC)
I don't actually mind whether an article uses {{coord}} directly (perhaps in a |coordinates= infobox param) or whether it uses three or more separate infobox parameters like |latitude=|longitude=|coord_region=, so long as both methods are not used in the same article (a tracking category for detecting such duplication is useful). Where there are two methods in use on the same article, you have two latitudes and two longitudes, which should be the same, but can easily become different. Perhaps an article starts off with two identical sets, but both are wrong in some way; somebody notices that the title coord link goes to the wrong place, corrects the title coords, but doesn't notice that there is also a set of pushpin map coords which must be fixed in synch. This is what I meant by "there should be one set of coordinates" above, which some people seem to assume meant that I was taking one side. I am a supporter of pushpin maps, and for so long as the coordinates for such maps cannot be extracted from {{coord}}, I am using the separate infobox parameters method - but that doesn't mean that I always will. --Redrose64 (talk) 10:41, 7 August 2016 (UTC)
@Jc86035: I'm not familiar with the Wikidata aspect. IIRC, in the one case I've seen of coords being pulled from Wikidata, the rendered precision was 12 decimal positions (microscopic resolution), completely defeating the concepts suggested at WP:OPCOORD, which I fully support. I don't know whether precision can be controlled from Wikidata. There are multiple other reasons that solution doesn't appeal to me, which I won't go into at this point, so I would prefer to avoid it unless a community consensus requires it.
I don't really understand in detail how this implementation would go down. Looking at Wikipedia:List of infoboxes, there are probably well over a hundred, if not hundreds of, infobox templates that support the named parameters. Are you going to change and test all of them yourself? If not, are you going to create some clear instructions for infobox template editors, something that wouldn't require them to wade through one or more discussion threads like this one? If so, I think such a page should be finalized before any work starts. I presume it would then be a matter of minions like me posting template edit requests pointing to your instruction page, at the talk page for each infobox. Are you that committed to this process? I ask only because I've made one or two passing comments that have morphed into "more than I signed up for".
Redrose64, I hope I didn't give the impression that I see you as an opponent here. I do not. ―Mandruss  17:56, 7 August 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Mandruss: So Wikidata's out of the question then. For the infobox templates, I'm not entirely sure how to phrase it but it'd probably be something like "in parameter |lat=/|long= of {{Location map}} insert [module code] inside {{{latd|}}} after the vertical bar, so it replaces both |latitude= and |latd= if both are empty" (repeated twice for latitude and longitude). Most of the parameter names should be the same throughout the infobox templates, except possibly a few |coordinatesN=/|coordinatesE=. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 05:16, 9 August 2016 (UTC)

I can't imagine that being clear and detailed enough for a template editor. I lack the experience to know how to move this forward. Redrose64, do you have any suggestions? As I said I have a proposal written for VPR and could sandbox it if there is any interest in previewing/refining it. As for the implementation if the proposal passed, I'm getting the feeling it would be just another of those things that remains "in progress" indefinitely, per WP:WIP, never yielding more than a fraction of its full benefit. ―Mandruss  05:33, 9 August 2016 (UTC)
@Mandruss: Well, I could file 50 nearly-identical edit requests, if that's what you'd prefer Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 06:12, 9 August 2016 (UTC)
(Pinging BU Rob13 and Johnuniq, just because.) Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 06:15, 9 August 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I have presented the proposal as an RfC, at Wikipedia:Village pump (proposals)#RfC: Deprecate named coordinates-related infobox parameters. ―Mandruss  02:46, 12 August 2016 (UTC)

@Pigsonthewing, Redrose64, Frietjes, Tagishsimon, Jo-Jo Eumerus, ScottDavis, and Jackmcbarn: Pinging all participants in above discussion. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 04:35, 13 August 2016 (UTC)

Wikipedia talk:Shortcut[edit]

Why do so many irrelevant random posts end up at Wikipedia talk:Shortcut (history)? Is it linked from somewhere that it shouldn't be? Or is Wikipedia:Shortcut linked from many pages? I can understand Wikipedia talk:About (history), Wikipedia talk:General disclaimer (history), Wikipedia talk:Contact us (history) etc. getting a lot of attention, since Wikipedia:About, Wikipedia:General disclaimer, Wikipedia:Contact us etc. are linked at the bottom of every single page. But why should WT:Shortcut get an even higher level of noise? --Redrose64 (talk) 08:53, 13 August 2016 (UTC)

Lessee, the main page gets a very large amount of traffic, less than these super-pages though. It's linked from some article space disambigs but neither main article nor talk are linked from the MediaWiki namespace. Jo-Jo Eumerus (talk, contributions) 15:51, 13 August 2016 (UTC)
The "noise" doesn't seem overwhelming there at roughly one a week, similar to the rate at many help, welcome and training pages. Because the project pages are semi-protected, edits from new editors turn up on the talk page. Maybe new editors find this one by clicking on the word "Shortcut" in the box containing the shortcuts at top-right of pages they are likely to be looking at, like WP:About or Welcome to Wikipedia, hoping (I'm guessing) to find a "shortcut" to the wisdom contained in such pages: Noyster (talk), 11:17, 16 August 2016 (UTC)
Redrose64, I can't explain it, but if you look at the protection log, you'll see that this has been an issue since 2010 at least, when Davidgothberg semiprotected it because "This talkpage attracts to much nonsense edits." I've restored semiprotection. Nyttend (talk) 12:14, 23 August 2016 (UTC)
It seems that Ironholds (talk · contribs) lifted the prot "to let IPs participte in the current discussion", presumably Semi-protection of shortcuts - but none then proceeded to do so (final version prior to archiving). The next IP edit was seven months later, and not at all germane to either that topic or the page in general. --Redrose64 (talk) 16:28, 23 August 2016 (UTC)

Source code messages to discourage editors[edit]

I just wondered how we deal with source code messages like this one aimed at preventing editors from a certain modification or addition to an article. This particular case is a curious one because Giano II (talk · contribs) decided this one 8 years ago unilaterally without prior discussion anywhere, but even if the message is softened to a suggestion for prior discussion before adding an infobox as modified by SchroCat (talk · contribs), is this really how we want it? Especially since, in that particular case it turned out that the suggestion was just a sugar-coated way of saying "suggest an infobox on the talk page so that we can tell you they are not mandatory by Wikipedia guidelines which entirely nullifies all your arguments instantly and chokes the discussion."

Anyhow, my point is that we should not have these discouraging messages in the first place. Rather than have to seek new consensus in a week-long discussion, editors should simply edit. If lets say over a several weeks a different editors repeatedly attempt to add an infobox to a certain article, then that's a sign of new consensus. Messages like the one added to this particular article have quite probably discouraged any attempt to add an infobox over the past 8 years. --bender235 (talk) 01:39, 17 August 2016 (UTC)

You may want to see Wikipedia:Arbitration/Requests/Clarification and Amendment#Amendment request: Infoboxes.--Moxy (talk) 01:45, 17 August 2016 (UTC)
Nice way to open the back door for tag teaming IB Warriors to force their own way on pages: a system that validates and rewards edit warring. Brilliant. The text is a polite way of asking people to use the talk page to avoid edit warring. I don't know why you would want to avoid the talk page for a system that actively encourages edit warring by tag team. – SchroCat (talk) 03:44, 17 August 2016 (UTC)
Infoboxes are a different case, I'm not familiar with this issue (and I don't see why an article couldn't have an infobox if it's useful), but for example if editors repeatedly try to add information that's known to be incorrect, that does not mean there's a "new consensus". So not all notes like that are necessarily evil. nyuszika7h (talk) 09:48, 17 August 2016 (UTC)
I understand what you mean. I would not compare it to adding incorrect information, but rather something like re-naming/re-ordering section titles, or shuffling images around in an article. An infobox usually is not about correct or incorrect information. --bender235 (talk) 13:34, 17 August 2016 (UTC)
I think that particular comment should have pointed to a discussion or given a reason. Overall I have no problem with comments discouraging editing if there is a good reason and a number of wrong edits have been done. For instance in spherical coordinate system even with comments discouraging them people still change the convention in equations - there's two main conventions normally used for them. Dmcq (talk) 11:06, 17 August 2016 (UTC)
I just remembered I had deleted an infobox [1] in the last couple of days! It was too large and displaced more useful stuff and really wasn't at the same level as the article. I certainly don't dislike all infoboxes but I do think they have to earn their keep. Dmcq (talk) 11:15, 17 August 2016 (UTC)
I just realized we actually have a guideline regarding the misuse of hidden texts. I guess this particular one falls under point 3: Telling others not to perform certain edits to a page, unless there is an existing policy against that edit.. Especially since the hidden text was added in a unilateral decision with no prior discussion at all. --bender235 (talk) 13:39, 17 August 2016 (UTC)
That doesn't look like a guideline – I think it's an essay (though one, somewhat deceptively, not labeled as such...). In any case, I don't think that's in any way "binding" – it just looks like a suggestion. --IJBall (contribstalk) 15:41, 17 August 2016 (UTC)
What makes you believe that Help:Hidden text is an essay? Also, it is linked from MOS:COMMENT. Let's hear from the creators/early contributors Sebwite, OlEnglish, Victor Victoria, and Berny68 please. --bender235 (talk) 18:09, 17 August 2016 (UTC)
I will label the page so there is no confusion (its an essay in the "help namespace"). This bring up a good point ...perhaps we need to expand our guidelines on this point. -- Moxy (talk) 18:25, 17 August 2016 (UTC)
I've reverted that. Wikipedia:Manual of Style #Invisible comments links to Help:Hidden text through the {{main article}} template. That identifies it as the detailed exposition of which MOS:COMMENT is the summary, as described at WP:Summary style. As part of the Manual of Style, it has the same status as a guideline, not an essay. --RexxS (talk) 22:20, 17 August 2016 (UTC)
@RexxS thats a bad it is not part of the manual. Many essays are linked from policy and guidelines. Best not to mislead seen above. Pls revert or use a different essay template so editors are not confused in the future. -- Moxy (talk) 00:57, 18 August 2016 (UTC)
I've reverting to Moxy's addition – I agree that Help:Hidden text is not a guideline. --IJBall (contribstalk) 04:04, 18 August 2016 (UTC)
It is just as much part of the MOS as any other daughter page would be when using WP:Summary style. The purpose of the {{main}} template is to give fuller information to a summary section. Wikipedia:Manual of Style #Invisible comments is the summary section for Help:Hidden text. Of course Help:Hidden text is a guideline - you only have to read it see that. I'll revert back - you have no consensus to change the state of the page. --RexxS (talk) 10:45, 18 August 2016 (UTC)
I agree that Help:Hidden text is a guideline, or if it isn't already we should make it one since these issues need to be addressed. --bender235 (talk) 12:30, 18 August 2016 (UTC)
Rather than just arguing among ourselves, I've set up an RfC at Help talk:Hidden text to try to reach a broader consensus on the issue. Hopefully that will move us forward. --RexxS (talk) 16:24, 18 August 2016 (UTC)
There is some clear confusion here as to what is what the fact an essay tag is a badge of dishonour - it is not. Please see Wikipedia:Essays#About essays and its main linked essays. When it comes to template documentation as with {{main}} see WP:CONLIMITED --Moxy (talk) 20:55, 18 August 2016 (UTC)
Nobody is suggesting that an essay is a badge of anything. The issue is simply whether a Help page has any standing in supporting a given position in a content debate. Editors should be free to ignore essays (like WP:Essays itself), but Help pages, like guidelines, should represent broader community consensus, and not be dismissed as optional at any editor's whim. --RexxS (talk) 17:44, 19 August 2016 (UTC)
All page that have not been approved by the community at large are classified as essays ...there are many types of essays - helpful ones, informative ones and even opinionated ones. Help pages are authored in the same manner as all others pages...some good some bad - Help:help See Wikipedia:Template messages/Wikipedia namespace. -- Moxy (talk) 23:00, 19 August 2016 (UTC)
That's pure invention on your part. There are many types of pages that are not policies, guidelines or essays - see WP:Policies and guidelines #Role "Policies ... Guidelines ... Essays ... Other pages that can be found in the Wikipedia: namespace include community process pages (which facilitate application of the policies and guidelines), historical pages, WikiProject pages, or help pages (also found in the Help namespace), community discussion pages and noticeboards." Stop making things up. --RexxS (talk) 23:09, 19 August 2016 (UTC)
Perhaps someone else can explain better then me. We have two types of "info" pages here those approved by the community and those that have not been approved by the community. Anyone may write a help page, anyone may also write a page about civility and so on see Wikipedia:Essay directory. Lets quote one of our guides WP:ADVICEPAGE - " An advice page written by several participants of a project is a "local consensus" that is no more binding on editors than material written by any single individual editor. Any advice page that has not been formally approved by the community through the WP:PROPOSAL process has the actual status of an optional essay." I edit alot on help and info pages and do not think those pages are more or less important then other essays. -- Moxy (talk) 02:22, 20 August 2016 (UTC)
So your position is that Help:Hidden text has no standing in any content dispute because in your view all help pages are essays? Whereas my position is that Help:Hidden text is not merely linked from Wikipedia:Manual of Style #Invisible comments, but is designated as the full page that the section of MOS summarises, and therefore is a guideline because it's part of MOS. Fine, we can make a decision on the status of Help:Hidden text by discussing its merits as a guideline at Help:Hidden text #RfC on status of this page. --RexxS (talk) 17:36, 20 August 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── This is an issue which is, practically, not going to be easy to solve. There are many essays, some clearly-stated as essays, some not, which are "see also'ed" or equivalent from policy or guideline pages. Whether those references/links give them some weight more than mere essays (as referred to by WP:ADVICEPAGE) is a question which, as far as I know, has never been addressed. Since I spend a lot of time monitoring some policy pages, I would note that on the core policies the addition of such links generally doesn't get by without consensus and, thus, at least some blessing as something more than just essays, but on other non-core policies I'd be willing to wager they don't get nearly as much attention. The practical problem is that I don't think that any one answer will work: In some cases they probably are "junior policies" or "policy by reference" but in others not. The problem is compounded by the fact that since they're not identified as policy or guidelines, that editors coming onto them from places other than the links in the policy feel much freer to edit them than they would a policy and since others may not think of them as policy-by-reference, they may not come under the same degree of scrutiny as designated policies or guidelines. Frankly, with all that in play my thought is that as a general rule they cannot be given any more weight than ordinary essays and that editors who wish for them to be given weight as guidelines or policies should be required to formally propose them for that status. Regards, TransporterMan (TALK) 23:01, 20 August 2016 (UTC)

That's a good analysis, although I'd add that the use of {{main article}} implies not just a link, but a two-way relationship. It would be anomalous for a section of a guideline to depend on (i.e. be the summary of) the content of an essay. I've already made the formal proposal for Help:Hidden text, which should produce some clarity in the particular case. Does anyone know of other help pages that ought to be considered for testing against the formal process? --RexxS (talk) 23:24, 20 August 2016 (UTC)
  • FWIW I've also dropped the question of the status of help pages to ArbCom: if they are to make a decision on hidden text, they should clarify whether their rationale is based on essay, guideline, policy or other and, accordingly, the weight that should be given to Help pages in relation to the others. – SchroCat (talk) 16:35, 18 August 2016 (UTC)

New Wikiproject[edit]

We have started WikiProject Unsourced Article Rescue, as there are thousands of older unsourced articles. We will be holding article rescue drives, with rewards. Sign up today! ThePlatypusofDoom (talk) 23:34, 19 August 2016 (UTC)

TfD pending for Split from/to[edit]

Not sure what's the best place to post this, so I'm just posting here. Feel free to move or place a notification on other relevant talk pages. {{Split from}} and {{Split to}} were subject to a TfD discussion back in March, and it was closed with a consensus to merge, but all that was done is {{Split article}} created as a copy of {{Split from}}. It does not appear to be usable as a replacement for {{Split to}}. Honestly, {{copied}} can do the job fine and it may be best to convert transclusions to that, but I'll leave the details to someone else. Pinging Izkala as the closer and BU Rob13 as the creator of {{Split article}}. – nyuszika7h (talk) 14:14, 26 August 2016 (UTC)

Please, no – I'd rather the merge go through, as {{Split from}}/{{Split to}} are easier to use than {{copied}}. --IJBall (contribstalk) 15:09, 26 August 2016 (UTC)
@IJBall: As I explained at Amaury's talk page, it's almost the same, the main four parameters listed in the documentation are enough, so not sure how a merged version of these would be much easier to use. But if someone actually does that, I wouldn't have a problem with it. nyuszika7h (talk) 20:04, 26 August 2016 (UTC)