Misplaced Pages

Revision as of 17:59, 7 September 2015

This is the talk page for discussing improvements to the Citation Style 1 page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcut WT:CS1

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97Auto-archiving period: 30 days

Misplaced Pages Help B‑class High‑importance

This page is within the scope of the Misplaced Pages Help Project, a collaborative effort to improve Misplaced Pages's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Misplaced Pages HelpWikipedia:Help ProjectTemplate:Misplaced Pages Help ProjectHelp B This page does not require a rating on the project's quality scale. High This page has been rated as High-importance on the project's importance scale.

Help: Citation Style 1

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 41, 42, 43, 44, 45, 46, 47, 48, 49, 50 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 61, 62, 63, 64, 65, 66, 67, 68, 69, 70 71, 72, 73, 74, 75, 76, 77, 78, 79, 80 81, 82, 83, 84, 85, 86, 87, 88, 89, 90 91, 92, 93, 94, 95, 96, 97

Index

This page has archives. Sections older than 30 days may be automatically archived by ClueBot III when more than 1 section is present.

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

This is the talk page for discussing improvements to the Citation Style 1 page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97Auto-archiving period: 30 days

Feature request: |note= parameter

It'd be nice to have a |note= parameter, so that things like "Source is a blog, but published by a project of the city government; primary but not self-published.", kept with (inside) the citation instead of external to it in an HTML comment. It's pretty common to to use a pseudo-parameter like |note=, or (in other contexts, like cleanup/dispute templates) |reason=, for this purpose, but CS1's auto-detection and red-flagging of unrecognized parameters makes this impossible at present.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  16:06, 15 July 2015 (UTC)

It would be nicer still to have a |null= to work around the red-flagging because there are time when as SMcCandlish unrecognized parameters are convenient. -- PBS (talk) 22:56, 15 July 2015 (UTC)

I think the problem with the example above is that all of the other parameters in CS1 are for bibliographic data that theoretically at least is understandable to readers and meaningful outside Misplaced Pages. Whereas that comment would be understandable to maybe 1 or 2 out of every 1,000 Misplaced Pages readers – the ones who are familiar with what WP editors usually mean when they call a source "primary". For that sort of thing, an HTML comment embedded in the wikitext seems like exactly the right way to handle it. Let's keep meta comments and WP-specific issues separate from the data. – Margin1522 (talk) 11:21, 16 July 2015 (UTC)

SMcCandlish is not proposing a display variable, but one to be used in place of <!-- a hidden comment --> as the parameter |reason= is used in the template {{Clarify}}. -- PBS (talk) 19:35, 16 July 2015 (UTC)

I can see the advantage of a |note= parameter. I find the |others= parameter very useful - today I've used it to flag "(published anonymously)". Library catalogs sometimes use square brackets for this. Aa77zz (talk) 20:19, 16 July 2015 (UTC)

Like this from Finch?:

{{ cite book | last=Leach | first=William Elford | author-link=William Elford Leach | year=1820 | chapter=Eleventh Room | title= Synopsis of the Contents of the British Museum | place=London | publisher=British Museum | edition=17th| pages=65-70 | others=(published anonymously) }}

Specifically these bits:

| publisher=British Museum and | others=(published anonymously)

One contradicts the other. And, from the template documentation at Authors:

• others: To record other contributors to the work, including illustrators and translators. For the parameter value, write Illustrated by John Smith or Translated by John Smith.

I think that your use of |others= as you have done is an improper use of the parameter.

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

I was well aware that my use was "improper" but I had wanted to say that the author wasn't specified rather than the publisher wasn't specified. I've now deleted the parameter.Aa77zz (talk) 07:05, 17 July 2015 (UTC)

At Finch it now says: "The name of the author is not specified in the document." If that is so, then who is | last=Leach | first=William Elford?

—Trappist the monk (talk) 09:31, 17 July 2015 (UTC)

