Template talk:Citation/core/Archive 16

Centralize talk?
Currently many of the citation template discussions are being centralized to Help talk:Citation Style 1. Should this one be included in that centralization? Several of the discussions here (for instance on boldfacing volume numbers or on where to link url parameters) are not about the technical details of the parameter but about what the displayed output should look like, so centralization should help get more interested parties involved in the discussion. —David Eppstein (talk) 21:05, 23 March 2012 (UTC)
 * It shouldn't. Help talk:Citation Style 1 is a place to discuss WP:CS1-related topics, which don't normally intersect with the technical issues that are supposed to be discussed here. At the same time this template is also used for WP:CS2 and other CS1-incompliant citation templates. Though having centralized discussion would be beneficial in some cases, I'm sure there'll be more of annoyances. — Dmitrij D. Czarkoff (talk) 21:23, 23 March 2012 (UTC)


 * I specifically did not include core as this should be more technical stuff related to changes. A lot of the individual CS1 talk pages were about how to cite something in particular, or related to errors, and that is starting to pop up. Now that is is centralized, we can more readily tweak the now-centralized documentation as needed. ---— Gadget850 (Ed)  talk 21:30, 23 March 2012 (UTC)

Centralize Template:MSW3 Groves
This is also a candidate to get merged here. Can somebody handle the edit request there? mabdul 20:57, 7 April 2012 (UTC)

✅ Editor parameters separated. ---— Gadget850 (Ed)  talk 21:14, 7 April 2012 (UTC)

Placement of format wrt contribution and editor
In this citation, I think the subscription required parameter's output is misplaced. The format describes the content of the url, and should go after the item linked by the url, which in this case is the contribution.

expands to

—David Eppstein (talk) 20:29, 22 April 2012 (UTC)
 * I'm afraid that is misuse of the parameter - format is for indicating the file format, if it's not HTML (see Template:Citation Style documentation/url). You should use the template, placing it just after the  but before the closing . -- Red rose64 (talk) 23:37, 22 April 2012 (UTC)
 * Your answer is irrelevant to my complaint. If I were to write pdf (which I wouldn't, because I think it's stupid clutter to do so, because the file format is usually unimportant and usually easily inferred from the url) then it would be equally misplaced. And for that matter, putting "subscription required" at the end of the citation, after everything else, is also incorrect. In this case the citation is to a book, which you could presumably buy without having to subscribe to anything. The subscription required notification should be as close to the url as possible, because that's what it goes with, not with the other parts of the citation. —David Eppstein (talk) 23:53, 22 April 2012 (UTC)


 * Subscription required/Registration required are supplemental information— not core elements of a citation in that they do not identify the source.
 * Related discussion: Help talk:Citation Style 1/Archive 8 ---— Gadget850 (Ed)  talk 10:39, 23 April 2012 (UTC)
 * But they are supplemental information that is associated with one specific part of the citation — its url — and not the rest of the citation. It is like you decided that color adjectives are unimportant and relegated them to the end of a sentence: "The car drove up to the building; red." instead of the usual "The red car drove up to the building". —David Eppstein (talk) 15:39, 23 April 2012 (UTC)

ISBN
Propose modifying per, so that ISBN 0-1-2345678-X shows as a single wikilink consistent with the rest of Wikipedia.

E.G.

Not

