Jump to content

Help talk:Citation Style 1/Archive 20

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15←Archive 18Archive 19Archive 20Archive 21Archive 22→Archive 25

Update to the live CS1 module weekend of 4–5 June 2016

I propose to update the live modules on the weekend of 4–5 June 2016. The changes are:

to Module:Citation/CS1
  1. allow hyphens in date ranges; discussion
  2. fixed cs2 translator static text; discussion
  3. moved |script-title= langauage-code table to Module:Citation/CS1/Configuration; discussion
  4. fixed Vancouver validation bug; discussion
  5. fixed cs2 page number rendering error; discussion
  6. support Vancouver generational suffixes; discussion
  7. CITEREF bug fix; discussion
to Module:Citation/CS1/Configuration
  1. allow hyphens in date ranges
  2. bibcode error detection; discussion
  3. add translated static text to messages table
  4. moved |script-title= language-code table from Module:Citation/CS1
to Module:Citation/CS1/Date validation
  1. allow hyphens in date ranges
to Module:Citation/CS1/Identifiers
  1. bibcode error detection

—Trappist the monk (talk) 19:34, 29 May 2016 (UTC)

need to refine bibcode checking

The bibcode check possibly needs to be updated to handle cases like Bibcode:1953QB901.W495...... Specifically, tests for characters 6-9 according to Help:CS1_errors#Check_.7Cbibcode.3D_.3Cmessage.3E. Headbomb {talk / contribs / physics / books} 16:02, 6 June 2016 (UTC)

These seem to be older/legacy bibcodes. I'll try to investigate if there's a way to detect legacy codes and ignore those specific instances, or maybe I'll just do an AWB run to update them. Headbomb {talk / contribs / physics / books} 16:05, 6 June 2016 (UTC)
That bibcode redirects to an updated one that does not cause an error message for me: Bibcode:1953GCRV..C......0W It looks like we should replace the invalid(?) bibcode with what looks like its replacement, maybe. – Jonesey95 (talk) 16:34, 6 June 2016 (UTC)
I've updated that specific one, which was plastered all over the place and reduced errors by about ~100, but there's also a similar Bibcode:1971GCVS3.C......0K which is both valid and up-to-date, which does produce an error. Headbomb {talk / contribs / physics / books} 17:14, 6 June 2016 (UTC)
The test should probably be revised. This is a relatively recent bibcode that does not redirect:
Title. Bibcode:2008hsf2.book..735N.
It fails because of the '2' in position 8; essentially the same reason that 1953QB901.W495..... fails.
—Trappist the monk (talk) 16:46, 6 June 2016 (UTC)
Yes, I'm seeing the same thing in Lupus (constellation): Preibisch, T.; Mamajek, E. (2008). "The Nearest OB Association: Scorpius-Centaurus (Sco OB2)". Handbook of Star-Forming Regions. 2. arXiv:0809.0407. Bibcode:2008hsf2.book..235P.. It looks like a number is allowable in the journal name. I see this publication in the list of conferences (do a Find for "hsf2"). There are journals named "sp98" and "sp1", so a number appears to be permissible in characters 7 and 8, at a minimum. – Jonesey95 (talk) 16:51, 6 June 2016 (UTC)

This insource search finds digits in position 7 but none are found in position 6.

I've made a subsection of this topic.

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

