Loading AI tools
From Wikipedia, the free encyclopedia
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 50 | ← | Archive 53 | Archive 54 | Archive 55 | Archive 56 | Archive 57 | → | Archive 60 |
{{Cite AV media notes}} uses |others=
for the artist, and liner notes often do not have a credited author. Here's an example of the template used with |others=
and without |last=
/|first=
:
Wikitext | {{cite AV media notes |
---|---|
Live | A Star Is Born (Credits from Liner notes). Lady Gaga and Bradley Cooper. Interscope Records. 2018.{{cite AV media notes}} : CS1 maint: others in cite AV media (notes) (link) |
Sandbox | A Star Is Born (Credits from Liner notes). Lady Gaga and Bradley Cooper. Interscope Records. 2018.{{cite AV media notes}} : CS1 maint: others in cite AV media (notes) (link) |
Should we suppress this maint message for {{Cite AV media notes}}? – Jonesey95 (talk) 07:31, 2 May 2019 (UTC)
|others=
be used in this way? The documentation for |others=
at {{cite AV media notes}}
reads:
{{cite magazine}}
template; why do it in {{cite AV media notes}}
?|others=
should be used for "Artist, producers, etc."{{cite AV media notes}}
says what it says. I wonder if those recommendations are correct and proper. The definition of |others=
says nothing about disambiguation. The use of |others=Lady Gaga and Bradley Cooper
suggests that Gaga and Cooper contributed to the media notes. Sure, they contributed to the media and I would be very surprised if their names did not appear on the media notes's cover so were I citing media notes I would probably use the words on the front cover of the notes for the citation's title. Just reaching into my box of CDs, here is Close to the Bone by Old Blind Dogs. Because the cover of the media notes reads, top to bottom:
{{cite AV media notes |title=Old Blind Dogs: Close to the Bone |year=1993 |publisher=Lochshore}}
|others=
for "Artist, producers, etc.", without qualification and clarification as is found in other documentation about this parameter (i.e. suggesting, sensibly, that this parameter is not used in lieu of author parameters, but is an additional parameter for, well, others). This actually brings up something I was just about to try to address here, anyway, and will do so in a thread below: the problem of increased forking of the citation template docs. — SMcCandlish ☏ ¢ 😼 12:00, 3 May 2019 (UTC)About |date=n.d.
(I think |date=nd
also works), can we please get this changed to report "undated" or perhaps "no date" instead of regurgitating the literal string "n.d."? It's a MOS:ABBR problem, in that it has no <abbr>...</abbr>
markup nor a wikilink, and is ambiguous at best and just a meaningless two-letter acronym to the average reader. Would also be nice if it accepted "undated" as input. — SMcCandlish ☏ ¢ 😼 21:07, 3 May 2019 (UTC)
n.d.
I think occurs in this conversation. There was some talk about undated
in this discussion.Are templates like Template:Vcite2 journal and Module:ParseVauthors still necessary now that Module:Citation/CS1 natively supports a |vauthors=
parameter? * Pppery * has returned 23:25, 25 April 2019 (UTC)
|vauthors=
parameter. Any suggestions for how to do this? Boghog (talk) 17:48, 26 April 2019 (UTC)
|first=
and |last=
(and name author format parameter as desired) to allow reusers to pick whatever citation method they prefer, and having full names in the metadata/wikitext is the only way to do so. The "there's too many in the wikitext" was never a reasonable argument for me, and especially shouldn't be now given LDR (which can see mixed use in rarer cases where there are e.g. 50 authors). --Izno (talk) 18:54, 26 April 2019 (UTC)
|vauthors=
are also stored in the PubMed database. Wikipedia is not a reliable source for citation data as it frequently contains errors. It is much more reliable to down load citation data from PubMed and there are many convenient tools for doing so. Why is it necessary to store full first names in Wikipedia when it can easily (and more reliably) be obtained from PubMed if needed? Also many don't like LDR as it splits up the text from the sources that support the text.|vauthors=
is not a hack, but a very efficient way to store author data that reduces wiki text clutter. It also enforces consistency in how first names are displayed. Boghog (talk) 07:11, 27 April 2019 (UTC)
|vauthors=
is "a very efficient way to store author data that reduces wiki text clutter." The "efficiency" of typing a few less characters is fairly insignificant in the broader context, and questionable in view of the loss of information. And wikitext clutter can be greatly reduced by not putting full citations into the text. (LDR is not the only alternative.) ♦ J. Johnson (JJ) (talk) 20:05, 27 April 2019 (UTC)
|pmid=
and download the data from PubMed using one of the many tools available tools for this purpose. If we ever switch to a system where citations are retrieved from Wikidata, and if a particular citation is also stored in a reliable database such as PubMed, the data will be harvested from PubMed, not Wikipedia. Other alternatives such as WP:HARV are complex to set up and maintain. Harvard might make sense sense when a few sources are cited many times, but much less sense when most sources are cited only once. Boghog (talk) 04:00, 28 April 2019 (UTC)
|vauthors=
is mainly used for biomedical citations indexed by PubMed. One probably would not be using |vauthors=
with an author like Ruth S. Smith who is a librarian. |first=
doesn't necessarily make it any easier finding an author since there are few restrictions on what is stored there. Wtih |vauthors=
, the author format is at least consistent. Finally the efficiency has nothing to do with the number of characters typed. Of course, one would download the sources from a database like PubMed using ref tool bar, citoid, or similar tool. The efficiency has to do with the number of characters stored in the raw wiki text. Boghog (talk) 05:52, 28 April 2019 (UTC)
there is an important distinction between what can be done, and what should be done. Boghog (talk) 07:38, 28 April 2019 (UTC)
|firstn=
/ |lastn=
but, alas, that ideal world is not this world. I've just made an awb pass through 25k of the 30k articles that populate Category:CS1 maint: Multiple names: authors list. I was plucking off the low hanging fruit, some of which was conversion of Vancouver-style name-list assignments in |author=
, |authors=
, and |last=
to |vauthors=
.{{vcite2 journal}}
need to be renamed to {{cite journal}}
.fewer characters" at the outset is not "
more efficient", because here it is also less information. It is arguable that the decrease of typing effort is less than the decrease of information, and therefore vcite style is less efficient (more effort relative to the information). And this is without factoring in any additional effort required further on. If people want vcite style, fine, but "more efficient" is a poor reason for doing so. ♦ J. Johnson (JJ) (talk) 19:54, 28 April 2019 (UTC)
|vauthors=
is not necessary, except as a slight (very slight, and even misguided) accommodation to the sensibilities of some editors. Mind, I am not necessarily against such accommodations, but we should be clear on why we do so. ♦ J. Johnson (JJ) (talk) 19:59, 29 April 2019 (UTC)
|vauthors=
was necessary, only whether it was necessary to have special templates for it when the main template already supported it. * Pppery * has returned 20:03, 29 April 2019 (UTC)
|first=
and |last=
"). If Boghog's point is de-hyperbolized, it is correct that WP:CITEVAR permits use of Vancouver or any other citation style, and that changing the style at an article with an established and consistent citation style is discouraged, without a consensus discussion first. (CITEVAR is often misinterpreted as a "once a style it set, it cannot be changed rule", and is nothing of the sort; worse, it's even misconstrued as a "whoever set the style in the first major edit has more say in how the article should develop, moving forward" rule, which is just flatly against WP:OWN] and WP:EDITING policies). However, this doesn't mean we need stand-alone templates for Vancouver citation formatting, or even that CS1/CS2 should support any parameters relating to that citation style, though I don't think there's any real harm in the latter.I'm honestly skeptical of the underlying rationale, though. It simply cannot be true that medical academics and other professions will quit Wikipedia in a huff if we do not bend over backwards to make it easy to use a citation style some of them prefer (actually, mostly Americans, and in particular fields), or even allow it at all. These people are entirely accustomed to either conforming to the house style sheets of the publications they submit papers to, or having it conformed for them. As a long-term test, I've been normalizing Vanc. author names to |last=
|first=
and compliant with MOS:INITIALS every time I have some time to spare and I encounter an article with Vanc. cites that are not used consistently; in about 5 years of this, I've been reverted a grand total of twice. (I got the change to stick in one of those cases by pointing out that article wasn't consistently using the style and did not have that style in its first non-stub version; in the other I conceded because that article did originate with Vanc. style, and the non-consistent cites in the page were recent additions.) So, the idea that if you change Vanc. cites to typical WP ones all Hell is going to break loose is patently false.
Anyway, no one is forced to use these templates, and a CITEVAR "universal permissiveness" about Vanc. and all other cite styles doesn't translate to required work on the WP:CS1 end; any doctor or lab researcher can insert Vanc.-style cites all they want, manually. We shouldn't be providing tools that make it easy to use confusingly divergent cite styles; WP is for readers, not for writers, much less writers with particular field-specific style manuals on their desks.
— SMcCandlish ☏ ¢ 😼 21:00, 3 May 2019 (UTC)
we'd preferis not a reason. The pros and cons have discussed ad nauseam above. Divergent styles, as long as they are documented is not confusing. The Vancouver system is not primarily American. It was established by the International Committee of Medical Journal Editors (ICMJE). Time to move on. Boghog (talk) 06:33, 4 May 2019 (UTC)
This edit request to Module:Citation/CS1/Configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Bibcode access on the http://adsabs.harvard.edu/abs/ site is now complaining about oncoming deprecation.
A minor change, but possibly worth a discussion: I have updated two error category names and many maintenance category names to make the capitalization of the category names consistent. These changes would go into effect with the next module update, and existing categories would need to be renamed or moved (or just deleted and recreated, whatever makes the most sense). – Jonesey95 (talk) 08:06, 2 May 2019 (UTC)
'CS1 maint: ignored ISBN errors'
-> 'CS1 maintenance: ignored ISBN errors'
. --Izno (talk) 13:13, 5 May 2019 (UTC)Right now, |subscription=
and |registration=
cause categorization of pages; see in Module:Citation/CS1/Configuration:
['subscription'] = '<span class="cs1-subscription">(Subscription required (<span title="The site requires a paid subscription to access this page.">help</span>))</span>' ..
'[[Category:Pages containing links to subscription-only content]]',
['registration']='<span class="cs1-registration">(Registration required (<span title="The site requires registration to access this page.">help</span>))</span>' ..
'[[Category:Pages with login required references or sources]]',
Do we want to do the same with the Access parameters? I did not see anywhere that this categorization occurs. --Izno (talk) 13:18, 5 May 2019 (UTC)
{{registration required}}
) and Category:Pages containing links to subscription-only content (shared with {{subscription required}}
). Perhaps Category:CS1 sources limiting access, Category:CS1 sources requiring registration, and Category:CS1 sources requiring subscription.There is increasing inconsistency between the various loci of our cite template documentation. In some cases (e.g. for |year=
) various pages have been long out of step with each other. We have too much of it separately maintained (and often basically unmaintained) in too many places, like Help:CS1, Help:CS1 errors, Template:Citation Style documentation, and each template's documentation page, and probably other places, too. Some of these are pulling the same documentation via transclusion, which is a good thing, while others are separate documentation, which is increasingly WP:CFIing in confusing and unhelpful ways. E.g., the discrepancy in the treatment of |year=
at these pages (I think I managed to resolve that today) is almost certainly the primary proximal cause of editors continuing to use |year=YYYY
despite its deprecation (except in one very, very specific circumstance) in favor of |date=YYYY
half a decade ago at a least. (Another cause is tools that have not been updated and which are hard-coded to use |year=
. Sometimes authors of these tools are surprisingly stubborn in refusing to update their code to comply with current WP:CS1 documentation, or WP:MOS changes, or anything else, which I think is a form of WP:BOTPOL failure, though I would try discussion/persuasion several more times before making some kind of dramaboard issue out of it.)
There are more such "documentation forks" (I think WP:CFI needs another section for that concept), and I hadn't even noticed the one reported here a few threads above, where |others=
is mis-documented at one page as just being for "authors, producers, etc." without any qualification, while another more accurately describes this as an adjunct to other biographical parameters, not a replacement for them, but for additional parties that don't fit into an author, editor, translator, or other specific bio parameter.
Maybe we need some kind of "map" of all the documentation, from which we can figure out how to transclude more and separately [fail-to-]maintain less.
— SMcCandlish ☏ ¢ 😼 12:14, 3 May 2019 (UTC)
I've tweaked Module:Citation/CS1/sandbox so that the error messages emitted when something is not right with the |xxx-url-access=
parameters, show the name of the actual parameters involved:
and aliasing still works:
—Trappist the monk (talk) 18:06, 5 May 2019 (UTC)
SMcCandlish imperfectly replaced "website" with "work"? I still think "website" should be the correct name of the field as this is cite web
, not cite news
. But because of his edit, now whenever I edit a ref via ProveIt or add a new one via the citations toolbar, the field "website" is treated as a separate field from work (whereas they were previously one). Can someone please now merge these two fields perfectly? --Kailash29792 (talk) 09:43, 3 May 2019 (UTC)
|website=
with this edit. I don't use ProveIt or ve so someone else will have to test that change.|work=
instead of the custom aliases it has at various templates (|website=
, |journal=
, |magazine=
, |newspaper=
, etc.), for consistency, concision, ease of conversion between templates, and so on. We should be able to update the template docs to display (and thus encourage) use of |work=
, and to mention the variant aliases only in passing, as legacy options. Having a tool like ProveIt treat |work=
and |website=
as separate things was the diametric opposite of the intended and expected results (and frankly seems like really bizarre behavior on the part of that tool – a problem to fix on that end). — SMcCandlish ☏ ¢ 😼 11:45, 3 May 2019 (UTC)
I think by now most of us have noticed ...You know, whenever I hear or read anything that remotely sounds like "I'm sure that we can all agree ...", that is when I start to think: "no, we do not all agree ..."; it's the contrarian in me. So, I tried a couple of simple searches.
{{cite web}}
templates. I did two searches looking for {{cite web}}
using:
|website=
~120k articles (timed out)|work=
~128k articles (timed out)|website=
v. |work=
in {{cite web}}
perhaps we need someone who can hunt through a recent database dump or we need to modify the cs1|2 modules to add properties cats for {{cite web}}
. I suppose that we ought to also include the other periodical aliases (|journal=
, |newspaper=
, |magazine=
, |periodical=
, |encyclopedia=
, |encyclopaedia=
, |dictionary=
, |mailinglist=
) and perhaps create maintenance cats for those. This (timed out) search for |newspaper=
in {{cite web}}
found ~8k articles.|website=
and |work=
had the exact effect that was reported above. My intent was certainly not to fork these parameters into separate entities, much less necessitate the creation of redundant categories!I understand your "contrarian me" reaction, but I'm not making an "everyone agrees" point. On WP it's never true that everyone agrees on anything! Ha ha. Rather, I'm observing a trend and trusting that others have been observant enough to pick it up as well. I've been okay for years with the templates being documented as having parameters like |website=
and |newspaper=
, and barely mentioning |work=
; I really didn't care much.
But some of what I've noticing more and more over about the last three years are the following: There's been a sharp increase in constructions like {{cite news|work=Foo News|...}}
and {{cite web|work=The BarBaz Blog|...}}
. If you convert an entire article to use the consistent and concise construction, virtually never will anyone will revert you (probably only at an obscure-topic WP:FA that has an effective WP:OWNer), because the change is generally seen as an improvement; but if you go the opposite direction, replacing |work=
with things like |website=
and |magazine=
, a revert is much more likely, as WP:MEATBOT-style change that is not helpful in any way to anyone. People actually complain about |website=
, etc., and label them pointless, confusing, and so on (I ran into that again just yesterday as part of the perennially recycling argument about italicization of work names when the source is electronic; the forcefulness of the complaints about the different and longer-named parameter aliases (e.g. "|work= or one of its pointless aliases (website, newspaper, etc)" – from someone who's actually on the opposite side from me on the matter actually under discussion over there) was what inspired me to look into normalizing toward |work=
. I picked a single template to do this with as a test run, and it's interesting that no one objected about the substance/intent of the change, only the unexpected effect it had on one tool, from the TemplateData part of that edit. A major source of misuse of parameters (especially work titles in |publisher=
and |via=
) is confusion about which parameter is for what; the more differently named parameters there are, the harder it is for people to make sense of them and memorize them. The trend toward |work=
is natural for more generalized reasons, too, familiar to those who spend a lot of time in discussions at WP:P&G pages and in WP:TFD: concision is generally a virtue, and consistency almost always is one in such matters. WP:CREEP is a problem, whether it's happening in P&G pages or template documentation; instructions are instructions, and the more we have and the more variant they are, the harder it is to become an editor and remain one who knows how things work and should work. For many years we've been increasingly normalizing similar templates to have identical parameters (for editor sanity, for codebase sharing, and for direct merger of redundant templates). So, I'm in no way surprised at the favoring of |work=
over time.
Part of my "job" as a P&G editor, a TemplateEditor, a PageMover, and a gnome in general is to normalize how stuff works to match what the community is doing/expects, what the operational consensus is, whether people have had fighty RfCs about it or not. I'm actually pretty good at this; given the large amount of that work I do, quite boldly, I would have been topic-banned from such activities, or just indeffed, long ago if I were technically incompetent at it, were just implementing my own or some WP:FACTION's preferences, or were simply terrible at gauging what the ground-truth consensus is.
Anyway, yeah, I would expect searches like the ones you did to time out, because there are millions of instances. I don't think such stats would be useful even if they could be gathered, because of legacy use and other skew. They'd only be informative if they could be gathered completely and compared at least as granularly as month to month. Even then, there's the fait accompli bias that most of the templates' documentation encourages the use of the variant, long-winded parameter aliases. And we'd need some way to exclude results from tools hard-coded to use particular parameter names. However, the fact that the results you were able to get out of the searches, before the timeout, showed |work=
with a marginal lead anyway despite being virtually hidden in the documentation is telling.
— SMcCandlish ☏ ¢ 😼 20:33, 3 May 2019 (UTC)
|work=
more than |website=
– but then I just don't pay much attention to that kind of stuff. I had thought that if the searches returned something useful that would be a simple way to gauge a trend if one exists by taking an initial sample now and over the next some-number of months take additional samples. This same can be accomplished by creating properties cats (relatively easy to do I think), or by hunting through database dumps (more difficult according to Editor GreenC).|website=
was added to Module:Citation/CS1/Whitelist (this edit 9 April 2013) we went through a spate of confusion, anger, ... (pic your emotion). Since then, there has been little or no discussion here about |work=
being preferred over |website=
. Much of that previous discussion was about either of these parameters rendering in italics.|website=
in the cs1|2 module suite seems to have arisen from this feature request. I didn't find discussion that necessarily supports that particular feature request but there is this and a long section of a much longer section (you rose in opposition in that latter conversation).|website=
exists, but of whether we "advertise" the consistent parameter or the divergent ones more. And, secondarily, what needs to be done to favor |work=
without breaking a tool and causing it to treat them as separate parameters rather than one parameter with a |website=
alias. — SMcCandlish ☏ ¢ 😼 09:11, 4 May 2019 (UTC)
|work=
over any of the 'periodical' parameters (|journal=
, |magazine=
, |newspaper=
) in their respective cs1 templates and {{citation}}
, so I would not favor |work=
over |website=
in {{cite web}}
or {{citation}}
. The periodicals that I read or refer to in everyday conversation are journals, magazines, newspapers; these are the common English terms for those things. I don't think that I've ever referred to a magazine or newspaper as a work except here in the context of these templates. When I visit some website, I'm visiting a website, not a work. Yeah, all of these things are 'works' but that is a jargon-ish term that I think is useful as a fall-back in certain cases (media other than newspapers in {{cite news}}
for example).|work=
as the primary parameter name for {{cite web}}
and the periodical cs1 templates, then, were I again a novice, I would have to look that up to see how to use that parameter. If I were a newby and citing a journal or a website, I suspect that I'd catch-on more quickly with parameter names that reflect the thing that I'm actually citing.cit
into the add-a-template text box, ve will offer them a handful of templates. For me it offers:
{{citation}}
, {{cite}}
, {{cite web}}
, {{cite book}}
, {{cite news}}
, {{cite journal}}
, {{cite av media}}
, {{cite episode}}
, {{cite encyclopedia}}
, {{cite av media notes}}
, {{cite press release}}
{{cite web}}
, {{cite news}}
, {{cite book}}
, {{cite journal}}
{{cite web}}
, {{cite news}}
, {{cite book}}
, {{cite journal}}
answer the majority of editors's citation needs.|website=
and |work=
would be useful as seperate parameters. Fossilworks is a website that uses the Palaeontogy Database (the work?), which also can be accessed from its own website. This is usually handled |publisher=
parameter for one of them, which doesn't seem right. Jts1882 | talk 13:09, 4 May 2019 (UTC)
|website=Fossilworks
is appropriate; if to paleobiodb.org then |website=The Paleobiology Database
is appropriate. We shouldn't astonish readers by writing citations that name one source but link to another.|work=Paleobiology Database
|publisher=Fossilworks
in this search. I think the reason it was done this way is that the fossilworks website requests that both the database and their gateway website are given in citations. There are some examples of other ways that this has been attempted. Jts1882 | talk 15:59, 4 May 2019 (UTC)
|publisher=fossilworks
but this doesn't seem an accurate use of publisher and the website should be the one italicised. Jts1882 | talk 10:50, 6 May 2019 (UTC){{cite web|url=http://fossilworks.org/bridge.pl?a=taxonInfo&taxon_no=162281|title=''Panthera leo atrox''|last=|first=|date=|work=[[Paleobiology Database]]|format=|accessdate=2012-03-11}}
{{cite web|url=http://paleodb.org/cgi-bin/bridge.pl?action=checkTaxonInfo&taxon_no=42695|title=Giraffa (giraffe)|publisher=[[The Paleobiology Database]] |accessdate=2016-09-13}}
{{cite fossilworks}}
template that would wrap an appropriate cs1|2 template to handle all of the constant stuff like the website name etc and give the citations some form of consistency. That won't fix the big problem of citation titles that don't match the database entries but it would be a step in the right direction. I can help if the cognizant wikiproject wants to implement an appropriate template.|work=Paleobiology Database
is appropriate. Using the PB database as the work and just referencing fossilworks in the url is the kind of surprise we should be avoiding. A number of the examples use |publisher=fossilworks
but this seems inappropriate. |via=
is another possibility but that seems to be used for archive services and sites like JSTOR.|access-date=
and produce output of the form "Retrieved from the Paleobiology Database on 6 May 2019" while using |website=fossilworks
. Jts1882 | talk 10:50, 6 May 2019 (UTC)
http://paleodb.org/
and http://fossilworks.org/
urls link to a database at Macquarie University.FAQ1 https://paleobiodb.org/classic/...
urls link to a database held at University of Wisconsin–Madison.FAQ2 Two separate databases. There is at least a one-way sync from the UW database to the Macquarie databaseFAQ2 – there is no mention of data sync in the other direction.|work=
) of |website=
to instead be treated as aliases (including |website=
) of |work=
. I'm guessing there was some kind of tiny syntax error in what I did in the TemplateData block, or I'm missing information about what that third-party tool is doing with that information in its own codebase. — SMcCandlish ☏ ¢ 😼 20:33, 3 May 2019 (UTC){{date}}
it will stop matching on the first "}", and there are cite templates with empty arguments that were copy-pasted in and not a good reflection of usage, and Elasticsearch considers the search too expensive. It would require parsing the dump taking into count these factors. I can do this, but it would take some work, so only if really needed. -- GreenC 15:18, 3 May 2019 (UTC)
Please see Talk:Mueller Report#Publisher versus work or website in citation template. — SMcCandlish ☏ ¢ 😼 05:47, 2 May 2019 (UTC)
|work=
/|website=
and |publisher=
parameters. - PaulT+/C 19:50, 6 May 2019 (UTC)I propose to update the cs1|2 module suite sometime on the 20–21 April 2019 weekend. The changes are:
{{use dmy dates}}
and {{use mdy dates}}
documentation update suggested|transcript=
for {{cite AV media}}
(discussion)|display-contributors=
and |display-translators=
, refactor et al check ([[Help_talk:Citation_Style_1/Archive_53#|display-interviewers=_and_|display-translators=|discussion]])|editors=
is_pdf()
to detect html entity fragment delimiter (discussion)to Module:Citation/CS1/Configuration:
|host=
from alias of |authors=
to alias of |last=
(discussion)|script-title=
to Module:Citation/CS1/Whitelist:
|host#=
parameters|subscription=
and |registration=
(discussion)|displayauthors
in limited_basic_arguments
list (discussion)to Module:Citation/CS1/Date validation:
to Module:Citation/CS1/Identifiers:
—Trappist the monk (talk) 15:37, 14 April 2019 (UTC)
|url-access=
. See Help:CS1#Registration or subscription required and subsections. --Izno (talk) 15:14, 20 April 2019 (UTC)|subscription=
and |registration=
is that they are vague, non-specific parameters. Functionality of these two parameters with greater specificity is provided by |url-access=
and related parameters. It is, unfortunately, all too common for editors to use these parameters for urls other than |url=
. It is legitimate for a citation to have, for example, both |url=
and |section-url=
; one source may be behind a paywall while the other source is not (they don't have to link into the same domain); it is not possible for |subscription=
and |registration=
to specify which is which but |url-access=
and |section-url-access=
can.
|subscription=
/ |registration=
and |url-access=
? What I mean is, since the former are deprecated, it means that, for example, a journal cited without a URL but with a DOI parameter can no longer include any indication (that I'm aware of) that says the source requires a subscription. JSTOR, for example, requires a subscription, but without the URL included, |url-access=
gives a "requires URL" error. Hopefully that made sense -- and apologies if this has been addressed and I missed it. – Broccoli & Coffee (Oh hai) 20:05, 26 April 2019 (UTC)
|jstor=
, |doi=
, etc typically lie behind a paywall. Because that is the normal case, we do not highlight that norm so cs1|2 does not support subscription / registration icons for those identifiers. For the occasional cases where the identifier-linked source is free-to-read, use |doi-access=free
and the like. |url=
is the opposite; sources linked by |url=
(and |chapter-url=
and aliases) are normally free-to-read. When they are not, |url-access=subscription
(also registration
and limited
) can be used.
Deprecated? When? Where? Why? All these things I am yet to know! But seriously, what's the story? ——SerialNumber54129 19:26, 22 April 2019 (UTC)
|subscription=
and |registration=
are the 'old system'.The citation plugin in VE seems to be broken at this time. Adding a plain URL (such as this one) to the Citoid field or to a regular (manual) citation template field results in the following error:
Lua error in Module:Citation/CS1/Configuration at line 458: attempt to index local 'content' (a nil value)").
Please fix this, this may affect every Wikipedia user trying to add a reference in visual editing mode.--DarTar (talk) 03:03, 23 April 2019 (UTC)
I tested this locally, the bug in the preview seems to have been introduced by the most recent change here as reverting it fixes it: https://en.wikipedia.org/w/index.php?title=Module%3ACitation%2FCS1&type=revision&diff=893307475&oldid=879151028 Mvolz (WMF) (talk) 08:00, 23 April 2019 (UTC)
mw.title.getCurrentTitle():getContent()
when a page is being created; but that is checked in the function get_date_format
in Module:Citation/CS1/Configuration to figure out the date format (this feature was indeed added in the last update). Galobtter (pingó mió) 08:05, 23 April 2019 (UTC)I abhor ve so don't use it. If I create a new page in main space and add a simple {{cite book}}
template to that page using the wikisource editor and preview that new page, no error. That suggests to me that the problem isn't with this module suite but rather it is with ve, with the preview mechanism, or with Scribunto. Just because this module reveals the problem does not make it the source of the problem.
We can, I suspect, mask the problem by writing:
local content = mw.title.getCurrentTitle():getContent() or '';
but that is possibly just a mask and not a proper fix. —Trappist the monk (talk) 11:34, 23 April 2019 (UTC)
or '';
fix. ESanders (WMF) (talk) 14:11, 23 April 2019 (UTC)This section gives cryptic advice, and my efforts to follow that advice generated more errors in the citation. Template:Cite news#Deprecated gives a list of odd-looking terms in place of url= when subscription=yes had been used for a newspaper citation. In specific, in the Natzweiler-Struthof article on the concentration camp, there is a ref to the New York Times of 10 Oct 1945, title=Kramer persists in denying guilt. It had an error message because it used the subscription=yes parameter. Now I have a subscription to the New York Times, so I do not know what a person sees who does not have one, if they click the link. I tried using article-url-access= for the New York Times article, and that generated error messages saying accessdate needs url, among other messages. As far as I understand, the New York Times does still require a subscription for much access to its articles; I know it was counting articles for me in 2018, and I had exceeded the count so access was blocked, and thus I decided in early 2019 to get a subscription. Can someone please expand the table at Deprecated to say when those various parameters need to be used? It is not obvious to me. I do not want to test each one in succession to learn that. Now the reference uses url= for the link to the image of the old article and generates no error messages as to format. Should I be adding a template with subscription required, from Template:Subscription required? --Prairieplant (talk) 03:46, 24 April 2019 (UTC)
|url=
with |article-url-access=
in a citation that was not the 1945 NYT article(the result). The
|xxx-url-access=
parameters are not replacements for |xxx-url=
but are, instead, replacements for |subscription=
and |registration=
.|subscription=
:
{{cite news |title=Kramer Persists in Denying Guilt |url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |subscription=yes |accessdate=19 September 2015 |work=The New York Times |issue=Vol. XCV, No. 32,036 |publisher=The New York Times Company |date=10 October 1945 |page=8}}
{{cite news}}
: |issue=
has extra text (help); Unknown parameter |subscription=
ignored (|url-access=
suggested) (help)|xxx-url-access=
parameters each match a |xxx-url=
parameter. Your example citation doesn't use |article-url=
because that parameter is not supported by {{cite news}}
:
{{cite news |title=Kramer Persists in Denying Guilt |article-url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |accessdate=19 September 2015 |newspaper=The New York Times |date=10 October 1945 |page=8}}
|url=
so the proper access parameter is |url-access=
{{cite news |title=Kramer Persists in Denying Guilt |url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |url-access=subscription |accessdate=19 September 2015 |newspaper=The New York Times |date=10 October 1945 |page=8}}
{{cite ODNB}}
.|dead-url=
should be renamed to something else because the value that it takes is not a url but a keyword. I have never gotten much support for renaming it to something else, perhaps because I haven't yet found a better name; yeah, we could flip it to |url-dead=
but that just doesn't sound write. This parameter, I think, is the only one like that. Got a suggestion for that?|url-state=
with possible values dead
, live
, and possibly also the HTML response #s (e.g. 404) which would enable machine checking (ru.WP allows HTML responses). Current values would be deprecated but could be bot-trivially replaced. --Izno (talk) 15:02, 25 April 2019 (UTC)
|url-state=
or |url-status=
:
|isdead-url=
? Nthep (talk) 16:21, 25 April 2019 (UTC)
-url
. It is this that makes |dead-url=
a poor name (editors regularly give that parameter the dead url as a value) and why so far, in my opinion, |url-status=
might be preferred. We use |dead-url=
for a variety of things so if possible we should retain the current keywords unfit
, usurped
, and bot: unknown
(we would have to replace yes
and no
with dead
(default) and live
. Thank you for the suggestion. Got any others?|dead[-]url=
end with "url=" causes other problems, e.g. when cleaning up citations for consistency and readability: a mass change done to all the actual URL-providing parameters in the page ends up having to be reversed for the dead-url case. — SMcCandlish ☏ ¢ 😼 20:37, 3 May 2019 (UTC)Why do the cite templates cause a page to transclude itself? Examples:
--Redrose64 🌹 (talk) 22:30, 25 April 2019 (UTC)
local content = mw.title.getCurrentTitle():getContent() or ''; -- get the content of the article
getContent()
title object says:
{{
and }}
. This was done to support auto date formatting.mw.loadData
ed submodule, so it only happens once per page. * Pppery * has returned 23:15, 25 April 2019 (UTC)Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.