Module talk:Citation/CS1/Archive 7

Translated title without title
I know that we have discussed this topic some place. In is an example citation that has a translated title but doesn't have an original language title (in this case Chinese). The Help:CS1 errors text recommends finding and inserting the original title. Not so easy for a Chinese source. Anyone remember where we had that discussion? How should editors handle this type of citation situation?

—Trappist the monk (talk) 16:33, 16 April 2013 (UTC)


 * Found what I was thinking about and it isn't what I thought. How should editors handle a citation when they have a translated title but not an original title?


 * Is this the best place to be asking this question?


 * —Trappist the monk (talk) 17:35, 16 April 2013 (UTC)


 * Perhaps use "trans_title=" when "title=" empty: Many editors can be expected to discard some titles written in Kanji or Arabic characters, and just give "trans_title=My Article" and "language= " but only rarely would they use "title=@#$^@$" so then the title would seem to be missing. Currently:


 * Currently, the trans_title will just continue to show in "[...]" which seems acceptable, while we juggle other higher-priority problems. -Wikid77 13:12, 17 April 2013 (UTC)


 * I'm not looking for a technical solution. I'm looking for some guidance to offer editors who encounter this error.  Hey click on that little help link and frankly, what help is offered is pretty meager. We could suggest this for one possibility:


 * CS1 citations report this error when the citation has an English translation of the title in trans-title but does not have the original-language title in title.


 * To resolve this error, provide the original language title for title. Consider adding language if not already part of the citation. If you are unable to provide a title in the original language, consider moving the contents of trans_title to title. Place the translated title in square brackets to indicate that the title is a translated title:


 * I'm looking for a better solution.


 * —Trappist the monk (talk) 01:05, 18 April 2013 (UTC)


 * Revised part of suggested error message to match current version in Help:CS1 errors. The same applies to trans-chapter without chapter. Looking for a better solution there as well.


 * While it isn't what I started out looking for, I have wondered if there might be a technical solution. Elsewhere I have argued that any and all blank parameters should be ignored; for example, postscript without a value has a defined meaning.  I have suggested the use of a special secret codeword that explicitly informs editors that the parameter is in use. Parameters with the special secret codeword are not just empty and therefore shouldn't be deleted. To the novice, postscript and publisher are both unused and so both can be deleted.


 * So, perhaps the solution here is the special secret codeword .  If none when trans-title is not missing or empty, then title is not displayed and an error is not reported.


 * —Trappist the monk (talk) 14:45, 19 April 2013 (UTC)

Growing category of unnamed parameter pages
It is troubling that more unnamed "|text" parameters seem to be added everyday, as if people are not looking to see the results of their new {cites} or just cannot understand why, because the cite was generated by a tool and not them coding the bar "|" separators. We have talked about quietly appending unnamed parameters to the end of each cite, with a quiet superscript note: "fix cite] " to keep from splattering 20,000 articles with red-error messages. -Wikid77 (talk) 15:35, 16 April 2013 (UTC)


 * Added log day 04-17 to category table: In the table of category counts, above, I have inserted day "04-17" because the 2-day delay and weekend lull led to less activity than hoped by 04-15. Hopefully, the counts on 04-17 will reveal more-typical weekday counts in those error-message categories. -Wikid77 (talk) 15:35, 16 April 2013 (UTC)
 * The growth you are seeing is because many articles have not yet had their citations refreshed after those categories were added / updated. According to the transclusion count tool, there are currently 1922690 pages using Module:Citation/CS1, but only 1181771 pages using Module:Citation/CS1/Configuration.  Since it is not actually possible to be doing that with the current version of the code, this difference implies there are approximately 740919 pages (37% of all pages with citations) that have not yet been refreshed since the Configuration file was added on April 9th (7 days ago).  Or put another way, the job queue sucks.   It is likely that it will be quite a while yet before the categories are fully populated.  Dragons flight (talk) 18:35, 16 April 2013 (UTC)


 * Wikipedia hasn't burst into flames from the sea of red and no one is out to lynch us because of it. I have seen only three discussions involving the new messages. We figured that about 3% of the articles have errors and if it climbs to 5% then again, I don't see huge problems. --  Gadget850 (Ed) talk 18:06, 16 April 2013 (UTC)

Laysummary
And yet another inconsistency though that's not what this post is about - well, maybe it is ...

This citation should produce a  error:

This citation should produce a  error:

This citation should produce a  error:

Yeah, ok, so I'll blather about inconsistency. laysummary is supposed to hold a url. All other parameters that hold urls have url in their name. laysummary is given the title "Lay summary". doesn't create chapter links that look like this:


 * →A Book Title. "Cited Chapter" – Chapter Title.

Why should laysummary? Part of the problem with this is that the link is disconnected from the title which should never happen. Why is laysummary different?

So, I propose that we deprecate laysummary in favor of layurl. laysource becomes the link-title for layurl. When rendered, the citation will look like this:


 * →A Book Title. Lay summary – The Laysummary Source. (2013-04-16).
 * →A Book Title. Lay summary – The Laysummary Source. (2013-04-16).

—Trappist the monk (talk) 00:19, 17 April 2013 (UTC)
 * Agree. I would also like to see a 'laysummarycaption' that would modify the default "Lay summary" as desired: review, etc. --  Gadget850 (Ed) talk 18:54, 17 April 2013 (UTC)


 * I've added the URL check. Believe it or not, I somehow hadn't really processed the fact that laysummary was a URL.  Which is of course just an example of the point you are making about bad variable names.  I agree that the idea of replacing laysummary with layurl is a good one.  I'm less sure about what to do withe formatting.  The current layout:
 * [ Lay summary] –  ().
 * is undoubtedly weird. However, the semantics of laysource suggest that it is intended to be the author / publisher (though if so, why italics?), and usually we use the work title for a URL description.  Also, I'm not really a fan of that dash.  Personally, I'm not sure what to do here.  Maybe something more like:
 * Lay summary: "[ ]" ().
 * Where I've also used quotes rather than italics. Perhaps it would be helpful to look through some of the examples of how it is used to see is laysource generally makes sense as a URL title.  Dragons flight (talk) 19:02, 17 April 2013 (UTC)


 * Following your search link and random sample several pages, there doesn't seem to be a concise usage. laysummarys link to abstracts, press releases, publisher's description of a book, web sites not apparently related to the cited work, newspaper articles.  While I didn't read these summaries, my gut reaction to many of them is that they might not fit into the "summary" category – if by summary, we mean a summary of the cited work. Certainly a publisher's description of a book that it publishes doesn't fit.  Only one of the couple of dozen that I looked at bothered to change the label:
 * (from orgasm)
 * →Time for rethink on the clitoris - Lay summary – BBC News


 * I like what you did there: layurl, laytitle, and laydate: they all convey what they should convey, you placed them in the proper positions and you got rid of "Lay summary –". What's not to like?  And yeah, quotes.  If italic styling is needed, then editors can wikimarkup.


 * Right, make it so.


 * —Trappist the monk (talk) 20:09, 17 April 2013 (UTC)

Thinking about this a little bit more, and incorporating Gadget's suggestion, it seems like the right semantics is probably something like:


 * : . "[ ]" ().

Where laylabel= defaults to "Lay summary" but can be changed to acknowledge other types of associated reporting (e.g. press releases, instruction manuals, etc.). I would suggest mapping the current laysource= to layauthor=, but that leaves a problem. If I do this change, none of the lay summary URLs would have a title (i.e. they would all be classed as bare URLs). Of course none of them really have titles now since the fixed text "Lay summary" isn't very informative; however, it would amount to treating all existing lay summaries as essentially incomplete due to the lack of a title, even though there was no previous capacity to include a title. That only affects about 140 pages, so maybe not so big a deal, though I am a little reluctant to do something that breaks existing usage. Dragons flight (talk) 15:54, 18 April 2013 (UTC)


 * I don't like defaulting text unless there is a way to prevent its display. The default text "Lay summary" should only display when laylabel is missing or blank. If laylabel has any value except the special secret codeword " " (same special secret codeword that should be used with postscript), then that value is displayed. This way editors know that a label is intentionally not displayed.


 * If there is a parameter with the word author in its name, then the parameter should be treated like an author-type parameter. layauthor should probably not map to laysource because laysource is really more a title than an author. Titles get italicized, authors don't.


 * layurl should become a synonym of laysummary because they both hold urls. laydate doesn't change.


 * Laysummary
 * laytitle: Title of a non-technical summary or review related to the source; synonym: laysource (deprecated);
 * layurl: URL of laytitle; synonym: laysummary (deprecated);
 * laylabel: Type of summary – abstract, press release, instruction manuals, etc.; when blank or not included, defaults to "Lay summary:"; displays value when included followed by a colon ; if laylabel=, suppresses label display;
 * layauthor: Author or list of authors of the summary;
 * laydate: Date of the summary displayed in parentheses.


 * —Trappist the monk (talk) 16:59, 18 April 2013 (UTC)


 * Is laysource ever used as a title? I went through 20 of these things and didn't note a single example where it was being used to describe the specific content being linked.  Mostly it had content like "CNN" or "ScienceDaily", which told you who published the summary but not what it contained.  Dragons flight (talk) 17:09, 18 April 2013 (UTC)


 * Argh!, You're right. Used more like publisher, or journal, or newspaper, though publishers shouldn't be italicized. That tosses a spanner into the works doesn't it? Or does it?


 * If laysource is deprecated and we make it synonymous with laytitle, there is still something that approximates a correct link label. Readers would see:


 * http://example.com CNN CNN 2013-04-18
 * →Lay summary: "CNN" (2013-04-18).


 * No need to report any errors unless there were embedded wikilinks:
 * →Lay summary: "[[CNN] ]" (2013-04-18).


 * Doesn't this work?


 * —Trappist the monk (talk) 20:12, 18 April 2013 (UTC)

Update affecting archiveurl
I recently resynced the code. From an end user perspective, the biggest change is that I consolidated the archiveurl errors so that cite web now has the same behavior as the other templates and is visible. Hence Category:Pages with archiveurl cite web errors should be in the process of merging into Category:Pages with archiveurl citation errors, and the special deadurl=no error message has also been eliminated since url= is presently required whenever archiveurl= is present, regardless of the deadurl state. Dragons flight (talk) 01:02, 17 April 2013 (UTC)

Separator
"Defaults to a period (.); if the parameter is present but blank, no separator punctuation will be used;"

—Trappist the monk (talk) 01:16, 17 April 2013 (UTC)
 * There has been discussion on defaulting to a period if 'separator' is blank. This is the better method, as a blank separator isn't right. --  Gadget850 (Ed) talk 01:26, 17 April 2013 (UTC)


 * Makes sense to me.


 * —Trappist the monk (talk) 02:17, 17 April 2013 (UTC)


 * This wasn't actually intentional. As presently implemented, blank values are ignored for all parameters except "postscript".  For most parameters, that is fine because the default value is blank.  However, a handful of parameters have non-empty default values (listed in the config file), and presently there is no way to reset those parameters to blank (except for postscript= which is handled as a special case).  Are there any cases where resetting those parameters to blank is actually a sensible thing to do?  Should additional allowances be made for blanking out any of the other default values?  Dragons flight (talk) 17:58, 17 April 2013 (UTC)


 * I think that any parameter should be ignored. It should be obvious to all editors, regardless of experience level, when a parameter is doing something.  Editors ought to be able to look at a citation, see blank parameters, and delete them without breaking the citation's display.  Instead of postscript, perhaps none is better.


 * Yeah, I know, but-there-are-already-a-bunch-of-editors-who-know-and-use-postscript-the-way-it-is. Sigh. Deprecate it.  We already detect the empty version of postscript so changing what happens after detection ought not be that hard.  (is it?) Found postscript suggest none. And yes,


 * —Trappist the monk (talk) 18:56, 17 April 2013 (UTC)

