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 15 | ← | Archive 20 | Archive 21 | Archive 22 | Archive 23 | Archive 24 | Archive 25 |
During WikiCite 2016 we plan to work on a bot that would add links to open access copies in citation links. See the relevant proposal and the current demo. Your input about how the bot should behave would be much appreciated. Let's use the project's talk page for this discussion.
In particular, we need to think about how to highlight open access versions, following the earlier discussion on this talk page. -- Pintoch ( talk) 09:40, 20 May 2016 (UTC)
|id={{citeseerx|...}}
, perhaps it would be better for us to add |citeseerx=
as a regular identifier. That would allow simple error checking and inclusion in the ctiation's metadata.|citeseerx=
as a parameter! But in fact, we will add identifiers from many other platforms, so I'm not sure where we should draw the line between identifiers and OA links (should we add a parameter for ResearchGate, for instance?) −
Pintoch (
talk) 11:27, 25 May 2016 (UTC)|10.1234/0123456789=
+ |doi-free=yes
or using |doi-free=10.1234/0123456789
, to be used only when the source is fully available, with no conditions on access. This would then display both the icon next to the ID and link the title. Something like
And that would apply for all identifiers, with the understanding that identifiers that are guaranteed to be free (e.g. arxiv, pmc, etc.) automatically get the icon. Headbomb { talk / contribs / physics / books} 16:57, 2 June 2016 (UTC)
Just a little side-idea: Given that in most cases the "open lock" symbol would follow the "external link arrow" symbol, wouldn't it be possible to combine them into one symbol? Either overlay the arrow symbol with a small lock in one of the corners, or just display a green (instead of a blue) external link symbol (and a red external link symbol for closed sources)? -- Matthiaspaul ( talk) 21:33, 8 June 2016 (UTC)
I'm pretty happy with the proposals here. Adding\marking links to openly accessible material is potentially quite valuable for the reader. It looks like the intention here is to signal "generally free to read" rather than (the previously suggested) "fully openly licensed content" - is this correct? If so, I'm definitely on board. If it's to be restricted to only CC-BY-type material, I'm not so sure it's useful; this is a bit of a subtle nuance that's not helpful for most readers. Andrew Gray ( talk) 21:57, 20 June 2016 (UTC)
There is a fly in the icon ointment. The way that MediaWiki implements the PDF icon has accessibility issues for the visually impaired. Because the icon is not an image in the html sense of an image, there is no
alt attribute that a screen reader can read to the human. This is why cs1|2 has |format=
and why cs1|2 automatically adds |format=PDF
when the value assigned to |url=
would cause MediaWiki to use the pdf icon. Using css to replace the normal external link icon would then require cs1|2 to add some sort of text to explain the open access nature of the preceding link.
It may still be possible to disable the normal external link icon and use an html image of the lock in its place, but to avoid adding additional text to each citation, this must be accomplished by a mixture of css to hide the external link icon and html to provide an image with the proper alt text.
— Trappist the monk ( talk) 12:05, 22 June 2016 (UTC)
<span class="plainlinks">[http://dx.doi.org/10.1234/0123456789 Article of things]</span>
<span style="margin-left:.1em">[[File:Open_Access_logo_PLoS_white_green.svg|9px|link=|open access publication - free to read]]</span>
{{cite journal |last=Smith |first=J. |year=2016 |title=Article of things |journal=Journal of Things |volume=66 |issue=3 |pages=11–15 |doi-free=10.1234/0123456789}}
|pmc=
and |arxiv=
first? They are low-hanging fruits as they do not require any change in the way templates are instantiated. I am happy to help implement this. −
Pintoch (
talk) 16:37, 29 June 2016 (UTC)I'm not quite sure why we need this. We already have indicators that can be added to indicate subscription required, like for newspaper sources. In my view, any source not free should be tagged with that, instead of tagging the free ones. Basically, online sources are free to read unless noted otherwise. Oiyarbepsy ( talk) 13:17, 22 June 2016 (UTC)
|subscription=
and |registration=
apply only to a citation as a whole, so we cannot use it to tell readers which links in a citation are paywalled. Second, we intend to use these parameters on scholarly references, where most sources are unfortunately paywalled (or just bare bibliographic references themselves). Third, I think that as a reader, it is more natural to get used to look for the green icon rather than to avoid links requiring subscriptions (you might actually have access to them in some contexts). Fourth, the bot we have written is never sure that a source is paywalled, but it can be sure that a source is free to read (that's easier to detect). −
Pintoch (
talk) 17:00, 22 June 2016 (UTC)Because the 'official' open access lock is orange, but the examples in this discussion use a green lock, I've started a conversation at Template talk:Open access#why is the lock orange?.
— Trappist the monk ( talk) 13:36, 23 June 2016 (UTC)
|alt=open access publication - free to read
. I see that alt text when I hover my mouse cursor over the lock: . Does that not work for you?{{
cite journal}}
, I believe), no. ···
日本穣 ·
投稿 ·
Talk to Nihonjoe ·
Join WP Japan! 00:30, 24 June 2016 (UTC)
Because of
this comment, I have modified the external_link_id()
, and arxiv()
functions in
Module:Citation/CS1/Identifiers/sandbox to replace the standard external link icon with a green lock:
The lock here is one that I modified from File:Open_Access_logo_PLoS_white_green.svg ( ). The primary differences are that the modified lock has a transparent background (the original's is white) and that the shackle is slightly more open:
For the time being, I have elected to leave the pmc identifier as it is. The pmc identifier is unique among the identifiers that cs1|2 supports because it causes the module to link |title=
with a redundant link that is the same as the identifier's link. I would prefer that all identifiers act the same way so would prefer to add the free to read lock to the pmc identifier and remove the special-case code that links |title=
with the identifier's url. I did remove that special-case code once, but that made some members of
WP:MED
rather angry.
— Trappist the monk ( talk) 13:40, 30 June 2016 (UTC)
if {{{url-free|}}} |url={{{url-free|}}} |url-icon=free else if {{{id-free|}}} |url=https://www.foobar.com/{{{id-free|}}} |url-icon=free else |url={{{url|}}} if {{{access|}}} |url-icon={{{access|}}} end if end if end if
with |access=
being either 'free' (green open lock) or 'non-free' (red closed lock). It could possibly be extended to have |access=registration
and |access=subscription
, producing yellow/red closed locks or something like that. There will be a need to develop a hierarchy of identifiers to see which should be favoured in case many are free, and allow this to be overridden through something like |url-free=pmc
} or |url-free=doi
.
Headbomb {
talk /
contribs /
physics /
books} 14:21, 30 June 2016 (UTC)
I like conciseness. I suppose it depends on the question: Just how important is it for the reader to understand the situation before they click through? It could take decades before a majority of readers who look at sources (1) have noticed those little locks and (2) have learned what they mean. We have little PDF icons, but the PDF logo is fairly widely recognized already (I think).
— User:Mandruss 16:27, 22 June 2016 (UTC)
|subscription=yes
text. Something like this:
upper curved partis the ' shackle'. The goal here is to have a lock that looks more or less like the orange (what were they thinking when they chose that color?) lock apparently associated with Open Access: . My green lock is derived from that design. At 9px width, small detail like the notch you describe will be lost. Even the much more open shackle of the green lock is relatively unnoticeable. Here are the two locks at 18px width:
I am deeply impressed by and appreciative of the detailed work above to improve the implementation. I think before this goes live, it would be wise to draw attention to the conversation from at least Village Pump and WikiProject Open Access. In order to make that consultation useful, we need a concise explanation of the what/when/where/why/how and a few examples of the change as it will appear. Ocaasi t | c 20:47, 30 June 2016 (UTC)
The top of the icon appears to be 1 pixel higher than the surrounding text (which is fine by me, since I only noticed it when zooming in a lot).
What's bugging me is that the lock extends 5 pixels below the numeric characters to the left of the above examples after "0707.0835", and 1 pixel below the to the right. It would be nice to have it aligned and/or as standardized height (which isn't that straightforward b/c people can use different fonts etc., but perhaps mimicking the default font's height limits is a good place to start). ~
Tom.Reding (
talk ⋅
dgaf) 16:41, 2 July 2016 (UTC)
Actually, this is more a description of a height issue than a valignment issue, since the lock is valigned (centered) with the , but not with the
0835
. ~
Tom.Reding (
talk ⋅
dgaf) 16:45, 2 July 2016 (UTC)
Two syntaxes have been suggested to specify that a DOI (for instance) is free to read:
|doi=10.3842/sigma.2014.079
by |doi-free=10.3842/sigma.2014.079
|doi=10.3842/sigma.2014.079
and adding |doi-free=y
(or |doi-free=yes
/|doi-free=true
) as an extra argument of the template|doi-access=free
, |doi-access=restricted
, |doi-access=closed
I think it would be simpler to support only one of these syntaxes. Which one do you prefer?
I am not an expert but I think it would be cleaner to implement the second one, because otherwise we might break other tools which expect to find DOIs at |doi=
(for instance, codes that extract citations for Altmetrics, DBpedia or the
DOI event watcher). These tools will typically ignore parameters they don't know how to interpret, so they should not be disturbed by an extra |doi-free=
.
I guess the same applies for |url-free=
and for any other identifier we might also want to support (what are they?). −
Pintoch (
talk) 22:59, 4 July 2016 (UTC)
|doi-free=10.3842/sigma.2014.079
because it's less clutter-y than an additional |doi-free=yes
in addition to the regular |doi=10.3842/sigma.2014.079
, but you do make a very good point concerning bots and tools. I think you may have convinced me |doi-free=yes
is the way to go, even if it is more annoying to type.
Headbomb {
talk /
contribs /
physics /
books} 02:57, 5 July 2016 (UTC)|access-state=
rather than the more specific |doi-free=
. A more complex case would (could?) involve |accessn-state=
(n=1, 2, etc.)
72.43.99.138 (
talk) 17:43, 5 July 2016 (UTC)
|access-state=
or |access1/2/3/etc.-state=
apply?). If the doi (or other id) is free, then we flag it as that. There's no need to flag each individual identifiers as free/registration required/subscription required/paywalled/embargoed/etc. If it's free flag it. If not, keep it a normal link. For the general url, |access=
can be used.
Headbomb {
talk /
contribs /
physics /
books} 17:49, 5 July 2016 (UTC)
|access-state=free|registration|subscription|limited
etc. By the way, the exact naming is not important, but limiting it to doi is imo too narrow.
72.43.99.138 (
talk) 19:04, 5 July 2016 (UTC)
|subscription=
. −
Pintoch (
talk) 20:30, 5 July 2016 (UTC)I have made a series of icons ([[File:Lock-GREEN/YELLOW/RED.svg]]), based on Trappist's version up there.
This way, we can have something like (highlight the icons for tooltips)
Headbomb { talk / contribs / physics / books} 19:48, 5 July 2016 (UTC)
|doi-free=
, it would be more flexible to have |doi-access=
with the same range of values as |access=
.
Kanguole 21:03, 5 July 2016 (UTC)
{{
cite journal}}
: Unknown parameter |subscription=
ignored (|url-access=
suggested) (
help){{
pp}}
, not this stylized shape. ―
Mandruss
☎ 15:45, 12 July 2016 (UTC)
Now that the discussion has stabilized, should we implement the current mockup in the sandbox? − Pintoch ( talk) 18:56, 19 July 2016 (UTC)
|arxiv=
, |rfc=
and |pmc=
(when it is not marked as embargoed) are marked as free to read. I have not noticed any problem in the wild. I will try to implement the current mock-up in the sandbox in the coming days. −
Pintoch (
talk) 07:34, 1 August 2016 (UTC)I have implemented the mockup in the sandbox. You can try it out with {{ cite journal/new}}.
{{cite journal/new| ... | doi-access = subscription | access = free | doi = 10.1139/f92-220| url = https://www.researchgate.net/profile/James_Irvine5/publication/233865122_A_Robust_Procedure_for_Estimating_Salmon_Escapement_based_on_the_Area-Under-the-Curve_Method/links/09e4150c65bae92991000000.pdf}}
{{
cite journal}}
: Invalid |doi-access=subscription
(
help); Unknown parameter |access=
ignored (|access-date=
suggested) (
help)For now it only covers |access=
and |doi-access=
, we might want to add other ones such as |hdl-access=
. In the case above we replace the PDF icon with our icon, not sure whether this is a feature or a bug. What do you think?
I also wanted to throw an error when |access=
was provided without |url=
(and similarly for |doi-access=
/ |doi=
) but for some reason the error does not show up (any idea why?) −
Pintoch (
talk) 20:42, 1 August 2016 (UTC)
{{cite journal/new |title=Title |journal=Journal |access=subscription}}
{{
cite journal}}
: Unknown parameter |access=
ignored (|access-date=
suggested) (
help)error_condition
table member. That fixed, this shows an error:
{{cite journal/new |title=Title |journal=Journal |doi-access=free}}
{{
cite journal}}
: |doi-access=
requires |doi=
(
help)|access=
should be constrained to limited, registration, and subscription. Neither do I think that all identifiers (doi, bibcode, etc) have the subscription-require lock because that too is the norm so just more clutter. We should be identifying the exceptions with these icons: the norm for url-linked titles is free-to-read; the norm for most identifiers is subscription-required. When the title link or the identifier does not adhere to the norm, then we should say so.limited
and registration
should not use a yellow-ish lock color because the contrast value between that color and the background fails to meet the
WCAG contrast standard. And, making a darker yellow makes it not yellow. For this reason, I favor shape over color and is why I suggested the blue locks:
|url=
is closed by default). And what about |hdl=
for instance? (HDL are mostly used to link to institutional repositories, where the full text might or might not be available, it's not clear what the default would be.) So I think it is fine to allow editors to use |access=free
to add a free-to-read lock on |url=
. (That does not necessarily imply that we want to run a bot to add |access=free
at a large scale.) Actually, with your blue version of the icons, I don't think it would add much clutter as the blue lock would essentially replace the "external link" icon without being much catchier. I have included the colored ones because it seems to me that there was a consensus for them (now that the shapes are different) but of course it's easy to change. −
Pintoch (
talk) 12:40, 2 August 2016 (UTC)
|url=
is closed by default? What is it about that occupation that leads them to believe that?|arxiv=
, |pmc=
, |rfc=
excepted. Because the goal here, as I understand it, is to highlight for readers those links that are free-to-read, we should flag those that are and leave the rest with the default WP external link icon. If an |hdl=
link is free-to-read, mark it as such else don't mark it.|registration=
and |subscription=
which identify the exceptions.|url=
. (Chemistry is just the extreme example, but many other fields don't do much better than that unfortunately.) If |access=free
is forbidden, how should we indicate that the link is free to read? People have been using the {{open access}} template next to CS1 templates, but I think it is quite sad to resort to that while we could integrate it within CS1. −
Pintoch (
talk) 17:04, 2 August 2016 (UTC)
|url=
to link the title to a free-to-read source. That is the norm. In the cases where |url=
links to a paywall or registration, we have had available |registration=
and |subscription=
and their progenitor templates {{
registration required}}
and {{
subscription required}}
.|registration=
and |subscription=
.{{
cite journal}}
templates with a |url=
and checked if I could access the full text from the given URL. Here are the results: 59 were open, 25 were closed and 16 were broken. Note that a good proportion of the open ones are not scholarly citations (which should rather use {{
cite magazine}}
or {{
cite news}}
according to the guidelines). So free to read is the majority, yes, but not the norm. So just let the community choose! Let them add any access level on their own, they will use the lock if they find it useful. I don't see why we should assert what information editors should or shouldn't add in a futile case like this. −
Pintoch (
talk) 17:25, 3 August 2016 (UTC)
{{
citation}}
? All of them support |url=
so shouldn't you be examining the whole pie and not just a slice of it?{{
cite journal}}
is not the only CS1 template... (my previous message mentions {{
cite magazine}}
and {{
cite news}}
). I analyzed {{
cite journal}}
because I think this is where |access=free
would be needed the most. I think it does not hurt to forbid |access=free
for {{
cite web}}
, say (although I am not sure it is actually useful to do so), but surely we need it at least for {{
cite journal}}
. −
Pintoch (
talk) 06:41, 4 August 2016 (UTC)
|publisher=
. Consistency is important to editors who use these templates. We should not allow the application of |access=
to have context-specific meaning unless the benefits gained far outweigh the troubles that come with it: code complexity and maintenance, documentation, support questions that need to be answered, ...|access=
, |doi-access=
and others, regardless of the template, as it is currently implemented. Otherwise, as you say, we will have to answer support questions such as
this one we have got a few days ago. -
Pintoch (
talk) 12:01, 4 August 2016 (UTC)
we should keep the code as simple as possible. You wrote:
it does not hurt to forbid. You expressed certainty in the one case and indifference in the other. My reply to that was in regard to different code for different templates, to wit, given the same parameters, code that causes|access=free
for{{ cite web}}
, say (although I am not sure it is actually useful to do so), but surely we need it at least for{{ cite journal}}
{{
cite journal}}
to render differently from {{cite whatever}}
, should be avoided unless it is required by style guides, MOS, or the purpose of the template, etc. The application of a little green lock to a title link is not necessary because title links almost always lead to free-to-read sources. Do not highlight the norm.|registration=
and |subscription=
. I referred that editor to this discussion but apparently that editor has not elected to participate here.If |access=free
is forbidden, how should we indicate that the link is free to read?
|url=
are marked as such, not including any icon will not indicate much. Tagging all paywalled sources with the appropriate lock is very difficult (if you know how to automate that at Wikipedia's scale, I'm very interested). So we cannot assume that once these icons will be live, the absence of an icon will mean "free to read". −
Pintoch (
talk) 18:58, 2 August 2016 (UTC)
|url=
source behind a registration form or paywall should be marked because that condition is not the norm. Because there isn't an automatic way to know the access status of a source, readers can never be perfectly confident that editors didn't omit |access=
, that editors didn't assign it the correct value, .... No sense in worrying about it. To aid editors, we establish one simple rule: we do not highlight the norm. We reinforce that rule by deciding that |access=
accepts subscription
, limited
, and registration
. Similarly, for named identifiers, one simple rule: we do not highlight the norm and we reinforce that rule by deciding that |<id>-access=
accepts free
.|access=
or |<id>-access=
, so we can go straight to the Bot Approvals Group without waiting for the new version of CS1 to be rolled out. (OAbot would only be capable of adding new |url=
and the corresponding |access=free
or parameters that are always free such as |arxiv=
or |pmc=
.) But then again, I think it is also sad to forbid |doi-access=subscription
… −
Pintoch (
talk) 06:41, 4 August 2016 (UTC)
|access=free
for new |url=
. If |url=
points to a free-to-read source, an icon is not needed.|url=
if they whish to do so. I don't think there is any circular argument here. −
Pintoch (
talk) 19:35, 2 August 2016 (UTC)The label "access" is bound to cause confusion because it is too generic. It is conceivable that it could be mistaken for "url", "via", "access-date", "website" etc. Also: most people do not read the documentation anyway, and this label already has well-established meanings in everyday language. Naturally, editors may carry these meanings in editing CS1 templates. And that would be correct. After all, why should "access" have a special meaning here? Flagging such errors in code is "fixing" an unnecessary flaw. It is better to give more thought to this before hand, there are enough design flaws in the code already. It was suggested that "access-state" be used (but any such label would do). This is better because it is more specific, and also specialized enough to perhaps prompt somebody to look in the doc and find out what "access-state" actually means in this context. Assuming the doc is written clearly. I'm not really holding my breath. 65.88.88.126 ( talk) 15:38, 5 August 2016 (UTC)
In Template:Cite_web#Usage, the sample with the most commonly used parameters, which I guess, I am not the only to paste regularly for use, should include the following parameters:
| archive-url = | archive-date = | dead-url =
The reason is to lure more editors to archive links or get archived links to resist link rot. Ever more I find dead links and source has already disappeared from the web. -- Robertiki ( talk) 18:04, 12 August 2016 (UTC)
Add parameters single-author
/single-editor
/single-translator
which
Module:Citation/CS1 name_has_mult_names
should check for before adding the page to
Category:CS1 maint: Multiple names: authors list/
Category:CS1 maint: Multiple names: editors list/
Category:CS1 maint: Multiple names: translators list. This will allow editors to suppress false positives where a single author has a name which the module thinks looks like multiple authors. See
Category talk:CS1 maint: Multiple names: authors list#And
jnestorius(
talk) 11:04, 10 August 2016 (UTC)
|corporate-author=
to contain the name of a corporate author (regardless of how it is punctuated) and similarly for editors and translators?
Kanguole 11:25, 10 August 2016 (UTC)
|authors=
, |editors=
, |others=
, and aliases such as people).
72.43.99.146 (
talk) 13:51, 10 August 2016 (UTC)
|authors=
instead of |author=
match the semantics of a single (corporate) author? And use of that param is deprecated.
jnestorius(
talk) 14:44, 10 August 2016 (UTC)
|authors=
is not deprecated. Nothing suggests to me that it must be used for multiple authors. It can be used for any author because it is a free-form field. That single author may or may not have multiple names, or/and roles indicated.
72.43.99.146 (
talk) 14:55, 10 August 2016 (UTC)|others=
, another non-deprecated free-form parameter that may include a singular name.
72.43.99.146 (
talk) 14:57, 10 August 2016 (UTC)
|corporate-author=
will handle all cases; what if the author is "John, Marquess of Foo, Bar, and Baz"? The fact is that any automated parsing of natural language is imperfect and will throw up errors; in this case, adding inappropriate maintenance categories. The most general solution would be a single |suppress-maintenance-category=
param with comma-separated values, e.g. suppress-maintenance-category=mult_names_auth,mult_names_trans
.
jnestorius(
talk) 14:44, 10 August 2016 (UTC)
|authors=
(plural). The size and scope of that issue was unknown until we added
Category:CS1 maint: Uses authors parameter which hardly makes it spurious.|authors=
, |authorn=
, or |lastn=
/|firstn=
. But from the point of view of "let us extract everything of value that we can from the template", only one of those provides the most value. If you're concerned regarding clutter, that's something you're going to get regardless of which citation style (hand-jammed or template) you use--the only way to remove such is to be using a WYSIWYG editor (yes, that's the only way). The view that changing the particular parameters in a particular template citation is a change in style was quite firmly rejected per the closure of
this recent RFC. --
Izno (
talk) 11:58, 11 August 2016 (UTC)|authors=
(plural) are not included in the metadata because there is no rft.authors
keyword in the metadata standard. All information in |authors=
(or any of its aliases) is missing from the metadata rendering of a template and that does concern the validity of the template and the citation.there is no rft.authors
keyword in the metadata standard.
So let me elaborate. The standard does not support the concept of multiple author-names in a single key/value pair. It supports multiple authors by allowing an unlimited number of rft.au
key/value pairs (one author-name (the value) per key). Because it is a standard established and maintained outside of Wikipedia, we cannot 'fix it'. But, we can adapt to it by perhaps adopting Editor Kanguole's |corporate-author=
suggestion.|corporate-author=
as a free-form parameter, though one that is unnecessarily narrow (why limit it to "corporate"?). And yes, it seems that the code may be trying to do too many things, not all of them well.
72.43.99.146 (
talk) 15:06, 10 August 2016 (UTC)|corporate-author=
parameter. Because it identifies its content, editors know what it's for and the module will know to ignore commas. We can enumerate them: |corporate-authorn=
.|authorn=
? Do we decide that corporate authors are rendered at the end of the author name-list? Or, do we list author names and corporate-author names in a single list where the enumerator decides where each name goes in the list? (this is the much more difficult of these possible options because |corporate-authorn=
is not an alias of |last=
). Unlike |authors=
(plural), |corporate-author=
can be made part of the citation's metadata because it holds one corporate name.|corporate-author=
but I am sceptical that it will address all problems. I already gave one example ("John, Marquess of Foo, Bar, and Baz"). I have no idea how common such cases will be. I think it's usually worth having an override option to handle any unforeseen errors; but if the processing cost is high and the errors are rare it may not be.|corporate-author=
needs to be |corporate-authorn=
for the multiple case|corporate-authorn=Smith, Jones, and Foo
with |authorn=Smith, Jones, and Foo
|corporate-authorn=Y
-- this allows interleaving of corporate and non-corporate authors and might be easier to code|vauthors=
, the parameter value wrapped in doubled parentheses, could be applied to |author=
to suppress categorization. So your contrived example would be written: |authorn=((John, Marquess of Foo, Bar, and Baz))
. That idea was dismissed but I raise it again as a solution to the false positive problem that does not require the introduction of new parameters and their attendant code an documentation.|authors=
and viewed by readers, as you would wish; readers and editors need not worry or even know about the concomitant CS1 issues if they don't want to. If someone patrolling the maintenance category comes along and modifies the format to make it CS1 compliant, there is no loss to those who don't care about metadata. This discussion is about facilitating the work of such patrollers; I agree that solutions which make life harder for CS1-disdainers should be avoided, but I don't think that makes the whole issue pointless.
jnestorius(
talk) 15:03, 12 August 2016 (UTC)
|authors=
if you like: if others tweak it later it doesn't affect you; if those same others discuss how best to tweak it it doesn't affect you; if you think tweaking is a waste of time it doesn't affect you.
jnestorius(
talk) 01:51, 13 August 2016 (UTC)|authors=
. Since this free-form parameter is "discouraged", an easy solution to the problem described in your original post gets a hiccup. The proposed workarounds introduce complexity to CS1 in general, and who knows what kinds of complications. And I think, likely additional bewilderment on the part of the average user.
72.43.99.146 (
talk) 15:14, 13 August 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 15 | ← | Archive 20 | Archive 21 | Archive 22 | Archive 23 | Archive 24 | Archive 25 |
During WikiCite 2016 we plan to work on a bot that would add links to open access copies in citation links. See the relevant proposal and the current demo. Your input about how the bot should behave would be much appreciated. Let's use the project's talk page for this discussion.
In particular, we need to think about how to highlight open access versions, following the earlier discussion on this talk page. -- Pintoch ( talk) 09:40, 20 May 2016 (UTC)
|id={{citeseerx|...}}
, perhaps it would be better for us to add |citeseerx=
as a regular identifier. That would allow simple error checking and inclusion in the ctiation's metadata.|citeseerx=
as a parameter! But in fact, we will add identifiers from many other platforms, so I'm not sure where we should draw the line between identifiers and OA links (should we add a parameter for ResearchGate, for instance?) −
Pintoch (
talk) 11:27, 25 May 2016 (UTC)|10.1234/0123456789=
+ |doi-free=yes
or using |doi-free=10.1234/0123456789
, to be used only when the source is fully available, with no conditions on access. This would then display both the icon next to the ID and link the title. Something like
And that would apply for all identifiers, with the understanding that identifiers that are guaranteed to be free (e.g. arxiv, pmc, etc.) automatically get the icon. Headbomb { talk / contribs / physics / books} 16:57, 2 June 2016 (UTC)
Just a little side-idea: Given that in most cases the "open lock" symbol would follow the "external link arrow" symbol, wouldn't it be possible to combine them into one symbol? Either overlay the arrow symbol with a small lock in one of the corners, or just display a green (instead of a blue) external link symbol (and a red external link symbol for closed sources)? -- Matthiaspaul ( talk) 21:33, 8 June 2016 (UTC)
I'm pretty happy with the proposals here. Adding\marking links to openly accessible material is potentially quite valuable for the reader. It looks like the intention here is to signal "generally free to read" rather than (the previously suggested) "fully openly licensed content" - is this correct? If so, I'm definitely on board. If it's to be restricted to only CC-BY-type material, I'm not so sure it's useful; this is a bit of a subtle nuance that's not helpful for most readers. Andrew Gray ( talk) 21:57, 20 June 2016 (UTC)
There is a fly in the icon ointment. The way that MediaWiki implements the PDF icon has accessibility issues for the visually impaired. Because the icon is not an image in the html sense of an image, there is no
alt attribute that a screen reader can read to the human. This is why cs1|2 has |format=
and why cs1|2 automatically adds |format=PDF
when the value assigned to |url=
would cause MediaWiki to use the pdf icon. Using css to replace the normal external link icon would then require cs1|2 to add some sort of text to explain the open access nature of the preceding link.
It may still be possible to disable the normal external link icon and use an html image of the lock in its place, but to avoid adding additional text to each citation, this must be accomplished by a mixture of css to hide the external link icon and html to provide an image with the proper alt text.
— Trappist the monk ( talk) 12:05, 22 June 2016 (UTC)
<span class="plainlinks">[http://dx.doi.org/10.1234/0123456789 Article of things]</span>
<span style="margin-left:.1em">[[File:Open_Access_logo_PLoS_white_green.svg|9px|link=|open access publication - free to read]]</span>
{{cite journal |last=Smith |first=J. |year=2016 |title=Article of things |journal=Journal of Things |volume=66 |issue=3 |pages=11–15 |doi-free=10.1234/0123456789}}
|pmc=
and |arxiv=
first? They are low-hanging fruits as they do not require any change in the way templates are instantiated. I am happy to help implement this. −
Pintoch (
talk) 16:37, 29 June 2016 (UTC)I'm not quite sure why we need this. We already have indicators that can be added to indicate subscription required, like for newspaper sources. In my view, any source not free should be tagged with that, instead of tagging the free ones. Basically, online sources are free to read unless noted otherwise. Oiyarbepsy ( talk) 13:17, 22 June 2016 (UTC)
|subscription=
and |registration=
apply only to a citation as a whole, so we cannot use it to tell readers which links in a citation are paywalled. Second, we intend to use these parameters on scholarly references, where most sources are unfortunately paywalled (or just bare bibliographic references themselves). Third, I think that as a reader, it is more natural to get used to look for the green icon rather than to avoid links requiring subscriptions (you might actually have access to them in some contexts). Fourth, the bot we have written is never sure that a source is paywalled, but it can be sure that a source is free to read (that's easier to detect). −
Pintoch (
talk) 17:00, 22 June 2016 (UTC)Because the 'official' open access lock is orange, but the examples in this discussion use a green lock, I've started a conversation at Template talk:Open access#why is the lock orange?.
— Trappist the monk ( talk) 13:36, 23 June 2016 (UTC)
|alt=open access publication - free to read
. I see that alt text when I hover my mouse cursor over the lock: . Does that not work for you?{{
cite journal}}
, I believe), no. ···
日本穣 ·
投稿 ·
Talk to Nihonjoe ·
Join WP Japan! 00:30, 24 June 2016 (UTC)
Because of
this comment, I have modified the external_link_id()
, and arxiv()
functions in
Module:Citation/CS1/Identifiers/sandbox to replace the standard external link icon with a green lock:
The lock here is one that I modified from File:Open_Access_logo_PLoS_white_green.svg ( ). The primary differences are that the modified lock has a transparent background (the original's is white) and that the shackle is slightly more open:
For the time being, I have elected to leave the pmc identifier as it is. The pmc identifier is unique among the identifiers that cs1|2 supports because it causes the module to link |title=
with a redundant link that is the same as the identifier's link. I would prefer that all identifiers act the same way so would prefer to add the free to read lock to the pmc identifier and remove the special-case code that links |title=
with the identifier's url. I did remove that special-case code once, but that made some members of
WP:MED
rather angry.
— Trappist the monk ( talk) 13:40, 30 June 2016 (UTC)
if {{{url-free|}}} |url={{{url-free|}}} |url-icon=free else if {{{id-free|}}} |url=https://www.foobar.com/{{{id-free|}}} |url-icon=free else |url={{{url|}}} if {{{access|}}} |url-icon={{{access|}}} end if end if end if
with |access=
being either 'free' (green open lock) or 'non-free' (red closed lock). It could possibly be extended to have |access=registration
and |access=subscription
, producing yellow/red closed locks or something like that. There will be a need to develop a hierarchy of identifiers to see which should be favoured in case many are free, and allow this to be overridden through something like |url-free=pmc
} or |url-free=doi
.
Headbomb {
talk /
contribs /
physics /
books} 14:21, 30 June 2016 (UTC)
I like conciseness. I suppose it depends on the question: Just how important is it for the reader to understand the situation before they click through? It could take decades before a majority of readers who look at sources (1) have noticed those little locks and (2) have learned what they mean. We have little PDF icons, but the PDF logo is fairly widely recognized already (I think).
— User:Mandruss 16:27, 22 June 2016 (UTC)
|subscription=yes
text. Something like this:
upper curved partis the ' shackle'. The goal here is to have a lock that looks more or less like the orange (what were they thinking when they chose that color?) lock apparently associated with Open Access: . My green lock is derived from that design. At 9px width, small detail like the notch you describe will be lost. Even the much more open shackle of the green lock is relatively unnoticeable. Here are the two locks at 18px width:
I am deeply impressed by and appreciative of the detailed work above to improve the implementation. I think before this goes live, it would be wise to draw attention to the conversation from at least Village Pump and WikiProject Open Access. In order to make that consultation useful, we need a concise explanation of the what/when/where/why/how and a few examples of the change as it will appear. Ocaasi t | c 20:47, 30 June 2016 (UTC)
The top of the icon appears to be 1 pixel higher than the surrounding text (which is fine by me, since I only noticed it when zooming in a lot).
What's bugging me is that the lock extends 5 pixels below the numeric characters to the left of the above examples after "0707.0835", and 1 pixel below the to the right. It would be nice to have it aligned and/or as standardized height (which isn't that straightforward b/c people can use different fonts etc., but perhaps mimicking the default font's height limits is a good place to start). ~
Tom.Reding (
talk ⋅
dgaf) 16:41, 2 July 2016 (UTC)
Actually, this is more a description of a height issue than a valignment issue, since the lock is valigned (centered) with the , but not with the
0835
. ~
Tom.Reding (
talk ⋅
dgaf) 16:45, 2 July 2016 (UTC)
Two syntaxes have been suggested to specify that a DOI (for instance) is free to read:
|doi=10.3842/sigma.2014.079
by |doi-free=10.3842/sigma.2014.079
|doi=10.3842/sigma.2014.079
and adding |doi-free=y
(or |doi-free=yes
/|doi-free=true
) as an extra argument of the template|doi-access=free
, |doi-access=restricted
, |doi-access=closed
I think it would be simpler to support only one of these syntaxes. Which one do you prefer?
I am not an expert but I think it would be cleaner to implement the second one, because otherwise we might break other tools which expect to find DOIs at |doi=
(for instance, codes that extract citations for Altmetrics, DBpedia or the
DOI event watcher). These tools will typically ignore parameters they don't know how to interpret, so they should not be disturbed by an extra |doi-free=
.
I guess the same applies for |url-free=
and for any other identifier we might also want to support (what are they?). −
Pintoch (
talk) 22:59, 4 July 2016 (UTC)
|doi-free=10.3842/sigma.2014.079
because it's less clutter-y than an additional |doi-free=yes
in addition to the regular |doi=10.3842/sigma.2014.079
, but you do make a very good point concerning bots and tools. I think you may have convinced me |doi-free=yes
is the way to go, even if it is more annoying to type.
Headbomb {
talk /
contribs /
physics /
books} 02:57, 5 July 2016 (UTC)|access-state=
rather than the more specific |doi-free=
. A more complex case would (could?) involve |accessn-state=
(n=1, 2, etc.)
72.43.99.138 (
talk) 17:43, 5 July 2016 (UTC)
|access-state=
or |access1/2/3/etc.-state=
apply?). If the doi (or other id) is free, then we flag it as that. There's no need to flag each individual identifiers as free/registration required/subscription required/paywalled/embargoed/etc. If it's free flag it. If not, keep it a normal link. For the general url, |access=
can be used.
Headbomb {
talk /
contribs /
physics /
books} 17:49, 5 July 2016 (UTC)
|access-state=free|registration|subscription|limited
etc. By the way, the exact naming is not important, but limiting it to doi is imo too narrow.
72.43.99.138 (
talk) 19:04, 5 July 2016 (UTC)
|subscription=
. −
Pintoch (
talk) 20:30, 5 July 2016 (UTC)I have made a series of icons ([[File:Lock-GREEN/YELLOW/RED.svg]]), based on Trappist's version up there.
This way, we can have something like (highlight the icons for tooltips)
Headbomb { talk / contribs / physics / books} 19:48, 5 July 2016 (UTC)
|doi-free=
, it would be more flexible to have |doi-access=
with the same range of values as |access=
.
Kanguole 21:03, 5 July 2016 (UTC)
{{
cite journal}}
: Unknown parameter |subscription=
ignored (|url-access=
suggested) (
help){{
pp}}
, not this stylized shape. ―
Mandruss
☎ 15:45, 12 July 2016 (UTC)
Now that the discussion has stabilized, should we implement the current mockup in the sandbox? − Pintoch ( talk) 18:56, 19 July 2016 (UTC)
|arxiv=
, |rfc=
and |pmc=
(when it is not marked as embargoed) are marked as free to read. I have not noticed any problem in the wild. I will try to implement the current mock-up in the sandbox in the coming days. −
Pintoch (
talk) 07:34, 1 August 2016 (UTC)I have implemented the mockup in the sandbox. You can try it out with {{ cite journal/new}}.
{{cite journal/new| ... | doi-access = subscription | access = free | doi = 10.1139/f92-220| url = https://www.researchgate.net/profile/James_Irvine5/publication/233865122_A_Robust_Procedure_for_Estimating_Salmon_Escapement_based_on_the_Area-Under-the-Curve_Method/links/09e4150c65bae92991000000.pdf}}
{{
cite journal}}
: Invalid |doi-access=subscription
(
help); Unknown parameter |access=
ignored (|access-date=
suggested) (
help)For now it only covers |access=
and |doi-access=
, we might want to add other ones such as |hdl-access=
. In the case above we replace the PDF icon with our icon, not sure whether this is a feature or a bug. What do you think?
I also wanted to throw an error when |access=
was provided without |url=
(and similarly for |doi-access=
/ |doi=
) but for some reason the error does not show up (any idea why?) −
Pintoch (
talk) 20:42, 1 August 2016 (UTC)
{{cite journal/new |title=Title |journal=Journal |access=subscription}}
{{
cite journal}}
: Unknown parameter |access=
ignored (|access-date=
suggested) (
help)error_condition
table member. That fixed, this shows an error:
{{cite journal/new |title=Title |journal=Journal |doi-access=free}}
{{
cite journal}}
: |doi-access=
requires |doi=
(
help)|access=
should be constrained to limited, registration, and subscription. Neither do I think that all identifiers (doi, bibcode, etc) have the subscription-require lock because that too is the norm so just more clutter. We should be identifying the exceptions with these icons: the norm for url-linked titles is free-to-read; the norm for most identifiers is subscription-required. When the title link or the identifier does not adhere to the norm, then we should say so.limited
and registration
should not use a yellow-ish lock color because the contrast value between that color and the background fails to meet the
WCAG contrast standard. And, making a darker yellow makes it not yellow. For this reason, I favor shape over color and is why I suggested the blue locks:
|url=
is closed by default). And what about |hdl=
for instance? (HDL are mostly used to link to institutional repositories, where the full text might or might not be available, it's not clear what the default would be.) So I think it is fine to allow editors to use |access=free
to add a free-to-read lock on |url=
. (That does not necessarily imply that we want to run a bot to add |access=free
at a large scale.) Actually, with your blue version of the icons, I don't think it would add much clutter as the blue lock would essentially replace the "external link" icon without being much catchier. I have included the colored ones because it seems to me that there was a consensus for them (now that the shapes are different) but of course it's easy to change. −
Pintoch (
talk) 12:40, 2 August 2016 (UTC)
|url=
is closed by default? What is it about that occupation that leads them to believe that?|arxiv=
, |pmc=
, |rfc=
excepted. Because the goal here, as I understand it, is to highlight for readers those links that are free-to-read, we should flag those that are and leave the rest with the default WP external link icon. If an |hdl=
link is free-to-read, mark it as such else don't mark it.|registration=
and |subscription=
which identify the exceptions.|url=
. (Chemistry is just the extreme example, but many other fields don't do much better than that unfortunately.) If |access=free
is forbidden, how should we indicate that the link is free to read? People have been using the {{open access}} template next to CS1 templates, but I think it is quite sad to resort to that while we could integrate it within CS1. −
Pintoch (
talk) 17:04, 2 August 2016 (UTC)
|url=
to link the title to a free-to-read source. That is the norm. In the cases where |url=
links to a paywall or registration, we have had available |registration=
and |subscription=
and their progenitor templates {{
registration required}}
and {{
subscription required}}
.|registration=
and |subscription=
.{{
cite journal}}
templates with a |url=
and checked if I could access the full text from the given URL. Here are the results: 59 were open, 25 were closed and 16 were broken. Note that a good proportion of the open ones are not scholarly citations (which should rather use {{
cite magazine}}
or {{
cite news}}
according to the guidelines). So free to read is the majority, yes, but not the norm. So just let the community choose! Let them add any access level on their own, they will use the lock if they find it useful. I don't see why we should assert what information editors should or shouldn't add in a futile case like this. −
Pintoch (
talk) 17:25, 3 August 2016 (UTC)
{{
citation}}
? All of them support |url=
so shouldn't you be examining the whole pie and not just a slice of it?{{
cite journal}}
is not the only CS1 template... (my previous message mentions {{
cite magazine}}
and {{
cite news}}
). I analyzed {{
cite journal}}
because I think this is where |access=free
would be needed the most. I think it does not hurt to forbid |access=free
for {{
cite web}}
, say (although I am not sure it is actually useful to do so), but surely we need it at least for {{
cite journal}}
. −
Pintoch (
talk) 06:41, 4 August 2016 (UTC)
|publisher=
. Consistency is important to editors who use these templates. We should not allow the application of |access=
to have context-specific meaning unless the benefits gained far outweigh the troubles that come with it: code complexity and maintenance, documentation, support questions that need to be answered, ...|access=
, |doi-access=
and others, regardless of the template, as it is currently implemented. Otherwise, as you say, we will have to answer support questions such as
this one we have got a few days ago. -
Pintoch (
talk) 12:01, 4 August 2016 (UTC)
we should keep the code as simple as possible. You wrote:
it does not hurt to forbid. You expressed certainty in the one case and indifference in the other. My reply to that was in regard to different code for different templates, to wit, given the same parameters, code that causes|access=free
for{{ cite web}}
, say (although I am not sure it is actually useful to do so), but surely we need it at least for{{ cite journal}}
{{
cite journal}}
to render differently from {{cite whatever}}
, should be avoided unless it is required by style guides, MOS, or the purpose of the template, etc. The application of a little green lock to a title link is not necessary because title links almost always lead to free-to-read sources. Do not highlight the norm.|registration=
and |subscription=
. I referred that editor to this discussion but apparently that editor has not elected to participate here.If |access=free
is forbidden, how should we indicate that the link is free to read?
|url=
are marked as such, not including any icon will not indicate much. Tagging all paywalled sources with the appropriate lock is very difficult (if you know how to automate that at Wikipedia's scale, I'm very interested). So we cannot assume that once these icons will be live, the absence of an icon will mean "free to read". −
Pintoch (
talk) 18:58, 2 August 2016 (UTC)
|url=
source behind a registration form or paywall should be marked because that condition is not the norm. Because there isn't an automatic way to know the access status of a source, readers can never be perfectly confident that editors didn't omit |access=
, that editors didn't assign it the correct value, .... No sense in worrying about it. To aid editors, we establish one simple rule: we do not highlight the norm. We reinforce that rule by deciding that |access=
accepts subscription
, limited
, and registration
. Similarly, for named identifiers, one simple rule: we do not highlight the norm and we reinforce that rule by deciding that |<id>-access=
accepts free
.|access=
or |<id>-access=
, so we can go straight to the Bot Approvals Group without waiting for the new version of CS1 to be rolled out. (OAbot would only be capable of adding new |url=
and the corresponding |access=free
or parameters that are always free such as |arxiv=
or |pmc=
.) But then again, I think it is also sad to forbid |doi-access=subscription
… −
Pintoch (
talk) 06:41, 4 August 2016 (UTC)
|access=free
for new |url=
. If |url=
points to a free-to-read source, an icon is not needed.|url=
if they whish to do so. I don't think there is any circular argument here. −
Pintoch (
talk) 19:35, 2 August 2016 (UTC)The label "access" is bound to cause confusion because it is too generic. It is conceivable that it could be mistaken for "url", "via", "access-date", "website" etc. Also: most people do not read the documentation anyway, and this label already has well-established meanings in everyday language. Naturally, editors may carry these meanings in editing CS1 templates. And that would be correct. After all, why should "access" have a special meaning here? Flagging such errors in code is "fixing" an unnecessary flaw. It is better to give more thought to this before hand, there are enough design flaws in the code already. It was suggested that "access-state" be used (but any such label would do). This is better because it is more specific, and also specialized enough to perhaps prompt somebody to look in the doc and find out what "access-state" actually means in this context. Assuming the doc is written clearly. I'm not really holding my breath. 65.88.88.126 ( talk) 15:38, 5 August 2016 (UTC)
In Template:Cite_web#Usage, the sample with the most commonly used parameters, which I guess, I am not the only to paste regularly for use, should include the following parameters:
| archive-url = | archive-date = | dead-url =
The reason is to lure more editors to archive links or get archived links to resist link rot. Ever more I find dead links and source has already disappeared from the web. -- Robertiki ( talk) 18:04, 12 August 2016 (UTC)
Add parameters single-author
/single-editor
/single-translator
which
Module:Citation/CS1 name_has_mult_names
should check for before adding the page to
Category:CS1 maint: Multiple names: authors list/
Category:CS1 maint: Multiple names: editors list/
Category:CS1 maint: Multiple names: translators list. This will allow editors to suppress false positives where a single author has a name which the module thinks looks like multiple authors. See
Category talk:CS1 maint: Multiple names: authors list#And
jnestorius(
talk) 11:04, 10 August 2016 (UTC)
|corporate-author=
to contain the name of a corporate author (regardless of how it is punctuated) and similarly for editors and translators?
Kanguole 11:25, 10 August 2016 (UTC)
|authors=
, |editors=
, |others=
, and aliases such as people).
72.43.99.146 (
talk) 13:51, 10 August 2016 (UTC)
|authors=
instead of |author=
match the semantics of a single (corporate) author? And use of that param is deprecated.
jnestorius(
talk) 14:44, 10 August 2016 (UTC)
|authors=
is not deprecated. Nothing suggests to me that it must be used for multiple authors. It can be used for any author because it is a free-form field. That single author may or may not have multiple names, or/and roles indicated.
72.43.99.146 (
talk) 14:55, 10 August 2016 (UTC)|others=
, another non-deprecated free-form parameter that may include a singular name.
72.43.99.146 (
talk) 14:57, 10 August 2016 (UTC)
|corporate-author=
will handle all cases; what if the author is "John, Marquess of Foo, Bar, and Baz"? The fact is that any automated parsing of natural language is imperfect and will throw up errors; in this case, adding inappropriate maintenance categories. The most general solution would be a single |suppress-maintenance-category=
param with comma-separated values, e.g. suppress-maintenance-category=mult_names_auth,mult_names_trans
.
jnestorius(
talk) 14:44, 10 August 2016 (UTC)
|authors=
(plural). The size and scope of that issue was unknown until we added
Category:CS1 maint: Uses authors parameter which hardly makes it spurious.|authors=
, |authorn=
, or |lastn=
/|firstn=
. But from the point of view of "let us extract everything of value that we can from the template", only one of those provides the most value. If you're concerned regarding clutter, that's something you're going to get regardless of which citation style (hand-jammed or template) you use--the only way to remove such is to be using a WYSIWYG editor (yes, that's the only way). The view that changing the particular parameters in a particular template citation is a change in style was quite firmly rejected per the closure of
this recent RFC. --
Izno (
talk) 11:58, 11 August 2016 (UTC)|authors=
(plural) are not included in the metadata because there is no rft.authors
keyword in the metadata standard. All information in |authors=
(or any of its aliases) is missing from the metadata rendering of a template and that does concern the validity of the template and the citation.there is no rft.authors
keyword in the metadata standard.
So let me elaborate. The standard does not support the concept of multiple author-names in a single key/value pair. It supports multiple authors by allowing an unlimited number of rft.au
key/value pairs (one author-name (the value) per key). Because it is a standard established and maintained outside of Wikipedia, we cannot 'fix it'. But, we can adapt to it by perhaps adopting Editor Kanguole's |corporate-author=
suggestion.|corporate-author=
as a free-form parameter, though one that is unnecessarily narrow (why limit it to "corporate"?). And yes, it seems that the code may be trying to do too many things, not all of them well.
72.43.99.146 (
talk) 15:06, 10 August 2016 (UTC)|corporate-author=
parameter. Because it identifies its content, editors know what it's for and the module will know to ignore commas. We can enumerate them: |corporate-authorn=
.|authorn=
? Do we decide that corporate authors are rendered at the end of the author name-list? Or, do we list author names and corporate-author names in a single list where the enumerator decides where each name goes in the list? (this is the much more difficult of these possible options because |corporate-authorn=
is not an alias of |last=
). Unlike |authors=
(plural), |corporate-author=
can be made part of the citation's metadata because it holds one corporate name.|corporate-author=
but I am sceptical that it will address all problems. I already gave one example ("John, Marquess of Foo, Bar, and Baz"). I have no idea how common such cases will be. I think it's usually worth having an override option to handle any unforeseen errors; but if the processing cost is high and the errors are rare it may not be.|corporate-author=
needs to be |corporate-authorn=
for the multiple case|corporate-authorn=Smith, Jones, and Foo
with |authorn=Smith, Jones, and Foo
|corporate-authorn=Y
-- this allows interleaving of corporate and non-corporate authors and might be easier to code|vauthors=
, the parameter value wrapped in doubled parentheses, could be applied to |author=
to suppress categorization. So your contrived example would be written: |authorn=((John, Marquess of Foo, Bar, and Baz))
. That idea was dismissed but I raise it again as a solution to the false positive problem that does not require the introduction of new parameters and their attendant code an documentation.|authors=
and viewed by readers, as you would wish; readers and editors need not worry or even know about the concomitant CS1 issues if they don't want to. If someone patrolling the maintenance category comes along and modifies the format to make it CS1 compliant, there is no loss to those who don't care about metadata. This discussion is about facilitating the work of such patrollers; I agree that solutions which make life harder for CS1-disdainers should be avoided, but I don't think that makes the whole issue pointless.
jnestorius(
talk) 15:03, 12 August 2016 (UTC)
|authors=
if you like: if others tweak it later it doesn't affect you; if those same others discuss how best to tweak it it doesn't affect you; if you think tweaking is a waste of time it doesn't affect you.
jnestorius(
talk) 01:51, 13 August 2016 (UTC)|authors=
. Since this free-form parameter is "discouraged", an easy solution to the problem described in your original post gets a hiccup. The proposed workarounds introduce complexity to CS1 in general, and who knows what kinds of complications. And I think, likely additional bewilderment on the part of the average user.
72.43.99.146 (
talk) 15:14, 13 August 2016 (UTC)