Help talk:Citation Style 1/Archive 11

Exclude Wikipedia space from CS1 maint: Extra text
There are quite a few pages in Wikipedia space in Category:CS1 maint: Extra text. Instead of "fixing" these pages (many of which are archives), would it be better to exclude Wikipedia space from this category? Thanks! GoingBatty (talk) 02:32, 29 January 2016 (UTC)


 * My two cents: Wikipedia-space pages appear in the error categories as well. I have fixed hundreds and have never had a complaint. Note that you need to look carefully to see if the error is really a demonstration of an example. In that case, using true may be appropriate to add.


 * Excluding all WP-space pages would exclude pages that are intended as help and how-to pages, as well as guidelines and policies. We wouldn't want to exclude those, I think. There may be a way to exclude archives, though, just as we have excluded template sandboxes and test case pages. – Jonesey95 (talk) 03:07, 29 January 2016 (UTC)
 * We can exclude archives. As originally proposed, the code would have excluded   and   pages.  The original discussion is here.
 * —Trappist the monk (talk) 14:15, 30 January 2016 (UTC)

website deprecated?
website is no longer shown as an alias for work. Are we deprecating website? Is there any discussion on that you can point me to? Thanks. ― Mandruss  &#9742;  08:47, 29 January 2016 (UTC) I don't really care what's done here, provided the doc accurately describes what the software does. If the software changes, I'll adapt. &#8213; Mandruss  &#9742;  17:00, 1 February 2016 (UTC) Editors spend countless hours arguing about these matters, which make little or no difference in what the readers see, edit-warring and continually "correcting" others' work to no visible change, and they will continue to do so until the end of time, despite exhortations to stop. Thus my comments below. I personally don't like coding domain names in citations. I've found that common sense is very often a matter of opinion. &#8213; Mandruss  &#9742;  22:14, 1 February 2016 (UTC)
 * No. Where are you looking? website shows as an alias at.
 * —Trappist the monk (talk) 12:18, 29 January 2016 (UTC)
 * Template:cite news &#8213; Mandruss  &#9742;  12:38, 29 January 2016 (UTC)
 * Though the doc is in places confusing in its mentions of "website", it is proper not to use it as an alias of work in . 208.87.234.201 (talk) 14:11, 29 January 2016 (UTC)
 * And this wisdom is written where? If cite news supports it, the doc for cite news should say how it supports it. That's Software 101. &#8213; Mandruss  &#9742;  14:47, 29 January 2016 (UTC)
 * I updated the documentation. – Jonesey95 (talk) 15:49, 29 January 2016 (UTC)
 * I don't see any update. &#8213; Mandruss  &#9742;  15:58, 29 January 2016 (UTC)
 * It appears you updated Template:Citation Style documentation/work2, whereas Template:Cite news/doc uses Template:Citation Style documentation/journal. GoingBatty (talk) 23:14, 29 January 2016 (UTC)
 * So I did. Silly me. I have updated both of them now. – Jonesey95 (talk) 02:39, 30 January 2016 (UTC)
 * Thank you. &#8213; Mandruss  &#9742;  03:45, 30 January 2016 (UTC)
 * This is not a good guideline. is for citing news sources. Websites are not news sources, they often are the medium news is delivered by a source. The source may be entirely online; it doesn't matter. If it is an online journal, use journal. If it is an online newspaper, use newspaper. There is a type parameter if you want to specify medium etc. Based on the latest change, I move to add print as an alias of work in . 208.87.234.201 (talk) 15:17, 31 January 2016 (UTC)
 * Of course web sites can be news sources. It's 2016. The documentation for cite news says "This Citation Style 1 template is used to create citations for news articles in print, video, audio or web." – Jonesey95 (talk) 17:40, 31 January 2016 (UTC)
 * Perfect confusion: "print, video, audio or web" is . News sources are entities that distribute their product over a variety of media. The template is there to cite a news source. The absence of coherence and common sense surrounding the citation system is breathtaking. 65.88.88.127 (talk) 18:44, 31 January 2016 (UTC)
 * Use for e.g. The Huffington Post. -- Red rose64 (talk) 19:52, 31 January 2016 (UTC)
 * work=magazine journal . In the absence of work=news-agency or work=news-blog. 65.88.88.127 (talk) 20:01, 31 January 2016 (UTC)
 * As it says at Template:Cite news: work: Name of the source periodical ... Aliases: journal, newspaper, magazine, periodical, website. Pick one, and don't worry if somebody alters it to one of the others, they're all equally valid. -- Red rose64 (talk) 20:31, 31 January 2016 (UTC)
 * If they are all equally valid, they are superfluous. If they provide to editors semantic information, then the one more approximating the type of source (not the medium of the source) should be used. 64.134.100.179 (talk) 22:29, 31 January 2016 (UTC)
 * The point is, if it's a newspaper that is available online, you can use work or newspaper or website - it really doesn't matter. If we tell people they must use only one of them, we will irritate a lot of people, not to mention all the hassle of sending a bot around to "fix" something that isn't broken. -- Red rose64 (talk) 23:33, 31 January 2016 (UTC)
 * I don't want to force anyone into using any particular alias. But "website" does not belong in a listing that includes types of news sources. It is a medium-type, not a source-type. Nobody is citing websites with (there's  for that), we are concerned with citing news sources (which may be online). If you want to cite the medium, use web. If we are to add distribution media, then I think more aliases for "work" are forthcoming, such as print, audio broadcast etc. I'm sure this will make things even more complicated. 65.88.88.46 (talk) 16:40, 1 February 2016 (UTC)
 * Nobody is citing websites with - Light-years from reality. Tons of editors are doing exactly that, because they have read the first sentence at Template:Cite news, the table at Help:Citation Style 1, and other guidance elsehwere, and believe in following the guidance given.
 * You are saying that when you cite say, a NY Times article, the source is not the news provider (The New York Times), but a website (www.nytimes.com) that the provider is using to present the information. So that instead of New York Times the proper rendition should be www.nytimes.com How does the latter qualify as a news source? Because the doc is confusing or wrong doesn't mean common sense has to be abandoned. The software does a decent job of formatting the citations. The doc is under par in several instances, especially where it sneaks novel (meaning non-discussed) citation guidelines disguised as citation formatting. 72.43.99.130 (talk) 20:39, 1 February 2016 (UTC)
 * Many choose to code The New York Times, in the opinion that "website" is not a synonym for "domain name". Many will defend to the death the notion that a web site is not a newspaper, since you can't hold it in your hands and turn the pages and it doesn't leave ink stains on your fingers, and so they refuse to use newspaper for web-published sources. There is no guidance as to these choices, nor any documented consensus that I'm aware of, hence conflicts such as this one.
 * I've long felt that aliases add unwarranted complexity and conflict (such as this) for no change to what readers see. That's what we're here for, by the way—what readers see. We could simply use work for a range of purposes as documented. But I realize it's probably many years too late for that to happen, so this is a pointless comment. &#8213; Mandruss  &#9742;  20:24, 31 January 2016 (UTC)

