Misplaced Pages

Revision as of 04:41, 16 May 2013

• Table of contents
• First discussion
• End of page
• New post

• WP:VPP

Please see this FAQ page for a list of frequent proposals and the responses to them.

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace

• view
• edit
• history
• watch
• archive
• talk
• purge

Use of accessdate in citation templates

As presently defined in Citation Style 1, the |accessdate= in citation templates is intended to indicate the date that an online resource was retrieved. As such, the value provided for |accessdate= is only displayed if |url= (or one of its analogs, like |chapterurl=) is included.

The underlying logic here is that an access date is intended to be used to determine the version/edition of an online work that one is looking at. By contrast, physical works such as books, journal articles, and the like generally have different mechanisms for determining the version (e.g. publication date, issue number, etc.). In general, an access date is unnecessary (and often useless) when determining what version of a book or other physical work is being cited. So, the long-standing practice is that |accessdate= is only displayed when a URL is present.

However, the new Lua citations reveal about 45,000 pages where an |accessdate= was given in a citation that didn't use a URL. This makes this usage by far the most common "error" in how citation templates are presently used.

Some people have criticized the current practice (e.g. this discussion), suggesting that the access date should always be displayed when given. Or alternatively that the access date should be displayed for some other situations that generate external links, such as using |doi=, |oclc=, |bibcode=, etc. (Though if you have a DOI or Bibcode, does an access date add any information about the version cited?)

So, I would like to ask the larger community:

1. Do you agree that |accessdate= should only be displayed if there is a URL present? Or should the present behavior be changed in some way?
2. If we agree that there are circumstances where having an access date is not helpful, then should we take steps to inform people when not to add it? For example by including a visible error message? This could help people understand when to use an access date, and help understand why it isn't shown in some cases. (At present, Lua citations can generate an error message for this, but it is hidden from users unless they specifically configure their personal CSS to see it.) Alternatively, we could just decide that this "error" is so trivial that it isn't worth bothering people over.
3. If we want to have a user visible error message, should we first task a bot with removing the access date from currently existing citations that are using it inappropriately? That would limit the impact of an error message to informing people presently writing citations, rather than placing a rather trivial error message on 45000 pages with existing citations.

Thanks for your feedback. Dragons flight (talk) 03:54, 29 April 2013 (UTC)

Note: the error help link leads here -DePiep (talk) 09:11, 29 April 2013 (UTC)

1. No, update the help page and template to match actual practice. 2. No, this is a programmer issue, not an editor mistake. Trust the cite-er to know whether an access date is warranted. There may be reasons for its use that are not obvious to a third party. 3. N/A. VQuakr (talk) 04:24, 29 April 2013 (UTC)

Your position appears to be that the access date should always be reported. Given that, it might help clarify the situation if you can offer some examples, or find some in the category mentioned above, where having an access date can help in identifying the work being cited even though no URL is present. Dragons flight (talk) 05:35, 29 April 2013 (UTC)

without taking a position on the issue as you framed it, i can foresee situations that verify VQuakr's position, such as in cases of a paywall of some sort. if the url is restricted, an editor may decide not to post it. but the accessdate is still useful. 70.19.122.39 (talk) 13:11, 29 April 2013 (UTC)

Citations with a |url= pointing to a resource that requires payment or registration should still be included in the citation. This limited access is noted by the {{subscription required}} or {{link note}} templates, or the new |subscription= parameter and is not an excuse to leave |url= empty and simultaneously include |accessdate=.

If the reasons for doing something unconventional are not obvious to another editor and not explained by hidden comments or other means as a way of making it obvious, such unconventional uses may, and probably should be removed or replaced.

|accessdate= has been part of the {{cite web}} documentation from the beginning when it was first established as a required parameter.

Documentation for |accessdate= first added to {{citation}} with this edit.

—Trappist the monk (talk) 18:37, 29 April 2013 (UTC)

clarity, please. in my reading, WP:SOURCELINKS seems to suggest that paywall links should appear only when the source is online and nowhere else:

If the publisher offers a link to the source or its abstract that does not require a payment or a third party's login for access, you may provide the URL for that link. If the source only exists online, give the link even if access is restricted
— WP:SOURCELINKS

70.19.122.39 (talk) 00:45, 30 April 2013 (UTC)

to add, if the above holds, a "naked" accessdate has some significance, in situations where the citing editor formatted the citation by having access behind the paywall.

70.19.122.39 (talk) 00:58, 30 April 2013 (UTC)

If no free versions are available, and the source is available on paper, then you may link to paid versions if you want—or not if you don't want. We do this all the time with scientific journal articles. If the source is online-only, then you must provide the link no matter what. WhatamIdoing (talk) 02:06, 30 April 2013 (UTC)

but that's not my question. if the editor may not want to enter the paywall url, s/he may still want to add the accessdate, to specify the retrieved version, esp. when the content changes. this would be relevant. 70.19.122.39 (talk) 12:20, 30 April 2013 (UTC)

clarification: the above is for paywall sources that also exist in other media, not just online. 70.19.122.39 (talk) 12:26, 30 April 2013 (UTC)

Citations should only contain as much information as necessary to help the reader verify the information in the article. When citing a non-static webpage, the access date is necessary, to pinpoint which version of the webpage contains the relevant information. When citing books, journals, newspaper articles, the content isn't going to change, so the access date isn't necessary (same goes for most online articles or blog posts; while these may not be as static as paper sources, they usually display a "last updated on" date alongside the publication date). However, I don't know if I like the idea of hiding parameters, or displaying an error message – partly because this is likely to confuse editors, and partly because there will always be exceptions. And redundant access dates don't do any real harm. I think it would be enough to add a note to WP:Citing sources#What information to include to more clearly discourage the use of access dates where the publication date is given (it currently implies this, with "required if the publication date is unknown", but that's open to interpretation). I routinely remove redundant access dates when I come across them, and while I haven't been challenged yet, it would be nice to be able to point to a specific guideline to justify my actions. DoctorKubla (talk) 06:34, 29 April 2013 (UTC)

How can we know a webpage is "static"? There is no guarantee ever. That would depend on the honesty & maintenance quality of the page owner/editor. This is also true for so-called read-only pdf files. I like the "underlying logic" reasoning in 2nd paragraph, so I'd keep the status quo for question 1. It is very logic, consistent and relatively easy (compared to other cite style elements). Also, the old citation documentation says (today): |AccessDate= date when the |URL= was accessed.. So the current errors were errors before (though unmarked). It seems the only issue is the sea of red errors now appearing. We do not have to change the style documentation to get them out. -DePiep (talk) 09:08, 29 April 2013 (UTC)

• From the current CS1 documentation: "accessdate: Full date when original URL was accessed; use the same format as other access and archive dates in the citations; do not wikilink. Not required for web pages or linked documents that do not change; mainly of use for web pages that change frequently or have no publication date. Can be hidden or styled by registered editors."
  • Note: The over use of access dates had gotten so bad that CSS was added so that editors could hide them.
• Publication Manual of the American Psychological Association, 5th ed., p. 192: "Do not include retrieval dates unless the source material may change over time.
• Chicago Manual of Style, 16th ed., 14.7: "An access date—that is, the self-reported date on which an author consulted a source—is of limited value: previous versions will often be unavailable to readers; authors typically consult a source any number of times over the course of days or months; and the accuracy of such dates, once recorded, cannot readily be verified by editors or publishers. Chicago does not therefore require access dates in its published citations of electronic sources unless no date of publication or revision can be determined from the source (see 14.8). For such undated sources--or for any source that seems likely to change without notice—authors are encouraged, as an additional safeguard, to archive dated copies, either as hard copy or in electronic form. Because some publishers in some disciplines—in particular, research-intensive fields such as science and medicine—do require access dates, authors should check with their publishers early on, and it never hurts to record dates of access during research."
• --  Gadget850 09:54, 29 April 2013 (UTC)

The vast majority of accessdates in Category:Pages using citations with accessdate and no URL seem pointless. They weren't added because the editor knew better. Don't display accessdates without a url. If a convinving case can be made that there are situations where an accessdate is valuable without a url then we could consider a new parameter like display_accessdate_with_no_url = yes. I wouldn't mind a long name like this so editors are fully aware what they request when they use the parameter. PrimeHunter (talk) 11:05, 29 April 2013 (UTC)

This is one reason why I never use templates to format citations... you don't get these problems when you use the old <ref>text, text, text</ref> format. That said (for those who do like to use the templates)... I agree that accessdates are needed for webpages that might change over time, but not for other citations. A template needs to be flexible enough to be used in all situations ... both citations that need an access date and those that don't. Blueboar (talk) 13:32, 29 April 2013 (UTC)

I think that an accessdate without a URL is pointless, but I am concerned that some of these citations might have contained a URL at the time that they were added. We have a small problem with people violating WP:DEADREF by deleting any URL that doesn't work for them. WhatamIdoing (talk) 20:23, 29 April 2013 (UTC)

• Numerous Bibcode, doi, PMC, PMID, OCLC weblinks have accessdate: A survey of pages will reveal numerous articles where cite editors think the accessdate is when a webpage was accessed, where the URL is specified by the various id codes: Bibcode, doi, PMC, PMID, OCLC, etc. Those cites generate the web-link URL from the id code, and so there is a "url" in those cites. -Wikid77 (talk) 21:38, 29 April 2013 (UTC)

• Spam filter promotes omitting improper URLs: Another major factor, to cause people to leave "accessdate=" but no URL, is to have the spam filter tell editors that their URL is improper (such as a news website), and then they learn how removing the URL worked to save the page with the cite title (and accessdate), as long as the URL was omitted. -Wikid77 21:38, 29 April 2013 (UTC)

• Over 150,000 accessdate problems, multiple per page: The count of "45,600" pages in the accessdate category is misleading, because in many cases, there are multiple accessdate problems on each page, often as a pattern of an editor who added several sources and set each "accessdate=" before those cites generated the Lua red-error messages. -Wikid77 21:38, 29 April 2013 (UTC)

• Many people think accessdate is when a source was accessed: After viewing thousands of articles, the clear pattern I have noticed is people who set the accessdate to whenever they read a particular source webpage, book or document. The accessdate is not exactly when they edited the page, but rather whenever they viewed the cited document, perhaps weeks or months earlier. Often the viewing of a newspaper story is given an accessdate, even if no proper (spam-filter-allowable) URL was stored in the page. I use the word "Viewed" when people consider access to a book. -Wikid77 21:38/21:42, 29 April 2013 (UTC)

i don't understand what your implied definition of "accessdate" is. if it is not the date of access, what does it signify? 70.19.122.39 (talk) 00:51, 30 April 2013 (UTC)

It's supposed to be used for when you access an online source, not when you access any old source. WhatamIdoing (talk) 02:36, 30 April 2013 (UTC)

