Jump to content

Help talk:Citation Style 1

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

    {Cite journal} pages styling

    [edit]

    There is no 'p.', 'pg.', 'p ' or something of the sort indicating the numbers supplied in the page= or pages= parameters are pages for {cite journal}. Please change the displayed text from '<supplied-numbers>' to 'p. <supplied numbers>'.

    Observe the example below, where I have only included page=400-500. It only displays '400-500', but it should display 'p. 400-500'

    : 400-500. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help)

    (Perhaps I am wrong about this, and there is a special academic standard for citing journal page numbers I am unaware of?) Tule-hog (talk) 19:56, 4 August 2024 (UTC)[reply]

    It seems fine to me as it is. What apart from a page span could be meant by an ndash-separated pair of increasing numbers following a colon following the volume and issue? Why not use {{cite periodical}} if you're unhappy with the display formatting of {{cite journal}}? Folly Mox (talk) 20:23, 4 August 2024 (UTC)[reply]
    Firstly, note this also applies to page= which does not provide an n-dash. I thought the following was a little confusing along side a year:
    . 2000: 1900. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help)
    I thought it was incorrect, not bad. If others disagree, then let it stay! Tule-hog (talk) 20:49, 4 August 2024 (UTC)[reply]
    Since we purport to be a publication for a generalist audience, I would think that we should format our citations for a generalist audience as well. Yes, that formatting is used in specialist publications, but we are not a specialist publication. For that reason, I continue to advocate that we should drop the overly truncated formatting for the volume/issue/page triplet on journals in favor of adding "vol.", "no." and "p." or "pp.". In short, it should be the way {{cite magazine}} does it without separating the vol./no. from the p. or pp. Imzadi 1979  20:57, 4 August 2024 (UTC)[reply]
    I feel like the "vol." and "no." add undesirable cruft that is more difficult to identify on vgrep than the bolded volume number of {{cite journal}}. Just because we're not a specialist publication doesn't mean we shouldn't support multiple citation formats. Also, I like that the formatting between {{cite journal}} and {{cite magazine}} differs, which lets me see at a glance how reputable and peer-reviewed a source is / purports to be.
    If there are confusion points in our citations to expunge for immediate understanding by any reader, I'd start with the lowest hanging fruit of Bibcodes and s2cids, which seldom if ever add any useful information even on clickthrough, and are entirely unfamiliar to almost every reader. Folly Mox (talk) 16:17, 5 August 2024 (UTC)[reply]
    People get used to this formatting after seeing it a few times, and the concision is helpful. Making it more explicit helps someone the first time, but only at the expense of significantly reducing information density of reference sections, which isn't worth it IMO. –jacobolus (t) 02:36, 9 August 2024 (UTC)[reply]
     Not done for now: please establish a consensus for this alteration before using the {{Edit semi-protected}} template. – Jonesey95 (talk) 20:41, 4 August 2024 (UTC)[reply]
    Is there a template to indicate the intent to use the {edit semi-protected} in future (i.e. 'request proposal', 'needs consensus', or something)? Tule-hog (talk) 20:52, 4 August 2024 (UTC)[reply]
    No. You just discuss until there is consensus, and then you can remove |answered=yes from the template in this section to reactivate the request. – Jonesey95 (talk) 13:22, 5 August 2024 (UTC)[reply]

    module suite update 17–18 August 2024

    [edit]

    I propose to update cs1|2 module suite over the weekend 17–18 August 2024. Here are the changes:

    Module:Citation/CS1:

    Module:Citation/CS1/Configuration:

    • fix 'email' generic name pattern; discussion
    • fix undeclared variable 'uncategorized_namespaces_t'; no discussion; this edit
    • add free DOI registrants: 4230 (LIPIcs) and 12942 (Living Reviews)
    • maintenance category when value assigned to |year= is more precise than a year;
    • support free-to-read DOI on certain 10.registrant/incipit...; initial support for MNRAS, MNRAS Letters, Geophysical Journal International, RAS Techniques and Instruments; discussion
    • test for 'bureau', 'company', 'correspondent', 'desk', 'group', 'limited', 'newsroom' generic names; discussion
    • update WorldCat URL prefixes; discussion

    Module:Citation/CS1/Whitelist

    Module:Citation/CS1/Date validation

    • maintenance category when value assigned to |year= is more precise than a year;

    Module:Citation/CS1/Identifiers

    • support free-to-read DOI on certain 10.registrant/incipit...; initial support for MNRAS, MNRAS Letters, Geophysical Journal International, RAS Techniques and Instruments;

    Trappist the monk (talk) 22:48, 9 August 2024 (UTC)[reply]

    Also:

    • support free-to-read DOI on certain 10.registrant/incipit...; additional support for Access Microbiology, Microbiology, Journal of General Microbiology, Microbial Genomics [1]
    • support free-to-read DOI on certain 10.registrant/incipit...; additional support for Heliyon [2]
    • support free-to-read DOI on certain 10.registrant/incipit...; additional support for Journal of the Endocrine Society, JCEM Case Reports [3]

    Headbomb {t · c · p · b} 17:33, 13 August 2024 (UTC)[reply]

    Bug

    [edit]

    doi:10.1093/notesj/gji104 is found as a match for doi:10.1093/jgi... Headbomb {t · c · p · b} 14:45, 19 August 2024 (UTC)[reply]

    Fixed in the sandbox I think:
    {{cite book/new |title=Title |doi=10.1093/notesj/gji104}}Title. doi:10.1093/notesj/gji104.
    {{cite book/new |title=Title |doi=10.1093/gji104}}Title. doi:10.1093/gji104.{{cite book}}: CS1 maint: unflagged free DOI (link)
    Trappist the monk (talk) 17:45, 19 August 2024 (UTC)[reply]

    If an italicized title ends in a question mark, shouldn't the following punctuation be suppressed?

    [edit]

    For example:

    Or likewise with an exclamation mark:

    It seems like the output should not put a period or comma immediately after another punctuation symbol.

    Edit: the relevant manual of style section is MOS:CONSECUTIVE. –jacobolus (t) 06:37, 13 August 2024 (UTC)[reply]

    Fully-protected edit request, August 17, 2024

    [edit]

    You can see in the screenshots above that some characters (in this case, a lowercase I), when italicized, collide with the closing square brackets when using the |trans-title= parameter. This occurs on all skins. In this case I was using {{cite book}}, which italicizes the translated titles automatically, but this will also occur with other citation templates if the final character happens to be italicized. I have no idea where exactly this change needs to be made, but hopefully someone more well-versed in these modules will know better than me about that. Let me know if you have any questions! TechnoSquirrel69 (sigh) 04:25, 17 August 2024 (UTC)[reply]

     Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. You didn't link to a page where this is happening, so I made my own. I get a slight white separation between the "i" and the right bracket. My default font is Lucida Grande, on Mac OS on a 2024-vintage laptop. I expect that everyone's formatting mileage will vary with font choices, screen resolution, and other computer-specific settings. Also, FWIW, your screen shots don't really show a connection or a gap, because of the blue highlighting. – Jonesey95 (talk) 05:12, 17 August 2024 (UTC)[reply]
    @Jonesey95: Thanks, I'm still learning exactly what information is helpful in bug reports like this. I took those screenshots in Firefox on Vector 2022 while logged out, so all the formatting should be what the majority of readers will be seeing. I highlighted the I because it looked like the white dot clipping the top of the bracket more clearly illustrated the issue, but oh well. I'm seeing the same kerning issue in your sandbox, obviously, so perhaps we could do with a third opinion on whether this is worth addressing — I remember working with Trappist the monk on a similar issue a few months ago. I'm setting the request to open again. TechnoSquirrel69 (sigh) 05:24, 17 August 2024 (UTC)[reply]
    I won't edit war with you over the edit request template, but please read its instructions. There is no "complete and specific description of the request, so that an editor unfamiliar with the subject matter could complete the requested edit immediately" here. This is simply a discussion.
    I am also using Firefox with the Vector 2022 skin. I don't think the problem here is with this particular template, or even with Wikipedia; it is with the way that an italic "i" is rendered when it is followed by a square bracket. On your computer, if you go to a text editor or other program where you can type, and set the font and font size to the same settings as Firefox, do you see the same problem? – Jonesey95 (talk) 13:26, 17 August 2024 (UTC)[reply]
    This is fully dependent on client configuration (specifically, the kerning pairs in the chosen display typeface). A hair space output when transitioning from oblique text to upright closing bracket could accommodate problem typefaces, but might make display wonkier for typefaces where the interaction is already accounted for. Folly Mox (talk) 17:18, 17 August 2024 (UTC)[reply]

    Not done, please made you request in a way that's actionable, e.g. "Change [this] to [that]". Until an exact change is requested, the edit request is premature. Headbomb {t · c · p · b} 13:50, 17 August 2024 (UTC)[reply]

    Docket Number Definition

    [edit]

    Could someone add a better definition for docket to Template:Cite report? At the moment it simply reads "docket number", but nowhere in the template documentation does it explain what a "docket" is – which is not particularly helpful for those unfamiliar with the word. –Noha307 (talk) 03:48, 19 August 2024 (UTC)[reply]

    wikt:docket Probably the 4th definition. Izno (talk) 16:21, 20 August 2024 (UTC)[reply]

    Coming soon: a completely new way to make citations

    [edit]

    Wikipedia:Village_pump_(technical)#Coming_soon:_A_new_sub-referencing_feature_–_try_it!.

    It will involving breaking CS1|2 citations apart, and spreading those pieces around into different parts of the article, as free-form untemplated text. It's integral to MediaWiki. There are no guidelines for usage, anything goes. -- GreenC 17:08, 19 August 2024 (UTC)[reply]

    Are there any plans yet to build a {{subref}} (or whatever name) template that can accept the arguments that Module:Citation/CS1 and Module:Footnotes accept? Rjjiii (talk) 02:31, 20 August 2024 (UTC)[reply]
    Should be. I got kick back, saying editors should have the "luxury" to do whatever they want, without constraint. That doesn't mean we can't make templates, but that also suggests there will be a small but vocal faction that will want complete personal freedom to add whatever thing they want in a sub-ref. I couldn't even get agreement we might need some sort of guideline on how to use sub refs. So, be prepared for this to become a massive headache. There's really nothing stopping anyone from creating sub refs for multiple authors, pages, quotes, URLs, archive URLs, DOIs and other identifiers, dates, ISBNs, works, in-source locations, access-date, and much more. Essentially, everything in a citation can be removed and replaced with a sub-ref. This will create red errors in citations, make parsing citations nearly impossible, fixing citations incredibly hard, link rot will go undetected and unfixed, none of the bots will work like Citation bot and Refill that so many depend on. The libraries like PyWikiBot won't work without a massive overhaul of core components and creation of new features and functions. -- GreenC 03:42, 20 August 2024 (UTC)[reply]
    If you want to create guidelines and gain consensus for them, then start at WP:VPPOL, not here which is a less-watched, more technical page. I'm not unsympathetic to your view (I don't like LDR style referencing - implied in this development as the way to go, but perversely I do like {{sfn}}) but the discussion needs to go wider than the technical pages and technical-minded editors who haunt them.
    It's an eternal problem with Wikipedia that technical changes happen in a vacuum and not in conjunction with changes with business practices. It's understandable when you consider that the way de-wp probably want to use a feature will be a different way to how the same feature will be used on en-wp, so I don't blame WMF for having a bit of a dump and run approach. We know the technical change is going to happen so let's have the associated en-wp business change discussion upfront but in the right place, which isn't here.
    Like any change, there are always fears about what will ensue. All the things you list may happen but less Chicken Little and more "approach X is to be recommended because it prevents/reduces ABC happening" is, imo, a better starting place for discussion. The use of ibid has been discouraged for years but it still gets used, to no great detriment overall. We even have WP:CITEVAR as policy accepting variances in referencing styles, so yes there are almost inevitably going to be edits using sub-refs in ways that you and I will not like for one reason or another. They're not going to eliminated but get the MOS/policy position established which reduces the likelihood of them happening in the first place. Nthep (talk) 07:42, 20 August 2024 (UTC)[reply]
    Very well said. There will likely be consensus for this feature generally, but if there is a guideline and what that guideline says, should be decided by the community. The community needs to understand the consequences of citations that are no longer supported by tools. It will become painfully apparent with time, but the sooner this is resolved the better. -- GreenC 17:06, 20 August 2024 (UTC)[reply]
    If a wiki page cites, e.g., multiple stories in an anthology, multiple articles in an issue, multiple papers at a conference, then it would be normal for different subreferences to have different |auther= parameters. OTOH, I see no reason to not exclude, e.g., |isbn=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:52, 20 August 2024 (UTC)[reply]
    Editors will be creative how they slice and dice citations. There will be a variety in one article, that exists nowhere else, or only a few articles. Many rare birds. Thus, automated tools loose the benefit of CS1|2, which is standardization. Our tools will simply cease to function (for those citations). So we gain things, and loose things. If folks are OK with the loss of Refill, Citation bot, InternetArchiveBot, GreenCbot, AWB, PyWikiBot, etc.. then they are also OK with link rot, usurped URLs, general maintenance of metadata, clearing tracking category errors, etc.. The expectation that tools will be able to adapt should not be assumed. Many rare birds, at high risk of extinction, another way of saying non-robust, error prone, weak ie. bad design. Wikipedia has a lot of bad design but this one of predictable and preventable, with the right guardrails. -- GreenC 16:32, 20 August 2024 (UTC)[reply]
    There should be no issue with the main reference. I also don't see an issue with sub-references that use CS1 or CS2 template with |title=op cit. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:07, 20 August 2024 (UTC)[reply]
    Specifying |title=op cit in a cs1|2 template inside of a <ref extends="...">{{cite whatever |title=op cit |...}}</ref> will cause the cs1|2 template to emit bogus title metadata: &rft.btitle=op+cit so anyone consuming article citations via reference management software won't be given the source's actual title in the scraped citation. Fortunately there are few cs1|2 templates that use |title=Op. cit.; see this search. Similarly, for |title=Ibid; this search.
    Yeah, we could add a mechanism (parameter) that would tell a cs1|2 template to mute its metadata output, but that would needs be a manual operation because the cs1|2 template cannot know which <ref extends="...">...</ref> tags wrap it.
    Trappist the monk (talk) 17:48, 20 August 2024 (UTC)[reply]
    I'm assuming that whoever uses <ref extends=main-reference>citation-template</ref> will use the proper parameters for the wrapped sub-reference, provide that template supports an appropriate parameter. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:23, 20 August 2024 (UTC)[reply]
    @GreenC, make sure you don't WP:CANVASS when you decide not to invoke the names of your would-be opposition. You got kickback for good reason. Izno (talk) 16:22, 20 August 2024 (UTC)[reply]
    This could be done by creating a variant of the citation templates that wrapped the citation in <ref name="CITEREFSmith2000">...</ref> instead of putting the ref in the <cite> tag. Then {{subref}} could be written to use that ref in a similar way to {{sfn}}. None of this seems to require anything more from the MediaWiki implementation. Kanguole 10:03, 20 August 2024 (UTC)[reply]
    That is
    {{ref cite book |first=E. |last=Miller |title=The Sun |location=New York |publisher=Academic Press |year=2005}}
    
    (arbitrary template name) would expand as
    <ref name="Miller2005">Miller, E. ''The Sun''. New York: Academic Press, 2005.</ref>
    
    and {{subref|Miller|2005|p=23}} would expand as
    <ref extends="Miller2005">Page 23.</ref>
    
    and the existing sub-referencing implementation would do the rest. The only thing missing would be merging of duplicate pages, but there are hooks to enable that too. Kanguole 10:24, 20 August 2024 (UTC)[reply]
    That is an interesting idea. It does lock this method further into source code editing. At the moment, the list-defined references (LDR) that this method relies on aren't fully implemented in the Visual Editor. The VE can't add, remove, or replace a list-defined reference. Hypothetically though, if the WMF can get LDR working in VE, then this could be much friendlier to new users than {{sfn}}. The template could be designed to plug into the sub-references like:
    <ref extends="Miller2005">{{subref|p=23}}</ref>
    
    Rjjiii (talk) 15:50, 20 August 2024 (UTC)[reply]

    cite conference and conference-url

    [edit]

    From Holographic algorithm:

    [1]

    References

    1. ^ Valiant, Leslie (17–19 October 2004). Holographic Algorithms (Extended Abstract). FOCS 2004. Rome, Italy: IEEE Computer Society. pp. 306–315. doi:10.1109/FOCS.2004.34. ISBN 0-7695-2228-9. {{cite conference}}: |access-date= requires |url= (help); |archive-url= requires |url= (help)

    Same problem with {{cite conference}} in Tervamäki ATE-3 and Tervamäki JT-5. Changing |conference-url= to |url= solved the problem eg. Special:Diff/1241238099/1241238294. This could be a new problem, I've never seen it before, three articles showed up in Category:CS1 errors: archive-url. -- GreenC 03:27, 20 August 2024 (UTC)[reply]

    The values assigned to |conference-url= and to |archive-url= are not links to the paper named in |title= and do not match the source linked by |doi=. |archive-url= and |access-date= do not apply to |conference-url= hence the error messages: |archive-url= requires |url= and |access-date= requires |url=. Both apply to |url= or in its absence to |chapter-url= (and aliases).
    Were it me, I would rewrite:
    {{cite conference |title=Holographic Algorithms |book-title=FOCS 2004: 45th Annual IEEE Symposium on Foundations of Computer Science |first=Leslie |last=Valiant |author-link=Leslie Valiant |date=17–19 October 2004 |conference=FOCS 2004 |publisher=IEEE Computer Society |pages=306–315 |isbn=0-7695-2228-9 |doi=10.1109/FOCS.2004.34 |conference-url=https://web.archive.org/web/20120313170241/http://www.cs.brown.edu/~aris/focs04/}}
    Valiant, Leslie (17–19 October 2004). "Holographic Algorithms". FOCS 2004: 45th Annual IEEE Symposium on Foundations of Computer Science. FOCS 2004. IEEE Computer Society. pp. 306–315. doi:10.1109/FOCS.2004.34. ISBN 0-7695-2228-9.
    This is not anything new. {{cite conference}} needs to be rewritten because editors routinely write poor proceedings citations (we are citing the proceedings, not the conference – if you want to cite the conference website, use {{cite web}}).
    Trappist the monk (talk) 14:37, 20 August 2024 (UTC)[reply]
    OK. Thanks for your time explaining. I'll keep this in mind next time I clear the category, about 80% by bot the remaining 20% manually have unusual cases like this. -- GreenC 15:51, 20 August 2024 (UTC)[reply]

    Are Zotero Wikipedia Templates useable?

    [edit]

    I just installed the "Wikipedia Templates" (version from 2021) from within Zotero, which are the only Wikipedia citation style that Zotero seems to have on offer. However, this always gives me a syntax that uses the "vauthors" parameter and always puts author names in double parentheses, e.g., vauthors=((Ellenberger, P.)). Is this correct? Am I doing something wrong, or is there an alternative Zotero citation style available somewhere that uses the standard last= and first= parameters instead? Thanks. Jens Lallensack (talk) 14:27, 23 August 2024 (UTC)[reply]

    Abusing the accept-as-written markup is wrong. I seem to recall a conversation some place where the participants were trying to find a way to avoid multiple author names in |author= (or something like that). Instead of working out a proper solution (enumerated author-name parameters), they chose to abuse the accept-as-written markup as their solution.
    If we are to believe this search, there are 500ish articles that have |vauthors= with multiple accept-as-written marked-up names. No doubt, there is a proportion of those articles that legitimately use the markup. Those that are not should be repaired.
    I know nothing about Zotero or whatever it is that you installed. But, given that the Zotero thingy does not produce proper output, were I you, I would uninstall and complain to Zotero about the poor quality of their thingy. I would also not hold my breath waiting for a positive (any?) response.
    Trappist the monk (talk) 15:02, 23 August 2024 (UTC)[reply]
    Thanks, that confirms my hunch that the Zotero templates are currently broken. I will try to fix it myself. Jens Lallensack (talk) 15:13, 23 August 2024 (UTC)[reply]
    Template:Cite journal documentation states that (( )) should only be used for institutional authors. This may be a fine distinction Zotero is having trouble picking up. CMD (talk) 15:22, 23 August 2024 (UTC)[reply]
    I just updated to the latest version, prompted by Jens Lallensack's post. I find the structure strange, even though I've been using it occasionally for years. In Edit->Settings, there is a Cite panel, which (by default) doesn't mention Wikipedia. But in the Edit->Settings->Export panel there is a Quick Copy feature, and you can select the format for items that are quick copied. One of the choices is Wikipedia Citation Templates. I've found this method to be reasonable, although some touch-ups are usually needed after I copy. Clarification: I did not take any steps to install any additional Wikipedia format. Jc3s5h (talk) 15:47, 23 August 2024 (UTC)[reply]
    @Jc3s5h: I thought that Zotero does not ship any Wikipedia template by default? Are you sure that it's not the old Wikipedia template you installed years ago (which works fine, as I remember)? If you go "Edit" -> "Settings" -> "Cite", what does the "Updated" field say for your Wikipedia template? If it is the older version that does not use vauthors, could you maybe send it to me? (Just go "Settings" -> "Cite" -> Select "Wikipedia Templates" -> click on "Style editor", and copy the xml code). That would be much appreciated, thank you. Jens Lallensack (talk) 16:04, 23 August 2024 (UTC)[reply]
    Never mind, I found it (as you wrote, the "Wikipedia Citation Templates", not the "Wikipedia Templates" from the style repository). Great, that works for me now. Thanks. --Jens Lallensack (talk) 16:12, 23 August 2024 (UTC)[reply]

    Limit for s2cid needs increasing

    [edit]

    Note that the value 270801523 is correct for s2cid and is larger than the currently configured limit of 270000000. —Jonathan Bowen (talk) 15:07, 23 August 2024 (UTC)[reply]

    Notice: discussions on WMDE sub-reference project in progress at Meta

    [edit]

    The WikiMedia sub-referencing project (parent project: Reusing references) is having multiple discussions about the development of a sub-referencing feature by WikiMedia Deutschland Engineering. Your feedback would be welcome at any of the discussons at m:Talk:WMDE Technical Wishes/Sub-referencing. Mathglot (talk) 21:00, 23 August 2024 (UTC)[reply]

    Citoid adds PMC prefix

    [edit]

    I sometimes make citations with "pmc" in the |pmc= parameter.[4] This is always the result of using Source Editor > Ref Toolbar > Cite > Templates > Cite journal > Autofill (Magnifying glass button). I believe the autofill is done by Citoid. Is it an error to include "pmc"? If so, how do we let the appropriate folks know? Rjjiii (talk) 20:47, 24 August 2024 (UTC)[reply]

    I don't use ve so can't speak to users who do. When I look at the RefToolbar form for {{cite journal}}, PMC is hidden behind the Show/Hide extra fields button and does not have autofill (no quizzing glass). Filling with PMID (PMID 33061789 in this case) which does have a quizzing glass and which would be most likely autofillable identifier to add PMC, does not fill the PMC parameter. Filling from URL and DOI likewise do not fill PMC.
    Are you sure that RefToolbar is how you created that {{cite journal}} template?
    It is not an error to include the PMC prefix when filling |pmc= but that does cause cs1|2 to add the article to Category:CS1 maint: PMC format.
    Trappist the monk (talk) 21:42, 24 August 2024 (UTC)[reply]
    Oh, dang, you're right, I must have done ProveIt on that one.
    This doi "10.1098/rspa.2020.0148" in either the Visual Editor's automatic citation or ProveIt's automatic {{cite journal}} will add the prefix. Rjjiii (talk) 21:58, 24 August 2024 (UTC)[reply]

    How do you use the autogenerated anchor, eg CITEREFBaldwinMarshall1999

    [edit]

    In Toxic heavy metal the is an anchor CITEREFBaldwinMarshall1999, but I can't figure out how to use it in a ref tag. Johnjbarton (talk) 18:59, 25 August 2024 (UTC)[reply]

    You can reference it with the {{sfn}} or {{harv}} families of templates. Kanguole 19:14, 25 August 2024 (UTC)[reply]
    @Kanguole Thanks! But.. I'm still stuck. The sfn template needs names and dates. Where do I put "CITEREFBaldwinMarshall1999"? Thanks! Johnjbarton (talk) 19:22, 25 August 2024 (UTC)[reply]
    The basic format for {{sfn}} templates for that would be {{sfn|Baldwin|Marshall|1999}}. -- LCU ActivelyDisinterested «@» °∆t° 19:31, 25 August 2024 (UTC)[reply]
    The template automatically links to that format to CITEREFBaldwinMarshall1999. -- LCU ActivelyDisinterested «@» °∆t° 19:33, 25 August 2024 (UTC)[reply]
    There are no {{sfn}} or {{harv}} templates in that article. Remember that WP:CITEVAR applies.
    Trappist the monk (talk) 19:37, 25 August 2024 (UTC)[reply]
    That article is a mess. Keeping WP:CITEVAR in mind, to make a Baldwin Marshall 1999 short form reference, here are some options:
    [[#CITEREFBaldwinMarshall1999|Baldwin Marshall 1999]]
    [[#{{sfnref|Baldwin|Marshall|1999}}|Baldwin Marshall 1999]]
    Both of these, to my mind, make life more difficult than it needs be. But, they work well with the cs1|2 templates. Alas, the article uses hand crafted fragment links so for strict compliance with WP:CITEVAR, this:
    [[#Baldwin|Baldwin Marshall 1999]]
    And you will get yet another short-form reference that does not link to its long-form companion – some do, but the majority do not so what is the purpose of all that fragment wikilinking?
    Were I the chief, I would replace all of those fragment wikilinks with proper {{sfn}} templates. Alas, I'm not. To accomplish that you will need to achieve consensus at the article talk page
    You are aware that there are two instances of Baldwin Marshall 1999 which appear to be the same source?
    Trappist the monk (talk) 19:37, 25 August 2024 (UTC)[reply]
    Thanks, but to be honest I don't understand all these options and half of the words. Anyway someone else already changed over to sfn ;-) Johnjbarton (talk) 19:45, 25 August 2024 (UTC)[reply]

    Feature request: enable manual title-linking of open access stable identifiers in Cite book

    [edit]

    {{Cite journal}} automatically links the title to a freely available external resource when it is marked with |ident-access=free; {{Cite book}} not only doesn't do this, but doesn't support manual title-linking to open access resources. There are plenty of open access books these days, and plenty of books with DOIs, free and subscription both. Can this functionality be enabled for this template? Could cut down on unnecessary URLs and their attendant archival and rotting. Folly Mox (talk) 14:24, 31 August 2024 (UTC)[reply]

    chapter-archive-url

    [edit]

    Should there be a chapter-archive-url parameter for dead chapter-url? Tule-hog (talk) 21:33, 2 September 2024 (UTC)[reply]

    Show a real-life example of where such a parameter is required. Note that when |archive-url= is provided in the presence of |chapter-url= with or without |url=, the module uses |archive-url= to link |chapter=:
    {{cite book |chapter=Chapter |chapter-url=//example.com/chapter |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2024-09-02}}
    "Chapter". Title. Archived from the original on 2024-09-02.
    If we are to support |chapter-archive-url= we must also support |chapter-archive-date=, and |chapter-url-status=.
    Give an example to show how a template would render with |archive-url=, |archive-date=, |chapter-archive-url= and |chapter-archive-date=.
    Trappist the monk (talk) 21:57, 2 September 2024 (UTC)[reply]
    Plus all the other *-url parameters. It's complex and messy. For those rare instances of ambiguity about which URL the archive-url is attached to, use {{webarchive}} with |format=addlarchive. -- GreenC 22:30, 2 September 2024 (UTC)[reply]
    I'll use archive.org-esque convention of archive.org/<url> for clarity, omitting the date component. I'll keep close to your example.

    {{cite book |chapter=Chapter |chapter-url=//example.com/chapter |chapter-archive-url=//archive.org/example.com/chapter |title=Title |url=//example.com |archive-url=//archive.org/example.com |archive-date=2024-09-02 |chapter-archive-date=2024-09-03 |chapter-url-status=dead}}
    "Chapter". Title. Archived from the original on 2024-09-02, the section on 2024-09-03.
    Example display is just a mockup, I'm not passionate about any particular method. Presumably chapter-url-status omitted by default would use chapter-archive-url, similar to url-status and archive-url. Tule-hog (talk) 22:32, 2 September 2024 (UTC)[reply]

    CS1 translator feature request: addition of empty trans-title param

    [edit]

    Can we add an empty trans-title param to the output of Module:CS1 translator, either always, or under control of a new, optional param?

    I invariably try to follow up the module action by adding |trans-title=. Having that empty param added by the Module would simultaneously be a time-saver, as well as provide a quick check (via search-on-page + highlight) of how much work I still have left to do translating titles, and where they are located on the page. If this is accepted and implemented under parameteric control, please don't call the param 'trans', out of possible confusion with the whole purpose of the module; maybe something as simple as |_extra=y or |_expand=y or something.

    The field even has utility empty: if I forget to come back and fill them in, some editor may come along and do it if they see the empty params, but may not look for the param in the doc if they don't know it exists.

    Optionally, if additional languages such as Russian or Arabic or other non-Latin scripts are supported in the future, that same function or param could output the original title as |script-title= and add empty params |title= and |trans-title= ready for supplying romanization and translation. Mathglot (talk) 23:54, 4 September 2024 (UTC)[reply]

    Just realized we have {{Cite journal/Arabic}}; does it do that? Mathglot (talk) 23:57, 4 September 2024 (UTC)[reply]
    It does not.
    Trappist the monk (talk) 00:57, 5 September 2024 (UTC)[reply]
    I'm not inclined to make this change primarily because some editor may come along and do it if they see the empty params whereupon, they grab the title from |title= and slap it into google translate, paste the translation into |trans-title= and claim: success! atta boy! job well done! Likely though, nothing will happen and the empty |trans-title= will remain empty; such is my experience.
    If you want to find templates that Module:CS1 translator has translated, you can do an insource search for this:
    <!-- auto-translated from <whatever language> by Module:CS1 translator -->
    For example, this search for Arabic translations. Once you have visited a translated template and added/fixed as appropriate, delete the comment.
    The purpose of the module is to (more-or-less accurately) do the grunt work of translating non-English template and parameter names to their English equivalents. Except for simple, mostly robust, month-name translations, that is all that the module does or should do.
    Trappist the monk (talk) 00:57, 5 September 2024 (UTC)[reply]

    Another Generic Title

    [edit]

    Hello, another Generic Title to be considered is "Unknown" or "unknown". Keith D (talk) 11:48, 5 September 2024 (UTC)[reply]