Help talk:Citation Style 1
This is the talk page for discussing improvements to the Citation Style 1 page. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95Auto-archiving period: 21 days ![]() |
![]() | To help centralise discussions and keep related topics together, the talk pages for all Citation Style 1 templates and modules redirect here. A list of those talk pages and their historical archives can be found at Help talk:Citation Style 1/Centralized discussions. |
![]() | This help page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||
|
This is the talk page for discussing improvements to the Citation Style 1 page. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95Auto-archiving period: 21 days ![]() |
Access locks on paywalled links: lock color and hover text
We have some access-lock images which are occasionally used to indicate whether a source is paywalled or not. One of them is File:Lock-red.svg. It's bright red (), with a transparent background. The {{cite journal}} source code uses it to indicate paywalled sources.
I don't like the bright red. Why? Because, as Mark viking pointed out six months ago,[1] many paywalled sources let you read the abstract for free, or a page or two for free. Please correct Mark and I if we're wrong, but we think that bright red may imply "you can't read any of this for free". This may mislead our readers, and dissuade them from clicking through and reading abstracts for free.
I think that we should use some color other than bright red.
We could use dark red (like this). And then we could add a white background or white border, to make sure that users reading Wikipedia on a black background would get sufficient contrast. In fact, if you look through the file history of Lock-red.svg, you'll see that it used to be dark red, until it changed to light red this past September.
Or we could use gray (on a transparent background), or black (on a white background), or any other color.
Thoughts?
Kind regards, —Unforgettableid (talk) 02:30, 22 February 2017 (UTC)
- The dark red fails one of the criteria we established for the icon designs, to wit: contrast against both white and black backgrounds. This is important for the visually impaired and for those who invert their colors (light text on a dark or black background).
- As part of the initial discussions I proposed a series of icons that were all blue; access indicated by the lock shape only. That idea was shot down because others believed that multiple indications of access (shape and color) are better than the single (shape alone).
- Before continuing this conversation, might I recommend that you spend some time in the archives of this page reading the discussions that got us to where we are today? I think that the bulk of it begins in Archive 22.
- —Trappist the monk (talk) 03:54, 22 February 2017 (UTC)
- Dear Trappist: The problem with the old dark-red access lock icon is that it had a transparent background. This made it nearly invisible when the icon was superimposed upon a black webpage. I see four possible workarounds: A) Underlay a white rectangle beneath the dark-red lock. B) Or a white rounded rectangle. C) Or a white oval. D) Or add a thick white outline to the dark-red lock. Even three or four pixels thick, if you want. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
- Sure, those are work-arounds. But, neither you nor I have the power to change that which was decided by RFC, do we? Without another RFC that overrides the current consensus, the access signals shall have the forms and colors that were determined by the visual design RFC.
- —Trappist the monk (talk) 03:56, 23 February 2017 (UTC)
- In that RFC, Headbomb offered a choice of multiple colors for the free-access lock and the partial-access lock. But the only color choice he offered for the paywall lock was bright red. (In other words, bright red was the only choice available on the ballot.) Because the ballot offered no choice in the matter, I believe it might be inaccurate to say that the RFC participants agreed to make it bright red. I believe it'd be more accurate to say that the lock ended up bright red by default. —Unforgettableid (talk) 04:27, 23 February 2017 (UTC)
- Only one color was offered for the free access lock, green. The only one where there was a choice was the partial access lock, yellow vs blue which left very few people happy. I personally believe Green/Grey/Red will gain support the next time we ask, but it's possibly Green/Grey/Grey will get it too. Green/Blue/Red is a a truly ridiculous scheme that makes zero sense, and people only went for it because the yellow was felt 'not yellow enough' or WP:ACCESS unfriendly. Headbomb {talk / contribs / physics / books} 04:54, 23 February 2017 (UTC)
- In that RFC, Headbomb offered a choice of multiple colors for the free-access lock and the partial-access lock. But the only color choice he offered for the paywall lock was bright red. (In other words, bright red was the only choice available on the ballot.) Because the ballot offered no choice in the matter, I believe it might be inaccurate to say that the RFC participants agreed to make it bright red. I believe it'd be more accurate to say that the lock ended up bright red by default. —Unforgettableid (talk) 04:27, 23 February 2017 (UTC)
- Look also at the post timestamped at "22:42, 10 February 2017 (UTC)" on this page for possible alternatives, some of which include gray. Headbomb {talk / contribs / physics / books} 12:17, 22 February 2017 (UTC)
- That gray is fine, though I still suspect that I prefer dark red. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
- The dark red would still violate WP:ACCESS. Headbomb {talk / contribs / physics / books} 04:46, 23 February 2017 (UTC)
- I've thought of some possible workarounds, and described them, in a comment which you probably haven't read yet. Search through this page for the phrase [ four possible workarounds ] if you'd like to learn about them. I believe that, with the workarounds, dark red is a viable option. —Unforgettableid (talk) 05:52, 23 February 2017 (UTC)
- Those aren't viable workarounds. A white rectangle underneath the lock for instance, would look downright awful and be very distracting. Likewise for the other choices. Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)
A) How about a thin white outline, perhaps one pixel thick or a few pixels thick? B) What percent of our readers view Wikipedia on a black background? I suspect that it's a tiny percentage. Shouldn't we care more about making things look nice for the majority than for the minority? —Unforgettableid (talk) 14:39, 24 February 2017 (UTC)The question on the left hasn't yet been answered. After someone replies, please remove this notice. - The colors and shapes of the access signals lock was decided by the visual design RFC. Must I repeat myself? Neither you nor I have the authority to arbitrarily overturn such a decision. The number of readers who use an inverted color scheme is irrelevant; those who do deserve to be accommodated if it is possible to do so.
- —Trappist the monk (talk) 11:17, 8 March 2017 (UTC)
- Those aren't viable workarounds. A white rectangle underneath the lock for instance, would look downright awful and be very distracting. Likewise for the other choices. Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)
- I've thought of some possible workarounds, and described them, in a comment which you probably haven't read yet. Search through this page for the phrase [ four possible workarounds ] if you'd like to learn about them. I believe that, with the workarounds, dark red is a viable option. —Unforgettableid (talk) 05:52, 23 February 2017 (UTC)
- The dark red would still violate WP:ACCESS. Headbomb {talk / contribs / physics / books} 04:46, 23 February 2017 (UTC)
- One thing we could possibly add to the hover text is "Paid subscription required, abstract or excerpt may be available" instead of just "Paid subscription required". Headbomb {talk / contribs / physics / books} 12:44, 22 February 2017 (UTC)
- Dear @Headbomb: Good idea. In fact, maybe we could provide even more alt text than that. Perhaps this: "A summary or excerpt may be available for free. However, to read the full text, you must either buy access or visit a library with a paid subscription. Try phoning your nearest university library." In addition, perhaps we could even add a dotted underline and a fancy cursor.
border-bottom: 1px dotted #000; cursor: help;
This would help readers realize that there's useful alt text, and that they should wait a second for it to appear. You can see a live preview of the full package at this link. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)- That is a ridiculously long message. 'Paid subscription required, abstract or excerpt may be available' covers all of that. I'm not against the cursor/underlining though. Headbomb {talk / contribs / physics / books} 04:45, 23 February 2017 (UTC)
- Both you and I have been to university. Also, both you and I both know that we can get free online access to many papers at a university library. But many laypeople don't know this. In fact, even some university graduates don't know this. For those in the know, we're wasting their time by writing so much hover text. But these people can quickly learn what the paywall lock means. They can read the hover text once, understand it, and never feel a need to hover their mouse over a paywall lock ever again. But, for high-school students and other individuals not in the know, we may be opening their eyes (maybe for the first time ever) to vast trove of scholarly knowledge. —Unforgettableid (talk) 06:09, 23 February 2017 (UTC)
- It's not a matter of having been to university or not, it's a matter of the message being exceedingly long. This is a message that will need to be read by screen readers several times per article, and thus needs to be short. This is why all the messages are short and to the point, e.g. "Free registration required" instead of "You are required to register to read this article, but it does not cost money to do so. Websites will typically asks for your email and some personal information. You could also ask a friend to register for you, or register with a dummy email if you do not trust the website with your personal information, however this may violate their terms of service. Your password and login information might be stored in a cookie. That being said, an excerpt might still be available to unregistered users."
- "Paid subscription required" implies a subscription is required to have access to the full version; it doesn't matter if it's yours, your supervisor's, your friend's or the library's institutional subscription. If you have short wordings, those could be suitable however. But they need to be short, e.g. "Paid or library subscription required, free abstract or excerpt may be available". Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)
- Both you and I have been to university. Also, both you and I both know that we can get free online access to many papers at a university library. But many laypeople don't know this. In fact, even some university graduates don't know this. For those in the know, we're wasting their time by writing so much hover text. But these people can quickly learn what the paywall lock means. They can read the hover text once, understand it, and never feel a need to hover their mouse over a paywall lock ever again. But, for high-school students and other individuals not in the know, we may be opening their eyes (maybe for the first time ever) to vast trove of scholarly knowledge. —Unforgettableid (talk) 06:09, 23 February 2017 (UTC)
- That is a ridiculously long message. 'Paid subscription required, abstract or excerpt may be available' covers all of that. I'm not against the cursor/underlining though. Headbomb {talk / contribs / physics / books} 04:45, 23 February 2017 (UTC)
- Dear @Headbomb: Good idea. In fact, maybe we could provide even more alt text than that. Perhaps this: "A summary or excerpt may be available for free. However, to read the full text, you must either buy access or visit a library with a paid subscription. Try phoning your nearest university library." In addition, perhaps we could even add a dotted underline and a fancy cursor.
- That gray is fine, though I still suspect that I prefer dark red. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
- Dear Trappist: The problem with the old dark-red access lock icon is that it had a transparent background. This made it nearly invisible when the icon was superimposed upon a black webpage. I see four possible workarounds: A) Underlay a white rectangle beneath the dark-red lock. B) Or a white rounded rectangle. C) Or a white oval. D) Or add a thick white outline to the dark-red lock. Even three or four pixels thick, if you want. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
Ah OK fair. Your point about screen readers is a good one. Indeed, I looked into the matter just now; and it turns out that screen readers will indeed read out the image's title
text in this case. (Source.) And your little speech discussing dummy emails and cookies made me laugh. :) How's this?: "Paid or library access required; but a summary may be available for free. Click for help." —Unforgettableid (talk) 19:05, 23 February 2017 (UTC)
- Locks aren't currently clickable and aren't linked to anything. Where would clicking on the lock take people? Headbomb {talk / contribs / physics / books} 19:29, 23 February 2017 (UTC)
- There need not be anything clickable for a
title=
attribute to be used; it is valid on most HTML elements since HTML 4.00, and all elements from HTML5 onward. From the HTML 4.01 spec:
Try hovering your mouse here. --Redrose64 🌹 (talk) 20:09, 23 February 2017 (UTC)Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tooltip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context.
Clicking on the paywall lock could take readers to Wikipedia:Find your source. Would this work? —Unforgettableid (talk) 14:48, 24 February 2017 (UTC)The question on the left hasn't yet been answered. After someone replies, please remove this notice.
- There need not be anything clickable for a
- MediaWiki copies the image's
alt=
attribute text into thetitle=
attribute. No need to muck withtitle=
attributes and no need for the image to be clickable. - —Trappist the monk (talk) 20:17, 23 February 2017 (UTC)
- Not true: consider the twelve images in Headbomb's post of 22:42, 10 February 2017 (UTC) beginning "No, we unrestrict their use on identifiers and urls" in the section #Whatever happened to the access lock RFCs? - here, all twelve images have the
alt=
attribute, and none of them have atitle=
attribute. --Redrose64 🌹 (talk) 21:58, 23 February 2017 (UTC)- I think that we are both mistaken. Your mistake: none of those twelve images have
alt=
attributes – though some have 'alt' in their name: - My mistake: MediaWiki does not copy
alt=
intotitle=
. Rather, it is done in Module:Citation/CS1/Configuration where the lock images are defined like this:[[File:Lock-green.svg|9px|link=|alt=Freely accessible|Freely accessible]]
→
- where the text to the right of the pipe is assigned to the
title=
attribute. - —Trappist the monk (talk) 23:09, 23 February 2017 (UTC)
- They do have
alt=
attributes. Use your browser's "View page source" feature. Search for the text<img alt="Lock-green.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png"
You should find six instances, other than the one in this post. All six are identical: the<img />
tag has seven attributes, being (some values replaced with an ellipsis for clarity)alt="Lock-green.svg" src=... width="9" height="14" srcset=... data-file-width="512" data-file-height="813"
. There is analt=
attribute; there is not atitle=
attribute. The enclosing<a href="/wiki/File:Lock-green.svg" class="image">...</a>
element doesn't have atitle=
either. --Redrose64 🌹 (talk) 01:33, 24 February 2017 (UTC)- So they do. MediaWiki copies the image file name into the
alt=
attribute. Better that than nothing I suppose. - —Trappist the monk (talk) 11:12, 24 February 2017 (UTC)
- So they do. MediaWiki copies the image file name into the
- They do have
- I think that we are both mistaken. Your mistake: none of those twelve images have
- Not true: consider the twelve images in Headbomb's post of 22:42, 10 February 2017 (UTC) beginning "No, we unrestrict their use on identifiers and urls" in the section #Whatever happened to the access lock RFCs? - here, all twelve images have the
The documentation implies that Links inserted by identifiers such as |doi=
are not expected to offer a free full text by default So I am expecting the subscription will be set to yes by default if one of these is set. But it isn't. Hawkeye7 (talk) 21:20, 10 March 2017 (UTC)
- If you mean that the template sets
|subscription=yes
if|doi=
or other identifier is set, then no, that does not happen. The problem with|subscription=
is that it doesn't specify which external link,|url=
or one of the identifiers – there can be multiples – requires the subscription. As the code stands now, it assumes, correctly, that most identifiers (like|doi=
) rarely offer free access to the source. We do not highlight the norm. When|doi=
refers to a source that is free-to-read, editors may add|doi-access=free
to highlight that identifier. There are exceptions: a couple of identifiers are automatically flagged because it is known that these identifiers are always free-to-read (|arxiv=
,|rfc=
, etc). In the same sense,|url=
and|chapter-url=
and their aliases are assumed to be free-to-read. Again, we don't hightlight the norm but when these are not free-to-read, editors may set|url-access=subscription
, etc. - —Trappist the monk (talk) 21:48, 10 March 2017 (UTC)
- But a
|doi=
card does not trigger a "subscription required" note, nor does a|jstor=
card; so|doi-access=free
is the default. Hawkeye7 (talk) 23:07, 10 March 2017 (UTC)- What is
card
?
- What is
-
- No,
|doi-access=free
is not the default because we do not highlight the normal state, either with an icon or with text. For most identifiers the links normally link to sources behind a registration or subscription wall. Because of this, there is no need to clutter the rendered citation with extraneous access signals. - —Trappist the monk (talk) 23:17, 10 March 2017 (UTC)
- No,
- But a
"|registration=yes" and "|subscription=yes" rendering is awful
(Sorry to add this new section not at the end of the page, but it's related to the one above.)
I brought this up awhile back, but didn't have time to pursue it further then. I'll quote here my main points from before:
- I was just editing an article where one of the citations required (free) registration to read, so I looked at the {{cite web}} template and found there was a "|registration=yes" parameter, so I added that. However, it renders so poorly and confusingly for readers -- "(registration required (help))." with the help tooltip giving "Sources are not required to be available online. Online sources do not have to be freely available. The site may require registration." -- that I reverted my change and just added "(Registration required.)" at the end of the <ref> manually.
- First off, the "r" in "registration" should be capitalized if there's a period at the end, and the period should go inside the parentheses, not outside. Secondly, "Sources are not required to be available online. Online sources do not have to be freely available." must be very confusing to the average reader. I don't think it's helpful to the average reader to obliquely define Wikipedia reference inclusion policy in the help for what the tag means. Finally, why the weasel words in "may be required"? The parameter says "registration=yes", and it renders as "registration required" -- the "may be" has no business being there.
And the same is true for "|subscription=yes". Thank you, Trappist the monk, for pointing me to where I would need to make my suggested changes. I have just edited Module:Citation/CS1/Configuration/sandbox to change:
- (registration required (<span title="Sources are not required to be available online. Online sources do not have to be freely available. The site may require registration." style="border-bottom:1px dotted;cursor:help">help</span>))
to:
- (Registration required (<span title="The site requires registration to access this page." style="border-bottom:1px dotted;cursor:help">help</span>))
and:
- (subscription required (<span title="Sources are not required to be available online. Online sources do not have to be freely available. The site may require a paid subscription." style="border-bottom:1px dotted;cursor:help">help</span>))
to:
- (Subscription required (<span title="The site requires a paid subscription to access this page." style="border-bottom:1px dotted;cursor:help">help</span>)
I see that the period after the ")" gets added elsewhere, and may be done in such a way that it would be difficult to omit it for registration=yes and subscription=yes so that the period can be placed inside the parentheses in the above text, so I have not yet looked into that. Before I do, I wanted to see what the reaction was to my suggested changes and the logic behind them. Thank you. --Dan Harkless (talk) 01:26, 14 April 2017 (UTC)
- I guess I wouldn't worry too much about the separator character. If one is to believe the outcome of this rfc, then both
|subscription=
and|registration=
will be going away. - —Trappist the monk (talk) 12:32, 14 April 2017 (UTC)
- I wouldn't believe the outcome of that rfc. Its conclusions, well-meaning as they are, are self-contradictory: aspect B1 allows all locks (
"the editorial discretion of individual Wikipedians should be allowed and supported
"), but aspect B3 imposes them by not offering any other alternative (). 65.88.88.126 (talk) 14:33, 17 April 2017 (UTC)"the editorial discretion of individual Wikipedians should be allowed and supported"
- Flagging would be allowed, whether to do so or not would be up to editor's discretion. There's no contradiction. Headbomb {t · c · p · b} 14:58, 17 April 2017 (UTC)
- Using the facilities of CS1, I would like to not use locks as allowed to, but I would like to flag access requiring subscription, as also allowed to. Any ideas? 65.88.88.126 (talk) 16:08, 17 April 2017 (UTC)
- The access of what is the question. URLs? arXiv links? DOIs? JSTOR identifiers? Simply appending "subscription required" at the end of the citation is ambiguous. How would you like things rendered? Do you have a mockup? Headbomb {t · c · p · b} 16:24, 17 April 2017 (UTC)
- Not what I am asking. The exact placement or wording of the flag to be applied is not relevant to my question. All I want to be able to do is to signal subscription requirement, but without using locks. It seems that locks are locked in when it comes to this. If that is the case, the RFC close mis-informs, possibly because the RFC itself did not clarify that subscription/registration access flags are apparently dependent on the lock scheme. Aspect B3 may not be independent, but a sub-aspect of Aspect B1. Something like this should have been pointed out, as it may have been material to the RFC's consideration. 65.88.88.126 (talk) 18:08, 17 April 2017 (UTC)
- Then what you would like is not a viable or sustainable option. The reasons have been explained to you, and the community agrees on this. Headbomb {t · c · p · b} 18:11, 17 April 2017 (UTC)
- And my point is that the community was presented with a partly false or incomplete set of options. Aspect B3 was not fully explained as dependent on Aspect B1. This may have affected the outcome. It certainly affected the closing, and the closer's comments, which seem contradictory as indicated above. 65.88.88.69 (talk) 19:51, 17 April 2017 (UTC)
- Then what you would like is not a viable or sustainable option. The reasons have been explained to you, and the community agrees on this. Headbomb {t · c · p · b} 18:11, 17 April 2017 (UTC)
- Not what I am asking. The exact placement or wording of the flag to be applied is not relevant to my question. All I want to be able to do is to signal subscription requirement, but without using locks. It seems that locks are locked in when it comes to this. If that is the case, the RFC close mis-informs, possibly because the RFC itself did not clarify that subscription/registration access flags are apparently dependent on the lock scheme. Aspect B3 may not be independent, but a sub-aspect of Aspect B1. Something like this should have been pointed out, as it may have been material to the RFC's consideration. 65.88.88.126 (talk) 18:08, 17 April 2017 (UTC)
- The access of what is the question. URLs? arXiv links? DOIs? JSTOR identifiers? Simply appending "subscription required" at the end of the citation is ambiguous. How would you like things rendered? Do you have a mockup? Headbomb {t · c · p · b} 16:24, 17 April 2017 (UTC)
- Using the facilities of CS1, I would like to not use locks as allowed to, but I would like to flag access requiring subscription, as also allowed to. Any ideas? 65.88.88.126 (talk) 16:08, 17 April 2017 (UTC)
- You will notice that what I wrote, included a caveat. The RfC closer wrote:
This I believe leaves us in some sort of limbo. When previously I asked how we should proceed, I don't think that I got a compellingly definitive answer. There are those who believe that we should revert all of the access-signal-related changes; there are those who believe that we should implement the individual aspects of the RfC that received consensus no matter how slight; there are those who believe that, for now, we should do neither of those things and continue with the status quo pending supplementary RfCs. I find myself in this latter camp because of closer's writing quoted above and because the status quo version of access-signal support is already out there in use and has been since 29 October 2016.There is,however, a greater issue: A significant body of opinion has been expressed below that the entire visual status indicator idea is not acceptable. The above assessment must be interpreted in light of this. I would urge that this close is treated as a tentative indication of how the Citation Template processing would work in a new RfC to see if there is significant buy-in to proceed forward. To move forward with the shaky consensus established below would not comport with WP:CONS. Overall, there is not yet significant consensus on implementation of these citation template behaviors.
- —Trappist the monk (talk) 15:38, 17 April 2017 (UTC)
- Flagging would be allowed, whether to do so or not would be up to editor's discretion. There's no contradiction. Headbomb {t · c · p · b} 14:58, 17 April 2017 (UTC)
- I wouldn't believe the outcome of that rfc. Its conclusions, well-meaning as they are, are self-contradictory: aspect B1 allows all locks (
Any update on doi-broken-date?
If anything, the doi should at the very least still link. Other improvements can wait/get more discussion, but the linking part should be easy to fix. Headbomb {t · c · p · b} 14:25, 11 April 2017 (UTC)
- @Trappist the monk: Any way we can get this bundled in the weekend's update? Headbomb {t · c · p · b} 05:29, 26 April 2017 (UTC)
- The purpose of this interstitial period is to have a last chance to find and fix bugs; to create or modify supporting documentation, categories, templates, etc. – housekeeping preparatory to the update. It is not the time for new development or new features.
- —Trappist the monk (talk) 11:28, 26 April 2017 (UTC)
Can we now implement this? Headbomb {t · c · p · b} 00:27, 2 May 2017 (UTC)
PMCID and the PMC prefix
I wanted to bring this topic back to the surface again. It was recently discussed at Help_talk:Citation_Style_1/Archive_30#PMC, which led to the creation of phab:T157152. This ticket concludes (and I agree) that what CS1 is doing is basically not following the guidelines for usage of PMCID usage. It is therefor a 'CS1'-problem that we should deal with at this level as well. I think we have two options, either make the 'input format' of the PMCID be more flexible (The lua code can easily be adapted to accept both) or cleanup PMCID additions with a bot. —TheDJ (talk • contribs) 15:14, 12 April 2017 (UTC)
- It's a citoid bug, so fix citoid? Headbomb {t · c · p · b} 15:40, 12 April 2017 (UTC)
(The lua code can easily be adapted to accept both)
Do we want to have output of "PMC PMC\d*" or "PMC \d*" in the event that we take that path? --Izno (talk) 15:59, 12 April 2017 (UTC)- Aside courtesy @Boghog: due to involvement on the phabricator task. --Izno (talk) 16:06, 12 April 2017 (UTC)
- Izno, according to that documentation, the output should be PMCID: PMC0123456. Headbomb {t · c · p · b} 16:11, 12 April 2017 (UTC)
- Which has little or no bearing on how we present the ID. I appreciate the fact that the ID is actually "PMC\d*", but that does not require us to present the ID as "PMC: PMC\d*" or even "PMC\d* rather than the current "PMC: \d*", and in fact I disfavor the former as being unnecessary at this time and the latter as being somewhat inconsistent with how we do present it presently. --Izno (talk) 16:29, 12 April 2017 (UTC)
- The NIH guideline (e.g., PMCID: PMC2291284) is crazy. Why repeat PMC twice? As pointed out by Izno and Trappist, there is no reason that CS1/2 has to follow the NIH guideline. Even less reason why the parmeter value has to include PMC (e.g.,
|pmc=PMC2291284
). Boghog (talk) 17:31, 12 April 2017 (UTC)- Not that crazy. Numbers without context are meaningless. By explicitly making the context part of the identifier, it's easier to scrape the web and find your numbers back (for starters). It's also not really uncommon. Many image database identifiers do the same thing for instance. —TheDJ (talk • contribs) 19:35, 12 April 2017 (UTC)
- For consistency, we then should add the parameter names to all parameter values (e.g.,
|volume=volume298
,|issue=issue1
,|pages=pages59–70
,|year=year2006
,|doi=doi10.1016/j.ydbio.2006.06.013
,|volume=volume4
}. The context is provided by the parameter name (e.g.,|pmc=2291284
) and in wiki link in the rendered citation (PMC: 2291284). It is redundant to repeat the parameter name in the parameter value and the wiki linked database name in the database accession number. Boghog (talk) 19:46, 13 April 2017 (UTC) - For scraping Wikipedia for specific PMC ids, CirrusSearch works pretty well (e.g., insource:\pmc = \d+\). Boghog (talk) 20:33, 13 April 2017 (UTC)
- That's the thing. For the PMID, the actual PMID is a pure number: e.g. 18183754. For the PMCID, the actual PMCID is not a pure number, it is e.g. PMC2990724. Headbomb {t · c · p · b} 19:55, 13 April 2017 (UTC)
- QED. The NIH is internally inconsistent. Boghog (talk) 20:02, 13 April 2017 (UTC)
- [citation needed] Headbomb {t · c · p · b} 20:22, 13 April 2017 (UTC)
the actual PMID is a pure number: e.g. 18183754
Just quoting you ;-) Boghog (talk) 20:37, 13 April 2017 (UTC)- I don't follow. PMIDs are in one format. PMCIDs are in another. It's like faulting ISBNs for not following the format of ISSNs. Headbomb {t · c · p · b} 20:39, 13 April 2017 (UTC)
- Both ISSNs and ISBNs are ISO standards and neither requires that the parameter name be include in the parameter value. Hence ISSNs and ISBNs are internally consistent. PMIDs and PMCIDs are both issued by the US National Library of Medicine/National Institutes of Health and only the PMC requires that the parameter name be included in the parameter value. This is inconsistent. Boghog (talk) 20:51, 13 April 2017 (UTC)
- ISSN is 8 characters. ISBN is 10 or 13. Clearly this is inconsistent. And no, the PMCID does not required the 'parameter name ' to be included in the parameter value. The name is PMCID, the value is PMC0123456. PMCID does not appear in PMC0123456 and even if it did, so what? Headbomb {t · c · p · b} 20:59, 13 April 2017 (UTC)
- The letters "PMC" appear twice which is redundant. Boghog (talk) 21:03, 13 April 2017 (UTC)
- ISSN is 8 characters. ISBN is 10 or 13. Clearly this is inconsistent. And no, the PMCID does not required the 'parameter name ' to be included in the parameter value. The name is PMCID, the value is PMC0123456. PMCID does not appear in PMC0123456 and even if it did, so what? Headbomb {t · c · p · b} 20:59, 13 April 2017 (UTC)
- Both ISSNs and ISBNs are ISO standards and neither requires that the parameter name be include in the parameter value. Hence ISSNs and ISBNs are internally consistent. PMIDs and PMCIDs are both issued by the US National Library of Medicine/National Institutes of Health and only the PMC requires that the parameter name be included in the parameter value. This is inconsistent. Boghog (talk) 20:51, 13 April 2017 (UTC)
- I don't follow. PMIDs are in one format. PMCIDs are in another. It's like faulting ISBNs for not following the format of ISSNs. Headbomb {t · c · p · b} 20:39, 13 April 2017 (UTC)
- [citation needed] Headbomb {t · c · p · b} 20:22, 13 April 2017 (UTC)
- QED. The NIH is internally inconsistent. Boghog (talk) 20:02, 13 April 2017 (UTC)
- That's the thing. For the PMID, the actual PMID is a pure number: e.g. 18183754. For the PMCID, the actual PMCID is not a pure number, it is e.g. PMC2990724. Headbomb {t · c · p · b} 19:55, 13 April 2017 (UTC)
- For consistency, we then should add the parameter names to all parameter values (e.g.,
- Not that crazy. Numbers without context are meaningless. By explicitly making the context part of the identifier, it's easier to scrape the web and find your numbers back (for starters). It's also not really uncommon. Many image database identifiers do the same thing for instance. —TheDJ (talk • contribs) 19:35, 12 April 2017 (UTC)
- Izno, according to that documentation, the output should be PMCID: PMC0123456. Headbomb {t · c · p · b} 16:11, 12 April 2017 (UTC)
- Aside courtesy @Boghog: due to involvement on the phabricator task. --Izno (talk) 16:06, 12 April 2017 (UTC)
- cs1|2, claims to the contrary notwithstanding, is a style in its own right. cs1|2 takes cues from published style guides but is not beholden to those style guides. So it is with PMC. We have no obligation to make cs1|2 adhere to PubMed Central's preferred styling. Given the comments in phab:T157152 I think it unlikely that those who play in the internals of citoid are interested in a citoid solution to the problem. That leaves it to us. We can tweak the module to accept PMC values with the redundant PMC prefix and then do as we wish with it.
- —Trappist the monk (talk) 16:24, 12 April 2017 (UTC)
- Because I think that there is no citoid fix, I've tweaked Module:Citation/CS1/Identifiers/sandbox:
- 4664-351: Title. PMC 4664-351.
{{cite book}}
: Check|pmc=
value (help) - 4664351: Title. PMC 4664351.
- pmc4664-351: Title. PMC pmc4664-351.
{{cite book}}
: Check|pmc=
value (help) - pmc4664351: Title. PMC 4664351.
{{cite book}}
: CS1 maint: PMC format (link) - pmc 4664351: Title. PMC pmc 4664351.
{{cite book}}
: Check|pmc=
value (help)
- 4664-351: Title. PMC 4664-351.
- —Trappist the monk (talk) 17:13, 12 April 2017 (UTC)
- I assume from the length of the phab ticket that mediawiki devs have declined to do anything on their side. So yes, pragmatic solution for the moment is to allow
|pmc=pmc1234
and|pmc=PMC1234
in addition to the existing|pmc=1234
(do we need to allow|pmc=pmc 1234
too?), and leave the rendered display as-is. If there is a desire to change the rendered display, that's a separate matter (I am also of the view that the PubMed guidelines seem to want redundancy that we are not required to show; broadly I think they want any display to be clear whether the number is a PMID or a PMC, which we do clearly as is, so I don't see a need to change rendered display.) Rjwilmsi 19:21, 12 April 2017 (UTC)- The primary point being made in the ticket is that the identifier is NOT just the number, but PMCnumber, and so Citoid is conceptually returning the right value. It's just that our templates expect a 'partial identifier'. The developer discussion gave no judgement on how we should render the ID. I wouldn't object personally to keeping any representation to just as it is right now, even though NIH guidelines suggest something else. However I do note that NIH uses that notation quite consistently, and I think that such consistency is something to take into account when evaluating this. —TheDJ (talk • contribs) 19:51, 12 April 2017 (UTC)
- I assume from the length of the phab ticket that mediawiki devs have declined to do anything on their side. So yes, pragmatic solution for the moment is to allow
- I've changed Module:Citation/CS1/Identifiers/sandbox slightly, to simply allow the number to be prefixed with PMC and display everything as we have so far. I think this is best for now. —TheDJ (talk • contribs) 08:45, 14 April 2017 (UTC)
- Why not display it as "Title. PMC4664351" directly then? Do we really need the first "PMC: "? My proposal would be to remove the first "PMC: " and normalize all input identifiers to add PMC in front of the number. This minimizes the visual difference compared to what we have now. − Pintoch (talk) 09:16, 14 April 2017 (UTC)
- Yes, we do need the first PMC as it explains what PMC is. Also, if we changed the PMC link to a plain link, it would no longer be consistent with the way
|doi=
,|pmid=
,|isbn=
,|issn=
,|bibcode=
, etc are rendered. Boghog (talk) 09:34, 14 April 2017 (UTC)- I think most readers do not care about what PMC is. They just want to read their article. When we use
|url=
, we don't put a link to the Wikipedia article for the website, and that's fine! As far as I know, Wikipedia is the only website with this weird convention. Citation templates are meant to refer to a source, not to give a lecture on the IT infrastructure of scholarly communications, especially when it comes to the cost of a painful redundancy like "PMC PMC1234". − Pintoch (talk) 12:27, 14 April 2017 (UTC)- Wikipedia is also designed to be read by people not familiar with academia, and students that are yet to become familiar with the bibliographic databases of their fields. We have different needs and aims than professional journals. Also, there is no PMC PMC1234 redundancy, right now we render PMC 012345. There might be a case for rendering PMCID: PMC012345 however. I don't particular like it, but it is the 'official' way of doing things.Headbomb {t · c · p · b} 12:41, 14 April 2017 (UTC)
- (edit conflict) I completely agree that writing PMC twice is redundant. Boghog (talk) 12:45, 14 April 2017 (UTC)
- No one has proposed to write PMC twice. Stop pretending this is even on the table. Headbomb {t · c · p · b} 12:47, 14 April 2017 (UTC)
- So do you agree that adopting the full NIH recommendation (PMCID: PMC012345) which is redundant is not on the table? Furthermore, there is very little difference between writing "PMC 012345" as is currently done versus "PMC012345" except that the former is more legible. Boghog (talk) 13:18, 14 April 2017 (UTC)
- The NIH format is on the table. PMC PMC0123456, however, is not. Headbomb {t · c · p · b} 13:21, 14 April 2017 (UTC)
No one has proposed to write PMC twice.
The NIH format writes PMC twice (PMCID: PMC012345). Boghog (talk) 13:29, 14 April 2017 (UTC)- Yes, and that is their legit, official format [name of identifier] [actual identifier], quite clearly distinct from one another, not PMC PMC0123465 as you have been arguing above. We do this for most of our identifiers, e.g arXiv:1301.1234, ISSN 1927-226X, PMID 12346, etc. We can choose to deviate from the official format if we want, but this would be a choice and we'd need a strong consensus to do so. Headbomb {t · c · p · b} 15:22, 14 April 2017 (UTC)
- Official or not, "PMCID: PMC0123465" is every bit as redundant as "PMC: PMC0123465". As argued below, we have zero obligation to follow the NIH recommendations. Quite to the contrary, it would take a strong consensus to overturn the long standing convention in how Wikipedia handles PMC identifiers. This is problem that did not exist until the folks that maintain Citoid decided to take a rigid interpretation of the NIH guidelines that do not apply to Wikipedia. Finally, none of the other identifiers that you mention contain a similar redundancy including and most notably
|pmid=
. Boghog (talk) 16:21, 14 April 2017 (UTC)- I agree. If you want to accept
|pmc=pmc1234
(or|pmcid=pmc1234
if you prefer) that's fine, but please make sure the string "PMC" does not appear twice in the output (just to make things clear: in "PMCID: PMC1234", there are two occurrences of the "PMC" string). − Pintoch (talk) 17:58, 14 April 2017 (UTC)
- I agree. If you want to accept
- Official or not, "PMCID: PMC0123465" is every bit as redundant as "PMC: PMC0123465". As argued below, we have zero obligation to follow the NIH recommendations. Quite to the contrary, it would take a strong consensus to overturn the long standing convention in how Wikipedia handles PMC identifiers. This is problem that did not exist until the folks that maintain Citoid decided to take a rigid interpretation of the NIH guidelines that do not apply to Wikipedia. Finally, none of the other identifiers that you mention contain a similar redundancy including and most notably
- Yes, and that is their legit, official format [name of identifier] [actual identifier], quite clearly distinct from one another, not PMC PMC0123465 as you have been arguing above. We do this for most of our identifiers, e.g arXiv:1301.1234, ISSN 1927-226X, PMID 12346, etc. We can choose to deviate from the official format if we want, but this would be a choice and we'd need a strong consensus to do so. Headbomb {t · c · p · b} 15:22, 14 April 2017 (UTC)
- The NIH format is on the table. PMC PMC0123456, however, is not. Headbomb {t · c · p · b} 13:21, 14 April 2017 (UTC)
- So do you agree that adopting the full NIH recommendation (PMCID: PMC012345) which is redundant is not on the table? Furthermore, there is very little difference between writing "PMC 012345" as is currently done versus "PMC012345" except that the former is more legible. Boghog (talk) 13:18, 14 April 2017 (UTC)
- No one has proposed to write PMC twice. Stop pretending this is even on the table. Headbomb {t · c · p · b} 12:47, 14 April 2017 (UTC)
- I think most readers do not care about what PMC is. They just want to read their article. When we use
- It is important to note that the scope of the NIH guideline is limited to
Anyone submitting an application, proposal or report to the NIH
. Wikipedia is not submitting anything to the NIH. The guideline is silent about how references or links to PMC are formatted in journals. This is a decision made by individual journals, not the NIH. Likewise Wikipedia is not bound by NIH guidelines. Boghog (talk) 09:45, 14 April 2017 (UTC)- Absolutely. If you intend to follow the guidelines of all the organizations that issue the identifiers in use on Wikipedia, then you should also change doi:10.5468/ogs.2016.59.1.1 to doi:https://doi.org/10.5468/ogs.2016.59.1.1, because Crossref recommends to write DOIs as URLs! I am sure this is going to be a very popular change. No redundancy at all! − Pintoch (talk) 17:58, 14 April 2017 (UTC)
- Yes, we do need the first PMC as it explains what PMC is. Also, if we changed the PMC link to a plain link, it would no longer be consistent with the way
- Why not display it as "Title. PMC4664351" directly then? Do we really need the first "PMC: "? My proposal would be to remove the first "PMC: " and normalize all input identifiers to add PMC in front of the number. This minimizes the visual difference compared to what we have now. − Pintoch (talk) 09:16, 14 April 2017 (UTC)
- Because I think that there is no citoid fix, I've tweaked Module:Citation/CS1/Identifiers/sandbox:
Proposal: silently drop "PMC" from identifier
In the interest of maintaining our citation style while allowing editors to add PMC identifiers that are technically correct, and in the interest of avoiding redundancy, I propose the following change, if it is technically possible:
- Allow identifiers of the form
|pmc=1234567
and|pmc=PMC1234567
and|pmc=pmc1234567
. - If "PMC" is present in the identifier, silently drop it during rendering, and render the identifier as we currently do: PMC 1234567.
- Run the identifier validity check on the numeric portion of the identifier only. – Jonesey95 (talk) 21:09, 14 April 2017 (UTC)
- I support this proposal. − Pintoch (talk) 21:12, 14 April 2017 (UTC)
- This has already been done in the sandbox. I made that change because cs1|2 has a long-standing 'style' (if you will) that, in the live version of the module, is being broken in templates authored by citoid. If the proposal is to 'formalize' the acceptance of that change to the module, meh, I'm indifferent. If the purpose is to get Editors Headbomb and Boghog to put a cork in it, then I wholeheartedly support the proposal. I will note that the change to the module isn't quite silent; there is code that adds a maintenance category for templates that include a 'pmc' prefix in the parameter value.
- —Trappist the monk (talk) 21:44, 14 April 2017 (UTC)
- You're proposing to drop the identier name / keep the same rendering, not proposing to drop the PMC in the identifer. That proposal would be either rendering it as PMCID 01234 or simply 01234. Neither of which are acceptable.
- I support keeping the same rendering FWIW. But let's not falsely label this as "dropping the pmc from the identifier". Headbomb {t · c · p · b} 22:51, 14 April 2017 (UTC)
- Headbomb, we know (or at least I think) you understand what is meant here, so please let us not dance on the head of a pin about language. What Jonesey95 is proposing, and what is currently implemented, is to convert identifiers input as
|pmc=PMC12345
back to|pmc=12345
internally, and then display it as usual. In that sense, it is correct to say that the code "drops the pmc from the identifier" (even if "PMC: " is prepended afterwards). By doing so it keeps the rendered version unchanged. I think the description above is crystal clear for anyone familiar with CS1, which is your case. − Pintoch (talk) 00:05, 15 April 2017 (UTC)
- Headbomb, we know (or at least I think) you understand what is meant here, so please let us not dance on the head of a pin about language. What Jonesey95 is proposing, and what is currently implemented, is to convert identifiers input as
- I support Jonesey's pragmatic proposal (and Trappist's sandbox implementation). Boghog (talk) 05:36, 15 April 2017 (UTC)
- Discussion seems to have stalled. Shall I make the change then ? —TheDJ (talk • contribs) 08:14, 24 April 2017 (UTC)
- No. This change will be part of the update.
- —Trappist the monk (talk) 08:50, 24 April 2017 (UTC)
- Discussion seems to have stalled. Shall I make the change then ? —TheDJ (talk • contribs) 08:14, 24 April 2017 (UTC)
ASIN-related discussion
See Wikipedia talk:WikiProject Spam#amazon.com Headbomb {t · c · p · b} 11:56, 13 April 2017 (UTC)
Can something be done about this template?
- It has quite low use (according to User:Green Cardamom at Special:Diff/775225851, only 181 articles).
- It has bugs which are not easy to fix. i.e.
|deadurl=no
is ignored, plus|archiveurl=
and|archive-url=
are not the same. It uses Template:Citation/core instead of Lua module templates like Template:Cite web. - Template:Cite web can do almost everything this template can do, including
|rfc=
. - Documentation is outdated.
As an example, right now this template needs to use Template:Webarchive for the purpose of |archive-url=
, seen in revision 775225151
.
I'd like to see this IETF template go away, or be fixed of its bugs. Any other proposals or suggestions? 80.221.152.17 (talk) 23:59, 13 April 2017 (UTC)
According to Template:Citation/core, Template:Cite wikisource is also affected and most templates have been converted to use Module:Citation/CS1. It's used on 2362 articles as of today. 80.221.152.17 (talk) 00:12, 14 April 2017 (UTC)
- Suggest open a WP:TfD with the above rationale (WP:TFD#REASONS #2). If it passes (for delete) I'll make a script for converting the 181. -- GreenC 02:26, 14 April 2017 (UTC)
- No need for a TFD, 'just' update {{cite IETF}} to mirror {{cite web}}, map
|section-name=
to|title=
, map|title=
to|work=
. Then add proper support for BCP, FYI, IEN, I-D, RFC, RTR and STD identifiers, with auto-url generation. I'd do it, but I can't do anything in LUA. Headbomb {t · c · p · b} 07:00, 14 April 2017 (UTC)
- No need for a TFD, 'just' update {{cite IETF}} to mirror {{cite web}}, map
- As far as I can tell (and I have not looked at all possible cases) {{cite ietf}} correctly applies Citation Style 1. The back-end, and/or the scripting language utilized, is not directly relevant to style issues in general, and to citing IETF docs in particular, at least per the current CS1 implementation. If this template has bugs that trouble you and/or bad documentation that also troubles you, by all means fix them. Converting it to a CS1 template is another topic. As for {{cite wikisource}}, this discussion is not applicable. It is not a CS1 template, nor should it necessarily be one. 65.88.88.75 (talk) 18:17, 14 April 2017 (UTC)
|coauthor= and |coauthors= are dead
Wikitext | {{cite book
|
---|---|
Live | Author. Title. {{cite book}} : |author= has generic name (help); Unknown parameter |coauthor= ignored (|author= suggested) (help)
|
Sandbox | Author. Title. {{cite book}} : |author= has generic name (help); Unknown parameter |coauthor= ignored (|author= suggested) (help)
|
We deprecated |coauthor=
and |coauthors=
sometime in late 2013 to early 2014. These two parameters contributed the vast majority of pages to Category:Pages containing cite templates with deprecated parameters. Except for eight stubborn pages (see separate discussion at WP:VPT), the category is now empty.
In the whitelist sandbox I have disabled the two parameters and will cleanup the supporting code in a bit.
—Trappist the monk (talk) 13:49, 16 April 2017 (UTC)
- At the WP:VPT conversation, Editor Jonesey95 has suggested that cs1|2 stop using Category:Pages containing cite templates with deprecated parameters and instead use Category:CS1 errors: deprecated parameters. I agree with this suggestion. The current name is too long; the proposed name is in keeping with the majority of subcategory names in Category:CS1 errors. Without objection, I shall make the necessary changes to implement this suggestion. Now is a good time since the category is more-or-less empty.
- —Trappist the monk (talk) 15:07, 16 April 2017 (UTC)
-
- I think that all support for
|coauthor=
and|coauthors=
has been removed from the module sandboxen. I have changed the deprecated parameter category name. After we take the module sandboxen live (we ought to do that, it's been a while) Category:CS1 errors: coauthors without author can be deleted along with its supporting help text at Help:CS1 errors. Similarly, the new deprecated parameter category needs to be created and the help text pointed to it. - —Trappist the monk (talk) 15:58, 16 April 2017 (UTC)
- I think that all support for
Month–month, year and html-encoded en-dashes
The CS1 templates are happy with |date=July–August 2008
but give warnings for the should-be-identical |date=July–August 2008
. There are some editors out there (not me, but others I've interacted with) who insist that spelling out the – rather than using an en-dash character is necessary to make the type of dash more visible to editors reading the source. Is there some way to make the citation templates accept input in this format? —David Eppstein (talk) 19:49, 16 April 2017 (UTC)
- I would guess that this is in the realm of possible, and a simply transform to the Unicode variant can take care of it for the metadata. --Izno (talk) 21:09, 16 April 2017 (UTC)
- More broadly, I'm sick of hearing that symbolics like –, & , {{ndash}}, and {{nbsp}} "pollute the COinS metadata" (as if anyone cared about that anyway). Post process the COinS data tobrdgularize that kind of thing and stop expecting editors to remember a bunch if special restrictions. EEng 21:29, 16 April 2017 (UTC)
- I use {{en dash}}. It is safe and error free. I generally agree that editors should not be limited by badly implemented interfaces foreign to the Wikipedia's citation system. 64.134.240.62 (talk) 21:39, 16 April 2017 (UTC)
- That does seem to work within the CS1 templates; thanks! It also may have the helpful side affect of being less likely to be removed by AWB-enthusiasts. —David Eppstein (talk) 21:53, 16 April 2017 (UTC)
- You're welcome. Notice that {{spaced en dash}} which is appropriate in some date citations is hatnoted as a no-no due to COINS limitations. 64.134.240.62 (talk) 22:05, 16 April 2017 (UTC)
- Wait a second. I've been told many times that I can't use {{ndash}} either. Any why is {{spaced ndash}} a "no-no"? What exactly are these COINS limitations? I've been asking for years and never get an answer. EEng 14:35, 20 April 2017 (UTC)
{{spaced ndash}}
resolves to: – 
- Before it is handed to a cs1|2 template, this date example:
|date=Winter 1992{{spaced ndash}}Spring 1993
- resolves to:
Winter 1992 – Spring 1993
- The cs1|2 template then percent encodes each of those characters for COinS:
Winter+1992%26nbsp%3B%26ndash%3B%26%2332%3BSpring+1993
- —Trappist the monk (talk) 15:13, 20 April 2017 (UTC)
- Wait a second. I've been told many times that I can't use {{ndash}} either. Any why is {{spaced ndash}} a "no-no"? What exactly are these COINS limitations? I've been asking for years and never get an answer. EEng 14:35, 20 April 2017 (UTC)
- You're welcome. Notice that {{spaced en dash}} which is appropriate in some date citations is hatnoted as a no-no due to COINS limitations. 64.134.240.62 (talk) 22:05, 16 April 2017 (UTC)
- That does seem to work within the CS1 templates; thanks! It also may have the helpful side affect of being less likely to be removed by AWB-enthusiasts. —David Eppstein (talk) 21:53, 16 April 2017 (UTC)
- The main thing is to format citations with ease, and in such a way that the result is clear to readers. I would not at all worry about COinS compatibility. It is by no means a (1) bug-free or (2) universal, standard. Granted that some of the inconsistencies stem from its reliance on OpenURL, which itself can be problematic. But Wikipedia citations do not have to be compatible with any foreign interface. It is up to those that design and implement such interfaces to make sure their middleware works correctly with its target platforms. We are talking about a 10-year+ effort that, when it comes to Wikipedia, cannot resolve basic HTML entities. That is why {{spaced en dash}} (a correct implementation) throws a hiccup. {{en dash}} doesn't because it utilizes the plain glyph. Symbolically/programmatically, {{en dash}} is inferior: the rendering of glyphs is not uniform. 65.88.88.127 (talk) 20:38, 20 April 2017 (UTC)
- I'm having trouble making sense of this:
That is why {{spaced en dash}} (a correct implementation) throws a hiccup. {{en dash}} doesn't because it utilizes the plain glyph. Symbolically/programmatically, {{en dash}} is inferior: the rendering of glyphs is not uniform.
- especially that last bit:
the rendering of glyphs is not uniform.
- I'm having trouble making sense of this:
-
- If I write:
{{spaced en dash}}{{en dash}}
- I get:
– –
- If you look in this page's source, this:
- – –
- has been translated to:
 – –
- Those two en dashes are the same character: U+2013. It would appear that the rendering is, for this particular example, uniform.
- —Trappist the monk (talk) 10:25, 23 April 2017 (UTC)
- "Symbolically/programmatically". Because right now there is no guarantee that a formatting character will display uniformly across platforms, the proper way to input the character is through its universal encoding. The template {{spaced en dash}} does this. {{en dash}} doesn't. In the latter case, editors have no certain way of knowing whether the writer intended an en dash or any other similar formatting character. Not only are there many different dashes, but they also may display differently, depending on platform. 72.43.99.138 (talk) 14:20, 23 April 2017 (UTC)
- I don't think that I buy this. Wikipedia serves html5 using character set UTF-8. In html5,
–
maps to the unicode character U+2013 and has done since html 4 and perhaps earlier. See html5 named character references (a rather awful table – here's a friendlier version). For the purposes of display, there is no distinction between a source that uses–
or–
or the en dash glyph. The browser will render any of these characters in exactly the same way according to the specified font (if it doesn't then the browser is fundamentally flawed).
- I don't think that I buy this. Wikipedia serves html5 using character set UTF-8. In html5,
-
- I have some sympathy for the complaint that the various dashes look rather similar in the wikitext edit box but that is the fault of the font, not of the html source.
- —Trappist the monk (talk) 11:17, 25 April 2017 (UTC)
- For the purposes of your display. There is no guarantee that what appears to you as a particular formatting character will do so across others' displays, browsers, scripting frameworks, operating systems, or hardware. There is nothing to buy here. The proper way to program this is to enter the code which unambiguously stands for the character you intend. But the point is not about bad/lazy template authoring. This tangent is a byproduct of the badly-written COinS interface, which forces these contortions. 72.43.99.138 (talk) 13:48, 25 April 2017 (UTC)
- Let me repeat myself:
Wikipedia serves html5 using character set UTF-8. In html5,
. Because–
maps to the unicode character U+2013–
is defined as U+2013, any browser compliant with html4 and later will render–
and U+2013 in the same way. How you see that character is determined by your chosen font. I can set my browser to render all text in a serif font which may display an en dash differently from the way it would be display were I to set my browser to render all text with a sanserif font. At the source level, there is no ambiguity because–
= U+2013.
- Let me repeat myself:
-
- I have written nothing regarding
bad/lazy template authoring.
I don't understand why you have made that statement.
- I have written nothing regarding
-
- That COinS is old and is limited is not a point of contention. I have, in the past, collected as much of the metadata code in a single place as I could so that we might, if ever we take the decision to do so, emit metadata according to some other standard and the effort required is mostly the writing of a module to replace Module:Citation/CS1/COinS. Propose a better metadata standard.
- —Trappist the monk (talk) 10:23, 27 April 2017 (UTC)
- For the purposes of your display. There is no guarantee that what appears to you as a particular formatting character will do so across others' displays, browsers, scripting frameworks, operating systems, or hardware. There is nothing to buy here. The proper way to program this is to enter the code which unambiguously stands for the character you intend. But the point is not about bad/lazy template authoring. This tangent is a byproduct of the badly-written COinS interface, which forces these contortions. 72.43.99.138 (talk) 13:48, 25 April 2017 (UTC)
- "Symbolically/programmatically". Because right now there is no guarantee that a formatting character will display uniformly across platforms, the proper way to input the character is through its universal encoding. The template {{spaced en dash}} does this. {{en dash}} doesn't. In the latter case, editors have no certain way of knowing whether the writer intended an en dash or any other similar formatting character. Not only are there many different dashes, but they also may display differently, depending on platform. 72.43.99.138 (talk) 14:20, 23 April 2017 (UTC)
- If I write:
- The main thing is to format citations with ease, and in such a way that the result is clear to readers. I would not at all worry about COinS compatibility. It is by no means a (1) bug-free or (2) universal, standard. Granted that some of the inconsistencies stem from its reliance on OpenURL, which itself can be problematic. But Wikipedia citations do not have to be compatible with any foreign interface. It is up to those that design and implement such interfaces to make sure their middleware works correctly with its target platforms. We are talking about a 10-year+ effort that, when it comes to Wikipedia, cannot resolve basic HTML entities. That is why {{spaced en dash}} (a correct implementation) throws a hiccup. {{en dash}} doesn't because it utilizes the plain glyph. Symbolically/programmatically, {{en dash}} is inferior: the rendering of glyphs is not uniform. 65.88.88.127 (talk) 20:38, 20 April 2017 (UTC)
- First, get rid of artificial limitations on users of these templates, that are imposed by inadequate interfaces. Secondly, we don't have to propose any metadata standard. Wikipedia citations don't exist to play nice with reference software or bibliographic systems. They are required in order to verify anonymous/pseudonymous claims. If you want to interface with foreign systems do it in a way that is totally transparent to end-users. Otherwise this may well add undue burden to the creation of citations using these templates. So this may be a potential obstacle to verification.
- The lazy/bad template authoring comment was referring to {{en dash}}. Basically a scripted (as in template script) glyph. Why even bother? Either use the bare symbol or script it properly with its encoding. By the way, variable user font selection is to be anticipated, and one more reason to use the proper encoding so that later editors know what is expected. And it is simply not true that browsers or platforms interpret the standards uniformly. I am sure you have seen how an em dash displays on say, MacOS 10.x (Safari). 72.43.99.146 (talk) 13:21, 27 April 2017 (UTC)
So all these years busybodies have been giving people a hard time for using templates in citation values for nothing? I'm shocked. EEng 01:04, 22 April 2017 (UTC)
Reprint
How to note a reprint? bkb (talk) 08:44, 17 April 2017 (UTC)
- Is it important to do so? Does the rest of the bibliographic detail not sufficiently WP:SAYWHEREYOUGOTIT? I have seen reprints noted in either of
|edition=
or|type=
. - —Trappist the monk (talk) 10:50, 17 April 2017 (UTC)
|edition=Reprint
usually. Headbomb {t · c · p · b} 11:23, 17 April 2017 (UTC)- I would not mention that a book was a reprint unless
- it was reprinted by a different publisher
- it was described as a corrected reprinting, or similar, or
- the page numbers of the reprint don't match the page numbers of the earlier version. Jc3s5h (talk) 14:32, 17 April 2017 (UTC)
- I would not mention that a book was a reprint unless
- Sometimes knowing the print run is important to identify a particular issue of a book, as errors are sometimes silently fixed. I have also seen other changes with reprints, different covers, updated prefaces, changed prices, and sometimes even without changing the ISBN. Therefore, I proposed to introduce a new parameter like
|print-run=
a while ago. This would allow editors to specify the extra info where they see fit without overloading the|edition=
parameter. For now, the template could just concatenate the values of both parameters for output, but keeping it in separate parameters would improve machine readability and allow us to adjust the output format depending on the target environment anytime later on (f.e. ignore the|print-run=
parameter for meta data schemes not supporting it). - --Matthiaspaul (talk) 23:29, 26 April 2017 (UTC)
Cyrillic URLs
{{Cite web}} generates a warning when a (valid) URL is in Cyrillic (and, I suspect, in any other non-Latin script), which it probably shouldn't, since there is nothing wrong with the URL. An example of this behavior can be seen here. Can someone please take a look into this?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 17, 2017; 17:48 (UTC)
- Instructions for converting the URL to Roman characters are available via the "help" link in the error message. – Jonesey95 (talk) 18:00, 17 April 2017 (UTC)
- I'm aware of that. The point is that there is no need to convert the characters, since the original URL is perfectly valid (and more readable).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 17, 2017; 18:03 (UTC)
-
- As far as I know, DNS domain names must still be Latin characters. Unless the standard has changed, I suspect that what is happening is that your browser is now capable of translating
хвастовичский-район.рф
to its Punycode value (xn----7sbbfb0baicf2bdizhdn4c5b.xn--p1ai
) to be usable by DNS but render's a Unicode version for the reader. If I drop the Punycode version of the url into my browser's address bar, I get the correct web site and my browser renders the Cyrillic domain name. - —Trappist the monk (talk) 18:46, 17 April 2017 (UTC)
- Thanks. I was looking for previous discussions, but must have missed that one.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 18, 2017; 13:27 (UTC)
- As far as I know, DNS domain names must still be Latin characters. Unless the standard has changed, I suspect that what is happening is that your browser is now capable of translating
Identifying editors
Can we automatically identify editors with "ed." or "eds." through this template in all instances? I'm doing a source review of Macedonia (ancient kingdom), and I really can't imagine that it's clear to a reader when someone is an editor or not. Ed [talk] [majestic titan]
- I agree. The template currently does this when the whole book is cited:
- but not when a chapter of an edited book is cited:
- Also marking the editor in in this case would be clearer. I would suggest the same formatting as for books without years:
- Kanguole 08:47, 18 April 2017 (UTC)
- It is the responsibility of the cs1|2 templates to render the citation with appropriate punctuation and appropriate static text. Editors should not be adding extraneous text to template parameters as you have done with this edit. If we make this change as you've requested, then that citation will render the editor list this way:
- Bolman, Elizabeth S., ed., ed.
- or this way, if Editor Kanguole's preference prevails:
- Bolman, Elizabeth S., ed. (ed.)
- If we are to make this change, is the full stop (cs1) or comma (cs2) the correct punctuation to separate <editor list> from title? Somehow, for me, a colon seems more correct:
- <author list> (2000). "Chapter". In <editor list>: Edited book. pp. 1–23.
- —Trappist the monk (talk) 11:14, 18 April 2017 (UTC)
- Certainly the templates should be responsible for static text, but the fact than many editors are adding this manually is evidence of demand. If the change were made to the templates, a bot would be needed to remove these manual annotations. Kanguole 11:30, 18 April 2017 (UTC)
- Perhaps you know how many editors are actually adding manual annotations? I don't. This insource: search pattern,
insource:/\| *editor[^=]*=[^\|\}]+[,;\.]? +\(?ed/
found 1130 matches – ymmv; insource: searches are not always consistent or reliable. I suppose, as a first step, we might add a test similar to the tests that populate Category:CS1 maint: Extra text (maybe into its own subcategory) and so gain more knowledge of the extent of this issue. Such tests don't indicate much about 'demand'; only that editors have in the past misused the editor parameters.
- Perhaps you know how many editors are actually adding manual annotations? I don't. This insource: search pattern,
-
- Out of curiosity, I changed the insource: search pattern to look at three of the author parameters:
|author[\ds]*=
: 1728|last[\d]*=
: 428|first[\d]*=
: 2208
- so perhaps if we are to make a test for the editor parameters, we should do the same for the author parameters.
- —Trappist the monk (talk) 12:33, 18 April 2017 (UTC)
- @Trappist the monk: I would prefer to not use a colon. TCMOS handles book chapters like this: "Kelly, John D. “Seeing Red: Mao Fetishism, Pax Americana, and the Moral Economy of War.” In Anthropology and Global Counterinsurgency, edited by John D. Kelly, Beatrice Jauregui, Sean T. Mitchell, and Jeremy Walton, 67–83. Chicago: University of Chicago Press, 2010." Ed [talk] [majestic titan] 03:06, 19 April 2017 (UTC)
- cs1|2 is not Chicago; is not MLA; is not APA; nor any other published style. It is bits, pieces, and parts from all of these and from none of these. Chicago's choice to style chapters in edited works in the manner you illustrate does not obligate cs1|2 to do the same.
- —Trappist the monk (talk) 09:53, 19 April 2017 (UTC)
- @Trappist the monk: Of course it's not, I was just giving an alternative example because I think the colon looks terrible. ;-) Ed [talk] [majestic titan] 14:18, 20 April 2017 (UTC)
[B]ecause I think the colon looks terrible
seems a rather insubstantial reason for opposition. I'm no grammarian so there may be more substantive grammatical reasons why we should not use the colon to introduce the title at the end of the editor list. I suppose that my preference for the colon stems from the use of the full stop (cs1) or comma (cs2) at the end of the editor list when introducing the title so perhaps an alternate is no punctuation:- In Editor Name. Title – as the templates render cs1 now
- in Editor Name, Title – as the templates render cs2 now
- In Editor Name: Title – cs1 with a colon
- in Editor Name: Title – cs2 with a colon
- In Editor Name Title – cs1 without punctuation
- in Editor Name Title – cs2 without punctuation
- —Trappist the monk (talk) 16:36, 20 April 2017 (UTC)
- @Trappist the monk: Of course it's not, I was just giving an alternative example because I think the colon looks terrible. ;-) Ed [talk] [majestic titan] 14:18, 20 April 2017 (UTC)
- The colon would be inconsistent with how we cite the book alone. We should reconsider all those period separators in cs1, but that can be separate from the issue of flagging editors. Kanguole 15:24, 20 April 2017 (UTC)
- How would the colon
be inconsistent with how we cite the book alone
? - —Trappist the monk (talk) 16:36, 20 April 2017 (UTC)
- There is no colon in
- Kanguole 17:45, 20 April 2017 (UTC)
- The author-editor-chapter-title rendering:
- is different from author-editor-title rendering:
- is different from editor-title rendering:
- so dismissing the use of a colon based on inconsistency doesn't seem very persuasive.
- —Trappist the monk (talk) 19:01, 20 April 2017 (UTC)
- Then let's fix the inconsistency, by changing these to
- Author. "Chapter". In Editor (ed.). Title.
- Author. Editor (ed.). Title.
- Editor (ed.). Title.
- Kanguole 19:25, 20 April 2017 (UTC)
- In general, I would not be opposed to such a fix. Yet, 'In Editor (ed.).' seems like a sentence fragment to me (it isn't in cs2 where it would be rendered as 'in Editor (ed.), ...').
-
- But, if we're going to fix editor rendering, we should also address the two different cases of author, editor, chapter, title. In the first case, Author is the author of Title which has been edited by Editor. We do not currently support this style. Perhaps this case could be rendered in one of these ways:
- Author. Editor (ed.). "Chapter". Title.
- Author. "Chapter". Title. Editor (ed.).
- some other way?
- In the second case, Author is the author of "Chapter" in Title which is an anthology or compilation of chapters edited by Editor. We support this case now:
- Author. "Chapter". In Editor (ed.). Title.
- How do we instruct the templates to distinguish between the two? Here is some previous discussion.
- —Trappist the monk (talk) 10:43, 21 April 2017 (UTC)
- If Author is the author of Title, which has been edited by Editor, then Title is the work that is cited, and
|chapter=
should not be set. But if we were citing a part of the book written by someone else, we'd use|contributor=
in addition to the author and editor. Kanguole 11:17, 21 April 2017 (UTC)- Wishful thinking on your part methinks. You know that Wikipedia editors can and will cite "Chapter" in Author's Title. Nothing in the cs1|2 documentation proscribes such citations. No doubt there are a bazillion such cites in the wild.
- —Trappist the monk (talk) 11:45, 21 April 2017 (UTC)
- In answer to my own question on how to instruct the templates to distinguish between the two styles of author, editor, chapter, title citations, we might deprecate and then re-purpose
|in=
. This parameter is a rarely used alias of|language=
. - —Trappist the monk (talk) 14:23, 21 April 2017 (UTC)
- We should not be adding parameters to support unjustified new usages. Kanguole 14:57, 21 April 2017 (UTC)
- If Author is the author of Title, which has been edited by Editor, then Title is the work that is cited, and
- But, if we're going to fix editor rendering, we should also address the two different cases of author, editor, chapter, title. In the first case, Author is the author of Title which has been edited by Editor. We do not currently support this style. Perhaps this case could be rendered in one of these ways:
- Then let's fix the inconsistency, by changing these to
- How would the colon
- @Trappist the monk: I would prefer to not use a colon. TCMOS handles book chapters like this: "Kelly, John D. “Seeing Red: Mao Fetishism, Pax Americana, and the Moral Economy of War.” In Anthropology and Global Counterinsurgency, edited by John D. Kelly, Beatrice Jauregui, Sean T. Mitchell, and Jeremy Walton, 67–83. Chicago: University of Chicago Press, 2010." Ed [talk] [majestic titan] 03:06, 19 April 2017 (UTC)
- Out of curiosity, I changed the insource: search pattern to look at three of the author parameters:
- Certainly the templates should be responsible for static text, but the fact than many editors are adding this manually is evidence of demand. If the change were made to the templates, a bot would be needed to remove these manual annotations. Kanguole 11:30, 18 April 2017 (UTC)
While I was cleaning out Category:Pages containing cite templates with deprecated parameters I saw a lot of misused |author=
and |editor=
parameters where editors had added inappropriate annotations. That experience and this discussion were the impetus to add name checks to the Module sandbox. I have added code that detects a variety of editor annotations that occur at the end of values assigned to author, contributor, interviewer, editor, and translator names. Still to do is similar annotations that occur at the begining of the name value. For examples see my sandbox: Special:Permalink/776334484
—Trappist the monk (talk) 11:18, 20 April 2017 (UTC)
- Looks good. I tested a few more cases where the author or editor's first name was "Ed" (short for Edward), and none of them gave me an error, even when I formatted them in slightly incorrect ways. – Jonesey95 (talk) 12:35, 20 April 2017 (UTC)
Added checks for annotation that precedes a name. See Special:Permalink/776493274. Are there other variants of inappropriate editor annotation that I've missed? Do these tests catch things that they should not catch?
—Trappist the monk (talk) 10:43, 21 April 2017 (UTC)
related bug fix
There is a minor rendering bug in the live module that inserts extra punctuation between <author list> and <editor list> when |contributor=
is set and |date=
is not set. Fixed, I think in the sandbox:
Wikitext | {{cite book
|
---|---|
Live | <contributor list>. Preface. Title. By <author list>. <editor list> (ed.). {{cite book}} : |author= has generic name (help)
|
Sandbox | <contributor list>. Preface. Title. By <author list>. <editor list> (ed.). {{cite book}} : |author= has generic name (help)
|
—Trappist the monk (talk) 11:14, 18 April 2017 (UTC)
Way to override |title requirement, or to replace title with a description?
Hey, I hope this is the right place. I was wondering if there was a way to use, say {{cite journal}}
without having a title? Sometimes I need to cite pieces in academic journals that don't have a title, per se. The most obvious example of this is a book review, which generally would be cited as [Review of such-and-such a work], where in lieu or or alongside any proper title is a description of the work itself; and titles and descriptions are distinguished in formatting. Right now I just have |title=[Review of such-and-such]
, but that creates the unsightly "[Review of such-and-such]". And if there is a proper title and a description, then it would have to end up as "Author X has done it again [Review of such-and-such]". For examples of this latter type, see this example from APA 6:
- Schatz, B. R. (2000, November 17). Learning by text or context? [Review of the book The social life of information, by J. S. Brown & P. Duguid]. Science, 290, 1304. doi:10.1126/science.290.5495.1304
- "If the review is untitled, use the material in brackets as the title; retain the brackets to indicate that the material is a description of form and content, not a title."
And these examples from CMoS 16 (the first two as notes, the third as a bibliography entry):
- Ben Ratliff, review of The Mystery of Samba: Popular Music and National Identity in Brazil, by Hermano Vianna, ed. and trans. John Charles Chasteen, Lingua Franca 9 (April 1999): B13–B14.
- David Kamp, “Deconstructing Dinner,” review of The Omnivore’s Dilemma: A Natural History of Four Meals, by Michael Pollan, New York Times, April 23, 2006, Sunday Book Review, http://www.nytimes.com/2006/04/23/books/review/23kamp.html.
- Sorby, Angela. Review of Songs of Ourselves: The Uses of Poetry in America, by Joan Shelley Rubin. American Historical Review 113 (April 2008): 449–51. doi:10.1086/ahr.113.2.449.
Does this make sense? Is there a way to not have a title (i.e., something that is surrounded with quotation marks) and instead (or in addition) have a description? Thanks! Umimmak (talk) 21:52, 18 April 2017 (UTC)
- Aesthetics are not the main concern when it comes to citing claims. What if a citation looks good but is illegible or obtuse? In any case, almost all serials that review works with some regularity have a "Reviews" column, section, or department. You can use
|department=Reviews
or similar. Additionally, you have to include the information that will help others easily discover the source: if the review has a title, you should use that title - or at least as much of the title as would be required to make it a legible, discoverable citation. If the review's title is the title of the reviewed work, then use that. Hopefully, helped by the rest of the citation, the context will be obvious to the average reader. 65.88.88.126 (talk) 22:36, 18 April 2017 (UTC)
- Previous discussion such as it was ... I don't know of any other
- —Trappist the monk (talk) 23:00, 18 April 2017 (UTC)
- Perhaps a
|descriptive-title=yes
option would work, turning off the default quotation marks around a news or journal article title? Imzadi 1979 → 23:21, 18 April 2017 (UTC)- Yeah perhaps, although what happens when you need both a title and a description? Umimmak (talk) 11:51, 19 April 2017 (UTC)
- We had a brief discussion on it in the context of cite interview, which cites a discussion from archive 5. --Izno (talk) 23:27, 18 April 2017 (UTC)
- Perhaps a
- Of the three examples provided by Editor Umimmak, in each case, I think I can find a title and so can construct three cs1 templates:
- Schatz, B. R. (17 November 2000). "Learning by text or context?". Books. Science. 290 (5495): 1304. doi:10.1126/science.290.5495.1304.
- Kamp, David (23 April 2006). "Deconstructing Dinner". Sunday Book Review. The New York Times (The Omnivore’s Dilemma: A Natural History of Four Meals, by Michael Pollan).
- Sorby, Angela (April 2008). "Joan Shelley Rubin. Songs of Ourselves: The Uses of Poetry in America". Featured Reviews. American Historical Review. 113 (2): 449–51. doi:10.1086/ahr.113.2.449.
- For Shatz, the term 'review' does not appear on the linked page though the actual article may use it. For this reason I left out mention of that. In Kamp, because
|department=Sunday Book Review
pretty well describes the type of the article, I made|type=The Omnivore’s Dilemma: A Natural History of Four Meals, by Michael Pollan
. Similarly,|department=Featured Reviews
means that it is not necessary to describe the type and because the reviewed work's title in in the article title, no need to use|type=
. - —Trappist the monk (talk) 23:59, 18 April 2017 (UTC)
- But those three are wildly inconsistent and don't all provide sufficient information like the author and title of the reviewed work, which most style guides recommend. The Schatz example is a book review; it's in the "Books et al." section and the article has an info box with the publication details of the work in question. But only having the title "Learning by Text or Context?" doesn't provide information to the reader that it's a review of Brown & Duguid 2000.
- For the Sorby review, the actual listed title is "Joan Shelley Rubin. Songs of Ourselves: The Uses of Poetry in America. Cambridge, Mass.: Belknap Press of Harvard University Press. 2007. Pp. 470. $29.95"; if you modify it, say, by removing extra information like the price, then you shouldn't surround it in quotes as it suggest that's the title.
- And sometimes using
|type=
and sometimes using|title=
for a description of the work (cf. the proposed templates for Kamp vs Sorby) seems wildly inconsistent. Umimmak (talk) 11:50, 19 April 2017 (UTC)- If Schatz is a review, then,
|type=Review
, problem solved. It is not the purpose of a citation to explain to reader what the cited content contains or describes. The purpose of a citation is to assist readers in locating the source that supports claims made in a Wikipedia article. If I go to the library and checkout the 17 November 2000 issue of Science and look in the table of contents, I likely won't find any reference to Brown & Duguid but I will find the title "Learning by text or context?" and that review's author. (Apparently not possible to directly link to that issue's TOC but a link to the TOC is available at the summary page).
- If Schatz is a review, then,
-
- The bibliographical details of Rubin's book are included in the review's title but to include them here only confuses the issue. Our reader does not need to have those details when seeking the review at the public library. I can imagine a reader checking the book for something that was written in the review because the book's bibliographic detail is the first thing he reads after the title. One can omit the reviewed work's bibliographic details as I did or hint at them with ellipses or include an editor's note: [bibliographic detail omitted]; in any of these cases the reader will be able to locate the review.
-
- In none of the example templates that I constructed did I use
|title=
as a descriptor. In each case, the title of the review was supplied by the source and was obvious to me. I did not set out to be wholly consistent; that isn't my job here. I did set out to show how I think these three reviews might be cited; that I did them differently just shows that there are different possible methods. It is for you to impose consistency when you create citations in articles. - —Trappist the monk (talk) 12:58, 19 April 2017 (UTC)
- In none of the example templates that I constructed did I use
Add error message for circular cites?
We constantly see new users citing other Wikipedia articles. I think it would be very useful if the cite templates generated an error message when a Wikipedia url was placed in the url field (maybe also when "Wikipedia" was placed in {{cite web}}'s publisher and website fields). Maybe something like:
- Other Wikipedia articles should not be used for citations. See WP:CIRCULAR.
There are rare exception—proper citations to Wikipedia pages such as in articles about Wikipedia—but they're very uncommon. (I don't think the error message should acknowledge these rare exceptions; it should just state the rule that's almost always true.) If anyone agrees we should do this and someone can provide the code (I cannot), we would need a way to turn off the error message for proper uses. If we reached that stage, if necessary, I would volunteer to spend the time (within reason) to find all instances and implement whatever that fix might be (maybe |WP-url=yes), if I had some help in generating a list of all articles with such circular citations.--Fuhghettaboutit (talk) 14:05, 20 April 2017 (UTC)
- I wonder if this wouldn't be better done by a filter. The CS1 templates are not the only places where a reference to another article might show up... --Izno (talk) 14:27, 20 April 2017 (UTC)
Weird placement of |language=
with Template:Cite Journal
Hey, I was just wondering why the |language=
gets displayed between |journal=
and |volume=
. The |language=
describes the language of the article (i.e., what |title=
describes) not the entire journal, so I would imagine it to be either near the title of the article or somehow modifying the entire citation. Right now it makes it seem like the entire series of a journal is in whatever language instead of just the article under discussion, which is quite often not the case as there are multi-language journals. For a concrete example, see below, which suggests to me at least the entire journal Africa is in German instead of just the article by Lukas, especially as there's no punctuation separation between |journal=
and |language=
:
- Lukas, J. (1938). "The Phonetic Structure of Somali by E. Lilias Armstrong". Review of Books. Africa: Journal of the International African Institute (in German). 11 (1): 121–122. JSTOR 1155231.
Is there a reason for this, or am I missing something obvious? This just doesn't seem to be super clear for a reader. Umimmak (talk) 14:43, 21 April 2017 (UTC)
- This occurs for most of the citation templates which might have a sub-work unit (notably, websites, encyclopedias, and so-forth, and even contributions to some books which might be in language X versus the book's Y). I can't recall having seen a discussion regarding the topic since the module-ization of the templates. I agree it is somewhat confusing. There might be some desire to deprecate language in favor of e.g. |work-language... OTOH, I'm not entirely sure why we indicate the language at all. I suppose it might prevent someone from spending time finding a document were they to know they could not read the language of that document, but I wonder if that isn't (usually) immediately obvious when the title is in a certain language. --Izno (talk) 15:01, 21 April 2017 (UTC)
- @Izno: "I wonder if that isn't (usually) immediately obvious when the title is in a certain language" — well in the example I have above,
|title=
,|department=
, and|journal=
all don't suggest the article would be in anything other than English, and the JSTOR link doesn't provide a preview for this work unless you log into your account/have access. I agree, though, that it probably isn't necessary to add the language a work is written in; I just thought that all non-English sources had to be explicitly tagged since otherwise sources are assumed to be English and that's why|
[or rather|language=en
] doesn't show up (although there certainly are times when the|journal=
would suggest a work would not be in English and the|title=
is of no help. Umimmak (talk) 15:25, 21 April 2017 (UTC)
- @Izno: "I wonder if that isn't (usually) immediately obvious when the title is in a certain language" — well in the example I have above,
- Yes, the language note would make more sense immediately following the title of the work cited. I don't see a need for a parameter to indicate the language of a containing book or journal, though. Kanguole 15:20, 21 April 2017 (UTC)
- Or maybe after
|trans-title=
? Especially since any|url=
would be linked to by|title=
and|trans-title=
combined, see, e.g.:- "Engelsche vacantieleergangen" [English vacation courses] (PDF). Kroniek. Leuvensche Bijdragen (in Dutch). 13 (1–2): 134. 1921.
- But I definitely agree that only one tag for language is needed; I can maybe understand why a reader might want to know the language of the actual source, but I don't know why it would be necessary to know all the languages in a given book/journal/encyclopedia/whatever. Umimmak (talk) 15:31, 21 April 2017 (UTC)
- Trans-title is not linked in the sandbox. The same in the sandbox: "Engelsche vacantieleergangen" [English vacation courses] (PDF). Kroniek. Leuvensche Bijdragen (in Dutch). 13 (1–2): 134. 1921. --Izno (talk) 15:50, 21 April 2017 (UTC)
- Sorry, @Izno: I'm confused what you're getting at. Does my citation not display as:
- That's how it looks for me in articles as well as my sandbox. Umimmak (talk) 16:29, 21 April 2017 (UTC)
- Not in your sandbox--the template's sandbox. It was a note to indicate that trans-title is not linked in the sandbox, since you made the comment
Especially since any
. --Izno (talk) 16:33, 21 April 2017 (UTC)|url=
would be linked to by|title=
and|trans-title=
combined- Oh, weird that it would be formatted differently when it's actually used an article as compared to when you're looking at it in a sandbox. Strange. Umimmak (talk) 16:44, 21 April 2017 (UTC)
- You misunderstand. The cs1|2 templates use Module:Citation/CS1 and related modules to render citations. Changes to those modules are made first in the sandbox versions (Module:Citation/CS1/sandbox ...) before they are made to the live versions. Editor Izno's example of your citation (without
|trans-title=
linked) used the module's sandbox by calling{{cite journal/new}}
. All of the cs1|2 templates have a '/new' version so that changes to the module sandboxen can be evaluated. The '/new' versions of the template are not for use in article space. At the next module update from sandbox to live,|trans-title=
will no longer be linked anywhere on en.wiki. - —Trappist the monk (talk) 17:06, 21 April 2017 (UTC)
- Oooohhh, I see; I didn't realize there was already a to-be-implemented change for how
|trans-title=
gets linked (or rather doesn't get linked). Thanks for clarifying. (Can you tell I'm new to this, haha). - [Quick-edit, but wait, it's still weird that the PDF icon is separated from (PDF) by the title translation, looking at the sandbox version in Izno's example, no?] Umimmak (talk) 17:21, 21 April 2017 (UTC)
- Not clear to me that changing the rendering so that the file format annotation flollow the link but precedes the translated title is any better:
- "Engelsche vacantieleergangen" (PDF) [English vacation courses]
- —Trappist the monk (talk) 17:44, 21 April 2017 (UTC)
- Not clear to me that changing the rendering so that the file format annotation flollow the link but precedes the translated title is any better:
- Oooohhh, I see; I didn't realize there was already a to-be-implemented change for how
- You misunderstand. The cs1|2 templates use Module:Citation/CS1 and related modules to render citations. Changes to those modules are made first in the sandbox versions (Module:Citation/CS1/sandbox ...) before they are made to the live versions. Editor Izno's example of your citation (without
- Oh, weird that it would be formatted differently when it's actually used an article as compared to when you're looking at it in a sandbox. Strange. Umimmak (talk) 16:44, 21 April 2017 (UTC)
- Not in your sandbox--the template's sandbox. It was a note to indicate that trans-title is not linked in the sandbox, since you made the comment
- Trans-title is not linked in the sandbox. The same in the sandbox: "Engelsche vacantieleergangen" [English vacation courses] (PDF). Kroniek. Leuvensche Bijdragen (in Dutch). 13 (1–2): 134. 1921. --Izno (talk) 15:50, 21 April 2017 (UTC)
- Or maybe after
Update?
I'll start a new section on this, since TTM's post about it got lost: It's been nearly 6 months since our previous release. Maybe we should update the module soon? --Izno (talk) 15:52, 21 April 2017 (UTC)
- Not lost. See my last post in this discussion. Upon the death of
|coauthor(s)=
the plan was (and still is) to announce an update to the live module this weekend with the update to follow a week later as it normally does. - —Trappist the monk (talk) 16:27, 21 April 2017 (UTC)
- Let's make sure Help_talk:Citation_Style_1/Archive_31#Category:CS1_errors:_SSRN gets in then. I did a lot of SSRN-related cleanup, and the category would be useful to get mistakes I've made / bad SSRNs. Headbomb {t · c · p · b} 17:01, 21 April 2017 (UTC)
- I just sent an e-mail to the SSRN folks to ask if they have a spec for their ID. – Jonesey95 (talk) 21:07, 21 April 2017 (UTC)
- Let's make sure Help_talk:Citation_Style_1/Archive_31#Category:CS1_errors:_SSRN gets in then. I did a lot of SSRN-related cleanup, and the category would be useful to get mistakes I've made / bad SSRNs. Headbomb {t · c · p · b} 17:01, 21 April 2017 (UTC)
I chose ssrn limits to be 100 and 3 million. This insource: search pattern, insource:/\| *ssrn *= *294[0-9]{4,}/i
, finds one use in the 2,940,000–2,949,999 range (2940297). That would suggest that the 3 million upper limit is sufficient for the time being.
- Title. SSRN 99.
{{cite book}}
: Check|ssrn=
value (help) - Title. SSRN 100.
- Title. SSRN 3000000.
- Title. SSRN 3000001.
—Trappist the monk (talk) 22:30, 21 April 2017 (UTC)
update to the live cs1|2 module weekend of 29–30 April 2017
I expect to update the live cs1|2 modules on the weekend of 29–30 April. Changes since the last update are:
- override mw:Extension:CLDR language definition for code bn; (discussion)
- remove support for special
{{cite interview}}
parameters; (discussion) - fix spacing oddity in maint cat messaging; (discussion)
- fix multi-byte character |vauthors= bug; (discussion)
- detect and alert on wayback machine deprecated liveweb host name; (discussion)
- move transtitle out of external link; (discussion)
- access signal lock images per RFC; (discussion)
- remove duplicate lock image code; (discussion)
- replace cite arxiv unsupported parameter test with list of supported in whitelist; (discussion)
- support for cite biorxiv and cite citeseerx; (discussion)
- remove support for coauthor and coauthors; (discussion)
- extra punctuation bug fix; (discussion)
to Module:Citation/CS1/Configuration:
- remove cite interview special parameters;
- add Burmese language script-title code;
- access signal lock images per RFC;
- remove duplicate lock image code;
- remove support for coauthor and coauthors;
- add ssrn validation; (discussion)
- drop the dx. in //dx.doi.org/... (discussion)
to Module:Citation/CS1/Whitelist
- removed cite interview special parameters;
- 2017-03-26: support for cite biorxiv and cite citeseerx;
- remove support for coauthor and coauthors;
to Module:Citation/CS1/Identifiers
- remove duplicate lock image code;
- add ssrn validation;
- modify PMC error check to allow "PMC" identifier prefix; (discussion)
- support for cite biorxiv and cite citeseerx;
—Trappist the monk (talk) 11:11, 22 April 2017 (UTC)
- Would it be possible to change the yellow/blue lock to the grey lock? No one was really happy with either color, the commnunity was evenly split, and grey pretty much addresses everyone's concerns. I'd rather avoid a lengthy RFC on the issue for such a simple and IMO reasonable change. Headbomb {t · c · p · b} 11:19, 22 April 2017 (UTC)
- I don't think it appropriate to disregard the outcome of an RFC. The community uses RFCs as an accepted method for making considered decisions. To hold an RFC and then disregard the decision essentially renders the process meaningless. You invoked the last RFC; you can invoke another.
- —Trappist the monk (talk) 12:27, 22 April 2017 (UTC)
Access lock RFC follow up:
![]() |
|
The visual design RFC for the access locks concluded with an essentially 50-50 split community on the colour of the "free with conditions" lock (yellow vs blue). This RFC is to investigate support for a third option (grey). Headbomb {t · c · p · b} 14:55, 22 April 2017 (UTC)
Options
The paste options were 1&2
People who supported this cited the intuitiveness of the traffic light colour scheme, people who opposed it mostly cited the yellow not being very yellow, and the colourblind-friendlier blue.
People who supported this cited the yellow not being very yellow in the previous scheme, and the colourblind-friendlier blue. People who opposed this cited the lack of a recognizable colour scheme of any sort. It also tends to get lost in a sea of blue. This had marginally more support (1 more !vote out of 22 or so).
However, late in the RFC, an alternate colour scheme was proposed as an alternative and garnered some support, but it was too late in the RFC to be introduced an option. Let's consider it now.
This has neither drawback of schemes 1 & 2. Green/Grey/Red is an intuitive colour scheme, is just as colourblind friendly as Green/Blue/Red, and doesn't get as lost in the sea of blue as the blue one does. I'd have included arguments against grey, but I know of none.
Basically, how this would look is something like
- Romaine, M.; Zatz, S.; Brown, K.; Lundberg, G.D. (2009). "So long but not farewell: The Medscape Journal of Medicine (1999-2009)"
. Medscape Journal of Medicine. 11 (1): 33. Retrieved 21 February 2009.
- Romaine, M.; Zatz, S.; Brown, K.; Lundberg, G.D. (2009). "So long but not farewell: The Medscape Journal of Medicine (1999-2009)"
. Medscape Journal of Medicine. 11 (1): 33. Retrieved 21 February 2009.
- Romaine, M.; Zatz, S.; Brown, K.; Lundberg, G.D. (2009). "So long but not farewell: The Medscape Journal of Medicine (1999-2009)"
. Medscape Journal of Medicine. 11 (1): 33. Retrieved 21 February 2009.
!Vote
Support #3 as proposer. Headbomb {t · c · p · b} 14:55, 22 April 2017 (UTC)
Discussion
I do not know whether this is the proper procedure, considering that the referenced RFC was submitted at a much better attended forum. At best, imo whatever discussion results here, should be used to stage a proper RFC at the proper forum. Especially since the original RFC seems inconclusive on the related issues. 65.88.88.126 (talk) 20:56, 22 April 2017 (UTC)
- The former RFC also had a much wider scope. This is listed and advertised at both Wikipedia:Requests for comment/Wikipedia technical issues and templates and Wikipedia:Requests for comment/Wikipedia style and naming, as well as through the Wikipedia:Feedback request service. Feel free to post neutrally worded notices in other places you deem relevant. Headbomb {t · c · p · b} 21:42, 22 April 2017 (UTC)
- My opinion: Regardless of which color you use for it, the middle symbol is unrecognizable as a lock or as anything else. Maybe it is a fountain with a two-tone base? Maybe it is a spray bottle? Maybe it is a necklace with a big pendant? It is just visual clutter rather than useful information. —David Eppstein (talk) 18:23, 23 April 2017 (UTC)
- Well, that's the appearance that got settled on in that RFC. Personally I would have gone with this shape. But let's focus on the color for now, shall we? Headbomb {t · c · p · b} 19:04, 23 April 2017 (UTC)
- The choices are puke, lost-in-a-sea-of-blue, or blander-than-bland. None are worth advocating. —David Eppstein (talk) 22:00, 23 April 2017 (UTC)
- Well, that's the appearance that got settled on in that RFC. Personally I would have gone with this shape. But let's focus on the color for now, shall we? Headbomb {t · c · p · b} 19:04, 23 April 2017 (UTC)
Minor tweak to doi.org links
https://www.crossref.org/display-guidelines/ suggests that we link to https://doi.org/10.nnnn/xxx.xxx, dropping the "dx." portion of the fully qualified domain name. I suggest that we make this minor, non-urgent change to the Module sandbox after this weekend's update. – Jonesey95 (talk) 22:28, 25 April 2017 (UTC)
- Why not now? No reason to delay this till the next update.Headbomb {t · c · p · b} 05:13, 26 April 2017 (UTC)
- Done. Headbomb {t · c · p · b} 05:22, 26 April 2017 (UTC)
- I suggested doing it later because we should be in a freeze period before deployment, we haven't done any testing yet, and this module is used in millions of pages. Also, the change is not urgent. – Jonesey95 (talk) 13:38, 26 April 2017 (UTC)
- OTOH, the change is simple and we have no evidence now nor will have any in the immediate future to suggest that doi.org is worse than dx.doi.org without such testing as is untenable. I see no problem with this change here. --Izno (talk) 13:46, 26 April 2017 (UTC)
- I suggested doing it later because we should be in a freeze period before deployment, we haven't done any testing yet, and this module is used in millions of pages. Also, the change is not urgent. – Jonesey95 (talk) 13:38, 26 April 2017 (UTC)
- Done. Headbomb {t · c · p · b} 05:22, 26 April 2017 (UTC)
Location for cite speech ambiguous
I'm looking at Template:Cite speech/doc and it seems to me that the location parameter is ambiguous in meaning. I believe Module:Citation/CS1 understands it as the place of publication, but one of the examples given is this:
- Last, First (April 1, 2000). Title (Speech). Event. Location.
On the one hand, I suppose I'm requesting that the documentation be clarified. On the other, I wonder if Module:Citation/CS1 needs to be updated to be able to include the actual location of the speech and event, which seems like an appropriate thing to include in a citation for an unpublished speech, if not for all speeches. Sondra.kinsey (talk) 23:09, 28 April 2017 (UTC) PS. Please use {{reply to}}; I don't watch this page.
- Unpublished sources, including speeches, may not be cited. Published speeches (in any medium) should follow the style guideline, which considers "location" as preferably, the (speech) publisher's location, and as a secondary choice the location where the work (speech) was produced. 64.134.66.143 (talk) 12:12, 29 April 2017 (UTC)
- It might not be documented (very well), but there is both a
|publication-place=
and a|location=
. Cite speech might reasonably make use of both. That said, you should WP:SAYWHEREYOUGOTIT--so I am not entirely sure about your use case. Maybe you can provide the specific citation you have in mind. --Izno (talk) 13:08, 29 April 2017 (UTC)
lingering deprecated parameters
This discussion begat this series of edits to Module:Citation/CS1/Whitelist/sandbox wherein |ARXIV=
and |BIBCODE=
were deprecated. Those changes went live on 29 October 2016. In the interim I think that support for the now long-deprecated parameters should have been removed from the whitelist sandbox and from Module:Citation/CS1/Configuration/sandbox. That did not happen.
Rather than add these parameters to the help documentation (they never were) and wait for the next update and because they do not appear be in use anywhere (none were in Category:Pages containing cite templates with deprecated parameters at the time that it was emptied), without objection, tomorrow I shall mark them as unsupported in Module:Citation/CS1/Whitelist and Module:Citation/CS1/Configuration.
We still have |version=
marked as deprecated when it is used with {{cite arxiv}}
(deprecated since 25 July 2015). This too, I shall mark as unsupported in Module:Citation/CS1/Whitelist. More complex changes to Module:Citation/CS1 are also needed but can be deferred to the next update.
—Trappist the monk (talk) 13:03, 29 April 2017 (UTC)
- Great! I support all these changes. Thank you so much for your work. − Pintoch (talk) 13:40, 29 April 2017 (UTC)
Done. The changes to Module:Citation/CS1 were not so complex as I imagined so that has been done also.
—Trappist the monk (talk) 09:44, 30 April 2017 (UTC)
|title=Archived copy
Can a new maintenance category be created (and coded into Module:citation/CS1) for when Archived copy
is used as a title in a cite-template? Currently we have 38 000+ articles (insource:/\|title\=Archived copy/), and I bet that not a single one of them should use that as a title. (t) Josve05a (c) 14:48, 29 April 2017 (UTC)
- And another could be finding
|work=Wayback Machine
&|work=Wayback Machine
--(t) Josve05a (c) 15:16, 29 April 2017 (UTC)- This looks like it was caused by IABot. @Cyberpower678: Can you let us know whether it's still occurring, whether it's a bug in the bot or something wrong in the IA API, and whether it might be possible to get IABot re-run on these articles? --Izno (talk) 17:09, 3 May 2017 (UTC)
- Yes, it is IABot that is the culprit in this case. The reason here though is deeper: IABot changed the citation format of the references in question from free-form to scripted (templated). Since the "title" in free-form citations is not easily parsed by machines, it made the default substitution
|title=Archived copy
. 72.43.99.146 (talk) 12:44, 4 May 2017 (UTC)
- Yes, it is IABot that is the culprit in this case. The reason here though is deeper: IABot changed the citation format of the references in question from free-form to scripted (templated). Since the "title" in free-form citations is not easily parsed by machines, it made the default substitution
- This looks like it was caused by IABot. @Cyberpower678: Can you let us know whether it's still occurring, whether it's a bug in the bot or something wrong in the IA API, and whether it might be possible to get IABot re-run on these articles? --Izno (talk) 17:09, 3 May 2017 (UTC)
CS1 errors in the "How the templates work" section
Presumably, the CS1 errors in the "How the templates work" section were unintended and undesired. Here, I've removed the |date=Date
part of the wikitext for the example citations to get rid of them. Improve as needed, please. Wtmitchell (talk) (earlier Boracay Bill) 02:24, 30 April 2017 (UTC)
- There were actually intentional, and it would be unfortunate to completely remove any date indication there because the date does shift positions and formatting depending on the presence or absence of author parameters. So to show something, I used
|date=n.d.
and added a note below the examples. That may need refinement though. Imzadi 1979 → 05:13, 30 April 2017 (UTC)- Next time you might want to use a <! -- comment --> to explain. EEng 05:48, 30 April 2017 (UTC)
Remove category "CS1 errors: coauthors without author"
Now that |coauthors=
is unsupported, we should be able to delete Category:CS1 errors: coauthors without author, I believe. Do we need code changes to the module, or can we just delete the category? – Jonesey95 (talk) 13:38, 30 April 2017 (UTC)
- redlink now.
- —Trappist the monk (talk) 14:00, 30 April 2017 (UTC)
- Perfect. Thanks. – Jonesey95 (talk) 14:38, 30 April 2017 (UTC)
Parameters first1 on Commons template
The template commons:Template:Cite_journal on Wikimedia Commons does not have implemented parameters first1= |last1= |first2= |last2= etc. commons:Template talk:Cite journal#Parameters. Could you improve it, please? This is crucial for proper referencing of images. Thanks. --Snek01 (talk) 18:51, 1 May 2017 (UTC)
- What Commons do with their templates is, broadly speaking, not our concern. Have you raised the issue at c:Template talk:Cite journal? --Redrose64 🌹 (talk) 20:55, 1 May 2017 (UTC)
- Yes, see the link above. --Snek01 (talk) 21:53, 1 May 2017 (UTC)
metadata bug
There is a metadata bug. Somehow, some of the multiple bytes of unicode characters outside of the ascii character set are not all included in the metadata:
{{cite book |title=Я}}
produces this metadata for the title:
&rft.btitle=%D0%AF
– correct
and:
{{cite book |title=ש}}
&rft.btitle=%D7%A9
– correct
but:
{{cite book |title=魂}}
&rft.btitle=%E9%82
– should be:%E9%AD%82
and:
{{cite book |title=–}}
&rft.btitle=%93
– should be:%E2%80%93
From these simple examples, it would appear that something is buggering up three-byte unicode percent encoding. This problem was apparently noticed just after the 29–30 April 2017 update to the live module suite. I am at a loss to explain this problem as a result of the changes that were incorporated in the update. So, I have reverted the sandboxen to the last live version before the update. Let me repeat that:
the current sandboxen DO NOT currently contain the next version of the live CS1 modules. Except in search of an answer to this issue, changes should not be made to the CS1 modules.
After reverting to the last live version, the simple tests above produce the same results.
The modules use the function mw.uri.encode()
to percent-encode metadata and also to encode identifiers like |doi=
. If I make up a doi with a character that doesn't work in the metadata, the doi link is encoded correctly:
{{cite book/new |title=Title |doi=10.1234/.魂}}
//dx.doi.org/10.1234%2F.%E9%AD%82
From all of this, I know that the problem has been with us for some time and that the problem appears to be confined to the metadata. Now it is just a matter of locating it.
—Trappist the monk (talk) 15:19, 2 May 2017 (UTC)
- fixed. This line:
value = value:gsub ('[\226\128\141\226\128\139\194\173]', '')
- changed to this:
value = mw.ustring.gsub (value, '[\226\128\141\226\128\139\194\173]', '');
- The purpose of this line is to remove invisible characters zero-width joiner and zero-width space, and the soft hyphen because these characters are pointless in the metadata. Because these characters are invisible, the code writes out their individual decimal byte values:
\226\128\141
for zero-width joiner, etc.
- The problem arises because value:gsub() operates on bytes, not characters. When
value
is an en dash, its byte values are\226\128\93
. In the original version,value:gsub()
finds both the\226
and the\128
bytes and removes them leaving the \147 which is later percent encoded to %93. Similarly, 魂 has byte values of\233\173\130
, value:gsub() finds and removes the\173
leaving behind\233\130
which percent encodes to%E9%82
.
- The new version treats the characters as characters.
- I have fixed this bug in the live version and restored the sandboxen.
{{cite book |title=魂}}
'"`UNIQ--templatestyles-00000075-QINU`"'<cite class="citation book cs1">''魂''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%E9%AD%82&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
- —Trappist the monk (talk) 17:06, 2 May 2017 (UTC)
- Good catch. Checking the modules for other unicode-related possible ommissions/incompatibilities might be a good idea. 65.88.88.127 (talk) 18:25, 2 May 2017 (UTC)
- Two things. The first, boxes is the plural of box, not boxen. You may enjoy using non-standard plurals, but this is confusing to people, especially those that wouldn't know oxen is the plural of ox. The second, there are lots of 'value:gsub' around that line of code you've updated. Should those be updated as well? Headbomb {t · c · p · b} 18:31, 2 May 2017 (UTC)
- The lines of code most similar to the offending line are:
value = value:gsub ('\226\128\138', ' ');
value = value:gsub ('[\009\010\013]', ' ');
- In the first of these the pattern is a string of bytes so
value
must match exactly. In the second, like regex, the pattern is a set of three individual bytes so will match with any of the three single-byte characters horizontal tab, line feed, or carriage return. - —Trappist the monk (talk) 19:35, 2 May 2017 (UTC)
- The lines of code most similar to the offending line are:
- Boxen is a harmless and amusing hacker in-joke; I have no problem with it here (on a talk page) although I wouldn't use it in article-space of course. And thanks, Trappist the monk, for catching and fixing this! —David Eppstein (talk) 18:42, 2 May 2017 (UTC)
- Credit for the discovery of this error belongs to Editor Silas S. Brown who reported it here.
- —Trappist the monk (talk) 19:35, 2 May 2017 (UTC)
- Two things. The first, boxes is the plural of box, not boxen. You may enjoy using non-standard plurals, but this is confusing to people, especially those that wouldn't know oxen is the plural of ox. The second, there are lots of 'value:gsub' around that line of code you've updated. Should those be updated as well? Headbomb {t · c · p · b} 18:31, 2 May 2017 (UTC)
- Good catch. Checking the modules for other unicode-related possible ommissions/incompatibilities might be a good idea. 65.88.88.127 (talk) 18:25, 2 May 2017 (UTC)
Re: "boxen". Yes, a hacker in-joke, but it has appeared in a headline in a reliable source at least once. It appears in article space with an explanation in a few places, and there's Pizza boxen (a redirect); I agree with David Eppstein that it should not be used casually in article space. – Jonesey95 (talk) 20:22, 2 May 2017 (UTC)
Table overflow bug
When User:SpikeToronto recently made this edit and many similar ones, trying to improve the table format for iPads, it actually broke the format for an ordinary Chrome browser on a Windows laptop. For example, unless the browser window is extremely wide, the right side of the table in Template:Cite book/doc#TemplateData gets truncated, cutting off words and the column-sort arrows, with no horizontal scrollbar to reach the truncated content. Is there a way to make these tables work properly on both types of devices? —Patrug (talk) 07:22, 3 May 2017 (UTC)
- This is not a cs1|2 bug. That TemplateData table is imposed on us by the developers of Visual editor. If Editor SpikeToronto's edit doesn't work here then likely it doesn't work elsewhere.
You might try discussing this issue with Editor Bermicourt who is apparently the author of{{TemplateData}}
which, I gather has the job of rendering the TemplateData table. - —Trappist the monk (talk) 08:29, 3 May 2017 (UTC)
- Good info, thanks. Let's see if SpikeToronto can shed any light on the situation, and why these edits were "required" for iPads. —Patrug (talk) 09:58, 3 May 2017 (UTC)
- Not so good info, actually.
{{TemplateData}}
doesn't have the job of rendering the TemplateData table. - —Trappist the monk (talk) 10:12, 3 May 2017 (UTC)
- Not so good info, actually.
- Good info, thanks. Let's see if SpikeToronto can shed any light on the situation, and why these edits were "required" for iPads. —Patrug (talk) 09:58, 3 May 2017 (UTC)
- One observation: there is a wider problem with the rendering of tables on mobile devices, so this may not even be strictly a <templatedata> issue. My past experience has been that you have to tap/drag at the screen edge to see the hidden info. Other than that, as Trappist mentioned, this is not the right forum. 65.88.88.126 (talk) 15:49, 3 May 2017 (UTC)
- Patrug, WP:VPT is probably a better forum for this question. I get the same results on Chrome for Windows, FWIW. – Jonesey95 (talk) 17:07, 3 May 2017 (UTC)
- One observation: there is a wider problem with the rendering of tables on mobile devices, so this may not even be strictly a <templatedata> issue. My past experience has been that you have to tap/drag at the screen edge to see the hidden info. Other than that, as Trappist mentioned, this is not the right forum. 65.88.88.126 (talk) 15:49, 3 May 2017 (UTC)