This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 20 | ← | Archive 25 | Archive 26 | Archive 27 | Archive 28 | Archive 29 | Archive 30 |
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)
{{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Check |biorxiv=
value (
help); Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help)
|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)
|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)
|id-access=free
([
the documentation was updated to reflect that.) I have therefore [https://en.wikipedia.org/?title=Module:Citation/CS1/Configuration/sandbox&diff=744752636&oldid=744680128 updated the code to reflect that. −
Pintoch (
talk) 06:24, 17 October 2016 (UTC)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)
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.
lock | color | background white | background black |
---|---|---|---|
#008400 | |||
#007a00 | |||
#7a7a00 | |||
#7a0000 | |||
#0077cc | |||
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)
lock | color | background white | background black |
---|---|---|---|
#0077cc | |||
#008400 | |||
#008900 | |||
#7a7a00 | |||
#ec0000 |
Done. Headbomb { talk / contribs / physics / books} 10:40, 29 September 2016 (UTC)
{{
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)
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)
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)
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)
|alt=
in [[File:Lock-green.svg|9px|alt=Freely accessible]].
Headbomb {
talk /
contribs /
physics /
books} 17:10, 5 October 2016 (UTC)
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)
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)
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)
|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).a. | / / |
b. | / / |
c. | / / |
d. | / / |
e. | / / |
f. | / / |
g. | / / |
h. | / / |
i. | / / |
j. | / / |
k. | / / |
l. | / / |
m. | / / |
n. | / / |
o. | / / |
p. | / / |
q. | / / |
r. | / / |
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)
|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)
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)
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)
|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?|subscription=
and |registration=
are deprecated. Where did that decision get made? Did we ever make such a decision?|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)
|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)
|subscription=yes
and for
|registration=yes
finds 9800-ish and 1300-ish uses of these parameters.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)
should be deprecatedis not the same as saying
we had to deprecatethem. 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.|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
.|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.|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)|*-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.|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){{
cite journal}}
: Unknown parameter |subscription=
ignored (|url-access=
suggested) (
help)|subscription=yes
by |url-access=subscription
):
{{
cite journal}}
: |url-access=
requires |url=
(
help){{
cite journal}}
: Unknown parameter |subscription=
ignored (|url-access=
suggested) (
help) 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)
|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)
mean throwing away. It means that for a time, could be months, could be years (as has been the case of|registration=
/|subscription=
in favour of the new system
|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'.['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.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)
|title=
and |work=
are not synonyms in
Template:Cite book{{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)
|work=
and |title=
to be aliases.
Peter coxhead (
talk) 13:29, 19 October 2016 (UTC)
|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)
|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)
|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)
|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)
|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)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 20 | ← | Archive 25 | Archive 26 | Archive 27 | Archive 28 | Archive 29 | Archive 30 |
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)
{{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Check |biorxiv=
value (
help); Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help){{
cite journal}}
: Cite journal requires |journal=
(
help)
|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)
|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)
|id-access=free
([
the documentation was updated to reflect that.) I have therefore [https://en.wikipedia.org/?title=Module:Citation/CS1/Configuration/sandbox&diff=744752636&oldid=744680128 updated the code to reflect that. −
Pintoch (
talk) 06:24, 17 October 2016 (UTC)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)
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.
lock | color | background white | background black |
---|---|---|---|
#008400 | |||
#007a00 | |||
#7a7a00 | |||
#7a0000 | |||
#0077cc | |||
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)
lock | color | background white | background black |
---|---|---|---|
#0077cc | |||
#008400 | |||
#008900 | |||
#7a7a00 | |||
#ec0000 |
Done. Headbomb { talk / contribs / physics / books} 10:40, 29 September 2016 (UTC)
{{
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)
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)
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)
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)
|alt=
in [[File:Lock-green.svg|9px|alt=Freely accessible]].
Headbomb {
talk /
contribs /
physics /
books} 17:10, 5 October 2016 (UTC)
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)
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)
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)
|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).a. | / / |
b. | / / |
c. | / / |
d. | / / |
e. | / / |
f. | / / |
g. | / / |
h. | / / |
i. | / / |
j. | / / |
k. | / / |
l. | / / |
m. | / / |
n. | / / |
o. | / / |
p. | / / |
q. | / / |
r. | / / |
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)
|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)
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)
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)
|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?|subscription=
and |registration=
are deprecated. Where did that decision get made? Did we ever make such a decision?|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)
|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)
|subscription=yes
and for
|registration=yes
finds 9800-ish and 1300-ish uses of these parameters.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)
should be deprecatedis not the same as saying
we had to deprecatethem. 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.|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
.|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.|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)|*-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.|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){{
cite journal}}
: Unknown parameter |subscription=
ignored (|url-access=
suggested) (
help)|subscription=yes
by |url-access=subscription
):
{{
cite journal}}
: |url-access=
requires |url=
(
help){{
cite journal}}
: Unknown parameter |subscription=
ignored (|url-access=
suggested) (
help) 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)
|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)
mean throwing away. It means that for a time, could be months, could be years (as has been the case of|registration=
/|subscription=
in favour of the new system
|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'.['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.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)
|title=
and |work=
are not synonyms in
Template:Cite book{{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)
|work=
and |title=
to be aliases.
Peter coxhead (
talk) 13:29, 19 October 2016 (UTC)
|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)
|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)
|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)
|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)
|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)