Wikipedia

Help talk:Citation Style 1/Archive 27

< Help talk:Citation Style 1
Latest comment: 8 years ago by 24.193.13.108 in topic |title= and |work= are not synonyms in Template:Cite book
Archive 20←Archive 25Archive 26Archive 27Archive 28Archive 29Archive 30

id-access support

Latest comment: 8 years ago108 comments15 people in discussion

Per #Which identifiers, we should support

  • |bibcode-access=free
  • |doi-access=free
  • |hdl-access=free
  • |jstor-access=free
  • |ol-access=free
  • |osti-access=free

To make them display green open access locks at the end of their identifier. We should also update

to also support the same |foobar-access=yes and have the green open access locks.

And then we should update

to always display the green free access locks. Headbomb {talk / contribs / physics / books} 14:50, 23 September 2016 (UTC)

After a lot of fiddling, the prototype in the sandbox should be mostly functional.
always free
  • Doe, J. "Title". arXiv:1001.1234. {{cite journal}}: Cite journal requires |journal= (help)
  • Doe, J. "Title". bioRxiv 047720. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)
  • Doe, J. "Title". CiteSeerX 10.1.1.220.7880. {{cite journal}}: Cite journal requires |journal= (help)
  • Doe, J. "Title". PMC 50050. {{cite journal}}: Cite journal requires |journal= (help)
  • Doe, J. "Title". RFC 125. {{cite journal}}: Cite journal requires |journal= (help)
  • Doe, J. "Title". SSRN 871210. {{cite journal}}: Cite journal requires |journal= (help)
id-access


