Help talk:Citation Style 1/Archive 95
'Others' parameter for 'Cite magazine' templateWhile looking through the parameters of Template:Cite magazine, I noticed that the 'others' parameter is the recommended means by which illustrators should be listed. As the 'authors' parameter was deprecated for not contributing to the citation's metadata, shouldn't a separate, optional 'illustrator' (aliases 'illustrator-last', 'illustrator-surname', 'illustrator1', 'illustrator1-last', 'illustrator1-surname', 'illustrator-last1', 'illustrator-last1'), 'illustrator-first' (aliases 'illustrator-given', 'illustrator1-first', 'illustrator1-given', 'illustrator-first1', 'illustrator-given1'), 'villustrators' (Vancouver style), and 'display-illustrators' (to determine when et al. is added) parameters be added, to ensure documented magazine illustrators are searchable as metadata in a format similar to the ones established for authors and editors? The 'others' parameter would still be kept, of course, as a catch-all parameter for any additional contributors. -CoolieCoolster (talk) 23:36, 11 May 2024 (UTC)
PDF page number parameterPDFs often have page numbers printed on each page, but these are offset from the page numbers of the digital PDF file due to title pages, forewords, etc. Normally we only cite the page number printed on the page we're citing. Could we add another page number parameter for the digital page number in such a document? Maybe we could call it "digital page", "PDF page", "digital document page", or "digital version page". Toadspike [Talk] 12:06, 27 May 2024 (UTC)
Prioritize publisher URL over third-party repositoriesI propose that we prioritize linking to articles provided by the publisher over third-party repositories when both are open access. When a citation template doesn't supply Consider the following citations of the same work: When
When
When both
I am proposing a change only for the very last example, when both My primary reason for this change is that some articles in PubMed Central appear to be preprints rather than the final published version, eg. PMC 6688940. (Note the text change following the mention of Salpiglossis sinuata.) Additionally, I think its worthwhile to encourage traffic to open access publishers. Minor considerations:
Daask (talk) 14:24, 27 May 2024 (UTC)
Citation issue still brokenAs mentioned, the template continues to be broken, failing to display Now, y'know, go ahead and actually fix it. Please. Thank you. — LlywelynII 23:40, 28 May 2024 (UTC)
Works with multiple volumesUsed to be simple to handle with
FAQI started an FAQ for this page at Help talk:Citation Style 1/FAQ because of this discussion. IDK if we even actually need a separate page for the FAQ or if we can just put it on Help:CS1 or something. But I do think it would be valuable to have something for recurring comments/requests. Izno (talk) 23:35, 1 June 2024 (UTC)
|agency not working in Cite book template?Is the agency parameter still working in the Cite book template? It is listed as an active template parameter on Template:Cite_book/TemplateData but the template is throwing up Unknown parameter errors, e.g. Template:Cite_OED_1933/doc Skullcinema (talk) 14:04, 26 April 2024 (UTC)
Can we please not remove parameters breaking hundreds or thousands of article citations? The agency parameter was used in tons of
The category CS1 errors: unsupported parameter currently has more than 3000 pages listed, the majority for
As the parameter
Relatedly, Citation bot has recently been adding agency= to cite book templates: see User talk:Citation bot/Archive 38#Adds unknown parameter to CS1 and Special:Diff/1221981567. —David Eppstein (talk) 19:26, 9 May 2024 (UTC) Displaying the name of the collaboration when the primary authors are not knownThe description of the collaboration parameter says:
When collaboration is supplied, but author is not, the current behavior is to not display the name of the collaboration at all. The problem is that there are studies for which the primary authors are not known. For example, the following rather important study, referenced in Euler–Heisenberg Lagrangian, has 397 authors, none of them marked as primary: "Measurement of e+e− Momentum and Angular Distributions from Linearly Polarized Photon Collisions". Listing the first few names from an alphabetically sorted list of authors makes no sense. The current behavior forces me to use author for the name of the collaboration. I propose to change the description and the behavior of collaboration so that it only requires supplying the primary authors if they are known, still displaying the name of the collaboration if author is empty. — UnladenSwallow (talk) 18:45, 1 June 2024 (UTC)
Placement of ISSN in Citation Style 1I'm seeking clarification on the placement of the ISSN parameter in {{cite journal}}. Specifically, what are the arguments for displaying the ISSN after the DOI and other article identifiers, rather than directly after the journal name? For context, the ISSN is an identifier for the journal as a whole, not the individual article. Here are two examples to illustrate my point:
In Example 1, the ISSN is listed after the DOI, suggesting it is an identifier for the article. In Example 2, the ISSN is placed after the journal name, clearly indicating it is an identifier for the journal. I believe that if we display the ISSN, it should be positioned to reflect that it identifies the journal. This would avoid confusion and provide a clearer reference structure. Alternatively, we could consider not displaying the ISSN at all in citations. What are the current reasons for the existing placement of the ISSN, and would it be possible to revise the format for better clarity? Thank you for your input. Jonatan Svensson Glad (talk) 19:21, 5 June 2024 (UTC)
MediaWiki changes to citation parsingJust saw this in "Tech News: 2024-24":
— SMcCandlish ☏ ¢ 😼 15:31, 11 June 2024 (UTC)
CS1 wrapper templates using "mode"Several templates have the same issue with formatting, so I'm posting here. I'll leave a link at the less-watched talk page of each template below. There are many specific-source templates that wrap a CS1/CS2 template. Previously, template formatting could be set with the
Side note: the handful of CS2 map templates like {{Cite gnis2}} have a similar issue, Rjjiii (talk) 16:31, 12 June 2024 (UTC)
Fixed @Rjjiii: I created Module:Citation mode which suppresses a mode argument when {{CS1 config}} is set. I edited all of the templates you listed, above, to call the module for the mode argument that they pass to their inner {{Citation}} template. For a simple example of usage, see {{cite gnis2}}. I'm not seeing any changes in the overriden-setting tracking category: I suspect that the current members of that category are caused by some other problem. Feel free to use Module:Citation mode or let me know if you see any problems. — hike395 (talk) 12:58, 13 June 2024 (UTC)
url-status requestI came across a case where an legitimate article was archived at archive.org. The original article was subsequently moved to a different website with a completely different path, and the original website (about.com) became black-listed by wikipedia (assuming unfit for citation). Shouldn't we have parameter "url-status = moved", or something like that to reflect what happened? Because the other parameters don't seem to apply (the new site isn't dead or unfit, or usurped), and "live" would apply, except that the archived link no longer matches the live link because of the move. Dhrm77 (talk) 18:45, 14 June 2024 (UTC)
Regarding archive dates parsed from URLs in Cite web template(s)Not sure if this is the correct place for a suggestion for the template. I am not comfortable with sending edit requests for templates (yet), so I figured I'd put it here. If you insert an archive link into web templates, such as https://web.archive.org/web/20240615012051/http://example.com/, you can see in the url in the highlighted area that the date is present in the url. Given so, why is the archive date field required when the date is provided through the url? If you input the wrong date into the template, a mismatch error is thrown and it shows the correct date. If it knows the correct date, why not correct the error? I am aware that not all archiving services provide the date handily in the url, but since the Internet Archive is the largest one, can't the template make an exception for the Archive? I know it's not a huge deal, but it is still another thing to type and check. Sorry if I'm not making very much sense, I am still learning about how all of this works. Thank you. EatingCarBatteries (contributions, talk) 05:56, 16 June 2024 (UTC) Whitespace in `CS1 config` and `bots`I'm not quite clever enough to figure out how Sub-titles, numeration, parts and |
Wikitext | {{cite speech
|
---|---|
Old | Smith, Adam (July 7, 2024). Title (Speech). Event. Location. https://www.example.com. |
Live | Smith, Adam (July 7, 2024). Title (Speech). Event. Location. {{cite speech}} : Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)
|
|transcript=Transcript Title
to your example so that |transcript-url=
would have something to link if it did work.- The
|transcript=
parameters are supported by{{cite av media}}
and{{cite episode}}
. - —Trappist the monk (talk) 18:28, 7 July 2024 (UTC)
- It appears on Template:Cite speech though!
- Besides, even if this parameter isn't supposed to work, shouldn't we add it? It could be very useful. Amayorov (talk) 19:05, 7 July 2024 (UTC)
- If you mean the mentions in Template:Cite speech § Deprecated, you will find that mention in every cs1|2 template (Template:Cite book § Deprecated, Template:Cite journal § Deprecated, etc). The mention is supposed to convey the fact that support for the unhyphenated
|transcripturl=
has been withdrawn globally. Nearly a year later, that table will be emptied at the next module suite update when support for|authors=
is withdrawn. - —Trappist the monk (talk) 19:14, 7 July 2024 (UTC)
- I see, thanks! Amayorov (talk) 22:40, 7 July 2024 (UTC)
- If you mean the mentions in Template:Cite speech § Deprecated, you will find that mention in every cs1|2 template (Template:Cite book § Deprecated, Template:Cite journal § Deprecated, etc). The mention is supposed to convey the fact that support for the unhyphenated
"Wikipedia:Lua cites" listed at Redirects for discussion
The redirect Wikipedia:Lua cites has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 July 8 § Wikipedia:Lua cites until a consensus is reached. Nickps (talk) 13:48, 8 July 2024 (UTC)
Nomination for deletion of Module:Citation
Module:Citation has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Nickps (talk) 16:01, 8 July 2024 (UTC)
- Actually I nominated for redirection rather than deletion. There is no such TfD notice template though. Nickps (talk) 16:03, 8 July 2024 (UTC)
year parameter
cs1|2 is somewhat schizophrenic when validating |year=
. If I write:
{{cite book |title=Title |year=August 2023}}
→ Title. August 2023.{{cite book}}
: CS1 maint: year (link)
no error even though 'August 2023' is not a 'year'. But, if I write:
{{cite book |title=Title |year=August 2023 |date=August 2023}}
→ Title. August 2023.{{cite book}}
: Check date values in:|year=
(help)CS1 maint: date and year (link) CS1 maint: year (link)
there is an error message because 'August 2023' is not a 'year'.
I propose to add a maintenance category to identify cs1|2 templates that have |year=
where the assigned value is not YYY
, YYYY
, their circa forms, year-only ranges, and with or without CITEREF
disambiguators. To make cs1|2 consistent in how it validates |year=
I propose that we define |year=
so that it may only hold one of the year formats named above. To accomplish that, we need to know where noncompliant |year=
year parameters exist so that they may be repaired before a fix is made in Module:Citation/CS1/Date validation. The category is necessary because there are a so many non-cs1|2 templates that use |year=
that Cirrus searching is woefully inadequate.
Yea or nay?
—Trappist the monk (talk) 15:53, 29 June 2024 (UTC) 13:24, 30 June 2024 (UTC) (modified)
- How should a range,
|year=2020–2022
, be treated? -- Michael Bednarek (talk) 01:03, 30 June 2024 (UTC)- That would need to be allowed. Kanguole 11:55, 30 June 2024 (UTC)
- Literalist as I have been accused of being, year to me means just that. Year range is a date so
|date=2020–2022
. Clearly there will be whining about this so I have modified the proposed definition of|year=
. - —Trappist the monk (talk) 13:24, 30 June 2024 (UTC)
- This matches a rationale for keeping both
|date=
and|year=
explained at Help talk:Citation Style 1/Archive 31#Preference between year or date parameter in Cite Journal. Two editors mention using|year=
to discourage future editors/bots from changing "YYYY" to something like "January YYYY" arbitrarily. Rjjiii (talk) 07:27, 30 June 2024 (UTC) - Support as maintenance category; oppose as error category. I don't think that a new CS1 error is being proposed here, but for clarity. Folly Mox (talk) 12:50, 30 June 2024 (UTC)
- Initially a maintenance category. Once that category is cleared, it goes away, the fix is made to Module:Citation/CS1/Date validation, and thereafter, noncompliant
|year=
parameters become errors categorized in the already existing Category:CS1 errors: dates. - —Trappist the monk (talk) 13:24, 30 June 2024 (UTC)
- Sounds fair. Folly Mox (talk) 14:13, 30 June 2024 (UTC)
- Initially a maintenance category. Once that category is cleared, it goes away, the fix is made to Module:Citation/CS1/Date validation, and thereafter, noncompliant
- I have tweaked the sandbox. The examples below are variations on this theme:
{{cite book/new |title=Title |year=900}}
|year=900
(ok):- Title. 900.
|year=c. 900
(ok):- Title. c. 900.
|year=c. 900a
(ok):- Title. c. 900a.
|year=1900
(ok):- Title. 1900.
|year=900–1000
(ok):- Title. 900–1000.
|year=1951–52
(ok):- Title. 1951–52.
|year=August 1900
(not ok because month is not a year):|year=Winter 1951–52
(not ok because season is not a year)::|year=April–May 1900
(not ok because month range is not a year):- —Trappist the monk (talk) 16:28, 12 July 2024 (UTC)
- I feel like "c." constructs should authomatically use {{circa}} to explain the notation, especially since
{{cite book/new |title=Title |year={{circa}} 900}}
- Title. c. 900.
{{cite book}}
: Check date values in:|year=
(help)CS1 maint: year (link) - produces an error. IceWelder [✉] 19:43, 12 July 2024 (UTC)
- {{circa}} is bad for accessibility (mobile readers can't hover) in addition to polluting the metadata. c. 900 is pretty widely understood as an approximate date. Folly Mox (talk) 22:17, 12 July 2024 (UTC)
Volume in bold
"Volume values that are wholly digits, wholly uppercase Roman numerals, or fewer than five characters will appear in bold." Why is bold text used in these cases? - BobKilcoyne (talk) 05:47, 30 June 2024 (UTC)
- That's true for e.g. {{cite journal}}, and not true for e.g. {{cite periodical}}, {{cite encyclopaedia}}, {{cite book}}.I don't remember which published academic citation style guides recommended bolding the volume number, but it does a good job of setting it apart from the issue number and visually separating the citation. I feel like we had a discussion here about this just last year at least. I'll see if I can locate it in the archives for you. Folly Mox (talk) 13:03, 30 June 2024 (UTC)
- Well, I wasn't able to locate the discussion I was remembering, but see for example:Short answer I guess is that a lot of people talked it through over the years and it got consensus. Folly Mox (talk) 13:21, 30 June 2024 (UTC)
- Help talk:Citation Style 1/Archive 50 § When |volume= is a Roman Numeral (2018)
- Help talk:Citation Style 1/Archive 62 § Bolding of the volume number (2020)
- Help talk:Citation Style 1/Archive 77 § Journal volume in Bold (2021)
- Help talk:Citation Style 1/Archive 79 § Still an issue with book volumes (2021)
- This seems like a reasonable style for citation output in the form "63 (7): 43–51", but a) we really have reason to do that at all, since WP:NOTPAPER and we have no reason to compress space; and b) "vol. 63, no. 7, pp. 43–53" (or "Vol." and "No." if one insists on capitalizing those things) is much clearer. It's also a format in which the boldfacing would serve no purpose. That is, the boldfacing only serves a disambiguating purpose for a format that we have no reason to use and a good reason not to. — SMcCandlish ☏ ¢ 😼 00:48, 2 July 2024 (UTC)
- This, exactly. I consistently use {{cite magazine}} even when citing traditional academic journals just to get away from the compressed format of {{cite journal}}. Imzadi 1979 → 04:18, 2 July 2024 (UTC)
- I support switching to an explicit style. — UnladenSwallow (talk) 04:26, 13 July 2024 (UTC)
- I oppose switching to a single style for both academic journals and popular periodicals. Having 30 (2) for journals and Vol. 30 no. 2 for magazines lets me tell at a glance what kind of publication I'm looking at in the reference list. Additionally, if we were to adopt a single style, I'd argue for the other direction, since bolded text is easier to distinguish amongst an information dense morass of a citation than a couple abbreviations prepending two of possibly a half dozen or more numeric strings. Folly Mox (talk) 14:57, 13 July 2024 (UTC)
- If not using paper meant space was no longer an issue, we'd be using "volume", "number" and "pages" instead of "vol.", "no." and "pp.". Many screens are smaller than pages, and readers are still human, so the old ergonomic factors still apply. Kanguole 15:33, 13 July 2024 (UTC)
cite magazine should support |agency
The cite magazine template should support the |agency parameter - for example this article https://www.golfdigest.com/story/golf-hope-ap should be cited as "Vegas Hangs On". Golf Digest. Associated Press. January 23, 2011. - but that throws an error. Some magazines do use news agencies so this should be a supported parameter. Tewapack (talk) 19:39, 2 July 2024 (UTC)
- Tewapack, lateness of reply acknowledged, but how is this source not a case for {{cite news}}? Granted it's hosted by Golf Digest, but nothing on the page indicates it was published as a story in any issue of their periodical. It appears just to be a wire story that they reprinted online. I'd probably go with
{{cite news |url= https://www.golfdigest.com/story/golf-hope-ap |title= Vegas Hangs On |work= Golf Digest | date= January 23, 2011 |agency= Associated Press}}
Folly Mox (talk) 16:13, 13 July 2024 (UTC)
External link indicator
In a conversation at Template talk:Internet Archive#Registration required parameter it was pointed out that {{Cite book}} does not produce an external link indicator for a title URL if |url-access=
is specified:
- Bloggs, Joe. Book of Bloggs.
- Bloggs, Joe. Book of Bloggs.
What's the rationale? -- Michael Bednarek (talk) 14:26, 7 July 2024 (UTC)
- If there was any discussion to explicitly overwrite the external link icon, I don't recall it. You might find your answer somewhere in the archives. I think the first discussion in a rather long chain of discussions might be at Help talk:Citation Style 1/Archive 13 § Open access icon.
- If I had to guess, I would say that we opted to do as MediaWiki does with external links to pdf documents:
[https://example.com/document.pdf A PDF Document]
→ A PDF Document
- —Trappist the monk (talk) 14:57, 7 July 2024 (UTC)
- Seems fine. Having links cluttered with an icon that means "this is an ext. link" followed by another that means "this is an external link to which X access conditions apply" would be redundant and annoying. — SMcCandlish ☏ ¢ 😼 11:07, 14 July 2024 (UTC)
Doesn't play well with {{ill}}
I tried to use {{ill}} inside a {{cite journal}}, like this:
* {{cite journal |author={{ill|Reinhold Merkelbach|de|Reinhold Merkelbach}} |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}
But that currently renders without any wikilink, like this:
- Reinhold Merkelbach"Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16.
{{cite journal}}
: Check|author=
value (help)CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link) (1989).
Is this bad interaction fixable by someone who knows about templates? --Quuxplusone (talk) 14:46, 6 July 2024 (UTC)
- You'll want to use
|author-link=:de:Reinhold Merkelbach
, which has the desired effect. Folly Mox (talk) 14:49, 6 July 2024 (UTC) - Not fixable. When expanded, your example
{{ill}}
produces this:[[Reinhold Merkelbach]]<span class="noprint" style="font-size:85%; font-style: normal; "> [[[:de:Reinhold Merkelbach|de]]]</span>
|author=
wants to see only a single name (which may be wikilinked) but it certainly does not want to see the styling that{{ill}}
adds.- One other way to wikilink the author's name is:
|author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]]
- —Trappist the monk (talk) 15:06, 6 July 2024 (UTC)
- Hm, that's too bad. I'm not a fan of unmarked wikilinks to non-English Wikipedias, so the suggestion to mark it up as Reinhold Merkelbach (via
author-link
or otherwise) is right out. I'll leave it as-is for now, but I hope this can be fixed someday. (For example, by finding whatever innards of theauthor
field currently "want[] to see only a single name (which may be wikilinked)" and whitelisting {{ill}} as a valid possibility there, too.) --Quuxplusone (talk) 17:39, 6 July 2024 (UTC)- Not going to happen. cs1|2 annotates interwiki-linked author names so that readers can see that the interwiki-linked author name is at a non-English Wikipedia:
{{cite journal |author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}
- Reinhold Merkelbach [in German] (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16.
- —Trappist the monk (talk) 17:54, 6 July 2024 (UTC)
- I understand the reasons for the behaviour by the citation templates. However, this construction,
[[:xx:Name]]
, will AFAIK forever prevent those links to be automatically converted to a local link if an article for that author gets written here. I wonder if this could be improved if the templates added a tracking category in those cases (in article space only) so that User:Cewbot's task #1, run by User:Kanashimi, has a way of locating this usage. -- Michael Bednarek (talk) 00:54, 7 July 2024 (UTC)- The bot can only handle interlanguage templates. Sorry it can't handle links to other language wikipedias, that would require quite a bit of extra work. Kanashimi (talk) 02:38, 7 July 2024 (UTC)
- A tracking category for interwiki links in templated citation authors could still be useful for others to check. —David Eppstein (talk) 04:09, 7 July 2024 (UTC)
- In the sandbox, interwiki-linked and interproject-linked names (author, editor, etc) will be categorized in one of two new properties categories. When both project and language are part of the link prefix, only the project will be categorized; this is in keeping with the rendered annotation. Using the example above, copy one (or both) of these to someplace in mainspace (necessary because prop cats are suppressed here), edit and preview (do not save):
{{cite journal/new |author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}
{{cite journal/new |author=Reinhold Merkelbach |author-link=:d:Q972677 |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}
- At the bottom of the mainspace article you will see two red-linked categories:
- Articles in those categories will be sorted by the interwiki or interproject prefix.
- Keep? Discard?
- —Trappist the monk (talk) 17:41, 13 July 2024 (UTC)
- A safer test is to copy the templates to the 'Input wikitext' box at Special:ExpandTemplates. Then click OK. Redlinked cats at the bottom of the page.
- —Trappist the monk (talk) 17:49, 13 July 2024 (UTC)
- In the sandbox, interwiki-linked and interproject-linked names (author, editor, etc) will be categorized in one of two new properties categories. When both project and language are part of the link prefix, only the project will be categorized; this is in keeping with the rendered annotation. Using the example above, copy one (or both) of these to someplace in mainspace (necessary because prop cats are suppressed here), edit and preview (do not save):
- A tracking category for interwiki links in templated citation authors could still be useful for others to check. —David Eppstein (talk) 04:09, 7 July 2024 (UTC)
- The bot can only handle interlanguage templates. Sorry it can't handle links to other language wikipedias, that would require quite a bit of extra work. Kanashimi (talk) 02:38, 7 July 2024 (UTC)
- I understand the reasons for the behaviour by the citation templates. However, this construction,
- Not going to happen. cs1|2 annotates interwiki-linked author names so that readers can see that the interwiki-linked author name is at a non-English Wikipedia:
- Hm, that's too bad. I'm not a fan of unmarked wikilinks to non-English Wikipedias, so the suggestion to mark it up as Reinhold Merkelbach (via
"cs1|2 annotates interwiki-linked author names so that readers can see that the interwiki-linked author name is at a non-English Wikipedia" — Oh, that's awesome! I recommend tweaking the formatting just a little bit, so that instead of displaying as "Reinhold Merkelbach [in German]" it would display as "Reinhold Merkelbach [de]". (That's trivial, and would also address Michael Bednarek's defect report.) And then perhaps instead of making the user have to know to type [[:de:Thing|Thing]], permit them to type {{ill|Thing|de|Thing}}. That would have the effect of accomplishing what I'm looking for, as a very small modification of what you've already implemented. --Quuxplusone (talk) 17:41, 7 July 2024 (UTC)
- The implementing discussion may explain to you why we did not do what you want us to do: Help talk:Citation Style 1/Archive 86 § author-link=interlanguage
- —Trappist the monk (talk) 18:00, 7 July 2024 (UTC)
Keep? Discard?
+1 for 'keep'. -- Michael Bednarek (talk) 03:00, 14 July 2024 (UTC)
I have to think that, for metadata purposes, it would be much cleaner to do this:
{{cite journal |last=Merkelbach |first=Reinhold |author-link=de:Reinhold Merkelbach |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |date=1989 |pages=15–16 |url= https://www.jstor.org/stable/20187001}}
But for some reason this is mis-rendered, presumably due to some questionably desirable pre-filtering of the value of |author-link=
:
- Merkelbach, Reinhold (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16.
{{cite journal}}
: Check|author-link=
value (help)
This:
{{cite journal |last=Merkelbach |first=Reinhold |author-mask=[[de:Reinhold Merkelbach|Merkelbach, Reinhold]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |date=1989 |pages=15–16 |url= https://www.jstor.org/stable/20187001}}
also fails:
- Merkelbach, Reinhold (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16.
{{cite journal}}
: Check|author-mask=
value (help)
Ideally, I would think |author-link=
would be the way to do this, and that it would detect the canonical other-project prefixes (mostly language codes), and do {{ILL}}
-style stuff. Even if that's too much work, then just not barfing on a xx:
language-code prefix would be good, even if does no extra things borrowed from {{ILL}}
and just builds the link the way doing a bare [[de:Reinhold Merkelbach|Merkelbach, Reinhold]]
works outside the template: Merkelbach, Reinhold. — SMcCandlish ☏ ¢ 😼 11:21, 14 July 2024 (UTC)
- You are mistook:
[[de:Reinhold Merkelbach|Merkelbach, Reinhold]]
→ Merkelbach, Reinhold
- works in this namespace but does not work in mainspace because the above markup is for adding interwiki links to the languages menu. Prove it to yourself by editing a page that does not list Deutsch in the languages menu (USS Will Rogers is one such). Edit and paste the above wikitext into the article and preview. Deutsch will be listed in the languages menu but Merkelbach will not be found where you inserted the link. This is why your example templates show the Check author-link= value error message. We don't want to be indiscriminately adding links to the languages menu so Module:Citation/CS1 suppresses the malformed author link whether the template wikilinks the
|author=
parameter or uses the|author-link=
parameter; contributor, editor, etc links similarly suppressed. - This is, by the way, discussed at the error message's help link.
- —Trappist the monk (talk) 14:52, 14 July 2024 (UTC)
Numeric author name
- 34 (19 September 2021). "Lane Rasberry". 34Questions. YouTube.
{{cite web}}
:|author1=
has numeric name (help)
The |author1=34
generates a red message. This is how the author signs their name, "34", and the name of the work is 34Questions. Is there a way to express this without a red message? -- GreenC 23:08, 16 July 2024 (UTC)
{{cite av media |author1=((34)) |title=Lane Rasberry |url=https://www.youtube.com/watch?v=gmhsqYsvz-I |publisher=34Questions |via=YouTube |language=en |date=19 September 2021}}
- 34 (19 September 2021). Lane Rasberry. 34Questions – via YouTube.
- —Trappist the monk (talk) 23:14, 16 July 2024 (UTC)
{{Cite paper}} without a journal?
Cite paper redirects to Cite journal. What should be done when the paper in question is a white paper published by a manufacturer, but not part of a journal, and not one of a clear series? It's more of a technical backgrounder on their significant invention. Andy Dingley (talk) 13:50, 14 July 2024 (UTC)
- I use {{Citation}} for this sort of source, but if it's online and you don't need specific page numbers, {{Cite web}} will work. Both templates accept
|series=
. If this is about Paxman Hi-Dyne engines, I'd probably go with {{Cite web}}, since the reproduction of the original via Richard Carr's Paxman History Pages is a human conversion to HTML and the original source is not what was consulted. Folly Mox (talk) 14:39, 14 July 2024 (UTC)- I have a photocopy of the paper copy too, but there's nothing useful on there about a journal as such.
- I know it's pointless on WP, because they're all just redirects, but I do prefer the semantics of marking up journals as journals and papers as papers. Andy Dingley (talk) 14:46, 14 July 2024 (UTC)
- Perhaps one could employ
|type=White paper
? Remsense诉 15:42, 14 July 2024 (UTC)
- Perhaps one could employ
- (edit conflict)
but if it's online and you don't need specific page numbers
Do you mean to suggest that{{cite web}}
does not support the pagination parameters? If you do then you are mistook:- —Trappist the monk (talk) 15:43, 14 July 2024 (UTC)
- Is {{cite report}} appropriate here? — Jts1882 | talk 15:34, 14 July 2024 (UTC)
- Thanks, that seems like the best fix. Andy Dingley (talk) 19:55, 14 July 2024 (UTC)
- While we're here: is this also ideal for standards documents? Remsense诉 20:07, 14 July 2024 (UTC)
- {{cite standard}} exists. Izno (talk) 23:31, 17 July 2024 (UTC)
Please fix: the limited mouseover for url-access is too specific
Some web servers refuse access as a way of avoiding having to respect the GDPR. This is especially the case for some US-based servers - presumably the idea that ordinary people might have the right to privacy is too radical to some newspapers. See this example for an archiver, in which case the archiver was presumably a server located outside of the US. Maybe there are similar cases for some Russian and Chinese servers that refuse access to people who can't be tracked.
Our current option limited for url-access for {{web cite}} gives the mouseover text Free access subject to limited trial, subscription normally required
, which is misleading for web servers that require privacy violation. The alternatives registration and subscription are misleading for this case too.
We need to either:
- add a fourth option, e.g. geolimited with mouseover text
Access forbidden to some geographical locations
; or - change the limited text to something more generic such as
Free access in some cases
.
This will require an extension or correction (respectively) to
['registration'] = {class='id-lock-registration', title='Free registration required'}, ['limited'] = {class='id-lock-limited', title='Free access subject to limited trial, subscription normally required'}, ['subscription'] = {class='id-lock-subscription', title='Paid subscription required'},
in Module:Citation/CS1/Configuration by someone with editing access. Boud (talk) 11:35, 16 July 2024 (UTC)
Possibly related discussions:
- Help talk:Citation Style 1/Archive 62#Request for new url-access_value(s) - Dec 2019/Jan 2020
- Help talk:Citation Style 1/Archive 74#Intent of url-access=limited - Jan 2021
Neither of these seem to mention the geo-related access-only-with-privacy-violation issue. The GDPR officially became active in 2018 and my feeling is that US geo restrictions were implemented by some US newspapers quite rapidly. But it seems like this issue hasn't been discussed earlier. Boud (talk) 11:45, 16 July 2024 (UTC)
- See Help talk:Citation Style 1/FAQ. This is not going to be done, and it is a misuse of these parameters to specify that a geo-limitation is enforced on the URL. Izno (talk) 23:30, 17 July 2024 (UTC)
MNRAS is open access
This would cover DOI patterns
- 10.1093/mnras
- 10.1111/j.1365-2966
- 10.1046/j.1365-8711
Is is possible to implement those? Headbomb {t · c · p · b} 02:44, 17 July 2024 (UTC)
- I presume that you are asking if it is possible to mark dois that match these patterns with the CS1 maint: unflagged free DOI maintenance message. Possible but costly. If we create a list of these sorts of patterns, each pattern must be individually matched against every doi that is not marked with
|doi-access=free
and the doi registrant is not listed as always free. The test for always-free dois does not suffer from this because the free-registrant table is converted from a sequence to an associative array (only occurs once per article rendering). Looking up a doi registrant in the array is quick. - Seems to me that this is a task better suited to some sort of bot.
- —Trappist the monk (talk) 11:46, 17 July 2024 (UTC)
- Why couldn't the others also be converted to an associative array? I know with regex, it's rather trivial to match those (e.g. 10\.1093\/mnras). The reason why this would be desirable is that it's rather trivial to find something like insource:/10\.1046\/j\.1365-8711/, but it's close to impossible, if not impossible to find which citations aren't marked with
|doi-access=free
. And with ~7000 articles citing MNRAS, it's extremely inefficient to do Citation bot runs in the hopes of catching stragglers. Headbomb {t · c · p · b} 12:24, 17 July 2024 (UTC)- Extracting the doi registrant from a doi prefix is easy because the registrant is always delimited by
10.registrant/
so in regex:registrant = 10\.([^\/]+)\/
. To determine if that registrant is free-to-read, we simply index into the known-free associative array:is_free = known_free_doi_registrants_t[registrant]
. it's rather trivial to match those (e.g. 10\.1093\/mnras)
. True, but every doi in the article must be tested like that. And if not found, we then have to test every doi in the article with10\.1111\/j\.1365-2966
. And if not found, we then have to test every doi in the article with10\.1046\/j\.1365-8711
.- The portions of the doi suffixes that you name above are not fixed length and aren't delimited by always-known delimiting characters so each doi must be tested against each pattern.
- —Trappist the monk (talk) 14:19, 17 July 2024 (UTC)
- If we create an associative array where the registrant is the index and the value is a sequence of unique doi suffix incipits then it is simple to test each registrant without having to test each doi suffix. So, if the array looks like this:
local extended_registrants_t = { -- known free registrants identifiable by the doi suffix incipit ['1046'] = {'j.1365-8711'}, -- MNRAS ['1093'] = {'mnras'}, -- MNRAS ['1111'] = {'j.1365-2966'}, -- MNRAS }
- So, for registrant
1234
not a known registrant and not an extended registrant no further testing required. Registrant5320
is a known free-to-read registrant so if no|doi-access=free
add the maint cat. Registrant1093
is an extended registrant so for each value in its associated sequence, do a string find for that value. If found and no|doi-access=free
add the maint cat. Still slower but not so bad as I was thinking it would be. {{cite journal/new |title=Title |journal=Journal |doi=10.1093/mnras/summat}}
- "Title". Journal. doi:10.1093/mnras/summat.
{{cite journal}}
: CS1 maint: unflagged free DOI (link)
- "Title". Journal. doi:10.1093/mnras/summat.
{{cite journal/new |title=Title |journal=Journal |doi=10.1111/j.1365-2966.summat}}
- "Title". Journal. doi:10.1111/j.1365-2966.summat.
{{cite journal/new |title=Title |journal=Journal |doi=10.1046/j.1365-8711.summat}}
- "Title". Journal. doi:10.1046/j.1365-8711.summat.
- —Trappist the monk (talk) 16:12, 17 July 2024 (UTC)
- Why not just test for "1046/j.1365-8711" directly? Anyway, if the above works, we have a way of tagging specific open access journals, when the DOI patterns are journal-specific. Headbomb {t · c · p · b} 20:44, 17 July 2024 (UTC)
- I already answered that question. If I did not explain it clearly enough, tell me what it is that you don't understand.
- —Trappist the monk (talk) 22:02, 17 July 2024 (UTC)
- Why not just test for "1046/j.1365-8711" directly? Anyway, if the above works, we have a way of tagging specific open access journals, when the DOI patterns are journal-specific. Headbomb {t · c · p · b} 20:44, 17 July 2024 (UTC)
- Extracting the doi registrant from a doi prefix is easy because the registrant is always delimited by
- Why couldn't the others also be converted to an associative array? I know with regex, it's rather trivial to match those (e.g. 10\.1093\/mnras). The reason why this would be desirable is that it's rather trivial to find something like insource:/10\.1046\/j\.1365-8711/, but it's close to impossible, if not impossible to find which citations aren't marked with
Access dates
I request making parameter access-date to be used if there is a DOI or a PMID. Currently an error appears with an access date parameter without a URL, meaning the "|access-date=2015-02-11" part has to be in an HTML comment outside of the template (cf., inter alia, Desmarestiales).
Having no need for a URL for an access date to be used helps when one uses a book (or a book chapter, if the book is there but some chapters are not) or a journal article that is not accessible online, for it was not uploaded.
An alternative solution would be to have a URL or a DOI, or a HDL, or a PMCID, or a PMID to be required to make the access date able to be used. Alfa-ketosav (talk) 08:34, 22 July 2024 (UTC)
- These would be completely pointless. doi:10.1086/392675, for example, will always refer to a paper published in March 1999. That you read it on January 4, 2014, March 28, 2022, or July 1, 2024, is completely inconsequential. Same for all other identifiers. Headbomb {t · c · p · b} 09:00, 22 July 2024 (UTC)
- Alfa-ketosav,
|access-date=
is intended only for sources whose content is likely to change over time, so people can locate the cited version in archives. Stable identifiers point to content that doesn't change. What do you feel the benefit is to adding this datum to stable sources? Folly Mox (talk) 10:55, 22 July 2024 (UTC)- If the URLs DOIs point to change, or a journal's website shuts down, it may be possible that a DOI breaks, even if only for a short time. Alfa-ketosav (talk) 11:18, 22 July 2024 (UTC)
oclc, issn, & eissn identifier prefixes
Editor Uzume, where is the discussion about these changes?
—Trappist the monk (talk) 11:23, 25 July 2024 (UTC)
- @Trappist the monk: right here, apparently. —Uzume (talk) 11:26, 25 July 2024 (UTC)
- Nothing happens here without we discuss it. Please justify these changes. To me, the current url prefixes are easier for human readers to interpret, especially the prefix for OCLC. The current prefix clearly indicates what the worldcat url points to:
https://www.worldcat.org/oclc/
can easily be read by humans as an OCLC identifier url;https://search.worldcat.org/title/
cannot. - Is there any indication from worldcat that the current prefixes are about to become unsupported?
- —Trappist the monk (talk) 11:52, 25 July 2024 (UTC)
- @Trappist the monk: I would be curious what documentation you might find on the subject. As far as I know there is no indication that the current prefixes will continue to be supported either but they do still work for the time being. —Uzume (talk) 14:35, 25 July 2024 (UTC)
- You are the editor who wants this change so the burden of demonstrating its necessity falls to you.
- For a bit of history of the OCLC prefix:
- 2006-09-12: included in
{{OCLC}}
at the creation of that template (http://worldcat.org/oclc/
) - 2012-08-27: introduced to Module:Citation at this edit (as protocol relative
//www.worldcat.org/oclc/
) - 2013-02-19: included in Module:Citation/CS1 at the creation of that module (also protocol relative)
- 2013-04-07: moved to Module:Citation/CS1/Configuration at this edit (also protocol relative)
- 2023-02-09: switched from protocol relative to https scheme at this edit (
https://worldcat.org/oclc/
)
- 2006-09-12: included in
- I acknowledge that past performance is no predictor of future existence. I wonder how often worldcat's internal remapping of the OCLC urls has changed in the 18 or so years since en.wiki started linking to that service.
- —Trappist the monk (talk) 16:34, 25 July 2024 (UTC)
- @Trappist the monk: I do not want the change but change has a way of always coming whether we want it or not. I think the burden is on OCLC but at some point we will likely have to deal with changes at WorldCat. Feel free to delay it or ignore it. I was just trying to get ahead of what might break in the future. I took the time to make the changes. If people want to throw them away I do not mind. —Uzume (talk) 17:23, 25 July 2024 (UTC)
- @Trappist the monk: I suppose the biggest argument for such links is that if one goes to such a record, e.g.,
{{OCLC search link|22239204}}
→ 22239204 (and yes, @Folly Mox the template is called "OCLC search link" so it is a search), then that page has a button for sharing a link to the record and from there, an item entitled "Copy link" which presumably is the link WorldCat recommends people use. And that yields: https://search.worldcat.org/en/title/22239204, providing the link prefix ofhttps://search.worldcat.org/en/title/
before the identifier to be linked to. So, perhaps I failed to get the URL correct and did not specify the "en" English UI (I tested and links like https://search.worldcat.org/ja/title/22239204 link to the same record with a Japanese UI). Please feel free to update the link prefixes appropriately. Incidentally, that very same record also has a "show more information" link that provides more information and within that it links to the "Online version" of the represented item. That link points to https://search.worldcat.org/search?q=no:701649298 providing a means to get to items via their search query. Perhaps you'd prefer that link prefix ashttps://search.worldcat.org/search?q=no:
for OCLC searches directly aligns with the linkprefix https://search.worldcat.org/search?q=n2:
for ISSN searches. —Uzume (talk) 21:35, 25 July 2024 (UTC)
- @Trappist the monk: I would be curious what documentation you might find on the subject. As far as I know there is no indication that the current prefixes will continue to be supported either but they do still work for the time being. —Uzume (talk) 14:35, 25 July 2024 (UTC)
- I don't think it makes sense for an identifier to link to a
search
. Jmo. Folly Mox (talk) 14:17, 25 July 2024 (UTC)- I've reverted the recent changes to identifier templates and infoboxes pending the outcome of this discussion Headbomb {t · c · p · b} 14:29, 25 July 2024 (UTC)
- @Headbomb: Your powers of reversion are amazing as always. Incidentally, at least with respect to ISSN, the change to use a search URL was discussed at Template talk:ISSN#Change request, requested by an editor without an account (IP user) and made by @MSGJ with 415549762 back in 2011-02-23 (more than 13 years ago at the time of this writing). —Uzume (talk) 16:19, 25 July 2024 (UTC)
- @Headbomb: Perhaps you'd prefer moving to issn.org as per your 942292297 in Feb 2020. I think that is a great idea. —Uzume (talk) 17:36, 25 July 2024 (UTC)
- @Headbomb: Your powers of reversion are amazing as always. Incidentally, at least with respect to ISSN, the change to use a search URL was discussed at Template talk:ISSN#Change request, requested by an editor without an account (IP user) and made by @MSGJ with 415549762 back in 2011-02-23 (more than 13 years ago at the time of this writing). —Uzume (talk) 16:19, 25 July 2024 (UTC)
- @Folly Mox: Why not? When you select such a link you are searching their federated union catalogue for that identifier (either their OCLC control number/WorldCat title ID or an ISSN). —Uzume (talk) 14:44, 25 July 2024 (UTC)
- I understand that https://www.worldcat.org/oclc/identifier resolves to https://search.worldcat.org/title/identifier, but as Trappist said above, humans might parse it differently on sight. For me personally, it gives the feeling that we don't actually know the OCLC identifier, and to people unfamiliar with the system entirely, they might not make the connexion between
search.worldcat.org
and OCLC. I don't feel particularly strongly about this, and have no opinion whatsoever about the ISSN bits, since I rarely include them and never click through on them. Folly Mox (talk) 22:10, 25 July 2024 (UTC)
- I understand that https://www.worldcat.org/oclc/identifier resolves to https://search.worldcat.org/title/identifier, but as Trappist said above, humans might parse it differently on sight. For me personally, it gives the feeling that we don't actually know the OCLC identifier, and to people unfamiliar with the system entirely, they might not make the connexion between
- I've reverted the recent changes to identifier templates and infoboxes pending the outcome of this discussion Headbomb {t · c · p · b} 14:29, 25 July 2024 (UTC)
- Nothing happens here without we discuss it. Please justify these changes. To me, the current url prefixes are easier for human readers to interpret, especially the prefix for OCLC. The current prefix clearly indicates what the worldcat url points to:
"cite proceedings" ignores issue
I wanted to cite this: http://www.rafmuseum.org.uk/documents/Research/RAF-Historical-Society-Journals/Journal-11-Sir%20Frank-Cooper-on-Air-Force-Policy-in-the-1950s-1960s.pdf ("THE PROCEEDINGS OF THE ROYAL AIR FORCE HISTORICAL SOCIETY, Issue No 11"), but {{cite proceedings}}
ignores the |issue=
parameter. The only supported parameter seems to be |volume=
, but it unconditionally adds "Vol." and complains "|volume= has extra text" about anything that is not a plain digital number. Can the proper output be achieved using currently existing templates, or {{cite proceedings}}
needs to be modified (then please do)? — Mikhail Ryazanov (talk) 18:10, 25 July 2024 (UTC)
- Use cite journal. Cite proceedings is for conference proceedings. Headbomb {t · c · p · b} 18:37, 25 July 2024 (UTC)
{{cite journal}}
requires both|title=
and|journal=
, but I need to cite the whole publication. And it's not a journal issue but really proceedings from their symposium (which "in modern usage, [means] an academic conference or meeting, such as a scientific conference"). — Mikhail Ryazanov (talk) 21:06, 25 July 2024 (UTC)- That looks like a journal with "proceedings" as part of its title (as many journals have), not a proceedings of a conference, to me. You should use cite journal for any paper published within it. It is not generally useful to cite whole issues of journals, but maybe the editorial is what you want to cite. As for the symposium: the editorial makes clear that this issue of this journal is filled with some but not all papers from the symposium. It is not the proceedings of the symposium (a book of all the papers from the symposium). It is an issue of a journal (the proceedings of the society) that happens to contain many but not all papers from a symposium with a different name. —David Eppstein (talk) 21:19, 25 July 2024 (UTC)
{{cite proceedings}}
is a redirect to{{cite conference}}
.{{cite conference}}
is screwy (because no one has ever complained enough?). It will support|issue=
if it also contains|journal=
:{{cite proceedings |title=Title |journal=Journal |volume=XX |issue=4 |conference=Conference}}
- Title. Conference. Journal. Vol. XX, no. 4.
- In the above example,
|title=
should not be italicized. - I agree with Editor David Eppstein except that I think that The Proceedings of the Royal Air Force Historical Society is a periodical rather than a journal. Use either; your call.
- —Trappist the monk (talk) 21:53, 25 July 2024 (UTC)
- My particular example is from Humphrey de Verd Leigh § External links. Here I've tried to format it more reasonably than it was, but it's not clear what exactly was supposed to be cited (Leigh is mentioned directly in at least two different presentations by different authors, but there might be also something else related). RAF Historical Society itself seems to call it a "journal", but at the same time says that "proceedings of each seminar, and the guest speaker’s paper read at each AGM, are published" in it. I don't know how people distinguish "periodical" and "journal", but this one is not very periodic (they had several issues in 1991, then none in 1992, then only this one in 1993, then several in 1994...). — Mikhail Ryazanov (talk) 22:30, 25 July 2024 (UTC)
- The only (very brief) mention of Humphrey de Verd Leigh is in a single paper:
- Paris, Michael (1993). "Flying training in the RFC, 1912–1915: A failure to prepare?" (PDF). Proceedings of the Royal Air Force Historical Society (11): 25–30.
- What reason do you have for insisting on citing the whole issue rather than being more specific? —David Eppstein (talk) 23:30, 25 July 2024 (UTC)
- I'm not insisting and have no reason for that, please read my explanations above. If you know better what to do, just go ahead. — Mikhail Ryazanov (talk) 23:46, 25 July 2024 (UTC)
- I explicitly suggested what to do above: cite the single paper by Paris that mentions the subject, as a journal paper, using the formatting I used. —David Eppstein (talk) 23:50, 25 July 2024 (UTC)
- I'm not insisting and have no reason for that, please read my explanations above. If you know better what to do, just go ahead. — Mikhail Ryazanov (talk) 23:46, 25 July 2024 (UTC)
- The only (very brief) mention of Humphrey de Verd Leigh is in a single paper:
- My particular example is from Humphrey de Verd Leigh § External links. Here I've tried to format it more reasonably than it was, but it's not clear what exactly was supposed to be cited (Leigh is mentioned directly in at least two different presentations by different authors, but there might be also something else related). RAF Historical Society itself seems to call it a "journal", but at the same time says that "proceedings of each seminar, and the guest speaker’s paper read at each AGM, are published" in it. I don't know how people distinguish "periodical" and "journal", but this one is not very periodic (they had several issues in 1991, then none in 1992, then only this one in 1993, then several in 1994...). — Mikhail Ryazanov (talk) 22:30, 25 July 2024 (UTC)
Title format for {{Cite AV media}}
Is there a way to display the title of a work in quotes rather than italics when using {{Cite AV media}}? I can't figure out a way to change the default italic formatting. Lord Bolingbroke (talk) 01:32, 28 July 2024 (UTC)
Enhancement request: add function in CS1 translator to list supported languages
Please add a new function 'list' (or maybe, 'languages') to Module:CS1 translator that returns a list of all the supported languages. My immediate use case is about mentioning this module on a Talk page, and naming the language list, so ideal would be comma-separated, and pre-final 'and': i.e, "Arabic, Chinese, , ... , and Turkish". (That suggests other possible enhancements down the road, including: returning WP (ISO)-prefix codes, or returning one language name given an index number or a WP/ISO code, returning the name if it's supported and empty if it isn't, for use in table-building, or support-checking. I can give a specific case where this would be useful, if interested, on an instruction page for translators.) Thanks, Mathglot (talk) 01:12, 31 July 2024 (UTC)
- If you
[mention] this module on a Talk page
, you could link to it. The module documentation, right at the top, has a table of supported templates with their associated languages (see Module:CS1 translator § Supported templates). If this is too technical, does{{Non-English citation templates}}
answer? - Is there a demonstrable need? This sounds like 'it sure would be nice if someone created thing one in case someday, someone else, might want to do thing two.'
- —Trappist the monk (talk) 13:38, 31 July 2024 (UTC)
- Okay, that'll do. Mathglot (talk) 19:10, 31 July 2024 (UTC)
For two articles in this category, I can't find the red error message:
Normally cntrl-f searching the rendered page for "archive-url" finds it. -- GreenC 23:10, 1 August 2024 (UTC)
- I edited, changed nothing, published: not in category anymore.
- —Trappist the monk (talk) 23:38, 1 August 2024 (UTC)
- Thanks. I did purge, needed null. Never been clear on the difference. -- GreenC 01:49, 2 August 2024 (UTC)
`Cite standard` redirect
{{Cite standard}}
is currently a redirect to {{Cite tech report}}
. I feel this is unideal, as the |type=
specified is unideal when citing standards, which are distinguished from technical reports by many bodies. Would it be a headache to retarget this redirect in a manner that only changes this parameter? Not sure if |type=Standard
or left unset is ideal, but. Remsense诉 23:46, 1 August 2024 (UTC)
- If you don't like the auto-value assigned to
|type=
choose another:|type=Standard
or if that isn't acceptable,|type=none
.{{cite standard |title=Title}}
- Title.
{{cite standard |title=Title |type=Standard}}
- Title (Standard).
{{cite standard |title=Title |type=none}}
- Title.
- —Trappist the monk (talk) 01:00, 2 August 2024 (UTC)
- Of course: my point is that since this would have to be done in each case, I would question the utility of this particular redirect. Remsense诉 01:03, 2 August 2024 (UTC)
- There is no way to cite a standard and have cs1|2 autoset
|type=Standard
(or whatever). You can avoid using{{cite standard}}
and use another cs1|2 template but you will still need to manually set|type=
if you want the template to render a type. If you don't, use a cs1|2 template that doesn't autoset|type=
. Alternately, change{{cite standard}}
from a redirect to a wrapper template around your favorite cs1|2 template and preset|type=
to your preferred value. - —Trappist the monk (talk) 01:14, 2 August 2024 (UTC)
- I was considering the latter, thank you for your expertise! Remsense诉 01:57, 2 August 2024 (UTC)
- There is no way to cite a standard and have cs1|2 autoset
- Of course: my point is that since this would have to be done in each case, I would question the utility of this particular redirect. Remsense诉 01:03, 2 August 2024 (UTC)
- The
|type=
parameter is an alias for|medium=
; repurposing it as|type=standard
precludes using|medium=
. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:29, 2 August 2024 (UTC)
Whitespace workaround for invisible templates redux
Sorry to persist about this, but as stated in this discussion about the issue: invisible templates such as {{Bots}}
and {{CS1 config}}
emit a newline, which is apparently an ancient bug avoided in other widely used templates like {{EngvarB}}
with a <nowiki>...</nowiki>
hack. If it's not liable to create problems, would it be possible to implement this same workaround in {tlx|Bots}} and {{CS1 config}}
for the time being? Remsense诉 00:04, 2 August 2024 (UTC)
- Phabricator: https://phabricator.wikimedia.org/T369520
- And a ping to John of Reading when he returns from vacation; he seems to have come up with the hack here: [7] Rjjiii (talk) 00:16, 2 August 2024 (UTC) Edit: old discussion at VPT 00:19, 2 August 2024 (UTC)
- @Rjjiii: That hack should be fine in these templates. I don't have TE rights currently, so cannot make the edits. -- John of Reading (talk) 07:28, 3 August 2024 (UTC)
See section in Module talk:Citation
User:Jon (WMF) has posted a message in Module talk:Citation. Since that page is a redirect, I provided a {{-r}} link to that comment. Nickps (talk) 19:30, 2 August 2024 (UTC)
- The misplaced section has been moved below: #Urgent: Please fix this template for printed content Module:Citation/CS1/styles.css. —andrybak (talk) 22:11, 2 August 2024 (UTC)
- I have already corrected this issue. Izno (talk) 23:09, 2 August 2024 (UTC)
Urgent: Please fix this template for printed content Module:Citation/CS1/styles.css.
Firstly, apologies for writing in English if this is not your first language (this is an automated message).
This template has been detected as one of 436 pages using styles that break the page when printed when the user is using dark mode. The fix is very straightforward - all your styles relating to dark mode must be scoped to. Since there is a high risk of this templates being copied to other wikis it is important this notice is acted on ASAP.
To fix this:
- Update `@media (prefers-color-scheme: dark` to `@media screen and (prefers-color-scheme: dark`
- Wrap any styles relating to `html.skin-theme-clientpref-night` in `@media screen`
If this message has not been acted on in 7 days, this will be fixed by an automated script. Thank you for your help fixing this important issue.
For any questions feel free to ask them at phab:T369874.
Jon (WMF) (talk) 18:22, 2 August 2024 (UTC) on behalf of the web team.
- Done
- Thank you! Jon (WMF) (talk) 01:12, 3 August 2024 (UTC)
Another generic pseudo-author to detect and warn about
"Newsroom" (or "newsroom", "News-room", "news-room", "News Room", "News room", "news room"). I've encounted this in |last=
at least twice in the last month or so. Might need to flag "News" by itself, too, though I guess it's conceivable for someone to be named something like "Janet News". I know for a fact that Room is an extant surname. — SMcCandlish ☏ ¢ 😼 11:01, 14 July 2024 (UTC)
- That reminds me that I keep running into "Company" in
|last=
and was a bit surprised it's not considered a generic name. Aninsource:
search yielded around 1000 hits, including maybe 30% false positives because I didn't want to pound the servers with a regex to escape the=
. A quick scroll through the first 500 results showed a single valid usage as a surname, at Ziphosuchia, with the balance of true positives consisting of publishing companies misparsed by Citoid and pals. Folly Mox (talk) 11:24, 14 July 2024 (UTC)- We might add a test to find only
Company
orcompany
as whole values. If someone cares to check the results of this search if may be possible to loosen the restriction so that the test finds names that includeCompany
orcompany
. Corporate authors are allowed so I don't think that we can error when a name simply includesCompany
orcompany
. - —Trappist the monk (talk) 15:30, 14 July 2024 (UTC)
- Sorry for the inclarity, but yes I meant specifically just
|last=Company
, without involving substring matching. Folly Mox (talk) 21:40, 14 July 2024 (UTC)- User:DreamRimmer has taken care of the largest single offender in this category of error following a request at WP:AWBREQ. A search for
insource:"last Company first"
now returns only around 350 matches, although of course it misses cases where the parameters are in a different order. The one author we cite whose actual human surname is "Company" is cited in at least three articles as it turns out, the other two being Ischyrochampsa and Wanosuchus (I note to myself for future double parentheses). Folly Mox (talk) 00:18, 18 July 2024 (UTC)
- User:DreamRimmer has taken care of the largest single offender in this category of error following a request at WP:AWBREQ. A search for
- Sorry for the inclarity, but yes I meant specifically just
- We might add a test to find only
- Before timing out, this search found ~2040 articles that have
|lastn=
or|authorn=
parameters with values that beginNews
ornews
. When I ran that search, I found: Newsby, Newsinger, Newsom, Newsome, Newstead, Newsum among the first 20 results; some of them multiple times. So our generic name search is limited to finding onlyNews
ornews
as whole values to avoid false positives. - For the others that you name:
- Adding a specific test for
Newsroom
andnewsroom
seems worthwhile; the others, not. - —Trappist the monk (talk) 15:30, 14 July 2024 (UTC)
- Another that you all should look at is
|lastn=Bureau
or|authorn=Bureau
. This search fund about 8300 articles where the assigned value begins withBureau
. Of those about 6680 hold only the wordBureau
. There are authors whose surname isBureau
. - —Trappist the monk (talk) 16:59, 15 July 2024 (UTC)
- Added tests for
bureau
andcompany
as whole values; added test for the various forms ofnewsroom
named in the OP where the word(s) may appear anywhere in the parameter value:{{cite book/new |title=Title |last=Bureau}}
→ Bureau. Title.{{cite book}}
:|last=
has generic name (help){{cite book/new |title=Title |last=Bureau}}
→ Bureau drawer. Title.{{cite book/new |title=Title |last=Company}}
→ Company. Title.{{cite book}}
:|last=
has generic name (help){{cite book/new |title=Title |last=Company}}
→ Mega Huge Company. Title.{{cite book/new |title=Title |last=Newsroom}}
→ Newsroom. Title.{{cite book}}
:|last=
has generic name (help){{cite book/new |title=Title |last=News room}}
→ News room. Title.{{cite book}}
:|last=
has generic name (help){{cite book/new |title=Title |last=News-room}}
→ News-room. Title.{{cite book}}
:|last=
has generic name (help){{cite book/new |title=Title |last=The News Room}}
→ The News Room. Title.{{cite book}}
:|last=
has generic name (help)
- —Trappist the monk (talk) 14:03, 22 July 2024 (UTC)
- And one more:
Desk
whole word: - —Trappist the monk (talk) 16:03, 22 July 2024 (UTC)
- And two more:
Group
andLimited
both whole word:{{cite book/new |title=Title |last=Group}}
→ Group. Title.{{cite book}}
:|last=
has generic name (help){{cite book/new |title=Title |last=Group photo}}
→ Group photo. Title.{{cite book/new |title=Title |last=Limited}}
→ Limited. Title.{{cite book}}
:|last=
has generic name (help){{cite book/new |title=Title |last=Limited availability}}
→ Limited availability. Title.
- —Trappist the monk (talk) 14:05, 24 July 2024 (UTC)
- Another worth considering is
correspondent
as the only entry in an author field. Currently 515 occurances. Keith D (talk) 10:33, 27 July 2024 (UTC)- This search suggests rather more than 500 articles with
correspondent
in|authorn=
or|lastn=
: - Added:
- —Trappist the monk (talk) 13:52, 27 July 2024 (UTC)
- This search suggests rather more than 500 articles with
- And another? What about
|last=staff
? Before it times out, this search finds about 19,500 articles where|last=authorn
or|lastn=
is assigned the single valueStaff
orstaff
. Is 19,500+ to much to dump into Category:CS1 errors: generic name (30,475)? Certainly we could write an awb script to remove parameters that are assigned the single valueStaff
. The script must also remove matching|firstn=
when present. - Displaying 'Staff' as an author name seems to me contrary to our past advice where we used to recommended
|author=<!--Staff writer(s); no by-line.-->
which seemed to implicitly suggest that we should not be using 'Staff' as an author name. At this edit in November 2016, pursuant to this discussion we changed the recommended hidden text. It also seems to me that specifically naming 'Staff' as an author doesn't make it any easier for readers to locate a source because that name is too generic.Staff
then amounts to pointless clutter. As an alternate option we could have the awb script convertStaff
to<!--Not stated-->
. This same awb task could also be used to replace<!--Staff writer(s); no by-line.-->
with<!--Not stated-->
. - What do?
- —Trappist the monk (talk) 22:28, 7 August 2024 (UTC)
Requested edit to Module:Citation/CS1/Configuration
This edit request to Module:Citation/CS1/Configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
On line 1179 of Module:Citation/CS1/Configuration/sandbox, I have added 'grc'
to the array script_lang_codes
, so that Ancient Greek can be supported as a script-title
language. Trappist the monk has also added 'ce'
to the same array, for Chechen, which should also be safe to add, but these are not the only changes between the sandbox and the live version of the include, so please copy over the whole array definition from line 1178 to 1183. (Note too that the array includes manual line breaks, so some items have moved onto the following line, compared with the live version; please check that no duplicate values exist in the array before saving.) Thank you! — OwenBlacker (he/him; Talk) 21:11, 3 August 2024 (UTC)
- No need to hurry. The
grc
text is correctly marked up:{{Citation |author=[[Herodian]] |script-title=grc:Τῆς μετὰ Μάρκον βασιλείας ἱστορία |trans-title=History of the Empire from the Death of Marcus |at=[http://www.tertullian.org/fathers/herodian_03_book3.htm#C8 III, 8, 2] |language=grc}}
'"`UNIQ--templatestyles-000000D9-QINU`"'<cite id="CITEREFHerodian" class="citation cs2 cs1-prop-script cs1-prop-foreign-lang-source-2">[[Herodian]], <bdi lang="grc" >Τῆς μετὰ Μάρκον βασιλείας ἱστορία</bdi> [''History of the Empire from the Death of Marcus''] (in Ancient Greek), [http://www.tertullian.org/fathers/herodian_03_book3.htm#C8 III, 8, 2]</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=grc%3A%CE%A4%E1%BF%86%CF%82+%CE%BC%CE%B5%CF%84%E1%BD%B0+%CE%9C%CE%AC%CF%81%CE%BA%CE%BF%CE%BD+%CE%B2%CE%B1%CF%83%CE%B9%CE%BB%CE%B5%CE%AF%CE%B1%CF%82+%E1%BC%B1%CF%83%CF%84%CE%BF%CF%81%CE%AF%CE%B1&rft.pages=III%2C+8%2C+2&rft.au=Herodian&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+95" class="Z3988"></span>
- It is my intention to update all of the cs1|2 suite modules within the next couple of weeks.
- —Trappist the monk (talk) 21:44, 3 August 2024 (UTC)
- Fair enough; I'm certainly in no hurry and had seen that the markup was working. I mainly just wanted to suppress the error message once I spotted it. If you're already on it, then I'll leave you to it. Thank you! 🙂 — OwenBlacker (he/him; Talk) 22:32, 3 August 2024 (UTC)
What would it take for...
Each parameter to be wrapped in a <span class="cs1parameter"></span>?
For example, if we had
- Linden, David van der (23 December 2015). "Coping with crisis. Career strategies of Antwerp painters after 1585". De Zeventiende Eeuw. Cultuur in de Nederlanden in Interdisciplinair Perspectief. 31 (1): 18. doi:10.18352/dze.10126.
That was built something like
- <span class=cs1last>Linden</span>, <span class=cs1first>David van der</span> (<span class=cs1date>23 December 2015</span>). "<span class=cs1title>Coping with crisis. Career strategies of Antwerp painters after 1585</span>". <span class=cs1journal>''De Zeventiende Eeuw. Cultuur in de Nederlanden in interdisciplinair perspectief''</span>. <span class=cs1volume>'''31'''</span> (<span class=cs1issue>1</span>): <span class=cs1pages>18</span>. <span class=cs1doi>{{doi|10.18352/dze.10126}}</span>.
Then people could customize how citation look. Don't want ISSNs to display? hide them with your own CSS tweaks. Don't like last/first order? Rejiggle it to First/Last with CSS. Want "vol./no./p. or pp." to show or not show? CSS tweaks again.
Headbomb {t · c · p · b} 16:47, 5 August 2024 (UTC)
- Adding something like that shouldn't be that hard, but the question is what are the costs for doing so. Would the additional characters cause loading time to increase on large articles? Gonnym (talk) 15:54, 6 August 2024 (UTC)
- This would significantly increase the output of a page using CS1 and likely decrease the number of pages that fit under WP:PEIS. Right now our limit seems to be around 600 references on any given day. Playing with it in a text editor with the full output of the initial example (including the coins), we're looking at an increase from 1090 to 1340 bytes, which is about 23%. On a page with 600 references of a similar size, that take the maximum down to about 480. And for pages where more authors are typical in citations, the ratio would grow pretty significantly (and you wouldn't be able to format the multi-author list without Javascript). I think it'd be neat to do something like this, but I don't think it's in the cards without sacrificing coins, which at least has what I think is a more meaningful benefit to people other than the elite. Izno (talk) 21:23, 9 August 2024 (UTC)
- Would we need COinS if we had this? Headbomb {t · c · p · b} 21:32, 9 August 2024 (UTC)
- Various software consume COinS natively today (notably Zotero). They would need to build adapters of some sort to consume our references marked up like this. Maybe fine for Google who I'm sure uses the data and can adapt at whatever velocity to a change in our output, not so good for the open source and general user community. Izno (talk) 22:09, 9 August 2024 (UTC)
- Would we need COinS if we had this? Headbomb {t · c · p · b} 21:32, 9 August 2024 (UTC)
- This would significantly increase the output of a page using CS1 and likely decrease the number of pages that fit under WP:PEIS. Right now our limit seems to be around 600 references on any given day. Playing with it in a text editor with the full output of the initial example (including the coins), we're looking at an increase from 1090 to 1340 bytes, which is about 23%. On a page with 600 references of a similar size, that take the maximum down to about 480. And for pages where more authors are typical in citations, the ratio would grow pretty significantly (and you wouldn't be able to format the multi-author list without Javascript). I think it'd be neat to do something like this, but I don't think it's in the cards without sacrificing coins, which at least has what I think is a more meaningful benefit to people other than the elite. Izno (talk) 21:23, 9 August 2024 (UTC)
Bad DOI link
Not related to the bot, but people stalking this page could perhaps help me. What should be done with this reference on Bartholomeus de Momper the Elder:
Linden, David van der (2015). "Coping with crisis. Career strategies of Antwerp painters after 1585". De Zeventiende Eeuw. Cultuur in de Nederlanden in Interdisciplinair Perspectief. 31: 18. doi:10.18352/dze.10126.
The link the doi points to is "for sale" and not working. Can mark the doi link as not working/usurped? Jonatan Svensson Glad (talk) 02:39, 5 August 2024 (UTC)
- (talk page stalker) In Special:Diff/1238717754 I marked the DOI inactive using
|doi-broken-date=
, and provided an alternative URL whilst the journal sorts out its DNS registration. Future inquiries of this sort are best handled at Help talk:Citation Style 1, FYI. Kindly, Folly Mox (talk) 09:52, 5 August 2024 (UTC)- Josve05a, fixing ping. Folly Mox (talk) 09:54, 5 August 2024 (UTC)
- The DOI is not broken though. The landing page is usurped. That's a different issue. This should be discussed at Help:CS1. Headbomb {t · c · p · b} 17:00, 5 August 2024 (UTC)
- So, anyone got a solution how to mark a doi-link as usurped? Is that an acceptable input in
|doi-broken-date=
somehow? Jonatan Svensson Glad (talk) 09:04, 9 August 2024 (UTC) - It's true that the DOI is not inactive in the usual sense which leads to a "DOI not found" result at doi.org, but it's not not broken. This is such an unusual situation that I don't think we need a
|doi-status=usurped
or anything.I liked my original solution, but it's true I don't know what bots do with the inactive DOI maintenance categories. Headbomb's removal of the|doi-broken-date=
is worse, since it leaves the broken link in the reference, but rather than reverting I've commented out the DOI for now. I suppose it could be altered to a plaintext field or postscript, so that it's visible to the reader but not linked to the usurped domain. Folly Mox (talk) 11:08, 9 August 2024 (UTC)
- So, anyone got a solution how to mark a doi-link as usurped? Is that an acceptable input in
- How is this case really any different from the last bullet point at Category:CS1 maint: DOI inactive (transcluded from
{{broken doi explanation}}
)? That item reproduced here for convenience:- The DOI resolves to a dead link. These are hard to report, since the doi.org thinks the DOI works and sometimes the journal no longer exists.
- In this particular case, a squatter is sitting on https://www.de-zeventiende-eeuw.nl/. For our purposes, that link is just as dead as a doi that links to a 404 page. I suspect that the squatter does not return 404 so it may be necessary to tweak Citation bot to look for
<meta name="description" content="This domain may be for sale!" />
or some such so that it doesn't inadvertently remove this sort of source from Category:CS1 maint: DOI inactive. - If one is to believe this search, there are eleven articles that have
10.18352/dze...
dois. - —Trappist the monk (talk) 13:54, 9 August 2024 (UTC)
Floating a long-term big idea
My user story is that newer editors using the Visual Editor's built in citation functionality running on Citoid often create garbage citations which have bad values and end up sorted into maintenance categories for others to fix.
There doesn't seem to be any will / urgency to implement any kind of error checking into Citoid: the goal seems to be to integrate it into more Wikimedia projects without addressing most of its problems.
My theory is that we may be able to get inexperienced editors to get in the habit of double checking the automatically generated citations if we show them the errors they're causing as soon as the citation is generated.
Module:CS1 is the thing that can do this best, and already handles it for existing citations.
I'm wondering whether there is or could be a hook somewhere in the module that citations could be passed to whenever they're created in the Visual Editor environment, to give editors instant feedback on the outcome of the Citoid library call.
I'm aware we'd need Foundation cooperation to integrate a CS1 error / maint check, either within Visual Editor or as part of the Edit Check feature once that is deployed. I'm just wondering how possible / difficult this side of it would be. Folly Mox (talk) 22:03, 5 August 2024 (UTC)
- One possibility would be to use an edit filter that catches new CS1 errors, warns against them, and requires editors to confirm before saving. I don't think that would require any Wikimedia cooperation. —David Eppstein (talk) 23:11, 5 August 2024 (UTC)
- VE's citation generator could theoretically detect the presence of errors and maintenance items: since it's already doing the rendering, it can just take what's inside cs1-maint/cs1-visible-error/cs1-hidden-error. Izno (talk) 21:30, 9 August 2024 (UTC)
What if the author is a organization such as AJC Sports?
What if the author is a organization such as AJC Sports? Abhiramakella (talk) 23:51, 10 August 2024 (UTC)
- Then use only the
|publisher=
parameter, and do not specify an individual author. Remsense诉 00:03, 11 August 2024 (UTC) - AJC == The Atlanta Journal-Constitution? Then
{{cite news}}
and|newspaper=AJC Sports
or|work=AJC Sports
. Omit|author=
. See Help:Citation Style 1 § Authors. - —Trappist the monk (talk) 00:25, 11 August 2024 (UTC)
Allowing Visual Editor/Citoid Citation tool to use more than one name format
Editors who use the manual citation generator in the Visual Editor see an interface in which they are unable to enter any author names that do not conform to the Lastname-Firstname naming system. This is not an issue for manual sourcing or for the Wikitext citation generator, which both allow the use of the |author
alias. My understanding is that the VE tool does not allow for the use of aliases, and some devs have indicated that changing the template data here is a preferred solution to this [8][9]. VE is already enabled for new users and recommended via pop-up to anonymous editors, so is there a way to adjust the WP:TEMPLATEDATA so that the author field can be used by VE? CMD (talk) 10:44, 11 August 2024 (UTC)
- The quirks of VE and TemplateData really are outside of the cs1|2 bailiwick. If what you say is true (I will not use ve so don't really know) then that suggests yet another fault in ve: an inability to recognize and utilize parameter aliases. If that is the case, perhaps phabricator should be your next stop.
- Have you tried adding
|authorn=
as separate parameters to the TemplateData? You should choose different names like Whole author name n. If that works, you should probably update the descriptions to note that only one of|lastn=
or|authorn=
is allowed – that order for Last name n; flipped for Whole author name n. - —Trappist the monk (talk) 14:40, 11 August 2024 (UTC)
- The place to make this change is going to be the Template:Cite web/doc type pages, because these contain the WP:TEMPLATEDATA that is being proposed to be changed here. Template talk:Cite redirects here, which is why I suggested CMD make a post here to verify consensus for this. Phab probably wouldn't be the best place for this since this is an enwiki issue, not a wiki agnostic issue.
- To be clear about what we're talking about here, the proposal is to add Author 1, Author 2, etc. to the left side of this screenshot.
- This could have implications. For example, the number of folks using last= and first= may go down and the number of folks using author= may go up. If there is someone that goes around changing author= to last= and first= because last= and first= are considered a better practice, for example, then having a little discussion before actioning this may be helpful. –Novem Linguae (talk) 15:44, 11 August 2024 (UTC)
- When I suggested WP:PHAB, it is because TemplateData already knows about aliases. This is a snippet from Template:Cite web/doc § TemplateData (the first entry in the rendered table;
paramOrder
putslast
at the top of the table):"last": { "label": "Last name", "description": "The surname of the author; don't wikilink, use 'author-link'; can suffix with a numeral to add additional authors", "aliases": [ "last1", "author", "author1", "author1-last", "author-last", "surname1", "author-last1", "subject1", "surname", "author-last", "subject" ], "type": "line", "suggested": true },
- Clearly, TemplateData already knows about those
aliases
. There should be no need for editors to add individual entries to the TemplateData for some or all of those aliases. Because all of those aliases are known, ve should be able to present them all to the editor; perhaps as a radio button sublist underLast name
withlast
selected as the default. As the editor, if you want|author=
from the alias list, tick that radio button and untick the associated 'First name' checkbox. The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData. And it certainly is not a cs1|2 template problem because cs1|2 templates are not the only templates that use parameters that have aliases. Not going to hold my breath waiting for a MediaWiki solution. In the meantime, the alias list is pointless and editors must add individual TemplateData entries for all aliases. How cumbersome; you can see why I abhor ve. - It has been said here that
|first=
/|last=
is the preferred name-list style but that does not work for all names (most notably Asian names where the separating comma in the rendering is problematic). There is a clumsy workaround for that but a good solution has yet to be discovered. If the goal of ve is to use only preferred parameter names, support for aliases should be withdrawn. Not going to hold my breath for that either. - —Trappist the monk (talk) 16:30, 11 August 2024 (UTC)
- Maybe it would help for Chipmunkdavis to provide a concrete example of how they are "unable" to enter an author name. If you want to cite a work by Sting (musician), what is preventing you from putting "Sting" in
|last=
using VE? Our documentation says "For corporate authors or authors for whom only one name is listed by the source, use last or one of its aliases". – Jonesey95 (talk) 17:01, 11 August 2024 (UTC)- Nothing is preventing me, I'm an experienced editor who knows the suggested course of action to ignore the instruction saying "The surname of the author" and just put in what I want, and also knows if I do that to go into the wikitext to fix the mislabeling of "Sting" as a last name. Relatedly the documentation should be changed, "whom only one name" is a small subset of affected names. CMD (talk) 17:11, 11 August 2024 (UTC)
- Maybe I misunderstood the meaning of the word "unable" in the OP:
Editors who use the manual citation generator in the Visual Editor see an interface in which they are unable to enter any author names that do not conform to the Lastname-Firstname naming system.
The documentation is not protected. That includes the TemplateData portion of the documentation, which is what provides guidance to editors who use VE. – Jonesey95 (talk) 17:52, 11 August 2024 (UTC)- You seem to have, as you copied through the fuller text however editors are unable to do so by following the instructions in the interface' your suggested solution is to ignore the interface. The documentation is not provided as guidance to editors that use VE, editors are provided only with the text that Novem has provided a screenshot of above. CMD (talk) 17:59, 11 August 2024 (UTC)
- WP:SOFIXIT? If editors can't or won't read template documentation, I don't know what to tell them. If VE needs its own documentation, it is up to people who care about VE to make it work. – Jonesey95 (talk) 20:30, 12 August 2024 (UTC)
- That is what I am doing, I am here to fix it. That is why I have opened this discussion, it is intended to find ways to fix it. CMD (talk) 03:42, 13 August 2024 (UTC)
- We came here to check consensus and I do not see sny objections, so let's just go ahead and edit the TemplateData and call it a day. We should make a list of every template that starts with cite, then edit the corresponding /doc pages (this is where TemplateData is stored) and add something like author, author2, ..., author10. CMD, want to take a stab at it? –Novem Linguae (talk) 12:15, 13 August 2024 (UTC)
|author=
already exists in the TemplateData. I think what you want to do is click "Edit template data" and then change the description for that parameter, currentlyThe surname of the author; don't wikilink, use 'author-link'; can suffix with a numeral to add additional authors
, to something that matches the actual documentation, possibly "The surname of the author, name of the corporate author, or author for whom only one name is listed by the source; do not wikilink ...". – Jonesey95 (talk) 13:48, 13 August 2024 (UTC)- Ummm, are you sure? If you look at the JSON formatted TemplateData for
{{cite web}}
, you will find only two instances of"author"
(with quotes): the|last=
definition as an alias (see my post above) and at"maps":
→"citoid":
→"author":
(as I understand it this latter applies only to automated, citoid-created, templates). - If someone adds
|authorn=
as a separate parameter, I fear that we will see an increase in the number of articles that populate Category:CS1 errors: redundant parameter because OMG!-there's-an-empty-box-in-the-form;-I-must-fill-it. This is why I suggested radio buttons for aliases; something that MediaWiki would needs implement. Not that it will do much good, but anyone adding|authorn=
as a separate parameter to TemplateData should carefully consider the description wording to emphasize the only-one-of-authorn-or-lastn-is-allowed property of name-list parameters. - —Trappist the monk (talk) 14:25, 13 August 2024 (UTC)
- My impression from the OP's description of what they see when using VE is that changing the "Description" for
|last=
in the Template Data will resolve their issue. – Jonesey95 (talk) 15:02, 13 August 2024 (UTC)- Asking new editors to translate "last" as not meaning "last" is not an optimal solution, as it suggests to new editors that the instructions/labels we have are poorly written, and it will populate templates with a |last field that does not contain a last name. The OMG-empty-box-fill is a complicating issue as well. I wonder how often both fields are filled with the wikitext citation tool. CMD (talk) 15:41, 13 August 2024 (UTC)
- Are new editors likely to be using the
manual citation generator in the Visual Editor
? From your OP, I understood you to be describing experienced editors. Hard (impossible) to knowhow often both fields are filled with the wikitext citation tool
. Category:CS1 errors: redundant parameter is mostly empty which suggests that there is a cohort of gnome editors who keep it swept clean. I guess there is more of a sense of accomplishment when emptying nearly-empty error and maint cats – I wish they would turn their attention to some of the very-not-so-empty cats... - —Trappist the monk (talk) 16:04, 13 August 2024 (UTC)
- Are new editors likely to be using the
- Mayhaps we're both confused. OP's first sentence is:
Editors who use the manual citation generator in the Visual Editor see an interface in which they are unable to enter any author names that do not conform to the Lastname-Firstname naming system.
To me, that says that using ve to manually create citations does not allow editors to create citations that use|authorn=
. Instead, editors must use|lastn=
and, as a separate operationgo into the wikitext to fix the mislabeling of "Sting" as a last name
. From all of that, I understand OP to be saying that they want to have authorn appear in the list of available parameters when manually creating citations using ve. The 'MediaWiki approved™' solution is to add authorn definitions to TemplateData. I think that this is a copout and that MediaWiki should allow editors to select from the list of aliases that TemplateData already knows about. - —Trappist the monk (talk) 16:04, 13 August 2024 (UTC)
- The general issue is present for all editors who use the VE citation tool, even experienced editors would be putting in incorrect markup if they used |last for a different name. However, the issue is obviously far more impactful for new editors, and VE is from various accounts much easier for them to use than wikitext markup. You seem to understand me accurately; I also felt the unwillingness to deal with this in VE itself was somewhat a copout and stated as much on the pump discussion. Nonetheless, I think it's an issue worth solving, and if there's another way to move it along (perhaps even just in the interim) it seems worth implementing. CMD (talk) 17:38, 13 August 2024 (UTC)
- Asking new editors to translate "last" as not meaning "last" is not an optimal solution, as it suggests to new editors that the instructions/labels we have are poorly written, and it will populate templates with a |last field that does not contain a last name. The OMG-empty-box-fill is a complicating issue as well. I wonder how often both fields are filled with the wikitext citation tool. CMD (talk) 15:41, 13 August 2024 (UTC)
- My impression from the OP's description of what they see when using VE is that changing the "Description" for
- Ummm, are you sure? If you look at the JSON formatted TemplateData for
- We came here to check consensus and I do not see sny objections, so let's just go ahead and edit the TemplateData and call it a day. We should make a list of every template that starts with cite, then edit the corresponding /doc pages (this is where TemplateData is stored) and add something like author, author2, ..., author10. CMD, want to take a stab at it? –Novem Linguae (talk) 12:15, 13 August 2024 (UTC)
- That is what I am doing, I am here to fix it. That is why I have opened this discussion, it is intended to find ways to fix it. CMD (talk) 03:42, 13 August 2024 (UTC)
- WP:SOFIXIT? If editors can't or won't read template documentation, I don't know what to tell them. If VE needs its own documentation, it is up to people who care about VE to make it work. – Jonesey95 (talk) 20:30, 12 August 2024 (UTC)
- You seem to have, as you copied through the fuller text however editors are unable to do so by following the instructions in the interface' your suggested solution is to ignore the interface. The documentation is not provided as guidance to editors that use VE, editors are provided only with the text that Novem has provided a screenshot of above. CMD (talk) 17:59, 11 August 2024 (UTC)
- Maybe I misunderstood the meaning of the word "unable" in the OP:
- Nothing is preventing me, I'm an experienced editor who knows the suggested course of action to ignore the instruction saying "The surname of the author" and just put in what I want, and also knows if I do that to go into the wikitext to fix the mislabeling of "Sting" as a last name. Relatedly the documentation should be changed, "whom only one name" is a small subset of affected names. CMD (talk) 17:11, 11 August 2024 (UTC)
- Maybe it would help for Chipmunkdavis to provide a concrete example of how they are "unable" to enter an author name. If you want to cite a work by Sting (musician), what is preventing you from putting "Sting" in
- When I suggested WP:PHAB, it is because TemplateData already knows about aliases. This is a snippet from Template:Cite web/doc § TemplateData (the first entry in the rendered table;
Duplicate cites
In Carl von Weinberg, citations #1 and #9 are the same, except for the |quote=
. This is a common scenario, but inefficient. How would you do it, without changing the citation style of the article? -- GreenC 14:53, 16 August 2024 (UTC)
- Depends. How important are the quotations to the article? At a glance, I would say not-so-important; the source is, after all, free to read and relatively short. I would delete and combine. Quotations require citations, citations do not require quotations.
- —Trappist the monk (talk) 15:02, 16 August 2024 (UTC)
You could always have something like
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.[1] Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.[2]
- ^ Nadeau, D.; Marchand, C. (1975). "Change in the kinetics of sulphacetamide tissue distribution in Walker tumor-bearing rats". Drug Metabolism and Disposition: The Biological Fate of Chemicals. 3 (6): 565–576. PMID 1234.
- ^ Nadeau & Marchand 1975, p. 569: "[...] sunt in culpa qui officia deserunt mollit anim id est laborum."
Headbomb {t · c · p · b} 15:15, 16 August 2024 (UTC)
- Perhaps something in the pipeline with meta:WMDE Technical Wishes/Sub-referencing. CMD (talk) 15:36, 16 August 2024 (UTC)
- Good timing! "Our plan is to deploy the sub-referencing feature for wikitext and Visual Editor by the end of 2024." - This is great. Thanks for the link. -- GreenC 16:18, 16 August 2024 (UTC)
- Once this becomes available, it will make
|page=
and|quote=
somewhat tricky, it will be better to include that information as a sub-reference, so that other sub-references can be attached to the origin cite which is clean of specific page # or quote data. The diffusion of information will create problems with tools, since being able to parse page numbers becomes difficult, information is in multiple templates. Plus, the option for sub-references to be named, makes it more complex. Plus, the possibility of other arguments being sub-referenced, such as authors in a multi-author book. It goes on. I suspect this well-intentioned feature is going to cause a great deal of chaos. -- GreenC 16:36, 16 August 2024 (UTC)- Followed up here, though unclear who is reading the page. -- GreenC 16:49, 16 August 2024 (UTC)
Extend "Cite uses generic title"
Hello, could the "Cite uses generic title" message be extended to apply to titles beginning with "Error 404" or "ERROR 404".
Such as "Error 404".
Keith D (talk) 21:20, 17 August 2024 (UTC)
- In an amusing coincidence, search is currently returning exactly 404 hits for insource:"error 404". —David Eppstein (talk) 21:22, 17 August 2024 (UTC)
- This search finds about 85 articles.
- Added.
- —Trappist the monk (talk) 23:06, 17 August 2024 (UTC)
module suite update 17–18 August 2024
I propose to update cs1|2 module suite over the weekend 17–18 August 2024. Here are the changes:
- allow
|agency=
in{{cite magazine}}
; discussion - maintenance category when value assigned to
|year=
is more precise than a year; discussion
Module:Citation/CS1/Configuration:
- fix 'email' generic name pattern; discussion
- fix undeclared variable 'uncategorized_namespaces_t'; no discussion; this edit
- add free DOI registrants: 4230 (LIPIcs) and 12942 (Living Reviews)
- maintenance category when value assigned to
|year=
is more precise than a year; - support free-to-read DOI on certain
10.registrant/incipit...
; initial support for MNRAS, MNRAS Letters, Geophysical Journal International, RAS Techniques and Instruments; discussion - test for 'bureau', 'company', 'correspondent', 'desk', 'group', 'limited', 'newsroom' generic names; discussion
- update WorldCat URL prefixes; discussion
- remove support for
|authors=
; limit|people=
to{{cite av media}}
,{{cite episode}}
, and{{cite serial}}
; discussion
Module:Citation/CS1/Date validation
- maintenance category when value assigned to
|year=
is more precise than a year;
Module:Citation/CS1/Identifiers
- support free-to-read DOI on certain
10.registrant/incipit...
; initial support for MNRAS, MNRAS Letters, Geophysical Journal International, RAS Techniques and Instruments;
—Trappist the monk (talk) 22:48, 9 August 2024 (UTC)
Also:
- support free-to-read DOI on certain
10.registrant/incipit...
; additional support for Access Microbiology, Microbiology, Journal of General Microbiology, Microbial Genomics [10] - support free-to-read DOI on certain
10.registrant/incipit...
; additional support for Heliyon [11] - support free-to-read DOI on certain
10.registrant/incipit...
; additional support for Journal of the Endocrine Society, JCEM Case Reports [12]
Headbomb {t · c · p · b} 17:33, 13 August 2024 (UTC)
Bug
doi:10.1093/notesj/gji104 is found as a match for doi:10.1093/jgi... Headbomb {t · c · p · b} 14:45, 19 August 2024 (UTC)
- Fixed in the sandbox I think:
{{cite book/new |title=Title |doi=10.1093/notesj/gji104}}
→ Title. doi:10.1093/notesj/gji104.{{cite book/new |title=Title |doi=10.1093/gji104}}
→ Title. doi:10.1093/gji104.{{cite book}}
: CS1 maint: unflagged free DOI (link)
- —Trappist the monk (talk) 17:45, 19 August 2024 (UTC)
Docket Number Definition
Could someone add a better definition for docket to Template:Cite report? At the moment it simply reads "docket number", but nowhere in the template documentation does it explain what a "docket" is – which is not particularly helpful for those unfamiliar with the word. –Noha307 (talk) 03:48, 19 August 2024 (UTC)
- wikt:docket Probably the 4th definition. Izno (talk) 16:21, 20 August 2024 (UTC)
Coming soon: a completely new way to make citations
Wikipedia:Village_pump_(technical)#Coming_soon:_A_new_sub-referencing_feature_–_try_it!.
It will involving breaking CS1|2 citations apart, and spreading those pieces around into different parts of the article, as free-form untemplated text. It's integral to MediaWiki. There are no guidelines for usage, anything goes. -- GreenC 17:08, 19 August 2024 (UTC)
- Are there any plans yet to build a {{subref}} (or whatever name) template that can accept the arguments that Module:Citation/CS1 and Module:Footnotes accept? Rjjiii (talk) 02:31, 20 August 2024 (UTC)
- Should be. I got kick back, saying editors should have the "luxury" to do whatever they want, without constraint. That doesn't mean we can't make templates, but that also suggests there will be a small but vocal faction that will want complete personal freedom to add whatever thing they want in a sub-ref. I couldn't even get agreement we might need some sort of guideline on how to use sub refs. So, be prepared for this to become a massive headache. There's really nothing stopping anyone from creating sub refs for multiple authors, pages, quotes, URLs, archive URLs, DOIs and other identifiers, dates, ISBNs, works, in-source locations, access-date, and much more. Essentially, everything in a citation can be removed and replaced with a sub-ref. This will create red errors in citations, make parsing citations nearly impossible, fixing citations incredibly hard, link rot will go undetected and unfixed, none of the bots will work like Citation bot and Refill that so many depend on. The libraries like PyWikiBot won't work without a massive overhaul of core components and creation of new features and functions. -- GreenC 03:42, 20 August 2024 (UTC)
- If you want to create guidelines and gain consensus for them, then start at WP:VPPOL, not here which is a less-watched, more technical page. I'm not unsympathetic to your view (I don't like LDR style referencing - implied in this development as the way to go, but perversely I do like {{sfn}}) but the discussion needs to go wider than the technical pages and technical-minded editors who haunt them.
- It's an eternal problem with Wikipedia that technical changes happen in a vacuum and not in conjunction with changes with business practices. It's understandable when you consider that the way de-wp probably want to use a feature will be a different way to how the same feature will be used on en-wp, so I don't blame WMF for having a bit of a dump and run approach. We know the technical change is going to happen so let's have the associated en-wp business change discussion upfront but in the right place, which isn't here.
- Like any change, there are always fears about what will ensue. All the things you list may happen but less Chicken Little and more "approach X is to be recommended because it prevents/reduces ABC happening" is, imo, a better starting place for discussion. The use of ibid has been discouraged for years but it still gets used, to no great detriment overall. We even have WP:CITEVAR as policy accepting variances in referencing styles, so yes there are almost inevitably going to be edits using sub-refs in ways that you and I will not like for one reason or another. They're not going to eliminated but get the MOS/policy position established which reduces the likelihood of them happening in the first place. Nthep (talk) 07:42, 20 August 2024 (UTC)
- Very well said. There will likely be consensus for this feature generally, but if there is a guideline and what that guideline says, should be decided by the community. The community needs to understand the consequences of citations that are no longer supported by tools. It will become painfully apparent with time, but the sooner this is resolved the better. -- GreenC 17:06, 20 August 2024 (UTC)
- If a wiki page cites, e.g., multiple stories in an anthology, multiple articles in an issue, multiple papers at a conference, then it would be normal for different subreferences to have different
|auther=
parameters. OTOH, I see no reason to not exclude, e.g.,|isbn=
. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:52, 20 August 2024 (UTC)- Editors will be creative how they slice and dice citations. There will be a variety in one article, that exists nowhere else, or only a few articles. Many rare birds. Thus, automated tools loose the benefit of CS1|2, which is standardization. Our tools will simply cease to function (for those citations). So we gain things, and loose things. If folks are OK with the loss of Refill, Citation bot, InternetArchiveBot, GreenCbot, AWB, PyWikiBot, etc.. then they are also OK with link rot, usurped URLs, general maintenance of metadata, clearing tracking category errors, etc.. The expectation that tools will be able to adapt should not be assumed. Many rare birds, at high risk of extinction, another way of saying non-robust, error prone, weak ie. bad design. Wikipedia has a lot of bad design but this one of predictable and preventable, with the right guardrails. -- GreenC 16:32, 20 August 2024 (UTC)
- There should be no issue with the main reference. I also don't see an issue with sub-references that use CS1 or CS2 template with
|title=op cit
. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:07, 20 August 2024 (UTC)- Specifying
|title=op cit
in a cs1|2 template inside of a<ref extends="...">{{cite whatever |title=op cit |...}}</ref>
will cause the cs1|2 template to emit bogus title metadata:&rft.btitle=op+cit
so anyone consuming article citations via reference management software won't be given the source's actual title in the scraped citation. Fortunately there are few cs1|2 templates that use|title=Op. cit.
; see this search. Similarly, for|title=Ibid
; this search. - Yeah, we could add a mechanism (parameter) that would tell a cs1|2 template to mute its metadata output, but that would needs be a manual operation because the cs1|2 template cannot know which
<ref extends="...">...</ref>
tags wrap it. - —Trappist the monk (talk) 17:48, 20 August 2024 (UTC)
- I'm assuming that whoever uses
<ref extends=main-reference>citation-template</ref>
will use the proper parameters for the wrapped sub-reference, provide that template supports an appropriate parameter. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:23, 20 August 2024 (UTC)
- I'm assuming that whoever uses
- Specifying
- There should be no issue with the main reference. I also don't see an issue with sub-references that use CS1 or CS2 template with
- Editors will be creative how they slice and dice citations. There will be a variety in one article, that exists nowhere else, or only a few articles. Many rare birds. Thus, automated tools loose the benefit of CS1|2, which is standardization. Our tools will simply cease to function (for those citations). So we gain things, and loose things. If folks are OK with the loss of Refill, Citation bot, InternetArchiveBot, GreenCbot, AWB, PyWikiBot, etc.. then they are also OK with link rot, usurped URLs, general maintenance of metadata, clearing tracking category errors, etc.. The expectation that tools will be able to adapt should not be assumed. Many rare birds, at high risk of extinction, another way of saying non-robust, error prone, weak ie. bad design. Wikipedia has a lot of bad design but this one of predictable and preventable, with the right guardrails. -- GreenC 16:32, 20 August 2024 (UTC)
- @GreenC, make sure you don't WP:CANVASS when you decide not to invoke the names of your would-be opposition. You got kickback for good reason. Izno (talk) 16:22, 20 August 2024 (UTC)
- This could be done by creating a variant of the citation templates that wrapped the citation in
<ref name="CITEREFSmith2000">...</ref>
instead of putting the ref in the<cite>
tag. Then{{subref}}
could be written to use that ref in a similar way to{{sfn}}
. None of this seems to require anything more from the MediaWiki implementation. Kanguole 10:03, 20 August 2024 (UTC) - That is
{{ref cite book |first=E. |last=Miller |title=The Sun |location=New York |publisher=Academic Press |year=2005}}
- (arbitrary template name) would expand as
<ref name="Miller2005">Miller, E. ''The Sun''. New York: Academic Press, 2005.</ref>
- and
{{subref|Miller|2005
would expand as|p=23
}} <ref extends="Miller2005">Page 23.</ref>
- and the existing sub-referencing implementation would do the rest. The only thing missing would be merging of duplicate pages, but there are hooks to enable that too. Kanguole 10:24, 20 August 2024 (UTC)
- That is an interesting idea. It does lock this method further into source code editing. At the moment, the list-defined references (LDR) that this method relies on aren't fully implemented in the Visual Editor. The VE can't add, remove, or replace a list-defined reference. Hypothetically though, if the WMF can get LDR working in VE, then this could be much friendlier to new users than {{sfn}}. The template could be designed to plug into the sub-references like: Rjjiii (talk) 15:50, 20 August 2024 (UTC)
<ref extends="Miller2005">{{subref|p=23}}</ref>
- That is an interesting idea. It does lock this method further into source code editing. At the moment, the list-defined references (LDR) that this method relies on aren't fully implemented in the Visual Editor. The VE can't add, remove, or replace a list-defined reference. Hypothetically though, if the WMF can get LDR working in VE, then this could be much friendlier to new users than {{sfn}}. The template could be designed to plug into the sub-references like:
- Should be. I got kick back, saying editors should have the "luxury" to do whatever they want, without constraint. That doesn't mean we can't make templates, but that also suggests there will be a small but vocal faction that will want complete personal freedom to add whatever thing they want in a sub-ref. I couldn't even get agreement we might need some sort of guideline on how to use sub refs. So, be prepared for this to become a massive headache. There's really nothing stopping anyone from creating sub refs for multiple authors, pages, quotes, URLs, archive URLs, DOIs and other identifiers, dates, ISBNs, works, in-source locations, access-date, and much more. Essentially, everything in a citation can be removed and replaced with a sub-ref. This will create red errors in citations, make parsing citations nearly impossible, fixing citations incredibly hard, link rot will go undetected and unfixed, none of the bots will work like Citation bot and Refill that so many depend on. The libraries like PyWikiBot won't work without a massive overhaul of core components and creation of new features and functions. -- GreenC 03:42, 20 August 2024 (UTC)
cite conference and conference-url
From Holographic algorithm:
References
- ^ Valiant, Leslie (17–19 October 2004). Holographic Algorithms (Extended Abstract). FOCS 2004. Rome, Italy: IEEE Computer Society. pp. 306–315. doi:10.1109/FOCS.2004.34. ISBN 0-7695-2228-9.
{{cite conference}}
:|access-date=
requires|url=
(help);|archive-url=
requires|url=
(help)
Same problem with {{cite conference}}
in Tervamäki ATE-3 and Tervamäki JT-5. Changing |conference-url=
to |url=
solved the problem eg. Special:Diff/1241238099/1241238294. This could be a new problem, I've never seen it before, three articles showed up in Category:CS1 errors: archive-url. -- GreenC 03:27, 20 August 2024 (UTC)
- The values assigned to
|conference-url=
and to|archive-url=
are not links to the paper named in|title=
and do not match the source linked by|doi=
.|archive-url=
and|access-date=
do not apply to|conference-url=
hence the error messages: |archive-url= requires |url= and |access-date= requires |url=. Both apply to|url=
or in its absence to|chapter-url=
(and aliases). - Were it me, I would rewrite:
{{cite conference |title=Holographic Algorithms |book-title=FOCS 2004: 45th Annual IEEE Symposium on Foundations of Computer Science |first=Leslie |last=Valiant |author-link=Leslie Valiant |date=17–19 October 2004 |conference=FOCS 2004 |publisher=IEEE Computer Society |pages=306–315 |isbn=0-7695-2228-9 |doi=10.1109/FOCS.2004.34 |conference-url=https://web.archive.org/web/20120313170241/http://www.cs.brown.edu/~aris/focs04/}}
- Valiant, Leslie (17–19 October 2004). "Holographic Algorithms". FOCS 2004: 45th Annual IEEE Symposium on Foundations of Computer Science. FOCS 2004. IEEE Computer Society. pp. 306–315. doi:10.1109/FOCS.2004.34. ISBN 0-7695-2228-9.
- This is not anything new.
{{cite conference}}
needs to be rewritten because editors routinely write poor proceedings citations (we are citing the proceedings, not the conference – if you want to cite the conference website, use{{cite web}}
). - —Trappist the monk (talk) 14:37, 20 August 2024 (UTC)
- OK. Thanks for your time explaining. I'll keep this in mind next time I clear the category, about 80% by bot the remaining 20% manually have unusual cases like this. -- GreenC 15:51, 20 August 2024 (UTC)
Portal di Ensiklopedia Dunia