Misplaced Pages

This is an old revision of this page, as edited by Carcharoth (talk | contribs) at 07:23, 16 May 2012 (→HTTP Secure for PMID: comment). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9

This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III.

To-do list for Template:Citation: edit · history · watch · refresh · Updated 2015-04-20 There are no active tasks for this page

CGNDB Discussion

I thought some page watchers might be interested in a discussion for changing CGNDB into a redirect here. Thanks! Plastikspork _―Œ

Language markup for non-English refs

Citation templates have |language=, which takes a prose value, such as "French". Shouldn't we also have a parameter or parameter which use an ISO value, such as "fr", and use that to mark up the language of the citation's title (avoiding the need to use {{Lang}}, which is often overlooked) and, where we link to an on-line source, using that value in an hHREFLANG attribute? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:34, 5 September 2011 (UTC)

Nudge. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 13:35, 31 October 2011 (UTC)

I'd support that. We'd probably need to decide whether to permit the use of the ISO 639-1, -2/B, -2/T and/or -3 codes, and whether to also include the ISO 15924 codes for the writing script. (ISO 639-1 is pretty easy to start, but maybe we should leave a path for expansion later.)

We also should think about the situation where we have a source in one language, and a quotation in another—my feeling is that's well-handled by citing the language of the source, and tagging the quoted text; if so, we'd need to explain that. Also, there's the issue of works in multiple languages; is lang-1=, etc. a good way to do that? TheFeds 05:49, 6 January 2012 (UTC)

Support. In Chinese Misplaced Pages if |language= is specified, e.g. "fr", Template:Fr icon will appear. I'll try to introduce this feature in this template.--Dingruogu (talk) 22:13, 5 March 2012 (UTC)

Basically I know how to do this now with a lot of code. To be compatible with existing usage of this template, we will have to add #switch to Template:citation/core, in which we iterate all possible language names, like "English", "Chinese", "French", etc. to show Template:En icon, Template:Zh icon and Template:Fr icon, respectively. This is much larger work load than I thought. (In Chinese Misplaced Pages, nobody used "in English" style, and thus we could use Template:Zh icon without handling compatibility issues. Compatibility issues bring the above-mentioned huge workload.)

Therefore, I would like to make sure whether others are interested in this change before I actually proceed. It will look like this after this change, no matter it's |language=en or |language=French:

Template:En icon Nowak, Ronald M. (1999). Walker's Mammals of the World, 6th edition. Johns Hopkins University Press. ISBN 0-8018-5789-9.

Template:Fr icon Spotorno, A.E., Marín, J.C., Manríquez, G., Valladares, J.P., Rico, E. and Rivas, C. (2006). "Ancient and modern steps during domestication of guinea pigs (Cavia porcellus L.)". Journal of Zoology: 060606025751032––. doi:10.1111/j.1469-7998.2006.00117.x.{{cite journal}}: CS1 maint: multiple names: authors list (link)

--Dingruogu (talk) 23:21, 5 March 2012 (UTC)

• Do we really want to give more ammunition to the "all citation templates are evil" brigade? Their main arguments concern rendering time and WP:TLIMIT. This proposal cannot improve matters. --Redrose64 (talk) 00:16, 6 March 2012 (UTC)

I prefer citation templates to plain text citation. The main reason is that I translate English Misplaced Pages articles to Chinese Misplaced Pages. I have to rewrite all the <ref> tags to make the citation style consistent, if they are not citation templates.--Dingruogu (talk) 06:52, 6 March 2012 (UTC)

Additionally, I want to make the title non-italic when |language=Chinese. It looks ugly when the title of the reference is made up of Chinese characters, e.g. here. I don't know whether it is the same with Japanese and Korean, but in Chinese we never use italics as titles. zh:WP:STYLE states this: "非中文的出版物或书名有各自的写法，最常见的是西文的斜体。请注意中文并无这些用法，所以在中文维基百科，请不要滥用斜体等非中文书名格式。这种情况在翻译西文维基的文章时容易岀现，敬请留意。"

--Dingruogu (talk) 23:21, 5 March 2012 (UTC)

I recently found {{asiantitle}}. Probably most non-Latin based character sets should not be italicized. This should be split to a separate discussion. ---— Gadget850 (Ed)  23:40, 5 March 2012 (UTC)

Thanks for pointing this out. I guess #if is not expensive and adding this needs the input from ja/kr wikipedians too. --Dingruogu (talk) 06:52, 6 March 2012 (UTC)

The Chinese Misplaced Pages markup uses #ifexist: which is an "expensive parser function" in that it consumes resources and is limited to the number of uses on a page. It only gets parsed if language is defined, but any use requires careful resource testing. You could use #switch, but that will run into a lot of markup with similar issues. ---— Gadget850 (Ed)  22:55, 5 March 2012 (UTC)

Yes we have to do this by using #switch instead of the zh-wiki approach tested in the sandbox, and that's why I mentioned there are a lot of code...--Dingruogu (talk) 06:52, 6 March 2012 (UTC)

I think you are on the wrong track here. The Chinese template calls {{language}}, which simply converts the ISO language code into the language name. I don't see the use there, especially as current uses of the language field are already the the language name. BTW, {{language}} uses #ifexist:, which doubles the expense.

The original request is for an implementation of {{lang}}, which would span text with xml:lang which would "help web browsers choose the right font, screen readers use the right pronunciation and more." The question is what text– potentially this could be the fields for title, chapter and quote. I need to do more reading, but it appears that xml:lang will not be supported whenever we switch over to HTML5, but there are other ways. ---— Gadget850 (Ed)  11:58, 6 March 2012 (UTC)

Comment I see the reference language issue as a growing problem from a copyeditor's point of view. Some people are using the language parameter and some people are using the language icon templates to specify the language of the source. Both methods are in roughly equal usage and are often intermixed within the same article. The MOS suggests the language icons should go after the link but putting it after the whole ref seems common too. I think the language field should go after the URL field as the MOS suggests. If it's technically possible (I've never really learned the details of wiki-templates so forgive my ignorance), the field should first check to see if its value is a value ISO language code, then if the text is not a template, it should still be marked-up in the same format that the language icons use. The word "in" used with the langauage field should be removed from the citation too. It's not needed. Jason Quinn (talk) 21:22, 20 March 2012 (UTC)

The "at" parameter suppressed by "page" parameter

The "at" parameter (location within a resource) can be very useful, but is suppressed when the "page" parameter is used.

E.g., {{citation |author= Smith |title= Big Book |at= Sec. 4.1 }} produces this:

> Smith, Big Book, Sec. 4.1

but {{citation |author= Smith |title= Big Book |at= Sec. 4.1 |page = 666 }} suppresses the "Sec. 4.1":

> Smith, Big Book, p. 666 {{citation}}: More than one of |at= and |page= specified (help).

({{Cite book}} does the same as {{citation}}.) Anyone know anything about this? Or any key terms to search for in the archives? If it is a bug, where should I take this? ~ J. Johnson (JJ) 21:31, 21 November 2011 (UTC)

Not a bug: it is intentional. They have similar purposes - they describe the lowest level of the place where the information was found. |at= is for use either where the book/etc. has no page numbers, or where it has some method better than pages, such as section/subsection/paragraph. If you really need to give both, use something like |at=p. 666, sec. 4.1 --Redrose64 (talk) 21:50, 21 November 2011 (UTC)

Yep. As documented. ---— Gadget850 (Ed)  22:55, 21 November 2011 (UTC)

I am curious as to why it was thought to be "a good thing" to not permit simultaneous use of both parameters. Just where is this documentation? ~ J. Johnson (JJ) 23:35, 21 November 2011 (UTC)

From Template:Citation:

at: Position within the resource when |page=/|pages= is inappropriate or insufficient. This parameter is ignored if |page=/|pages= is specified. Examples of usage of |at=: |at=para. 14 (when citing a source without page numbers), |at=02:56 (a film or audio timestamp), |at=no. 456 (something in a numbered list), |at=p. 6, col. 2 (for a page and a column because "column" is not a Citation template parameter), or |at=sec. F pp. 4–6 (for a section and a page within the section, "section" not being a parameter).

---— Gadget850 (Ed)  02:21, 22 November 2011 (UTC)

Sorry, I wasn't entirely clear. I did see that documentation, which describes what is, but does not explain if this is a bug, or a "feature". Certainly does not explain why this might be considered "a good thing", it just assumes (undocumented!) that these two parameters are exclusionary. As it is, I'd like to use both simultaneously. Is this the proper place to take that up? ~ J. Johnson (JJ) 23:27, 22 November 2011 (UTC)

The logic is if page then page, else if pages then pages, else if at then at. This conditional is in {{citation}} and in most of the Citation Style 1 templates, so it is obviously a feature. All three parameters feed into the meta-parameter |At= (notice the upper case) used by the meta-template {{citation/core}}. There is no real advantage to having three separate parameters that would be concatenated into one parameter. Indeed, we would have to add several lines of markup to deal with separators. ---— Gadget850 (Ed)  00:29, 23 November 2011 (UTC)

I see that the Citation/core documentation refers to "At" as a page reference, which I think indicates a basic problem: thinking of "at" as just another way of saying "page", an alias, and entirely substitutable. Not even for paragraph numbering, which is directly comparable to page numbering, would I say that one should preclude the other. Sections are comparable to chapters, and to have a page number suppress a chapter title would certainly be ludicrous, so why suppress sections?

Is there anything that might break if "at" was made independent of "page"? At least so both could simultaneously feed into "At"? ~ J. Johnson (JJ) 20:36, 23 November 2011 (UTC)

If they were independent, we would certainly encounter cases where the formatting of the "at" and "page" parts of a citation are in the wrong order or punctuated badly. But I think the biggest downside is that the logic in our citation templates is already comvoluted and slow, to the point where there is pressure not to use them at all, and such a change would make things worse rather than better. —David Eppstein (talk) 21:10, 23 November 2011 (UTC)

"Comvoluted" seems apt. Is the logic unnecessarily so, and ought to be re-written? Or does it merely reflect the demands made of it? I would think it fairly straightforward to simply concatenate the two fields (with the proper separator character), perhaps even reduce the ugly else-if structure. How would this make things end up in the wrong order?

To the extent these templates are slow (which seems to be the principal objection to using them), I have seen that attributed elsewhere to COINS bloat. If speed is a problem, then we ought to go after the problem (but that is a different discussion). ~ J. Johnson (JJ) 21:46, 23 November 2011 (UTC)

As Redrose64 noted earlier, you simply put both values into the |At= field}}:

