Help talk:Citation Style 1/Archive 42

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

talk | contribs

) 23:19, 28 March 2018 (UTC)

Eh, I haven't found anything, but

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

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

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.

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

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

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

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

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)

JFM 52.0002.04

.

Original discussion.

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

For the second one, see

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)

@

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)

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)

@

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

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

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

@

b

} 14:43, 30 April 2018 (UTC)

On the page

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

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