Help talk:Citation Style 1/Archive 16

I have a fact from a magazine (using cite journal). The article in the magazine goes from page from 11-14, *but* the single fact being referenced is on page 13. So, do I have pages=11-14 or page=13? — Preceding unsigned comment added by Naraht (talk • contribs) 00:15, 4 April 2016 (UTC)

The single page. --Izno (talk) 00:45, 4 April 2016 (UTC)

And {{cite magazine}} if the periodical is a magazine and not a scholarly or academic journal. Others apparently disagree with Editor Izno since many many journal cites list all of the pages that an article spans which, to my mind, doesn't really aid the reader in locating the supporting text. I, however, do agree: if the fact is on one page, identify that page in the cs1 template.

—Trappist the monk (talk) 00:54, 4 April 2016 (UTC)

Indeed, I disagree: the full page range is part of the identification of the article, and it is standard practice to give it for journal articles and contributed chapters of edited books. The specific page number is also useful information, but in these cases it would have to go outside the template. Kanguole 01:05, 4 April 2016 (UTC)

I might agree that you should cite the page range if the entire page range supported the statement being made. But that is clearly not the case being considered. I don't see how I can agree to the page range identifying the article, much less why it should be standard practice when no other types of works do the same. --Izno (talk) 01:39, 4 April 2016 (UTC)

Use {{cite magazine}} and |page=13. The reader should not be expected to hunt through the entire article to find the supporting statement. The identification of the article is not a reason for using a page range, but is a reason why you should also make sure that |title= is filled in with the title of the article. --Redrose64 (talk) 07:44, 4 April 2016 (UTC)

When citing journal articles, it's standard academic practice to give the page range; similarly when citing chapters in books. The rationale is that in both cases we are dealing with a contribution: the 'published entity' is the journal volume or the book; the page range locates the contribution within that entity. When the article or chapter is long, I've usually also given an individual page or pages, outside the template as Kanguole says above. However, I've had these 'extra' pages removed by at least one editor on the grounds that it's not normal practice. When |pages= is being used for the 'contribution', I'm wondering whether we can provide an extra parameter for the more precise location. Peter coxhead (talk) 07:52, 4 April 2016 (UTC)

I might be persuaded that identifying all of the pages of an article or a chapter has value in a bibliographic listing of the author's writings, though I'm not really sure what that value is because identifying both the article title and all of its pages seems redundant to me. I am hard put to imagine how identifying all of the source's pages in a citation helps a Wikipedia reader verify the content of our articles. Searching through an entire journal article is more difficult than searching through a single page – even if you have an electronic copy and can figure out a workable ctrl+f search term.

I think that this 'academic practice' is inappropriate for a general audience; much like abbreviated journal titles are inappropriate for those outside of the specialty. I wonder if this practice is a result of laziness on the part of our editors who are aided by tools like RefToolbar which returned this when I gave it a PMID:

{{cite journal|last1=Mosher|first1=DF|last2=Wing|first2=DA|title=Synthesis and secretion of alpha2-macroglobulin by cultured human fibroblasts.|journal=The Journal of experimental medicine|date=1 February 1976|volume=143|issue=2|pages=462-7|pmid=55456}}

The work is done and because it was done by the machine must be correct, right? Hardly.

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

If you are trying to find a paper in a bound volume of a journal in a library (and, yes, sometimes you still have to do that!) then the number of the first page is very helpful. The same applies to a chapter in book, or any other kind of contribution you want to find within a printed work. The end page is just convention, I think. Peter coxhead (talk) 12:32, 4 April 2016 (UTC)

Isn't that why someone invented the table of contents? A proper citation includes the page number where the supporting text can be found. No need to include the article's first page number (or its last).

—Trappist the monk (talk) 12:44, 4 April 2016 (UTC)

I think giving the entire page range might go back to the days when, as a courtesy, libraries would send copies of an article to another library. This way, an engineering major who had a student job as a library aide could make a copy of a French-language history journal while hung over from a party last night. Jc3s5h (talk) 14:35, 4 April 2016 (UTC)

@Trappist the monk: I agree with you re the page number where the supporting text can be found, at least for contributions longer than a "few pages". However, I'm not sure there's a consensus for this for journal articles, particularly since it often means multiple references using something like {{sfn}}, and as I said above, I've had them removed. Anyway, WP:CITEVAR protects styles currently in use, so we're stuck with them, and there's no prospect of a change there. Peter coxhead (talk) 16:52, 4 April 2016 (UTC)

For journal articles, best practice is to give the full page range. If it's important to know exactly were, you can use |pages=14–19 [17] or similar ("See p. 17 in Smith (2012)." / "See p. 17 in Smith J. (2012) "Important article". Important Journal. 6(4):14–19.") Headbomb {talk / contribs / physics / books} 17:31, 4 April 2016 (UTC)

Using |pages=14–19 [17] would pollute the metadata, which assumes that |pages= contains the full page range of the article. In addition to the other solutions, the issue can be avoided by using shortened footnotes or {{rp}}. Kanguole 17:48, 4 April 2016 (UTC)

{{rp}} is a blight upon the world though. Better to have bad metadata and correct visual outputs than those horrors. Headbomb {talk / contribs / physics / books} 18:17, 4 April 2016 (UTC)

I'm not sure I would put it so strongly, but I also quite disllike {{rp}}. It gunks up the appearance of the article and gratuitously splits the information you're looking for into different places, for no benefit at all that I can see. —David Eppstein (talk) 18:49, 4 April 2016 (UTC)

I agree with "blight upon the world". {rp} was an attempt to provide a useful bit of information (a specific location within a source). But it is totally in the wrong place, and reflects a lack of understanding of how to use the available tools. It should be deprecated. ~ J. Johnson (JJ) (talk) 19:43, 4 April 2016 (UTC)

As to the broader issue: it is mostly definitely established standard practice that the citation of a source, magazines as well as journals, is to give the full page range. This has various benefits, including showing how big the article is (giving an idea of how much material it has, and how comprehensive). If one uses a source only once, and doesn't want to add a separate short cite simply to provide a specific location, just add the specific page number (or section or whatever) following the citation template. E.g.: <ref> {{citation ... |pages= 11-14}}, p.13. </ref>. All the information is present, in a form and the place where it is understood, unlike the cryptic ^[1]13. ~ J. Johnson (JJ) (talk) 19:49, 4 April 2016 (UTC)

