Help talk:Citation Style 1/Archive 49

Template:Noitalic causing CS1 error in citation templates
Here is a search showing instances of "work={ {noitalic" (I get about 450 results in article space). The use of noitalic in CS1 templates has caused COinS metadata errors for a while, and after the last template update, it causes a red error message, "". Someone with access to AWB should be able to make quick work of these errors.

There are also about 230 of these errors in publisher, and about 930 uses overall, if my insource search is working properly. – Jonesey95 (talk) 14:05, 23 October 2018 (UTC)
 * It kind of looks like all of them could be removed. --Izno (talk) 14:32, 23 October 2018 (UTC)
 * And I'd use the more permissive check for whitespace and redirects. Some of those may be false positives in CS1 templates but it's more inclusive overall. --Izno (talk) 14:36, 23 October 2018 (UTC)
 * I've done those that were  in authorn, journal, publisher, website, and work.
 * —Trappist the monk (talk) 16:09, 23 October 2018 (UTC)


 * Okay but how are you supposed to force non-italic script then? Like, Chinese characters really shouldn't be italic in something like
 * And while admittedly "hacky", what's the better way have something which isn't a title (and thus shouldn't be italicized) in the title field, as there's no option to have no title. Or must the title be redundantly supplied?
 * []
 * Umimmak (talk) 17:36, 24 October 2018 (UTC)
 * At the moment there isn't a good answer to the first issue. There has been relatively little discussion about what would probably be the best solution, script-journal, script-magazine, script-newspaper, script-website, script-work, and perhaps others.  See these that I found recently in the archives:
 * Help talk:Citation Style 1/Archive 8
 * Help talk:Citation Style_1/Archive 12
 * Help talk:Citation Style 1/Archive 30
 * Help talk:Citation Style 1/Archive 39
 * For the second issue, writing cs1|2 templates like this:
 * is poor practice that should not be continued; the citation when considered in isolation (as it might be when consumed by reference management software) is wholly incomplete lacking in the fundamentals of proper title and author. You can visually hide the author information and note that 'this' citation is a reprint by by writing:
 * While the author's name does not appear visually, it is still available in the citation's metadata:
 * —Trappist the monk (talk) 18:34, 24 October 2018 (UTC)
 * While the author's name does not appear visually, it is still available in the citation's metadata:
 * —Trappist the monk (talk) 18:34, 24 October 2018 (UTC)
 * While the author's name does not appear visually, it is still available in the citation's metadata:
 * —Trappist the monk (talk) 18:34, 24 October 2018 (UTC)
 * —Trappist the monk (talk) 18:34, 24 October 2018 (UTC)

Global templates
I'm looking at T121470 and wondering whether this might reduce some of the maintenance hassles around these popular citation templates. It's hard to set them up, and then most of the small wikis never update their code again. If they do, then a straight copy of the enwiki templates means that they lose anything (e.g., parameter names) that they translated into the local language.

The global template system would require some dev work (maybe a year's worth of work), and then the template would have to be "marked for translation", to steal a phrase from Extension:Translate. So that's extra work for the template editors. On the other hand, once that happened, you could push an update once, and it would update all the wikis at the same time (well, all the wikis that wanted to use the global template system, but that's probably most of them).

What do you think? (Please ping me. I'd really appreciate it.)  Whatamidoing (WMF) (talk) 17:28, 25 October 2018 (UTC)

ndash not working suddenly
Suddenly  is not being recognized within cite template page ranges. For example, go to Phineas Gage and search the text ndash in the rendered page. Unless I'm losing my mind this is new. EEng 10:09, 20 October 2018 (UTC)
 * , see this and this discussions above Galobtter (pingó mió) 10:12, 20 October 2018 (UTC)
 * Sleep-deprivation has dulled my mental faculties just now. Is it being fixed or not? EEng 10:21, 20 October 2018 (UTC)
 * It's fixed in the sandbox but the change has not been synced to the main template as of yet. (changes are made in batches every now and then by ) Galobtter (pingó mió) 10:32, 20 October 2018 (UTC)


 * Which just shows how ridiculous the syncing schedule is. This is something that should have been deployed as soon as it was fixed, and should still be deployed ASAP. Tens of thousands of articles are broken because of 'oh let's wait till the next update in [0-6 months]'. Headbomb {t · c · p · b} 15:49, 20 October 2018 (UTC)
 * Yes. XOR&#39;easter (talk) 18:36, 27 October 2018 (UTC)

Removal of publisher and publisher location
Why is the bot removing the publisher and publisher location for a cite journal template at ?--Sturmvogel 66 (talk) 23:39, 27 October 2018 (UTC)
 * This page is not the home of Citation bot. Instead, see this discussion.
 * —Trappist the monk (talk) 00:00, 28 October 2018 (UTC)


 * And because this is pointless and useless information that violates every style guide on how to do journal citations. If an exception exist (like hacking a cite web into a cite journal for... whatever reason) you can tell the bot to leave that citation alone. Headbomb {t · c · p · b} 01:13, 28 October 2018 (UTC)

Script title without a title has no quotation marks
I don't think this is deliberate (maybe it is?) but a script title without a title has no quotation marks:

->

It probably should. --Izno (talk) 19:45, 21 October 2018 (UTC)
 * I think that was a deliberate choice. cs1|2 does not apply markup to the value assigned to script-title so that it is distinct from the value assigned to title.  Compare  with :
 * At the time this parameter was created, it is not obvious that we considered the script-title-absent-title use-case though I have a vague memory of at least thinking that non-Latin scripts don't need markup because they are distinct from Latin scripts.
 * The development discussion is here and continued here.
 * —Trappist the monk (talk) 22:37, 21 October 2018 (UTC)
 * I agree that the case where both are set was clearly conceived. A lot of the discussion in that conversation seems to focus on the problem of italics (especially the east Asian languages) rather than the problem of quotation marks, which I'm not sure is a problem. (Maybe for consistency it's an issue.) Is Cyrillic text not supposed to use script-title?
 * On an aside, I am not really sure why cite report gets a special case in the relevant section of code (that's around line 2900). I would guess those titles should be marked up either as italics or as quoted, not neither. We have a preference for the transliterated title of a report (quotation marks), which is bizarre. The relevant discussion was in archive 6. I'd support removing the special case in favor of the quotation marks. --Izno (talk) 01:22, 29 October 2018 (UTC)
 * —Trappist the monk (talk) 22:37, 21 October 2018 (UTC)
 * I agree that the case where both are set was clearly conceived. A lot of the discussion in that conversation seems to focus on the problem of italics (especially the east Asian languages) rather than the problem of quotation marks, which I'm not sure is a problem. (Maybe for consistency it's an issue.) Is Cyrillic text not supposed to use script-title?
 * On an aside, I am not really sure why cite report gets a special case in the relevant section of code (that's around line 2900). I would guess those titles should be marked up either as italics or as quoted, not neither. We have a preference for the transliterated title of a report (quotation marks), which is bizarre. The relevant discussion was in archive 6. I'd support removing the special case in favor of the quotation marks. --Izno (talk) 01:22, 29 October 2018 (UTC)

Wrapper template as a solution to IUCN Red List URL changes
Due to a recent change in the URLs for the IUCN Red List website, there's been a proposal to enhance the functionality of the supposedly-deprecated IUCN-family of templates to handle this, and potentially future, changes to IUCN URLs. I have a few questions that I think people here are well equipped to answer: So, while useful, something about this doesn't seem Kosher to me, especially since how this fix is decided will determine whether or not we expand, or we continue to curtail our usage of, IUCN-family templates. At the very least I think it deserves a discussion wider than WikiProject level. ~ Tom.Reding (talk ⋅dgaf) 15:58, 24 October 2018 (UTC)
 * 1) Given the documentation at IUCN, is there any guideline to not use wrapper templates to CS1 templates? The reason the doc reads as it does (i.e. use Cite journal instead of IUCN; re-ping to, who originally placed the text in 2015) might just be due to the way the IUCN handles their site, and by their recommendations, or there might also be an underlying WP movement away from wrappers and towards using CS1 directly. I just want to eliminate the latter as a possibility, if that's indeed not the case.
 * 2) The enhanced functionality of the wrapper template would be to construct the correct URL from composite wrapper-template parameters, namely doi and/or page, which take the necessary text from the DOI and use it to form the URL, as intended by the IUCN. My problem (and perhaps it's only my problem) is that old values of url, which are currently dead in both the wrapper and CS1 templates, will be ignored, and, instead, the wrapper will pass the automatically-generated URL to Cite journal or Cite web. This produces a disconnect between the citation text (the, unfortunately, dead URL) and the displayed text (a functioning URL). The old url can be removed to solve this secondary problem, but I would prefer to simply update the hard-coded URLs, if possible.
 * I support the use of wrapper templates for all the major taxonomic databases and the like, since there's a history of some of them changing URLs without implementing redirection (e.g. the World Checklist of Selected Plant Families did this, so it's not just the IUCN). One point I would make is that it's essential to have mode in the wrapper, at least to select between CS1 and CS2, to maintain a consistent citation style as per the MoS. Peter coxhead (talk) 16:08, 24 October 2018 (UTC)
 * I am not aware of any guideline that discourages the creation and use of wrapper templates. There are lots of them and they are the reason I wrote Module:Template wrapper.  I do not follow your old url / new url description.  Real life example?  For Editor Peter coxhead, the current IUCN template has mode; that same template rewritten to use Module:Template wrapper would get the mode functionality gratis.
 * —Trappist the monk (talk) 16:19, 24 October 2018 (UTC)
 * Old (dead): https://www.iucnredlist.org/details/13922/0
 * Temp (alive for the short-term): http://oldredlist.iucnredlist.org/details/13922/0
 * New (alive for the "long-term"): https://www.iucnredlist.org/species/13922/45199653, where  is taken from the DOI , available at both the 'Temp' and the 'New' links.   ~ Tom.Reding (talk ⋅dgaf)  16:27, 24 October 2018 (UTC)
 * My problem (and perhaps it's only my problem) is that old values of url, which are currently dead in both the wrapper and CS1 templates, will be ignored, and, instead, the wrapper will pass the automatically-generated URL to Cite journal or Cite web. This produces a disconnect between the citation text (the, unfortunately, dead URL) and the displayed text (a functioning URL). The old url can be removed to solve this secondary problem, but I would prefer to simply update the hard-coded URLs, if possible.
 * If you are rewriting the template doesn't that, sort of by definition, remove the old, dead url value and replace it with the new, living url value?  This:
 * gets replaced with something perhaps like this:
 * So where then, is the disconnect?
 * Is the issue that instances of in article space may not have doi so until they get doi you want to modify the old, dead url value into the temp url value unless doi is present (and has a value) in which case you want to use doi to make a new url value?  Even if this is the case, I still don't see the disconnect.
 * —Trappist the monk (talk) 17:01, 24 October 2018 (UTC)
 * Removing the old does make the situation a bit better, and will prefer the use of Cite journal, which I think is more appropriate, over Cite web. If a user would want to use a different URL, then the url parameter would be rendered useless in the wrapper; but perhaps that will be an unlikely scenario, and can be discussed at the template/WikiProject level, if needed.
 * Separately, each of my 2 points aren't a real obstacle, but together they were too many 'ifs' for me to feel comfortable. Also, I spent some time converting from IUCN-type templates to Cite journal per the template's own recommendations, so I prefer there be at least some respect given to that direction; but as long as there's strong agreement in either direction, and no major issues, I'm fine with it.  ~ Tom.Reding (talk ⋅dgaf)  19:19, 24 October 2018 (UTC)
 * If a user would want to use a different URL, then the url parameter would be rendered useless in the wrapper Really?  In the wrapper, wouldn't this use the editor's url over the url constructed by the wrapper?
 * —Trappist the monk (talk) 19:48, 24 October 2018 (UTC)
 * Nothing has been implemented yet, but yes, that behavior was suggested at Wikipedia talk:WikiProject Tree of Life. I didn't mean it to sound like that behavior would be a direct result of any wrapping, just that it was a tentatively described "feature" (one that may not even be implemented, especially if removing the old, dead, url happens in the same edit).  ~ Tom.Reding (talk ⋅dgaf)  21:36, 24 October 2018 (UTC)
 * Why does the doi url not work? http://dx.doi.org/10.2305/IUCN.UK.2016-1.RLTS.T13922A45199653.en
 * I was going to suggest that because you have a doi, url is superfluous – it is in the normal case, but if iucn is not going to support doi any longer then, yeah, I guess you have to rewrite the url.
 * —Trappist the monk (talk) 22:06, 24 October 2018 (UTC)
 * My assumption is that the failure of doi urls is an oversight by the IUCN. The use of doi as permanent links was part of their reasoning that they should be cited as a journal and the reason for preferring cite journal on Wikipedia. So hopefully the IUCN and IDF will communicate and fix the issue. Although if the IUCN want to encourage people to link to the new site they might not want the doi updated to the old site. If they don't fix it this week the latter may be the case.  Jts1882 &#124; talk 16:51, 25 October 2018 (UTC)
 * The IUCN doi links now work again, pointing to the new website.  Jts1882 &#124; talk 14:27, 29 October 2018 (UTC)
 * Nothing has been implemented yet, but yes, that behavior was suggested at Wikipedia talk:WikiProject Tree of Life. I didn't mean it to sound like that behavior would be a direct result of any wrapping, just that it was a tentatively described "feature" (one that may not even be implemented, especially if removing the old, dead, url happens in the same edit).  ~ Tom.Reding (talk ⋅dgaf)  21:36, 24 October 2018 (UTC)
 * Why does the doi url not work? http://dx.doi.org/10.2305/IUCN.UK.2016-1.RLTS.T13922A45199653.en
 * I was going to suggest that because you have a doi, url is superfluous – it is in the normal case, but if iucn is not going to support doi any longer then, yeah, I guess you have to rewrite the url.
 * —Trappist the monk (talk) 22:06, 24 October 2018 (UTC)
 * My assumption is that the failure of doi urls is an oversight by the IUCN. The use of doi as permanent links was part of their reasoning that they should be cited as a journal and the reason for preferring cite journal on Wikipedia. So hopefully the IUCN and IDF will communicate and fix the issue. Although if the IUCN want to encourage people to link to the new site they might not want the doi updated to the old site. If they don't fix it this week the latter may be the case.  Jts1882 &#124; talk 16:51, 25 October 2018 (UTC)
 * The IUCN doi links now work again, pointing to the new website.  Jts1882 &#124; talk 14:27, 29 October 2018 (UTC)
 * —Trappist the monk (talk) 22:06, 24 October 2018 (UTC)
 * My assumption is that the failure of doi urls is an oversight by the IUCN. The use of doi as permanent links was part of their reasoning that they should be cited as a journal and the reason for preferring cite journal on Wikipedia. So hopefully the IUCN and IDF will communicate and fix the issue. Although if the IUCN want to encourage people to link to the new site they might not want the doi updated to the old site. If they don't fix it this week the latter may be the case.  Jts1882 &#124; talk 16:51, 25 October 2018 (UTC)
 * The IUCN doi links now work again, pointing to the new website.  Jts1882 &#124; talk 14:27, 29 October 2018 (UTC)

Cite AV Media doesn't show title-link
Example

Result: -- minhhuy (talk) 04:25, 31 October 2018 (UTC)
 * Fixed in the sand box I think:
 * —Trappist the monk (talk) 09:40, 31 October 2018 (UTC)
 * —Trappist the monk (talk) 09:40, 31 October 2018 (UTC)

Cite Map with translated title
I'm a bit confused on how I should use Template:Cite map with map, map-url and trans-title as I can't get a translated title to work with these.
 * If I add these 3, I get.
 * If I change map to title, I get.
 * If I then also change map-url to map, I get.
 * If I try replacing trans-title with trans-map, I get Missing or empty.

Any suggestion on how to use Cite Map with these fields? --Gonnym (talk) 09:22, 31 October 2018 (UTC)
 * If you are citing a sheet map (a stand-alone map) then you must use title, trans-title, and url. When you are citing a map that is part of a larger work, map, trans-map, and map-url apply; these are akin to chapter, trans-chapter, and chapter-url in a  template.  See the examples at.
 * —Trappist the monk (talk) 09:53, 31 October 2018 (UTC)
 * The example I was following is the last one in the "Maps contained within larger works" examples - which is the only example given for an online map (which is not Google or Bing). Please note that I did what you wrote but still got an error, see my last bullet point. Also, if you'd like to test it - take the example from the list and add "trans-map" --Gonnym (talk) 10:01, 31 October 2018 (UTC)
 * You changed title to work which is not an alias of title. Restoring the example and adding trans-map:


 * —Trappist the monk (talk) 10:33, 31 October 2018 (UTC)
 * I didn't change anything, as I just used the only example shown for a web generated map. I just tried to make sense of the examples as the documentation doesn't even address trans-map, and trans-title doesn't even say that using work is incorrect. Regardless, thanks for clearing this up. --Gonnym (talk) 11:04, 31 October 2018 (UTC)
 * Right, you didn't; mea culpa. The documentation sucks, everyone complains that the documentation sucks yet those who complain never do anything but complain and never help to make it better.  The example's code-view did not match the example's rendered view.  I've fixed that.
 * —Trappist the monk (talk) 11:37, 31 October 2018 (UTC)
 * I tend to fix stuff I understand and stay clear from those I don't. I've used mostly cite web all these years and if you ask me what does anyone of the params I've never used, I'll have no idea. For me the cite template doc always felt like a huge wall of text and I either stay completely clear or just Ctrl+f to find a specific word. --Gonnym (talk) 11:54, 31 October 2018 (UTC)

Add |software parameter to Template:cite map
The cite map template is missing a single parameter to be able to fully cite GIS maps. From this website, it seems like it is recommended to cite the software package used to create the map. -Furicorn (talk) 19:10, 6 November 2018 (UTC)

Last/First, First/Last
Could somebody add an option to cite book to display the author's first name before the last name? Kurzon (talk) 08:15, 9 November 2018 (UTC)
 * Names are hard. Use author. – Jonesey95 (talk) 08:35, 9 November 2018 (UTC)
 * No. It's customary for any citation style, inside or outside Wikipedia, to specify when the first name should be written first, and when the family name should be written first, and for everyone to follow whatever the specification is. There is no reason to create an option to make it easier for editors to deviate from the standard chosen for Citation Style 1. Jonesey95, I believe author is best used for corporate authors, where the terms last name and first name do not apply. Jc3s5h (talk) 11:04, 9 November 2018 (UTC)
 * Unfortunately, we have WP:CITEVAR here at en.WP, which means it's up to local consensus (or the article's "first major contributor") to determine how citations look in a given article. If an editor or WikiProject wants to implement CMOS's "First Last, First2 Last2, and First3 Last3" or "Last, First, First2 Last2, and First3 Last3" (ugh) style in a consistent way using CS1 templates, author makes that possible. You might not like it, but that's CITEVAR for you (p.s. I don't like it either, but I'm not going to die on that hill.) – Jonesey95 (talk) 11:12, 9 November 2018 (UTC)
 * Yes, but this is the Citation Style 1 talk page, so we are talking about an article where this family of templates has been chosen, and therefore the last, first name order has been chosen. Just as if Chicago Manual of Style footnotes without a bibliography had been chosen, in which case the order would be first last. And I believe it's just incorrect to use Citation Style 1 templates to implement a citation style that departs from the documentation at this page and the individual templates that make up the style; by no it's firmly established that CS1 is a style, not just a set of tools. If you want to use your chisel as a screwdriver at your home, go ahead, but don't use CS1 to implement Chicago style. Jc3s5h (talk) 11:21, 9 November 2018 (UTC)
 * I am sympathetic to Jc3s5h's viewpoint, but the consensus is against it. Even the CS1 Template:cite book documentation disagrees: "author: this parameter is used to hold the complete name of a single author (first and last) or to hold the name of a corporate author. This parameter should never hold the names of more than one author." (emphasis added). This text was added more than two years ago, to no objections; it had been a de facto practice for many years before that. – Jonesey95 (talk) 13:39, 9 November 2018 (UTC)
 * I will also use author with Asian names, because I am dumb and how Asian names are in the west versus the east versus wherever the cited author is from is hard. --Izno (talk) 13:24, 9 November 2018 (UTC)
 * This was discussed recently, at some length, in archive 45. --Izno (talk) 13:23, 9 November 2018 (UTC)
 * I still support adding af, failing that, hacks are valid. Or use author1/author2/... Headbomb {t · c · p · b} 15:35, 9 November 2018 (UTC)


 * When did "first and last" get added? Just how much attention did that get? Apparently not enough for any COinS fans to complain about degrading the metadata. This needs looking into.


 * The CMS "footnotes without a bibliography" example Jc3s5h provides is the special case of individual full citations at the foot of a printed page, where they are laid out in European-centric "normal" order. I believe all style guides recommend having lists of citations sorted by the lexicographic key, which is normally the first author's surname ("last name"). (Where styles differ is whether co-authors should have their names inverted. The general and accepted practice here is to invert the co-authors' name same as the first author's name.)


 * Kurzon: why do you want this option? Is it a purely personal preference, or is there some kind of problem that needs addressing?


 * The MOS is where we say that certain consistencies of "style" are strongly preferred (even to the point of being required). That WP:CITEVAR allows some latitude in some areas doesn't give editors carte blanche elsewhere. Largish lists (such as sources) need to be sorted (so they can be readily scanned by the reader), with the sort key (such as last name) at the head of each entry. This is so standard that deviation would be confusing. (Surely no one is proposing to sort by an author's first name. Right?)


 * Mixing first and last names into author is bad enough where we are familiar enough with the names to distinguish them, but even worse for unfamiliar names. We need this last/first metadata, and the editor adding a source should sort out the name parts, and put them into the proper parameters. &diams; J. Johnson (JJ) (talk) 23:37, 9 November 2018 (UTC)

I don't like using author because the harv template can't use that parameter. Kurzon (talk) 08:38, 10 November 2018 (UTC)

ndash entity in pages parameter
Trying

(note: I actually tried it with the ndash entity but I had to expand out the ampersand into an amp entity to get it to be visible as an entity inside the nowiki) I expected to see the same result as if the ndash entity were replaced by an actual en-dash character, namely
 * Author, A.N. (2018). "Title". Journal: 10–24.

but instead it was spelled out:
 * (live template)
 * Author, A.N. (2018). "Title". Journal: 10&ndash, 24. (substituted in case the live template gets fixed)

Would it be possible to fix this, please? I don't use the ndash entity much myself as I have a Mac keyboard on which the dashes are easy to type, but it's a convenient alternative spelling for editors who use other systems, and it works most of the time but not here where we need en-dashes so frequently. (And in fact I found this in someone else's markup while editing an article, rather than by randomly experimenting myself.) I think the problem is that the semicolon that terminates the entity is getting misinterpreted as normal punctuation and replaced by a comma, which makes the rest of the entity stop looking like an entity to browsers that see the resulting markup. —David Eppstein (talk) 05:47, 9 October 2018 (UTC)
 * fixed in the sandbox:
 * The code that converts hyphens to endashes splits the page and issue parameter values at commas and semicolons (because editors do use semicolons where commas should be used).   and   entities are now converted to their respective characters before the split.
 * —Trappist the monk (talk) 10:00, 9 October 2018 (UTC)
 * Thanks for the quick work! —David Eppstein (talk) 16:31, 9 October 2018 (UTC)
 * It appears to be broken at the moment. XOR&#39;easter (talk) 18:33, 27 October 2018 (UTC)
 * Thanks for the quick work! —David Eppstein (talk) 16:31, 9 October 2018 (UTC)
 * It appears to be broken at the moment. XOR&#39;easter (talk) 18:33, 27 October 2018 (UTC)

Definitely it was broken when I looked at a couple of articles today. This needs to get fixed, since there are probably over a million occurrences of – in Wikipedia articles. Michael Hardy (talk) 00:09, 12 November 2018 (UTC)
 * Are you aware that this is not fixed? Michael Hardy (talk) 19:44, 12 November 2018 (UTC)
 * Aye, of course; I fixed the issue in the sandbox as noted above.
 * Except for when the cs1|2 modules emit or evince some other sort of fatal error, it has been the practice here to accumulate multiple tweaks, modifications, fixes, enhancements, etc. and then update the cs1|2 module suite all in one go (2 module weekend of 29–30 September 2018|the last update).
 * —Trappist the monk (talk) 22:46, 12 November 2018 (UTC)
 * —Trappist the monk (talk) 22:46, 12 November 2018 (UTC)

Move development to GitHub?
Is it just me who feels that its rather pathetic that this wonderful project has been limited due to it being completely on-wiki, when most serious software development these days take place on dedicated platforms like GitHub? Are there any reasons why we are keeping this here?

The CS1 modules appear to be almost entirely written and maintained by one single editor since around 2013 (though undeniably he has done a great work at that). But there is no collaboration taking place. All edits are saved with the edit summary "sync from sandbox" and the sandbox edits themselves don't have any edit summaries at all. I note that changes are still being recorded through other means, but its nothing like the commit history available on version control systems like git.

The recent issue with ndashes has been brought up brought up four times. The fix, though promptly done by, is still in the sandbox and hasn't been deployed. Edits are made in the sandbox and deployed in batches to main module once in a while by the Monk. This wiki-based workflow is quite inferior to the sophisticated pull request mechanism we have on git. Using a system like GitHub, everything is a whole lot easier. Commit messages are helpful in allowing multiple coders to collaborate (which isn't taking place here, and I don't it's due to lack of interested programmers). When two people working on forks make changes to different parts of a same file, the git software merges both versions automatically - the sort of stuff that here would be need to fixed by the nasty process of manually copy-pasting the correct code blocks from both versions.

Moving the development work to GitHub (and having a bot to sync changes from the github repo to the wiki) would help new coders who wish to help out on this project. This is the way popular gadgets and tools like Twinkle, wikEd, AFCH script, etc are written and maintained. SD0001 (talk) 18:49, 13 November 2018 (UTC)
 * Well one big difference is that changes to CS1|2 require community consensus. The sandbox changes are announced, then time is given for comment before they are committed. Also the sandbox changes are not even made until there is some initial discussion with no serious objection. The idea is to give lots of time for editors to discover the proposal and comment and not move fast (unless it's an urgent bug). Also since the template has millions of instances the Module can't be updated frequently or it interferes with backend services (someone more knowledgeable can comment on details of this). -- Green  C  19:03, 13 November 2018 (UTC)
 * I have collaborated multiple times. :) As for syncing, the reason that it is not often synced is because many pages are affected and we try to avoid causing the job queue to be sad. I would have no issue with a mini-RFC to release the module to correct the dash issue if you think that is necessary (I think it might be). Maybe what we should really have is a discussion about how often we should release this module set. --Izno (talk) 20:04, 13 November 2018 (UTC)
 * GitHub is not free software, so it would be against Wikipedia's values to force people to use it. Wikimedia offers compliant git hosting facilities, but as noted above this is not a matter of technical tools, rather it's about decisions on release speed etc. Nemo 12:16, 14 November 2018 (UTC)
 * @SD0001: I'm unclear on the basis for you're complaint. Have you ever been denied the opportunity to collaborate here?  Has anyone been denied?  Can you give a concrete example to show how this project has been limited due to it being completely on-wiki?
 * I have some, not a lot, but some experience with github. In my use of it I have always had sufficient permissions so that I did not have to do pull requests to implement my changes to the code.  Were we to migrate cs1|2 to github, someone or a group of designated someones, would need to serve as the gatekeeper(s) for pull requests from contributors who do not have the requisite permissions.  At github, there is no facility to test changes so we would still require some sort of sandboxing here.  At en.wiki, any admin can edit the live modules; the sandboxen are open to any and all editors.
 * —Trappist the monk (talk) 13:17, 14 November 2018 (UTC)
 * —Trappist the monk (talk) 13:17, 14 November 2018 (UTC)

Needs a lot of work
The Cite AV Media template page needs a lot of work. There aren't many instructions. Which fields to use is confusing. I can see readers getting lost trying to use it as a guide for how to cite DVDs. Vmavanti (talk) 19:25, 19 November 2018 (UTC)
 * The quality of the documentation for the cs1|2 templates can always be improved. If you can help make the documentation better, please do.
 * —Trappist the monk (talk) 19:31, 19 November 2018 (UTC)
 * Uh, yes, well I wanted to, but first I would have learn how to use the template. I'm not confident I know how it's done. It's like I said. It's not clear to me what the basic fields are and how they should be used. For example, let's say I want to source a DVD. The field "people" refers to director? People? Last name first with director in parentheses? I don't know. What if there are two directors? Why people? Why not use last1, first1? What's the difference between medium and format? Date: year only or day, month, and year? In what order? Does time refer to length of the DVD? Are there fields for chapters or sections of the DVD? Are there fields for the time of the DVD when a certain moment occurs which is being referenced? After scrolling past the default blank template I come to Examples, which is in the plural although there is only one mediocre example. Scrolling past that I come to Syntax, parent, child. How would these parent and child fields be used in DVD? Next I come to COinS metadata. How many readers understand this? How many editors? This is what I mean. The person who wrote this is assuming too much. When writing instructions, you have to assume almost nothing. That's the whole point of instructions. Capece? Vmavanti (talk) 23:49, 19 November 2018 (UTC)
 * There are 22700+ pages that use so someone must have figured out how to use the template; see Special:WhatLinksHere/Template:Cite_AV_media.
 * people is nothing more than an alias of authors; the 'name (role)' appears to be the way someone (who? don't know) thought that this template should be written. There is no reason that you shouldn't use lastn / firstn and in fact, that should be preferred but if you choose to do that don't include the person's role in either of those.  format applies the the electronic file format of the source linked by url; medium is the source's type: DVD, Video tape, LP, CD, etc.  Chapters / sections can use chapter or section.  minutes, time and time-caption are documented at In-source locations.
 * I have no idea what §Syntax is trying to convey; it may be left over from a bygone older version of this template. The important take-home from §COinS is that editors should not write any of these parameters so that they include other templates; for example, do not write 🇦🇹 because  produces this in the citation's metadata:
 * most of which has nothing to do with the author's surname.
 * I wrote some of this documentation and I freely admit that I suck at it (because I wrote so much of the supporting code, it is nigh-on impossible for me to assume almost nothing while writing about it). This is why every time someone rises to complain about the quality of the documentation here, I ask, as I did of you, that they help to make it better.  Rarely, oh so rarely, have any of those whom I've asked done anything to improve the template documentation.
 * —Trappist the monk (talk) 01:04, 20 November 2018 (UTC)
 * most of which has nothing to do with the author's surname.
 * I wrote some of this documentation and I freely admit that I suck at it (because I wrote so much of the supporting code, it is nigh-on impossible for me to assume almost nothing while writing about it). This is why every time someone rises to complain about the quality of the documentation here, I ask, as I did of you, that they help to make it better.  Rarely, oh so rarely, have any of those whom I've asked done anything to improve the template documentation.
 * —Trappist the monk (talk) 01:04, 20 November 2018 (UTC)
 * —Trappist the monk (talk) 01:04, 20 November 2018 (UTC)

Vmavanti (talk) 01:54, 20 November 2018 (UTC)
 * I have a reputation as a bold editor, so I will try to improve it after I'm certain I have it right, ok? I'm not trying to condemn anyone. I simply want the instructions to be clear for anyone, anyone who happens to consult them, and that in turn benefits all of us. I was comparing Cite AV Media to Cite AV Media Notes and was curious why the latter was easier to understand. Yes, many people use templates, but not all of them use them correctly. I know I'm stating the obvious. I work on a lot of music articles and most of those IP editors use templates of all kinds incorrectly. If the instructions are as clear as possible, and this includes organization and presentation, then they will have no excuse. For me, step one is a good default example. The kind of example used most often with Cite AV Media. My guess is that would be a DVD movie. Having a good models (examples) to work from is very important. People are natural copiers and followers. When you write, put yourself in the shoes of someone who knows nothing about Wikipedia. Assume nothing. Start with a blank slate, question everything, almost nothing is too simple or too obvious. Thank your for your effort in making Wikipedia easier to use. Many people appreciate it but they don't say it.

cite wikisource
Because of discussion here, I made some changes to Module:Template wrapper/sandbox (discussed here). I was looking for something a bit more complex that could be a test-bed for ideas the the IUCN template inspired and settled on because, when wrapped in Module:Template wrapper for cite book, it has some parameters (at, chapter, publisher, title) that are native both to  and to the working template.

I think that I have resolved all of the issues that would allow rewriting to use Module:template wrapper with  except for one:  adds wikisource icons to chapter and title by prefixing the content of chapter or title with   (which it should not be doing because that corrupts the citation's metadata.

There may be a solution. cs1|2 adds access icons to externally linked title, chapter, various identifiers. I created wikisource icon css in Module:Citation/CS1/sandbox/styles.css and tried wrapping the content of Chapter_VII Instinct with an appropriate tag. That worked but didn't work because the icon overlaid the last word of the chapter rendering. I think that this is because the icon image is positioned according to the right-side boundary of the chapter text (the right-most  mark). There may still be a solution there; I imagine that we might add n number of  characters sufficient to allow proper placement of the icon or perhaps, there is some slick css trick that I don't know about that would do the same.

The solution that I did come up with is to convert  to   which uses the space occupied by the normal MediaWiki external link icon (as we do for access icon's):

Compare :

There is a long-standing feature request to add to the cs1|2 module. I don't think that we should do that but adding a little support to the cs1|2 module that allows the icon and also moves away from  is probably a good thing.

—Trappist the monk (talk) 15:01, 5 November 2018 (UTC)
 * I support moving cite wikisource away from using citation/core, since it is antiquated and not maintained. Is there a page of testcases that show how the template looks now versus how it looks in a sandbox version using the wrapper? I'd be happy to look at it and provide feedback. Have you considered placing a note at Template talk:Cite wikisource? I would do so for you, but you usually have a plan in mind, so I will defer to you. – Jonesey95 (talk) 17:25, 5 November 2018 (UTC)
 * No page of test cases yet for this particular change to the cs1|2 module. You can see comparisons of the live and Module:template wrapper/sandbox versions of  at Template:cite wikisource/testcases.  I still have to figure out how to support wikisource interwiki links in title and in title-link within cs1|2 templates before I'll be ready to broach the topic at Template talk:cite wikisource.  I don't know if this change should be constrained to  or if there are other cs1|2 templates that should support this feature.
 * —Trappist the monk (talk) 18:32, 5 November 2018 (UTC)
 * Tweaked the code to add wikisource icon to the rendered title when title is linked through title-link:
 * I have also inserted a single space character between the ends of chapter and title renderings to move the icon so that it doesn't directly abut the text. The wikisource icon is a tad larger than the access icons (12px v 9px).
 * edit:
 * and when title holds an interwiki link:
 * —Trappist the monk (talk) 12:25, 6 November 2018 (UTC) 14:59, 7 November 2018 (UTC)
 * Personally, I'd drop the icon and have the template add Wikisource. AASHTO minutes cites Wikisource (for one of its minutes) or Commons (for the rest, for now), and we even added a v-link to turn on a wikilink to the entry in the underlying via:
 * In any case, we don't add icons when a copy of a source is hosted on Commons, so I don't see why Wikisource is anything special.  Imzadi 1979  →   12:56, 6 November 2018 (UTC)
 * I agree that Wikisource is more correct than concatenating  onto the end of publisher as  does now.
 * Wikilinks and interwiki links are so similar in appearance as to make them indistinguishable to the casual reader; especially in isolation. Compare:
 * wikilink color
 * interwiki link color
 * external link color
 * the icon clearly indicates to the reader that a wikisource link is not a link to a page at en.wiki. Because  uses, it must be given a value in url which causes MediaWiki to apply the external link icon thereby distinguishing it from wikilinks and interwiki links.
 * —Trappist the monk (talk) 14:59, 7 November 2018 (UTC)
 * Further tweaks to Module:Citation/CS1/sandbox to support wikisource interwiki links in page, pages, at done. Notices posted at Template talk:Cite wikisource and Wikipedia talk:WikiProject Wikisource
 * —Trappist the monk (talk) 12:13, 21 November 2018 (UTC)
 * wikilink color
 * interwiki link color
 * external link color
 * the icon clearly indicates to the reader that a wikisource link is not a link to a page at en.wiki. Because  uses, it must be given a value in url which causes MediaWiki to apply the external link icon thereby distinguishing it from wikilinks and interwiki links.
 * —Trappist the monk (talk) 14:59, 7 November 2018 (UTC)
 * Further tweaks to Module:Citation/CS1/sandbox to support wikisource interwiki links in page, pages, at done. Notices posted at Template talk:Cite wikisource and Wikipedia talk:WikiProject Wikisource
 * —Trappist the monk (talk) 12:13, 21 November 2018 (UTC)

Digression on usage
This is not really relevant to purposes in the thread above, where is just a use case for changes to Module:template wrapper, but…

I don't think a template makes sense. Wikisource doesn't publish original works, it just reproduces existings works. These works can be books, journals, magazines, newpapers, or encyclopedias (or, of course, parts like chapters, articles, entries, etc.). What Wikipedia cites is the original work, it just happens that we cite the copy extant on Wikisource. This is analogous to databases like Questia, JSTOR, or Project MUSE, and what we have via for.

In view of that, perhaps a better approach would be a title parameter as a convenience shortcut for  syntax, and possibly also triggering the display of the Wikisource logo (analog here to the external link icon). --Xover (talk) 12:46, 6 November 2018 (UTC)
 * You might be right. If you think that the template should be deleted, or you are wondering if its documentation should restrict its use, I recommend posting at both Template talk:Cite wikisource and Wikipedia talk:WikiProject Wikisource to see if you get any response. Each of those pages has fewer than 30 watchers, however, so you might not get much. – Jonesey95 (talk) 13:17, 6 November 2018 (UTC)
 * I agree, and was thinking about this yesterday. I am very bothered by it. :) --Izno (talk) 19:19, 6 November 2018 (UTC)
 * I'm not sure that I agree. There is no requirement that citation templates of any stripe be used only for original-work publishers.  Were that the case then  (basically a fork of a 2007-ish version of ) should be disallowed because Project Gutenberg just reproduces [existing] works.  That template uses this construct to link to a Project Gutenberg title:
 * The Canterbury Tales and Other Poems
 * That pseudo-interwiki construct must be documented someplace but a quick-search didn't locate the documentation. Anyone know where it is? Are there others like it?
 * I do agree that should be using via.
 * —Trappist the monk (talk) 14:59, 7 November 2018 (UTC)
 * meta:interwiki map. --Izno (talk) 17:38, 7 November 2018 (UTC)
 * Well, I don't generally mind specific-source templates, for convenience and consistency, but there is an argument to be made that since Wikisource is, itself, not a reliable source, we should not have a template that suggests that we cite it as an authority. But I suppose that argument runs afoul of the second corollary to Spaf's first axiom of Usenet ( "Arguing about the significance of newsgroup names and their relation to the way people really think is equivalent to arguing whether it is better to read tea leaves or chicken entrails to divine the future." ).A more practical issue, however, is that Wikisource contains all kinds of sources: if, for example, wraps  the output (including metadata AIUI) will be incorrect for a magazine, and so forth. Hence the thought that if we want various special behaviours for citations to works that are reproduced on Wikisource then those behaviours are better triggered by specific parameters (like the mentioned wikisource-link example above) on the main citation templates than by the invoking template. Or perhaps via should accept magic words (i.e. Wikisource) that trigger such behaviour? --Xover (talk) 08:49, 8 November 2018 (UTC)
 * The documentation for doesn't explicitly say that the template is to be used solely for books though book-only is implied by the examples it shows.  You are correct that, at present, books are all that it supports.  We could easily change  to use  so that rendering and metadata are determined by the content of the periodical parameters newspaper and magazine.  Here is a newspaper cite using :
 * and again, this time using :
 * Here is a book cite using :
 * same again using :
 * In a new version of using  we would preset mode so that the citations render in the same style as legacy .  I have tested these changes in  but not yet implemented them.
 * —Trappist the monk (talk) 13:01, 8 November 2018 (UTC)
 * Further, has class which can be set to one of the various values supported by  (these aren't defined anywhere except in the various cs1|2 templates that directly call Module:Citation/CS1).  This search would seem to indicate that article space has some 400ish instances of  that include some form of class, most of them dictionary; this contrary to the template doc that says:
 * class: The CSS class for the citation; use only when this template is used as a metatemplate; do not use directly when making citations in the article namespace.
 * Not sure why that stricture. Regardless, with the exception of setting the the css class for the rendering's enclosing  tag, class appears be exclusively used in the mind-numbing mess that feeds 's At parameter so doesn't, apparently, drive the correct use of the template's metadata or rendering.
 * —Trappist the monk (talk) 16:28, 8 November 2018 (UTC)
 * same again using :
 * In a new version of using  we would preset mode so that the citations render in the same style as legacy .  I have tested these changes in  but not yet implemented them.
 * —Trappist the monk (talk) 13:01, 8 November 2018 (UTC)
 * Further, has class which can be set to one of the various values supported by  (these aren't defined anywhere except in the various cs1|2 templates that directly call Module:Citation/CS1).  This search would seem to indicate that article space has some 400ish instances of  that include some form of class, most of them dictionary; this contrary to the template doc that says:
 * class: The CSS class for the citation; use only when this template is used as a metatemplate; do not use directly when making citations in the article namespace.
 * Not sure why that stricture. Regardless, with the exception of setting the the css class for the rendering's enclosing  tag, class appears be exclusively used in the mind-numbing mess that feeds 's At parameter so doesn't, apparently, drive the correct use of the template's metadata or rendering.
 * —Trappist the monk (talk) 16:28, 8 November 2018 (UTC)
 * Further, has class which can be set to one of the various values supported by  (these aren't defined anywhere except in the various cs1|2 templates that directly call Module:Citation/CS1).  This search would seem to indicate that article space has some 400ish instances of  that include some form of class, most of them dictionary; this contrary to the template doc that says:
 * class: The CSS class for the citation; use only when this template is used as a metatemplate; do not use directly when making citations in the article namespace.
 * Not sure why that stricture. Regardless, with the exception of setting the the css class for the rendering's enclosing  tag, class appears be exclusively used in the mind-numbing mess that feeds 's At parameter so doesn't, apparently, drive the correct use of the template's metadata or rendering.
 * —Trappist the monk (talk) 16:28, 8 November 2018 (UTC)

Editor in TemplateData
Hello, it seems editor-first and editor-last is in Cite encyclopedia's TemplateData twice. Am I right? Could you fix it please? --Dvorapa (talk) 13:01, 21 November 2018 (UTC)
 * Are you sure? I don't see duplicate editor-first and editor-last entries at Template:Cite encyclopedia.
 * —Trappist the monk (talk) 13:41, 21 November 2018 (UTC)

When to disambiguate and wikilink place/location
cite book's documentation could use some clarification on wikilinks and disambiguation. In the case of: Sure, I wouldn't link New York City, but Oakland, California, is not a major city—when should the place/location be linked? And regardless of whether it's linked, should we use the full disambiguated article title, or would it be sufficient to link as Oakland and Princeton? czar 16:21, 20 October 2018 (UTC)
 * Princeton: Princeton University Press.
 * Oakland: AK Press.
 * bump (not watching, please )  czar  13:42, 9 November 2018 (UTC)


 * maybe other editors have different practices, but in general I never wikilink locations in citations since I can't imagine a situation where a reader sees a citation and really wants to know more about a particular city in the context of it being the location of a publishing house for one of an article's sources. And I add state/province/country if it really needs disambiguating (for example, CMoS 17 has Cambridge, MA: MIT Press but Cambridge: Cambridge University Press) or if I don't think the average reader would know where a particular city would be (although perhaps I have higher expectations for the general reader since I would think everyone knows where Princeton is but CMoS 17 gives Princeton, NJ: Princeton University Press). Obviously Wikipedia house style is different from Chicago, but If the city of publication may be unknown to readers or may be confused with another city of the same name, the abbreviation of the state, province, or (sometimes) country is usually added probably works as general advice. For your Princeton example, it seems omit when the name of the work includes the location takes care of that anyway since where else would Princeton University Press be if not Princeton so location probably isn't even necessary. Just my $0.02 on this. Umimmak (talk) 21:28, 12 November 2018 (UTC)
 * I think that the inclusion of publisher's place in citations dates back to a time when the normal process for buying a book was to have your local bookseller write to its equally local publisher to order a copy of the book for you, and "Name of Publisher, City, Country" would have typically been a sufficient address for the postal system. It is perhaps not really useful information in this age of multinational publishing houses.  I would therefore not wikilink them except in unusual circumstances.  WhatamIdoing (talk) 19:07, 21 November 2018 (UTC)

Protected edit request on 21 November 2018
Please change the configuration from,

['event'] = 'Event occurs at',

to,

['event'] = 'Event occurs at time',

to match the current documentation. --Ans (talk) 15:03, 21 November 2018 (UTC)
 * Is it the module that needs to be changed or the documentation? This comparison between the current and old wikitext versions of  would suggest that the documentation is in error (the editor who wrote most of the text in  set about to document what the cs1|2 templates, not what they  do):


 * Perhaps the documentation should be changed to read:
 * OR: time: Time the event occurs in the source; preceded by default text "Event occurs at ".
 * —Trappist the monk (talk) 15:27, 21 November 2018 (UTC)
 * I think the documentation should be changed to match the module. That text in Template:Citation Style documentation/time has not been changed since February 2012, and the module has had its current text since that text was added in 2013. In both cases, unless I missed something, the documentation has never matched the module. Thanks to the sharp eyes of for noticing this discrepancy. – Jonesey95 (talk) 15:47, 21 November 2018 (UTC)
 * No, the text was added before 2013. The documentaion has ever matched the template in 2012. --Ans (talk) 05:31, 22 November 2018 (UTC)
 * I think that I don't understand what it is that you wrote. Here is a brief history of the static text associated with time:
 * – 16:56, 18 September 2007
 * – 12:29, 20 February 2012
 * – 12:31, 21 February 2012
 * – 17:48, 27 February 2012
 * – 10:11, 20 May 2013
 * – 14:47, 8 April 2013
 * Since its introduction, the template has always rendered time as: 'Event occurs at ' except during a brief period of 7 days, 5 hours, 19 minutes.  The first 1 day, 2 minutes of that period is the only time that I have found where the template and the documentation were in agreement.  The static text did not change when we shifted to the module.
 * The documentation should change to reflect the historic reality.
 * —Trappist the monk (talk) 11:22, 22 November 2018 (UTC)
 * Excellent research. Based on the above, I have changed the documentation to match how the template has always* behaved. (*for engineering-acceptable values of "always") – Jonesey95 (talk) 12:23, 22 November 2018 (UTC)
 * But the documentation has 100% always been . The documentation has never been "Event occurs at" --Ans (talk) 07:30, 27 November 2018 (UTC)
 * Agreed. The documentation has contained an error. Thank you very much for finding it. I fixed it. – Jonesey95 (talk) 10:42, 27 November 2018 (UTC)
 * Agreed. The documentation has contained an error. Thank you very much for finding it. I fixed it. – Jonesey95 (talk) 10:42, 27 November 2018 (UTC)

renaming cs1|2 error categories
There are 45 error categories at. Of those 45, 11 do not follow the name style of the 34.

Yesterday, after discovering an inappropriate category link in an article, I hunted about for other articles with the same problem. The hunt reminded me that these 11 have non-standard names. So, today I propose that on the next update to the cs1|2 module suite, we also move these new categories to new, standardized names. Here is a table of current and prospective names; the list also includes the one non-standard maintenance category. Opinions? —Trappist the monk (talk) 11:50, 29 November 2018 (UTC)
 * Are any of these populated by other templates? --Izno (talk) 13:08, 29 November 2018 (UTC)
 * Should not be (famous last words, those). Template namespace insource: searches for the category names don't find any templates that include the category name-text except for, , , and  which populates  as expected.
 * —Trappist the monk (talk) 13:45, 29 November 2018 (UTC)
 * They should not be populated by non-CS1 templates.
 * This change has been needed for a while. I think a couple of the names might need more disambiguation or explanation.
 * One that may need work is "CS1 errors: URL". Since we have multiple URL-related error categories (bare URL, missing URL), we should probably disambiguate this category name a bit. Maybe "CS1 errors: URL format" or "CS1 errors: URL syntax" (so as not to confuse things with format).
 * I would prefer "CS1 errors: missing title" to "CS1 errors: title", unless we anticipate highlighting other types of errors in the title parameter and using this category to do so.
 * The other ones that could be confusing are "CS1 errors: access-date" and "CS1 errors: format", since the access-date and format themselves are not a problem, but rather the use of them without a URL is a problem. Perhaps "... without URL". (I considered "... missing URL", but that could be misleading, since sometimes the URL should not or cannot be added.) – Jonesey95 (talk) 13:50, 29 November 2018 (UTC)
 * I chose the single-term names 'access-date', 'archive-url', 'format', 'title', and 'URL' because those names are in keeping with existing category names, , , , , etc and to keep the names as generic as possible. We might want to change 'CS1 errors: URL' to 'CS1 errors: url' as an indicator that the error applies to url.
 * All of these categories are hidden and we have taken some care to provide useful information about the category and what it contains at the top of each category page. This, I think, reduces any requirement for the category names to be explicitly descriptive.
 * Sort of off topic, there are two 'missing title' error messages; one categorizes to and the other to .  It is a bit astonishing to click that latter category link and see:
 * missing title
 * Might be worth thinking about a better error message for that category; something involving 'bare url'? I haven't quite figured out how to do that in a way that isn't too awkward though perhaps:
 * bare url in
 * —Trappist the monk (talk) 15:12, 29 November 2018 (UTC)
 * Responding to the latter suggestion first: I think the current red error message is clearer than the suggested one. The error is that the specified xxx-URL parameter is missing its corresponding title. "bare url in ..." gives the editor less help in determining the correct resolution of the error.
 * As for the difference between the existing "CS1 errors: ASIN" and the proposed "CS1 errors: format", I see the difference as this: In the former, and its siblings, the ASIN (or ISBN, or DOI) is the element at fault. In the "format" and "access-date" categories, there is nothing necessarily wrong with the format or access-date itself; the problem is that another parameter is missing. The proposed names imply (to me) a parallel meaning of "error with parameter xxx", but for these renamed categories (format and access-date), the actual meaning is not that. Hence my proposal for non-parallel names. – Jonesey95 (talk) 16:29, 29 November 2018 (UTC)
 * But we are already inconsistent by the rule that you are asserting.  and  are two such:
 * ignored
 * requires
 * requires
 * requires
 * Also,, , perhaps others. These error messages don't necessarily apply to the actual content of the parameter and may apply to 'misused' parameters instead.  Though we haven't written it down as such, it would seem the the current rule is to name categories for the parameters that they involve, be that an assigned-value error or a usage error.
 * I did say that finding a replacement bare-url error message is not coming easily to me...
 * —Trappist the monk (talk) 17:29, 29 November 2018 (UTC)
 * ignored
 * requires
 * requires
 * requires
 * Also,, , perhaps others. These error messages don't necessarily apply to the actual content of the parameter and may apply to 'misused' parameters instead.  Though we haven't written it down as such, it would seem the the current rule is to name categories for the parameters that they involve, be that an assigned-value error or a usage error.
 * I did say that finding a replacement bare-url error message is not coming easily to me...
 * —Trappist the monk (talk) 17:29, 29 November 2018 (UTC)
 * —Trappist the monk (talk) 17:29, 29 November 2018 (UTC)

I guess it goes without saying leave a redirect in case bots etc to avoid breakage. -- Green  C  14:33, 29 November 2018 (UTC)
 * Of course, but it isn't just bots; there are plenty of incoming links to these category pages from user pages, project pages, talk pages ...
 * —Trappist the monk (talk) 15:12, 29 November 2018 (UTC)
 * I don't like "CS1 errors: access-date" or "CS1 main: arXiv" because it makes it look like there's a problem with the access-date /arxiv parameters themselves. "CS1 errors: access-date without URL" would be better for the first one and "CS1 maint: cite arXiv with missing parameters" for the second one. Headbomb {t · c · p · b} 17:12, 29 November 2018 (UTC)
 * I believe the idea is consistency, brevity and universality. The categories can have multiple types of errors thus "CS1 errors" (plural) and which argument the errors are for (access-date). It could be any type of error related to access-date. But a disambiguation for the type of error ("without URL") the category is locked to only that type of error. Is that the case, each type of error for each argument has its own category? --  Green  C  17:43, 29 November 2018 (UTC)
 * AFAICT, the point is to rename existing categories, not merge them. So if the point is to rename "Category:Pages using citations with accessdate and no URL" to something more conventional, then yes, "CS1 errors: access-date without URL" would indeed only contain such errors. Headbomb {t · c · p · b} 17:46, 29 November 2018 (UTC)
 * Not seeing other categories for access-date errors in Category:CS1_errors. Right now it's only for missing URLs but any future errors could also be included in the same cat. That seems to be how the categories generally work each argument has its own error category that can hold multiple error types, though there might be some exceptions to the rule. Assuming I understand the design correctly. --  Green  C  17:56, 29 November 2018 (UTC)
 * Assuming I understand the design correctly. Since when has anything about cs1|2 ever been 'designed'?  (yeah, that's a rhetorical question)  cs1|2 has morphed from one thing to another – this hallmark of a wiki development environment bears no resemblance to 'design'.
 * The names that I have suggested were intended for simplicity. Simplicity gets you into the ballpark which I think is sufficient because, at the top of each category page, we give editors what I hope is a sufficient description of that category's content, what the error messages mean, and what to do about them.  Perhaps in future, if error counts can be sufficiently lowered, we might then combine the three url categories into one.
 * —Trappist the monk (talk) 12:03, 1 December 2018 (UTC)
 * were intended for is all I meant by "design", it's not a fancy word just an intention applied as systematically as it makes sense. I agree that the design or intention is a good one to keep it simple and easier to work with in the future. -- Green  C  15:09, 1 December 2018 (UTC)
 * were intended for is all I meant by "design", it's not a fancy word just an intention applied as systematically as it makes sense. I agree that the design or intention is a good one to keep it simple and easier to work with in the future. -- Green  C  15:09, 1 December 2018 (UTC)

Cite arxiv missing class=
New style (post April 2007) cite arxiv should have a class specified. I suggest we add a test for this Old style (e.g. gr-qc/006546) should not give the error. Or rather give the error when class is specified (Category:CS1 maint: superfluous class). Headbomb {t · c · p · b} 15:11, 30 November 2018 (UTC)
 * If a ####.#### or ####.##### arxiv is present, require class. Create a Category:CS1 maint: missing class or similar.
 * And then give a link to citation bot, like we currently do for missing authors/titles/whatever.
 * For new style arXiv identifiers, class is optional according to the template doc and has been since the documentation's . The value assigned to class does not form any part of the url that the module assembles from arxiv or eprint.  As such, this does not seem to me to rise to the level of an error message.
 * —Trappist the monk (talk) 16:03, 30 November 2018 (UTC)
 * The error message for missing class wouldn't be very critical, hence why the maintenance category over the error category (with the error message being hidden by default). More important would be for those with the superfluous class, but even there, not very critical to be displayed, if only because that once we have the categories, citation bot will be able to fix those pretty much overnight. Headbomb {t · c · p · b} 22:18, 30 November 2018 (UTC)
 * The module emits an error message when class is used with old-style arxiv (has done since the September update). These are categorized into :
 * —Trappist the monk (talk) 23:02, 30 November 2018 (UTC)
 * —Trappist the monk (talk) 23:02, 30 November 2018 (UTC)
 * —Trappist the monk (talk) 23:02, 30 November 2018 (UTC)

That's fine, now what's missing is an maintenance category to find newstyle cite arxiv missing class. Headbomb {t · c · p · b} 16:04, 1 December 2018 (UTC)
 * I disagree about the need for such error detection (it must be an error if previously optional class is now to be required). Still, if you must require class for  you can add something that might look like this:
 * the above is not known to work so test it in the sandbox against a sufficient number of testcases to prove that it works correctly.
 * Don't forget to update the documentation if you make this change to require class.
 * —Trappist the monk (talk) 17:07, 1 December 2018 (UTC)
 * Don't forget to update the documentation if you make this change to require class.
 * —Trappist the monk (talk) 17:07, 1 December 2018 (UTC)


 * I cannot make this change, as I do not know LUA, and I am not an admin. Otherwise there would have been several more features deployed long ago, a much speedier roll out of fixes for major problems. Headbomb {t · c · p · b} 20:19, 1 December 2018 (UTC)

Strange formatting problems involving citation of works in Hebrew
I just notice the strange formatting behavior at Wimpy (restaurant) that involve the use of Hebrew in one of its citations.

A snippet of code is as follows:



Which is displayed as follows:



Not being familiar with the Hebrew language, is this the best way to display such information in the cite template on the English language Wikipedia? If not, this template needs to be patched.

As an aside, is there an easy way to insert an English translation of the quotation shown in the example into the cite template? Such a feature would be very beneficial to readers of the article who are not fluent in that language that the actual quote was written in. - 147.202.209.1 (talk) 20:22, 1 December 2018 (UTC)
 * This is why we have script-title. You might rewrite the template this way:
 * For the translation of the text in quote simply add the translation to the end enclosed in .  The Hebrew text in quote might be wrapped in  as I have shown here (but only the Hebrew text in quote – do not use  in any other cs1|2 parameter).
 * —Trappist the monk (talk) 20:39, 1 December 2018 (UTC)
 * Trappist, thank you for your reply. But isn't the big problem is that the 1967: that is part of the original Hebrew title is being displayed in the wrong place in both your version and the original code that was in the Wimpy's article?  In your version, the Hebrew numerical date 1967: is somehow being separated from the original title, so I would assume that this is also an unwanted display effect.  - 147.202.209.1 (talk) 21:36, 1 December 2018 (UTC)
 * Remember that Hebrew is a right-to-left language. At he.wiki there is an article about this book, which see.  That article's title appears to match the rendering of the template when we use script-title.
 * —Trappist the monk (talk) 21:48, 1 December 2018 (UTC)
 * Remember that Hebrew is a right-to-left language. At he.wiki there is an article about this book, which see.  That article's title appears to match the rendering of the template when we use script-title.
 * —Trappist the monk (talk) 21:48, 1 December 2018 (UTC)

Edit request for Template:Cite book
Under Edition, series, volume in Template:Cite book, the edition parameter allows only for abbreviation to "ed." when in fact the word is often abbreviated to "edn" in British English, and in World English, eg according to oxforddictionaries.com. Could the template please be amended to allow for edn (no period). Thank you. JG66 (talk) 04:46, 14 October 2018 (UTC)


 * edition takes, as input, a text string to which is appended a space character and the static abbreviation 'ed.' (with a dot). There is no facility in cs1|2 to support any specific variety of English.  To accommodate this request would require some sort of new parameter or some special encoding of the value assigned to edition to tell cs1|2 to use 'edn' instead of 'ed.' when rendering.
 * —Trappist the monk (talk) 11:08, 14 October 2018 (UTC)
 * Many thanks for your reply. How would I go about trying to achieve that, do you know? Should I request the special encoding directly from a template editor, for instance? JG66 (talk) 11:28, 14 October 2018 (UTC)
 * The cs1|2 module suite sandboxen are open to all; requests not needed. All you need is a consensus for the change.
 * —Trappist the monk (talk) 13:12, 14 October 2018 (UTC)
 * Why couldn't the lua pattern for validating edition be set to allow both "ed." and "edn"? Galobtter (pingó mió) 12:03, 14 October 2018 (UTC)
 * The 'validation' pattern doesn't validate anything. It is looking for extraneous text that is often included in the value assigned to edition: 'ed', ed.', 'Ed', 'Ed.', 'edition', 'Edition' because this text is redundant to the 'ed.' static text that cs1|2 appends to the value prior to rendering.  Of course, the 'validation' can be bypassed when the last three characters of the edition value are 'edn'; that is the sort of special encoding I was thinking about.
 * —Trappist the monk (talk) 13:12, 14 October 2018 (UTC)
 * OK ... And the talk page for that module suite Module:Citation/CS1/sandbox leads right back here. I confess I'm utterly hopeless with all things template-ory. My request for a change – that is, the allowance for a second option ("edn") – is based on English language variation. I'm not sure what lengths one needs to go to achieve consensus on this sort of an issue. Does anyone object to such a change being made? I'm envisioning something that an editor could select to trigger "edn" over the default "ed.", but it wouldn't be binding beyond that. JG66 (talk) 14:06, 14 October 2018 (UTC)
 * I have these objections:
 * I see this as a path to inconsistent citation formatting; British English speakers may (unconsciously or no) use the 'edn' form in an article otherwise using the 'ed.' form; conversely, other English-variant speakers ...
 * it's yet one more niggling detail for editors to argue about
 * as far as I can tell, this is the only case where there appears to be a difference for English language variation so allowing editors to override this one parameter's static text is inconsistent with all other static text
 * this would be a special-case; special-cases are to be discouraged because they deviate from the norm
 * British English speakers apparently understand what 'ed.' means in cs1|2 templates
 * 'ed.' has been in since its
 * 'ed.' has been in since it was  to use
 * I cannot find mention of 'edn in the archives of this page nor in the archives of Template talk:Citation
 * —Trappist the monk (talk) 15:50, 14 October 2018 (UTC)
 * I agree with your objections; I don't see the need for the inconsistency here. (Just was a bit confused what you were saying regarding "special encoding") Galobtter (pingó mió) 16:00, 14 October 2018 (UTC)
 * Right, Trappist, but do you actually write articles at all, or just template away? Because, as someone who does write (and only does that here), I can say one doesn't give a crap about templates, just as readers don't, as long as the information appears on screen correctly.
 * I've provided a link to show that "edn" is the acceptable abbreviation for edition in British English (and other varieties), according to one very well known source; it's not the only acceptable abbreviation, I'm sure. All your objections seem to come from a mindset whereby the answer's no, now what's the question? I'm not surprised there's no mention of "edn" in the archives – I've contributed here for over six years, got used to an American bias and default for most things, and only now have decided to try to do something about this particular issue. "Yet one more niggling detail for editors to argue about" – of course it's not, it's an option that can be selected in a particular variance of English and only then. JG66 (talk) 16:19, 14 October 2018 (UTC)
 * What you and I here is entirely immaterial.  If you [don't] give a crap about templates, you are to free construct citations by hand.
 * The claim that "edn" is the acceptable abbreviation for edition in British English might be better phrased 'an acceptable abbreviation'; see the 'ed.' entry at your very well known source. [What's] the question?  The one you posed: Does anyone object to such a change being made?  I accept that there may be an American bias at en.wiki.  For those editors who believe that consistency between citations in an article is important, anything that makes one citation's format different from another citation's format (beyond the obvious citing of different sources) has been and will continue to be a point of contention – that was amongst the reasons that we implemented mode (so that cs1 templates render in the same manner as cs2 and visa versa) and df (so that all dates in a citation render in the specified format).
 * —Trappist the monk (talk) 17:30, 14 October 2018 (UTC)
 * Just a wild idea: would it be possible to detect whether or not the article is in (a subcategory of) Category:Use British English (i.e. uses Use British English), and change 'ed.' to 'edn' based on that? I'm not saying it would be desirable, you'd probably want to get wider consensus before changing it, but would this be a proper technical solution? rchard2scout (talk) 11:24, 3 December 2018 (UTC)
 * In theory, yes; in practice, no. There is a Lua extension, mw:Extension:CategoryToolbox, that has a function   that will purportedly return boolean indication of a page's membership in a specific category.  This extension is not installed on en.wiki
 * The structure of is not flat but is composed of dated subcategories.  When processing the templates in 1976 in Scotland, for example, the module would have to search through who-knows-how-many subcategories before it found the article in.
 * Were we to attempt this, a better way would probably be to search the article's unparsed source for the raw text string:  (and its eleven redirects).  I tried this idea in the past with the  templates to see if we could auto-format dates.  That experiment worked for articles with only a handful of cs1|2 templates but failed spectacularly when the article contained more than some number which I no longer remember – the article source had to be reread for almost every template (because almost every cs1|2 template has a date parameter of some kind) so the Lua processing ran out of time.  edition is used relatively rarely so for each article parsing, Lua would not need to reread article source all that often.
 * —Trappist the monk (talk) 13:12, 3 December 2018 (UTC)
 * Were we to attempt this, a better way would probably be to search the article's unparsed source for the raw text string:  (and its eleven redirects).  I tried this idea in the past with the  templates to see if we could auto-format dates.  That experiment worked for articles with only a handful of cs1|2 templates but failed spectacularly when the article contained more than some number which I no longer remember – the article source had to be reread for almost every template (because almost every cs1|2 template has a date parameter of some kind) so the Lua processing ran out of time.  edition is used relatively rarely so for each article parsing, Lua would not need to reread article source all that often.
 * —Trappist the monk (talk) 13:12, 3 December 2018 (UTC)
 * —Trappist the monk (talk) 13:12, 3 December 2018 (UTC)

I would object to any change supporting this variance as well. The list by Ttm above is a good list for why. --Izno (talk) 15:14, 3 December 2018 (UTC)