Help talk:Citation Style 1/Archive 42

This is an archive of past discussions about Help:Citation Style 1. 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.

[Note: this was previously part of "Demarcation of cite interview", but I (E to the Pi times i) split it into its own section.]

Looking at Izno's example usage more closely, I have a question. If other citation templates can utilize |interviewer-last= and |interviewer-first=, why do we need {{cite interview}}? E to the Pi times i (talk | contribs) 15:50, 17 March 2018 (UTC)

Isn't that the same question that Editor Codename Lisa was asking about {{cite press release}}?

—Trappist the monk (talk) 15:53, 17 March 2018 (UTC)

Maybe, I'll have to examine that proposal again. I don't think so, but I'll do some more research before discussing it further. E to the Pi times i (talk | contribs) 15:56, 17 March 2018 (UTC)

@Trappist the monk: I think Lisa's proposal conflated the prefered style of names of works with types of works.

The only difference I see in using {{Cite interview}} over interview parameters with other citation templates is that {{Cite interview}} puts (Interview) after the name of the work. This could be accomplished in other works by using |type=Interview. Another way to accomplish this is implementing the CS1 module to add (Interview) after any citations which use |interviewer-last= and |interviewer-first=. In the interrim of implementation, interviews could use |type=.

The reason why I see this as an advantage is that most of the other CS1 templates categorize sources by publication type, but this template categorizes a type of work, an interview. While being an interview does matter for the purposes of primary source tracking, using publication-specific templates would simplify citation standaradization. If interviews are implemented in a sensible way through other templates (|type=, |interviewer-last=, |interviewer-first=), then I see no reason to use {{cite interview}} when it doesn't (and probably shouldn't have to try to) accomodate the formatting all types of publication the interview may be published in.

Are there any other differences that I'm missing? Do you agree that it's a categorical difference? E to the Pi times i (talk | contribs) 16:26, 17 March 2018 (UTC)

I was thinking about this attempted change in which, it appears to me, Editor Codename Lisa would have merged {{cite press release}} into {{cite news}} and then required editors to know to set |type=Press release. A handful of the cs1 templates automatically set |type=: {{cite AV media}}, {{cite interview}}, {{cite mailing list}}, {{cite map}}, {{cite podcast}}, {{cite press release}}, {{cite report}}, {{cite techreport}}, and {{cite thesis}}.

These templates started as individual templates created (in some amount of isolation from each other) to cite some specific thing where the name of that thing was used as the name of the template. That 'tradition' isn't limited to the cs1 templates. We could break with that tradition but ought not without significant discussion beforehand (of course, thinking about the where, what, why, how of the design before committing to the implementation is not the wiki-way). Were we setting out to craft a suite of citation templates anew, we might attempt to make fewer of them but make them highly dependent of the parameter/value pairs that specify the citation. It is not at all clear to me that the benefits of such a redesign outweigh the efforts required.

{{cite interview}} could use a tweak. It doesn't handle pagination correctly if written as a journal cite; renders the same as magazine, news, and generic 'work' cites:

"Title". Magazine (Interview). Vol. 1, no. 4. p. 7.

"Title". Newspaper (Interview). Vol. 1, no. 4. p. 7.

"Title". Work (Interview). Vol. 1, no. 4. p. 7.

"Title". Journal (Interview). 1 (4): 7.

I'll look into tweaking it.

—Trappist the monk (talk) 21:56, 17 March 2018 (UTC)

Tweaked:

—Trappist the monk (talk) 22:04, 17 March 2018 (UTC)

@Trappist the monk: I suppose this is what you mean by the efforts required. 3559 transclusions is certainly quite a few to replace. If one replaces 1 citation a minute, it would take 60 hours. I have ideas of how to expedite that (e.g. bots, semi-automation, url filtering for the correct CS1 template), but I have to do more research and testing before I can discuss them.

I guess the real question for me is should we switch the format. I strongly think we should. As I mentioned previously, {{cite interview}} is an outlier in that it is a format of work, not a type of publication. {{cite book}}, {{cite news}}, and {{cite magazine}} are all types of publications in which an interview might appear; an interview itself is not a concrete type in the same sense. When I'm referencing an interview, I care more about where it came from than about it being an interview.

The other thing I see is that in the short term it may be a lot of work, but in the long term it will save work. It seems to me that {{cite interview}} will continually have to be tweaked to support new formats that arise. The CS1 suite would probably be simpler without {{cite interview}}. This may be due to a misunderstanding of the CS1 module on my part; I am not sure how cohesive the code for new templates would be with {{cite interview}}. This is where I welcome clarification and correction, as you have coded the CS1 module. E to the Pi times i (talk | contribs) 15:12, 19 March 2018 (UTC)

No, I wasn't talking about template replacement. I wasn't even talking about tweaks to the existing module suite to accommodate changes to {{cite whatever}} to make them 'smart enough' to do the 'right thing' in the presence of |interviewer=. I was musing about an entire redesign of cs1 and, though I didn't write about it, thinking about how such changes might effect downstream tools and other users.

Is there evidence to support your assertion that {{cite interview}} will need continuous tweaks?