I regularly use this approach, but it does create a small problem with links. If the information is on p.13 and the source is online, it's reasonable to expect a link to this page. So where do you put it? If you use something like [http://... p.13], then you can't put an access date in the citation since this produces an error without |url=. So you have to put a URL for the whole source, even though it's not actually needed. If designing a citation template from the start, I'd suggest something like |pagespan= for the full page range and reserve |p= and |pp= for the location of the information. But I guess it's too late now. Peter coxhead (talk) 20:18, 4 April 2016 (UTC)

Well, |p= and |pp= do point to the location of the information within the source: but they do that from {{Harv}}. Perhaps you momentarily confused them with |pages= in the citation/cite templates?

The |accessdate= parameter shouldn't be affected by anythng that comes outside the tmeplate. Are you sure you have closing braces in the right place? E.g.: <ref> {{citation ... |pages= 11-14 }}, [http: ... p.13]. </ref>. Otherwise, perhaps you have an example? ~ J. Johnson (JJ) (talk) 23:09, 4 April 2016 (UTC)

|p= and |pp= are aliases of |page= and |pages=.

—Trappist the monk (talk) 00:08, 5 April 2016 (UTC)

That is not a good idea. In that the page range of a source (which can be a single page) is NOT the same as the specific page(s) in a source, different parameter names would help to distinguish them, while making them equivalent only weakens the distinction, leading to the kind of confusion we have seen here. ~ J. Johnson (JJ) (talk) 22:53, 5 April 2016 (UTC)

I am not at all sure that I understand what it is that you wrote nor how it bears on parameter aliases (which have been in the module since its first incarnation).

—Trappist the monk (talk) 23:58, 5 April 2016 (UTC)

What do you not understand: that pagination of a source itself is not the same as pagination of a section within the source? Or that when similar parameters, that use the same kind of data, but in different contexts, are given the same names it will blur the distinction, create confusion, and raise questions and discussions exactly as we have here? ~ J. Johnson (JJ) (talk) 17:31, 6 April 2016 (UTC)

Why you think that for cs1|2 the meaning of |p= is or should be different from the meaning of |page= and that the meaning |pp= is or should be different from the meaning of |pages=.

—Trappist the monk (talk) 09:48, 8 April 2016 (UTC)

Because (as I have said before): the page range of a source itself is not the same as the page (possibly mulitple pages) of a section within the source. And it is long-established standard practice that the full citation of a source gets the full page range of the source. ~ J. Johnson (JJ) (talk) 20:55, 8 April 2016 (UTC)

Where is it written that it is long-established standard practice? When I cite a source, I put the actual page numbers that the facts were given on. To give more is both misleading and a waste of time for those who later wish to verify my claims. --Redrose64 (talk) 22:27, 8 April 2016 (UTC)

Of course you should put in the specific page number(s) where the specific material ("facts") are to be found. That is what would be put into the |p/pp= parameters in Harv. Or following the full citation, as I illustrated above. But the full citation of the source, where it is only part of a larger work (i.e., an article or chapter), is, conventionally, the full (or inclusive) page range of the whole source. E.g.:

CMS-13, Ch. 16, Bibliographic forms:

§16.3: For an article in a periodical include "Pages occupied by the article."

§16.5: Examples of inclusive page ranges.

§16.50: Inclusive page numbers for chapters or parts of books.

§16.106: "Inclusive (first and last) page numbers are usually provided for journal articles in bibliography entries; they not only help the reader find the article but indicate the length of it."

§16.114: Examples.

MLA-6th specifies inclusive page numbers in various places.

§ 5.6.7, p. 158: "Give the inclusive page numbers of the piece you are citing. Be sure to provide the page numbers for the entire piece, not just the material you used."

§5.7.1 (articles in periodicals), p. 183: "The inclusive page numbers cited should encompass the the complete article, not just the portion you used. (Specific page references appear parenthetically at appropriate places in your text ...."

§ 5.7.6, p. 187: "The entry for a magazine article ends with a colon and the page-number range of the article."

And I could go on, but surely this should be sufficient demonstration. ~ J. Johnson (JJ) (talk) 22:06, 9 April 2016 (UTC)

Assuming that there would be only one page to point to, we could solve and support this case without breaking any existing citations simply by allowing |page= and |pages= to exist at the same time. |pages= would then hold the full page range of the article, whereas |page= would just point to the page supporting the statement - like a bookmark. There could even be some (limited) error-checking: If both values exist, the |pages= range should include the page specified by |page=. One remaining question is how this special case should be rendered - we might put the |page= page in brackets or - more pragmatically - just comma-append it to the |pages= range. Another open question is what should be put in the meta-data?

If, however, there are multiple pages supporting the statement, |page= cannot be used. An alternative approach would be to not change the behaviour of |page= and |pages=, but add a |bookmark= parameter, which could include a comma-separated list of individual pages, all checked to reside inside the page range specified by |pages= (or |page=). If the |bookmark= parameter exists without a |page= or |pages= parameter, it could be treated as an alias.

--Matthiaspaul (talk) 20:01, 18 April 2016 (UTC)

On the metadata question, it is fairly clear from the OPENurl specs that rft.pages should only be used when the item cited is part of a collection item, i.e. a journal article or contributed chapter in a book (denoted by rft.genre being article, bookitem or proceedings) and that in such cases it should be the full page range of the article or chapter. Kanguole 21:11, 18 April 2016 (UTC)

Matthiaspaul: No, not at all. The distinction between |page= and |pages= is solely to indicate "number" - i.e., to distinguish between single and plural. That specific locations are often just single pages, while sources are usually multiple pages, does not warrant this distinction you would overload onto these parameters. Exceptions are common, and your proposal would indeed break many existing citations. Handling exceptions with brackets or such would just make matters more arcane, to the confusion of editors and readers both.

What you seem to not recognize is that the full citation - i.e., the description - of the source is entirely unaffected by what parts are specifically cited in the text, or how many times. If it were otherwise the full citation would have to be modified every time a specific cite was added or removed. If you must use full citations in-line (that is, without short cites) just add the specific locations following the citation template (as I have shown, above). That would be much more straight-forward. ~ J. Johnson (JJ) (talk) 21:27, 18 April 2016 (UTC)

cs1|2 does not make a distinction between full citations used with short citations and 'other' citations. The documentation, such as it is, at Help:Citation_Style_1#Pages has this first sentence:

"An editor may use any one of the following parameters in a given citation to refer to the specific page(s) or place in a cited source that contains the information that supports the article text." – where "one of the following parameters" refers to |page=, |pages=, |at=

