Help talk:Citation Style 1/Archive 37

Pointless whitespace error
The error "line feed character in" is not cool. Templates are supposed to be whitespace-agnostic, and if the template can detect the presence of an LF it can also strip it out for metadata purposes. This is an impediment to copy-pasting source details. — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  01:18, 3 October 2017 (UTC)
 * Line feeds create many more issues than just those concerning metadata, and they should be fixed at the wikitext level. Headbomb {t · c · p · b} 03:11, 3 October 2017 (UTC)
 * Somehow WP has failed to fall apart as the result of LFs being present, which they often can be. This is not a citation issue, and the citation template should not be barfing on cite data or metadata to try to force people to fix something they can't even see. The averaged editor probably doesn't even know what an LF .  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  06:04, 3 October 2017 (UTC)
 * WP also has also failed to fall apart as the result of vandalism. Doesn't mean vandalism shouldn't be fixed. Likewise for stray line feeds which can cause both rendering accessibility issues. Headbomb {t · c · p · b} 12:17, 3 October 2017 (UTC)
 * That's a WP:GREATWRONGS argument. Cite templates are the place to try to do anti-LF enforcement. Way, way out of scope. It's abusing a core function and necessity of the encyclopedia (citing sources) to try to arm-twist people into doing geek work for which many of them are not competent.  Don't insert work- or behavior-coercion "riders" into basic functionality templates. Have a bot look for LFs and remove them. This is what we have bots for. Also, your analogy is false; WP has failed to fall apart at the hands of vandals because and only because of the constant work a large number of anti-vandals. There is no huge cadre of anti-LF editors, and WP works just fine without one.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  20:25, 3 October 2017 (UTC) I've set up the bot request for you, at Bot requests/Archive 75. Feel free to make it more specific or whatever.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  21:27, 3 October 2017 (UTC)
 * Must say that this is a very useful feature of the templates as it catches many vandal edits as does the date error messages. Keith D (talk) 21:35, 3 October 2017 (UTC)
 * Bots can certainly assist in cleanup, but that doesn't mean the issue shouldn't be flagged in the first place. Headbomb {t · c · p · b} 01:22, 4 October 2017 (UTC)
 * As an average editor who learned what an LF was precisely because of this error, I agree that it's beyond the fixing capacity of many. That said, it is an error that ought to be identified because an invisible character in a URL is still a character and is contaminating the usefulness of the information. I see it as similar to date errors: while potentially difficult/unintuitive to fix, it causes problems, and so it needs to be identified. Leave the error message and get the bot to do its work. Triptothecottage (talk) 04:27, 4 October 2017 (UTC)

missing error handlers for cite bioRxiv and cite citeseerx
It somehow escaped us to include the error handlers for the cases where and  are missing their respective parameters biorxiv and citeseerx. That oversight has been remedied in the sandbox:

—Trappist the monk (talk) 11:10, 6 October 2017 (UTC)

collaboration-link
Can collaboration-link be made, analogous to author-link, etc.? Example @ K2K experiment. ~ Tom.Reding (talk ⋅dgaf) 14:57, 10 October 2017 (UTC)
 * Why? The purpose of author-link is to provide a way of linking a last, first pair because the two cannot be wikilinked. But, collaboration can be wikilinked:


 * —Trappist the monk (talk) 15:17, 10 October 2017 (UTC)
 * Ahh, my force of habit. Thanks!  ~ Tom.Reding (talk ⋅dgaf)  15:24, 10 October 2017 (UTC)
 * Ahh, my force of habit. Thanks!  ~ Tom.Reding (talk ⋅dgaf)  15:24, 10 October 2017 (UTC)

