Help talk:Citation Style 1/Archive 43

Latest comment: 6 years ago by Trappist the monk in topic script-title and no title
Archive 40Archive 41Archive 42Archive 43Archive 44Archive 45Archive 50

Alias acdate for access date

Among perhaps 200 common cite errors (such as "access date=" for "access-date="), the word "access" causes many problems. I propose using "acdate=" for access dates, and making "accessdate=" as the older form. Users often misspell the long name, as from Spanish "acceso" (with one "s") or Portuguese "acesso" (with one "c") and even 3-letter c-or-s forms (like "acccessdate="). As a result, about 10% of cite errors misspell "accessdate=" while "acdate=" would avoid hundreds of cite errors per month (but allow old "access-date="). -Wikid77 (talk) 12:16, 21 April 2018 (UTC)

That wouldn't solve anything, because people will still try to write accessdate, and make the typo. We're not suggesting |tit= as an alias of |title= because many people write |tilte= by accident. Headbomb {t · c · p · b} 15:54, 21 April 2018 (UTC)
about 10% of cite errors misspell "accessdate=" .. is that really true? If so, it's trivial for a bot to fix and should be running full-time given the scale of the problem. But would need evidence to get bot approval. Do you happen to have a list of common misspellings? Then I can run monitoring/logging searches for a while and see how many show up. -- GreenC 15:59, 21 April 2018 (UTC)
Troll through Category:Pages with citations using unsupported parameters because that will be where misspelled parameter errors end up.
Trappist the monk (talk) 16:08, 21 April 2018 (UTC)
That's good. Looks like a large variety of problems not just accessdate. Sort of like building a spam filter. CS1 sometimes provides suggested alternatives in red, how does it do this, is there a table of common mistakes and alternatives? -- GreenC 13:33, 22 April 2018 (UTC)
There is a list of common misspellings and non-English parameter names in Module:Citation/CS1/Suggestions. If the incorrect parameter name is found in the list, Module:Citation/CS1 offers the recommended parameter name. If the parameter is correctly spelled but case is wrong, Module:Citation/CS1 offers the correct name in lowercase.
Trappist the monk (talk) 14:16, 22 April 2018 (UTC)
What would you think about a bot that keyed off the Suggestions table to automate corrections ie. if it sees a |annodiaccesso= in one of the English-language citation templates, it changes to |accessdate=. The bot would only target articles in Category:Pages with citations using unsupported parameters. The bot would ignore wrapper templates like {{Citar web}} (Portuguese). -- GreenC 15:03, 22 April 2018 (UTC)

(new discussion starts here about Category:Pages using citations with accessdate and no URL)

You could. WP:BRFA is that way →. A better use of your talents, I should think, might be the creation of a bot that could interface to WikiBlame and thereby help solve the backlog that is Category:Pages using citations with accessdate and no URL by removing |access-date= from cs1|2 templates that never had a value assigned to |url=. This would be of much greater benefit to the project. Does WikiBlame have an api? Could an api be added?
Trappist the monk (talk) 16:21, 22 April 2018 (UTC)
Yeah ok just want to make sure wasn't missing anything. WikiBlame not sure how. Example 1965 MGM vault fire (ref #1) WikiBlame can't find the original edit. It's difficult as it requires knowing what the original cite looked like. Every field in the cite may have been subsequently modified since it was originally created, what text to search WikiBlame with? Though in this case it has a |jstor= which is probably the intended |access-date= target. It might cut down on the number of errors by ignoring cites containing other types of external links, such as |jstor= and |chapter-url= etc.. -- GreenC 23:56, 22 April 2018 (UTC)
Yes it can. I gave this to WikiBlame: '|accessdate=21 March 2018' and it found this edit. |access-date= can go away.
|access-date= applies to |url= and to |chapter-url=, not to identifier links |doi=, |jstor=, ... because the content at an identifier link is considered permanent so does not require an access date to identify the point in time that the source supported our article. But, we cannot know without inspection that the editor who added |access-date= meant it to accompany a now-non-existent |url= or as you suggested meant it to accompany an identifier.
I get that things get modified at Wikipedia. It would be nice if WikiBlame were somehow less 'strict'. This is no simple problem which is why there are so damn many articles in that single category.
Trappist the monk (talk) 00:51, 23 April 2018 (UTC)
Also the accessdate date could have been modified after the original insertion. And there could be other cites with the same accessdate added in an earlier edit then the one looking for. The more one looks, the more difficult it gets. The problem is intractable enough consider instead using approximate procedures. Like if |jstor= (or any identifier) and empty/missing |url= assume the access-date was for the |jstor= and not for a missing URL (which if it ever existed was probably a URL to JSTOR and correctly replaced with the identifier method - probably by an AWB script). It might get it wrong sometimes, but an error rate is acceptable. Run it on x# cases and manually check the results to see what the error rate is. I bet it would be acceptable. -- GreenC 02:55, 23 April 2018 (UTC)
History. I am all in for a bot that removes |access-date= from cs1|2 templates that do not have a value assigned to |url= but do have values assigned to any of the various 'permanent-record' identifiers. {{cite web}} should probably be excluded from the bot's operation (though I have seen any number of cases where {{cite web}} was misused when {{cite journal}} or {{cite magazine}} would have been the appropriate choice.
Trappist the monk (talk) 11:48, 23 April 2018 (UTC)
{{cite web}} is going to be the bulk of citation types so I think we should include it initially. Can monitor the first cases to make sure it's not missing URLs hidden in the diffs. It will start slow in small batches, halted, checked, modified, restart etc.. flexible depending what is uncovered. Good to have your initial acceptance, that and this discussion will weigh in on the BOTREQ approval. To clarify, it would be a bot dedicated to Category:Pages using citations with accessdate and no URL and not the previously discussed Category:Pages with citations using unsupported parameters which would be a different project. I have some other work to finish but will get to this soon. -- GreenC 14:26, 23 April 2018 (UTC)
{{cite web}} requires that a url must be assigned to |url=. When {{cite web}} templates do not have a |url=url, those templates cause the article to be categorized in Category:Pages using web citations with no URL. Of course if {{cite web}} is without |url= but has |access-date=, that article will appear in both categories. I do not think that removing |access-date= from {{cite web}} templates that do not have |url= is a good idea. If a {{cite web}} template does not have |url= but does have an identifier, that may be grounds for using a different template and is perhaps out of scope for this bot task.
Trappist the monk (talk) 14:47, 23 April 2018 (UTC)
Ok. I'll need help which cite templates to target if not cite* -- GreenC 00:26, 24 April 2018 (UTC)

Bot request: Wikipedia:Bots/Requests_for_approval/GreenC_bot_5 -- GreenC 02:56, 24 April 2018 (UTC)

@Trappist the monk: - would this be applicable to both general use and specific-source CS1 templates, or only the former? Assuming general only. -- GreenC 18:19, 24 April 2018 (UTC)

I guess that this bot task should apply to just the cs1|2 templates; it can be expanded later if there is reason to believe that there would be benefit in that. I think that you can safely omit {{cite web}}, {{cite podcast}}, and {{cite mailing list}} from consideration because all of these require |url=.
Were it me, I would argue for removal of |url= when it obviously matches an identifier; I'm thinking primarily of worldcat urls and |oclc= which is something I've been seeing a lot of recently; more silliness that is ve I think.
Trappist the monk (talk) 00:25, 25 April 2018 (UTC)
Ok it's now set to use all the cites in this category minus those three. I think the url=identifier would be have to be a different task because it would process a different and larger set of articles and I think people might freak out a little more about removing a URL versus removing a stray access-date which has clear CS1 documentation supporting it. -- GreenC 14:34, 25 April 2018 (UTC)

I tested the bot on 1000 articles dry-run. It fixed about 17 articles (80 cites). Less than 2% rate. I added in {{cite web}} and it went to 2.5% - this is disappointing, it will make a dent in the tracking category, maybe 800-1000 articles out of 45,000. Any other strategies you can you think of besides checking for an identifier? -- GreenC 20:18, 25 April 2018 (UTC)