|oclc=
I have added simple oclc checks to look for spaces. The code first removes any punctuation from the identifier value (WorldCat ignores punctuation in the identifier value) and then attempts to convert the value to a number which must be 1 or greater. Any non-digit characters the identifier value will cause the conversion to fail and the module will emit a bad oclc error message. These errors will be categorized in

At the time of this writing, this insource search string found 62 oclc values with letters:

None of the links that I checked were valid.

—Trappist the monk (talk) 17:30, 2 February 2016 (UTC)
 * We could check for multiple OCLCs by limiting the number of digits. See this reference source for a rough OCLC specification. Something like this should not be valid:




 * Thoughts? – Jonesey95 (talk) 22:31, 2 February 2016 (UTC)


 * That documentation is rather vague. WorldCat specifically identifies the OCLC number in the Details box.  The document implies, I think, that there are forms of OCLC that have prefixes. But, inclusion of the prefix in oclc causes WorldCat to return a page-not-found error.  Simple testing seems to indicate that removing the prefix from the 'number' returns a page that matches the title in the citation.


 * We can limit the OCLC to 9 digits. If the numbers are sequential, then as I write this, the current top number is 936,401,218 so that leaves us 63,598,781 before the number rolls over to 10 digits.  Perhaps we make the test smart enough to limit the number of digits according to any prefix it may have.


 * I'll work on this tomorrow.


 * —Trappist the monk (talk) 02:03, 3 February 2016 (UTC)


 * My reading of the documentation was that some sources use a prefix of their own before the OCLC identifier, but the identifier itself is a whole number starting at 1 and getting close to 1 billion (US style: 1000000000, or one followed by nine zeroes). I think we should limit the OCLC check to ten digits (not nine, given the guidance at that page), greater than zero. – Jonesey95 (talk) 04:17, 3 February 2016 (UTC)

Rewritten. Since the oclc document specifies length as a function of the prefix, the code tests for length when a recognized prefix is present. For oclc without a prefix and for the prefix, length is constrained to 9 digits for the time being. This is much like the constraint we impose on pmc and pmid. Where prefixes are included in the oclc parameter value, they are stripped from the number and not displayed.

Prefix  requires 8 digits:

Prefix  requires 9 digits:

Prefix  requires 10+ digits:

Prefix  requires 1+ digits without leading zeros (constrained to 9 digits):

OCLC without prefix 1 to 9 digits:

Unrecognized prefix:

Punctuation between two oclc numbers:

Space between two oclc numbers:

—Trappist the monk (talk) 12:58, 3 February 2016 (UTC)


 * Looks good. Nice work. – Jonesey95 (talk) 15:09, 3 February 2016 (UTC)

Interaction with blocks
It seems that  blocks are processed before templates, meaning that cite journal and cite book only work inside them if they go all on one line. See for example - refs 3 and 4 are treated as plain wikitext. If you remove the newline before the first pipe, you get some weird errors about delete characters. There are no delete characters in the wiki text. Hairy Dude (talk) 01:26, 5 February 2016 (UTC)
 * I have "fixed" that article by removing the line breaks, but it looks like this is a limitation of the poem tag. I recommend raising the issue at Help talk:Wiki markup, since it may affect other templates used inside of the poem tag as well. – Jonesey95 (talk) 01:43, 5 February 2016 (UTC)

Perhaps pages+page combined as page of pages
In the Category:Pages_with_citations_having_redundant_parameters, I have cleared all old entries from months ago, and left new entries to show a growing set of examples of recent redundant parameters. Previously, over 80% of entries had been pages+page, but 2nd most were author2+last2 (or similar). For the vast majority, as pages+page, the common fix is to show "page of pages" where many people think "pages=" is the total (similar to French "pages totales=" in fr:Template:Ouvrage but not in fr:Template:Lien_web). If the cites auto-combine as "page of pages" then over 80% of former "redundant" parameters will be valid now, and in viewing prior revisions of those pages, such as in old talk-pages. We would simply state in the CS1 documentation, "when pages+page cite shows page of pages" (or such), and that would remove those numerous pages+page errors from cites. -Wikid77 (talk) 17:18, 5 February 2016 (UTC)
 * All of those edits are relatively new; I have cleared out that category many times over the past year or more. They appear to be caused by editors who misread or do not read the documentation, which clearly states "pages: A range of pages in the source that supports the content. Use either |page= or |pages=, but not both. ... do not use to indicate the total number of pages in the source."


 * Showing "page x of xxx" would require consensus to change the documentation for the CS1 templates. – Jonesey95 (talk) 17:25, 5 February 2016 (UTC)
 * Or are caused by Citation bot. --Izno (talk) 17:30, 5 February 2016 (UTC)

"Check title= value" links to param-link error
I'm confused about the error messages here and how to fix them. I found this citation in Bayou Country.