• Agree with WhatamIdoing In general accessdate should only be used when needed, which would mean URLs for the most part. But I routinely see people removing dead URLs rather than finding an archive. This leaves the reference with an accessdate but no URL. This is a problem we should be aware of during this discussion. 64.40.54.181 (talk) 01:44, 30 April 2013 (UTC)
  • Well now there will be a red link in the references section after that edit. I guess a redlink in the article text would trigger the editor who is probably not going to look at the bottom of the article to see if they messed anything up. While maybe overkill, maybe a bot to post a notice on the editors page? Since I have been doing categories lately I scrool past the references, I try and fix those red warnings while I'm in the article. Vegaswikian (talk) 02:03, 30 April 2013 (UTC)
    • Or the bot could simply remove the accessdate, since it is of no further use (it's in the history if needed). —— 02:27, 30 April 2013 (UTC)
      • Or not since the best solution may be to undo an undesirable change. How can the bot tell when to remove and when to fix? I almost suggested a bot to remove bad parameters, or at least those with no data. However I'm not convinced that is wise. Humans need to look at a lot of these. I don't think using the over sized sledge hammer to fix the square peg into the round hole is the best solution here. Vegaswikian (talk) 02:38, 30 April 2013 (UTC)
• None of the above (1, 2, or 3): I think the accessdate is useful for offline resources to document the date the editor actually saw the material. This can be used to resolve ambiguities if there are problems with the rest of the cite (i.e. missing issue number/date), etc. As to whether to display the date or not, that's up to the more biblio-minded people to decide as a matter of style. Even if it should be decided not to render the date in some situations, I'd still leave it there and make it clear that it can be used for internal documentation, even though hidden. —— 02:27, 30 April 2013 (UTC)
• My comments and observations are as follows:
  1. There is simply no point of displaying access dates when there is no url. These should be either deleted, or not displayed.
  2. In line with the guideline, I believe we should switch off displaying of accessdates in certain templates, such as {{cite book}}, ore remove these altogether. The content of books, printed magazines or newspapers changes with the edition and is independent of accessdates.
  3. I do a lot of refs work, and would say that access dates for electronic citations are in general about as useful as wet tissue paper, and I'm inclined to follow the advice of the CMOS (quoted above).
  4. I have no objection to keeping accessdates only visible as metadata where they have been supplied and the content is still 'live'; many are formatted in what I would call 'machine language' and are incomprehensible to the average reader. Simply not displaying accessdates, which are irrelevant to most users, would considerably reduce on-screen clutter
  5. I'm not in favour of showing any error message where these involve access dates. Editors wanting to clean up will already have that category to sift through.
  6. There is nothing that 'defines' a static web page. However, general links that contain short names (or only the domain name) are much likely to be non-static than ones with long urls with many slashes. Having said that, a lot of long urls also go dead (like yahoo news links), and we should advise editors to prefer other news sites that have enduring static content. -- Ohconfucius  04:49, 30 April 2013 (UTC)

• Completely agree with everything Ohconfucius says above, especially points 3 and 4. I also do a lot of refs work, and I have always found access dates to be a great deal more trouble than what little they are worth. -- Alarics (talk) 07:39, 30 April 2013 (UTC)
• opinion: 1. if the paywall issue i discuss above is resolved in some way or other, i have no problem displaying the accessdate only when urls are present. 2. no error messages please. emphasize the proposed guideline in the doc and make accessdate dependent on url (if no paywall) 3. no. even though leaving the naked accessdates in is inconsistent, this goes into article cleanup territory, and should be treated under the relevant guidelines.

comment: i disagree with ohconfucius re: the usefulness of accessdates for online citations. from a verification standpoint, when an online source is concerned, i start with the accessdate as the most significant piece of information: i have no way of knowing whether any given page is static, and i want to verify the citation as the citing editor saw it and composed it. if that particular version is unavailable, i have to make further research on whether the content changed since, which is a chore. if i cannot determine the content's stability, the citation as formatted is unverifiable afaic. even if i find the source in other media (another chore) i have to make sure the content is similar in both.

70.19.122.39 (talk) 13:01, 30 April 2013 (UTC)

• My opinion. Access dates are not very useful without a URL. The only utility I can think of for non-URL uses is in cases where subsequent edits move the citation away from what it supports or insert statements not supported by the cite. In those cases, it functions more like a timestamp for when the citation was added to help locate the original version in edit history. I have found it useful on occasion to locate dead URL links in the Internet Archive. To sum up, I don't see any reason to prevent editors from adding the access dates for non-URL links, though I agree there is no reason to display access dates for non-URL links. older ≠ wiser 13:20, 30 April 2013 (UTC)
  • When the url is dead, the accessdate is invariably not necessary. 'Live' citations are more often found using the article title. -- Ohconfucius  16:19, 30 April 2013 (UTC)
  • Wait, check accessdate first: As noted above, when the web-link url is dead, the first thing I check is the accessdate (not the title which often differs from the actual webpage), and if recent, then I re-try the url, very carefully, because a recent "deadlink" is often a case of prior server-offline-long, rather than a true dead-link URL address. -Wikid77 (talk) 19:40, 30 April 2013 (UTC)

• Opinion for original 3 questions: So, after reading responses above, I think: 1. No, always show any accessdate. 2. No, no error messages. 3. No, do not have bots remove accessdates. -Wikid77 (talk) 12:49, 1 May 2013 (UTC)
• I will say that not displaying the red error and just categorizing the page is totally useless! I just went to the category to see how it is being used and maybe fix a few. Without the red error, these errors are for all practical purposes hidden. If so they will not be fixed. Vegaswikian (talk) 19:05, 10 May 2013 (UTC)

Consensus: show accessdate if present

Well, after reviewing all opinions above, the only reasonable consensus is to show the "accessdate=" value whenever present (without error message: see (visible error message?) dif319 "No, this is a programmer issue, not an editor mistake" or dif8429 "not in favour of showing any error message where these involve access dates" or dif9404 "no error messages please" or dif947 "no error messages"). This is because, when omitting error messages for non-url accessdates, then a user would wonder why a cite keeps refusing to show the accessdate, regardless of where the parameter is placed, even if "accessdate=" is added 10x times it would not show based on the Lua cite's url-only rule. Plus, in actual usage, people find other places to put the URL data, such as within the "id=" or even as "format=". As feared in the above discussion, there have been several exceptions to the url-only rule, in actual use, where people have in fact linked a source webpage in other cite parameters, and set the accessdate for that web-link. Hence, "The exception makes the rule" to always show an accessdate. So, all accessdate parameters would be displayed, and then editors who dislike accessdates could remove them with consent of other editors of each article. Meanwhile, showing accessdate, without restrictions, would fix more than 150,000 date errors in the Lua-based wp:CS1 cites. It would also fix accessdate errors in double-nested cites, such as inside the Template:Cite_pmid or Template:Cite_doi subtemplate knowledgebase. I want to thank everyone above for exploring all aspects of the accessdate problems, to reveal the final consensus, and to note how some people use the accessdate to deduce an omitted document date (month/year) or check for prior revisions (see: dif1464 "it functions more like a timestamp") for when a URL was available (removed as deadlink). -Wikid77 (talk) 19:40/20:05, 30 April 2013, 14:05, 1 May 2013 (UTC)

Huh? --  Gadget850 19:46, 30 April 2013 (UTC)

Editor Wikid77 may be misstating the facts: This is because, when omitting error messages for non-url accessdates, then a user would wonder why a cite keeps refusing to show the accessdate, regardless of where the parameter is placed, even if "accessdate=" is added 10x times it would not show based on the Lua cite's url-only rule. Not true. Neither the Lua nor the {{citation/core}} versions of {{cite book}} display the contents of |accessdate= when |url= is left blank or omitted as this very simple comparison shows:

Apparently, then, not displaying the accessdate when there isn't a url has been going on for some time and is not new to the Lua version of the citations.

I'm not really clear on the point that sentence is trying to make. If I didn't know better, I'd think that Editor Wikid77 is in favor of the error messages that CS1 displays. But that can't be the right conclusion given writings elsewhere.

I can't say when I've ever seen a url in |id= or |format=. That's not to say that it doesn't happen, but I haven't seen it so I'm inclined dismiss this claim as interesting but rare unless there is evidence that I've missed.

Is there a new rule to always show the accessdate? When did the rule-making occur? Who was party to it and where can I read the discussion that the took that decision?

150,000. Where does this number come from?

How does hiding an error message fix something that may be broken?

Preemptively declaring consensus seems to be the purpose here. I'm not convinced that Editor Wikid77 is the editor to make such a declaration.

—Trappist the monk (talk) 02:14, 1 May 2013 (UTC)

• Accessdate used to locate a newspaper article: There seems to be a misunderstanding, above, because when an accessdate is specified for a magazine article, then it could be a clue to the print date (rather than hidden):

• Parameters: {{cite document |author=John Doe |work=The Telegraph |title=Article Name |date=2009 |accessdate=1 June 2009}}
• Result: John Doe (2009). "Article Name" (Document). {{cite document}}: Cite document requires |publisher= (help); Unknown parameter |accessdate= ignored (help); Unknown parameter |work= ignored (help)

The consensus viewpoint is to show the accessdate (no error messages), and editors could modify the page if they do not want to see it. Hence, readers could see the accessdate ("1 June 2009") to find that newspaper article of 2009. Current cites which use accessdate to timestamp a source are one of many exceptions, as suspected above, where the accessdate should be shown even without "url=". That is why the consensus view is to always show the accessdate, as date information, to handle all situations. Editors who want to remove the date can edit the cite. Thus, this is a consensus which addresses all options. -Wikid77 (talk) 05:30, 1 May 2013 (UTC)

• Uh huh.   However, as noted above, there could be an optional parameter to change the default results, such as by setting: hide_accessdate_with_no_url = yes, with the "long name like this so editors are fully aware what they request when they use the parameter". Otherwise, if editors set the accessdate, then the accessdate should appear in the formatted citation (with no error message, as people indicated above). Also in the discussion above, many actual cases were noted, and I have seen many cites of newspapers where the "accessdate=" provided the clue to the missing "date=" often where those dates would be the same/next date, and someone added the cite with accessdate set to being the day they read that newspaper article. If the accessdate were suppressed while having no "date=" parameter, then the readers would not know which day/month/year to check for the newspaper page. It really makes a lot of sense, when other editors discuss what typically happens in actual cites, and why readers seeing the accessdate, in a displayed article, can help, or is often crucial, to find the specific source/version to read. -Wikid77 (talk) 21:35, 30 April 2013 (UTC)

There is no need for special parameters to hide an accessdate on a citation. If you don't want to see them, see this: Help:Citation Style 1/accessdate.

—Trappist the monk (talk) 02:14, 1 May 2013 (UTC)

• Access date is not a time stamp for when every citation was added. An access date, as defined by the major style guides as noted above, is the date a web page that contains no discernible date was accessed or for a web page that changes (example: Misplaced Pages main page). Frankly, a web page that does not include a date should be examined carefully to ensure it is a reliable source.
• Online documents identified by doi, Bibcode, JSTOR and the like are not going to change, thus no access date is required. Printed works are not going to change, thus no access date is required. If an online work is revised, then the 'date' should reflect the change.
• The purpose of the citation is to identify the source work and each element needs to be considered in that context. We don't work in a vacuum: we mainly use the APA and Chicago style guides.
• Simply because we have a way to hide the access date for individual editors does not mean that showing it for everyone else is right. This just means that we had no good way to show spurious access dates and editors got tired of seeing them.
• Bottom line: 'accessdate' without 'url' is a spurious citation element. 'accessdate' with 'url' but with 'date' is a spurious citation element. --  Gadget850 10:13, 1 May 2013 (UTC)

some clarifications are needed imo: 1. citations by def. identify sources. their purpose is to aid verification. it may look like a minor point, but it properly (in my view) shifts emphasis to the reader from the editor. the discussion has been too editor-centric. if readers are not going to use citations (no matter how well-formatted), they are useless 2. the incongruity between WP:CITE (section WP:SOURCELINKS) re: restricted urls, and what is being proposed here has to be resolved in some fashion, perhaps by a "paywall/subsrcription" option? 3. also account for the guidelines re: Google Books (WP:BOOKLINKS – only preview/fullview urls). Google Books imposes viewing limits per unique IP/Google sign-in. a previously available url may suddenly become restricted for users that share ip addresses (practically anyone at work, libraries, etc.). even though most Google Books content doesn't change, "accessdate" for such sources may become significant in view of the limitations. 70.19.122.39 (talk) 12:50, 1 May 2013 (UTC)

if consensus has not been reached, please edit the section heading, it may mislead. 70.19.122.39 (talk) 12:52, 1 May 2013 (UTC)

That section heading refers to the "consensus viewpoint" which has been supported by a rough consensus of opinions already stated. So, it is not misleading. -Wikid77 (talk) 14:05, 1 May 2013 (UTC)

I don't know how disinterested Admins who close discussions on whatever subject can do it and feel confident that they know and understand the consensus. It must be easier when the proposal or question is tightly constrained. In this case, Editor Dragon Flight's multiple questions aren't tightly constrained. Editors in this discussion have raised related issues and stated opinions that don't actually answer Editor Dragon Flight's questions.

If I sift through the discussion above and extract postings that only address the first part of Editor Dragon Flight's first question, (I've intentionally ignored answers to questions two and three because they are dependent on an affirmative answer to question one) this is what I get (quotes may have been edited for brevity):

• Do you agree that |accessdate= should only be displayed if there is a URL present? – Dragons flight

• No, update the help page and template to match actual practice. – VQuakr
• "citing a non-static webpage, the access date is necessary"; "citing books, journals, newspaper articles, ... access date isn't necessary" – DoctorKubla
• "I'd keep the status quo for question 1" – DePiep
• "Don't display accessdates without a url." – PrimeHunter
• "accessdate without a URL is pointless ... might have contained a URL at the time that they were added" – WhatamIdoing
• "accessdate should only be used when needed, which would mean URLs for the most part" – 64.40.54.181
• "None of the above (1, 2, or 3): I think the accessdate is useful for offline resources to document the date the editor actually saw the material." – AlanM1
• "1 ... no point of displaying access dates when there is no url"; "2 ... switch off displaying of accessdates in certain templates, such as {{cite book}}, ore remove these altogether"; "3 ... access dates for electronic citations are ... as useful as wet tissue paper, ... follow the advice of the CMOS"; "4 ... no objection to keeping accessdates only visible as metadata where they have been supplied and the content is still 'live'" – Ohconfucius
• "Completely agree with everything Ohconfucius says above, especially points 3 and 4" "access dates to be a great deal more trouble than what little they are worth" – Alarics
• "if the paywall issue i discuss above is resolved in some way or other, i have no problem displaying the accessdate only when urls are present." "i disagree with ohconfucius re: the usefulness of accessdates for online citations." – 70.19.122.39
• "Access dates are not very useful without a URL." "I don't see any reason to prevent editors from adding the access dates for non-URL links, though I agree there is no reason to display access dates for non-URL links." – older ≠ wiser
• "When the url is dead, the accessdate is invariably not necessary." – Ohconfucius
• 1. No, always show any accessdate. – Wikid77

