Help talk:Citation Style 1/Archive 33

Archive 30

Archive 31

Archive 32

Archive 33

Archive 34

Archive 35

→

Archive 40

PMCID and the PMC prefix

I wanted to bring this topic back to the surface again. It was recently discussed at Help_talk:Citation_Style_1/Archive_30#PMC, which led to the creation of phab:T157152. This ticket concludes (and I agree) that what CS1 is doing is basically not following the guidelines for usage of PMCID usage. It is therefor a 'CS1'-problem that we should deal with at this level as well. I think we have two options, either make the 'input format' of the PMCID be more flexible (The lua code can easily be adapted to accept both) or cleanup PMCID additions with a bot. —TheDJ (talk • contribs) 15:14, 12 April 2017 (UTC)

It's a citoid bug, so fix citoid? Headbomb {t · c · p · b} 15:40, 12 April 2017 (UTC)

Mmm I see. [1] says format should be PMCID: PMC#####. We should follow suit then. Headbomb {t · c · p · b} 15:49, 12 April 2017 (UTC)

(The lua code can easily be adapted to accept both) Do we want to have output of "PMC PMC\d*" or "PMC \d*" in the event that we take that path? --Izno (talk) 15:59, 12 April 2017 (UTC)

Aside courtesy @Boghog: due to involvement on the phabricator task. --Izno (talk) 16:06, 12 April 2017 (UTC)

Izno, according to that documentation, the output should be PMCID: PMC0123456. Headbomb {t · c · p · b} 16:11, 12 April 2017 (UTC)

Which has little or no bearing on how we present the ID. I appreciate the fact that the ID is actually "PMC\d*", but that does not require us to present the ID as "PMC: PMC\d*" or even "PMC\d* rather than the current "PMC: \d*", and in fact I disfavor the former as being unnecessary at this time and the latter as being somewhat inconsistent with how we do present it presently. --Izno (talk) 16:29, 12 April 2017 (UTC)

The NIH guideline (e.g., PMCID: PMC2291284) is crazy. Why repeat PMC twice? As pointed out by Izno and Trappist, there is no reason that CS1/2 has to follow the NIH guideline. Even less reason why the parmeter value has to include PMC (e.g., |pmc=PMC2291284). Boghog (talk) 17:31, 12 April 2017 (UTC)

Not that crazy. Numbers without context are meaningless. By explicitly making the context part of the identifier, it's easier to scrape the web and find your numbers back (for starters). It's also not really uncommon. Many image database identifiers do the same thing for instance. —TheDJ (talk • contribs) 19:35, 12 April 2017 (UTC)

For consistency, we then should add the parameter names to all parameter values (e.g., |volume=volume298, |issue=issue1, |pages=pages59–70, |year=year2006, |doi=doi10.1016/j.ydbio.2006.06.013, |volume=volume4}. The context is provided by the parameter name (e.g., |pmc=2291284) and in wiki link in the rendered citation (PMC: 2291284). It is redundant to repeat the parameter name in the parameter value and the wiki linked database name in the database accession number. Boghog (talk) 19:46, 13 April 2017 (UTC)

For scraping Wikipedia for specific PMC ids, CirrusSearch works pretty well (e.g., insource:\pmc = \d+\). Boghog (talk) 20:33, 13 April 2017 (UTC)

That's the thing. For the PMID, the actual PMID is a pure number: e.g. 18183754. For the PMCID, the actual PMCID is not a pure number, it is e.g. PMC2990724. Headbomb {t · c · p · b} 19:55, 13 April 2017 (UTC)

QED. The NIH is internally inconsistent. Boghog (talk) 20:02, 13 April 2017 (UTC)

Headbomb {t · c · p · b} 20:22, 13 April 2017 (UTC)

the actual PMID is a pure number: e.g. 18183754 Just quoting you ;-) Boghog (talk) 20:37, 13 April 2017 (UTC)

I don't follow. PMIDs are in one format. PMCIDs are in another. It's like faulting ISBNs for not following the format of ISSNs. Headbomb {t · c · p · b} 20:39, 13 April 2017 (UTC)

Both ISSNs and ISBNs are ISO standards and neither requires that the parameter name be include in the parameter value. Hence ISSNs and ISBNs are internally consistent. PMIDs and PMCIDs are both issued by the US National Library of Medicine/National Institutes of Health and only the PMC requires that the parameter name be included in the parameter value. This is inconsistent. Boghog (talk) 20:51, 13 April 2017 (UTC)

ISSN is 8 characters. ISBN is 10 or 13. Clearly this is inconsistent. And no, the PMCID does not required the 'parameter name ' to be included in the parameter value. The name is PMCID, the value is PMC0123456. PMCID does not appear in PMC0123456 and even if it did, so what? Headbomb {t · c · p · b} 20:59, 13 April 2017 (UTC)

The letters "PMC" appear twice which is redundant. Boghog (talk) 21:03, 13 April 2017 (UTC)

Again, so what? Headbomb {t · c · p · b} 07:02, 14 April 2017 (UTC)

The most valuable of all talents is that of never using two words when one will do.

— Thomas Jefferson

Boghog (talk) 07:38, 14 April 2017 (UTC)

cs1|2, claims to the contrary notwithstanding, is a style in its own right. cs1|2 takes cues from published style guides but is not beholden to those style guides. So it is with PMC. We have no obligation to make cs1|2 adhere to PubMed Central's preferred styling. Given the comments in phab:T157152 I think it unlikely that those who play in the internals of citoid are interested in a citoid solution to the problem. That leaves it to us. We can tweak the module to accept PMC values with the redundant PMC prefix and then do as we wish with it.

—Trappist the monk (talk) 16:24, 12 April 2017 (UTC)

Because I think that there is no citoid fix, I've tweaked Module:Citation/CS1/Identifiers/sandbox:

• 4664-351: Title. PMC 4664-351. {{cite book}}: Check |pmc= value (help)
• 4664351: Title. PMC 4664351.
• pmc4664-351: Title. PMC pmc4664-351. {{cite book}}: Check |pmc= value (help)
• pmc4664351: Title. PMC 4664351.{{cite book}}: CS1 maint: PMC format (link)
• pmc 4664351: Title. PMC pmc 4664351. {{cite book}}: Check |pmc= value (help)

—Trappist the monk (talk) 17:13, 12 April 2017 (UTC)

I assume from the length of the phab ticket that mediawiki devs have declined to do anything on their side. So yes, pragmatic solution for the moment is to allow |pmc=pmc1234 and |pmc=PMC1234 in addition to the existing |pmc=1234 (do we need to allow |pmc=pmc 1234 too?), and leave the rendered display as-is. If there is a desire to change the rendered display, that's a separate matter (I am also of the view that the PubMed guidelines seem to want redundancy that we are not required to show; broadly I think they want any display to be clear whether the number is a PMID or a PMC, which we do clearly as is, so I don't see a need to change rendered display.) Rjwilmsi 19:21, 12 April 2017 (UTC)

The primary point being made in the ticket is that the identifier is NOT just the number, but PMCnumber, and so Citoid is conceptually returning the right value. It's just that our templates expect a 'partial identifier'. The developer discussion gave no judgement on how we should render the ID. I wouldn't object personally to keeping any representation to just as it is right now, even though NIH guidelines suggest something else. However I do note that NIH uses that notation quite consistently, and I think that such consistency is something to take into account when evaluating this. —TheDJ (talk • contribs) 19:51, 12 April 2017 (UTC)

I've changed Module:Citation/CS1/Identifiers/sandbox slightly, to simply allow the number to be prefixed with PMC and display everything as we have so far. I think this is best for now. —TheDJ (talk • contribs) 08:45, 14 April 2017 (UTC)

Why not display it as "Title. PMC4664351" directly then? Do we really need the first "PMC: "? My proposal would be to remove the first "PMC: " and normalize all input identifiers to add PMC in front of the number. This minimizes the visual difference compared to what we have now. − Pintoch (talk) 09:16, 14 April 2017 (UTC)

Yes, we do need the first PMC as it explains what PMC is. Also, if we changed the PMC link to a plain link, it would no longer be consistent with the way |doi=, |pmid=, |isbn=, |issn=, |bibcode=, etc are rendered. Boghog (talk) 09:34, 14 April 2017 (UTC)

I think most readers do not care about what PMC is. They just want to read their article. When we use |url=, we don't put a link to the Wikipedia article for the website, and that's fine! As far as I know, Wikipedia is the only website with this weird convention. Citation templates are meant to refer to a source, not to give a lecture on the IT infrastructure of scholarly communications, especially when it comes to the cost of a painful redundancy like "PMC PMC1234". − Pintoch (talk) 12:27, 14 April 2017 (UTC)

Wikipedia is also designed to be read by people not familiar with academia, and students that are yet to become familiar with the bibliographic databases of their fields. We have different needs and aims than professional journals. Also, there is no PMC PMC1234 redundancy, right now we render PMC 012345. There might be a case for rendering PMCID: PMC012345 however. I don't particular like it, but it is the 'official' way of doing things.Headbomb {t · c · p · b} 12:41, 14 April 2017 (UTC)