And so on. Note that currently |id-access=registration and |id-access=limited are allowed, although that makes little sense given the identifiers that currently use the system. Should we only allow |id-access=free? − Pintoch (talk) 13:02, 24 September 2016 (UTC)
It might make sense to support |id-acccess=registration/limited, but if we do that, only for doi and (possibly) jstor. However, I don't see anyone, even bots actually bothering to flag those, so I'd personally be in favour of only supporting 'free' per the WP:KISS principle, but it's not a strongly-held opinion. Headbomb {talk / contribs / physics / books} 13:24, 24 September 2016 (UTC)
I agree we should only support |id-access=free ([the documentation was updated to reflect that.) I have therefore [https://en.wiki.x.io/w/index.php?title=Module:Citation/CS1/Configuration/sandbox&diff=744752636&oldid=744680128 updated the code to reflect that. − Pintoch (talk) 06:24, 17 October 2016 (UTC)

Free locks vs url locks

Currently, the free green locks uses Trappist's version of the lock + hover message, while the newer url-access locks use my versions of the locks + hover messages. Those should be made consistent. Headbomb {talk / contribs / physics / books} 10:03, 27 September 2016 (UTC)

More importantly, we should settle the color vs. shape vs. accessibility issue. Having attended to that, we can create a uniformly consistent set of lock images to suit.
—Trappist the monk (talk) 12:42, 27 September 2016 (UTC)
We should, yes, but we should also have consistency in the initial rollout. Headbomb {talk / contribs / physics / books} 13:23, 27 September 2016 (UTC)
I'm quite happy with the current mix, the locks seem consistent to me. As far as I can tell, the only discrepancy is in the alt text: should it be short, like "free to read", or longer, like "A (paid) subscription is required to access this source"? I don't know what is best in terms of accessibility. Concerning shape and color, I think we all agree that one should be able to tell the locks apart from their shapes only. This is currently the case. Then, do we agree that it does not hurt to use different colors, as long as they are not crucial to understand what the locks mean? − Pintoch (talk) 05:43, 29 September 2016 (UTC)
My series of files is File:Lock-green.svg/File:Lock-yellow.svg/File:Lock-red.svg. File:Lock-green.svg differs ever so slightly from File:Free-to-read lock 75.svg in its shade of green (I used the same shade of green/yellow/red), but it also makes better use of its space, and matches the design of the yellow and red locks. Compare
    
Headbomb {talk / contribs / physics / books} 07:23, 29 September 2016 (UTC)

Here is an attempt to compare color contrast against two backgrounds. The values in the table are taken from this website. I included the en.wiki redlink color as a point of reference. Where the color contrasts aren't balanced, the table suggests alternate rgb values.

color contrasts
lock color background white background black
  #008400
4.9  
4.3  
  #007a00
5.5  
3.8  
  #7a7a00
4.6  
4.6  
  #7a0000
11.5  
1.8  
  #0077cc
4.7  
4.5  
redlink #ba0000
6.8
3.1
alternate colors
  #008900
4.6
4.6
  #ec0000
4.6
4.6
  #0077d6
4.6
4.6

—Trappist the monk (talk) 10:16, 29 September 2016 (UTC)

It should be simple manner to update green to 008900 and red to ec0000. I'll do that right away. Headbomb {talk / contribs / physics / books} 10:30, 29 September 2016 (UTC)
color contrasts
lock color background white background black
  #0077cc
4.7  
4.5  
  #008400
4.9  
4.3  
  #008900
4.6  
4.6  
  #7a7a00
4.6  
4.6  
  #ec0000
4.6  
4.6  

Done. Headbomb {talk / contribs / physics / books} 10:40, 29 September 2016 (UTC)

I've implemented this in the sandbox too. I've also tweaked the hover messages to be short and sweet, as well as vertically-aligned the locks so the bottom lines up with the bottom of the letter o. See "Title". {{cite journal}}: Cite journal requires |journal= (help)/"Title". {{cite journal}}: Cite journal requires |journal= (help)/"Title". arXiv:1001.1234. {{cite journal}}: Cite journal requires |journal= (help) Headbomb {talk / contribs / physics / books} 01:54, 30 September 2016 (UTC)
Nice! Although now, to be honest, I find the locks a bit too high - maybe scaling them down while keeping the baseline at the same place would help? But it's a matter of taste. − Pintoch (talk) 06:23, 30 September 2016 (UTC)
They're about as scaled down as they can be at their current size. However, we could shorten the locks' shackle, so that the overall image spans less height. Headbomb {talk / contribs / physics / books} 09:30, 30 September 2016 (UTC)
Or we could leave them like they are now. I was worried they would increase line size, but they don't seem to. Headbomb {talk / contribs / physics / books} 09:34, 30 September 2016 (UTC)
Restore the previous lock positioning. The new position is too high. At their highest points, the lock should be no higher than the height of the tallest character and should be no lower than lowest descender. The characters in the standard font that are both tallest and have the lowest descender are the [] characters, commonly part of arXiv identifier renderings:
Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [math.CT]. – live
Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [math.CT]. – sandbox.
—Trappist the monk (talk) 10:18, 30 September 2016 (UTC)
With my browser (with the standard font, I suppose), the live version is too low (it goes below []) and the sandbox is too high (it goes above []). − Pintoch (talk) 10:43, 30 September 2016 (UTC)
Play with your appearance settings. For me:
Cologne blue renders the baseline of the live lock at about the baseline of the font; the baseline of the sandbox lock is at about mid-height of a digit character so the top of the lock impinges on the line above it (the two locks in my previous example touch)
Modern is similar to Cologne blue except that the sandbox lock is slightly lower so that the two locks above do not touch
Monobook has the baselines lower. The live lock looks to be just a hair lower than the descender of the adjacent [ character; the baseline of the sandbox lock appears to be just a hair lower than the baseline of the font
Vector puts the baseline of the live lock at or maybe just a hair above the descender of the adjacent [; sandbox lock baseline appears at or slightly higher than the font baseline.
These would suggest that we should not be adjusting the vertical position of the locks.
—Trappist the monk (talk) 12:16, 30 September 2016 (UTC)
Hmmm... that is mighty annoying. I'm using monobook, which explains why they're so misaligned. I wonder if we can't tweak the skins themselves. I suppose it's good enough for now. Very much looking forward to things being rolled out. Trappist the monk, when could we expect this? Over the weekend? Headbomb {talk / contribs / physics / books} 12:23, 30 September 2016 (UTC)
Because of the alignment issue in the various skins, I've reverted that change.
In my mind the remaining accessibility issue is lock shape. The current locks are all the same shape except in the shackle which I think sufficiently vague and why the blue locks that I proposed used the lock-body to differentiate their individual meanings:
     
     
Ignoring color, and considering the locks as they might appear in gray-scale, there is little to distinguish the yellow from the red at the size that they will be used.
Changes to the live module are not generally made at a moment's notice. I publish a list of the changes to be made about a week ahead of the planned event so that editors have the chance to have a final say beforehand.
—Trappist the monk (talk) 11:05, 1 October 2016 (UTC)
The problem I have with the alternate set of locks, is that their shapes, while more visually different, are quite unclear.
     
     
Free vs Subscription I would say are about as equally clear in both sets of locks, although I don't like that the blue limited/subscription locks loses the middle circle [probably fixable by removing the middle blue dot in the free lock so they are consistent]. The issue really is the limited access lock. While the current version of the yellow lock might not be visually super distinct, it is clear in meaning (i.e. dashed shackle = not a hard lock). I think that issue is fixable by adjusting the shackle's dash density / tweak the shackle's appearance. The blue limited access lock has the opposite issue: it is visually quite distinct, but its meaning completely unclear, especially if it's not wedged between the other two locks. How is a fully closed lock with a half-filled body convey "This source is free to read under certain conditions"? It doesn't, and that is a much deeper issue because the icon itself doesn't make sense. Headbomb {talk / contribs / physics / books} 13:19, 1 October 2016 (UTC)
There, I've tweaked the dash density, and the yellow lock is now much more visually distinct from the red lock. Headbomb {talk / contribs / physics / books} 15:29, 1 October 2016 (UTC)
You are attempting to use fine detail to make the distinction but that fine detail is lost at 9px width (the size that is used in rendered citations). Essentially what you've created is a halftone shackle that appears closed at 9px. My original lock was based on the orange open-access lock ( ). My version opened the shackle farther because editors noted that they couldn't easily distinguish between open and closed. That's why I chose lock-body-fill as the way to differentiate among the three. In gray scale, and at 9px width, the halftone shackle is slightly fainter than the lock's body; both of which are slightly fainter than a subscription lock. At a comfortable reading distance, the gray-scale subscription and registration locks are distinguishable by shade but not by shape. It is not obvious that the two have different meanings.
Icons can't always communicate exact meaning given the constraints of a size that obscures detail. That's why we have tool tips and alt text so that readers learn what the icon means. Were I new to these icons, the halftone shackle and the half filled lock body would be equally incomprehensible. Is it even possible to fit the exact meaning of 'Free access subject to limited trial, subscription normally required' into 9px? I think not.
—Trappist the monk (talk) 18:29, 1 October 2016 (UTC)

Actually, I've just had an idea for improved locks, and I think this one will satisfy everyone! I have to go to work soon, but I'll upload it later this afternoon, or tonight when I'm back from work. Headbomb {talk / contribs / physics / books} 11:22, 3 October 2016 (UTC)

Lock design

Zoomed in
      (current/original)
      (alt design 1)
      (alt design 2)
      (alt design 3)
      (alt design 4)
      (alt design 5)
      (alt design 6)
      (alt design 7)
      (alt design 8)
      (alt design 9)
      (alt design 10)
      (alt design 11)
Intended size (with tooltips)
"Title"  / "Title"  / "Title"  / "Title"  (current/original)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 1)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 2)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 3)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 4)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 5)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 6)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 7)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 8)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 9)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 10)
"Title"  / "Title"  / "Title"  / "Title"  (alt design 11)

There. I think we have a winner with alt 1 (or alt 3, no strong preference here) alt 4 (or 5, which I have a slight preference for). Colours are there, each with a contrast of 4.6:1 against both black and white backgrounds. The shackles convey the openness, but if you can't make out the details of the shackle or the colour of the lock, the amount of filling in the lock's body also conveys the openness of the link. I believe everyone wins. Headbomb {talk / contribs / physics / books} 15:12, 3 October 2016 (UTC)

