Misplaced Pages

Revision as of 11:26, 23 October 2021

This template was considered for deletion on 2019 April 18. The result of the discussion was "Move patent citations out of {{Citation}} and into {{Cite patent}}, deprecate the dedicated code in {{Citation}} for patents".

This is the talk page for discussing improvements to the Citation template.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9Auto-archiving period: 3 months

To-do list for Template:Citation: edit · history · watch · refresh · Updated 2015-04-20 There are no active tasks for this page

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9

This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III.

Non-breaking spaces

Why does the template throw ugly errors on the page for non-breaking spaces in content, including in names, titles, quotations, and other fields? Like this:

1. Non-breaking spaces are a normal part of written text. They are absolutely required in practically all kinds of text, including in normal content from sources cited, according to our own Manual of Style and authoritative references. They are also mandatory for common punctuation in foreign-language text (e.g., in French for colons, semicolons, question marks, and exclamation marks).
2. If there is a reason to flag these, then an invisible error should only show up in previews and in the Visual Editor. It should not create ugly breakage in article text displayed to the reader, interfering with reading.
3. The basic template docs should explain this.

Example of error messages generated by correct text:

• J. K. Doe (2021), L'espace insécable : oui!, Quoi ? {{citation}}: no-break space character in |author= at position 3 (help); no-break space character in |quote= at position 5 (help); no-break space character in |title= at position 19 (help)

Example of mandatory non-breaking spaces in typographically correct normal English usage:

• En dashes: NBSP-dash-space, according to MOS:DASH
• Ellipses: NBSP-dot-dot-dot per MOS:DOTDOTDOT, or space-dot-NBSP-dot-NBSP-dot per the CMOS
• Initials: J.-NBSP-R.-NBSP-R. Tolkien, per MOS:INITIALS

It drives me nuts to get these messages all the time when I’ve pasted correct text into references, and then have to go track down the correct invisible characters that I or someone else has taken the trouble to enter, strip them out, and see the citation content display incorrectly in an article. Based on no rationale that I can fathom. —Michael Z. 17:08, 4 March 2021 (UTC)

Because intentional non-breaking spaces should be declared with  , not just the direct character. Headbomb {t · c · p · b} 17:26, 4 March 2021 (UTC)

And if you just want to clear the errors, just run User:Citation bot on the article, and it will remove all invisible non-breaking spaces. Headbomb {t · c · p · b} 17:47, 4 March 2021 (UTC)

Per MOS:NBSP:

Insert non-breaking and thin spaces symbolically ({{nbsp}}, {{thinsp}},   or  ), never by entering them directly into the edit window from the keyboard – they are visually indistinguishable from regular spaces, and later editors will be unable to see what they are.

But, the templates {{nbsp}}, {{thinsp}} should not be used in cs1|2 template parameters because they render extraneous markup that corrupts the citation's metadata. The templates render like this:

<span class="nowrap">&nbsp;</span> ← {{nbsp}}

<span style="white-space: nowrap;">&thinsp;</span> ← {{thinsp}}

Careful construction of parameter values may be something that you do, but, the vast preponderance of the no-break space character in |<param>= at position n that I have fixed are copy/pastes from sources that appear to use no-break space characters indiscriminately.

And, last point, cs1|2 are not CMOS, are not APA, are not Bluebook, are not any published style. cs1|2 are amalgams of various styles plus stuff that en.wiki have decided for themselves to make part of the cs1|2 styles.

—Trappist the monk (talk) 17:47, 4 March 2021 (UTC)

Thank you. Is anyone able to fix this? Please update the error message text so:

1. It makes this clear, say, as Unicode no-break space character in |title= at position 00 should changed to latin entity &⁣nbsp;?
2. It only appears in previews and editing?

I can update the documentation.

There still remains a problem that literal NBSPs will be transcluded from sources that we have no control over, i.e., in {{cite q}}, and I will mention that problem at the relevant talk page. —Michael Z. 17:49, 4 March 2021 (UTC)

Updated docs. —Michael Z. 17:57, 4 March 2021 (UTC)

@Mzajac, I've been annoyed by this, too. Help talk:Citation Style 1/Archive 74#ISBN line breaking redux may be related. {{u|Sdkb}}  05:10, 27 August 2021 (UTC)

The proposed HTML simplifier in CS1/CS2 and a scheme to enhance other templates (like {{nbsp}}, {{thinsp}}, {{lang}}, {{nowrap}}...) to emit internal metadata for CS1/CS2 might become part of a possible solution to this problem, see Help_talk:Citation_Style_1#Guidance_for_science_etc.

--Matthiaspaul (talk) 13:33, 28 September 2021 (UTC)

Harv warning

Practically every page on WP has a lot of "Harv warning"s - including this template's own documentation. I understand that originally the templates defaulted to |ref=none and that this warning was only shown if |ref=harv was used - which makes sense. But a while back |ref=harv became the default. So when any cite template is used for things like bibliographies (which are not meant to have <ref>...</ref> pointing to them, otherwise they would be reference entries, not bibliography entries), we get nasty orange warnings littering so many pages. We can add |ref=none to all these entries (and I have done for a few articles) but this is adding yet another burden to the editors and has complications when used with {{sfn}}. Can we turn these warnings off.  Stepho  talk  12:44, 24 April 2021 (UTC)

The warnings do not come from this template or from any of the cs1 templates. The warning and error messages are created by a user script. To get rid of the warnings, you must remove importScript('User:Ucucha/HarvErrors.js'); from User:Stepho-wrs/common.js. But, that will also prevent you from detecting any short-form-to-long-form link errors. You may be able to customize the Ucucha script; see its documentation at User:Ucucha/HarvErrors.