If I have incorrectly attributed or misquoted or improperly edited your comment please point that out.

So, this sifting leads me to a conclusion that is distinctly different from Editor Wikid77's conclusion. In general, the answer to the first part of Editor Dragon Flight's first question seems to be yes, accessdates should only be displayed when there is a url.

The answer to the second part of Editor Dragon Flight's first question is a little harder to get because editors seem to have declined to answer it. Those who appear to have answered it state:

• Or should the present behavior be changed in some way? – Dragons flight

• If a convinving case can be made that there are situations where an accessdate is valuable without a url then we could consider a new parameter like display_accessdate_with_no_url = yes. – PrimeHunter
• As to whether to display the date or not, that's up to the more biblio-minded people to decide as a matter of style. Even if it should be decided not to render the date in some situations, I'd still leave it there and make it clear that it can be used for internal documentation, even though hidden. – AlanM1
• 4 Simply not displaying accessdates, which are irrelevant to most users, would considerably reduce on-screen clutter – Ohconfucius

Not a clear agreement here and probably an insufficient number of opinions upon which to base a consensus.

—Trappist the monk (talk) 16:57, 2 May 2013 (UTC)

• Consensus viewpoint is a workable compromise: In the early years of Misplaced Pages, there were discussions about types of voting to determine so-called consensus, but the concept now has been explained as a "compromise" position. Of course there are some users who do not want to see accessdates. However, we already know more than 30,000 users prefer to show all accessdate values, with over 40,100 pages having accessdate without a "url=" or "chapterurl=" or such. There are many editors who have set accessdate with the weblink for Bibcode, doi, OCLC, ISSN, PMC, PMID, Zbl, etc. Plus other editors, above, have already noted cases where the accessdate is set but the URL was (later) omitted due to paywall restrictions, or deadlink status, or spam-filter rejection, or being obvious from newspaper and title. In some cases, the only date information comes from the accessdate, and people have used those dates to find prior revisions where that cite was added, to then check what text was backed by the original cite (before other unsourced text was added at the same cite). Plus I have found cases where people put URL addresses in the "id=" parameter, while setting accessdate for that. For all those reasons, the logical, workable, compromise is to show the accessdate if present (with no error messages), but allow a page to be edited to remove accessdates if other editors agree for those pages. Also, users can set their CSS-page to suppress the class to bypass all accessdate values for them. Hence, the consensus viewpoint is to always show the accessdate by default, but allow users to suppress or remove unwanted dates, as a workable compromise. I have also suggested creating a new parameter (perhaps named "urldate=") which could be used to show red-error messages in new cites when parameter "url=" was not set, as being directly tied to new usage of the url parameter, not a retroactive restriction. So having all those options allows for a workable consensus, as noted. This does not require years of discussion to resolve. I think we have reached a workable compromise now. -Wikid77 (talk) 16:15, 3 May 2013 (UTC)

Conceptually, I agree that consensus can be defined as a workable compromise. However, we don't have that here. What we have is one party unilaterally declaring that a state of compromise and hence consensus exists. Compromise is not reached through declaration but through negotiation. Where is the negotiation? Thus far, there has been The Question; there have been expressions of opinion regarding The Question; there have been posts declaring consensus (you); there have been posts disputing the declaration of consensus (me). There has been no negotiation so there is no compromise.

How do we know that more than 30,000 users prefer to show all accessdate values? Where does that number come from?

That editors misapply |accessdate= is not disputed; that editors remove |url= without also removing |accessdate= is not disputed; that editors use |accessdate=, orphaned or not, to research a citation is not disputed. These facts do not explain why all accessdates should be visible and the existing error messages that highlight malformed citations should be removed.

No need to "allow" |accessdate= removal – that privilege already exists; that registered editors can hide all accessdates with css is not disputed. These facts are simply statements reflecting current practice that don't establish a new consensus viewpoint.

The idea of |urldate= is worth consideration though probably not in this forum.

Where there is negotiation, there can be compromise and consensus. Unilateral declarations of consensus do not constitute actual consensus.

—Trappist the monk (talk) 10:12, 5 May 2013 (UTC)

Handling non-consensus accessdate issues

To address specific concerns of issues which do not meet the rough consensus, then more discussion should be continued. Some issues to discuss:

• Suppress all accessdates already in cites: The idea to suppress all accessdate values, as a rare viewpoint, could be handled by a user-preference which redefines a CSS class to hide the accessdate value, which even contradicts the current documented use of "accessdate=" to be a parameter which is displayed in some cases. However, that user-preference option could be explained in a help-page for custom viewing of articles. -Wikid77 (talk) 14:41, 1 May 2013 (UTC)
• Have an accessdate to reject when no URL, perhaps urldate: For editors who want to have an accessdate parameter which future users could be warned not to use, then consider adding a new parameter to the full wp:CS1 style, perhaps named "urldate=" which could issue an error message to beware usage, because the old parameter "accessdate=" has already been used in over 150,000 citations without a "url=" or "chapterurl=" parameter. Typically, when changing the rules, avoid retroactive "punishment" (or error messages); however, a new parameter "urldate=" would not have a retroactive impact. -Wikid77 (talk) 14:41, 1 May 2013 (UTC)
• Update Misplaced Pages essays to warn how people think "access" means "accessed" or "viewed": Because thousands of editors have already imagined that "accessdate=" was the date on which they accessed a source, then it should be noted, in Misplaced Pages design essays, how over 30,000 people ran away with that notion, and perhaps having a parameter named "urldate=" might have avoided that confusion about the word "access". A rough consensus often forms around the perceived meanings of terms, rather than the formal, precise redefinitions, as in stated in style manuals. -Wikid77 (talk) 14:41, 1 May 2013 (UTC)

• Feature already available through CSS due to the overuse of spurious access dates.
• "an accessdate parameter which future users could be warned not to use" My babel fish just puked in my ear when it could not translate this.
• Already in the template documentation, as noted above. Where else should it be? --  Gadget850 17:54, 1 May 2013 (UTC)

PLEASE don't randomly delete accessdates. If you want to get rid of the error, you can just comment out the parameter.

• It really sucks to come across a dead link, try to 'fix' it, and find 300 entries for that url on the Wayback Machine.
• It also sucks to find where someone used {{cite web}} for something like a NYT article, and put 'accessdate' of the day they read it, instead of the publication date from the page. It 'autobreaks' when it moves behind the paywall, but if the editor put in the access date it makes it easier to actually fix the cite (like all the {{cite web}}s that are actually to wire service stories, and available elsewhere).
• The accessdate isn't really 'part' of a citation, imo...you should be able to find the source w/o it, eventually...it's more like an 'editorial comment' of "This was working on this date"....i.e. metadata. It lets someone else come by and 'clarify' the reference by connecting it to the right Wayback Machine page without having to worry about breaking the actual 'citation'.
• A better fix for the 'overdisplay' of them, IMO, would be an additional parameter to {{reflist}}...something like...{{reflist|suppress-postcripts}} for use in 'overcrowded' reference lists.
  • Something like this would also be useful for things such as LCCNs, WorldCat, etc. People object to including or adding them because it 'breaks' the layout, but the 'metadata' they embed is important.
  • Even better would be something like {{reflist|postscript-footnotes}} to automatically 'fold' the spammy and 'nonessential' parts of the citations, like the {{DNBfirst}} banner and such, into a 'reference footnotes'.
  • You could 'optionally' change the 'book sources' ISBN link in the cite to a little link like (search for this book) to book sources, and move /all/ the UIDs out of the reference list itself into a 'reference footnote'.
• I think (I'm not going to try to test it, because I might break an article) that you should be able to simulate this effect by wrapping the {{reflist}} with the 'suppress accessdates' css, in the article itself. Revent (talk) 18:13, 10 May 2013 (UTC)

• No - the accessdate should be the date you read/accessed an electronic document. It _isn't_ the publication date, which is date. Secretlondon (talk) 18:30, 10 May 2013 (UTC)
  • Right. I'm not saying that....sorry if unclear. My point is that if someone used a {{cite web}} for, say, an NYT story, and put in an accessdate, it's easy to fix, even if I can't 'see' the paywalled story...I can look up the 'byline' to get the publication date, and use the citation tool to 'autogen' the corrected paywalled url in a {{tl:cite news}}. Hiding the access date doesn't 'break' that, but drive-by deleting of it does. Revent (talk) 19:10, 10 May 2013 (UTC)

I mean hiding in the sense of commenting out here. Revent (talk) 21:22, 10 May 2013 (UTC)

if the citation is behind a paywall, and you have no easy/free access to other formats of the source, you cannot verify the byline or anything else about it. this goes for all restricted sources. you have to obtain paywall access. the extra step immediately degrades the quality of the citation from a verification standpoint. this standpoint is much more important than presentation, or someone's idea of aesthetics.

newspaper articles are often corrected. so accessdate for a paywalled source can become significant in 2 ways where source info is altered: 1. it helps determine the citation's initial veracity (before alteration at the source) and 2. it can flag the citation (and therefore the relevant article information) as in need of correction/verification, or as obsolete (after the alteration at the source).70.19.122.39 (talk) 17:15, 11 May 2013 (UTC)

I'm not saying I would remove the access date. What I'm saying is that I would fix the url (which is only a convenience link, you're citing the NYT itself, and saying you /saw/ it on their website) to the 'permanent' location that the NYT uses for their archive. BTW, the NYT cite tool (once you give it the 'correct' url) actually pulls the article author, name, publication date, etc from the NYT archive (this is all info that's usually missing). Just a {{cite web}} to the 'free' location on the NYT current stories, with no more info, is totally useless, and I mean TOTALLY. With an accessdate, I can find the story...it was always published within a week or so before the accessdate, and I can use the 'words' in the dynamic url (and the topic) for comparison against the 'headline/byline/lead' on a free newswire and make sure it's the right story. NYT doesn't change them after they go to the archive...they write new ones. :)

If there /is/ some kind of uncertainty, I can just comment out the original markup of the cite, put the 'corrected' one in, and mark it with a commented {{verification needed}}, keeping the same accessdate on the new cite, and someone can check it in....what....three clicks? and then edit the cite if something is wrong, or take out the flag. What's arguable about this? Every reader is an editor.

And yes, you never change the accessdate unless you actually 'fact checked' the article...i.e. reread it, and said "Yes, it's accurate. I'll verify that." With stuff like a webpage on the Wayback Machine, that's trivial to do. Revent (talk) 22:30, 11 May 2013 (UTC)

• Or I can say 'oh, that's a news agency story', find a 'free' copy (like from the service itself), check the cite real fast, and change the source to the 'better' one. Revent (talk) 22:48, 11 May 2013 (UTC)

• {{reflist}} can't modify any of the entries in the reference list. All it can do is apply a style to the list, such as columns or labels. The list is generated by the included <references /> tag which is part of the Cite software extension. --  Gadget850 23:20, 11 May 2013 (UTC)

RFC: WP:MOS-AM discussions

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Misplaced Pages policies and guidelines When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

There are two discussions concerning changes to the manual of style on anime- and manga-related articles. The discussions can be found WT:MOS-AM#Article content and WT:MOS-AM#Franchise articles. The current wording of the manual of style's article names and disambiguation section regarding separate articles for a franchise (such as Ghost in the Shell and Dragon Ball) is:

In general, do not create separate articles for a different medium belonging to the same franchise, unless:

1. They differ sharply in plot, characters, or in other major characteristics; or
2. The article becomes too large.

In one of these discussions regarding article content, a user has expressed concern about not mentioning WP:SPLIT in the MOS. Also, there is some concern about WP:LOCALCONSENSUS as well. However, since this may create a bit of controversy, I suppose more input from the community would not hurt. Thanks, Lord Sjones23 (talk - contributions) 02:44, 30 April 2013 (UTC)

Having read the two discussions, is the RfC question, whether the MOS be changed to allow the articles to be split per WP:LIMIT of sections other than those sections listed in MOS-AM?

From what I can read of the Wikiproject MOS, the MOS does not say do not create subarticles but gives guidence on which sub-articles (and thus which section to split) first.--RightCowLeftCoast (talk) 17:42, 30 April 2013 (UTC)

