Template talk:Cite web/Archive 4
This is an archive of past discussions about Template:Cite web. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | Archive 6 |
This template spreads U.S. centrism across British English articles
This template should be deleted as it is U.S. centric. It requires people to enter dates in U.S. numerical format (month first), which can lead to errors, and it displays dates in U.S. format, which is insensitive and a violation of the principle that British English has equality. Unless these issues can be completely overcome, it should be deleted. Postlebury 10:15, 1 September 2007 (UTC)
- So is there a speedy delete tag? What is the process for getting rid of this template? Tony 10:42, 1 September 2007 (UTC)
- In fact, the day-month-year format is not British, it is used all over the world except in the United States. Still, I don't see the problem, because you can change the way of displaying dates by going to your preferences. Melsaran (talk) 10:59, 1 September 2007 (UTC)
- Sorry, you're wrong. None of the three numerical dates (date=, accessdate=, and archivedate=) require the format you mention nor do they force a US display style. The accessdate= and archivedate= parameters must be entered in yyyy-mm-dd format and are displayed according to the reader's preferences. The date= parameter is displayed exactly as entered by the editor, and can be formatted according to the reader's preference at the editor's discretion. RossPatterson 12:23, 1 September 2007 (UTC)
- He appears to believe that because "year-month-day" is a US format because it contains "month-day", despite it being an international standard, the US format being "month/day/year", and YMD order in everyday usage being primarily the case in eastern european and asian countries rather than north america --—Random832
Should support omitting url
url should not be a required parameter when archiveurl is provided, to allow to cite sources that are no longer available except from the archive. —Preceding unsigned comment added by Random832 (talk • contribs) 17:03, 21 September 2007 (UTC)
- But even on archive sites, it'll tell you what the original URL was, right? Besides, you never know when the original page might come back online. --zenohockey 22:27, 23 September 2007 (UTC)
- But what if the domain name is gone (i.e. now owned by spammers, etc), so we would not want to link to it? —Random832 18:15, 3 October 2007 (UTC)
- I think a better solution would be to not activate the _URL_ link when _archiveurl_ is present. In other words, for _Cite web_ only one link to the source should be active – URL or ARCHIVEURL. --User:Ceyockey (talk to me) 13:44, 22 March 2008 (UTC)
- But what if the domain name is gone (i.e. now owned by spammers, etc), so we would not want to link to it? —Random832 18:15, 3 October 2007 (UTC)
Hanging indent proposal
For a proposal to add an optional formatting parameter to this and related citation templates, which would allow display as a hanging indent, see this discussion. --cjllw ʘ TALK 04:49, 25 September 2007 (UTC)
AGAIN: Redundant word "on" before the date
Someone has wrongly archived my query about this glitch (it's right at the end of the most recent archive).
Here is the previous text.
I wonder whether someone here can remove this word from the template; it's appearing in the thousands all over the place, and is quite unnecessary (= irritating). This issue has come up in the FAC room. Tony 13:49, 28 August 2007 (UTC)
This may be a minor issue to some, but as I am currently suffering in said FAC room, here is my tuppence worth. WP:CITE#Embedded Links suggests the format: Accessed [[October 27]] [[2005]]., which is of course what many editors choose to do (although 'Retrieved' seems to be the standard verb at present). If an article ends up with a mixture of reference types those using 'citeweb' will say 'Retrieved on' and those using the standard embedded link will say 'Retrieved'. Editors accused of inconsistency thus have to amend all the standard ref tags, or remove all the citeweb templates, which is a nuisance (=very irritating). My conclusion is that the template is in minor breach of WP:CITE and that one or other of them should be changed. Ben MacDui (Talk) 09:15, 30 August 2007 (UTC)
- Yep, the template needs to be changed. Inconsistency is bad, and so is a redundant word, especially when repeated ad infinitum through a work list. I have no option but to discourage the use of the template unless this change is made. Tony 09:45, 30 August 2007 (UTC)
I ask again why this template should not be deleted, since no one seems willing to fix up this redundant word that is now scattered through WP's reference lists, inconsistently within lists, of course, since manual entries are usually required as well.
Can we have some action on this? It can't be very hard. Tony (talk) 02:37, 30 September 2007 (UTC)
- I guess your question 'why shouldn't this be deleted' is more a rhetorical one borne of irritation, than a serious proposal to delete a template used across many thousands of articles on the basis of a possibly unnecessary word. I don't quite see the inconsistency, given that it seems that all of the various templates commonly used for formatting references that have this field ({{cite journal}}, {{cite news}}, {{cite conference}}, and a few others listed at WP:CITET) display as "Retrieved on [date]". The example given for the embedded link at WP:CITE would itself appear to be the odd-one-out. IMO, I don't think that example's formatting is meant to be definitive, just illustrative. If there are issues arising at FAC because references which are manually formatted don't exactly match those that are generated by one of the templates, then why wouldn't the remedy be to make the manually coded match the templates' outputs? Or, if typographical consistency is a dealbreaker there, why not convert the discrepant embedded links-style references to the appropriate template? --cjllw ʘ TALK 14:43, 30 September 2007 (UTC)
- Because the word on is redundant. Yes, it certainly is irritating. Why can't someone fix it? Does it take more than two minutes? Tony (talk) 15:05, 30 September 2007 (UTC)
You will perhaps forgive my confusion here. WP:CITE is a guideline that "is generally accepted among editors and is considered a standard that all users should follow." This template and others does something that produces a result different from that guideline. This in turn means that you expect me to waste my time amending references so that either they contradict WP:CITE or that this template is removed from the article in question. This is an absurd, even Kafkaesque situation that is not acceptable. Two solutions make sense to me. Either the template (and the others if necessary) should be changed, or we can agree to continue the discussion at WP:CITE. The idea that a template should de facto over-rule a style guideline is absurd. Ben MacDui (Talk) 20:59, 30 September 2007 (UTC)
- WP:CITE points to Wikipedia:Embedded citations "[f]or more details". Wikipedia:Embedded citations has two examples, one hand-coded and the other generated by {{cite news}}. Both say "Retrieved on". RossPatterson 01:55, 1 October 2007 (UTC)
- Sorry, why is removing the errant word "on" anything to do with following a standard or guideline? Where is the code, so I can do it myself? Tony (talk) 01:31, 1 October 2007 (UTC)
- The code is right here in this template. However, it has been protected so that only an admin can edit it. Pagrashtak 19:47, 1 October 2007 (UTC)
- Even admins don't edit this template much. It is used extremely often, so it takes along time for a change here to move through the job queue, which is a nuisance for other editors. And a change here changes thousands of articles, so there has to be very clear consensus for the cite templates to be changed. — Carl (CBM · talk) 15:54, 3 October 2007 (UTC)
- The code is right here in this template. However, it has been protected so that only an admin can edit it. Pagrashtak 19:47, 1 October 2007 (UTC)
The word "on" is not redundant, it's proper grammar. Just like how you say "I went to the store on 9 September" and not "I went to the store 9 September". Melsaran (talk) 19:37, 1 October 2007 (UTC)
In the context of a list of external references, between "Retrieved" and "[date]", it most certainly is redundant. It's irritating to read scores of them in a row. Tony (talk) 07:34, 2 October 2007 (UTC)
- I don't think Tony's complaint is that it is ungrammatical, just not necessary. And yes, it would be a relatively trivial change mechanically, but if done should also be done for all of the half-dozen or more templates which are presently phrased that way. I don't know when or what prompted the template standardisation to "Retrieved on", but it would probably be best to propose said change at somewhere more central like Wikipedia talk:Citing sources as other templates would be involved, and FAIK others may take a different view. --cjllw ʘ TALK 04:02, 2 October 2007 (UTC)
- Of course it's necessary, it's proper grammar. "Retrieved 9 September" is not proper English, at best it could be considered telegram style. Melsaran (talk) 17:45, 3 October 2007 (UTC)
- Rubbish: particularly in AmEng, on is typically absence even before days of the week (We finished the job Tuesday). While I would not use that phrase, I would certainly remove on as quite unnecessary to the sense here in the context of a list of web cites, which is in the category of short text in any case (titles, headlines, notices, etc). Are you telling me that the meaning is unclear without on? No. It is not ungrammatical, as you seem to think. It has to go. Tony (talk) 00:50, 11 October 2007 (UTC)
- With "retrieved on 9 September", we mean "This reference was retrieved on 9 September". "Retrieved 9 September" (without the "on") could also mean "9 September was retrieved". Just like how "retrieved my lost possessions" means "my lost possessions were retrieved". Although it's not really confusing in this context, this is another example that illustrates why "Retrieved 9 September" is bad grammar. Melsaran (talk) 22:55, 11 October 2007 (UTC)
- Don't confuse ambiguity with "bad grammar": they're very different. Grammar is not at issue here. Who on earth would take it as meaning that the editors were retrieving 9 September? How ridiculous. There's no ambiguity in the context of a huge list of retrieval dates for weblinks.
- If people are so offended by the removal of "on", why not clean up the wording by changing it completely: "Retrieval date 9 September 1980"? But the shorter and simpler "Retrieved" is preferable. Tony (talk) 03:23, 12 October 2007 (UTC)
- With "retrieved on 9 September", we mean "This reference was retrieved on 9 September". "Retrieved 9 September" (without the "on") could also mean "9 September was retrieved". Just like how "retrieved my lost possessions" means "my lost possessions were retrieved". Although it's not really confusing in this context, this is another example that illustrates why "Retrieved 9 September" is bad grammar. Melsaran (talk) 22:55, 11 October 2007 (UTC)
- Rubbish: particularly in AmEng, on is typically absence even before days of the week (We finished the job Tuesday). While I would not use that phrase, I would certainly remove on as quite unnecessary to the sense here in the context of a list of web cites, which is in the category of short text in any case (titles, headlines, notices, etc). Are you telling me that the meaning is unclear without on? No. It is not ungrammatical, as you seem to think. It has to go. Tony (talk) 00:50, 11 October 2007 (UTC)
- Of course it's necessary, it's proper grammar. "Retrieved 9 September" is not proper English, at best it could be considered telegram style. Melsaran (talk) 17:45, 3 October 2007 (UTC)
Please remove the word "on" from this and all similar templates
{{editprotected}}
As discussed here and on the related talk page, this word is redundant, and should be simply removed so that tens of thousands of "ons" are no longer scattered through lists of external links. Thus: "Retrieved on [date]" should simply be "Retrieved [date]". Tony (talk) 14:57, 3 October 2007 (UTC)
- This was discussed above and there doesn't appear to be any consensus in making this change. As per my comments on the above proposal, this change would also break existing uses where a mixture of cite * and manually added ref entries (conforming to the cite format) have been used. It needs wider discussion. → AA (talk) — 15:25, 3 October 2007 (UTC)
- It will require very clear consensus to change the cite template this way, since the change will affect thousands of articles. For now I am disabling the editprotected tag. — Carl (CBM · talk) 15:51, 3 October 2007 (UTC)
- In which case, I'll advise everyone I come into contact with at FAC, FAR/C and elsewhere not to use the template. Tony (talk) 15:53, 3 October 2007 (UTC)
- Considering that I don't see any strong opposition, I'd suggest you first discuss at Wikipedia talk:Citing sources as suggested in the earlier section and see if you can get consensus to change all citation templates. Pagrashtak 16:11, 3 October 2007 (UTC)
- Agree. The main opposition is that thousands of articles which have used these templates that also have manually added references where "Retrieved on" has been used, will need to be updated to remove the "on". Not a difficult task for a bot. I would suggest seeing if one of the bots (User:MetsBot seems appropriate) is willing to take on this task. If you can show that a bot has been lined up to fix the manual entries, then there shouldn't be any opposition. → AA (talk) — 16:18, 3 October 2007 (UTC)
- Considering that I don't see any strong opposition, I'd suggest you first discuss at Wikipedia talk:Citing sources as suggested in the earlier section and see if you can get consensus to change all citation templates. Pagrashtak 16:11, 3 October 2007 (UTC)
- It's quite petty for you to advise people not to use this template over one word. -- tariqabjotu 18:36, 3 October 2007 (UTC)
- That's as maybe, but what is quite extraordinary is that there does not seem to be any sane way to codify Wikipedia's house style without recourse to obtaining separate sets of 'consensus' on disparate pages. Candidly I don't much care whether the 'on' is used or not, but it is patently absurd for it to be required by one system whilst omitted on another. I tend to avoid using citeweb, but its ten to one that just as I am preparing an article for some kind of review a well meaning editor will come along and add a few citeweb refs or change some existing one to use the template. This results in a quite unnecessary mess. In my view what is requited is a 'style committee' of some sort to deal with these issues and create a coherent set or protocols, rather than a set of semi-independent referencing mini-empires. Ben MacDui (Talk) 19:38, 3 October 2007 (UTC)
- AA, I first noticed inconsistency because many users omit "on" in their manual entries, creating inconsistency with their citeweb entries. Better to remove the errant "on" altogether. I don't understand why it should be a bureacratic nightmare to to this. Tony (talk) 23:17, 3 October 2007 (UTC)
Remove parameter list
{{editprotected}} An ugly orange box for the not-enough-parameters error was added to this template via the archived discussion here. Apparently the reason for this was to encourage people to fix the broken templates. Now we have Category:Articles with broken citations, however, which currently contains no articles from mainspace. The category is a sane and not jarring way of getting broken templates fixed, in my opinion, and we should replace
<div style="border:1px solid red; background-color:#ffdab9; display:table;"> You must specify '''''title = ''''' and '''''url = ''''' when using {{tl|cite web}}. Available parameters: {{Cite web/doc/parameterlist}} </div>
with
Error on call to [[Template:cite web]]: Parameters '''archiveurl''' and '''archivedate''' must be both specified or both omitted
which was there before. If this has consensus, I would appreciate if the same change could be made to {{cite news}}. GracenotesT § 19:33, 4 October 2007 (UTC)
- At a minimum, the current text should be retained, rather than reverting to the older "Error on call ..." garbage (I can call it that, I wrote both texts :-) ). RossPatterson 22:40, 4 October 2007 (UTC)
- On review, I can't say I disagree with your name for the earlier version. The text (You must [...] {{cite web}}) currently there is fine, just without the box and the parameter list. Really, whichever text is fine; I merely disagree with the presentation. GracenotesT § 02:13, 5 October 2007 (UTC)
Could an admin implement the above changes (remove the div and parameter list), unless there is further discussion? Also, please substitute all instances of {{tl}} in this template: no need to have it transcluded when the code will work fine by itself. GracenotesT § 02:22, 21 October 2007 (UTC)
- Done. --- RockMFR 23:12, 21 October 2007 (UTC)
- Thank you. GracenotesT § 18:54, 22 October 2007 (UTC)
Error category should only be applied in article namespace
{{editprotected}} After policing Category:Articles with broken citations for a few months, I've come to the conclusion that only articles should be placed in that category. I think it's still a good idea to display the error messages ("You must specify ...") any time the template is used incorrectly, but there's no need to flag things like user-page examples or talk-page samples for repair. I've made the necessary modifications and put the result in User:RossPatterson/cite web, could an admin please replace this template with that copy? RossPatterson 16:54, 3 November 2007 (UTC)
- Sounds like a reasonable proposal -- article space is the only one we really need to be presentable to the public, and so the most pressing concern. On such a widely used template, of course, discussion prior to changes is probably a good idea. I see this is also requested at Template talk:Cite news, I'll drop off a link there. Feedback or opinions, anyone? – Luna Santin (talk) 04:24, 4 November 2007 (UTC)
- Agree – talk/user pages should not be listed in the category. → AA (talk) — 09:31, 4 November 2007 (UTC)
There seems to be agreement for this, but no actual code. Editprotected requests are for changes that have general agreement and can be put in place immediately. For complex highly-used templates such as this, someone needs to write and test the code first, before it is is made live. If you need help doing that, you can ask at Wikipedia:Requested templates. Once there is agreement on a particular solution to this issue, please make a new editprotected request and the code will be made live. — Carl (CBM · talk) 16:43, 6 November 2007 (UTC)
- The code has already been written and tested. It's at User:RossPatterson/cite web as noted above, and it passes all the examples in Template:cite web/doc including an error-generation test case that I added and temporarily disabled until the editprotected is done. It's ready to go. If you prefer to see the code change, it is simply replacing the two occurrances of
[[Category:Articles with broken citations]]
with{{#if: {{NAMESPACE}}|| [[Category:Articles with broken citations]]}}
. RossPatterson 02:22, 7 November 2007 (UTC)
Automatic date wikilinking
It's really counterintuitive how the current version of this template requires that the date
parameter be wikilinked (for example, date=[[2007-11-08]]), but the accessdate
parameter must not be wikilinked (for example, accessdate=2007-11-08). I propose that we fix this by automatically wikilinking the date parameter if it is not passed in wikilinked. This would allow for the parameter to be passed in easily as date=2007-11-08 while not breaking the old-style date=[[2007-11-08]].
To do this, we would change the two lines that read:
| ({{{date}}})
To read:
| ({{#ifeq:{{#time:Y-m-d|{{{date}}}}}|Error: invalid time|{{{date}}}|[[{{{date}}}]]}})
For now, you can try out these changes using User:Remember the dot/Sandbox. Here are a couple of examples of how it would work:
{{cite web |url=http://www.markschenk.com/opera/history.html |title=Opera browser version history |last=Schenk |first=Mark |date=2007-01-06 |accessdate=2007-10-24 }}
Schenk, Mark (2007-01-06). Opera browser version history. Retrieved on 2007-10-24.
{{cite web |url=http://www.markschenk.com/opera/history.html |title=Opera browser version history |last=Schenk |first=Mark |date=[[2007-01-06]] |accessdate=2007-10-24 }}
Schenk, Mark ([[2007-01-06]]). Opera browser version history. Retrieved on 2007-10-24.
In time, all the old instances of date=[[2007-11-08]] would be transitioned to date=2007-11-08 (this could perhaps be done by bot) and then we could simplify the code further by removing the backwards-compatibility for date=[[2007-11-08]].
Any thoughts? —Remember the dot (talk) 20:22, 8 November 2007 (UTC)
- Considering the number of people that come by this page and "demand" that the accessdate be unwikilinked, getting the date parameter wikilinked is probably going to be a tough sell. Also, your code doesn't seem to properly account for the multitude of dates that are input as Month Day, Year or Day Month Year.
- Schenk, Mark (6 January 2007). Opera browser version history. Retrieved on 2007-10-24.
- A bot would definitely have to go through and force those through into ISO format. --Bobblehead (rants) 22:17, 8 November 2007 (UTC)
- Hmm, that is a problem. But still, we need to find a way to make the
date
andaccessdate
parameters behave the same way for consistency. Surely there's another way that would allow for a relatively easy transition to automatic wikilinking. Give me some time to experiment. —Remember the dot (talk) 23:21, 8 November 2007 (UTC)
- Hmm, that is a problem. But still, we need to find a way to make the
The formats of the date values and the accessdate values are quite different. Accessdates can and should be in a consistent format throughout an article. The publication dates are quite different, as they should (arguably) be in the format used by the original publisher. Remember, most of the information in citations is to help readers find the sources. Consistency is preferred in format, but not in the actual data that is presented. --- RockMFR 03:52, 9 November 2007 (UTC)
- I assume you primarily mean not turning "January 2007" into some form of "January 1, 2007", right? A correctly-written citation for such a date wouldn't use date=January 2007 anyway, but rather month=January and year=2007. But you're absolutely correct about the purpose of all this! RossPatterson 04:21, 9 November 2007 (UTC)
- No, that would not happen. —Remember the dot (talk) 05:52, 9 November 2007 (UTC)
OK, how about if we change
| ({{{date}}})
To read:
| ({{#ifeq:{{#time:Y-m-d|{{{date}}}}}|{{{date}}}|[[{{{date}}}]]|{{{date}}}}})
That would automatically wikilink only dates that are in YYYY-MM-DD format, giving us consistency with the accessdate
parameter while not breaking things like date=January 1, 2007. —Remember the dot (talk) 05:52, 9 November 2007 (UTC)
- If it restricts auto-linking to only YYYY-MM-DD formats and ignores already linked or other format dates, then I think it won't break existing uses of the template and therefore should not be a problem. → AA (talk) — 10:48, 9 November 2007 (UTC)
- That's a cute trick:
- {{#time:Y-m-d|2007-01-02}} = "2007-01-02" which matches "2007-01-02" so we get "(2007-01-02)".
- {{#time:Y-m-d|[[2007-01-02]]}} = "Error: Invalid time." which doesn't match "[[2007-01-02]]", but it is already linked, so we get "(2007-01-02)".
- {{#time:Y-m-d|January 2, 2007}} = "2007-01-02" which doesn't match "January 2, 2007", so we get "(January 2, 2007)".
- {{#time:Y-m-d|January 2007}} = "2007-01-01" which doesn't match "January 2007", so we get "(January 2007)".
- {{#time:Y-m-d|[[January 2]], [[2007]]}} = "Error: Invalid time." which doesn't match "[[January 2]], [[2007]]", but it is already linked, so we get "(January 2, 2007)".
- {{#time:Y-m-d|01/02/07}} = "2007-01-02" which doesn't match "01/02/07", so we get "(01/02/07)", which is still ambiguous but that's how it started.
- I think it covers all the bases. RossPatterson 23:19, 9 November 2007 (UTC)
Comment: Please note that date=
is also used in various fashions, such as with qualifiers after the date, depending on various cases.
- For instance, when there is no way to have any information about the date of a document (including HTTP Last-Modified), I'll just put "2007 online" (all I know is that the document exists now in 2007 and that's the version I've read for sourcing) or "2007 copyright" (if that's all the page gives for date). Same when I'm consulting a non-archivable database page such as Library of Congress, I'll put the date as "2007 online", in line with the more complete
accessdate=
.
- In that case, you ought to simply provide
accessdate
and notdate
. "2007 online" implies that the document was modified in 2007, when what you really meant is given later in the citation: "Retrieved on 2007-11-10". —Remember the dot (talk) 17:54, 10 November 2007 (UTC)
- In that case, you ought to simply provide
- Also, when I can get an Archive.org or Webcite stable url, and I see the page has been non-trivially changed/revised many times, I will qualify the date with "[[YYYY-MM-DD]] revision" (if I could extract it from HTTP Last-modified) or maybe just "YYYY update" (if I don't have the exact date but only the "archive was updated" dates, or if I can stuff the full date in another field).
- The archivedate= parameter is a better choice for that sort of date. RossPatterson 15:27, 10 November 2007 (UTC)
- The qualifier is useful to inform that it comes from one revision of a mercurial online document. Also, my trying to always get a year (even if with qualifier) is to help with using Author-Year cites in <REF>: by at least labelling an undatable document "2007 online", I can make a <REF NAME="DOE-2007">Doe 2007</REF>.
- This is another case where the archivedate= parameter might be a better choice. RossPatterson 15:27, 10 November 2007 (UTC)
- Also, I've seen uses such as "date=YYYY, [[Month Day]]", which are identically intended to provide both the full date, and a more easily parsable list of "Author-Year" references: when you get an endnote such as "Foo 1994" and you have a long list of references, including 10 books by Foo, I think you are happy to see the year come first in the parentheses.
Anyway, it looks like the proposal above by RossPatterson won't break those cases, but it's better if y'all are aware they also exist. — Komusou talk @ 07:18, 10 November 2007 (UTC)
- It's Remember the dot's proposal, not mine, but I like it :-) RossPatterson 15:21, 10 November 2007 (UTC)
{{editprotected}}
Since it's been a few days and there do not appear to be any objections, I propose that this change be implemented. For reference, the two lines that read
| ({{{date}}})
Should be changed to:
| ({{#ifeq:{{#time:Y-m-d|{{{date}}}}}|{{{date}}}|[[{{{date}}}]]|{{{date}}}}})
—Remember the dot (talk) 19:17, 12 November 2007 (UTC)
- Because this is the type of thing that has drawn large amounts of complaints before, I think it would be prudent to announce it at the proposals village pump first. This is not a comment on the merits of the change, only the voice of caution from experience. It does seem reasonable the dates formats should match. — Carl (CBM · talk) 01:59, 13 November 2007 (UTC)
- I think previous complaints were due to the proposed changes "breaking" existing uses of the template. This proposal is fully "backwards compatible" and therefore is uncontroversial. However, it is nevertheless worth publicising in the village pump so that editors are aware of the enhancement. → AA (talk) — 07:30, 13 November 2007 (UTC)
- It has been publicized, both here and because of CBM's comment, here. Since, like you said, it's fully backwards-compatible, it shouldn't be too controversial. —Remember the dot (talk) 07:51, 13 November 2007 (UTC)
{{editprotected}}
Still no complaints. Would it be all right if we implemented the change now? —Remember the dot (talk) 21:52, 14 November 2007 (UTC)
- I'd go ahead and do it, personally. --Bobblehead (rants) 20:54, 16 November 2007 (UTC)
Order of display
How come full publication dates are displayed just after the author's name instead of after the title and publisher (as is already done with partial dates)? It look odd and does not fit any citation standards I am aware of.
For Example:
- Lambert, David (11/12/2007). Stingray – Cover Art for Cannell's Complete Series. TVshowsOnDVD.com. Retrieved on 2007-11-14.
would look much better as: - Lambert, David. Stingray – Cover Art for Cannell's Complete Series. TVshowsOnDVD.com. (11/12/2007) Retrieved on 2007-11-14.
—MJBurrage • TALK • 22:48, 14 November 2007 (UTC)
Hmm... /doc not visible
All of the sudden the transcluded /doc page is not showing up, but it is there can can be edited, and can be viewed on its own page. I skimmed the code and didn't see anything obvious, like a stray noinclude. Weird. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:29, 25 November 2007 (UTC)
Why is the date wikilinked?
There is an editor opposed to using this citation template for the sole reason that it automatically wikilinks the date. So I have two questions:
- Why is the date automatically wikilinked?
- Is there some way to turn off the automatic wikilinking of dates?
–panda (talk) 15:57, 27 November 2007 (UTC)
The date and accessdate are wikilinked so that users can have the date displayed according to their preferences. According to the Manual of Style, all dates with a day, month and year should be wikilinked. See also this page. There is no way to turn off this feature as far as I know, and it shouldn't be turned off as it is useful and mandated by the MOS. Lurker (said · done) 16:41, 27 November 2007 (UTC)
- Actually, it seems you can create a non-wikilinked retrieval date using the fields accessmonthday (or accessdaymonth) and accessyear and a non-wikilinked date using the fields month and year (although this doesn't allow you to put the day in). See the template page for instructions on how to do this. Quite why you'd do this is beyond me- it means users would not be able to choose how these dates are displayed. And it goes against the MOS. However, if it is important that you have a full non-wikilinked publication date, I'm sure a monthday and daymonth field could be added. Lurker (said · done) 16:59, 27 November 2007 (UTC)
- It would be much nicer to have a flag that allows you to turn off auto wikilinking of dates. At any rate, I'll see if bringing up the MOS changes this other editor's mind about wikilinking dates. –panda (talk) 17:21, 27 November 2007 (UTC)
- I mentioned your points and the editor doesn't seem convinced. Could you please make a comment about this in Talk:Swedish language? –panda (talk) 20:02, 27 November 2007 (UTC)
- Could we get som sense into this discussion? For one thing, the MoS is clearly supposed to regulate article content, not notations concerning when some Wikipedian checked a certain website, and it's not something that has to be slavishly obeyed unless everyone accepts a written counter-mandating guideline (a rather good example of instruction creep). The dates in references (even the publishing dates) are without almost any exceptions non-notable events with zero relevance to the article topic or the events that are listed in the articles of individual dates or years.
- Moreover, the idea that the incessant linking of any full date anyone can find in an article would somehow lead to readers being able to choose not to have those links displayed is patently ridiculous. Most readers aren't registered users, and out of the very few registered users only a small percentage will probably ever bother to tweak the preferences. For all practical purposes, it's something that only concerns established Wikipedians, and this is certainly a group of individuals who could certainly be bothered with the vexing task of typing in a date in the search field manually.
- Peter Isotalo 14:26, 29 November 2007 (UTC)
- There's plenty of sense in WP:OVERLINK#Dates and WP:DATE#Autoformatting and linking already. Painting "consistent use of date autoformatting markup" as "incessant linking" misses the point. If the benefit is limited to a small percentage, that is still a reason to use it, for that (perhaps small) benefit, unless the detriment outweighs it. And there is no apparent detriment. Nobody's being yelled at for including dates without the formatting markup, but there is no reason to get into an edit war when another editor includes the markup. -- JHunterJ (talk) 15:46, 29 November 2007 (UTC)
- Linking the dates that some Wikipedian retrieved a web reference is not in any way significant to any article. It has no encyclopedic relevance whatsoever. As for no reason into getting into an edit war over an issue like this: WP:KETTLE.
- Peter Isotalo 12:00, 3 December 2007 (UTC)
- Speaking of kitchenware... this looks like a tempest in a teapot. I don't see why linked dates in this template are something to make a big deal about. If there is some editor who refuses to use these templates due to those date links... well... fine. I think that's a petty reason to not use this template at all, but (s)he can do whatever (s)he wants. Many believe there should be some way to format dates without linking them, but this is not an issue specific to this template. -- tariqabjotu 15:42, 3 December 2007 (UTC)
This issue has now been brought up in Wikipedia talk:Manual of Style (dates and numbers)#Linking full dates. –panda (talk) 17:50, 7 December 2007 (UTC)
- Lurker, you say it's done that way so that users can display the date according to their preferences. All right. As a user, it's my preference to display dates as plain, black text without any link to irrelevant pages about Gregorian calendars that I might click by mistake hoping I'm going to load an online copy of an article. How do I set it up to display it like that on all pages that use that format? --Coppertwig (talk) 00:57, 20 January 2008 (UTC)
- Petition the Wiki programmers to add that option to "my preferences". -- JHunterJ (talk) 03:21, 20 January 2008 (UTC)
Pages parameter
pages: pp. 5–7: first page and optional last page. This is for listing the pages relevant to the citation, not the total number of pages in the book.
I don't quite understand what is the proper way to insert the page number in the "pages" parameter. Am I suppose to enter only the corresponding page number into the pages parameter, such as "12", or am I suppose to enter "pp. 12" or "p. 12", following the example given? --Silver Edge (talk) 03:27, 30 November 2007 (UTC)
- If you want "p. 12" or "pp. 5–7" to show up, enter exactly that. If you just enter "12", there will be no "p.". Whether the "p." is desired or not is a matter of style. Anomie⚔ 14:01, 30 November 2007 (UTC)
Interesting template problem
I am having an interesting (or weird depending on your perspective) problem with the cite web template. The author name refuses to display the first word. Here is an example:
[Taxonomic Information System (ITIS)]. Standard Report Hieracium caespitosum (HTML). Retrieved on 2007-12-15.
Which should look like:
Integrated Integrated Taxonomic Information System (ITIS). "Standard Report Hieracium caespitosum" (HTML). Retrieved 2007-12-15. {{cite web}}
: Check |authorlink=
value (help); External link in
(help)
|authorlink=
Thanks for your attention (when I get it) -- carol 13:00, 15 December 2007 (UTC)
- "authorlink" is not for external links, but to links to the author's Wikipedia entry:
- Integrated Taxonomic Information System (ITIS). "Standard Report Hieracium caespitosum" (HTML). Retrieved 2007-12-15. -- JHunterJ (talk) 16:08, 15 December 2007 (UTC)
- Well, that is quite interesting and possibly a pain for fixing where I have used it wrongly ;)
- I actually dislike that kind of link in most places I have accidentally encountered it -- I think the last time I noticed that I did not like that quality was when I wanted to get to wiktionary or wikispecies quickly and wondered the reason my searches kept landing me here again.
- So, I hacked the template then? Heh, not if the examples above are how mine are working. Eek! -- carol 19:14, 15 December 2007 (UTC)
Fix formatting
{{Editprotected}}
Per all normal citation style guidelines and the MOS, and {{Cite book}} and other templates in this series, please fix this template to put "double quotes" around the "title=" value. This should be done in the code so that it puts the quotation marks about only the value, not the entire URL-plus-title, or the quotations marks will accidentally end up including the "external link icon". I.e. the rendered result should be <a href="URL HERE">"TITLE HERE"</a>
, not "<a href="URL HERE">TITLE HERE</a>"
(underlining emphasis added for clarity; obviously, the underlining would not be in the actual code). — SMcCandlish [talk] [cont] ‹(-¿-)› 02:24, 24 December 2007 (UTC)
- Hrm, a quick Google search turns up at least as many style guidelines that suggest italics as it does guidelines that suggest quotes. I'm also not sure what {{Cite book}} has to do with it, and I don't see webpage titles mentioned at all on MOS:TITLE. Anomie⚔ 13:54, 24 December 2007 (UTC)
- According to "Citing Web resources", Chicago and MLA would use quotes, APA would use no quotes or italics. What guideline specifies italics? I would agree that the titles should be quoted here. -- JHunterJ (talk) 14:00, 24 December 2007 (UTC)
- I suppose it depends on whether the
title
parameter to this template is being used for the "document title" or the "web site title"; all three there use italics for the "web site title". Sometimes it makes sense to have a separate "document title" and "web site title" (in which casework
is used for the "web site title"), while other times there is only one title involved (in which casetitle
must be used). Anomie⚔ 17:01, 24 December 2007 (UTC)
- I suppose it depends on whether the
- According to "Citing Web resources", Chicago and MLA would use quotes, APA would use no quotes or italics. What guideline specifies italics? I would agree that the titles should be quoted here. -- JHunterJ (talk) 14:00, 24 December 2007 (UTC)
This is controversial, so I've disabled the request. You might also want to consider current usages which already use quotes, which obviously would be messed up by such a change. --- RockMFR 17:56, 24 December 2007 (UTC)
In-text cites?
{{editprotected}} There are a number of warning signs that refer to the lack of in-text cites on an article. However, nothing on this page refers to in-text cites. Could that be clarified on the page please? If not, please tell me WTF they are.
- Slamlander (talk) 16:15, 10 January 2008 (UTC)
- Disabling the request, as this appears to be a request for a change to the documentation, which is not protected. If this is in error, please reinstate the request with a more specific description. If you show me an example of the warning to which you refer, I might be able to answer your question. Pagrashtak 17:48, 10 January 2008 (UTC)
Publisher field should NOT be italicized
the "publisher" field should not be ital. due to publishers being either companies and/or individuals. miranda 05:39, 7 February 2008 (UTC)
- Correct; the work field should be italicized. SandyGeorgia (Talk) 06:22, 7 February 2008 (UTC)
{{#if: {{{work|}}} | . ''{{{work}}}'' }}{{#if: {{{pages|}}} | {{{pages}}} }}{{#if: {{{publisher|}}} | . {{{publisher}}}{{#if: {{{author|}}}{{{last|}}} | | {{#if: {{{date|}}}{{{year|}}}{{{month|}}} || }} }}
This appears to be the relevant bit, if I'm understanding you correctly. If I'm reading it right, it appears to be set up as SandyGeorgia described. Is there a particular case where this isn't working right? – Luna Santin (talk) 08:47, 7 February 2008 (UTC)
- Sorry, I guess I was confused about the "work" field. I am wondering if we can change the "work" field to something like "newspaper" for the field? Lessens on the confusion. Thanks for your efforts. miranda 12:35, 7 February 2008 (UTC)
- Ah, I see. Adding an alternate parameter name might be confusing, but shouldn't be too difficult on the template end; changing the variable name outright would require that we check/update an awful lot of transclusions (possible with AWB, but difficult to tell how much work that'd be). Any opinions on that, anybody? – Luna Santin (talk) 03:10, 8 February 2008 (UTC)
Format for video clips
What is the correct value of the parameter "format=" for video clips, such as at Common Cold Unit? Thanks—G716 <T·C> 09:13, 17 February 2008 (UTC)
- For video files, I think the format would always be the file extension (e.g. MIDI or MP3). However, I hope someone with more authority than I have will confirm/deny this, as it could be a related concept, like the MIME type.--Jesdisciple (talk) 11:58, 15 March 2008 (UTC)
Language field producing extra brackets
The language brackets are producing extra brackets when used with {{Languageicon}}. Jappalang (talk) 23:40, 21 February 2008 (UTC)
- These extra brackets are appearing even with a straight: title|url|accessdate format. See:Philosophical_views_of_suicide#References, ref. #1. Is it me? Am I mis-applying the parameters? ~ Alcmaeonid (talk) 16:42, 26 February 2008 (UTC)
- I'm having a similar problem @ Handchime. I've done everything I can think of to the parameters, and nothing gets rid of the brakets or makes the link apply to the title instead of being written out (which is seriously ugly). Any help? Godofbiscuits 21:47, 29 February 2008 (UTC)
- I fixed the reference problem in both the Philosophical views of suicide[1] and Handchime[2] articles. Instead of the "space key", the "enter key" was pressed after the colon (:) used in the title of both references, which caused the problem. --Silver Edge (talk) 03:30, 1 March 2008 (UTC)
- Thanks for the help, Silver Edge! Godofbiscuits 16:42, 1 March 2008 (UTC)
- I fixed the reference problem in both the Philosophical views of suicide[1] and Handchime[2] articles. Instead of the "space key", the "enter key" was pressed after the colon (:) used in the title of both references, which caused the problem. --Silver Edge (talk) 03:30, 1 March 2008 (UTC)
- I'm having a similar problem @ Handchime. I've done everything I can think of to the parameters, and nothing gets rid of the brakets or makes the link apply to the title instead of being written out (which is seriously ugly). Any help? Godofbiscuits 21:47, 29 February 2008 (UTC)
- I don't think the language parameter of this template was made to be used with {{Languageicon}}. For example: "Wikipedia". "Wikipedia" (in (in English)).
{{cite web}}
: CS1 maint: unrecognized language (link) --Silver Edge (talk) 03:41, 1 March 2008 (UTC)- Could this template be made to work with the {{Languageicon}}? Is there any reason it should not? papageno (talk) 03:05, 22 April 2008 (UTC)
- The {{Cite news}} template appears to be taking the language parameter and converting to the language icon. See the "Radio Okapi" references at 2008_Hewa_Bora_Airways_crash. papageno (talk) 17:10, 24 April 2008 (UTC)
- I propose that the language parameter be used to invoke a language icon, just as done with {{Cite news}}. papageno (talk) 18:26, 30 April 2008 (UTC)
- The {{Cite news}} template appears to be taking the language parameter and converting to the language icon. See the "Radio Okapi" references at 2008_Hewa_Bora_Airways_crash. papageno (talk) 17:10, 24 April 2008 (UTC)
- Could this template be made to work with the {{Languageicon}}? Is there any reason it should not? papageno (talk) 03:05, 22 April 2008 (UTC)
Rm "other"
{{editprotected}} Under the "All parameters" heading, pls remove the word "other" from the following sub-heading:
All other parameters, horizontal format (delete the ones you don't need)
The word "other" makes that sub-heading incorrect, as it implies that the listed parameters don't include the ones listed previously. It should read:
All parameters, horizontal format (delete the ones you don't need)
Another change that would be worthwhile, but not necessary, is to remove the parenthetical text "(delete the ones you don't need)" and put it above that sub-heading, to show that it applies to both the horizontal and vertical formats. E.g., it could be moved intact to the end of the "All parameters" heading, or it could be converted to an explanatory, unbolded sentence immediately below the "All parameters" heading.
Thank you, --Rich Janis (talk) 02:07, 15 March 2008 (UTC)
- The template documentation is at Template:Cite web/doc which is unprotected and you are welcome to edit yourself. mattbr 10:03, 15 March 2008 (UTC)
Syntax
I need to find out what I'm doing wrong... I'm using this syntax:
{{cite web |title=Example.com – Home |url=http://www.example.com/ |accessdate=2008-03-14}}
And I get this: {{cite web |title=Example.com – Home |url=http://www.example.com/ |accessdate=2008-03-14}} Why? Thanks! --Jesdisciple (talk) 12:14, 15 March 2008 (UTC)
- You need a | after the template name, ie
{{cite web | title=Example.com – Home | url=http://www.example.com/ | accessdate=2008-03-14}}
. mattbr 12:20, 15 March 2008 (UTC)- Thanks! I wish I had a 'WikiLint'... --Jesdisciple (talk) 13:12, 15 March 2008 (UTC)
Suggestion: case sensitivity and parameter tags
The url parameter should not be case-sensitive; at the very least,
{{cite web | URL=http://example.net | title=your example document}}
should not display the annoying error, "You must specify title = and url = when using {{cite web}}." 69.140.152.55 (talk) 04:16, 20 March 2008 (UTC)
- Agreed; case sensitivity in parameter tags is a problem. However, I think this is a MediaWiki 'feature', isn't it? --User:Ceyockey (talk to me) 13:39, 22 March 2008 (UTC)
- Correct. Parameters are case-sensitive, therefore the error message was not displayed in error. It may have been annoying, but it caused you to fix your template call, so you should be happy you got it. Shinobu (talk) 23:02, 25 March 2008 (UTC)
adding funding= parameter
{{editprotected}}
Adding a "funding=" parameter so that we can add the funding source for the study. This was brought up because of multiple sources being suspected of having funding from the same company on Water memory. The "publisher=" parameter is not adequate for this since people think that I am talkng about the editor and change it, see [[3]].
We have been arguing for the need of specifying the funding on studies suspected of POV and which studies need the funding specified and which don't, but it's all moot unless we have the technical means to specify funding on the first place (aka "funding="). The whole discussion is spread over Talk:Homeopathy/Article_probation/Incidents#pushing_articles_on_talk_pages and Talk:Arsenicum_album#More_info_on_the_human_trial.
Another solution would be creating "Template:Cite_study" with a funding parameter, on the line of "Template:Cite_news", but, as it stands now, +95% of the params would be identical to citeweb, and citeweb is already used everywhere for studies with no problem except this recent problem --Enric Naval (talk) 13:21, 3 April 2008 (UTC)
- Funding isn't the sort of thing that is normally included in citation information. I think the best solution to this problem would be to not use templates in cases where you wish to specify this additional information. --- RockMFR 15:14, 5 April 2008 (UTC)
- Since this information is only going to be required in a very few instances, I would recommend you create
{{cite study}}
rather than adding to the 19th most-transcluded-template on Wikipedia. That way, you can customise the fields to display exactly what you need. Be careful to keep the formatting consistent with the other citation templates. Happy‑melon 15:57, 5 April 2008 (UTC)
- Since this information is only going to be required in a very few instances, I would recommend you create
- OK, I'll create that one --Enric Naval (talk) 20:12, 5 April 2008 (UTC)
Common form for cases where little is known about authorship of the page
Would it be fair to say that editors shouldn't actually be adding links to pages where "little is known about the authorship"? Given that this is first off the top, might we be encouraging bad links? It doesn't have the publisher field, for instance, and you can't ascertain reliability without finding a publisher. Can it go? Marskell (talk) 16:57, 27 April 2008 (UTC)
Ref parameter
Any chance of getting a "ref" parameter as per the Cite Book template? (see Wikipedia:Citing_sources/Further_considerations#Filling_in_ref_field_of_cite-xxx_templates for more). Greenshed (talk) 20:57, 31 August 2008 (UTC)
date not wiki linked
Out of curiosity why is the accessdate automatically wikilinked but not the date? -- Argash | talk | contribs 04:52, 2 October 2007 (UTC)
- That's a good question that I've wonder as well. The only thing I can think of is if the full date is not available, like it's just the year, or month-year, something like that. I have found that adding the [[ ]]s works, but it would be nice if it did it automatically. (Guyinblack25 talk 14:24, 2 October 2007 (UTC))
{{editprotected}}
- Could someone make the date= field auto wiki linked? -- Argash | talk | contribs 14:28, 3 October 2007 (UTC)
- No – please don't. This will break all the existing uses of this template. This proposal needs wider discussion as it affects all cite * templates and they should all be updated, if deemed necessary, with a bot fixing the broken links. → AA (talk) — 14:48, 3 October 2007 (UTC)
- I'm disabling the editprotected. Changes to the cite templates are made only when there is clear agreement. — Carl (CBM · talk) 15:49, 3 October 2007 (UTC)
- No – please don't. This will break all the existing uses of this template. This proposal needs wider discussion as it affects all cite * templates and they should all be updated, if deemed necessary, with a bot fixing the broken links. → AA (talk) — 14:48, 3 October 2007 (UTC)
- Could someone make the date= field auto wiki linked? -- Argash | talk | contribs 14:28, 3 October 2007 (UTC)
- Fundamentally the date fields should allow variety, including the unlinked "October 2007". It would help, however,if all the links occurred in the parameter rather than the template, as it creates special cases that should/shouldn't be linked normally. Rich Farmbrough, 09:37 7 November 2007 (GMT).
- I'm curious about why the template description says that the field must not be wikilinked. I thought wikilinking was the norm, based on MOS:SYL#Autoformatting_and_linking?—RJH (talk) 16:39, 24 June 2008 (UTC)
- Because it is automatically formatted and wikilinked by the template :P -- AnmaFinotera (talk · contribs) 16:59, 24 June 2008 (UTC)
ISSN
Shouldn't there be a parameter for ISSNs? Lurker (said · done) 13:10, 5 November 2007 (UTC)
ISSNs are only for books, but even Template:Cite book doesn't have it, so you might want to ask someone to include it on Template:Cite book here.DA PIE EATER (talk) 00:57, 25 June 2008 (UTC)- Sorry, my mistake. Template:Cite book already has it. Since ISSNsare for electronic books, somewhere along the line, consensus(probably) included ISSN in cite book, not cite web. DA PIE EATER (talk) 01:03, 25 June 2008 (UTC)
I was just wondering why {{cite web}} should only be used for non-news sources. Doesn't {{cite news}} have very similar fields? Thanks, Drum guy (talk) 21:24, 17 February 2008 (UTC)
- Yes, I agree with you. I have used {{cite web}} for news sources. There is no need for {{cite news}}. I think the two templates should be merged. Masterpiece2000 (talk) 03:47, 4 March 2008 (UTC)
- Reminder: url and title are mandatory fields in {{cite web}}. Not all news citations will have a url. {{cite web}} could be merged into {{cite news}}, but not the other way around, unless the url field in web citations was no longer mandatory. And that would be odd. -- JHunterJ (talk) 12:09, 4 March 2008 (UTC)
- Thanks for replying :)
- Reminder: url and title are mandatory fields in {{cite web}}. Not all news citations will have a url. {{cite web}} could be merged into {{cite news}}, but not the other way around, unless the url field in web citations was no longer mandatory. And that would be odd. -- JHunterJ (talk) 12:09, 4 March 2008 (UTC)
- I think that before considering whether to merge (although it's good to consider it!), it would be brilliant to think about what's written on the template documentation. At the moment, it clearly, unarguably says that the template mustn't be used for citing news sources, and to use {{cite news}} for that. If we have consensus to change that, then I think that should be our first step :) ¡Muchas gracias, Drum guy (talk) 23:09, 4 March 2008 (UTC)!
- Regardless of whether the use of _cite web_ is expanded to include news articles or not, the point made about "not all news citations will have a url" (I agree with this) puts a full-stop on the notion of deprecating _cite news_ ... a merger of the two would be counter productive. --User:Ceyockey (talk to me) 01:16, 5 March 2008 (UTC)
- I concur that "cite news" must not be deprecated. It's exactly the wrong direction to go. Professionally published news, on average, is a far better, more reliable source than mere web pages. The news template also contains more specific information (like pages) that are missing from the web template. The net result is that "cite news" conveys more serious weight to its cited sources, which is abetted by the fact that "cite web" is often used to paste in any old page found on the web, with no regard to the reliability of the publishers behind it. This is not a fatal error for "cite web" — we can, after all, aspire to be do better — but merging "news" into "web" is like merging a professional weekly paper into a tabloid. (Not that that probably hasn't been done, but we must avoid a similar travesty if we want to be taken seriously as an encyclopedia.) ~ Jeff Q (talk) 03:12, 5 March 2008 (UTC)
- I certainly agree about the comparative reliability of some news organs, but that derives from their name and reputation, not from the template used to cite them. Similarly, some web sites also are well known and reputable, e.g., Salon.com, The Register, heck, even in its own way The Onion. And on top of that, those who only read the artible don't know which template is being used, if any. RossPatterson (talk) 00:05, 6 March 2008 (UTC)
- The Register is among those websites that it would be reasonable to use _cite news_ for rather than _cite web_. The distinction in using _cite news_ is one of journalistic standards, not the medium used to communicate the work. --User:Ceyockey (talk to me) 02:05, 6 March 2008 (UTC)
- So what can we say?
- Are we saying that we can never use {{cite web}} for news sources, but if it's possible to use exactly the same fields but just change the word 'web' to 'news', can we add that in the template documentation? Are there more things (e.g. other necessary fields) that we need to know? Thanks, Drum guy (talk) 17:01, 21 March 2008 (UTC)
- Not quite. For instance, the URL field is mandatory for _Cite web_ and one point above is that not all news items have associated URLs. There are other differences, but this is the first that comes to mind. --User:Ceyockey (talk to me) 13:37, 22 March 2008 (UTC)
- OK, but can we add to the documentation that to cite a news source, all you have to do is change the word 'news' to 'web', and that, although there are differences, the same fields can be used? Drum guy (talk) 21:11, 27 April 2008 (UTC)
- Not quite. For instance, the URL field is mandatory for _Cite web_ and one point above is that not all news items have associated URLs. There are other differences, but this is the first that comes to mind. --User:Ceyockey (talk to me) 13:37, 22 March 2008 (UTC)
- Are we saying that we can never use {{cite web}} for news sources, but if it's possible to use exactly the same fields but just change the word 'web' to 'news', can we add that in the template documentation? Are there more things (e.g. other necessary fields) that we need to know? Thanks, Drum guy (talk) 17:01, 21 March 2008 (UTC)
- If we were to depreciate {{cite news}}, I'm just asking if we could still use Toronto Star, Chicago Tribune, New York Post,etc. as a source?Note:I'm not POVing or COIing when I say those newspapers, those were the first newspapers to popinto my head, thats all.DA PIE EATER (talk) 01:13, 25 June 2008 (UTC)
- Yes. In _cite news_, these would fit into the "work" field, which is also found in _cite web_. --User:Ceyockey (talk to me) 01:15, 1 July 2008 (UTC)
- If we were to depreciate {{cite news}}, I'm just asking if we could still use Toronto Star, Chicago Tribune, New York Post,etc. as a source?Note:I'm not POVing or COIing when I say those newspapers, those were the first newspapers to popinto my head, thats all.DA PIE EATER (talk) 01:13, 25 June 2008 (UTC)
(unindent) What made me write this was that I read the documentation and was slightly taken aback, as I've been using {{cite web}} for news sources for ages. I propose changing the first paragraph of the documentation from:
This template is used to cite non-news sources in Wikipedia articles. (See cite sources for general information about citations in Wikipedia articles and see {{cite news}} to learn about citing a news source). This template replaces deprecated template:web reference. It provides lower case parameters only.
to:
This template is used to cite online sources in Wikipedia articles. {{Cite news}} can also be used when citing a news source; for general information about citations in Wikipedia articles, see Wikipedia:cite sources. This template replaces deprecated template:web reference, and provides lower case parameters only.
- Oops - had forgotten to sign that! I've made the change to the description as there was no discussion, but if you want to discuss it further first, please revert until there is consensus to apply the change. Thanks, Drum guy (talk) 20:28, 28 July 2008 (UTC)
- I would suggest that addition of "or {{Citation}}" so that the second sentence in the blockquote begins "{{Cite news}} or {{Citation}} can also be used". --User:Ceyockey (talk to me) 03:18, 31 July 2008 (UTC)
Date wikilinking bug
Because
{{#time:Y-m-d|1935-09-15}}
evaluates to
1970-01-01
the template refuses to automatically wikilink all dates before 1970. This is problematic for material which originated before this date (e.g. historical documents) and were later put on the web. Shinobu (talk) 22:58, 25 March 2008 (UTC)
- Fixed: "p". 1965-04-30..--Patrick (talk) 00:12, 26 March 2008 (UTC)
- Just an FYI to everyone, this is a technical limitation and is further explained at Unix time. Gary King (talk) 21:50, 13 April 2008 (UTC)
- I suspected it might have something to do with the Unix era. :-) Link to the diff for reference. Thanks for fixing! Shinobu (talk) 22:46, 13 May 2008 (UTC)
- Just an FYI to everyone, this is a technical limitation and is further explained at Unix time. Gary King (talk) 21:50, 13 April 2008 (UTC)
- I wouldn't call it a technical limitation; I'd call it an abuse of a function. Functions that can only deal with Unix time are obviously only intended to work with events that occur on a computer that was put in service sometime after the Unix operating system was created. Using such a function to deal with an event that did not occur inside such a computer is wrong. --Gerry Ashton (talk) 03:08, 3 August 2008 (UTC)
Unfortunately, this links all dates before 1970, regardless of format. Using the example above:
- "p". 30 April 1965.
Redlinks are worse than the problem this attempts to fix. Gimmetrow 02:52, 3 August 2008 (UTC)
Date linking
In [4], why does the accessyear field not require a link (if it is linked, the "[[]]" appear in the text), while accessdaymonth does require linking? Thanks, –Outriggr § 01:08, 6 May 2008 (UTC)
- Accessdaymonth is used for non-wikilinked dates.
accessdate=2005-07-06
will yield a formatted, wikilinked date: 6 July 2005.accessmonthday=July 6|accessyear=2005
will yield a non-formatted date, with only the year linked: July 6, 2005.accessmonthday=[[July 6]]|accessyear=2005
will yield a formatted, wikilinked date: 6 July 2005, the same as when using accessdate.- By the way, I really don't understand why we would support having non-wikilinked dates here in the first place. It's just a crude way of overriding the user's settings, which strikes me as a very impolite thing to do, the message it conveys is approximately "my settings are better than yours, so I will force them upon you." I think we should either abandon accessmonthday or link it just like in the accessdate version. Shinobu (talk) 23:06, 13 May 2008 (UTC)
- If I follow you, I agree. This is very unintuitive and unexpected behaviour. Template parameter names should be as self-explanatory as possible; accessdaymonth vs accessmonthday, seriously?? It seems every time I find myself working with a date in a citation template, I have to make an informed guess about whether to link the field; and I'm usually wrong. I don't understand how wiki's most widely used citation templates end up this way. –Outriggr § 23:51, 13 May 2008 (UTC)
- Oops, I misinterpreted; I thought one of those parameters linked and one didn't. (Although my point about explanatory naming is still kinda valid; who wouldn't expect access(day|month) to link, unless you deduced the reason that they are separate parameters, but since the reason they are separate seems poor, you wouldn't deduce it...) So I still agree with you – deprecate them. –Outriggr § 23:57, 13 May 2008 (UTC)
WebCite and archiveurl
I've just tried to use WebCite to document references. For example this editin the Julian Lincoln Simon article. Is there a reason not to use WebCite on every web source you document? Maybe WebCite should have it's own parameter and always be included (automaticly if possible)? Nsaa (talk) 21:03, 20 May 2008 (UTC)
I've added the following help page ({{Reference help}}
) for the Referensce section in articles:
{{reference help}}
Is this a good way of helping people adding the correct template and parameters? Nsaa (talk) 13:15, 13 July 2008 (UTC)
Edit requested dates: optional links and style
{{editprotected}}
The formatting of dates using accessdaymonth and accessmonthday violates the manual of style: They should look like this (when used with accessyear, which there is no situation that they should not be):
respectively
But actually look like this:
This is wrong, and the incorrect comma in the first is hard-coded.
I have fixed the problem on temp-page {{cite web2}} – you may delete redirect that here that when you're done with it. Shoemaker's Holiday (talk) 16:53, 22 May 2008 (UTC)
- According to the documentation (and how the template was until a few months ago), nothing should be wikilinked if accessdaymonth/accessmonthday is used. Just having the year linked is obviously wrong, as it is now, so I'm changing it back to how it was a few months ago. --- RockMFR 18:31, 23 May 2008 (UTC)
- According to WP:MOSDATE the whole thing should be linked, as two halves. Shoemaker's Holiday (talk) 16:59, 24 May 2008 (UTC)
- I won't argue either way about the linking (because personally I believe the accessmonth(day) and accessyear parameters shouldn't exist), but I will suggest that if and when a change is made, {{cite web2}} be deleted and the only two articles that use it be changed to use this template, rather than creating a redirect. RossPatterson (talk) 15:22, 3 July 2008 (UTC)
Option: lk=on versus lk=off
I suggest that we have an option for 'lk=on' and 'lk=off'. I think this would be an improvement over having to choose between accessdate and accessmonth. Lightmouse (talk) 18:36, 4 July 2008 (UTC)
- I have created a test version at Template:Cite web/sandbox.
- Lightmouse suggested "To make it simplest for users, it would be good if it can accept 'accessdate' as a parameter. For example, would it accept 'accessdate=2006-09-19' ?"
- It is done at Template:Cite web/sandbox.
Gary King (talk) 18:38, 4 July 2008 (UTC)
Could you explain the full problem and solution you are proposing? What is that you want to change to accessdate and why? Renata (talk) 19:47, 4 July 2008 (UTC)
- Ah yes, we should start from the top. Basically, there has been a push to allow editors to choose whether to link or not link dates in articles (linking dates has never been mandatory), especially when going through WP:FAC and WP:FLC where the standards are higher than usual. Now that some articles are choosing not to link dates, the only dates that are still linked are the dates and access dates in citation templates, primarily {{cite web}} since that's the one that is usually used the most. I first suggested to use accessmonthday and accessyear to have unlinked accessdates, but stemming from User_talk:Tony1#Removing_excessive_links, if we just add a lk=off option, then everything else could stay the same. Gary King (talk) 20:03, 4 July 2008 (UTC)
- I strongly support the migration from enforced to optional autoformatting; indeed, it is required to match the fact that for some time now, date autoformatting has been optional in the main text of our articles. (This is a slight correction to Gary's point that autoformatting has never been mandatory; it was until last year.) Tony (talk) 02:35, 5 July 2008 (UTC)
What about I.P. users?
Excuse me, but aren’t the above-mentioned efforts on autoformatting of dates yet another case where slick, user-sensitive formatting will only work for A) registered editors, B) who’ve taken the time to set their user prefs? If so, unregistered I.P. users—the vast majority of readers—would see what? Someone, please explain as I don’t know. If unregistered users see dates that only appear in one form or are inferior to well-thought-out, fixed-text dates (where due consideration is given to the subject and readership), then I don’t see the point of the effort here. I’m actually quite surprised that the current autoformatting of dates (and the accompanying ‘over’-linking) was created only for the benefit of registered editors. Is there a way to tap into Wikipedia’s awareness of the reader’s I.P. address (country of origin)? Many Web sites routinely rely on automated capture of users’ I.P. address (and even such minutia as their O.S.).
Frankly, if we actually were to gain access to an I.P.-sensitive function that could be accessed in magic words and templates, I’d just as soon see it first used for something more compelling than date formats. For instance, {{dialect|color|colour}}
would be read as “color” in the U.S., and as “colour” in England/Australia/etc. It wouldn’t have to be “smart” at all. Simply by looking to the readers’ I.P. address, {{dialect|trunk|boot}}
would be read as “the border patrol agents discovered the bomb upon opening the trunk” for Americans, and as “the border patrol agents discovered the bomb upon opening the boot” for others. Now that, would be something I’d really like. Greg L (talk) 20:07, 4 July 2008 (UTC)
- First of all, this discussion is better suited for MOS:DATE. Secondly, the discussion above is trying to solve precisely this. Currently, when dates are linked in date and accessdate fields, they appear as 2008-01-01 for unregistered users. The suggestion given above would format them as January 1, 2008 for all users. Gary King (talk) 20:10, 4 July 2008 (UTC)
- Funny, I was alerted to this issue by Tony on my talk page, directing me to User_talk:Tony1#Removing_excessive_links, where I saw that you had moved it to User_talk:Lightmouse#User_talk:Tony1.23Removing_excessive_links, where Lightmouse had moved it to here. This issue is clearly an adopted bastard child.
I’m done. Goodbye. Greg L (talk) 20:15, 4 July 2008 (UTC)
- Funny, I was alerted to this issue by Tony on my talk page, directing me to User_talk:Tony1#Removing_excessive_links, where I saw that you had moved it to User_talk:Lightmouse#User_talk:Tony1.23Removing_excessive_links, where Lightmouse had moved it to here. This issue is clearly an adopted bastard child.
- This section's discussion and the one above (and the ones you linked) tackle different issues. The one I started on Tony's page was to primarily let him know that there was a way to show unlinked dates using cite web, then Lightmouse suggested that a simpler method be created. Gary King (talk) 20:20, 4 July 2008 (UTC)
- OK. Autoformatting of dates using {cite web}: So… Why bother if the vast majority of readers (non-registered, regular folk) just see “January 1, 2008”? Is it so we registered editors are privileged Eloi and most every other reader are subterranean Morlocks? I submit that any forum where autoformatting of dates is being discussed is a valid one for someone to point out that end product only really benefits an elite club: us. We’re just all patting ourselves on the back here if we’re making tools that only we can enjoy; we might as well just hard-code “January 1, 2008”. Did any of my above post not make that point clear? If we’re going to be autoformatting dates, make it work for regular readers or forget it. Greg L (talk) 20:38, 4 July 2008 (UTC)
- Huh? This effort is so that most users see "January 1, 2008" and NOT "2008-01-01", which is what they see right now. Gary King (talk) 20:59, 4 July 2008 (UTC)
- I’m saying that if the vast majority of users (non-registered, plain-folk readers) see “January 1, 2008”, then we might as well simply type
January 1, 2008
and shouldn’t be pretending we’re doing any good with {cite web} and [[1 January]] [[2008]]. We shouldn’t bother with any tool that only benefits us registered editors. Why?Because when registered American editors see “January 1, 2008” and European registered editors see “1 January 2008”, we editors—especially the European ones who are content with the dates they see—are going to loose track that most everyone else in Europe sees American-style dates. I’m American but can imagine that in an article like French Revolution, an English-speaking European reader (there are many) would find “June 10, 1789” just as awkward as would an American seeing “4 July”. Further, new editors who aren’t highly familiar with the idiosyncrasies of these tools will simply copy them from other articles without being aware of their limitations.
Again: If we’re going to be autoformatting dates, make it work for regular readers or forget it. Greg L (talk) 21:33, 4 July 2008 (UTC)
- I’m saying that if the vast majority of users (non-registered, plain-folk readers) see “January 1, 2008”, then we might as well simply type
Greg, the idea is to migrate the template from enforced linking of dates to an optional linking where an editor makes a deliberate choice. You will see other discusssions on this topic more than once on this page. I think systematic mandatory linking dates is wrong and it conflicts with guidance elsewhere. I think it is a fairly easy transition to turn mandatory linking into optional linking. However, if you make a pitch here that the template code should be updated to end date links, then you will not find an objection from me. Lightmouse (talk) 23:30, 4 July 2008 (UTC)
- Greg, I think I'd have gone for a simpler, less ambitious tweaking of cite web at this stage, to match what is a gradually evolving realisation by WP's editors that date autoformatting in their main text is not mandatory and has a number of serious disadvantages. In view of the unlikelihood of technical action by WikiMedia to fix the issues in their patch, it would be better to allow editors to manually check through the date formatting of their reference lists as they do now for punctuation, capitalisation and the order of the elements. It's urgent, in fact, that we force the issue on checking raw formatting, since it's concealed from us, the very people who are charged with making it consistent. The fact that almost all of our readers (i.e., those who are unregistered) see "2008-01-01" in cite web is shocking revelation and additional reason to add the switch-of-autoformatting function.
- Right now, we need consensus that this function be inserted. Anyone care to provide feedback? Tony (talk) 02:32, 5 July 2008 (UTC)
- Why is it shocking to see "2008-01-01"? What's wrong with that? Renata (talk) 06:18, 5 July 2008 (UTC)
- I don’t find it shocking. But I do find it quite unattractive and ambiguous. It’s not a common format in the U.S. (I don’t know about Europe) and many readers have to stare at it to figure out that it’s likely year-month-day. Only 60 percent of the time (after the 12th day of the month, e.g. 2008-01-13) does it become absolutely unambiguous and easier to parse. It’s much more attractive and functional to have dates where the month is spelled out (either fully or abbreviated). Greg L (talk) 20:07, 6 July 2008 (UTC)
- The biggest problem with this format is that unlike both 1 Jan 2008 and Jan 1, 2008, it is not unambiguous for someone who is unfamiliar with it. Christopher Parham (talk) 17:43, 12 July 2008 (UTC)
- I’m not up-to-speed enough on the technical issues and intricacies being discussed to be able to make a meaningful contribution on such details; that should be left to you experts. But I’m pleased to hear that there is an evolving sensitivity to the experience of unregistered (most) readers and your efforts are being directed in that direction. As for updating template code to end date links, where do I sign up? Greg L (talk) 06:03, 5 July 2008 (UTC)
adminisrator asked to implement Gary's sandbox change
Dear colleagues—I've posted a note with Davidruben, who made the most recent change to the code of cite web, asking for his agreement to implement the change. Tony (talk) 11:06, 6 July 2008 (UTC)
- Ok, I'm going to be really dense here, the suggested coding change[5] is:
{{#if: {{{archivedate|}}} | Archived from [{{{url}}} the original] on [[{{{archivedate}}}]]. }}{{#if: {{{doi|}}} | [[Digital object identifier|DOI]]:[http://dx.doi.org/{{{doi|{{{doilabel|}}}}}} {{{doi}}}]. }}{{#if: {{{accessdate|}}} | Retrieved on [[{{{accessdate}}}]]{{#if: {{{accessyear|}}} | , [[{{{accessyear}}}]] }}. }}{{#if: {{{accessmonthday|}}} | Retrieved on {{{accessmonthday}}}{{#if: {{{accessyear|}}} | , {{{accessyear}}} }}. }}{{#if: {{{accessdaymonth|}}} | Retrieved on {{{accessdaymonth}}}{{#if: {{{accessyear|}}} | {{{accessyear}}} }}. }}
- to this:
{{#if: {{{archivedate|}}} | Archived from [{{{url}}} the original] on [[{{{archivedate}}}]]. }}{{#if: {{{doi|}}} | [[Digital object identifier|DOI]]:[http://dx.doi.org/{{{doi|{{{doilabel|}}}}}} {{{doi}}}]. }}{{#if: {{{accessdate|}}} | Retrieved on {{#ifeq: {{{lk}}} | off | {{#time: F j, Y | {{{accessdate}}}}} | [[{{{accessdate}}}]] }}{{#if: {{{accessyear|}}} | , [[{{{accessyear}}}]] }}. }}{{#if: {{{accessmonthday|}}} | Retrieved on {{{accessmonthday}}}{{#if: {{{accessyear|}}} | , {{{accessyear}}} }}. }}{{#if: {{{accessdaymonth|}}} | Retrieved on {{{accessdaymonth}}}{{#if: {{{accessyear|}}} | {{{accessyear}}} }}. }}
I get the concept of the [[{{{accessdate}}}]] generates a style of date based upon user preference (where a registered used has so chosen), but where the editor sets lk to "off" you are going to force american dates on everyone else.
I would understand if editors sought to force the relevant style for the specific location of the subject matter of the article, hence US subjects might use American dates and articles on UK used European style of dates (so perhaps options of lk being set to "off-Am" for American style or "off" for rest of the world), but the above proposed use of lk forces US-centric editing and seems, on initial reading of this proposal, as daft. As I said, maybe I'm just being dense, so do please enlighten me :-) David Ruben Talk 23:01, 6 July 2008 (UTC)
- Yes, that is a good point, and something that I have been thinking about. One alternative could be to include a setting for "format=us" and "format=uk" for different date formats. I would prefer a preset date format like =us and =uk rather than requiring a date format specified every time this template is used (like format=m d, y), for shorthand purposes and also so there isn't one template used in an article that is accidentally using a different format from the other templates used in the same article. Gary King (talk) 23:05, 6 July 2008 (UTC)
- As Calendar date#Date format indicates "d m y" neither just UK nor European, "m d, y" mostly but not exculsively used by US, and Asian coutries generally "y m d" (repectively "Little-endian", "middle-endian" and "big-endian" - see Endianness); but clearly "le", "me" & "be" as abreviations would confuse everyone. As usage seems (at least for English language contries) to follow American or British usage (akin "AmE" and "BrE"), perhaps selected options should be formats being "=Am" and "=Br", with "=As" for asian ? Alternatively use "little", "middle" and "big" (almost confuse everyone). Simplist might be to specify precisely what one means with "dmy", "mdy" or "ymd" being the options ?David Ruben Talk 00:13, 7 July 2008 (UTC)
- That sounds good to me. Gary King (talk) 00:15, 7 July 2008 (UTC)
- Ok re how to implement then, but as for proposal itself, how does this maintain or improve compatability with the other citation templates of {{citation}}, {{cite journal}} etc ? (Currently move to at least coordinate feature development , there being no consensus to merge the cite xxx to just citation) David Ruben Talk 00:38, 7 July 2008 (UTC)
- Those templates don't automatically wikilink dates. Only cite web requires that accessdate be YYYY-MM-DD, otherwise it will wikilink anyways. Gary King (talk) 00:41, 7 July 2008 (UTC)
- I'm a bit dumb about these programming things: I do hope that there will be a simple "lk on / lk off" facility. Apart from all else, allowing editors to remove the autoformatting function will force them check the consistency of the raw formatting, which, I presume, is what almost all (non-logged-in) readers see. If this can be achieved as simply as possible (from users' perspective), that would be just great. Tony (talk) 08:58, 8 July 2008 (UTC)
- "On" & "off" is problematic - what format will be used if "Off". As above discussions considered, the "January 4, 2004" American style is a minority-style worldwide :-) The relevant style should mirror general language issues (AmE vs BrE) in that correct for subject matter of article (hence "American Road Signs" is clearly going to use "color" vs "colour", but the opposite for say "British Paintings"), but where an article not country specific then in the style of the first major edit/creation of the article (ie whoever edits first). As there seems no standardised terms for date styles that anyone has heard of (i.e. "little-endian" does not count as widely known), then options are as set out above of:
- as Am/Br/As - but without looking it up, who knows what standard Asian date layout is ?
- as dmy/mdy/ymd - which at least is explicit in the resulting outcome
- I going to suggest we go for the latter option. Remember this is for editors to see, not the general reader, and then only for editors who wish to start forcing a specific date style (so only for a little step of a learning curve needed). I'll code this up when I have a quiet moment in next day or two :-) David Ruben Talk 12:38, 8 July 2008 (UTC)
- "On" & "off" is problematic - what format will be used if "Off". As above discussions considered, the "January 4, 2004" American style is a minority-style worldwide :-) The relevant style should mirror general language issues (AmE vs BrE) in that correct for subject matter of article (hence "American Road Signs" is clearly going to use "color" vs "colour", but the opposite for say "British Paintings"), but where an article not country specific then in the style of the first major edit/creation of the article (ie whoever edits first). As there seems no standardised terms for date styles that anyone has heard of (i.e. "little-endian" does not count as widely known), then options are as set out above of:
Why are we talking about forcing any date style on citations in articles? Although there's a long-standing consensus to present some general formatting (like spelling) in the style of the subject's predominant style of English, I was under the impression that we've pretty much established that all full dates and month-day fragments should be set to use a wiki-linked style that allows readers to choose how they're represented. Is this just about date fragments like "July 7-8" that MediaWiki can't format flexibly? Or is this just another pass at trying to to force a particular style when readers can otherwise choose what they're comfortable with? (As an American who uses military date formatting — dd mmm (yy)yy — for correspondence, I take exception to considering these things "American" or "British", and firmly believe we shouldn't push any formatting on people not mandated by software limitations. Spelling is a basic text problem that needs this kind of localization/localisation. The date problem is already solved.) ~ Jeff Q (talk) 14:04, 8 July 2008 (UTC)
- David (and Jeff, e.c.), I apologise for having neglected to provide you with the essential background information. MOSNUM no longer encourages date autoformatting and now prescribes rules for the raw formatting). These changes were intruduced last year. The rules for which formattings are acceptable in which articles came first, and apply to formattings with and without autoformatting (since almost all readers see main-text autoformatted text in the original, raw format that is concealed from us as logged-in WPians. This was seen as years overdue, and was sparked by complaints at WP:FAC that when reviewers checked what outsiders see (via edit windows), they commonly found inconsistencies within articles, and such anomalies as Euro formatting in US-related articles and vice versa.
- Critically for this issue here, only two formats are recognised as standard in MOSNUM: the US and the British/Australian (aka Euro): m d, y and d m y. I think we're keen that these not be blue-linked in cite web, so that editors would simply type in the date manually. If you know how to arrange for the date to be autoformatted without the blue and the underlining, through the choice of "US" or "UK", that would be acceptable, I think. But I think manual keying in, as people do in the main text, is probably the best option.
- The move to optional autoformatting has arisen from widespread discontent with WikiMedia's rather dysfunctional, inflexible system, not least of which are that it's exclusive to logged-on WPians, often clutters high-value links, and is often incorrectly used by editors, resulting in broken formats.
- It has become clearer over the past few weeks, as people have thought through the larger situation, that the use of cite web makes all dates at the bottom of an article a sea of formatted or unformatted blue (depending on whether you're a WPian or an outside reader), and is inconsistent with the main text of an article where editors have decided not to use date autoformatting.
- This is why Greg, Gary and I have come here (from MOSNUM) to ask that cite web be modified to allow such editors the freedom of choice in their citations lists. No one is forcing any change on anyone: we just wish this template to match the consensus for choice WRT main text in articles. Tony (talk) 14:09, 8 July 2008 (UTC)
- Sorry, Tony and everyone. It's my responsibility to keep on top of that stuff, not yours to keep me informed. My (very) bad. I have to agree that the blue-sea look is less than pleasant. Carry on. ~ Jeff Q (talk) 15:07, 8 July 2008 (UTC)
PS Just in case an illustration is required, this is an FA candidate after and before dates were de-autoformatted. Here, month/day are mostly involved. In the "after" version, I scroll down to see the opposite standard format used in the citations from the US form in the main article. Tony (talk) 14:21, 8 July 2008 (UTC)
- Coded here: Template:Cite web/sandbox. Please comment. I used "lk" for the date format field but perhaps something else is more appropriate? I was going to use "fmt" but then figured it would be difficult to remember for most people, and then thought about using "format" but then remembered that that was already used for the format of the reference (i.e. PDF, HTML). Gary King (talk) 17:00, 8 July 2008 (UTC)
- Looks quite good, but a couple of queries on the above sandbox:
- I'm not aware that the YMD format is accepted on Wikipedia: WP:DATE lists International, American and ISO (for occasional use), so I would suggest that the third option use ISO format (I imagine that this wouldn't be used much, but as WP:DATE allows it...)
- If a cite web is set to use lk=mdy (American), will my user date preference for International format still override this (it wouldn't matter whether the date ended up wikilinked or not)? If not, we are breaking existing functionality, which would be a real issue for me.
- (probably obvious to everybody else) Query: I assume then that we would accept to use ISO format for raw dates in cite web, and to have the option of the lk= field to change the markup. If this is the case, we would need to agree to slightly change WP:DATE to say that this meets the requirement for 'consistent raw date formatting' in articles. I assume this has been implicitly agreed by the users above? Thanks Rjwilmsi 17:59, 8 July 2008 (UTC)
As with spelling of colour/color, as long as the date format is unambiguous I do not care. Most Wikipedia readers see dates without any autoformatting. In this case, that means ISO8601 format is already the default. I thought that was a rather neat solution for the particular circumstances of cite web (compact, somewhat technical data, no need to adapt to article region or reference region). I suggest that we do not change the default and where 'lk=' sequence is not specified or is set to 'off', the existing raw text is not subject to any reformatting. Lightmouse (talk) 18:17, 8 July 2008 (UTC)
- (edit conflict) The three formats I coded in are the three that are also options as user preferences; I think WP:DATE allows all three? We aren't breaking existing functionality if user preferences do not override the date formats in an article. Current MOS dictates that as long as date formats are consistent within an article, then it is acceptable. I'm not quite sure on what you mean in your third point, but as I said, MOS says that as long as date formats are consistent in an article, then that is acceptable. They don't have to be linked, also; linking dates was only to auto-format them, but now that MOS has changed, linking dates is not a requirement anymore.
- The default has not been changed. I added another example to the sandbox page, please check it. Gary King (talk) 18:22, 8 July 2008 (UTC)
- I agree the default (i.e. lk= not present or invalid) should not be changed. Scrap point 1 then. Now, point 2 is important for me: at the moment an ISO date in a cite web field is displayed as International per my user date preference. If for a particular reference, a user added lk=mdy (American), I understand the date would not be linked. That's fine, but would it display to me as American or International? If it's going to force American on me, that's an issue for me (I am aware this wouldn't break MOS consistency rules in itself). Point 3 was a minor one, but WP:DATE says "underlying formats need to be checked for consistency in the edit box", so I think we would need to agree to relax that to say it's okay if the markup (for non-logged in users) can override it. Thanks Rjwilmsi 18:33, 8 July 2008 (UTC)
- The default has not been changed. I added another example to the sandbox page, please check it. Gary King (talk) 18:22, 8 July 2008 (UTC)
- Regarding the second point, yes, American format would be forced on you. This has been discussed before, especially at MOS where most of the discussions have taken place. Regarding the third point, I think I get what you're saying; however, I don't know if it needs some rewording, considering dates are already entered in YYYY-MM-DD format for all citation templates. Gary King (talk) 18:46, 8 July 2008 (UTC)
- Hmm, thanks for clarifying. I'm not sure I would like having the date format forced upon me, as currently I can choose. However, MOS discussion was mostly against me and there are clearly advantages to introducing this lk= field, from which the majority of page viewers (not logged in ones) will benefit, so it seems I may have to lose some freedom for the benefit of the masses...medals in the post please ;)
- If this goes ahead I have a script I could easily modify to add lk= fields and convert all non-ISO dates in the template date fields to ISO format, which I could use to edit a list/category of pages upon request (e.g. I could imagine users would want the American presidents category converted to lk=mdy). Thanks Rjwilmsi 18:59, 8 July 2008 (UTC)
- Regarding the second point, yes, American format would be forced on you. This has been discussed before, especially at MOS where most of the discussions have taken place. Regarding the third point, I think I get what you're saying; however, I don't know if it needs some rewording, considering dates are already entered in YYYY-MM-DD format for all citation templates. Gary King (talk) 18:46, 8 July 2008 (UTC)
- Except that the lk= field should only be added to articles that already have all dates unlinked; from my experience, most articles have dates linked, understandably, because that has been the norm for years and when new editors see dates linked in one article, they do it to others. I think if and when this change goes through, effort should be concentrated to push for this change in FACs, something I'm sure people including Tony will do. I have about 75 Good Article reviews and plan to continue reviewing them, so I could also suggest that people remove links from dates and instead use lk=. Gary King (talk) 19:12, 8 July 2008 (UTC)
- But I thought users would want to add the appropriate lk= fields in lots of articles so that date=/accessdate= ISO dates would then display as unlinked American or International for non-logged in users, as opposed to linked ISO dates at the moment. In the case of accessdate= in cite web, it can't be used without providing a linked date as markup, so how do FACs get round that? Surely they all need this change to be able to? Probably we are getting a bit ahead of ourselves though. Rjwilmsi 19:33, 8 July 2008 (UTC)
- Except that the lk= field should only be added to articles that already have all dates unlinked; from my experience, most articles have dates linked, understandably, because that has been the norm for years and when new editors see dates linked in one article, they do it to others. I think if and when this change goes through, effort should be concentrated to push for this change in FACs, something I'm sure people including Tony will do. I have about 75 Good Article reviews and plan to continue reviewing them, so I could also suggest that people remove links from dates and instead use lk=. Gary King (talk) 19:12, 8 July 2008 (UTC)
- Hold on, hold on. First of all, I am assuming that you are referring to the ugliness of "2008-01-01" (pretend this is blue-linked) to most visitors; people unanimously agree that this is ugly. But, they need to still be linked if other dates in a specific article are linked. If you unlink all dates in an article, then lk= can be used for {{cite web}}. I'm not sure what you mean about accessdate requiring a linked date; accessdate is used like "accessdate=2008-01-01"; it will stay the same. lk= changes that accordingly, per the sandbox example. "A bit ahead of ourselves" would be changing a lot of articles at once ;) Again, it's best if we focus on FACs (and I can help with GANs), first. Gary King (talk) 19:38, 8 July 2008 (UTC)
- Okay, I agree the way accessdate will be typed in won't change. My example was this: a FAC uses a cite web template, and has an accessdate. The accessdate field requires an unlinked ISO date (e.g. {{cite web | url=http://www.a.com | accessdate=2008-01-01 | title=Hello }}. When displayed, the accessdate appears as a wikilinked date (e.g. "Hello". Retrieved 2008-01-01.
{{cite web}}
: Check|url=
value (help)). For users who aren't logged in, it displays as a wikilinked ISO date, and most agree the ISO date format is not very user-friendly. So, 'lk=' isn't available yet, what do FACs do to be user-friendly? It must be inevitable that if they use cite web and accessdate, the result is a wililinked ISO date for the general public. Therefore I assumed there would be a large takeup of the lk field, if introduced. - And please don't worry, I'm not going to add it to 50,000 articles the day after it's introduced ;) Rjwilmsi 19:58, 8 July 2008 (UTC)
- Okay, I agree the way accessdate will be typed in won't change. My example was this: a FAC uses a cite web template, and has an accessdate. The accessdate field requires an unlinked ISO date (e.g. {{cite web | url=http://www.a.com | accessdate=2008-01-01 | title=Hello }}. When displayed, the accessdate appears as a wikilinked date (e.g. "Hello". Retrieved 2008-01-01.
- Hold on, hold on. First of all, I am assuming that you are referring to the ugliness of "2008-01-01" (pretend this is blue-linked) to most visitors; people unanimously agree that this is ugly. But, they need to still be linked if other dates in a specific article are linked. If you unlink all dates in an article, then lk= can be used for {{cite web}}. I'm not sure what you mean about accessdate requiring a linked date; accessdate is used like "accessdate=2008-01-01"; it will stay the same. lk= changes that accordingly, per the sandbox example. "A bit ahead of ourselves" would be changing a lot of articles at once ;) Again, it's best if we focus on FACs (and I can help with GANs), first. Gary King (talk) 19:38, 8 July 2008 (UTC)
← Most of the FACs do indeed have wikilinked ISO dates at the moment, including my own. lk= will certainly be in highest demand in FAC moreso than anywhere else on Wikipedia. Gary King (talk) 20:01, 8 July 2008 (UTC)
- Okay, that's what I thought. Then the change looks good to me – I will accept a loss of user date preference for these dates as it will benefit the majority of page viewers in allowing a page's dates to be displayed consistently within the page. Not perfect, but what is? Rjwilmsi 20:14, 8 July 2008 (UTC)
- However, when the date is forced appropriately, like American dates for American President biographies, I think that's acceptable eh? :p I think later on, the more common argument will be which date format to use in each article on an article-by-article basis (on their respective talk pages), once user preferences no longer work in a large number of articles. Gary King (talk) 20:20, 8 July 2008 (UTC)
- Yes, on balance. I had thought to myself that the best solution was for the mediawiki software to allow a new per-page parameter, and to format that page's dates in either the American or International format according to the parameter's value, which would be overriden by any user date preference. That will remain a pipe dream; the above change is about as close to it as we can get I suppose. And yes, we will be opening up a new can of worms! I would suggest that WP:ENGVAR/WP:DATE will need to be updated in anticipation of the change to provide rules for the correct date format (American vs International) choice for articles. Rjwilmsi 20:27, 8 July 2008 (UTC)
- However, when the date is forced appropriately, like American dates for American President biographies, I think that's acceptable eh? :p I think later on, the more common argument will be which date format to use in each article on an article-by-article basis (on their respective talk pages), once user preferences no longer work in a large number of articles. Gary King (talk) 20:20, 8 July 2008 (UTC)
- Probably will not happen in the near future, for a number of reasons. You're basically talking about a variable setting. MediaWiki wiki markup does not support variables that only exist on a single page, as far as I know. If it did, then someone could easily hide a variable on a page and other editors would be wondering why the dates they input change when it is saved. Also, there needs to be a way for pages to know that some text is actually a date, besides using regular expressions, such as formatting dates like #2008-01-01# or something. Gary King (talk) 20:46, 8 July 2008 (UTC)
- Yes, I had realised these things, and totally agree with your point. I'm now in favour of the proposed solution for cite web (consistency for the general public beats my user date preference), so am happy to end discussion of wider issues. Over to others for any other comments. Rjwilmsi 20:56, 8 July 2008 (UTC)
- What about {{DEFAULTSORT}}, something like {{DEFAULTDATE}} wouldn't be so different. As for trying to force your new "lk" parameter on any class of articles, IMO that's just more WP:CREEP and another thing for people to fight over. I don't look forward to having to revert if/when people try to implement these changes across Wikipedia without discussion on each affected article. Anomie⚔ 21:43, 8 July 2008 (UTC)
- Probably will not happen in the near future, for a number of reasons. You're basically talking about a variable setting. MediaWiki wiki markup does not support variables that only exist on a single page, as far as I know. If it did, then someone could easily hide a variable on a page and other editors would be wondering why the dates they input change when it is saved. Also, there needs to be a way for pages to know that some text is actually a date, besides using regular expressions, such as formatting dates like #2008-01-01# or something. Gary King (talk) 20:46, 8 July 2008 (UTC)
- It has and always will be up to FAC nominators to decide what they want to do with their article. Gary King (talk) 22:01, 8 July 2008 (UTC)
New cite web in the sandbox with dmy, mdy, and ymd support
I think the link got hidden beneath the discussion above. Again, here it is my original message:
Coded here: Template:Cite web/sandbox. Please comment. I used "lk" for the date format field but perhaps something else is more appropriate? I was going to use "fmt" but then figured it would be difficult to remember for most people, and then thought about using "format" but then remembered that that was already used for the format of the reference (i.e. PDF, HTML).
Gary King (talk) 21:02, 8 July 2008 (UTC)
- Thanks for trialling the coding.
- Ifeq is ugly for multiple options and leads to hard-to-maintain multiple levels of nesting conditions here. I'll have a try at recoding it.
- As for ymd, according to relevant wikipedia article that is universal style in most Asian countries. Whilst I'ld love all dates in British style, probably wrong to force American or British styles on say articles about Japan ? I've no strong views on this, but should be considered.
- We're discussing its effect on the date & accessdate; but cite web also has a archivedate parameter to consider too. The example only allowed user preference to take priority for date, whilst for accessdate, the coding forced lk style even if user has set a preference.
- "lk" is horrible as a parameter name and does not convay its purpose unless an editor was to look up this template's documentatoin . We're discussing its effect on the date & accessdate; but cite web also has a archivedate parameter to consider too. Can I suggest we call it "datestyle" ("dateformat" risks being confused with file format of the "format" parameter). David Ruben Talk 22:55, 8 July 2008 (UTC)
- The example only allowed user preference to take priority for date: does that mean it's possible to make this change, but still let an individual user date preference overrule it (for date, accessdate and archivedate)? I would like this if it's possible. BTW, the sandbox seems to be slightly broken as the 'retrieved on' bit for the accessdate is missing, so I can't properly evaluate the examples. Thanks Rjwilmsi 23:13, 8 July 2008 (UTC)
- I'm in process of trying to allow this for all variables. Currently struggling a bit with excess closing "}}", so hold on looking at Template:Cite web/sandbox for a few minutes :-) David Ruben Talk 00:13, 9 July 2008 (UTC)
- Failure :-( I fixed most of coding, but fails to show wikilinked dates if datestyle not set, i.e. as 2008-01-01 -Arrrgh ! Unless anyone can fix the sandbox code, I'm asking a template guru Davidgothberg to help out :-) David Ruben Talk 01:35, 9 July 2008 (UTC)
- I'm in process of trying to allow this for all variables. Currently struggling a bit with excess closing "}}", so hold on looking at Template:Cite web/sandbox for a few minutes :-) David Ruben Talk 00:13, 9 July 2008 (UTC)
Working version and final discussion
Ok, I think problem is that apparently one can not use #ifeq: to detect a user's preference (and hence not possible to test if wikified output is the default unset-preference of ISO YYYY-MM-DD or some set user preference) according to meta help - meta:Help:Date_formatting_and_linking#Accessibility of date preference for branching. This is because date formating is rendered after the parser fuction is processed. So unless someone clever spots a flaw in my testing, metatemplate ({{Date style}} works in its own document page but not as a called template within another, ifeq not able detect a format display of yyyy mm-dd) then we have limited coding options:
- A single parameter, say, datelink, which is either unspecified or blank, else takes single value of "off".
- This shows all dates with code {{{date|}}} eg 2007-10-23, rather than current wikified values using code [[{{{date|}}}]] eg 2007-10-23 which shows as YYYY-MM-DD for those who do not have a date preference set but otherwise user selected preference.
- Horrible downside to this is that if this is set to "off" then whilst any style of dates may be used within the relevant parameters (date, archivedate, accessdate) as no attempt is made to wikilink, there is no hope ever of showing dates in a user's prefered style (as later wikifying other date-styles does not work, eg 23 October 2007 is a redlink). Furthermore if there is ever any change in policy to show a single date style or return to wikified dates, an editor-entered freestyle of date can not be recovered back into ISO format
- Parameter datestyle which if blank gives current de facto wikilinked date (ie YYYY-MM-DD for all but those who have specified a date preference). Otherwise as a fixed (ie user preference is ignored) unlinked "dmy", "mdy" or "ymd" format.
- This is my preference as it still requires the relevant parameters (date, archivedate, accessdate) to be entered into the template in a single standard ISO YYYY-MM-DD format which can be machine read, or used to show user preference if this software feature later becomes available (or say if a later change in wikipedia policy say requires all dates to be again wikified)
- This is the version on display currently at template:cite web/sandbox (historically this).
- As previous option (3) but with the additional option of "off" to show dates as unformated freetext however the date, archivedate, accessdate parameters are entered.
- A bad option as per option (1) of a free-for-all which prevents ever recovering back fixed styles or user-set preferences
- the initial proposal at the start of this thread (above) of datestyle blank giving the current de facto wikified dates for all. Then if specified as dmy/mdy/ymd then still shown in user preference if this has been set, else as these fixed formats... seems impossible to code currently (we can't test for presence of a user preference or not)
I therefore present option 2 as allowing editors to show dates within cite_web in a fixed style which can be later adjusted according to any later policy changes. I'll implement this provided consensus remains happy that for the minority who have a set a date-preference, this may be ignored where an editor defines a datestyle parameter in this template...
Finally as it would be nice to have the cite templates remain consistant, should such a similar option be given to the date/accessdate parameters of other cite XXX templates ? David Ruben Talk 19:19, 14 July 2008 (UTC)
- Vote: Option two. Good work. Option two is the best in an imperfect world. As a user with a date preference, I am happy for this to be overridden if it allows an article to present all its dates to all users in the same format, as appropriate to the article's subject. Also, I've checked and invalid dates display with a nice big red error, so it will be clear to editors when an invalid date has been given. When implemented this should be available to all fields requiring a full date in all cite templates to allow consistency (since it defaults to off, i.e. no change, I don't see how this would create any problems). Rjwilmsi 19:43, 14 July 2008 (UTC)
- Is there any way to do this on a per-article basis rather than having to put the parameter in every reference? --Gerry Ashton (talk) 20:05, 14 July 2008 (UTC)
- Not with the tools we have available to us now. That would require a variable like DEFAULTSORT that is built-in to MediaWiki. Gary King (talk) 20:31, 14 July 2008 (UTC)
- Is there any way to do this on a per-article basis rather than having to put the parameter in every reference? --Gerry Ashton (talk) 20:05, 14 July 2008 (UTC)
- Heads up: while Gary King had done work on a pre-1970 unix problem with regards to #time formating that I admit totally went over my head initially :-( (partly due to other MediaWiki problems I was encountering), I have now worked to insert his error trap back into the coding. There was though a separate pre-1901 problem that needed addressing too. Neither pre-1970 nor pre-1901 problems affect wikifying dates. The combined 3-way issues really makes coding tricky to follow, and so I've returned to using a metatemplate.
However wikified dates cannot it seems be passed between templates, so this cite_web/sandbox still needed to directly wikify dates if datestyle is not defined(the metatemplate takes care of the formating and error trapping). Hence see changes to this sandbox and work on metatemplate (ignore code for when metatemplate is directly used without a date and defaults to today - cite_web of course tests for existance of date parameters itself).- Stupid extraneous space in my coding caused this - as Anomie's work helped show me. David Ruben Talk 00:33, 17 July 2008 (UTC)
- This feature may now be included in other cite XXX templates using a not unworkable compressed coding of:
{{#ifeq:{{{datestyle|}}}| |[[{{{date}}}]]|{{Date style|{{{datestyle}}}|{{{date}}}}}}}
- ("date" does not need "|" pipe as existance will have been prior checked, likewise "datastyle" within the metatemplate call is at that point known to exist)David Ruben Talk 03:07, 16 July 2008 (UTC)
- That's starting to resemble this (subtemplate) that I started throwing together yesterday, before realizing it wouldn't really help the issue here (re honoring user date preferences). IMO, errors should be displayed so editors can know to fix them,
and if you add a default do-nothing case to the template you can simplify the usage toOops! Forgot about the need to wikilink in the "default" case. OTOH, I still think it would be best if the devs would just install the FormatDates extension (or something similar), and maybe include a{{Date style|{{{datestyle}}}|{{{date}}}}}
.{{DEFAULTDATEFORMAT}}
directive to specify the format to use for non-logged-in users. Anomie⚔ 12:24, 16 July 2008 (UTC)- Your coding correctly tests, I think, for the pre-1901 problem, it but also needs test for pre-1970 (dates might only show as 1970-01-01). I agree if we did not wish to keep the status quo of wikilinked dates where datestyle not specified (and show instead plain unlinked yyyy-mm-dd in all cases) that indeed would be the ideal simpler coding. However this would also mean that for those registered users who have selected a date preference, this would always be ignored for the ISO style (if we wish to be bold on that fine, but would need a strong consensus). NB as currently envisaged, the date formating would apply not just to 'accessdate', but also 'date' and 'archivedate'. David Ruben Talk 13:58, 16 July 2008 (UTC)
- It does test for pre-1970 dates. The problem with #time is that if the input is between 1901-12-13 20:45:52 (UTC) and 1969-12-31 23:59:58 (UTC) inclusive, it always returns the epoch date (1970-01-01T00:00:00+00:00) instead of the correct date. My code checks if "12:00:01 am on {{{date}}}" and "12:00:02 am on {{{date}}}" result in the same output. This allows 1970-01-01 as a valid date, and shouldn't break if they change the b0rken output to 1900-01-01 or something (instead of just fixing the bug). The "default option" idea could still work if the default case always wikilinked the output. Anomie⚔ 17:52, 16 July 2008 (UTC)
- Your coding correctly tests, I think, for the pre-1901 problem, it but also needs test for pre-1970 (dates might only show as 1970-01-01). I agree if we did not wish to keep the status quo of wikilinked dates where datestyle not specified (and show instead plain unlinked yyyy-mm-dd in all cases) that indeed would be the ideal simpler coding. However this would also mean that for those registered users who have selected a date preference, this would always be ignored for the ISO style (if we wish to be bold on that fine, but would need a strong consensus). NB as currently envisaged, the date formating would apply not just to 'accessdate', but also 'date' and 'archivedate'. David Ruben Talk 13:58, 16 July 2008 (UTC)
- That's starting to resemble this (subtemplate) that I started throwing together yesterday, before realizing it wouldn't really help the issue here (re honoring user date preferences). IMO, errors should be displayed so editors can know to fix them,
- Clever - a more sophisticated 1970 test; I'll try and incorporate your coding then. Having a default wikilinked-date out from the metatemplate into this template, does not work (seems wikilinked dates get messed up by MediaWiki going across this process and end up showing as redlinked 2008-07-16), hence the need for this template to do the simple default wikilinking, and let the metatemplate do the hard work of 1970/1901 errors and editor selected formating.David Ruben Talk 18:59, 16 July 2008 (UTC)
- Anomie I note you used 2 levels of metatemplates for your coding which was neat, do we need to be worried about the server load for this ? Is placement in a single metatemplate better. As you can see from edit to Date style, your suggestion for a best test works, but not a nice single metatemplate to look at :-) Should I split this into a meta-metatemplate, there again I'm only duplicating the check-coding thrice for the 3 options, so not that terrible ? David Ruben Talk 19:23, 16 July 2008 (UTC)
- Last I checked, {{ft to m}} uses something like 10 levels of meta-templates. Anyway, have the sysadmins said to worry about meta templates? As for date auto-formatting not working in layers of meta-templates, I had User:Anomie/Sandbox4 transcluding User:Anomie/Sandbox3 transcluding User:Anomie/Sandbox transcluding User:Anomie/Sandbox2 and it worked fine. Anomie⚔ 22:50, 16 July 2008 (UTC)
- "Doh" just aint expressive enough at my stupidity - Thanks Anomie for your example, I finally (checking your coding and my failled attempts) realised that my past coding attempts had not worked due to the spacing I had so very carefully inserted for clearer coding layout - so I'll say it again doh ! Again many thanks Anomie for your work on this - sandbox coding so much simpler as a result. David Ruben Talk 00:33, 17 July 2008 (UTC)
- No disrespect to the thoughtful comments of the few of us who have been discussing these proposals, but notices on other citation templates of this proposed change, and that it might then be a good idea to be consistant in the other cite_XXX templates with this formating option, has not brought a flurry of other opinions. I've posted heads-up at Wikipedia talk:Citation templates and Wikipedia talk:Citing sources. But unless any great change in consensus, then shall we go live in 5 days ? David Ruben Talk 18:59, 16 July 2008 (UTC)
- Go live this weekend sounds very reasonable. However, having read all of the above and understood the correct functionality of the change with unlinked ISO dates, I'm still not sure how the new formatting will handle errors (non-ISO dates with datestyle, and pre-1970/1900 dates, wikilinked dates): can you add examples of how the change will handle the following comma separated examples: date=[[20 May]] [[2007]] | datestyle = mdy, date=20 May 2007 | datestyle = mdy, date=[[May 20]] [[2007]] | datestyle = dmy, date=3rd February 2008 | datestyle = mdy, date=[[20 May]] [[1884]] | datestyle = mdy, date=[[20 May]] [[1968]] | datestyle = mdy, date=[[2007-04-13]] | datestyle = mdy perhaps under a 'handling of misformatting' section. Thanks Rjwilmsi 20:26, 16 July 2008 (UTC)
- Ok, section added to display at {{cite web/sandbox}} giving these examples and a couple extra for the pre-1901 example. All show a meaningful date, but wikilinked dates can not be unlinked for reformating and so they show as entered. In essence because we cannot format dates pre-1901 and the only test for these are that they cause an error if we try to format, the template must handle errors by simply showing the date-parameter as a literal value; whether that be part-linked examples as you suggest, "date=last day of 2003" or complete nonsense values of say "date=this is a date". So provided date set to be some sort of date we can understand, some comprehensible output will be shown. As there is no string manipulation available to us, nor ability to strip out wkilinking (i.e. to see the "2008-10-14" literal of 2008-10-14) we either accept this or remove the abilty for an editor ever to set a date format. Of course hopefully in future templates might read a user's preference and only set a style where none has been prefered - for this flexibility we should encourage editors to enter dates in a standard manner (ISO most obvious but as you will see from the example it is not the only style that works).David Ruben Talk 22:43, 16 July 2008 (UTC)
- Go live this weekend sounds very reasonable. However, having read all of the above and understood the correct functionality of the change with unlinked ISO dates, I'm still not sure how the new formatting will handle errors (non-ISO dates with datestyle, and pre-1970/1900 dates, wikilinked dates): can you add examples of how the change will handle the following comma separated examples: date=[[20 May]] [[2007]] | datestyle = mdy, date=20 May 2007 | datestyle = mdy, date=[[May 20]] [[2007]] | datestyle = dmy, date=3rd February 2008 | datestyle = mdy, date=[[20 May]] [[1884]] | datestyle = mdy, date=[[20 May]] [[1968]] | datestyle = mdy, date=[[2007-04-13]] | datestyle = mdy perhaps under a 'handling of misformatting' section. Thanks Rjwilmsi 20:26, 16 July 2008 (UTC)
- Clever - a more sophisticated 1970 test; I'll try and incorporate your coding then. Having a default wikilinked-date out from the metatemplate into this template, does not work (seems wikilinked dates get messed up by MediaWiki going across this process and end up showing as redlinked 2008-07-16), hence the need for this template to do the simple default wikilinking, and let the metatemplate do the hard work of 1970/1901 errors and editor selected formating.David Ruben Talk 18:59, 16 July 2008 (UTC)
For those of us who are not interested in how to write templates, what is the design of the end result? I think the key things to keep in mind are that the datestyle parameter is specified by the author of the article, and is governed by the consensus of the article authors; all the citations in an article should be the same. The date format preference set by logged in readers will be set by each reader. So it would make sense that the result, if a full date, after the datestyle parameter is dealt with, but before any user profile preference is processed, will always be wikilinked, or will never be wikilinked, no matter what the datestyle is set to. According to WP:MOSNUM, "Date elements that do not contain both a day number and a month should not generally be linked." That case will occur frequently with monthly magazines.
So, how close will the revised version come to what I describe? --Gerry Ashton (talk) 21:29, 16 July 2008 (UTC)
- Part dates, because they cannot be formated should show as the part date, so enter "20 April" or "2008" or "Xmas 2008" matters not - they all show in these examples as entered. The first example "20 April" will be wikilinked if datestyle not specified (ie as per current practice), but where a format specified then as unlinked item:
- "Example". 20 April.
{{cite web}}
: Check date values in:|date=
(help); Unknown parameter|datestyle=
ignored (help) - David Ruben Talk 22:43, 16 July 2008 (UTC)
- Thanks for the examples David. All, would it be accurate to summarise the usage advice as follows (for articles wishing to implement the datestyle field):
- to use the datestyle parameter in citation templates in an article, enter unlinked ISO dates for all date fields with dates between 1970 and 2038 and one datestyle per reference so that all users see unlinked dates in the format specified by the datestyle value.
- for dates outside this range, or only day and month combinations, set the datestyle value as before and use an unlinked date in the same format as the chosen datestyle (i.e. American, International or Asian) and this will display as entered for all users.
- ensure all dates (except quoted text) in the article's main text match the format in the references and use the same datestyle value for the whole article and in all references so that all dates in the article display consistently for all users.
- and the warning against other formats:
- Thanks for the examples David. All, would it be accurate to summarise the usage advice as follows (for articles wishing to implement the datestyle field):
- when using the datestyle parameter, do not use wikilinked dates or dates in an invalid date format, as the datestyle value will be ignored, the date format will not be automatically changed and the citation date will display as per standard Wikimedia markup, which will most probably not provide a result consistent with the other dates in the article. Remember, you will still need to set the datestyle value for references with dates just of day and month combinations.
- I think we can go live with this. If my summary above is good it can be the basis of the cite templates documentation on datestyle. Thanks Rjwilmsi 23:30, 16 July 2008 (UTC)
- If I understand Rjwilmsi's use instructions, then the following overall advise would apply (except that dates in quotations are never wikilinked):
- Since all dates throughout an article should be consistent, if there is a desire to both use the Cite web template and allow readers to choose what they see based on their user profile setting, all dates in the article would have to be wikilinked dates in ISO format. Since this format is not suitable for most articles, it will be necessary to give up on wikilinking dates, and choose another format for the dates. All dates outside of Cite web templates should be entered as they will appear to the reader. Dates within Cite web templates should be in ISO format, and should specify the appropriate value of the datestyle parameter.
- Editors who insist on dates which appear in a widely used format, such as American or UK-international, to readers who have no user profile setting, and appear in the preferred setting for readers who do have a user profile setting, should wikilink all dates that have both a month and a day, and avoid the use of any citation templates. --Gerry Ashton (talk) 23:50, 16 July 2008 (UTC)
- Your summary seems correct. Another way to put it might be: choose two of consistent dates, date wikilinking and citation templates! Rjwilmsi 00:07, 17 July 2008 (UTC)
- Personally, I think applying "all dates throughout an article should be consistent" to references (and all data tables) is overdoing it. Dates in the body of the article should be consistent, as should infobox dates, image caption dates, and most dates in tables. There is a place for ISO dates in tables for a more compact display. I for one like to see ISO dates in the references for the same reason: more compact, so I can see more references at once. YMMV. Anomie⚔ 00:29, 17 July 2008 (UTC)
- Editors who insist on dates which appear in a widely used format, such as American or UK-international, to readers who have no user profile setting, and appear in the preferred setting for readers who do have a user profile setting, should wikilink all dates that have both a month and a day, and avoid the use of any citation templates. --Gerry Ashton (talk) 23:50, 16 July 2008 (UTC)
- Can I just clarify on what I had posted earlier when I said part dates eg "April 2008" will wikify as a default as is the current system - that is true for the currently wikified 'accessdate' but not for current 'date' parameter. To prevent wikifying a part date, in the default case where 'datestyle' is unset, rather than use "|date=April 2008", use instead but "|month=April |year=2008" as these fields are unchanged in their non-linked appearance, hence:
- {{cite web/sandbox |title=Example |url=http://example.org |date=April 2008 |datestyle=}} = "Example". April 2008.
{{cite web}}
: Cite has empty unknown parameter:|datestyle=
(help) - {{cite web/sandbox |title=Example |url=http://example.org |date=April 2008 |datestyle=mdy}} = "Example". April 2008.
{{cite web}}
: Unknown parameter|datestyle=
ignored (help) - {{cite web/sandbox |title=Example |url=http://example.org |month=April |year=2008 |datestyle=}} = "Example". 2008.
{{cite web}}
: Cite has empty unknown parameter:|datestyle=
(help); Unknown parameter|month=
ignored (help) - {{cite web/sandbox |title=Example |url=http://example.org |month=April |year=2008 |datestyle=mdy}} ="Example". 2008.
{{cite web}}
: Cite has empty unknown parameter:|datestyle=
(help); Unknown parameter|month=
ignored (help) - There are similar split parameters in place of 'accessdate' of 'accessmonthday', 'accessmonth' & 'accessyear'. David Ruben Talk 00:53, 17 July 2008 (UTC)
- {{cite web/sandbox |title=Example |url=http://example.org |date=April 2008 |datestyle=}} = "Example". April 2008.
- Can I just clarify on what I had posted earlier when I said part dates eg "April 2008" will wikify as a default as is the current system - that is true for the currently wikified 'accessdate' but not for current 'date' parameter. To prevent wikifying a part date, in the default case where 'datestyle' is unset, rather than use "|date=April 2008", use instead but "|month=April |year=2008" as these fields are unchanged in their non-linked appearance, hence:
- Can I add a caveat to Gerry's first paragraph usage instruction (as bold), second paragrah seems a little harsh (but true enough) David Ruben Talk 01:18, 17 July 2008 (UTC)
- Since all dates throughout an article should be consistent, if there is a desire to both use the Cite web template and allow readers to choose what they see based on their user profile setting, all dates in the article would have to be wikilinked dates in ISO format. Since for most readers who have not set their user profile this format is not suitable for most articles, it will be necessary to give up on wikilinking dates, and choose another format for the dates. All dates outside of Cite web templates should be entered as they will appear to the reader. Dates within Cite web templates should be in ISO format, and should specify the appropriate value of the datestyle parameter.
- Editors who insist on dates which appear in a widely used format, such as American or UK-international, to readers who have no user profile setting, and appear in the preferred setting for readers who do have a user profile setting, should wikilink all dates that have both a month and a day, and avoid the use of any citation templates.
- Can I add a caveat to Gerry's first paragraph usage instruction (as bold), second paragrah seems a little harsh (but true enough) David Ruben Talk 01:18, 17 July 2008 (UTC)
Anomie thinks that "all dates throughout an article should be consistent" is overdoing it. I think this is a defensible position, especially for tables. I think Anonie should try to pursuade the editors of WP:Manual of style (dates and numbers) to alter the guideline. However, there are many editors (including me) who don't care much for citation templates, and while they might change style guidelines because the altered version looks better or is clearer, making the citation templates easier to program won't carry much weight. --Gerry Ashton (talk) 02:08, 17 July 2008 (UTC)
- Hell no, I'm not going anywhere near that mess. As far as I'm concerned, WP:IAR applies to anything in that page that doesn't make sense, because getting involved in WT:Manual of Style (dates and numbers) would make me have to take a loooong wikibreak out of frustration with people who will argue until the heat death of the universe without getting anywhere, and that would prevent me from improving and/or maintaining Wikipedia.
- I'll just try to stick to the parts of Wikipedia not filled with insanity, thank you. Anomie⚔ 02:37, 17 July 2008 (UTC)
Server worry ?
Anomie, a couple days ago you observed that we do not need to worry about the server, but whilst that's generally true, a re-read of WP:PERF had me wondering. If the {{date style}} formating metatemplate gets call for each of the 3 date parameters of {{cite web}}, and an article such as AIDS has 150 references, then there could be as many as 450 calls to the metatemplate for one article... I started getting nervous about that and posted to Wikipedia talk:Template limits#Proposed use of a date metatemplate into citation templates and asked Tim Starling to comment. His response though, of just going and editing DateFormater.php (see [6]), just confuses me (nay terrifies me - not least 'cos I can't follow php) surely that's a system wide option and we do not seek one fixed format style to force all wikilinked ISO dates into (we seek option to select between American & International styles on an article-by-article basis). So apart from some encouragement that the current proposal ain't going to gain me a Whacking with a Wet Trout for seizing up the servers, nor that we have missed some MediaWiki trick or two (what's the "regexes[self::YDM]" that Tim seemed to be referring to, can wikilinked dates have a style parameter associated with it?), then code testing is ready (provided people happy with {{date style}} would not be better coded with its own meta-metatemplate)... I'll give this a further 24hrs before implementing... David Ruben Talk 15:02, 19 July 2008 (UTC)
- OK, as a test for Aids article (which has 150 or so citation template calls), the central core of the article in WP:Sandbox gives activity level as:
- Preprocessor node count: 32054/1000000
- Post-expand include size: 273919/2048000 bytes
- Template argument size: 121577/2048000 bytes
- Expensive parser function count: 1/500
- If we do a temp show preview with all citation templates swopped to cite_web/sandbox
- Preprocessor node count: 22303/1000000
- Preprocessor node count: 22303/1000000
- Post-expand include size: 139743/2048000 bytes
- Template argument size: 93243/2048000 bytes
- Expensive parser function count: 1/500
- Now the test is unfair in as much as many of cite_XXX templates have more complicated coding than cite_web. But it at least proves the new cite_web with its repeated calling of a metatemplate does not seem to hugely affect the "Post-expand include size" result...
- Done per these changes to template and to documentation pages. David Ruben Talk 20:32, 20 July 2008 (UTC)
- Undone - see below - previous "date" shown unlinked if error trapped as non-date (seems applied to part dates too). But new coding assumed error trap as pre-1091 date (vs existing trap just for pre-1970 I think).
- PS server did hiccup both occasions (on implementation and its revert went through) - must have been me - sorry :-( David Ruben Talk 22:13, 20 July 2008 (UTC)
Follow up
One of the side effects of date linking in citation templates is that typos leading to date errors (invalid dates), which are common when one is entering citation data, show up in red. If dates are delinked, errors will no longer show in red. Is there a way the coding can check for valid dates? I'm concerned that we not lose a built-in mechanism we have now that detects errors when publication dates are typed in—an important part of maintaining WP:V. SandyGeorgia (Talk) 06:11, 14 July 2008 (UTC)
- Sure we can implement this. Will be done soon. I will most likely just make it red link if it is inputted incorrectly as I think that's the best way to make it obvious. Gary King (talk) 06:22, 14 July 2008 (UTC)
- Forgive my ignorance, but isn't this just bringing out of the woodwork glitches that should be cleared up anyway? Do those typos show up for non-logged-in readers? Tony (talk) 07:33, 14 July 2008 (UTC)
- If this helps, there are guidelines at MOSNUM for which format-style should be used in which article. They resemble our highly successful ENGVAR policy, with some important differences, of course. Tony (talk) 07:37, 14 July 2008 (UTC)
- TONY is right that incorrectly formatted dates is an issue whether the date is wikilinked or not e.g. neither '[[1st Nov.]]' or '1st Nov.' are valid dates on Wikipedia (except in quotes...). However, wikilinking will often produce redlinks (for everybody), which helps to highlight the error. Therefore it might be useful to keep this when the 'datestyle=' is implemented.
- If this helps, there are guidelines at MOSNUM for which format-style should be used in which article. They resemble our highly successful ENGVAR policy, with some important differences, of course. Tony (talk) 07:37, 14 July 2008 (UTC)
- I am currently working on dates in citation templates (and no, that doesn't just mean wikilinking them all!) and have already identified a large number of errors, and have started fixing them. If anybody knows of any common errors, contact me and I'll look into them. Rjwilmsi 11:10, 14 July 2008 (UTC)
- Tony, the point is for the typos to show for Wiki editors who correct them (the person who entered the citation will see the red, or they'll show up on review). SandyGeorgia (Talk) 17:18, 14 July 2008 (UTC)
- As an alternative, we already have a category which holds incorrectly formatted citations, namely Category:Articles with broken citations. Perhaps a check could be implemented to place incorrectly formatted dates into this category? To be honest, I only found this category a few days ago, but I am going to start patrolling it occasionally to fix the errors it checks. — Huntster (t • @ • c) 22:33, 14 July 2008 (UTC)
- The advantage of having autoformatted dates with errors show up in red is that the editor entering the incorrect citation (who has the sources) is more likely to see it and fix it right away. Other editors, checking a category an inderminate time later, might not have access to the source or be able to correct the error. SandyGeorgia (Talk) 22:36, 14 July 2008 (UTC)
- Indeed. I personally have this huge urge to fix red links whenever I see them; having a red link in my references would be a huge embarrassment! Gary King (talk) 01:11, 15 July 2008 (UTC)
Article title in quotation marks please
"Cite web" doesn't put the article title in quotation marks while "cite news" and "cite journal" do. Please add quotation marks to the template for consistency. Thanks. --Phenylalanine (talk) 12:52, 29 June 2008 (UTC)
Done per this edit David Ruben Talk 22:26, 7 July 2008 (UTC)
- Is there any chance that we can move the quotation marks in the title itself. The way it currently looks ("Wikipedia") looks hard to understand and makes it look like bad code. However, if it looks like it is in the title itself ("Wikipedia"), it looks like it is part of the title, much easier to understand. — NuclearVacuum 17:04, 11 July 2008 (UTC)
- Whilst I have no preference on this, all the other cite XXX templates currently include the link-box inside the quotes - see User:Smith609/Citation for comparisons. I'm open to them all being changed if there is cross-template consensus, else just makes for a clash of styles in articles.
- Such proposals that might affect all cite XXX need, IMHO, to be in a centralised area - would people be happy for say Template talk:citation to act as central location for such discussions, agreements and then implementations ?
- If the backlog of ideas on the talk:cite_XXX pages can have their straw polls and be cleared as support/rejected, then I'm tempted to suggest they all become redirects to Template talk:citation where ideas such as this, that if felt to be a good case in one template then a good case for all cite_XXX, need only come up the once ? David Ruben Talk 18:22, 11 July 2008 (UTC)
- Okay. I don't like quotes inside the URL, though, as technically it isn't part of the title. Gary King (talk) 18:32, 11 July 2008 (UTC)
The only reason I ask this is because of the arrow on the side of the link. What is with this arrow? Well either way, this arrow moves the quotation mark far enough from the title, that it looks improper and "dirty". When it is put into the title itself, it looks cleaner. Also, all titles never have quotation marks in it (it is always apostrophes). And also, if this is a good idea, it could be implemented in all the cite templates. Take a look at the full explanations below. — NuclearVacuum 15:40, 12 July 2008 (UTC)
- "Wikipedia" This is the way it looks now. As you can see, the "arrow" on the side of the url moves the quotation mark in just the manner that it looks dirty.
- "Wikipedia" When the quotation marks are put into the link, it looks cleaner, the quotation marks are not moved (on a count of the arrow), and what are the odds of finding an article title with quotation marks (which can easily be moved to the proper apostrophes).
- In response to your question about what the arrow is for, it's to indicate that these are external links. Gary King (talk) 17:09, 12 July 2008 (UTC)
- I had a feeling that's what that was for. On that note, it still is obstructing the quotation marks to the point that the marks look to be unrelated to the title (even hidden by the arrow). — NuclearVacuum 20:46, 12 July 2008 (UTC)
- Is there any chance that my request could be done? — NuclearVacuum 20:49, 14 July 2008 (UTC)
- Not until it gains consensus. It would have to be changed in all citation templates. Gary King (talk) 20:53, 14 July 2008 (UTC)
- Against change: With the quotation marks in the link and the same colour as the link, it looks as though the title is itself in quotes. To me this doesn't look right. Rjwilmsi 21:00, 14 July 2008 (UTC)
- Same for me. That's what I've been thinking. It's functional and practical but probably not aesthetically pleasing, but the former usually trumps the latter. Gary King (talk) 21:05, 14 July 2008 (UTC)
- Against change: With the quotation marks in the link and the same colour as the link, it looks as though the title is itself in quotes. To me this doesn't look right. Rjwilmsi 21:00, 14 July 2008 (UTC)
- Not until it gains consensus. It would have to be changed in all citation templates. Gary King (talk) 20:53, 14 July 2008 (UTC)
This discussion misses an important point. When giving the title of a freestanding work, like a book, the title is put in italics. This would apply to cite book. When giving the title of an article within a larger work, the article title is in quotes and the title of the larger work is in italics (e.g. "Banking Stocks Tumble Amid Market Unease" in the Washington Post); this would apply to cite news or cite journal. Since web pages may be either freestanding or part of a larger work, either convention might be appropriate for the title of a web page. --Gerry Ashton (talk) 22:39, 14 July 2008 (UTC)
Language - bolded?
Should the language, when specified, be bolded to match the style of Template:Language icon? --Drum guy (talk) 15:50, 3 July 2008 (UTC)
- No - other cite XXX nor {{citation}} template do this, so either do for all, or for none. Currently moves to standardise as much as possible across these templates, tehn need to merge talk-page discussions to one area for these templates. David Ruben Talk 22:30, 7 July 2008 (UTC)
Standardising with other templates
A suggestion comparing this to the other cite XXX templates:
- {{cite web}} has pages details after the "work" parameter and before the publisher, but that is out of keeping with cite journal, cite news, cite book and citation templates which all have journal/publisher before the pages. David Ruben Talk 03:31, 8 July 2008 (UTC)
- {{cite web}} & {{cite news}} place after the title "(format) (in language)", whilst {{cite journal}} & {{citation}} order these two as "(in language) (format)" - which is better ? David Ruben Talk 03:39, 8 July 2008 (UTC)
- I would prefer "(format) (in language)" Rjwilmsi 00:29, 13 July 2008 (UTC)
- Me too Gary King (talk) 00:32, 13 July 2008 (UTC)
- (until cite template talk pages merged into one) needs support/consensus over at cite journal & citation to make them change to this (ie both if they are to move to a common standard and move to what I agree reads as better English)David Ruben Talk 01:31, 13 July 2008 (UTC)
- Me too Gary King (talk) 00:32, 13 July 2008 (UTC)
- I think you should have posted this at each template talk page but with links to the discussion at Template_talk:Citation#Standardising_with_other_templates :) Gary King (talk) 01:36, 13 July 2008 (UTC)
- With hindsight, true :-) David Ruben Talk 02:46, 13 July 2008 (UTC)
- I think you should have posted this at each template talk page but with links to the discussion at Template_talk:Citation#Standardising_with_other_templates :) Gary King (talk) 01:36, 13 July 2008 (UTC)
date field
Hi. Sorry if this is a FAQ. I notice someone has changed the 'date' field not to accept prose (for example "undated, note...") or hyphenated dates or any of the innumerable other possibilities. The change now renders a red link for all exisiting refs on Wikipedia who have used anything but the new expected input. I'd suggest that change be reverted. -SusanLesch (talk) 20:31, 20 July 2008 (UTC)
- Thanks for spotting, the feature has been implemented with desire to change the archive date that was more strongly worded for needing to always be in ISO style and clearly could not have had any other uses. If one date field was to be formated then other date fileds (date & archivedate) need to reamin consistent. You have spotted a valid, and unthought of, use for date - being that there is no date :-)
- If any of the date fields now take prose, then datestyle will trap the error and show "as is".
- Without datestyle set
- {{cite web|title=Title |url=http://example.org |date=2007-10-25 |datestyle=}}
- Gives "Title". 2007-10-25.
{{cite web}}
: Cite has empty unknown parameter:|datestyle=
(help) - {{cite web|title=Title |url=http://example.org |date=Undated |datestyle=}}
- Gives "Title". Undated.
{{cite web}}
: Check date values in:|date=
(help); Cite has empty unknown parameter:|datestyle=
(help)
- With it set
- {{cite web|title=Title |url=http://example.org |date=2007-10-25 |datestyle=dmy}}
- Gives "Title". 2007-10-25.
{{cite web}}
: Unknown parameter|datestyle=
ignored (help) - {{cite web|title=Title |url=http://example.org |date=Undated |datestyle=dmy}}
- Gives "Title". Undated.
{{cite web}}
: Check date values in:|date=
(help); Unknown parameter|datestyle=
ignored (help)
- So we have to make a quick decision:
- Either trap non-date entries and just show as unlinked free text - impossible I'm afraid as any rendering error is used to trap MediaWiki's inability format dates before 1901 (yes I know no web sites back then, but proposal is to extend this across to {{cite journal}} and {{cite book}} where will apply)
- Set defined accepted text values that are not wikilinkd.
- As for hyphenated dates (not quite sure what you mean "5-August-2008"?), well they are not a valid date format and need converting to a correct format that wikipedia can read.
- So please add suggestions for freetext options that should be specifically recognised at Template talk:Date style#Excluded values David Ruben Talk 21:18, 20 July 2008 (UTC)
- I also saw no problem with the old usage - allowing for incomplete dates or prose as SusanLesch said. Also, any previously wikilinked dates now appear as [[2008-07-20]] in the references - it's not worth fixing all previously linked dates and wrecking prose just so some editors don't have to place brackets around a full date. I support a revert to the old version. Sillyfolkboy (talk) 21:20, 20 July 2008 (UTC)
- Ok "Undated" (or "undated") now an accepted values. Are there other examples of a simple acceptance of other values. If "date" really widely used outside of being just a date (please show examples), then maybe wikilinking on this needs to be removed? David Ruben Talk 21:34, 20 July 2008 (UTC)
- Wikilinked dates always did appear as ISO dates unless you had set your "my preferences" to an alternative ? David Ruben Talk 21:36, 20 July 2008 (UTC)
- Davidruben, would you mind making a revert? I found this because of a single featured article at this time on Wikipedia's main page. It looks, if you'll pardon the phrase, crappy to have 10 or so broken and red links while a discussion goes on. I completely support the idea of a new set of unified citation templates but, sorry, not on the fly. -SusanLesch (talk) 21:40, 20 July 2008 (UTC)
- Yes, wikilink should be removed. It break all kinds of other dates used by editors. For example, half-dates (as July 2005) or all previously linked dates (as Sillyfolkboy said). I do not know if that is related, but ref#65 on George Bush shows as "You must specify archiveurl = and archivedate = when using
{{cite web}}
: Empty citation (help)."Spending and the National Debt". Retrieved on 2007-06-25." You can see that article for plenty of broken date links. Renata (talk) 21:45, 20 July 2008 (UTC)- That ref#65 is a quite distinct problem - and I've just reverted anyway) - but if archiveurl is specified then an archivedate is required as stated in the documentation - that ref needs individual fixing :-) David Ruben Talk 21:59, 20 July 2008 (UTC)
- Yes, wikilink should be removed. It break all kinds of other dates used by editors. For example, half-dates (as July 2005) or all previously linked dates (as Sillyfolkboy said). I do not know if that is related, but ref#65 on George Bush shows as "You must specify archiveurl = and archivedate = when using
Just coming over to note that there are now messed up dates in citations throughout WP:FA; hope y'all are only halfway there, because what's there now isn't working. SandyGeorgia (Talk) 21:42, 20 July 2008 (UTC)
- The introduction of datestyle hasn't worked as planned. The idea was that no existing cite webs would be affected at all. I'm sure David will soon revert the change, then we can look at introducing datestyle without affecting existing citations. Rjwilmsi 21:49, 20 July 2008 (UTC)
- We should just create another template with these changes and test that, first. Gary King (talk) 21:50, 20 July 2008 (UTC)
- (ec). This has messed up thousands of articles' citations, and it makes linking to days and years using the template impossible without getting a redirect. I suggest a revert, at least until an adjustment can be made. Qst (talk) 21:51, 20 July 2008 (UTC)
- We should just create another template with these changes and test that, first. Gary King (talk) 21:50, 20 July 2008 (UTC)
- Besides everything else, I'm confused. I thought the idea was to delink dates; why are they being linked incorrectly, resulting in double links on what were previously correct dates? No longer sure what's up here. SandyGeorgia (Talk) 21:55, 20 July 2008 (UTC)
Done reverted - that is.David Ruben Talk 21:56, 20 July 2008 (UTC)
- Thanks David. Let's just wait until the dust settles, then have a look at how to introduce datestyle without affecting existing stuff. Rjwilmsi
- OK - I'm away from wikipedia for a short while, but I've spotted "the problem": the new coding affected how wikilinked accessdate and archivedate fields handled and only where datestyle was specified (default being the existing wikilinkage). "date" was never previously directly wikified and so accepted any input (error trapping showed as unlinked if not a normal date format) - whilst this is valid for webpages dates, we were thinking that if the coding was to be extended to books or journals, then error trap was needed for pre-1901 dates (MediaWiki issue), but clearly not an issue for webpages....
- Solution may be code in new style for just the accessdate & archive fields, but leave the date coding as was.
- What we then do for "date" parameter over at say cite_journal will need considering (perhaps a bot to take part dates, what I think just caused the most problems, over to say a "datetext" parameter, leaving "date" as real date information) ? David Ruben Talk 22:08, 20 July 2008 (UTC)
- I don't know the capabilities of the template code, but if possible I think we should do the following (for all dates): if valid datestyle set and date is unlinked ISO date, apply datestyle, else do as per current functionality (also keep the pre-1901 check). This will avoid any issues with existing citations and avoid the need for mass bot changes, and allow the datestyle to be used on the "date" field. Is it possible for the template to check whether the date/accessdate/archivedate matches a regex like
\d{4}-\d\d-\d\d
Rjwilmsi 22:18, 20 July 2008 (UTC)- Yes; it should already have a check in there for that. Gary King (talk) 23:45, 20 July 2008 (UTC)
- I don't know the capabilities of the template code, but if possible I think we should do the following (for all dates): if valid datestyle set and date is unlinked ISO date, apply datestyle, else do as per current functionality (also keep the pre-1901 check). This will avoid any issues with existing citations and avoid the need for mass bot changes, and allow the datestyle to be used on the "date" field. Is it possible for the template to check whether the date/accessdate/archivedate matches a regex like
- Don't know anything about what regex is, I presume it relates to query Tim Starling raised with me for editing DateFormatter.php - see http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3ATemplate_limits&diff=226629254&oldid=226493549 ? David Ruben Talk 00:48, 21 July 2008 (UTC)
- Regex is regular expressions. Gary King (talk) 00:59, 21 July 2008 (UTC)
- Gary King, are you saying it is possible for a template to check a parameter against a regex? How do you do that, I've never seen anything even close to that capability. I've never even seen a way to get a substring of a parameter. Anomie⚔ 02:02, 21 July 2008 (UTC)
- Not exactly; rather than actually using regular expressions (which if enabled and used incorrectly, could crush a template's loading time), what you can do is convert a string (either in YYYY-MM-DD format or not) to YYYY-MM-DD using #time; if the returned value is the same as the input value, then it's indeed in YYYY-MM-DD format and the check was a success. Gary King (talk) 02:13, 21 July 2008 (UTC)
- You're overlooking the part where that only works for dates between 1970-01-01 00:00:01 (UTC) and 2038-01-19 03:14:07 (UTC). Anomie⚔ 03:55, 21 July 2008 (UTC)
Review of current and sandbox coding
In summary whilst no problem for full ISO dates after 1970, all sorts of part-dates or text entries not handled in same manner where datestyle was unset, this not pre-tested for and do not have same overall default - see examples in subsection below (#Review of current and sandbox coding - examples).
The documentation does indicate though that:
- date: Full date of publication in the same format as the main text of the article. If in ISO 8601 YYYY-MM-DD format, e.g. 2006-02-17, must not be wikilinked; it will be linked automatically.
- OR: year: Year of publication, and month: Name of the month of publication. If you also have the day, use date instead. Must not be wikilinked
... and the sandbox had rather assumed there would be a full date in date even if not in ISO format (could still be handled), and part dates would use year and month whose handling remains unchanged as unlinked parameters (part dates in date is handled differently). As it is, date it seems is currently being used in articles with part-dates and freetext entries, and if we are not to change all the articles and wider-editor habits then alternative approach is needed.
The existing code sees if it is possible to use #time to set as y-m-d, if so then wikified date (showing as user preference else as a default ISO), but if not formatable by #time then left unlinked. As there was no internet pre-1970 a valid enough test. Handles following as indicated:
- Full dates after 1970 wikified as intended but with no editor-selection option of how dates shown
- Pre-1970 wikified as intended
- Pre-1901 cause error and so shown unlinked (a failing current coding method if used in other cite_XXX)
- Part-dates can't be formated and so are unlinked (might likewise be seen as a failing given not linked as full dates are)
- Free-text can't be formated and so are unlinked (a good handling of this unforseen option)
The {{date style}} metatemplate was to cope with say cite_book where values pre-1970 and pre-1901 might exist but due to PHP/MediWiki issues can not be formated by #time but can still be if wikified; hence error trapping here always forced wikilinkage. Sandbox would handle following as indicated:
- Full dates after 1970 wikified as intended with optional editor-selection of how dates shown
- Pre-1970 wikified as intended
- Pre-1901 wikified as intended
- Part-dates can't be formated and so are still linked (so far better as consitant with full date linking, although generates wikilinking where none seen before)
- Free-text can't be formated - as this assumed to indicate the pre-1901 issue and value is inappropriately attempted to be shown by wikification.
The basic problem is that the only test for pre-1901 dates seems to give the same outcome for a valid date as for free text:
- Hence: {{#time: y-m-d|1890-01-28}} gives: 90-01-28
- Hence: {{#time: y-m-d|undated}} gives: Error: Invalid time.
and we can't as far as I can immediately see compare wikilinked with unlinked values
- thus: {{#ifeq: [[1890-01-28]] | 1890-01-28 | yes |no}} gives: no
- also: {{#ifeq: [[undated]] | undated| yes |no}} gives: no
A pre-test for whether the page exits also fails to distinguish:
- Hence: {{#ifexist:1890-01-28|yes |no}} gives: no yet [[1890-01-28]] is 1890-01-28
- Hence: {{#ifexist:undated|yes |no}} gives: no but [[undated]] is undated
- Hence: {{#ifexist:[[1890-01-28]]|yes |no}} gives: no yet [[1890-01-28]] is 1890-01-28
- Hence: {{#ifexist:[[undated]]|yes |no}} gives: no but [[undated]] is undated
- But part dates might be trapped:
- Hence: {{#ifexist:January 2007|yes |no}} gives: yes as [[January 2007]] is January 2007
- also : {{#ifexist:2007|yes |no}} gives: yes as [[2007]] is 2007
- NB: {{#ifexist:Foo|yes |no}} gives: yes as [[Foo]] is Foo a real article
- But part dates might be trapped:
An error test on a wikifying pre-test for whether page exits also fails distinguish:
- Hence: {{#iferror:[[1890-01-28]]|yes |no}} gives: no
- Hence: {{#iferror:[[undated]]|yes |no}} gives: no
and a pretest for strong error from ifexists likewise fails An error test on a wikifying pre-test for whether page exits also fails distinguish:
- Hence: {{#iferror:{{#ifexists:1890-01-28|yes |no}}|yes |no}} gives: no
- Hence: {{#iferror:{{#ifexist:undated|yes |no}}|yes |no}} gives: no
- Hence: {{#iferror:{{#ifexists:[[1890-01-28]]|yes |no}}|yes |no}} gives: no
- Hence: {{#iferror:{{#ifexist:[[undated]]|yes |no}}|yes |no}} gives: no
The only solution, currently seems to abandon trying to correctly wikify pre-1901 dates and accept these must remain as unlinked freetext "as is" (so we loose appropriate red-linking error warnings for say "1865-05-32" as 1865-05-32).
... If everyone is happy with that, then we might easily and quickly reset up {{date style}} and {{cite web/sandbox}} for further reconsideration. David Ruben Talk 00:48, 21 July 2008 (UTC)
- If I have understood then this would mean: unlinked ISO dates between 1901 and 2038 will obey datestyle if set correctly. If datestyle invalid or not set, or date is in any other format, display as currently except that unlinked pre-1901 ISO dates will now not be wikilinked. So then the only change to current citations is that pre-1901 dates won't be wikilinked. That's probably okay, please set up the sandbox so we can all have a look/add examples. Thanks Rjwilmsi 07:27, 21 July 2008 (UTC)
- Rjwilmsi, you understand correctly :-) I've set out below a comparison table of options, with non-standard date styles & part-dates included... David Ruben Talk 20:48, 21 July 2008 (UTC)
Review of current and sandbox coding - examples
See {{cite web/sandbox}} for tested examples which seem to work (or at least be consistant in wikilinking accessdates and date fields). The examples showing current similarities and the problems just revealled are:
- Current {{cite web |title=Title |url=http://example.org |date=2007-10-16 |accessdate=2008-07-20}}
- Part date{{cite web |title=Title |url=http://example.org |date=August 2007 |accessdate=July 2008 }}
- Just year{{cite web |title=Title |url=http://example.org |date=2007 |accessdate=2008}}
- Free text{{cite web |title=Title |url=http://example.org |date=pre 2007 |accessdate=last week}}
- Ok so that is where the new proposal overlinked (valid) values for "date" and redlinked invalid date formats (something that seemed a useful feature, except "undated" was not considered as a possible valid value). But if the approach was to be extended to {{cite book}}, then current coding copes with pre-1970 dates but not pre-1901:
- Pre 1970:{{cite web |title=Title |url=http://example.org |date=1960-01-27 |accessdate=1965-05-16}}
- But pre-1901:{{cite web |title=Title |url=http://example.org |date=1860-01-27 |accessdate=1965-05-16}}
David Ruben Talk 00:48, 21 July 2008 (UTC)
Three questions: why are dates linked at all, when MoS no longer requires it. Why are solo years linked, when MoS has never recommended they be linked. And why are month year combos linked when linking them has never been recommended. I'm afraid I don't really understand what this undertaking is about: I thought the goal was to delink dates. SandyGeorgia (Talk) 01:21, 21 July 2008 (UTC)
- That's what I've been wondering myself. Gary King (talk) 01:23, 21 July 2008 (UTC)
- Was trying to preserve user-preference where set, but obviously too much so in case of part-dates. For a quick attempt at removing automatic wikilinking of dates: what I think is the status quo for dates, but reduces linking of accessdate, is User:Davidruben/sandbox4#Part dates and free text. For full removal of all automatic default wikilinking (and so not same as current, as the user-set preferences are never followed) User:Davidruben/sandbox2#Part dates and free text - but purpose of not having dates as just plain free-text was to continue some user-perference (and as we can't in MediaWiki read a user's preferences, then we have to continue practice of wikilinking where possible) - its catch-22. If need be, we can handle date differently from accessdate, but seems illogical (even though past editor flexibility might require it).David Ruben Talk 01:49, 21 July 2008 (UTC)
- In point of fact the MOS did at one point recommend the linking of solo years. Christopher Parham (talk) 00:07, 19 August 2008 (UTC)
David, thanks for your time and effort in trying to solve this issue. I think there's a sudden realisation among many people that the citation templates need to catch up with the evolution of guidelines and practice away from autoformatting and, certainly, the linking of single chronological fragments such as years and months. When editors are able to choose not to autoformat and link these items in their use of the templates (and hopefully to change from auto to non-auto without too much trouble), it will be a happy day on Wikipedia!
I do encourage you to persist in this noble task on your return. Thanks again. Tony (talk) 01:58, 21 July 2008 (UTC)
- Thanks. Just goes to prove that one can test in all ways one can think of, post notes reasonably widely, and when time comes some valid examples one had not considered are flagged up :-) Indeed the benefit of a wiki that others can & do join in. I think options are:
- per my User:Davidruben/sandbox4, possibly retaining stricter implementation that accessdate is supposed to always be in ISO
- rethinking use of date for anything other than full date (year and month being the alternative) - but this would need major changes to existing articles (? a bot) for this and upsetting many and the current article-specific consensus that might currently exist
- removing all wikilinking and abandoning user-preferences - likely to upset many
- some future changes to MediaWiki allowing #time to work as well as wikilinked dates in as much that accepts pre-1970/pre-1901 dates
- Personally... its time for my bed, as except for my pillow, enough feathers gently ruffled this evening including the servers me thinks upon the change & revert edits :-) David Ruben Talk 02:20, 21 July 2008 (UTC)
Ok here are how dates are variously handled: current cite_web handling of 'date' and 'accessdate', the problems shown with existing metatemplate date_style when applied these two fields, and two possible alternatives to it. Feel free to jump to important "Summary" at the bottom :-)
Value | Current template activity | Various new handling options | |||
---|---|---|---|---|---|
[[Wikified]] per 'accessdate' must be ISO |
Coding per 'date' ideally ISO |
{{date style}} datestyle=blank & =mdy |
My SB datestyle=blank & =mdy |
My SB3 datestyle=blank & =mdy | |
1980-01-02 | 1980-01-02 | 1980-01-02 | {{date style||1980-01-02}} & {{date style|mdy|1980-01-02}} |
1980-01-02 & January 2, 1980 |
1980-01-02 & January 2, 1980 |
2 January 1980 | 2 January 1980 | 2 January 1980 | {{date style||2 January 1980}} & {{date style|mdy|2 January 1980}} |
2 January 1980 & January 2, 1980 |
2 January 1980 & January 2, 1980 |
02 January 1980 | 02 January 1980 | 02 January 1980 | {{date style||02 January 1980}} & {{date style|mdy|02 January 1980}} |
02 January 1980 & January 2, 1980 |
02 January 1980 & January 2, 1980 |
2-January-1980 | 2-January-1980 | 2-January-1980 | {{date style||2-January-1980}} & {{date style|mdy|2-January-1980}} |
2-January-1980 & January 2, 1980 |
2-January-1980 & January 2, 1980 |
January 2, 1980 | January 2, 1980 | January 2, 1980 | {{date style||January 2, 1980}} & {{date style|mdy|January 2, 1980}} |
January 2, 1980 & January 2, 1980 |
January 2, 1980 & January 2, 1980 |
January 1980 | January 1980 | January 1980 | {{date style||January 1980}} & {{date style|mdy|January 1980}} |
January 1980 & January 1980 |
January 1980 & January 1980 |
1980 | 1980 | 1980 | {{date style||1980}} & {{date style|mdy|1980}} |
1980 & 1980 |
1980 & 1980 |
1960-01-02 | 1960-01-02 | 1960-01-02 | {{date style||1960-01-02}} & {{date style|mdy|1960-01-02}} |
1960-01-02 & 1960-01-02 |
1960-01-02 & January 2, 1960 |
1860-01-02 | 1860-01-02 | 1860-01-02 | {{date style||1860-01-02}} & {{date style|dmy|1860-01-02}} |
1860-01-02 & January 2, 1860 |
1860-01-02 & January 2, 1860 |
2 January 1860 | 2 January 1860 | 2 January 1860 | {{date style||2 January 1860}} & {{date style|dmy|2 January 1860}} |
2 January 1860 & January 2, 1860 |
2 January 1860 & January 2, 1860 |
unknown | unknown | unknown | {{date style||unknown}} & {{date style|dmy|unknown}} |
unknown & unknown |
unknown & unknown |
not indicated | not indicated | not indicated | {{date style||not indicated}} & {{date style|dmy|not indicated}} |
not indicated & not indicated |
not indicated & not indicated |
- Observations
- Any date shown as wikilinked full-date above, shows to a user who has set their date-preference in that chosen format. For all other registered users and all anons, they appear in a linked ISO YYYY-MM-DD style.
- Currently accessdate is specified as only for ISO values and hence red-link options seen above should never occur - and it currenly copes with part-dates and pre-1970 full-dates
- doomed date_style (allowed too much option for user-set preference):
- Default (datestyle unset)
- matched existing outcome for accessdate i.e. always wikilinked - but redlinks if value is not in ISO format
- NB only one of the options to wikilink ISO dates pre-1970 & pre-1901 and for those with a user-preference set, they would continue to see these dates shown in the style of their choosing (ISO, American, International). If user-preference not set then now shown as a linked blue ISO date (whereas currently as unlinked freetext)
- freetext options wikilinked if happens to be an article by that name as in unknown, but otherwise redlinked eg not indicated.
- However if we can agree some specific free-text options then these can be added to an exclusion-list within the metatemplate - see [7] which screens for value of "undated"
- Datestyle set
- partial-dates get wikilinked and far worse, day & month would have been magically created !
- Of course, if instead year and month parameters used for part-dates then no problem as those fields shown unlinked - however apparent that is not how this template is always used.
- NB As SB and SB3 options show, an easy bug to correct.
- Default (datestyle unset)
- My Sandbox (SB) column - nothing ever gets wikilinked.
- Default (datestyle unset)
- For user's with set preferences, this ignored for valid ISO dates after 1970 if datestyle unset - will they complain ?
- Part dates are unlinked
- Datestyle set
- Needed additional coding though to prevent a set datestyle from trying to format anything where a page exits (i.e. part-dates and recognised freetext) - the used #ifexists: coding will be a somewhat heavier load on the server.
- Default (datestyle unset)
- My Sandbox3 (SB3) column - matches current date display
- Default (datestyle unset)
- User preference seen for ISO dates only after 1970 (prior to this as unlinked ISO, so feature loss from current date_style).
- Part dates are unlinked
- Datestyle set
- Needed additional coding though to prevent a set datestyle from trying to format anything where a page exits (i.e. part-dates and recognised freetext) - the used #ifexists: coding will be a somewhat heavier load on the server.
- Default (datestyle unset)
- Summary
- So, where datestyle is not set: not linking on part dates in SB & SB3 means these nolonger appear as blue links but also freetext is never redlinked (?good idea, and as noted, we could have a preset list of accepted freetext terms). However these loose ability for dates prior to 1970 to be shown in a user-selected style.
- Where datestyle is set, then current SB & SB3 show one can fixed the separate error in {{date style}} with part-dates generating nonsense day & month values - easy enough to correct, but I've left that metatemplate alone for now.
Given how {{cite web}} has been used in articles, I think we should go with SB or SB3 option and state in the documentation that "parameter should entered in ISO style, except if before 1970 when the relevant American/International style may be used" (until if/when MediWiki issues addressed) ? David Ruben Talk 20:48, 21 July 2008 (UTC)
- Wow, that must have taken ages! Let me ask about SB3: assuming all accessdates entered are after 1970 (which seems reasonable as how do you access a source before the internet existed?) and assuming nothing about the other dates, am I right to say that (1) there will be no changes at all to existing citation templates if SB3 is implemented (2) date style will be achieved by setting a valid date style and using an ISO date for dates > 1970 and < 2038, and an unlinked full date for other dates (matching the date style entered). If yes and yes, I vote yes for SB3. (Date style and My SB cause a change to existing citations, which is not the purpose of date style, so aren't workable) Rjwilmsi 21:51, 21 July 2008 (UTC)
- Thanks (mulled over this most of the day, as need to try and cover all the things we previously had "assumed" we needn't cover). I (cautiously) from the table, think answers are yes & yes re accessdates :-)
- I'm still intrigued by Tim Starling's suggestion to edit regex at Dateformater.php, but the php recoding of MediaWiki itself is well beyond me and I'm not sure if could really fix any of the wider date-handling issues !
- Given everyone's feathers still need re-preening after yesterday (and alarming that servers definitely temporarily hiccupped with the edit and revert - delaying my ability to view problem coding examples - plus endless edit conflicts as I tried to speedily respond to everyones helpful and quick responses)... I’d really appreciate people trying out the SB3 metatemplate {{User:davidruben/sandbox3|style|date}}, and look at how this appears in the new sandbox version of cite web at {{User:davidruben/sandbox4}}.
- As for time frame, needs very clear acceptance in next few days (would be nice to have well-vetted and consensus-agreed conclusion to this soon), else will need wait a couple of weeks, as I'll be away for 2 weeks come Sunday :-) David Ruben Talk 22:38, 21 July 2008 (UTC)
- I'd like to also pitch in with this effort; however, a lot of it was done by you and so I would suggest we wait until you get back then we can continue with this. While you are away, I'm sure it wouldn't hurt to continue having discussions with what you have created and uncovered. Gary King (talk) 23:02, 21 July 2008 (UTC)
Proposal to go #2
Ok, I'm back from holiday and caught up on my real-world intray backlog. If people still wish to add the optional datestyle parameter as set out in thread above, then please let me know. I would greatly appreciate others testing out the proposed template and using it in ways I wont have thought of: use template sandbox of {{User:davidruben/sandbox4|author= |title= |url= |date= |publication= |accessdate= |datestyle=}} which implements the proposed sandbox upgrade of {{User:davidruben/sandbox3|style|date}} to the metatemplate {{Date style}}.
I'm going to softly propose implementation in 7 days ... David Ruben Talk 22:48, 18 August 2008 (UTC)
- Since you acknowledge that dates in the form YYYY-MM-DD are "ISO style", I imagine you mean ISO 8601. Every date in ISO 8601 format is a Gregorian date, or if before the adoption of that calendar, a proleptic Gregorian calendar date. Since it is not unheard of to cite a book that was published before 14 September 1752 (the date the British Empire adopted the Gregorian calendar), you should absolutely forbid any non-Gregorian date from being input or output in the ISO 8601 format. --Gerry Ashton (talk) 00:31, 19 August 2008 (UTC)
- I'm note sure sure I understand, the template can't "forbid" input by an editor, it can only offer to format where datestyle is set for dates between 1970 and 2038 until such time as mediawiki software has date handling improved. For now, most dates in most (but obviously not all) articles will relate to recent works and certainly all accessdates parameter values will be for after 1970 as no internet before then. If 'datestyle' is undefined then no processing of date parameters will be performed (i.e. shows as currently), hence "|date=1252-01-03 |datestyle=" will show as 1252-01-03 (likewise "|date=nonsense |datestyle=" as nonsense), and if the date before 1970 as in "|date=1252-01-03 |datestyle=dmy" then as per mediawiki issue of being unable to #time format before 1970 this cannot be manipulated and so shows as 3 January 1252. However if we wish all dates to be linked then such dates could be handled as [[1252-01-03]] displaying as 1252-01-03 (which appears for most editors who have not set their personal preferences and for all unregistered readers as an ISO 8601 format - only for the minority of registered editors who have set a personal preference as any type of formated date) - however the intension of WP:MOSDATE currently, as I understand it, is to move away from linking dates. So dates before 14 September 1752 are not an issue, as no wikipedia template can (currently) manipulate dates before even 1970. David Ruben Talk 03:05, 19 August 2008 (UTC)
- Where is the documentation for sandbox #4, which is what I think you intend to put in production in a while? --Gerry Ashton (talk) 03:33, 19 August 2008 (UTC)
- Sorry, sandbox4 is an alternative coding for the current {{cite web}}, the 'datestyle' documentation is that for the metatemplate sandbox3, itself an alternative coding for {{Date style}} (I've provided a clearer link per this edit to sandbox4 to point to the "polished" documentation. The examples of various options given in table higher up on this talk-page.
- But in essence, the datestyle parameter may be set to 'dmy', 'mdy' or 'ymd' (as in "24 August 2008", "August 24, 2008" and "2008 August 24") or of course left blank leaving dates displayed unaltered from how they are currently ('datestyle' being an optional feature). David Ruben Talk 04:10, 19 August 2008 (UTC)
- Where is the documentation for sandbox #4, which is what I think you intend to put in production in a while? --Gerry Ashton (talk) 03:33, 19 August 2008 (UTC)
So let me see if I've got the overview. David proposes to put the code currently in User:davidruben/sandbox4, which is a replacement for the {{Cite web}} template, into production on 24 August. The documentation for that template is at Template:Cite web/doc. That documentation makes no mention of the fact that the code has various forms of difficulty with dates before 1970. So the code does not behave as documented, and is therefore faulty. But David hopes it will be less faulty than the current version. Also, the new version will implement the undocumented datestyle parameter. So if the elite who read this page actually use the datestyle parameter in real articles, it will confuse the hell out of the inattentive editors who have not read this page.
In case you haven't figured it out yet, I'm a firm believer of writing the documentation first, and then writing the code to implement it. --Gerry Ashton (talk) 05:24, 19 August 2008 (UTC)
- My appologies, the documentation for the datestyle directly here in cite web was briefly shown before (before that is we turned the first coding off again), see this documentation. The revised coding will not need any changes to that as the #1 coding problem had been some extra linking appearing where none was intended and as the documentation already stated "then appropriate unlinked American/International format is shown". So the documentatoin would therefore be that of 22:39, 20 July 2008 (but of course further emphasis of this feature could always be given, but I don't think initially we wish to push it any harder that that) David Ruben Talk 11:40, 19 August 2008 (UTC)
- If you look at that documentation, the examples currently will show the various examples as ISO dates as the documentation is utilising the current cite web template which does not have datestyle enabled of course. (the examples of output are shown in the preceeding thread above). If you really want, I can copy the whole of that version of cite web/doc over to my sandbox4/doc, but that seemed unecessary as sandbox4's current documentation is to shows how the datestyle parameter will work, not to rehashing how cite web gets used, but I'm happy to oblige :-) David Ruben Talk 11:50, 19 August 2008 (UTC)
- I have created an essay which exercises the sandbox4 code, and describes how a documentation change could partially address the issue, only for Cite web. The essence of the change is to define in the documentation the date parameter to mean only the date the document was published on the web, not any earlier form of the document that might have existed in paper, stone, clay tablets, etc. Obviously this documentation fix only applies to cite web, becase the web, (unlike other media) didn't exist before 1970. --Gerry Ashton (talk) 18:01, 19 August 2008 (UTC)
Use of this template in other language versions
Whatever you're doing please consider that other WP languages – e.g. DE, ZH, PL – are using this template as well so parameters must not be changed to incompatibility. However IMO the source code should be cleaned up as much as possible. At this moment there is the redundancy of the paramteres date (full date or ISO date) vs. date/month/year. That feature should be omitted in the future. Linking of dates in citations I consider as unnecessary. In the German WP I enhanced the template with the de:Vorlage:FormatDate. It checks wether the date written in is in the ISO format and if so converts to the German language date conventions. If not it leaves the entry unchanged. So actually we're combining the advantages of both, ISO and conventional entries. Needless to say, that an entry like August 2008 does not make problems. --Matthiasb (talk) 18:43, 24 August 2008 (UTC)
- Ooh, clever - treating ISO as a literal number. Code then removes off dates, month and year by treating the "-" not as a dash but a mathematical minus. Hence {1}-({1}*2) is the day, i.e. 2008-08-25 - (2008-08-25*2) = 25 etc. This therefore works with any "ISO-style" date input, even before 1970 and 1900 ! A cut down version (using English, without linking options and some other stuff I haven't quite figured out yet) as my User:Davidruben/Sandbox5:
Value User:Davidruben/Sandbox5 2008-10-23 2008-10-23 1969-10-23 1969-10-23 1869-10-23 1869-10-23 2008-10-00 2008-10-00 2008-00-00 2008
- Has some neat possibilities of ensuring machine readable dates, but setting human (ie non-ISO) looking displays. If and when mediawiki gets directly better able to handle dates, the ISO date is still within the cite ref to be used however dates are then handled (who knows perhaps anon readers will be able to set Language (AmE vs BrE) and date preferences in a top option box, or else leave unset to follow an editor-selected default relevant to the page) David Ruben Talk 01:37, 25 August 2008 (UTC)
- That's a very cool method indeed. Very cool. Gary King (talk) 01:51, 25 August 2008 (UTC)
- Just tweaked to recognise a bad numerical entry, i.e. if input has a word in it (such as month name or some other free text), in which case shown "as is".
28 January 2008 28 January 2008 January 28, 2008 January 28, 2008 January 2008 January 2008 foo foo 2008 2008
- Could of course try using #time for such wordy dates (to force into Interntaion/American style), but that comes back to 1970/1900 limiting issues, and anyway this is accepting of wordy-dates and editor can enter in appropriate form (main issue been over accessdate parameter which should currently be entered in ISO style). Only immediate option not covered is year alone as in "2008" which gives 2008 (but works if entered as "2008-00-00" as set out above). That and some spaces issues for another day :-) David Ruben Talk 02:43, 25 August 2008 (UTC)
- This should only be used for the date= parameter though, right? accessdate will rarely, if ever, be before 1970, and I'd still prefer to stick with the "proper" built-in way rather than this way, which is still good but may have some problems. Gary King (talk) 02:55, 25 August 2008 (UTC)
- I find it a bit disturbing to see people playing with code with little discussion of trying to find the full requirements of the problem. For example, how are Julian calendar dates to be entered, and how shall the date be marked as being in that calendar? --Gerry Ashton (talk) 03:46, 25 August 2008 (UTC)
- Personally, I say ignore that issue, IMHO so what about Julian vs. Gregorian ? We make no distinction between "12 January 1257" and "12 January 1957" in terms of how we present dates, and I guess most readers will not be aware that one is Julian and the second is Gregorian, more importantly nor will they care (its only 10 days difference). If we have no distinction for full dates, why insist upon an ISO-style yyyy-mm-dd distinguishing (we are not beholden to the ISO body to only apply this style to Gregorian dates). Of course it is important to distinguish the date systems in the years whilst there were changes and discrepancy across Europe and as such needs to be carefully indicated where relevant, but I do not expect to see such distinction mentioned for dates clear of that, e.g. at Norman_conquest#Norman_invasion of England in 1066. Some good arguments have been made for yyyy-mm-dd style to persist (at least in coding) to help facilitate conversion into other language wikipedias (so choice of American/International English dates does not cover full range of worldwide readership for which we might offer some assistance). Unless you can obtain a consensus to start marking all full-dates be flagged as either Julian/Gregorian, then I do not see such discussion as other than tangential to whether or not to wikifying dates, what style to display and whether template input might restrict to a common internal style (whole discussion at {{cite web}} and above been about ensuring general readers do not then see this) . David Ruben Talk 00:29, 26 August 2008 (UTC)
- The answer is to use the Discordian calendar for all dates. Anomie⚔ 01:34, 26 August 2008 (UTC)
- Personally, I say ignore that issue, IMHO so what about Julian vs. Gregorian ? We make no distinction between "12 January 1257" and "12 January 1957" in terms of how we present dates, and I guess most readers will not be aware that one is Julian and the second is Gregorian, more importantly nor will they care (its only 10 days difference). If we have no distinction for full dates, why insist upon an ISO-style yyyy-mm-dd distinguishing (we are not beholden to the ISO body to only apply this style to Gregorian dates). Of course it is important to distinguish the date systems in the years whilst there were changes and discrepancy across Europe and as such needs to be carefully indicated where relevant, but I do not expect to see such distinction mentioned for dates clear of that, e.g. at Norman_conquest#Norman_invasion of England in 1066. Some good arguments have been made for yyyy-mm-dd style to persist (at least in coding) to help facilitate conversion into other language wikipedias (so choice of American/International English dates does not cover full range of worldwide readership for which we might offer some assistance). Unless you can obtain a consensus to start marking all full-dates be flagged as either Julian/Gregorian, then I do not see such discussion as other than tangential to whether or not to wikifying dates, what style to display and whether template input might restrict to a common internal style (whole discussion at {{cite web}} and above been about ensuring general readers do not then see this) . David Ruben Talk 00:29, 26 August 2008 (UTC)
- I find it a bit disturbing to see people playing with code with little discussion of trying to find the full requirements of the problem. For example, how are Julian calendar dates to be entered, and how shall the date be marked as being in that calendar? --Gerry Ashton (talk) 03:46, 25 August 2008 (UTC)
- Davidruben wrote "we are not beholden to the ISO body to only apply this style to Gregorian dates". We are if we say we are. Are you prepared to expunge from Wikipedia all the comments about this date format being an ISO date format? I think the idea that the idea that this format is controlled by ISO is so widespread both within and without Wikipedia that we cannot erase that idea from people's minds. We might as well try to convince people that within Wikipedia, 12:00 PM always means noon and that 12:00 M is unacceptable notation.
- Note especially that the documentation for this template says in at least two places that it uses the ISO 8601 standard. --Gerry Ashton (talk) 01:36, 26 August 2008 (UTC)