Author mask
When set to a text value, includes either the default or author-separator specified separator. This behavior is different from the old-style citations.

—Trappist the monk (talk) 12:31, 17 April 2013 (UTC)


 * Fixed in sandbox. Dragons flight (talk) 18:23, 17 April 2013 (UTC)

Displayauthors
Setting 0 hides the author list but still displays et al. This might be a useful artifact if the et al. display can also be suppressed when 0.

—Trappist the monk (talk) 12:36, 17 April 2013 (UTC)
 * Useful how? --  Gadget850 (Ed) talk 12:48, 17 April 2013 (UTC)


 * I don't know, that's why I said it might be a useful artifact. If it isn't useful at all, then CS1 should act the same as the old-style templates.


 * —Trappist the monk (talk) 14:00, 17 April 2013 (UTC)

Honestly, I'm not really sure what to do. Ignoring it seems silly since someone must have intentionally added the 0, at the same time displaying only "et al." also seems silly. Without a use case where displayauthors = 0 makes sense, I'm not sure it really matters what we do here. Dragons flight (talk) 18:27, 17 April 2013 (UTC)


 * Incidentally, we are currently ignoring non-integer values, e.g. 3.14159 does nothing. I can't really think of any use case where it makes sense to worry about that either.  Dragons flight (talk) 18:29, 17 April 2013 (UTC)


 * I'm perfectly happy to constrain displayauthors (and displayeditors) to integer values >0. I'm also happy if an editor sets either to 0.  If we accept that though, the et al. should be suppressed and, for editors, drop the "In".


 * Probably easiest to constrain displayauthors and displayeditors to integer values >0.


 * Interesting that -0 works the same as 0, but -1 isn't the same as 1. (a function of the Lua math library?) Yep, more pathological inputs ...


 * —Trappist the monk (talk) 19:21, 17 April 2013 (UTC)


 * On reflection, I'm inclined to allow displayauthors=0 be available to completely remove the author list (i.e. no "et al."). I still can't think of a use case for such a thing, but at least it would provide output that looks sane.  Dragons flight (talk) 16:03, 18 April 2013 (UTC)
 * Okay, I made it possible to completely hide the authors by setting displayauthors = 0, not sure why one would do that but it seems the most logical code response to a strange input. Dragons flight (talk) 00:11, 19 April 2013 (UTC)


 * Until someone can make the case for a reasonable use, I think that this feature should remain undocumented.


 * —Trappist the monk (talk) 00:41, 19 April 2013 (UTC)


 * Fine by me. Dragons flight (talk) 00:50, 19 April 2013 (UTC)
 * it's a cool feature, which i've used. pls don't remove (though there's a workaround even if you do). thnx!! 70.19.122.39 (talk) 14:58, 22 April 2013 (UTC)


 * Can you tell us why you used it? What are the benefits over the workaround (and what is that workaround)?


 * —Trappist the monk (talk) 15:11, 22 April 2013 (UTC)

Horus Heresy (novels), where it is being used to list every version of a work without specifying the actual source used:


 * ;; ;;


 * ;; ;;

I've been into this article before— it and related articles are a magnet for odd markup and template usage. It also uses 'format' without 'url' and is going to turn into a red sea when we enable those messages. --  Gadget850 (Ed) talk 15:30, 22 April 2013 (UTC)


 * i agree 100% that we disagree 100% on how meaty chunks of the citation system should be designed, implemented, and used. if readers in general complain about the above example, it will be changed. but (and not referring to you), based on very crude sampling, it seems "wikipedians' " distribution is heavily weighed towards the curmudgeon/nit-picker/legalistic/literalist type. well that's my experience at least. not exactly a normal real-world median. this type can, and will, find anything wrong. 70.19.122.39 (talk) 00:45, 23 April 2013 (UTC)


 * What a mess. Doesn't WP:NOT apply to that kind of collection?


 * Regardless, the editor has caused me to wonder if there is a legitimate use for 0. In bibliographies, n replaces an author's name with n mdashes.  When multiple authors have together authored multiple works listed in the bibliography, an admittedly rare case, an editor might elect to include author masks in the second and subsequent citations.  To mask all of the authors requires an authormask for each displayed author.


 * (author mask for each author)
 * (one author displayed)
 * (one author displayed)


 * I can imagine that a cleaner and easier solution would be to set 0 and authormask to whatever to produce something that looks like this


 * ——. Fourth Collective Work.


 * This is a special case for when 0 and n because it can be argued that 1 and n is just as easy and probably more correct. As such this notion should not rank very high on anyone's implementation list were it ever to be decided that it's worth doing.


 * —Trappist the monk (talk) 18:57, 22 April 2013 (UTC)


 * wait, do tell (not here, its off-topic) how WP:NOT is not up to par with that "collection"? 70.19.122.39 (talk) 00:45, 23 April 2013 (UTC)
 * Do whatever you want— I don't wrestle with greased pigs. The Warhammer articles are a crufty, walled garden of a mess and I will stay out of it. --  Gadget850talk 00:54, 23 April 2013 (UTC)
 * ok. but it seems slightly evasive. i'm sorry for the off-topic tangent. 70.19.122.39 (talk) 01:08, 23 April 2013 (UTC)

Parameters that rely on other parameters should have error messages
Like accessdate requires url, displayauthors requires authors, and authormask requires authors.

Yeah, it's that consistency thing again.

—Trappist the monk (talk) 12:42, 17 April 2013 (UTC)


 * Because of how the lists are structured, everything to do with author parameter checking is rather a pain. Maybe I'll get around to it eventually, but its not a high priority.  Incidentally, the suggested errors above don't really work either.  displayauthors= and authormask= only work properly with an author list, i.e. author1=, author2=, etc., or its equivalent and not with the generic authors=, so one would also have to have some way to convey that.  Dragons flight (talk) 16:09, 18 April 2013 (UTC)

Avoid reformatting 2 million articles all month
We should stop changing Citation/CS1 every few days. I was afraid that rewriting the wp:CS1 cites into Lua, to supposedly make Wikipedia run faster, would lead to endless, daily changes to the cite-engine, which then trigger the wp:Job_queue to reformat 2 million pages, to reformat 2 million pages, to reformat 2 million pages, to reformat 2 million pages, to reformat 2 million pages, etc. The continual reformatting of the affected pages has been running over a month now, including changes to, on 17 March 2013. At this point, I think we need to consider delaying changes to perhaps just once a week, or once every 2 weeks. -Wikid77 (talk) 13:31, 17 April 2013 (UTC)


 * I guess I don't understand. Are you saying that the Wikipedia servers hold fully rendered articles on some disk in the server farm and that Lua-based, as well as template-based citations aren't processed "on-the-fly"?


 * Clarify please.


 * —Trappist the monk (talk) 14:09, 17 April 2013 (UTC)
 * Yes. The servers cache the current version of an article for registered readers. When we make these updates, the changes go into a job queue. You can force an update by editing an article or using the API sandbox. See Help:Job queue. --  Gadget850 (Ed) talk 14:19, 17 April 2013 (UTC)


 * Top-revision panel is cached and skin borders are overlayed: The process has changed over the years. As I understand the current composite formatting of a Wikipedia webpage, the screen panel which shows the article text/images portion is stored into cached form (for 220-pixel image size), then when viewed by each user, unless some template/module has changed, that cached form is read by another server to generate a "cache-copy" with the menu borders and username data overlayed around the cached contents 2x-50x times faster, regardless of browser skin (&useskin=monobook). Every IP user always sees a cache-copy. Other image-size settings, or other unusual settings (in Special:Preferences), will cause the entire page to be regenerated from scratch, for every page viewed by a username, even if many other users also share the same alternate image size (formerly 180px was the default). Every prior revision, viewed from History, is always reformatted from scratch. When a template is changed, then the WhatLinksHere pages are all queued to regenerate the cached-form of the top revision, but those pages seem to be spread across the wp:Job_queue, as if 2 million pages were being queued as 4,000 groups of 500 pages each, by "spreading" them across the queue. Once a page reaches the top of the queue, then whichever server, which grabs that request, will check to see if that page has already been reformatted by some other edit-save (or by a prior request from another changed template in the queue); so only "invalidated-cache" pages will be reformatted. Meanwhile, any other updated template with a "zillion" links will also bombard the queue(s) with numerous pages to reformat, and hence the recent non-consensus changes to Template:Convert (to put hidden category links into every converted number) dumped a load of 524,000 articles into the job queue, which generated hundreds of broken conversions of non-numeric "[ [Category:...]]" (links), which perhaps, with careful prior discussion (and various testing) might have been avoided. Once those non-numeric category links were discovered, then {Convert} was changed 5 more times, to re-schedule those 534,000 pages to reformat and reformat and reformat. Now, hopefully, the job queue will wait awhile these days, to see if a template is changed again 3x times within 20 minutes, before rescheduling each 2-million page reformat; but in the past, changing a template would cause 400 pages to reformat within 4 minutes. Several cases of prior reformatting of 300,000 pages have stretched into a 4-day process. However, the exact optimization tricks, to rethink a template/module just edited one hour prior, are a separate discussion. -Wikid77 (talk) 16:08, 17 April 2013 (UTC)


 * You're right about most of the technical details, but as far as I can tell, none of that actually articulates a reason why we should wait a week or two between deployments. I assume your implicit argument is something along the lines of "constantly regenerating caches is bad for the servers".  But the reason the job queue exists is to make sure updates are sufficiently spaced out and delayed so that they avoid being burdensome on the servers.  When the job queue is working as intended, I'm not aware of any evidence that the load introduced by recaching these 2 million pages is harmful, or even all that noticeable compared to pre-existing loads.  Nor am I sure why waiting a week or two would make any difference (either recaching 2 million pages is harmful or it isn't, delaying isn't going to change that).  Historically there have been some issues with the job queue itself introducing excessive write activity on the database servers when adding large numbers of jobs to the queue, but as I understand it that problem is supposed to be resolved.  Dragons flight (talk) 17:54, 17 April 2013 (UTC)

Documentation updates
I have started updating the template documentation using a 'lua' parameter to select the appropriate doc set. Parameters updated so far:


 * Citation Style documentation/author
 * Citation Style documentation/display
 * Citation Style documentation/volume

--  Gadget850 (Ed) talk 14:45, 17 April 2013 (UTC)


 * I have done . Shall I stop there and let you do the rest?  I get the impression that I'm stepping on your toes.


 * —Trappist the monk (talk) 15:16, 17 April 2013 (UTC)
 * I will get to them. What do we need to update yet? --  Gadget850 (Ed) talk 15:19, 17 April 2013 (UTC)


 * I starting at the bottom of the and working my way up looking at how the parameters worked and how they compared to the old-style template parameters.  That is what cause the several posts last night for the display parameters.  So I've been through Display options, Laysummary, and Editors.


 * —Trappist the monk (talk) 15:24, 17 April 2013 (UTC)

Duplicate missing title error messages with cite web
Elsewhere Editor 117Avenue used this :



We don't really need two error messages and two different categories for a single error do we? The cite web version and Category:Pages using web citations with no title should merged into the more general version.

—Trappist the monk (talk) 10:28, 19 April 2013 (UTC)

As an adjunct, we have three missing or empty title error messages that more-or-less mean the same thing: Bare URL without a title (anchor: ), Citation without a title of any form (anchor:  ), and Web citation without a title (anchor:  ). Why? Can we combine these three?

—Trappist the monk (talk) 11:53, 19 April 2013 (UTC)


 * The plan has been for cite_web_title to be merged into bare_url_missing_title, but it hasn't been done yet because the former is currently visible while the latter is hidden. It is already the case that only one of bare_url_missing_title and citation_missing_title is allowed to be shown, e.g.:




 * Because they can have non-overlapping circumstances, I have generally planned for both citation_missing_title and bare_url to continue to exist indefinitely. Dragons flight (talk) 16:54, 19 April 2013 (UTC)