(edit conflict) I completely agree that writing PMC twice is redundant. Boghog (talk) 12:45, 14 April 2017 (UTC)

No one has proposed to write PMC twice. Stop pretending this is even on the table. Headbomb {t · c · p · b} 12:47, 14 April 2017 (UTC)

So do you agree that adopting the full NIH recommendation (PMCID: PMC012345) which is redundant is not on the table? Furthermore, there is very little difference between writing "PMC 012345" as is currently done versus "PMC012345" except that the former is more legible. Boghog (talk) 13:18, 14 April 2017 (UTC)

The NIH format is on the table. PMC PMC0123456, however, is not. Headbomb {t · c · p · b} 13:21, 14 April 2017 (UTC)

No one has proposed to write PMC twice. The NIH format writes PMC twice (PMCID: PMC012345). Boghog (talk) 13:29, 14 April 2017 (UTC)

Yes, and that is their legit, official format [name of identifier] [actual identifier], quite clearly distinct from one another, not PMC PMC0123465 as you have been arguing above. We do this for most of our identifiers, e.g arXiv:1301.1234, ISSN 1927-226X, PMID 12346, etc. We can choose to deviate from the official format if we want, but this would be a choice and we'd need a strong consensus to do so. Headbomb {t · c · p · b} 15:22, 14 April 2017 (UTC)

Official or not, "PMCID: PMC0123465" is every bit as redundant as "PMC: PMC0123465". As argued below, we have zero obligation to follow the NIH recommendations. Quite to the contrary, it would take a strong consensus to overturn the long standing convention in how Wikipedia handles PMC identifiers. This is problem that did not exist until the folks that maintain Citoid decided to take a rigid interpretation of the NIH guidelines that do not apply to Wikipedia. Finally, none of the other identifiers that you mention contain a similar redundancy including and most notably |pmid=. Boghog (talk) 16:21, 14 April 2017 (UTC)

I agree. If you want to accept |pmc=pmc1234 (or |pmcid=pmc1234 if you prefer) that's fine, but please make sure the string "PMC" does not appear twice in the output (just to make things clear: in "PMCID: PMC1234", there are two occurrences of the "PMC" string). − Pintoch (talk) 17:58, 14 April 2017 (UTC)

It is important to note that the scope of the NIH guideline is limited to Anyone submitting an application, proposal or report to the NIH. Wikipedia is not submitting anything to the NIH. The guideline is silent about how references or links to PMC are formatted in journals. This is a decision made by individual journals, not the NIH. Likewise Wikipedia is not bound by NIH guidelines. Boghog (talk) 09:45, 14 April 2017 (UTC)

Absolutely. If you intend to follow the guidelines of all the organizations that issue the identifiers in use on Wikipedia, then you should also change doi:10.5468/ogs.2016.59.1.1 to doi:https://doi.org/10.5468/ogs.2016.59.1.1, because Crossref recommends to write DOIs as URLs! I am sure this is going to be a very popular change. No redundancy at all! − Pintoch (talk) 17:58, 14 April 2017 (UTC)

Proposal: silently drop "PMC" from identifier

In the interest of maintaining our citation style while allowing editors to add PMC identifiers that are technically correct, and in the interest of avoiding redundancy, I propose the following change, if it is technically possible:

• Allow identifiers of the form |pmc=1234567 and |pmc=PMC1234567 and |pmc=pmc1234567.
• If "PMC" is present in the identifier, silently drop it during rendering, and render the identifier as we currently do: PMC 1234567.
• Run the identifier validity check on the numeric portion of the identifier only. – Jonesey95 (talk) 21:09, 14 April 2017 (UTC)

I support this proposal. − Pintoch (talk) 21:12, 14 April 2017 (UTC)

This has already been done in the sandbox. I made that change because cs1|2 has a long-standing 'style' (if you will) that, in the live version of the module, is being broken in templates authored by citoid. If the proposal is to 'formalize' the acceptance of that change to the module, meh, I'm indifferent. If the purpose is to get Editors Headbomb and Boghog to put a cork in it, then I wholeheartedly support the proposal. I will note that the change to the module isn't quite silent; there is code that adds a maintenance category for templates that include a 'pmc' prefix in the parameter value.

—Trappist the monk (talk) 21:44, 14 April 2017 (UTC)

You're proposing to drop the identier name / keep the same rendering, not proposing to drop the PMC in the identifer. That proposal would be either rendering it as PMCID 01234 or simply 01234. Neither of which are acceptable.

I support keeping the same rendering FWIW. But let's not falsely label this as "dropping the pmc from the identifier". Headbomb {t · c · p · b} 22:51, 14 April 2017 (UTC)

Headbomb, we know (or at least I think) you understand what is meant here, so please let us not dance on the head of a pin about language. What Jonesey95 is proposing, and what is currently implemented, is to convert identifiers input as |pmc=PMC12345 back to |pmc=12345 internally, and then display it as usual. In that sense, it is correct to say that the code "drops the pmc from the identifier" (even if "PMC: " is prepended afterwards). By doing so it keeps the rendered version unchanged. I think the description above is crystal clear for anyone familiar with CS1, which is your case. − Pintoch (talk) 00:05, 15 April 2017 (UTC)

I support Jonesey's pragmatic proposal (and Trappist's sandbox implementation). Boghog (talk) 05:36, 15 April 2017 (UTC)

Discussion seems to have stalled. Shall I make the change then ? —TheDJ (talk • contribs) 08:14, 24 April 2017 (UTC)

No. This change will be part of the update.

—Trappist the monk (talk) 08:50, 24 April 2017 (UTC)

Minor tweak to doi.org links

https://www.crossref.org/display-guidelines/ suggests that we link to https://doi.org/10.nnnn/xxx.xxx, dropping the "dx." portion of the fully qualified domain name. I suggest that we make this minor, non-urgent change to the Module sandbox after this weekend's update. – Jonesey95 (talk) 22:28, 25 April 2017 (UTC)

Why not now? No reason to delay this till the next update.Headbomb {t · c · p · b} 05:13, 26 April 2017 (UTC)

Done. Headbomb {t · c · p · b} 05:22, 26 April 2017 (UTC)

I suggested doing it later because we should be in a freeze period before deployment, we haven't done any testing yet, and this module is used in millions of pages. Also, the change is not urgent. – Jonesey95 (talk) 13:38, 26 April 2017 (UTC)

OTOH, the change is simple and we have no evidence now nor will have any in the immediate future to suggest that doi.org is worse than dx.doi.org without such testing as is untenable. I see no problem with this change here. --Izno (talk) 13:46, 26 April 2017 (UTC)

There's many a slip 'twixt the cup and the lip. EEng 13:49, 26 April 2017 (UTC)

Reprint

How to note a reprint? bkb (talk) 08:44, 17 April 2017 (UTC)

Is it important to do so? Does the rest of the bibliographic detail not sufficiently WP:SAYWHEREYOUGOTIT? I have seen reprints noted in either of |edition= or |type=.

—Trappist the monk (talk) 10:50, 17 April 2017 (UTC)

|edition=Reprint usually. Headbomb {t · c · p · b} 11:23, 17 April 2017 (UTC)

I would not mention that a book was a reprint unless

1. it was reprinted by a different publisher
2. it was described as a corrected reprinting, or similar, or
3. the page numbers of the reprint don't match the page numbers of the earlier version. Jc3s5h (talk) 14:32, 17 April 2017 (UTC)

Sometimes knowing the print run is important to identify a particular issue of a book, as errors are sometimes silently fixed. I have also seen other changes with reprints, different covers, updated prefaces, changed prices, and sometimes even without changing the ISBN. Therefore, I proposed to introduce a new parameter like |print-run= a while ago. This would allow editors to specify the extra info where they see fit without overloading the |edition= parameter. For now, the template could just concatenate the values of both parameters for output, but keeping it in separate parameters would improve machine readability and allow us to adjust the output format depending on the target environment anytime later on (f.e. ignore the |print-run= parameter for meta data schemes not supporting it).

--Matthiaspaul (talk) 23:29, 26 April 2017 (UTC)

Month–month, year and html-encoded en-dashes