Did you test on a random sample of 1,000 articles from the category, or from the start of the alphabet? It is possible that someone has been working their way through this category from the start of the alphabet, which would reduce your hit rate. A random sample may give you better results. Also, fixing 1,000 articles would be great, and we might learn something about how to proceed from the pages that remain. That is how we trained a bot to fix articles in the CS1 date error category: let it run through the category and fix the easy ones, then look at what is left to see what other patterns we could add to the bot's code. – Jonesey95 (talk) 21:21, 25 April 2018 (UTC)
It's random not alphabetical. A 2% fix rate doesn't narrow it down. Pick one at random and chances are it's not among that 2% that would be fixed. Any suggestions appreciated. -- GreenC 21:33, 25 April 2018 (UTC)
I went to the "Mo" section of the alphabet and found the following cases in 20 sample articles:
  • Cite news and Cite journal with an access date but no URL. This was at least half of the errors. Per the documentation, "Access dates are not required for links to published research papers, published books, or news articles with publication dates." What I infer from those instructions is that if there is no link, and the source is a paper, book, or news article with a publication date, we don't need an access date. If a publication date is provided in Cite news or Cite journal, we could remove access dates. We could ask here for consensus to do this as a bot task (and to make the instructions just a bit more clear so that I do not have to infer).
  • Cite book with an ISBN, as in Mobberley. Remove access date.
  • A few oddball cases that need to be handled manually, sometimes by finding a web page to match the reference.
Question for all: If a reference cites a published research paper, published book, or news article with a publication date, can we remove the access date? Sorry for the bolding. There is just a lot of text here, and I wanted to emphasize that there is a significant question here. – Jonesey95 (talk) 05:12, 26 April 2018 (UTC)
The access date serves two purposes:
  1. For urls that lead to pages that may change and do not have a clear 'publication' date, it identifies the version that was used as the reference.
  2. For urls that lead to pages that do not change, such as those that contain a PDF copy of a published journal article or a scan of a book, it can indicate the likelihood of the pages still being there, and may help in locating an archived copy if they are not.
So the underlying question is whether we believe that the access date should serve only purpose (1). Peter coxhead (talk) 06:23, 26 April 2018 (UTC)
In these cases there is no |url= so we don't know if the access-date serves the purpose of (1), (2) or neither. This is approximate reasoning, can be we approximate that the lack of a |url= in a {{cite journal}} with a |date= and |access-date= -- can the |access-date= be removed based on the approximate rationale there never was a |url=, the |access-date= was made in error and the |date= is sufficient to find the journal article. -- GreenC 13:12, 26 April 2018 (UTC)
I think that (1) and (2) above are both valid, but as GreenC says, if there is NO url and the access date does not provide information that helps a reader locate the cited source (keep in mind that it is not displayed to the reader when there is no url!), we should just remove it. I would like to hear other opinions, either agreeing or disagreeing, with a rationale. – Jonesey95 (talk) 17:09, 26 April 2018 (UTC)
This thread is getting long and buried so I summarized below. -- GreenC 15:25, 27 April 2018 (UTC)

@Jonesey95: - excellent ideas. I am willing and ready to program the bot to remove |access-date= from {{cite book}}, {{cite journal}} and {{cite news}} based on the criteria given above. -- GreenC 16:21, 26 April 2018 (UTC)

Proposal

The proposal is for the purpose-built accdate bot to remove |access-date= from citations in the tracking category Category:Pages using citations with accessdate and no URL using the following strategies:

  • 1. Remove |accessdate= in CS1|2 templates that don't have a |url= but do have a value assigned to any of the various 'permanent-record' identifiers. Excluding templates {{cite web}}, {{cite podcast}}, and {{cite mailing list}}. Normally |isbn= would be excluded from the identifier list, but if a {{cite book}} it would be included.
  • 2. Remove |accessdate= in {{Cite book}}, {{Cite news}} and {{Cite journal}} with no |url=. Per the documentation, "Access dates are not required for links to published research papers, published books, or news articles with publication dates." If a publication date is provided, remove |access date=.

-- GreenC 15:25, 27 April 2018 (UTC)

