Help talk:Citation Style 1/Archive 19

Archive 15

←

Archive 17

Archive 18

Archive 19

Archive 20

Archive 21

→

Archive 25

Time zone problem?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This may have been discussed previously, too lazy to search now.

"Dummy webpage". Website. Retrieved 2016-06-06.

However in my time-zone (UTC-5) it is still 2016-06-05. 72.43.99.138 (talk) 16:30, 5 June 2016 (UTC)

Because the module can't know where you are when it renders the cached version of the page that you will read. As long as |access-date= is no more than 1 day ahead of UTC±00:00 then there is no error. This allows anyone in time zones east of UTC to add |access-date= for their own current local date without errors popping up.

—Trappist the monk (talk) 17:11, 5 June 2016 (UTC)

True, for readers. However, for writers the module should be able to know when the commit datestamp for the particular edit < access-date?? 72.43.99.138 (talk) 17:29, 5 June 2016 (UTC)

I don't think that the module has access to file modification time stamp. And even if it did, it can do nothing to prevent a page save in the event of an error.

—Trappist the monk (talk) 17:40, 5 June 2016 (UTC)

The editor wrote that he/she viewed the web page on June 6, which was presumably true for that editor. – Jonesey95 (talk) 18:44, 5 June 2016 (UTC)

If the module has access to the timestamp it can flag the error. 64.134.96.89 (talk) 19:58, 5 June 2016 (UTC)

What error? Peter coxhead (talk) 20:34, 5 June 2016 (UTC)

This one:

"Dummy webpage". Website. Retrieved 2016-06-06..
However in my time-zone (UTC-5) it is still 2016-06-05.72.43.99.138 (talk) 16:30, 5 June 2016 (UTC)

Notice that the template accepted a forward access date: "2016-06-06", even though the local date was "5 June 2016". 65.88.88.126 (talk) 13:09, 6 June 2016 (UTC)

And as I attempted to explain, the module cannot know where on earth you are. An editor in India can add an access date at her local time 2016-06-06T05:30 IST (2016-06-06T00:00 UTC), you could read that citation seconds later at your local time of 2016-06-05T20:00 EDT. There is no error because at that instant there are two dates in the world and the module cannot know that the editor was in India and you the reader are in New York.

—Trappist the monk (talk) 13:58, 6 June 2016 (UTC)

And as it was already mentioned previously, this is not about the reader, but about the writer of the citation. As the example above shows, the module allowed the writing of a citation with a future date. This is an error. Here is a reproduction:

{{cite web|url=http://www.dummy.com|title=Dummy webpage|website=Website|access-date=2016-06-07}}

• "Dummy webpage". Website. Retrieved 2016-06-07.

Now look at my (the writer's) timestamp. 15:21, 6 June 2016 (UTC)

The module should read the stamp, determine that "edit was commited at local date that is before the entered access date" and flag the error appropriately.

65.88.88.200 (talk) 15:21, 6 June 2016 (UTC)

Both of the two time stamps in your post are the same and both are UTC giving no clue to your actual location and thus no clue to your current local date.

The time of last revision of this page is:

2022-09-11T13:14:51 (UTC)

Because that time is UTC it is to be expected that there are two (or three) possible and valid dates in the world where your 'tomorrow' date is one of them. Also, because the revision time is in UTC, the module cannot know that you were not east of the prime meridian when you made your last post.

—Trappist the monk (talk) 16:08, 6 June 2016 (UTC)

It seems like the IP editor is not understanding. Maybe this will help. The |access-date= is intended to establish the date on which an editor read a web-based source. If that source subsequently changes, we might be able to use an archive to see the older revision. Because there are always two dates somewhere in the world, it is impossible to insist on a single access date that works for all editors and web publishers. A web page could be published on June 6 in India and read on June 5 in the U.S., for example. In that case, an access date of June 6 or June 5 is equally valid for the purposes of later verification. It is not reasonable to expect additional precision (unless we support UTC date stamps for access dates, which seems pointless to me, mostly because editors won't use it or won't use it accurately). – Jonesey95 (talk) 14:27, 6 June 2016 (UTC)

Again this is not about the reading of the citation, but about the writing of it. As it is now, |access-date= does not really mean access date (24-hour period). It means an interval that can encompasses two days. If this is to remain, a note should be entered in the doc. 65.88.88.200 (talk) 15:21, 6 June 2016 (UTC)

What is asked, is something like this:

{{cite web|url=http://www.dummy.com|title=Dummy webpage|website=Website|access-date=2016-06-08}}

• "Dummy webpage". Website. Retrieved 2016-06-08.

65.88.88.200 (talk) 15:25, 6 June 2016 (UTC)

What are you asking? You provide something, give what the template does, but give no stated outcome, or how the template should behave differently. Headbomb {talk / contribs / physics / books} 15:33, 6 June 2016 (UTC)

I thought it was obvious. The module throws an error when "impossible date"(s) are involved (Help:CS1_errors#bad_date). How is it possible for the writer to assert something happened after the date it was written?

This future (impossible) date the module handles correctly:

{{cite web|url=http://www.dummy.com|title=Dummy webpage|website=Website|access-date=2016-06-08}}

• "Dummy webpage". Website. Retrieved 2016-06-08.

This future (impossible) date the module handles incorrectly:

{{cite web|url=http://www.dummy.com|title=Dummy webpage|website=Website|access-date=2016-06-07}}

• "Dummy webpage". Website. Retrieved 2016-06-07.

65.88.88.200 (talk) 15:48, 6 June 2016 (UTC)

Not an impossible date. 2016-06-06T15:48 UTC is 2016-06-07T01:48 JST [refresh] in Japan.

—Trappist the monk (talk) 16:17, 6 June 2016 (UTC)

Of course it is impossible. In the timezone the citation was written in, the author claims something has happened at a future date. For readers in that timezone this will seem a prophesy, not an access date. The citation will be unverifiable. Technically, it is always incorrect, because it is logged in the revision history with such an impossibilty. 65.88.88.126 (talk) 16:27, 6 June 2016 (UTC)

(←) IP65:

1. The module does not have access to the time at which an edit is committed.
2. The API does not provide information regarding the time zone from which an edit was committed (this would be a privacy violation)
3. As such, your request is technically impossible to implement, even if it made sense to do so.
4. And in fact, it does not make sense to do so, since an edit made from Japan, right now would be on June 7, one day in advance of today (where I am, which is the East Coast of the US, aka EDT).
5. So an accessdate of +1 day is possible, even if you disagree.
6. And lastly, the accessdate is for editors and not for readers.

--Izno (talk) 18:27, 6 June 2016 (UTC)

I beg to differ.

Module:Citation/CS1/Date validation includes a routine that checks access dates, by comparing the entered access date to today's (local) date. It is clumsy. However, look at lines 47 to 51. The comment for the subroutine is what I'm talking about:

Wikipedia start date <= accessdate < tomorrow's date

— line 47

This is already implemented if the date is 2 days in the future.

The API does provide for local time information: Help:Magic words#Other variables by type, mw:Help:Magic words#Date and time, and in more detail, mw:Help:Extension:ParserFunctions##time and the following section, #timel (local time fake out, through mw:Manual:$wgLocaltimezone).

A person in Japan editing this page "tomorrow" from our perspective will have her/his edit still appear with the proper date ("today") in our local time. MW translates the actual time zone info to the "fake" local time. Not to get too technical, but otherwise there would be no integrity in the logging of edits, and revision history would be invalidated.

As I stated in the very beginning, this, like every date validation in CS1 has to do with the writer of the citation, not the reader.

72.43.99.146 (talk) 23:38, 6 June 2016 (UTC)

I think that you are misreading what $wgLocaltimezone does. According to the documentation, $wgLocaltimezone is a configuration setting in the WikiMedia php code that "[Fakes] out the timezone that the server thinks it's in." For this wiki, it appears that $wgLocaltimezone is set to UTC:

{{#time: Y-m-dTH:i:s }} → 2024-11-14UTC03:20:02

{{#timel: Y-m-dTH:i:s }} → 2024-11-14UTC03:20:02

Even if $wgLocaltimezone were set to something other than UTC, that Japanese editor's edits may very well happen one day ahead of edits made by a Canadian editor even though the edits occurred seconds apart in 'server' time.

The code that checks |access-date= values compares the values against server time (UTC), not against local time. If is_valid_accessdate () is "clumsy", here is a link to the sandbox. Go thou and make it better.

—Trappist the monk (talk) 01:12, 7 June 2016 (UTC)

What am I misreading? I said that there are facilities at the API level to access the current (local) time, which editor Izno disputed. And I hinted that everything happens in server time (technically, in server language), for version control among other things. Anyway, I won't edit a sandbox when I can't apply the code. So I guess we are where we are. You state that the module cannot access the revision timestamp. I think that it can, that it should compare it to the access date and at the minimum, flag an error. Actually, since that flag will turn stale when the access date eventually matches the current date, the module should disallow the citation, not just flag it. But nevermind. 72.43.99.138 (talk) 14:06, 7 June 2016 (UTC)

You have misread the code; you wrote:

Module:Citation/CS1/Date validation includes a routine that checks access dates, by comparing the entered access date to today's (local) date.

Not true. The |access-date= value is checked against current server time which is defined as UTC

You have misread the documentation at mw:Manual:$wgLocaltimezone

Yes, there is a {{LOCALTIMESTAMP}} magic word but, on en.wiki, it returns the same time as {{CURRENTTIMESTAMP}} which shows that $wgLocaltimezone is not set to a time zone other than UTC (if it is set at all):

{{LOCALTIMESTAMP}} → 20241114032002

{{CURRENTTIMESTAMP}} → 20241114032002

I showed in my previous post that, on en.wiki, {{#time:}} and {{#timel:}} produce the same results which shows that $wgLocaltimezone is not set to a time zone other than UTC (if it is set at all)

The conclusion you drew (that there are facilities at the API level to access the current (local) time) is correct only in the sense that those magic words and parser functions support the server's own local time when $wgLocaltimezone is set to something other than UTC. It only applies to the server. There is no knowledge of user local time.

You wrote: Anyway, I won't edit a sandbox when I can't apply the code.

I don't understand that. Almost never does anyone directly edit the source of the live cs1|2 modules (because they are used on nearly 2.93 million articles so when things go wrong they really go wrong). If the code you write in the sandbox works, there is no reason for you to believe that it won't go live at the next update (assuming that there is consensus for the change you make).

What I really said, and repeated, is that the code cannot know where on earth an editor is when the editor adds an access date. Since I wrote that I have learned that there is {{REVISIONTIMESTAMP}} but, that magic word returns the same time as {{CURRENTTIMESTAMP}} so that doesn't give us any information that we didn't already have:

{{REVISIONTIMESTAMP}} → 20220911131451

{{CURRENTTIMESTAMP}} → 20241114032002

—Trappist the monk (talk) 16:05, 7 June 2016 (UTC)

I have nothing more to add, then. To validate access date, the module converts it to a unix timestamp, and compares it to today ({{#time:U|today}} or 1731542400) adding 48 hours. Unless I totally misread the protected call to mw:Extension:Scribunto/Lua_reference_manual#mw.language:formatDate, there is no need to know where the edit took place; only that the revision timestamp value is smaller than the access date timestamp value. So fine, if it can't be done it can't be done. 65.88.88.127 (talk) 17:42, 7 June 2016 (UTC)

An aside: {{REVISIONTIMESTAMP}} and {{CURRENTTIMESTAMP}} do not refresh at the same rate, so they will not always return the same value. The revision timestamp changes when an edit is commited. Compare previous revision, scroll down to see. 65.88.88.126 (talk) 15:04, 8 June 2016 (UTC)

At the top of that version of this talk page is a pink box that includes this text:

"00:45, 8 June 2016"

which agrees with the timestamp returned by {{REVISIONTIMESTAMP}} for that revision:

20160608004526

For a new revision, which must be the case for a newly added access date, {{REVISIONTIMESTAMP}} will be the same as {{CURRENTTIMESTAMP}}.

—Trappist the monk (talk) 15:28, 8 June 2016 (UTC)

Nobody disputes that. And it should be obvious that what is pertinent is the revision|current timestamp at the time the template is commited (at that point revisiontime=currenttime={{#time:U|now}}). For some reason that is not clear, the access date timestamp is compared to {{#time:U|today+2 days}} instead of the seemingly more logical {{#time:U|tomorrow}} (perhaps minus 1 second to account for when current time is exactly 00:00:00). There may also be discrepancies due to CAPTCHA delay between commiting an edit and it being saved. 65.88.88.62 (talk) 16:51, 8 June 2016 (UTC)

If |access-date= has today's date, the call to pcall( lang.formatDate, lang, 'U', accessdate ); returns a Unix time stamp for start-of-day (00:00:00) this morning. You can prove this to yourself. Go to Module:Citation/CS1/Date validation/sandbox. Click Edit. Copy this command (a direct form of the pcall() function call) into the Debug console:

=mw.getContentLanguage():formatDate ('U', 'today' )

Press ↵ Enter and the console returns a Unix time stamp. For 2016-06-08 it returns 1465344000 (you can prove that by replacing 'today' in the function call with '2016-06-08'). Put the number that was returned in a {{#time:}} parser function:

{{#time:Y-m-d\TH:i:s|@1465344000}} → 2016-06-08T00:00:00

Similarly, replacing 'today' with 'tomorrow' returns the time stamp for start-of-day tomorrow (one second more than all of today). Since we want to allow access dates for two consecutive dates existing on Earth, we use 'today+2 days' to give us a time stamp for start-of-day on the day after tomorrow (one second more than all of tomorrow).

Because these time stamps all reflect a time at the start-of-day, an access date with tomorrow's date will be less than the time stamp for 'today + 2 days'. When I wrote this code I determined that it is easier to convert the various dates to a Unix time stamp for numerical comparison rather than write a bunch of code to disassemble the individual dates and account for leap year, the variable number of days in a month, ...

—Trappist the monk (talk) 19:49, 8 June 2016 (UTC)

But that was not my argument, I have no problem with any of that. The call ultimately uses the {{#time}} function, applying to the entered access date (which should always be today or before today at the time of the writing of the template), and to the day after tomorrow, in unix format.

Suppose the access date is today:

{{#time:U|today}} or {{#time:U|8 June 2016}} which give

1731542400 or 1465344000

It is compared with:

{{#time:U|today+2}} or {{#time:U|10 June 2016}} which give

1731535200 or 1465516800

But as shown, this can produce the incongruity of something having happened at a future date.

What I am saying is, compare the access date with the current time instead:

{{#time:U|now}} which is different from {{#time:U|today}} and {{#time:U|tomorrow}} which give respectively

1731554403 (now) 1731542400 (today) and 1731628800 (tomorrow)

Will some situations throw an error where there isn't any? Yes, but I believe this is better than having an impossible date, especially if the rationale is clearly explained.

65.88.88.126 (talk) 20:38, 8 June 2016 (UTC)

You wrote: For some reason that is not clear, the access date timestamp is compared to {{#time:U|today+2 days}} instead of the seemingly more logical {{#time:U|tomorrow}}. What I wrote was intended to explain, with examples, why the code uses the 'today+2 days' construct.

Now, I think your argument is circling us back to the not-knowing-where-in-the-world-an-editor-is-when-that-editor-adds-an-access-date. The server only knows UTC time/date. We know that there are legitimate (not at all impossible) times and dates that are ahead of UTC. We acknowledge that editors shouldn't see error messages suggesting that they have done a bad thing when they enter their local date as an access date. They have not done wrong and we should not reprimand them for doing what is natural.

—Trappist the monk (talk) 22:40, 8 June 2016 (UTC)

I cannot be circling back to a point that I never abandoned (no matter what other related issues crept in): namely that in some time zones readers who cannot be expected to care about any of these technicalities, may be presented with a source that has supposedly been retrieved after the time they are reading the reference. And as I keep explaining the proposed solution has nothing to do with the reader's time zone, but with comparing the revision/current time of the editor of the reference to the access date that s/he entered and making sure that current time is later or equal to the access date, irrespective of time zones. Yes, there are going to be false positives (for editors) in some cases. These special cases can be explained in the documentation which is aimed at editors, and which editors should read. But the target audience for any citation is the reader, not the writer. Their interests should take priority. 72.43.99.146 (talk) 01:08, 9 June 2016 (UTC)

It feels to me like we are going in circles. The reader could indeed see an access date that she perceives as "tomorrow", just as a human being in the U.S. might talk on the phone "today" to someone in Japan who is already living in "tomorrow". This is how time zones work on Earth. We have explained this to you (well, to IP 72.x and IP 65.x) in multiple ways above. If you have not yet abandoned this concern, I think we might have to agree that we are failing to communicate. – Jonesey95 (talk) 01:29, 9 June 2016 (UTC)

I understand very well what you are communicating. You want the burden of understanding a paradoxical situation to be on the consumer of the paradox, not its producer. As a reader, I don't want to know, neither should I be expected to understand, anything about timezones, time variables, or whatever 3 people in an obscure internal area of Wikipedia decide. All I know is that I see something that has been "retrieved" (past tense) in the future. This is irrational, and not even acknowledged with an error message. It makes the including reference immediately suspect. Some of this suspicion could be transferred to the including article, and from there to Wikipedia. This is a failure on the Wikipedia editors' part, not its readers. So fix it. 72.43.99.138 (talk) 13:02, 9 June 2016 (UTC)

So if I call a Wikipedia reader who is in the United States and for whom it is June 9, and I am in Japan and tell that person that it is June 10, that person will doubt that I am telling the truth and will also doubt everything else I say? I think that our readers fall into two basic camps: the vast majority, who never read access dates, and a tiny minority, who would notice something like this and be smart enough to figure it out. It is not our job to fix readers who do not understand how time zones work. – Jonesey95 (talk) 18:34, 9 June 2016 (UTC)

Ok, fine, so we disagree. I tend to put readers first, and try to make things plain and comprehensible for the intended audience of the encyclopedia. I am not going to force the audience to accept an (avoidable for them) glitch without any explanation. It doesn't matter how many readers notice it. How many readers verify citations? This is not a numbers game. 65.88.88.214 (talk) 20:37, 9 June 2016 (UTC)

Link to the "+2 days" discussion. – Jonesey95 (talk) 17:06, 8 June 2016 (UTC)

Thank you, but it was not entirely convincing. A decision was made in favor of some time zones vs. others, and the error trigger was moved accordingly. To me, it seems more intuitive to 1. add something about the software limitation to all CS1 access date-related docs, including the error doc, and 2. compare access date with the current time, and warn the editor immediately that something may be wrong. As noted in that discussion and also above, the error condition decays anyway. 65.88.88.126 (talk) 17:53, 8 June 2016 (UTC)

I also use local time instead of UTM for accessdates (in part, because it makes more sense to me to do it that way, in part because then I don't have to translate dates to other time zones). In fact, if I'm editing past midnight, I generally backdate my accessdates to the logical day that I think of them as part of, rather than the wall clock day. And I agree that, if one is using this convention, then it is an error to postdate your accessdates. However, I don't think it should be flagged by the software as an error. The reason is different from the ones above (difficulty of accessing local time in the code): it's because of the potential scenario where editor X in Europe sets an accessdate, editor Y in the US makes a small change to the article, and editor X's date is still in the future from the point of view of editor Y. How is the software to know that the accessdate in the version that editor Y is trying to save is really valid (because it was produced by editor X) rather than invalid (produced by editor Y)? —David Eppstein (talk) 00:12, 7 June 2016 (UTC)

I don't know how to explain it any better. Editor X edits a citation at local time L1. By human error, s/he enters an access date D1>L1. The module reads the local (L1) timestamp and determines that D1 is an "impossible" date. Editor X gets an error. Editor Y at local time L2=D1, edits the same citation. The module determines that the local (L2) timestamp satisfies (access date is =< today's date). Editor Y does not get an error.

I am asking whether this can/should be done. If it cannot/should not be done, a note at the documentation would be apt, imo.

72.43.99.146 (talk) 00:43, 7 June 2016 (UTC)

@David Eppstein: What is UTM? --Redrose64 (talk) 13:05, 7 June 2016 (UTC)

Typo for UTC. —David Eppstein (talk) 17:22, 7 June 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

ṣ causing Vancouver style error: non-Latin character

The WP page for Ṣ says it's a letter of the Latin alphabet. The only case of this is on Mycena renati, but it might extend (eventually, as more |vauthors= are used) to whatever character subset/range Ṣṣ are part of (I'm guessing). ((Iṣiloğlu M)) doesn't suppress the error either.

Iṣiloğlu M:

{{cite journal |vauthors=Türkoglu A, Alli H, Iṣiloğlu M, Yağiz D, Gezer K|title=Blah}}

Türkoglu A, Alli H, Iṣiloğlu M, Yağiz D, Gezer K. "Blah". {{cite journal}}: Cite journal requires |journal= (help)

Isiloğlu M:

{{cite journal |vauthors=Türkoglu A, Alli H, Isiloğlu M, Yağiz D, Gezer K|title=Blah}}

Türkoglu A, Alli H, Isiloğlu M, Yağiz D, Gezer K. "Blah". {{cite journal}}: Cite journal requires |journal= (help)

((Iṣiloğlu M)):

{{cite journal |vauthors=Türkoglu A, Alli H, ((Iṣiloğlu M)), Yağiz D, Gezer K|title=Blah}}

Türkoglu A, Alli H, Iṣiloğlu M, Yağiz D, Gezer K. "Blah". {{cite journal}}: Cite journal requires |journal= (help)

  ~ Tom.Reding (talk ⋅dgaf)  17:30, 6 June 2016 (UTC)

More reason to rewrite the name handling code. That character is part of the Unicode character set Latin Extended Additional (U+1E00–U+1EFF) which, along with:

Latin Extended-C (U+2C60–U+2C7F)

Latin Extended-D (U+A720–U+A7FF)

Latin Extended-E (U+AB30–U+AB6F)

is not currently supported.

I suspect that the correct way forward is to support at least Latin Extended Additional rather than making a change that would allow doubled parentheses to mask non-Latin character errors.

—Trappist the monk (talk) 00:18, 7 June 2016 (UTC)

@Tom.Reding: I would like to note that you are using incorrect character in this Turkish surname - it should be ş (U+015F) rather than ṣ as the latter only belongs to Indic languages and is never used in Turkish. — kashmiri ^TALK 07:31, 11 June 2016 (UTC)

Kashmiri, I didn't introduce the character; I'm just reporting the error. Thanks for the clarification.   ~ Tom.Reding (talk ⋅dgaf)  13:25, 11 June 2016 (UTC)

moved static text to /Configuration

I have moved the static text that the module renders for {{cite thesis}} and {{cite interview}} to Module:Citation/CS1/Configuration/sandbox. Anything that can be translated for use in other wikis belongs in one place.

Cite thesis comparison

Wikitext	{{cite thesis|title=Title}}
Live	Title (Thesis).
Sandbox	Title (Thesis).

Cite thesis comparison

Wikitext	{{cite thesis|degree=Ph.D.|title=Title}}
Live	Title (Ph.D. thesis).
Sandbox	Title (Ph.D. thesis).

Cite interview comparison

Wikitext	{{cite interview|subject=Subject|title=Title}}
Live	Subject. "Title" (Interview).
Sandbox	Subject. "Title" (Interview).

Cite interview comparison

Wikitext	{{cite interview|interviewer=Interviewer|subject=Subject|title=Title}}
Live	Subject. "Title" (Interview). Interviewed by Interviewer. {{cite interview}}: |interviewer= has generic name (help)
Sandbox	Subject. "Title" (Interview). Interviewed by Interviewer. {{cite interview}}: |interviewer= has generic name (help)

Cite interview comparison

Wikitext	{{cite interview|interviewer=Interviewer|subject=Subject|title=Title|type=Shouting match}}
Live	Subject. "Title" (Shouting match). Interviewed by Interviewer. {{cite interview}}: |interviewer= has generic name (help)
Sandbox	Subject. "Title" (Shouting match). Interviewed by Interviewer. {{cite interview}}: |interviewer= has generic name (help)

—Trappist the monk (talk) 22:06, 11 June 2016 (UTC)

Cite journal issue

Hi, can someone shed some light on the last question here? I think I've figured out what is happening, but I can't figure out why the template does this. Thanks. Parsecboy (talk) 13:03, 12 June 2016 (UTC)

"|edition=" output difference between En and Vi language versions of {{Template:Cite_book}}

Hi~ There seems to be different output for |edition= between English and Vietnamese Wikipedia. (I'm not sure if the different language versions of templates share code or not, so I'm not sure where to ask about this.)

Here is example where <ref name="sherman"> is almost identical definition on both English and Vietnamese versions of the same article:

Ref on the En version of article:

<ref name="sherman">{{cite book |last=Sherman |first=James E. |author2=Barbara H. Sherman |title=Ghost Towns of Arizona |publisher=University of Oklahoma Press |year=1969 |edition=First |isbn=0-8061-0843-6 |accessdate=2009-09-16}}</ref>

Its output shows the edition as expected:

Sherman, James E.; Barbara H. Sherman (1969). Ghost Towns of Arizona (First ed.). University of Oklahoma Press. ISBN 0-8061-0843-6.

Ref on the Vi version of same article:

<ref name="sherman">{{chú thích sách |last=Sherman |first=James E. |coauthors=Barbara H. Sherman |title=Ghost Towns of Arizona |publisher=University of Oklahoma Press |date=1969 |edition=First |isbn=0806108436 |accessdate = ngày 16 tháng 9 năm 2009}}</ref>

Its output is missing the edition and only has an empty space and period:

Sherman, James E.; Barbara H. Sherman (1969). Ghost Towns of Arizona . University of Oklahoma Press. ISBN 0806108436.

Should I just change |edition= from "First" to "1", or does the template need some change for Vi version? Thank you for any advice:) Zeniff (talk) 05:30, 11 June 2016 (UTC)

It looks like vi.wiki is modified from the en.wiki cs1|2 module suite as it existed on 7 September 2015. Part of that modification was to add a function vi_formatedition() that strips ordinal indicators from the value assigned to |edition= so that it can be rendered as (ấn bản n). When that cannot be done, as with |edition=First, the function blanks the edition value so nothing is displayed. See vi:Module:Citation/CS1.

vi.wiki appears to be rather more strict about what is allowed in |edition= than en.wiki. I don't think that there is any template change needed at vi.wiki – it is their wiki, they can do as they wish. If |edition= is important to that citation, changing to |edition=1 at vi.wiki would seem appropriate. (and if you are going to do that, also replace |coauthors= – its use is also deprecated at vi.wiki.)

—Trappist the monk (talk) 10:21, 11 June 2016 (UTC)

Thank you very much for your thorough answer:) I edited, changing what you suggested. I wasn't sure how to change |coauthors= so I just replace it with |author2= to follow the en.wiki ref, and it seems to work. (It looks like I have a lot to learn about this part of Wikipedia:P) Zeniff (talk) 18:21, 12 June 2016 (UTC)

Removed parentheses from around publisher information, per RFC

In the sandbox code for the citation module, I have attempted to remove the parentheses from around the publisher information, per a recent RFC. Please let me know if I have made any errors or introduced any problems. – Jonesey95 (talk) 14:46, 12 June 2016 (UTC)

Cite journal comparison

Wikitext	{{cite journal|editor-first=H.|editor-last=Garbett|journal=Journal of the Royal United Service Institution|location=London|oclc=8007941|pages=199–204|publisher=J. J. Keliher|title=Naval Notes – Italy|volume=XLII|year=1898}}
Live	Garbett, H., ed. (1898). "Naval Notes – Italy". Journal of the Royal United Service Institution. XLII. London: J. J. Keliher: 199–204. OCLC 8007941.
Sandbox	Garbett, H., ed. (1898). "Naval Notes – Italy". Journal of the Royal United Service Institution. XLII. London: J. J. Keliher: 199–204. OCLC 8007941.

Cite book comparison

Wikitext	{{cite book|editor-first=H.|editor-last=Garbett|location=London|oclc=8007941|pages=792–796|publisher=J. J. Keliher|title=Naval Notes – Italy|volume=XLIII|year=1899}}
Live	Garbett, H., ed. (1899). Naval Notes – Italy. Vol. XLIII. London: J. J. Keliher. pp. 792–796. OCLC 8007941.
Sandbox	Garbett, H., ed. (1899). Naval Notes – Italy. Vol. XLIII. London: J. J. Keliher. pp. 792–796. OCLC 8007941.

Cite book comparison

Wikitext	{{cite book|editor-first=H.|editor-last=Garbett|location=London|oclc=8007941|pages=792–796|publisher=J. J. Keliher|title=Naval Notes – Italy|volume=XLIII|work=Journal of the Royal United Service Institution|year=1899}}
Live	Garbett, H., ed. (1899). Naval Notes – Italy. Vol. XLIII. London: J. J. Keliher. pp. 792–796. OCLC 8007941. {{cite book}}: |work= ignored (help)
Sandbox	Garbett, H., ed. (1899). Naval Notes – Italy. Vol. XLIII. London: J. J. Keliher. pp. 792–796. OCLC 8007941. {{cite book}}: |work= ignored (help)

Cite book comparison

Wikitext	{{cite book|editor-first=H.|editor-last=Garbett|location=London|oclc=8007941|pages=792–796|publisher=J. J. Keliher|series=Journal of the Royal United Service Institution|title=Naval Notes – Italy|volume=XLIII|year=1899}}
Live	Garbett, H., ed. (1899). Naval Notes – Italy. Journal of the Royal United Service Institution. Vol. XLIII. London: J. J. Keliher. pp. 792–796. OCLC 8007941.
Sandbox	Garbett, H., ed. (1899). Naval Notes – Italy. Journal of the Royal United Service Institution. Vol. XLIII. London: J. J. Keliher. pp. 792–796. OCLC 8007941.

I have copied Trappist the monk's sandbox of test cases to my own sandbox to show the implementation of this change in the CS1 templates. See Special:Permalink/724937035. – Jonesey95 (talk) 14:46, 12 June 2016 (UTC)

I've removed the .. "" bits because concatenating an empty string on the end of a string doesn't really do anything;

—Trappist the monk (talk) 17:20, 12 June 2016 (UTC)

Thanks for the cleanup. The first thing I tried along those lines didn't work, so I tried the most minimal change I could think of. – Jonesey95 (talk) 18:26, 12 June 2016 (UTC)

contributor, translator given and surname aliases

Editor Kanguole added these aliases to Module:Citation/CS1/Configuration/sandbox:

|contributor-givenn=

|contributorn-given=

|contributor-surnamen=

|contributorn-surname=

|translator-givenn=

|translatorn-given=

|translator-surnamen=

|translatorn-surname=

and these duplicates which I have removed:

|contributorn-last=

|translatorn-last=

I have completed the task by adding the given and surname parameters to Module:Citation/CS1/Whitelist/sandbox.

I don't particularly care if other editors have a go at improving the modules but please finish what you start. These new parameters are not tested. I will leave that to you.

—Trappist the monk (talk) 23:45, 7 June 2016 (UTC)

Thanks for that. They now work in my tests. Kanguole 00:45, 8 June 2016 (UTC)

Can someone add |display-translators=etal to complement |display-authors=etal & |display-editors=etal?   ~ Tom.Reding (talk ⋅dgaf)  21:12, 8 June 2016 (UTC)

Is there a pressing need? Right now, the highest enumerator is 4 and there are two of them. See this insource:search.

—Trappist the monk (talk) 22:04, 8 June 2016 (UTC)

Nope, no pressing need. I'm currently migrating |others=Translated by ... to |translators= and saw 1 or 2 "et al."s, but I didn't bother to do an |others= insource:search until now (only found 1). Low priority if/until I find more cases during my travels.   ~ Tom.Reding (talk ⋅dgaf)  22:26, 8 June 2016 (UTC)

Just to point out, conflating "first" and "given" is confusing. Perhaps the editor meant "personal", although since "personal name" has two completely different and equally common definitions ("first name" and "entire name") that's also confusing. "first" and "given" names are entirely separate things, although they're often (but not always) related. Given name is the name given at birth/baptism/etc. (hence the term), but in fact many people -- quite possibly most -- go by a hypocorism as a first name, usually a variation of their given name (Sandy, Judy, Dave, etc.) but sometimes not even that (Bunny, Lefty, etc.).

(In East Asia the first name does not actually come first in order when the person's entire name is written or said, but this is a detail -- we still by convention use "first name" to refer to that part of the person's full name which is equivalent to our "Dave" etc. -- that is, unique to that person (not a family name) and used to denote that person when further detail is not required. We do this because there's no other term, and "given name" can't be shoehorned to be this other term because it means something else entirely.)

I dunno for sure if you should remove this change, but probably. I appreciate the thought but IMO it's just introducing a subtle error and minor source of potential confusion, not commensurate with any benefit. Herostratus (talk) 07:18, 9 June 2016 (UTC)

The edit didn't add |given=, |surname=, |editor-given=, |editor-surname=, etc – those aliases have been in the template for quite some time. What it did was to add the corresponding aliases to the recently added parameters |contributor= and |translator= to achieve consistency. Nor are the names unreasonable: the documentation has long said

• last: Surname of author. ...
  • first: Given or first names of author, including title(s);

I very much doubt that it is conventional to say that Deng Xiaoping had a first name of Xiaoping and a last name of Deng. It is precisely when citing authors with East Asian names that |first= and |last= are most confusing, especially if these are mixed with names in the European order. Kanguole 20:30, 9 June 2016 (UTC)

You're right, it's not conventional. I dunno about about Deng Xiaoping and I didn't even realize his name wasn't an Angelesized version of Xiaoping Deng. We certainly do that for Japanese names generally (e.g. Yumiko Kurahashi is written "Kurahashi Yumiko" in Japanese (acually 倉橋 由美子, of which "Kurahashi Yumiko" is a transliteration), and so on. Even so Yumiko Kurahashi's first name is "Yumiko" I think, and I believe this is done for Japanese (and Korean (e.g. Syngman Rhee), and Hungarian) persons generally, but apparently not Chinese I guess, which is... one of those things. So I guess for non-Chinese persons "first name"="that part of your individual name which denotes you uniquely rather than your family and by which you are commonly called by intimates" (leaving aside middle names etc.)

The fact that Chinese people are an outlier (or maybe everyone else is, after all there are 1.2 billion of them) doesn't change the fact that my first name is Dave and my given name is David and these are very much entirely different things, although in my case they happen to be somewhat related (they would not be related if my first name was Champ or Killer or (by conversion) Muhammed and so forth). Using two terms for something when one of the terms is objectively wrong, not common, and actually refers to something different but vaguely related, is a recipe for confusion IMO.

Hopefully the coders here are not in the habit of being like "well this variable name is not exactly the same as the one I actually want to refer to, but it's kind of close, so good to go". Same thing with language, sometimes. However, I apparently misunderstood the nature of the change and this matter was decided in the past, in which case it still ought to be reversed, but I'm not inclined to press the issue. Just pointing it out. Herostratus (talk) 02:48, 11 June 2016 (UTC)

Herostratus, you could take this opinion to Talk:Given name. It seems disingenuous for you to state the above as if it is a well-referenced fact, given your statements at this recent discussion. – Jonesey95 (talk) 05:22, 11 June 2016 (UTC)

It's not disingenuous and, when all is said and done, I prefer not to be insulted, so if you could refrain from that, that'd be great, thanks! I wrote " I'm still looking into this, but I think I might well find that "given name" and "first name", while identical and interchangeable in most reference works (which matters a little, but not much), are not so in actual usage. If I do find that..." but guess what? I didn't find that. OK? My thinking is evolving and after considering the matter and looking at sources, I think it is just sloppiness and erroneous to say that Bunny Berrigan's given name is Bunny. It's putting intentions into sources which they did not intend, and its misreading sources. It's wrong to support templates and code which encourage people to tell other editors that Bunny is Bunny Berrigan's given name. It's erroneous. I'm opposed to error, is all, especially errors which are liable to cause confusion. Herostratus (talk) 01:19, 13 June 2016 (UTC)

transcript-url for AV, podcast, etc.

As previously mentioned, I'd like to once again request a transcript-url field for the Cite AV media, Interview, Podcast, and Speech templates. If the transcript is included in the url of the media itself, as is sometimes the case, a boolean transcript=true or transcript-incl=true might also be useful, to show up with medium=video or something in the citation like:

• Prisoners Begin Hunger Strike (Video w. transcript). Democracy Now!, 04 January 2011.

But mostly I just want the transcript-url field for all the multimedia templates. Thanks guys. SamuelRiv (talk) 05:16, 13 June 2016 (UTC)

incomplete access dates

I just stumbled across this template (since repaired) that specifies only a year for the access date:

{{cite news |url=http://news.bbc.co.uk/sport1/hi/cricket/england/3596939.stm type=team | title=England v West Indies 2004 – Hoggard hat-trick|publisher=BBC Sport|year= 2004 |accessdate=2007}}

type=team "England v West Indies 2004 – Hoggard hat-trick". BBC Sport. 2004. Retrieved 2007. {{cite news}}: Check |url= value (help); Check date values in: |accessdate= (help); Missing pipe in: |url= (help)

This type of citation is relatively rare – this insource search turns up only 200ish occurrences.

It seems to me that the value assigned to |access-date= should be specific to the day because access dates are meant to identify the date that an ephemeral source supported the article text. If that is true, we should be showing a date error when |access-date= is incomplete.

—Trappist the monk (talk) 16:03, 5 June 2016 (UTC)

Concur. The value should be a complete date, the date the editor accessed the particular version. 72.43.99.138 (talk) 16:24, 5 June 2016 (UTC)

For as long as there's a way to override the check and suppress the error message. I recently gave a real-world example where incomplete access-date values can occur: https://wiki.riteme.site/wiki/Help_talk:Citation_Style_1/Archive_14#Acessdates

--Matthiaspaul (talk) 23:33, 7 June 2016 (UTC)

I do not think that is a valid example. The source for your citation was no longer online, and therefore it was not retrieved from the publishing entity (website/database or whatever etc.). Obviously, when somebody contributes a citation of an online source the full date is available. 65.88.88.62 (talk) 17:05, 8 June 2016 (UTC)

Yeah, I agree for normal cases. Since I was citing from the (previously downloaded) off-line source, providing the original download link was optional information.

However, in this case, I think it was important to provide the original link (and approximate download/access date) in order to indicate that the document was in fact once published, even though it is no longer available online (anywhere). (Think of it as a technical specification / document once provided online by a meanwhile defunct company.)

Otherwise some editors in the future would be tempted to remove such citations, and then the corresponding statement in the article would no longer be verifiable (although it once was backed up by a perfectly valid reliable source).

This is a problem, because virtually all currently existing links will be dead links some decades in the future. If, as a consequence, we would have to remove all information only backed up by no longer existing sources (which cannot be substituted by other sources), only the most basic and trivial mainstream knowledge would survive and we'd put a lot of the most interesting detail information in articles at risk. It would be an exercise in futility to add little known background information to articles if that is backed up by one (or very few) electronic sources only (even if they are reliable sources and the info is known to be correct).

Anyway, I was trying to give an example where an incomplete access date might still be useful for verification purposes in the future, and where it should not be counted as error, and where a fix is impossible simply because the source is no longer available online.

Sure, this does not apply to the majority of sources. I am not against adding sanity checks at all (as they can help track down typos and other mistakes in many articles), but there should be some method to mute false error messages in those cases, where it becomes necessary. After all, the citation templates are there to help, not to hinder providing information. --Matthiaspaul (talk) 22:31, 8 June 2016 (UTC)

Why not just upload the information to an archive? Then cite the archive. That way you avoid misusing |access-date=. 65.88.88.127 (talk) 17:17, 9 June 2016 (UTC)

I wasn't misusing |access-date=. The incomplete date I specified was still the actual date when I downloaded the file. I just could not provide the complete date any more... (I would be misusing |access-date=, if I would have "invented" some reasonable dummy month and day just to give a complete date, but as I stated I didn't want to do that.)

In general, your suggestion won't work for most such cases, as you cannot legally redistribute files, even if they were once available for free and the publisher and/or copyright holder is no longer in business. Unless the license agreement would have granted you a right to redistribute, redistribution is a right owned by the copyright owner by default (as the name suggests). It might even have been the copyright owner's intentions to keep the information available forever, but unfortunately you cannot blindly assume this without his clear indication. Instead, you would have to track down the legal successor (who is the copyright holder in such cases) to ask for permission first, and this might be next to impossible to achieve in many cases. Alternatively, you would have to wait for the copyright to expire (f.e. 70 years after the author's death) - so there's still hope, that such information may show up again online if it survived on someone's storage medium for that long, but it won't be in our life's time... ;-) (As great as they are, sites like archive.org are legally working in a "gray zone".)

Also, not everyone has webspace available to upload files.

However, all this is beside the point. This was meant as an example for why we should not forget about implementing some method to override such sanity checks when necessary. --Matthiaspaul (talk) 19:51, 12 June 2016 (UTC)

I was suggesting archiving to places like the Internet Archive, WebCite etc. Technically, you are not making the material available, just a link to it. Obviously if there are link-related copyright issues involved, the case is moot. However, in my experience, such issues are somewhat rare. There is also the additional consideration of reliability: unlike in other (non-free) services, neither the Internet Archive nor WebCite should be considered reliable archives. There is no mechanism that I know of that verifies the archived copy vs. the original. That's ok when there is an a priori solution (while the original is still live, it can be compared with the archive). But in your case, there is no way to make such prior comparison, since the original is what you say it is.

Access dates are expected to be full dates. As a reader, when I see just the year, a flag is raised. Didn't the editor know what day s/he accessed the source? Is the editor guessing? In both cases, it is better not to use the field imo. 65.88.88.126 (talk) 12:48, 13 June 2016 (UTC)

Needing both access and archive dates

What is the state of consensus on whether we need separate access dates listed for website citations that already have archive date citations? It seems like a lot of wasted space, especially in cases when that date is the same. czar 17:16, 4 June 2016 (UTC)

??? The only commonality between access date and archive date is that they are both date fields. They are there for different reasons, and serve different functions. 72.43.99.146 (talk) 19:11, 4 June 2016 (UTC)

Which is why I'm asking. The vast majority of my usage has the dates identical, indicating that the version "accessed" is the same version that is "archived"—the verbiage makes the citation twice as long as it need be. czar 19:56, 4 June 2016 (UTC)

But they don't have to be the same; the original can be accessed after it was archived if it's still there. So one can't be predicted from the other, i.e. they aren't redundant. Peter coxhead (talk) 20:59, 4 June 2016 (UTC)

There is no prohibition on giving both. The archive date is obtained from the archiving service, the access date is the date that the source was checked. --Redrose64 (talk) 11:33, 5 June 2016 (UTC)

I'm not suggesting that they're always redundant—I mean to ask, in the many cases when they are redundant, whether there is precedent for only using the archive date, or whether this will upset the order. And if the latter, would it make sense to bake the archive and access statements into the same phrase when the dates are identical? E.g., Archived from the original on August 22, 2015. Retrieved August 22, 2015. → Archived from the original and last retrieved on August 22, 2015. I would think that the current archiveurl text should be sufficient on its own, though. czar 16:07, 5 June 2016 (UTC)

The problem here is that access dates and archive dates involve different sources. When using |archive-date= it is implied that you are no longer citing the original source, but a 3rd-party copy. This may have WP:RS and other issues of its own. 72.43.99.138 (talk) 16:46, 5 June 2016 (UTC)

If it's not a reliable copy of the original source, it oughtn't qualify for use of the archival parameters at all. Nikkimaria (talk) 21:42, 5 June 2016 (UTC)

How are you interpreting access date? If I access the 15 May archive version on 5 June, my access date is 5 June, not 15 May. In any case, access dates are so often omitted out of oversight or laziness that it would be impossible to impart meaning by omitting it for your purpose. It would just look like another missing access date. Better to live with the "lot of wasted space". ―Mandruss ☎ 17:29, 5 June 2016 (UTC)

I interpret it the same, but two thoughts: (1) I've not once seen evidence of the access date field's usefulness (either in discussion or personally). When a link is dead or its contents contested, it's either in the Internet Archive (or a similar service) or it is not—no one references the access date and if the content of the source were to change, we'd treat it as {{failed verification}} and update it all the same. I would think that the access dates were first devised for print citations of early websites that were prone to change. My personal preference would be to suppress the access date statement from display altogether—keep it for the metadata if you wish—but I can save that thought. (2) At the very least might we consider combining the statements when they are identical as shown above? That was |accessdate=June 5, 2016 + |archivedate=June 5, 2016 → Archived from the original and last retrieved on June 5, 2016. The vast majority of cases I've come across would benefit from such a change. czar 21:33, 5 June 2016 (UTC)

Access date isn't required for documents that don't change, and archival copies of pages shouldn't change. Nikkimaria (talk) 21:42, 5 June 2016 (UTC)

Access dates were not "first devised for print citations" - they are pointless for such sources. There are still web pages - particularly in the fields of news and current affairs - which are very prone to frequent change. Only two days ago a prominent boxer was reported as being ill. His funeral's on Friday this week. This is why we recommend access dates for online sources. --Redrose64 (talk) 22:21, 5 June 2016 (UTC)

That should have read as "devised for citing websites in printed publications". What sources changed in the Muhammad Ali article such that the access date had any consequence? That discussion is still a separate point—my proposal here is to combine the sentences when they are redundant (same date). czar 05:45, 6 June 2016 (UTC)

The Internet Archive often has dozens of versions of a page. The access date can be useful because if you are fixing a dead link then you can choose the version closest in time to the access date. (I'd note that IMO both of these dates are much less important than the original date of publication, especially for print sources. Editors should always include the date of publication (or updating), if available.)– Margin1522 (talk) 23:32, 5 June 2016 (UTC)

Combine access and archive date statements when identical

• The above thread has gone off-topic. The proposal is to combine the access date and archive date statements when they are identical. E.g.,

|accessdate=June 5, 2016 and

|archivedate=June 5, 2016 →

Archived from the original and last retrieved on June 5, 2016.

czar 16:38, 7 June 2016 (UTC)

I have been asked to comment. I am indifferent to slightly opposed. Indifferent because I don't see that there is a lot to be gained from the proposed change. Slightly opposed because there are three separate message forms to consider (|dead-url=no, |dead-url=unfit, |dead-url= (or omitted)). Dates must be compared which will require code that converts dates to a neutral format before the comparison because we can't guarantee that the formats of the two dates will be the same. This latter is complicated because the several wikis outside of en.wiki that use these modules already have trouble with the access-date comparison because the {{#time:}} parser function doesn't support non-English month-names so well. This Haitian date for 15 February 2016 for example:

{{#time:U|15 fevriye 2015}} →

So, the simple date comparison mechanism is not a path forward.

—Trappist the monk (talk) 22:15, 9 June 2016 (UTC)

I don't see why we should be held up here for an issue with compatibility in another language. The dates should be expected to be in the same format between the two fields anyway so I'm not sure how many edge cases we're really looking to solve. My concern is the length. My archive+access statements are often longer than my actual citation, which is silly. My alternative is to not include access dates and for readers to assume that the content referenced matches the access date/info from the archived version. czar 05:38, 13 June 2016 (UTC)

Because other wikis use this module suite, it makes sense to me to minimize the work necessary for them (and also for us) when it comes time to upgrade to our latest version.

There is no requirement that |access-date= and |archive-date= have the same format. Typically they do, but that is not guaranteed.

Have you considered using css to hide access dates?

—Trappist the monk (talk) 11:41, 13 June 2016 (UTC)

I would think that languages incompatible with the #time parser function would then want to see that incompatibility resolved. But I can also acknowledge that this proposal isn't exactly engendering much affirmation. My concern is primarily for my readers—I don't see them benefitting from the duplicative information. I've turned the CSS on (thank you) for my own purposes, but I don't plan on using access dates simultaneous with archivedates in my future writing. czar 14:56, 13 June 2016 (UTC)

access-date checking tweak

Because internationalization was on my mind and because I know that the current access-date checking code in use at en.wiki does not work with other languages, I have converted the text in Module:Citation/CS1/Date validation/sandbox to use the same code that I've used at bs, ht, and sr wikis. MediaWiki apparently doesn't understand non-English month names:

{{#time:U|15 fevriye 2015}} → (Haitian date for 15 February 2016)

To get around that, because as part of the date validation, the code extracts numeric date values from acceptable date formats, its a simple thing to have the access-date validator use the numeric values assembled into ymd format.

• Fail: too early. Retrieved 2001-01-14. {{cite book}}: Check date values in: |accessdate= (help)
• Pass. Retrieved 2001-01-15.
• Pass. Retrieved 2016-06-11.
• Pass. Retrieved 2016-06-12.
• Fail: future date. Retrieved 3016-06-13. {{cite book}}: Check date values in: |accessdate= (help)

This change will make it easier for existing and other wikis to update from en.wiki should they so choose.

—Trappist the monk (talk) 23:16, 11 June 2016 (UTC)

I'm hoping this will also fix "date" checking in Template:Cite web and every other date field that doesn't currently accept YYYY-MM-DD? I see lots of false alarms due to rejection of that format, e.g. currently in tax haven. -- Beland (talk) 04:43, 15 June 2016 (UTC)

I believe that all date= fields accept the YYYY-MM-DD format. The only error in tax haven at the moment is a date of 2011-21-31. There is no month 21. – Jonesey95 (talk) 05:38, 15 June 2016 (UTC)

Dot

Is elseif date_string:match ("%d%d%d%d?.-%d%d%d%d?") then in date validation module OK? My question is, actually, what is .- part used for? --Obsuser (talk) 08:55, 15 June 2016 (UTC)

The dot means accept any character. When followed by the - quantifier, .- matches one or more characters but isn't greedy – a minimal match. Compare to .+ which is similar but will match as much as it can and still meet the requirements of the net bit of the pattern. When used at that particular line in the code, we already know that the date range is valid so we don't care what the approved separator is; we only want the range start and end dates.

You can see this in the debug console with these:

=string.match ('2015–2016', "(%d%d%d%d?).-(%d%d%d%d?)") – date range with ndash

=string.match ('2015—2016', "(%d%d%d%d?).-(%d%d%d%d?)") – date range with mdash

=string.match ('2015 some other stuff 2016', "(%d%d%d%d?).-(%d%d%d%d?)") – date range with nonsense separator (remember, at this point we don't care what the separator is)

Repeat using the .+ or .* patterns

—Trappist the monk (talk) 12:17, 15 June 2016 (UTC)

pmc & access-date behavior without url

I've been cleaning up Category:Pages using citations with accessdate and no URL when a permanent identifier is present, but have avoided cases where |access-date= & |pmc= exist (i.e. they're filled in) with no |url= or |contribution-url=, etc. The reason is that there is no error emitted in this case (the 2nd compare):

I'm just wondering, is this is a bug or a feature?   ~ Tom.Reding (talk ⋅dgaf)  13:34, 14 June 2016 (UTC)

-- Account for the oddity that is {{cite journal}} with |pmc= set and |url= not set.  Do this after date check but before COInS.
-- Here we unset Embargo if PMC not embargoed (|embargo= not set in the citation) or if the embargo time has expired. Otherwise, holds embargo date
	Embargo = is_embargoed (Embargo);											-- 

	if config.CitationClass == "journal" and not is_set(URL) and is_set(ID_list['PMC']) then
		if not is_set (Embargo) then											-- if not embargoed or embargo has expired
			URL=cfg.id_handlers['PMC'].prefix .. ID_list['PMC'];				-- set url to be the same as the PMC external link if not embargoed
			URLorigin = cfg.id_handlers['PMC'].parameters[1];					-- set URLorigin to parameter name for use in error message if citation is missing a |title=
		end
	end

appears to be the relevant passage. Looks deliberate to me? --Izno (talk) 13:38, 14 June 2016 (UTC)

Which is calling from Module:Citation/CS1/Identifiers at function is_embargoed and function pmc. --Izno (talk) 13:42, 14 June 2016 (UTC)

Less deliberate than overlooked methinks. If, as I believe, access dates only apply when |url= is set to a value by an editor, then we should be treating templates with |pmc= set and with |access-date= set and with |url= unset as an error condition.

—Trappist the monk (talk) 14:13, 14 June 2016 (UTC)

Indeed. I think, regardless of the embargo, an error condition should occur. --Izno (talk) 14:38, 14 June 2016 (UTC)

And the accessdate suppressed. Headbomb {talk / contribs / physics / books} 20:23, 14 June 2016 (UTC)

Fixed in the sandbox.

—Trappist the monk (talk) 12:34, 15 June 2016 (UTC)

Related discussion on CITEVAR

There is an ongoing discussion at Wikipedia:Administrators' noticeboard/Incidents#Checkingfax that might be of interest to editors here, As far as I can tell it concerns the question of whether changing |authors= to split out multiple authors into separate parameters counts as a "change of style" that needs a discussion per WP:CITEVAR, or whether this sort of change is just routine cleanup not requiring discussion. —David Eppstein (talk) 19:36, 16 June 2016 (UTC)

Because of that discussion and because there are still many thousands of articles in Category:CS1 maint: Multiple names: authors list and Category:CS1 maint: Multiple names: editors list, I have tweaked the documentation a bit (author, editor).

—Trappist the monk (talk) 10:34, 18 June 2016 (UTC)

Say where you got it

Wikipedia:Citing_sources#Say_where_you_read_it "WP:SAYWHERE" asks for editors to cite where they themselves read the material rather than supposing that the citation should be correct. The page uses this example:

John Smith, Name of Book I Haven't Seen, Cambridge University Press, 2009, p. 99, cited in Paul Jones, Name of Encyclopedia I Have Seen, Oxford University Press, 2010, p. 29.

Does CS1 note support something like this "cited in"? I didn't see anything in the documentation and it doesn't seem like something editors should be forced to do manually. (|via= comes closest, though I don't think it fits.) czar 16:10, 18 June 2016 (UTC)

Personally, I've just cited the "Name of Encyclopedia I Have Seen" and skipped the other half, but you could do something with a pair of templates:

• Smith, John (2009). Name of Book I Haven't Seen. Cambridge University Press. p. 99. Cited in Jones, Paul (2010). Name of Encyclopedia I Have Seen. Oxford University Press. p. 29.

Imzadi 1979 → 16:49, 18 June 2016 (UTC)

In terms of making the data machine-readable, I would think that it would be better to have a |citedin= field that would contain the child citation or short footnote. czar 00:31, 19 June 2016 (UTC)

I kind of agree, but that opens up a whole new level of complexity, unless you're going to just embed another citation template in that field. Imzadi 1979 → 01:49, 19 June 2016 (UTC)

PDF PDF

Wikipedia has about 200 articles like this example where web pages are identified as "(PDF) (PDF)" or some variation of that duplication. I presume this is a mistake, so should I at least edit the document to say that "PDF" is not what you had in mind for the type= parameter? Are there any other common misuses of that parameter we should warn or edit against? Art LaPella (talk) 22:41, 19 June 2016 (UTC)

This particular 'error' likely became visible when cs1|2 began automatically setting |format=PDF (if not already set). There are a couple of correct solutions to this issue: 1) simply delete |type=[[PDF]] or 2) change |type=[[PDF]] to |format=[[PDF]].

No doubt there are forms of error or misuse of cs1|2 parameters that we are unaware of. When you find them, post them here.

—Trappist the monk (talk) 22:52, 19 June 2016 (UTC)

math ml rendering changes and metadata

Tracked in Phabricator
Task T138229

more technical discussion at Wikipedia:Village pump (technical)/Archive 147#math ml rendering changes and scribunto

When editors create cs1|2 templates that have <math>...</math> markup, especially in |title=, that math markup must be decoded so that it can be rendered in the citation's metadata. This is further complicated because editors may select how MediaWiki renders the content of the <math>...</math> tags. This is controlled by the choice the editor has made at preferences. There are three options: PNG images, LaTeX source, and MathML with SVG or PNG fallback.

If the cs1|2 title parameter looks like this:

|title=<math>\Delta{H}</math>

MediaWiki replaces the math markup with a strip marker. Module:Citation/CS1/COinS can ask MediaWiki to render the equation associated with that strip marker. The module then extracts the raw-text equation for inclusion in the metadata. That's how it used to work and how it still works for PNG images and LaTeX source preferences. The method does not work for the MathML preference. For PNG images and LaTeX source, Module:Citation/CS1 renders the above title in the metadata like this:

&rft.btitle=%5CDelta%7BH%7D

Because of a new way of handling MathML, MediaWiki does not return the rendered equation but instead returns the strip marker. Module:Citation/CS1/COinS can do nothing with that so it inserts an error message in the metadata:

&rft.btitle=MATH+RENDER+ERROR

The discussion at WP:VPT listed above, produced nothing helpful so I've added this issue to Phabricator in the hopes that MediaWiki will be fixed someday.

What can you as editors do about your cs1|2 templates that have math markup in their titles? Nothing. Even if you set you preferences to PNG images and create a cached version of the page that has correct metadata, the next editor (or bot) who comes along and edits the page will produce a cached version that uses his/her/its math preference setting.

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

exclude templates and tags from metadata

made this topic its own topic—Trappist the monk (talk) 11:07, 21 June 2016 (UTC)

Is there a way to make somewhere a list or actually to add all templates (by namespace) to that list except citation ones so any other template ({{template, |, its parameters [this is the problem] and }}) used inside citation template is "excluded" when creating that COinS metadata? That would enable many useful templates (including my {{nowrap}}) to be used inside citation templates. Aside from templates, to "exclude" any tags such as <math></math>, <u></u>, <code></code> etc.--Obsuser (talk) 06:07, 21 June 2016 (UTC)

I'm pretty sure that I don't understand completely what it is that you're asking. If you are asking, "Can we exclude templates from cs1|2 templates?" then the answer is no. Templates within a cs1|2 template are processed first then the result of the internal template is handed to the cs1|2 template. For example, in this:

{{cite book |title={{nowrap|Long Title that shouldn't be Wrapped}}}}

MediaWiki does this first:

{{nowrap|Long Title that shouldn't be Wrapped}}

which replaces the |title= value with:

<span class="nowrap">Long Title that shouldn't be Wrapped</span>

which then gets handed to Module:Citation/CS1

{{cite book |title=<span class="nowrap">Long Title that shouldn't be Wrapped</span>}}

For tags like <u>...</u> and <sup>...</sup>, it has been in the back of my mind to remove or somehow replace these before the metadata are created but I haven't yet gotten round to it.

—Trappist the monk (talk) 11:07, 21 June 2016 (UTC)

I don't know where/when/how is COinS created but maybe there is a possibility to recognize any expanded template used in a citation template and not include it (delete it) from that metadata. If it is encoded so it becomes metadata, it should be possible to delete it afterwards from that metadata by matching values of template content converted to metadata. Nowrap will create its own, unique metadata in UTF or whatever, and that should be just deleted; only author name, surname, years interval, publisher name with a hyphen etc. would then be left as the useful data. This is only a theory, of course; it is maybe/probably impossible...

Another question is why is why is COinS so important, after all? Also, can it be created another way (by directly "excluding" template parts [{{template, |, its parameters [this is the problem] and }}] and not to deal with more complicated converted-in-UTF-or-whatever text)? These problems are more for phab technicians, not Wikipedia editors; however, [almost] nothing gets resolved there either, so it becomes pointless to discuss something that will be resolved in ten or twenty years untill when whole current technology or Wikipedia might get deprecated.--Obsuser (talk) 12:37, 21 June 2016 (UTC)

There is one experiment in Module:Citation/CS1/COinS that does what you have suggested:

value = value:gsub ('<span class="nowrap" style="padding%-left:0%.1em;">&#39;(s?)</span>', "'%1");	-- replace {{'}} or {{'s}} with simple apostrophe or apostrophe-s

As you can see, it isn't pretty. If ever either of those two templates ({{'}} and {{'s}}) is changed for any reason, the code breaks.

Because the old Wiki markup templates had COinS metadata? The first discussion that I've found about adding it is here ({{cite book}} and the cs1 templates). There was another here ({{citation}}). COinS is here now because of that 2006 decision. Since then, who knows how many editors have consumed cs1|2 references through the metadata and external reference management tools so it is here to stay.

—Trappist the monk (talk) 13:41, 21 June 2016 (UTC)

|dead-url=unfit maintenance category

Cyberbot II has apparently been setting |dead-url=unfit for every cs1|2 template that it touches (see this insource search). I have added code to the module sandbox to place articles with templates using |dead-url=unfit and |dead-url=usurped into a maintenance category so that these articles can be inspected and repaired.

Cite book comparison

Wikitext	{{cite book|archive-date=2016-06-20|archive-url=//example.org|deadurl=unfit|title=Title|url=//example.com}}
Live	Title. Archived from the original on 2016-06-20. {{cite book}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)
Sandbox	Title. Archived from the original on 2016-06-20. {{cite book}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 11:05, 20 June 2016 (UTC)

I misspoke. Cyberbot II sets |dead-url=unfit when it moves an archival url from |url= to |archive-url= leaving behind the original url in |url=. An example of this can be seen at Atmosphere of Pluto.

Other discussion is at the bot operator's talk page. The RfC mentioned there is here.

—Trappist the monk (talk) 14:47, 20 June 2016 (UTC)

As a result of the conversation at the bot operator's talk page, I have modified the sandbox to include a new |dead-url= keyword bot: unknown. This form serves a couple of purposes: 1) it is in keeping with the semantics established in the conversations (beginning, conclusion) we had about the |dead-url= keywords. The new keyword describes the reason that the original url link is disabled and also indicates that the parameter value is for and used by bots; and 2) it's long so that it's a pain to type which may (or not) dissuade editors from using it to hide the original url link. (Because this keyword is for bots, length is not really important so we could have the keyword be similar to the proposed maintenance category name bot: original-url status unknown, for example.)

"Title". Archived from the original on 2016-06-21. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

Opinions?

—Trappist the monk (talk) 15:45, 21 June 2016 (UTC)

How to cite an anthology

Is this correct

• Jackson, Peter; Lockhart, Laurence, eds. (1986). The Timurid and Safavid Periods. The Cambridge History of Iran. Vol. 6. Cambridge: Cambridge University Press. ISBN 9780521200943. {{cite book}}: Invalid |ref=harv (help)

Alexis Ivanov (talk) 22:32, 16 June 2016 (UTC)

That would be correct for an anthology that collects a number of anonymous works together. A quick check of Wikibooks allowed me to determine the book you cite lists the authors of each chapter. As a result, I would recommend something along the lines of:

• Roemer, H. R. (1986). "The Safavid Period". In Jackson, Peter; Lockhart, Laurence (eds.). The Timurid and Safavid Periods. The Cambridge History of Iran. Vol. 6. Cambridge: Cambridge University Press. pp. 189–350. ISBN 9780521200943. {{cite book}}: Invalid |ref=harv (help)

The down side to this is that you will need a full citation for each chapter you reference. --Allen3 ^talk 23:17, 16 June 2016 (UTC)

That is why there is {{harvc}}; one cs1 template for the whole work, and a {{harvc}} for each chapter.

—Trappist the monk (talk) 23:32, 16 June 2016 (UTC)

Thank you for your help guys, this is excellent, one more question, CS1 uses The Chicago Manual of Style?, but why is the date not at the end, I'm conflicted, I'm thinking of adopting this style for my own writing and getting rid of MLA, to be honest I didn't know what rule I was following till know. Alexis Ivanov (talk) 03:23, 17 June 2016 (UTC)

No, cs1|2 is an amalgam of Chicago, MLA, APA, ...; in a word a mutt.

—Trappist the monk (talk) 11:13, 17 June 2016 (UTC)

But it's our mutt, and we love it so! --Izno (talk) 11:18, 17 June 2016 (UTC)

I'd say that it's probably close to an "average" of styles used by different sources. Certainly CS2 closely resembles a style I taught for well over 25 years, and CS1 essentially differs only in the ugly stops instead of commas. Peter coxhead (talk) 13:40, 17 June 2016 (UTC)

Thanks for the information, bookmarked so I can read it later Alexis Ivanov (talk) 17:52, 21 June 2016 (UTC)

deprecate |dead-url=?

made this topic its own topic—Trappist the monk (talk) 19:58, 21 June 2016 (UTC)

First, as was suggested in the past, rename |dead-url= to |url-state=.

Then, switches could be renamed ("yes"→"dead", "no"→default – original is live) or re-used ("unfit", "usurped").

Finally add new switches per your post above eg "bot", "dnd"→do not display (original), "ogk"→only god knows etc.

65.88.88.127 (talk) 19:00, 21 June 2016 (UTC)

|url-state= was suggested in this conversation.

For a long time I have wanted to deprecate |dead-url= simply because it is inconsistent with all of the other |<something>-url= parameters which contain, not surprisingly, urls. Assuming for the sake of discussion that we accept |url-state=, it would need to be a parallel parameter with |dead-url= simply because we can't change them all overnight, nor are we going to be able to wean editors off of |dead-url= as quickly as we might like. That means that there will be two lists of appropriate keywords meaning the same thing so the code will get a bit uglier until |dead-url= is finally abandoned. In a year? two years?

—Trappist the monk (talk) 19:58, 21 June 2016 (UTC)

Let's kill |dead-url=. Could a bot-assisted insource search-and-replace happen in article namespace? That may speed up things, and get rid of the requirement for added arguments, aliases etc. If it can be done, I think first a list of valid options (and option labels) for the parameter should be agreed. Then option-labels should be replaced first (if different) before proceeding to replace the parameter label itself. 72.43.99.146 (talk) 00:03, 22 June 2016 (UTC)