Help talk:Citation Style 1/Archive 62

• I would point out that in addition to Journal abstracts, many newspaper sites give free access to the first few paragraphs of a story, but paywall the rest. DES ^(talk)_{DESiegel Contribs} 01:44, 3 January 2020 (UTC)

Abstracts are "official" summaries, at least in the context we are discussing presently, I think. What you are referring to would be an extract, or non-extant part. I still think that "limited" is a correct url option for it. 72.43.99.138 (talk) 15:07, 3 January 2020 (UTC)

It is not. |xxx-access= is to describe what restrictions on accessing the full source. For instance, a source that requires free registration to read is limited access. Or a source that you can read 10 times before having to pay for is limited access. A free blurb is irrelevant to this. All blurbs are free.

b

} 15:35, 3 January 2020 (UTC)

A site that has a requirement for free registration should use url-access=registration, this is the specific use case for that value. X articles or X articles per month is definitely "limited", that is the suggested use case for that value, but perhaps not the only use case. DES ^(talk)_{DESiegel Contribs} 16:08, 3 January 2020 (UTC)

Right, same icon though.

b

} 17:30, 3 January 2020 (UTC)

I propose to update the cs1|2 module suite on the weekend of 11–12 January 2020.

Module:Citation/CS1

• fix archive static text case; discussion
• removed support for |dead-url= and |deadurl=;
• add support for |script-map=; discussion
• i18n support for limited parameter values; discussion
  • examples in the discussion are now broken because non-English keywords have been removed from the sandbox pending this update
  • discussion on my talk page now archived
• support categorization when |language=<local language>; discussion
  • discussion on my talk page now archived
• tweak to support IETF lang codes related to harmonization with Module:Lang; discussion
• fix |script-title= error report bug when used in {{cite encyclopedia}}; discussion
• support three-char codes for |script-param=; discussion
• add prop cat to evaluate 2-location-param use in article space; discussion
• no ampersands in vanc-style namelists; discussion
• removed support for |ASIN-TLD=, |class=, |registration=, |subscription=; discussion

Module:Citation/CS1/Configuration

• change deprecated errors back to visible for next release; discussion
• fix archive static text case
• remove laysummary, dead-url per previous deprecation
• add support for |script-map=;
• i18n support for limited parameter values;
• support categorization when |language=<local language>;
• tweak to support IETF lang codes related to harmonization with Module:Lang;
• add script-lang code: bo, ota, dz;
• add prop cat to evaluate 2-location-param use in article space;
• update pmid url; see Help_talk:Citation_Style_1#PMID:_updated_PubMed_website,_URL_scheme
• removed support for |ASIN-TLD=, |class=, |registration=, |subscription=;

Module:Citation/CS1/Whitelist

• remove laysummary, dead-url per previous deprecation
• add support for |script-map=;
• removed support for |ASIN-TLD=, |class=, |registration=, |subscription=;

Module:Citation/CS1/Date validation

• i18n fix for |year= with non-Latin script; discussion

Module:Citation/CS1/Identifiers

• i18n support for limited parameter values;
• use this_wiki_code from ~/Configuration;
• emit isbn error when 9790...; discussion
• enhance doi registrant code validation; discussion

Module:Citation/CS1/Utilities

• fixed improper removal of pipe character | from plain text title; discussion

—Trappist the monk (talk) 15:40, 4 January 2020 (UTC)

Don't see anything controversial here. Just want to comment on

add prop cat to evaluate 2-location-param use in article space; discussion

It seems to me there is some consensus into making all location parameters aliases of [publisher] |location=. 108.182.15.109 (talk) 16:34, 4 January 2020 (UTC)

By my reading, there was a consensus to implement a tracking category so that we could see whether making the location parameters aliases of one another was feasible. That tracking category will be populated after the update. – Jonesey95 (talk) 17:04, 4 January 2020 (UTC)

There is something weird in the current {{

--Izno (talk) 03:24, 8 January 2020 (UTC)

That is how it is supposed to be. What you are really citing here is a journal, so use {{

cite ssrn

}} are similar.

—Trappist the monk (talk) 03:51, 8 January 2020 (UTC)

I think Izno is pointing out that the error message says that two parameters are being ignored, but the parameter values are being displayed. I don't think both things can be true at the same time (although perhaps I haven't achieved a sufficient level of enlightenment). – Jonesey95 (talk) 05:03, 8 January 2020 (UTC)

You are the truly enlightened for understanding my bug report. ;) --Izno (talk) 06:36, 8 January 2020 (UTC)

No one has ever claimed that I am a member of the enlightened clan ... I have been rightly accused of leaping to incorrect conclusions because I failed to completely read the whole damn message before replying. Yep, I'm old enough to know better ...

The pre-print templates are rendered using the same code as is used for the periodical templates. Most of the parameters allowed in periodical templates are unset because they aren't listed in the limited-parameter lists used by the pre-print templates. |access-date= and |publisher= are valid for use in periodical templates but not valid for use in the pre-print templates. But, |access-date= and |publisher= escaped that 'unsetting' because they matched the patterns we have in Module:Citation/CS1/Suggestions. The code for that emitted the error messages but left the parameters intact so they were rendered by the periodical rendering code in the citation along with the error message.

—Trappist the monk (talk) 13:17, 8 January 2020 (UTC)

Publisher should also be ignored.

