Help talk:Citation Style 1/Archive 87

Archive 80

←

Archive 85

Archive 86

Archive 87

Archive 88

Archive 89

Archive 90

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

My issue was the opposite; there was an inline translation that I considered problematical, and I added English 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)

Notes

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)

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)

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)

Thank you both for your suggestions.--Obi2canibe (talk) 19:48, 22 December 2022 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

A specification related to references was unilaterally removed a couple of months ago. Nikkimaria (talk) 01:51, 21 December 2022 (UTC)

@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)

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)

Cambridge MA - is it a degree or a place? DuncanHill (talk) 23:09, 21 December 2022 (UTC)

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)

The reader of a thesis citation doesn't see to which parameter "Cambridge MA" applies. -- Michael Bednarek (talk) 02:59, 22 December 2022 (UTC)

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)

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)

|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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

But limited to a specific geographical area, vs something like "UK" which is international. Nikkimaria (talk) 01:51, 21 December 2022 (UTC)

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)

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)

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)

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)

See ISBN documentation.

—Trappist the monk (talk) 16:53, 8 December 2022 (UTC)

When the 13 digit one is actually printed, use it over the 10 please. — xaosflux ^Talk 17:27, 8 December 2022 (UTC)

Yes!  Done Sadhuguru (talk) 13:01, 24 December 2022 (UTC)

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)

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)

...which was broken by [1] DMacks (talk) 04:09, 26 December 2022 (UTC)

Oh. I see. Thanks for that. Hawkeye7 (discuss) 04:51, 26 December 2022 (UTC)