In the description for |pages=, the assigned value may be a comma separated list of individual pages, an en dash separated page-range, or a combination of both. The documentation does not require |pages= to list all of the pages occupied by the source material (all of the pages of a journal article, all of the pages of a book chapter). Listing all of the pages may be appropriate in bibliographies or when an article uses full citations with accompanying short citations. When an article is not so formal as to use full citation together with short citations, identifying the "specific page(s) or place in a cited source that contains the information that supports the article text" within a cs1|2 template using one of the in-source location parameters is appropriate and should be preferred over listing all of the source's pages.

Similar instruction can be found at Template:Cite_book#In-source_locations (and other of the cs1|2 templates as well).

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

That documentation is clearly incorrect when the these templates are used in lists, e.g. in bibliographies, further reading lists and targets of short references. I would maintain it also does not describe common practice when these templates are used inside ref tags. The examples in those doc pages, on the other hand, do describe the usual practice of giving full pages for journal articles and contributed book chapters. It seems we will need an RFC to settle this. Kanguole 22:37, 18 April 2016 (UTC)

Yes, that documentation needs to be corrected. ~ J. Johnson (JJ) (talk) 18:03, 19 April 2016 (UTC)

It is not necessary to give the whole page range as an aid to locating the article. Wikipedia has Article X, containing Claim Y, which you doubt, but there is a reference Z. Ref Z indicates that the information may be found in Journal A, article B, date C, p. 123. You go to the library, find (or have brought to you) the journal in question (which might be a single issue or a bound volume, it doesn't matter). What does matter is that it has dates and page numbers in the top or bottom margins (of most pages). You don't know if the article begins on page 123 of the issue for date C or on an earlier page, and you shouldn't care - you turn to date C page 123, start at the beginning of page 123 - no earlier - and go through maybe 3/4 of the page before you find the relevant text, probably stated using slightly different wording, but it's there and supports Claim Y in article X. If you don't find it before you get to page 124, the ref does not support the claim. Either way, job done. Now imagine that ref Z is exactly the same except that it shows "pp. 108-127" - you turn to page 108, where the article begins, and need to go through a little more than fifteen pages before you find Claim Y. If you don't find it by the time you get to page 128, you wonder if you missed it somewhere and check through the whole thing again, by which time you're pissed off with the whole thing. --Redrose64 (talk) 11:08, 19 April 2016 (UTC)

You are confusing some things. For finding specific material at a specific location within a source specific page numbers (or similar) are certainly helpful (and I would have required), as you have illustrated. And it doesn't appear that anyone here is arguing that we should not have specific page numbers for that purpose. What you seem to have missed is that having the source's inclusive page range does NOT preclude specific page numbers. Your example is set up as an either/or, which is a false dichotomy. As I keep saying, you use specific page numbers in the short cites, which are specific to each use of any material. If you don't use a short cite - presumably because the source is cited only once - then (as I keep saying) just append the specific page number after the citation template.

You also fail to consider what happens when a source is used more than once. In your conception the page range could include every page specifically cited, but there would be no indication of which page goes to which use. For a short but heavily cited source these page numers approach the page range.

The bottom line: the full citation is a description of the source, not of the which parts within it have been used in the WP text. Ideally this description is invariant across all articles, and even all Wikis. ~ J. Johnson (JJ) (talk) 18:09, 19 April 2016 (UTC)

I am confusing nothing. I am trying to assist the original poster, Naraht (talk · contribs), who at no point indicated that they were using short cites - a referencing method that I am very familiar with, having used Shortened footnotes extensively for well over six years. Only yourself and Kanguole seem to be assuming that Naraht is doing that. I happen to know - having checked Naraht's contributions from just before and just after they posted here - that they were working on Alpha Phi Omega, which is using the ordinary, everyday, common-or-garden method of placing a cite template inside <ref>...</ref> tags, see for example this edit. No short cites, none at all. --Redrose64 (talk) 00:10, 20 April 2016 (UTC)

Just to indicate the way that I've used these... I have never used Shortened Footnotes, but have on occasion used Template:rp.Naraht (talk) 02:21, 20 April 2016 (UTC)

Redrose64, whether you are speaking for yourself, or for Naraht, my comments are still applicable to your narrative demonstration of why specific page numbers are needed. In which I actually concur. My issue with your comments starts with your "Now imagine that ref Z" uses the inclusive page range of the source. While you are not explicit about it, your narrative expresses the issue as either specific page(s) or inclusive page range. Which is exactly as Nahrat initially expressed it: "pages=11-14 or page=13?" That Nahrat is not using short cites (which neither I nor Kanguole assume, so you are wrong to suggest that) is perhaps part of the problem, but not necessarily relevant, because AS I KEEP SHOWING, it is quite possible to use inclusive page ranges (of the source) and specific page(s) (within the source) TOGETHER, without short cites. E.g., "using the ordinary, everyday, common-or-garden method": <ref>{Cite magazine|...|pages= 11-14}, p. 13.</ref>. The only problem is if you try to make |pages= do more than one thing at a time. Is there any part of this you do not understand? ~ J. Johnson (JJ) (talk) 00:24, 21 April 2016 (UTC)

Naraht, please not Nahrat

Oops! My profound apologies. ~ J. Johnson (JJ) (talk) 18:25, 21 April 2016 (UTC)

I'm through here. I came to help Naraht, not to be abused by J. Johnson and find that they are willing to apologise to Naraht and not to me. --Redrose64 (talk) 19:01, 21 April 2016 (UTC)

I am not aware that you are owed any apologies. I am generally pleased to offer explanations where something is not understood, and to consider why an explanation falls short, but it seems to me that the problem here is due to inattention on your part. ~ J. Johnson (JJ) (talk) 19:55, 21 April 2016 (UTC)

Just for the records, I was trying to help Naraht as well. I have run into this "problem" often enough and while I typically provide page ranges because it is common practise for journal articles (and because it helps when searching for or trying to obtain an article), I also acknowledge that a specific page number makes it easier to verify the information if the article is accessible on a page-by-page basis (online or in front of me), so I would prefer if there would be a dedicated place to put this information as well.

My approach was to offer a compromise solution which would allow us to support both, inclusive page ranges and specific pages at the same time, so that editors could either choose their preferred style, or provide both. I made two proposals how to possibly achieve this, and although they have pros and cons, none of them would break existing citations. I'm open for other solutions as well as how to actually render the output (append the specific pages to the inclusive range, put them in brackets, etc.). What I do not support is to place the specific page outside the cite template as it defeats the whole purpose of using templates to aid machine readability and give a consistent, but still easy and centrally maintainable output. Placing the info outside the template is like missing an opportunity and it puts the burden to maintain such free-flow information on future editors. I see your point that a specific page is a sub-object of a page range covering a whole article, and that it could therefore be put into a different template as well. However, it is trivially easy for bots to extract the info from one template and move it to another large-scale and over millions of articles, would the community decide to reorganize this somewhen in the future. But if the info is only provided as free flow text following a template, reorganizing it requires manual editing. This is why any such info belongs into dedicated parameters, not free-flow text. --Matthiaspaul (talk) 22:48, 22 April 2016 (UTC)

Of course sometimes an article is on a single page, and sometimes the sentence you're citing is split between two pages. User:Peter coxhead mentioned the possibility of having two sets of page parameters above, but wondered if it was too late for that. The transition might be possible, though. Bots could be designed to do the right thing in most cases. Kanguole 23:08, 22 April 2016 (UTC)

Kanguole touches an important point: the source pagination is usually an "inclusive page range", but sometimes a single page, and the pagination of the specific material cited within the source is usually a single page, but often is multiple pages. But lest there be an confusion: the issue here is not whether the pagination is single or multiple. The issue is whether the pagination pertains to the entire source, or just the page(s) of the specific material cited. I think the case has been made generally that both are important, and the issue is how to accommodate both. Kanguole suggests a bot, but I don't see how that could be done (at least not on any inherent distinction of the data), nor how that would be useful, the users of this information being readers and editors, not bots.

I would like to examine Peter's Matthiaspaul's (and perhaps others?) objection to placing the specific pagination outside of the cite/citation template. My position is that it does not belong inside the template, that the purpose of the full citation that such templates produce is entirely about the source itself, not about how the source is used in an article. Ideally, the citation for a source is (aside from differences of style and presentation) essentially invariant for all articles, regardless of how it is used. Conversely, if the citation template includes each article's specific use of the source, then each article has a different citation. Also, the cite/citation templates have no way of pointing into an article, to show where the material is used. (Even when named refs are used to create links at specific locations, the contained citation has no way of indicating which source pages are applicable at each location.)

But to return to the objection, what kind of "opportunity" are we missing if article specific usage is not incorporated into the full citation? What purpose is served? Why should a bot be moving such article specific information anywhere else?

If we really need to capture such specific information then the template to use is {{Harv}}. Where I have suggested appending specific pagination to the citation template is for where editors use a source once, and don't want to bother with any kind of short cite. ~ J. Johnson (JJ) (talk) 22:25, 23 April 2016 (UTC)

@J. Johnson: I don't object per se to placing specific pagination (or other specific location information) outside the citation template (I do it all the time); the "small concern" I expressed above was about what happens when it is linked via a URL. This applies whether it's put inside the ref tags but outside the cite/citation template or in one of the Harv/sfn family of templates. It's not possible to have an access date or an archive date other than for a URL inside the template; if you provide them in the main citation, they will be ignored unless there is a URL there. Sometimes you can get round this by using e.g. {{cite book}} with |contribution= and |contribution-url= and basically inventing a contribution title for the specific page, but this is a fudge. Peter coxhead (talk) 10:19, 24 April 2016 (UTC)

Oops, got my threads confused. Peter's "small problem with links" was back on 4 April, and is about using access dates with specific pagination. As a quick comment on that, I think access dates are generally more appropriately applicable to the whole source. But if someone were to, say, check only one "fact" out of several that were cited from a source, then that access date would be specific in the same manner as pagination, and best handled outside of the template.

The objection I was addressing is, of course, that raised by Matthiaspaul. ~ J. Johnson (JJ) (talk) 19:34, 24 April 2016 (UTC)

@Matthiaspaul: would you care to explain on what kind of "opportunity" are we missing if article specific usage is not incorporated into the full citation? ~ J. Johnson (JJ) (talk) 21:56, 26 April 2016 (UTC)

Regarding "missed opportunities". If information is given as free-flow text outside of any framework, it isn't parsable, so it is lost for machines to read and thereby for any potential output they might generate. Possible benefits from including it in the template: parameter format and range checking; centrally coordinated changes in the display format of citations, perhaps even dynamically adjusted to user preferences or output media; generation of indexes for reverse-lookup, which pages in citations are referred to in which articles; potential template features like direct linking to specific pages in conjunction with certain external resources like Google Books; possibility for bots to completely reorganize any information related to citations based on automated scripts would this become necessary in the future - for example because citation templates would be split up into several templates, or all data be moved to Wikidata; various other external uses which might benefit from information about specific pages in citations, f.e. improved search engine functionality. If we don't store the information in a parameter now, editors will likely have to retrofit it somewhen in the future. Editors working on an article might have the page information readily available right now, so the info could be added with minimal effort, but many of them might not provide it simply because there is no well-defined place to put it. Future editors may not have the reference available to them, but even if they have, looking up the information again takes more time than it would have costed the original editor. That's what I call a "lost opportunity" and a "waste of precious editor time".

Regarding "providing page ranges as template parameter but specifically referred-to pages outside the template". This approach depends on page ranges to be the last information displayed by citation templates, so that specific page information can be appended outside the template. However, often this condition isn't met, as it depends on the usage of various other parameters like |issn=, |doi=, |archive-url= etc. Such info is displayed after that of |page=/|pages=, so using such parameters would cause article page ranges and specific pages to be displayed in different locations in a citation, which is highly undesirable as it breaks the logical flow. Even if this wouldn't occur at present, another editor could always add a parameter or the community could decide to change the order of displayed template information for some reason in the future. Therefore, the info should be made part of the template in order to ensure a coherent output in the future without a need for manual reediting.

Regarding "invariability of citations". I see your point here and like that idea in general, but thinking about a better data organization in the future shouldn't hinder us to provide the necessary framework to enter the data now, even if it is following a more pragmatic approach. I don't consider it as a major problem that we will have to edit the page parameters when copying citation templates to other articles. My point here is that as soon as we've put the information into parameters, we're on the safe side, because it enables bots to convert the information into whatever new format and organization we might need in the future. Much better than not providing the information at all (or in unparsable free-flow text outside a template).

--Matthiaspaul (talk) 08:58, 28 April 2016 (UTC)

This needs some study. ~ J. Johnson (JJ) (talk) 19:42, 28 April 2016 (UTC)

Your general theme seems to be that data on specific pages cited should be templated (put into parameters), just in case there is some future use for that data. Please note that I am not arguing against templating such data. My argument is that the full citation (as prepared by the cite/citation templates), and particularly the |pages= parameteer therein, is the wrong place for that data. If such data must be templated, fine, but that should be done through a template suitable for that purpose, such as {{Harv}}. If Harv is too much trouble for a single-use reference we could look at a special template for that purpose. But no such purpose is served by bastardizing "pages=".

As you eschewed any "need for manual reediting" in your second paragraph, it is odd you "don't consider it as a major problem that we will have to edit the page parameters when copying citation templates to other articles." More troubling is that you fail to grasp that mixing specific pages cited in with source inclusive page range makes for less coherent usage, in polluting the latter with the former. Having specific page numbers following a citation (where they are not otherwise templated) is parsible at least by humans; mixing these kinds of data is unparsible. This amounts to misuse of |pages=, and does not serve the purposes you want. ~ J. Johnson (JJ) (talk) 22:29, 29 April 2016 (UTC)

No, I never proposed to mix specific pages cited and source page ranges in any way, quite to the contrary, I suggested several ways how to better distinguish between them in the future. At present, we have no specific rules for this, and editors use the existing |page=/|pages= parameters for both infos depending on their preferences (and this is also why the OP came here asking for assistance).

I did state that both page-related infos should be grouped together in a citation (in a format making it possible to distinguish between them, of course), as distributing page-related info all over the place breaks the logical flow for readers. However, this isn't possible (except for in exceptional cases, and your example further up is one of them) when appending the specific pages cited as free flow text or putting it in another template following the main template. It's only possible when putting all that info into the main template, even if this means that it carries invariable and variable information then. Let's face it: It already does contain variable information right now - and large scale -, so we're not making things worse in any way. (Regarding invariable and variable parts of citations, specific page info is only one variable info, any context-specific info like the handling of languages or dates is another - and larger - part, so following your idea, this would have to be split out of the citation as well.)

Regarding reediting. It would be nice if any editing could be avoided (but it can't in the current implementation), but I don't consider it a problem to adjust (or delete) the specific page info when copying citations to different articles. This is not reediting, as it happens at the same time when the citation is copied, and the editor who does must have the reference available in order to cite from it, so the effort is minimal. What IMO should be avoided is storing citation-related information outside of a citation template, because this will require manual reediting (instead of bot editing) if the output format of the template or the organization of citations changes in general (for example, when the info is moved to Wikidata). The reediting problem could be solved also by using two templates, but the other issues require all the info to reside in a single template.

In either case, it may still take years before the citation framework gets reorganized to solve some conceptual issues (and when this happens the transition will for sure be bot-assisted, similar to when inter-wiki links or authority control info were moved to Wikidata), but this should not hinder us from providing a well-defined place to put the specific page info now, as it requires only minimal template editing and basically could be had in days, without breaking any existing citations and without getting in the way of any future developments. Editors could start providing specific page info now, so waiting years for a perfect solution is wasting uncountable opportunities to improve articles in those years.

--Matthiaspaul (talk) 12:04, 30 April 2016 (UTC)

Perhaps we have gotten a little confused here, but the original question here was whether the page=/pages= parameter should have the source inclusive or material specific pagination. As to distinguishing them, I say that is simple: |pages= gets only the source inclusive page range. Are we agreed on that part?

As to where the material specific pages should be included, I have suggested two places. 1) In a short cite (e.g., with Harv). 2) Or, where a source is cited only once and an editor doesn't want to set up a short cite, simply appended to the full citation. To which you object, saying that every specific usage of a source in an article must be parameterized in some kind of template so that it is readily accessible for some feature we don't yet have. Well, if you want to prepare for that I suggest you urge everyone use Harv, but that is a different question than what we have here. Similarly for any discussion of any new features ("well-defined places"?) that might be added.