b

} 16:28, 8 January 2020 (UTC)

In the sandbox it is, isn't it? Are you seeing something that I'm missing?

—Trappist the monk (talk) 16:32, 8 January 2020 (UTC)

It looks to me like this bug has been fixed in the sandbox. Now I might be the blind one; was it fixed before or after this conversation was started? – Jonesey95 (talk) 01:39, 9 January 2020 (UTC)

After, at just about 12:54 UTC today. --Izno (talk) 02:39, 9 January 2020 (UTC)

Seems a {{Cite web}} discussion has creeped its way to Wikipedia talk:Manual of Style/Film#We should not be italicizing RT, MC and BOM. Interested parties are welcomed. --Gonnym (talk) 09:40, 10 January 2020 (UTC)

Using {{cite web}}, if the |title= ends on "?" or "!" and either |work= or |series= is used and the separator is set to the default ".", the rendered output looks odd as the "?" or "!" is immediately followed by a ".". This does not happen when the |title= ends on "." because a trailing "." is automatically removed. Since the "?" or "!" cannot reasonably be removed from a title, the "." preceding either |work= or |series= should be suppressed instead. --Matthiaspaul (talk) 02:48, 10 January 2020 (UTC)

Examples:

Suggestions? – Jonesey95 (talk) 03:31, 10 January 2020 (UTC)

This is on the feature request list; see Module talk:Citation/CS1/Feature requests § Separator suppression.

—Trappist the monk (talk) 12:32, 10 January 2020 (UTC)

As discussed before there are journals, magazines (and even books) which define values for |volume=, |issue= and |number= - for example

Right now, the usage of the |issue= and |number= parameters is mutually exclusive and will create an error message. Putting the |number= value into another parameter like |id= is an unsatisfactory solution given that we already have a suitably named parameter for this. Also, this makes the number look out of place in the output.

I understand that issuing an error message is a safety measure so that people don't accidently add one of the two parameters overlooking the other, but I wonder if this is really a frequent problem.

If not, I suggest to simply allow either or both of these parameters to be used at the same time. If both are used, |issue= should be displayed following |volume=, followed by the |number= as follows:

<volume> (<issue>) #<number>

or

Vol. <volume> no. <issue> #<number>

If only one of the parameters is given, the display should be as follows (for journals):

<volume> (<issue>)

<volume> (<number>)

or (for magazines):

Vol. <volume> no. <issue>

Vol. <volume> no. <number>

If, however, the error condition is a frequent problem that needs to be catched by default, I suggest to add at least some means to override this error message, like putting the |number= value in (()) in order to let the template accept it.

Assuming that there is only one "issue number" placeholder to be filled in metadata I'm open in regard to what value(s) should be passed on if both are given: It would be possible to only pass on |issue= or to concat both parameters into one string like "<issue> #<number>" before passing it on. It would also be possible to make this selectable on (()) being used on either or both of |issue= and |number=.

--Matthiaspaul (talk) 03:22, 10 January 2020 (UTC)

Personally, I'd prefer |num-issue=yes and |issue-num=yes to set the order and declare that both are actually relevant. See also

b

} 05:16, 10 January 2020 (UTC)

I'm open for suggestions. Whatever helps to finally get the underlying problem addressed and resolved.

BTW, I just found an older discussion Help talk:Citation Style 1/Archive 29#Cite journal causes error for journals with given issue and number numbers.

Beyond the original proposal, if we have both, |issue= and |number= values, perhaps the template output should be given some more thought to remain as close to established rules for formatting as possible:

To me (and in the case of "Dr. Dobbs Journal" and "Minolta-Spiegel"), issue is the value considered relative to volume, and number is an absolute number, but for "Aeroplane Monthly" (in the other thread) the meaning appears to be swapped: Vol. 44, No 12, Issue no 524.

Conceptually, both values are numeric to me, but if not, I would consider |number= to contain a number, but perhaps prefixed like "number 524". This could also apply to |issue=, like in "issue 4", but it could also contain a text-only value like "summer issue", "special issue" etc.

Therefore, as a refinement to the above proposal, the above suggested output rendering

<volume> (<issue>) #<number>

or

Vol. <volume> no. <issue> #<number>

appears reasonable only if both values are all-numeric.