—Trappist the monk (talk) 13:03, 24 April 2021 (UTC)

Weird. I have no memory of editing that file but removing it did fix the problem. Thanks.  Stepho  talk  11:41, 25 April 2021 (UTC)

Permament errors

Post moved to Help talk:Citation Style 1/Archive 78#Permanent_errors. --BrownHairedGirl (talk) • (contribs) 01:51, 21 August 2021 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Category:CS1 errors: unsupported parameter includes 22 pages in the Misplaced Pages namespace: 14 AFD pages, and 8 pages from the Signpost.

These pages should not be edited, so they are perma-clutter in this cleanup category.

Please can the CS1/2 module(s) be modified to stop categorising citation errors in these pages? Cleanup categories should be capable of being fully cleaned up, but these pages prevent that. --BrownHairedGirl (talk) • (contribs) 21:56, 20 August 2021 (UTC)

Possibly doi-access could be "abstract" or "limited"

doi-access, and similar access parameters deemed to be normally paywalled, only allow value "free" (deemed normally to be "subscription"). It's fairly common to allow free access to the abstract, only, of a paper, which is usually a lot better than nothing at all. Possibly a little more than an abstract is sometimes offered; I'm not sure. I would suggest allowing value "abstract" (and possibly "limited") for these access parameters, with suitable displayed wording such as "free access to abstract only". Possible counter-argument: free access to abstract is very common, perhaps universal, so no real need to specify. Up for discussion. Best wishes, Pol098 (talk) 13:24, 20 September 2021 (UTC)

Put me in the oppose category. I'm sure that I've seen publisher sites where everything is paywalled except some amount of bibliographic information. I've seen paywalled sites where you can read the first page of an article (abstract, first paragraph or a bit more, and a footnote or two). I've seen paywalled sites where an article's reference list is reproduced. If you want to cite something in a journal article's abstract and the abstract is available on the journal article's landing page, use {{cite web}}, set |type=abstract, and omit |doi= or other identifier.

If we support minor variants like |<identifier>-access=abstract for free access to abstract only, where does it end?

—Trappist the monk (talk) 13:57, 20 September 2021 (UTC)

Without trying to push the matter, the large variety of partial information that could be available might possibly justify |<identifier>-access=limited. But I take it that Trappist the monk is against it, and I'm not strongly for it because, as a reader, I'm aware that clicking a DOI link is often useful even without full-text access. Pol098 (talk) 15:06, 20 September 2021 (UTC)

Or alternatively, simply a {{cite journal |... |doi=... |at=Abstract}} or See abstract in {{cite journal |... |doi=...}} if you're citing the abstract. Headbomb {t · c · p · b} 15:16, 20 September 2021 (UTC)

While we should be careful in our selection of possible states and not introduce semantical redundancy, I think these various access and status parameters don't make any sense at all if the real-world states cannot intuitively be associated with the supported states. So, to answer the question, IMO it should stop when we have covered a reasonable abstraction of possible real-world cases. This may also require to review the set of supported states once in a while in order to check if new real-world states have emerged which are worth to be included. --Matthiaspaul (talk) 22:22, 20 September 2021 (UTC)

How to add lang attribute to chapter title?

It seems the template doesn't add a lang attribute to a chapter title based on |language=. Is this intended or not? If it is intended I'll use {{lang}} for that job? Thanks in advance for any help, (pings appreciated) --Marsupium (talk) 17:47, 20 September 2021 (UTC)

It is as intended. We cannot know that the title or chapter-title is in the same language as the text of the rest of the book. If the title or chapter title is written using a non-Latin script, use |script-title= or |script-chapter=. Do not use {{lang}} in cs1|2 |title=, |chapter=, or any other parameter that contributes to the citation's metadata; doing so will corrupt the metadata.

—Trappist the monk (talk) 17:54, 20 September 2021 (UTC)

I propose to allow all language codes in |script-title= and |script-chapter=, not just those for non-Latin scripts. For those in the short list of non-Latin scripts, the parameter would behave just as before (bdi etc.), but for the other codes, after stripping off the code, it would contribute to |title=, but we would have a proper language code we could use for the lang= attribute. See also:

• Help_talk:Citation_Style_1/Archive_67#Possible_improved_treatment_of_title_parameters_and_language_attributes
• Help_talk:Citation_Style_1/Archive_72#Value_for_script-title
• Help_talk:Citation_Style_1/Archive_73#Guidance_about_indexing_by_first_name?

--Matthiaspaul (talk) 22:10, 20 September 2021 (UTC)

Brings up a related issue: At present we also don't set the lang= attribute of the <q> element in |quote= sections. Given that the quote is an extract of the contents of the publication written in the language specified by |language=, I think we would be safe to assign this attribute to the <q> element. (|script-quote= already uses lang=, but only for the <bdi> defined by |script-quote=, not for the quote as a whole.)

--Matthiaspaul (talk) 13:46, 28 September 2021 (UTC)

Free-form "Editors"?

Hi. The template already supports a free-form "authors" field. Could it support a similar free-form "editors" field, please? Thanks. fgnievinski (talk) 05:15, 23 October 2021 (UTC)

No. |editors= was deprecated at this edit and removed at this edit. Of all the 'name' (author, contributor, editor, interviewer, translator) parameters, the only free-form parameter is |authors=. Use of |authors= is discouraged; see Template:Citation § Authors.

—Trappist the monk (talk) 11:25, 23 October 2021 (UTC)

• Misplaced Pages pages with to-do lists