I see "|url= missing title (help). Check |title= value (help)". There is a title, and the second help link leads to the param-link error explanation. I'm guessing it has to do with the single square brackets in the title parameter. – Jonesey95 (talk) 22:56, 22 January 2016 (UTC)


 * Yes, the brackets are causing the title value error but not the url error.
 * I would guess that because there's a title link the url-title checker is going a little haywire:
 * On an aside, I've removed the link from the article in question, since articles shouldn't have self-links (aside from navigation, etc.). --Izno (talk) 23:05, 22 January 2016 (UTC)
 * On an aside, I've removed the link from the article in question, since articles shouldn't have self-links (aside from navigation, etc.). --Izno (talk) 23:05, 22 January 2016 (UTC)
 * On an aside, I've removed the link from the article in question, since articles shouldn't have self-links (aside from navigation, etc.). --Izno (talk) 23:05, 22 January 2016 (UTC)


 * Thanks for the feedback and the suggestion about how to fix this instance of the problem, but I think the sandbox code might need to be adjusted. There are a number of articles that appeared in Category:CS1 errors: parameter link after the latest code update that seem to be false positives. – Jonesey95 (talk) 04:30, 25 January 2016 (UTC)


 * Square brackets are not allowed in article titles unless they are encoded as html entities (see WP:TITLESPECIALCHARACTERS). The module appears to be doing the wrong thing in this case.  Because it is permissible to wikilink the value assigned to title, the intent was to reuse the code that finds the illegal characters in -link to find the first   of a wikilink when link label and article title from which the module would produce this illegal construct:
 * I have tweaked the module sandbox to explicitly look for the double leading square brackets of a wikilink in title (also applies to series when series-link is set as well as to the various other link/label pairs identified in the help text.
 * I have tweaked the module sandbox to explicitly look for the double leading square brackets of a wikilink in title (also applies to series when series-link is set as well as to the various other link/label pairs identified in the help text.


 * title cannot be linked simultaneously by both title-link and url. When both of the latter are present, title-link consumes title so url has no title-text for which it can be a link.  This is a long-standing error message.


 * —Trappist the monk (talk) 11:01, 2 February 2016 (UTC)

Meanwhile, to view this thread on a mobile-phone screen, I have wrapped the overlong url by inserting a hyphen into "assets/" as "assets-/" which no longer links to the actual webpage but is treated as valid URL format (and wraps on small-device screens). -Wikid77 (talk) 13:37, 8 February 2016 (UTC)
 * Reverted. If you have a problem with the template, the page you should be changing is Template talk:Cite compare. --Izno (talk) 15:34, 8 February 2016 (UTC)

Suppressing unnecessary archive-urls
It would be nice to have some option to pre-emptively archiveurl things but without having any archive-related stuff appear in the rendered citation at all, either with a particular dead-url value to suppress it, or better yet, having display suppressed by default any time dead-url=no. Having archive-related stuff appear when it is not needed is cruft that badly bloats references sections when pre-emptive archiving of Web sources is done article-wide. It's bad enough that I put all my pre-emptive archive-url and archive-date parameters inside HTML comments; it adds 7 characters of edit-mode cruft per cite, versus a big bunch of it visible to everyone when left un-commented-out. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  00:32, 9 February 2016 (UTC)


 * This should not be difficult. I did and then reverted a simple test to prove that a tweak to the code that handles the case of no worked as you described (no archive output).  I'm not sure that no is the best parameter value to use to suppress the archive output.  The historic definition means that the url is still assigned to title and 'Archived' in the archive out put is linked:
 * We already have  and   which keep the archive text output but don't link to the original url:
 * Adding another keyword to handle this particular case shouldn't be a problem. Provide an appropriate keyword.
 * —Trappist the monk (talk) 01:04, 9 February 2016 (UTC)
 * Nominate . It may be more intuitive to change dead-url to url-state. 208.87.234.201 (talk) 14:53, 9 February 2016 (UTC)
 * I could go with "hidden". But having the display off by default would be better. We can have a bot check for dead links and turn the display on for cases that need it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:29, 10 February 2016 (UTC)
 * Adding another keyword to handle this particular case shouldn't be a problem. Provide an appropriate keyword.
 * —Trappist the monk (talk) 01:04, 9 February 2016 (UTC)
 * Nominate . It may be more intuitive to change dead-url to url-state. 208.87.234.201 (talk) 14:53, 9 February 2016 (UTC)
 * I could go with "hidden". But having the display off by default would be better. We can have a bot check for dead links and turn the display on for cases that need it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:29, 10 February 2016 (UTC)

Language
In keeping with my post at Wikipedia_talk:COinS, and because this page has more watchers, I have moved this conversation from Module_talk:Citation/CS1/Feature_requests to here.

At Feature requests#Language, Editor OwenBlacker wrote Is it possible to reinstigate discussion on this change? At the moment, providing human-readable language tagging is done (as Jonesey95 pointed out on 20 December 2013) and COinS-tagging means that we can't use lang within CS1 templates (like {{cite book |title={{lang|es|La Casa de Mi Padre}} |trans_title=My Father's Home |author=Will Ferrell |language=es }}) because it would pollute the machine-readable data; we need to use {{cite book |title=La Casa de Mi Padre |trans_title=My Father's Home |author=Will Ferrell |language=es }} instead.

What would be great would be to change the output markup so that this example above goes from rendering (without the COinS):   to rendering   for example. This would allow assistive technologies correctly to identify the language of the title (and, for example, user CSS to style text differently according to language). Alternatively, rather than assuming that the  (and only the  ) will match the , new parameters could be added such as title_lang, chapter_lang and journal_lang, for example.

I'm entirely open to discussing the details, as I've just made these up on the spot, but in principle this feels like something we could make work, no? :o) —  OwenBlacker (Talk) 14:32, 7 February 2016 (UTC)

Is  required? Wikipedia pages are.

It occurs to me that one way to address this might be to support certain parameters that look like this: title-es, chapter-de, etc where the language code suffix is the appropriate ISO 639-1 code. This will require that we make changes to,   (this one is problematic because it is not at all documented and is not easily understood), and certainly others.

We would ignore the English versions: title-en, etc.

What do we do when script-title is also set? If both script-title and title are set, title is supposed to hold the transliteration of the original title so its language specifier, if provided, must be the same as the specifier in script-title. If the language is specified for one of script-title or title but not both, what do we do then?

—Trappist the monk (talk) 16:44, 7 February 2016 (UTC)
 * Using script-title overloaded to hold the lang code of the title, or a new title-lang, seems more sensible than a number of new parameters. I have a preference for the latter. --Izno (talk)
 * StackExchange on xml:lang. My read is that, since we're serving Html5, we don't need xml:lang. --Izno (talk) 17:29, 7 February 2016 (UTC)
 * We also need parameters for identifying the language of other items IMO e.g. work-title-lang. --Izno (talk) 17:34, 7 February 2016 (UTC)
 * Not sure I quite understand this. How would you overload script-title to hold the language code of title?  Like this?:
 * The purpose of my suggestion was to avoid creating new parameters; we have enough of them now. If we can figure out how to modify or tag existing parameters and still recognize, programmatically, when they are valid, that seems a better solution for editors who will use them.  If we can make this work for title then it should extend to other 'title' holding parameters as well.  Which leads me to the additional question, what about authors:
 * and this is a simple example, author and title are the same language. What about for journals?  For journals, internationally disparate authors are common.  Perhaps we just don't go there.
 * I agree that  does not apply to us, but I thought that the question should be asked since the Editor OwenBlacker specifically included it in the example cite.
 * —Trappist the monk (talk) 18:30, 7 February 2016 (UTC)
 * It was a stray thought tossed out that might solve the issue of "what to do when script is also specified". Don't worry too much if an implementation doesn't jump out at you--we have two others to consider (but which include the issue). I think we should attempt not to confuse the issue of having a title in a different language than the default and the issue of having a title at all, which is why I prefer es + title to title-es. The former can presumably also re-use the language checking utility we have in language without change. There is also the issue of duplicate parameteres that User:Citation bot chokes on (reported already as a bug) as-it-is as well as updating other scripts to consider title and title-es as duplicates.  I think it's trivial to indicate that a certain work's/section's/whatnot's title may be in a particular language in the citation; I'm unsure if the same can be said about personal names. Besides the case of psuedonyms (which, at best, we can indicate are in a particular script), is the name "Steven" in Swedish, English, or Spanish? So I'd be disinclined to agree to an author-lang or similar. --Izno (talk) 18:49, 7 February 2016 (UTC)
 * The relevant section of the HTML5 spec is 3.2.5.3 The  and   attributes, in particular the paragraph beginning "Authors must not use the   attribute in the XML namespace on HTML elements in HTML documents." In this context, "the   attribute in the XML namespace" means  . Therefore, as MediaWiki serves HTML, we must not add the   attribute to a  tag. -- Red rose64 (talk) 21:33, 7 February 2016 (UTC)
 * Concur.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:30, 10 February 2016 (UTC)
 * It was a stray thought tossed out that might solve the issue of "what to do when script is also specified". Don't worry too much if an implementation doesn't jump out at you--we have two others to consider (but which include the issue). I think we should attempt not to confuse the issue of having a title in a different language than the default and the issue of having a title at all, which is why I prefer es + title to title-es. The former can presumably also re-use the language checking utility we have in language without change. There is also the issue of duplicate parameteres that User:Citation bot chokes on (reported already as a bug) as-it-is as well as updating other scripts to consider title and title-es as duplicates.  I think it's trivial to indicate that a certain work's/section's/whatnot's title may be in a particular language in the citation; I'm unsure if the same can be said about personal names. Besides the case of psuedonyms (which, at best, we can indicate are in a particular script), is the name "Steven" in Swedish, English, or Spanish? So I'd be disinclined to agree to an author-lang or similar. --Izno (talk) 18:49, 7 February 2016 (UTC)
 * The relevant section of the HTML5 spec is 3.2.5.3 The  and   attributes, in particular the paragraph beginning "Authors must not use the   attribute in the XML namespace on HTML elements in HTML documents." In this context, "the   attribute in the XML namespace" means  . Therefore, as MediaWiki serves HTML, we must not add the   attribute to a  tag. -- Red rose64 (talk) 21:33, 7 February 2016 (UTC)
 * Concur.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:30, 10 February 2016 (UTC)

Second DOI for English translation
Many Russian mathematics journal articles have two DOIs, one for the original Russian article and a second one for its translation into English. Example: (Also note that the Russian original is free online while the translation is paywalled.) Above, I am abusing the id parameter to link the translation. Is there or should there be a better way? —David Eppstein (talk) 21:48, 27 January 2016 (UTC)


 * Or just append the extra stuff after the citation template:


 * Translated as.
 * ~ J. Johnson (JJ) (talk) 00:24, 28 January 2016 (UTC)
 * Right, that's what I actually did in the article where this came from. Using id was a later cleanup for here. But it would be nice if we could actually use the template to format the whole citation rather than having some of it spill over into freeform non-templated text. —David Eppstein (talk) 06:16, 28 January 2016 (UTC)
 * I agree. But this kind of problem doesn't happen too often, and it's easier to just slap something on then try to fine tune the tool for every possibility. ~ J. Johnson (JJ) (talk) 21:12, 28 January 2016 (UTC)
 * Why would we need, on en.WP, to provide a URL (etc.) to the Russian version if the English one is available? WP:NOT a document translation indexing service.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:38, 10 February 2016 (UTC)

|editor= documentation
Editor ‎SMcCandlish added this to the editor : "These parameters are for editors of collaborative printed works, such as multi-author anthologies. Wikipedia does not use them to indicate the managing editors of periodicals such as journals, newspapers, magazines, or news sites (this information is not needed in source citations). For editor-revisers of later editions of previously published unitary works, add any editors as authors, with an '(ed.)' annotation after their given names, e.g. ; this will prevent formatting that implies the cited chapter in a title (for books), or the title in a work or website, is an isolated contribution contained within a multi-author work compiled by the named editor(s). None of these parameters should be used to add other, non-essential contributors who are not needed in citations, such as foreword authors or illustrators, only credited editors, revisers, and work-wide commentators." I am on wikibreak and have no time to discuss right now so have reverted the addition and started this discussion. Please discuss.

My objection lies in the 'add any editors as authors, with an "(ed.)" annotation ...'. We should not be encouraging the improper practice of adding extraneous text to parameters that are part of the metadata nor should we misuse parameters in this way.

We can, and probably should disable editor when the template is, ,. Foreword authors is supported in with contributor and others serves for illustrators and other non-essential contributors.

—Trappist the monk (talk) 13:49, 25 January 2016 (UTC)
 * That solution would work for some cases, but not for the . I'm not trying to impose a permanent solution, just work around a problem that bites us really often.  The number of misleading citations that imply that a chapter in a single-author book, in a revised edition with an author-posthumous editor, is just one author's minor contribution to an anthology, greatly outnumber the cases of metadata-extraneous "(ed.)" annotations. You've said before that any such editorial insertions can be used with square brackets, so just changing it to "[ed.]" is sufficient for my documentation to be correct. (And I already know that for some of these templates we have special parameters for other contributor types, and I still see editor parameters abused for this purpose frequently, so the documentation still needs to say not to use editors parameters for those.) I would prefer that this be fixed in some parameter-based way, that suppresses the "in" output when it's not wanted, but until that's implemented, what I documented (plus the square-brackets fix) is the most correct approach, because it's overwhelmingly more important that our citations be correct and be parsed properly by our own readers than that COinS metadata be perfect. That metadata is an afterthought, a convenience we provide for non-central purposes, and some of us are starting to think that directly implementing it in these templates is more trouble than its worth. Almost every time I document a, reader- or editor-affecting problem here and try to work around or fix it, I get shot down or ignored by the same one or two  editors for whom COinS seems to be more important than WP:CITE, but who effectively totally control these templates.  I've been a vocal supporter of CS1 for years, and would like to see CS2 eliminated, but over the last year and half I get increasingly inspired to go create a CS3 that looks almost identical to CS1, and has one consistent set of parameters, and no extraneous fiddly stuff. CS1 has turned into an enormous pile of "feeping creaturism", and hardly anyone can figure out how to use it effectively any longer. I've been here a decade, and these template still screw up my sourcing attempts at least once a week. I spend more time reading these templates' documentation than any others. I've reported more problems with these templates than any others. Fewer of them have been resolved than with any others. Given that people are not required to use any of our templates at all to insert citations, it would be a entirely valid approach to simplicity-fork this. If the principal and rather my-way-only maintainers of these templates don't want to see that happen, they need to be more responsive to problem reports, including paying attention to the details they report, and not dismissing them "oh well, you can do this complicated hack no one will remember nor understand when they encounter it", much less "we can't fix this because our precious metadata won't be ideal".  Faaaaaack...  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:28, 25 January 2016 (UTC)
 * Where have I said that editorial insertions can be used with square brackets?
 * Yes, Wikipedia editors abuse editor and author to include names that are neither (sometimes with annotation; sometimes not). That will be a problem forever I'm afraid.
 * Yes, a parametric remedy is best. A couple of solutions occur to me off the top of my head: perhaps a modification of mode to accept additional keywords to control how the editor name list is rendered; perhaps alternate editor parameters that render in a certain way; perhaps some other parameter or parameter modification.  Of these, I think that modifying mode is likely the better solution. Suggest other solutions.
 * Consumers of the metadata are also our own readers and though only a small minority of our own readers their right to quality information is the same as that of the majority.
 * —Trappist the monk (talk) 13:13, 26 January 2016 (UTC)
 * We could also modify display-editors in some fashion; this would be my new favorite solution.
 * —Trappist the monk (talk) 13:22, 26 January 2016 (UTC)
 * I agree that we need to be careful not to allow the metadata aspect of citation templates to prevent reasonable use within Wikipedia, but recommending something like Jane (ed.) can't possibly be a sensible way forward – it's simply a misuse of the parameters regardless of whether it generates misleading metadata. ( it's like using '' instead of em or  instead of . Largely unnecessary. For some books, there may be 5 or more ISBNs, depending on whether its hardback, paperback, trade paperback, spiral-bound, e-book, etc., and maybe additional ones depending on whether the UK or US or India office printed it, etc.  There's no point in including all this info, per WP:NOT.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:34, 10 February 2016 (UTC)
 * The question was about specifying that there may be substantially different editions based on medium-type. Is it enough to add e.g. e-book and digital (or similar) to a citation of an e-book that has additional features not in the print editions? Or is an additional signifier along the lines of eISSN to be considered? 65.88.88.127 (talk) 16:23, 10 February 2016 (UTC)
 * —Trappist the monk (talk) 13:22, 26 January 2016 (UTC)
 * I agree that we need to be careful not to allow the metadata aspect of citation templates to prevent reasonable use within Wikipedia, but recommending something like Jane (ed.) can't possibly be a sensible way forward – it's simply a misuse of the parameters regardless of whether it generates misleading metadata. ( it's like using '' instead of em or  instead of . Largely unnecessary. For some books, there may be 5 or more ISBNs, depending on whether its hardback, paperback, trade paperback, spiral-bound, e-book, etc., and maybe additional ones depending on whether the UK or US or India office printed it, etc.  There's no point in including all this info, per WP:NOT.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:34, 10 February 2016 (UTC)
 * The question was about specifying that there may be substantially different editions based on medium-type. Is it enough to add e.g. e-book and digital (or similar) to a citation of an e-book that has additional features not in the print editions? Or is an additional signifier along the lines of eISSN to be considered? 65.88.88.127 (talk) 16:23, 10 February 2016 (UTC)

date=, year= mismatch
Hi there. In [//en.wikipedia.org/w/index.php?title=Arthur_Quiller-Couch&oldid=prev&diff=704369517 this] edit I overcame a date=/year= mismatch error but I do not feel this is a proper edit to really fix the error. What is the correct fix? The papers were re-released in 2010 and written in 1914. Ping me back. Cheers! 04:42, 11 February 2016 (UTC)


 * I don't think it was the correct fix. Your cite uses 28 January 1914 which appears to refer to the date of the lecture that is Chapter 12.  Generally, date is the publication date.  The template identifies Cambridge University Press as publisher but links to the Bartleby version.  The Bartleby version is dated April 2000.  According to WorldCat and GoogleBooks, the ISBN is for a 2008 Cambridge publication.  Were I seeking the exact source that you are citing, I would be at a loss since I cannot extract the reality, the WP:SAYWHEREYOUGOTIT, from this collection of mismatched facts.  Choose one source, and cite that.  Since the Bartleby appears to support the article text, I would rewrite the cite this way:
 * —Trappist the monk (talk) 11:15, 11 February 2016 (UTC)
 * —Trappist the monk (talk) 11:15, 11 February 2016 (UTC)
 * —Trappist the monk (talk) 11:15, 11 February 2016 (UTC)

author-link effciency
It would be helpful if y would auto-grab values from the author/first/last[N] parameters and use them. About 80% of the time, no disambiguation or other alteration is needed (unless you use one of those awful citations styles that force the use of initials, which should be banned on WP, but that's another matter). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:04, 10 February 2016 (UTC) I assume the point of SMcCandlish's proposal is that IshiharaShintaroShintaro Ishihara is significantly more difficult and time-consuming for the average, non-techy user than IshiharaShintaroy, as well as being a case of data redundancy/duplication. It has a small upside and no downside that I can see, aside from the one-time developer effort, and a small bit of feature creep. &#8213; Mandruss  &#9742;  20:50, 10 February 2016 (UTC)
 * This would cover our article references in a sea of red links. Is that desirable? Most authors do not pass notability criteria. – Jonesey95 (talk) 14:27, 10 February 2016 (UTC)
 * It's only if y is coded. &#8213; Mandruss  &#9742;  14:30, 10 February 2016 (UTC)
 * How about having the author-link not display if no target is found? Just a little more run-time overhead. ~ J. Johnson (JJ) (talk) 19:47, 10 February 2016 (UTC)
 * But the same benefit would apply to other parameters that can accept wikilinks. So the first thing we'd see would be a thread saying, hey, if we have this cool autolinking feature for author-link, why not work and its aliases? And so on. Hard to justify saying yes to one and no to the rest, hard to justify the overhead to do all of them, in my opinion. Slippery slope, Unintended consequences. &#8213; Mandruss  &#9742;  19:52, 10 February 2016 (UTC)
 * This proposal makes absolutely no sense. To reinforce what Jonesey said above, 99.9% of authors currently or will ever have a Wikipedia page devoted to them.  Implementing this proposal would convert the reference section of many articles into a sea of red. Also the y parameter makes no sense.  If you are going to the trouble of using that, why not just use author-link as it was originally intended and only use it if and only if the corresponding page exists? (For the remaining 0.1% of authors that do have articles, it would be simple enough for a bot to create systematic redirects from the Vancouver style author name to the target article so that we can avoid that awful first1, last1, ... parameter bloat,  but that's another matter ;-) Boghog (talk) 20:25, 10 February 2016 (UTC)
 * To link author names in vauthors, use author-linkn where  is that author's position in the vauthors list.  Same is true for veditors.  Bots to create redirects not needed.
 * —Trappist the monk (talk) 20:37, 10 February 2016 (UTC)
 * Completely agree that bots are not needed (see below). Boghog (talk) 21:07, 10 February 2016 (UTC)
 * Implementing this proposal would convert the reference section of many articles into a sea of red - No reading of SMcCandlish's proposal suggests such an outcome. No reading of J. Johnson's proposal suggests such an outcome. Both mentions of "sea of red" have been unfounded. I assumed that Jonesey95 simply misread the proposal, but to continue saying that is puzzling to me.
 * OK, I misread the original proposal, but I still think it doesn't make any sense. Works "80% of the time" is a non starter. In addition, there are numerous ways that an the title of an author could be spelled and authors with the same name are a frequent occurrence. It is simpler and more reliable for an editor to locate and link the author's article than relying on an automatic procedure that will frequently be wrong. Boghog (talk) 21:09, 10 February 2016 (UTC)
 * The proposal assumes that the editor would first check to see if the article's title is an exact match for first+last. The only difference would be what they code. They wouldn't use the feature in cases where it wouldn't work. The 80% number is the proposer's guesstimate of the proportion of cases where it would work. &#8213; Mandruss  &#9742;  21:14, 10 February 2016 (UTC)
 * Assumptions concerning editor behavior are dangerous. An editor would have made a conscious decision to use the author-linkn and is more likely to have checked the target of the link. An editor using y may assume that it would work without checking. Boghog (talk) 21:33, 10 February 2016 (UTC)
 * A fair point. A competent editor would check for a redlink, but not all editors are that competent. At least we're now on the same page as to what the proposal means. &#8213; Mandruss  &#9742;  21:38, 10 February 2016 (UTC)
 * I don't like this idea. No automatic system will be able to determine if the linked-to article is the right one. Consider Diana Ross (author) - how is the system going to know that the disambiguator is necessary to distinguish from the Motown singer? -- Red rose64 (talk) 00:23, 11 February 2016 (UTC)
 * The system doesn't determine that, the editor does. As I've said, the editor would not code y unless they have checked and determined that the correct article's title is a match for first+last. At least that's how the proposal intends for it to work. &#8213; Mandruss  &#9742;  00:30, 11 February 2016 (UTC)
 * Expectations of editorial care and thoroughness are nearly always disappointed. While there is no indication that an editor will exercise more care and checking if s/he has to type out the full name, yet we might hope that the few extra seconds required might allow for a tad more reflection on the matter. What would be really disappointing is if some editors started thinking that the s/w will handle all the details, and blame the s/w where all they did was to type "y". ~ J. Johnson (JJ) (talk) 21:22, 11 February 2016 (UTC)

Need {cite_page} to link "url=" to page
I am thinking to create a simple template, {cite_page} to ignore "title=" & "publisher" and just show "Author (year). p. [url page]." as a short cite for optional link page+url. However, the template could also show "volume=" so the cite could link a page within different volumes of the same author/year book. The benefit would be to morph multiple refs to the same book, but different pages, to be {cite_page} with optional "url=" link to each page (rather than link to title). Recent timing tests show the simple markup cite templates (without Lua) now run over 800/second and use perhaps 300 bytes (rather than Lua's 1,000-1,600 per cite, as 4x title+url length) of the wp:post-expand include size (limit 2,000MB). Would that kind of short cite need CoINS metadata? -Wikid77 (talk) 17:04, 5 February 2016 (UTC)
 * What's wrong with using the existing sfn and its cousins?


 * Here's a short cite, linking to page 34 of an article, hosted on www.example.com.


 * The real source is a Time magazine article, fully cited using harv.

— Preceding unsigned comment added by Jonesey95 (talk • contribs) 17:16, 5 February 2016‎

While the use of "" is great for people who think of parameters that way, it is very, very different from "author=" plus "year=" plus "url=" & "pages=" etc. Again, the benefit would be to easily morph multiple refs to the same book, but different pages, to be {cite_page} with optional "url=" link to each page (rather than link to title). Typically, we see repeated:
 * {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google |publisher=Acme}
 * {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google..PA14 |page=14}
 * {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google..PA34 |pages=34-36}
 * {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google..PA67 |pages=67}

So to fix all the repeats, just change each extra "cite book" to be "cite page" and instantly done. No need to explain Harvard referencing with the mandatory parameter "|ref=harv" and no need to omit "author=" or "year=" or "url=" or "pages=" (etc.); the template could just ignore "title=" (or "publisher") to show the short cites. Fixing repeated references would become a matter of seconds per article, with no worry of misspelling the author's names or putting wrong year. New users would see {cite_page} as having similar parameters to the other cites they wrote in the page. -Wikid77 (talk) 17:48, 5 February 2016 (UTC)
 * How is a reader to know that "Baker 2013 p. 34" is a reference to the full Baker 2013 citation without a link to the full citation? Showing just "Author (year). p. [url page]." makes it difficult for the reader to locate the source if there is not a clear link to that full source in the article. Harvard referencing provides that full link.


 * Maybe a sandbox example page would be a good way of explaining how your proposed way is better than the documented way of doing this that is standard and has existed for a while. – Jonesey95 (talk) 18:03, 5 February 2016 (UTC)


 * The {cite book ...} examples above are all full citations of a source, and generally should not be repeated; once per article is generally sufficient. Repeated citation of a source is handled with short citations, that is their purpose, and harv implements them very well. E.g.:
 * {harv |Doe|2011|p=14}
 * {harv |Doe|2011|pp=34-36} etc.


 * It seems to me what you want is a way of converting existing instances of repeated full citations to some kind of short cite without a lot of retyping, essentially re-using the existing "typing". That would leave a lot of unused cruft in the text, confusing new editors as to what parameters are actually needed. It would be better to have a script that does whole replacement of such instances, perhaps after checking that there is a full citation some where. ~ J. Johnson (JJ) (talk) 21:56, 11 February 2016 (UTC)


 * P.S. Just had an idea. How about a {cit2harv} template that is only an alias for {cite} (etc.). An editor could use it to identify full citations that should be converted to short cites, which would be done by a script. What I like about this is the avoidance of yet another bot turned loose; it would provide specific and deliberate targeting for a limited purpose script. ~ J. Johnson (JJ) (talk) 22:05, 11 February 2016 (UTC)

Italics in publisher
May we use italics in publisher when it is a newspaper? SLBedit (talk) 00:49, 9 February 2016 (UTC)
 * What's wrong with using newspaper? E.g.
 * (although I would normally omit the publisher in this case). —David Eppstein (talk) 00:54, 9 February 2016 (UTC)
 * I normally use when using a source from a newspaper's website. SLBedit (talk) 01:06, 9 February 2016 (UTC)
 * I'm not sure why you should: it's a newspaper, regardless of whether you are reading the print or online version, just like en e-book is still a book and an online scientific journal is still a journal. But if you insist, you can use work:
 * —David Eppstein (talk) 01:15, 9 February 2016 (UTC)
 * Yes, work (alias for website) adds italics. SLBedit (talk) 02:59, 9 February 2016 (UTC)
 * What is the reason for to display a website's name in italics? SLBedit (talk) 03:07, 9 February 2016 (UTC)
 * cs1|2 take their styling cues from standard published style guides like MLA, APA, CMOS. No doubt, we've made certain styling decisions ourselves, but in general, cs1|2 is guided by those established style guides.  There is this, which on pages 4 and 5, compares three style guides for citing online material:
 * If one is to believe that, website names are rendered in italics in citations.
 * —Trappist the monk (talk) 12:37, 9 February 2016 (UTC)
 * The answer to your question is: no you may not use italics in publisher. Markup and static text in rendered citations is the duty and obligation of the template.  The cs1|2 templates provide a machine readable version of the rendered citation as metadata.  By adding extraneous markup and text to parameter values, you corrupt that metadata.  This is documented in all of the cs1|2 templates at, for example, Template:Cite_web.
 * —Trappist the monk (talk) 01:19, 9 February 2016 (UTC)
 * Okay. SLBedit (talk) 02:59, 9 February 2016 (UTC)
 * Also, do not confuse publisher with publication. Newspapers are publications; they have publishers. -- Red rose64 (talk) 12:03, 9 February 2016 (UTC)
 * Which in many cases take the same name as their publication. --Izno (talk) 13:15, 9 February 2016 (UTC)
 * In reality, not exactly (nitpick). Publishers have designations (Inc., Ltd.) etc. It is a convention not to include these in citations which sometimes makes publication-title=publisher-name. 208.87.234.201 (talk) 14:58, 9 February 2016 (UTC)
 * That's why the wording here says "substantially" the same.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:26, 10 February 2016 (UTC)
 * A recent discussion on this page showed that, while there are strong opinions, there is no documented community consensus on the use of publisher in a news context. I welcome anyone to go to a more public venue and try to establish such a consensus. &#8213; Mandruss  &#9742;  15:27, 9 February 2016 (UTC)
 * Also, do not confuse publisher with publication. Newspapers are publications; they have publishers. -- Red rose64 (talk) 12:03, 9 February 2016 (UTC)
 * Which in many cases take the same name as their publication. --Izno (talk) 13:15, 9 February 2016 (UTC)
 * In reality, not exactly (nitpick). Publishers have designations (Inc., Ltd.) etc. It is a convention not to include these in citations which sometimes makes publication-title=publisher-name. 208.87.234.201 (talk) 14:58, 9 February 2016 (UTC)
 * That's why the wording here says "substantially" the same.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:26, 10 February 2016 (UTC)
 * A recent discussion on this page showed that, while there are strong opinions, there is no documented community consensus on the use of publisher in a news context. I welcome anyone to go to a more public venue and try to establish such a consensus. &#8213; Mandruss  &#9742;  15:27, 9 February 2016 (UTC)

Why should I use cite news for news and articles available on a newspaper's website if those articles are different from the (printed) newspaper itself? (I'm not discussing an online edition of a printed newspaper.) SLBedit (talk) 18:28, 10 February 2016 (UTC)
 * Agreed with David. Using is an abuse of the parameters. If you insist on drawing a distinction between the online and print editions (this should only be done when an article appears in one but not the other, or when it appears in different form in one vs. the other), do :   — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:24, 10 February 2016 (UTC)
 * I don't know, maybe because they are news? &#8213; Mandruss  &#9742;  19:06, 10 February 2016 (UTC)
 * Web news. SLBedit (talk) 19:36, 10 February 2016 (UTC)
 * News nonetheless. Perhaps you wish to propose, since is clearly not up to the task. Before you do that, see WP:BIKESHED. &#8213; Mandruss   &#9742;  19:39, 10 February 2016 (UTC)
 * But a source from a newspaper's website is not always news. SLBedit (talk) 22:49, 10 February 2016 (UTC)
 * For that source, would probably be more appropriare. That doesn't mean you can't use  for the items that are news. You don't have to use the same template for everything on a given site. &#8213; Mandruss   &#9742;  22:55, 10 February 2016 (UTC)
 * Okay. SLBedit (talk) 23:00, 10 February 2016 (UTC)
 * says, right at the top,
 * This template is used to create citations for news articles in print, video, audio or web.
 * Nothing in that sentence prevents it from being used for a news story on a newspaper's website. If you don't want to use the newspaper parameter, you can use work or website, as I explained above at 23:33, 31 January 2016. -- Red rose64 (talk) 00:03, 11 February 2016 (UTC)
 * What should I use for a magazine that is part of a newspaper? I'm inclined to use with newspaper, which is an alias for magazine. SLBedit (talk) 00:59, 11 February 2016 (UTC)
 * My answer depends on one factor, if that magazine is a nationally printed or recognizable item that's inserted in a paper, like Parade, versus something specific to a single paper. For the former, I'd cite the magazine with no reference to the enclosing paper as it wouldn't matter which paper that included it was consulted. In the latter case, I'd probably cite it as a department of the enclosing paper since you'd need to find that specific paper to find that magazine. Things like The New York Times Book Review, which are recognizable as their own publications would probably fall into the former case as well.  Imzadi 1979 →   10:12, 11 February 2016 (UTC)
 * I would do it the other way round - you're citing a news source, so use and since it's not the actual newspaper but its magazine, use e.g. The Sunday Times Magazine. -- Red rose64 (talk) 14:24, 11 February 2016 (UTC)
 * Agree with Imzadi1979. Most newspaper "magazines" cannot be purchased/subscribed to/searched-for independently, and therefore they cannot be verified independently of the enclosing newspaper. So they should not be cited independently. Most newspaper publishers in my experience call them their newspaper's "magazine section". The proper citation would be: . 72.43.99.146 (talk) 15:25, 11 February 2016 (UTC)
 * The magazine (yes, it's printed "magazine" in the cover) I'm referring to is like a supplement, it cannot could not be bought separately. It came with the newspaper. I don't have the newspaper anymore, but I know its issue number, which is also printed in the magazine's cover. SLBedit (talk) 18:50, 11 February 2016 (UTC)
 * The issue numbers of supplementary magazines don't necessarily correspond with those of the newspaper itself, particularly when the magazine hasn't always been included: The Sunday Times Magazine began in 1962, whereas The Sunday Times began some 140 years earlier. Although intended for sale together, they're often printed in different plants, and supplied to the newsagent in different bundles - my younger brother had a paper round, and had to make sure that he put the correct supplement inside each Sunday newspaper before he delivered it. -- Red rose64 (talk) 00:58, 12 February 2016 (UTC)
 * In this situation, the issue number belongs to the newspaper. It's not a regular magazine. SLBedit (talk) 01:45, 12 February 2016 (UTC)

By far the most important things about citations are: As long as your cite satisfies those two goals, the rest is trivial detail. Make some attempt to follow whatever guidance is given in the doc. Where something is not covered in the doc, or the doc is ambiguous, use your best judgment. Many of the things we agonize over make no difference in what the reader sees, so we should cease agonizing over them. Even when they make a difference in what the reader sees, it's usually a minor formatting difference that is meaningless to most readers. My opinions. ― Mandruss  &#9742;  01:33, 11 February 2016 (UTC)
 * 1) To facilitate verifiability. Give the reader a link they can click on to verify the information. And it's nice if the rendered citation looks neat and professional, too.
 * 2) To help combat link rot. When the link for a source goes dead, it's easier to find its new location (if any) if the cite contains information beyond the URL, such as title, author names, date, etc.

Update to the live cs1|2 modules weekend of 20–21 February 2016
I propose to update the cs1|2 modules over the weekend of 20–21 February 2016. The changes are:

to Module:Citation/CS1:
 * 1) bug fix; format/title type order in ; discussion
 * 2) query and fragment delimiters in ; discussion
 * 3) language code 'no' spoof no longer required; discussion
 * 4) presentation tweaks; discussion
 * 5) bug fix in ; discussion
 * 6) add language code 'be' to ;