Given the interchangeability of the two parameters, in this all-numeric case, the one with the smaller number should be considered to be relative to the volume, that is, it should be listed first. Otherwise the values are swapped so that the larger value is always the one listed last (and with the # mark), as follows:

<volume> (<number>) #<issue>

or

Vol. <volume> no. <number> #<issue>

If only one of the parameters carries a non-numeric value, and further assuming that the generic template rendering "V (X)" or "Vol. V no. X" should remain unchanged, the numeric value should be the one immediately following the volume (for backward compatibility). Example (with volume containing 5, one of the other parameter contains "6", the other "summer"):

5 (6) summer

or

Vol. 5 no. 6 (summer)

An example assuming one parameter would contain "6", the other "summer issue":

5 (6) summer issue

or

Vol. 5 no. 6 (summer issue)

Yet another example assuming one parameter would contain "6", the other "number 524":

5 (6) number 524

or

Vol. 5 no. 6 (number 524)

If both parameters carry non-numerical values, the order should again be "issue followed by number" (to preserve the nominal default order as with both values being all-numeric):

<volume> (<issue>) <number>

or

Vol. <volume> no. <issue> (<number>)

Since non-numerical values cannot (easily) be evaluated and compared, there is no swapping. It is up for the user (and documentation) to assign suitable text values to these parameters for this rendering. The only visual difference compared to the all-numerical case would be that in the non-numerical case, the # is missing in front of the number.

Well, perhaps if we would drop the proposed # from the second value in the all-numerical case as well, the output would look exactly the same for all cases. This would be more consistent and easier for documentation. Still, whatever the values put into these parameters, the output would be reasonable formatted in a way that the values can be distinguished from another.

--Matthiaspaul (talk) 22:59, 10 January 2020 (UTC)

The {{cite book}} and {{cite web}} templates silently ignore the |issue= and |number= parameters, if they are specified. Additionally, {{cite web}} ignores the |volume= parameter. There might be more such cases, but these are the ones I run into quite frequently in articles.

In general, I don't think it is a good idea to suppress information provided. The contributing editor probably had a reason to add this information in the first place. Also, as has been discussed earlier, there are books which have volume, issue and number values assigned to them, hence this info should be displayed.

I don't know if {{cite journal}}, {{cite magazine}} etc. silently suppress some other parameters as well, but if not, {{cite book}} and {{cite web}} should display some message suggesting to switch to {{cite journal}} or {{cite magazine}} if unsupported parameters are used. (Not sure, if this should be an error message, a maintenance message or a message only displayed in edit mode.)

Additionally, these citations should be put into some maintenance category so that they can be reviewed and reworked to use more suitable templates.

--Matthiaspaul (talk) 04:58, 10 January 2020 (UTC)

Is there something in the documentation for {{cite web}} that makes you think |issue= and |number= are supported parameters? All I see is {cite news} accepts |issue= and |volume= parameters while {cite web} does not. Template documentation is supposed to list all supported parameters, and editors should not expect that other parameters will work.

The {{cite book}} documentation appears to be incorrect, in that it lists |issue= as a supported parameter. I will fix it. If this discussion results in that parameter gaining support, my edits can be reverted. – Jonesey95 (talk) 15:28, 10 January 2020 (UTC)

Yeah, documentation is not always correct, complete, or up to date. But even if it would, an editor's capabilities to keep memorized all the available and ever changing parameters (and their dependencies) for each of the many cite variants are limited.

The templates do not "passively" ignore these parameters (completely unknown parameters like typos throw an error message), but silently "suppress" them, still knowing that they are used in other cite template variants.

IIRC at some point in the past, before all the diversification started and these error checks were introduced to the citation framework, either {{cite web}} or {{cite book}} still supported these parameters, but anyway, cleaning up citations I sometimes run into these parameters (and I am "guilty" myself as well having added missing issue number information to journal citations, not realizing that {{cite web}} was used by prior editors instead of {{cite journal}}).

With all these new dependencies now throwing error messages, perhaps some users are just switching the cite templates until they get rid of the error messages (for example with a missing |journal= in {{cite journal}}, a user might be tempted to switch to {{cite web}}), not realizing that some of the other parameters will be ignored then. This is easy to miss, in particular if editing "foreign" citations.

My point is, all combinations, which exist in the real world, should be supported, and all other combinations should at least give some form of hint (if not throw an error) so that someone knowledgeable can look at the citation and change it to a better variant (instead of just ignoring the information or even removing it because it does not fit into someone's personal concept).

--Matthiaspaul (talk) 23:46, 10 January 2020 (UTC)

After a discussion at

The parameter ssrn= automatically displays the green free access lock, which is almost always a good thing (apparently this feature was added in 2016 - see SSRN free access lock in this talk page's archives). I discovered today that SSRN hosts a few papers that require payment, such as

This is surprising, SSRN has committed to remain a free open access repository since being acquired by Elsevier. I'll be writing them to see what's what.

b

} 17:05, 15 January 2020 (UTC)

The free access is provided for Elsevier rather than for any users. See "License to Elevier" at https://www.ssrn.com/index.cfm/en/terms-of-use/ . Elsevier charge fees because "we believe that offering the broadest array of content provides the most value to our users". See "10. What is the charge for using the SSRN eLibrary?" at https://www.ssrn.com/index.cfm/en/ssrn-faq/#elec_lib_charge . Thincat (talk) 08:38, 16 January 2020 (UTC)

Maybe it would be helpful to have |accessdate= (or something similar to that parameter) work with {{cite sign}}, as signs are frequently removed, vandalised or become unreadable after exposure to the elements. This is just a suggestion; I could see it not being helpful due to how rarely signs are "archived" compared to web pages. Glades12 (talk) 18:22, 16 January 2020 (UTC)

I am afraid this is not doable. There is no way I can see to apply neutrality to such access, it is non-fungible and unprovable. 24.105.132.254 (talk) 19:22, 16 January 2020 (UTC)

Can you explain further? Can't it just be the same as with URLs, where the date is the last one at which someone went to the sign, read it and could confirm that it still verifies the information before the citation? Glades12 (talk) 19:50, 16 January 2020 (UTC)

I would think it self-evident... this is stated without attempting to be sarcastic or ironic. But what you are proposing is I think unverifiable. 108.182.15.109 (talk) 02:01, 17 January 2020 (UTC)

Access date with web pages is (if someone updates it, as they are supposed to) unverifiable too, yet we still have that. You seem to have a double standard here. Glades12 (talk) 06:45, 17 January 2020 (UTC)

A quarry query reveals a few things. Namely

• Citations with DOI prefixes that have 10.#, where # is not 4 or 5 digits should be reported as errors.
• Citations with DOI prefixes that range from 10.0001 to 10.0999 should be reported as errors.
• Citations with DOI prefixes that range from 10.00001 to 10.09999 should be reported as errors.
• Citations with DOI prefixes that are over 10.40000 should be reported as errors.

This is about the registrant code portion of a doi. If I understand §2.2.2 DOI prefix, nothing constrains the composition of doi prefix registrant codes. Have doi.org published someplace, anyplace, a list of valid registrant codes?

—Trappist the monk (talk) 18:43, 29 December 2019 (UTC);;

Technically, nothing restraints that. In practice, those have never been assigned. Theses checks should also be implemented in {{

b

} 20:37, 29 December 2019 (UTC)

~/Identifiers/sandbox tweaked. All of these emit the doi error message except the first four:

• "Title". Journal.
  doi:10.1000.10/somat
  . – prove that four-digit registrant code with sub code is accepted
• "Title". Journal.
  doi:10.1000/somat
  . – prove that four-digit registrant code is accepted
• "Title". Journal.
  doi:10.10000.10/somat
  . – prove that five-digit registrant code with sub code is accepted
• "Title". Journal.
  doi:10.10000/somat
  . – prove that five-digit registrant code is accepted
• "Title". Journal.
  doi:11.1000/somat. {{cite journal}}: Check |doi= value (help
  ) – invalid directory
• "Title". Journal.
  doi:10.1000/somat. {{cite journal}}: Check |doi= value (help
  ) – terminal punctuation
• "Title". Journal.
  doi:10.123.10/somat
  . – three-digit registrant with subcode
• "Title". Journal.
  doi:10.123/somat. {{cite journal}}: Check |doi= value (help
  ) – three-digit registrant
• "Title". Journal.
  doi:10.0123.10/somat. {{cite journal}}: Check |doi= value (help
  ) – four digit leading zero with subcode
• "Title". Journal.
  doi:10.0123/somat. {{cite journal}}: Check |doi= value (help
  ) – four digit leading zero
• "Title". Journal.
  doi:10.01000.10/somat. {{cite journal}}: Check |doi= value (help
  ) – five digit leading zero with subcode
• "Title". Journal.
  doi:10.01000/somat. {{cite journal}}: Check |doi= value (help
  ) – five digit leading zero
• "Title". Journal.
  doi:10.40000.10/somat. {{cite journal}}: Check |doi= value (help
  ) – five digit does not begin with 1, 2, or 3; is there a 40000 registrant?
• "Title". Journal.
  doi:10.50000/somat
  . – five digit does not begin with 1, 2, or 3
• "Title". Journal.
  doi:10.100056/somat. {{cite journal}}: Check |doi= value (help
  ) – six+ digit registrant
• "Title". Journal.
  doi:10.5555/somat. {{cite journal}}: Check |doi= value (help
  ) – test registrant

—Trappist the monk (talk) 16:55, 30 December 2019 (UTC)

Highest legit registrant I was able to find was 10.36931 [1]. I don't know how high they go, but none have crossed 10.40000 yet.

b

} 17:00, 30 December 2019 (UTC)

"Test to see that we haven't impacted something on the other side of the slash". Journal.

doi:10.3109/15563650.2010.492350. --Izno (talk

) 17:58, 30 December 2019 (UTC)

@

b

} 14:17, 11 January 2020 (UTC)

Yeah, I saw that:

{{cite book |last=Metzinger |first=Thomas |year=2013 |title=Spirituality and Intellectual Honesty: An Essay |publisher=Self-Published |isbn=978-3-00-041539-5 |doi=10.978.300/0415395}}

Metzinger, Thomas (2013). Spirituality and Intellectual Honesty: An Essay. Self-Published.

ISBN 978-3-00-041539-5

.

I'm not clear about what you mean by 10.d.d, but not in 10.d is each d three digits so, as regex, 10\.\d\d\d\.\d\d\d, but not in 10\.\d\d\d?

—Trappist the monk (talk) 14:23, 11 January 2020 (UTC)

@Headbomb: Because of this pending update, if you can clarify the question above before I make the update, any necessary fixes can be applied at the same time.

—Trappist the monk (talk) 17:27, 13 January 2020 (UTC)

I just mean that dois should start with 10.#/... or 10.#/... with the restrictions that # is 4 or 5 digits, ranging from 1000 to 40000. And if you have a 10.#.#/... then it seems those restrictions don't apply, or that 978 is a special case.

b

} 17:37, 13 January 2020 (UTC)