Only in plain text
I need to add the myself afterwards?! &mdash; fortuna  velut luna  17:19, 10 October 2017 (UTC)
 * If you want your reference to be in a footnote, yes. There are many cases where citations should not be in footnotes (for instance, when they are part of a separate list of references at the end of an article and the footnotes only give short links to them), so it would be a bad idea to bundle the footnoting code into the citation templates. —David Eppstein (talk) 17:46, 10 October 2017 (UTC)
 * Right, thanks a lot; I wanted to use the ref within the article (that would explain why it doesn't have a parameter for page nos, perhaps?), but as I said, it didn't like it! &mdash;  fortuna  velut luna  17:56, 10 October 2017 (UTC)
 * supports page numbers:
 * Why would you say that it doesn't. Can you provide an example showing that it doesn't?
 * —Trappist the monk (talk) 18:01, 10 October 2017 (UTC)
 * Thanks for your good faith there, Trappist. Was going by . &mdash; fortuna  velut luna  20:19, 10 October 2017 (UTC)
 * Here's a direct link to the documentation for page in cite thesis. – Jonesey95 (talk) 22:15, 10 October 2017 (UTC)
 * Thanks very much, I'll remember that. &mdash; fortuna  velut luna  14:02, 11 October 2017 (UTC)
 * Here's a direct link to the documentation for page in cite thesis. – Jonesey95 (talk) 22:15, 10 October 2017 (UTC)
 * Thanks very much, I'll remember that. &mdash; fortuna  velut luna  14:02, 11 October 2017 (UTC)

cite collection
Would it be possible to get a sub-class of cite encyclopedia for citing collections that are not encyclopedias? Perhaps "cite collection"? I realize there is no technical reason for this, but the semantic context is currently being obscured and that is a Bad Thing. Maury Markowitz (talk) 13:10, 13 October 2017 (UTC)
 * Rather than everyone imagining what it is that they think that you mean, perhaps you could supplement your request with a real-life (not contrived) example?
 * —Trappist the monk (talk) 13:35, 13 October 2017 (UTC)
 * Just use a redirect like Cite contribution if you are uncomfortable with the template name. Or make a new redirect at Cite collection. PrimeHunter (talk) 13:47, 13 October 2017 (UTC)

Years and Classical publications from Antiquity
This seems to throw an error when using dates of Classics

















It appears to need a three digit absolute magnitude value or greater. This is clearly an error in the processor. -- 70.51.46.15 (talk) 06:57, 11 October 2017 (UTC)
 * This topic is related to this citation? Forgive my skepticism, but I suspect that you are not directly citing a first century CE copy of Metamorphoses, but are citing a rather more recent edition.  That being the case, then the appropriate date for the citation would be the date of the source that you consulted.  At en.wiki, WP:SAYWHEREYOUGOTIT applies.


 * Also, your post here is a duplicate of a post you made at Help talk:CS1 errors/Archive 3. One conversation in one place only, please.
 * —Trappist the monk (talk) 11:22, 11 October 2017 (UTC)


 * Photographs of published Latin works do exist, and there have been digitization efforts as well. So, accessing such, would the date the work was digitized or photographed be your "source date" ? This is a generalized query, since I've used old Latin sources for other things in the past (though with triple or quadruple digit years) I would expect that the citation template should work for older dates as well. Some Wikipedian editors can read Latin or Greek or Hebrew or Chinese, so ancient documents are accessible to some of the general population of editors here at Wikipedia, thus the citation template should be able to support this editor population. -- 70.51.46.15 (talk) 05:23, 12 October 2017 (UTC)


 * Unless you're literally at a museum looking at manuscripts/tablets/whatever dating from antiquity, I don't see how there would be an issue. Can you give an example where the date of publication (not the date of authorship) of a source you cite would be in the double digits?
 * Edit: Personally for a well known text such at the Metamorphoses you can probably just do
 * That's generally how I've works like the CMoS say to cite classical works unless it really matters which edition you're using, e.g., if there's some debate as to the original text. Umimmak (talk) 09:29, 12 October 2017 (UTC)
 * I do not deny that facsimiles of sources exist nor that there are editors here who can read them. Facsimiles abound on the internet:
 * But apparently, there are no surviving first-century manuscripts of Metamorphoses (so says the en.wiki article). The lack of surviving first-century manuscripts and WP:SAYWHEREYOUREADIT suggest that citing Metamorphoses and using 8 AD is inappropriate.  Cite the source that you read.
 * When the cs1|2 templates were first written, there were technical reasons for limiting minimum year values to three digits. While the technical limitation no-longer applies because of new technology, the constraint was left in and, but for the occasional case like the one in hand, there has been little call to extend date-handling support to cover all time.  When the scholars of ancient texts take up their pitchforks and torches and clamber for ancient-date support in cs1|2, we can certainly consider it.
 * —Trappist the monk (talk) 11:18, 12 October 2017 (UTC)
 * Since Chinese over the last 2000 years is readable to modern Chinese readership, if they've been trained to read Classical Chinese (ie. 19th century Chinese and before) I would say that such sourcing would be expected for some topics. Or if you're a Brahmin and quoting Sanskrit sources of the past 3000 years. -- 70.51.46.15 (talk) 04:46, 14 October 2017 (UTC)
 * Again, the year something was originally written is distinct from the year of of the source the editor got the text from. Umimmak (talk) 05:34, 14 October 2017 (UTC)
 * There are still good reasons to mark three-digit years as an error. Most three-digit years, like "year=207", are typos for four-digit years, like "year=2017". The error check finds these frequently. – Jonesey95 (talk) 01:41, 13 October 2017 (UTC)
 * Shouldn't this be able to be specified with an override of some sort, like providing "BCE" or "AD" in the parameter ? Or a plus or a minus sign? (ie. French-style dates with minus-signs for BC dates) -- 70.51.46.15 (talk) 04:38, 14 October 2017 (UTC)
 * —Trappist the monk (talk) 11:18, 12 October 2017 (UTC)
 * Since Chinese over the last 2000 years is readable to modern Chinese readership, if they've been trained to read Classical Chinese (ie. 19th century Chinese and before) I would say that such sourcing would be expected for some topics. Or if you're a Brahmin and quoting Sanskrit sources of the past 3000 years. -- 70.51.46.15 (talk) 04:46, 14 October 2017 (UTC)
 * Again, the year something was originally written is distinct from the year of of the source the editor got the text from. Umimmak (talk) 05:34, 14 October 2017 (UTC)
 * There are still good reasons to mark three-digit years as an error. Most three-digit years, like "year=207", are typos for four-digit years, like "year=2017". The error check finds these frequently. – Jonesey95 (talk) 01:41, 13 October 2017 (UTC)
 * Shouldn't this be able to be specified with an override of some sort, like providing "BCE" or "AD" in the parameter ? Or a plus or a minus sign? (ie. French-style dates with minus-signs for BC dates) -- 70.51.46.15 (talk) 04:38, 14 October 2017 (UTC)


 * orig-year works well for citing the original publication dates of older works. – Jonesey95 (talk) 13:56, 11 October 2017 (UTC)
 * I think you need a date as well though, see: which produces  Umimmak (talk) 09:29, 12 October 2017 (UTC)






 * That "|orig-year=" indeed does not provide the year unless "|year=" is specified per Umimask. -- 70.51.46.15 (talk) 04:38, 14 October 2017 (UTC)

Special formatting for lists of works by an author.
This is a feature request. In lists of works by the subject of an article, eg. Andrea Gallo, I tend to use  so the date comes first. In works with more than one author, I wish there was a parameter for cite which would show the date first and then list secondary authors prefixed by "with" after the date. Thank you. Sondra.kinsey (talk) 16:52, 14 October 2017 (UTC)


 * May I point out that the first entry in any masked list should have the full citation reference, including the name of the author. Otherwise it is unclear what exactly you are masking. This holds for works by an article's subject as well, even when it is obvious who the author is. Secondly, in most citation applications, works are universally indexed by author(s) first (though some specialized systems may index by title/date rather than author/date). Since you decided to use CS1 to populate this list (a good idea, imo), the style should be followed. If this style doesn't suit your needs, I suggest formatting the list differently, without the strictures of CS1. 65.88.88.46 (talk) 17:55, 14 October 2017 (UTC)

Cite book problem
Does anyone know what is wrong with this?

which produces two errors:

SarahSV (talk) 00:33, 16 October 2017 (UTC)
 * I don't know, but retyping the chapter title (without changing the chapter URL) seems to have fixed it:
 * —David Eppstein (talk) 00:37, 16 October 2017 (UTC)
 * , thank you! I wonder whether there was an invisible character in the chapter title. SarahSV (talk) 00:40, 16 October 2017 (UTC)
 * U+200B zero-width space. With your cursor highlight the 'E' in 'End'.  Walk the highlight one character at a time to the right.  You will notice that it takes an extra step to get from the 'd' in 'End' to the chapter's closing double quote character.  And, interestingly enough, that is position 49 in the chapter parameter value, just as the error message said.  Isn't that amazing?
 * —Trappist the monk (talk) 00:49, 16 October 2017 (UTC)
 * (EC) There was one yes . You can find it by counting 49 character positions in chapter. Put your cursor there, hit delete. Nothing will apparently happen, but you've deleted the invisible character. Headbomb {t · c · p · b} 00:51, 16 October 2017 (UTC)
 * Thanks, everyone. SarahSV (talk) 22:34, 16 October 2017 (UTC)
 * (EC) There was one yes . You can find it by counting 49 character positions in chapter. Put your cursor there, hit delete. Nothing will apparently happen, but you've deleted the invisible character. Headbomb {t · c · p · b} 00:51, 16 October 2017 (UTC)
 * Thanks, everyone. SarahSV (talk) 22:34, 16 October 2017 (UTC)

automatic |format=pdf
In the wild I discovered a reference that rendered with the (PDF) annotation but the url did not point to a pdf file. Module:Citation/CS1 is confused by a url that ends '.pdf.html'.

Fixed in the sandbox.

—Trappist the monk (talk) 14:19, 17 October 2017 (UTC)

Example of book with journal-like properties, chapter authors and issue plus number indicators
Interesting example of a (hardcopy) book (with ISBN), which is part of a book series (with ISSN) and has volume, issue and number indicators (similar to a journal). Also, it contains at least one chapter by a pair of authors completely different from those authors responsible for the remainder of the book (and listed on the front cover) and the series editor. The volume number (V) is incremented every year, the issue number (I) is incremented for each book published in that year in the series (just like in a journal, except for that the number of issues in a year seems to be variable), and the number (N) is apparently a running number counting up from the first book in that publisher's series (the publisher publishes multiple series of books). So, I need either or both the cite book and cite journal template to support something like this:


 * Steinbach, Bernd; Posthoff, Christian. Chapter 3: Boolean Differential Calculus. In: Sasao, Tsutomu; Butler, Jon T. (2010-01-15). Thornton, Mitchell A., ed. "Progress in Applications of Boolean Functions". Synthesis Lectures on Digital Circuits and Systems. 4 (1) #26 (1st ed.). San Rafael, CA, USA: Morgan & Claypool Publishers: 55–78. ISBN 978-1-60845-181-4. ISSN 1932-3166.

Issues with the current template implementation:


 * The cite journal template does not support the chapter parameter. This is an artificial restriction based on the invalid assumption that there are no chapters in journal articles. Over the years, a lot of examples have been brought forward in older discussions showing that some longer journal articles do have chapters, and that it can be necessary to cite them individually. Let's fix this.
 * Also, it is necessary to support either series or work in parallel to chapter.
 * Since chapter author(s) are not always the same as the author(s) listed as article or book author(s) on the front, it is necessary to support a set of optional chapter-author* parameters when chapter is given as well. In some cases this can be worked around by abusing the editor* parameters to specify the book authors but the given example even has a series editor, so the editor* parameters are needed for him.
 * The cite book template currently ignores the issue and number parameters - but it should support them.
 * The cite journal template supports them, but handles both of them the same and does not allow both to be specified at the same time. Instead, it should allow both to be specified at the same time and (only) then use issue as a parameter for volume-specific numbers and number for independent numbers. I suggest to render this as:
 * V (I) #N
 * (If both issue and number cannot be put into meta-data at the same time, the number should be ignored in the meta-data (at least for the time being) but still be shown in the visual output.)
 * This would be a fully-backward compatible extension to the currently supported forms
 * V (I)
 * or
 * V (N)
 * if only one out of issue and number is given.

Thanks. --Matthiaspaul (talk) 01:39, 19 October 2017 (UTC)


 * Yeah I agree, it'd be nice to have issue number for books; right now a workaround is just to do, which seems to allow more options. I've also been using "contribution" if the author of a chapter isn't the author (not editor) of the rest of the book. Umimmak (talk) 02:06, 19 October 2017 (UTC)
 * I think I would just do this and move on:
 * That certainly gives readers enough information to be able to definitively locate the source. – Jonesey95 (talk) 03:25, 19 October 2017 (UTC)
 * Concur. cs1|2 is a general purpose citation tool that is adequate to the needs of most citation requirements.  It works quite well in that role.  Being a general purpose tool prevents it from being a specialized, handle--citation-needs tool.
 * —Trappist the monk (talk) 09:26, 19 October 2017 (UTC)
 * That certainly gives readers enough information to be able to definitively locate the source. – Jonesey95 (talk) 03:25, 19 October 2017 (UTC)
 * Concur. cs1|2 is a general purpose citation tool that is adequate to the needs of most citation requirements.  It works quite well in that role.  Being a general purpose tool prevents it from being a specialized, handle--citation-needs tool.
 * —Trappist the monk (talk) 09:26, 19 October 2017 (UTC)

internationalization
An editor at kn.wiki desires to fix the cs1|2 modules there; the original post about that is here.

Some months ago I tweaked the module suite at ht.wiki so that it worked correctly and as part of that added support for simple replacement of English month names with the appropriate Haitian Creole month names. Because date support at kn.wiki will have similar problems and because I would prefer to not have multiple variations of the base code at each different wiki (if it can be avoided) I have implemented the ht.wiki tweaks in the en.wiki sandbox. These changes should make it easier for other wikis to maintain currency with the en.wiki module suite.

—Trappist the monk (talk) 11:17, 19 October 2017 (UTC)

Long institutional author name with commas in it.
In Nancy Temkin I have a source whose authors are "National Research Council, Institute of Medicine, Board on Children, Youth, and Families, Committee on Sports-Related Concussions in Youth", which I have placed into the author parameter. This puts the article into an inappropriate maintenance category, Category:CS1 maint: Multiple names: authors list. It is not a multiple-name author list; it is a single institutional author name that happens to have commas in it. How do I avoid the maintenance category and the inevitable bot mangling of this name? —David Eppstein (talk) 17:34, 19 October 2017 (UTC)
 * You might consider rewriting the citation in the form that the publisher recommends on this page:
 * The publisher's recommendation seems to match the attribution stated on the cover image of the Google books facsimile except that it leaves off 'of the National Academies'.
 * The publisher's recommendation seems to match the attribution stated on the cover image of the Google books facsimile except that it leaves off 'of the National Academies'.
 * The publisher's recommendation seems to match the attribution stated on the cover image of the Google books facsimile except that it leaves off 'of the National Academies'.


 * Were it me, I'd write Institute of Medicine National Research Council because they are separate entities.
 * —Trappist the monk (talk) 18:00, 19 October 2017 (UTC)

Discussion on whether/how to add citations to papers on university repositories
Wikipedia talk:WikiProject Open

Cheers, Ocaasi (WMF) (talk) 23:15, 19 October 2017 (UTC)

Sfn / VE
Anywhere t establish how? Tried adding sfn template- two big lines with ref text results! CHEERS &mdash; fortuna  velut luna  13:37, 21 October 2017 (UTC)
 * What? I cannot decode what you have written.  Can you clarify?  Example?
 * —Trappist the monk (talk) 13:41, 21 October 2017 (UTC)


 * Yes indeed, many thanks! Using virtual editor- and trying to use the short notation. If it's used by inserting as a template, then the result is ->
 * Most odd! Any ideas, Trappist the monk? This is the article in question, btw. &mdash; fortuna  velut luna
 * No idea. Except that the  template is on its own line (shouldn't be), I don't see what you are seeing in the current article.  That makes me suspect VE (an abomination in my opinion – full disclosure here) or possibly, though unlikely, your browser.  Perhaps raise this issue at VisualEditor/Feedback.
 * —Trappist the monk (talk) 13:59, 21 October 2017 (UTC)
 * Many thanks Trappist the monk. Yes, I'l be returning to BASIC model at least in order to finish the blooming thing off. The annoying thing about VE (well one of them perhaps) is that it lures one in with how easy certain things are... and then does something like this to waste an hour of one's ******* editing time: FFS. Thanks for your advice, anyway! Take care. &mdash; fortuna  velut luna  14:07, 21 October 2017 (UTC)

Partial script-title and title mixup
The display of script-title and title is partially mixed up. What defines and therefore what should be displayed as the title of the work is always what is printed on the book or article itself (this holds true in general, even if the title is written in a foreign script). If known and necessary, it is helpful to also display transliterations and translations, however, since neither of them is without ambiguities (several transliteration systems existed and continue to exist, and translations are even more subject to interpretation) and they are therefore only weak identifiers, this is only auxiliary information, not authorative. If only one of the two parameters is given, the cite journal template displays them as title, which is fine. However, if both are given at the same time, the template displays the actual title (then given in script-title) only as secondary information (after the transliteration in quotes) thereby creating the invalid impression that the transliterated title would be the actual title. Example:



erroneously renders as:


 * Таланцев, А. Д. (1959). "Ob analize i sinteze nekotorykh električeskikh skhem pri pomośći special'nykh logičeskikh operatorov" б анализе и синтезе некоторых электрических схем при помощи специальных логических операторов [On the analysis and synthesis of certain electrical circuits by means of special logical operators]. Автоматика и телемеханика (in Russian). 20 (7): 898–907.

but should instead render as (round brackets added by me as another suggestion):


 * Таланцев, А. Д. (1959). "б анализе и синтезе некоторых электрических схем при помощи специальных логических операторов" (Ob analize i sinteze nekotorykh električeskikh skhem pri pomośći special'nykh logičeskikh operatorov) [On the analysis and synthesis of certain electrical circuits by means of special logical operators]. Автоматика и телемеханика (in Russian). 20 (7): 898–907.

There's another (only remotely related) issue: If only a trans-title is given, but neither script-title nor title, the template does not display a title at all. While this is not a hard error, I think it would be beneficial if the translation gets displayed anyway (in [brackets], of course), perhaps with an edit-time warning "Missing title parameter!" or similar. This would make it easier for editors to identify the actual source and retrofit the actual title.

--Matthiaspaul (talk) 18:16, 20 October 2017 (UTC)
 * On the only remotely related issue, yep, broken, now fixed in the sandbox:


 * And on the other, I think that the styling decision comes from this conversation.
 * —Trappist the monk (talk) 19:25, 20 October 2017 (UTC)
 * Thanks for the fix and the pointer - there's a lot of interesting stuff in that old thread, much appreciated.
 * --Matthiaspaul (talk) 13:53, 21 October 2017 (UTC)


 * Your view on the presentation of titles is not shared by The Chicago Manual of Style, which suggests that original titles in Chinese or Japanese characters be placed after the romanized title. (It does not suggest original titles for other non-Latin scripts.)  Nor is it plausible that anyone would mistake a romanized title placed before a script title for the original title – the only reason to include a title in a non-Latin script would be if it were the original title.  Kanguole 20:08, 20 October 2017 (UTC)
 * Thanks for pointing out CMOS' suggestions for Chinese and Japanese titles, I wasn't aware of them.
 * While I still find it somewhat counter-intuitive to not put the most authorative title first, and, according to the old thread, I'm not alone with that opinion, following an established standard is more important (unless there were strong reasons to not follow it). So, I agree with you that the order of titles should remain:
 * &lt;transliterated_title> &lt;scripted_title> &lt;translated_title>
 * What I did not find addressed in the other thread is the transliterated title to be put in "quotes". Somehow, I associate those quotes with the original title. So, with both script-title and title given, wouldn't it be better if the quotes were moved to the Cyrillic title? Like in:


 * Таланцев, А. Д. (1959). Ob analize i sinteze nekotorykh električeskikh skhem pri pomośći special'nykh logičeskikh operatorov "б анализе и синтезе некоторых электрических схем при помощи специальных логических операторов" [On the analysis and synthesis of certain electrical circuits by means of special logical operators]. Автоматика и телемеханика (in Russian). 20 (7): 898–907.
 * In some Asian scripts, the quotes could be replaced by corner brackets etc.
 * Only in absence of script-title the quotes should fall back to the "next-best" title representation in title.
 * Pros? Cons?
 * --Matthiaspaul (talk) 13:53, 21 October 2017 (UTC)


 * In the Chinese and Japanese examples given in CMOS, the romanized titles are surrounded by quote marks, and the original titles are unadorned. Kanguole 14:10, 21 October 2017 (UTC)
 * And that is how renders titles that include script-title:
 * And also how renders chapter titles that include script-chapter:
 * Similarly, for titles that would be italicized:
 * —Trappist the monk (talk) 15:00, 21 October 2017 (UTC)
 * Similarly, for titles that would be italicized:
 * —Trappist the monk (talk) 15:00, 21 October 2017 (UTC)
 * Similarly, for titles that would be italicized:
 * —Trappist the monk (talk) 15:00, 21 October 2017 (UTC)
 * —Trappist the monk (talk) 15:00, 21 October 2017 (UTC)
 * —Trappist the monk (talk) 15:00, 21 October 2017 (UTC)

edtf experiment removed
See 2 date parameter values. Because there is apparently no support for this 'solution', I have removed the experimental code that supported it.

—Trappist the monk (talk) 11:42, 19 October 2017 (UTC)
 * I think EDTF is a good idea, but in order to not confuse bots trying to make sense of the date parameter, perhaps it should be implemented as a new parameter like edtf-date or similar. --Matthiaspaul (talk) 00:28, 20 October 2017 (UTC)
 * If a bot is able to find and properly evaluate edtf-date it can find and properly evaluate date else it has no business being a bot.
 * —Trappist the monk (talk) 12:44, 21 October 2017 (UTC)
 * ;-) Yes, of course. I didn't see much opposition against this format (after all, it's optional), but since you mentioned a lack of support, it was my assumption that the only possible reason not to support such an extension would be that it would somehow interfere with existing functionality here or elsewhere. Hence the idea of putting it into a separate parameter (for now), so we can be sure that it will be interpreted only by bots, spyders (and humans) who know how to interpret it, thereby eliminating the risk that these strings would end up in databases uninterpreted or even interpreted incorrectly. Well, that happens with other unknown date formats as well, so this is not a strong argument. Personally, I'm not against supporting EDTF in the date parameter. --Matthiaspaul (talk) 14:26, 21 October 2017 (UTC)
 * I don't like having unused code lying about in the module suite. If we need it sometime in future, we can troll through the old versions and get it back.  Because Citoid doesn't now, and as far as I can see from recent posts at, may never support edtf, I don't see a need at present to support it.
 * —Trappist the monk (talk) 15:18, 21 October 2017 (UTC)

edtf is now part of ISO DIS 8601 2016. Because of that, and because we may someday return to this topic, I have changed the season numbering that Module:Citation/CS1/Date validation/sandbox uses to internally represent seasons. This change does not mean that suddenly 2017-23 is an acceptable numeric date that means Autumn 2017. We could do that but this change does not consider that.

This change does remove the season-order checking because there are cases like this double issue where Spring–Winter 1971 is appropriate.

—Trappist the monk (talk) 12:44, 21 October 2017 (UTC)

Full vs truncated number for end of page-range
For cite journal and friends, should we use 2041–2043 or 2041–43? Last year, MOS:DATERANGE determined that full years should (almost) always be used for the end of year-ranges, but MOS:NUM is silent about the more general idea of ranges and I can't find any statement in the docs for the various citation templates about it. DMacks (talk) 21:30, 27 September 2017 (UTC)
 * Probably mute on the subject because there is little need to micromanage. If one were in need of saving ink or were attempting to squeeze the citation into the last available space on a crowded page, then truncation would be an option to accomplish those goals.  But, we don't use ink, and space is not a problem.  And, for some, reading anything that's truncated causes a stutter in the flow.
 * —Trappist the monk (talk) 21:51, 27 September 2017 (UTC)
 * I think there is no one citation style for page ranges, and it probably depends on the conventions of the field. The Chicago manual of style has one such set of rules about page range style. As Trappist says, publishers cared about good compression for printing, but we don't have the problem here. Use what you think is best. --Mark viking (talk) 22:03, 27 September 2017 (UTC)
 * I agree with the above, consistency within the same article is probably more important. — Paleo  Neonate  – 23:16, 27 September 2017 (UTC)
 * The same logic applies to page number ranges, obviously. The problem with things like "2943–76" is they are not immediately parseable for what they're intended to be, and worse yet, they can often coincide with numeric dates, e.g. "1902–11" (remember that many fonts do not clearly distinguish - and –).  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  08:23, 3 October 2017 (UTC)
 * Yep. Also, they are neither used nor understood everywhere. Since our MOS advises against using abbreviations unless they can be expected to be understood by anyone, and also because "Wikipedia is not paper", I replace such abbreviated page ranges by their expanded form when I run into them - and so far noone ever complained. --Matthiaspaul (talk) 17:55, 22 October 2017 (UTC)

Volume, issue, article, and page numbers
Some academic journals, especially on-line ones, maintain a volume/issue numbering, but no longer assign sequential page numbers within issues. Rather, each article has a number, and its page numbers start at 1.

For example, consider It's volume 95, issue 8, article number 082002, pages 1 through 17. This journal actually numbers the pages 082002-1 through 082002-17, but there are others which do not. Normally, I abuse the "page number" parameter for the article number, but it becomes awkward if I'd like to cite a particular page of an article. Is there a suggested way to deal with this? (One is to take the page number out of the citation template and use .) 104.153.72.218 (talk) 09:38, 22 October 2017 (UTC)
 * Do it the usual way. If you want to cite page 15 specifically, do

Headbomb {t · c · p · b} 12:06, 23 October 2017 (UTC)
 * See p. 082002-15 in
 * Or

Bug when using script-title ISO 639-1 prefix and url-access together?
Hey I think I found a bug that I figured I should point out. Right now the code:

produces:

Specifically the link reads:

["Zhōngguó tángláng mù xīn jìlù shǔ jí yī xīn zhǒng jìshù" 中国螳螂目新记录属及一新种记述]

You'll see the  hanging out in the middle there.

If you remove the url-access or the script-title ISO 639-1 prefix it works, but they don't seem to like each other.

I imagine this is an easy fix so I'd bring it to people's attention. Thanks :)