The CS1 templates are happy with |date=July–August 2008 but give warnings for the should-be-identical |date=July–August 2008. There are some editors out there (not me, but others I've interacted with) who insist that spelling out the – rather than using an en-dash character is necessary to make the type of dash more visible to editors reading the source. Is there some way to make the citation templates accept input in this format? —David Eppstein (talk) 19:49, 16 April 2017 (UTC)

I would guess that this is in the realm of possible, and a simply transform to the Unicode variant can take care of it for the metadata. --Izno (talk) 21:09, 16 April 2017 (UTC)

More broadly, I'm sick of hearing that symbolics like –, & , {{ndash}}, and {{nbsp}} "pollute the COinS metadata" (as if anyone cared about that anyway). Postprocess the COinS data to regularize that kind of thing and stop expecting editors to remember a bunch if special restrictions. EEng 21:29, 16 April 2017 (UTC)

I use {{en dash}}. It is safe and error free. I generally agree that editors should not be limited by badly implemented interfaces foreign to the Wikipedia's citation system. 64.134.240.62 (talk) 21:39, 16 April 2017 (UTC)

That does seem to work within the CS1 templates; thanks! It also may have the helpful side affect of being less likely to be removed by AWB-enthusiasts. —David Eppstein (talk) 21:53, 16 April 2017 (UTC)

You're welcome. Notice that {{spaced en dash}} which is appropriate in some date citations is hatnoted as a no-no due to COINS limitations. 64.134.240.62 (talk) 22:05, 16 April 2017 (UTC)

Wait a second. I've been told many times that I can't use {{ndash}} either. Any why is {{spaced ndash}} a "no-no"? What exactly are these COINS limitations? I've been asking for years and never get an answer. EEng 14:35, 20 April 2017 (UTC)

{{spaced ndash}} resolves to:

 – 

Before it is handed to a cs1|2 template, this date example:

|date=Winter 1992{{spaced ndash}}Spring 1993

resolves to:

Winter 1992 – Spring 1993

The cs1|2 template then percent encodes each of those characters for COinS:

Winter+1992%26nbsp%3B%26ndash%3B%26%2332%3BSpring+1993

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

The main thing is to format citations with ease, and in such a way that the result is clear to readers. I would not at all worry about COinS compatibility. It is by no means a (1) bug-free or (2) universal, standard. Granted that some of the inconsistencies stem from its reliance on OpenURL, which itself can be problematic. But Wikipedia citations do not have to be compatible with any foreign interface. It is up to those that design and implement such interfaces to make sure their middleware works correctly with its target platforms. We are talking about a 10-year+ effort that, when it comes to Wikipedia, cannot resolve basic HTML entities. That is why {{spaced en dash}} (a correct implementation) throws a hiccup. {{en dash}} doesn't because it utilizes the plain glyph. Symbolically/programmatically, {{en dash}} is inferior: the rendering of glyphs is not uniform. 65.88.88.127 (talk) 20:38, 20 April 2017 (UTC)

I'm having trouble making sense of this:

That is why {{spaced en dash}} (a correct implementation) throws a hiccup. {{en dash}} doesn't because it utilizes the plain glyph. Symbolically/programmatically, {{en dash}} is inferior: the rendering of glyphs is not uniform.

especially that last bit: the rendering of glyphs is not uniform.

If I write:

{{spaced en dash}}{{en dash}}

I get:

 – –

If you look in this page's source, this:

 – –

has been translated to:

 – –

Those two en dashes are the same character: U+2013. It would appear that the rendering is, for this particular example, uniform.

—Trappist the monk (talk) 10:25, 23 April 2017 (UTC)

"Symbolically/programmatically". Because right now there is no guarantee that a formatting character will display uniformly across platforms, the proper way to input the character is through its universal encoding. The template {{spaced en dash}} does this. {{en dash}} doesn't. In the latter case, editors have no certain way of knowing whether the writer intended an en dash or any other similar formatting character. Not only are there many different dashes, but they also may display differently, depending on platform. 72.43.99.138 (talk) 14:20, 23 April 2017 (UTC)

I don't think that I buy this. Wikipedia serves html5 using character set UTF-8. In html5, – maps to the unicode character U+2013 and has done since html 4 and perhaps earlier. See html5 named character references (a rather awful table – here's a friendlier version). For the purposes of display, there is no distinction between a source that uses – or – or the en dash glyph. The browser will render any of these characters in exactly the same way according to the specified font (if it doesn't then the browser is fundamentally flawed).

I have some sympathy for the complaint that the various dashes look rather similar in the wikitext edit box but that is the fault of the font, not of the html source.

—Trappist the monk (talk) 11:17, 25 April 2017 (UTC)

For the purposes of your display. There is no guarantee that what appears to you as a particular formatting character will do so across others' displays, browsers, scripting frameworks, operating systems, or hardware. There is nothing to buy here. The proper way to program this is to enter the code which unambiguously stands for the character you intend. But the point is not about bad/lazy template authoring. This tangent is a byproduct of the badly-written COinS interface, which forces these contortions. 72.43.99.138 (talk) 13:48, 25 April 2017 (UTC)

Let me repeat myself: Wikipedia serves html5 using character set UTF-8. In html5, – maps to the unicode character U+2013. Because – is defined as U+2013, any browser compliant with html4 and later will render – and U+2013 in the same way. How you see that character is determined by your chosen font. I can set my browser to render all text in a serif font which may display an en dash differently from the way it would be display were I to set my browser to render all text with a sanserif font. At the source level, there is no ambiguity because – = U+2013.

I have written nothing regarding bad/lazy template authoring. I don't understand why you have made that statement.

That COinS is old and is limited is not a point of contention. I have, in the past, collected as much of the metadata code in a single place as I could so that we might, if ever we take the decision to do so, emit metadata according to some other standard and the effort required is mostly the writing of a module to replace Module:Citation/CS1/COinS. Propose a better metadata standard.

—Trappist the monk (talk) 10:23, 27 April 2017 (UTC)

First, get rid of artificial limitations on users of these templates, that are imposed by inadequate interfaces. Secondly, we don't have to propose any metadata standard. Wikipedia citations don't exist to play nice with reference software or bibliographic systems. They are required in order to verify anonymous/pseudonymous claims. If you want to interface with foreign systems do it in a way that is totally transparent to end-users. Otherwise this may well add undue burden to the creation of citations using these templates. So this may be a potential obstacle to verification.

The lazy/bad template authoring comment was referring to {{en dash}}. Basically a scripted (as in template script) glyph. Why even bother? Either use the bare symbol or script it properly with its encoding. By the way, variable user font selection is to be anticipated, and one more reason to use the proper encoding so that later editors know what is expected. And it is simply not true that browsers or platforms interpret the standards uniformly. I am sure you have seen how an em dash displays on say, MacOS 10.x (Safari). 72.43.99.146 (talk) 13:21, 27 April 2017 (UTC)

So all these years busybodies have been giving people a hard time for using templates in citation values for nothing? I'm shocked. EEng 01:04, 22 April 2017 (UTC)

Location for cite speech ambiguous

I'm looking at Template:Cite speech/doc and it seems to me that the location parameter is ambiguous in meaning. I believe Module:Citation/CS1 understands it as the place of publication, but one of the examples given is this:

Last, First (April 1, 2000). Title (Speech). Event. Location.

On the one hand, I suppose I'm requesting that the documentation be clarified. On the other, I wonder if Module:Citation/CS1 needs to be updated to be able to include the actual location of the speech and event, which seems like an appropriate thing to include in a citation for an unpublished speech, if not for all speeches. Sondra.kinsey (talk) 23:09, 28 April 2017 (UTC) PS. Please use {{reply to}}; I don't watch this page.

Unpublished sources, including speeches, may not be cited. Published speeches (in any medium) should follow the style guideline, which considers "location" as preferably, the (speech) publisher's location, and as a secondary choice the location where the work (speech) was produced. 64.134.66.143 (talk) 12:12, 29 April 2017 (UTC)

It might not be documented (very well), but there is both a |publication-place= and a |location=. Cite speech might reasonably make use of both. That said, you should WP:SAYWHEREYOUGOTIT--so I am not entirely sure about your use case. Maybe you can provide the specific citation you have in mind. --Izno (talk) 13:08, 29 April 2017 (UTC)

CS1 errors in the "How the templates work" section

Presumably, the CS1 errors in the "How the templates work" section were unintended and undesired. Here, I've removed the |date=Date part of the wikitext for the example citations to get rid of them. Improve as needed, please. Wtmitchell (talk) (earlier Boracay Bill) 02:24, 30 April 2017 (UTC)

There were actually intentional, and it would be unfortunate to completely remove any date indication there because the date does shift positions and formatting depending on the presence or absence of author parameters. So to show something, I used |date=n.d. and added a note below the examples. That may need refinement though. Imzadi 1979 → 05:13, 30 April 2017 (UTC)

Next time you might want to use a <! -- comment --> to explain. EEng 05:48, 30 April 2017 (UTC)

lingering deprecated parameters

This discussion begat this series of edits to Module:Citation/CS1/Whitelist/sandbox wherein |ARXIV= and |BIBCODE= were deprecated. Those changes went live on 29 October 2016. In the interim I think that support for the now long-deprecated parameters should have been removed from the whitelist sandbox and from Module:Citation/CS1/Configuration/sandbox. That did not happen.

Rather than add these parameters to the help documentation (they never were) and wait for the next update and because they do not appear be in use anywhere (none were in Category:Pages containing cite templates with deprecated parameters at the time that it was emptied), without objection, tomorrow I shall mark them as unsupported in Module:Citation/CS1/Whitelist and Module:Citation/CS1/Configuration.

We still have |version= marked as deprecated when it is used with {{cite arxiv}} (deprecated since 25 July 2015). This too, I shall mark as unsupported in Module:Citation/CS1/Whitelist. More complex changes to Module:Citation/CS1 are also needed but can be deferred to the next update.

—Trappist the monk (talk) 13:03, 29 April 2017 (UTC)

Great! I support all these changes. Thank you so much for your work. − Pintoch (talk) 13:40, 29 April 2017 (UTC)

Done. The changes to Module:Citation/CS1 were not so complex as I imagined so that has been done also.

—Trappist the monk (talk) 09:44, 30 April 2017 (UTC)

Remove category "CS1 errors: coauthors without author"

Now that |coauthors= is unsupported, we should be able to delete Category:CS1 errors: coauthors without author, I believe. Do we need code changes to the module, or can we just delete the category? – Jonesey95 (talk) 13:38, 30 April 2017 (UTC)

redlink now.

—Trappist the monk (talk) 14:00, 30 April 2017 (UTC)

Perfect. Thanks. – Jonesey95 (talk) 14:38, 30 April 2017 (UTC)

Parameters first1 on Commons template

The template commons:Template:Cite_journal on Wikimedia Commons does not have implemented parameters first1= |last1= |first2= |last2= etc. commons:Template talk:Cite journal#Parameters. Could you improve it, please? This is crucial for proper referencing of images. Thanks. --Snek01 (talk) 18:51, 1 May 2017 (UTC)

What Commons do with their templates is, broadly speaking, not our concern. Have you raised the issue at c:Template talk:Cite journal? --Redrose64 🌹 (talk) 20:55, 1 May 2017 (UTC)

Yes, see the link above. --Snek01 (talk) 21:53, 1 May 2017 (UTC)

metadata bug

There is a metadata bug. Somehow, some of the multiple bytes of unicode characters outside of the ascii character set are not all included in the metadata:

{{cite book |title=Я}}

produces this metadata for the title:

&rft.btitle=%D0%AF – correct

and:

{{cite book |title=ש}}

&rft.btitle=%D7%A9 – correct

but:

{{cite book |title=魂}}

&rft.btitle=%E9%82 – should be: %E9%AD%82

and:

{{cite book |title=–}}

&rft.btitle=%93 – should be: %E2%80%93

From these simple examples, it would appear that something is buggering up three-byte unicode percent encoding. This problem was apparently noticed just after the 29–30 April 2017 update to the live module suite. I am at a loss to explain this problem as a result of the changes that were incorporated in the update. So, I have reverted the sandboxen to the last live version before the update. Let me repeat that:

the current sandboxen DO NOT currently contain the next version of the live CS1 modules. Except in search of an answer to this issue, changes should not be made to the CS1 modules.

After reverting to the last live version, the simple tests above produce the same results.

The modules use the function mw.uri.encode() to percent-encode metadata and also to encode identifiers like |doi=. If I make up a doi with a character that doesn't work in the metadata, the doi link is encoded correctly:

{{cite book/new |title=Title |doi=10.1234/.魂}}

//dx.doi.org/10.1234%2F.%E9%AD%82

From all of this, I know that the problem has been with us for some time and that the problem appears to be confined to the metadata. Now it is just a matter of locating it.

—Trappist the monk (talk) 15:19, 2 May 2017 (UTC)

fixed. This line:

value = value:gsub ('[\226\128\141\226\128\139\194\173]', '')

changed to this:

value = mw.ustring.gsub (value, '[\226\128\141\226\128\139\194\173]', '');

The purpose of this line is to remove invisible characters zero-width joiner and zero-width space, and the soft hyphen because these characters are pointless in the metadata. Because these characters are invisible, the code writes out their individual decimal byte values: \226\128\141 for zero-width joiner, etc.

The problem arises because value:gsub() operates on bytes, not characters. When value is an en dash, its byte values are \226\128\93. In the original version, value:gsub() finds both the \226 and the \128 bytes and removes them leaving the \147 which is later percent encoded to %93. Similarly, 魂 has byte values of \233\173\130, value:gsub() finds and removes the \173 leaving behind \233\130 which percent encodes to %E9%82.

The new version treats the characters as characters.

I have fixed this bug in the live version and restored the sandboxen.

{{cite book |title=魂}}

'"`UNIQ--templatestyles-00000027-QINU`"'<cite class="citation book cs1">''魂''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%E9%AD%82&rfr_id=info%3Asid%2Fen.wiki.x.io%3AHelp+talk%3ACitation+Style+1%2FArchive+33" class="Z3988"></span>

—Trappist the monk (talk) 17:06, 2 May 2017 (UTC)

Good catch. Checking the modules for other unicode-related possible ommissions/incompatibilities might be a good idea. 65.88.88.127 (talk) 18:25, 2 May 2017 (UTC)

Two things. The first, boxes is the plural of box, not boxen. You may enjoy using non-standard plurals, but this is confusing to people, especially those that wouldn't know oxen is the plural of ox. The second, there are lots of 'value:gsub' around that line of code you've updated. Should those be updated as well? Headbomb {t · c · p · b} 18:31, 2 May 2017 (UTC)

The lines of code most similar to the offending line are:

1. value = value:gsub ('\226\128\138', ' ');
2. value = value:gsub ('[\009\010\013]', ' ');

In the first of these the pattern is a string of bytes so value must match exactly. In the second, like regex, the pattern is a set of three individual bytes so will match with any of the three single-byte characters horizontal tab, line feed, or carriage return.

—Trappist the monk (talk) 19:35, 2 May 2017 (UTC)

Boxen is a harmless and amusing hacker in-joke; I have no problem with it here (on a talk page) although I wouldn't use it in article-space of course. And thanks, Trappist the monk, for catching and fixing this! —David Eppstein (talk) 18:42, 2 May 2017 (UTC)

Credit for the discovery of this error belongs to Editor Silas S. Brown who reported it here.

—Trappist the monk (talk) 19:35, 2 May 2017 (UTC)

Re: "boxen". Yes, a hacker in-joke, but it has appeared in a headline in a reliable source at least once. It appears in article space with an explanation in a few places, and there's Pizza boxen (a redirect); I agree with David Eppstein that it should not be used casually in article space. – Jonesey95 (talk) 20:22, 2 May 2017 (UTC)

Table overflow bug

When User:SpikeToronto recently made this edit and many similar ones, trying to improve the table format for iPads, it actually broke the format for an ordinary Chrome browser on a Windows laptop. For example, unless the browser window is extremely wide, the right side of the table in Template:Cite book/doc#TemplateData gets truncated, cutting off words and the column-sort arrows, with no horizontal scrollbar to reach the truncated content. Is there a way to make these tables work properly on both types of devices? —Patrug (talk) 07:22, 3 May 2017 (UTC)

This is not a cs1|2 bug. That TemplateData table is imposed on us by the developers of Visual editor. If Editor SpikeToronto's edit doesn't work here then likely it doesn't work elsewhere. You might try discussing this issue with Editor Bermicourt who is apparently the author of {{TemplateData}} which, I gather has the job of rendering the TemplateData table.

—Trappist the monk (talk) 08:29, 3 May 2017 (UTC)

Good info, thanks. Let's see if SpikeToronto can shed any light on the situation, and why these edits were "required" for iPads. —Patrug (talk) 09:58, 3 May 2017 (UTC)

Not so good info, actually. {{TemplateData}} doesn't have the job of rendering the TemplateData table.

—Trappist the monk (talk) 10:12, 3 May 2017 (UTC)

One observation: there is a wider problem with the rendering of tables on mobile devices, so this may not even be strictly a <templatedata> issue. My past experience has been that you have to tap/drag at the screen edge to see the hidden info. Other than that, as Trappist mentioned, this is not the right forum. 65.88.88.126 (talk) 15:49, 3 May 2017 (UTC)

Patrug, WP:VPT is probably a better forum for this question. I get the same results on Chrome for Windows, FWIW. – Jonesey95 (talk) 17:07, 3 May 2017 (UTC)

|title=Archived copy

Can a new maintenance category be created (and coded into Module:citation/CS1) for when Archived copy is used as a title in a cite-template? Currently we have 38 000+ articles (insource:/\|title\=Archived copy/), and I bet that not a single one of them should use that as a title. (t) Josve05a (c) 14:48, 29 April 2017 (UTC)

And another could be finding |work=Wayback Machine & |work=Wayback Machine --(t) Josve05a (c) 15:16, 29 April 2017 (UTC)

This looks like it was caused by IABot. @Cyberpower678: Can you let us know whether it's still occurring, whether it's a bug in the bot or something wrong in the IA API, and whether it might be possible to get IABot re-run on these articles? --Izno (talk) 17:09, 3 May 2017 (UTC)

Yes, it is IABot that is the culprit in this case. The reason here though is deeper: IABot changed the citation format of the references in question from free-form to scripted (templated). Since the "title" in free-form citations is not easily parsed by machines, it made the default substitution |title=Archived copy. 72.43.99.146 (talk) 12:44, 4 May 2017 (UTC)

Volume and page parameters being separated in cite encyclopedia

Hi, I was wondering why the volume and page numbers were separated so much in Template:Cite encyclopedia? Right now the volume separated from the pages by the edition, publishing location, and publishing house. Should I be using |at= instead so that the volume of the encyclopedia immediately precedes the page numbers, as in Chicago or APA?

Because right now I think it's unclear to have the volume so far from the pages as in:

Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{cite encyclopedia}}: |last1= has generic name (help)