Error categories and user pages
I'm just wondering if it's really worth adding user pages to all those error tracking categories? The purpose of the categories is to list the pages that need fixing so that editors can then come along and fix the issues. But most people are going to be less inclined to update the user page errors. So eventually once the other errors are fixed, the categories will mainly contain pages that nobody wants to fix and it will not be as easy to notice when new pages come along that do need fixing. So why not sort it out now and remove categorisation on user pages (and maybe some other namespaces as well)? -- WOSlinker (talk) 12:23, 19 April 2013 (UTC)


 * I've been wondering that too. I would add pretty much any form of talk page: Module talk, Template talk, Help talk, Wikipedia talk, and perhaps even article talk. Anything where readers are the primary consumer should be categorized.  I don't know how to accomplish this but I'd be surprised if Lua didn't have the ability to get current namespace, something akin to the magic word.


 * —Trappist the monk (talk) 13:00, 19 April 2013 (UTC)
 * We do namespace detection on Help:Cite errors and show them only on main (article), template, category, help and file pages. This was implemented after the developers expanded the error checking and it took a while for a group of editors to implement the namespace and help pages.
 * However, editors who develop draft articles in their userspace are then hit with errors when they move to articlespace. Regardless, if we suppress it, we need the option to show it for concerned editors.--  Gadget850 (Ed) talk 17:14, 19 April 2013 (UTC)


 * I didn't read in anything in what Editor WOSlinker wrote that suggests error message suppression in user space, just categorization. Did I misread?


 * —Trappist the monk (talk) 17:24, 19 April 2013 (UTC)


 * At right is a list of namespaces. I would suggest excluding: User, User talk, and Wikipedia talk (mainly because of WP:AFC, e.g. Category:Pages using web citations with no title), but leave the categories for the other namespaces.  This would be done by essentially setting nocat = true by default for these namespaces, with the effect that the error message would still be present but no categories would be added.  Dragons flight (talk) 17:21, 19 April 2013 (UTC)


 * I've added a configuration handle "citation_config.uncategorized_namespaces" to the sandbox configuration page using my suggested defaults, though others are free to adjust this. I'm going to go add code to the sandbox to actually make this check happen now.  Dragons flight (talk) 17:29, 19 April 2013 (UTC)


 * Okay, there is a working version of this set up in the sandbox. Dragons flight (talk) 17:48, 19 April 2013 (UTC)


 * Pass namespace as a configuration argument: The Lua module is accepting configuration arguments, during the #invoke, as well as parameter arguments passed from the caller page. We have been setting "|namespace=" in other templates, to allow obvious access to the same {NAMESPACE} variable used in markup templates. For Template:Cite_web, that would become:
 * { {#invoke:citation/CS1|citation
 * CitationClass=web |namespace= }}
 * Then there would be no second-guessing if a Lua function for namespace data might be giving a different result than {NAMESPACE} in templates. -Wikid77 (talk) 16:49, 19 April 2013 (UTC)
 * Well there's also mw.title.getCurrentTitle.namespace or mw.title.getCurrentTitle.nsText -- WOSlinker (talk) 17:15, 19 April 2013 (UTC)


 * Asking the parser for and passing it in is slower than getting the same information inside Lua.  We used to be passing  in via template and I dropped that for the same reason.  Dragons flight (talk) 17:21, 19 April 2013 (UTC)

Translated title and chapter error messages
I'm thinking that the translated title and chapter error messages aren't quite right. The translated title error message is missing or empty title. It gets lumped in with all of the other possible missing or empty title error messages. The translated chapter error message is missing or empty chapter. It is solitary. Both of these error messages are categorized into Category:Pages with citations using translated terms without the original, yet trans-title is part of the group of missing or empty title errors at Help:CS1 errors.

I think a name change is in order:
 * trans-title requires title
 * trans-chapter requires chapter

—Trappist the monk (talk) 12:25, 19 April 2013 (UTC)


 * I'm in favor of the description change. Dragons flight (talk) 18:00, 19 April 2013 (UTC)


 * Not sure what you mean by description change. Do you mean that you are in favor of changing the error message text or do you mean something else?


 * —Trappist the monk (talk) 19:38, 19 April 2013 (UTC)


 * Yes, I meant the error message. Dragons flight (talk) 19:39, 19 April 2013 (UTC)


 * Changed in sandbox.


 * —Trappist the monk (talk) 19:47, 19 April 2013 (UTC)


 * And Help:CS1 errors updated;


 * —Trappist the monk (talk) 20:05, 19 April 2013 (UTC)

The trans_title should have no error message as when specified by users who cannot read the original title, depending on browser character support.

There is no need to keep making every other option, now, show a red-error message where never shown before. -Wikid77 (talk) 16:49, 19 April 2013 (UTC)


 * There are several options here. One is to drop the error entirely, and simply consider translated titles sufficient.  Another is to consider it a full error and make it visible.  A middle ground might be to keep the error but never make it visible by default, so that only sophisticated wikignomes would worry about cleaning this up.  Personally, I'm not sure.  Most of the time when a foreign language work is cited, the editor using it understands that language, in which case the editor ought to have no problem adding the original title.  There will be some exceptions where an editor is working from an already translated or multi-language work, but those tend to be much rarer in my experience.  Dragons flight (talk) 18:00, 19 April 2013 (UTC)
 * I just did a 5% sample of pages with this issue: most were simply missing the original title and could be easily fixed, some should have used 'title' and a few had dead links, so I don't know. With 259 pages, it isn't a big problem. --  Gadget850 (Ed) talk 18:47, 19 April 2013 (UTC)
 * You're probably right. I had forgotten that this was such a relatively rare error to begin with.  Dragons flight (talk) 18:51, 19 April 2013 (UTC)

Title and translated title styling
Shouldn't the trans-title value be italicized in the same manner as title? But not the same way as the old-style citations; brackets should not be italicized.

Should look like this: "Title" &#91;Translated Title&#93;.

—Trappist the monk (talk) 12:39, 19 April 2013 (UTC)

Fixed in sandbox?

—Trappist the monk (talk) 13:43, 19 April 2013 (UTC)


 * I'm not so sure, at present the trans-title style can follow either an italic title, or a quoted title. Because of that I sort of purposely left it as plain text.  For example:


 * With the italics added, the chapter translation style seems wrong. We could leave it without the italics, or we could differentiate a trans-italic-title and a trans-quoted-title style I suppose.  Dragons flight (talk) 18:15, 19 April 2013 (UTC)


 * This is why you are the coder and I'm not. Yes, with the italics added the way I did it, translated chapter style is wrong.  I didn't realize that the same message_list item is used for both title and chapter.  I think that the rule should be: If the original language entity is italicized, then the translation shall be italicized because they are the same thing.  Brackets shall not be italicized.


 * Should look like this:
 * Dolvet, Jean (1998). "Ancien Régime" [Old Regime]. République Française [Republic of France].


 * Can be done?


 * —Trappist the monk (talk) 18:59, 19 April 2013 (UTC)
 * Shouldn't the translated chapter be in quotes:
 * Dolvet, Jean (1998). "Ancien Régime" ["Old Regime"]. République Française [Republic of France].
 * I would like these to use different style spans, as the quotes could be different if the module is ported to another language. --  Gadget850 (Ed) talk 19:15, 19 April 2013 (UTC)


 * Perhaps like the old-style except that for title, the brackets aren't italicized. Here are the three currently suggested versions.  Compare:
 * Dolvet, Jean (1998). "Ancien Régime" ["Old Regime"]. République Française [Republic of France].
 * Dolvet, Jean (1998). "Ancien Régime [Old Regime]". République Française [Republic of France].
 * Dolvet, Jean (1998). "Ancien Régime" [Old Regime]. République Française [Republic of France].


 * —Trappist the monk (talk) 19:26, 19 April 2013 (UTC)


 * We rarely talk about such things, but looking up APA style they use brackets but don't apply italics or quotes even when such markers apply to the original (so basically the same as the current "Lua" version shown above). MLA style apparently doesn't make any provision for the use of translated titles at all.  That said, the simplest option for me is probably to differentiate the style configurations and let other people sort out the formatting.  Dragons flight (talk) 19:36, 19 April 2013 (UTC)


 * In the sandbox I've added settings to allow translated titles to be styled differently when associated with italic titles or with quoted titles. Personally, I'd just as well not add italics or quotes to the translated titles, but I let other people figure out what is needed.  Dragons flight (talk) 21:36, 19 April 2013 (UTC)


 * ✅ This is good. I like it.


 * —Trappist the monk (talk) 23:18, 19 April 2013 (UTC)

New errors visible
I've resynced the sandbox. In the process, I've made the bare_url error message visible and merged cite_web_title into it. I've also revealed the translation errors, the citation with no title error, and the URL with no scheme error. Combined with the cite web archiveurl error merged earlier in the week, this marks the second block of error messages made public. Dragons flight (talk) 23:14, 19 April 2013 (UTC)


 * PS. I should also note that this release also adds error category suppression by namespace. As presently configured, User, User talk, and Wikipedia talk will not be added to error categories.  The error message is still displayed to the editor but it is not added to the tracking cat.  Dragons flight (talk) 23:17, 19 April 2013 (UTC)


 * Brilliant!


 * Help:CS1 errors updated to reflect current error messaging.


 * Does this mean that error_conditions.cite_web_url in Module:Citation/CS1/Configuration should go away?


 * —Trappist the monk (talk) 23:36, 19 April 2013 (UTC)


 * I removed cite_web_title. cite_web_url is a different issue.  Dragons flight (talk) 01:08, 20 April 2013 (UTC)


 * Just further proof, as if more were needed, that sometimes I am an idiot. Nevermind.


 * —Trappist the monk (talk) 11:15, 20 April 2013 (UTC)