Umimmak (talk) 11:53, 28 August 2017 (UTC)


 * Don't have time to look at the code right now, but looks like the culprit could be a missing closing html tag. 72.43.99.138 (talk) 12:39, 28 August 2017 (UTC)

I think it's not an easy fix in the sense that a simple tweak will fix it. The problem lies in the creation of the external link. The code is at Module:Citation/CS1/sandbox (which fixes other problems with the live module's handling of kerning). Editors whined and complained when the access signal wrapped to another line so we tried adding a non-breaking thin space between the end of the link and the access icon. The results of that experiment were disappointing; it did not work. So we opted for adding around the last word and the icon. The last word is separated from the other words in the label by a space character. If you look at the whole rendering (simplified from the original) you can see that the code found the last space character in the  tag and inserted the  tag there:

Closing that space doesn't fix the problem because the code will simply find the required space between 'bdi' and 'class'.

The solution to this particular problem is not easy for another reason: interleaving html tags is not permitted. What the code is trying to do is this:

MediaWiki will rewrite that and put the closing some probably-inappropriate place (especially if script-title holds a right-to-left script – Arabic, Hebrew, etc).

Were the language something other than Chinese where there were spaces between words we might do this:

Yeah, not so simple and not merely a matter of an omitted tag.

—Trappist the monk (talk) 16:21, 28 August 2017 (UTC)
 * Why are we not inserting our own closing tags into the proper places, instead of letting Tidy (or whatever) have a guess at it? -- Red rose64 &#x1f339; (talk) 16:32, 28 August 2017 (UTC)
 * We do insert our own closing tags. Nothing that I have written here suggests that we aren't writing complete markup.  But, I have said that the markup that we are writing is malformed.  It is malformed because of the way the code is written.  At the particular place where we assemble the title, the script title, the url and the access signal, the code does not know about  tags.  Because of that for most scripts, English will do here for an example, it places the  between  and :
 * The output for that looks like this (coloring added and metadata removed for clarity):
 * You can see in the above that the tags are interleaved as I described and that closing tags are present.
 * From this page's source for the example template we get this (coloring added for clarity):
 * In the above, mediawiki has closed the tag prematurely and the  tags enclose not only the script title but also the lock image markup.  This latter might have detrimental effects.  Or not; but the markup is still wrong in part because we gave it malformed markup in the first place even though that markup had all of its closing tags.
 * —Trappist the monk (talk) 17:33, 28 August 2017 (UTC)
 * You can see in the above that the tags are interleaved as I described and that closing tags are present.
 * From this page's source for the example template we get this (coloring added for clarity):
 * In the above, mediawiki has closed the tag prematurely and the  tags enclose not only the script title but also the lock image markup.  This latter might have detrimental effects.  Or not; but the markup is still wrong in part because we gave it malformed markup in the first place even though that markup had all of its closing tags.
 * —Trappist the monk (talk) 17:33, 28 August 2017 (UTC)
 * In the above, mediawiki has closed the tag prematurely and the  tags enclose not only the script title but also the lock image markup.  This latter might have detrimental effects.  Or not; but the markup is still wrong in part because we gave it malformed markup in the first place even though that markup had all of its closing tags.
 * —Trappist the monk (talk) 17:33, 28 August 2017 (UTC)


 * Since this seems to require careful code re-write, shouldn't editors be discouraged from using the ISO codes in script-title until a solution emerges? There is language as an interim fix. (Unless that too presents a problem). 72.43.99.130 (talk) 18:51, 28 August 2017 (UTC)
 * I don't think so. I suspect that this particular problem is relatively rare.  language is not a 'fix' because all that it does is categorize the source as a non-English language source and render the language in the final citation.
 * —Trappist the monk (talk) 09:57, 29 August 2017 (UTC)
 * That's not it at all. language and all other parameters are there to give information to readers about the cited source. In this case, to identify a strange-looking script and provide an important detail about the original source. It is a "fix" only in that sense. The ISO option in script-title is a technicality concerning browser rendering. If it breaks the display of the citation for humans. as it does in this case, it has no business there. The focus of CS1 seems hopelessly off. 72.43.99.138 (talk) 14:16, 29 August 2017 (UTC)

