This is an archive of past discussions about Module:Citation. 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.
Maybe there should be included some check in |url=, if it starts with http/ftp etc.? Because if there is |url=www.example.com or |url=example.com, the link won't be clickable. --Edgars2007 (talk/contribs) 18:01, 25 September 2014 (UTC)
I'm not sure I understand what it is that you're asking. By the time the module gets to the content of a citation's various parameters, any templates will have already been expanded. So, all the module sees is all of the template cruft intermingled with the important stuff that CS1 wants.
If you mean should someone run an AWB script of some-such that would strip citations of these particular templates, then, yeah, someone should. I have it in mind to do that for {{nihongo}} and {{asiantitle}} after the initial implementation of |script-title= so that editors who work on Asian topics can see the results, and we'll get cleaner COinS.
I just added {{COinS safe|n}} to {{date}} and {{dts}}.
BattyBot aready removes {{date}}, {{dts}}, {{nowrap}} and {{start date}} from citation date fields to remove articles from Category:CS1 errors: dates. If there are variations that BattyBot isn't removing or additional templates it could remove, please let me know.
Re {{aut}}, you can find quite a few of them in the remaining articles in the deprecated parameters category, since Monkbot is not programmed to fix |coauthors= when templates are present in citations, as far as I know.
@Jonesey95: Closer inspection of the code showed that BattyBot already removed {{Nobreak}} and {{Startdate}} as well. It now also removes {{Nobr}}, {{No break}}, {{No wrap}}, and {{Start Date}} (although there weren't any CS1 date errors due to these templates). If anyone has examples of the other templates in use in CS1 citations, I'll add them too. Thanks! GoingBatty (talk) 23:54, 26 September 2014 (UTC)
A few months ago, {{cite doi}} was deprecated. Today, it looks like some edit enforced that deprecation by breaking the connection from {{sfn}} using an individual {cite doi} template. But without article cleanup (by a bot, I expect), {sfn} now produces an error (see helium). I do not know which page was edited into this break. Anyone an idea? (With that knowledge, I'll ask a revert on the right talkpage). -DePiep (talk) 09:26, 13 October 2014 (UTC)
Do you mean this?
Markup
{{Cite journal|title = Probing the interior of fullerenes by <sup>3</sup>He NMR spectroscopy of endohedral <sup>3</sup>He@C<sub>60</sub> and <sup>3</sup>He@C<sub>70</sub> |author = Saunders, M. ''et al.''|journal = Nature |volume = 367|issue = 6460|pages = 256–258 |year = 1994 |doi = 10.1038/367256a0|bibcode = 1994Natur.367..256S|first2 = Hugo A.|first3 = R. James|first4 = Stanley|first5 = Darón I.|first6 = Frank A. L. }}
Renders as
Saunders, M.; et al. (1994). "Probing the interior of fullerenes by 3He NMR spectroscopy of endohedral 3He@C60 and 3He@C70". Nature. 367 (6460): 256–258. Bibcode:1994Natur.367..256S. doi:10.1038/367256a0. {{cite journal}}: |first2= missing |last2= (help); |first3= missing |last3= (help); |first4= missing |last4= (help); |first5= missing |last5= (help); |first6= missing |last6= (help); Explicit use of et al. in: |author= (help)
Yes, these names are missing, producing error texts (helium now has four such references). The point is, a week ago they were not. The names were not deleted, but somehow a connection was removed ( Mirokado noted this). I don't know if the breaking edit was done in citation/CS1 or elsewhere. If a "bug removal" in /CS1 is the cause, I'd say that removal failed and should be revisited. But it could also be caused by another edit, someone enforcing the {{cite doi}} deprecation . -DePiep (talk) 12:02, 13 October 2014 (UTC)
Author detection was fixed in the last update. The citation listed above has |first= without |last= which is certainly not proper. As I see it, this error is proper.
re Aa77zz: nice, but they were mass-created, and I don't want to be forced to manually edit this way. Problem is so far nobody knows where the bad edit was made. -DePiep (talk) 13:05, 13 October 2014 (UTC)
If, by "mass-creating", you mean that many citations have lists of first names with no corresponding last names, Citation Bot created many citations like that; it was a bug that was eventually fixed. Running Citation Bot on the page again may add the last names. You will want to inspect the resulting edit, however; Citation Bot is a useful tool, but it is never free of bugs. – Jonesey95 (talk) 05:41, 14 October 2014 (UTC)
The bot action you propose still involves manual editing. I think all 17000 {cite doi} transclusions are suspected, and that would be too much for manual check.
I meant to say it was "mass-created" by one single recent edit (exposing old edits at once being 'wrong'; likely and edit in /CS1 as we know by now). When I asked for a bot cleanup, I was thinking of a new bot task, running once, that cleans this up. However, I don't know whether this is feasible, I have lost the topic after the code discussion below. Also, the code discussion below could produce another solution, making a bot action unneeded. So bots can wait till that option is fleshed out. -DePiep (talk) 07:24, 14 October 2014 (UTC)
The citation hack consists of stuffing {{cite doi}} into the |title= parameter of {{citation}} and adding markup to undo the italic markup. Currently the apostrophes are added to the title in the COinS metadata.
Module:Citation/CS1 was updated to prevent apostrophe markup from being passed into the COinS metadata. A bug was found and this update was reverted.
If this explains it, I think we better ask a bot to get author names from {cite doi/xxx} into the straight {cite} parameters (in article page that is). {{cite doi}} has 17000+ transclusions. -DePiep (talk) 13:24, 13 October 2014 (UTC)
The "real hack" used by Mirokado in this edit was the right idea but the wrong method. The old code was e.g.
{{citation|title=''{{Cite journal | last1 = Ahrens | first1 = L. | title = Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate | doi = 10.1039/c0em00373e | journal = [[Journal of Environmental Monitoring]]| publisher = [[Royal Society of Chemistry]]| volume = 13 | issue = 1 | pages = 20–31 | year = 2011 | pmid = 21031178| pmc = }}''|ref={{harvid|Ahrens|2011}}}}
and this was altered to
<span id="{{harvid|Ahrens|2011}}" class="citation">{{Cite journal | last1 = Ahrens | first1 = L. | title = Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate | doi = 10.1039/c0em00373e | journal = [[Journal of Environmental Monitoring]]| publisher = [[Royal Society of Chemistry]]| volume = 13 | issue = 1 | pages = 20–31 | year = 2011 | pmid = 21031178| pmc = }}</span>
but by using {{wikicite}} it could have been simpler:
{{wikicite|reference={{Cite journal | last1 = Ahrens | first1 = L. | title = Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate | doi = 10.1039/c0em00373e | journal = [[Journal of Environmental Monitoring]]| publisher = [[Royal Society of Chemistry]]| volume = 13 | issue = 1 | pages = 20–31 | year = 2011 | pmid = 21031178| pmc = }} |ref={{harvid|Ahrens|2011}}}}
It is wrongheaded to think that the citation hack ever worked as this citation from Fluorine shows:
{{citation/new|title=''{{Cite journal | last1 = Ahrens | first1 = L. | title = Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate | doi = 10.1039/c0em00373e | journal = [[Journal of Environmental Monitoring]]| publisher = [[Royal Society of Chemistry]]| volume = 13 | issue = 1 | pages = 20–31 | year = 2011 | pmid = 21031178| pmc = }}''|ref={{harvid|Ahrens|2011}}}}
'"`UNIQ--templatestyles-00000017-QINU`"'<cite id="CITEREFAhrens2011" class="citation cs2">''<span></span>'''"`UNIQ--templatestyles-00000016-QINU`"'<cite id="CITEREFAhrens2011" class="citation journal cs1">Ahrens, L. (2011). "Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate". ''[[Journal of Environmental Monitoring]]''. <b>13</b> (1). [[Royal Society of Chemistry]]: 20–31. [[doi (identifier)|doi]]:[https://doi.org/10.1039%2Fc0em00373e 10.1039/c0em00373e]. [[PMID (identifier)|PMID]] [https://pubmed.ncbi.nlm.nih.gov/21031178 21031178].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Environmental+Monitoring&rft.atitle=Polyfluoroalkyl+Compounds+in+the+Aquatic+Environment%3A+A+Review+of+Their+Occurrence+and+Fate&rft.volume=13&rft.issue=1&rft.pages=20-31&rft.date=2011&rft_id=info%3Adoi%2F10.1039%2Fc0em00373e&rft_id=info%3Apmid%2F21031178&rft.aulast=Ahrens&rft.aufirst=L.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+11" class="Z3988"></span>''<span></span>''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%7F%27%22%60UNIQ--templatestyles-00000016-QINU%60%22%27%7F%3Ccite+id%3D%22CITEREFAhrens2011%22+class%3D%22citation+journal+cs1%22%3EAhrens%2C+L.+%282011%29.+%22Polyfluoroalkyl+Compounds+in+the+Aquatic+Environment%3A+A+Review+of+Their+Occurrence+and+Fate%22.+Journal+of+Environmental+Monitoring.+%3Cb%3E13%3C%2Fb%3E+%281%29.+Royal+Society+of+Chemistry%3A+20%E2%80%9331.+doi%3A%5Bhttps%3A%2F%2Fdoi.org%2F10.1039%252Fc0em00373e+10.1039%2Fc0em00373e%5D.+PMID+%5Bhttps%3A%2F%2Fpubmed.ncbi.nlm.nih.gov%2F21031178+21031178%5D.%3C%2Fcite%3E%3Cspan+title%3D%22ctx_ver%3DZ39.88-2004%26rft_val_fmt%3Dinfo%253Aofi%252Ffmt%253Akev%253Amtx%253Ajournal%26rft.genre%3Darticle%26rft.jtitle%3DJournal%2Bof%2BEnvironmental%2BMonitoring%26rft.atitle%3DPolyfluoroalkyl%2BCompounds%2Bin%2Bthe%2BAquatic%2BEnvironment%253A%2BA%2BReview%2Bof%2BTheir%2BOccurrence%2Band%2BFate%26rft.volume%3D13%26rft.issue%3D1%26rft.pages%3D20-31%26rft.date%3D2011%26rft_id%3Dinfo%253Adoi%252F10.1039%252Fc0em00373e%26rft_id%3Dinfo%253Apmid%252F21031178%26rft.aulast%3DAhrens%26rft.aufirst%3DL.%26rfr_id%3Dinfo%253Asid%252Fen.wikipedia.org%253AModule%2Btalk%253ACitation%252FCS1%252FArchive%2B11%22+class%3D%22Z3988%22%3E%3C%2Fspan%3E&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+11" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:citation|citation]]}}</code>: </span><span class="cs1-visible-error citation-comment">External link in <code class="cs1-code"><code class="cs1-code">|title=</code></code> ([[Help:CS1 errors#param_has_ext_link|help]])</span>; <span class="cs1-visible-error citation-comment">templatestyles stripmarker in <code class="cs1-code">|title=</code> at position 3 ([[Help:CS1 errors#invisible_char|help]])</span>
There are two copies of the citation's metadata in that mass of stuff.
This form from Editor Mirokado is better because it produces only one copy of the metadata, but is more difficult to type:
<span id="{{harvid|Ahrens|2011}}" class="citation">{{Cite journal | last1 = Ahrens | first1 = L. | title = Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate | doi = 10.1039/c0em00373e | journal = [[Journal of Environmental Monitoring]]| publisher = [[Royal Society of Chemistry]]| volume = 13 | issue = 1 | pages = 20–31 | year = 2011 | pmid = 21031178| pmc = }}</span>
<span id="CITEREFAhrens2011" class="citation">'"`UNIQ--templatestyles-0000001B-QINU`"'<cite id="CITEREFAhrens2011" class="citation journal cs1">Ahrens, L. (2011). "Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate". ''[[Journal of Environmental Monitoring]]''. <b>13</b> (1). [[Royal Society of Chemistry]]: 20–31. [[doi (identifier)|doi]]:[https://doi.org/10.1039%2Fc0em00373e 10.1039/c0em00373e]. [[PMID (identifier)|PMID]] [https://pubmed.ncbi.nlm.nih.gov/21031178 21031178].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Environmental+Monitoring&rft.atitle=Polyfluoroalkyl+Compounds+in+the+Aquatic+Environment%3A+A+Review+of+Their+Occurrence+and+Fate&rft.volume=13&rft.issue=1&rft.pages=20-31&rft.date=2011&rft_id=info%3Adoi%2F10.1039%2Fc0em00373e&rft_id=info%3Apmid%2F21031178&rft.aulast=Ahrens&rft.aufirst=L.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+11" class="Z3988"></span></span>
This form from Editor Redrose64 is similar but adds an extra <span>...</span>:
{{wikicite|reference={{Cite journal | last1 = Ahrens | first1 = L. | title = Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate | doi = 10.1039/c0em00373e | journal = [[Journal of Environmental Monitoring]]| publisher = [[Royal Society of Chemistry]]| volume = 13 | issue = 1 | pages = 20–31 | year = 2011 | pmid = 21031178| pmc = }} |ref={{harvid|Ahrens|2011}}}}
'"`UNIQ--templatestyles-00000021-QINU`"'<cite class="citation wikicite" id=CITEREFAhrens2011>'"`UNIQ--templatestyles-00000022-QINU`"'<cite id="CITEREFAhrens2011" class="citation journal cs1">Ahrens, L. (2011). "Polyfluoroalkyl Compounds in the Aquatic Environment: A Review of Their Occurrence and Fate". ''[[Journal of Environmental Monitoring]]''. <b>13</b> (1). [[Royal Society of Chemistry]]: 20–31. [[doi (identifier)|doi]]:[https://doi.org/10.1039%2Fc0em00373e 10.1039/c0em00373e]. [[PMID (identifier)|PMID]] [https://pubmed.ncbi.nlm.nih.gov/21031178 21031178].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Environmental+Monitoring&rft.atitle=Polyfluoroalkyl+Compounds+in+the+Aquatic+Environment%3A+A+Review+of+Their+Occurrence+and+Fate&rft.volume=13&rft.issue=1&rft.pages=20-31&rft.date=2011&rft_id=info%3Adoi%2F10.1039%2Fc0em00373e&rft_id=info%3Apmid%2F21031178&rft.aulast=Ahrens&rft.aufirst=L.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+11" class="Z3988"></span></cite>
If this sort of hacking is necessary, choose either of the latter two. Don't use the first.
My suggestion adds an extra <span>...</span>, yes; but only compared to the original. When compared to Mirokado's technique, it's the same number of spans. The only technical difference is that one has the wikicite class, the other doesn't. --Redrose64 (talk) 15:20, 13 October 2014 (UTC)
Titles in CoinS data for books
For books, the template places the book title in rft.atitle and the chapter title in rft.btitle, which seems the wrong way round.[2]Kanguole14:20, 5 November 2014 (UTC)
I think you're right, it has been wrong forever. Thanks for that. Fixed in the sandbox.
'"`UNIQ--templatestyles-00000024-QINU`"'<cite class="citation book cs1">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+11" class="Z3988"></span>
Books published in Chinese have titles in Chinese characters, romanized titles in pinyin, and translated titles in English, e.g.
Wang, Li (1985). Hànyǔ Yǔyīn Shǐ 汉语语音史 [History of Chinese Phonetics] (in Chinese). Beijing: China Social Sciences Press. ISBN978-7-100-05390-7.
While the romanized title should be italicized, it is recommended at WP:MOS-ZH that characters not be italicized. However {{noitalic}} is not allowed within citation templates. A common expedient is an extra set of italic quotes, e.g. Hànyǔ Yǔyīn Shǐ ''汉语语音史'' in the above, but this seems brittle. So could these templates have an additional parameter, say |noitalic_title= or something, for a title in a non-roman script that should not be italicized? This would be in addition to |title=, which could be used for the romanized form (which would be italicized), and |trans-title=, for the English translation. Kanguole10:57, 10 July 2014 (UTC)
But the '''' workaround you suggested seems to work. For instance, it doesn't break things like |url=:
The two are semantically different: that discussion is about works with no title but a description, while this one is about works with two titles, one of which is in a non-roman script. Kanguole11:59, 10 September 2014 (UTC)
They are related because they both impact how Module:Citation/CS1 renders the value in |title=; clearly this is an under-the-hood relationship, but for those of us who might attempt a workable solution, keeping the two conversations separate is no benefit.
We already have a way to remove italics from titles of articles using {{Italic title}}, so it would be best to stay with a similar parameter name for consistency. How hard would it be to implement an optional |italic-title= (using the dash, as recently specified for multi-word parameters) with a default value of "yes" and an optional value of "no"? – Jonesey95 (talk) 14:47, 10 September 2014 (UTC)
But in Editor Kanguole's example, half of the title is italicized while the other half is not. Therein lies the problem. Which leads me to the question, why are both Chinese logograms and pinyin used in |title=? Are both required?
Some library catalogues will use the original title (in Chinese characters), while others will use the pinyin rendering of the title. The latter is more convenient for some purposes, but loses information. Kanguole15:35, 10 September 2014 (UTC)
I think in that case, I would put the "lossy" rendering(s), in this case both Pinyin and English, in |trans-title=, something like this:
Wang, Li (1985). 汉语语音史 [History of Chinese Phonetics (Hànyǔ Yǔyīn Shǐ)] (in Chinese). Beijing: China Social Sciences Press. ISBN978-7-100-05390-7.
|italic-title=no could be used to straighten the original Chinese title. I think that is clear enough to show a reader what's going on. – Jonesey95 (talk) 19:05, 10 September 2014 (UTC)
It would be pretty weird to put the Chinese pinyin in the English translation. Publications I've seen put it before the characters, formatted approximately as above. Kanguole16:41, 11 September 2014 (UTC)
The template {{asiantitle}} also renders the logogram title first followed by a transliteration in parentheses. {{Asiantitle}} should not be used in CS1 citation because of the COinS metadata problem that Editor Gadget850 describes above and addresses at Template talk:Asiantitle#CS1 templates.
At the moment, I'm not sure how to solve this problem. Likely it will involve some sort of new parameter which value would be concatenated to the value in |title= after italics have been applied. So the process for a title with both pinyin and logograms and would be:
COinS title = <logogram title> <pinyin title> -- create COinS metadata before formatting
Title = <pinyin title>
Title = ''<pinyin title>'' -- italics applied: pinyin title
Title = <logogram title> ''<pinyin title>'' -- concatenate logogram title: logogram title pinyin title
Title = [<url> <logogram title> ''<pinyin title>''] -- add external link (wikilink is similar)
Do we have a list of all languages that must not be italicized? Presumably Japanese and Korean are on that list. What others? Do these languages have transcribed equivalents as pinyin is to Chinese?
If we invent a new parameter, what do we call it? What restrictions apply to its use?
I think, that to be safe, it's better to specify the languages where italicisation is sensible, rather than those where it isn't. Any language which uses a Latin, Greek or Cyrillic script should be OK, anything else should be treated with caution. --Redrose64 (talk) 19:13, 11 September 2014 (UTC)
Point. I've tweaked my pseudo-process outline above to make more sense – it was actually completely wrong in its original state.
Perhaps for a parameter name we could use |translit-title= or |xlit-title=. I think I prefer the latter because |translit-title= is a bit close to |trans-title=.
I was thinking of putting the romanized title (to be italicized, e.g. pinyin) in |title= and the original non-roman, not-to-be italicized title in a new field. Are you proposing to do it the other way round? I guess that would follow {{asiantitle}}, though that doesn't seem to be widely used. I also think it's a bit more complicated: it would have the font of |title= varying depending on whether this other field was given a value. Kanguole14:01, 12 September 2014 (UTC)
Ah, you're right. And now I wonder if this ought not also apply to Hebrew and Arabic scripts as well With them we also have the right to left issue. Argh! But let's set those aside and just think about the Asian titles. Clearly we could create a parameter |asian-title= but then when we do get round to Hebrew or Arabic |asian-title= is not quite right. So something more generic: |logogram-title=, |logo-title=|lg-title= or some such? |title= would be assigned the romanized title.
Logogram is probably the simplest. Do we need this for chapter and author? As to directionality, we should be able to wrap it in <bdi>...</bdi> to isolate it from the title text-direction settings; by default <bdi> sets dir=auto. --Gadget850talk15:37, 12 September 2014 (UTC)
If, according to MOS, chapter titles are supposed to be rendered in quotes, not italics, then no, we don't need to do this for |chapter=. But, there is a peculiarity in the module such that when all three of |work=, |title=, and |chapter= are used, the formatting for |chapter= and |title= swap. This to me seems wrong and is properly the topic of another conversation. I see no need to add this functionality to |author= because that is not rendered in italics, right?
The common practice with author names is |last=Wang|first=Li 王力, which seems adequate. "logogram" is a bit narrow: hangul and kana don't fit, and nor do the non-Latin alphabets of Southeast and South Asia, which presumably also shouldn't be italicized. Kanguole16:49, 12 September 2014 (UTC)
So the initial hack was easier than I thought it would be:
{{cite book/new | title = Hànyǔ Yǔyīn Shǐ |script-title=汉语语音史 | trans-title = History of Chinese Phonetics | last = Wang | first = Li | author-link = Wang Li (linguist) | location = Beijing | publisher = China Social Sciences Press | year = 1985 | isbn = 978-7-100-05390-7 | language = Chinese |url=//example.com}}
Wang, Li (1985). 汉语语音史 [History of Chinese Phonetics] (in Chinese). Beijing: China Social Sciences Press. ISBN978-7-100-05390-7. {{cite book}}: Invalid |script-title=: missing prefix (help)
The formatting of {{asiantitle}} is a bit idiosyncratic. I just checked four English-languge books I have to hand that include both titles in their bibliographies, and they all put the pinyin title before the character title. As for the name, |nonlatin-title= or |nonitalic-title=? Kanguole17:43, 12 September 2014 (UTC)
|logogram= looks reasonable for some Asian languages. I am not a linguist, so all I know about logograms, graphemes, and phonograms comes from the WP articles about them. If there is demand after implementation, it should be straightforward to create aliases to |logogram= that respect and align with the linguistic and cultural differences between Chinese, Japanese, Arabic, Hebrew, Korean, and other languages that do not use variations on Roman alphabet letters for their written language. – Jonesey95 (talk) 17:39, 12 September 2014 (UTC)
'nonlatin' doesn't work either, since Greek, Cyrillic and some others have italic variants. 'nonitalic' would be abused by some who want some oddball formatting or just misunderstand the parameter because they don't read the documentation. --Gadget850talk17:55, 12 September 2014 (UTC)
The name of the parameter should have "title" in it, since this is only for titles. As for the rest, "nonitalic" is at least fairly straightforward about what is meant, as "scripts-that-lack-italics" is a bit long. Kanguole10:35, 13 September 2014 (UTC)
|non-italic-script-title= with an alias |nis-title=?
Should this functionality apply to the periodical parameters |journal=, |encyclopedia=, |work=, etc?
According to the logic and context of citations which include Mandarin, Japanese, Korean titles:
|title=
|not_italic_title= (alias: |no_i_title=) —yes/no flag value only
|En_cover_title= —optional extra but also better combined into a general |other_title= with free formatting, in other words non–essential and of much less priority for coding, because these English–'spin' type subtitles most commonly get published only on the covers for marketing purposes, not in the colophon (page) nor the official citation such as with the ISBN registering authority and often do not accurately translate fully and properly the actual primary title that is published in Mandarin, Japanese, Korean, etc..
|title_transliteration= (alias: |title_xlit=)
|title_trans= (title translation) —currently exists as the |trans-title= parameter.
—and the equivalents for titles of journals, encyclopaedias, works, series, conferences, newspapers, etc..
The key point to remember please: the proper title of the document, eg. a book, has been set by the author and publisher and authoritatively published in the book’s colophon (page) and authoritatively registered with the ISBN granting authority. In proper terms, in reality, for books, we WP editors do not have to decide which is the title, the choice was already made in the event of publishing; we have to read the colophon (page) of the book or document, and cross-check with the front cover and the ISBN granting library or authority. Hacking the title (mostly only us geeks doing so) for superficial purposes of rendering appearance is an entirely separate topic and direction to go in.
For example, most books published in Mandarin, Japanese or Korean have their actual proper titles in Hanzi, Kanji–Hiragana–Katakana and Hangul respectively. These books may or may not have been published with secondary English translation subtitles on the cover, usually only for marketing purposes, such as appeal to some Chinese, Japanese and Korean particular people who’ve adopted westernisation sensibilities. Etcetera. For more information of a professional standard refer for example to Extended Citation Style Language and its implementation in Multilingual Zotero, etc. --Macropneuma 04:42, 14 September 2014 (UTC) —correct parameter names, small revision edit—--Macropneuma02:23, 15 September 2014 (UTC)
I did not find any Wikipedia style rules or advice regarding the use of italics for titles in any non-Latin alphabets and script other than Chinese. For example, I didn't find any rules or advice on how to render a book title in Greek or Cyrillic letters. The Chicago Manual of Style 14th Edition has little to say on this either. About all the advice found there is for Russian, where it says (9.113, p. 347): "In the Cyrillic originals of these citations the author's name and the title are both set in ordinary type (called in Russian pryamoy, "upright"); the author's name, however, is letterspaced. The Cyrillic kursiv is used more sparingly than our italic—never for book titles." This leads me to two ideas:
Somewhere under WP:MOS there should be advice on the use of italics with non-Latin alphabets and scripts, in titles and perhaps elsewhere.
I think the policy should probably be to avoid italics for titles in any non-Latin alphabet and script; however, both the translations and transliterations of titles should be italicized whenever an English title would be italicized, e.g. names of books, magazines, films, long poems, etc.
With your evidence check based reasoning and point of considering all "non–Latin–alphabet languages in general" i agree. My previous message was coming from my experience and long consideration with those east Asian languages, not at all to exclude the more general point you put forward. --Macropneuma07:07, 14 September 2014 (UTC)
I agree that Japanese characters (kanji and kana) should not italicized. But if they aren't, don't we need another way to indicate that it's a title? {{Asiantitle}} has parameters for this. You can specify "j" for double corner brackets around a book title, or "jsgl" for single corner brackets around a chapter title. That is normal way this is done in Japan and agrees with the MOS at Japanese Wikipedia (著作物名). --Margin1522 (talk) 19:13, 14 September 2014 (UTC)
Yes, i agree, those are the proper ways in those languages, thus adding another level of consideration here. Once decided upon coding implementation of each of these language specific types of brackets per se is simpler than the more complex interactions of italics and non–italics with the titles, title_translations, title_transliterations and so on. Thanks Margin1522 for reminding us of these language specific types of brackets, i was on one step at a time here with my previous talk post. Instead of |not_italic_title= (—yes/no flag value only), we can use for example |non_italic_title= (alias: |non_i_title=) with the code flags for each different language or yes for simple non italics or no for explicitly specifying plain italics (if necessary for some reason, whatever). That’s a start for this next step here. No worries, many ways we can do this. --Macropneuma22:53, 14 September 2014 (UTC)
I just checked the way the Japanese cite templates handle this. They have a |和書 (washo, meaning "Japanese book") parameter that takes no value. For example {{cite journal|和書|... will put the single brackets around the article title and the double brackets around the journal name. If the parameter is absent, then it is handled just like the English template. --Margin1522 (talk) 23:08, 14 September 2014 (UTC)
Are you-all not describing what amounts to a style parameter? If we have a parameter (|logogram= but perhaps |script-title= is better because that can encompass a variety of non-Latin languages) we might have another parameter |script-title-style= that takes an ISO639-1 language code as its value. The language codes are unique and already defined so for each script we can have a 'style' that the module applies for the citation's title.
|title= – Usually Latin font title or a transcription
|script-title= – non-Latin title could be Hebrew, Chinese, Cyrillic, Greek, Malay, whatever
|script-title-style= – ISO639-1 language code that selects a predefined style for |script-title=; if empty or omitted no special style applied; if invalid value throws an error
Editor Margin1522 asked: don't we need another way to indicate that it's a title? Perhaps an initial way to do that might be to underscore |script-title= – you know, the way we did titles with typewriters before word processors: |script-title=汉语语音史 → 汉语语音史
We shouldn't base our styling on the conventions of Japanese-language (or Chinese-language) publications. The convention in the four English-language books I checked was to write titles of Chinese books and journals in the form Hànyǔ yǔyīn shǐ 汉语语音史 [History of Chinese phonetics]. Indeed the style sheet in Chinese History: A New Manual specifies this form. The italicized pinyin serves to mark the following characters as the title. Also, underlining can make the characters harder to read. Kanguole01:42, 15 September 2014 (UTC)
That's a good point. We should check the Monumenta Nipponica style guide to see what they recommend for Japanese titles in English publications.
Initially the idea of an ISO language code was the first thing that occurred to me. From a quick check at the Chinese Wikipedia, it seems (maybe) that they just write the title straight up, no text decoration and no extra characters. And of course no pinyin. The template has no field for that (or for a translation), and in footnotes we're supposed to be able to simply quote the original language. Under current policy anyway. But about ISO, other scripts might have have preferred styles. I have no idea what titles look like in Hebrew or Thai. The Japanese tend to avoid all kinds of text decoration for any purpose and use extra characters instead. The one exception is underlines. But I can't recall seeing underlines to indicate titles, so I'm not sure if readers would understand it. --Margin1522 (talk) 02:04, 15 September 2014 (UTC)
I checked the Monumenta Nipponica style guide, and they reommend the following, which is similar to the Chinese style sheet quoted above.
Murasaki shikibu nikki. 紫式部日記. In NKBT 19.
They give the romanized title, italicized, and add no-italic kanji after it. If we did this for titles, it would essentially be Kanguole's suggestion for an "asiantitle" field. Or whatever the field is named. One question: would it be possible to write a function to detect whether the title string contains any Asian characters? If so, then we could just not italicize that title and the immediate problem (italicized kanji) is solved without adding an extra parameter. Too much processing just for Asian characters? --Margin1522 (talk) 04:09, 15 September 2014 (UTC)
Italicized transliteration may identify the following characters as the title, but we may not always have a transliteration to use as a delimiter. To those of us who do not read Arabic or Thai or whatever, an author name, which in CS1 precedes the title, is essentially indistinguishable from the title when they are in the same script. I think that it is fairly common for English-only readers to understand that an underscore indicates title. That is somewhat reinforced here at enwiki by the way wikilinks work – hover the mouse pointer over a wikilink and you get underscored text, often the title of an article. True, non-English languages may eschew text decoration, but our purpose here is to serve the readers of enwiki.
I thought about auto-detecting characters and then acting accordingly. The immediate problem that my thought experiment couldn't easily overcome was: what happens when there is a mix of Latin and non-Latin script? Probably better to leave it to editors who (presumably) know what they are doing rather than rely on code to make the right determination for every case.
Because this is not just for Asian-language-only titles but for all non-Latin script titles, I think that we should place the script title (presumably the original title) ahead of transliterated and translated titles because the latter two derive from the original language title.
The author name is separated from the title by the year and a period. I would also argue that a romanized title should be very strongly recommended, because of the opacity of the non-Latin title to most readers. (Of course they may not know what the pinyin or romaji title means either, but at least they'll have an idea of its pronunciation, and may recognize some words.) Regarding the ordering, you propose to ignore the common treatment of Chinese and Japanese titles in English-language publications – are there any publications that use your preferred ordering? Kanguole12:52, 15 September 2014 (UTC)
Since dates aren't required, they aren't always present so the normal terminal punctuation may not be sufficient especially when titles heretofore have been distinctly styled either by italics or quotes. Yep, strong recommendation for transcribed titles is a must; that part goes in the template documentation.
CS1 is a general purpose tool and this feature, if it is ever implemented, must apply to more than just Asian-script titles. So, yeah, I am ignoring the common treatment you describe in favor of what I perceive to be a treatment that, while not perfect in all cases, is acceptable. It is entirely possible that as time progresses and we gain experience with the feature we can provide more nuanced language specific treatment. We aren't there yet.
I would like to define a minimal implementation solution that can be taken live. We can then gauge how editors react to it. There are too few who watch this page to make any assessment regarding this feature's use or acceptance in the broader community.
Chinese and Japanese titles are the principal use cases for this extension. Because titles in alphabetic scripts can usually be deduced from their standard romanization, style guides such as the Chicago Manual of Style recommend that non-specialist works use just the romanized title for titles in non-Latin scripts. But they make an exception for these two scripts (CMOS, 16th ed, 11.110): "Chinese and Japanese characters, immediately following the romanized version of the item they represent, are sometimes necessary to help readers identify references cited or terms used." We already place the characters after the romanization for authors' names; it would be consistent to do that for titles too. Kanguole23:30, 15 September 2014 (UTC)
So it looks like the simplest way to go is to provide a field where people can write a non-roman title and not italicise it. That is, everything above "Latin Ext-B" in UTF-8#Codepage_layout is straightup? As far as CJK goes that would be better than italics.
About the order of Romanization/Kanji, most of the Japanese on En Wikipedia uses {{nihongo}}, which has 2 main options: order (A) "English (Kanji Romanization)" and order (B) "Romanization (Kanji)". There is no option (C) for "Kanji (Romanization)". A typical real-life example on Wikipedia might be Eiichiro Oda. It has both (A) and (B) in the titles in the Works section, but not (C). So it looks like romanization should come first.
That said, I wonder whether editors will actually provide the romanization. We can certainly encourage it, but it is extra work. And sometimes you don't know. If a Japanese title contains a proper name it can take up to 1/2 hour of research on the Internet to discover how it's pronounced. Editors aren't going to do that. They'll just write the kanji, and I think that's OK too. --Margin1522 (talk) 06:44, 16 September 2014 (UTC)
Here is a comparison of the four versions of {{nihongo}} and {{asiantitle}}:
{{Nihongo|Tokyo Tower|東京タワー|Tōkyō tawā}} → Tokyo Tower (東京タワー, Tōkyō tawā) – translation, original language, transliteration
{{Nihongo2|東京タワー}} → 東京タワー – only original language so not applicable
{{Nihongo3|Tokyo Tower|東京タワー|Tōkyō tawā}} → Tōkyō tawā (東京タワー, Tokyo Tower) – transliteration, original language, translation
{{Nihongo4|Tokyo Tower|東京タワー|Tōkyō tawā}} → Tokyo Tower (東京タワー, Tōkyō tawā) – translation, original language, transliteration
In CS1, translation (|trans-title=) always follows the title. Ignoring the translations in the above templates, except for {{nihongo3}} original language precedes transliteration in the rendering.
Here's another interesting data point. Transclusion counts of the templates might be taken as an indication of preference by editors who use the templates. Yeah, I know they weren't created simultaneously so {{nihongo}} from 2006 has a big advantage over the others:
{{nihongo}} (2006) → 70515
{{nihongo3}} (2008) → 718
{{nihongo4}} (2012) → 186
{{asiantitle}} (2010) → 157
I have no idea if editors will provide romanization. Agreed that we should encourage it in the documentation; MOS:ROMANIZATION and the like.
So it appears that there is something of a conflict. Chicago Manual of Style vs. common usage on Wikipedia. CS1 is loosely based on CMOS and other published style guides but is ultimately driven by its users.
WP:MOSCHINA says to use pinyin (汉字) in running text and pinyin 汉字 for titles in citations, both of which are in line with CMOS. WP:MOSJAPAN has no guidance on citations. The usage of {{nihongo}} gives little information about citations, as most are used for the bolded title of articles (e.g. the above example in Tokyo Tower – Chinese articles use the {{zh}} template for a similar purpose). Most of the other uses of the template don't use all three parameters and few are in citations. I also noticed a lot of cases where people are putting romaji in the first parameter instead of the third. For example in Fist of the North Star we find
*{{cite book|title={{nihongo|Hokuto no Ken Kanzen Tokuhon|北斗の拳 完全読本||"The Complete Guide to Fist of the North Star"}}|ISBN=978-4-7966-5856-0}}
to obtain something similar to the style recommended by CMOS:
Hokuto no Ken Kanzen Tokuhon (北斗の拳 完全読本, "The Complete Guide to Fist of the North Star"). ISBN978-4-7966-5856-0.
Very well. I've changed |logogram= to |script-title= and Module:Citation/CS1/sandbox so that the rendered order is |title=transliteration, |script-title=original language|trans-title=translation. This change can be seen in the six citations above.
The six citations look good to me (except for the underline, I'm still a bit dubious about that). My version of CMOS is older and doesn't have that passage. Do they give any long examples? Maybe we need to consult a bibiliography with Chinese titles in a book edited by the U. of Chicago Press. That should settle it any questions about how they handle it.--Margin1522 (talk) 01:48, 18 September 2014 (UTC)
They include an example journal article citation in each language. That section of CMOS is reproduced here, wrapped in some commentary by the library. Elsewhere CMOS has examples of Arabic (11.100) and Russian (11.120), but for those languages they recommend using the transliterated title only. I'm also dubious about adding underlining, and when the title itself is a link, as in the above examples, one gets two underlines on mouseover. Kanguole09:18, 18 September 2014 (UTC)
At Help talk:Citation Style 1/Archive 6#Wikimarkup and COinS metadata I describe a proposed change to Module:Citation/CS1 that strips the common apostrophe markup from |title= so that it doesn't corrupt the COinS metadata. The change will allow editors to add this basic styling to titles or to 'undo' the default italic style of some CS1 templates.
Tōkyō tawā would be italicized in the normal way and 東京タワー would be straightup. This looks like the simplest solution yet, and the result would just as good as the extra field. If this happens I volunteer to add an explanation to WP:MOS-JP to encourage it, and discourage putting {{nihongo}} in citations.
The question is whether editors will actually do it. Many of them don't read the MOS, e.g. the editors coming over from the Japanese wiki to add information about current events. Perhaps we could lobby the author of AWB to add this to the list of things it checks. There are a lot of editors who use AWB to patrol new posts. We could ask them to fix any kanji in (new or existing) title strings that lack the double apostrophes. AWB already checks citations for invalid parameters. --Margin1522 (talk) 19:30, 18 September 2014 (UTC)
Not a complete solution, I think. Simply allowing the use of wikimarkup in |title= values, doesn't address right-to-left language scripts nor does it enforce consistent transcription-script-translation order.
I was just going to make the same comment on language isolation. This could be resolved by having the editor wrapp the Asian text in <bdi> and having the template strip it out, but that puts more on the editor and continues the slippery slope of using HTML inside the templates. --Gadget850talk12:41, 19 September 2014 (UTC)
This is unrelated to Asian, but is this the policy?
cite web
"Hongkongs Zukunft entscheidet sich auf der Straße" [The future of Hong Kong will be decided on the street]. Die Zeit (in German). 30 September 2014. {{cite web}}: Missing or empty |url= (help)
cite book
Hongkongs Zukunft entscheidet sich auf der Straße [Hong Kong's future will be decided on the street] (in German). 2014.
Policy? I don't know about that but it has been ever thus:
Cite web comparison
Wikitext
{{cite web|date=30 September 2014|language=German|title=Hongkongs Zukunft entscheidet sich auf der Straße|trans-title=The future of Hong Kong will be decided on the street|work=Die Zeit}}
Live
"Hongkongs Zukunft entscheidet sich auf der Straße" [The future of Hong Kong will be decided on the street]. Die Zeit (in German). 30 September 2014. {{cite web}}: Missing or empty |url= (help)
Sandbox
"Hongkongs Zukunft entscheidet sich auf der Straße" [The future of Hong Kong will be decided on the street]. Die Zeit (in German). 30 September 2014. {{cite web}}: Missing or empty |url= (help)
Cite book comparison
Wikitext
{{cite book|language=German|title=Hongkongs Zukunft entscheidet sich auf der Straße|trans-title=Hong Kong's future will be decided on the street|year=2014}}
Live
Hongkongs Zukunft entscheidet sich auf der Straße [Hong Kong's future will be decided on the street] (in German). 2014.
Sandbox
Hongkongs Zukunft entscheidet sich auf der Straße [Hong Kong's future will be decided on the street] (in German). 2014.
I see. If possible, could we consider no italics for translated titles, when the original title is given? That's what CMOS recommends, and I prefer it that way, also outside of Wikipedia. It also goes for capitalization. According to CMOS the translated title is just for information, so only the first word gets capitalized. (Although most editors seem to show a strong preference for treating the translated title as a real title, with title caps. So maybe they would prefer the italics too.) – Margin1522 (talk) 23:43, 30 September 2014 (UTC)
If it is important to you, I think that you should raise the issue at some other venue than this backwater talk page; there are 51 others watching us. Some of what I think you are asking for is beyond the abilities of Module:Citation/CS1. In your examples, for instance, CS1 would have to know that Hong Kong should be capitalized so the choice of title case or sentence case will need to be left to the editor. Rendering |trans-title= as undecorated text can be done.
Attention Trappist the monk. Malformed |title= parameter values, including those with italic markup in citations, are causing Lua errors. Examples:
{{cite book |last=Beller |first=Anne-Marie|title=''[http://www.mcfarlandpub.com/book-2.php?id=978-0-7864-3667-5%20 ''Mary Elizabeth Braddon: A Companion to the Mystery Fiction'']''|location=Jefferson, NC |publisher=McFarland |year=2012}}
{{Citation|last= Walker|first=Benjamin|year=1968|title=The Hindu world: an encyclopedic survey of Hinduism
(Lua error, and a few subsequent citations hidden, because this citation template was not closed)
{{cite book |last=Shattuck |first=Roger |title=''[http://books.google.com/books?vid=ISBN1568360487&id=9COPTtX16IIC&pg=PP1&lpg=PP1&ots=TKQrin2p4P&dq=%22forbidden+experiment%22&sig=FFI91sIU9yzIyP8yvBxO-1xATgU The Forbidden Experiment: The Story of the Wild Boy of Aveyron]'' |origyear=1980 |year=1994|publisher=Kodansha International |isbn=1-56836-048-7 }}
In case you can't see the error, it is "Lua error in Module:Citation/CS1 at line 741: invalid capture index." One might argue that these citations are malformed, but presumably they were displaying more or less correctly before the updates. – Jonesey95 (talk) 00:34, 13 October 2014 (UTC)
I have disabled two functions: strip_apostrophe_markup() and make_coins_title() which uses it.
I think I have fixed the problem. Once again, patterns in string.gsub() have bitten me, though more accurately, this time it is Lua magic characters in the original string when that string is used as a replacement. strip_apostrophe_markup() gets all text between matching italic or bold wikimarkup. It then replaces the original string (which includes the markup) with the text found inside the markup:
original string: ''test%20string'' – an italicized string; the %20 is a space character used in urls
the found string: test%20string
now, look in the original string for this pattern: ''test%20string'' and replace it with this: test%20string
In the originally released code, the pattern was not modified to escape the Lua magic characters: ^$().[]*+-?%. These characters have properties similar to those used in regular expressions. I fixed part of the problem after the 11 October 2014 update to prevent these magic characters from inappropriate action that was causing similar problems to those that caused the protected edit request. I didn't go far enough. I failed to realize that the replacement is also treated as a Lua pattern and not as a literal string. In my little example above, the substring %2 is treated as a capture identifier in the replacement. There isn't a capture 2, hence the big red error message.
I have created a function escape_lua_magic_chars() that causes string.gsub() to treat the magic characters in these pattern and replacement strings as literal characters so now, the example broken citations work as intended:
{{Citation/new|last= Walker|first=Benjamin|year=1968|title=The Hindu world: an encyclopedic survey of Hinduism
Unless there comes a flood of similarly broken cites this change will be made with the next update to the live module. I've fixed the one instance you found.
A question from non-professional (in terms of all the utm thing) - shouldn't all the Google Analytics things (like in the example) be tracked in some category so it later can be fixed? I think nobody knows, that it should be removed when used in citation. Or it is completely not needed? You gonna ask - how to track? I would say, that check could be added for strings like ?utm_source, &utm_medium, &utm_campaign etc. --Edgars2007 (talk/contribs) 18:33, 26 November 2014 (UTC)
I remember reading somewhere that this kind of tracking information should be stripped from |url= values. Just where that was, I no longer recall, nor can I find in the places that I looked. Still, detecting and categorizing pages with these kinds of urls shouldn't be too difficult if we decide that we should do it. Are there other tracking strings from sites other than Google (Amazon, etc) – large on-line vendors would seem to be the prime candidates?
Category:CS1 maint: Date and year is not an error category so pages that land in it are not flagged with error messages. This is because use of both was a requirement under {{citation/core}} to create correctly disambiguated CITEREF anchors for authors who published multiple works in the same year. Because separate |year= and |date= parameters are no longer required to support CITEREF anchor disambiguation, |year=, while still supported, can be removed when the value in |year= is the same as the year portion of |date= (|date=January 2008|year=2008). The year portions being the same, if the disambiguation character is moved to |date=, then too, |year= may be removed.
Thanks for explanation. Though without some sort of flag then you have to search through each of the refs to find which one is causing the problem. Keith D (talk) 16:54, 30 November 2014 (UTC)
True, but this is the sort of problem that can be easily attacked by an AWB script (which I have in the works) so that editors need not worry over much about 'fixing'.
I have come across this paper which is cited here and here on en-wp. The jstor value of 10.1086/515973 looks like a DOI but fails to resolve as such, so I set |jstor=10.1086/515973. This gets URL-encoded, turning / into %2F, which then means the link doesn't work (seems it would work if that encoding were not applied). So two questions please: is URL encoding of |jstor= deliberate/somehow required by other logic? I suppose it could be that JSTOR have failed to register a set of DOIs (other articles in same issue of journal don't resolve either), anybody know anything about these 10.1086 values? Thanks Rjwilmsi19:17, 26 November 2014 (UTC)
Can't say that I know anything about those identifiers. There is a flag set in Module:Citation/CS1/Configuration that for JSTOR is :encode = true. I don't know why it is that way. Documented code? What's that? Most JSTOR identifiers are simply a string of digits so uri encoding would seem to be unnecessary. As a test, I have changed the flag to false:
This does what it should do. Will it always work? Don't know. So here's the question: Do I revert this little change or do we leave it and see if anything breaks when I update the live module at week's end?
There are a couple of references at Serial Item and Contribution Identifier#References that might explain JSTOR identifiers, but irritatingly both are dead links. Browsing in JSTOR suggested to me that a high proportion of identifiers (for books at least a third) have the form "publisher_id/item_id" ("10.1086" in the example appears to be a publisher id) rather than just "item_id". The only non-alphanumeric characters in either part of the JSTOR id that I found were "." and "_". So (a) it's essential not to encode "/" (b) it's probably ok not to encode any part of a JSTOR id. Peter coxhead (talk) 21:58, 26 November 2014 (UTC)
I found the first dead link at archive.today here. It doesn't say much, only that JSTOR uses SICI. But about the JSTOR implementation, I did find this. See page 4 "SICIs in Active Use" for an explanation of how JSTOR URLs use SICI. – Margin1522 (talk) 08:56, 6 December 2014 (UTC)
Off topic
P.S. I hope the formatting error in Amos, Robert (2012), "Show Reports: Malvern Show", The Alpine Gardener, 80 (1): 80–83, where the article title is in italics not roman+quote marks, will be fixed this weekend. It's been around far too long in my view. Otherwise I'll join other editors in changing |title= to |contribution= when using {{Citation}} for journal articles. Peter coxhead (talk) 22:36, 26 November 2014 (UTC)
change |trans-title= and |trans-chapter= error messages to use hyphens instead of underscores;
these deprecated parameters are no longer supported: |albumlink=, |artist=, |cointerviewers=, |day=, |director=, |notestitle=, |publisherid=, |titleyear=;
|interviewer= and |interviewers= are now aliases of |others=;
The cite web template used to accept the section parameter, although I noticed in some articles that it now returns and error message for the chapter parameter. It would be useful if functionality for this is restored, because many databases and online textbooks have sections, some of which may be linked to directly. E.g., pubchem has direct section links, like this one: https://pubchem.ncbi.nlm.nih.gov/compound/3007?from=summary#section=Identification It may be better to just uncouple the chapter and section alias in general, since some textbook chapters include sections with headers. From searching the page code, I think the issues are coming from the lines that follow (this is the first time I've ever looked at CS1).
Looking at {{Cite web/old}} I do not see that it supported |section= or |chapter=. These would have fed into the meta-parameter |IncludedWorkTitle= but that is used for |title=. --Gadget850talk03:54, 6 December 2014 (UTC)
Er... I probably should have specified this earlier: when I said "used to" I meant mid-2014-ish, so the issue would have been in this module, not that template, assuming the template was deprecated by the date in the revision history. If it wasn't intended in this module, then it was probably just a misspecified line of code somewhere. An earlier version of this module was passing that parameter through to articles between the retrieval dates in the web citations with errors in this article permalink (Sept 2013-May 2014). If the functionality isn't restored, then I have to collapse many those cite webs into general links to 2 ginormous databases, which is a little bit of a pain in the ass for WP:V. Seppi333 (Insert 2¢ | Maintained) 21:36, 6 December 2014 (UTC)
If you want to link to a section within the Pubchem entry for a drug, why not use something like:
{{cite web |title=Amphetamine: Toxicity |url=http://pubchem.ncbi.nlm.nih.gov/compound/3007?from=summary#section=Toxicity |work=Pubchem Compound |publisher = National Center for Biotechnology Information |accessdate=6 December 2014}}
"Amphetamine: Toxicity". Pubchem Compound. National Center for Biotechnology Information. Retrieved 6 December 2014.
It seems to me that you can always use |title=TITLE: SECTION with the url pointing to the section. A citation with more than two "levels" is always difficult to format so that the levels are distinguished. If you have |section=Toxicity|title=Amphetamine|work=Pubchem Compound, how can they be formatted so the three levels are distinguished? Almost all citation styles provide for two levels: the lower being set in roman in quotes, the higher being set in italics. Peter coxhead (talk) 22:14, 6 December 2014 (UTC)
Since DrugBank is essentially encyclopedic in scope, cite it as such:
{{cite encyclopedia |section=Pharmacology |title=Dextroamphetamine |section-url=http://www.drugbank.ca/drugs/DB01576#pharmacology |encyclopedia=[[DrugBank]] |version=4.1 |publisher= University of Alberta |accessdate=10 April 2014 |date=6 December 2014}}
→"Pharmacology". Dextroamphetamine. DrugBank. 4.1. University of Alberta. 6 December 2014. Retrieved 10 April 2014.
With a somewhat significant rethink about what 'encyclopedia' means to CS1 and CS2 in the module? At present, |encyclopedia= is lumped together with |work=, |journal=, |newspaper=, and other similar 'periodical' aliases. The module uses |CitationClass= from the template's {{#invoke:}} to identify {{cite encyclopedia}}.
I'm not sure that an encyclopedia should necessarily be considered a periodical in the same sense as newspapers or journals. Perhaps we split off |encyclopedia= and |encyclopaedia= from the meta variable Periodical so that we can use that as a marker instead of or in addition to |CitationClass=. I'll think about this and propose a solution at Help talk:Citation Style 1.
As for Template:Citation#Republications, or edited quotations in a periodical article, that is a somewhat flawed example. The citation isn't to an affidavit but to a newspaper article that contains the affidavit. There is no 'Affidavit' heading. The 5 September date is not the date of the affidavit but the date that a justice certified that the affidavit had been copied it faithfully. The date should be 10 April 1871. Toohy is identified on the masthead as publisher not editor. Newspaper editors are generally not credited nor are publishers. And of course, in the article, the author of the affidavit is identified as Philip Klingon Smith. Too bad there isn't a Klingensmith article.
So, the example citation might be rewritten like this:
{{Citation
| last = Klingensmith
| first = Philip
| date = April 10, 1871
| place = Lincoln County, Nevada
| title = Mountain Meadows Massacre
| newspaper = Corinne Daily Reporter
| publication-date = September 24, 1872
| publication-place = Corinne, Utah
| volume = 5
| issue = 252
| page = 1
| url = http://udn.lib.utah.edu/u?/corinne,5359
}}
which gives:
Klingensmith, Philip (April 10, 1871), written at Lincoln County, Nevada, "Mountain Meadows Massacre", Corinne Daily Reporter, vol. 5, no. 252, Corinne, Utah (published September 24, 1872), p. 1
@Trappist the monk: I'm not convinced that "encyclopedia" is a good descriptor for citations with three "levels", which is the issue at hand. A good book citation can require section, chapter and (book) title without the book being an encyclopedia. A good web citation can require section, (page) title and website without treating the website as an encyclopedia. I suspect the deep problem is the extreme context sensitivity of |title= which makes it hard to error-check without additional information as provided by the "mode" of the cite templates.
I wonder if adding an optional parameter |mode= to {{citation}} might be one solution. It would then be possible to guarantee that {{citation |mode=XXX |...}} always behaved the same as {{cite XXX |...}} other than the three standard differences. It wouldn't interfere with existing uses of {{citation}}. Peter coxhead (talk) 21:10, 7 December 2014 (UTC)
I have moved your post out of my post. Except for position, it is unmolested.
I think that {{cite encyclopedia}} has three levels because that was a way out of a never-resolved quandary that still exists in the {{citation/core}} version where |title= from {{cite encyclopedia}} feeds {{citation/core}} parameters |Title= and |IncludedWorkTitle=. Is 'encyclopedia' the best descriptor? Perhaps not. But it is the one we have so if we move to make {{citation}} mimic {{cite encyclopedia}} then similar terminology is in order, isn't it?
It's possible that |mode= could perhaps have some benefit but for every place where Module:Citation/CS1 currently uses |CitationClass= it would be necessary to determine if it is appropriate to evaluate |mode= at that same place.
SourceOhWatchcontributed a tip about linking to a specific page inside a PDF using #page=123. Perhaps this module could be modified to automatically include that named anchor: if format contains "PDF" and url (or archiveurl or chapterurl) doesn't contain a named anchor, parse page or pages for the first page to link to and append it to the URL. – Minh Nguyễn💬23:14, 6 December 2014 (UTC)
Do you remember where that was? According to this, which is a link from the above thread, the client strips the hash string before sending the URI to the server. So if there are problems, would they be in processing of the hash string on the client side? It occurs to me now that another issue is that the displayed page may not seem to match the requested page number. This happens in Adobe Reader when the 123rd page (counting separately numbered TOC, etc.) is not same as page 123 (not counting front matter). – Margin1522 (talk) 07:05, 7 December 2014 (UTC)
Oh, that's a good point: most sources in PDF form would have front matter that would throw off the page numbering. So it's up to editors to put in the anchor. – Minh Nguyễn💬08:17, 7 December 2014 (UTC)
Shouldn't it be preferred that the value of |page= parameter (or {{rp}} template, by the way using |pages= wouldn't work) contains the page numeration as it's used in the actual PDF file? That way it could be used for generating anchors automatically. However, we can't rely on editors to use PDF numeration over the actual page numbers. — Dsimic (talk | contribs) 08:29, 7 December 2014 (UTC)
Actually, no. We should not alter the pagination of the original source to match the pagination of a courtesy copy hosted online in our citations. Because readers may have to consult a printed copy or a different online copy because the linked file is inaccessible to them, we cannot rely on the PDF's pagination of the source. You may want to note something at the end of the citation as a supplement, but not as a replacement.Imzadi 1979→09:27, 7 December 2014 (UTC)
Thanks for the clarification. However, please allow me to provide an example, just to make sure we're on the same page (no pun intended, hehe): a PDF file numbers pages as 1-1, 1-2, 2-1, etc., and doesn't respond well to page numbers such as 1, 2 or 3 when entered into the page number input field in Adobe Reader. Should we specify 1-2 or 2 as the |page= value? — Dsimic (talk | contribs) 09:48, 7 December 2014 (UTC)
For the reasons I outlined in my last comments, page 1-1, the page number as assigned by the original publishers of the source. If you wish, you could add an optional manually typed note as to what page number it is in the file, but the citation itself should be based upon what the publisher assigned, or in the case of unpaginated works, didn't assign. (Other style guides would say if the publisher didn't include page numbers to use "n.p." so that readers know the page number wasn't just omitted by accident.) Imzadi 1979→00:12, 8 December 2014 (UTC)
Makes sense, thanks, that's also what I usually do with PDF references. Perhaps I didn't explain it well in my initial description above. :) — Dsimic (talk | contribs) 02:17, 8 December 2014 (UTC)
Three notes. 1. The page number "2-1" as printed shall be mentioned in the parameter: |page=2-1. Using a different #page=123 would apply to the url only. 2. If the source is published in pdf only without print-only page numbers, then teh pdf-numbering is the page number right? 3. Is there a general rule on using an anchor in external source links? -DePiep (talk) 13:04, 14 December 2014 (UTC)
1. Correct. 2. |url=//<filename>.pdf#page=<page number>|page=<page number> 3. I don't know of any such proscription.
This sounds like it is acceptable to add this #page to the url (provided cite quality). But from this thread I got the impression (as in: "taste") that it was ill-advised to do so. For straightforward cases, can we use it in a cite? -DePiep (talk) 13:43, 14 December 2014 (UTC)
The thing that is ill-advised is automatically forming #page=<page number> from |page=<page number> when |url=//<filename>.pdf which was the question stated in the initial post of this discussion. It seems to me that editors are free to add the #page=<page number> to the content of |url= just as they are free to provide links in this form: |url=//en.wikipedia.org/wiki/Module_talk:Citation/CS1#PDF_page_links.
Hello! Well, it surely isn't "dependent on the server", as web servers generally have nothing to do with the URLs they're requested to serve. Of course, if a PDF file isn't served statically that's another story, but the majority of PDF files are served that way. It is browser-dependent, but specifying the page number through #page=123 shouldn't cause any harm. — Dsimic (talk | contribs) 08:00, 7 December 2014 (UTC)
If you want to include the PDF page number in |url=, then do so. If the server fails to deliver the PDF in the proper manner it should fallback to opening at the front page, as would opening a saved PDF. |page= should always be the page number printed on the page. You can also specify a PDF destination if the PDF has destinations configured, usually to chapter headings. --Gadget850talk16:50, 7 December 2014 (UTC)
But, it pretty much isn't up to the server to preserve the #page=n anchor – it could be lost only if the server performs a HTTP redirect, which is highly unlikely to happen while retrieving PDF files. And, that anchor is what the web browser relies on to display (scroll down to) the proper page, while the web server has nothing to do with the displaying/scrolling. — Dsimic (talk | contribs) 17:13, 7 December 2014 (UTC)
One thing that I have been thinking about is to add code that would change the external link icon to the pdf version when |url= does not have the .pdf file extension and when |format=pdf. Essentially, wrap the external link with <span class="PDFlink">...</span>:
-- Taking lua for a spin.
local p = {}
local citation = require( "Module:Citation/CS1" )
function p.lc_cite_journal(frame)
frame.args.CitationClass='journal'
return citation.citation( frame.args )
end
return p
This throws and error "Lua error in Module:Citation/CS1 at line 2523: attempt to call method 'getParent' (a nil value)."
I suspect what's happening is that in trying to pass in frame.args as a parameter, I'm actually passing in a single parameter that is a table and things are going south from there. What's the approved way of writing a wrapper script so that I'm able to munge a few parameters and then pass the parameter list along to citation()?
I recently created an article citing a journal with a publication date of "July/August 2000", which appears to cause this module to complain about the format. Does CS1 handle such date formats, and if so, how should it be specified in the citation template? (I've also tried "Jul/Aug 2000" with no success. Perhaps "July and August 2000"?) If the module cannot currently handle this format, could I request its addition, as I imagine its a common (or at least, not rare) journal date format. Example use at The Brownies' Book, specifically the reference "Jesse Fauset: Midwife to the Harlem Renaissance". Mindmatrix16:10, 29 December 2014 (UTC)
WP:DATERANGE does not allow the virgule as a separator in dates. That being so, Module:Citation/CS1 does not support the virgule as a separator. WP:DATERANGE specifies the use of the endash (spaced or unspaced depending on application) as the only allowed separator in date ranges.
OK. Note that "July–August 2000" works, but "July–August 2000" causes the module to complain. Feature, or bug? Mindmatrix17:36, 29 December 2014 (UTC)
I think of it as a bug. But then I'm not exactly normal; I was typing in IBM Generalized Markup Language, a predecessor of HTML, since the 1980s. I much prefer to type a standard HTML entity that is useful in many computing environments, rather than a template, since there is no assurance that the template will work anywhere other than the English Wikipedia. Jc3s5h (talk) 17:54, 29 December 2014 (UTC)
The date is encoded into the COinS metadata. When using the HTML entity ndash, the entity is injected into the metadata:
With the HTML entity, the date is July%26ndash%3BAugust+2000.
I don't know if the HTML entity can be converted, but the current implementation properly generates an error. We should expand the help to explain this. --Gadget850talk18:33, 29 December 2014 (UTC)
Protected edit request on 14 February 2015
This edit request to Module:Citation/CS1 has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
if string.len(first) == 2 and string.match(first,'%u%u') then return(first) end -- if first already initialized, return unchanged
The purpose of this function is to convert the name in |firstn= to initials so that it conforms to the Vancouver system formatted author list. If the first and middle names are already initials, the function reducetoinitials(first) will strip the middle initial returning only the first initial. The above proposed addition will check for this special case (a string two characters long and containing only upper case letters) and if it finds it, return the parameter value unchanged. Boghog (talk) 15:29, 14 February 2015 (UTC)
The removal of |authorformat=scap may cause those who really like small caps for authors in citations to switch to using {{aut}}, which is worse as it contaminates the metadata. Should the occurrence of this template inside a CS1/CS2 citation template also cause a visible error message? Peter coxhead (talk) 21:30, 15 February 2015 (UTC)
I'm copyediting an article for the current GOCE Blitz. Part of the work involves converting long citations that are currently in the text of the article to references. The citation templates have an argument for the author's article. But this source is in German, and English WP has no article about the author, although German WP does.
If this were an ordinary inline interlanguage link I'd use {{ill|de|Wılhelm Papɛ}} to get
But when I put that into {{cite book}} I get this:
Papɛ, W.; Benseler, G. E. (1875). Wörterbuch der griechischen Eigennamen [Dictionary of Greek Proper Names] (in German). F. Vieweg und sohn. Retrieved 20 February 2015. {{cite book}}: Check |author-link= value (help)
[proposals and discussions of workarounds omitted here]
So, my helpful fellow editors, you have solved the problem for now, but not for the next time such a situation arises. I think we need an additional couple of parameters that, like "template-doc-demo", can be added to any citation template (at least!) to do the work that {{ill}} does: "There's a page for this on another wiki." E.g.,
... and then, Gott mit uns, interwiki-for1, interwiki-name1, interwiki-for2..., for additional authors, editors, and who knows what else. Where should such a suggestion go? (Other than "where the sun don't shine", please!) --Thnidu (talk) 00:19, 21 February 2015 (UTC)
No error messages, but readers won't necessarily intuit what (de) actually means because it looks like it might be, perhaps, part of his name. We might leave the colon so that the linked author name looks like this: Papɛ W. (de:) but that isn't much better.
The tricky part about {{ill}} is this, from the documentation: "When the English article is created, the other language link won't be shown". That might be a challenge to program. – Jonesey95 (talk) 14:40, 21 February 2015 (UTC)
I'll take your word for that. As it is, I intend to give up (for now, at least) on using any tweak of |author-link=. Instead, I'll add a link after the {{cite}} and before </ref>, so the ref will display like this:
This edit request to Module:Citation/CS1 has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The behaviour of the quote= parameter has been changed, (in a recent edit), from plain un-formatted text, to wrapping it with <q>...</q> tags, which wrongly changes the text to all-italics. Quotations often contain italics of their own for Latin phrases, titles of works, translator added words in Bible quotes, etc. All-italics ruins everything.
Old code line 2074:
Quote = sepc .." " .. wrap( 'quoted-text', Quote );
New code line 2120:
Quote = sepc .." " .. wrap_style ('quoted-text', Quote ); -- wrap in <q>...</q> tags
Telpardec, can you please provide an example? Here's a {{cite book}} template that uses |quote=, and it does not show the quotation in italics (in my web browser):
"Chapter of book". Title of book. p. 45. This is a quotation from page 45.
Here's another one with italicized text within the quotation.
"Chapter of book". Title of book. p. 45. This is a verbatim quotation from page 45.
You could also try logging out of Wikipedia and then refreshing one of the pages that does not display correctly for you. If it looks fine, then something in your common.css file or a similar file may be causing italics for you (and not for others). – Jonesey95 (talk) 01:47, 23 January 2015 (UTC)
@Jonesey95 and Gadget850: Both the cite book and <q> examples above are all italics, with no difference for the word verbatim. According to w3schools: "The <q> tag defines a short quotation. Browsers normally insert quotation marks around the quotation." I made a test page on my local hard drive with the result that the <q> tag is normally ignored by my browser. It does not add quote marks or italics. I don't have any local CSS set. It is only here on Wikipedia that the <q> tag is producing all italics. It is the same logged out and purged. It is the same for Vector or MonoBook skin. Thanks for your help. —Telpardec TALK 07:05, 23 January 2015 (UTC)
@Telpardec: Aha. Looks like IE6 does not support <q>. The MediaWiki software has been stripping support for IE6, but we should be able to resolve this. My XP VM has IE8, so I can't test this immediately but this should work. Add this to your CSS:
Good detective work by both of you. Telpardec, I'm sure this has been suggested before, but a browser upgrade would probably serve you well. If there is a reason you need to keep IE at version 6, maybe Chrome or Firefox can become your dedicated browser for Wikipedia. – Jonesey95 (talk) 15:57, 23 January 2015 (UTC)
@Gadget850 and Jonesey95: Thanks. This machine cannot be upgraded further. The CSS fix above did not work because it did not have the q selector, like this:
q{font-style:normal}
That fix cancels the all italics for me while logged in, but there is still a problem for others. There is some rogue CSS somewhere that is wrongly changing <q> to italics. The correct behaviour for quote=, according to Help:Citation Style 1#Quote, is that the text should be "enclosed in quotes". Anyway. Thanks again. —Telpardec TALK 18:35, 23 January 2015 (UTC)
I updated the CSS rules above. I usually test this stuff, but I need to install a new XP VM to do so (and actually I just found a VM I can download instead of having to create it from scratch). Per Wikimedia Analytics - User Agent Breakdown by Browser, MSIE 6 accounts for 0.22% of all requests. A number of fixes for MSIE 6 have been removed from core MediaWiki and more are scheduled for removal.
Unlike others, I'm not going to tell you that IE sucks and you should switch. As a support professional, I understand that many users do not have a choice, either by limitations of their system, corporate policy or compatibility with other software. But MSIE 6 just does not support the modern web. Wikipedia is rapidly implementing CSS3 and HTML5 which is leaving older browsers unable to render a page as the editors intend; more at Internet Explorer 6. XP can upgrade to MSIE 8 and it will support Firefox, Chrome and others.
What do you mean by "the q property"? There is no property of that name in CSS - there are no single-letter properties, the shortest property names are all:, cue: and top: with three letters. The way that you've used q above is as a type selector matching the <q>...</q> element. Whether a browsers supports that element isn't to do with CSS, but HTML - the browser must be older than HTML 4.01. --Redrose64 (talk) 15:43, 24 January 2015 (UTC)
"Quotations often contain italics of their own for Latin phrases, titles of works, translator added words in Bible quotes, etc. All-italics ruins everything."
The asterisk is known as a "star hack", which causes all browswers to ignore that style, except Internet Explorer versions below IE8. The illegal CSS in this MediaWiki module is not limited in its affects to this template or Wikipedia alone, but undermines the integrity of all projects and languages where the <q> element is used; and therefore needs to be removed from the module ASAP. Thanks. —Telpardec TALK 10:22, 14 February 2015 (UTC)
Good detective work! Setting debug=true makes it more readable.[3] Which lets us see:
/* IE 6 and 7 lack support for quotes aroud the <q> element ('::before' and '::after' pseudoelements, 'quotes' property). Let's italicize it instead (using the star hack). */q{*font-style:italic;}
It is wrong now. That was part of the early interface CSS that was copied out of Vector and Monobook CSS into a separate "skins/common/commonInterface.css" file, which was later converted to the present ResourceLoader module. I don't see where (if anywhere) in the early interface the <q> tag was used. It needs to be removed from the interface module. Thanks Gadget850. —Telpardec TALK 12:45, 15 February 2015 (UTC)
As visible in ref 4 of Justin_Hayward-Young, a title beginning with a single quote triggers this kerning function so that the inserted double quote and the title's single quote don't blend together, which is fine, except that it also introduces a weird break in the link underline. The code calls out to cfg.presentation['kern_left'], which as a relative newcomer to this codebase I don't know where to find. Does anyone know why this kerning breaks the link underline, and if it can be fixed? I'd also be happy to take a stab at it myself if someone points me to the code actually doing the kerning. Personman (talk) 13:36, 25 February 2015 (UTC)
cfg.presentation['kern_left'] and cfg.presentation['kern_right'] are both defined in Module:Citation/CS1/Configuration. But, I don't think that the underscore gap is the fault of the module as this (clearly contrived) example shows:
[[Abraham Lincoln|{{" '}}Abe' Lincoln]] → "'Abe' Lincoln
The format of arxiv identifiers has changed, with the sequence number being padded to five digits from 2015 onward. This change doesn't seem to be implemented in the check, with valid arxiv IDs resulting in "Check |arxiv= value" warnings, for example here. Huon (talk) 13:22, 10 January 2015 (UTC)
FWIW, ReferenceBot (talk·contribs) is delivering error notices based on the CS1 error message to editors who add arXiv id's in citation templates that use the new id# format; so there may be users who don't understand what's going on with messages they are receiving and therefore leaving enquiries at the various help outlets. -- 65.94.40.137 (talk) 07:55, 11 January 2015 (UTC)
Reference Errors on 4 February
Hello, I'm ReferenceBot. I have automatically detected that an edit performed by you may have introduced errors in referencing. It is as follows:
ReferenceBot is still producing error messages, even though this is a valid arXiv ID, so the module is giving editors invalid user talk page messages. -- 70.51.200.101 (talk) 11:40, 5 February 2015 (UTC)
Ok, what should we do about that? Apparently, there are books out there in the wild world that are in multiple languages. I still don't know what it is that you're looking for.
Banga, Vita; Marina Levina; et al. (2007). Rīgas dievnami: Arhitektūra un māksla. Riga's Churches. Architecture and Art (in Latvian, German, English, and Russian). Riga: Zinātne, Apgads Mantojums. ISBN978-9984-823-00-3. OCLC217266501. {{cite book}}: Explicit use of et al. in: |author2= (help)
Some books are written in multiple languages. The WorldCat entry for the book listed above says that it is written in Latvian, but the entry also contains the following note: "Summary and captions in German, English, and Russian."
{{Citation/new | publisher = Darling, David J. | title = The Universal Book of Mathematics | url = http://books.google.de/books?id=nnpChqstvg0C&pg=PA70&dq=circular+prime&hl=de&ei=4TVMTLTOMYSD4Qag-MSaDA&sa=X&oi=book_result&ct=result&resnum=4&ved=0CDcQ6AEwAw#v=onepage&q=circular%20prime&f=false | accessdate = 25 July 2010 (see page 70)}}
I saw one of these in the wild yesterday but forgot to report it here. The error message was correct, but the display was wrong, as reported above. Thanks for fixing it in the sandbox. – Jonesey95 (talk) 17:37, 5 March 2015 (UTC)
@Wtmitchell: Who are these "et al" authors? further, who is the second Valdez? When I follow the link, it says "Maria Stella S. Valdez"; and when I look up various library category entries via ISBN978-971-23-4868-6, they mostly say the same or a small variant on that, e.g. "Valdez, Maria Stella S." - just one author. Open Library says "Maria Stella Sibal Valdez ; Angelita Geronimo Gonzales, coordinator." - the second of these sounds like an editor, but certainly isn't another Valdez. --Redrose64 (talk) 11:48, 26 March 2015 (UTC)
I looked up the book as well, thus I agree with Redrose64.
The anchor created by {{cite book}} is CITEREFValdezValdez which ignores "et al." (which is the proper capitalization and abbreviation), thus {{harvnb|Valdez|Valdez|2007}} would create the proper link. --Gadget850talk12:21, 26 March 2015 (UTC)
It sure would be nice to have a maintenance category for sfn/harvnb links that go nowhere. I have the javascript installed, so I fix them when I see them, but there are thousands of articles with broken links and (as far as I know) no systematic way to track them down. I have asked at VPT, but I was told that it wasn't possible. – Jonesey95 (talk) 13:26, 26 March 2015 (UTC)
There is no way to do that via personal CSS/JS. This would have to be added either to the site JS. Let me think on it a bit. --Gadget850talk13:30, 26 March 2015 (UTC)
The authorformat=scap/name-list-format=scap, producing smallcaps, is now producing an " Invalid |name-list-format=scap" error across a large number of articles. Anyone have any idea why? Simon Burchell (talk) 15:26, 15 February 2015 (UTC)
MOS smallcaps guidance seems more geared towards the body text of an article, and smallcaps in references helps author names stand out from the mass of text when looking up a reference. I find it ironic that supposedly there is no "house style" of referencing, yet widespread styles such as smallcaps are stamped out via citation templates. At any rate, I'm done with it. The citation template parameters are constantly changing, and I've reached my patience threshold with running to catch up. All the best, Simon Burchell (talk) 21:13, 15 February 2015 (UTC)
That's all very well for reading sentences or paragraphs of text, but when one is merely scanning for an author name I find that having smallcaps help pick out the author names for rapid identification of a cited source (which I admit becomes irrelevant if {{sfn}} is used). Simon Burchell (talk) 21:27, 15 February 2015 (UTC)
I think it is absolutely ridiculous to prohibit the use of small caps in references. What exactly is the rationale? What problems does it cause? And yes I agree with Simon that if supposedly we are free to choose our own citation style then we should also be free to use small caps for author names. The all caps readability argument is irrelevant since this is not about running prose but about making it easier to pick out author names in reference lists - something which is often done with small caps in professional publications. I will also, like Simon, consider to stop using citation templates all together.User:Maunus ·ʍaunus·snunɐw·18:52, 16 February 2015 (UTC)
You can certainly stop using templates, but that means you are not going to be adding citations to articles already using templates unless you have consensus to change per WP:CITEVAR. --Gadget850talk19:13, 16 February 2015 (UTC)
Wtf? How on earth is Gadget805s decision to unwatch this page my fault? As for being helpful that doesnt exactly seem like a fitting description of their interactions with Simon Burchell above or with myself.User:Maunus ·ʍaunus·snunɐw·02:01, 17 February 2015 (UTC)
Maunus / Simon, I have no strong opinion about the scap option. However, it seems to me that if you object to the result of the previous discussion, the best course of action is to express that objection at a broader forum. I would suggest Village Pump (policy) since this does seem to touch on how broadly the MOSCAPS guideline should be applied. This is a wiki, and the change to CS1 can be reverted if that is the consensus. Dragons flight (talk) 19:45, 16 February 2015 (UTC)
This RFC has been resolved in favor of leaving the citation module as it currently exists. Capitals and small caps are allowed only when the meaning of the words or letters is changed when caps are used. – Jonesey95 (talk) 16:50, 10 May 2015 (UTC)
Hi! See this task. We are wondering if there's a way to tell Cite templates in VE that they don't need to add the language parameter if the source language is the same than the wiki one. Do you think this is feasible, and most importantly, that it makes sense to do so? (AWBremoves that parameter anyway.) Thanks a lot for your input! --Elitre (WMF) (talk) 11:33, 30 April 2015 (UTC)
I don't use VE so I don't know anything about how it works. But is that really your question? The phabricator task doesn't mention VE.
If the question is should VE populate |language=English (or the ISO 639-1 code en) then I would say no, don't do it. Editors here complain about citation template clutter whether it's in the rendering (access dates or English language annotation) or in the wikitext. The exception – isn't there always an exception? – is when the source is in multiple languages: |language=fr, de, en, then you should include English in the |language= parameter.
I oversimplified :) mw:Citoid is a tool in VE which auto-generates references. It relies on Cite templates and TemplateData, so we're looking for a way to change the former or the latter to tell it to not populate that field, precisely for the reason you provided. Maybe now the Phabricator task makes more sense? Thank you! --Elitre (WMF) (talk) 12:32, 30 April 2015 (UTC)
I don't use Citoid or VE either, but those would be the places to focus. In one of them, you may be able to have some sort of explanatory note for editors that they should not populate |language= with the language of the WP that they are editing. – Jonesey95 (talk) 12:45, 30 April 2015 (UTC)
Doesn't Citoid create the cite template? If so, how could the template, which hasn't yet been created, tell citoid how it is to be populated? Why am I so confused?
@Trappist the monk and Jonesey95: Sorry for the confusion, possibly my fault for not explaining my suggestion clearly enough near the bottom of that phab task.
Briefly, the aim (of my suggestion) is to make our Module work the same way as the French Modules do - to not render the language if it's set to the local default (English) - for example, in this revision, the 1st and 2nd citations both include |langue = français, but that info isn't rendered in the reflist below. That fixes the issue of having a useless string of text shown to readers (I assume that's the main reason we automatically remove it, when someone includes it in a citation).
This would:
make the citation's language (meta-info) programatically available for researchers (rather than them having to just assume a missing language=..)
let Citoid freely add any detected language (without having to worry about exceptions)
Remove one task from the Checkwiki cleanup list at enwiki (thereby leading to fewer bot-edits like (half of the changes in) this diff)
I hope that's a bit clearer, and seems like a sensible course of action. [I tried searching for past discussions about this, but it could've been in dozens of locations, and the topic keywords are very common which makes it even harder! If you know of any details/discussions/edge-cases that need to be considered, please point them out. I'm not a developer, so am not sure what else needs to be considered. Thanks for your thoughts, and your previous work on this complex code. :) ] Quiddity (WMF) (talk) 18:27, 30 April 2015 (UTC)
The more-or-less equivalent code in en:WP's Module:Citation/CS1/sandbox (sandbox because it is slightly different from the current live module and til now was the intended update) is at line 1762. There, we look to see how many languages are listed in |language=. If only one language is listed and if that language is English or en then we add the page to Category:CS1 maint: English language specified and then go on to render the (in English) annotation text. We could, instead of or in addition to categorizing, simply return an empty string when English is the only language in the parameter value. That more-or-less mimics fr:WP.
As far as past conversations about the language parameter, those, if they exist, would most likely be in this page's archive or in the archives of Help talk:Citation Style 1. Or not. When I wrote Monkbot task 6 I adopted the philosophy stated in the box at {{en icon}}. If I remember correctly, that's the only place that I found that addressed the issue of English language annotation in en:WP.
There has been little to no reaction from CS1|2 template users with regard to the changes I've made to |language= support. Still, if your proposal is to procede, it might be best to, at the least, notice Help talk:Citation Style 1 with its 160 watchers since only 60 watch this page (and who probably are also watching H:CS1).
I also apologize for the confusion: my point instead was a bit different. I'm taking for granted that not having the language parameter at in the template (not just not having a redundant language code in the reflist) is what the community here currently desires and the reason why it gets deleted by bots. I'm not challenging the reasoning behind this, I'm asking if there's a way to achieve this by changing the template behaviour, if possible and, as I stated in my first post, if it really makes sense for everybody. If it doesn't, and Quiddity's suggestion makes more sense, or if you have a different one, great! We'd just like to understand what's everybody's preference, here. HTH. --Elitre (WMF) (talk) 19:32, 30 April 2015 (UTC)
I'm not sure I understand what you mean by changing the template behaviour. An editor (or Citoid) creates a CS1|2 template and Module:Citation/CS1 renders it. Here, we can't do anything about what editors or Citoid create. We can, though, decide how we render the citation that the reader sees. The fr:WP solution is to not display language annotation when the specified language is an acceptable form of French. The |language=English parameter is still in the wikitext. Is this what you mean by changing behavior?
What the French are doing is a partial solution - you wouldn't provide a redundant information, but you'd still need cleanup; if an empty string (when English is the only language in the parameter value) was returned, wouldn't editors here still instruct the bot to go and delete "language=en" from wikitext anyway? I think they would, unless they decided this is not an error which needs to be corrected anymore. Since bots at enwiki currently get rid of "language=en" entirely, I'm just wondering if there is a way to prevent that that parameter is added in the first place (if this is a desirable outcome, obviously, and only when the source language matches the wiki one). Again, we're just flagging this to understand whether something needs to be done, and by whom :) Best, --Elitre (WMF) (talk) 08:28, 1 May 2015 (UTC)
The only way to keep bots from deleting something is to deny them access to the wikitext. Automated tools that create CS1|2 templates place those templates into the wikitext. The template processing tool (here, Module:Citation/CS1) has no power to rewrite the template in wikitext; it can only read and act upon what it reads where that act is to translate the data contained in the template into a correctly rendered HTML citation for display in a reader's browser.
The only place to prevent |language= parameter insertion is at the inserter: Citoid or Visual Editor. The French solution handles the cases where the inserter is a human editor constructing CS1|2 citations and where the community have decided that language annotation for sources in the local WP language need not be displayed.
Elitre (WMF): I have changed the en:WP Module:Citation/CS1/sandbox so that citations at en:WP with |language=en or |language=English will not display the language annotation:
You know, thinking about how often WPMED folks (especially the translation task force) copy citations to other Wikipedias, it might be a good idea to keep the |language=en information. Maybe we should hide it, rather than removing it. WhatamIdoing (talk) 17:38, 5 May 2015 (UTC)
Hello, I'm ReferenceBot. I have automatically detected that an edit performed by you may have introduced errors in referencing. It is as follows: