Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite sign)
Jump to: navigation, search
Citation templates (conception)
Citation templates (reality)

message-id error[edit]

I've been trying to wrap my head around what causes an error in

|message-id= doesn't have < > characters. I'm not sure what "make sure that it contains @ between left and right identifiers" mean however, but |message-id=@bnews.uw-beave.451@ doesn't work. Headbomb {t · c · p · b} 12:31, 3 November 2017 (UTC)

@Headbomb: I think it means that the parameter should be of the form |message-id=foo@bar, rather like an email address - foo being the left identifier, and bar being the right. --Redrose64 🌹 (talk) 23:39, 3 November 2017 (UTC)
@Redrose64: so how do we fix the above? Headbomb {t · c · p · b} 01:36, 4 November 2017 (UTC)
No idea. --Redrose64 🌹 (talk) 08:53, 4 November 2017 (UTC)
In case anyone here is unaware, the format for message-id parameters comes from RFC 822. According to that format, the given message-ID is definitely invalid (it should look like an email address with a string of non-special characters (or a quoted string), an @, and a domain name). But on the other hand, it is the actual message-ID of an actual message. So maybe we shouldn't be so strict about what we demand for this field? —David Eppstein (talk) 07:21, 6 November 2017 (UTC)
Indeed. It is important that the source should be easily and unambiguously verified. The error message creates unnecessary confusion, as this is not a citation formatting error. The validation parameters for this field may be too strict. We shouldn't expect that all of the thousands of RFCs that IETF publishes are followed or applied in all situations. Relax the validation to reflect the real world, and perhaps add in the doc that the format specified in RFC 822 is the preferred one. 72.43.99.138 (talk) 16:10, 6 November 2017 (UTC)
I'm fine with the error being flagged by default, all that needs to be done is have a |ignore-message-ID-error=yes or like we do in case of ISBN errors that are nonetheless the ones that feature on book covers. Headbomb {t · c · p · b} 16:31, 6 November 2017 (UTC)
Any progress on relaxing this overly strict check? That standard was obviously not universally followed; see this message from 1983 which has "bnews.uw-beave.451" as a message-id (451@bnews.uw-beave intended?) -- Michael Bednarek (talk) 02:05, 29 November 2017 (UTC)
I'm not sure how we might relax the test. It works for the 500+ transclusions of {{cite newsgroup}} and adding a special test or exception for this single outlying example seems like a bit of work to little benefit. Until there a lot more examples where this non-standard style of message id is used for messages referenced in article space, I see no real reason to do anything.
At the moment, Category:CS1 errors: message-id is empty so it would appear that someone found a solution to the one example that was categorized.
Trappist the monk (talk) 11:54, 29 November 2017 (UTC)
That's fine with me. The message mentioned above was used in shar and User:Hecseur sensibly changed |message-id=… to |quote=message-id:…. Cheers, Michael Bednarek (talk) 13:06, 29 November 2017 (UTC)
Yeah, I saw it used that way over in Usenet so I assumed it'd be the best way to deal with it. Hecseur (talk) 15:03, 29 November 2017 (UTC)

Semicolon with single author and "et al."[edit]

Using the {{cite web}} template, should there be a semicolon in a reference starting "Nuss, M.; et al. ..."? Example at this permalinked page. In regular English we wouldn't say "Nuss, M.; and others". Am I understanding this correctly? Can the semicolon be removed?  SchreiberBike | ⌨  18:09, 22 November 2017 (UTC)

AFAICT, there are only two editors for that page, it reads: "[editors: Landry, B., Nuss, M.]", so I'm not sure why the et al. is necessary. FWIW, CMOS17 reads
  • [§14.76] For works with more than ten authors—more common in the natural sciences—Chicago recommends the policy followed by the American Naturalist (see bibliog. 5): only the first seven should be listed in the bibliography, followed by et al. (Where space is limited, the policy of the American Medical Association may be followed: up to six authors’ names are listed; if there are more than six, only the first three are listed, followed by et al.)
  • [§6.20] The abbreviation et al. (et alia [neut.], et alii [masc.], or et aliae [fem.], literally “and others”), whether used in regular text or (more often) in bibliographical references, should be treated like etc. If et al. follows a single item, however (e.g., “Jones et al.”), it requires no preceding comma.
  • [§6.60] When items in a series themselves contain internal punctuation, separating the items with semicolons can aid clarity.