Because I do not have a solution to this problem and because I would like to update the live modules, I have removed support for nowrapping url access signal icons. The template at the top of this discussion will now render correctly:

—Trappist the monk (talk) 12:13, 24 October 2017 (UTC)
 * This change also removes code that was added to support this issue. With nowrap gone, the additional code became superfluous.
 * —Trappist the monk (talk) 13:01, 24 October 2017 (UTC)

Dragon magazine mess
Dragon has a somewhat nonstandard scheme, whereas it has an issue number, a volume number, a number number, and then pages.

E.g.
 * Dobson, Michael (March 1986). "The Forum" Dragon. #107 Vol. 10 no. 10. p. 6.

Now in the wild, this is often cited as which has the annoying tendency to put the issue number in the journal field. How do we fix this?

Three options exist, IMO
 * Add a hack, so that for magazine/work/journal = The Dragon / Dragon / Dragon Magazine, that we allow both issue and number
 * Add yes, letting the template know that those are distinct fields.
 * Shove both issue/number in issue or number, i.e. 3, #111 to create

What should be done? Headbomb {t · c · p · b} 20:31, 10 September 2017 (UTC)


 * I'm not a template programmer and don't have a strong opinion on the API. But for Dragon and Dragon+ magazines, looking at bibliographic resources such as DragonDex suggests that the issue number and page are what readers really use when locating articles; volume and number aren't even mentioned. So putting the issue number first, as in your 'in the wild" examples, seems the way to go. As a reader, I'm not bothered by the issue number being in the journal field, but understand for database purposes, it is better to have the issue number as a separate field. --Mark viking (talk) 21:01, 10 September 2017 (UTC)
 * I agree not one [really] cares about vol/num for Dragon magazine. I suppose we could just purge volume/number from those citation, and do something like
 * But the output is a bit misleading on some of them (if using cite magazine). Headbomb {t · c · p · b} 21:21, 10 September 2017 (UTC)
 * But the output is a bit misleading on some of them (if using cite magazine). Headbomb {t · c · p · b} 21:21, 10 September 2017 (UTC)
 * But the output is a bit misleading on some of them (if using cite magazine). Headbomb {t · c · p · b} 21:21, 10 September 2017 (UTC)
 * But the output is a bit misleading on some of them (if using cite magazine). Headbomb {t · c · p · b} 21:21, 10 September 2017 (UTC)

— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:14, 10 September 2017 (UTC)
 * I support the idea of permitting both issue and number as separate parameters when both appear (and with prescribed uses for each). This isn't difficult, and I've encountered many circumstances where this would be useful, even going back to periodicals from the late Victorian era. This would also solve the common problem of issues having designations like "Winter" and "Beatles Commemorative Edition" and whatnot.  These could go in issue, with number used for the number within the volume, when both number and issue are used, but issue otherwise being treated as an alias of number. Failing that, I guess one can overload the current number/issue parameter: XI3 (Summer).  Or, to use the first Dragon example: 1010 (#107); it just seems a little messy and potentially confusing, even at the source level.
 * I also support that idea, and, like you, have run into many examples in the past, where both an issue and a number were given (and variously used in citations, so it isn't a particularly smart idea for us to ignore one of the parameters). However, in the examples I saw, number was used for a running number (typically counting up from the start of the journal), and issue was a number relative to the current volume. I'm open how to render this in the output, but suggest to use # for the number.
 * --Matthiaspaul (talk) 21:02, 24 October 2017 (UTC)

Parameter for Wikidata ID, redux
User:Headbomb and I suggested a parameter for a work's Wikidata ID; there was support, but discussion has been archived. What's happening about this, please? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:50, 28 August 2017 (UTC)
 * I still support this. But how should the link be presented? Wikidata: Q21706380? WD: Q21706380? WDQID: 21706380? Q-ID: 21706380? Something else? Headbomb {t · c · p · b} 17:57, 28 August 2017 (UTC)
 * One of the first two (if the second, with abbr or similar), or with a tiny icon. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 18:49, 28 August 2017 (UTC)
 * So I take it we need to declare this via Q21706380. Headbomb {t · c · p · b} 22:09, 28 August 2017 (UTC)
 * Yes. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:26, 29 August 2017 (UTC)
 * For my part, I don't see overwhelming support for this. Some support, yes, but also some opposition.  When asked how this new parameter would be useful, Editor Pigsonthewing replied, in part: Furthermore, that identifier can in turn be used to fetch identifiers and other metadata for the publication, the author, publisher et al. which seems contrary to the opinion expressed by Editor Headbomb and seconded by Editor J. Johnson: We should most definitely not draw citation data from wikidata.
 * —Trappist the monk (talk) 11:08, 29 August 2017 (UTC)
 * I didn't say it would be used to fetch the metadata by the template; but any reader can do so once they know the Wikidata ID; either manually, or by using a tool of their own preference (e.g. this page on Scholia). I don't think either Headbomb (who proposed and supports the addition of the parameter) or J. Johnson objected to that. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:24, 29 August 2017 (UTC)
 * (EC) Nothing is proposed about drawing information from Wikidata, this would be treated no differently than doi or mr. Could it be used to fetch stuff from Wikidata? It could, in theory. We might even decide this is desirable in the future. But for now it's simply about given a link to Wikidata, and there was no objection on that. Headbomb {t · c · p · b} 17:26, 29 August 2017 (UTC)
 * We did have some objections on the simple addition of a new identifier, and I subscribe to 's comments on that. I do not think all unique identifiers are worth displaying to our readers in citations : we should only include well-established bibliographical identifiers that readers will find useful. I suspect many readers would be annoyed to see yet another unique id they do not care about popping up in citations. Just to be clear, I personally love Qids, but I am just not sure this is the right place for them. As a random reader, what does it bring to me? I can click on that identifier, and see a page with the metadata of that citation on a Wikidata. Fine, but I already had the metadata in the citation. Not everybody is a Linked Open Data enthusiast who will experience a warm and fuzzy feeling only at the sight of a Qid… − Pintoch (talk) 19:12, 29 August 2017 (UTC)
 * The relevant question is "is this useful in relation to the purpose of a citation?" Citations are cluttered already with IDs and potential IDs (review Help:Citation Style 1). I haven't yet seen a strong case in relation to the purpose of a citation, as opposed to information that might be useful to someone. Peter coxhead (talk) 20:59, 29 August 2017 (UTC)
 * A Wikidata ID might constitute an opportunity to move all of those IDs elsewhere and either a) leave users to investigate themselves or b) pull the identifiers from Wikidata automatically with each invocation (even if you don't want to pull an entire citation from Wikidata). --Izno (talk) 22:08, 29 August 2017 (UTC)
 * Using a Wikidata ID to replace many of the others might be useful, I agree, although there would need to be discussion on which ones. Peter coxhead (talk) 22:18, 29 August 2017 (UTC)
 * You ask "As a random reader, what does it bring to me?"; just above your question, I wrote "any reader can do so [fetch identifiers and other metadata for the publication, the author, publisher et al] once they know the Wikidata ID; either manually, or by using a tool of their own preference (e.g. this page on Scholia)". Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 23:03, 29 August 2017 (UTC)
 * fetch identifiers: CS1/2 already supports loads, the author, publisher et al: that's also easy to include in the citation template, either manually, or by using a tool of their own preference: CS1/2 templates are already inter-operable with many tools thanks to COinS… Again I am playing the devil's advocate here, but I think people are just very likely to reject this change. We should be very careful not to foster the skepticism that already exists around Wikidata among some Wikipedia editors. Changes bringing more Wikidata integration to Wikipedia should bring real value to the community (e.g. better integration in infoboxes) instead of splashing our Wikidata ids all over the place for no apparent benefit. − Pintoch (talk) 06:13, 30 August 2017 (UTC)
 * CS1/2 already supports loads, the author, publisher et al... What?  cs1|2 does not support 'loading' any data from anywhere any other than the template's wikisource.  What is it that you really mean?
 * The opportunity, it seems to me, for integration of cs1|2 and wikidata is best begun by making a sterling exemplar of correct use of that resource.  Alas, I fear that the opportunity is slipping away.   could be written to enforce best practices to ensure that the underlying data at wikidata are properly curated.  Unfortunately, data deficiencies are being 'fixed' by tweaks to the template code rather than the correct fix to the data source.  If  becomes recognized as a quality tool, then perhaps there is a future for wikidata in cs1|2.  But, if slipshod craftsmanship of  is allowed to continue, I don't hold out much hope for wikidata in cs1|2.
 * —Trappist the monk (talk) 11:31, 30 August 2017 (UTC)
 * By already supports loads, I meant "CS1/2 already supports loads of identifiers" (it has support for a lot of identifiers). Sorry about that! − Pintoch (talk) 12:35, 30 August 2017 (UTC)
 * True, you didn't say it would be used to fetch the metadata by the template but you did not say that the identifier would be a link only; you did not say that the identifier would not be used by the templates to fetch metadata from wikidata. Because this discussion is about modifying cs1|2 to support a wikidata identifier, don't you know that editors might understand your statement to mean: "once implemented, the templates will be able to fetch metadata from wikidata"?  Without a statement to the contrary, why shouldn't they draw that conclusion?
 * —Trappist the monk (talk) 11:08, 30 August 2017 (UTC)
 * What could the purpose of such a parameter be but to set up future fetches from wikidata? The link itself is not something that would be of much use to readers. —David Eppstein (talk) 12:54, 30 August 2017 (UTC)
 * Wikidata contains a lot more metadata than what we include in our citations. ORCIDs for authors for instance. We also typically leave out ISSNs, publishers, etc... when citing journal articles. There are lots of benefits beyond data fetching. Headbomb {t · c · p · b} 13:29, 30 August 2017 (UTC)
 * Sure − so Qids could be useful in COinS, for instance (or even just in wikicode, maybe). But is it really worth displaying that to human readers? − Pintoch (talk) 13:43, 30 August 2017 (UTC)
 * Yes. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 14:17, 30 August 2017 (UTC)
 * Now there's a novel idea: emit all of the identifiers as metadata in COinS, but potentially leave (some of) them out of the displayed version of the citation.  Imzadi 1979  →  15:16, 30 August 2017 (UTC)
 * No, hiding data isn't a novel idea, it's often been suggested, and rejected as harmful, because errors are hidden. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:29, 31 August 2017 (UTC)
 * For the third time: "any reader can do so [fetch identifiers and other metadata for the publication, the author, publisher et al] once they know the Wikidata ID; either manually, or by using a tool of their own preference (e.g. this page on Scholia)"  Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 14:17, 30 August 2017 (UTC)
 * Andy, I think we got your point, repeating it verbatim will not make it more convincing. Do you want me to repeat why I think the use cases you are talking about are not useful to the average reader? I can rephrase if that was unclear. But let's avoid being too assertive and have a constructive discussion together! − Pintoch (talk) 16:48, 30 August 2017 (UTC)
 * Well, if people could stop acting as though no such argument had been presented... Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:08, 30 August 2017 (UTC)
 * Well, if people could stop acting as though no such argument had been presented... Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:08, 30 August 2017 (UTC)

Another reason to include Wikidata IDs is that bots can compare what's in the templates to what's on Wikidata, and alert humans to discrepancies. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:29, 31 August 2017 (UTC)
 * Hmm, again I'm not sure that is very useful: many citations already have some id, so we can compare the metadata in the template and the data associated to that id. In the vast majority of cases, the data that is on Wikidata was created from one of these sources by a tool (such as fatameh), so it's not like we are getting access to a new data source. Granted, in some cases, a human editor might have added some information (such as disambiguating an author), but that seems to be very rare for now. There would also be the possibility to transfer authorlinks from Wikipedia citations to Wikidata items (to disambiguate authors there), but again that is something we can already do based on the existing identifiers. In any case, as you point out, these use cases would be for bots, so I do not see the point of displaying the id to human readers.
 * Another idea: if Scholia is the tool you want to access from Wikipedia, what about putting directly a link to that tool? Instead of adding something like "WD: Q38197781", it would add " Scholia : Q38197781"?
 * Anyway, I think there is a simple way to trial your idea and show that the community is not going to reject it. Just create an id template, say Scholia, along the lines of doi or arXiv, and add it to citations in the id field:
 * Scholia : Q38197781
 * If there is wide adoption for this, it will be easy to create the id in CS1/2 and migrate the ids to native parameters. This is what has happened to CiteSeerX, for instance. CiteSeerX was already used a lot in id before it became natively supported, and I migrated the citeseerx to citeseerx with a simple regular expression. − Pintoch (talk) 08:11, 1 September 2017 (UTC)
 * OK, I've knocked something up as Scholia. It lacks error trapping, which will be needed before widespread use, and I'd probably replace the text "Wikidata" with a tiny icon (and maybe do the same for "Scholia", once an icon is avilable). Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:12, 11 September 2017 (UTC)
 * OK, I've knocked something up as Scholia. It lacks error trapping, which will be needed before widespread use, and I'd probably replace the text "Wikidata" with a tiny icon (and maybe do the same for "Scholia", once an icon is avilable). Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:12, 11 September 2017 (UTC)

Please don't display any IDs from unreliable sites (whether Wikidata, Scholia, Quora, Findagrave, or whatever else you can come up with). Cite should be used to link to reliable sources and repositories, not user-generated or otherwise unreliable ones. Fram (talk) 11:51, 11 September 2017 (UTC)
 * Not in favor per Fram. Ealdgyth - Talk 14:08, 11 September 2017 (UTC)
 * All citations are user-generated and no more reliable or unreliable than the person who types them in, whether that be on Wikipedia or elsewhere. Making use of a central repository for sources (such as Wikidata) helps keep citations consistent and reduces typos and transcription errors. We should be very much in favour of efforts to stop typing in a hundred versions of the same cite when one is sufficient. --RexxS (talk) 17:20, 13 September 2017 (UTC)


 * I also support the idea of a parameter like wikidata to specify Wikidata nodes. Since these IDs don't have any established meaning outside WP's context, we would not even have to display the numbers in the citations, a small "Wikidata" icon to click on would be enough. Optionally, the ID could be displayed when hovering over the link. And using CSS it should be possible to hide the links depending on user preferences. --Matthiaspaul (talk) 21:15, 24 October 2017 (UTC)

Development setup
I am trying to understand the templates in detail, in particular, in regard to date handling.

I have set up the following pages:


 * User:Jc3s5h/Citation testcases
 * User:Jc3s5h/cite-sand/Cite AV media

In the former, I have used Cite compare2 and an invocation to the template in my user space.

I would like advice on whether I'm headed in the right direction in setting up an environment where I can test, and potentially improve, the templates. Jc3s5h (talk) 12:25, 26 October 2017 (UTC)
 * If, by the right direction, you mean to improve the current cs1|2 templates, perhaps not.  uses wikitext markup to invoke a bot to fill in citation details;  uses wikitext markup for making the determination to render cs2 version of  which both use  but are not part of the cs1|2 suite of templates.  With those exceptions, all cs1|2 templates use the module suite.  A list of all of the modules used by cs1|2 is at the top of Module:Citation/CS1.  If you wish a more complete understanding of the cs1|2 templates, start there.


 * Certainly your User:Jc3s5h/Citation testcases can be tweaked to allow you to test the differences that exist between the live and sandbox versions of the templates (they are very unlikely to change) and between the live and sandbox versions of the modules (which change quite often).
 * —Trappist the monk (talk) 13:31, 26 October 2017 (UTC)

Identifier order messed up.
Why is bibcode displaying before arxiv in?



Identifiers should be listed in alphabetical order. Headbomb {t · c · p · b} 13:49, 10 June 2017 (UTC)
 * The identifier labels are sorted with a case sensitive sort. 'B' has an ascii numerical value of 66 (0x42) and 'a' has an ascii numerical value of 97 (0x61).  Proof for that is here, where I've added 1365-2966 and 0035-8711 from the journal's wikipedia article:
 * —Trappist the monk (talk) 14:42, 10 June 2017 (UTC)
 * Well, that ought to be fixed then, either with case-insensitive sorting, or by putting the sortkey in a identifiername type of thing. Because it wasn't like that before. Headbomb {t · c · p · b} 15:18, 10 June 2017 (UTC)
 * There have been no changes to the identifier sorting since at least (April 2013) of Module:Citation/CS1.
 * —Trappist the monk (talk) 15:59, 10 June 2017 (UTC)
 * I distinctly remember those to be sorted correctly as late as this spring. But even if my memory somehow fails me, those should be sorted alphabetically, regardless of casing. Headbomb {t · c · p · b} 17:02, 10 June 2017 (UTC)
 * De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)
 * De-archived again. . Headbomb {t · c · p · b} 13:58, 13 August 2017 (UTC)
 * De-archived again. . Headbomb {t · c · p · b} 13:58, 13 August 2017 (UTC)