Yes. The question is Should the MOS be changed to allow the articles to be split per WP:LIMIT of sections other than those sections listed in MOS-AM? Lord Sjones23 (talk - contributions) 17:55, 30 April 2013 (UTC)

Instruction creep? I am wondering when the issue of splitting an article became something that a Style guide should discuss... Is the MOS-AM being used as a one-stop all-purpose catch-all set of "rules" for Anime related articles? Blueboar (talk) 20:00, 30 April 2013 (UTC)

Not to detract, but I am confused if this is the discussion area or if this a call for attention. To answer Blueboard's comment, yes it is being used for that purpose. MOS-AM also states, Articles should be self-contained, only referring to subpages for additional information or details if the main article or a section becomes too long. Follow guidelines at Misplaced Pages:Summary style when creating subarticles. So either way, the "In general, do not create separate articles for a different medium belonging to the same franchise" is in conflict with greater Misplaced Pages policy and with MOS-AM. Hence why, I cited your comment as reason for the removal of the questionable section. A manual of style, or a wikiproject cannot override community consensus on a wider scale. ChrisGualtieri (talk) 03:29, 1 May 2013 (UTC)

Stop insisting on a "franchise". Blueboar, the MOS currently states that the main article on any anime and manga should be about the original work of fiction (whether it began life as an anime or as a manga), with separate articles dedicated to episode lists, character lists, chapter lists, and films. ChrisGualtieri's issues with the manual of style stem from the fact that there are currently no separate articles for the Dragon Ball Z TV series or the original Ghost in the Shell manga.

Regarding Ghost in the Shell, there was for the longest time a relatively short article just on the original manga separate from what Chris keeps insisting on calling a "franchise article". I boldly merged this "manga only" article with the central article, bringing it in line with the format that every other anime/manga page is in, while retaining the separate manga page as a "list of chapters" page instead.

On Dragon Ball Z, Dragon Ball is the original work of fiction, and its content was adapted into the anime Dragon Ball (covering the part of the manga where the main character is a child/teenager) and Dragon Ball Z (covering the part of the manga where the main character is an adult with children). As they are just two parts of a whole, they got rid of the separate "Dragon Ball Z" (and Dragon Ball GT, a third TV series with an original storyline) article and merged it into the main one. Chris's argument is that because Dragon Ball Z is arguably the most popular form it has taken in the west that it requires a separate article.

All in all, the arguments aren't really swaying anybody at the WikiProject as they feel it is better not to have so many pages on 95% identical topics.—Ryulong (琉竜) 05:24, 1 May 2013 (UTC)

Ryulong, that is not in there, MOS-AM states "Article introductions should be primarily about the original format of a work and not about the most popular format of that work. For example: "Bleach is a manga series, which was later adapted into an anime series", NOT "Bleach is an anime series, based on a manga of the same name." Article introductions are lede and the first coming work, to prevent 'Bleach is an anime series' from being discussed when it was a manga first. Your 'original work'-focused argument seems to be your own creation. Prove to me otherwise. MOS-AM is not perfect, but this 'original work' issue has destroyed GITS and DBZ was effectively neutered by a bad and undeveloped page and a manual of style being used as policy. Why was the unrelated-to-the-manga GT anime even merged then? ChrisGualtieri (talk) 12:20, 1 May 2013 (UTC)

My thoughts on this issue: if there is enough reliably sourced material to create a separate article, then it is perfectly acceptable to do so. MOSAM should not and can not prevent this as this is enwiki policy and guidelines. Preventing the creation of viable reliably sourced articles is against everything Misplaced Pages stands for. I think the original reason MOSAM had that little bit added in was to prevent the creation of gazillions of character pages and individual volume pages for manga (I have a vague recollection of a discussion about that years ago), but I think that can be dealt with via PROD, AFD, and similar methods. Any article which doesn't meet the basic guidelines for inclusion can be deleted. We don't need MOSAM trying to micromanage things for us. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 06:11, 1 May 2013 (UTC)

Thank you for stating that, and I do understand we have numerous character articles that do not meet N or GNG. A recent example is Obito Uchiha prior to the merging. With no references and commentary and speculation running rampant, the MOS-AM 'general' comment was probably meant for this and not international bestsellers and cultural icons. ChrisGualtieri (talk) 12:29, 1 May 2013 (UTC)

• Delete I just jumped from page to page trying to figure our what the centralised discussion was. It seems to be some prescriptive time-wasting contrary to WP:CREEP and WP:NOTLAW. Please eliminate it. Warden (talk) 16:54, 3 May 2013 (UTC)
• In general, I don't think we need genre-specific instructions about when to split or not to split articles. The general rules at WP:SS and WP:N are quite workable for all topic areas.  Sandstein  07:05, 5 May 2013 (UTC)
• Feels like instruction creep. The idea that closely related works are often easiest and best described, and their articles maintained, as a single article is simple enough and would hopefully be apparent to most editors. That anime/manga might be a case of this might be worth a mention. That there are exceptions doesn't need a mention, it merely requires editors to have an understanding of what these general rules about, and a bit of common sense. --j⚛e decker 16:42, 11 May 2013 (UTC)

Partially disambiguated titles

I propose that we establish a guideline stating that parenthetical disambiguation should render titles unambiguous and that, consequently, WP:PRIMARYTOPIC should only apply to titles that do not employ parenthetical disambiguation. For example, Orange (film) redirects to the Orange disambiguation page because there are multiple films that are called "Orange"; each film's article therefore uses a fully disambiguating parenthetical, such as Orange (2012 film). Similarly, Party (album) redirects to Party (disambiguation) because there are multiple albums called "Party"; the articles about albums called "Party" are fully disambiguated, such as in the case of Party (Iggy Pop album). It has been argued in certain individual cases (normally citing WP:PRIMARYTOPIC) that the most prominent member of a particular category of thing should hold the less-disambiguated slot, thereby employing a partially disambiguated title. In the majority of cases, partially disambiguated titles have already been rejected through local consensus, but there is not anything in the guidelines at present to explicitly prevent partially disambiguated titles. I propose that we exclude partially disambiguated titles from our articles because the purpose of parenthetical disambiguation is to disambiguate; parenthetical disambiguation that does not disambiguate does not serve its purpose. Neelix (talk) 15:02, 4 May 2013 (UTC)

Agreed. There are some projects and naming conventions that already specify this approach, but it is not a WP-project-wide standard. I think it should be; by the time a parenthetical qualifier is opted for, there's no reason to create a "qualifier hierarchy" -- the qualifier exists for disambiguation, so let them disambiguate fully. -- JHunterJ (talk) 15:37, 4 May 2013 (UTC)

I agree that a uniform approach would simplify matters and avoid unnecessary move discussions as to whether some particular instance of an already disambiguated title is the primary use for that type of topic. Discussions about primary topic already have a tendency to become unnecessarily combative over such trifling matters. older ≠ wiser 16:31, 4 May 2013 (UTC)

• Since most people would expect New York (city) to redirect them to the article about the city of New York, it does. It should not redirect to New York (disambiguation). In other words, the primary topic principles apply to all titles, including titles of redirects with parenthetic qualifiers. If this proposal were to pass, an enormous number of redirects like New York (city) would have to change. And to what end, exactly? What problem would this solve? --B2C 04:57, 5 May 2013 (UTC)
  • Wow, that's an excellent point! I never thought of that. But if this is only a guideline, surely we could IAR that for the most important of cases? Or should we just state that there is a very, very strong preference for 100% unambiguous parentheticals, and put New York (city) as a counterexample? Red Slash 05:27, 5 May 2013 (UTC)
    • Even better, clarify the point of the proposal, which is to not name an article with a partially-disambiguated title. If phrased that way, New York (city) is not a counter example, since it's not the name of an article. It doesn't really hurt that it's a redirect based on primary topic. The nom asserts "It has been argued in certain individual cases (normally citing WP:PRIMARYTOPIC) that the most prominent member of a particular category of thing should hold the less-disambiguated slot, thereby employing a partially disambiguated title." If that's true, it does sound to me like a very bad idea; however, without examples, it's hard to argue what we need a guideline to avoid a potential problem. Does anyone have an example? If we find one or more, we can argue specifics as to whether it's a good idea or not. – I just noticed that Template:R from incomplete disambiguation says "This is a redirect from a disambiguating title that is too ambiguous to identify an article. Such titles should generally redirect to the appropriate disambiguation page (or section of it)." I don't know if this is a guideline, but it pretty much has the suggested intent already, since we're talking about titles that are too ambiguous to identify an article; but we could amend it to allow redirect to an article when the title is too ambiguous to identify an article but nevertheless has a clear primarytopic, like with New York (city). Dicklyon (talk) 07:08, 5 May 2013 (UTC)

  New York (city) occurs outside of Misplaced Pages. Thriller (album) does not.. So the guidance could be clarified to allow such "real world" qualifiers. -- JHunterJ (talk) 12:11, 5 May 2013 (UTC)

"New York (city)" is not a counterexample; it would not be affected by this proposed guideline. New York (city) redirects to New York City, therefore the redirect contributes no additional ambiguity. Anyone looking for a city other than the American city who types "New York (city)" into the search bar will rightly be provided with the New York City (disambiguation) hatnote at the top of the article, and would have been presented with this hatnote even if "New York (city)" did not redirect to New York City. This argument assumes that New York City (disambiguation) lists the other cities called "New York", which, unfortunately, it currently does not. Affected articles would be ones such as Lost (TV series) and Kiss (band). Neelix (talk) 13:10, 5 May 2013 (UTC)

• Support proposal (although maybe tweak the wording slightly to make it more explicit). We have situations for example where Angel (TV series) is the article name for the 1999 TV series, yet other TV series called "Angel" also have articles, so this disambiguator could equally apply to these. The whole point of a disambiguator is to be unambiguous, yet this is not reflected in practice. See also Thriller (album). WP:PRIMARYTOPIC should apply to the undisambiguated title only, not to partially disambiguated titles. --Rob Sinden (talk) 07:50, 5 May 2013 (UTC)
• Oppose (or possibly "Partial oppose", the proposal isn't entirely clear on this point): The actual article should probably be at a fully-disambiguated title. But I see nothing wrong with the partially-disambiguated title redirecting to the WP:PRIMARYTOPIC for that partially-disambiguated title, if one exists, rather than the "main" disambiguation page. Or, for that matter, with the partially-disambiguated title being a dab page in its own right, referenced from or transcluded into the "main" dab page, if there are a large number of disambiguations for that partially-disambiguated title. Anomie⚔ 13:24, 5 May 2013 (UTC)

  WP:PRIMARYTOPIC does not address partially disambiguated titles at all. If there's a primary topic, it goes at the base name (or the base name redirects to it). If it's not at the base name (or the target of the base name redirect), it's not the primary topic. Misplaced Pages:Incomplete disambiguation also deals with making partially disambiguated titles dab pages (that is, we don't, we make them redirects to the disambiguation page). -- JHunterJ (talk) 17:07, 5 May 2013 (UTC)

  The same logic applies. Anomie⚔ 21:00, 6 May 2013 (UTC)

  The same logic does not necessarily apply. -- JHunterJ (talk) 11:16, 8 May 2013 (UTC)

• Oppose - there is no need for a guideline on this. If a given article needs disambiguation (or further disambiguation), it is perfectly reasonable to propose moving it to an appropriately disambiguated title. However, once you set "rules" to deal with situations where a complexly disambiguated title is needed, you end up with those "rules" being enforced in silly situations where a complexly disambiguated title is NOT needed.... simply because the "rules" says so. (Or, you end up with "rules" that get so bloated with "exceptions" that they become meaningless.) Uniformity is not always a good thing, and disambiguation is one of those areas where uniformity can actually be more harmful than helpful. Blueboar (talk) 17:44, 5 May 2013 (UTC)

In what case would a partially disambiguated title be benefitial? Neelix (talk) 15:23, 6 May 2013 (UTC)

• Partially oppose. Kiss (band) is an excellent example of a term for which people would not expect the band name to reside at the undisambiguated title, Kiss, but for which people would expect the title disambiguated only with the word "band" to go to this one particular band. Kiss (band) is also an example where there is only one other band by that name in the encyclopedia, allowing the other possibility to be addressed in a hatnote. I would suggest that a rule like the proposed rule should only be implemented where there is more than one reasonable challenge to any one term being primary for the disambiguated name. bd2412 T 20:05, 5 May 2013 (UTC)

  I think experienced Wikipedians might expect the band topic to reside at Kiss (band), but that most visitors to the topic article might have no expectation of where the article would reside if not at Kiss or KISS. Many readers are not aware of (and do not care about) our selection of qualifiers. Even for those expectations, I do not see the drawback to fuller disambiguation, as with it the experienced Wikipedians' expectations would adapt to the new policies. -- JHunterJ (talk) 11:04, 6 May 2013 (UTC)