I was trying to simplify as this isn't an important reference. In the Finch article I've actually cited two sources - the other is Bock 1994. It is Bock who gives the information about the publication: "All the parts of this public guide to the British Museum are unsigned, however, this part was clearly written by Leach as indicated by the fact that he was Keeper of Zoology at the time and by the numerous references to Leach's list of family-group names by his contemporaries." I'm reluctant to add a notelist with this info. It is not uncommon to have "unsigned" articles. I've met them in 19th century book reviews. Sometimes there is a RS giving the authors name. I've seen square brackets used in references when the information isn't present on the title page - such as the author or the year of publication. Aa77zz (talk) 10:17, 17 July 2015 (UTC)

If Synopsis ... doesn't identify the authors then | last=Leach | first=William Elford | author-link=William Elford Leach should be removed from that citation. You might then change the note to read: "Attributed to Leach in Both 1994." I'm not at all sure that this is even important. Will knowing that Both thinks that Leach wrote "Eleventh Room" help readers find a copy of Synopsis ...?

—Trappist the monk (talk) 12:13, 17 July 2015 (UTC)

The conversation has moved a long way from User:SMcCandlish's request for a |note= parameter to allow a hidden editor to editors message, similar to |reason= in the cleanup templates. -- PBS (talk) 21:23, 30 July 2015 (UTC)

And it would actually serve the purpose Aa77zz has in mind, anyway. So, I renew the request. All fields I'm aware of, including physical sciences, social sciences, humanities, law, etc., that regularly cite sources do in fact have definitions of "primary source" and so on (even if they sometimes differ in their particulars), so the objection to my example isn't even valid. And it was just an example. There are any number of reasons to use such a parameter, e.g.:

• |note=Titled "Blood of the Isles" in the UK printing.
• |note=Paywall can be bypassed by request at URL here.
• |note=Page 17 is missing from this Project Gutenberg scan, but is not part of the cited material.
• |note=There is a newer edition, but the cited section has not changed, according to URL to changes list.
• |note=This is a master's thesis, but was reviewed by Notable Researcher Here, and has been cited in 12 journal papers as of July 2015.

etc. There's no reason to put these in messy HTML comments that some editors are apt to delete on sight because they don't like HTML comments. And, really, no one's head will asplode if someone happens to include a more WP-jargon-specific note. They'll just shrug and move on. No one will see them but wikitext-editing users anyway.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:15, 30 July 2015 (UTC)

Are you hoping that the note will appear when a user mouses over the tag as with {{clarify-inline}} ? AngusWOOF (bark • sniff) 08:12, 22 August 2015 (UTC)

extra text in |edition= detection bug

There is a bug in the extra text detector. The current detector was intended to find |edition=2nd ed. which would render as

Title (2nd ed. ed.). {{cite book}}: |edition= has extra text (help)

But, it also finds the 'ed' at the end of illustrated, revised, etc:

Title (revised ed.).

So, I've adjusted the test:

Title (2nd ed. ed.). {{cite book}}: |edition= has extra text (help) – should find 'ed.'

Title (revised ed.). – should not find 'ed'

—Trappist the monk (talk) 11:38, 25 July 2015 (UTC)

I'm still seeing the error raised with "revised": {{Cite book|authorlink=Maynard Solomon|last=Solomon|first=Maynard|title=Beethoven|edition=2nd revised|location=New York|publisher=Schirmer Books|year=2001|isbn=0-8256-7268-6}}:

• Solomon, Maynard (2001). Beethoven (2nd revised ed.). New York: Schirmer Books. ISBN 0-8256-7268-6. <-- shows "CS1 maint: Extra text (link)"

but not in {{Cite book/new}}:

• Solomon, Maynard (2001). Beethoven (2nd revised ed.). New York: Schirmer Books. ISBN 0-8256-7268-6.

Any reason why {{Cite book/new}} cannot be deployed? -- Michael Bednarek (talk) 13:42, 9 August 2015 (UTC)

{{cite book/new}} is the same as {{cite book}} except that it uses the sandbox version of Module:Citation/CS1. Because every change to the live module dumps a couple of million articles on the job queue, we collect multiple changes in the sandbox before updating the live module.

—Trappist the monk (talk) 14:44, 9 August 2015 (UTC)