I would expect it to be something like:

Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia (2nd ed.). City: Publishing House. Vol. 3, pp. 100–102. {{cite encyclopedia}}: |last1= has generic name (help)

Thanks. Umimmak (talk) 15:39, 8 May 2017 (UTC)

A primary goal when we integrated all of the old wikitext cs1|2 templates into the new Lua Module:Citation/CS1, was to make the new look like the old. Apparently we were successful with the |volume= / |page(s)= aspect of that integration for {{cite encyclopedia}}:

Cite encyclopedia comparison

Wikitext	{{cite encyclopedia|date=2017|edition=2nd|editor-first=E.|editor-last=Editor|encyclopedia=Title of Encyclopedia|first1=A.|last1=Author|location=City|pages=100–102|publisher=Publishing House|title=Entry|volume=3}}
Live	Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{cite encyclopedia}}: |last1= has generic name (help)
Sandbox	Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{cite encyclopedia}}: |last1= has generic name (help)

The rendering of {{cite encyclopedia}} looks much like the rendering of {{cite book}} given similar parameters:

{{cite book |last1=Author|first1=A.|date=2017|chapter=Chapter |title=Title of Book |edition=2nd|editor-last=Editor|editor-first=E.|volume=3|pages=100–102|publisher=Publishing House|location=City}}