Missing title?
In the above example the error message is misleading, as the parameter that is missing is chapter, not title. GregorB (talk) 08:16, 20 April 2013 (UTC)


 * Yeah, I think I agree. I hunted through the argument_map and found all of the url labeled parameters. Here are the four that I expect to see cause this error (are there others?):
 * chapterurl or contributionurl expects: chapter, contribution, entry, article
 * chapterurl or contributionurl expects: chapter, contribution, entry, article
 * chapterurl or contributionurl expects: chapter, contribution, entry, article


 * conferenceurl expects: conference
 * conferenceurl expects: conference
 * conferenceurl expects: conference


 * → (not currently supported?)
 * transcripturl expects: transcript
 * transcripturl expects: transcript


 * titlelink and url contending for title; titlelink wins, should it? Should titlelink even exist since without url, title can be wikilinked?
 * titlelink and url contending for title; titlelink wins, should it? Should titlelink even exist since without url, title can be wikilinked?
 * titlelink and url contending for title; titlelink wins, should it? Should titlelink even exist since without url, title can be wikilinked?


 * Is there anything else that causes this error?


 * The error message as now presented lacks specificity. I presume that we could change the message to be something like this:  needs title .  The help page can list the appropriate matching title parameters (it should do that now, I'll fix that).


 * —Trappist the monk (talk) 12:27, 20 April 2013 (UTC)


 * That would be fine. Thanks! GregorB (talk) 13:18, 20 April 2013 (UTC)
 * 'transcripturl' goes with 'transcript'. Used in cite episode and cite serial. --  Gadget850 (Ed) talk 15:09, 20 April 2013 (UTC)
 * ...and, apparently, several such parameters may be missing at the same time:


 * Chapterurl and contributionurl are mutually exclusive, a condition that is already detected as an error. Of course, the chapterurl case should be handled too. GregorB (talk) 17:12, 20 April 2013 (UTC)


 * Wow, something weird happened. Somehow Editor Gadget850's signature ended up in one of the examples above.  I've returned it to it's proper place.


 * I'm not sure that I'm following your meaning. conferenceurl and contributionurl suffer from the same shortcoming that you identified for chapterurl.  Did you mean something different from that?  What did you mean by "missing"?


 * When I suggested needs title I meant it to apply to all of chapterurl, conferenceurl, contributionurl, and transcripturl so that when, for example, contributionurl is missing its associated title, the error message would be:  needs title.


 * And thanks for noticing these.


 * —Trappist the monk (talk) 17:49, 20 April 2013 (UTC)
 * Well, I wasn't sure if the error message is displayed separately for each "violation", or just once. Currently, multiple messages are displayed, which should be OK once the fix is applied. The above is merely an additional test case that checks for handling of multiple missing params in the same invocation. GregorB (talk) 18:12, 20 April 2013 (UTC)


 * This has now been updated in line with the suggestions. Dragons flight (talk) 18:46, 25 April 2013 (UTC)

Citation: ref
Per citation: "If an empty ref is given, no anchor is generated". The Lua version does not honor this.

--  Gadget850 (Ed) talk 08:57, 20 April 2013 (UTC)


 * Argh! Another empty parameter that requires the editor to know the esoterica of  and another editor's intention: did the editor leave it blank intentionally or inadvertently.


 * No empty parameters. They are ambiguous. Use the special secret codeword none to tell CS1 that it is not to create an anchor.


 * —Trappist the monk (talk) 13:03, 20 April 2013 (UTC)


 * As before, I'm generally not going to break from documented usage. I've updated the sandbox to work as previously intended.  However, I have also added an option to allow none to accomplish this behavior.  So one could start encouraging people not to use blank.  Eventually we could use a bot to migrate the existing uses.  Dragons flight (talk) 17:37, 21 April 2013 (UTC)


 * And postscript too! Brilliant!


 * I don't think that I'm asking you, or anyone here, to go against documented usage. If I do, or have, let me know.  I am asking for ways to improve what exists so that for those things that are inconsistent or that might be misinterpreted or that might be improved, there are consistent, unambiguous, improved alternatives that editors can be encouraged or persuaded to use.  When CS1 next gets synced to the sandbox, one of us can tweak the ref and postscript documentation to begin that process.


 * —Trappist the monk (talk) 18:26, 21 April 2013 (UTC)

Configuration
The "in_text" constant, which is used before a list of editors, should be moved to the configuration subpage as well. --DixonD (talk) 22:40, 20 April 2013 (UTC)


 * Done in sandbox. Dragons flight (talk) 17:13, 21 April 2013 (UTC)
 * There are also the " " and " " literals in the " " function. --DixonD (talk) 17:35, 21 April 2013 (UTC)


 * Done. Dragons flight (talk) 20:03, 21 April 2013 (UTC)

Error message won't go.
See Rutherfordium. I've added, it works, but the error message is still visible. The named ref is used four times. -DePiep (talk) 15:34, 21 April 2013 (UTC)


 * Here is the citation taken without modification from the article:




 * No problem here. And, there are only three instances of the citation name in the article.  The fourth is in .  Look there, you'll find a duplicate of this citation without the displayauthors parameter.


 * —Trappist the monk (talk) 16:12, 21 April 2013 (UTC)
 * Thanks. -DePiep (talk) 16:35, 21 April 2013 (UTC)

Pages in the User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.
I've been sent here from Help_talk:CS1_errors to ask if anyone here can identify the reason that 4 user talk pages are included in Category:Pages with citations lacking titles. Thanks, Illia Connell (talk) 21:39, 24 April 2013 (UTC)


 * It's just a bad cache of the page that hasn't been updated. A WP:NULLEDIT of each page clears it and removes the category.  There have been a lot of apparent issues lately with the job queue not updating some pages as the Module has been edited, so you end up with some stuck pages like this that reflect an old version of the Module (in this case before User space was removed from the tracking cats).  It's really some kind of a bug in Mediawiki's cache update system.  Dragons flight (talk) 22:07, 24 April 2013 (UTC)
 * Thanks for the speedy reply. Regards, Illia Connell (talk) 22:21, 24 April 2013 (UTC)

| unused_data =
User:Citation bot adds some instances of, such as here:. If the new citation templates flag this as an error, perhaps there should be some coordination with the bot so that it does something more appropriate with stuff it can't figure out. Regards, Illia Connell (talk) 03:07, 25 April 2013 (UTC)
 * On the other hand, maybe flagging it as an error is exactly the intended effect. That way there's a chance someone will notice and fix it. —David Eppstein (talk) 03:12, 25 April 2013 (UTC)
 * I agree, the bot does the right thing and it is an error, it's just that currently it is reported just like any other unrecognized parameter. At first - before I figured out it was added by a bot, as a way to separate "random junk" from actual parameters - I didn't quite understand how to fix these. So, I think that a separate error help section just for unused_data might be in order. GregorB (talk) 09:09, 25 April 2013 (UTC)
 * Don't think a separate category is needed. The error is the same before and after the bot edit. Apart from the marking (it might be overlooked by the eye, but is caught anyway in the new CS1), we could do without this bot action. -DePiep (talk) 10:07, 25 April 2013 (UTC)
 * FWIW: Actually, the error is not exactly the same before/after the bot action. First it was an "unused textvalue" error (not assigned to any parameter), after the bot action it is an "unknown parameter" error. The page is also put in a different category. -DePiep (talk) 21:35, 25 April 2013 (UTC)
 * Good point: with Lua error handling, I don't think these edits would serve any useful purpose anymore. Still, a large number of such edits were already made, so while a separate category is unnecessary, a separate error section would make sense, at least in the transitional period. GregorB (talk) 10:31, 25 April 2013 (UTC)
 * In this specific case, the bot made an error in trying to fix the nowikied "c|net". Regardless, I think we should request that the bot stop doing this, as it is no longer needed on the updated templates. --  Gadget850talk 10:53, 25 April 2013 (UTC)


 * Anything inside  tags is stripped of any significance. The publisher parameter prior to Citation bot's edit looked like this:


 * and after, like this:


 * CS1 treats everything inside  as simple plain text without significance; nothing wrong, so nothing to report. Apparently, Citation bot ignores the </nowiki> tags and treats everything literally.


 * —Trappist the monk (talk) 11:26, 25 April 2013 (UTC)
 * I started a discussion on the bot page. --  Gadget850talk 12:38, 25 April 2013 (UTC)

I've taken some examples from the last 1500 edits of the bot and compared the before and after citations. (By chance, these happen to be cite web or cite book). These show some of the bizarre things editors can do with the citation templates, and what the bot and LUA can handle.

Example 1 The bot edit is understandable (although wrong), and LUA did not flag it as something to review As described above, this is not an error by the template.
 * Before Citation bot
 * After Citation bot
 * After Citation bot
 * Comment
 * Comment

Example 2 LUA and the bot caught this error. I prefer the LUA message before the bot edit.
 * Before Citation bot
 * After Citation bot
 * After Citation bot
 * Comment
 * Comment

Example 3 LUA did not catch the  in the before bot version. The bot caught it, and LUA flagged it for review.
 * Before Citation bot
 * After Citation bot
 * After Citation bot
 * Comment
 * Comment

Example 4 LUA and the bot caught this error. I prefer the LUA message before the bot edit.
 * Before Citation bot
 * After Citation bot
 * After Citation bot
 * Comment
 * Comment

Example 5 LUA did not catch the  in the before bot version. The bot caught it, and LUA flagged it for review.
 * Before Citation bot
 * After Citation bot
 * After Citation bot
 * Comment
 * Comment

Illia Connell (talk) 18:32, 25 April 2013 (UTC)


 * Isn't Example 4 just you not closing the template?
 * You are absolutely correct - my mistake. Thanks for pointing it out.  Illia Connell (talk) 19:15, 25 April 2013 (UTC)
 * Currently the Lua version is set to completely ignore parameters that are empty, and doesn't check them against the list of supported parameters. We could add such a check, but removing unknown empty fields seems much less important that considering unknown fields with content.  So I thought it made sense to focus effort of things that are more important.  Dragons flight (talk) 19:00, 25 April 2013 (UTC)
 * That makes lots of sense. Maybe the bot should do the same.  Regards, Illia Connell (talk) 19:15, 25 April 2013 (UTC)
 * uhrgh: so when empty parameters (=no value entered) are Lua errored in a next CS1 version, I am supposed to check & edit my watchlist again? I approve the priotities you write here, DF. No problem. But as far as I am concerned, I'd rather have this projected error message together with a big CS1 change. (me from wp:chemical elements)-DePiep (talk) 20:45, 26 April 2013 (UTC)
 * I'm not sure empty parameters will ever be treated as an error. They could be, if people wanted to do that, but from my point of view they are basically harmless.  It might make more sense set up a bot to go around and remove them, that is if people actually think they are worth removing.  That's not to say that there will necessarily never be more CS1 errors.  There probably will be some additions eventually.  For example, we don't presently check that OCLC or ISSN numbers are well formed, and that seems like a natural possibility.  Also things like laysource= without layurl=.  However, I think we've already hit all the big ones.  The stuff that is left generally concerns rare parameters, and so such errors would rarely be seen.  Also I would like to thank you DePiep for the work cleaning up these errors.  You've been doing a good job.  Dragons flight (talk) 21:57, 26 April 2013 (UTC)


 * Concur. Empty parameters are kind of a pain because they clutter up the edit window but they're essentially benign.


 * —Trappist the monk (talk) 22:04, 26 April 2013 (UTC)
 * Ttm you miss this: it adds a red error message to the page. No editor wants that. -DePiep (talk) 23:53, 26 April 2013 (UTC)
 * Thank you, Dragons flight, for your careful answer. Again. Not only do I learn how to do good scripts, I also learn how to exlain in text without getting angry. -DePiep (talk) 00:23, 27 April 2013 (UTC)


 * What?! Here is the skeleton of the most common parameters taken from plus an invalid parameter nosuchparameter which doesn't exist:




 * Nothing red there, ne? All of the empty parameters, including the nosuchparameter, are ignored as they should be.


 * —Trappist the monk (talk) 00:19, 27 April 2013 (UTC)
 * DF writes eloquent, here again, about core issues. Both in text and in code. Now what is your question? -DePiep (talk) 01:09, 27 April 2013 (UTC)


 * I do not have a question. You claimed that I had miss this: it adds a red error message to the page. My response: What?!, was an exclamation of surprise.  You know, and I showed again with my example, that empty parameters do not add a red error message to the page.


 * —Trappist the monk (talk) 02:17, 27 April 2013 (UTC)
 * Perhaps the intended example was closer to this?
 * This does, of course, throw the red message. LeadSongDog <small style="color:red; font-family:Papyrus">come howl! 14:48, 13 June 2013 (UTC)
 * This does, of course, throw the red message. LeadSongDog <small style="color:red; font-family:Papyrus">come howl! 14:48, 13 June 2013 (UTC)
 * This does, of course, throw the red message. LeadSongDog <small style="color:red; font-family:Papyrus">come howl! 14:48, 13 June 2013 (UTC)

layurl
In the recent update I added layurl as a synonym for laysummary. I'd actually like to suggest that WP:CS1 documentation be updated to use layurl as the recommended form. This is the only parameter name that is expected to contain a URL but which historically hasn't had "url" in its name. Hence I think the new alias is likely to be clearer to users and should be preferred. Dragons flight (talk) 19:04, 25 April 2013 (UTC)


 * Excellent! I think that I've got the documentation for layurl, none, and none fixed.


 * —Trappist the monk (talk) 00:46, 26 April 2013 (UTC)


 * Please stop forking the Lua templates to veer away from original parameters: The wp:CS1 cite templates have developed a set of specific parameters, over the years, which interact with various tools, various bots (including User:DASHBot), and are expected to be compatible with the related cite interfaces on the other-language wikipedias, such as the Simple English Wikipedia where editors are expecting text from enwiki. I just do not understand this obsession to forkify the parameter names, report thousands and tens of thousands of red-error messages where none have appeared before. -Wikid77 (talk) 05:40, 27 April 2013 (UTC)

safeforurl shouldn't check & escape category links
They works in link text. <span class="signature signature_2539476">Liangent (talk) 19:22, 26 April 2013 (UTC)
 * Specific issue please. --  Gadget850talk 19:37, 26 April 2013 (UTC)
 * . A wikitext link  can work as expected (add the page to category and generate an external link with text "Google"). <span class="signature signature_2539476">Liangent (talk) 19:55, 26 April 2013 (UTC)


 * Because this:


 * Category wikilink becomes part of WP:COinS.


 * And it's title. That's the parameter you're looking for.
 * —Trappist the monk (talk) 20:08, 26 April 2013 (UTC)


 * Sorry I meant to say title ("text" is not listed on cite web), and anyway this fails too:  = . <span class="signature signature_2539476">Liangent (talk) 20:22, 26 April 2013 (UTC)


 * CS1 has properly identified a malformed citation. Wikipedia categories aren't part of a referenced source's name and don't belong in title.


 * —Trappist the monk (talk) 20:42, 26 April 2013 (UTC)
 * This is just a simple example to demonstrate the technical problem. Let's see this: [//en.wikipedia.org/w/index.php?title=Sandbox&oldid=552329351], at the bottom. Wikitext is: . <span class="signature signature_2539476">Liangent (talk) 20:51, 26 April 2013 (UTC)


 * Your new example no different. The  template does not belong in title because the text that it adds,   does not belong in the COinS metadata and because that additional text was never part of the reference's title.  What you are demonstrating is not technical problem with CS1.  Just because you can create a wikilink that does what you want doesn't mean that CS1 should do the same.


 * —Trappist the monk (talk) 21:55, 26 April 2013 (UTC)
 * But that's another thing. I don't mean to add category links, but I want to tag my text as in Chinese (lang="zh" in HTML). It's also possible to fix lang to avoid adding category links in this case. As noted below this issue falls in Module talk:Citation/CS1/Feature requests. <span class="signature signature_2539476">Liangent (talk) 04:54, 27 April 2013 (UTC)


 * You don't mean to add category links yet all of your posts in this conversation (and its title) have been about adding category links. I agree with you that identifying the language used in citation titles should be done.  But right now, the tools to do it don't exist and the tools that work well elsewhere, don't work with CS1.  And yes, conversation about that belongs elsewhere.


 * —Trappist the monk (talk) 11:19, 27 April 2013 (UTC)


 * Including categories in URL links sometimes works, but there are also examples that fail unexpectedly, e.g.:


 * Google Website
 * Google Website
 * Google Website
 * Google Website


 * So, I'm not sure it is a great practice to recommend, since it may have unexpected results depending on how you place the category relative to the other elements. More significantly, we also have the issue that categories included in the title text get passed into the COinS metadata.  That's the issue that Trappist is trying to explain above, giving the example of rft.btitle=GoogleCategory%3AGoogle-cite which is the malformed side effect of using title=Google.  For the case on languages there is actually a dedicated field language that is preferred to note the language used.  It is not necessarily impossible that we could write code to handle categories as a special case to clean the problems with the title and metadata, though that might add confusion since   would then be allowed in a URL wrapped title but other kinds of wikilinks, e.g. , would not be allowed.  Personally, I tend to think that it makes more sense to move such categories outside of the citation, e.g.  , but I'm open to other options if the consensus favors something else.  Dragons flight (talk) 22:17, 26 April 2013 (UTC)
 * I have a feature request to properly format the title using the 'language' parameter. Since this would done inside the module, the language markup and category would not be injected into the metadata. --  Gadget850talk 23:04, 26 April 2013 (UTC)
 * This getting off-topic, but at the Feature Requests page, I previously asked if you could give some examples of what the markup should look like. Dragons flight (talk) 23:21, 26 April 2013 (UTC)

The various IDs
Anyone want to take the time to try and work up recommendations for how to validate the various IDs? At present, we support 18 ID types, but only do any validation on 3 of them. I believe that ISSN has a check digit, and I know several others are suppose to be strictly numeric, so those are examples of things we can verify. It would be nice to work up a set of validation goals for each case though. This is doubly true for some of the IDs I've never heard of prior to looking at citations (e.g. Zbl?!), as I'm not even sure where to find specifications for them. Dragons flight (talk) 23:17, 26 April 2013 (UTC)
 * Need to avoid wider oceans of red-error messages: I think we already have enough new error messages, in tens of thousands of pages, which will leave many articles scarred for years with trivial restrictions, such as cannot have an accessdate when accessing a webpage by doi or PMID or PMC or Bibcode ids. Plus, many of the new red-error messages have appeared in talk-pages, where posted messages are not supposed to be re-edited just because a modified template breaks where formerly, there had been no red-error messages displayed. Also, when the id-format rules change, then the Lua module will need to be updated to allow alternate ids, and then again, reformat all 2 million pages after changing the Lua module, again and again and again. Beware recent changes in id format; for example, from Zbl article "Zentralblatt MATH", it states: "The electronic form was provided under the name INKA-MATH (acronym for Information System Karlsruhe-Database on Mathematics) since at least 1980; the name was later to Zentralblatt MATH". Hence, today we have the "Zbl" id, but there might be another bout of renaming or changing the id-format rules. All these new error conditions are just creating trivial busy work where not present before. -Wikid77 (talk) 06:17, 27 April 2013 (UTC)
 * What is your alternative plan to fix broken ids in templates? Have we received a lot of complaints about error messages? --  Gadget850talk 11:13, 27 April 2013 (UTC)
 * Editors at PUMPTECH have already complained about red-errors: The general comment, made a week earlier at wp:PUMPTECH, was that the red-error messages are highlighting issues previously left in cites for years, and hence useless busywork. So, I had replied that we are showing the messages, now, to count the impacts, and then we might put small superscript "[fix cite] " as a subtle reminder that a trivial error was detected and auto-corrected. Part of the impact is to consider if the errors are totally trivial, as suspected by the general comment. -Wikid77 (talk) 21:20, 28 April 2013 (UTC)
 * A quick search found format descriptions for these ID:
 * ASIN
 * http://arxiv.org/help/arxiv_identifier
 * Bibcode
 * Bibcode
 * ISSN
 * LCCN


 * —Trappist the monk (talk) 12:54, 27 April 2013 (UTC)

Red-errors scarring medical articles
Well, it has been over 2 weeks since the Lua red-error messages were activated for all users, and over 95% of the red-error articles have not been "fixed" to appear "red-free". Part of the problem is errors inside double-nested cite templates, such as inside the Template:Cite_doi knowledgebase of 9,000(?) double-nested cites. For example, major article "Bacillus" has retained 3 trivial red-error messages for those 2 weeks, because it shows errors from 3 {cite_doi} cites (which cannot be fixed by editing "Bacillus"):
 * Parameters:
 * Result:

Those trivial errors must be fixed by editing each of the 3 {cite_doi} subtemplates, named as "Template:Cite doi/10....". Consider each:
 * Parameters:
 * Result:
 * Parameters:
 * Result:
 * Template:Cite doi/10.1016.2FJ.Syapm.2008.07.001 - redirects to lowercase cite.
 * Template:Cite doi/10.1016.2Fj.syapm.2008.07.001 - complained about "displayauthors=".
 * Template:Cite doi/10.1016.2Fj.syapm.2010.08.001 - contains the parameter "1=20817437" which could just be shown after postscript, as ". 20817437" and really, who cares?
 * Template:Cite doi/10.1186.2F1471-2164-11-332 - The doi number was repeated, incorrectly, as an ISBN perhaps because it contains 13 digits; however, the doi number is sufficient for the web-link and the incorrect ISBN could be ignored, not red-flagged for months or years.

In all 3 cases, the red-error message had scarred the text for extremely trivial issues, where the id numbers needed to link the cite were, in fact, precisely correct, and the red-error text is grandstanding over minor errors which should be ignored, as suspected by the general comment, made at wp:PUMPTECH, how the Lua cite templates are creating unneeded busywork. There is no need for red-error scarring of major medical article "Bacillus" which is viewed over 1,000 times per day. Over 11,500 pages use the {cite_doi} double-nested cites. -Wikid77 (talk) 21:20, 28 April 2013 (UTC)


 * It was Editor GoingBatty in this conversation and the direct quote is: In this case, the new template is pointing out errors that were previously not visible to the reader, and therefore not significant enough to fix. Are we just creating busywork for editors by highlighting these issues to readers? That's it, the whole enchilada. Hardly a statement of condemnation.  Convincing evidence of a groundswell of opposition to the red-error menace has yet to arise, despite claims of red-error grandstanding and scarring.


 * errors are a pain to fix. Last time I tried,, citationbot zoomed in seconds after my edit was saved and reverted me.  Robots should never do that.


 * —Trappist the monk (talk) 01:10, 29 April 2013 (UTC)
 * Revert and it will stay out of that page. -DePiep (talk) 01:17, 29 April 2013 (UTC)
 * (Slightly OT) The citation bot can do some pretty weird reversions.  I tagged a malformed template for speedy deletion and the bot reverted it, twice .  Used a seemingly benign edit summary:  ([423]Misc citation tidying. User-activated.) Regards, Illia Connell (talk) 03:34, 29 April 2013 (UTC)


 * To continue with the slightly OT part of this conversation. Apparently a simple revert isn't sufficient.  Editor Gadget850 tried that and just as quickly as it happened to me, was reverted by citation bot.  The solution turned out to be ; a solution that I'm not really sure I'm comfortable with.  There are perfectly legitimate reasons to send bots out to do the menial labor; blocking them means that human editors need to do the labor.  I have change  to . The correct solution is for citation bot to get with the program.


 * —Trappist the monk (talk) 12:38, 29 April 2013 (UTC)

"et al." twice
I have not kept the diffs, but I remember seeing and editing out things like this: In general it arises when: "et al." is written in author1 and author2 has text. Errorizable? -DePiep (talk) 11:46, 27 April 2013 (UTC)


 * I'm sure it could be, but should it? Certainly Dopey et al. is not last1's surname so the COinS metadata are corrupted. Does this condition occur often enough to worry about? Are there similar cases of parameter values that contain clearly identifiable inappropriate text?


 * —Trappist the monk (talk) 11:55, 27 April 2013 (UTC)
 * I think I've met it some three two times in ~150-200 citations I corrected this week.
 * OTOH, it would be a content correction (even if it improves COinS quality), not a template technical one as the current errormessages are. Maybe something for a bot? -DePiep (talk) 13:10, 27 April 2013 (UTC)

A similar related but different situation exists when all authors are listed in one parameter: Dopey, Grumpy, Sneezy et al.. I have seen and edited some of these. Now the "et al." is not the issue, but the semantic incorrectness (parameter meaning corrupted e.g., for COinS).

-DePiep (talk) 21:47, 27 April 2013 (UTC)
 * example: []
 * I think, now, that we should leave it to a bot, not the (Lua) module. CS1 should not do content checks (for now). -DePiep (talk) 22:52, 27 April 2013 (UTC)


 * CS1 does content checking now for some of those parameters that have strictly defined uses: doi, isbn, ol, url. date and year should be added to that list – but that's another topic.


 * I'm not sure that automated processes that actually change content is a good idea. I'd rather leave that to thinking brains.


 * —Trappist the monk (talk) 12:04, 28 April 2013 (UTC)

Discussion regarding the usage and cleaning of accessdate
I've started a wider community discussion at Village pump (policy) about the appropriate usage of the accessdate parameter and what steps (if any) should be taken to clean it up. I invite your comments at that page. Dragons flight (talk) 03:57, 29 April 2013 (UTC)

Discrepancy in error messages for Pages using citations with old-style implicit et al.
I've noticed that pages in can show either  suggested (help)  or Citation uses old-style implicit et al. for authors, I think that it's namespace-dependent, since I've seen the first style on many article pages, and the second one on several template pages. The problem is exactly the same - nine authors, but no displayauthors - so why do the messages differ? -- Red rose64 (talk) 11:17, 30 April 2013 (UTC)


 * Older version (not red text) in the cache? Both of your examples look the same to me (red).  Purge?


 * —Trappist the monk (talk) 11:25, 30 April 2013 (UTC)
 * Could be; I just found another instance of Citation uses old-style implicit et al. for authors (which was definitely red) and did a WP:PURGE and it changed to the first form. It was a page that I'd not visited in over six months, therefore local caching is not the cause. -- Red rose64 (talk) 11:56, 30 April 2013 (UTC)
 * OK, I've worked out why Citation uses old-style implicit et al. for authors shows red for me but black for you. It's as advised . If I, it turns black. -- Red rose64 (talk) 16:11, 30 April 2013 (UTC)


 * I'm confused. I did not see an old style error message in either of the examples in your first post. I wasn't clear in what I meant when I said that they both look the same.  What I meant was that I saw current red error messages in both examples.


 * You listed two different error messages for the same type of error:
 * suggested (help)
 * Citation uses old-style implicit et al. for authors


 * As far as I know, these two messages were never coexistent in a single version of CS1. CS1 either produced one error message or the other.  The red one above is the current message.  This is why I suggested an old copy in the cache – I should have been more clear that it isn't a local cache but a wiki server cache.  As I understand it from some conversation somewhere, there are multiple caches so perhaps you got an old copy from a server that is different from the server that is showing me current red error messages.


 * My common.css file has this line in it and I see red.


 * .citation-comment {display: inline !important;}


 * —Trappist the monk (talk) 16:52, 30 April 2013 (UTC)

for your consideration:
should/will some of the functionality in this template appear in the module? 70.19.122.39 (talk) 01:00, 3 May 2013 (UTC)


 * CS1 already supports subscription required and language support is one of the items listed at Module talk:Citation/CS1/Feature requests. What of those listed features do you think CS1 should support and why?


 * —Trappist the monk (talk) 01:35, 3 May 2013 (UTC)


 * i was not aware that "subscription required" was already supported. i think there is a case to be made that registration and/or login requirements should be explicit: it is not just good protocol, some users may consider them a burden to verification, a privacy nuisance, or technically undesirable (if they involve modifying cookie/scripting settings at their browser). also consider "plugin" and "requires" as described in the template doc. if i remember correctly, one of the (many) early uses of format was to flag plugin requirements. 70.19.122.39 (talk) 14:29, 3 May 2013 (UTC)

authorformat = vanc
In order to generate the "Vancouver-like" style, in addition to setting "authorformat = vanc", one also needs to add author-separator and author-name-separator parameters : This syntax seems unnecessarily verbose. In my opinion, if "authorformat = vanc" is specified, then author-separator and author-name-separator should also be automatically set as above without having to explicitly include these two parameters. Thoughts? Boghog (talk) 18:01, 4 May 2013 (UTC)


 * Hmm, so in this first case just vanc:


 * And here per Editor Boghog:


 * According to the authors documentation at, semicolon-separated author given-names aren't converted to initials and where initials are used, each is followed by a period. Seems that CS1 is doing a blend of both  styles.  Is there a more authoritative description of Vancouver-like style than ?


 * —Trappist the monk (talk) 18:26, 4 May 2013 (UTC)


 * Thanks for providing the examples Trappist the monk. The vcite documentation cites Template:Vcite_book which is more authoritative and specifies a single author format. In particular, there is no delimiter character between the last and first names and authors are separated by commas instead of semicolons. See also the examples in Vancouver system.  Hence while vcite may be a blend, the Vancouver system itself as defined by the NCBI specifies a single author format.  Boghog (talk) 19:31, 4 May 2013 (UTC)
 * vcite is a typing aid and should not be escaped. vcite → . See Help:Citation tools for more.
 * If the intent is to truly use the Vancouver system, then separate templates should be used. has a series of templates, but is little used. The developer and proponent is no longer active. --   Gadget850talk 13:32, 5 May 2013 (UTC)
 * The intent is to provide flexibility to the cite doi and cite pmid templates that in turn use the CS1 template. What I think is needed is a single pass-through authorformat parameter that would allow the cite doi template to display the citation in a Vancouver style. (see this discussion and especally this discussion). Boghog (talk) 14:00, 5 May 2013 (UTC)
 * I still don't understand the underlying intent or use. Do you mean to create articles using the Vancouver style? The intent of 'authorformat' in the CS1 templates is not to implement the Vancouver style, but to allow editors to show initials only for journals.
 * To implement what you desire, add something like this to the template:
 * --  Gadget850talk 19:35, 5 May 2013 (UTC)
 * The problem as discussed here is that inflexible cite doi templates are being added to articles that already have a pre-established Vancouver style. According to WP:CITEVAR, the previous citation style should be respected unless there is consensus to change it. What is needed is a more flexible cite doi template that supports alternative citation styles like Vancouver.   "authorformat = vanc"  is a partial implementation of the Vancouver style.  In the vast majority of cases, if one specifies "authorformat = vanc", one would also very likely specify "  ".  In my opinion, there should be an option to enable a Vancouver style citation by setting a single parameter.  This can be handled either in the CS1 template or as you suggest, in the cite doi and cite pmid templates.  My preference would be the former since only one template would require modification.  The later solution would require changes to at least two templates and therefore would be harder to maintain.  Boghog (talk) 20:00, 5 May 2013 (UTC)
 * Vancouver style is more than just the elements you have noted. For example, titles are plain, without quotes or italics. Vancouver style (formally Uniform Requirements for Manuscripts Submitted to Biomedical Journals) may not be the best choice for Wikipedia as it seems a niche format, but I am sure it has its proponents. Regardless, if the article is truly using the Vancouver format, it should be so noted. We have the templates for this. --   Gadget850talk 21:45, 5 May 2013 (UTC)
 * Vancouver style is more than just the elements you have noted. For example, titles are plain, without quotes or italics. Vancouver style (formally Uniform Requirements for Manuscripts Submitted to Biomedical Journals) may not be the best choice for Wikipedia as it seems a niche format, but I am sure it has its proponents. Regardless, if the article is truly using the Vancouver format, it should be so noted. We have the templates for this. --   Gadget850talk 21:45, 5 May 2013 (UTC)

A variant of the Vancouver style (produced by User:Diberri's Wikipedia template filling tool) is widely used in the WP:MED and WP:MCB projects. This variant only modifies the display of the author list and uses the default display of journals produced by cite journal. Furthermore the use of Diberri's tool is mentioned (but not required) in MEDMOS and MCBMOS. Using the vcite journal template does not solve the problem of incompatibilities between cite doi and citations generated by Diberri's tool and in fact would introduce a new incompatibility. Furthermore the use of citations generated by Diberri's tool far exceeds that of vcite journal.

The primary motivation for vcite template was to reduce page load times. The new cite journal that is based on CS1 is far more efficient, hence there is now much less need for the vcite templates. Also as you have already pointed out above, vcite templates are no longer being maintained.

To reiterate, the "authorformat = vanc" is only a partial implementation of the Vancouver style for the display of the author names as it only converts first names to initials. Hence the syntax of "authorformat = vanc" as it is currently implemented is misleading. Logically if "authorformat = vanc" is set, it should also apply the Vancouver convention to the punctuation used within (no comma) and between authors (comma). Boghog (talk) 05:07, 6 May 2013 (UTC)
 * Technical issue: If the cite doi subtemplates don't have the 'authorformat' parameter, then they can't pass it to the CS1 module. You have to update every subtemplate to support it.
 * If these articles are going to use a distinct citation style, then it needs to be defined. We need a name (Citation Style Med?) and a specification (see ). We can then create a 'style' parameter that would enable that style. You could then use something like ; this would apply to other cite templates used in the article. --   Gadget850talk 11:13, 6 May 2013 (UTC)


 * Vcite templates are fast for Vancouver style, only CS1 needs Lua: The {vcite_*} templates have been kept separate to simplify the plans to use Module:Citation/CS1, and focus on improvements for that style. The problems with the {cite_doi} templates can be fixed by passing the vcite (or other CS1) cite-template name into {cite_doi} to then pass to each subtemplate {cite_doi/10*...}. Otherwise, just copy the parameters from a specific {cite_doi} to make a {vcite_*} citation with those parameters. There is no need to further complicate the wp:CS1 citations to support Vancouver style. In cases where it seems too much work to handle the {cite_doi} citations, then just get consensus on the talk-page to convert each whole article to use wp:CS1 format, rather than Vancouver style. -Wikid77 (talk) 20:23, 9 May 2013 (UTC)
 * As noted, the style is not true Vancouver, but a hybrid. I don't see an issue with setting variant styles, but they need to be speced and documented before implementation. We are using this module for CS1 and CS2. Why not CS3? --  Gadget850talk 22:21, 9 May 2013 (UTC)
 * The Diberri template filler obtains author data formatted in Vancouver style from the National Library of Medicine's (NLM) PubMed. The following in turn is the most complete documentation for the NLM Vancouver author format that I have been able to find:
 * Is this sufficient documentation for the specification? Please also note that the combination of "  " will get very close to the Vancouver author style as defined by the NLM. Boghog (talk) 14:40, 2 June 2013 (UTC)
 * How would you want to implement this? Separate template? A style parameter? --  Gadget850talk 15:16, 2 June 2013 (UTC)
 * A parameter option (e.g., "authorformat = NLM") which in turn sets " " would be sufficient. Boghog (talk) 15:37, 2 June 2013 (UTC)
 * A parameter option (e.g., "authorformat = NLM") which in turn sets " " would be sufficient. Boghog (talk) 15:37, 2 June 2013 (UTC)

Dead link when deadurl=yes and archiveurl is not specified
Shouldn't we show dead link in this case? Also this must be so according to RfC --DixonD (talk) 19:26, 12 May 2013 (UTC)


 * Looking at the RfC, I guess that yes was supposed to do something, but it was never implemented or documented. The only check implemented is for no where it swaps the display of 'url' and 'archiveurl'. --  Gadget850talk 21:01, 12 May 2013 (UTC)
 * Let's implement it now then. I mean the part of RfC labeled as "Dead link simplification and moving closer to the url" --DixonD (talk) 21:07, 12 May 2013 (UTC)

Sandbox changes: via and subscription parameters
The via and subscription parameters act somewhat like the template. But only somewhat. In Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox I have made changes that, I think, make these parameters more closely reflect the operation of.

Conceptually, via and subscription in CS1 citations can be considered as more-or-less one-way synonyms in that they both refer to material that requires a subscription. The difference is that via identifies a source whereas subscription does not. This means that only one of the two parameters is needed to identify the citation as one that requires subscription. So, I modified the via handler to force the output of (subscription required).

adds one of two categories, one for instances where via is not specified (Category:Pages containing links to subscription-only content), and one one where via is specified (Category:Subscription required using via). I have added these categories.

The last thing I changed was the &amp;mdash; to &amp;ndash; to be consistent with and MOS:DASH.

If both via and subscription are included in a citation, subscription is ignored. This condition should probably emit a redundant parameter error.

—Trappist the monk (talk) 00:10, 13 May 2013 (UTC)


 * cool, thanx. minor points about the presentation:
 * i suggest "Journal Title (via Journal Subscription Service – subscription required)" with the parenthetical info greyed perhaps. that way the dash is not introduced to the module as yet another fixed punctuation mark (along with the ampersand + the colons), but is conditional to via.
 * for consistency (and context) there should not be punctuation between the parenthesis and the related field (i think this is the module norm with other data in parentheses).
 * 70.19.122.39 (talk) 13:26, 14 May 2013 (UTC)

These parameters should be added to the CS1 documentation. Though they have been part of the Module since before I got here, most of the template documentation pages still direct users to use subscription required, if anything is said at all. Dragons flight (talk) 23:58, 21 May 2013 (UTC)

year
Would it be possible (and useful) to check that the value of the  is numeric, and, if it is numeric, that it is less than or equal to the value of  ? (Possibly the two character strings  and    code be exceptions). Regards, Illia Connell (talk) 04:27, 13 May 2013 (UTC)
 * This would not be useful, because there are valid uses for a non-numeric year, such as when an article using references two different works by the same author published in the same year. See for example the Cooke refs, also the Beeching refs, in Reading Southern railway station. -- Red rose64 (talk) 10:23, 13 May 2013 (UTC)
 * Right! I'm learning something new all the time.  Regards, Illia Connell (talk) 02:30, 14 May 2013 (UTC)
 * Although we still might be able to have error reporting if the numeric start of the year value isn't a valid year < current year. <b style="color:darkgreen">Rjwilmsi</b> 08:22, 14 May 2013 (UTC)

extracting year from date when 0
does not work.

1. citations

2. citation links

the harvard citation link "E" does not work (0). however a visually blank does (harvard citation link "C" above). recommendation: set "author-mask= " behavior as the default.

70.19.122.39 (talk) 14:48, 15 May 2013 (UTC)
 * The anchor is just "CITEREF2004", so it looks like 0 prevents 'author' from being inserted into the anchor. And I really don't want to know where or why you are using something this oddball. --  Gadget850talk 15:29, 15 May 2013 (UTC)
 * that's the wrong question. the right answer is, "parameters should not assume unexpected strange dependencies. thanks for pointing out a bug". 70.19.122.39 (talk) 16:03, 15 May 2013 (UTC)
 * The year is being extracted from the date just fine. What is happening is a failure to place the author into the anchor. Before we had Lua, the display-authors parameter ( in ) was ignored when constructing an anchor for harv. -- Red rose64 (talk) 17:41, 15 May 2013 (UTC)
 * The pre-Lua versions did not support 0. --  Gadget850talk 18:09, 15 May 2013 (UTC)
 * I didn't intend to imply that they did. What I was saying is that pre-Lua versions ignored display-authors, no matter what its value, when constructing anchors. -- Red rose64 (talk) 19:17, 15 May 2013 (UTC)
 * I agree with 70.19.122.39: this is a bug, the author should still be in the anchor even if it is not displayed, and we should thank 70.19.122.39 for reporting it. —David Eppstein (talk) 18:12, 15 May 2013 (UTC)
 * Yes, this is a bug and needs to be fixed. This behavior 0 was not supported by the older templates, thus this usage is new. And novel. --  Gadget850talk 19:58, 15 May 2013 (UTC)

This should be fixed in the sandbox. Dragons flight (talk) 00:07, 19 May 2013 (UTC)

--  Gadget850talk 11:26, 22 May 2013 (UTC)

A bit of time
These last several weeks I needed to cut back my wiki involvement in order to deal with issues in real life. It seems like I will probably have a bit more time in the near future. Obviously there are several yet to be resolved issues with this module, and with the overall migration. If anyone wants to make some suggestions about which issues to look at first, then I'm happy to take that into consideration as I decide how to prioritize the time I do have. Dragons flight (talk) 23:56, 18 May 2013 (UTC)

Cite Template feature prompting incorrect entry of date, month, year parameters
There is an issue with the "Cite Templates" feature in the editing window, which I have previously raised here and here concerning the date, month and year fields. Refer to this screenshot which produces the following code:

""

I thought that, since there were separate fields for date, month and year, each element (day, month, year) was required to be entered separately in this way, and I'm not the only one. This doesn't produce an error; it simply means that only the day (1) instead of the whole date (1 April 2013) is included in the reference at the end of the article. This detail may be overlooked because the editor either doesn't see it or doesn't recognise that the single number is actually meant to be a date.

The result is that there may be many faulty refs out there with this error. They might all fail when the  parameter is deprecated and returns an error, but it would be good:


 * to get a bot out there to fix all those broken template refs; and
 * to fix the "Cite Templates" feature to remove the month field and rename the year field as appropriate (e.g., "year (when full date unknown)" or "year (Harvard referencing only)").

Help! —sroc (talk) 12:18, 21 May 2013 (UTC)


 * I was training a new user, who attempted to use those parameters in the manner described, just last week, using (what I call ) the toolbar wizard. The problem will recur until the documentation is changed, an error message is thrown, or the parameters renamed. We should fix that, before we fix individual instances. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 13:46, 21 May 2013 (UTC)
 * That is the RefToolbar. The creator of RefToolbar is no longer active, and it has been slowly reverse engineered to figure out how it works. I did figure out how to change the tooltips; if you have specific suggestions, please leave them on the talk there. There is a feature request to validate the date. --  Gadget850talk 15:39, 21 May 2013 (UTC)
 * The date parameter was never intended to hold the day-of-month alone. There was a short period of about eight weeks in late 2008-early 2009, when we encouraged the use of separate day month year parameters in conjunction with dateformat. -- Red rose64 (talk) 17:02, 21 May 2013 (UTC)
 * Redrose64, yes, I understand that now, but the RefToolbar wizard doesn't make the correct usage clear which has presumably resulted in countless errors littered throughout Wikipedia over time. Many editors use the toolbar without consulting the handbook on proper use of the templates.
 * Andy Mabbett, is there any reason we should leave obvious errors and wait for them to fail disgracefully before fixing them? The error is out there already; it will only become more obvious once the template returns errors.  If we can fix the problems now, before they become more obvious, then we should.  I don't know much about bots, but surely they can be programmed to do something like this:
 * Search for all templates in article namespace
 * Find:
 * Replace:
 * Then run the bot again once the documentation is updated to catch any later instances. —sroc (talk) 02:07, 22 May 2013 (UTC)
 * We should fix the cause and the effects, soon. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 10:31, 22 May 2013 (UTC)
 * I can look at fixing affected articles. Do any of the existing 'articles with citation syntax errors' categories pick up this error? <b style="color:darkgreen">Rjwilmsi</b> 13:10, 23 May 2013 (UTC)

Cite sign
Cite sign can readily be updated, as it is essentially a clone of Cite AV media. I had updated it in an attempt to merge the former into the latter, but it failed in discussion.

COinS spec
I started Module talk:Citation/CS1/COinS as a specification. --  Gadget850talk 02:43, 4 June 2013 (UTC)

Archiving
Has User:MiszaBot forgotten this talkpage? Seems it's getting overdue. LeadSongDog <small style="color:red; font-family:Papyrus">come howl! 15:50, 13 June 2013 (UTC)
 * I don't think it's forgotten - I think it's unaware. Although Pigsonthewing automatic archiving on 22 March, it's never actually been actioned. There are three archiving bots in the MiszaBot family, each operates on a different selection of namespaces, and none of them operate on Module talk: space (see contribs for [//en.wikipedia.org/w/index.php?title=Special%3AContributions&target=MiszaBot+I&namespace=829 MiszaBot I]; [//en.wikipedia.org/w/index.php?title=Special%3AContributions&target=MiszaBot+II&namespace=829 MiszaBot II]; [//en.wikipedia.org/w/index.php?title=Special%3AContributions&target=MiszaBot+III&namespace=829 MiszaBot III] - all are empty). This namespace was only created in the last few months (I think February 2013), and  hasn't made many edits since October 2012. -- Red rose64 (talk) 16:21, 13 June 2013 (UTC)
 * Did archive the top threads that ended in March 2013 manually dindex.php?title=Module_talk:Citation/CS1/Archive_6&diff=560351896&oldid=552631249 -DePiep (talk) 21:09, 17 June 2013 (UTC)
 * And those ending April 2013: -DePiep (talk) 21:28, 17 June 2013 (UTC)

RFC: Consistent date location in citation templates
Please see Help talk:Citation Style 1 where I ask if the location of the date in the most popular citation templates should always be consistent. At present, the date is immediately after the authors if authors are given in the citation, but near the end if not. Jc3s5h (talk) 18:54, 13 June 2013 (UTC)

RFC: Consistent date location in citation templates EXPIRED
This RFC has expired and appears to have more or less reached consensus. Developers might feel the discussion is clear enough to begin implementation, or might want to wait for an editor to close the discussion. Jc3s5h (talk) 12:55, 13 July 2013 (UTC)

Possible bug in safejoin
I think there is a possible hidden bug in, when one of the element of the array is   in the code:

the check on  values will never be executed as the loop will stop at the last not   value, the successive elements will be silently ignored.

Try for example the following code: the result will be "ab" not "abc". --Moroboshi (talk) 06:48, 22 June 2013 (UTC)


 * I'm about 99% certain there is no way for a user to input a citation that would result in an explicit nil being sent to safejoin. The argument_wrapper converts all nil input to empty strings.  The check you highlight in safejoin would then be unnecessary since nil input can never be present.  So a bit of superfluous code rather than a bug.  (In earlier versions of the code there were a lot of nils floating around, but most of them were removed.)  Dragons flight (talk) 08:26, 22 June 2013 (UTC)

ignore-isbn-error
As 'ignore-isbn-error' is becoming more used (see for example) we should add a tracking category.

Is it possible to put categories into a separate config file? --  Gadget850talk 11:31, 29 June 2013 (UTC)


 * Any suggestion on what to call such a category. A search on "ignore-isbn-error" (with quotes) suggests that about 30 pages use it.  Dragons flight (talk) 18:05, 29 June 2013 (UTC)
 * Category:Pages with ignored ISBN errors, a subcat of Category:Pages with ISBN errors. --  Gadget850talk 18:15, 29 June 2013 (UTC)

Typographical quotes
Some parts of the template wrap titles in quotes. Right now it uses ASCII (straight) quotes. Is there a reason why typographical (curly) quotes are not used for this purpose?

I’ve modified Module:Citation/CS1/Configuration/sandbox to use “curly” quotes; it seems Module_talk:Citation/CS1/testcases uses that, and as far as I can tell it works correctly. (Though of course the tests fail because they expect straight quotes.)

I’m not at all comfortable editing templates, especially one so often used like this, so perhaps someone else should apply the change? — bogdanb (talk) 09:44, 13 July 2013 (UTC)
 * Yes, there is a reason, see MOS:QUOTEMARKS, the part headed "Quotation characters". -- Red rose64 (talk) 10:00, 13 July 2013 (UTC)

Transcript parameter
Maybe I'm wrong but  parameter is never assigned to the citation returned by the module. It is last used on rows 1379-1383 (to assign ) but I cannot find any row where it's assigned to text of the citation.--Moroboshi (talk) 06:40, 21 July 2013 (UTC)
 * 'transcript' is used by cite episode and cite serial which have not yet been updated. --  Gadget850talk 14:43, 21 July 2013 (UTC)

Separator parameter bug
The documentation specifies   when an editor desires to change the separator to a space with separator. That works to a point. The problem is that the value specified in separator is also tacked onto the last parameter in the citation.

Well mostly. Here separator is assigned the value. But, at the end of the citation, only  is output.



For two-byte characters, endash in this example, one byte of the character-pair is deleted:



Whatever mechanism is removing the last character from the separator value appears to be the wrong mechanism. Instead, separator should not follow the last parameter in the citation.

—Trappist the monk (talk) 13:44, 21 July 2013 (UTC)

Open Library: Internet Archive
The Open Library has identifiers for pages archived from the Internet Archive. Specifications: --  Gadget850talk 10:31, 24 July 2013 (UTC)
 * The id begins with:
 * The URL is

Positioning of |format= parameter
→

In this citation, the format element parameter is placed after the title element which is misleading because in this case, the title element is not a pdf document. Similarly, the chapter element, which is a pdf document, is not suffixed with the format element. Understood that when and if the pdf icon ever gets alt text this will cease to be an issue (for pdf documents). Until then, the format element should follow the leftmost linked item in the rendered citation.

—Trappist the monk (talk) 16:30, 24 July 2013 (UTC)

Chapter/title
Something wrong here:

--  Gadget850talk 13:22, 3 August 2013 (UTC)
 * Yesss... pre-Lua doesn't recognise work, perhaps because it's a direct equivalent to title -- Red rose64 (talk) 14:45, 3 August 2013 (UTC)

HTML classes
Are we in a position, yet, to start adding HTML classes to elements wrapping parameter values, in order to enhance the machine-readability of citations? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 13:45, 3 August 2013 (UTC)
 * What is the class for 'chapter', 'episode' or 'isbn'? What tools are reading these classes? --  Gadget850talk 19:01, 3 August 2013 (UTC)
 * I addressed that at Module talk:Citation/CS1/Archive 4 and at WikiProject Microformats/citation to which the former links; and which I started at your request in March. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 20:58, 3 August 2013 (UTC)
 * Did you see my reply? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 20:53, 26 August 2013 (UTC)

Authorlink and terminal punctuation bug


When a citation contains authorlink and first is terminated with a period (full stop), a second period is added to the rendered citation.

—Trappist the monk (talk) 12:32, 6 August 2013 (UTC)

HTML entities not parsed in COinS
Any HTML entity is currently rendered without parsing in the COinS metadata:

--  Gadget850talk 15:20, 7 August 2013 (UTC)

doix support
When manually created, templates in the Template:Cite doi/ space (e.g. Template:Cite doi/10.1038.2Fnature09068) urlencode the doi to a parameter called doix using. The doix parameter will eventually be converted to a doi by User:Citation bot. In the meantime, the (encoded) doi is not displayed in the output, because the doix parameter is ignored. Is LUA capable of replacing url-encoded entities in a doix parameter with their url-decoded equivalents (i.e. .2F → /) and displaying this to the user until the bot tidies up the parameter?

Thanks, Martin  (Smith609 – Talk)  08:59, 17 August 2013 (UTC)

'doix' has never been a supported parameter. Is this already supported by Citation Bot? How should 'doix' be displayed? --  Gadget850talk 11:21, 31 August 2013 (UTC)
 * The url-decoded version of the doix value would ideally be presented in the same way as a doi. Of course, once the bot replaces it as Martin describes above, the doix value and parameter both disappear and would no longer be of value to the reader.LeadSongDog <small style="color:red; font-family:Papyrus">come howl! 22:16, 3 September 2013 (UTC)

Proposed release schedule for revealing errors (revisited)
This is the schedule from Archive 6#Proposed release schedule for revealing errors slightly modified to add release dates.

I see no sense in waiting any longer for the third group so I have edited Module:Citation/CS1/Configuration/sandbox to enable these last error messages:


 * accessdate requires url
 * Missing or empty url
 * format requires url
 * displayauthors suggested
 * displayeditors suggested

Admin assistance needed to make the sandbox live please.

—Trappist the monk (talk) 17:08, 26 August 2013 (UTC)


 * Looks good. I want to review the other changes, then I will make the update in a while. --  Gadget850talk 19:10, 26 August 2013 (UTC)

✅ Need to update the help page.


 * Saw that you added section and sectionurl. I've added sectionurl to Module:Citation/CS1/Whitelist/sandbox which will also need to be synched for those parameters to work correctly.


 * —Trappist the monk (talk) 19:43, 26 August 2013 (UTC)

✅


 * Also, there doesn't seem to be any support for sectionurl in Module:Citation/CS1 though there does appear to be support for section.


 * Module:Citation/CS1 will also need to be synched to Module:Citation/CS1/sandbox before registration can work. Make sure that you change these two lines:


 * to


 * —Trappist the monk (talk) 20:14, 26 August 2013 (UTC)

✅


 * Saw that you added section and sectionurl. I've added sectionurl to Module:Citation/CS1/Whitelist/sandbox which will also need to be synched for those parameters to work correctly.


 * —Trappist the monk (talk) 19:43, 26 August 2013 (UTC)

✅ --  Gadget850talk 20:43, 26 August 2013 (UTC)

ORCID
Back in May, we discussed adding an ORCID parameter (or parameters, for each contributor). The idea, AIUI, was parked then, so that lua conversion and error notification could be the priority. Can we do that, now? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 20:57, 26 August 2013 (UTC)


 * My concern with ORCID (Open Researcher and Contributor ID) is that the parameter does not deal with the work being cited but with a tangential piece of information, namely an identifier for the author of the work. This naturally leads the the slippery slope argument of how many other tangential data points to include (e.g. a Dewey Decimal, Universal Decimal, or Library of Congress number would be useful for locating works dealing with the same or related subjects as the cited work while a list of other newspapers that printed the same wire service story would assist readers in locating a newspaper article when the originally cited source is not conveniently available).  It should also be noted that Authority control, a template commonly used to provide information about an author, already supports ORCID. --Allen3 talk 21:23, 26 August 2013 (UTC)
 * I agree with all of this, and would add that I don't see why we should privilege ORCID over VIAF and the other identifiers used in Authority control. And we certainly don't want to include all of them: imagine the mess created by having half a dozen different identifiers each for half a dozen different authors of a work. —David Eppstein (talk) 22:49, 26 August 2013 (UTC)
 * That need not be an issue. Firstly, the barrier to entry for a contributor to get an ORCID is much lower than for VIAF, so in time more will have them. Also, unlike VIAF, ORCID records are managed by the subject or their agent. Secondly, we could add both (or other) parameters, and only publish one if two (or more) are present. Finally, once we have any one of the Authority Control identifiers, Wikidata will provide a lookup for the rest, no need for us to include them. Indeed, one day - but not yet - we might switch to just including the Wikidata identifier.  Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 23:10, 26 August 2013 (UTC)
 * Barrier to entry is not the only factor governing coverage. The barrier to entry to getting an account as a Wikipedia editor is low, possibly lower than to joining Facebook, and yet there are many fewer Wikipedia editors than Facebook members. Do you have statistics on how many people currently have ORCIDs vs how many people have VIAFs, and on how those numbers are changing? The numbers I can see in the category sizes in Category:Wikipedia articles with authority control information look very unpromising for ORCID. But maybe they don't tell the whole story? —David Eppstein (talk) 00:47, 27 August 2013 (UTC)
 * There are, of course, currently far fewer people with ORCIDs than VIAFs, but of course ORCID is new. The growth curve is what matters, and its impressive, as are the names and numbers of publishing houses universities, and others that are taking ORCID onboard. Our category numbers are low, for now, because we have done little to gather and enter the data into Wikipedia - but that's in hand. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 09:22, 27 August 2013 (UTC)
 * Ok, then, I believe at this point WP:TOOSOON and WP:SOAPBOX apply to your proposal. —David Eppstein (talk) 15:45, 27 August 2013 (UTC)
 * I don't believe either apply; but I draw your attention to my post below (currently the last on this page) time-stamped 10:22, 27 August 2013 (UTC). Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 19:25, 27 August 2013 (UTC)
 * Last point first: Yes, supports ORCID, but that's for article subjects (or Wikipedia editors). The proposal is to add the parameter for cited contributors (authors, editors, illustrators etc.) who are not article subjects. This will, as the parameter is populated over time, allow us to do several things: i) see all the articles in which a given contributor is cited ii) disambiguate different contributors with the same name iii) identify citations for a single contributor, under different names (spellings, Anglicisations, initials vs full name; married names, etc) iv) allow readers to click on an ISBN style link, and see all the authors' works, at their local library or wherever. This offers far more richness than the other identifiers which you mention. There is also interest from those in the Wikidata team to whom I have spoken, in adding entries for cited contributors, even if they are not article subjects. In future, therefore, it should be possible to draw citation data from that central repository through an editing tool. But first we must take some baby steps... [Disclosure: I volunteer on ORCID's works metadata working group, drafting a specification for their data standards]  Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:58, 26 August 2013 (UTC)
 * It seems to me that the functionality you propose will necessitate one of (1) eliminating wikilinks from authors to the Wikipedia articles about them, (2) only allowing this functionality for authors who do not have Wikipedia articles, or (3) cluttering up the references with lots of silly ID numbers instead of just placing a link on the author's name. All of these outcomes seem undesirable to me. Additionally, since the only documentation I can find on searching for author identities in ORCID involves using curl and somehow interpreting the XML file you get as a result, I tend to think that ORCID is not ready for Wikipedia editors to use as a data source. —David Eppstein (talk) 23:51, 26 August 2013 (UTC)
 * None of the three changes you suggest are either proposed or necessary. It is not necessary to refer to the ORCID site to use an ORCID to do a look up on a third party system, any more than it is necessary to go to the ISBN authority's site to find a book on Amazon. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 00:24, 27 August 2013 (UTC)
 * Well, if you're not intending to change it in one of those three ways, then what (visible) changes do you intend instead? And you misunderstand my point about the ORCID site: it was not about using ORCIDs (once they are known and linked) to find other information, it was about how Wikipedia editors might go about finding the ORCID to use in the citations they write. —David Eppstein (talk) 00:40, 27 August 2013 (UTC)
 * Sorry; I think there's been a conflation between the short term change I'm proposing here, and my musing about the long-term benefits. In the short term, we would add a link to the ORCID profile for authors with no article, which might use their name, the ID, the letters "ORCID", or an icon the size of a single "O" (ditto, as an alternative, for VIAF, etc.); that's up for discussion. In the long term, I have no firm suggestions; that's also up for discussion - I'm sure greater minds than mine will have some interesting ideas. As for finding a cited contributor's ORCID, the model is that they will be included in published works, in author profiles on publishers' websites, on individuals websites and suchlike, and in citation metadata gathered by tools such as Zotero and Mendeley. Again, no need to visit the ORCID website, and my ISBN example pertains. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 09:12, 27 August 2013 (UTC)
 * Andy, you are speaking as if ORCIDs were as common and accessible as ISBNs. In my personal experience this is not true.  ISBNs are available from a wide variety of sources (Google books, new and used book sellers, library catalogs, and even the physical books).  I have never seen a publication other than Wikipedia that makes mention of ORCIDs and those mentions were in very limited context (the ORCID article and discussions, such as this, promoting the use of ORCIDs on Wikipedia).  If this parameter is added, there will be a training cost associated with the effort needed to prepare editors to use the new parameter (measured primarily in time and effort outlays by Wikipedia volunteers explaining to others what the new value represents and how to obtain the information needed to utilize the parameter).  We need a realistic guesstimate for this effort as part of a basic cost–benefit analysis of this proposal.  You are speaking in glowing terms about potential long-term benefits, but are glossing over the short-term costs for the commitments you are requesting.  All this suggests this proposal has not been thought through well enough to implement at this time. --Allen3 talk 10:12, 27 August 2013 (UTC)
 * I don't believe that I am "speaking as if ORCIDs were as common and accessible as ISBNs", merely describing the mechanics as being similar, by way of example. I think the "guestimate" would be low, given that we can link to ORCID and I would happily draft a 'Help:' page equivalent as part of the work I plan to do rewriting all our internal authority control documentation. Nonetheless, given your concerns, and unless anyone else objects to doing so, lets park this again and revisit it when the uptake is more widespread and the benefits clearer. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 10:22, 27 August 2013 (UTC)