Pinging @Trappist the monk, Pintoch, Jonesey95, Ocaasi, Ocaasi (WMF), Izno, Pigsonthewing, David Eppstein, Matthiaspaul, Andrew Gray, Nihonjoe, Mandruss, Obsuser, Tom.Reding, Kanguole, and Martin of Sheffield: for their feedback on the three proposed design. Headbomb {talk / contribs / physics / books} 15:26, 3 October 2016 (UTC)
Off topic discussion about pings and edits
@Headbomb: This edit won't have notified anybody, least of all Andrew Gray. --Redrose64 (talk) 19:30, 3 October 2016 (UTC)
I believe pings are sent when signatures/timestamps are converted from ~~~~~ to 19:35, 3 October 2016 (UTC). If so, then they have been notified. Headbomb {talk / contribs / physics / books} 19:35, 3 October 2016 (UTC)
No. You need to make a new post, including a link to the notifyee(s) and your signature, and it all needs to be done in the same edit, see WP:Echo#Triggering events. Editing an existing post simply won't work; in this edit, all that you did was alter three characters. You might have deleted the existing timestamp and used five tildes before saving, but as far as the notifications system is concerned, it's not a new timestamp, let alone a new post. @Headbomb: I shall demonstrate with my next edit. --Redrose64 (talk) 19:57, 3 October 2016 (UTC)
This is clearly off-topic, but I was notified. This appeared in my notifications seven hours ago: "‪Headbomb‬ mentioned you on ‪Help talk:Citation Style 1‬ in "‪Lock design‬". Pinging @Trappist the monk, Pintoch, Jonesey95, Ocaasi, Ocaasi (WMF), Izno, Pigsonthewing, David Eppstein, Matthiaspaul, Andrew Grey, Nihonjoe, Man..." – Jonesey95 (talk) 22:43, 3 October 2016 (UTC)
@Jonesey95: Yes, you were notified, but by the original post, not by the amendment. --Redrose64 (talk) 22:53, 3 October 2016 (UTC)
(EC) You were in the original post, this is just about Andrew Grey's notification. Anyway, not important, so I'm collapsing this section. Headbomb {talk / contribs / physics / books} 22:57, 3 October 2016 (UTC)
Of the three, alt2 seems to have the most easily distinguished icons. Why not use those icons, but with the green/blue/ red colours? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:34, 3 October 2016 (UTC)
Alt design 1.
[e] @Headbomb: It is better than current/original if we consider colors too (if free registration required and paid subscription required are compared, and user has no color on the screen + screen is small — bigger the chance is he/she will see difference between two mentioned locks in alt design 1 because circle is fully filled in the latter and broken line in the former might appear as non-broken line).
@Pigsonthewing: I think more distinguished icons are in alt design 1a than in alt design 2; empty and full circle have more meaning than dot, half circle and full circle too. --Obsuser (talk) 15:28, 3 October 2016 (UTC)
Perhaps empty, half circle, and full would be better? I've added that row above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:50, 3 October 2016 (UTC)
Tweaked with proper color (alt 3). Headbomb {talk / contribs / physics / books} 15:59, 3 October 2016 (UTC)
Alt 3 is now not what I was proposing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 4 October 2016 (UTC)
So you wanted specifically green/blue/red as a color scheme??? Well picture me puzzled and categorically opposed to that! Headbomb {talk / contribs / physics / books} 15:17, 4 October 2016 (UTC)
alt design 1, since there are 3 changes per progression (Δshackle, Δbody, Δcolor), making it superior to the others. alt design 2's intermediate design is hard to see. My eye strains when looking at it, like it's looking for more detail in the image, even though I already know how it looks like. I can glance over the others without experiencing that effect. A 40/60-ish blue/not-blue body-fill-in-ratio might be a little better, but still not as good as alt design 1 (probably on par with/slightly better than current/original).
The changes per progression (unlocked→intermediate & intermediate→locked) for each design are:
  • current/original: 2 & 2
  • alt design 1: 3 & 3
  • alt design 2: 2 & 1
  • alt design 3: 3 & 3
On this basis I order my preference from most to least favorable as: alt design 1, alt design 3, current/original, alt design 2.   ~ Tom.Reding (talk ⋅dgaf)  16:01, 3 October 2016 (UTC)

I've added a 4th and 5th design, which I think are the best. It still has a partial yellow shackle, but it looks much much better in print. The 5th design keeps the dot in the green lock, which prevents it from looking too much like a lowercase a. Headbomb {talk / contribs / physics / books} 16:59, 3 October 2016 (UTC)

I prefer alt 1 and alt 2 as they are easiest to distinguish as they use both color and fill to indicate the differences. This is important for those who may be colorblind (I am not). ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:25, 3 October 2016 (UTC)
I prefer alt 5, but I am happy with any other design. I think it is useful to have the dot inside the green lock, so that it is easier to recognize the similarity with the orange open access lock. Thanks for these proposals! − Pintoch (talk) 22:28, 3 October 2016 (UTC)
Of course I prefer alt2. The suggestion of alt2 in green→blue→red with the same shapes is acceptable. In that vein, alt5 shapes in green→blue→red would also be acceptable. The reasons for this color preference is that the 'yellow' is not yellow but a rather bilious color that reminds me of the content of a baby's diaper.
It occurs to me to wonder if the limited and registration locks should be different. Perhaps the registration lock has its dark half on the left as an indicator that the source goes from closed to open. The limited lock then has its darkened half on the right indicating that the source goes from open to closed. If the alt5 'yellow' lock is chosen, perhaps a 180° flip around the y-axis to put the broken portion of the shackle on the right would be best if this suggestion is adopted. The single break in the 'yellow' lock's shackle is substantially better than the halftone shackle.
—Trappist the monk (talk) 10:20, 5 October 2016 (UTC)
I think that's a subtlety that would be lost on most of us, let alone the average reader. I think yellow/partial shackle conveys 'restrictions' well enough, and that's really all they should convey. I think the KISS principle applies here, and we'd be overengineering if we tried to include finer meanings in the icons. I think the only people who need the distinction are the visually impaired, and the tooltips will cover that (I believe they are read by text-to-speech software. If they aren't, then we'll make use of |alt= in [[File:Lock-green.svg|9px|alt=Freely accessible]]. Headbomb {talk / contribs / physics / books} 17:10, 5 October 2016 (UTC)
I suspect these intermediate access levels will not be used much anyway. It is good to offer them, with different values, but I agree with Headbomb that it seems hard to convey the difference between the two in a tiny icon like that. I think each lock should be in a uniform color for simplicity. − Pintoch (talk) 17:47, 5 October 2016 (UTC)
Of course it is hard to convey complex ideas with simple icons. That is a point I made some time ago and why we have tool tips and alt text. Using a single simple lock icon to communicate two distinctly different but vaguely similar meanings just complicates the matter. That is why I suggested slightly different icons for slightly different meanings. I can agree that the 180° flip around the y-axis of my earlier suggestion is insufficiently distinct. Perhaps a rotation of the lock body by 90° is better:
       