to Module:Citation/CS1/Configuration:
 * 1) oclc error checking; discussion
 * 2) presentation tweaks; discussion

to Module:Citation/CS1/Date validation:
 * 1) tweak  and  ; better code practices;

to Module:Citation/CS1/Identifiers: —Trappist the monk (talk) 12:50, 14 February 2016 (UTC)
 * 1) oclc error checking; discussion


 * Do you have an opinion on the section "Status of filtering square brackets in URLs" above? I think it would be helpful to add this check. Thanks. – Jonesey95 (talk) 14:13, 14 February 2016 (UTC)
 * I don't. At least not at the moment.  More at the original discussion.
 * —Trappist the monk (talk) 18:30, 14 February 2016 (UTC)

Suggestion for orig-date= parameter
In many cases, where we currently use the orig-year parameter, the full original date is known (and sometimes even important or at least insightful to know), but our orig-year parameter only accepts a year, not a full date. I would like to suggest to either relax the error checking of the orig-year parameter or to add an orig-date parameter to the cite template framework accepting a date similar to the date parameter. The existing orig-year parameter could be deprecated and mapped to the new orig-date parameter. --Matthiaspaul (talk) 18:05, 15 February 2016 (UTC)
 * There is no error checking on orig-year:
 * —Trappist the monk (talk) 18:09, 15 February 2016 (UTC)
 * Thanks for the hint, I haven't tried stuffing full dates into orig-year for quite a while, but I seem to remember that it threw an error message when I tried back then. Anyway, even better this way.
 * So my suggestion is basically to "rename" orig-year into orig-date and change the documentation accordingly.
 * --Matthiaspaul (talk) 19:23, 15 February 2016 (UTC)
 * So my suggestion is basically to "rename" orig-year into orig-date and change the documentation accordingly.
 * --Matthiaspaul (talk) 19:23, 15 February 2016 (UTC)