How do you suppress errors when titles are missing?

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=]
 |volume=33 |pages=549–551
 |bibcode=
 |doi=
}} reproduced and translated in {{cite journal
 |last1=<!----> |first1=<!---->
 |year=1957
 |title=<!---->
 |journal=]
 |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 , 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 , 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 . 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 "don'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=]
 |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=]
 |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)

Italicization of websites in citations

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 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 Misplaced Pages should create a non-traditional form of punctuation. Indeed, not even Misplaced Pages 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 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 Misplaced Pages 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 "Misplaced Pages" not "Misplaced Pages.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 ".
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: Misplaced Pages .

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 Misplaced Pages, 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 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 Misplaced Pages 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)

deprecate enumerator-in-the-middle parameters

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.

† 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)

error handling for parameters with defined values

As the result of a conversation elsewhere, I have added a function is_valid_parameter_value() that checks a parameter's value against a list of accepted values. If the parameter value is not a member of the accepted list, the function emits an invalid parameter error. There is code in the current live module that detects these kinds of errors for |mde= and |name-list-format=. This new code extends that functionality to several other parameters.

|nopp=

accepted values are 'yes', 'true', 'y'

• Title: nopp=y. pp. 45-46. {{cite book}}: |page= has extra text (help); Unknown parameter |nopp= ignored (|no-pp= suggested) (help)
• Title: nopp=true. pp. 45-46. {{cite book}}: |page= has extra text (help); Unknown parameter |nopp= ignored (|no-pp= suggested) (help)
• Title: nopp=yes. pp. 45-46. {{cite book}}: |page= has extra text (help); Unknown parameter |nopp= ignored (|no-pp= suggested) (help)
• Title: nopp=1. p. pp. 45-46. {{cite book}}: |page= has extra text (help); Invalid |nopp=1 (help); Unknown parameter |nopp= ignored (|no-pp= suggested) (help)

|name-list-format=

accepted value is 'vanc'

• Last, Fred George; Laster, A. B.; Lastest, First. Title: name-list-format=vanc. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)
• Last, Fred George; Laster, A. B.; Lastest, First. Title: name-list-format=venc. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)

|mode= – accepted values are 'cs1', 'cs2'

• Last, Fred George; Laster, A. B.; Lastest, First. Title: mode=cs1. {{citation}}: Missing pipe in: |title= (help)
• Last, Fred George; Laster, A. B.; Lastest, First, Title: mode=cs2 {{cite book}}: Missing pipe in: |title= (help)
• Last, Fred George; Laster, A. B.; Lastest, First. Title: mode=cs3. {{cite book}}: Invalid |mode=cs3 (help); Missing pipe in: |title= (help)

|dead-url=

accepted values are 'yes', 'true', 'y', 'no'

• "Title: dead-url=y". Archived from the original on 2015-08-07. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
• "Title: dead-url=true". Archived from the original on 2015-08-07. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
• "Title: dead-url=yes". Archived from the original on 2015-08-07. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
• "Title: dead-url=no". Archived from the original on 2015-08-07. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
• "Title: dead-url=f". Archived from the original on 2015-08-07. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

|subscription=

accepted values are 'yes', 'true', 'y'

• Title: subscription=y. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
• Title: subscription=true. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
• Title: subscription=yes. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
• Title: subscription=1. {{cite book}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

|registration=

accepted values are 'yes', 'true', 'y'

• Title: registration=y. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)
• Title: registration=true. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)
• Title: registration=yes. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)
• Title: registration=1. {{cite book}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)

Have I missed any others? —Trappist the monk (talk) 17:11, 7 August 2015 (UTC)

I did:

|ignore-isbn-error=

accepted values are 'yes', 'true', 'y'

• Title: ignore-isbn-error=y. ISBN 1234567890. {{cite book}}: Check |isbn= value: checksum (help); Unknown parameter |ignore-isbn-error= ignored (|isbn= suggested) (help)
• Title: ignore-isbn-error=true. ISBN 1234567890. {{cite book}}: Check |isbn= value: checksum (help); Unknown parameter |ignore-isbn-error= ignored (|isbn= suggested) (help)
• Title: ignore-isbn-error=yes. ISBN 1234567890. {{cite book}}: Check |isbn= value: checksum (help); Unknown parameter |ignore-isbn-error= ignored (|isbn= suggested) (help)
• Title: ignore-isbn-error=1. ISBN 1234567890. {{cite book}}: Check |isbn= value: checksum (help); Unknown parameter |ignore-isbn-error= ignored (|isbn= suggested) (help)

