Help talk:Citation Style 1/Archive 6

This is an archive of past discussions about Help:Citation Style 1. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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=//example.com}}

which gives:

Lapin, Jacques. "Easter Bunny Goes Berzerk". Easter Bunny, Kill! Kill!. p. 2. {{cite news}}: |chapter= ignored (help)

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

Or:

|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)

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)/Archive 137#Citations with title parameter in rtl language.2C beginning with numbers: Display issue and workaround – Jonesey95 (talk) 16:32, 18 August 2014 (UTC)

That discussion now in archive 129.

—Trappist the monk (talk) 14:20, 13 September 2014 (UTC)

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)

*{{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=http://www.lpi.usra.edu/meetings/lpsc2008/pdf/1594.pdf
}}

Yields the following output.

• Ground-based observational campaign for asteroid 162173 1999 JU3 (PDF). 37th COSPAR Scientific Assembly. Lunar and Planetary Science. Vol. 39. 2008. p. 1594. {{cite conference}}: Unknown parameter |authors= ignored (help)

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=http://www.lpi.usra.edu/meetings/lpsc2008/pdf/1594.pdf
}}

• Ground-based observational campaign for asteroid 162173 1999 JU3 (PDF). 39th Lunar and Planetary Science Conference. Vol. 39. Lunar and Planetary Institute. 2008. p. 1594. {{cite conference}}: Unknown parameter |authors= ignored (help)

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:

• "Ground-based observational campaign for asteroid 162173 1999 JU3" (pdf). Lunar and Planetary Science. 39. Lunar and Planetary Institute: 1594. 2008. {{cite journal}}: Unknown parameter |authors= ignored (help)

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=:

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)

The Sun Magazine used to appear every Sunday in The Baltimore Sun. (It now appears to be part of it six times each year: [1].) 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)

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 VT^alk 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 VT^alk 20:25, 18 August 2014 (UTC)

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 id – Jonesey95 (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)

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.

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)

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 10699186M.

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'.

—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 https://openlibrary.org/books/OL23377687M will bounce to https://openlibrary.org/books/OL23377687M/The_adventures_of_Tom_Sawyer 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 OL 14052591M. --  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 OL 25620088M and OL 6617739M under OL 7744673W. 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: OL 1234A OL OL1234A.

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)

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 Creole). – 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 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. 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:

• '"`UNIQ--templatestyles-0000010A-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></span>
• '"`UNIQ--templatestyles-0000010C-QINU`"'<cite class="citation book cs1 cs1-prop-foreign-lang-source">''Title'' (in Scottish Gaelic).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></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)

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= ''{{{title|}}}'' 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. {{cite tech report}}: Unknown parameter |docket= ignored (help)

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)

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)

(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}} ^(t•c) 08:09, 17 September 2014 (UTC)

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 archive.org typically have their archive dates in the URL, but those from some other archiving sites, like webcitation.org, do not (see, for example, this reference). In any event, someone who does not know how to decode the date in an archive.org 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}} ^(t•c) 21:26, 20 September 2014 (UTC)

FYI—The other day I ran across several archive.org 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}} ^(t•c) 00:54, 2 October 2014 (UTC)

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".:

• '"`UNIQ--templatestyles-00000123-QINU`"'<cite class="citation news cs1">"'''''Bold italic title'''''".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Bold+italic+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></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".:

• '"`UNIQ--templatestyles-00000127-QINU`"'<cite class="citation news cs1">"'''''Bold italic title'''''".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Bold+italic+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></span>

• '''''Bold''' italic'' title → "Bold italic title".:

• '"`UNIQ--templatestyles-0000012B-QINU`"'<cite class="citation news cs1">"'''''Bold''' italic'' title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Bold+italic+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></span>

• '''''Italic'' bold''' title → "Bold italic title".:

• '"`UNIQ--templatestyles-0000012F-QINU`"'<cite class="citation news cs1">"'''''Bold'' italic''' title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Bold+italic+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></span>

• ''Italic '''bold''''' title → "Italic bold title".:

• '"`UNIQ--templatestyles-00000133-QINU`"'<cite class="citation news cs1">"''Italic '''bold''''' title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Italic+bold+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></span>

• '''Bold ''italic''''' title → "Bold italic title".:

• '"`UNIQ--templatestyles-00000137-QINU`"'<cite class="citation news cs1">"'''Bold ''italic''''' title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Bold+italic+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></span>

simple bold

• '''Bold''' title → "Bold title".:

• '"`UNIQ--templatestyles-0000013B-QINU`"'<cite class="citation news cs1">"'''Bold''' title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Bold+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></span>

simple italics

• ''Italic'' title → "Italic title".:

• '"`UNIQ--templatestyles-0000013F-QINU`"'<cite class="citation news cs1">"''Italic'' title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Italic+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></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".:

• '"`UNIQ--templatestyles-00000143-QINU`"'<cite class="citation news cs1">"'''''Bold''' italic'' title and ''italic'', '''bold''', '''bold again''', last ''italic''".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Bold+italic+title+and+italic%2C+bold%2C+bold+again%2C+last+italic&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+6" class="Z3988"></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/Archive 11#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)

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)/Archive 130#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/Archive 11#non-italic titles and Module talk:Citation/CS1/Archive 10#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/Archive 6#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)

moved from Help talk:Citation Style 1/Archive 6#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)

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)

|accessdate=

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

I'd like to be able to add a separate date for the ArXiv link specified with {{{arxiv}}} in {{cite journal}} and related templates. For those not familiar with this, ArXiv is a site where academic papers (I think overwhelmingly scientific) can be uploaded for free access and peer review before and while being submitted to regular journals. The ArXiv version remains (freely!) available regardless of subsequent publication elsewhere, and the date of submission can be very different from that of eventual publication. I know that {{{orig-year}}} is available but it doesn't mean the same thing. I would therefore like to add {{{arxiv-date}}} to allow this distinction to be displayed. HTH HAND —Phil | Talk 17:48, 3 October 2014 (UTC)

• publication-date: Date of publication when different from the date the work was written. Displays only if year or date are defined and only if different, else publication-date is used and displayed as date. Use the same format as other dates in the article; do not wikilink. Follows publisher; if work is not defined, then publication-date is preceded by "published" and enclosed in parenthesis.

--  Gadget850 ^talk 19:21, 3 October 2014 (UTC)

If you want to specify a version of the arxiv link, include the v1, v2, etc... part to the arxiv identifier and that's all. If you want to cite the arxiv link specifically, use {{cite arxiv}}. Headbomb {talk / contribs / physics / books} 20:18, 3 October 2014 (UTC)

Just curious - why doesn't the {{date}} template generate a CS1 error, even though the template's documentation says not to use it within citation tempates? For example:

• {{cite web|url=http://www.google.com|title=test|accessdate={{date|22 mar 2013}}}} generates
• "test". Retrieved 22 March 2013.

Thanks! GoingBatty (talk) 15:29, 5 October 2014 (UTC)

Umm, you added {{COinS safe|n}}, perhaps you should tell us?

—Trappist the monk (talk) 15:47, 5 October 2014 (UTC)

Self-reverted my edit to the documentation. GoingBatty (talk) 15:51, 5 October 2014 (UTC)

I don't see any issues with {{date}} except for the template overhead. But I really don't see the use unless you are importing citation data. --  Gadget850 ^talk 16:02, 5 October 2014 (UTC)

I always use {{date}} in the hope that some time in the future it will be recognised by the renderer, and show date in user's preferred style and language. Overhead, schmoverhead. John of Cromer (talk) mytime= Mon 17:41, wikitime= 09:41, 6 October 2014 (UTC)

If the MediaWiki parser ever gets that feature we will add support to the templates. In that case, {{date}} will probably interfere. --  Gadget850 ^talk 12:27, 6 October 2014 (UTC)

I think it's unlikely that User:Johnmperry's hope for the renderer to show dates in the user's preferred style and language will ever be fulfilled. During the extensive debates about date linking, it was shown that, in running text, it is impossible to automatically change from the dmy format to the mdy fomat or vice versa without causing usage errors, because the former does not use commas and the latter usually uses 2 commas. So the renderer would have to limit its activity to tables and other structured text which might be predictable enough to automate the change in rendering. Any such change would clash with the unchanged dates in the running text. Jc3s5h (talk) 16:40, 6 October 2014 (UTC)

I have a work by someone with an English name and a Chinese name. What to do?

What I did was put his English name as author, and his alias as others= alias....

Anyone got a better idea? John of Cromer (talk) mytime= Mon 17:37, wikitime= 09:37, 6 October 2014 (UTC)

Asked at Wikipedia:Help desk#Module:Citation/CS1.

Module:Citation/CS1/Configuration has a number of parameters commented with "remove after 1 October 2014". I am guessing that the use would be updated, the documentation updated and the parameters removed. --  Gadget850 ^talk 10:46, 12 October 2014 (UTC)

I thought about doing that with yesterday's update but there was enough in the update that I just didn't want to add more. The 1 October date is not a hard and fast date. I put it there as a reminder to myself to remove those deprecated parameters that it makes sense to remove. Clearly, |coauthors= isn't ready for removal yet but most of the others can be so will likely be removed at the next update.

—Trappist the monk (talk) 12:52, 12 October 2014 (UTC)

Hi, I just noticed a broken cite journal date in an article. The publication was "date = January-March 1969" but the system doesn't like this, so I changed it to "date = January 1969". But how should a date range be specified? Thanks, Esowteric+Talk 14:30, 13 October 2014 (UTC)

Use an endash instead of a hyphen. Did the link in error message not answer your question? If not, how can we improve it?

Date with hyphen. January–March 1969.{{cite book}}: CS1 maint: date format (link)

Date with endash. January–March 1969.

—Trappist the monk (talk) 14:46, 13 October 2014 (UTC)

Ah, thanks! Sorry, I was in too much of a dash and didn't correctly read the help. Esowteric+Talk 14:48, 13 October 2014 (UTC)

Hello, I am looking for a template similar with {{cite web}}, that is capable to accept the date in the YYYY-MM-DD format and then to transform it into the desired output.

Imagine for example a template named {{cite web US}}, where, when I specify the date like "date= 2014-01-07", it will show it like "January 7, 2014" (or "January 7th, 2014").

And another template named {{cite web UK}}, where, when I specify the date like "date= 2014-01-07", it will show it like "7 January 2014" (or "7th of January 2014").

And then, each Wikipedia will translate that template into their own language. So when you create a reference (manually or automatically), you only have to specify the data in the universally YYYY-MM-DD format, so you don't have to bother to understand how that language outputs the date. For example, at Spanish Wikipedia, "date= 2014-01-07", will output "7 de enero de 2014". Therefore, the same reference can be translated and adapted everywhere (in any other Wikipedia), and then when you use it, you don't need to know how each language outputs the date.

To be more specific, the following reference:

• {{cite web US |url=http://www.bbc.com/news/science-environment-26488432 |title=Elephants recognise human voices |newspaper=BBC |date= 2014-03-10 |author=Victoria Gill |accessdate= 2014-09-26}}</ref>

will output it like:

• Victoria Gill (March 10, 2014). "Elephants recognise human voices". BBC. Retrieved September 26, 2014.

on Spanish Wikipedia, it ({{cite web YMD}}) will output it like:

• Victoria Gill (10 de marzo de 2014). "Elephants recognise human voices". BBC. Consultado el 26 de septiembre de 2014.

Is there such a template, or can anyone create such template? Thanks —  Ark25  (talk) 10:45, 14 October 2014 (UTC)

There isn't such a template as far as I know. There was a time when something similar was done based on a user preference setting. That functionality went away. The history of that in in the {{citation}} or {{citation/core}} archives I think. The problem as I see it is that here at en.wiki, each article can have its own date format style which may or may not be specified by templates like {{use dmy dates}} and {{use mdy dates}}. Templates can only deal with information that they are given so unless each template includes a date format parameter of some sort, it will have no way of knowing what the article requires.

—Trappist the monk (talk) 11:18, 14 October 2014 (UTC)

This has had a lot of discussion over the years. See User:Gadget850/FAQ/YYYY-MM-DD dates, especially reference 4. Bottom line: write the article and the references with the date styles desired. --  Gadget850 ^talk 11:41, 14 October 2014 (UTC)

The various Citation Style 1 templates did format dates according to user pref setting (known as "dynamic dates") - for about six weeks in December 2008-January 2009. Not only was it technically complicated, it was also unpopular. In more general terms, Wikipedia deprecated the use of dynamic dates in late 2009, and the facility for performing that function was removed from the MediaWiki software itself with the release of MediaWiki 1.21 in March 2013. It's not coming back. --Redrose64 (talk) 16:38, 14 October 2014 (UTC)

Wait, I don't need something so deep as a special MediaWiki functionality or article-wide settings for how to output the data. I don't want the template to interfere with any settings. I just need a new template, with this tiny feature: to accept the data field specified in YYYY-MM-DD format and to output it in a certain way. Such a functionality would make it much easier to translate Wikipedia articles from one language to another, because you won't have to bother to translate the dates of every single reference you have in the translated articles. —  Ark25  (talk) 17:31, 14 October 2014 (UTC)

I suggest User:Ohconfucius/script/MOSNUM dates. When you edit it gives you options on the side bar to convert all dates to the desired format. This will ensure the entire article is unified, not just the citations. If you add it to your global.js, it should be available cross wiki. --  Gadget850 ^talk 18:13, 14 October 2014 (UTC)

Sorry, I don't need anything like unifying an entire article. I just need the template to output the date as I say. I tried it other way, using the {{date}}, it works, but it doesn't work with subst:

This one works:

• <ref name="MyUser_BBC_October_15_2014c">{{cite web |url=http://www.bbc.com/news/uk-england-25462900 |title=How do zoos prepare for dangerous animal escapes? |newspaper=BBC |date= {{date|2014-04-18|mdy}} |author=Laurence Cawley |accessdate= {{date|2014-10-15|mdy}}}}</ref>

And this one doesn't work:

• <ref name="MyUser_BBC_October_15_2014c">{{cite web |url=http://www.bbc.com/news/uk-england-25462900 |title=How do zoos prepare for dangerous animal escapes? |newspaper=BBC |date= {{subst:date|2014-04-18|mdy}} |author=Laurence Cawley |accessdate= {{subst:date|2014-10-15|mdy}}}}</ref>

—  Ark25  (talk) 22:34, 14 October 2014 (UTC)

subst: never works inside <ref>...</ref>, this is a known problem, and is not specific to one template (or group of templates). There's nothing that we can do about it except wait for the existing bugzilla: reports to be actioned. --Redrose64 (talk) 00:13, 15 October 2014 (UTC)

Thanks, it looks like there is already a bug report for it: https://bugzilla.wikimedia.org/show_bug.cgi?id=72079 —  Ark25  (talk) 09:09, 16 October 2014 (UTC)

See also cite journal and quarterly publications]]

I want to use a {{harvnb}} with a year parameter of 1828. See here, the date in the publication is given as "February & June MDCCCXXVIII" which before the introduction of CS1 could be dealt with as in a {{cite book}} with the parameters set to the following values "month=February & June |year=1828" or as "year=1828 |date=February, June 1828" How to deal with it now as CS1 barfs on "date=February, June 1928" (Help:CS1 errors#bad date). Of course one can use "date=February–June 1828" or even "date=June 1828", but that is a distortion of date in the source.

{{cite book |title=Date months with an ndash: |date=February–June 1928}} Date months with an ndash:. February–June 1928.

{{cite book |title=Two months fails: |date=February, June 1828}} Two months fails:. February, June 1828. {{cite book}}: Check date values in: |date= (help)

-- PBS (talk) 19:12, 14 October 2014 (UTC)

It looks like that source is the February and June issues of The Foreign Quarterly Review in a single binding. The June issue appears to begin on page 403 – if you 'search in this book' for "list of the principal new works", google will show you two search results at pages 395 and 750. I think that simplifies the problem: cite the issue that contains your source material. If you want to cite the whole book, use the "Published in... as a subtitle: |title=The Foreign Quarterly Review: Published in February & June MDCCCXXVIII and set |date=1828.

—Trappist the monk (talk) 20:27, 14 October 2014 (UTC)

Rather bizarre case, especially if there were any intervening issues. Perhaps they published three times a year, and combined two issues? Something like a single "January—February" issue would be ordinary enough, while two separate issues bound together would cited individually. This seems more like a book which was compiled from two issues, and the "February & June" seems more like a note of the original source than a subtitle. But if you go with this as a date I'd say use "date=February—June 1828". ~ J. Johnson (JJ) (talk) 21:25, 14 October 2014 (UTC)

There are a number of web sites which give their preferred citation in the form "YEAR onwards" (e.g. the Angiosperm Phylogeny Website – see [3]) or "YEAR+" (e.g. the Euro+Med database – as one example see [4])). I recall pointing this out when the date processing in the cite/citation templates was updated. Yet dates of this form produce errors. Peter coxhead (talk) 16:11, 15 October 2014 (UTC)

Because WP:DATESNO does not support open-ended date ranges (2001–, or 2001+, or 2001 onward, etc.), and in some cases discourages them, CS1 does not support open-ended date ranges.

—Trappist the monk (talk) 16:59, 15 October 2014 (UTC)

But if these are the standards recommended by major websites (and I can list several more) then they should be supported. They are really part of the "external titles and quotes" given by WP:DATESNO: using them is just using the citation given in the source. I use several of these sources very regularly and am very reluctant to have to give up the template in favour of plain text, which is what I will have to do if they aren't supported. Peter coxhead (talk) 17:08, 15 October 2014 (UTC)

The CS1 templates are designed to comply with the MoS, including WP:DATESNO. Thus the place to start this is WP:DATESNO. --  Gadget850 ^talk 17:26, 15 October 2014 (UTC)

My understanding/memory of the Wikipedia guidance on citing websites is that those sites are in the wrong (in the sense that "YEAR onwards" is unnacceptably ambiguous as to the version of the source consulted) and in this case one can ignore the given date and must use |accessdate= to identify the date you consulted the source. Just because a source asks us to cite in a particular way does not mean we have to, particularly if the format is not fit for our purposes.

--TuxLibNit (talk) 18:31, 15 October 2014 (UTC)

@TuxLibNit:, @Gadget850: so to be clear you would not use |date= at all for such websites, just |accessdate= (which of course I always give)? Peter coxhead (talk) 10:17, 16 October 2014 (UTC)

@Peter coxhead:Well I can't speak for Gadget850 but I expect I would omit |date= in this case even if it was a free text field that could accept "<year> onwards" without the red warnings. For me, "<year> onwards" contains almost no useful information, and none at all once "Retrieved on <date>" is given.

– TuxLibNit (talk) 16:49, 18 October 2014 (UTC)

Is there any particular reason why {{Cite journal}} displays page numbers in a format unlike the rest of the cite x series of templates? Why is p. or pp. missing here? Resolute 17:27, 15 October 2014 (UTC)

{{cite journal|author=Author|title=Title|journal=Journal name|pages=56-62}}

{{cite book|author=Author|chapter=Chapter name|title=Book Title|pages=56-62}}

Examples above. – Jonesey95 (talk) 17:35, 15 October 2014 (UTC)

Don't know. Perhaps it's because the various templates that eventually became CS1 were independently developed. You might research the the template histories and report back.

—Trappist the monk (talk) 18:17, 15 October 2014 (UTC)

• "test". test: 5.
• "test". test: 5.
• "test". test: 5.
• "test": 5. {{cite journal}}: Cite journal requires |journal= (help)
  • Looks like the work or journal (or other alias) parameter suppresses this for some reason. That's... just odd, especially when I want to cite a magazine's title. But I don't know enough about how the CS1 modules work to go further than that. This actually came up in a GA review because the reviewer didn't see that the page number is included, just formatted inconsistently compared to book and newspaper sources. I think my immediate solution is to simply use Cite News instead of Cite Journal for my magazine cites. Resolute 18:56, 15 October 2014 (UTC)

Or use |pages=pp. 56-62. ‑‑Mandruss (talk) 19:01, 15 October 2014 (UTC)

Not recommended; the extra pp. will be injected into the citation's COinS metadata. Very often, {{cite journal}} includes |volume= and |issue= parameters so perhaps the all-numeric formatting arises from that association.

The {{cite journal}} page handling has been done the way it has been for a long time: Compare the old {{citation/core}} version with the current version:

—Trappist the monk (talk) 19:22, 15 October 2014 (UTC)

{{Cite journal}} states that the p. or pp. is displayed (i.e., added) unless |work= or |nopp=y is present. That appears to be incorrect, and either the code or the doc should be fixed. ‑‑Mandruss (talk) 19:36, 15 October 2014 (UTC)

The documentation is correct:

{{cite journal|title=test|page=5}} → "test": 5. {{cite journal}}: Cite journal requires |journal= (help)

{{cite journal|title=test|journal=Journal|page=5}} → "test". Journal: 5.

|journal= and |work= are aliases of each other.

—Trappist the monk (talk) 19:47, 15 October 2014 (UTC)

Interesting. I am fairly certain the templates once displayed the p. and pp., but I can't really argue against that that cite comapre tool. And I have used cite magazine for years. Rather surprising that I haven't picked up on this before. Thanks! Resolute 19:51, 15 October 2014 (UTC)

{{cite journal}} is primarily used for citing peer-reviewed academic journals ({{cite magazine}} has redirected to {{cite journal}} for some years, but I don't know why), and the people who mainly use peer-reviewed academic journals prefer to omit abbreviations like "vol.", "no." and "p.", preferring instead a system of boldface and parentheses. --Redrose64 (talk) 19:56, 15 October 2014 (UTC)

That is along the lines of what I figured, and also why I seriously dislike the idea of template consolidation in many cases. It seems that a possible solution is to split the journal prameter out as its own option which disables those abbreviations, but leave them on by default for the work/magazine/other aliases. Resolute 22:47, 15 October 2014 (UTC)

People who mainly cite peer-reviewed academic journals normally use a style manual that treats all sources in a reasonably unified manner, and which does not switch between using "p." or "pp." or not depending on what kind of work is being cited. Such style manuals also don't radically change the position of the publication date depending on what kind of source is being cited; an RFC concluded the date behavior should be fixed, but developers have preferred to fix other things. Jc3s5h (talk) 22:54, 15 October 2014 (UTC)

That's quite a stretch, Ttm, to say that the doc is correct if you've been around long enough to know the aliases of |work= (or to know that you have to check for possible aliases to make effective use of the doc). But I've been down this road before at Wikipedia. ‑‑Mandruss (talk) 19:58, 15 October 2014 (UTC)

Pretty sure that I did not write anything that was not true. But if you believe otherwise, perhaps you can back up your claim and show me where I went wrong. This is a quote from the {{cite journal}} documentation:

• work: Name of the source periodical; may be wikilinked if relevant. Displays in italics. Aliases: journal, newspaper, magazine, periodical.

page and pages do not show p. or pp.

—Trappist the monk (talk) 21:02, 15 October 2014 (UTC)

Volume was bolded in January 2006.[5] I don't see it ever used the page abbreviations. {{cite magazine}} was created as a redirect in 2006 with the summary of "creating redirect, 'cause I keep forgetting what the real template is called."

The documentation is correct, but I wrote it based on how the template worked. --  Gadget850 ^talk 21:08, 15 October 2014 (UTC)

Ttm: Yes, but elsewhere on that very long page, it says the following:

page: The number of a single page in the source that supports the content. Use either |page= or |pages=, but not both. Displays preceded by p. unless |nopp=y or |work= is defined.

[followed by similar language for pages:]

There is nothing there that tells the user, Don't take this literally, dummy. When we say "work=", what we really mean is, "work=, or any of its aliases".

The user should not be expected to have read the entire very long page and absorbed everything on it. Inexperienced users know nothing of aliases, and good doc is written for inexperienced users. They are the users who have the greatest need for the doc. ‑‑Mandruss (talk) 21:26, 15 October 2014 (UTC)

Here is the complete documentation section:

• work (required by {{cite journal}} and {{cite magazine}}): Name of the work containing the source; may be wikilinked if relevant. Displays in italics. If the name of the periodical changed over time use the name at the time of the source's publication. If script-work is defined, use work to hold a Romanization (if available) of the title in script-work. Aliases: journal, newspaper, magazine, periodical, website. Use Latin script. For languages written in non-Latin based scripts (Arabic, Chinese, Cyrillic, Greek, Hebrew, Indic, Japanese, Korean, etc.) use a standard Romanization in this field.
  • script-work: Work title in its original, non-Latin script; not italicized, follows italicized Romanization defined in work (if present). Must be prefixed with one of the supported language codes to help browsers properly display the script. Leave empty for Latin-based scripts (Czech, French, Turkish, Vietnamese, etc.). Aliases: script-journal, script-newspaper, script-magazine, script-periodical, script-website.
  • trans-work: English translation of the work title if the source cited is in a foreign language. Displays in square brackets after work or script-work. Aliases: trans-journal, trans-newspaper, trans-magazine, trans-periodical, trans-website.

    ... |work=Zhōngguó piàofáng |script-work=zh:中国票房 |trans-work=China Box Office ...

  • issue: When the publication is one of a series that is published periodically. Alias: number. When the issue has a special title of its own, this may be given, in italics, along with the issue number, e.g. |issue=2, ''Modern Canadian Literature''. Please choose either |issue= or |number= depending on what is used in the actual publication. If a publication carries both issue and number designations (typically one being a year-relative and the other an absolute value), provide them both, for example |issue=2 #143. Displayed in parentheses following volume.

When set, work changes the formatting of other parameters in the same citation:

title is not italicized and is enclosed in quotes.

chapter does not display (and will produce an error message).

As noted, if and only if work or one of its aliases is defined, then the formatting changes are applied. If you use {{cite journal}} and don't define work then the formatting is not applied. --  Gadget850 ^talk 21:50, 15 October 2014 (UTC)

I understand that, but the point I am struggling to make is that a user will not go to the doc for the work parameter for information about the page parameter. Instead, he will go to the doc for the page parameter, and it says nothing about work aliases there. Again, the doc is correct only if taken in its entirety, which is not how doc is used. ‑‑Mandruss (talk) 21:57, 15 October 2014 (UTC)

So allow me to state the obvious: If the documentation that we have is unsatisfactory, change it until it is. If you would like assistance in understanding what something does, ask, I'll help. I can't necessarily answer the why, but I can probably tell you the what where and when. We know that documentation is never good enough; help make it better.

—Trappist the monk (talk) 23:12, 15 October 2014 (UTC)

If I'm understanding how the pieces fit together, the element that needs to be changed is Template:Citation Style documentation/pages. It currently contains the phrase: or work is defined. This phrase needs to read: or work or one of its aliases is defined. If possible I would like to link to the subsection that defines those aliases, which is currently titled "journal", as or '''work''' or one of [[#journal|its aliases]] is defined. Will this work there, and is there any reason the link shouldn't be done that way? ‑‑Mandruss (talk) 01:43, 16 October 2014 (UTC)

Can't hurt to try. I would suggest an alternate text: or '''work''' (or an [[#csdoc_work|alias]]) is defined.

—Trappist the monk (talk) 11:00, 16 October 2014 (UTC)

The master template is {{citation Style documentation}}; each section has an [edit subtemplate] link. Every entry has an anchor, in this case it is "csdoc_work". --  Gadget850 ^talk 14:13, 16 October 2014 (UTC)

Done. Two edits, here and here. {{Cite journal}} looks good and the links work. Doc for other Cite templates displays as before, and that's the desired result as I understand it. Thank you. ‑‑Mandruss (talk) 15:38, 16 October 2014 (UTC)

@Gadget850: I don't think that it's quite true to say "every entry has an anchor" - the one in question was added by myself just a few days ago and a few minutes later I added another. I expect there are plenty more that I've not got around to yet. --Redrose64 (talk) 21:06, 16 October 2014 (UTC)

Does anyone know how to go about adding more than one publisher to a book citation? I've got a scenario where a source has two publishers in the same country who jointly published the book - but I don't know how to put the second publisher into the cite template. Thanks! Miyagawa (talk) 16:54, 16 October 2014 (UTC)

There may not be a great solution here. CS1 is not designed to accommodate multiple values except in the |author= and |editor= parameters. If you can, choose one publisher and use that one, especially if that one is a much better known publisher, presumably the one listed first on the book's title page. You could then add a note following the {{cite book}}: also Location:Second Publisher. Alternately, if the two publishers are in different locations, leave out |location= and then do something like this: |publisher=First Publisher, Second Publisher (jointly).

—Trappist the monk (talk) 18:02, 16 October 2014 (UTC)

Great, thanks for the advice. Miyagawa (talk) 18:47, 16 October 2014 (UTC)

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:

• Machu Picchu
• Neutral Zone of Junik
• Arshad Hasan
• Hyde Park (Burkeville, Virginia)

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)

For the record, I did eventually update my stats to correct errors in my analysis identified from GoingBatty's comments, then added another 20 pages and used those results to guide some updates to the help. TuxLibNit (talk) 21:41, 10 October 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)

ReferenceBot sounds particularly promising. Regarding recruitment of gnomes, I have to admit that I also started fixing ISBN errors as a result of the red text but I also can't help thinking that there must be a better way. TuxLibNit (talk) 21:41, 10 October 2014 (UTC)

This obscure discussion has suddenly generated '000s of error messages all over the wiki, many relating to very simple "errors" that are generated by current "official" template-filling tools inbuilt to the editing page that throw up dates like "2012 Mar". You can't fix those by bot??? Really? You can't change the tools first??? The whole situation is absurd. Look at Pancreatic cancer for example. Wiki CRUK John (talk) 14:03, 16 October 2014 (UTC)

@Wiki CRUK John: Hopefully you started at the top of this section and read about BattyBot, which has fixed over 50,000 articles with CS1 date errors, including running five times on the Pancreatic cancer article since December 2013. Making the errors visible to all users will hopefully keep people from adding additional incorrect dates into the article, and encourage people to do the necessary manual cleanup to reduce the number of articles with errors so the bot can run more often. GoingBatty (talk) 00:40, 17 October 2014 (UTC)

Fixing the official ref toolbar in the editing window so it doesn't continue to generate "errors", or indeed changing the MOS so that it accepts perfectly unambiguous forms like "2012 Mar", would seem more efficient and realistic approaches to this. Wiki CRUK John (talk) 12:14, 17 October 2014 (UTC)

OK, so what are we supposed to do with a date like 370 BC, then? That isn't an error, but one is reported. Chiswick Chap (talk) 19:48, 19 October 2014 (UTC)

If such citations are legitimate, they must be so rare that a hand-crafted citation will suffice. CS1 is a general purpose tool suitable to most applications but not all.

Just to satisfy my own curiosity, what are you citing that is nearly 2,400 years old?

—Trappist the monk (talk) 21:24, 19 October 2014 (UTC)

"370 BC" could go in |origyear=, with the publication date of the source you are actually citing (and viewing with your own eyes), or to which you are referring readers, in |date=. – Jonesey95 (talk) 01:06, 20 October 2014 (UTC)

Cite4Wiki Phoenix is a Firefox extension intended to make it easier to generate citations for a page which you are currently viewing. It has a number of features which are configurable in order to generate citations formatted as desired for the article which you are working on. The point of view is that the tool should do a good job at generating values for parameters, but ultimately the user is in control of what actually goes in the citation.
Some feature highlights:

• Extensible page scraping for any/all parameter(s)

There is not yet a GUI to make it easy to extend the page scraping Profiles, but page scraping configurations are read from a file with each Profile (a domain, or subset of a domain) in JSON format. The user can specify a file containing their own definitions.

• Includes fleshed-out profiles for many different websites (many news outlets, JSTOR, HighBeam, Questia, PubMed, arXiv, archive.org, WebCite, Google Books, etc.)
• Includes a decent default page scraping definition for domains for which there is not a specific one available.

• Automatic and semi-automatic preemptive archiving (Archive.org and/or WebCite) with easy display of the archive page for user verification.

• Automatic detection of some failures and fallback to the other archiving site.

• Automatic and semi-automatic case formatting for parameters (user selectable, both what type of casing change and what parameters)
• Uses TemplateData (when available) for determining available parameters and if there are duplicated aliased parameters (warns user).
• "Picker": single click selection of text elements within a webpage and applied to the parameter.
• Automatic parsing of author and editor names into first/last (can be overridden by user).
• Unlimited number of authors and/or editors, or user can specify a maximum number to use.
• Available user selection of the contents of all <meta /> tags on the page.
• Automatic selection of the appropriate citation template (based on dynamic or static selection in the Profile used).

• User selection of any Citation template (including all CS1 templates)
• The list of templates is user definable, or free-form while citing a page.

• User selection of citation layout format: horizontal/vertical/vertical with "=" lined up

• Option to display in vertical format and automatically use horizontal when copying to the clipboard

• Date formats in DMY/MDY/YMD
• Automatic and semi-automatic naming of references (user configurable, name defined in the Profile used for the site or a random number component is generated).

A couple of example citations:
<ref>{{cite news |url=http://www.bloomberg.com/news/2014-10-15/ebola-outbreak-boosts-odds-of-mutation-helping-it-spread.html |title=Ebola Outbreak Boosts Odds of Mutation Helping It Spread |last1=Langreth |first1=Robert |last2=Cortez |first2=Michelle Fay |last3=Lauerman |first3=John |date=October 15, 2014 |work=[[Bloomberg News]] |publisher=[[Bloomberg L.P.]] |accessdate=October 19, 2014 |others=Photographer: John Moore/Getty Images |editor1-last=Gale |editor1-first=Reg |editor2-last=Putka |editor2-first=Gary |editor3-last=Pollack |editor3-first=Andrew |location=[[New York, NY]] |archiveurl=//web.archive.org/web/20141019230955/http://www.bloomberg.com/news/2014-10-15/ebola-outbreak-boosts-odds-of-mutation-helping-it-spread.html |archivedate=October 19, 2014 |deadurl=no}}</ref>^[1]

<ref name="PubMed-22012269">{{cite journal |url=https://www.ncbi.nlm.nih.gov/pubmed/22012269 |title=Requirements for Empirical Immunogenicity Trials, Rather Than Structure-Based Design, for Developing an Effective HIV Vaccine |last=van Regenmortel |first=M. H. |date=January 2012 |journal=Arch Virol |publisher=Springer |accessdate=19 October 2014 |issue=1 |doi=10.1007/s00705-011-1145-2 |volume=157 |pages=1–20 |pmid=22012269}}</ref>^[2]

This follow-on to Cite4Wiki is a work in progress. This release should be considered to be an alpha or beta level release. I have been using Cite4Wiki Phoenix to make citations for some time now and found it to be quite useful.

It would be helpful to have input from others on any and all aspects of the tool. This includes anything (e.g. bug reports, desired/missing features, GUI changes, page scraping issues, lack of CS1 compliance, etc.). You can add it to Firefox from Mozilla Add-ons. — Makyen (talk) 23:56, 19 October 2014 (UTC)

T71964

On the October 23 update, templates with duplicate parameters will be tracked by a category defined in MediaWiki:duplicate-args-category.[6][7] --  Gadget850 ^talk 14:00, 20 October 2014 (UTC)

It looks like this new category will apply to all templates, not just citation templates. That will be fun. I could not tell from the code diffs whether there will be an error message associated with this categorization, to make it easier for editors to identify the location of the offending template. Can you tell whether there will be such a message, or whether we'll be able to add one here on the English Wikipedia?

For what it's worth, Citation Bot finds duplicate parameters in citation templates and converts the first instance of each duplicate to |DUPLICATE_parameter-name= (e.g. |DUPLICATE_title=). If there is no error message, we can run Citation Bot on the new category and it will create CS1 "unsupported parameter" errors for us. – Jonesey95 (talk) 03:02, 21 October 2014 (UTC)

Yes, this applies to all templates. The category defaults to Category:Pages using duplicate arguments in template calls. Duplicate parameters will only put the page into the tracking category; there is no provision to display an error. --  Gadget850 ^talk 17:07, 21 October 2014 (UTC)

I seem to be seeing dates indicated as "spring 1969" or "fall 1993" or "Nov./Dec. 1983" on the original publications showing an error when the date= field of the cite template inserts that value. That seems silly; we ought to be able to declare the exact date of a dated publication that is issued quarterly or bimonthly, for careful bibliographic work. You can find examples by page-searching for "(help)" in my user bibliography for updating articles. This brand-new error message isn't helpful to editors. -- WeijiBaikeBianji (talk, how I edit) 17:03, 21 October 2014 (UTC)

The template enforces the Manual of Style, and none of the dates you specified meet the MOS:DATEFORMAT format standard:

• Title. spring 1969. {{cite book}}: Check date values in: |date= (help)
• Title. Spring 1969.
• Title. fall 1969. {{cite book}}: Check date values in: |date= (help)
• Title. Fall 1969.
• Title. Nov./Dec. 1983. {{cite book}}: Check date values in: |date= (help)
• Title. November–December 1983.

--  Gadget850 ^talk 17:15, 21 October 2014 (UTC)

@WeijiBaikeBianji: I agree that it is critical for the Wikipedia citation clearly provide accurate date information so users can find the source for careful bibliographic work. Note that this source uses "Fall", while you used "fall" on your userpage. Wikipedia has its own house style for capitalization and punctuation that might be slightly different than some publishers.

BattyBot is fixing incorrect dates like those you mentioned in articles (e.g. this edit from June), but not on user pages. Also note that abbreviated months are also OK if that is consistent with the reference format of the Wikipedia article:

• Title. Nov–Dec 1983.

Thanks! GoingBatty (talk) 17:34, 21 October 2014 (UTC)

In most cases, we are not at a point where the information in a citation can be, or should be, matched character-for-character to the corresponding data provided by the publisher. Like all style manuals I have ever seen, the data from the publisher is adjusted to conform to Citation Style 1. Jc3s5h (talk) 17:57, 21 October 2014 (UTC)

Thanks for the speedy replies. I used the examples I just encountered to expand the help page for this error message. -- WeijiBaikeBianji (talk, how I edit) 18:01, 21 October 2014 (UTC)

• "The template enforces the Manual of Style, and none of the dates you specified meet the MOS:DATEFORMAT format standard" - perhaps the template does enforce the MOS itself, but if so it is wrong to do so. That MOS section begins: "These requirements do not apply to dates in quotations or titles. Special rules apply to citations; see Wikipedia:Citing sources § Citation style." - aka WP:CITESTYLE. That section begins "While citations should aim to provide the information listed above, Wikipedia does not have a single house style, though citations within any given article should follow a consistent style.". If "Spring 1969" is how the source dates itself, that is the correct and only correct dating to use, and it the template's job to allow that - ideally including capitalization at least, but not punctuation. It is entirely wrong to attempt to twist citation dates to meet the general MOS article text dating rules. Wiki CRUK John (talk) 11:34, 22 October 2014 (UTC)

I'm somewhat baffled by what you wrote. CS1 is one of several citation styles in use at Wikipedia. Each of the standard styles listed at WP:CITESTYLE no doubt has its own particular rules for date format. Why should CS1 be any different? CS1 chooses to follow the style rules enumerated in Wikipedia's Manual of Style. If you wish to create articles that comply with APA, or with The Chicago Manual of Style, or whatever, then to be in compliance with the chosen style, you must render dates and other details as the style specifies. This same is true if you wish to use CS1 to style your citations. If you wish to create articles that mimic the styles used by your sources, you are of course free to do so. In that case, CS1 may not be useful to you.

CS1 allows |date=Spring 1969 but not |date=spring 1969. I'm not sure I understand what you mean by If "Spring 1969" is how the source dates itself, that is the correct and only correct dating to use, and it the template's job to allow that - ideally including capitalization at least, but not punctuation.

—Trappist the monk (talk) 12:11, 22 October 2014 (UTC)

I concur with Trappist the monk. The citation in question from your user page:

• Jensen, Arthur R. (spring 1969). "How Much Can We Boost IQ and Scholastic Achievement?". Harvard Educational Review. 39 (1): 1–123. ISSN 0017-8055. Retrieved 15 October 2014. {{cite journal}}: Check date values in: |date= (help)

The linked source uses "Spring 1969" so I don't see the issue at all.

I have done a bit of cleanup on dates just to see the problems; most are simple typos that we now hope that editors will catch and repair quickly. --  Gadget850 ^talk 12:55, 22 October 2014 (UTC)

Yes, Wiki CRUK John, that's a good point. If the Wikipedia manual of style itself doesn't impose a house style on how dates are mentioned in original sources (as some other style guides, such as those I used to work with in professional editing, do), then Wikipedia's citation templates might just as well allow as valid date formats any date format actually encountered in reliable sources. In any event, once a citation throws an error message and a Wikipedian like me follows the link to the help page, I hope the help page is informative (through specific examples) about what the error is and how to fix it. Thanks for the further comments here. -- WeijiBaikeBianji (talk, how I edit) 18:00, 22 October 2014 (UTC)

CS1 forms a distinct citation style which is described at "Help:Citation Style 1". The "CS1 compliance with Wikipedia's Manual of Style" section of that document states "CS1 uses Wikipedia:Manual of Style/Dates and numbers §§Dates and years (WP:DATESNO) as the reference for all date format checking performed by Module:Citation/CS1." So although Wikipedia in general does not apply the date rules in Wikipedia's "Manual of Style" to citations, CS1 does. Jc3s5h (talk) 18:13, 22 October 2014 (UTC)

But if CS1 enforces date styles more strictly than WP:CITESTYLE requires, the unfortunate consequence is that editors may choose not to use templates for those citations which are acceptable under WP:CITESTYLE but not to the CS1 templates. This means that metadata, etc. is lost, and is surely undesirable? This seems a classic case of the best being the enemy of the good: by being too strict, usefulness may be lost. Peter coxhead (talk) 19:18, 22 October 2014 (UTC)

The bots have reached a point of diminishing returns. Should we remove the date checking altogether? This would allow dates such as "posted on Tuesday, September 16, 2008", "05 tháng 08 năm 2014", "2nd cent.", "31 November<newline>2009" and the like. IF we just relax the error checking, what is allowable? --  Gadget850 ^talk 20:00, 22 October 2014 (UTC)

@Gadget850: conceptually it's easy for me to answer: in citations, we should allow editors to use date styles according to WP:CITESTYLE, i.e. those which editors have deliberately used and for which there is support in style manuals or published sources. Turning this into an algorithm is a different issue. It does seem to me that anything which is bot-fixable is almost certainly an error and so should be corrected. I myself wouldn't leave "red marking" of supposed date errors in place. At the least it should be possible for an editor to turn it off for individual references.
My real objection is to what seems to be Jc3s5h's view, namely that the cite templates should be restrictive rather than trying to encourage their use by supporting a range of styles where this is possible. Peter coxhead (talk) 09:00, 23 October 2014 (UTC)

We should leave date error messages in place until obviously wrong dates like "12/4/11" and "1975, 1986" have been fixed. – Jonesey95 (talk) 17:00, 23 October 2014 (UTC)

Historically, citation templates were created to produce consistently formatted citations, just like most style guides demand. Any value the parameter values might have as metadata was a by-product. To say that what we really care about is the metadata, and we no longer care that templates tend to produce a consistent style, is a reversal of the original purpose of citation templates, so would require a well-advertised RfC to be accepted. Jc3s5h (talk) 17:12, 23 October 2014 (UTC)

@WeijiBaikeBianji: our MOS does actually specify which date formats can be used for citation dates in an article. Under MOS:DATEUNIFY, it says:

Publication dates in an article's citations should all use the same format, which may be

• any format from the "Acceptable date formats" table, or
• formats required by the citation style being used.
• However, all-numeric date formats other than yyyy-mm-dd must still be avoided.

and:

Access and archive dates in an article's citations should all use the same format, which may be:

• yyyy-mm-dd, or
• the format used for publication dates in the article, or
• the format required for the citation style adopted in the article.

In other words, if a Wikipedia article is citing a newspaper article dated today in the APA style, "2014, October 23" would be the appropriate date format. However, if that same Wikipedia article is using CS1 in its references, then it needs to follow the "Acceptable date formats" table, and the templates used for CS1 style are enforcing those formats.

@Wiki CRUK John and Peter coxhead: CS1 has its own style guide, which is Help:Citation Style 1. If editors want to use APA instead of CS1, and WP:CITESTYLE and MOS:DATEUNIFY both allow that option, then they need to consult the current edition of the Publication Manual of the American Psychological Association. However, the CS1 templates are their own style, so editors should not mix and match thinking it's acceptable. Imzadi 1979 → 15:17, 23 October 2014 (UTC)

Of course people have no idea there is such a thing as "Citation Style 1" or that they are using it, they just use the tool provided in the default editing window, which gives no indication of this. Wiki CRUK John (talk) 17:06, 23 October 2014 (UTC)

@Imzadi1979: no citation style manual – and I've both them in my academic career and taught postgraduate students how to cite and reference – ever covers all the possible complications in dealing with real publications rather than the idealized ones in the examples in the manual, and I've never come across a journal editor who didn't understand this. No-one is arguing that obviously incorrect dates should not be flagged dealt with, only that there needs to be some way of flexibly dealing with less straightforward cases which do occur (open-ended dates and discontinuous dates are two examples). Peter coxhead (talk) 17:26, 23 October 2014 (UTC)

For me, it's enough to have a help page that lists the actual "error" I'm encountering as I use the templates, with examples that suggest what "problem" has been identified by the automatic check, and what I can do as a careful editor to fix the problem. I attempted to fix the help page that the error message links to as soon as I saw the first part of the helpful discussion here. I have a lot of habits that carry over from years of editing print publications according to the Chicago Manual of Style that I've gradually had to unlearn as I do more editing on Wikipedia. I can unlearn old habits and practice new habits more efficiently if a help page linked to an error message takes me directly to the answer to my problem. (Thanks to all of the editors here for your helpful comments.) -- WeijiBaikeBianji (talk, how I edit) 17:42, 23 October 2014 (UTC)

Peter coxhead, above you seemed to argue that CS1 templates should accommodate a range of choices. Many style manuals do mandate certain date formats; a publication date of "July 12, 1962" used as a publication date in APA style would be an obvious error. If someone who will submit a manuscript to a journal that requires APA asked me to copy-edit the manuscript, it would be my job to fix it. But in your earlier post, you seemed to say CS1 should only flag date formats that no English-speaker would ever use. But your later post seems to indicate that a style manual cannot anticipate every situation, and should allow flexibility when it is impossible to both comply with the style manual and correctly convey the date information (which I agree with). So which is your position? Jc3s5h (talk) 18:33, 23 October 2014 (UTC)

They are different but related issues. The issue immediately above, on which it seems we agree, is independent of Wikipedia policies. I would go further within the English Wikipedia, which explicitly allows an extremely wide range of citation styles. The citation templates obviously can't support all of them, but I believe the value of the templates – including, but not limited to, some degree of consistency, error-checking, and providing metadata – is such that they should try to support more variation than would be permitted within in a "normal" publication. Where exactly to draw the line is open to discussion. I assume we would all agree that "31 February 2014" should be flagged as an error. However, although it's desirable to standardize "spring" to "Spring", it's perfectly meaningful to a reader, and I'm not convinced that it's sensible to generate a red error notice in an article in such cases. Peter coxhead (talk) 21:39, 23 October 2014 (UTC)

The advantage of limiting the choices in CS1 is when an editor (or sometimes, even a bot) comes an article that uses CS1 templates, but the style of the parameters is inconsistent, the editor immediately knows what to change them to, rather than having to go through the article history to see which style was first, or count the instances of different usages to see which one has a plurality. Jc3s5h (talk) 21:49, 23 October 2014 (UTC)

"Limiting choices" is a broad and less than ideal phrasing. More palatable subsets would be error detection and consistency enforcement. But the primary purpose of the templates is to format the supplied data; all the rest is added layers of complexity. While it seems to reasonable to go as far as checking for missing data and outright errors (like "32 May"), perhaps even capitalization and quasi-errors like "Juni" and "Oktober", I wonder how far the template itself should enforce consistency. Especially in matters where even human judgements might well differ. Would it not be better to have some alternate method of doing that, rather than loading the template with code for enforcing somewhat subjective and potentially variable notions of consistency? ~ J. Johnson (JJ) (talk) 19:45, 25 October 2014 (UTC)

I have removed parameters |albumlink=, |albumtype=, |artist=, |publisherid= from Module:Citation/CS1/Configuration/sandbox and Module:Citation/CS1/Whitelist/sandbox. The parameters were deprecated when {{cite AV media}}, {{cite AV media notes}}, and {{cite DVD notes}} were migrated from {{citation/core}} to Module:Citation/CS1.

I am currently running an AWB script that looks for these parameters and am replacing what ones I find – there aren't many.

—Trappist the monk (talk) 16:34, 25 October 2014 (UTC)

What about |notestitle=? Have we discussed |titlelink=, |director =, |titleyear =, ? --  Gadget850 ^talk 16:54, 25 October 2014 (UTC)

Here are some old conversations

Music release notes

AV media notes

DVD notes

So, yeah, we have talked about them. A CirrusSearch insource:// search turned up one instance of |notestitle= that isn't part of a CS1 template. There are less than 20 instances of |titleyear=. The same CirrusSearch for |director= turns up nearly 450,000 pages. I tried doing a regex search that forces CirrusSearch to include the pipe. That got the count down to 8800ish. A more complex regex search restricting the search to {{cite anything}} got me a gateway timeout. Which pretty much leaves me with brute force testing each of the 7,800ish pages that use these template

My script is also looking for |titleyear= and |director=.

Any instances of these parameters that are still in the wild after the next live module update will cause unknown parameter errors. We should probably add them to Module:Citation/CS1/Suggestions

—Trappist the monk (talk) 17:51, 25 October 2014 (UTC)

My script has finished so I've now removed |director=, |notestitle=, and |titleyear= from Module:Citation/CS1/Configuration/sandbox and Module:Citation/CS1/Whitelist/sandbox. I have also removed |day= with attendant changes to Module:Citation/CS1/sandbox.

My script is currently working on replacing |cointerviewers= with |others=.

—Trappist the monk (talk) 11:30, 27 October 2014 (UTC)

As part of this change, I've made |interviewer= and new parameter |interviewers= 'official' aliases of |others= and tweaked Module:Citation/CS1/sandbox to use the meta parameter Others. I'll run a script after the next update to harmonize the |interviewer=, |cointerviewers=, and |others= parameters in {{cite interview}}.

It was probably premature to change |cointerviewers= to |others=. Mea culpa.

—Trappist the monk (talk) 15:11, 27 October 2014 (UTC)

Hello, I have noticed that the chapters in edited collections are not working correctly. For example, the following template:

• {{cite book |first=Marie |last=Lall |title=Indian education policy under the NDA government |work=Coalition Politics and Hindu Nationalism |editor1=Katherine Adeney |editor2=Lawrence Saez |publisher=Routledge |year=2005 |ISBN=0-415-35981-3}}

is producing the following displayed text:

• Lall, Marie (2005). Katherine Adeney; Lawrence Saez, eds. Indian education policy under the NDA government. Coalition Politics and Hindu Nationalism (Routledge). ISBN 0-415-35981-3.

The correct display (which used to be the case till recently) is:

• Lall, Marie (2005). "Indian education policy under the NDA government", Katherine Adeney; Lawrence Saez (eds) Coalition Politics and Hindu Nationalism (Routledge). ISBN 0-415-35981-3.

It looks like there was an update to the template recently, which is breaking things. Specifically, the authors of the chapter and the editors of the collection are being combined. The chapter title and the book title are being combined. This is very confusing! Kautilya3 (talk) 14:57, 27 October 2014 (UTC)

You have to specify a chapter for the chapter styling to take effect:

{{cite book |first=Marie |last=Lall |chapter=Indian education policy under the NDA government |title=Coalition Politics and Hindu Nationalism |editor1=Katherine Adeney |editor2=Lawrence Saez |publisher=Routledge |year=2005 |ISBN=0-415-35981-3}}

Lall, Marie (2005). "Indian education policy under the NDA government". In Katherine Adeney; Lawrence Saez (eds.). Coalition Politics and Hindu Nationalism. Routledge. ISBN 0-415-35981-3.

|work= is not synonymous with |title=.

—Trappist the monk (talk) 15:15, 27 October 2014 (UTC)

I took a quick search through the archives but I don't see mention of this. Some of the historical journals that I reference for railroad history are issued quarterly and their issue dates read like "First quarter YYYY" through "Fourth quarter YYYY". When I put that information into the date parameter, the page gets added to CS1 errors: dates even though this specification is valid according to WP:SEASON. Typing "the first quarter of YYYY" instead of "first quarter YYYY" seems nonsensical for a citation, so I've used the shorter of the two versions.

So what I guess I'm asking is this: how should I be entering journal issue dates when the journal is issued quarterly and specifies the quarter number in its official issue date rather than the month name? Thanks! Slambo (Speak) 16:33, 13 October 2014 (UTC)

CS1 doesn't support quarterly dates per se; and WP:DATESNO, from which CS1 takes its date format guidance, is mute on the topic. You might write |date=January–March YYYY.

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

I would not change the description of the date that the journal used; the reader might wonder if the quarters are based on the journal's fiscal year or the calendar year observed by society in general. It's best if the words in the citation match the words on the cover of the journal (but minor changes in capitalization and punctuation are OK; "FIRST QUARTER" could be changed to "First quarter.") If you don't like the red error message, format the citation by hand and don't use CS1. CS1 is incapable of describing some sources. Jc3s5h (talk) 14:56, 28 October 2014 (UTC)

You could also use |issue=Fourth quarter YYYY. I don't think that would break anything, but I am wrong multiple times every day. – Jonesey95 (talk) 15:30, 28 October 2014 (UTC)

You could also split it: |date=YYYY and |issue=Fourth quarter. Both |date= and |issue= are included in the COinS metadata. Splitting would at least allow the citation to sort by year.

—Trappist the monk (talk) 15:43, 28 October 2014 (UTC)

This would be complicated if the periodical also has volume and issue numbers. I suppose the one in my case could be done as |volume=11 and |issue=2 – Second quarter along with |year=1973. Sincerely, SamBlob (talk) 23:49, 28 October 2014 (UTC)

Or we could add "First Quarter XXXX", "1st Quarter XXXX", "Q1 XXXX", etc to the error checking as allowed options and make a note that just as we capitalize season names when used as dates of publication, we have a set of allowed formats for these quarterly publications. I'm neutral on capitalization on the word quarter. but I would recommend the Q1 type format as an option to go along with abbreviated month names in other dates. Imzadi 1979 → 01:23, 29 October 2014 (UTC)

Is this one of those 'great minds' coincidences? I've been wondering much the same thing: if MOS is mute on a topic, we can make our own rule. I don't think that ordinal quarters should be used because MOS:BADDATEFORMAT proscribes the use of ordinals in other date styles. I'm ambivalent about Q1, Q2, ...; too informal I think. Certainly First quarter, Second quarter, ... Should quarter be capitalized or no?

—Trappist the monk (talk) 02:17, 29 October 2014 (UTC)

I have a copy of the Second Quarter 1973 issue of Automobile Quarterly that I have used as a reference in articles on Triumph, Messerschmitt, and ALCO automobiles in general, and on the Alfa Romeo 8C 2900 and first generation of the Pontiac Grand Am in particular, as the magazine has articles on these cars.

However, the date given for the magazine is "Second Quarter 1973", and this triggers an error response in the "date" entry in Template:Cite journal. Is there a solution to this, other than just giving a year and a volume and issue number instead of the date as stated in the magazine?

Sincerely, SamBlob (talk) 14:22, 28 October 2014 (UTC)

This is the same topic as Help talk:Citation Style 1/Archive 6#cite journal and quarterly publications.

—Trappist the monk (talk) 14:42, 28 October 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 amazon.com.

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 |asin-tld=co.jp:

"幽☆遊☆白書 其之一 (1) 霊界死闘 編(SHUEISHA JUMP REMIX) (単行本)" [Yū Yū Hakusho (1) Spiritual Guide: Deathmatch (SHUEISHA JUMP REMIX) (Paperback)] (in Japanese). Amazon.com. ASIN 4081097011. Retrieved September 2, 2013. {{cite web}}: Check |asin= value (help)

The second uses |isbn=4081097011:

"幽☆遊☆白書 其之一 (1) 霊界死闘 編(SHUEISHA JUMP REMIX) (単行本)" [Yū Yū Hakusho (1) Spiritual Guide: Deathmatch (SHUEISHA JUMP REMIX) (Paperback)] (in Japanese). Amazon.com. 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 amazon.com#Website.

—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, co.jp, co.uk, de, es, fr, it, so we need to add z.cn (China), amazon.in (India), amazon.com.mx (Mexico), amazon.com.au (Australia) and amazon.com.br (Brazil). --  Gadget850 ^talk 21:36, 24 September 2014 (UTC)

India is already supported. I don't see any reason to do anything about z.cn since it gets mapped to amzon.cn. I have added support in the sandbox for Australia, Brazil, and Mexico.

• Chandra, Bipan. History of Modern India. ASIN 8125036849. {{cite book}}: Check |asin= value (help) – 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)

Now that Category:CS1 maint: ASIN uses ISBN exists, I've written an AWB script that removes |asin-tld= and removes or replaces |asin= with |isbn= when |asin= has the form of a 10-digit ISBN. The script validates the content of |isbn= before replacement or removal.

I've noticed that the value assigned to some |asin= identifiers is 9 digits. It occurs to me to wonder if we shouldn't be doing at least a length check on the |asin= value. So I've hacked the sand box:

• Title. ASIN 123456789. {{cite book}}: Check |asin= value (help)
• Title. ASIN B234A678D. {{cite book}}: Check |asin= value (help)
• Title. ASIN 123GOOD890. {{cite book}}: Check |asin= value (help)
• Title. ASIN B1234A6789D. {{cite book}}: Check |asin= value (help)

Anyone ever seen a functioning |asin= that is not 10 characters? Ever seen one that is anything but uppercase letters and digits?

—Trappist the monk (talk) 23:08, 29 October 2014 (UTC)

There was a link to a bare-bones description of ASINs in the Refs at Amazon Standard Identification Number. I just added another. – Jonesey95 (talk) 00:07, 30 October 2014 (UTC)

Thanks for that. I've tweaked the test a bit so that it will emit an error message if a 10-digit |asin= value fails the isbn10 test:

• Title. ASIN 1421560046. {{cite book}}: Check |asin= value (help)
• Title. ASIN 1421560045. {{cite book}}: Check |asin= value (help)

Do we think its true that alpha-numeric asins always begin with a letter? If we do, that is one last thing to test (the third example above would be an error condition).

—Trappist the monk (talk) 10:34, 30 October 2014 (UTC)

Assuming that we do, I've tweaked amazon() so that now mixed alpha numeric asins must begin with an uppercase alpha:

• Title. ASIN 123456789. {{cite book}}: Check |asin= value (help) – not enough characters
• Title. ASIN B234A678D. {{cite book}}: Check |asin= value (help) – not enough characters
• Title. ASIN 1234BAD89. {{cite book}}: Check |asin= value (help) – mixed alpha numeric begins with digit
• Title. ASIN B1234G6789. – pass
• Title. ASIN B1234A6789D. {{cite book}}: Check |asin= value (help) – too many characters
• Title. ASIN B1234-6789. {{cite book}}: Check |asin= value (help) – invalid character

—Trappist the monk (talk) 15:35, 31 October 2014 (UTC)

I propose to update {{Cite DVD notes}} (366 transclusions) to {{Cite AV media notes}} (7666 transclusions). Thoughts? --  Gadget850 ^talk 11:48, 31 October 2014 (UTC)

I presume by this that you mean to redirect {{cite DVD notes}} to {{cite AV media notes}}. Module:Citation/CS1 handles them as if they were the same so I see no problem doing this and think that we should. I don't see any reason to have a separate CS1 template specifically for DVD notes.

Is this related to the removal of |people= and |medium= from Cite AV media/doc (diff) and |titlelink= from Cite AV media notes/doc (diff)?

—Trappist the monk (talk) 12:23, 31 October 2014 (UTC)

I think you meant "to {{Cite AV media notes}}". I would update the uses with AWB as well. And I thought we had deprecated those parameters. --  Gadget850 ^talk 12:42, 31 October 2014 (UTC)

Yeah, copy pasta strikes again. Fixed.

The parameters that Module:Citation/CS1 considers deprecated are listed at Help:CS1_errors#Cite_uses_deprecated_parameters. As a backup check, one can always look in Module:Citation/CS1/Whitelist for parameter names assigned the value false. For example, ['albumlink'] = false.

I would like to see us deprecate |people= I think. This because that parameter seems to collect a bunch of stuff that ought not be there: |people=Sam Smith (Director), Joe Shmoe (Producer). Such parameter values do rather add clutter to the metadata. Don't know what the proper solution is but we should bend our minds to finding one.

—Trappist the monk (talk) 13:41, 31 October 2014 (UTC)

I was just thinking a bit about this yesterday and then overnight, a ping from Editor GoingBatty caused me to do this experiment. In Module:Citation/CS1/sandbox I have added <span class="nowrap">...</span> to the value assigned to |accessdate=. The code looks for the three MOS compliant date formats and wraps accordingly. YYYY-MM-DD is completely wrapped and for the other two, Mmm dd, yyyy and dd Mmm yyyy, the code wraps everything but the last space and the year. Invalid date formats aren't wrapped.

I have seen ISBNs that wrapped inappropriately so those and perhaps other identifiers are candidates for nowrap. Is there anything else that should be prevented from wrapping in inappropriate places?

—Trappist the monk (talk) 11:30, 18 October 2014 (UTC)

I'm glad this is getting some attention. But am I understanding correctly? You think it's OK to wrap between October and 18, but not between 18, and 2014?

Lack of sensible wrapping in ISBNs, DOIs, and so on is one of my biggest peeves about the citation templates, so I hope those can be rationalized as well. But they're way too long to be simply nowrapped. EEng (talk) 14:36, 18 October 2014 (UTC)

Better table.

—Trappist the monk (talk) 15:27, 18 October 2014 (UTC)

Yeah, but what you said is, "the code wraps everything but the last space and the year." That sounds wrong. The effect should be October{{nbsp}}18, 2014 or 18{{nbsp}}October, 2014, but it sounds like you're saying something like October 18,{{nbsp}}2014. Have I got it wrong? EEng (talk) 23:02, 18 October 2014 (UTC)

@EEng: I read that as, "the code wraps everything [in the span tags] but the last space and the year". Imzadi 1979 → 23:13, 18 October 2014 (UTC)

This: <span class="nowrap">October 18,</span> 2014, <span class="nowrap">18 October</span> 2014, and <span class="nowrap">2014-10-18</span>.

—Trappist the monk (talk) 00:07, 19 October 2014 (UTC)

Just curious: 1. Why is this about accessdate and not the other CS1 dates? 2. Are we talking about appearance in the reflist and the citation tooltip? ‑‑Mandruss (talk) 23:39, 18 October 2014 (UTC)

1. No doubt there are other things that could/should be given the nowrap css class. |accessdate= is convenient for testing. And it is at the end of the rendered citation so perhaps has a greater chance of wrapping improperly. 2. Yes.

—Trappist the monk (talk) 00:07, 19 October 2014 (UTC)

Ok. I would ask how publications with high MOS standards would handle this. I'm thinking they would break a date only at a comma, but it should be possible to verify that with a style manual. Or the question could be asked at WP:Reference desk/Language. ‑‑Mandruss (talk) 00:19, 19 October 2014 (UTC)

What is a high MOS standard?

—Trappist the monk (talk) 00:25, 19 October 2014 (UTC)

I mean close attention to matters of form as opposed to substance, such as is used at newspapers like NYT. They have what I would call a high MOS standard, whereas my local town newspaper has a lower MOS standard. Btw, I don't see any guidance on the question in WP:DATES. ‑‑Mandruss (talk) 00:41, 19 October 2014 (UTC)

Don't know about them. We have MOS:NBSP and if you read between the lines at WP:DATESNO (see the ranges section at MOS:DOB) you can see how dates are formatted to prevent line-wrapping.

—Trappist the monk (talk) 01:00, 19 October 2014 (UTC)

• This is very important... take a look at WP:Manual_of_Style/Dates_and_numbers#Non-breaking_spaces. You can't infer much if anything from the absence of nbsp at any given point in any given example. For whatever reason, there hasn't been enough trouble about where nbsp is/should be used for MOS to give comprehensive treatment of the question (with respect to dates or, generally, anywhere else, with a maybe a few exceptions). EEng (talk) 01:47, 19 October 2014 (UTC)

I went ahead and asked the question at WP:Reference desk/Language, without mentioning the reason for asking, as that might affect the replies. There are a few smart language guys watching that page. ‑‑Mandruss (talk) 01:57, 19 October 2014 (UTC)

Sorry, but I think that's an extremely poor idea. Most editors will say, with some justice, that this kind of machinery should follow MOS, and if MOS needs clarification it should be done in a MOS discussion. By asking at Refdesk you're just inviting a lot of personal opinions or old remembered style rules. EEng (talk) 03:45, 19 October 2014 (UTC)

Did you read what I posted there? I specifically said I was not looking for personal opinions. If any are given, I will ignore them. If our MOS were clarified as to this question, I suspect it would be made consistent with major style manuals—why wouldn't it?—which is what I asked for in my post. The major style manuals are regularly updated per modern trends, so they don't represent "old remembered style rules". That said, it wouldn't be my first extremely poor idea! ‑‑Mandruss (talk) 03:54, 19 October 2014 (UTC)

I just consulted my three style guides, (APA 6th ed., CMOS 16th ed., and MLA 7th ed.), and all three are silent on this issue. That's not too surprising to me since this is more a matter of typesetting. MOS:NBSP does say, "It is desirable to prevent linebreaks ... within expressions such as 17 kg, AD 565, 2:50 pm; in other places where breaking across lines might be disruptive to the reader ...." I've always interpreted that to mean that it is undesirable to have a number separated from other content to which is explicitly related. I edit a lot of highway articles, and we encourage fellow project members to use non-breaking spaces in things like "exit 326", "Route 66" or "US 41" to keep the number together with the text because that is one name. That name forms a unit that should be parsed together. This follows the advice and review commentary I've received in working on Featured Articles over the years, and I would say that the day of a month and the month are similarly a single unit. Now in WP:MOS#Years and longer periods, and advice I've been given over the years, tells me that years can be parsed as a separate unit.One of the examples in the list following that quotation from MOS:NBSP above shows "May 2014" with a non-breaking space to keep them together. Sadly, no examples deal with full dates or months and days taken together. <span style="color:Imzadi 1979 → 05:40, 19 October 2014 (UTC)

Ok, thanks for the research and the rest. That satisfies me, and it sounds consistent with Ttm's opening post. Ttm, you could collapse beginning with my 00:19, 19 October comment, if you like, as everything after it followed from it. ‑‑Mandruss (talk) 06:19, 19 October 2014 (UTC)

CS1 has a bunch of date-holding parameters: |accessdate=, |airdate=, |archivedate=, |date=, |doi-broken-date=, |embargo=, |laydate=, |publication-date=. Question 1: Should some or all of these be protected from inappropriate line-wrapping?

I have created a function nowrap_date() that, at the moment, can protect any date in one of the three formats YYYY-MM-DD, DD Mmmm YYYY, and Mmmm DD, YYYY. These are the only allowable date formats for |accessdate= so if it is to be used with other date-holding parameters it will need to be expanded to support date formats allowable there.

Here are the other date formats:

1. Mmmm DD–DD, YYYY
2. DD–DD Mmmm YYYY
3. DD Mmmm – DD Mmmm YYYY
4. Mmmm DD – Mmmm DD, YYYY
5. DD Mmmm YYYY – DD Mmmm YYYY
6. Mmmm DD, YYYY – Mmmm DD, YYYY
7. Winter YYYY–YY
8. Summer YYYY–YYYY
9. Mmmm YYYY – Mmmm YYYY
10. Mmmm–Mmmm YYYY
11. Mmmm YYYY
12. YYY–YYY or YYY–YYYY or YYYY–YYYY or YYYY–YY

Question 2: If the answer to Question 1 is affirmative, then where should browsers be allowed to break the other dates? It seems that for #1 and #2, the rule is the same as for date formats DD Mmmm YYYY and Mmmm DD, YYYY but what about the others?

—Trappist the monk (talk) 14:50, 1 November 2014 (UTC)

Don't forget DD Mmm YYYY, and Mmm DD, YYYY (abbreviated months). Does Mmmm–Mmmm YYYY and Mmmm YYYY include the seasons too? Thanks! GoingBatty (talk) 19:28, 1 November 2014 (UTC)

Please stop playing around with {{cite web}} immediately. For the first time in years, almost all preformatted dates and accessdates are suddenly "rejected" by this template with a nasty error message. Please put it back where it was. These are not "errors". Thanks, Poeticbent talk 18:09, 13 October 2014 (UTC)

@Poeticbent: Please give a few examples. --Redrose64 (talk) 18:34, 13 October 2014 (UTC)

• I really have no time for this but here are a few examples: 1.^[1] 2.^[2] 3.^[3] 4.^[4] 5.^[5]

— Preceding unsigned comment added by Poeticbent (talk • contribs) 18:53, 13 October 2014 (UTC)

See the linked help page, which references MOS:BADDATEFORMAT

1. "2014-10-7" is missing a leading 0
2. "5 October 2014." includes a period
3. "1974, 1995, 2013" my swag is this should use |origyear=
4. "5 October 2014." includes a period
5. "1992; 1998" is an ambiguous date; this should use |origyear=

--  Gadget850 ^talk 19:03, 13 October 2014 (UTC)

(edit conflict) OK, here we go. In (1) there is |accessdate=2014-10-7 this should be |accessdate=2014-10-07 - a zero is missing; in (2) there is |accessdate=5 October 2014. this should be |accessdate=5 October 2014 - the full stop is invalid; in (3) there is |year=1974, 1995, 2013 this should be |origyear=1974|year=2013 - only one year per parameter should be given, and the 1995 is superfluous since all we need are the year of the edition that was actually used plus (optionally) the original year of publication; in (4) there is |accessdate=5 October 2014. - full stop again; in (5) there is |year=1992; 1998 this should be |origyear=1992|year=1998 as with (3). --Redrose64 (talk) 19:05, 13 October 2014 (UTC)

• Please stop defacing articles with this nonsense. A zero missing in 7: 07? A full stop again after 2014? How many thousands of articles have them... and, for God's sake, who cares if the full stop is invalid! The dates are there. They are readable and easy to trace. Unless your intention is to fix all these "errors" yourself, please let go of scare tactics. Thanks, Poeticbent talk 19:24, 13 October 2014 (UTC)

The intent is to improve the quality of the citations by providing error checking that complies with the Manual of Style. We have had the date checking for several months, but have not displayed the error. This has allowed bots to repair thousands of bad dates. But now we are down to dates that cannot be automatically fixed and need human intervention, thus the errors now show. --  Gadget850 ^talk 19:34, 13 October 2014 (UTC)

• The "errors" do not show, only the "error message" shows like a sore thumb. The actual numbers (which are dates added by users in a matter-of-factly way) remain hidden from the reader. This whole affair is ripe for some kind of intervention. I wonder how many articles are affected by this new red monster across the entire project. Poeticbent talk 20:11, 13 October 2014 (UTC)

What you're asking is that a programmer should (1) be able to imagine every possible way that an editor could screw up a date in a way that doesn't rise to the level of "error", and (2) spend the time to include toleration of those screw-ups in the code. Have you done much programming? That's simply not practical short of something approaching artificial intelligence. Feel free to start an RfC to ask whether the community would rather have the errors or the red errors reminding editors to correct the errors. I'll be there to negate your !vote. ‑‑Mandruss (talk) 20:36, 13 October 2014 (UTC)

You can see the articles with date errors by looking at Category:CS1 errors: dates, which currently has 60,874 articles in it, which is a decline on what it was the last time I looked before the error message was turned on. This is good as it was steadily rising before that and the BOTs could only fix some of the new article errors. Keith D (talk) 23:54, 13 October 2014 (UTC)

• Do you guys hear me at all... or you're just to wrapped up in your own chain of sorrow. Twenty four hours went by, and the number of articles affected by this new red monster has gone from 60,874 articles to 60,698 total. Some 176 articles were fixed... sixty thousand six hundred ninety eight articles remain defaced. At this rate, all silly pseudo-errors will be fixed in 344 days providing that no new articles get written and no new references added with even more of those. I'm taking this page off my watchlist. Poeticbent talk 23:25, 14 October 2014 (UTC)
  • Whilst I want to remain neutral on the actual issue myself, my overall feeling is that consensus is against you on this thread, at least. I think that, if you want to overturn this, the best way to go is to follow others' advice here and start an RfC. It Is Me Here ^{t / c} 14:03, 15 October 2014 (UTC)

Part of me says this thread should be allowed to die a natural death. According to the OP, s/he has given up trying to get through to us morons. But I'm the only one who has mentioned RfC, so if we're encouraging the OP to start one I guess I should clarify what I meant. For starters, I said "feel free to", which is not the same as "advice" to do so. To the contrary, I think it would be a really bad idea, and a waste of people's time. I was not referring to an RfC to ask whether CS1 should flag some some undefinable set of date errors that don't actually prevent the reader from understanding the date. As I said, that is not practical, and we don't ask programmers to do impractical things. That RfC would be a snow close before it got started. What I meant was an RfC to ask whether CS1 should flag any date errors at all. I was only half serious about that, I know it would fail, and I don't think it's what the OP wanted. ‑‑Mandruss (talk) 14:34, 15 October 2014 (UTC)

An obscure discussion higher up the page has suddenly generated '000s of error messages all over the wiki, many relating to very simple "errors" that are generated by current "official" template-filling tools inbuilt to the editing page that throw up dates like "2012 Mar". You can't fix those by bot??? Really? You can't change the tools first??? There is in any case no ambiguity there, so no actual need to fix anything. I don't see why a bot can't fix other errors like filling leading zeros to numbers between 1-9. The whole situation is absurd. Look at Pancreatic cancer for example. No-one is ever going to fix all all these errors, and realy why should they bother. I would certainly support an RFC. Let me know if one launches. Wiki CRUK John (talk) 14:03, 16 October 2014 (UTC)

Wiki CRUK John: BattyBot is fixing the errors you describe. It runs about once a month and looks like it will stop by to edit Pancreatic cancer in the next day or two. "2012 Oct" is not a valid date per the MOS, so it is flagged as invalid so that someone, or some bot, will fix it in order to present valid dates to our readers.

The date error messages were exposed for a while in 2013, then hidden for about a year after this RFC resulted in their being hidden until a bot could go through the error category and fix as many as were feasible. We did that, and the vast majority of remaining date errors require human intervention. We have solid evidence that at least some human editors are motivated by the red error messages to bring the dates into compliance with the MOS, which is linked from the help page that you see when you click on "help" immediately following the error message.

We have already alerted the maintainers of some citation-filling tools that their tools were being used to generate citations with formatting errors, and many of those tools have been fixed. If you use a particular tool that is generating citations with errors, contact the maintainer of that tool, and feel free to refer them to this Talk page for assistance. – Jonesey95 (talk) 14:37, 16 October 2014 (UTC)

When you wrote No-one is ever going to fix all all these errors, I expected a sea of red error messages. I found 13 in a list of 107; I fixed the five date errors and the six accessdate errors. The two url-missing-title errors (currently 100 and 102) are left for editors more knowledgeable on the topic to fix. It took me about five minutes.

—Trappist the monk (talk) 14:52, 16 October 2014 (UTC)

Thanks both, but @Trappist the monk, you know what you are doing, which most editors won't. Factor in a trip to the MOS to try to work out what is wrong, and the initial fix time rises hugely. Even at 5 minutes, with 68K pages to fix, and presumably new ones being added all the time, that's still 6,000-odd working hours. @Jonesey95, I have no idea who, if anyone, maintains the drop-down cite tool in the standard editing window, which I think isn't even a preference option nowadays. Do you? Wiki CRUK John (talk) 18:06, 16 October 2014 (UTC)

That would be Wikipedia:RefToolbar. --  Gadget850 ^talk 18:50, 16 October 2014 (UTC)

Thanks, I've raised it there, & we will see what, if anything happens. It still seems bizarre that in one part of the forest there is a tool busy generating "errors" and in another a team busy fixing them, without fixing the tool. Although some of the people seem the same. Wiki CRUK John (talk) 12:29, 17 October 2014 (UTC)

Yep, that's a lot of hours. But those errors were not created overnight; it has taken us multiple years to make them all and we didn't even know that we were doing it. Now the foot is in the other shoe.

—Trappist the monk (talk) 19:09, 16 October 2014 (UTC)

I worked error tracking cats for some time before the messages were turned on. I could see the messages, but only because I made some modification to my local configuration that I can't remember—something that would be beyond most editors even if they could find the instructions on how to do it. I remember thinking, "of course there are a lot of errors, the editors can't see the messages." I think being a quality encyclopedia, which is the goal, includes consistency in these date values. Since citations are at the core of what WP is about, their quality is as important as anything else an editor does. As for the backlog, see WP:WIP. We'll get there. ‑‑Mandruss (talk) 18:45, 16 October 2014 (UTC)

Regarding the error-fixing rate, my experience has been that once I get going, I can fix about 50–100 errors per hour, depending on how easy they are to fix and whether I need to click through to additional web pages to locate an unambiguous date. 60,000 errors will take a while to fix, but luckily, there is no deadline. Most of the erroneous dates are still human-readable and more or less understandable, so often it is a question of fixing formatting rather than content. – Jonesey95 (talk) 19:01, 16 October 2014 (UTC)