Help talk:Citation Style 1/Archive 62

Archive 55

←

Archive 60

Archive 61

Archive 62

Archive 63

Archive 64

Archive 65

What to do about ISBN-10s

10-digit ISBNs have been deprecated since about 2007 and should be replaced by 13-digit ISBNs (now called just "ISBNs") wherever found. Conversion is a simple task (prepend "978-" and calculate a new check digit).

Correct grouping of the other digits (based on "group" and "publisher" identifier lengths) is quite a bit more complicated and would require some kind of periodically updated table.

I do have a javascript that accurately does both of these things while editing, so it could probably be converted to a lua module to do them while rendering instead. And I do mean a separate module, not just a new feature in {{cite book}}. That way it can also replace the contents of the standalone {{ISBN}} template, which currently looks dreadful.

If the above sounds like too much of a cosmetic execution-timesink (I suppose I'd need to create the module first and see how badly it performs), we could resort to tracking categories to fix the input rather than the output:

• A maintenance category when the number of digits is 10 and should be converted to 13.
  • This would be in addition to the error category when the number of digits is neither 10 nor 13.
• A maintenance category whenever (digits == 10 && hyphens != 3) || (digits == 13 && hyphens != 4), because these are sure to be wrong.

Note that detecting ISBNs with the correct number of hyphens at incorrect positions would probably be nearly as expensive as actually fixing them, so they would be neglected in the latter strategy. ―cobaltcigs 02:46, 8 November 2019 (UTC)

I guess I disagree with your premise that 10-digit ISBNs...should be replaced by 13-digit ISBNs (now called just "ISBNs") wherever found. A 10-digit isbn in a book printed in 1982 is and forever shall be a 10-digit isbn. Editors at en.wiki are admonished to WP:SAYWHEREYOUGOTIT. Part of that is accurately recording bibliographic details from the book that they are being citing. If the isbn on the title page of the book is 10 digits, use 10 digits in the citation, don't convert it to 13 digits. See the cs1|2 isbn documentation.

—Trappist the monk (talk) 03:05, 8 November 2019 (UTC)

citation bot does the conversion IF the year is 2007 or later. That way we follow the say where you got it rule. In defense of isbn13 in older books, it COULD be thought of as adding area codes to older phone numbers—it is a stretch. AManWithNoPlan (talk) 03:39, 8 November 2019 (UTC)

IPv4 → IPv6 seems like a better analogy. ―cobaltcigs 20:47, 8 November 2019 (UTC)

The ponderous tome I linked to above says (emphasis mine):

All new ISBN assignments are based on ISBN-13. If a 10 digit ISBN is 
found on the resource, it should be converted to a 13 digit number, 
following the rules set out later in this section, before being 
encoded into the URN framework. According to the rules of the ISBN 
standard, such conversion does not create a new ISBN for the book, 
but a new representation of the existing ISBN.  
[...]
The ISBN in thirteen digit form is defined by the ISO Standard 
2108-2005 and later editions. It was previously referred to as 
“ISBN-13” to distinguish it from “ISBN-10”, but since all ISBNs are 
now valid only in the 13 digit format and ISBN-10 is deprecated, 
ISBN-13 should be referred to as “ISBN”, although in this document 
ISBN-13 is  used for the sake of clarity. 

Note that it very clearly says "all ISBNs" and not "ISBNs of books published in or after 2007" and that there is no reference to any "grandfather clause" or continued validity of ISBN-10s for any duration of time after 2007.

I do know Google Books (surely a more popular "where you got it" source than physical books anymore) info shows both 10- and 13-digit ISBNs, without regard to year of publication and without indicating which of them was ever printed on a physical book. Of course, according to the above document, they could have stopped displaying ISBN-10s (or recognizing them for search) twelve years ago without violating any standards. And since Google Books is an order of magnitude more popular than anything else on the Special:BookSources list, Wikipedia and the rest of the world would have immediately followed suit, if only they had done that. ―cobaltcigs 04:49, 8 November 2019 (UTC)

I find it difficult to get worked up about this cosmetic difference that has no effect on the verifiability of sources or readers' ability to find books when there are hundreds of pages with actual ISBN problems on them. – Jonesey95 (talk) 05:21, 8 November 2019 (UTC)

That document is about how isbn's are or should be used in the context of Uniform Resource Names. cs1|2 does not use urns so the requirements of that document do not apply here.

—Trappist the monk (talk) 12:08, 8 November 2019 (UTC)

Also, conversion is not simply a matter of prepending "978" to an ISBN. The prefix may also be 979 or in the future, something else. The ISBN registrar for the United States has a conversion tool but it is for US & Australia ISBNs only, see About ISBN (notice section on 979) and Converter. 72.43.99.138 (talk) 15:06, 8 November 2019 (UTC)

ISBNs starting with prefixes other than 978- will have no 10-digit equivalent. ―cobaltcigs 20:01, 8 November 2019 (UTC)

Did I miss something? I did not see any such statement. To quote from Bowker (the "About ISBN") link above, "A 10-digit ISBN cannot be converted to 13-digits merely by placing three digits in front of the 10-digit number. There is an algorithm that frequently results in a change of the last digit of the ISBN". So I assume this means there may be potentially a problem with the check digit in a text-based replacement. 98.0.246.242 (talk) 20:48, 8 November 2019 (UTC)

• Every 13-digit ISBN beginning with 978- corresponds to exactly one deprecated ISBN-10.
  • "Corresponds to" means both forms refer to the same book publication and share a substring of 9 "significant" digits.
  • These 9 are followed by a final check digit, which is calculated differently depending on which form and will differ about 91% of the time.
• Every 13-digit ISBN beginning with 979- corresponds to… no other number at all.
• Every 13-digit ISBN beginning with any other prefix… doesn't exist yet. Hopefully nobody still uses ISBN-10s at such future time.
• The "algorithm" is not as complicated as you may fear.

Hope this clears up some confusion. ―cobaltcigs 22:42, 8 November 2019 (UTC)

No, not really. But imo this discussion is becoming non-relevant as far as citations are concerned. As was stated before, editors should cite what they consult. If they consult a source with a 10 digit ISBN, then that is what belongs in the citation. If one feels so strongly about ISBN-13s, they should:

Find a source with a published ISBN-13

Verify the wikitext claim (previously supported by an ISBN-10 source) based on the new source

Replace and rewrite the citation based on the newly consulted source

What should not be done is replacing an ISBN-10 with an ISBN-13. These are marketing ids assigned to publishers by the proper agencies. Personally, I would reject any citation with a Wikipedia editor-manufactured ISBN-13 as original research or misdirection. Conversions of ISBN-10s are supposed to be done (and published) by the entities the ISBN's are assigned to. It is not up to Wikipedia to provide such service.

Not relevant to the above, are the various assignations. First, a straight text replacement is not the right way to go about it. Secondly, conversion tools, and their respective algorithms, seem specific to geographical areas. It is also not clear to me if outside the US "979" prefixes have not been used to replace ISBN-10s. In non-US materials, I have seen non-book ISBN-10s replaced by 979-prefixed ISBN-13s (sorry I have no real-world example handy). It would be perhaps relevant for citations to provide for an International Article Number (EAN) id, since that is what ISBN-13 is purported to align to. 108.182.15.109 (talk) 14:54, 9 November 2019 (UTC)

The above should be amended, as according to the latest edition of the ISBN Users' Manual (2017), "ISBN is now fully compatible with GTIN-13" (7th ed., p. 10, find it here). So I suppose that it would be a Global Trade Item Number id rather than an EAN that could be added if needed. 24.105.132.254 (talk) 18:39, 9 November 2019 (UTC)

• Math is not original research, especially not when the agency issuing these numbers has published very specific instructions for performing said math. The result is as deterministic as an MD5 hash. It just happens to be 5 lines of code and not 109. Here's another tool that does the exact same math. Using that is not original research either.
• Here are Google Books data examples from 1972 and from 2017, both of which show (mathematically!) equivalent 10- and 13-digit ISBNs side-by-side. Choosing the longer one in both cases, for the sake of consistency and forward compatibility, is not original research either.
• There will eventually come a day when some of the hundreds of databases shown at Special:BookSources will cease to recognize 10-digit ISBNs. This will probably coincide with the assignment of 979s in the United States (when the confusion begins affecting people whose opinions matter). At that point our only choice will be to unlist certain book sources or quickly convert numbers to continue using them.
• Here's a French children's book with a 979- ISBN and no short form next to it, because 979 ISBNs are not convertible to a 10-digit format and exist only in a 13-digit format. Any replacement such as you describe would have to be a bonehead error, or the intentional re-assignment of a whole new ISBN to an old edition of a book (not any conversion at all). Any claim that one of the latter two things routinely happens would be original research. Hopefully it's all just a false memory.
• Do you read many books from France, South Korea, and/or Italy? Serious question.

―cobaltcigs 20:01, 9 November 2019 (UTC)

This is not how citations work. They involve published material from reliable secondary sources. ISBNs are legally issued and assigned identifiers through organizations established for this purpose. Even when the use of the conversion tools is allowable by third parties, the result would be unacceptable in a citation. The officially (by publishers) converted ISBNs have to be assigned by the ISBN agencies, like any other ISBN, and the source officially published with that ISBN. Anyone else doing a conversion and publishing it as an "ISBN" is doing OR as far as citations are concerned. Never mind wading into legally dubious territory. And that is assuming the algorithms don't change in the meantime.

We have no way of knowing if or when, book-source databases stop recognizing anything. The data is already entered and structured. There is no rule that says ISBN-10 should not be listed in such databases, nor that it should be replaced by ISBN-13. In contrast, book-marketing databases (including publisher databases) are told by the International ISBN Org. to no longer quote ISBN-10s, but this is irrelevant.

Additionally ISBNs have country codes irrespective of language. Different English-speaking countries may have different ISBN structures. The allocation of ISBNs is not cut and dried either. An educational music work could have been legally assigned an ISBN-10, and could be additionally assigned a 979 ISBN-13. A commercial music work would not have been assigned an ISBN-10, but perhaps an ISMN. Now however it can be assigned a 979 ISBN, since all these ids are compatible with GTIN-13, the new standard that is subsuming them.

And who says that anything involving math cannot be OR? It's not just how you arrive at the numbers, but also how and why you use the results. 24.105.132.254 (talk) 20:51, 9 November 2019 (UTC)

Anyway, ISBNs are so frustratingly unreliable in Wikipedia. How often I seen metadata for an ISBN be out of sync with the metadata in the cite book template (year/publisher). This can happen for a number of reasons, but mainly books have multiple years of publication and multiple publishers such as the co. name vs. imprint name vs. later editions. So someone may put the original year of publication in |year= while using the ISBN of their in-print edition which might be 20 years later. Then how do you know which edition it is? One could assume the ISBN is correct, but I've seen people and scripts add missing ISBNs to templates without a clear indication they are choosing the one intended, and not just the most recently published in-print edition. Particularly by people pushing links to bookseller sites for a certain edition. -- GreenC 19:53, 8 November 2019 (UTC)

Isn't this more of a behavioral issue. There are many admonishments in various help pages for editors to cite what they actually consult. If the consulted online link refers to a different edition than the one originally consulted to write the citation, such information is relevant and should be included somewhere, maybe in a link note. 98.0.246.242 (talk) 20:56, 8 November 2019 (UTC)

Also when you see a plural | pages = parameter followed by only one page number, there's a 90% chance it's the last page (often intentionally blank). ―cobaltcigs 21:19, 8 November 2019 (UTC)

This thread is full of obviously wrong information. Some quick facts. All books with and isbn10 have an isbn13 — it’s automatic. It does not mean that it is printed in the book obviously. The EAN for a book is the isbn13. The GTIN 13 for a book is the isbn13 number. Lastly converting an isbn10 to isbn13 is easy: just add the prefix and change the check digit. AManWithNoPlan (talk) 18:53, 9 November 2019 (UTC)

Well, none of the above are facts, quick or otherwise, according to the official ISBN manual or the official ISBN issuing authorities. I suggest you go back and check. 24.105.132.254 (talk) 20:51, 9 November 2019 (UTC)

Since you (24.105.132.254) are unwilling to do even a basic google search to see that you are wrong, here are the links. https://www.isbn.org/about_ISBN_standard and https://en.wikipedia.org/wiki/International_Standard_Book_Number#ISBN-10_to_ISBN-13_conversion all isbn10's have an isbn13 equivalent. https://en.wikipedia.org/wiki/International_Standard_Book_Number#EAN_format_used_in_barcodes,_and_upgrading and https://www.barcoding.com/blog/bookland-13-ean-13-and-isbn-numbers-one-in-the-same/ All ISBN13 are EAN. All ISBN's a GTIN https://en.wikipedia.org/wiki/Global_Trade_Item_Number#Format_and_encodings AManWithNoPlan (talk) 00:52, 10 November 2019 (UTC)

Since I was the one who originally used these links on this discussion I know very well what they are about, and the background. 72.89.161.42 (talk) 02:22, 10 November 2019 (UTC)

• I normally copy the ISBN from the indicia of the book. If it's an ISBN-10, a Bot will convert it to an ISBN-13. It did have an instance where the ISBN-10 in the book was incorrect; libraries had filed it both under the incorrect number and the correct one. After a discussion, it was agreed to substitute the ISBN-13. However, we have detected hoaxes based on invalid ISBNs. Hawkeye7 (discuss) 20:21, 9 November 2019 (UTC)

If you add anything that is not published at the source, it makes for an invalid citation. I thought this was clear. How can you "cite" something that is not there? 24.105.132.254 (talk) 20:54, 9 November 2019 (UTC)

The point is that even though the ISBN13 in not in the book, it is still a proper way to refer to the book. Just like journals from 1800 with DOIs and ISSNs and Such . AManWithNoPlan (talk) 23:41, 9 November 2019 (UTC)

Only if the later assignations have been published by reliable sources. If they have been concocted by Wikipedia bots or by anyone else they are not citable material. 72.89.161.42 (talk) 02:22, 10 November 2019 (UTC)

Agree keep ISBN10 there is a better chance of matching the book with other databases which may or may not respected unpublished/concocted ISBN13s -- GreenC 14:27, 18 November 2019 (UTC)

• While it is true that ther is a 1-to-1, fixed mapping between ISBN-10s and 978- ISBN-13s, In the spirit of "say where you got it, books published before, roughly, 2005, should always use the ISBN-10, and no bot or editor should be converting these to ISBN-13s, unless citing to a newer edition. DES ^(talk)_{DESiegel Contribs} 08:06, 9 December 2019 (UTC)

I second this. Unfortunately, CitationBot was doing just this for months without approval and despite complaints.

If the other ISBN is known as well, the alternative ISBN can be added as additional parameter |id={{ISBN|1234567890123}} (it would be even better, if the |isbn= parameter would accept two values rather than only one). On a practical level the two ISBNs are not actually redundant, as both might be used as text search patterns by users, and listing only one of them, users searching for ISBNs in articles may unfortunately fail to find a referenced book due to the embedded checksum (this is why stores almost always list both ISBNs in order to not miss any possible hits). --Matthiaspaul (talk) 22:27, 23 December 2019 (UTC)

Cite journal disallows pages and page params together

I recently added a citation which I wanted to include both a page range, because it's a journal article, and a page, to point to a particular portion of the article, but it has a CS1 error. (diff) Maybe this should be allowed for cite journal? Cheers, Mvolz (talk) 10:59, 23 December 2019 (UTC)

You can use template {{Rp}} to indicate the particular page.   Jts1882 | talk  11:12, 23 December 2019 (UTC)

The in-source location for {{cite journal}} is usually an article, and such locations should be indicated with a page range (an older, much rarer practice cited the first page only). Since articles were historically short, this was deemed acceptable. Adding a second-level location probably overcomplicates things. I would add a shortened reference ({{sfn}}) with its own location to the specific page. Or, a note outside the full reference. 100.33.37.109 (talk) 14:50, 23 December 2019 (UTC)

Or something like |pages=98–109 [101]. Headbomb {t · c · p · b} 17:49, 23 December 2019 (UTC)

I like this notation. I've also seen |pages=98–109 (101). Not being aware that pages accepts free-flow input, personally I have used |pages=98–109, 101 hoping that readers would "get it" that there must be something important with page 101, and editors would not remove it as redundant. However, for consistency it would be better to have a well-defined and documented way to handle cases like this (with or without extra parameter). --Matthiaspaul (talk) 22:35, 23 December 2019 (UTC)

To regular editors of the {{cite book | ... }} template, that have write privileges

To this template, to the section/box entitled "Most commonly used parameters in horizontal format", for each of the examples for which this does not appear, please at least add:

• | page = | pages =

If one of these do not appear in every example, lack of importance might be inferred, which is contrary to WP policies and guidelines.Then, please add any other standard, important field that is normally needed (better empty fields in an example, than the field to be missing). Please, take onto account the preference of WP writers for web-accessible sources (and the fact of inevitable url demise). That is, consider whether every example book citation template should also present:

• | url = | url-status = | archive-url = | archive-date = | access-date =

and possibly:

• | doi = | doi-broken-date =

Finally, in my opinion, at least one further example would be helpful, that of a two-author book with two editors, that is a part of a series, that has an original publication date that is old, and a recent publication date of a newer edition, that is available both in hardcopy, and in a digital paginated form. Add to this access date, and the fields based on the expectation that the url/doi will die.

All from me. Just aiming for no {{cite book | ... }} example to lack a page number, and for all to have needed url fields, and after than, hoping for an example that has essentially everything that is generally needed for citing scholarly secondary academic sources (which is our aim, I understand), Cheers. 2601:246:C700:9B0:A57B:85B4:7889:AE7D (talk) 15:42, 9 December 2019 (UTC)

While I tend to agree about page numbers, book citations are primarily to the printed text, and a URL to a convenience copy is in no sense required, still less a DOI, which msot books do not have. Even an ISBN is not required, and for older books there may not be one. url-status and the various archive parameters are not required even for {{cite web}} much less for {[tl|cite book}}. We should not imply that an online version is expected, much less required. DES ^(talk)_{DESiegel Contribs} 18:40, 24 December 2019 (UTC)

Small bug with Cite web and Visual editor

When using the Cite function to add a URL in the VisualEditor, the |subscription= parameter is still available even though it has been deprecated. - Samuel Wiki (talk) 16:05, 26 December 2019 (UTC)

Deprecated does not mean unsupported; |subscription= and |registration= are still valid supported parameters. Likely these two parameters will become unsupported at the next module-suite update.

—Trappist the monk (talk) 16:11, 26 December 2019 (UTC)

I figured out it was coming from TemplateData and set the parameters to deprecated status. - Samuel Wiki (talk) 16:44, 26 December 2019 (UTC)

There is a problem with the edit that you made. {{cite web}} does not support |chapter= or |cite entry= so template data should not recommend replacement of |subscription= and |registration= with |chapter-url-access= and |entry-url-access=. You might want to fix that.

—Trappist the monk (talk) 16:52, 26 December 2019 (UTC)

Fixed. - Samuel Wiki (talk) 17:25, 26 December 2019 (UTC)

New url-status needed: content-missing

We might need a new url-status value (or two); maybe something like content-missing or no-data, for urls which are not dead, not usurped, not unfit (per discussions here and here), but which bring up the correct website, display readable content on the page like a containing header and footer with the expected website boilerplate there, but with the "meat and potatoes" portion in the middle blank, missing, or otherwise not able to verify the content of the article.

Example: this page should (and at one time, did) have the results of the Brazilian presidential election of 2002 (and others, via radio button) but no longer does; instead, the central frame of the website is an empty gray box. None of the current |url-status= values express the fact that this url still belongs to the owner, still comes up, but contains no useful information capable of verifying content in a Wikipedia article. (In this case, the internet archive doesn't help; among 67 captures at Archive.org, it's no better (spot-checked a few). But that won't always be the case.)

I wish I had a better example, where the current website was a gray box, but Archive.org still had a valid capture showing the original page with complete data present (which I expect is a more common case), because that would be easier to deal with: the linked title should go to the archived page in that case instead of the url value; i.e., the action is similar to the status=dead-url, except "dead" is inaccurate since the original url is still live, just useless. In the example I gave, the action should actually be different, with the title being in plain-text, unlinked. It may be we need two new statuses then:

• url-status=content-missing – url is live and identifiably the correct page but needed data is absent; archive is good: link the title to the archive.org capture
• url-status=content-inaccessible – url is live and identifiably the correct page but needed data is absent; archive either doesn't exist, or exists but also has missing data: unlink the title.

The actions required by these two cases may match actions associated with already existing values, and in that sense the new values (action-wise) are aliases of existing values. That would be a win for implementation, but the option of having new values would still be valuable in giving a clear and proper name to the cases. For example, the action for the first bullet is equivalent to the action for |url-status=dead; but imho it would be confusing to use the word "dead" for this case merely to elicit the proper action when the url in that case is so clearly not dead, and would confuse citation template users no end. Thanks, Mathglot (talk) 07:06, 11 December 2019 (UTC)

Isn't this already covered by |url-status=unfit? —David Eppstein (talk) 07:09, 11 December 2019 (UTC)

Did you read the discussions linked at "here and here" in the first sentence? Mathglot (talk) 07:12, 11 December 2019 (UTC)

Sure, but I don't see anything there that would make it not fit this case. Although less harmful than being hijacked by malware, I'd say that a blank page still meets the description of "generally inappropriate". And if a url is not working any more, I don't see the point in putting effort into a fine-grained classification of exactly the manner in which it is not working. —David Eppstein (talk) 08:22, 11 December 2019 (UTC)

As near as I can tell from the wandering path taken by unfit and usurped (see this comment by Trappist above), the actions don't match; but I could be mistaken. Also, the url is working, and it's decidedly not a blank page; it is identifiably the correct page. That's the whole point. Mathglot (talk) 08:35, 11 December 2019 (UTC)

Pinging @Izno and Mindmatrix: Mathglot (talk) 07:17, 11 December 2019 (UTC) and @Jonesey95, Jc3s5h, and GoingBatty:. updated by Mathglot (talk) 08:15, 11 December 2019 (UTC)

The document at that URL is functionally broken. It should return a 404 or even a 500 if it were coded properly, so I'd consider it "dead" and it's certainly "unfit". Nemo 11:14, 11 December 2019 (UTC)

|url-status= has no meaning to cs1|2 without the citation also has |archive-url=. Because what en.wiki cares about is source content, this citation is as good as dead. I was going to suggest that {{failed verification}} might be added to a citation with that url but that template requires at 4 that "the source still contains useful information on the topic". The example url does not meet that requirement. The advice at {{failed verification}} when the source has "no relevance to any part of the article" is to delete the citation and add {{citation needed}}. The url may once have supported the article text (we don't know but WP:AGF, it did). Marking the citation with {{dead link}} will, I think, bring it to the attention of IABot or others which will dutifully find one of the several archived empty snapshots at archive.org, add |archive-url=, delete {{dead link}}. No benefit there.

Perhaps what is needed is not a change to cs1|2 but some sort of new template that occupies the space between {{dead link}} (because the link isn't) and {{failed verification}} (because no "useful information on the topic"). Until a new source can be found, we want to continue to say that once-upon-a-time this article text was sourced but now cannot be verified due to a form of link rot; perhaps: {{content missing}} (surely there is a better name); something that would not cause IABot and friends to add useless blank snapshots but would serve as a flag for editors who might be induced to find a working or archived source as a replacement.

—Trappist the monk (talk) 13:49, 11 December 2019 (UTC)

Trappist, I like your suggestion, and your comments about the in-between world. And like you, I had also considered various things, including definitely the {{failed verification}} idea, which however didn't seem quite enough all by itself. I like your idea of a new template. And again, I agree that surely there must be a better name; I tried to think of some, and just couldn't come up with a good one yet; I thought about all sorts of things about missing middles, like bagels and donut holes and taxidermy and Mayan sacrifice and 'data eviscerated' but none of those seem serious or appropriate or suggestive enough; and the last few sound ominous. Maybe a new, optional param attached to {{failed verification}}? Although, if we could come up with a good name for the param, then we'd have the name for the new template. The other reason I like your suggestion, is because it avoids having to complicate an already complicated situation here.

I'd like to hear from others, to see what they think. If there is consensus for a new template along the lines of what you suggest, then the CS1 doc for url-status should certainly mention it, so that folks attempting to code a {{citation}} and running into this situation, could be guided to the template, rather than performing contortions with {{citation}} or using improper values of url-status. Mathglot (talk) 22:58, 11 December 2019 (UTC)

If the link does not verify the citation, and there is no archive link proving otherwise, the link should be removed. Whether such original link at some point did verify the citation is irrelevant. Citations must verify in real time, not at some point in the past or the future. There is no assumption of good faith here: the link either helps to verify the citation or it doesn't. This is not an unfit url, the parameter itself is unfit for inclusion. I remember a fairly extensive discussion on this issue not too long ago. Again, my comments only concern urls without counterparts in reliable archives. 24.105.132.254 (talk) 21:17, 12 December 2019 (UTC)

Usually called a soft 404. They should be status 404, but the site is poorly maintained, it reports 200 even though the original page no longer exists or works (redirects to homepage is common). They are difficult to detect with automated processes. The best action is treat as dead. -- GreenC 01:30, 13 December 2019 (UTC)

I've recently ran into a similar situation trying to verify some references from Indian and US newspapers, which only display a message like "we are currently not providing access or use of our website/mobile application to our users in Europe". Probably, this is down to the General Data Protection Regulation (GDPR/DSGVO). I was considering to use |url-status=usurped, but then used |url-access=limited. I agree that a special option like |url-access=regional or |url-access=GDPR-blocked (or something along that line) might be useful. --Matthiaspaul (talk) 23:09, 23 December 2019 (UTC)

Those are policy blocks. They come and go with arbitrary decree, and are relative to viewer location. What is blocked for one reader is not blocked for another. What is blocked today is unblocked tomorrow. There is no way Wikipedia can maintain that information. BTW these probably should not be set to |url-access=limited which concerns limited for all readers (if we follow the given examples). Wikipedia is not designed to deal with policy blocks, such as Turkey and China. The permutations are endless and constantly changing. -- GreenC 02:19, 24 December 2019 (UTC)

Not a soft 404. Page still exists at the original location, still contains some of the boilerplate content including correct page title, radio button selections for selecting specific years, and so on. A soft 404 is not that, but typically a server trapping a page, that like you said, no longer exists, and putting up substitute material, such as, "Hmm... that page seems to be missing. Try our site map.." or some such. This is nothing like that. This is the original page, in its proper place, with some of the proper material, but with the guts of the content hollowed out or missing. This doesn't affect the utility or benefit of Trappist's suggestion pro or con; but I don't agree that calling ita dead url is correct, as "dead url" has a specific meaning. This url is still owned by the domain owner, the url is not a soft 404, and the url still presents some data, but not the crucial data required for verifiability. That simply isn't a dead url. In my view, this is closer to an online news article that used to verify an assertion a month ago, but has since been significantly updated, and no longer does, with no archive of the earlier one available. Mathglot (talk) 08:18, 29 December 2019 (UTC)

template-doc-demo should be a bad parameter in the mainspace

I was about to recommend the use of |template-doc-demo= for another user but it turns out that I had a faulty assumption in mind: It currently disables error categorization in the mainspace. I do not believe that is the intent of the parameter and do believe that placement in the mainspace should cause the parameter to be disabled (or emit its own error message). --Izno (talk) 23:08, 28 December 2019 (UTC)

At the moment, it appears that it is used in one place in article space (Paleocene, in case the search link no longer works) because that article contains a valid DOI ending in a period (full stop), which the module currently flags as an error. If we are to flag this usage somehow, I recommend a CS1 maintenance category for uses of |template-doc-demo= in article space, for situations like this where the module has not yet been updated and a red error message should not be displayed. – Jonesey95 (talk) 01:20, 29 December 2019 (UTC)

Such cases should probably use a wikitext comment to explain why the parameter throws an error (for the time being). I would certainly prefer an error; we have too many hidden maintenance messages as is. Maintenance messages should be reserved for when a page should be checked-in-on rather than obviously fixed (as with our ISBN-ignored category). --Izno (talk) 02:25, 29 December 2019 (UTC)

If the functionality of |template-doc-demo= is do as its name indicates, then it certainly should not be used in article-space. If its aliases |no-cat=, |nocat=, |no-tracking=, and |notracking= are indicators then perhaps it could be used in article-space. The parameter's documentation is not a stellar example of clarity or, more importantly, accuracy:

template-doc-demo: The archive parameters will be error-checked to ensure that all the required parameters are included, or else {{citation error}} is invoked. With errors, main, help and template pages are placed into one of the subcategories of Category:Articles with incorrect citation syntax. Set |template-doc-demo=true to disable categorization; mainly used for documentation where the error is demonstrated. Alias: no-cat.

cs1|2 does not invoke {{citation error}} nor does it use Category:Articles with incorrect citation syntax (it once did via {{citation/core}}). The first two sentences of the |template-doc-demo= documentation should go away.

The point about the 'unique' doi with required terminal punctuation seems to me to be a different sort of thing. That is a case where we want to suppress the error message and the category. For other parameters we have provided the doubled parentheses markup to tell cs1|2 that it is to accept this value as written. At some point, perhaps we will come to the decision that any parameter value that can cause cs1|2 to emit an error message should allow the accept-this-value-as-written markup. Then, |template-doc-demo= and aliases will be disabled in article-space and |ignore-isbn-error= goes away.

—Trappist the monk (talk) 14:45, 29 December 2019 (UTC)

deprecated parameters

I have removed support for the last few remaining deprecated parameters: |ASIN-TLD=, |class= (still supported by {{cite arxiv}}), |registration=, and |subscription=.

—Trappist the monk (talk) 18:41, 30 December 2019 (UTC)

When is url-status=unfit to be used?

I do not understand when url-status should be set to unfit. What is this setting for? The documentation doesn't seem to say what cases it is supposed to be used in. Thanks! DemonDays64 (talk) 00:46, 28 December 2019 (UTC)

Achieving clarity on that question has eluded us. See Help talk:Citation Style 1 § spam black list and archive urls (currently at the top of this page so likely soon to be archived). There is some history there.

—Trappist the monk (talk) 01:07, 28 December 2019 (UTC)

The classic use case is when a domain has expired and hijacked by spammers, malware or porn sites. We don't want those links displayed. They are no longer "fit" for Wikipedia. -- GreenC 01:56, 28 December 2019 (UTC)

• I would think that ought to be url-status-=usurped A distinction without much difference in effect. And there is the related use case: The site is still valid, and is not porn or anything, but the content at the specified url has been changed so that it no longer supports the statement it is being cited for. This could use url-access=unfit, in that it is no longer fit for Wikipedia's purposes. Personally, I would like to see support for url-access=changed (or perhaps "altered") for this specific use case, but I can't say that doing so is vital. DES ^(talk)_{DESiegel Contribs} 19:25, 30 December 2019 (UTC)

Request for new url-access value(s)

I encounter a number of cited sources, particularly in medical refs cited via PMID, but in various other contexts as well, where a part of the source is made free for anyone to see (often a abstract for scholarly papers, or the first 2-3 paragraphs for a newspaper), but the full text is behind a paywall. Sometiems the visible part is all that is needed to support whatever content it is cited for, sometimes the paywalled part is needed. In any case it seems to me that we need a new value supported for |url-access=. "subscription" is not right, because a significant part of the source is visible without a subscription. Would url-access=partial work? Do we want to try to have different values depending on whether the part of the source being used is hidden or not? DES ^(talk)_{DESiegel Contribs} 19:35, 30 December 2019 (UTC)

|url-access=limited works here IMO. --Izno (talk) 21:25, 30 December 2019 (UTC)

Nothing is needed, since a PMID url will be redundant to the identifiers and should be removed. If the source is paywalled behind a url that isn't redundant to identifiers, then |url-access=subscription is the one. It doesn't matter than an excerpt is freely available, what matters is the full source. Headbomb {t · c · p · b} 22:41, 30 December 2019 (UTC)

I must disagree. If the abstract or a relevant except is publicly visible, that may well be enough to verify the statement nin nthe article, and if it is, a reader who might otherwise have noticed the subscription needed icon and ignored the cite could usefully verify. This is true whatever url is being used, if it is paywalled but with a significant excerpt public, in my view. thr value limited is batter than nothing, but a more specific value would be a good idea, I think. DES ^(talk)_{DESiegel Contribs} 01:09, 2 January 2020 (UTC)

Agreed with the use of |url-access=limited when an excerpt/abstract is available. "Limited" includes "partial" (among other cases), and is good enough. Proliferation of parameter options to cover every single case (or class of cases) that appears should imo be avoided. 72.43.99.138 (talk) 16:04, 2 January 2020 (UTC)

Limited is not ok. If you need to point out that you're citing the abstract specifically, then have |at=Abstract, or "See abstract in {{cite xxx}}". Abstracts are always free, so there's no need to point out that the abstract is free while the rest of the article isn't. Headbomb {t · c · p · b} 17:30, 2 January 2020 (UTC)

Yes, abstracts are free. And it seems they can be mostly found at the article url, although abstracts are similar to reliable annotations, and not technically a part of the article. So we can have a situation with two access variables "at this url there is 1. free access to a source abstract 2. paywalled access to the source" or with one "at this url there is limited access to the source". The second option is not perfect. But it is simple, and it does the job, since it covers the particular case. And if the abstract fully supports the wikitext, then access to proof is free, and no signaling is required. As a reader verifying the wikitext, I would have no need to venture into the article further. 24.105.132.254 (talk) 21:45, 2 January 2020 (UTC)

• 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. Headbomb {t · c · p · 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. Headbomb {t · c · p · b} 17:30, 3 January 2020 (UTC)

Update to the live CS1 module weekend of 11–12 January 2020

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)

Cite arxiv displaying "ignored" parameters

There is something weird in the current {{cite arxiv}} code that is causing the following to display an "ignored" error... while also displaying the parameter which is supposedly ignored (I noticed on my random trawl through the archives). See here where |publisher=Publisher is displayed, as is |accessdate=:

Cite arXiv comparison

Wikitext	{{cite arXiv|accessdate=3 March 2014|arxiv=0711.2260|class=quant-ph|date=2002|first=Elio|journal=Proceedings Fundamental problems of Sciences, 271-304, S. Petersburg 2002|last=Conte|pages=271-304|publisher=Publisher|title=A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics|url=https://arxiv.org/abs/0711.2260v1}}
Live	Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". pp. 271–304. arXiv:0711.2260 [quant-ph]. {{cite arXiv}}: Unknown parameter |accessdate= ignored (help); Unknown parameter |journal= ignored (help); Unknown parameter |publisher= ignored (help)
Sandbox	Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". pp. 271–304. arXiv:0711.2260 [quant-ph]. {{cite arXiv}}: Unknown parameter |accessdate= ignored (help); Unknown parameter |journal= ignored (help); Unknown parameter |publisher= ignored (help)

--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 journal}}; {{cite arxiv}} is a pre-print citation template that supports only those parameters that are relevant to a pre-print. {{cite biorxiv}}, {{cite citeseerx}}, and {{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. Headbomb {t · c · p · 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)

Cite web discussion over at MoS:Film

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)

Problem with "." separator in front of work or series info in conjunction with titles ending on "?" or "!"

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:

Cite web comparison

Wikitext	{{cite web|title=Title?|url=http://www.example.com|work=Website}}
Live	"Title?". Website.
Sandbox	"Title?". Website.

Cite web comparison

Wikitext	{{cite web|title=Title.|url=http://www.example.com|work=Website}}
Live	"Title". Website.
Sandbox	"Title". Website.

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)

Problem with journals, magazines (and books) using all three parameters: volume, issue and number

As discussed before there are journals, magazines (and even books) which define values for |volume=, |issue= and |number= - for example Dr. Dobbs Journal, Minolta-Spiegel etc.

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 this. Headbomb {t · c · p · 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)

Undesired silent suppression of some parameters by cite book and cite web templates

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)

Documentation for interviewer= updated

After a discussion at WP:VPT, I have updated the documentation for |interviewer= based on the documentation for the |author= parameters. You can see the updates at {{cite interview}}. Error corrections are welcome. – Jonesey95 (talk) 22:21, 15 January 2020 (UTC)

Some SSRN documents now require payment

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 an NBER Working Paper I cited today (that's a wikilink to the footnote). ¶ Therefore, it seems we will (eventually) need a method to indicate that an SSRN paper is not free. (I tried ssrn-access=subscription but that parameter doesn't exist.) I don't see this as a top priority—I simply wanted to bring it to the attention of folks who know how address little problems like this one. My solution today was to just leave out the SSRN link as interested readers will find it on the NBER page for the paper anyway. Thanks! - Mark ¶ P.S. My apologies if this is old news. I did search the archives but didn't find anything.   - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 04:47, 15 January 2020 (UTC)

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. Headbomb {t · c · p · 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)

Access date with signs

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)

DOI prefix errors

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.

Headbomb {t · c · p · b} 18:03, 29 December 2019 (UTC)

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 {{doi}}, with a error 'invalid registrant' or shove em in the existing categories of invalid dois. And DOI.org have never published a list of registrant, sadly. I've been in contact with them about it, and they leave that to DOI assigning agencies like CrossRef and Datacite. Headbomb {t · c · p · 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. Headbomb {t · c · p · 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)

@Trappist the monk: seems I've overlooked a special case: {{doi}} is a legit DOI apparently. So 3 digits after 10. in the doi prefix structure 10.d.d, but not in 10.d. Headbomb {t · c · p · 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. doi:10.978.300/0415395. 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. Headbomb {t · c · p · b} 17:37, 13 January 2020 (UTC)

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

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

|year= fails with non-Latin script

Cite book comparison

Wikitext	{{cite book|first=سيد يوسف|last=شاه|location=لاھور|pages=١٦٠-١٦١|publisher=محمدی پریس|title=حالات مشوانی|year=١٩٣٠}}
Live	شاه, سيد يوسف (١٩٣٠). حالات مشوانی. لاھور: محمدی پریس. pp. ١٦٠-١٦١. {{cite book}}: Check date values in: |year= (help)
Sandbox	شاه, سيد يوسف (١٩٣٠). حالات مشوانی. لاھور: محمدی پریس. pp. ١٦٠–١٦١. {{cite book}}: Check date values in: |year= (help)

~/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)

CS1 / Visual Editor copy-paste bug apparently fixed

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)

@Jonesey95: good task for a bot? Headbomb {t · c · p · 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)

i18n: miscellaneous fixes

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)

ISBN and e-book ISBN

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)

Date not flagged as error

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)

Cite web comparison

Wikitext	{{cite web|access-date=26November 2019|date=11July 1998|publisher=Goethe|title=PEDESTAL OF THE SOCALLED "PEACE MEMORIAL“|url=https://www.goethe.de/ins/ca/en/kul/sup/dsk/dstu/fvp.html}}
Live	"PEDESTAL OF THE SOCALLED "PEACE MEMORIAL"". Goethe. 11July 1998. Retrieved 26November 2019. {{cite web}}: Check date values in: |access-date= and |date= (help)
Sandbox	"PEDESTAL OF THE SOCALLED "PEACE MEMORIAL"". Goethe. 11July 1998. Retrieved 26November 2019. {{cite web}}: Check date values in: |access-date= and |date= (help)

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

Ability to use more than one chapter in Template talk:Cite book

Hello, is it possible that a dev add the ability to have multiple |chapter= in Template talk:Cite book? It would be useful if,for example, one is to use sources from the same book but from different chapters. Veverve (talk) 01:46, 29 January 2020 (UTC)

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)

Bolding of the volume number

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. Headbomb {t · c · p · 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:

	Book	Journal
Current	3, pp. 12–56.	3: 12–56.
Proposal 1	vol. 3, pp. 12–56.	3: 12–56.
Proposal 2	vol. 3, pp. 12–56.

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. Quark ref 13 that this refers to the volume, and this is a great and concise visual format in scientific articles, and what is recommended by most style guides. At the same time, while grating, having an explicit vol. #, iss. #, pages #-# isn't completely the worst, however headaches will abound when people get confused/angry by issue vs number. Could probably be avoided with "vol. A, #B, pages C" or similar though. Headbomb {t · c · p · b} 21:39, 6 February 2020 (UTC)

Fully against full text though. That's just a waste of space and time. Headbomb {t · c · p · 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)

Para ref causes extra punct maintenance category

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. Headbomb {t · c · p · 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.
•  ———  (1962). "Theism and Utopia". Philosophy. 37 (140): 153–158. doi:10.1017/S0031819100036810. ISSN 1469-817X. 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)

Use high-resolution icons

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:

Extended content

Old New .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)

Footnote and endnote parameters needed

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 (talk) 19:13, 8 February 2020 (UTC)

@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. --John Maynard Friedman (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=End matter and |at=End matter, p. [number], n. [number]. Edit: I moved "End matter" to |at= because only a limited number of special front/back sections are not quoted by the module. 98.0.246.242 (talk) 22:08, 8 February 2020 (UTC)

As Jc3s5h observes, the article where this question arose is indeed a mess of various citation styles. I made the mistake of thinking I could clean them up using a mobile (cell phone). Not a good idea. Thank you all for the suggestions, I will review the whole article when I have time to do it properly. --John Maynard Friedman (talk) 08:29, 9 February 2020 (UTC)

add chapter-archive-url

The template provides an archive-url parameter but does not provide an equivalent parameter for the archive of the chapter-url. It would be useful to provide an archive for the referenced chapter when chapter-url is present. Adding chapter-archive-url would need chapter-archive-date, chapter-url-status, and chapter-access-date parameters. Whywhenwhohow (talk) 20:48, 9 February 2020 (UTC)

There are half a dozen "-url" arguments. I think we are archiving any one of them, of which |archive-url= is the placeholder. Suggest extra archives added to {{webarchive}} which can hold up to 10. -- GreenC 20:59, 9 February 2020 (UTC)

How do I cite a Russian webpage with translation from a Latin book?

I need to cite several webpages with modern (2011) scholarly translations into Russian of mediaeval Italian chronicles written in Latin, translated from their 19-century publication in book series form printed in Germany. GregZak (talk) 09:21, 10 February 2020 (UTC)

Cite the source that you consulted; see WP:SAYWHEREYOUREADIT. If you consulted a Russian-language website where the content is taken from a German book, cite the website. If the Russian website holds a facsimile of the German book, cite the website as a book.

It is always true that examples of what you want to do will aid editors here in their attempts to help you.

—Trappist the monk (talk) 12:56, 10 February 2020 (UTC)

Nomination for deletion of Module:Citation/testcases

Module:Citation/testcases has been nominated for deletion. You are invited to comment on the discussion at the module's entry on the Templates for discussion page. * Pppery * _{it has begun...} 01:44, 11 February 2020 (UTC)

language parameter tweak

I've tweaked |language= handling so that it accepts ISO 639-2, -3 codes with IETF tags (yue-HK); ISO 639-1 with IETF tags already accepted.

Cite book comparison

Wikitext	{{cite book|language=yue-HK|title=Title}}
Live	Title (in Cantonese).
Sandbox	Title (in Cantonese).

—Trappist the monk (talk) 18:46, 10 February 2020 (UTC)

Thanks, Trappist the monk! Immediately a big change to Category:CS1 maint: unrecognized language. What are the new codes that are accepted? Can they be added to Template:Citation Style documentation/language/doc? = paul2520 (talk) 13:50, 11 February 2020 (UTC)

Umm, nothing has happened. The change that I made was only to the sandbox. I trolled through Category:CS1 maint: unrecognized language yesterday with an awb script and then manually. Both those efforts cleared a couple of hundred articles from the category and was the impetus for the sandbox fix that I made (one article with the yue-HK IETF language tag).

The content of Template:Citation Style documentation/language/doc will not change as a result of this fix. Module:Citation/CS1 accepts language codes with various tags but those tags are discarded. The listed codes and languages are the codes and languages that MediaWiki defines augmented with a very limited list of codes and languages that cs1|2 has overridden or added. When MediaWiki changes their list, the list at ~/language/doc will automatically reflect that change.

—Trappist the monk (talk) 14:26, 11 February 2020 (UTC)

i18n: wikisource tweak;

Because there are different language versions of wikisource, en.wikisource should not be hard-coded into Module:Citation/CS1. Tweaked the sandbox to use the local language's language code (from Module:Citation/CS1/Configuration) as the second-level domain name.

—Trappist the monk (talk) 15:36, 14 February 2020 (UTC)

Script to detect unreliable sources

Main page: User:Headbomb/unreliable

I have (with the help of others) made a small user script to detect and highlight various links to unreliable sources and predatory journals. The idea is that it takes something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14. (John Smith "[https://www.deprecated.com/article Article of things]" ''Deprecated.com''. Accessed 2020-02-14.)

and turns it into something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14.

It will work on a variety of links, including those from {{cite web}}, {{cite journal}} and {{doi}}.

I'm still expanding coverage and tweaking logic, but what's there already works very well. Details and instructions are available at User:Headbomb/unreliable. Questions, comments and requests can be made at User talk:Headbomb/unreliable. Headbomb {t · c · p · b} 13:04, 19 February 2020 (UTC)