Module:Citation/CS1/Identifiers function doi() updated.

—Trappist the monk (talk) 14:33, 18 January 2020 (UTC)

~/Date validation recognizes the Arabic digits as digit characters, but Lua's tonumber() function only works with Latin characters. Fixed in the sandbox. Because this is a lua script error, I will likely update ~/Date validation within the next week.

—Trappist the monk (talk) 17:24, 13 January 2020 (UTC)

Module:Citation/CS1/Date validation updated.

—Trappist the monk (talk) 14:35, 18 January 2020 (UTC)

For a while, there has been a copy-paste bug in the Visual Editor (VE) that caused code like templatestyles src="Module:Citation/CS1/styles.css" to appear in articles' wikicode. The bug is described in T209493. A bug fix was reportedly deployed on 15 January 2020.

This search shows articles currently affected by the bug. In theory, if we get them all cleaned up, we can find out if the bug is still present by watching to see if it shows up as a result of a future VE copy-paste edit.

Here's how I fixed one article. Helpfully, the edit that placed the bug-infected code in the article had a nice edit summary that led me to the original wikicode, which I was able to copy and paste to replace the badly formatted references. – Jonesey95 (talk) 05:19, 21 January 2020 (UTC)

@

b

} 05:40, 21 January 2020 (UTC)