Yes, cs1 would be simpler without {{cite interview}} but not by much (and we should probably continue to support it because en.wiki isn't the only wiki to use the cs1 module suite).

—Trappist the monk (talk) 23:52, 19 March 2018 (UTC)

In regards to your first question, I will have to look at how the LUA module is coded to be able to proficiently answer that. I'll get back to you.

By other wikis "using" it, do they literally copy every edit that's made to the module, or is it more direct? Regardless, en.wiki is the biggest WF wiki, so we would have the most work in implementing the change (in theory.) I think I will do some more research on this and get back to you, but you can reply to my comment if you have anything else to add. E to the Pi times i (talk | contribs) 10:48, 20 March 2018 (UTC)

This is a follow up to Help talk:Citation Style 1/Archive 31#Enable error tracking in draft space?

There's no reason why errors shouldn't be flagged and tracked in draft space. It's time to enable this. Headbomb {t · c · p · b} 16:27, 24 February 2018 (UTC)

Consensus was not obvious in that discussion. --Izno (talk) 17:32, 24 February 2018 (UTC)

No one gave any objection save "there would be a lot of errors", which is a rather silly objection given this is one of the main reasons for enabling the reasons tracking, and the initial exclusion was done for no given reason. Headbomb {t · c · p · b} 18:55, 24 February 2018 (UTC)

You entirely mischaracterize my comments there. Please go and review. --Izno (talk) 20:27, 24 February 2018 (UTC)

I've reread them multiple times, and that's still my reading of what you wrote. If that's not what you mean, feel free to clarify. Headbomb {t · c · p · b} 01:27, 25 February 2018 (UTC)

Well, most of the things in draft space generally get deleted in 6 months so it seems a waste to fix them..maybe a separate cat for non-mainspace errors? Galobtter (pingó mió) 19:11, 24 February 2018 (UTC)

But a lot of those are also moved to mainspace, and those aren't a waste. Especially since a lot of the stuff can be fixed relatively mindlessly by bots / AWB. Headbomb {t · c · p · b} 19:13, 24 February 2018 (UTC)

sandbox'd. Headbomb {t · c · p · b} 14:26, 22 March 2018 (UTC)

@ this talk page's article, My bad. unintentional, this may be how I learn to revert (vandalism or good faith), I'm all earsDeermouse (talk) 22:32, 25 March 2018 (UTC)

This cite template gives an "ASIN uses ISBN" error:

"General Hospital: Luke & Laura (Lovers on the Run) Vol. 1". Burbank, California: ABC Studios. February 2, 1994. ASIN 6303007759. Retrieved September 27, 2016.

Is this ASIN really an ISBN? It passes the checksum test, but I am unable to find any verification that it is really an ISBN. Here's another one:

"Clay Pigeon". PolyGram Filmed Entertainment. Universal City, California: Universal Studios. April 27, 1999. ISBN 6305353212. Retrieved November 21, 2016. {{cite web}}: Check |isbn= value: invalid group id (help)

"Clay Pigeon". PolyGram Filmed Entertainment. Universal City, California: Universal Studios. April 27, 1999. ASIN 6305353212. Retrieved November 21, 2016.

When I click to follow the ISBN link, I get nothing but dead ends, even using the Amazon link at Special:BookSources. When I follow the ASIN link for the same number, I get an Amazon page.

Wikipedia:WikiProject Check Wikipedia/ISBN errors shows these "ISBN" values starting with 63 as errors. I don't know what CheckWiki's methodology is.

List of ISBN identifier groups does not show a country for 10-digit ISBNs starting with 63. Neither does the International ISBN Agency. – Jonesey95 (talk) 14:34, 27 March 2018 (UTC)

The module doesn't 'know' that a 10-digit number is an ISBN except that the 10-digit number 'looks-like-an-isbn' because it passes the check digit test and doesn't have extraneous characters. I think that the help text at Category:CS1 maint: ASIN uses ISBN alludes to this. If we can say categorically that |asin=63... is not an isbn then perhaps we might tweak the module code to exclude such asin numbers from the category.

—Trappist the monk (talk) 15:02, 27 March 2018 (UTC)

i note recent conflict on reference using cite web in film article.

reference about aggregator website, example rotten tomatoes, metacritic, box office mojo. name of website usually go in work=, website=.

but some user do not like italic that work=, website=, put on name. they do following:

1. put italic in work=, like, work=''rotten tomatoes'', so show up on page with no italic.
2. move to publisher=, like, publisher=rotten tomatoes, so show up on page with no italic. but meaning maybe wrong.

does italic matter? does work=, publisher= difference matter?

discussion previous at Wikipedia talk:WikiProject Film#i comment about reference format. IUpdateRottenTomatoes (talk) 18:03, 27 March 2018 (UTC)

Oh, this discussion again. See:

Help talk:Citation Style 1/Archive 9#Italicization of websites in citations

Help talk:Citation Style 1/Archive 23#Adding a "disable italics on work" parameter?

these two discussion specifically mention Rotten Tomatoes but there may be others in the archives.

—Trappist the monk (talk) 20:39, 27 March 2018 (UTC)

i thank you for comment. i look in related discussion:

Wikipedia talk:WikiProject Video games/Archive 124#Assuming no change to CS1...

discussion has consensus to use work for rotten tomatoes but no italic in article context.

i find to be useful information. IUpdateRottenTomatoes (talk) 20:59, 27 March 2018 (UTC)

In the past I used the dead-url parameter (I think) to indicate that the URL for the citation no longer worked, and someone needed to look at it, i.e. find an archived version or a new version of the page. However, from reading the documentation and using it again now, it looks like this is no longer the intended usage of dead-url. It doesn't show up anywhere, there is no hidden category, etc. What is the correct usage of dead-url and what parameter can I use to indicate dead links? Or should it be in a separate {{dead link}} template? —Ynhockey ^(Talk) 12:33, 17 February 2018 (UTC)

I'm pretty sure that the use you describe was never the intended purpose of |dead-url= nor has that functionality ever been implemented. The parameter is ignored except when the cs1|2 template uses both |archive-url= and |archive-date=. There is no cs1|2-specific parameter to indicate that a url is dead so the {{dead link}} template should be used to do that (outside of the cs1|2 template).

—Trappist the monk (talk) 12:55, 17 February 2018 (UTC)

At one time it was a simple yes/no binary parameter, but nowadays has at least two more recognised values, see Help:Citation Style 1#Web archives and Template:Cite web#csdoc_deadurl. --Redrose64 🌹 (talk) 12:59, 17 February 2018 (UTC)

Thank you for this topic. This thread fixed my misunderstanding of that parameter too. This is a terribly misleading parameter name. If |dead-url= is intended to be used in conjunction with archived urls, the name should have reflected that to avoid obvious confusion by users. Jason Quinn (talk) 13:58, 17 February 2018 (UTC)

I agree and I think that I have argued elsewhere in these pages that it is a bad name because all other |<name>-url= parameters take urls as their assigned values. I have never gotten sufficient traction to deprecate |dead-url= and replace it with with something more appropriate. This morning I was thinking that |use-archive= might work. Anyone have a better name?

—Trappist the monk (talk) 14:10, 17 February 2018 (UTC)

I have privately supported your suggestion of url-state/url-status before. (Russian Wikipedia allows HTTP codes in the field as well, which might be an interesting addition here, especially for IABot.) --Izno (talk) 15:33, 17 February 2018 (UTC)

Suggest |archive-state= (or |archive-status= or |archive-display=) so that the three |archive-*= arguments are easier to remember and kept together as a set. It's also more clear referring to the state of the archive, and not the url, which is the main source of confusion. Should the archive come first or second in display is the underlying question. -- GreenC 19:46, 17 February 2018 (UTC)

Any of those would be preferable and it'd be splitting hairs to chose among them. I have a slight preference for |archive-display= among the three. In each case the association is much clearer. The problem with |dead-url= is that it looks self-explanatory (seeming to answer the question "does the url work?") but it is not. Jason Quinn (talk) 02:26, 18 February 2018 (UTC)

Previous conversations:

Help talk:Citation Style 1/Archive 11#Suppressing unnecessary archive-urls

Help talk:Citation Style 1/Archive 19#deprecate |dead-url=?

I don't think that the issue is the state of the archive but rather it's the state of the url which can be: live, dead, unfit, usurped, or unknown. This suggests that the parameter name must refer to the url somehow so parameter names like |url-state= or |url-status= (credit an IP editor for those names, not me) should be preferred over an |archive-*= name.

|dead-url= accepts yes, true, y, no, unfit, usurped, bot: unknown. If we shift to use |url-state=, then the accepted parameter values become: dead, live (the default), unfit, usurped, bot: unknown.

—Trappist the monk (talk) 12:56, 18 February 2018 (UTC)

The only problem is the same confusion factor comes into play. I don't see |url-state=dead as being more clear than |dead-url=yes in terms of clearing up the confusion what the argument is meant for. -- GreenC 19:56, 18 February 2018 (UTC)

So give us a better name. Here's another: |url-is= (dead, live, ...) Got anything better?

—Trappist the monk (talk) 14:34, 19 February 2018 (UTC)

I don't have a better name using "url" because the focus is on the url, and that will always lead to the same confusion (eg. "url is dead, marking it so"). When the focus is on the archiveurl it's more clear. I understand this leads to conceptual problems related to option-switches, they can be modified: |archive-disp=url-unfit, |archive-disp=url-dead, |archive-disp=url-live etc.. or drop the "url" part altogether. What the option-switches do is described in the docs, but the argument name makes it clear it is mainly being used for archive display, what most people use it for. -- GreenC 17:03, 19 February 2018 (UTC)

Also this kind of change will break a lot of third party tools that work on citations. In my experience how quickly and easily those tools get fixed (if at all) is an open question. I'm of the opinion keep it the same because it's not a huge problem if a stray |deadurl= gets added - my bot WaybackMedic removes strays, and Cyberpower678's IABot marks links dead regardless. -- GreenC 19:55, 17 February 2018 (UTC)

Certainly an abrupt change will break iabot and wayback medic but we don't do abrupt here. |dead-url= would be deprecated when the new parameter is implemented, and the two would operate in parallel (but not simultaneously) through the transition period – which could be quite long. A bot task could be developed to convert existing |dead-url= to the new parameter (iabot and wayback medic might implement that as well). At some point in the future when the count of articles using |dead-url= drops below an acceptable number, support for it is removed. This is, more-or-less, how we handle all deprecated parameters (which all have had the possibility of breaking external tools).

—Trappist the monk (talk) 12:56, 18 February 2018 (UTC)

I wasn't thinking too much of Medic and IABot as we are pretty responsive to changes but there are many other tools including proprietary ones from research institutions etc. Also, what would you think about keeping the argument as-is, and IABOt and/or Medic then act upon it when they see a |dead-url= with a missing or empty |archive-url=. They could assume the url is dead act accordingly (add an archive) - probably a safe bet in most cases since how else would a stray |deadurl= with a "yes" value get added unless a human thought the URL was dead. -- GreenC 19:56, 18 February 2018 (UTC)

I don't think that it is our responsibility to limit what we do here because of some external tool's dependency unless we have specifically committed to support that tool (as we have done for the metadata). It is entirely possible that we have no knowledge of these many other tools ... so it is the tool maintainers' responsibility to keep up with us and to join in these conversations to say why we should or should not do what we propose to do.

—Trappist the monk (talk) 14:34, 19 February 2018 (UTC)

Ok well the offer is still open to automate fixing this particular problem (stray |dead-url=) which I don't think is too common. I haven't been logging this, but just added logs so the next time it runs it will record how common it is within a set of articles (probably 100k to 200k articles will get processed). Granted, bot maintenance is not ideal as long-term is not guaranteed. -- GreenC 17:03, 19 February 2018 (UTC)

@Trappist the monk and GreenC: Another possible parameter which I don't see suggested above is |use-archive= (or |use-archive-url=, but I prefer the former). This would explicitely state what the parameter does, and because of the "use" verb, there is little opportunity for confusion (though if you see possible confusion, please tell me). This parameter could take true and false like |dead-url= currently does. E to the Pi times i (talk | contribs) 19:17, 19 March 2018 (UTC) Edit: I did not realize there were more than two parameters, otherwise I would not have suggested that. I am curious why those parameters were added, so I may go back and look at prior discussions. E to the Pi times i (talk | contribs) 22:20, 27 March 2018 (UTC)

The parameter value describes the condition, state, quality, take your choice, of the value assigned to |url=. The parameter isn't a boolean so the parameter name and all of its acceptable values 'should' read somewhat sensibly. I don't think that |use-archive=unfit is any better than |dead-url=unfit and neither (I think) are as good as |url-state=unfit (which would require new values dead and live in place of yes and no). Alas, |use-archive=yes conveys nothing about the 'why' we should be using the archive.

—Trappist the monk (talk) 00:20, 20 March 2018 (UTC)

I too am (a little) confused about |dead-url=. Looks like it was originally intended as a "yes"/"no" parameter to link the title to the original or archived URL (with the other being available). The values "usurped" and "unfit" were added to cover situations were the URL was still "live" but either was "usurped" by another unrelated site or a site "unfit" for viewing (and therefore no reason to view original site). I have encounter many sites that redirect an "unknown" page to another (usually "home") page on the site. A similar situation occurs when the referenced page contents change (e.g. "Home"). In both of these cases, I attempt to find an appropriate archive page and use |dead-url=yes to link the title to the archived page. I do not think this is the correct usage of this parameter. I do think the parameter should be renamed and appropriate values defined. I have a slight preference for |url-state= with values like: valid, dead, redirected, volatile, usurped, and unfit. usurped and unfitwould be two were the original link would need to be supressed.—User-duck (talk) 22:06, 27 March 2018 (UTC)

P.S. Remember, there can be more than one URL specified in some citation templates (e.g. {{cite book}})—User-duck (talk) 22:06, 27 March 2018 (UTC)

{{cite book}} has |url= and |chapter-url= parameters to link the specified URL with the appropriate field in the citation. Some archive websites provide access to the entire book and a URL for the entire book can be included. I assume the same is true for chapters as well. They may also provide access to a specific page. Google Books URLs often link to specific pages or portions of pages but seldom entire books. Editors have used |url= or |chapter-url= the for these URLs. I feel this is an incorrect usage of the parameter(s). I believe a |page-url= parameter would be useful for linking a specified page with a page URL. I have used several methods to work-around the issue, but they are work-arounds.—User-duck (talk) 23:00, 27 March 2018 (UTC)

Oh, this discussion again. See:

Help talk:Citation Style 1/Archive_23#About WP:PAGELINK

Issues you raise here have been raised there. The problem of multiple pages either as page-ranges, as comma-separated lists, or combinations of both is a substantial headache (and this doesn't address the issue of a page or range of pages that isn't (can't) be linked). I raise some of these issues in that other discussion.

—Trappist the monk (talk) 23:31, 27 March 2018 (UTC)

I've used "cite book" with "|isbn=1234567". Is there a way to make an automated bot built into wikipedia do research based on the quoted isbn number to fill in the author and publisher information? Thanks. Adrian816 (talk) 21:27, 28 March 2018 (UTC)

Interesting idea. Depending which source the bot uses it might come back with different information. It would take some testing to see how reliable it was. Like with author it sounds easy but can be complicated: multiple authors, editors, chapter authors, abbreviated names, author wikilinks, variations in spelling, non-Latin characters Latinized, use of "Jr" or "Sir", etc.. not impossible but not trivial and would take watching over. -- GreenC 21:43, 28 March 2018 (UTC)

This seems so general it must have been proposed before. I will go examine the archives... E to the Pi times i (talk | contribs) 23:19, 28 March 2018 (UTC)

Eh, I haven't found anything, but Trappist the monk is more knowledgeable about previous discussions, so he will give a definitive answer. E to the Pi times i (talk | contribs) 23:31, 28 March 2018 (UTC)

If you pull down the cite template at the top of your editing screen, and in the books option type in the isbn (or paste it) and then hit the magnifying glass symbol beside the typing space, it will fill in the majority of the information, if it is known. Not sure if that is the same as a bot, but it does fill in most of the information, unless it is a really new isbn, or one that has issues. SusunW (talk) 23:44, 28 March 2018 (UTC)

Yah, that and User:Citation bot, I think plus citoid via WP:VE. Do not trust them. Just because a tool did the citation filling, there is no guarantee that the result is correct. The tool may have filled the citation template but you are responsible for the citation's ultimate correctness. Can you tell that I have little respect for the tools? It isn't the tools so much as the data sources. There was some related discussion at Help talk:Citation Style 1/Archive 33#ISBNs in mw:Citoid.

—Trappist the monk (talk) 00:19, 29 March 2018 (UTC)

For book having isbn 978-0-85412-822-8, copyright of the Handbook of Doctrine published by the Salvation Army is held "in trust" by a specific employee of the organisation, the General. While wikipedia allows a number of types of information to be included like publisher, there's no tag for " |copyright=The General of The Salvation Army".

On the relevant page of the book is: c 2010 The General of The Salvation Army This edition published 2010

therefore full citation of this book needs to include the copyright holder and printing company name for wikipedia to have full information.

There's also "Printed by" information for this book, in this case "UK Territory Print & Design Unit".

Please can someone look into getting wikipedia software updated to include these tags: |copyright= |printed-by=

Thanks Adrian816 (talk) 22:29, 28 March 2018 (UTC)

No style guide ever requires presenting copyright information. Such information could be added to Wikidata I suppose, but they do not belong in citations. Headbomb {t · c · p · b} 23:02, 28 March 2018 (UTC)

I agree with Headbomb. Citations on Wikipedia are meant to allow the reader to verify and reference where the material came from. Each new parameter should aid in that identification, otherwise the templates would become overly difficult to use. The proposed parameters |copyright= and |printed-by= negligibly add to the ability to verify sources. E to the Pi times i (talk | contribs) 23:17, 28 March 2018 (UTC)

The copyright and printed by information isn't even cataloged at http://worldcat.org, nor would it likely be included in other catalogs, so it's not really germane to a citation. Imzadi 1979 → 23:21, 28 March 2018 (UTC)

When copyright is relevant, then it can be added by hand. For example, if the copyright on the Book of Mormon was owned by the Jehovah witnesses, then it would be worth mentioning. Otherwise meh. AManWithNoPlan (talk) 00:25, 29 March 2018 (UTC)

Just because it has not been done before doesn't mean that Wikipedia can not do as long as we don't engage in WP:OR. Traditional styleguides may focus on WP:paper and not electronic projects. Emir of Wikipedia (talk) 19:24, 29 March 2018 (UTC)

Just because something can be done does not mean it is good, let alone that it should be done. Copyright and printer data are generally non-significant bibliographically, and in any special cases where they are they can be handled specially. ~ J. Johnson (JJ) (talk) 20:02, 29 March 2018 (UTC)

• Oppose Absolutely not. No sane librarian would ask for this should you enquire for the source. Can you imagine it? "I'm sorry, we don't have the McSmith & Co printing - will the O'Jones & Son printing do?" or "We have it, but it's copyright level means that we can't show it to you - come back when you have a higher security clearance." Nope. --Redrose64 🌹 (talk) 21:00, 29 March 2018 (UTC)

Wow! We've really gotten a unanimous response to this request. I think Adrian816 gets the point, and there's no need to continue this discussion. E to the Pi times i (talk | contribs) 22:27, 29 March 2018 (UTC)

{{{lang}}} should be a shortcut for {{{language}}} as it would be much easier and when I write "language" I usually shorten it to "lang" anyway. – Nixinova ⟨ T | E ⟩ 04:07, 31 March 2018 (UTC)

Heading tweaked because templates in headings break links to section headings from watchlists, etc.

As for the topic at hand: meh. |language= does have the alias |in= which to me, is poorly chosen. I used to see it quite a lot in Category:CS1 maint: Unrecognized language when editors meant that a source was |in= some other larger work. I would be fine with deprecating |in= and then, if a shorter version of |language= is really needed, adding |lang=.

—Trappist the monk (talk) 10:49, 31 March 2018 (UTC)

I would support deprecating |in= as well as adding a |lang= as a synonym for |language=. --Izno (talk) 14:03, 31 March 2018 (UTC)

Seems reasonable to me too Galobtter (pingó mió) 14:09, 31 March 2018 (UTC)

I just fixed all three instances of |in= in {{cite web}}, and they were all being used incorrectly. Let's deprecate that one. – Jonesey95 (talk) 14:23, 31 March 2018 (UTC)

Support deprecating |in= and adding a |lang=. --Emir of Wikipedia (talk) 14:40, 31 March 2018 (UTC)

I have made a change to the configuration and whitelist sandboxes for both parameters. Addition of lang and deprecation of in. --Izno (talk) 14:55, 31 March 2018 (UTC)

Agree, |in= is confusing since it make it look like it refers to the "in Smith, J. (ed) Title part of an editor work. If |lang= us accepted as an alias (which I'm fine with), it should cover all templates, not just {{cite web}}. Headbomb {t · c · p · b} 18:50, 31 March 2018 (UTC)

Agree to deprecate |in=. I'm mildly against adding |lang=, though; it's unambiguous enough but I think there is enough unnecessary variation in parameter names already. —David Eppstein (talk) 19:35, 31 March 2018 (UTC)

Is it possible that a parameter name of lang was deliberately avoided? Commons and Wikidata, as the two WMF multilingual projects, support several schemes for display of multilingual content. For templates it is commons to use the Autotranslate mechanism and template, which uses the lang parameter. On Commons and Wikidata templates avoid assigning their own use to a lang parameter to avoid incompatibility with Autotranslate. Probably not a direct concern for CS1 on en.WP, and I don't think either Commons or Wikidata currently make use of CS1, but something to consider. —RP88 ^(talk) 19:38, 31 March 2018 (UTC)

Do they just use |lang= or |language= too? If it is just the former then it is something to consider, but if it is both then if it was really a big issue it would have been brought up anyway. Emir of Wikipedia (talk) 19:40, 31 March 2018 (UTC)

Autotranslate uses just |lang=. —RP88 ^(talk) 19:50, 31 March 2018 (UTC)

The citation

{{cite journal|first=D. J.|last=Struik|authorlink=Dirk Jan Struik|title= Het probleem 'De Impletione Loci'|year=1925|journal=Nieuw Archief voor Wiskunde|series=2nd ser|zbl=52.0002.04|volume=15|pages=121–134}}

appears as

Struik, D. J. (1925). "Het probleem 'De Impletione Loci'". Nieuw Archief voor Wiskunde. 2nd ser. 15: 121–134. Zbl 52.0002.04. {{cite journal}}: Check |zbl= value (help)

with an error message "Check |zbl= value (help)". I have checked the zbl= value, and it is correct. Please correct this so that the reference can be formatted with its correct zbl id. —David Eppstein (talk) 07:15, 3 April 2018 (UTC)

PS the other article in Category:CS1 errors: ZBL also has a valid |zbl=, Zbl 06684722, that the citation template again does not like. Where is the source for the information that this parameter must be of the form "nnnn.nnnnn"? Because apparently this is incorrect. —David Eppstein (talk) 07:23, 3 April 2018 (UTC)

Not a Zbl; that identifier is a JFM:

Struik, D. J. (1925). "Het probleem 'De Impletione Loci'". Nieuw Archief voor Wiskunde. 2nd ser. 15: 121–134. JFM 52.0002.04.

Original discussion.

—Trappist the monk (talk) 10:31, 3 April 2018 (UTC)

For the second one, see Help talk:Citation Style 1/Archive 39#8 digit ZBL and Help talk:Citation Style 1/Archive 36#Zbl error checking. It's a temporary assignment, which should be categorized in a maintenance category, but the request has been ignored for 6+ months now. Headbomb {t · c · p · b} 10:37, 3 April 2018 (UTC)

This help request has been answered. If you need more help, you can ask another question on your talk page, contact the responding user(s) directly on their user talk page, or consider visiting the Teahouse.

but the help page cite tweet doesn't have the infobox on the template. Can the infobox listing the different variations of cite... be added to the cite tweet page please. The infobox looks like a global template, but it lacks cite tweet Please fix the cite tweet help page, and amend the infobox on this help page to include cite tweet thanks Adrian816 (talk) 23:01, 3 April 2018 (UTC)

There are only very few instances where citing a tweet is appropriate. Thus I rather do not think widely advertising it is helpful. Besides, it's a specialized application of {{cite web}} that doesn't have any additional functionality but merely transforms a tweet's parameters such as user, number and title into input for that template. Thus it differs from the likes of {{cite web}}, {{cite book}}, {{cite podcast}} and so on which are all directly based on the same Lua module, Module:Citation. Huon (talk) 23:37, 3 April 2018 (UTC)

Mostly right. {{cite tweet}} is not a cs1 template because it does not directly use either of Module:Citation/CS1 or {{citation/core}}. For that reason, {{cite tweet}} is a meta template and meta templates do not belong in the cs1 'infobox'.

—Trappist the monk (talk) 23:46, 3 April 2018 (UTC)

I'd say that {{cite tweet}} does use Module:Citation/CS1, albeit indirectly because it is a wrapper for {{cite web}}, but that's not why I'd oppose listing it in the box. I'd call it a source-specific citation template, just like {{cite MDOT map}} is a wrapper for {{cite map}} and inputs all of the specific citation details for specific Michigan Department of Transportation paper maps. If someone had suggested that either source-specific template be added to the box, I'd object not he grounds that they don't fit due to the source-specific nature. Imzadi 1979 → 02:14, 11 April 2018 (UTC)

Hi all. As you probably noticed recently, the WMF released a dataset on the works cited on En-Wiki that included a few select identifiers (particularly ISBNs, WorldCat IDs and DOIs): https://blog.wikimedia.org/2018/04/05/ten-most-cited-sources-wikipedia/ . One of the challenges with this dataset: is that it only works, when their are identifiers including in citations. Could we create a tracking category, which helps identify citations from the Journal/Book citations that don't include any identifier? This could help empower community members to help better populate those citation data, so that future analysis could include more of our citations? Secondly to make this a manageable backlog: could we create a variable for citations in those sets for "no identifier available" -- which could allow folks to review the citation, and then confirm that it in fact can not be tied to an identifier (and put those items in another tracking category?) Generally Books and Journals should be things with some type of identifier, otherwise the templates are probably be used for the wrong thing (i.e. published reports or magazines, which should be cited using one of the more specific templates). Thanks much, Sadads (talk) 14:47, 14 April 2018 (UTC)

Why not start meta:WikiCite style and make sure that every publication and article which Wikipedia cites has a Wikidata item? Is there any conceivable less expensive, lower labor, and easier way? Blue Rasberry (talk) 15:09, 14 April 2018 (UTC)

@Bluerasberry: Personally, I think creation of the Wikidata items really ought to be driven by the identifiers -- so that we aren't creating an overwhelming number of duplicates. The tracking categories would definitely be the most low-labor way to do this, without introducing messy citation data into Wikidata -- remember most of the fields in En-Wiki citations are not used consistently. Sadads (talk) 16:07, 14 April 2018 (UTC)

@Sadads: What kind of identifier are you imagining? Are you not imagining Wikidata items as identifiers? How would you assign and manage a set of identifiers if not with Wikidata? Blue Rasberry (talk) 16:16, 14 April 2018 (UTC)

I am mostly interested in the items that _don't yet have identifiers_ which likely need to be cleaned up-- and need to have more consistent metadata before we import it into Wikidata. A tracking category doesn't prevent us from importing to Wikidata, but it can empower contributors on English Wikipedia. Sadads (talk) 16:22, 14 April 2018 (UTC)

I'm concerned, especially in the case of ISBNs, that if there is no ISBN, the citation may not contain enough information to positively identify which version of the book is being cited. In that case it would be necessary for an editor to obtain the book and see if the cited page actually supports the claim, in which case the ISBN from the book could be added. If the verification fails, we must consider the possibility that the cited page in some other version of the book supports the claim. Jc3s5h (talk) 17:38, 14 April 2018 (UTC)

I can point to plenty of older (pre-ISBN) books and (typically open access) reputable journal papers with no identifier. Although I think we should add ISBNs and DOIs when we have them, I worry that these categories are going to be overflowing with non-problematic articles. —David Eppstein (talk) 18:16, 14 April 2018 (UTC)

@David Eppstein and Jc3s5h: This is why I am suggesting that any tracking category be paired with a variable that allows folks to say that they "have checked and can't find an appropriate ID" -- we have something like this for Template:Orphaned article -- allowing a documented date for when something was an attempted de-orphan. That said, there are also other identifiers that might be an adequate fit for each item such as OCLC WorldCat ID, JSTOR id, or another id (say something from EEBO online, for instance, that could be a perfectly adequate using the existing "id=" property ). The goal is to identify some unique, stable version of the object, that we can point to so that we could, for example, integrate it into Wikidata eventually, or export the data as part of the WMF research pointed at above, which empowers folks like Internet Archive to digitize the books or find open access versions, so that we can in fact verify the content. Sadads (talk) 23:19, 14 April 2018 (UTC)

I am working with an editor at bn.wiki to implement the cs1|2 module suite there; discussion on my talk page.

I have moved the definitions of the various separator and postscript characters out of Module:Citation/CS1/sandbox into the presentation table in Module:Citation/CS1/Configuration/sandbox.

Because Bengali does not use western style digits, and also because Lua does not understand non-western digits, a couple of tweaks were necessary to support enumerated parameter names written wholly in Bengali.

These changes should be transparent to the en.wiki module suite:

—Trappist the monk (talk) 12:34, 14 April 2018 (UTC)

More. The cs1|2 module suite has the capability to do rudimentary English month-name to local month-name translation using names provided in the local wiki's copy of /Configuration. I have extended that so that it will also translate western-style digits to local-language-style digits. Because date translation is disabled at en.wiki, this change is not visible here.

—Trappist the monk (talk) 12:19, 17 April 2018 (UTC)

And more. /Date validation/sandbox is tweaked so that Unicode digits in YMD dates aren't mistaken for text when quietly converting hyphens to dashes.

And yet more. /Date validation/sandbox at en.wiki is currently broken. When dates fail validation at bn.wiki or other wiki's that allow for non-English parameter names, the error message always returns the failing parameter's English alias even when the parameter name used in the template was not the English alias. I think that this issue is partially resolved but for some date parameters, notably |publication-date= and |year=, both of which, when used alone in a cs1|2 template are promoted to |date=, are returning incomplete error messages:

{{cite book/new |title=Title |publication-date=99}}

Title. 99. {{cite book}}: Check date values in: |publication-date= (help)

{{cite book/new |title=Title |year=c 2000}}

Title. c 2000. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

It is a puzzlement.

—Trappist the monk (talk) 21:49, 7 May 2018 (UTC)

@Trappist the monk: wrote "And more. /Date validation/sandbox is tweaked so that Unicode digits in YMD dates aren't mistaken for text when quietly converting hyphens to dashes." I have a review copy of the next ISO 8601 standard; existing versions have influenced (but don't necessarily define) English Wikipedia's YMD dates. The word "dash" is not present in the standard. "Hyphen" and "hyphen-minus" are mentioned. "Hyphen" is used to separate date elements; "In an environment where use is made of a character repertoire based on ISO/IEC 646, 'hyphen' and 'minus' are both mapped onto 'hyphen-minus'."

Unfortunately the standard does not give Unicode values for any of these characters. I hope whatever you're doing is consistent with this. Jc3s5h (talk) 23:08, 7 May 2018 (UTC)

Sigh. You have often written that ISO 8601 has not been adopted by en.wiki (here is one such place) yet here you are invoking ISO 8601?

Regardless, you misunderstand what cs1|2 means by quietly converting hyphens to dashes. See this discussion.

At bn.wiki ymd dates can look like this:

|date=২০১৮-০৫-০৭

As the code was previously written, there was a string.match() function looking to match the pattern '%d%d%d%d%-%d%d%-%d%d' which worked fine as long as the digits were western (0–9) single-byte digits (because the Lua string library operates on bytes). But, Bengali digits are three bytes each. Here is the percent encoded version of the example date:

%E0%A7%A8%E0%A7%A6%E0%A7%A7%E0%A7%AE-%E0%A7%A6%E0%A7%AB-%E0%A7%A6%E0%A7%AD

The problem experienced at bn.wiki was that the module did not recognize ২০১৮-০৫-০৭ as a ymd date so it silently converted the hyphens to endashes giving this result:

২০১৮–০৫–০৭ (hyphens from the template converted to endashes; rendered citation added to the bn.wiki equivalent of our Category:CS1 maint: Date format maintenance category)

The fix for this particular problem was to change string.match() to mw.ustring.match() which operates on Unicode characters, so that ymd format dates are recognized and skipped when the module does the hyphen conversion.

—Trappist the monk (talk) 00:10, 8 May 2018 (UTC)

Something I noticed re translators and periods, as a heads up:

{{cite journal|last=Author|first=A. |translator-last=Translator|translator-first=T. |title=Title|journal=Journal|date=2018|volume=1|page=100}}

Author, A. (2018). "Title". Journal. 1. Translated by Translator, T.: 100. {{cite journal}}: |last= has generic name (help)

{{cite journal|author=Aut.–A.C.R.O.N.Y.M. |translator=Transl.–A.C.R.O.N.Y.M. |title=Title|journal=Journal|date=2018|volume=1|page=100}}

Aut.–A.C.R.O.N.Y.M. (2018). "Title". Journal. 1. Translated by Transl.–A.C.R.O.N.Y.M.: 100.

The "extra" full stop gets removed if |first= or |author= ends with a period but the same fix hasn't been yet been applied to |translator-first= or |translator=.

I'm also not sure off the top of my head of a real source that might need to be cited as such (but it's within the realm of possibility), but I also just now discovered if there is no listed author, but is a listed translator, there is an errant period at the beginning:

{{cite journal |translator-last=Translator|translator-first=T. |title=Title|journal=Journal|date=2018|volume=1|page=100}}

"Title". Journal. 1. Translated by Translator, T.: 100 2018. {{cite journal}}: |translator-last= has generic name (help)

Thanks, hopefully this is of use :) Umimmak (talk) 10:33, 25 April 2018 (UTC)

Also applies to |others= and |interviewer= and only for {{cite journal}} and {{citation}} when a 'work' parameter is set (though for this case, it isn't an issue for {{citation}} because the element separator is a comma). Fixed, I think in the sandbox:

For completeness, one more, this time initials without terminal punctuation:

—Trappist the monk (talk) 12:29, 25 April 2018 (UTC)

@Trappist the monk:After looking into this i found a problem on bn wiki. Please take a look here. --আফতাব (talk) 17:22, 25 April 2018 (UTC)

Fixed, I think. This fix changed code at en.wiki. The function safe_join() uses a series of Lua pattern matching string functions to do its work. The Lua string library works well at en.wiki becase our terminal characters are all single byte characters. At bn.wiki, the terminal character is the dari ('।', Unicode U+0964 Devanagari Danda) which is a three-byte character. For safe_join() to properly recognize that character requires that we use the Ustring library function which are significantly slower than their equivalent String library function. So that en.wiki doesn't take a performance hit and to make the code compatible with bn.wiki and others that use multi-byte terminal characters, safe_join() now inspects the terminal character and chooses the appropriate library functions before it does its work.

One of these days, when time allows, I very much want to rewrite how we assemble the elements of a rendered citation so that safe_join() is no longer required...

—Trappist the monk (talk) 10:52, 26 April 2018 (UTC)

|chapter= has these aliases: |contribution=, |entry=, |article=, and |section=.

Associated with |chapter= are: |chapter-format=, |chapter-url=, and |chapter-url-access=. We should have similar parameters for all of the |chapter= aliases but don't.

I have added these to Module:Citation/CS1/Configuration/sandbox:

|entry-format=, |article-format=

|entry-url=, |article-url=

|contribution-url-access=, |entry-url-access=, |article-url-access=, |section-url-access=

—Trappist the monk (talk) 11:47, 24 May 2018 (UTC)

An editor from Australia brought up an interesting point in this discussion that the |archivedate= can actually pre-date the publication of the underlying source due to time zone shifts. For example a news report published noon Monday in Australia might have an |archivedate= of Sunday, which is nonsensical (archive.org is located in San Francisco and probably uses GMT). So the editor has been entering the day they created the archive relative to their location in Australia, which then gets changed by bots trying to keep the snapshot date in sync with the |archivedate= (example). The source of the confusion appears to be the CS1 documentation which ambiguously says "Date when the original URL was archived" .. is the date relative to the archive service provider or the archiving user location?

As I see it, there's no reason to record when the editor created the archive (information more often than not unknown since the archive was created by someone else); the reader only needs to know the webarchive service date so they know how to retrieve it, the only purpose of having a |archivedate=. As such, would it make sense to change the documentation to reflect that dates are relative to the service provider date. -- GreenC 15:25, 19 April 2018 (UTC)

The current wording has been in place since this edit in February 2013. I suppose that it might be changed to something like:

Archive-service snapshot-date; preceded in display by default text "archived from the original on". Use the same format as other access and archive dates in the citations. This does not necessarily have to be the same format that was used for citing publication dates.

I suspect that we might similarly change the documentation for |archive-url= to include the word 'snapshot':

The URL of an archived snapshot of a web source, if or in case the url becomes unavailable. Typically used to refer to services like WebCite and the Internet Archive; requires archive-date.

—Trappist the monk (talk) 21:33, 19 April 2018 (UTC)

Specifying the word "snapshot" is a clear and simple solution. -- GreenC 21:50, 19 April 2018 (UTC)

I added this. Took the opportunity to additionally add "templated dates are discouraged" since it is also documented elsewhere due to COIN data. -- GreenC 02:53, 21 April 2018 (UTC)

Was there a reason that you chose not to modify the |archive-url= documentation?

—Trappist the monk (talk) 03:01, 21 April 2018 (UTC)

No I just forgot :) Done. I added archive.is to the list, the "big three" archive services in use on EnWiki are Wayback, WebCite and Archive.is in terms of total usage. -- GreenC 03:10, 21 April 2018 (UTC)

Since this module is being continuously copied and overwritten to wikidata, I guess this is the place to report errors of that copy as well. On Wikidata the id_handlers cannot provide a valid sitelink by the code:

text = external_link_id({link = handler.link, label = handler.label, prefix=handler.prefix,id=id,separator=handler.separator, encode=handler.encode, access=access}) .. (inactive or '')

"handler.link" just doesn't work on Wikidata. The QID should be also provided in Module:Citation/CS1/Configuration, and link is compiled as something like "d:QID". Of course a site server checking would also be needed to be able to decide which link configuration to use:

_linkconfig = string.match(mw.site.server, "wikidata") or "sitelink"

--Pzgulyas (talk) 15:14, 20 March 2018 (UTC)

Continuously copied and overwritten to wikidate? (emphasis mine) What do you mean by that?

Can you show a real-life example of what doesn't work? What do you mean by: "handler.link" just doesn't work on Wikidata?

—Trappist the monk (talk) 16:27, 20 March 2018 (UTC)

As far as I can tell, the CS1 module code was imported to Wikidata on March 10, via Special:Import, which imports the (misleading, as a result of the import) edit history from en.WP. The import appears to have been a result of this request. See the history for wikidata:Module:Citation/CS1 to see an example of the results of the import. If the module doesn't work on wikidata, I would think that the way to address that problem is to troubleshoot it there, make the necessary fixes, and then return to this forum to recommend changes that would allow the module to function on wikidata without breaking other WP instances that periodically copy this module. – Jonesey95 (talk) 19:35, 20 March 2018 (UTC)

I added a real-life example to d:Wikidata:Sandbox, please see the red links. Please also try changing the display language to something different than English, which highlights another malfunction: The property P577 (publication date) should be queried in language-independent manner in Cite Q template, the simpler {{#property:P577|from={{{1}}}}} doesn't work in Wikidata well.--Pzgulyas (talk) 11:46, 21 March 2018 (UTC)

You did not answer my continuously copied... question.

I confess that I know little about wikidata.

The red links occur because wikidata does not have articles to which the identifier labels can link:

d:Digital object identifier

d:PubMed Central

d:PubMed Identifier

d:Wikidata

This is the expected behavior, isn't it? The lack of targets at wikidata is not necessarily the fault of the module; wiki links need a target. Were wikidata like en.wiki, clicking on a redlink would take us to an article-creation page so that the identifier link might no longer be red. That is not an option at wikidata.

Dates are problematic. The date validation code was written to ensure that dates in cs1|2 templates comply with the rules of the en.wiki MOS. For en.wiki that means that date names must be in English, meet certain requirements for form and punctuation, etc. There are crude facilities to support other languages when the module suite is used at other-language wikis but often editors there must modify the code as necessary to support their local date formats. The various wikipedias are language specific; wikidata is not so presents a complication.

Questions and comments concerning {{cite Q}} should be directed to Template talk:cite Q. That template fetches data from wikidata and then hands it off to {{citation}} for rendering. {{citation}}, Module:Citation/CS1, and associated modules do not use wikidata for anything.

—Trappist the monk (talk) 13:09, 21 March 2018 (UTC)

@Trappist the monk:: Don't feel be opposed, I'm trying to answer your questions one-by-one:

• continuously copied...: I mean, it was copied in the past, and any changes on wikidata will be overwritten from enwiki in the future.
• The red links occur because...: I know the reason why they occur, but the fix should be done in this software. E.g. the link that points here to Digital object identifier on wikidata should point to d:Q25670. Currently the Q number is not available in the Module:Citation/CS1/Configuration, and should be added.
• This is the expected behavior, isn't it?...: No, the expected behavior is that they point to the correspondig wikidata Q object.
• Dates are problematic. (...) editors there must modify the code as necessary to support their local date formats...: Here the case is different. There is no need to support local date formats, only when reading the date property, it must be ensured that the data is passed in a way that the rest of the code understands. Querying the property with #property:P577 is not appropriate, this must be replaced by a piece of lua code.
• Questions and comments concerning (...) should be directed to...: You are right about {{cite Q}}, but the problem is caused by the codes in Module:Citation/CS1/Configuration and Module:Citation/CS1/Identifiers, both of which talk pages are redirected here, I guess for the sake of keeping the discussion in a centralized place.

--Pzgulyas (talk) 13:41, 21 March 2018 (UTC)

If the Cite Q template or the CS1 module doesn't work on wikidata, editors should troubleshoot it there, make the necessary fixes, and then return to this forum to recommend changes that would allow the module to function on wikidata without breaking other WP instances that periodically copy this module. – Jonesey95 (talk) 13:57, 21 March 2018 (UTC)

Let's set aside dates for the moment and just think about identifier labels. Are you saying: change from:

[[Digital object identifier|doi]]

to:

[[d:Q25670|doi]]

Really? Editors opposing the use of wikidata at en.wiki have often complained that data presentation at wikidata is unacceptable for this encyclopedia's readers. Is there a way to fetch a page name from wikidata's list of wikipedia articles appropriate to the local wikipedia? For use at wikidata, how can the module know the user's display language setting?

—Trappist the monk (talk) 14:25, 21 March 2018 (UTC)

Pinging Pigsonthewing, who might be able to contribute positively to this discussion or help move it to a more appropriate forum. – Jonesey95 (talk) 14:36, 21 March 2018 (UTC)

A partial answer to my questions (for doi) might be:

1. this_wiki_code = mw.language.getContentLanguage():getCode()
2. article = mw.wikibase.getEntity ('Q25670'):getSitelink (this_wiki_code .. 'wiki')
3. link = '[[' .. this_wiki_code .. ':' .. article .. ']]'

So, for Spanish wiki:

1. sets this_wiki_code to 'es'
2. sets article to 'Identificador de objeto digital'
3. puts it all together: link = '[[' .. 'es' .. ':' .. 'Identificador de objeto digital' .. ']]' → [[es:Identificador de objeto digital]] → es:Identificador de objeto digital

But, I don't know if this works for wikidata. At wikidata, this_wiki_code = mw.language.getContentLanguage():getCode() for me, sets this_wiki_code to 'en' regardless of user preferences language setting.

—Trappist the monk (talk) 16:26, 21 March 2018 (UTC)

I've tweaked Module:Citation/CS1/Configuration/sandbox and Module:Citation/CS1/Identifiers/sandbox so that identifier label links are taken first from wikidata (if available) else from the local configuration. In this example, the code gets links for the doi and pmc labels from wikidata; the pmid label link uses the locally defined link (this because there are several, apparently similar, pmid 'Q' values, none of which seems appropriate for this use). You can know that the code worked correctly because the doi and pmc labels use interwiki links and pmid does not:

—Trappist the monk (talk) 14:15, 22 March 2018 (UTC)

If it is decided going this way, language code on wikidata can be queried by print(mw.getCurrentFrame():preprocess('{{int:lang}}'))--Pzgulyas (talk) 09:02, 22 March 2018 (UTC)

Thanks for that. Too bad {{int:lang}} doesn't work at en.wiki; → ⧼lang⧽. The tone of your post suggests to me that you believe that the 'partial answer' that I described above is: wrong? flawed? misguided? something else? If that is your belief then what is the better way?

—Trappist the monk (talk) 14:15, 22 March 2018 (UTC)

I'm really sorry for my previous short answer, I like your solution. Just I wrote from work office, and suddenly some work appeared to be done, so I apologize. I think what you have done, is the right fix. I think for the language code querying method selection you may use some test like string.match(mw.site.server, "wikidata") --Pzgulyas (talk) 10:11, 23 March 2018 (UTC)

Tweaks to d:Module:Citation/CS1/Configuration and d:Module:Citation/CS1/Identifiers (also to the en.wiki sandboxen). See d:Wikidata:Sandbox. The code renders redlinks when the wiki that corresponds to the interface language does not have a matching article. I suppose that we could force a link to en.wiki but I'm not sure that that is the correct thing to do.

—Trappist the monk (talk) 10:29, 23 March 2018 (UTC)

I have hacked d:Template:Cite Q and d:Module:Citeq so that dates extracted from wikidata are always rendered dmy in English regardless of the user's interface language choice.

While doing that, I wondered if it was even necessary. What protections does wikidata provide? Are dates in wikidata validated and so guaranteed to be correct? If so, then much the cs1|2 date validation is not required for dates taken from wikidata. But, it's still problematic because editors can override |date= in {{cite Q}}; can still provide |access-date= so these must be validated.

—Trappist the monk (talk) 11:05, 24 March 2018 (UTC)

Time zones are faulty in Wikidata. Thus all dates with day precision are suspect, except in the time zone of 0° longitude in winter. This has been discussed in many places, including mediawikiwiki:Talk:Wikibase/Indexing/RDF Dump Format. Jc3s5h (talk) 12:05, 24 March 2018 (UTC)

That may be true, but isn't all that relevant to the question; which could perhaps have been clearer. cs1|2 cares that dates are real dates and are written using MOS acceptable formats. What I want to know is: does Wikidata prevent editors from entering malformed dates: 25 Bob 2013? The answer to the question, apparently is yes; except for the weirdness that converts 29 February 2015 to 1 March 2015. That result is wrong because the input was wrong. But, simply replacing a date that doesn't exist with a date that does exist merely masks the error. To their credit however, Wikidata does show the 'converted' date at the time of editing giving editors a chance to correct. Are there other weirdnesses?

—Trappist the monk (talk) 11:41, 25 March 2018 (UTC)

Thank you Trappist the monk, very useful to fetch the DOI and PMC IDs from Wikidata items where available. --Nemo 16:44, 22 April 2018 (UTC)

I think we should allow in press and forthcoming preprints to be cited on Wikipedia, at least if a public URL is available for WP:V. Currently, cite templates produce an error message if "In press" is used with the date parameter of these templates. I propose that

1. "In press" and "Forthcoming" be allowed parameters for |date= in citation templates. I think this involves changing function check_date in Module:Citation/CS1/Date validation
2. If |date= is "In press" or "Forthcoming", citation templates display an error message if access-date is empty, and show the access-date parameter even if no URL is given. This is a new use for |access-date=, but I think it is better than creating a new parameter just for this purpose.
3. A tracking category be used for old values of access-date have dates of "In press" or "Forthcoming" to assist in completing these citations and filling in the final publication date. Of course, there is a potential issue of differences between preprints and final publication versions, and we might consider how to encourage editors to verify citations.

I suggest that proposal 3 depends on proposal 2, and proposal 2 depends on proposal 1, but proposal 1 does not depend on 1 or 2. What do others think? Daask (talk) 11:55, 23 April 2018 (UTC)

If it is "in press" or "forthcoming", it is not published, no? --Izno (talk) 13:26, 23 April 2018 (UTC)

@Izno: Incorrect. Many journals (I think primarily commercially published ones) have a multi-year waiting period for actual publication, but put their final-version papers online much earlier. This can also happen when a special issue is still being assembled but some of its papers have already been accepted. They are citable, in that they have been certified by the journal as having gone through peer review, are in their final edited form, and even have an official doi, but they don't yet have an official publication date, volume number, or page numbers. We should make it easy both to cite such works and to find them later and fill in the publication details once they become available. —David Eppstein (talk) 18:32, 24 April 2018 (UTC)

• As I recall The New York Times has often published online with tomorrow's date as the "date=" timestamp, and so "accessdate=" could predate the "date=" value. -Wikid77 (talk) 23:51, 23 April 2018 (UTC)

More and more, book chapters are published electronically and have their own doi. we already have parameter chapter-url; in my view it would be useful to have chapter-doi as well. Is that do-able? thanks. Jytdog (talk) 18:10, 28 April 2018 (UTC)

Why not just always cite one doi, the most specific one applicable to a given reference? I don't think adding more line noise to our citations is beneficial to our readers, and in all the cases your suggestion considers, if we provide only the link to the chapter, the readers will not have difficulty finding from it the link to the whole book. —David Eppstein (talk) 18:32, 28 April 2018 (UTC)

Yeah this is what I've always done, it seems redundant to have a DOI for the book if there's a DOI for the chapter. In the exceptionally rare case where it isn't redundant, maybe the book is available on two completely different websites with different paywall systems and it would be beneficial to the reader to have more options, one can always use |id={{doi}} to provide a second option. But I can't see a reason for systematically including the book DOI if the chapter DOI will easily lead the reader to the same place in a click or two. Umimmak (talk) 14:42, 29 April 2018 (UTC)

There is a discussion at Template talk:Cite tweet#Non text tweets about citing tweets that contain links, images, etc. Please comment over there. wumbolo ^^^ 14:57, 29 April 2018 (UTC)

I updated the documentation of the |issue= parameter to account for cases like "#293, Vol. 24, No. 5" (i.e., two different kinds of issue numbering), by adding the instruction "When a total issue number and an issue within a volume are both given – e.g., "#293, Vol. 24, No. 5" – this can be coded as |volume=24|issue=5 [total issue #293]." [1]; the documentation has for years already accounted for issue naming, with "When the issue has a special title of its own, this may be given, in italics, along with the issue number, e.g. |issue=2, ''Modern Canadian Literature''." This was not only reverted, but the revert included removal of both of these instructions, with an edit summary that doesn't make much sense to me: "no; abusing |issue= is no substitute for abusing |page=; one piece of information per parameter" [2]. Using |issue= for issue information is not "abuse" of the parameter, it's what the parameter exists for. Nor is there any principle here of "one piece of information per parameter", or we'd have separate parameters for middle names of authors, separate parameters for countries of city locations, separate parameters for days and months in dates, separate parameters for subtitles, and so on.

The problem to solve is that people are randomly actually abusing completely unrelated parameters like |page= and |publisher= to try to shoe-horn complex issue information into the template, when it obviously belongs in |issue=. But not obviously enough, or people wouldn't be doing that and we wouldn't need to have clearer documentation.

The only other alternative it to introduce yet more parameters for such things, and I think that's a terrible idea. So, I think this version should be restored.  — SMcCandlish ☏ ¢ 😼  12:28, 5 February 2018 (UTC)

I concur with SMcCandlish. Jc3s5h (talk) 16:20, 5 February 2018 (UTC)

That was me. It is not correct for us to 'permit' the misuse of a parameter just because editors have abused another parameter. The correct approach to the cumulative-issue-number vs. volume-issue-number question is to permit either but not both and to proscribe |volume= when a cumulative issue number is supplied in |issue=. For the issue-number-issue-title question, we have two fundamentally different pieces of information: the number is the basic descriptive unit typical of almost all periodicals and issue titles are generally rare special cases where the title merely supplements the issue number. Choose one, do not include wiki markup because the value assigned to |issue= is made part of the metadata.

No we would not have separate parameters for author middle names because we we have no need for that granularity; same for country location; same for dates. The question of subtitles is vaguely similar to the issue-number-issue-title question. There have been occasional requests here for a subtitle parameter but the community (not necessarily me) have rejected that, ostensibly because subtitles are merely extensions of the title. One might stretch the subtitle-as-title-extension point to argue that we should permit extension of issue number with issue title. I do not think that we should; extending a title with more title text is not the same as extending a sequence number with wiki markup and title text.

I don't see much value in the inclusion of issue titles in a citation. If the primary purpose of a citation is to help reader locate source material taken from a periodical, volume, issue, and date are much more likely to be helpful than an issue title. Further, it is the duty and obligation of the cs1|2 templates to render the correct style for each parameter. The only parameters that should use wiki markup are |title= and |chapter= (and their aliases) because titles often mix upright and italic fonts for good reason (scientific names, for example).

—Trappist the monk (talk) 12:09, 6 February 2018 (UTC)

I think the simplest way to handle this would be to not consider |number= and |issue= aliases when they are both listed. Or at least you could have |number-issue=yes to overide them being considered aliases. This way you could use

• {{cite magazine|author=A. Uthor |year=2010 |title=Things and stuff |magazine=Magazine Weekly |volume=7 |issue=245 |number=5|pages=24–445 |number-issue=yes}} to generate
• A. Uthor (2010). "Things and stuff". Magazine Weekly. Vol. 7 no. 5. #245. pp. 24–445. (or alternatively)
• A. Uthor (2010). "Things and stuff". Magazine Weekly. Vol. 7 no. 5. iss. 245. pp. 24–445.

or

• {{cite journal|author=A. Uthor |year=2010 |title=Things and stuff |journal=Magazine Weekly |volume=7 |issue=245 |number=5|pages=24–445 |number-issue=yes}} to generate
• A. Uthor (2010). "Things and stuff". Journal Weekly. 7(5, #245): 24–445.

This would solve a crapton of issues. Headbomb {t · c · p · b} 17:51, 21 March 2018 (UTC)

@Trappist the monk: could you help here? Headbomb {t · c · p · b} 14:43, 30 April 2018 (UTC)

On the page Yang Jisheng (statesman), there is a possible issue with the citation for the article "Lǐ Dàzhāo de Zuòyòumíng", which possesses an original title that uses Chinese characters. This does not appear to be merely a problem with my computer or browser, as I have tried multiple examples of each. The template {{Cite web}} was used for that particular citation. Between "Lǐ Dàzhāo de Zuòyòumíng" (title) and the same in Chinese characters (script-title) there appears to be a line break where there should not be one. Do other users observe the same issue? (Is this a problem in other articles?) Please advise if script-title is broken or if I am overlooking a simple solution. Simply removing the parameter script-title might solve the problem, but it is an issue if our citations are unable to display Chinese text. RexSueciae (talk) 21:51, 29 April 2018 (UTC)

I observe the issue too. Attempted to fix it and on the preview it looked like the issue had resolved, but then I must have changed what I did as when I saved it wasn't fixed. Emir of Wikipedia (talk) 22:22, 29 April 2018 (UTC)

I have double checked, when I do a preview it shows one online but after saving it doesn't. --Emir of Wikipedia (talk) 22:28, 29 April 2018 (UTC)

@Trappist the monk set it right! Thank you, friend. RexSueciae (talk) 22:43, 29 April 2018 (UTC)

Reduce the citation to just a wikilink:

[http://cpc.people.com.cn/BIG5/64162/64172/85037/85038/7104292.html "Lǐ Dàzhāo de Zuòyòumíng" <bdi lang="zh" >李大釗的座右銘</bdi>]

Place it directly at the left margin in show preview (for me) splits the wikilink at the <bdi>...</bdi> tag:

"Lǐ Dàzhāo de Zuòyòumíng" 李大釗的座右銘

Indent with definition list markup (:):

"Lǐ Dàzhāo de Zuòyòumíng" 李大釗的座右銘

renders correctly.

Same experiments, but replace <bdi>...</bdi> with <span>...</span>:

"Lǐ Dàzhāo de Zuòyòumíng" 李大釗的座右銘

Indent with definition list markup (:):

"Lǐ Dàzhāo de Zuòyòumíng" 李大釗的座右銘

Both render correctly in show preview. Saving this page now to see what happens.

—Trappist the monk (talk) 22:47, 29 April 2018 (UTC)

But ... but ... Argh. So I saved my edit above and both the <bdi>...</bdi> and <span>...</span> tests whether against the left margin or indented rendered correctly. As a further experiment, I null edited the page and got a different result: same as I get in show preview. It is interesting that in show preview, the Chinese characters in <bdi>...</bdi> (indented) are not part of the wikilink when they should be.

I'm seeing this with the latest Chrome browser (only one on my machine).

I can only conclude that this is not a |script-title= issue but appears to be a mediawiki issue with <bdi>...</bdi>. Perhaps I'll think on this some more and then take it to WP:VPT

—Trappist the monk (talk) 23:01, 29 April 2018 (UTC)

At WP:VPT.

—Trappist the monk (talk) 13:14, 30 April 2018 (UTC)

Thanks for clarifying Trappist the monk. I should have realized something was up when my preview differed. Emir of Wikipedia (talk) 20:18, 30 April 2018 (UTC)