Help talk:Citation Style 1

For more talk pages, see Special:WhatLinksHere/Help talk:Citation Style 1.

• Help talk:Citation Style 1 (active, central discussion)
• Help talk:Citation Style 1/accessdate
• Help talk:CS1 errors (active)
• Template talk:Citation (the only Citation style 2 template)
• Template talk:Cite AV media notes
• Template talk:Cite AV media
• Template talk:Cite book
• Template talk:Cite conference
• Template talk:Cite DVD-notes
• Template talk:Cite encyclopedia
• Template talk:Cite episode
• Template talk:Cite interview
• Template talk:Cite journal
• Template talk:Cite mailing list
• Template talk:Cite map
• Template talk:Cite manual
• Template talk:Cite music release notes
• Template talk:Cite news
• Template talk:Cite newsgroup
• Template talk:Cite podcast
• Template talk:Cite press release
• Template talk:Cite report
• Template talk:Cite serial
• Template talk:Cite sign
• Template talk:Cite speech
• Template talk:Cite techreport
• Template talk:Cite thesis
• Template talk:Cite web
• Template talk:Citation Style documentation
• Module talk:CS1
• Module talk:Citation/CS1
• Module talk:Citation/CS1/COinS (active)
• Module talk:Citation/CS1/Configuration
• Module talk:Citation/CS1/Date validation
• Module talk:Citation/CS1/Identifiers
• Module talk:Citation/CS1/styles.css
• Module talk:Citation/CS1/Suggestions
• Module talk:Citation/CS1/Utilities
• Module talk:Citation/CS1/Whitelist
• Module talk:Citation
• Category talk:CS1 errors: dates/Archive 1

Should autofix more cites

I am again thinking about ways to autofix many of the invalid parameters in wp:CS1 Lua-based cites. It has been almost a year since transitioning to the Lua-based cite templates which were designed to autofix 25,000 pages for separators and page numbers (autofixes 'pages=7' as "p. 7" not "pp."), but there are still over 8,000 pages which contain "Unknown parameter" in the wp:CS1 cites (new invalid values are added to pages almost every day). As discussed last year, it will take years to manually hand-correct so many pages, with the current rate as 100-to-150 pages hand-fixed per month (4 to 7 years). Instead, we should return to the original plan, using the power of Lua to "autofix" many simple invalid parameters and log those pages in autofixed categories, thereby reducing the categories of unfixed pages to list the fewer but severe pages which really need hand-editing to fix. Users who wish to hand-update all pages could still edit the autofixed pages, and there could be hidden error messages which some users could set for view by CSS options.
In practice, most of the autofixes would occur in 2 spots in the Lua modules; the first spot would be during initial loading of the cite parameters, and the 2nd autofix would occur when preparing to show error messages but instead logging to an autofix category or hidden autofix warning for simple cases. For example, the Lua module could treat invalid "other=" to be autofixed as "others=" or handle invalid "translator=" as "others=__(translator)". An unusual parameter could list the value, such as 'part=B' could show "part: B". Likewise, a missing "url=" could check for an unnamed parameter containing "http:..." and autofix with a warning category. Recall how these autofix plans were discussed about year ago, but several other issues have delayed enhancing the Lua modules to rapidly auto-correct parameters in perhaps 10,000 more pages with simple errors/typos. Unlike Bot updates, the actual page contents would not be altered, and so the autofixes would also rapidly correct cites in hundreds of talk-pages, user-pages, drafts, or archives without inserting "unused_data" or "DUPLICATE" or altering the page histories. -Wikid77 (talk) 13:58, 5 March 2014 (UTC)

First, the current rate of hand fixing is more on the order of 100-150 pages per day. I average about 50 per day by myself, and I know of four or five other gnomes who also fix about this many at least a few days per week. That's not going to get 300,000 articles fixed any time soon, but it keeps the already-cleared categories empty and makes a dent in the populated ones.

Second, the fixes you describe could easily be made by bots. We have successfully deployed a couple of bots that have fixed tens of thousands of articles at a rate of 100+ per hour. We need a few more of these bots; a new one is in the works that will fix tens of thousands of articles. The conditions you identify are ones that I have thought about as well. If you have a list of specific conditions that bots or module code could automatically fix, please post them here in a numbered list for comment. That would be helpful.

Third, it's useful to remember that the goal is to display useful, well-formatted citations that help readers locate sources. As we identify more erroneous conditions (like the recent addition of errors for invalid DOIs and PMIDs), the total article count may increase, not because the number of erroneous citations is increasing, but because we are learning to identify and flag them more effectively. – Jonesey95 (talk) 17:34, 5 March 2014 (UTC)

Users can still re-edit pages to redo any cites, but the autofixed cites will not need to be edited and the red-error messages will be limited to severe cases, such as the impending doom when an accessdate is used without a URL or other crucial problems. -Wikid77 07:37, 6 March 2014 (UTC)

Just a quick thought, but I'd rather not autofix stuff. If the template "just fixes it for me", I'm less likely to learn that something I'm doing is causing an error. Not all of the CS1 templates are on Lua yet, so an error that cite web "just fixes" won't be autofixed by cite map, and I might not be educated about the error when it's fixed by gnome or bot (or flagged with an error message). Since we have a method to automate a fix, why not deploy a bot task that fixes the errors in the article? Interested editors will see the edit, and they may investigate and discover that something they thought was hunky dory was a problem. Additionally, if it's an error that isn't flagging a red error message, editors may copy the citation from article to article, spreading the errors around further.

In short, if the software silently fixes errors, editors won't know they are making errors. Using a bot or letting a gnome fix a type of error isn't a silent fix. Imzadi 1979 → 19:31, 5 March 2014 (UTC)

I agree it would be great to inform the particular writers of cite problems, but unfortunately, most typos in cites were entered months or years ago, and we cannot stop other users from "quietly fixing" problems without holding a cite-education class to teach the prior author's mistakes. We should not leave typos in cites, for another year, in hopes the user will, some day, return to correct the text. As a result of the past year of slow hand-edited cites, we are left with no practical alternative except to autofix the typos and auto-correct the thousands of pages within a few days, by using the speed of Lua to rapidly scan the cites and autofix the values in thousands of pages per hour. Plus the autofixing would occur in saved archives of talk-pages or user-space drafts, which would remain unchanged and yet display valid citations. However, a Bot or gnome could be used to notify some prior users about how the cites were being autofixed and explain the valid cite options. -Wikid77 (talk) 07:37, 6 March 2014 (UTC)

If you have a list of specific conditions that bots or module code could automatically fix, please post them here (or in the section below) in a numbered list for comment. That would be helpful. – Jonesey95 (talk) 15:17, 6 March 2014 (UTC)

See below: "#Types of autofixes". -Wikid77 21:34, 6 March 2014 (UTC)

Good point. I would like to propose that we add a parameter to the template family: pagetotal, so that this edit (please take a look and note the edit summary) would work right, AND be less likely to have been necessary in the first place. In other words, the above comments and this example suggest that editors are often using |pages=, assuming (incorrectly) that it is what it sounds like! To the lay editor, when describing a work, "pages" is obviously the total number of pages in a work. Except it isn't. I bet I've made this mistake myself. I wonder if confusion over this is the reason we have nopp=y, and if it's misused more often than not. So, let's discuss the |pagetotal= idea. Pro? Con? Pros: 1)It's useful to know the total number of pages, as if it's off due to a change of format, it'll help the user find the cited material nonetheless. 2)The existence of this parameter will reduce the frequency with which people use |pages= the total # of pages. (I just made this related edit to Template:Cite_book/doc. P.S.: Wow, nice to see all the thought and effort going into these citation improvements. Kudos. Apologies if this has been brought up before. --Elvey (talk) 16:02, 20 April 2014 (UTC)

Anyone?--Elvey (talk) 02:23, 23 April 2014 (UTC)

No printed style guide I know of suggests giving the total number of pages for a large work, like a book.