{{citation |author=Smith |title=Big Book |at=Sec. 4.1, p. 666}}

Smith, Big Book, Sec. 4.1, p. 666

If you want a completely separate |at= parameter, then the change must be made in {{citation core}}. Currently, |page=, |pages= and |at= feed into |At=. I am not sure what you need that would render differently. ---— Gadget850 (Ed)  23:24, 23 November 2011 (UTC)

Yes, I got that. But I am going to be setting some things up for other editors, and everytime someone gets the bright idea of using the familiar, handy-dandy |page= parameter it will kill what ever was carefully tucked in on |at=. Which I think spells "broken" however you look at it. ~ J. Johnson (JJ) 23:53, 23 November 2011 (UTC)

So if someone adds |page=666 without noticing |at=Sec. 4.1, p. 666, then you also presume they will not notice that the citation shows p.=666, Sec. 4.1, p. 666. Sounds more like we need to add error checking for uses where |page= and |at= are defined in the citation. ---— Gadget850 (Ed)  00:17, 24 November 2011 (UTC)

In what way is this any more broken than the fact that using both |page= and |pages= in the same citation will ignore one of them? —David Eppstein (talk) 01:04, 24 November 2011 (UTC)

As a professional programmer, I can state from many years experience that "broken" doesn't mean "this doesn't do what the user wants it to do", but "this doesn't do what the specification requires it to do". --Redrose64 (talk) 17:03, 24 November 2011 (UTC)

As a former professional programmer myself, I know to distinguish between nonconformance of the s/w to the spec, and nonconformance of the spec to what the user wants. In the end it does come down to what the user (customer?) wants. (Albeit that "want" gets filtered through the specification process to minimize random changes, maintain consistency, etc.) Here I would say that the suppression of |at= is not an explicit specification, it was a likely an under-considered assumption that just fell through. And I say that upon consideration the spec should be tonot to suppress.

The distinction between "page" and "pages" is trivial, as they are the same kind of metadata, and we don't expect to have overlapping pagination domains. (That is, a given location does not have more than one page number. Aside from pdfs.) Whereas the domain of (say) sections is independent of pagination, so it is quite reasonable for a given location to have both a page number and a section number/header.

Getting back to Ed's comment, my concern is not so much where a page has already been included in an |at=, but where it has not, and someone wanting to add a page number quite reasonably reaches for |page=. Of course we hope that people preview their work, and are alert for problems, but reality often falls short. And when they do see the effect, I think the general impression is "broken". ~ J. Johnson (JJ) 22:46, 25 November 2011 (UTC)

There are a lot of things that a user can do that will bork the template and make it render in an unanticipated manner. We can add error detection for every misuse, but it would require the addition of a lot of markup. See WP:CS1PROBS for some common issues. ---— Gadget850 (Ed)  23:17, 25 November 2011 (UTC)

Why is using |at= and |page= together a "misuse" – aside from the documentation saying it is a misuse? I am saying that it is not a misuse to specify both, but quite reasonable, and the problem is where the one suppresses the other. I think it would be easier to concatenate them then to tell the user he can't use them both. As to the "common problems" you point to: as the only ones applicable here are generic problems, I would hope there is a generic function for checking them. Which is invoked with a single call, not "a lot of markup". Alternately, since "At" presumably does the same checking regardless of whether it has "at" data or "page" data', why would there be a problem when it contains the concatenated data of both? ~ J. Johnson (JJ) 18:37, 26 November 2011 (UTC)

It is a misuse precisely because it contradicts both the documentation and the current implementation. It's reasonable to request, as you have done, that the template be changed, and I think it's also reasonable to oppose the change. But don't pretend that the current behavior is a bug. It's not, it's a feature. It may or may not be a good design, but it is currently performing exactly as designed. —David Eppstein (talk) 18:56, 26 November 2011 (UTC)

Let me rephrase my earlier question. Do you want:

• |At={{{pages|}}}}}}|{{{page|{{{pages|}}}}}}, {{{at|}}}

Or;

• |Pages={{{pages|}}}}}}|{{{page|{{{pages|}}}}}}
• |At={{{at|}}}

---— Gadget850 (Ed)  19:41, 26 November 2011 (UTC)

I can't say as to which, as I don't understand the code well enough to be certain of what either snippet does. (Or how |Pages= and |At= are subsequently processed.) What I think would be reasonable (and what most editors would expect) is, given the example above, a result like "Smith, Big Book, Sec. 4.1, p. 666". ~ J. Johnson (JJ) 20:48, 27 November 2011 (UTC)

To me it seems likely that, about equally often, editors would want the "at" part after the page numbers, not before. And if they do want it before, where does it go when the citation is in the journal volume:pages format? To me this ambiguity seems another good reason for forcing the editors to specify themselves how to combine the at and page information in a single parameter (as it works now) rather than letting the template decide for them and getting it wrong half the time. —David Eppstein (talk) 20:56, 27 November 2011 (UTC)

David, your argument is circular. You're saying that the documentation correctly describes what the code does, and the code correctly does what the documenation describes – including what happens when both parameters are used – and therefore all is correct. But that is only internal consistency, nothing more. How can you say that using both parameters (and expecting a different results) is a misuse? How can you call this behavior a feature, when it contradicts a reasonable expectation? Where is the specification that requires this suppression? ~ J. Johnson (JJ) 21:54, 27 November 2011 (UTC)

(jumping in from the sidelines) Specification? what specification? We don't need no stiiiiiinking specification!!! Take that as an attempt to lighten things up a bit, please, though it does characterize the template development process with some accuracy.

The behavior at issue seems to have been instituted in October of 2007 here and here by User:COGDEN. I don't know how much prior discussion there was about that, or where the discussion might have taken place.

Personally, I think a change to the requirements spec (if there were such a thing) for this template to allow this might be a good idea. I've sandboxed a first-cut implementation as a possible aid to this discussion. I have not sandboxed an update to the documentation. If such a change is made, corresponding changes should probably be made in the {{cite xxx}} templates. I would urge asking COGDEN for his views on this before going live with changes. One concern would be the question of how many existing articles such a change would break. I suspect that it would not break many, but it might break some.

Actually, the sandboxed change was something like a tenth-cut implementation by the time I got it working. I think the template coding language ought to be named LISB (maybe LISBon) following on custom established by similar namings re parentheses in LISP. Wtmitchell (talk) (earlier Boracay Bill) 02:45, 28 November 2011 (UTC)

I guess Help:Citation Style 1 is a back specification since it was written after the templates were implemented. ---— Gadget850 (Ed)  03:33, 28 November 2011 (UTC)

Thanks for digging out the diffs, and yes on all points. On the prospect that this might go in, and being duly prudent re possible breakage: is there any idea of how many instances there are of {{citation}} or {tl|cite xxx}} using both parameters? ~ J. Johnson (JJ) 23:12, 28 November 2011 (UTC)

