This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 70 | ← | Archive 72 | Archive 73 | Archive 74 | Archive 75 | Archive 76 | → | Archive 80 |
In
{{
cite journal}}
: Check |doi=
value (
help)The DOI is clearly invalid. The format is 10.####/ or 10.#####/ and nothing else. Headbomb { t · c · p · b} 05:18, 4 January 2021 (UTC)
If a book is available online, we enter |url=
, and if this URL is dead we can enter |archive-url=
. But there is no such equivalent for chapter-specific links, i.e. |chapterurl=
. Is there is specific reason for that? (for a specific example, I could've just used such an option
here.) --
bender235 (
talk) 17:25, 2 January 2021 (UTC)
{{cite book |first=Michael P. |last=Barnett |authorlink=Michael P. Barnett |chapter=Symbolic calculation in the life sciences: trends and prospects |title=Algebraic Biology 2005 |series=Computer Algebra in Biology |editor-first=H. |editor-last=Anai |editor2-first=K. |editor2-last=Horimoto |publisher=Universal Academy Press |location=Tokyo |year=2006 |chapterurl=https://web.archive.org/web/20060616135155/http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf }}
{{cite book |first=Michael P. |last=Barnett |author-link=Michael P. Barnett |chapter=Symbolic calculation in the life sciences: trends and prospects |title=Algebraic Biology 2005 |series=Computer Algebra in Biology |editor-first=H. |editor-last=Anai |editor2-first=K. |editor2-last=Horimoto |publisher=Universal Academy Press |location=Tokyo |year=2006 |chapter-url=http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf |archive-url=https://web.archive.org/web/20060616135155/http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf |archive-date=2006-06-16}}
|archive-url=
, its assigned value applies to |chapter-url=
(or aliases) even when |url=
is present; without |chapter-url=
(or aliases), |archive-url=
applies to |url=
.|chapter=
and |title=
as well as |chapter-url=
and |url=
, this model could be extended so that if an |archive-chapter-url=
parameter would be given, it would be taken as archive link for |chapter-url=
instead of |archive-url=
(and |archive-url=
for |url=
). I have run into citations where it would have been desirable to specify independent archive links for chapters and work titles.There are quite a few URL-related arguments and IMO having separately named archive-url/archive-date/url-status for each is a lot of complication. There is {{
webarchive}}
for those archive URLs that don't fit the current model. --
Green
C 16:14, 3 January 2021 (UTC)
{{
webarchive}}
too verbose to use - readers typically care about the fact that they can access an archived link, but don't care about the name of the archiving service.What is the correct markup for a range of hyphenated page numbers? Is |pages=4-5{{snd}} 4-7
(4-5 – 4-7) correct or should it be |pages=4{{hyphen}}5{{snd}}4{{hyphen}}7
(4-5 – 4-7)?
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 15:17, 3 January 2021 (UTC)
|pages=4-5 – 4-7
. Or you could write |pages=4-5 to 4-7
.
Jc3s5h (
talk) 16:12, 3 January 2021 (UTC)|pages=4-5-4-7
(all simple keyboard hyphens) and let cs1|2 figure out the rendering:
{{cite book |title=Title |pages=4-5-4-7}}
|at=
, anticipating that well-meaning editors will come along and mangle the carefully constructed page range. |at=pp. 4-5–4-7
should work. –
Jonesey95 (
talk) 18:51, 3 January 2021 (UTC)|pages=((4{{hyphen}}5–4{{hyphen}}7))
, where the thing in the middle is an n-dash.
Jc3s5h (
talk) 18:55, 3 January 2021 (UTC)
|page=hyphenated-number
and for |pages=simple-range
, but does not spell it out for a range of hyphenated numbers. Thanks.
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 19:48, 3 January 2021 (UTC)
I am concerned that the documentation for these templates, both Help:Citation Style 1 and Template:Citation Style documentation, is becoming bloated with redundant prescriptive injunctions, which degrade its value as documentation. In this case, the admitted purpose is to further a position in a dispute on this talk page, but the problem is broader, and has been going on for some time.
Bloated documentation wastes users' time, and makes it harder for them to find the information about the templates that they seek. The documentation should define the meaning of each parameter concisely, and not expand with polemics on what they should not be used for, especially when this is already a logical consequence of the definition. Kanguole 22:26, 4 January 2021 (UTC)
I know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized. We save that for newspapers and magazines. Where is the MoS guideline for when NOT to italicize those listed news sources? An editor seems to think it makes no difference, and they are changing the citations all over the place so that those agencies are italicized. When I'm in doubt, I just look at the article for the source and see how it's done there, because I know that other editors have followed the MoS. -- Valjean ( talk) 01:20, 25 November 2020 (UTC)
|publisher=
for |work=
. The "work" is what is generally considered as the source, and this (unlike "publisher") is emphasized, in most cases with italic type. I would recommend a compromise: use the website (e.g. www.npr.org) as the "work", and NPR as the "publisher" of such work. And let the software format them accordingly.
69.94.58.75 (
talk) 12:30, 25 November 2020 (UTC)know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized? In cs1|2, the name of the source (the publisher's work) is italicized. If the source is a website, the name of the website is italicized; if the source is a magazine, journal, newspaper, or other periodical, the name of the magazine, journal, newspaper, or other periodical, is italicized; if the source is a book, the name of the book is italicized; if the source is a corporate entity initialism or broadcaster call-sign, the initialism or call-sign is italicized. This applies to both physical an online sources. It does not matter if the initialism of a cited source is the same as the initialism of the business that produced it.
and this:Do not append ".com" or the like if the site's actual title does not include it ... and omit "www."
The "publisher" parameter should not be included for widely-known mainstream news sources, for major academic journals, or where it would be the same or mostly the same as the work.
So why not go to these articles ( PBS, NPR, CNN, ABC, NBC, BBC) and try to italicize them?Why would I want to do that? The articles are about those entities as businesses; we do not cite the business, we cite the business' work (its programming, its articles, etc), and the work, in cs1|2, is italicized.
I know that publisher= and website= produce italics, and work= does not. Umm, not true...
|publisher=
is not rendered in italics but both |website=
and |work=
are (along with their aliases |newspaper=
, |magazine=
, |periodical=
, and |journal=
).{{
cite magazine}}
and |magazine=
. Both
The Guardian and
The Washington Post are newspapers so {{
cite news}}
and |newspaper=
.
Fresh Air isn't a news program nor is it a journal or a magazine or a newspaper, so {{
cite web}}
(because you included a url) or because it's aired periodically (daily where I live) you might use {{
cite periodical}}
(a redirect to {{cite magazine}}
) and |work=[[Fresh Air]]
. You can include or omit |publisher=[[NPR]]
as you choose. Hanging the program name after the cs1|2 template as you did means that the name is not included in the citation's metadata (for those who consume our citations using various machine tools).The list should also specify the ideal template to use– my answer would be always use {{ Citation}} for all citations. If you like full stops/periods all over the place, then add
|mode=cs1
. I'm sure that many editors would strongly disagree, which is why the list should not specify the ideal template to use.
Peter coxhead (
talk) 17:15, 28 November 2020 (UTC)|title=Title of Article Here
|work=[[BBC News]]
, and do not include |publisher=[[BBC]]
which would be redundant and would treat our readers like they have severe brain damage. If you're citing a news source that has no clear title beyond its domain name, then do |work=Whatever.com
. If you're citing a work that has the exact same name as the publisher (aside maybe from an appended "Inc." or "Ltd" in the latter case), put the name in |work=
, even if the wikilink in it (if any) goes to a company article (the publication is a subtopic thereof), and omit |publisher=
. E.g., the title of npr.org really is NPR, which is also the common name of the organization (in longer form National Public Radio), ergo: |work=[[NPR]]
. If this just makes your head asplode, no one is likely to care if you do |work=[[NPR|NPR.org]]
to distinguish a bit between company and output. But someone is apt to remove the .org later, because it is not actually a part of the title of the work. You cannot omit the work title and just use the publisher in an attempt to avoid italics because you have some weird notion in your head that online sources shouldn't receive the same style as dead trees ones. If you do that, you are writing broken citations and someone will correct them. If you revert-war against these corrections you are being disruptive and need to give up your lost cause. [PS: I'm using a generic "you" in this; it's not directed at a specific party in this thread, but at a diffuse cloud of editors who keep trying to abuse template parameters to de-italicize things and to pretend that we're citing a corporation rather than a published work produced by a corporation.] —
SMcCandlish
☏
¢ 😼 19:54, 4 December 2020 (UTC)|work=
is always required (|website=
and |newspaper=
, etc., are aliases of it); Wikipedia only cites published works (see
WP:V and
WP:CITE); it does not cite companies, persons, or other entities, only works by them. The |publisher=
should be added, as additional source-identification information, only if significantly different from the title of the work (do |work=The New York Times
not |work=The New York Times
|publisher=The New York Times Company
). If the name of the website is ABC News then that is in fact the title of the work, despite that also being part of the name of publisher. (It's also harmless to do |work=ABCNews.Go.com
, though that's a bit sloppy.) The actual publisher is ABC News Internet Ventures, a division of ABC News Network, a division of American Broadcasting Company, a division of Walt Disney Television, a division of the Walt Disney Company (most or all of which also have corporate postfixes like "Inc." in their full names). None of these names need appear in a citation, because they are either redundant with the |work=
at the lower levels, or too lost in financial-holdings arrangements, at the upper levels, to be meaningful to the reader in relation to a citation. (In most contexts, anyway. In a WP article about Disney or one of its other properties, it might in fact be pertinent to indicate that Disney is the ultimate publisher, either with that parameter or with a free-form note, so the reader has a clear indication of the source's lack of complete independence from the subject.) —
SMcCandlish
☏
¢ 😼 22:52, 31 December 2020 (UTC)PS, an aside to address of a bit of
WP:WIKILAWYERING that was attempted at one of the redundant concurrent threads: When the |work=
parameter (or one of it aliases) does not apply (e.g., the cited material is stand-alone and not part of a broader publication), then |title=
is the work being cited. So, yes, the work is always required, just not necessarily in the form of the parameter by that name. Another side point that's been covered before: When any website is cited by WP, it is cited as a published work (by definition), not as a shop or server or corporate entity or whatever else the same name might refer to outside of a citation-to-published-work context, where it gets italicized, even if it would not be italicized in running text as a service or company or whatever. —
SMcCandlish
☏
¢ 😼 19:41, 1 January 2021 (UTC)
|work=
and |publisher=
in many cases (when they are not basically the same): {{Citation|Title=He Smart|work=The Evening News with Walter Kronkite|publisher=Fox Sports}}, that raises the question of which is better when someone skips the work and goes straight to the publisher, which of these is better : {{Citation|Title=He Smart|work=Fox Sports}} or {{Citation|Title=He Smart|publisher=Fox Sports}}
AManWithNoPlan (
talk) 15:23, 2 January 2021 (UTC). If anyone is claiming that the |work=
or an alias thereof is always required, I call bullshit. Nonprofit organizations and for-profit corporations publish stuff all the time and what matters is the organization or corporation. When
Amnesty International publishes something, it is |publisher=Amnesty International
. When
Human Rights Watch publishes something, it is |publisher=Human Rights Watch
. When
The Heritage Foundation publishes something, it is |publisher=The Heritage Foundation
. When
United Airlines publishes something, it is |publisher=United Airlines
. When
Nestlé publishes something, it is |publisher=Nestlé
. Bonafide news organizations are the same. When
NPR does a news story, it is |publisher=NPR
. If the story is part of
All Things Considered, publisher is an optional addition to |work=All Things Considered
. When
BBC News does a news story, it is |publisher=BBC News
. These organizations existed long before the World Wide Web, and the existence of npr.org does not turn NPR into a "work".
How do we know BBC News is not a work? Just as Chevrolet is part of General Motors, BBC News and BBC Sport are part of BBC. Just as Chevrolet is not a "work" of General Motors, BBC News is not a "work" of BBC. Similarly, Fox News and Fox Sports are divisions, not works, of Fox Corporation. — Anomalocaris ( talk) 06:23, 3 January 2021 (UTC)
|publisher=
parameter for the value that belongs in |work=
just because some citations don't have a |work=
value to put anywhere (those that do not will have their sole work title in |title=
, which is still a work). So, let's not be silly. What this is about is the difference between a publication (a work), and a publisher (a business, nonprofit, or governmental entity). As shown above, trying to claim that CBS News is not the work (when the actual title of that work is provably CBS News) but is instead the publisher (when the actual publisher is provably CBS Interactive) is fact-falsification twice over. That some editors are so obsessed with the strange notion that online sources are magically exempt from the italics style applied to all publications regardless of medium, that they'll engage in falsification to trick the templates into giving them their way, is a strong indication that some topic bans from changing these parameter values around in citations is probably in order, to prevent further damage to citation integrity and factuality. —
SMcCandlish
☏
¢ 😼 20:20, 3 January 2021 (UTC){{cite news |title=Newly released docs show world's reaction to Nixon's resignation |date=August 24, 2016 |publisher=CBS News |url=https://www.cbsnews.com/news/richard-nixon-resignation-newly-released-docs-show-worlds-reaction/}}
:
"Newly released docs show world's reaction to Nixon's resignation". CBS News. August 24, 2016.{{cite news |title=Newly released docs show world's reaction to Nixon's resignation |date=August 24, 2016 |work=CBS News |url=https://www.cbsnews.com/news/richard-nixon-resignation-newly-released-docs-show-worlds-reaction/ |agency=Associated Press}}
|agency=Associated Press
. But that doesn't turn the business entity CBS News into a work. It's just a division of a larger corporation. —
Anomalocaris (
talk) 23:35, 3 January 2021 (UTC)
|work=
(or an appropriate alias). This is no different from that same story from AP were it published in a newspaper.|title=
parameter name with what a title is (see
MOS:TITLES). That which goes in |work=
is also a title. So is what goes in |series=
; they are simply titles of different things. And |title=
isn't even the same parameter in different templates. In {{
cite book}}
it is the title of the entire work (the "article" equivalent in that template is |chapter=
). That is, in {{
cite web}}
and the periodical citation templates, |title=
takes the place of |chapter=
in the book template, and |work=
or one of its many aliases takes the place of |title=
in the book template. Honestly, at this point your unfamiliarity with the templates, their parameters, and even the basic terminology of source citation makes me wonder why you are in this discussion. PS: Even if you were correct that "[CBS News is] just a division of a larger corporation", that still would not make it the |publisher=
; the larger corporation or other entity would be (in this case it is
CBS Interactive, which is too similar to the work title to bother including). But it's a false statement to begin with, as has already been explained to you (please see
WP:IDHT); "CBS News" is both the name of that division and the title of several works by that division and subsidiaries thereof, including the CBS News website. —
SMcCandlish
☏
¢ 😼 00:10, 4 January 2021 (UTC)|website=
. It did not comment on when |website=
vs |publisher=
should be used - ie whether a particular entity is best described as a work or a publisher.
Nikkimaria (
talk) 03:04, 4 January 2021 (UTC)
|work=
and |publisher=
parameters and to not abuse them for stylistic reasons. I tried to improve the documentation by stating this explicitly and adding a crosslink but was reverted by Kanguole (
[1]) for this would be bloating the documentation. In fact it does and I would prefer we would not need it, but looking at the discussion above apparently we do. My time is limited and I do not care enough about this triviality to further engage into this discussion, therefore I leave it to others to restore the sentence and link - or not - as they see fit.
User:Monkbot/task 18 is a cosmetic bot task. Among the various things that it does is replace nonhyphenated parameter names with their canonical hyphenated names. One of those replacements is |accessdate=
to |access-date=
.
I have started this discussion because an
editor at my
talk page has objected to the bot's replacement of |accessdate=
: accessdate is not currently deprecated, there is currently no discussion about deprecating it, and your only basis for replacing it by bot is the concern that were we to get consensus to deprecate it at some unknown future point, error messages would annoy people?
For the time being, I have disabled the |accessdate=
to |access-date=
replacement.
I believe that it is our intent to deprecate and remove all of the all-run-together multiword parameter names in favor of their hyphenated forms. Am I wrong? At the bottom of the §Deprecated section of every cs1|2 template (except Template:Cite citeseerx/doc) is this:
In addition to the above list(s) of deprecated and removed parameters, all non-hyphenated aliases of parameters with hyphens are discouraged to be used in citation templates and are kept only for legacy support. They are subject to becoming deprecated and unsupported in the future as well. To streamline the appearance and improve consistency across the project, these variants should no longer be used when adding parameters to citation templates. Instead, select the hyphenated parameter variants and also consider switching other non-hyphenated parameters, which may be present in a citation already, to their hyphenated equivalents at the same time. – emphasis in original
A variant of that text is present at Help:CS1 errors#Cite uses deprecated parameter |<param>=:
Plan for the future: All non-hyphenated, multiword parameter names are aliases of hyphenated multiword parameter names. The non-hyphenated aliases exist only for legacy support. Editors should expect that support for non-hyphenated parameter names will be withdrawn. Choose the hyphenated form when adding parameters to a citation template. Consider replacing non-hyphenated parameters with the hyphenated equivalents at the same time.
Do those declarations accurately reflect our intent with regard to nonhyphenated parameter names? I believe that the answer is yes because:
aliases{}
table in
Module:Citation/CS1/Configuration so that the hyphenated multiword forms are listed first|chapter=
, |contribution=
, |entry=
, |article=
, |section=
); nonhyphenated variants of a hyphenated parameter name do not meet this criterium|chapter-url-access=
, |name-list-style=
, |script-title=
, |url-status=
, etc)|conferenceurl=
, |contributionurl=
, |laydate=
, |laysource=
, |layurl=
, |sectionurl=
, |seriesno=
, |timecaption=
, and |titlelink=
;
discussionIt is probably true that we have never actually declared an intent to deprecate and remove, but reading between the lines of our past and current actions, it seems highly likely to me that our intent is to deprecate and remove these parameter names.
Is it?
— Trappist the monk ( talk) 12:41, 30 November 2020 (UTC)
I also agree that this should have consensus but I don't see the scale of change as an important factor. We are talking about a formatting change that is transparent, with zero effect on semantics, in a very specialized area of Wikipedia. Imo, the change makes semantic meaning more obvious, a good thing. 68.173.79.202 ( talk) 13:42, 30 November 2020 (UTC)
|archiveurl=
, which often has a very long link without any breaks. Using |archive-url=
helps alleviate this. It also helps to distinguish "Archived from the original on..." as plain text, |archivedate=
, and |archive-date=
in plain-text searches. -
BRAINULATOR9 (
TALK) 15:07, 30 November 2020 (UTC){{
cn}}
still redirects to {{
citation needed}}
, but we even have bots and AWB/JWB scripts that canonicalize such shortcuts to the real, non-jibberish templates names, and various tools use the real names of the templates in the first place now. Also, various cite template parameters (mostly newer ones) with hyphens don't even have non-hyphenated aliases, and the sky did not fall; there is no editorial outcry about it, so obviously there's not a real editorial demand for them theruntogetherversions as necessary or desirable. —
SMcCandlish
☏
¢ 😼 21:23, 30 November 2020 (UTC)
|accessdate=
or |authorlink=
are still too frequently used in mainspace to deprecate them now, they are only "discouraged". Being "discouraged" means that the functionality is still supported and no error message shown, but that preparations are in the works to deprecate the parameter at some later point in time, so it is wise to reduce the parameter's use whereever possible so that less work needs to be done when it gets deprecated eventually. --
Matthiaspaul (
talk) 23:16, 4 December 2020 (UTC)|accessdate=
. The functionality of any deprecated parameter is retained through the deprecation period. At the end of the deprecation period, support for the parameter name will be withdrawn and the parameter name will no longer work. For |accessdate=
, an extended deprecation period may be desirable.|accessdate=
.
Nikkimaria (
talk) 13:12, 5 December 2020 (UTC)
The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intent.In that sentence,
all nonhyphenated parametersincludes
|accessdate=
because that parameter name is a concatenation of two words and is not hyphenated.to move the whole hand away from the letter keysto reach the hyphen. All it requires is a slight move of the right hand's little finger. -- Matthiaspaul ( talk) 23:16, 4 December 2020 (UTC)
|accessdate=
on a qwerty keyboard, the introductory pipe is both hands, 'accessdate' left hand only, and the assignement operator is right hand and the key is directly adjacent to the hyphen character.While I think we should be careful not to actually remove support for frequently used parameter variants until all uses in mainspace (and possibly also in other spaces) and all tools have been updated to use hyphenated parameter variants, I think, we should not skip a chance to transform citations automatically in order to make the transition as smooth as possible for everyone.
-- Matthiaspaul ( talk) 22:34, 30 November 2020 (UTC)
|authorlink=
etc. That raises two concerns - identify all those leaf templates that recognize these parameters and pass them on, and make sure they also recognize the hyphenated version before touching their customer articles. (There are other templates that transclude {{
cite book}} and can be fixed painlessly). Second, somewhat orthogonally, in order to make the change thoroughly it should be necessary to list all templates that through a call chain end up in cs1|2, and fix the articles that use them. None of this is urgent as long as the smashedtogether variants are supported, of course.
David Brooks (
talk) 04:19, 1 December 2020 (UTC)
|authorlink=
, as opposed to those that call {{
cite book}} with parameters passed through. More significantly, I guess {{
cite book}} was not a great example, because it is not likely that users will override the specific author. More likely cases: templates that wrap {{
cite encyclopedia}} or {{
cite journal}}. An example of the former is {{
New Cambridge History of Islam}}, which needs to recognize |author-link=
before fixing its callers. I only did a shallow dive to show this pattern is non-zero.
David Brooks (
talk) 14:38, 1 December 2020 (UTC)
{{
cite book}}
. Similar numbers for {{
cite news}}
, {{
cite journal}}
, and {{
citation}}
but not for {{
cite encyclopedia}}
(142).|authorlink=
? Did you mean |accessdate=
? It is those kinds of cs1|2 templates-within-templates that task 18 can fix. It will not be able to fix cases where the wrapper template accepts/requires |accessdate=
as an input:
|accessdate={{{accessdate|}}}
|authorlink=
, which I had looked at in a little detail, and just inferred that |accessdate=
could have similar characteristics. Thanks for the clarification.
David Brooks (
talk) 17:44, 3 December 2020 (UTC)|accessdate=
. I'm not at all sure how useful that will be.I think that the sense of the above discussion is that we are going to deprecate all nonhyphenated parameter names. As of the time I write this, Monkbot task 18 has made more than 125,000 edits. About half of those edits included the |accessdate=
→ |access-date=
fix. Those 125k edits were made to a broad variety of articles so likely are included on thousands of watchlists. There have been 22 reverts (0.0176%). Given all of this, I intend to restore the |accessdate=
→ |access-date=
fix to minimize the number of articles that Monkbot must revisit.
— Trappist the monk ( talk) 14:53, 3 December 2020 (UTC)
"old" templates. The task's activities are constrained to edits inside the canonical 27 cs1|2 templates and some of their most commonly used redirects. All of the canonical cs1|2 templates invoke Module:Citation/CS1 so all of them accept both
|accessdate=
and |access-date=
. Redirects, being redirects, simply take the round-about way to get to Module:Citation/CS1. Did I answer the question?|accessdate=
but presents it as access-date when calling {{
Schaff-Herzog cite}}. That redirects to {{
Cite Schaff-Herzog}}, which (stop me if you've heard this before) recognizes only |accessdate=
but presents it as access-date before passing to {{
Cite encyclopedia}}, which invokes CS1. So there's no way of successfully representing the parameter, and the same blocked path attends |authorlink=
. Sorry, just pointing out that while the 27 canonical templates are well-behaved, the rest of the ecosystem is a mess; there's no simple global fix. But I think everyone knew that.
David Brooks (
talk) 22:39, 3 December 2020 (UTC)
Trappist the monk, again: please start a well-advertised properly-run RfC. Editors have raised objections here and at your talk page, and even those supporting preferring hyphenated parameters have expressed concerns about aggressive bot-runs and removing functionality. A change impacting over a third of the articles on the site should have a stronger consensus behind it than what is seen here. Nikkimaria ( talk) 22:06, 8 December 2020 (UTC)
|accessdate=
should be kept supported. When they fall <25,000 through "passive" conversations (e.g. AWB genfixes), then we can have bots aggressively convert them.
Headbomb {
t ·
c ·
p ·
b} 17:28, 3 December 2020 (UTC)
|access-date=
the scale is millions of articles, it could take years - even bot speed could take months. Years might not be a problem through patience and dogged determination, but in the mean time users are still adding new templates (est 5-10 thousand a week) creating churn - users adding, bots removing, spinning wheels. So the idea if I understand is to deprecate with a red warning message, but that can't be rightly done until most of the existing stock is removed since in the past when millions of red warning messages suddenly appear the community revolts and demands the problem be fixed before red errors flood articles. --
Green
C 18:12, 3 December 2020 (UTC)"passive" [conversions]route by including
|accessdate=
→ |access-date=
in AWB genfixes but there was
pushback; understandable because there are so many instances of |accessdate=
that the genfix obfuscates the fixes that awb operators intend. I have since
suspended that genfix.|authorlink=
and |accessate=
makes global changes to them important enough to warrant special treatment. I think sometimes it makes sense to unbundle big very specific changes from less specific umbrella tasks that have mostly a bunch of rare and non-controversial changes. I'd like to see the bots approval group lean towards more specific, smaller tasks in the future as the discussion above shows how valuable focused discussion just on just |accessdate=
is. That said, I recognize the power of
WP:BE BOLD and don't want to discount the efforts of those who have the know-how and put in the work to keep Wikipedia evolving. For reasons related to both typing and reading source code, I have a preference for |accessdate=
over |access-date=
but since those editors actually working in this area are clearly against the un-hyphenated ones, I am fine with being neutral in regards to their deprecation or this bot making these changes.
Jason Quinn (
talk) 06:09, 4 December 2020 (UTC) (EDIT: Now oppose instead of neutral.
Jason Quinn (
talk) 02:08, 6 January 2021 (UTC))
we have never actually declared an intent to deprecate and remove. We know our intent from the actions that we take, the code and the documentation that we write, etc. This discussion is about declaring our intent.
"to-be-deprecated" means they are still valid. These parameters are valid now and will be valid during the deprecation period until support for them is withdrawn. Given that support will be withdrawn, it is necessary to convert those nonhyphenated names to their hyphenated equivalents before deprecation so that we minimize the quantity of Cite uses deprecated parameter
|accessdate=
and similar error messages. Too many of those cause torches and pitchforks uprisings. It is precisely the recognition of the widespread use of some of these parameters that makes Monkbot task 18 important because when it comes time to deprecate these parameters, there will be far fewer error messages to distress editors.Where are we on this? Everyone seems to have moved on and I'm not clear that all the outstanding questions are resolved.
The only RFC I'm aware of is the June 2014 resolution that only "All parameter names in Citation Style 1 templates" should accept hyphenated parameters; in addition, I think there is a consensus that documentation—narrative, examples, and TemplateData—should privilege the hyphenated versions. I believe both have been accomplished for the 26 or 23 (depending which list you consult, and I may have the wrong formal terms) canonical or "General use CS1 templates", but question 1: Is it still valid to use the nonhyphen versions in an example, if there are any such?
Remaining are the hundreds that wrap one of those templates, in particular those that recognize the parameters and pass them on (there are others that simply use a CS1 template internally to identify a single specific source). Are they included in the phrase "Citation Style 1 templates" in the RFC? If so, question 3: should there be a formal effort to identify those that don't recognize hyphens, and fix them? Some have been fixed recently but I think only because they were found using an incomplete search. Independently, question 4: should we make an effort to fix all the documentation, or will "fix them when you see them and have time" be OK for now, given that there is no agreement to formally deprecate the nonhyphen parameters? David Brooks ( talk) 16:50, 14 December 2020 (UTC)
|accessdate=
. Not all of them are CS1 wrapper templates. It will probably be easiest to deal with them as follows: (1) Let Monkbot complete its run through affected articles, (2) put unhyphenated parameters in a maintenance category, which will allow us to catch templates, pages in other namespaces, and edge cases that the bot was unable to process, (3) process the pages in the maintenance category using a combination of bots and manual gnome work, (4) formally deprecate unhyphenated parameters in the module code, using the deprecated parameter category, and finally (5) remove support for the deprecated parameters. This process will probably take a year or more. –
Jonesey95 (
talk) 17:36, 14 December 2020 (UTC)
|accessdate=
(etc) recognizes |access-date=
. I guess the hunt through those that use CS1 could be automated pretty easily.
David Brooks (
talk) 22:40, 14 December 2020 (UTC)|accessdate=
which is so commonly used. A lot of editors prefer it, perhaps even most? What was the ratio of with and without the hyphen before Monkbot started "fixing" it?|accessdate=
without the hyphen is ever deprecated. It should remain a valid alias. Plenty of users still create articles with citations that use the unhyphenated form, and if the goal is to inflict big ugly red error messages or just not display the date at all upon use of the unhyphenated form, I can't see how that's going to go down well or how it's even an appropriate remedy. There are claims this is for clarity, but who has ever said they were confused about what the unhyphenated form of |accessdate=
means? Cosmetic, spam-like bot edits is all this is currently amounting to. I don't see the point of these edits. There will never be complete conformity on any issue like this on Wikipedia, and we should stop trying to force people to adapt when the old form has endured for years without any hassle.
Ss
112 13:42, 15 December 2020 (UTC)citation["cite book"]["access date"] = "2020-12-16"
--
Green
C 15:33, 16 December 2020 (UTC)TL/DRis no excuse for childishly spamming Monkbot to stop. It also sounds like the pot calling the kettle black/ psychological projection.
WP:IDHT~ Tom.Reding ( talk ⋅ dgaf) 14:59, 30 December 2020 (UTC)
|accessdate=
will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form. When that deprecation occurs, citation templates that the the bot touched will not show error messages. But, citation templates that the
bot touched and were
subsequently reverted like this one from
And a Little Child Shall Lead Them will show an error message:
{{cite web |url=http://www.silentera.com/PSFL/data/A/AndALittleChildShallLe1909.html |title=And a Little Child Shall Lead Them |accessdate=February 13, 2015 |work=Silent Era}}
|accessdate=
(
help) – error message is a mockup|accessdate=
is deprecated.Sometime, probably within the coming year, |accessdate=
will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form
. Where have you established consensus for that? It certainly hasn't been demonstrated in this thread.
Nikkimaria (
talk) 19:01, 30 December 2020 (UTC)I saw in the archive that this has been touched on in the past. I would like to see if there is a possibility of adding |illustrator-last= and |illustrator-first= to the template cite book. An example where I see the need is for John Eyre (British artist), who illustrated classics such as Pickwick Papers, The Compleat Angler, and Rip Van Winkle. These were classics, even in his day. Putting him as |author-last2=, etc. makes it appear that he helped write the books, when his actual role was to make the stories more compelling with art. Considering all the illustrated books in the world, I think the template should inlude illustrator. Am I alone? Jacqke ( talk) 14:12, 19 December 2020 (UTC)
|contributor-last=Eyre
|contributor-first=John
|contribution=Illustrator
|contributor-link=John Eyre (British artist)
-- there are many contributor roles which come to mind: illustrator, cover artist, cover designer, forward, introduction, narrator, photographer, preface, translator. If there are multiple contributors, not sure how that works of contribution and contributor-link support > one. --
Green
C 14:36, 19 December 2020 (UTC)|contribution=
is an alias of |chapter=
and is rendered in the citation in the same way that a chapter is rendered and is included in the citation's metadata as &rft.atitle=Illustrator
. Do not corrupt the citation's metadata.
{{cite book|title=Pickwick Papers|author=Charles Dickens|contributor-last=Eyre|contributor-first=John|contribution=Illustrator|contributor-link=John Eyre (British artist)}}
'"`UNIQ--templatestyles-00000040-QINU`"'<cite id="CITEREFEyre" class="citation book cs1">[[John Eyre (British artist)|Eyre, John]]. "Illustrator". ''Pickwick Papers''. By Charles Dickens.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Illustrator&rft.btitle=Pickwick+Papers&rft.aulast=Eyre&rft.aufirst=John&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+74" class="Z3988"></span>
|others=
is where other contributors go so |others=Illustrations by [[John Eyre (British artist)|John Eyre]]
{{cite book |title=Pickwick Papers |author=Charles Dickens |others=Illustrations by [[John Eyre (British artist)|John Eyre]]}}
|contribution=
together with |contributor-last/first=
, which works quite good for as long as only one type of contribution needs to be mentioned and it is okay to list it in front of the citation (and include them in the metadata).|others=
requiring manual free-style formatting. This latter type should be expanded to allow to specify multiple names by their last and first names and their roles to let the template format the output according to our preferences. In the other thread I gave examples how to possibly combine this with the |contributor-last/first=
parameters utilizing a new |contributor-role=
parameter. Alternatively, |others=
could be expanded to the same effect (|other-last/first=
and |other-role=
), but the parameter name is not particularly meaningful.I propose to update cs1|2 module suite over the weekend 9–10 January 2021. Here are the changes:
|editors=
withdrawn;
discussion|ignore-isbn-error=
, |lastauthoramp=
, |last-author-amp=
withdrawn;
discussion|nocat=
withdrawn;
discussion|edition=
parameter;
discussion|page(s)=
, also test |quote-page(s)=
;|quote-pages=
in analogy to |pages=
;
discussion
|volume=
evaluation accordingly for all cite types;|quote-page(s)=
to metadata if none of the other page-related parameters was used;
discussionModule:Citation/CS1/Configuration:
|editors=
withdrawn;|authormask=
, |displayauthors=
, |editorlink=
, |ignore-isbn-error=
, |subjectlink=
, |authormask#=
, |author#mask=
, |editorlink#=
, |editor#link=
, |subjectlink#=
, |subject#link=
, |lastauthoramp=
, |last-author-amp=
withdrawn;
discussion|seriesnumber=
, |event-format=
, |event-url=
, and |eventurl=
withdrawn;
discussion|nocat=
withdrawn;
to "et al", "edition", "section"', "sections" messages to avoid wrapping;
discussionModule:Citation/CS1/Whitelist:
|editors=
withdrawn;|authormask=
, |displayauthors=
, |editorlink=
, |ignore-isbn-error=
, |subjectlink=
, |authormask#=
, |author#mask=
, |editorlink#=
, |editor#link=
, |subjectlink#=
, |subject#link=
, |lastauthoramp=
, |last-author-amp=
withdrawn;|seriesnumber=
, |event-format=
, |event-url=
, and |eventurl=
withdrawn;|nocat=
withdrawn;|conferenceurl=
, |contributionurl=
, |laydate=
, |laysource=
, |layurl=
, |seriesno=
, |sectionurl=
, |timecaption=
, |titlelink=
deprecated;
discussionModule:Citation/CS1/Identifiers:
Module:Citation/CS1/Utilities:
make_wikilink()
where link and label are the same;
discussionModule:Citation/CS1/Suggestions:
|editors=
;|displayauthors=
, |ignore-isbn-error=
, |last-author-amp=
, |lastauthoramp=
, |authormask=
, |authormask#=
, |author#mask=
, |editorlink=
, |editorlink#=
, |editor#link=
, |subjectlink=
, |subjectlink#=
, |subject#link=
;|ASIN-TLD=
, |registration=
, |subscription=
;|nocat=
;— Trappist the monk ( talk) 17:32, 3 January 2021 (UTC)
err_extra_text_edition
and err_extra_text_pages
have hidden = true
. Why? Copy/pasta oversite?The citation indexing in Mortimer Taube is rather poor, which is highly ironic. I'm trying to improve this, but ran into a problem. How do I list multiple editors in an encyclopedia? editor_first1 et all does not appear to work and no alternative is listed on the template help page. Maury Markowitz ( talk) 13:51, 7 January 2021 (UTC)
|editor-first=
, |editor-firstn=
, |editor-last=
, |editor-lastn=
, |editor=
, and |editorn=
; underscore-separated parameter names are not supported. See
Template:Cite encyclopedia § EditorsI have been working on the maintenance backlog for a wikiproject and a significant number of the issues are "CS1 errors: missing periodical". In a majority of cases, the fix is obvious, e.g. use cite book instead, or add the journal name. However, a minority are coming from "cite document" which is basically as far as I can see a wrapper to cite journal. The problem with this is that it is not obvious to editors that if you use a template called "document" you need to add the journal field. Some examples of its use for generic documents can be found on the A30 road page. The talk page for this template states "This template is used when a bot needs to switch from the Citation format to the Cite xxx format, but cannot deduce whether the source is a book, newspaper or other document" but if the source is a book or a newspaper, then there won't be a journal field either, so this is a problem for that use case as well. Can anyone suggest a way forward here please?-- NHSavage ( talk) 09:22, 9 January 2021 (UTC)
The documentation at
Help:Citation Style 1, and for the individual CS1 templates,
says that |url-access=limited
means that, besides registering on some website, there are other constraints (such as a cap on daily views) to freely access this source
, while the tooltip on the lock icon that |url-access=limited
produces says Free access subject to limited trial, subscription normally required
.
These descriptions of the meaning of |url-access=limited
don't seem equivalent to me.
For example, having a free account on Archive.org lets one "borrow" a book, but (for many books) one must wait to do so until there is a copy of the book available (not borrowed by someone else).
If such a book is used as a source, I would understand this simulation of a physical library to create an other constraint
besides registration to freely access this source
, so, according to the documentation, |url-access=limited
applies.
On the other hand, the Archive.org account is not merely a free trial
, and (as far as I'm aware) there is no "full subscription
" one could buy to bypass the constraint, so, according to the tooltip, |url-access=limited
does not apply.
Could the intent of |url-access=limited
be clarified?
Thank you, — 2d37 ( talk) 13:53, 6 January 2021 (UTC)
Free access limited eg. trial, subscription, registration, or cap on views.The "eg." (or "for example") means these are not a complete set of reasons but are typical. -- Green C 14:01, 6 January 2021 (UTC)
viewcap limitnecessarily entails a
trial, despite that it does so in what I imagine is an archetypal example of such a limit, a newspaper's website's allowing a user to read some limited number of articles per month for free and offering a paid subscription for full access. Literally, I suppose the case of books at Archive.org involves a
cap on views(not limiting a user to viewing some number of articles but limiting a book to being viewed by some number of users), but there's no trial in that case; as far as I know, one can't buy unlimited access to the Archive's books. — 2d37 ( talk) 10:12, 8 January 2021 (UTC)
|url-access=registration
, which gives the true but incomplete description "Free registration required", and the second two use |url-access=limited
, despite that the tooltip produced thereby speaks inapplicably of trials and subscriptions. I realize that my sample size here is terribly small; if it's interesting, perhaps someone familiar with running bulk queries against Wikipedia could get better data. —
2d37 (
talk) 10:59, 8 January 2021 (UTC)
|url-access=
parameters appear to have been added to all four of those articles by
InternetArchiveBot and/or
GreenC bot:
registration
:
limited
:
|url-access=
but when IA bot is operating on its own, |url-access=
gets the correct value. It would seem to me that you should raise this issue with the bot operators and not here.|url-access=
. If there were necessarily an implicit complaintin my original post, it was that the documentation for
|url-access=limited
seems inconsistent with the tooltip that it produces. —
2d37 (
talk) 09:18, 9 January 2021 (UTC)to patrons with print disabilities. Perhaps offtopically, I wonder whether, given that restriction, Google Books previews (where available) should be preferred for those citations' URLs. — 2d37 ( talk) 09:38, 9 January 2021 (UTC)
|url=
is made less significant because of how the ISBN links to many different BookSources. —
2d37 (
talk) 08:06, 10 January 2021 (UTC)This is a follow-up to Help_talk:Citation_Style_1/Archive_73#ISBN_line_breaks, which got archived before consensus became fully clear. I continue to believe that it would be beneficial to wrap ISBNs in {{ nowrap}}, which would prevent line breaks like the one in the screenshot (that appears for Chrome; issue does not seem to manifest on Firefox). Because ISBNs are quite short, I do not see any significant downside; one would have to have an insanely narrow screen width to run into any issues. Can we decide if we're ready to implement? (Please note that the space between "ISBN" and the ISBN itself is already non-breaking; it is just the hyphens within the ISBN that are at issue.) {{u| Sdkb}} talk 14:49, 9 January 2021 (UTC)
.citation a[href*="BookSources"] { white-space: nowrap }
. --
Izno (
talk) 15:42, 9 January 2021 (UTC)
Furigana#References has a reference which contains {{ ruby}}, which is an instance of Ruby character content. I can replace the template (which uses templatestyles) with the associated HTML. Is that reasonable for metadata et al? -- Izno ( talk) 19:33, 9 January 2021 (UTC)
<announcer voice>the-prefect-solution-for-all-of-your-citation-needs</announcer voice>
. Perhaps the best solution is to hand-write those citations; their use in that article appears to be as examples of Furigana in use.Perhaps the best solution is to hand-write those citations
Is that reasonable for metadata et al?, for which I would have expected "yes, go ahead and use the raw HTML and the template will be fine" or "no, seek another solution, such as removing the ruby annotation or rewrite it". You will find no answer on that specific question in your responses. :) -- Izno ( talk) 16:56, 11 January 2021 (UTC)
Perhaps the best solution is to hand-write those citationsis the answer to the specific question because implicit in
hand-writeis:
no, seek another solution.
|title=((...))
as well - similar to what is proposed in
Help_talk:Citation_Style_1#Modifier_being_recognized_as_zero_width_joiner.These 50 pages have manual invocations of CS1 categories that need to be converted from "Category" to ":Category" inside their brackets. If anyone has a quick script that can fix them, go for it. I fixed a half-dozen of them, but it's tedious. – Jonesey95 ( talk) 23:37, 9 January 2021 (UTC)
X. JSTOR 10.14321/j.ctt1pd2k5h. links to https://www.jstor.org/stable/10.14321%2Fj.ctt1pd2k5h and not https://www.jstor.org/stable/10.14321/j.ctt1pd2k5h and escaping the slash breaks the link. AManWithNoPlan ( talk) 13:37, 10 January 2021 (UTC)
false
in the live code while devising a better solution for the next update. Trappist, can you do this, please? Thanks. --
Matthiaspaul (
talk) 15:46, 10 January 2021 (UTC)
{{cite book |title=Title |jstor=141 294}}
{{
cite book}}
: Check |jstor=
value (
help){{cite book |title=Title |jstor=141dfdfdf29 4}}
{{
cite book}}
: Check |jstor=
value (
help)Straw poll: make publication-date and publication-place full synonyms... to date and place/location respectively. Publication-place and location are used only some 600 times in conjunction (see Category:CS1 location test). I anticipate publication-date and date have similar numbers (the first several in this search look like they are being used as synonyms, and at least one or two misuses of publication-date). Anything so little used does not need full support in the module. -- Izno ( talk) 02:43, 11 January 2021 (UTC)
|publication-place=
and |location=
/|place=
are not aliases, and shouldn't be treated as such. Publication place and written-at location are two independent properties of a source, and while it is true that they are seldomly both relevant and given at the same time (hence the low numbers), sometimes they are relevant and it would be counter-productive for readers as well as for machine-readability to not distinguish between them any more. It would weaken the quality of information in references. While the parameter name |publication-place=
is perfectly descriptive already, the parameter name |location=
, unfortunately, is not. Therefore, I propose a semantically more descriptive name for it like |written-at-place=
, |written-place=
, |writing-place=
, |write-place=
, |creation-place=
or something else along that line following our modern naming conventions of adding more descriptive parts of parameter names on the left side of a parameter. Afterwards, the |location=
parameter could either be left as it is or be faded out slowly, probably a process that would take several years to finish as each usage would have to be checked manually and the parameter replaced by either the written-at or the publication place parameter.|publication-date=
and |date=
, we should analyze what other typical types of dates are referred to in various types of references and add dedicated and descriptive parameter names for them as well to improve machine-readability and allow for more meaningful and consistent output. At present, we have to put everything else into the |orig-date=
parameter, which has no date format checking and cannot contribute to the metadata output. Using more descriptive parameter names would improve the situation.You are incorrect and continue to be incorrect. They are only not aliases when they are used together, and that situation has a total of 600 uses. Total. Out of 5 million pages using this template. We do not and need not support the distinction.|publication-place=
and|location=
/|place=
are not aliases, and shouldn't be treated as such.
Publication place and written-at location are two independent properties of a sourceYeah, that is true but irrelevant. Citation templates are not repositories for all possible
properties of a source. For cs1|2,
machine-readabilityis constrained to what COinS can support so a cs1|2 template with both of
|location=
and |publication-place=
and both of |date=
and |publication-date=
emits metadata from |publication-place=
and |date=
; the other two are ignored.|date=
and/or |place=
are also present. Be mindful of the fact that certain sources such as films, etc. may be classified by work date (date of production) by default, and would be much harder to find by publication date (date of |date=
and |publication-date=
are paired.|publication-place=
, |place=
, and |publication-date=
. These simple searches give some idea of how often these parameters are used when compared to |location=
and |date=
:
{{
citation needed}}
which also takes |date=
)|location=
and |date=
. Deprecate and remove the others.|place=
and |publication-place=
as synonyms violates the
Principle of least astonishment. Either allow both or deprectae |date=
, |location=
and |place=
.
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 15:24, 11 January 2021 (UTC)
What is the proper way to mark up a {{ cite conference}} to specify the dates of the conference, the location of the conference, the time of a session and the number of a session, e.g.,
Dual Address Space & Linkage-Stack Architecture Dan Greiner dgreiner@us.ibm.com z/Server Architecture SHARE 118 in Atlanta Session 10446, 12 March 2012, 4:30 pm
I can fudge some like this, [1] but Atlanta would be incorrectly indexed as the publication place and it doesn't show the session time. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 03:33, 09 January 2021 (UTC)
|session=
would be apt. I am not sure this is the case now.
98.0.246.242 (
talk) 04:33, 12 January 2021 (UTC)References
|id=
.
66.65.114.61 (
talk) 19:48, 12 January 2021 (UTC)In
List of most-liked TikTok videos, ref 15 (currently) has the error zero width joiner character in |title= at position 46
. The issue is with the characters 🤷♂️🔥
- removing the modifier character solves the error but leads to 🤷🔥
- different text. This is a very minor issue but a bit annoying.
Elliot321 (
talk |
contribs) 07:52, 9 January 2021 (UTC)
|title=((...))
or |script-title=
?has_invisible_chars()
to detect the ((...))
markup wrapping the entire parameter value when a zwj character is found (we already look for and allow zwj characters in Indic-script text because zwj is used as a character-modifier in those scripts). We must not abandon the invisible-character check when we detect the ((...))
markup because we don't want to mask errors caused by stripmarkers from TemplateStyles or inappropriate wiki tags and the like.|title=((...))
is a better (lower footprint, less maintenance and more flexible) solution at present.Extended content
|
---|
U+200D U+1F308 U+200D U+1F33E U+200D U+1F373 U+200D U+1F393 U+200D U+1F3A4 U+200D U+1F3A8 U+200D U+1F3EB U+200D U+1F3ED U+200D U+1F466 U+200D U+1F467 U+200D U+1F468 U+200D U+1F469 U+200D U+1F48B U+200D U+1F4BB U+200D U+1F4BC U+200D U+1F527 U+200D U+1F52C U+200D U+1F5E8 U+200D U+1F680 U+200D U+1F692 U+200D U+1F91D U+200D U+1F9AF U+200D U+1F9B0 U+200D U+1F9B1 U+200D U+1F9B2 U+200D U+1F9B3 U+200D U+1F9BA U+200D U+1F9BC U+200D U+1F9BD U+200D U+1F9D1 U+200D U+2620 U+200D U+2640 U+200D U+2642 U+200D U+2695 U+200D U+2696 U+200D U+2708 U+200D U+2764 |
Wikitext | {{cite web
|
---|---|
Live | "its official: we are the CEO's of this sound🤷♂️🔥 @justjonathan14". TikTok. Archived from the original on 29 October 2020. Retrieved 14 September 2020. |
Sandbox | "its official: we are the CEO's of this sound🤷♂️🔥 @justjonathan14". TikTok. Archived from the original on 29 October 2020. Retrieved 14 September 2020. |
Seems to work. It did for all of the emoji zwj errors in cs1|2 templates listed in
Category:CS1 errors: invisible characters. {{
cite tweet/sandbox}}
uses the live version of {{
cite web}}
so I haven't tested the code against that template.
— Trappist the monk ( talk) 17:08, 12 January 2021 (UTC)
IBM System/360 cites a section
[1] within a journal article with this
<ref>{{cite journal
| author = A. Padegs
| title = System/370 Extended Architecture: design considerations | journal = IBM Journal of Research & Development
| volume = 27
| issue = 3
| pages = 198–205
| date = May 1983
| publisher = IBM
| doi = 10.1147/rd.273.0198
}} – a subsection titled "31-bit addressing" begins on page 201.</ref>
markup. The {{
cite journal}} template does not support |section=
or |section-url=
, nor does it support nested page ranges.
What is the proper markup for doing this? Shmuel (Seymour J.) Metz Username:Chatul ( talk) 13:24, 13 December 2020 (UTC)
References
|at=§31-bit addressing p. 201
|span-page(s)=
or |range-page(s)=
and |cite-page(s)=
to distinguish between them, and we came up with two possible notations how to display them in a citation. However, for as long as these parameters are not implemented, you could use something like |pages=198–205 [201]
to manually specify a page range of 198–205 with a relevant page 201 in there.|at=
to be given in addition to |page=
/|pages=
, in the same way that {{
harv}}
and friends allow |loc=
together with |p=
/|pp=
. (And then to make |at=
and |loc=
aliases for each other – it's always hard to remember which goes with which template.)
Kanguole 16:09, 17 December 2020 (UTC)
|loc=
in {{
harv}} is used for primary source locations as well as in-source (secondary) locations, so I am not sure if the aliasing would be a good fit.
98.0.246.242 (
talk) 02:21, 20 December 2020 (UTC)
Monkbot doesn't like the combination. Why, @ Trappist the monk:? 98.0.246.242 ( talk) 03:19, 14 January 2021 (UTC)
10.51355 is a working prefix. Headbomb { t · c · p · b} 04:35, 14 January 2021 (UTC)
Wikitext | {{cite journal
|
---|---|
Live | Berube, David; Eubanks-Turner, Christina; Mosteig, Edward; Zachariah, Thomas (2018-07-01). "A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University". Journal of Research in STEM Education. 4 (1): 13–22. doi: 10.51355/jstem.2018.32. ISSN 2149-8504. |
Sandbox | Berube, David; Eubanks-Turner, Christina; Mosteig, Edward; Zachariah, Thomas (2018-07-01). "A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University". Journal of Research in STEM Education. 4 (1): 13–22. doi: 10.51355/jstem.2018.32. ISSN 2149-8504. |
Limit is 10.59999.
— Trappist the monk ( talk) 13:44, 14 January 2021 (UTC)
Should the new CS1 error categories (e.g. Category:CS1 errors: extra text: edition, Category:CS1 errors: extra text: pages, Category:CS1 errors: redundant parameter, Category:CS1 errors: URL) have talk pages that redirect here? Thanks! GoingBatty ( talk) 05:02, 11 January 2021 (UTC)
Following up on
Help_talk:Citation_Style_1/Archive_72#last-author-amp=, support for the |name-list-format=
alias of the |name-list-style=
parameter has now been removed in the sandbox. Use of |name-list-format=
and the former |last-author-amp=
parameter has been completely replaced by |name-list-style=
in mainspace.
--
Matthiaspaul (
talk) 05:34, 16 January 2021 (UTC)
In the sandbox I have unhidden the empty unknown parameter error message. At this writing, Category:CS1 errors: empty unknown parameters has 324 entries, most of which are not in article space. I still think that there are various archives logs etc that should not be in error categories. Someone tell me again: Why it is that we don't automatically disable categorization of archives and logs for things in Wikipedia and other name spaces?
— Trappist the monk ( talk) 14:11, 30 December 2020 (UTC)
|no-cat=
parameter, but got no answer.|no-cat=
parameter (renamed to something more semantically meaningful or merged into a more generic |debug=
parameter) could be used to enable it, likewise to disable categorization in mainspace.((...))
), we probably won't need a facility to disable categorization in mainspace at all any more.uncategorized_namespaces{}
. You appear to be saying that we should be categorizing talk pages, archives, sandboxes, logs. I can see no justification for categorizing pages that are archives, or logs, or sandboxen (these kinds of pages are 'dead') nor can I see a reason to categorize talk pages. To get archived and logged pages out of the various error categories requires that editors visit each cs1|2 template with an error and manually add
|no-tracking=yes
. As new error detection is created so too, we create new 'dead' entries in the associated categories so it's back to the 'dead' pages to add yet more |no-tracking=yes
. That is mind numbing drudgework but, at present, necessary to get those 'dead' pages out of the category. Why is it that you think that these 'dead' pages should be categorized? How does categorizing 'dead' pages benefit us?uncategorized_subpages = {'/[Ss]andbox', '/[Tt]estcases', '/[^/]*[Ll]og', '/[Aa]rchive'}
Currently, if you do |access=
CS1 templates suggest |access-date=
. However, it probably should include |url-access=
which (at least in my case) was what I was trying to get to. –
MJL
‐Talk‐
☖ 18:20, 1 January 2021 (UTC)
|url-access=
per
Help:CS1 errors#param_access_requires_param.
–
MJL
‐Talk‐
☖ 18:24, 1 January 2021 (UTC)
|access-date=
not because someone could simply assume |access=
to be the correct name of the |access-date=
parameter. We could strengthen the rule to no longer trigger on variations of access without some form of date following, but given that we also have rules to catch some parameter names very similar to access as used in foreign language Wikipedias for |access-date=
I don't think this would be an improvement.Fixed two bugs in the error message display for parameters unsupported by some templates (like |publisher=
with {{
cite bioRxiv}}, {{
cite citeseerx}} and {{
cite ssrn}}) if the given parameter was in the list of parameter suggestions. The first bug caused the template to still suggest a parameter even if not supported by a particular template. The second bug caused the template to display the name of the suggested parameter rather than the given parameter.
Valid parameter |publisher=
given: (supported by {{
cite book}} but not by {{
cite ssrn}})
Wikitext | {{cite book
|
---|---|
Live | Title. Publisher. |
Sandbox | Title. Publisher. |
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |publisher= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |publisher= ignored (
help)
|
Bogus parameter |xyz=
given:
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Unknown parameter |xyz= ignored (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |xyz= ignored (
help)
|
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |xyz= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |xyz= ignored (
help)
|
Misspelling |pulbisher=
given instead of parameter |publisher=
: (example for pattern matching rule)
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Unknown parameter |pulbisher= ignored (|publisher= suggested) (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |pulbisher= ignored (|publisher= suggested) (
help)
|
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pulbisher= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pulbisher= ignored (
help)
|
Old parameter |pub=
given instead of parameter |publisher=
: (example for specific matching of rule)
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Unknown parameter |pub= ignored (|publisher= suggested) (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |pub= ignored (|publisher= suggested) (
help)
|
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pub= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pub= ignored (
help)
|
-- Matthiaspaul ( talk) 23:45, 17 January 2021 (UTC)
Why is url-access=free not a permitted parameter? I'm thinking of citing something like this: Kramer, Hilton (June 26, 1977).
"Black Art or Merely Social History?".
The New York Times. p. D25.{{
cite news}}
: CS1 maint: url-status (
link) Reprinted as Kramer, Hilton (June 26, 1977).
"A show about black artists, not an anthology of achievements".
St. Louis Post-Dispatch. p. 29. Retrieved 2021-01-19.{{
cite news}}
: CS1 maint: url-status (
link) The review was originally published in the NYT (and a review by a NYT critic is obviously more significant than a review by a St. Louis Post-Dispatch critic) so the citation should refer to the review's original publication in the NYT. If a reader wants to verify the reference, though, it will probably be easier to visit the newspapers.com clipping of the St. Louis Post-Dispatch reprint of the review. I'd like to show the contrast between paywalled/free so readers immediately know to click on the second one. Is the idea just that not having an icon indicates it is free? I know that I could use
but if I just stick it after {{
cite web}} it doesn't put the icon in a parallel position. Thanks,
Calliopejen1 (
talk) 19:02, 19 January 2021 (UTC)
|url-access=subscription
). cs1|2 does not highlight the norm. See
Help:Citation Style 1 § Registration or subscription required.|via=Newspapers.com
because the source is delivered to our readers from Newspapers.com not from St. Louis Post-Dispatch. It's |page=5B
, the page number actually printed on the page. For both cites, unless you are going to provide links to archives, delete |url-status=live
, |archive-url=
, and |archive-date=
; the former has no meaning without the latter two (with values).A couple of additional questions for a related citation: Ghent, Henri (October 10, 1976). "LACMA Takes a Giant Step for Black Heritage". The Los Angeles Times. pp. 1, 64-65 (Calendar section) – via Newspapers.com. Article continues here and here. ---- Is there some better way to indicate which section the article appeared in? (If they're just letters it would be something like A1, A64-A65, but Calendar-1, Calendar-64-65 or similar is pretty horrible.) Also, is there recommended way of handling this situation where there are multiple URLs for the multiple pages of the newspaper article? Thanks! Calliopejen1 ( talk) 21:15, 19 January 2021 (UTC)
{{cite news |last=Ghent |first=Henri |date=October 10, 1976 |title=LACMA Takes a Giant Step for Black Heritage |pages=1, [https://www.newspapers.com/clip/68027414/ 64], [https://www.newspapers.com/clip/68027363/ 65] |work=Los Angeles Times Calendar |url=https://www.newspapers.com/clip/68026751/black-american-art-crossing-the/ |via=[[Newspapers.com]]}}
{{cite news |last=Ghent |first=Henri |date=October 10, 1976 |title=LACMA Takes a Giant Step for Black Heritage |pages=1, [https://www.newspapers.com/clip/68027414/ 64], [https://www.newspapers.com/clip/68027363/ 65] |work=Los Angeles Times |department=Calendar |url=https://www.newspapers.com/clip/68026751/black-american-art-crossing-the/ |via=[[Newspapers.com]]}}
Greetings, everyone. The line "language=English" does not return anything in a citation. Perhaps because it's considered the obviously default language in the Engligh Wikipedia. However, there are cases (like this one) where the source's text carries only the title in a foreign language while the text is in English. I'd suggest that this information should be allowed to appear in the citation. Whenever redundancy appears, i.e. someone puts that up for a typical English-language source, we can simply delete it. - The Gnome ( talk) 11:39, 22 January 2021 (UTC)
|trans-title=
. You could also note that the body is a translation if the original was first published in French. If the report was published in both languages simultaneously there's no need to indicate a foreign language original.
65.204.10.231 (
talk) 13:16, 22 January 2021 (UTC)|language=en, fr
is probably the correct form which will render as: (in English and French).Whenever redundancy appears, i.e. someone puts that [|language=
] up for a typical English-language source, we can simply delete it.
— I seem to recall that it's desired to have |language=
given for all citations because it helps the other Wikipedias. —
2d37 (
talk) 01:59, 23 January 2021 (UTC)My understanding is that the DOI parameter supports the addition of scite_ data (info from https://scite.ai/ ), but this addition is creating a display problem where "SCITE" is expanded to a huge extent, obscuring references which invoke the addin. Is this a known problem? --User:Ceyockey ( talk to me) 02:12, 20 January 2021 (UTC)
I see that in |url-status=
there is a value for "unfit". I'm looking at a reference that is behind a paywall (so, useless to most), but for which there is an archive at archive.org. Should I use unfit for this purpose, or is there a better option, like creating a "paywall" value?
Cyphoidbomb (
talk) 00:12, 24 January 2021 (UTC)
|url-access=
. --
Izno (
talk) 00:58, 24 January 2021 (UTC)
{{cite book |last1=Dexter |first1=Franklin Bowditch |title=Biographical sketches of the graduates of Yale College: with annals of the college history |date=1911 |publisher=Holt |location=New York |pages=41-45 |volume=5 |number=1 |url=https://archive.org/details/biographicalsket51dext |oclc=1041576339 |language=en}}
This is actually part 1 of a two-part volume. |number=
does not do anything in cite book, so how would I reflect this fact? –
MJL
‐Talk‐
☖ 19:37, 26 January 2021 (UTC)
{{cite book |last1=Dexter |first1=Franklin Bowditch |title=Biographical sketches of the graduates of Yale College: with annals of the college history |date=1911 |publisher=Holt |location=New York |pages=41-45 |volume=5, part 1 |number=1 |url=https://archive.org/details/biographicalsket51dext |oclc=1041576339 |language=en}}
|doi=10.1126/science. 1140516
encodes as
https://doi.org/10.1126/science.+1140516 instead of as
https://doi.org/10.1126/science.%201140516 Note that this DOI has a space in it!
AManWithNoPlan (
talk) 19:08, 27 January 2021 (UTC)
mw.uri.encode ('10.1126/science. 1140516')
) for a very long time. If we are to believe the Scribunto documentation, we can change to mw.uri.encode ('10.1126/science. 1140516', 'PATH')
which differs only from the default by encoding space characters as %20
instead of +
. I am not inclined to relax the 'no spaces' requirement just because this one doi uses a space character. I've tweaked
Module:Citation/CS1/Identifiers/sandbox. Here, the doi works:Wikitext | {{cite book
|
---|---|
Live | Title.
doi:
10.1126/science. 1140516. {{
cite book}} : Check |doi= value (
help)
|
Sandbox | Title.
doi:
10.1126/science. 1140516. {{
cite book}} : Check |doi= value (
help)
|
Wikitext | {{cite book
|
---|---|
Live | Title.
doi:
10.1126/science. 1140516.{{
cite book}} : CS1 maint: ignored DOI errors (
link)
|
Sandbox | Title.
doi:
10.1126/science. 1140516.{{
cite book}} : CS1 maint: ignored DOI errors (
link)
|
Hello, at the Arecibo Observatory article there's a valid PMID of 33214727 despite the red ink saying 'Check |pmid= value'. I presume that the range of valid PMID numbers needs extending- please can someone fix this? TIA, Yadsalohcin ( talk) 08:20, 25 November 2020 (UTC)
It might be a good idea to figure out the growth rate of these PMID numbers. At the time or writing, the "latest literature" section on https://pubmed.ncbi.nlm.nih.gov/ gives 33338219, already 17000 more than the november 19 arecibo article. This growth rate feels ridiculous, since it would imply that PMID would've gone from 0 to 33500000 in less than 3 years. Someone got to analyze the XML dump. -- Artoria 2e5 🌉 21:33, 19 December 2020 (UTC)
Hello, https://pubmed.ncbi.nlm.nih.gov/33511486 is over 33500000. The upper limit needs to be increased. Thanks. — Bruce1ee talk 08:37, 30 January 2021 (UTC)
I have added a maintenance message in the sandbox when |ref=
is the default CITEREF generated:
Wikitext | {{cite book
|
---|---|
Live | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
Sandbox | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
Wikitext | {{cite book
|
---|---|
Live | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
Sandbox | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
The ref parameter is actually {{ sfnref}} just to prove it works. I don't really understand why author jumped to the end in the displayed wikitext. |
This can be used to clean up wikitext, and I imagine when the great deletion of |ref=harv
is over can be merged with that category, either as maintenance or error (basically, "stop trying so hard" :).
I have also made a dedicated Module:Citation/CS1/testcases/anchor where other tests regarding the anchor can be found and regressions indicated. I found a couple unexpected cases down the way in test_ref, indicated on the module page-proper.
(I plan to add maybe one or two more cases/assertions to ensure that display names don't impact the CITEREF generation, which I was thinking about the other day.)
I also did some code cleaning related to Ref and the CS1/2 style setting code, since by the time the style code was being reached, the module was setting |ref=
to harv if it was not yet set. --
Izno (
talk) 07:17, 30 January 2021 (UTC)
|ref=
parameter as people would have to start guessing the actual anchor name again.|ref=CITEREF...
.This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 70 | ← | Archive 72 | Archive 73 | Archive 74 | Archive 75 | Archive 76 | → | Archive 80 |
In
{{
cite journal}}
: Check |doi=
value (
help)The DOI is clearly invalid. The format is 10.####/ or 10.#####/ and nothing else. Headbomb { t · c · p · b} 05:18, 4 January 2021 (UTC)
If a book is available online, we enter |url=
, and if this URL is dead we can enter |archive-url=
. But there is no such equivalent for chapter-specific links, i.e. |chapterurl=
. Is there is specific reason for that? (for a specific example, I could've just used such an option
here.) --
bender235 (
talk) 17:25, 2 January 2021 (UTC)
{{cite book |first=Michael P. |last=Barnett |authorlink=Michael P. Barnett |chapter=Symbolic calculation in the life sciences: trends and prospects |title=Algebraic Biology 2005 |series=Computer Algebra in Biology |editor-first=H. |editor-last=Anai |editor2-first=K. |editor2-last=Horimoto |publisher=Universal Academy Press |location=Tokyo |year=2006 |chapterurl=https://web.archive.org/web/20060616135155/http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf }}
{{cite book |first=Michael P. |last=Barnett |author-link=Michael P. Barnett |chapter=Symbolic calculation in the life sciences: trends and prospects |title=Algebraic Biology 2005 |series=Computer Algebra in Biology |editor-first=H. |editor-last=Anai |editor2-first=K. |editor2-last=Horimoto |publisher=Universal Academy Press |location=Tokyo |year=2006 |chapter-url=http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf |archive-url=https://web.archive.org/web/20060616135155/http://www.princeton.edu/~allengrp/ms/annobib/mb.pdf |archive-date=2006-06-16}}
|archive-url=
, its assigned value applies to |chapter-url=
(or aliases) even when |url=
is present; without |chapter-url=
(or aliases), |archive-url=
applies to |url=
.|chapter=
and |title=
as well as |chapter-url=
and |url=
, this model could be extended so that if an |archive-chapter-url=
parameter would be given, it would be taken as archive link for |chapter-url=
instead of |archive-url=
(and |archive-url=
for |url=
). I have run into citations where it would have been desirable to specify independent archive links for chapters and work titles.There are quite a few URL-related arguments and IMO having separately named archive-url/archive-date/url-status for each is a lot of complication. There is {{
webarchive}}
for those archive URLs that don't fit the current model. --
Green
C 16:14, 3 January 2021 (UTC)
{{
webarchive}}
too verbose to use - readers typically care about the fact that they can access an archived link, but don't care about the name of the archiving service.What is the correct markup for a range of hyphenated page numbers? Is |pages=4-5{{snd}} 4-7
(4-5 – 4-7) correct or should it be |pages=4{{hyphen}}5{{snd}}4{{hyphen}}7
(4-5 – 4-7)?
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 15:17, 3 January 2021 (UTC)
|pages=4-5 – 4-7
. Or you could write |pages=4-5 to 4-7
.
Jc3s5h (
talk) 16:12, 3 January 2021 (UTC)|pages=4-5-4-7
(all simple keyboard hyphens) and let cs1|2 figure out the rendering:
{{cite book |title=Title |pages=4-5-4-7}}
|at=
, anticipating that well-meaning editors will come along and mangle the carefully constructed page range. |at=pp. 4-5–4-7
should work. –
Jonesey95 (
talk) 18:51, 3 January 2021 (UTC)|pages=((4{{hyphen}}5–4{{hyphen}}7))
, where the thing in the middle is an n-dash.
Jc3s5h (
talk) 18:55, 3 January 2021 (UTC)
|page=hyphenated-number
and for |pages=simple-range
, but does not spell it out for a range of hyphenated numbers. Thanks.
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 19:48, 3 January 2021 (UTC)
I am concerned that the documentation for these templates, both Help:Citation Style 1 and Template:Citation Style documentation, is becoming bloated with redundant prescriptive injunctions, which degrade its value as documentation. In this case, the admitted purpose is to further a position in a dispute on this talk page, but the problem is broader, and has been going on for some time.
Bloated documentation wastes users' time, and makes it harder for them to find the information about the templates that they seek. The documentation should define the meaning of each parameter concisely, and not expand with polemics on what they should not be used for, especially when this is already a logical consequence of the definition. Kanguole 22:26, 4 January 2021 (UTC)
I know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized. We save that for newspapers and magazines. Where is the MoS guideline for when NOT to italicize those listed news sources? An editor seems to think it makes no difference, and they are changing the citations all over the place so that those agencies are italicized. When I'm in doubt, I just look at the article for the source and see how it's done there, because I know that other editors have followed the MoS. -- Valjean ( talk) 01:20, 25 November 2020 (UTC)
|publisher=
for |work=
. The "work" is what is generally considered as the source, and this (unlike "publisher") is emphasized, in most cases with italic type. I would recommend a compromise: use the website (e.g. www.npr.org) as the "work", and NPR as the "publisher" of such work. And let the software format them accordingly.
69.94.58.75 (
talk) 12:30, 25 November 2020 (UTC)know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized? In cs1|2, the name of the source (the publisher's work) is italicized. If the source is a website, the name of the website is italicized; if the source is a magazine, journal, newspaper, or other periodical, the name of the magazine, journal, newspaper, or other periodical, is italicized; if the source is a book, the name of the book is italicized; if the source is a corporate entity initialism or broadcaster call-sign, the initialism or call-sign is italicized. This applies to both physical an online sources. It does not matter if the initialism of a cited source is the same as the initialism of the business that produced it.
and this:Do not append ".com" or the like if the site's actual title does not include it ... and omit "www."
The "publisher" parameter should not be included for widely-known mainstream news sources, for major academic journals, or where it would be the same or mostly the same as the work.
So why not go to these articles ( PBS, NPR, CNN, ABC, NBC, BBC) and try to italicize them?Why would I want to do that? The articles are about those entities as businesses; we do not cite the business, we cite the business' work (its programming, its articles, etc), and the work, in cs1|2, is italicized.
I know that publisher= and website= produce italics, and work= does not. Umm, not true...
|publisher=
is not rendered in italics but both |website=
and |work=
are (along with their aliases |newspaper=
, |magazine=
, |periodical=
, and |journal=
).{{
cite magazine}}
and |magazine=
. Both
The Guardian and
The Washington Post are newspapers so {{
cite news}}
and |newspaper=
.
Fresh Air isn't a news program nor is it a journal or a magazine or a newspaper, so {{
cite web}}
(because you included a url) or because it's aired periodically (daily where I live) you might use {{
cite periodical}}
(a redirect to {{cite magazine}}
) and |work=[[Fresh Air]]
. You can include or omit |publisher=[[NPR]]
as you choose. Hanging the program name after the cs1|2 template as you did means that the name is not included in the citation's metadata (for those who consume our citations using various machine tools).The list should also specify the ideal template to use– my answer would be always use {{ Citation}} for all citations. If you like full stops/periods all over the place, then add
|mode=cs1
. I'm sure that many editors would strongly disagree, which is why the list should not specify the ideal template to use.
Peter coxhead (
talk) 17:15, 28 November 2020 (UTC)|title=Title of Article Here
|work=[[BBC News]]
, and do not include |publisher=[[BBC]]
which would be redundant and would treat our readers like they have severe brain damage. If you're citing a news source that has no clear title beyond its domain name, then do |work=Whatever.com
. If you're citing a work that has the exact same name as the publisher (aside maybe from an appended "Inc." or "Ltd" in the latter case), put the name in |work=
, even if the wikilink in it (if any) goes to a company article (the publication is a subtopic thereof), and omit |publisher=
. E.g., the title of npr.org really is NPR, which is also the common name of the organization (in longer form National Public Radio), ergo: |work=[[NPR]]
. If this just makes your head asplode, no one is likely to care if you do |work=[[NPR|NPR.org]]
to distinguish a bit between company and output. But someone is apt to remove the .org later, because it is not actually a part of the title of the work. You cannot omit the work title and just use the publisher in an attempt to avoid italics because you have some weird notion in your head that online sources shouldn't receive the same style as dead trees ones. If you do that, you are writing broken citations and someone will correct them. If you revert-war against these corrections you are being disruptive and need to give up your lost cause. [PS: I'm using a generic "you" in this; it's not directed at a specific party in this thread, but at a diffuse cloud of editors who keep trying to abuse template parameters to de-italicize things and to pretend that we're citing a corporation rather than a published work produced by a corporation.] —
SMcCandlish
☏
¢ 😼 19:54, 4 December 2020 (UTC)|work=
is always required (|website=
and |newspaper=
, etc., are aliases of it); Wikipedia only cites published works (see
WP:V and
WP:CITE); it does not cite companies, persons, or other entities, only works by them. The |publisher=
should be added, as additional source-identification information, only if significantly different from the title of the work (do |work=The New York Times
not |work=The New York Times
|publisher=The New York Times Company
). If the name of the website is ABC News then that is in fact the title of the work, despite that also being part of the name of publisher. (It's also harmless to do |work=ABCNews.Go.com
, though that's a bit sloppy.) The actual publisher is ABC News Internet Ventures, a division of ABC News Network, a division of American Broadcasting Company, a division of Walt Disney Television, a division of the Walt Disney Company (most or all of which also have corporate postfixes like "Inc." in their full names). None of these names need appear in a citation, because they are either redundant with the |work=
at the lower levels, or too lost in financial-holdings arrangements, at the upper levels, to be meaningful to the reader in relation to a citation. (In most contexts, anyway. In a WP article about Disney or one of its other properties, it might in fact be pertinent to indicate that Disney is the ultimate publisher, either with that parameter or with a free-form note, so the reader has a clear indication of the source's lack of complete independence from the subject.) —
SMcCandlish
☏
¢ 😼 22:52, 31 December 2020 (UTC)PS, an aside to address of a bit of
WP:WIKILAWYERING that was attempted at one of the redundant concurrent threads: When the |work=
parameter (or one of it aliases) does not apply (e.g., the cited material is stand-alone and not part of a broader publication), then |title=
is the work being cited. So, yes, the work is always required, just not necessarily in the form of the parameter by that name. Another side point that's been covered before: When any website is cited by WP, it is cited as a published work (by definition), not as a shop or server or corporate entity or whatever else the same name might refer to outside of a citation-to-published-work context, where it gets italicized, even if it would not be italicized in running text as a service or company or whatever. —
SMcCandlish
☏
¢ 😼 19:41, 1 January 2021 (UTC)
|work=
and |publisher=
in many cases (when they are not basically the same): {{Citation|Title=He Smart|work=The Evening News with Walter Kronkite|publisher=Fox Sports}}, that raises the question of which is better when someone skips the work and goes straight to the publisher, which of these is better : {{Citation|Title=He Smart|work=Fox Sports}} or {{Citation|Title=He Smart|publisher=Fox Sports}}
AManWithNoPlan (
talk) 15:23, 2 January 2021 (UTC). If anyone is claiming that the |work=
or an alias thereof is always required, I call bullshit. Nonprofit organizations and for-profit corporations publish stuff all the time and what matters is the organization or corporation. When
Amnesty International publishes something, it is |publisher=Amnesty International
. When
Human Rights Watch publishes something, it is |publisher=Human Rights Watch
. When
The Heritage Foundation publishes something, it is |publisher=The Heritage Foundation
. When
United Airlines publishes something, it is |publisher=United Airlines
. When
Nestlé publishes something, it is |publisher=Nestlé
. Bonafide news organizations are the same. When
NPR does a news story, it is |publisher=NPR
. If the story is part of
All Things Considered, publisher is an optional addition to |work=All Things Considered
. When
BBC News does a news story, it is |publisher=BBC News
. These organizations existed long before the World Wide Web, and the existence of npr.org does not turn NPR into a "work".
How do we know BBC News is not a work? Just as Chevrolet is part of General Motors, BBC News and BBC Sport are part of BBC. Just as Chevrolet is not a "work" of General Motors, BBC News is not a "work" of BBC. Similarly, Fox News and Fox Sports are divisions, not works, of Fox Corporation. — Anomalocaris ( talk) 06:23, 3 January 2021 (UTC)
|publisher=
parameter for the value that belongs in |work=
just because some citations don't have a |work=
value to put anywhere (those that do not will have their sole work title in |title=
, which is still a work). So, let's not be silly. What this is about is the difference between a publication (a work), and a publisher (a business, nonprofit, or governmental entity). As shown above, trying to claim that CBS News is not the work (when the actual title of that work is provably CBS News) but is instead the publisher (when the actual publisher is provably CBS Interactive) is fact-falsification twice over. That some editors are so obsessed with the strange notion that online sources are magically exempt from the italics style applied to all publications regardless of medium, that they'll engage in falsification to trick the templates into giving them their way, is a strong indication that some topic bans from changing these parameter values around in citations is probably in order, to prevent further damage to citation integrity and factuality. —
SMcCandlish
☏
¢ 😼 20:20, 3 January 2021 (UTC){{cite news |title=Newly released docs show world's reaction to Nixon's resignation |date=August 24, 2016 |publisher=CBS News |url=https://www.cbsnews.com/news/richard-nixon-resignation-newly-released-docs-show-worlds-reaction/}}
:
"Newly released docs show world's reaction to Nixon's resignation". CBS News. August 24, 2016.{{cite news |title=Newly released docs show world's reaction to Nixon's resignation |date=August 24, 2016 |work=CBS News |url=https://www.cbsnews.com/news/richard-nixon-resignation-newly-released-docs-show-worlds-reaction/ |agency=Associated Press}}
|agency=Associated Press
. But that doesn't turn the business entity CBS News into a work. It's just a division of a larger corporation. —
Anomalocaris (
talk) 23:35, 3 January 2021 (UTC)
|work=
(or an appropriate alias). This is no different from that same story from AP were it published in a newspaper.|title=
parameter name with what a title is (see
MOS:TITLES). That which goes in |work=
is also a title. So is what goes in |series=
; they are simply titles of different things. And |title=
isn't even the same parameter in different templates. In {{
cite book}}
it is the title of the entire work (the "article" equivalent in that template is |chapter=
). That is, in {{
cite web}}
and the periodical citation templates, |title=
takes the place of |chapter=
in the book template, and |work=
or one of its many aliases takes the place of |title=
in the book template. Honestly, at this point your unfamiliarity with the templates, their parameters, and even the basic terminology of source citation makes me wonder why you are in this discussion. PS: Even if you were correct that "[CBS News is] just a division of a larger corporation", that still would not make it the |publisher=
; the larger corporation or other entity would be (in this case it is
CBS Interactive, which is too similar to the work title to bother including). But it's a false statement to begin with, as has already been explained to you (please see
WP:IDHT); "CBS News" is both the name of that division and the title of several works by that division and subsidiaries thereof, including the CBS News website. —
SMcCandlish
☏
¢ 😼 00:10, 4 January 2021 (UTC)|website=
. It did not comment on when |website=
vs |publisher=
should be used - ie whether a particular entity is best described as a work or a publisher.
Nikkimaria (
talk) 03:04, 4 January 2021 (UTC)
|work=
and |publisher=
parameters and to not abuse them for stylistic reasons. I tried to improve the documentation by stating this explicitly and adding a crosslink but was reverted by Kanguole (
[1]) for this would be bloating the documentation. In fact it does and I would prefer we would not need it, but looking at the discussion above apparently we do. My time is limited and I do not care enough about this triviality to further engage into this discussion, therefore I leave it to others to restore the sentence and link - or not - as they see fit.
User:Monkbot/task 18 is a cosmetic bot task. Among the various things that it does is replace nonhyphenated parameter names with their canonical hyphenated names. One of those replacements is |accessdate=
to |access-date=
.
I have started this discussion because an
editor at my
talk page has objected to the bot's replacement of |accessdate=
: accessdate is not currently deprecated, there is currently no discussion about deprecating it, and your only basis for replacing it by bot is the concern that were we to get consensus to deprecate it at some unknown future point, error messages would annoy people?
For the time being, I have disabled the |accessdate=
to |access-date=
replacement.
I believe that it is our intent to deprecate and remove all of the all-run-together multiword parameter names in favor of their hyphenated forms. Am I wrong? At the bottom of the §Deprecated section of every cs1|2 template (except Template:Cite citeseerx/doc) is this:
In addition to the above list(s) of deprecated and removed parameters, all non-hyphenated aliases of parameters with hyphens are discouraged to be used in citation templates and are kept only for legacy support. They are subject to becoming deprecated and unsupported in the future as well. To streamline the appearance and improve consistency across the project, these variants should no longer be used when adding parameters to citation templates. Instead, select the hyphenated parameter variants and also consider switching other non-hyphenated parameters, which may be present in a citation already, to their hyphenated equivalents at the same time. – emphasis in original
A variant of that text is present at Help:CS1 errors#Cite uses deprecated parameter |<param>=:
Plan for the future: All non-hyphenated, multiword parameter names are aliases of hyphenated multiword parameter names. The non-hyphenated aliases exist only for legacy support. Editors should expect that support for non-hyphenated parameter names will be withdrawn. Choose the hyphenated form when adding parameters to a citation template. Consider replacing non-hyphenated parameters with the hyphenated equivalents at the same time.
Do those declarations accurately reflect our intent with regard to nonhyphenated parameter names? I believe that the answer is yes because:
aliases{}
table in
Module:Citation/CS1/Configuration so that the hyphenated multiword forms are listed first|chapter=
, |contribution=
, |entry=
, |article=
, |section=
); nonhyphenated variants of a hyphenated parameter name do not meet this criterium|chapter-url-access=
, |name-list-style=
, |script-title=
, |url-status=
, etc)|conferenceurl=
, |contributionurl=
, |laydate=
, |laysource=
, |layurl=
, |sectionurl=
, |seriesno=
, |timecaption=
, and |titlelink=
;
discussionIt is probably true that we have never actually declared an intent to deprecate and remove, but reading between the lines of our past and current actions, it seems highly likely to me that our intent is to deprecate and remove these parameter names.
Is it?
— Trappist the monk ( talk) 12:41, 30 November 2020 (UTC)
I also agree that this should have consensus but I don't see the scale of change as an important factor. We are talking about a formatting change that is transparent, with zero effect on semantics, in a very specialized area of Wikipedia. Imo, the change makes semantic meaning more obvious, a good thing. 68.173.79.202 ( talk) 13:42, 30 November 2020 (UTC)
|archiveurl=
, which often has a very long link without any breaks. Using |archive-url=
helps alleviate this. It also helps to distinguish "Archived from the original on..." as plain text, |archivedate=
, and |archive-date=
in plain-text searches. -
BRAINULATOR9 (
TALK) 15:07, 30 November 2020 (UTC){{
cn}}
still redirects to {{
citation needed}}
, but we even have bots and AWB/JWB scripts that canonicalize such shortcuts to the real, non-jibberish templates names, and various tools use the real names of the templates in the first place now. Also, various cite template parameters (mostly newer ones) with hyphens don't even have non-hyphenated aliases, and the sky did not fall; there is no editorial outcry about it, so obviously there's not a real editorial demand for them theruntogetherversions as necessary or desirable. —
SMcCandlish
☏
¢ 😼 21:23, 30 November 2020 (UTC)
|accessdate=
or |authorlink=
are still too frequently used in mainspace to deprecate them now, they are only "discouraged". Being "discouraged" means that the functionality is still supported and no error message shown, but that preparations are in the works to deprecate the parameter at some later point in time, so it is wise to reduce the parameter's use whereever possible so that less work needs to be done when it gets deprecated eventually. --
Matthiaspaul (
talk) 23:16, 4 December 2020 (UTC)|accessdate=
. The functionality of any deprecated parameter is retained through the deprecation period. At the end of the deprecation period, support for the parameter name will be withdrawn and the parameter name will no longer work. For |accessdate=
, an extended deprecation period may be desirable.|accessdate=
.
Nikkimaria (
talk) 13:12, 5 December 2020 (UTC)
The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intent.In that sentence,
all nonhyphenated parametersincludes
|accessdate=
because that parameter name is a concatenation of two words and is not hyphenated.to move the whole hand away from the letter keysto reach the hyphen. All it requires is a slight move of the right hand's little finger. -- Matthiaspaul ( talk) 23:16, 4 December 2020 (UTC)
|accessdate=
on a qwerty keyboard, the introductory pipe is both hands, 'accessdate' left hand only, and the assignement operator is right hand and the key is directly adjacent to the hyphen character.While I think we should be careful not to actually remove support for frequently used parameter variants until all uses in mainspace (and possibly also in other spaces) and all tools have been updated to use hyphenated parameter variants, I think, we should not skip a chance to transform citations automatically in order to make the transition as smooth as possible for everyone.
-- Matthiaspaul ( talk) 22:34, 30 November 2020 (UTC)
|authorlink=
etc. That raises two concerns - identify all those leaf templates that recognize these parameters and pass them on, and make sure they also recognize the hyphenated version before touching their customer articles. (There are other templates that transclude {{
cite book}} and can be fixed painlessly). Second, somewhat orthogonally, in order to make the change thoroughly it should be necessary to list all templates that through a call chain end up in cs1|2, and fix the articles that use them. None of this is urgent as long as the smashedtogether variants are supported, of course.
David Brooks (
talk) 04:19, 1 December 2020 (UTC)
|authorlink=
, as opposed to those that call {{
cite book}} with parameters passed through. More significantly, I guess {{
cite book}} was not a great example, because it is not likely that users will override the specific author. More likely cases: templates that wrap {{
cite encyclopedia}} or {{
cite journal}}. An example of the former is {{
New Cambridge History of Islam}}, which needs to recognize |author-link=
before fixing its callers. I only did a shallow dive to show this pattern is non-zero.
David Brooks (
talk) 14:38, 1 December 2020 (UTC)
{{
cite book}}
. Similar numbers for {{
cite news}}
, {{
cite journal}}
, and {{
citation}}
but not for {{
cite encyclopedia}}
(142).|authorlink=
? Did you mean |accessdate=
? It is those kinds of cs1|2 templates-within-templates that task 18 can fix. It will not be able to fix cases where the wrapper template accepts/requires |accessdate=
as an input:
|accessdate={{{accessdate|}}}
|authorlink=
, which I had looked at in a little detail, and just inferred that |accessdate=
could have similar characteristics. Thanks for the clarification.
David Brooks (
talk) 17:44, 3 December 2020 (UTC)|accessdate=
. I'm not at all sure how useful that will be.I think that the sense of the above discussion is that we are going to deprecate all nonhyphenated parameter names. As of the time I write this, Monkbot task 18 has made more than 125,000 edits. About half of those edits included the |accessdate=
→ |access-date=
fix. Those 125k edits were made to a broad variety of articles so likely are included on thousands of watchlists. There have been 22 reverts (0.0176%). Given all of this, I intend to restore the |accessdate=
→ |access-date=
fix to minimize the number of articles that Monkbot must revisit.
— Trappist the monk ( talk) 14:53, 3 December 2020 (UTC)
"old" templates. The task's activities are constrained to edits inside the canonical 27 cs1|2 templates and some of their most commonly used redirects. All of the canonical cs1|2 templates invoke Module:Citation/CS1 so all of them accept both
|accessdate=
and |access-date=
. Redirects, being redirects, simply take the round-about way to get to Module:Citation/CS1. Did I answer the question?|accessdate=
but presents it as access-date when calling {{
Schaff-Herzog cite}}. That redirects to {{
Cite Schaff-Herzog}}, which (stop me if you've heard this before) recognizes only |accessdate=
but presents it as access-date before passing to {{
Cite encyclopedia}}, which invokes CS1. So there's no way of successfully representing the parameter, and the same blocked path attends |authorlink=
. Sorry, just pointing out that while the 27 canonical templates are well-behaved, the rest of the ecosystem is a mess; there's no simple global fix. But I think everyone knew that.
David Brooks (
talk) 22:39, 3 December 2020 (UTC)
Trappist the monk, again: please start a well-advertised properly-run RfC. Editors have raised objections here and at your talk page, and even those supporting preferring hyphenated parameters have expressed concerns about aggressive bot-runs and removing functionality. A change impacting over a third of the articles on the site should have a stronger consensus behind it than what is seen here. Nikkimaria ( talk) 22:06, 8 December 2020 (UTC)
|accessdate=
should be kept supported. When they fall <25,000 through "passive" conversations (e.g. AWB genfixes), then we can have bots aggressively convert them.
Headbomb {
t ·
c ·
p ·
b} 17:28, 3 December 2020 (UTC)
|access-date=
the scale is millions of articles, it could take years - even bot speed could take months. Years might not be a problem through patience and dogged determination, but in the mean time users are still adding new templates (est 5-10 thousand a week) creating churn - users adding, bots removing, spinning wheels. So the idea if I understand is to deprecate with a red warning message, but that can't be rightly done until most of the existing stock is removed since in the past when millions of red warning messages suddenly appear the community revolts and demands the problem be fixed before red errors flood articles. --
Green
C 18:12, 3 December 2020 (UTC)"passive" [conversions]route by including
|accessdate=
→ |access-date=
in AWB genfixes but there was
pushback; understandable because there are so many instances of |accessdate=
that the genfix obfuscates the fixes that awb operators intend. I have since
suspended that genfix.|authorlink=
and |accessate=
makes global changes to them important enough to warrant special treatment. I think sometimes it makes sense to unbundle big very specific changes from less specific umbrella tasks that have mostly a bunch of rare and non-controversial changes. I'd like to see the bots approval group lean towards more specific, smaller tasks in the future as the discussion above shows how valuable focused discussion just on just |accessdate=
is. That said, I recognize the power of
WP:BE BOLD and don't want to discount the efforts of those who have the know-how and put in the work to keep Wikipedia evolving. For reasons related to both typing and reading source code, I have a preference for |accessdate=
over |access-date=
but since those editors actually working in this area are clearly against the un-hyphenated ones, I am fine with being neutral in regards to their deprecation or this bot making these changes.
Jason Quinn (
talk) 06:09, 4 December 2020 (UTC) (EDIT: Now oppose instead of neutral.
Jason Quinn (
talk) 02:08, 6 January 2021 (UTC))
we have never actually declared an intent to deprecate and remove. We know our intent from the actions that we take, the code and the documentation that we write, etc. This discussion is about declaring our intent.
"to-be-deprecated" means they are still valid. These parameters are valid now and will be valid during the deprecation period until support for them is withdrawn. Given that support will be withdrawn, it is necessary to convert those nonhyphenated names to their hyphenated equivalents before deprecation so that we minimize the quantity of Cite uses deprecated parameter
|accessdate=
and similar error messages. Too many of those cause torches and pitchforks uprisings. It is precisely the recognition of the widespread use of some of these parameters that makes Monkbot task 18 important because when it comes time to deprecate these parameters, there will be far fewer error messages to distress editors.Where are we on this? Everyone seems to have moved on and I'm not clear that all the outstanding questions are resolved.
The only RFC I'm aware of is the June 2014 resolution that only "All parameter names in Citation Style 1 templates" should accept hyphenated parameters; in addition, I think there is a consensus that documentation—narrative, examples, and TemplateData—should privilege the hyphenated versions. I believe both have been accomplished for the 26 or 23 (depending which list you consult, and I may have the wrong formal terms) canonical or "General use CS1 templates", but question 1: Is it still valid to use the nonhyphen versions in an example, if there are any such?
Remaining are the hundreds that wrap one of those templates, in particular those that recognize the parameters and pass them on (there are others that simply use a CS1 template internally to identify a single specific source). Are they included in the phrase "Citation Style 1 templates" in the RFC? If so, question 3: should there be a formal effort to identify those that don't recognize hyphens, and fix them? Some have been fixed recently but I think only because they were found using an incomplete search. Independently, question 4: should we make an effort to fix all the documentation, or will "fix them when you see them and have time" be OK for now, given that there is no agreement to formally deprecate the nonhyphen parameters? David Brooks ( talk) 16:50, 14 December 2020 (UTC)
|accessdate=
. Not all of them are CS1 wrapper templates. It will probably be easiest to deal with them as follows: (1) Let Monkbot complete its run through affected articles, (2) put unhyphenated parameters in a maintenance category, which will allow us to catch templates, pages in other namespaces, and edge cases that the bot was unable to process, (3) process the pages in the maintenance category using a combination of bots and manual gnome work, (4) formally deprecate unhyphenated parameters in the module code, using the deprecated parameter category, and finally (5) remove support for the deprecated parameters. This process will probably take a year or more. –
Jonesey95 (
talk) 17:36, 14 December 2020 (UTC)
|accessdate=
(etc) recognizes |access-date=
. I guess the hunt through those that use CS1 could be automated pretty easily.
David Brooks (
talk) 22:40, 14 December 2020 (UTC)|accessdate=
which is so commonly used. A lot of editors prefer it, perhaps even most? What was the ratio of with and without the hyphen before Monkbot started "fixing" it?|accessdate=
without the hyphen is ever deprecated. It should remain a valid alias. Plenty of users still create articles with citations that use the unhyphenated form, and if the goal is to inflict big ugly red error messages or just not display the date at all upon use of the unhyphenated form, I can't see how that's going to go down well or how it's even an appropriate remedy. There are claims this is for clarity, but who has ever said they were confused about what the unhyphenated form of |accessdate=
means? Cosmetic, spam-like bot edits is all this is currently amounting to. I don't see the point of these edits. There will never be complete conformity on any issue like this on Wikipedia, and we should stop trying to force people to adapt when the old form has endured for years without any hassle.
Ss
112 13:42, 15 December 2020 (UTC)citation["cite book"]["access date"] = "2020-12-16"
--
Green
C 15:33, 16 December 2020 (UTC)TL/DRis no excuse for childishly spamming Monkbot to stop. It also sounds like the pot calling the kettle black/ psychological projection.
WP:IDHT~ Tom.Reding ( talk ⋅ dgaf) 14:59, 30 December 2020 (UTC)
|accessdate=
will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form. When that deprecation occurs, citation templates that the the bot touched will not show error messages. But, citation templates that the
bot touched and were
subsequently reverted like this one from
And a Little Child Shall Lead Them will show an error message:
{{cite web |url=http://www.silentera.com/PSFL/data/A/AndALittleChildShallLe1909.html |title=And a Little Child Shall Lead Them |accessdate=February 13, 2015 |work=Silent Era}}
|accessdate=
(
help) – error message is a mockup|accessdate=
is deprecated.Sometime, probably within the coming year, |accessdate=
will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form
. Where have you established consensus for that? It certainly hasn't been demonstrated in this thread.
Nikkimaria (
talk) 19:01, 30 December 2020 (UTC)I saw in the archive that this has been touched on in the past. I would like to see if there is a possibility of adding |illustrator-last= and |illustrator-first= to the template cite book. An example where I see the need is for John Eyre (British artist), who illustrated classics such as Pickwick Papers, The Compleat Angler, and Rip Van Winkle. These were classics, even in his day. Putting him as |author-last2=, etc. makes it appear that he helped write the books, when his actual role was to make the stories more compelling with art. Considering all the illustrated books in the world, I think the template should inlude illustrator. Am I alone? Jacqke ( talk) 14:12, 19 December 2020 (UTC)
|contributor-last=Eyre
|contributor-first=John
|contribution=Illustrator
|contributor-link=John Eyre (British artist)
-- there are many contributor roles which come to mind: illustrator, cover artist, cover designer, forward, introduction, narrator, photographer, preface, translator. If there are multiple contributors, not sure how that works of contribution and contributor-link support > one. --
Green
C 14:36, 19 December 2020 (UTC)|contribution=
is an alias of |chapter=
and is rendered in the citation in the same way that a chapter is rendered and is included in the citation's metadata as &rft.atitle=Illustrator
. Do not corrupt the citation's metadata.
{{cite book|title=Pickwick Papers|author=Charles Dickens|contributor-last=Eyre|contributor-first=John|contribution=Illustrator|contributor-link=John Eyre (British artist)}}
'"`UNIQ--templatestyles-00000040-QINU`"'<cite id="CITEREFEyre" class="citation book cs1">[[John Eyre (British artist)|Eyre, John]]. "Illustrator". ''Pickwick Papers''. By Charles Dickens.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Illustrator&rft.btitle=Pickwick+Papers&rft.aulast=Eyre&rft.aufirst=John&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+74" class="Z3988"></span>
|others=
is where other contributors go so |others=Illustrations by [[John Eyre (British artist)|John Eyre]]
{{cite book |title=Pickwick Papers |author=Charles Dickens |others=Illustrations by [[John Eyre (British artist)|John Eyre]]}}
|contribution=
together with |contributor-last/first=
, which works quite good for as long as only one type of contribution needs to be mentioned and it is okay to list it in front of the citation (and include them in the metadata).|others=
requiring manual free-style formatting. This latter type should be expanded to allow to specify multiple names by their last and first names and their roles to let the template format the output according to our preferences. In the other thread I gave examples how to possibly combine this with the |contributor-last/first=
parameters utilizing a new |contributor-role=
parameter. Alternatively, |others=
could be expanded to the same effect (|other-last/first=
and |other-role=
), but the parameter name is not particularly meaningful.I propose to update cs1|2 module suite over the weekend 9–10 January 2021. Here are the changes:
|editors=
withdrawn;
discussion|ignore-isbn-error=
, |lastauthoramp=
, |last-author-amp=
withdrawn;
discussion|nocat=
withdrawn;
discussion|edition=
parameter;
discussion|page(s)=
, also test |quote-page(s)=
;|quote-pages=
in analogy to |pages=
;
discussion
|volume=
evaluation accordingly for all cite types;|quote-page(s)=
to metadata if none of the other page-related parameters was used;
discussionModule:Citation/CS1/Configuration:
|editors=
withdrawn;|authormask=
, |displayauthors=
, |editorlink=
, |ignore-isbn-error=
, |subjectlink=
, |authormask#=
, |author#mask=
, |editorlink#=
, |editor#link=
, |subjectlink#=
, |subject#link=
, |lastauthoramp=
, |last-author-amp=
withdrawn;
discussion|seriesnumber=
, |event-format=
, |event-url=
, and |eventurl=
withdrawn;
discussion|nocat=
withdrawn;
to "et al", "edition", "section"', "sections" messages to avoid wrapping;
discussionModule:Citation/CS1/Whitelist:
|editors=
withdrawn;|authormask=
, |displayauthors=
, |editorlink=
, |ignore-isbn-error=
, |subjectlink=
, |authormask#=
, |author#mask=
, |editorlink#=
, |editor#link=
, |subjectlink#=
, |subject#link=
, |lastauthoramp=
, |last-author-amp=
withdrawn;|seriesnumber=
, |event-format=
, |event-url=
, and |eventurl=
withdrawn;|nocat=
withdrawn;|conferenceurl=
, |contributionurl=
, |laydate=
, |laysource=
, |layurl=
, |seriesno=
, |sectionurl=
, |timecaption=
, |titlelink=
deprecated;
discussionModule:Citation/CS1/Identifiers:
Module:Citation/CS1/Utilities:
make_wikilink()
where link and label are the same;
discussionModule:Citation/CS1/Suggestions:
|editors=
;|displayauthors=
, |ignore-isbn-error=
, |last-author-amp=
, |lastauthoramp=
, |authormask=
, |authormask#=
, |author#mask=
, |editorlink=
, |editorlink#=
, |editor#link=
, |subjectlink=
, |subjectlink#=
, |subject#link=
;|ASIN-TLD=
, |registration=
, |subscription=
;|nocat=
;— Trappist the monk ( talk) 17:32, 3 January 2021 (UTC)
err_extra_text_edition
and err_extra_text_pages
have hidden = true
. Why? Copy/pasta oversite?The citation indexing in Mortimer Taube is rather poor, which is highly ironic. I'm trying to improve this, but ran into a problem. How do I list multiple editors in an encyclopedia? editor_first1 et all does not appear to work and no alternative is listed on the template help page. Maury Markowitz ( talk) 13:51, 7 January 2021 (UTC)
|editor-first=
, |editor-firstn=
, |editor-last=
, |editor-lastn=
, |editor=
, and |editorn=
; underscore-separated parameter names are not supported. See
Template:Cite encyclopedia § EditorsI have been working on the maintenance backlog for a wikiproject and a significant number of the issues are "CS1 errors: missing periodical". In a majority of cases, the fix is obvious, e.g. use cite book instead, or add the journal name. However, a minority are coming from "cite document" which is basically as far as I can see a wrapper to cite journal. The problem with this is that it is not obvious to editors that if you use a template called "document" you need to add the journal field. Some examples of its use for generic documents can be found on the A30 road page. The talk page for this template states "This template is used when a bot needs to switch from the Citation format to the Cite xxx format, but cannot deduce whether the source is a book, newspaper or other document" but if the source is a book or a newspaper, then there won't be a journal field either, so this is a problem for that use case as well. Can anyone suggest a way forward here please?-- NHSavage ( talk) 09:22, 9 January 2021 (UTC)
The documentation at
Help:Citation Style 1, and for the individual CS1 templates,
says that |url-access=limited
means that, besides registering on some website, there are other constraints (such as a cap on daily views) to freely access this source
, while the tooltip on the lock icon that |url-access=limited
produces says Free access subject to limited trial, subscription normally required
.
These descriptions of the meaning of |url-access=limited
don't seem equivalent to me.
For example, having a free account on Archive.org lets one "borrow" a book, but (for many books) one must wait to do so until there is a copy of the book available (not borrowed by someone else).
If such a book is used as a source, I would understand this simulation of a physical library to create an other constraint
besides registration to freely access this source
, so, according to the documentation, |url-access=limited
applies.
On the other hand, the Archive.org account is not merely a free trial
, and (as far as I'm aware) there is no "full subscription
" one could buy to bypass the constraint, so, according to the tooltip, |url-access=limited
does not apply.
Could the intent of |url-access=limited
be clarified?
Thank you, — 2d37 ( talk) 13:53, 6 January 2021 (UTC)
Free access limited eg. trial, subscription, registration, or cap on views.The "eg." (or "for example") means these are not a complete set of reasons but are typical. -- Green C 14:01, 6 January 2021 (UTC)
viewcap limitnecessarily entails a
trial, despite that it does so in what I imagine is an archetypal example of such a limit, a newspaper's website's allowing a user to read some limited number of articles per month for free and offering a paid subscription for full access. Literally, I suppose the case of books at Archive.org involves a
cap on views(not limiting a user to viewing some number of articles but limiting a book to being viewed by some number of users), but there's no trial in that case; as far as I know, one can't buy unlimited access to the Archive's books. — 2d37 ( talk) 10:12, 8 January 2021 (UTC)
|url-access=registration
, which gives the true but incomplete description "Free registration required", and the second two use |url-access=limited
, despite that the tooltip produced thereby speaks inapplicably of trials and subscriptions. I realize that my sample size here is terribly small; if it's interesting, perhaps someone familiar with running bulk queries against Wikipedia could get better data. —
2d37 (
talk) 10:59, 8 January 2021 (UTC)
|url-access=
parameters appear to have been added to all four of those articles by
InternetArchiveBot and/or
GreenC bot:
registration
:
limited
:
|url-access=
but when IA bot is operating on its own, |url-access=
gets the correct value. It would seem to me that you should raise this issue with the bot operators and not here.|url-access=
. If there were necessarily an implicit complaintin my original post, it was that the documentation for
|url-access=limited
seems inconsistent with the tooltip that it produces. —
2d37 (
talk) 09:18, 9 January 2021 (UTC)to patrons with print disabilities. Perhaps offtopically, I wonder whether, given that restriction, Google Books previews (where available) should be preferred for those citations' URLs. — 2d37 ( talk) 09:38, 9 January 2021 (UTC)
|url=
is made less significant because of how the ISBN links to many different BookSources. —
2d37 (
talk) 08:06, 10 January 2021 (UTC)This is a follow-up to Help_talk:Citation_Style_1/Archive_73#ISBN_line_breaks, which got archived before consensus became fully clear. I continue to believe that it would be beneficial to wrap ISBNs in {{ nowrap}}, which would prevent line breaks like the one in the screenshot (that appears for Chrome; issue does not seem to manifest on Firefox). Because ISBNs are quite short, I do not see any significant downside; one would have to have an insanely narrow screen width to run into any issues. Can we decide if we're ready to implement? (Please note that the space between "ISBN" and the ISBN itself is already non-breaking; it is just the hyphens within the ISBN that are at issue.) {{u| Sdkb}} talk 14:49, 9 January 2021 (UTC)
.citation a[href*="BookSources"] { white-space: nowrap }
. --
Izno (
talk) 15:42, 9 January 2021 (UTC)
Furigana#References has a reference which contains {{ ruby}}, which is an instance of Ruby character content. I can replace the template (which uses templatestyles) with the associated HTML. Is that reasonable for metadata et al? -- Izno ( talk) 19:33, 9 January 2021 (UTC)
<announcer voice>the-prefect-solution-for-all-of-your-citation-needs</announcer voice>
. Perhaps the best solution is to hand-write those citations; their use in that article appears to be as examples of Furigana in use.Perhaps the best solution is to hand-write those citations
Is that reasonable for metadata et al?, for which I would have expected "yes, go ahead and use the raw HTML and the template will be fine" or "no, seek another solution, such as removing the ruby annotation or rewrite it". You will find no answer on that specific question in your responses. :) -- Izno ( talk) 16:56, 11 January 2021 (UTC)
Perhaps the best solution is to hand-write those citationsis the answer to the specific question because implicit in
hand-writeis:
no, seek another solution.
|title=((...))
as well - similar to what is proposed in
Help_talk:Citation_Style_1#Modifier_being_recognized_as_zero_width_joiner.These 50 pages have manual invocations of CS1 categories that need to be converted from "Category" to ":Category" inside their brackets. If anyone has a quick script that can fix them, go for it. I fixed a half-dozen of them, but it's tedious. – Jonesey95 ( talk) 23:37, 9 January 2021 (UTC)
X. JSTOR 10.14321/j.ctt1pd2k5h. links to https://www.jstor.org/stable/10.14321%2Fj.ctt1pd2k5h and not https://www.jstor.org/stable/10.14321/j.ctt1pd2k5h and escaping the slash breaks the link. AManWithNoPlan ( talk) 13:37, 10 January 2021 (UTC)
false
in the live code while devising a better solution for the next update. Trappist, can you do this, please? Thanks. --
Matthiaspaul (
talk) 15:46, 10 January 2021 (UTC)
{{cite book |title=Title |jstor=141 294}}
{{
cite book}}
: Check |jstor=
value (
help){{cite book |title=Title |jstor=141dfdfdf29 4}}
{{
cite book}}
: Check |jstor=
value (
help)Straw poll: make publication-date and publication-place full synonyms... to date and place/location respectively. Publication-place and location are used only some 600 times in conjunction (see Category:CS1 location test). I anticipate publication-date and date have similar numbers (the first several in this search look like they are being used as synonyms, and at least one or two misuses of publication-date). Anything so little used does not need full support in the module. -- Izno ( talk) 02:43, 11 January 2021 (UTC)
|publication-place=
and |location=
/|place=
are not aliases, and shouldn't be treated as such. Publication place and written-at location are two independent properties of a source, and while it is true that they are seldomly both relevant and given at the same time (hence the low numbers), sometimes they are relevant and it would be counter-productive for readers as well as for machine-readability to not distinguish between them any more. It would weaken the quality of information in references. While the parameter name |publication-place=
is perfectly descriptive already, the parameter name |location=
, unfortunately, is not. Therefore, I propose a semantically more descriptive name for it like |written-at-place=
, |written-place=
, |writing-place=
, |write-place=
, |creation-place=
or something else along that line following our modern naming conventions of adding more descriptive parts of parameter names on the left side of a parameter. Afterwards, the |location=
parameter could either be left as it is or be faded out slowly, probably a process that would take several years to finish as each usage would have to be checked manually and the parameter replaced by either the written-at or the publication place parameter.|publication-date=
and |date=
, we should analyze what other typical types of dates are referred to in various types of references and add dedicated and descriptive parameter names for them as well to improve machine-readability and allow for more meaningful and consistent output. At present, we have to put everything else into the |orig-date=
parameter, which has no date format checking and cannot contribute to the metadata output. Using more descriptive parameter names would improve the situation.You are incorrect and continue to be incorrect. They are only not aliases when they are used together, and that situation has a total of 600 uses. Total. Out of 5 million pages using this template. We do not and need not support the distinction.|publication-place=
and|location=
/|place=
are not aliases, and shouldn't be treated as such.
Publication place and written-at location are two independent properties of a sourceYeah, that is true but irrelevant. Citation templates are not repositories for all possible
properties of a source. For cs1|2,
machine-readabilityis constrained to what COinS can support so a cs1|2 template with both of
|location=
and |publication-place=
and both of |date=
and |publication-date=
emits metadata from |publication-place=
and |date=
; the other two are ignored.|date=
and/or |place=
are also present. Be mindful of the fact that certain sources such as films, etc. may be classified by work date (date of production) by default, and would be much harder to find by publication date (date of |date=
and |publication-date=
are paired.|publication-place=
, |place=
, and |publication-date=
. These simple searches give some idea of how often these parameters are used when compared to |location=
and |date=
:
{{
citation needed}}
which also takes |date=
)|location=
and |date=
. Deprecate and remove the others.|place=
and |publication-place=
as synonyms violates the
Principle of least astonishment. Either allow both or deprectae |date=
, |location=
and |place=
.
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 15:24, 11 January 2021 (UTC)
What is the proper way to mark up a {{ cite conference}} to specify the dates of the conference, the location of the conference, the time of a session and the number of a session, e.g.,
Dual Address Space & Linkage-Stack Architecture Dan Greiner dgreiner@us.ibm.com z/Server Architecture SHARE 118 in Atlanta Session 10446, 12 March 2012, 4:30 pm
I can fudge some like this, [1] but Atlanta would be incorrectly indexed as the publication place and it doesn't show the session time. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 03:33, 09 January 2021 (UTC)
|session=
would be apt. I am not sure this is the case now.
98.0.246.242 (
talk) 04:33, 12 January 2021 (UTC)References
|id=
.
66.65.114.61 (
talk) 19:48, 12 January 2021 (UTC)In
List of most-liked TikTok videos, ref 15 (currently) has the error zero width joiner character in |title= at position 46
. The issue is with the characters 🤷♂️🔥
- removing the modifier character solves the error but leads to 🤷🔥
- different text. This is a very minor issue but a bit annoying.
Elliot321 (
talk |
contribs) 07:52, 9 January 2021 (UTC)
|title=((...))
or |script-title=
?has_invisible_chars()
to detect the ((...))
markup wrapping the entire parameter value when a zwj character is found (we already look for and allow zwj characters in Indic-script text because zwj is used as a character-modifier in those scripts). We must not abandon the invisible-character check when we detect the ((...))
markup because we don't want to mask errors caused by stripmarkers from TemplateStyles or inappropriate wiki tags and the like.|title=((...))
is a better (lower footprint, less maintenance and more flexible) solution at present.Extended content
|
---|
U+200D U+1F308 U+200D U+1F33E U+200D U+1F373 U+200D U+1F393 U+200D U+1F3A4 U+200D U+1F3A8 U+200D U+1F3EB U+200D U+1F3ED U+200D U+1F466 U+200D U+1F467 U+200D U+1F468 U+200D U+1F469 U+200D U+1F48B U+200D U+1F4BB U+200D U+1F4BC U+200D U+1F527 U+200D U+1F52C U+200D U+1F5E8 U+200D U+1F680 U+200D U+1F692 U+200D U+1F91D U+200D U+1F9AF U+200D U+1F9B0 U+200D U+1F9B1 U+200D U+1F9B2 U+200D U+1F9B3 U+200D U+1F9BA U+200D U+1F9BC U+200D U+1F9BD U+200D U+1F9D1 U+200D U+2620 U+200D U+2640 U+200D U+2642 U+200D U+2695 U+200D U+2696 U+200D U+2708 U+200D U+2764 |
Wikitext | {{cite web
|
---|---|
Live | "its official: we are the CEO's of this sound🤷♂️🔥 @justjonathan14". TikTok. Archived from the original on 29 October 2020. Retrieved 14 September 2020. |
Sandbox | "its official: we are the CEO's of this sound🤷♂️🔥 @justjonathan14". TikTok. Archived from the original on 29 October 2020. Retrieved 14 September 2020. |
Seems to work. It did for all of the emoji zwj errors in cs1|2 templates listed in
Category:CS1 errors: invisible characters. {{
cite tweet/sandbox}}
uses the live version of {{
cite web}}
so I haven't tested the code against that template.
— Trappist the monk ( talk) 17:08, 12 January 2021 (UTC)
IBM System/360 cites a section
[1] within a journal article with this
<ref>{{cite journal
| author = A. Padegs
| title = System/370 Extended Architecture: design considerations | journal = IBM Journal of Research & Development
| volume = 27
| issue = 3
| pages = 198–205
| date = May 1983
| publisher = IBM
| doi = 10.1147/rd.273.0198
}} – a subsection titled "31-bit addressing" begins on page 201.</ref>
markup. The {{
cite journal}} template does not support |section=
or |section-url=
, nor does it support nested page ranges.
What is the proper markup for doing this? Shmuel (Seymour J.) Metz Username:Chatul ( talk) 13:24, 13 December 2020 (UTC)
References
|at=§31-bit addressing p. 201
|span-page(s)=
or |range-page(s)=
and |cite-page(s)=
to distinguish between them, and we came up with two possible notations how to display them in a citation. However, for as long as these parameters are not implemented, you could use something like |pages=198–205 [201]
to manually specify a page range of 198–205 with a relevant page 201 in there.|at=
to be given in addition to |page=
/|pages=
, in the same way that {{
harv}}
and friends allow |loc=
together with |p=
/|pp=
. (And then to make |at=
and |loc=
aliases for each other – it's always hard to remember which goes with which template.)
Kanguole 16:09, 17 December 2020 (UTC)
|loc=
in {{
harv}} is used for primary source locations as well as in-source (secondary) locations, so I am not sure if the aliasing would be a good fit.
98.0.246.242 (
talk) 02:21, 20 December 2020 (UTC)
Monkbot doesn't like the combination. Why, @ Trappist the monk:? 98.0.246.242 ( talk) 03:19, 14 January 2021 (UTC)
10.51355 is a working prefix. Headbomb { t · c · p · b} 04:35, 14 January 2021 (UTC)
Wikitext | {{cite journal
|
---|---|
Live | Berube, David; Eubanks-Turner, Christina; Mosteig, Edward; Zachariah, Thomas (2018-07-01). "A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University". Journal of Research in STEM Education. 4 (1): 13–22. doi: 10.51355/jstem.2018.32. ISSN 2149-8504. |
Sandbox | Berube, David; Eubanks-Turner, Christina; Mosteig, Edward; Zachariah, Thomas (2018-07-01). "A Tale of Two Programs: Broadening Participation of Underrepresented Students in STEM at Loyola Marymount University". Journal of Research in STEM Education. 4 (1): 13–22. doi: 10.51355/jstem.2018.32. ISSN 2149-8504. |
Limit is 10.59999.
— Trappist the monk ( talk) 13:44, 14 January 2021 (UTC)
Should the new CS1 error categories (e.g. Category:CS1 errors: extra text: edition, Category:CS1 errors: extra text: pages, Category:CS1 errors: redundant parameter, Category:CS1 errors: URL) have talk pages that redirect here? Thanks! GoingBatty ( talk) 05:02, 11 January 2021 (UTC)
Following up on
Help_talk:Citation_Style_1/Archive_72#last-author-amp=, support for the |name-list-format=
alias of the |name-list-style=
parameter has now been removed in the sandbox. Use of |name-list-format=
and the former |last-author-amp=
parameter has been completely replaced by |name-list-style=
in mainspace.
--
Matthiaspaul (
talk) 05:34, 16 January 2021 (UTC)
In the sandbox I have unhidden the empty unknown parameter error message. At this writing, Category:CS1 errors: empty unknown parameters has 324 entries, most of which are not in article space. I still think that there are various archives logs etc that should not be in error categories. Someone tell me again: Why it is that we don't automatically disable categorization of archives and logs for things in Wikipedia and other name spaces?
— Trappist the monk ( talk) 14:11, 30 December 2020 (UTC)
|no-cat=
parameter, but got no answer.|no-cat=
parameter (renamed to something more semantically meaningful or merged into a more generic |debug=
parameter) could be used to enable it, likewise to disable categorization in mainspace.((...))
), we probably won't need a facility to disable categorization in mainspace at all any more.uncategorized_namespaces{}
. You appear to be saying that we should be categorizing talk pages, archives, sandboxes, logs. I can see no justification for categorizing pages that are archives, or logs, or sandboxen (these kinds of pages are 'dead') nor can I see a reason to categorize talk pages. To get archived and logged pages out of the various error categories requires that editors visit each cs1|2 template with an error and manually add
|no-tracking=yes
. As new error detection is created so too, we create new 'dead' entries in the associated categories so it's back to the 'dead' pages to add yet more |no-tracking=yes
. That is mind numbing drudgework but, at present, necessary to get those 'dead' pages out of the category. Why is it that you think that these 'dead' pages should be categorized? How does categorizing 'dead' pages benefit us?uncategorized_subpages = {'/[Ss]andbox', '/[Tt]estcases', '/[^/]*[Ll]og', '/[Aa]rchive'}
Currently, if you do |access=
CS1 templates suggest |access-date=
. However, it probably should include |url-access=
which (at least in my case) was what I was trying to get to. –
MJL
‐Talk‐
☖ 18:20, 1 January 2021 (UTC)
|url-access=
per
Help:CS1 errors#param_access_requires_param.
–
MJL
‐Talk‐
☖ 18:24, 1 January 2021 (UTC)
|access-date=
not because someone could simply assume |access=
to be the correct name of the |access-date=
parameter. We could strengthen the rule to no longer trigger on variations of access without some form of date following, but given that we also have rules to catch some parameter names very similar to access as used in foreign language Wikipedias for |access-date=
I don't think this would be an improvement.Fixed two bugs in the error message display for parameters unsupported by some templates (like |publisher=
with {{
cite bioRxiv}}, {{
cite citeseerx}} and {{
cite ssrn}}) if the given parameter was in the list of parameter suggestions. The first bug caused the template to still suggest a parameter even if not supported by a particular template. The second bug caused the template to display the name of the suggested parameter rather than the given parameter.
Valid parameter |publisher=
given: (supported by {{
cite book}} but not by {{
cite ssrn}})
Wikitext | {{cite book
|
---|---|
Live | Title. Publisher. |
Sandbox | Title. Publisher. |
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |publisher= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |publisher= ignored (
help)
|
Bogus parameter |xyz=
given:
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Unknown parameter |xyz= ignored (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |xyz= ignored (
help)
|
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |xyz= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |xyz= ignored (
help)
|
Misspelling |pulbisher=
given instead of parameter |publisher=
: (example for pattern matching rule)
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Unknown parameter |pulbisher= ignored (|publisher= suggested) (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |pulbisher= ignored (|publisher= suggested) (
help)
|
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pulbisher= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pulbisher= ignored (
help)
|
Old parameter |pub=
given instead of parameter |publisher=
: (example for specific matching of rule)
Wikitext | {{cite book
|
---|---|
Live | Title. {{
cite book}} : Unknown parameter |pub= ignored (|publisher= suggested) (
help)
|
Sandbox | Title. {{
cite book}} : Unknown parameter |pub= ignored (|publisher= suggested) (
help)
|
Wikitext | {{cite ssrn
|
---|---|
Live | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pub= ignored (
help)
|
Sandbox | "Title". {{
cite SSRN}} : |ssrn= required (
help); Unknown parameter |pub= ignored (
help)
|
-- Matthiaspaul ( talk) 23:45, 17 January 2021 (UTC)
Why is url-access=free not a permitted parameter? I'm thinking of citing something like this: Kramer, Hilton (June 26, 1977).
"Black Art or Merely Social History?".
The New York Times. p. D25.{{
cite news}}
: CS1 maint: url-status (
link) Reprinted as Kramer, Hilton (June 26, 1977).
"A show about black artists, not an anthology of achievements".
St. Louis Post-Dispatch. p. 29. Retrieved 2021-01-19.{{
cite news}}
: CS1 maint: url-status (
link) The review was originally published in the NYT (and a review by a NYT critic is obviously more significant than a review by a St. Louis Post-Dispatch critic) so the citation should refer to the review's original publication in the NYT. If a reader wants to verify the reference, though, it will probably be easier to visit the newspapers.com clipping of the St. Louis Post-Dispatch reprint of the review. I'd like to show the contrast between paywalled/free so readers immediately know to click on the second one. Is the idea just that not having an icon indicates it is free? I know that I could use
but if I just stick it after {{
cite web}} it doesn't put the icon in a parallel position. Thanks,
Calliopejen1 (
talk) 19:02, 19 January 2021 (UTC)
|url-access=subscription
). cs1|2 does not highlight the norm. See
Help:Citation Style 1 § Registration or subscription required.|via=Newspapers.com
because the source is delivered to our readers from Newspapers.com not from St. Louis Post-Dispatch. It's |page=5B
, the page number actually printed on the page. For both cites, unless you are going to provide links to archives, delete |url-status=live
, |archive-url=
, and |archive-date=
; the former has no meaning without the latter two (with values).A couple of additional questions for a related citation: Ghent, Henri (October 10, 1976). "LACMA Takes a Giant Step for Black Heritage". The Los Angeles Times. pp. 1, 64-65 (Calendar section) – via Newspapers.com. Article continues here and here. ---- Is there some better way to indicate which section the article appeared in? (If they're just letters it would be something like A1, A64-A65, but Calendar-1, Calendar-64-65 or similar is pretty horrible.) Also, is there recommended way of handling this situation where there are multiple URLs for the multiple pages of the newspaper article? Thanks! Calliopejen1 ( talk) 21:15, 19 January 2021 (UTC)
{{cite news |last=Ghent |first=Henri |date=October 10, 1976 |title=LACMA Takes a Giant Step for Black Heritage |pages=1, [https://www.newspapers.com/clip/68027414/ 64], [https://www.newspapers.com/clip/68027363/ 65] |work=Los Angeles Times Calendar |url=https://www.newspapers.com/clip/68026751/black-american-art-crossing-the/ |via=[[Newspapers.com]]}}
{{cite news |last=Ghent |first=Henri |date=October 10, 1976 |title=LACMA Takes a Giant Step for Black Heritage |pages=1, [https://www.newspapers.com/clip/68027414/ 64], [https://www.newspapers.com/clip/68027363/ 65] |work=Los Angeles Times |department=Calendar |url=https://www.newspapers.com/clip/68026751/black-american-art-crossing-the/ |via=[[Newspapers.com]]}}
Greetings, everyone. The line "language=English" does not return anything in a citation. Perhaps because it's considered the obviously default language in the Engligh Wikipedia. However, there are cases (like this one) where the source's text carries only the title in a foreign language while the text is in English. I'd suggest that this information should be allowed to appear in the citation. Whenever redundancy appears, i.e. someone puts that up for a typical English-language source, we can simply delete it. - The Gnome ( talk) 11:39, 22 January 2021 (UTC)
|trans-title=
. You could also note that the body is a translation if the original was first published in French. If the report was published in both languages simultaneously there's no need to indicate a foreign language original.
65.204.10.231 (
talk) 13:16, 22 January 2021 (UTC)|language=en, fr
is probably the correct form which will render as: (in English and French).Whenever redundancy appears, i.e. someone puts that [|language=
] up for a typical English-language source, we can simply delete it.
— I seem to recall that it's desired to have |language=
given for all citations because it helps the other Wikipedias. —
2d37 (
talk) 01:59, 23 January 2021 (UTC)My understanding is that the DOI parameter supports the addition of scite_ data (info from https://scite.ai/ ), but this addition is creating a display problem where "SCITE" is expanded to a huge extent, obscuring references which invoke the addin. Is this a known problem? --User:Ceyockey ( talk to me) 02:12, 20 January 2021 (UTC)
I see that in |url-status=
there is a value for "unfit". I'm looking at a reference that is behind a paywall (so, useless to most), but for which there is an archive at archive.org. Should I use unfit for this purpose, or is there a better option, like creating a "paywall" value?
Cyphoidbomb (
talk) 00:12, 24 January 2021 (UTC)
|url-access=
. --
Izno (
talk) 00:58, 24 January 2021 (UTC)
{{cite book |last1=Dexter |first1=Franklin Bowditch |title=Biographical sketches of the graduates of Yale College: with annals of the college history |date=1911 |publisher=Holt |location=New York |pages=41-45 |volume=5 |number=1 |url=https://archive.org/details/biographicalsket51dext |oclc=1041576339 |language=en}}
This is actually part 1 of a two-part volume. |number=
does not do anything in cite book, so how would I reflect this fact? –
MJL
‐Talk‐
☖ 19:37, 26 January 2021 (UTC)
{{cite book |last1=Dexter |first1=Franklin Bowditch |title=Biographical sketches of the graduates of Yale College: with annals of the college history |date=1911 |publisher=Holt |location=New York |pages=41-45 |volume=5, part 1 |number=1 |url=https://archive.org/details/biographicalsket51dext |oclc=1041576339 |language=en}}
|doi=10.1126/science. 1140516
encodes as
https://doi.org/10.1126/science.+1140516 instead of as
https://doi.org/10.1126/science.%201140516 Note that this DOI has a space in it!
AManWithNoPlan (
talk) 19:08, 27 January 2021 (UTC)
mw.uri.encode ('10.1126/science. 1140516')
) for a very long time. If we are to believe the Scribunto documentation, we can change to mw.uri.encode ('10.1126/science. 1140516', 'PATH')
which differs only from the default by encoding space characters as %20
instead of +
. I am not inclined to relax the 'no spaces' requirement just because this one doi uses a space character. I've tweaked
Module:Citation/CS1/Identifiers/sandbox. Here, the doi works:Wikitext | {{cite book
|
---|---|
Live | Title.
doi:
10.1126/science. 1140516. {{
cite book}} : Check |doi= value (
help)
|
Sandbox | Title.
doi:
10.1126/science. 1140516. {{
cite book}} : Check |doi= value (
help)
|
Wikitext | {{cite book
|
---|---|
Live | Title.
doi:
10.1126/science. 1140516.{{
cite book}} : CS1 maint: ignored DOI errors (
link)
|
Sandbox | Title.
doi:
10.1126/science. 1140516.{{
cite book}} : CS1 maint: ignored DOI errors (
link)
|
Hello, at the Arecibo Observatory article there's a valid PMID of 33214727 despite the red ink saying 'Check |pmid= value'. I presume that the range of valid PMID numbers needs extending- please can someone fix this? TIA, Yadsalohcin ( talk) 08:20, 25 November 2020 (UTC)
It might be a good idea to figure out the growth rate of these PMID numbers. At the time or writing, the "latest literature" section on https://pubmed.ncbi.nlm.nih.gov/ gives 33338219, already 17000 more than the november 19 arecibo article. This growth rate feels ridiculous, since it would imply that PMID would've gone from 0 to 33500000 in less than 3 years. Someone got to analyze the XML dump. -- Artoria 2e5 🌉 21:33, 19 December 2020 (UTC)
Hello, https://pubmed.ncbi.nlm.nih.gov/33511486 is over 33500000. The upper limit needs to be increased. Thanks. — Bruce1ee talk 08:37, 30 January 2021 (UTC)
I have added a maintenance message in the sandbox when |ref=
is the default CITEREF generated:
Wikitext | {{cite book
|
---|---|
Live | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
Sandbox | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
Wikitext | {{cite book
|
---|---|
Live | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
Sandbox | _A_ (2020). T.{{
cite book}} : CS1 maint: ref duplicates default (
link)
|
The ref parameter is actually {{ sfnref}} just to prove it works. I don't really understand why author jumped to the end in the displayed wikitext. |
This can be used to clean up wikitext, and I imagine when the great deletion of |ref=harv
is over can be merged with that category, either as maintenance or error (basically, "stop trying so hard" :).
I have also made a dedicated Module:Citation/CS1/testcases/anchor where other tests regarding the anchor can be found and regressions indicated. I found a couple unexpected cases down the way in test_ref, indicated on the module page-proper.
(I plan to add maybe one or two more cases/assertions to ensure that display names don't impact the CITEREF generation, which I was thinking about the other day.)
I also did some code cleaning related to Ref and the CS1/2 style setting code, since by the time the style code was being reached, the module was setting |ref=
to harv if it was not yet set. --
Izno (
talk) 07:17, 30 January 2021 (UTC)
|ref=
parameter as people would have to start guessing the actual anchor name again.|ref=CITEREF...
.