|no-tracking=

accepted values are 'yes', 'true', 'y'

• Title: no-tracking=y. {{cite book}}: Missing pipe in: |title= (help)
• Title: no-tracking=true. {{cite book}}: Missing pipe in: |title= (help)
• Title: no-tracking=yes. {{cite book}}: Missing pipe in: |title= (help)
• Title: no-tracking=1. {{cite book}}: Invalid |no-tracking=1 (help); Missing pipe in: |title= (help)

—Trappist the monk (talk) 17:43, 7 August 2015 (UTC)

and another:

|last-author-amp=

accepted values are 'yes', 'true', 'y'

• Title: last-author-amp=y. {{cite book}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
• Title: last-author-amp=true. {{cite book}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
• Title: last-author-amp=yes. {{cite book}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
• Title: last-author-amp=1. {{cite book}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

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

I've created a table of keywords in Module:Citation/CS1/Configuration/sandbox so that the keywords can be defined and the same reused; 'yes, true, y' is used for several parameters – no need to keep separate lists.

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

Why reinvent the wheel, when we have {{yesno}}? --Redrose64 (talk) 17:34, 15 August 2015 (UTC)

template vs module.

—Trappist the monk (talk) 17:39, 15 August 2015 (UTC)

Module:Yesno does exist. My concern using it in general would be that in a number of cases we don't have a boolean consideration (e.g. yes v. no) but instead an enumerated comparison. --Izno (talk) 19:02, 15 August 2015 (UTC)

AWB or bot opportunity to fix 1000+ missing author errors

There are over 1,000 (around 1,200, I think) articles on towns in India that have citations with a |first= but no |last=. I have changed a few hundred of these from |first= to |publisher=, but my fingers are getting tired. If someone with AWB or some nice bot code wants to have a go at them, do a search for this:

insource:/\|first=Registrar General...Census Commissioner, India/

Here is a sample change.

If it would help to have a list of these article titles, let me know, and I'll compile one. – Jonesey95 (talk) 20:10, 9 August 2015 (UTC)

Note that since the most recent edit to the CS1 module, these citations with a |first= but no |last= no longer generate a missing author error. The example article you give no longer shows a missing author error if you look at the revision immediately before your edit. The count of articles populating Category:CS1 errors: missing author or editor has dropped precipitously since the recent edit to the CS1 module, from almost 9000 articles to a current count of roughly 1300. Stamptrader (talk) 00:22, 10 August 2015 (UTC)

Fixed in the sandbox. See Missing author without error message

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

True, but these are definitely errors, and they are all of the same type, so a script or bot should be able to fix them quickly and easily. – Jonesey95 (talk) 03:34, 10 August 2015 (UTC)

vancouver errors

From AKAP12 this cite:

{{cite journal | vauthors = Lin F, Wang Hy, Malbon CC | title = Gravin-mediated formation of signaling complexes in beta 2-adrenergic receptor desensitization and resensitization | journal = J. Biol. Chem. | volume = 275 | issue = 25 | pages = 19025–34 | year = 2000 | pmid = 10858453 | doi = 10.1074/jbc.275.25.19025 }}

Lin F, Wang Hy, Malbon CH (2000). "Gravin-mediated formation of signaling complexes in beta 2-adrenergic receptor desensitization and resensitization". J. Biol. Chem. 275 (25): 19025–34. doi:10.1074/jbc.275.25.19025. PMID 10858453. {{cite journal}}: Vancouver style error: name in name 2 (help)CS1 maint: unflagged free DOI (link)

The error occurs because the second author includes a lowercase initial. The author's name, according to the doi link is Hsien-yu Wang.

According to Citing Medicine: The NLM Style Guide for Authors, Editors, and Publishers surnames are listed first followed by one or two uppercase initials. In this case, because the author is Asian, Hsien-yu is the surname and Wang the given name. Has PubMed got it wrong?

What advice should be given at Vancouver style error to editors who encounter this sort of error?

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

Few editors follow this page. You might to better to ask at the humanities reference desk about how asian authors shorten their name when using the Roman alphabet. Then there is the additional problem of how journals that use Vancouver style shorten the names of asian authors, which could be different. Jc3s5h (talk) 16:19, 10 August 2015 (UTC)

@Trappist the monk: It's also unlikely that the order given is wrong. Chinese names in the form Foo-bar are usually given names, so a Western source would be likely to call this person Hsien-yu Wang, who would be Wang Hsien-yu at home, and the proper family-name-first version in the Western bibliographic style is Wang, Hsien-yu. The "Foo-bar" convention is not universal, and the same name will often be rendered "Foo-Bar", and sometimes "Foo Bar" or even "Foobar", depending on how sources treat Chinese names in latin script. I encounter this issue a lot in cue sports writing, since China fields many players of pool, snooker, and carom billiards. "Foo-bar" seems to be something of a spreading convention, but it may vary geographically (you have Taiwan, Hong Kong, Macau, and Singapore to factor in, plus Chinese diaspora in the US, etc., and it's highly unlikely they're all converging on exactly the same format). Anyway, the point being you can get away with "Wang HY".  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  17:05, 10 August 2015 (UTC)

Even western authors with hyphenated names should sometimes have the second part of the name included in the initials. And sometimes the correct initials really do include lower-case letters. I have a Belgian co-author named Jean-Claude who insists that the correct abbreviation of his name is J.-Cl. On the other hand I know a Japanese author named Ken-ichi who wants his name abbreviated K. rather than K.-I. or K.-i. My general feeling is that any attempt to automatically deduce how to rearrange human names is doomed to at least occasional failure (as usual, see "Falsehoods Programmers Believe About Names") so it is essential that there be some workaround that we can use when the machines get it wrong. In this case, "Hy" is the correct Vancouver initialization and there should be some way of persuading the template to allow it. —David Eppstein (talk) 17:21, 10 August 2015 (UTC)

Agreed. – S.McC.
PS: I wasn't meaning to imply "do the wrong thing to make the template happy", but rather that since the name is a transliteration anyway, in a style that's not used consistently, that it might not matter in this case. There are Europeans who abbreviate names like Christophe as "Ch.", so my lackadaisicalness on this wouldn't help them.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  17:37, 10 August 2015 (UTC)

The rules for Vancouver system author name lists prohibit hyphens in the given name initials, see: Given names containing punctuation, a prefix, a preposition, or particle. The error mentioned at the start of this conversation is not the result of an attempt to automatically deduce how to rearrange human name, but arises because Module:Citation/CS1 cannot know if the lowercase 'y' is intentionally lowercase (cases like this or as the result of Romanization: Θ → Th) or a typo. The error can be suppressed after review by treating the name as an institutional name: |vauthors=Lin F, ((Wang Hy)), Malbon CC

—Trappist the monk (talk) 15:13, 14 August 2015 (UTC)

DOI throwing an error

The DOI found here is not accepted by the DOI checking code called by {{Cite journal}}.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  16:54, 10 August 2015 (UTC)

(Edit conflict: Trappist, you accidentally removed my earlier comment.)

Looks ok to me: Pérez-García, Alejandro; Romero, Diego; Fernández-Ortuño, Dolores; López-Ruiz, Francisco; De Vicente, Antonio; Torés, Juan A. (2009). "The powdery mildew fungus Podosphaera fusca (synonym Podosphaera xanthii), a constant threat to cucurbits". Molecular Plant Pathology. 10 (2): 153–160. doi:10.1111/j.1364-3703.2008.00527.x. Maybe you're incorrectly including the period that pubmed puts after it? —David Eppstein (talk) 17:04, 10 August 2015 (UTC)

Not intentionally.

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

Don't include the terminal period that PubMed includes:

"Title". Journal. doi:10.1111/j.1364-3703.2008.00527.x. {{cite journal}}: Check |doi= value (help)

The doi checking code looks for a terminal comma or period. If one of those is found, the code emits the error message. Was the help text insufficient to the task?

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

@David: Ah, yeah, that would be it. Derp.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  17:07, 10 August 2015 (UTC)

@Trappist: Yeah, it says "Check |doi= value (help)", and I looked at the help but somehow did not see "does not end with punctuation". Total PEBCAK on my part. Time for coffee.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  17:30, 10 August 2015 (UTC)

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 Misplaced Pages 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:

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)

How to cite letter in CS1?

I would like to cite the letter found here. The hard copy of the letter appears to be held by the National Archives and Records Administration (NARA) in a box titled "HSCA Segregated CIA Collection, Box 19", and they appear to refer to the letter as "NARA Record Number: 1993.08.02.09:31:14:370053". If I use {{cite letter}}, then...

{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}

...gives me...

Frank, Sturgis (May 7, 1976). "Pre-freedom of information request notice of charges". Letter to Gene Wilson. Retrieved August 11, 2015.

Unfortunately, with the above template I don't believe I am able to note additional information about where this original document may be found, such as the |id= noted above. Is there something similar in CS1 that I can use? If so, what is the equivalent of |recipient= in CS1? Also, should |title= be "Letter from Frank Sturgis to Gene Wilson" or the subject noted by the author, and NARA, as "Pre-freedom of information request notice of charges"? Sorry for so many questions. Thanks! - Location (talk) 20:29, 12 August 2015 (UTC)

Try:

{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015 |via= National Archives and Records Administration (HSCA Segregated CIA Collection, Box 19) |id= NARA Record Number 1993.08.02.09:31:14:370053 }}

which gives:

Frank, Sturgis (May 7, 1976). "Pre-freedom of information request notice of charges". Letter to Gene Wilson. NARA Record Number 1993.08.02.09:31:14:370053. Retrieved August 11, 2015 – via National Archives and Records Administration (HSCA Segregated CIA Collection, Box 19).

I just added |id= to the template, and |via= was already there. Imzadi 1979 → 20:51, 12 August 2015 (UTC)

Are you citing the hard copy? Have you actually seen the hard copy? If not, and you are citing the copy at the Mary Ferrell Foundation website, then the direct cs1 equivalent to {{cite letter}} would be {{cite web}} (WP:SAYWHEREYOUGOTIT applies). It should be noted that {{cite letter}} is a meta-template of {{cite news}}. Such a citation might look like this:

{{cite web |last=Sturgis |first=Frank |title=Pre-freedom of information request notice of charges |type=Letter to Gene Wilson |website=Mary Ferrell Foundation |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}

Sturgis, Frank (May 7, 1976). "Pre-freedom of information request notice of charges". Mary Ferrell Foundation (Letter to Gene Wilson). Retrieved August 11, 2015.

In your example, |last= and |first= are swapped; the writer's name if 'Frank Sturgis'.

—Trappist the monk (talk) 21:01, 12 August 2015 (UTC)

Imzadi1979, Trappist the monk: Thanks for the feedback! - Location (talk) 22:49, 13 August 2015 (UTC)

I think the advice to use {{cite web}} instead of a more specific citation type for a source found on the web rather than through hardcopy is wrongheaded. When we find books online through Google books, we should use {{cite book}}, not {{cite web}}. When we find academic journal articles online at their official publisher's online repository, we should use {{cite journal}}, not {{cite web}}, even for journals that have no print edition and are only online. And for the same reason, if we are viewing a facsimile of a written letter, we should still use {{cite letter}}. —David Eppstein (talk) 23:51, 13 August 2015 (UTC)

Yes, this is why the |url= parameter is not confined to {{cite web}} but is included in all the others. --Redrose64 (talk) 12:12, 14 August 2015 (UTC)

|script-chapter=

Following up on this conversation, I've added |script-chapter=. Styling and order of rendered chapter parts follows the same rules as |script-title=:

{{cite book/new |title=Tōkyō tawā |script-title=ja:東京タワー |trans-title=Tokyo Tower}}

Tōkyō tawā 東京タワー .

Here are those same parameter values moved to their chapter equivalents:

{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower}}

"Tōkyō tawā" 東京タワー . Title.

and with a link:

{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower |chapter-url=//example.com}}

"Tōkyō tawā" 東京タワー . Title.

I wonder if the |script-chapter= value should be quoted when rendered especially in the case where the template also has |script-title= without |title=:

{{cite book/new |script-title=ja:東京タワー |script-chapter=ja:東京タワー}}

東京タワー. 東京タワー.

Still to do: include |script-chapter=value in the metadata; support |script-title= and |script-chapter= in {{cite encyclopedia}} and {{cite episode}}.

—Trappist the monk (talk) 11:37, 15 August 2015 (UTC)

Metadata support added, {{cite episode}} code tweaked which resolves this issue, and {{cite encyclopedia}} code tweaked which resolves this issue.

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

time to abandon protocol relative urls for the predefined identifiers?

There is a move afoot to replace http:// and relative protocol (//) with https: for certain urls in article space and in |url= in citations. These replacements mostly involve Google, YouTube, and Internet Archive. In September 2013, Module:Citation/CS1 converted all of the identifier urls that could be converted to relative protocol. That was a time when logged-in users used https: but users who weren't logged in used http:. Since then, Wikimedia has migrated everyone to using https:. Part of the reason for the module's switch to protocol relative urls was to prevent switching back and forth from secure (at Misplaced Pages) to not-secure (the identifier's site).

It appears that all but two of the predefined identifiers supported by the module and that use external links can be accessed using https:. The two that cannot be accessed are bibcode and LCCN. Here is a list of the identifiers with the various flavors of url:

• ARXIV :
  • http://arxiv.org/abs/0709.0674
  • https://arxiv.org/abs/0709.0674
  • //arxiv.org/abs/0709.0674
• ASIN :
  • http://www.amazon.com/dp/B00086U61Y
  • https://www.amazon.com/dp/B00086U61Y
  • //www.amazon.com/dp/B00086U61Y
• BIBCODE :
  • http://adsabs.harvard.edu/abs/2007A&A...474..653V
  • https://adsabs.harvard.edu/abs/2007A&A...474..653V – does not work
  • //adsabs.harvard.edu/abs/2007A&A...474..653V – does not work
• DOI :
  • http://dx.doi.org/10.3998/3336451.0004.203
  • https://dx.doi.org/10.3998/3336451.0004.203
  • //dx.doi.org/10.3998/3336451.0004.203
• ISSN :
  • http://www.worldcat.org/issn/0028-0836
  • https://www.worldcat.org/issn/0028-0836
  • //www.worldcat.org/issn/0028-0836
• JFM :
  • http://zbmath.org/?format=complete&q=an:54.0271.04
  • https://zbmath.org/?format=complete&q=an:54.0271.04
  • //zbmath.org/?format=complete&q=an:54.0271.04
• JSTOR :
  • http://www.jstor.org/stable/2118559
  • https://www.jstor.org/stable/2118559
  • //www.jstor.org/stable/2118559
• LCCN :
  • http://lccn.loc.gov/sn2006058112
  • https://lccn.loc.gov/sn2006058112 – does not work
  • //lccn.loc.gov/sn2006058112 – does not work
• MR :
  • http://www.ams.org/mathscinet-getitem?mr=96d:11071
  • https://www.ams.org/mathscinet-getitem?mr=96d:11071
  • //www.ams.org/mathscinet-getitem?mr=96d:11071
• OCLC :
  • http://www.worldcat.org/oclc/22239204
  • https://www.worldcat.org/oclc/22239204
  • //www.worldcat.org/oclc/22239204
• OL
  • http://openlibrary.org/authors/OL18319A
  • https://openlibrary.org/authors/OL18319A
  • //openlibrary.org/authors/OL18319A
• OSTI :
  • http://www.osti.gov/energycitations/product.biblio.jsp?osti_id=6851152
  • https://www.osti.gov/energycitations/product.biblio.jsp?osti_id=6851152
  • //www.osti.gov/energycitations/product.biblio.jsp?osti_id=6851152
• PMC :
  • http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1408034
  • https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1408034
  • //www.ncbi.nlm.nih.gov/pmc/articles/PMC1408034
• PMID :
  • http://www.ncbi.nlm.nih.gov/pubmed/12122621
  • https://www.ncbi.nlm.nih.gov/pubmed/12122621
  • //www.ncbi.nlm.nih.gov/pubmed/12122621
• RFC :
  • http://tools.ietf.org/html/rfc882
  • https://tools.ietf.org/html/rfc882
  • //tools.ietf.org/html/rfc882
• SSRN :
  • http://ssrn.com/abstract=512922
  • https://ssrn.com/abstract=512922
  • //ssrn.com/abstract=512922
• ZBL :
  • http://zbmath.org/?format=complete&q=an:0823.11029
  • https://zbmath.org/?format=complete&q=an:0823.11029
  • //zbmath.org/?format=complete&q=an:0823.11029

Is there any need to continue to support protocol relative urls for these identifiers?

—Trappist the monk (talk) 22:41, 15 August 2015 (UTC)

If everyone is using https, then protocol-relative links would use https also. Why change // to https://? It seems like another source of potential typos and errors. – Jonesey95 (talk) 00:34, 16 August 2015 (UTC)

Then for bibcode and lccn, we make sure that all links are explicitly http: - since the rest are all working in each available method, we leave these links alone. --Redrose64 (talk) 08:04, 16 August 2015 (UTC)

You can't be here (on Misplaced Pages) without your browser supports an https: connection. If the identifier sites support an https: connection (and all do except bibcode and LCCN) then there is no need for us to support the protocol relative scheme. For identifiers, editors don't have to type a url so I'm not clear on how this change would be a source of typos and errors. Can you expand on that?

—Trappist the monk (talk) 12:45, 17 August 2015 (UTC)

So the "https:" would be added by the module only for the identifiers linked above? In that case, I'm fine with that. The first sentence of this section made it sound like we were going to go around replacing "//" with "https:", which sounded unnecessary and potentially harmful.

Again, though, if it's not currently broken, I don't see why we should fix it. If it is broken in some way that I do not understand, I'll go along with it. – Jonesey95 (talk) 14:47, 17 August 2015 (UTC)

One conversation about changing http: to https: is here. We change lots of stuff that isn't 'broken' for a variety of reasons. This is just another of those.

—Trappist the monk (talk) 15:13, 17 August 2015 (UTC)

urls in |title=

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=}}

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

{{cite book/new |title=}}

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

External wikilink with leading text:

{{cite book/new |title=Leading text }}

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

External wikilink with trailing text:

{{cite book/new |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 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=}}

. {{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 =

|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=''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 = and | publisher =FamilySearch.org | | url = |accessdate = 12 March 2014 }}

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

{{cite press release |title= 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}}

" 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 | accessdate=2012-06-08}}

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

{{cite web|title=The Beverly clock|type=Abstract|journal= ]|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 web}}: External link in |title= (help); Missing or empty |url= (help)

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

<ref></ref><ref></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=}}

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

{{cite journal/new |title=Title |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= |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)

when both original and archive urls are dead

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)

ISBN error category

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)

url-wikilink conflict error category and error message change

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=

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.
• . Title. {{cite book}}: |trans-chapter= requires |chapter= or |script-chapter= (help)
• "Chapter". . {{cite book}}: |trans-title= requires |title= or |script-title= (help)
• . . {{cite book}}: |trans-chapter= requires |chapter= or |script-chapter= (help); |trans-title= requires |title= or |script-title= (help)
• "Chapter" . 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)

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

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)

|translator=

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=] |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=] |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 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)

Time of day field

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)

vancouver error tweak

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:

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

page protection applied to the suggestions list

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

Perhaps there is reason to be somewhat optimistic. I think that all of these are caught by this pattern: = '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: +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 = 'author2'. Using patterns may be a way to solve this weakness. Using this pattern: +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:

+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)

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)

• B-Class Help articles
• High-importance Help articles
• Misplaced Pages Help Project pages