Jump to content

Help talk:Citation Style 1/Archive 11

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 04:14, 12 March 2016 (Archiving 5 discussion(s) from Help talk:Citation Style 1) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 5Archive 9Archive 10Archive 11Archive 12Archive 13Archive 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 {{cite news}} for e.g. 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. OCLC 0.
  • 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. OCLC 12345678.
Title. OCLC ocm123456789. {{cite book}}: Check |oclc= value (help)

Prefix ocn requires 9 digits:

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

Prefix on requires 10+ digits:

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

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

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

OCLC without prefix 1 to 9 digits:

Title. OCLC 1.
Title. OCLC 0001.
Title. OCLC 123456789.
Title. OCLC 1234567890.

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)

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}}
Mínervudóttir, Guðrún Eva (2000). Fyrirlestur um hamingjuna [Lecture on Happiness] (in Icelandic). Reykjavík: Bjartur. ISBN 9789979865773.
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, iff it actually affects the metadata accuracy in COinS (which is a rather blunt instrument). But that still leaves us with the question of what do in cases like what I outlined in my "rogue" documentation change.

      To address some of the comments above: For the record, I do not agree that the sole purpose of these citations is identifying the source so people can find it; that's the primary purpose. As anyone with any familiarity with academia knows, it also has a lot to do with proper attribution, credit where due. And this is actually important for WP-internal reasons, like being exact in our attribution of claims, especially primary ones.

      As someone commented above, yes, it is true that we do not cite managing editors of newspapers and such, except possibly under unusual circumstances. (When would we ever do that? Give a concrete example. Even if there's some kind of "Statement by the Editor" piece, the "editor" in that case is actually the author, and would be cited as such.) If you are adding the names of the general or managing editorial staff at a newspaper or journal as |editors, you are not doing citations right, you're engaging in 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:SAYWHEREYOUGOTIT. Just use the ISBN of what you're actually reading. If you want to add a note that it's also available in a different-medium edition with a different ISBN, you could do so between the template and the </ref>. 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#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)