Help talk:Citation Style 1/Archive 9

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

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

→

Archive 15

urls in |title=

Latest comment: 8 years ago10 comments3 people in discussion

Per this discussion, this discussion, and this discucssion, I have added a test that finds external wikilinks within the content of |title=. I expect to add calls to this same test for |chapter= and |website=. Templates that fail the test are added to Category:CS1 errors: external links

{{cite book/new |title=[//example.com Title]}}

Title. {{cite book}}: External link in |title= (help)

{{cite book/new |title=[http://example.com Title]}}

Title. {{cite book}}: External link in |title= (help)

External wikilink with leading text:

{{cite book/new |title=Leading text [http://example.com Title]}}

Leading text Title. {{cite book}}: External link in |title= (help)

External wikilink with trailing text:

{{cite book/new |title=[http://example.com Title] trailing text}}

Title trailing text. {{cite book}}: External link in |title= (help)

External wikilink with leading and trailing text:

{{cite book/new |title=Leading text [http://example.com Title] trailing text}}

Leading text Title trailing text. {{cite book}}: External link in |title= (help)

The external wikilink must be protocol relative or have valid scheme (uses much the same test as is newly implemented for url tests):

{{cite book/new |title=[8http://example.com Title]}}

[8http://example.com Title]. {{cite book}}: External link in |title= (help)

The external wikilink must be complete:

{{cite book/new |title=[http://example.com Title}}

[http://example.com Title. {{cite book}}: External link in |title= (help)

{{cite book/new |title=http://example.com Title]}}

http://example.com Title]. {{cite book}}: External link in |title= (help)

The limitations of the test as just described mean that it does not answer the challenge posed here. I chose a vague error message so that should we decide to change the test to find urls, not just external wikilinks, in parameter values, we can do so without needing to change messaging and categorization.

—Trappist the monk (talk) 22:27, 19 August 2015 (UTC)

An external link on the whole title can obviously be replaced by |url=, but this change is going to prevent editors from making external links on only part of a title. I don't know of a valid use case for doing that, but maybe there is one. Before making this change, is there any way to search for the citations that already have links on part of but not the whole title, so that we can judge whether any of them are appropriate? —David Eppstein (talk) 22:31, 19 August 2015 (UTC)

This search string should answer: insource:/\| *title *=[^\|\}]*http/ but it doesn't. The regex works in AWB but is not working for me as an insource: search. This search string: insource:/\| *title *=[\|\}]*http/ at least returns |title=http...

The reason for this test is that external links (as external links, not plain text) in |title= corrupt the metadata. This is why we have |url=.

—Trappist the monk (talk) 23:09, 19 August 2015 (UTC)

Sure, but I'm primarily concerned about being able to generate a correct rendering of all valid citations, and only secondarily concerned about generating proper metadata for them. So if this change prevents us from formatting valid citations that happen to include external links in only part of the title, then it's a bad thing, even if it also constrains the citations in such a way as to make it easier to generate valid metadata. In this particular case, it seems likely enough that there are no valid citations that we'd be breaking, but I'm not certain of that, and you haven't convinced me that you have any evidence of that either. So running a search that would find them would be helpful, if we could get such a search to work. —David Eppstein (talk) 23:18, 19 August 2015 (UTC)

Perhaps it is working, sort of. insource:/\| *title *=[^\|\}]*http/ finds four results (it should find a lot more). The regex means:

Find a pipe, zero or more spaces, the string 'title', zero or more spaces, an equal sign, zero or more characters that are not a pipe or closing curly brace, and the string 'http'.

That means it should find |title=http.... It didn't, but it did find these (none of which are cs1|2):

| title = [http://www.google.com/patents/US2615129 Synchro-Cyclotron]

|title=Jamaica by-election (April 13, 2005): Kingston West<ref>http://www.eoj.com.jm/content-70-243.htm</ref>

|title = Surrey County Council election results, 2009, Guildford<ref>Sources: http://www1.surreycc.gov.uk/election2009/</ref>

|title=2014 Minnesota Legislature - House District 39A<ref>http://electionresults.sos.state.mn.us/Results/StateRepresentative/20?districtid=431</ref>

If we can presume that the search tool works well enough to find these where the url occurs after the beginning of |title= then that may mean that cs1|2 templates that have urls embedded midway or at the end of |title= do not exist.

That leaves us with urls that begin the |title=parameter value. For that, this search string:

insource:/\| *title *= *http/ (c. 290 hits)

This search string finds external wikilinks at the beginning of the |title= value:

insource:/\| *title *= *\[http/ (c. 150 hits)

These are the type of url-in-title that the test is currently configured to catch.

—Trappist the monk (talk) 00:26, 20 August 2015 (UTC)

I generally support this error check. I believe that due to the uncertainty that exists in describing this situation, the failure of the insource search, and the wide variety of weirdness that editors put into citation templates, we should either hide this error message by default and/or have this check result in a maintenance message rather than a red error message. I think that we are going to see some false positives. I think that our credibility is diminished when we roll out code to all readers that shows errors for valid text like |edition=Illustrated, as we have recently done, and I think this particular check has a high likelihood of doing that.

One note about the terminology used in this discussion section: I believe that on WP, "wikilink" means a link to an article within WP, while "external link" means a link (generally a URL) that leads outside of WP. See Help:Link#Wikilinks and Help:Link#External_links. I do not think that the phrase "external wikilink" used above has a valid meaning on WP. Let's be clear in our use of language. – Jonesey95 (talk) 04:41, 20 August 2015 (UTC)

If that's all this check dug up, I'm happy enough with this new restriction. I don't think any of those are good uses of external links in titles. BTW, re the above comment: I was assuming that "external link" meant single-bracketed links and that "wikilink" meant double-bracketed links. The double-bracketed kind usually stay within WP but not always; for instance, it's possible to use double-bracket syntax for doi or arXiv links. —David Eppstein (talk) 04:56, 20 August 2015 (UTC)

I've looked at about 50 of the c. 150 pages returned by the insource:/\| *title *= *\[http/ search. Of those, I found three where the |title= value was more than just an external wikilink:

{{cite web|last=Flexible Plug and Play website |title=[http://www.flexibleplugandplay.co.uk/ Flexible Plug and Play]''accessed 18 October 2012}}

Flexible Plug and Play website. "Flexible Plug and Playaccessed 18 October 2012". {{cite web}}: External link in |title= (help); Missing or empty |url= (help)

{{cite web | last =FamilySearch.org | first = | coauthors = | title = [https://familysearch.org/pal:/MM9.1.1/K42Z-L65 1940 US Census] and [https://familysearch.org/pal:/MM9.1.1/KYFC-72S United States Public Records Index] | publisher =FamilySearch.org | url = }}

FamilySearch.org. "1940 US Census and United States Public Records Index". FamilySearch.org. {{cite web}}: Cite has empty unknown parameter: |coauthors= (help); External link in |title= (help); Missing or empty |url= (help)

{{cite press release |title=[http://www.letu.edu/_Other-Resources/presidents_office/about.html] LeTourneau University Names New President |publisher=LeTourneau University |date=2007-03-08 |url=http://www.letu.edu/opencms/opencms/_Other-Resources/presidents_office/news/presAnnouncement.html |accessdate=2007-08-09}}

"[http://www.letu.edu/_Other-Resources/presidents_office/about.html] LeTourneau University Names New President" (Press release). LeTourneau University. 2007-03-08. Retrieved 2007-08-09. {{cite press release}}: External link in |title= (help); line feed character in |title= at position 68 (help)

In each of the cases above, the templates are clearly malformed or misused.

I chose to use the term 'external wikilink' because the code is looking for urls formatted with wiki markup: opening square bracket, url, optional link-label text, closing square bracket. I used this term to distinguish that form of url from a plain url or external link (one without the wiki markup).

I did consider maintenance rather than errors but chose error because:

• url-in-title corrupts the metadata
• url-in-title can trigger access-date-requires-url errors
• for {{cite web}} url-in-title triggers missing-or-empty-url errors
• for other templates, url-in-title can trigger format-requires-url errors
• automatic pdf format annotation doesn't work when the url is part of title

If the insource search results are to be believed, there aren't enough url-in-title errors to warrant hiding them.

—Trappist the monk (talk) 12:54, 20 August 2015 (UTC)

WP:VPT is your friend:

insource:title insource:http insource:/\| *title *=[^\|\}]*http/

That search string first finds pages with the strings 'title' and 'http' and then does the regex search on those pages. However, more results aren't necessarily better results. In the first page of results, these:

{{cite web | url= | title=http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation) | publisher=City of Edmonton | date=March 2011 }}

"http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation)". City of Edmonton. March 2011. {{cite web}}: External link in |title= (help); Missing or empty |url= (help)

{{Cite journal|duplicate_title=The Beverly clock|type=Abstract|journal= [[European Journal of Physics]]|publisher=IOPscience|title=http://iopscience.iop.org/0143-0807/5/4/002}}

"http://iopscience.iop.org/0143-0807/5/4/002". European Journal of Physics (Abstract). IOPscience. {{cite journal}}: External link in |title= (help); Unknown parameter |duplicate_title= ignored (help)

clearly, both malformed. But, the search also finds stuff like this:

<ref>[http://stljazznotes.blogspot.com/2014/07/bull-of-heaven-performing-at-lnac-this.html|title=St. Louis Jazz Notes: Bull of Heaven performing at LNAC this Saturday, August 2]</ref><ref>[http://news.allaboutjazz.com/jazz-this-week-st-louis-cabaret-festival-bull-of-heaven-all-that-tap-xxiii-and-more.php|title=Jazz This Week: St. Louis Cabaret Festival, Bull of Heaven, "All That Tap Xxiii," and More]</ref>

which is also clearly broken but outside the cs1|2 remit.

—Trappist the monk (talk) 13:37, 20 August 2015 (UTC)

I have added code that also checks |chapter= and |work=:

{{cite book/new |title=Title |chapter=[//example.com Chapter]}}

"Chapter". Title. {{cite book}}: External link in |chapter= (help)

{{cite journal/new |title=Title |journal=[//example.com Journal]}}

"Title". Journal. {{cite journal}}: External link in |journal= (help)

The test can handle all three in the same template:

{{cite encyclopedia/new |title=Title |article=[//example.com Article] |encyclopedia=[//example.com Encyclopedia]}}

"Article". Title. Encyclopedia. {{cite encyclopedia}}: External link in |article=, |encyclopedia=, and |title= (help)

The error message lists the 'prime' (for lack of a better term) alias. Is there some way to mark the prime alias in an error message that tells readers that the message for this parameter may be aliased? For instance, |work= could be |newspaper=, |journal=, |encyclopedia=, ... We might tweak the error message so that it reads:

External link in |<work>=

External link in <|work=>

External link in |work=

External link in |work=

Other, better ideas?

—Trappist the monk (talk) 22:16, 20 August 2015 (UTC)

How do you suppress errors when titles are missing?

Latest comment: 8 years ago32 comments8 people in discussion

For instance, in the PMNS matrix article, we have citations such as

*{{cite journal |last1=Pontecorvo |first1=B. |year=1957 |title=Mesonium and anti-mesonium |journal=[[Zhurnal Éksperimental’noĭ i Teoreticheskoĭ Fiziki]] |volume=33 |pages=549–551 |bibcode= |doi= }} reproduced and translated in {{cite journal |last1=<!----> |first1=<!----> |year=1957 |title=<!----> |journal=[[Soviet Physics JETP]] |volume=6 |pages=429 |bibcode= |doi= }} 

Giving out

• Pontecorvo, B. (1957). "Mesonium and anti-mesonium". Zhurnal Éksperimental’noĭ i Teoreticheskoĭ Fiziki. 33: 549–551. reproduced and translated in Soviet Physics JETP. 6: 429. 1957. {{cite journal}}: Missing or empty |title= (help)

There's no reason why this should be considered invalid. How do you suppress the error message? Headbomb {talk / contribs / physics / books} 15:34, 29 July 2015 (UTC)

Each citation template is a stand-alone object that produces stand-alone metadata. While the text "reproduced and translated in" visually connects the two in the article, there is no such connection in the metadata because there is no inter-template communication.

If both journal articles were consulted when writing PMNS matrix, then both templates should have all of the required information and both used separately. If only one journal article was consulted for PMNS matrix then only that template is required (the other, completed template could be added to §Further reading or similar section – perhaps with a note identifying it as the original or the translation).

When the article's citation style dictates it, you can use |title=none in {{cite journal}} and {{citation}} when |journal= is set to suppress the error message. It is my belief that this sort of shorthand is inappropriate because it leaves the metadata incomplete.

The parameters |language=; |script-title= for the original language and/or |title= for a transliterated title; and |trans-title= for the translated title would be appropriate for the first (original language) template.

—Trappist the monk (talk) 16:16, 29 July 2015 (UTC)

This rigid attitude is driving people away from using the citation templates, with the result that no metadata at all is produced. For example, my recommendation here (as I have used and seen in several other articles) would be to manually format the second part of the citation (where this article appears in translation, or in some other cases where it appears in an edited volume of journal reprints) since our citation templates are unable to produce elided citations in an appropriate format, the appearance to our readers should be a much higher priority than the quality of the metadata, and (as evidenced above) our template software maintainer is unwilling to fix the problem. —David Eppstein (talk) 22:53, 3 August 2015 (UTC)

Agreed. And see WP:SAYWHEREYOUGOTIT.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:37, 30 July 2015 (UTC)

I would be so glad if |title=none worked as claimed, but, hmmm [looking at “Jones (1957). "none". {{cite journal}}: Cite journal requires |journal= (help)”], it doesn't. And you seem to have missed the implication that if the metadata must always be complete, then only those sources with complete metadata - more precisely, complete COinS metadata - can be cited. ~ J. Johnson (JJ) (talk) 22:05, 3 August 2015 (UTC)

But it does work when you use |title=none in {{cite journal}} and {{citation}} when |journal= is set. Rewriting your example as cs1:

{{cite journal |last1=Jones |year=1957 |title=none |journal=Journal}}

Jones (1957). Journal.{{cite journal}}: CS1 maint: untitled periodical (link)

and as cs2:

{{citation |last1=Jones |year=1957 |title=none |journal=Journal}}

Jones (1957), Journal{{citation}}: CS1 maint: untitled periodical (link)

Yes, I know that the metadata for such citations is incomplete and as such I don't care for this 'style' (which apparently really exists in some scholarly communities). I could have chosen to omit mention this functionality in my first post in this discussion. Of course, if I had omitted it, someone else would have pointed that out.

—Trappist the monk (talk) 00:43, 4 August 2015 (UTC)

That's fine where the source is a journal. Can you make it work with |chapter/contribution= where the source is not a journal? ~ J. Johnson (JJ) (talk) 21:30, 4 August 2015 (UTC)

And as I said in another post here, having the exact value |title=none should work in some other situations. It's very irksome (both for make-work reasons and for accuracy reasons) to have to input fake "titles" for citing something's homepage, as in this example:
     "Ministry of Foreign Affairs Homepage". MoFA.gov.pk. Government of Pakistan. 2013. Retrieved 4 August 2015.
which I had to do yesterday at both Pakistan and Foreign relations of Pakistan (and "Government of Pakistan" is kind of a lame |publisher= value). Properly, this would just be something like:
     {{cite web |title=none<!--homepage--> |work=MoFA.gov.pk |url= http://www.mofa.gov.pk/index.php |publisher=Pakistan Ministry of Foreign Affairs |date=2013 |accessdate=4 August 2015}}
but the template won't permit this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:11, 6 August 2015 (UTC)

I would have used |title=Ministry of Foreign Affairs [homepage], using the brackets to show that "homepage" didn't actually appear in the source. Printed style guides call for just using a description with no italics nor quote marks if a source has no title, but this family of templates can't do that. — Preceding unsigned comment added by Jc3s5h (talk • contribs) 00:20, 6 August 2015‎

Reasoned, but my point is that it shouldn't be necessary.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:20, 6 August 2015 (UTC)

{{cite report}} renders title without title styling:

Ministry of Foreign Affairs [homepage]. Government of Pakistan. 2013. Retrieved 4 August 2015.

Setting |type=none disables the default type annotation.

—Trappist the monk (talk) 10:10, 6 August 2015 (UTC)

But it's not a report, so it's wrong. I consider lying to the template to make it look right intolerable. If I found an article that did that I would rip all the templates out and switch to a citation style based on a paper style guide. Jc3s5h (talk) 15:39, 6 August 2015 (UTC)

You wrote: a description with no italics nor quote marks if a source has no title, but this family of templates can't do that. I merely point out that, in fact, a member of this family of templates does render a description in lieu of title without styling.

Without doubt, we can concoct a mechanism that disables the default title styling; I once suggested a separate title parameter for that purpose which conversation didn't go very far. Since we have parameters like |name-list-format= and |mode= we could have something similar for titles where the parameter takes a named constant and applies a defined rule to the content of |title= or not even bother with a new parameter and just change |mode= processing to accept a comma delimited list of descriptors so {{cite web}} might have |mode=cs2, desc to render a web cite in cs2 style with an unstyled title.

—Trappist the monk (talk) 16:27, 6 August 2015 (UTC)

Works for me. While I wouldn't go as far as Jc3s5h vows (probably tongue-in-cheek), I too object to having to use the wrong template, both on the basis that it's using the wrong template, and the more pragmatic one that the next editor to come along is liable to "fix" it to use the correct one that does the undesirable formatting.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:20, 6 August 2015 (UTC)

As before: can you make "none" work with |chapter/contribution= where the source is not a journal? ~ J. Johnson (JJ) (talk) 23:43, 11 August 2015 (UTC)

If you are asking for |chapter/contribution=none, simply omit |chapter/contribution= or leave it blank.

—Trappist the monk (talk) 13:29, 12 August 2015 (UTC)

No, I am asking for suppression of the "missing or empty title" error message, or explicit suppression of a title. Omitting use of a citation template is even simpler, but that is not a constructive answer.

To be more explicit, can you make |title=none (or some variation) suppress the title without having to specify {{cite journal}} or |journal=? E.g., for "{{citation |year= 1990 |title=none |author= Folland et al. |chapter= Chap. 7: Observed Climate Variation and Change }}", which produces: Folland; et al. (1990), "Chap. 7: Observed Climate Variation and Change", none {{citation}}: Explicit use of et al. in: |author= (help). ~ J. Johnson (JJ) (talk) 20:27, 12 August 2015 (UTC)

These discussion again? My position as stated there has not changed.

—Trappist the monk (talk) 11:59, 13 August 2015 (UTC)

What, that attitude again? Trappist, you're being a jerk. There are cases where it is quite valid to cite a chapter (or contribution) in a larger work without directly including the title of the work. (For brevity I omit the winding, tendentious details we have previously traced out.) Yet you are obsessed with requiring a title for all uses. When this was discussed last January (see cite journal without Ctitle) you grudgingly ("I'd rather not if I can avoid it") accepted Gadget850's proposal (endorsed by Imzadi) that |title=none should suppress the error message. Yet you adamantly refuse to make any concession for other uses, You are fixated on this idea that every citation template must produce "stand-alone" (complete within itself?) COinS metadata, never mind that your rigid attitude (as enunciated above by David Eppstein) is going to drive people away from using templates and thereby reduce the metadata. The degree of your obsession is indicated in the time and effort you have spent objecting and resisting this (and in developing the misbegotten harvc template), which is likely more time than it would have taken to extend the "none" exception. (Or even better, to just eliminate the title test.) To insist that ALL citations must be "COinS complete" (which implies that only sources with complete COinS data can be cited using templates) is counter-productive. In the end your position is just "I don't like it." That is a very feeble argument. And your intransigence impairs the work of others. ~ J. Johnson (JJ) (talk) 21:00, 13 August 2015 (UTC)

To be honest JJ, you haven't shown consensus for your change. Trappist has provided an alternative method, and your use case is unrelated to the thread above from my read. If you really think the template should change, start an RFC or a straw poll, lay out all the options (since there are now alternatives), and ask the community whether it makes sense to support what you think should be supported. --Izno (talk) 21:17, 13 August 2015 (UTC)

Consensus? Off-hand I don't recall where the consensus was for Trappist to break existing valid usage. Nor was any explicit consensus needed for him to add the 'journal' exception. As to alternatives, the one he provided is {{harvc}}, which is an abomination that makes citation more complex and harder to understand (discussed elsewhere). The other alternatives are: 2) to characterize a non-journal source as a journal (which amounts to metadata corruption); 3) not use citation templates; 4) not write anything requiring citations. #2 seems the least offensive, but even so this "lying to the template" (as Jc3s5h calls it) is "right intolerable", while SMc has noted the pragmatic problem where such misuses are "fixed" by subsequent editors. None of these alternatives are good, but everyone else has to accept them because one editor "do[es]n't care for this 'style'"? ~ J. Johnson (JJ) (talk) 22:28, 14 August 2015 (UTC)

Requests for comments is -> that way. --Izno (talk) 04:46, 15 August 2015 (UTC)

That way? What is wrong with here? As stated at the top of this very page: "This is the talk page for discussing improvements to the Citation Style 1 page". Not only is it a matter of a particular 'style' that is raised here, but here is the very question I would like answered: How do you suppress errors when titles are missing? Trappist has provided an answer for use with 'cite journal'; my particular question is how to suppress these "errors" for non-journal sources. As Trappist is the WP:WikiKing here, what would be the point of asking for comments from anyone else? ~ J. Johnson (JJ) (talk) 20:35, 16 August 2015 (UTC)

Then what you're looking for is {{RFC}}. Continuing to ask and ask and ask is not going to get you anywhere, so not asking for external comments is not an option. If consensus decides that it's a valuable change, then we'll go find a template editor/coder to make the desired change. If not, then you have an answer that isn't decided by a so-called WikiKing. It's really that simple. --Izno (talk) 21:08, 16 August 2015 (UTC)

Izno, are you even paying attention? You seem to be saying (yes?) that whatever I ask has to go through the hoop of an RfC. Perhaps you would permit me to ask you directly: Where was the Rfc that decided that this "title test" was a valuable change? Or the RfC to add the journal-only "title=none" exception? ~ J. Johnson (JJ) (talk) 23:28, 18 August 2015 (UTC)

Of course I'm paying attention. It seems you aren't, so I'm done replying. --Izno (talk) 03:23, 19 August 2015 (UTC)

Your replies seem to consist solely of enabling for Trappist's intransigence, so that's probably a net positive. —David Eppstein (talk) 03:33, 19 August 2015 (UTC)

Yours seem to be enabling JJ's. Starting an RFC is not hard and gets results. Whining that process wasn't followed does not. Want something to change? Be bold. Can't change it yourself? Ask for help. If help does not want to be given by a certain person, or if it is not obvious what the consensus should be and so it is not obvious that your desired help is that consensus, find that consensus. How do we do that? An RFC. Or if you think the behavioral issues so insurmountable as to prevent you from such, take it to the dramaboard. As I said before, it's simple. Trappist seems unwilling to help you. Guess what that means: an RFC, or ANI. Or identify an expert-editor of templates/Lua, have said person take time to analyze the problem and provide the solution, and then convince Trappist not to edit war. You know which one gets a positive result? I certainly do. Since you decided to snipe at me instead of taking the literal 5 minutes for yourself to start the RFC, I'll take it that you don't. Or you don't care. One of the two. (And yes, I understand the irony of "taking the literal 5 minutes for yourself...". I'm not the one who wants the change.) --Izno (talk) 05:20, 19 August 2015 (UTC)

Izno: I am sorry if you think I am sniping at you. Undoubtedly you understand that I am rather frustrated here; I think you will also understand why I might feel even more frustrated at your suggestion that I should jump through more hoops. But now you have clarified: you are suggesting with how I might deal with the intransigence. Right? In your conception I can seek to build community consensus that a certain state of affairs is desireable (whether it be striking the title-test, adding a non-journal exception, or something else), and request to have it implemented. When the request is refused go back to the community for support - and then what? Sanction Trappist? I think that is where a formal by-the-rules (i.e., "Rfc") approach ends up, and, frankly, I don't like it. (Way too much drama, all around, not because I begrudge 5 minutes, literally or figuratively.) I would prefer to deal with this informally, here. With the understanding that I really don't want to go nuclear, would you have you have any suggestions how else I might proceed? ~ J. Johnson (JJ) (talk) 17:34, 19 August 2015 (UTC)

Quick Re On Sniping: No, I was commenting on David's comment at 3:33. --Izno (talk) 18:22, 19 August 2015 (UTC)

Oh. I was wondering if he was chastising me. ~ J. Johnson (JJ) (talk) 18:32, 19 August 2015 (UTC)

Izno: again, do you have any suggestions how to proceed, without going nuclear? ~ J. Johnson (JJ) (talk) 20:33, 23 August 2015 (UTC)

Returning to the original example, I would have written

*{{cite journal |last1=Pontecorvo |first1=B. |author-link=Bruno Pontecorvo |year=1957 |title=Mesonium and anti-mesonium |journal=[[Soviet Physics JETP]] |volume=6 |pages=429–431 |url=http://www.jetp.ac.ru/files/pontecorvo1957_en.pdf }} English version of {{cite journal |last1=Pontecorvo |first1=B. |author-mask=2 |year=1957 |title=Mezoniy i antimezoniy |journal=[[Zhurnal Éksperimental’noĭ i Teoreticheskoĭ Fiziki]] |volume=33 |pages=549–551 |url=http://www.jetp.ac.ru/files/pontecorvo1957_ru.pdf }} 

which yields

• Pontecorvo, B. (1957). "Mesonium and anti-mesonium" (PDF). Soviet Physics JETP. 6: 429–431. English version of —— (1957). "Mezoniy i antimezoniy" (PDF). Zhurnal Éksperimental’noĭ i Teoreticheskoĭ Fiziki. 33: 549–551.

Kanguole 15:56, 17 August 2015 (UTC)

when both original and archive urls are dead

Latest comment: 8 years ago4 comments4 people in discussion

This conversation at WP:Help desk is perhaps vaguely related to this discussion about suppressing the original url. In that discussion is this cs1 template:

{{cite web| url=http://www.planning.org/thenewplanner/nonmember/default1.htm |title=The New Planner: Drowning Office Park Rescued by Students During High Tide | accessdate=2006-11-01 |archiveurl = http://web.archive.org/web/20060714232619/http://www.planning.org/thenewplanner/nonmember/default1.htm <!-- Bot retrieved archive --> |archivedate = 2006-07-14}}

"The New Planner: Drowning Office Park Rescued by Students During High Tide". Archived from the original on 2006-07-14. Retrieved 2006-11-01.

Neither the original url nor the archive url work. To me this seems a case of 'find-another-source-to-cite'. Until that other source can be located, is there something that cs1|2 can/should do to indicate to readers that both urls are dead? Is this even in the cs1|2 remit?

—Trappist the monk (talk) 20:25, 21 August 2015 (UTC)

To me, archived copies of web sources are similar to, but not the same as, courtesy links to online copies of books. If we assume the underlying source is (or was) reliable when it was consulted, then there is a bit of a presumption that it is still reliable going forward. The archived copy makes otherwise inaccessible sources accessible again, much like a Google Books-hosted copy of a rare book. If that same Google Books link stopped working, it could be removed without changing the fact that the underlying source, the rare book, was used to source the cited information.

In other words, if it were just me, and I discovered that an archived copy no longer worked, I'd remove or comment out |archive-url= and |archive-date= and add a {{dead link}} tag to the citation. This would notify editors that we would want a new archive of the original source, if possible. We'd still be free to locate replacement sources to cite, just as we'd be free to attempt to find other books that are more accessible than rare books housed in only a few select libraries. Because our sources need to be accessible to someone somehow someway, we allow citation of very rare sources, and we'd eventually want a dead online source to be resurrected or replaced. I hope my thought processes make some sense. Imzadi 1979 → 03:15, 22 August 2015 (UTC)

Why is the archive URL not working? Sometimes it's a temporary issue with IA and it works again a few days later. In several cases, inspecting the edit history revealed a rogue edit had added or removed a character from the URL rendering it non-functional. -79.74.108.165 (talk) 23:31, 22 August 2015 (UTC)

IA says "Page cannot be crawled or displayed due to robots.txt." It could be that planning.org added their robots.txt page after the archiveurl was added to the citation. GoingBatty (talk) 18:43, 23 August 2015 (UTC)

url-wikilink conflict error category and error message change

Latest comment: 8 years ago4 comments2 people in discussion

To shorten and make it more consistent with other error categories, in Module:Citation/CS1/Configuration/sandbox I have changed the Category:Pages with citations having wikilinks embedded in URL titles to Category:CS1 errors: URL–wikilink conflict. Because of this change I have also changed the error message to reflect the category name: 'Wikilink embedded in URL title' to 'URL–wikilink conflict'.

—Trappist the monk (talk) 17:10, 22 August 2015 (UTC)

I support the two criteria listed, but I think that both the old and the new names are confusing to readers. I will try to come up with a proposal for one that meets the criteria: short, consistent, clear. I hope we don't have to settle for two out of three. (And a pedantic note: as I read the "In compounds when the connection might..." section of MOS:DASH, that should be an en dash, not a hyphen. Let's not pick that fight with pedants like me.)

If these category name changes stick, we'll need to update the math on the CS1 errors category page and check for links to the old category names. – Jonesey95 (talk) 10:10, 23 August 2015 (UTC)

I concur and have changed the sandbox to use ndashes. {{category redirect}} for hyphenated versions is appropriate.

Internal–external link conflict? Clash? Collision?

—Trappist the monk (talk) 10:37, 23 August 2015 (UTC)

"URL overrides wikilink"? "Duplicate links"? "Redundant links"? "External link and wikilink?" I like the last two better than the first two ("duplicate links" makes it sound like they are identical). – Jonesey95 (talk) 11:04, 23 August 2015 (UTC)

error handling for |trans-title= and |trans-chapter=

Latest comment: 8 years ago1 comment1 person in discussion

In Module:Citation/CS1/Configuration, there are two nearly identical entries in the error_conditions table for |trans-title= and |trans-chapter= missing their original language counterparts. I have tweaked the code in Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to combine these two error handlers. Examples:

• "Chapter". Title.
• [Trans Chapter]. Title. {{cite book}}: |trans-chapter= requires |chapter= or |script-chapter= (help)
• "Chapter". [Trans Title]. {{cite book}}: |trans-title= requires |title= or |script-title= (help)
• [Trans Chapter]. [Trans Title]. {{cite book}}: |trans-chapter= requires |chapter= or |script-chapter= (help); |trans-title= requires |title= or |script-title= (help)
• "Chapter" [Trans Chapter]. Title [Trans Title].

Similarly, in Help:CS1 errors the help text for these two errors is nearly identical. When we make the next update to the live module, the help text for trans-chapter should be merged into the help text for trans-title (trans-title has the common anchor for the error message help link).

The two error messages shared Category:Pages with citations using translated terms without the original. That category name changes to Category:CS1 errors: translated title.

—Trappist the monk (talk) 21:50, 22 August 2015 (UTC)

Suppress original URL

Latest comment: 7 years ago17 comments6 people in discussion

  Moved from Module talk:Citation/CS1/Feature requests § Suppress original URL

Discussion moved here for a somewhat broader audience.

When urls die for whatever reason, normal practice is to keep the url and if possible, add |archive-url= and |archive-date=. Doing so links |title= to the archive copy and links static text provided by the template to the original url.

It has been suggested that we adopt a mechanism to suppress the original url when it is not dead in the sense of 404 or gateway errors and the like, but dead in the sense that the url has been taken over by someone and is now a link farm or advertising or phishing or porn or other generally inappropriate content.

To accomplish this I have suggested modifying the code that handles |dead-url=. This parameter takes a limited set of defined keywords (yes, true, y, no) and adjusts the rendered output accordingly. We could add another keyword that would render the static text in the same way as |dead-url=yes except that this value would not link the static text with the original url.

The question is: What should this defined keyword be? These have been suggested: hide, nolink, origspam, originalspam, spam, advert, phishing, fraud, unfit, usurped.

Is any of these the best keyword? Is there another keyword that would be better?

—Trappist the monk (talk) 15:05, 12 August 2015 (UTC)

Commenters are encouraged to read through the original thread also. --Izno (talk) 15:32, 12 August 2015 (UTC)

I suggest topic-changed. This covers complete takeover by an undesireable publisher, but also covers the case of the original publisher no longer having a page that supports the material in the article. For example, software publisher X had a page about a quirk of version 99 of their software, which Wikipedia described with a citation to the relevant X webpage. Once version 100 of the software is released, X removes the relevant webpage and does not provide information about the quirk anywhere on their site. Jc3s5h (talk) 15:43, 12 August 2015 (UTC)

The purpose of |dead-url= is to indicate for pages which are still live that they can be accessed (when an archive url is also present) (for the case of the original publisher). So from this point of view, adding an archiveurl solves that "broader" issue. Even in the case where an archiveurl cannot be identified and subsequently provided, you can set deadurl to yes and still have that case covered. --Izno (talk) 16:06, 12 August 2015 (UTC)

I don't see any benefit in having citations provide links to dead URLs. However, if other people do, then I suggest simply |dead-url=nolink to describe the function, with an update to the template documentation describing when it is appropriate (or not) to not provide the link to a dead URL. Thanks! GoingBatty (talk) 19:01, 12 August 2015 (UTC)

The benefit I see to providing links to dead URLs (not necessarily clickable) is that the editor who marked the URL as dead might not have the knowledge to find a substitute at a related web page, but a later editor might have that knowledge; the dead URL serves as a clue for finding a substitute. Jc3s5h (talk) 19:18, 12 August 2015 (UTC)

@Jc3s5h: I agree that a later editor may be able to use the dead URL to find a substitute web page, and the archiveurl does not necessarily contain the original URL. I'm all for keeping the dead URL in the citation template for this purpose. However, I suggest that the citation only provide one link for the reader when the original URL is dead. Thanks! GoingBatty (talk) 02:38, 13 August 2015 (UTC)

What about adding a few more keywords, say:

• usurped for domains now operated by a different entity (covers advertising, linkfarm, fraud, spam, phishing, or site/content unrelated to original)
• purged for domains operated by original entity but for which the original website content has been deleted
• abandoned for domains that are no longer registered

The latter may not as desirable as the first two, as domain registrations can fluctuate. Mindmatrix 21:53, 12 August 2015 (UTC)

Multiple keywords are possible. For the purposes of this conversation, I don't think abandoned domains need to be hidden because such domains are the definition of dead. I see no reason to hide links like that.

—Trappist the monk (talk) 10:22, 13 August 2015 (UTC)

Since it has gotten quiet here I have implemented |dead-url=usurped to suppress the link to the original url:

Cite news comparison

Wikitext	{{cite news|accessdate=29 March 2009|archivedate=24 October 2006|archiveurl=https://web.archive.org/web/20061024013933/http://www1.videobusiness.com/article/CA616459.html|date=June 9, 2003|dead-url=usurped|first=Daniel|last=Frankel|publisher=Video Business|title=''Artisan pulls the repackaged Hip Hop Witch''|url=http://www.videobusiness.com/article/CA616459.html}}
Live	Frankel, Daniel (June 9, 2003). . Video Business. Archived from the original on 24 October 2006. Retrieved 29 March 2009. {{cite news}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
Sandbox	Frankel, Daniel (June 9, 2003). . Video Business. Archived from the original on 24 October 2006. Retrieved 29 March 2009. {{cite news}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

And here are tests to show that |dead-url=no and |dead-url=yes still works as they should:

{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=no}}

"Title". Archived from the original on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=yes}}

"Title". Archived from the original on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 16:39, 14 August 2015 (UTC)

The documentation of the parameter value should make the intent of |dead-url=usurped clear (in accordance with the discussion above). Other than that, looks good. --Izno (talk) 16:54, 14 August 2015 (UTC)

Looks good. Mindmatrix 15:09, 16 August 2015 (UTC)

The more I think about the keyword usurped, the less I like it. The term certainly fits for those cases where a domain name has been usurped but does it fit for all other cases where it is prudent to suppress the original url? I'm not sure, so rather than use a keyword that may have limited specificity, I think we should switch to a more general keyword, perhaps unfit, which would covers a broader variety of reasons for suppression of the original url.

—Trappist the monk (talk) 19:26, 17 August 2015 (UTC)

At the risk of boring all of you, I will re-express my view that the parameter value should express the function, not the reason (as I said in the previous discussion linked above, and as GoingBatty said above. I like "hide" or "nolink".

TL:DR; version: The value of |display-editors=, for example, is either a number (to show a given number of editors) or "etal" (to show "et al." without listing all of the editors in the citation template. We don't dictate why an editor should use a specific value, we just show how to get the display you want, assuming that editors will make a good choice (a bad assumption, I know, but you have to start by treating people like competent adults). There are many reasons why someone might want to suppress a link to the original URL: it is a porn site, the site has been sold, the page has been moved or archived, the editor wants a consistent citation style, or other reasons I can't think of. We can list some of them in the documentation, but assuming only one reason for hiding the URL paints us into a corner. – Jonesey95 (talk) 19:42, 17 August 2015 (UTC)

I was hoping you wouldn't re-iterate your opinion so I wouldn't have to reiterate mine. To wit: The problem I have with function over purpose is that function enables behavior that may not be desirable. For example, I can't think of any reason other than a link being a "bad" link to be correct to hide. And my feeling is that the suitable keyword should reflect the reason. This allows us to trivially say "yes, you have used this as intended". I want in fact to preempt other reasons for usage without associated keywords, because I do not want "oh, the site is dead" simply to cause the link to be suppressed (as I am sure there is at least one person who would be wont to do so). See above illustrative discussion on that point. --Izno (talk) 21:59, 17 August 2015 (UTC)

In the cases of |dead-url=hide or |dead-url=nolink or similar, we create a mechanism that doesn't explain to editors of a later age why the action was taken. With |display-editors=etal, |mode=cs2 it's pretty easy to determine why the parameter was set the way it was set and that it is, or is not, set properly. Setting |dead-url=usurped or |dead-url=unfit gives follow-on editors some indication why the original url is suppressed. Like Editor Izno, I can think of no real reason why an original url should be suppressed unless it leads to inappropriate content. As I indicated before, we can have a variety of keywords to use as reasons should experience dictate a need.

—Trappist the monk (talk) 13:08, 18 August 2015 (UTC)

Supported keywords are now unfit and usurped (also shows that auto |format=PDF works correctly when original url is suppressed):

{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=unfit}}

"Title" (PDF). Archived from the original (PDF) on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=usurped}}

"Title" (PDF). Archived from the original (PDF) on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 16:45, 24 August 2015 (UTC)

Yet another example of two levels of title within a journal publication

Latest comment: 7 years ago5 comments3 people in discussion

The following reference is a paper, part of a conference proceedings that was published as an issue of a journal (whose name indicates that it regularly publishes proceedings in this way, but with a combined volume and issue numbering system that looks much more like a journal than like a book series). The following formatting produces a citation that looks correct but with what I believe to be incorrect metadata. Is there a way to get the metadata right, too, or is this the best I can do?

{{cite journal | last = Charatonik | first = Janusz J. | title = Selected problems in continuum theory | url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf | issue = 1 | journal = Topology Proceedings | mr = 2048922 | pages = 51–78 | department = Proceedings of the Spring Topology and Dynamical Systems Conference | volume = 27 | year = 2003}}

produces

Charatonik, Janusz J. (2003). "Selected problems in continuum theory" (PDF). Proceedings of the Spring Topology and Dynamical Systems Conference. Topology Proceedings. 27 (1): 51–78. MR 2048922.

—David Eppstein (talk) 01:41, 25 August 2015 (UTC)

Because there is no COinS record assigned to |department=, 'Proceedings of the Spring Topology and Dynamical Systems Conference' is not included in the metadata. Rewriting this cite to use {{cite conference}} isn't much better:

{{cite conference | last = Charatonik | first = Janusz J. | title = Selected problems in continuum theory | url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf | issue = 1 | journal = Topology Proceedings | mr = 2048922 | pages = 51–78 | booktitle= Proceedings of the Spring Topology and Dynamical Systems Conference | volume = 27 | year = 2003}}

In this case, 'Topology Proceedings' is left out which isn't any better and is probably worse, because the journal title is common to the two volumes published each year.

—Trappist the monk (talk) 10:38, 25 August 2015 (UTC)

Use of |contribution/chapter= seems more suitable, but – oops! – red messages:

• Charatonik, Janusz J. (2003). "Proceedings of the Spring Topology and Dynamical Systems Conference" (PDF). Topology Proceedings. 27 (1): 51–78. MR 2048922. {{cite journal}}: |chapter= ignored (help)

~ J. Johnson (JJ) (talk) 20:55, 26 August 2015 (UTC)

Yes, that would be my preference, if it worked. But it doesn't, {{cite journal}}/|department= does, and it appears from Trappist's message above that it doesn't even produce bogus metadata. So that's what I'll be using for now. —David Eppstein (talk) 20:11, 29 August 2015 (UTC)

On one hand, I would be happy for any reasonable work around. On the other hand, COinS is not the only kind of metadata here. The names of parameters also carry information regarding the nature of the data encoded. E.g., |journal= implies the source is journal (specfically, an academic journal), which is different from a newspaper or a book. Likewise, |department= is defined at Cite journal#Periodical as "Title of a regular department, column, or section within the periodical or journal", and has specific effects on the resulting formatting. To use these parameters for other purposes is a form of metadata corruption. And (as has been previously commented) eventually leads to some unsuspecting editor attempting to "correct" what looks like an error. ~ J. Johnson (JJ) (talk) 22:18, 30 August 2015 (UTC)

vancouver error tweak

Latest comment: 7 years ago1 comment1 person in discussion

I have noticed that a space between the two initials of a name in |vauthors= is not detected as an error. I think that I have fixed that:

Cite book comparison

Wikitext	{{cite book|title=Title|vauthors=Last AA, Last B B}}
Live	Last AA, Last B B. Title. {{cite book}}: Vancouver style error: initials in name 2 (help)
Sandbox	Last AA, Last B B. Title. {{cite book}}: Vancouver style error: initials in name 2 (help)

—Trappist the monk (talk) 21:55, 31 August 2015 (UTC)

Time of day field

Latest comment: 7 years ago4 comments3 people in discussion

I would like to propose that we add an optional field to Template:Cite web (and by extension also to Template:Cite tweet) for the hours and minutes of the day, perhaps also time zone.

This data is sometimes available in things, and where it is, I think it would be a good thing to add it.

This helps in cases where there is a dispute on how to organize things, who said what first, etc.

Sometimes you might want to cite 2 news articles about something made in the same day (or 2 tweets) and knowing that information could be useful for putting them into the correct order without requiring people to constantly go and check what the tweet said. This is also particularly useful if the tweet is taken down and wasn't archived. Ranze (talk) 22:02, 28 August 2015 (UTC)

If a tweet is taken down, and has not been archived anywhere, then it is not verifiable, and I would question its suitability as a source. If you feel it is useful to document the exact time some tweet or other information is posted/published, you can always add that following the template. I am not aware that a "time" field is necessary. ~ J. Johnson (JJ) (talk) 22:47, 28 August 2015 (UTC)

I would think that in the rare instance where it was necessary to discuss the time various sources were published, it would be necessary to describe the times in the body of the article rather than leaving it to the footnotes. Jc3s5h (talk) 00:09, 29 August 2015 (UTC)

"Footnotes" is a bit ambiguous. More particularly, if short cites are used then the time could be used in the same manner as a page number, perhaps using |loc=. But however this might be done, the bottom line here is that (lacking any specific demonstrated need) we seem to have adequate means for adding timestamps, and the proposed field is not needed. ~ J. Johnson (JJ) (talk) 19:26, 2 September 2015 (UTC)

page protection applied to the suggestions list

Latest comment: 7 years ago4 comments3 people in discussion

Module:Citation/CS1/Suggestions has been, since it creation, unprotected. At the time, I wondered if that page should be protected, but I didn't pursue it and have come to believe that protection of that page is not necessary.

The page was set to template editor level protection by Editor Courcelles at the request of Editor CFCF. That discussion, since archived, is here. Because it has been archived, I have raised the issue here.

Is the current (template editor) protection appropriate?

Should we keep or revert?

—Trappist the monk (talk) 10:50, 4 September 2015 (UTC)

As an editor with template editor rights, I don't mind, but I think it's odd that a page that has never been vandalized or even edited incorrectly, as far as I can tell, would be protected. The page has 42 edits total, by my count.

Since you bring it up, is it somehow possible to use regular expressions on that page? I may have asked this before. There are a lot of creative spellings of |access-date=, for example, that could be caught with a few regular expressions. – Jonesey95 (talk) 14:01, 4 September 2015 (UTC)

Perhaps improperly edited once (you reverted).

Feature requests has your regex suggestion.

—Trappist the monk (talk) 15:32, 4 September 2015 (UTC)

Oops. I think my brain thought to set it to semi, and my fingers to template. Courcelles (talk) 17:32, 4 September 2015 (UTC)

pattern matching for suggestion list

Latest comment: 7 years ago5 comments2 people in discussion

Perhaps there is reason to be somewhat optimistic. I think that all of these are caught by this pattern: ['ac+es+ ?d?a?t?e?'] = 'accessdate'

• "Title". {{cite web}}: Unknown parameter |acccessdate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accesdate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |access date= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accessate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accessdare= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessdatte= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessddate= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessdte= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accessed= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessedate= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accesssdate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accssdate= ignored (help) – |accssdate= missing first 'e' so not a pattern match
• "Title". {{cite web}}: Unknown parameter |acessdate= ignored (|access-date= suggested) (help)

As the pattern is written, |accessdare= returns a partial match 'accessda'. I guess that could be a good or bad; too tight and we might as well just use the exact-match-method we use now or too loose and we get a lot of false positives.

At the moment, Module:Citation/CS1/sandbox only catches |access-date= errors – I did that so that I could be sure that the errors weren't being caught by the existing code. Now I have to figure out how to integrate this with the existing test. And of course, I need to ask, do we really need this?

—Trappist the monk (talk) 18:45, 4 September 2015 (UTC)

Regular exact-match-method restored. I've added a second pattern for variations on a theme of publisher using this pattern: ['pu[blish]+ers?$'] = 'publisher'

• Title. {{cite book}}: Unknown parameter |pubisher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publiser= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publishers= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publsher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publsiher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |pulbisher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |pulisher= ignored (|publisher= suggested) (help)

—Trappist the monk (talk) 22:21, 4 September 2015 (UTC)

At the end of this discussion, I noted that the suggestion mechanism doesn't allow suggestions for enumerated parameters. This is true except for the specific case of |autor2= which has an exact-match rule ['autor2'] = 'author2'. Using patterns may be a way to solve this weakness. Using this pattern: ['a[utho]+r%d+'] = 'author#':

• Title. {{cite book}}: Unknown parameter |autor1= ignored (|author1= suggested) (help); Unknown parameter |autor1= ignored (|author1= suggested) (help)

—Trappist the monk (talk) 11:51, 5 September 2015 (UTC)

These new suggestions look helpful. Can we use something like '$1' in the suggestion to repeat the number that was detected by the pattern? – Jonesey95 (talk) 21:32, 5 September 2015 (UTC)

Without getting too complicated we can do one capture:

['a[utho]+r(%d+)'] = 'author$1' (see my previous example to see that it works)

More than that and some more involved code will be required.

—Trappist the monk (talk) 22:58, 5 September 2015 (UTC)

Double period bug (again)

Latest comment: 7 years ago2 comments2 people in discussion

I know this was reported before, but this bug is still alive and annoying.

Steps to replicate: give the publisher parameter a value that ends with a period.

Result: Two periods after the publisher. Which is wrong. Mature software such as BibTeX and Citation Style Language can deal with this.

Real-life example: Look for “Digitalcourage e.V.” on de:Digitale_Gesellschaft_(Schweiz). --Thüringer ☼ (talk) 08:08, 7 September 2015 (UTC)

Here is the citation from de:Digitale_Gesellschaft_(Schweiz):

{{Cite web |title=Überwachung in und aus der Schweiz: Das volle Programm |url=https://digitalcourage.de/blog/2015/ueberwachung-in-und-aus-der-schweiz-das-volle-programm |author=Digitale Gesellschaft Schweiz |publisher=Digitalcourage e.V. |date=2015-08-18 |accessdate=2015-09-07 }}

Digitale Gesellschaft Schweiz (2015-08-18). "Überwachung in und aus der Schweiz: Das volle Programm". Digitalcourage e.V. Retrieved 2015-09-07.

De:wp does not use the en:wp Module:Citation/CS1 to render citation templates. The de:wp, {{cite web}} is a template that is written using wiki markup.

Probably best to raise the issue at de:Vorlage Diskussion:Cite web.

—Trappist the monk (talk) 11:09, 7 September 2015 (UTC)

RfC closure challenge: Template talk:Cite doi#RfC: Should Template:cite doi cease creating a separate subpage for each DOI?

Latest comment: 7 years ago1 comment1 person in discussion

Please take part in the discussion at Wikipedia:Administrators' noticeboard#RfC closure challenge: Template talk:Cite doi#RfC: Should Template:cite doi cease creating a separate subpage for each DOI? Curly Turkey 🍁 ¡gobble! 05:12, 8 September 2015 (UTC)

RFCs on citation templates

Latest comment: 7 years ago1 comment1 person in discussion

There are ongoing discussions (mostly parallel but since each one is argued as separate consensus, separate) regarding the use of (A) Template:Cite wdl (which creates subpages for a wrapper of cite web) here; (B) Template:Cite pmid (which is a wrapper for cite journal either in-article or via pages at Category:Cite pmid templates) here; and (C) another RFC at Template:Cite doi (a cite journal wrapper with almost 60k pages at Category:Cite doi templates) here. There are unique wrinkles to each one but basically all three discussions concern whether to deprecate these templates or not. Please comment there if everyone could. -- Ricky81682 (talk) 06:22, 8 September 2015 (UTC)

Italicization of websites in citations

Latest comment: 7 years ago40 comments11 people in discussion

  Stale

 – Discussion has moved on, to #Request for Comments: Italics or Non-Italics in "website" field.

If I may revive an old discussion (pardon me if there are other threads), I don't understand why we are italicizing websites (thru the |website= parameter) in citation templates. The argument seems to be that the alias of |website= is |work= (meaning you can use one or the other but not both) and obviously |work=, |journal=, etc. should be italicized. But the plain fact is that, per the MOS, while we italicize the names of publications, we (generally) do not do so for websites. So these parameters should not be interchangeable. For example: TMZ, Gawker, BroadwayWorld.com and other sites and urls should not be italicized. And while for content found in both a print publication and on its website I may cite The Advocate or Entertainment Weekly, if the actual url is being cited (Advocate.com or EW.com) it should not be italicized. This seems like a no-brainer.— TAnthony^Talk 21:16, 31 July 2015 (UTC)

"Generally" is the key word here, though. The vast majority of the time when a WP article is referring to a website, it's referring to it a business entity (or other kind of entity, e.g. a nonprofit, a free software coding group, a government project, whatever), or in a functional way, e.g. as a service or product. But when we cite it as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:53, 1 August 2015 (UTC)

As a journalist and editor, I need to disagree with the premise that when we cite Amazon.com, or the British Board of Film Classification or Marvel.com that these entities transmogrify into "a major published work, like a book, journal, magazine, film, etc."

No mainstream source italicizes Amazon.com, British Board of Film Classification, Marvel.com, or, for that matter, Rotten Tomatoes or Box Office Mojo, and none of these entities themselves italicize their names.

Italicizing dotcom names is not done anywhere else, and I'm afraid I can't find a valid reason that Wikipedia should create a non-traditional form of punctuation. Indeed, not even Wikipedia italicizes these entities in their respective articles. So I'd like to ask for what compelling reason we do so here. --Tenebrae (talk) 19:43, 29 August 2015 (UTC)

I agree. Entirely. ~ J. Johnson (JJ) (talk) 22:25, 30 August 2015 (UTC)

With what, though? Half of that wasn't cogent. British Board of Film Classification is a publisher, not a work of any kind, and what source italicizes itself (except as an incidental stylistic matter)? Looking at an entire bookshelf, only a tiny handful of covers have italic titles, and if you look at the actual title on the frontispiece, and at the top or bottom of each (or every other) page in the book, it is not italicized. This tells us nothing at all about whether WP would italicize the book title in a citation to it. No one made any such argument of "transmogrification". What I actually said was 'when we cite [a website] as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.' This argument has not actually been responded to at all. Instead, Tenebrae told us what some other publishers are doing, and made some unrelated observations. But WP's citation system is not that of any other site or publication, and no case has been made for why WP should treat the titles of all major works consistently (italicizing them by template) except when they're online publications.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:21, 30 August 2015 (UTC)

The problem is with how the website parameter is used. Since it's a synonym for work, it should only be used when a work is given as the value. "Amazon.com" is not a work. Peter coxhead (talk) 00:59, 31 August 2015 (UTC)

Exactly. Titles can be italicized, so we could have Amazon.com, but only because it is a title, not because it refers to a url. As to usage outside of WP: while some aspects of other styles are questionable, and often contradictory, it is still a good idea to consider them: 1) They often reflect a lot of hard-earned experience, and it would be shameful waste to insist on having to re-experience more than is useful. 2) Making WP more different than standard uses makes it harder to edit, and can even lead to subtle problems of reading. ~ J. Johnson (JJ) (talk) 18:06, 2 September 2015 (UTC)

As Peter coxhead rightly notes, "Amazon.com" is not a work or a title. "Rotten Tomatoes" or "Rotten Tomaotes.com" are not titles. "Sears.com" is not a title. Though I certainly agree with J. Johnson (JJ) that no other reference source, nor newspapers or magazines, italicize dotcom names. There is no reason for Wikipedia to have a nonsensical deviation from every grammatical standard in this regard. --Tenebrae (talk) 21:40, 2 September 2015 (UTC)

I think you all are missing a couple key things here:

1. the name of the website very rarely includes the domain space (.com, .org, etc)...eg. it's "Wikipedia" not "Wikipedia.org"
2. citation styles are, generally, an exception to the MoS...the citation styles are intended to reflect common citation styles. Of the common citation styles, condsider how the following handle the names of websites:

1. MLA uses italics (scroll down to the section "A page on a website")
2. Chicago uses italics
3. APA generally doesn't include the name of a website that's not scholarly website (eg. an online journal), but instead uses "Retrieved from [url]".
4. ASA and Oxford style also does not include the name of the website, but rather the url
5. Vancouver style (see page 5) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Wikipedia [internet].

While there are many exceptions, websites are generally a work/publication. Of the citation styles that include the name of the website, the two general style guides (MLA and Chicago) both italicize the name of the website, while the Vancouver style guide is generally reserved for the physical sciences. AHeneen (talk) 01:58, 3 September 2015 (UTC)

I don't think we need to research varied style guidelines. It's already established that websites/urls are generally not italicized at Wikipedia, and I'm not aware that we have separate formatting conventions for citations in this regard. The fact that cite templates equate "website" with "work" is the problem, because while one or the other should be required, they do not have the same established formatting style. Period. If I'm citing EW.com, I actually cite |work=Entertainment Weekly because the website is an obvious platform of that publication. But when you cite a website not affiliated with a conventional publication, yes it may be considered a "major published work" in the sense that it is a reliable source, but I don't see why it should be italicized when it does not meet the criteria for that formatting, and would not be italicized in other contexts at WP. I get SMcCandlish's basic argument, but it is not as if there a requirement somewhere that something has to be italicized in each citation, or that the source has to be italicized no matter what it is.— TAnthony^Talk 19:24, 3 September 2015 (UTC)

Okay, we need some clarification here, as it seems that "website" is being used in several different ways. Note that websites usually have a proper name, such as "Google", "The New York Times", "Entertainment Weekly", and "Rotten Tomatoes". Websites also have hostnames, such as (resp.) "www.google.com", "www.nytimes.com", "ew.com", and "wwww.rottentomatoes.com", which often (but not always) incorporate some form of the website's (or parent entity's) name. Hostnames are usually part of URLs (but see below), and as such have specific form and usage in the context of the Internet. As hostnames (URLs) they are not italicised, nor capitalized. What are italicized are titles, such as the names of books, periodicals, and (generally) works. A book title in the form of a hostname, such as Amazon.com, would be italicized, but only because it is a title.

It seems to me the real issue here is what constitutes a title; particularly, the name of a source. "The New York Times" and "Entertainment Week" are the names of both publications and their associated websites; "nytimes.com" and "ew.com" are not. (Entertainment Weekly could have named their website "EW.com", in which case it could be a title, but they did not.) Note that a further distinction can be made between a publisher and a publication (or work). E.g., "Amazon" (the website) might be the publisher of a reveiw found there, but is it a publication? ~ J. Johnson (JJ) (talk) 21:34, 3 September 2015 (UTC)

Amazon, or Amazon.com, indeed is not a publication. Neither is the publisher Simon & Schuster or simonandschuster.com. Likewise, Sears.com is not a publication, and citing, just for example, the number of stores that Sears owns would be to the website Sears.com, and not Sears.com.

TAnthony is correct that if we're citing something created by the editorial department of Entertainment Weekly or The New York Times, we credit the publication rather than ew.com or nytimes.com, and these publications of course are italicized. In such cases, we use "work=" or "newspaper=" or "journal=". But neither Black & Decker nor blackanddecker.com is italicized. Same with The Home Depot or homedepot.com.

The sensible solution, I believe, is to have the "website" field not italicize its contents. That way we're not putting in " Amazon.com " or " Sears.com ". If we're citing an actual publication, we have three different fields we can use. --Tenebrae (talk) 22:48, 3 September 2015 (UTC)

Careful! You seem to be sliding back to confusing the name (as in a proper name) of a website with its hostname. E.g., "Sears.com" is not the name of a website, so should not be put in anywhere. If you want to cite something from the Sears website (located at "www.sears.com"), then you cite that, not its hostname. If a website is a publication (e.g., "Rotten Tomatoes") then its name is properly italicized. ~ J. Johnson (JJ) (talk) 23:27, 3 September 2015 (UTC)

I don't think I am. And I think you are the only person on this thread making the argument that Amazon.com should be italicized. And, certainly, no one italicizes Rotten Tomatoes, not even Rotten Tomatoes, as it is not, by any definition, a publication.

What do the other editors think? Aside from one holdout, the consensus seems to be to have the "website" field be non-ital. Do we need to create a formal RfC, or have we reached consensus? --Tenebrae (talk)

If all sources are italicized, including sources that contain the cited work, then websites should be italicized for both stylistic consistency and semantic reasons (e.g. to distinguish a webpage or section from the hosting website). — Preceding unsigned comment added by 64.134.64.231 (talk) 21:43, 5 September 2015 (UTC)

T: You don't seem to understand the distinction I am making, and have thereby misstated my view. Note: I believe we have no disagreement that (e.g.) titles can be (even should be) italicized. Also, that hostnames - such as found in URLs, and when used as hostnames - are NOT italicised. What you don't seem to understand is the use of a hostname in other contexts, such as in a title, or as the proper name of a website. Where I say that "Amazon.com" - note the capitalization, which is generally not done in urls - could be italicized it is very much dependent on it being used in the context of a title (like of a book) or proper name. That you think there is consensus to not italicize "website" is only because you have conflated "website" with "hostname". This is indicated by your earlier reference to "dotcom names". Strictly speaking, there no such things, except in the casual use of "XXXX.com" to refer to the website of some company XXXX. While such uses are in the fashion of a hostname, simply adding ".com" to some name does not make it a hostname, and does not exclude it from italicization. ~ J. Johnson (JJ) (talk) 22:05, 5 September 2015 (UTC)

I believe this is a valid point. The print product Grapes of Wrath, delivered by a printer, is not the book Grapes of Wrath delivered by a publisher. The digital product Amazon.com, delivered by a software developer, is different from the website www.amazon.com delivered by an online publisher. In most cases what is cited as the source is the content, not the "delivery method/packaging", as it were.208.87.234.201 (talk) 14:43, 6 September 2015 (UTC)

I can only repeat my previous point. At present, |website= is simply a synonym of |work=, and so its value should be italicized, in line with the usual style for a work. It would be possible to give the two parameters a different meaning, but this would require a huge number of existing uses to be checked. Since "website" seems to be widely misunderstood, perhaps its use should be deprecated? Peter coxhead (talk) 19:28, 6 September 2015 (UTC)

I agree that "website" (as in "work") can be italicized; the problem seems to be where people mistakenly equate it with the url/hostname. Perhaps the documentation should be clearer about this. And perhaps a bot could flag all the instances where the value of |website= is a valid hostname. I am reluctant to deprecate |website= as I think it has a good use, but if the problem is too great then that is something to consider. ~ J. Johnson (JJ) (talk) 21:34, 6 September 2015 (UTC)

Editors were perplexed or confused with the term 'work'. In response to this feature request, |website= became an alias of |work=.

—Trappist the monk (talk) 22:12, 6 September 2015 (UTC)

Suggesting that it is the concept of "website" as a "work" that is confusing. ~ J. Johnson (JJ) (talk) 22:36, 6 September 2015 (UTC)

So Amazon.com should not be italicized by www.amazon.com should, is what you're saying? First, I'm not sure how often we would be citing a raw URL. Second, I don't see URLs italicized in any mainstream source. I'm not sure it's a positive thing for WIkipedia credibility to be adopting highly non-standard forms of citation. I'm not sure this is any different from citing authors by first name rather than last. That would be a highly non-standard way of citing, and would only make Wikipedia look eccentric. I'm thinking that italicizing URLs where virtually no one else does might do the same. --Tenebrae (talk) 17:03, 7 September 2015 (UTC)

No, I believe he's saying the reverse. Amazon.com is the name of a website, and as a major published work, it would be itaicized if included in a citation. On the oter hand, www.amazon.com is the hostname and wouldn't be itaicized nor would we need to cite it. Imzadi 1979 → 17:59, 7 September 2015 (UTC)

Again, no one italicizes Amazon.com or Sears.com, RottenTomatoes.com, etc., including those companies themselves. A URL / hostname / website does not suddenly change and become a book, magazine, newspaper or other "major published work." There's a reason we say things are "posted to the Web" and not "published to the Web". I think the fact no one in the mainstream italicizes these things should be a significant factor in this discussion. --Tenebrae (talk) 18:24, 8 September 2015 (UTC)

Exactly. Tenebrae, you started off with an incorrect understanding, so everything else that follows is invalid. If you start off the right way (and if you understand/accept that "website" ≠ hostname) I think you will find that we are largely in agreement. ~ J. Johnson (JJ) (talk) 20:40, 7 September 2015 (UTC)

I would like to think so, but a fundamental issue is that I believe the "website" parameter should not be italicized. Virtually no mainstream source italicizes either website names or URLs, which I take it is what you mean by "hostname". Italicizing websites/URLs is non-standard and does Wikipedia no good. --Tenebrae (talk) 21:52, 7 September 2015 (UTC)

You need to loosen your death-grasp on 'the "website" parameter should not be italicized'. Your implicit argument is that URLs (which includes hostnames) are not italicized. Look, we all get that part - everyone agrees that URLs should not be italicized. And that includes parts of a URL, such as hostnames. So it is a bit annoying that you keep asserting that. What you don't get is that this is irrelevant, because "website" does not equal URL/hostname. In particular, what you don't get is that a website - that is, a site on the World Wide Web with "web page" (HTML) content - can have a proper name. E.g.: the name of the website located at the WWW address "www.nytimes.com" is The New York Times - which is properly italicized. I repeat: "website" ≠ hostname. ~ J. Johnson (JJ) (talk) 21:58, 8 September 2015 (UTC)

With all respect, we're talking specifically about a field in "cite web" called "website". If we're citing The New York Times, we use "cite news or "cite newspaper" and enter the name of the paper in the field "work".

But I am confused, because it does sound as if we both agree that the name of a website is not italicized unless it's a newspaper, magazine, etc. ... in which case we wouldn't use "cite web." So ... am I wrong or do we agree that if we use "cite web" that the field "website" should not be italicized?--Tenebrae (talk) 22:29, 8 September 2015 (UTC)

Suppose one wanted to cite this web page. Becuase it isn't a newspaper, it isn't a journal, nor a book, nor anything but a web page, then I would cite it with {{cite web}} like this:

{{cite web |url=http://www.cdc.gov/ncbddd/autism/data.html |title=Autism Spectrum Disorder (ASD) |website=[[Centers for Disease Control and Prevention]] |date=12 August 2015}}

"Autism Spectrum Disorder (ASD)". Centers for Disease Control and Prevention. 12 August 2015.

—Trappist the monk (talk) 23:04, 8 September 2015 (UTC)

Yet nowhere else is the Centers for Disease Control and Prevention italicized. Same with CNN or CBS News. They are not publications, and I'm not sure it makes sense for Wikipedia to transmogrify them and pretend that they are publications. CBS News is never italicized. CNN, Sears, BBC, Rotten Tomatoes — none of these are italicized. If virtually no one else in the mainstream is italicizing these entities, I'm not sure why Wikipedia would. It makes us look eccentric. Do you see my reasoning?--Tenebrae (talk) 23:54, 8 September 2015 (UTC)

Agreed, yet the name of the website at http://www.michiganhighways.org , if it were being cited, is "Michigan Highways" per the site's mastheads. If it were being cited, it should appear in italics as the name of a major work (as opposed to individual webpages within the site which would be minor works in quotation marks). There is no entity named "Michigan Highways" to be called a publisher. In some of those cases being mentioned above, what is being claimed as the name of a website is the publisher. Not all websites have names, but when they do, they should be in italics. If a website lacks a separate name, without resorting to creating "Official website of X", then |website= should be left blank. It's the same in comparing the news sites of WLUC-TV (Upper Michigan's Source) with that of WBUP-TV (no name). Imzadi 1979 → 00:48, 9 September 2015 (UTC)

cs1|2 take their styling cues from MLA, APA, CMOS, and, no doubt, stuff we've made up ourselves. There is this, which on pages 4 and 5, compares three style guides for citing online material:

"The Purdue OWL: Citation Chart" (PDF). Online Writing Lab. Purdue University. pp. 4–5.

If one is to believe that, website names are rendered in italics in citations so my CDC citation above is correctly rendered.

—Trappist the monk (talk) 00:51, 9 September 2015 (UTC)

Wikipedia is highly non-standard. Contributors are not vetted. Sources are not systematically checked. Citation styles are not enforced. Editors have widely varying expertise. Consumers cannot be assumed to be experts. The present problem should I think take this non-standard approach into account. If the source is a website (a collection of pages connected by hyperTEXT links and employing the digital equivalent of a markup language) then should be treated the same way CS1 treats other similar collections in other media. --— Preceding unsigned comment added by 64.134.64.231 (talk • contribs) 19:43, 7 September 2015

Tenebrae, lets say I want to something from the New York State Department of Motor Vehicles website, something that only appears on the website, and is not in any book, pamphlet, etc. So I use cite web. And I use |website= = New York State DMV because that is the title of the web site. I know it is the title of the website because when I examine the html source for the home page of the web site I find <title>New York State DMV</title>. It should be italicised because that is the title of the work. Jc3s5h (talk) 23:06, 8 September 2015 (UTC)

Except no one other than we italicize it. New York State DMV is a proper-noun entity, but to suggest that all proper-noun entities be italicized — I dunno. I mean, what's the advantage of italicizing CBS News, Sears, New York State DMV, Yellowstone Park or United Airlines? Would readers not understand that " 'Traffic Laws in 2015'. New York State DMV." comes from the New York State DMV? I'm not sure what the advantage is of going with a deliberately eccentric format.--Tenebrae (talk) 23:58, 8 September 2015 (UTC)

At the NYS DMV website, the <title>New York State DMV</title> html officially declares to the world "the title of our website is New York State DMV. My Firefox browser responds to that declaration by putting that title in the tab associated with the web page. Style guides outside Wikipedia, mentioned in this discussion, explain that when a website has a title, that title is italicised, and we have decided to follow that guidance. It has nothing to do with whether "New York State DMV" is a proper noun phrase or not. Jc3s5h (talk) 14:15, 9 September 2015 (UTC)

And my Google Chrome does not italicize anything at http://dmv.ny.gov/. Nor does the title of the page itself, in big blue letters. As for "we have decided," that's what this discussion is for, to discuss a change. Because having a style that virtually no one else uses just seems remarkably eccentric for no purpose. I don't believe any of us has ever seen, anywhere, "Author's Page". Simon & Schuster. No one would ever italicize the publisher Simon & Schuster. And to suggest that Rotten Tomatoes, which is not italicized in article text, be italicized in the footnote seems determinedly inconsistent. I think we're going to need wider input from all of Wikipedia.--Tenebrae (talk) 16:35, 9 September 2015 (UTC)

T: We are not saying that "that all proper-noun entities be italicized". In the context of citation publications ("works") are italicized, publishers are not. This is not "eccentric", this is a standard convention. So we italicize the titles of webpages (as Jc3s5h just explained), such as Sears or New York State DMV. We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. What kind of font is used on the website has nothing to do with it. (E.g., that the New York Times uses a serif title font has absolutely no bearing whatsoever on how a citation is formatted.)

Your persistent failure to understand this is starting to sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 01:13, 10 September 2015 (UTC)

No, it is the other way around, and I'll thank you stop casting aspersions. Pick up some books with footnotes and see whether web pages are italicized. See what AP Stylebook, the largest style guide in the English-speaking world, has to say. Nobody properly writes Rotten Tomatoes in regular font in article prose and then, inconsistently, puts it in italics in footnotes. Virtually no one in the world would italicize an organization like CBS News when citing something from the CBS News website. Organizations and institutions don't suddenly become titles because they have a web page.

Try and WP:HEAR this: The information we get from the New York State Department of Motor Vehicles comes, ultimately, under the auspices of the New York State Department of Motor Vehicles and not from the Web editor who inserted the information onto the web. Just as we cite The New York Times and Entertainment Weekly and not NYTimes.com or EW.com, the information from those websites ultimately comes under the auspices of those organizations. And in the case of non-publications, those organizations' names are not italicized. Now stop making false accusations — I understand perfectly, as I've said. It's you who seem to have trouble grasping the concept. --Tenebrae (talk) 20:26, 10 September 2015 (UTC)

False accustations? Aspersions? Perhaps you should review the bit at WP:NPA that accusing someone of a personal attack can also be considered a personal attack.

My "accusation" is that you have repeatedly failed to understand what is being said here. E.g., you have just insisted that "no one in the world would italicize an organization like CBS News", and "those organizations' names are not italicized." But who has said we should? You have implied that I did (and again at the RfC (below). But that is false. I have no where said that names of organizations should be italicized. And you seem to have totally missed what I said in my last comment regarding organizations: We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. (Emphasis added for the hard of hearing.) You have mis-taken my position, and are arguing against something (italicization of organizational names) that nobody is arguing for. If you in fact do "understand perfectly" then why are you arguing a non-issue? I surmise that you have confused "website" with "publisher", just as you earlier confused it with "hostname". I submit that not understanding this despite repeated explanations does sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 22:38, 10 September 2015 (UTC)

Don't you dare accuse me of uncivil behavior, when you were the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning. And you compound your incivility by falsely claiming I was deliberately misunderstanding in order to obfuscate. How dare you. Look around this RfC — other people have no problem whatsoever understanding my point, so the fact that only you seem to have a problem understanding seems ironic, given your accusations. You say organizations should not be italicized, but you support leaving the "website" field italicized (01:19, 10 September 2015) because the very same words are not, in your view, that of organization anymore but of a page title. That seem contradictory. I've already explained that when we're using publications, we wouldn't be using "cite web" field but "cite news" etc., so why you keep bringing up publications is beyond me. --Tenebrae (talk) 23:23, 10 September 2015 (UTC)

Yes, I think I will dare to accuse you of uncivil behavior: of grotesquely misrepresenting my views, of attributing to me things I have clearly not said. Let's start with your statement that I was "the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning." Where? Give us a diff. That view is entirely your interpretation. As I said at the RfC, you it have backwards: I disagree with your position because your reasoning is faulty, not the other way around. As to your "deliberately misunderstanding in order to obfuscate: I asked why (if, as you stated, you "understand perfectly") you are arguing a non-issue. Again, the suggestion "in order to obfuscate" is entirely yours, not mine. But now that you have raised it, is that your answer to my question?

I think it is quite evident that your understanding of matters here (and reasoning) is faulty, but as all efforts (of others as well as mine) to explain this to you are unavailing it seems pointless to continue. If you can provide that diff, fine, but otherwise you should cease your flailing about. If anyone else thinks that I have misunderstood something, please bring it to my attention. ~ J. Johnson (JJ) (talk) 23:48, 11 September 2015 (UTC)

deprecate enumerator-in-the-middle parameters

Latest comment: 7 years ago20 comments7 people in discussion

See this archived discussion.

I propose to deprecate these parameters and standardize on the enumerator-at-the-end form. The numbers in the preference ratio column are caclulated from the values in the tables in the archived discussion: (terminal enumerator ÷ medial enumerator). Where the cells are blank the denominator is zero.

CS1 parameters to be deprecated

parameter	extant replacement	preference ratio
|authorn-last=	|author-lastn=	2.51
|authorn-first=	|author-firstn=	2.36
|authorn-link=	|author-linkn=†	1.91
|authornlink=	|authorlinkn=	1066.9
|authorn-mask=	|author-maskn=†	101.43
|authornmask=	|authormaskn=	23.23
|editorn-link=	|editor-linkn=†	1.54
|editornlink=	|editorlinkn=	7.24
|editorn-mask=	|editor-maskn=†	3.17
|editornmask=	|editormaskn=	16
|editorn-first=	|editor-firstn=	1.42
|editorn-given=	|editor-givenn=
|editorn-last=	|editor-lastn=	1.58
|editorn-surname=	|editor-surnamen=
|subjectn-link=	|subject-linkn=†	47
|subjectnlink=	|subjectlinkn=

† these parameters are the canonical form

—Trappist the monk (talk) 13:26, 4 August 2015 (UTC)

Makes more conceptual sense the other way around. editor2-last implies the last name of editor #2, but editor-last2 implies the second surname of the editor.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:33, 5 August 2015 (UTC)

I agree with SMC on this point and think it would make more sense to keep the number in the middle than to have it out there hanging at the end. --Izno (talk) 17:47, 6 August 2015 (UTC)

The implication arises from the sense of the digit binding more tightly than the hyphen. (I.e., to "last" rather than "editor-last".) On the otherhand, when indexing a list of authors/editors I have found it most useful to have the index digit next to the equals sign, which gives the index better visibility, and provides a handy anchor for a regex. It's also easier to scan a list of authors/editors when the index is not buried inside the string. Which all might explain the medial location is not as widespread as the terminal form. I prefer the latter. ~ J. Johnson (JJ) (talk) 20:16, 7 August 2015 (UTC)

And yet others of us view the number as better in the middle. Comparing |editor2-last= and |editor-last2=, I parse the first as being the last name of the second editor and the second as the second last name of the (singular) editor. YMMV, and as far as I'm concerned, there's no harm in retaining both forms. Imzadi 1979 → 20:44, 7 August 2015 (UTC)

I am sympathetic to both points of view though my personal preference is terminal enumerator. I have added a column to the table that shows that overall, editors who have used these enumerated parameters generally prefer to use the terminal enumerator forms.

—Trappist the monk (talk) 12:26, 8 August 2015 (UTC)

That's surely skewed by how they're documented, and likely also by some individuals, perhaps even with AWB scripts, manually changing them to your "preferred" version. I know I've occasionally seen diffs that include this change along with other "general cleanup".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:06, 9 August 2015 (UTC)

Of course it's possible that the documentation has influenced one style choice over the other and its possible that editors change extant parameters to suit their own preferences. I don't know that AWB, as part of its general fixes, makes this kind of change; I haven't noticed changes of that kind. If you are suggesting that I have written an AWB script that changes enumerator-in-the-middle to enumerator-at-the-end, then you would be wrong.

—Trappist the monk (talk) 12:35, 9 August 2015 (UTC)

• Strongly oppose deprecation. These are still listed as the primary parameter names for {{citation}} and we should not diverge the CS1 and CS2 templates so far from each other as to deprecate one template's parameters in the other. Additionally, these are used by software for creating citation templates (I know, because I have written such software myself). What purpose is served by this change? What does it make better? It seems to me to be purely a foolish consistency. Finally, I note that once again Trappist is proposing major changes that relate to {{citation}} without even bothering to mention the discussion on Template talk:Citation. Trappist, you have been told over and over again: don't do that. —David Eppstein (talk) 17:14, 8 August 2015 (UTC)

  I don't understand why you think this affects {{citation}}... when it doesn't. --Izno (talk) 21:09, 8 August 2015 (UTC)

This change affects {{citation}} because {{citation}}, despite being cs2, is rendered by Module:Citation/CS1.

—Trappist the monk (talk) 21:52, 8 August 2015 (UTC)

Yes, and also because it is desirable to continue the current state of affairs in which we can change CS1 to CS2 or vice versa just by changing the template name. Not that changing the citation style of an article is frequent nor usually a good idea. But finding articles that mix the two styles is common enough, and changing them to use only one is usually a (minor) improvement. Thanks to recent improvements it's also possible to do this using a parameter but changing the actual template name seems less likely to encourage more inconsistency later. —David Eppstein (talk) 06:27, 9 August 2015 (UTC)

Standardizing on terminal enumerators will not prevent editors from changing CS1 to CS2 or vice versa just by changing the template name. Standardizing on lowercase parameter names did not change that nor did standardizing on the hyphen as a separator in parameter names change that.

—Trappist the monk (talk) 12:35, 9 August 2015 (UTC)

Citation Style 2 is distinguished from Citation Style 1 by its element separator (comma vs period), by lowercase static text (retrieved..., archived from ..., written at ..., etc. vs Retrieved..., Archived from ..., Written at ..., etc.), by terminal punctuation (none vs period), and cs2 automatically sets |ref=harv, cs1 doesn't. cs2 is not distinguished from cs1 by some subset of the commonly shared parameters.

The primary documentation for both cs1 and cs2 is {{csdoc}}. I grant that {{csdoc}} has a cs1 bias, so does Help:CS1 errors though I did a bit of work on that recently that removed some of the bias.

Of the sixteen parameters in the above table, these seven are found in Template:Citation/doc outside of the {{csdoc}} content:

|authornlink=

|authorn-link=

|editorn-first=

|editorn-last=

|editorn-link=

|editorn-given=

|editorn-surname=

Are we to believe then that the other nine are not or should not be supported by {{citation}}?

Yep, it is just for consistency whether you think it foolish or not. This choice is no different from the choice we made to standardize on parameter names that use hyphens instead of underscores or spaces; and standardize on lowercase instead of capitalized or camel-case. Choosing one flavor or the other is merely for consistency.

—Trappist the monk (talk) 21:52, 8 August 2015 (UTC)

Yes, I think it is foolish to suddenly kill off the primary documented parameter choices of the sister CS2 style, that our templates have been handling perfectly well, for the sake of no reason at all but neatness. The costs of this proposal involve breaking software or forcing the developers of the software to make parallel changes, breaking the mental model of who knows how many editors (as an example, I am still months after you made this change unable to remember to use contribution-url= in place of url= for the url of book chapters, and this is causing actual citations to be formatted wrong), forcing edits to who knows how many live citations after the red error messages start showing up, etc. The benefit of the proposal is appeasing the OCD of one single software developer who wants all the ducks to be perfectly lined up in a precise row. It's a bad idea. —David Eppstein (talk) 02:52, 9 August 2015 (UTC)

Agreed (other than the assumption of mental issues), and as I said earlier, the proposed "norms" don't make conceptual sense: |author2-last= implies the surname of the second author, while |author-last2= implies the second surname of the (singular) author. I.e., there are multiple, independent reasons not to deprecate this, and at least one to actually prefer the form Trappist wants to deprecate.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:00, 9 August 2015 (UTC)

Deprecation does not suddenly kill off anything.

—Trappist the monk (talk) 12:35, 9 August 2015 (UTC)

Must be why I still have an ant problem. This bug spray says "Deprecates on Contact!"  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:41, 10 August 2015 (UTC)

:-} ~ J. Johnson (JJ) (talk) 23:38, 11 August 2015 (UTC)

While all these are valid and could exist in the same article

|authorn-last= vs. |lastn=

|editorn-first= vs. |firstn=

they are also inconsistent. Just as parameter case was decided to be lower-case, this could also be decided in similar fashion.72.43.99.130 (talk) 19:34, 9 September 2015 (UTC)

|translator=

Latest comment: 7 years ago7 comments7 people in discussion

For a very long time editors have been asking for |translator= in some form or other. For a very long time the answer has been |others=. While I have been hacking away at the |coauthors= problem in Category:Pages containing cite templates with deprecated parameters I have become somewhat sympathetic to that request. So, here it is, these new parameters:

|translator=

|translatorn=

|translator-first=

|translator-last=

|translator-link=

|translator-mask=

|translator-firstn=

|translator-lastn=

And an example:

{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=[[Hesiod]] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}}

Hesiod (1810). "Works and Days". English Translations: From Ancient and Modern Poems. Vol. 2. Translated by Cooke, Thomas. N. Blandford. p. 745.

Relatively little is new as the translator-name-list makes use of existing author- and editor-name-list code. Currently, there is no support for et al. and no support for Vancouver styling.

Right now, |others= is appended to |translator= and the two rendered in the same place as |others=. This may not be the correct placement. There have been suggestions that |translator= belongs with |author=. What say you? Also, keep? Discard? What about punctuation? Static text?

—Trappist the monk (talk) 17:36, 25 August 2015 (UTC)

This is a good addition to the module. It will be welcomed by many editors. Here's how it looks with |others=:

{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=[[Hesiod]] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}

Hesiod (1810). "Works and Days". English Translations: From Ancient and Modern Poems. Vol. 2. Translated by Cooke, Thomas. Illustrated by Jane Doe. N. Blandford. p. 745.

That looks right to me. As for the fixed text "Translated by", I like it. Our guidance in the documentation for CS1 templates has contained only this recommended form since October 2012, as far as I can tell. – Jonesey95 (talk) 18:17, 25 August 2015 (UTC)

The ball on naming of parameters with numbers hasn't been resolved yet, so I would expect to see the number-in-the-middle variants also. --Izno (talk) 21:40, 25 August 2015 (UTC)

I don't think consistency requires us to introduce number-in-the-middle variants of new parameters, just because some of our old and entrenched parameters already have them. I'd prefer to see only one version of the new parameters rather than trying to duplicate all the variants of the old parameters. —David Eppstein (talk) 17:29, 27 August 2015 (UTC)

• Hesiod (1810). "Works and Days". In Smith, Edward (ed.). English Translations: From Ancient and Modern Poems. Vol. 2. Translated by Cooke, Thomas. Illustrated by Jane Doe. N. Blandford. p. 745.

I wondered how the above would work in with an editor. Are the translator and the illustrator meant to be volume wide and not related to the chapter?

Translator is one option but another is "Reviewed by" which is used by the ODNB, another is "Illustrated by". So rather than having a specific type why not have other parameters with a "other string" it could default to ("translated by") but be set to another word such as "Reviewed" or "Illustrated" etc. or set to "none" if other is a mixture of more than one type (translated by some, and illustrated by others), and instead of |translator-firstn= have |other-firstn= etc. -- PBS (talk) 16:52, 27 August 2015 (UTC)

Good, as long as these also work:

|translatorn-first=

|translatorn-last=

Discussions above (e.g. #deprecate enumerator-in-the-middle parameters) do not indicate a consensus in favor of this role-lastn order, with multiple editors objecting to it as counter-intuitive.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:16, 29 August 2015 (UTC)

As also noted in the relevant discussion, retaining both

|[role]n-last=

|lastn=

and

|[role]n-first=

|firstn=

is inconsistent and could also be counterintuitive. Per your suggestion then, |lastn=, |firstn= should be deprecated? 208.87.234.201 (talk) 14:52, 12 September 2015 (UTC)

Request move for Module talk:Citation/CS1

Latest comment: 7 years ago1 comment1 person in discussion

Could use some eyeballs at Module talk:Citation/CS1/Archive 12#Requested move 9 September 2015. Thanks! Kaldari (talk) 01:37, 15 September 2015 (UTC)

Add citationstyle= parameter to CS1 templates

Latest comment: 7 years ago9 comments9 people in discussion

All the talk about having |website= in italics or not got me thinking:

What if the cs1 templates like {{cite web}} etc. had a |citationstyle= parameter, with values of LSA, Vancouver, etc.

When these values are used, the CS1 templates would become "wrapper" templates to the existing Vancouver, LSA, etc. templates.

This would be a lot of work, but assuming the work got done, do you think the parameter would get a lot of use? davidwr/(talk)/(contribs) 02:47, 11 September 2015 (UTC)

We have a start to this in |mode= and |name-list-format=, but you're right, it would take some work. – Jonesey95 (talk) 02:58, 11 September 2015 (UTC)

Your idea has been in the back of my mind since the introduction of |mode= or there abouts. At about the same time there was a kerfuffle regarding small caps and LSA if I recall correctly. I have thought that we can extend |mode= to support clearly defined styles. Step 1 after we decide that this is something that we should be doing is to set down just exactly what it is that defines a particular style and then and only then hack the code to make it a reality.

—Trappist the monk (talk) 03:04, 11 September 2015 (UTC)

I strongly favour this idea. It would render the maintenance of citations easier if there are fewer citation template types. Also, fixing inconsistent citation styles or changing them when there is consensus to do so would be much easier.Jo-Jo Eumerus (talk, contributions) 08:54, 12 September 2015 (UTC)

Ideally, in my view, |mode= would be used with the {{citation}} template, which would make life much simpler for users – no need to choose which of the cite templates to use. However, I suspect this is difficult or impossible in all cases because there isn't always enough information to pick the right formatting. The |website= discussion above exemplifies one issue: having it as an alias of |work= loses information. Peter coxhead (talk) 10:00, 12 September 2015 (UTC)

I strongly oppose having multiple citation styles at all, much less supporting external ones (i.e. other than CS1 and CS2, and we should retire CS2). But if we're stuck with it, something like this is the way to do it, and we should get rid of external-citation-style-specific templates for Vancouver, etc., and just have it all done by the Lua module on the fly. So consider this "support until we come to our senses and have a single citation style like, well, every other publication in the world".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:31, 12 September 2015 (UTC)

If we are to retire one of CS1 or CS2, I would strongly prefer it to be CS1. All. Those. Periods. Make. It. Very. Difficult. To. Read. And. Really. What's. The. Point. Of. Them? —David Eppstein (talk) 20:28, 15 September 2015 (UTC)

Not sure how I feel about this being in {{cite xxx}} / {{citation}}, but I'd definitely support this feature if it could be shoved in {{reflist}}. Headbomb {talk / contribs / physics / books} 13:27, 12 September 2015 (UTC)

Reflist is only capable controlling styling of what's inside it, but that requires a strong classing dicsipline inside the templates (so same problem as above). It has absolutely no way of controling content of these templates. -- [[User:Edokter]] {{talk}} 09:06, 13 September 2015 (UTC)

Handling multiple italicized titles

Latest comment: 7 years ago6 comments4 people in discussion

Notwithstanding the above RfC, which appears to be firmly in favor of retaining the italics by default, we might actually want a |work-noitalic=yes, as something to be used on a case-by-case basis for a reason, and not just created so people can evade a style they don't like. A genuine use case for it would be books (discrete major works) that have been published inside other books (bound paper things) with separate titles. I'd like to be able to do: {{Cite book|chapter=Foreign Words and Phrases|work-noitalic=yes|work=''The Oxford Guide to Style'', in ''Oxford Style Manual''|...}}.

Another example would be: {{Cite book|chapter=Foreign Words and Phrases|work-noitalic=yes|work=''Blood of the Isles: Exploring the Genetic Roots of Our Tribal History'' [North American title: ''Saxons, Vikings and Celts: The Genetic Roots of Britain and Ireland'']|...}}.

Another approach to this, that might be less prone to "gimme my own style" abuse, would be to distinguishing the two use cases:

• {{Cite book|chapter=Foreign Words and Phrases|title=The Oxford Guide to Style|anthology=Oxford Style Manual|...}}
• {{Cite book|chapter=Foreign Words and Phrases|title=Blood of the Isles: Exploring the Genetic Roots of Our Tribal History|alt-title=Saxons, Vikings and Celts: The Genetic Roots of Britain and Ireland|alt-title-label=North American title|...}}

My approach to handling the former case has been {{Cite book|chapter=Foreign Words and Phrases|title=The Oxford Guide to Style|...}} (published as part of {{Cite book|title=Oxford Style Manual|...}}. For the latter I've been doing something similar, using two citation templates. It's an unnecessarily longwinded way to do it, and prone to breakage because it doesn't keep all the citation's details in one template "package".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:12, 14 September 2015 (UTC)

{{cite encyclopedia}} does something like this:

{{cite encyclopedia |chapter=Chapter |title=Title |encyclopedia=Anthology}}

"Chapter". Title. Anthology.

and so does {{cite book}} (sort of):

{{cite book |chapter=Chapter |title=Title |encyclopedia=Anthology}}

"Chapter". Title. {{cite book}}: Unknown parameter |encyclopedia= ignored (help)

There are constraints imposed by the metadata. A book title in the metadata is two parts: article (chapter) title and book title. {{cite encyclopedia}} emits the value from |chapter= and |encyclopedia=. {{cite book}} on the other hand, emits the values from |chapter= and |title=. Presumably, the {{cite encyclopedia}} model is the preferred model for an anthology because, one presumes, that parameters like ISBN, publisher, etc. apply to the anthology and not to the component book. There is no way that I know of to feed a three-part title to the metadata.

It would seem not to difficult a task to create {{cite anthology}} and |anthology= so that we don't 'misuse' {{cite encyclopedia}}.

—Trappist the monk (talk) 17:15, 14 September 2015 (UTC)

The example of different titles depending on place of publication seems to go against the principle of editors citing the copy that they examined. In most cases one editor would add the cite, and would have had access to only one copy. If an American and UK edition were used, probably they were used by two different editors, and the two editors would not necessarily know if the pagination in the two versions was the same. Jc3s5h (talk) 17:55, 14 September 2015 (UTC)

Right. Titles are the primary identifier of books (and other items), and if a publisher changes the title there is no telling what else may have been changed. If two titles are actually identical than one might be considered a reprint of the other, but how would an editor know that? Best that distinct titles have distinct citations. If a book or article has been republished under a different title that can be mentioned following the citation. ~ J. Johnson (JJ) (talk) 22:40, 14 September 2015 (UTC)

This isn't quite what I'm getting at. These are works that I have on hand, and they have three relevant titles: "Chapter/Article", Logical Book, Physical Book, in the one case, and "Chapter/Article", Regional Book Title I [Regional Book Title II], in the other. In the first case, I'm citing the specifics of a single work that has a hierarchy of three, not two, titles. In the other, I'm providing information to help readers locate the same source under two names (it has a typical hierarchy of two titles, but the major title has two variants). They're different cases.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:23, 15 September 2015 (UTC)

Oh. What you are talking about is not alternative titles, but titles at hierarchial levels of organization (e.g., work/chapter/section) - right? I got into that with the IPCC citations, but I am disinclined to re-visit it. ~ J. Johnson (JJ) (talk) 23:04, 15 September 2015 (UTC)

Cite book needs work alias for title

Latest comment: 7 years ago6 comments3 people in discussion

The above reminds me: {{Cite book}} needs to support |work= as an alias of what it calls |title=; as far as I recall, it's the only template in the series that doesn't support |work=, and this is a hassle for multiple reasons (having to remember which template demands what, not being able to convert easily between {{cite web}} and {{cite book}} for e-books, etc.).

Strictly speaking, it might make the most sense to re-code the {{Cite book}}'s |title= as an alias of existing |work= code (the input that gets italicized as a major work) in Cite/core, and use the same code to generate all |work= titles across all the templates. What is presently handled as |title= in almost all the templates (i.e., the input that gets quotation marks as a minor work) could be turned into an object called |item= or something, with |title= usually being an alias to it, and {{Cite book}}'s |chapter= being one, but using the same function to generate it regardless what template calls it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:12, 14 September 2015 (UTC)

For the purposes of cs1|2, {{citation/core}} is dead.

{{cite book}} only supports |work= visually (discussed here) for which reason I have suggested elsewhere in these pages that |work= and its aliases should be ignored by {{cite book}} as they were in the old days of {{citation/core}}.

—Trappist the monk (talk) 17:54, 14 September 2015 (UTC)

That you have a preference in this regard doesn't address why lack of support for |work= is problematic. I'm not suggesting that {{Cite book}} handle |title= and |work= as separate entities, but rather alias one to the other, the same way |accessdate= can also be called |access-date=. I'm not sure what "only supports |work= visually" even means, but have to run for now; will re-read that stuff and see if I can suss your meaning, if you don't clarify in the interim.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:27, 15 September 2015 (UTC)

{{cite book}} only supports |work= visually... means that you can have |work= in {{cite book}} with |title= and you will see it in the rendered citation. But, a value in |work= without |chapter= causes an error in the metadata – the citation is treated as a journal article (a bug I think that bears some thinking on). When |chapter= is included with |title= and |work= in {{cite book}}, |work= is rendered but not made part of the metadata while the other two parameters are (correctly this time).

—Trappist the monk (talk) 03:03, 15 September 2015 (UTC)

That sounds like it would be fixed by having |work= and |title= be the same thing (one an alias for the other). Why would we want {{Cite book|title=...|work=...}}? That would generally make the same not-sense as {{Cite journal|journal=...|work=...}}. That said, having a special case where the use of both would case |work= to render but be omitted from the metadata would actually resolve my above need for being able to cite The Oxford Guide to Style (a logical |work=, and previously published as a separate volume, and in both editions having its own chapters and authors and such), and the Oxford Style Guide (a published |title= of the book in the "bound thing of paper in my hands" sense). In pseudocode:

if $title

if $work

[optional code for handling work-editor, etc., if separate from editor, etc., of $title]

print italicized $work [without metadata]; print ', in '; print italicized $title [with metadata];

else print italicized $title [with metadata]

else if $work

print $work [with metadata as if $title]

else [i.e. both are missing] throw missing-title error

Seems pretty simple, though I forget what is using template code and what is using Lua in these things. This could even be used for bound journals, with the bound physical book being cited as the |work= and the journal issue being cited as |journal=. I ran into this problem before trying to cite my bound volumes of Jugend, The Studio, etc., in some Art Nouveau articles, and again ended up doing the two-citations-back-to-back thing: {{Cite journal}} followed by a {{Cite book}} for the bound volume that was largely a redundant citation, but necessary to both WP:SAYWHEREYOUGOTIT and preserve the details of the bound and original publications. This can be important because, e.g. The International Studio was bound by more than one operation, and differently; I have some bound volumes of it that overlap, with some being bound by calendar year, the others being bound by the journal's own volume/issue numbering order.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:49, 16 September 2015 (UTC)

The main use case I can see for having both |title= and |work= in a {{cite book}} would be for a long multivolume work where you want to separately represent the titles of the whole work and of the volume. But that's better handled with |title= and |volume= now that the volume parameter knows to not boldface long parameter values, as for instance in

{{cite book|first1=Elwyn R.|last1=Berlekamp|first2=John H.|last2=Conway|first3=Richard K.|last3=Guy|title=[[Winning Ways for your Mathematical Plays]]|volume=Volume 2: Games in Particular|year=1982|publisher=Academic Press}}

Berlekamp, Elwyn R.; Conway, John H.; Guy, Richard K. (1982). Winning Ways for your Mathematical Plays. Vol. Volume 2: Games in Particular. Academic Press. {{cite book}}: |volume= has extra text (help)

So I agree with the general sentiment that having title and work be aliases of each other seems harmless enough, as long as we can get an error flag when both are used together to let us find them and replace one of the two parameters by volume or series or whatever the replacement should be. However, this does bring up a different issue (not really solved very well by misuse of the work parameter): what do we do when we have a book series that contains a multivolume book and we want to refer to one volume of that book? The |volume= parameter currently has two quite different semantics: the number of a book within a series of books, and the number or title of a volume within a single multivolume book. Is there some way to add a |series-volume= parameter to be used in ambiguous cases, or something like that? —David Eppstein (talk) 00:37, 17 September 2015 (UTC)

choosing the correct metadata when |chapter=, |title=, and |work= are all set

Latest comment: 7 years ago2 comments1 person in discussion

Here is a list of all of the cs1 templates in the form:

{{cite ___ |title=Title |chapter=Chapter |work=Work}}

• arXiv: Author. "Title". {{cite arXiv}}: |arxiv= required (help); |author= has generic name (help); Unknown parameter |chapter= ignored (help); Unknown parameter |work= ignored (help) – chapter and work not supported in this template; includes |author= to avoid the bot invocation message
• AV media: "Chapter". Title. Work.
• AV media notes: "Chapter". Title. Work (Media notes).
• book: "Chapter". Title. {{cite book}}: |work= ignored (help)
• conference: "Chapter". Title. Work.
• DVD notes: "Chapter". Title. Work (Media notes).
• encyclopedia: "Chapter". Title. {{cite encyclopedia}}: |work= ignored (help)
• episode: "Title". {{cite episode}}: Missing or empty |series= (help) – chapter not supported; title is promoted to chapter; series is promoted to title; work ignored
• interview: "Chapter". "Title". Work (Interview).
• journal: "Title". Work. {{cite journal}}: |chapter= ignored (help) – chapter ignored
• mailing list: "Chapter". "Title" (Mailing list). {{cite mailing list}}: Missing or empty |url= (help) – work not supported; chapter is but shouldn't be
• map: "Title" (Map). Work. {{cite map}}: More than one of |map= and |chapter= specified (help) – chapter not supported;
• news: "Title". Work. {{cite news}}: |chapter= ignored (help) – chapter ignored
• newsgroup: "Title". Work. {{cite newsgroup}}: |chapter= ignored (help) – chapter ignored
• podcast: "Title". Work (Podcast). {{cite podcast}}: |chapter= ignored (help); Missing or empty |url= (help) – chapter ignored
• press release: "Title". Work (Press release). {{cite press release}}: |chapter= ignored (help) – chapter ignored
• serial: Title. Work. – chapter not supported
• sign: "Chapter". Title. Work. – should only support title
• speech: "Chapter". Title (Speech). Work. – should only support title
• techreport: "Chapter". Title. Work (Technical report).
• thesis: "Chapter". Title. Work (Thesis).
• web: "Title". Work. {{cite web}}: |chapter= ignored (help); Missing or empty |url= (help) – chapter ignored

and cs2:

• citation: "Title", Work {{citation}}: |chapter= ignored (help) – chapter ignored

The purpose of this list is to examine how the various templates handle the three parameters when all are set. Another conversation led me to discover that Module:Citation/CS1 may not be emitting correct metadata when |work= is set.

In Module:Citation/CS1 (and in {{citation/core}} before it), |work= and its aliases (|journal=, |newspaper= etc.) map to the meta-parameter Periodical. Similarly, |chapter= (and its aliases |article=, |contribution=, etc.) map to the meta-parameter Chapter.

There are two types of metadata: book and journal. When creating the citation's metadata, the module looks first at Chapter. If Chapter is set then the metadata type is set to book. If Chapter is not set but Periodical is set then the metadata type is set to journal. For all other cases, the metadata type is set to book.

Because the module knows which of the cs1|2 templates it is processing, we can use that knowledge to fix this issue. I will change the module so that these templates produce journal type metadata:

• arXiv
• conference – only when |work= is set (conference paper published in a journal)
• interview – only when |work= is set (interview published in a magazine, newspaper, television broadcast, etc.)
• journal
• news
• press release – only when |work= is set (published in a newspaper, magazine, etc.)
• citation – only when |work= is set

Then comes a more difficult question. The metadata can accommodate two title-holding parameters: rft.jtitle and rft.atitle for journals, or rft.btitle and rft.atitle for books. When cs1 templates use three title-holding parameters |chapter=, |title=, and |work=, which two of these should be made part of the metadata? Some templates are already constrained to one or two title-holding parameters; should others be similarly constrained?

—Trappist the monk (talk) 13:35, 15 September 2015 (UTC)

Module:Citation/CS1/sandbox tweaked. These are {{cite conference}} examples:

• |title=, |chapter=, |work= – uses jtitle, atitle, and sets genre to article
  • '"`UNIQ--templatestyles-000000B6-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=conference&rft.jtitle=Work&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
• |title=, |chapter= – uses btitle, atitle, and sets genre to bookitem
  • '"`UNIQ--templatestyles-000000B8-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.atitle=Chapter&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
• |title= – uses btitle and sets genre to book
  • '"`UNIQ--templatestyles-000000BA-QINU`"'<cite class="citation conference cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>

the same but this time with the one-way alias |book-title=; chapter is held in |title= (|chapter= is ignored when |book-title= is set):

• |book-title=, |title=, |work= – uses jtitle, atitle, and sets genre to article
  • '"`UNIQ--templatestyles-000000BC-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=conference&rft.jtitle=Work&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
• |book-title=, |title= – uses btitle, atitle, and sets genre to bookitem
  • '"`UNIQ--templatestyles-000000BE-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.atitle=Chapter&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>
• |book-title= – uses btitle and sets genre to book
  • '"`UNIQ--templatestyles-000000C0-QINU`"'<cite class="citation conference cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>

—Trappist the monk (talk) 15:05, 15 September 2015 (UTC)

error message tweak

Latest comment: 7 years ago3 comments2 people in discussion

I have tweaked Module:Citation/CS1/sandbox. The current live version of the module lumps all aliases of |chapter= into a single '|chapter= ignored' error message. This tweak causes the error message to identify the alias that is used in the cs1|2 template:

• "Title". Journal. {{cite journal}}: |chapter= ignored (help)
• "Title". Journal. {{cite journal}}: |contribution= ignored (help)
• "Title". Journal. {{cite journal}}: |entry= ignored (help)
• "Title". Journal. {{cite journal}}: |article= ignored (help)
• "Title". Journal. {{cite journal}}: |section= ignored (help)

—Trappist the monk (talk) 23:53, 15 September 2015 (UTC)

Wouldn't it be far more helpful to directly alias these to cite journal's version of |title=, given that that's what they mean? If they're used at the same time, then |chapter= could be treated as |at=, within |title=. And if |at= is also present, well, I dunno; have an |at2=.

This brings me back to my earlier proposal of normalizing all these parameter names across all the templates. It would be so much simpler if we had something like this:

{{Cite ______
|cite=
|at=
|work=
|...
}}

where |cite= is the minor work being cited (article, episode, book chapter, song on album, etc.); |at= is a subset there of, where relevant (section of article, section of book chapter, whatever); |work= is the major work (journal/newspaper/magazine, website, book title, album, TV series, etc.). I get more and more tempted all the time to just go create a CS3 designed from the start to be mutually consistent across all media types, so someone could learn how to cite in one sitting and get it right no matter what they're citing.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:12, 16 September 2015 (UTC)

Hindsight being what it is, were we to do it again, crafting a citation system from the ground up by starting with a real style guide and then coding to that would be preferable. But that isn't how it happened. We started with one or two templates that evolved into some twenty, all written independently. {{citation/core}} reduced the differences amongst the templates and Module:Citation/CS1 continues that with varying amounts of success. That is the problem with the evolutionary nature of Wikipedia: start with something disruptive and then tweak it until it's just good enough.

—Trappist the monk (talk) 09:59, 17 September 2015 (UTC)

COinS and smallcaps

Latest comment: 7 years ago2 comments2 people in discussion

Template:Smallcaps/doc needs an update (where the {{clarify}} tag is) on what people should do to get the desired Small Caps effect for certain things in particular citation styles, given that {{Smallcaps}} is not COinS-safe.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:02, 16 September 2015 (UTC)

  Done. Let me know if my edits are unclear in incomplete. – Jonesey95 (talk) 03:37, 17 September 2015 (UTC)

<cite> has been fixed, so we can now use it for entire citation

Latest comment: 7 years ago24 comments6 people in discussion

Yay! <cite>...</cite> has now been fixed to stop forcing italicization, so we can now use it instead of <span>...</span> to wrap the entire citation. This, BTW, has been interesting in that WP as a "developer user" of HTML & CSS has actually gotten W3C to fix things. Their own advice with regard to this element was self-contradictory between documents, and I got them to normalize to the current HTML5 description of the element. Details at Mediawiki talk:Common.css#cite-updates (anchor to update reporting in middle of larger thread about this issue over the last month or two).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:54, 12 September 2015 (UTC)

Done in the sandbox; compare live:

'"`UNIQ--templatestyles-000000CC-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>

to sandbox:

'"`UNIQ--templatestyles-000000CE-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>

—Trappist the monk (talk) 13:47, 12 September 2015 (UTC)

Two comments:

1. @Pigsonthewing:, I think this may be the incorrect way to handle the microformat. Have a look, if indeed that first span is intended as a microformat.
2. The intent was for the <cite> to wrap the entire citation, whereas the sandbox is only wrapping the title. --Izno (talk) 19:30, 12 September 2015 (UTC)

Re: #1: why do you think it's wrong?

Re: #2: I made a minimal example because that is easier to read. Here is one that is more complex:

'"`UNIQ--templatestyles-000000D0-QINU`"'<cite class="citation web cs1">[http://www.cdc.gov/ncbddd/autism/data.html "Autism Spectrum Disorder (ASD)"]. ''[[Centers for Disease Control and Prevention]]''. 12 August 2015.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Centers+for+Disease+Control+and+Prevention&rft.atitle=Autism+Spectrum+Disorder+%28ASD%29&rft.date=2015-08-12&rft_id=http%3A%2F%2Fwww.cdc.gov%2Fncbddd%2Fautism%2Fdata.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+9" class="Z3988"></span>

—Trappist the monk (talk) 19:41, 12 September 2015 (UTC)

The class=citation book looked like a microformat pair of classes to me, rather than what is their more likely use of just plain ol' CSS classes.

Didn't realize the COinS was dumped at the end of the citation. I haven't looked too closely at the HTML behind the template system before.... --Izno (talk) 00:08, 13 September 2015 (UTC)

Looks OK to me. Strictly, COinS isn't a microformat, and works differently to them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)

I would check and make sure that Mediawiki:* and other parts of the CSS cascade aren't anywhere doing anything that relies on span.citation vs just .citation, and same for the .book class selector. I.e., ensure that moving the classes from <span> to <cite> doesn't break something we don't notice immediately. Then again, if it does, I'm sure someone will tell us. I've not looked at COinS much; if the book, etc., classes are part of COinS, they do seem to need to be in <span>, so we might need both (presumably the <span> inside the <cite>, since the span by itself would have no semantic "reality" on its own); but if that's just one of WP's own classes, it can be in the <cite>.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:43, 12 September 2015 (UTC)

The extent of .citation in Common.css is the following:

/* Highlight clicked reference in blue to help navigation */ span.citation:target {  background-color: #DEF; } /* Styling for citations (CSS3). Breaks long urls, etc., rather than overflowing box */ .citation {  word-wrap: break-word; } /* For linked citation numbers and document IDs, where  the number need not be shown on a screen or a handheld,  but should be included in the printed version */ @media screen, handheld {  .citation .printonly {  display: none;  } } 

Indeed, @Edokter: I'm not sure about that first item there. Does the <ref>...</ref> include a span when it drops its content into the bottom of the page, or is that meant to specifically target our various and sundry reference templates? --Izno (talk) 00:13, 13 September 2015 (UTC)

That's the thing that makes the ^[2] or whatever of the ref citation turn light blue when you are in the refs section and click on the ^ link to get back to where you were in the text. So, yeah, that would need to change to refer to the <cite>, or to be a class by itself without the element being named (unless we really do need the span as well; I'm still not sure if that class has anything to do with COinS). Ultimately it probably does not matter if have a <cite><span>{{cite journal|...}}</span></cite> structure; costs nothing but a few bytes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:21, 13 September 2015 (UTC)

The Cite extension already provides the styles to turn the automatically generated referneces blue with the selector ol.references li:target, sup.reference:target. [Removed my own irrelevant bits] The span.citation:target snippet is an old remnant of the old link targeting mechanism, before the extension took over. The current snippet is useless and can be safely removed, because 1) references generated by citation templates, by themselves (ususally appearing between {{refbegin}}/{{refend}}), have no id and therefor 2) are not (and cannot) be linked to. That makes :target pretty pointless. -- [[User:Edokter]] {{talk}} 10:01, 13 September 2015 (UTC)

class="citation" is required so that a cs1|2 template in a bibliography gets the blue highlight when linked from a reference in a reference list.^[1] I've hacked the sandbox code so that class="citation" is not part of the <class> as an illustration.^[2]

References

1. Blue 2008.
2. Not blue 2008.

• Blue (2008). Title. {{cite book}}: Invalid |ref=harv (help)
• Not blue (2008). Title. {{cite book}}: Invalid |ref=harv (help)

—Trappist the monk (talk) 11:05, 13 September 2015 (UTC)

I see. In that case, The span should be removed or replaced by <cite>. Though it will work without the element in the selector, I'd prefer to keep the specificity consistent to prevent accidental linking to other elements with the .citation class. But that should not be a problem until the conversion is complete. -- [[User:Edokter]] {{talk}} 12:36, 13 September 2015 (UTC)

Sorry, I do not understand what you just wrote. In Module:Citation/CS1/sandbox, the cs1|2 template output (except for the COinS) was wrapped in <span>...</span>. It is now wrapped in <cite>...</cite>. My example shows, I think, that <cite class="citation"> is required to get the blue highlight when the target cs1|2 template is outside of a {{reflist}} as commonly occurs when an article uses {{sfn}} and {{harv}} et al.

—Trappist the monk (talk) 13:19, 13 September 2015 (UTC)

I was talking about the selector in Common.css. It should match whatever the module outputs. It now targets neither span or cite tags; just the .citation class, which is too broad. So I will make it target only cite.citation once the modules have been converted. If you still don't understand, don't worry about it. -- [[User:Edokter]] {{talk}} 21:52, 13 September 2015 (UTC)

FWIW, I am seeing blue highlight for the ^[2] ref even for the "Not blue" sample above, when I click on it's "^" link-back. I'm supposing this is because the underlying sandbox code has changed in the interim, but thought I'd report it in case not, and the example is supposed to do something else, since it might be relevant for debugging, if so.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:21, 14 September 2015 (UTC)

The superscripts do have the blue highlight; that isn't the issue. The issue is with the long-form citations; these links: #CITEREFBlue2008 and #CITEREFNot_blue2008 (or their mates in the reference list). The 'Blue' citation was rendered with <cite class="citation book"> but the 'Not blue' citation was rendered with <cite class="book">.

—Trappist the monk (talk) 16:33, 14 September 2015 (UTC)

Hack to Module:Citation/CS1/sandbox in support of the examples I made here is undone.

—Trappist the monk (talk) 11:23, 19 September 2015 (UTC)

@SMcCandlish: Congratulations on getting this fixed; it's good to see us as a movement contributing in that way. I've previously had WP:NOT cited at me when I've tried to get us to lead by example in similar areas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)

Pfft! WP:NOT has no power whatsoever to tell me who I can and can't contact off-wiki to fix things like W3C contradicting their own standards. >;-) It's the kind of thing I'd do anyway; the WP issue just made me notice this particular case. This may actually have quite noteworthy longer-term effects; apparently the entire W3C Cheatsheet was not being synched with the actual, live W3C Recommendation (the real spec), but had only been synched by hand or something to some old version in 2009! And WHATWG does what the Cheatsheet says. And browser makers and many others do what WHATWG says, to some extent. As far as I know, WHATWG has not updated its own materials yet since this W3C fix, but they should soon enough. I suspect and hope that much of what we're seeing with browsers lagging so far behind what the W3C HTML5 Recommendation says to do may be directly and primarily due to this synchronization failure. It would certainly be hot if that's the case, and all of sudden they started consistently implementing stuff we've been waiting on since 2013.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:28, 12 September 2015 (UTC)

2013 is awfully optimistic. --Izno (talk) 00:06, 13 September 2015 (UTC)

Hee haw! Yeah, I mean just the new stuff; I wasn't talking about stuff we've been waiting to work properly since the '90s. LOL. There did seem to be a rush to implement (at least with prefixes) lots and lots of stuff from the old draft and early release versions of HTML5, and then it just kind of stopped. I think it's because the Cheatsheet wasn't updated, so WHATWG didn't update. Then the HTML5 spec was revamped in 2013, and kinda nothing happened.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:09, 13 September 2015 (UTC)

In my opinion the CS1 and CS2 templates should produce HTML that not only gives the desired appearance at this moment, but also uses the HTML tags correctly. This thread should have begun with a link to the current official definition of the <cite> element so we could evaluate whether the changes discussed in this thread obey the documentation. Jc3s5h (talk) 15:22, 13 September 2015 (UTC)

WP:PROCESS is only important when it's important. :-) That documentation was already provided and discussed in the previous edition of this thread just a couple of weeks ago, and is also provided prominently in the Mediawiki talk:Common.css discussion linked to in the first post in this thread, where I indicated the matter had been discussed at length. Here it is again, with all the relevant off-site links. The purpose of pointers to such discussions is to avoid rehashing the same discussions. The entire point of these threads is, yes, to use the HTML correctly; the limitation of <cite> to title only was a 2009–2013 experiment that the HTML-using community rejected. As in HTML 4, the HTML5 spec allows this to cover citation data generally (the only required part is that at least one of the following must be present to use <cite>: author, title, URL).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:53, 14 September 2015 (UTC)

Update: I've fixed the placement and styling of <cite>...</cite> in all the templates using it that are not Template:Cite something, Template:Cite/something, or Template:Citation/something, which I've deferred here to Help talk:CS1. (This was mostly fixing it in single-source citations and in quotation templates). All that remains is for it to be integrated into the more complex citation templates.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:53, 14 September 2015 (UTC)

|section= not working in cite news?

Latest comment: 7 years ago10 comments4 people in discussion

I used |section= in a {{cite news}} in the My War article, and I got the error: "|chapter= ignored (help)". Curly Turkey 🍁 ¡gobble! 23:13, 15 September 2015 (UTC)

This?

{{cite news |last = Hampton |first = Howard |title = Black Flag: Waving Goodbye to the World |newspaper = [[The Phoenix (newspaper)|The Phoenix]] |date = 1984-04-17 |page = 8 |section = 3 |url = https://news.google.com/newspapers?nid=1959&dat=19840417&id=OXMhAAAAIBAJ&sjid=OogFAAAAIBAJ&pg=2247,1781571&hl=en |ref = harv}}

Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. p. 8. {{cite news}}: |section= ignored (help); Invalid |ref=harv (help)

|section= is an alias of |chapter=, hence the error message. Consider |at=Section 3, p. 8

Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. Section 3, p. 8. {{cite news}}: Invalid |ref=harv (help)

—Trappist the monk (talk) 23:24, 15 September 2015 (UTC)

Is |section= (or |chapter= or whatever) not supposed to work, then? Curly Turkey 🍁 ¡gobble! 00:29, 16 September 2015 (UTC)

The mention of |chapter= and |section= in Template:Cite news#COinS could lead someone to think it is OK to use those parameters in {{cite news}}. GoingBatty (talk) 02:31, 16 September 2015 (UTC)

I sthere some reason it shouldn't be? The newspaper I cited had sections with their own paginations. Curly Turkey 🍁 ¡gobble! 03:58, 16 September 2015 (UTC)

Isn't it true that most newspapers have separate sections and pagination? The documentation for |at= at {{cite news}} specifically includes Section. The decision to make |section= an alias of |chapter= was taken long ago in support of another template ({{cite manual}} I think). Chapters are not supported in periodicals because it is not possible to shoehorn three cs1|2 title-holding parameters (|newspaper=, |title=, and |section= in this case) into the two metadata title-holding parameters (rft.jtitle and rft.atitle). Because there is an in-source metadata parameter (rft.pages), setting |at=Section 3, p. 8 renders the complete citation visually as well as in the metadata.

—Trappist the monk (talk) 10:46, 16 September 2015 (UTC)

Well, that went over my head, but okay ... But wouldn't it be better to have the template automatically format it at least, rather than spit out an error? Curly Turkey 🍁 ¡gobble! 12:18, 16 September 2015 (UTC)

The template spits out an error because it doesn't know what to do with a chapter alias in a periodical-style citation. How should it be automatically formatted? Quoted? Italics? Neither of those? Where in the rendered citation should it go? The answers to these questions must apply to a very large majority of the templates in which |section= is used.

—Trappist the monk (talk) 15:02, 16 September 2015 (UTC)

Well, if it's what I have to do then it's what I have to do, but it (a) feels like a hack, and (b) is totally unintuitive. |at= "May be used instead of 'page' or 'pages' where a page number is inappropriate or insufficient"—in this case |page= sure doesn't seem insufficient (it's on page 8!), and |at= isn't the obvious answer (you have to dig to find it, and then interpret the documentation as "Aha! This situation!").

if |section= et. al don't work, then shouldn't they be removed from the "COinS metadata is created for these parameters" section? Curly Turkey 🍁 ¡gobble! 23:27, 16 September 2015 (UTC)

|section= should be supported in periodicals, independently of |chapter=, because there are important sources that do break articles by sections. Also by paragraphs. ~ J. Johnson (JJ) (talk) 22:40, 17 September 2015 (UTC)

ISBN error category

Latest comment: 7 years ago5 comments3 people in discussion

So that it is consistent with the naming convention of other identifier error categories, and while it is mostly empty, I've changed the ISBN error category name from Category:Pages with ISBN errors‎ to Category:CS1 errors: ISBN in Module:Citation/CS1/Configuration/sandbox.

After the next module update, I think that the old category Pages with ISBN errors ‎can go away.

—Trappist the monk (talk) 16:34, 22 August 2015 (UTC)

Support. It helps distinguish it from Category:Articles with invalid ISBNs as well. – Jonesey95 (talk) 10:14, 23 August 2015 (UTC)

This will break some ISBN fixing tools such as WPCleaner. -- Magioladitis (talk) 12:39, 19 September 2015 (UTC)

If Category:Pages with ISBN errors‎ is hard coded into the tool, I have no sympathy. Wikipedia:WPCleaner/Configuration/Help#isbn_errors_categories suggests that ISBN categories are kept in a configuration file somewhere though that isn't at all clear from the documentation. If this latter is true, then I see no reason not to proceed.

—Trappist the monk (talk) 13:39, 19 September 2015 (UTC)

Magioladitis, can you provide some details? If we are breaking something by standardizing this category name, we are willing to help fix it or test the tool after the change. It looks like we may need to change the second category name at User:NicoV/WikiCleanerConfiguration#ISBN; will that fix the problem? – Jonesey95 (talk) 13:46, 19 September 2015 (UTC)

Test for date in |author=?

Latest comment: 7 years ago9 comments4 people in discussion

I came across a date in |author= while working on something else. How hard would it be to test for dates, or at least well-formed dates, in |author= fields? As always, I worry about false positives, so it may be something to put in a maintenance category.

I suspect that some sort of automated reference-filling tool populated |author= with dates, or at least included dates along with the author name, due to bad metadata on the source web page or bad processing of the page's data. – Jonesey95 (talk) 13:58, 19 September 2015 (UTC)

If such a test is to be created, bear in mind we allow editors to enter corporate authors in this field. Some organizations have a date fragment in their name. So the test should only be triggered if a well-formed date containing a year, month, and day is present. Jc3s5h (talk) 14:11, 19 September 2015 (UTC)

@Jonesey95: Edits like the one you've mentioned are a result of editors not fixing the suggestions given by Reflinks before saving their edits. We tried to discuss this with Dispenser but did not get any answer. BattyBot tries to fix/remove some bad author values, but can't fix them all. Therefore, I support a maintenance category. GoingBatty (talk) 14:16, 19 September 2015 (UTC)

Reflinks was the tool: diff and diff. But, like any edit, the tool-user is equally culpable.

If this is a problem caused by a tool, then the tool should be fixed. I suspect that searching for date formats that both do and don't comply with WP:DATESNO is a challenge that we should only accept if there is significant evidence of widespread malformed |author= parameters in the field.

(I've renamed this section to remove {{para}} so that section links from watch lists work.)

—Trappist the monk (talk) 14:31, 19 September 2015 (UTC)

@Trappist the monk: A quick search of the September 2015 database dump of found 2,304 results. I'm sure other formats will find additional instances. I'm adding some rules for BattyBot to remove the date from the author parameter when it matched the YYYY-MM-DD date in the date parameter. I'd also be happy if ReferenceBot would notify editors when they added references with incorrect parameters like this. GoingBatty (talk) 15:40, 19 September 2015 (UTC)

Is that number sufficiently large to make us add code to the module and create some sort of category to support it? Is this an automated tool issue or is it an error commonly made by editors filling out the template?

—Trappist the monk (talk) 16:06, 19 September 2015 (UTC)

@Trappist the monk: To determine if it's sufficiently large enough, I guess you would first identify the most common incorrect formats, see how many added/tweaked rules could be added to BattyBot, and then see how many are left. My guess is this is commonly an issue of people not taking care when using automated tools (and people unwilling to fix their tools), but I have no statistics on that. GoingBatty (talk) 18:32, 19 September 2015 (UTC)

How can BattyBot fix these errors if they are not yet in a category? – Jonesey95 (talk) 20:31, 19 September 2015 (UTC)

@Jonesey95: I built the list of articles based on a database search for author\s*=\s*(January|February|March|April|May|June|July|August|September|October|November|December)\s+\d{1,2},\s+\d{4}. GoingBatty (talk) 20:40, 19 September 2015 (UTC)

Citeweb website parameter

Latest comment: 7 years ago1 comment1 person in discussion

Would it be possible to make this respond to typing "site=" as well as "website=" ? "Web" is implied by the use of the template and this would take up less space and I find myself using that by accident a lot. Ranze (talk) 14:52, 22 September 2015 (UTC)

Proposal for lead with the main cite that Wikipedians come to this page for

August 24, 2023