Author, A. (2017). "Chapter". In Editor, E. (ed.). Title of Book. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{cite book}}: |last1= has generic name (help)

If you are concerned, you might research the issue in the archives of this talk page and the archives of the {{cite encyclopedia}} talk page. There may be something there that will explain why the original authors of {{cite encyclopedia}} did what they did. Or not.

Contructs like this:

|at=Vol. 3, {{pp.|100|102}}

are discouraged because it introduces volume information into an in-source element of the metadata.

—Trappist the monk (talk) 16:15, 8 May 2017 (UTC)

Can you explain what you mean by that last line, Trappist the monk? What's an "in-source element of the metadata," and why can't you have the volume information there? Thanks. Umimmak (talk) 16:32, 8 May 2017 (UTC)

These points:

1. it is the job of the cs1|2 templates to render citations in a consistent manner; cs1|2 have the responsibility for 'under the bonnet' formatting
2. cs1|2 templates produce COinS metadata so that readers may import citations from Wikipedia via special software
3. in-source means inside the source: page, paragraph number, etc

It is almost always unnecessary to add special formatting to a templated citation; if special formatting is needed, then the general purpose templates (as cs1|2 templates are) may not be appropriate to the circumstances, in which case, they should not be used and other solutions applied.

The cs1|2 parameters map to similarly named metadata keys. In this particular case, |page=, |pages=, and |at= are in-source location parameters; all map to a key called &rft.pages; volume information does not belong there. There is a cs1|2 parameter specially intended to hold volume information: |volume= which feeds &rft.volume.

—Trappist the monk (talk) 17:42, 8 May 2017 (UTC)

I would say Trappist the monk's comment about in-source location is rooted in the code used to implement the cite templates; the degree to which this applies to actual sources depend on the nature of the source. A particular edition of an encyclopedia is one source, just as all the CDs in a multi-CD music album constitute one source. Ordinarily, these things are all purchased and used together. A volume number is a means of finding the location in the single source, just like the page number. On the other hand, the seven volumes in the Harry Potter series are separate sources, because they were published at different times and are not usually purchased as a set. Jc3s5h (talk) 18:30, 8 May 2017 (UTC)

Yeah it seems like that volume number is sort of where it would be if it refers to the number within a book series, but as the volume number of a multi-volume work like an encyclopedia is necessary to figure out the location, I'd expect it to be with the other "in-source" parameter like |page=. Umimmak (talk) 20:35, 8 May 2017 (UTC)

How do I do multiple quotes

I recently had a FAR where a user pointed out I was using a Japanese book and that I needed to provide both the original Japanese prose of the book's information and the English translation. Would it be "quote=Japanese and trans_quote=English"? Regards,Tintor2 (talk) 00:08, 5 May 2017 (UTC)

I think that the method that you suggest is inconsistent with how cs1|2 handle translations in titles and chapters. Perhaps:

|quote=Japanese quote</q> <q>[English quote] – the </q> <q> are used here because the quotation marks around |quote= are formed that way

"Title" [Trans title]. Japanese quote. [English quote.]

—Trappist the monk (talk) 00:32, 5 May 2017 (UTC)

I'm giving it my first try here. Is it correct?Tintor2 (talk) 01:09, 5 May 2017 (UTC)

Mostly. The transition between the original language and the English translation should be:

... ています</q> <q>[Hoshino: Guess ...

The </q> following the original language quote closes the opening <q> provided by the template. Similarly, the <q> preceding the English translation matches the closing </q> provided by the template. And thus, all is in balance.

—Trappist the monk (talk) 10:13, 5 May 2017 (UTC)

Sorry, but that's quirky... Such tags should be dealt with by the template internally.

I too suggest(ed) to add a |trans-quote= parameter (some while ago). This would be following the basic principle to keep different types of contents in different parameters.

With two parameters |quote= and |trans-quote= we'd be free to change the output format whenever this might become necessary in the future, even depending on settings or target devices. We might even suppress the translation if it would not be desired in a certain context. Example:

... |quote=Japanese quote |trans-quote=English quote ...

for either

"Title" [Trans title]. "Japanese quote" "[English quote]"

or

"Title" [Trans title]. "Japanese quote [English quote]"

--Matthiaspaul (talk) 22:49, 5 May 2017 (UTC)

Neither the original text nor the translation really bear on the citation of the source. Where there is a comment on a source that should follow the citation. E..g.:

<ref>{{citation|...}}. "ています" is translated [by whom?] as "Hoshino: ...".</ref>

There's no need to introduce entirely extraneous material into the citation template. ~ J. Johnson (JJ) (talk) 23:54, 5 May 2017 (UTC)

I gave it a try but trans-quote is not working.Tintor2 (talk) 00:17, 6 May 2017 (UTC)

There is not |trans-quote= parameter which explains why it did not work.

—Trappist the monk (talk) 12:31, 6 May 2017 (UTC)

I think that Editor J. Johnson and I may actually be in agreement (at least partially) for once. I have never believed that source quotations belong in a citation. If it is appropriate to quote the source, then put the quote in the article and cite it. Additionally to this particular question, where does the translation come from? If it is from the cited source then there is no need for the Japanese version of the quotation. If it not from the cited source, then the questions of accuracy and reliability and verification come into play. I am minded of this because I recall that these translation questions were recently discussed, in particular about machine translation, but I don't remember where that discussion occurred.

—Trappist the monk (talk) 12:31, 6 May 2017 (UTC)

I agree putting a quotation inside a citation template is probably a bad idea. One reason it's a bad idea is quotations might need all kinds of special stuff to reproduce what's in the source, like a table for instance. Such complex markup would be very likely to break the citation template.

However, I disagree that a quote from a source should either be placed in the running text of the article, or omitted. Most citations in Wikipedia are in the form of an endnote. Endnotes are for details that distract from the point being made in the running text of the article. Such detailed digressions might very well need quotations from the source. Thus, there's nothing wrong with including quotes from the source in a footnote. Jc3s5h (talk) 12:54, 6 May 2017 (UTC)

I did not write that a source should either be placed in the running text of the article, or omitted; I made no mention of running text. Do not put words into my mouth that I have not spoken. By put the quote in the article and cite it, I simply meant that the quotation, if required, should be placed somewhere other than in the citation itself.

—Trappist the monk (talk) 13:44, 6 May 2017 (UTC)

Anyway, I got this comment here. The third opinion agreed.Tintor2 (talk) 14:22, 6 May 2017 (UTC)

It is not clear to me just what you mean by third opinion. Clarify?

—Trappist the monk (talk) 14:42, 6 May 2017 (UTC)

I was not sure about using both the Japanese original quote and English at the same time so I went to Wikipedia:Third opinion and asked the third opinion.Tintor2 (talk) 14:48, 6 May 2017 (UTC)

WhatamIdoing recently suggested a use for |quote= at WT:Verifiability#How does one transparently cite more than one part of an e-book in a single citation?: to provide a short piece of text that can be searched for to locate the section referenced in media such as certain e-books that do not have pagination or other in-source indices. But even that can be handled outside of the template. ~ J. Johnson (JJ) (talk) 20:27, 8 May 2017 (UTC)

Interesting. If possible ping me whatver happens. I still think the article I withdrew, Yu Kanda, could become a FA.Tintor2 (talk) 21:25, 8 May 2017 (UTC)

Convert some refbegin lists from : to * lists

Please see/join this discussion about a bot conversion of some existing reference lists making use of unordered lists (*) instead of definition lists (:). —TheDJ (talk • contribs) 14:07, 12 May 2017 (UTC)

Subtitle?

I can't see a field for a subtitle. Is this a deliberate policy decision or an omission? --Pfold (talk) 11:53, 6 May 2017 (UTC)

There is no |subtitle= parameter. Most often, if a subtitle is required, it is included in |title= set off from the main title with a colon:

|title=Main Title: Subtitle

I don't know if the lack of |subtitle= is a policy decision or an omission. You might troll through the archives of this page, the talk page archives of the individual templates before they were merged into this page, and the talk page archives for {{citation}}.

—Trappist the monk (talk) 12:15, 6 May 2017 (UTC)

I would consider it an omission as other Wikipedias do support a |sub-title= (or similar) parameter. I would welcome its introduction in the English Wikipedia as well. --Matthiaspaul (talk) 00:14, 14 May 2017 (UTC)

It would have several advantages:

• While sub-titles are informative and therefore desirable to be included, sometimes they are very long and some editors hesitate to include them in the title because long titles create a "sea of blue" when the title gets linked. Splitting the long part off into a sub-title and linking only the title would reduce this and therefore improve readability.
• Letting the template rather than the editor concat title and sub-title for display would help to create a consistent output format. Right now, all sorts of separators are used: ". ", ", ", ": ", " - ", "—", " > ", etc. If a separator is actually used in the publication and for some reason is important to reproduce, a |title-separator= parameter could be used to specify it, otherwise the template would default to some internal default like " - ".
• In some cases, there are multiple title links available through |title-link= and |url=. In this case, our templates throw an error message, as there is only one string to attach the link to. |sub-title= could help remedy this situation, as the second link could be attached to the sub-title then - not a perfect solution, but still better than having to append raw links after the citation.
• On small devices, sub-titles could be excluded from normal display in order to make better use of the available display space. Sub-titles could still be displayed in a smaller font or in a pop-up help bubble etc. On larger PCs monitors with enough display space available sub-titles could be displayed with the title as usual. There might be other reasons why only titles should be given in some situations (narrow tables, merging); in such scenarios it's good to have a well-defined break in the title instead of having to cut the title string at some arbitrary fixed position.

--Matthiaspaul (talk) 10:44, 14 May 2017 (UTC)

ISSN check fails on apparently valid ISSN?

• Gatialová, Eva (27 February 2016). "Ženská národná rada" [Women's National Council]. ASPEKTin (in Slovak). Bratislava, Slovakia: Záujmové združenie žien Aspekt. ISSN 1225-8982. Archived from the original on 4 May 2017. Retrieved 4 May 2017. {{cite journal}}: Check |issn= value (help); Invalid |ref=harv (help)

That ISSN resolves to the correct title, yet the template flags it as problematic. What gives? Headbomb {t · c · p · b} 12:04, 15 May 2017 (UTC)

The error message is correct. The issn uses an invalid check-digit:

1 × 8 + 2 × 7 + 2 × 6 + 5 × 5 + 8 × 4 + 9 × 3 + 8 × 2 =

8 + 14 + 12 + 25 + 32 + 27 + 16 = 134

134 ÷ 11 = 12 remainder 2

check digit = 11 − 2 = 9

{{issn|1225-8989}}

ISSN 1225-8989 (uses the same check code as cs1|2)

QED

—Trappist the monk (talk) 12:41, 15 May 2017 (UTC)

Yet it's been assigned, and resolves... How do we suppress the error display then? Because ISSN 1225-8989 is an entirely different publication. Headbomb {t · c · p · b} 12:53, 15 May 2017 (UTC)

Use OCLC 643237586 instead?

—Trappist the monk (talk) 14:56, 15 May 2017 (UTC)

That's not a solution to the issue though. How do we handle invalid checksum ISBNs that are nonetheless those actually assigned? We should handle invalid ISSNs the same way. Headbomb {t · c · p · b} 15:24, 15 May 2017 (UTC)

Access lock RFC follow up:

The visual design RFC for the access locks concluded with an essentially 50-50 split community on the colour of the "free with conditions" lock (yellow vs blue). This RFC is to investigate support for a third option (grey). Headbomb {t · c · p · b} 14:55, 22 April 2017 (UTC)

Options

The paste options were 1&2

1) Green/Yellow/Red: / /

People who supported this cited the intuitiveness of the traffic light colour scheme, people who opposed it mostly cited the yellow not being very yellow, and the colourblind-friendlier blue.

2) Green/Blue/Red: / /

People who supported this cited the yellow not being very yellow in the previous scheme, and the colourblind-friendlier blue. People who opposed this cited the lack of a recognizable colour scheme of any sort. It also tends to get lost in a sea of blue. This had marginally more support (1 more !vote out of 22 or so).

However, late in the RFC, an alternate colour scheme was proposed as an alternative and garnered some support, but it was too late in the RFC to be introduced an option. Let's consider it now.

3) Green/Grey/Red: / /

This has neither drawback of schemes 1 & 2. Green/Grey/Red is an intuitive colour scheme, is just as colourblind friendly as Green/Blue/Red, and doesn't get as lost in the sea of blue as the blue one does. I'd have included arguments against grey, but I know of none.

Basically, how this would look is something like

1. Romaine, M.; Zatz, S.; Brown, K.; Lundberg, G.D. (2009). "So long but not farewell: The Medscape Journal of Medicine (1999-2009)". Medscape Journal of Medicine. 11 (1): 33. Retrieved 21 February 2009.
2. Romaine, M.; Zatz, S.; Brown, K.; Lundberg, G.D. (2009). "So long but not farewell: The Medscape Journal of Medicine (1999-2009)". Medscape Journal of Medicine. 11 (1): 33. Retrieved 21 February 2009.
3. Romaine, M.; Zatz, S.; Brown, K.; Lundberg, G.D. (2009). "So long but not farewell: The Medscape Journal of Medicine (1999-2009)". Medscape Journal of Medicine. 11 (1): 33. Retrieved 21 February 2009.

!Vote

Support #3 as proposer. Headbomb {t · c · p · b} 14:55, 22 April 2017 (UTC)

Oppose all. See below. – Finnusertop (talk ⋅ contribs) 01:46, 6 May 2017 (UTC)

A pointless !vote, given that's not one of the options at the moment, which will mostly means blue will stay for now. Headbomb {t · c · p · b} 02:02, 6 May 2017 (UTC)

Discussion

I do not know whether this is the proper procedure, considering that the referenced RFC was submitted at a much better attended forum. At best, imo whatever discussion results here, should be used to stage a proper RFC at the proper forum. Especially since the original RFC seems inconclusive on the related issues. 65.88.88.126 (talk) 20:56, 22 April 2017 (UTC)

The former RFC also had a much wider scope. This is listed and advertised at both Wikipedia:Requests for comment/Wikipedia technical issues and templates and Wikipedia:Requests for comment/Wikipedia style and naming, as well as through the Wikipedia:Feedback request service. Feel free to post neutrally worded notices in other places you deem relevant. Headbomb {t · c · p · b} 21:42, 22 April 2017 (UTC)

Notifying WP:FRS isn't necessary, the presence of {{rfc}} attracts the attention of Legobot (talk · contribs) which (based upon its table of open RfCs) sends out the FRS messages to user talk pages. --Redrose64 🌹 (talk) 23:49, 22 April 2017 (UTC)

Hence why I said advertised through, not at. Headbomb {t · c · p · b} 23:58, 22 April 2017 (UTC)

My opinion: Regardless of which color you use for it, the middle symbol is unrecognizable as a lock or as anything else. Maybe it is a fountain with a two-tone base? Maybe it is a spray bottle? Maybe it is a necklace with a big pendant? It is just visual clutter rather than useful information. —David Eppstein (talk) 18:23, 23 April 2017 (UTC)

Well, that's the appearance that got settled on in that RFC. Personally I would have gone with this shape. But let's focus on the color for now, shall we? Headbomb {t · c · p · b} 19:04, 23 April 2017 (UTC)

The choices are puke, lost-in-a-sea-of-blue, or blander-than-bland. None are worth advocating. —David Eppstein (talk) 22:00, 23 April 2017 (UTC)

Lack of choice likely means keeping blue. Headbomb {t · c · p · b} 22:11, 23 April 2017 (UTC)

I have to agree with David Eppstein. None of these designs do their job particularly well and all are eyesores. – Finnusertop (talk ⋅ contribs) 01:46, 6 May 2017 (UTC)

I haven't actively followed the original discussions, but if those locks are difficult to distinguish or even to recognize as locks, have other possible lock shapes been investigated already? For example a more squarish shape for the body of the lock? Or differently styled keys instead of locks? --Matthiaspaul (talk) 16:35, 17 May 2017 (UTC)

@Matthiaspaul: Square locks can be confused with secure html locks. In my experience, no one I talked to IRL (about 6 people,including 2 color blind) finds the shape of the locks confusing, although the non-colorblind nearly always got confused by the blue because it doesn't convey "intermediate" as yellow does (the colorblind were conditioned to ignore color). Yellow was unanimously preferred by the non-colourblind, but they thought grey also worked. The colorblind didn't care either way. Headbomb {t · c · p · b} 16:51, 17 May 2017 (UTC)

