Jump to content

Help talk:Citation Style 1: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
ClueBot III (talk | contribs)
m Archiving 3 discussions to Help talk:Citation Style 1/Archive 90. (BOT)
Line 481: Line 481:
:::{{cite web/new |title=W.Media| url=https://w.media}}
:::{{cite web/new |title=W.Media| url=https://w.media}}
:—[[User:Trappist the monk|Trappist the monk]] ([[User talk:Trappist the monk|talk]]) 21:42, 29 September 2023 (UTC)
:—[[User:Trappist the monk|Trappist the monk]] ([[User talk:Trappist the monk|talk]]) 21:42, 29 September 2023 (UTC)

== Protected edit request on 3 October 2023 Suggestion: Suggestion add template data ==

{{edit fully-protected|Template:Cite map|answered=no}}
Want to add TemplateData for Cite map so that it can work with ProveIt, using Cite book page as an example

Change from:
<nowiki><includeonly>{{#invoke:Citation/CS1 | citation
|CitationClass=map
}}</includeonly><noinclude>
{{documentation}}
</noinclude></nowiki>

to

<nowiki><includeonly>{{#invoke:Citation/CS1 | citation
|CitationClass=map
}}</includeonly><noinclude>
{{documentation}}
{{collapse top|TemplateData}}
{{Cite map/TemplateData}}
{{collapse bottom}}
</noinclude></nowiki> [[User:Furicorn|Furicorn]] ([[User talk:Furicorn|talk]]) 20:52, 3 October 2023 (UTC)

Revision as of 20:52, 3 October 2023

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

    Recognize free DOI prefixes

    Several DOIs can be known to be free from their DOI prefix. While we could autoflag them as free, a better practice, IMO, would be to have Category: CS1 maint: Unflagged free DOI (or similar), that would populate when we have a DOI prefix match, and when |doi-access=free is not set. This way we would have a category against which to run User:Citation bot (similar to Category:CS1 errors: DOI, or Category:CS1 maint: PMC format). Because right now, we need to collect all articles with DOI match (about 30,000 articles), but have no good way of excluding articles where their free DOIs have already been flagged, leading to a lot of wasted bot processing time.

    10\.(1100|1155|1186|1371|1629|1989|1999|2147|2196|3285|3389|3390|3410|3748|3814|3847|3897|4061|4089|4103|4172|4175|4236|4239|4240|4251|4252|4253|4254|4291|4292|4329|4330|4331|5194|5306|5312|5313|5314|5315|5316|5317|5318|5319|5320|5321|5334|5402|5409|5410|5411|5412|5492|5493|5494|5495|5496|5497|5498|5499|5500|5501|5527|5528|5662|6064|6219|7167|7217|7287|7482|7490|7554|7717|7766|11131|11569|11647|11648|12688|12703|12715|12998|13105|14293|14303|15215|15412|15560|16995|17645|19080|19173|20944|21037|21468|21767|22261|22459|24105|24196|24966|26775|30845|32545|35711|35712|35713|35995|36648|37126|37532|37871|47128|47622|47959|52437|52975|53288|54081|54947|55667|55914|57009|58647|59081)

    will match the currently known garanteed-to-be-free DOI prefixes. The list could be expanded as more are discovered (and likely externalized for ease of maintenance). Headbomb {t · c · p · b} 04:53, 18 August 2023 (UTC)[reply]

    This shouldn't be very hard to implement. Any news on this? Headbomb {t · c · p · b} 23:12, 1 September 2023 (UTC)[reply]
    {{cite book/new |title=Title |doi=10.1100/sommat}}
    Title. doi:10.1100/sommat.{{cite book}}: CS1 maint: unflagged free DOI (link)
    {{cite book/new |title=Title |doi=10.1100/sommat |doi-access=free}}
    Title. doi:10.1100/sommat.
    Trappist the monk (talk) 13:38, 2 September 2023 (UTC)[reply]
    Given the intent is to run a bot against this, can we adjust this to emit a properties category without message instead? Izno (talk) 17:58, 12 September 2023 (UTC)[reply]
    When it's not a high-priority fix/an actual error, that's what maintenance categories are for, basically. Citation bot already handles the vast majority of issues in
    We don't really need another type of category that's "maintenance, but not maintenance that needs to be displayed when I enable the maintenance messages". It'll have a few hundred/thousands pages in it at first, but one the initial run is done, remain below 10ish pages a day like the others. Headbomb {t · c · p · b} 21:56, 17 September 2023 (UTC)[reply]
    Category:CS1 properties does exist.
    I am entirely unconcerned about the count, the thought is that no human reader should want to maintain this category by hand, since it's fixable by bot (not all of the above are, despite Citation bot fixing them). So why emit a message to the user? (This is rhetorical, I don't really care enough on this point.)
    Separately, what happens when one of these publishers decides they're no longer going to publish content freely? Izno (talk) 16:52, 25 September 2023 (UTC)[reply]
    If a publisher stops being systematically free, we can remove them from the flag missing category and update bots accordingly (e.g. Citation bot stops flagging automatically, OABot keeps flagging on a case-by-case) basis. Headbomb {t · c · p · b} 21:51, 29 September 2023 (UTC)[reply]

    How to handle website unavailable in some countries?

    For a |url= where the website says thing like "this content is unavailable in your country", how should that be handled by our cite templates? None of the current combinations of |url-status= and |url-access= values seem to correctly work for this situation. My workaround is to mark the url as dead with a note. Perhaps a new value for |url-access= called "geographical" or something could be introduced. Or maybe I'm overlooking the solution. Suggestions? Jason Quinn (talk) 06:06, 3 September 2023 (UTC)[reply]

    If it's accessible to someone then it should not be marked dead. As I'm in the UK I often have US sites unavailable to me due to GDPR. If I really want to see it, I'll switch my VPN on and pretend I'm in the US.
    There are too many variables around the world for citations to catch every possibility, so we shouldn't worry about the geographical ones. Just the global ones e.g. pay walled sites that affect everyone. Nthep (talk) 09:19, 3 September 2023 (UTC)[reply]
    |url-access=limited seems to have pretty broad scope. Could that work for this situation? Agree that the link should not be marked as dead. Folly Mox (talk) 13:06, 3 September 2023 (UTC)[reply]
    It is not appropriate to mark these links as anything. (And this question really needs to be made clear in the documentation since we keep getting questions on it.) Izno (talk) 03:12, 4 September 2023 (UTC)[reply]

    Publications with multiple months as their dates

    Hello fellow Wikipedians - Can anyone comment on the proper way to cite publications that are dated as being two or more months? For instance, I would like to use the following as a citation:

    https://www.fedbar.org/wp-content/uploads/2013/01/bookrev-janfeb13-pdf-1.pdf

    which is from the January/February 2013 issue of a publication called The Federal Lawyer.

    However, I can't figure out how to do this without generating an error. Any insights from anyone?

    Thanks KConWiki (talk) 21:20, 4 September 2023 (UTC)[reply]

    Use the format indicated in MOS:NUM, which in your case would be January–February 2013. The character between the months is an n-dash. Don't use the html entity &ndash; because that won't work with the citation templates. Jc3s5h (talk) 21:33, 4 September 2023 (UTC)[reply]
    OK great, done - Thanks for your guidance on that. KConWiki (talk) 21:37, 4 September 2023 (UTC)[reply]

    Citing translations

    When citing a translation of a foreign work, should one supply |title=original and |trans-title=translation or only |title=translation? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:32, 6 September 2023 (UTC)[reply]

    WP:SAYWHEREYOUGOTIT if your referencing the translation use |title=translation -- LCU ActivelyDisinterested transmissions °co-ords° 20:42, 6 September 2023 (UTC)[reply]
    It seems to me both the title of the original and the title of the translation should be provided. This allows a reader to read the translation if the reader can find it. If not, the reader can, language skills permitting, read the original. Jc3s5h (talk) 20:46, 6 September 2023 (UTC)[reply]
    I only use |trans-title= if I'm referencing the foreign original and want to give the reader some indication of what the title means.
    I do like to provide the title of the original if I'm referencing a translated work, but I don't think any of the built in parameters is necessarily fit for this purpose. I've used |type= to hold this information in the past, but suspected it might be parameter misuse and started just adding "Translation of Non-English Title." after the closing curly brackets but before the closing ref tag. Folly Mox (talk) 21:08, 6 September 2023 (UTC)[reply]
    Yeah that's not what |type= is for, adding it after the cite is a better idea. -- LCU ActivelyDisinterested transmissions °co-ords° 21:11, 6 September 2023 (UTC)[reply]
    While we're on the subject, when a translation is an annotated, critical translation instead of just the regular type, is it better to credit the translator in the |editor= parameter? or leave them in |translator=? Folly Mox (talk) 21:30, 6 September 2023 (UTC)[reply]
    Just as one person can appear as both author and editor in a compilation that includes some chapters authored by the editor, this case seems analogous imho, as that individual is both translator, and editor.
    As far as Chatul's original question, the answer depends on whether you consulted the original foreign language version, or the English translation. As ActivelyDisinterested mentioned, you always say where you found it, and if that source is not in English, it's helpful to readers to add the |trans-title= parameter to give them the English version of the title. However, if you read a book in English translation, such as Beauvoir's The Second Sex, then there's no need to provide the original French title, mostly because it does not help WP:Verifiability, which is the whole reason we write citations in the first place, and it doesn't help English-speaking readers of Wikipedia, either. If you do wish to provide the original title, note that it won't fit either in parameter |title= (because param |title= is already taken by "The Second Sex") nor does it fit in |trans-title=, because that's *exclusively* for English titles of foreign works. So, where can you put it? The citation templates do not have a dedicated location for the original title of a work in a foreign language that you consulted in English translation, however, you could include it in |orig-date=, which is conceived to contain other information about an edition you did not consult. So, following the Beauvoir example, you could add: |orig-date=1st pub. [[Gallimard]]:1949 ''Le deuxième sexe''. Hope this helps, Mathglot (talk) 06:25, 7 September 2023 (UTC)[reply]
    I follow the metadata the work provides. If all it says is "translator", into |others= it goes. If all it says is "editor", into |editor= it goes. In the case where the work lists them as both, I tend toward either placing it in both, or if I'm feeling lazy, solely in |editor=. Izno (talk) 20:58, 8 September 2023 (UTC)[reply]

    East Asian name order

    Most of my content work is in Chinese history, so I'm frequently citing works by Chinese authors. As is well known, in China the family name precedes the personal name, like Qiu Xigui.

    When using the |last= and |first= parameters as usual, this causes names in citations to display like "Qiu, Xigui". While this isn't exactly wrong, it does look wrong, at least to me and many other people familiar with East Asian name order. Some English language scholars – even in the topic area – do format their bibliographical entries like this, but not as many as those who format names without the extraneous comma; some publications will ALLCAPS the family name for clarity, but I think this is recommended against here.

    My usual solution to this is to put the full author name in the |author= parameter, but then I have to do extra work to get shortened footnotes to work, like |ref={{sfnref|Qiu|1999}}. Also I suspect this is suboptimal for COinS metadata.

    I was thinking a new parameter like |name-separator=none could be a better solution, but I'm not sure how much work it would take to get it to apply dynamically to whichever contributor field it is supposed to. It would certainly be easy to add to existing citations without fiddling with |ref= and might benefit data reusers.

    I was also wondering if this could be handled with |author1-mask=, and what the syntax for that would look like. Just the full author name?

    What's the recommended practice for this, apart from "don't let it bother you"? Folly Mox (talk) 20:59, 6 September 2023 (UTC)[reply]

    Publications specializing in Asian topics will typically use Qiu Xigui, etc in their bibliographies, but publications for a general audience often use a consistent marking of surnames and given names: "Qiu, Xigui" and "Smith, John". It could be argued that Wikipedia should be more like the latter category. Note also that bibliographies are already unusual: "Smith, John" isn't what you'd write in a sentence either.
    However, I do find the parameter names |last= and |first= confusing, especially when working with a mix of Asian and Western author names. I find it less confusing to use the aliases |surname= and |given=. No change in the formatting, but at least the semantics is clear. Kanguole 22:01, 6 September 2023 (UTC)[reply]
    (edit conflict)
    Asian names in cs1|2 templates are problematic. In addition to the issue you describe, it is my understanding that when citing a person with an Asian name, the name should be written using the logograms because, apparently, it is not possible to accurately convert a transliteration, Qiu Xigui for example, to its logographic form(s): 裘锡圭 (zh-Hans) or 裘錫圭 (zh-Hant). Very often I see Asian names in cs1|2 templates written in |author= to 1) avoid the comma separator issue and 2) to include a logographic form: |author=Qiu Xigui (裘錫圭) (flipped order also).
    I don't think that |name-separator=none is a solution because such a parameter would apply to all names in the list so a list of mixed Asian and western names would result in malformed western names. Such mixed lists are quite common, especially in STEM topics.
    Format for using |author-mask= could be something like this:
    {{cite book |title=Title |surname=Qiu |given=Xigui |author-mask=Qiu Xigui (裘錫圭)}}
    Qiu Xigui (裘錫圭). Title.
    '"`UNIQ--templatestyles-0000002E-QINU`"'<cite id="CITEREFQiu" class="citation book cs1">Qiu Xigui (裘錫圭). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Qiu&rft.aufirst=Xigui&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
    I suppose that it might be possible to create |asian-surnamen=, |asian-givenn=, and |asian-authorn= parameters that would be rendered without the comma. I haven't given any thought to how this might be implemented. I suppose that in theory, when all three are present, |asian-authorn= would hold the author name in logogram form so cs1|2 could build an internal |author-mask= as shown above.
    Trappist the monk (talk) 22:17, 6 September 2023 (UTC)[reply]
    that allows one to mix and match asian and non-asian in the same person. first=Frank asian-last=Wong. That is a recipie for confusion. Perhaps is-asian-name1=yes/no AManWithNoPlan (talk) 22:26, 6 September 2023 (UTC)[reply]
    Oh yeah, I didn't mention below but I don't think a separate group of parameters for cultures where the family name is presented first is the solution here. Seems messy, and in addition to the case above we have authors of Asian descent who live and work in the West and have chosen to present their name in the Western order, so attaching an ethnic label to their name or not isn't something I'd want to get into. Folly Mox (talk) 22:34, 6 September 2023 (UTC)[reply]
    Yeah my thought for |name-separator= was to have it be a group of parameters (|editor2-name-separator= etc.) to avoid the issue you mention. Apologies I failed to clarify that in the original post.
    It is true that it's usually not possible to reconstruct the Chinese original from a pinyin transliteration, which is a lossy conversion. For this specific case we have an article on the individual so it's not necessary per MOS, but often it is important to include the actual words alongside transliterations, which I've also seen as |last=Qiu 裘|first=Xigui 錫圭. It sounds like the |-mask= series of parameters is the easiest way to implement what I'm looking for without messing with the underlying metadata. Folly Mox (talk) 22:31, 6 September 2023 (UTC)[reply]
    I think the current author-mask solution/provision is appropriate if painful for people who really wish to style these a certain way.
    Incidentally and personally, the only reason I put these in |author= is because I never know which name is given and which is family, with the large number of Americanized East-Asian names being in the same order as other American names typically are. Izno (talk) 20:55, 8 September 2023 (UTC)[reply]

    Replacing “curly” quote marks with "typewriter" quote marks

    Lines 478–479 of Module:Citation/CS1 read:

    label = mw.ustring.gsub (label, '[“”]', '\"');
    label = mw.ustring.gsub (label, '[‘’]', '\'');
    

    and are intended to:

    -- replace “” (U+201C & U+201D) with " (typewriter double quote mark)
    -- replace ‘’ (U+2018 & U+2019) with ' (typewriter single quote mark)
    

    in displaying chapter titles and the like, as far as I can tell.

    Could someone explain why this is done, please? 0DF (talk) 00:50, 8 September 2023 (UTC)[reply]

    To simplify the subsequent kerning patterns and because MOS:CURLY.
    Trappist the monk (talk) 00:56, 8 September 2023 (UTC)[reply]
    @Trappist the monk: I was not aware of MOS:CURLY. Thanks for the explanation. 0DF (talk) 03:16, 8 September 2023 (UTC)[reply]

    unicode v15.1 emoji

    in Module:Citation/CS1/Configuration/sandbox, emoji_t has been updated to unicode v15.1 Newly added unicode code points are:

    • U+2194 LEFT RIGHT ARROW
    • U+2195 UP DOWN ARROW
    • U+27A1 BLACK RIGHTWARDS ARROW
    • U+1F4A5 💥 COLLISION SYMBOL
    • U+1F7E9 🟩 LARGE GREEN SQUARE
    • U+1F7EB 🟫 LARGE BROWN SQUARE
    • U+1F9D2 🧒 CHILD

    Trappist the monk (talk) 18:12, 12 September 2023 (UTC)[reply]

    Irish language

    "Comhchoiste na Gaeilge, na Gaeltachta agus Phobal Labhartha na Gaeilge debate - Wednesday, 15 Jun 2022" [Joint Committee on The Irish Language, The Gaeltachts and the Use of Irish in Public]. Oireachtas.ie (in Irish). June 15, 2022.

    "|language=ga" resolves as "in Ga". is that a bug, or an unwillingness to decide on the "gaelic"/"Irish language" debate? -Bogger (talk) 16:02, 13 September 2023 (UTC)[reply]

    cs1|2 cannot distinguish between ga/Ga/GA/gA (the Ga language) and ga/Ga/GA/gA (the ISO 639-1 tag for Irish language) so defaults to language name. For Irish-language sources use |language=Irish; |language=Gaelic is accepted but is not recognized:
    {{cite book |title=Title |language=Irish}}Title (in Irish).
    {{cite book |title=Title |language=Gaelic}}Title (in Gaelic).{{cite book}}: CS1 maint: unrecognized language (link)
    Trappist the monk (talk) 16:24, 13 September 2023 (UTC)[reply]
    There are hundreds of articles to be fixed.  Working... GoingBatty (talk) 18:11, 13 September 2023 (UTC)[reply]
    @Trappist the monk: Now that I've updated over 100 articles, I'm wondering if there are any articles with citations with |language=ga that are supposed to represent the Ga language? The Ga language article doesn't use it. GoingBatty (talk) 02:24, 15 September 2023 (UTC)[reply]
    @Trappist the monk: Found Yacub Addy which uses |language=gaa:
    {{cite AV media |title=title |language=gaa}}title (in Ga).
    I've found a few articles where "ga" needed to be changed to "Galician", but none where "ga" meant the Ga language. GoingBatty (talk) 04:30, 15 September 2023 (UTC)[reply]
    The language tag for Galician is gl. Not surprised that there aren't many Ga-language sources.
    If you are interested, there is one other language-name/language-tag that can be confused:
    ho is the language tag for Hiri Motu but that can be confused with the Ho language name (tag: hoc)
    Trappist the monk (talk) 14:39, 15 September 2023 (UTC)[reply]
    Because our |language= documentation prefers language tags over language names, it occurs to me that Module:Citation/CS1 should presume that the value assigned to |language= is a language tag and not a two-character language name. So, I've switched the order of evaluation so that the module first assumes that |language= holds a tag and only when that fails, assume that |language= holds a language name:
    Cite book comparison
    Wikitext {{cite book|language=ga|title=Title}}
    Live Title (in Irish).
    Sandbox Title (in Irish).
    Cite book comparison
    Wikitext {{cite book|language=ho|title=Title}}
    Live Title (in Hiri Motu).
    Sandbox Title (in Hiri Motu).
    Trappist the monk (talk) 17:29, 15 September 2023 (UTC)[reply]
    How would you specify Ga as the language of the source if it works that way? -- LCU ActivelyDisinterested transmissions °co-ords° 19:49, 15 September 2023 (UTC)[reply]
    {{cite book |title=Title |language=gaa}}Title (in Ga).
    Trappist the monk (talk) 19:51, 15 September 2023 (UTC)[reply]
    Thanks Trappist. -- LCU ActivelyDisinterested transmissions °co-ords° 21:52, 15 September 2023 (UTC)[reply]

    US state format/guidelines in location parameter

    Are there guidelines regarding consistency of US state names used in |location= parameter? In Philippines, it previously used US state abbreviations for all its sources (example: |location=Berkeley, CA), but an editor several months ago changed most of them to avoid abbreviating the state names (|location=Berkeley, Calif.). What is the recommended format? Should I restore all state abbreviations or should I use their full names (|location=Berkeley, California)? Sanglahi86 (talk) 02:12, 15 September 2023 (UTC)[reply]

    See MOS:POSTABBREV. Nikkimaria (talk) 02:22, 15 September 2023 (UTC)[reply]
    Thank you for the information. Sanglahi86 (talk) 02:28, 15 September 2023 (UTC)[reply]

    Language=de in "Ça plane pour moi"

    Hi, I can't understand why language=de doesn't work in "Ça plane pour moi" (note 32, "Offiziellecharts.de – Plastic Bertrand – Ça plane pour moi". GfK Entertainment charts. Retrieved 15 February 2021).-- Carnby (talk) 20:08, 15 September 2023 (UTC)[reply]

    Maybe because it's French?--Sturmvogel 66 (talk) 20:48, 15 September 2023 (UTC)[reply]
    Because there is no citation template used there. I have added {{in lang}} to the "West Germany" entry in {{Single chart}}. I don't know if that will be accepted by the editors there, but it seemed like a nice thing to do for readers. – Jonesey95 (talk) 21:07, 15 September 2023 (UTC)[reply]
    I've checked {{Single chart}}: apparently {{in lang|de}} works only if access-date is set before 2020.-- Carnby (talk) 21:14, 15 September 2023 (UTC)[reply]
    @Jonesey95: Thank you. Could you please add it just after the title like in Austria or the Netherlands?--Carnby (talk) 21:20, 15 September 2023 (UTC)[reply]
    Moved. Is it better now? – Jonesey95 (talk) 22:34, 15 September 2023 (UTC)[reply]
    Perfect! Thank you!.-- Carnby (talk) 12:54, 16 September 2023 (UTC)[reply]

    Adding a second archive url

    Given the fact that sometimes Internet Archive will remove the archives of a webpage, amd that the whole Internet Archive enterprise may be in legal jeopardy, I was hoping it would be possible to add a second webarchive parameter. When I am creating a reference, I don't mind going to the trouble of creating an archive.today backup, and it seems good to have some redundancy so that archived links don't just disappear if IA ceases to exist. I think this would also imply a new parameter to track url archive status as well. -Furicorn (talk) 11:53, 16 September 2023 (UTC)[reply]

    Clarifications on cite template usages and descriptions

    I have a few questions about the templates, I would love to add these clarifications to the table, as well as to the text of the individual templates, as I can't imagine I'm the only one with these kinds of questions.

    • {{Cite AV media}} - is this only for physical media? or does it also cover things like news broadcasts? Why does it exclude online videos? How does it differ from cite podcast? I know people can use cite web, but if you're citing a youtube video typically people aren't citing the comments
    • {{Cite encyclopedia}} - is this also used for edited scholarly collections where each scholar provides a chapter? the description on the template makes it sound like it also includes those kinds of works, but I've historically used {{Cite book}} for a chapter in a book like that
    • {{Cite interview}} - is this only for written interviews or does it also include video interviews?
    • {{Cite technical report}} - can this description be specified a bit more, how does this differ from {{Cite report}}, seems to me govt bodies could def issue a technical report but I can't really tell from the current description
    • {{Cite podcast}} - can a youtube channel be considered a podcast, since you can access a youtube channel via an RSS reader. Also why is this separate from {{Cite episode}}? It seems like they are both episodic content, and nowadays podcasts sometimes even have networks, or are distributed on the radio. I'm thinking a lot about online videos in the way we think about books, books get cited with the same template whether we found them online or physically, and I just wanted to maybe open a discussion about the proliferation of video media citations types.
    • {{Cite episode}} vs {{Cite serial}} how would you choose one over the other, the difference here really confuses me.

    Thanks! -Furicorn (talk) 12:28, 16 September 2023 (UTC)[reply]

    I have never heard of {{Cite AV media}} applying only to offline sources, and in fact have only ever used it to cite sources with a working url or archive-url. I also use {{Cite book}} to cite books with individual chapter contributions. My feeling is that {{Cite encyclopedia}} is more for works with entries rather than chapters, but I'm not an expert on this. Folly Mox (talk) 16:10, 16 September 2023 (UTC)[reply]

    DOI filling in URL in Cite journal

    In the article October 1 (film), I've added DOI parameters for several journal articles, but it's linking the article title to the DOI even though I have not used the url parameter.

    For example: {{Cite journal |last=Ezepue |first=Ezinne Michaelia |last2=Nwafor |first2=Chidera G. |date=July-September 2023 |title=''October 1'': Metaphorizing Nigeria's Collective Trauma of Colonization |journal=[[SAGE Open]] |doi=10.1177/21582440231197271 |doi-access=free}}

    displays as:

    Ezepue, Ezinne Michaelia; Nwafor, Chidera G. (July–September 2023). "October 1: Metaphorizing Nigeria's Collective Trauma of Colonization". SAGE Open. doi:10.1177/21582440231197271.{{cite journal}}: CS1 maint: date format (link)

    This hasn't happened in the past; was there a change to the template or something? voorts (talk/contributions) 14:03, 17 September 2023 (UTC)[reply]

    This functionality is not new. It was implemented at the 11 July 2020 module suite update as a result of these discussions:
    If you don't want |doi= to link |title= then:
    {{Cite journal |last=Ezepue |first=Ezinne Michaelia |last2=Nwafor |first2=Chidera G. |date=July–September 2023 |title=''October 1'': Metaphorizing Nigeria's Collective Trauma of Colonization |journal=[[SAGE Open]] |doi=10.1177/21582440231197271 |doi-access=free |title-link=none}}
    Ezepue, Ezinne Michaelia; Nwafor, Chidera G. (July–September 2023). "October 1: Metaphorizing Nigeria's Collective Trauma of Colonization". SAGE Open. doi:10.1177/21582440231197271.
    Trappist the monk (talk) 15:23, 17 September 2023 (UTC)[reply]
    Thank you! I'm not sure why this has never occurred for me before. Very odd. voorts (talk/contributions) 15:26, 17 September 2023 (UTC)[reply]
    I think it only makes the link when |doi-access=free is present. —  Jts1882 | talk  15:32, 17 September 2023 (UTC)[reply]
    There was another cite in the article without |doi-access=free where the same behavior was occurring. voorts (talk/contributions) 15:37, 17 September 2023 (UTC)[reply]
    If PMC is set it'll use the PMC link. Headbomb {t · c · p · b} 16:04, 17 September 2023 (UTC)[reply]
    Are you sure? Going back to the last edit from 16 September 2023 (permalink) and the version just before you added |title-link=no (permalink) and looking for doi in the wikitext, I find two |doi= parameters with |doi-access=free and one |doi= without. Can you show me the [other] cite in the article without |doi-access=free where the same behavior was occurring? I presume that your same behavior means title-linked-from-doi.
    And, by the way, |title-link=none when {{cite journal}} has a doi but does not have |doi-access=free is meaningless clutter.
    Trappist the monk (talk) 16:32, 17 September 2023 (UTC)[reply]
    You're right. I must have misremembered. I'll remove |title-link=none from the cite without |doi-access=free. voorts (talk/contributions) 16:40, 17 September 2023 (UTC)[reply]

    Maintenance category for supplemental issues in volume

    See this in particular.

    The pattern is |volume=\d+ *Suppl\.? *\d+. Headbomb {t · c · p · b} 21:37, 17 September 2023 (UTC)[reply]

    Is a supplement always considered to be an issue? Is it possible to have volume, issue, and supplement all at the same time?
    COinS has a &rft.part keyword for journal objects:
    Part can be a special subdivision of a volume or it can be the highest level division of the journal. Parts are often designated with letters or names, i.e. "B", "Supplement".
    That is different from &rft.issue. We could adopt |part= and |supplement= (as aliases of each other) and support them with &rft.part
    If we do this, how do we render it?
    when only volume with supplement?
    when only issue with supplement? (if this is possible)
    when volume, issue, with supplement? (doi:10.1161/CIRCULATIONAHA.110.971028 doi:10.1212/WNL.48.5_Suppl_6.2S)
    What value does |supplement= get when when a supplement is not enumerated? (doi:10.1016/j.parkreldis.2007.06.003) Are 'special issues' supplements? (doi:10.36076/ppj.2013/16/SE217) How do we support that?another alias, |special-issue=?
    Do we support |part= or |supplement= in non-journal citations?
    If we do this that resolves the with-a-dot-without-a-dot bug report at User talk:Citation bot § Treat Suppl. as Suppl because it is the template's job to format its output.
    I got my example DOIs from this search
    Trappist the monk (talk) 23:27, 17 September 2023 (UTC)[reply]
    For journals, supplements are always issues. There might be books with "Volume 3, Supplement 2" or something, but those would be the odd balls out. For the above Circulation, we'd have |issue=18 Suppl 3. (They have Issue 11, Issue 11 Supplement 1, Issue 16, Issue 16 Supplement 2, Issue 18, Issue 18 Supplement 3, the rest being regularly numbered issues). For P&RD, it's an unnumbered supplement, so simply |issue=Suppl (or equivalent). The issue here isn't detecting weird stuff in |issue=, it's detecting weird stuff in |volume=. Headbomb {t · c · p · b} 01:01, 18 September 2023 (UTC)[reply]

    Push PMC limit to 11000000

    To deal with the cases in Category:CS1_errors:_PMC, e.g. PMC 10500258. Headbomb {t · c · p · b} 22:04, 17 September 2023 (UTC)[reply]

    Cite conference format question

    I am planning to convert some citations using {{cite report}} to {{cite conference}}. However, I find the format of cite conference a little confusing and somewhat bloated. As shown in the second citation below, using |title=, |conference=, and |publisher= in cite conference displays the term "Asia-Pacific Regional Conference on Underwater Cultural Heritage" thrice (although I may be unknowingly misusing the parameters). How should the cite conference citation be formatted?

    {{cite report|type=Conference proceeding |last=Bolunia |first=Mary Jane Louise A. |chapter=Astilleros: the Spanish shipyards of Sorsogon |chapter-url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |title=Proceedings of the 2014 Asia-Pacific Regional Conference on Underwater Cultural Heritage Conference; Session 5: Early Modern Colonialism in the Asia-Pacific Region |url=http://www.themua.org/collections/collections/show/13 |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |publisher=Asia-Pacific Regional Conference on Underwater Cultural Heritage Planning Committee |page=1 |location=Honolulu, Hawaii |oclc=892536655 |via=The Museum of Underwater Archaeology}}

    {{cite conference |last=Bolunia |first=Mary Jane Louise A. |conference=Asia-Pacific Regional Conference on Underwater Cultural Heritage |chapter=Astilleros: the Spanish shipyards of Sorsogon |chapter-url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |title=Proceedings of the 2014 Asia-Pacific Regional Conference on Underwater Cultural Heritage Conference; Session 5: Early Modern Colonialism in the Asia-Pacific Region |url=http://www.themua.org/collections/collections/show/13 |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |publisher=Asia-Pacific Regional Conference on Underwater Cultural Heritage Planning Committee |page=1 |location=Honolulu, Hawaii |oclc=892536655 |via=The Museum of Underwater Archaeology}} Sanglahi86 (talk) 06:46, 20 September 2023 (UTC)[reply]

    Someone might correct me, but I think the problem is that you are trying to cite the conference and the published proceedings of the conference in the same cite. I think the following would be correct:
    {{cite conference |last=Bolunia |first=Mary Jane Louise A. |conference=Asia-Pacific Regional Conference on Underwater Cultural Heritage |title=Astilleros: the Spanish shipyards of Sorsogon |url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |page=1 |location=Honolulu, Hawaii |oclc=892536655 |via=The Museum of Underwater Archaeology}} -- LCU ActivelyDisinterested transmissions °co-ords° 11:27, 20 September 2023 (UTC)[reply]
    {{cite conference}} should be rewritten (I've been saying that for years now). The purported purpose of {{cite conference}} is to cite a paper in a proceedings. If one is to believe OCLC, the title of the proceedings is: Proceedings of the 2nd Asia-Pacific Regional Conference on Underwater Cultural Heritage. Googling that, I found an editors list: Hans van Tilburg, Sila Tripati, Veronica Walker, Brian Fahy, Jun Kimura. Elsewhere I found a url for all of the papers for the conference but I didn't find consistent publication data; some sites say the publisher is the conference organizing committee, another names The Museum of Underwater Archaeology. The online version of the cited paper itself does not indicate that it was presented at a conference and in fact, does not mention any conference or proceedings.
    Absent a clear and consistent indication of the necessary bibliographic detail, I would shift from {{cite report}} to {{cite web}}:
    {{cite web |last=Bolunia |first=Mary Jane Louise A. |title=''Astilleros'': the Spanish shipyards of Sorsogon |website=The Museum of Underwater Archaeology |url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |url-status=live |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |page=1}}
    Bolunia, Mary Jane Louise A. "Astilleros: the Spanish shipyards of Sorsogon" (PDF). The Museum of Underwater Archaeology. p. 1. Archived (PDF) from the original on April 13, 2015. Retrieved October 26, 2015.
    If you have a physical copy of the proceedings to hand, then {{cite conference}} might be usable, if not, stick to {{cite web}}; WP:SAYWHEREYOUREADIT.
    Trappist the monk (talk) 14:22, 20 September 2023 (UTC)[reply]
    I think the problem with inconsistent publisher information probably stems from the fact that most conference proceedings are published as a joint collaboration between the organising body and some academic publisher. Since many systems (including our own) only have space for one publisher, people have to pick and choose, similar to how in previous centuries books could be published by a publishing house, but printed by a subcontracted press.
    WP:SAYWHEREYOUREADIT is good advice, but I don't think I would ever remove the information that a certain paper was published as part of a conference proceedings (like how an academic bibliography would cite it) just because I read it online instead of perusing a physical book. If I took that logic train all the way to its terminus, I'd be using {{cite web}} for all the book and journal citations I add apart from the books that are present physically at my home. Folly Mox (talk) 14:40, 20 September 2023 (UTC)[reply]
    I would suggest using |conference=Asia-Pacific Regional Conference on Underwater Cultural Heritage, |book-title=Proceedings of the 2014 Asia-Pacific Regional Conference on Underwater Cultural Heritage Conference and |title=Astilleros: the Spanish shipyards of Sorsogon. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:52, 20 September 2023 (UTC)[reply]

    Contributors for a book with no primary author

    I'm trying to cite a chapter in a book that doesn't have a primary author, but rather three editors and then contributors for each chapter. When I try to use |contributor-last=, it throws an error and does not display the contributor name: [1]

    Switching to |author-last= fixes this: [2]

    Is this a case of the error correctly pointing me to the appropriate way to format this information? Or is it leading me to incorrectly document that the chapter's author was the main author of the book (in which case we would need to fix CS1/error detection to permit citing contributors in books without a primary author)?

    References

    1. ^ Donald, Stephanie Hemelryk; Hong, Yin; Keane, Michael, eds. (August 23, 2002). "The Surfer-in-Chief and the Would-Be Kings of Content: A Short Study of Sina.com and Netease.com". Media in China: Consumption, Content and Crisis. London: RoutledgeCurzon. pp. 192–199. ISBN 978-0-415-40627-7. {{cite book}}: |contributor= requires |author= (help); |contributor= requires |contribution= (help)
    2. ^ Xin, Hu (August 23, 2002). "The Surfer-in-Chief and the Would-Be Kings of Content: A Short Study of Sina.com and Netease.com". In Donald, Stephanie Hemelryk; Hong, Yin; Keane, Michael (eds.). Media in China: Consumption, Content and Crisis. London: RoutledgeCurzon. pp. 192–199. ISBN 978-0-415-40627-7.

    {{u|Sdkb}}talk 05:44, 22 September 2023 (UTC)[reply]

    |author=/|last= is used for the author of a chapter in a volume edited by |editor=.
    |contributor= is used more when there isn’t an editor of a book; rather the book has an author, but that author did not write one section (like an introduction). See the (help) link in the error message.
    Second citation looks fine (although I don’t know any citation styles which require specifying the publication date—a full month, day, year—for a print volume instead of just the year. |doi=10.4324/9781315870663 would also be nice and you probably don’t need to link the publisher; Routledge is pretty well known. Umimmak (talk) 06:11, 22 September 2023 (UTC)[reply]

    Request to expand checks for bad URLs

    Could you please consider expanding the checks for bad URLs to also catch hhttp and hhttps? I stumbled across one of these today, and was surprised it didn't have an error message.

    {{cite web |title=Title |url=http://foobar.com |website=Good example}}
    "Title". Good example.
    {{cite web |title=Title |url=http//foobar.com |website=Error displays}}
    [http//foobar.com "Title"]. Error displays. {{cite web}}: Check |url= value (help)
    {{cite web |title=Title |url=hhttp://foobar.com |website=No error displayed}}
    [hhttp://foobar.com "Title"]. No error displayed.

    If you were to do add these so they are included in Category:CS1 errors: URL, I'll periodically run my bot to fix them. Thanks! GoingBatty (talk) 00:17, 23 September 2023 (UTC)[reply]

    60 uses. Izno (talk) 16:57, 25 September 2023 (UTC)[reply]

    Also this:

    • insource:"%7" insource:/%7[Cc](%20)*(url|archive|title|access|work|website|last|first|author|date|quote|publisher|isbn|editor|agency|location|page|language|trans|type|format|doi|jstor|)/] (697)

    Not all are errors, most are. This is for Cite Web. There are still some arguments missing, I didn't want to overload regex search. -- GreenC 18:33, 25 September 2023 (UTC)[reply]

    Oh no! What process causes | to be escaped as %7c? Folly Mox (talk) 06:12, 28 September 2023 (UTC)[reply]
    Automated editing that doesn't parse things correctly which can be a GIGO situation [input], tool bug [output], or some series of both. If someone wanted to try and determine a prolific culprit it would be helpful, assuming they exist and it hasn't been fixed yet. But I think this sort of thing is par for the course and new ones will keep showing up indefinitely. -- GreenC 07:36, 28 September 2023 (UTC)[reply]

    Can someone add Creative Commons parameters to the Cite template?

    Template:Creative Commons text attribution notice is designed to go inside <ref> tags. This is impossible to do in Visual Editor (see background info here). In the free content movement, we spend a lot of energy trying to get institutions to release content under Wikipedia-compatible licenses, but within Wikipedia re-use of that content is actually hampered by technical limitations such as this one.

    A good solution could be to add the five Creative Commons parameters to Template:Cite. These templates could then be displayed as options within the Add Citation dialog box in Visual Editor. If these parameters were made available as part of the citation itself, contributors would not have to insert Template:Creative Commons text attribution notice. What do you all think? Clayoquot (talk | contribs) 21:57, 23 September 2023 (UTC)[reply]

    The information in cite templates is intended to help readers verify a claim made in an article by providing information useful in locating the cited source, and ideally, a location within the source. Attribution notices lie outside of that scope. It is trivial to place the attribution notice in the References section or inside the ref tags. If the Visual Editor can't help editors do this in a reasonable way, you might want to file a Phabricator ticket and then, while you are waiting for someone to address the ticket, add a section to Wikipedia:VisualEditor#Limitations. – Jonesey95 (talk) 22:17, 23 September 2023 (UTC)[reply]
    Reference templates are for WP:V purposes. Licensing is not a matter of referencing. Headbomb {t · c · p · b} 01:04, 24 September 2023 (UTC)[reply]
    Side note: Clayoquot, if you're trying to make these free content notices easier to use in the visual editor, you could add template data to their documentation. That would be universally appreciated. Good luck, Rjjiii (talk) 02:05, 24 September 2023 (UTC)[reply]
    Thanks everyone for the prompt responses and suggestions. I'll follow up with Jonsey95's ideas. Rjjiii (talk · contribs), is there a place where I could flag down a volunteer who might be able to add template data? I don't know if I'll have bandwidth to figure out how to do it. Cheers, Clayoquot (talk | contribs) 17:48, 24 September 2023 (UTC)[reply]

    s2cid

    Kalambo structure is currently on the main page (In the news) and is returning the error "Check |s2cid= value". Not the best look for Wikipedia. I checked and double-checked the value (262084949) and it is correct. Help:CS1_errors#bad_s2cid says "if the value is correct and larger than the currently configured limit of 262000000, please report this at Help talk:Citation Style 1, so that the limit can be updated." Here I am. Viriditas (talk) 08:33, 25 September 2023 (UTC)[reply]

    @Trappist the monk: A cited journal paper in Philosophical pessimism has an identifier of S2CID 262038677, which excesses the currently configured limit of 262000000 and leads to a bad S2CID error of Citation Style 1. Please update this limit. NmWTfs85lXusaybq (talk) 13:02, 25 September 2023 (UTC)[reply]

    Suggest of "require" TemplateData param property

    I suggested new TemplateData param property "require" or "depend on" to indicate that a param requires another (or depends on) other param. We need this property for citation params for example:

    • "url-status", "url-access" and "access-date" all of them require "url"
    • "dio-access" requires "dio"
    • "author-first", "author-mask" and "author-link" all require "author-last"

    please disscus this in phab:T347377. حبيشان (talk) 07:25, 26 September 2023 (UTC)[reply]

    Update chapter and format sections??

    I dunno if it's worth it, but I was wondering if it's worth mentioning in the 'format' section any relevant policies related to ISBN and ISSN numbers, where the journal or book cited may be in ebook, hardcover, or paperback form and each having a different ISSN or ISBN. Sort of along the lines of why locations are often cited, each location has a slightly different edition and ISSN/ISBN in many cases and thus providing the location helps to find the exact version of whatever. Similarly, I know I was a bit confused by what to do with chapter DOIs. Apparently, a variable for this was proposed back in 2020 and then scrapped (Help talk:Citation Style 1/Archive 70#Auto-linking titles with free DOIs under sub-section 'Auto-linking for book chapters'). I'm assuming, not sure if this is correct or not, that in such cases the current protocol is to use the 'cite chapter' tag and then cite the corresponding chapter DOI and maybe it might be worth mentioning it under the chapter sections of this document? And I'm also not sure I have the current consensus correct either, but, was wondering if for future ease of newer editors and for the ease of users, if updating this document to include sections about what to do in such instances may be worth explicitly mentioning. Thanks for reading. Thoughts? KnowTheManyHistories (talk) 01:12, 27 September 2023 (UTC)[reply]

    For the first question, if I understand it, the relevant guideline is at WP:SAYWHEREYOUREADIT. For the chapter DOI issue, please give an example. – Jonesey95 (talk) 03:55, 27 September 2023 (UTC)[reply]
    |format= is for the kind of file at the other end of a URL. It might as well be named |url-file-format=. If you are using it in some other way, that's incorrect. Izno (talk) 20:33, 29 September 2023 (UTC)[reply]

    Generic title

    Hello, another generic title that could do with flagging up is "Wayback Machine has not archived that URL". Keith D (talk) 11:38, 27 September 2023 (UTC)[reply]

    Also "Subscribe to The Daily Telegraph for exclusive stories" - currently 79 of these. -- John of Reading (talk) 12:12, 27 September 2023 (UTC)[reply]
    I've seen a lot of cases of generic titles being reduced to blank space, in effect swapping one error for another. Does anyone know if there's a bot that does this or if it's always the work of human editors? It doesn't seem helpful. Folly Mox (talk) 17:08, 27 September 2023 (UTC)[reply]

    book citation parameter for publisher product pages?

    Many books now, especially from academic presses, have a product page with a table of contents, some positive review excerpts, a brief author bio, and a link to purchase the book. Sometimes – but more often not – these pages have a DOI pointing to them. In general I don't like having these pages as the "url" parameter for a book, linked to the book title, because readers trying to verify citations cannot easily look at the text there and are likely to be at least slightly misled by the unadorned link. However, putting a url-access=subscription red lock icon by such links also doesn't quite seem appropriate. Would it be helpful for the citation templates to add some kind of "product page" parameter for such links? I'm not sure what the best way to render them would be. –jacobolus (t) 15:40, 27 September 2023 (UTC)[reply]

    Sometimes an article, book, journal, magazine, etc., is available for download but there is also an abstract page with metadata. It would be nice if the templates had separate parameters for linking to both the abstract and the actual document. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:45, 27 September 2023 (UTC)[reply]
    In such a case, if the abstract page clearly links to the PDF / full text, then it is appropriate to always link the abstract page. Readers can easily do one extra hop to arrive at the full text. (But that's a different kind of situation than what I am talking about here, and is not really relevant to my question.) –jacobolus (t) 16:58, 27 September 2023 (UTC)[reply]
    In cases where the full text is not available online, a link to the publisher's landing page is often better than nothing, although it's pretty silly when they get archived. I agree that |url-access=subscription doesn't seem appropriate for this sort of URL, but maybe it actually is and I just feel wrong about it.
    I don't think the solution is a |product-url= parameter, if that's what's being suggested. It would be mildly helpful for distinguishing without clickthrough whether a URL pointed to the source text or not, but would overwhelmingly end up being used for promotion, in my opinion. Folly Mox (talk) 17:06, 27 September 2023 (UTC)[reply]
    I don't think I agree that a URL pointing at the landing page is better than nothing. It sets a misleading expectation for readers, who click through and are then disappointed when they can't actually see the source. I guess one current workaround could be something like |id=[http://example.com Publisher's site], but this seems like an abuse of the ID parameter. I don't really understand why links explicitly designated as pointing at a publisher's page would be more "used for promotion" than links on the book title, links from a DOI, etc. I guess my key point is that these are links about the book rather than containing the book. Perhaps instead of url-access=subscription there should be a synonym like url-access=purchase (instead of a lock icon it could perhaps use a $ icon). –jacobolus (t) 17:25, 27 September 2023 (UTC)[reply]
    I see your point about a link to a landing page not necessarily being better than nothing. I guess I see it as skipping a few steps from tapping an ISBN link, then a search link at whichever cataloguing site I prefer (OCLC, gbooks, whatever): the landing page won't contain the full text, but demonstrates instantly that the source exists, and shows who publishes it (in case I somehow have a subscription with them). It sounds like you and I have different expectations around what a linked title in a book citation will lead to, and I'm not sure which of our perspectives is more broadly shared in the community or in the readerbase.
    As to promotional use of a putative |product-url=, I am imagining well-meaning editors adding |product-url= values to citations where the full text is already available somewhere, as well as links to Amazon pages. I'd be happy to hear what others think about these things. Folly Mox (talk) 18:55, 27 September 2023 (UTC)[reply]
    I definitely don't mean Amazon pages. I was thinking of either the author's personal page about their book (but not containing it), or the publisher's product page, or something like that. Sometimes such URLs contain valuable auxiliary material like images, code, extended bibliography, sample chapters, errata, etc., but as a reader I still find them frustrating if I was expecting to click and get the source directly. –jacobolus (t) 20:33, 27 September 2023 (UTC)[reply]
    I understand that you definitely don't mean Amazon pages. My concern is the misinterpretation by future editors. I'm not sure if |type=publisher landing page is appropriate parameter usage, but might get the same point across without updating the templates. Folly Mox (talk) 21:07, 27 September 2023 (UTC)[reply]
    I would prefer not to add a parameter like this because having a parameter encourages editors to fill in the parameter and most of the time it should not be filled in. —David Eppstein (talk) 21:27, 27 September 2023 (UTC)[reply]
    What is the problem with |url-access=subscription? It is possible to have subscription access to books. (For instance my employer supplies me with a subscription to many Springer books.) That said, I tend to avoid using publisher urls in the |url= parameter, except for open-access books, mostly per WP:ELNO #5 as a page "that primarily exists to sell products or services". If it has a doi that can be included instead. —David Eppstein (talk) 19:24, 27 September 2023 (UTC)[reply]
    Is "url-access=subscription" appropriate for a page that says "click here to buy a physical copy for $100?" That doesn't seem to me like a subscription, but maybe the red lock icon is the right idea there. –jacobolus (t) 20:34, 27 September 2023 (UTC)[reply]
    If you have the subscription, what you see is different. —David Eppstein (talk) 20:38, 27 September 2023 (UTC)[reply]
    I think we are talking about different links here. Here are some specific examples of what I would call product pages that don't (as far as I can tell) involve any subscription: https://bookstore.ams.org/hmath-27, https://wwnorton.com/books/the-man-from-the-future, https://www.penguinrandomhouse.com/books/133168/prisoners-dilemma-by-william-poundstone/, https://mitpress.mit.edu/9780262518857/. –jacobolus (t) 20:48, 27 September 2023 (UTC)[reply]
    I can't tell because I don't have a subscription to those. Here's one that, when I visit it, shows me a prominent "Download book PDF" link (along with the table of contents, visible to everyone), but that probably looks like the same kind of product page to you: https://link.springer.com/book/10.1007/978-3-540-77974-2David Eppstein (talk) 21:29, 27 September 2023 (UTC)[reply]
    This link should work for any editors with Wikipedia Library access. Folly Mox (talk) 22:51, 27 September 2023 (UTC)[reply]
    I can't help thinking Wikilibrary links are a bad idea, they'd be incredibly helpful to me but most readers (or even editors) don't meet the criteria. If there was a coding way to autoswitch it would be great, but from past discussions there doesn't appear to be a real solution for that. Can't say I like the idea of |product-url= it looks ripe for abuse with spam or monetised links. -- LCU ActivelyDisinterested transmissions °co-ords° 23:33, 27 September 2023 (UTC)[reply]
    I agree that that's a bad idea. Our reader-facing content should be aimed at readers, not editors. Wikilibrary links are aimed at editors, not readers. —David Eppstein (talk) 00:33, 28 September 2023 (UTC)[reply]
    Oops apologies for my lack of clarity. I have never added a Wikipedia Library link to mainspace and don't propose to do so. I dropped the link there so people can compare how the landing pages look with and without a subscription to Springer. Folly Mox (talk) 01:14, 28 September 2023 (UTC)[reply]
    Okay, I hear you about the way a product-url or similar parameter would encourage more spam. @ActivelyDisinterested, @David Eppstein, @Folly Mox do you think product page links like the ones I linked above to university presses etc. (which I just recently removed from an article's citations) should be included as the "url" parameter in citations, or is it better to just go without a "url"? If they were included, should they include "url-access=subscription" (no subscription is available, but the main point of the page is to direct people to a 'buy' button)? –jacobolus (t) 01:29, 28 September 2023 (UTC)[reply]
    I think I'd like to hear more about what other editors expect to find behind a linked book title, because I think whether or not a product page is better than no url depends on what you're expecting.
    I will say that it looks like some nuance might be better, because not all of the links removed are the same sort. Some (like Springer) are identical to the DOI, and thus have no real purpose except to attract parameter cruft like unnecessary |access-date=, |archive-url=, and |archive-date=. Some (like OUP) certainly have an equivalent DOI, but it was not added. Most if not all of the academic publishers support a subscription model, so even a link to a landing page will lead to the full text for subscribers. In these cases, they'll almost certainly have a DOI as well, which are presumed to be subscription only, and if we're using DOI in place of equivalent URLs, the |url-access=subscription parameter will be both unnecessary and a template error. For academic publishers with subscription models but no DOI schema (I'm unaware of any), the landing page with |url-access=subscription seems appropriate. Lastly, the commercial publishers. I don't think a publisher like Random House Penguin or WW Norton offers a subscription to read their content, so works must be independently purchased. I don't think landing pages of this genre are helpful outside of verifying the work exists. I might be all the way wrong about these business models. Folly Mox (talk) 02:56, 28 September 2023 (UTC)[reply]
    I looked (briefly) for DOIs for the same books and added the ones I found, but didn't find some others, though I admit some of them might have DOIs I didn't locate in a brief search. The OUP ones are https://oup.com/academic/product/9780190655174 and https://oup.com/academic/product/9780190948191 – I still can't find any DOIs for these in a slightly less brief search. For academic publishers with subscription models but no DOI schema (I'm unaware of any), the landing page with url-access=subscription seems appropriate. I also added a couple of these, specifically to the links https://read.dukeupress.edu/hope/issue/24/Supplement (Duke) and https://muse.jhu.edu/book/17623 (UMichigan Press via a page at JHU Press) for which I could not find DOIs. –jacobolus (t) 02:59, 28 September 2023 (UTC)[reply]
    Apologies for my oversights. I didn't consult the later diffs. I seem to remember OUP having DOIs. I'll see if I can find the two. Folly Mox (talk) 03:30, 28 September 2023 (UTC)[reply]
    Attempt failed. I shouldn't have doubted you. Folly Mox (talk) 03:47, 28 September 2023 (UTC)[reply]
    No worries at all. :-)
    I can still plausibly imagine some Wiki authors wanting to keep these product page links, and would be happy to defer to some alternative (local or global) consensus about it. –jacobolus (t) 04:49, 28 September 2023 (UTC)[reply]
    For this one, I would recommend just linking the DOI. I'm not talking about SpringerLink pages or the like. –jacobolus (t) 01:23, 28 September 2023 (UTC)[reply]
    As a concrete example I just removed a bunch of product page links from John von Neumann in special:diff/1177440279, but perhaps other editors think those links should stay. –jacobolus (t) 20:36, 27 September 2023 (UTC)[reply]

    "URL access level" options

    Some publishers such as Springer Nature offer a type of URL that can be used as the URL and gives full open access to an otherwise paywalled source. It would be useful if there were an option in addition to 'registration', 'subscription' or 'limited', such as open (or equivalent name) that displayed a green padlock to make it clear these URL links do give the reader full access to the publication? Or should I use the 'limited' option?

    Example, this paper is normally paywalled, however this version of the link attained via Wikipedia Library be used as the citation URL and gives the reader full access.The grey 'limited' padlock is described for "free access is subject to limited trial and a subscription is normally required", should this be used instead? Zenomonoz (talk) 04:33, 28 September 2023 (UTC)[reply]

    I think these links are intended to be shared with a friend or two privately, not with the general public. I would recommend avoiding them in Wiki pages because my expectation is that they will stop working in a relatively short timeframe. If the publisher wants every reader to have open access to the paper, they'll publish the paper as open access.
    Here are the T&C: We support a reasonable amount of sharing of content by authors, subscribers and authorised users (“Users”), for small-scale personal, non-commercial use provided that you maintain all copyright and other proprietary notices. ... Users and the recipients of the shareable link, may not 1. use the SharedIt service or shareable links for the purpose of providing other users with access to content on a regular or large scale basis or as a means to circumvent access control; ... We are not obligated to publish any information or content and may remove it and the shareable links or any SharedIt features or functionality at our sole discretion, at any time with or without notice. We may revoke this licence to you at any time and remove access to any copies of the shared content or shared links which have been saved.... If you intend to distribute our content to a wider audience on a regular basis or in any other manner not expressly permitted by these Sharing Terms of Use please contact us at sharedit@springernature.com.
    Their examples are stuff like authors sharing a link to their own paper on facebook (an inherently temporary/ephemeral kind of sharing, to a relatively small group of readers). It does not really sound like "please publish this on Wikipedia" is one of the intended uses. –jacobolus (t) 05:00, 28 September 2023 (UTC)[reply]
    Thanks for your response. Zenomonoz (talk) 07:47, 28 September 2023 (UTC)[reply]

    |url-status=

    Of late there has been a bit of churn at Template:Citation Style documentation/url, likely due to discussion at User talk:Citation bot § Removing url-status = live.

    To minimize the documentation churn, we should discuss here and then change the documentation.

    You will note from the Citation bot discussion that there are those who believe that |url-status=<any legit value> should be allowed anytime and others who disagree (I am firmly in this latter camp).

    The recent churn at the documentation template caused me to take a hard look at the documentation for |url-status= which, to me, has become a rather confusing mishmash so I propose to replace it with something like this:

    • url-status: A control parameter to select one of |url= or |archive-url= to link |title=; requires url and archive-url. Use {{dead link}} to mark dead |url= when there is no |archive-url=.
      Accepts multiple keywords:
      • dead – (default when |url-status= omitted or empty) selects |archive-url=
      • live – selects |url=; used when |url= is preemptively archived
      • deviated – selects |archive-url=; used when |url= is still 'live' but no-longer supports the text in a Wikipedia article
      • unfit – selects |archive-url=; used when |url= links to porn, spam, advertising, or other unsuitable sites; links to |url= are suppressed in the rendering
      • usurped – selects |archive-url=; used when |url= links to information unrelated to the original link; links to |url= are suppressed in the rendering

    The current version doesn't clearly state the purpose of the parameter so I started there and then rewrote, as a list, the various keyword definitions. I removed mention of maintenance messaging because that just adds to the mess (and if we discuss maint messages here, we'll end up discussing them everywhere... so more mess elsewhere.

    Opinions?

    Trappist the monk (talk) 14:49, 29 September 2023 (UTC)[reply]

    If we're going to require |archive-url= can we say requires |url= and |archive-url=? |archive-url= already requires |url=. I will say I don't really like the {{dead link}} alternate (no idea how common this is), since it requires navigating to the end of the template call, and typing in a date, rather than just adding a parameter wherever. I understand this is probably easier on a keyboard. Folly Mox (talk) 14:59, 29 September 2023 (UTC)[reply]
    We could. I think that including |url= in the requirements more tightly binds the three parameters together as a unit and by doing so (perhaps) editors might be less likely to add stand-alone |url-status= to a citation (or not).
    It is not in the cs1|2 remit to assume the duties and infrastructure of inline citation cleanup templates. Adding |url-status=dead to a cs1|2 template that doesn't have |archive-url= with value does not now add the article to an Articles with dead external links category and should not do so in the future; that is not the purpose of |url-status=dead (and wasn't the purpose of its predecessor |dead-url=yes). And you don't have to type the date... AnomieBOT will do that for you.
    Trappist the monk (talk) 17:52, 29 September 2023 (UTC)[reply]
    All right, I can manage a little extra effort if it's for best practices. Your explanation for the wording makes sense as well. Thanks. Folly Mox (talk) 19:10, 29 September 2023 (UTC)[reply]
    Per Mike at Citation bot talk, archiveurl should not be required. Nikkimaria (talk) 03:11, 30 September 2023 (UTC)[reply]

    Agree with everything Trappist the Monk said. It makes no sense for the CS1|2 template to mark dead links, and then other non-CS1|2 templates use {{dead link}}, plus square and bare URLs - it's a confusing mismatch of systems that will be prone to error eg. people using one system, or another system, or both systems. Then there is all the legacy issues. 100s of bots, reports, tools, etc.. are configured to do things as they are. It will lead to breakages, errors, that will take years to resolve and cause a lot of damage upstream eg. reFill will take decades to fix at current pace, and VE who knows. Then there is the user-base, literally millions of brains which have been hard-wired by 15+ years of doing things this way that need change, it's unnecessarily disruptive. Once you know how its done, it's not hard to follow or understand. -- GreenC 04:16, 30 September 2023 (UTC)[reply]

    The only problem here is that |url-status= name causes confusion, which inturn leads to it being misused. The solution to that is not continued misuse. Clarification of how it should be used is definitely a step in the right direction. So inagre definitely agree with Trappist. Using {{dead links}} is a separate template the same as any other maintenance tag, citation needed, clarify, dubious for instance. -- LCU ActivelyDisinterested transmissions °co-ords° 10:23, 30 September 2023 (UTC)[reply]

    Per Nikki's comment above, here's a version of what I posted at the bot's talk. I have two use cases, one for |url-status=dead and one for |url-status=live. This URL will quite possibly go out of date in months; a quarterly update at that website causes pages like this to be regenerated and the URL may change (it's difficult to predict whether or not it will change, for reasons I can explain if anyone cares). When I create a link to that URL, it's live and not deviated, but I know it's possibly going to go out of date so I always add the archiveURL when I can. I have also been putting in |url-status=dead, because otherwise someone reviewing the links is likely to mark it as live. (At a recent FAC source review a reviewer suggested marking one of these as live, not dead, for example.)

    The use case for |url-status=live without archive-URL is when archive.org is down or refusing to archive, which happens fairly often. I try to always archive links when adding the citation; I think that's best practice. If I can't do the archive, then for the links I know are going to be stable long-term I add |url-status=live so that if someone else comes along and adds an archive URL it won't default to the archive link in the citation.

    I understand that neither use case exactly fits the intended use of these parameters, but they are natural ways to use them. My main complaint about the bot having removed them is that they are not inaccurate (they don't lead to erroneous output HTML) and they don't incorrectly represent reality. A response at the other conversation was that they do lead to maintenance message output, but if these use cases are a natural way to interpret the parameters I don't think these parameter states should generate maintenance messages. What is the harm in allowing this usage? Mike Christie (talk - contribs - library) 12:03, 30 September 2023 (UTC)[reply]

    I believe a lot of this comes from the fact that the parameter is named url-status, if it was renamed archive-url-switch or some other name this wouldn't be an issue (but that would require updating lots of other tools, so is a waste of resources).
    Using url-status to mark dead links seems like a bad idea, as it doesn't generate any visible output, unlike {{dead links}} which creates a proper maintenance message. -- LCU ActivelyDisinterested transmissions °co-ords° 12:23, 30 September 2023 (UTC)[reply]
    I agree that the name is what led me to use the parameters in this way. Why do you feel it needs correction, though? The negative outcome you give -- using url-status to mark dead links doesn't cause visible output -- doesn't apply here, as far as I can see, since I only set the parameter to dead when the archive-url is there, which means no further action is necessary. And dead-link would be wrong anyway -- this situation doesn't require a user to come along fix a link, which would be a hopelessly repetitive task for philsp.com, the website in question. (There are 771 cites to the website per an insource search I just did.) Mike Christie (talk - contribs - library) 12:30, 30 September 2023 (UTC)[reply]
    Any fix would be to stop it's misuse, but as I said renaming the parameter at this point is unlikely. -- LCU ActivelyDisinterested transmissions °co-ords° 19:13, 30 September 2023 (UTC)[reply]

    url=w.media false warning

    {{cite web |title=W.Media| url=https://w.media}} produces:

    "W.Media".

    It currently says "Check |url= value" but the link https://w.media works. The warning comes for a single-letter second level domain. Originally reported at Wikipedia:Village pump (technical)#.Media web sites confusing the cite web template. PrimeHunter (talk) 20:58, 29 September 2023 (UTC)[reply]

    fixed in the sandbox:
    {{cite web/new |title=W.Media| url=https://w.media}}
    "W.Media".
    Trappist the monk (talk) 21:42, 29 September 2023 (UTC)[reply]

    Protected edit request on 3 October 2023 Suggestion: Suggestion add template data

    Want to add TemplateData for Cite map so that it can work with ProveIt, using Cite book page as an example

    Change from: <includeonly>{{#invoke:Citation/CS1 | citation |CitationClass=map }}</includeonly><noinclude> {{documentation}} </noinclude>

    to

    <includeonly>{{#invoke:Citation/CS1 | citation |CitationClass=map }}</includeonly><noinclude> {{documentation}} {{collapse top|TemplateData}} {{Cite map/TemplateData}} {{collapse bottom}} </noinclude> Furicorn (talk) 20:52, 3 October 2023 (UTC)[reply]