While we could be in accord on the foregoing, I strongly disagree with you in regards of having the full citation (via {{citation}} or {{cite xxx}}) record every specific use made of a source by every article. That is simply ludicrous. My argument on this (in brief) is that as the source itself is not changed when ever it is cited, the description of the source should also not change. Now you say you don't mind a little reediting, but wny should every editor that copies a full citation have to delete the previous editor's additions? The only reason you would force this on us is because you want to preserve the specific usage details for some future use. Which I would not object to, except that within the citation template (and especially pages=) is the wrong place for that. ~ J. Johnson (JJ) (talk) 21:35, 2 May 2016 (UTC)

For {{cite journal}} (the original question), I agree that |pages= should be source inclusive. However, for {{cite book}} it should be material specific: we don't need to know how many pages the book has, but it is more useful for books than for journals to specify where in the book the relevant information can be found. —David Eppstein (talk) 22:35, 2 May 2016 (UTC)

That would mean that |pages= in journals differs from |pages= in books, which is not a good idea: being inconsistent confuses people, and would encourage the "wrong" usage in journals. And such a distinction would be practically impossible when using {{citation}}. While you are correct that, for citation purposes, we usually are not interested in the number of pages for books themselves, yet we also cite chapters, prefaces, etc. in books, for which an inclusive |pages= is helpful. ~ J. Johnson (JJ) (talk) 22:25, 3 May 2016 (UTC)

