Help talk:Citation Style 1/Archive 11

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.
Archive 5 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 15

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 |template-doc-demo=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 /[Aa]rchive and /[Ll]og 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  08:47, 29 January 2016 (UTC)

No. Where are you looking? |website= shows as an alias at cite web.
Trappist the monk (talk) 12:18, 29 January 2016 (UTC)
Template:cite news#csdoc_workMandruss  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 {{cite news}}. 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. ―Mandruss  14:47, 29 January 2016 (UTC)
I updated the documentation. – Jonesey95 (talk) 15:49, 29 January 2016 (UTC)
I don't see any update. ―Mandruss  15:58, 29 January 2016 (UTC)
@Jonesey95: It appears you updated Template:Citation Style documentation/work2, whereas Template:Cite news/doc#Periodical 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. ―Mandruss  03:45, 30 January 2016 (UTC)
This is not a good guideline. {{cite news}} 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 {{cite book}}. 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 media. 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 {{
The Huffington Post. --Redrose64 (talk
) 19:52, 31 January 2016 (UTC)
|work==|magazine= |work=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#Periodical: 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. --Redrose64 (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. --Redrose64 (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 {{cite news}} (there's {{cite web}} for that), we are concerned with citing news sources (which may be online). If you want to cite the medium, use |type=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 {{cite news}} - 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#Templates, and other guidance elsehwere, and believe in following the guidance given.
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. ―Mandruss  17:00, 1 February 2016 (UTC)
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 |newspaper=New York Times the proper rendition should be |website=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 |website=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.
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. ―Mandruss  22:14, 1 February 2016 (UTC)
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. ―Mandruss  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 Category: CS1 errors: OCLC

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

insource:/\| *oclc *= *[A-Za-z]+/

None of the links that I checked were valid.

  • Fail: a letter.
    OCLC A. {{cite book}}: Check |oclc= value (help
    )
  • Fail: number less than 1. .
  • Fail: has a space.
    OCLC 1.000 000. {{cite book}}: Check |oclc= value (help
    )
  • Pass: comma thousands separators.
    OCLC 1,000,000. {{cite book}}: Check |oclc= value (help
    )

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 (OCoLC), 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 ocm requires 8 digits:

Title.
OCLC ocm1234567. {{cite book}}: Check |oclc= value (help
)
Title. .
Title.
OCLC ocm123456789. {{cite book}}: Check |oclc= value (help
)

Prefix ocn requires 9 digits:

Title.
OCLC ocn12345678. {{cite book}}: Check |oclc= value (help
)
Title. .
Title.
OCLC ocn1234567890. {{cite book}}: Check |oclc= value (help
)

Prefix on requires 10+ digits:

Title.
OCLC on123456789. {{cite book}}: Check |oclc= value (help
)
Title. .
Title. .

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

Title.
OCLC (OCoLC)01. {{cite book}}: Check |oclc= value (help
)
Title. .
Title. .
Title.
OCLC (OCoLC)1234567890. {{cite book}}: Check |oclc= value (help
)

OCLC without prefix 1 to 9 digits:

Title. .
Title. .
Title. .
Title. .

Unrecognized prefix:

Title.
OCLC bob12345678. {{cite book}}: Check |oclc= value (help
)

Punctuation between two oclc numbers:

Title.
OCLC 12345678,2345. {{cite book}}: Check |oclc= value (help
)

Space between two oclc numbers:

Title.
OCLC 12345678 2345. {{cite book}}: Check |oclc= value (help
)

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

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

Interaction with <poem> blocks

It seems that <poem> blocks are processed before templates, meaning that {{cite journal}} and {{cite book}} only work inside them if they go all on one line. See this revision of "Lightbulb joke" 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.

Cite AV media notes comparison
Wikitext {{cite AV media notes|authorlink=Joel Selvin|first=Joel|id=FAN-30877-02|last=Selvin|location=U.S.A.|others=Creedence Clearwater Revival|publisher=[[Concord Music Group]]|title=Bayou Country [Expanded Reissue]|titlelink=Bayou Country|type=CD booklet|url=http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf|year=2008}}
Live Selvin, Joel (2008). Bayou Country [Expanded Reissue] (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. {{cite AV media notes}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)
Sandbox Selvin, Joel (2008). Bayou Country [Expanded Reissue] (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. {{cite AV media notes}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)

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.
Cite AV media notes comparison
Wikitext {{cite AV media notes|authorlink=Joel Selvin|first=Joel|id=FAN-30877-02|last=Selvin|location=U.S.A.|others=Creedence Clearwater Revival|publisher=[[Concord Music Group]]|title=Bayou Country Expanded Reissue|titlelink=Bayou Country|type=CD booklet|url=http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf|year=2008}}
Live Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. {{cite AV media notes}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)
Sandbox Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. {{cite AV media notes}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)
I would guess that because there's a title link the url-title checker is going a little haywire:
Cite AV media notes comparison
Wikitext {{cite AV media notes|authorlink=Joel Selvin|first=Joel|id=FAN-30877-02|last=Selvin|location=U.S.A.|others=Creedence Clearwater Revival|publisher=[[Concord Music Group]]|title=Bayou Country Expanded Reissue|type=CD booklet|url=http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf|year=2008}}
Live Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02.
Sandbox Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02.
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 |<param>-link= to find the first [ of a wikilink when |title=[[link label]] and |title-link=article title from which the module would produce this illegal construct:
[[article title|[[link label]]]]
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 |dead-url=no worked as you described (no archive output). I'm not sure that |dead-url=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:
{{cite web |title=Title |url=//example.com |archive-url=//example.org |archive-date=2016-02-08 |dead-url=no}}
"Title". Archived from the original on 2016-02-08. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
We already have unfit and usurped which keep the archive text output but don't link to the original url:
{{cite web |title=Title |url=//example.com |archive-url=//example.org |archive-date=2016-02-08 |dead-url=unfit}}
"Title". Archived from the original on 2016-02-08. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
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 hidden. 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#Language metadata pollutes COinS, and because this page has more watchers, I have moved this conversation from Module_talk:Citation/CS1/Feature_requests#Language 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):

<cite class="citation book">Will Ferrell. <i>La Casa de Mi Padre</i> [<i>My Father's Home</i>] (in Spanish).</cite>

to rendering

<cite class="citation book">Will Ferrell. <i lang="es" xml:lang="es">La Casa de Mi Padre</i> [<i>My Father's Home</i>] (in Spanish).</cite>

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 title (and only the title) will match the language, 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 xml:lang="..." required? Wikipedia pages are <!DOCTYPE html>.

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 validate(), argument_wrapper() (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?:
{{cite ... |title=La Casa de Mi Padre |script-title=es: |...}}
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:
{{cite book |first=Guðrún Eva |last=Mínervudóttir |author-link=Guðrún Eva Mínervudóttir |title=Fyrirlestur um hamingjuna |trans-title=Lecture on Happiness |isbn=9789979865773 |location=Reykjavík |publisher=Bjartur |date=2000 |language=is}}
.
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 xml:lang 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 |title-lang=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 lang and xml:lang attributes, in particular the paragraph beginning "Authors must not use the lang attribute in the XML namespace on HTML elements in HTML documents." In this context, "the lang attribute in the XML namespace" means xml:lang=something. Therefore, as MediaWiki serves HTML, we must not add the xml:lang= attribute to a <i> tag. --Redrose64 (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:
~ 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= documentation:

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. |author2-last=Doe |author2-first=Jane (ed.); 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 {{cite journal}}, {{cite news}}, {{cite magazine}}. Foreword authors is supported in {{cite book}} 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 main problem. 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 real, 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 |author2-first=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. (@SMcCandlish: it's like using '' instead of {{em}} or <tt> instead of <code>, both of which you have rightly deprecated in the past. Parameters, like markup, should be used semantically.)
The purpose of a citation is not to record every last minute detail of the contributions of different people to the work, but to enable readers to find a source. The templates are over-complex partly because editors have been allowed to keep adding "features" which have nothing to do with their primary purpose, which, I repeat, is to provide sufficient information (and no more) to allow readers to locate the source. Peter coxhead (talk) 15:32, 25 January 2016 (UTC)
I agree with the purpose of citations. But I thought the topic here (CS1) is citation style. That is, after citation requirements have been agreed upon, how do we proceed with presentation?
Because there has been haphazard discussion on citation requirements elsewhere, discussion on requirements creeps into this forum. It shouldn't be so, imo. There should be a more organized discussion on citation design (discovering & implementing requirements) separately from the discussion on citation formatting (presentation).
72.43.99.130 (talk) 20:19, 25 January 2016 (UTC)
  • I Oppose any attempt to remove editor from {{cite magazine}}, {{cite news}} etc. Many articles have no credited author, for example this one. --Redrose64 (talk) 19:54, 25 January 2016 (UTC)
    • Seconded. Oppose removal of editor from the templates mentioned. As an aside, most of the problems mentioned in the thread I believe could be resolved with better, clearer documentation. 72.43.99.130 (talk) 20:24, 25 January 2016 (UTC)
    It is not the usual practice to give the editor name in this situation. CMOS recommends using the magazine name in such a case.
    The reason we name the editors of collections of contributions by several authors, or of an author's work, is because it helps the reader find the book, as that is how they are typically catalogued. That doesn't apply in the case of magazines or newspapers. Kanguole 22:19, 25 January 2016 (UTC)
  • Oppose changing the templates to remove the possibility of setting an editor. Although the editor or editorial board of most journal publications should not be cited, editors are occasionally useful for journals, for instance when citing a special issue or special section of a journal that has its own separate editors. Making the templates more rigid in what they accept has the cost of making more special-case citations that cannot be properly handled by the templates (pushing people to not use the templates at all) for only a very small benefit of catching a few unusual cases where people are citing things the wrong way. It's the wrong tradeoff to take. —David Eppstein (talk) 23:26, 25 January 2016 (UTC)
    • PS I also agree with Trappist's reversion of the change to the documentation: adding "(ed.)" to values of other parameters is the wrong way to do it and should not be encouraged. —David Eppstein (talk) 00:15, 26 January 2016 (UTC)
  • I also oppose any disablement of |editor= in journal, etc. However, note that such disablement is only TM's secondary comment, that the main point is regarding Mac's documentation change that editors can be cited as authors. I also oppose that change (effectively supporting TM's reversion), though as a possible work-around it might merit discussion. ~ J. Johnson (JJ) (talk) 23:46, 25 January 2016 (UTC)
    • Fine. You can keep your precious author/editor distinction (which is often artificial or tenuous; I have books where the author went from author to "editor" between editions, simply because someone at the publisher decided to make it that way). I can concede that in most cases it's a distinction we want to preserve,
      WP:NOT#BIBLIOGRAPHY; it's exactly the same thing as giving the total page count, the address of the publisher, or hardback vs. paperback. This is not citation information. It looks superficially like attribution, but it's attribution for an organizational role, like adding a parameter for the owner of the newspaper, and its janitor. WP is not IMDb; we don't provide details on every single person associated with a "production" in any medium. That said, we s should not disable the parameter for any particular medium, since a particular piece may in fact have a direct, actual, credited-in-the-specific-piece editor who needs attribution (and whose editorial presence in the piece may considerably enhance its reliability, I might add). We don't need to kill the parameter, we need to clarify what not to do with it. That much of what I added to the docs should be restored.

      At any rate, it looks like me like neither of the issues I attempted to address in what I wrote in the doc page have been addressed. We do need to discourage the misuse of the editor field to identify corporate administrators, and we do need to distinguish between two different levels of revisers of an original author, especially when the intermediary one was a very significant contributor to the work. Many "editors" are actually posthumous co-authors, and may even be responsible for much more of the content than the original author, yet may themselves be retired from the project in question (or deceased) for some time, with some new editor (actually acting as an editor per se or a new layer of co-author). This sort of thing comes up very frequently in style guides, as just one topical example. What is presently called Fowler's Modern English has much less of H. W. Fowler's original content in it than people think (I know; I have the 1st ed., too). Same goes for the ones we call in short form Turabian and Hart's, and Gowers. Sometimes the editions with different editors are cumulative, sometimes they are not, and this can have actual RS implications – particular editors are more reputable than others, and even particular editions by the same editor may be (and this is not always chronological).  — SMcCandlish ¢

       ≽ʌⱷ҅ʌ≼  01:29, 9 February 2016 (UTC)

Just for clarification, the change that Editor SMcCandlish is discussing refers to how cs1|2 handles editors when |chapter= is set (1) and when it is not set (2):
  1. Darwin, Charles (1909). "Laws of Variation". In Eliot, Charles W (ed.). The Origin of Species. New York: P F Collier and Son.
  2. Darwin, Charles (1909). Eliot, Charles W (ed.). The Origin of Species. New York: P F Collier and Son.
When chapter is set (1) cs1|2 makes it appear that Darwin is one of possibly several authors of an anthology edited by Eliot when, in fact, Darwin is the only author.
The question then is: how should we instruct cs1|2 to render |editor= using the form in (2) when |chapter= and |editor= are set and when |authorn= is/are the author(s) of the whole work?
The answer to the implementation question will determine, I think, how the documentation should be changed so perhaps that topic should be tabled until the implementation decision is taken.
Trappist the monk (talk) 13:43, 9 February 2016 (UTC)

Proposal: editor, cite encyclopedia

  1. Remove the text "in {{{editor}}}" from all templates except {{cite encyclopedia}}; keep the display of editor role (ed.) in all templates
  2. Rename {{cite encyclopedia}} into {{cite compilation}} (or similar); keep {{cite encyclopedia}} as an alias
  3. Activate {{{contributor}}} in proposed {{cite compilation}}
Thank you. 72.43.99.146 (talk) 15:23, 26 January 2016 (UTC)
On first glance, that might actually do it, as long as there's not some new "you're abusing the metadata" complaint about using |contributor to deal with multiple levels of editor–co-authors. Is there any sort of potential fallout from this? Besides the obvious one: Many collaborative books (e.g. scholarly volumes of journal-style papers by different authors, under an editor [or plural] who is actually an editor, not a corporate functionary, like this [1]) are already coded in {{cite book}} with the expectation of the "in {{{editor}}} (editor)" output, not just "{{{editor}}} (editor)". I have to ask if there any actual harm at all in that drop-the-"in" conversion? While the "in" format (in one exact stylization or another) is very common, it's not universal. In a quick comparison of American citation styles (from Cite Right, Charles Lipson, 2006, and "Purdue OWL Citation Chart" 2014), there's a clear split between how to style an editor of a book when just citing the book, or a chapter by someone else in an edited book. I've summarized these, splitting the former from the latter with a "/", and giving some indication whether the editor citation starts a new sentence or not, and how it ends (the quotation marks are bracketing what I'm quoting, not part of the citation style):

MLA: "Ed. Kathleen A. Hauke." or "Hauke, Kathleen A., ed.," depending on edition / "In. [title], ed. Kathleen A. Hauke." or "[chapter]. [title]. Ed. Kathleen A. Hauke." (emphasis added – note the lack of "[i|I]n", and that's from the 2014 source), depending on edition
APA: "K. A. Hauke (Ed.)." / "In K. A. Hauke (Ed.),"
CMS: "Edited by Kathleen A. Hauke." / "In [title], edited by Kathleen A. Hauke,"
Chicago/Turabian: "Kathleen A. Hauke, ed.," / "[I|i]n [title], edited by Kathleen A. Hauke,"
AAA: "Kathleen A. Hauke, ed." / In [title]. Kathleen A. Hauke, ed."
CSE & AMA: "Hauke KA, editor." / In: Hauke KA, editor. [title]."
ACS: "Hauke, K. A., Ed.;" / "In [title]; Hauke, K.A., Ed.;"
AIP: "K. A. Hauke, editor," / ", in [title], edited by K. A. Hauke (...)."
Astro. (no single standard, but fairly consistent): ", ed. K. A. Hauke (...)" / ", in [title], ed. K. A. Hauke (...)."
Maths. (not consistent): "K. A. Hauke (ed.)," or "K. A. Hauke (ed.):" or "In: K. A. Hauke (ed.)," / ", in [title], K. A. Hauke, ed.," or "In: K. A. Hauke (ed.), [title]."
Bluebook & ALWD: "(Kathleen A. Hauke ed, ...)." / ", in [title] (Kathleen A. Hauke ed, ...)." (Bluebook italicizes in, ALWD does not).

So, all of these use some form of "in" except some editions of MLA. But at least that's proof it's not effectively mandatory to treat it this way. I've not yet gone through MHRA and other non-American sources on this question. I'm pretty sure there are more that do not expect an "in". Anyway, I actually need to verify that the 2014 Purdue source is correct on MLA dropping the "in". I actually just got the latest MLA guide last month, and have not perused it yet, but my eyes hurt, so I'll look into it later.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:51, 9 February 2016 (UTC)

There are differences in the roles of editors of single-author books and editors of works from multiple authors. In the latter case, the term editor often encompasses the work of a compiler (somebody who chooses who and why will be included in the work) and also somebody who often vets the contributions for relevance/topicality relative to the particular "compilation". Although a “compilation” editor (for lack of better term) may not be involved in fact-checking (esp. in science publications) s/he should have acquired a certain level of confidence regarding the veracity of the contributions. It seems that in many situations, a compilation editor does meaningful work, which affects the end-product. Less, or not at all so, with single-author books. So the text “in {{{editor}}}” would be justified in the former case. 65.88.88.127 (talk) 20:57, 9 February 2016 (UTC)
I know there are differences; that's why I carefully showed how these citations styles specify the two distinct cases. [sigh]  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:41, 10 February 2016 (UTC)
In order not to have recurring useless discussion about style, the doc should make clear why the editor may be presented differently in {{cite book}} vs. the proposed {{cite compilation}}. It's not enough that we know. Letting all Wikipedia users know (through the doc) that there is a valid rationale behind the difference in formatting, would perhaps rid this page of unnecessary debate. 65.88.88.127 (talk) 16:12, 10 February 2016 (UTC)

eISBN?

It seems the number of works with dual numbers (print & electronic ISBN) or just an eISBN (when published solely as

e-books) is increasing. 72.43.99.130 (talk
) 20:37, 2 February 2016 (UTC)

Apparently, there is no such thing.
Trappist the monk (talk) 20:48, 2 February 2016 (UTC)
Some publishers are using the term anyway (in edition notices of both print and digital books), but the acronym is not important. How to differentiate, if need be? It seems to me that digital versions of books increasingly differ from print versions, sometimes with "enhanced" features. If eISSN is justified, "eISBN" (or whatever) should be considered. 208.87.234.201 (talk) 01:29, 3 February 2016 (UTC)
Not necessary per
WP:NOT#BIBLIOGRAPHY.  — 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. |type=e-book and |edition=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 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! {{u|

Talk
} 04:42, 11 February 2016 (UTC)

I don't think it was the correct fix. Your cite uses |date=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:
{{cite book |last1=Quiller-Couch |first1=Sir Arthur |title=On the Art of Writing: Lectures Delivered in the University of Cambridge, 1913–1914 |edition=Online |url=http://www.bartleby.com/190/ |access-date=3 March 2012 |date=2000 |orig-year=1916 |publisher=Bartleby.com |chapter=XII. On Style |chapterurl=http://www.bartleby.com/190/12.html |at=¶6}}
Quiller-Couch, Sir Arthur (2000) [1916]. "XII. On Style". On the Art of Writing: Lectures Delivered in the University of Cambridge, 1913–1914 (Online ed.). Bartleby.com. ¶6. Retrieved 3 March 2012. {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help)
Trappist the monk (talk) 11:15, 11 February 2016 (UTC)

author-link effciency

It would be helpful if |author[N]-link=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)

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 |author-link=y is coded. ―Mandruss  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. ―Mandruss  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 |author-link=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 n 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.
I assume the point of SMcCandlish's proposal is that |last=Ishihara|first=Shintaro|author-link=Shintaro Ishihara is significantly more difficult and time-consuming for the average, non-techy user than |last=Ishihara|first=Shintaro|author-link=y, 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. ―Mandruss  20:50, 10 February 2016 (UTC)
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. ―Mandruss  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 |authorn-link=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. ―Mandruss  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? --Redrose64 (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 |author-link=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. ―Mandruss  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

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.[1]
The real source is a Time magazine article, fully cited using |ref=harv.[2]

References

  1. ^ Baker 2013, p. 34.
  2. ISSN 0040-781X. Retrieved 2016-02-05. {{cite news}}: Invalid |ref=harv (help
    )

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

While the use of "{{sfn|Baker|2013|p=[http://www.example.com 34]}}" 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.
  • {{cite news|title=Headline|date=February 8, 2016|newspaper=[[Los Angeles Times]]|publisher=[[Tribune Publishing]]}}
  • "Headline". Los Angeles Times. Tribune Publishing. February 8, 2016.
(although I would normally omit the publisher in this case). —David Eppstein (talk) 00:54, 9 February 2016 (UTC)
I normally use {{cite web}} 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 {{cite web}} 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:
"The Purdue OWL: Citation Chart" (PDF). Online Writing Lab. Purdue University. pp. 4–5.
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#COinS.
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. --Redrose64 (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. ―Mandruss  15:27, 9 February 2016 (UTC)
  • Agreed with David. Using {{cite web|title=Aliens Invade Roswell|...|website=latimes.com|publisher=''[[Los Angeles Times]]''}} 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 {{cite news|title=Aliens Invade Roswell|...|work=[[Los Angeles Times]]|edition=online}}: Doeh, Janet (April 1, 2016). "Aliens Invade Roswell". Los Angeles Times (online ed.).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:24, 10 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)

I don't know, maybe because they are news? ―Mandruss  19:06, 10 February 2016 (UTC)
Web news. SLBedit (talk) 19:36, 10 February 2016 (UTC)
News nonetheless. Perhaps you wish to propose {{
WP:BIKESHED. ―Mandruss 
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, {{cite web}} would probably be more appropriare. That doesn't mean you can't use {{cite news}} for the items that are news. You don't have to use the same template for everything on a given site. ―Mandruss  22:55, 10 February 2016 (UTC)
Okay. SLBedit (talk) 23:00, 10 February 2016 (UTC)
{{cite news}} says, right at the top,
This
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. --Redrose64 (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 {{cite magazine}} 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 {{cite news}} and since it's not the actual newspaper but its magazine, use e.g. |magazine=The Sunday Times Magazine. --Redrose64 (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: {{cite news|department=Magazine|newspaper=Newspaper}}. 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. --Redrose64 (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:

  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.

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  01:33, 11 February 2016 (UTC)

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 {{cite map}}; discussion
  2. query and fragment delimiters in split_url(); discussion
  3. language code 'no' spoof no longer required; discussion
  4. presentation tweaks; discussion
  5. bug fix in link_title_ok(); discussion
  6. add language code 'be' to format_script_value();

to Module:Citation/CS1/Configuration:

  1. oclc error checking; discussion
  2. presentation tweaks; discussion

to Module:Citation/CS1/Date validation:

  1. tweak get_month_number() and is_valid_month_season_range(); better code practices;

to Module:Citation/CS1/Identifiers:

  1. oclc error checking; discussion

Trappist the monk (talk) 12:50, 14 February 2016 (UTC)

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=:
{{cite book |title=Title |date=2016 |orig-year=some text in orig year that clearly isn't a year}}
Title. 2016 [some text in orig year that clearly isn't a 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)

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 |edition=3rd, but just |edition=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 |edition=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 |edition=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 |edition=3rd? After all, if you'd enter it as |edition=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)

|date=Spring–Summer 2015. We convert the slash to an en dash for consistency with our MOS.
  • Author (Spring–Summer 2015). "Article". Magazine. {{cite magazine}}: |author= has generic name (help)
Imzadi 1979  01:57, 17 February 2016 (UTC)
Imzadi1979 (talk · contribs)Thank You!Naraht (talk) 13:48, 17 February 2016 (UTC)
I wonder whether seasons should be used? They are frowned upon 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
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)
@
65.88.88.126: 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)
@
65.88.88.126:So where is the appropriate place to discuss it/make the policy more clear?Naraht (talk
) 08:52, 18 February 2016 (UTC)
@ 09:47, 18 February 2016 (UTC)
@Naraht: the MOS has been updated to make clear that the season in an issue date is perfectly acceptable: [2] Imzadi 1979  23:49, 18 February 2016 (UTC)
@Imzadi1979: Thank you a lot!Naraht (talk) 00:50, 19 February 2016 (UTC)