I don't know. There are only 43 articles affected, so an editor versed in AWB and/or regular expressions, or simply someone with good detective skills could probably take it on. – Jonesey95 (talk) 06:48, 21 January 2020 (UTC)

Since the last update, I have been engaged in discussions with the editor who maintains the cs1|2 modules at sq.wiki. Those discussions have led to some changes that, I hope, will aid editors at other wikis when they update their module suites.

• Module:Citation/CS1/sandbox:
  • the supplemental portions of the Vancouver-style and archive url error messages have been moved into a table in ~/Configuration/sandbox
  • cfg.defaults table is disabled
• Module:Citation/CS1/Configuration/sandbox:
  • added more notes to aid translators
  • removed defaults table because it only supported |url-status= and the code never actually looks for the assigned default value (dead); rather, it looks for live, unfit, usurped, and bot: unknown
  • added err_msg_supl to hold supplementary error message text for archive url, bibcode, isbn, and Vancouver style error messages
• Module:Citation/CS1/Identifiers/sandbox:
  • the supplemental portions of the bibcode and isbn error messages have been moved into a table in ~/Configuration/sandbox

—Trappist the monk (talk) 14:07, 21 January 2020 (UTC)

I have had several sources which have both a paper book and an e-book available, and they naturally have both their own ISBN numbers. Should the template:Cite book have parametres for inputting both (to be used only in case they are releases of the same edition), like the journal and magazine templates have the possibility of inputting both ISSN and eISSN parametres? --XoravaX (talk) 19:16, 23 January 2020 (UTC)

It seems to me the most important thing is leading the reader to the exact page that supports the statement. Since the pages between electronic books and paper books are often different. The person completing the citation should cite the one that the editor looked at. I think the cases where the editor looked at both and confirmed the page numbers are the same are rare enough that the extra complexity in writing the template code, using the template, and understanding how to use the templates, just isn't worth it. On those rare occasions the editor can always mention the alternate version in the citation, but outside the template. Jc3s5h (talk) 19:25, 23 January 2020 (UTC)

Indeed that the page numbering often differs between the paper and e-book releases is a major concern and a good point against. I suppose you are right that the rare occasions don't justify the possibility for inputting both paper ISSN and eISSN, especially considering the chance of mix-ups if the editor doesn't check the page numbering from both. --XoravaX (talk) 19:45, 23 January 2020 (UTC)

Hi, just spotted that a date without a space between the day & month is not flagged as an error.