I noticed that the static text associated with |translator= is capitalized in cs2 citations. Fixed in the sandbox.

—Trappist the monk (talk) 13:26, 7 May 2016 (UTC)

@Trappist the monk: I was thinking that |arxiv= and |bibcode= could very likely be used to double check the year/date. Quite often, a cite arxiv (say from September 2012) will be upgraded to a journal cite after it's published (say in January 2013). The bibcode will reflect the actual year of publication, so this should raise a "check |year= value" flag. Likewise, the first two digits of |arxiv=YYMM.#### correspond to a year, while digits 3 and 4 correspond to a month (YY = 91 to 99 = 19YY, YY = 0 to 90 = 20YY). Preprints are updated, and retain their identifier through their lives, but it will mean that the value of |year= or |date= has to be equal or greater to the arxiv date. Headbomb {talk / contribs / physics / books} 01:30, 5 May 2016 (UTC)

I suppose that this could be done. Is there evidence that such a test is necessary?

—Trappist the monk (talk) 10:54, 5 May 2016 (UTC)

Citation bot used to update cite arxiv to cite journal without fixing the year (which may still be the case, but the bot's down so hard to tell at the moment). Headbomb {talk / contribs / physics / books} 21:17, 5 May 2016 (UTC)

There are some cases like arXiv:1303.7403 that are posted to the arxiv after being published, but these are minorities and should probably be manually bypassed. Headbomb {talk / contribs / physics / books} 02:26, 8 May 2016 (UTC)

Is there a fix that can be made for (86039) 1999 NC43's missing pipe maintenance indication? Looks like a false positive, but maybe my eyes are deceiving me. --Izno (talk) 12:44, 9 May 2016 (UTC)

It looks like the check is detecting "type =" in the title field as a missing pipe. That's a false positive. I don't know the best way to fix it, but I replaced "=" with "&#61;", its HTML equivalent, and the error message went away. Not very pretty. I tried {{=}}, but it didn't have any effect. If someone knows a better way, post it here and replace my workaround in the article. – Jonesey95 (talk) 13:27, 9 May 2016 (UTC)

Right, I tried {{=}} as well. --Izno (talk) 13:45, 9 May 2016 (UTC)

Yes. Because |type= is a legitimate cs1|2 parameter.

Perhaps a better fix is to wrap the '=' in <nowiki>...</nowiki>. Replacing '=' with = forces Module:Citation/CS1/COinS to percent encode each character of the html entity:

&rft.btitle=JPL+Small-Body+Database+Search+Engine%3A+spec.+type+%26%2361%3B+Q+%28SMASSII%29

whereas, using <nowiki>...</nowiki> gives this:

&rft.btitle=JPL+Small-Body+Database+Search+Engine%3A+spec.+type+%3D+Q+%28SMASSII%29

—Trappist the monk (talk) 13:50, 9 May 2016 (UTC)

@Jonesey95 and Trappist the monk: (though I know you're watching the page): I'm not sure about using nowiki's to work around this maintenance error. Users unfamiliar with the maintenance category aren't going to understand why we're seemingly adding a nowiki to around the equals sign. Thoughts? --Izno (talk) 19:51, 9 May 2016 (UTC)

I would assume that this special case could be added to the documentation as there are other special encodings discussed in the CS1 doc already. 72.43.99.130 (talk) 20:37, 9 May 2016 (UTC)

Why don't we extend the "<parameter>=((<argument>))" error message suppression concept to this (and other parameters which could possibly match parameters like chapter, quote, contribution and their variants)? It would not allow us to prevent the message from occuring proactively (as we cannot predict parameters implemented in the future), but it would be an easy to remember workaround. --Matthiaspaul (talk) 19:41, 9 May 2016 (UTC)

When I suggested double parentheses error suppression for another maintenance message (here), Editor Izno suggested that such a mechanism should not be used. At least that is what I think was the message.

Similarly, with regard to hyphenated page numbers (here), the doubled parentheses solution was not well received.

—Trappist the monk (talk) 21:14, 9 May 2016 (UTC)

I have been working my way through Category:CS1 maint: Unrecognized language and have added two new |script-title= language categories to Category:CS1 uses foreign language script and am about to add another. These categories are associated with a table of ISO 639-1 codes that has been kept in Module:Citation/CS1 in the function format_script_value(). I have decided to move the table into Module:Citation/CS1/Configuration (the sandbox) primarily because I foresee the need for other language code tables (codes for languages not supported by MediaWiki, for instance) so having all language codes in a single location makes sense to me.

'"`UNIQ--templatestyles-00000020-QINU`"'<cite id="CITEREFSagar_Desai,_Yadgir" class="citation news cs1 cs1-prop-script cs1-prop-foreign-lang-source">Sagar Desai, Yadgir. [http://kannada.oneindia.com/literature/people/2012/0308-woman-of-substance-d-roopa-moudgil-aid0038.html <bdi lang="kn" >ದಿಟ್ಟ ಪ್ರತಿಭಾವಂತ ಪೊಲೀಸ್ ಅಧಿಕಾರಿ ರೂಪಾ ಮೌದ್ಗೀಲ್</bdi>] &#91;Maudgil to transform bold and talented police officer&#93;. ''kannada.oneindia.com'' (in Kannada)<span class="reference-accessdate">. Retrieved <span class="nowrap">7 May</span> 2016</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=kannada.oneindia.com&rft.atitle=%E0%B2%A6%E0%B2%BF%E0%B2%9F%E0%B3%8D%E0%B2%9F+%E0%B2%AA%E0%B3%8D%E0%B2%B0%E0%B2%A4%E0%B2%BF%E0%B2%AD%E0%B2%BE%E0%B2%B5%E0%B2%82%E0%B2%A4+%E0%B2%AA%E0%B3%8A%E0%B2%B2%E0%B3%80%E0%B2%B8%E0%B3%8D+%E0%B2%85%E0%B2%A7%E0%B2%BF%E0%B2%95%E0%B2%BE%E0%B2%B0%E0%B2%BF+%E0%B2%B0%E0%B3%82%E0%B2%AA%E0%B2%BE+%E0%B2%AE%E0%B3%8C%E0%B2%A6%E0%B3%8D%E0%B2%97%E0%B3%80%E0%B2%B2%E0%B3%8D&rft.au=Sagar+Desai%2C+Yadgir&rft_id=http%3A%2F%2Fkannada.oneindia.com%2Fliterature%2Fpeople%2F2012%2F0308-woman-of-substance-d-roopa-moudgil-aid0038.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+16" class="Z3988"></span>

—Trappist the monk (talk) 15:35, 8 May 2016 (UTC)

Relevant to your "working your way through" rather than the technical issue noted above, I do find it a pity that informative language information, like "in Chinese with English abstract" has now been replaced by "In Chinese and English", which to me means something rather different. Is this a price worth paying for checking that the language is correctly specified? Peter coxhead (talk) 16:04, 8 May 2016 (UTC)

The problem is that |language= is a structured parameter (has been since September 2013) and has rules for what it accepts. The basic rule has always been that |language= holds the language of the source. Extra descriptors don't fit with that basic rule. The rest of the rule is that when there is more than one language, the |language= parameter value is a comma separated list of languages (or ISO 639-1 or -2 codes) recognized by MediaWiki that the module can properly categorize and format.

Your example is just one of many slightly different forms I've found that include the descriptor 'abstract':

<language> with <language> abstract (your example)

<language> (with <language> abstract)

<language> with [a|an] <language> abstract

<language> with abstract in <language>

<language> abstract in <language>

<language> (<language> abstract)

<language> <language> abstract

<language> (abstract in <language>)

(each of the above can use a comma separator after the first <language> so the list for 'abstract' is 2× as long as shown)

and there are other descriptors that can ofttimes be used in place of 'abstract' in forms similar to those listed above: available, captions, commentary, introduction, manuscript, notes, options, original, originally, partially, portions, preface, subtitles, summary, vernacular, and probably yet more that I haven't discovered.

We don't have a mechanism to specify gradations of language use in a source. Perhaps you could invent such a mechanism?

—Trappist the monk (talk) 17:54, 8 May 2016 (UTC)

|contribution=Abstract and new |contribution-lang=English? --Izno (talk) 12:45, 9 May 2016 (UTC)

Semantically this may or may not be correct. Because it may not be a contribution (different author). Perhaps, a new |abstract-lang= that requires |language=some language? Presented as "in [language], abstract in [abstract-lang]" or similar. 65.88.88.200 (talk) 15:09, 9 May 2016 (UTC)

Right, I'm tossing it at the wall. It should be a generic parameter rather than e.g. |abstract-lang= because as TTM notes, "there are other descriptors". My thought regarding contribution is that we relax the necessary constraint on |contribution= to require either a |contributor= or a |contribution-lang=, and have the module figure out how to place the statements. --Izno (talk) 15:23, 9 May 2016 (UTC)

Alternatively, |section= and |section-lang= might work--I don't know if |section= is global to all CS1 templates though. --Izno (talk) 15:23, 9 May 2016 (UTC)

|section= and |contribution= are both aliases of |chapter= so neither are global. |section= is also not a |chapter= alias when used with {{cite map}}.

—Trappist the monk (talk) 17:15, 9 May 2016 (UTC)

Are all the languages in the list put into metadata, or only the first one?

Couldn't we define a special separator character, where the evaluation stops, allowing the remainder of the text to be any free-flow text just displayed without any error checking.

Alternatively and much more flexible, but this would require conceptual changes elsewhere as well, we could allow optional parameter suffixes indicating the language of the argument of a specific parameter, something like title-en=Title, title-de=Titel, contribution1-en=Preface, contribution2-de=Vorwort, contribution-author1-en=Contributor, contribution-author2-de=Beitragender. Or we could extend the prefix notation supported by script- parameters to many other parameters as well, like in title=en:Title, title=de:Titel, contribution1=en:Preface, contribution2=de:Vorwort, contribution-author1=en:Contributor, contribution-author2=de:Beitragender.

--Matthiaspaul (talk) 19:55, 9 May 2016 (UTC)

None of the languages are made part of the COinS metadata. But, all of the languages are used to categorize the article page in any of the various subcategories of Category:CS1 properties.

—Trappist the monk (talk) 21:38, 9 May 2016 (UTC)

@Trappist: where did you find the descriptor 'abstract' please? Maybe I'm looking at the wrong module? 72.43.99.130 (talk) 20:31, 9 May 2016 (UTC)

Not in the module code. 'Abstract' and all of the other descriptors that I listed were all found in |language= parameters in any number of the various cs1|2 templates in use in article space. Those descriptors are not languages so the module adds the article to Category:CS1 maint: Unrecognized language.

—Trappist the monk (talk) 21:38, 9 May 2016 (UTC)

Well then is it only a case of finding the citations with the above incorrectly filled |language= and parsing the abstract's language into a new parameter? 72.43.99.146 (talk) 14:54, 10 May 2016 (UTC)

How about skipping the error checks for parenthesised text? This would allow |language=Chines to be flagged as an error, but accept |language=Chinese (English abstract) at the price of accepting |language=Chinese (Eglish abstract). Peter coxhead (talk) 16:26, 10 May 2016 (UTC)

This article uses the {{cite web}} template to format external links to a defunct site, which, however, is archived at archive.org. Whilst the usage of the template for this purpose is a bit unorthodox, I'd still like to point out a few oddities in the behaviour of the template and error message currently displayed: "|archive-url= is malformed: flag".

The provided parameters are as follows:

|url=http://www.harri-deutsch.de/

|dead-url=yes

|archive-url=http://web.archive.org/web/20131030225414*/http://www.harri-deutsch.de/

|archive-date=2013-10-30

That is, the timestamp is 14 digits long (indicating a date close to the last snapshot before the site went offline) but it deliberately has a "*" suffix added, so that archive.org shows the timeline allowing users to move backwards in time as well.

Issues:

• The error message indicates a "flag" error, whilst it should indicate a "wildcard" error.
• Shortening the timestamp, the error messages changes to "timestamp", but it should better still display "wildcard" (because this is the stronger error of the two and it can be fixed only by removing the wildcard, not by changing the length of the timestamp, as the error message and explanations at Category:Pages with archiveurl citation errors suggest).
• Only when the "*" is removed, it should display "timestamp" (when the length of the timestamp is invalid).
• The only error condition, which can be considered "harmful" is the "save command" error, so the link should be suppressed only when encountering this case. However, at present, the link is suppressed on all error cases, which is particularly inconvenient, as it makes it even more complicated to fix the error by simply clicking on the faulty link and selecting one of the available snapshots. (See Help talk:Citation Style 1/Archive 13#web.archive.org/save/... for a related discussion how the behaviour could easily be further improved.)
• Ideally, there would be some special syntax or parameter to mute the error message to allow "*" to be used in cases such as this one.

Fortunately, these issues appear to be easy to address by changing the order of tests and modifying the patterns sligthly. --Matthiaspaul (talk)

1. Flag error because the trailing '*' is occupying the first flag character position, is not a letter, and is not followed by another flag character and an underscore.
2. The required length of a timestamp is 14 digits; any other timestamp length is an error. In this case the error message is correct because the timestamp has the correct length so the error message should not identify it as a failure. For the purposes of this test, a wildcard error message only occurs when the timestamp is replaced with '*' (http://web.archive.org/web/*/.... There isn't any error weighting; all errors are treated the same, none is 'stronger' than another.
3. Correct.
4. I disagree. The purpose of |archive-url= is to hold the url of an archived copy of the source that supports the Wikipedia article text. Sending the reader to a search results page does not serve that purpose. Allowing Internet Archive to choose which page it displays is inappropriate. It is the editor's duty to make sure that the value assigned to |archive-url= is valid and points to a correct copy of the source that supports the Wikipedia article text.
5. Perhaps we can allow the archive url to show in preview mode (save command would never show) so that editors can pick one snapshot from a wildcard search result. I'll think on that.

—Trappist the monk (talk) 00:21, 10 May 2016 (UTC)

• Ad 1) Yes, I see why it is displaying a "flag" error, but the purpose of the error message (and related documentation) is to help editors fixing the problem. In this case, the error message is misleading as the problem is the trailing "*", not some flag. Therefore, it would be more appropriate to display a "wildcard" error. My point is that the check(s) should be refined to display the most appropriate error message.
• Ad 2) Yes, but for the purpose of helping editors fixing the error, it would be better if the template would generate "wildcard" errors not only for the special case of "/*/" (with zero-length timestamp), but also for any other case of "/<timestamp>*/". If the timestamp is 14 digits long, a pending "*" should generate a "wildcard" error, because the timestamp is fine. For timestamps of length 1 to 13, we have two error conditions, "timestamp" and "wildcard", but since apparently only one error can be shown at a time, it would be better to display the "wildcard" error first, so that "wildcard" errors would be consistently shown for all cases of "/<timestamp>*/" with timestamps of lenght 0 to 14. That's what I meant by "wildcard errors are stronger than timestamp errors". My point is that from archive.org's perspective "*" can be appended to timestamps of any length 0 to 14 and it triggers special behaviour in all such cases. So, if this behaviour is an error for us in a citation template (for normally good reasons), our "wildcard" error message should be shown in all such cases as well instead of only for the special case of a zero-length timestamp. From archive.org's perspective, there is nothing special about the zero-length case, so it shouldn't for us as well.
• Ad 4) Yes, (as per our prior discussion about this) I agree with you that wildcards should not be allowed in a reference. However, our citation templates are used for other purposes as well, for example to format work lists, "further reading" sections or - rarely - "external links" sections, where they are not used as references. In some of these cases, it might make sense to allow wildcards (it definitely does in this particular case). So, we could either strictly rule out the usage of these templates for such purposes, or we could be happy that they are useful for other related formatting purposes as well and offer limited support by providing some means to override the occasional error messages in these cases.
• Ad 5) Yes.

--Matthiaspaul (talk) 10:13, 10 May 2016 (UTC)

1. Perhaps a reread of the error message help text is in order. That text identifies the location of the error and the requirements for a properly formed flag:

   flag – the flag portion of the url path (if present; new form urls only) is not 2 lowercase letters followed by an underscore: 'id_'

If the character appended to the timestamp is a '+' instead of a '*', what then? The flag error message is perfectly adequate for identifying both cases.

2. I'm not convinced. We have stated that the requirement for timestamp is 14 digits; anything more or less is an error. A flag is two lowercase letters followed by an underscore; anything different is an error. Perhaps we should get rid of the wildcard error message since '/*/' is a zero-length timestamp. By doing so we avoid the special case that is wildcard detection.
4. Wildcards are the equivalent of a search result. WP:ELNO item 9 discourages search results. If it is really necessary to link to a wildcard archive listing, then it is not necessary to use cs1|2; for this example (were it appropriate though I think it is not) it would be better to make a simple external wikilink and not use cs1|2 at all.

—Trappist the monk (talk) 13:37, 10 May 2016 (UTC)

In the module sandbox I have disabled the wildcard test and added preview detection:

{{cite web/new |title=Title |url=//example.com |archive-url=https://web.archive.org/web/*///example.com |archive-date=2016-02-06}}

"Title". {{cite web}}: |archive-url= is malformed: timestamp (help)

Edit this section and then click the show preview button:

{{cite web/new |title=harri deutsch electronic science (hades) |url=http://www.harri-deutsch.de/ |dead-url=yes |archive-url=http://web.archive.org/web/20131030225414*/http://www.harri-deutsch.de/ |archive-date=2013-10-30}}

"harri deutsch electronic science (hades)". {{cite web}}: |archive-url= is malformed: flag (help); Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 14:17, 10 May 2016 (UTC)

Regarding disabling the wildcard test. Not a good idea IMHO. See below.

Regarding preview. Yes, that's much better already. We could make it even more convenient for editors to select the correct snapshot, if the template would automatically append a "*" to an incomplete timestamp in preview, if it does not contain a "*" already. Thereby, we'd force archive.org to display the timeline for the editor to choose from instead of letting archive.org select a nearby snapshot automatically (with sometimes "unexcepted" effects and no easy means to select another). Compare:

http://web.archive.org/web/200506/http://www.harri-deutsch.de/

http://web.archive.org/web/200506*/http://www.harri-deutsch.de/

Ad 1) For archive.org, wildcards and flags are separate features. I haven't tried but I assume they can even occur at the same time.

It would be enough for us to just display "invalid parameter", but if we go the extra mile and display more specific error message for their features, why don't we model the scope of our allowed ranges after their allowed parameter ranges as well? To answer the question, if we have a (14-digit) timestamp and append a '*', this should be indicated as "wildcard" error, but if we append a "+" instead (which has no special meaning for archive.org), this could be counted as a "flag" error (or just as "invalid character").

Ad 2) IMO we should instead improve the detection for "wildcard" errors, so that they are displayed whenever a "*" is appended regardless of the length of the timestamp.

--Matthiaspaul (talk) 19:36, 10 May 2016 (UTC)

I've modified the test. If the timestamp is incomplete and has a '*' suffix then the archive url is not modified for preview mode. If the timestamp is incomplate but does not have a '*' suffix then the archive url is modified for preview mode so that the timestamp is no longer than six digits (yyyymm). This, I think, give the best opportunity of locating a suitable snapshot. Incomplete with '*':

{{cite web/new |title=harri deutsch electronic science (hades) |url=http://www.harri-deutsch.de/ |dead-url=yes |archive-url=http://web.archive.org/web/2013103022541*/http://www.harri-deutsch.de/ |archive-date=2013-10-30}}

"harri deutsch electronic science (hades)". {{cite web}}: |archive-url= is malformed: timestamp (help); Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

Incomplete without '*':

{{cite web/new |title=harri deutsch electronic science (hades) |url=http://www.harri-deutsch.de/ |dead-url=yes |archive-url=http://web.archive.org/web/2013103022541/http://www.harri-deutsch.de/ |archive-date=2013-10-30}}

"harri deutsch electronic science (hades)". {{cite web}}: |archive-url= is malformed: timestamp (help); Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

I guess we will just have to disagree about wildcards and flags. It seems pointless to continue that discussion since neither of us is convincing the other. Wildcards and flags together in the url are incompatible:

http://web.archive.org/web/200506*id_/http://www.harri-deutsch.de/

http://web.archive.org/web/200506id_*/http://www.harri-deutsch.de/

—Trappist the monk (talk) 11:44, 11 May 2016 (UTC)