Jump to content

Help talk:Citation Style 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Citation templates
...in conception
...and in reality

Let's revamp the functionality. In {{cite arxiv}}, when you have an incomplete citation (missing mandatory parameters), you have (the rather outdated)

whereas in {{cite journal}}, you have something like

  • {{cite journal |title= |arxiv=1507.00123}}
  • . arXiv:1507.00123. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help)

Let's streamline the functionality to look like

  • <normal output> when all mandatory parameters are present
  • <normal output> + <bot message> when one or more mandatory parameters are missing

This would look something like

This should be rather straightforward to code, when something mandatory is missing, append —&nbps;[https://tools.wmflabs.org/citations/process_page.php?edit=toolbar&page={{FULLPAGENAMEE}}&slow=1 Attempt to fix with Citation bot]. This will also streamline {{cite arxiv}} rather than make it the exception.

Headbomb {t · c · p · b} 17:53, 28 August 2018 (UTC)[reply]

Looking at Module:Citation/CS1/Configuration, it seems the way to go would be something like a botfixable = true in (for example)

    accessdate_missing_url = {
        message = '<code class="cs1-code">|access-date=</code> requires <code class="cs1-code">|url=</code>',
        anchor = 'accessdate_missing_url',
        category = 'Pages using citations with accessdate and no URL',
        botfixable = true
        hidden = true
         },

which would append —&nbps;[https://tools.wmflabs.org/citations/process_page.php?edit=toolbar&page={{FULLPAGENAMEE}}&slow=1 Attempt to fix with Citation bot] after (help) Headbomb {t · c · p · b} 01:19, 3 September 2018 (UTC)[reply]

@Trappist the monk: this would be a pretty hugely helpful addition. If you can implement the 'botfixable = true' part, I can sync the sandbox to keep which errors are bot-fixable with current bot functionality. Headbomb {t · c · p · b} 01:23, 3 September 2018 (UTC)[reply]
Why? If the bot can fix these kinds of errors, there are whole long lists of them at Category:Pages with citations lacking titles and Category:Pages using citations with accessdate and no URL; turn the bot loose on the category pages. Those articles that remain in those categories after the bot runs have completed would not be aided by this proposed change.
Trappist the monk (talk) 13:43, 3 September 2018 (UTC)[reply]
Three reasons. The first is that the bot still makes too many mistakes to be unleashed on 100000+ pages without review. The second is that category runs still require manual activation, and will often crash 100-200 articles in when the bot encounters something like a badly-formed DOI. And third, even if all the bugs were fixed, and continuous runs were possible, it would still take months to clear the categories. There is no drawback to letting editors trigger the bot manually to get ahead of the queue, like we do for {{cite arxiv}}. Headbomb {t · c · p · b} 13:57, 3 September 2018 (UTC)[reply]
The crash is fixed. The othet reasons still stand. AManWithNoPlan (talk) 03:44, 22 September 2018 (UTC)[reply]
  • I see no reason not to activate this again. (tJosve05a (c) 01:31, 9 November 2018 (UTC)[reply]
  • As long as we show those red messages in the view mode, I think it's useful to add a link which helps people fix them with little effort. If/when they can be fixed automatically, we could as well stop showing them out of the edit preview and just use tracking categories. But we're not there yet. Nemo 12:10, 14 November 2018 (UTC)[reply]
    • Maybe we can start with adding the link for some specific errors where the bot is most helpful? Maybe one of those for which the tracking categories know 5k-10k cases. Nemo 16:59, 27 December 2018 (UTC)[reply]
      • That would encourage editors to run the bot, which would trigger all its rules and bugs, while shifting (notionally) the responsibility for them and demonstrating consensus for them from the actual bot operators and onto the hapless editor we told to go use the bot. No, that sounds like a spectacularly bad idea. If the bot can reliably fix a problem then let the bot operators get BAG approval in the normal way, and take responsibility for the edits it makes in the normal way, for a run against one of the maintenance categories. These error messages are for informing human editors of a problem; not for advertising someone's pet bot project. --Xover (talk) 20:38, 27 December 2018 (UTC)[reply]

Using access-date and archive-date

Is there any benefit to using both archive-date and access-date when there is an archived url? I have been told in the past to remove the "access-date" field when adding a link to an archived version, which makes logical sense to me, but another editor recently restored all the access-date text. It seems like unnecessary cluttering of the references, but I would like to know if this has been decided already?  Mr.choppers | ✎  01:17, 13 November 2018 (UTC)[reply]

I provide one or the other, not both, as indeed it is superfluous (given that your archive page reflects the web page as it stood on the access date--not always or necessarily the case for web pages which change frequently--but in that case, you probably wouldn't want the archive page). --Izno (talk) 02:56, 13 November 2018 (UTC)[reply]
What is the rationale for including both access and archive dates. It makes citations hard to read and messy. If an archive only exists for a certain date, the access-date is useless. If the archive matches the access-date, it is useless. If the archive verifies the cited fact, the access-date is useless. -- GreenC 04:12, 13 November 2018 (UTC)[reply]
Should the template even allow both dates to be displayed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 3 December 2018 (UTC)[reply]
With dead links in citations it is a quite common situation that an archive is added long after the original link has gone dead in order to rescue a reference. In these cases, an existing access-date cannot be "updated" (and shouldn't, because it might even help to find a better archive or alternative link in the future). I think, if both, access-date and archive-date happen to specify the same date, archive-date could be suppressed from display inside the template, but the parameter should not be removed. Otherwise they should both be displayed, as they serve different purposes.
--Matthiaspaul (talk) 22:18, 31 December 2018 (UTC)[reply]

RFC on publisher and location in cite journal

Right now, Citation bot removes publisher and location in {{cite journal}}. Proponents of this removal state that this is recommended by nearly every style guide under the belief that there is little value to the information.

However:

  • Several recent threads at User talk:Citation bot indicate that removing the parameters is unexpected at-best and believed to be detrimental at worst;
  • "nearly every style guide" is not our style guide
  • Removing them does not respect the consensus in Module:Citation/CS1, which is to provide the parameters in cite journal.

This RFC seeks consensus for the following questions:

  1. Should Citation bot continue to remove these data?
  2. Is there consensus for this removal, anywhere, by anyone?
  3. Should we continue to support these parameters in Module:Citation/CS1 for {{cite journal}}? If we continue to support these parameters, should we:
    1. Support them only in metadata without display;
    2. Display them only without support in the metadata;
    3. Status quo, which is both to support them in the metadata and display them?

--Izno (talk) 15:59, 27 November 2018 (UTC)[reply]

For the record, {{cite journal}} does not emit metadata for |location= and |publisher= because COinS does not support those parameters for journals. For more, see these:
Matrix defining the KEV Format to represent a journal publication
Matrix defining the KEV Format to represent a book
Matrix defining the KEV Format to represent a patent
Matrix defining the KEV Format to represent a dissertation
With respect to the metadata, all cs1 periodical templates are treated as journal templates; all cs2 templates that use a periodical parameter (|journal=, |magazine=, |work= etc) are treated same as their cs1 counterparts.
Trappist the monk (talk) 16:34, 27 November 2018 (UTC)[reply]
Thanks. Amended the RFC. :) --Izno (talk) 16:37, 27 November 2018 (UTC)[reply]
  • [For clarity: Stop automatic removal and Continue to display 16:57, 27 November 2018 (UTC)] I think if there is a DOI/ISSN/URL/some sort of identifier to the journal/article which eliminates the need to disambiguate, there is no need to add publisher or location. But when there is no such identifier and the publisher or location can be used to disambiguate/help locate a journal then it should be displayed. I don't think it should be blindly done without making sure that this information isn't useful to the reader. From CMoS 17: If a journal might be confused with another with a similar title, or if it might not be known to the users of a bibliography, add the name of the place or institution where it is published in parentheses after the journal title. Umimmak (talk) 16:47, 27 November 2018 (UTC)[reply]
  • Stop removal and display. (edit conflict) First, it is not true that nearly all style guides say this information should be omitted from citations. Chicago Manual of Style 17th ed. §14.182 states that "if a journal might be confused with another with a similar title, or if it might not be known to the users of a bibliography, add the name of the place or institution where it is published in parentheses after the journal title."
Second, conference proceedings are typically bound like a book, but they usually come out every year, so may be thought of as a periodical, and hence, a journal. An editor might be unaware of {{cite conference}} and cite a paper in conference proceedings with {{cite journal}}, but include the place and publisher because it is like a book. Just deleting the place and publisher is the wrong way to correct such a situation; the way to correct it is to change from the journal template to the conference template, and leave all the parameters alone. Jc3s5h (talk) 16:52, 27 November 2018 (UTC)[reply]
  • Stop removal and display. Lots of citations use cite journal for minor periodicals with generic names like "Insights" that are re-used over and over by multiple organizations, and can only be properly identified if the publisher is also listed. It is also important in some cases to show the publisher when a primary source associated with the subject of an article is used, to make clear its non-independence. Humans may be able to figure out these distinctions; automation, currently, can't. —David Eppstein (talk) 17:14, 27 November 2018 (UTC)[reply]
  • Block Citation bot until fixed. If Citation bot is unable to abide by WP:CITEVAR it should be blocked. If its operator (creator/coder in this case) is unable to abide by WP:CITEVAR and the bot's task approval they should be admonished or sanctioned as well as being banned from making autmated edits. WP:AWB users do not get to impose their style preferences on random articles (do we need to go into that history?) so I am baffled that Citation bot's operators imagine they should be allowed to do so. --Xover (talk) 17:23, 27 November 2018 (UTC)[reply]
    Comment - the action of removing these should be stopped until the RFC is completed. (Unless the owner is proposing to reinstate all removed items if this RFC concludes in favour of retaining.) Keith D (talk) 18:43, 27 November 2018 (UTC)[reply]
    +1, agreed. --User:Ceyockey (talk to me) 01:28, 28 November 2018 (UTC)[reply]
    If you believe these removals should be stopped with that much interest/investment, I left a threat at BOTN regarding this discussion. You may wish to add on to that thread to have the bot blocked. --Izno (talk) 03:37, 28 November 2018 (UTC)[reply]
    Comment - Wikipedia:Bots/Requests for approval/Citation bot is 10 years old. Is it even the same bot? Barely recognizable. My understanding is this is a user-triggered tool and tools don't require community approval. Every editor who uses it is responsible for their action. -- GreenC 22:45, 27 November 2018 (UTC)[reply]
    That is a concern as well. I am willing to contest that the original authorization even applies at this point in time given how the bot has changed since the original BRFA. --Izno (talk) 03:37, 28 November 2018 (UTC)[reply]
    @GreenC: That is strictly speaking correct, but in this case it amounts to sophistry: the rule that suggests removing these parameters is implemented by the bot maintainers and reflect their personal preferences, in a blatant attempt to impose that on articles in contravention of WP:CITEVAR. WP:AWB users are also responsible for the edits they make with the tool, but they had to have special rules added to prevent the users from running around thoughtlessly making edits that AWB suggested but which were considered controversial. What defaults are implemented in such a tool has a disproportionate impact, and hiding behind an argument that "it's the users' responsibility" is disingenous. It's a valid argument when a bug or edge case messes up an edit for otherwise uncontroversial cleanup (which parts of Citation bot's functionality and use I fully support), but not for explicit rules deliberately implemented in the tool itself. If you look at, e.g., Headbomb's argument below (and the issue at the bot's talk Izno linked), you'll see they argue for their preference for how citation should be formed and therefore the bot should behave this way, implicitly because that's the way to get their preferred style implemented across articles (I should note that I mean implicitly in the sense "the implication of which is"; it's not intended to suggest bad faith on the part of the ones making the argument. That I find it a bad argument does not make it a bad faith argument.). The correct and upfront approach to realising that desire is to argue its merits at WT:CITEVAR (any argument based on external style guides rather than enwp policy belongs there). Making that argument by way of bot is inherently an end-run around WP:CON. --Xover (talk) 07:46, 28 November 2018 (UTC)[reply]
    For the record I have no opinion either way on this issue. I agree that each bot function should be open to community consensus and presumably that is what this RfC does. If this RfC closes no-consensus it should be the same as 'no feature', the burden should be on those who want the feature to obtain consensus, which is in-line with how other bot consensus discussions work. -- GreenC 15:05, 28 November 2018 (UTC)[reply]
    The bot feature in question is a decade old. I don't have a strong opinion other than making sure that facts a kept straight. This feature is really old. AManWithNoPlan (talk) 04:08, 30 November 2018 (UTC)[reply]
    In your edit summary you claim bot is approved for this and historically it has consensus. Please provide a link for the bot approval for removing |publisher= and |location= from all {{cite journal}} instances in all articles as well as the community-wide consensus process that supports overriding WP:CITEVAR on this issue. Those are question #2 in this RfC and central to the issue under debate. --Xover (talk) 08:41, 30 November 2018 (UTC)[reply]
  • Keep, per compliance with pretty much every style guide out there. You will not find one single manual of style that recommends inclusion of the publisher for journals, stopping this function is a net negative for the project. Note that the bot does not remove the publisher for books and other non-journal publications, where certain style guides recommend the inclusion of the publisher. If disambiguation is needed, that's why we have the ISSN parameter. Publishers are not stable enough and can change several times over the lifespan of the journal. If a special snowflake citation is desired, for whatever reason, the usual mechanism of telling the bot "leave this one alone" works just fine, especially given that the bot does not edit automatically, and the activating user is responsible for the bot's edits. Headbomb {t · c · p · b} 18:06, 27 November 2018 (UTC)[reply]
  • Stop automated removal and continue to display per the arguments to that effect above. XOR'easter (talk) 18:48, 27 November 2018 (UTC)[reply]
  • Keep status quo per Headbomb (removal recommended). I think the removal is no big deal, but it's a net positive, inter alia, because people nearly always fill in the "publisher" parameter incorrectly, the publisher name changes constantly and often in non-obvious ways (for instance subsidiaries with slightly different names), and finally publishers or places nearly never help identification of journals or works in recent decades (you see people using the ISSN if they're desperate and all of DOI, IDs, names and dates failed them, but the possibility of people using publisher names for a journal is so remote that not even the typical SFX mask considers it, let alone modern discovery tools). The parameter is also used by a vanishingly small amount of citations, less than 1 % in the most recent XML dump (and they look like citations added by some automatic system, such as VisualEditor, without a specific consensus or user will, probably assuming that other automated systems would clean up). Nemo 22:08, 27 November 2018 (UTC)[reply]
    • The point isn't whether we should recommend removal in some or most cases. It's whether we should automatically remove the publisher in all cases, and/or prevent the citation template from ever even showing it. And 1% of our cite journal instances is a huge number of actual citations. So you're answering the wrong question. —David Eppstein (talk) 07:20, 28 November 2018 (UTC)[reply]
      • It doesn't remove publisher in all cases. It removes publishers by default, but you can overrule it by either 1) not activating the bot 2) putting a comment telling the bot to leave it alone. Headbomb {t · c · p · b} 14:46, 28 November 2018 (UTC)[reply]
        • The editor who added the citation cannot prevent removal of publisher or location by not activating the bot; it will almost always be some other editor who activates the bot. Putting in the comments is not a valid defence of CitationBot because the documentation about citation templates does not warn editors of the need to defend their work from CitatonBot. Jc3s5h (talk) 15:09, 28 November 2018 (UTC)[reply]
How does one trivially prevent another editor from running a bot, aside from just blocking the bot entirely? ♦ J. Johnson (JJ) (talk) 23:12, 28 November 2018 (UTC)[reply]
I was talking about the documentation update, but if you want to know about how to prevent citation bot from touching a citation, simply put a comment on the problematic citation (e.g. {{cite journal<!-- Bypass citation bot -->|...}}), or simply add {{Bots|deny=Citation bot}} to the article to tell it to leave everything alone. Headbomb {t · c · p · b} 14:49, 30 November 2018 (UTC)[reply]
The problem with "bots deny" is that one might want to be more selective than all or nothing servicing. And I've seen a bot-driver remove the bots-deny on the grounds that "all" is better than "nothing". On the otherhand, is this "bypass" comment simply a note to the bot-driver? Or is it bot detectable, possibly with specific requirements? ♦ J. Johnson (JJ) (talk) 21:44, 30 November 2018 (UTC)[reply]
@J. Johnson: As I understand it, the comments just make the bot skip over it by interrupting the string it searches for in the code (e.g., strings like {{cite journal|, presumably). It's still annoying that someone who might not even be aware that some future editor might go ahead and mess up all the citations by running a bot should be expected to go and comment out exceptions in all the fields which Citation Bot makes worse though. Umimmak (talk) 22:04, 30 November 2018 (UTC)[reply]
Curious. An undocumented feature? Well, thanks for that info. ♦ J. Johnson (JJ) (talk) 23:39, 30 November 2018 (UTC)[reply]
  • Keep status quo (per Headbomb and others) of consistency with nearly universal citation style.
Izno waves his hands around a bit alleging various points (such as "Several recent threads at User talk:Citation bot ..." and "the consensus in Module:Citation/CS1"), but his links don't point to any specific language supporting his alleged points. Perhaps there is something there (like, one comment at Citation bot), but waving one's hands around isn't the same as describing an actual problem. That is a poor basis for trying to generate consensus for multiple questions on a matter of deep significance. ♦ J. Johnson (JJ) (talk) 00:15, 28 November 2018 (UTC)[reply]
Comment I'm not sure which discussion Izno has in mind, but a quick search produces the following relevant discussions on User talk:Citation bot: Publisher (Nov 2018); Bug: Publisher weirdness (Oct 2018); Publishers being deleted & specific pages being changed to page ranges... (Oct 2018); I disagree with the Consensus the drives the bot's actions (Sept 2018); Do not remove the publisher (Jul 2018). Umimmak (talk) 01:10, 28 November 2018 (UTC)[reply]
^ --Izno (talk) 03:37, 28 November 2018 (UTC)[reply]
Nor am I sure which discussion Izno has in mind, lacking any definite statement of his argument. ♦ J. Johnson (JJ) (talk) 21:42, 30 November 2018 (UTC)[reply]
Those same discussions show that the users asking for the publisher parameter to be filled could not agree on which name to put in it, for instance in the case of what appears to be a society journal. Those who want publisher names in citations should first come up with a system to choose the name and settle disputes on it. (Do we have exact records for who was the registered/legal publisher of every journal dating back to centuries ago? See also Umimmak below.) Nemo 07:02, 28 November 2018 (UTC)[reply]
@Nemo bis: That's a valid argument on an individual article or at WP:CITEVAR. But in terms of enforcing it across articles by way of rules in an automated tool, CITEVAR exists because the community as a whole has decided that such issues need to be settled at each article rather than centrally imposed. As it happens I would prefer there be One True Citation Style for enwp—and would make a strong argument for what The One should be and in favour of strict enforcement—but CITEVAR has stood steady for ages and I see no reason to think the community-wide consensus on this has changed since the last time.
PS. And, yes, for most journals, at least in my field, we know exactly who the publisher of record is over time, and, where relevant, who the actual publisher is (other fields may differ). In some cases the publisher is relevant information (location less so, but sometimes relevant), and some times it's not. That this is difficult to determine in some cases, or that editors agree on the specifics in others, does not really bear on the general issue (there are cases where author is unknown or editors disagree on authorship; it's a problem in the specific case, but doesn't really impact the general case). --Xover (talk) 08:00, 28 November 2018 (UTC)[reply]
WP:CITEVAR is about styles for otherwise equivalent information. Just read it: «Editors should not attempt to change an article's established citation style merely on the grounds of personal preference». It's not about giving total freedom to anyone to add whatever they want to citations unless someone objects on each talk page. Otherwise tomorrow someone can start adding fax, phone number, street address, ZIP code and their library's preferred unique identifier in the "publisher" field on the grounds that it's what they find most useful for the specific citation. Nemo 08:30, 28 November 2018 (UTC)[reply]
Actually, yes, that's exactly what CITEVAR provides for. It's just that such extreme examples are very unlikely to be actually used by anyone, and it's exceedingly unlikely that such use would find consensus on that article's talk page. There are also technical limitations when using citation templates: for example, |url= must actually contain a valid URL (but these do not apply when not using citation templates). But whether or not to include publisher and location information for journal cites is absolutely within the scope of what CITEVAR addresses. To wit: the arguments for mass removing these refer to external style guides. (Note that there are several good arguments for why this information should not be added in a lot, or even the majority, of cases—some of which have been brought up here—but per CITEVAR these must be decided on an article-by-article basis). --Xover (talk) 10:52, 28 November 2018 (UTC)[reply]
And if you want to keep the publisher/location because you have a special snowflake citation, you can do that by 1) not activating the bot 2) inserting a comment in the citation template. However, I've yet to see a valid, on-Wikipedia case, of where publisher/location acts an actual disambiguator, rather than something that was just added automatically by tools, or added by users mistakenly thinking "if there's a parameter, the parameter must be used". But if the publication is somehow ambiguous, and there's a need for disambiguation (e.g. you don't have a DOI), then using the ISSN should be teh go-to solution, rather than figure out what corporate entity was publishing the journal at the time of publication, because that may very well have changed 3-4 times since the article was published. Headbomb {t · c · p · b} 11:53, 28 November 2018 (UTC)[reply]
  • Exclusion method needed—I think the argument about disambiguation among sources is pretty compelling. I do think, though, that many journals which are widely known and cited don't need the publisher/location information. In regard to publisher-often-wrong/changes-frequently ... the publisher at the time of the cited article is the one which should be reported, not updated to the most recent publisher, if, in fact, the publisher information is needed for disambiguation. All this being said, I'm thinking there might be an exclusion list would direct the bot to NOT take action on periodicals on the list; I wouldn't leave this up to an individual citation editor (i.e. an in-citation tag) as this would lead to chaos and a lot of warring. I'm thinking the number of periodicals which would need to be on the list would be relatively small, but I don't have a good sense of this. Definitely include information about the exclusion list and the bot activity in the Cite Journal template documentation. --User:Ceyockey (talk to me) 01:26, 28 November 2018 (UTC)[reply]
    Comment The thing with the types of journals which need non-ISSN disambiguation is that they tend to be older, obscurer publications. I doubt the usefulness of such a system just because I suspect most of these journals aren't going to be cited in that many different articles, but maybe I'm wrong on this. I do think it's safe to remove |location= if there already is |issn= to disambiguate (obviously not possible for journals which don't have one, due to, say, being discontinued before the 1970s), but that's not ideal to make it a requirement for removal since, I believe, for the most part ISSN isn't needed either. (The same many journals which are widely known and cited and which don't need the publisher/location information don't need an ISSN to identify them either.) Umimmak (talk) 01:38, 28 November 2018 (UTC)[reply]
  • While publishers/locations may not normally be necessary for normal, well known academic journals or magazines, the cite journal templates are also used for circumstances which aren't regular journals - examples include Annual publications like Jane's Fighting Ships which some editors will treat as a periodical and some as a book - in these cases, removing publishers would be harmful as it would remove valid metadata and make it more difficult to change between templates.Nigel Ish (talk) 23:24, 28 November 2018 (UTC)[reply]
    • The solution to GIGO situation is simple: Just revert the bot and fix the citation from the pre-bot version. Seeing the bot making those changes makes it immensely easier to actually fix those issues btw, since they show up in the diff, and will expose a problem. As for Jane's Fighting Ships, it's not a journal, and shouldn't be cited as such. If you want to cite it as a periodical, use {{cite magazine}} instead of {{cite journal}}. Headbomb {t · c · p · b} 01:21, 29 November 2018 (UTC)[reply]
      • You write as if there is a clear distinction between journals, magazines, and other periodicals (newsletters, yearbooks, trade magazines, bulletins, etc), that the distinction is easy for editors to make, and that the distinction is easy for automated citation-formatting tools such as Citoid to make. None of those things is true. —David Eppstein (talk) 01:39, 29 November 2018 (UTC)[reply]
  • Keep status quo – There is a reason why style guides recommend against. In the vast majority of cases, |location= and |publisher= are unnecessary clutter. Boghog (talk) 09:18, 30 November 2018 (UTC)[reply]
As a side note: that is a very interesting project. ♦ J. Johnson (JJ) (talk) 20:31, 2 December 2018 (UTC)[reply]
  • I don't think the removal should be automatic. Yes, in the majority of cases publisher and location information is unnecessary, but there are situations where it is helpful. One inolves disambiguation: when there are different journals that happen to have the same title. Another has to do giving enough information to be able to track down really obscure journals (typically without ISSNs or ones that have only ever had one or two issues published). – Uanfala (talk) 15:33, 3 December 2018 (UTC)[reply]
    • And you can tell the bot to ignore those extremely rare cases pretty easily. Worse case, a whitelist of such journals could be built. Headbomb {t · c · p · b} 15:49, 3 December 2018 (UTC)[reply]
      • But isn't that what optional template parameters are there for in the first place? {{Cite journal}} supports |publisher= and people who need to use this parameter, use it. And instead of allowing uses of the paramer but aslo having some automated tool that goes around and removes them all and then after that some editor who comes and builds an exclusion list, can't we, like, just not go through the whole rigmarole? If an editor has taken the trouble to specify a parameter, then it's best to assume they've done it for a reason (as far as I'm aware this paramter isn't filled in when you export citations from bibliography mangers, at least not from Zotero). – Uanfala (talk) 01:12, 4 December 2018 (UTC)[reply]
        • The vast, vast, vaaassst majority of those are parameter misuse by bots/tools that filled every parameter they could, or people that were given bad advice or under the misguided impression that if there's a parameter, it must be used. They are not added because they disambiguate anything. Knowing that Cell was published by MIT Press for a few years, then got purchased by Cell Press, who eventually got purchased by Elsevier add nothings to anything. And even worse, if you click on DOI, you're taken to the modern publisher page, even if the journal wasn't published by that publisher when the article got published, and will therefore lie to readers by falsely claiming Cell Press/Elsevier published the journal when it fact it was MIT Press. Again, having the publisher listed serves zero purpose whatsover, is often misleading, and goes against every style guide out there. So yes, it is simpler to remove by default, because the default is bad usage. Headbomb {t · c · p · b} 02:37, 4 December 2018 (UTC)[reply]
  • Stop removal and display. I agree with the arguments put forward by Jc3s5h and David Eppstein — Preceding unsigned comment added by Morgan Leigh (talkcontribs) 01:31, 4 December 2018 (UTC)[reply]
  • Keep—for all of those commenting that the templates should display the publisher, they already do. In most cases, the publisher name of a journal isn't needed and should be removed per the standards most style guides use. In the rare cases it's needed, 1) it will be displayed if provided, but also 2) adding a comment will prevent any bot from removing it. If it's not needed, it's just clutter in a citation. Imzadi 1979  03:18, 4 December 2018 (UTC)[reply]
  • Keep status quo and continue to remove them. (tJosve05a (c) 01:23, 9 December 2018 (UTC)[reply]
  • Stop removal as this is removing potentially correct and useful information. If it is no appropriate to display for some styles then that should be done at the template level, not by editing with a bot. Graeme Bartlett (talk) 11:54, 11 December 2018 (UTC)[reply]
  • Create a whitelist for the (rare) cases where |publisher= should not be removed. That will permanently solve the problem (and the whitelist could also be used by other tools). Even without a whitelist, I favour keeping the bot as it is, as the exceptions are rare, and we already have an easy way of stopping the bot on particular citations. --NSH001 (talk) 14:11, 11 December 2018 (UTC)[reply]
  • Stop removal and display instead. There never was a consensus to remove publisher and location information from citations, with one exception: In journal citations, the publisher sometimes has the same name as the journal itself, and only in these cases it was okay to remove the publisher. However, this scenario should be handled inside the template by suppressing the display of the publisher if it is the same as the journal name, so that the template still contains complete data for machines to read. In all other cases, it is perfectly okay to include publisher and location information per WP:CITEVAR, and often enough it is even interesting and useful information to know. In my own experience publisher and location information has often helped me to locate historic references in archives I would not have been able to find otherwise. Likewise, this info may also help future editors in locating references, including those which today may still be obtainable without this information. Therefore, when I know this information, I provide it as well - and I consider it downright rude and disruptive when another editor thinks he can remove it because he doesn't need it. It is possible that some editors have no use for it, but then they have just not run into those cases where it is viable. If those editors remove the info from citations, they are acting with the wrong attitude in a collaborative project, and if they even start edit-warring over it (as I have seen several times recently), they should be banned from the project - we don't need pushers and vandals here. The same goes for citation bot - this bot was never approved to carry out all the actions it tries to perform in recent months. Citation bot has been found to remove the info not only in the single case described above, but also elsewhere, including from non-journal citations. The shocking long list of complaints about issues on its talk page make me believe that the bot is broken beyond possible repair. It's not a single rule that needs to be removed, there are dozens, possibly hundreds of cases where it obviously malfunctions in bold ways. It is causing huge harm to the project instead of assisting us by working on routine cases as bots should do. Unfortunately, with the attitude shown by the bot / talk page maintainers towards complaints in recent months, I don't see citation bot ever being converted into something useful. They are part of the problem, therefore the bot should be stopped permanently. --Matthiaspaul (talk) 16:19, 15 December 2018 (UTC)[reply]

Stop removal - this should be done at the template level, if and when consensus can be reached. Or we could depreciate the parameters, rather than deleting possibly useful information.  Mr.choppers | ✎  16:36, 19 January 2019 (UTC)[reply]

url-access not working?

I've added a few |url-access=subscription parameters to {{cite news}} references in the George Shaw Wheeler article, and the icon indicating subscription access is not appearing in the reference. The parameters seem to work for {{cite web}} in the same article. Has the url-access parameter been disabled for this template? Was it inadvertently broken? -- Mikeblas (talk) 14:02, 26 December 2018 (UTC)[reply]

It's the PDF icon interfering with the access lock icon.
Whether that's a bug or intended behaviour I'm not certain of. --Xover (talk) 14:14, 26 December 2018 (UTC)[reply]
I don't know if this has never worked or has stopped working because of some change in the order of css application. Only one icon can occupy the space assigned for the external link icon: pdf or access. We must determine which of those is the one that wins. If we decide that the access icon should win then we can do this:
.cs1-lock-subscription a {
	background: url(/media/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png) no-repeat !important;
	background-position: right .1em center !important;
}
which will override the pdf icon with the access lock. I am not a css expert so there may be a better solution. Izno?
Trappist the monk (talk) 14:40, 26 December 2018 (UTC)[reply]
I would avoid the use of !important by increasing the specificity of the selector. It's possible that the specificity of the PDF icon was increased itself or !important set on that; we'd have to look into the CSS stack to see what caused the issue. --Izno (talk) 15:05, 26 December 2018 (UTC)[reply]
That said, the specificity on the styling is pretty high: div#mw_content a[href*=".PDF?"].external with 1 ID, 2 (pseudo) classes/attributes, and 2 (pseudo) elements. We maybe should see about changing mediawiki:common.css which has the offending rule. Removing the div#content from the rule would reduce the specificity to 2 classes and 1 element. The specificity on the other is .mw-parser-output .cs1-lock-subscription a which is 2 classes and 1 element, so that would override the common.css declaration (as it is loaded later). --Izno (talk) 15:16, 26 December 2018 (UTC)[reply]
As for when it worked/when it stopped working, it would have stopped working when we switched to TemplateStyles as inline declarations always take precedence regardless of any stylesheets loaded prior (including the user agent's, which is why TemplateStyles is preferable). --Izno (talk) 15:18, 26 December 2018 (UTC)[reply]
On an aside, there's a comment by Brion V about the ease of working with these icons. FWIW. --Izno (talk) 15:20, 26 December 2018 (UTC)[reply]
I have made an edit request at Mediawiki talk:common.css#PDF rules (pt 1) with my findings. As I said there, the rules here probably need to have a selector added, e.g. .citation. I haven't worked on that problem yet to verify if that's the exact solution. --Izno (talk) 20:52, 29 December 2018 (UTC)[reply]
The edit request went through and I have made the appropriate edits to the sandbox modules (catching a missing patch note on the way). You will need to verify the change on a page which has no other citations using {{cite news/new}}. --Izno (talk) 14:18, 5 January 2019 (UTC)[reply]

Total number of pages

In the description of the template "Cite book" for the parameter "pages" it is written: "do not use to indicate the total number of pages in the source". But how to correctly specify the total number of pages? I want to use this template in the "Sources" indicating the total number of pages, and then in the text to use refs on it with "sfn" template.--Nicoljaus (talk) 08:56, 28 December 2018 (UTC)[reply]

There is no need to specify the total number of pages in a source, even when you are listing it in a sources section and using sfn or the like. It doesn't matter whether a reference is 100 pages long or 300 pages long.Nigel Ish (talk) 09:33, 28 December 2018 (UTC)[reply]
I disagree. The total number of pages is always indicated in bibliographic descriptions. For example, it helps to navigate in different editions of the book, including various e-books.--Nicoljaus (talk) 09:49, 28 December 2018 (UTC)[reply]
Perhaps {{cite book}} is not the template for you. cs1|2 does not support total pages; does not support physical descriptions, viz. (cloth : alk. paper); does not support retail price: USD35.00; does not support / and — separator characters. cs1|2 is not ISBD.
You can always add the total pages info after the template's closing }}.
Trappist the monk (talk) 11:59, 28 December 2018 (UTC)[reply]
Price and physical condition is really not needed, but information about the total number of pages sometimes helped me out. However, thanks for the advice.--Nicoljaus (talk) 12:10, 28 December 2018 (UTC)[reply]
Total number of pages is irrelevant, and should not be mentionned. Headbomb {t · c · p · b} 14:39, 28 December 2018 (UTC)[reply]
"For example, it helps to navigate in different editions of the book, including various e-books."--Nicoljaus (talk) 15:24, 28 December 2018 (UTC)[reply]
It doesn't. Knowing the 35th edition has a total of 443 pages, and that the 32nd edition has 473 pages tells me nothing useful. Headbomb {t · c · p · b} 17:47, 28 December 2018 (UTC)[reply]
Have you heard about percentages, proportions, and so on?--Nicoljaus (talk) 19:14, 28 December 2018 (UTC)[reply]
Hm, different people have different backgrounds, experiences and uses for our citation templates.
The need for a parameter to specify the total number of pages has been discussed many times over the years. It is also implemented in citation templates in a number of other language editions of Wikipedia. While it is certainly not needed in every citation, there are uses and there is obviously a demand for it.
Personally, I find information about the total number of pages potentially useful in various ways: In articles about authors and publications, they are useful information in itself when multiple editions of a work are listed for comparison. This may help readers to decide, which edition to locate, or if an older edition in their possession should possibly be replaced by a newer version. In normal citations, the information may be useful to decide if the work is substantial enough to be worth looking into it at all, or, if it is worth to order the source as a whole or only the cited pages from an archive. There are also older / incomplete citations where knowledge of the number of pages helps to distinguish between editions. In cases, where the total number of pages distinguishes between the pages of the front, body and back matter, this may also give extra clues how to interpret the cited page numbers, thereby helping to reliably source particular statements in a larger or complex work. Finally, having a parameter for the total number of pages as well as for the cited page(s) will help editors to provide reference information more reliably (right now, many editors abuse the existing page(s)= parameter(s) to specify the total number of pages). This misuse will be reduced, if they have a separate parameter for the total number of pages.
It is possible to add the total number of pages in a comment following the citation when needed, but it would be more convenient to have a well-defined place inside the citation template itself, so that it becomes easier maintainable, to streamline the format being used, and also to make it machine-readable.
--Matthiaspaul (talk) 22:29, 1 January 2019 (UTC)[reply]
Thank you very much for the well justified opinion.--Nicoljaus (talk) 21:37, 2 January 2019 (UTC)[reply]
Unless you're including PDF in "e-book" then the number of pages is going to be thoroughly fluid according to whatever you're reading it on, what font you are using at what size. I fail to understand how the number of pages can possibly be more helpful than other parameters—like date or edition—to distinguish the source for a citation/reference which is what this template is used for. Please educate me? TIA HAND —Phil | Talk 17:28, 28 December 2018 (UTC)[reply]
Not only PDF, but also other variants, in which the text of a paper book after recognition is reformatted. At the same time, the paper book had, for example, 200 pages, the 50th page was indicated in the ref. If I would find (for example) only the electronic version, in which there are 400 pages, and then look at the 50th page, and on this page I will not find anything confirming the text of the Wikipedia article. But if I know that this is not just "50th page", but 50th out of 200, then I will look at the e-book of 400 pages in the 100th-page area and it will be much easier for me to figure it out.--Nicoljaus (talk) 19:11, 28 December 2018 (UTC)[reply]
It is of no use even for this role when the number of pages of an e-book will vary depending on the individual reader and its settings (such as screen size and text size), not on the edition. This would be only useful if you were writing citations for yourself.Nigel Ish (talk) 23:30, 31 December 2018 (UTC)[reply]
Have you heard of percentages, proportions, and so on? "Сitation for myself" does not need the total number of pages, because the values in the fields "page" and "pages" will be put down exactly the same way as in the edition I own. But this is necessary for people who may find another edition with a different total number of pages. Look at the above, I think the example with editions of 200 and 400 pages is quite simple and you can understand what the problem is.--Nicoljaus (talk) 21:34, 2 January 2019 (UTC)[reply]

Facsimile editions?

Does anyone know what to do when there is a facsimile reprint-edition and the original edition of the book *and* both are being cited in a single "Cite book" reference? For instance, I have come across a situation where I am trying to correct a referencing situation where another editor cited a 1974 reprint of a book originally published in 1902, but the pages vary on each version...I want to cite both editions in the same cite if I can... Thanks. Shearonink (talk) 04:23, 2 January 2019 (UTC)[reply]

Per WP:SAYWHEREYOUREADIT cite the version where you read it. The citations written by a previous editor could be left as-is, or if necessary, correct any errors in how the citation is written. Since that is the custom both within Wikipedia and elsewhere, readers will be confused if you try to combine two printings with different page numbering in the same citation. Jc3s5h (talk) 04:33, 2 January 2019 (UTC)[reply]
Per OKIWILLHEREYOUGO following is the mangled/error-riddled cite etc. It cannot be left as is so I'm going to fix it. Somehow.:
The article is Battle of Frenchtown, the ref in question is Ref #22. Here is the present code:
<ref>Alexander C. Casselman, ed., ''Richardson's War of 1812'', Vol. 1 (Toronto: Historical Publishing Co.) {{p. 132|date=1902}} facsimile edition by Coles Publishing Co., Toronto, {{p. 164|date=1974}}; Sandy Antal, ''A Wampum Denied, Proctor's War of 1812'' (Ottawa: Carleton University Press) {{p. 164|date=1997}}</ref>
which renders as
Alexander C. Casselman, ed., Richardson's War of 1812, Vol. 1 (Toronto: Historical Publishing Co.) Template P. 132 facsimile edition by Coles Publishing Co., Toronto, Template:P. 164; Sandy Antal, A Wampum Denied, Proctor's War of 1812 (Ottawa: Carleton University Press) Template:P. 164
So. My questions remains...How best to proceed? Is there a way to put both the original edition and the reprint/facsimile edition of a book in a cite? They're the same...yet different-ish. Thanks, Shearonink (talk) 14:25, 2 January 2019 (UTC)[reply]
@Shearonink: These are two entirely separate citations: one to a book published in 1902 (the original) and one published in 1974 (the facsimile). They are both editions of the same work, and may contain essentially the same text, but they are different citations: treat them as if they are completely separate books and you probably won't go wrong in practice. Start by including both of them as separate citations, depending on in which edition you found the information that the citation supports. Then, if you like, you can go find all the citations to the edition that you do not have, verify the information in the edition you do have, and then replace the citation with a new one to the edition you have. The end result is that only one of these two editions will be cited in the article. If my quick peek is correct, the only cite to this work is for a couple of numbers in the infobox: in which case you can check those numbers in the edition you have at the page number provided in the existing citation, and then simply delete the information for the other edition.
There is no (reasonable) way to cite both these editions in a single CS1-based citation template, and, as you've found, even doing so in plain text in a ref tag just ends up creating problems for other editors down the line. But on the other hand, it's not really a big issue for a single article to cite two different editions of the same work. It's a bit annoying for readers who have to track down both editions instead of one, but there's nothing really to say you can't choose to do that.
Personally, I would probably re-cite all instances to the original, as that is in the public domain and is easily accessible online (e.g. at Internet Archive). Something like this:
  • Casselman, Alexander C. (ed.). Richardson's War of 1812. Vol. 1. Toronto: Historical Publishing. p. 132.
And then delete the "facsimile edition by Coles Publishing Co., Toronto, P. 164" bit. The template invocation (curly brackets) around the page numbers is clearly by someone that's confused and can be safely removed (should be removed) completely independently of the main issue in this thread. --Xover (talk) 15:39, 2 January 2019 (UTC)[reply]
Yeah, figured there probably wasn't a real WP-way to use both. Nice to have the confirmation (and thanks for that link to the Internet Archive version). Cheers, Shearonink (talk) 18:44, 2 January 2019 (UTC)[reply]
Xover has already described one way to deal with such situations, but IMHO there are situations where mentioning both editions, the original one as well as the facsimilie edition is beneficial to readers, for example, when the historical original edition is very rare and difficult to obtain and the facsimilie edition is easily available, has extra data attached like ISBNs etc., is frequently cited in other sources, or is of particularly high reproduction quality. In such cases, both could be listed either as two adjacent but separate references or as two citation templates combined into one <ref></ref> block with some intermediate text. --Matthiaspaul (talk) 19:26, 2 January 2019 (UTC)[reply]

possible to allow date={{date}} template for date parameters?

It would be nice if I could use the {{date}} template within the date type of fields (access-date, archive-date, ...). Currently, setting date = {{date|2019-02-03|YMD}} results in an error.

Is this possible?

JamesThomasMoon1979 08:29, 3 January 2019 (UTC)[reply]

It isn't the use of the template that gives the error but the resulting format that is the error. YMD (2019 February 3) is not a format allowed by MOS:DATES so is not allowed by cs1|2. Allowed date formats using {{date}} work:
{{cite book |title=Title |date = {{date|2019-02-03|DMY}}}}
Title. 3 February 2019.
Trappist the monk (talk) 09:40, 3 January 2019 (UTC)[reply]
It may be easier to use CS1's |df= parameter, depending on what you are trying to achieve. – Jonesey95 (talk) 13:13, 3 January 2019 (UTC)[reply]
Please never support that, and maybe throw an error when that is used. Headbomb {t · c · p · b} 13:39, 3 January 2019 (UTC)[reply]
Too late. |df= has been supported since January 2016.
Trappist the monk (talk) 13:42, 3 January 2019 (UTC)[reply]
Headbomb, what is your antecedent for the word "that"? There are a few different things discussed above. – Jonesey95 (talk) 13:44, 3 January 2019 (UTC)[reply]
I was referring to |date={{date}}. Headbomb {t · c · p · b} 13:54, 3 January 2019 (UTC)[reply]
Not possible to detect the use of {{date}} because that template is processed before the cs1|2 template; the module only sees the result of the {{date}} transclusion (a date string).
Trappist the monk (talk) 15:18, 3 January 2019 (UTC)[reply]

@Jtmoon: according to Template talk:Date#Shouldn't use 11 May 2025 in articles. Easy cleanup using safesubst: and Template:Date/doc#Description the Date template should only be used internally in templates, not directly in articles. If you have been using it in articles please go back and change the articles to avoid the use of the Date template. Jc3s5h (talk) 18:03, 3 January 2019 (UTC)[reply]

Oh dear. --Izno (talk) 18:20, 3 January 2019 (UTC)[reply]
It doesn't say why it should only be used in templates, or even why it should be used in templates. Started a discussion there, at least the reasons should be documented. -- GreenC 18:25, 3 January 2019 (UTC)[reply]

Wow, thanks for the timely replies @Trappist the monk:, @Jonesey95:, @Headbomb:, @GreenC:, @Izno:, @Jc3s5h:.
When I wrote, " ... results in an error ", this was user error as Trappist the monk replied (。-_-。).
Jc3s5h, to clarify, I'm using date={{date|2018-01-04}} (a specific date), like here.
--JamesThomasMoon1979 11:20, 4 January 2019 (UTC)[reply]

I would definitely reconsider using this template at all, except for special applications. Plain text is less complexity and always preferred. The template can make things difficult for bots and tools to parse, the result is they will ignore citations containing it thus won't get needed maintenance work done. -- GreenC 18:53, 5 January 2019 (UTC)[reply]

Removing format=pdf when the URL ends in ".pdf"

Is there any reason not to remove |format=PDF when the URL is evidently ending in .pdf -- the template is able to detect it and add the PDF icon, |format=PDF is redundant. Or is it used for other purposes also? -- GreenC 18:48, 5 January 2019 (UTC)[reply]

The URL is opaque and ending in ".pdf" (or anything else) has no defined meaning. What determines the type of file is the HTTP Content-Type header in the response message. |format=pdf is an explicit labelling of content type. Thus, inferring file type by a heuristic inspection of the opaque URL and relying on the explicit labelling in |format= are not equivalent and replacing explicit labelling with the non-standards-compliant heuristic method would be both incorrect and a worse solution. --Xover (talk) 09:09, 6 January 2019 (UTC)[reply]
In plain English please? Because if you link to a PDF file, and the template automatically determined it to be a PDF file and automatically appends |format=PDF, then there's no reason for anyone to manually append |format=PDF in those cases. Headbomb {t · c · p · b} 14:48, 6 January 2019 (UTC)[reply]
Which part did you not understand? And the templates do not add any parameters by themselves, so |format=PDF is always added by an editor. --Xover (talk) 15:19, 6 January 2019 (UTC)[reply]
Nearly all of your post. As for |format=PDF, yes that's added by editors (and possibly bot/scripts), that's why I'd want citation bot to remove |format=PDF when they are automatically added, because it's just pointless clutter to have. Headbomb {t · c · p · b} 15:30, 6 January 2019 (UTC)[reply]
Well, if you do not understand the basics of how this works, would it not be a more prudent approach to attempt to gain that understanding? Because you've just written that you want Citation Bot to remove parameters added by human editors because they were added by human editors. Nothing that I am aware of automatically adds |format=PDF, and if anything (like Citation Bot) erroneously adds it automatically then the correct course of action is to prevent whatever that automated tool is from doing that in the future. It's possible that VE or Reftoolbar or something tries to be helpful by adding it based on some heuristic, but then it is also always saved by a human editor afterwards. In other words, the set you are describing is nil. --Xover (talk) 16:03, 6 January 2019 (UTC)[reply]
"Well, if you do not understand the basics of how this works, would it not be a more prudent approach to attempt to gain that understanding?" What exactly do you think this whole discussion is about, if not an attempt to gain that understanding? And the set isn't nil, because the redundant use of |format=PDF is widespread. Headbomb {t · c · p · b} 16:14, 6 January 2019 (UTC)[reply]
Well, I believe GreenC was looking for feedback and discussion on the merits of an explicit |format=PDF for citations which contain the string ".pdf" in the URL. However, based on your posts in this thread it appears that you are seeking justification for pursuing a course of action that you have already decided you want to pursue; because you're mostly just making assertions and not asking questions. Calling something which you do not understand "redundant" "pointless clutter" does not seem particularly apt to give the impression of someone who is seeking better understanding. --Xover (talk) 16:47, 6 January 2019 (UTC)[reply]
Is a (PDF) or a (PDF) better is the question. AManWithNoPlan (talk) 17:10, 6 January 2019 (UTC)[reply]
Clearly the former, as far as the reader/editor is concerned. The question is, is there a technical reason of some kind to not do this. Headbomb {t · c · p · b} 17:19, 6 January 2019 (UTC)[reply]
A reasonable question, but, as I explained in my reply to GreenC above, the syntax for URLs do not assign any particular meaning to what some are used to thinking of as a "filename extension" (which is an OS convention originating on Windows): that part of an URL is just an opaque text string. An URL ending in ".pdf" can (and not infrequently does) return something other than a PDF. The way to find out what's returned is to do a GET or HEAD request on the URL and look at the MIME media type returned in the HTTP Content-Type header of the response. Conversely, |format=PDF in a citation template reflects an editor's explicit intent to indicate that the resource referenced by the associated URL is a PDF file. That is, it reflects human judgement. Their intent may well be misguided, of course, and their judgement flawed, but there is no reasonable way to determine that absent manual inspection (i.e. another human's judgement). In other words, the two methods to determine file type are not equivalent in function, implementation, or semantics (or, put anoter way, they're only "redundant" with eachother if you squint just right): and the one that is amenable to automated processing is both the worse (inaccurate, error prone) and not standards compliant. --Xover (talk) 17:39, 6 January 2019 (UTC)[reply]
(edit conflict) For clarity. When cs1|2 sees this:
{{cite book |title=Title |url=//example.com/some_doc.pdf}}
it renders this:
Title (PDF).
The pdf icon is added by MediaWiki:Common.css (search for pdf). That icon is a background image. That type of image does not allow for alt text so, for accessibility reasons, cs1|2 adds the (PDF) annotation. It does this by inspecting the value assigned to |url= using rules similar to those used by MediaWiki:Common.css.
At en.wiki it can be argued that |format=PDF is redundant when the file type extension of the value assigned to |url= indicates a PDF document. Other wikis copy citations from en.wiki and these other wikis may not have current version of the cs1|2 modules (may still be using some version of {{citation/core}}). Those wikis, benefit from the existence of our 'redundant' |format=PDF and we are not harmed by its presence.
Trappist the monk (talk) 17:29, 6 January 2019 (UTC)[reply]
More generally, I wonder if it is truly necessary to keep this mostly-legacy special-cased behavior around. I would actually move to remove it. --Izno (talk) 18:04, 6 January 2019 (UTC)[reply]

Language parameter

Not sure if I should be asking here or at MOS but I've noticed recently that a lot of citations are now including |language=en.

Is this some change in guidance/policy or it is perhaps the result of people using a particular gadget that adds the thing? I can understand the need to specify the language if it is not in English but this is the English language Wikipedia and it seems to me just to be more clutter in the edit window to announce what should be the expectation anyway. - Sitush (talk) 15:50, 8 January 2019 (UTC)[reply]

Citoid includes |language=en. The citation module obviously does not render anything in the final output. It is useful for translators to know what the language is. --Izno (talk) 15:56, 8 January 2019 (UTC)[reply]
Similarly, when the cs1|2 modules are used on other-language-wikis, when |language= is 'their' language, it is not rendered there. The exception is (for all wikis) when the local language is one of several languages listed in |language=.
Trappist the monk (talk) 16:01, 8 January 2019 (UTC)[reply]
Ah, I'd never looked at Citoid before. I still think it is clutter. I can't imagine we have that many translators, and I'm pretty sure most of them would recognise English when they saw it. Especially since they would be translating from the en-WP article anyway. - Sitush (talk) 16:16, 8 January 2019 (UTC)[reply]
It isn't for the translators but for the readers of en.wiki articles that have been translated for use on other wikis. WP:MED has a rather robust translation effort. |language=en at other-language-wikis tell readers of those wikis that this particular source is written in English so that is as useful to them as citations here with |language=fr.
Trappist the monk (talk) 16:33, 8 January 2019 (UTC)[reply]
Well, if an en-WP article has been translated for use on another wiki then it is surely a part of the translator's role to modify cites as required, just as they would also have to modify the article to comply with that wiki's policies and guidelines (different MOS, different RS etc). It still doesn't make it necessary to fill in the parameter with "en" here.
I am not disputing that the parameter has uses, I am querying why it should be filled by default with the native language of whichever wiki it is being used on. It seems that may be an issue more to do with the tools than anything else, ie Citoid, the RefToolbar and whatever else may do so. Oddly, and merely from casual experience rather than empiric study, it seems likely to me that the parameter is not being filled automatically with, say, |language=hi or |language=ta on this wiki even though that certainly would fit with the rationale you and others have explained; perhaps that is just because I haven't happened acrossl the right articles yet, although I look at hundreds most days and have not long since cut my watchlist down to ca. 4,000. - Sitush (talk) 19:36, 8 January 2019 (UTC)[reply]
What language it is filled in with depends on the URL being accessed and whether the publisher of that URL has made the metadata available to indicate the language of the work. I regularly see |language=de and |language=fr (and occasionally |language=ja) filled in with my uses of Citoid.
I doubt anyone here would be bothered if you removed |language=en from articles you care about; just know that it does have its uses and so you would probably have some resistance if you wanted to bot-remove them. In some articles, there are multiple-language works which will include English, which displays like Book (in French, German, and English), which does include English in the output so-as not to mislead the reader. --Izno (talk) 19:45, 8 January 2019 (UTC)[reply]
Ah, its generated from metadata - that would explain the scarcity of Indic ones, thanks. I've no intention of ever running a bot and don't even care for AWB, so no worries there, and I almost always do the cite templates by hand, the exception being the occasional use of the reflinks tool when I find an article with a load of barelinks and can't be bothered running through them all. I'm still not really seeing why inclusion of the parameter for native languages should be by default with Citoid and RefToolbar but then I don't understand your last sentence either, sorry, and suspect the answer lies in that. - Sitush (talk) 20:08, 8 January 2019 (UTC)[reply]
It also happens automatically if Wikipedia:RefToolbar automatically fills in the fields from a URL, and people might just not notice or care to remove it. Umimmak (talk) 18:21, 8 January 2019 (UTC)[reply]
I can imagine this being useful if the title of the work cited is not in English, but the work is; a book called "La Vie en Rose", for instance. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 8 January 2019 (UTC)[reply]
Perhaps, but again that would be a rare occurrence and could be dealt with as an exception to the rule. - Sitush (talk) 19:36, 8 January 2019 (UTC)[reply]

update to the live cs1|2 module weekend of 19–20 January 2019

I intend to update the live modules over the weekend of 19–20 January 2019

changes to Module:Citation/CS1:

  • add .cs1-maint, moved styling to styles.css; see discussion
    maint message presentation now part of cfr.presentation{};
    fixed extraneous trailing space character
  • i18n of language name separation; see discussion
  • recognize n and mdash entities in page/issue ranges; see discussion
  • remove support for 'interviewers' parameter; see discussion
  • expand support for tagged language codes; see discussion
  • get_iso639_code() bug fix; see discussion
  • bold all of |volume= when value is all digits or all uc roman numerals; see discussion
  • support for cite wikisource; see discussion

changes to Module:Citation/CS1/Configuration:

  • add .cs1-maint, moved styling to styles.css
  • remove support for 'interviewers' parameter;
  • add lang code for Sinhalese
  • expand support for tagged language codes;
  • remove cnr/montenegrin;
  • add lang codes for Hindi, Kazakh, Khmer, Nepali, Tamil
  • support for cite wikisource;

changes to Module:Citation/CS1/Whitelist:

  • remove support for 'interviewers' parameter;

changes to Module:Citation/CS1/Date validation:

  • i18n; add support for YYYY mmmmm DD date format (ml.wiki); see discussion

changes to Module:Citation/CS1/Identifiers:

  • i18n: support non-Latin script digits in |isbn=; <bdi>...</bdi> around ISBN to prevent reversal at right-to-left wikis; see discussion;

changes to Module:Citation/CS1/styles.css

  • add .cs1-maint, move styling to styles.css
  • increase specificity of <q> styling for consistency; see discussion
  • increase specificity lock styles; see discussion
  • refactor to group styling by function

Trappist the monk (talk) 11:48, 12 January 2019 (UTC)[reply]

Updating them in September 2018? Have you invented time travel lately? --Izno (talk) 14:42, 12 January 2019 (UTC)[reply]
No, I've been working on a secret you-know-what-I-want version of copy/pasta control (Ctrl+v+y+k+n+w+i+w) which, as you can see, is not yet production-ready.
Trappist the monk (talk) 15:13, 12 January 2019 (UTC)[reply]

Vertical version of commonly used parameters for Cite book?

I would like Template:Cite book to include a vertical version of commonly used parameters. --77.173.90.33 (talk) 17:21, 16 January 2019 (UTC)[reply]

The documentation is not protected. You are welcome to edit it. – Jonesey95 (talk) 18:02, 16 January 2019 (UTC)[reply]
Alrighty; done. --77.173.90.33 (talk) 18:14, 16 January 2019 (UTC)[reply]

Journal / Magazine / News(paper) uniformity

Bascially, this is a request to change the code of at least {{Template:cite magazine}} to behave like the rest of the volume/issue-based CS1 templates. Right now, we have the following:

  • Using cite journal: Last, First (2019). "Something reliable was printed here". Prestigious Academic Publication. 2 (7): 110–113.
  • Using cite magazine: Last, First (2019). "Something reliable was printed here". General Circulation Magazine. Vol. 12, no. 2. pp. 12–14.
  • Using cite news: Last, First (2019). "Something reliable was printed here". The Still-in-Print Newspaper. Vol. 75, no. 18. pp. 2B – 5B.

No two of these templates produce the same formatting as a result, which is a problem. Cite magazine's output is particularly glaring, with the "Vol." and "no." labels. It's particularly terrible in articles that use both forms of citation. Arguably, standardization of the page number display would be nice, also. Journal currently separates the page numbers from the previous elements with a colon but no "p." or "pp."; the others use the page abbreviation. I don't have a horse in the race for which is preferable, and frankly if I only got to make one change to CS1, the magazine situation has clear priority. Squeamish Ossifrage (talk) 22:45, 16 January 2019 (UTC)[reply]

Magazine was made that way in this edit as a result of this discussion. --Izno (talk) 23:06, 16 January 2019 (UTC)[reply]
At least with {{cite magazine}} it is clear what the elements refer to, in the others you are just presented with figures which are not identified and thus confusing. Keith D (talk) 01:03, 17 January 2019 (UTC)[reply]
I'd prefer more harmonization with cite magazine's formatting, which makes it clear what is being referenced in terms of the volume and issue number. I'd tack on that cite magazine and cite news should do one thing that cite journal does. When a publisher is given (which in most cases isn't needed, but that's another discussion), the publisher should not interrupt the volume/issue/page number grouping. Cite journal gets it right by keeping the volume/issue/page numbers together, because all three, if given, are used together to locate the article. I also think we might want to discuss a little capitalization consistency between "Vol." and "no.", but that could be done later.
  • Using cite journal: Last, First (2019). "Something reliable was printed here". Prestigious Academic Publication. 2 (7). Academic Publisher: 110–113.
  • Using cite magazine: Last, First (2019). "Something reliable was printed here". General Circulation Magazine. Vol. 12, no. 2. Magazine Publisher. pp. 12–14.
  • Using cite news: Last, First (2019). "Something reliable was printed here". The Still-in-Print Newspaper. Vol. 75, no. 18. Media Company. pp. 2B – 5B.
Imzadi 1979  07:38, 17 January 2019 (UTC)[reply]
One thing that positively seem weird to me is inserting publisher between issue and pages. Headbomb {t · c · p · b} 16:18, 17 January 2019 (UTC)[reply]
Agreed. Whatever anyone thinks about the rest of this, I think that placement is simply incorrect. As to the broader issue, I know that I prefer the cite journal formatting, but it's clear that others prefer the cite magazine formatting. Can we consider amending the documentation to suggest that either way is acceptable for "periodical" sources in general (WP:CITEVAR and all that), but that you shouldn't mix them (because doing so looks awful)? Squeamish Ossifrage (talk) 16:30, 17 January 2019 (UTC)[reply]
We should not tell editors to choose a template based on how they want the rendered citation to look. Creating nice rendering is the template's job, not the editor's.
While we're at it, the longstanding problem of radically different order of rendered elements depending on whether there's an author or not should be solved. Jc3s5h (talk) 16:34, 17 January 2019 (UTC)[reply]
There are many such longstanding problems. Try to keep focused to the particular ones in this thread. --Izno (talk) 19:08, 17 January 2019 (UTC)[reply]
I wouldn't mind if we switched to magazine style for journal citations. It's not how they're usually formatted in academic publications but I think they're more readable by non-specialists that way, and that's more important. While we're discussing the ordering of things, the language parameter is also misplaced. It's the individual article, not the journal, that has a language (a single journal may well publish things in multiple languages) so the language should be closer to the title of the article than the title of the journal. Here are the same three examples, with a language set:
  • Using cite journal: Last, First (2019). "Something reliable was printed here". Prestigious Academic Publication (in Brobdignagian). 2 (7). Academic Publisher: 110–113.{{cite journal}}: CS1 maint: unrecognized language (link)
  • Using cite magazine: Last, First (2019). "Something reliable was printed here". General Circulation Magazine (in Brobdignagian). Vol. 12, no. 2. Magazine Publisher. pp. 12–14.{{cite magazine}}: CS1 maint: unrecognized language (link)
  • Using cite news: Last, First (2019). "Something reliable was printed here". The Still-in-Print Newspaper (in Brobdignagian). Vol. 75, no. 18. Media Company. pp. 2B – 5B.{{cite news}}: CS1 maint: unrecognized language (link)
David Eppstein (talk) 07:05, 19 January 2019 (UTC)[reply]
Language is a known 'issue'. See comment to Jc3s5h. --Izno (talk) 15:12, 19 January 2019 (UTC)[reply]

Template Autocite web

Suggest create template:Autocite web, only giving a parameter: a URL in the template .

For example : {{Autocite web| https://www.google.com/hostednews/afp/article/ALeqM5hMD5bqWMFmMSpBvXr1Xo7eGqcM-Q}}


would generate:


{{Cite web | title = London West End show goes multi-lingual | url=https://www.google.com/hostednews/afp/article/ALeqM5hMD5bqWMFmMSpBvXr1Xo7eGqcM-Q | accessdate = 19 January 2019}}

and would show :


"London West End show goes multi-lingual". Retrieved 19 January 2019.

BoldLuis (talk) 20:35, 19 January 2019 (UTC)[reply]

You want User:Zhaofeng Li/reFill. It will suggest citation template contents for you based on a URL. – Jonesey95 (talk) 20:50, 19 January 2019 (UTC)[reply]

Cite episode and author

The documentation says this for |author=: Title of existing Wikipedia article about the author; can suffix with a numeral to add additional authors - what exactly should be added here? The directer? Teleplays writers? Story writers? Showrunners? Seems this (and |first= and |last=) should either be removed for this template or have a different name. --Gonnym (talk) 08:43, 22 January 2019 (UTC)[reply]

I think you are confused. That definition comes from Template:Cite episode#TemplateData for |author-link=.
Trappist the monk (talk) 09:48, 22 January 2019 (UTC)[reply]
Yes, you are correct, but the issue is still the same as it talks about the author. Also, one parameter above: |author-first= (or one of the other aliases) that says: Given or first name, middle names, or initials of the author; don't wikilink, use 'authorlink'; can suffix with a numeral to add additional authors. --Gonnym (talk) 11:21, 22 January 2019 (UTC)[reply]
Now I'm not sure what you are asking. The common element of the texts you quoted is: can suffix with a numeral to add additional authors so is your question about that?
Author parameters are about the author(s) of the source so if Abraham Lincoln is the author of the source and the template uses |last=Lincoln and |first=Abraham, set |author-link=Abraham Lincoln so that the rendered citation gives:
{{cite book |last=Lincoln |first=Abraham |author-link=Abraham Lincoln |title=Title}}
Lincoln, Abraham. Title.
Trappist the monk (talk) 12:56, 22 January 2019 (UTC)[reply]
I know what a book author is. I was asking how this is relates to a television episode. What value is expected for this parameter - the writers (and if so, which, as there are 3 different types)? the directer? The showrunners for the entire series? Each of those can be an entry for the author and at the same time all 3 are not authors of an episode. So asking again, should this parameter be available in {{Cite episode}} and if so, what value is the correct one and if it is kept, wouldn't a more correct parameter name be advisable as episodes don't have authors? --Gonnym (talk) 13:08, 22 January 2019 (UTC)[reply]
Someone had to author the words that the actors speak; someone had to author the stage direction, etc. Name the person or persons (never more than one in a single parameter) who authored whatever it is in the episode that you are citing. What is it that I am not understanding about your question?
Trappist the monk (talk) 14:45, 22 January 2019 (UTC)[reply]
That there is no author for an episode. There is a director, a writer, a screenwriter, a teleplay writer, a showrunner, an executive producer, but no author. As you can see these are very different credits from each other, so sticking them all to author is a bad style at best. --Gonnym (talk) 15:36, 22 January 2019 (UTC)[reply]
Is the question that you are really trying to ask: Can we add {{cite episode}}-specific |authorn= aliases:
|director= – once supported for {{cite DVD notes}}; removed long since
|writer=
|screenwriter=
|teleplay-writer=
|showrunner=
|executive-producer=
or is the question: Can we remove support for |authorn= along with its attendant aliases and related parameters from {{cite episode}} because episodes don't have authors? I dispute that last notion; someone or some set of someones must author an episode because fully-formed episodes don't simply appear as if by magic.
Trappist the monk (talk) 20:03, 22 January 2019 (UTC)[reply]
No need to guess what I really was asking, as I plainly said it 3 different types in 3 different ways So asking again, should this parameter be available in {{Cite episode}} and if so, what value is the correct one and if it is kept, wouldn't a more correct parameter name be advisable as episodes don't have authors? The situation now where "author"(or "first"/"last") should be used but not explained in any way what person should be added to it, does not add any value to articles. I personally wouldn't mind seeing it removed, as an author does not exist for an episode, that is, the audio-visual finished product. Unlike a book were it is mostly written by one person with an editor, the episode has many moving parts. An episode script does have an author, but not all scripts have the visual style written in them, which comes from the director (or even Director of Photography). So if you wanted to cite an episode for a reference to something visual or even a sound design, that isn't the writer. That said, if we do continue on keeping it, the parameter should be changed so a consistent use and visual style will show up when used. For example, when I saw it used today, the editor who added the template, added the roles in parenthesis "Marc Guggenheim & Keto Shimizu (writers) & Glenn Winter (director)", which I'll take a wild guess and assume is not how everyone who used it does. Also, to make things a bit more complicated, in the US there is a difference between "Writer A and Writer B" and "Writer A & Writer B" (WGA screenwriting credit system). --Gonnym (talk) 20:39, 22 January 2019 (UTC)[reply]
Maybe you did but you seem to be hung-up on author does not exist for an episode in some sort of a strict noun-form definition. I rather see author as a more generic term that can and should be applied as a parameter that names one who has created something that is being cited; |authorn= exists for all cs1|2 templates, it is not likely to go away.
That you find the documentation for {{cite episode}} inadequate is a common condemnation of all cs1|2 template documentation. If you can see how the documentation can be made better, please do so. I don't use the template so I am not qualified, and no, I did not write the template, I just implemented it in Module:Citation/CS1.
Lumping human names with roles in name-holding parameters is not good practice because that extraneous text corrupts the citation's author metadata (yeah, director, producer, whatever, if we had parameters with those names, would all be reduced to author k/v pairs in the citation's metadata). Editors who use |people= write citations that do not include the names of those people in the citation metadata because |people= is an alias of |authors= which, because of its free-form nature and the diversity of human naming constructs, is not included in citation metadata. cs1|2 is not bound by writer's guild rules just as it is not bound by Chicago, APA, or whatever other style guides are out there.
I suggest that you confer with editors in projects that use {{cite episode}} and with them develop a set of |authorn= aliases and the rules for their use and rendering. Give us links to those discussions.
Trappist the monk (talk) 13:25, 23 January 2019 (UTC)[reply]

Registration without url

The templates currently complain when given |accessdate= but no |url=. Shouldn't they do the same when given |registration= but no |url=? —David Eppstein (talk) 08:01, 23 January 2019 (UTC)[reply]

Yes. Or better, to deprecate and remove |registration= and |subscription=
Trappist the monk (talk) 09:02, 23 January 2019 (UTC)[reply]

Cite podcast: is host= really an alias of last= ?

I was trying to improve CITEVAR consistency in an article that included a {{cite podcast}} template, and I ran into a bit of trouble. I was trying to change a full name in the |host= parameter into two separate parameters for the host's name. The documentation says that |host= is an alias of |last=, so I tried this:

{{cite podcast|host=Smith|first=Jane |url=http://www.example.com|title=Podcast title}}Smith, Jane. "Podcast title" (Podcast).

I got two errors: "More than one of author-name-list parameters specified (help); |first1= missing |last1= in Authors list (help)". If |host= is an alias of |last=, I don't think I should get those errors.

Then I looked at the documentation, which says that this should work:

{{cite podcast|last=Smith|first=Jane |url=http://www.example.com|title=Podcast title}}Smith, Jane. "Podcast title" (Podcast).

It does work. This makes me think that the code and the documentation have a mismatch somewhere. Any ideas? – Jonesey95 (talk) 19:10, 23 January 2019 (UTC)[reply]

|host= is an alias of |authors= (plural). Not sure why, the {{citation/core}} version assigned |host= to |surname1= so the documentation is probably correct but the code has been wrong since January 2014.
Trappist the monk (talk) 19:22, 23 January 2019 (UTC)[reply]
That explains a lot. Possibly fixed in the sandbox, including addition of support for numbered host1=, host2=, etc. I did not fork more aliases to create host-last=, host-first=, and other flavors.
Cite podcast comparison
Wikitext {{cite podcast|first=Jane|host=Smith|sandbox=yes|title=Podcast title|url=http://www.example.com}}
Live Smith, Jane. "Podcast title" (Podcast). {{cite podcast}}: Unknown parameter |sandbox= ignored (help)
Sandbox Smith, Jane. "Podcast title" (Podcast). {{cite podcast}}: Unknown parameter |sandbox= ignored (help)
Cite podcast comparison
Wikitext {{cite podcast|first1=Jane|first2=Juan|host1=Smith|host2=Gomez|sandbox=yes|title=Podcast title|url=http://www.example.com}}
Live Smith, Jane; Gomez, Juan. "Podcast title" (Podcast). {{cite podcast}}: Unknown parameter |sandbox= ignored (help)
Sandbox Smith, Jane; Gomez, Juan. "Podcast title" (Podcast). {{cite podcast}}: Unknown parameter |sandbox= ignored (help)
I do not have actual Lua skills, though, so please check my work at some point. – Jonesey95 (talk) 20:36, 23 January 2019 (UTC)[reply]

Editor parameters and extra text

I've been fixing various citations tagged in Category:CS1 maint: Extra text: editors list for having extra text like "ed." or "eds." in |editor= and related parameters. Obenritter rightfully objected on the grounds that in some cases the template was not displaying "ed." at all, so removing the extra text misrepresents the displayed info by (incorrectly) suggesting to the reader than an editor of a work is actually an author. What I didn't realize was, as stated in the documentation of {{Cite book}}, If authors [are present]: Authors are first, followed by the included work, then "In" and the editors, then the main work. If no authors: Editors appear before the included work; a single editor is followed by "ed."; multiple editors are followed by "eds." I'm not sure why the presence of an author should negate the need to clearly identify editors beyond the use of "In", and I can't yet find an archived discussion that gets into this. Using Obenritter's examples:

  • CS1 error due to extra text, but the template is not displaying "ed." on its own because an author is present:
Peterson, Neal H. (2002) [1992]. "From Hitler's Doorstep: Allen Dulles and the Penetration of Germany". In George C. Chalou, ed. (ed.). The Secrets War: The Office of Strategic Services in World War II. Washington DC: National Archives and Records Administration. ISBN 0-911333-91-6. {{cite book}}: |editor= has generic name (help); Invalid |ref=harv (help)
  • Removing "ed." to dismiss the error message leaves Chalou without an "ed.":
Peterson, Neal H. (2002) [1992]. "From Hitler's Doorstep: Allen Dulles and the Penetration of Germany". In George C. Chalou (ed.). The Secrets War: The Office of Strategic Services in World War II. Washington DC: National Archives and Records Administration. ISBN 0-911333-91-6. {{cite book}}: Invalid |ref=harv (help)
  • The template displays "ed." when no author is present:
Hunt, Chris, ed. (2005). NME Originals: Beatles – The Solo Years 1970–1980. London: IPC Ignite!. p. 103.
  • The same citation with extra text creates a redundancy (and a CS1 error message):
Hunt, Chris, ed., ed. (2005). NME Originals: Beatles – The Solo Years 1970–1980. London: IPC Ignite!. p. 103. {{cite book}}: |editor-first= has generic name (help)CS1 maint: multiple names: editors list (link)

Thanks.— TAnthonyTalk 23:03, 25 January 2019 (UTC)[reply]

I'm grateful you raised this here, TAnthony, because I'd seen the changes you've been making and the problems they leave behind in the case of author-editors of a multi-contributor work.
I've nothing to add except to say I completely agree with Obenritter's objections and that this misrepresentation is a far more important issue than the need to fix apparent errors in the interest of maintenance. Readers don't view the inclusion of (manually inserted) "ed."/"eds" as any sort of an error, but they do get presented with incorrect information on authorship when the "error" is removed. It's like deciding that, in the interest of encyclopedia maintenance, we'll ignore a sourced credit that says someone provided a horn arrangement on a song and instead list the individual as a horn player. In fact, with many of the multi-contributor book sources, we end up vastly over-crediting an author-editor, because in reality they only write perhaps 10 per cent or less of the book. Which is why Wikipedia editors reinstate the "ed."/"eds" text after it's been removed. JG66 (talk) 01:02, 26 January 2019 (UTC)[reply]
I'm of a mind that "ed." or "eds." should always be included when the editor parameters are used, but the fact that they are intentionally left out under certain conditions suggests a discussion took place about it. I'm not up on style guides outside Wikipedia, so does anyone know if this " ed. only in the absence of an author" business is actually a thing?— TAnthonyTalk 01:17, 26 January 2019 (UTC)[reply]
I'm continuing to look thru old discussions like this one from 2013, which indicates this is a long-standing situation but has no background. Trappist the monk noted in this 2015 discussion:

The 'In <Editor> ...' formatting was introduced with the transition from {{citation/core}} to Module:Citation/CS1. Clearly it was done intentionally and is briefly mentioned at Module talk:Citation/CS1/Archive 3#Multi-phase transition to Lua cites. I didn't find the discussions that led to that decision; they may be in the archives of the individual template talk pages.

In the same discussion, Jonesey95 said:

APA does it the way we do for chapters within books, but with "(Ed.)" after the editor's name.

I'm hoping for some more background before this becomes a full on discussion regarding changing the template(s).— TAnthonyTalk 01:38, 26 January 2019 (UTC)[reply]
@TAnthony:@JG66: Thanks for ringing in JG66. Actually, it seems a bit ridiculous to me that simply adding ed. or eds. at the back end of the editor(s) name is somehow a major formatting concern, when in actuality it protects Wikipedia from having improperly attributed Sources in its Encyclopedia. If we are truly building an Encyclopedia, it seems academic integrity would FAR outweigh Wiki formatting nuances. --Obenritter (talk) 02:02, 26 January 2019 (UTC)[reply]
Yes, well put. That is precisely what I meant by the dubious identification of an "error" relative to what the reader's presented with on the page: "If we are truly building an Encyclopedia, academic integrity would FAR outweigh Wiki formatting nuances." JG66 (talk) 02:06, 26 January 2019 (UTC)[reply]

@TAnthony, JG66, and Obenritter: one point to consider is that the templates also emit metadata about the information they display. So if you're manually adding "ed." to an editor's name to get it to display, the template would include that extra text as part of the name in the metadata emitted. Assuming tomorrow that your desired extra text were added to the output display of the template, we'd still have to go through and remove the errant extra "ed." inserted in the input parameters because now we'd be displaying that indicator twice, once from the errant input and once from the modified display output.

In short, it's still an error to include extra text within an input parameter that's only supposed to supply the name, regardless of any modification of the output displayed. Imzadi 1979  03:07, 26 January 2019 (UTC)[reply]

@TAnthony, JG66, and Imzadi1979: So input parameters and metadata takes precedence over academic integrity? #Wonders_why_he_bothers_sometimes --Obenritter (talk) 04:09, 26 January 2019 (UTC)[reply]
I'm sorry, Imzadi1979, but I have no interest in the issue of metadata emission (or, more accurately, any understanding of the concept). If it is a problem, then the solution remains to ensure that the template actually displays "ed." as it does in the "when no author is present" example given above by TAnthony. I freely admit I'm coming from a position of total ignorance with regard to metadata, but not so writing and ensuring that information is accurately and responsibly reproduced on Wikipedia – which I've always understood to be a central tenet of the encyclopedia. JG66 (talk) 04:30, 26 January 2019 (UTC)[reply]
@Obenritter and JG66: if you were to use |editor-first=John, ed. |editor-last=Doe to get "In Smith, John, ed." as part of the citation, the CoINS data embedded in the output that can be read by Zotero and other bibliographic tools will be told that the first name of that editor is "John, ed.", which is exactly what you input into the parameter. If you use |editor=Richard Roe, ed. to get "In Richard Roe, ed." in the citation, the same issue happens, telling those bibliographic tools that his name includes ", ed.". Setting Zotero aside, editors reading the direct wikitext will be told, in a literal sense, that either name includes ", ed.", although I'm sure we'd all agree that many people would intuit that the text doesn't actually form part of the name.

For whatever past reasons to which I'm not aware, the "In" text in the middle of a citation followed by a name was used to indicate that the name that followed would be an editor, and again for whatever past reasons to which I'm not aware, it was decided that "ed."/"eds." was unneeded in that case. Conversely, if there was no author indicated, the "ed."/"eds." was inserted to distinguish the placement of a name at the front of a citation as an editor instead of an author because that name was moved to the position normally occupied by an author. In a use case not displayed above, if we have a book with authors and editors, but no individual chapter/contribution being cited, you get something like:

  • Doe, John (2019). Roe, Richard (ed.). Important Book. City: Publisher. p. 47.
Now then, for consistency reasons and simplicity, you'd probably prefer that the output always displays the "ed."/"eds.", and that editors would no longer have to manually insert the "ed."/"eds." text. I'm all for giving clearer indications of what the content in a citation means. See my preferences in another discussion thread about using a slightly more verbose method to list a journal citation's volume, issue and page numbers. Given that, I'd probably support making the change myself, and if that change were made, the extra text would still need to be removed to avoid duplication and to avoid corrupting the metadata. Imzadi 1979  06:46, 26 January 2019 (UTC)[reply]
Imzadi1979, thank you for your detailed reply. The second point you make, at the conclusion of which you talk about how the absence of an individual chapter means that "ed." is displayed, just highlights how nonsensical it is, surely, that the template omits the qualification in other instances. The Cambridge Companions to Music series has clearly designated editors who make some, but comparatively minimal, writing contribution to the volume; and there's no doubt they are the author-editors. So what on earth is Wikipedia doing ignoring credits that appear on each book's cover, title page and CIP entry? I guess we'll find out if and when anyone else unearths a rationale for this author-editor + chapter title scenario.
I'd seen the recent journal citation discussion, yes. I'm all for greater clarity in these templates; the cite AV media template is a real nightmare, as far as I'm concerned – the displayed text often only makes sense when one opens an article's edit window and reads the content accompanied by the relevant field. I'm getting ahead of myself but, assuming that we can restore "ed." in the display for cite book, I'd like to see it enabled that, if an article's style is British English/EngvarB, then the plural form can be rendered as "eds" (not "eds."). That's in keeping with British (and Australian) usage, where a full stop is not required if the abbreviation (contraction) ends in the last letter of the unabbreviated form, per WP:MOS#Full stops and spaces. JG66 (talk) 12:49, 26 January 2019 (UTC)[reply]
Regarding that last, we've had a discussion on it. You were involved. It was archived just recently. Please start a new section if you would like to revisit the question. --Izno (talk) 15:38, 26 January 2019 (UTC)[reply]
Izno: That was not a discussion about removing the period from "eds." JG66 (talk) 16:17, 26 January 2019 (UTC)[reply]
Gosh-does-it-sound-the-same. I'd oppose your suggestion here as well for the same reasons as there. --Izno (talk) 16:19, 26 January 2019 (UTC)[reply]
Chicago supports an explicit "ed" or similar statement [1] as does the APA [2] as does MLA. I would guess others similarly do so. Adding the explicit statement of editorship would somewhat duplicate the "in" statement, which may have been cause for the removal. --Izno (talk) 15:38, 26 January 2019 (UTC)[reply]
I've removed the special case in the sandbox. I have no opinion on the change, but this is how it would look.
Peterson, Neal H. (2002) [1992]. "From Hitler's Doorstep: Allen Dulles and the Penetration of Germany". In George C. Chalou (ed.). The Secrets War: The Office of Strategic Services in World War II. Washington DC: National Archives and Records Administration. ISBN 0-911333-91-6. {{cite book}}: Invalid |ref=harv (help)
--Izno (talk) 16:02, 26 January 2019 (UTC)[reply]

Common usage section should include |archive-url=| and |archive-date=| even though if usage isn't as common as it should be and a lot of pages are NOT saved and protected from Link rot as a result, the way it automatically pulls usage data from all the language wikis and shows the most common is very technically impressive but not the most reasonable thing to do when setting guidelines for usage as it simply encourages people to carry on with the way things are instead of encouraging to do them better. --Archive everything do it now (talk) 17:17, 26 January 2019 (UTC)[reply]