For example {{cite web |url=https://www.goethe.de/ins/ca/en/kul/sup/dsk/dstu/fvp.html |title=PEDESTAL OF THE SOCALLED "PEACE MEMORIAL“ |date=11July 1998 |publisher=Goethe |access-date=26November 2019 }}

"PEDESTAL OF THE SOCALLED "PEACE MEMORIAL"". Goethe. 11July 1998. Retrieved 26November 2019. {{cite web}}: Check date values in: |access-date= and |date= (help)

Keith D (talk) 17:31, 23 January 2020 (UTC)

I have modified the value in |date= above, removing the space to show that this is not just a problem with |access-date=. – Jonesey95 (talk) 18:16, 23 January 2020 (UTC)

Just guessing here: should ^([1-9]%d?) *(%D-) +((%d%d%d%d?)%a?)$ in Module:Citation/CS1/Date validation/sandbox have + instead of * in the 13th character position? I made that change and got the output below. I have done no further testing, which could be risky. – Jonesey95 (talk) 18:24, 23 January 2020 (UTC)

+ is 1 or more; * is 0 or more. Your change was correct. --Izno (talk) 20:44, 23 January 2020 (UTC)

Hello, is it possible that a dev add the ability to have multiple |chapter= in

There is some helpful information on a variety of Wikipedia help pages like this one that provides guidance on how to cite the multiple locations in the same source. – Jonesey95 (talk) 03:29, 29 January 2020 (UTC)

This seems undesirable. In some articles, the citations are arranged in a bibliography, which is sorted alphabetically by author name. Without having separate citations, it wouldn't be possible to decide where in the list to put the cite that combines several chapters (assuming each chapter was written by different authors). Jc3s5h (talk) 03:31, 29 January 2020 (UTC)

You might take a look at articles that have complex citation styles, like Herman Melville#References or Jane Austen#Citations, to get a sense of how chapters are cited in larger works. – Jonesey95 (talk) 03:57, 29 January 2020 (UTC)

I will have a look, thanks. Veverve (talk) 16:01, 2 February 2020 (UTC)

Are there particularly significant reasons behind why we bold volume numbers in CS1? Although it may help parse volume versus issue, it also over-emphasiseds the volume in a way that's not really very helpful. It seems to have been more common in very compact citation styles where often the title would be omitted or before the ability to link to an item. Do the benefits outweigh the drawbacks? T.Shafee(Evo&Evo)^talk 11:29, 5 February 2020 (UTC)

Because that's what most academic citation guides do. Historically because finding the volume of a print journal was the most important thing, because if you got the page number wrong, you could still find whatever article you were looking for.

b

} 14:01, 5 February 2020 (UTC)

In addition to what Headbomb has said, it helps distinguish the volume from, say, the year or issue. Glades12 (talk) 14:14, 5 February 2020 (UTC)

The issue number was already mentioned. Sorry for my mistake. Glades12 (talk) 14:16, 5 February 2020 (UTC)

Thanks for the points raised. Given it's historically logical roots, of course plenty implement it (e.g. Nature, Science), however there are also plenty that don't any more / never have (e.g. BMJ, Cell, PLOS, BMC). So my question is more if we were designing CS1 today, is it something that would be implemented or is it just status quo momentum. If it's mainly momentum, it might be something worth revisiting as to whether it is overall a net benefit. T.Shafee(Evo&Evo)^talk 11:13, 6 February 2020 (UTC)

Bolding of volume (presentation of |issue/number= and |page(s)= in {{cite journal}} particularly also) comes up every couple months or so and mostly just needs an RFC to decide what we want to do. I imagine a couple questions:

1. Should the volume be consistent across all templates?
2. If yes, what should that presentation be?
3. If no, in addition to which multiple presentations should we provide, which templates should have which presentations?

For reference today, at least {{cite magazine}} varies from the bold presentation ("vol #"). (I have opinions on the other questions but I don't want to get into that right now because I'm just proposing the questions. :) --Izno (talk) 17:02, 6 February 2020 (UTC)

I would say we should be consistent across all of the templates and that we should clearly show that it is the volume by outputting "Vol." before it or else how do people know it is a volume? Keith D (talk) 18:35, 6 February 2020 (UTC)

This is certainly how journals are cited in most style guides, but I think it looks a bit jarring when citing books. Chicago (mostly), APA and MLA use "Vol.", Blue Book just a plain number. None bold. – Finnusertop (talk ⋅ contribs) 19:16, 6 February 2020 (UTC)

I believe journals go this way in style guides today because there is at least one international standard that lays out the expected styling for journals. --Izno (talk) 19:34, 6 February 2020 (UTC)

We used different rendering of page numbers (colon vs pp.) depending on whether the item is a journal or not. I would suggest we render volumes as bold in the former case and with "vol." otherwise. Kanguole 18:43, 6 February 2020 (UTC)

We should be clear on page numbers as well and always use "p." or "pp." in all templates. This is so people do not have to guess the meaning of the figures. Keith D (talk) 18:52, 6 February 2020 (UTC)

Et al, try not to get bogged down in the what it should be already :). I think what would be best right now is to (dis)agree that my questions are the questions we want to answer (in an RFC) and then to do the research necessary to present the question to the wider community (both what is done today in CS1/2 and what is done by external style guides, if we should choose to take external inspiration). Are those questions reasonable? Is there one to add? --Izno (talk) 19:31, 6 February 2020 (UTC)

From the above, we have three styles for rendering volumes and pages:

and maybe variants of the first two without bolding. In my view the volume needs to be set off in some way, if not by bolding then with a prefix. Kanguole 19:17, 6 February 2020 (UTC)

I am naturally concerned about the presentation in our other templates, such as cite encyclopedia and cite magazine. --Izno (talk) 19:31, 6 February 2020 (UTC)

[edit conflict] I would be happy with proposal 2 here. We are not an academic publisher and when academic standards are too technical for a general readership we should set them aside. —David Eppstein (talk) 19:32, 6 February 2020 (UTC)

Ah, I thought of the proposal 3: Full text, which has been floated much more rarely (e.g. volume 3, pages 12-56). I doubt it is an attractive option to anyone, but I do think the rationale for having our citations be one way vice another does partially come down to readability of the citation, and that is the most readable. (I think the contra-argument, if anyway, is that full text is hard to parse when we have the reference structure we do across the board, which largely emulates citations found in journal papers (multiple columns of citation/content) rather than in books, which I believe are usually single line + hanging indent or single line bullet points in one column). (I am not claiming this is what's done, just that's my impression of the matter.) --Izno (talk) 19:38, 6 February 2020 (UTC)

Just add the full text version as proposal 4. How should we proceed with the rendering of issues and numbers (and the less common, but nevertheless existing case of journals/magazine showing both at the same time)? Should we offer rendering options for them as well as part of an RfC, or should we just sort this out at a later stage? --Matthiaspaul (talk) 21:36, 6 February 2020 (UTC)

I reread what you wrote. Issues/numbers can be a part of this discussion, but I think the "uses both" needs some more thought on proposed implementation (i.e. do we run a bot to remove one or the other across the board and let people who know better correct it? etc.). That said, issue/number would need some more discussion in this section. --Izno (talk) 21:42, 6 February 2020 (UTC)

(EC) I'm partial to proposal 1 for now, because bolding volumes for books make no sense. I'm of two minds on bolding volumes for journals, first because it's rather clear that in, e.g.

b

} 21:39, 6 February 2020 (UTC)

Fully against full text though. That's just a waste of space and time.

b

} 21:41, 6 February 2020 (UTC)

