Help talk:CS1 errors

BC Dates?

Is there a way to cite a BC date without a CS1 error? Example:

Aristophanes (424 BC). The Clouds. 

--Srleffler (talk) 21:19, 27 February 2016 (UTC)

cs1|2 do not support dates earlier than 100 CE. You can cite a modern edition and include the original's date in |orig-year=.

—Trappist the monk (talk) 21:44, 27 February 2016 (UTC)

In fact, Srleffler should be giving the date of the edition he/she read. Jc3s5h (talk) 23:22, 27 February 2016 (UTC)

Access-date localization

Hello, can someone help me? I want to localize {{Cite web}} from English Wikipedia but I am failing to localize "access-date". Is it possible to change the date format of "access-date" field to another in module configurations? (currently it is YYYY-MM-DD).--Zygimantus (talk) 07:32, 5 March 2016 (UTC)

Perhaps. Localize where? Do you mean at another language Wikipedia? Which one? At en.wiki |access-date= accepts ymd, mdy, and dmy dates per MOS:DATEFORMAT so to add another date format to en.wiki's version of cs1|2 requires changes to MOS:DATEFORMAT.

—Trappist the monk (talk) 11:22, 5 March 2016 (UTC)

External link in |title= because URL in actual title

What is the recommended cite journal approach in the rare case where a title actually includes a url, such as the journal article "New allele frequency database: http://www.allelefrequencies.net", cited in HLA-DQ8? --Worldbruce (talk) 15:25, 6 April 2016 (UTC)

References

Wrap it in <nowiki>...</nowiki> tags:

{{cite journal | author = Middleton D, Menchaca L, Rood H, Komerofsky R | title = New allele frequency database: <nowiki>http://www.allelefrequencies.net</nowiki> | journal = Tissue Antigens | volume = 61 | issue = 5 | pages = 403–7 | year = 2003 | pmid = 12753660 | doi =10.1034/j.1399-0039.2003.00062.x }}

Middleton D, Menchaca L, Rood H, Komerofsky R (2003). "New allele frequency database: http://www.allelefrequencies.net". Tissue Antigens 61 (5): 403–7. doi:10.1034/j.1399-0039.2003.00062.x. PMID 12753660.  CS1 maint: Multiple names: authors list (link)

The delete character error arises because MediaWiki changed how it encodes stripmarkers; the error message will go away when next the Modules are updated:

Middleton D, Menchaca L, Rood H, Komerofsky R (2003). "New allele frequency database: http://www.allelefrequencies.net". Tissue Antigens. 61 (5): 403–7. doi:10.1034/j.1399-0039.2003.00062.x. PMID 12753660.  CS1 maint: Multiple names: authors list (link)

You should not place multiple authors in |author=. In this case, the best parameter to use is |vauthors=.

—Trappist the monk (talk) 15:41, 6 April 2016 (UTC)

Quarterly date issues

The date issues with Quarterly journals hasn't been fixed despite being raised before: see here and here. Is anyone able to add something to prevent the red-error messages that appear for perfectly valid dating terminology? Current example at Raymond Vernon. Carcharoth (talk) 11:24, 11 April 2016 (UTC)

Because cs1|2 follows the date styles specified in MOS:NUM, it would be best if that document had something more definitive than a single mention (which refers to seasons and not to quarterly dates, per se).

It has been suggested that cs1|2 establish the necessary 'rule' that dictates appropriate use of a quarterly date. The idea died aborning due to lack of interest.

—Trappist the monk (talk) 11:24, 12 April 2016 (UTC)

Yes, I see. Are you saying I need to go down the corridor to room 345, get form B67a filled out in triplicate, and then come back here before any changes can be made? Carcharoth (talk) 13:56, 12 April 2016 (UTC)

No. It means that if you want to change the MOS, you need to propose that change. The date checking here at CS1 reflects MOS, for the most part. For example, when there was confusion about how months should be abbreviated, an editor started an RfC at MOS to determine a consensus on that issue. The CS1 templates now check for month abbreviations that match that outcome. – Jonesey95 (talk) 15:10, 12 April 2016 (UTC)

There is absolutely no need to go anywhere near the manual of style. This is a citation issue, not a manual of style issue. Wikipedia:Citing sources is clear (version quoted from):

Seasonal publication dates and differing calendar systems - Publication dates, for both older and recent sources, should be written with the goal of helping the reader find the publication and, once found, confirm that the correct publication has been located. For example, if the publication date bears a date in the Julian calendar, it should not be converted to the Gregorian calendar. If the publication date was given as a season or holiday, such as "Winter" or "Christmas" of a particular year or two-year span, it should not be converted to a month or date, such as July–August or December 25. If a publication provided both seasonal and specific dates, prefer the specific one.

The citation guideline is being correctly followed, and this error-detection module is incorrectly flagging up errors in the use of this citation template. It needs to be fixed. It doesn't need a manual of style RfC, it just needs common sense to add something that avoids error messages being produced upon use of quarterly and seasonal publication dates (and various other non-standard date formats). These dates formats are correct. A system that produces error messages when there is no error is broken. Carcharoth (talk) 15:28, 12 April 2016 (UTC)

I will raise this issue at Help talk:Citation Style 1. Carcharoth (talk) 16:18, 12 April 2016 (UTC)

I have struck my above doctrinaire comment. I will say, however, that when we added "Christmas" as an acceptable date, we did some research to show that there were actual citations using "Christmas" as an issue "month" and tracking down images of magazine covers that showed "Christmas YYYY" on the cover. See this discussion for those links. Some similar due diligence would probably be in order here. – Jonesey95 (talk) 17:18, 12 April 2016 (UTC)

Thank you. There is this example. "3rd Qtr., 1999". How many do you want? Carcharoth (talk) 17:30, 12 April 2016 (UTC)

That's a useful one. Here's a Link to list of issues for that journal, Journal of International Business Studies, which dated its issues with "Qtr", in addition to volume and issue numbers, for many years.

You might also propose a MOS-style standard for what formats would be acceptable, e.g. "3rd Qtr.", "3rd Qtr", "Third Quarter", etc. It's nice to settle on something consistent. – Jonesey95 (talk) 18:23, 12 April 2016 (UTC)

That journal also used seasonal dates if you go back earlier still. As for a MOS-style standard, that would be nice, but I would prefer to leave that to people that really care about that. I don't mind inconsistency across articles as long as people can understand what is meant. "3rd Qtr.", "3rd Qtr", "Third Quarter" are all understandable by the reader, and that is the main thing. What I want is to see support added for quarterly dates, and the error-detection system updated to accept those dates. I do accept that the error-detection system will need a MOS-style standard to work with, so is this like a Catch-22 situation? I don't want to thrash out a MOS-style standard, but those maintaining the error-detection system need such a standard? Seems like the error-detection system is forcing people to think in MOS-mode, so to speak. Positively Pavlovian reinforcement. :-) Carcharoth (talk) 22:02, 12 April 2016 (UTC)

Archive-url timestamp

I've run across a seemingly widespread error where working urls from archive.org cause a message like "|archive-url= is malformed: timestamp (help)". E.g. see this search. Apparently, archive.org has added a new directory to their urls (diff), so the timestamp is now in web.archive.org/web/ which causes old links to fail our internal template check. De728631 (talk) 11:54, 16 April 2016 (UTC)

Fixed in Module:Citation/CS1. Null edits will fix pages with this error message.

—Trappist the monk (talk) 11:59, 16 April 2016 (UTC)

Thank you. Maybe we should a have bot make null edits on all these pages. De728631 (talk) 16:28, 16 April 2016 (UTC)

Re: Archive-url timestamp

I've run accross the same error message but apparently for a different reason. The error message was shown because I added the string "id_" to the teimstamp part of the archive.org's URL. Example: this version of XWT article (see error message at reference No. 3). Error message disappeared when I changed archive-url=https://web.archive.org/web/20160416213029id_/https://github.com/mono/xwt/blob/master/README.markdown to archive-url=https://web.archive.org/web/20160416213029/https://github.com/mono/xwt/blob/master/README.markdown (20160416213029id_ => 20160416213029). However, adding id_ in archive links is legal, it removes site's additional markup and in this case it is useful because additional markup makes page appear less clear (I guess there are some unsolved technical issues at archive.org regarding this). Expert intervention would be appreciated :) Ajgorhoe (talk) 22:01, 16 April 2016 (UTC)

Yep, this is a known error. I'm noodling out a solution. Partially fixed in the sandbox:

"Xwt Read Me". Xwt on GitHub. 15 Jan 2012. Archived from the original on 2016-04-15. Retrieved 2016-04-15. 

Interestingly, while the id_ suffix makes the archived page appear all pretty-like, it breaks the back button. Websites should never ever break the back button.

—Trappist the monk (talk) 22:27, 16 April 2016 (UTC)

"incomplete year-initial dates" and editing for clarity about date problems, for arriving editors

What is an "incomplete year-initial date"? I just dropped it from the list of date format problems in the "Check date values" section (in this diff. If someone wishes to restore it, could you please include an example or a link? Including to please include an example in the table "Examples of unacceptable dates and how to fix them".

Also, I made other revisions in this series of edits, trying to make the section more comprehensible to editors arriving to this section from date errors in articles. Arriving editors don't know what is above or below, and they don't want to have to wade through technically correct but dense information. Really most editors would rather "pattern-match" on potential date formats, rather than ponder vague advice like avoiding "misplaced, incorrect, or extraneous punctuation". So giving them a link which allows them to jump down to the table of examples is helpful.

And the introductory two sentences were dense and confusing, at least to me, so I tried to clarify them, including by naming linked things more precisely. Hopefully the revised text is more straightforward and the changes have not introduced any technical errors. --doncram 22:30, 20 June 2016 (UTC)

The "incomplete..." date is listed as "Ambiguous date range or year and month" in the table. – Jonesey95 (talk) 23:21, 20 June 2016 (UTC)

Ah, so "2002-03" is an example. It is either a "year-initial date" (but is it not complete as a month-and-year? or is it "incomplete" because it does not include the day?) or it is a date range.

Can't we improve upon the label in the table, "Ambiguous date range or year and month"? There is no ambiguous date range, nor any ambiguous year. There is ambiguity between whether it is a date range or it is a date in year-and-month format. How about "Ambiguity: month-and-year or date range?", with hyphens and switched order for clarity about what are the alternatives compared by "or"? Or clarify by using "versus" instead: "Date range vs. month and year", or "Ambiguity: date range vs. month-and-year"?

Relatedly, I don't like the label '"mm-dd-yyyy" or "dd-mm-yyyy" date format', which is another in the table. In pattern-matching mode, I would go, like, "yup, my date is in MM-DD-YYYY format" (or in the other one). The label does not suggest there is anything wrong. How about 'Ambiguity: "MM-DD-YYYY" or "DD-MM-YYYY"?', or '. Or how about 'Unclear: "MM-DD-YYYY" vs. "DD-MM-YYYY"'. Or how about 'Avoid MM-DD-YYYY and DD-MM-YYYY" or "Avoid MM-DD-YYYY and DD-MM-YYYY (ambiguous)". While "YYYY-MM-DD" is okay.

Maybe I am belaboring this, but I'll go on: Only some of the labelsconvey that something is wrong. Perhaps especially strange are the pair: "Zero-padding" (January 04, 1987), and "One-digit month or day" (2007-3-6) where the sin is not zero-padding. "Zero-padding" is not a clearly negative label. What to do, if anything?

• Perhaps put one after another in the table, to make it clear zero-padding is sometimes outlawed and sometimes required. (But why, as that doesn't really help pattern-matchers.)
• Perhaps relabel them. What is the problem, really, with either? Perhaps zero-padding is wrong when the type of date format is one where zero-padding usually does not often occur. ("Month D, Year" is the common way we write out dates when we are writing out full sentences, and then zero-padding looks wrong / is rare / doesn't accomplish anything in terms of lining up dates better in columns.) And failure to zero pad is wrong when the type of date format is like how computer printouts of databases often are, where zero-padding is usual so that numbers line up? (Aside: where is the reasoning about what is right and wrong in CS1 explained somewhere?) How about revising to: "Zero-padding where rare" or "Zero-padding when it is unusual" or "where uncommon"? And revise the other to "Not zero-padding where it is usual"? I dunno. --doncram 21:46, 22 June 2016 (UTC)

An incomplete year initial date can also have the form yy-mm-dd or yyyy-m-d, both of which are in the table.

Not clear to me how this:

"...an automated test is done to see if the dates are real dates that comply with a CS1-related subset of Wikipedia's Manual of Style..."

is more clear than this:

"... an automated test is done to see if the dates are real dates that comply with a subset of Wikipedia's Manual of Style..."

I wonder if it wouldn't be better for the error message help text to link to the compliance table instead of the Dates heading.

—Trappist the monk (talk) 23:40, 20 June 2016 (UTC)

moved the following comment out of my comment—Trappist the monk (talk) 00:24, 23 June 2016 (UTC)

(Jumping in) Oh, you are saying those are incomplete in a different way than omitting the day.

In the first case, the table label is "Two-digit year" (87-12-06). Apparently YYYY-MM-DD is okay, but not YY-MM-DD. Perhaps because (like in 07-12-06), it may be ambiguous with DD-MM-YY and MM-DD-YY. For pattern-matchers, perhaps it would be better to put this example together with the example on MM-DD-YY and DD-MM-YY.

In the second case, the table label is "One-digit month or day" (2007-3-6). Which is apparently wrong when a year-initial hyphenated numerical date ("YYYY-MM-DD") is used. Perhaps make the label into a transition statement: "YYYY-MM-DD is okay, but zero-pad"? I dunno. --doncram 21:46, 22 June 2016 (UTC)

Please don't insert text I did not write into my comments.

Yes, remember y2k?

The only MOS accepted all numerical date format is YYYY-MM-DD which is modeled after ISO 8601. That international standard requires zero padding of day and month numbers between 1 and 9 inclusive. MOS has taken the position that it is inappropriate to zero-pad day numbers in mdy and dmy dates. cs1|2 complies with all of this.

I have no basis for an opinion on 'pattern matching', but isn't that what reading is? Pattern matching is what allows us to consume whole words without analyzing each and every letter, right? Even when some of those letters are jmulbed up into a non-word.

—Trappist the monk (talk) 00:24, 23 June 2016 (UTC)

About inserting Talk page comments, I believe that by indenting 2 steps I avoided confusion about whose text was whose. When there is a list of items, it is subjective whether it is good for keeping stuff together, item-wise, or bad for chopping up another editor's writing. But okay. --doncram 05:56, 23 June 2016 (UTC)

I thought "subset" would link to a definition of what a subset is, like in mathematics, so this was to avoid surprising the reader. And the actual target, the Dates heading, did not seem to be obviously a subset of anything, so labeling it "CS1-related subset" was my way of trying to make it more sensible. (I was not sure, but eventually decided that the CS1 rules, within MOS, are the "subset" that was intended. Rather than the CS1 section on dates being a subset of CS1.) I agree that linking to the compliance table, the section titled "CS1 compliance with Wikipedia's Manual of Style", would be better than linking to the section titled "Dates", of which it is a part.

But CS1 rules are apparently not a subset of MOS, they are inconsistent with MOS, says that subsection. So perhaps call it a "version":

"... an automated test is done to see if the dates are real dates that comply with a CS1 version of Wikipedia's Manual of Style..."

or, better, try to call it what is really meant:

"... an automated test is done to see if the dates are real dates that comply with Citation Style 1, a house style that is used in many Wikipedia articles"

if that is an acceptable way to roughly define CS1. I am not going to implement any of these musings into the article. --doncram 21:46, 22 June 2016 (UTC)

I guess I disagree. The whole suite of MOS rules for dates encompasses some date types and styles that are inappropriate or impossible for citations in general and for cs1|2 in particular. Where it can and where appropriate, cs1|2 hews closely to the rules set down in the MOS; this is why I chose the 'subset' term: because the rules that cs1|2 obeys are a subset of the rules established by MOS. Where cs1|2 can't or doesn't obey a MOS rule, the reason is generally provided in the table.

I get your point about the 'subset' word definition so perhaps that sentence can be rewritten:

"... an automated test is done to see if the dates are real dates that comply with a subset of the date rules in Wikipedia's Manual of Style...

You wrote: they are inconsistent with MOS, says that subsection – where?

—Trappist the monk (talk) 00:24, 23 June 2016 (UTC)

I like your revised sentence better than what's in the article.

About "inconsistent", the linked section states "For various reasons, CS1 is not fully compliant with MOS:DATEFORMAT." I don't know what are the reasons or ways CS1 is not fully compliant, but I take MOS:DATEFORMAT is part of MOS. Non-compliant = inconsistent. I wasn't referring to anything else. --doncram 05:56, 23 June 2016 (UTC)