Rich Farmbrough, 10:07, 8 May 2012 (UTC).


 * I added support for RFC and PMID auto linking:




 * Need to check protocol relative. ---— Gadget850 (Ed)  talk 13:12, 8 May 2012 (UTC)


 * PMID magic does not support protocol relative: we just fixed this, so I am going to revert that. Filed . ---— Gadget850 (Ed)  talk 13:51, 8 May 2012 (UTC)


 * PMID fixed at MediaWiki:Pubmedurl. ---— Gadget850 (Ed)  talk 00:36, 9 May 2012 (UTC)


 * Oppose The problem is that these links for the acronyms ISBN, ISSN, OCLC, etc, also serve as an explanation of what the numbers are. Delinking them and merging the acronym into the link for the number loses that, and honestly, I can't support that. MOS:LINK might say, "when possible, avoid placing links next to each other so that they look like a single link ... Consider rephrasing the sentence, omitting one of the links, or using a more specific single link", but in this case we would lose the explanatory link, which isn't something I can support. A reader can hover his cursor over the wikilinked acronym to pull up the tooltip that spells out the full name, as well as click the link to the article on International Standard Book Numbers. If the acronyms absolutely have to be unlinked, consider using a variant on abbr which will still generate a tool tip. If these two sentences of the MOS are the sole guideline reason for unlinking them, I'm going to point to WP:IAR and ask that they remain for the benefit of our readers.  Imzadi 1979  →   06:40, 9 May 2012 (UTC)


 * I disagree with Imzadi1979. I have often clicked on the wrong part of what I thought was a single blue link to the ISBN number, only to find myself taken to the article about ISBN, which I do not need to read, rather than to the WorldCat page for the book. -- Alarics (talk) 07:07, 9 May 2012 (UTC)
 * A misclick is not a reason to remove information. Not all of our readers will know what an ISBN, ISSN, or OCLC number are, and if we can give them some context for that, we should.  Imzadi 1979  →   07:14, 9 May 2012 (UTC)
 * Surely the reader can infer what it is when they get to it. -- Alarics (talk) 11:22, 9 May 2012 (UTC)
 * Since ISBN/ISSN/OCLCs aren't part of standard print citations in most style guides, so our inclusion of them is somewhat novel. Removing the cues as to what the numbers are might discourage readers from even clicking the links in the first place. At a minimum, if these links are removed as proposed, can we at least have the acronym "tooltipped" à la abbr? I've used that template so that the abbreviation for the Marquette County Road Commission (MCRC) could be used in infoboxes without a link analogously to how the Michigan Department of Transportation links are piped to just "MDOT". That way our readers get information by hovering their cursors over the acronym (as before) but the term isn't link (which is what some want to avoid adjacent links).
 * I still say though that a misclick is not a reason to remove a valid, and useful, link. A change of this sort needs a wider advertisement before being implemented. The community might yawn and not care, or they might.  Imzadi 1979  →   19:06, 9 May 2012 (UTC)
 * The point is that this is not how Wikipedia does ISBNs, this is really a revert of a previous change to the usual way of doing things. ISBN 978-0586041833 renders like that with no code at all. If extra functionality is wanted for standard ISBN  rendering it should be a MediaWiki fix.  ISBNs should render the same inside a cite template as they do outside a cite template, principle of least surprise applies.  ISBN is also very widely understood, and is mentioned on the booksource page. Rich Farmbrough, 20:54, 9 May 2012 (UTC).


 * I agree with Rich that there should be consistency of ISBN magic word versus cite templates, though I can see arguments for and against having ISBN linked separately. Rjwilmsi  09:34, 10 May 2012 (UTC)
 * Oppose: The current behaviour (separate links for ISBN/PMID/RFC and the identifier itself) is better. It's consistent with the behaviour of all other identifier, and you can have an explanation of what the identifier is if you don't know what it is. Headbomb {talk / contribs / physics / books} 14:25, 10 May 2012 (UTC)
 * Then submit a Bugzilla to get the default behaviour changed. Although I have to say it's pretty egregious WP:OVERLINKING. Rich Farmbrough, 23:31, 10 May 2012 (UTC).


 * OK I put the change live since there seems to be consensus. I am not adverse to someone adding the tooltip Imzadi1979 suggests.  I have checked the bugzilla lists for ISBN based bugs and can't find Robert Allen's ISBN related bug, whcih would be the place to tie a request to link to the ISBN article.  Note also that the magic word provides other benefits to the rendered page such as a class, and more if Robert's proposal gets adopted, as well as providing a small reduction in cite transclusion size and depth, and probably rendering time. Rich Farmbrough, 02:04, 13 May 2012 (UTC).


 * There wasn't consensus to make the change, and I suggest that you shouldn't have made it. You had two editors (myself and Headbomb) oppose the change, and as the proposer, you shouldn't have ended the discussion and made it. Please reverse as you are WP:INVOLVED here.  Imzadi 1979  →   02:06, 13 May 2012 (UTC)
 * There's four in favour, and you seemed to be happy (albeit grudgingly) if the tooltip were added. That could go in as  a separate change, I made it clear that I had no objection to that. Rich Farmbrough, 02:12, 13 May 2012 (UTC).


 * I'd rather things stay as is. I'd also rather we don't do this in two steps if anything is to be done. There's no guarantee that a second step would be made, and any support you might have from me is predicated on additional changes. In short, count me as a full oppose unless the change to be made satisfies my objection, and the current sandbox does not.  Imzadi 1979  →   03:04, 13 May 2012 (UTC)