It's just a bit weird because there's only one editor before the "et al." but the semicolon makes sense if it's preceded by multiple names I think. Umimmak (talk) 19:17, 22 November 2017 (UTC)
This page lists their authors as "Nuss, M., B. Landry, R. Mally, F. Vegliante, A. Tränkner, F. Bauer, J. Hayden, A. Segerer, R. Schouten, H. Li, T. Trofimova, M. A. Solis, J. De Prins & W. Speidel". I couldn't find "[editors: Landry, B., Nuss, M.]". Et al. seemed appropriate rather than listing all 14. I tried listing them all and using |display-authors=1, but that has the same problem with the semicolon. I suppose I could use |display-authors=2 or some other number, then it would make sense to have the semicolon. It's a frequently used reference on Wikipedia and making the list as long as Chicago suggests above seems excessive.  SchreiberBike | ⌨  19:45, 22 November 2017 (UTC)
I couldn't find "[editors: Landry, B., Nuss, M.]" FWIW, Landry and Nuss were the editors involved for the Pseudocatharylla faduguella entry (I'd link it but this website doesn't seem to have permalinks? Umimmak (talk) 20:23, 22 November 2017 (UTC)
Thanks. I see now. Since it's impossible to link to individual pages in that database I thought the longer list was more appropriate.  SchreiberBike | ⌨  20:32, 22 November 2017 (UTC)
The single-author plus "et al." form should NOT be used in a full citation, as that is incomplete characterization of the source and its authorship. (It also suggests that the editor was too lazy to list at least three more authors, which validly raises a question of whether anything else has been scamped.) In all cases at least the first four authors should be listed (four, because that is where {harv} automatically switches to the "et al." form), and display-authors to three or more. Any less short changes the reader, and suggests a certain sloppiness.
As I recall, the recommended form for truncating a long list of authors in a full citation is "and N others" (where "N" is the appropriate number). In this regard the action of display-authors is incorrect. Use of "et al." is only for short cites, like "Smith, et al., 2000". Note the use of the comma; I believe the semicolon is incorrect here. ~ J. Johnson (JJ) (talk) 21:12, 22 November 2017 (UTC)
One author + et al. is a valid citation style, not laziness. Listing 3 authors out of 234 vs 1 out of 234 makes no difference. Headbomb {t · c · p · b} 21:25, 22 November 2017 (UTC)
By default, the CS1 templates separate author names with semicolons. Authors' first and last names are separated by commas. For display options, see #Display options. – Jonesey95 (talk) 22:20, 22 November 2017 (UTC)
Bullshit. "234" is a strawman argument, and even a red-herring, as I am NOT talking about entering 234 authors. I am talking about as many as four. If some editor can't take the trouble to list just that many they are undercutting WP:V, and showing a lack of due care and effort.
Yes, "one author + et al. is valid citation style", but only in the context of a short citation (short cite), such as "Smith, et al., 2000". Which should connect to a full citation, which contains the full bibliographic details, such as co-authors (up to some reasonable number), along with the authors' first names or initials. (Note that, for short cites, two authors + et al. is also acceptable, where the single author and year is ambiguous.)
Jonesey, are you paying attention? (I will go back and highlight portions of my prior comment to make it clearer.) Of course cs1 separates the authors by semicolons, and uses a comma where each author's surname is inverted from the rest of that individual author's name. That is the standard and accepted form for full citations, and I have said nothing contrary to that. Where the semicolon is incorrect is in short citations, where only the surnames (last names) are used. ~ J. Johnson (JJ) (talk) 23:35, 22 November 2017 (UTC)
No, one author + et al is a valid style for 'long/full' citations as well. There's absolutely no reason for why the n in author-n has to exceed a certain value before display the et al., it makes zero difference if you list the first 4 authors of 200, or the first author of 200. Some style guides say list 3 before the et al., others say list 6, and yet others say list 1. Headbomb {t · c · p · b} 01:16, 23 November 2017 (UTC)
Where "one author + et al." is considered valid for a full citation is in various journals where space is reckoned expensive. In the same context they also routinely abbreviate titles, which is something we do not do here, space not being limited.
You say "There's absolutely no reason for why the n in author-n has to exceed a certain value", but that is false. There is a very good reason to include at least four authors: so that cs1 and harv can do their CITEREF magic. Another even better reason is that many authors write more than one co-authored article in a year, and leaving out all the coauthors can make it harder to find the right article. There is also a good reason for listing all co-authors (well, up to a dozen or so): senior researchers often put their names at the end (so that their co-authors can have more credit), or alphabetization may put a very notable contributor well down the list, and shorting the list of authors means that people familiar with the subject might not recognize the significance of the contributors. ~ J. Johnson (JJ) (talk) 23:01, 25 November 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── No CS1/harv/CITEREF magic depends on what the N of truncation is. Which of

  • Aaij, R.; et al. (LHCb Collaboration) (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006. 
  • Aaij, R.; Adeva, B.; Adinolfi; et al. (LHCb Collaboration) (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006. 
  • Aaij, R.; Adeva, B.; Adinolfi, M.; Adrover, C.; Affolder, A.; Ajaltouni; et al. (LHCb Collaboration) (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006. 
  • Aaij, R.; Adeva, B.; Adinolfi, M.; Adrover, C.; Affolder, A.; Ajaltouni, Z.; Albrecht, J.; Alessio, F.; Alexander, M.; Alvarez Cartelle, P.; Alves, A.A.; Amato, S.; Amhis, Y.; Amoraal, J.; Anderson, J.; Appleby, R.B.; Aquines Gutierrez, O.; Arrabito, L.; Artuso, M.; Aslanides, E.; Auriemma, G.; Bachmann, S.; Bailey, D.S.; Balagura, V.; Baldini, W.; Barlow, R.J.; Barschel, C.; Barsuk, S.; Bates, A.; Bauer, C.; Bauer, Th.; Bay, A.; Bediaga, I.; Belous, K.; Belyaev, I.; Ben-Haim, E.; Benayoun, M.; Bencivenni, G.; Bernet, R.; Bettler, M.-O.; van Beuzekom, M.; Bifani, S.; Bizzeti, A.; Bjørnstad, P.M.; Blake, T.; Blanc, F.; Blanks, C.; Blouw, J.; Blusk, S.; Bobrov, A.; Bocci, V.; Bondar, A.; Bondar, N.; Bonivento, W.; Borghi, S.; Borgia, A.; Bos, E.; Bowcock, T.J.V.; Bozzi, C.; Brambach, T.; van den Brand, J.; Bressieux, J.; Brisbane, S.; Britsch, M.; Britton, T.; Brook, N.H.; Brown, H.; Büchler-Germann, A.; Bursche, A.; Buytaert, J.; Cadeddu, S.; Caicedo Carvajal, J.M.; Callot, O.; Calvi, M.; Calvo Gomez, M.; Camboni, A.; Camilleri, L.; Campana, P.; Capon, G.; Carbone, A.; Carboni, G.; Cardinale, R.; Cardini, A.; Carson, L.; Carvalho Akiba, K.; Casse, G.; Cattaneo, M.; Charles, M.; Charpentier, Ph.; Chiapolini, N.; Cid Vidal, X.; Clark, P.J.; Clarke, P.E.L.; Clemencic, M.; Cliff, H.V.; Closier, J.; Coca, C.; Coco, V.; Cogan, J.; Collins, P.; Constantin, F.; Conti, G.; Contu, A.; Coombes, M.; Corti, G.; Cowan, G.A.; Currie, R.; DʼAlmagne, B.; DʼAmbrosio, C.; Da Silva, W.; David, P.; De Bonis, I.; De Capua, S.; De Cian, M.; De Lorenzi, F.; De Miranda, J.M.; De Paula, L.; De Simone, P.; Decamp, D.; Degaudenzi, H.; Deissenroth, M.; Del Buono, L.; Deplano, C.; Deschamps, O.; Dettori, F.; Dickens, J.; Dijkstra, H.; Dima, M.; Diniz Batista, P.; Donleavy, S.; Dossett, D.; Dovbnya, A.; Dupertuis, F.; Dzhelyadin, R.; Eames, C.; Easo, S.; Egede, U.; Egorychev, V.; Eidelman, S.; van Eijk, D.; Eisele, F.; Eisenhardt, S.; Eklund, L.; dʼEnterria, D.G.; Esperante Pereira, D.; Estève, L.; Fanchini, E.; Färber, C.; Fardell, G.; Farinelli, C.; Farry, S.; Fave, V.; Fernandez Albor, V.; Ferro-Luzzi, M.; Filippov, S.; Fitzpatrick, C.; Fontanelli, F.; Forty, R.; Frank, M.; Frei, C.; Frosini, M.; Fungueirino Pazos, J.L.; Furcas, S.; Gallas Torreira, A.; Galli, D.; Gandelman, M.; Gandini, P.; Gao, Y.; Garnier, J.-C.; Garofoli, J.; Garrido, L.; Gaspar, C.; Gauvin, N.; Gersabeck, M.; Gershon, T.; Ghez, Ph.; Gibson, V.; Gligorov, V.V.; Göbel, C.; Golubkov, D.; Golutvin, A.; Gomes, A.; Gordon, H.; Grabalosa Gándara, M.; Graciani Diaz, R.; Granado Cardoso, L.A.; Graugés, E.; Graziani, G.; Grecu, A.; Gregson, S.; Gui, B.; Gushchin, E.; Guz, Yu.; Gys, T.; Haefeli, G.; Haines, S.C.; Hampson, T.; Hansmann-Menzemer, S.; Harji, R.; Harnew, N.; Harrison, P.F.; He, J.; Hennessy, K.; Henrard, P.; Hernando Morata, J.A.; van Herwijnen, E.; Hicheur, A.; Hicks, E.; Hofmann, W.; Holubyev, K.; Hopchev, P.; Hulsbergen, W.; Hunt, P.; Huse, T.; Huston, R.S.; Hutchcroft, D.; Iakovenko, V.; Iglesias Escudero, C.; Ilten, P.; Imong, J.; Jacobsson, R.; Jahjah Hussein, M.; Jans, E.; Jansen, F.; Jaton, P.; Jean-Marie, B.; Jing, F.; John, M.; Johnson, D.; Jones, C.R.; Jost, B.; Kapusta, F.; Karbach, T.M.; Keaveney, J.; Kerzel, U.; Ketel, T.; Keune, A.; Khanji, B.; Kim, Y.M.; Knecht, M.; Koblitz, S.; Konoplyannikov, A.; Koppenburg, P.; Kozlinskiy, A.; Kravchuk, L.; Krocker, G.; Krokovny, P.; Kruse, F.; Kruzelecki, K.; Kucharczyk, M.; Kukulak, S.; Kumar, R.; Kvaratskheliya, T.; La Thi, V.N.; Lacarrere, D.; Lafferty, G.; Lai, A.; Lambert, R.W.; Lanfranchi, G.; Langenbruch, C.; Latham, T.; Le Gac, R.; van Leerdam, J.; Lees, J.-P.; Lefèvre, R.; Leflat, A.; Lefrançois, J.; Leroy, O.; Lesiak, T.; Li, L.; Li, Y.Y.; Li Gioi, L.; Lieng, M.; Liles, M.; Lindner, R.; Linn, C.; Liu, B.; Liu, G.; Lopes, J.H.; Lopez Asamar, E.; Lopez-March, N.; Luisier, J.; Mʼcharek, B.; Machefert, F.; Machikhiliyan, I.V.; Maciuc, F.; Maev, O.; Magnin, J.; Maier, A.; Malde, S.; Mamunur, R.M.D.; Manca, G.; Mancinelli, G.; Mangiafave, N.; Marconi, U.; Märki, R.; Marks, J.; Martellotti, G.; Martens, A.; Martin, L.; Martin Sanchez, A.; Martinez Santos, D.; Massafferri, A.; Mathe, Z.; Matteuzzi, C.; Matveev, M.; Matveev, V.; Maurice, E.; Maynard, B.; Mazurov, A.; McGregor, G.; McNulty, R.; Mclean, C.; Meissner, M.; Merk, M.; Merkel, J.; Merkin, M.; Messi, R.; Miglioranzi, S.; Milanes, D.A.; Minard, M.-N.; Monteil, S.; Moran, D.; Morawski, P.; Morris, J.V.; Mountain, R.; Mous, I.; Muheim, F.; Müller, K.; Muresan, R.; Murtas, F.; Muryn, B.; Musy, M.; Mylroie-Smith, J.; Naik, P.; Nakada, T.; Nandakumar, R.; Nardulli, J.; Nedos, M.; Needham, M.; Neufeld, N.; Nicol, M.; Nies, S.; Niess, V.; Nikitin, N.; Oblakowska-Mucha, A.; Obraztsov, V.; Oggero, S.; Okhrimenko, O.; Oldeman, R.; Orlandea, M.; Ostankov, A.; Pal, B.; Palacios, J.; Palutan, M.; Panman, J.; Papanestis, A.; Pappagallo, M.; Parkes, C.; Parkinson, C.J.; Passaleva, G.; Patel, G.D.; Patel, M.; Paterson, S.K.; Patrick, G.N.; Patrignani, C.; Pavel-Nicorescu, C.; Pazos Alvarez, A.; Pellegrino, A.; Penso, G.; Pepe Altarelli, M.; Perazzini, S.; Perego, D.L.; Perez Trigo, E.; Pérez-Calero Yzquierdo, A.; Perret, P.; Petrella, A.; Petrolini, A.; Pie Valls, B.; Pietrzyk, B.; Pinci, D.; Plackett, R.; Playfer, S.; Plo Casasus, M.; Polok, G.; Poluektov, A.; Polycarpo, E.; Popov, D.; Popovici, B.; Potterat, C.; Powell, A.; du Pree, T.; Pugatch, V.; Puig Navarro, A.; Qian, W.; Rademacker, J.H.; Rakotomiaramanana, B.; Raniuk, I.; Raven, G.; Redford, S.; Reece, W.; dos Reis, A.C.; Ricciardi, S.; Rinnert, K.; Roa Romero, D.A.; Robbe, P.; Rodrigues, E.; Rodrigues, F.; Rodriguez Cobo, C.; Rodriguez Perez, P.; Rogers, G.J.; Romanovsky, V.; Rouvinet, J.; Ruf, T.; Ruiz, H.; Sabatino, G.; Saborido Silva, J.J.; Sagidova, N.; Sail, P.; Saitta, B.; Salzmann, C.; Sambade Varela, A.; Sannino, M.; Santacesaria, R.; Santinelli, R.; Santovetti, E.; Sapunov, M.; Sarti, A.; Satriano, C.; Satta, A.; Savrie, M.; Savrina, D.; Schaack, P.; Schiller, M.; Schleich, S.; Schmelling, M.; Schmidt, B.; Schneider, O.; Schopper, A.; Schune, M.-H.; Schwemmer, R.; Sciubba, A.; Seco, M.; Semennikov, A.; Senderowska, K.; Serra, N.; Serrano, J.; Shao, B.; Shapkin, M.; Shapoval, I.; Shatalov, P.; Shcheglov, Y.; Shears, T.; Shekhtman, L.; Shevchenko, O.; Shevchenko, V.; Shires, A.; Simioni, E.; Skottowe, H.P.; Skwarnicki, T.; Smith, A.C.; Sobczak, K.; Soler, F.J.P.; Solomin, A.; Somogy, P.; Soomro, F.; Souza De Paula, B.; Spaan, B.; Sparkes, A.; Spiridenkov, E.; Spradlin, P.; Stagni, F.; Steinkamp, O.; Stenyakin, O.; Stoica, S.; Stone, S.; Storaci, B.; Straumann, U.; Styles, N.; Szczekowski, M.; Szczypka, P.; Szumlak, T.; TʼJampens, S.; Talanov, V.; Teodorescu, E.; Terrier, H.; Teubert, F.; Thomas, C.; Thomas, E.; van Tilburg, J.; Tisserand, V.; Tobin, M.; Topp-Joergensen, S.; Tran, M.T.; Tsaregorodtsev, A.; Tuning, N.; Ukleja, A.; Urquijo, P.; Uwer, U.; Vagnoni, V.; Valenti, G.; Vazquez Gomez, R.; Vazquez Regueiro, P.; Vecchi, S.; Velthuis, J.J.; Veltri, M.; Vervink, K.; Viaud, B.; Videau, I.; Vilasis-Cardona, X.; Visniakov, J.; Vollhardt, A.; Voong, D.; Vorobyev, A.; Vorobyev, An.; Voss, H.; Wacker, K.; Wandernoth, S.; Wang, J.; Ward, D.R.; Webber, A.D.; Websdale, D.; Whitehead, M.; Wiedner, D.; Wiggers, L.; Wilkinson, G.; Williams, M.P.; Williams, M.; Wilson, F.F.; Wishahi, J.; Witek, M.; Witzeling, W.; Wotton, S.A.; Wyllie, K.; Xie, Y.; Xing, F.; Yang, Z.; Ybeles Smit, G.; Young, R.; Yushchenko, O.; Zavertyaev, M.; Zhang, L.; Zhang, W.C.; Zhang, Y.; Zhelezov, A.; Zhong, L.; Zverev, E. (April 2011). "Observation of J/ψp Resonances Consistent with Pentaquark States in Λ0b→J/ψK−p Decays". Physics Letters B. 698 (2): 115–122. doi:10.1016/j.physletb.2011.03.006. 

to use is a matter that the template should be neutral on. The first is the standard way of citing things in particle physics, while last three are definitely non-standard.Headbomb {t · c · p · b} 04:09, 26 November 2017 (UTC)

More bullshit. And as before, a strawman argument, as NO ONE – other than YOU, that is – has suggested a need to list 200+ coauthors, let alone 546. Once again you have mistaken what I said. (Sigh, guess I needed to highlight my "up to a dozen or so".) Your little exercise demonstrates a level of WP:POINTiness to be lamented in one who aspires to adminship. And my three reasons still beats your "absolutely no reason". ~ J. Johnson (JJ) (talk) 06:17, 26 November 2017 (UTC)
The point, which you refuse to hear, is that "Aiij, R.; et al. (2011) ..." is entirely fine in 'long citation' form, and is both used on Wikipedia's featured articles (e.g. Quark) and in the published world, and I will oppose any attempt at delegitimizing this citation style, per WP:CITEVAR. This style in no way suggests that an editor who uses it "was too lazy to list at least three more authors" nor does it "validly raises a question of whether anything else has been scamped". Headbomb {t · c · p · b} 13:56, 26 November 2017 (UTC)
I have given my reasons, which you have not addressed other than to deny. As you seem rather over-wrought for discussion, there is little point in continuing. ~ J. Johnson (JJ) (talk) 22:43, 26 November 2017 (UTC)
It is claimed no CS1/harv/CITEREF magic depends on what the N of truncation is: when short citations are in use, with templates like {{harvnb}}, and the full citation has more than four authors, at least the first four surnames are necessary in order to create a valid link between the two templates. --Redrose64 🌹 (talk) 23:43, 26 November 2017 (UTC)
Yes. ~ J. Johnson (JJ) (talk) 21:37, 27 November 2017 (UTC)
Use of {{harv}} is not required, and you can easily accomodate it if you insist on having {{harv}} around. (Aaij et al. 2011) works just fine, e.g., if you combine it with {{harvid|Aaij et al.|2011}}. Headbomb {t · c · p · b} 13:48, 2 December 2017 (UTC)

Attempting to restate the original question[edit]

Wow, that went sideways. I believe that SchreiberBike was asking a more generic question, which was: Should the punctuation in a citation using CS1 style (i.e. full citations) be "Smith, Alfred; et al." or "Smith, Alfred et al."? In other words, should there be a semicolon, something else, or any punctuation at all, between a single author's name and "et al.", and does CS1 allow an editor to make that choice? Perhaps SchreiberBike can let us know if that was the initial query. – Jonesey95 (talk) 03:09, 23 November 2017 (UTC)

@Jonesey95: Indeed. If we weren't using Latin, we could say "Smith, Alfred and others", but that way we are not using paired commas to set off the first name used last. We could say "Smith, Alfred, and others", but that could be confused with one person named Smith and another named Alfred; though it doesn't look like that if we write "Smith, A. and others". On reflection, I'm thinking that the semicolon "Smith, A.; and others" is the best choice. It's also the way the template works.  SchreiberBike | ⌨  03:29, 23 November 2017 (UTC)
I think that a semicolon here is the least bad choice (among semicolon, comma, or nothing), as SchreiberBike lays out above. And when more than one author is listed before "et al.", a semicolon is essentially performing the function of a serial comma, a stylistic choice that, in this case, reduces ambiguity. – Jonesey95 (talk) 03:53, 23 November 2017 (UTC)
It might be noted that Science uses a comma to separate authors, but then it does not invert the surname, so there is no confusion. Nature does invert, and uses the comma for both that and separating authors, but there is (or should be?) no confusion with dual use of the comma as they use initials. But where ever there is a list of authors, with inverted first names (such as here at WP), yes, it is preferable to use both comma and semicolon for (resp.) name inversion and author separation. My complaint here (above) is not with the semicolon, but with the use of "et al." to avoid listing co-authors in the full citation, as implied in the examples. ~ J. Johnson (JJ) (talk) 23:06, 25 November 2017 (UTC)
Thank you for the helpful clarification. It appears that your complaint is with editors and editing guidelines, then, not with the Citation Style 1 templates. It has been my experience that changing editors and editing guidelines is much more challenging than changing templates. – Jonesey95 (talk) 23:28, 25 November 2017 (UTC)
It was initially about templates because OP was asking about turning off the semicolon if only one author is listed before the "et al.", although I agree with J. Johnson in that this should never happen so it shouldn't be encouraged by the template. Umimmak (talk) 23:45, 25 November 2017 (UTC)
Indeed. I have generally found templates (etc.) to be much better behaved. Though I allow my first encounter with List-defined references was pretty wild. And there was an encounter with a self-modifying program once, but I've pretty much forgotten about that. ~ J. Johnson (JJ) (talk) 23:53, 25 November 2017 (UTC)

Archive-date parameter[edit]

I was just wondering whether the |archive-date= function could be performed automatically with links to the Internet Archive, by interpreting the URL. For example:

https://web.archive.org/web/20160303181922/http://www.historyhome.co.uk/c-eight/ministry/northmin.htm.

As the date is already included in the URL, might it be possible to code {{cite web}} so that |archive-date= appears automatically? Thanks.--Nevéselbert 19:09, 23 November 2017 (UTC)

I believe that InternetArchiveBot does this for you if you go to the page's history and click Fix Dead Links. I haven't tried it, though. – Jonesey95 (talk) 19:18, 23 November 2017 (UTC)
@Jonesey95: that's good, but what I'm asking is whether the parameter can be done away with entirely, with Internet Archive links.--Nevéselbert 20:07, 23 November 2017 (UTC)
I've often wondered this myself. The only concern would be how to format the date, if we want consistency either of this field within an article or consistency of date fields within the cite. DMacks (talk) 20:11, 23 November 2017 (UTC)
mdy probably should be the default. For dmy or ymd formatting, |dmy-all= or |ymd-all= should be used per {{Cite web#Date}}.--Nevéselbert 20:34, 23 November 2017 (UTC)
Help talk:Citation Style 1 is the best forum for discussing changes to the CS1 templates that use |archive-date=. – Jonesey95 (talk) 21:36, 23 November 2017 (UTC)
I am not averse to it. Should user entry be suppressed in favor of auto entry or the other way around? 72.43.99.138 (talk) 15:58, 24 November 2017 (UTC)

There are at least 20 web archiving services in use on enwiki and not all URL types support 14-digit snapshot dates in the URL. -- GreenC 02:34, 27 November 2017 (UTC)

But some do (or at least one of the popular ones does), and it's trivial to detect those that are known to based on other parts of the URL. DMacks (talk) 11:49, 5 December 2017 (UTC)
This is true. Like when I wrote {{webarchive}}, if |date= is missing (equivalent to |archivedate= in the CS1) it will attempt to extract the date from the URL. However |date= is still a required argument so rather than issue a red warning message (since the template is able to display a date) it silently adds it to tracking category. It's fairly trivial for a bot to fix them by adding a |archivedate=, and my bot WP:WAYBACKMEDIC does it already (fix #3). Consider though if editors assume the |archivedate= is optional, they may habitually not add it even with URL's that don't use a 14-digit format. -- GreenC 14:49, 5 December 2017 (UTC)
Hi there GreenC, do you think something similar could work in this scenario? I suppose we could add a red warning message in cases where an editor forgoes |archivedate= with URLs that don't use the 14-digit format. I think |date= should be optional for IA links, but recommended for other archive websites.--Nevéselbert 10:34, 11 December 2017 (UTC)

Suppress automatic "ed." when adding edition information[edit]

Often the "edition" of a book is more than just "Nth ed." Right now if I want to cite the edition which calls itself the "Ninth edition with a revised supplement" (distinct from the "Ninth edition"), it automatically puts "ed." at the end, when it oughtn't.

  • Liddell, Henry George; Scott, Robert, eds. (1996). A Greek–English Lexicon. Revised and augmented by Henry Stuart Jones, with Roderick McKenzie et al. (9th ed. with a rev. suppl. ed.). Oxford: Oxford University Press. ISBN 978-0-19-864226-8. 

I suppose I could put it in the title, as in:

  • Liddell, Henry George; Scott, Robert, eds. (1996). A Greek–English Lexicon With a Revised Supplement. Revised and augmented by Henry Stuart Jones, with Roderick McKenzie et al. (9th ed.). Oxford: Oxford University Press. ISBN 978-0-19-864226-8. 

And this is probably what I'll end up doing and I guess this works, but I don't think one can just put it in the |title=. It seems like there ought to be like a | or something like that when dealing with these and similar cases.

Umimmak (talk) 09:07, 24 November 2017 (UTC)

Why not:
  • Liddell, Henry George; Scott, Robert, eds. (1996). A Greek–English Lexicon. Revised and augmented by Henry Stuart Jones, with Roderick McKenzie et al. (9 with revised supplement ed.). Oxford: Oxford University Press. ISBN 978-0-19-864226-8. 
--Izno (talk) 13:12, 24 November 2017 (UTC)
9 with revised supplement ed. just seems incredibly awkward to me; it's not really how English works, is it? But I guess it is another option. Umimmak (talk) 19:51, 24 November 2017 (UTC)

Please add parameter ZDB for the German public "ZeitschriftenDatenBank"[edit]

See http://zdb-opac.de/LNG=EN/DB=1.1/ and from now on http://zdb-katalog.de/?lang=EN of the DFG-funded online German periodicals catalogue. The ZDB-ID allows to access directly all records of the periodical, which is useful since there are often quite different periodicals which have or had the same name. The number should be translated in a http request for the periodicals record as in the simple template in the German language wikipedia. If possible, the value of the LNG parameter in the call to the ZDB could be dependent on the language of the Wikipedia from which the cite journal is being called. Thanks in advance! --L.Willms (talk) 12:54, 24 November 2017 (UTC)

From the ZDB-Website:

Zeitschriftendatenbank (ZDB)
The ZDB: what it is
The ZDB is the world's largest specialized database for serial titles (journals, annuals, newspapers etc., incl. e-journals).
The ZDB: what it contains
The ZDB [currently] contains more than 1.8 million bibliographic records of serials from the 16th century onwards, from all countries, in all languages, held in 3.700 German and Austrian libraries, with 15.6 million holdings information. It does not contain contents, i. e. journal articles.


The responsibility for the maintenance and further development of the ZDB lies with the Staatsbibliothek zu Berlin - Preußischer Kulturbesitz and the German National Library.

Request to change CS1 errors: dates[edit]

Could Category:CS1 errors: dates please be removed from pages in the Wikipedia space? I don't think it's appropriate to "fix" many of those pages (e.g. anything in Wikipedia:Articles for deletion discussions) Thanks! GoingBatty (talk) 23:20, 26 November 2017 (UTC)

I think this is the original discussion that led to most Talk namespaces having the error categories removed. That was four years ago, so it might be time to revisit, now that many error categories have been added and many are regularly cleaned out. (Of the 44 CS1 error categories, 33 are regularly or occasionally emptied by gnomes.) – Jonesey95 (talk) 04:23, 27 November 2017 (UTC)
@Jonesey95: It's been four years?!?!? Wow - time flies! I haven't been keeping up with the date cleanup (or discussions) lately, but spent some time over the last few days. There are 1,176 Wikipedia-space pages in Category:CS1 errors: dates (3.6% of the category). Thanks! GoingBatty (talk) 03:54, 29 November 2017 (UTC)
I guess I don't see why, in the majority of cases, these pages can't be fixed. Why not create an awb script to add |no-cat=true to the offending cs1|2 templates? No visible change to the archives and the archives no longer clutter the category.
Trappist the monk (talk) 12:32, 30 November 2017 (UTC)
Is there a description somewhere for what |no-cat= does? I can't find it in {{Citation Style documentation}}.   ~ Tom.Reding (talkdgaf)  14:17, 30 November 2017 (UTC)
Alias of |template-doc-demo=; it's easier to type (and, for the usage I described above, more semantically correct).
Trappist the monk (talk) 14:28, 30 November 2017 (UTC)
{{Citation Style documentation/url}} updated (the only place I found with a dedicated section to |template-doc-demo=.   ~ Tom.Reding (talkdgaf)  15:42, 30 November 2017 (UTC)
Running a script is only a one-time solution, the category will re-clutter (over what timeframe I don't know), and the script would be subject to re-coding for updated error-rules each time it is run, all more complicated (I assume) than creating a mask. Would an article-mask for ignoring Wikipedia:-space pages produce a lot of computational overhead or some other undesirable effect?   ~ Tom.Reding (talkdgaf)  15:42, 30 November 2017 (UTC)
All of what you wrote is true. But, if we are worried about re-cluttering, then we should do away with categorization entirely. But, we aren't worried about that; look at Category:CS1 errors: deprecated parameters. It was empty before the last module update, after which it filled up with several thousand articles, was cleared by a bot and some gnomes, so that today it has a handful of entries. This Wikipedia namespace thing would be much the same. Any change to the module suite has the possibility of creating new errors that must be fixed – that is inherent in a 'living' encyclopedia.
Tweaking the module to inhibit error categorization for Wikipedia namespace is relatively simple. But, WP: namespace is not solely 'archives' nor is it solely discussion pages, so I think that even in 'talk-like' WP: namespace pages, errors should be fixed (except when the discussion is about the error – probably rare). If we leave WP: namespace pages alone and could somehow magically clear all other errors right now, we would have 5+ category-pages of broken WP: namespace page names that could stay there forever (and by doing so be a plague to future gnomes).
Were a 'one-time script' for AWB, or some other semi-automated tool, to be written, its source might be stored in some public sub-page of Help:CS1 errors or Help:Citation Style 1 with a link from either or both of those pages so that future editors can easily find, update, and use it when the need arises, if the need arises.
Trappist the monk (talk) 17:06, 30 November 2017 (UTC)

Date formatting[edit]

I was surprised to recently learn that it is acceptable MOS to write the date format in two different styles within the same references. Publisher written date and access in digits. Every editor I know picks one style of formatting the date and mainly sticks with it. I see both styles within the same ref so infrequently it was one of the rules of my contest to format dates in one way!♦ Dr. Blofeld 11:50, 29 November 2017 (UTC)

I'm not sure of the purpose of this post. Yes, MOS allows archive and access dates to be in a different format from publication date format and has allowed that for a long time. Date validation in cs1|2 does not look for consistency in different date-holding parameters:
{{cite web |title=Title |publication-date=20 June 1998 |date=August 6, 1977 |url=//example.com |archive-url=//example.org |archive-date=2017-11-29}}
"Title" (published 20 June 1998). August 6, 1977. Archived from the original on 2017-11-29. 
So how does your discovery, if I might call it that, apply to us here at WT:CS1? What 'contest'?
Trappist the monk (talk) 12:05, 29 November 2017 (UTC)
Dr. Blofeld: The MOS text in question is at MOS:DATEUNIFY. If you would like to discuss changing that text, Wikipedia talk:Manual of Style/Dates and numbers is the correct venue. – Jonesey95 (talk) 14:33, 29 November 2017 (UTC)
We could however, check for disallowed mismatches. Like |date=20 August 2009 vs |access-date=August 29, 2013, or silly things like an access-date older than the date. This could even be bot-assisted (e.g. if {{Use dmy dates}} is used, then convert dates to that format).Headbomb {t · c · p · b} 16:43, 29 November 2017 (UTC)

PubMed Identifier on Cite Journal Template[edit]

Can an admin change the link(s) to PubMed Identifier (piped in as "PMID") to point directly to PubMed#PubMed identifier (like PMID)? I know the redirect works and all, but it's clearly already piped so it might as well be piped right to the correct spot. This is concerning the Cite Journal template, as well as a few others. Nessie (talk) 18:00, 29 November 2017 (UTC)

I don't think that this is a good idea. The nice thing about the redirect is that the tooltip from the piped redirect matches what the PMID static text means. The direct-linked tooltip just says 'PubMed' which doesn't identify PMID as 'PubMed Identifier'.
Trappist the monk (talk) 18:41, 29 November 2017 (UTC)
Assuming the tooltip says "PubMed" instead of "PubMed Identifier", I think most people can guess what "ID" stands for. Nessie (talk) 18:58, 29 November 2017 (UTC)
I don't see a reason to change it to a section link, especially since the "What Links Here" results should point to PubMed Identifier since that's the intended link. Headbomb {t · c · p · b} 19:19, 29 November 2017 (UTC)

accessdate (or access-date) and url[edit]

I've been involved in a conversation with @Tom.Reding: over an edit he made to Band of Brothers (book); he deleted the entry for accessdate in {{cite book}} because the citation was did not have a url. I acknowledge that he was technically correct because the documentation for cite book states that accessdate requires a url but that information does not appear in the template pop-up available in the editing window. The problem is compounded by the decision to suppress the error message, thereby denying the editor the knowledge of his or her error and the opportunity to correct it. The solution to this is to display the error message. I posting here, btw, because Template talk:Cite book redirected me here.--Georgia Army Vet Contribs Talk 18:01, 2 December 2017 (UTC)

Gaarmyvet, please see the solution on my talk page.   ~ Tom.Reding (talkdgaf)  18:07, 2 December 2017 (UTC)
No, your solution is to tell a potentially novice editor that he or she has to edit a css page.--Georgia Army Vet Contribs Talk 18:18, 2 December 2017 (UTC)
The error is nothing the reader needs to see and be bothered with, hence why it's suppressed by default, and should remain so. Headbomb {t · c · p · b} 18:24, 2 December 2017 (UTC)
I didn't say "readers." I said "editors."--Georgia Army Vet Contribs Talk 18:51, 2 December 2017 (UTC)
And how exactly do you propose that editors and readers see different things? Headbomb {t · c · p · b} 18:58, 2 December 2017 (UTC)
Well, one option would be to display the error only in preview mode, either the pop-up or the page. It seems to me there are some things that already display only in preview mode, but which slip my mind right now. Of course, every reader is a potential editor.--Georgia Army Vet Contribs Talk 19:42, 2 December 2017 (UTC)
(edit conflict)
There was this rfc, that forced us to turn off a handful of error messages. The supporters of that rfc promised that an automated solution would be forthcoming, and to their credit, I recall that there was some movement toward fulfilling that promise. But, alas, that effort has come to naught. I'm not going to bother to look for the discussions since the rfc where I have suggested that we should lift the restrictions on that handful of error messages, but I will suggest, yet again, that we should, so that human editors can, if they choose, make repairs as they do other editing. Making the error messages visible doesn't guarantee that they will be repaired, but at least exposes the error to the light of day. It has, after all, been more than 4 years and no one has stood up a bot to do as the rfc proponents promised.
The editing tools that you mention are not in our bailiwick here at cs1|2. For issues with them, see Wikipedia:VisualEditor/Feedback and/or MediaWiki_talk:RefToolbar.js; there may be other places to discuss those tools.
Trappist the monk (talk) 19:50, 2 December 2017 (UTC)
I support displaying all of the error messages. It's been long enough, and no bots have come forward to do the remaining work. (Bots have done much of the work on errors that were initially hidden, like date errors.) – Jonesey95 (talk) 20:05, 2 December 2017 (UTC)
Support showing errors in preview mode, since some fraction of otherwise-error-producing edits will be corrected before even being created, and anyone already in a position to correct will at least be alerted to their existence. Worth doing another RfC imo.   ~ Tom.Reding (talkdgaf)  22:33, 2 December 2017 (UTC)
I'd prefer always showing errors too, but can concede to a minimum of preview-only depending on the arguments.   ~ Tom.Reding (talkdgaf)  04:40, 3 December 2017 (UTC)
People regularly miss errors perhaps because they were inattentive, because the error message was outside of the displayed window, because they didn't bother to use the Show preview button, or did but didn't think to look at the page reference section or the reference previews. There are a lot of infoboxes out there that have preview-only-error-messaging. These error messages are regularly ignored – I am guilty of this. I suspect that they are ignored because they don't show at any time but in preview – no motivation for editors to fix the errors. Be glad for gnomes.
There are three error messages (of some 50-ish) that are still hidden. The error messages contribute to these categories (and current page counts):
Category:Pages using citations with accessdate and no URL: 42,397 articles
Category:Pages using web citations with no URL: 13,791 articles
Category:Pages using citations with format and no URL: 4,002 articles
For comparison, Module:Citation/CS1 is currently transcluded in 3,440,000 pages (yeah, that includes pages that aren't categorized so include that fact in your calculations).
Trappist the monk (talk) 00:12, 3 December 2017 (UTC)
Recently added in 1928 Chico State Wildcats football team:
{{cite news|title=Football Results|newspaper=San Francisco Chronicle|date=October 6, 1928|page=25|via=[[GenealogyBank.com]]|access-date=November 12, 2017}}
The editor intends to signify the newspaper was accessed on November 12, 2017 on the commercial database GenealogyBank.com. Seems reasonable, though not what accessdate means (we don't track offline activities). The warning message would alert users they are doing it wrong and cut down on the number of new instances.
I expect most of them never had a URL for reasons like above, or data entry error forgetting to add. A bot can search the revision history for the original cite and determine there was never a url, it shouldn't be too difficult to fix about 80% (estimate) simply by deleting the url and accessdate. Then rely on the warning messages for the remainder to be fixed manually. -- GreenC 04:18, 3 December 2017 (UTC)

Working on Category:CS1 errors: invisible characters[edit]

I know that most of the editors who hang out here are gnomes that prefer to work quietly, but sometimes it's fun to take on a project as a team. This is an invitation to do just that. I'm planning to work on Category:CS1 errors: invisible characters, which has about 3,105 pages in it as of this writing.

I have found that most of the errors are straightforward line feeds and tab characters that should be replaced with spaces. Other characters should be replaced by a dash, apostrophe (single quote mark), space, ellipsis, quote mark, an accented character, or nothing. You can usually figure it out by context, or by checking the original source. I have some regexes that mostly work (each one needs to be checked manually) in the "invisible character" section of User:Jonesey95/AutoEd/unnamed.js, an AutoEd script. You are welcome to copy and refine those regexes, use manual searches, or adopt any other method you want.

I am planning to make a pass through the category to fix the easy errors, then see what's left. Feel free to join me, and post here with questions or comments. – Jonesey95 (talk) 05:56, 3 December 2017 (UTC)

Down to 2,800 at this writing. There is still a lot of low-hanging fruit in this category. – Jonesey95 (talk) 16:40, 24 December 2017 (UTC)
Now at 2773. I basically went after the first page in each alphabetical section (why not?). However, I stumbled across several pages with errors inside non-English text--mostly related to Sri Lanka--which I think will require some work by someone with language skills (example at Cadex 2009). I checked on one editor but he/she has not been here since 2011.--Georgia Army Vet Contribs Talk 20:19, 24 December 2017 (UTC)
Thanks for contributing! I've been skipping those zero-width joiner characters so far, as well as right-to-left text, which does not behave well in my editor. – Jonesey95 (talk) 21:49, 24 December 2017 (UTC)
We recently fixed that issue for several Indic scripts. A bit of Googling seems to show that zwj is also required for Sinhalese so I've added detection for Sinh script to Module:Citation/CS1/Configuration/sandbox (and fixed a bug at the same time):
Cite news compare
{{ cite news | last=Warnakulasuriya | date=2009-10-11 | first=Keerthi | title=යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ | language=Sinhala | work=Divaina | pages=18 | accessdate=2009-10-16 }}
Live Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18.  zero width joiner character in |title= at position 31 (help);
Sandbox Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18. 
Trappist the monk (talk) 22:04, 24 December 2017 (UTC)

Is there a validation process before this is implemented?--Georgia Army Vet Contribs Talk 03:52, 29 December 2017 (UTC)

Horizontal tab[edit]

Is there any use, anywhere, in Wikipedia for the horizontal tab, U+0009 (HT)? I've been editing for seven years plus and can't think of one. If there isn't one, I don't see why we can't ask the folks who work on bots to do a search and replace and substitute a <space> for every <HT>. In some cases, we might get strings of spaces but that would still be an improvement. I'm a big fan of letting computers do my work for me. Or am I over simplifying this?--Georgia Army Vet Contribs Talk 23:58, 30 December 2017 (UTC)

Tab can be seen on programming pages in and out of article space. You might also see it in <pre> and <poem> blocks, or even outside to provide the latter (since a space at the beginning of a line starts a block). --Izno (talk) 00:10, 31 December 2017 (UTC)
Oh, well.<sigh>--Georgia Army Vet Contribs Talk 00:32, 31 December 2017 (UTC)

Update one month in[edit]

A little over one month in, we are down to 2,149. I am working backwards through the alphabet and have hit pages starting with S-Z so far. Steady progress. – Jonesey95 (talk) 05:25, 10 January 2018 (UTC)

We need to get implementation on ignoring the zero-length characters in Indic(?). I think every page in the U's "suffers" from that condition.--Georgia Army Vet Contribs Talk 15:17, 12 January 2018 (UTC)

It has been implemented in the sandbox. It will be useful to go through the rest of the category to see if there are any other bugs that need to be fixed. – Jonesey95 (talk) 15:41, 12 January 2018 (UTC)
1,294. 0–9, A–I. Meet at N? :)
I'm seeing a lot of tabs and newlines, mainly in |title=, but also in other params. These should be possible to automate: in all params (except |quote=, see below; and with a caveat, ditto), all runs of whitespace can be safely collapsed to a single space character. Another big class is apostrophes, long dashes, and smart quotation marks copied from unlabelled Windows code page 1252 (and a few other charsets) that can probably be automated with an acceptable error rate. Then there's a bunch of completely garbled text, titles mostly, that suffers from the same problem but which can't really be fixed automatically or semi-automatically. There's also a few similarly garbled author names, but not a lot of them. And, of course, a lot of ZWJ warnings in various asian scripts (possibly only in Sinhalese, but there may have been some Malayalam and Hindic etc. too) that, I believe, are just false positives.
And then there's a ton of newlines in |quote= that can't really be fixed, neither automated nor manually. Truncating the quote or simply removing the newlines is likely to annoy the natives (local editors), and I don't know of a workaround. This needs to be resolved somewhere, somehow: drop support for |quote= entirely; set a hard limit on what it can contain; or permit newlines inside this specific parameter.
And then there is {{cite tweet}}.
Which wraps {{cite web}}, but for its |title= parameter documents: "Entire content of the tweet, including hashtags (#), at signs (@), and links". This, to me, is bogus in so many ways; but in any case, this module's check for newlines is in direct conflict with that template's documented behaviour. In other words, this can't be cleaned up by gnomes. --Xover (talk) 17:54, 14 January 2018 (UTC)
Thanks for the comments. I wonder if silently converting all white space to spaces without emitting error messages would bother editors. We currently collapse white space and emit an error message; it might be more fruitful to do so without an error message. Here's an example of how we do it now:
Cite web compare
{{ cite web | title=Text followed by new line Second line Third lines | url=http://www.example.com | date=January 1, 2000 | author=Author }}
Live Author (January 1, 2000). "Text followed by new line Second line Third lines".  line feed character in |title= at position 26 (help)
Sandbox Author (January 1, 2000). "Text followed by new line Second line Third lines".  line feed character in |title= at position 26 (help)
Perhaps someone here could remind us why we emit error messages for harmless white space. I forget, and I am too busy doing other stuff (lazy?) to dig through this page's archives right now. Maybe later. – Jonesey95 (talk) 18:02, 14 January 2018 (UTC)
For |quote=, newlines can be replaced with <br /> tags:
{{cite book |title=Title |quote=Text followed by new line<br />Second line<br />Third line}}
Title. Text followed by new line
Second line
Third line
 
or, depending on context, <p>...</p> tags:
{{cite book |title=Title |quote=Paragraph followed by<p>Second paragraph</p><p>Third paragraph</p>}}
Title. Paragraph followed by

Second paragraph

Third paragraph

 
We find tabs, line feeds, carriage return characters because they generally don't belong in the metadata along with all of the other ascii characters with byte value less than 32 decimal (0x20 hex) – the space character.
Trappist the monk (talk) 18:59, 14 January 2018 (UTC)
Thanks. I don't know why I was convinced <br /> and <p>...</p> wouldn't work here. Possibly I'd been doing battle with errors related to strip markers and such. In any case, most |quote= parameters now look like they can be fixed this way (some cases require too much tag soup so I'm leaving them alone). In view of that, what I'm leaving behind (not touching) are mainly ZWJ cases and {{cite tweet}} (which would turn into tag soup if handled this way).
Incidentally, in going back over these articles I've found (in Fuk'anggan) that Manchu alphabet and Mongolian script (the former seems to be an extension/adaption of the latter) also require ZWJ. Otherwise the ZWJ cases so far are all Sinhalese. --Xover (talk) 11:51, 16 January 2018 (UTC)
(added) Oh, and I nearly forgot: based on Characters of Casualty, certain cases of Emoji also require ZWJs, which will be an increasing issue as we copy whole tweets into citations. See this link on emojipedia for details. Not sure what, if anything, can be done about this (detect and ignore them in Emoji sequences?). --Xover (talk) 11:58, 16 January 2018 (UTC)
Additional case of legitimate use / false positive: Burmese script does not use spaces for word boundaries, so a Zero width space character is often used at phrase boundaries to facilitate line breaking. See UNICODE technical note 11 for details. Example in Ayeyarwady Region Government. --Xover (talk) 09:32, 19 January 2018 (UTC)

I came across a "line feed in quote" in El Rancho Hotel and Casino last night that I could not find. I decided the error was from an included {{collapsible list}}, which I remmed out. It worked but left a very long reference which I'm not sure is necessary.--Georgia Army Vet Contribs Talk 19:25, 14 January 2018 (UTC)

I haven't looked at the source, but a quote that long is likely to be a copyright violation. I have found a couple of those while cleaning out this category, and my fix is to remove all but a sentence or two, preserving the relevant text that supports the statement in the article's prose. – Jonesey95 (talk) 19:46, 14 January 2018 (UTC)
I went back and "aggressively trimmed" the quote.--Georgia Army Vet Contribs Talk 16:30, 16 January 2018 (UTC)

Pretty much done[edit]

At this writing, we have reduced this category from 3,000+ pages to 193 pages. One more pass through the letters P, R, and S could probably fix a couple dozen more pages. I haven't done an exact count, but I think at least half of the remaining pages are false positives – Sinhalese and other scripts that use allowable zero width joiner characters. The CS1 sandbox has been partially updated to account for these; once it is moved to production, we can null-edit the whole category to find (and, ideally, fix) the remaining errors. Great work, everyone! – Jonesey95 (talk) 05:19, 23 January 2018 (UTC)

Bot forcing publication titles into the publisher parameter if they're hostnames[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see User talk:Ohconfucius#Changes to 2017 Brighton siege.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  15:50, 3 December 2017 (UTC)

Help on usage[edit]

How would I use this template to cite a death certificate? Or is there a better template for citing primary source documents? -- Foofighter20x (talk) 23:35, 6 December 2017 (UTC)

Which template are you referring to? If you insist on using a CS1 template for death certificates, I would use {{cite report}}. Else, I would go with CS2. In the United States, the publisher would be the relevant vital records office. However, increasingly these authorities consider death certificates private documents, and copies are released only to persons with a proven relationship to the deceased. This may make some or most death certificates non-citable (because the citation would not be verifiable). If you want to cite a death, maybe other, more public sources (newspaper death notices, obituaries, etc.) may be a better option. 72.43.99.146 (talk) 01:22, 14 December 2017 (UTC)

Please add Subtitle parameter for press releases[edit]

Hi, I'm adding a {{cite press release}} to an article. Nearly all press releases have a subtitle that gives more information beyond what the title announces. In the one I'm citing,

TerraPass Sells Retail Business, Adopts New Name
Company Reorganizes to Focus on Project Origination in Carbon & Energy

But there's no parameter for this. This has been discussed before but nothing came of it. Adding the subtitle to the title after a colon, as suggested in that discussion, is a non-starter since it is usually a long sentence that would create a two- or more line blue link.. The guidelines for this new parameter would tell editors to only fill in the subtitle if it's relevant to the claim in the article that the citation supports. -- Skierpage (talk) 00:39, 8 December 2017 (UTC)

A colon (or leaving out the subtitle) usually works great. Would you mind linking to an article where you are using this citation to show what it looks like in context? Thanks. – Jonesey95 (talk) 04:26, 8 December 2017 (UTC)

Harvnb links to mixed author/editor cites not working[edit]

I'm straying a bit out of my depth here since I normally avoid {{harv}}-type constructs, but is this a feature or a bug?

Template:Harvard citation no brackets#Wikilink to citation does not work's #2.1.1.5 says The citation does not have an author's last name, but the {{harvnb}} link definitely works (search for "Pinowski & Summers-Smith 1990") when only |editor= aliases are used (a minor inconsistency in the /doc), but it doesn't work (search for "Pinowski, Kavanagh & Górski 1991") when 1 author and 2 editors are used.

The mixed author/editor citation was:

* {{cite book |last1=Pinowski |first1=Jan |editor1-last=Kavanagh |editor1-first=P. P. |editor2-last=Górski |editor2-first=W. |title=Nestling mortality of granivorous birds due to microorganisms and toxic substances |year=1991 |publisher=Polish Scientific Publishers |location=Varsovia |isbn=83-01-10476-7|ref=harv}}

and the {{harvnb}} call is (search for "Pinowski, Kavanagh & Górski 1991"):

{{Harvnb|Pinowski|Kavanagh|Górski|1991|pp=111–120}},

which now works, after the citation was changed back to all-authors.

Can {{harvnb}} be made to search for editors when author parameters run out?   ~ Tom.Reding (talkdgaf)  15:43, 12 December 2017 (UTC)

Could you explain why you want to cite both authors and editors for the same book? Normally, when authors and editors are both present in an instance of a {{cite book}} template, the authors wrote a chapter, and the editors edited the entire book. Jc3s5h (talk) 16:01, 12 December 2017 (UTC)
This isn't meant to be an example for using an author+editor {{harv}} link, but a description of {{harvnb}}s behavior, in what, I assume, can be plausible usage (somewhere).   ~ Tom.Reding (talkdgaf)  16:11, 12 December 2017 (UTC)
To make the templates understandable and usable, they have some "baked in" concepts of what kind of works exist and what information to cite about them. I don't think trying to work for arbitrary hypothetical cases is at all desirable. Weird citations should be written by hand. Jc3s5h (talk) 16:21, 12 December 2017 (UTC)
If Pinowski is the author and Kavanagh & Górski are the editors, then that is how they should be listed in the cs1|2 template. None of the {{sfn}} and {{harv}}-family of templates will link to a combination of authors+editors so the short citation should be {{Harvnb|Pinowski|1991|pp=111–120}}.
Trappist the monk (talk) 16:36, 12 December 2017 (UTC)
My original intention was to properly enumerate the author & editor of that citation based on web search. Fortunately, in this case, I was aware of the {{harvnb}} link, but may not in the future (for manual edits anyway, since I now avoid such AWB edits to |ref=harv citations). I could see other editors doing same, but accidentally breaking the link. To have any bit of "fool-proof-ness", it would be good for {{harvnb}} to search for editors when author parameters run out, unless the inability to do so is itself a feature meant to fool-proof some other thing, or at least be much more explicit and verbose about not mixing them (either in the /doc or via a CS1 maint/error message).   ~ Tom.Reding (talkdgaf)  16:51, 12 December 2017 (UTC)
cs1|2 templates only know what you tell them and they believe you unquestioningly because they cannot know if you are right or wrong and because they can only see what lies between the opening {{ and the closing }}. This same applies to the {{sfn}} and {{harv}} templates. There is no communication between templates, ever (I wish there were). When working with cs1|2 and the {{sfn}} & {{harv}} templates, I have found User:Ucucha/HarvErrors to be invaluable.
Documentation can always be improved so I would encourage you to improve it.
Trappist the monk (talk) 17:07, 12 December 2017 (UTC)
Ah, I think I see. Because there's no communication, the only way to do this would be for {{Cite book}} to produce 2 #CITEREFs: one for Pinowski only (in my example), and another for Pinowski + the 2 editors, which could become a problem if another source existed where those 3 people are all the authors (or 2 were authors + 1 editor), thus producing 2 or more non-unique anchors.
And thanks for that link; it looks like the harv equivalent for show-all-CS1-errors!   ~ Tom.Reding (talkdgaf)  18:46, 12 December 2017 (UTC)
@Tom.Reding: There is nothing to prevent you adding as many (or as few) editors as you like to the {{cite book}} template. Editors are ignored by {{harvnb}} and {{sfn}} except when there are no authors in the {{cite book}}. But when {{cite book}} does have authors, the first four need to correspond to those in the {{harvnb}} or {{sfn}}. --Redrose64 🌹 (talk) 18:28, 12 December 2017 (UTC)
If you really have your heart set on doing something unusual with short references, you can use {{harvid}} in the |ref= parameter. Ugly examples here.Jonesey95 (talk) 05:17, 13 December 2017 (UTC)
But perhaps better not to? Tom, when using a short cite (the "Smith and Jones, 2001" construct, not the full bibliographic citation), editors are used only when referring to the whole work, not to any subsections. Sometimes a work is cited by its name, such as for maps or notable reports. But I have never seen any case, nor can I even conceive of (so far), any case where it is necessary or even just useful to cite a combination of author(s) and editor(s). Some times an editor contributes to a section, but then s/he is cited as an author.
The problem here is not in what Harv does or doesn't, or should, but in the basic notion of what you are trying to do. There really isn't any reason for a "combination" author/editor short cite. ~ J. Johnson (JJ) (talk) 21:35, 16 December 2017 (UTC)

Not a journal[edit]

A search found some 279 citations referring to "Lecture Notes in XXX" (in most cases from a book series published by Springer) in the journal parameter of the citation [1]. These are not journals and should instead be the |series= parameter of a {{cite book}} or {{cite conference}} citation, with the |title= parameter found and added. Anyone looking for gnome-like edits to perform? Or are any of our bots up to the task? —David Eppstein (talk) 06:54, 16 December 2017 (UTC)

Not {{cite conference}}, as lecture notes generally arise from classes, not conferences. I am dubious about these books of collected lecture notes (I doubt any publisher's editors have spent much time on them, and I am a little amazed at some of the junk Springer publishes), but if that is where a WP editor sees something, then that's what should be cited. However, separate lecture notes are a different matter, the "publication" being questionable. If they are found on a website, then cite as a web site. If found as printed class materials, then consider them as unpublished manuscript. In either case they are of limited reliability. ~ J. Johnson (JJ) (talk) 21:59, 16 December 2017 (UTC)

JSTOR error checking[edit]

AFIACT, the allow formats for the jstor identifier are

  • All digits
  • Same as doi

If error checking could be done, that would be great here. Going to @Trappist the monk: here. Headbomb {t · c · p · b} 22:22, 16 December 2017 (UTC)

Upon browsing, there's a few more formats allowed

So maybe a simpler check would be |jstor=(\w|\d|\.)+, and verify that the last character isn't a dot. Headbomb {t · c · p · b} 01:21, 17 December 2017 (UTC)

If DOIs are allowed in JSTOR identifiers, then we could reuse the DOI validation code while also allowing values matching the above regex. – Jonesey95 (talk) 01:54, 17 December 2017 (UTC)
DOIs are allowed in JSTOR ids. In my experience these JSTOR documents have the same access requirement as the underlying DOI, which would make use of the JSTOR id an inefficient link. Just use the underlying DOI in such cases. 72.43.99.138 (talk) 15:28, 17 December 2017 (UTC)
I don't think this is always the case. There are journal articles that I can't access directly via the DOI when it goes to the publisher's website, but can access when logged into JSTOR via an institutional account. Furthermore, if you have an individual account with JSTOR (free), you can put some articles that are not externally accessible onto your "shelf" and read them there. Peter coxhead (talk) 16:22, 17 December 2017 (UTC)

metadata dates rfc[edit]

RFC: Accurate dates in citation metadata has been closed. So, what to do? We have a decision to do 'something' but that 'something' is wholly undefined. Don't you love decisions like that?

While looking at the code that sets the &rft.date= kv pair I noticed that I had neglected to change the indexing for season dates when I made season indexing compliant to ISO DIS 8601 2016 part 2 §4.7. I have fixed that in the sandbox.

Back to the topic at hand, how it works now:

dates before 1582 produce only the year in the metadata:
{{cite book |title=Title |date=16 March 1581}}Title. 16 March 1581. 
<cite class="citation book">''Title''. 16 March 1581.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1581&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"><span style="display:none;">&nbsp;</span></span>

I suppose that we could refine the demarcation point:

any whole-date before 15 October 1582 gets year only
any month-and-year date before November 1582 gets year only

The 1582–1925 interstice is of course the tough nut. What to do about sources with dates from that period? It might be interesting to create a hidden property category to identify articles with cs1|2 templates with |date= value between 1 October 1582 and 1 January 1926 inclusive. This, I think, would give us an idea of the magnitude of the 'problem' if there is one.

Trappist the monk (talk) 16:41, 17 December 2017 (UTC)

I've added code to the module sandboxen that will add articles to Category:CS1: Julian–Gregorian interstice when |date= has a value between 1 October 1582 and 1 January 1926 inclusive.
But, if one is to believe this source, the year part of Julian and Gregorian calendars do not diverge (and will not for a long time into either the past or the future). A month-and-year date during the interstice can be either calendar; we can't tell the which and I don't think that we care because both would be represented in the metadata as &rft.date=YYYY-MM.
What we care about are those |date= values that are whole dates, right? When the date is precise to the day it is definitively one calendar or the other and we can't hand-wave it as we can with month-and-year date. These dates then are the problem children so these are the dates that should be categorized. I'll adjust the detector to categorize only these types of dates in the interstice.
Trappist the monk (talk) 20:22, 17 December 2017 (UTC)
Absent a clear consensus, nothing should be done. These templates exist to standardize the display of information pertinent to verification of articles. If the editor inserted the publication date as identified in the source, then that is enough. The calendaring system used by the source is irrelevant, as far as the templates' purpose is concerned. A reader will be able to replicate the editor's steps and find the particular source, whatever the calendar used. If that reader is a machine (software) with cognition problems is surely not a concern here. It should be a concern of those who tend to that machine. They should be notified, and if the problem persists, the machine should be discarded. AFAIC, I don't see why valuable man-hours should be spent on this external deficiency by people interested in verification. 24.105.132.254 (talk) 20:40, 17 December 2017 (UTC)
I don't know what missing consensus you're talking about. Second paragraph of the closer's comments has this (emphasis mine):
"There is clear and strong consensus that non-Gregorian publication dates should not be fed into COinS, because they will generate inaccurate and misleading data."
The closer specifically did not rule on how the consensus is to be implemented except to say that there is a target goal.
The whole purpose of this topic and any work I do right now is an attempt to understand the extent of the issue and what might be required for us to attain the goal set by the consensus.
Trappist the monk (talk) 23:30, 17 December 2017 (UTC)
Can't this just be what the original year parameter is used for, with quotation marks / some explanation? e.g., "Some Old Russian Newspaper". 1 March 1700 [19 March 1700 in N.S.]  or "Some Old Russian Newspaper". 19 March 1700 [O.S. date listed as "1 March 1700"].  (I can't figure out how to link O.S. and N.S. in the parameter though.Umimmak (talk) 23:57, 17 December 2017 (UTC)

Ellipses being truncated[edit]

{{cite web}} seems to be truncating ellipses in citation titles. Examples: 1 2. Opencooper (talk) 15:44, 18 December 2017 (UTC)

It seems that a final full stop/period is always trimmed from the end of the title when rendering the title, which is also a problem when the title ends with an abbreviation such as "U.S.A.". So it would be interesting to understand whether such scenarios were considered when adding the trim logic. Rjwilmsi 16:36, 18 December 2017 (UTC)
Fixed in the sandbox I think:
  • {{cite book/new |title=no dots |publisher=Publisher}}no dots. Publisher. 
  • {{cite book/new |title=one dot. |publisher=Publisher}}one dot. Publisher. 
  • {{cite book/new |title=two dots.. |publisher=Publisher}}two dots. Publisher. 
  • {{cite book/new |title=three dots... |publisher=Publisher}}three dots... Publisher. 
  • {{cite book/new |title=four dots.... |publisher=Publisher}}four dots... Publisher. 
and, for the Doubting Thomas's, this:
Cite book compare
{{ cite book | publisher=Publisher | title=Title ends with an abbreviation such as "U.S.A.". }}
Live Title ends with an abbreviation such as "U.S.A.". Publisher. 
Sandbox Title ends with an abbreviation such as "U.S.A.". Publisher. 
and take out the quote marks:
Cite book compare
{{ cite book | publisher=Publisher | title=Title ends with an abbreviation such as U.S.A. }}
Live Title ends with an abbreviation such as U.S.A. Publisher. 
Sandbox Title ends with an abbreviation such as U.S.A. Publisher. 

The module does the right thing I think; if it doesn't, no one has ever spoken up about it.

Trappist the monk (talk) 23:46, 18 December 2017 (UTC)
@Trappist the monk: Doesn't seem to be working for cite journal, still getting final full stop truncation:
{{cite journal| author=Sheppard, P.A. |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}Sheppard, P.A. (1959). "Title ending U.S.A". Quarterly Journal of the Royal Meteorological Society. 85. 
{{cite journal/new| author=Sheppard, P.A. |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}Sheppard, P.A. (1959). "Title ending U.S.A.". Quarterly Journal of the Royal Meteorological Society. 85. 
Which doesn't seem correct to me. Thanks Rjwilmsi 09:22, 11 January 2018 (UTC)
Difficult to know what to do. This insource search timed out after finding nearly 24,000 articles where the last character in |title= is a dot (those may not all be cs1|2 parameters). For some reason, editors like to put dots at the end of titles. More so, I think, than any other parameter value. Refining the search to look for \.[a-z]\. (case insensitive) timed out at about 2k articles. In many (most?) of these the trailing dot appears to be part of an initialism. And once again to look for \.[0-9]\. found about 50 where the trailing dot appears (to me) to be terminal punctuation rather than a key component of the last character group.
I suppose that we can look for \.[a-z]\. as a special case for retaining the trailing dot. I have tweaked the sandbox to do that. Is that a correct solution? Renering is slightly different with and without |url=:
{{cite journal/new| author=Sheppard, P.A. |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}
Sheppard, P.A. (1959). "Title ending U.S.A.". Quarterly Journal of the Royal Meteorological Society. 85. 
{{cite journal/new| author=Sheppard, P.A. |url=http://www.example.com |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}
Sheppard, P.A. (1959). "Title ending U.S.A." Quarterly Journal of the Royal Meteorological Society. 85. 
Trappist the monk (talk) 12:32, 11 January 2018 (UTC)
I have an sqlite database generated from data dump, with all en wp mainspace cite journal and citation with journal param, here are my numbers for title ending in dot, and what the penultimate character of title is, and how many of those have 3rd last char is dot too (e.g. ends in ".A." of "U.S.A.") grouped by character type (data from Nov 2016 but somewhat updated):
Class Count 3rd last is dot?
Lower alpha 80804 44
Num 5903 182
Other 6328 1332
Upper alpha 4386 1247
Does that help? I'm not sure what the right answer is, I think something needs to change to handle U.S.A. format better, but a simple rule to handle all scenarios is unlikely to be possible. Rjwilmsi 13:16, 11 January 2018 (UTC)
We might also have to look for "\. [a-z]\.", which would be proper spacing per MOS:INITIALS. – Jonesey95 (talk) 14:15, 11 January 2018 (UTC)
\. +[a-z]\. Sandbox tweaked.
{{cite journal/new| author=Sheppard, P.A. |year= 1959| title= Title ending U. S. A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}
Sheppard, P.A. (1959). "Title ending U. S. A.". Quarterly Journal of the Royal Meteorological Society. 85. 
Trappist the monk (talk) 14:38, 11 January 2018 (UTC)

ASIN[edit]

I am seeing evidence that some people are filling in the ASIN reference when there is an ISBN or other identifier. Clearly we should not be using Amazon's proprietary ID unless there is no alternative. What's the best way to document this and perhaps call it out int he interface (ProveIt or whatever) so that people don't use ASIN unless it's required? Guy (Help!) 10:48, 21 December 2017 (UTC)

The documentation already says, Because this link favours one specific distributor, only include it if standard identifiers are not available. It might be reasonable for a maintenance or error message to display on the page when both ASIN and some other set of identifiers (probably ISBN at least) are present. --Izno (talk) 13:44, 21 December 2017 (UTC)
Or the ASIN could automatically be suppressed if ISBN are provided. Headbomb {t · c · p · b} 14:04, 21 December 2017 (UTC)
Because this link favours one specific distributor .. this could be more direct: Because this link favours one company Amazon.com. -- GreenC 14:33, 21 December 2017 (UTC)
No. What you propose is open to misinterpretation, and the documentation could be seen as biased against a specific company. Any company is not targeted; any company that happens to be the distributor in question is. The appearance of neutrality is as important as the thing itself, because people do tend to misread depending on their own biases. No specific company or person (legal or natural) should be mentioned anywhere, even if they are clearly the only example. 72.43.99.138 (talk) 14:53, 21 December 2017 (UTC)
The above needs to be qualified a bit. I suppose it would be ok if any one entity is mentioned in passing, as an example e.g. "such as Amazon". Imo, this would be less likely to be misinterpreted as targeting. 72.43.99.138 (talk) 15:12, 21 December 2017 (UTC)
This is an Amazon-specific link. There is no other entity it could possibly apply to. Headbomb {t · c · p · b} 15:59, 21 December 2017 (UTC)
Correct. Saying "one specific distributor" is an unnecessary obfuscation. Even the IP editor is confused. -- GreenC 19:43, 21 December 2017 (UTC)
I was referring to the documentation, not the identifier. The documentation should avoid the appearance of targeting, even when such interpretation seems far-fetched. There is no confusion on my part at all. The documentation should retain the generic condition ("a specific distributor") and optionally add specific examples ("such as Amazon" − emphasis on plural examples). Both these statements are true, and more neutral than the proposed documentation change. 72.43.99.138 (talk) 15:16, 23 December 2017 (UTC)
"a specific distributor" is the only thing we need to say. "Such as Amazon" is redundant nonsense since this is documentation for the ASIN identifier, and would imply that there are non-Amazon ASINs. Headbomb {t · c · p · b} 20:09, 24 December 2017 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────Going back to Izno above how about: if ISBN is present then supress presentation of seemingly redundant identifiers such as ASIN and also throw an error/warning notification that redundant identifiers have been supressed? Wtmitchell (talk) (earlier Boracay Bill) 13:38, 11 January 2018 (UTC)

8 digit ZBL[edit]

I was fixing some citations when I stumbled upon a zbl with 8 digits in Lou van den Dries. It is indeed the valid zbl for the citation in question, but it causes an error because usually zbl appears in nnnn.nnnnn format. As User:Headbomb had pointed out, this is a temporary zbl for new abstracts/articles. He suggested making a maintenance category for these zbls. While I'm not the most experienced editor, since I stumbled upon this, I thought I should bring it to someone's attention. Hecseur (talk) 12:39, 23 December 2017 (UTC)

How to make source-specific shim?[edit]

I just embarked on the creation of a source-specific citation template, on the naïve assumption that this would be easy. After all, we're just talking about providing defaults for a few params and passing the rest along to Module:Citation/CS1, right? Right?

Obviously I ran into the wall of my own ignorance pretty quick. So… Any docs on how to create source-specific citation templates based on Module:Citation/CS1? My use case (and, I imagine, most such) just needs to provide defaults for stuff like |publisher=, |editor-last=, |editor-first=. Maybe add some simple logic for creating an URL based on |title= (e.g. prefix |title= with https://en.wikipedia.org/wiki/ and stash it in |url=).

My first cut was using template code that called one of the existing CS1 modules ({{cite_book}} say), but that means I have to write the boilerplate for every single param (last1, last2, last3, etc.) and in MW template syntax. Then I tried just #invoke'ing Module:Citation/CS1, expecting to be able to just touch the params I want to hard code, but here I don't seem to have figured out how to pass stuff from the template to the Lua module (even though using the template seems to pass them just fine).

In other words, I'm completely lost! Help? Surely there's some doc explaining this somewhere? Or an explanation in a talk page archive somewhere (I didn't find anything in the archives here, but that may be my poor choice of terms)? For anyone curious, the project that prompted this plea for help is Template:cite_Grove, an attempt to replace Template:GroveOnline (and its companions) with something that supports all the nice stuff in Module:Citation/CS1 (|ref=harv for one thing!). If you look at its sandbox you can probably tell I'm reduced to voodoo-debugging and trying random variations to get anywhere. Any pointers would be appreciated! --Xover (talk) 14:56, 26 December 2017 (UTC)

Except for the single parameter, |CitationClass=, frame parameters (those parameters implemented in the {{#invoke:}}) are reserved for cs1 debugging.
I can see that {{GroveOnline}} has it's problems, particularly:
|encyclopedia=''In L. Root, Deane.'' [[The New Grove Dictionary of Music and Musicians|Grove Music Online. Oxford Music Online]]
editor's name and static text do not belong there so that line should be replaced with:
|editor-last=Root
|editor-first=Deane L.
|encyclopedia=[[The New Grove Dictionary of Music and Musicians|Grove Music Online. Oxford Music Online]]
The {{subscription required}} template seems to me to be redundant to |url-access=. Perhaps when |url= is not set, only then should {{subscription required}} be executed:
{{#if:{{{url|}}}||{{subscription required}}}}
To support |harv=, add:
|ref={{{ref|}}}
Otherwise, what else is needed?
Trappist the monk (talk) 16:20, 26 December 2017 (UTC)
Well, |last= etc., since each entry has a separate author (or multiple authors). |doi=, since each entry has a DOI (as does the overall work, I believe). |year=, since there are various publication dates for the entries. There's also a whole collection (7-ish) of Grove templates with duplicated code, variations in quirks and supported params, and so forth. Some call {{cite encyclopedia}} and some {{cite book}}. Some put the entry in |title=, and some in |chapter=.
But do I understand correctly that Module:Citation/CS1's approach is to deliberately force "wrappers" (i.e. source-specific citation templates) to go through existing "core" templates (like {{cite_book}}) rather than invoke the module directly? Are there any docs outlining this anywhere? Any alternate approaches that would let me handle stuff in Lua rather than that horrid mess of line noise that is MW template syntax? --Xover (talk) 17:38, 26 December 2017 (UTC)
|last=, |first=, |doi=, and |year= are all easy fixes that could be made to {{GroveOnline}}.
Before cs1|2 supported |vauthors=, there was (and still is) {{vcite2 journal}} which uses Module:ParseVauthors. {{vcite2 journal}} is a wrapper template that uses its module to convert Vancouver style names to |last=-|first= parameters. The module passes the new author name parameters and everything else that it got from the template-call to Module:Citation/CS1 by calling {{cite journal}} with
frame:expandTemplate{title = 'cite journal', args = citeArgs}
Another example of this trick is {{cite Q}} which uses Module:citeq.
You could do something similar by setting the appropriate default values into a table from the frame and then filling it with whatever is included in the parent frame; parent frame parameters, if set, would, of course, overwrite same-named defaults.
Trappist the monk (talk) 18:43, 26 December 2017 (UTC)
Perhaps this:
{{Cite Grove/sandbox}}Root, Deane L. (ed.). Grove Music Online. Oxford University Press. (Subscription required (help)). 
Add authors:
{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B}}Black, A; Brown, B. Root, Deane L., ed. Grove Music Online. Oxford University Press. (Subscription required (help)). 
add translator:
{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B |translator=Green, C}}Black, A; Brown, B. Root, Deane L., ed. Grove Music Online. Translated by Green, C. Oxford University Press. (Subscription required (help)). 
uses Module:Sandbox/trappist the monk/cs1 wrapper
If this is what you're looking for, we should move it out of my sandbox and put it somewhere useful.
Trappist the monk (talk) 22:00, 26 December 2017 (UTC)
Oooh, yes. Provided I'm following this correctly (always an open question ;D), this is exactly what I was looking for! If this is something you're willing to support it should definitely move out of the sandbox; and maybe even amass some "Here's how you make a source-specific citation template in the CS1 system" docs? I don't think most such templates exist as half-baked cut-n-paste code for any reason other than the lack of a better alternative. --Xover (talk) 08:55, 27 December 2017 (UTC)
One point I would make strongly is that, as for all source-specific templates, it's important that they include |mode= and any other parameters needed to enable them to be adapted to the existing style in an article, as per WP:CITEVAR. There have been issues in the past (and indeed ongoing) where source-specific templates only generated CS1 or generated only one format for access and archive dates.
More generally, it's surely a bad idea to call the module directly, rather than via a carefully documented template (such as {{Citation}} or the most appropriate of the "cite" templates). The more entry points there are into a Lua module, the harder it is to maintain and modify (as I know from experience with the automated taxobox system). Peter coxhead (talk) 09:35, 27 December 2017 (UTC)
The templates that use Module:Sandbox/trappist the monk/cs1 wrapper (or whatever its final name becomes) do not have to include |mode=. In {{cite Grove/sandbox}} |mode= does not exist, yet:
{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B |translator=Green, C |mode=cs2}}
Black, A; Brown, B, Root, Deane L., ed., Grove Music Online, translated by Green, C, Oxford University Press, (Subscription required (help)) 
This works because the wrapper module passes everything that it gets from the wrapper template to the wrapped template (encyclopedia in this example) which hands them off to Module:Citation/CS1 which knows about |mode= and all other cs1|2 parameters.
Trappist the monk (talk) 10:04, 27 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The new {{cite Grove}} template that uses Module:Sandbox/trappist the monk/cs1 wrapper has been in actual use (in an FA in mainspace) for a week now with no obvious ill effects. Perhaps the cs1 wrapper could migrate into Module:Citation/CS1/Wrapper (or similar) and be marked supported (but possibly also "experimental" until it gets wider use and testing)? I'm uncomfortable taking it further so long as it lives inside a user sandbox. --Xover (talk) 07:18, 8 January 2018 (UTC)

That looks nice. Even |mode=cs2 works, a pleasant surprise. I can imagine rewriting a lot of source-specific citation templates this way; for instance, {{Introduction to Algorithms}} would become both simpler and more flexible by not having to copy the arguments it doesn't actually use itself and by allowing a broader class of arguments (e.g. |page= or |at= in place of |pages=). —David Eppstein (talk) 07:43, 8 January 2018 (UTC)
Ok, moved. I've also added code to ignore empty editor-supplied parameters and added a keyword unset that may be used to 'unset' a default parameter:
{{cite Grove|subscription=unset}}
Root, Deane L. (ed.). Grove Music Online. Oxford University Press. 
And added vague documentation to the module.
Trappist the monk (talk) 13:09, 8 January 2018 (UTC)
Ah, perfect. Thank you! --Xover (talk) 15:25, 8 January 2018 (UTC)

trans-journal[edit]

Please add "trans-journal" parameter to Template:cite journal in order to translate foreign journal names into English.--Zoupan 05:56, 28 December 2017 (UTC)

I think script-journal would be useful—perhaps even more useful—since journal titles don't often get translated, but it would be nice to give the actual title and transliteration for titles in non-Latin scripts. Umimmak (talk) 06:33, 28 December 2017 (UTC)
Agreed. Publication names are usually not translated, so Le Monde, a newspaper in Paris, would not be given as The World in any typical citation. Imzadi 1979  16:11, 28 December 2017 (UTC)
There is an old request on the feature requests subpage to provide for {{lang}}-like parameters for all of the parameters in Citation. However, I have previously documented a parenthetical bunching problem, and I suspect this particular suggestion would exacerbate that issue. --Izno (talk) 17:09, 28 December 2017 (UTC)
Indeed, especially since Die Welt also translates as The World. --Redrose64 🌹 (talk) 21:53, 28 December 2017 (UTC)
Are the articles referenced in said journals in English? Localized-language sources are preferred for Wikipedia localized editions. A non-local-language in-source article should only be used when 1) it is unique and 2) there are no available reliable translations for it. 72.43.99.146 (talk) 16:02, 28 December 2017 (UTC)
Yes. Also: I don't see any point in translating the name of a foreign journal. E.g.: Die Welt is the name of that publication for all languages. If someone is competent enough in German to search for material written in German (because it's not available in English?) then they are competent enough to understand what the name means in English. Not that that is necessary: where a publication incorporates some foreign word – or for that matter, any technical, obscure, or even invented word – we do not need a translation or explanation in order to reference that publication. ~ J. Johnson (JJ) (talk) 23:54, 28 December 2017 (UTC)
That's fine for Die Welt, but what about (for instance) 香港經濟日報? Even if we transliterate it to Xiānggǎng Jīngjì Rìbào, our readers can't reasonably be expected to have the slightest idea that this is the Hong Kong Economic Times (an impeccable RS) without a translation to guide them. Even if it's not always used, the facility needs to be there. ‑ Iridescent 00:03, 29 December 2017 (UTC)
However, the Hong Kong Economic Times uses (I assume Mandarin) Chinese, without any obvious English facility. To reiterate my point above, any reference in non-Chinese Wikipedias using that publication as a source would be a bit of a red herring, as far as verifiability is concerned. One could certainly flag it as difficult to verify. 72.43.99.146 (talk) 14:15, 29 December 2017 (UTC)
The English Wikipedia allows the use of non English sources. Emir of Wikipedia (talk) 15:10, 29 December 2017 (UTC)
Of course. But, WP:NOENG. 50.74.121.43 (talk) 21:10, 29 December 2017 (UTC)
With reference to Japanese only, many academic journals have their own official English names, so that could go into the journal field without the need for a trans-journal field. However, a script-journal field might be helpful. Not as important as the original article title, but it always helps to look something up if you know the original. It would also address the problem that Japanese looks terrible in italics (one of the reasons why script-title was introduced for books). – Margin1522 (talk) 16:38, 29 December 2017 (UTC)

mediawiki and language names/code again[edit]

Previous discussion re: Bengali or Bangla. This time it's language code bh.

ISO 639-1 defines code bh as a synonym of ISO 639-2 code bih for 'Bihari languages'; see bih @ sil.org.

MediaWiki has remapped code bh for use as a subdomain name for the Bhojpuri language edition of Wikipedia https://bh.wikipedia.org (see List of Wikipedias).

cs1|2 attempts to fetch a language code from MediaWiki when |language= holds a name. With the remapping, when queried for language 'Bhojpuri', MediaWiki returns code bh. This code is used to categorize the article into one of the subcategories of Category:CS1 foreign language sources (639-1 two-character codes) or into Category:CS1 foreign language sources (ISO 639-2) (three-character codes). ISO 639-2 assigns bho to language name 'Bhojpuri' (bho @ sil.org); this is the code that MediaWiki should be returning.

We know that MediaWiki knows about bho because:

{{#language:bho|en}} → Bhojpuri

but:

{{#language:bh|en}} → Bhojpuri

or

{{#language:bih|en}} → bih

This last result, bih, is expected because ISO 639-1 has a synonym bh so bih would be omitted from the list of codes (this is the common practice).

I have tweaked Module:Citation/CS1/sandbox (Bengali included here because special case code for that language has been rewritten):

Cite book compare
{{ cite book | title=Title | language=bh }}
Live Title (in Bhojpuri). 
Sandbox Title (in Bihari). 
should be Bihari
Cite book compare
{{ cite book | title=Title | language=bih }}
Live Title (in bih). 
Sandbox Title (in bih). 
ISO 639-2 codes with 639-1 synonyms are not listed; module uses the code for language
Cite book compare
{{ cite book | title=Title | language=bho }}
Live Title (in Bhojpuri). 
Sandbox Title (in Bhojpuri). 
should be Bhojpuri
Cite book compare
{{ cite book | title=Title | language=bn }}
Live Title (in Bengali). 
Sandbox Title (in Bengali). 
should be Bengali

Trappist the monk (talk) 12:43, 30 December 2017 (UTC)

BCE dates in the date parameter[edit]

Is there currently a supported method (i.e., one that doesn't generate an error message) for specifying a BCE date in the date parameter of a CS1-based citation template? I've just encountered citations that use BCE dates for the first time ([1][2]) and I'm not really sure how to address the error messages without un-templating these citations. Seppi333 (Insert ) 04:08, 5 January 2018 (UTC)

References

  1. ^ Herodotus (2009) [440 BCE]. The Histories: Book II (Euterpe). Translated by George Rawlinson. 
  2. ^ Plato (2009) [360 BCE]. Timaeus. Translated by George Rawlinson. 
See discussion here: https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1/Archive_37#Years_and_Classical_publications_from_Antiquity . Remember |date= is for the date of publication of the actual work cited. Umimmak (talk) 06:56, 5 January 2018 (UTC)
Good point. Both of those links point to a text document which links to another page which don't include publication dates, but instead list "©1994-2009". I'm just going to assume 2009 is the republication date for both and use that in the date parameter instead. Seppi333 (Insert ) 08:22, 5 January 2018 (UTC)

Raised eyebrow[edit]

@Trappist the monk: So what is the problem with this edit? Paradoctor (talk) 16:15, 6 January 2018 (UTC)

Wrong place. WP:ACCESSDATE is a redirect that links to Help:Citation_Style_1#Access_date. Information at that location is more-or-less a word-for-word copy of the information that is found on all of the template documentation pages (which all get it by transcluding Template:Citation Style documentation/url).
The shortcut template goes at the target. Because you put {{shortcut}} inside the main documentation template that is transcluded into all of the cs1|2 template docs, you made it look like the shortcut linked to each of the individual template docs when in fact it did not. If this shortcut template is required, then it should go at the target, Help:Citation_Style_1#Access_date, not inside Template:Citation Style documentation/url. There can be only one target for a shortcut, right?
Trappist the monk (talk) 16:43, 6 January 2018 (UTC)
So what is problem with fixing the redirect instead of reverting? Paradoctor (talk) 17:29, 6 January 2018 (UTC)
Because
  1. I suck at mindreading
  2. the edit summary told me what was done but not why it was done
  3. I could not think of a use-case for that edit that made sense
Trappist the monk (talk) 20:05, 6 January 2018 (UTC)
"mindreading" / "told me what was done but not why it was done" Guess how I felt when I saw a revert that just ordered me to "discuss"? Face-wink.svg
"could not think of a use-case" For a shortcut box? You must have seen many more of them than I did. Well, whatever.
Now that that has been cleared, there will be no problem if I revert back and retarget the shortcut? Paradoctor (talk) 23:13, 6 January 2018 (UTC)
I could not, cannot, think of a use case where including {{shortcut}} in Template:Citation Style documentation/url which then transcludes into 25-ish cs1|2 template documentation pages thus creating 25-ish false targets. If there is a good reason to do that, please tell us.
Trappist the monk (talk) 00:01, 7 January 2018 (UTC)
I don't think that's going to be a productive use of my time, so I'll leave this conversation. Paradoctor (talk) 01:01, 7 January 2018 (UTC)
Also, it creates accessibility problems via horrifically mixed-up list markup. --Redrose64 🌹 (talk) 21:04, 6 January 2018 (UTC)
When the community decides to ditch wiki markup in favor of an object oriented document model, I'll be the first to open a cask of Amontillado. Until then, I'll dream of better times and stay the hell away from Lua. Face-tongue.svg Paradoctor (talk) 23:13, 6 January 2018 (UTC)
Who said anything about Lua? You dropped definition lists into the middle of unordered lists. Put simply - this is valid:
*Item
**Item
*Item
so is this:
*Item
*:Item
*Item
but this is not:
*Item
:*Item
*Item
The easiest way is to make sure that your new entry starts with the same symbol(s) as the entry above it, optionally adding one more symbol - whether asterisk, colon or hash - after the existing ones, not before them. --Redrose64 🌹 (talk) 23:32, 6 January 2018 (UTC)
This is the first time I became aware that this is one of the Help:List#Common mistakes. I referred to Lua because I only edited the list because the {{shortcut}} template breaks the bulleting when using the standard **... wiki markup. Now that I know the proper workaround for that, I'll use it, of course. Thanks, and happy editing. Paradoctor (talk) 00:04, 7 January 2018 (UTC)

Italic lint error[edit]

In some citations with italics in the title (if nowhere else), lint errors are being caused. (There is a similar issue reported by @IKhitron: regarding bolding at phab:T140358, and I've left some comments there.) One example is at Geodesic convexity, the Rapcsák reference, which I believe to be legitimate. Currently, the HTML served (so, module + parser + Tidy) is (abbreviated for relevance):

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b></i><sup>n</sup>.</cite>

-> Rapcsák, Tamás. Smooth nonlinear optimization in Rn. 

Like a previous post of mine at Template talk:Lang, this is clearly wrong, as the italics should surround the entirety of the title.

However, in a world where Tidy is turned off, the same citation returns:

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b><sup></sup></i>n<i></i>.</cite>

Which causes the misplacement of the sup tag and a subsequent visual rendering difference (in that the "n" is no longer superpositioned). (Aside: This seems also to cause a number of the errors related to the cite tag and template:Reflist in the misnesting category.)

The correct fix would be for all of the italic tags to be included (by changing Module:Citation/CS1/Configuration to add HTML italics rather than wikitext italics) and for the inner italics to be de-italicized. The HTML of that is the following:

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b><sup><i>n</i></sup></i>.</cite>

To de-italicize the inner italics, we would need to make a change to the CSS files of interest (at least on en.wp). However, making this particular fix would not preserve the italicization of the source currently: I have tested what happens when we have italics wrapping italics at this perma-link--in short, nothing! We could probably hack around this issue in this specific case at MediaWiki:Common.css by adding CSS to the tune of i sup i {font-style: normal;}, but this is sadly a not-so-general solution (I'll leave the exercise of futility to the reader). LESS could fix this according to StackOverflow, but we can't use LESS on-wiki.

So, the optimal solution to the problem is the following:

  1. Change Module:Citation/CS1/Configuration to italicize using HTML. This removes the lint errors (which is categorically good because of problems like that reference, IK's reference) but does not preserve the sense of the italics.
  2. Use LESS to style the <i> tag generally on Wikipedia (where its parent text is unitalicized, italicize; where its parent text is italizied, unitalicized). This would require a MediaWiki change.

I'm looking for thoughts, interim steps, and such agreement as can be found on Wikipedia (ping SSastry (WMF) for good measure) to a) making sure all of the italics render correctly, and b) the template is future-proof to the removal of Tidy. --Izno (talk) 02:54, 19 January 2018 (UTC)

All of your suggested formats are wrong. Math formulas in titles should not be italicized, because mathematics uses different font styles to encode different meanings, so changing the font style changes the meaning. Unfortunately, the {{math}} templates don't do anything to avoid italicizing when they are used in an italic context, and it would be really really ugly to put in explicit un-italic coding in the title parameter. So the only option we're left with is <math>:
{{cite book|last=Rapcsák|first=Tamás|title=Smooth nonlinear optimization in <math>\mathbf{R}^n</math>}}
Rapcsák, Tamás. Smooth nonlinear optimization in . 
David Eppstein (talk) 04:03, 19 January 2018 (UTC)
That's not an unreasonable approach in the context of math, but my problem is clearly more general. :^) --Izno (talk) 04:13, 19 January 2018 (UTC)
PS if you look up a preview of the book itself, you'll find that it's printed on the front cover as "Smooth Nonlinear Optimization in ", with an italic (not bold) R. So it's a bad example of the issue for multiple reasons. —David Eppstein (talk) 04:41, 19 January 2018 (UTC)
I think quote parsing in MediaWiki is somewhat hacky because of unintended interactions between quotes in template args and quotes in the template source and this seems to be a common problem (I've seen this on many wikis including itwiki, svwiki, and others). But, I digress. In this case, what I have seen itwiki do is exactly what Izno proposes which is to change the template to use the HTML <i> tag instead of '' and <b> tag instead of '''. I recommended the same solution for svwiki. That said, given that some pages (like the Geodesic convexity example) "hack" their way to intended rendering by deliberately breaking quoting, with this fix by itself, rendering for those refs can change. I feel like using CSS to preserve it is another hack (which, we could add if it became necessary, but not sure what other unintended effects it could have). Ideally, the pages using this hack would be changed. One option is to use math as User:David Eppstein recommends. Another is to use a styled span tag around the text that needs de-italicising. But, that depends on how many pages are actually relying on this quote-hack. SSastry (WMF) (talk) 05:15, 19 January 2018 (UTC)
Thank you for noticing. Something weird. The problem I described in the task was fixed a couple of months ago. I totally forgot about filing the task, closed it now. It was my understanding of situation - the cause was <span /> in the code of the module. It was fixed in enwiki, and I fixed it in our wiki when I been told about this. I believed there could not be something you're describing. Can you please give a simple nowiki example that can create a problem in enwiki now? IKhitron (talk) 10:29, 19 January 2018 (UTC)
I'm on wiki break right now so my participation in this conversation will be sporadic. The <math>...</math>-markup-in-cs1|2-titles-solution is problematic. It used to be that the module could extract the raw content of markup for use in its metadata, but MediaWiki was broken some time ago and never fixed. See this and linked discussions.
Presently, cs1|2 render an error message in the metadata in lieu of a stripmarker:
<cite class="citation book">Rapcsák, Tamás. ''Smooth nonlinear optimization in '"`UNIQ--math-000000D8-QINU`"'''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Smooth+nonlinear+optimization+in+MATH+RENDER+ERROR&rft.aulast=Rapcs%C3%A1k&rft.aufirst=Tam%C3%A1s&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"><span style="display:none;">&nbsp;</span></span>
Trappist the monk (talk) 12:02, 19 January 2018 (UTC)

Lay source[edit]

I discovered during my work for the above that the current module processes LaySource by adding italics and then invoking safe_for_italics (and then closing the italics). Is there a reason we're not using wrap_style here (I think it's possible but I can be told I'm wrong :D)? --Izno (talk) 03:42, 19 January 2018 (UTC)

The more important question is: should cs1|2 support lay sourcing at all? If the lay source is important enough to cite, shouldn't it get its own cs1|2 template? Aren't cs1|2 templates intended to cite a single source per template? That is, after all the reason cs1|2 doesn't support multiple ISBNs; why should a layman's version of a source be any different?
Trappist the monk (talk) 12:07, 19 January 2018 (UTC)
What is a lay source? Also, "shouldn't it get its own cs1|2 template" is confusing. Of course we do not have separate cs1 or 2 templates for each source, such as the notional {{cite-tale-of-two-cities}}.So it isn't clear what this phrase means. Jc3s5h (talk) 16:39, 19 January 2018 (UTC)
I would guess a "lay source" (it's completely undocumented from what I can tell) is a source which explains a source only understandable by subject matter experts. There are only about 3k uses.— Preceding unsigned comment added by Izno (talkcontribs) 17:27, 19 January 2018 (UTC)
Template:Cite journal#Lay summary.
Trappist the monk (talk) 01:43, 20 January 2018 (UTC)

Is language=Bengali an error?[edit]

I am seeing articles in Category:CS1 maint: Unrecognized language due to |language=Bengali (example: 1950 East Pakistan riots), but this apparently official link says that Bengali is the official language name. What am I missing? – Jonesey95 (talk) 16:35, 19 January 2018 (UTC)

Help talk:Citation Style 1#mediawiki and language names/code again. The sandbox accepts Bengali and bn even though MediaWiki thinks that bn = {{#language:bn|en}} → Bangla.
Trappist the monk (talk) 01:39, 20 January 2018 (UTC)