And, for those seeking meaning in the imagery, one might construe the new lock's bottom-fill as a vague representation of the sand in an hourglass.
—Trappist the monk (talk) 13:23, 8 October 2016 (UTC)
  • Interesting - I hadn't realised the discussion had progressed to suggest four options not simply open/shut. Really glad to see someone's working on this! From that perspective, alt2, alt6, and alt7 (half-circle with unbroken top section) look fine when seen as part of a set, but will probably be too confusing in practice - if you don't have a 'full lock' to compare them to, they'll look like closed padlocks and will be assumed to indicate "closed" rather than "half-closed". Which is not a bad fallback, I suppose. Likewise, the part-dashed (alt4, alt5) seem too visually close to the closed upper section - I prefer the all-dashed approach. Current, alt1, or alt3 seem best for that. Andrew Gray (talk) 19:50, 5 October 2016 (UTC)

Third lock nailed

From what I can tell above, there's a rough consensus (if not full consensus) for the fully-closed red lock above (aka "the third lock"). I think we should make that change in the sandbox regardless of the other locks. Does anyone (dis)agree? --Izno (talk) 20:42, 10 October 2016 (UTC)

Agreed that it's very likely what the final choice will be / there is consensus for it. But I don't really see the point in making the changes right now. We might need to have a community wide RFC on this, and just go with the preference of the majority. Headbomb {talk / contribs / physics / books} 21:28, 10 October 2016 (UTC)

Nailing down the first lock

I think everyone agrees the fully-open lock (aka "the first lock") should be green and open (in the latch). Let's figure out whether we want the middle of the lock to have a small circle or completely open so we can nail that lock down. --Izno (talk) 20:42, 10 October 2016 (UTC)

The first lock is kinda contingent on the second lock, and vice versa. Say we go for File:Lock-yellow-alt-4.svg (dot), then that likely means File:Lock-green-alt.svg (no dot). If we go instead with for File:Lock-yellow-alt-5.svg (half circle), then either File:Lock-green.svg (dot) or File:Lock-green-alt.svg (not dot) are viable.
Likewise, if we decide on File:Lock-green.svg (dot), then that gets rid of File:Lock-yellow-alt.svg, File:Lock-yellow-alt-4.svg, File:Lock-yellow-alt-6.svg. If if we decide on File:Lock-green.svg (no dot), then all yellow/blue locks are viable choices. Headbomb {talk / contribs / physics / books} 21:25, 10 October 2016 (UTC)


RFC?

I think we should hold an RFC on the matter of lock designs. I've drafted something at User:Headbomb/sandbox3. Comments before I shoot this at the village pump? Or maybe this should be posted here? Headbomb {talk / contribs / physics / books} 22:27, 10 October 2016 (UTC)

Nice! Any chances you could also include Trappist's last proposal (two different shapes for the two intermediate access levels)? I think it might be worth pushing the changes in the live module before holding that RFC. That might sound a bit awkward, but here are a few reasons:
  • If the change goes live now, immediately no new lock will be added to citations (because they need to be explicitly added with |id-access=). Except the existing green ones, which are already live and against which I have not witnessed any rebellion. Some people might start tagging some |url-access=subscription but it will be marginal (otherwise a bot approval request needs to be filed).
  • This lets us submit the OAbot for approval (as it only adds green locks)
  • Having a working CS1 code will help people who are not familiar with the sandbox to try out these new features, so that they can really understand what the RFC is about.
  • Holding an RFC now and waiting for it to complete will postpone the next update of the live code even more.
  • Pushing the changes to the live module enables us to publish the Signpost article and advertise the RFC there.
If the outcome of the RFC was a very controversial decision, surely the RFC should be held first, but I have the feeling here that we are all mostly fine with most solutions.
− Pintoch (talk) 06:28, 11 October 2016 (UTC)
You make good points. I agree we should roll out. Let go with the 'original/current' locks so the discussion/RFC is easier to follow, and change them after the RFC is concluded. Headbomb {talk / contribs / physics / books} 10:53, 11 October 2016 (UTC)
This rfc is about too many things. It starts out with the icon designs then shifts to how and when icons should be displayed (without stating how editors will cause icon display) and then shifts again to auto-linking. Too much choice, too much for editors to wrap their brains around. How long has it taken us, who have a strong interest, to get to this point? For editors who don't have such strong interest, so much choice may cause them to make choices that aren't fully considered or may cause them to make no choice at all; both of which are detrimental to the outcome of the rfc. If the goal is lock design, keep the rfc to just that topic: lock design. Defer aspects 2 and 3 to later rfcs if rfcs are necessary for these topics.
All lock icons in the rfc should have the tool tips and alt text.
Use the correct markup in the citation mock-ups so that editors don't see both the lock icon and the typical external link icon. Show the citations as they would actually be rendered by the templates.
One quibble I have with rfcs is that the authors choose generic section headings Vote (should be !vote), Discussion, etc which are meaningless when looking at my watchlist or a talk page history. Choose heading titles that identify the rfc to which the section headings belong.
The Choice 1, Choice 2, Choice 3 headings do not necessarily instruct editors to make three separate choices but at first blush may appear to be three offerings from which editors are to make one choice. Perhaps:
Lock design step 1) choose lock colors: Green–Yellow–Red (GYR) or Green–Blue–Red (GBR)
Lock design step 2) choose shackle style: 100% dashed or 50% dashed or 25% dashed
Lock design step 3) choose body style: Dotted–Half–Full (DHF) or Empty–Half–Full (EHF) or Empty–Dotted–Full (EDF)
Under the !vote heading, add text that tells editors what they are expected to do in the rfc: express opinion on three separate characteristics of the lock icon designs.
Do not lead the !voting. Another of my quibbles with rfcs is the tendency of rfc authors to write an rfc in such a way that !voting editors know the outcome that the author desires. Once proposed, we have thirty days or so to express our opinions; we can and should hold off until later. Neutral language throughout.
The pseudo-rfc that was held here started with a couple of options but then ballooned to nearly a dozen choices. In the real rfc, that must not happen. Once committed, except for glaring error, the rfc must not be edited in any way. We do not want to take the chance that such an edit might possibly negate an editor's !vote as happened here in the pseudo-rfc.
For interested editors, we should provide links to all of the discussions that got us here.
The original lock icons (A1 – what does A1 mean?) directly above the Dotted Green / Yellow / Red (DGYR) pseudo-heading should be removed so that editors don't think that that color/shackle/body combination is one that we want them to include in their !vote considerations.
—Trappist the monk (talk) 10:54, 12 October 2016 (UTC)
Good feedback Trappist the monk (talk · contribs). Glad I held off posting to the village pump until you chipped in. Take a look at it now, see if I overlooked anything. I'm fine will withholding my !vote so it doesn't lead the sections, it's just there for now because I'm still forming an opinion on some of those matters, and writing it down helps to crystallize my thoughts. Headbomb {talk / contribs / physics / books} 12:03, 12 October 2016 (UTC)
Not happy with the new section headings. Granted that 'Aspect A1) Color: Green–Yellow–Red (GYR) vs Green–Blue–Red (GBR)' etc is atypical but it is not instructive whereas 'Lock design step 1) choose lock colors: Green–Yellow–Red (GYR) or Green–Blue–Red' tells the reader that this heading is part of the lock design rfc, that this heading is the first step in a multi-step process, that under this heading the reader is to make a choice between these two things. 'First RFC' does not identify this rfc in a watchlist as the lock design rfc. Every heading in the rfc should in some way include a brief mention of the rfc subject: 'RFC lock design' → 'RFC lock design: !vote' → 'RFC lock design: discussion' so that editors looking at their watchlists immediately know that the lock design rfc was recently edited without the need to follow the link into the rfc to figure out which one (of possibly multiple rfcs) this one is.
For the color choice, I wonder if simple display of color against the two background colors without the influence of the lock shapes would be better:
                                                         
                                                         
Here the choice is blue or yellow. Is it necessary to show the other two colors?
                         
                         
Because the shackle shape choice only applies to the limited locks, is there a need to show the other two? Perhaps this step in the process selects the whole limited access lock from the six possible shapes.
  1.   |  
  2.   |  
  3.   |  
  4.   |  
  5.   |  
  6.   |  