I'm fine with that. However, if |url= is there and empty, make |access-date= empty, rather than removed entirely. Headbomb {t · c · p · b} 15:38, 27 April 2018 (UTC)
That's no problem technically if that is wanted. It might cause some double-takes in the diffs, like the bot made an error, so I would need to be able to explain to people why it was being done. What is the rationale? -- GreenC 15:44, 27 April 2018 (UTC)
The logic being if you provide |url=, then it's really annoying to have to type |access-date= afterwards, and we normally want people to put access-dates when they give URLs.
That being said, I'd support removing |access-date= from templates entirely (e.g. at {{cite journal}}/{{cite book}}) per "It is not required for linked documents that do not change". Headbomb {t · c · p · b} 15:51, 27 April 2018 (UTC)
That sounds a lot like the wiki version of 'if you build it, they will come', to wit: 'if you leave empty parameters in a template someone else will fill them'. I call bullshit. Empty parameters tend to remain empty (and they aren't deleted because 'cosmetic changes ...' Adding empty parameters is a useless exercise that just results in clutter. Do not do this.
Trappist the monk (talk) 16:33, 27 April 2018 (UTC)
I didn't say add the missing ones, just leave them empty, rather than removed if the url parameter is present but empty. E.g. {{cite journal ... |url= |accessdate=2018-01-10}}{{cite journal |... |url= |accessdate=}}, but {{cite journal |... |accessdate=2018-01-10}}{{cite journal |... }} Headbomb {t · c · p · b} 21:51, 27 April 2018 (UTC)
General support for everything listed above. – Jonesey95 (talk) 16:26, 27 April 2018 (UTC)
Just a note that often the wrong template is being used so you cannot just remove depending on the template name. Also sometimes there may be URL present but it is not on the |url= field or the URL may have been lost and the |accessdate= can be used to look for the lost URL. Keith D (talk) 20:32, 27 April 2018 (UTC)
In the (small) sample of actual articles that I looked at, I saw no errors of this kind, FWIW. I see them very rarely. It would be a shame to prevent this bot from doing some valuable work for these edge cases. I wonder if the bot could be programmed to skip any citation that contains a URL in any parameter value. – Jonesey95 (talk) 20:47, 27 April 2018 (UTC)
The bot checks for |chapter-url= but since there may be others it doesn't know about it can just regex the cite for a URL and skip if found. -- GreenC 21:24, 27 April 2018 (UTC)
Yeah I'd add to what Jonesey95 said the bot is Heuristic based. Otherwise the programming challenges are intractable (having the accessdate is not sufficient to find the url, see discussion above), and so are the manual editing aspects intractable (50,000+ articles and probably 200,000+ citations). Heuristics are a way forward. Is it worth not running a bot because of a small error rate. The alternative is do nothing and let the category continue to grow in size since day 1. -- GreenC 21:24, 27 April 2018 (UTC)
There is always a middle ground, like (just as an example) limiting the bot to a specific number of edits per day so that human editors can check the edits manually. Scanning through a few hundred of the same kind of edit, looking for errors, is not that hard. – Jonesey95 (talk) 22:00, 27 April 2018 (UTC)
Not really a middle ground because it's just as much work manually checking for errors (ie. finding URLs hidden deep in old diffs) as doing it manually without the bot to begin with. Can't visually scan for errors. And, at about 100,000 cites / 100 a day should take a bot operator about 1,000 days to complete, assuming no new cases show up during those 3 years. Not even sure I could do 100 cites a day, it would take many hours. This is exactly why the tracking category is so large - it's too much work and no one does it. -- GreenC 23:25, 27 April 2018 (UTC)
Another reason for its size is that the error messages are hidden (something that I have opposed). Were we able to reveal them, normal editors might fix at least the errors that they are making today and perhaps even fix preexisting errors (no guarantees of course). When I implemented Module:Lang something like 10k article pages ended up in the error category. I fixed a lot of those error but I didn't fix 10,000 pages of errors. There is value in showing editors where the errors are. Yeah, I know, that RFC. But, once this bot has run to completion, we will have met the criteria for revealing the error messages.
Trappist the monk (talk) 00:53, 28 April 2018 (UTC)
Sorry, I was unclear. I meant that we could let the bot run on, say, 500 articles per day, and then a human editor could visually inspect those edits and undo any that were questionable. Looking at 500 of the same kind of edit is not too bad. The bot will probably modify about 20,000 articles, which would take 40 days. After that, we could make the error messages visible. – Jonesey95 (talk) 12:34, 28 April 2018 (UTC)
How do you propose determining, visually, if an edit if this type is questionable? 20,000 articles.. when I ran test case it found 16 articles with 81 cites modified or a ratio of 5:1 meaning about 100,000 cites need checked (assuming that ratio holds). Normally this sort of scale you do spot checks. -- GreenC 14:41, 28 April 2018 (UTC)
I rather enjoy visually proofreading bot edits, and I have no trouble doing 200 or so at a time. The nice thing about bot edits is that they are pattern-based, so once you have looked at a few, it is not hard to glance at an edit and see whether it is flawed. I propose that we get this bot to a trial phase and have it run a couple hundred edits using the above criteria. At that point, we will have specific edits to discuss, rather than hypothetical problems that may end up being a minuscule fraction of thousands of beneficial edits. – Jonesey95 (talk) 17:40, 28 April 2018 (UTC)
You still didn't answer the question. How will you determine, visually, if an edit of this type is questionable? Serious question. Explain how one can "at a glance" determine that the URL exists buried in thousands of diffs. That's the whole reason this tracking category is so large, it's impossible for anyone to simply determine. If you're willing to search diffs manually, why even have a bot. If the concern is the bot will make syntax errors, it would be wasting time because I've done much more difficult work across millions of edits and am quite confident it will be reliable, there's no reason to hold up the bot on those grounds. As for initial trial edits, that's how the bot process works. And if you want to manual check the first 1,000 or whatever that's fine also, as much time as you want. And if after those 1,000 you want to keep checking, we can work something out. I can set it up on cron with X size batch per day. -- GreenC 23:32, 28 April 2018 (UTC)
I don't know what to say beyond I look at the edit, and if the bot did something other than what it was supposed to do, I revert or fix the edit, and alert the bot operator so that code can be fixed. I have done this for many bots and bot trials. Humans are better at finding anomalies than bots. I'm not worried about the bot making a syntax error; from experience, I know that human bot coders are fallible and that WP editors are immensely creative when it comes to putting strange things into citation templates. There is no way for a bot coder to predict all of the bizarre things that editors have done, so visual inspection of edits can help find those anomalies. – Jonesey95 (talk) 13:34, 29 April 2018 (UTC)
I agree this is a suitable work for a bot. Fixes are possible after the fact at any time, with no need for a special rate limiting (e.g. when inspecting the history of a troubled reference or scanning the byte differences of revisions). I personally prefer template parameters to be removed entirely rather than emptied. Nemo 15:05, 29 April 2018 (UTC)

I've updated Wikipedia:Bots/Requests for approval/GreenC bot 5 with the latest dry run results, it's now up to 57% success rate. That leaves a large amount unfixed, but a noticeable improvement over 2% (thank you Jonesey95). Any other ideas how to justify removal of stray |access-date=? -- GreenC 15:51, 1 May 2018 (UTC)

Issue reading COinS with Zotero

I'm using Zotero (current, v.5.0.46) in Firefox (also current, v.59.0.3) under Windows 10. When I try to "save" from Wikipedia to Zotero, I am only able to save metadata for the encyclopedia article I am viewing, but not for the individual works cited there - I am sure I was able to do the latter, previously. Is something broken in CS1, or in Zotero? Or my memory? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:24, 1 May 2018 (UTC)

@Pigsonthewing: Andy, I had this problem too, but have now found a solution. I'm using Firefox on MacOS with the standalone Zotero. The following works for me. The "save to Zotero" icon shows the tool tip "Save to Zotero (Wikipedia)", whereas we want "Save to Zotero (COinS)". If I right-click on the icon, I get a menu allowing me to choose "Save to Zotero (COinS)". Maybe this used to be the default? (Sometime I have to reload the page to make the menu appear.) Peter coxhead (talk) 19:13, 1 May 2018 (UTC)
There have been no changes to cs1|2 CoinS module since November 2017.
Trappist the monk (talk) 19:19, 1 May 2018 (UTC)
There's definitely no problem with the COinS data; the problem is persuading Zotero to look at it. Peter coxhead (talk) 20:35, 1 May 2018 (UTC)
In the case of Firefox & Windows, the add-in or whatever they call it has changed, so to save to Zotero, the desktop version of the program must be running when you do the save. Jc3s5h (talk) 21:16, 1 May 2018 (UTC)

When to use series

I've always made use of the |series= field to denote... the series, as in the case of

  • Last, F (2018). "Title". Journal of the Royal Statistical Society. Series B (Statistical Methodology). doi:10.1111/rssb.12275.
  • Last, F. (2018). "Title". The Journals of Gerontology. Series B. doi:10.1093/geronb/gbx148.
  • Last, F. (1950). "Title". Bulletin of the British Museum (Natural History). Zoology.

etc., but I've had some editors inexplicably remove the |series= parameter and making it part of the |journal=. Is there any guidance as to when something should be at the end of the |journal= and when it should be by itself in |series=? I thought it was pretty clear-cut to use the |series= for the series, but maybe I've misunderstood. Thanks for any guidance. Umimmak (talk) 15:53, 3 May 2018 (UTC)

There are two senses to the word series. The first is "Series = Sequence of numbers", the second is "Series = Part/Section". For journals, the |series= parameter refers to the first meaning: it exists to distinguish volume renumberings.
For instance the journal Physical Review, was numbered volumes 1–35 from 1893–1912. That is the first series of Physical Review. In 1913–1969, the volume number restarted at 1 and went up to 188. That is the second series of Physical Review. In 1970, Physical Review split into individual parts, Physical Review A/B/C/D, where volumes again restarted at 1 (currently at its 97th volume). That is the third series.
Since there are two publications identified as Physical Review, Volume 1 , you need to distinguish which is which by use of |series=First Series/|series=Second Series.
In your above examples, all of that information is related to the second meaning, so it should be put in the |journal= parameter.
Headbomb {t · c · p · b} 16:36, 3 May 2018 (UTC)

False date error

The markup:

<ref>{{cite news|title=A Cosmic Dog |url=http://recordcollectormag.com/articles/cosmic-dog |issue=448 |pages=54-60 |date=Xmas 2015 |work=[[Record Collector]]}}</ref>

gives a date error, yet Xmas 2015 is the date given on the cover of the magazine, and online (IIRC there are 13 issues per year). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 4 May 2018 (UTC)

There are whole classes of dates that give false alarms. Your choices are to just leave the "error", hand-code a reference in a format that looks like the other citations in the article, or change all the citations in the article to some other format, such as Chicago. Jc3s5h (talk) 11:11, 4 May 2018 (UTC)
No, that is a legitimate error. Just because some hipster-cool publication designers choose to use non-standard date formats (because it's hip and cool), does not obligate cs1|2 to sycophantically adopt each new hip and cool style concocted by these designers. cs1|2 aren't and should not attempt to be hip and cool. Really, it's no different from emitting errors when hip and cool magazine designers' chosen format uses all lowercase for issue month or season dates or uses dot separators (or both: 4.may.2018 – how cool is that?) cs1|2 are not here to perpetuate pretentious hip and cool style. cs1|2 do support |date=Christmas 2015:
{{cite magazine |title=A Cosmic Dog |url=http://recordcollectormag.com/articles/cosmic-dog |issue=448 |pages=54-60 |date=Christmas 2015 |work=[[Record Collector]]}}
"A Cosmic Dog". Record Collector. No. 448. Christmas 2015. pp. 54–60.
Also: {{cite magazine}}
Trappist the monk (talk) 11:43, 4 May 2018 (UTC)
The character string "Christmas" does not occur at Help:Citation Style 1 nor at Template:Cite news. Editors should not be expected to discover undocumented features by trial and error. Jc3s5h (talk) 12:05, 4 May 2018 (UTC)
Another possibility is to put the fancy date in the issue= field. – Jonesey95 (talk) 14:12, 4 May 2018 (UTC)

Free but limited access (url-access)

Geneall displays the following message on its website: "All the basic genealogical information contained in the website is available freely to our visitors. More detailed and specific information is only accessible in the Geneall Plus level."

The issue I have encountered is that none of the url-access parameters apply to this source, i.e., access to source is free but access to information is limited ("Information only available for Geneall Plus. Please Login or Register.") SLBedit (talk) 23:30, 29 April 2018 (UTC)

Is the information in the source needed to verify the sentence in the article in front of or behind the paywall? --Izno (talk) 23:59, 29 April 2018 (UTC)
Some information, like the name of his parents and his wife, although I got that information from a screenshot taken by someone with "plus" access to Geneall. SLBedit (talk) 00:38, 30 April 2018 (UTC)

(edit conflict)

Isn't |url-access=subscription the correct answer to this question if the source you need is behind one of those orange bars? If you have to hand over dollars, euros, shekels, yen, whatever, then |url-access=subscription is the correct answer.
Trappist the monk (talk) 00:01, 30 April 2018 (UTC)
Some information is available without paying. SLBedit (talk) 00:38, 30 April 2018 (UTC)
Yes, I know. But, is the information that you have used to support the article behind the paywall? If yes, then as a courtesy to readers set |url-access=subscription. If the information that you have used to support the article is not behind the paywall, then no need for |url-access=.
Trappist the monk (talk) 00:55, 30 April 2018 (UTC)
Some information added to the article is freely available and some isn't. SLBedit (talk) 01:00, 30 April 2018 (UTC)
Yes, we know, it's the 4th time you say this. Headbomb {t · c · p · b} 01:01, 30 April 2018 (UTC)
@User:SLBedit--if you are using any information that isn't freely available, I would use |url-access=subscription. If your information comes partly from freely available parts of a source and party from paywall-restricted parts of the source, I would label it using the more restrictive classification just to be on the safe side. In the end, it's not a big deal if you're a little off and somebody changes it later (it's happened to me, for sure). As long as your citation is accurate enough that other people can check that the info is correct, you're in the clear. RexSueciae (talk) 01:16, 30 April 2018 (UTC)
The advice we should give that if the source is paywalled, then that's what |url-access=subscription is for. That some information can be found in the abstract rather than the main text is irrelevant. Headbomb {t · c · p · b} 12:53, 30 April 2018 (UTC)
One could create two citations, one for the free portion and one for the subscription portion, the latter having the url-access=subscription parameter. This might seem like overkill, but the material from the subscription portion is NOT sourced from the site, but from a screenshot from the site, which the citation should reflect. --User:Ceyockey (talk to me) 23:20, 4 May 2018 (UTC)

Foreword

I have several books that contain Forewords by authors distinct from the author of the main text. Often they are giving a minibio of the author, explaining the importance of the book, describing its impact, etc. If I want to use the material in the Forword, I have no way in the template of doing that. How about ForewordAuthorLast, ForwordAuthorFirst, ForewordAuthorLink, and ForewordTitle? Nick Beeson (talk) 16:30, 6 May 2018 (UTC)

Already exists. |contributor= and the usual aliases, +link, +mask; requires |contribution=. See the template documentation under Authors.
Trappist the monk (talk) 16:40, 6 May 2018 (UTC)

Publisher of a media

Could someone please give me an opinion on this matter? — Preceding unsigned comment added by ZeR0101MiNt (talkcontribs) 23:22, 10 May 2018 (UTC)

Websites in italics

Hi all. I was hoping can someone can clarify something for me. In the past, I have been taught that companies such as iTunes Store should not be in italics. Now if you put it in the website/work parameter, it is rendered in italics. Should it be in the publisher parameter instead (although it is published by Apple) or does it not matter that it is in italics? CoolMarc 08:22, 12 May 2018 (UTC)

Already been discussed at:
Some editors suggest that even if other websites don't, we have our own internal style guidelines that italicise websites, and some examples (MLA and Chicago) use italics, so we follow their example. There's really been no consensus, except it would seem that because the parameter still italicises work/website and there's no option to disable it, that we shouldn't force-disable italics with markup. Also, iTunes Store is just an online store, not a company. Apple is the company. Same thing as when Amazon or Amazon.com is placed in website or work. Ss112 08:58, 12 May 2018 (UTC)

Nomination for deletion of Module:Citation

 Module:Citation has been nominated for deletion. You are invited to comment on the discussion at the module's entry on the Templates for discussion page. {{3x|p}}ery (talk) 16:21, 13 May 2018 (UTC)

Addition of tooltip to "et al." in display parameters

I have searched the archives and found no discussion that even mentions this idea, so I might as well propose it here. If there is a better place to do so, please direct me to that place. Moreover, if there is any current policy, consensus, or coding issue preventing the implementation of this proposal, please inform me because I am aware of none. Lastly, if this functionality is somehow already implemented and available in a way that does not pollute the COinS metadata (like {{abbr}} apparently does), or I am otherwise missing something simple and obvious that makes this whole proposal a non-starter, please whack me at a scale of your discretion and point it out. Thanks.

After noticing this occur occasionally, and having encountered this myself, I think it would be useful to implement a tooltip function for the display-authors and display-editors parameters for all appropriate CS1 templates (but especially in {{cite journal}}, {{cite report}}, and other templates where it would be most used). Specifically, if the number of authors or editors (as defined in the appropriate parameters) exceed the numeric value in the aforementioned two parameters, all authors or editors omitted in the output of the citation remain visible within a tooltip at the "et al." which replaces them.

To use an example from Template:Cite journal/doc § Examples, if the following citation is added:

{{cite journal |last=Viollet |first=Benoît |last2=Andreelli |first2=Fabrizio |last3=Jørgensen |first3=Sebastian B. |last4=Perrin |first4=Christophe |last5=Geloen |first5=Alain |last6=Flamez |first6=Daisy |last7=Mu |first7=James |last8=Lenzner |first8=Claudia |last9=Baud |first9=Olivier |last10=Bennoun |first10=Myriam |last11=Gomas |first11=Emmanuel |last12=Nicolas |first12=Gaël |last13=Wojtaszewski |first13=Jørgen F. P. |last14=Kahn1 |first14=Axel |last15=Carling |first15=David |last16=Schuit |first16=Frans C. |last17=Birnbaum |first17=Morris J. |last18=Richter |first18=Erik A. |last19=Burcelin |first19=Rémy |last20=Vaulont |first20=Sophie |display-authors=5 |date=January 2003 |title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity |journal=The Journal of Clinical Investigation |volume=111 |issue=1 |pages=91–98 |doi=10.1172/JCI16567 |doi-broken-date=2017-01-01 |pmc=151837 |pmid=12511592}}

The following is the output's first part:

Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain; et al. (January 2003).

The proposal would change that output to the following:

Viollet, Benoît; Andreelli, Fabrizio; Jørgensen, Sebastian B.; Perrin, Christophe; Geloen, Alain; et al. (January 2003).

The same would occur for editors; if both of the display parameters are used in the same citation, then a tooltip would be available for each. An added benefit, beyond it actually outputting those omitted data, is that this information is now available for readers in an unintrusive way that does not involve seeing the source text (or page source) when it would otherwise be unknown unless someone checks there. Moreover, hypothetically, this increased visibility would naturally assist in vandalism detection for anyone reading the article, but that is admittedly unlikely given it would probably be caught by the diff well before then. Lastly, this incentivizes editors to provide full authorship when due and available; presently, why add the inputs if there is no output? The editor might as well just truncate the authorship (or editorship) and maybe finish with display-authors=etal (or editor equivalent), since it's the same output and the predominant group of users who would probably use and care about such data would be the readers, anyway.

I could continue, but I think I have made my proposal and rationale clear enough. Thoughts? ―Nøkkenbuer (talkcontribs) 02:30, 21 April 2018 (UTC)

I think that the use of {{abbr}} is inappropriate here. As I understand it, <abbr>...</abbr> marks an abbreviation and then makes the whole term available through a tool tip:
<abbr title="et alii">et al.</abbr>et al.
so, for cs1|2, if we adopt this proposal the markup would be something like:
<span style="border-bottom: 0; text-decoration: underline dotted; dotted; cursor:help;" title="Flamez, Daisy; Mu, James; Lenzner, Claudia; Baud, Olivier; Bennoun, Myriam; Gomas, Emmanuel; Nicolas, Gaël; Wojtaszewski, Jørgen F. P.; Kahn1, Axel; Carling, David; Schuit, Frans C.; Birnbaum, Morris J.; Richter, Erik A.; Burcelin, Rémy; Vaulont, Sophie">et al.</span>
et al.
Trappist the monk (talk) 11:37, 21 April 2018 (UTC)
I am fine with however it is implemented so long as the output is functionally the same, Trappist the monk, assuming the proposal is implemented at all. I simply used {{abbr}} as an example to illustrate the visual output I mean and because I am not very familiar with coding in HTML; but I understand that it is probably not the best way to code it, especially when considering semantic integrity. Thank you for noting that (and for correcting my coding). ―Nøkkenbuer (talkcontribs) 11:40, 22 April 2018 (UTC)
Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the {{abbr}} template may be used to indicate the long form of a word. from WP:ACCESSIBILITY is relevant Galobtter (pingó mió) 11:54, 22 April 2018 (UTC)
Galobtter is right, such information doesn't belong to a tooltip. Note that there are articles with thousands of authors: it's not the citation's job to store complete attribution. --Nemo 16:48, 22 April 2018 (UTC)
But it is nonetheless the citation's job to provide attribution, including of the authors, which the display parameters truncate. Of course, in the extremely rare circumstances in which literally hundreds or thousands of authors and editors contributed to a source being cited, a "complete attribution" is unreasonable. This is also a situation in which I suspect not a single Wikipedian will attempt to include more than 50 in their citation, however, not least because manually coding all that in a CS1 template would probably take weeks and any edit that adds over 5,000 bytes (let alone 50,000+ bytes!) of just names will probably be reverted. In those situations, and probably only those situations, would I find it reasonable to omit the majority of authors or editors from a citation's attribution. Even then, the collaboration parameter could be used to circumvent specification altogether, which avoids privileging any particular author or editor during attribution.
As with most all things, Nemo, there will inevitably be exceptions; as someone of your seniority would well know, that is partly why Ignore all rules is a core policy of Wikipedia that informs its fifth pillar. Nonetheless, I do not think those exceptions—especially rare ones like this—justifies not changing the rule itself to improve the accessibility of information to the readers. I think my proposal does just that. ―Nøkkenbuer (talkcontribs) 15:18, 16 May 2018 (UTC)
But it is nonetheless the citation's job to provide attribution... I don't think so. Attribution (naming all of the authors in the order of their contribution to the work) is the duty and obligation of the publisher. Here, the purpose of a citation is to identify the source that supports our article's text so that readers can WP:Verify article content. It is common, I believe, that published style guides often say something to the effect "when there are more than n authors, list the first n authors followed by 'et al.'". There is, as best I can determine, no requirement here to list all contributing authors.
I suspect not a single Wikipedian will attempt to include more than 50 in their citation Not true. Here's one with 230 authors.
Trappist the monk (talk) 16:47, 16 May 2018 (UTC)
I am frankly surprised at that example and obviously stand corrected. Thanks for providing it, Trappist the monk. As for your statements regarding attribution, I see what you mean. Perhaps it is worthwhile to add the same sort of style guide recommendation to a pertinent policy or guideline, since I am not aware of any which specify when a number of authors or editors cited becomes one too many. I still think my proposal would be a valuable improvement to the current display parameters (and would be useful in the example you provided), but it seems clear that—at least, among the editors who responded thus far—there is no support for it and overwhelming consensus for no change. Unless that changes, I will just drop it. ―Nøkkenbuer (talkcontribs) 21:10, 16 May 2018 (UTC)
Does that mean that the quote parameter in {{rp}} violates MOS:ACCESS § Text? If there was a better way to implement this unobtrusively, Galobtter, then I would of course recommend that. Given that the choice appears to be between omitting the output entirely (current display parameter functions), unobtrusively providing the rest of the authors or editors via hovertext (my proposal), or printing the entire list regardless of its length (CS1 without display parameters), I would opt for the hovertext. Alternatively, I could just display all 20 authors from the above example or omit most while privileging a few, but neither seem satisfactory. The former problem is why the display parameters were added; the latter problem is what my proposal addresses.
The point of including the hovertext is to provide greater access to that information than is presently provided and to make the information being hidden by the display parameters worthwhile to add at all, thereby preserving the function of those display parameters. Why should I or any other editor include all 20 authors, as in the above example, when 15 (or whatever arbitrary cutoff) will not even display? For the zero to one reader who checks the article page source? That is time better spent editing something else, so why not just deprecate these functions of the display parameters and set a policy or guideline for when to et al. the rest? If part of the function of those display parameters is to preserve the information of those additional authors and editors, then I do not see how that information is being preserved in a way useful and accessible to the readers, since it is not being displayed in the article at all and can only be found in the page source that many do not even know exists, much less know how to check. ―Nøkkenbuer (talkcontribs) 15:18, 16 May 2018 (UTC)
Regarding first question - possibly. You don't really have to include the full author list; normally they just come from tools that grab the full author list. I personally dislike the hovertext thing and there really isn't much value in the authors. Galobtter (pingó mió) 16:14, 16 May 2018 (UTC)

If a book has 2 ISBN numbers, how to cite e-book?

I'm adding The Salvation Army Year Book 2018 to a list of publications in the Salvation Army article but it has 2 isbn numbers:

paperback book isbn 978-1-911149-40-8 e-book isbn 978-1-9111-49-41-5

what "cite book" syntax do I use to cite the e-book version?

I've put (e-book) after the title (before the <ref>...</ref> tags)

thanks Adrian816 (talk) 20:54, 10 April 2018 (UTC)

@Adrian816: Since you're listing rather than citing, I would recommending putting the paper copy in the |isbn= parameter and simply listing the ebook ISBN after. Something like Title. ISBN 978-1-911149-40-8. E-book ISBN 978-1-9111-49-41-5. --Izno (talk) 21:05, 10 April 2018 (UTC)
What a sensible answer! I asked the same question five years ago and was given a dozen reason why my question didn't need answering. EEng 22:19, 10 April 2018 (UTC)
It wasn't the same question. This one is about adding to a list of publications of an organisation; the earlier question was about citing a source. --Redrose64 🌹 (talk) 22:43, 10 April 2018 (UTC)
The passage of years has wisened you none, it seems. EEng 23:39, 10 April 2018 (UTC)
Except that's exactly the answer Moxy gave you therein? And anyway, I agree with RR64 (and the rest of the discussion in that link); the use cases are different. WP:SAYWHEREYOUGOTIT reigns with citations (the source consulted, and only the source consulted, should be provided in a citation--users who need to find another copy will just Google for it). --Izno (talk) 02:43, 11 April 2018 (UTC)
I understand that this has largely been answered, but I might as well explain how I addressed this when I encountered the same issue. Hopefully, I have not been mistaken this entire time. My opinion would be that if you want to want to use {{cite book}}, you could fill out the citation like normal, but add type=E-book to specify the type of media format, which seems consistent with the documentation. If other citations need disambiguation, the type parameter could be set to "Paperback" or "Hardcover" or whatever. If you want to include ISBNs from other formats, Adrian816, you could always add them using {{ISBN}} afterward (such as in a nested bullet point) if you do not want to print out a new full citation. ―Nøkkenbuer (talkcontribs) 12:13, 17 May 2018 (UTC)

WMF Proposal on referencing sections of the same work

This was posted at Wikipedia:Village pump (technical)#Feedback round: A proposal for referencing sections of the same work more easily and maybe of interest to people here. Nthep (talk) 13:56, 17 May 2018 (UTC)

External pages should not be linked for identifiers (like doi=) when they are paywalled. Links should only appear for freely accessible resources, ie. ones with matching *-access=free parameter set. Otherwise just display the identifier as plain text. — Preceding unsigned comment added by 83.29.160.2 (talk) 18:16, 7 May 2018 (UTC)

No. Why make it hard for those who do have access to sources behind a paywall?
Trappist the monk (talk) 18:21, 7 May 2018 (UTC)
Links should be provided, since it takes you to the relevant page, and makes it much easier to get access, either via institutional subscriptions, or by paying for the article. Headbomb {t · c · p · b} 18:23, 7 May 2018 (UTC)
Also even if a reader doesn't have access to the article, a link via DOI or whatever will typically provide them with other useful information like an abstract, first page, list of references, supplementary materials, etc. At minimum it allows people to confirm the citation information is accurate. There is absolutely no reason to de-link them just because the article isn't freely accessible for everyone. Umimmak (talk) 18:39, 7 May 2018 (UTC)
If it is all about *easiness* of access, then why not link to http://gen.lib.rus.ec/ or https://sci-hub.tw/? Why *help* paid providers or journals get people's money for something they long time ago (sometimes tens of years) got for free and just published in paper form, and really have no rights to whatsoever? The only thing they do is actively *preventing* people from reaching scientific publications and slowing down progress in research and science. This should not be promoted by Wikipedia by linking to their paywalled content. — Preceding unsigned comment added by 83.29.160.2 (talk) 18:43, 7 May 2018 (UTC)
Citations exist to verify article content only, not to make positional statements. The only help that is important in this context, is the one that enhances Wikipedia's verifiability and reliability, and therefore, its relevance. Free sources, provided they are reliable and verifiable, are encouraged. But I don't think it is in anybody's favor to stop providing information that can be verified as true and reliable, just because the verification particulars are non-free. What is important is to put such information out. 24.105.132.254 (talk) 19:01, 7 May 2018 (UTC)
The purpose of linking to the official source is to guide readers to the official source that they can use, if they are so motivated, to verify a claim in an article. Sometimes those sources are not freely available, due to copyright, limited physical copies, or other limits imposed by the owners of the source. I'm pretty sure that it is not Wikipedia's job to fight global capitalism or make every bit of copyrighted information freely available to the world's population. – Jonesey95 (talk) 19:04, 7 May 2018 (UTC)
And still no because the sources behind the paywall are the 'record' source. The provenance of facsimiles found elsewhere is dubious, may be in violation of the publisher's copyright, may be out-dated preprints. The single doi that I checked (doi:10.1038/18014) had rather large copyright notices on every page. I love this statement from sci-hub.tw > about: "the first pirate website in the world to provide mass and public access to tens of millions of research papers" (emphasis mine). Clearly, for honest people, that site should be avoided.
Trappist the monk (talk) 19:13, 7 May 2018 (UTC)
Not to mention Sci-Hub/Lib Gen inherently have unstable addresses as they keep getting shut down by various court orders (cf the now defunct sci-hub.org, .cc, .ac, .io, .la, .mn, .name, .tv, bz, .biz, ...). DO are stable.
If someone wants to illegally pirate copyrighted works that's on them; Wikipedia doesn't condone this behaviour (see WP:ELNEVER). Umimmak (talk) 19:24, 7 May 2018 (UTC)

On the other hand, when a green open access identifier is provided, we could use it as link target, as we do for PubMedCentral already. The link should also override any existing url= unless it's marked as free access. --Nemo 04:34, 17 May 2018 (UTC)

It should do no such thing. If someone put an existing url= on a citation they presumably did it for a reason. Like, it may be the published version of record. Open access versions are often wrong versions (put up before any revisions made in the editorial process, for instance) and an ideological preference for open access should not override editorial judgement. —David Eppstein (talk) 04:40, 17 May 2018 (UTC)
Also there's WP:SAYWHEREYOUGOTIT; there's no guarantee that the linked material is the same. For example, authors often put only parts of their published papers online, perhaps without the supplementary materials, or put pre-publication drafts online. The link should go to the material actually used by the editor who added the reference. Peter coxhead (talk) 07:34, 17 May 2018 (UTC)
Which is why I'm concerned over Nemo bis's spree of rapid-fire addition of CiteSeerX links to references in many articles today. At a rate of several articles per minute, there's no way Nemo actually read the articles from the CiteSeer links, compared them to the versions of record, and made sure that they were similar enough to be usable in the same place (for instance, that they actually contained all the material they were used to source). —David Eppstein (talk) 07:38, 17 May 2018 (UTC)
Or even that the CiteSeerX links work e.g., [1] added CiteSeerx10.1.1.205.5564, marking it as free access, but the link requires a Princeton University login making it kind of pointless. Umimmak (talk) 07:51, 17 May 2018 (UTC)
|url= should always overrule autolinking, but we should expand autolinking to identifiers beyond just PMC. There was consensus for that idea, but it got buried in an RFC with too many issues at once. Headbomb {t · c · p · b} 12:30, 17 May 2018 (UTC)
@Umimmak: that CiteSeerX link doesn't require any login for me. I am at work though, but I can check again when I'm at home. Headbomb {t · c · p · b} 12:30, 17 May 2018 (UTC)
As Headbomb says. Also, [2] works for me. --Nemo 12:42, 17 May 2018 (UTC)
Ah I was trying where it said "[www.hep.princeton.edu]", i.e., [3]; I didn't realize one was supposed to click on the image. Umimmak (talk) 02:50, 18 May 2018 (UTC)

Cite > Templates Update?

It seems as if — in the editing bar — that the "Cite" sub-heading, "Templates," which features {{Cite web}}, {{Cite news}}, {{Cite book}} and {{Cite journal}} might require updating to follow CS1? Don't know if this has been discussed or brought up before, but the citation formats and setup seem to differ from the now-preferred CS1 stylization, and didn't know if they needed to be updated, maybe? livelikemusic talk! 16:01, 18 May 2018 (UTC)

Not clear to me what you mean. How do the the citation formats and setup seem to differ from the now-preferred CS1 stylization? And what do you mean by now-preferred CS1 stylization? Preferred by what or by whom? Wikipedia:RefToolbar/2.0 creates cs1 templates from the information that you put into the fields of the various forms. The created templates are 'styled' by and rendered by Module:Citation/CS1 just as if you had written the template by hand. Can you elaborate on what you mean?
Trappist the monk (talk) 16:17, 18 May 2018 (UTC)
Sorry about that. So, when you hit "Preview" on {{Cite web}} from the "Cite > Templates" header helper, for example, it sets up like this:
  • {{cite web|last=LAST|first=FIRST|title=TITLE|url=URL|website=WEBSITE|accessdate=AD|location=LOCATION|date=DATE}}.
However, at the template page itself, the set up would actually be:
  • {{cite web |url=URL |title=TITLE |last=LAST |first=FIRST |date=DATE |website=WEBSITE |location=LOCATION |access-date=AD}}.
Is there an overall preference? livelikemusic talk! 16:35, 18 May 2018 (UTC)
Personally the main thing I'd like for the gadget to do is put spaces to the left of pipe symbols to improve readability/wrapping in the edit window. Headbomb {t · c · p · b} 16:37, 18 May 2018 (UTC)
There is no 'preferred order' for parameters in the wikitext template. There are cases where it is useful to list certain parameters first; for example in bibliography listings by author in alpha order:
{{cite book |last=... |first=...
Module:Citation/CS1 and the supported templates do not care about parameter order.
Trappist the monk (talk) 16:46, 18 May 2018 (UTC)
The visual editor always places the parameters in a set order (determined by the template's TemplateData), but I don't think that should be taken as the "correct" order. It's just how it happens to do it. Whatamidoing (WMF) (talk) 16:49, 18 May 2018 (UTC)
@Livelikemusic: When named parameters - such as |last= and |title= - are used, the order is immaterial. You can arrange them in alphabetical order, or in order of size, or in the order in which you remember to add them. It makes no difference at all: this is a general characteristic of all templates that use named params. --Redrose64 🌹 (talk) 19:45, 18 May 2018 (UTC)
Excellent! Okay then! Because I've seen, multiple times, people say that because CS1 changed, the first template (as exhibited by the templates drop down) is "wrong," so I was just inquiring if it was something that required changing. Glad to know it isn't! Thank you! livelikemusic talk! 12:42, 19 May 2018 (UTC)

Date in Cite journal is wrongly parsed (locale problem?), feature suggestion to Citations

Example:

Cite journal automatic from http://www.dtic.mil/docs/citations/AD0694606

Report Date : Oct 1952 (I think parser gets date from this)

In Cite journal, Source date is set to 1952-10, which is incorrect (red |date= error in reference tool tip). I must manually change that field to Oct 1952.


Feature suggestion: add text parameter "Additional info"/"Contents" for ex. description of citation contents ("Contains biography, rewards, pictures" etc.) or other information (ex. Cite web for Ext. links). Presently I'm using parameter Others for that.--89.25.210.104 (talk) 21:48, 21 May 2018 (UTC)

There is no Cite journal automatic anything. Perhaps you are referring to the visual editor or to reftoolbar either of which can write a wikitext {{cite journal}} template that Module:Citation/CS1 then renders into a properly formatted citation – if and only if the data provided in the wikitext template obeys the rules for the various template parameters. A year-month date in the form yyyy-mm is not allowed per WP:DATESNO.
There have been similar extra-info-parameter requests in the past, none of which have succeeded; you might hunt about in the archives of this page for those discussions.
Trappist the monk (talk) 22:08, 21 May 2018 (UTC)
Yes, I'm talking about editing in visual mode (Cite -> Automatic [Cite journal]).
If yyyy-mm isn't allowed, why did it converts date from first example to that format? Because of locale conversion?
Automatic conversion to ALLOWED formats would be nice. Or highlight in red Source date field with incorrect format.
In browser [Seamonkey/Fifrefox] I have List of preferred languages set to pl/en-us/en, browser and OS is in my native language (not in English).--89.25.210.104 (talk) 19:47, 22 May 2018 (UTC)
See "Wikipedia:VisualEditor". The gist of it is VisualEditor is an unfinished experiment. Jc3s5h (talk) 20:39, 22 May 2018 (UTC)

"Redundant" doi with JSTOR id?

Not sure if this is the best place to ask this question, but I wasn't sure where else to ask. Is there a benefit to including a |doi= if that DOI takes someone to JSTOR and there is already a |jstor=? I would think the |doi= should only be used in the case where it takes the reader to a different website where the article can be found (e.g., the article on the publisher's site), as different websites might have different paywalls or subscriptions or information available to the reader. It seems redundant to have both and maybe a bit inconvenient if the reader is expecting them to be different, but I've noticed some editors add these "redundant" DOIs so maybe I'm missing something. Thanks Umimmak (talk) 21:09, 24 May 2018 (UTC)

To give explicit (shortened) examples, I think Cornyn (1944). "Outline of Burmese Grammar". JSTOR 522027. {{cite journal}}: Cite journal requires |journal= (help) is preferable to Cornyn (1944). "Outline of Burmese Grammar". doi:10.2307/522027. JSTOR 522027. {{cite journal}}: Cite journal requires |journal= (help) as both DOI and JSTOR links to go https://www.jstor.org/stable/522027. I think it's only beneficial to make use of both parameters when they go to different sites as in Brown (1925). "Books on Burma and Siam". doi:10.1017/S0035869X00169060. JSTOR 25220835. {{cite journal}}: Cite journal requires |journal= (help), where the DOI goes to the article on the Cambridge UP website, not to JSTOR. Umimmak (talk) 21:14, 24 May 2018 (UTC)
I find this annoying too. If we can't agree to avoid these duplicates, could the templates suppress display of doi's of the form 10.2307/jstor-id when the same id is supplied to |jstor=? Kanguole 21:18, 24 May 2018 (UTC)
Yeah you'd need to make sure they're actually the same since I think there are some DOIs starting with 10.2307 which don't just go to JSTOR. To give an example, it would be useful to have both doi:10.2307/2713499 and JSTOR 2713499. Umimmak (talk) 21:29, 24 May 2018 (UTC)
Ah, we can't expect the template to check those. Kanguole 22:29, 24 May 2018 (UTC)

@Umimmak and Kanguole: Additionally, DOIs and JSTOR numbers have orthogonal semantics. The JSTOR number, which is our proxy for what JSTOR itself terms a "Stable URL", is really just one archive provider's direct link that happens to have some "API"-like stability guarantees. It is owned, and can only be owned, by the archive provider. The DOI, on the other hand, is a proper de-coupled identifier that is resolved through a resolver: it is explicitly and deliberately not a stable URL. The identifier is notionally owned by the publisher, not by the archive, and can be changed to point at new archive providers or the publisher's own website (in practice the archive providers often own the DOI too, but...). That is, the one is an address while the other is an identifier. |url=, on the other hand, is entirely redundant with |jstor=. --Xover (talk) 07:53, 26 May 2018 (UTC)

Markup for named collections

Sometimes a publishers lists a set of distinct books or manuals under a series name, e.g., IBM Redbooks. The obvious way to mark up citations is something like


but the usage of the version= parameter in {{cite}} is very different from the usage of the word by publishers, and the above example gets an error message:

Alvaro Salla; Patrick Oughton (4 May 2018). ABCs of z/OS System Programming. Redbooks. Vol. Volume 10 (Sixth ed.). IBM International Technical Support Organization. SG24-6990-05{{cite manual|publisher = IBM International Technical Support Organization|series = Redbooks|title = ABCs of z/OS System Programming|volume = Volume 10|id = SG24-6990-05|author1 = Alvaro Salla|author2 = Patrick Oughton|edition = Sixth|date = 4 May 2018|version = 1up}}. {{cite book}}: |volume= has extra text (help); More than one of |version= and |series= specified (help)

I don't want to arbitrarily concatenate the name of the publisher with the name of the series. Is there a supported way to do this, and if not, would this be something useful to add? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:53, 14 May 2018 (UTC)

I'm not at all sure that I understand your question. In your examples you include |version=1up. Where does that come from? When I looked at ABCs of z/OS System Programming, at the ABCs of z/OS System Programming, and at the Google books facsimile ABCs of z/OS System Programming, I cannot find the text 1up. What am I not understanding?
Trappist the monk (talk) 21:57, 14 May 2018 (UTC)
Just guessing based on the string used here, but back when dinosaurs walked the earth and IBM was a big player, digital texts were often published in multiple variants to account for printing preferences: 1up (single-sided), 2up (print on both sides of the sheet), and variants for paper size like A4 vs. Letter. I haven't actually seen that since the days when actual PostScript files were a plausible option (i.e. pre-PDF), but I can well imagine that IBM might still be doing that from old habit. Perhaps Chatul would like to elaborate on his meaning? --Xover (talk) 05:06, 18 May 2018 (UTC)
It doesn't apply to that particular document, but some manuals on [bitsavers] are available in separate files with one column per page (1up) and two columns per page (2up). I'd like a supported way to indicate that in the {{cite}} tag. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:16, 23 May 2018 (UTC)
Related, working (or not) examples are always appropriate here. If the Redbook examples don't apply, why did you give them as examples? And your bitsavers link doesn't work (http://bitsavers.org/pdf/ibm does). But, I'm not interested in chasing though that list of 120-ish subfolders looking for 1up / 2up examples. If Editor Xover is correct, whether the source is printed 1up or 2up is immaterial. The purpose of the cs1|2 templates is to identify the source for readers; 1up and 2up indicators don't aid a reader in locating a copy of the source.
I'm not sure that I agree with your definition of 1up/2up. Archive.org uses those terms in urls. For example, On the Origin of Species 2up:
https://archive.org/stream/onoriginofspeci00darw#page/n7/mode/2up
and 1up:
https://archive.org/stream/onoriginofspeci00darw#page/n8/mode/1up
Here the terms clearly mean: display 1 page at a time, or display two pages at a time. HathiTrust uses the terms for the same purpose.
Trappist the monk (talk) 16:52, 23 May 2018 (UTC)
I gave it as an example to illustrate what I was trying to do; the Redbooks are a series in the publishing, but not the {{cite}}, sense.
Here are bitsaver examples, but those aren't part of a series.
               
{{cite manual
| publisher = IBM
| title = IBM System/360 Reference Data
| id = GX20-1703-9
| edition = Tenth
| version = 1up
| series = illustrative only
| url = http://bitsavers.org/pdf/ibm/360/referenceCard/GX20-1703-9_System360_Reference_Data.pdf
| mode = cs2
}}
               
{{cite manual
| publisher = IBM
| title = IBM System/360 Reference Data
| id = GX20-1703-9
| edition = Tenth
| version = 2up
| series = illustrative only
| url = http://bitsavers.org/pdf/ibm/360/referenceCard/GX20-1703-9_System360_Reference_Data_2up.pdf
| mode = cs2
}}
IBM System/360 Reference Data (PDF), illustrative only (Tenth ed.), IBM, GX20-1703-9 {{cite book}}: More than one of |version= and |series= specified (help)
IBM System/360 Reference Data (PDF), illustrative only (Tenth ed.), IBM, GX20-1703-9 {{cite book}}: More than one of |version= and |series= specified (help)
-Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:35, 23 May 2018 (UTC)
I guess I see no significant difference. In these examples, Machine Instructions begins on page 1 and concludes on page 2 so the rendering isn't columnar but is single page vs two pages side-by-side. Pick one as your source and cite that one because the 1up or 2up rendering is immaterial. If there are material differences beyond the simple 1up/2up rendering then, perhaps if it is necessary, cite both in separate cs1|2 templates because then they are two different sources.
Trappist the monk (talk) 00:02, 24 May 2018 (UTC)
To me this information seems more like a different edition than a different series. An edition distinguishes between minor variations of the same book; a series is a named collection of books on similar topics. Editions are normally numbered sequentially but they don't have to be sequential and their descriptors don't have to be numbers. So you could use |edition=Tenth (1up) etc., if you really wanted to distinguish these. —David Eppstein (talk) 00:59, 24 May 2018 (UTC)
New additions have changes in the text. The 1up and 2up documents have identical text. It's more analogous to the difference between a hardbound and a softbound printing of the same edition. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:22, 25 May 2018 (UTC)
@Chatul: In publishing and bibliography, the difference between the "hardback", "paperback" and "ebook" is usually termed an "edition". An edition may have multiple print runs, between which there is usually presumed to be no differences, and no need to differentiate between runs. The term "edition" also covers translations (e.g. "the French edition") and other substantial changes (e.g. "this updated edition has a new foreword by the author, and substantial rewrites to chapter X, Y, and Z"). I agree with David, above, that differences like one column vs. multi column layout, and 1up vs. 2up print layout, and similar do most naturally fit the "edition" concept. Note that the purpose of the citation is to enable verification: so long as it lets the reader locate the relevant information, the citation has no need of endless bibliographic detail. If your "1up" and "2up" variants both have information X on page Y there is no need to specify which edition it is. If the citation includes a link to the specific file that contains the information there is even less need. In other words, I think you're overthinking this. --Xover (talk) 07:38, 26 May 2018 (UTC)
They might plausibly have different pagination, though, in which case the edition would be important to allow readers to find the right page. —David Eppstein (talk) 07:48, 26 May 2018 (UTC)
I've never seen a case where the edition number wasn't the same in the hardbound and paperback version of the same text. I could use {{cite book|title = foo|edition = pb 10th}} to produce foo (pb 10th ed.)., but it seems unnatural. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:34, 29 May 2018 (UTC)
@Chatul: Inside the physical book (or the specific digital file) there is no need to specify hardback/paperback/etc. with the edition number, since that's implicit in context. However, I believe, at least with traditional books, the colophon will usually specify such things (along with the numbered print run of the same edition), just not alongside the edition number. In any case, you can think of the overall citation as referring to an abstract work, and |edition= specifying which particular edition of that work is referenced. --Xover (talk) 08:10, 30 May 2018 (UTC)

URL and JSTOR access parameters

After reading the Nov 2016 Signpost article I began adding |url-access= when referencing subscription-limited sources, including those via JSTOR. Recently I noticed a a follow-up CitationCleanerBot edit replaced a url=https://www.jstor.org/stable/ with a more concise jstor= but with the side-effect of leaving a red "|url-access= requires |url=" warning on the article. Can a |jstor-access= be introduced to enable detail equivalent to similar to |url-access= to be retained? A corresponding CitationCleanerBot enhancement could then be requested as a follow-up. AllyD (talk) 09:50, 31 May 2018 (UTC)

The bot correctly replaced |url=https://www.jstor.org/stable/ with |jstor= (should have deleted |url-access=subscription at the same time). In general, titles linked by |url= are considered to be free-to-read (this is why |url-access=free is not allowed) and, similarly, identifier links (doi, jstor, etc) are generally not free-to-read (this is why |id-access=free is allowed but |id-access=subscription is not). See Help:Citation Style 1#Registration or subscription required.
Trappist the monk (talk) 10:26, 31 May 2018 (UTC)

The dead-url=usurped mechanism seems to be broken

Apparently, it does not actually suppress the display of the link.The same applies to dead-url=unfit

It is my understanding from the help page that it should do that. So either the template or its documentation is wrong here. Wefa (talk) 20:23, 31 May 2018 (UTC)

Are you sure? Can you provide a real-life example of a cs1|2 template where |dead-url=usurped does not work? In this example, there should be a link to archive.org but the rendered citation should not link to the 'original' example.com:
{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2018-05-31 |dead-url=usurped}}
Title. Archived from the original on 2018-05-31. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
Trappist the monk (talk) 20:43, 31 May 2018 (UTC)
well.... Title nobody bothered to archive. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
-Wefa (talk) 21:11, 31 May 2018 (UTC)
That is as it is supposed to be. Without |archive-url=, Module:Citation/CS1 ignores |dead-url=. You must provide |archive-url= (and |archive-date=) for |dead-url=usurped to have any meaning.
Trappist the monk (talk) 21:57, 31 May 2018 (UTC)
Hmm. But when an editor is adding |dead-url=usurped to a citation, their intent will invariably be "Supress this link because it now points to something inappropriate" with the "Use the archive link instead" bit being only a corollary. It is also generally desireable to be able to supress usurped links even for citations where no one has yet added an archive (which may or may not exist), without removing the link entirely (in order to enable actually locating any archive in the future). Without reopening the previous discussion on the conceptual semantics of |dead-url=, perhaps this particular case (usurped) makes practical sense to special-case? --Xover (talk) 04:33, 1 June 2018 (UTC)

Update to the live cs1|2 modules weekend of 9–10 June 2018

I intend to update the live cs1|2 modules over the weekend of 9–10 June 2018. These changes are included:

to Module:Citation/CS1:

  • support for lang code cnr; fix script-title to use override names when making categories; discussion
  • unlink trans-chapter rendering; discussion
  • make pagination work better in cite interview with |journal=; discussion
  • i18n: sep & ps chars to /Configuration; translate non-western enumerators; discussion
  • i18n: support date digit translation; discussion
  • duplicate-dot bug fix for |others=, |interviewer=, |translator=; discussion
  • i18n: multi-byte terminal character support related to duplicate-dot bug fix; discussion

to Module:Citation/CS1/Configuration

  • support for lang code cnr; fix script-title to use override names when making categories;
  • "interview with" changed to "interviewed by"; discussion
  • Enable error tracking in Draft namespace; discussion
  • Add |lang=lang as a |language= alias; discussion
  • i18n: support date digit translation;
  • remove extraneous closing code tag; discussion
  • add parameters for |chapter-xx= alias consistency; discussion

to Module:Citation/CS1/Whitelist

  • Add |lang=lang as a Language alias; deprecate |in=

to Module:Citation/CS1/Date validation

  • move misplaced local_digit translation to proper place; discovered debugging this module at bn.wiki;
  • i18n: support date digit translation;
  • prevent ymd hyphen-to-dash conversion when digits are not western digits;

Trappist the monk (talk) 16:31, 3 June 2018 (UTC)

Semi-relatedly, I updated the red access lock to display the dial. It is now much more recognizable as a lock. See new vs old. Headbomb {t · c · p · b} 22:18, 5 June 2018 (UTC)
Not related at all; rather, it appears that you are ignoring the decisions taken with this RFC dated 29 October 2016. The red lock that was approved by the RFC can be seen at File:Lock-red-alt.svg#filehistory (the 3 October 2016 version). It seems to me that a decision taken by the community via the formal RFC process must not be unilaterally overridden by an individual editor. Please revert the lock back to the 3 October 2016 version. If you desire a different lock shape/color/etc, the proper course is to pursue a community consensus via RFC.
Trappist the monk (talk) 00:12, 6 June 2018 (UTC)
The RFC supported a red lock, with a full shackle, and full body. This is still exactly what this is, except with enhanced recognizability. We don't need full RFCs for minor changes like this. Headbomb {t · c · p · b} 00:21, 6 June 2018 (UTC)
Precisely: The RFC supported a red lock, with a full shackle, and full body. The community did not support a full-body lock with a transparent center dial thing. Please revert the lock back to the 3 October 2016 version.
Trappist the monk (talk) 11:39, 6 June 2018 (UTC)
  Done --Redrose64 🌹 (talk) 19:59, 6 June 2018 (UTC)
Sigh, this template is by far the worse WP:BURO quagmire there is on Wikipedia. Still, see this RFC on the issue. Headbomb {t · c · p · b} 02:53, 7 June 2018 (UTC)

Template wrapper for book chapters

Just FYI that Template:Cite chapter was created by User:Mvolz (WMF). She thinks it would help produce cleaner, more specific citations by the mw:citoid service. Whatamidoing (WMF) (talk) 16:48, 18 May 2018 (UTC)

This does not seem like a good solution to me – if I understand the problem. This 'solution' would seem to suggest that every one of the various language wikipedias that use ve and citoid would need to have this template as a host for a special fork of the {{cite book}} templatedata to 'fix' a problem that exists elsewhere. There are two changes in the {{cite chapter}} templatedata fork:
cite book cite chapter
"description": "This template formats a citation to a book using the provided bibliographic information (such as author and title) as well as various formatting options.", "description": "This template formats a citation to a book chapter, or other type of book section",
"citoid": {
	"edition": "edition",
	"title": "title",
	"bookTitle": "title",
	...
"citoid": {
	"edition": "edition",
	"title": "chapter",
	"bookTitle": "title",
	...
While {{cite chapter}} is still unused, it should be deleted or, at the very least, prominently marked as experimental, and the problem fix where it is broken.
Trappist the monk (talk) 19:24, 18 May 2018 (UTC)
Okay - I think it will work just to switch it over from Cite book to Citation instead. Mvolz (WMF) (talk) 11:10, 7 June 2018 (UTC)
@Mvolz (WMF): As we discussed with RexxS (talk · contribs) on 20 May, there is no need for this template: you can use {{cite encyclopedia}}. If the word "encyclopedia" is a problem, you can always use one of its redirects, such as {{cite contribution}}. --Redrose64 🌹 (talk) 11:29, 7 June 2018 (UTC)
@Redrose64: - Yes, credit where credit is due :). I opted to do Citation instead of the Cite encyclopedia because as you say, the name is a bit off, but you can invoke the encyclopedia citation style by using the 'encyclopedia' parameter from Template:Citation as well and I think that solves that issue nicely. Mvolz (WMF) (talk) 11:35, 7 June 2018 (UTC)

Question about format parameter

Is this meant to be linkable, like |format=[[Audio Video Interleave|AVI]], and whether it is or not, is it doing something special with a short list of common format names/acronyms like "PDF"? We should document this parameter better, e.g. to suggest that the format be linked.  — SMcCandlish ¢ 😼  01:01, 7 June 2018 (UTC)

Meant to be linkable? I don't think so. May it be linked? Sure, why not? Module:Citation/CS1 applies css styling (style="font-size:85%;") to the value provided by |format= and the |name-format= parameters, but otherwise does nothing special with those parameters.
Of course, documentation can always be made better. I don't know that the parameter value should always be linked lest we run afoul of WP:OVERLINK (do we really need to link PDF?) Linking obscure file formats seems sensible.
Trappist the monk (talk) 14:43, 7 June 2018 (UTC)

script-title and no title

There probably should be some tracking category for cites, where is |script-title=, but isn't |title=. See Sergei Ignashevich, for example. --Edgars2007 (talk/contribs) 06:21, 9 June 2018 (UTC)

See this discussion.
Trappist the monk (talk) 08:20, 9 June 2018 (UTC)