Put the sandbox version live please, pursuant to the above discussion. Rich Farmbrough, 02:12, 13 May 2012 (UTC).


 * There's no consensus for this. Headbomb {talk / contribs / physics / books} 04:49, 13 May 2012 (UTC)

Identifiers
Having my head in citation/identifier, it seems to me that we could improve performance a bit.

Currently, citation/core does an #if to check for each identifier; when found, citation/identifier is then invoked where it does a #switch and checks for each identifier until a match is made.

We could improve this a bit by splitting citation/identifier into separate subtemplates. ---— Gadget850 (Ed)  talk 14:54, 20 May 2012 (UTC)

Edit request of 23 May
There are two minor errors in the template's output. First, the wikilinked "doi" should be "DOI", and second, "et al" should be "et al." since "al" is an abbreviation of "alii". Example of both:



Note that user Gadget850 is looking into the latter.


 * —DocWatson42 (talk) 02:40, 24 May 2012 (UTC)
 * Attended to the first request, as no one expressed any objection to the change. Perhaps you could check with Gadget on his progress with the latter because I don't want to duplicate his work. He has probably just forgotten about it. &mdash; Martin (MSGJ · talk) 17:38, 29 May 2012 (UTC)
 * Fiddling with it in one of my sandboxes. ---— Gadget850 (Ed)  talk 17:42, 29 May 2012 (UTC)
 * The previous problem was that without a date, there were two periods after el al. because of the separator. My previous fix caused it to have a period only if the date was not defined. Fixed the same issue with ed.---— Gadget850 (Ed)  talk 18:15, 29 May 2012 (UTC)
 * Banzai! Thank you both; the "ed." fix is a bonus that I also appreciate. ^_^ —DocWatson42 (talk) 06:06, 30 May 2012 (UTC)