Just a reminder that long volume values are not rendered in bold, e.g. "Title". Journal Name. Volume (Issue): Pages. 2020. {{cite journal}}: |issue= has extra text (help); |volume= has extra text (help) If we are going to do an RFC, that existing condition needs to be thrown into the soup. – Jonesey95 (talk) 22:42, 6 February 2020 (UTC)

I am not sure if this is intended, but this edit clears the "extra punctuation" category. Should |ref= actually be checked for extra punctuation? --Izno (talk) 20:51, 6 February 2020 (UTC)

It also seems to be checked in |author-mask=, which is intended to have dashes, as with here. I do not know about the correct solution in this case either, though I have found a preferable solution in the context of these templates. --Izno (talk) 21:23, 6 February 2020 (UTC)

See the explanatory text at Category:CS1 maint: extra punctuation for an explanation of the first edit. As for the second one, it looks like you may have seen Template:Cite book#Display options, which shows the supported options for |author-mask=. {{long dash}} renders as &nbsp;<span style="letter-spacing:-.25em;">———</span>&nbsp; – note the ending semicolon, which places the citation in the "extra punctuation" category. – Jonesey95 (talk) 22:37, 6 February 2020 (UTC)

Right... I'm aware of why I needed to make the changes. It is not however obvious to me that the two parameters in question should have these changes made. --Izno (talk) 22:39, 6 February 2020 (UTC)

I think this is why the category is currently a maintenance category, with a hidden error message that normal editors don't see. We usually set up maintenance categories if we are unsure of the scope of a potential problem, or unsure if we will catch false positives, or both. In this case, we are catching a false positive in the first instance. One could argue that the |author-mask= usage is not compliant with the documentation, but I could go either way.

In any event, no, you don't have to "fix" these conditions, but it's worth discussing whether those parameters should be excluded from this particular error check. – Jonesey95 (talk) 22:45, 6 February 2020 (UTC)

Well, it's designed to catch obvious nonsense like |author-mask=3;, but really the ideal solution is to exclude well-formed HTML entities from it.

b

} 23:35, 6 February 2020 (UTC)

I've added a line of code that allows for <, >, &, ", and   html entities as the final 'character' in a parameter. Here are the two templates mentioned above:

• Vermont State Archives (June 12, 2006). "General Election Results, U.S. Representatives, 1822–1830 (Five Districts)" (PDF). www.sec.state.vt.us. Montpelier, VT: Vermont Secretary of State.
• JSTOR 3748372. {{cite journal}}: Invalid |ref=harv (help
  )

This is not a perfect solution. For example, this, which uses |author=  will no longer be detected:

  (2005-12-21). "TWU Leaders Refuse To Back Down Despite Threat Of Jail Time". NY1. Archived from the original on April 3, 2008. Retrieved 2014-04-04.{{cite web}}: CS1 maint: extra punctuation (link)

I'm not sure if this is a net gain or loss.

—Trappist the monk (talk) 17:17, 7 February 2020 (UTC)

Never mind, I've been reverted.

—Trappist the monk (talk) 17:25, 7 February 2020 (UTC)

I reverted your change, mostly to demonstrate an alternative: I didn't realize that we had a whitelist of parameters, so I've added "Ref" there. I do think it would be a net loss for something like that in |author= not to be caught would be unfortunate. What I didn't try is to put the Mask parameters in the whitelist. Do you think that's possible with the current code? Or do we think it is not worth it and users should be instructed to provide an alphanumeric directly in |author-mask= et al, and to continue checking it like it is today? I think I tend toward continuing to check it and instructing users--which might lead to a stronger parameter check than currently (because this kind of check is fairly soft). --Izno (talk) 17:28, 7 February 2020 (UTC)

Adding meta-parameter Ref to that whitelist 'works' but we lose the ability to detect stray comma-colon-semicolon punctuation.

I don't know how common the |author=  problem is; MediaWiki repeatedly dies, returns nothing, or times out when I try to search for |author= .

We could, if we can determine that it is warranted, check for parameter values that are only white-space 'characters' that are html entities ( ,  , etc) with or without ascii space characters mixed in. When these strings of html whitespace characters are detected, the whole parameter value would be set to nil and the module would emit an error message or maint cat.

—Trappist the monk (talk) 00:36, 8 February 2020 (UTC)

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

The styles in Module:Citation/CS1/styles.css define a few new link icons, but they use low-resolution images, which look ugly on high-resolution screens (or when zooming in), particularly when shown next to default MediaWiki link icons, which are high-resolution.

For example, look at reference 2 on It (novel)#References.

I recommend using the same approach as MediaWiki to load SVG images on browsers that support them: https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.less/mediawiki.mixins.less#L31

Namely, please make these changes to Module:Citation/CS1/styles.css:

.id-lock-free a,
.citation .cs1-lock-free a {
	background: url(//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png) no-repeat;
	background-position: right .1em center;
}

.id-lock-limited a,
.id-lock-registration a,
.citation .cs1-lock-limited a,
.citation .cs1-lock-registration a {
	background: url(//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png) no-repeat;
	background-position: right .1em center;
}

.id-lock-subscription a,
.citation .cs1-lock-subscription a {
	background: url(//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png) no-repeat;
	background-position: right .1em center; 
}

.id-lock-free a,
.citation .cs1-lock-free a {
	background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png);
	background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/6/65/Lock-green.svg);
	background-repeat: no-repeat;
	background-size: 9px;
	background-position: right .1em center;
}

.id-lock-limited a,
.id-lock-registration a,
.citation .cs1-lock-limited a,
.citation .cs1-lock-registration a {
	background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png);
	background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/d/d6/Lock-gray-alt-2.svg);
	background-repeat: no-repeat;
	background-size: 9px;
	background-position: right .1em center;
}

