Help talk:Citation Style 1

Using names of months

i have two connected problems on Cite news on cywiki: 1. When I copy this most recent version to our older module on cywiki, it causes an error which I'm unable to correct and 2. The date format on cywiki is always dd name of month yyyy (eg 19 Gorffennaf 2017), but as you can see on cy:Alfred Russel Wallace we can only use yyy-mm-dd (eg 2017-07-19). Any help would be warmly received! Llywelyn2000 (talk) 04:40, 22 July 2017 (UTC)

@Llywelyn2000: What is "an error which I'm unable to correct"?

Does the date format problem only happen with cy:Template:Cite news, or does it affect cy:Template:Cite web as well? Is it only the |access-date= parameter, or |date= as well? What happens if you use English-language dates like 19 July 2017 - does the problem disappear? --Redrose64 🌹 (talk) 08:30, 22 July 2017 (UTC)

I'm also perplexed. You said this most recent version by which I would expect the 28 May 2017 version of the module suite. But, at cy.wiki, the date there looks to be 26 May 2016.

Tracked in Phabricator
Task T21412

The |access-date= validation at cy.wiki does not work because the MediaWiki time parser does not understand non-English month names. Try this in your sandbox at cy.wiki:

{{#time:U|5 Ebrill 2007}}

then try this:

{{#time:U|5 April 2007}}

you should get:

{{#time:U|5 April 2007}} → 1175731200

Because this problem exists in all non-English wikis, all versions of the module suite since 30 July 2016 have a fix for the problem.

What is your intent? Do you want to just fix your version of your older fork of the module suite? Do you want to the cy.wiki module suite to track the en.wiki modules?

I can see that someone has copied en:Module:Citation/CS1/Date validation/sandbox to cy:Modiwl:Citation/CS1/Date validation/sandbox, changed the month names to Welsh and then reverted. I would not recommend ever taking the en.wiki sandbox versions of the module suite; they are never guaranteed to be working. You should, instead, take the current live version into your sandboxen and make sure that whatever changes are required to suit your particular language are made first there before upgrading the live versions.

—Trappist the monk (talk) 11:59, 22 July 2017 (UTC)

Many thanks to both of you. I've reproduced the problem here. I managed to translate the months, so we're partly there! @Redrose64: - I've also added your bits; the Welsh one doesn't work. Intent - to enable any form of input to produce our usual format (27 Mai 2017). Thanks again! Llywelyn2000 (talk) 05:53, 24 July 2017 (UTC)

The dates rendered in the citation at test 1 are (for me): 2017-07-19 and Adalwyd 2017-07-19. I see no 19/07/2017 in that page except where you write that the dd/mm/yyyy style is not used on cy.wiki. Test 1 apparently shows that the module suite is working correctly; can't fix it if it ain't broke.

The reason for the failure of test 2 is described above and confirmed by the results of test 3.

Intent - to enable any form of input to produce our usual format (27 Mai 2017). Do you mean that you want the module suite to automatically reformat dates in mdy and ymd formats to dmy format?

—Trappist the monk (talk) 10:17, 24 July 2017 (UTC)

I'm not making myself clear! Sorry, i'll try again:

Test 1 - should produce '19 Gorffennaf 2017'; as you say, the module should reformat to our accepted format

Test 2 - should not have that error at the end (Check date values in: |access-date= (help))

Test 3 - should allow the input to be in Welsh (5 Ebrill 2007); at the monment it creates an error 'Gwall: Amser annilys'.

Thanks! Llywelyn2000 (talk) 16:10, 28 July 2017 (UTC)

At test 1 you write this: If we input the date as 2017-07-19... what we get is 19/07/2017. I don't see that. Here is a copy paste of the rendered citation I see:

"Gwerthu llythyrau’r Cymro oedd yng nghysgod Charles Darwin". Golwg 360. 2017-07-19. Adalwyd 2017-07-19.

19/07/2017 is not part of that rendering. I don't know how you can be seeing a dd/mm/yyyy date format; that is not something that the modules produce.

Test 3 does not test the cs1|2 modules; it tests the MediaWiki {{#time}} parser function. It is not possible for us to fix that here. See phab:T21412.

Test 2 fails because of the problem illustrated in test 3. I have explained that newer versions of the cs1|2 module suite have overcome that problem. My recommendation to you is to do these things:

1. import the current version of the live modules (all of them) from en.wiki into their appropriate sandboxen at cy.wiki
2. modify the sandboxen as appropriate to suit the Welsh language (most will not require modifications I think)
3. test to make sure that the sandbox suite works
4. overwrite the current live version with the sandbox version

Automatic date reformatting is not something that the cs1|2 modules have ever done. At en.wiki |df= allows us to do date reformatting on a citation-by-citation basis. And that works at cy.wiki, but not correctly (it renders English month names). I believe that I know a solution to that which would enable automatic date reformatting and, as a side benefit, enable automatic translation of English month names into the local language month names. I'm interested in exploring that but am not interested in retrofitting it into older versions of the module suite. Cy.wiki would be a good test-bed but it must be upgraded first.

—Trappist the monk (talk) 10:41, 29 July 2017 (UTC)

The rendered reference for test 1 is wholly italicized. It should not be. This is because user agents (browsers) apply default italic styling to the <cite>...</cite> tag that wraps the citation. Wherever it is that cy.wiki handles site-wide styling, you can add this:

/* Reset italic styling set by user agent */
cite, dfn {
    font-style: inherit;
}

(may require some consensus). Alternately, we can edit cy:Module:Citation/CS1/Configuration to locally override the default. A site-wide solution would be preferred I suspect. I don't know where cy.wiki keeps its site-wide css; if you cannot find it, I suspect that there are editors at WP:VPT who can help.

—Trappist the monk (talk) 11:19, 29 July 2017 (UTC)

@Trappist the monk: - Many thanks for your work on this! I have a lot of work to do! I'll get back to you in a millennium or two! Llywelyn2000 (talk) 08:38, 14 August 2017 (UTC)

Identifier order messed up.

Why is bibcode displaying before arxiv in?

• "The extended rotation curve and the dark matter halo of M33". Monthly Notices of the Royal Astronomical Society. 311 (2): 441–447. 2000. arXiv:astro-ph/9909252. Bibcode:2000MNRAS.311..441C. doi:10.1046/j.1365-8711.2000.03075.x. {{cite journal}}: Unknown parameter |authors= ignored (help)CS1 maint: unflagged free DOI (link)

Identifiers should be listed in alphabetical order. Headbomb {t · c · p · b} 13:49, 10 June 2017 (UTC)

The identifier labels are sorted with a case sensitive sort. 'B' has an ascii numerical value of 66 (0x42) and 'a' has an ascii numerical value of 97 (0x61). Proof for that is here, where I've added |eissn=1365-2966 and |issn=0035-8711 from the journal's wikipedia article:

"The extended rotation curve and the dark matter halo of M33". Monthly Notices of the Royal Astronomical Society. 311 (2): 441–447. 2000. arXiv:astro-ph/9909252. Bibcode:2000MNRAS.311..441C. doi:10.1046/j.1365-8711.2000.03075.x. eISSN 1365-2966. ISSN 0035-8711. {{cite journal}}: Unknown parameter |authors= ignored (help)CS1 maint: unflagged free DOI (link)

—Trappist the monk (talk) 14:42, 10 June 2017 (UTC)

Well, that ought to be fixed then, either with case-insensitive sorting, or by putting the sortkey in a {{lc:IDENTIFIERNAME}} type of thing. Because it wasn't like that before. Headbomb {t · c · p · b} 15:18, 10 June 2017 (UTC)

There have been no changes to the identifier sorting since at least this version (April 2013) of Module:Citation/CS1.

—Trappist the monk (talk) 15:59, 10 June 2017 (UTC)

I distinctly remember those to be sorted correctly as late as this spring. But even if my memory somehow fails me, those should be sorted alphabetically, regardless of casing. Headbomb {t · c · p · b} 17:02, 10 June 2017 (UTC)

De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)

De-archived again. @Trappist the Monk and Jonesay95:. Headbomb {t · c · p · b} 13:58, 13 August 2017 (UTC)

Any update on doi-broken-date?

If anything, the doi should at the very least still link. Other improvements can wait/get more discussion, but the linking part should be easy to fix. Headbomb {t · c · p · b} 14:25, 11 April 2017 (UTC)

@Trappist the monk: Any way we can get this bundled in the weekend's update? Headbomb {t · c · p · b} 05:29, 26 April 2017 (UTC)

The purpose of this interstitial period is to have a last chance to find and fix bugs; to create or modify supporting documentation, categories, templates, etc. – housekeeping preparatory to the update. It is not the time for new development or new features.

—Trappist the monk (talk) 11:28, 26 April 2017 (UTC)

Yeah well this has been requested a long while ago, is an easy fix, and we have over half a week left. WP:BURO applies here. Headbomb {t · c · p · b} 11:57, 26 April 2017 (UTC)

Can we now implement this? Headbomb {t · c · p · b} 00:27, 2 May 2017 (UTC)

De-archived because discussion is ongoing/unresolved. @Trappist the monk:. Headbomb {t · c · p · b} 17:20, 23 May 2017 (UTC)

@Trappist the monk and Jonesey95: pinging. Headbomb {t · c · p · b} 19:13, 12 June 2017 (UTC)

It makes sense to me to have allegedly broken DOIs linked, since the doi-broken-date is checked by a bot and (a) could have been wrongly applied or (b) could have been a temporary problem or (c) both. There are plenty of links that don't work and are not flagged as such. That's just the state of the web, and always has been. – Jonesey95 (talk) 02:00, 13 June 2017 (UTC)

De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)

De-archived again. @Trappist the Monk and Jonesay95:. Headbomb {t · c · p · b} 13:58, 13 August 2017 (UTC)

Instructions when info is hard to find at source page

Occasionally there are certain quirks in web pages that make it harder to find the source information being cited. For example, in the article on Kevin Quackenbush, I sourced some information from his bio on MLB.com, but to get to that information requires an additional click (on the not-so-obvious "View More Bio Info +" link), which then produces a popup window that doesn't seem to have a URL of its own. In these cases, I believe it would be useful to provide some instruction to the reader on how to navigate to the relevant information, e.g. click the "View More Bio Info +" link. Is there a parameter within the template that can be used for this or another standard way of doing so? Thanks. --Jameboy (talk) 17:44, 24 July 2017 (UTC)

@Jameboy: |at= or choosing to put the information outside the template would both be reasonable, I think. --Izno (talk) 18:49, 24 July 2017 (UTC)

That seems sensible, good suggestion, thanks. --Jameboy (talk) 19:09, 24 July 2017 (UTC)

You can use "postscript=Click View More Bio Info" and put some further instructions there. AngusWOOF (bark • sniff) 08:10, 25 July 2017 (UTC)

@AngusWOOF: This is a misuse of |postscript=. --Izno (talk) 12:00, 25 July 2017 (UTC)

Citing Foreign Affairs

Foreign Affairs comes out six times a year, and the issues are dated with two months; the current issue is the "July/August" issue. If I put "July/August" into the date= variable of cite magazine, as I did at Ryukyu_Islands#Okinawa_Islands, the template throws up an error. What's the correct method here? Thanks in advance, A Train^talk 17:42, 29 July 2017 (UTC)

cs1|2 adheres to the date-range rules set by MOS:DATERANGE modified as described at Help:Citation_Style_1#Dates. Dates always require a year. |date=July–August yyyy where yyyy is the year of issue. Did the help text linked by the error message not answer this question? How can the help text be improved?

Please fix the unclosed italics wiki markup in your signature (the user talk link).

—Trappist the monk (talk) 18:07, 29 July 2017 (UTC)

Thanks for that -- the problem wasn't that I hadn't included a year, it was that I had used a slash to separate the months instead of a dash. Also, thanks for the heads-up on the signature. No one had noticed that in over ten years. :) A Train^talk 18:23, 29 July 2017 (UTC)

JFM error checking

JFM seems to come in only one format (\d\d\.\d\d\d\d\.\d\d). Headbomb {t · c · p · b} 23:33, 2 August 2017 (UTC)

Exception:

• ERAM 066.1720cj found in Hermite polynomials and Mehler kernel
• ERAM 021.0672cj found in Von Staudt–Clausen theorem

But that's are not really JFM identifiers, those are ERAM identifiers, which happen to resolve to the same database. Not quite sure how to handle that one. Headbomb {t · c · p · b} 14:30, 4 August 2017 (UTC)

I've updated them to use |id={{ERAM|foobar}} instead. Headbomb {t · c · p · b} 20:57, 4 August 2017 (UTC)

JFM could be abused to put a Zbl identifier. If the Zbl structure is found, it should throw an error and tell users to user |zbl= instead. Headbomb {t · c · p · b} 14:54, 4 August 2017 (UTC)

MR error checking

MR come in two formats, old (which I can't find documentation for, and can have digits, letters, and :) and new (\d+), which means error checking is a bit hard to do. However, none of them start with letters, and catching that would mean having a way of catching mistakes such at |mr=mr01234, e.g. [1].

Headbomb {t · c · p · b} 23:33, 2 August 2017 (UTC)

Zbl error checking

ZBL come in two formats, old [temporary?] format which consists of pure digits (\d+, possibly 8 digits \d{8}) and new (\d{4}\.\d{5}). Catching errors would mean having a way of catching mistakes such at |zbl=t0303.10056, e.g. [2].Headbomb {t · c · p · b} 14:15, 4 August 2017 (UTC)

\d{3}\.\d{5} will resolve (e.g Zbl 607.73009), but the correct identifier has a \d{4}\.\d{5} structure (e.g Zbl 0607.73009). Headbomb {t · c · p · b} 15:14, 4 August 2017 (UTC)

I'll also point out that I found quite a few (pre\d+) that would resolve only once the (pre) part was striped [e.g. [3], which I've updated to the new style]. I think those are temporary Zbl identifiers. Compare Zbl pre06066616 (which doesn't resolve) to Zbl 06066616 (which resolves to Zbl 1260.11001). Headbomb {t · c · p · b} 14:21, 4 August 2017 (UTC)

Zbl will often be abused to put a JfM identifier [4]. If the JFM structure is found, it should throw an error and tell users to user |jfm= instead. Headbomb {t · c · p · b} 14:53, 4 August 2017 (UTC)

This page describes the coding for the \d{4}\.\d{5} format, but I could not find anything for the other formats or temporary IDs. If the first four digits are a volume number, it makes sense that one could remove the zero padding with no loss of info. --Mark viking (talk) 20:44, 4 August 2017 (UTC)

If the \d{8} format isn't desired, that could be shown as an error too. There's only a handful of (around 41, last I checked). Headbomb {t · c · p · b} 21:02, 4 August 2017 (UTC)

I've updated them all, except [5] Zbl 06247765 in Superpermutation. This is either the temporary assignment, or an oversight in the Zbl database, or it's just a legit but undocumented code. Headbomb {t · c · p · b} 21:37, 4 August 2017 (UTC)

Handling sites that have become malicious

The site www.heritage-history.com in July was promoting fake tech support. That problem seems to have gone away, but now the https version of the site has an invalid security certificate. Whether heritage-history has been taken over by bad guys forever, or they are somehow able to resolve their problem, this point up a need to be able to cite an archive of a site without having the citation contain a link to the original site, so as to minimize the risk that readers will click the link and arrive at a malicious site.

See Military history of Italy for an example of an offending link. Jc3s5h (talk) 13:36, 4 August 2017 (UTC)

|dead-url=usurped or |dead-url=unfit

—Trappist the monk (talk) 13:58, 4 August 2017 (UTC)

The parameters values |dead-url=usurped or |dead-url=unfit are not described on the help page. I don't use undocumented parameter values. Jc3s5h (talk) 14:07, 4 August 2017 (UTC)

I see partial documentation at Template:Cite web/doc#URL, but it does not make clear if the value of the url parameter should be the link to the malicious site, or should just be url= Jc3s5h (talk) 14:13, 4 August 2017 (UTC)

If a parameter is documented at any of the cs1|2 template pages, it is documented. You are free to improve the cs1|2 documentation so please do. The documentation does say "setting |dead-url=usurped or |dead-url=unfit suppresses display of the original URL (but |url= is still required).' You will discover that omitting |url= or leaving |url= blank will get the . Again, you are free to make the documentation better. Please do so.

—Trappist the monk (talk) 15:05, 4 August 2017 (UTC)

I don't want to test this on a live article. What if the malicious site has already been added to the spam blacklist before the attempt to add the deadurl=unfit parameter. Wouldn't it be impossible to perform the edit with the offending URL still present? Jc3s5h (talk) 15:47, 5 August 2017 (UTC)

If blacklist will prevent page-save, there is no problem, right? And even if blacklist does not prevent the page-save, undo is your friend. For those cases where blacklist prevents page-save, |url= can be set to an innocuous site, perhaps https://www.example.com with |dead-url=unfit, and |archive-url= & |archive-date= as appropriate for the archive copy and then <!--original url blacklisted--> added at the end of the cite.

—Trappist the monk (talk) 10:34, 6 August 2017 (UTC)

Question mark at the end of ref

There seems to be an issue at United States presidential election, 2020 with question marks showing up right after a ref. See this. Callmemirela 🍁 ^talk 17:30, 10 August 2017 (UTC)

Not a cs1|2 problem. There is a stray invisible character after the last Mark Cuban reference: a delete character U+007F (you can 'not' see it between these arrows: →?← in the wiki source for this comment). Delete that stray character at United States presidential election, 2020 and no question mark.

—Trappist the monk (talk) 18:09, 10 August 2017 (UTC)

Thank you! Callmemirela 🍁 ^talk 21:17, 10 August 2017 (UTC)

Proposed revision to "Usage" text

The current "Usage" subdocument currently reads, "Copy a blank version to use. All parameter names must be in lowercase. Use the "|" (pipe) character between each parameter. Delete unused parameters to avoid clutter in the edit window. Some samples may include the current date. If the date is not current, then purge the page."

I would like to change this to, "You may copy a blank version to use. All parameters are optional except the |title= parameter. Parameter names must be in lowercase or will not be recognized. A "|" (pipe) character must be placed between each parameter. You should delete unused parameters to avoid clutter in the edit window. Some samples may include the current date. If the date is not current, then purge the page."

Thoughts? Objections? KDS4444 (talk) 03:25, 13 August 2017 (UTC)

"All parameters are optional except the |title= parameter" is not true. For example, |url= is required if |access-date= is used, and |last2= is required if |last1= |last1= is required if |last2= is used. Look at the "Prerequisites" section of the {{cite journal}} documentation for more requirements, and also read the explanation of title parameter requirements at Category:Pages with citations lacking titles. – Jonesey95 (talk) 15:55, 13 August 2017 (UTC)

That would be |last1= is required if |last2= is used, right?

Perhaps that text in Category:Pages with citations lacking titles (and so Help:CS1 errors) needs revisiting. Certainly |title= is a requirement except in {{cite conference}} where |book-title= can be used. Otherwise, |chapter=, |article=, |contribution=, |entry=, and |section= cannot stand alone as titles. It was once true that they could but that has long since been changed.

—Trappist the monk (talk) 17:08, 13 August 2017 (UTC)

Using OAdoi

According to https://peerj.com/preprints/3119v1/ , nearly 50 % of the papers people look for (usually more recent publications) are available in some form of open access, even without counting academic social networks. Perhaps we should point all DOI links to https://oadoi.org/ instead of https://doi.org ? It's clearly a better service if people get to an URL where they can actually access the resource, and oadoi.org (used by hundreds of libraries already) redirects to doi.org if it doesn't know a better destination URL than the publisher-provided one. Alternatively, we could keep a double link, but I think we already provide too many overlapping links. --Nemo 05:31, 13 August 2017 (UTC)

Previous discussion.

—Trappist the monk (talk) 09:10, 13 August 2017 (UTC)

Thanks. The situation evolved in the latest few months though, to the point oaDOI is becoming the de facto main DOI resolver for many institutions (being also included in Web of Knowledge: [6]). If we wanted to be standard-compliant we would (only) display the "doi:" pseudo-protocol, instead we prefer to provide links which are useful (as CrossRef rightly recommends for its own dx.doi.org/doi.org).

Automatically linking the best PDF available is better than requiring users to edit articles and hardcode URLs or identifiers. --Nemo 22:41, 14 August 2017 (UTC)

Hi Nemo_bis! I would be surprised to see this happen, for the same reasons as the one pointed out in the previous discussion. Resolving errors are still possible (and in fact, likely, as the service relies on screen scraping). In terms of policy, even running OAbot as a bot was controversial, because a mass addition of CiteseerX links would violate WP:ELNEVER (see the discussion here). Switching the DOI resolver to oadoi.org would do that at a much larger scale and is therefore likely to face the same backlash. As I wrote earlier, I think this policy is out of touch with the current practices, but it seems quite hard to change it.

But there are even practical reasons why switching the DOI resolver would be a problem. Consider the following citation:

Selinger, P. (2010). "A Survey of Graphical Languages for Monoidal Categories". New Structures for Physics. Lecture Notes in Physics. Springer Berlin Heidelberg. pp. 289–355. arXiv:0908.3347. doi:10.1007/978-3-642-12821-9_4. ISBN 978-3-642-12820-2. {{cite book}}: |access-date= requires |url= (help); Unknown parameter |editors= ignored (|editor= suggested) (help)

If we decide that the DOI is resolved by oadoi.org like this, then the two links will likely point to the arXiv: that is redundant. What if the reader actually wants to access the publisher's website instead? (Sometimes the documents are slightly different, for instance.) So we would need to have two links, one for doi.org and one for oadoi.org, but I agree that would be quite heavy (and useless in many cases, if not most).

− Pintoch (talk) 07:24, 15 August 2017 (UTC)

Note that we could still have something like |auto-url=oadoi that would provide that functionality. But first we need to get that autolinking feature implemented, so when we have |doi-access=free, we get the doi link on the title. Headbomb {t · c · p · b} 15:38, 15 August 2017 (UTC)

Ongoing <references /> discussion at WP:VPPR

The village pump discussion about modifying <references /> into columns is still ongoing. I invite you to comment there. --George Ho (talk) 09:58, 14 August 2017 (UTC)

Edit request to setup or track CS1/Arguments module documentation

Please create Module:Citation/CS1/Arguments/doc with {{Improve documentation|date=August 2017}} (or better) for maintenance category tracking. I've already created Module talk:Citation/CS1/Arguments/doc and redirected here. The documentation page to be created will appear at Module:Citation/CS1/Arguments and will categorize into Category:Templates with missing or incorrect documentation.

It is not semi-protected per se, but anonymous contributors can't create new pages to module namespace. 2001:2003:54FA:D2:0:0:0:1 (talk) 20:14, 16 August 2017 (UTC)

• Amending the request: Please do the same for Module:CS1/doc. I've redirected Module talk:CS1/doc here. (The faith of Module:Citation/doc and Module talk:Citation/doc are a bit unclear to me.) 2001:2003:54FA:D2:0:0:0:1 (talk) 20:31, 16 August 2017 (UTC)
• Why, regarding Module:Citation/CS1/Arguments? The submodule is unused. --Izno (talk) 21:05, 16 August 2017 (UTC)
  • And, in fact, is documented at Module:Citation/CS1/Whitelist. --Izno (talk) 21:06, 16 August 2017 (UTC)
    • Would {{Documentation|Module:Citation/CS1/Whitelist/doc}} do better then? 2001:2003:54FA:D2:0:0:0:1 (talk) 21:51, 16 August 2017 (UTC)
  • I don't know these modules very well. I noticed it has a lot of Lua code, doesn't have documentation and hasn't been marked as deprecated or unused. If it's really unused, should it be nominated for MfD? 2001:2003:54FA:D2:0:0:0:1 (talk) 21:51, 16 August 2017 (UTC)
• Not done: please establish a consensus for this alteration before using the {{edit semi-protected}} template. (Seeking wider consensus first.) 2001:2003:54FA:D2:0:0:0:1 (talk) 21:56, 16 August 2017 (UTC)