Module talk:Citation/CS1

From Wikipedia, the free encyclopedia
Jump to: navigation, search

non-italic titles[edit]

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. ISBN 978-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. Kanguole 10:57, 10 July 2014 (UTC)

But the '''' workaround you suggested seems to work. For instance, it doesn't break things like |url=:
So why not just stick to using that? It Is Me Here t / c 10:33, 10 September 2014 (UTC)

Since the title is italicized, the nested italics are affecting the rendered markup. The span is not properly closed:

  • Without nested italics: <span class="citation book">''Hànyǔ Yǔyīn Shǐ 汉语语音史''.</span>
  • With nested italics: <span class="citation book">''Hànyǔ Yǔyīn Shǐ ''汉语语音史''<span />''

This is probably HTML Tidy at work. This can cause issues if the span connects to another.

And the CoiNs metdata now includes the encoded apostrophes (%27):

  • H%C3%A0ny%C7%94+Y%C7%94y%C4%ABn+Sh%C7%90+%27%27%E6%B1%89%E8%AF%AD%E8%AF%AD%E9%9F%B3%E5%8F%B2%27%27

We should resolve this in the module. Thoughts? --  Gadget850 talk 11:15, 10 September 2014 (UTC)

This appears to be related to Help talk:Citation Style 1#Untitled work which also seeks a mechanism to disable italics. It would be best if we could have one conversation in one place?
Trappist the monk (talk) 11:45, 10 September 2014 (UTC)
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. Kanguole 11: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.
Trappist the monk (talk) 12:14, 10 September 2014 (UTC)
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?
Trappist the monk (talk) 15:05, 10 September 2014 (UTC)
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. Kanguole 15: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. ISBN 978-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. Kanguole 16: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.
Trappist the monk (talk) 13:18, 12 September 2014 (UTC)

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:

  1. COinS title = <logogram title> <pinyin title> -- create COinS metadata before formatting
  2. Title = <pinyin title>
  3. Title = ''<pinyin title>'' -- italics applied: pinyin title
  4. Title = <logogram title> ''<pinyin title>'' -- concatenate logogram title: logogram title pinyin title
  5. 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?

Trappist the monk (talk) 17:56, 11 September 2014 (UTC)

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.
Trappist the monk (talk) 19:59, 11 September 2014 (UTC)
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=.
Trappist the monk (talk) 13:18, 12 September 2014 (UTC)
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. Kanguole 14: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.
Trappist the monk (talk) 14:49, 12 September 2014 (UTC)
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. --  Gadget850 talk 15: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?
Trappist the monk (talk) 16:15, 12 September 2014 (UTC)
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. Kanguole 16:49, 12 September 2014 (UTC)
Have you got a better name for the parameter?
Trappist the monk (talk) 17:11, 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=//}}


Wang, Li (1985). Hànyǔ Yǔyīn Shǐ 汉语语音史 [History of Chinese Phonetics] (in Chinese). Beijing: China Social Sciences Press. ISBN 978-7-100-05390-7. 

without |title=:

Wang, Li (1985). 汉语语音史 [History of Chinese Phonetics] (in Chinese). Beijing: China Social Sciences Press. ISBN 978-7-100-05390-7. 

without |title= and without |trans-title=:

Wang, Li (1985). 汉语语音史 (in Chinese). Beijing: China Social Sciences Press. ISBN 978-7-100-05390-7. 

I wonder if we should follow the example set by {{asiantitle}} and wrap the transliterated title in parentheses?

Trappist the monk (talk) 17:09, 12 September 2014 (UTC)

Couple more for completeness: without |trans-title=:

Wang, Li (1985). Hànyǔ Yǔyīn Shǐ 汉语语音史 (in Chinese). Beijing: China Social Sciences Press. ISBN 978-7-100-05390-7. 

without |script-title=:

Wang, Li (1985). Hànyǔ Yǔyīn Shǐ [History of Chinese Phonetics] (in Chinese). Beijing: China Social Sciences Press. ISBN 978-7-100-05390-7. 

without|script-title= and without |trans-title=:

Wang, Li (1985). Hànyǔ Yǔyīn Shǐ (in Chinese). Beijing: China Social Sciences Press. ISBN 978-7-100-05390-7. 

Trappist the monk (talk) 17:17, 12 September 2014 (UTC)

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=? Kanguole 17: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. --  Gadget850 talk 17: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. Kanguole 10: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?
Trappist the monk (talk) 11:28, 13 September 2014 (UTC)
I expect so – I've seen it with journal titles. Kanguole 15:18, 13 September 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── 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—--Macropneuma 02: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:

  1. Somewhere under WP:MOS there should be advice on the use of italics with non-Latin alphabets and scripts, in titles and perhaps elsewhere.
  2. 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.

In any event, I encourage this discussion to consider non-Latin-alphabet languages in general. —Anomalocaris (talk) 06:05, 14 September 2014 (UTC)

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. --Macropneuma 07:07, 14 September 2014 (UTC)
Wikipedia talk:Citing sources#Italics and non-Latin languages in titles
Trappist the monk (talk) 13:02, 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. --Macropneuma 22: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=汉语语音史汉语语音史
Trappist the monk (talk) 00:38, 15 September 2014 (UTC)
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. Kanguole 01: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)
Sorry, I take that back about the translation field. We do have the trans_title= field. --Margin1522 (talk) 02:15, 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.

Trappist the monk (talk) 10:06, 15 September 2014 (UTC)

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? Kanguole 12: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.
Trappist the monk (talk) 13:52, 15 September 2014 (UTC)
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. Kanguole 23: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}}:
  1. {{Nihongo|Tokyo Tower|東京タワー|Tōkyō tawā}} → Tokyo Tower (東京タワー Tōkyō tawā?) – translation, original language, transliteration
  2. {{Nihongo2|東京タワー}}東京タワー – only original language so not applicable
  3. {{Nihongo3|Tokyo Tower|東京タワー|Tōkyō tawā}}Tōkyō tawā (東京タワー?, Tokyo Tower) – transliteration, original language, translation
  4. {{Nihongo4|Tokyo Tower|東京タワー|Tōkyō tawā}} → Tokyo Tower (東京タワー Tōkyō tawā) – translation, original language, transliteration
  5. {{Asiantitle|東京タワー|Tōkyō tawā|Tokyo Tower|j}}東京タワー (Tōkyō tawā = Tokyo Tower) – original language, transliteration, translation
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.
Trappist the monk (talk) 11:55, 16 September 2014 (UTC)
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"). ISBN 978-4-7966-5856-0. 
So I don't think there's evidence of a widely-used Wikipedia style that conflicts with CMOS. Kanguole 17:28, 16 September 2014 (UTC)
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.
Trappist the monk (talk) 18:13, 16 September 2014 (UTC)
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. Kanguole 09:18, 18 September 2014 (UTC)
Thanks, that looks good. If citations could be made to look like that I would be happy. --Margin1522 (talk) 19:30, 18 September 2014 (UTC)

At Help talk:Citation Style 1#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.

Trappist the monk (talk) 12:54, 18 September 2014 (UTC)

So then could just ask editors to write this?
|title=Tōkyō tawā ''東京タワー'' |first=....
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.
Trappist the monk (talk) 12:34, 19 September 2014 (UTC)
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. --  Gadget850 talk 12:41, 19 September 2014 (UTC)

rtl language support in CS1 titles[edit]

I have split this off from Module talk:Citation/CS1#non-italic titles. It is related but I want to focus this discussion on right-to-left language support. |script-title= is a new parameter in the sandbox version of Module:Citation/CS1 Its purpose is to hold citation title text that must not be italicized in the final rendered citation. It is concatenated with the value in |title= which is to be italicized. See non-italic titles for the discussion that led to the creation of |script-title=. At the time of this writing, |script-title= is just hacked into the CS1 sandbox as a proof of concept. Its full use and purpose is not clearly defined. I am seeking a better name for this parameter. Ideas for a better name and for use definition and restrictions welcome.

The post that I split from non-italic titles begins here:

This citation comes from a discussion now in WP:VPT archive 129. I changed it from {{cite web}} to {{cite book}} so that |script-title= would apply because {{cite web}} doesn't italicize |title=). You'll notice that title and translated title are malformed:

Tova Green (6 May 2010). 12 ימים [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 

I added code to Module:Citation/CS1/sandbox to wrap |script-title= in <bdi>...</bdi> tags. The sandbox version of the citation renders correctly:

{{cite book/new |author=Tova Green |date=6 May 2010 |script-title=12 ימים|language=he |trans_title=13 days |publisher=Maybe So |url= |accessdate=15 May 2010}}
Tova Green (6 May 2010). 12 ימים [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 

I'm beginning to think that values assigned to |title= and |script-title= (or whatever it finally becomes) should be wrapped in <bdi>...</bdi> tags – the value assigned to |trans-title= is always supposed to be English so wrapping it seems unnecessary.

Trappist the monk (talk) 14:46, 13 September 2014 (UTC)

In Module:Citation/CS1/sandbox I have replaced |logogram= with |script-title=. All instances of |logogram= in the above post have also been replaced.
Trappist the monk (talk) 20:54, 16 September 2014 (UTC)
One problem is, it seems that IE and Safari don't support <bdi>. I wonder if it's needed. I visited the arabic C++ page and it looked the same in both Chrome and IE. LTR "C++" was handled properly in both, and I didn't see any bdi tags in the HTML or anything that looked like wrappers around "C++". Is is possible that the browser would just do the right thing with arabic text in the title field? At WC3, this page goes into some of the issues in wrapping elements in spans to bulletproof the code. It looks really hairy.--Margin1522 (talk) 02:54, 20 September 2014 (UTC)
According to this page, only IE doesn't support <bdi>...</bdi>. We're in the position of not really knowing what direction the value assigned to |script-title= might use. We could wrap |script-title= in <span dir=auto>...</span> but, yet again, IE doesn't support dir=auto. That, I think, leaves us with two options: do nothing and wait for IE to join the 21st century, or wrap |script-title= in <bdi>...</bdi>. In the former case, the problem that led to this discussion is a problem for everyone; in the latter, its only a problem for those who use IE. I think that we should use <bdi>...</bdi> because eventually, I presume, IE will get its act together.
Trappist the monk (talk) 13:50, 20 September 2014 (UTC)
Er, I followed your link, and it doesn't say that "only IE doesn't support <bdi>...</bdi>"; it says "Internet Explorer, Safari and Opera do not support bdi." --Redrose64 (talk) 15:28, 20 September 2014 (UTC)
Allow me to clarify what I think the that page says. I think that the first listed basic test, 'bdi has dir=auto by default' is the result that matters to us. Because the default dir=auto is how we will be using <bdi>...</bdi>, then it would seem that the basic test results indicate that all but IE 'support' <bdi>...</bdi>.
I have current versions of Chrome and Opera. Both of them render the Hebrew portion of this citation's title correctly:
Tova Green (6 May 2010). 12 ימים [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 
(where I understand that correctly is four Hebrew characters, a space, followed by '12' – reading left to right)
Anyone out there have current versions of Firefox, Safari, and IE? Run the test at the link above; for example click the link 'bdi has dir=auto by default'.
Trappist the monk (talk) 16:54, 20 September 2014 (UTC)
After looking into it some more, it seems that every browser implements the Unicode birectional algorithm, which normally works well. But it has trouble when neutral characters or characters with weak directionality (numbers) occur at the boundaries between opposite-direction runs. "12 ימים " might to be a special case of this. This thread about XeTeX and the bidi algorithm has an example of an arabic page about Lionel Messi, where the citations at the bottom of the page are messed up, even on Wikipedia. That looks like what we are trying to prevent. Wrapping the title in <bdi>...</bdi> would probably fix it. The title string would get the direction of its first strongly directional character and wouldn't be affected by neighboring strings.
The reason I still feel kind of reluctant to do it is, <bdi>...</bdi> is 11 bytes. With a lot of cites, that could add a considerable amount of data to everyone's download, on every page. Would it work to look at the first byte in the title string and wrap the title in <bdi>...</bdi> if it's a number or another weak character? --Margin1522 (talk) 22:30, 20 September 2014 (UTC)

For this citation:

  • {{cite book/new |author=Tova Green |date=6 May 2010 |script-title=12 ימים|language=he |trans_title=13 days |publisher=Maybe So |url= |accessdate=15 May 2010}}

With Firefox 33 and IE 11, I see 12 space followed by the Hebrew then [13 days]]. --  Gadget850 talk 23:21, 20 September 2014 (UTC)

Wrong capitalization in check for season names[edit]

The module apparently checks that season names are spelled Spring, Summer, Fall (or Autumn), or Winter. But season names are not capitalized (look them up in, for example, American Heritage Dictionary 3rd. ed.) Jc3s5h (talk) 05:29, 26 August 2014 (UTC)

@Jc3s5h: Prior discussions about seasons include:
On the other hand, the documentation at Help:Citation Style 1#Dates shows uncapitalized seasons.
Since CS1 is designed to conform with a subset of WP:DATESNO and WP:SEASON states "Seasons are uncapitalized", I suggest that either the CS1 module be changed to follow the MOS or CS1 documentation is added in various places to state why CS1 citations use capitalized months. Thanks! GoingBatty (talk) 13:55, 26 August 2014 (UTC)
There are a lot of words that are capitalized in citations that are not capitalized in running text or in the dictionary: words in article titles, words in journal or book titles, and more. Season names are the same. They would look ridiculous in lower case in a |date= or |issue= field.
Are you really suggesting that this would be a reasonable citation format?
P. E. Dant (summer 2002). "seasons, months, and days: what to do?". journal of capitalization 4 (2). 
I have posted a question at the MOS:DATE talk page. – Jonesey95 (talk) 13:52, 26 August 2014 (UTC)
  • The Chicago Manual of Style, 16th ed., section 14.180 "Journal Volume, Issue, and Date: Seasons, though not capitalized in running text (see 8.87), are capitalized in source citations." --  Gadget850 talk 23:08, 28 August 2014 (UTC)

Suggestion; if url="null" and PMID is valid then set URL to PMID-url[edit]

In the list of identifiers, PMID is one result that usually (if not always) results in a free full text of the citation. I'm not a programmer so I'm suggesting this in the form of a logical sentence: if 'url'="null" and PMID is valid (not flag "bad pmid") then set 'URL' can be set to PMID-url. It looks like this could be built into function 'buildlist'. ~Technophant (talk) 14:04, 28 August 2014 (UTC)

Free full text is probably the exception rather than the rule for citations that are indexed in PubMed. If a |pmid= parameter is present, then one link is already there. I don't see a particular advantage of creating a redundant link from the citation's title. Boghog (talk) 14:18, 28 August 2014 (UTC)
I bring this up because I tried to add a full-free text url that had a PMID link already and was reverted here. When I tried to complain about it I was told that it was a perfectly appropriate revert. I thought of this as an alternative. Google Scholar automatically gives links to full-free texts when available. I'm not sure if there's any other way for those to found and sorted than manually however. ~Technophant (talk) 14:35, 28 August 2014 (UTC)
Ah, in this case, the |pmc= parameter already does exactly what you want to do. PubMed Central by definition does contain the free full text. In addition, if |pmc= is present and |url= is empty, then the citation's title is automatically linked. Boghog (talk) 14:45, 28 August 2014 (UTC)
This then seems to just be my own confusion between PMC and PMID. There's a section of code prefaced with "--Account for the oddity that is {{cite journal}} with |pmc= set and |url= not set" that seems to do exactly what I was wishing for already in place. ~Technophant (talk) 15:42, 28 August 2014 (UTC)
Yes we have pmc= when free full text is available. Doc James (talk · contribs · email) (if I write on your page reply on mine) 21:37, 28 August 2014 (UTC)
I think the title of the article should only be linked to a free full text version (unless subscription is set to yes, but then only to full text version). Linking the title to the PMID entry does not provide full text access. If no url is set and a the PMC parameter is set the template automatically links the title. PMC is free full text. Both the PMID and DOI parameters link their entries and I think that is the appropriate place for those links not the title. - - MrBill3 (talk) 03:18, 29 August 2014 (UTC)
A consensus was developed here that if |pmc= is present, then the title should be linked because pmc provides full free text. Boghog (talk) 06:17, 29 August 2014 (UTC)

Changing the Zbl URL[edit]

Would it be possible to change, at /Configuration, the |zbl= URL from to E.g. for me, redirects to It Is Me Here t / c 11:46, 4 September 2014 (UTC)

The HTTP URL also appears under "JFM". It Is Me Here t / c 12:18, 9 September 2014 (UTC)
Have you discussed this change with the Wikipedia communities that are most likely users of these identifiers? If I make this change and something breaks it will be my fault.
Trappist the monk (talk) 12:34, 9 September 2014 (UTC)
Also {{zbl}} and {{citation/identifier}} which is still in use. --  Gadget850 talk 13:10, 9 September 2014 (UTC)
{{JFM}} and the CS1 |jfm= parameter also redirect. --  Gadget850 talk 13:51, 9 September 2014 (UTC)
I've now notified WP:WPMATH. It Is Me Here t / c 16:04, 9 September 2014 (UTC)
Seems correct: I land on URL too. Deltahedron (talk) 21:28, 9 September 2014 (UTC)

Ok. Done in the sandbox.

Title. JFM 1177.37036. Zbl 1177.37036. 

Trappist the monk (talk) 12:37, 13 September 2014 (UTC)

{{jfm}} and {{zbl}} templates also updated.

Trappist the monk (talk) 13:07, 13 September 2014 (UTC)

URL in title check[edit]

Could some form of check be made on title fields that include a URL? The URL is usually at the end of the title after something like "Read more". May be these could be categorised and a BOT set-up to remove this clutter. Thanks. Keith D (talk) 01:36, 8 September 2014 (UTC)

I don't think that I've seen what it is that I think you're describing. Is it common? Can you show some examples?
Trappist the monk (talk) 13:33, 8 September 2014 (UTC)
On some newspaper websites, if you drag the mouse over text like the headline, copy to clipboard, and then paste into an empty |title= parameter, you sometimes find that you've copied more than you intended. Among the extra text is often "Read more:" and a URL. I always delete the unintended extras, but there must be people who either didn't notice, or didn't realise that it was not part of what we want in a |title= --Redrose64 (talk) 14:09, 8 September 2014 (UTC)
Yeah, I've experienced that but have not yet seen such stuff left in citations. Does it happen enough that we should attempt to detect a uri scheme in the |title= parameter's value?
Trappist the monk (talk) 15:24, 8 September 2014 (UTC)
This sort of junk often shows up in the CS1 unnamed (or maybe the unsupported) parameter category, which I patrol every couple of days. Here are some examples: [1] [2]. Titles of articles from the Daily Mail often have this junk, although I don't see one in my edit history right now. – Jonesey95 (talk) 18:23, 8 September 2014 (UTC)
Probably over 300 at a guess, I have cleared about 30 in the last few days, example. Keith D (talk) 21:31, 8 September 2014 (UTC)

Support Format ISO 8601 dates[edit]

At Norwegian Bokmål Wikipedia we have added support for formatting ISO 8601 dates (YYYY-MM-DD) and recommend using them. If more wikipedias could support ISO 8601, it would be easier to copy citations from one wikipedia to another. It could also make life easier for bots that need to insert dates, or scripts relying on Citoid. Are there any objections to adding ISO 8601 date support on enwiki? Here's an example of how it could be done (with testcases), inspired by our implementation at nowiki. One possible problem is that any fixed output format like 'j M Y' might not confirm to WP:MOS#Choice_of_format. – Danmichaelo (talk) 16:58, 14 September 2014 (UTC)

I suspect that this will not be accepted at enwiki. There was a similar sort of thing in the old Wiki markup / {{citation/core}} days where the templates automatically converted from year-initial numeric dates to the user's preferred format. For a while. That functionality was removed.
Trappist the monk (talk) 17:37, 14 September 2014 (UTC)
The pertinent guideline is MOS:DATEUNIFY. --  Gadget850 talk 19:19, 14 September 2014 (UTC)
Ok, thanks for clarifying. – Danmichaelo (talk) 20:26, 14 September 2014 (UTC)
ISO 8601 does not allow the use of the Julian calendar, so any publication that bears a Julian calendar publication date could not be cited. On the surface Danmichaelo's post hints that the Norwegian Wikipedia suffers from Wikipedia:Recentism. Jc3s5h (talk) 22:46, 14 September 2014 (UTC)


I see from the template that {{PDFlink}} is in the process of being merged into CS1. The TfD discussion noted that wikipedia's CSS adds the PDF icon where an external link indicates the document is a pdf, however not all links will do this. Some (e.g. this one used on Ford Island) generate a pdf and force the browser to download it. Even for sites which don't force a download, sometimes the content type is displayed in the header, not the url. For resources like that we should have some way of indicating to the user that the resource is a PDF. How do we do that when the merger is complete with CS1? Protonk (talk) 14:26, 19 September 2014 (UTC)

The pdf icon is added when the file extension of the associated url is '.pdf. So [ Example] turns into this: Example – there is no such file, by the way. Your Ford Island example does not have the '.pdf' extension so Wikimedia can't know it's file format. To notify readers that the link is to a pdf file, use |format=pdf which gives: "Historic Hawaii" (pdf). 
There has been precious little discussion about merging {{PDFlink}} into CS1 so don't expect anything soon. {{PDFlink}} should not be used within CS1 templates.
Trappist the monk (talk) 15:06, 19 September 2014 (UTC)
The PDF icon is not accessible, thus visually impaired readers have no idea that it exists. A recent MediaWiki update removed all of the other icons (AVI, OGG, News, etc.) from the Vector skin and a more recent update removed the HTTPS icon. The PDF icon exists only because it is locally added. --  Gadget850 talk 18:04, 19 September 2014 (UTC)

Range of seasons in "date="[edit]

CS1 doesn't seem equipped to handle a range of seasons as the "date=" parameter; see for example here. I managed to get both a single season and a range of years displayed correctly, so I don't think it's me. Huon (talk) 20:35, 20 September 2014 (UTC)

When dates contain spaces (Winter 2014 has a space), separate the other date with space ndash space. Do not use {{ndash}} or &ndash;; like this:
{{cite book |title=Title |date=Winter 2013 – Spring 2014}}Title. Winter 2013 – Spring 2014. 
Trappist the monk (talk) 20:49, 20 September 2014 (UTC)
And is documented in the help page that was linked in the error message. You have the full error message display enabled, so you are seeing the error. --  Gadget850 talk 21:04, 20 September 2014 (UTC)
Not so well documented, I think. For example, it actually is ok to use {{ndash}}, it's {{spaced ndash}} that shouldn't be used. I'll tweak the help a bit.
Trappist the monk (talk) 21:12, 20 September 2014 (UTC)