This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 65 | ← | Archive 67 | Archive 68 | Archive 69 | Archive 70 | Archive 71 | → | Archive 75 |
This section in a nutshell: Effective
April 2020,
CS1 templates (e.g. {{
cite book}}, {{
cite journal}}, and the other {{cite ...}} templates) behave like
CS2 templates (e.g. {{
citation}}) with respects to the generation of harvard-style anchors (see
discussion). This means that adding |ref=harv to "long" CS1 citations is no longer required to use "short" citation templates like {{
harvnb}}, {{
sfn}}, and other {{
harv}}-like footnotes.
If you see more yellow warnings like
than usual, those are caused by User:Ucucha/HarvErrors.js. To suppress/reduce these yellow warnings, you can use any of the following options
If there still are errors after this, see how to deal with harvard-style citation issues. The documentation might be a bit out of date, but every piece of advice listed for CS2 (e.g. {{ citation}}) now applies to CS1 (e.g. {{ cite book}}) as well. If none of those options satisfy you, you can make a new script request at WP:SCRIPTREQ. |
Cite book has started giving a harv error message even when ref=harv has not been added. E.g.
It only did this before with the citation template. Many articles use this template without ref=harv, and they are all suddenly giving error messages, which is ugly and distracting. If it carries on I will have to turn off the harv warnings, but then I will not be warned when I am using ref=harv and I make a mistake. What is the position? Dudley Miles ( talk) 21:54, 18 April 2020 (UTC)
window.checkLinksToCitations = false;
Sorry I'm late, I posted the following at Template talk:Citation, and I appreciate much of this has been said and argued over already:
"This week, for the first time ever that I know of, ordinary {{cite web| ... and {{cite new| ... and probably other such templates are suddenly displaying warnings like
This type of message used to occur, helpfully, only when there was an explicit Harvard parameter indicating that links were expected: ... |ref=harv }]
That was useful as one normally only put the harv indicator in when the plan was to insert inline citations in the text, and missing one was obviously a problem.
Now, however, the error occurs WITHOUT the ref=harv parameter! This makes no sense: it causes an error if any citation is listed in a bibliography or further reading, and worse, if citations are listed inside an inline ref tag --- it seems to happen from the third citation onwards --- there is a fine specimen at K. Pattabhi Jois, and there is no visible means of suppressing the errors.
This makes checking for ACTUAL errors much more difficult, as false positive "errors" are displayed all over. Would be glad if the status quo could be resumed, please." Chiswick Chap ( talk) 12:18, 21 April 2020 (UTC)
third citation onwardsyou are referring to this group of references, the first two of that group do not have contributor, author, or editor names. An anchor ID is the concatenation of
CITEREF
, up to four contributor/author/editor names and a date. When there are no names, no anchor ID (this is not new).{{
harv}}
or {{
sfn}}
families of templates.Sorry to join in with this late. Looking at this from a different angle, automatically adding harv anchors to every cite template not immediately proceeded by a <ref> tag is adding unnecessary html to the page when parsed. Whilst this isn't a problem with only a few instances on the page, on certain pages with maybe 50 "Further reading" links, this will add a significant overhead to the html (which could be problematic on older mobiles). When the page is parsed to html, the harv anchors become html anchors with an id equal to the CITEREF anchor. In html, id's must be unique. When we had to add anchors manually, where we cite the same author with several publications in the same year we differentiate the anchors eg Smith 1990a; Smith 1990b; Smith 1990c; etc. Automatically adding the anchors, would in the above case give 3 anchors with an id of "Smith 1990", causing non-compliant html. This probably isn't a problem most of the time, but the worst case scenario would be the browser going into "quirks mode", stop rendering the page and then redraw the page once the html, css, javascript etc has finished downloading. Again, this is more likely to happen on mobiles. As 40 - 70% (dependent on who's figures you look at) of internet access is from mobiles, then how the site behaves on mobiles needs to be considered. Putting aside "errors" being shown up by scripts, we should be adding |ref=none to unused anchors to prevent html problems. -- John B123 ( talk) 16:05, 15 June 2020 (UTC)
automatically adding harv anchors to every cite template not immediately proceeded by a <ref> tag is adding unnecessary html to the page when parsed
<ref>...</ref>
tags and many of which are the targets of the short-form citations. In fact, I suspect that the opposite is true; in most cases, cs1|2 templates wrapped in <ref>...</ref>
tags don't need anchor IDs because generally, nothing links to them except the superscript added by cite.php
during conversion from wiki-text to html.where we cite the same author with several publications in the same year we differentiate the anchors eg Smith 1990a; Smith 1990b; Smith 1990c; etc. Automatically adding the anchors, would in the above case give 3 anchors with an id of "Smith 1990"
|date=
in the cs1|2 templates as should be done when citing three 1990 vintage Smith sources. The lazy en.wiki editor should have written {{cite ... |last=Smith |... |date=1990a |...}}
, {{cite ... |last=Smith |... |date=1990b |...}}
, {{cite ... |last=Smith |... |date=1990c |...}}
. If the article is using short-form citation templates to link to the long-form cs1|2 citations,
Module:Footnotes detects cs1|2 templates with identical anchor IDs and, when there is a short-form citation that uses that anchor ID, emits an error message. These error messages are hidden; see
:Category:Harv and Sfn template errors § Displaying error messages to learn how they may be displayed for you.|ref=none
. There has been some discussion about creating a cs1|2 configuration template that would be read when the wiki-text is converted to html that might be used to disable all cs1|2 anchor IDs except those specifically created (|ref=
has a value other than none
). As far as I know, no one is clambering for such a template.<ref>...</ref>
tags don't need anchor IDs because generally, nothing links to them - My point in mentioning the <ref>...</ref>
in my previous post was exactly that, the issue generally occurs outside the references section: Bibliography, Further reading etc. (On a side note, where multiple cite templates are bundled within single <ref>...</ref>
, anchors are added for the second and subsequent cites.)|date=
in the cs1|2 templates I'm not sure if it's laziness. Judging by the number of sfn and harv errors I've put right, I think it's lack of understanding rather than laziness. I doubt it would enter the mind of the average user to disambiguate dates when adding a list of articles to a "Further reading" section with nothing linking to them. --
John B123 (
talk) 19:25, 15 June 2020 (UTC)@ Trappist the monk:, can you point to where consensus was reached for this change?
This was the situation before the change. When writing an article, we compile a list of long citations under "Works cited" and use short citations (sfn or harvnb) throughout the text. The short links to the long. If we include a long citation but don't use it, we see a red error message. This is very useful.
What we might do at that point is move the unused reference into Further reading, and remove ref=harv. We do the same when compiling "Selected works" lists of publications. Then if we want to use the same long citation as a source again, we move it back into "Works cited" and add ref=harv; that allows us to restore an sfn citation.
That flexibility has now disappeared, it seems. Either we get ugly error messages all the time in Further reading and Selected works, or we turn them off and don't get the ones we need. SarahSV (talk) 03:00, 21 April 2020 (UTC)
These two discussions— here and here—don't amount to consensus. The second is from 2018; the first is more recent but hardly anyone commented. You need strong consensus for a change that affects so many people.
Can you explain about the broken anchors? (Your last point about equal footing means we've lost functionality/flexibility because CS1 and CS2 are now the same; that's not a benefit.) SarahSV (talk) 04:53, 21 April 2020 (UTC)
{{
harv}}
or {{
sfn}}
templates, the script is mute so reference sections are not cluttered with the warning messages. I use a different color scheme and my error messages don't shout so the look is a bit different. In
User:SlimVirgin/common.js, replace importScript('User:Ucucha/HarvErrors.js');
with importScript('User:Trappist the monk/HarvErrors.js');
.There is now no way to get rid of these error messages, because removing ref=harv no longer works.To quash the script warning messages in a Further reading section (or anywhere else), you can set
|ref=none
in the cs1|2 template. When set to this value, the cs1|2 templates will not create an anchor ID.For the broken anchors, see Help talk:Citation Style 1/Archive 46#broken anchors, I've updated the archive to reflect the old behaviour. For consensus, it's a pretty strong one. This fixes tens of thousands of broken anchors, putting CS1 and CS2 on par with each other, thus allowing for greater flexibility in the choice of CS1 and CS2 styles with an increased user-friendliness. That this reduces the usefulness of an opt-in, optional script used by about 200 active editors is not much of an argument compared to the benefits this brings to everyone else. Headbomb { t · c · p · b} 05:28, 21 April 2020 (UTC)
|ref=none
if you really don't want to see brown warning messages for those citations, but if you later want to move the citations up to Works cited, you'll need to remember to remove it. As it stands, seeing a brown warning for every entry in Further reading is a good way to confirm that those full citations are not being used in the article, as long as they are all formatted consistently.|ref=none
since it's not cited directly. The Gross 2003 citation works correctly, there's a collision, but it's not an important one.
Headbomb {
t ·
c ·
p ·
b} 06:06, 21 April 2020 (UTC)Re. "You could also ask ... at
WP:SCRIPTREQ ..." – anyhow, I posted a place-holder request there (
WP:SCRIPTREQ#HarvErrors.js), that is: inviting script-writing co-editors to come here to help determine what is feasible. I was thinking about placing an RfC at
WP:VPT to determine whether the "|ref=
harv " default is what editors generally want for cs1 cite templates, but didn't do that yet: I am still pondering whether that is a good idea (and if so: how to get it started on the right foot). --
Francis Schonken (
talk) 07:20, 21 April 2020 (UTC)
This is what I see now in "Selected works" and "Further reading" sections that use {{ cite book}}, {{ cite news}}, etc. Dudley and Gerda, have you been able to find a solution yet? SarahSV (talk) 18:28, 21 April 2020 (UTC)
|ref=none
to either {{
citation}} or {{
cite book}}, is actually easier than converting {{
citation}} to {{
cite book}}. –
Jonesey95 (
talk) 18:59, 21 April 2020 (UTC)
{{
harvnb}}
to that article and preview it, I see the appropriate error message and, because the article now has a short cite template (bogus or not), all of the warning messages. Read my reply. Try it. Report back here.namely when we use a long citation without a corresponding short one: that is not, and never has been, an error. Most Wikipedia articles are formatted with long citations that do not have short forms referring to them. Perhaps you have something more specific in mind, like "when we add a long citation to a references section that is only supposed to contain things that are referred to by short footnotes". The script you use did catch those, but caught a lot of non-errors besidea. If you want to catch these you will need a smarter script, one that is capable of distinguishing articles that use short citations for all references from articles that use them only for some or for none of the references. — David Eppstein ( talk) 19:45, 21 April 2020 (UTC)
|ref=harv
works exactly as before, and there is no degradation of anything. It simply has been made default to make templates more user friendly and to repair tens of thousands of broken anchors. However you dealt with warnings in CS2 before still apply here. There is literally no difference in how CS1 and CS2 templates behave. For the millionth time now, if you don't like how
User:Ucucha/HarvErrors.js behaves, then make a
WP:SCRIPTREQ for a new script.
Headbomb {
t ·
c ·
p ·
b} 19:34, 21 April 2020 (UTC)
long citation without a corresponding short one; the error messages apply to a short cite without a corresponding long citation.
importScript('User:Ucucha/HarvErrors.js');
importScript('User:Trappist the monk/HarvErrors.js');
The addition of ref=harv to cite book was the way linked and unlinked sources were distinguished. Now that ref=harv has been made non-functional, there is no way a script can distinguish between cases where cite book is being used with anchors or intentionally without. Dudley Miles ( talk) 20:00, 21 April 2020 (UTC)
|ref=harv
works exactly as it did before and generates a harvard anchor.
Headbomb {
t ·
c ·
p ·
b} 20:02, 21 April 2020 (UTC)|ref=none
inhibits anchor ID creation. This functionality was added several years ago specifically for {{
citation}}
so that editors didn't have to see the warning messages emitted by HarvErrors.js.Combining with Headbomb's suggestion at User talk:Citation bot/Archive_20#remove ref=harv, I see (for the time being) some possible tasks (please add more ideas worth considering if you think of any):
|ref=harv
currently throws a
maintenance category. Maybe it shouldn't, and maybe a bot removal isn't a good idea, but removing the parameters is not a cosmetic edit according to the definition in the policy.
Jo-Jo Eumerus (
talk) 19:05, 21 April 2020 (UTC)|ref=harv
s as a stand-alone task (
example) – are we OK with that? --
Francis Schonken (
talk) 18:50, 29 April 2020 (UTC)
|ref=
definition:
|ref=harv
being the default is that thousands of citation notes are fixed, and that it makes the entire citation ecosystem more user-friendly. The solution is to use a script that's up to date.
Headbomb {
t ·
c ·
p ·
b} 10:55, 19 April 2020 (UTC)|ref=
definition.
Two solutions work for me to stop the wrong error message when cite book is used without harv referencing. 1. Adding "window.checkLinksToCitations = false;" to "importScript('User:Ucucha/HarvErrors.js');" 2. Replacing "importScript('User:Ucucha/HarvErrors.js');" with "importScript(David Eppstein/HarvErrors.js);".
However, I have found a new problem. When cite book is used with ref=harv, I am getting an error message "CS1 maint: ref=harv (link)". Based on the comment of Trappist the monk above, this appears to be because CS1 has been changed to make harv referencing the default for cite templates, and give an error message for ref=harv on the ground that it is now redundant. Can I get rid of the wrong "CS1 maint: ref=harv (link)" error message by changing from CS1 to CS2, and if so how do I do that? Dudley Miles ( talk) 09:30, 19 April 2020 (UTC)
|ref=harv
is now the default, use of that parameter value no longer has meaning. The module suite adds the category so that editors and their tools can know where these parameters are being used so that they can be removed or modified.|ref=harv
. To remove the message, remove the parameter or change its assigned value to something more appropriate.|ref=none
, just as you could in CS2 before. Now people are free to use either CS1 or CS2, as they should have been a long time ago.
Headbomb {
t ·
c ·
p ·
b} 12:02, 19 April 2020 (UTC)
|ref=harv
is now the default, use of that parameter value no longer has meaning." Headbomb says "ref=harv is still working." Which is correct? What are the tens of thousands of broken citations which now work? Who decided that "Failing to remove an "unused" citation is not a high-priority issue"? In some cases they will have been removed because they are unreliable sources. The solution is to stop using citation templates. The latest changes have made them too difficult to use for anyone who is not a technical expert.
Dudley Miles (
talk) 12:48, 19 April 2020 (UTC)
|ref=harv
is the same as writing a cs1 template without |ref=harv
. In both cases, the template does the same thing. ref=harv is still workingbecause it is the same as the default. All other values assigned to
|ref=
are still handled in exactly the same way that they were handled before the module suite update..citation-comment {display: inline !important;} /* show all Citation Style 1 error messages */
|ref=harv
is not an edit that should be done on its own.
Headbomb {
t ·
c ·
p ·
b} 12:26, 20 April 2020 (UTC)
|ref=harv
would be bundled among those.
Headbomb {
t ·
c ·
p ·
b} 12:42, 20 April 2020 (UTC)Let's link this to policy: a WP:COSMETICBOT task, i.e. a bot performing cosmetic edits, is usually allowed if the WP:COSMETICBOT task is performed, in the same edit, with a substantial task. That does not make a WP:COSMETICBOT task a substantial task. Aligning citations with core content policies are, in contrast, substantial edits. A script that significantly assists with that is more important than whether or not a substantial edit has an appended cosmetic edit. The loss of perspective seems complete if you think that a cosmetic edit appended to a substantial edit is remotely as substantial as getting a script which has proven its usefulness for articles' WP:V compliance back on track. Trying to make policies say what they don't say is further illustration of that loss of perspective. -- Francis Schonken ( talk) 13:16, 20 April 2020 (UTC)
|ref=harv
) is now the default behaviour in CS1 templates, just like it was the default behaviour in CS2 templates. This has 2 main effects.
|ref=harv
to CS1 templates (or adding pointless |ref=harv
to CS2 templates because this was required in CS1 before). The number of actual errors (namely missing anchors) flagged by users scripts, like
User:Ucucha/HarvErrors.js has gone done significantly, leaving only things that now actually require human review, alongside a slight increase in collisions (which are flagged by HarvErrors scripts and other opt-in messages).|ref=harv
, will now warn against "missing" {{
sfn}}-generated anchors regardless of which of CS1 or CS2 templates are used. Additionally an opt-in CS1/CS2 maintenance message will display for those that choose to have those enabled. If those warnings bother you, then use
User:Svick/HarvErrors.js instead of
User:Ucucha/HarvErrors.js, and don't enable opt-in CS1/CS2 maintenance messages.I have checked the three solutions suggested and I see that they all work, but with reduced functionality as they do not highlight unused sources. This is an important issue as in some cases citations have been deleted because the sources are not reliable, and in other cases the book should be in further reading to signal to readers that it may contain additional information not covered in the article. I hope this deficiency will be resolved in the future. Dudley Miles ( talk) 14:58, 20 April 2020 (UTC)
"Ideas related to getting the HarvErrors script back on track" - how about putting it back how it was before the changes which were plainly made without consensus, and are certainly (judging by all the above) against consensus now? The hundreds of thousands of article-problems created would be seen from any rational standpoint as a powerful argument for reversion. Chiswick Chap ( talk) 13:19, 21 April 2020 (UTC)
The cite book functionality has not be degraded, it has been upgraded. You can now use harvard/snf templates with it without having to worry about explicitly declaring |ref=harv
. See for example
Smith (2016).
This fixed tens of thousand of broken footnotes everywhere on Wikipedia. It also makes the conversion of "manual" footnotes like <ref>Smith 2016</ref>
very much easier to do without having to worry about finding where the corresponding citation is in the text.
Headbomb {
t ·
c ·
p ·
b} 15:44, 21 April 2020 (UTC)
I never used HarvErrors.js. I do it all manually. Which can be a painstaking endeavour. Maybe if I'd used the script I'd have addressed this train-wreck of a "References" section (qualifying it WP:OVERREF is an understatement) a long time ago. CITEVAR issues regarding the article have been discussed on its talk page, e.g. here.
So, anyone to take up this challenge, that is the challenge of cleaning up "References", "Further reading" etc of
that article, with or without script assistance? I would like to get some feedback on how much difference the script (in its original and/or patched versions) makes in tackling such complex cases, and whether the task would have been easier before the "|ref=
harv " default for cs1 templates. Tx. --
Francis Schonken (
talk) 08:15, 21 April 2020 (UTC)
|ref=harv
would have shown the brown warnings. Now, the warnings are consistent whether CS1 or CS2 is used. In a situation like this, this change makes the script even more useful than it once was. Unless I am completely missing the point. –
Jonesey95 (
talk) 15:23, 21 April 2020 (UTC)Do we have a resolution to this issue yet? If a source is in the reference/bibliography/etc. section, it ought to be cited in the text, and the presence of warnings there that an anchor is not being used is a useful way to highlight the fact that the source either needs to be removed or shifted to a further reading section. Parsecboy ( talk) 11:58, 24 April 2020 (UTC)
There was a discussion at User talk:Citation bot/Archive 20#remove ref=harv about removing "ref=harv", and there was no consensus. Despite this, Headbomb continues to do it with AWB, first from templates now from drafts. This makes it a Wikipedia:Fait accompli, and ignores that retaining ref=harv makes it less of a nuisance to add ref=none (assuming this change to the templates sticks).
It concerns me how these discussions have been split across multiple pages. When I tried to open a central discussion at the PUMP, Kees08 closed it down; see the archived discussion. It means no one is keeping track of the objections and Headbomb can continue as if there is consensus. SarahSV (talk) 22:33, 29 April 2020 (UTC)
It concerns me how these discussions have been split across multiple pages.2.
Almost every time I write about this issue, here and elsewhere. You are making it difficult to AGF. Despite your forking of the discussions, we have tried to help you everywhere that you have posted and reposted your questions and comments and objections. – Jonesey95 ( talk) 05:15, 30 April 2020 (UTC)
|ref=harv
being default in the CS1/2 update or the HarvErrors.js script. And I also agree with you that those error messages should not be enabled, at least until the false positive situation is resolved. Which it may not end up being.
Headbomb {
t ·
c ·
p ·
b} 18:23, 30 April 2020 (UTC)Back then, almost all citation-class templates with no error in coding or usage (and hence not reported by Ucucha) were complaining with something like sfn error: no target..., and a pointer to a suppression method that usually didn't work.
almost all? Not true. The error message that you quote was emitted then as it is now by Module:Footnotes. The error messages were, and still are, usually not from false positives though those exist. When I enabled the error messages on 27 March 2020, the category held about 47.7k pages. With whitelisting, with editor fixes, and with the switch to auto-
|ref=harv
, the category is now at about 34.2k pages. How much reduction of the category size is due each of these three 'reducers' is not known; probably not knowable. The module is used on about 144k pages so clearly not almost all.
|ref=harv
whenever I wanted to use sfn templates was also quite irritating. And I am willing to bet that a lot more templates needed that parameter back then than need |ref=none
, meaning that the amount of work needed now is less than before the change. I think we might want to discuss a better way to socialize CS1/2 changes. This isn't the first time where a change caused contention. Perhaps notifying folks through The Signpost - if I understand CS1/2 templates correctly, changes to them are implemented in periodic batches and there is a schedule of sorts of when they change - of major changes to CS1/2 will prevent complaints about breaking changes. Jo-Jo Eumerus ( talk) 14:57, 1 May 2020 (UTC)
|ref=none
for articles to be functional to readers, that sort of goes without saying that it's a lot less work. Also the Signpost editors don't like these tutorial articles, so don't bother writing them because you'll be wasting your time, because they'll even try to delete things in your userspace if you try to write something for them that they don't like.
Headbomb {
t ·
c ·
p ·
b} 15:15, 1 May 2020 (UTC)
Headbomb continues to remove ref=harv. [1] Pinging RexxS because I don't know what else to do at this point. SarahSV (talk) 21:44, 7 May 2020 (UTC)
When, and why, did |episode=
in {{
Cite episode}} become unsupported? It seems counter-intuitive. --
Michael Bednarek (
talk) 02:31, 19 April 2020 (UTC)
|number=
. When and why was that removed? Was there any attempt to bot-replace it? Now
we see |episode=
removed without replacement, a clear disimprovement. --
Michael Bednarek (
talk) 02:26, 20 April 2020 (UTC)
|episode=
was reintroduced to {{
cite episode}}
, you should be able to find its reintroduction and then removal in the template's history somewhere. I was not able to find a reintroduction and removal; I only found the initial removal that I linked above.|episode=
should be made part of {{cite episode}}
. Since then I have done nothing with that parameter in the module suite.|episode=
was globally supported in that whitelist
until 18 April 2020. Reading the module code, it seems the parameter is supported at {{
Cite serial}}, so why not at {{
Cite episode}}? --
Michael Bednarek (
talk) 11:31, 25 April 2020 (UTC)
{{
cite episode}}
and {{
cite serial}}
from their {{
citation/core}}
implementations to their
Module:Citation/CS1 implementations within minutes of each other. Because |episode=
was required for {{cite serial}}
, that parameter is whitelisted. The migrations were intended to be transparent to readers and editors. The new Module:Citation/CS1 implementation of {{cite episode}}
reproduced the {{citation/core}}
implementation of {{cite episode}}
as it existed on the day of the migration. The old implementation did not support |episode=
.|episode=
was replaced with |title=
in 2006; I wasn't here then. The editor who made that change hasn't contributed to en.wiki since April 2019 but you could try asking via email.|lang=zh-tw
displays "Taiwanese Mandarin" and not "Chinese"
zh-tw
makes no sense. It outputs "Chinese" for zh-tw
, zh-cn
, etc. ISO really dropped the ball for zh
. Languages as diverse as
Cantonese,
Beijing dialect, and
Wu Chinese can be, and often are, all called "Chinese" even though they are not at all mutually intelligible in speech, especially traditional forms. (
Nota bene:
Varieties of Chinese.)|lang=zh-cn
"Chinese" either, but rather "Mandarin Chinese". Only plain |lang=zh
should be "Chinese", and its use should be treated as an error, in my opinion, and we should consider raising one, maybe only putting it in an error category. Perhaps,
Category:Articles with CS1 sources in unspecified language in Chinese language family.Psiĥedelisto ( talk • contribs) please always ping! 01:30, 19 July 2020 (UTC)
cmn
, wuu
and yue
, respectively. Several other languages in the massive tent of written Chinese have separate codes as well, as is demonstratable by following links from
Varieties of Chinese and looking at the articles' infoboxes. That doesn't solve this problem entirely, but it's incorrect to say that zh
is the only available code.
Glades12 (
talk) 19:12, 19 July 2020 (UTC)
|lang=cmn
, though. It does understand |lang=yue
(outputting Cantonese) and |lang=wuu
(outputting Wu Chinese). I guess why I say ISO dropped the ball is that I don't think |lang=zh
should exist—no other broad language families have such codes, and it causes a lot of lazy mislabeling under the broad identifier rather than the narrow. What do you think about my idea to add a hidden error category? Now that you've taught me about |lang=cmn
, I suppose we need that really: |lang=cmn-TW
(
Taiwanese Mandarin), |lang=cmn-CN
(
Standard Chinese, or should it be
Beijing dialect?), etc.
Psiĥedelisto (
talk •
contribs) please always
ping! 19:21, 19 July 2020 (UTC)
zh
. Also, no idea why the software doesn't recognise
cmn
; it's as valid a code as the others we've mentioned here.
Glades12 (
talk) 07:36, 20 July 2020 (UTC)
|lang=zh
and the short name "Chinese" are quite appropriate. Codes like cmn, yue, wuu, etc would be relevant if we were citing recordings.
Kanguole 08:32, 20 July 2020 (UTC)
zh
an error category is fine with me, though, I see your point.
Cantonese, also, is often not fully mutually intelligible even in writing, and Cantonese-only characters exist. A Western reader might also confuse
Chữ Nôm for Chinese, when they are also not mutually intelligible. So, these codes do serve a purpose for written texts. I'm not familiar enough with Wu Chinese to comment on it.
Psiĥedelisto (
talk •
contribs) please always
ping! 20:36, 20 July 2020 (UTC)
|lang=vi-Hani
.
Kanguole 21:06, 20 July 2020 (UTC)
cmn
in most places we're using zh
now.
Psiĥedelisto (
talk •
contribs) please always
ping! 02:10, 21 July 2020 (UTC)
zh-tw
to "Taiwanese Mandarin", adding cmn
and putting zh
into a tracking category, but since most Western readers won't be able to determine something more specific than zh
when some text is advertised in the real world just as "Chinese" (which is often the case), it shouldn't be an error category as this would keep people from adding the information at all, and it is useful for formating purposes even while unspecific. --
Matthiaspaul (
talk) 17:59, 20 July 2020 (UTC)Wikitext | {{cite book
|
---|---|
Live | Fiennes, Celia (1888). Through England on a Side Saddle in the Time of William and Mary. London: Leadenhall Press. {{
cite book}} : Check |author-link= value (
help)
|
Sandbox | Fiennes, Celia (1888). Through England on a Side Saddle in the Time of William and Mary. London: Leadenhall Press. {{
cite book}} : Check |author-link= value (
help)
|
fixed in the sandbox;
— Trappist the monk ( talk) 12:53, 22 July 2020 (UTC)
In the Usage section is a table of parameters with some having prerequisites. It notes that the others parameter has a prerequisite of title, but it fails to note that the others parameter also has a prerequisite of last or author. I would fix it myself but I can't figure out where this is stored. — Anomalocaris ( talk) 07:12, 22 July 2020 (UTC)
|others=
doesn't have that prerequisite, and shouldn't anyway, because some sources (such as signs and very short magazine articles) only credit certain roles such as illustrators or editors. In cases like those, the templates should absolutely not force editors to choose between guessing who wrote the material and not including any names at all.
Glades12 (
talk) 11:09, 22 July 2020 (UTC)
|title-link=
prerequisite at {{
cite AV media notes}}
was misplaced; fixed now.|title=
, |chapter=
, |article=
, or |booktitle=
, etc. while also specifying a URL for that element.|others=
without also using |author=
or |editor=
or any of their aliases. |others=
is provided to record other (secondary) contributors to the cited source. Articles are listed in this category when
Module:Citation/CS1 identifies a template that does not identify primary contributors....|title-link=
with its prerequisite |title=
because, as it was, it was so obviously wrong and because, at the time, I had other stuff on my mind. The incorrect alignment has been in place since I made
this edit – I guess it wasn't so obvious at the time... Unless someone beats me to it, I'll add |lastn=
, |authorn=
, |editor-lastn=
, and |editorn=
as prerequisites for |author=
(probably tomorrow).We need a way to handle page numbers in computer files and eBooks that are not absolute page numbers. Google has their own way of identifying such pages, and we should decide how we want to handle it in the general case, Google or otherwise. I'm hoping for a discussion to see, in the first instance, whether there's interest in establishing a conventional method of doing this (achievable via /doc changes alone), or if something more robust is required.
Checked the archives, and didn't see anything about this; please add a link if I missed something. More and more, books are being "printed" online only, and exist purely as digital files. Or as both, but the accessible one is digital. Especially in the former case, there may not be an absolute "page number", depending on the format (i.e., not pdf or other fixed format) and on the rendering engine. In particular, Google will render these without visible page numbers in their page view mode. They do have an identifier they use in their url to distinguish the two cases. As near as I can determine from generalizing from a few dozen examples, the url param |pg=
is used for both cases, but the value differs depending on the source; for example: |pg=PA35
for printed, absolute page number visible in printed version, and |pg=PT35
for a page number on a digital resource. Note that in book search results, the Google result snippet will be slightly different: the boxed contextual snippet will say found inside – page 35 in the latter case, and found inside in the former.
For starters, I think this could be a doc-only change, by way of some additional text at the section on page, recommending what to do in this case, without any need for software changes. For example, something like:
For computer files where no fixed page number is present, code the page number a
|page=X99
, where the 'X' prefix is replaced by an identifier ('G' for Google books, 'I' for internet archive, ...) and the '99' represents the page identifier given by that display provider. The following table provides the identifiers for some common eBook providers: <table>...
That's just a first cut, and I'm sure I failed to consider lots of things. But the point is, I think we can initiate something useful without a software change, which would be a lot easier to get going, n'est-ce pas?
An example of using a conventional approach, as proposed
|
---|
By June, the different branches of Free France, led by de Gaulle out of London, and by Giraud out of Algeria, merged into one, creating the French Committee of National Liberation.<ref name="Davis-2018">{{cite book |lang=en |last=Brunet |first=Luc-Andre |editor-last1=Davis |editor-first1=Muriam Haleh |editor-last2=Serres |editor-first2=Thomas |title=North Africa and the Making of Europe: Governance, Institutions and Culture |chapter=1. The Role of Algeria in Debates over Post-War Europe within the French Resistance |url=https://books.google.com/books?id=tP5DDwAAQBAJ&pg=PT35 |accessdate=23 July 2020 |date=22 February 2018 |publisher=Bloomsbury |isbn=978-1-350-02184-6 |oclc=1037916970 |type=computer file |page=G35–36}}</ref> |
Going forward, maybe we do want more control of this, so maybe there's a new param to explain who the rendering engine is:(e.g., |epager=Google
, |epager=Internet Archive
, etc.). You would think that the value of the |url=
field would be enough to imply the latter, but in the real world, the multiplicity of CS1 params not infrequently don't all remain in sync, so I wouldn't trust that method; you'd end up with page numbers corresponding to some mystery provider. That might even be a reason to keep the original suggestion (i.e., use |pg=G35
for Google efile) because the page number and the method are kept together in one param value. Your thoughts appreciated.
Mathglot (
talk) 01:10, 24 July 2020 (UTC)
|chapter-url=
and its aliases. Other than that, I don't think any special system is warranted. In scanned works, what is actually cited is the scan image, not its source. Different considerations apply, imo.
98.0.246.242 (
talk) 01:37, 25 July 2020 (UTC)The other day, I noticed that we don't have |subject-mask=
or any of its enumerated forms. I have added |subject-mask=
, |subjectn-mask=
, and |subject-maskn=
{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask=2}}
{{cite interview/new |title=Title |subject=Abraham Lincoln |subject1-mask=2}}
{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask1=2}}
The |subject=
and |interviewer=
arrays of parameters are used primarily in {{
cite interview}}
. Because we don't have non-hyphenated forms of the |interviewer=
parameters and because the preferred form for parameter names is hyphenated, I have deprecated |subjectlink=
, |subjectlinkn=
, and |subjectnlink=
. Here are some simple searches that indicate usage of these parameters:
|subjectlink=
:
~860 hits|subjectlinkn=
:
~110 hits|subjectnlink=
:
times out
{{
cite interview}}
:
|subjectnlink=
0 hits— Trappist the monk ( talk) 22:48, 26 July 2020 (UTC)
Wikitext | {{cite journal
|
---|---|
Live | Barry, R. G. (1978). "H.-B. de Saussure: The First Mountain Meteorologist". Bulletin of the American Meteorological Society. 59 (6): 702–705. Bibcode: 1978BAMS...59..702B. doi: 10.1175/1520-0477(1978)059<0702:hbdstf>2.0.co;2. ISSN 0003-0007. |
Sandbox | Barry, R. G. (1978). "H.-B. de Saussure: The First Mountain Meteorologist". Bulletin of the American Meteorological Society. 59 (6): 702–705. Bibcode: 1978BAMS...59..702B. doi: 10.1175/1520-0477(1978)059<0702:hbdstf>2.0.co;2. ISSN 0003-0007. |
Fixed in the sandbox.
— Trappist the monk ( talk) 16:19, 29 July 2020 (UTC)
{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-style = vanc | title= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | contribution= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}
Gives
{{
cite journal}}
: |contribution=
ignored (
help)It should give something better, like
Or maybe
Headbomb { t · c · p · b} 18:31, 27 July 2020 (UTC)
|department=
:
{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-style = vanc | department= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | title= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}
I'm trying to cite a newspaper source, for which the paper (or its website) doesn't exist anymore, but copies of the relevant article are embedded in a council ordinance. Can I do that, and if so, what would be the syntax?
The full ordinance is
here, and I would like to reference page 106: "Success or failure?", Sean Robinson, The News Tribune.
Frescard (
talk) 14:23, 29 July 2020 (UTC)
|via=
), but if you think it is helpful, you can instead cite both in one <ref> statement; something like {{cite news |newspaper=The News Tribune |first=Sean |last=Robinson |title=Success or failure? Probing Prometa}} as in {{cite web |url=https://online.co.pierce.wa.us/cfapps/council/model/otDocDownload.cfm?id=1448900&fileName=2007-81s%20final%20Ord%20file%201.pdf |department=Today in the Trib |website=Pierce County, Washington |title=Ordinance No. 2007-81s: etc. |p=106}}
: Robinson, Sean. "Success or failure? Probing Prometa". The News Tribune. as in
"Ordinance No. 2007-81s: etc" (PDF). Today in the Trib. Pierce County, Washington. p. 106. --
Izno (
talk) 02:18, 31 July 2020 (UTC)
|via=
is I believe problematic: the source that includes the article is not an archive, repository, or other publisher. The article is included as supporting (incidental) documentation, as the OP described it, a source from a 3rd party. Tertiary sources should be referenced as such.
98.0.246.242 (
talk) 02:16, 1 August 2020 (UTC)
|via=
is justified. But even that case does not apply here. The relevant text is a fragment of the containing source. It should be cited as such.
65.88.88.57 (
talk) 14:16, 2 August 2020 (UTC)What is the standard, if any, for citing a newspaper article that is available online, that is split onto two webpages. This occurs a lot with Newspaper.com sources. Generally speaking, the article is one source, with one title, author, date, etc. However, to assist with verifiability and to be able to archive each page of the article, I have been splitting it into two separate references, adding "Part 1" and "Part 2" to the title. See an example below:
This allows me to cite each sentence in an article with the relevant page of the news article. But it does create some confusion and adds additional sources in the reference list. Is there a better way to do this? Does (or could) {{ Cite news}} support two urls and two archive-urls? Thanks for any insight. « Gonzo fan2007 (talk) @ 15:39, 3 August 2020 (UTC)
|type=clipping
is helpful because Newspapers.com will allow readers without an account to see the full page from which the clipping is drawn.
Imzadi 1979
→ 20:56, 3 August 2020 (UTC)Is there a different validation for |publication-date=
as it is reporting an error which does not happen if it is |date=
?
Rik Farrow (2018). Rik Farrow (ed.).
"Musings" (PDF). ;login. 43 (4).
USENIX (published Winter 2018): 4.
ISSN
1044-6397. {{
cite journal}}
: Check date values in: |publication-date=
(
help)</ref>
Keith D ( talk) 21:17, 17 July 2020 (UTC)
|date=
.|publication-date=
as well, I guess. --
Matthiaspaul (
talk) 11:20, 18 July 2020 (UTC)
|publication-date=
an alias of |date=
and deprecate the long alias or remove it from the docs; we do not need to "advertise" every alias that has ever existed. —
SMcCandlish
☏
¢ 😼 13:04, 4 August 2020 (UTC)How should editors use the |website= parameter? I'm talking about this edit and similar ones. The examples at Template:Cite web#Examples use the website name (in this case, Parties and Elections in Europe), but the automatic citation-creating tool uses the url of the website (in this case, www.parties-and-elections.eu). However, I also tried to use the auto-citation tool with a Wikipedia article as the url to test, and it put Wikipedia in the website parameter. Is this a mistake in the auto-citation tool? Thanks, Ezhao02 ( talk) 15:37, 27 July 2020 (UTC)
both www.parties-and-elections.eu and Parties and Elections in Europe should be listedNo, do pick one or the other. Our guidance at Help:CS1#Work and publisher is currently the following:
Does that help you decide? -- Izno ( talk) 16:02, 27 July 2020 (UTC)On websites, in most cases "work" is the name of the website (as usually given in the logo/banner area of the site, and/or appearing in the <title> of the homepage, which may appear as the page title in your browser tab, depending on browser). Do not append ".com" or the like if the site's actual title does not include it (thus |work= Salon, not Salon.com). If no clear title can be identified, or the title explicitly is the domain name, then use the site's domain name. Do not falsify the work's name by adding descriptive verbiage like "Website of [Publisher]" or "[Publisher]'s Homepage". Capitalize for reading clarity, and omit "www.", e.g. convert "www.veterinaryresourcesuk.com" to "VeterinaryResourcesUK.com".
Hello, can you please add some error-check code and emit a big, red error message, if an editor codes a "link" param (author, title, translator, editor, contributor are the ones I'm aware of) to a sister wikipedia like fr-wiki without a leading colon on the lang code? What happens in this case, is various kinds of strange behavior, including dropping the field (author, say) and emitting only a semicolon or other punctuation; but worse is that the first of these, whatever it is, is picked up as an interwiki, and the entire article is linked under that language name in the left sidebar. Same thing occurs for fields with permissible wiki-linking, such as publisher. Beyond that, it screws up article links at Wikidata, as soon as their bot sees it.
You can see an example of the faulty behavior in revision 969921029 of André Diethelm. Go to the language links in the left sidebar, and notice that the Hebrew and Arabic links point to the correct articles (Google translate does a sufficient job of transliterating the titles to confirm they are correct if you need it) but the French one is wrong, and links to fr:Éditions Philippe Rey. This happens to be the publisher of one of the sources listed in the #Further reading section, namely "Lambert (2010)", but you won't see it on the rendered page, because it's been snatched by the wikimedia code and interpreted as the target of the "Francais" link in the language sidebar; all you will see in the Lambert citaton is extra punctuation between "Paris" and the ISBN. To actually see the linked publisher with the missing colon, you have to view the wikicode of that revision.
You can diff that version with current ( diff), to see that the only change was to add one colon in the Lambert publisher field. Notice that the Francais link in the sidebar is now correct. (Same thing happens if you forget the leading colon in authorlink, or any of the other *-link fields.) These should be flagged as errors, because they will escape the notice of many users. Also, the bots at Wikidata are rapid, and although I noticed and fixed the problem within minutes, I was too late, and the Wikidata bot had already linked my French Resistance guy at en:André Diethelm to the French publisher fr:Éditions Philippe Rey via item d:Q3579477 ("Éditions Philippe Rey"; diff). I had to both unlink that connection, then go relink Diethelm to d:Q2847654 instead (same one that has the Hebrew and Arabic articles as well).
This is too much to ask most users to do. A big, fat, red error for interwiki links that lack a leading colon would be a big help. Thanks, Mathglot ( talk) 06:04, 28 July 2020 (UTC)
|publisher=[[fr:éditions Philippe Rey|Philippe Rey]]
is not a |<param-link>=
problem; somewhat related, but not the same.|<param-link>=
where the assigned value begins with a known local inter-wiki prefix without a leading colon. There are a couple of exceptions. The w:
and wikipedia:
prefixes do not require leading colon. The s:
and wikisource:
prefixes have special meaning because cs1|2 creates urls from these inter-wiki links so that it can add the wikisource icon. From the example template, tweaked so that the author wikilink is missing the leading colon:
|publisher=
inter-wiki link problem must be handled differently because for the most part, any cs1|2 parameter may be wiki-linked (despite documentation to the contrary). For all parameters in a cs1|2 template that are not |<param-link>=
parameters, inter-wiki links must begin with [[<prefix>:
where <prefix>
is a known local inter-wiki prefix, s:
, w:
and their long-forms again excepted. As each parameter name is validated, the cs1|2 sandbox looks for this pattern and emits and error message when detected:
wikipedia:
in the exclusion list because it is listed at
Help:Interwiki linking as the long form of w:
. But, now that you point it out, wikipedia:
the prefix makes no sense because it conflicts with wikipedia:
the namespace. No doubt the exclusion list might include
b:
(wikibooks),
c:
(commons),
d:
(wikidata),
m:
(meta),
n:
(wikinews),
q:
(wikiquote),
v:
(wikiversity).wikipedia:
does not conflict on other wikis as a thought. --
Izno (
talk) 22:55, 4 August 2020 (UTC)
[[wikipedia:]]
on
meta: links to the en.wiki main page. As a guess, I would say that wikipedia:
, the name space, is common on encyclopedia wikis but not on other types of wiki.[[
w:]]
appears to be a prefix that always links to en.wiki, I'm wondering if that prefix should continue to be excluded from the error check. Here at en.wiki, the w:
prefix gets you to the article in the same way that the en:
prefix or no prefix does:
[[
w:Abraham Lincoln]]
[[
en:Abraham Lincoln]]
[[
Abraham Lincoln]]
w:
prefix links to the en.wiki article but isn't otherwise treated as a inter-language inter-wiki link.
v:
earlier.mw.site.interwikiMap ('local')
. I am minded to change that and instead use the list of languages returned by mw.language.fetchLanguageNames ('<local wiki lang code>', 'all')
if I can show that all of the language codes in that list are also found in the inter-wiki map list.mw.site.interwikiMap ('local')
and mw.language.fetchLanguageNames ('<local wiki lang code>', 'all')
. Prefixes in mw.site.interwikiMap ('local')
must match a language code in mw.language.fetchLanguageNames ('<local wiki lang code>', 'all')
to be added to the local list. There are seven 'language-like' codes in mw.site.interwikiMap ('local')
that 'redirect' to another-language wiki but these codes do not contribute to the inter-wiki language list:
cmn:
→ Mandarin Chinese (ISO 639-3 code); redirects to zh.wikipedia.org
cz:
→ Czech (ISO 3166 country code); redirects to cs.wikipedia.org
dk:
→ Danish (ISO 3166 country code); redirects to da.wikipedia.org
epo:
→ Esperanto (ISO 639-3 code); redirects to eo.wikipedia.org
jp:
→ Japanese (ISO 3166 country code); redirects to ja.wikipedia.org
minnan:
→ invalid IETF language tag; redirects to zh-min-nan.wikipedia.org
zh-cfr:
→ invalid IETF language tag; redirects to zh-min-nan.wikipedia.orgno
(Norwegian, in general) or nn
(Nynorsk), I can't remember —is odd man out, wrt to a giant list of WP codes that generally match the ccTLD codes, except for that one case. (There's also Bokmal, nb
, but it wasn't that.) This could be a red herring, but just wanted to recall it, in case it's relevant here.
Mathglot (
talk) 03:40, 6 August 2020 (UTC)
[[
nn:]]
links to the Norsk nynorsk nn.wiki, both of [[
nb:]]
and [[
no:]]
link to the Norsk bokmål nb.wiki. I do remember that for a time, language code no
was not supported by the {{#language:}}
magic word. That has since been fixed:
{{#language:nb|en}}
→ Norwegian Bokmål{{#language:nn|en}}
→ Norwegian Nynorsk{{#language:no|en}}
→ Norwegian|langcode=
and |googlelangcode=
, not found in any other Expand language template (such as
Template:Expand Norwegian). The explanation at
this /doc page references Nynorsk. So, red herring, as far as we are concerned here.
Mathglot (
talk) 04:28, 7 August 2020 (UTC)Also, while I'm thinking of it: despite the emission of a CS1 error in preview mode, the editor can still override and save anyway, as shown in your sandbox example above. This is fine, for the *-link case, but not so great for the publisher=[[fr:Seuil]] case, because if that link is saved like that, the Wikidata bot will likely do something strange. I don't know if this is beyond the scope of this template, but, for example, could you stop the user from saving it in that form, either by stripping out the brackets, or supplying the preceding colon? If not, maybe in that case we'd need to see about an edit filter to trap it, but I suppose that would be a discussion for somewhere else. Mathglot ( talk) 09:50, 5 August 2020 (UTC)
|<param-link>=
parameters that fail the various link tests (has a url, has wikilink markup, has inter-wiki prefix without leading colon) the code simply unsets the parameter and declares the error:
{{Cite book/new |title=Title |title-link=//example.com}}
→ Title. {{
cite book}}
: Check |title-link=
value (
help); External link in |title-link=
(
help){{Cite book/new |title=Title |title-link=[[Title]]}}
→ Title. {{
cite book}}
: Check |title-link=
value (
help){{Cite book/new |title=Title |title-link=nv:Title}}
→ Title. {{
cite book}}
: Check |title-link=
value (
help)|<param>=[[<prefix>:<value>
the code extracts the label portion of the wikilink:
Hi, I guess most of us do not remember all parameters supported by the various citation templates, in particular those which are not generic, but specific to certain templates.
In order to make it easier (quicker) to look up the template specific help page, I propose to let the template display an unobtrusive link to its help page (only) in article preview, either in front of the citation or after it.
This could look like [1]
{{ Cite journal}} would have a link to Help:Cite journal, {{ Cite conference}} to Help:Cite conference, {{ Cite book}} to Help:Cite book etc.
If even this small [?] would be found to be too obtrusive, it could be put into some CSS stuff so that it would show only when an editor has opted in to maintenance messages.
-- Matthiaspaul ( talk) 11:01, 13 July 2020 (UTC)
As a preview/opt-in message. Headbomb { t · c · p · b} 12:42, 13 July 2020 (UTC)
{{REVISIONID}}
magic word for every citation whether there were errors or not. That implementation drew the attention of MediaWiki because it took longer to save pages. This because preview-pages are different from saved pages so MediaWiki can't reuse the preview and must parse the wikitext again before it can be saved. See
Help talk:Citation Style 1/Archive 20 § archive url checks and preview mode and the related discussion at
Wikipedia:Village pump (technical)/Archive 147 § Preview-only template warnings using REVISIONID magic word.(X-posting from the Tech Pump) Wikiquote's ref template will parse "July 2 1999" just fine, but our template requires a comma, e.g. "July 2, 1999". Why is that? Can someone fix our template to stop caring so much? I screw this up on my first pass something like 25% of the time. -- Kendrick7 talk 00:30, 7 August 2020 (UTC)
Right now, Category:CS1 maint: display-authors and other friends are nearly always empty because they are nearly always an easy-to-correct error. I would like to propose upgrading them to errors accordingly, which will make them more visible to editors.
To make this easier to do in the future with maintenance messages we decide should be errors, I'd also like to see the error and maintenance system implementations be made the same (save for the obvious distinction). For this latter, I trip up really hard every time I want to get maintenance items turned into errors, and it's making it hard to parse how to make the necessary code modification for display-X.
Any concerns? -- Izno ( talk) 12:45, 4 July 2020 (UTC)
message
, anchor
, category
, hidden
. For maint cats, we might define these:
message
always nil
or empty stringanchor
a unique value used to link into
Help:CS1 errors help textcategory
the key that tells common set_error()
how to handle the issue; maint cat names all begin with 'CS1 maint:' whereas error message cats aren't so consistenthidden
ignored for maint cats which are always hiddenz.error_categories
. Property and maint cats have their own tables (maintenance_cats
and properties_cats
). Maint cats can display their names as an editor-option via css, prop cats display nothing.category
to the correct error cat; add the appropriate error message in message
, and set hidden
to the appropriate boolean.|date=
twice. --
Matthiaspaul (
talk) 07:58, 7 July 2020 (UTC)
set_error()
→ set_message()
and been modified so that it will emit maintenance category 'messages' when the message
property for that message is nil
. Maint messaging is now part of the error_conditions{}
table in
Module:Citation/CS1/Configuration/sandbox; TODO: rename that table.I worked my originating request as a result of this rework, which moves display_names messaging (inconsistently error and maintenance) to strictly errors. Main, /Configuration and testcases2. Perhaps of note that this changes the error for the "don't know" case from invalid_param_values to disp_name; I made that change to centralize all the disp_name errors fixing. There may be further work that should be done so the other use of that error can be more definite. -- Izno ( talk) 22:50, 8 August 2020 (UTC)
One other thing: I am not personally convinced that we need 5 categories to handle display_names issues. I think 1 would suffice. Seeking feedback on that point. -- Izno ( talk) 22:52, 8 August 2020 (UTC)
"Template:Cite Book" needs terms for all of the MARC 21 fields, especially total pages, size, etc. 71.230.16.111 ( talk) 06:47, 24 July 2020 (UTC)
|size=quarto
". Yeesh.
Wikipedia is not anything like
WorldCat. —
SMcCandlish
☏
¢ 😼 13:00, 4 August 2020 (UTC)I'm sure the way in which access is indicated in citations has been discussed extensively by the regulars here, and I apologize for my ignorance of your past discussions. Is there a field to indicate that a book is public-domain (in this case, a 2018 work of US government) and the fulltext is freely available online? This will make it obvious that it is easy to verify the cited statement, and increase the likelihood of editors and readers actually doing it. I understand that such access parameters are already common on journal article templates.
An additional winkle here: many medical journal articles are currently freely accessible due to a special action taken by publishers for the COVID-19 pandemic. At some future date to be decided upon by the publishers, they will put the articles back behind paywalls. Public licenses are permanent, but free access may be revoked. I'm not sure how widespread this is, but we might end up with a lot of incorrect information on access. HLHJ ( talk) 17:29, 8 August 2020 (UTC)
I have a question about a book that is divided into several individual sections with their own authors. ¿How should I cite that book? In my case I am only interested in one section of that book. -- Muwatallis II ( talk) 23:11, 8 August 2020 (UTC)
{{
cite book}}
: |author=
has generic name (
help) is the basic skeleton. If you have some more information we can fill out the rest for you. --
Izno (
talk) 23:12, 8 August 2020 (UTC)The book is called: Escuadra Nacional 1818-2018 (no author, only publisher)
The title of the chapter or section of the book already mentioned is: De la Guerra del Pacífico hasta fines del siglo XIX. The author is: Piero Castagneto Garviso. This author is just from the chapter or section of the book.
As I mentioned before, the book has other chapters or sections with their own authors, but I'm only interested in the one already mentioned. -- Muwatallis II ( talk) 00:04, 9 August 2020 (UTC)
|url=http://anyflip.com/yccc/bhap
:
When the source being cited is a chapter in an edited book or an article in a journal, the language of the source (specified with |language=
) should be notated after the chapter or article, rather than after the book or journal, which may include items in several languages. For example, currently we have:
{{
cite book}}
: |author=
has generic name (
help){{
cite book}}
: |editor=
has generic name (
help)The first is fine, but in the last two "(in German)" should be moved forward, after the chapter or article. Kanguole 11:50, 9 August 2020 (UTC)
In the following example, the "(PDF)" format designation comes after the translated title, which looks odd because the PDF symbol is displayed after the foreign language title:
There are several potential ways to solve this:
Ideas? -- Matthiaspaul ( talk) 14:28, 20 June 2020 (UTC)
|script-*=
and |trans-*=
parameter variants for them. I've changed it to |magazine=
, though - they describe themselves as a magazine rather than as a journal. |work=
is too unspecific. I use |work=
only when none of the more descriptive parameters applies (typically with {{
cite web}} or {{
cite book}}, rarely with {{
cite journal}} or {{
cite magazine}}). --
Matthiaspaul (
talk) 10:22, 13 July 2020 (UTC)|format=
is used to specify something different, it would be displayed as before, but then the icon and the text would not be redundant and therefore look much less out of place than now. --
Matthiaspaul (
talk) 18:12, 20 July 2020 (UTC)
the PDF icon and a "(PDF)" text is redundant. The pdf icon is rendered by MediaWiki as a css
background-image
property (
MediaWiki:Common.css). Because it is not rendered from an html <img>...</img>
tag, it does not support the alt=
attribute. In cs1|2, the automatic |format=PDF
is a way to notify screen-reader-users that the source is a pdf file. That functionality should not be degraded.alt=
text).There's a few links I've seen in references to old webpages with valid archive URLs of what the site looked like in 1997, but there's malware-downloading squatters at the URL now. Is there a way to suspend a link to the site in this template? Or should the URL just be replaced directly with the archive link in such cases? SnowFire ( talk) 05:53, 10 August 2020 (UTC)
|url-status=unfit
to the citation, the original URL will not be linked. Read more at
Template:Cite web/doc. --
John of Reading (
talk) 06:07, 10 August 2020 (UTC)This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 65 | ← | Archive 67 | Archive 68 | Archive 69 | Archive 70 | Archive 71 | → | Archive 75 |
This section in a nutshell: Effective
April 2020,
CS1 templates (e.g. {{
cite book}}, {{
cite journal}}, and the other {{cite ...}} templates) behave like
CS2 templates (e.g. {{
citation}}) with respects to the generation of harvard-style anchors (see
discussion). This means that adding |ref=harv to "long" CS1 citations is no longer required to use "short" citation templates like {{
harvnb}}, {{
sfn}}, and other {{
harv}}-like footnotes.
If you see more yellow warnings like
than usual, those are caused by User:Ucucha/HarvErrors.js. To suppress/reduce these yellow warnings, you can use any of the following options
If there still are errors after this, see how to deal with harvard-style citation issues. The documentation might be a bit out of date, but every piece of advice listed for CS2 (e.g. {{ citation}}) now applies to CS1 (e.g. {{ cite book}}) as well. If none of those options satisfy you, you can make a new script request at WP:SCRIPTREQ. |
Cite book has started giving a harv error message even when ref=harv has not been added. E.g.
It only did this before with the citation template. Many articles use this template without ref=harv, and they are all suddenly giving error messages, which is ugly and distracting. If it carries on I will have to turn off the harv warnings, but then I will not be warned when I am using ref=harv and I make a mistake. What is the position? Dudley Miles ( talk) 21:54, 18 April 2020 (UTC)
window.checkLinksToCitations = false;
Sorry I'm late, I posted the following at Template talk:Citation, and I appreciate much of this has been said and argued over already:
"This week, for the first time ever that I know of, ordinary {{cite web| ... and {{cite new| ... and probably other such templates are suddenly displaying warnings like
This type of message used to occur, helpfully, only when there was an explicit Harvard parameter indicating that links were expected: ... |ref=harv }]
That was useful as one normally only put the harv indicator in when the plan was to insert inline citations in the text, and missing one was obviously a problem.
Now, however, the error occurs WITHOUT the ref=harv parameter! This makes no sense: it causes an error if any citation is listed in a bibliography or further reading, and worse, if citations are listed inside an inline ref tag --- it seems to happen from the third citation onwards --- there is a fine specimen at K. Pattabhi Jois, and there is no visible means of suppressing the errors.
This makes checking for ACTUAL errors much more difficult, as false positive "errors" are displayed all over. Would be glad if the status quo could be resumed, please." Chiswick Chap ( talk) 12:18, 21 April 2020 (UTC)
third citation onwardsyou are referring to this group of references, the first two of that group do not have contributor, author, or editor names. An anchor ID is the concatenation of
CITEREF
, up to four contributor/author/editor names and a date. When there are no names, no anchor ID (this is not new).{{
harv}}
or {{
sfn}}
families of templates.Sorry to join in with this late. Looking at this from a different angle, automatically adding harv anchors to every cite template not immediately proceeded by a <ref> tag is adding unnecessary html to the page when parsed. Whilst this isn't a problem with only a few instances on the page, on certain pages with maybe 50 "Further reading" links, this will add a significant overhead to the html (which could be problematic on older mobiles). When the page is parsed to html, the harv anchors become html anchors with an id equal to the CITEREF anchor. In html, id's must be unique. When we had to add anchors manually, where we cite the same author with several publications in the same year we differentiate the anchors eg Smith 1990a; Smith 1990b; Smith 1990c; etc. Automatically adding the anchors, would in the above case give 3 anchors with an id of "Smith 1990", causing non-compliant html. This probably isn't a problem most of the time, but the worst case scenario would be the browser going into "quirks mode", stop rendering the page and then redraw the page once the html, css, javascript etc has finished downloading. Again, this is more likely to happen on mobiles. As 40 - 70% (dependent on who's figures you look at) of internet access is from mobiles, then how the site behaves on mobiles needs to be considered. Putting aside "errors" being shown up by scripts, we should be adding |ref=none to unused anchors to prevent html problems. -- John B123 ( talk) 16:05, 15 June 2020 (UTC)
automatically adding harv anchors to every cite template not immediately proceeded by a <ref> tag is adding unnecessary html to the page when parsed
<ref>...</ref>
tags and many of which are the targets of the short-form citations. In fact, I suspect that the opposite is true; in most cases, cs1|2 templates wrapped in <ref>...</ref>
tags don't need anchor IDs because generally, nothing links to them except the superscript added by cite.php
during conversion from wiki-text to html.where we cite the same author with several publications in the same year we differentiate the anchors eg Smith 1990a; Smith 1990b; Smith 1990c; etc. Automatically adding the anchors, would in the above case give 3 anchors with an id of "Smith 1990"
|date=
in the cs1|2 templates as should be done when citing three 1990 vintage Smith sources. The lazy en.wiki editor should have written {{cite ... |last=Smith |... |date=1990a |...}}
, {{cite ... |last=Smith |... |date=1990b |...}}
, {{cite ... |last=Smith |... |date=1990c |...}}
. If the article is using short-form citation templates to link to the long-form cs1|2 citations,
Module:Footnotes detects cs1|2 templates with identical anchor IDs and, when there is a short-form citation that uses that anchor ID, emits an error message. These error messages are hidden; see
:Category:Harv and Sfn template errors § Displaying error messages to learn how they may be displayed for you.|ref=none
. There has been some discussion about creating a cs1|2 configuration template that would be read when the wiki-text is converted to html that might be used to disable all cs1|2 anchor IDs except those specifically created (|ref=
has a value other than none
). As far as I know, no one is clambering for such a template.<ref>...</ref>
tags don't need anchor IDs because generally, nothing links to them - My point in mentioning the <ref>...</ref>
in my previous post was exactly that, the issue generally occurs outside the references section: Bibliography, Further reading etc. (On a side note, where multiple cite templates are bundled within single <ref>...</ref>
, anchors are added for the second and subsequent cites.)|date=
in the cs1|2 templates I'm not sure if it's laziness. Judging by the number of sfn and harv errors I've put right, I think it's lack of understanding rather than laziness. I doubt it would enter the mind of the average user to disambiguate dates when adding a list of articles to a "Further reading" section with nothing linking to them. --
John B123 (
talk) 19:25, 15 June 2020 (UTC)@ Trappist the monk:, can you point to where consensus was reached for this change?
This was the situation before the change. When writing an article, we compile a list of long citations under "Works cited" and use short citations (sfn or harvnb) throughout the text. The short links to the long. If we include a long citation but don't use it, we see a red error message. This is very useful.
What we might do at that point is move the unused reference into Further reading, and remove ref=harv. We do the same when compiling "Selected works" lists of publications. Then if we want to use the same long citation as a source again, we move it back into "Works cited" and add ref=harv; that allows us to restore an sfn citation.
That flexibility has now disappeared, it seems. Either we get ugly error messages all the time in Further reading and Selected works, or we turn them off and don't get the ones we need. SarahSV (talk) 03:00, 21 April 2020 (UTC)
These two discussions— here and here—don't amount to consensus. The second is from 2018; the first is more recent but hardly anyone commented. You need strong consensus for a change that affects so many people.
Can you explain about the broken anchors? (Your last point about equal footing means we've lost functionality/flexibility because CS1 and CS2 are now the same; that's not a benefit.) SarahSV (talk) 04:53, 21 April 2020 (UTC)
{{
harv}}
or {{
sfn}}
templates, the script is mute so reference sections are not cluttered with the warning messages. I use a different color scheme and my error messages don't shout so the look is a bit different. In
User:SlimVirgin/common.js, replace importScript('User:Ucucha/HarvErrors.js');
with importScript('User:Trappist the monk/HarvErrors.js');
.There is now no way to get rid of these error messages, because removing ref=harv no longer works.To quash the script warning messages in a Further reading section (or anywhere else), you can set
|ref=none
in the cs1|2 template. When set to this value, the cs1|2 templates will not create an anchor ID.For the broken anchors, see Help talk:Citation Style 1/Archive 46#broken anchors, I've updated the archive to reflect the old behaviour. For consensus, it's a pretty strong one. This fixes tens of thousands of broken anchors, putting CS1 and CS2 on par with each other, thus allowing for greater flexibility in the choice of CS1 and CS2 styles with an increased user-friendliness. That this reduces the usefulness of an opt-in, optional script used by about 200 active editors is not much of an argument compared to the benefits this brings to everyone else. Headbomb { t · c · p · b} 05:28, 21 April 2020 (UTC)
|ref=none
if you really don't want to see brown warning messages for those citations, but if you later want to move the citations up to Works cited, you'll need to remember to remove it. As it stands, seeing a brown warning for every entry in Further reading is a good way to confirm that those full citations are not being used in the article, as long as they are all formatted consistently.|ref=none
since it's not cited directly. The Gross 2003 citation works correctly, there's a collision, but it's not an important one.
Headbomb {
t ·
c ·
p ·
b} 06:06, 21 April 2020 (UTC)Re. "You could also ask ... at
WP:SCRIPTREQ ..." – anyhow, I posted a place-holder request there (
WP:SCRIPTREQ#HarvErrors.js), that is: inviting script-writing co-editors to come here to help determine what is feasible. I was thinking about placing an RfC at
WP:VPT to determine whether the "|ref=
harv " default is what editors generally want for cs1 cite templates, but didn't do that yet: I am still pondering whether that is a good idea (and if so: how to get it started on the right foot). --
Francis Schonken (
talk) 07:20, 21 April 2020 (UTC)
This is what I see now in "Selected works" and "Further reading" sections that use {{ cite book}}, {{ cite news}}, etc. Dudley and Gerda, have you been able to find a solution yet? SarahSV (talk) 18:28, 21 April 2020 (UTC)
|ref=none
to either {{
citation}} or {{
cite book}}, is actually easier than converting {{
citation}} to {{
cite book}}. –
Jonesey95 (
talk) 18:59, 21 April 2020 (UTC)
{{
harvnb}}
to that article and preview it, I see the appropriate error message and, because the article now has a short cite template (bogus or not), all of the warning messages. Read my reply. Try it. Report back here.namely when we use a long citation without a corresponding short one: that is not, and never has been, an error. Most Wikipedia articles are formatted with long citations that do not have short forms referring to them. Perhaps you have something more specific in mind, like "when we add a long citation to a references section that is only supposed to contain things that are referred to by short footnotes". The script you use did catch those, but caught a lot of non-errors besidea. If you want to catch these you will need a smarter script, one that is capable of distinguishing articles that use short citations for all references from articles that use them only for some or for none of the references. — David Eppstein ( talk) 19:45, 21 April 2020 (UTC)
|ref=harv
works exactly as before, and there is no degradation of anything. It simply has been made default to make templates more user friendly and to repair tens of thousands of broken anchors. However you dealt with warnings in CS2 before still apply here. There is literally no difference in how CS1 and CS2 templates behave. For the millionth time now, if you don't like how
User:Ucucha/HarvErrors.js behaves, then make a
WP:SCRIPTREQ for a new script.
Headbomb {
t ·
c ·
p ·
b} 19:34, 21 April 2020 (UTC)
long citation without a corresponding short one; the error messages apply to a short cite without a corresponding long citation.
importScript('User:Ucucha/HarvErrors.js');
importScript('User:Trappist the monk/HarvErrors.js');
The addition of ref=harv to cite book was the way linked and unlinked sources were distinguished. Now that ref=harv has been made non-functional, there is no way a script can distinguish between cases where cite book is being used with anchors or intentionally without. Dudley Miles ( talk) 20:00, 21 April 2020 (UTC)
|ref=harv
works exactly as it did before and generates a harvard anchor.
Headbomb {
t ·
c ·
p ·
b} 20:02, 21 April 2020 (UTC)|ref=none
inhibits anchor ID creation. This functionality was added several years ago specifically for {{
citation}}
so that editors didn't have to see the warning messages emitted by HarvErrors.js.Combining with Headbomb's suggestion at User talk:Citation bot/Archive_20#remove ref=harv, I see (for the time being) some possible tasks (please add more ideas worth considering if you think of any):
|ref=harv
currently throws a
maintenance category. Maybe it shouldn't, and maybe a bot removal isn't a good idea, but removing the parameters is not a cosmetic edit according to the definition in the policy.
Jo-Jo Eumerus (
talk) 19:05, 21 April 2020 (UTC)|ref=harv
s as a stand-alone task (
example) – are we OK with that? --
Francis Schonken (
talk) 18:50, 29 April 2020 (UTC)
|ref=
definition:
|ref=harv
being the default is that thousands of citation notes are fixed, and that it makes the entire citation ecosystem more user-friendly. The solution is to use a script that's up to date.
Headbomb {
t ·
c ·
p ·
b} 10:55, 19 April 2020 (UTC)|ref=
definition.
Two solutions work for me to stop the wrong error message when cite book is used without harv referencing. 1. Adding "window.checkLinksToCitations = false;" to "importScript('User:Ucucha/HarvErrors.js');" 2. Replacing "importScript('User:Ucucha/HarvErrors.js');" with "importScript(David Eppstein/HarvErrors.js);".
However, I have found a new problem. When cite book is used with ref=harv, I am getting an error message "CS1 maint: ref=harv (link)". Based on the comment of Trappist the monk above, this appears to be because CS1 has been changed to make harv referencing the default for cite templates, and give an error message for ref=harv on the ground that it is now redundant. Can I get rid of the wrong "CS1 maint: ref=harv (link)" error message by changing from CS1 to CS2, and if so how do I do that? Dudley Miles ( talk) 09:30, 19 April 2020 (UTC)
|ref=harv
is now the default, use of that parameter value no longer has meaning. The module suite adds the category so that editors and their tools can know where these parameters are being used so that they can be removed or modified.|ref=harv
. To remove the message, remove the parameter or change its assigned value to something more appropriate.|ref=none
, just as you could in CS2 before. Now people are free to use either CS1 or CS2, as they should have been a long time ago.
Headbomb {
t ·
c ·
p ·
b} 12:02, 19 April 2020 (UTC)
|ref=harv
is now the default, use of that parameter value no longer has meaning." Headbomb says "ref=harv is still working." Which is correct? What are the tens of thousands of broken citations which now work? Who decided that "Failing to remove an "unused" citation is not a high-priority issue"? In some cases they will have been removed because they are unreliable sources. The solution is to stop using citation templates. The latest changes have made them too difficult to use for anyone who is not a technical expert.
Dudley Miles (
talk) 12:48, 19 April 2020 (UTC)
|ref=harv
is the same as writing a cs1 template without |ref=harv
. In both cases, the template does the same thing. ref=harv is still workingbecause it is the same as the default. All other values assigned to
|ref=
are still handled in exactly the same way that they were handled before the module suite update..citation-comment {display: inline !important;} /* show all Citation Style 1 error messages */
|ref=harv
is not an edit that should be done on its own.
Headbomb {
t ·
c ·
p ·
b} 12:26, 20 April 2020 (UTC)
|ref=harv
would be bundled among those.
Headbomb {
t ·
c ·
p ·
b} 12:42, 20 April 2020 (UTC)Let's link this to policy: a WP:COSMETICBOT task, i.e. a bot performing cosmetic edits, is usually allowed if the WP:COSMETICBOT task is performed, in the same edit, with a substantial task. That does not make a WP:COSMETICBOT task a substantial task. Aligning citations with core content policies are, in contrast, substantial edits. A script that significantly assists with that is more important than whether or not a substantial edit has an appended cosmetic edit. The loss of perspective seems complete if you think that a cosmetic edit appended to a substantial edit is remotely as substantial as getting a script which has proven its usefulness for articles' WP:V compliance back on track. Trying to make policies say what they don't say is further illustration of that loss of perspective. -- Francis Schonken ( talk) 13:16, 20 April 2020 (UTC)
|ref=harv
) is now the default behaviour in CS1 templates, just like it was the default behaviour in CS2 templates. This has 2 main effects.
|ref=harv
to CS1 templates (or adding pointless |ref=harv
to CS2 templates because this was required in CS1 before). The number of actual errors (namely missing anchors) flagged by users scripts, like
User:Ucucha/HarvErrors.js has gone done significantly, leaving only things that now actually require human review, alongside a slight increase in collisions (which are flagged by HarvErrors scripts and other opt-in messages).|ref=harv
, will now warn against "missing" {{
sfn}}-generated anchors regardless of which of CS1 or CS2 templates are used. Additionally an opt-in CS1/CS2 maintenance message will display for those that choose to have those enabled. If those warnings bother you, then use
User:Svick/HarvErrors.js instead of
User:Ucucha/HarvErrors.js, and don't enable opt-in CS1/CS2 maintenance messages.I have checked the three solutions suggested and I see that they all work, but with reduced functionality as they do not highlight unused sources. This is an important issue as in some cases citations have been deleted because the sources are not reliable, and in other cases the book should be in further reading to signal to readers that it may contain additional information not covered in the article. I hope this deficiency will be resolved in the future. Dudley Miles ( talk) 14:58, 20 April 2020 (UTC)
"Ideas related to getting the HarvErrors script back on track" - how about putting it back how it was before the changes which were plainly made without consensus, and are certainly (judging by all the above) against consensus now? The hundreds of thousands of article-problems created would be seen from any rational standpoint as a powerful argument for reversion. Chiswick Chap ( talk) 13:19, 21 April 2020 (UTC)
The cite book functionality has not be degraded, it has been upgraded. You can now use harvard/snf templates with it without having to worry about explicitly declaring |ref=harv
. See for example
Smith (2016).
This fixed tens of thousand of broken footnotes everywhere on Wikipedia. It also makes the conversion of "manual" footnotes like <ref>Smith 2016</ref>
very much easier to do without having to worry about finding where the corresponding citation is in the text.
Headbomb {
t ·
c ·
p ·
b} 15:44, 21 April 2020 (UTC)
I never used HarvErrors.js. I do it all manually. Which can be a painstaking endeavour. Maybe if I'd used the script I'd have addressed this train-wreck of a "References" section (qualifying it WP:OVERREF is an understatement) a long time ago. CITEVAR issues regarding the article have been discussed on its talk page, e.g. here.
So, anyone to take up this challenge, that is the challenge of cleaning up "References", "Further reading" etc of
that article, with or without script assistance? I would like to get some feedback on how much difference the script (in its original and/or patched versions) makes in tackling such complex cases, and whether the task would have been easier before the "|ref=
harv " default for cs1 templates. Tx. --
Francis Schonken (
talk) 08:15, 21 April 2020 (UTC)
|ref=harv
would have shown the brown warnings. Now, the warnings are consistent whether CS1 or CS2 is used. In a situation like this, this change makes the script even more useful than it once was. Unless I am completely missing the point. –
Jonesey95 (
talk) 15:23, 21 April 2020 (UTC)Do we have a resolution to this issue yet? If a source is in the reference/bibliography/etc. section, it ought to be cited in the text, and the presence of warnings there that an anchor is not being used is a useful way to highlight the fact that the source either needs to be removed or shifted to a further reading section. Parsecboy ( talk) 11:58, 24 April 2020 (UTC)
There was a discussion at User talk:Citation bot/Archive 20#remove ref=harv about removing "ref=harv", and there was no consensus. Despite this, Headbomb continues to do it with AWB, first from templates now from drafts. This makes it a Wikipedia:Fait accompli, and ignores that retaining ref=harv makes it less of a nuisance to add ref=none (assuming this change to the templates sticks).
It concerns me how these discussions have been split across multiple pages. When I tried to open a central discussion at the PUMP, Kees08 closed it down; see the archived discussion. It means no one is keeping track of the objections and Headbomb can continue as if there is consensus. SarahSV (talk) 22:33, 29 April 2020 (UTC)
It concerns me how these discussions have been split across multiple pages.2.
Almost every time I write about this issue, here and elsewhere. You are making it difficult to AGF. Despite your forking of the discussions, we have tried to help you everywhere that you have posted and reposted your questions and comments and objections. – Jonesey95 ( talk) 05:15, 30 April 2020 (UTC)
|ref=harv
being default in the CS1/2 update or the HarvErrors.js script. And I also agree with you that those error messages should not be enabled, at least until the false positive situation is resolved. Which it may not end up being.
Headbomb {
t ·
c ·
p ·
b} 18:23, 30 April 2020 (UTC)Back then, almost all citation-class templates with no error in coding or usage (and hence not reported by Ucucha) were complaining with something like sfn error: no target..., and a pointer to a suppression method that usually didn't work.
almost all? Not true. The error message that you quote was emitted then as it is now by Module:Footnotes. The error messages were, and still are, usually not from false positives though those exist. When I enabled the error messages on 27 March 2020, the category held about 47.7k pages. With whitelisting, with editor fixes, and with the switch to auto-
|ref=harv
, the category is now at about 34.2k pages. How much reduction of the category size is due each of these three 'reducers' is not known; probably not knowable. The module is used on about 144k pages so clearly not almost all.
|ref=harv
whenever I wanted to use sfn templates was also quite irritating. And I am willing to bet that a lot more templates needed that parameter back then than need |ref=none
, meaning that the amount of work needed now is less than before the change. I think we might want to discuss a better way to socialize CS1/2 changes. This isn't the first time where a change caused contention. Perhaps notifying folks through The Signpost - if I understand CS1/2 templates correctly, changes to them are implemented in periodic batches and there is a schedule of sorts of when they change - of major changes to CS1/2 will prevent complaints about breaking changes. Jo-Jo Eumerus ( talk) 14:57, 1 May 2020 (UTC)
|ref=none
for articles to be functional to readers, that sort of goes without saying that it's a lot less work. Also the Signpost editors don't like these tutorial articles, so don't bother writing them because you'll be wasting your time, because they'll even try to delete things in your userspace if you try to write something for them that they don't like.
Headbomb {
t ·
c ·
p ·
b} 15:15, 1 May 2020 (UTC)
Headbomb continues to remove ref=harv. [1] Pinging RexxS because I don't know what else to do at this point. SarahSV (talk) 21:44, 7 May 2020 (UTC)
When, and why, did |episode=
in {{
Cite episode}} become unsupported? It seems counter-intuitive. --
Michael Bednarek (
talk) 02:31, 19 April 2020 (UTC)
|number=
. When and why was that removed? Was there any attempt to bot-replace it? Now
we see |episode=
removed without replacement, a clear disimprovement. --
Michael Bednarek (
talk) 02:26, 20 April 2020 (UTC)
|episode=
was reintroduced to {{
cite episode}}
, you should be able to find its reintroduction and then removal in the template's history somewhere. I was not able to find a reintroduction and removal; I only found the initial removal that I linked above.|episode=
should be made part of {{cite episode}}
. Since then I have done nothing with that parameter in the module suite.|episode=
was globally supported in that whitelist
until 18 April 2020. Reading the module code, it seems the parameter is supported at {{
Cite serial}}, so why not at {{
Cite episode}}? --
Michael Bednarek (
talk) 11:31, 25 April 2020 (UTC)
{{
cite episode}}
and {{
cite serial}}
from their {{
citation/core}}
implementations to their
Module:Citation/CS1 implementations within minutes of each other. Because |episode=
was required for {{cite serial}}
, that parameter is whitelisted. The migrations were intended to be transparent to readers and editors. The new Module:Citation/CS1 implementation of {{cite episode}}
reproduced the {{citation/core}}
implementation of {{cite episode}}
as it existed on the day of the migration. The old implementation did not support |episode=
.|episode=
was replaced with |title=
in 2006; I wasn't here then. The editor who made that change hasn't contributed to en.wiki since April 2019 but you could try asking via email.|lang=zh-tw
displays "Taiwanese Mandarin" and not "Chinese"
zh-tw
makes no sense. It outputs "Chinese" for zh-tw
, zh-cn
, etc. ISO really dropped the ball for zh
. Languages as diverse as
Cantonese,
Beijing dialect, and
Wu Chinese can be, and often are, all called "Chinese" even though they are not at all mutually intelligible in speech, especially traditional forms. (
Nota bene:
Varieties of Chinese.)|lang=zh-cn
"Chinese" either, but rather "Mandarin Chinese". Only plain |lang=zh
should be "Chinese", and its use should be treated as an error, in my opinion, and we should consider raising one, maybe only putting it in an error category. Perhaps,
Category:Articles with CS1 sources in unspecified language in Chinese language family.Psiĥedelisto ( talk • contribs) please always ping! 01:30, 19 July 2020 (UTC)
cmn
, wuu
and yue
, respectively. Several other languages in the massive tent of written Chinese have separate codes as well, as is demonstratable by following links from
Varieties of Chinese and looking at the articles' infoboxes. That doesn't solve this problem entirely, but it's incorrect to say that zh
is the only available code.
Glades12 (
talk) 19:12, 19 July 2020 (UTC)
|lang=cmn
, though. It does understand |lang=yue
(outputting Cantonese) and |lang=wuu
(outputting Wu Chinese). I guess why I say ISO dropped the ball is that I don't think |lang=zh
should exist—no other broad language families have such codes, and it causes a lot of lazy mislabeling under the broad identifier rather than the narrow. What do you think about my idea to add a hidden error category? Now that you've taught me about |lang=cmn
, I suppose we need that really: |lang=cmn-TW
(
Taiwanese Mandarin), |lang=cmn-CN
(
Standard Chinese, or should it be
Beijing dialect?), etc.
Psiĥedelisto (
talk •
contribs) please always
ping! 19:21, 19 July 2020 (UTC)
zh
. Also, no idea why the software doesn't recognise
cmn
; it's as valid a code as the others we've mentioned here.
Glades12 (
talk) 07:36, 20 July 2020 (UTC)
|lang=zh
and the short name "Chinese" are quite appropriate. Codes like cmn, yue, wuu, etc would be relevant if we were citing recordings.
Kanguole 08:32, 20 July 2020 (UTC)
zh
an error category is fine with me, though, I see your point.
Cantonese, also, is often not fully mutually intelligible even in writing, and Cantonese-only characters exist. A Western reader might also confuse
Chữ Nôm for Chinese, when they are also not mutually intelligible. So, these codes do serve a purpose for written texts. I'm not familiar enough with Wu Chinese to comment on it.
Psiĥedelisto (
talk •
contribs) please always
ping! 20:36, 20 July 2020 (UTC)
|lang=vi-Hani
.
Kanguole 21:06, 20 July 2020 (UTC)
cmn
in most places we're using zh
now.
Psiĥedelisto (
talk •
contribs) please always
ping! 02:10, 21 July 2020 (UTC)
zh-tw
to "Taiwanese Mandarin", adding cmn
and putting zh
into a tracking category, but since most Western readers won't be able to determine something more specific than zh
when some text is advertised in the real world just as "Chinese" (which is often the case), it shouldn't be an error category as this would keep people from adding the information at all, and it is useful for formating purposes even while unspecific. --
Matthiaspaul (
talk) 17:59, 20 July 2020 (UTC)Wikitext | {{cite book
|
---|---|
Live | Fiennes, Celia (1888). Through England on a Side Saddle in the Time of William and Mary. London: Leadenhall Press. {{
cite book}} : Check |author-link= value (
help)
|
Sandbox | Fiennes, Celia (1888). Through England on a Side Saddle in the Time of William and Mary. London: Leadenhall Press. {{
cite book}} : Check |author-link= value (
help)
|
fixed in the sandbox;
— Trappist the monk ( talk) 12:53, 22 July 2020 (UTC)
In the Usage section is a table of parameters with some having prerequisites. It notes that the others parameter has a prerequisite of title, but it fails to note that the others parameter also has a prerequisite of last or author. I would fix it myself but I can't figure out where this is stored. — Anomalocaris ( talk) 07:12, 22 July 2020 (UTC)
|others=
doesn't have that prerequisite, and shouldn't anyway, because some sources (such as signs and very short magazine articles) only credit certain roles such as illustrators or editors. In cases like those, the templates should absolutely not force editors to choose between guessing who wrote the material and not including any names at all.
Glades12 (
talk) 11:09, 22 July 2020 (UTC)
|title-link=
prerequisite at {{
cite AV media notes}}
was misplaced; fixed now.|title=
, |chapter=
, |article=
, or |booktitle=
, etc. while also specifying a URL for that element.|others=
without also using |author=
or |editor=
or any of their aliases. |others=
is provided to record other (secondary) contributors to the cited source. Articles are listed in this category when
Module:Citation/CS1 identifies a template that does not identify primary contributors....|title-link=
with its prerequisite |title=
because, as it was, it was so obviously wrong and because, at the time, I had other stuff on my mind. The incorrect alignment has been in place since I made
this edit – I guess it wasn't so obvious at the time... Unless someone beats me to it, I'll add |lastn=
, |authorn=
, |editor-lastn=
, and |editorn=
as prerequisites for |author=
(probably tomorrow).We need a way to handle page numbers in computer files and eBooks that are not absolute page numbers. Google has their own way of identifying such pages, and we should decide how we want to handle it in the general case, Google or otherwise. I'm hoping for a discussion to see, in the first instance, whether there's interest in establishing a conventional method of doing this (achievable via /doc changes alone), or if something more robust is required.
Checked the archives, and didn't see anything about this; please add a link if I missed something. More and more, books are being "printed" online only, and exist purely as digital files. Or as both, but the accessible one is digital. Especially in the former case, there may not be an absolute "page number", depending on the format (i.e., not pdf or other fixed format) and on the rendering engine. In particular, Google will render these without visible page numbers in their page view mode. They do have an identifier they use in their url to distinguish the two cases. As near as I can determine from generalizing from a few dozen examples, the url param |pg=
is used for both cases, but the value differs depending on the source; for example: |pg=PA35
for printed, absolute page number visible in printed version, and |pg=PT35
for a page number on a digital resource. Note that in book search results, the Google result snippet will be slightly different: the boxed contextual snippet will say found inside – page 35 in the latter case, and found inside in the former.
For starters, I think this could be a doc-only change, by way of some additional text at the section on page, recommending what to do in this case, without any need for software changes. For example, something like:
For computer files where no fixed page number is present, code the page number a
|page=X99
, where the 'X' prefix is replaced by an identifier ('G' for Google books, 'I' for internet archive, ...) and the '99' represents the page identifier given by that display provider. The following table provides the identifiers for some common eBook providers: <table>...
That's just a first cut, and I'm sure I failed to consider lots of things. But the point is, I think we can initiate something useful without a software change, which would be a lot easier to get going, n'est-ce pas?
An example of using a conventional approach, as proposed
|
---|
By June, the different branches of Free France, led by de Gaulle out of London, and by Giraud out of Algeria, merged into one, creating the French Committee of National Liberation.<ref name="Davis-2018">{{cite book |lang=en |last=Brunet |first=Luc-Andre |editor-last1=Davis |editor-first1=Muriam Haleh |editor-last2=Serres |editor-first2=Thomas |title=North Africa and the Making of Europe: Governance, Institutions and Culture |chapter=1. The Role of Algeria in Debates over Post-War Europe within the French Resistance |url=https://books.google.com/books?id=tP5DDwAAQBAJ&pg=PT35 |accessdate=23 July 2020 |date=22 February 2018 |publisher=Bloomsbury |isbn=978-1-350-02184-6 |oclc=1037916970 |type=computer file |page=G35–36}}</ref> |
Going forward, maybe we do want more control of this, so maybe there's a new param to explain who the rendering engine is:(e.g., |epager=Google
, |epager=Internet Archive
, etc.). You would think that the value of the |url=
field would be enough to imply the latter, but in the real world, the multiplicity of CS1 params not infrequently don't all remain in sync, so I wouldn't trust that method; you'd end up with page numbers corresponding to some mystery provider. That might even be a reason to keep the original suggestion (i.e., use |pg=G35
for Google efile) because the page number and the method are kept together in one param value. Your thoughts appreciated.
Mathglot (
talk) 01:10, 24 July 2020 (UTC)
|chapter-url=
and its aliases. Other than that, I don't think any special system is warranted. In scanned works, what is actually cited is the scan image, not its source. Different considerations apply, imo.
98.0.246.242 (
talk) 01:37, 25 July 2020 (UTC)The other day, I noticed that we don't have |subject-mask=
or any of its enumerated forms. I have added |subject-mask=
, |subjectn-mask=
, and |subject-maskn=
{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask=2}}
{{cite interview/new |title=Title |subject=Abraham Lincoln |subject1-mask=2}}
{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask1=2}}
The |subject=
and |interviewer=
arrays of parameters are used primarily in {{
cite interview}}
. Because we don't have non-hyphenated forms of the |interviewer=
parameters and because the preferred form for parameter names is hyphenated, I have deprecated |subjectlink=
, |subjectlinkn=
, and |subjectnlink=
. Here are some simple searches that indicate usage of these parameters:
|subjectlink=
:
~860 hits|subjectlinkn=
:
~110 hits|subjectnlink=
:
times out
{{
cite interview}}
:
|subjectnlink=
0 hits— Trappist the monk ( talk) 22:48, 26 July 2020 (UTC)
Wikitext | {{cite journal
|
---|---|
Live | Barry, R. G. (1978). "H.-B. de Saussure: The First Mountain Meteorologist". Bulletin of the American Meteorological Society. 59 (6): 702–705. Bibcode: 1978BAMS...59..702B. doi: 10.1175/1520-0477(1978)059<0702:hbdstf>2.0.co;2. ISSN 0003-0007. |
Sandbox | Barry, R. G. (1978). "H.-B. de Saussure: The First Mountain Meteorologist". Bulletin of the American Meteorological Society. 59 (6): 702–705. Bibcode: 1978BAMS...59..702B. doi: 10.1175/1520-0477(1978)059<0702:hbdstf>2.0.co;2. ISSN 0003-0007. |
Fixed in the sandbox.
— Trappist the monk ( talk) 16:19, 29 July 2020 (UTC)
{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-style = vanc | title= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | contribution= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}
Gives
{{
cite journal}}
: |contribution=
ignored (
help)It should give something better, like
Or maybe
Headbomb { t · c · p · b} 18:31, 27 July 2020 (UTC)
|department=
:
{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-style = vanc | department= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | title= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}
I'm trying to cite a newspaper source, for which the paper (or its website) doesn't exist anymore, but copies of the relevant article are embedded in a council ordinance. Can I do that, and if so, what would be the syntax?
The full ordinance is
here, and I would like to reference page 106: "Success or failure?", Sean Robinson, The News Tribune.
Frescard (
talk) 14:23, 29 July 2020 (UTC)
|via=
), but if you think it is helpful, you can instead cite both in one <ref> statement; something like {{cite news |newspaper=The News Tribune |first=Sean |last=Robinson |title=Success or failure? Probing Prometa}} as in {{cite web |url=https://online.co.pierce.wa.us/cfapps/council/model/otDocDownload.cfm?id=1448900&fileName=2007-81s%20final%20Ord%20file%201.pdf |department=Today in the Trib |website=Pierce County, Washington |title=Ordinance No. 2007-81s: etc. |p=106}}
: Robinson, Sean. "Success or failure? Probing Prometa". The News Tribune. as in
"Ordinance No. 2007-81s: etc" (PDF). Today in the Trib. Pierce County, Washington. p. 106. --
Izno (
talk) 02:18, 31 July 2020 (UTC)
|via=
is I believe problematic: the source that includes the article is not an archive, repository, or other publisher. The article is included as supporting (incidental) documentation, as the OP described it, a source from a 3rd party. Tertiary sources should be referenced as such.
98.0.246.242 (
talk) 02:16, 1 August 2020 (UTC)
|via=
is justified. But even that case does not apply here. The relevant text is a fragment of the containing source. It should be cited as such.
65.88.88.57 (
talk) 14:16, 2 August 2020 (UTC)What is the standard, if any, for citing a newspaper article that is available online, that is split onto two webpages. This occurs a lot with Newspaper.com sources. Generally speaking, the article is one source, with one title, author, date, etc. However, to assist with verifiability and to be able to archive each page of the article, I have been splitting it into two separate references, adding "Part 1" and "Part 2" to the title. See an example below:
This allows me to cite each sentence in an article with the relevant page of the news article. But it does create some confusion and adds additional sources in the reference list. Is there a better way to do this? Does (or could) {{ Cite news}} support two urls and two archive-urls? Thanks for any insight. « Gonzo fan2007 (talk) @ 15:39, 3 August 2020 (UTC)
|type=clipping
is helpful because Newspapers.com will allow readers without an account to see the full page from which the clipping is drawn.
Imzadi 1979
→ 20:56, 3 August 2020 (UTC)Is there a different validation for |publication-date=
as it is reporting an error which does not happen if it is |date=
?
Rik Farrow (2018). Rik Farrow (ed.).
"Musings" (PDF). ;login. 43 (4).
USENIX (published Winter 2018): 4.
ISSN
1044-6397. {{
cite journal}}
: Check date values in: |publication-date=
(
help)</ref>
Keith D ( talk) 21:17, 17 July 2020 (UTC)
|date=
.|publication-date=
as well, I guess. --
Matthiaspaul (
talk) 11:20, 18 July 2020 (UTC)
|publication-date=
an alias of |date=
and deprecate the long alias or remove it from the docs; we do not need to "advertise" every alias that has ever existed. —
SMcCandlish
☏
¢ 😼 13:04, 4 August 2020 (UTC)How should editors use the |website= parameter? I'm talking about this edit and similar ones. The examples at Template:Cite web#Examples use the website name (in this case, Parties and Elections in Europe), but the automatic citation-creating tool uses the url of the website (in this case, www.parties-and-elections.eu). However, I also tried to use the auto-citation tool with a Wikipedia article as the url to test, and it put Wikipedia in the website parameter. Is this a mistake in the auto-citation tool? Thanks, Ezhao02 ( talk) 15:37, 27 July 2020 (UTC)
both www.parties-and-elections.eu and Parties and Elections in Europe should be listedNo, do pick one or the other. Our guidance at Help:CS1#Work and publisher is currently the following:
Does that help you decide? -- Izno ( talk) 16:02, 27 July 2020 (UTC)On websites, in most cases "work" is the name of the website (as usually given in the logo/banner area of the site, and/or appearing in the <title> of the homepage, which may appear as the page title in your browser tab, depending on browser). Do not append ".com" or the like if the site's actual title does not include it (thus |work= Salon, not Salon.com). If no clear title can be identified, or the title explicitly is the domain name, then use the site's domain name. Do not falsify the work's name by adding descriptive verbiage like "Website of [Publisher]" or "[Publisher]'s Homepage". Capitalize for reading clarity, and omit "www.", e.g. convert "www.veterinaryresourcesuk.com" to "VeterinaryResourcesUK.com".
Hello, can you please add some error-check code and emit a big, red error message, if an editor codes a "link" param (author, title, translator, editor, contributor are the ones I'm aware of) to a sister wikipedia like fr-wiki without a leading colon on the lang code? What happens in this case, is various kinds of strange behavior, including dropping the field (author, say) and emitting only a semicolon or other punctuation; but worse is that the first of these, whatever it is, is picked up as an interwiki, and the entire article is linked under that language name in the left sidebar. Same thing occurs for fields with permissible wiki-linking, such as publisher. Beyond that, it screws up article links at Wikidata, as soon as their bot sees it.
You can see an example of the faulty behavior in revision 969921029 of André Diethelm. Go to the language links in the left sidebar, and notice that the Hebrew and Arabic links point to the correct articles (Google translate does a sufficient job of transliterating the titles to confirm they are correct if you need it) but the French one is wrong, and links to fr:Éditions Philippe Rey. This happens to be the publisher of one of the sources listed in the #Further reading section, namely "Lambert (2010)", but you won't see it on the rendered page, because it's been snatched by the wikimedia code and interpreted as the target of the "Francais" link in the language sidebar; all you will see in the Lambert citaton is extra punctuation between "Paris" and the ISBN. To actually see the linked publisher with the missing colon, you have to view the wikicode of that revision.
You can diff that version with current ( diff), to see that the only change was to add one colon in the Lambert publisher field. Notice that the Francais link in the sidebar is now correct. (Same thing happens if you forget the leading colon in authorlink, or any of the other *-link fields.) These should be flagged as errors, because they will escape the notice of many users. Also, the bots at Wikidata are rapid, and although I noticed and fixed the problem within minutes, I was too late, and the Wikidata bot had already linked my French Resistance guy at en:André Diethelm to the French publisher fr:Éditions Philippe Rey via item d:Q3579477 ("Éditions Philippe Rey"; diff). I had to both unlink that connection, then go relink Diethelm to d:Q2847654 instead (same one that has the Hebrew and Arabic articles as well).
This is too much to ask most users to do. A big, fat, red error for interwiki links that lack a leading colon would be a big help. Thanks, Mathglot ( talk) 06:04, 28 July 2020 (UTC)
|publisher=[[fr:éditions Philippe Rey|Philippe Rey]]
is not a |<param-link>=
problem; somewhat related, but not the same.|<param-link>=
where the assigned value begins with a known local inter-wiki prefix without a leading colon. There are a couple of exceptions. The w:
and wikipedia:
prefixes do not require leading colon. The s:
and wikisource:
prefixes have special meaning because cs1|2 creates urls from these inter-wiki links so that it can add the wikisource icon. From the example template, tweaked so that the author wikilink is missing the leading colon:
|publisher=
inter-wiki link problem must be handled differently because for the most part, any cs1|2 parameter may be wiki-linked (despite documentation to the contrary). For all parameters in a cs1|2 template that are not |<param-link>=
parameters, inter-wiki links must begin with [[<prefix>:
where <prefix>
is a known local inter-wiki prefix, s:
, w:
and their long-forms again excepted. As each parameter name is validated, the cs1|2 sandbox looks for this pattern and emits and error message when detected:
wikipedia:
in the exclusion list because it is listed at
Help:Interwiki linking as the long form of w:
. But, now that you point it out, wikipedia:
the prefix makes no sense because it conflicts with wikipedia:
the namespace. No doubt the exclusion list might include
b:
(wikibooks),
c:
(commons),
d:
(wikidata),
m:
(meta),
n:
(wikinews),
q:
(wikiquote),
v:
(wikiversity).wikipedia:
does not conflict on other wikis as a thought. --
Izno (
talk) 22:55, 4 August 2020 (UTC)
[[wikipedia:]]
on
meta: links to the en.wiki main page. As a guess, I would say that wikipedia:
, the name space, is common on encyclopedia wikis but not on other types of wiki.[[
w:]]
appears to be a prefix that always links to en.wiki, I'm wondering if that prefix should continue to be excluded from the error check. Here at en.wiki, the w:
prefix gets you to the article in the same way that the en:
prefix or no prefix does:
[[
w:Abraham Lincoln]]
[[
en:Abraham Lincoln]]
[[
Abraham Lincoln]]
w:
prefix links to the en.wiki article but isn't otherwise treated as a inter-language inter-wiki link.
v:
earlier.mw.site.interwikiMap ('local')
. I am minded to change that and instead use the list of languages returned by mw.language.fetchLanguageNames ('<local wiki lang code>', 'all')
if I can show that all of the language codes in that list are also found in the inter-wiki map list.mw.site.interwikiMap ('local')
and mw.language.fetchLanguageNames ('<local wiki lang code>', 'all')
. Prefixes in mw.site.interwikiMap ('local')
must match a language code in mw.language.fetchLanguageNames ('<local wiki lang code>', 'all')
to be added to the local list. There are seven 'language-like' codes in mw.site.interwikiMap ('local')
that 'redirect' to another-language wiki but these codes do not contribute to the inter-wiki language list:
cmn:
→ Mandarin Chinese (ISO 639-3 code); redirects to zh.wikipedia.org
cz:
→ Czech (ISO 3166 country code); redirects to cs.wikipedia.org
dk:
→ Danish (ISO 3166 country code); redirects to da.wikipedia.org
epo:
→ Esperanto (ISO 639-3 code); redirects to eo.wikipedia.org
jp:
→ Japanese (ISO 3166 country code); redirects to ja.wikipedia.org
minnan:
→ invalid IETF language tag; redirects to zh-min-nan.wikipedia.org
zh-cfr:
→ invalid IETF language tag; redirects to zh-min-nan.wikipedia.orgno
(Norwegian, in general) or nn
(Nynorsk), I can't remember —is odd man out, wrt to a giant list of WP codes that generally match the ccTLD codes, except for that one case. (There's also Bokmal, nb
, but it wasn't that.) This could be a red herring, but just wanted to recall it, in case it's relevant here.
Mathglot (
talk) 03:40, 6 August 2020 (UTC)
[[
nn:]]
links to the Norsk nynorsk nn.wiki, both of [[
nb:]]
and [[
no:]]
link to the Norsk bokmål nb.wiki. I do remember that for a time, language code no
was not supported by the {{#language:}}
magic word. That has since been fixed:
{{#language:nb|en}}
→ Norwegian Bokmål{{#language:nn|en}}
→ Norwegian Nynorsk{{#language:no|en}}
→ Norwegian|langcode=
and |googlelangcode=
, not found in any other Expand language template (such as
Template:Expand Norwegian). The explanation at
this /doc page references Nynorsk. So, red herring, as far as we are concerned here.
Mathglot (
talk) 04:28, 7 August 2020 (UTC)Also, while I'm thinking of it: despite the emission of a CS1 error in preview mode, the editor can still override and save anyway, as shown in your sandbox example above. This is fine, for the *-link case, but not so great for the publisher=[[fr:Seuil]] case, because if that link is saved like that, the Wikidata bot will likely do something strange. I don't know if this is beyond the scope of this template, but, for example, could you stop the user from saving it in that form, either by stripping out the brackets, or supplying the preceding colon? If not, maybe in that case we'd need to see about an edit filter to trap it, but I suppose that would be a discussion for somewhere else. Mathglot ( talk) 09:50, 5 August 2020 (UTC)
|<param-link>=
parameters that fail the various link tests (has a url, has wikilink markup, has inter-wiki prefix without leading colon) the code simply unsets the parameter and declares the error:
{{Cite book/new |title=Title |title-link=//example.com}}
→ Title. {{
cite book}}
: Check |title-link=
value (
help); External link in |title-link=
(
help){{Cite book/new |title=Title |title-link=[[Title]]}}
→ Title. {{
cite book}}
: Check |title-link=
value (
help){{Cite book/new |title=Title |title-link=nv:Title}}
→ Title. {{
cite book}}
: Check |title-link=
value (
help)|<param>=[[<prefix>:<value>
the code extracts the label portion of the wikilink:
Hi, I guess most of us do not remember all parameters supported by the various citation templates, in particular those which are not generic, but specific to certain templates.
In order to make it easier (quicker) to look up the template specific help page, I propose to let the template display an unobtrusive link to its help page (only) in article preview, either in front of the citation or after it.
This could look like [1]
{{ Cite journal}} would have a link to Help:Cite journal, {{ Cite conference}} to Help:Cite conference, {{ Cite book}} to Help:Cite book etc.
If even this small [?] would be found to be too obtrusive, it could be put into some CSS stuff so that it would show only when an editor has opted in to maintenance messages.
-- Matthiaspaul ( talk) 11:01, 13 July 2020 (UTC)
As a preview/opt-in message. Headbomb { t · c · p · b} 12:42, 13 July 2020 (UTC)
{{REVISIONID}}
magic word for every citation whether there were errors or not. That implementation drew the attention of MediaWiki because it took longer to save pages. This because preview-pages are different from saved pages so MediaWiki can't reuse the preview and must parse the wikitext again before it can be saved. See
Help talk:Citation Style 1/Archive 20 § archive url checks and preview mode and the related discussion at
Wikipedia:Village pump (technical)/Archive 147 § Preview-only template warnings using REVISIONID magic word.(X-posting from the Tech Pump) Wikiquote's ref template will parse "July 2 1999" just fine, but our template requires a comma, e.g. "July 2, 1999". Why is that? Can someone fix our template to stop caring so much? I screw this up on my first pass something like 25% of the time. -- Kendrick7 talk 00:30, 7 August 2020 (UTC)
Right now, Category:CS1 maint: display-authors and other friends are nearly always empty because they are nearly always an easy-to-correct error. I would like to propose upgrading them to errors accordingly, which will make them more visible to editors.
To make this easier to do in the future with maintenance messages we decide should be errors, I'd also like to see the error and maintenance system implementations be made the same (save for the obvious distinction). For this latter, I trip up really hard every time I want to get maintenance items turned into errors, and it's making it hard to parse how to make the necessary code modification for display-X.
Any concerns? -- Izno ( talk) 12:45, 4 July 2020 (UTC)
message
, anchor
, category
, hidden
. For maint cats, we might define these:
message
always nil
or empty stringanchor
a unique value used to link into
Help:CS1 errors help textcategory
the key that tells common set_error()
how to handle the issue; maint cat names all begin with 'CS1 maint:' whereas error message cats aren't so consistenthidden
ignored for maint cats which are always hiddenz.error_categories
. Property and maint cats have their own tables (maintenance_cats
and properties_cats
). Maint cats can display their names as an editor-option via css, prop cats display nothing.category
to the correct error cat; add the appropriate error message in message
, and set hidden
to the appropriate boolean.|date=
twice. --
Matthiaspaul (
talk) 07:58, 7 July 2020 (UTC)
set_error()
→ set_message()
and been modified so that it will emit maintenance category 'messages' when the message
property for that message is nil
. Maint messaging is now part of the error_conditions{}
table in
Module:Citation/CS1/Configuration/sandbox; TODO: rename that table.I worked my originating request as a result of this rework, which moves display_names messaging (inconsistently error and maintenance) to strictly errors. Main, /Configuration and testcases2. Perhaps of note that this changes the error for the "don't know" case from invalid_param_values to disp_name; I made that change to centralize all the disp_name errors fixing. There may be further work that should be done so the other use of that error can be more definite. -- Izno ( talk) 22:50, 8 August 2020 (UTC)
One other thing: I am not personally convinced that we need 5 categories to handle display_names issues. I think 1 would suffice. Seeking feedback on that point. -- Izno ( talk) 22:52, 8 August 2020 (UTC)
"Template:Cite Book" needs terms for all of the MARC 21 fields, especially total pages, size, etc. 71.230.16.111 ( talk) 06:47, 24 July 2020 (UTC)
|size=quarto
". Yeesh.
Wikipedia is not anything like
WorldCat. —
SMcCandlish
☏
¢ 😼 13:00, 4 August 2020 (UTC)I'm sure the way in which access is indicated in citations has been discussed extensively by the regulars here, and I apologize for my ignorance of your past discussions. Is there a field to indicate that a book is public-domain (in this case, a 2018 work of US government) and the fulltext is freely available online? This will make it obvious that it is easy to verify the cited statement, and increase the likelihood of editors and readers actually doing it. I understand that such access parameters are already common on journal article templates.
An additional winkle here: many medical journal articles are currently freely accessible due to a special action taken by publishers for the COVID-19 pandemic. At some future date to be decided upon by the publishers, they will put the articles back behind paywalls. Public licenses are permanent, but free access may be revoked. I'm not sure how widespread this is, but we might end up with a lot of incorrect information on access. HLHJ ( talk) 17:29, 8 August 2020 (UTC)
I have a question about a book that is divided into several individual sections with their own authors. ¿How should I cite that book? In my case I am only interested in one section of that book. -- Muwatallis II ( talk) 23:11, 8 August 2020 (UTC)
{{
cite book}}
: |author=
has generic name (
help) is the basic skeleton. If you have some more information we can fill out the rest for you. --
Izno (
talk) 23:12, 8 August 2020 (UTC)The book is called: Escuadra Nacional 1818-2018 (no author, only publisher)
The title of the chapter or section of the book already mentioned is: De la Guerra del Pacífico hasta fines del siglo XIX. The author is: Piero Castagneto Garviso. This author is just from the chapter or section of the book.
As I mentioned before, the book has other chapters or sections with their own authors, but I'm only interested in the one already mentioned. -- Muwatallis II ( talk) 00:04, 9 August 2020 (UTC)
|url=http://anyflip.com/yccc/bhap
:
When the source being cited is a chapter in an edited book or an article in a journal, the language of the source (specified with |language=
) should be notated after the chapter or article, rather than after the book or journal, which may include items in several languages. For example, currently we have:
{{
cite book}}
: |author=
has generic name (
help){{
cite book}}
: |editor=
has generic name (
help)The first is fine, but in the last two "(in German)" should be moved forward, after the chapter or article. Kanguole 11:50, 9 August 2020 (UTC)
In the following example, the "(PDF)" format designation comes after the translated title, which looks odd because the PDF symbol is displayed after the foreign language title:
There are several potential ways to solve this:
Ideas? -- Matthiaspaul ( talk) 14:28, 20 June 2020 (UTC)
|script-*=
and |trans-*=
parameter variants for them. I've changed it to |magazine=
, though - they describe themselves as a magazine rather than as a journal. |work=
is too unspecific. I use |work=
only when none of the more descriptive parameters applies (typically with {{
cite web}} or {{
cite book}}, rarely with {{
cite journal}} or {{
cite magazine}}). --
Matthiaspaul (
talk) 10:22, 13 July 2020 (UTC)|format=
is used to specify something different, it would be displayed as before, but then the icon and the text would not be redundant and therefore look much less out of place than now. --
Matthiaspaul (
talk) 18:12, 20 July 2020 (UTC)
the PDF icon and a "(PDF)" text is redundant. The pdf icon is rendered by MediaWiki as a css
background-image
property (
MediaWiki:Common.css). Because it is not rendered from an html <img>...</img>
tag, it does not support the alt=
attribute. In cs1|2, the automatic |format=PDF
is a way to notify screen-reader-users that the source is a pdf file. That functionality should not be degraded.alt=
text).There's a few links I've seen in references to old webpages with valid archive URLs of what the site looked like in 1997, but there's malware-downloading squatters at the URL now. Is there a way to suspend a link to the site in this template? Or should the URL just be replaced directly with the archive link in such cases? SnowFire ( talk) 05:53, 10 August 2020 (UTC)
|url-status=unfit
to the citation, the original URL will not be linked. Read more at
Template:Cite web/doc. --
John of Reading (
talk) 06:07, 10 August 2020 (UTC)