Jump to content

Help talk:Citation Style 1

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

This is an old revision of this page, as edited by 65.88.88.70 (talk) at 20:46, 9 January 2023 (→‎Mark as accessible through Wikipedia Library: About-turn.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

    Must translation parameters use the translations in the text?

    When a text is published with a translation, must |trans-quote= and similar parameters use the translation in the text, or may an editor substitute a translation that she believes to be more accurate? This question is prompted by https://en.wikipedia.org/w/index.php?title=Hillel_the_Elder&curid=313892&diff=1125022169&oldid=1124176915, which I believe to be WP:OR. Either way, it would be helpful if the documentation of, e.g., |trans-title=, specified whether editors must respect the translations in the text. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:50, 2 December 2022 (UTC)[reply]

    Yes, use the text, Quotes should be verbatim. Editor interpolations are allowed only for context, for example when substituting a generic "he" in the quote with the actual name of the person/character. The translated title is part of the work's publication data and the citation's retrieval data. Should be entered as is at all times. 50.75.226.250 (talk) 16:05, 2 December 2022 (UTC)[reply]
    Chatul, I run into this from time to time. First, let me just agree with the above; use the quote exactly as it appears. But it's possible to mitigate any ill effect, if you feel that it could be problematic. My response in similar situations depends on the severity of the problem. If it's just a poor translation, or an annoying issue such as false friends confusion that doesn't really interfere with understanding, then I just let it go. If I believe that the translation is inaccurate or ambiguous in a way that could affect the article or its verifiability, then I might add a Talk page section "Possibly inaccurate translation" or similar, and then add a {{clarify}} template to the article immediately after the citation and include the |reason= and |post-text= parameters, linking the template to the Talk section you just added. Mathglot (talk) 19:40, 22 December 2022 (UTC)[reply]
    My issue was the opposite; there was an inline translation that I considered problematical, and I added English[a] and Hebrew quotes directly from the text of the cited book rather than start an edit war over the translation in the body of the article. The other editor proceeded to change the |trans-quote= in the {{cite book}}; I view that as close to vandalism. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:26, 22 December 2022 (UTC)[reply]

    Notes

    1. ^ The text used the word only, which was not in the Hebrew text, but enclosed it in brackets.

    Which ISBN?

    I'm adding details to a citation, and the publisher shows

    • ISBN-10: ISBN 0738457256
    • ISBN-13: ISBN 9780738457253

    The documentation doesn't show |isbn-10= and |isbn-13= parameters. Which ISBN goes in the |isbn= parameter? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:39, 8 December 2022 (UTC)[reply]

    See ISBN documentation.
    —Trappist the monk (talk) 16:53, 8 December 2022 (UTC)[reply]
    When the 13 digit one is actually printed, use it over the 10 please. — xaosflux Talk 17:27, 8 December 2022 (UTC)[reply]
    Yes!  Done Sadhuguru (talk) 13:01, 24 December 2022 (UTC)[reply]

    Add "admin" to generic names

    Found at Earlimart pesticide poisoning * Pppery * it has begun... 00:05, 13 December 2022 (UTC)[reply]

    Error in CS1 on clean mediawiki install; Lua error in Module:Citation/CS1 at line 2561: attempt to call field 'hyphen_to_dash' (a nil value)

    Hi, the current version of CS1 causes the following error on a clean mediawiki install:

    Lua error in Module:Citation/CS1 at line 2561: attempt to call field 'hyphen_to_dash' (a nil value).

    Reverting this edit fixes it locally: https://en.wikipedia.org/w/index.php?title=Module%3ACitation%2FCS1&type=revision&diff=1017669505&oldid=1017041380

    This is the line in question: 

    if not utilities.in_array (config.CitationClass, cfg.templates_not_using_page) then
Page = A['Page'];
Pages = utilities.hyphen_to_dash (A['Pages']);
At = A['At'];

    Mvolz (talk) 11:20, 13 December 2022 (UTC)[reply]

    Clearly this clean mediawiki install (which I understand to be an installation on a MediaWiki site that has never had the cs1|2 module) did not happen at en:Module:Citation/CS1 so where did it happen?
    The diff you gave fixes an issue with utilities.has_accept_as_written(). That function returns two values (a string and a boolean). return utilities.has_accept_as_written (str) will return both which, if both are not required or handled by the calling function cause confusion. For the avoidance of confusion, the fix shown in the diff assigns the string returned by utilities.has_accept_as_written() to temp_str and then returns temp_str.
    The Lua error in Module:Citation/CS1 at line 2561: attempt to call field 'hyphen_to_dash' (a nil value) error message suggests that wherever this clean mediawiki install is, it doesn't have the current version of Module:Citation/CS1/Utilities. The has_accept_as_written() function is at line 121. If your clean mediawiki install does not have has_accept_as_written() in its Module:Citation/CS1/Utilities then the ~/Utilities module is the wrong version.
    —Trappist the monk (talk) 14:24, 13 December 2022 (UTC)[reply]

    Please update broken mr= link address

    {{MR}} has used urls of the form https://mathscinet.ams.org/mathscinet-getitem?mr=1470715 since October 2017, and these currently work. The citation templates, for the |mr= parameter, instead currently use urls of the form https://www.ams.org/mathscinet-getitem?mr=1470715, and these currently give a 404 error. Can we fix the links to match {{MR}}, please? —David Eppstein (talk) 05:36, 14 December 2022 (UTC)[reply]

    Both work here. Headbomb {t · c · p · b} 18:59, 14 December 2022 (UTC)[reply]

    Policy for wikilinking

    What is the policy for adding internal wikilinks to the website= parameter for example? Should only the first reference from that website be linked? Or none or alle of them? PhotographyEdits (talk) 15:03, 14 December 2022 (UTC)[reply]

    I believe the answer you'll get is that there isn't a policy. Some editors will only include a wikilink on a first reference, some will include it on every reference, and some will not include one at all. Imzadi 1979 → 16:49, 14 December 2022 (UTC)[reply]
    @Imzadi1979 Ah, the reason I asked is that I wanted to write a bot that will link all of them automatically. If I'm going through Wikipedia as a whole, that means I'm creating a de facto policy. PhotographyEdits (talk) 17:08, 14 December 2022 (UTC)[reply]
    I personally would oppose such a bot, and were it to edit on an article I've been maintaining, I'd revert such an edit. I think of the reference section similar to how I think about the rest of the article. I minimize the number of extra links in that section to push readers toward clicking the important links, which in that case are the external links to the specific sources. Extra links dilute the importance of the links that are there.
    I do see some merit in wikilinking publishers and publication names, so that's why I keep to just first mentions as a balance when I do include them. Imzadi 1979 → 17:36, 14 December 2022 (UTC)[reply]
    @Imzadi1979 So what about a bot that would wikilink the first occurrence of every publisher used in the references of an article? That sounds like what you're doing right now. If you'd oppose that, why? PhotographyEdits (talk) 19:11, 14 December 2022 (UTC)[reply]
    I still think a bot is a bad idea, even for that. Bots follow consensus, and yours would attempt to create it as a fait accompli. I'm sure it would be considered disruptive, either because some editors think that lots of wikilinks in references are better, or that no wikilinks in references are better. So there are two camps of editors that would be potentially upset if a bot came and made changes to articles on their watchlists.
    Now some sort of user script that could do the same thing may be helpful so editors can restore such a convention after a period of expansion or editing. Imzadi 1979 → 19:41, 14 December 2022 (UTC)[reply]
    Such a bot would likely not achieve consensus. There are other thing you should spend your time on. Bots don't get to make their own consensus, they implement a user-created one. Izno (talk) 17:46, 14 December 2022 (UTC)[reply]
    @Izno If there currently isn't a consensus, then such a bot would not go against a consensus as well right? PhotographyEdits (talk) 19:33, 14 December 2022 (UTC)[reply]
    Bots need to be approved before they're allowed to operate widely. That approval requires consensus for the desired activity. This isn't a case where you'd get to ask for forgiveness instead of permission. Imzadi 1979 → 19:42, 14 December 2022 (UTC)[reply]
    ^. Please read WP:BOTPOL. Izno (talk) 19:46, 14 December 2022 (UTC)[reply]
    Thanks! PhotographyEdits (talk) 19:51, 14 December 2022 (UTC)[reply]

    CS1 maint: location

    I was recently made aware that |location= and the like do not allow any digits to prevent misuse of the parameter, such as inserting page- and chapter numbers or unnecessary postal codes. But what if the number is essential to the location, say, 10 Downing Street? ~~lol1VNIO (I made a mistake? talk to me) 21:19, 17 December 2022 (UTC)[reply]

    Please link to an actual article where this need would be present. Without seeing an actual article, my guess is that |location=London would suffice. – Jonesey95 (talk) 21:40, 17 December 2022 (UTC)[reply]
    Ref 133 of this article (permalink). I guess London does work but I think it's a bit of a shame that we can't be more specific. ~~lol1VNIO (I made a mistake? talk to me) 21:46, 17 December 2022 (UTC); edited 22:08, 17 December 2022 (UTC)[reply]
    Traditionally the location in a citation is the city of publication, which would just be London. We wouldn't list the address of the publisher.
    If we're thinking about the original utterance of a speech as its publication, then the location would be where it was given, which is "Guildhall, London", not 10 Downing Street, and not the Prime Minister's Office. But in this case, you're citing a transcript published from elsewhere, so trying to be more specific is just confusing or inaccurate.
    The publisher is the Prime Minister's Office, or 10 Downing Street if you want to use the residence as a metonym for the office (like The White House substitutes for the Executive Office of the President on this side of the pond). In short, your best option is |location=London |publisher=Prime Minister's Office. Imzadi 1979 → 23:20, 17 December 2022 (UTC)[reply]
    Some older works do list addresses on the title page, although these were usually where they were to be sold. eg Sir John Oldcastle, the location is London, but the publishers part says, "Printed by V.S. for Thomas Panier, and areto be ſolde at his ſhop at the ſigne of the Catte and Parrots neere the Exchange."--Auric talk 18:38, 20 December 2022 (UTC)[reply]

    Book belonging to multiple series?

    Are there provisions in the template for referring to multiple series when a book is listed as part of more than one series? For example, Itineraria Phoenicia is the volume 127 of the Orientalia Lovaniensia analecta series and the volume 18 of the Studia Phoenicia series. But I am not sure how to add both of these to the template when using it in articles. Antiquistik (talk) 11:12, 18 December 2022 (UTC)[reply]

    In general, one should list the one that is more readily available, which usually is the one more often classified in providers' metadata. For example, at the WorldCat entry the work is classified under "Series: Orientalia Lovaniensia analecta". 67.243.247.14 (talk) 16:47, 18 December 2022 (UTC)[reply]
    I would still request for provisions to be added to the template so that multiple series can be mentioned when using the template, because doing so would in fact facilitate doing research regarding citations as well as navigation. Antiquistik (talk) 22:41, 1 January 2023 (UTC)[reply]

    access-date and Gale links

    Is there any reason to include an access-date parameter if the only outbound link is a Gale ID generated thru Template:Gale? I'm getting the error message. My assumption is that there isn't a reason to include access-date because Gale is an archive and the content shouldn't change, but I thought I'd double check. ThadeusOfNazereth(he/him)Talk to Me! 17:14, 18 December 2022 (UTC)[reply]

    Please post the CS1 error message. Otherwise your assumption is correct. Citations of stable-link repositories such as Gale should not display an access date. 204.19.162.34 (talk) 21:09, 18 December 2022 (UTC)[reply]
    The error message is "access-date without URL" - And thanks, that's what I figured. ThadeusOfNazereth(he/him)Talk to Me! 23:43, 18 December 2022 (UTC)[reply]

    Postal abbreviations

    H:CS1 currently says Do not use sub-national postal abbreviations ("DE", "Wilts", etc.), per MOS:POSTABBR. This does not appear to actually be consistent with MOS:POSTABBR, which provides Postal codes and abbreviations of place names—e.g., Calif. (California), TX (Texas), Yorks. (Yorkshire)—should not be used to stand for the full names in normal text (emphasis added). References are not normal text, and are often allowed to deviate from abbreviation-related aspects of MoS. See e.g. MOS:&. This also does not appear to be consistent with current practice, even in FAs. I count 174 featured articles matching the regex location *= *New York( City)?(\]\])?, N\.?Y\.?; 38 for location Boston(\]\])?, M(A|ass[^a]); 25 for San Francisco(^\]\])?, (CA|alif[^o]); etc. It also doesn't seem consistent with common sense: One, because we abbreviate all sorts of things in references, and it's not clear why we would suddenly break with that practice for locations, even when something like "CA" for California is probably more recognizable than "eds." And two, because we allow location strings consisting only of city name (with fairly vague guidance as to when it's acceptable), creating a paradoxical situation in which "Boston" is allowed but the less ambiguous "Boston, MA" and "Boston, Mass." are not.

    If this guidance must be kept, we should at a minimum remove the reference to a part of MoS that does not apply. But I would submit we should go further and remove the line outright, for the reasons outlined above—or walk it back to something like Do not use obscure or made-up abbreviations for place names. -- Tamzin[cetacean needed] (she|they|xe) 07:39, 19 December 2022 (UTC)[reply]

    Perhaps it is best left to the individual citation writer to choose between an official abbreviation and the official locale name. The MOS:POSTABBR reference should be removed from the doc for this case, perhaps with guidance to use only official nomenclature, and the (obvious but necessary) remark that full names are non-ambiguous.
    As an aside, I do not consider usage in Wikipedia an indication of anything. CS1 template elements are decided primarily here by anyone willing to participate. The fact that editors choose to divert from suggested usage could be for a variety of reasons that may or may not be valid. I presume anyone really interested could come here to state their case for consideration, just like you did. 65.88.88.179 (talk) 16:55, 19 December 2022 (UTC)[reply]
    MOS:POSTABBR does apply everywhere except for the allowances it makes for limited space, which does not include citations, so the guidance here is consistent. Abbreviations of states are non-standard and not universally known; there's no reason to use them. -- Michael Bednarek (talk) 01:30, 20 December 2022 (UTC)[reply]
    Citations are classically included in the set of items where there is limited space, hence why ISO dates are allowed here. Izno (talk) 01:39, 20 December 2022 (UTC)[reply]
    So you argue in line with Tamzin for the removal of that passage from H:CS1? And allow "Boston, MA", "Boston, Mass.", "San Francisco, CA", "San Francisco, Calif.", "Grafton, NSW", "Gronau, NRW", "Stanstead, Que."? -- Michael Bednarek (talk) 02:35, 20 December 2022 (UTC)[reply]
    I was clarifying your possibly ambiguous statement on whether citations are considered to be a limited space case. They are, hence we allow ISO dates. The reason I call it possibly ambiguous is because I am not sure on a second reading that you are noting that the allowance provided in the context of POSTABBR is only for tables, which are one kind of limited space, or whether you thought that citations are indeed not a limited space. Izno (talk) 03:37, 20 December 2022 (UTC)[reply]
    The exception in POSTABBR does not extend to all instances of limited space beyond tables - it specifically notes they should not be used in infoboxes, for example, whereas MOS:DATE includes those as instances where space is limited. Thus the current text is appropriate. (As an aside, POSTABBR states that in the space-limited-exception case these abbreviations should be marked up using {{abbr}} - while I have seen citations using postal abbreviations, I don't think I've ever seen that markup applied to them there). Nikkimaria (talk) 03:57, 20 December 2022 (UTC)[reply]
    On the aside, I am neither surprised about the suggestion to mark them up with abbr nor surprised to see that it's never used (and I have observed similarly). I'd say it's probably one of those cases where the context of an address is clear so users don't think it's needed, and usually the user can click to the article on the local region to understand more about the pair of letters after the local region. Contrast EIT, as a particular example, which has multiple meanings, some of which may be applicable in more contexts than not, being dropped in an article (I was thinking Engineer in Training [I'm glad to see the exam is now only 6 hours long instead of the 8 hour day it was when I skipped taking the voluntary exam during college]). Izno (talk) 17:10, 20 December 2022 (UTC)[reply]
    If POSTABBR is supposed to apply to everything but tables, it should be rewritten to apply to everything but tables. As currently written, there's no "table exception": Rather, the complete prohibition only applies in normal text and in infoboxes, while a separate rule (use {{abbr}}) applies in tables, and no rule is specified for other space-limited areas. -- Tamzin[cetacean needed] (she|they|xe) 22:24, 20 December 2022 (UTC)[reply]
    A specification related to references was unilaterally removed a couple of months ago. Nikkimaria (talk) 01:51, 21 December 2022 (UTC)[reply]
    @Nikkimaria: Ah yeah, I see Why? I Ask removed it citing lack of consensus, pending a full RfC. Is it maybe time to have that RfC? -- Tamzin[cetacean needed] (she|they|xe) 20:10, 21 December 2022 (UTC)[reply]
    It was removed because it had been discussed before, never found consensus to be added, and yet it was. That's WP:CREEP if I ever. Personally, this whole thing is silly. No reader (especially one that looks at a source's location) will be confused by something such as "San Francisco, CA". If there is such a confusion between terms (e.g., Leipsic, DE referring to either Germany (Deutschland) or Delaware), then just use common sense and write it in full. Such a case is so rare that it won't matter for 99% of the articles that it applies to. Let the article editor decide. Why? I Ask (talk) 21:22, 21 December 2022 (UTC)[reply]
    Cambridge MA - is it a degree or a place? DuncanHill (talk) 23:09, 21 December 2022 (UTC)[reply]
    If it's placed where the location parameter is, then it's a no brainer. Why? I Ask (talk) 23:38, 21 December 2022 (UTC)[reply]
    The reader of a thesis citation doesn't see to which parameter "Cambridge MA" applies. -- Michael Bednarek (talk) 02:59, 22 December 2022 (UTC)[reply]
    No, you don't need to see the parameter, you just need to know what a citation looks like. However, as I said, in that case that applies to less that 0.1% of articles, sure, expand it to say Massachusetts. Why? I Ask (talk) 03:19, 22 December 2022 (UTC)[reply]
    Not true. Location is always followed by colons and the value in |publisher=, it is meaningless otherwise. There is scarce chance for ambiguity there. 172.254.255.250 (talk) 14:41, 22 December 2022 (UTC)[reply]
    |location= is sometimes used, especially in {{cite news}}, as a disambiguator for same-named newspapers (The Times for example):
    {{cite news |author=EB Green |date=22 December 2022 |title=Title |newspaper=The Times |location=Chicago |page=B3}}
    EB Green (22 December 2022). "Title". The Times. Chicago. p. B3.
    No colon; no publisher.
    —Trappist the monk (talk) 15:12, 22 December 2022 (UTC)[reply]
    But then why would a degree be listed for a newspaper? Still no chance of confusion. Why? I Ask (talk) 15:19, 22 December 2022 (UTC)[reply]
    What? I'm pretty sure that I said nothing about a degree. I was referring to IP editor's statement: Location is always followed by colons and the value in |publisher=. That is not wholly true as my example shows.
    —Trappist the monk (talk) 15:27, 22 December 2022 (UTC)[reply]
    Read up further in the chain; other editors are complaining that there would be a confusion between the degree Master of Arts (Oxford, Cambridge, and Dublin) and the location, Cambridge, MA. I find that highly dubious with the layout of the citations. Why? I Ask (talk) 16:03, 22 December 2022 (UTC)[reply]
    Yes, I know that. Nothing in what I have written is or was intended to address those complaints so why are we having this discussion? If you want to discuss confusion between the degree ... and the location, you should be responding to posters who are discussing those things.
    —Trappist the monk (talk) 16:35, 22 December 2022 (UTC)[reply]
    Then |location= itself is ambiguous because it may refer either to the place of publication or to the place of the publisher (as a commercial entity), which may be different. So either have |publisher-location= and |publication-place=, or fix |location= to mean "publisher location" (i.e. make it a conditional parameter dependent on |publisher=) and disambiguate newspapers in another manner, perhaps following MOS (parenthetical location after title). 65.88.88.69 (talk) 19:54, 22 December 2022 (UTC)[reply]
    At least one example of a {{cite news}} template using |location= to disambiguate |newspaper= can be seen at Template:Cite news/doc § Examples so apparently that sort of use of |location= is not new.
    When used alone, |publication-place=, |place=, and |location= function identically. The confusion arises when |publication-place= is used with either of |location= or |place= which confusion I should like to see go away by making these three parameters equal aliases of one another (something that I have periodically raised on these talk pages in the past – last discussion that referred to that is at Help talk:Citation Style 1/Archive 86 § place, when publication-place is redundant with work).
    No doubt, no doubt, the template documentation can be improved so please do so.
    —Trappist the monk (talk) 23:22, 22 December 2022 (UTC)[reply]
    Generally, move away from aliases. Citations are (supposed to be) exact, unambiguous statements and are understood best with unique parameter labels. Aliases make sense as transition aids when code labels are new and the old way is grandfathered in temporarily. In other programming situations aliases may be important as related terms may actually (in the real world) be fuzzy, or have multiple applications. In a well-designed system you would never find a generic code label like "location". As you pointed out in the news example it could mean publisher location. Or it could mean publication place. These are two different attributes and if it is decided that both should be available then what is needed are separate labels applied to different parameters. Otherwise the winning combination is publisher location. Publisher information is unique and authoritative in the sense that place(s) of publication derive from the publisher entity. 24.193.2.168 (talk) 01:27, 23 December 2022 (UTC)[reply]
    Generally, move away from aliases. Right. Don't hold your breath; that cow has been out of the barn for far too long.
    —Trappist the monk (talk) 14:01, 23 December 2022 (UTC)[reply]

    Indeed. But let's not add more. Perhaps it is better to think of adding CS3, built with the hopeful view that all the intractable design glitches that have nothing to do with technical issues could be swept away in a clean slate. And let the best solution win. 24.168.89.97 (talk) 20:51, 23 December 2022 (UTC)[reply]

    I don't know how one could call official state abbreviations, or any postal abbreviation, "non-standard". They are designated by a proper naming authority and applied widely. 65.88.88.59 (talk) 16:32, 20 December 2022 (UTC)[reply]
    But limited to a specific geographical area, vs something like "UK" which is international. Nikkimaria (talk) 01:51, 21 December 2022 (UTC)[reply]
    Why is this discussion here? The use of postal abbreviations is not a cs1|2-specific issue is it? Doesn't this also apply to hand-crafted citations so wouldn't a better place for this discussion be at perhaps WT:CITE?
    —Trappist the monk (talk) 15:12, 22 December 2022 (UTC)[reply]
    The original comment makes the implication that there is something wrong with how Help:CS1 describes use of the relevant policy. Hence the followon discussion on whether the policy is of interest.
    I think given the discussion about an RFC above that people are tending toward a discussion elsewhere, they just haven't gotten there yet. :^) Izno (talk) 17:18, 22 December 2022 (UTC)[reply]
    It is not useless. For example, I just found out that |location= may mean two different things, something that should be fixed. 65.88.88.69 (talk) 19:57, 22 December 2022 (UTC)[reply]

    Wikilink and external link

    I have come across an unusual situation where the book I want to cite has a Wikipedia article and there is an external source where the book can be viewed freely. Is there any way to link both the Wikipedia article and the external source in the citation? Obi2canibe (talk) 22:10, 20 December 2022 (UTC)[reply]

    Only if the external source can be reached through a content-resolving identifier such as doi. The book article ideally should have an external url link to the book if one exists, and you can link the book article. Following the link, readers will eventually have access to the url. Alternately, use |url= and forgo |title-link=. 24.103.241.218 (talk) 22:33, 20 December 2022 (UTC)[reply]
    A citation doesn't have to restrict itself to what citation templates provide. Adding (online) after the template will do what you want. -- Michael Bednarek (talk) 01:39, 21 December 2022 (UTC)[reply]
    Thank you both for your suggestions.--Obi2canibe (talk) 19:48, 22 December 2022 (UTC)[reply]

    DOI "inactive"

    Trying to overhaul Howard Florey and getting a warning: CS1 maint: DOI inactive as of October 2022. How do you suppress this warning? Obviously we can just drop it but I keyed it in to the university system and it came up okay, via the Wiley Online Library. Looks like a "virtual" doi. Hawkeye7 (discuss) 03:18, 26 December 2022 (UTC)[reply]

    Fix the doi and then unset or remove |doi-broken-date=. The actual doi appears to be doi:10.1038/npg.els.0002792 not doi:10.1038/png.els.0002792.
    —Trappist the monk (talk) 03:53, 26 December 2022 (UTC)[reply]
    ...which was broken by [1] DMacks (talk) 04:09, 26 December 2022 (UTC)[reply]
    Oh. I see. Thanks for that. Hawkeye7 (discuss) 04:51, 26 December 2022 (UTC)[reply]

    CS1 errors: URL

    Category:CS1 errors: URL has about 6,500 pages even after I run my bot through them. Is there a way to generate a report with the most common errors, so we can see if we can fix them via bot? Thanks! GoingBatty (talk) 06:08, 2 January 2023 (UTC)[reply]

    I can separate out the text warnings with url and archive-url, but there's nothing else in the output today to indicate which of the errors triggered. Izno (talk) 06:26, 2 January 2023 (UTC)[reply]
    @Izno: Thanks for that suggestion. Some of the |archive-url= errors occur when |archive-url= is a duplicate of |url=, so that's something to look into. There's also a few chapter-url and contribution-url issues. Thanks! GoingBatty (talk) 07:07, 2 January 2023 (UTC)[reply]

    Dates: first, reprint and PDF

    If a book is published on foo, reprinted on bar and scanned from the bar printing on baz, what date parameters are appropriate for citing the baz PDF of bar? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:19, 4 January 2023 (UTC)[reply]

    I think the specifics might be helpful here instead of variables, I could see it either being the original publication date if the reprint is just a later impression within the same edition (or some sort of print on demand type thing), or the reprint date if, say, this is an entirely new publication (e.g., a facsimile production of a historical book, in which case also use |orig-date=). Umimmak (talk) 15:30, 4 January 2023 (UTC)[reply]
    I concur with the above. If I understand correctly, you are citing a reprint edition of a book that is bound digitally. The content is provided by the "printer". I would do something like this:
    {{cite book|year=2022|orig-year=oroginally published 2021 by Foo|title=Title|url=http://www.example.com/example.pdf|edition=reprint|publisher=Bar|via=Baz}}
    • Title (PDF) (reprint ed.). Bar. 2022 [originally published 2021 by Foo] – via Baz.
    The (media/binding) |type= here would be "pdf", but this is preformatted in the citation (the parameter |format= would be superfluous for the same reason). Even though binding info is not included in CS1/2 metadata, you may want to include one of these parameters anyway, in case some aggregator imports the citation texts themselves, in which case the format/binding icon will not display.
    50.75.226.250 (talk) 16:02, 4 January 2023 (UTC)[reply]
    In my question, foo, bar and baz were all dates, so |orig-year=oroginally published 2021 by Foo and |via=Baz would be inappropriate. What inspired my question was edit https://en.wikipedia.org/w/index.php?title=Newline&curid=238775&diff=1131455576&oldid=1121592635, which includes the comment PDF date=1 August 2002 in the {{cite book}} template Qualline, Steve (2001). Vi Improved - Vim (PDF). Sams Publishing. p. 120. ISBN 9780735710016. Archived from the original (PDF) on 8 April 2022. Retrieved 4 January 2023..
    Well here it might be that the |url= is just a convenience link for the reader. The book itself was published in 2001 as far as I can tell from WorldCat OCLC 247896918. Kind of frustrating that this PDF seems to lack the frontmatter with the actual date and copyright information, but the comment I guess got the date from metadata and is just making a note on the off chance this PDF is not the exact same as the book. Umimmak (talk) 16:32, 4 January 2023 (UTC)[reply]
    Sorry for my misunderstanding. Again I agree with Umimmak. Assuming the PDF is a fascimile transfer to digital, its creation date is immaterial for the reader. The useful date info is the publication date of the edition the PDF was based on. Also. for long works it is important that the title URL points to a location where the correct metadata is easily available: compare the landing page on Google Books. It seems the content in that citation is offered in "reader mode", which is perfect for in-source locations, but the front matter that includes relevant metadata is missing. 50.75.226.250 (talk) 17:07, 4 January 2023 (UTC)[reply]

    module suite update 14–15 January 2023

    I propose to update cs1|2 module suite over the weekend 14–15 January 2023. Here are the changes:

    Module:Citation/CS1:

    • ~/Suggestions v. ~Suggestions/sandbox selection tweak; discussion
    • added support for |article-number= in journal and conference cites; discussion
    • moved list of single-letter second-level TLDs to ~/Configuration/sandbox; discussion
    • annotated namelist entries when interwikilinked; discussion
    • fixed unexpected 'preprint' parameter required error; discussion
    • inhibited leading punctuation when |display-authors=0 / |display-editors=0 and |others= has a value; discussion
    • kerned leading and trailing quotes in |quote=; discussion

    Module:Citation/CS1/Configuration

    • i18n change for uncategorized namespaces; discussion
    • add script tags pa, tt;
    • add 'allmusic' to 'generic_names' list; discussion
    • added support for |article-number= in journal and conference cites;
    • created list of single-letter second-level TLDs from main module; added 'foundation';
    • updated emoji list; discussion
    • added 'Reuters', 'Business', 'CNN', 'Inc' and 'Inc.' to 'generic_names' list; discussion
    • changed Valencian-language tag from 'ca' to 'ca-valencia';

    Module:Citation/CS1/Whitelist

    • added support for |article-number= in journal and conference cites;

    Module:Citation/CS1/Date validation

    • limited CITEREF dab to |date=, |year=, |publication-date=; discussion

    Module:Citation/CS1/Whitelist

    • catch 1 & 2 digit doi registrants with subcode; discussion

    Module:Citation/CS1/COinS

    • added support for |article-number= in journal and conference cites;

    Module:Citation/CS1/styles.css

    • Removed linear-gradient on icons, not necessary when serving SVGs

    —Trappist the monk (talk) 16:48, 7 January 2023 (UTC)[reply]

    I support this update. It's been too long since the previous one (July 2022, if I am reading the notes correctly). – Jonesey95 (talk) 17:12, 7 January 2023 (UTC)[reply]

    Podcast dates range

    If you want to cite the dates a podcast runs from, how do you do that? Like |date=18 December 2020 – present? The field does not like that parameter and throws up errors. How do you do that without causing a problem? Eievie (talk) 01:02, 8 January 2023 (UTC)[reply]

    You should be citing a specific episode of the podcast, not the entire series. Izno (talk) 01:09, 8 January 2023 (UTC)[reply]
    It's for a bibliography listing someone's various different works. Using the {{cite book}} template in the list of someone's books is common practice; why not use the associated templates for rest of a person's works as well? Eievie (talk) 01:11, 8 January 2023 (UTC)[reply]
    Books also don't have continuing dates. :) This series of modules is primarily intended for citations and its use for bibliographies has kind of been grafted on.
    There is no way to add the date as you would prefer. You can probably cheat and use {{today}} but that will update somewhat sporadically, and also does not reflect specific publication dates. You could probably be relatively safe with {{year}} as in |date=2020–2024. Izno (talk) 01:34, 8 January 2023 (UTC)[reply]
    Using 2023 as a stand-in for "present" still requires updating, and implies an end, which isn't great. This suggests only including the start date and leaving the end unsaid, so I tried |date=from Dec 2020 and that threw an error too :/ Is there any way to just silence the error in the template? Eievie (talk) 01:58, 8 January 2023 (UTC)[reply]
    Don't use 2023, use the template indicated. Izno (talk) 02:07, 8 January 2023 (UTC)[reply]
    And no, you cannot silence the error. Anyway, MOS:DATETOPRES says to include the end date regardless, so in the context of a citation template I do not think it is too onerous to use something like {{year}} to indicate your intent. You can always choose not to use the template, but I think that work around is sufficient, perhaps with an in-wikitext comment. Izno (talk) 02:10, 8 January 2023 (UTC)[reply]

    Mark as accessible through Wikipedia Library

    I know not all users have access to Wikipedia Library, but especially with its recent expansion, many previously pay-for or institution-locked journals etc. are completely accessible for users meeting requirements. Would it be possible, then, to add a parameter (or an option for the url-access parameter) that says a source is free through Wikipedia Library? Kingsif (talk) 02:52, 9 January 2023 (UTC)[reply]

    |via=Wikipedia Library. 172.254.255.250 (talk) 12:58, 9 January 2023 (UTC)[reply]
    I'd say that would work, if the link in citation is specific to the Wikipedia Library, but most are not. For example, I have a Newspapers.com account through the Wikipedia Library, and if I cite a newspaper article from those archives, I'd be using |via= to indicate that website, not the library because the library didn't republish the article. Imzadi 1979 → 19:07, 9 January 2023 (UTC)[reply]
    At least from my past experience, a bunch of the URLs for Wikipedia library sources are either rejected by the insert citation tool in the source editor, or are soon "anonymized" by a bot, so I'm not sure that basing something off of the link itself will be of great use, unless something has changed recently. Hog Farm Talk 19:10, 9 January 2023 (UTC)[reply]
    What TWL has access to at any given point varies. I would not support an actual parameter on the point.
    Here is a 2018 RFC which permits its use in |via=, which is certainly sufficient to me. There's other discussion in the archives about the utility in general of using |via= to indicate libraries (short answer is don't, which I think is also either directly in WP:Citing sources or similarly discussed on its talk page) as well as a few other discussions directly pertinent mostly under "TWL" but all older than that RFC. Izno (talk) 19:22, 9 January 2023 (UTC)[reply]
    Perhaps hastily, mine was the initial reply. Thinking it through, it seems the TWL is not an alternate provider or a content aggregator, but a facility/conduit to the former.
    So now I agree with replies that suggested that |via= may not be proper (even though allowable), and the citation should be silent on the matter. I also agree with Izno that a specific parameter adds nothing to the citation's purpose. With well-established rationale, citations don't credit other physical or virtual libraries; I don't see why TWL should be an exception. 65.88.88.70 (talk) 20:46, 9 January 2023 (UTC)[reply]
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1&oldid=1132638034"