Help talk:Citation Style 1/Archive 19

This is an archive of past discussions. 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.

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

Iṣiloğlu M:

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

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

Isiloğlu M:

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

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

((Iṣiloğlu M)):

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

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

  ~ 

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

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

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

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

is not currently supported.

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

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

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

dgaf

)  13:25, 11 June 2016 (UTC)

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

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

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

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

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

Ref on the En version of article:

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

Its output shows the edition as expected:

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

ISBN 0-8061-0843-6

.

Ref on the Vi version of same article:

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

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

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

ISBN 0806108436

.

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

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

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

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

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

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

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

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

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

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

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

|contributor-givenn=

|contributorn-given=

|contributor-surnamen=

|contributorn-surname=

|translator-givenn=

|translatorn-given=

|translator-surnamen=

|translatorn-surname=

and these duplicates which I have removed:

|contributorn-last=

|translatorn-last=

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

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

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

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

Can someone add |display-translators=etal to complement |display-authors=etal & |display-editors=etal?   ~ 

dgaf

)  21:12, 8 June 2016 (UTC)

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

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

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

dgaf

)  22:26, 8 June 2016 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Also, not everyone has webspace available to upload files.

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

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

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

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

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

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

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

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

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

The problem here is that access dates and archive dates involve different sources. When using |archive-date= it is implied that you are no longer citing the original source, but a 3rd-party copy. This may have

WP:RS and other issues of its own. 72.43.99.138 (talk

) 16:46, 5 June 2016 (UTC)

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

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

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

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

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

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

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

Combine access and archive date statements when identical

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

|accessdate=June 5, 2016 and

|archivedate=June 5, 2016 →

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

czar 16:38, 7 June 2016 (UTC)

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

{{#time:U|15 fevriye 2015}} → Error: Invalid time.

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

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

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

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

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

Have you considered using css to hide access dates?

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

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

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

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

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

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

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

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

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

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

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

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

You can see this in the debug console with these:

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

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

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

Repeat using the .+ or .* patterns

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

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

I'm just wondering, is this is a bug or a feature?   ~ 

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

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

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

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

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

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

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

And the accessdate suppressed.

books

} 20:23, 14 June 2016 (UTC)

Fixed in the sandbox.

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

There is an ongoing discussion at

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

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

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

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

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

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

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

→

16:49, 18 June 2016 (UTC)

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

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

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

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

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

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

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

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

If the cs1|2 title parameter looks like this:

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

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

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

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

&rft.btitle=MATH+RENDER+ERROR

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

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

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

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

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

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

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

MediaWiki does this first:

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

which replaces the |title= value with:

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

which then gets handed to Module:Citation/CS1

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

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

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

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

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

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

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

As you can see, it isn't pretty. If ever either of those two templates ({{

'}} and {{'s

}}) is changed for any reason, the code breaks.

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

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

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

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

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

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

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

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

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

Opinions?

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

Is this correct

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|url-state= was suggested in this conversation.

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

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

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