ISBNs in mw:Citoid

Hey All; at the WMF we have been working with OCLC to make ISBN generated citations available, through using their ISBN database. We have deployed the feature on all language Wikipedias: you can learn more about it on the Wikimedia blog. Astinson (WMF) (talk) 19:29, 11 May 2017 (UTC)

How do we downtrammeled logged-in editors use this without switching to VE? EEng 19:46, 11 May 2017 (UTC)

@EEng: You are unable presently. If you don't want to visually edit, but are willing to stomach the same kinds of interfaces (and associated Javascript heaviness on edit), you should try the New wikitext mode--you can access the citation tools there. --Izno (talk) 20:34, 11 May 2017 (UTC)

(edit conflict)@EEng: The mw:2017_wikitext_editor supports this feature as well (I am editing in that editor right now, and use it for most of my non-content editing in my volunteer capacity. I am not sure if there are other gadgets/tools that support Citoid in the older Wikitext editor. @Whatamidoing (WMF): might know. Astinson (WMF) (talk) 20:43, 11 May 2017 (UTC)

Why can't you give us a {ISBN-to-citebook} template, so we can code something like {subst:ISBN-to-citebook|978-0399594496} and get the same result, without demeaning ourselves by using these toolbars and visual editing and other paraphernalia of the Wikiediting welfare state? This would often require a second edit to clean up what the subst returns, but I for one would be most happy to use facility like that. EEng 20:52, 11 May 2017 (UTC)

How about me, Astinson (WMF)? Can I have a bug report too? EEng 01:34, 12 May 2017 (UTC)

@Astinson (WMF): I note that the WikiEditor icw Reftoolbar (enabled by default for everyone on English Wikipedia) has supported using ISBNs to import reference information for years already now. However that is specific to English Wikipedia editors of course. —TheDJ (talk • contribs) 21:07, 12 May 2017 (UTC)

The what? Where would I find that? EEng 23:03, 12 May 2017 (UTC) (Repinging TheDJ EEng 13:20, 15 May 2017 (UTC))

If, at Special:Preferences#mw-prefsection-editing, you have checked Enable enhanced editing toolbar, in the source editor choose the Cite dropdown. From the Templates dropdown choose cite book and enter an isbn in the ISBN field and click the magnifying glass. Here's an isbn to try it with: 9783161484100

—Trappist the monk (talk) 14:21, 15 May 2017 (UTC)

@Astinson (WMF): The example citation on your blog post uses YYYY-MM-DD format for the publication date, while most citations on Wikipedia use Month DD, YYYY or DD Month YYYY depending on US/UK variations. To me this suggests that some of us are going to be forced by your change to spend a lot of time making the dates of references added by users of this tool more consistent with the other dates in our articles. Is there any way that you could detect the date format used by an article and use that, please? Also, it appears that for many books, you are using dates like 1993-01-01 where the "01-01" part has no actual meaning (the book was not actually published on January 1) but is instead just a default value for when the date is unknown. Is there some way of preventing your tool from inserting this fake data into our citations? —David Eppstein (talk) 20:28, 11 May 2017 (UTC)

@David Eppstein: You can use |df= for the first problem, if you don't simply want to use a script such as the one that Ohconfucius provides. The WMF developer team is unwilling to let us get the dates in the format we wish. As for the second problem, using ISO dates allows for ambiguity in the form of 1993-00-00 to indicate that the year is known but not the month nor day, as well as 1993-01-00 to indicate that year and month are known, but not the day--I do not know why they use 01 instead. (It impacts Wikidata too, but I haven't thought to comment there yet.) --Izno (talk) 20:32, 11 May 2017 (UTC)

(Erm, not quite right regarding the 0s, but the intent is similar: review ISO 8601#Calendar dates.) --Izno (talk) 20:39, 11 May 2017 (UTC)

1993-00-00 is clearly a nonsense date. But can we not instead use a |year= field, where only the 4-figure year is inserted? -- Ohc ^¡digame! 21:50, 11 May 2017 (UTC)

Tracked in Phabricator
Task T165116

@Ohconfucius, Izno, and David Eppstein: We filled at bug at phabricator:T165116. I agree: their are going to be very rare occasions when the precision of something tracked via an ISBN has a publication date more precise than a year. Astinson (WMF) (talk) 01:22, 12 May 2017 (UTC)

In the examples given at the blog, is ISBN 9783161484100. Follow that link through Special:BookSources to WorldCat. Several different titles apparently use that isbn. I would guess that sometimes WorldCat is correct and that this tool may return correct information. But I'm not holding my breath; I've seen a lot of strange stuff in WorldCat listings.

I also notice, as others have pointed out, that the date format is rather incorrect for books which, for the most part are year-only. Further, WorldCat and citoid don't seem to care about extraneous punctuation; Gallery has an extra trailing comma. The Boris citation left out |location=Ljubljana; the Gallery Citation left out both |location= and |publisher=.

Like so many 'magic' tools, I fear that editors will assume that whatever is returned by the tool, because it's a tool, must be correct. It came from a database, right? The machine got the data for me, right? It therefore must be correct, right? I think that there is too much weirdness in WorldCat (akin to the weirdness in Google Books metadata) to make this tool very reliable. Handy perhaps, for those who will massage what the tool returns, but detrimental to the project in the hands of lazy editors.

—Trappist the monk (talk) 00:46, 12 May 2017 (UTC)

It's unfortunate, then, that it is deployed only to the VE users and not to the users who can actually see the template coding to massage it. —David Eppstein (talk) 00:56, 12 May 2017 (UTC)

Change unfortunate to incompetent and I'll agree with you. I can't think of one thing WMF has done in the 9 years I've been editing that's actually made editing easier. Honestly and truly, the one best thing that's happened is the Thank feature. EEng 01:01, 12 May 2017 (UTC)

@EEng: The comms tech team and Cyberpower put together the magical archive every URL on a single page tool that just rolled out. You should try it. This diff was cathartic, to be honest. --Izno (talk) 02:21, 12 May 2017 (UTC)

Well, I tried it, but I can't get it to do anything other than produce some statistics on various articles. Is there some magic button that makes it do something. EEng 02:46, 12 May 2017 (UTC)

It should be noted that this functionality has been available in Reftoolbar for years now (also using worldcat). So it's not exactly that it wasn't available to users before (maybe a lot more hidden, but its there). And I find irony in the fact that we keep setting so much higher bars than we set for our own project. Apparently we are the only website in the world that should be allowed to have the occasional error in it's data. No. I see this as an opportunity to make sure data quality of worldcat and ourselves improves, so that better crossover knowledge and insight can be generated, be it within (meta:WikiCite) or outside of our movement. —TheDJ (talk • contribs) 21:07, 12 May 2017 (UTC)

Yes, I know. That tool is just as bad as the new tool because it relies on what WorldCat has in its database which doesn't appear to be curated very well. Here is what the old tool retrieved when given the same isbn as the blog's Gallery example:

{{cite book|last1=Maps|first1=Peekaboo|title=Berkeley, Oakland : Albany, Emeryville, Alameda, Kensington|date=2009|publisher=Peek A Boo Maps|location=[Berkeley?]|isbn=9783161484100|edition=1st ed.}}

Maps, Peekaboo (2009). Berkeley, Oakland : Albany, Emeryville, Alameda, Kensington (1st ed. ed.). [Berkeley?]: Peek A Boo Maps. ISBN 9783161484100. {{cite book}}: |edition= has extra text (help)

Here we have: publisher as author, uncertain location (but we did get that), malformed edition; but, date is in the proper form. Looking at the dates in the entries on that WorldCat page, there are a variety of year styles; some are plain years: 2013; some are bracketed: [2016]; some include the copyright mark: ©2016, some have combinations of these three, which to choose?

Certainly, both tools cannot fix bad data. Maybe they can be made to be more clever in how they handle multiple different author, and multiple different title returns from the data base using the same isbn key. Still the basic and enduring problem is dubious data fetched by the 'magic', officially sanctioned, tool so it must be right, right?

—Trappist the monk (talk) 21:59, 12 May 2017 (UTC)

Perhaps a new parameter for Citoid to spit out when it is run on a reference (spitball name: |citoid=) which when equal to oclc, creates a green maintenance category message with some text of the sort: "CS1 maintenance: Citations imported from OCLC", if we believe that OCLC is so poor a quality of reference and that no-one will go back to fiddle with parameters. For reference, I know I use Citoid now for other websites and its hit-or-miss-enough in general such that I always check the imported citation, so I'm not sure if such a parameter is even necessary, since I would guess most others who use the service have a similar workflow. --Izno (talk) 22:06, 12 May 2017 (UTC)

So let's see:

Badly implemented (the date issue), also limiting editor choice

Contravenes established Wikipedia content guidelines (WP:CITEVAR) by limiting the citations to Style 1, also misleading by not pointing this out. This is a problem with Citoid documentation, and examples, in general.

May possibly result in ambiguous citations that editors may accept at face value as correct.

Conclusion: at present, nothing to see here.

72.43.99.146 (talk) 13:50, 12 May 2017 (UTC)

On a related issue, Mediawiki's refusal to use any date format other than YYYY-MM-DD in their cites (because they don't want to go through the hassle of full internationalization): in response to this, we could always be passive-aggressive about it and modify the cite templates to put up big red edit-time warnings when they see dates in this format in the date field (not the accessdate where they are ok): "Warning: Numeric date format detected. Please convert all dates to the prevailing style of the article." Because unless the users of the citoid template see it as not properly working, they won't notice the work it causes the rest of us and won't be motivated to do anything about the problem. —David Eppstein (talk) 16:30, 12 May 2017 (UTC)