For journals and magazines, when short footnotes or parenthetical references are combined with a bibliography, the page number(s) that support the point being made go in the short footnote or parenthetical reference, and the range of pages that includes the entire article are included in the bibliography. (This allows a copy request to be made to a distant library, and the librarian there won't have to pay too much attention to where one article begins and another ends; just look at the page numbers.) If only end notes are used, the Chicago Manual of Style indicates only the pages that support the point being made are given.

So even for journals, the total number of pages is never given, although it could be calculated from the page range. I really don't think we should be encouraging editors to clutter articles with information no style manual considers useful just so editors who don't bother to read the instruction will have a better chance of guessing what to do. Jc3s5h (talk) 02:53, 23 April 2014 (UTC)

Ok, thanks for the input. I think you misunderstand me and the whole premise for my suggestion. For example, the total number of pages in the work cited canNOT be calculated from the page range given for the pages within the work that support the article content. (Can you tell me the total number of pages in the work cited if I say 25-27 is the page range of the pages within the work that support the article content? No, you can't. Please reread my initial comment? --Elvey (talk) 02:31, 25 April 2014 (UTC)

If a Wikipedia article only provides endnotes, then indeed we can't calculate the number of pages. But if the Wikipedia article provides short footnotes or parenthetical referencing combined with a bibliography, the we can find the page count of the work. (Jones 2014, 112)

• Jones, A. (March 2014). "Discussion of stuff". Proceedings of the Stuff Society: 110–114.

Jc3s5h (talk) 02:42, 25 April 2014 (UTC)

I think you're confused; how many pages are in the imaginary works you and I cited? In mine, it's not 3; it's over 27, but we don't know the number. In yours, it's not 5; it's over 114, but we don't know the number. I think you still misunderstand me and the whole premise for my suggestion. Mayken gets it. --Elvey (talk) 00:42, 4 May 2014 (UTC)

When you go to buy a book online the website usually lists the total number of pages in the publication. I guess that's where people are getting the idea from. It's a mistake I also made a long time ago. However, adding the total number of pages rather than the page number that supports the article text can set off an unintended chain of consequences. I have found that several pieces of text and their references are no longer found in some articles. What appears to have happened is that a bot came along and fixed |pages=600 to |page=600. At some later date an editor looked at page 600 of the reference, found that the stated 'fact' was nowhere to be seen on this page, the last page of the document. Their next action was to replace the reference with {{citation needed}}. Some time very much later the 'fact' was deleted because no-one had added a suitable reference. - 79.67.241.227 (talk) 18:50, 25 April 2014 (UTC)

The fact that people do mistakenly record the total number of pages in |pages= is a problem. At a minimum, the documentation should be updated to explicitly state that |pages= is not to be used for the total pages in the work.

We should also consider creating and documenting a parameter like |total-pages=. We do not need to display the information, and, if done, could explicitly state in the documentation that it is not desired, or displayed. However, it would provide a clear, intended location to record the number of pages in the work for those editors inclined to do so. Creating such a parameter might keep a reasonable number of editors from incorrectly putting the total number of pages in |pages=. I'm only floating the idea; not sure about it myself. I'm looking at this as a user interface issue. Giving the user a specific place to put the information currently erroneously placed in |pages= would, probably, reduce the erroneous use of that parameter. — Makyen (talk) 21:03, 25 April 2014 (UTC)

@Makyen: Glad you agree and understand - and perhaps have explained it better! I chose "pagetotal" so that it's alphabetically close to page and pages. And didn't include a dash because others didn't. I agree with all the other enhancements to my idea you've given.

There are two ways to use these templates, and when it comes to books, there is one case I can think of where the total pages is a desirable detail. If {{cite book}} is used for entries in an bibliography in an article on the author, not a list of works cited. In that case, it is helpful to know that Dan Savage wrote a book of X pages in Dan Savage bibliography. But if I were to cite The Kid: What Happened After My Boyfriend and I Decided to Go Get Pregnant in an article, that detail is useless. (I'll note now that the bibliography article uses tables instead of citation templates to hold the various details, but Caroline Kennedy#Works published could easily be using cite book in a bulleted list.) Imzadi 1979 → 22:57, 25 April 2014 (UTC)

Useless when there's more than one printing of the book, and the different versions have different pagination? Nonsense. As I said above: Pros: 1)It's useful to know the total number of pages, as if it's off due to a change of format, it'll help the user find the cited material nonetheless. Over your head? --Elvey (talk) 00:42, 4 May 2014 (UTC)

I don't see it. Adding 'pagetotal' will not fix the issue of editors using 'pages' for the total number of pages. The documentation already states "do not use to indicate the total number of pages in the source." If editors are not reading that, then they will not read that there is a new parameter. The purpose of a citation is to identify the source material; the total number of pages is not useful in identification, nor does it indicate anything about the quality of the source. No style guide I am aware of includes the total pages. And this page total subject has wanderd off the initial subject. --  Gadget850 ^talk 10:18, 4 May 2014 (UTC)

Types of autofixes

The autofixes could be tagged with small "^{[fix cite]}" where the various types of auto-corrected parameters would be:

• f1. subtitle as comment: The value of "subtitle=" could be treated as a comment to show after a title, but not in the COinS metadata
• f2. roles as others: Common roles, such as "photographer=" or "illustrator=" could be inserted after "others="
• f3. autofix alias keywords: A typical alias would be allowed, such as "dated=" for "date=" to also place in COinS metadata
• f4. prefix/suffix respellings: An unknown parameter could be spell-corrected, such as "fist=" autofixed as "first=" or "auhtor2=" treated as matching "author2=".
• f5. list unknown parameters: Any other unknown parameters, which did not match prefix/suffix respelling (not simple "pulbisher" as "publisher") could be listed as "keyword: value" format, such as "site: Xcom Conference" or "near: Paris" because neither "site=" nor "near=" would match as a common respelled parameter.

Any non-autofixed issues would still log the current error messages, but the autofixed pages would link to different maintenance categories, such as:

• Category:Pages_with_citations_autofixing_respell_parameters
• Category:Pages_with_citations_autofixing_unknown_keywords
• Category:Pages_with_citations_autofixing_unknown_phrases

Because one of the goals, of autofixes, is to reduce the clutter of simple typos and help pinpoint serious problems, there would be more categories to list the simple autofixes (such as obvious respelling "auuthor=" as "author="), away from pages with the more-complex cite problems. In a sense, reducing a category of 9,000 various unknown parameters into 5 or 6 categories, where one isolated the "unknown phrases" (as a separate list) could help to pinpoint just a few hundred pages which needed severe updates to fix the garbled cites. As the many simple cases are autofixed, then methods to auto-fix complex problems will become easier to spot. Currently, we have many simple cite typos, from 2 years ago, cluttering the list where the complex cite cases are drowned in an ocean of simple typo pages. Update: New essay "wp:Autofixing cites" describes some methods to autofix cites used by the new version of Lua-based cite templates. -Wikid77 (talk) 21:34, 6 March, 13:25, 13 March 2014 (UTC)

• Also fixes f6. renamed/split URL with bar, where the "url=" keyword has been omitted or misspelled as "ulr=" or such, and split URLs (which contain vertical bar/pipe "|") can be rejoined in some cases. Split URLs occur in links to Google Translate with language pairs coded as "&langpair=it|en" and with newbank.nl webpages. All cases of f1-f2 have been autofixed in Lua script, and the extra runtime is neglible because cites with valid parameters do not run the autofix steps. -Wikid77 15:44, 18 March 2014 (UTC)
  • What value are comments in a citation? How do they help identify the source? --  Gadget850 ^talk 10:23, 4 May 2014 (UTC)

Prototype to autofix cites

I have created a working Lua prototype, to begin comparing the results when a citation has been autofixed for simpler display. Compare the sample results:

{{cite web |title=Test1 |last=Doe |pages=3--4|Guardian|http://z |office=London}} autofix: current: Doe. "Test1". pp. 3--4. {{cite web}}: Missing or empty |url= (help); Text "Guardian" ignored (help); Text "http://z" ignored (help)

Note, in the above autofixed example, the missing "url=" is set with the "http://z" text, and linked to title "Test1" while the double-hyphen in pages "3--4" is filtered as a dash 3–4. Next, the 'Guardian' is shown, followed by "office: London" as extra text. By comparison, the current cite is awash in a sea of alarming red-error messages which overpower the text but demand attention to the simple details which have been quietly autofixed in the first case. -Wikid77 (talk) 10:00, 7 March 2014 (UTC)

Autofixing will echo extra parameters

A major benefit of wp:autofixing cites will be the echoing of the extra, unknown parameters (such as "paragraph: 6" when a user has inserted invalid "paragraph=6"), and hence, the autofixed cite tends to show more data, more details to help pinpoint the text to verify, such as "note: 3rd line from bottom". By contrast, the red-error message had shown "Unknown parameter |note= ignored" to show only the name "note" but no mention of the "3rd line". Of course the main benefit of autofixing will be to reconstruct an unnamed or split URL with a rebuilt title, plus autofixing to show the author names. The strategy is to completely autofix the title/url plus first author or editor, but echoing extra parameters is another major benefit. -Wikid77 11:44, 2 April 2014 (UTC)

So |note=This is a really good book pinpoints the in-source location? What is the plan to auto-validate good and useless comments? How many citations currently have notes? --  Gadget850 ^talk 10:37, 4 May 2014 (UTC)

Autofixing has indicated new parameters

When analyzing thousands of pages with invalid parameters, to look for common problems, a major issue has been users putting "comment=" or "note=" or other parameters to insert notes. Of course, autofixing will show any named parameter, such as "note:__" or "comment:__" (or "figure: 2b"), but it would be better to make "note=" and "comment=" as valid parameters, unlike "postscript=" replacing the final dot. Also, a few others should be added, such as "author_note=(members of ABC committee)" and "title_note=(written as the prequel to Book)" to further explain a book/magazine title where people have forced such comments into "format=" or "publisher=" as if being substitutes for missing "title_note". -Wikid77 17:52, 8 April 2014 (UTC)

Autofixing for recent pages

By mid-April 2014, all remaining 3,500 articles with "Unknown parameter" had been hand-edited to correct the CS1 cite parameters. By 19-21 April, another dozen pages each day contained recent cite errors, such as: some (15%-20%) misspelled "accessdate=" (or 2 words), extra bar "|url|=", one "publishe=" misspelling, ten capital "Publisher=" in one page, "pags=" for page, and 3 uses of {{cita_web}} in one page with 7 Spanish parameters (título, obra, fecha, formato, idioma, etc.). A variety of long-term upgrades can be used: similar to accepting capital "Author=" then capital "Publisher" should be among the common parameter names allowed; the Template:Cita_web should be changed to handle any Spanish parameters as switched into English parameters; and autofixing should handle a bar within "url|=http" in order to auto-correct and link the url data. Per the 80/20 Rule, perhaps allowing just 20 aliases of 100 common typos (such as "other=" or "note=" as postscript) would reduce ~80% of invalid cite parameters. For example 2-word "access date=" was used 11 times in article "University of Central Florida College of Medicine" (26 April 2014). -Wikid77 (talk) 16:17, 19 April 2014, 15:20, 27 April 2014 (UTC)

Should quote chapter when title and journal

I think there is still an old 3-way bug for "chapter=" when using both title/journal, which I neglected to fix when first developing the Module:Citation/CS1 last year. As I interpret the issue, a "chapter=" should always be quoted and then force "title=" into italics. However, note the following in {cite_journal}:

Cite journal comparison

Wikitext	{{cite journal|EditorGiven1=J.S.|EditorSurname1=Hollingsworth|chapter=Trilobite Biostratigraphy and Sequence Stratigraphy of the Upper Dyeran (traditional Laurentian "Lower" Cambrian) in the southern Great Basin, USA|first=Mark|journal=Museum of Northern Arizona Bulletin|last=Webster|number=67|title=Cambrian Stratigraphy and Paleontology of Northern Arizona and Southern Nevada|year=2011}}
Live	Webster, Mark (2011). "Cambrian Stratigraphy and Paleontology of Northern Arizona and Southern Nevada". Museum of Northern Arizona Bulletin (67). {{cite journal}}: |chapter= ignored (help); Unknown parameter |EditorGiven1= ignored (help); Unknown parameter |EditorSurname1= ignored (help)
Sandbox	Webster, Mark (2011). "Cambrian Stratigraphy and Paleontology of Northern Arizona and Southern Nevada". Museum of Northern Arizona Bulletin (67). {{cite journal}}: |chapter= ignored (help); Unknown parameter |EditorGiven1= ignored (help); Unknown parameter |EditorSurname1= ignored (help)

In the above example, "Trilobite Biostratigraphy" is just one chapter in the larger topic (book), Cambrian Stratigraphy and Paleontology..., which would cover all life forms of the Cambrian Period. Perhaps always quote a chapter title? I was too tired last year (still am) to test all major combinations with title+journal/work, and I neglected to fix that. It is a minor problem, but some PhD users might expect it fixed in the next Lua release. -Wikid77 (talk) 20:38, 9 March 2014 (UTC)

• Problem is setting Chapter italic when Periodical+Title set: The problem can be fixed, in 2 places, by not quoting the Title text and not italicizing Chapter name, as done here:

        if is_set(Periodical) and is_set(Title) then
            Chapter = wrap( 'italic-title', Chapter ); --DO NOT DO THIS!!
            TransChapter = wrap( 'trans-italic-title', TransChapter );
        else
            Chapter = kern_quotes(Chapter);
            Chapter = wrap( 'quoted-title', Chapter );
            TransChapter = wrap( 'trans-quoted-title', TransChapter );
        end

Instead, always quote the Chapter name, by: Chapter = wrap( 'quoted-title', Chapter). Plus fix "if is_set(Periodical) then" to also check Chapter, as:

        if is_set(Periodical) and not is_set(Chapter) then
            Title = kern_quotes (Title);
            Title = wrap( 'quoted-title', Title );
            TransTitle = wrap( 'trans-quoted-title', TransTitle );
        elseif inArray(config.CitationClass, ...)

By adding the restriction "and not is_set(Chapter)" then the logic will naturally decide to italicize the book's Title as well as the "journal=" Periodical. Hence, that fixes the problem, without altering other issues about the quoted/italic titles. -Wikid77 (talk) 23:55, 10 March 2014 (UTC)

Update: I have noticed several articles with similar use of 3 parameters about chapters, book/magazine titles, and collections or series. Hence, this issue should be fixed in the current Lua /sandbox version. -Wikid77 18:00, 8 April 2014 (UTC)

Accesswalls

Proposal: Replace |subscription= and |registration= with a new |access=.

Rationale: There are at least five, probably more, types of access restriction, and more may develop in the future.

Syntax:

• |access=sub (or |access=subscription) = subscription (paid registration) required
• |access=reg (or |access=registration) = free registration required
• |access=fee = per-access or per-item fee required
• |access=abstract = free abstract, but fee required for access to complete content
• |access=audience = access restricted to defined (e.g. academic or professional institution) audience

This will also obviate any need to have code trying to determine which existing parameter supercedes the other, and other potential future complications.  — SMcCandlish ☺ ☏ ¢ ⚞(^Ʌⱷ҅̆_⚲͜ⱷ^{^})≼  14:55, 24 March 2014 (UTC)

I rather like this idea. What I don't like is the parameter name: |access= is too close to |accessdate=. Perhaps |permission=? I have bulleted your syntax.

What is Template:Pra?

—Trappist the monk (talk) 15:08, 24 March 2014 (UTC)

I get what you mean about |accessdate=, but |permission= is longwinded. {{pra|access|subscription}} was a typo for {{para|access|subscription}}. All of them require some form of registration, so perhaps |register=.  — SMcCandlish ☺ ☏ ¢ ⚞(^Ʌⱷ҅̆_⚲͜ⱷ^{^})≼  16:28, 24 March 2014 (UTC)

• I fear that this further complicates the edit window, and the likely input errors when people don't know what too fill in. That's why binary yes/no is good. While these differences exist, I'd like to understand on a practical level what you feel the benefits to the project of this fractioning of the type of access. -- Ohc ^¡digame! 15:16, 24 March 2014 (UTC)

• I'm not sure if the complexity is worth the value to readers and editors. One problem is this sort of thing tends to change fairly rapidly, compared to the frequency with which reference lists are maintained. There are also some problem with the details of the proposal. A particular entry might be available at no additional fee to those affiliated with a particular institution, a paid subscription might be available, and the item might be available for one-time access. Another problem that an item with "access restricted to defined (e.g. academic or professional institution) audience" is not published and so shouldn't be cited in Wikipedia. Jc3s5h (talk) 15:40, 24 March 2014 (UTC)

• My concern is that it's already fragmented into a code mess for paid and unpaid accesswalls, with the further complication that some forms of paywall are not subscription-based, but one-time purchases. An alternative idea to what I first proposed is to merge the two existing options into one simplified parameter, and not distinguish at all between the paid types of accesswall: Perhaps a |register= or |wall=, with one value paid and opposite value free, with any other value (e.g. y) defaulting to "paid".  — SMcCandlish ☺ ☏ ¢ ⚞(^Ʌⱷ҅̆_⚲͜ⱷ^{^})≼  16:32, 24 March 2014 (UTC)

Revised proposal: Perhaps a |register= or |wall=, with one value paid and opposite value free, with any other value (e.g. y) defaulting to "paid". The problem with the current code that it assumes that paywalls are subscription based when this is often not true.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:02, 13 April 2014 (UTC)

Migrating cite music release notes to Module:Citation/CS1/sandbox

Because it is similar to {{cite AV media notes}} I'm beginning to think about how to migrate {{cite music release notes}} to Module:Citation/CS1/sandbox.

I'm thinking that changes similar to those made to {{cite AV media notes}} apply here:

1. |type= – provides functionality similar to |albumtype= as described at Migrating cite AV media notes, item 2. Here, |type= has been repurposed to control the format of |name=. When |type= is set to any value, the value in |name= is rendered in quotations; otherwise the value is rendered in italic font. Presumably, this is because individual song titles are quoted, not italicized. Because {{cite music release notes}} cites the notes, not the song or album, this undocumented functionality is inappropriate in this template. I propose to remove this functionality from {{cite music release notes}} and so free |type= for use consistent with the other CS1 templates.
2. |Format= – not the same as |format=, this undocumented parameter is an alias of |type= which is not supported in the normal way; see above. Another, also undocumented parameter, |titletype=, is also an alias of |type=. I propose to deprecate |Format= because it is so similar to |format= (which has the specific definition of online resource file format) and deprecate |titletype= because it is undocumented. Both of these shall be deprecated in favor of |type= and I shall change the default value from "Release notes" to "Media notes" so that it is the same as {{cite AV media notes}}.
3. |name= – an alias of |series= is used in place of |title= which places the "title" of the notes in a nonstandard position when the citation is rendered. While supported, |title= is remapped to be an alias of |chapter= though this functionality is not documented. I propose to restore the normal sense of |title= and deprecate |name= in favor of the restored |title= consistent with all other CS1 templates.
4. |artist= – simply a unique alias of |others=, which is not currently supported, so I propose to deprecate it in favor of |others= as was done in {{cite AV media notes}}.
5. |pid= – I propose to deprecate |publisherid= because it is simply an undocumented alias of |id=.

As I did with {{cite AV media notes}}, I will modify the template, tweak the documentation, and then create an AWB script to make appropriate changes to the templates in article space.

I think that once these changes are made, another AWB script can rename the templates in article space from {{cite music release notes}} to {{cite AV media notes}} and so accomplish the migration without having any effect on Module:Citation/CS1. A redirect would handle any new instances of {{cite music release notes}}.

—Trappist the monk (talk) 13:22, 26 March 2014 (UTC)

This all sounds straightforward to me. Would you consider notifying relevant Wikiprojects, as you did with the last migration? – Jonesey95 (talk) 15:23, 26 March 2014 (UTC)

Did that already.

—Trappist the monk (talk) 15:51, 26 March 2014 (UTC)

I have tweaked the {{cite music release notes/sandbox}} (testcases – such as they are) and have an AWB script to run after I update {{cite music release notes}}. I have added code to the script to fix capitalization. In a surprising number of these cites, the parameters are capitalized, so for who knows how long, these citations have not been fully rendered. I have also added code to change |albumlink= to |titlelink= because I have found them in the wild. Though neither are supported in the current or sandbox versions, |titlelink= is supported by {{cite AV media notes}} to which all of these {{cite music release notes}} will eventually migrate.

I have found several instances of citations like the second example on the template's documentation page. This example should be {{cite journal}} not {{cite music release notes}}. Sigh. And, those that I did find seem to also put the journal's volume and issue number in |id=. Perhaps I'll see if I can make yet another script that will tease apart the contents of |id= and just fix these.

—Trappist the monk (talk) 19:42, 26 March 2014 (UTC)

I was going though {{cite music release notes}} a while back and found the same issue where other templates should have been used. I think there were some also uses of oddball parameters that were never coded. --  Gadget850 ^talk 15:34, 27 March 2014 (UTC)

Turns out that there were only about twenty of those citations that referenced Film Score Monthly and I have fixed them. Today or tomorrow I'll update the {{cite music release notes}} from {{cite music release notes/sandbox}} and start my AWB script working on adapting the article space templates.

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

So is there now no longer any way to control the format of |name=? I ask because {{Cite music release notes}} is often used to cite the release notes for singles, and it conflicts with our manual of style if the name of any single referenced in this way can only be formatted in italics, rather than in quotation marks. A Thousand Doors (talk | contribs) 22:50, 30 March 2014 (UTC)

The purpose of {{cite music release notes}} is to cite print material. The title of the printed notes may be the same as the title of a single, but it is still a print document, separate and apart from the single, so the template treats it that way.

You do, I think, point out a shortcoming that exists in {{cite AV media}} which is supposed to be the proper template for citing singles, albums, video, etc. There is no mechanism available to render the title of a single in quotes. I'll have a look at that and see what can be done about it.

—Trappist the monk (talk) 23:25, 30 March 2014 (UTC)

Having remembered that I want to finish this, within the next couple of days I will run an AWB script to rename existing instances of {{cite music release notes}} to {{cite AV media notes}}. Once that is complete, I'll make {{cite music release notes}} a redirect to {{cite AV media note}} and do documentation cleanup.

—Trappist the monk (talk) 12:22, 26 April 2014 (UTC)

Some tweaks to the case sensitivity of the script, or a follow-on script, may be needed. See the unsupported parameter errors resulting from this edit, this edit, and probably more. If you are done converting these templates, you could probably focus on Article-space pages in the unsupported parameter category. – Jonesey95 (talk) 04:59, 30 April 2014 (UTC)

There were a small number which could have been handled a bit better in this transition, but nothing significant/major. I recall having to change some in earlier passes through the "unsupported parameters" category. Mostly I noticed it because it has some unique parameter usage which required special-casing a couple of the regex replacements I was using. most of my notice of it was the need to refine what I was doing to account for uniquely permitted parameter names. There are multiple templates where this sort of thing was the case. On this set I did not check, but it is possible that the most recent problems existed prior to the transition.

However, the Category:Pages with citations using unsupported parameters is once again cleared. If I recall correctly, there were 21 new pages in the category. At least 20%, if not more, were due to vandalism. At least one appeared to be erroneously not in the category earlier: the unknown parameters existed on the page from 2012. — Makyen (talk) 10:40, 30 April 2014 (UTC)

In {{cite music release notes}}, |name= equated to |title=, not |author=. Similarly, |PID= in these templates equated to |id= and not to |pmid=. |type= should be deleted and then |Format= becomes |type=. If there were other {{cite music release notes}} citations that your script fixed, you might want to revisit them. I have fixed the two that Editor Jonesey95 identified.

—Trappist the monk (talk) 12:36, 30 April 2014 (UTC)

In March when I started all of this, I ran an AWB script that modified instances of {{cite music release notes}} by changing parameter names and fixing capitalization. Apparently I didn't get them all.

I did just run a script over the content of Category:Pages using citations with format and no URL because I noticed that other {{cite AV media notes}} citations in pages that were edited by my rename script were misusing |format=. The script fixed about 120 of them.

—Trappist the monk (talk) 11:17, 30 April 2014 (UTC)

Done, I think.

—Trappist the monk (talk) 11:41, 30 April 2014 (UTC)

Someone did a revert on Bette Davis Eyes, but I fixed it. Looks like you missed Say Somethin' (Mariah Carey song). I will fix the navboxes. --  Gadget850 ^talk 16:04, 30 April 2014 (UTC)

Good, thanks. Carey is fixed.

—Trappist the monk (talk) 16:23, 30 April 2014 (UTC)

Need help fixing unsupported parameters

As the Bots continue to mangle major articles by inserting invalid parameters, we still need more people to help fix a few more pages, each day, to fix "DUPLICATE_" or "unused_data=" or other invalid parameter names. See category:

• Category:Pages_with_citations_using_unsupported_parameters (pages: 0)
• Category:Pages_with_citations_using_unsupported_parameters&from=La

Remember, it is possible to navigate the category by URL question-suffix "?from=Ra" to display pages beginning at letters "Ra" or such. Try to scan through the list to fix major pages first (or semi-major, with 100+ pageviews per day); I just fixed page "Pluto" again, as major pages scarred with glaring red-error messages give the appearance that the "keepers of the 'pedia" are unable to correct major errors in major pages. Many invalid parameters date back over 1-3 years, before the wp:CS1 Lua-based cites were installed to show cite messages. Any help, even edit a few pages per day, will help reduce the backlog of 3,400 scarred pages, growing larger every day. -Wikid77 16:03, 30 March, 11:18, 2 April 2014 (UTC)

If these improper edits are still happening, why are the bots not blocked? Why is it not the responsibility of the bot owners to fix all damage before the bots are unblocked? Jc3s5h (talk) 16:21, 30 March 2014 (UTC)

I think Bot errors are rare. -Wikid77 11:18, 2 April 2014 (UTC)

@Wikid77: Could you please give some examples of bots that "continue to mangle major articles" where you (or someone else) has reported the error to the bot owner and the bot owner has not made the appropriate changes? Thanks! GoingBatty (talk) 21:51, 30 March 2014 (UTC)

Coming here after seeing discussion on Jimbo's talk page: I'm happy to help gnoming away, but it would be great if there could be a priority list of the high hit-rate articles within the 3315 in the category.

And a question: why do some of the articles in Category:Pages with citations using unsupported parameters seem to be sorted by their DEFAULTSORT, and others not? See, under "Pa": "Richard Phipson" followed by "Phoenix Jones": both have DEFAULTSORTS, so Jones should be appearing under "J". At the end of "M" we have Málaga though it has a DEFAULTSORT of "Malaga", while Öreryd is sorted correctly by its DEFAULTSORT of "Oreryd" What's happening? (My instinct is to look at this category for articles which need other work such as adding a DEFAULTSORT or checking whether "Foo (whatnot)" is correctly linked from "Foo", to do this while sorting out the citation problem, but I'm puzzled by the inconsistent treatment of defaultsorts.) PamD 14:20, 1 April 2014 (UTC)

Just scan the category sections ("?from=Ta") for obvious major articles; otherwise, fixing 5 pages is equivalent to a page read 100x per day. -Wikid77 11:18, 2 April 2014 (UTC)

I'll commit to fixing 30 to 50 of these per day until the category is done. Who else is in? If we can do 200 per day, we can clear out the category in a couple of weeks. – Jonesey95 (talk) 15:04, 1 April 2014 (UTC)

I'm fixing 10-20 per day, while copy-editing. -Wikid77 11:18, 2 April 2014 (UTC)

@PamD: Articles are placed in these error categories via Template:Broken ref. The coding in that template currently sets the category sort key to the page name, thus overiding any DEFAULTSORT in the article. These categories contain a mixture of people and non-people categories, so maybe a sort by surname wouldn't work too well. -- John of Reading (talk) 16:16, 1 April 2014 (UTC)

@John of Reading: but the weird thing is that they're sorting inconsistently, some by the Defaultsort and others by the page title. Your note doesn't explain how Öreryd files in the Os and Richard Phipson in the Ps. PamD 17:46, 1 April 2014 (UTC)

Tracked in Phabricator
Task T40435

@PamD: Yes, my attempted answer was rubbish! The difference is that some of the entries are generated by citations inside <ref>...</ref> tags and some are not. bugzilla:38435 says that the DEFAULTSORT gets ignored when the category is generated via a reference and the DEFULTSORT statement is below the reflist. There's an example at User:John of Reading/Sandbox. In one of my test categories, the page is sorted under "Z", matching the DEFAULTSORT, and in the other it is sorted under "J", ignoring the DEFAULTSORT. -- John of Reading (talk) 18:35, 1 April 2014 (UTC)

I don't know of a way to provide a list of high-hit-rate articles in a given category, but I can provide a catscan report listing Featured Articles that have CS1 errors. There are currently 2,687 such articles. There are 26 Featured Articles in the "unsupported parameter" category. – Jonesey95 (talk) 20:40, 1 April 2014 (UTC)

• I think many of those have "|coauthor=". -- Ohc ^¡digame! 09:23, 2 April 2014 (UTC)

|coauthor= is deprecated but still supported so that's not how a page gets added to Category:Pages with citations using unsupported parameters.

—Trappist the monk (talk) 10:19, 2 April 2014 (UTC)

Somehow I didn't finish my thought. There are three bots now in WP:BRFA and a fourth on the way that will, I hope make a dent in the 99,000ish pages in Category:Pages containing cite templates with deprecated parameters.

—Trappist the monk (talk) 10:46, 2 April 2014 (UTC)

After sampling a few pages, 'unused_data' and 'DUPLICATE_xxx' added by Citation bot is probably the most common. Then we have a number of totally oddball parameters such as 'isbn2', 'opening', 'book', 'ref name', 'digitalised', 'issues', 'paragraph', 'producer', 'newsen', 'refname', 'nbv accessdate' and 'rev'; two references on one page use 'date-of-publication', 'title-of-website' and 'sponsor'. --  Gadget850 ^talk 10:37, 2 April 2014 (UTC)

Agree, quite a lot originating from the citation bot (that is, existing error that the bot marked in a particular way) and a mixture of other stuff. Please consider expanding Wikipedia:AutoWikiBrowser/Rename template parameters where appropriate, then we can more easily keep this category clean in future. Rjwilmsi 11:30, 2 April 2014 (UTC)

I have fixed a few hundred of these articles, and Trappist the monk has cleaned up most of the low-hanging fruit (a few thousand articles) using an AWB script. Most of what is left are the "oddballs" referred to above. I believe that Citation Bot no longer adds "unused_data" to citations, but it is currently adding "DUPLICATE_XXX" (legitimately pointing out duplicate parameters that need attention from a human editor) and "eprint". The latter is an unsupported parameter; a bug report has been submitted.

The category should be empty in 2-3 weeks, after which we will be able to watch for patterns in what is newly added to the category, notify editors using ReferenceBot, and take other steps to reduce the future growth of the category. Keep up the good work, everygnome! – Jonesey95 (talk) 18:16, 2 April 2014 (UTC)

 Done As of 13:08, 15 April 2014 (UTC) this category was cleared of all pages which I believe should be changed. I went back through it again at about 03:03–04:27, 16 April 2014 (UTC) and cleaned the additional 5 which had been added to the category.

I just ran through it again (03:09, 19 April 2014 (UTC)). There were 18 additional pages added. The errors on these 18 pages included:

6x Mistyped parameter names

1x "=" in parameter value instead of after parameter.

6x URL bad/no quoting of |

1x URL bad/no quoting of [

4x misunderstanding parameters (e.g. splitting access date into multiple parameters (year/month/day))

1x wrong separator between words within parameter name. "access date"

1x title bad quoting of |

1x title/chapter/book confusion

2x excess text

15–20x (4 pages, probably 15-20 parameter names were wrong) parameter names in foreign language (Spanish)

1x multiple uses of same parameter name

10x incorrect capitalization of parameter names

There are 168 pages remaining in the category. However, none of them appear to be ones which should be changed. All appear to be archives, testcases, etc. I am using the following regular expression for the name criteria to filter them out:

[Aa]rchive|Articles for|Mediation Cabal|requests for arbi|Filled requests|Deletion review|Deletion review|Categories for discussion|Featured article candidates/Featured log|Files for deletion|Requests for arbitration|Suspected sock puppets|Wikipedia Signpost|Autofixing cites|Bots/Requests for approval|Centralized discussion/Citation discussion|Featured article candidates/Navenby|testcases|regression tests|sandbox

I fixed 2,000, or so, pages. A significant number of the specific substitutions I determined are appropriate to put as standard template parameter name replacements within AWB for most citation templates. This will include all of the non-English parameter names for which I determined direct substitutions. Determination was done by a combination of translation and investigating the actual parameter names used in templates on various language Wikipedias. These determinations are far from comprehensive, but included all such which I encountered while making changes. I will try to work up a list of them and get them in as default substitutions for AWB. Doing so will, hopefully, help keep the quantity of pages in this category low. If anyone else has specific substitutions which are always correct (i.e. do not require human verification), they can be added to the set that AWB routinely fixes.

However, the large majority of the rules (regular expressions) I used do not fit with that method of correction, or are inappropriate for unattended substitution without additional logic to check for erroneous corrections. Examples of such are regular expressions to replace within parameter names many/most 2 erroneous characters errors, any adjacent character swap, replacement of "|" characters in URLs and titles when the following text was obviously not a parameter, etc. Most of these could be included in a bot with a bit of logic for determining that the correction is valid. — Makyen (talk) 04:16, 19 April 2014 (UTC)

date errors

What should I do with cases like "|date=undated"? Outright removal would probably be simplest. But correct? -- Ohc ^¡digame! 04:46, 2 April 2014 (UTC)

|date=n.d. is accepted by the CS1 module. Like this:

Author (n.d.). Title. {{cite book}}: |author= has generic name (help)

That's what I would recommend. Another choice would be to comment it out so that anyone editing the article would know not to look for a date in vain. I would not remove it entirely, lest you send someone on a wild goose chase that results in reinsertion of "undated". – Jonesey95 (talk) 05:05, 2 April 2014 (UTC)

• Wonderful. Didn't know that "n.d." is accepted. Thanks. -- Ohc ^¡digame! 06:10, 2 April 2014 (UTC)

Looks like |date=n.d. needs to be added to the documentation.

Given that we explicitly recommend:

• |author=<!--Staff writer(s); no by-line.-->
• |publisher=<!--Unspecified by source.-->

Having a comment in addition might not be a bad idea. It could save someone some time checking. — Makyen (talk) 08:22, 2 April 2014 (UTC)

When changing from "undated" to "n.d." be sure to check for Harvard citations or short footnotes that need to change to match. This would apply whether the Harvard citations or short footnotes were done with templates ({{harv}} or {{sfn}} or manually. Jc3s5h (talk) 11:24, 2 April 2014 (UTC)

Can the full stop after the brackets be suppressed when {n.d.) is used as (n.d.). looks a bit silly. Nthep (talk) 22:09, 19 April 2014 (UTC)

We have the same situation regarding editions, formats/types:

• Doe, John (n.d.). Book of Examples (2nd ed.). Anytown: Example Press.
• Doe, John (2013). A Study of Examples (Thesis). Collegetown: University.
• "Michigan" (Map). The Road Atlas. Rand McNally. 2013. p. 50.

I don't see this as a problem since we terminate sections of the citation with a period, regardless if the content within parentheses contains a period or not already. Imzadi 1979 → 00:06, 20 April 2014 (UTC)

Alternately, use nd instead.

—Trappist the monk (talk) 00:24, 20 April 2014 (UTC)

One of the style manuals that inspired the citation templates was APA style, which does call for "(n.d.)." Jc3s5h (talk) 00:59, 20 April 2014 (UTC)

nd produces a CS1 error. Regardless of the APA style guide, to my British eyes, a period after parentheses which terminate with a period looks out dated and overly formal. Nthep (talk) 18:22, 20 April 2014 (UTC)

{{cite book |title=Title |date=nd}}

→Title. nd.

No error. Example please?

—Trappist the monk (talk) 18:38, 20 April 2014 (UTC)

No error there but why has it not parenthesised the (non)date? Nthep (talk) 19:15, 20 April 2014 (UTC)

{{cite book |title=Title |author=Author |date=nd}}

→Author (nd). Title. {{cite book}}: |author= has generic name (help)

Date in parentheses when following |author=. Still no error. So where are you seeing errors? Can you show an example where nd produces a CS1 error?

—Trappist the monk (talk) 19:28, 20 April 2014 (UTC)

Can't find it again, probably a preview error on my part. Thanks for the clarification. Nthep (talk) 21:06, 20 April 2014 (UTC)

Need to accept free-form dates

At this point, we can begin to allow free-form dates, such as "undated" or "late October 2011" and change the Lua software to bypass date-format checking when the date seems to be free-form. Recall that the Lua-based cites were purposely kept limited, from last year, in an effort to speed the markup-to-Lua transition from {Citation/core} within a 6-week period, leaving rare cite forks (and complex parameters) for later, which is now. The expansion of such new features should be tested in a separate version (not the main /sandbox version). -Wikid77 (talk) 22:35, 2 April 2014 (UTC)

I don't quite recall the reasoning. Can you provide a link to the discussion?

Since there seems to be no hope of distinguishing free-form dates from gibberish, the only way I can imagine your proposal working is to recognize a date in an improper form and issue a warning that it should be changed to an acceptable date; any entry not recognized as a date in an improper form would be assumed to be a free-form date and allowed. For example, "July 4th, 1776" could be recognized as a date in improper form. Jc3s5h (talk) 23:14, 2 April 2014 (UTC)

The use of free-form dates is a common practice, and could be detected by some trigger words such as "late" or "early" or "before" (etc.), or perhaps by words which do not match misspelled month names. In the above case, "4th" beginning with digit "4" could be excluded as a non-alphabetic word, but would match a Lua regex pattern for digit-plus-th as pattern "%dth". -Wikid77 23:28, 2 April 2014 (UTC)

Please provide data to back up your assertions about the commonness of the use of free-form dates. At this writing, there are 108,000 articles in Category:CS1 errors: dates. What fraction of those use free-form dates?

I think it makes more sense, since the date error messages are not displayed to readers unless they have specifically changed their preferences to show those errors, to leave the system as is until the category can be scrubbed by bots and bot-like editors, followed by human editors, who can find and fix the vast majority of cases that are actual date errors. In my experience, the vast majority of errors in the category are (a) valid date ranges that need an en dash or other punctuation fixes (many of these are bot-fixable), (b) newly-acceptable date ranges that need a null edit to remove the error category, (c) dates that are bot-fixable and just waiting on closure of an RFC about month abbreviations, and (d) dates of the form XX/XX/YY or XX/XX/YYYY.

I just clicked on a random sample of 50 articles in the category and found the following: 5 bot-fixable date ranges, 8 valid ranges needing a null edit, 18 fixable by BattyBot task 25, 8 of the form XX/XX/YY(YY) or XX.XX.YY(YY), 10 other dates needing human attention, and 1 free-form date ("YYYY-present"). So that's one free-form date out of an admittedly small sample of 50 articles, 31 bot-fixable or already-valid dates, and 18 dates needing human attention. If that scales, we're looking at about 2,000 free-form dates. Let's have this discussion again when the category is in the 10,000-article range.

A null edit of the whole category would cut the article count substantially, I believe. I don't know of any easy way to accomplish that. – Jonesey95 (talk) 23:54, 2 April 2014 (UTC)

Unhiding hidden error messages

Right now, there are seven error message that are hidden from editors who have not chosen to make all error messages visible. These are

hidden CS1 error messages

error message	category	number of pages in category
	Category:Pages using citations with accessdate and no URL	0
	Category:CS1 errors: dates	60
	Category:Pages containing cite templates with deprecated parameters‎	0
	Category:Pages using citations with old-style implicit et al.	0
	Category:Pages using citations with old-style implicit et al.	0
	Category:Pages using citations with format and no URL	0
	Category:Pages using web citations with no URL	0

Any reason why at least some of these shouldn't be unhidden at the next Module:Citation/CS1 update?

—Trappist the monk (talk) 17:17, 5 April 2014 (UTC)

My two cents: If I recall correctly, in the discussion that resulted in these errors being hidden, it was agreed that they would be hidden in a particular category until the bot-fixable errors had been fixed. Neither Bot nor AWB work has been applied to the "accessdate", "displayeditors", "format", or "missing url" categories. Please correct me if I am wrong. We may decide as a group that one or more of these categories is not fixable by bots (I'm looking at you, "missing url").

The "date" and "deprecated parameters" categories have been traversed by bots to fix some of the problems therein, but they both need more work by bots. Those bots are either returning from RFC-induced hiatus soon (BattyBot Task 25, are you out there?) or awaiting BRFA approval (Monkbot's various tasks). Once those bots make a couple of passes through those two categories, we should expose the remaining error messages.

The "displayauthors" category has been traversed by Citation Bot, which has fixed as many errors as it can. The category is down from about 10,000 entries to under 500. I think that error should be displayed.

The "displayeditors" category is awaiting an update to Citation Bot's code, which has been requested via a bug report. – Jonesey95 (talk) 22:14, 5 April 2014 (UTC)

I believe many of the "cite web with missing URL" entries are likely to be references where a dx.doi.org URL has been bot replaced by a |doi= parameter and the template was not changed to the more appropriate "cite journal" version, or whatever, at the same time. Likewise for many of the "format requires URL" errors. I might be wrong though.

Where a bot removes |url= it should also remove other parameters that can only be present if |url= is present. -- 79.67.241.229 (talk) 23:11, 5 April 2014 (UTC)

• Oppose more red messages. I have explained below how the red-error messages have left errors in thousands of pages for months/years (viewed up to 5 million times before hand-fixed), see reply moved to "#No more red-error messages" below. -Wikid77 07:27, 9 April 2014 (UTC)

No more red-error messages

Tracked in Phabricator
Task T7984

Tracked in Phabricator
Task T23798

Tracked in Phabricator
Task T56906

• No more red-error messages: After years of showing various types of the red-error messages to all users via Template:Convert or the wp:CS1 cite templates, the evidence is conclusive that such messages do not cause readers to fix pages when left for months/years (or viewed over 300,000 times, as page "Vladimir Putin" in 5-13 March 2014), and even several experienced editors have edited many pages leaving red-error messages still visible for the year. There was even an RfC to re-hide such red-error messages in the wp:CS1 cites as being a distraction for the readership. Therefore: After years of trying to get people to fix pages by showing numerous, clarified, red-error messages with help-page links of how-to explanations, the whole tactic of showing red-error messages has been shown to be a total failure of communication to get problems fixed in pages. In fact, numerous editors have fixed many cite errors faster by following the tracking categories and searching for "unknown parameter" or such, rather than viewing pages until a red message appears somewhere. Hence, the red-error messages can capture a reader's attention, but they do not cause readers to fix the errors which should be handled by Bots or by autofixing instead, to clear errors in recent updates and archives and talk-pages, all with the same rapid autofixing. -Wikid77 (talk) 18:53, 8 April 2014, 05:49, 10 April 2014 (UTC)

If I see a red error message as I preview an edit, especially if I have just caused the error message to appear, I usually fix it before saving the page. Error messages should be shown when previewing a page otherwise the amount of errors may rapidly increase. On one page, I recently fixed a number of invalid |authorlink= parameters. However, as an experiment to see how long it would take, I left six references needing the document title to be filled in. It took 68 edits from 45 different users (and around 60 000 pageviews) before someone fixed four of the titles. The other two remain broken. -- 79.67.241.252 (talk) 19:19, 8 April 2014 (UTC)

The supposition that editors are unwilling to fix red error messages because people do not do so over a large number of edits to a page is flawed. The issue is not that having red error messages is a failure. It is that there is a failure to display such errors at the time when they can and would be fixed. Such errors are not shown anytime only a section of the page is edited and previewed. In order to see those errors you have to either be editing the entire page, specifically looking for the error, or have set up and enabled Anomie's Ajax Preview which shows references while previewing a section. Further, even when just reading a page in order to see the errors one has to go looking for them.

How many readers/editors scroll through the sometimes huge list of references just to read them? I know I do not. If I am reading a page and am interested in a reference, I just move the mouse to hover over that specific reference link. A popup window then shows that reference and that reference only. I then click within that popup to go to the reference. While reading, rarely do I actually click on the reference tag to visit the entire reference list.

There is a discussion at VPP at which Wikid77 has raised this issue within the context of a larger question. There are multiple tracked bugs, some of which will certainly be fixed which will at least partially, address this issue. Getting the word out about the existence of Anomie's Ajax Preview to editors will probably also help. — Makyen (talk) 22:12, 8 April 2014 (UTC)

Just for the record, I believe that red error messages sometimes cause editors to fix article references. I am presenting just as much conclusive evidence as was presented by the original poster. – Jonesey95 (talk) 22:24, 8 April 2014 (UTC)

Many of those cases could be autofixed, with no need to edit the page, and no need to issue a red-error message. Where the cite data is undecipherable, then a simple note "[fix cite]" plus a link to a severe-error cite category would be sufficient. By autofixing the cites, then the severe cases can be isolated to separate categories, to enable faster fixing by cite experts. However, I do see not a problem with a lead zero "0" in a date "07 May" and 50,000 such dates could be autofixed to show "7 May" without a red message. -Wikid77 07:27, 9 April 2014 (UTC)

As above, the date errors are a straw man. Date error messages are not displayed to readers unless they have specifically changed their preferences to show those errors. I'm trying to engage in discussions about this opportunity under an assumption of good faith, and I have provided actual data about articles above. Unqualified assertions that "Many of those cases could be autofixed..." and "evidence is conclusive..." without data are not helpful in advancing this discussion. I am willing to be persuaded, but so far I have seen nothing to persuade me that efforts in the autofix direction are better than the current system of fixing with bots and human editors. – Jonesey95 (talk) 13:10, 9 April 2014 (UTC)

• Evidence of failure of red-errors to fix pages: As evidence, note how page "Theta" had shown "Unknown parameter 'book=' ignored " for 5 months (since rev. Nov 2013), but the cite error was left during 151,000 pageviews. Today, I fixed page "Modern Healthcare" which had a flood of 7 red-errors (from years ago) viewed over 4,800 pageviews (see old: rev-4839), where "_accessdate=" was appended after 7 agency names. Other pages also exemplify the problem: a page can be viewed thousands of times, while updated many times, but a red-error message does not cause readers to fix the error, so don't show it. -Wikid77 05:49/15:05, 10 April 2014 (UTC)

• Autofixing author, title, url or extra data: Remember, while the red-error messages have been left in pages for months/years during 2013-2014, the current autofixing can handle many previously garbled cite parameters; compare:

{{cite web |tittel=Title |work=Essays |lats=Doe |first=John |date 3 May 2011 |pages=3--4|ACME Print|web=http://z |edit1-lasst=Smith |editor1-first=Jane |paragraph=6 |lociation=London}} autofix: current: Essays. pp. 3--4. {{cite web}}: |editor1-first= missing |editor1-last= (help); |first= missing |last= (help); Missing or empty |title= (help); Missing or empty |url= (help); Text "ACME Print" ignored (help); Text "date 3 May 2011" ignored (help)

Note the extensive autofixing of title (from "tittel="), author ("lats="), url ("web"), date ("date 3 May") and editor ("edit1-lasst"), plus showing "paragraph: 6" to allow a reader to check the cite to verify the sourced text against paragraph 6. -Wikid77 (talk) 07:05, 10 April 2014 (UTC)

Not this again. You've raised autofixing at the village pump as noted above, at Template talk:Location map, at Wikipedia:Autofixing cites and its talk page , at User talk:Jimbo Wales‎ twice and here once before. Meanwhile your template has been thoroughly discussed and userfied without redirect. Nowhere has there been any support for your solution. It's gone well beyond the bounds of forum shopping already. Please give it a rest.--JohnBlackburne^words_deeds 21:39, 10 April 2014 (UTC)

Why would multiple "fix" notes, and mangled punctuation, as in "pp. 3–4. ^{[fix date][fix cite]}; ACME Print; ^{[fix title]};" that hardly anyone will ever notice and fix, be preferable to a red note that attracts the attention of gnomes? There may not be many of us, but its pretty uncommon for me to edit an article (that even bothers to cite sources <sigh>) and not check some citations for cleanup. I have to agree the suggestions everywhere Wikid77 raises this issue that the "smarts" involved in his code are better suited to a bot or AWB script or something that people can use to go fix things. "Fixing" them by making guesses as to the intent and then adding more "fix me" notes is throwing the baby out with the bathwater. Or trying to drown more babies in the same bath, or something.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:54, 13 April 2014 (UTC)

Because autofixing provides several advantages: The autofixing is preferable to a red note because it removes that distracting note while auto-correcting the cite to show author, title, url-link, date (etc.), with no need for a gnome or other user to alter the cite for years or decades, and as such, the small note "^[fix cite]" is indeed a minor reminder that the cite parameters have been adjusted. In many cases, the issue of "making guesses" is a no-brainer, and the autofixed correction is obvious due to typical misspellings of parameters, but the great benefit with that is the detection of mangled phrase parameters, as a separate category, to help focus human effort on fixing garbled cites which require expertise, while hundreds of trivial typos are autofixed and do not need human intervention to cite the intended source document. In cases where human editing is rejected, such as in archived AfD or Arbcom discussions, then the autofixed cites will link to suggested sources without altering the archived page history. As for "throwing the baby out with the bathwater" (no), instead the autofixing is more like automated draining of a bathtub by pulling the plug, with indoor plumbing, rather than hauling a washtub to be emptied. In general, autofixing is a type of automated technology, to make citing sources easier, with instant correction of typos. -Wikid77 (talk) 21:50, 19 April 2014 (UTC)

No it doesn't provide several advantages, as has been explained to you many times. But we've had the discussion and consensus was to userfy, and so to not use autofixing. Since then you've been pushing this almost continuously and got little interest and even less support. Please drop it.--JohnBlackburne^words_deeds 22:13, 19 April 2014 (UTC)

Cite web or accessdate without URL

Currently, using the cite web template requires a url or an error message is issued to those who have the messages turned on. Likewise a URL is expected whenever the accessdate parameter is present. But I came across an edit where an editor had added information from a source behind a paywall. I might face the same problem; I have access to some paywall sources through my library, but the access is explained by library personnel as clicking on a link on the library home page, then giving the password, and then searching for the source. If I give the URL from my address bar at the time I'm viewing the source, and then try that URL from a different computer, I get a page asking for a userid and password, but no one at the library seems to know the userid. So it would be rather useless to provide the URL.

It seems to me we should provide some advice about this situation. If the paywall operator is reliable and we viewed an exact copy of a paper publication, I suppose we could just give the information about the paper publication that we viewed online, and not mention that we viewed it online. But if the source is an electronic-source, subject to silent revision, we should provide an access date. What, then, do we use as a URL? The homepage of the paywall operator?

Courtesy also comes into play. If the paywall operator has in some way given support to the writing of the article, for example, by giving accounts to selected Wikipedia editors, or to another charity, it might be appropriate to acknowledge in some way that the information was accessed through the paywall. Jc3s5h (talk) 17:47, 5 April 2014 (UTC)

I believe this is why we have |subscription=yes. I could be misunderstanding you or just plain wrong, though.

I think it makes sense to provide the URL. Using {{cite web}} without a URL at all doesn't make sense. If it's a web-based source, it should have a URL. If your research librarian has access to the source, someone else's research librarian may have that same access. A reader who is desperate to locate that source can show the URL and other citation content to a savvy librarian and ask for help.

If another editor can provide a more open URL for the same source, that editor can do so, which will benefit readers.

Long-winded TL;DR part of this answer: In any event, these categories are like some of the other CS1 error categories, in that we have (or had) suppositions about the proportion of errors that were of one type or another. The steps in determining how to deal with the category, in my experience, are (1) do a bunch of edits and make a mental checklist of the sorts of errors you find and how to fix them, (2) if possible, develop scripts or bots to make common fixes, (3) run through the whole category and fix the straightforward problems using scripts or hand-editing, (4) examine the remaining citations to determine if the module code needs to be changed, to ask for a consensus-based way to fix the remaining errors, (5) modify documentation to help editors make fewer errors, and (6) recruit ReferenceBot to notify editors who create new entries in the category. – Jonesey95 (talk) 00:44, 6 April 2014 (UTC)

The parameter subscription=yes is fine if the url will bring a scriber to the source. But if the url won't bring a subscriber to the source, then the url is useless. Jc3s5h (talk) 02:37, 6 April 2014 (UTC)

Is there a "permanent URL" link at the place where the source is? - Purplewowies (talk) 03:51, 6 April 2014 (UTC)

The paywall operator is Gale; I took a closer look at the URL in the address bar while viewing the text of the sources. I discovered what the userid of my libary is, I also found that the library's userid is embedded in the URL. There are differences in the URL when the source is revisited, so there are no permantent URLs. Jc3s5h (talk) 13:20, 6 April 2014 (UTC)

• Some paywalls allow partial viewing to verify intro: There are currently cites using some paywall urls which will display part of the linked webpage, to at least verify the intro of the article matches the cite, and in some cases, the partial intro section contained the text needed to verify the sourced text. So, as with the general rules, "less is more" and we should remove any preconceived restrictions about paywall access, as with users who purposely leave out some author first-names perhaps to simplify listing extra authors as just "last3=" and "last4=" etc. We need to avoid further "instruction creep" by omitting unusual rules which have also cluttered the template documentation with more wp:rulespam. -Wikid77 (talk) 18:22, 8 April 2014 (UTC)

Date v. Year on drop down cite book template in edit window toolbar

I see from discussions above that "date" and "year" have been discussed. At some point, the standard "year" was dropped from the Cite Book template and replaced with "date". Ergo, when one uses the drop down template on the edit window toolbar, "date" is the only option available. This creates citation error issues with functions such as Shortened footnotes that only work correctly with years. After using the template, the user then has to manually change the word "date" to "year" for that to work. A big pain in the behind if an editor is creating an article with a hundred or so citations. And not every editor has enough experience to know it needs to be changed. If they don't manually correct it, the errors remain in referencing until such a time as another editor happens to run AWB, or just stumbles across it and manually corrects it. Or not. Can we please include "year" as a standard "fill in the blank" on the cite book template?— Maile (talk) 13:19, 8 April 2014 (UTC)

That isn't how it is supposed to work. {{cite book}} is handled by Module:Citation/CS1. In that module, the year portion of a CITEREF anchor is extracted from either |date= or |year=, when both are present, the year portion of the CITEREF anchor comes from |year=. If the value in |date= is invalid, then the year is not added to CITEREF.

Can you give me an example of where this is failing?

—Trappist the monk (talk) 13:40, 8 April 2014 (UTC)

I understand you want examples. Why was "year" removed from the templates? Was it causing a conflict? Mindful, that I am specifically talking about the cites used in conjunction with templates for SFN, Harvrefs, etc.

Please refer to Help:Shortened_footnotes#Date. The in-text cite should include only the year. The full citation may include the year only or the full date. Most citation templates will extract the year from a full date to form the anchor. If both a date and a year are included, then the date is displayed, but the anchor is formed from the year. Regardless of what that says, the cite templates do not pull the year from a full date with shortened footnotes.

Even before "year" was removed, if I tried to use shortened footnotes with only "date", it essentially told me the SFN is not pointing to anything in the bibliography. I cannot give you a specific example right now. And you might need to install User:Ucucha/HarvErrors to see the error messages. But even without that installed on your .js, if you are looking at a reference section with shortened footnotes template, when you click on one of them, they are supposed to jump to the cite in the bibliography section. If they don't, it's an error. Whether it's supposed to or not, not having "year" will trigger an error. SFN and Harvrefs have "year", and if the cites don't have "year", SFN and Harvrefs don't know what to look for and point to nothing. I have run across this innumerable times. — Maile (talk) 14:13, 8 April 2014 (UTC)

My experience has been the opposite. Using something like |date=2001 or |date=3 May 2002 within cite templates has worked fine for me in conjunction with {{sfn}} (use only the year within the sfn template). That's why we're hoping for examples, so that if there is a subtle bug, we can fix it.

I have the HarvErrors script installed, so if you point me to an article where this is not working, I'll take a look at it.

Here's an example of a shortened footnote that uses the year from a date.

Sources

• Brown, Philip (2004). Title. {{cite book}}: Invalid |ref=harv (help)
• Smith, William (2 May 2001). Title. {{cite book}}: Invalid |ref=harv (help)
• Xavier, John (June 2006). Title. {{cite book}}: Invalid |ref=harv (help)

These three footnotes all work perfectly for me. – Jonesey95 (talk) 14:29, 8 April 2014 (UTC)

Interesting. Next time I run across this, I'll post the example here. In the meantime, no one answered my question of why "year" was removed from the templates. — Maile (talk) 14:35, 8 April 2014 (UTC)

|year= has not been removed from any of the CS1 templates. It is still a valid and active parameter.

—Trappist the monk (talk) 14:39, 8 April 2014 (UTC)

Do you use the edit window Toolbar that has a drop down for the cite template? Year disappeared from cite book (or Book citation) template when accessed from that drop down. Where "Year" used to be, it now says "Date". "Show extra fields" does not have "Year". Cite web has "Year". Neither cite news nor cite journal has "Year", however I never used "Year" with those, so maybe they never had it. — Maile (talk) 17:35, 8 April 2014 (UTC)

Maile,in the "Preferences" window that can be accessed by clicking "Preferences" at the top of the page, in the editing tab, there are two relevant check boxes, "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar". Which of these do you have checked? ???? — Preceding unsigned comment added by Jc3s5h (talk • contribs)

I have them both checked. But the one I'm referring to is RefToolbar/2.0. The "cite" selection in the upper right is what hides or displays the template drop down on the left. And in response to IP below, my concern is not the layout of anything except the disappearance of "year" on the cite book selection. That's a fairly recent change. I would say within the last few weeks. — Maile (talk) 18:07, 8 April 2014 (UTC)

The layout of those form fields is terrible, still contains deprecated stuff like coauthors and has absolutely no clarity on when to use last/first and when to use author. Most of the forms have little or no support for multiple authors. A number of essential fields are also hidden away behind the "show extra fields" button. -- 79.67.241.252 (talk) 17:48, 8 April 2014 (UTC)

Thanks, everyone, for the detailed detective work. It looks like the proper venue for continuation of this discussion is Wikipedia_talk:RefToolbar/2.0, since the toolbar, not the cite templates themselves, is presenting a limited set of parameters to editors.

Again, if anyone sees a citation using |date= that does not properly link to an sfn or harv template, feel free to post a link to an article or a sandbox test case here. – Jonesey95 (talk) 22:37, 8 April 2014 (UTC)

I don't really see a need to fracture the discussion. |year= was removed from the toolbar because it is supposedly redundant to |date=. Is it not? Mr.Z-man 23:39, 8 April 2014 (UTC)

I believe |year= is surplus to requirements as I explained at the other conversation.

—Trappist the monk (talk) 00:55, 9 April 2014 (UTC)

I temporarily turned on "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar". I found that the toolbar provided a mechanism to insert free-form footnotes. It also provided a way to insert citation template footnotes. It did not provide a mechanism to insert a reference list entry ready-to-go with short footnotes or Harvard citations. Before the toolbar citation would be usable, the editor would have to remove <ref> and </ref> and add |ref=harv. Perhaps the non-working cases that user:Maile66 complained about were a result of the editor not correctly modifying the output of the toolbar. Jc3s5h (talk) 13:30, 9 April 2014 (UTC)

So that people know: AWB currently changes parameter |date= to |year= in all citation templates when the value of the parameter is only a year as part of the General Fixes. This means that thousands of articles have been changed to using |year= instead of |date=. If this is not what CS1 desires, the general fixes need to get changed. — Makyen (talk) 02:25, 11 April 2014 (UTC)

Proper use of parameter?

Is this how the |website= or |work= parameter was envisaged to work? If not, what can be done about it? -- Ohc ^¡digame! 02:33, 9 April 2014 (UTC)

I don't think so. Thanks for fixing it. The documentation for |website= in {{cite web}} and for |work= in Help:Citation Style 1 says nothing about urls in this parameter. I don't think that it would be too hard to add error checking for urls in these parameters as we've done for urls in |authorlink=.

—Trappist the monk (talk) 12:35, 9 April 2014 (UTC)

It's easy enough to build in a rule to strip the url down to domain name for |work= and |publisher=, but I fear an avalanche of false positives if I include "website" in the regex. -- Ohc ^¡digame! 06:34, 10 April 2014 (UTC)

The documentation states "title of website" and I think that is pretty clear. --  Gadget850 ^talk 12:39, 10 April 2014 (UTC)

External link icons

It appears that external link icons will be removed in the next update. The PDF icon is set locally by a rule in MediaWiki:Common.css and there is discussion on removing it. See MediaWiki talk:Common.css#External links icons removed. I bring it up here, as many editors believe the icons are added by the templates. --  Gadget850 ^talk 12:43, 10 April 2014 (UTC)

ORCID, redux

A year ago, we discussed using ORCID in citations, as an identifier for authors. Are we now in a position to do so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 10 April 2014 (UTC)

As noted ORCID is a subset of International Standard Name Identifier. Where are we going with that? --  Gadget850 ^talk 16:55, 10 April 2014 (UTC)

Yes, but ORCID and ISNI are separate schemes (and separate parameters in Wikidata). Some people (me, for example!) have one of each. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 10 April 2014 (UTC)

I guess I don't understand how an ORCID number aids a reader in locating the resource specified in the citation. Taking Editor Andy Mabbett's ORCID number as an example, and assuming that the article "A salutary lesson in the perils of inflation" supports a salient point in a Wikipedia article, an editor might write the citation this way:

{{cite web |url=http://birdguides.com/webzine/article.asp?a=1490 |title=A salutary lesson in the perils of inflation |last=Mabbett |first=Andy |website=BirdGuides |date=14 November 2008}}

→Mabbett, Andy (14 November 2008). "A salutary lesson in the perils of inflation". BirdGuides.

Simple, and correct; does the job. If the editor adds the author's ORCID to the citation, perhaps using |id= (NOT recommended because it violates the definition of |id=), we get this:

→Mabbett, Andy (14 November 2008). "A salutary lesson in the perils of inflation". BirdGuides. ORCID 0000-0001-5882-6823.

Show me how the addition of the author's ORCID has helped me, as a reader, confirm that the information in the Wikipedia article is supported by the cited work?

—Trappist the monk (talk) 18:21, 10 April 2014 (UTC)

Let's say the source article is in a journal that is not available for free online, but the journal does allow authors to put copies of their articles on their personal websites. Using the ORCID, we may be able to locate the author's personal website, which may contain a free copy of the article. Jc3s5h (talk) 18:51, 10 April 2014 (UTC)

With the article title and author's name, any one of the internet search engines may be able to locate a free copy of the article also. If the free copy on the author's website is the same as, or substantially similar to, the journal article (the two may not be the same because of revisions, editorial choices, etc), an editor might use the author's copy as the source for the Wikipedia article and cite that. If the two are different, an ORCID link in a citation implies an imprimatur that might or might not be appropriate. If a reader uses a search engine to find a copy of the article, no such implication exists.

—Trappist the monk (talk) 11:01, 11 April 2014 (UTC)

The use of an ORCID identifier implies nothing than the precise identity of the author. Please let's not have any more such FUD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 14 April 2014 (UTC)

Further to Jc3s5h's sensible observation, the functions of ORCID include:

1. To disambiguate the work of two authors with the same name (A salutary lesson... is not written by the hypothetical namesake Andy Mabbett who wrote Navel fluff collecting for beginners)
2. To unify all the works by one such author (it was written by the same Andy Mabbett who also wrote "Pink Floyd - The Music and the Mystery")
3. To unify the works by one author under different names (this work attributed to Cassius Clay is by the same person as that work attributed to Mohammed Ali)

Once those things are possible, it's easier to compare and evaluate statements in different citations (for example, if Jane Doe's 2014 work contradicts Jane Smith's 2013 work, that may be a clash of opinions, or just one author may have changed name and then found new information), find other articles that cite the same work, find works by an author cited in other articles (perhaps under other names), and so on. It also allows editors to easily find other works by a cited author, which may be useful as extra sources, and even perhaps suggest new articles.

Regarding formatting, I envisage a time when the author name will (if it does not link to a Wikipedia article about the author) link to a Wikidata entry or "Special:ORCID" page (like Special:ISBN) listing all the articles where we cite works by that author - but let's not run before we walk. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 10 April 2014 (UTC)

[Aside: I'd encourage every Wikipedia editor who exposes their real identity to register for an ORCID, and to list their "Special:Contributions" page on their ORCID profile as a work; with the ORCID in the {{Authority control}} template on their user page) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 10 April 2014 (UTC)]

Citations are about the source, not the author. In CS1 we have |authorlink= and |editorlink= to provide easy access to a Wikipedia article about an author or editor and that article is the place for an ORCID link.

All of the reasons for the existence of ORCID that you have enumerated are valid and legitimate reasons. But not in a CS1 citation. The purpose of a citation is to identify the source that supports the article. None of the reasons for ORCHID's existence help to identify the source that supports the article. Disambiguation of authors and unification of their works is a subject outside the essential purpose of a CS1 citation.

—Trappist the monk (talk) 11:01, 11 April 2014 (UTC)

|authorlink=, |editorlink= and |url= are all convenience links and not essential to the identification of the citation; the manner in which the links are created do not overwhelm the citation.

Adding ORCID to the end of the citation disconnects the ORCID from the author name it is supposed to amplify, especially where there are multiple authors.

If we add ORCID, I suggest it replace and override |authorlink=, not add an identifier that does not directly identify the article. --  Gadget850 ^talk 12:57, 11 April 2014 (UTC)

That's fine when we have an article about the author; and I said above that we should use them, But most cited authors are not the subject of a Wikipedia article. Disambiguating the identity of a work's author is "about the work". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 14 April 2014 (UTC)

Abortive attempt at creating subtemplate; now deleted

Alternative solution: While Gadget850's observation about convenience links (more generally) is true, I find Trappist's reasoning pretty solid; yet if there's one real use case for this stuff, it's Mabbett's that authors (especially later-married women) can change names, and lead to false assumptions that sources conflict when really a source author revised. If we added ORCID stuff, I would suggest it should be a small-as-possible link attached to the author name, and I've created a template for this at {{orcid}}. Usage example: Mabbett, Andy{{orcid|0000-0001-5882-6823}} (14 November 2008). "A salutary lesson in the perils of inflation". BirdGuides.{{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link) In order to make it compatible with authorlinks (authorlinks1, etc.), it would have to be done with, say, a set of after1, after2, etc. parameters tied to the author/first/first1, first2, etc., parameters. This makes more sense than hard-coding ORCID stuff into the citation templates; just have these be free-form so that {{orcid}} can be used there, or just a link to the author's site, or a "[of Germany, not to be confused with author of same name from Canada]" note, or whatever consensus decides is needed for the citation in question at that article. It's way more important and useful for an authorlink to be used than an ORCID link when the former is available, because this helps readers get a feel for who the writer is as judged by the public, vs. as self-promoted by the writer's website or whatever else the ORCID would lead to. So, the suggestion above to actually override authorlink with a new orcid parameter, when both are specficied, would be objectionable.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:40, 13 April 2014 (UTC) I think that {{orcid}} should not be used in CS1 templates that produce COinS metadata. Here is the HTML output from the Mabbett citation without {{orcid}}: '"`UNIQ--templatestyles-0000008D-QINU`"'<cite id="CITEREFMabbett2008" class="citation web cs1">Mabbett, Andy (14 November 2008). [http://birdguides.com/webzine/article.asp?a=1490 "A salutary lesson in the perils of inflation"]. ''BirdGuides''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=BirdGuides&rft.atitle=A+salutary+lesson+in+the+perils+of+inflation&rft.date=2008-11-14&rft.aulast=Mabbett&rft.aufirst=Andy&rft_id=http%3A%2F%2Fbirdguides.com%2Fwebzine%2Farticle.asp%3Fa%3D1490&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> and the HTML output from the same citation with {{orcid}}: '"`UNIQ--templatestyles-0000008F-QINU`"'<cite id="CITEREFMabbett2008" class="citation web cs1">Mabbett, Andy<code>&#123;&#123;[[Template:Orcid|orcid]]&#124;0000-0001-5882-6823&#125;&#125;</code> (14 November 2008). [http://birdguides.com/webzine/article.asp?a=1490 "A salutary lesson in the perils of inflation"]. ''BirdGuides''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=BirdGuides&rft.atitle=A+salutary+lesson+in+the+perils+of+inflation&rft.date=2008-11-14&rft.aulast=Mabbett&rft.aufirst=Andy%3Ccode%3E%26%23123%3B%26%23123%3Borcid%26%23124%3B0000-0001-5882-6823%26%23125%3B%26%23125%3B%3C%2Fcode%3E&rft_id=http%3A%2F%2Fbirdguides.com%2Fwebzine%2Farticle.asp%3Fa%3D1490&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite web|cite web]]}}</code>: CS1 maint: multiple names: authors list ([[:Category:CS1 maint: multiple names: authors list|link]]) CS1 maint: numeric names: authors list ([[:Category:CS1 maint: numeric names: authors list|link]])</span> —Trappist the monk (talk) 21:04, 13 April 2014 (UTC) An ORCID will not lead to "as [sic] self-promoted by the writer's website"; if anything, it should lead to the page about the author on http://orcid.org, but, as I suggested above, that could be via a SPECIAL:ORCID page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 14 April 2014 (UTC) I speedied {{orcid}}, now {{ORCID-inline}}. Hadn't anticipated that metadata problem.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:31, 16 April 2014 (UTC)

Your example's location [^see collapsed section, above] of the ORCID after the author name rather than at the end of the citation is sensible (even more so when there are multiple authors); but there's no justification for a separate template; the author name is part of the citation template, and so should be the UID that disambiguates that name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 14 April 2014 (UTC)

Let me amplify my last comment. If we add |orcid=, then it should create a link based on the author name exactly like |authorlink=. |orcid= and |authorlink= should then be exclusive, with one overriding the other, thus you can link to either the ORCID or the author page, but not both. Again, this is a convenience. As to Special:ORCID, it does not exist, so discussion belongs on Bugzilla as a feature request — Preceding unsigned comment added by Gadget850 (talk • contribs) 13:25, 14 April 2014 (UTC)

ORCID and Wikipedia articles provide different kinds of information about authors. I don't accept as generally agreed that the only reason for adding a wikilink to an author is to help disambiguate the author. Thus the two parameters should not be mutually exclusive. Also, mutually exclusive parameters are confusing for editors; information just disappears from the visible citation for no obvious reason. Jc3s5h (talk) 13:00, 14 April 2014 (UTC)

The reason I suggested that we don't need to show the ORCID of an author about whom we have an article is that the ORCID should be shown on that article. But if others want it in the citation, I'd be happy with that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 14 April 2014 (UTC)

I've raised a ticket on Bugzilla, but meanwhile we can provide something of that kind on Wikipedia, say in the form of Wikipedia:ORCID/0000-0001-5882-6823, where I've created a mock-up. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 14 April 2014 (UTC)

Continuing

It seems to me that there are five decisions to make, in order:

1. Whether to use ORCID in citations
2. Whether the time is right to do so
3. How to record ORCIDs in citation templates
4. How to display ORCIDs in citations
5. How and to what to link those ORCIDs

We were in danger of becoming bogged down in 3 & 4, and possibly 5, before being clear on 1 & 2. I contend that the answer to the first two is "yes" and that we should now decide 3 (which is probably the most easy to resolve), before moving on to 4 and only after that is resolved, then 5. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:38, 17 April 2014 (UTC)

How might we move this forward, starting with my point 3? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 2 May 2014 (UTC)

Discussion of |accessdate= in another location

There is a discussion regarding |accesdate= at Help_talk:CS1_errors#Accessdate.

—Trappist the monk (talk) 11:01, 13 April 2014 (UTC)

Exact use for place/location?

I am currently having a small dispute with Sitush (talk · contribs) over whither the |location= / |place= field in {{cite news}} is meant to show the physical publication location of the newspaper (Sitush) or the dateline (my position). Sitush has cited Template:Cite news#Publisher as a source, but the description is ambiguous. I feel that Sitush's interpretation is meant more for {{cite book}}. Can someone settle this?--Auric talk 16:52, 13 April 2014 (UTC)

Consistency. If it were as you suggest then "location" for a book would be, for example, the house (cafe, in the case of J. K. Rowling!) where the author wrote the book but in fact it is always the location of the publisher. Location can always be ascertained for place of publication of newspaper stories, defaulting to the first-named if there are several, but the place of submission is often not given. - Sitush (talk) 17:03, 13 April 2014 (UTC)

The place of submission is usually given in the dateline.--Auric talk 17:08, 13 April 2014 (UTC)

I'd dispute that, too. More often than not, it is not given at all. - Sitush (talk) 17:26, 13 April 2014 (UTC)

Hence "usually".--Auric talk 17:41, 13 April 2014 (UTC)

No, "usually" means that more often than not it is in the dateline; I'm saying the opposite. - Sitush (talk) 17:47, 13 April 2014 (UTC)

We agree then. --Auric talk 18:02, 13 April 2014 (UTC)

I give up. You seem to be being deliberately obtuse now, sorry. - Sitush (talk) 18:12, 13 April 2014 (UTC)

No, I said that "The place of submission is usually given in the dateline", using usually to indicate that sometimes it is not. You replied, saying "More often than not, it is not given at all.", which means the same thing. Hence, we agreed.--Auric talk 18:24, 13 April 2014 (UTC)

(edit conflict) Traditionally, the location of a newspaper is given when it is not contain in the name of the newspaper. This is to aid a reader in finding a copy of that specific newspaper in library archives. The dateline for an article is practically useless for this purpose because it will vary from article to article within the same paper

To take an example from my hometown area, The Daily News is a newspaper published in Iron Mountain, Michigan, here in the US. There is also The Daily News that is published in Bowling Green, Kentucky, and The Daily News from Galveston, Texas. If I were to cite an article from the Iron Mountain paper that had a dateline of either Bowling Green or Galveston, readers would be confused as to which publication is the source of the cited article. What if the dateline listed was instead "Marquette, Michigan", which has no paper called The Daily News (the paper there is The Mining Journal)?

I hope this helps. Imzadi 1979 → 17:10, 13 April 2014 (UTC)

And Help:Citation_Style_1#Work_and_publisher.

—Trappist the monk (talk) 17:14, 13 April 2014 (UTC)

(edit conflict)Now I'm even more confused. As I understand it, the dateline is the location from where the article is submitted to be published in a newspaper. It has nothing to do with the location of the newspaper it is published in. Many newspapers use stringers for this purpose. --Auric talk 17:19, 13 April 2014 (UTC)

You've got the basic concept of a dateline correct, but in terms of citing an article, that location is not helpful for a reader to find a source. If I told you that the dateline location for an article is "Marquette, Michigan" for an event of national importance, and the newspaper is called The Daily News, would you look for the article in The Daily News published in Iron Mountain, Bowling Green, or Galveston? It could even be the Daily News from New York, which doesn't include the The in its name.

Just like for a book, the location given in a citation is the place of publication. If you're citing something like The New York Times, however, the location can be omitted because it is contained in the name of the newspaper. Imzadi 1979 → 17:45, 13 April 2014 (UTC)

(edit conflict)Actually, as I now understand it, the dateline is a holdover from the years of print-only newspapers, used to indicate that a story was created at or near the location of the event and was thus more accurate. The lack of a dateline would indicate that it was created at the newspaper offices. A reach-around is the use of news agencies and stringers. --Auric talk 17:58, 13 April 2014 (UTC)

I'm starting to think that maybe a |dateline= field could be added to prevent confusion.--Auric talk 18:27, 13 April 2014 (UTC)

We already have a way to handle both: |publication-place= vs. |location=. Compare:

• Pepin, John (April 12, 2004). "Frost Causes Gas Leaks". The Mining Journal. Marquette, MI. p. A1.
• Pepin, John (April 12, 2004). Written at Ishpeming, MI. "Frost Causes Gas Leaks". The Mining Journal. Marquette, MI. p. A1.

Adding both properly indicates the dateline location of "Ishpeming, MI" while still disambiguating the newspaper to "Marquette, MI". Imzadi 1979 → 18:37, 13 April 2014 (UTC)

Getting this discussion back to the question at hand, I pulled my copies of the APA and MLA style guides plus The Chicago Manual of Style.

• APA: the 6th ed. is silent on including locations for periodicals.
• MLA: "If the city of publication is not included in the name of a locally published newspaper, add the city in square brackets, not italicized, after the name: 'Star Ledger [Newark].' For nationally published newspapers (e.g. Wall Street Journal, Chronicle of Higher Education), you need not add the city of publication." (7th ed., §5.4.5, p. 141)
• CMOS: "A city name, even if not part of the name of an American newspaper, should be added, italicized along with the official title. The name (usually abbreviated) of the state, or in the case of Canada, province may be added in parentheses if needed." It then gives a list of names with "but Oregonian (Portland, OR)" and then "For such well-known national papers as the Wall Street Journal or the Christian Science Monitor, no city name is added." (16th ed, §14.210, pp. 741–2)
• AP Stylebook: "Capitalize the in a newspaper's name if that is the way the publication prefers to be known. ... Where location is needed but is not part of the official name, use parentheses: The Huntsville (Ala.) Times. (33rd ed., p. 140)

Our CS1 templates separate the name and location of a newspaper like the MLA style or the last example from CMOS. Both style guides ignore the dateline location because it won't help a reader find the source; datelines are specific to the article, they vary from article to article within the same newspaper, and are not going to help distinguish between two papers of the same name. Imzadi 1979 → 18:37, 13 April 2014 (UTC)

Ahhh, now I begin to understand. Thanks for clearing that up. The dateline is probably for the benefit of the newspaper then, not the reader, to help distinguish between articles with the same name. --Auric talk 18:59, 13 April 2014 (UTC)

Not really. "A dateline should tell the reader that the AP obtained the basic information for the story in the datelined city" is how the Associated Press describes it (AP Stylebook, 33rd ed., p. 57). The dateline is only going to appear inside a paper once you find the article to give the reader information about the article, but if you're going off a citation, you'll need to find the right paper called The Daily News first. Imzadi 1979 → 19:19, 13 April 2014 (UTC)

Okay, I see. Thanks for the clarification.--Auric talk 19:31, 13 April 2014 (UTC)

Work parameter (Template:Cite news)

I'm sure I'm not the only one here that has this problem. It seems that most of the people using this template do not understand the difference between the 'publisher' parameter and the 'work' parameter. The result is that many templates are filled out incorrectly, with the 'publisher' parameter filled instead of the more appropriate 'work'. Is there any way we could clarify this, perhaps by renaming the 'work' parameter to something more obvious? It is annoying to have to fix templates that have filled out incorrectly merely because of the vagaries of the parameters. RGloucester — ☎ 17:50, 13 April 2014 (UTC)

The aliases for |work= are |newspaper= or |magazine=. The documentation clearly says that |publisher= is for the company that publishes something and that |work= is for the name of the name of the published work. I don't know why people will get that the publisher is a company in the case of a book, but get confused on newspapers. Maybe they forget that an article is published in the Daily News and not published by the Daily News. I also find the same confusions with television networks like CBS (the publisher) and individual programs like 60 Minutes (the published "work" of the network). With the alternate parameter names already in place, I think the only way forward is to educate people and just fix their errors. Imzadi 1979 → 18:48, 13 April 2014 (UTC)

Yes. There's really no excuse for not acting like one cannot tell the difference between Apple Records and The Magical Mystery Tour. The only template code suggestion that might help is to add a |publishingco= parameter as an equivalent of |publisher= and change the documentation to stop mentioning the latter.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:48, 13 April 2014 (UTC)

I'd support that change. The parameter would be longer, but at least it would make it absolutely clear that 'publisher' is not the same thing as the 'work' it was published in. RGloucester — ☎ 13:59, 14 April 2014 (UTC)

To be clear, I also support such a change, as the nominator-of-sorts. This template already uses long-winded parameter names, so it's not a big deal. I'd like it if it also supported |pubr= for those of us with borderline carpal tunnel syndrome, but whatever. I know we can't keep adding duplicate parameters indefinitely.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:17, 16 April 2014 (UTC)

Rethinking accessdate

During testing of an AWB script to 'fix' accessdate CS1 errors (more), I began wondering if we shouldn't be rethinking |accessdate=, its application, and the rules for its use. So, some of the questions that I think need answering are:

1. Is |accessdate= correctly defined in terms of:

   a. its meaning?

   b. rules that govern when to use it?

   c. rules that govern when to display it?

2. Are the definitions above correctly and adequately documented?
3. Are we correctly handling citations that have |accessdate= but don't have |url=?
   1. No? What should we be doing with these citations?
4. Do we need a bot to sift through Category:Pages using citations with accessdate and no URL?

   Yes?

   1. What should the bot fix?
   2. What constitutes a fix?

I'm sure that there are other questions but these are enough for now.

—Trappist the monk (talk) 20:02, 14 April 2014 (UTC)

Good questions. To help with answering question 1, here's the current text from CS1 template documentation that explains |accessdate=

• accessdate: Full date when original URL was accessed; use the same format as other access and archive dates in the citations; requires url. Do not wikilink. Not required for web pages or linked documents that do not change; mainly for use of web pages that change frequently or have no publication date. Can be hidden or styled by registered editors.

Some thoughts:

• It seems clear enough to me, but is it "correctly defined"?
• I was unable to find an explanation of when the value of |accessdate= is actually displayed, except for the oblique "requires url".
• There is no reference to date verification.
• I believe that we are handling these citations as documented, though the documentation could be made more explicit.
• I believe that the bot should fix the citations described at Help_talk:CS1_errors#Accessdate in rules 1–8 by commenting out |accessdate=. – Jonesey95 (talk) 20:44, 14 April 2014 (UTC)

|accessdate= is only displayed when |url= has a value.

—Trappist the monk (talk) 00:03, 15 April 2014 (UTC)

Does the module only look at |url=, or are other places where a URL might be found considered?

Here is a non-exhaustive list of places where a URL might be found:

URL positions:

• bare URLS in, or next to the citation (some are placed next to citations; yep, not the way it is supposed to be, but it is done)
• |url=
• |chapterurl=
• |chapter-url=
• |contributionurl=
• |contribution-url=
• |archive-url=
• |layurl=
• |website= (Yep, again not supposed to happen, but it does)
• |deadurl= (Yep, again not supposed to happen, but it does)
• commented out URLs
• Any parameter in which the editor has placed a URL. example:

Fortescue, Sir John William (1915), A history of the British army, vol. 4 part 2, Macmillan and company, pp. 889–890 {{citation}}: |access-date= requires |url= (help) [Note: This example links to a source which should not be changing, but other citations link to changeable content.]

Keep in mind that all it takes is a missing | character and the |url= is actually in some other parameter.

Technical note: The module should be changed to have one piece of code that determines if a URL is present and set a flag variable. Errors are also inappropriately generated about the lack of |url= for the presence of |archiveurl= when a |chapterurl= or |contributionurl= is present. Probably also the case for |layurl=, but I have not tested that one. — Makyen (talk) 02:03, 15 April 2014 (UTC)

From the beginning, |accessdate= has only applied to |url=. A primary requirement in the original development of Module:Citation/CS1 was to keep its functionality the same as that of {{citation/core}}. Now that most CS1 templates have migrated from {{citation/core}} to Module:Citation/CS1 that requirement may be eased.

Would you have an access-type date for all of your list of urls when there are multiple occurrences in a citation? If only one |accessdate=, to which in your list of urls should it apply if there are multiples but not |url=? What about the automatic urls associated with the module-supported identifiers (bibcode, doi, pmid, etc)?

Anything inside HTML remark tags in a CS1 citation is not visible to Module:Citation/CS1. To change that behavior would require a change to Wikimedia parser. So, the commented out URLs item on your list doesn't apply.

—Trappist the monk (talk) 10:45, 15 April 2014 (UTC)

Concerning Template:Csdoc#url, it generally makes no sense to include an accessdate in a journal citation, even if a url is present. Articles that are published in journals must by definition have been published on a specific date and with rare exceptions, the content is frozen and does not change over time. If a publication does not have an original publication date (year + volume + issue + page number), it wasn't published in a journal. With or without a url, I generally delete accessdates in cite journal templates on sight. Hence if a journal citation contains an accessdate without a url, I think the accessdate can be safely be deleted. Boghog (talk) 20:50, 14 April 2014 (UTC)

Bohog's comment is true of print journals. However, cite journal has long been a synonym for cite news. Both news outlets and journals are now online, so there is a greater potential for changes to content, especially for news media. Another issue is that editors may not think to use cite web rather than cite journal when citing material on a journal website that is not a "paper", for example, a style guide for the journal. Jc3s5h (talk) 21:54, 14 April 2014 (UTC)

Given that it appears people have not, and will not, follow the link to the other discussion, I am re-posting an edited version of comments I made there (it is a bit TL;DR 8-) ):

I object to |accessdate= being deleted on any citations.

1. I regularly use access date information, even those on material which is supposedly unchanging (e.g. books, PMID, DOI, etc). |accessdate= provides a hint as to when the citation was entered on the page. Generally, this means that the person who added the citation believed that the reference supported the text at that point. While this may, or may not, be accurate, I routinely use access dates to prioritize which references need to be checked to verify that article content is still supported by the citation. Using it in this way is, of course, imperfect. However, there really is just not enough time in existence to do all the checking which really should be performed. This is one piece of information which can be used to help determine where to spend limited time.
2. I have also found that |accessdate= is useful in attempting to determine to what a reference actually is referring. We all know those references that have inaccurate or corrupted information. Sometimes the citation is copied from page to page with errors/vandalism – I recently fixed one that had the same error on 34 pages across 7 wikis which appeared to be the result of copying a vandalized citation. All information we have, including |accessdate=, is potentially valuable in such situations. In that specific instance having the |accessdate= helped me identify which citations had been copied from page to page and which were valid. This would have taken much longer without |accessdate=.
3. |accessdate= can provide a hint as to the time-frame of the actual date of the reference when that is not included with the citation.
4. It also can be used to eliminate some possibilities of what the reference is (A citation can't refer to a reference created after that date).
5. |accessdate= is also useful as one of the quick sanity checks for a citation: Is |accessdate= before |date=? If so, that citation needs to be checked.
6. In addition, I have used |accessdate= as an indicator that someone has merely copied a reference from one page to another. This can indicate that the person may have not bothered to read the actual reference which may imply that a closer examination of if the reference actually supports the text is appropriate. If the |accessdate= does not closely match the date when the citation was added to the page this can indicate that the citation was not actually checked by the editor who put it in the article.

Let's not delete the information just because some people feel it is not useful, to them, on a citation that is correctly formatted, not corrupted by vandalism and has not been copied from page to page.

Why is having an access date actually bad in any of these situations? Is it just that people feel it is not useful, for them right then? It's not like we have a limited amount of space on a page and we need to trim all information which is not critical.

I see no reason to consider that having an |accessdate= without a URL is inherently an error, let alone that the |accessdate= should be deleted for that reason. I can understand the converse of a URL without access date being an error. I can understand not requiring an access date for most references without a URL (i.e. ones which refer to physical objects).

It is not reasonable to consider it an error to have an access date when the reference does not have a URL where other information in the citation implies that what is being referenced is not primarily on the web. In such case, the access date is information that is helpful in some situations, but not required. It is reasonable to give a warning that someone should check the citation and verify that a URL is not supposed to be there and disable the warning (perhaps with something similar to |ignore-isbn-error=true). Alternately, just have the module not flag having an |accessdate= without a URL to be an error if there is a valid ISBN, DOI, or other ID that leads directly to a permanent, unchanging reference.

The existence of the "error" is not to indicate that having the access date is wrong. It is to indicate that having an access date makes it likely that the person forgot to enter a URL when a URL is what is being referenced. The solution to citations being erroneously classified as this type of "error" is not to get rid of the access date information. The solution is to change the module so that it does not report most of the cases mentioned in the list of tasks (elsewhere), where additional information that the module has (e.g. valid ISBN, DOI, etc.) indicates that a URL should not be required. Additionally, there should be a way to directly inform the module that a specific instance has been checked and |accessdate= without a URL is not something that needs further attention (e.g. a |no-url-is-ok=true)).

It appears to me that people may be coming at this from the wrong point of view: See error..."fix" in easiest way possible. The easiest solution for an editor is to remove the |accessdate=. For us, there are more appropriate ways to solve a large quantity of these "errors". I think one reason people are concentrating on removing |accessdate= is that the text of the "error" leads their thinking in that direction. The "error" should have different text which concentrates on the lack of a URL, not the presence of |accessdate=. The error text should be something along the lines of: "Is there a missing URL? Add |no-url-is-ok=true if URL is not missing." instead of what is currently displayed.

All of the templates are increasingly used to refer to online versions of documents instead of physical copies. They are (all?) used to actually refer to websites with and without URLs being included. It would only be reasonable to comment out/delete |accessdate= if you can actually verify that there is enough valid data to indicate that the source really is a physical paper copy of an article. Doing so in such instances would ignore the other uses for |accessdate= data.

For a large portion of citations currently in the error category, the right solution is for the module to not report the missing URL error when enough information is there to indicate a valid physical source, or "permanent" electronic location information (e.g. valid ISBN, valid DOI, valid arXiv, etc.). The module should also be changed to: 1. have a parameter which can be added to the citation to indicate that a URL is intentionally not present; 2. report the "error" in a manner that more clearly indicates that the issue is a potential lack of a URL, not the presence of |accessdate=. — Makyen (talk) 02:03, 15 April 2014 (UTC)

I'll attempt a partial answer to the questions in Trappist's post that began this thread. An accessdate should be specified for content that was obtained from a source that is accessible through the World Wide Web, and similar protocols (for example, Gopher) if and only if the source

1. lacks a publication date OR
2. is likely to disappear and be difficult to locate OR
3. is likely to be altered

The first choice for the URL is the URL that is visible in the browser address bar while reading the source. If this isn't feasible, for example, with a pdf, the second choice is a URL that will download the source, will display download instructions, or which contains a link which can be clicked to download the source. Third chhoice: if the procedure for accessing the source is more complex (for example some paywalls), the URL should be a page from which the source can be navigated to; after the close of the CS1 template (but before the &ltref> element, if applicable) the navigation directions should be given. Jc3s5h (talk) 12:27, 15 April 2014 (UTC), clarified 13:22 UT.

To clarify, do you mean:

• lacks a publication date OR is likely to disappear and be difficult to locate OR is likely to be altered

or do you mean:

• (lacks a publication date AND is likely to disappear and be difficult to locate) OR is likely to be altered

or do you mean:

• lacks a publication date AND (is likely to disappear and be difficult to locate OR is likely to be altered)

Not sure I understand your apparent exception for pdf files unless by that you mean the exception for those browsers that spawn Adobe reader either as a plugin or as a separate program. If that's the case, then, is it not true that the url of the pdf can be obtained with a right mouse click on the pdf link and then by choosing 'Copy link address' or some such similar action?

—Trappist the monk (talk) 13:13, 15 April 2014 (UTC)

I mention pdf files as a type where the URL of the file may not be visible while viewing the file. This would also often apply to Microsoft Word and Microsoft PowerPoint files. Jc3s5h (talk) 13:24, 15 April 2014 (UTC)

Is it necessary for a reader to see the file's url while viewing the file? And still, isn't it true that for a file not directly displayed by the browser, the file's url is available with a right mouse click on the file's link in the referring page? For example, there are pdf links on this PMC search results page. If I want the url of the pdf file for the article "By any name, female–female competition yields differential mating success", I can right click on the pdf link and get this url: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3199164/pdf/arr111.pdf.

This same applies to any non-native file type, right?

How does all of this apply to rethinking |accessdate=?

—Trappist the monk (talk) 14:18, 15 April 2014 (UTC)

Maybe I didn't word my post as well as it could be worded. The parameters, the automatic warnings, and any bots making fixes should all be in agreement. Much of what I wrote is intended as advice to an editor about which URL to include in a citation; if one URL will display the source directly while another will lead to a page where it could be downloaded by clicking a link, the former is preferable. From the display and bot-fixing point of view, we should hesitate to hide or remove the accessdate if we don't know what kind of source we are dealing with. Maybe it's a paywall where it's impossible to give a URL that will lead directly to the source; the editor didn't know what to do so left out the URL. A later editor may be able to supply a URL that is somewhat helpful. Jc3s5h (talk) 14:53, 15 April 2014 (UTC)

The issues about paywall sites are another reason to drop all restrictions about "accessdate=". -Wikid77 17:21, 15 April 2014 (UTC)

Opinions of accessdate restrictions

I think enough objections have been raised, above and in prior discussions, to reach a consensus now about the "accessdate=" parameter. Reply below. -Wikid77 17:21, 15 April 2014 (UTC)

• Support removing accessdate restrictions: Limiting accessdate has not worked. The day someone noted a URL can be linked within a page number, I knew immediately the accessdate should have no restrictions and always be shown. The alternative would be new parameter "show_accessdate_you_moron = true" and that would only confirm the contempt which many people feel about accessdate, when one angry user noted we should just offer an abbreviation instead, such as "acdate=". Always beware how intelligent people are judging Wikipedia, and try to act smarter, quicker. -Wikid77 (talk) 17:21, 15 April 2014 (UTC)

Unsure exactly what you are proposing but if removal of text "Not required for web pages or linked documents that do not change; mainly for use of web pages that change frequently or have no publication date." then I am in favour of deleting that phrase from the document and allowing it to be used without such restriction. Trying to enforce this is just ridiculous. Keith D (talk) 18:03, 15 April 2014 (UTC)

It sounds like Wikid77 and Keith D are in favor of displaying the value of |accessdate= in all cases and eliminating the current error message. Please correct me if I am misstating your position.

That leads me to wonder what harm would come from doing that. If someone wants to provide an accessdate for a book they found at the library, does that do any harm? I can't think of any. It may be extraneous information, but anyone who is looking at references on Wikipedia knows that they are going to run into all sorts of information that they do not need in order to locate the cited source. – Jonesey95 (talk) 18:52, 15 April 2014 (UTC)

One of the reasons that accessdates are everywhere is the result of click-through editing using Reflinks: some editors simply run it and click 'save' without amending anything. It always adds an accessdate. I wish editors would instead archive the reference and add archiveurl and archivedate instead. I find no use for knowing that a newspaper article published and archived on the same day was also accessed on the same day. Of course it was! -- 79.67.241.227 (talk) 20:22, 15 April 2014 (UTC)

Style guide that recommends access dates for reading a book? Anyone? --  Gadget850 ^talk 20:49, 15 April 2014 (UTC)

If one reads a first edition tome by a long-dead author, and then cites in WP what it says, the date on which it's read is entirely irrelevant. And it would be ludicrous to say that such a date was in any way meaningful. -- Ohc ^¡digame! 02:24, 16 April 2014 (UTC)

• Oppose I entirely endorse what 79.67.. said. This is an encyclopaedia, where the object is to be useful within meaningful confines. We should not go down the road of allowing something merely because it's "harmless". Despite the instructions urging restraint, we've already gone some way down the road in ubiquitous use of access dates without truly questioning their utility or labouring under some misguided notion of the potential use which few actually explore. This is something that automated tools like Reflinks have a lot to answer for.

  Whilst some editors might feel rather clever in second-guessing by applying logical and coherence checks, these checks are often not very determinant on the error. Do I want to spoil their fun? Hell no. But we need to remember access dates add an additional dimension that occupies a lot of server storage space whilst being, IMHO, rather shallow. This encyclopaedia, being a wiki, is prone to all sorts inconsistencies. Errors and vandalism happen and are often corrected by others. Maintaining these access dates is more trouble than is worth, as one can just as easily (or not) find alternatives or archived cites without them. OTOH, having these gives a false sense of security that a link can be found with a little diligence. Access dates are not palliatives for poor referencing practices. They should be removed in favour of urging editors to preemptively or systematically archive. -- Ohc ^¡digame! 01:51, 16 April 2014 (UTC)

• Support within reasons; maybe we need some limitations but more lax ones. Accessdates can be useful for non-web sources. Any source that may change should have an accessdate. Accessdates can also be used to indicate when a source was checked vs. when others sources were checked or when some other thing happened, and this can be useful information in determining whether source verification has been completed (i.e., in relation to a WP:V/WP:RS-related cleanup or dispute tag or discussion on talk page. Not all hardcopy sources have known publication dates. If someone has added a totally pointless accessdate , thenthat can be removed, and if there's an alleged reason for putting it back (maybe it wasn't as pointless as thought), that's a matter for discussion at that article, not a "never ever do this" decision made on some "Help talk:"-namespace page that only about ten of us pay any attention to.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:14, 16 April 2014 (UTC)
• "Any source that may change" is not a reliable source. "Access dates are not palliatives for poor referencing practices" make me reconsider the concept of access date altogether. --  Gadget850 ^talk 12:54, 16 April 2014 (UTC)

• The fact that a source may change does not reflect on its reliability, so long as the source exercises appropriate editorial control over changes. Jc3s5h (talk) 13:10, 16 April 2014 (UTC)

• Right. The entire WWW would have to be ruled out otherwise.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:07, 23 April 2014 (UTC)

• The APA style guide specifies that with online sources, the reference needs either a DOI or a URL with accessdate. Legal citations to online sources in Bluebook format use an access date with the URL. MLA now just specifies that if a referenced source is online, no URL is listed, but the accessdate is listed after "Web" as the descriptive label. Chicago doesn't require access dates, and instead it suggests archiving copies of sources, but it does allow them where publishers or instructors require them. But as SMcCandlish says, the entire online world is not ruled out, not by us nor by the various guides to citations. Imzadi 1979 → 04:35, 23 April 2014 (UTC)

Allow uppercase parameter names

After this whole past year of the Lua-based cites, I think it is time to allow uppercase names for several major parameters, including "Title=" & "Date=" & "Publisher=" & "Accessdate=" (etc.). The successful use of capital "Author=" has shown the feature to be workable, as well as perhaps leading some people to imagine capital "Title=" should work as well. The data seems to show 10% of spelling errors are capital-letter parameters, although the percentage might be higher due to the obvious quick fix for a even newcomer to use lowercase when an error message is seen. To simplify implementation, perhaps start with just 10 major parameters where the capital letter would be allowed.

Although the unknown parameters have been fixed among the 10,000 articles with "unsupported" parameters, the prior usage can be estimated from checking the user-space pages, as with a search:
Template:Nb10• Google Search: "Unknown parameter" "date ignored" site:en.wikipedia.org
In several prior cases, the problem has been capital "Date=" as an irksome glitch which prevented the date from appearing in a formatted cite. Anyway, because the long-term use of capital "Author=" has not caused major problems, then allowing a capital letter in 10 other major parameters should work well. -Wikid77 18:13, 15 April 2014 (UTC)

This kind of tolerance of mixed case doesn't sound crazy to me. Clearly I'm in a devil's advocate mood today. Does anyone know the rationale behind allowing only lower-case letters in most parameters? Is there some programming-related reason that (some) parameters need to be case-sensitive? Why should the parser care whether someone writes |author=, |Author=, |AUTHOR=, or even, perversely, |AuthoR=? I'm just asking. If there's a reason, it would be helpful to understand it. – Jonesey95 (talk) 19:00, 15 April 2014 (UTC)

See below: "#No significant overhead for major capital names". -Wikid77 (talk) 17:18, 19 April 2014 (UTC)

In the old template, we would have had to case change each and every parameter. This would have added more overhead to an already resource intensive template. I had a fix for the double periods issue, but it added way to much overhead.

We have any number of bots working citation templates that we must consider before making a change of this magnitude. And lower case parameters are the defacto standard. --  Gadget850 ^talk 19:39, 15 April 2014 (UTC)

Having bots do it (very easy for them to spot, quick to hopefully do) seems much more sensible than a programming fix, which will marginally make the code more complex. Only marginally but added up across every reference in every article there's bound to be some impact. All for fixing a few dozen/hundred/thousand errors. If bots do it once fixed it's fixed, and can stay fixed with periodic bot patrols.--JohnBlackburne^words_deeds 20:05, 15 April 2014 (UTC)

Right, this would add a terrible amount of overhead to the template, and would make some pages fail (there's a limit to how many templates and parser functions one page can call). MediaWiki really needs some way to set "this wiki's parameters are case-insensitive by default" and "in this code, flip the case-sensitive bit until we say stop".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:01, 16 April 2014 (UTC)

Browsing through the search above, the first ten search pages are user and talk pages. The few articles I sampled don't have this error, as they were fixed but still show in Google's search cache. I don't see a huge problem. --  Gadget850 ^talk 10:10, 16 April 2014 (UTC)

That's because gnomes have diligently fixed all of those articles over the past few months (the error category was emptied yesterday!) and User/Talk/etc. pages are not included in the CS1 error category. – Jonesey95 (talk) 13:07, 16 April 2014 (UTC)

I wanted to see what it would be like to edit a page with all-uppercase parameter names, so I temporarily created this. Click the edit button at the top of the left hand column. To me it is not at all pleasant and quite a lot like being shouted at. -- 79.67.241.227 (talk) 13:11, 16 April 2014 (UTC)

I'm not convinced that this is an issue. For a time, there were a large number of {{cite music release notes}} templates in article space with capitalized parameters. Because that template is handled by {{citation/core}}, the capitalized parameters weren't displayed. I've fixed that with an AWB script and I've fixed thousands of capitalization errors in Category:Pages with citations using unsupported parameters. That category is essentially empty now.

I would rather see more consistency than less. It's my experience that for the vast majority of templates, parameter names are case sensitive and that the default state is lowercase. Without there being a significant clamor for case insensitive parameter handling, we should stick with lowercase.

Along the lines of consistency, I think, and have said before that we should standardize on parameter name separator characters and style. We have parameters that don't use a separator; parameters that use underscores, hyphens, spaces; parameters that are capitalized, lowercase, uppercase, and CamelCase. Where separators are used, the hyphen is by far the most commonly used. While we could allow spaces in place of visible-character separators, I think that it is helpful to readers to visibly connect the various parts of a parameter name so that it looks like a whole unit and not separate words.

Similarly, where parameter names are run-together collections of whole or partial words, there should be a length limit before requiring the inclusion of separator characters. CamelCase names may be easier to parse, but out of all of the parameters currently in use, only a few have that form. As words get longer they get harder to parse, and it's harder to find typographical errors because these 'words' don't appear in everyday writing so your browser's spell checker declares most parameter names to be misspellings even when they are spelled correctly. Perhaps the limit should be 10 characters so: |accessdate= but not |ignoreisbnerror=; |trans-title= or |transtitle= but not |trans_title=; parameter names that naturally occur in English are not subject to this requirement: |encyclopedia=.

Because it is common practice to capitalize initialisms, ISBN, DOI, etc., these types of parameter names (the identifiers) are, and should continue to be, allowed. Documentation, however, should not use the capitalized versions.

So, I propose that we:

1. deprecate underscores and spaces as parameter name separators in favor of hyphens
2. deprecate unseparated parameter names of 10 or more characters in favor of hyphen separated names
3. deprecate CamelCase parameter names in favor of lowercase; hyphenate as required above
4. deprecate Capitalized parameter names in favor of lowercase; hyphenate as required above

To implement this in Module:Citation/CS1 is for the most part trivial. The cleanup afterward will require a bot or AWB script to troll through Category:Pages containing cite templates with deprecated parameters to repair individual citations. I am prepared to do that task.

—Trappist the monk (talk) 13:38, 16 April 2014 (UTC)

As someone that has often typed |trans-title= without thinking, I support your proposal for parameter names to include hyphens, not underscores, not spaces, not CamelCaps and not capitalised. When inconsistency is allowed, it becomes harder to spot inconsistent things that are real errors. Of course, bots that edit references should be able to read aNyCase and allow for space or underscore where hyphen should be and then re-emit the corrected reference parameter names as all lower case with hyphens. It would be nice to see a requirement for space to the left of each pipe as a bare minimum so that word-wrap also has a fighting chance of working properly. -- 79.67.241.227 (talk) 16:51, 16 April 2014 (UTC)

I strongly support unifying the way we concatenate words in parameter names. When a user is typing a parameter name they should not have to think "Now is this the one that is joined with a '_', or is it nothing, nothing with camelCase, or a normal one with '-'"?

We should decide on one method and make it such that from the user's point of view that method always works. It should work without consideration for how long the parameter is, or any other consideration. Given that there are a large number of hyphen separated names, I would second the suggestion that we choose that method. If we want to also have aliases for shorter parameter names where no separator is used, that is reasonable. An example would be that |access-date= could also be used as |accessdate=. For shorter parameter names it may be easier to type without the hyphen. However, the user that does not have detailed familiarity with the template should not have to know that words in certain parameter are joined in a particular way. One way of joining words should always work.

Making this change would reduce confusion on the part of users and result in a template that is a bit more user-friendly. — Makyen (talk) 06:39, 21 April 2014 (UTC)

No significant overhead for major capital names

After years of allowing both lowercase and uppercase id parameter names (such "isbn=" and "ISBN="), there has been no significant overhead incurred by allowing just one alias for a dozen parameters. The major problem with {{Citation/core}} had been allowing 'surname1' up to 'surname9' or 'given9' as 18 extra aliases which were almost never used, compared to use of capital 'Date=' or 'Publisher'. Also, each various camel-case or mixed spelling (such as 'AccessDate' or 'AutHOR') would be cumbersome to handle in the {Citation/core} while almost never used in live articles. Fortunately, the parameters where people tend to use a capital letter are still rare, including: Title, Chapter, Last, First, Date, Publisher, Accessdate, or Author. Hence, if perhaps 10 major parameters were accepted with a capital letter, then there would be fewer cite errors, while no significant overhead in processing just those extra spellings (similar to 'issn' or 'ISSN'). Although wp:autofixing cites would also handle the capital-letter format, those would still be logged into a tracking category which would expand the total list of pages with invalid parameters. Instead by treating the major capital-letter forms as valid (similar to valid 'Author' during 2013), then the size of a tracking category would be reduced. -Wikid77 (talk) 17:18, 19 April 2014 (UTC)

circa

At present, the citation templates does not seem to recognise "circa" and abbreviations thereof, and throws these up as cs1 date errors. What does the template recognise, if at all? Or what can we do about these? -- Ohc ^¡digame! 03:21, 17 April 2014 (UTC)

"c. " should work (letter c, full stop, space), like this:

Cite book comparison

Wikitext	{{cite book|author=Author|date=c. 1894|publisher=Publisher|title=Title}}
Live	Author (c. 1894). Title. Publisher. {{cite book}}: |author= has generic name (help)
Sandbox	Author (c. 1894). Title. Publisher. {{cite book}}: |author= has generic name (help)

This usage conforms with WP:DATEOTHER, which is part of the MOS. – Jonesey95 (talk) 04:07, 17 April 2014 (UTC)

In that case, per ISO/WCAG accessibility guidelines, the HTML should be <abbr title="circa">c.</abbr>_ (my underscore represents your space). The template {{abbr}} may be used to achieve this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:44, 17 April 2014 (UTC)

Which would then corrupt the &rft.date with the {{abbr}} HTML. --  Gadget850 ^talk 09:49, 17 April 2014 (UTC)

And it exposes the strip markers and causes a date error.

'"`UNIQ--templatestyles-000000A1-QINU`"'<cite class="citation book cs1">''Title''. <abbr title="circa">c.</abbr> 1900.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Check date values in: <code class="cs1-code">&#124;date=</code> ([[Help:CS1 errors#bad_date|help]])</span>}}

--  Gadget850 ^talk 09:53, 17 April 2014 (UTC)

And it looks like any inclusion of #tag or a template that includes it causes the strip marker issue. I'm not knowledgeable enough about Lua to be able to break this down and properly characterize it. --  Gadget850 ^talk 12:56, 17 April 2014 (UTC)

What about the template {{circa}} which is what WP:DATEOTHER suggests as the way of displaying approximate dates? Nthep (talk) 13:06, 17 April 2014 (UTC)

The shortcut above, WP:DATEOTHER, is incorrect; it is associated with the level 4 heading "Ranges" heading in MOSNUM (not MOS). The correct heading is "Uncertain, incomplete, or approximate dates". Jc3s5h (talk) 13:12, 17 April 2014 (UTC)

Same thing:

'"`UNIQ--templatestyles-000000A6-QINU`"'<cite class="citation book cs1">''Title''. <abbr title="circa">c.</abbr> 1900.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Check date values in: <code class="cs1-code">&#124;date=</code> ([[Help:CS1 errors#bad_date|help]])</span>}}

If we are going to use this, we need to include it in the CS1 module. --  Gadget850 ^talk 13:18, 17 April 2014 (UTC)

Presumably, we could then use Lua to strip the markup and substitute the word "circa" in the COinS data? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 18 April 2014 (UTC)

Not a Lua programmer, but the simplest way would be to inject the date field (ca. 1900) into COinS as is and parse the "c." into the abbr markup. --  Gadget850 ^talk 18:42, 18 April 2014 (UTC)

Not sure where you mean to do that parsing; but why not put the word in full in COinS? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 18 April 2014 (UTC)

Unless it is required by WP:DATESNO, which it doesn't seem to be, is this functionality necessary?

—Trappist the monk (talk) 19:54, 18 April 2014 (UTC)

It may not be part of WP:DATESNO, but marking up abbreviations as above is part of WCAG. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 18 April 2014 (UTC)

In fact the first line of the WP:DATESNO section on uncertain dates mentions {{Circa}}; I've posted a suggestion on the talk page about strengthening that recommendation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 18 April 2014 (UTC)

Log dates over 24 characters as long dates

To solve the problem of misjudging free-form dates or "{{circa}} 1950" as being invalid dates (when actually valid), then I suggest any date over 24 characters long (longer than "September 16-29, 1150 BC") should be logged into a non-error tracking category, and not tagged with a "Check date values" message using a CSS class. The Template:Circa inserts an abbr-tag as "<abbr title="circa">c.</abbr>" which is 29 characters, longer than 24 and hence could be skipped when checking for valid date format. Otherwise, there are too many date formats which need to be allowed, such as the need to allow dates in years BC:

• {cite web |title=BC Years |date=November 20, 31 BC} → "BC Years". November 20, 31 BC. {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help)

When a tracking category is flooded with errors for valid dates, then it makes it more difficult to spot the pages which contain actual invalid dates. -Wikid77 (talk) 19:12, 19 April 2014 (UTC)

As noted above, {{circa}} injects HTML into the COinS metadata, so it should be detected as invalid. --  Gadget850 ^talk 02:18, 20 April 2014 (UTC)

• Lua can instantly remove any span-tag or abbr-tag: Before storing the COinS metadata, we can use the Lua regex gmatch() function to remove any circa <abbr> tag (or span-tag) and store only the "c." portion in the COinS. For "{{circa}} 1850" see result:

• {{#invoke:String|match|pattern=<.*>(.*)<.*> |s=<abbr title="circa">c.</abbr> 1850 |plain=0 }}{{#invoke:String|match|pattern=.*>(.*)$ |s=<abbr title="circa">c.</abbr> 1850 |plain=0}}
  → c. 1850

I have run several timing tests to confirm how Lua's internal gmatch() function is extremely fast, and could remove the HTML abbr-tag or span-tag instantly, leaving only the plain text in the COinS metadata. -Wikid77 (talk) 12:12, 20 April 2014 (UTC)

We should not use Lua to change <abbr title="circa">c.</abbr> to c. in COinS; if anything it should change it to circa Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:33, 20 April 2014 (UTC)

We should not use {{circa}} or any other template inside a CS1 template. If the functionality is worthwhile, then we should build it into the CS1 module. -  Gadget850 ^talk 13:23, 20 April 2014 (UTC)

Why not? It's a perfectly reasonable thing for an editor to expect to be able to do. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:44, 20 April 2014 (UTC)

Pigsonthewing's question goes against the philosophy of the date checker: popular date expressions are OK and everything else is wrong. For example, the date checker considers "before 1924" to be wrong, even though it could be perfectly valid. Jc3s5h (talk) 13:49, 20 April 2014 (UTC)

Pigsonthewing We have no control over other templates. If the functionality is valid, then we should include it in the CS1 module where we can ensure it works proper with COinS. Otherwise we have to add a check for each and every template that might be included and injects HTML/CSS: {{smallcaps}} (functionality now in CS1), {{registration required}} (functionality now in CS1), {{subscription required}} (functionality now in CS1), {{asiantitle}}, {{start date}}, and others. --  Gadget850 ^talk 15:07, 20 April 2014 (UTC)

I wouldn't argue that we should do so for check for each and every template that might be included, (other than to strip away such HTML), but we should do so for those which add meaning or value to a citation; as in this case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 20 April 2014 (UTC)

That rather suggests that the date checker is in error. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 20 April 2014 (UTC)

HTML classes

We've previously discussed using HTML classes to make our citations more easily parseable (Representatives of Zotero, for example, have said that if we publish and apply such a schema, then Zotero will parse it. ). The suggestion then was "Once this module is debugged and implemented, then we can look at adding this feature". Shall we now do so? A proposed list of class names is at Wikipedia:WikiProject Microformats/citation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:19, 20 April 2014 (UTC)

Zotero already uses the COinS metadata— what is different or missing? --  Gadget850 ^talk 16:53, 20 April 2014 (UTC)

Among other things, it offers higher granularity and more features than COinS (the date the ref was accessed, for instance), and extensibility, which the earlier method lacks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:31, 20 April 2014 (UTC)

"news=" alias?

I have noticed that when editors cite a newspaper they tend to find |newspaper= okay. But when they have a source that is obviously news (such as a television network) but not a paper, they balk (quite rightly, as it is not a newspaper), then get confused as to what alternate to use. Which would hardly matter, as |work=, etc., are just aliases, except that names do carry meaning. So I wonder if, to avoid semantic conflict, |news= could be added as an alias? ~ J. Johnson (JJ) (talk) 22:15, 20 April 2014 (UTC)

The words "newspaper" and "work" both indicate a specific publication, which is exactly what we want to indicate. The word "news" means all kinds of new information, or all news publications as a group. I'm not convinced editors would understand what is intended if it were created as a parameter synonymous with "newspaper" and "work". Jc3s5h (talk) 22:28, 20 April 2014 (UTC)

Well, the problem is one of education, I think. When dealing with TV news, a segment on the news is analogous to an article in a newspaper, the name of the news program is analogous to the name of the newspaper (which is the encompassing work), and the network is the publishing company. When dealing with web-only news from TV sources, there isn't a program involved to serve as the encompassing work, so the network, a division of the network, or a local TV station is the publisher to be referenced. If we were to include aliases, I would recommend some variations of |network= or |station= as aliases to |publisher=, not |work= because a TV network or TV station is a publisher not a publication. Imzadi 1979 → 00:15, 21 April 2014 (UTC)

• Keyword "news" commonly used like "book": Among the prior 8,500 pages which contained "unknown parameters" this year, the (invalid) keyword "news=" was very common, especially in {cite_news}, similar to common usage of invalid keyword "book=" in {cite_book}. Because the Lua modules can easily handle another 90 parameter names (of the Lua 200-per-function limit), without restructuring, I support adding "news=" as an alias for "newspaper=". Meanwhile, I would also add "book=" for "work=" because people have been using "title=" for a short story or technical paper within a "book=" such as Proceedings of a Conference. Other common keywords used by people include: "note=" or "comment=" and "part=" or "paragraph=" or "column=" (for which column in a newspaper). However, "news=" was used quite often. -Wikid77 (talk) 12:26, 21 April 2014 (UTC)

I think "book=" warrants some discussion, but perhaps we could table that for the moment?

I'd like to think that the existing use of "news=", and in the manner contemplated by this request, reflects its "obvious" appropriateness, but allow it could be just random attempts to find an alternative. The problem being addressed is that the only "news source" parameter is specifically newspaper; the request is for a "news" alternative. I don't believe there would be a problem if "news=" were taken generically for all news sources.

The use of "publisher=" (or possible equivalents, such as "station=" or "network="), another common approach, I find unsatisfactory. E.g., there is a difference between the NBC network, and NBC News, parallel to the difference between The New York Times newspaper and the company that publishes it. ~ J. Johnson (JJ) (talk) 21:19, 21 April 2014 (UTC)

NBC News is a division of NBC, just as NBC Entertainment is; it's still a publisher and not the publication. The NBC Nightly News with Brian Williams would be one of its publications. I would compare NBC News with an imprint of a publisher, like Zondervan is an imprint of HarperCollins; they're still corporate personas, not publications.

I'm reading through chapter 14 in The Chicago Manual of Style (16th ed.), and it does not list TV networks, TV stations, or divisions thereof as periodicals. The section "Websites and Blogs" does not give any support to your argument either; the examples only italicize Wikipedia (which is the online equivalent of an encyclopedia that would be italicized if a print source) but do not italicize the names of corporations publishing websites.

The current editions of the MLA (7th) and APA (6th) style guides follow suit: corporate names in citations are publishers and not publications. Sorry, based on my survey of the style guides I have at my disposal, I'm not seeing any support for your argument, and in fact, I'm finding Imzadi 1979 → 00:50, 22 April 2014 (UTC)

• Handle 'news=' as 'agency=' data: I think the safest role for common invalid parameter "news=" would be folded into "agency=" as non-italic. In reviewing usage of "news=" in actual pages, there has been a mix of websites (such as "news=xx.com") or publications (such as "news=The Washington Post") or agencies ("news=ABC News"). See usage:
       • Google: "Unknown parameter" "news ignored" site:en.wikipedia.org
  It is better to avoid italics for this, rather than incorrectly use italic websites (xx.com), and discerning users can add their own tic-marks "news=''Guardian''" if needed, but suppressing italics (prepend "</i>") would be a challenge for most users. For the rare case of "news=" plus "agency=" then I would append them both with a separator, and store in the COinS metadata as the agency parameter. What we really want to avoid is people (or Bots) rushing to fix "news=xx.com" and put "work=xx.com" to show italic "xx.com" which just makes Wikipedia look ill-formatted. Meanwhile, I will update "wp:autofixing cites" to fold "news=" into "agency=" where autofixing would provide better (non-italic) results, compared to human/Bot fixes very likely forcing italics (see: dif289), because there is a limit to what people can rapidly hand-fix, while autofixing is now handling hundreds of tedious issues instantly. -Wikid77 (talk) 09:29, 22 April 2014 (UTC)

I'm not sure what you are trying to get at. The diff you linked to shows the invalid |news=nreionline.com being changed to |work=nreionline.com. For that citation "nreionline.com" is the work in which the news report is contained. |work= is correct. You imply that it should be |agency= which it should not in that case. In that citation, there should be no |agency= as there is no agency credited and a author is named. You appear to be advocating significantly changing how we display citations.

Given that the "unknown parameter" category has already been cleared, I don't see why there would be a bunch people or bots rushing out now to fix invalid |news= parameters.

While the use of |agency= should be higher than it is, I highly doubt that the correct alias, if we establish one, for "news" would be |agency=. I believe that it is far more likely that "news" be mistakenly used for |work= than for |agency=.

Wait a second. The Google search you provided shows a total of 22 hits. Are we saying that out of the thousands of "unknown parameters" there were a total of 22 times that "news" was used? If so, why are we considering this as an alias? That does not appear to be a high enough usage to justify having it as an alias. Particularly when there are ambiguity issues with using "news". — Makyen (talk) 11:18, 22 April 2014 (UTC)

Parameter 'news=' is for both prior and future use: Although the prior 22 times when pages used 'news=' are only a portion of the total pages fixed now to remove 'news', the intent is to recommend future use as "news=NewsSource.com" where people want to specify an online (website) source but not show italic website "NewsSource.com". -Wikid77 10:35, 28 April 2014 (UTC)

No, please don't fold "news=" into "agency=", as if "news" was simply short for "newsagency". The problem I am trying to resolve is the equivalent of how to handle sources that are fully equivalent to what newspapers put on line, but are not papers. ~ J. Johnson (JJ) (talk) 00:37, 23 April 2014 (UTC)

Then 'news=' should be a separate parameter, rather than an alias, and 'news=nn.com' would not show italic website "nn.com" but just plain-text "nn.com". -Wikid77 10:35, 28 April 2014 (UTC)

Your example confuses me; perhaps I might recapitulate my concept of the situation here. We have a kind of news source, newspapers, with or without an associated web page, for which 'newspaper=' is appropriate, and other kinds of web pages, possibly not a news source (e.g., a blog). The documentation for 'cite web' says it is for "web sources not characterized by another CS1 template"; I presume that covers blogs, etc.

The matter here is how to handle a kind of an online news source (such as NBC) that is fully the equivalent of a newspaper, but isn't a "paper". In cases of journals, magazines, and periodicals, whose parameters are aliased wth 'newspaper=', the absence any print (paper) form doesn't seem to cause a problem. But newspaper seems too strongly specific in that regard, which is why I have asked for 'news=' aliased (with the others) to 'work='.

I'm not quite following these aspects of italicization. I would presume that 'news=' should follow the usage of 'newspaper=' in all regards, and don't see why it should be separate parameter, rather than an alias. ~ J. Johnson (JJ) (talk) 22:27, 28 April 2014 (UTC)

The thing is, I think you're confusing the equivalents, and your case gets muddied. NBC is not a form of periodical. Rather, it is a publisher of periodicals in the form of its various TV news broadcasts like the NBC Nightly News with Brian Williams, Today or Dateline. If they publish a news article without attributing it to one of those broadcasts, there wouldn't be anything to list in italics. This article is from the NBC Nightly News, but this article lacks a connection to one of those works, so it would be just cited to the network, a publisher. NBC shouldn't be in italics anymore than The New York Times Company would be, but Today or The New York Times would. Imzadi 1979 → 00:06, 29 April 2014 (UTC)

Well put, thank you. We are delving into the definition and nature of "periodical". I agree that "NBC" is too broad for my example (it broadcasts much more than news); NBC Nightly News is a better parallel to (say) The New York Times. In such a case wouldn't aliasing 'news=' to (say) 'newspaper=' be satisfactory?

The other issues you raise show there are a bewildering range of complications, especially where "non-periodical" articles are co-mingled with "periodical" articles. Conceivably the The New York Times might take responsibility for articles at www.nytimes.com site not found in the paper, but I doubt NBC Nightly News would do so for www.nbcnews.com. This gets deeper than I want to get into. But I wonder if any of that would preclude using 'news='. ~ J. Johnson (JJ) (talk) 23:25, 29 April 2014 (UTC)

Cite web cite not displaying properly

Resolved

I've stumbled across a bit of a problem on the article William Wigginton. One of the cites, for {{cite web}} is refusing to display, or rather, displaying as code.--Auric talk 04:53, 21 April 2014 (UTC)

Fixed. I'm not sure how or why. I replaced the hard return between "cite" and "web" with a space. I thought all white space was supposed to be treated the same, but maybe not. – Jonesey95 (talk) 05:19, 21 April 2014 (UTC)

No, not all whitespace is treated the same. One of the issues we had with "unknown parameters" in citation templates was that a variety of different Unicode spaces were used within or around parameter names in some citations and not recognized as whitespace. Mostly those were the use of a hard-coded non-breaking space. In this instance, it was a standard LF (0x0A) character. It appears that while a LF is considered whitespace on either side of the template name, it is not considered such within the name of the template. — Makyen (talk) 06:03, 21 April 2014 (UTC)

Similar problem occurs if a newline gets copied inside a parameter value, such as title or url. ~ J. Johnson (JJ) (talk) 21:24, 21 April 2014 (UTC)

We can potentially fix those problems. We can't fix it in the template name as it occurs before the template is invoked. --  Gadget850 ^talk 22:48, 21 April 2014 (UTC)

So is "cite web" a distinct template, not a "web" variant of "cite"? ~ J. Johnson (JJ) (talk) 23:39, 21 April 2014 (UTC)

@J. Johnson: The answer to your question is a bit more complex than you are probably intending to ask. Yes, {{cite web}} is a separate template. Except for redirects, each citation type is a separate template. However, most such either invoke or call two base sets of functionality. The newer set of functionality is based on a Lua module. Templates such as {{cite web}} invoke that module. Some citation templates still use the older wiki-template based citation code. There is a third type used for a few types of citations where a bot will go out and collect the information for the citation and create a template with the information filled in which is then transcluded into the citing page. All of those are ultimately based on the Lua module once the bot builds the template to transclude. There is a list of the General use citation templates indicating which base functionality is being used.

@Gadget850: It is not clear to me that such problems should be handled within the module. The number of occurrences is relatively low and easily fixed in the page. Once we start "fixing" such things in the module it is an ever growing list of things to "fix". We have already cleared out the "unknown parameter" category. The extra processing is probably not worth it moving forward. — Makyen (talk) 00:56, 22 April 2014 (UTC)

Thanks, Mayken. I was wondering how much of that had been changed. ~ J. Johnson (JJ) (talk) 22:43, 22 April 2014 (UTC)

• CS1 cites already rejoin split newline data: There has been some misunderstanding, but for over a year, the Lua wp:CS1 templates have been autofixing cites which have newlines (LF) in data, but not newlines within the template name "{cite web}". For example, note a title on 4 lines:

• {cite web |title=Title
  Broken
  into
  Four Parts |author=Joe Fixit |date=Another day of autofixing}}
  →

           Joe Fixit (Another day of autofixing). "Title Broken into Four Parts". {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help); line feed character in |title= at position 6 (help)

When I first developed the Lua-based CS1 cites, several types of autofixing were added, such as non-plural pages "pages=4" shows as "p. 4" not "pp." or removing double-dots between parameters. The filter to remove newlines in titles was added soon after. Although handling all these issues has been detailed work, the results are amazing, such as wikilinking "location=[[Washington, D.C.]]" and still getting only one dot separator after the "D.C." text because the Lua module checks for end-dot (or other separator) inside a wikilink. -Wikid77 (talk) 11:16, 22 April 2014 (UTC)

Status of autofixing cites

I have been updating topic above "#Should autofix more cites" but I wanted to note some recent issues. Although the use of autofixing will retro-correct cites in archived pages (especially wp:AfD's which admins want left unchanged) and fix all prior revisions of any page, the auto-corrections have reached perhaps 200 issues and will take more time to discuss. Please understand, the whole prior tactic of issuing red-error messages for cites was never my intention, but by allowing them into Lua cites for a whole year (April 2013-2014), we gained extensive evidence that those messages do not cause users to fix "9,000" articles, which had to be hand-fixed by a special backlog drive to clear 8,500 of them by mid-April 2014. Now, we see perhaps 12 new "unknown parameter" pages left each day (366/month, ~4,400/year), to be hand-fixed or else thousands of people see red messages. However, at this point, we are spotting the trends for new unknown parameters, where perhaps 10% are bad accessdate as "acesdate" or "access date" or "accessed" (etc.) and many are capital-letter form (invalid "Publisher="). Before release of autofixing, more users need to understand to search for Template:J and "^[fix url]" rather than "Unknown parameter |xx= ignored". The next step would be partial rollout for use of autofixing in some types of cites, such as {{cite encyclopedia}} or such. However, I expect more weeks of discussion and stronger autofixing, such as to handle invalid:
Template:Nb10"| urlhttp://xxx.com/index.php?zz=123&arg=en"   as if   "url="
Long-term, we need to expect many more editors to write invalid cites every day, but not yet, because currently the editor base of Wikipedia is in a slight decline, perhaps due to strange user-interface changes (https, login redesign, 2-style Frankenfonts with Liberation Sans, etc.) or users leaving who cannot post more adverts. However, many users keep joining despite all the forced wp:VE or login problems, and autofixing will allow more new users to write invalid cites but still get workable results. That's the brief status so far. It will take time to transition. -Wikid77 (talk) 10:40, 22 April 2014 (UTC)

I plan to recruit ReferenceBot in the next month or so to notify editors who leave unsupported parameter errors, along with "coauthors without author", redundant parameter, PMC, and PMID errors. I am waiting for the redundant parameters category to be cleared (in the next couple of days) and for the job queue to stop adding new articles to the new PMC and PMID categories. Of the 27 error categories, 14 have been cleared, and four have fewer than 500 articles with errors, so they should be easy to clear and keep clear. That leaves nine categories to focus new ideas and energy on. – Jonesey95 (talk) 14:36, 22 April 2014 (UTC)

"coauthors without author" should perhaps read "coauthors is deprecated, use last/first or author" There are still many editors adding references with the coauthors attribute. -- 79.67.241.210 (talk) 17:14, 22 April 2014 (UTC)

I was referring to Category:CS1 errors: coauthors without author, which has been cleared out recently. Now that the category has been cleared, ReferenceBot will be able to notify the 2–4 editors per week who add a citation containing this error.

I forgot to mention above that we have eliminated over 50,000 articles from Category:Articles with incorrect citation syntax in the last month, since the most recent code update. The total number of articles shown on that page was about 299,000 on March 23, 2014, and it's down to 253,000 today (April 22). (I estimate over 50,000 articles eliminated because the code changes have added at least a few thousand new articles.) That is great progress. – Jonesey95 (talk) 18:09, 22 April 2014 (UTC)

Time for a real CS1 style guide?

Of late there seem to have been several discussions that relate to various template parameters and the styling of rendered citations:

• Should quote chapter when title and journal
• Bold/non-bold volume parameter doc issue, or bug
• Accesswalls
• Chapter with book/volume and series
• Cite web or accessdate without URL
• Proper use of parameter?
• ORCID, redux
• Work parameter (Template:Cite news)
• Rethinking accessdate
• Allow uppercase parameter names
• circa
• HTML classes
• "news=" alias?

All or most of these issues could / should be answered by a proper style guide. Instead, what we get are a lot of short-term conversations that ultimately produce nothing. As we are now, we have documentation distributed across the various CS1 templates and help pages. The documentation is often out of date with respect to CS1's actual implementation and does not serve as a style guide because it can't. I know that there are editors out there who are familiar with published style guides (I'm not one of them) who could write a style guide for CS1. That guide would then direct further development of Module:Citation/CS1 into the tool that it really is capable of being.

Isn't it time we had such a guide? This is no short term project. Every citation type, every parameter, every bit of functionality, should be taken apart, examined and if found worthy, included in the style guide that details its use.

—Trappist the monk (talk) 12:32, 22 April 2014 (UTC)

Before enabling the CS1 errors: dates messages (or any of the other hidden messages) for everyone to see, I agree that a proper style guide should be in place which addresses those errors and their resolution. GoingBatty (talk) 14:16, 22 April 2014 (UTC)

It would be easier to start with a printed style guide and write a supplemental guide explaining which rules in the printed guide have been changed. For example, if we started with "APA Style" we could say that it has been extended to endnotes rather than being restricted to Harvard references, article titles are in double quotes rather than plain, the article title is linked to the web site of the article if available, etc.

This approach would allow the CS1 style to benefit from discussions of the printed style guide outside of Wikipedia, for example, the blog at the APA style website. Jc3s5h (talk) 14:22, 22 April 2014 (UTC)

Writing a supplement as you describe requires free and open access to the particular version of the established style guide that the supplement modifies. Any editor must be able to read that original and the supplement. CS1 is not APA, nor Chicago, nor any other but is, as I understand it, some combination of those with ideas of our own tossed in. This would seem to make it more difficult to pick one to modify but perhaps it's possible.

You're the expert here on APA, how closely does what amounts to style in CS1 match APA?

—Trappist the monk (talk) 17:05, 22 April 2014 (UTC)

I don't think there is a requirement that the base style guide be freely accessible, although it would be preferable. The more popular guides have many free websites that summarize them. The biggest differences between APA and CS1, in my view:

• APA covers both the body of an article, and the citations; CS1 only covers citations.
• APA only describes parenthetical referencing, while CS1 applies to endnotes only, short endnotes with bibliography, and parenthetical referencing
• APA has some details of how elements of the citation are to be written that are not specified in CS1; for example, article titles are plain and have sentence case. Also, author first and middle names are always initials in APA style.
• APA publication dates are in the format "(2014, April 22)."
• In APA the date always follows the authors; if there are no authors, the title is the first element and is immediately followed by the date.
• Since APA is designed for paper, the URLs from which documents were retrieved are written out rather than being hyperlinks.
• There are element order conventions for many situations. The order is similar but not identical to CS1. If we wanted, we could make some minor changes in the order of elements to match APA, without requiring any parameter changes.

As for other style guides, Chicago Manual of Style has pretty much the same options (endnote only, short endnotes and bibliography, parenthetical referencing) as CS1, but the order of elements are quite a bit different. Also, the date format for journals and newspapers is pretty strange.

The Modern Language Association style is based on parenthetical referencing, where the author and shortened titile (not the year) are put in the parentheses. That would be a huge change. Jc3s5h (talk) 18:53, 22 April 2014 (UTC)

I've been taking some undergraduate classes, and all of my professors/instructors have recommended the Purdue Online Writing Lab (OWL). I purchased copies of the current editions of the APA, MLA and Chicago style guides, but Purdue OWL or the official websites are just as good for consultations. Imzadi 1979 → 19:03, 22 April 2014 (UTC)

So, perhaps I really don't know what it is that I want. Scanning through the MLA and APA sections at Purdue OWL tells me how to manually construct various types of citations. With CS1, there is no manual construction, the templates and Module:Citation/CS1 do that for us.

—Trappist the monk (talk) 11:22, 23 April 2014 (UTC)

As noted, the issue with APA, Chicago and others is that the manuals are copyrighted. We really need to start from scratch and create our own open style. The current display of citations is different enough from published styles that it should not be an issue. We already have a MoS that covers other styles; we need to work on only citation style here. We need to deconstruct the current documentation and recodify it.

A major issue is that many editors and projects use the CS1 templates, but add their own spin, such as first name initials, smallcaps names, and many more variations. This muddles CS1 as a style. We will never have internal consensus on a house style— any consistent style will have to be imposed from above.

--  Gadget850 ^talk 12:13, 23 April 2014 (UTC)

Copyright is not an issue, except for those who insist on getting the information from the horse's mouth, and decide to buy the printed style guide. Copyright only applies to the words that are used in the style manual to explain the style; copyright does not apply to the ideas. We can explain the same style points in Wikipedia that a printed style guide explains; we just can't use the same wording to explain it. And of course, fair use still applies, so the occasional phrase or example from a printed style guide can be quoted so long as it falls under the fair use doctrine. Jc3s5h (talk) 15:29, 23 April 2014 (UTC)

We need to not adopt some third-party, paper-based citation standard. We've evolved our own for good reasons. If there's any justice in the world, it'll even spread off of WP.

I strongly concur that we do need such a guide. I have no objection to basing the overall gist of our style on some other one, but like all of WP:MOS, it should be a synthesis of several, guided by actual mainstream usage, and with every point focused on what is best for our readers, not for editors much less particular camps of them.

Some of the style problems of various off-WP citation style guides, just off the top of my head and in 5 minutes or less:

1. Failure to italicize the titles of major works (books, journals, TV shows, albums).
2. Failure to double-quotation-markup titles of minor works (chapters, articles, episodes, songs).
3. Forcing of all titles to sentence case, when WP should either leave them alone or (probably preferably) change them all to title case (except in foreign languages that do not use title case, like French).
4. Boldfacing of volume numbers instead of using the word "Volume" or "Vol." (an accessibility problem among other things).
5. Using even more cryptic markup like 32.7:234, which varies between fields and off-WP "authorities", and is user-hateful jargon, vs. Vol. 32, No. 7, p. 234.
6. Confusing reversal of given-name and family-name order, after first author as in Lopez, Maria; John Samuels.
7. Reduction of all middle names to initials.
8. Reduction of everything but surnames to initials.
9. Worse yet, doing so without period/stops/dot: Frehley, IP.
10. Even worse yet, doing so without commas Frehley IP.
11. Use of SMALL CAPITALS for various conflicting purposes (first author's family name, all author family names, titles of one sort or the other, etc.).
12. Use of inconsistent date formats.

If I were to sit down and pore over the major citation styles again, I'm sure I could quadruple that list in a hour or two, but a complete catalog of academic citation styles' "sins" isn't the point here, just an illustration that there are lots of them and that our style has evolved to avoid them, though imperfectly – I think some template may still be boldfacing volume numbers, and we do nothing at all to even encourage proper name handling instead of stuff like "Frehley IP".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:28, 27 April 2014 (UTC)

Icon templates in language parameters

Reflinks (and humans too, probably) are using the various icon templates in the |language= parameters of CS1 templates, which do not display properly. Here's an example from Saab Automobile bankruptcy:

{{cite web|author=Anna-Karin Nils Gustavsson |url=http://ttela.se/ekonomi/saab/1.1587482-saab-ar-varderat-till-3-6-miljarder |title=Saab är värderat till 3,6 miljarder – Saab |language={{sv icon}} |publisher=www.ttela.se |date= |accessdate=2012-04-11}} generates:

Anna-Karin Nils Gustavsson. "Saab är värderat till 3,6 miljarder – Saab" (in Template:Sv icon). www.ttela.se. Retrieved 2012-04-11.{{cite web}}: CS1 maint: unrecognized language (link)

I did not receive any response when I posted on Dispenser's talk page for Reflinks. Is there any interest in updating the CS1 templates to display "(in Swedish)" when the icon templates are misused, or should I submit a bot request to have BattyBot fix these? Thanks! GoingBatty (talk) 14:39, 22 April 2014 (UTC)

That is a task that I've had in mind for Monkbot. Should be pretty simple to do. Remember that Module:Citation/CS1 understands ISO 639-1 two letter language codes so for those {{language icon}} templates, simply removing the braces and 'icon' will get the job done. For three letter language codes a different solution will be required.

–Trappist the monk (talk) 15:54, 22 April 2014 (UTC)

I've submitted an AWB feature request for this. If that doesn't go anywhere, then I'll submit a bot request. Thanks! GoingBatty (talk) 17:24, 4 May 2014 (UTC)

CS1 Advisories

The functionality afforded by using templates is great but there are a number of template generators and bots which continue to produce deprecated parameters or make amendments that are, or soon will be, unnecessary.

I'd like to suggest creating a Help:Citation_Style_1/Advisories page, where salient points can be listed (and can link to more detailed stuff where necessary). This would be aimed at bot operators and at coders working on producing template generators. It would simply be a clear list of changes they may need to be aware of so they can amend the functionality of their systems. Template changes would be easy to find without having to trawl through the huge amounts of template documentation looking for things that may have changed.

Some examples to kick off:

• The |month= and |day= parameters are deprecated. Monkbot is cleaning up remaining cases. The |date= parameter can handle full or partial dates. Processes should be amended to no longer generate the deprecated parameters.
• Bots should no longer swap |date=1999 over to |year=1999.
• Bots should no longer swap |trans-title= over to |trans_title=. The hyphenated version is currently an acceptable alias and may?/will? at some point become the "default".
• The |coauthor= and |coauthors= attributes are deprecated. Processes should be amended to no longer generate the deprecated parameters. Use |last=|first= or |author=.
• When handling a |url= ending .pdf or .doc it is useful to add the appropriate |format=PDF or |format=DOC parameter.
• For human readability of template code and sensible word-wrapping, please ensure there's a space before each |pipe when emitting refactored template code.

The idea is to avoid producing more stuff that needs to be fixed, and avoid doing work that is currently unnecessary or which will need to be undone when a future planned change is made to the template workings.

Discuss... -- 79.67.241.210 (talk) 17:09, 22 April 2014 (UTC)

I've just updated Wikipedia:AutoWikiBrowser/Rename template parameters so AWB bots will no longer swap |trans-title= over to |trans_title=. It would be very helpful to have a list of the valid parameters and aliases for each citation template. GoingBatty (talk) 03:09, 23 April 2014 (UTC)

The best list of CS1 (Lua module) parameters I know of is at Module:Citation/CS1/Whitelist. – Jonesey95 (talk) 04:29, 23 April 2014 (UTC)

Column number parameter for newspapers etc, please

Can we have a col or column parameter for use with newspaper reports and so on? (And please don't tell me to use at -- that requires me to give up page#.) Especially in older newspapers, it can be really, really hard to find an article on the huge, type-dense pages of the time. Not a priority, but a nice touch. EEng (talk) 03:03, 26 April 2014 (UTC)

|at=p. 1, col. 4 works, but it may be nice to add a specific parameter to do that automatically. Imzadi 1979 → 03:11, 26 April 2014 (UTC)

We need to think about what we want overall. If we add a "column" parameter we would have to consider adding other such parameters if someone comes up with a prevalent situation where some other specific specifier is needed.

We currently have a single, generic parameter, |at=, which is to specify where the material being cited is located. This parameter is currently mutually exclusive with the |page=, and |pages= parameters. I feel that a better solution to adding additional parameters for this purpose is to make |at= usable in addition to either |page= or |pages=. I know that I initially attempted to use it in this manner, and every once in a while I forget and try it again. To me, using both |page=1 and |at=col. 4 to specify "p. 1, col. 4" feels natural. I think being able to use both |at= and one of |page= or |pages= would better fit the expectations of editors using the templates and would alleviate the need/desire to have additional parameters for more specific situations. Making this change would, of course, be backward compatible with any current usage which is not currently producing a visible error. The logic would be something like: use a "," separator between display of |page= or |pages= and |at= if either of the page parameters exist, if they do not then no "," separator.

We would need to consider what is appropriate for the separator. Should it be something other than ","? Should it be no automatic separator with the requirement that a separator be included by the editor in the |at= value? — Makyen (talk) 08:12, 26 April 2014 (UTC)

Something to consider might be what {{cite map}} does:

• "Michigan" (Map). The Road Atlas. Rand McNally. 2013. p. 50. Western Upper Peninsula inset. § B1.

when you specify |page=50 |section=B1 |inset=Western Upper Peninsula. Conversely, if you specify |at= in cite map, you get the free form parameter:

• The Road Atlas (Map). Rand McNally. 2013. p. 50, section B1, Western Upper Peninsula inset; p. 52, Detroit inset.

with something like |at=p. 50, section B1, Western Upper Peninsula inset; p. 52, Detroit inset . Other combinations add or subtract:

• State Transportation Map (Map). Michigan Department of Transportation. § B6.
• State Transportation Map (Map). Michigan Department of Transportation. Grand Rapids inset.
• State Transportation Map (Map). Michigan Department of Transportation. Detroit Area inset. § B6.
• "Michigan" (Map). The Road Atlas. Rand McNally. p. 51. § G10.

I'm not opposed to including a |col= parameter and building in the logic that allows it to be combined with |page=, but |at= should stay free-form that overrides other parameters. Imzadi 1979 → 08:37, 26 April 2014 (UTC)

I don't mind using |at= as a catch-all for unusual "where to find it" info like column and the other examples just given, because these are unusual enough that I don't think formality and uniformity of their presentation matters much. But the sort of thing that would go in |at= will still be often used with a page #, and uniformity pf presentation of page # does matter, so |p= should be usable with |at= at the same time. I don't understand why |at= should override or force out other parameters -- why not just let it be a free-form addition that comes after the page# or whatever? (Yes, I know there are niggling issues about punctuation and so on, but I have every confidence you guys will come up with something appropriate.) EEng (talk) 08:45, 26 April 2014 (UTC)

When I documented |at=, I added examples from citations:

page (p.) or pages (pp.); section (sec.), column (col.), paragraph (para.); track; hours, minutes and seconds; act, scene, canto, book, part, folio, stanza, back cover, liner notes, indicia, colophon, dust jacket, verse

And not an indictment against, but I expect there will be confusion with a regular feature in a publication (Letters to the Editor, etc.) for which we have |department=. --  Gadget850 ^talk 11:19, 26 April 2014 (UTC)

No matter how elaborate the list of special-purpose parameters, there will always be unanticipated things for which something like |at= is needed, and there will always be a danger that someone will use |at= for something for which there is, in truth, a standard facility. For example, I didn't know there's a |department= parm, and in my ignorance would have used |at= for a letter-to-editor instead. Not sure what to do about that except make the documentation as searchable as possible. EEng (talk) 14:14, 26 April 2014 (UTC)

When I proposed |department=, I originally sandboxed it as |column= until the confusion was pointed out. I'm not adverse to column, and I think previous objections were for performance with the old core where we were being very conservative. But we should also consider other in-source locations. --  Gadget850 ^talk 18:05, 26 April 2014 (UTC)

I repeat that I think |at= is sufficient for seldom-needed stuff such as column #, as long as it can be used at the same time as |page= . EEng (talk) 18:09, 26 April 2014 (UTC)

Well, we have two potential conflicting uses of |at= and need to sort out how it is going to work, and how the other use will be handled by something else:

1. |at=Section 28|page=28.12
2. |page=28.12|at=column 2

Plus we have templates like {{Cite web}} where |at= is relevant to citing sections of a site, and where there are no page numbers, but we might want to independently cite something on the page at the URL, such as a sidebar. This is especially important now that HTML5 is breaking things up into HTML "<article>...</article>" segments that operating more like independent pages than <div>...</div> segments do.

Anyway, we need an "at" that is freeform and above page number and something similar, below page number (in paginated works) and below |at= in non-paginated works. Maybe |at2= for simplicity.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:03, 4 May 2014 (UTC)

Requesting help with CS1 date error

In the Benzodiazepine dependence article, there's a CS1 date error that I can't seem to fix:
{{cite journal |author=Professor Lader |coauthors=Professor Morgan, Professor Shepherd, Dr Paul Williams, Dr Skegg, Professor Parish, Dr Peter Tyrer, Dr Inman, Dr John Marks (Ex-Roche), Peter Harris (Roche), Tom Hurry (Wyeth) |editor1-first= |editor1-last= |editor1-link= |date=30 October 1980 – 3 April 1981 |title=Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005 |publisher=[[National Archives]] |location=England |url=http://nationalarchives.gov.uk/catalogue/displaycataloguedetails.asp?CATLN=6&CATID=7798554&j=1 |format=PDF }} generates:

• Professor Lader (30 October 1980 – 3 April 1981). "Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005" (PDF). England: National Archives. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)

This seems to be valid per MOS:DATEFORMAT#Ranges but still generates an error. What am I missing? Thanks! GoingBatty (talk) 15:39, 26 April 2014 (UTC)

Similar to an error reported by Editor Jonesey95. Fixed in the sandbox.

—Trappist the monk (talk) 16:25, 26 April 2014 (UTC)

Demonstrating the sandbox fix:

Cite journal comparison

Wikitext	{{cite journal|author=Professor Lader|coauthors=Professor Morgan, Professor Shepherd, Dr Paul Williams, Dr Skegg, Professor Parish, Dr Peter Tyrer, Dr Inman, Dr John Marks (Ex-Roche), Peter Harris (Roche), Tom Hurry (Wyeth)|date=30 October 1980 – 3 April 1981|format=PDF|location=England|publisher=[[National Archives]]|title=Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005|url=http://nationalarchives.gov.uk/catalogue/displaycataloguedetails.asp?CATLN=6&CATID=7798554&j=1}}
Live	Professor Lader (30 October 1980 – 3 April 1981). "Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005" (PDF). England: National Archives. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
Sandbox	Professor Lader (30 October 1980 – 3 April 1981). "Benzodiazepine Dependence Medical Research Council headquarters, Closed until 2014 - Opened 2005" (PDF). England: National Archives. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)

That looks like it works. The deprecated parameter error is still there for |coauthors=, of course. – Jonesey95 (talk) 20:17, 26 April 2014 (UTC)

For phased releases of new version

This is a Lua technical note. Due to the massive use of the wp:CS1 cite templates, an upgrade runs over 6-7 weeks to deploy the smallest change into any article. Meanwhile, if a change is needed immediately, it would be faster to hand-edit it into a cite. Instead, if the Lua modules were partially released in phases, then many articles (perhaps 100,000) could get the upgraded cite templates within 2-3 days (15-20x faster). As an example, if the cite templates were changed to invoke the new Lua modules only when parameter "last2=" is used, then that would cause many major articles to have the update perhaps 20x faster. See proposed markup:

{{#if: {{{last2|}}}
| {{#invoke: Citation/CS1/new|citation|CitationClass=web}}
| {{#invoke: Citation/CS1|citation|CitationClass=web}}<!--old version-->
}}

In this proposed case, the early release of the new Module:Citation/CS1/sandbox would be copied into Module:Citation/CS1/new, and then only pages with parameter "last2=" (about 124,000 pages) would have the new features within 3 days, while the remainder of the 2.1 million pages (with CS1 cites) would be reformatted over the 6-7 week period (perhaps after re-checking the results of the 3-day early release). In cases where another page needed immediate update, then setting one cite as "last2=&nbsp;" would cause that page to be reformatted within the 3-day period. Currently, we have occasional complaints that a problem, fixed in the /sandbox version weeks ago, is still annoying users due to the 2-3 month delay in upgrading all 2.1 million pages for a new feature. Because major pages tend to need new features, and major pages tend to use parameter "last2=" then the rapid 20x faster results could be applied in the targeted articles, as if the MediaWiki software had been improved to work much faster. The initial change to such partitioned cite templates would require a total reformat of all 2.1 million pages for 6-7 weeks, and then afterward the 3-day partial release would be possible. Meanwhile, hand-editing of cite formats is still the best method to get instant results in a limited set of pages. -Wikid77 (talk) 16:28, 27 April 2014 (UTC)

This seems excellent in every way, other than maybe the side effect that the "guinea pigs" being sort of tested on in the fast 3-day window are also most likely to be the major articles, but I guess that can't be helped.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:44, 28 April 2014 (UTC)

The guinea-pig aspect is lessened... by the quick ability to re-deploy a last-minute fix, within a 3-day reformat period. I think the developers have noted how a last-minute fix (even deployed within a day) will re-reformat the prior pages but also override the prior change for pages not yet reformatted (during the initial 3-day period), as a combined 4-to-5-day reformat, not always 6 days total. In contrast, with a 7-week reformat then a last-minute-fix might delay a re-reformat (fixing a glitch) until late during the 7 weeks, although each straggler could use a wp:null edit to force each page to reformat the glitch within a minute. With the Lua-based Template:Convert, the reformat of 550,000 pages took over 20 days (from 11 December 2013), and improvements have slowed to a crawl as leaving bugs for over 5 months now (where nonsense range 105–106 °F (41–41 °C) formerly showed 40.6–41.1 °C, rather than the nonsense "41-41" same result for different numbers 105/106). When it's not "wiki" then it is "slowki" with very slow improvements. -Wikid77 (talk) 10:14, 28 April 2014 (UTC)

Works for me. Glad someone is on this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:14, 28 April 2014 (UTC)

This sounds like a nightmare from a diagnostic and troubleshooting standpoint. A purge or null edit of an article would either invoke the current (old) version of the template or the new version of the template, but you would have to scan the whole article for an instance of |last2= (or whatever) in order to figure out which one it was using. Ugh.

Wouldn't it be easier to set up a null-edit bot, job queue job, or something equivalent, to perform periodic (daily? weekly?) null edits on the most popular articles?

Or, and I know I'm talking crazy now, what would it take to eliminate the root problem, which is that it takes two months for articles to be fully recategorized when the CS1 citation templates are updated? Is there a bugzilla bug for this issue, or is everyone resigned to the circumstance that two months is how long changes take to propagate? I, for one, am not resigned to that state of things, but I don't know enough WP history to understand why the situation exists. – Jonesey95 (talk) 03:11, 29 April 2014 (UTC)

New CS1 versions could be just weeks ahead of old: I think the MediaWiki developers are trying to design a new, faster type of multiple wp:Job_queue structure, auto-reformatting some major articles every day, but such software redesigns tend to take many months/years. The reason partitioned templates would work, to solve this cite-reformat problem, is because mainly the complex cites, with unusual parameters, tend to need new features/upgrades, and triggering a partial release by "last2=" (or also "author2=") would tend to reformat pages with complex cites. Also note: both the main release and the partial release could actually be the same revision of the CS1 cites, but the pages using "last2/author2=" would be reformatted weeks sooner then all pages using the main release of the CS1 Lua modules. The general principle is this: if a 20-times-shorter list of pages to reformat, plus the long list, are both processed at the same speed, then the shorter list will finish 20x times faster than reformatting all pages in the long list. Hence, the major pages (using last2/author2) would be re-rendered ~20x sooner than today's CS1 cites. In fact we might tend to release the partial release just 7-14 days sooner than the full, main release of the CS1 Lua modules. That is how we could reduce confusion between the features provided with last2/author2 cites versus all the other cites: keep the partial and main CS1 versions similar, within a few weeks of each other. However, we would definitely need to keep a formal release schedule, including feature/bug issues resolved by each particular release. By comparison, today's complexity is the uncertainty of whether a major article has yet been reformatting to display the current CS1 cites, or is still "in the queue" to be reformatted 7 weeks later. It would be great to look for last2/author2 and know whether the page would be updated within 3 days (or 50 days, as usual now). -Wikid77 17:18, 30 April 2014 (UTC)

Work or publisher? Specify host name?

Noting previous discussions on the topic of what goes in the "work" parameter and what goes in the "publisher" parameter, is there an expert here that could add their thoughts to the discussion over there (was linked to (User talk:Blethering Scot#Works and Publishers)? - 91.85.48.114 (talk) 17:46, 29 April 2014 (UTC) Disable link to a user's talk page to help prevent others from following the link to comment on a no longer existent thread. — Makyen (talk) 21:02, 29 April 2014 (UTC)

Ive moved the below comments from my talk page to here. Its not a discussion I'm interested in or started.Blethering Scot 20:20, 29 April 2014 (UTC)

I'm commenting because of the request at Help_talk:Citation_Style_1#Work_or_publisher.3F_Specify_host_name.3F. In the case of the online edition of a newspaper, I would still cite the name of the newspaper as the |work=. Looking at it from another perspective, the name of the website is The Telegraph in the masthead at the top of the website, and that is the name of the published work. (And given the possibility for confusion, newspaper names/website versions of newspaper names should have a city of publication listed, even when electronic.) Imzadi 1979 → 18:04, 29 April 2014 (UTC)

I'm not sure why the IP asked for comment on my talkpage. I'm not really interested in the subject or a debate on it. To me if citing the web then the work is the website and the publisher is the newspaper. Blethering Scot 18:19, 29 April 2014 (UTC)

I am also here in response to this request.

There is fundamental difference between a |work= and a |publisher=. A |work= is an object – which can be virtual – within which the the item was published (made available to numbers of people). For web based sources, this is often the website/domain name (without a preceding "www."). If the domain has a name under which it is called, it can be referred to as that name. In the case where the same name is given to a physical publication it can be helpful to also include the domain name to distinguish it from the physical version, or say something like "(online)". For something which is published in multiple places, you should clearly indicate where you saw it. In some instances this requires adding the domain name instead of just "(online)". An example of this is the BBC Online website which is published as both bbc.co.uk and bbc.com. If the content at the two domains was completely identical, then it would not be necessary to be specific. However, in this instance there are differences in what is displayed to the reader between the two domains. Because there are differences, a citation should be specific as to which was viewed by the person citing it either as the domain name alone, or in addition to, "[[BBC Online]]".

A |publisher= is a legal entity. Examples of legal entity types are people or companies. The publisher is the entity responsible for the actual publication. Usually this means they are the entity that pays for the object to be put into a form accessible by large numbers of people. Except in very limited situations (e.g. a tattoo), a publisher (legal entity) can not be a work (object). A work (object) can not be a publisher (legal entity). — Makyen (talk) 20:14, 29 April 2014 (UTC)

Yes. Though I would refine the bit of a publisher "pays for ...". More precisely, I think the publisher is the entity that takes responsibility for the publication, which is usually exercised on the basis of ownership. This can involve multiple levels. E.g., an editor of a journal may pay someone else to publish the journal, who in turn contract out the printing, or a news operation may be owned by some company which is in turned owned by some conglomerate. Of these cascading levels of ownership and control the publisher is the one that exercises control of content and takes responsibility for it. ~ J. Johnson (JJ) (talk) 22:19, 30 April 2014 (UTC)

This can't be tied to a notion of "responsibility", which would be legal WP:OR. Attaching some notion of "credit"/"blame" or "vouching" or "editorial oversight" is not the function of the parameter; it's sole purpose is aiding in identifying the work (e.g. to help in locating or distinguishing it). It's also not the same as where you got it. A press release by the WMF is |publisher=WikiMedia Foundation, no matter what website I found a copy of it on.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:31, 30 April 2014 (UTC)

Also, in th eabove example, the |publisher=BBC, not BBC Online. BBC Online is a website (i.e. |work=BBC Online) with two URL schemes, and WP doesn't care which of them we're citing, as long as it works or an archiveurl to it does.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:39, 30 April 2014 (UTC)

The cool thing now is that we have |via=, so for a press release from a government agency found online at PRNewsWire, we can do |publisher=Wikimedia Foundation |via=PRNewsWire, thus indicating the original publisher along with the republisher for an enhanced WP:SAYWHEREYOUGOTIT. Imzadi 1979 → 00:01, 1 May 2014 (UTC)

"Legal WP:OR"? Hardly. It is the nature of publishing that the publisher is the entity that controls certain functions (thus incurring responsibility for the result). Normally this is self-reported, and it takes no more "research" to discover than authors, volume, page numbers, etc. Identifying such an entity in the 'publisher=' parameter does not make the entity a publisher, we're only identifying the entity claiming to be the publisher. ~ J. Johnson (JJ) (talk) 20:50, 2 May 2014 (UTC)

Thanks for the various thoughts, but unfortunately the original question got lost somewhere along the way and isn't in this thread. Having finally located where it had been moved to, it is now reproduced just below: -- 91.85.36.175 (talk) 17:44, 6 May 2014 (UTC)

Works and Publishers (original question)

I was looking at your recent edit here. My understanding is that 'The Daily Telegraph' is the published work and that 'Telegraph Media Group' are the publishers (and that 'publisher' is usually omitted when citing newspapers).

From the CS1 template documentation, 'work' is an alias of 'newspaper'. Additionally, the 'location' parameter is usually used where the location is not mentioned within the newspaper name and not otherwise obvious. However, for a UK-centric article this is probably not necessary.

Your thoughts? - 91.84.92.16 (talk) 20:43, 22 April 2014 (UTC)

Its an interesting question but not one I overly concern myself about. First of all I never use the location parameter. Was this 100% printed in the telegraph newspaper or just published online, can we be certain of that?. If I'm citing a physical newspaper then i would use cite news and then I would go down the route you have, but if its web then I see nothing wrong really with how it was cited. At the end of the day as long as articles are well referenced and the citing contained within them is relatively consistent, then I don't see any harm really. This is the case in this article. Those are just my thoughts and I'm sure if you asked every editor you would get a fairly inconsistent answer.Blethering Scot 20:58, 22 April 2014 (UTC)

Thanks for the insights. I often find it's a bit tricky to work out which way is best. As you say, every editor seems to have their own way of doing things. - 91.85.48.114 (talk) 17:45, 29 April 2014 (UTC)

I am still interested in a definitive answer, though I suspect there will actually be a range of opinions. -- 91.85.36.175 (talk) 17:44, 6 May 2014 (UTC)

Request for an extra parameter

Hi people I think we could benefit from adding another parameter a parameter called trans_url. The reason for this is that sometimes websites we might be referencing might be in another language and hence, if this is the case, then it might be nice if we can provide one with a translated form of the doco we're referencing. For instance, I've been translating (with the help of Google Translate) some PDF files of summary of product characteristics for drugs that are only marketed in non English-speaking countries like Germany. These translations I keep in my Google Drive and hence I'd like to be able to give people a link to these translations so that others can use them too so they can expand the drug articles in question. Fuse809 (talk) 11:33, 1 May 2014 (UTC)

It sounds like you're posting translations of copyrighted material. If so, I believe that linking to that material from WP would be contrary to WP policy, even though it is of clear utility. See Wikipedia:Copyrights#Linking_to_copyrighted_works. – Jonesey95 (talk) 14:36, 1 May 2014 (UTC)

'trans_url' may have some benefits, but there are two really big problems here:

• "I've been translating" Sounds like you are translating copyrighted documents and storing them. As a derivative, the translations are still copyrighted.
• "These translations I keep in my Google Drive" That is a real problem, as we should never link to personal storage such as Google Drive, OneDrive, DropBox and the like. So you are storing copyrighted content in personal storage.

--  Gadget850 ^talk 11:17, 2 May 2014 (UTC)

Pipes in URLs

How should I deal with pipes ("|") in URLs, which cause an error, as can be seen in Stuart Latham. The template documentation doesn't seem to mention this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:54, 1 May 2014 (UTC)

Documented at {{cite news}} and others at url: replace pipes in urls with %7c

—Trappist the monk (talk) 13:17, 1 May 2014 (UTC)

Thank you. I failed to find that, because I searched for the string "pipe". Perhaps we should have a subtemplate, to wrap such URLS? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:54, 1 May 2014 (UTC)

Bots

We really need to start a list of bots and tools used with citations. Yesterday I flubbed a URL in a citation and got a very quick notice from ReferenceBot that I had caused a cite error. --  Gadget850 ^talk 11:21, 2 May 2014 (UTC)

User:BracketBot is another helpful one, although its scope is not limited to citations. There's also User:BattyBot (tasks 24, 25, and 28), User:Citation bot, User:RjwilmsiBot, User:Monkbot (multiple tasks), User:Dispenser/Reflinks (not a bot, but a bot-like tool that is used only on citations). – Jonesey95 (talk) 14:47, 2 May 2014 (UTC)

Things that can create CS1-style references include RefToolbar, MakeRef, Templator, Reflinks and others. -- 79.67.241.235 (talk) 16:18, 3 May 2014 (UTC)

See also the scripts at User:Ohconfucius/script/Sources and User:Ohconfucius/script/MOSNUM dates. GoingBatty (talk) 04:41, 4 May 2014 (UTC)

Migrating cite newsgroup to Module:Citation/CS1/sandbox

This is one of the examples from the documentation page for {{cite newsgroup}}:

{{cite newsgroup | author = A. S. Tanenbaum | title = LINUX is obsolete | date = 1992-01-29 | newsgroup = comp.os.minix | id = 12595@star.cs.vu.nl | url = http://groups.google.com/group/comp.os.minix/browse_thread/thread/c25870d7a41696d2/f447530d082cd95d?tvc=2 | accessdate = 2006-11-27 }}

→A. S. Tanenbaum (1992-01-29). "LINUX is obsolete". Newsgroup: comp.os.minix. 12595@star.cs.vu.nl. Retrieved 2006-11-27.

I'm wondering about the various external links. In this citation, the title links to news:12595@star.cs.vu.nl, |newsgroup= is an alias of |publisher= and links to news:comp.os.minix, and the parenthetical (Web link) text is linked to http://groups.google.com/...

Is this the correct way to link these parameters? My guess it that most readers haven't bothered to configure their computers for newsgroup access. It would seem that when |url= has a value, that value should combine with |title= to form a link that appears first in the rendered citation. Here I've used {{cite web}} to mimic how I think {{cite newsgroup}} should render:

A. S. Tanenbaum (1992-01-29). "LINUX is obsolete". comp.os.minix. 12595@star.cs.vu.nl. Retrieved 2006-11-27. {{cite web}}: External link in |publisher= (help)

Should the message id be displayed as 12595@star.cs.vu.nl or should it be 'hidden' under some form of text in the same way that |url= is currently hidden by the text 'Web link'?

Absent |url=, in Module:Citation/CS1 the message id value in |id= would be mapped to |url= as it does now. If both are missing, CS1 emits the citation-missing-url error message.

Comments and opinions?

—Trappist the monk (talk) 11:37, 3 May 2014 (UTC)

|url= in your first example should be the |archiveurl=. The actual URL is news:12595@star.cs.vu.nl. Specifically, the Google page is not canonical, and includes content, such as advertising, which is not part of the original post. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 3 May 2014 (UTC)

I didn't make up that example, it came from Template:Cite newsgroup/doc.

|archiveurl= requires |archivedate=. Neither the google link nor this other archive are dated except for the date of the original post. So where does an editor find that information? I suppose we could elect to except {{cite newsgroup}} from the |archivedate= requirement. I'm not much in favor of that idea because inconsistent rules produce confused editors. Here's the {{cite web}} example rewritten to use |archiveurl= and |deadurl=no:

A. S. Tanenbaum (1992-01-29). "LINUX is obsolete". comp.os.minix. Retrieved 2006-11-27. {{cite web}}: |archive-url= requires |archive-date= (help); External link in |publisher= (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 12:58, 3 May 2014 (UTC)

The "normal" way to access newsgroups is through a newsreader application. It therefore follows that websites preserving old posts are all archive copies of the proceedings. The archivedate for each post would be the actual date of the post. -- 79.67.241.235 (talk) 16:25, 3 May 2014 (UTC)

+1; though the date of a groups.google.com link should be no earlier than the creation of Google's Usenet archive. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 3 May 2014 (UTC)

Building on Andy's comment, the Google Groups service was created in February 2001, but Google acquired the archives from Deja News which date back to March 1995. Later in 2001, the University of Western Ontario donated its Usenet archives to Google, and those date back to May 11, 1981. So I would set the |archivedate= to be the same as the posting date so long as it was after May 11, 1981. Imzadi 1979 → 19:27, 3 May 2014 (UTC)

A constant signal conveys no new information. Setting |date=<post date> and then setting |archivedate=<post date> because we don't know the real archive date, seems rather pointless.

Yeah, normal access to usenet newsgroups is by way of a newsreader application. But what percentage of the general reading population has bothered to set up a news reader? I don't know the answer to that question but I suspect that the answer is in the single-digit percentages. It seems to me best to accommodate the readership by linking |title= with |url= (when present) rather than make the web-accessible link the third link in the citation. When |url= is empty or omitted it would seem best to include {{link note}} functionality stating that a news reader application is required.

—Trappist the monk (talk) 11:08, 4 May 2014 (UTC)

This has only 455 transclusions, and I agree on the number of news reader users. I suggest we treat the news link as any other id and present it as such—

Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". comp.os.minix. Newsgroup: 12595@star.cs.vu.nl. {{cite web}}: External link in |publisher= (help)

--  Gadget850 ^talk 11:31, 4 May 2014 (UTC)

We could do that. 'Newsgroup' probably isn't the correct identifier label because in that citation, comp.os.minix is the newsgroup and 12595@star.cs.vu.nl is the article or post id. Perhaps the identifier with label might be: Usenet 12595@star.cs.vu.nl or Post id 12595@star.cs.vu.nl or something along those lines?

—Trappist the monk (talk) 12:56, 4 May 2014 (UTC)

Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". Newsgroup comp.os.minix. Usenet 12595@star.cs.vu.nl. {{cite web}}: External link in |publisher= (help) --  Gadget850 ^talk 15:07, 4 May 2014 (UTC)

doi: or DOI

I've noticed that citations that include |doi= render the identifier type in lowercase followed by a colon (doi:) but that other identifier types are rendered in uppercase without a trailing colon as can be seen in this citation:

Viollet, Benoît (January 2003). "The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. 111 (1): 91–8. doi:10.1172/JCI16567. PMC 151837. PMID 12511592. Retrieved 2012-11-17.

Is there a reason for this difference?

—Trappist the monk (talk) 12:01, 4 May 2014 (UTC)

I suspect that the reason is that this presentation appears to be recommended by the DOI Handbook. "When displayed on screen or in print, a DOI name is preceded by a lowercase "doi:" unless the context clearly indicates that a DOI name is implied." I think that second part may give us enough wiggle room to standardize on "DOI 10.1000/acbdefg", since linking DOI "clearly indicates that a DOI name is implied." – Jonesey95 (talk) 16:29, 4 May 2014 (UTC)

Also ARXIV and Bibcode. All other identifiers use   as a separator between the identifier label and its value.

—Trappist the monk (talk) 12:34, 4 May 2014 (UTC)

Should be consistent across identifiers. --  Gadget850 ^talk 16:22, 4 May 2014 (UTC)

(edit conflict) The arXiv identifier scheme is described here. As far as I know, "arXiv" has always been written in lower case with the capital "X" in the middle. Unlike DOI, ISBN, and other identifiers, "arXiv" and "Bibcode" are not initialisms.

BTW, If we do not yet do any arXiv validation, the page linked above may be a good starting point. And the Bibcode page provides some info that might help to create validation code for Bibcodes. – Jonesey95 (talk) 16:29, 4 May 2014 (UTC)

In Module:Citation/CS1/sandbox

9108-0703 format:

"Pass (hyphenated archive)". Journal. arXiv:hep-th/9405085.

"Pass". Journal. arXiv:math.gs/0309136.

"fail: missing solidus". Journal. arXiv:math.gs0309136. {{cite journal}}: Check |arxiv= value (help)

"fail: misplaced hyphen". Journal. arXiv:-math.gs/0309136. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid year". Journal. arXiv:math.gs/9009136. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid year". Journal. arXiv:math.gs/0809136. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid month". Journal. arXiv:math.gs/9107136.

"fail: invalid month". Journal. arXiv:math.gs/0704136. {{cite journal}}: Check |arxiv= value (help)

"fail: too many article id digits". Journal. arXiv:math.gs/03091360. {{cite journal}}: Check |arxiv= value (help)

"fail: not enough article id digits". Journal. arXiv:math.gs/030913. {{cite journal}}: Check |arxiv= value (help)

0704- format:

"Pass (without version)". Journal. arXiv:0706.0001.

"Pass (with version)". Journal. arXiv:0706.0001v2.

"fail: missing dot". Journal. arXiv:07060001. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid year". Journal. arXiv:0606.0001. {{cite journal}}: Check |arxiv= value (help)

"fail: invalid month". Journal. arXiv:0703.0001. {{cite journal}}: Check |arxiv= value (help)

"fail: too many article id digits or missing version separator". Journal. arXiv:0706.00012. {{cite journal}}: Check |arxiv= value (help)

"fail: not enough article id digits". Journal. arXiv:0706.001. {{cite journal}}: Check |arxiv= value (help)

—Trappist the monk (talk) 16:47, 5 May 2014 (UTC)

Auto filling duplicates "ed."

Had a very quick search of this page and this issue does not seem to have been discussed.

In my experience, autofilling the template with an isbn always populates the "Edition" field with e.g., 2nd Ed., 3rd Ed., etc. However, the "ed." somehow becomes doubled when the citation is created, meaning that the user has to delete the "ed" from the form, somewhat defeating the whole autofill thing. Thoughts? 92.41.84.153 (talk) 22:48, 4 May 2014 (UTC)

I don't think that's a Citation Style 1 issue but rather, an issue with the tool that you are using to do the autofilling. What tool are you using?

—Trappist the monk (talk) 22:56, 4 May 2014 (UTC)

Bad classes

Following this edit by Trappist the monk (talk · contribs), {{Cite AV media notes}} sets |CitationClass=AV media notes - this means that the generated HTML is <span class="citation AV media notes">...</span>. Only two classes (citation album_notes) were necessary before, and only two (citation book) are needed for e.g. {{cite book}}, so why are four classes necessary now? --Redrose64 (talk) 11:51, 5 May 2014 (UTC)

I'm not understanding your question. {{cite book}} has |CitationClass=book, {{cite journal}} has |CitationClass=journal, {{cite news}} has |CitationClass=news, {{cite web}} has |CitationClass=web. Each of the other citation templates that use Module:Citation/CS1 have their own |CitationClass parameter that mimics these four. The module uses these parameters for the rendered html and to distinguish between the various citation templates when special handling of parameters is required.

Is there a problem?

—Trappist the monk (talk) 12:45, 5 May 2014 (UTC)

Spaces are not valid in class names, they are delimiters.[1] Thus class="citation AV media notes" is applying four separate class names. class="citation AV-media-notes" is two class names.

And I am still not convinced that these are used anywhere. If they are, then creating new classes without coordinating with whoever uses them is a problem. --  Gadget850 ^talk 13:06, 5 May 2014 (UTC)

This post of mine from just under a year ago is related.

The classes are useful for those (like me) who take care to ensure that articles don't mix WP:CS1 with WP:CS2. I have set up a CSS rule that styles all citations which use either CS1 or CS2 templates so that they show with a pink background. This is followed by a rule which alters that background to yellow for the CS1 templates. Therefore, if prior to editing an article, I see that all the refs are yellow, I know that the article uses CS1, so I mark up my refs with {{cite book}} etc.; if they're all pink, it's CS2, so I mark up my refs with {{citation}}. If I see both pink and yellow in the same article, there are two possible reasons: (i) it's got mixed citation styles and should be resolved one way or the other; (ii) I've not set up a rule for one or more of the CS1 templates. If you're curious, see User:Redrose64/common.css and search for "show refs using citation templates in colour". Note particularly the line

span.album_notes, /* cite album-notes */

- if I alter that to

span.AV media notes, /* cite AV media notes */

it will try to apply the rule to HTML marked up with <notes>...</notes> (which doesn't exist) within <media>...</media> (which also doesn't exist) within <span class="AV">...</span>. --Redrose64 (talk) 14:46, 5 May 2014 (UTC)

I see the utility there. We could simply use class="citation cs1" for all CS1 templates.

This leads to a new question. {{cite music release notes}} used musicrelease. We merged that template to {{cite AV media notes}}. If the class is truly used, then when we merge templates, we should add the class of the old template to the class of the new template. --  Gadget850 ^talk 14:56, 5 May 2014 (UTC)

Except that Module:Citation/CS1 uses |CitationClass= to determine which template is being used so that it can correctly interpret the meaning of various parameters, I might agree with making them all |CitationClass=citation-CS1 or somesuch.

At the next update of Module:Citation/CS1 I'll change {{Cite AV media notes}} to be |CitationClass=AV-media-notes and {{Cite DVD notes}} to |CitationClass=DVD-notes.

—Trappist the monk (talk) 17:47, 5 May 2014 (UTC)

sfn and CS1

I have read the discussion above about {{sfn}} and years but I don't know where we are. I have an article MV Alam Pintar and FV Etoile des Ondes collision where I want to use sfn to link to three {{cite book}} references with the same author and year. In sfn I have 2010, 2010a and 2010d as years. In cite book I originally had "date" in the format Month 2010 and "year" as one of the three strings above. When I saw a CS1 date flag I removed "year" and put "date" as Month 2010a, etc. This (unsurprisingly to me) is also being flagged. In both situations the links resolve correctly. Am I making a silly mistake or is there a problem? Can someone advise before the bots come round? Thincat (talk) 16:24, 5 May 2014 (UTC)

PS I think this has nothing to do with RefToolbar because, although I use it, I generally copy edit what it produces, as I have done in this case. Thincat (talk) 16:31, 5 May 2014 (UTC)

It's not showing any little red error messages, and (as you say) the links work, so I don't think that there's a problem here. --Redrose64 (talk) 16:53, 5 May 2014 (UTC)

No, it had a hidden category "CS1 errors: dates". However, Trappist has kindly corrected a (mildly) malformatted archivedate 04 may 2014 and now even the hidden category has gone. Thank you both: false alarm. Thincat (talk) 17:02, 5 May 2014 (UTC)

You seem to have figured out the date issue and it looks correct. Because these documents are pdfs you should add |format=pdf because the icon doesn't have an |alt= description. I also wonder about MAIB. As I understand it, Marine Accident Investigation Branch is the author and part of Department for Transport who is the publisher. Making Marine Accident Investigation Branch the author requires changing |ref=harv to |ref={{sfnref|MAIB|2010a}}. Also, I wonder if for MAIB2010a you should use |chapter=Annexes.

I also wonder about MAIB2010d. That is a different publication, a journal, with an identifiable author. That citation can use |ref=harv but the {{sfn}}s change to {{sfn|Meyer|2010}}. Perhaps like these?:

• Marine Accident Investigation Branch (September 2010). "Report on the investigation of the collision between the bulk carrier Alam Pintar and the fishing vessel Etoile des Ondes" (pdf). Department for Transport.
• Marine Accident Investigation Branch (September 2010a). "Report on the investigation of the collision between the bulk carrier Alam Pintar and the fishing vessel Etoile des Ondes" (pdf). Department for Transport. {{cite web}}: |chapter= ignored (help)
• Meyer, Stephen (April 2010). "Introduction" (pdf). Safety Digest Lessons from Marine Accidents (1/2010). Marine Accident Investigation Branch. {{cite journal}}: Invalid |ref=harv (help)

—Trappist the monk (talk) 17:31, 5 May 2014 (UTC)

I shall look into all that and will learn a lot. I was pleased with myself when I first was able to use sfn at all! Many thanks. Thincat (talk) 18:12, 5 May 2014 (UTC)

Yes, that looks better. I had no idea what "ref=harv" meant, I just knew I had to put it in. As for publishers, I don't know. In the olden days I think HMSO used to publish everything UK governmental. Anyway, at least as an exercise, I've followed your opinion. When I get stuck with references I look back on articles I've worked on previously so this will be a good reference for me! Thincat (talk) 19:03, 5 May 2014 (UTC)

The role of HMSO was more in the nature of printer and distributor than publisher. They didn't really make content decisions. LeadSongDog come howl! 20:28, 5 May 2014 (UTC)

Cite PDF page # as well as book's page #?

In regards to cite book, probably also cite web: I was just now looking for a way to directly cite a page in a PDF, because with a lot of unlisted page numbers it wasn't obvious, especially if you're only scrolling down instead of across. So I wanted to point out that it's page 186 in the PDF, which maps to page 173 in the book itself. Is there a good way to do this? I don't even know if browser plugins understand any kind of hash-links, but it'd be good info regardless, since I personally couldn't find it for a bit with just the book's page #. I settled on "|page=173 (pdf p.186)", but I figured I'd ask what everyone else thinks of this. (Or if it's just not important at all.) SilverbackNet^(talk) 09:53, 6 May 2014 (UTC)

This was being discussed somewhere else very recently (I'm forgetting where exactly), but the short version is we should not do this, because PDF pagination is dependent upon viewer software and even screen resolution – net every app on every device behaves exactly like Adobe Acrobat Viewer for Windows or whatever you're using. Sources that have pagination in them should cite those page numbers; our readers can read and will figure it out. Those that are not paginated need to be specific in some other way, like naming the titled chapter/section, etc.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:25, 6 May 2014 (UTC)

I have wondered about that sometimes and I'm glad that was agreed. Thincat (talk) 10:35, 6 May 2014 (UTC)

Where a single page (or a single range) is involved I have previously used

| url=http://www.example.com/that-file.pdf#page=12 | format=PDF | page=9 | or

| url=http://www.example.com/that-file.pdf#page=12 | format=PDF | pages=9–11 |

with the |url= parameter pointing at the correct page as far as the reader software goes (and the user takes pot luck whether their reader actually scrolls to the right place), and the |page= parameter indicating the page number physically printed on that page. -- 79.67.241.223 (talk) 12:51, 6 May 2014 (UTC)

Not really different from hard copy. Page 1 in a book might be the 6th or 10th physical page. --  Gadget850 ^talk 14:27, 6 May 2014 (UTC)