We would have to add detection and tracking categories toe each individual template. ---— Gadget850 (Ed)  23:45, 28 November 2011 (UTC)---— Gadget850 (Ed)  23:45, 28 November 2011 (UTC)

Why? (Note that my previous question concerns existing instances, for which I presume some kind of dump could be searched, not to track future usage, for which I see no point.) ~ J. Johnson (JJ) 21:14, 29 November 2011 (UTC)

break

Again, is there any way of (say) scanning the WP corpus to see where |at= is used in citation/cite templates? ~ J. Johnson (JJ) (talk) 00:46, 7 December 2011 (UTC)

This is a list of the 137 citations on en-wiki mainspace from the January 2012 database dump using both |at= and |page=. There are none using both |at= and |pages=, and 4707 using just |at=. Rjwilmsi 21:05, 31 January 2012 (UTC)

Looks like a few legitimate types of use and a lot of confusion confusion with location or website. ---— Gadget850 (Ed)  22:59, 31 January 2012 (UTC)

Thanks for doing that. My first impression of the list was: where are all the maps I've cited using "|at="? But of course, I generally use citation templates as a "full reference", without the specific page/paragraph/section/etc. specification. (I put those in with the Harv link.) Nonetheless, some of the uses I have made of |at= might be of interest:

• at = 1 sheet, scale 1:250,000, with 15 p. text
• at = Project Award Number 07HQGR0088

What this reminds me is that I have found "at" to be useful as a sort of miscellaneous parameter for data not readily accommodated in other parameters, much like many of the examples seen in the list. While I would agree that some of those uses seem inappropriate, yet the need for such a miscellaneous field seems evident, and "at" suffices. In this regard the data is not similar to "page" (etc.), and so I think one should not be suppressed in favor of the other.

That "at" (in the sense of "@") is so variously used does make me wonder if handling the various subdivisions smaller than chapters (sections, paragraphs, stanzas, etc.) should have a more specific parameter. Perhaps "section", or some such. ~ J. Johnson (JJ) (talk) 01:02, 1 February 2012 (UTC)

I think that |at=1 sheet, scale 1:250,000, with 15 p. text is misuse of the parameter. Since |pages= is not for the total number of pages in the book, it follows that the number of sheets or pages (in an atlas?) is also irrelevant. This leaves the scale, which is important for a map, but would be better placed in the edition, for example |edition=1:50 000 first series for the Ordnance Survey maps of the mid-1970s. Regarding |at=Project Award Number 07HQGR0088, this seems trivial: but if 07HQGR0088 is some sort of unique identifier, this would be better placed in the |id= parameter. --Redrose64 (talk) 12:39, 1 February 2012 (UTC)

 The "Project Award Number" is a unique identifier, and I can't remember why I didn't use "id" for it. I'll have to check on that.

 I would take issue with you re |pages=, but that is irrelevant here: the number of sheets (plates) and amount of text (pages) is considered key descriptive detail in regard of maps. I can see an argument that description is not the same as location within ("at"), but |id= seems limited to unique identifiers, and I don't see what other parameters would best handle such data. I think part of my preferred usage here stems from not liking the format that results from using other combinations of parameters.

 It seems to me that |at= is being used as the generic descriptive field. Though I certainly agree many of those uses are inappropriate. ~ J. Johnson (JJ) (talk) 20:45, 8 February 2012 (UTC)

{{Citation}} used with no parameters

How easy would it be to add an error message or category when {{Citation}} is used with no parameters as here? The editor clearly meant {{Citation needed}}. I've seen this a few times now. -- John of Reading (talk) 12:42, 25 January 2012 (UTC)

Title should be mandatory— it would be fairly easy to add a check and show an error. I can look at this in a bit. ---— Gadget850 (Ed)  12:49, 25 January 2012 (UTC)

It would be probably wise to make {{citation}} with no arguments (or only "date" argument) render exactly as {{citation needed}} and to phase out {{citation needed}} at all. Probably same features should be implemented for WP:CS1 and other citation templates. — Dmitrij D. Czarkoff (talk) 15:08, 25 January 2012 (UTC)

I'm not sure we want to conflate two templates with opposite purposes like that. It's probably better just to show an error. Regards, RJH (talk) 15:42, 25 January 2012 (UTC)

And these templates are already eat enough resources. ---— Gadget850 (Ed)  16:01, 25 January 2012 (UTC)

I've got round to doing a database scan. There are 459 mainspace articles that match \{\{ *it *\}\} so I guess I could switch them all to {{Citation needed|date=March 2012}} without too much hassle. Or is that too many to do without a bot approval? -- John of Reading (talk) 13:45, 6 March 2012 (UTC)

Display of long doi.

I have noticed various instances (including this) where a long doi in a double-column format doesn't wrap, and extends into the adjoining column. Is there any way of dealing with this? (The only mention I have found, at TT::Citation/Archive_1#Problem_with_longer_DOI, doesn't address this.) ~ J. Johnson (JJ) (talk) 20:45, 18 February 2012 (UTC)

Looks OK in Firefox 10; since you see columns, you aren't using IE9 or below. ---— Gadget850 (Ed)  22:08, 18 February 2012 (UTC)

Looks OK in Firefox 3.6.27 too --Redrose64 (talk) 22:36, 18 February 2012 (UTC)

Oh. So likely my Firefox 3.0.6 is just a few minor revisions behind curve, eh? Thanks for checking. One more item for the to-do list. ~ J. Johnson (JJ) (talk)

At present, Mozilla are pushing Firefox 10.0.2; but if you don't want to go that far the only "older" version that they still offer is 3.6.27 (released 17 February 2012), see here. Bear in mind that 3.6.x development may well cease soon. --Redrose64 (talk) 18:51, 19 February 2012 (UTC)

Minor author-link problem

Corbett, Richard; Jacobs, Francis; Shackleton, Michael, {{citation}}: Check |author2-link= value (help); External link in |author2-link= (help); Missing or empty |title= (help)

That partial citation in European Union#Literature produces the "|" and extra brackets in Jacobs; but seems to my novice eye to be done correctly. Any thoughts? Thanks. I'll check back. Swliv (talk) 19:26, 27 February 2012 (UTC)

The use of an URL in |authorlink= will break the link; this field is for the name of the Misplaced Pages article about the author, not a website. ---— Gadget850 (Ed)  19:32, 27 February 2012 (UTC)

Thanks. I guess I'm inclined to leave it despite the slight awkwardness of the look. Swliv (talk) 03:03, 28 February 2012 (UTC)

The link seems to be dead. A working archived copy is http://web.archive.org/web/20071015122553/http://europarl.ie/about.html. Wtmitchell (talk) (earlier Boracay Bill) 03:28, 28 February 2012 (UTC)

Don't worry, some helpful editor will notice the problem and fix it. ---— Gadget850 (Ed)  09:26, 29 February 2012 (UTC)

Bug in Template:Citation/identifier handling of OL works