I agree; it is only Wikipedians who expect particular disambiguators, not the readers for whom we are writing Misplaced Pages. Setting a particular number of alternate meanings before full disambiguation is required seems arbitrary. Neelix (talk) 15:26, 6 May 2013 (UTC)

I think you're both underestimating our readers. The disambiguators we use seem to me to be very easy for a reader to pick up on for anyone who looks things up on Misplaced Pages with reasonable frequency. Anomie⚔ 21:00, 6 May 2013 (UTC)

I don't think there's any underestimation. I think using more precise qualifiers where needed will be no less each for a reader to pick up, and the reader landing at the appropriate section of a dab page will understand what happened. -- JHunterJ (talk) 20:55, 7 May 2013 (UTC)

• Support - at the moment only one project - which has two conflicting guidelines, one agreeing with WP:PRIMARYTOPIC and one opposing WP:PRIMARYTOPIC (WP:MOSALBUM, edited to conflict with "one" primary topic 18 months ago, only recently felt). Since there's no evidence yet that any other project has adopted such a guideline, and since projects such as WP:FILM and WP:FOOTBALL specifically confirm WP:PRIMARYTOPIC, the simplest solution is to undo the "PRIMARY ALBUM" edit from 18 months back as lacking any consensus discussion (even in the project as far as Talk page indicates?). As far as I can tell there's only 1 article affected anyway, even in WP:ALBUMS cannot find any example except Thriller (album) which does this. It appears to be the only single article on the whole of en.wp deliberately promoting "PRIMARY ALBUM" or any similar guideline. Until today I would have assumed Lost (TV series) and Kiss (band) are just accidents. In ictu oculi (talk) 04:55, 7 May 2013 (UTC)

Interesting, after Thriller (album), Lost (TV series), Angel (TV series) and Kiss (band) is there a 5th article which does this? In ictu oculi (talk) 05:05, 7 May 2013 (UTC)

Just looking at bands, there is also Poison (band) and Poison (German band); Bush (band) and Bush (Canadian band); Genesis (band) and Genesis (Colombian rock band); Oasis (band) and Oasis (1970s group) and Oasis (1980s group); Nirvana (band) and Nirvana (British band); Anthrax (band) and Anthrax (UK band); The Eagles (which redirects to Eagles (band)) and The Eagles (UK band); Rainbow (band) and Rainbow (South Korean band); Exodus (band) and Exodus (Polish band). There's likely more, but that's all I had time for. older ≠ wiser 15:53, 7 May 2013 (UTC)

A few more examples I've found, there are undoubtedly more.

• For films, there are Metropolis (film) and Metropolis (anime), a 2001 animated film; Tommy (film) and Tommy (1931 film); Cabaret (film) and Cabaret (1927 film); Contact (film), Contact (short film), and Contact (animated short film).
• For albums, there is A Hard Day's Night (album) and A Hard Day's Night (Sugarcult album); Tommy (album) and Tommy (Dosh album); Demons and Wizards (album) and Demons and Wizards (Demons and Wizards album).
• Songs are a little trickier, in that there may often be an article about one song with "(song)" in the title, while the corresponding disambiguation page may list other songs that might not have stand-alone articles (some of which may be a redirect to an album). A few examples: Born to Run (song) and at least three songs listed at Born to Run (disambiguation), one of which Born to Run (k-os song) is a redirect; Stormy Weather (song) and at least four other songs at Stormy Weather (disambiguation), one of which Stormy Weather (Echo & the Bunnymen song) is a stand-alone article; Helter Skelter (song) and at least five other songs at Helter Skelter (disambiguation); Stardust (song) and at least three other songs at Stardust (disambiguation) including Stardust (Lena Meyer-Landrut song); Imagine (song) and Imagine (Tone Damli song) and two other songs at Imagine (disambiguation); Jolene (song) and at least five other songs at Jolene (disambiguation); Fragile (song) and Fragile (Kerli single); Boys Don't Cry (song) and Boys Don't Cry (Moulin Rouge song), Boys Don't Cry (Plumb song) and two others at Boys Don't Cry (disambiguation).

older ≠ wiser 17:54, 7 May 2013 (UTC)

Thanks. At first sight there are some of these where ambiguous disambiguation could be a problem, and a few where a clearly derivative and borderline notable (non-encyclopedic) article shouldn't be given much weight: "A Hard Day's Night is a Japan-only EP from the Californian pop-punk group Sugarcult featuring a cover of The Beatles classic." generally redlinks and redirects don't count unless its clear that there could/should be a notable article, or if its included as a chunk in a main article. In ictu oculi (talk) 23:38, 7 May 2013 (UTC)

NB after that comment I moved to A Hard Day's Night (Sugarcult EP), doesn't affect the point however. In ictu oculi (talk) 23:56, 7 May 2013 (UTC)

Just came across another eyebrow-raiser. There is Rainmaker (song), which I'll grant is a pretty good song, but Rainmaker (disambiguation) lists no less than ten other songs with that title. Is it really that much better known than Traffic or the Harry Nilsson songs. I have at least added a hatnote at the Iron Maiden song article which had been missing. older ≠ wiser 12:57, 8 May 2013 (UTC)

