Jump to content

Help talk:Citation Style 1

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

    strange capitalization

    [edit]

    Why was {{cite web}} unilaterally capitalized in the documentation just recently? — Fourthords | =Λ= | 18:16, 25 October 2024 (UTC)[reply]

    Editor MtBotany made that edit. Best to ask them. So far as I know, there was no discussion here mandating that change.
    Trappist the monk (talk) 18:29, 25 October 2024 (UTC)[reply]
    I'd planned to ask at template talk:cite web (per my original wording), but figured here was the only place to ask, given the redirection. — Fourthords | =Λ= | 20:13, 25 October 2024 (UTC)[reply]
    @Fourthords I thought it was the correct style based on what I have seen used in other templates. If I am wrong I apologize and feel free to correct what I did. 🌿MtBotany (talk) 18:32, 25 October 2024 (UTC)[reply]
    I have no idea whether you were incorrect to do so; that's why I asked. What I can say is that it doesn't match the documentations at {{cite book}}, {{cite magazine}}, {{cite news}}, and {{cite journal}}. — Fourthords | =Λ= | 20:13, 25 October 2024 (UTC)[reply]
    You're right about that. I assumed that all templates used the same style of first letter capitalized to match with the way it is in the name of the page. I had also seen it capitalized that way in the documentation of Template:Reflist. It does work either way, but I was trying for consistency and made things more confused rather than less. 🌿MtBotany (talk) 20:47, 25 October 2024 (UTC)[reply]

    SSRN update request

    [edit]

    Rio do Rasto Formation has this working SSRN link but it's being flagged as incorrect. Category:CS1 errors: SSRN said to mention it here as it's above the 4900000 range. Thanks! MrLinkinPark333 (talk) 02:16, 27 October 2024 (UTC)[reply]

    IslamPidia might be deleted or moved by the time this issues is resolved, but it includes a working SSRN numbered 5000986. The SSRN error help page currently says numbers up to 5000000 are valid. Maybe we should bump it up to 5100000? Snowman304|talk 19:14, 2 November 2024 (UTC)[reply]

    PMC limit update

    [edit]

    PMC 11508991 - 11508991 - confirmed by pmid & doi @ Anderus maculifrons - ref 3 and also others new 6245 & 6159 checked from errors: PMC Dave-okanagan (talk) 07:22, 28 October 2024 (UTC)[reply]

    Work vs. Publisher

    [edit]

    This template includes both "work" and "publisher" - what then is the semantic difference between the two? Also, in what circumstance might both be utilised?
    Enquire (talk) 21:01, 28 October 2024 (UTC)[reply]

    See Help:Citation Style 1 § Work and publisher.
    Trappist the monk (talk) 21:52, 28 October 2024 (UTC)[reply]

    Wikibooks for CS1|2

    [edit]

    Looking at the above discussion about Help:Citation Style 1 § documentation for work and publisher, it's surprising no one has ever created a Wikibook for CS1|2. It would be genuinely useful to a lot of people. And could be better than current documentation, there are no space or formatting constraints. It's like the difference between templates written in wikitext vs. Lua -- one can be made to work for short and easy tasks, the other is the proper way to scale larger jobs. The CS1|2 docs are now large and complex. Here is a Wikibook on LaTeX, and other computer books. -- GreenC 04:44, 29 October 2024 (UTC)[reply]

    URLs, for volume and issue and page

    [edit]

    If a magazine/journal article doesn't have a proper URL, but proper URLs exist for a page that is being cited, or an entire issue that was scanned, or to a compendium; such as a hardbound yearly volume that was scanned; then shouldn't there be |volume-url= , |issue-url= , |page-url= / |at-url= available? Bluelinking the article title would seem off, considering that entering a DOI doesn't bluelink the article title. And subbing in an entire year/volume url under the article title instead of the volume id doesn't give a reader the article they think they've been pointed to. -- 65.92.246.77 (talk) 11:13, 30 October 2024 (UTC)[reply]

    |at= and |page= will accept external links as values without throwing an error like the rest of the template parameters. You might have to do some manual formatting (especially if you're using |at= to link a volume, and have to leave out the |volume= parameter to offset— a form of parameter abuse someone here is likely to inveigh against).
    Also, entering a DOI in combination with |doi-access=free will bluelink the title, for {{cite journal}} only. Folly Mox (talk) 11:20, 30 October 2024 (UTC)[reply]
    Cite what you see. If you are reading a book that is a yearly bound volume of magazine releases, then make the reference to that book rather than the magazine. -- LCU ActivelyDisinterested «@» °∆t° 11:22, 30 October 2024 (UTC)[reply]
    What I can read and what I can provide a URL to can be different. In one case, I can access a volume URL, but I can access a physical copy, which is just an issue. It would be nice if page/at had URL params. I'll give the URL encoded in page/at params a go, to link to the particular point where a piece referenced data occurs -- 65.92.246.77 (talk) 22:39, 31 October 2024 (UTC)[reply]
    While |page-url= would be nice, |page=[url#page=pdfpage pageno] works well.-- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:28, 1 November 2024 (UTC)[reply]

    Two dots at the end?

    [edit]

    I noticed that this template appears to add two dots at the end of the citation for no obvious reason. See External links on this page for an example (there is only one external link). Can somebody figure out why this happens and fix it?

    SkyLined (talk) 09:29, 4 November 2024 (UTC)[reply]

    While I confirm that the citation appears in the link above with double dots, the exact same template, copied, doesn't produce double dots (for me, anyway!) here:
    (Also the link as generated by Citer doesn't produce double dots in the original context.)
    Pol098 (talk) 12:33, 4 November 2024 (UTC)[reply]
    The extra dot was placed after one of the categories for the article. Since categorisation doesn't render in place, but rather at the page foot, it made it appear as if the dot was produced by the citation template. I removed it. Folly Mox (talk) 12:40, 4 November 2024 (UTC)[reply]
    Thanks for spotting and fixing that!
    It currently renders as The 'Basic' HTTP Authentication Scheme. Internet Engineering Task Force. September 2015. doi:10.17487/RFC7617. RFC 7617. which has more than a few dots and repeats the RFC number. That looks weird to me - is that how it is supposed to look?
    SkyLined (talk) 02:54, 5 November 2024 (UTC)[reply]
    {{cite IETF}} is not a cs1|2 template. It is a wrapper around {{citation}}. If you believe that that {{cite IETF}} should render differently, you must discuss that at the template's talk page.
    Trappist the monk (talk) 14:38, 5 November 2024 (UTC)[reply]

    length or running time parameters

    [edit]

    This page was given as Talk for Cite AV Media template.

    Nowhere do I find any parameter for the size of the media as in "pages=" for books; the "time=" parameter is described as a location in the work, like "page=" or "at=".71.230.16.111 (talk) 05:26, 9 November 2024 (UTC)[reply]

    @71.230.16.111: we typically don't list the size of a work in that way in a citation. |pages= is for a page range of a location within a book or other work, not the total size. That parameter is used to prefix the plural "pp." in front of a group of pages instead of the singular "p.", and it's not for the total pages in a book. This might be the source of confusion for you. Imzadi 1979  05:54, 9 November 2024 (UTC)[reply]
    I use |type=Video (23'34"). Unlike, say, a book, AV media are sequential, not random, access, so the length is more relevant to the reader. If this suggestion is generally liked, it could be added to the documentation of {{Cite AV media}}. Documentation for |type= at present includes "Alias: |medium=. Use one of the following as applicable: Motion picture, Television production, Videotape, DVD, Blu-ray, Trailer, CD, Radio broadcast, Podcast". Best wishes, Pol098 (talk) 13:08, 9 November 2024 (UTC)[reply]

    Documentation unnecessarily verbose (author1, author2, ... author9)

    [edit]

    The documentation for the citation templates in unnecessarily verbose, with entries tabulated like author3, last3, author3-link, for numerical values up to 9, and similarly for other parameters. After the entries for the 2nd author (etc.), I suggest simply and similar values for further authors, e.g. author3, etc. , omitting entries 3-9. This also has the merit of being more general; the existing table goes up to 9, without mention of listing further authors, e.g., author15. I suppose there is a limit to the number of authors (etc.) supported; this could be mentioned (some physics papers have around 1,000 authors, though I don't suggest including them all). This is fairly obvious; maybe it has been suggested, and rejected? Best wishes, Pol098 (talk) 14:44, 10 November 2024 (UTC)[reply]

    There is no practical limit to n in |authorn= (for the real limit see mw:Extension:Scribunto/Lua reference manual § number).
    If you are talking about that abomination that is TemplateData, this is the wrong venue. There is no support in TemplateData to 'short-hand' enumerated parameter names.
    Trappist the monk (talk) 15:12, 10 November 2024 (UTC)[reply]
    Thanks; indeed TemplateData. Best wishes, Pol098 (talk) 15:48, 10 November 2024 (UTC)[reply]

    URL for cite document

    [edit]

    {{cite document}} under its COinS says url is supported. But at Kaufman, Texas I'm getting "Unknown parameter |url= ignored" How do I specify a URL for {{cite document}}? Jay 💬 14:50, 10 November 2024 (UTC)[reply]

    Note: This table of metadata is displayed in the documentation of all Citation Style 1 templates. Not all of these parameters are supported by every CS1 template. {{Cite document}} is specifically for offline documents; why not use {{cite web}}? Mackensen (talk) 15:23, 10 November 2024 (UTC)[reply]
    (edit conflict)
    From the first line of text in the {{cite document}} template's documentation:
    This ... template is used to create citations for short, stand-alone, off-line documents. (emphasis added)
    The COinS documentation at Template:Cite document § COinS has this:
    Note: This table of metadata is displayed in the documentation of all Citation Style 1 templates. Not all of these parameters are supported by every CS1 template.
    Use an appropriate template.
    Trappist the monk (talk) 15:24, 10 November 2024 (UTC)[reply]
    Fixed. Folly Mox (talk) 15:39, 10 November 2024 (UTC)[reply]
    For some documents {{Cite report}}, which takes a URL, is appropriate. Pol098 (talk) 15:56, 10 November 2024 (UTC)[reply]
    Thanks, but since it was a PDF, I wanted to use a citation that is closest to document. And that PDF is not a report. Jay 💬 07:39, 12 November 2024 (UTC)[reply]
    I'm open to correction here by the people who actually did the work, but my understanding is that the theory behind the CS1|2 templates is not to taxonomise source types, but to present multiple consistent display formats while constraining parameter sets. Most written media can be construed as "documents". {{Cite web}} is perfectly adequate here: with complete bibliographic information a reader should be able to locate and consult a printed version of this source should the source's current server go dark. If in doubt of the appropriate template, {{Citation}} can be used as an initial implementation, with |mode=cs1 to force stops instead of commas in between displayed parameter values. Folly Mox (talk) 17:16, 17 November 2024 (UTC)[reply]
    Oh and to provide well-structured metadata for downstream reusers and to infill certain values in some cases and probably other goals. Forgetfully and in ignorance, Folly Mox (talk) 17:19, 17 November 2024 (UTC)[reply]

    MOS:RANGE violation

    [edit]

    MOS:RANGE states: "The en dash in a range is always unspaced, except when either or both elements of the range include at least one space, hyphen, or en dash; in such cases, {{snd}} between them will provide the proper formatting" and it gives the example "pages 5-7 – 5-9". However, the citation templates do not obey this, instead stripping out the spaces from parameters like |pages=12-1 – 12-24

    Example:

    • {{citation|title=Algorithms and Theory of Computation Handbook: General Concepts and Techniques|editor1-first=Mikhail J.|editor1-last=Atallah|editor2-first=Marina|editor2-last=Blanton|contribution=Chapter 12: Randomized Algorithms|first1=Rajeev|last1=Motwani|author1-link=Rajeev Motwani|first2=Prabhakar|last2=Raghavan|author2-link=Prabhakar Raghavan|edition=2nd|publisher=CRC Press|year=2010|pages=12-1 – 12-24}}
    • Motwani, Rajeev; Raghavan, Prabhakar (2010), "Chapter 12: Randomized Algorithms", in Atallah, Mikhail J.; Blanton, Marina (eds.), Algorithms and Theory of Computation Handbook: General Concepts and Techniques (2nd ed.), CRC Press, pp. 12-1–12-24
    • SANDBOX: Motwani, Rajeev; Raghavan, Prabhakar (2010), "Chapter 12: Randomized Algorithms", in Atallah, Mikhail J.; Blanton, Marina (eds.), Algorithms and Theory of Computation Handbook: General Concepts and Techniques (2nd ed.), CRC Press, pp. 12-1–12-24

    Using the MOS recommendation of {{snd}} is worse, producing "12-1 –&#32, 12–24". Can this be fixed, please? —David Eppstein (talk) 07:22, 11 November 2024 (UTC)[reply]

    Use of ((…)) will fix that: title, pp. 12-1 – 12-24. -- Michael Bednarek (talk) 09:10, 11 November 2024 (UTC)[reply]
    There is no need for hacks. If this should be fixed, the module can handle it without that. Gonnym (talk) 11:16, 11 November 2024 (UTC)[reply]
    I agree this should be fixed but am not sure how to fix it. Maybe this is something Trappist the monk or Folly Mox can help with? Firefangledfeathers (talk / contribs) 13:53, 12 November 2024 (UTC)[reply]
    Apologies for any confusion: I'm fairly well versed in the behaviour of Module:CS1 and its dependent templates, but I'm almost entirely unfamiliar with the codebase. I've read through parts of it, but Trappist is by far the primary maintainer. Folly Mox (talk) 18:44, 12 November 2024 (UTC)[reply]
    In the sandbox. Spaced em/en/hyphen separators between hyphenated compound page numbers:
    • {{citation/new|title=Title |pages=12-1 – 12-24}}Title, pp. 12-1 – 12-24
    • {{citation/new|title=Title |pages=12-A – 12-X}}Title, pp. 12-A – 12-X
    • {{citation/new|title=Title |pages=A-12 - A-24}}Title, pp. A-12 – A-24
    • {{citation/new|title=Title |pages=A-12 — A-24}}Title, pp. A-12 – A-24
    Unspaced em/en/hyphen separators between hyphenated compound page numbers:
    • {{citation/new|title=Title |pages=12-1–12-24}}Title, pp. 12-1 – 12-24
    • {{citation/new|title=Title |pages=12-A–12-X}}Title, pp. 12-A – 12-X
    • {{citation/new|title=Title |pages=A-12-A-24}}Title, pp. A-12 – A-24
    • {{citation/new|title=Title |pages=A-12—A-24}}Title, pp. A-12 – A-24
    Unspaced em/en/hyphen separators between dot-separated compound page numbers:
    • {{citation/new|title=Title |pages=12.1–12.24}}Title, pp. 12.1 – 12.24
    • {{citation/new|title=Title |pages=12.A–12.X}}Title, pp. 12.A – 12.X
    • {{citation/new|title=Title |pages=12.A-12.X}}Title, pp. A.12 – A.24
    • {{citation/new|title=Title |pages=12.A—12.X}}Title, pp. A.12 – A.24
    Spaced em/en/hyphen separators between simple numeric page numbers:
    • {{citation/new|title=Title |pages=12 – 24}}Title, pp. 12–24
    • {{citation/new|title=Title |pages=12 - 24}}Title, pp. 12–24
    • {{citation/new|title=Title |pages=12 — 24}}Title, pp. 12–24
    Unspaced em/en/hyphen separators between simple numeric page numbers:
    • {{citation/new|title=Title |pages=12–24}}Title, pp. 12–24
    • {{citation/new|title=Title |pages=12-24}}Title, pp. 12–24
    • {{citation/new|title=Title |pages=12—24}}Title, pp. 12–24
    Spaced em/en/hyphen separators between simple alpha page numbers:
    • {{citation/new|title=Title |pages=xii – xiv}}Title, pp. xii–xiv
    • {{citation/new|title=Title |pages=xii - xiv}}Title, pp. xii–xiv
    • {{citation/new|title=Title |pages=xii — xiv}}Title, pp. xii–xiv
    Unpaced em/en/hyphen separators between simple alpha page numbers:
    • {{citation/new|title=Title |pages=xii–xiv}}Title, pp. xii–xiv
    • {{citation/new|title=Title |pages=xii-xiv}}Title, pp. xii–xiv
    • {{citation/new|title=Title |pages=xii—xiv}}Title, pp. xii–xiv
    Spaced and unspaced em/en/hyphen separators between mixed alpha and numeric page numbers; returned unmodified:
    • {{citation/new|title=Title |pages=xii – 5}}Title, pp. xii – 5
    • {{citation/new|title=Title |pages=xii - 5}}Title, pp. xii - 5
    • {{citation/new|title=Title |pages=xii — 5}}Title, pp. xii — 5
    • {{citation/new|title=Title |pages=xii–5}}Title, pp. xii–5
    • {{citation/new|title=Title |pages=xii-5}}Title, pp. xii-5
    • {{citation/new|title=Title |pages=xii—5}}Title, pp. xii—5
    Trappist the monk (talk) 14:51, 15 November 2024 (UTC)[reply]

    clean up usurped / unfit / deviated

    [edit]

    For probably more than a decade, I've been fixing {{cite}} templates with |url-status=usurped or |url-status=unfit, changing those to |url-status=dead. In one place, Template:Cite web/doc offers usurped and unfit as valid values for this parameter and in two other places it additionally offers deviated, which I didn't know about until now, and that value actually works. Template:Cite news/doc has those two other places, but doesn't have the place offering usurped and unfit without also offering deviated. Recommendations: First, all cite template documentation pages be updated to say that usurped and unfit are not supported and to use deviated instead. Second, cite template documentation pages should—for parameters that are identical in name, range of values, and display—explain the parameters using identical language. —Anomalocaris (talk) 22:22, 13 November 2024 (UTC)[reply]

    What do you mean when you say: usurped and unfit are not supported? Give us an example of that shows how those parameter values not supported. Every cs1|2 template that supports |archive-url= (all but the preprint templates – {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, {{cite medrxiv}}, and {{cite ssrn}} – and {{cite document}}) support usurped and unfit for |url-status=.
    Most of the cs1|2 documentation comes from Template:Citation Style documentation which is shared amongst the all of the cs1|2 templates. That is the real documentation. If you are talking about that abomination that is TemplateData, that is not the template documentation. Please specify where you think that the documentation is falling short. If you know how the documentation can be improved, please improve it. The documentation is not protected.
    Trappist the monk (talk) 23:08, 13 November 2024 (UTC)[reply]
    A factual comment, with no opinion: use of usurped and unfit trigger a cs1 warning. As far as I remember without checking they are identical, and the reference renders without link to the original article, while deviated is identical to dead. Best wishes, Pol098 (talk) 11:49, 14 November 2024 (UTC)[reply]
    It's a maintenance message, not a warning. I'm not super sure of the point, since no maintenance is required and the URL blacklist is a completely separate process. |url-status=bot: unknown is another maintenance message that needs no attention. Folly Mox (talk) 21:40, 14 November 2024 (UTC)[reply]
    I'm demoralized somebody is intentionally and systematically removing |url-status=usurped. I have spent years adding usurp to hijacked domains (see WP:JUDI). We should remove that maintenance message, it keeps coming up as a source of confusion, and now apparently a source of harm to the system. At the same time, what can be done to improve TemplateData? --GreenC 03:03, 15 November 2024 (UTC)[reply]
    TemplateData should be collapsed, it's not part of the documentation and any editor who knows what it is and wants to edit it won't be harmed by it being collapsed. At the moment editors mistake it as part of the documentation causing confusion. -- LCU ActivelyDisinterested «@» °∆t° 10:34, 15 November 2024 (UTC)[reply]
    Yeah I got hung up on the subtopic and failed to engage with the real problem here: well-intentioned but misinformed and deliberate disimprovements that undo the work of others and may lead readers to malware, scams, online gambling spam, etc. @Firefangledfeathers: suggest url-status. Folly Mox (talk) 17:16, 15 November 2024 (UTC) Edited 15:16, 16 November 2024 (UTC) [reply]
    Comment: the suggested search also finds many pages where "url-status=live", unambiguously incorrect without archive-url, has been deleted by Anomalocaris. I also delete these. Best wishes, Pol098 (talk) 12:02, 16 November 2024 (UTC)[reply]
    They edited 760 pages, with an edit summary. The JUDI processes has edited about 42,000 pages. About 2%. -- GreenC 00:29, 16 November 2024 (UTC)[reply]
    That was a bad suggestion, posted in haste slightly after my break was already over. I clicked through to and reviewed about 40 diffs from the first page of 500 results (back to summer 2020) where the edit summary made it ambiguous what action was taken. Most were false positives, and of the five instances I found where |url-status= was changed away from unfit or usurped, today only one is actually a usurped domain, which I fixed at Special:Diff/1257764735. Anomalocaris does a high volume of good and accurate citation gnoming.
    @Anomalocaris: could you speculate on the scope of your edits that have removed these statuses?
    I'll try looking for other edit summary keywords and reviewing the diffs instead of blindly posting poor suggestions here for others to work through. Folly Mox (talk) 15:16, 16 November 2024 (UTC)[reply]
    As a follow up here: I'm experiencing an issue with Σ's edit summary search tool, where it claims there are 762 hits, but will only display 501. The 501th, from May 2020, is the earliest diff it will return irrespective of specified date range.
    I manually reviewed all the diffs in the displayed results yesterday where it was unclear from the summary whether a usurped or unfit status was being removed, and all the diffs that indicated that was being done (major overlaps with searches for "usurped" and "unfit", which each return four hits). If anyone is able to get the earlier diffs to display, please ping me with a working link to the summary.py results and I'll manually review them.
    The majority of the diffs I checked were false positives (usually clearing up |url-status=bot: unknown), and of the true positives the switch of |url-status= was actually correct in most cases: a few US government websites some earlier editor had marked as unfit perhaps as a personal statement, a redirect to a different content page on a safe domain (Salon), and a domain with an expired registration that no one bothered to usurp.
    Had no positives with other edit summary searches; out of ideas. I am seeing a very kindred spirit in Anomalocaris. Unless they are able to estimate a broader scope for this particular change, or we're somehow able to find removals of membership in Category:CS1 maint: unfit URL (49,891) with some database query, I'm hesitantly but optimistically suspecting that although the timeframe quoted in the first sentence of the OP is a long one, the volume of this specific change is not particularly high. May this suspicion mollify in particular GreenC. For the record, Folly Mox (talk) 17:05, 17 November 2024 (UTC)[reply]
    I am sorry for messing up other editors' work and I would like to make amends. Occasionally I mentioned url-status in edit summaries, but most of my edits involving changing url-status would be covered by "improve <ref>s" rather than "url-status". About a third of my edit summaries include "improve <ref>s", so it would take a long time to examine each of those edits for changing unfit or usurped to dead. Is there any tool that can perform, in effect: For all Anomalocaris edits do if (Diff includes removing "usurped" or "unfit") then (report that edit)? I'm putting a line below this edit to reflect that comments below are actually older and I encourage any replies to be above the line. —Anomalocaris (talk) 18:51, 17 November 2024 (UTC)[reply]



    Anomalocaris, it would help to be able to review your edits in which you removed "usurped". I see very few that use "usurped" in the edit summary. The most recent are appropriate, since the urls direct to 404 pages; "dead" is the right argument to use. What other edit summaries might lead us to more "usurped" changes? Firefangledfeathers (talk / contribs) 15:25, 15 November 2024 (UTC)[reply]
    • A new experiment shows {{cite web}} with |url-status= set to any of {usurped, unfit, deviated} generates the warning {{cite web}}: CS1 maint: url-status (link). When I started this discussion I thought I saw that deviated did not generate the warning. I may have been mistaken. [Update: deviated doesn't seem to generate the warning. Anomalocaris (talk) 00:30, 16 November 2024 (UTC)][reply]
    • I misunderstood the warning to mean, "Please change the URL status to dead. I now understand the warning to mean, "Please find a better reference."
    • Apologies to editors whose efforts to put in usurped status I undermined.
    • But I don't understand why you made those efforts, because I don't see the practical difference between an external link that's invalid because the original domain owner didn't renew it, and an external link that's invalid because the webmaster discontinued the page. Either way, it's a dead link. Yes, sometimes it might be possible to find the page on the same website, now organized differently, but usually, when a page is gone it's gone. (strike by Anomalocaris (talk) 00:30, 16 November 2024 (UTC))[reply]
    • If someone can suggest a way of searching through my over 87,000 edits for changing |url-status=usurped or |url-status=unfit to |url-status=dead, I can review my work, but this would be a huge project; some of the formerly usurped URLs might be dead by now and some of the references may not be in the current version, so it would be a big process.
    • If the meaning of the maintenance tag is "Please find a better reference", I believe the maintenance tag should go away if an archive-url is supplied. (strike by Anomalocaris (talk) 00:30, 16 November 2024 (UTC))[reply]
    • The documentation should be improved, as I said before, and another improvement is to clarify that the warning message means "Please find a better reference", not "please change the URL status to dead".
    Anomalocaris (talk) 19:24, 15 November 2024 (UTC)[reply]
    Kindly, the important distinction is that usurped and unfit URLs do not generate a clickable link. Folly Mox (talk) 21:39, 15 November 2024 (UTC)[reply]
    User:Anomalocaris: I don't understand why you made those efforts. Really? Since we don't want readers to unwittingly click through to gambling and porn, expecting they would arrive at a normal website, we hide those malicious links by setting them to usurped. You have not noticed this before?
    "Example with status=dead". Archived from the original on 2024-11-01.
    "Example with status=usurped". Archived from the original on 2024-11-01.{{cite web}}: CS1 maint: unfit URL (link)
    You see the difference? One displays a link to "the original" and the other does not. It is why |url-status=usurped exists. It serves a function, usurped is not just another word for dead. -- GreenC 23:49, 15 November 2024 (UTC)[reply]
    GreenC (also Folly Mox): Thank you for making the obvious even more obvious. I see it now. I struck two bullets above. I also confirm Pol098's observation that deviated seems to be identical to dead in this regard. —Anomalocaris (talk) 00:30, 16 November 2024 (UTC)[reply]
    It's been commented here that "Since we don't want readers to unwittingly click through to gambling and porn, expecting they would arrive at a normal website, we hide those malicious links by setting them to usurped." This makes perfect sense; I suggest that it should be mentioned in the documentation, not just "these parameters suppress the original URL". Maybe add "... because they link to inappropriate sites. A maintenance message is generated to suggest that a better link could be found". I don't actually think that a better link is likely to be available in perhaps most cases, sites are often gone with content only findable, sometimes, on the Wayback Machine; I'm not sure, without statistics, that the maintenance message is even useful. Best wishes, Pol098 (talk) 12:23, 16 November 2024 (UTC)[reply]
    The statuses live, dead, unfit, usurped, and deviated are all invisible to readers (for whom Wikipedia is intended), and confusing to editors, in particular with different parameters behaving exactly the same (dead, deviated; unfit, usurped). I would suggest deprecating them all (except live, for archived references), and for all future use suggest live, unavailable (but linked), and unsuitable (no link). It would be up to editors to choose; for example, is a link to, say acme.com/rodulator unavailable or unsuitable when the rodulator is discontinued and the link redirected to the acme.com home page? Best wishes, Pol098 (talk) 13:33, 16 November 2024 (UTC)[reply]
    I think this is a wakeup call that the maintenance message for these |url-status= values should be suppressed. I'm not sure if there's a better tracking route than adding the article to Category:CS1 maint: unfit URL (49,891), but many editors see maintenance categories as problems to fix, rather than just tracking methods. Maybe it could be reparented to Category:CS1 properties? Folly Mox (talk) 15:16, 16 November 2024 (UTC)[reply]
    "many editors see maintenance categories as problems to fix" - most are problems to fix - missing title, "Editor" as author name or "Archived" as title, and so on. Best wishes, Pol098 (talk) 19:59, 16 November 2024 (UTC)[reply]
    I should have phrased my words more clearly. Yes, many / most maintenance categories (including subcats of Category:CS1 maintenance) are full of errors that require repair (phone suggested: full of beans). Maybe I should have differentiated between "maintenance" and "tracking" categories? The software doesn't. My point was that, specifically for the "unfit URL" category, usually the case is that the archive snapshot supports the cited claim, but the URL that used to point to the original now points to garbage. There's usually not a repair to be made, and it certainly isn't just changing the |url-status= value to one that doesn't emit a message. The fact that an editor of nineteen years with a huge volume of citation gnoming had such a misunderstanding is a signal for more clarity around unfit / usurped URLs. Folly Mox (talk) 21:00, 16 November 2024 (UTC)[reply]
    User:Folly Mox, maintenance message for these url-status values should be suppressed. Is this occurring at the MediaWiki level outside our (Enwiki) immediate control? -- GreenC 00:58, 17 November 2024 (UTC)[reply]
    The message is emitted by Module:CS1. I think it's hidden for people who don't have the custom css set up to display CS1 maintenance messages. Subcats of Category:CS1 properties each seem to require their own custom css, which makes surfacing them even more intentional for interested editors. Presumably such editors would understand that no action is required for this property. Folly Mox (talk) 03:06, 17 November 2024 (UTC)[reply]
    If there are CS1 maintenance messages when an edit is previewed without CS1 messages set to display, there is a prominent notice like "Script warning: One or more {{cite book}} templates have maintenance messages; messages may be hidden (help).", with no indication of what cites are the cause. And, with CS1 messages displayed, a message like "missing publisher" looks a lot more like an error than just a comment. Best wishes, Pol098 (talk) 20:26, 17 November 2024 (UTC)[reply]
    User:Folly Mox, that's good. Do you think an RfC to disable it, for some or all, would be appropriate? Otherwise this thread will have no result. I can start it, unless there is strong objection to the idea of even having an RfC. -- GreenC 00:49, 18 November 2024 (UTC)[reply]

    "Ambiguous" numerical month dates leading to many errors

    [edit]

    This topic has been brought up at least twice, Help talk:Citation Style 1/Archive 33#edtf date formats as cs1|2 date parameter values and Help talk:Citation Style 1/Archive 44#Fix the date formatting, but to no avail.

    Many scientific journals use YYYY-MM format dates and don't bother that they might be interpreted as a range of two years (it's almost impossible in this context). These dates are imported by a gadget which automatically converts URLs into cite templates, but this type of format is prohibited on Wikipedia, leading to CS1 errors. I don't know which gadget is that and where is its talk page so I decided to write here.

    Why wouldn't anyone fix the issue? There are so many possible solutions: automatically convert to the desired format (which is what currently done manually by Ira Leviton, Paul2520 and perhaps some other users, I'm pretty sure they have never seen a single YYYY-YY date), show an error etc. 5.178.188.143 (talk) 21:06, 14 November 2024 (UTC)[reply]

    P. S. And by the way, Citation bot apparently makes such changes in an entirely automatic fashion, without ever verifying that the date was actually YYYY-MM not YYYY-YY.

    It is always helpful to link to example diffs, or pages with a problem, when reporting an issue. Please do so. – Jonesey95 (talk) 14:23, 16 November 2024 (UTC)[reply]
    https://wiki.riteme.site/w/index.php?title=Steven_Kistler&diff=prev&oldid=1257506607 5.178.188.143 (talk) 16:05, 16 November 2024 (UTC)[reply]
    That diff shows Citation Bot fixing an unambiguous YYYY-MM problem. – Jonesey95 (talk) 02:10, 17 November 2024 (UTC)[reply]
    According to a thread a few up from one of the ones mentioned in the OP, this "gadget" is Citoid, the Foundation's essentially unmaintained citation problem generator.[uncharitable characterisation] Tracked at phab:T132308 (2016, Open, High priority, no assignee). Folly Mox (talk) 15:32, 16 November 2024 (UTC)[reply]
    What's wrong with Wikimedia Foundation that they can't fix a high-priority bugs in eight years, aren't they swimming in money and volunteers? 5.178.188.143 (talk) 16:01, 16 November 2024 (UTC)[reply]
    To be fair, there was a lot of progress made in 2021, including global updates to the Citoid codebase and local updates to Module:CS1. The Foundation devs and contractors tend not to prioritise enwiki specific concerns, and focus on things they presume will benefit all / many projects in the Wikimedia ecosystem.
    I don't think it would be super unreasonable if the Module were updated to convert YYYY-NN to month year when NN is in the range (01,12). Citing a year range with an ambiguous abbreviated terminus is fair game for miscorrection.
    But, it's easy for me to say that, since I've never actually touched the code and have no responsibility to update it when features are requested. I might also be wrong about the surrounding issues, having not fully read through Wikipedia talk:Manual of Style/Dates and numbers/Archive 160 § ISO 8601 YYYY-MM Calendar Date Format (June 2020). Folly Mox (talk) 17:42, 16 November 2024 (UTC)[reply]
    The issue is that formats like 2010-11 cannot be interpreted automatically by the module because they are ambiguous. Someone needs to figure out what the original intent of the date is, because that information is not present in the text. Is it supposed to be 2010–2011 or November 2010? Because the module does not have the information to disambiguate it, it should not try. —David Eppstein (talk) 20:04, 16 November 2024 (UTC)[reply]
    It's never, ever 2010-2011 5.178.188.143 (talk) 10:14, 17 November 2024 (UTC)[reply]

    It's not an error or bug. ISO 8601 style dates (yyyy-mm and yyyy-mm-dd) are common in many parts of the world and progressively becoming more common in English speaking parts of the world - at least for official forms, engineering and multinational organisations. Among other reasons, I love it for putting dates in computer file names because it also sorts alphabetically. According to WP:DATERANGE, year ranges should be written as 1881–1886, not 1881–86 - so you should never have a year range like 2010-11. If you do see 2010-11 then look around and see if there are other dates like 2010-05 (obviously not a valid year range). The cite templates know about ISO 8601 style dates, so if you have {{use dmy dates}} or {{use mdy dates}} at the top of the article then the cite templates will transform it into the appropriate style.  Stepho  talk  10:42, 17 November 2024 (UTC)[reply]

    Cite dictionary issue with entry-url

    [edit]

    {{cite dictionary |dictionary=[[Oxford English Dictionary]] |entry-url=http://www.oed.com/view/Entry/135679?rskey=7ZL0rI&result=3&isAdvanced=false |entry-url-access=subscription |title=oxymoron |url=https://www.oed.com/dictionary |access-date=26 February 2013}}

    renders as

    "oxymoron". Oxford English Dictionary. Retrieved 26 February 2013.

    The rendered citation uses the value of |url=, not, as expected, |entry-url=. Paradoctor (talk) 19:37, 16 November 2024 (UTC)[reply]

    Too many urls:
    {{cite dictionary |dictionary=[[Oxford English Dictionary]] |entry-url=http://www.oed.com/view/Entry/135679?rskey=7ZL0rI&result=3&isAdvanced=false |entry-url-access=subscription |entry=oxymoron |access-date=26 February 2013}}
    "oxymoron". Oxford English Dictionary. Retrieved 26 February 2013.
    Trappist the monk (talk) 19:57, 16 November 2024 (UTC)[reply]
    Thanks! Paradoctor (talk) 20:23, 16 November 2024 (UTC)[reply]

    :A comment about the documentation: while |entry-url= isn't included in the listed parameters, it is discussed, and the use of both |url= and |entry-url= in an example is given (dictionary is an alias of encyclopedia):

    • "{{cite encyclopedia |encyclopedia=Biographical Memoirs |volume=82 |date=2003 |given=Arnel R. |surname=Hallauer |entry=John David Axtell |publisher=[[National Academies Press]] |publication-place=Washington, D.C. |language=en |url=https://www.nap.edu/catalog/10683/biographical-memoirs-volume-82 |entry-url=https://www.nap.edu/read/10683/chapter/2}}
      Hallauer, Arnel R. (2003). "John David Axtell". Biographical Memoirs. Vol. 82. Washington, D.C.: National Academies Press.

    Above is an example of using {{para|entry-url}} to link to the cited entry in the encyclopedia while also using {{para|url}} to link to the encyclopedia as a whole."

    Best wishes, Pol098 (talk) 20:37, 16 November 2024 (UTC)[reply]

    In OP's example, it is not possible to use |url= to link the [dictionary] as a whole because |dictionary=[[Oxford English Dictionary]]; you cannot link the Oxford English Dictionary text to two separate targets at the same time.
    Trappist the monk (talk) 20:58, 16 November 2024 (UTC)[reply]
    [edit]

    Category:Articles with Moldovan-language sources (ro-md), which uses Template:CS1 language sources (which talk page redirects here) has an error.

    Gonnym (talk) 13:52, 17 November 2024 (UTC)[reply]

    That was Editor Error living up to their username. {{CS1 language sources}} is for categories with the name structure:
    Category:CS1 <language name>-language sources (<tag>)
    For categories with the name structure:
    Category:Articles with <language name>-language sources (<tag>)
    use {{Non-English-language sources category}}.
    Preview is your friend; use it.
    Trappist the monk (talk) 15:12, 17 November 2024 (UTC)[reply]
    Sorry. It seems I copied from the wrong page and I didn't understand the error message. --Error (talk) 00:32, 18 November 2024 (UTC)[reply]

    Double-checking regarding year disambiguation

    [edit]

    When a citation uses a letter e.g. |year=1997a, the COinS metadata is unaltered, right? Remsense ‥  18:17, 17 November 2024 (UTC)[reply]

    {{cite book |title=Title |date=1997a}}
    '"`UNIQ--templatestyles-000001DE-QINU`"'<cite class="citation book cs1">''Title''. 1997a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1997&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
    Title. 1997a.
    Trappist the monk (talk) 18:25, 17 November 2024 (UTC)[reply]
    Thank you! I guess I meant to clarify that this format has the intended, recommended effect, but since it's plainly listed I'm not quite sure what I was worried about. Remsense ‥  18:28, 17 November 2024 (UTC)[reply]

    URL for original edition of book

    [edit]

    There is a book where only the original edition has an open access online copy, seen at {{Kelley 1975}} (created for use with {{sfn}}). The URL links to the 1955 edition, but the citation includes information about both the 1st (via |orig-date) and 2nd editions. Should there be an |orig-url, or is there a concise way to indicate that a link is to an older edition in {{cite book}}? Tule-hog (talk) 18:53, 17 November 2024 (UTC)[reply]

    Don't confuse the reader by specifying the second edition and then linking to the 1955 (1st?) edition. Those are two different sources with different bibliographic details so cite the one you consulted, You can modify the template so that you can specify one or the other but don't mash two sources into one template.
    Trappist the monk (talk) 19:10, 17 November 2024 (UTC)[reply]
    (Yes - 1st=1955, 2nd=1975.) Given the two editions are page-for-page almost identical, wouldn't it be to the benefit of readers and editors to include the link? The book is cited across many articles, and it seems unclean to include both editions separately on each just for the sake of supplying a link, and best practice to cite the most recent edition regardless of availability (with some exceptions). Tule-hog (talk) 19:35, 17 November 2024 (UTC)[reply]
    (Apologies if I misinterpreted and you were referring to modifying {{cite book}}!) Tule-hog (talk) 19:36, 17 November 2024 (UTC)[reply]
    That is still two sources with two separate and different sets of bibliographic details:
    Kelley, John L. (1955). General Topology. New York: D. Van Nostrand.
    Kelley, John L. (1975). General Topology (2nd ed.). New York: Springer-Verlag. ISBN 978-0-387-90125-1.
    Were the bibliographic details the same edition-to-edition, then |orig-date=1955 and |url=https://archive.org/details/GeneralTopologyJohnL.Kelley might be acceptable. As those details are not the same edition-to-edition, I do not think that |orig-date= and |url= are appropriate.
    You might change the template so that it renders something like this:
    Kelley, John L. (1975). General Topology (2nd ed.). New York: Springer-Verlag. ISBN 978-0-387-90125-1. (1955 edition)
    This complies with the one-source-one-template rule and still gives you the link to the first edition.
    Trappist the monk (talk) 22:45, 17 November 2024 (UTC)[reply]