Similarly, the last choice is the free lock body shape so the choice reduces to choosing one of these two:
  1.  
  2.  
There is still no text under the !vote heading that tells the reader what is expected of them for this rfc.
The second instance of the original lock icons must be removed so that readers are not confused into thinking that the originals are an option (unless they are, in which case, that choice must be explicitly stated). Is it necessary to include the original locks at all?
May I copy edit the rfc?
—Trappist the monk (talk) 11:44, 13 October 2016 (UTC)
I've cut down and simplified a few options per the above. Feel free to copy-edit the RFC. However, we should really roll out the updated citation template code, so hopefully that can be done over the weekend / sooner. Headbomb {talk / contribs / physics / books} 15:10, 13 October 2016 (UTC)
a.   /   /  
b.   /   /  
c.   /   /  
d.   /   /  
e.   /   /  
f.   /   /  
g.   /   /  
h.   /   /  
i.   /   /  
j.   /   /  
k.   /   /  
l.   /   /  
m.   /   /  
n.   /   /  
o.   /   /  
p.   /   /  
q.   /   /  
r.   /   /  
Meh.
I chose blobs of color within areas of the black and white backgrounds because the overall white of the rest of the screen effects how the locks appear within a small black background surrounded by white. Also because the first aspect choice is color, there is no need to complicate the decision process by including any locks. Reduce the information presented to only that which is necessary for editors to make a decision.
In an attempt to minimize any perception of my preferences in these choices, in my suggested changes I alternated color for the shape choices; that isn't possible for the green lock.
Because the individual choices are more limited now, the columnar locks with their cryptic initialisms can probably be replaced with the illustration at right. In that table, there is a single change row-to-row which I think includes all of the possible choices.
—Trappist the monk (talk) 11:30, 14 October 2016 (UTC)

Wait for url generation?

Now that I think of it, it might be best to wait for #Automatic_url_generation before deploying. Headbomb {talk / contribs / physics / books} 12:39, 30 September 2016 (UTC)

I remain opposed to automatic urls for the reasons that I stated there.
—Trappist the monk (talk) 11:05, 1 October 2016 (UTC)
Which means we would treat free full version identifiers inconsistently, and will add lots of useless clutter in print versions. Automatic main-linking is a good thing, and would be so immensely useful in the case of free bibcodes. Headbomb {talk / contribs / physics / books} 13:23, 1 October 2016 (UTC)
As I've said before, I think that auto-linking PMC is wrong. Compounding that wrong by auto-linking all the other free-to-read identifiers does not, in my mind, solve the problem. For consistency, we should disallow auto-linking of PMC especially if we can get around the lock icon issues that remain.
You used the printed clutter argument before. I did not understand it then and do not understand it now. When I print a page of citations, there is no clutter of the kind that you suggest must already be present. What are you doing that shows clutter problems?
—Trappist the monk (talk) 18:29, 1 October 2016 (UTC)
Copy {{cite journal |last1=Bar |first1=Krzysztof |last2=Vicary |first2=Jamie |title=A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem |url=https://dx.doi.org/10.4204/EPTCS.172.23 |journal=Electronic Proceedings in Theoretical Computer Science |date=28 December 2014 |volume=172 |pages=316–332 |doi=10.4204/EPTCS.172.23}} in your sandbox and select "printable version" from the print/export toolbar. You'll see the issue. Headbomb {talk / contribs / physics / books} 13:55, 11 October 2016 (UTC)
Strange, it doesn't do that anymore. That is very, very weird. How is someone to know what link is meant? I'll make a thread on the village pump to restore that behaviour / update it. Headbomb {talk / contribs / physics / books} 13:59, 11 October 2016 (UTC)
I agree that this is a feature worth being debated (and the |pmc= case shows that editors value it), but it is an important proposal which might have unexpected side effects. The last update of the live module dates back to a few months ago, so if we want to include the change you propose, it will probably take a long time and block other changes awaiting the live module update. I think it would be simpler to clear the backlog of pending updates and discuss that afterwards. − Pintoch (talk) 14:26, 1 October 2016 (UTC)
We can deploy now I suppose, but it would have been nice to include this in the Signpost piece I'm writing which details everything. I don't think it would take much more than a week to develop and tweak automatic url generation though. Headbomb {talk / contribs / physics / books} 14:45, 1 October 2016 (UTC)
(←) I agree with Pintoch dated 1 October. Your draft can still make reference to the proposal, if desired. --Izno (talk) 20:15, 10 October 2016 (UTC)

Tooltips

Tooltip definitions: "free registration" and "paid subscription" may be oxymorons. A "paid registration" is a subscription; a "free subscription" is a registration. I would do away with the "free" and "paid" modifiers. 72.43.99.146 (talk) 14:32, 30 September 2016 (UTC)

Sorry I mean the link text for the icons, which appears as a tooltip. 72.43.99.146 (talk) 15:16, 30 September 2016 (UTC)
An oxymoron requires contradictory terms e.g. Dark light. "Free registration" and "Paid subscription" are at best somewhat redundant, but this is the good kind of redundancy because it makes it clear that free/paid is the difference between registration vs subscription. Because technically, you can have free subscriptions (e.g. I'm subscribed to several mailing lists, and I didn't pay anything for that), and paid registration (e.g. when I sign up at a conference, I register).
Subscription and registration. 184.75.21.30 (talk) 21:58, 30 September 2016 (UTC)
Google search: "Free subscription", "Paid registration". Headbomb {talk / contribs / physics / books} 13:26, 1 October 2016 (UTC)
Marketing terms (confirmed by the majority of search results), that have no place in an encyclopedia. 72.43.99.138 (talk) 14:33, 1 October 2016 (UTC)
Hardly. I've got dozens of mailing list subscriptions, and those aren't mailing list registrations. Likewise, I've paid to be registered for several things, and those aren't subscriptions. See in particular definition 1.b here "An agreement to receive or be given access to electronic texts or services, especially over the Internet", with no reference to whether money was exchanged. Headbomb {talk / contribs / physics / books} 14:42, 1 October 2016 (UTC)
I think terms should be used according to the accepted definition from reliable sources (the free dictionary? we might as well be bringing up Wikipedia as a source), not as people abuse them or because promoters (publishers, conference organizers, universities, the WMF etc.) want people to buy their product. A subscription is a payment in advance. There is no such thing as a free subscription; that is something else. Are you a healthy sick person? Registrations do not involve payments (though they are not free, they are exchanges: you provide information, they provide the product). A paid registration is not a registration, it is a purchase. But don't let me upset the newspeak, obfuscation, and resulting incomprehensible documentation around here; do carry on. 72.43.99.138 (talk) 13:55, 2 October 2016 (UTC)

Deploy

Let's deploy this thing. It's been two months and a half since the last update. The code is stable and tested. Nothing will budge till the #RFC? discussed above is concluded, and that RFC can't start till the new code is rolled out. Headbomb {talk / contribs / physics / books} 11:41, 14 October 2016 (UTC)

@Trappist the monk: I agree, what do you think about that? − Pintoch (talk) 11:40, 16 October 2016 (UTC)
Are you really ready? In the past, for changes that I have made to cs1|2, I have created the initial documentation, I have created categories, I have created help text, etc. If all of those things are done, then the next step is to make the one-week-ahead-of-deployment announcement.
Real life for me is busier than normal so I haven't the time to do all of these things for you.
—Trappist the monk (talk) 12:24, 16 October 2016 (UTC)
Well, the doc and categories can be taken care of pretty quickly, I can do those tonight or tomorrow. Not really sure what exactly is help text, but I can't see any of that taking more than a day or two to take care of. Headbomb {talk / contribs / physics / books} 12:30, 16 October 2016 (UTC)
I have created Category:CS1_errors:_⟨id⟩-access_without_id, added error messages to Help:CS1 errors and started some documentation at Help:Citation Style 1. Improvements welcome! − Pintoch (talk) 17:00, 16 October 2016 (UTC)
I have also created Category:CS1_errors:_citeseerx and the relevant section of Help:CS1 errors. − Pintoch (talk) 18:41, 16 October 2016 (UTC)
I chose Category:CS1 error: param-access as a category name because it is not specific to identifiers alone. Identifiers, and 'id', have a specific meaning within cs1|2 so the use of 'id' in the name of the new category implies that the category holds only pages with identifier access level errors. |url-access= applies to |url=, which most definitely is not an identifier, should therefore not be made part of this newly named category but should, instead, have its own, something I was attempting to avoid by the use of the generic 'param-access' name I chose. Why did you undo that work?
—Trappist the monk (talk) 19:21, 16 October 2016 (UTC)
Oops, sorry about that, for some reason I misread the thread and thought Headbomb's proposal was the latest one. No idea why, really. (I even agreed with your change earlier…). Let me fix that. − Pintoch (talk) 20:00, 16 October 2016 (UTC)
At Help:Citation Style 1#Deprecated parameters you wrote that |subscription= and |registration= are deprecated. Where did that decision get made? Did we ever make such a decision?
—Trappist the monk (talk) 21:52, 16 October 2016 (UTC)
This removed ['DoiAccess'] = {'doi-access'}. Not really sure what it does, but should we also remove ['UrlAccess'] = {'url-access'}?
As for a specific decision on deprecating |subscription= / |registration=, it as never explicitly !vote on, but the issues with those parameters were mentioned several times, as was deprecation was mentioned several times and I don't recall anyone raising an objection. Headbomb {talk / contribs / physics / books} 23:22, 16 October 2016 (UTC)
I object (though not strenuously) to the deprecation of |subscription= / |registration= without further discussion. Apologies if I missed something, but I did not see that explicit proposal. I have tuned out of the (to my mind) esoterica of the -access parameters and the padlocks, but these two parameters are used quite widely, I believe. – Jonesey95 (talk) 03:59, 17 October 2016 (UTC)
An insource search for |subscription=yes and for |registration=yes finds 9800-ish and 1300-ish uses of these parameters.
—Trappist the monk (talk) 10:03, 17 October 2016 (UTC)

About 'DoiAccess': no we should not remove 'UrlAccess', it is still used in the code. 'DoiAccess' was not. It was a leftover from the first implementation that only covered |doi-access=.

@Headbomb: I see you have added an error message category and help text for |biorxiv=. But as far as I can tell this error message is never raised by the code: no validation is done on the biorxiv id (just like for a bunch of other ids). So either we add some validation, or we should remove this category and help text, I think.

About the proposed deprecation: Trappist, you agreed we had to deprecate these if the new |param-access= system was rolled out. The relevant discussion is here. Anyway I did not deprecate them in the code: they will still work as expected. Feel free to restore the original documentation if you feel that we did not discuss that enough… − Pintoch (talk) 05:06, 17 October 2016 (UTC)

By the way, in the section just below this one, Headbomb called for the said deprecation as a wrap-up of what had been agreed in the previous discussion (linked above). No concern was raised and this was almost a month ago already. I agree the debate is sometimes hard to follow but I am not sure that turning it into a lengthy formal discussion and vote would help… − Pintoch (talk) 05:26, 17 October 2016 (UTC)
(edit conflict) Agreeing that they should be deprecated is not the same as saying we had to deprecate them. Please don't put words into my mouth that I have not spoken. Those two parameters do not have to be deprecated. I just wanted to make sure that there is a firm decision to deprecate. If there is, then the whitelist settings for those two parameters should be set to false so that they are actually treated by the module as deprecated.
—Trappist the monk (talk) 10:03, 17 October 2016 (UTC)
Yes, we should add validation for |biorxiv=. I personally feel deprecation has been discussed enough. There's just too many issues with |registration=/|subscription=, and it makes no sense for have both |registration=yes/|subscription=yes and |url-access=registration/|url-access=subscription.
The real question is how do we deprecate? Do we consider |registration=yes as an alias of |access=registration for this update? This way if we misread the community / didn't think of some aspect, we can un-deprecate without great pains and we don't have to deal with thousands of error messages. And if we get no reasonable objections, we can send bots to convert |registration=yes to |url-access=registration and cleanup articles before the next code update, when we'll throw a proper error message. I'm not really worried about misreading the community/not having thought of something, but I'm partial to that option just so that bots have a chance to cleanup things before we throw error messages.
Or is it too complicated/dirty code to make |registration=yes an alias of |url-access=registration, and we should just go all in and throw the error message now. Headbomb {talk / contribs / physics / books} 09:44, 17 October 2016 (UTC)
Ok, I think there was a misunderstanding. By writing in the documentation that these parameters are deprecated I did not intend to change anything in the code to reject these parameters. I am totally against adding lots of error messages for all occurrences of |subscription= and |registration= in the coming update. So it seems that I should rather have written that the new system is preferred over the old one. Once the new system is deployed, we can let a few months to see how the community reacts, and then think about running a bot to transform the unambiguous uses of the old parameters to the new ones. (I don't think it is a good idea to do an alias, because of the possible ambiguous cases.) I just think it makes sense to point editors to the new system for the edits they do after the roll-out. But I am also happy with not stating any preference in the doc, really. − Pintoch (talk) 10:16, 17 October 2016 (UTC)
As far as I can tell, all known bugs in the sandbox have been resolved, docs and help messages have been written and categories have been created. Are we ready to deploy? − Pintoch (talk) 16:20, 18 October 2016 (UTC)
Template documentation for the |*-access= parameters? Where is that? I suppose, if you are feeling adventurous and have nothing better to do with your time, you might make appropriate additions to the abomination that is TemplateData. Or not. I don't care if that latter task is ever accomplished, but, these new parameters must be documented in the normal template documentation; even if, as a certain IP editor takes pains to remind us, that documentation is inadequate and sucks.
—Trappist the monk (talk) 19:55, 18 October 2016 (UTC)
Help:Citation_Style_1#Access_level_of_identifiers? Headbomb {talk / contribs / physics / books} 19:59, 18 October 2016 (UTC)
I just realized each CS1-based template could have its own specialized doc, such as Template:Cite_journal/doc… They should be updated as well, I guess. − Pintoch (talk) 20:19, 18 October 2016 (UTC)
Template documentation and TemplateData updated. I suggest we announce the deployment so that the documentation and the actual code do not stay out of sync too long. The docs can still be improved but this can be done during the week before deployment. − Pintoch (talk) 08:35, 20 October 2016 (UTC)
Ok. Announcement this weekend.
—Trappist the monk (talk) 09:34, 20 October 2016 (UTC)
Why are we now no longer depracating |registration= and |subscription=? Let's get rid of them, both for simplicity's sake and so we don't have to deal with error messages for the inevitable case of having both |registration=yes and |url-access=registration, or |registration=yes |url-access=subscription. They can be put as aliases of |url-access=registration/|url-access=subscription for now if we want a transition period, but they need to go. Headbomb {talk / contribs / physics / books} 17:17, 18 October 2016 (UTC)
Well, surely the case of conflicts between the old and the new systems can be avoided: it is up to the editors or bots who introduce them! If we deploy the sandbox as it is now, no new error should be added. Again it is not acceptable to create an alias. Here is an example taken from Brownian motion:
If we put an alias, here is what will happen (I just replace |subscription=yes by |url-access=subscription):
I don't have the exact figures but I can produce at least a few hundreds of examples like that. There are other cases where the alias would not raise any error, but would display false information. This example is taken from Clathrina:
So, I think the migration to the new system should be done with a bot. This implies not disrupting the existing parameters in the coming update. (By the way, these examples seen in the wild make our case for the ambiguity of the existing parameters pretty nicely, I think.) − Pintoch (talk) 17:59, 18 October 2016 (UTC)
Hmm, the first example can really only be taken care of after the RFC to see if we want to allow |doi-access=subscription. I guess we can wait after that to deprecate. Headbomb {talk / contribs / physics / books} 18:03, 18 October 2016 (UTC)

Following the discussions regarding this is effectively impossible, so even as a pretty technical editor and enthusiastic user of these templates, I have no idea what you're now actually proposing to do. Before you "deprecate" anything here I would strongly urge that you post a comprehensive but succinct summary of the planned changes. Because I get really concerned when, absent context, I see suggestions that a new |url-access= param can replace |subscription= (even for cites, like the majority of those I use these templates for, that have a DOI or JSTOR number but no URL). Some practical way for more, and more diverse, eyeballs to check your assumptions before deploying would be a very good idea (unless you enjoy the angry villagers forming up at your door with torches and pitchforks). --Xover (talk) 18:20, 18 October 2016 (UTC)

Basically, deprecation would mean throwing away |registration=/|subscription= in favour of the new system |url-access=registration/|url-access=subscription. However, as mentioned above, we can't really throw them away now, because sometimes |registration=/|subscription= are used to refer to whether identifiers require registration/subscription, and we don't currently support |doi-access=registration/|doi-access=subscription. Whether we should (and I think we should), will be addressed by an upcoming RFC (see RFC draft) on what the final behaviour of the template should be with respect to access locks. Headbomb {talk / contribs / physics / books} 18:28, 18 October 2016 (UTC)
Thanks. That does alleviate my concerns, particularly that you're planning to run an RFC on it. In any case, the main thrust of my "intervention" was to not rely solely on the discussions here, because they're impossible to follow and risk falling prey to the "echo chamber" effect. In various other places I've occasionally had to remind people of this, but it seems in this case it was not needed. Carry on... :) --Xover (talk) 03:57, 19 October 2016 (UTC)
Not quite true. Deprecation does not mean throwing away |registration=/|subscription= in favour of the new system. It means that for a time, could be months, could be years (as has been the case of |coauthor(s)=), the deprecated parameters exist in parallel with the new system. The old parameters are gradually replaced by the new until the count of old parameters drops to an insignificant number. When that happens, then and only then, are the old parameters 'thrown away'.
To deprecate, we simply set ['registration'] = false and ['subscription'] = false in Module:Citation/CS1/Whitelist and wait. As pages are edited or they work their way through the job queue, cs1|2 templates with those parameters will be marked with an error message and the pages will be added to Category:Pages containing cite templates with deprecated parameters. Editors may 'fix' the errors, bots can 'fix' the errors, AWB scripts can 'fix' the errors.
—Trappist the monk (talk) 10:56, 19 October 2016 (UTC)

Documentation of {{cite AV media}} should not refer to "text of the publication"

Latest comment: 8 years ago4 comments3 people in discussion

In {{Cite AV media/doc}}, the documentation of the URL parameter refers repeatedly and inappropriately to "the online location where the text of the publication can be found". AxelBoldt (talk) 02:38, 20 October 2016 (UTC)

@AxelBoldt: Are you suggesting that AV media probably isn't in text form? :D WP:BOLD applies. --Izno (talk) 11:18, 20 October 2016 (UTC)
I've updated the centralized documentation of the URL parameter at Template:Citation_Style_documentation/url to add a 'media' option that causes the doc to use 'media' in place of 'text of publication'.and then added the option to the URL section at Template:Cite AV media/doc. —RP88 (talk) 12:22, 20 October 2016 (UTC)
Perfect, thank you! AxelBoldt (talk) 17:48, 20 October 2016 (UTC)

|title= and |work= are not synonyms in Template:Cite book

Latest comment: 8 years ago11 comments5 people in discussion

{{cite book |last=Thompson |first=Richard |date=2008 |work=Willamette Valley Railways |pages=29, 32, 59 and 77 |publisher=[[Arcadia Publishing]] |isbn=978-0-7385-5601-7}}

produces:

Thompson, Richard (2008). Arcadia Publishing. pp. 29, 32, 59 and 77. ISBN 978-0-7385-5601-7. {{cite book}}: |work= ignored (help); Missing or empty |title= (help)

I'm a little surprised by this. --Izno (talk) 12:22, 19 October 2016 (UTC)

Why? I don't see why you would expect |work= and |title= to be aliases. Peter coxhead (talk) 13:29, 19 October 2016 (UTC)
I wonder if these design flaws should have their own section in the "documentation" so that people don't keep asking the same questions about them. I vaguely remember discussions about this stretching back years. This particular one (about the ambiguous function/definition of |title=) keeps coming back, perhaps because it is a flaw that can be easily seen by editors. 65.88.88.126 (talk) 13:51, 19 October 2016 (UTC)
I've just been musing on the ambiguity problem this morning as I reported this, but I didn't want to make this particular un-expectation about the larger issue. --Izno (talk) 14:06, 19 October 2016 (UTC)
@Peter coxhead: Is a book not a work? Is the title of the book not reflect of the title of the work? |work= is aliased in several other locations (|website=, and I believe |journal= and |encyclopedia=) that would indicate that these should be aliases. --Izno (talk) 14:06, 19 October 2016 (UTC)
Precisely. |work= is aliased to entities that need titles as well, so if it were aliased to |title= it would be confusing. Some cases would need |title= and |work=, in other cases they would be duplicates. Peter coxhead (talk) 15:25, 19 October 2016 (UTC)
@Peter coxhead: Then |title= is also inconsistent--sometimes being used for minor work items (a chapter, section, or a webpage) and sometimes major work items (a book). --Izno (talk) 11:19, 20 October 2016 (UTC)
|title= is not used for a chapter or a section. The only real "level" inconsistency I can see is that, by tradition, "title" is used for a journal article, which is in some ways like a chapter of a volume of a book (since it's a contribution to a volume of a journal). Webpages are a different matter altogether: citation styles were created before the web, and web cites have had to be shoehorned into existing protocols. It probably would have been better to use different parameters for purely web-based sites (as opposed to otherwise published material hosted on the web), but we are where we are. Peter coxhead (talk) 12:36, 20 October 2016 (UTC)
The specific concern is about the use of parameters in CS1 templates, not how their labels are used in general. The ambiguity in the use of |title= stems from a design flaw that allows a parameter ("title") to mean two different things, depending on the {{cite xxx}} used: e.g. in {{cite journal}} it refers to a fragment in a source; in {{cite book}} it refers to the source in toto. However, the source is actually represented by |work= in the so-called design of CS1 templates; so this cascades into another dependency that seems out of joint: why are some labels for "work" (e.g. "journal") aliases of "work", and some (e.g. "title" in {{cite book}}) aren't? This brings up even more inconsistencies, but enough of that. As noted, this argument is perennial. 72.43.99.146 (talk) 13:18, 20 October 2016 (UTC)
I don't regard it as a "design" flaw; it reflects pre-existing usage in citation terminology, which is historical rather than entirely logical. Peter coxhead (talk) 22:31, 21 October 2016 (UTC)
This "historical" use, which is irrelevant in a newer system targeted to non-experts, is what led to a flaw in design, where system-wide parameters assume different functionality. It's obvious in the code. More so in application, where it results in confusion. 24.193.13.108 (talk) 01:06, 22 October 2016 (UTC)
Retrieved from "https://en.wiki.x.io/w/index.php?title=Help_talk:Citation_Style_1/Archive_27&oldid=1166670907"