Anyone? Headbomb {t · c · p · b} 02:02, 3 October 2017 (UTC)
 * I see you made good progress on the identifier check below. Any word on identifier sorting? Headbomb {t · c · p · b} 19:48, 27 October 2017 (UTC)
 * —Trappist the monk (talk) 19:59, 27 October 2017 (UTC)
 * Awesome! Can't wait for the next rollout! Headbomb {t · c · p · b} 20:02, 27 October 2017 (UTC)
 * Awesome! Can't wait for the next rollout! Headbomb {t · c · p · b} 20:02, 27 October 2017 (UTC)

Any update on doi-broken-date?
If anything, the doi should at the very least still link. Other improvements can wait/get more discussion, but the linking part should be easy to fix. Headbomb {t · c · p · b} 14:25, 11 April 2017 (UTC)


 * Any way we can get this bundled in the weekend's update? Headbomb {t · c · p · b} 05:29, 26 April 2017 (UTC)
 * The purpose of this interstitial period is to have a last chance to find and fix bugs; to create or modify supporting documentation, categories, templates, etc. – housekeeping preparatory to the update. It is not the time for new development or new features.
 * —Trappist the monk (talk) 11:28, 26 April 2017 (UTC)
 * Yeah well this has been requested a long while ago, is an easy fix, and we have over half a week left. WP:BURO applies here. Headbomb {t · c · p · b} 11:57, 26 April 2017 (UTC)