• Partially support – if we can clarify that it means we don't like things like New York (city) as article titles but they're OK sometimes as redirects, that I'm OK with it. That is, if we're going to use a parenthetical disambiguator, we should not leave partial ambiguity; if we're going to have potential primary topic arguments over partially disambiguated titles, and we will, then let's have those arguments only affect redirects. For articles, less ambiguity is better. And yes, the unique contrary suggestion at PRIMARY ALBUM should be repealed, and Thriller (album) moved to Thriller (Michael Jackson album). Thanks for pointing those out. The fact that the RM at Talk:Thriller (album) was a "not moved" close is clear evidence that fanboys will continue to argue for keeping ambiguous titles on their favorites (which we're accustomed to on undisambiguated titles; but on partially disambiguated is news to me, and quite silly); this guideline will help move such outliers into line with sense. Dicklyon (talk) 05:29, 7 May 2013 (UTC)

Your amendment makes sense to me. Neelix (talk) 14:42, 7 May 2013 (UTC)

• Concern: I am concerned that this will lead to multiple articles about the same song... Song title (band X), Song title (band Y), and Songtilte (band Z). I understand the need for good diambiuation if all three bands have recorded a different song with the same title... but I am talking about multiple bands performing the same song. We have hand numerous RfCs on this issue, and the consensus has repeatedly been against having multiple (by performer) articles. Instead we should have one single article on the song (which either contains a List of bands that have recorded "Song"... or points to a "list of bands" sub article.) Blueboar (talk) 17:03, 7 May 2013 (UTC)

I agree that there's an important issue here: we don't want separate articles on covers of song. What's less clear to me is why you think this proposal would open up that problem. If Song title (song) is already unambiguous, we're done; if it's only partially disambiguated, because there are two different songs by the same title (not different performances of the same song), then we need further disambiguation. It would probably be conventional to use the songwriter's or originating band's name for that, no? Consider Mother (song), Mother (Danzig song), Mother (John Lennon song). Dicklyon (talk) 17:18, 7 May 2013 (UTC)

WP Song already has a rule prohibiting covers from having separate entries. At least that's what I was told when it came up before, but I can't remember the link. In ictu oculi (talk) 23:33, 7 May 2013 (UTC)

• Support. I once thought Psycho (film) was okay, but after further experience with these partially-disambiguated names, I'm convinced that (though they are helpful) they're not helpful enough to the reader to be worth the added complexity, confusion, and primary-topic discussions that will ensue. It's bad enough trying to decide if a topic is the primary topic for a particular title; adding to that trying to decide if topics are the primary topic for a particular title plus disambiguator is just too much. Powers 02:40, 12 May 2013 (UTC)

Are we anywhere towards a consensus with this yet? --Rob Sinden (talk) 11:58, 15 May 2013 (UTC)

As far as I can tell, three users (Anomie, Blueboar, and BD2412) oppose the proposal because they perceive non-editor users as likely to expect particular articles to be located at partially disambiguated titles, and because full disambiguation adds a measure of complexity which they perceive as unnecessary. Seven users (JHunterJ, Bkonrad, Robsinden, In ictu oculi, Dicklyon, LtPowers, and I) all appear to support the proposal provided that the redirect clause Dicklyon refers to is stipulated, believing that partially disambiguated titles do not serve their purpose, and that discussions over what constitutes the primary topic for a partially disambiguated title are detrimental to the project. Please correct me if I have misinterpreted anyone's position on the issue. Neelix (talk) 14:20, 15 May 2013 (UTC)

If I understand Dicklyon's statement correctly, that e.g. Thriller (album) could redirect to Thriller (Michael Jackson album) should that be deemed the primary topic for "Thriller (album)", rather than being forced to redirect to Thriller (disambiguation) as in the original proposal, that's also basically what I said. I just phrased it as "oppose because X should be allowed" rather than "support if changed so X is allowed". OTOH, I may have misunderstood Dicklyon's statement. Anomie⚔ 17:23, 15 May 2013 (UTC)

Should the orange bar gadget be on by default?

The orange bar talk notification, OBOD, was turned off by the devs when Echo was launched. A consensus seemed to have developed at WT:Notifications that it should be turned back on because newbies and IPs would otherwise miss warnings. A gadget mimicking this functionality was created with default on. Another user has turned off the default on on the grounds there is not wide enough consensus. Please comment at WT:Notifications#Pseudo OBOD Gadget is live. SpinningSpark 19:33, 4 May 2013 (UTC)

• The script (almost entirely based on User:Writ Keeper's work, except for a bit in the usermessage about Notifications and a link to the doc page) can be reviewed at MediaWiki:Gadget-OBoD.js. Ignatzmice•talk 19:46, 4 May 2013 (UTC)
• I disabled the default, and expanded my reasons for doing so in that the code has not been reviewed, and I want to avoid the site experiencing any trouble by running untested code by default. — Edokter (talk) — 19:50, 4 May 2013 (UTC)
  • And how long would it take you to review the code versus turning it off? Surely with your level of talent it wouldn't take long! Killiondude (talk) 20:30, 4 May 2013 (UTC)
• For the record, while I don't think there are any bugs in my code, and I do perform substantial testing of my scripts on my own before I publish them, I think the deployment of my script was over-hasty, especially since I haven't heard back from one user who has reported problems (though I'm reasonably sure I fixed them); I had not been asked for a final go-ahead. My last communication that I recall about this was with MBisanz on IRC some time ago (around 6 AM this morning UTC, I believe), where I said that the code might be ready for such a deployment, but that I wanted to hear back from Nyttend first, and that I would like to have seen an explicit consensus to adopt the script first. I'm not sure whether I support or oppose on-by-default in any case. Writ Keeper ⚇♔ 22:19, 4 May 2013 (UTC)

This appears to be OTBE'd, since a much more noticeable, bright-red warning now appears when you have messages. WhatamIdoing (talk) 02:17, 7 May 2013 (UTC)

Which photos to use for biography headers?

The apparently accepted policy on Misplaced Pages of posting the most recent photo of any living person at the top of the page -- often followed by other recent photos farther down the page -- seems totally contradictory to the purpose of a quick biography to give the highlights and most important facets of a person's life and/or career. For example, for a world class and internationally known musician from the rock era in the 1960s, whose career peaked during that period, it would make little sense to post a picture at the top of the page of that musician at his/her current age of 73. This is particularly egregious if the person has had little known popularity in recent years. While this faulty policy is most apparent when applied to entertainers and actors, whose outwards personas are/were an inherent part of their careers, it really makes little sense for any person. for example, if a scientist is mostly known for a major contribution made in 1957, it would make little sense to post a current picture of the person in 2013 at the top of the page. on the other hand, if an older person is most known for his/her recent work, and the career peaked in later life, it might make more sense.

If one of the aims of a biography is to inform people who may know little about the personality, it seems the persona of the personality when he/she was at the height of his/her career would dictate the most relevant image be posted at the top of the page. Some bios don not even have images of the people when they were at their most prolific or successful, or when they were most known to the public. — Preceding unsigned comment added by 208.120.171.79 (talk) 15:41, 5 May 2013 (UTC)

Makes sense to me. What policy/guideline page covers this? Blueboar (talk) 15:47, 5 May 2013 (UTC)

Misplaced Pages:Manual of Style/Images#Choosing images, but where's this supposed policy that says to show a picture of an old man when the person was a famous only when quite young? I've seen a couple of discussions on this point, and the always conclude that it's best to post a picture that shows the person during the actual period of notability. That means that a person who is notable as an athlete from age 19 to 24 should lead with a picture of the person in his (or her) early 20s. Now, musicians generally have much longer careers than athletes, as do most politicians, academics, and business people, so if you're talking about a person still very active in the field, then it would be appropriate to lead with a current picture. One wouldn't want to say, "Oprah started her talk show back in the 1980s, so let's lead with a picture from 1980s, as if she hadn't done anything interesting or important since that first show". In that instance, you're best off showing a reasonably current picture in the lead, and adding others to illustrate the appropriate stages of her career. WhatamIdoing (talk) 00:09, 6 May 2013 (UTC)

The issue here is that our non-free content policy and the Foundation resolution on non-free media and free-content goal that specifically call out that we should never use non-free images of living persons since a free image is always, presumably, possible. So if they were famous in, say, the 1950s but still alive today, we are required to use free media which is more likely than not going to be the older person. We do accept the reasoning for a non-free image of a person if their visual appearance was a key factor in their career , so for a movie star, sports person, or the like, where this was a noted facet of their life, we do accept non-free but this is almost always part of their history and not the infobox picture. (Example Weird Al Yankovic's earlier look is included on his article because his former look was of note in the article. But for a scientist or a politican, this is less likely going to be the case, and so we are required to stick to whatever free images we can.

Of course, that said, if we have free images of both the earlier part of their career and of a more recent one, the image that is most representative of their career should be the infobox one. --MASEM (t) 00:32, 6 May 2013 (UTC)

I'm the one who initiated the topic here -- "if we have free images of both the earlier part of their career and of a more recent one, the image that is most representative of their career should be the infobox one". Glad both of you basically agree with me. It is certainly possible that in some cases there are not images to choose from available for free during the apex of a person's career. However, usually this is not the case. Let's take a specific example: how about Bob Dylan? while it is true that Dylan's career has continued all the way to the present, Dylan's mark on history is his iconic contribution to the folk-rock era of the 60s and 70s -- an era that also spans major socio-political and historical events in the US and the world. the Wiki article opens with a photo of a much older man from 2010. Why? Why not use one of the photos below from 1963 or 1975, that show the more iconic image of Dylan? This is not even one of the most egregious examples, because Dylan himself has not changed his look all that much -- has only gotten older. We can try this with almost any famous musician: check out Neil Young and David Bowie. it's really ridiculous, in my opinion.

To answer the question about "policy", no, i don't think it is part of Wiki's policy. My own feeling is that it is something done by people who are not all that familiar with the people in the bios, but who like editing bios. And this has become an apparent standard, unfortunately. I guess my feeling is that if there were a kid in school wanting to know how a celebrated person looked during the major part of that person's career, the student would open up Wiki and see a much older person. The people i mentioned above are all people who became famous for their contributions during eras in which youthful energy was very important in the music business. They all continue to make contributions, and recent photos should be shown as well -- but it just seems silly to highlight recent photos. We're going to end up with a Misplaced Pages full of pictures of old people at the top of the page -- the latest photos before they died -- except for people who lived during the age of easy photography. How absurd. — Preceding unsigned comment added by 168.244.11.3 (talk) 17:48, 11 May 2013 (UTC)

I see your point and think I agree in general with what you're saying, but I'm not so sure about your examples. Dylan, Young, and Bowie continue to have vibrant careers and are highly notable for what they're up to today. Years from now, it may be possible to look back and identify the stage of a performer's career that was unquestionably the apex, but I rather think we should avoid making such judgments while someone is still very much alive, working, and relevant. Otherwise, we risk conveying a subtle message that so-and-so is "past it" (beyond the apex being another way of saying over the hill). Also, what about famous people who have had two or more highly noteworthy periods in their careers, with intervals of inactivity in between? We'd wind up arguing about which period was the more important one to depict. It also occurs to me that a biographical article should be about the whole person—the relatively minor things that make them notable as well as the moments of greatest notability—and the person today is, in a sense, the sum of that whole person. Does that make sense or have I begun to ramble? Rivertorch (talk) 20:49, 11 May 2013 (UTC)

Rules for Fools

Misplaced Pages:Rules for Fools is a failed proposal, but it has been marked with a banner template as having community consensus. Since my removal of this has been reverted, I have started an RfC at Misplaced Pages talk:Rules for Fools#Failed proposal. SpinningSpark 14:51, 8 May 2013 (UTC)

I think your RFC question has serious flaws, and I think you should re-write it promptly. I've left detailed comments at the RFC. WhatamIdoing (talk) 21:41, 8 May 2013 (UTC)

Should I Accept this Revision (Pending Changes)

As you can see, the user has provided a reasonable edit summary as to why they removed the section. However, the section is cited and could therefore be considered notable. Wanted to get a second. opinion before I either reject or approve the edit. Oddbodz (talk) 16:09, 8 May 2013 (UTC)

Ignore that - it has been resolved Oddbodz (talk) 16:19, 8 May 2013 (UTC)

This encyclopedia's scope

I believe that WP:UNDUE is an often misapplied policy. However, this is because I assume a certain vision of this encyclopedia, the English Misplaced Pages, which I believe is the right vision and one which many people share. However, I realize now that maybe most people don't share this vision. Before I keep going on about the application of WP:UNDUE, I want to be clear where the community stands on this vision.

I envision this encyclopedia not to be limited in its depth of coverage of a topic qua depth. I want to know whether people agree with this or not. What does this vision mean? This means that details of a topic are not to be excluded just because these details are too fine. This doesn't mean that details of a topic are not to be excluded when they don't have sufficient coverage in reliable sources, or when they are largely disputed by reliable sources. So, consider some details which are universally agreed upon in multiple high-quality reliable sources: these may be included in this encyclopedia, I envision.

I want to make examples, but I also don't want to speak falsely about a topic: My training is in philosophy, and I realise this doesn't have a wide-appeal, so such an example may just be confusing rather than enlightening, but I'll try one anyway. So we have an article on Plato. In the article we go into Plato's metaphysics. We could go in depth into his metaphysics, such that the article would be so long, it would require a sub-page, and we (kind of) have one at Platonic realism. But at such a sub-page we could go even more in depth into just the metaphysics of Plato's Republic, and we would require a sub-page for that. And then there we could even go in depth to single arguments that occur in the Republic, such that we would require a sub-page for just one argument. Such a page could be fully sourced to multiple,, high-quality reliable sources (i.e., the works of tenured professors of philosophy at accredited institutions published in academic presses and peer-reviewed journals).

Let me try a more general example, but just take this with a grain of salt, because I don't actually know if this topic could be covered to such a detail with multiple, high-quality reliable sources: We have an article on Minnesota. There we go into such depth of that state's economy, that we require an article, Economy of Minnesota. There too I think we could go into such depth into mining in Minnesota, that we could require a sub-page on Mining in Minnesota. There we could into such depth into the environmental impact of mining in Minnesota that we could require on subpage on the Environmental impacts of mining in Minnesota. Then to the environmental impact on Lake Superior of mining in Minnesota. Then on the impact of mining in Minnesota of Lake Superior's lake trout populations. I don't doubt that all of this could be referenced to multiple, high-quality reliable sources.

The question is: Are such things beyond the scope of this encyclopedia? I don't think so. It certainly would be educational, and it would certainly be verifiable, and it certainly would be notable. It does a lot of good to include such details, and it does no harm. However, I realize that there are some people that think that this encyclopedia should not contain such a level of detail. These people could cite WP:NOTEVERYTHING, which says "An encyclopedia article should not be a complete exposition of all possible details. Rather, an article is a summary of accepted knowledge regarding its subject."

I think that statement is fine, if understood in the right way: An article should be summary of its topic, that itself is true. But that is not to say that the encyclopedia as a whole should be limited to being just a summary, which it shouldn't. An implication of this is, however (because the encyclopedia is built out of articles), that there must be a prima facie allowance for such details in some article (if not in the main article for a topic). That is: Sub-pages which then deal with finer details may be made. If no such sub-page has been made yet, such finer details shouldn't simply be excluded from the encyclopedia altogether, but, when they have received sufficient length, they should be rolled into a sub-page. This is all assuming accurate references to high-quality, reliable sources, of course.

More than anything I just want to see where people stand on this issue. That's my primary concern. However, as matter of secondary concern, if people do agree with me that this encyclopedia should not be limited in this way, I propose amending WP:NOTEVERYTHING to include something like "That an article should be summary of a topic should not by itself exclude including more in-depth coverage in sub-articles devoted to sub-topics of that topic. If a sub-topic does not have the depth of coverage to warrant its own article, then the sub-topic should still be included in the main article." I welcome suggestions for the wording of this or any other alternatives. --Atethnekos (Discussion, Contributions) 19:43, 8 May 2013 (UTC)

UNDUE applies to individual pages, not to the whole encyclopedia. It's perfectly fine to have an entire article on the Impact of mining in Minnesota of Lake Superior's lake trout populations. But you must not disturb the BALANCE of Environmental impacts of mining in Minnesota by filling it with thousands of words about Lake Superior's fish. If you reach a point at which the lake trout are taking over the general article, you must remove information from the general article and WP:PRESERVE it at the far more specific article. WhatamIdoing (talk) 21:46, 8 May 2013 (UTC)

If such guidance is needed, it probably makes more sense to make reference to the guidelines on forking and summary. Alanscottwalker (talk) 22:12, 8 May 2013 (UTC)

Notability also comes into play here. If only one or two sources have gone into great depths on a subject, a separate article make not be appropriate for that sub-topic. You can always link as references or external links in the main topic to these detailed papers if they are appropriate. --MASEM (t) 01:57, 9 May 2013 (UTC)

There is no simple answer... essentially the question is whether specific bit of detailed information X is appropriate for specific article Y. Because the question is based on specifics, you can't make a one-size-fits-all generalized "rule" about it... each time we ask the question, the answer will be different. Going into detail might well be appropriate in one article, and not appropriate at all in another. And within one article, it might be appropriate to go into detail about sub-topic A, yet totally inappropriate to go into detail about sub-topic B. Blueboar (talk) 12:55, 9 May 2013 (UTC)

To rephrase the question of the vision, which is not specific but is general: Should some details be excluded from this encyclopedia just because they are too fine? If you answer yes, then you disagree with the vision. --Atethnekos (Discussion, Contributions) 13:51, 9 May 2013 (UTC)

No. The detail may be too specific for a particular article, but the encylopedia as a whole has no such limitations. AIUI, WP:NOTPAPER addresses this point. Roger (Dodger67) (talk) 14:02, 9 May 2013 (UTC)

It's not so clear cut... this isn't a black and white Yes/No answer... A lot depends on what the specific detail actually is. Some details may not be notable enough for a stand alone article, and may be considered too trivial to discussed in the context of any other article. Blueboar (talk) 13:04, 11 May 2013 (UTC)

If a detail is discussed in multiple high-quality reliable sources (the assumption being made), is it still not notable and too trivial? --Atethnekos (Discussion, Contributions) 16:04, 11 May 2013 (UTC)

It can also be too tangential to a current article, which are scope and balance issues open to editorial discussion. Alanscottwalker (talk) 23:58, 11 May 2013 (UTC)

I think a question of quality rears its ugly head early on. We can't answer these questions before they arise. An editor has to be on hand to create an article on a relatively obscure subject. If other editors can look at the rough draft and say "yes, I get it", "yes, I'm beginning to understand"—then the green light can be given for the article to take its place among articles. But if no one else "gets" it, it is doomed to failure. Even if some can see that it is a good idea, it won't get off the ground without initiative. Someone has to make it take form. Articles don't write themselves. (Not yet, anyway.) So the question is more one of initiative and hard work rather than Misplaced Pages's limited scope. I haven't addressed how much depth one should go into in individual articles. The article should be readable as an article. Too much depth in one area might upset the overall balance. On the other hand a reader need not read an entire article. Bus stop (talk) 01:26, 12 May 2013 (UTC)

Bus stop: I think that's true.

Alanscottwalker: I think that's the editorial discussion I'm trying to start. Another way I describe my vision: If tenured professors of the relevant discipline at accredited institutions are writing in peer-reviewed publications on a certain detail, then I think that detail is worthy of discussion, since these eminently reliable sources find it worthy of discussion. I don't see a reason to trust the judgement of each editor here over the judgement of these scholars as to what is worthy of discussion. Absolutely, you're right that such a detail is going to be too tangential for most articles, but I don't think it is too tangential or too specific such that it should not be mentioned in this encyclopedia. Here's the (albeit small) harm of excluding it: Whereas otherwise readers would be informed of this (albeit small) detail, they now are deprived of this information. And I don't see any harm of including it in theory, and in practice there are footnotes and appendices which may contain the detail such that inclusion will not disrupt articles stylistically or in terms of readability. --Atethnekos (Discussion, Contributions) 03:11, 12 May 2013 (UTC)

You are aware, Atethnekos, that a tenured professors job is, in very large part, to write publications in peer-reviewed journals? And that, in many cases, those journals are accepting information of extraordinarily narrow scope, scope that may, in fact, be of interest to only a few hundred people in the world? And that they may accept claims which are not in broad agreement, even though there aren't necessarily specific other papers that refute it? Take, for instance, intelligent design. There are peer-reviewed journals for it (in the sense that people with PhDs are blindly reviewing submissions from other people with PhDs). And there are often papers published there that are never refuted in mainstream scientific journals, because they deal with theories that are simply irrelevant to actual scientific work. Would it then be appropriate for us to find a place for such a detail somewhere in the encyclopedia, despite the fact that, if asked, 99% of other tenured professors in the field would reject it as non-scientific?

Furthermore, how fine a level of detail do you propose? Should we, for example, reproduce (w/o violating copyright) detailed discussions of the methodology and background for every research study we talk about (which, presumably, based on your thinking, should be every one we can get)?

And let me bring in a non-academic point: I'm sure that, if I looked hard enough, I could find reliable sources that stated what Jeniffer Aniston wore to several thousand public events, and probably a great many nominally private ones. Would it be appropriate to include that info in Misplaced Pages somewhere?

If people want access to all possible information, there's a great resource: the Internet (and the journals themselves, and libraries, and...). Misplaced Pages's value, like that of any encyclopedia or other knowledge aggregator, is that we distill down the essence of subjects in a way that a general reader can gain at least a surface level understanding of them. What you propose is to essentially (in my opinion) remove the very thing that makes us useful. Qwyrxian (talk) 14:55, 12 May 2013 (UTC)

If multiple-high-quality sources discuss a subject, then the remaining barriers are WP:NOT (is it encyclopedic? Some actress's wardrobe probably isn't) and editorial judgment (a separate article, or part of a larger one?). If all three of those considerations agree that the subject is worth an article, then it is notable and qualifies for its own article. This is true even if the subject is non-scientific or primarily interesting to a minority viewpoint. WhatamIdoing (talk) 15:33, 12 May 2013 (UTC)

Answer to question 1: Yes. Q2: Yes. Q3. Yes. Q4: I personally don't know much about intelligent design. I also don't know much about what distinguishes what's non-scientific from what's not non-scientific (the scientific), so your question is a bit mysterious to me. I would guess that such sources would not be reliable sources for most claims for which a certain group of misguided editors would use them as sources. So just on that ground they would not be so useable. Our Intelligent design article says "The intelligent design movement has not published a properly peer-reviewed article supporting ID in a scientific journal, and has failed to publish supporting peer-reviewed research or data. The only article published in a peer-reviewed scientific journal that made a case for intelligent design was quickly withdrawn by the publisher for having circumvented the journal's peer-review standards". If however they somehow are reliable sources for the claims for which they are being used, then I don't see why including such a claim somewhere in the encyclopedia would be problematic just because it is too specific for this encyclopedia. For example, if one of these so-called "peer-reviewed" intelligent design journals featured a piece which stated in the authorial voice of the article that the author herself knew that her views were not widely accepted, then that source seems like it would be strong enough to back a claim that at one point at least the author believed her views were not widely accepted.

Q5: I'm not sure if I propose any level of detail. I propose that no level of detail is too fine for this encyclopedia qua level of detail. Q6. I don't think we should do that. I believe that we shouldn't remove entirely such discussion if it is sourced to reliable sources. Q7. I'm not sure if it would be appropriate to include that information. I think it would be inappropriate to remove entirely such information, if what you say is true.

Re: removing usefulness: I don't see how it removes that thing. The distilling down would still occur and would be unaffected. What would be added are more articles and entries in sub-categories. For example, were it the case that an article such as "The effects of Minnesota mining on Lake Superior lake trout populations" exists would not affect the ability of a general reader to gain a surface level understanding of Minnesota, because the article "Minnesota" would still contain the distilling down to which you refer. Similarly, I don't believe that were it the case that an article such as "Outfits worn by Jennifer Aniston" exists would affect the general ability of a such a reader to gain such an understanding of Jennifer Aniston, for the same reason just given, mutatis mutandis. --Atethnekos (Discussion, Contributions) 19:11, 12 May 2013 (UTC)

Merging of material from articles at AfD

Sometimes when I see an article at AfD (only nominated for notability issues) I think I'd like to merge some of the contents to a "parent" article. If I went ahead I would use {{copied}} on source and destination talk pages. This template commands that the history of the source is not to be deleted so long as the destination article exists. So, I do not want to do this during the AfD discussion because it would put a spanner in the works of deleting the article. However, if I wait and the article is deleted it is too late. What is the best thing to do? Thincat (talk) 08:23, 9 May 2013 (UTC)

You propose the merge in the AFD discussion as an alternative to deletion. Roger (Dodger67) (talk) 14:06, 9 May 2013 (UTC)

Thank you. What I should have asked is, is it acceptable, in the course of an AfD on an article, to copy some material to another article? Or, is it better to wait to the end of the AfD and, if it results in delete, ask the closer to provide the material? I see this recently. Was it the appropriate procedure? Presumably the material would then have to be re-written afresh to avoid misattribution. Thincat (talk) 16:47, 9 May 2013 (UTC)

Roger Dodger is right. Although no rule on WP (that I know of) specifically forbids such an action, merging an article in the middle of an AFD at best makes the discussion harder to fathom, and far more seriously it's very easy in such a situation to screw up attribution and thus violate GFDL copyright. It's far better, as Roger Dodger correctly suggests, to propose the merge and gather consensus for it. Also, and I know this is obvious but it still needs to be said, genuinely bad material (copyvio, non-notable, unsourced, spammy, etc) should not be merged or copied anywhere. Andrew Lenahan - Starblind 21:06, 10 May 2013 (UTC)

OK. I'll try things this way and see how it works out. Thincat (talk) 11:37, 11 May 2013 (UTC)

WP:Guide to deletion#You may edit the article during the discussion #5 recommends against copying during a live AfD. It was revised December 2009 after WT:Articles for deletion/Archive 58#Merging during live AfD. Flatscan (talk) 04:33, 13 May 2013 (UTC)

Thank you. I shouldn't have missed that, but I did. Thincat (talk) 19:59, 13 May 2013 (UTC)

... and the discussion you pointed to was a good one. Thincat (talk) 20:14, 13 May 2013 (UTC)

WP:HISTRS

Some of us would like to upgrade WP:HISTRS from an essay to a guideline. Where do we go to apply for this? It would be really good if someone would work with us on it. A guideline would be particularly useful for resolving disputes that relate to nationalism, where there are competing versions of history. As WP:MEDRS is an invaluable tool for ensuring that we don't inadvertently promote quack cures. Thanks for any advice. Itsmejudith (talk) 14:18, 9 May 2013 (UTC)

You should probably start an RFC. Ruslik_Zero 18:24, 9 May 2013 (UTC)

You make another WP:PROPOSAL. WhatamIdoing (talk) 20:01, 9 May 2013 (UTC)

Thanks to both. I will go to the ideas incubation people and also to WP:HISTORY before the RfC. Itsmejudith (talk) 06:44, 10 May 2013 (UTC)

Gender-neutral language

Please go to Misplaced Pages talk:Gender-neutral language and read the section titled "Man overboard". User:Frungi thinks that man meaning person (of either gender) is gender-neutral language. Georgia guy (talk) 18:55, 10 May 2013 (UTC)

If the gender-neutral sense of the word (wikt:man#Noun sense 3) is clearly being used, yes. If the gender-specific meaning of “adult male” is meant, then obviously it wouldn’t be gender-neutral. —Frungi (talk) 20:17, 10 May 2013 (UTC)

"Man overboard" is a generic, gender-neutral phrase, used no matter who falls off the ship. Indeed if the ship had a mascot (say a dog) and it fell overboard, the lookout would probably cry... "Man overboard!" Blueboar (talk) 20:39, 10 May 2013 (UTC)

A question in MOS - WP:TIMEZONE

MOS states that: When writing a date, first consider where the event happened and use the time zone there.

However, in some cases, a historical event took place where the time zone in that particular location is different than what is today. That is, the time zone has changed since the event took place. MOS did not make note of this.

Example, 1920 Haiyuan earthquake stated that it hit at local time 20:06:53 (GMT 12:06:53), of which it is expressed modern China time zone, which is GMT +8. However, during Republic of China, China was divided into five time zones. The epicenter is at Haiyuan County, Ningxia Province which at that time is in Kansu-Szechuan Time Zone, which is in GMT +7.

Corresponding article in Chinese Misplaced Pages noted this fact and recorded in 19:06:53 (GMT+7).

Opinion on this? SYSS Mouse (talk) 03:16, 12 May 2013 (UTC)

Just note the difference in the text of the article. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 15:06, 13 May 2013 (UTC)

The use of official broadcast dates versus actual broadcast dates in articles

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Misplaced Pages style and naming When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Since early April, there has been a discussion at WikiProject Anime and manga about broadcast schedules. For convenience, I'll summarize the discussion below, or alternatively, please read the link above for the full discussion.

This page in a nutshell: A short background: In Japan, the broadcast date continues into the early morning of the following day, meaning that shows can be advertised to air at times like "May 11 at 25:30" would actually air on "May 12 at 1:30". Many, but not all, Japanese television channels use this broadcast schedule. Some non-Japanese TV stations or blocks which show anime, such as Adult Swim and Animax Hungary also follow or followed to some extent this practice. According to MOS:TIME, "25:30" is incorrect, thus, "1:30" should be used. However, it doesn't directly say that, if the date is "May 11 at 25:30", the date should be changed to May 12. However, for the stations that practice the past-midnight broadcast schedule format, the reliable sources used in articles also use it. For example, reliable sources would state that Show A premiered on Channel A on January 1, at "25:00". The arguments are as follows: Those who are in favor of using the actual broadcast date say that MOS:DATE must be followed, despite what reliable sources say, both for consistency, and also to avoid confusion for those who are unfamiliar with Japanese broadcast schedules. Those who are in favor of using the official broadcast date say that, even though the official broadcast date used is technically incorrect, this is still the date used by the TV station, and what is stated by reliable sources.

In the discussion, it was suggested that a centralized discussion to determine consensus should be started on this page, because the practice is not only limited to anime and Japan, and also because this could affect several articles and projects, not just WP:ANIME. As such, in this case, should the official broadcast date be followed, or should the actual broadcast date be used? Narutolovehinata5 10:10, 12 May 2013 (UTC)

Narutolovehinata5, you mischaracterize this as a "Japan-only" thing. Many television channels have programming schedules that go into late night/early morning broadcasts.—Ryulong (琉竜) 14:20, 12 May 2013 (UTC)

Which is why: 1. I said "because the practice is not only limited to anime and Japan", and 2. The discussion is here instead of being at WT:JAPAN. Narutolovehinata5 14:30, 12 May 2013 (UTC)

Important Comment - I have personal insight into this matter and I want to offer additional information and exceptions for this RFC. It is frequently common in Asian countries or Asian Publications including Chinese, Vietnamese and Korean publications to refer to dates as X 2 A.M and which would be X+1 to English speakers. An example of this is many Asian countries, a show (theatre, concerts) with a 2:00 AM start time on 5/12/2013 would occur to English speakers at 5/13/2013 2:00 A.M. This is related, at least among the Chinese, that the day begins with the rising of the sun. So in general, a localization of how time is interpreted and under what circumstances are not among just Japanese publications. In these materials the text literally translates to <month> <day> at night. Where English text, even right underneath it, will often say Day of the Week, Month Day a.m. Most English speakers do not understand this, and it is very confusing because both are correct depending on view, but when you convert out of context like Misplaced Pages does, the dates become incorrect. This issue extends to ALL media and not just anime works; this RFC is very important for that reason. ChrisGualtieri (talk) 15:20, 12 May 2013 (UTC)

• So, we're going to have a centralized RFC to hash out how to say what time some television shows were broadcast? Put me down for an extra-large helping of not giving a fuck. Beeblebrox (talk) 19:04, 12 May 2013 (UTC)

  No, it's to determine which date should be presented should something air after midnight: the broadcast date that appears in reliable sources or the actual calendar date, should they differ.—Ryulong (琉竜) 02:41, 13 May 2013 (UTC)

I'd like to DGAF, but RFCs have a nasty tendency to form long-term consensus. The major concern is imposing a Western concept of time against the native understanding of time; has not even been brought up by either editor. Either way, the two parties viewpoints have issues that show that MOS-TIME is probably not being used correctly for the specific niche of past-midnight airings which to the purist or casual English reader will be wrong in any setting. An example from the thread was Adult Swim's schedule which has date and times which deal with this. The programming starts at 9 p.m. and runs to 5:30 a.m. with shows airing after midnight still being under that day's events. So Friday's programming runs into Saturday by the clock, yet still aired on Friday for the schedule. A cultural difference has this matter solidified in many Asian countries, with any alteration or augmentation making it incorrect on one aspect and correct on another. Neither editor understands this, and neither editor has suggested addressing the actual underlying problem for post-midnight airings. Friday 25:30 is probably the most correct given proper context, with Friday 1:30 at night being confusing for Westerners and Saturday 1:30 being the most confusing for native/informed readers while correct with general Western standards. MOS-TIME is a policy, but it should not to be followed blindly or be invoked to perpetuate errors. WP:IAR should apply for right now until a proper RFC can deal with it. This may seem trivial, but either of the proposed changes would damage Misplaced Pages's credibility, and that's why it is a big deal. ChrisGualtieri (talk) 03:30, 13 May 2013 (UTC)

That's why I started this RfC, to decide what to do with the practice. Narutolovehinata5 05:58, 13 May 2013 (UTC)

It seems to me that the easiest way to deal with this is in the text of any affected article: simply state the advertised time, and what it really was per UTC and/or per standard timekeeping, and then go from there. This is not a hard concept. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 15:05, 13 May 2013 (UTC)

Comment - It would be appreciated if we could agree on some kind of standard for airing dates of these after midnight programs. There are cases, where the TV station advertises the airing time in one place in one form, but shows the airing time in another place in another frorm. I provide an example: Chihayafuru TV series; Nippon Television (the original broadcaster) advertises the airing time as (Fri.) 25:58, in Chihayafuru2 web page (here for episode 19), but shows the airing time of the episodes in standard form, (Sat.) 1:58, in its scheduling. What should we do here? Use the advertised time, or use the standard time in the scheduling? NTV has used both forms. What should be written in the infobox for air date of first episode? January 12, 2013 (1:58, the standard time and date listed in the schedule), or January 11, 2013 (25:58, the advertised time and date)? I personally am for using the standard (and correct) time and date in general, ignoring the non-standard advertised forms. Raamin (talk) 19:32, 14 May 2013 (UTC)

I like converted time as the norm instead of the tv schedule time, especially if the episode list I'm working on as Japanese and English dates; which would result in one have tv schedule time and the other as converted if they both air after midnight. DragonZero (Talk · Contribs) 21:37, 14 May 2013 (UTC)

Article name

Are we allowed to use any language version of settlements and towns as link with source, or just agreed article title per WP:AT? --WhiteWriter 21:53, 12 May 2013 (UTC)

Follow Misplaced Pages:AT#English-language titles. Blueboar (talk) 23:53, 12 May 2013 (UTC)

But what if common name is not english? Are we allowed to use several language variants? --WhiteWriter 00:46, 13 May 2013 (UTC)

The article's title should be in the Latin alphabet.—Ryulong (琉竜) 02:42, 13 May 2013 (UTC)

No, no, we are missing the point of my question. Can we use other languages linked name, instead agreed article title? --WhiteWriter 10:49, 13 May 2013 (UTC)

I am not sure what you mean by "other languages linked name" and "agreed article title"? Our policy is to prefer English language sources over non-English language sources of equal quality (this is the English language version of Misplaced Pages, after all). So... a) we first look at the English language sources to see if there is a standard (or "common") name for the place in English. If so, Misplaced Pages uses that as our article title. If not, b) we look at the appropriate non-English language sources to see there is a standard ("common") name for the place in those.

Does this answer your question? If not, perhaps you could give us an example of what you are asking about? Blueboar (talk) 11:46, 13 May 2013 (UTC)

To give you an example... consider the capital city of Italy. Looking at English language sources, we discover that the vast majority refer to the city as "Rome"... so we use that name as our article title (we can refer to "Rome" as being the "common English language name"). We don't use the Italian "Roma".

Now consider another Italian city ... "Livorno". The appropriate title for our article on this city is debated... Many (archaic) English language sources refer to it as "Leghorn"... A few English language sources refer to it as "Legorno" or "Ligorno"... but the majority of modern English language sources now refer to it using the Italian name, so... after a lot of discussion our article title settled on Livorno. We can say that "Livorno" is the most common English language name. Blueboar (talk) 13:52, 13 May 2013 (UTC)

Bravo, exactly that was my question! So, if we have Livorno as article tile, can we use ] instead in articles anyway, or not? --WhiteWriter 14:04, 13 May 2013 (UTC)

Why would you need to do that anyway?—Ryulong (琉竜) 14:29, 13 May 2013 (UTC)

(ec) Ah... Usage in the article text is trickier, and depends somewhat on context. For example, in an article that discusses Livorno in terms of its historic use as a British naval base, it might well be appropriate to use the archaic English name "Leghorn" (which is a redirect) and not the modern English name "Livorno" (although to help readers who might not know the archaic name, I would probably give both... writing: "For many years, the Mediterranean Fleet was based out of ] in Italy" ... at least the first time I referred to it).

I would be happy to give you more specific advice (relating to a specific article)... but suggest that we continue on my talk page rather than here. Blueboar (talk) 15:00, 13 May 2013 (UTC)

Should articles about plays list all awards or just the most prestigious awards

Last year WP:MUSICAL established a strict policy regarding limiting award lists for musical stage productions to only very prestigious awards. Although WP:FILM's policy is not expressly stated, if you look at any WP:FL regarding a movie you will see a fairly exhaustive list of awards that includes everything down to the film critic circle of any major city. Plays are somewhat related to both musicals and films, so it is not unreasonable to consider both policies. This is my first year of involvement in critically praised plays. I am in contentious discussion regarding whether all awards or just the most prestigious awards should be included in play articles. Please contribute your opinion on how WP:THEATRE should set its policy at Wikipedia_talk:WikiProject_Theatre#Award_enumeration.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 08:16, 15 May 2013 (UTC)

It doesn't read like a strict policy to me. Indeed the opening paragraph of the page is written rather nicely saying it hopes you will take the guideline into consideration. And that is how it ought to be. Thincat (talk) 14:36, 15 May 2013 (UTC)

Awards that have articles, meet GNG or N should not be removed. While it is preferential that most important ones should be noted first or over lesser ones, but not to exclude them. By doing so, it seems that THEATER is selectively attempting to deny recognizing an award that has already demonstrated notability. Anyone who removes properly sourced information for an award that claims it is non-notable should take a look at Misplaced Pages's inclusion criteria. Lucille Lortel Awards and other such awards while 'second-tier' are still valid and removing them is sort of like removing the Bronze Star Medal from the award list from military personnel in favor of 'higher awards' like Soldier's Medal. No one should remove all traces of an award simply because a higher one has been given. Even just listing the award itself and the year is suitable, but awards with Misplaced Pages articles or meet N should remain. I'm say WP:LOCALCONSENSUS can be interpreted as covering THEATER's preference issue as it directly conflicts with the purpose and coverage of Misplaced Pages. ChrisGualtieri (talk) 15:25, 15 May 2013 (UTC)

Misplaced Pages:WikiProject Musical Theatre didn't "set a strict policy", because a WP:WikiProject cannot write policies. They can't even write official guidelines. They can (and are encouraged to) write WP:Advice pages (notice that this fact is in an official, community-wide guideline), which are kept as a subpage of the WikiProject's namespace (so "Misplaced Pages:WikiProject Musical Theatre/Our best advice") and have exactly the same status as a plain old {{essay}}.

WikiProject Theatre is free to disagree with WikiProject Musical Theatre's advice, just like WP:BLUE is free to disagree with WP:NOTBLUE. WhatamIdoing (talk) 01:29, 16 May 2013 (UTC)

Blocked users - rescinding watchlist and notification access as part of the block

A quick question - is there any support within the community to rescind access to some or all notifications, and to the watchlist, for the duration of a block (as a selectable option along the lines of rescinding talk page access in the case of abuse) ? Do users who have been blocked feel that notifications and access to the watchlist is useful or was it a temptation to sock during a block ? There is some evidence to suggest that some users, whilst indefinitely blocked or banned are using the watchlist and/or notifications to watch various pages and continue editing using dynamic IP addresses, causing a headache for administrators and editors who have to deal with abuse and inappropriate editing behaviour. Any and all thoughts would be welcome. Nick (talk) 15:00, 15 May 2013 (UTC)

• There is a good case to be made that a watchlist cannot possibly be useful for a blocked user except as an enticement to evade that block. The information isn't lost, if/when the block is lifted one can always see what one missed; but I can't think of a good reason to keep it useable while you're blocked. — Coren  15:11, 15 May 2013 (UTC)

  I would say that's a bad assumption. I for one use my watchlist just to see anything new in various articles. A reading issue, not an editing one. If someone is blocked they can't edit, so if they were going to evade the block they'd have to consistently log in and out of different accounts...anyone that determined isn't going to be deterred. Though as an option to be added in case there's fear they ARE going to do that, I could get behind. ♫ Melodia Chaconne ♫ (talk) 16:39, 15 May 2013 (UTC)

• This could be helpful, as I have seen a case where this is probably happening. Writ Keeper ⚇♔ 15:24, 15 May 2013 (UTC)
• I certainly support disabling e-mail watchlist notifications during the duration of a block. E-mailing someone to say "here's an edit that you can't do anything about" doesn't seem like a good idea. As for the standard watchlist, I don't care much one way or another. If the editor is logging in to check his watchlist, he's triggering his autoblocks.—Kww(talk) 16:52, 15 May 2013 (UTC)
  • What does "triggering his autoblocks" mean? Autoblocks only prevent someone from editing not viewing their watchlist. Delicious carbuncle (talk) 17:31, 15 May 2013 (UTC)

• The act of logging in to view a watchlist prevents that same IP from immediately editing based on that watchlist, even if the editor logs back out or switches accounts. It's not a huge obstacle, but nothing about our blocking system is really a huge obstacle.—Kww(talk) 17:35, 15 May 2013 (UTC)

• I can't see how revoking watchlist access would do much good, it's easy enough to get around. Anomie⚔ 17:25, 15 May 2013 (UTC)
  • Well, so are the blocks themselves, but we don't let that stop us. Writ Keeper ⚇♔ 17:34, 15 May 2013 (UTC)

• At the very least, it makes sense to be revoked for indefinitely blocked/banned users, as they have absolutely no reason to be able to see their watchlist. And, indeed, I can certainly see how it would be abused by their socking accounts. Would blocking access to their watchlist also block their access to the list of articles they've watched? That would be best, as it would severely hamper their ability to reconstruct their watchlist under a socking account. 68.106.213.57 (talk) 17:58, 15 May 2013 (UTC)

• I think this would be counter-productive. Blocked users would get frustrated that they could not view their watchlist and would be more likely to set up an alternate account to view the pages they're interested in. Not all blocked users are willing to sock to evade their block, and this would be, essentially, punishing the ones who don't. 28bytes (talk) 18:46, 15 May 2013 (UTC)

• I agree; for most users being blocked for shorter periods, removing watchlist and notifications would be punitive and not really in the spirit of why we block users. I would only ever support blocking access to watchlists and notifications as an option that would need to specifically be set, and to be justified by the blocking administrator, in the way revoking talk page access is. I would envisage this sort of block option being used very sparingly and targeted at long term abuse, longer term blocked users (months and longer, I'd say) and those banned from the site. The default block would not alter in any way the watchlist or notification functionality as it is at present. Nick (talk) 19:38, 15 May 2013 (UTC)

• If a user lacks the self-control to sit out their block and resorts to socking that is their fault, not the fault of a notification. Also what 28bytes said. Beeblebrox (talk) 19:35, 15 May 2013 (UTC)
  • Well, it's not about self-control; the specific scenario involved a blocked user who was probably using his watchlist to see if and when another user's talk page came off semiprotection in order to harass them on their talk page more. Also, I'm pretty sure the proposal is for this to be a blocking option like removing talk page access, not part of any old block. All the same, though, the potential for abuse on our end and evasion on theirs is a good point well made. Writ Keeper ⚇♔ 19:40, 15 May 2013 (UTC)

Editnotice for IPs

I have no idea if this is the right page for this, but some people might be interested to comment on m:Talk:Editor_engagement_experiments#Convert_the_IP_editors. πr (t • c) 01:00, 16 May 2013 (UTC)

Policy on talk page archiving

I'm in a very odd edit war with someone with a very poor command of english. The editor appears to think that archiving will somehow effect an active discussion. Here is what is being reverted. Are my actions according to official policy given in WP:TALKCOND? TippyGoomba (talk) 04:28, 16 May 2013 (UTC)

If a dispute has no activity for 90 days... I think it'd be stale. And it needs 6 threads before archiving any. So in all fairness, the auto archiving is not a problem. ChrisGualtieri (talk) 04:41, 16 May 2013 (UTC)

• Misplaced Pages noticeboards
• Pages automatically checked for accidental language links
• Misplaced Pages requests for comment