The OL identifier is incorrectly presumed to refer to a specific edition. OL ids that end in W refer to works, at urls of the form (http://openlibrary.org/works/OL237370W). Such links are appropriate where the specific edition sourced is uncertain and often are helpful in finding an online-accessible edition in lieu of a similar less-accessible one. LeadSongDog come howl! 04:08, 29 February 2012 (UTC)

What needs to be don here? ---— Gadget850 (Ed)  22:58, 5 March 2012 (UTC)

OL IDs end in either W or M. Those ending in M are presently handled correctly, with the url for a specific edition, such as the link to http://openlibrary.org/books/OL14030155M for |ol=14030155M. Those ending in W refer to a work, which at OL refers to one or more editions, such as http://openlibrary.org/works/OL237370W for |ol=237370W. So the template should check to see if the value of |ol= ends in M or W, then use a different url in each case. Right now it treats both as if they ended in M. LeadSongDog come howl! 14:53, 6 March 2012 (UTC)

I see the issue. {{str endswith}} looks useful. Let me look at this later. What if the OL does not end with W or M?---— Gadget850 (Ed)  16:27, 6 March 2012 (UTC)

So far as I can tell the only other valid option is "A", which would map OL2548361A to http://openlibrary.org/authors/OL2548361A. While I don't forsee this being used much, it's at least a theoretical possibility that an editor might cite only the author name without the title.LeadSongDog come howl! 21:27, 6 March 2012 (UTC)

There's nothing wrong with how the template works. Identifiers should be used to identify what you actually cited, hence M (more or less the equivalent of an ISBN), and not W (more or less the equivalent of an ISSN). Headbomb {talk / contribs / physics / books} 17:39, 6 March 2012 (UTC)

Do you mean that W should go 404 or it should not be used? ---— Gadget850 (Ed)  18:04, 6 March 2012 (UTC)

That it should not be used (as an identifier). Headbomb {talk / contribs / physics / books} 18:17, 6 March 2012 (UTC)

Did you read the first line of this section: "where the specific edition sourced is uncertain..."? It is quite common for editors to provide only an author and title when citing, without bothering to give a year, publisher, etc. For citegnomes coming along after the fact, the next step is to more fully identify the work. It would be false precision were I to insert the "M" identifier for an edition without actually seeing it, but the "W" identifier is still valid. Having gotten that far, a subsequent editor can find a specific edition to check if it supports the in-text assertion and if so, can then cite that more specific edition, adding page number, publisher, and date. Incremental improvement is still improvement. LeadSongDog come howl! 21:09, 6 March 2012 (UTC)

And these people can still give a link to that page with |url=. Personally, I don't see the point, but I supposed some fancy-pants logic could be used for the 3-4 cases where that could happen for some weird reason. Whatever happens here should be synced with {{OL}}. Headbomb {talk / contribs / physics / books} 21:17, 6 March 2012 (UTC)

Looking at {{OL}}, it detects whether the id ends with A, M or W. The doc page needs some updating. ---— Gadget850 (Ed)  21:33, 6 March 2012 (UTC)

Ah: just checked the history. ---— Gadget850 (Ed)  21:53, 6 March 2012 (UTC)

Add doi-check

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

If an admin could put {{citation/identifier/sandbox}} (this revision) into {{citation/identifier}}, that would be peachy. What it does is check if the DOI starts with '10.Foobar'. If not, it throws an error message and populates Category:Pages with DOI errors. It's tested and everything. Headbomb {talk / contribs / physics / books} 19:05, 6 March 2012 (UTC)

 Done --Redrose64 (talk) 19:40, 6 March 2012 (UTC)

A new solution needs to be found for the "2001a" problem

The section "IDs must be unique" provides a sloppy kluge for getting around the problem of duplicate Harvard reference link-target anchor IDs, which arises when two sources share the same author and year. This needs to be fixed with a parameter, like |harvletter= or something, so that the letter is appended the year only for linking purposes, and is not actually appended to year data as the year data; doing so falsifies and invalidates that data. There is no such year as "2001a", and because automated systems we cannot predict can and will re-use WP content in ways we cannot predict, we have a responsibility to get this right. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 20:26, 17 March 2012 (UTC)

Let's say that you're using Shortened footnotes. The inline template might be {{sfn|Doe|2012|p=12}}, which links to a {{cite book|last=Doe|first=John|title=A Book of Stuff|year=2012|ref=harv}} (or, if you prefer, to {{citation|last=Doe|first=John|title=A Book of Stuff|year=2012}}). Then the same guy writes a different book in the same year which is also useful in the article. How should the short notes distinguish? --Redrose64 (talk) 21:02, 17 March 2012 (UTC)

Using "2001a" etc is not solely for the purpose of making link-target anchors. It's also necessary as a way of unambiguously identifying references to human readers. —David Eppstein (talk) 21:09, 17 March 2012 (UTC)

Yeah, I know. I've used the |year=2012a technique several times myself and it works just fine. I'm just a bit pissed off because I know we've gone through this several times before. It must be in the archives but I just can't be arsed to look. --Redrose64 (talk) 21:57, 17 March 2012 (UTC)

It also has to work for printed versions. The use of year suffixes is used by most style author-date style guides. ---— Gadget850 (Ed)  22:17, 17 March 2012 (UTC)

I hate the whole appended digit idea; I use {{sfnRef}} to make a name that's unique. See Ernest Shackleton (2×Shackleton 1919), Amundsen's South Pole expedition (2×Huntford 1985), and Richard Nixon (8×Nixon Library) for examples. Others out there, too. SMcCandlish is very right about the falsified data aspect of this. Alarbus (talk) 06:47, 18 March 2012 (UTC)

Looking at those articles, you are using author-title, author-title-year and work-title. This may be even more tortured than the alpha suffix method.

• Shackleton, South (film).
• Shackleton, South
• Huntford (The Last Place on Earth) 1985
• Huntford (Shackleton) 1985
• Nixon Library, Post Presidency
• Nixon Library, President
• Nixon Library, Childhood
• Nixon Library, Vice President

The alpha suffix is a well used method:

• "Two or more works by the same author in the same year must be differentiated by the addition of a, b, and so forth (regardless of whether they were authored, edited, compiled, or translated), and are listed alphabetically by title." CMOS 16 15.19

• "Place lowercase letters—a, b, c, so forth—immediately after the year, withing the parentheses:" APA 6 p. 162 OWL

It would be technically possible to add something like |datesuffix= to the templates that would use the label to create the links but would not display it, unless printed. ---— Gadget850 (Ed)  13:43, 18 March 2012 (UTC)

Those formats are commonly used as plaintext, I'm just {sfn}'ing them up. I know the alpha suffix is well used in print, but we're not paper and all that; we're a website, a datebase. Links/anchors need to be unique and we should not be hiding things except for print; people need to be able to sort things out simply by reading off the screen. And actually adding the alpha character into the year parameter amounts to database corruption. Alarbus (talk) 19:10, 18 March 2012 (UTC)

The citation templates already hide the URL except in print. The proposal I made above would separate the suffix from the date: it would only be used when the anchor is created and in print. ---— Gadget850 (Ed)  19:22, 18 March 2012 (UTC)

I do think that separating suffixes from years is needful when they're used. My point was that a reader simply viewing the article (or listening with a screen reader) needs to be able to figure out which "2000" is meant; it's not enough that two links target different sources. The distinction has to be apparent without clicking (which is very useful and the whole linking helps verifiability). I'm glad url are printed. Not displaying them on screen is an internet-wide practise and some are insanely long. Alarbus (talk) 20:07, 18 March 2012 (UTC)

  I think you all are straining too hard on this. A couple of points. First, SM is right (also Alarbus) in that "2001a" is not a year (date). I reckon any such value in |year= (or |date=) as corrupt data, and I strongly urge against any such perversions. However (second point), in the link (e.g., "Smith 2001a") used to connect the short reference to the full reference this is not a problem, because that tag is not a date field. It is a composite (of author+year+suffix) which conveniently incorporates the year, but that tag is not intended as a date. (If it is parsed for year, then the suffix can be parsed as readily as author.)

  As to the question of how to get {{citation}} to build a suitable anchor for something like {{Harv|Smith|2001a}}, I find it handy to specify the ref link explicitly with "ref=CITEREFSmith2001a". We get the properly suffixed year in the link, but not in the full reference, nor is the metadata corrupted. I've been doing this for a while, and it works fine. ~ J. Johnson (JJ) (talk) 21:07, 18 March 2012 (UTC)

Pretty much right. I don't think anyone is objecting to a digit or whatever else in the link-text or #anchor (although I do prefer the other routes, above). It's the corrupt year field that's got to be cleaned-up, and there must be many hundreds of thousands out there. You should avoid the "ref=CITEREFSmith2001a" approach, though; see {{sfnRef}} or its redirect {{harvid}}; its job is to do exactly that without having to glue the encoding into each citation (which may want to change someday (see Encapsulation). {sfnRef} is building more complex forms of ref=CITEREF..." in the above examples. Alarbus (talk) 21:31, 18 March 2012 (UTC)

(edit conflict) There is a template specifically for that purpose. In the {{citation}} you would put |ref={{harvid|Smith|2001a}} which generates |ref=CITEREFSmith2001a. You don't need to remember any new syntax - {{harvid}} takes the same positional parameters as {{harv}}, it just lacks the named params like |p=. --Redrose64 (talk) 21:35, 18 March 2012 (UTC)

  Why should direct coding of the citeref be avoided? Sure, perhaps the citation will get changed someday, but how does that change an explicit "ref="? I don't see what is saved in adding another layer of templating. ~ J. Johnson (JJ) (talk) 23:55, 18 March 2012 (UTC)

The scheme of encoding might change; this thread is an example of the sort of issue that might benefit from that (or not), and glueing the scheme into a huge number of spots is limiting. See the article I linked for the concept: Encapsulation (object-oriented programming). The {{sfnRef}} template is friendlier and familiar and provides a means of encapsulating the encoding. It should be used. Someone should put a bot on the task of fixing embedded encoding instances. Alarbus (talk) 01:07, 19 March 2012 (UTC)

  Look, I understand encapsulation (and that article was not relevant to my question), and if a datum needs to be processed I quite understand running it through a standard "object" rather than coding the processing in every instance. But what is the benefit of "|ref={{harvid|Smith|2001a}}" over the hardcoded "|ref=CITEREFSmith2001a"? I don't believe the link-tag needs processing. (Alternately: should each component be processed with something like "|ref=CITEREF{{author-check|Smith}}{{year-check|2001}}{suffix|a}}"?) ~ J. Johnson (JJ) (talk) 22:18, 19 March 2012 (UTC)

If the method used by {{harv}} (and related templates) to generate the link changes (it's happened as recently as February 2011), amending a few templates is much easier than going through every single page. --Redrose64 (talk) 23:53, 19 March 2012 (UTC)

Exactly; explicitly encoding within articles should be strong discouraged for this reason. JJ, my meaning was that the encoding is encapsulated by the template; please use it. Alarbus (talk) 03:21, 20 March 2012 (UTC)

Yes this is a horrible kludge. There is however a ref field of some sort, and when I recommended dumping the year field some time ago, that was a good place to put a solution. At the time there were virtually no uses of a year with a letter, and not that many of the year parameter. Unfortunately my suggestion to deprecate "year" entirely (since we have a "date" field) resulted in AWB being modified to change all year-only dates to "year" fields. Never did figure why that was a good thing. Rich Farmbrough, 02:30, 20 March 2012 (UTC).

The CS1 templates extract the year from |date= using #time. If the date is a single number, it can be interpreted as a time and not properly parsed when creating the anchor. Examples:

• last (2001). {{cite book}}: Invalid |ref=harv (help); Missing or empty |title= (help) anchor = CITEREFlast2001; correct
• last (916). {{cite book}}: Invalid |ref=harv (help); Missing or empty |title= (help) anchor = CITEREFlast; wrong

The markup is in each CS1 template, not core. Perhaps we should look at fixing this. ---— Gadget850 (Ed)  03:03, 20 March 2012 (UTC)

By a relatively strange coincidence I just read up on a related PHP issue in one of the archives. This certainly bears some thought. Rich Farmbrough, 16:40, 21 March 2012 (UTC).

'Cite newspaper The Times' and 'Cite wikisource'

Would someone following this page be willing to have a look at the question I've raised here about citing The Times Digital Archive? I'm trying to work out the best way to cite this wikisource obituary from The Times. I could use Template:Cite wikisource, but as I also have access to The Times Digital Archive, I could use that as well. I would prefer to cite direct to The Times Digital Archive, as the wikisource page appears to have been typed freehand, not verified from a page scan, but possibly including the wikisource page as a courtesy link, though I realise that might be too convoluted. Carcharoth (talk) 13:18, 18 March 2012 (UTC)

My view is, just cite it to The Times in the usual way. No need to mention the Times Digital Archive. Since there happens to be a copy of the article at Wikisource, there is no harm in giving the URL of that as a courtesy link; obviously not necessary but at any rate more useful, I think, than giving the URL of the Times Digital Archive, since most readers won't have access to that, and those who do (e.g. me with my local library card) will probably be aware of the fact already and will know how to look it up there if they wish. -- Alarics (talk) 14:29, 18 March 2012 (UTC)

See {T} New York Times Misplaced Pages reference generator.Moxy (talk) 14:43, 20 March 2012 (UTC)

translator(s)

There are plenty of texts which are translations, the translators of which are as important as the original author. My specific case in point was ISBN 9780195147339 - authored by Tsongkhapa - but translated by Garfield and Samten who are very well known in their field. (20040302 (talk) 11:10, 20 March 2012 (UTC))

This is one of the uses of the |others= parameter. Use |others=trans. Garfield, Jay L. and Samten, Ngawang or similar. --Redrose64 (talk) 13:20, 20 March 2012 (UTC)

I opted to include them as authors in an authors list, with (tr.) after their lastnames. They have positively contributed to the text, with many interpretations and much commentary; so much so that quite some of their work can be identified as secondary sources. I don't really like the idea of 'others' either. IMO it's a catch-all kludge. Anyhow, I'm not going to push for translators being added to the template, though I still consider it a good idea and far more relevant than some existing parameters. (20040302 (talk)) —Preceding undated comment added 14:41, 20 March 2012‎.

The "url" parameter

Discussion about changing Template:Citation/core so that the URL given with |url= won't slip to chapter is happening at Template talk:Citation/core#The "url" parameter. — Dmitrij D. Czarkoff (talk) 00:01, 21 March 2012 (UTC)

Usage of 'Publisher', 'work', 'agency' parameters in 'cite' templates; possible bot to fix

These parameters are frequently wrongly used; for example, "publisher=''The Times''" should be "work=The Times". A related complication is that the name of the work wrongly declared as 'publisher' is sometimes included in double apostrophes so that it shows italicised (as 'work' automatically does). Also, agencies such as Reuters are sometimes described as 'publisher' where they should be 'agency'. I've developed a set of regexes that (mostly) fix these problems while I'm doing other gnoming, but the scale of the problem is large enough that only a bot could really sort it out. Here's what I propose the bot should do.

• publisher = (list of agencies) --> agency=agency
• publisher = (list of common newspapers, magazines and journals) --> work = publication
• publisher = ''(list of common publishers)'' ---> publisher = publisher

Any comments?

In a related question, I see BBC and its variations such as BBC Sport, BBC News, as a publisher; at least one other editor feels that they belong under the work= parameter. (See User_talk:Rjwilmsi#Possible_Cite_template_parameter_cleanup_bot.) Any thoughts on that? Colonies Chris (talk) 09:40, 1 April 2012 (UTC)

I fall on the side of work = BBC News. The publisher is the BBC, the work is BBC News, BBC Sport etc. But, having put the work in, the publisher is unneeded in this case. Mr Stephen (talk) 10:57, 1 April 2012 (UTC)

My feeling is that an individual sports or news programme, if relevant, would be the 'work', and BBC Sport or BBC News would be the publisher of that work. In most cases, the reference isn't to a specific programme though, so there would be no 'work', just the publisher. Colonies Chris (talk) 22:51, 1 April 2012 (UTC)

I entirely agree with Mr Stephen. The existence of the "publisher" parameter in "cite news" is actually a tremendous nuisance, because so many editors think it means the name of the publication. In reality it is not required at all in the case of most news citations -- mainstream newspapers, BBC News, etc.

I agree that the publisher is entirely unnecessary when the publication is well known, and I generally remove that parameter. If this is an uncontroversial change, I will propose it for the bot. Colonies Chris (talk) 22:51, 1 April 2012 (UTC)

My preference is for "BBC News" but quite a lot of refs still say "BBC News Online" which is what the BBC website used to call itself. I think it should at least be consistent within any one article.

I very much look forward to the bot proposed by Colonies Chris. It should save me an enormous amount of time. -- Alarics (talk) 14:29, 1 April 2012 (UTC)

A newspaper is not a work (as in "work=The Times"), but a serial. A "work" is usually a complete bit of work, published as a single unit, with definite authorship. In regard of newspapers, magazines, journals, encyclopedias, etc., I don't see that "work" is appropriate, and would urge that |work= not be introduced into the corresponding {{cite xxx}} templates. ~ J. Johnson (JJ) (talk) 22:23, 1 April 2012 (UTC)

Fair enough, but your point is moot as "journal", "periodical", "newspaper", "magazine", and "work" are treated identically by the template. Mr Stephen (talk) 22:28, 1 April 2012 (UTC)

Yes - I'm not proposing to add a 'work' parameter to the cite templates - it's already there and is is extensively used, normally for periodicals and encyclopaedias. (That's why the template automatically italicises the 'work' value, in line with WP style for periodicals etc.) It would be possible to convert the incorrrect 'publisher' values I mentioned to use a parameter more specific than 'work' (such as 'newspaper', 'magazine' etc - would there be any benefit to that, given that the template treats them all the same anyway? Colonies Chris (talk) 22:51, 1 April 2012 (UTC)

In "cite news", I generally put "work" for newspapers and magazines and news websites because it covers all of them (and is only 4 characters to type) and produces the same result. I don't see the point in distinguishing between these different kinds of news source, especially when the output result for the reader is identical (most notably, it comes out in italics, which is what we want for all these things). What we really means is "news source" but that is not an available parameter at present. On balance, since the "work" parameter is already there, I am inclined to leave it like that and use the nice short "work" even if strictly speaking BBC News (etc.)is not a work. I should be quite happy to see the proposed bot simply convert the incorrect "publisher" values to just "work", or alternatively somebody creates a new parameter called "source".

BTW just to clarify an apparent misunderstanding above, when I talk about "BBC News" here I mean the website of that name (http://www.bbc.co.uk/news). I am not talking about radio and TV programmes which are not news and for which I see from WP:CITET we are supposed to use "cite episode". -- Alarics (talk) 06:22, 2 April 2012 (UTC)

I'm very surprised by this predominant opinion that sources such as BBC News should be considered a 'work'. I can say from my gnoming experience that it's substantially at odds with actual practice: overwhelmingly, physical media - periodicals and books and encyclopaedias - are parameterised as 'work', and websites are given under 'publisher', even when it's a website directly associated with a physical periodical. I've just checked with the MoS, and I see that it does indeed recommend that news websites should be italicised (i.e. treated as a 'work'). This came as news to me and also, I suspect, to most editors. A bot could help fix this, but perhaps the documentation of the 'cite' parameters in this area needs some review too - clearly the message isn't getting through. Colonies Chris (talk) 13:33, 2 April 2012 (UTC)

As I understand it, the thinking is that the fact of its being a news source (or perhaps more accurately "a piece of journalism" which may be either hard news or a feature article) is more important than whether it takes the form of print or digital or (increasingly nowadays) both. This makes sense to me. When it is exactly the same sort of journalism, why treat it differently according to what technical form the material happens to take? Of course we still keep "cite web" and its parameter "publisher" for stuff found on websites that are not news media.

Another thing not all editors have grasped, while we are on the subject, is that a press release, though conveying "news" (or what purports to be news), is "cite press release" and not "cite news" because it comes from an organisation talking about itself, not from a, we hope, more or less objective news source. Of course in this case "publisher" is the right parameter to use for the name of the company or organisation issuing it. -- Alarics (talk) 14:36, 2 April 2012 (UTC)

postscript doc

What does this mean: "Punctuation specified by this parameter will appear within the cite span, and consequently before any icons added by metadata-using software, e.g. library browser plugins. Hence this parameter should be used instead of manually appending data to the citation."

I don't understand the allusions to icons or plugins. ---— Gadget850 (Ed)  10:08, 5 April 2012 (UTC)

Sorry, where did you take this phrase from? I see two explanation of |postscript= in this template's doc, but neither of them matches this phrase. — Dmitrij D. Czarkoff (talk) 14:03, 5 April 2012 (UTC)

About your question: some plugins insert icons after citation templates. In case when some text was manually added after this template, the icon will show up between the citation and added text, so it is proposed to add text to |postscript= in order to avoid the icon insertion in the middle. Or did I misunderstand the question? — Dmitrij D. Czarkoff (talk) 14:07, 5 April 2012 (UTC)

The second explanation contains the text and is the original. I am doing a documentation update, but I have never seen this in the description for the parameter. What plugins? What data would be manually added using postscript? The only additions I can think of are {{subscription required}}, {{registration required}} and {{retracted}}, but these go after the template. ---— Gadget850 (Ed)  15:11, 5 April 2012 (UTC)

The plugins may be whatever referencing tools. I don't use those.

Say we have a plugin that adds an icon after citation (don't ask me what's that for):

Code	Rednering with plugin
{{citation |url=http://example.com |title=Example }} {{subscription required}}	Example (subscription required)
{{citation |url=http://example.com |title=Example |postscript= {{subscription required}} }}	Example (subscription required){{citation}}: CS1 maint: postscript (link)

So the integrity of citation isn't lost. There may be some other cases like "as cited by ". — Dmitrij D. Czarkoff (talk) 15:22, 5 April 2012 (UTC)

That is really stretching postscript. If we really want to do that, we should have an addon parameter. ---— Gadget850 (Ed)  16:11, 5 April 2012 (UTC)

Upon reflection, all of that markup now pollutes the citation span:

{{Source}} is deprecated. Please use a more specific template. See the documentation for a list of suggested templates. ---— Gadget850 (Ed)  17:07, 5 April 2012 (UTC)

I didn't get the pollution part. The same amount of markup, but the second is semantically clearer, though goes against the idea behind |postscript=. So I would ask you again: where did you get the text you quoted in initial comment of this thread? — Dmitrij D. Czarkoff (talk) 19:05, 5 April 2012 (UTC)

From http://en.wikipedia.org/search/?title=Template:Citation/doc&oldid=485575188#Full_citation_parameters ---— Gadget850 (Ed)  20:16, 5 April 2012 (UTC)

Press release

The example given at Template:Citation#Press release used the "cite" family template {{Cite press release}} rather than this template. I've changed it. Peter coxhead (talk) 07:59, 16 April 2012 (UTC)

HTTP Secure for PMID

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

In Template:Citation/identifier, please someone replace

|pmid={{hide in print |] 

with a HTTP Secure link, i.e.:

|pmid={{hide in print |] 

That's all. Thanks. bender235 (talk) 16:15, 24 April 2012 (UTC)

 Done; please let me know ASAP if this is problematic in practice. Chris Cunningham (user:thumperward) (talk) 20:09, 24 April 2012 (UTC)

Thanks. Works perfectly. We could also think about changing the PMC identifier link, too. Since e.g. redirects to anyway (but HTTP Secure does not work with redirects), we could also replace

|pmc={{hide in print |]  }}

with

|pmc={{hide in print |]  }}

Should work just as well, and provides HTTPS comfort. --bender235 (talk) 21:38, 24 April 2012 (UTC)

 Done, but please check as there was a whitespace change and I don't want to have accidentally missed some brackets. Chris Cunningham (user:thumperward) (talk) 09:09, 25 April 2012 (UTC)

Could you explain why this is worthwhile please? It adds a lock symbol after each PMID value and if https connections are more resource intensive and Misplaced Pages sends appreciable traffic to the NLM may not be a friendly act. RDBrown (talk) 13:22, 25 April 2012 (UTC)

I already added a link explaining the advantages of HTTP Secure. You're right, HTTPS has slightly higher latency, because browser and server have to perform a Diffie–Hellman key exchange at the beginning of each session, but today this is minimal, basically negligible. --bender235 (talk) 15:31, 25 April 2012 (UTC)

• It would probably be preferable if the protocol (http or https) matched what the user is currently using to access Misplaced Pages, so – . —  HELLKNOWZ  ▎TALK 13:36, 25 April 2012 (UTC)

Why not send users to a secure source, regardless of which protocol they accessed Misplaced Pages with in the first place? I fail to see any drawbacks that come with using HTTPS. --bender235 (talk) 15:31, 25 April 2012 (UTC)

Matching how they accessed would be good. With Results 1–20 of 55,952 for PMID, Results 1–20 of 29,995 for PMC, I'm more concerned about Slashdot effects on the PubMed servers, since I've seen load related effects using the template filler. If wiki sends enough traffic their way, they may want their say. RDBrown (talk) 23:23, 25 April 2012 (UTC)

The difference between HTTP and HTTPS traffic is absolutely minimal. You're exaggerating this issue. And PubMed is offering HTTPS service, why not use it? YouTube offers it, too, and Template:YouTube links to HTTPS. --bender235 (talk) 00:39, 26 April 2012 (UTC)

Nothing wrong with using it. Making it mandatory is another matter. For users behind institutional firewalls that block all https, you've denied them access for no good reason.LeadSongDog come howl! 03:29, 26 April 2012 (UTC)

I've yet to see any non-theoretical pushback on this sort of thing, but if there's evidence that we do actually have readers that are inconvenienced I'll be happy to back this out. Chris Cunningham (user:thumperward) (talk) 07:10, 26 April 2012 (UTC)

The changes broke PMC. I copied the changed markup to the sandbox and reverted the PMC changes:

{{citation/identifier |identifier=pmc |input1=1408034}}

{{citation/identifier/sandbox |identifier=pmc |input1=1408034}}

---— Gadget850 (Ed)  14:30, 30 April 2012 (UTC)

Any idea why it doesn't work? --bender235 (talk) 14:06, 30 April 2012 (UTC)

 Fixed An = needed to be escaped. ---— Gadget850 (Ed)  14:30, 30 April 2012 (UTC)

What is ?tool=pmcentrez in the PMC URL? It does not seem to be needed. It is not used in {{PMC}} (which should be updated to match). ---— Gadget850 (Ed)  16:25, 30 April 2012 (UTC)

I believe it is part of legacy article renderer at pmc. any thoughts about my concerns below? 70.137.148.196 (talk) 16:38, 30 April 2012 (UTC)

FWIW, I saw the secure symbols pop up on some editing done on some articles I edit, and it struck me as strange. To me (and possibly to the general reader as well), the secure symbol is almost as offputting as the "subscription required" symbols and their ilk. I'd hazard a guess that it makes people less likely to follow links to sources, and it makes the sources in question stand out from the other ones as 'different', nad not for any good reason I can make out. I too would prefer that such things matched the way the user is accessing Misplaced Pages. Carcharoth (talk) 07:23, 16 May 2012 (UTC)

HTTPS

https is actually meant for sensitive personal information, like you banking or your health records. I do not see why accessing pmids/pmcs with public(!) information would need https, unless you are concerned that your research may be traced by competitors. But then the pmids and pmc themselves hold the information already the exchanged text is immaterial. https does NOT come for free. Contemporary processors have processing power to burn. On an old PC processor or a small processor of a hand held gadget the Diffie-Hellmann matters. I believe https is misplaced here or should follow the way how you connect to wiki, if you are paranoid. (take you damn pills, folks) I propose to reconsider. It HAS disadvantages. I would propose to only implement it if there is a broad customer base asking it, not one person who skipped the pills. Next you read the FOX news webpage with https. For me it makes completely no sense, as no personal info is exchanged. 70.137.148.196 (talk) 15:57, 30 April 2012 (UTC)

I believe the main utility of Wiki is for kids in third world countries,(or American SLUMS) on stone age legacy hardware and software from a CHARITY, behind institutional FIREWALLS, with absolutely NO SPARE processor power, to learn scientific work, editing scientific text, training for their ACADEMIC FUTURE. You put THEM at a disadvantage. Really one thing beginning engineers have to learn is not to overengineer with "nice to have", and follow "if its not broken don't fix it". Listen to an old engineer. 70.137.148.196 (talk) 16:16, 30 April 2012 (UTC)

Even if they were on a slow-as-hell machine, it's what? Three seconds of processing power at most? Headbomb {talk / contribs / physics / books} 19:02, 30 April 2012 (UTC)

Apart from the 3 seconds, which are annoying, legacy configurations may not even support secure access. Think back to the machine you used 15 years ago and to its software. As far as I can see this is feature creep for "nice to have". No systematic investigation of backward compatibility issues has taken place. 70.137.148.196 (talk) 19:32, 30 April 2012 (UTC)

None of this matters anyway. If some host for a PMID resource wants to enforce HTTPS for whatever DRM-based reason, then that's their choice, not ours. Technically it's up to them to enforce that with a suitable redirect too, no matter what protocol we supply for the initial URI. Andy Dingley (talk) 19:12, 30 April 2012 (UTC)

No host for a pmid resource enforces https here, we are talking about NIH, and they offer it, not enforce it. Stop the damn feature creep. It matters, yes. NIH is not "DRM" its not the damned video gadget. Its a public repository. So cut it out. Have you done a systematic investigation of backward compatibilty issues? (No) 70.137.148.196 (talk) 19:32, 30 April 2012 (UTC)

Andy, you describe yourself as "code monkey" on your user page. Thats the worst part, to prevent them from fingerpoking on things which are just good and work, out of their innate coding instinct! Now stay back from the 'puter, relax and have a banana. Don't rush up the curtain. Its not broken, don't fix it. Find something useful (broken) to fix. 70.137.148.196 (talk) 19:38, 30 April 2012 (UTC)

I would expect that many accesses to pubmed from here involve individuals using Misplaced Pages to find out about medical conditions. To me that sounds like exactly the sort of personal information that should be secured. —David Eppstein (talk) 19:40, 30 April 2012 (UTC)

The https functionality is primarily used for financial transactions, including secure login for a subscriber. If the vendor wants you to pay for access, they will (or should) forward you on to an https-based address. Hence I agree with anon. The http address should be good enough for Misplaced Pages verification purposes. Beyond that, this discussion seems to be creeping toward incivility, which should be unnecessary. Regards, RJH (talk) 19:47, 30 April 2012 (UTC)

Re David - Finding out about medical conditions is not personal. Also reading the "Top ten fugitives" does not mean you are one. You do not enter "I have anal leakage, can it be the potato salad", you enter a pmid. And it is a public repository. If somebody draws conclusions on eavesdropping your connection, too bad for him, he probably skipped his pills! and he should have his (oo) ripped off for spying on you. 70.137.148.196 (talk) 19:56, 30 April 2012 (UTC)

I agree with David Eppstein. Privacy of medical conditions merits HTTPS. By the way, HTTPS not only encrypts the connection, but it also verifies the identity of the content node.

Besides, Anon's worries are way overblown. Even if you had like a 20-yr old 33-MHz computer connected with a 56k, HTTPS adds close to nothing to your latency. --bender235 (talk) 20:00, 30 April 2012 (UTC)

Is there any reason that the link can't be coded as which is protocol-relative? This form has been available since MediaWiki 1.18 (Sep/Oct 2011). --Redrose64 (talk) 20:02, 30 April 2012 (UTC)

As a compromise, I guess, that would be fine. But I've yet to hear why we shouldn't always use HTTPS. Performance clearly is not an issue. --bender235 (talk) 20:04, 30 April 2012 (UTC)

Wait, where are we using private medical information on Misplaced Pages? That type of information seems highly inappropriate for a reference. Hence this issue seems like a non sequitur. Regards, RJH (talk) 22:23, 30 April 2012 (UTC)

Protocol-relative looks like a good idea. If we're concerned about readers following links to pubmed to look up anal leakage, they've presumably come from an article about that topic where they have searched for it on wikipedia. So if they don't use https here, the cat's already out of the bag for snoopers. And if we're talking self-diagnosis (vs academic research), are readers actually likely to track down those pubmed links (vs often just reading the WP article)? If we're really trying to protect readers via secure(r) connections, seems like WP is the place (bonus: you also protect all sorts of other tempting snoop-targets that could have much more serious consequences, like political dissidents and people wanting to learn about the "outside" from within repressive regimes). Conversely, if readers have already not cared about being secure or are stuck using craptastic platforms and connections, why are we forcing our paranoia on their secondary actions once getting here? DMacks (talk) 02:26, 1 May 2012 (UTC)

Sounds like a plan. I updated all the links in {{Citation/identifier/sandbox}}. Please review, test and comment. ---— Gadget850 (Ed)  02:39, 1 May 2012 (UTC)

I second the proposal. Just to end this frenzy. Make it protocol-relative, and if you do, make for both PMID and PMC, and since we're at it, also OCLC and OSTI. --bender235 (talk) 12:11, 1 May 2012 (UTC)

All of the fields in the sandbox are PR. ---— Gadget850 (Ed)  12:49, 1 May 2012 (UTC)

I see. But not all of the identifiers support HTTPS. DOI and arXiv, for example. --bender235 (talk) 13:01, 1 May 2012 (UTC)

Which is why this is in the sandbox for review. Headbomb got a head of me on testing and has made a number of updates. ---— Gadget850 (Ed)  18:21, 1 May 2012 (UTC)

Its not only a performance issue, it is also a backward compatibility issue with old/special software, browser, OS, installation, server, firewall, totalitarian state internet etc. which may not even support https, and SSL may be forbidden. You have not systematically investigated such compatibility issues.

Still thou are blest, compared wi' me! The present only toucheth thee: But och! I backward cast my e'e, On prospects drear! An' forward, tho' I canna see, I guess an' fear! 70.137.148.196 (talk) 20:14, 30 April 2012 (UTC)

So bender, do us a favor and investigate the pitfalls of backward compatibility systematically, or ask a systems architect for an opinion. Are you the bender from "Futurama"? 70.137.148.196 (talk) 20:27, 30 April 2012 (UTC)

Uhm, no. I think it's your obligation to present backward compatibility issues, not mine. I don't even think those issues exists, unless you go back to like early 90s technology.

Also, totalitarian regimes that block HTTPS per se usually also block Misplaced Pages entirely, regardless of protocol, anyways. --bender235 (talk) 20:33, 30 April 2012 (UTC)

No, you got the burden of proof issue wrong. If YOU want a change to the existing and working solution, then YOU have to prove that it does not break existing functionality. That means YOU are asked for an investigation of backward compatibility issues. Thats is how ECOs are applied - NOT that EVERYBODY introduces unchecked ECOs per gusto and the unlucky victims of the resulting wild feature creep have to prove they got problems. (You talk a bit like the non-technical mgrs. I have encountered during my long career as an eng. They didn't understand that either. Must be the economist curriculum.) 70.137.148.196 (talk) 20:45, 30 April 2012 (UTC)

I'm not sure if you're just trolling, but for this time I'll continue to WP:AGF: it is logically impossible to prove the non-existence of backward compatibility issues. It only works the other way 'round: someone names a concrete setup of OS, browser, etc. in which HTTPS does not work. But since HTTPS has been implemented in browsers as early as 1994, I believe no one in the world is using a browser that doesn't support it. --bender235 (talk) 22:57, 30 April 2012 (UTC)

For heavens sake, why should an old engineer be trolling. I just see that you are introducing new features and changing functionality without thinking of side constraints. What if an installation has https connections blocked? You are in a company, a university, a research facility? You are running through a proxy? Why in hell are students not taking professional concerns serious? We are also not only talking about PCs but also about other internet operable gadgets. And you really got the way how to implement customer requirements and Engineering Change Orders wrong, as well as the burden of proof. 70.137.148.196 (talk) 23:08, 30 April 2012 (UTC)

Also regarding the privacy, you are clicking on a link in the public Wiki. It links to an entry in a public database. If somebody infers "if he clicks on diarrhea he got it himself" this would be very novel illogical thinking, except in the circles of paranoics. "if he clicks on dynamite, he is a terrorist". Damn, folks, now take your swig of Haldol. I am aware of attempts to hide whatever you click on, to prevent the Gestapo from waking you up at 5am. But sofar I have discounted it as conspiracy theories. 70.137.148.196 (talk) 23:32, 30 April 2012 (UTC)

bender, I see you are from Jena. They don't have a Stasi there any more. So what is the problem? Relax, man they are gone. Is the formula for concrete in Jena still "two parts cement, one part microphones"? Do you still get Diamat lectures to pass the semester? Do they still shove a mirror under your car to see if you hide someone there? No. So relax. (or does it stick for 20+ years?) 70.137.148.196 (talk) 23:55, 30 April 2012 (UTC)

That was totally uncalled for. We hit Godwin's law more quickly than I ever expected. If you don't have anything technical or engineerish to add, then let it go. ---— Gadget850 (Ed)  02:10, 1 May 2012 (UTC)

It is not Godwins Law, and I am not talking about Nazis. I am German and Jena is in in former communist part of Germany, reunited 1990. Get a damn education, I am serious that the man shall relax, it is over, they are gone. I just try to give my fellow countryman comfort. They had a hard time. 70.137.129.18 (talk) 03:07, 1 May 2012 (UTC)

Hell, Gadget I see you were stationed there, then what do you talk? Thx for defending us against the commies. 70.137.129.18 (talk) 03:10, 1 May 2012 (UTC)

re technical - engineerish: So what is about installations blocking https targets? What about the other concerns? Legacy software, installations? 70.137.129.18 (talk) 03:14, 1 May 2012 (UTC)

Be specific. Do you know of such blocks, or of such outdated software? How many people are affected, if any? Vague concerns that bears will eat you if you click on a locked link will not be convincing without news reports of actual bears. —David Eppstein (talk) 05:01, 1 May 2012 (UTC)

I have seen company installations blocking https for concerns of uncontrollable communication to outside of proprietary information. There have been old browsers from a German company, before netscape I think, not supporting SSL. I do not have vague concerns. I have worked in engineering in the electronic security field.(identification, authentication, sidechannel leakage, architectural support for process isolation) A solution following the way how you connect to wiki would be ok. because then it is your choice between secure/not secure, not a forced choice. So the http is then available as a fallback, whenever https doesn't work for any reason. Please don't confuse (really) old farts with your students. 70.137.129.18 (talk) 05:17, 1 May 2012 (UTC)

Please take a look at above opinion by DMacks. He got it right, and I got it right. (at the start of this discussion) Besides I got my EE in '69 70.137.129.18 (talk) 05:49, 1 May 2012 (UTC)

Sandbox

Here are samples using the sandbox, protocol relative:

{{citation/identifier/sandbox |identifier=arxiv |input1=0709.0674}}

{{citation/identifier/sandbox |identifier=asin |input1=B00086U61Y}}

{{citation/identifier/sandbox |identifier=bibcode |input1=2007A&A...474..653V}}

{{citation/identifier/sandbox |identifier=doi |input1=10.3998/3336451.0004.203}}

{{citation/identifier/sandbox |identifier=isbn |input1=978-0-471-70410-2}}

{{citation/identifier/sandbox |identifier=issn |input1=0028-0836}}

{{citation/identifier/sandbox |identifier=jfm |input1=54.0271.04}}

{{citation/identifier/sandbox |identifier=jstor |input1=2118559}}

{{citation/identifier/sandbox |identifier=lccn |input1=sn2006058112}}

{{citation/identifier/sandbox |identifier=mr |input1=96d:11071}}

{{citation/identifier/sandbox |identifier=oclc |input1=22239204}}

{{citation/identifier/sandbox |identifier=ol |input1=18319A}}

{{citation/identifier/sandbox |identifier=osti |input1=6851152}}

{{citation/identifier/sandbox |identifier=pmc |input1=1408034}}

{{citation/identifier/sandbox |identifier=pmid |input1=12122621}}

{{citation/identifier/sandbox |identifier=rfc |input1=882}}

{{citation/identifier/sandbox |identifier=ssrn |input1=512922}}

{{citation/identifier/sandbox |identifier=zbl |input1=0823.11029}}

---— Gadget850 (Ed)  13:39, 1 May 2012 (UTC)

Updated the list with supported protocols. Not every site supports HTTPS. If you try it with DOI, it dumps you to a login. ---— Gadget850 (Ed)  00:00, 2 May 2012 (UTC)

Removing "?tool=pmcentrez" from PMC links seems to resolve to the same page, though on the equivalent PMID 11212593 page to your example the PMC there links with "?tool=pubmed".

From Creating Links to Web Pages in the Entrez System it's not clear that "?tool=pmcentrez" adds anything useful. RDBrown (talk) 03:59, 3 May 2012 (UTC)

Sandbox now live. ---— Gadget850 (Ed)  12:19, 5 May 2012 (UTC)

One bit that seems to be missing is that while |pmc= creates an HTTPS link (when logged in via HTTPS) the URL-from-PMC generation still creates HTTP. Is this fixable? Thanks Rjwilmsi 12:07, 15 May 2012 (UTC)

Not sure what you man by "URL-from-PMC generation". ---— Gadget850 (Ed)  12:30, 15 May 2012 (UTC)

There is logic in the template code to set the URL parameter from the PMC parameter, if no URL is otherwise set. This generated URL does not appear to be protocol relative. Thanks Rjwilmsi 13:04, 15 May 2012 (UTC)

I don't see that:

{{citation |title=title |journal =journal |pmc=1408034}}

---— Gadget850 (Ed)  14:37, 15 May 2012 (UTC)

In citation core, sorry. Rjwilmsi 17:03, 15 May 2012 (UTC)

I need a live example, as I just don't see the problem. ---— Gadget850 (Ed)  22:06, 15 May 2012 (UTC)

Update OL behaviour

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Apparently I didn't quite get the template behaviour right despite my testing. If someone could sync Template:Citation/identifier/sandbox, with Template:Citation/identifier (diff), that would be great. Otherwise the template will not recognise OLs ending with either M or W. Headbomb {talk / contribs / physics / books} 22:50, 6 May 2012 (UTC)

 Done --Redrose64 (talk) 23:16, 6 May 2012 (UTC)

RFC on date consistency within references

Hello. There's a RFC on date consistency within references. I think you might be interested. 1exec1 (talk) 09:10, 9 May 2012 (UTC)

Additional identifier NCJ

To Template:Citation/identifier, please add NCJ number, so that an input like

{{citation ... |ncj=122967 }}

produces a link looking like this:

NCJ 122967

Explanation: NCJ is to criminal law literatur what PMID is to medical literature. (BTW: www.ncjrs.gov also supports HTTPS, so per discussion above please make the link protocol-relative. --bender235 (talk) 15:30, 11 May 2012 (UTC)

How many citation templates would we expect to use this identifier? I ask because if it is only a few dozen, say, then it would make more sense to use a standalone template within |id= rather than burdening all citation templates with the cost of decoding yet another parameter. —David Eppstein (talk) 16:18, 11 May 2012 (UTC)

I think the threshold in previous discussion was 100+. Nulling edit request for now, as it has not been discussed, not have specific changes been proposed. ---— Gadget850 (Ed)  16:26, 11 May 2012 (UTC)

It looks like there are presently 18 article pages using the {{NCJ}} template. Regards, RJH (talk) 16:31, 11 May 2012 (UTC)

And more used as URLs. ---— Gadget850 (Ed)  16:35, 11 May 2012 (UTC)

That appears to push it well over the 100+ threshold. Thanks. Regards, RJH (talk) 19:49, 11 May 2012 (UTC)

An interesting fing ...

Just going through FAC with an article, and this one came up. Is it possible to fix the {{citation| ...}} template so that it puts a period before "retrieved"? The non-standardisation of the period / comma delineation was picked up at review. Pesky (talk) 03:51, 16 May 2012 (UTC)

• Misplaced Pages pages with to-do lists