Can we now implement this? Headbomb {t · c · p · b} 00:27, 2 May 2017 (UTC)


 * De-archived because discussion is ongoing/unresolved. . Headbomb {t · c · p · b} 17:20, 23 May 2017 (UTC)


 * pinging. Headbomb {t · c · p · b} 19:13, 12 June 2017 (UTC)
 * It makes sense to me to have allegedly broken DOIs linked, since the doi-broken-date is checked by a bot and (a) could have been wrongly applied or (b) could have been a temporary problem or (c) both. There are plenty of links that don't work and are not flagged as such. That's just the state of the web, and always has been. – Jonesey95 (talk) 02:00, 13 June 2017 (UTC)


 * De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)
 * De-archived again. . Headbomb {t · c · p · b} 13:58, 13 August 2017 (UTC)

Anyone? Headbomb {t · c · p · b} 02:02, 3 October 2017 (UTC)
 * any updates on this? I know you did some work related to deprecation, but the doi link should still appear when doi-broken-date is set. Headbomb {t · c · p · b} 13:17, 28 October 2017 (UTC)

zwj in indic script
See Module_talk:Citation/CS1/Feature requests.

Module:Citation/CS1 detects invisible characters and when it does, it emits an error message. Among the detected characters is zero width joiner, ZWJ (U+200D). This character should not appear in normal Latin scripts but is extensively used in Indic scripts. I have added code that mutes the error message if the parameter value containing a ZWJ character has at least one character from any of these Unicode character sets:
 * Devanagari – 0900–097F – https://unicode.org/charts/PDF/U0900.pdf
 * Devanagari extended – A8E0–A8FF – https://unicode.org/charts/PDF/UA8E0.pdf
 * Bengali – 0980–09FF – https://unicode.org/charts/PDF/U0980.pdf
 * Gurmukhi – 0A00–0A7F – https://unicode.org/charts/PDF/U0A00.pdf
 * Gujarati – 0A80–0AFF – https://unicode.org/charts/PDF/U0A80.pdf
 * Oriya – 0B00–0B7F – https://unicode.org/charts/PDF/U0B00.pdf
 * Tamil – 0B80–0BFF – https://unicode.org/charts/PDF/U0B80.pdf
 * Telugu – 0C00–0C7F – https://unicode.org/charts/PDF/U0C00.pdf
 * Kannada – 0C80–0CFF – https://unicode.org/charts/PDF/U0C80.pdf
 * Malayalam – 0D00–0D7F – https://unicode.org/charts/PDF/U0D00.pdf

