Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite speech)
Jump to: navigation, search
the Wikipedia Help Project (Rated B-class, High-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the help menu or help directory. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article B  This page does not require a rating on the project's quality scale.
 High  This page has been rated as High-importance on the project's importance scale.

Update to the live CS1 module week of 2014-08-24[edit]

After the end of this week I propose to update:

Module:Citation/CS1 to match Module:Citation/CS1/sandbox (diff)
Module:Citation/CS1/Configuration to match Module:Citation/CS1/Configuration/sandbox (diff)
Module:Citation/CS1/Whitelist to match Module:Citation/CS1/Whitelist/sandbox (diff)
Module:Citation/CS1/Date validation to match Module:Citation/CS1/Date validation/sandbox (diff)

This update changes the things: in Module:Citation/CS1:

  1. Normalize LCCN values before validation (discussion)
  2. Identify and categorize citations with |firstn= / |lastn= mismatch (discussion) Undone. See discussion.
  3. arXiv validation (discussion)
  4. change |CitationClass= tests to require unspaced class names for {{cite DVD notes}} and {{cite AV media notes}} (discussion)
  5. fix bug in |vanc= handling (discussion)
  6. instances of four consecutive spaces converted to tabs

in Module:Citation/CS1/Configuration:

  1. Identify and categorize citations with |firstn= / |lastn= mismatch
  2. Add hyphenated parameter name aliases (discussion)
  3. instances of four consecutive spaces converted to tabs
  4. override <code>...</code> css formatting for error messages (discussion)

in Module:Citation/CS1/Whitelist:

  1. Add hyphenated parameter name aliases

in Module:Citation/CS1/Date validation:

  1. Add support for "Winter YYYY–YY" (discussion)
  2. Add support for whole date range validation (dmy - dmy and mdy - mdy formats) (discussion and discussion 2)

Trappist the monk (talk) 13:59, 17 August 2014 (UTC)

Hooray! Our last update was at the end of March. A reminder that, after the update, if you see pages that still show an error message for something that should no longer show an error message, try purging (to refresh the display of the page) or null editing (to remove category membership) the page to fix it. There is more information in this VPT thread. – Jonesey95 (talk) 20:03, 17 August 2014 (UTC)
Trappist the monk I'm trying to modify the sandboxes to include the corrections for {{cite podcast}}; what's the problem?—D'Ranged 1 VTalk 19:52, 18 August 2014 (UTC)
It has been my practice to freeze new changes to the sandbox from the time I announce the update to the live module so that new changes don't disrupt seemingly settled changes. It also gives editors another chance to point out my failings before an update affects untold numbers of pages. As you can see from your post below, that last bit works.
Because you hadn't replied to my last post at Transcript parameter for cite podcast by the time I announced this update, I left it out.
Trappist the monk (talk) 21:44, 18 August 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Additionally, the current Module:Citation/CS1/Configuration/sandbox is rendering |id= erroneously as a Usenet ID; |publisherid= was deprecated in favor of using |id=. Wouldn’t it be easier to create a new |usenet= parameter?—D'Ranged 1 VTalk 20:25, 18 August 2014 (UTC)

Template Markup Renders
Example 1
  live {{Cite AV media notes |title=Artist Live! |others=[[Artist]] |year=2000 |url= |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles |accessdate=July 2, 2014}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. Retrieved July 2, 2014. 
  sandbox {{Cite AV media notes/sandbox2 |title=Artist Live! |others=[[Artist]] |year=2000 |url= |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles |access-date=July 2, 2014}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. Retrieved July 2, 2014. 
Example 2
  live {{Cite AV media notes |title=Artist Live! |titlelink=Album Title |others=[[Artist]] |year=2000 |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. 
  sandbox {{Cite AV media notes/sandbox2 |title=Artist Live! |title-link=Album Title |others=[[Artist]] |year=2000 |first=Malcolm |last=Johnson |page=1 |type=Liner notes |publisher=Arid Publications |id=Catalog no. K2145 |location=Los Angeles}} Johnson, Malcolm (2000). Artist Live! (Liner notes). Artist. Los Angeles: Arid Publications. p. 1. Catalog no. K2145. 
The Usenet problem appears to be caused by new code in Configuration/Sandbox that starts with ['USENETID'] = {. Also in the Module itself, search for the new code beginning with -- special case for cite newsgroup which uses |id= for a usenet article or post idJonesey95 (talk) 20:32, 18 August 2014 (UTC)
This discussion about migration of {{cite newsgroup}} was archived without answering the question of whether to use a new parameter, |message-id=, instead of |id=. Maybe that new parameter is needed. – Jonesey95 (talk) 21:15, 18 August 2014 (UTC)
Right, forgot about this half-done change. Thanks for the reminder. I think that I'll comment-out the relevant portions so that the rest of the update can proceed.
Trappist the monk (talk) 21:44, 18 August 2014 (UTC)

Done. In the process I discovered that the documentation for the old style arxiv identifiers does not mention versioning as the new style identifiers do. So, I wrote the original test so that versioning was only allowed in the new style. Turns out that old style identifiers may have versioning. I've fixed both the sandbox and the live versions of the module to correct this error.

Trappist the monk (talk) 11:55, 24 August 2014 (UTC)

Documentation needed[edit]

We need documentation sections on Help:CS1 errors for the new arXiv and first name / last name errors. Does anyone have a sandboxed version of those new sections yet? If not, I'll start drafting them in commented sections on the page.

The styling change for the error message means that we will need to re-style the error messages on the Help page as well. Is there a clever way to do this for the whole page, or do we need to edit each instance of code individually? – Jonesey95 (talk) 20:40, 18 August 2014 (UTC)

On my list of things to do before the update but I won't turn away willing help. I am unaware of any clever tricks except a change to common.css (which I don't think will fly). So, each <code>...</code> in the example error messages in Help:CS1 errors has to become <code style="color:inherit; border:inherit; padding:inherit;">...</code>.
Trappist the monk (talk) 21:44, 18 August 2014 (UTC)
Error message style in Help:CS1 errors done.
Trappist the monk (talk) 21:59, 18 August 2014 (UTC)
I have added commented documentation to the Help page. I think it will look right when it is uncommented, but I am not sure. Feel free to tweak my wording if it does not make sense; consider my work a first draft. – Jonesey95 (talk) 17:40, 19 August 2014 (UTC)
And I've rather heavily edited them. I split the author/editor list errors into two descriptions because they really are two separate conditions. I'm wondering if they shouldn't also have separate categories. Have a look.
Trappist the monk (talk) 14:51, 20 August 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Your edits look fine to me. I might tweak the wording a bit after it goes live and I can see it in context, but I do not expect to make major changes.

I don't think we need separate categories. In both cases, |lastn= is missing. That's the fundamental error. Now that there are two sections, however, to which section will the "help" link direct editors?

I do think that a missing editor should report "missing |editor-lastn=" instead of "missing |lastn=". The current error message is "missing |lastn=", which is confusing and not strictly accurate.

Cite book compare
{{ cite book | editor1=Editor 1 | editor4=Editor 4 | title=Title | editor2=Editor 2 | displayeditors=29 }}
Old Title.
Live Editor 1; Editor 2 (eds.). Title. 
Sandbox Editor 1; Editor 2; Editor 4 (eds.). Title.  Missing |last3= in Editors list (help)

Is that difficult or easy to modify? – Jonesey95 (talk) 15:39, 20 August 2014 (UTC)

That's why the error messages identify the particular list where the error was found and also why I added the blurb about the error messages using a bit of shorthand. I'm sure that we can tweak the error messages to get what we want but I'd rather not do that just now. We can certainly refine them before the next update.
Trappist the monk (talk) 16:49, 20 August 2014 (UTC)

Rendering problem with right-to-left language and trans-title[edit]

Trappist the monk and others who might know the details of the Lua code: please see the following thread at VPT: Wikipedia:Village pump (technical)#Citations with title parameter in rtl language.2C beginning with numbers: Display issue and workaroundJonesey95 (talk) 16:32, 18 August 2014 (UTC)

That discussion now in archive 129.
Trappist the monk (talk) 14:20, 13 September 2014 (UTC)

self-referential authorlinks[edit]

Is there a guideline which recommends using the authorlink parameter to refer to the same article that the cite book tag appears in? In this edit summary, Damiens.rf contends, "this parameter IS to be used even in the case of the subject's being the author. It would give an error otherwise." I don't see why this would be the case, as such a usage does not fall within the normal recommendations on self links. Nick Number (talk) 18:18, 21 August 2014 (UTC)

The link is optional in all cases, and is merely a convenience link. --  Gadget850 talk 18:31, 21 August 2014 (UTC)
It is neither recommended nor not recommended; certainly not required as Editor Damiens.rf seems to imply. No errors will be incurred in either case. Including |authorlink= can be a minor benefit when editors copy CS1 templates from one article to another. I see no other benefit or harm.
Trappist the monk (talk) 18:39, 21 August 2014 (UTC)
I double checked: The one issue is that a link to the current page is bolded:
Help talk:Citation Style 1. title. 
I am sure we discussed adding CSS to fix this. --  Gadget850 talk 19:36, 21 August 2014 (UTC)
Wikilinks that point to the page you are reading are bolded and not linked. I don't know where or when that stylistic decision was made, but it seems to me that we should not override it in one small place in the project. – Jonesey95 (talk) 20:27, 21 August 2014 (UTC)
@Jonesey95:, you mean that article should use the bolded and not the linked version, right?
@Trappist the monk:, I see the bolding itself as a benefit, since it works as a useful interface hint. It points out that the reference's author is the subject of the article. --damiens.rf 16:48, 22 August 2014 (UTC)
I don't think that either linking or bolding is useful. By using the |authormask= parameter, the citation templates can show a pair of em-dashes instead, see John Marshall (railway historian)#Selected publications by John Marshall. --Redrose64 (talk) 18:49, 22 August 2014 (UTC)
|authormask= can only be used in bibliographies or shortened footnotes where the order of the list can be controlled. --  Gadget850 talk 22:36, 22 August 2014 (UTC)

So, should we use authorlinks for the article subject or avoid it? --damiens.rf 03:33, 28 August 2014 (UTC)

I'd reiterate my preference that, following the existing guideline in Help:Self link, self-referential links should be avoided. There's no reason to make a specific exception in the case of authorlinks. Nick Number (talk) 21:41, 2 September 2014 (UTC)
  • @Damiens.rf: I respect your position and your sincerity, but I've got to agree with Nick Number and others above. The bolding overemphasizes that the reference's author is the subject of an article, in a way that some of us find extremely distracting. It doesn't conform to the norms in Wikipedia. In previous discussions of self-links, there was a consensus that bolding was useful in navigation boxes. However, in the context of citations and references, it isn't commonplace, and I have not found examples (by other editors) where an authorlink or subjectlink is intentionally used for emphasis that the reference's author is the subject of the article. I believe that an ordinary reader will not need that visual cue in order to recognize who wrote the reference. To the extent that bolding might provide a visual suggestion that the credibility of the reference could be perceived as questionable, I trust that the average reader can recognize the author's name, and the potential self-interest of the author, and can use their own judgment about that without any need for bolding. Lwarrenwiki (talk) 22:37, 2 September 2014 (UTC)
    • I didn't know the was just a side effect of it being a self-link. I thought it was a decision made by the authors of the cite template. Things make more sense to me now. --damiens.rf 15:29, 3 September 2014 (UTC)

Symbol question.svg Question: What about citations that are stored on templates, rather than articles (e.g. {{cite doi/φ}}, {{cite isbn/ψ}}), and that might be transcluded ({{cite doi|φ}}) in multiple articles? Is there a way, at {{cite doi/φ}}, of having |authorlink1= only/not appear if Condition A & Condition B, or whatever? It Is Me Here t / c 10:20, 10 September 2014 (UTC)

I'm pretty sure that I'm not sure what it is that you are asking. What are the undefined Conditions A and B? What do your example redlinked templates have to do with CS1?
Trappist the monk (talk) 11:54, 10 September 2014 (UTC)
OK, so take Template:Cite doi/10.3897.2Fzookeys.31.261:
Stümpel, N.; Joger, U. (2009). "Recent advances in phylogeny and taxonomy of Near and Middle Eastern Vipers – an update". ZooKeys 31: 179–191. doi:10.3897/zookeys.31.261. 
Imagine that we had articles on both Nikolaus Stümpel and Ulrich Joger, and that that template had |author1link=Nikolaus Stümpel and |author2link=Ulrich Joger, and that it was transcluded on Nikolaus Stümpel, Ulrich Joger, and Viper. Would it be possible for the authorlink to appear in the template's citation IFF the template were not being transcluded in the article that the authorlink pointed to? So, Nikolaus Stümpel would just show "Stümpel, N." (no links, no bolding), but "Joger, U."; etc. (I know it's not a perfect example, since the authors' articles don't exist, but imagine they did.) It Is Me Here t / c 12:18, 10 September 2014 (UTC)
I think that it can be done in the module. The module has access to the current page information and uses that for proper categorization, COinS, and |language= support. I think that we can pass the current page name to listpeople() where author links are processed and either allow or disallow linking.
Trappist the monk (talk) 12:50, 10 September 2014 (UTC)
I've modified Module:Citation/CS1/sandbox so that it doesn't link the author's name if the link would be self-referencing. Here, this example citation from Angela P. Harris links her name. If you copy the citation to her page and preview it, her name isn't linked.
{{cite book/new | last1 = Harris | first1 = Angela P. |authorlink=Angela P. Harris | last2 = Bartlett | first2 = Katharine | title = Gender and law: theory, doctrine, commentary | publisher = Aspen Law & Business | location = New York | year = 1998 | isbn = 9781567067408 }}
Harris, Angela P.; Bartlett, Katharine (1998). Gender and law: theory, doctrine, commentary. New York: Aspen Law & Business. ISBN 9781567067408. 
|editorlink= should work the same way though I haven't tested it yet has been tested and works the same way.
I don't know what happens if |authorlink= links to a redirect (either with this fix or without it). If anyone knows of an author or editor who has redirect pages we can test that. If I set author name and page name to lower case before doing the compare that will account for differences in capitalization.
Trappist the monk (talk) 18:16, 10 September 2014 (UTC)
Elwyn Brooks White is a redirect to the page for author E. B. White. – Jonesey95 (talk) 19:10, 10 September 2014 (UTC)
Setting |authorlink=Elwyn Brooks White caused both the live and sandbox versions of the module to render a non-bold link to Elwyn Brooks White. This is not surprising and as long as they both act the same way I'm content.
Is this 'feature' worth keeping? There has been some discussion of the topic at Module talk:Citation/CS1/Feature requests#Check for wikilink to current page.
Trappist the monk (talk) 23:00, 10 September 2014 (UTC)
Personally, I think it's a very good feature, so thank you for taking the time to develop it. I can confirm that it works, not just for |authorlink=, but also for |authorlinkn= and |editorlinkn=. It Is Me Here t / c 11:05, 11 September 2014 (UTC)

Time to show date error messages?[edit]

Currently, errors categorized in Category:CS1 errors: dates are hidden, pending fixing of as many as reasonably possible by a bot. The hiding decision was a result of this RFC.

BattyBot task 25 has been processing Category:CS1 errors: dates periodically for about eight months now. When BattyBot is not running, date errors are added to the category at a rate of hundreds per week, maybe more. The category population was about 100,000 when BattyBot started running; it is about 60,000 now, and would be tens of thousands higher than 100,000 if not for the bot's work.

I have been working with GoingBatty, the bot's operator, to add more patterns to the list of bot-fixable errors. You can see the latest round of proposed fixes on GoingBatty's talk page, and there are many previous rounds of this exercise in that page's archives.

I believe that we have reached a point of diminishing returns with the bot, and that the bot has "run to sufficient completion" (quoting the RFC closure decision). I believe that the date error messages should be exposed by default to editors when the live version of the citation module is next updated. Thoughts? – Jonesey95 (talk) 02:30, 26 August 2014 (UTC)

I agree that it's unlikely we'll find many more patterns that will significantly reduce the number of errors, although suggestions will always be appreciated. I think our next task is to prepare ourselves (and others) for the onslaught of questions and concerns that will be raised when these errors are visible to all.
  • People will see a "(help)" link in the article, which will take them to Help:CS1 errors#bad date. Are there any improvements needed here, such as:
    • Maybe mentioning why other text in the date field is bad, and providing a link to a simplified explanation of WP:COinS with examples?)
    • A link to Wikiblame to help research accessdates?
  • From there, people will see a link to Wikipedia:Help desk. We should announce there (and where else? WP:VP/T?) when the errors are scheduled to be turned on, and ensure we have extra people checking there.
  • People may also follow the link to Help:Citation Style 1#Dates. Are there any improvements needed here?
  • What guidance will we give people who have valid dates that are flagged as false errors?
Thanks! GoingBatty (talk) 03:56, 26 August 2014 (UTC)
Do you know of any valid dates that are being flagged as errors?
Trappist the monk (talk) 13:00, 26 August 2014 (UTC)
Seasons (e.g., winter 2013) are being flagged as errors if they are capitalized, but seasons should not be capitalized. This is actually a subtle issue. If the separator between citation elements is a period, and each clause separated by a period is punctuated as a sentence, and if the season is the first word in one of these elements, then it should be capitalized. But if the separator between elements is a comma, or if the season is not the first word in the element, it should not be capitalized. Finally, neither our dates nor the date element in the APA style, is properly punctuated as a sentence, so it isn't clear that seasons should ever be capitalized. I'll poke around to see what other styles do. Jc3s5h (talk) 13:13, 26 August 2014 (UTC)
To clarify: seasons that are not capitalized are flagged as errors.
In the CS1 citations, the separator between elements is a period. In CS1 citations, season dates begin with the season. So clearly in CS1 citations, the season portion of a season date shall be capitalized.
So is your question: What should we do in the {{citation}} template citations where the separator between elements is a comma? And as a corollary: what should we do when CS1 citations override the period separator with some other character?
My answer to those is: nothing different. The element should take precedence over punctuation because the element is the important part. The element is not like the element type indicator words 'retrieved', 'archived', etc.
In the magazine and journal world, do those periodicals that use season dating capitalize the season on the cover of each issue? My experience is that they do; excepting those hipster periodicals that don't capitalize stuff for stylistic reasons and just because they're cool.
Seasons in dates in CS1 citations are roughly synonymous with months in dates. As such they should be treated in the same fashion.
Trappist the monk (talk) 14:37, 26 August 2014 (UTC)
I checked the APA Style Blog. Their advice is

If the periodical uses a season with the year, put the year, a comma, and the season in parentheses (2008, Early Spring).

But I think this requires some consensus; we don't automatically follow other style guides. The distinction between the period and comma separator still applies. Jc3s5h (talk) 13:20, 26 August 2014 (UTC)
APA style dates are not supported by MOS:DATE and in the example you've posted, the season is capitalized.
Trappist the monk (talk) 14:37, 26 August 2014 (UTC)
The last time I asked about unhiding hidden error messages, I got no real support. I remain in favor of showing error messages so I support showing the date error messages at the next CS1 update.
Trappist the monk (talk) 13:00, 26 August 2014 (UTC)
BattyBot's latest run, which incorporated the new fixes linked above, fixed only 500 articles, out of the 60,000 in the category, and many of those articles had errors introduced between the bot's last run (which finished a few days ago) and this one. I think the bot has reached a point of substantial completion and we have met the conditions of the RFC.
GoingBatty makes some good suggestions above. Let's make sure our documentation is in order before the next code update. I have tweaked the help text a bit already. – Jonesey95 (talk) 13:42, 27 August 2014 (UTC)
I think it is a bad idea to enable display of 60,000+ error messages at a stroke (I assume we're talking about just Category:CS1 errors: dates not Category:Pages using citations with accessdate and no URL‎ too). The intent can only be that they should all be fixed, but the sheer size of the task is demoralising and the payoff is uninspiring. Preparing thoroughly would be essential but not necessarily sufficient. I think it is also important to be seen to have prepared (What is the effort required? How long will it take? Why is that a favourable cost/benefit ratio?), and to have considered other options (Are |date= and |accessdate= equally important? Could we focus on probable typos over incorrect style? Do we really want to enforce MOS:BADDATEFORMAT regarding dd-mm-yyyy and mm-dd-yyyy? What about trading Category:CS1 errors: dates for Category:Pages with citations having bare URLs‎ and Category:Pages with citations lacking titles‎?). To try to understand some of this better I started my own analysis of the remaining errors here which may be of interest (eg help should address the most common errors first). Is that analysis worth taking further (the sample size is currently far too small), or is there a better analysis already available? I realise some of this has been covered in the past (possibly multiple times) but I find it hard to get a handle on what is agreed, what is still controversial, and what has not been discussed.TuxLibNit (talk) 20:33, 1 September 2014 (UTC)
@TuxLibNit: Thanks for putting together this analysis. Some comments:
  • I've updated my bot's code to fix mm/dd/yy where "dd" > 12 and "yy" = 13 or 14.
  • The bot can be updated to change undated to n. d., but I was hoping that CS1 would be changed so that undated would be acceptable.
  • While my bot normally fixes July/August 2010, it did not in this case because of the (unnecessary) brackets within the citation template.
  • 1997-98 needed to be changed to 1997–98.
  • Ministry of Defense (Kuwait) contained |date=May–June 2004|year=84|volume=3, which needed to be changed to |date=May–June 2004|volume=84|issue=3
  • My bot will now fix Octrober, and fixed all five existing instances
  • I had already updated the bot's code to not create ranges such as Winter 2003–1904, and fixed all existing instances.
The rest are misuses and/or typos that can be fixed manually, and the red error will help editors to notice the issues so they can be fixed. GoingBatty (talk) 21:43, 1 September 2014 (UTC)
I've manually fixed as many of the articles that TuxLibNit identified as I could. I would appreciate if others could provide input on the validity of using undated (see above) and work on fixing the following articles:
Thanks! GoingBatty (talk) 15:54, 4 September 2014 (UTC)
Re "undated", here is a previous discussion. Style guides (at least Chicago and MLA) say that "n.d." should be used, but I think that abbreviation is needlessly obscure. I think that "undated" or "no date" should be allowed. I would suggest taking this to MOS or a wider forum, but I have been told recently that MOS is not the right place for citation-specific discussions. A few editors are fond of reminding us that nearly any consistent citation style may be used, so can we just be bold and decide that "undated" is part of CS1's consistent citation style? That would be my preference. – Jonesey95 (talk) 16:44, 4 September 2014 (UTC)
As far as undated goes, if we're going to have a style, we should follow it. If you want to let folks do their own thing, just remove all the requirements from this page and scrap all the error messages and bots. Jc3s5h (talk) 16:42, 4 September 2014 (UTC)

Is there a decision here? If not, what about some of the other hidden error messages?

Category:Pages using citations with format and no URL – 2649 pages
Category:Pages using citations with old-style implicit et al. – 248 pages
Category:Pages using citations with old-style implicit et al. in editors – 1167 pages

or, dare I even suggest it:

Category:Pages containing cite templates with deprecated parameters – 27,815 pages (down from 163,762 pages on 4 January 2014)

Trappist the monk (talk) 12:50, 15 September 2014 (UTC)

Nobody has disagreed with the statement that BattyBot has run to substantial completion, so I believe we should show the date error messages.
I believe that we should also show the deprecated parameter errors. Monkbot and BattyBot have removed the vast majority of errors from this category (its population has decreased from 164,000 articles to 28,000!). A little tweaking of Monkbot's code to add a few more template aliases may remove another 1,000 or so, but that is "substantial completion" by any measure.
The "et al." messages should be shown. I have worked with Citation Bot and manual edits to get the two categories down from about 12,000 articles to less than 1,500. This one has also run to substantial completion.
I haven't examined the "format and no URL" category in detail, but I don't think it is tractable with a bot, so those errors should probably be exposed as well.
We'll have to be ready for some communication about these error messages from people new to the conversation. Let's remember to treat them gently. – Jonesey95 (talk) 13:19, 15 September 2014 (UTC)
For the record, I agree that the bot fixes have run to substantial completion but I'm opposed to displaying the error. While I appreciate the responses that I got to an earlier post here, those responses did nothing to address my reasons for objecting. If the error is to be enabled I'd appreciate at least a few days advance notice because I intend to modify the help text so that it more directly addresses the most common errors.TuxLibNit (talk) 23:42, 17 September 2014 (UTC)
Is there a reason that you can't make improvements to the help text now? Even though the errors are hidden from most editors, there are editors who have enabled the error display for hidden errors so whatever improvements you make can help those editors right now.
And why is that you're opposed?
Trappist the monk (talk) 23:52, 17 September 2014 (UTC)
TuxLibNit: the error messages used to be displayed. They were hidden after an RFC with one condition: that a bot designed to remove the errors in each category "run to sufficient completion". That condition has been met for the "dates" category. At this time, articles with date errors are being added to the error category at a rate of about 100 per day. If we continue to hide the error messages, some erroneous dates will continue to be added, but some editors will see the error, read the (improved?) help text, and fix the errors.
I reread the comments of TuxLibNit above, and I found it difficult to determine the editor's reasons for objecting. I saw a lot of questions and a link to an analysis of a sample of dates. What are the objections at this point? Do they outweigh the clear reasons for displaying the error messages, e.g. dates generating error codes are ambiguous, missing data, or otherwise not as clear as they should be? – Jonesey95 (talk) 06:21, 18 September 2014 (UTC)
OK, I'll try to be clearer. I was trying to be brief because I didn't want to generate a wall of text and because I'm aware I'm coming late to this discussion so I thought there was a good chance I'd be pointed to some conclusive argument or agreement that would render a more complete post pointless. As that does not appear to be the case, here we go:
  • A side point regarding the RFC: My understanding of the RFC is that "run to sufficient completion" merely signals the end of an agreement that this error should be disabled. While the closer does explicitly bless re-enabling the errors that the RFC hid, I beleive this is just to restore the status quo — with the messages enabled, but their status disputed. I didn't see a consensus that those arguing for the messages to be disabled more permanently had failed to make their case and that the messages should remain enabled despite their objection.
  • Trying to be clearer about my position:
    • I'm opposed to leaving the red error messages enabled on large numbers (say more than 400 pages/category) of minor errors (subjective, but an ambiguous date in a cite definitely qualifies for me) for long periods of time (really more than a month or so, but I'll be generous and say a year). I hope the principle at least is not too controversial — that the harm done by the presence of an error should be weighed against the harm done by displaying the corresponding error message and the latter harm is at its greatest for an error that does not get fixed for a long time. The messages are there to help ensure the errors are fixed, if they are not doing that job, then they are purely harmful (in the sense that they are defacing the article with no benefit) and should be turned off.
    • I'm not disputing that the overwhelming majority of dates flagged in this category are indeed errors that in an ideal world would be fixed. However I'm not convinced that simply enabling the errors as proposed is a fair or effective way to get them fixed.
    • Regarding fairness. The intended effect of an error message is to flag up an error that a grateful (or at least dutiful) editor will then voluntarily fix because it is an error. This should apply to all major errors and to recently introduced minor errors, but in the case of sufficiently minor errors this logic can be reversed so that the editor will fix the error primarily because the error message defaces the article not because they consider the error itself particularly worth fixing for its own sake. When the errors arise piecemeal (because the error has just been introduced) this can still be tolerable but if lots of minor errors appear all at once it becomes a problem, because the editor feels forced to expend a significant amount of effort right now simply to suppress the error messages, whereas the errors themselves could have been left until later (or arguably even left indefinitely). Forcing an editor to make trivial changes would be unfair.
    • Regarding effectiveness. There are already error categories with red messages enabled that contain huge numbers of members that are not declining significantly. Why should this error be any different (i.e. get fixed rapidly)? I also regard the history of Category:Pages_with_ISBN_errors as support for my position because although there has recently been some success in reducing it, it had remained large for a long period of time and the success has come from a (more or less) coordinated effort by a relatively small number of editors making many edits, and even then, every time that effort flags, the size of the category stabilises again (growing slowly). I think this means that people are mainly fixing these errors from the category and/or from WP:WikiProject_Check_Wikipedia/ISBN_errors, not because they happen to be viewing an article containing an error message.
  • Some final comments for now:
    • It appears that no-one here realised that when I was asking questions in my first post it was because I hoped for answers.
    • There's nothing stopping me editing the help, its on a to-do list but I haven't got to it yet. If the message enable was imminent it would bump that task up my list.
    • If it helps, I could for example support unhiding the error message for a single large category (eg the date errors with 60000 members) if there was also an agreement that if the category did not decline fast enough (say by 5000 messages in a calendar month) while it remained large (say over 400 members) then the message would be hidden again. That doesn't mean I'd be willing to put in much effort into fixing them myself.
    • On the other hand I realise there is no particular need for you to get hung up on one person's objections.
    • I hope that gives a clearer idea of the arguments and reasoning behind my objections. Apologies for the long post, but you did ask for it.
TuxLibNit (talk) 22:32, 18 September 2014 (UTC)
Thank you for the long post. I did ask for it, and your post was helpful. I will respond to a few of the points raised.
  1. I got involved in fixing citation errors because I saw a red error message and it made me curious. If all of the error messages had been hidden, I probably would not be here. Since I began fixing those errors in 2013, I have fixed errors in 20,000 to 30,000 pages. I typically fix 50 to 100 errors per day. There are other gnomes and bots who have fixed many more.
  2. There are currently 28 subcategories of CS1 errors. Of those, 19 are essentially empty or are close to empty due to diligent work by a handful of editors. A few more categories have been massively reduced in the last year; many categories had "huge numbers of members" (quoting the response above) recently, but they have been addressed in a reasonable amount of time. The wikilinks error category, for example, had something like 8,000 articles in it last year, and is empty now. The ISBN error category had about 7,000 articles in it just a few months ago, and it has been reduced to 650 during 2014 (it was at about 1,000 a month or two ago; progress has slowed, since the remaining cases are more difficult than the low-hanging fruit that was there initially). The "old style et al." categories had about 12,000 articles and are now down to about 1,400. My point is that significant progress has been made on almost all of the categories. Most of this work has been done by gnomes and bots, many of whom have been attracted to the work by the error messages. I have some evidence to show that individual reader/editors are motivated by the error messages to fix errors; sometimes I will queue up 20 articles to fix, only to find when I get to the 15th article that an editor actively working on the article has already fixed the error.
  3. The categories that have a stable and large number of members may need to be discussed here individually (e.g. accessdate without URL, format without URL). If nobody wants to fix these errors, maybe we need to set them aside. The "dates" and "deprecated parameters" categories are large, but not large and stable; they have both decreased significantly because editors are interested in fixing these errors.
  4. ReferenceBot has been configured to notify editors when they add some types of CS1 errors to articles. There are additional categories that need to be added to its notification list; I will help those categories to get on the bot's list one of these days. I have evidence that these notifications motivate editors to return to articles and clean up after themselves. Not everyone does so, of course, but many do.
  5. You suggest "more than a year" as a time to determine if progress has been made on reducing error messages in articles. There are currently about 60,000 date errors, with about 100 being added daily. That says that we need to fix about 260 articles per day for a year to clear out the category. Based on my own experience with fixing CS1 errors, I think it is reasonable to expect that focused effort by gnomes and bots on this category could achieve that. Adding ReferenceBot notification (optional, to be decided here) and showing the date errors make it more likely that we could reach that goal.
Thanks for your interest and the explanation. – Jonesey95 (talk) 23:38, 18 September 2014 (UTC)
The date is one of the critical elements of a citation that is used to identify the source. Error checking is intended to identify issues in the citations for quality assurance. Browsing a sample of articles, a large number of errors are due to ambiguous formats such as 9/10/2013 that a bot cannot resolve. Editors should be reviewing their work and if they see an obvious error message they should be able to use the help page and fix the problem quickly. This not currently happening since the messages are hidden by default. --  Gadget850 talk 11:34, 19 September 2014 (UTC)

not exactly pleased with "origyear"[edit]

Often enough I need to add an original publisher (i.e. different from the present/current edition one). There's no actual field for this and the way this is crammed in the origyear field in the examples makes it look very bad because the whole field is rendered before the title, and you don't normally put the publisher before the title. JMP EAX (talk) 08:36, 30 August 2014 (UTC)

Why? The purpose of a citation is to identify where you read or saw a particular fact that supports text in the article. If you read or saw this fact in the current edition, then cite that edition; there is no need to include the publication history. In fact, adding information pertaining to an older edition to a citation referring to the current edition may only serve to confuse readers. If the older edition is important, include it as a separate citation.
If I misunderstand you, an example of where such a combined older/newer cite is required would be helpful.
Trappist the monk (talk) 09:52, 30 August 2014 (UTC)
Some other style guides say you should cite the earlier edition. Some reasons it could be helpful:
  • A reader who possesses the earlier edition will know substantially the same book is being used (depending on what kind of changes were made in the revision process).
  • If the reader has read other works, in addition to the Wikipedia article, which refer to the earlier edition, the reader will know substantially the same book is being used as a source.
  • By giving the earlier publication date, and the original publisher, the reader will realize the ideas in the book may be outdated, and can evaluate the reputation of the original publisher.
Jc3s5h (talk) 11:28, 30 August 2014 (UTC)
WP:SAYWHEREYOUGOTIT. Each instance of a Citation Style 1 template is tool to identify one source and one source only. It is not the responsibility of Wikipedia editors to divine what editions a reader may possess or may have read. That a source may be out dated is irrelevant. The purpose of a citation is to identify and support statements in article text regardless of currency or factual correctness.
Trappist the monk (talk) 11:52, 30 August 2014 (UTC)
Disagree. Jc3s5h (talk) 11:56, 30 August 2014 (UTC)
Different versions of a work can vary quite a bit. If there is a compelling reason to cite different versions of a work, then cite them separately. For example, I have the 1989 and the 2001 versions of Baden-Powell and there are a lot of differences. --  Gadget850 talk 12:48, 30 August 2014 (UTC)
It's not so much a matter of different editions as indicating derivation or descent of an edition. E.g., if you and I are comparing notes from Darwin's Origin of Species the publication dates of my Modern Library edition and your (let's say) Norton edition are likely less significant to each other than that one is from Darwin's fifth edition and the other from his first or second edition. Yes, we WP:SAYWHEREYOUGOTIT, but it helps, and doesn't hurt, to where that came from. ~ J. Johnson (JJ) (talk) 22:46, 30 August 2014 (UTC)
Yeah, if we are making comparisons, then knowing the publication history of each is important. But it is not the purpose of a citation – any citation, not just CS1 – to make comparisons between sources. The purpose of a citation is to say to the reader, "Look here. This is where I found that fact." Nothing more, nothing less. I think that adding unnecessary publication history to a citation is a disservice to readers.
If it is important to the reader to know about previous editions or other versions of the same work, add another citation. Don't try to pack two or more into one.
(Addendum) Lest we repeat ourselves, we have discussed this before. Trappist the monk (talk) 15:40, 31 August 2014 (UTC)
Trappist the monk (talk) 10:51, 31 August 2014 (UTC)
Chicago Manual of Style 16th ed. paragraph 15.38 disagrees with Trappist the monk. This is part of Chicago's chapter on their author-date system, so the reference list entry given below would be referred to with a parenthetical inline citation that would contain any necessary page numbers. The following citation may be found there as an example of an acceptable citation:

Austen, Jane. (1813) 2013. Pride and Prejudice. London: T. Egerton. Reprint, New York: Penguin Classics. Citations refer to the Penguin edition.

Jc3s5h (talk) 15:45, 31 August 2014 (UTC)
Fortunately, Chicago Manual of Style and Trappist the monk don't have to agree. Chicago Manual of Style is not CS1. CS1 is not designed to provide a provenance for each citation. CS1 is designed to meet the requirements established by WP:V and WP:SAYWHEREYOUGOTIT. To meet this particular clause of chapter 15.38, CS1 would need to be modified to support at a minimum |orig-location=, |orig-publisher=, and in-source locators |orig-page=, |orig-pages=, and |orig-at=. This is a complicating path upon which I think we should not venture.
Trappist the monk (talk) 17:50, 31 August 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────CS1 is not really designed, full stop. The existence of |orig-year= suggests some desire on the part of template users to be able to provide some information about earlier editions. At present, this could be done by following the citation template with additional text explaining the situation. In any case, Trappist the monk's statement "any citation, not just CS1" just isn't so. Jc3s5h (talk) 18:26, 31 August 2014 (UTC)

As you wish. CS1 is not designed in a formal engineering sense. It has evolved and adapted to the environment in which it exists. So let me rephrase the sentence: CS1 is not designed adapted to provide a provenance for each citation.
Rather than simply saying that [my] statement "any citation, not just CS1" just isn't so, perhaps you could explain why you believe that?
Trappist the monk (talk) 22:20, 31 August 2014 (UTC)
In context, the statement was "But it is not the purpose of a citation – any citation, not just CS1 – to make comparisons between sources. The purpose of a citation is to say to the reader, 'Look here. This is where I found that fact.' Nothing more, nothing less." But Chicago says sometimes it is useful to provide information about the earlier edition of a work; presumably the writer citing the source only has access to the later edition, but the front matter of the later edition may allow the citing author to make simple statements about how the original differs (if at all) from the later edition. For example, the later edition might contain the same text but be paginated differently, putting a reader with the original edition on alert that the material of interest may be on a different page than indicate in the citation.
APA style 6th ed. is more emphatic. Section 6.18, "Classical Works", states "When you know the original date of publication, include it in the citation." So two major citation guides say that you may (Chicago) or should (APA) provide information about an earlier edition which you did not consult. Hence the claim "any citation, not just CS1" just isn't so. Jc3s5h (talk) 23:44, 31 August 2014 (UTC)
You missed the point of my statement entirely. Editor J. Johnson introduced the notion of two editors (he and me) comparing different editions of a source. Comparison of sources is something that we editors can do. Comparison of sources is not something citations can or should do. Neither Chicago nor APA nor CS1 compare sources.
In the Chicago example that you gave, a single citation identifies two sources. It makes no comparison but simply identifies the two sources. In CS1, if both are important, cite them both but cite them separately. In the quote from APA that you gave, APA limits itself to the original publication date. It also makes no comparisons between the original and the cited work. CS1 supports this through |orig-year=.
Trappist the monk (talk) 11:07, 1 September 2014 (UTC)
Chicago says that if both an original publication (which was not consulted) and republished version (which was consulted) of a work are mentioned, certain differences should be mentioned, if known. One such difference is whether the pagination is the same. This is a simple comparison. Jc3s5h (talk) 12:28, 1 September 2014 (UTC)
No, it just identifies two sources with a single citation. That one is not consulted is poor practice that ought not be condoned.
Aren't we done with this? Clearly, neither one of us is going to convince the other so perhaps it is best to leave off unless there are some new and interesting aspects to discuss. You may have the last word which I shall read; it is likely that I'll decline to respond.
Trappist the monk (talk) 14:08, 1 September 2014 (UTC)


The current description could use a bit of amplification:

  • origyear: Original publication year; displays after the date or year. For clarity, please supply specifics. For example: |origyear=First published 1859 or |origyear=Composed 1904.

Reading Chicago and APA, the intent of 'origyear' is to include the date of original publication for a reprint or modern edition of a work. In my collection, I have:

  • Handbook for Boys (Reprint, Applewood Books) (1st ed.). Doubleday, Page. 1997 [Original publication 1911]. 

Here, 'type' seems to work quite well. But again, this would only work for a reprint, not a different edition. --  Gadget850 talk 13:55, 31 August 2014 (UTC)

Note that Handbook for Boys (Reprint, Applewood Books) (1st ed.). Doubleday, Page. 1997 [Original publication 1911].  is hopelessly confusing in other ways. This suggests we need to rethink the order in which these things appear.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:53, 6 September 2014 (UTC)

An ISO 639-1 language name test[edit]

Sometime ago somewhere there was a discussion about ISO 639-1 that led me to do a brief experiment with mw.language.fetchLanguageName(). Right now, Module:Citation/CS1/Configuration has a table of ISO 639-1 codes and their English meanings (["af"] = "Afrikaans"). It seems silly to me for us to be maintaining a list of these translations if there is some other place we can get the same information.

So, I've tweaked Module:Citation/CS1/sandbox to use mw.language.fetchLanguageName(). In the collapse box is a list of simple cites that use the names and codes from the list in Module:Citation/CS1/Configuration.

If the tweaked code works, and if mw.language.fetchLanguageName() agrees with Module:Citation/CS1/Configuration then the citation title and the parenthetical language element of the rendered citation should be the same.

{{cite book/new |title=Afar |language=aa}}
Afar (in Afar). 

I have been through the list and found a handful of code translations that do not match. Can anyone find others?

These codes produced results different from the current table of definitions in Module:Citation/CS1/Configuration. Each is accompanied by a link to SIL International (SIL) along with a list of language names. Presumably, where two or more language names are listed, the first listed should be preferred? Right? SIL is, according to the Library of Congress web site, is the keeper of ISO 639 (here is a table of ISO 639 codes at the Library of Congress).

  • Maldivian (in Divehi). code dv: Dhivehi; Divehi; Maldivian – neither CS1 nor mw.language.fetchLanguageName() use the preferred language name
  • Haitian Creole (in Haitian). code ht: Haitian; Haitian Creole – CS1 does use the preferred language name
  • Nuosu (in Sichuan Yi). code ii: Nuosu; Sichuan Yi – mw.language.fetchLanguageName() does not use the preferred language name
  • Gikuyu (in Kikuyu). code ki: Gikuyu; Kikuyu – mw.language.fetchLanguageName() does not use the preferred language name
  • Kwanyama (in Kuanyama). code kj: Kuanyama; Kwanyama – CS1 does use the preferred language name
  • Greenlandic (in Kalaallisut). code kl: Greenlandic; Kalaallisut – mw.language.fetchLanguageName() does not use the preferred language name
  • Central Khmer (in Khmer). code km: Central Khmer – mw.language.fetchLanguageName() does not use the preferred language name
  • Norwegian (in Norwegian). code no: Norwegian – bug in mw.language.fetchLanguageName()?
  • Ossetian (in Ossetic). code os: Ossetian; Ossetic – mw.language.fetchLanguageName() does not use the preferred language name
  • Tonga (Tonga Islands) (in Tongan). code to: Tonga (Tonga Islands) – mw.language.fetchLanguageName() does not use the preferred language name

With the exception of codes no and to, mw.language.fetchLanguageName() provides an approved language name for each of the codes I've tested here. If, at the very least, code no can be fixed then I think that Module:Citation/CS1 should discontinue use of it's current table of names in favor of mw.language.fetchLanguageName().

In the mean time I will adjust the existing table so that if it takes a while before code no is fixed at least CS1 will be doing correct code to language name translation for codes dv, ht, and kj.

Trappist the monk (talk) 23:06, 1 September 2014 (UTC)

Don't forget the parser function {{#language:}}, e.g. {{#language:dv}} → ދިވެހިބަސް and {{#language:dv|en}} → Divehi --Redrose64 (talk) 23:44, 1 September 2014 (UTC)
I'm going to hazard a guess that {{#language:}} and mw.language.fetchLanguageName() are intimately related: {{#language:no|en}} produces Norwegian (bokmål) which is the same wrong language name produced in the Norwegian language test above.
Trappist the monk (talk) 23:57, 1 September 2014 (UTC)
See also m:List of Wikipedias#Nonstandard language codes. --  Gadget850 talk 01:10, 2 September 2014 (UTC)

I have tweaked Module:Citation/CS1/sandbox to provide a workaround for the code no problem. This does not fix the {{#language:no|en}} magic word which relies on the same code in mw:Extension:CLDR. {{#language:no|en}} produces: Norwegian (bokmål). More at WT:LUA#Bug in mw.language.fetchLanguageName()?

With this tweak, I think we can remove the translation table from Module:Citation/CS1/Configuration.

Trappist the monk (talk) 16:59, 10 September 2014 (UTC)

If this is intended to appear in the citation, this would be way more helpful if the output was "(language: Langname)" instead of "(in Langname)", an ambiguous construction that relies entirely upon the reader's recognition of Langname as the name of a language. That is unworkable because of the large number of obscure languages on the planet, and the fact that some of them are not distinguished from geonyms or ethnonyms.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:49, 6 September 2014 (UTC)

I suspect that '(in language name)' is an artifact of published style manuals: this example at CMOS 14.110 for example.
Trappist the monk (talk) 14:45, 10 September 2014 (UTC)

I've been wondering if the categorization that Module:Citation/CS1 applies to pages with citations that assign ISO639-1 codes to |language= is correct. Right now, if |language=de is use then the page is added to Category:Articles with German-language external links. This may or may not actually be true. For example this citation provides no links except to Special:BookSources

{{cite book |last1=Busch |first1=Rainer |last2=Röll |first2=Hans-Joachim |title=Deutsche U-Boot-Verluste von September 1939 bis Mai 1945 |work=Der U-Boot-Krieg |volume=IV |publisher=Mittler |location=Hamburg, Berlin, Bonn |year=1999 |isbn=3-8132-0514-2 |language=de}}

Here, |language= is used to identify the language of the source which is in keeping with the CS1 documentation.

So my question is: Are we correctly categorizing these pages? If yes, then we're done; if no, how should these pages be categorized?

Trappist the monk (talk) 14:45, 10 September 2014 (UTC)

I added some comments about the 'no'/'nb' issue here. – Danmichaelo (talk) 20:03, 14 September 2014 (UTC)

Based on my conversation with Editor Danmichaelo, I have taken the decision that Module:Citation/CS1 will return the string '(in Norwegian)' when editors use |language=no.

I have removed the translation table from Module:Citation/CS1/Configuration/sandbox so language codes now get the language names from Mediawiki.

Still unanswered is the categorization question. Category:Articles with non-English-language external links appears to have been intended for just that: external links. Right now, the module is indiscriminate. Whenever a citation with |language=<ISO639-1 code> is used, we add the page to the 'language' sub category of Category:Articles with non-English-language external links regardless of whether the citation has an external link. We aren't the only violators of the category, editors use {{xx icon}} to identify a string of text as a particular language (see Borgund Stave Church at the top of the infobox for an example).

Trappist the monk (talk) 11:34, 15 September 2014 (UTC)

What about using the categorisation that the lang-xx templates use? For example, at Swansea, it has {{lang-cy|Abertawe}} which puts the page into Category:Articles containing Welsh-language text. --Redrose64 (talk) 15:07, 15 September 2014 (UTC)
I don't know. The text at the top of Category:Articles containing non-English-language text does say that articles added to those categories should be added by the {{lang}} family of templates. That restriction sort of disqualifies CS1, né?
Of course the question that I haven't asked yet is: do we need to categorize pages that cite foreign language sources? My guess is that there will be some sort of maintenance or other benefit that can be gained by doing so. As an aside, I've been thinking that CS1 needs a maintenance category any way so this could be the impetus to create one.
Trappist the monk (talk) 00:18, 16 September 2014 (UTC)
No opinions? Ok, there is a new category Category:CS1 properties into which we can put stuff like Category:CS1 foreign-language sources into which we put categories like Category:CS1 German-language sources (de), Category:CS1 Spanish-language sources (es), etc. There will be about 270 or so 185 of these language-specific subcategries. I will use AWB to create them all. So that I get it right, are these names acceptable? Is there a better way to name categories that contain citations to sources in languages other than English?
Trappist the monk (talk) 13:55, 26 September 2014 (UTC)
It is done: 183 individual subcategories ordered by ISO639-1 two-character codes in Category:CS1 foreign language sources which itself is a subcategory of Category:CS1 properties.
To get the list of individual language categories, I copied the table at the Library of Congress website into a spreadsheet; deleted ISO639-2, French, and German columns; sorted by ISO639-1 and removed all rows without a two-character code; used the spreadsheet to make a simple {{cite book/new}} template that used |language=xx where xx is the ISO639-1 code; copied the list of templates to an edit window in Wikipedia; Show preview to get the names associated with the codes as Wikimedia understands them; copied the result to Notepad++ where I used a regex search and replace to create category names and other info to feed to the AWB CSVloader plugin which did all of the actual work.
Trappist the monk (talk) 23:29, 27 September 2014 (UTC)

The other half is now implemented in Module:Citation/CS1/sandbox. The code will now categorize pages with CS1 citations containing |language=<lang> where lang is a ISO639-1 language name. The code does not check spelling but is immune to capitalization and will render language name correctly capitalized. Language names that aren't ISO639-1 names are allowed but are not categorized.

Trappist the monk (talk) 16:05, 29 September 2014 (UTC)

Does this test categorize pages only in the namespaces currently categorized by our error messages, or does it categorize pages in all namespaces? I recommend the former; categorizing User and Talk (et al.) pages is probably not useful, since fixing them is often not appropriate and they are not "encyclopedic" pages exposed to regular readers of WP. – Jonesey95 (talk) 18:35, 29 September 2014 (UTC)
Only categorizes mainspace and only if |language= is something other than en or English. This follows the precedence set by other language categorizes like the {{xx icon}} templates. These:
  • *{{code|{{cite book/new |title=Title |language=gd}}}}
  • *{{code|{{cite book/new |title=Title |language=Scottish Gaelic}}}}
don't categorize here:
  • <span class="citation book">''Title'' (in English).</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • <span class="citation book">''Title'' (in Scottish Gaelic).</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
but if you copy them to an article in mainspace, click Show preview, you'll see that they do.
But, your question did make me think that we should be applying the same mainspace limitation to categorizing articles with |language=en and |language=English into Category:CS1 maint: English language specified. We aren't right now so I'll fix that.
Trappist the monk (talk) 19:31, 29 September 2014 (UTC)

Is something wrong with the description of "Cite web"?[edit]

{{Help me}} I was looking at the description of Template:Cite web (edit|talk|history|links|watch|logs) and saw large boxes full of white space and all the parameters are described as "You can explore profiles of current Radio staff in the section of this site and learn more about the type of work we do on . Get the latest BBC Radio news from the and .". Is this just me (I got the same result in Chrome and Firefox) or is something wrong?BiologicalMe (talk) 15:41, 2 September 2014 (UTC)

Don't know what caused it. If it's still there, click the purge link (top of the green near the Template documentation header) and see if that fixes the problem.
Trappist the monk (talk) 15:51, 2 September 2014 (UTC)
Someone broke Template:Csdoc. -- John of Reading (talk) 16:09, 2 September 2014 (UTC)
It's working now. Thanks for the responses, and if someone did something to fix it that I didn't see in the histories, thank you as well.BiologicalMe (talk) 16:44, 2 September 2014 (UTC)
{{csdoc}} is a redirect to {{Citation Style documentation}}. I protected both. --  Gadget850 talk 22:49, 2 September 2014 (UTC)

Should Template:Cite report be listed on this Help page?[edit]

I recently came across an invalid LCCN in a {{Cite report}} template, which uses Citation/core, so it did not report an error message. Should {{Cite report}} be listed in the table on this Help page? – Jonesey95 (talk) 00:07, 5 September 2014 (UTC)

See the talk page. --  Gadget850 talk 01:19, 5 September 2014 (UTC)
Sorry, I must be dense. I looked at Template_talk:Cite_report but did not see anything related to my question. I'll explain more fully. It appears to me that {{cite report}} is a CS1 template, so I'm asking if {{cite report}} should be added to the table at Help:Citation_Style_1#General_use. – Jonesey95 (talk) 04:29, 5 September 2014 (UTC)
Yes. Done.
Trappist the monk (talk) 09:58, 5 September 2014 (UTC)
Then we need to change the CS1 description:

There are a number of templates that use a name starting with cite; many were developed independently of CS1 and are not compliant with the CS1 style. There are also a number of templates that use one of the general use templates as a meta-template to cite a specific source.

To be compliant with CS1, a template must:

  • Be based on {{citation/core}}, Module:Citation/CS1 or one of the templates listed below.
  • Use a period as a punctuation mark to separate fields and end the citation.
  • Use a semicolon as a punctuation mark to separate authors and editors.
  • Format longer works in italics.
  • Format short works such as chapters in quotes.
--  Gadget850 talk 10:31, 5 September 2014 (UTC)
All of those criteria are met, are they not, with the exception of title formatting? It isn't clear to me why the |title= value isn't formatted in the same way as other titles throughout Wikipedia. The title value passed to {{citation/core}} is |Title= ''&#xFEFF;{{{title|}}}&#xFEFF;'' which undoes normal italic formatting and adds zero-width no break space characters. Why undo the italic formatting and what purpose do the unicode characters serve?
Trappist the monk (talk) 10:57, 5 September 2014 (UTC)
Exactly. This is discussed on the talk page. The template is for "Unpublished reports by government departments, instrumentalities, operated companies, etc" which I also failed to understand. It is redundant to {{cite journal}}. --  Gadget850 talk 11:02, 5 September 2014 (UTC)
And the manner of usage is also odd. See Area 51 for example. --  Gadget850 talk 11:06, 5 September 2014 (UTC)
I don't think that the case has been well made for removing title styling contrary to MOS. As for use of {{cite report}} in Area 51, that looks like a case of profound laziness on the part of the editors. A few minutes in Google turned up pdf copies of both documents:
The U-2's Intended Successor: Project Oxcart,1956-1968
A-12, YF-12A, & SR-71 Timeline of Events
That second document doesn't have the pristine provenance of the first, but editors have been satisfied with less.
Trappist the monk (talk) 12:25, 5 September 2014 (UTC)

The documentation for {{cite report}} is so bad and the title formatting is so non-standard that this template should not be considered part of CS1. I consider the template unfit for any use at all and if I come across a featured article that uses it, I will change it. If the change is reverted I will challenge the FA status of the article. Jc3s5h (talk) 12:54, 5 September 2014 (UTC)

Thanks for adding the template to the table. Should {{cite report}} be converted to use the CS1 Module? It looks like that would clear up problems with title formatting, lack of availability of some parameters, and documentation. Are there problems that it would create? – Jonesey95 (talk) 13:59, 5 September 2014 (UTC)
Do you intend to keep the existing formatting? As best I recall, the only difference between {{cite report}} and {{cite journal}} is the title presentation and the 'docket' id (which may not be in use). --  Gadget850 talk 14:20, 5 September 2014 (UTC)
It would seem that {{cite report}} is in many ways similar to {{cite thesis}}. Both support |docket= and both are 'unpublished', and each sets |type= to a default value. Similarly, one might claim that {{cite report}} is similar to {{cite techreport}}; |type= set to default values and 'unpublished' in the sense expressed at {{cite report/doc}}. In both {{cite thesis}} and {{cite techreport}}, titles are italicized.
{{cite report |title=Title |id=ID |docket=Docketname}}Title (Report). Docketname.
{{cite thesis |title=Title |id=ID |docket=Docketname}}Title (Thesis). Docket Docketname. ID. 
{{cite techreport |title=Title |id=ID |docket=Docketname}}Title (Technical report). ID. 
And what does 'docket' mean in this context? The general definition (wikt:docket) isn't much help. Perhaps 'docket' is a contraction of 'docket number'? {{cite thesis}} adds the word 'Docket' to the value assigned to the module's internal variable ID when |docket= is used with {{cite thesis}}. Is there a real value gained from this?
Trappist the monk (talk) 15:26, 5 September 2014 (UTC)
Where are we on this? Either we change cite report (which will make it redundant), we change the description of CS1, or we leave cite report as a different style. --  Gadget850 talk 20:52, 10 September 2014 (UTC)
I'm of the opinion that {{cite report}} should be modified to put report titles in at least quotation marks or italics (my preference being the latter). The template is otherwise no more redundant than {{cite thesis}} and should be included in the CS1 family. Imzadi 1979  21:31, 10 September 2014 (UTC)
At this point I am presuming that report titles should be unformatted. I will be updating the documentation as such and redirecting the talk page to the CS1 centralized talk. --  Gadget850 talk 14:20, 30 September 2014 (UTC)

Cite news documentation[edit]

The {{cite news}} documentation says, correctly, that periodicals usually omit the publisher, and not to include it when it is substantially the same as the work name. But the example of "A news article with a credited author", as well as several other examples, is a newspaper where the publisher is very similar to the work name. In my opinion, the cite news examples and the blanks under "Usage" should not include the publisher. --JFH (talk) 01:39, 5 September 2014 (UTC)

Go for it. --  Gadget850 talk 01:41, 5 September 2014 (UTC)

Untitled work[edit]

I notice that CS1 does not support untitled works. Chicago would use a descriptive phrase where the title would normally go, and the phrase would not be in italics nor would it be enclosed with quotes. So if someone needs to cite an untitled work, what would they do, other than rewrite all the citations in the article to use a style other than CS1? Jc3s5h (talk) 13:26, 5 September 2014 (UTC)

Example? In my mind, untitled would mean unpublished, which would fail the reliability standard. --  Gadget850 talk 13:34, 5 September 2014 (UTC)
I will give an example from Chicago Manual of Style 16th ed. section 14.240:

42. Burton to Merriam, telegram, 26 January 1923, Charles E. Merriam Papers, University of Chicago Library.

Jc3s5h (talk) 13:46, 5 September 2014 (UTC)
That's arguably an unpublished source, per Gadget850's concerns, above, though some might consider it a primary source because it's publicly accessible and validated by the institution. While it's conventional in art-related publishing to treat untitled works as if their title was "Untitled" or Untitled, as appropriate, those are usually also unpublished works. The most common case for this where we'd care about it are small newspaper entries with no title, and these are actually quite common, or were, back in the day. I think the most common way of handling them has been to use their first few words and "..." as if it were a title: |title=Yesterday's Spinks vs. Schaefer match was... |at="Sports" section |department=Sports |work=[[New York Times]].... A |noquotes= parameter could be used to remove quotation marks from around descriptive entries that are not actually titles, per Chicago's usage (and properly documented as to why this parameter would ever be used). A corresponding |noitalics= could also be used, for even rarer cases, to deitalicize names of major works. Actually, the most common use for both cases might be where the title needs to ben manually given in the proper formatting and also be followed by an annotation that should not be quoted/italicized, e.g. |noitalics=y |title=''Serenity'' (original script) |at="Extras" section |work=[[Serenity (film)|Serenity]] |format=Blu-ray .... There are many cases of not-intended-to-be-published works which have subsequently been published as part of bigger collective ones, and which have no titles or have titles, have been assigned later, conventional names in critical lit that are not actually titles, or have titles that would be ambiguous or confusing without such notes. An obvious example is the enormous amount of draft and abandoned and incomplete work by J. R. R. Tolkien edited and published in collected volumes by his son, which includes examples of all three types of cases.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:36, 6 September 2014 (UTC)
Perhaps something like |description-in-lieu-of-title= (yeah, much too long as a parameter name but could be aliased to an initialism |dilot=). If |title= or |chapter= (or any of the appropriate aliases) is present in the template and has an assigned value, do not display |dilot=; else display the unstyled, unquoted content of |dilot=. Content of |dilot= would not be restricted; |url=, if present, attaches to |dilot= just as it does to |title=. CS1 templates that display |dilot= content would add the page to a maintenance category; it would be inappropriate to misuse this parameter for the purpose of affecting title style in a rendered citation.
Trappist the monk (talk) 16:01, 6 September 2014 (UTC)
But |title= is already mandatory. So, the simple way to get at this is to allow styling (quotes or italics) to be decoupled from that parameter when necessary. That's way simpler than that "dilot" stuff, the name of which no one is likely to remember. The real code to implement how you've described the behavior of such as |dilot= would be quite bloated; it's a bunch of nested ifs, and ifs in multiple sections of essentially unrelated code, etc. Let's go with the KISS principle on this.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:52, 6 September 2014 (UTC)
@SMcCandlish: Instead of |at="Sports" section I would recommend |department=Sports: "Regular department within the periodical. Displays after work and is in plain text." --  Gadget850 talk 16:32, 6 September 2014 (UTC)
Noted; that parameter must have been added since the last time I pored over the parameters list in any detail.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:52, 6 September 2014 (UTC)
I have seen sources that incorporated a bunch of other documents (usually memos, letters, or messages) that don't have titles. Should we establish some kind of recommended practice that such items be explicitly "titled" with something like "[untitled]"? I think the strongest reason for that is so that the lack of a title is acknowledged, rather than seeming like a possible omission. ~ J. Johnson (JJ) (talk) 20:58, 29 September 2014 (UTC)
The style manuals I've read use a description of such works, but don't give any special typographic treatment to the description (no quote marks, no italics) so readers will know it is a description rather than a title. Jc3s5h (talk) 21:12, 29 September 2014 (UTC)

Seasons and year–year boundaries[edit]

In the northern hemisphere, the transition from one year to the next occurs during winter. Not so,for the southern hemisphere. This morning I found an instance of a journal that was dated Summer 2003–2004. The current live version of the module doesn't support dates in that form. So, I've modified Module:Citation/CS1/Date validation/sandbox.

Cite book compare
{{ cite book | date=Winter 2003–04 | title=Title }}
Live Title. Winter 2003–04. 
Sandbox Title. Winter 2003–04. 
Cite book compare
{{ cite book | date=Summer 2003–04 | title=Title }}
Live Title. Summer 2003–04. 
Sandbox Title. Summer 2003–04. 
Cite book compare
{{ cite book | date=Winter 2003–2004 | title=Title }}
Live Title. Winter 2003–2004. 
Sandbox Title. Winter 2003–2004. 
Cite book compare
{{ cite book | date=Summer 2003–2004 | title=Title }}
Live Title. Summer 2003–2004. 
Sandbox Title. Summer 2003–2004. 

Trappist the monk (talk) 16:32, 5 September 2014 (UTC)

Cool. I actually needed that just the other day, with an Australian journal.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:02, 6 September 2014 (UTC)

Discussion on placement of ref-related tags[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:WikiProject Inline Templates#Placement of ref-related tags, on placement of reference-related inline templates (e.g. {{verify credibility}} and {{clarifyref2}}) inside or outside the <ref>...</ref> element.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:08, 6 September 2014 (UTC)

OL parameter not being processed optimally[edit]

I have noticed a problem with the CS1 citations' processing of the (little-used) |ol= parameter. You can see the problem in The Carnival. Click on the link in the OL value in the first paragraph, and you will see that the link leads to a 404 error. If you remove the leading "OL" from the OL value, it takes you to the correct page.

This OL is broken: Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL OL10699186M. 

This OL works: Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL 10699186M. 

The OLID listed on the resulting page is "OL10699186M", so we should expect editors to put in such values. We should also expect them to leave off the leading "OL", since doing so has presumably resulted in working links for some period of time.

I was unable to find a spec for the Open Library Identifier (OLID); someone else may have better luck finding it. It appears that we might want to ignore the presence of a leading "OL" in the |ol= parameter, however, when rendering a clickable URL for the OL value. – Jonesey95 (talk) 23:18, 8 September 2014 (UTC)

It isn't documented, but the leading OL is not supposed to be included in the id. I think we only check for the terminator. --  Gadget850 talk 00:30, 9 September 2014 (UTC)
Maybe it's not supposed to be there, but even the Open Library page that you get when you click an OL link shows "ID Numbers: Open Library OL10699186M". That is why I suggest making the code flexible, serving up a working link whether the "OL" prefix is included in the value or not. – Jonesey95 (talk) 03:15, 9 September 2014 (UTC)
I've tweaked the OL validation code so that it looks for a series of one or more digits followed by one of the characters 'A', 'M', or 'W'.
Cite book compare
{{ cite book | isbn=978-0-590-30611-9 | ol=OL10699186M | author=Marjorie L. Burns | publisher=Scholastic Book Services | year=1980 | oclc=8000874 | title=How to Read a Short Story (Scholastic language skills) }}
Live Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL OL10699186M. 
Sandbox Marjorie L. Burns (1980). How to Read a Short Story (Scholastic language skills). Scholastic Book Services. ISBN 978-0-590-30611-9. OCLC 8000874. OL OL10699186M Check |ol= value (help). 
Trappist the monk (talk) 11:36, 9 September 2014 (UTC)
The page about Open Library's API may help. While it doesn't explicitly say it, a link to will bounce to and similar things happen for works or authors. For some reason, no similar handling is done for publishers.
LeadSongDog come howl! 13:58, 9 September 2014 (UTC)
{{OL}} shows an example of {{OL|ia:publicrecords02conn}}OL ia:publicrecords02conn which redirects to OL14052591M. --  Gadget850 talk 14:08, 9 September 2014 (UTC)
I've scanned through the developer documentation (such as it is) a couple of times without finding anything that describes the identifier system. I have often been unable to see those things I have been looking for when they are right before me, so other eyes to look would be helpful.
I'm not inclined to support |ol=ia:publicrecords02conn because the OpenLibrary web site does redirect at least some of these kinds of 'identifiers' to a proper OL identifier. Not all Internet archive material has OL identifiers: OL ia:wargardenguyed00nati. If one wants to cite material on Internet Archive, use |url= and perhaps |via=Internet Archive.
Trappist the monk (talk) 14:51, 9 September 2014 (UTC)
That disinclination is a good thing. Such records as "ia:publicrecords02conn" are, in many cases, defectively linked on OpenLibrary as "books" but not associated as instances of identified "works". The result is that neither edits to correct the book nor the work record are possible. It's a bug in the OpenLibrary software which mines the Internet Archive database which has been identified but the OpenLibrary database has not yet been cleaned up. LeadSongDog come howl! 17:09, 9 September 2014 (UTC)
Ok, I've linked that book under OL records as OL25620088M and OL6617739M under OL7744673W. They are fixable one at a time, once you figure out the technique. LeadSongDog come howl! 17:52, 9 September 2014 (UTC)
Trappist the monk, thanks for modifying the code. I expect that if implemented, it would result in a fair number of error messages that would be easy to fix, but I think that it would be better to silently discard the leading "OL" when creating a link. My reasoning is that we do not have a specification to refer people to, and the OL web site itself shows OLIDs with a leading "OL". – Jonesey95 (talk) 20:29, 9 September 2014 (UTC)
That would be inconsistent with the way we handle all of the other IDs. We don't silently ignore PMC or ISBN or any of the other identifier labels. I'd really rather not start making exceptions.
We're sort of at sixes with this one. Historically, CS1, {{citation/core}} through {{citation/identifier}}, has required that |ol= not include the 'OL'; {{OL}} requires that the id not include the'OL'; related templates {{OL author}}, {{OL book}}, and {{OL work}} do require the 'OL'. None of those templates has more than 500 transclusions so it wouldn't be too onerous to change them all to use the id without the 'OL' (which, because it never changes conveys no meaningful information except when the id is used in isolation).
Trappist the monk (talk) 21:16, 9 September 2014 (UTC)
I see the issue with silently ignoring the extra "OL", but perhaps a more useful diagnostic is the better way, suggesting the correction to be made rather than just complaining that it is wrong? There's some history behind all this Template:OL/doc and Template talk:Cite book/Archive 6, which indicates there used to be some ambivalence about including "OL" in the identifier, but ultimately what's past is past. LeadSongDog come howl! 22:32, 9 September 2014 (UTC)
At some point in the dim dark past, {{OL}} may have accepted either OL1234A or simply 1234A, but in its current implementation it doesn't: OL1234A OLOL1234A.
I have hacked up the sandbox version of {{OL author}} so that it will accept identifiers with or without the 'OL' prefix. See Template:OL author/testcases.
As for more useful diagnostic, that is why we have Help:CS1 errors. We can put a lot more information there than would ever be accepted in an in-article error message. I invite everyone to help us make the help text better.
Trappist the monk (talk) 23:15, 9 September 2014 (UTC)
I can live with |ol=OL12345A being flagged as an error; I'll whip up a quick AutoEd script to fix the errors that crop up, as I currently do with similar PMC, DOI, ISBN, and other ID errors. I just thought that it might be more forgiving in this case to allow the OL, since the definitive source does not really seem to have its act together. – Jonesey95 (talk) 23:38, 9 September 2014 (UTC)
  • I once came across this very issue and figured out that I need to remove the "OL" from the parameter value. I would support rolling out the {{OL author/sandbox}} code that lets you both include and omit "OL"; it seems useful for the reasons outlined in the OP. It Is Me Here t / c 10:12, 10 September 2014 (UTC)
{{OL author}}, {{OL book}}, and {{OL work}} have been updated to accept identifiers with or without the OL prefix. Instances of |id={{OL|...}} in CS1 citations have been converted to |ol=....
Trappist the monk (talk) 16:14, 20 September 2014 (UTC)

TITLE or Title?[edit]

Hopefully this is an easy one. I would like to cite a Playboy article in which the title is in all caps.[1] Should I use |title=PLAYBOY INTERVIEW: MARK LANE OR |title=Playboy Interview: Mark Lane? Thanks! - Location (talk) 04:32, 9 September 2014 (UTC)

Sentence case or title case. See WP:ALLCAPS.
Trappist the monk (talk) 10:27, 9 September 2014 (UTC)
I use to reformat case. --  Gadget850 talk 10:39, 9 September 2014 (UTC)
Thanks for pointing me in the right direction! - Location (talk) 13:45, 9 September 2014 (UTC)

Cite original title or second title for the continuation of a newspaper story[edit]

Sometimes a story from one page of a newspaper (e.g. on page 1 "Easter Bunny Goes Berzerk") is continued on another page under a different title (e.g. on page 2, "Children run in terror; Chocolate eggs spilled everywhere - continued from p. 1"). If the material I want to use is on page 2, do I still cite only the original title? Should I use |page=2 or |pages=1-2 if I am only using material on page 2? In using the GNews archives, I am also wondering if I should use |url= to link to the original title on page 1 where the article starts or the second title on page 2 where the material I want to use is located. Thanks again! - Location (talk) 16:02, 10 September 2014 (UTC)

I suppose that you could do this:
{{cite news |title=Easter Bunny Goes Berzerk |chapter=Children run in terror; Chocolate eggs spilled everywhere |newspaper=[[Easter Bunny, Kill! Kill!]] |last=Lapin |first=Jacques |page=2 |url=//}}
which gives:
Lapin, Jacques. Children run in terror; Chocolate eggs spilled everywhere. "Easter Bunny Goes Berzerk". Easter Bunny, Kill! Kill!. p. 2. 
That sort of works but just isn't quite right. You might concatenate the two titles:
|title=Easter Bunny Goes Berzerk: Children run in terror; Chocolate eggs spilled everywhere
and then refer to |page=2
|title=Children run in terror; Chocolate eggs spilled everywhere |page=2 |url=<page 2 url>
Unless there is a need elsewise, link to page 2 if that is where the pertinent information is located.
Trappist the monk (talk) 17:16, 10 September 2014 (UTC)
|title=Easter Bunny Goes Berzerk|at=p. 2, "Children run in terror; Chocolate eggs spilled everywhere" --Redrose64 (talk) 18:11, 10 September 2014 (UTC)
IMHO, if possible, use a URL that links to the complete article, not a URL that links only to page 2. The reader may get a better understanding of the information on page 2 iif they have the context of the entire article. GoingBatty (talk) 22:19, 10 September 2014 (UTC)
Thanks again to all! - Location (talk) 18:45, 12 September 2014 (UTC)

Peculiar title formatting[edit]

When all three of |title=, |chapter=, and |work= (or their aliases) are used together in a CS1 citation, the normally (at least to me) expected formatting shifts. For example:

{{cite book |title=Title |chapter=Chapter}}"Chapter". Title. 

But when I add |work=, this:

{{cite book |title=Title |chapter=Chapter |work=Work}}Chapter. "Title". Work. 

If I take away |title=, this:

{{cite book |chapter=Chapter |work=Work}}"Chapter". Work. 

If I take away |chapter=, this:

{{cite book |title=Title |work=Work}}"Title". Work. 

I suppose that these last two are correct if you assume that |title= or |chapter= are 'smaller' or subsidiary portions of |work=.

This is a new 'feature' to CS1 if you believe this comparison:

Cite book compare
{{ cite book | chapter=Chapter | title=Title | work=Work }}
Old "Chapter". Title.
Live Chapter. "Title". Work. 

Is the module's current rendering of citations that use all three |title=, |chapter=, and |work= correct?

Trappist the monk (talk) 17:38, 12 September 2014 (UTC)

That looks wrong to me. I think the value of |chapter= should always be in quotation marks, and the value of |title= should be italicized, at least in {{cite book}}. Under what circumstances would one want to use both |title= and |work=? Shouldn't they be aliases, as with |journal= and |work= in {{cite journal}} and {{cite news}}? The goal is to cite a chapter/article (in quotation marks) within a larger work (in italics), I think. What is the point of having three distinct parameters?
I notice that |work= is not a documented parameter in the documentation for {{cite book}}.
If three distinct parameters are needed, I think the display should be "Chapter". Title. Work. – Jonesey95 (talk) 20:30, 12 September 2014 (UTC)
|work= is a generic parameter name for |journal=, |encyclopedia=, |dictionary=, etc. This is probably a good example of the dark side of Module:Citation/CS1 supporting every parameter regardless of template name. Here are {{cite journal}}, {{cite encyclopedia}}, {{cite AV media}} which all give the same result:
{{cite journal |title=Title |chapter=Chapter |journal=Journal}}Chapter. "Title". Journal. 
{{cite encyclopedia |title=Title |chapter=Chapter |encyclopedia=Encyclopedia}}Chapter. "Title". Encyclopedia. 
{{cite AV media |title=Title |chapter=Chapter |work=Work}}Chapter. "Title". Work. 
I think I agree with you that when this case exists, it should be as you described.
Trappist the monk (talk) 21:45, 12 September 2014 (UTC)

It works as documented, but this is because I documented it as it works:

  • work: Name of the source periodical; may be wikilinked if relevant. Displays in italics. Aliases: journal, newspaper, magazine, periodical.
    • issue: When the publication is one of a series that is published periodically. Alias: number.
When set, work changes the formatting of other parameters:
title is not italicized and is enclosed in quotes.
chapter is italicized and is not enclosed in quotes.
location and publisher are enclosed in parentheses.
page and pages do not show p. or pp.
edition does not display.
type does not display.

No one has ever been able to explain the formatting difference. I don't know why we even support chapter for journal and news. --  Gadget850 talk 00:49, 13 September 2014 (UTC)

In the code, the quote / italicize determination works this way:
if |work= is used then |title= is quoted.
if the citation is {{cite web}}, {{cite news}}, {{cite pressrelease}}, {{cite conference}}, or {{cite podcast}}; and |chapter= is not used then |title= is quoted.
|title= is italicized.
There is a similar construct for |chapter=:
if both |work= and |title= are used then |chapter= is italicized.
|chapter= is quoted.
I think that this is wrong and should be revised so that |chapter= is always quoted and (ignoring non-Latin languages for the time being) |title= is always italicized except when the citation is {{cite journal}}, {{cite web}}, {{cite news}}, {{cite press release}}, {{cite conference}}, or {{cite podcast}} in which cases |title= is quoted |chapter=, if used, is ignored. Further, |chapter= without |title= should cause a missing title error.
Trappist the monk (talk) 15:32, 14 September 2014 (UTC)
An addendum: |title= should not be italicized in {{cite journal}}. In those citations, |title= is always used for the title of the article within the larger work, at least in my experience of correcting citation errors in a zillion {{cite journal}} templates. |journal= or |work=, in italics, is used for the name of the larger work.
What about |title= in {{cite encyclopedia}}? I know that one is particularly complex.
I think the last suggestion about chapter without title may have unintended consequences and may merit a separate discussion. – Jonesey95 (talk) 15:39, 14 September 2014 (UTC)
Yep, missed that one; {{cite journal}} added. Did I miss any others? I can imagine that there might be encyclopediae with articles long enough to subdivide into chapter-like sections. |section= is an alias of |chapter= so the rule as I've proposed it would render something like this:
"Section Title". Article Title. Encyclopedia
But, the problem with this or any citation that uses the three parameters |work=, |title=, and |chapter=, is that |work= (which is |encyclopedia= in {{cite encyclopedia}}) doesn't make it into the COinS metadata so we've lost the most important identifier.
Trappist the monk (talk) 16:21, 14 September 2014 (UTC)

I've adjusted Module:Citation/CS1/sandbox to demonstrate how I think citations with |work=, |title=, and |chapter= should render:

Cite book compare
{{ cite book | chapter=Chapter | title=Title | work=Work }}
Live Chapter. "Title". Work. 
Sandbox "Chapter". Title. Work. 
Cite journal compare
{{ cite journal | chapter=Chapter | title=Title | work=Work }}
Live Chapter. "Title". Work. 
Sandbox "Title". Work. 
Cite encyclopedia compare
{{ cite encyclopedia | chapter=Chapter | title=Title | encyclopedia=Encyclopedia }}
Live Chapter. "Title". Encyclopedia. 
Sandbox "Chapter". Title. Encyclopedia. 

Note that in the ({{cite journal}} example, |chapter= is ignored.

I found an undocumented snippet of code that maps |title= to |chapter= if |work= is set and |chapter= is not set. I have disabled that in the sandbox:

Cite book compare
{{ cite book | work=Work | title=Title }}
Live "Title". Work. 
Sandbox Title. Work. 

I suspect it is there to force the title to render in quotes. If we adopt this change, I will leave it in the code, though disabled, in case it serves some other purpose that I haven't managed to noodle-out.

Trappist the monk (talk) 14:39, 16 September 2014 (UTC)

These all look right to me. Do we want to flag |chapter= in {{cite journal}} as an error of some sort, rather than silently discarding potentially useful information that has heretofore been displayed? – Jonesey95 (talk) 14:45, 16 September 2014 (UTC)
In the sandbox, |chapter= will be ignored by {{cite journal}}, {{cite web}}, {{cite news}}, {{cite press release}}, {{cite conference}}, and {{cite podcast}} when |title= and |work= are both set. For {{cite journal}}, {{cite web}}, {{cite news}}, and {{cite podcast}} this makes sense because |work= in those citation types is a journal or magazine, a newspaper, or a website. For {{cite press release}}, the quoted title is appropriate to the relative size of a press release. We should just get rid of {{cite conference}}. Most often, {{cite conference}} is used when {{cite journal}} or {{cite book}} or even {{cite speech}} would be more appropriate.
Certainly we should update the documentation for these particular templates to say that |chapter= is ignored. It isn't really an error to have a valid parameter that doesn't get used. Any reason that we shouldn't have |chapter= requires |title= (Help) when |chapter= is used without |title=?
Trappist the monk (talk) 15:24, 16 September 2014 (UTC)
In the past, the test for Missing or empty |title= looks for a value in any one of |chapter=, |title=, |work=, |conference=, |trans-title=, or |trans-chapter=. In the sandbox, I have removed the tests for |chapter= and |trans-chapter=. Either of these, without one or more of the others, is somewhat meaningless: |chapter=3. xxxx of what? With this change, I don't see a need for |chapter= requires |title=.
Cite book compare
{{ cite book | chapter=3. xxxx }}
Live "3. xxxx". 
Sandbox "3. xxxx".  Missing or empty |title= (help)
Trappist the monk (talk) 14:15, 24 September 2014 (UTC)
That makes sense to me. I have been trying to think of valid edge cases, but I haven't come up with any. – Jonesey95 (talk) 19:59, 24 September 2014 (UTC)

Where is the deprecated parameter in this article?[edit]

Where is the deprecated citation parameter in Michael Sells? I have done a null edit and a purge, and it shows the deprecated parameter category, but I do not see any error messages or deprecated parameters.

The category appears to have been added with this recent edit.

The article also sorts at the very top of the error category, before the articles that start with numbers, for some reason. I don't know if that is relevant.

I am also seeing this same situation with Urban College of Boston, Wiktor Eckhaus, and University of Natal. – Jonesey95 (talk) 03:05, 14 September 2014 (UTC)

@Jonesey95: All four were using |access-date= instead of |accessdate=. I've been fixing these for about four years now; there is a citation tool that still insists on using the hyphen even though it's been deprecated for years. --Redrose64 (talk) 10:58, 14 September 2014 (UTC)
|access-date= is a legitimate parameter. But {{citation}} is different. {{citation}} is a hybrid of old Wiki markup and new module. The Wiki markup portion still has a call to {{citation/patent}}. As such it also includes the code that tests for the old list of deprecated parameters.
I don't think that it is necessary to keep the list – |accessdaymonth=, |accessmonthday=, |accessday=, |accessmonth=, |accessyear=, |day=, |access-date=, |dateformat=. There is some small possibility that some of these are still in use out there but none are supported by patent citations so will be silently ignored until patent citations can be brought into Module:Citation/CS1. Shall I remove this code?
Trappist the monk (talk) 11:52, 14 September 2014 (UTC)
Also, these four pages were listed at the top because the wiki markup categorization uses sort keys. The module doesn't.
[[Category:Pages containing cite templates with deprecated parameters|{{NAMESPACE}} {{PAGENAME}}]]
Trappist the monk (talk) 12:04, 14 September 2014 (UTC)
Yes, please either remove that code (preferred), or remove the portion of the code that categorizes the article in the error category, or add code that emits an error message that makes it possible to track down the error. Thanks.
Redrose64, the addition of |access-date= as a valid parameter is a recent change, after an RFC that standardized all multi-word parameters with aliases that contain hyphens in addition to their previous formats (i.e. lumped together like accessdate, or underscored like trans_title). – Jonesey95 (talk) 15:15, 14 September 2014 (UTC)
I took your original request of "Where is the deprecated citation parameter", and your subsequent actions (null edit, purge) to mean "please would somebody help to stop this error being reported". I did exactly that with edits like this. If it's a valid parameter, it shouldn't put the page in Category:Pages containing cite templates with deprecated parameters. --Redrose64 (talk) 15:23, 14 September 2014 (UTC)
Thanks for fixing it. It appears to be a valid parameter; it was being rendered properly in the version that I linked to, with no error message. – Jonesey95 (talk) 15:28, 14 September 2014 (UTC)

Deprecated parameter test removed from {{citation}}.

Trappist the monk (talk) 22:43, 14 September 2014 (UTC)

Missing space in cite conference[edit]

*{{cite conference
 | authors=Abe, M. et al.
 | date=2008
 | title=Ground-based observational campaign for asteroid 162173 1999 JU3
 | journal=[[Lunar and Planetary Science]]
 | volume=39 |pages=1594
 | conference=37th COSPAR Scientific Assembly
 | url=

Yields the following output.

Notice the part that says "37th COSPAR Scientific AssemblyLunar and Planetary Science", which should instead be "37th COSPAR Scientific Assembly. Lunar and Planetary Science". Headbomb {talk / contribs / physics / books} 16:31, 15 September 2014 (UTC)

Well ..., |journal= isn't defined for {{cite conference}}; it sort of works but not really. Perhaps you can do this with {{cite conference}}:

*{{cite conference
 | authors=Abe, M. et al.
 | date=2008
 | title=Ground-based observational campaign for asteroid 162173 1999 JU3
 | publisher=[[Lunar and Planetary Institute]]
 | volume=39 |page=1594
 | conference=39th Lunar and Planetary Science Conference
 | url=

Or, I think a better solution is to use {{cite journal}} or {{cite book}} because by all appearances, you are citing the proceedings not the actual talk given at the conference. Here's how cite journal might look:

As an aside, I think that {{cite conference}} should be used only very rarely. It implies a presence at a conference and that leads to verification questions and thus a source that isn't so reliable. Were it up to me, {{cite conference}} would just fade away ...

Trappist the monk (talk) 19:07, 15 September 2014 (UTC)

The |Periodical= meta-parameter was not implemented in the old version, thus there was no |journal=:
Cite conference compare
{{ cite conference | authors=Abe, M. et al. | date=2008 | journal=Lunar and Planetary Science | title=Ground-based observational campaign for asteroid 162173 1999 JU3 | volume=39 | conference=37th COSPAR Scientific Assembly | pages=1594 | url= }}
Old Abe, M. et al. (2008). "Ground-based observational campaign for asteroid 162173 1999 JU3". 39. 37th COSPAR Scientific Assembly. pp. 1594.
Live Abe, M. et al. (2008). "Ground-based observational campaign for asteroid 162173 1999 JU3". 37th COSPAR Scientific AssemblyLunar and Planetary Science 39: 1594. 
I agree with Trappist: this citation should use cite journal. Can we disable |journal= and the others for this? --  Gadget850 talk 23:24, 15 September 2014 (UTC)
Limiting individual parameter use to certain citation types wasn't something that was contemplated at the beginning of the switch to Module:Citation/CS1. I think that the genii is out and we may never catch him up and stopper the bottle. There is code (written before my time) that purports to 'account for the oddity that is {{cite conference}}, but it isn't qualified in any way (no test to restrict its operation to just {{cite conference}}) so I'm hesitant to simply add code that would set Periodical to nil or empty string.
Perhaps in the future we can begin to look at restricting which parameters are available to the various citation types.
In the meantime, just say no to {{cite conference}}.
Trappist the monk (talk) 00:32, 16 September 2014 (UTC)
The solution is to fix the template, not bury our heads in the sand pretending the problem doesn't exist. Headbomb {talk / contribs / physics / books} 13:54, 17 September 2014 (UTC)

archivedate considered harmful[edit]

(in the tradition of Goto considered harmful)

The existence of Help:CS1_errors#.7Carchiveurl.3D_requires_.7Carchivedate.3D makes little sense to me. 99%[1] of archiveurl fields on en contain the archive date within the URL, so the archivedate field is redundant, and where the archivedate field conflicts with the archive date within the URL, it's always the former that is wrong. I therefore proclaim archivedate considered harmful, and propose it be deprecated. --{{U|Elvey}} (tc) 08:09, 17 September 2014 (UTC)

  1. ^ (guesstimate)
Cute, but... MOS:DATEUNIFY, even ignoring those archiveurls which don't "point to" the date. Can you make the template rendering of the date from the archiveurl context sensitive, so it matches the other dates in the article? LeadSongDog come howl! 13:38, 17 September 2014 (UTC)
I can't tell if the OP is joking or not. If so, the sarcasm is subtle.
URLs from typically have their archive dates in the URL, but those from some other archiving sites, like, do not (see, for example, this reference). In any event, someone who does not know how to decode the date in an URL (which requires hovering over the link with a mouse and reading the URL in the browser's status bar, if it is being displayed) is out of luck unless a human or bot editor converts it to a human-readable archive date. – Jonesey95 (talk) 16:05, 17 September 2014 (UTC)
For the Owen Edwards example, see [2] to see how timestamps are available. That raises the point though... couldn't a bot check archiveurl strings from major archives for matching archivedate values, and put them in the format appropriate for the article? LeadSongDog come howl! 18:33, 17 September 2014 (UTC)
I think so, yes... I meant to include a sentence in my OP suggesting that CS1 render the date from the archiveurl. I think CS1 could be made to match the other dates in the article; I think dates and templates like {{Use dmy dates}} and {{Use mdy dates}} can be detected too, but I'm not sure. --{{U|Elvey}} (tc) 21:26, 20 September 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────FYI—The other day I ran across several URLs that had bogus values in the date part; e.g., "15" in the location where the month is supposed to be. The URLs were functional, but IIRC they redirected to "valid" URLs. There is no way of knowing how widespread the problem is, but you can't rely on those values 100% of the time. ‑‑Mandruss (talk) 13:08, 27 September 2014 (UTC)

Odd. Can you link to an example of where you found one on-wiki?--{{U|Elvey}} (tc) 00:54, 2 October 2014 (UTC)

Publication within a publication[edit]

The Sun Magazine used to appear every Sunday in The Baltimore Sun. (It now appears to be part of it six times each year: [3].) If I am using Template:Cite news for an article published in The Sun Magazine, do I indicate that for |newspaper= or the parent paper, The Baltimore Sun? Thanks! - Location (talk) 21:18, 17 September 2014 (UTC)

Use |department=. --  Gadget850 talk 22:30, 17 September 2014 (UTC)
I agree with Gadget on this one. That would look something like:
  • Doe, John (September 13, 2014). "Article". The Sun Magazine. The Baltimore Sun. p. 2. 
If you were citing Parade magazine, which is published completely independently of the newspaper itself with separate publication staff, I wouldn't bother to mention the paper into which it was enclosed, whether it is The Baltimore Sun, or The Mining Journal. But in this case, that magazine is a component of a specific larger paper, I would use the |department= parameter. Imzadi 1979  02:09, 18 September 2014 (UTC)

Wikimarkup and COinS metadata[edit]

One very common corrupter of the COinS metadata is wikimarkup when it is used to add bold and / or italic styling to |title= (or to undo the default italic styling). The problem arises because the markup gets copied into the metadata. In this example, all of the apostrophes used to make the title bold italic appear in the metadata as a string of %27 which are not part of the actual title:

  • '''''Bold italic''''' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold italic title'''''".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>

In Module:Citation/CS1/sandbox, I have created a function get_coins_title(), that strips the most common legitimate markup from |title= before adding the title to the metadata:

the five-apostrophe cases
  • '''''Bold italic''''' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold italic title'''''".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • '''''Bold''' italic'' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold''' italic'' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • '''''Italic'' bold''' title → "Bold italic title". :
  • <span class="citation news">"'''''Bold'' italic''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • ''Italic '''bold''''' title → "Italic bold title". :
  • <span class="citation news">"''Italic '''bold''''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • '''Bold ''italic''''' title → "Bold italic title". :
  • <span class="citation news">"'''Bold ''italic''''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
simple bold
  • '''Bold''' title → "Bold title". :
  • <span class="citation news">"'''Bold''' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
simple italics
  • ''Italic'' title → "Italic title". :
  • <span class="citation news">"''Italic'' title".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
a combination of all three
  • '''''Bold''' italic'' title and ''italic'', '''bold''', '''bold again''', last ''italic'' → "Bold italic title and italic, bold, bold again, last italic". :
  • <span class="citation news">"'''''Bold''' italic'' title and ''italic'', '''bold''', '''bold again''', last ''italic''".</span><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>

The above examples use {{cite news}} because that template renders titles in upright font.

Have I missed anything obvious?

With this fix, the work discussed at Module talk:Citation/CS1#non-italic titles may no longer be necessary.

Trappist the monk (talk) 12:46, 18 September 2014 (UTC)

Renamed function to strip_apostrophe_markup() and now also used to strip wikimarkup from |chapter=.
Trappist the monk (talk) 10:52, 19 September 2014 (UTC)
I don't know what COinS expects for data, or how resilient it is in the face of obviously bad data, but I would think that any kind of markup that is purely for display purposes is not proper data. Perhaps this is part of a larger problem, of editors trying to coerce the templates? Perhaps that should be flagged as an error? ~ J. Johnson (JJ) (talk) 20:40, 29 September 2014 (UTC)


At {{asin}} is this note:

If the ASIN begins with a number, it is a standard ISBN; please use "ISBN xxxxxxxxxx" instead of ASIN xxxxxxxxxx, as this will allow us to link to other sites as well as Amazon.

Using |isbn= links to Special:BookSources where there is some hope of finding information about the book so we aren't simply feeding readers to

We should add this to the documentation for |asin= shouldn't we? And that made me wonder if we shouldn't just treat such |asin= values as if they were |isbn=. Obviously we can't treat the alphanumeric asins as isbns so those would still render as they do now.

Here are a couple of (not very good) example citations. The first uses |asin=4081097011 and |

"幽☆遊☆白書 其之一 (1) 霊界死闘 編(SHUEISHA JUMP REMIX) (単行本)" [Yū Yū Hakusho (1) Spiritual Guide: Deathmatch (SHUEISHA JUMP REMIX) (Paperback)] (in Japanese). ASIN 4081097011. Retrieved September 2, 2013. 

The second uses |isbn=4081097011:

"幽☆遊☆白書 其之一 (1) 霊界死闘 編(SHUEISHA JUMP REMIX) (単行本)" [Yū Yū Hakusho (1) Spiritual Guide: Deathmatch (SHUEISHA JUMP REMIX) (Paperback)] (in Japanese). ISBN 4081097011. Retrieved September 2, 2013. 

The documentation for |asin-tld= needs to be updated to list or refer to all of the ccTLDs that can be found at

Trappist the monk (talk) 21:01, 21 September 2014 (UTC)

I was looking at this last week.
The Amazon ASIN should be only used for Amazon unique products. I know it is used quite a bit for video games published in Japan; I added the TLD codes to the CS1 core at the request of WikiProject Video games. But a quick sample shows that {{ASIN}} is often mis-used as a citation template; see The Highway Code for example. This lazy use needs to be replaced with a full citation template where it fits the established style.
The CS1 templates support ca, cn,,, de, es, fr, it, so we need to add (China), (India), (Mexico), (Australia) and (Brazil). --  Gadget850 talk 21:36, 24 September 2014 (UTC)
India is already supported. I don't see any reason to do anything about since it gets mapped to I have added support in the sandbox for Australia, Brazil, and Mexico.
  • Chandra, Bipan. History of Modern India. ASIN 8125036849.  – India already supported; this from the live version of the module
  • Corris, Peter. Silent Kill. ASIN B00G65FW0Q.  – Auatralia
  • Follett, Ken. Eternidade por um fio: Terceiro livro da trilogia O Século. ASIN B00KI2HDCS.  – Brazil
  • Jakovlevs, Valerijs. Mazatlan Travel Guide. ASIN B005JFBRFS.  – Mexico
Still, my main question remains unanswered. When |asin= is a number, that number is an ISBN. Should we treat it as an ISBN and link it to Special:BookSources?
Trappist the monk (talk) 22:53, 24 September 2014 (UTC)
I would rather see a bot or an AWB user convert ASINs that are ISBNs into ISBN parameters. That would follow the principle of linking to neutral sources for references instead of to specific vendors (see also WP:ADV). Linking an ASIN to Special:Booksources would be contrary to the principle of least surprise for readers. Converting ASINs to ISBNs would also allow us to validate those ISBNs and flag errors. – Jonesey95 (talk) 23:22, 24 September 2014 (UTC)
Point. So perhaps I'll make us a CS1 maintenance category and add code to categorize citations that use all numeric values for |asin=.
Trappist the monk (talk) 00:15, 25 September 2014 (UTC)
Don't forget that not all ISBNs are all-numeric: nine digits followed by the letter "X" is a valid ISBN format. --Redrose64 (talk) 07:05, 25 September 2014 (UTC)
Thanks, not forgotten, I merely misspoke. In Module:Citation/CS1/sandbox, the value in |asin= is passed to the code that validates ISBNs. If the asin value is a legitimate ISBN, the page is added to category Category:CS1 maint: ASIN uses ISBN.
Trappist the monk (talk) 14:26, 25 September 2014 (UTC)

Accessibility and COinS[edit]

There may be an accessibility issue with the COinS metadata that is appended to citations emitted by the {{citation}} template as well as all the Citation Style 1 templates. See Wikipedia:Village pump (technical)#Spurious text on source links. --Redrose64 (talk) 22:59, 24 September 2014 (UTC)


I have created some new categories. Category:CS1, Category:CS1 errors, and Category:CS1 maintenance. I have added Category:CS1 errors to all of the current error categories listed at Category:Articles with incorrect citation syntax with the exception of Category:Pages with DOI errors and Category:Pages with OL errors. Because these two categories are also populated by non-CS1 templates, I have modified Module:Citation/CS1/sandbox so that errors that previously categorized pages into these two categories will use two new categories Category:CS1 errors: DOI and Category:CS1 errors: OL when the module is next updated.

First use for Category:CS1 maintenance is likely to be to categorize citations that use |asin= where the assigned value is an ISBN. (see Help talk:Citation Style 1#Asin) Another use is to monitor pages that use |script-title=. (see Module talk:Citation/CS1#non-italic titles and Module talk:Citation/CS1#rtl language support in CS1 titles)

I plan to add a properties category which will get as its first subcategory something like Category:CS1 foreign language citations which will then list all pages that have CS1 citations that use |language=. This so we don't continue to improperly (I think) add pages to Category:Articles with non-English-language external links which was intended for other purposes. The conversation about this (such as it has been) is at Help talk:Citation Style 1#An ISO 639-1 language name test.

Trappist the monk (talk) 11:59, 25 September 2014 (UTC)

All of this is useful. I can imagine a bot checking the foreign language categories for various errors, like misspelled languages and |language=English. The maintenance categories could also be used to highlight other conditions that are not errors, but where improvements could be made, like the templates in |id= that Trappist the monk has recently been editing to use the dedicated parameters. – Jonesey95 (talk) 13:10, 25 September 2014 (UTC)
I have added a new maintenance category Category:CS1 maint: English language specified and supporting code in Module:Citation/CS1/sandbox that will categorize pages with citations containing |language=English or |language=en. These parameters are redundant in the English Language Wikipedia.
Trappist the monk (talk) 14:55, 26 September 2014 (UTC)
I wonder what sort of results we would get from adding "unrecognized" languages to a maintenance category. In other words, if the value of the language parameter does not match a list of known languages, we flag it to be checked. It should not be put in an error category, since some of the values like "English and French" might be OK, but I suspect there are misspelled languages or invalid two-letter codes out there. – Jonesey95 (talk) 21:35, 26 September 2014 (UTC)
Keep that thought in mind. The list of changes this go-round is getting rather long. I'd like to finish up on what has been started, update the live module, and then think about new stuff (and old stuff that I have been neglecting).
Trappist the monk (talk) 22:21, 26 September 2014 (UTC)
I'll keep an eye on the new Category:CS1 maint: English language specified - AWB should be able to fix these. GoingBatty (talk) 23:13, 26 September 2014 (UTC)

Updating the live module?[edit]

moved from Help talk:Citation Style 1#Categories

I support updating the live module. Has the missing editor/author condition been re-implemented in this round of updates? Also, do we feel that there is consensus on enabling any of the hidden error messages? (See discussion above.) If this comment is forking the discussion, feel free to move it to a new section or subsection about updating the module. – Jonesey95 (talk) 03:40, 27 September 2014 (UTC)

Missing name detection will be part of the next update.
I don't see much hew and cry about against unhiding date errors so I have set the bad date error hidden parameter to false.
Trappist the monk (talk) 10:49, 27 September 2014 (UTC)

Update to the live CS1 module weekend of 11–12 October 2014[edit]

Over the 11–12 October 2014 weekend I propose to update:

Module:Citation/CS1 to match Module:Citation/CS1/sandbox (diff)
Module:Citation/CS1/Configuration to match Module:Citation/CS1/Configuration/sandbox (diff)
Module:Citation/CS1/Whitelist to match Module:Citation/CS1/Whitelist/sandbox (diff)
Module:Citation/CS1/Date validation to match Module:Citation/CS1/Date validation/sandbox (diff)

This update changes these things:

in Module:Citation/CS1:

  1. Bug fix in get_coins_pages(); (discussion)
  2. Bug fix in extractnames(); (discussion)
  3. Change lccn() to require lower case alpha characters; (discussion)
  4. Change openlibrary() to emit error message when OL identifier contains leading alpha characters; (discussion)
  5. Change |language= support (discussion):
    1. get ISO639-1 language name from Wikimedia;
    2. Add support for right-to-left languages using new parameter |script-title=; (discussion) and (discussion)
    3. Categorize pages when |language=language name;
  6. Change listpeople() so that we don't link to the current page through |authorlinkn= or |editorlinkn=; (discussion)
  7. Add code to strip wikimarkup (italics and bold) from titles and chapters when adding those to COinS metadata; (discussion)
  8. Add Australia, Brazil, Mexico to list of countries supported by |asn-tld=; (discussion)
  9. Undo peculiar title and chapter format swap when |work= or any of its aliases set; (discussion)
  10. Categories:
    1. Add support for maintenance categories; discussion
    2. Change amazon() to add maintenance category when |asin= value is an isbn; discussion
    3. Add support for properties categories; (discussion)

in Module:Citation/CS1/Configuration:

  1. Updated JFM and ZBL prefixes; (discussion)
  2. deleted ISO639-1 table; (discussion)
  3. Changed error categories for doi and ol errors (discussion)
  4. Make date errors visible; (discussion)

in Module:Citation/CS1/Whitelist:

  1. add new parameter |script-title= (discussion) and (discussion)

in Module:Citation/CS1/Date validation:

  1. Add support for valid date formats Summer yyyy–yy and Summer yyyy–yyyy; (discussion)

There is enough here that there is a deal of documentaion to be done. I think that I'll begin that and not bother to hide it prior to the live update – it's just easier that way.

Trappist the monk (talk) 16:18, 30 September 2014 (UTC)

I think this update will also re-enable the missing author/editor errors. And wasn't there something about creating an error when |chapter= exists when there is no |title= or |work=? (See "I have removed the tests for" above.) – Jonesey95 (talk) 16:52, 30 September 2014 (UTC)
Missing author/editor is the extractnames() bug (#2); |chapter= is Undo peculiar title ... (#9).
Trappist the monk (talk) 17:25, 30 September 2014 (UTC)


Could the value of |script-title= not be underlined? Kanguole 17:51, 30 September 2014 (UTC)

Agree. The proper name mark is a Chinese convention that would not apply to other writing systems such as Hebrew or Arabic. --  Gadget850 talk 18:12, 30 September 2014 (UTC)
and an obsolete Chinese convention at that. But these are conventions for Chinese running text, which isn't the situation here. Kanguole 20:26, 30 September 2014 (UTC)
Looks like that was removed.
  • {{cite book/new |title=ABC |script-title=ar:العربية}}
ABC العربية. 


script-title: Title in the original writing system where it is not appropriate to italicize (e.g. Arabic, Chinese, Hebrew, Japanese). Displays after title in upright font and is isolated from the surrounding text-direction settings so that right-to-left scripts render properly. The language may be set by prefixing the value with the ISO 639-1 two-character language code followed by a colon. Unrecognized codes are ignored and will display in the rendered citation. Example: |script-title=ar:العربية.

--  Gadget850 talk 18:05, 1 October 2014 (UTC)

I'd suggest using Chinese or Japanese as the example language, as those are the two for which CMOS recommends also including the original form. Kanguole 20:50, 1 October 2014 (UTC)
Sample? --  Gadget850 talk 12:56, 2 October 2014 (UTC)
Arabic is a good example because it is both non-Latin and rtl, and because support for rtl is a substantial reason for the existence of |script-title=.
Trappist the monk (talk) 13:15, 2 October 2014 (UTC)

Error checking[edit]

Unrecognized codes are not ignored:

  • {{cite book/new |title=ABC |script-title=zz:العربية}}
ABC zz:العربية. 

More than two characters or other than alpha characters do show the language code. --  Gadget850 talk 14:25, 2 October 2014 (UTC)

Thanks for that. Fixed.
Trappist the monk (talk) 14:38, 2 October 2014 (UTC)

Date when no date supplied[edit]

This webpage does not list a date, but does state the copyright, "© 2009-2014 Concordia Theological Seminary", at the bottom. Should I leave |date= blank or use |date=2009-2014? Thanks! - Location (talk) 23:16, 1 October 2014 (UTC)

Trappist the monk (talk) 13:16, 2 October 2014 (UTC)