Tracked in Phabricator
Task T132308

This silly date bug is tracked at T132308. The bug above has been closed as a duplicate of T132308, which was the same bug submitted earlier. It's hard to understand why this tool was rolled out with this bug unfixed; the results of the bug are even prominently featured in step 6 of the demonstration in the blog post linked above. The explanation for why it hasn't been fixed is unpersuasive at best. I do not understand why WMF puts its credibility on the line by being in the business of automating the addition of untrue data to Wikipedia. – Jonesey95 (talk) 17:52, 12 May 2017 (UTC)

Hey all, brief update: User:Mvolz (WMF) has pushed a fixed for the polluted year-level accurate-date issue in the ISBN generator, and is looking into a way to generate better human-readable dates via Citoid: https://phabricator.wikimedia.org/T132308 . Thank you for all the feedback on the bug, and it is helping generate ways to deliver a better date format to each Wiki. Continue giving feedback on phabricator as patches get published. Astinson (WMF) (talk) 14:24, 18 May 2017 (UTC)

License information

For some reason I was under the impression that the "cite journal" would accept a "license" parameter where one could indicate, e.g., "CC BY". I do not see it. Is there any (other?) way to indicate this? — fnielsen (talk) 12:39, 20 May 2017 (UTC)

Recent discussion on the topic of a license parameter is here.

—Trappist the monk (talk) 12:46, 20 May 2017 (UTC)

edtf date formats as cs1|2 date parameter values

Related to the discussions at Help_talk:Citation_Style_1#ISBNs_in_mw:Citoid and T132308.

Because WP:DATE does not allow year initial numeric dates in the form YYYY-MM but does allow YYYY–YY (with an en dash), and because cs1|2 emits an error when the MM or YY portion of those dates is in the range 00–12 inclusive, and because citoid needs to be able to transfer dates to all of the different language wikis, it has been suggested that citoid use the Extended Date/Time Format (EDTF). A draft of the standard is here.

For us, the immediate issue is the YYYY-xx date form. EDTF provides an alternate way to encode that kind of date. Similar in form to YYYY-MM-DD, EDTF allows for portions of the date string to be declared as 'unspecified'. When citoid needs to send en.wiki a month and year date, it can take the form |date=YYYY-MM-uu. That date format would surely violate WP:DATE so needs to be transformed into a more appropriate form. I have hacked the module sandbox to accept and transform dates that are provided in this style:

{{cite book/new |title=Title |date=2000-06-uu}}

Title. 2000-06-uu. {{cite book}}: Check date values in: |date= (help)

Similar to the transformations preformed for |df= and for auto-changing hypens to dashes, if there are any date errors in the citation, even in unrelated parameters, the module will not do any transformations. Here, using the same format for |access-date=, causes an error because |access-date= requires a day:

{{cite web/new |url=//example.com |title=Title |date=2000-06-uu |access-date=2017-05-uu}}

"Title". 2000-06-uu. Retrieved 2017-05-uu. {{cite web}}: Check date values in: |access-date= and |date= (help)

—Trappist the monk (talk) 16:45, 18 May 2017 (UTC)

That's all well & good, but I don't think the problem here is WP:DATE. After all, that is just a style guideline, so theoretically any hack is acceptable if the result conforms to the style. I think there should be an effort to integrate EDTF as a native format in MW. If this is to be a universal biblio standard, surely WMF should take a proactive role. 107.19.188.204 (talk) 22:39, 18 May 2017 (UTC)

EDTF isn't meant to be a "universal biblio standard". It is meant to trim out the less useful features of ISO 8601 (in that sense it's a profile) and to provide some extensions for things like uncertainty and seasons. One thing that hasn't been extended is the calendar; like ISO 8601, EDTF only supports the Gregorian calendar. That makes it ok for recently published works, but it isn't suitable for older works with publication dates stated in the Julian calendar. Nor would it be suitable for works with publication dates stated in some other calendar, which wouldn't even have the same names for months. This would be especially true if the dates can't be precisely converted, as happens with religious calendars whose dates depend on religious officials making an actual observation of the new moon. Jc3s5h (talk) 01:10, 19 May 2017 (UTC)

Relevant: [2]. —David Eppstein (talk) 05:31, 21 May 2017 (UTC)

Drawing citation metadata from Wikidata

In preparation for the WikiCite event, currently taking place in Vienna, I have built a demonstrator template, {{Cite Q}}. Much work remains to be done, to deal with more complex use cases, and to resolve the issues listed there. Hopefully that will be addressed during the WikiCite hackathon, on Thursday (CET time, GMT +2). Your comments and remote participation will be welcome. Please use the template's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:09, 23 May 2017 (UTC)

The documentation for this prototype states

• Eventually, each signed-in reader should be able to set, under their "Preferences", the style in which they wish to see citations rendered. No more CiteVar wars!

This is the same concept that date linking tried to accomplish for dates. There was a huge battle over this (if I recall correctly a few editors were banned by the community). The biggest issue that would apply to this proposal is that most people who read Wikipedia are not editors and are not logged in. So the people maintaining articles, if they are foolish enough to log in and set a citation preference, will be seeing something different than the majority of readers, and may fail to see problems with the way the citations are presented to the majority of readers. I think a well-advertised RfC at WT:CITE would be appropriate before going in this direction. Jc3s5h (talk) 13:31, 23 May 2017 (UTC)

Please use the template's talk page.. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:56, 23 May 2017 (UTC)

(edit conflict)

Is it even possible for a template to know a logged-in user's preferences? Not possible, so far as I know. Were it possible, no doubt, there would have been discussion here suggesting, or perhaps demanding, that cs1|2 be modified to accommodate user preferences.

—Trappist the monk (talk) 13:58, 23 May 2017 (UTC)

Since this will allow data reuse without dealing directly with the source, the quality of the underlying citations is more important AFAIC. Isn't reliability an issue here? How does this reflect/impact on citation reuse? People have a tendency to conflate automation & reliability. 72.43.99.146 (talk) 14:54, 23 May 2017 (UTC)

Yes it is. That is exactly the argument I was trying to make in the ISBNs in mw:Citoid discussion. It is perhaps more insidious because WikiData can be edited by anyone whereas WorldCat, as I understand it, is a rather more closed system.

—Trappist the monk (talk) 15:07, 23 May 2017 (UTC)

Templates shouldn't pull from Wikidata, and {{cite Q}} templates would be even more problematic and editor-unfriendly than the now-killed {{cite doi}}. A |wikidata=Q15625490 parameter however, would be pretty great. Headbomb {t · c · p · b} 15:21, 23 May 2017 (UTC)

It seems to me the biggest problem with reusing cited data is the lack of consensus that the editor who copies a claim, with a citation, from one article to another must look at the source to see if it really supports the claim. Without such a consensus, all is lost. Jc3s5h (talk) 15:34, 23 May 2017 (UTC)

Protected edit request on 23 May 2017

I would like to make an edit request adding a new lastnamefirst parameter. It changes the name order in citations, defaulting to yes. Change it to no for Icelandic names. Numberguy6 (talk) 15:54, 23 May 2017 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. This may be a valuable discussion to have but it certainly does not have a consensus at this time. What reason do you propose to make this change? Izno (talk) 16:13, 23 May 2017 (UTC)

Licensing

Is there a way in this family of templates to be able indicate the licensing of the cited material? I am particularly interested in being able to mark a citation as being Creative Commons licensed so that the reader can see if it can be re-used. As Wikipedians, we are generally in favour of information being open and reusable. While I can see that we support expressing whether a source is free/subscription/etc (which affects "open"), I cannot see a similar way of expressing the source's potential for re-use. As a writer of Wikipedia, I would love to be alerted to CC-licensed materials (particularly the ones that enable re-use on Wikipedia itself). I write a great deal about Queensland, Australia, and there are a lot of government resources that people don't realise are CC-BY licensed and I'd like to alert readers (and other writers) to this when citing them. Is there a way to do it? Or do I have to do it after the cite template and before the closing ref tag as I did at State Strategic Touring Route. Thanks Kerry (talk) 08:18, 27 May 2017 (UTC)

Previous discussion on this topic is here.

—Trappist the monk (talk) 09:41, 27 May 2017 (UTC)