Suggestion for edition= parameter to treat raw numbers
I would like to suggest an addition to the edition parameter, so that it would treat at least the numbers 1..9 (perhaps 1..99) as symbols, so that we no longer have to write 3rd, but just 3 etc. It would make the parameter list easier to parse and edit by editors (at least in the default cases), it would make it easier to change the output format of the template in the future, and it would aid automatic processing by bots, translation services, etc. Since the use of raw numbers is not conflictive with the existing usage of the parameter, it should be very easy to implement this. --Matthiaspaul (talk) 18:05, 15 February 2016 (UTC)
 * This has occurred to me but I haven't given it much thought. Apparently in some parts of the world, '3.' (with the dot) is the same as '3rd' so if we consider this, we should standardize on one form of ordinal number.
 * —Trappist the monk (talk) 18:15, 15 February 2016 (UTC)
 * FWIW, I can confirm that "3." is a very common form to numerically denote "third".
 * My proposal was meant to accept the value of the edition parameter symbolically only when it does not contain any other info. In all other cases, the string would be passed along unaltered. So, values like "1", "2", "3" etc. would be replaced by whatever is our preferred text to indicate a first, second, third etc. edition (f.e. "1st ed.", "2nd ed.", "3rd ed." in the English version of the template), whereas "third", "3." or "3rd" (with or without more stuff following) would not be changed in any way. So, the proposal would only cover the most common cases, but still give us the freedom to use the parameter as free-flow parameter for the more complicated cases.
 * Beyond the scope of the proposal, a bot could implement more complicated logic to detect obvious cases like "third", "3.", "3rd" or "Dritte Auflage" and replace them by "3" (still leaving alone anything it cannot detect reliably), but this would already be too complicated to put into the template itself, I think. So, I'm not proposing to add this to the template.
 * --Matthiaspaul (talk) 19:52, 15 February 2016 (UTC)


 * What if a publisher decides to call their edition "3"? Jc3s5h (talk) 20:06, 15 February 2016 (UTC)


 * Which would be the common case, and not a problem case at all, or do I miss something?
 * At present, you would normally use 3rd and it would be rendered as "(3rd ed.)". You could continue to do this if you want to, of course.
 * However, following my proposal, you could simply write 3 as well (which isn't a useful value at present, as it would result in the grammatically incorrect rendering "(3 ed.)" at present). Following my proposal, this would be rendered properly as "(3rd ed.)" as well (but it could be easily adjusted to something different like "(third edition)", if we'd want to do so in the future).
 * There is no conflict with existing usage of the parameter, and the existing usage can continue into the future without creating problems. The point is once again to isolate semantics (information) from presentation (grammar, style).
 * --Matthiaspaul (talk) 20:34, 15 February 2016 (UTC)


 * The common situation is the publisher would call the edition "3rd" or "third". But especially if dealing with software, it possible a publisher would decide to call an edition just "3". Jc3s5h (talk) 20:48, 15 February 2016 (UTC)
 * Yes, in the case of a software rather than a book, a publisher might very well decide to call an edition "3". But outside of a name (which would most likely end up as part of the title) wouldn't you still enter this as 3rd? After all, if you'd enter it as 3, the template displays "(3 ed.)" at present, which is grammatically incorrect.
 * --Matthiaspaul (talk) 22:32, 15 February 2016 (UTC)