.id-lock-subscription a,
.citation .cs1-lock-subscription a {
	background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png);
	background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/a/aa/Lock-red-alt-2.svg);
	background-repeat: no-repeat;
	background-size: 9px;
	background-position: right .1em center; 
}

.cs1-ws-icon a {
	background: url(//upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Wikisource-logo.svg/12px-Wikisource-logo.svg.png) no-repeat;
	background-position: right .1em center;
}

.cs1-ws-icon a {
	background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Wikisource-logo.svg/12px-Wikisource-logo.svg.png);
	background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/4/4c/Wikisource-logo.svg);
	background-repeat: no-repeat;
	background-size: 12px;
	background-position: right .1em center;
}

Matma Rex talk 17:41, 7 February 2020 (UTC)

 Not done: Please feel free to add them to the sandbox, Matma Rex. Izno (talk) 17:45, 7 February 2020 (UTC)

Like this, I guess? I'm not familiar with the template stuff on this wiki. Matma Rex talk 18:12, 7 February 2020 (UTC)

@Matma Rex: Yes. Now, this won't be deployed until the next cycle in a month or two, so I'm disabling the edit request for that as well. --Izno (talk) 18:23, 7 February 2020 (UTC)

I like this. Quite a while ago I asked at the graphics lab about how to make these icon images clearer. I never got an answer so I'm glad to see that there is a way to make the images less fuzzy.

—Trappist the monk (talk) 00:38, 8 February 2020 (UTC)

I have just normalised a book citation, which cited a specific footnote. So I inserted a 'footnote = ' in front. It is an unrecognised parameter. Can this be added? And I suppose we better have endnote= too. The context for this is when the cited book itself cites an inaccessible source. --

@

John Maynard Friedman: Can you describe in more detail what you are trying to do? --Izno (talk

) 19:19, 8 February 2020 (UTC)

You can specify both a page and footnote with |at=p. 117, footnote 77. Kanguole 19:30, 8 February 2020 (UTC)

yes, that would probably do, if I could see how to integrate it. Here is the citation as written:

• {{cite book| url = https://academic.oup.com/past/article/149/1/95/1460442 | title= Calendar Reform in eighteenth-century England | last= Poole | first= Robert | date= 1995| series= Oxford Academic Past & Present| page = 117 | footnote=77}}

It seems to me that footnote= sits more easily with the rest of the syntax. --

talk

) 19:43, 8 February 2020 (UTC)

It would be

{{cite book| url = https://academic.oup.com/past/article/149/1/95/1460442 | title= Calendar Reform in eighteenth-century England | last= Poole | first= Robert | date= 1995 | series= Oxford Academic Past & Present | at = p. 117, footnote 77}}

• Poole, Robert (1995). Calendar Reform in eighteenth-century England. Oxford Academic Past & Present. p. 117, footnote 77.

but actually this is a journal citation, so the specific location has to go outside it anyway:

{{cite journal | title = 'Give us back our eleven days!': Calendar Reform in eighteenth-century England | last= Poole | first= Robert | date= 1995 | journal= Past & Present | volume = 149 | issue = 1 | pages = 95–139 | doi = 10.1093/past/149.1.95 }} p. 117, footnote 77.

• Poole, Robert (1995). "'Give us back our eleven days!': Calendar Reform in eighteenth-century England". Past & Present. 149 (1): 95–139.
  doi:10.1093/past/149.1.95
  . p. 117, footnote 77.

Kanguole 20:38, 8 February 2020 (UTC)

"has to" is strong verbiage given what |page= (even in journal citations) is supposed to be used for according to its documentation. :^) There is nothing to prevent JMF from having the specific page and I'm sure I would not be alone in recommending he add the specific page number. --Izno (talk) 20:45, 8 February 2020 (UTC)

The Wikipedia article in question appears to be "Calendar (New Style) Act 1750". It's a hopeless mix of {{Citation}}, Cite xxx, short footnotes, cites to books without using short footnotes as an intermediary, citations using special purpose templates, and citations that do not use templates. It seems to me you need to figure out what the citation system will be for the article before trying to improve individual endnotes. Jc3s5h (talk) 20:50, 8 February 2020 (UTC)

If you do go for short footnotes, this could be done with {{sfn|Poole|1995|p=117|loc=footnote 77}}. Kanguole 20:57, 8 February 2020 (UTC)

It turns out that Poole 1995 is already in the reference list for this article, so the above {{sfn}} will work as given. Kanguole 22:22, 8 February 2020 (UTC)

If this is actually a footnote, add "n" at the end of the page number: |p=117n. If there is more than one footnote in the same page, these are usually numbered (or otherwise separated), so you should include that number/separator: |p=117n2. This has been the way to signify footnotes, since … forever. If it is a note at the end of a chapter or a book, these are usually in a separate, titled section. In this case you are citing a note in that section. Input the section title after the chapter title |chapter=Chapter: Section (most likely, "Notes"), or if at the end, |chapter=Section or |chapter=