COinS turns into broken MathJax formatting when math formatting is present in the title of an article
In Squared triangular number, two of the references have mathematical formulae in them (with binomial coefficients, so impossible to rewrite as html). When I view them using User:Nageh/mathJax, I see a spurious italicized "< spanstyle="display:none;">< /span >" at the end of the reference. For example (with some minor changes to the TeX markup that don't affect the problem): displays as something approximately like (where I've replaced the binomial coefficient with the letter X). The problem is in the COinS markup at the end of the reference: the title of the article goes into the parameters of the COinS span, and something in mediawiki transforms the whole COinS data span into &amp;#160;   (regardless of whether I'm using MathJax or not) which is at least harmless on non-MathJax views but causes things to break when I use MathJax. Getting the developers to fix MediaWiki seems to be hopeless; they haven't made any effort to fix much more serious bugs in the MathJax support. Is there any chance of adding a flag to the template that would disable COinS in this case? Or that would provide a substitute title to use in the COinS data when the real title causes problems like this? —David Eppstein (talk) 18:20, 14 June 2012 (UTC)
 * Benjamin, Arthur T.; Orrison, M. E. (2002). "Two quick combinatorial proofs of ∑k3=X". The College Mathematics Journal 33 (5): 406–408.< spanstyle="display:none;">< /span >


 * Citations end with &amp;#160;. For some reason, this span gets wrapped in, which is what exposes the span. I don't know why we have the non-displayed, non-breaking space at the end of the citation. ---— Gadget850 (Ed)  talk 18:34, 14 June 2012 (UTC)
 * Because of the COinS data. COinS is formatted as something . The something is just there to make the span work and is a non-displayed no-break space because that's pretty harmless. But the problem is that, when math is present in the title, the COinS span gets munged into a TeX span and the contents inside it stop being harmless. So we get both (1) no COinS data, and (2) displayed garbage. I would like a workaround where we at least avoid the garbage and perhaps can restore the data as well. —David Eppstein (talk) 18:38, 14 June 2012 (UTC)
 * Yes, the COinS data is held in the  attribute of the opening . HTML attributes may not contain the   sequence, because that is assumed to be the end of the element. Can we use anchorencode (or similar) on the content of the   attribute? -- Red rose64 (talk) 19:26, 14 June 2012 (UTC)
 * We're already using urlencode on it, which is good enough when there's other markup such as a  within the title. I guess the problem is that MediaWiki's MathJax conversion is too smart for its own good, and turns the $$...$$ into a TeX span even when it's urlencoded (and even when it's inside an html attribute). It looks like anchorencode would work (it completely removes the math from the text it's encoding) but I wonder whether its other side effects such as converting spaces to underscores would be too severe. —David Eppstein (talk) 20:39, 14 June 2012 (UTC)
 * Maybe whats needed is a  parameter, this could be a representation of the title which does not include embeded markup. So you could then use the citation as
 * So the COinS atribute is set to the plaintitle which should render fine. Quite how a mathematical equation in an article title should be rendered in COinS is a good question, certainly an embedded image or mathml does not seem to meet the COinS objective. Using a plaintitle parameter would be relatively easy to implement rft.atitle= in appropriate places. Doing this would have much smaller processing load than any automated solutions to cleanup the title parameter.--Salix (talk): 23:33, 14 June 2012 (UTC)
 * So the COinS atribute is set to the plaintitle which should render fine. Quite how a mathematical equation in an article title should be rendered in COinS is a good question, certainly an embedded image or mathml does not seem to meet the COinS objective. Using a plaintitle parameter would be relatively easy to implement rft.atitle= in appropriate places. Doing this would have much smaller processing load than any automated solutions to cleanup the title parameter.--Salix (talk): 23:33, 14 June 2012 (UTC)


 * Here is a sample using citation/core:
 * And using citation/core/sandbox, where &amp;#160; has been removed:
 * ---— Gadget850 (Ed)  talk 00:34, 15 June 2012 (UTC)
 * That has the effect of always removing all of the COinS data, regardless of whether there is any math in the title. You could achieve the same effect more simply by removing the whole COinS section of the template (the last 20 or 30 lines, I think). This wouldn't present any visible change to readers (except for resolving this issue) but would make the people who like COinS squawk, I imagine. —David Eppstein (talk) 00:40, 15 June 2012 (UTC)
 * ---— Gadget850 (Ed)  talk 00:34, 15 June 2012 (UTC)
 * That has the effect of always removing all of the COinS data, regardless of whether there is any math in the title. You could achieve the same effect more simply by removing the whole COinS section of the template (the last 20 or 30 lines, I think). This wouldn't present any visible change to readers (except for resolving this issue) but would make the people who like COinS squawk, I imagine. —David Eppstein (talk) 00:40, 15 June 2012 (UTC)

I've reinserted the span in the sandbox so CoINS works again. This means Gadget850's example does not work above. I've also added code for a  parameter, here are three working examples These all display fine.--Salix (talk): 06:54, 15 June 2012 (UTC)
 * Sandbox with maths and PlainTitle, Journal
 * Sandbox with maths and PlainTitle, Book
 * Sandbox with maths and PlainTitle, book with IncludedWorkTitle
 * Sandbox with maths and PlainTitle, book with IncludedWorkTitle
 * Sandbox with maths and PlainTitle, book with IncludedWorkTitle
 * This will require some manual editing in any affected articles, but I think it's the cleanest solution. —David Eppstein (talk) 07:22, 15 June 2012 (UTC)


 * Ah. Per the COinS spec, the non-breaking space is needed to keep HTML Tidy from stripping the COinS span. My SWAG is that HTML Tidy is causing the problematic tex span. To implement the above fix, every dependent template must be updated. ---— Gadget850 (Ed)  talk 10:42, 15 June 2012 (UTC)