Cite magazine with combined season date.
I'm looking to properly cite the following magazine https://issuu.com/apa1906network/docs/201510001-02. The issue date according to the cover is "Spring/Summer 2015". How should I place this into the date field?Naraht (talk) 01:42, 17 February 2016 (UTC)
 * Spring–Summer 2015. We convert the slash to an en dash for consistency with our MOS.
 *  Imzadi 1979 →   01:57, 17 February 2016 (UTC)
 * Thank You!Naraht (talk) 13:48, 17 February 2016 (UTC)
 * I wonder whether seasons should be used? They are frowned upon by WP:MOS and also by WP:SEASON. Instead, "March–August" seems to be suggested instead of "Spring–Summer". 65.88.88.126 (talk) 16:14, 17 February 2016 (UTC)
 * That would apply to wording date references inline, but it can't apply to citations for a very practical resason. Changing it would remove the correct information used to locate the proper issue of a source article. Additionally, there is no one way to convert a season to a range of dates/months even once we assume which hemisphere's seasons are an appropriate starting point.  Imzadi 1979 →   16:31, 17 February 2016 (UTC)
 * Your reasoning is sound. An indication (per your explanation) in the doc might be helpful to editors and would-be strict MOS followers. 65.88.88.126 (talk) 16:44, 17 February 2016 (UTC)
 * I think User:65.88.88.126's question illustrates why WP:MOS should be changed to clearly state that it does not apply to citations at all, and that only WP:CITE governs citations. Jc3s5h (talk) 16:45, 17 February 2016 (UTC)
 * For the magazine in question, it is definitely Northern Hemisphere seasons (USA based Collegiate Greek Letter Organization), but I'd rather drop the date descriptor and just use volume and number rather than try to convert to a date range. (Ugh).Naraht (talk) 18:33, 17 February 2016 (UTC)
 * at least as far as I'm concerned, in citation contexts, the name of a season or a quarter that appears on a periodical's cover as a publication date is just as valid as the name of a month, and they should be treated accordingly. As a result, the MOS needs an exception to its preference of avoiding seasons. That preference is laudable in the sense of making dates more accessible to a global audience, but it has been carried to an extreme when the context of an article makes it quite clear otherwise what is intended. However, this is not the place to discuss that other than to say that copying the season name from a periodical to a citation should always be an acceptable practice.  Imzadi 1979 →   06:45, 18 February 2016 (UTC)
 * So where is the appropriate place to discuss it/make the policy more clear?Naraht (talk) 08:52, 18 February 2016 (UTC)
 * I just checked, and it says at Manual of Style: "For guidelines regarding publication dates in citations, refer to Wikipedia:Citing sources § Dates and reprints of older publications." MOS:SEASON just needs a similar statement, which I proposed at WT:MOSDATE.  Imzadi 1979 →   09:47, 18 February 2016 (UTC)
 * the MOS has been updated to make clear that the season in an issue date is perfectly acceptable:  Imzadi 1979  →   23:49, 18 February 2016 (UTC)
 * Thank you a lot!Naraht (talk) 00:50, 19 February 2016 (UTC)
 * Thank you a lot!Naraht (talk) 00:50, 19 February 2016 (UTC)