Alright, I've updated a bunch of those. I've discovered two things:
  1. Basically, anything that starts with [YYYY]QB[###].[L] is a call number reference, should be updated to the modern bibcode. Sometimes these links work, but they quite often don't. In any case, they are outdated and should be updated.
  2. Characters 7-8 can be digits, but only if characters 9-13 are .book, .coll, .conf, or .proc

Headbomb {talk / contribs / physics / books} 17:57, 6 June 2016 (UTC)

The following bibcode is apparently correct but is being rejected: Bibcode:1971GCVS3.C......0K Lithopsian (talk) 19:42, 6 June 2016 (UTC)

Yeah, I mentioned that one above. Can't figure which test(s) it's failing, so maybe it's an issue with the validation code itself. Headbomb {talk / contribs / physics / books} 19:44, 6 June 2016 (UTC)
Sorry, missed that. Isn't the test for character 9 being a letter or a dot? Character 9 is a number here. Lithopsian (talk) 19:49, 6 June 2016 (UTC)
Right you are. I triple checked it, but I guess I missed that somehow. It's a shame we don't have a list of the catalogue codes used by the ADSABS, but I could send them an email later tonight to see what they have to say. If it's only this code that has that, it might be better to simply create an exception for this one. Headbomb {talk / contribs / physics / books} 19:56, 6 June 2016 (UTC)
This insource search shows that there are others.
—Trappist the monk (talk) 20:38, 6 June 2016 (UTC)
So basically, 1971GCVS3.C......0K and those that start with YYYYJPhy[1-4]. Headbomb {talk / contribs / physics / books} 20:51, 6 June 2016 (UTC)
Headbomb, the lists of valid codes are here (linked in the page that is linked in the footnote when you click on help after the bibcode error). I expect that there are some missing, but there are thousands on those lists, so we should be able to use those lists to help us. That's how I found "sp98" above. You can find "JPhy1" in the list of journals, which makes a number in position 9 valid. – Jonesey95 (talk) 22:51, 6 June 2016 (UTC)
That's journals and proceedings, but don't include catalogues. Headbomb {talk / contribs / physics / books} 22:56, 6 June 2016 (UTC)

I've cleaned the whole category (~roughly 300 pages since this morning). The remaining incidences, as of writing, are where the validation code needs to be update to recognize legit cases. Headbomb {talk / contribs / physics / books} 23:04, 6 June 2016 (UTC)

I have adjusted the sandbox code (caveat: I am not a lua programmer) to see if I could allow digits in positions 7 through 9. I imagine that we could get more complicated, but it might backfire on us. I'd rather miss a few than have a bunch of false positives.
Cite journal comparison
Wikitext {{cite journal|bibcode=1971GCVS3.C......0K|journal=Journal|title=Title}}
Live "Title". Journal. Bibcode:1971GCVS3.C......0K.
Sandbox "Title". Journal. Bibcode:1971GCVS3.C......0K.
Cite journal comparison
Wikitext {{cite journal|bibcode=2008hsf2.book..235P|journal=Journal|title=Title}}
Live "Title". Journal. Bibcode:2008hsf2.book..235P.
Sandbox "Title". Journal. Bibcode:2008hsf2.book..235P.
Cite journal comparison
Wikitext {{cite journal|bibcode=1953QB901.W495.....|journal=Journal|title=Title}}
Live "Title". Journal. Bibcode:1953QB901.W495.....
Sandbox "Title". Journal. Bibcode:1953QB901.W495.....
Comments? The above is the extent of my testing. I tried to minimize the changes to avoid unintended consequences. – Jonesey95 (talk) 23:05, 6 June 2016 (UTC)
Looks to me like you did the right thing. I tweaked the documentation.
—Trappist the monk (talk) 23:34, 6 June 2016 (UTC)
Yep, thanks. Copy/paste/proofread mistake in my documentation change. – Jonesey95 (talk) 23:37, 6 June 2016 (UTC)

I'm getting a "check bibcode" error for the valid bibcode "Bibcode:1992JPhy1...2.2221N":

Is this fixed in the sandbox or an ongoing problem? —David Eppstein (talk) 18:38, 9 June 2016 (UTC)

Yes, fixed in the sandbox. You can always test the sandbox version of a cs1|2 template by writing the template name with /new for example: {{cite journal/new}} (caveat: this testing functionality is not safe for use in article space).
—Trappist the monk (talk) 18:45, 9 June 2016 (UTC)

Port validation to {{Bibcode}} and CS1 templates?

Would it be possible to port this bibcode validation to {{Bibcode}} and CS2 templates? Headbomb {talk / contribs / physics / books} 00:00, 23 June 2016 (UTC)

Which is it that you want? cs1 or cs2? Doesn't matter really, if the checking is part of cs1, it is part of cs2:
{{citation |title=Title |bibcode=1953QB901.W495..... |journal=Journal}}
"Title", Journal, Bibcode:1953QB901.W495.....
Yes, it is possible to add the checking to {{bibcode}}
—Trappist the monk (talk) 00:36, 23 June 2016 (UTC)
Follow up question then. Could you/would you do it? I speak template natively, my LUA skills are about as great as my knowledge of norse poetry. Headbomb {talk / contribs / physics / books} 14:54, 23 June 2016 (UTC)
Template talk:bibcode.
—Trappist the monk (talk) 00:45, 24 June 2016 (UTC)

Citing image captions

I asked this question elsewhere, and was directed here. I created an article on Amy Bess Miller fairly recently, and that article includes her bibliography. However, there is another work currently not listed to which Miller contributed. The Shaker Image Second and Annotated Edition includes annotations by Magda Gabor-Hotchkiss, with captions written by Amy Bess Miller and John Harlow Ott. How would I credit this in a bibliography? For the introduction that Miller wrote for the fascimile reprint of The gardener's manual, I just used the "cite book" template and entered "Introduction" into the chapter parameter. But this type of thing I don't think would work in this case. So what would be the solution?--3family6 (Talk to me | See what I have done) 21:42, 22 June 2016 (UTC)

perhaps this?
{{Cite book |title=The Shaker Image Second and Annotated Edition |last=Pearson |first=Elmer R. |first2=Julia |last2=Neal |contributor-last=Miller |contributor-first=Amy Bess |contributor-mask=2 |contribution=Captions |publisher=Hancock Shaker Village |date=1995}}
—— (1995). "Captions". The Shaker Image Second and Annotated Edition. By Pearson, Elmer R.; Neal, Julia. Hancock Shaker Village.
—Trappist the monk (talk) 21:58, 22 June 2016 (UTC)
I'd considered that. That is probably the best solution. Thank you,--3family6 (Talk to me | See what I have done) 03:35, 24 June 2016 (UTC)

|vauthors= and corporate names

Recently a couple of articles turned up in Category:CS1 errors: Vancouver style that were sort of like the examples below. Each had a corporate name; one had a comma-separated list of department names associated with NIH and the other included something in parentheses (both have been 'fixed' by someone else so I can't use them as examples here). The first one failed because, as a first step, the module separates the |vauthors= name-list at the commas separating the names. For corporate names, the module expects the name to be wrapped in matching doubled parentheses. For |vauthors=White AB, Brown CD, ((Alpha, Bravo, Charlie)) the result after parsing was:

  • |last1=White
  • |first1=AB
  • |last2=Brown
  • |first2=CD
  • |last3=((Alpha – these doubled parentheses are made part of the metadata
  • |last4=Bravo
  • |last5=Charlie)) – these doubled parentheses are made part of the metadata

This is fixed in the sandbox:

Cite book comparison
Wikitext {{cite book|title=Title|vauthors=White AB, Brown CD, ((Alpha, Bravo, Charlie))}}
Live White AB, Brown CD, Alpha, Bravo, Charlie. Title.
Sandbox White AB, Brown CD, Alpha, Bravo, Charlie. Title.

'"`UNIQ--templatestyles-00000023-QINU`"'<cite id="CITEREFWhiteBrownAlpha,_Bravo,_Charlie" class="citation book cs1">White AB, Brown CD, Alpha, Bravo, Charlie. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=White&rft.aufirst=AB&rft.au=Brown%2C+CD&rft.au=Alpha%2C+Bravo%2C+Charlie&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+20" class="Z3988"></span>

In the other case, the parenthetical part of the corporate name caused an error because the single parentheses are not allowed in Vancouver names. But, corporate names are not Vancouver names so the module should not have been doing that test. This too, has been fixed in the sandbox:

Cite book comparison
Wikitext {{cite book|title=Title|vauthors=White AB, Brown CD, ((Alpha Bravo Charlie (ABC)))}}
Live White AB, Brown CD, Alpha Bravo Charlie (ABC). Title.
Sandbox White AB, Brown CD, Alpha Bravo Charlie (ABC). Title.

—Trappist the monk (talk) 22:57, 24 June 2016 (UTC)

Parameter order

I didn't see this in the archives, so please point me in the right direction if this has been answered. Is there a logic behind the default parameter order at {{cite web}}, {{cite news}}, etc.? Is it local consensus? I try to put the parameters in the order in which they display, personally, and I know that their order is not standardized on the whole (and I am not suggesting that it should), but in terms of the default shown, I was wondering about the logic. czar 04:31, 22 June 2016 (UTC)

I wasn't aware that there was a "default" order. The blank templates that you can copypaste include a non-exhaustive selection of available parameters; mostly, these put authors info first, identifiers (like ISBN OCLC etc.) last. everything else in between those. But since the citation templates use named parameters exclusively (there are no positional parameters), the order in which you give them is immaterial - no order is more "correct" than another. The only requirement is that you don't use the same named parameter more than once - that includes its aliases, so {{cite book |last=Smith |first=Fred |author=Joe Public |title=Our book of facts }} would be an error. --Redrose64 (talk) 08:09, 22 June 2016 (UTC)
Since the order makes no difference to the software, I think it would be best (if there is to be a default order, i.e. the one you get by copying and pasting a blank template) if the ordering is useful to human editors reading the code. So I think the parameters that are more readable for identifying the citation (its title or authors) would be better placed earlier, and other more machine-only data (like urls) later. The custom software that I use for many citations puts authors first, then alphabetical for everything else, rather than trying to find a logical ordering for everything. —David Eppstein (talk) 08:24, 22 June 2016 (UTC)
My only 2 cents on this is that "first last" makes more sense than "last first", since there are more sources that show author as "first last". Thus you would code it the way you see it, more often than not, rather than the way readers will see it. ―Mandruss ☎ 10:28, 22 June 2016 (UTC)
In a bibliographic listing, alpha-ordered by lead author's/editor's surname, write the template {{cite ... |last=... . Doing that can make life easier for follow-on editors.
—Trappist the monk (talk) 11:32, 22 June 2016 (UTC)
I have found both first/last and last/first name ordering have their advantages; I don't see that either warrants preference in all cases. To the extent that a particular citation model is recommended it should be clear that either name ordering is fine, provided it is consistent within the citation. I don't think we should require such consistency within an article. ~ J. Johnson (JJ) (talk) 20:36, 24 June 2016 (UTC)
Being a bit gnomeish, if you are sorting out a list that is out of order (not uncommon), then it is much easier if |last= comes first in the list. The only exception to this is where there is no author (corporate authorship or lookup to specialised databases such as listed buildings) when the publisher or listing organisation needs to be first. Martin of Sheffield (talk) 21:37, 24 June 2016 (UTC)
It really depends on the context. Assuming vertical format (one author per line) and some uniformity of spacing I found that something like the following (making allowances for proportional fonts)
  |first1= Tom A.     |last1= Jones
  |first2= Robert C. |last2= Brown
is very readable. Though many editors would object to the extra spacing. Of course, when you get to
  |first3= John Jacobjingleheimer |last3= Smith
the pattern is bit unwieldy. But for the many cases where only the initials (and last name) is used, this works well. And when the authors' names copied in are in first/last order it is a bit of work to invert them. Anyway, like I said before, both arrangements have their advantages. (And disadvantages.) I think this is less important than (e.g.) having everything closed-up (no spaces) except for the space before the vertical bar and the space after the equals sign. ~ J. Johnson (JJ) (talk) 22:08, 26 June 2016 (UTC)
Well we are certainly going to disagree here! When working on a bibliography I enter it at one parameter per line, two spaces to the left of the pipe one between pipe and parameter name and spaces surrounding the "=" sign. The first line will be an asterisk and the template name, the last just the closing braces. Obviously in-line citations aren't spaced out in the same way, but for a list it makes it so much more readable than everything condensed into a single wrapping string. Martin of Sheffield (talk) 22:21, 26 June 2016 (UTC)
"So much more readable" in your opinion, but not in mine. That's the problem with citations: editors have strong opinions and there's absolutely no consensus. WP:CITEVAR is interpreted to protect even minor variations. Result: endless back-and-forth changing of formatting. Sigh... Peter coxhead (talk) 09:40, 27 June 2016 (UTC)

Recently, one bot user and admin at the same time on sr.wiki wanted even to block me as I insisted on "my" parameter order that I consider logical (it is, for example, {{cite book |url= |title= |language= |last1= |first1= |last2= |first2= |publisher= |isbn= |lccn= |volume= |issue= |pages= |date= |accessdate= |quote= |archiveurl= |archivedate= |deadurl=}}). Stated reason was something like "bot unifies citation templates so |pages= has to be at the end [nonsense], near }}" etc. This could work if the bot user placed it at the end and then move it back on the initial position; but the second does not happen...

Can editor frame or whatever (e.g. after saving the wiki code) automatically reorder all parameters to some default order, and to make them like |parameter1=content |parameter2=content style; equally spaced, with parameter name and content right next to the = sign [no spaces] so it is clear on all Wikipedias that one format is used and such conflicts generally don't happen?

I wonder also something else: Is parameter order important for Lua time/memory usage? I think of some scanning-and-checking-like process [if it even exists, I do not understand the exact process of forming and displaying a single citation/reference] that goes slower/faster when taking into account order of some functions in Lua modules and order of parameters in some citation template.--Obsuser (talk) 18:12, 23 June 2016 (UTC)

The policies, guidelines and other conventions of the Serbian Wikipedia do not apply here and vice versa. If you are in breach of their rules for something that you did on that wikpedia, there's nothing that we can (or should) do about it here. --Redrose64 (talk) 18:37, 23 June 2016 (UTC)
I don't think that parameter order markedly improves cs1|2 performance.
—Trappist the monk (talk) 19:03, 23 June 2016 (UTC)

tracking use of |authors= and |editors=

I have tweaked the sandbox so that templates that use either of |authors= or |editors= (the plural versions only). Use of these parameters is discouraged because they don't contribute to the citation's metadata (actually no 'editor' parameter contributes but all of the 'author' parameters do except |authors=).

For the time being, the aliases of |authors= (|people=, |host=, |credits=) are excluded from categorization because those parameters tend to bring with them additional baggage (|people=Jo Bloe (Director), Somebody Else (Producer) ...) which we should think about as a separate topic.

{{cite book/new |title=Title |authors=AB Black, CD Brown, EF White}}

Title. {{cite book}}: Unknown parameter |authors= ignored (help)

{{cite book/new |title=Title |people=AB Black, CD Brown, EF White}}

Title. {{cite book}}: Unknown parameter |people= ignored (help)

{{cite book/new |title=Title |editors=AB Black, CD Brown, EF White}}

Title. {{cite book}}: Unknown parameter |editors= ignored (|editor= suggested) (help)

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

Hmm. If I read the above correctly, there is no metadata difference between using |editors= and |editor=. Is that right? If so, when people start to modify articles that are showing this message, and then other editors complain, what is the rationale to support the first modification (from editors= to editorn=)? I'm really just asking; I have no dog in this fight, but I suspect that there will be a fight, because people on WP love to fight about minutiae like this. – Jonesey95 (talk) 16:27, 28 June 2016 (UTC)
I was under the impression that the |editor= family of parameters (and, more recently, |translator=) populated the metadata. I support including them in the metadata.   ~ Tom.Reding (talk ⋅dgaf)  17:00, 28 June 2016 (UTC)

(edit conflict)

You read it correctly. I chose to include |editors= for the sake of consistency. If we prefer the use of multiple |authorn= and |lastn= / |firstn= parameters over the use of a single |authors= parameter then, for the sake of consistent documentation and usage, we should have the same preference for |editorn= and |editor-lastn= / |editor-firstn= over |editors=, shouldn't we? It was for this reason that we did not create |translators= and |contributors=.
There are no keywords for editors, translators, or contributors (authors of intro, forewords, etc) in the current incarnation of the COinS standard. If ever such support is added, it is best that we have already minimized the number of metadata keywords that will be corrupt or unavailable.
—Trappist the monk (talk) 17:11, 28 June 2016 (UTC)

Archived from the original on...

This text or similar that points to the archived version (either on word "Archived" or "original", depending on the |deadurl= value) sometimes is not true because archive version must not have identical URL at the end as the original URL (i.e. word "original" in "... from the original..." is not always applicable).

Example is when website changes design and url format so page is still available in similar form but has different URL (and possibly some content is missing/extra). Then the most information is preserved if user changes parameter |url= so it is not broken anymore and adds |archiveurl=, |archivedate= and |deadurl=no with old archived URL (if he/she does not have time to / does not want to check source in the original URL whether it is still a valid Wikipedia reference or not, or does not want to archive that new URL etc.).

I think other form for this text can be figured out so implication that we are talking about "real original" does not exist but functionality is still preserved. However, I don't have any ideas for better formulation. Raw example (notice where are particular URLs):

  • {{cite web |url=http://au.gamespot.com/news/take-two-has-extensive-pipeline-of-unannounced-titles-in-development-6404968 |title=Take-Two has 'extensive pipeline' of unannounced titles in development |last=Makuch |first=Eddie |publisher=GameSpot |date=7 March 2013 |accessdate=7 April 2013}} →
Makuch, Eddie (7 March 2013). "Take-Two has 'extensive pipeline' of unannounced titles in development". GameSpot. Retrieved 7 April 2013.
  • {{cite web |url=http://www.gamespot.com/articles/take-two-has-extensive-pipeline-of-unannounced-titles-in-development/1100-6404968/ |title=Take-Two has 'extensive pipeline' of unannounced titles in development |last=Makuch |first=Eddie |publisher=GameSpot |date=7 March 2013 |accessdate=7 April 2013 |archiveurl=https://web.archive.org/web/20130511035649/http://au.gamespot.com/news/take-two-has-extensive-pipeline-of-unannounced-titles-in-development-6404968 |archivedate=11 May 2013 |deadurl=no}} →
Makuch, Eddie (7 March 2013). "Take-Two has 'extensive pipeline' of unannounced titles in development". GameSpot. Archived from the original on 11 May 2013. Retrieved 7 April 2013. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)

There might be other examples too when "original" does not fit but cannot remember now... --Obsuser (talk) 09:23, 28 June 2016 (UTC)

If I understand you correctly, this is a problem with the url metadata, not the source: the original and archive copy have different metadata (site, subpage, item identifier etc.) However, this does not affect the verifiability of the citation: the archive matches the original word for word. It also seems there is no material change in reliability, since this is the same type of source (and seemingly the same publisher). As far as Wikipedia policies/guidelines are concerned, the url metadata difference seems to be a non-issue. The citation contributor accessed the original at a documented date, and a true archived copy at another documented date. I think that this is sufficient for our purposes. 72.43.99.138 (talk) 18:17, 28 June 2016 (UTC)

kerning for “” and ‘’

It won't show in the comparison below but note the quote marks used in |title=UrFU scientist was awarded the title “Professor of the Russian Academy of Sciences”. When the template has typewriter single and double quote marks, the module adds kerning to separate them from quote marks that it adds as part of title formatting. It doesn't understand “” and ‘’. But the sandbox now does:

Cite web comparison
Wikitext {{cite web|title=UrFU scientist was awarded the title “Professor of the Russian Academy of Sciences”|url=http://urfu.ru/en/news/news/14859/}}
Live "UrFU scientist was awarded the title "Professor of the Russian Academy of Sciences"".
Sandbox "UrFU scientist was awarded the title "Professor of the Russian Academy of Sciences"".

—Trappist the monk (talk) 16:45, 25 June 2016 (UTC)

These shouldn't be used, see MOS:QUOTEMARKS. --Redrose64 (talk) 22:05, 25 June 2016 (UTC)
Aye, but that prohibition has never stopped editors from using them in the past. How would you have us deal with these cases?
—Trappist the monk (talk) 22:23, 25 June 2016 (UTC)
@Trappist the monk: do my eyes deceive me, or does the sandboxed version uncurl the typographer's quotes in the final output? If so, this means it renders the final result to comply with with the MOS section Redrose64 mentions. In other words, win-win all around. Imzadi 1979 → 00:23, 26 June 2016 (UTC)
For quoted parameters, |title= in {{cite web}}, |chapter= in {{cite book}}, the module calls kern_quotes(). The first thing that the function does is replace any and all occurrences of “” and ‘’ with " and '. It then does it's usual kerning with those characters if necessary. So, even if kerning is not necessary, there are no typographer's quotes in the output:
{{cite book/new |chapter=Don’t do this |title=Things we shouldn't do}}
"Don't do this". Things we shouldn’t do.
As you can see, the 'fix' only applies to quoted titles.
—Trappist the monk (talk) 01:35, 26 June 2016 (UTC)
There are other, similar characters that are used as apostrophes and quotation marks. I come across them occasionally when editing citations. They look to me like copy-paste text from web sites. We should probably include them in our processing of these marks. I'll paste them here if I can find some. – Jonesey95 (talk) 16:31, 28 June 2016 (UTC)
Like those at quotation mark?
—Trappist the monk (talk) 17:14, 28 June 2016 (UTC)
Yes, I have seen and fixed almost all of the characters listed in the Unicode table in that article. They mostly appear to be copy-pasted or inserted by a citation-filling tool. – Jonesey95 (talk) 21:38, 28 June 2016 (UTC)

archive url checks and preview mode

There is a discussion at WP:VPT that may change how Module:Citation/CS1 handles malformed Internet Archive |archive-url= values. Currently, when these values are malformed, the module renders the citation without a link to the archive but with an error message. When the page is rendered in preview mode, the module modifies the malformed archive url so that it links to what should be the most relevant calendar directory. To know if the page is being rendered in preview mode, the module looks at the value of {{REVISIONID}} (has no value in preview mode). Apparently this is a bad thing.

In the current live module, {{REVISIONID}} is queried for every cs1|2 template regardless of need. As an experiment, I've tweaked the sandbox so that the magic word is only queried when |archive-url= has a malformed IA url:

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)

Save command:

{{cite web/new |title=example |url=http://example.com/ |archive-url=http://web.archive.org/save/http://example.com/ |archive-date=2013-10-30}}
"example". {{cite web}}: |archive-url= is malformed: save command (help)

It remains to be seen whether this change shall be kept

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

Making that change should be very helpful. You might spot the result in https://performance.wikimedia.org/ (save timing). Aaron Schulz 11:40, 18 June 2016 (UTC)
How often does the Sandbox get merged into the main module? It would be nice to make this change sooner rather than later. I still see waves of page saves effected by the vary-revision flag in the site logs. I eliminate one of the two excess parses needed on page save, but there is only so much I can do server side. Aaron Schulz 22:55, 21 June 2016 (UTC)
Jargon is ok as long as we all understand it. I have no idea what waves of page saves effected by the vary-revision flag in the site logs means.
Typically bimonthly; we did it in February, April, and first week of June this year.
At the WP:VPT conversation I asked you this:
What happens if a module that needs to know about preview mode got the value of REVISIONID passed to it in the {{#invoke:Module|function|{{REVISIONID}}}}? Is this still 'bad'?
You ignored those questions. Can I have answers?
What is the status of the patch proposing a magic word to expose preview mode? What does 'exposing preview mode' actually mean? What is the magic word? What does it return? When can I expect to have it available to me?
—Trappist the monk (talk) 23:23, 21 June 2016 (UTC)
To make saves snappy, whenever we think the user is about to submit an edit (because s/he has started typing an edit summary, for example), we send it to our servers so we can start processing it. We try to do all the work except actually save the edit to the database. If the user does not end up saving the edit or if the user goes back and makes additional changes, we just throw away whatever we computed. But if the user saves the edit, then often times a lot of the work is already done and all we have to do is commit it to the database. Whenever the REVISIONID magic word is used, this whole mechanism is basically subverted, because we can't reliable know in advance what the revision ID is going to be before we save it to the database. CS1 is widely used and it *always* uses REVISIONID, which makes saving any page that uses it slower than it needs to be. You could improve the situation a lot if you only check REVISIONID if you know you're going to need it (because you definitely detected some issue you want to flag to the user). You could do this by applying the diff I put up here. It does not change the functionality of this module at all. --Ori Livneh (talk) 00:24, 22 June 2016 (UTC) (WMF, but editor too :))
Thank you. Didn't know about the predicting part.
Yep, I know that cs1 always uses REVISIONID; that's what this conversation is all about, ne?. At the top of this discussion I wrote:
I've tweaked the sandbox so that the magic word is only queried when |archive-url= has a malformed IA url
which change you can see in Module:Citation/CS1/sandbox at archive_url_check(). Because this is the only place where we want to know if we're in preview, the change I made works as you can see if you preview this discussion.
I would much prefer to have a Scributo function or environmental variable to query to learn the rendering mode. But, since the only tool available is a hammer, it is what must be used to insert that screw.
—Trappist the monk (talk) 01:08, 22 June 2016 (UTC)
Looks good to me. Thanks a lot. (Though note you kept "local Preview_mode = false;", even though the variable is no longer in use.) --Ori Livneh (talk) 01:56, 22 June 2016 (UTC)
Any use of REVISIONID has the same problem, whether it is an argument to the #invoke call or not. Aaron Schulz 02:31, 22 June 2016 (UTC)
Thank you. And the answers to the other questions that I asked you?
—Trappist the monk (talk) 02:51, 22 June 2016 (UTC)
The PREVIEWMODE magic word patch is unlikely to be deployed, since most discussion on it gravitated towards instead exposing a Lua method to add page save warnings. This was merged, but the warnings don't have anything to indicated the location of the page, which another developer was interested in working on. I don't know when anything will come of that, though it probably won't be soon. Aaron Schulz 08:54, 22 June 2016 (UTC)
If transaction prefetching is truly affected negatively by this then as you remarked at VPT, the use of REVISIONID should be disabled serverside. On the other hand, prefetching always carries risks, and REVISIONID seems too useful a marker not to be used by module writers when there is need. I am ignorant of how transcation commit/rollback happens in MW database(s). But I wonder if REVISIONID could be pre-stuffed with a dummy value, to be discarded when the transaction is actually commited. 65.88.88.127 (talk) 14:49, 22 June 2016 (UTC)


@Trappist the monk:, any chance you could merge this change to the canonical module? We're eager to see the impact on page save perf. --Ori Livneh (talk) 23:24, 27 June 2016 (UTC)

In general, unless something is broken to the extent that there are large red system error messages or the rendering is meaningless, I avoid making changes to the live module. I understand that you are eager, but I don't see this issue rising above the must-fix-now threshold. Am I wrong?
—Trappist the monk (talk) 10:19, 28 June 2016 (UTC)
This one on its own perhaps not, but certainly bundling that with the bibcode validation and other updates since the last one... bimonthly is a long time to wait between updates. Monthly seems much better. And if a WMF dev says they're waiting eagerly for that update, I don't really see a benefit to waiting for an arbitrary deadline before deploying. Headbomb {talk / contribs / physics / books} 13:56, 28 June 2016 (UTC)
There are those who would say that monthly is too often. Neither of these updates, even grouped together, it seems to me, are must-fix-now. I am eager for a fix to the Math ML metadata problem and am eager for a preview-mode keyword or a Lua function to take the place of the ugly mechanism that must be used to support the preview-mode functionality both as it is now or with the update. We all want something, né?
—Trappist the monk (talk) 16:54, 28 June 2016 (UTC)
I know of no one who would argue that one month is too often. Personally, I'd even go with weekly. If the code is tested, and it works, then the sooner it's rolled out the better, and unless sys admins tell us they'd appreciate us slowing down the deploy rate, WP:PERF applies. Headbomb {talk / contribs / physics / books} 20:43, 28 June 2016 (UTC)
And it seems particularly silly to delay a feature that WMF sys admins say would actually help them with said performance, because... what exactly is the argument for only rolling out updates every two months anyway? Headbomb {talk / contribs / physics / books} 20:47, 28 June 2016 (UTC)
Let's not get all hot and bothered over this. The issue is not really pertinent here. Performance is something that should (and can) be resolved at the MW development/admin level, not in user space. As for updating, there is the issue of code stability. No matter how well code is tested, bugs/incompatibilities can and will creep in, as most updates introduce added levels of complexity. Especially so when programmers succumb to featuritis. Not to mention the increased opportunities of code misuse with every addtion. Security/stability updates should be applied as soon as possible. Optimizations can wait a while. And enhancements can certainly be under a two-month cycle. 72.43.99.146 (talk) 23:46, 28 June 2016 (UTC)
Two months seems about right because by then, enough minor changes have accumulated to make it worth while. When the module suite was in development, there were complaints about too many changes too often – something to do with the job queue if I remember correctly. Every time we change Module:Citation/CS1, 2.9+million articles get dumped onto the job queue. It can take more than a month to sort through all of those articles.
—Trappist the monk (talk) 12:16, 29 June 2016 (UTC)
We have a workflow that involves making small changes and looking carefully at the numbers so we can understand impact. Two months is just way too long in my opinion, especially considering you can apply this particular change in isolation very easily with no real risk. So I am a bit disappointed. That said, it's ultimately for you and your peers to make the call, based on whatever works best for you. --Ori Livneh (talk) 04:52, 30 June 2016 (UTC)

"|registration=yes" rendering is awful

I was just editing an article where one of the citations required (free) registration to read, so I looked at the {{cite web}} template and found there was a "|registration=yes" parameter, so I added that. However, it renders so poorly and confusingly for readers -- "(registration required (help))." with the help tooltip giving "Sources are not required to be available online. Online sources do not have to be freely available. The site may require registration." -- that I reverted my change and just added "(Registration required.)" at the end of the <ref> manually.

First off, the "r" in "registration" should be capitalized if there's a period at the end, and the period should go inside the parentheses, not outside. Secondly, "Sources are not required to be available online. Online sources do not have to be freely available." must be very confusing to the average reader. I don't think it's helpful to the average reader to obliquely define Wikipedia reference inclusion policy in the help for what the tag means. Finally, why the weasel words in "may be required"? The parameter says "registration=yes", and it renders as "registration required" -- the "may be" has no business being there.

Points 1 and 3 seem objective enough that I would go ahead and edit the template myself now, but I don't seem to have the rights to edit that particular template.

"|subscription=yes" rendering may have parallel problems; I didn't check. --Dan Harkless (talk) 09:15, 30 June 2016 (UTC)

@Dan Harkless: Everyone has the right permissions to edit the sandbox. Nothing at cs1|2 changes unless it first passes through the sandbox. The text rendered for |registration= and |subscription= is in Module:Citation/CS1/Configuration/sandbox.
You may also be interested in this discussion: Help talk:Citation Style 1#Partial paywall and subscription.3Dy.
—Trappist the monk (talk) 09:54, 30 June 2016 (UTC)

Df parameter

I've tested the df parameter in the cite web template. The use of that parameter is described in the documentation for that template. However, that parameter isn't included in the TemplateData, which means that using the parameter in VE requires ignoring an "unknown field" comment by VE. Once added, it does work as documented, however. Would someone add df parameters to TemplateData descriptions for all citation templates that allow this, so the "unknown field" comment by VE goes away? -- John Broughton (♫♫) 23:23, 25 June 2016 (UTC)

On a related point, I just used |df= to test something else on the Beta Cluster, and there's a display bug. It produced ( 7 July 2008), with an extraneous leading space. Please feel free to {{ping}} me if you need any further information from me. Whatamidoing (WMF) (talk) 16:22, 30 June 2016 (UTC)

Fixed, I think.

Cite news comparison
Wikitext {{cite news|accessdate=November 22, 2008|date=July 8, 2007|df=dmy|first=Jennifer|last=Ablan|publisher=Reuters|title=Wikipedia page the latest status symbol|url=http://www.reuters.com/article/domesticNews/idUSN2232893820071022?sp=true}}
Live Ablan, Jennifer (8 July 2007). "Wikipedia page the latest status symbol". Reuters. Retrieved November 22, 2008.
Sandbox Ablan, Jennifer (8 July 2007). "Wikipedia page the latest status symbol". Reuters. Retrieved November 22, 2008.

The conversion uses os.date() with a format string '%e %B %Y'. The %e format returns the day-of-month-number with a leading space if the day is 1–9. There isn't a format string to return just the number regardless of the number of digits so I tweaked the code to look for and remove any leading space characters.

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

Small caps formatting in |author=

There are editors (or at least one that I know of: Tisquesusa) who insist on small caps formatting of author names in references. The argument is that the ability to customize appearance of names is important, and that a technical solution should be found to enable it (i.e. a form of |author-mask= functionality). It would be helpful to discuss whether the current recommendation is to be upheld, or perhaps there is a way to accommodate this request. --Dcirovic (talk) 22:42, 30 June 2016 (UTC)

Small caps are not allowed in |author=, per the Manual of Style, which says "Avoid writing with all capitals, including small caps, when they have only a stylistic function."
Also see this May 2015 RFC. Quoting from the closing statement: "essentially the consensus is that all caps should not be used, except when omitting them gives the section a completely different meaning, such as in scientific terms."
As for the specific diff, the {{aut}} template that is being used inside those cite templates "should not be used in citation templates such as Citation Style 1 and Citation Style 2, because it includes markup that will pollute the COinS metadata they produce". This is a quotation from the documentation for the {{aut}} template. The documentation for the template explains the reasons in detail and provides alternative cite templates to use if small caps are still desired. – Jonesey95 (talk) 00:05, 1 July 2016 (UTC)
The list of exceptions in the MOS section you cite includes "some citation styles". But I think Citation Style 1 is not one of them. —David Eppstein (talk) 00:22, 1 July 2016 (UTC)
The editor's claim that there are 35k uses of {{aut}} plainly wrong. That template has about 12k page uses; {{small caps}} has a mere 70 page uses. According to this insource: search, there are less than 25 pages using {{aut}} in |author=; I found none in a similar search using |last= or |lastn=.
—Trappist the monk (talk) 00:41, 1 July 2016 (UTC)
Hi all, the thing is: is something is broken, fix it. It doesn't help avoiding the problem by postponing the solution. To avoid the problems is avoiding triggering a solution and that's what's needed. I hope a solution will be developed soon, as that is the only way forward. Cheers, Tisquesusa (talk) 02:44, 1 July 2016 (UTC)
Tisquesusa, thanks for joining this discussion. Please define what you think is broken so that we can help you fix it.
Citation Style 1 does not allow {{aut}}/{{smallcaps}} or all caps in citations as a text styling method. Reasons for this are explained in copious detail in the template's documentation. If you want all caps in your citation style, which is contrary to MOS (but which is probably OK with CITEVAR, which has been interpreted to allow editors to do just about anything), you can use {{Cite LSA}} or another template that allows such styling, or you can write your citations without the use of cite templates. There are probably other valid options as well. – Jonesey95 (talk) 03:39, 1 July 2016 (UTC)
Yes I saw it generates an error in Zotero (or something like that). To me, that means; task to solve the error, as apparently it is not about the small caps themselves, as LSA is possible. I will rewrite the citations to the LSA style then to keep the format. Will take some time as I cite a lot in the articles I write or expand. It could be good to mention it clearer, the LSA solution is somewhat hidden in a list of suggestions, and the page itself does not even list the option of |url= which is possible, I just tested it. But that's my general problem with "Help" pages in Wikipedia, they are far too unclear for even relatively experienced users, while the wiki syntax is easy enough. Thanks for the link, Tisquesusa (talk) 05:30, 1 July 2016 (UTC)
I'm aware, of course, of the interpretation of CITEVAR that says it allows smallcaps, but be clear that this is directly against the MOS and not acceptable to many editors. Peter coxhead (talk) 05:55, 1 July 2016 (UTC)
I was first one to suggest Tisquesusa not to use that as it is uncommon; however, the user was trying to prove it is a "professional" way to list out names in the particular citations (it is not true, obviously; not only for cited bibliography but for any CS1 template). --Obsuser (talk) 14:13, 1 July 2016 (UTC)

dates other than year in |year=

I'm in the process of cleaning out Category:CS1 maint: Date and year and have found several templates like this one where |year= holds more date detail than just the year:

{{Cite news| url=http://www.telegraph.co.uk/finance/newsbysector/retailandconsumer/5207045/Intertek-shares-soar-on-speculation-of-bid-from-Swiss-rival-SGS.html|title=Intertek shares soar on speculation of bid from Swiss rival SGS|accessdate=30 August 2010|publisher=The Telegraph| year=23 Apr 2009 | location=London | first=Louise | last=Armitstead | date=23 April 2009}}
Armitstead, Louise (23 April 2009). Intertek shares soar on speculation of bid from Swiss rival SGS. London: The Telegraph. Retrieved 30 August 2010. {{cite book}}: Check date values in: |year= (help)CS1 maint: date and year (link) CS1 maint: year (link)

It seems to me that |year= should hold just that, a year with optional circa and/or optional CITEREF disambiguator.

—Trappist the monk (talk) 12:55, 10 June 2016 (UTC)

Looking further at this, a 'solution' is problematic. Before we do the date validation, we look at the values of |date=, |year=, and |publication-date=. If |date= is not set, we promote the first set of |year= or |publication-date= to |date=. So, when |date= is not set and |year=23 Apr 2009, we make |date=23 Apr 2009 and |year= becomes nil. Because '23 Apr 2009' is a valid date, and no longer associated with |year=, there is no detectable error.

'Fixed' in the sandbox:

pass: |year= without |date= is promoted to date. 23 Apr 2009.{{cite book}}: CS1 maint: year (link)
pass: |year= has year and |date= has date. 2009-04-23.{{cite book}}: CS1 maint: date and year (link)
pass: |year= has year with CITEREF disambiguator and |date= has date. 2009-04-23.
fail: |year= has whole date and |date= has a value. 2009. {{cite book}}: Check date values in: |year= (help)CS1 maint: date and year (link) CS1 maint: year (link)

—Trappist the monk (talk) 10:45, 2 July 2016 (UTC)

Don't feel like hunting for the code, so I ask you instead:
If |date= is not set, we promote the first set of |year= or |publication-date= to |date=.
Does the code actually transfer the value of |year= or |publication-date= to |date=? Or does the value of these parameters become the cited date instead?
72.43.99.146 (talk) 14:38, 2 July 2016 (UTC)
Module:Citation/CS1/sandbox line 2426.
—Trappist the monk (talk) 14:52, 2 July 2016 (UTC)
Thanks. 72.43.99.146 (talk) 15:22, 2 July 2016 (UTC)

Volume and Issue default fields for Citoid w/ Journals

Currently, the invocation of {{cite journal}} in citoid and VE's insert template function, doesn't, by default, include the fields of "Volume" and "Issue". I am guessing for the vast majority (academic journal and popular magazine runs) of the uses of this template, having those fields is crucial to identifying the correct issue within the print run of the work. Can someone who is familiar with TemplateData make these default fields? It seems silly to have new editors know they need to add this field, instead of spoon feeding the option to them. Thanks much, Sadads (talk) 15:29, 5 July 2016 (UTC)

Not a fan of ve and certainly not a fan of TemplateData so I'm not going to be editing that. Perhaps you meant 'suggested' instead of 'default'. Since the TemplateData documentation is at best mediocre, I can only guess that 'default' applies to the parameter's assigned value – if |volume= is left blank, then ve uses the value set in the TemplateData 'default' field. The 'suggested' as opposed to 'optional' setting would seem to be what it is that you want.
To edit the {{cite journal}} TemplateData, go to Template:Cite_journal#TemplateData and edit that section. You will see a button at the top that reads 'Manage TemplateData'. Click that and you are in the TemplateData editor.
—Trappist the monk (talk) 15:52, 5 July 2016 (UTC)
@Sadads: You shouldn't be using {{cite journal}} for popular magazines, but {{cite magazine}} - it also has |volume= and |issue=, but they are displayed differently. --Redrose64 (talk) 17:08, 5 July 2016 (UTC)
 Done Thanks for the feedback/suggestion @Trappist the monk:. If you haven't tried visual editor in the last 6 months or so, I am a convert: almost all the bugs are gone, and its only about 5-10% of my edits in article space that I want something more. I have also found it extremely useful in my volunteer outreach role, when I am running editathons, etc: not having to teach folks templates, and how they work -- instead teaching them simple forms for specific use cases is beautiful. Thanks for the suggestion Redrose64: was not familiar with cite magazine -- at some point in redirected didn't it? I think I have just never used it because all of the major citation guidelines and help tools just provide journal (which offers much the same metadata preservation). Sounds like something we ought to have a bot for, Sadads (talk) 22:21, 5 July 2016 (UTC)

Partial paywall and subscription=y

The Los Angeles Times has some kind of weird paywall thing going on. For example, this article displays for me with no problem, but this one tells me I've reached my monthly limit and need to cough up some cash if I want to read it.

Well never mind that weirdness, that's secondary. Let's say they treated all articles the same, giving you x free views per month. There is no way to know whether a particular reader has reached their monthly limit, so should cites for that site use |subscription=y? It's a "subscription might be required, depending" situation. ―Mandruss ☎ 09:43, 22 June 2016 (UTC)

Pretty sure this topic has come up before but never resolved. The template needs some sort of way to know that there is limited free-access so perhaps |subscription=limited which in turn might tell the module to emit a message like (Subscription may be required) or (Limited free access).
—Trappist the monk (talk) 11:46, 22 June 2016 (UTC)
Ok, I'd support that parameter value, and "limited free access" would be the more descriptive of the two. For the time being I'll just omit |subscription= (which most editors are doing even for zero-free-access sites). ―Mandruss ☎ 12:46, 22 June 2016 (UTC)

Addressing issues raised at Adding open access links to references caused me to wonder about applying a similar mechanism to |subscription= and |registration=. For example, for this case: |subscription=yes, the module might render a citation

{{cite news |title=Article title |url=//example.com |newspaper=World-wide Times Gazette |subscription=yes}}
"Article title"subscription required. World-wide Times Gazette.

Unlike the open access icons, this one is linked to explanatory text.

For |registration=yes, use the same lock icon but in a different color? For the 'limited free access' case contemplated in this discussion, perhaps a gray colored version of the open access lock?

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

I like conciseness. I suppose it depends on the question: Just how important is it for the reader to understand the situation before they click through? It could take decades before a majority of readers who look at sources (1) have noticed those little locks and (2) have learned what they mean. We have little PDF icons, but the PDF logo is fairly widely recognized already (I think). ―Mandruss ☎ 16:27, 22 June 2016 (UTC)

I have been thinking about this topic because of the discussion at Help talk:Citation Style 1#adding free-to-read icons. If cs1|2 is to replace text with icons, then those icons, it seems to me, should all have the same base shape. Because of the small size, detail visible at larger sizes will be lost. Along with that, we can't use color as the sole indicator of meaning because, those who are color blind won't notice the color difference except that perhaps the icon is a slightly different shade of gray. The meaning then, must be distinguishable by its shape. Here are four icons that I think could be used:

  • free to read – free to read – derived from the Open Access logo
  • registration required – registration required – same shape as free-to-read except that the shackle is closed and the color is black
  • subscription required – subscription required – same shape as registration required except that the body is filled
  • limited free access – limited free access – same shape as registration required except that half the body is filled

—Trappist the monk (talk) 09:20, 3 July 2016 (UTC)

The icons are a cosmetic change, but the link notes are (or can be) precise and informative. Other than that, I suppose they look good, even if somewhat cryptic. Tooltips help to make their meaning more explicit, but in general, I have doubts over tooltip usability. 72.43.99.138 (talk) 17:02, 3 July 2016 (UTC)
I've tweaked the above examples to include alt text which provides tool tips and in the case of the subscription required lock, added a link to Wikipedia:Verifiability#Access to sources. I imagine that we should make all of these locks, if we decide to use them in cs1|2 templates, link to appropriate subsections of Help:Citation Style 1 so that readers can learn what they mean.
—Trappist the monk (talk) 10:38, 4 July 2016 (UTC)
I do have trouble mentally distinguishing between the registration and subscription icons. Both are in effect locks: one key is registering, and the other key is purchasing. I can't tell from looking which image is supposed to describe the more burdensome (costly) scenario. The registration lock still looks completely closed-off, moreso than it really is, while the subscription icon looks entirely foreboding with its menacing and blank white face. I've never seen a lock with no keyhole before, so this introduces some confusion regarding what to associate it with. It may be worth rethinking those two icons (although the other two are very cool). One thought, for registration, you could consider using a lock with the @ symbol somewhere it's keyhole would be, signifying an email address is needed. Just thinking. Graphic design is not my speciality... Jake Ocaasi (WMF) (talk) 20:08, 6 July 2016 (UTC)
There is only so much "meaning" you can put into something that small, so I think we would have to rely on the tooltips and links for first-time usage. Can you tell what this means without clicking on it? ---> <--- Similarly, Firefox shows me a little "i" icon next to my address bar. I had no clue what it meant until I moused over and read the tooltip: "Verified by: GlobalSign nv-sa". And the star to the right of the address bar? How could I have guessed that a star means "Bookmark this page"? I think we all use tooltips to learn what things are without even thinking about it. Don't know what something is? Try a mouseover. It's automatic for most of us. ―Mandruss ☎ 20:30, 6 July 2016 (UTC)
@Trappist the monk: But I think the icons would be more recognizable as padlocks if in the form or . This is consistent with the icons produced by {{pp}} to show page protection. Not necessarily the same images, but mimicking that shape. I think a darker color would make it more apparent that the second lock is open, but I couldn't find such an image. That Open Access logo is stylized and I don't think intended to closely resemble a padlock. Likewise, the Apple logo is more about distinctive branding than apple recognition. It's meant to convey Apple, not apple. ―Mandruss ☎ 03:32, 7 July 2016 (UTC)
A propos of nothing, what you mentioned above re:meaning and cryptic icons (like your Firefox examples) is indicative of bad software design imo, which is now accepted as the norm. General-use software (i.e. software not targeting experts) should not force people to divine a whole new symbol-based nomenclature as an additional requirement (to learning how to actually use the software itself). 72.43.99.146 (talk) 14:30, 7 July 2016 (UTC)
We live in a symbol-based world. How about you prototype us a browser interface that provides the needed functionality without using symbols and tooltips. Microsoft will pay big bucks for it. ―Mandruss ☎ 15:17, 7 July 2016 (UTC)

Parameter "permalink"?

Hello,

Maybe I'm missing something but I found that the cite web template (from here and citar web from portuguese wikipedia) doesn't offer a "permalink" parameter?! Most of time a website URL is different from the content URL (the "permalink"), how we inform this:

The portuguese version of "cite web" template is currently broken on several pages that has an URL on "publisher" and other parameters (eg [1], [2] and thousand others articles). How we can fix those citation without removing the very website URL or the permalink? It seems lame that cite web/citar web doesn't provide a permalink parameter. Thanks for any clarification. Dianakc (talk) 17:23, 30 June 2016 (UTC)

From en.wiki's point of view, your template is working correctly. Here, we have taken the position that a working |url= is all that is required and that url links in |work= and |publisher= (and all of their aliases) are unnecessary and perhaps harmful (for a list of aliases, see 'Periodical' and 'PublisherName' here). The values assigned to |work= and |publisher= may be used in the citation's metadata where the metadata format expects titles or title-like text. For example, the publisher metadata from this {{citar web}} at pt:Begonia annulata:
{{Citar web | url=http://www.theplantlist.org/tpl1.1/record/kew-361149|título=''{{subst:PAGENAME}}''|acessodata=17/8/2014|autor=|data= 2010|formato= |publicado= [http://www.theplantlist.org The Plant List]|páginas=|língua=inglês|citação=}}
is:
&rft.pub=%5Bhttp%3A%2F%2Fwww.theplantlist.org+The+Plant+List%5D
It should be:
&rft.pub=The+Plant+List
Here, I don't think we have the same concept of 'permalink' that you apparently have. For us, I think that 'permalink' is a permanent link to a page. I understand your concept of 'permalink' to be a link to a website's home page.
As you can see from the example pages that you provided, |título=''{{subst:PAGENAME}}'' isn't doing what it is that you want it to do. This is not a fault of the template but is a long-standing problem with MediaWiki. {{subst:}} does not work in <ref>...</ref> tags.
—Trappist the monk (talk) 19:29, 30 June 2016 (UTC)
I left out a bit. What to do about the 8,000+ pages is a decision that only pt.wiki can make. We cannot make it for you. Were it up to me, I would fix each citation. That is a task that can very likely be accomplished with a bot task or an editor who uses pt:WP:AWB.
—Trappist the monk (talk) 19:44, 30 June 2016 (UTC)
Thanks for reply, just to clarify that I'm using the permalink concept that is "a URL that points to a specific web page", we do not have a different concept for that (on or off-wiki). I understand that the code is ok but not really sure on how this template can be useful, the rendering is not user friendly since it can't differ the website URL from the content permalink. I will ask someone to fix the current pages using the template and will avoid using the template. Thanks again. Dianakc (talk) 20:54, 30 June 2016 (UTC)
@Dianakc: I guess I don't understand what you wrote. |url= holds a URL that points to a specific web page. Nor do I understand how you are not really sure on how this template can be useful, the rendering is not user friendly since it can't differ the website URL from the content permalink. Someone must have found it useful because at en.wiki it is used on 2.2+million pages and there is this at the top of the {{citar web}} documentation page:
Esta predefinição é usada em mais de 308 438 página
So perhaps I'm not understanding your question?
—Trappist the monk (talk) 21:44, 30 June 2016 (UTC)

What is generated COinS for |publisher=[[The New York Times]]? I've seen editors often link publisher, newspapers etc. so [[ and ]] might be problem too if modules don't do delinking.

Btw, (maybe wrong place to ask for {{para}} but not important too much for starting discussion on template's talk page) I've just noticed that {{para|publisher|[[The New York Times]]}} gives |publisher=The New York Times, why not |publisher=[[The New York Times]] i.e. why not to nowiki parameter content?--Obsuser (talk) 02:46, 1 July 2016 (UTC)

For each of the three cases 
|publisher=The New York Times
|publisher=[[The New York Times]]
|publisher=<nowiki>[[The New York Times]]</nowiki>
the emitted COinS is exactly the same - rft.pub=The+New+York+Times. But the third case pollutes the displayed reference, by making the square brackets visible. However, your examples exhibit a common error with news sources - The New York Times is not the publisher, it is the publication (the work in which the item was published), so you should use |newspaper=The New York Times and if you want to be pedantically complete, add |publisher=Arthur Ochs Sulzberger Jr. as well (but I don't see the point in that unless the news item was libellous, in which case it is Sulzberger who would be served with the legal papers). --Redrose64 (talk) 08:39, 1 July 2016 (UTC)
Third case is irrelevant (I nowikied so that wikilink inside {{para}} is not shown but square brackets). Content of the parameter is also unimportant (however, thanks for explaination for publisher and newspaper etc.).
My question was only about square brackets i.e. whether they appear or not in (pollute or not) metadata. Now I know they don't but external links (with URLs) do. --Obsuser (talk) 14:13, 1 July 2016 (UTC)
If wikiling square brackets can be and are recognized and removed from metadata, why not to remove other things such as &nbsp;, some templates, some tags etc. too? --Obsuser (talk) 18:16, 8 July 2016 (UTC)

Two citations I can't figure out how to format correctly

Somehow neither my familiarity with these templates nor the documentation is helping me figure out how to cite these two citations using the templates in a way that generates correct metadata and avoids error messages.

First, from Monterey Road (California), we have the citation

I would like to format it as

  • {{cite magazine|publisher=California State Automobile Association|year=1974|url=https://books.google.com/books?id=U5Y9AQAAIAAJ|magazine=Motorland|issue=2|page=8}}

but that doesn't work:

Abusing |author= instead of |publisher= is a little better, but still no good.

  • California State Automobile Association (1974). "none". Motorland. No. 2. p. 8.

It gets the text formatted the way I want, but puts the url in a bad place and complains about the missing or empty title. I also tried setting |title=none to no avail. Possibly the magazine piece has an actual title, but the Google books snippet view (sufficient for verifying the fact claimed to that source) is inadequate to locate it. In any case, we should be capable of formatting non-titled magazine information. (This article actually uses CS2 and {{citation}} but the behavior is the same.)

The second one is an external link from Erdős–Gyárfás conjecture:

There seems to be no way to include a link both on the |title= and |work= without a complaint from the template. Changing |title= to |contribution= and |url= to |contribution-url=, in order to free up |title= and |url= for the second link, also doesn't work; the template just ignores the url.

These sorts of inflexibilities are driving me away from using the citation templates. I can only imagine how much stronger the same effect is likely to be on new users. —David Eppstein (talk) 20:23, 12 July 2016 (UTC)

We've had a number of discussions regarding the second case, mostly resolving to the point that we don't need to provide the URL to the work's site if we have a more specific web page of interest (and sometimes even where we don't). I'm pretty sure we've also discussed #1, but I am unsure of keywords to look for that one in the archive. --Izno (talk) 21:11, 12 July 2016 (UTC)
A bit naughty, but how about *{{cite magazine|title=Article|publisher=California State Automobile Association|year=1974|url=https://books.google.com/books?id=U5Y9AQAAIAAJ|magazine=Motorland|issue=2|page=8}}
  • "Article". Motorland. No. 2. California State Automobile Association. 1974. p. 8.
I'd agree with Izno, the link to the article implicitly gives a link to the whole. {{cite web | url = http://www.math.uiuc.edu/~west/openp/2powcyc.html | title = Erdős Gyárfás Conjecture on 2-power Cycle Lengths | work = Open Problems - Graph Theory and Combinatorics | author = West, Douglas B.}}
HTH, Martin of Sheffield (talk) 21:21, 12 July 2016 (UTC)
(edit conflict) Regarding the first situation, the title of the magazine article is not known because you're accessing it through snippet view. We can't read enough of the page that way to determine the proper article title to credit. We can't even be sure that Google's pagination matches that of the print magazine they're reproducing; what is page 8 to them might have a different numbering in print. In short, the citation is incomplete and the error is basically valid .The best course of action, long term, is for someone to attempt to locate the actual source in print and fill in the missing details. (Also, it would be better to consult the full article to see if there are additional details to be added to our article from that source, details obscured in snippet view. Imzadi 1979 → 21:24, 12 July 2016 (UTC)
Thanks for the clarification. Let me reiterate my broader point, since you all seem to be overlooking it. This inflexibility is driving me away from using the citation templates. I had already given up on using the templates for the Roadways cite, and have now gone ahead and reformatted the West cite manually as well. —David Eppstein (talk) 21:25, 12 July 2016 (UTC)
Interesting POV. Given a free choice I tend to use {{citation}}. Just fill in all that is known and let the system worry about the formatting. Citation has the advantage over the Cite XYZ templates that it sets up harvid for you, which makes using {{sfn}} simplicity itself. Martin of Sheffield (talk) 21:34, 12 July 2016 (UTC)
Ok, don't believe me that these templates are increasingly becoming very difficult to use. I don't care any more. —David Eppstein (talk) 21:54, 12 July 2016 (UTC)
The question here is mostly that |title=none should be supported, but also that the URL in this instance is useless. Headbomb {talk / contribs / physics / books} 21:57, 12 July 2016 (UTC)
How about: "[title unknown]". Motorland. No. 2. California State Automobile Association. 1974. p. 8.
That eliminates the error message and correctly shows that we do not know the title of the article we are citing. Some text in magazines appears with no title at all, so putting "[no title]" or something similar should suffice.
By the way, the article in question appears to be called "Commentary: Freeway link near San Jose needs finishing". Do a search for "commentary" or "dirty car again" to see the top of the page. I was unable to verify the page number. – Jonesey95 (talk) 22:06, 12 July 2016 (UTC)

Cite web is malfunctioning

template markup removed from section heading. here's the link {{Cite web}}—Trappist the monk (talk) 10:18, 13 July 2016 (UTC)

Hey.

I tried inserting this:

{{cite web |url=http://www.mactech.com/articles/mactech/Vol.05/05.05/Hourglass/index.html |title=Lisa's Hourglass Is Back! |work=[[MacTech]] |publisher=Xplain |volume=5 |issue=5 |first=Mike |last=Morton |location=[[Waipahu, HI]]}}

It gave me this:

Morton, Mike. "Lisa's Hourglass Is Back!". MacTech. Waipahu, HI: Xplain.

As you can see, the |issue=, |volume= and |location= are ignored without an error message saying they are unknown parameters. (Doc pages says they are supported.) I could swear this is new. I had seen these parameters working before.

FleetCommand (Speak your mind!) 07:09, 12 July 2016 (UTC)

|location= is working again. FleetCommand (Speak your mind!) 07:13, 12 July 2016 (UTC)
MacTech is a journal so you should use {{cite journal}}:
{{cite journal |url=http://www.mactech.com/articles/mactech/Vol.05/05.05/Hourglass/index.html |title=Lisa's Hourglass Is Back! |work=[[MacTech]] |publisher=Xplain |volume=5 |issue=5 |first=Mike |last=Morton |location=[[Waipahu, HI]]}}
Morton, Mike. "Lisa's Hourglass Is Back!". MacTech. 5 (5). Waipahu, HI: Xplain.
—Trappist the monk (talk) 11:11, 12 July 2016 (UTC)
Or, {{Cite magazine}}, unless you consider that in the class of "academic and scientific papers and journals". Per {{Cite journal}}. ―Mandruss ☎ 15:36, 12 July 2016 (UTC)
Hi.
Judging from FC's edit log, he already knows as much. He has used {{Cite news}}.
But why is {{cite web}} broken? And why just this instance when I though we have the green light to go ahead and merge these two and have one less damn template around the place?
Best regards,
Codename Lisa (talk) 09:22, 13 July 2016 (UTC)
{{cite web}} is not broken. In November 2015 we adjusted how Module:Citation/CS1 supports |volume=, |issue=, |page(s)=. See the discussion.
I do not understand your last sentence. Merge what two? From whom did we get a green light? Can you point to a discussion about these matters?
—Trappist the monk (talk) 10:18, 13 July 2016 (UTC)
@Trappist the monk: Did you or did you not prevent {{Cite web}} from displaying them? If yes, why Cite web isn't generating an error message to the effect that they are unsupported? (As it does when you pass |FooBarParam=FUBAR to it.) And why the documentation didn't get an update?
Best regards,
Codename Lisa (talk) 13:20, 13 July 2016 (UTC)
P.S. Please excuse any delay in my response time. I have a huge copyright mess to clean up. —Best regards, Codename Lisa (talk) 13:25, 13 July 2016 (UTC)
I did write: In November 2015 we adjusted how Module:Citation/CS1 supports |volume=, |issue=, |page(s)= and I did point to the discussion that preceded the change. So, yeah, I did prevent {{Cite web}} from displaying them.
cs1|2 is rather selective about reporting unsupported valid (in the sense that they are listed in Module:Citation/CS1/Whitelist) parameters. Off the top of my head I can think of {{cite arxiv}} which has a very limited set of parameters it supports and certain cases of |chapter= aliases (see Category:CS1 errors: chapter ignored).
The current Template:Cite web/doc does not mention |volume= or |issue= except in the COinS boilerplate. Because that template's documentation is itself a template, it's hard to know if {{cite web}} ever supported |volume= and |issue=. Certainly, it does not now and the documentation reflects that.
So what about the green light to merge something? I'm still unclear what it is that you're talking about.
—Trappist the monk (talk) 00:55, 14 July 2016 (UTC)
Thank you for finally answering my question, after much beating around the bush. Of course, your point-making style of writing clearly indicates there is a lot bad blood between you and Mrs. "Best Regards" here, so I'll get out of the way and let you two kill each other however you see fit. —FleetCommand (Speak your mind!) 13:42, 14 July 2016 (UTC)

Multiple authors II

Further to Help talk:Citation Style 1/Archive 18#Multiple authors, and User talk:Dcirovic/Archive 1#Authors, it appears that Dcirovic (talk · contribs) has resumed their behaviour. I have left a note at User talk:Dcirovic#Authors, again. --Redrose64 (talk) 14:37, 14 July 2016 (UTC)

Consulting editors

Hello. How do I cite "consulting editors" for this book in Zev Garber's article please? Someone added the book without using the citation template, but I'd like to cite it properly and include the OCLC. Thank you.Zigzig20s (talk) 21:40, 14 July 2016 (UTC)

Use |others=. See the documentation for {{cite book}}. – Jonesey95 (talk) 22:30, 14 July 2016 (UTC)
No, I don't think so. This looks weird:
  • Berenbaum, Michael; Rubenstein, Betty Rogers, eds. (1995). What Kind of God? Essays in Honor of Richard L. Rubenstein. Rubenstein Feibel, Hannah; Garber, Susan; Garber, Zev. Lanham, Maryland: University Press of America. ISBN 9780761800361. OCLC 32780110.
User:Jonesey95: Did you mean something else?Zigzig20s (talk) 23:19, 14 July 2016 (UTC)
I meant like this:
  • Berenbaum, Michael; Rubenstein, Betty Rogers, eds. (1995). What Kind of God? Essays in Honor of Richard L. Rubenstein. Consulting editors: Rubenstein Feibel, Hannah; Garber, Susan; Garber, Zev. Lanham, Maryland: University Press of America. ISBN 9780761800361. OCLC 32780110.
as is roughly described in the documentation to which I referred you. – Jonesey95 (talk) 23:33, 14 July 2016 (UTC)
OK I've updated Zev Garber's article. I think it's not ideal that the consulting editors don't come just after the main editors, though. Could someone please fix this? I also think the citation templates should include editors, not just authors.Zigzig20s (talk) 23:47, 14 July 2016 (UTC)

See this version of Carmen, which fails to render the editor "Neef, Sigrid" when |editor-link=de:Sigrid Need is present. Omitting the de: unsatisfactorily solves this problem.

Cite book comparison "editor-link=de:Sigrid Need"
Wikitext {{cite book|edition=English|editor-link=de:Sigrid Need|editor=Neef, Sigrid|isbn=3-8290-3571-3|location=Cologne|publisher=Könemann|title=Opera: Composers, Works, Performers|year=2000}}
Live Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. {{cite book}}: Check |editor-link= value (help)
Cite book comparison "author-link=de:Sigrid Need"
Wikitext {{cite book|author-link=de:Sigrid Need|author=Neef, Sigrid|edition=English|isbn=3-8290-3571-3|location=Cologne|publisher=Könemann|title=Opera: Composers, Works, Performers|year=2000}}
Live Neef, Sigrid (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. {{cite book}}: Check |author-link= value (help)
Cite book comparison "editor-link=Sigrid Need"
Wikitext {{cite book|edition=English|editor-link=Sigrid Need|editor=Neef, Sigrid|isbn=3-8290-3571-3|location=Cologne|publisher=Könemann|title=Opera: Composers, Works, Performers|year=2000}}
Live Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3.
Cite book comparison "author-link=Sigrid Need"
Wikitext {{cite book|author-link=Sigrid Need|author=Neef, Sigrid|edition=English|isbn=3-8290-3571-3|location=Cologne|publisher=Könemann|title=Opera: Composers, Works, Performers|year=2000}}
Live Neef, Sigrid (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3.

  ~ Tom.Reding (talk ⋅dgaf)  18:07, 14 July 2016 (UTC)

What's doubly weird is that the editor is rendered here in the {{cite compare2}} calls above, but not in my sandbox...   ~ Tom.Reding (talk ⋅dgaf)  18:08, 14 July 2016 (UTC)

@Tom.Reding: they all render exactly as they should for me. Peter coxhead (talk) 18:17, 14 July 2016 (UTC)
@Peter coxhead: on all 3 pages (here, Carmen, sandbox)? I've null-edited all 3 of them, but that's not working.   ~ Tom.Reding (talk ⋅dgaf)  18:21, 14 July 2016 (UTC)
Whoops, no; at Carmen there's just a blank for the editor, displayed and in the source HTML. Must be a bug. Peter coxhead (talk) 18:46, 14 July 2016 (UTC)
That is very strange. I am seeing a rendered editor name and link here on this page, but not at User:Tom.Reding/sandbox2. I have copied and pasted the full contents of the Sandbox2 page to this page just to make sure I'm not missing invisible characters or something. – Jonesey95 (talk) 19:25, 14 July 2016 (UTC)

Perhaps this isn't a problem with cs1|2 but a problem with the mark-up. Remember the old days when interlanguage links were added to the article? Then we moved them all to wikidata so we've forgotten that those old interlanguage links had the form: [[de:Sigrid Neef]] (and it is Neef). Those constructs added the link to the languages menus at left but were not visible in the article.

In those days, and still today, if you want a visible interlanguage link in an article, the format is: [[:de:Sigrid Neef]]. Right? See Help:Interlanguage_links.

—Trappist the monk (talk) 22:39, 14 July 2016 (UTC)

Eureka! [You] found it! Carmen & User:Tom.Reding/sandbox2 now display as intended (except for the Neef/d typo, which never happened on Carmen). I'll leave the above examples unchanged for permalink comparisons b/w here & my sandbox2.
So it works just like [[:Category:, [[:File:, etc; wonderful. I hadn't connected the syntaxes for some reason...   ~ Tom.Reding (talk ⋅dgaf)  01:53, 15 July 2016 (UTC)
The small remaining bug is that both {{cite compare}} and {{cite compare2}} display "Neef, Sigrid" here, but not when transcluded elsewhere (sandbox). One would expect them to at least be self-consistent regardless of their location, especially since they are used to check and instruct parameter usage.
Cite book comparison
Wikitext {{cite book|edition=English|editor-link=de:Sigrid Need|editor=Neef, Sigrid|isbn=3-8290-3571-3|location=Cologne|publisher=Könemann|title=Opera: Composers, Works, Performers|year=2000}}
Live Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. {{cite book}}: Check |editor-link= value (help)
Sandbox Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. {{cite book}}: Check |editor-link= value (help)
{{cite compare}}
Also, replacing de: with de&#58; didn't change anything.   ~ Tom.Reding (talk ⋅dgaf)  12:41, 15 July 2016 (UTC)
It's not a problem with either of those templates, it's the way that interlangauge links are parsed. In all namespaces, [[:de:Sigrid Need]] produces an inline link to the foreign-language page. In talk namespaces only, [[de:Sigrid Need]] produces an inline link to the foreign-language page, but in non-talk namespaces, [[de:Sigrid Need]] produces nothing inline, instead it adds a link to the "languages" list in the left sidebar. --Redrose64 (talk) 21:03, 15 July 2016 (UTC)
Ah, all is explained! So would it be sensible for the template to implicitly add ":" to interlanguage link values where it has been omitted? Peter coxhead (talk) 21:47, 15 July 2016 (UTC)
Yes, or at least an error message when in |author-link= or |editor-link=.   ~ Tom.Reding (talk ⋅dgaf)  22:45, 15 July 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_20&oldid=1153317343"