Conveniently, with the exception of Devanagari extended, all of the above are sequential so it is easy to write a Lua pattern for  that will find characters in the set 0900–0D7F.

Here, Latin script with ZWJ should show an error.

—Trappist the monk (talk) 18:21, 25 October 2017 (UTC)
 * Module:Citation/CS1/COinS/sandbox tweaked to keep zwj characters in metadata when associated with Indic scripts.
 * —Trappist the monk (talk) 19:34, 29 October 2017 (UTC)

Update to the live cs1|2 modules weekend of 4–5 November 2017
I expect to update the live cs1|2 modules some time 4–5 November with these changes:

changes to Module:Citation/CS1
 * 1) support kerning of quotes in wikilinks; discussion
 * 2) fix multiple language categorization bug; discussion
 * 3) single letter/digit 2nd level domain names for .cash TLD; discussion
 * 4) support for chapter-url-access; discussion
 * 5) remove trailing separator character from title; discussion
 * 6) internationalization of month, season, and named dates; discussion
 * 7) fix broken |trans-title= missing |title= message display; discussion
 * 8) remove url access signal nowrap; discussion
 * 9) allow wikilinks in vauthors and veditors; discussion
 * 10) mute zwj error message when used with Indic script; discussion

changes to Module:Citation/CS1/Configuration
 * 1) add Tajik to script-title language list;
 * 2) support for chapter-url-access;
 * 3) add Gujarati to script-title language list;
 * 4) add missing error handlers for and ; discussion
 * 5) internationalization of month, season, and named dates;

changes to Module:Citation/CS1/Whitelist
 * 1) support for chapter-url-access;
 * 2) deprecate |doi_brokendate=, |doi_inactivedate=, |trans_chapter=, |trans_title=, |template doc demo=; discussion

changes to Module:Citation/CS1/Date validation
 * 1) internationalization of month, season, and named dates;

changes to Module:Citation/CS1/Identifiers
 * 1) accept OL prefix in ol; discussion
 * 2) jfm error checking; discussion
 * 3) mr error checking; discussion
 * 4) zbl error checking; discussion
 * 5) case insensitive sort; discussion
 * 6) link inactive dois; discussion

changes to Module:Citation/CS1/Utilities
 * 1)  in support kerning of quotes in wikilinks;

changes to Module:Citation/CS1/COinS —Trappist the monk (talk) 12:20, 29 October 2017 (UTC)
 * 1) fix long-time corrupted-metadata bug; discussion
 * 2) preserve author order in COinS output; discussion


 * On removing the nowrap for the accesslocks, why don't we just &amp;nbsp; it instead rather than use a non-breaking thin space? We could do this for all identifiers. Headbomb {t · c · p · b} 12:51, 29 October 2017 (UTC)

– mediawiki fails to correctly identify edit conflicts
 * Because it doesn't work. Probably because the css in which applies to all cs1|2 template renderings, includes   and because the locks are images and not words.  This is all in the archives of this page.
 * —Trappist the monk (talk) 14:46, 29 October 2017 (UTC)

I'd just like to say here that I'm really happy to see the "allow wikilinks in vauthors" change. This one has been occasionally but regularly biting me. Thanks! —David Eppstein (talk) 00:56, 2 November 2017 (UTC)

Suggestions for related fixes

 * I wonder if, due to the fix for vauthors/veditors, whether the problem with page/pages/at can be solved. --Izno (talk) 14:36, 29 October 2017 (UTC)
 * Perhaps, but now is not the time to be doing new work on the module. After the update.
 * —Trappist the monk (talk) 15:02, 29 October 2017 (UTC)
 * Similarly for detecting and reporting wikilinks in author parameters. --Izno (talk) 14:37, 29 October 2017 (UTC)
 * Wikilinks in author parameters are permissible (even in this perculiar usage):
 * —Trappist the monk (talk) 15:02, 29 October 2017 (UTC)
 * Permissible in the code, but the documentation has proscribed them since before January 2009. Should we remove the prohibition from the documentation if wikilinks in author/editor/contributor parameters do no harm? The prohibition may have been there due to code that was not sophisticated enough to handle wikilinks. A separate discussion section may be best. – Jonesey95 (talk) 20:22, 29 October 2017 (UTC)
 * —Trappist the monk (talk) 15:02, 29 October 2017 (UTC)
 * Permissible in the code, but the documentation has proscribed them since before January 2009. Should we remove the prohibition from the documentation if wikilinks in author/editor/contributor parameters do no harm? The prohibition may have been there due to code that was not sophisticated enough to handle wikilinks. A separate discussion section may be best. – Jonesey95 (talk) 20:22, 29 October 2017 (UTC)
 * Permissible in the code, but the documentation has proscribed them since before January 2009. Should we remove the prohibition from the documentation if wikilinks in author/editor/contributor parameters do no harm? The prohibition may have been there due to code that was not sophisticated enough to handle wikilinks. A separate discussion section may be best. – Jonesey95 (talk) 20:22, 29 October 2017 (UTC)