Masking authors in a more sophisticated fashion
I would like to investigate ways of hiding authors other than simply the first in the list.

I am working on sharing citations between articles, usually using sub-templates of cite doi or related, and it would be really handy if this could be extended to the articles relating to the authors of said citations. At the moment the only way to do this would be to copy and paste slightly different versions of the wikitext across articles, adjusting the author list to shift the subject of the containing article to the front of the list, which rather obliterates the advantage of sharing.

What I would like is to be able to hide whichever author x for which the authorlinkx parameter matches the current &#x7b;&#x7b;PAGENAME&#x7d;&#x7d; but I'm not quite sure how to go about it. Actually hiding the relevant author isn't so difficult, so much as detecting when there is a match so as to display the author-mask parameter or equivalent.

Any thoughts? TIA HAND —Phil | Talk 21:37, 10 July 2012 (UTC)


 * I don't know what style guide you read, but in Turabian or Chicago the authors "Bloggs, Ada; Jones, Sara" and "Bloggs, Ada" are different authors for citation style purposes, so I should never read "Bloggs, Ada [new line] ———; Jones, Sara". Also, "author-mask" is a broken implementation last time I checked, and needs to be manually set to two or three m-dashes as required. Fifelfoo (talk) 21:47, 10 July 2012 (UTC)


 * An almost identical thread has been started at Help talk:Citation Style 1 and has attracted more than one comment. Per WP:MULTI, I suggest this be discussed there, not here. -- Red rose64 (talk) 22:39, 10 July 2012 (UTC)

new 'fast' citation templates
There's a new 'fast' set of templates; fcite web and kin. They are slimmed-down forks of the usual ones and they are very limited in their functionality. They've been deployed to a bunch of articles and they break things; harv and sfn, for example. They also require shoving the non-primary author into coauthor instead of last2 et al. Wikid77 is behind this and is not responding to queries, so it's at:
 * Administrators' noticeboard/Incidents

Br&#39;er Rabbit (talk) 05:57, 11 July 2012 (UTC)


 * Now @Village pump (technical). pablo 10:45, 11 July 2012 (UTC)


 * Fcite_web is a very fast alternative, not a fork: All of the {&#123;Fcite_*}} templates are faster variations of the others, running about 5-6x times faster, but allow mixed use with the original templates. So, to list names of 8 authors, separately, then use the older template {&#123;cite_web}}, while using {fcite_web} for fast cases of just 1 or 2 authors (or list all in "coauthors=") or 1 editor. To support {Harvnb} & {sfn} cross-links from author names, the Template:Fcitation has been fixed to set the {anchor|xx} tags in "CITEREFxx" format, and allow name parameters: last1, last2 and last3. The intent is to allow very rapid formatting of most references, but still support author-crosslinks, while allowing use of any and all original templates of the {&#123;Cite}} family. In large articles with 100 or more references, the speed improvement has tended to make the whole article reformat 3x faster, such as during each edit-preview when editing the whole page. The 3x reformat speed has occurred in major articles, such as nations or big cities, but also in research topics which use many {cite_journal} or {cite_book} cases. With rare cases, such as 7 author names or 3 editors, then the speed improvement will be less when using some of the old cite templates. -Wikid77 (talk) 23:14, 11 July 2012 (UTC)
 * Per WP:MULTI, let's not split this discussion - it's ongoing at Village pump (technical) so please comment there, not here. -- Red rose64 (talk) 09:06, 12 July 2012 (UTC)

AuthorMask
When AuthorMask is set to a numeric value, it displays the value of em spaces wrapped in. This causes display issues on some systems, specifically MacOS X 10.6.8 with Safari 5.1.7, where nothing displays. I really don't understand why deleted em spaces are used here. I have updated the sandbox to use mdashes:

---— Gadget850 (Ed)  talk 01:13, 13 July 2012 (UTC)

✅ ---— Gadget850 (Ed)  talk 09:45, 21 July 2012 (UTC)