Help talk:Citation Style 1/Archive 74

• The RFC cited does not support the claims put forward in this edit. The RfC's conclusion was solely that websites should be italicized, which is accomplished by the use of |website=. It did not comment on when |website= vs |publisher= should be used - ie whether a particular entity is best described as a work or a publisher. Nikkimaria (talk) 03:04, 4 January 2021 (UTC)
  • I strongly disagree. That
    WP:CITALICSRFC had extensive discussion and it should not be necessary to rehash it all again and act all confused about it. It shouldn't matter whether the website I am referencing is the CBS News website or The New York Times website or the CNN website or the BBC website or the PBS website – the name of the website should be rendered in the same way (with italics). And we should definitely not be using the publisher parameter and omitting the website/work name as a way of avoiding the italics. The concept here is not really so complicated. — BarrelProof (talk
    ) 05:55, 4 January 2021 (UTC)
    • You and SMcCandlish are both repeating loudly and at great length the part we are all completely clear about (names of websites or more generally of collections of works should be italicized, names of organizations that publish websites should not) and by doing so, you are obfuscating the real question: how do we come to agreement on whether a name like "BBC News" refers to the organization that publishes collections like "BBC Newsroom Live", or whether it refers to a collection of pages or programs that is published by a larger umbrella organization, BBC? —David Eppstein (talk) 07:41, 4 January 2021 (UTC)
      • Roughly speaking, BBC or BBC News is both the name of a website and the name of the organization that publishes it. When the name of a work/website and the name of its publisher are the same or very similar (e.g., The New York Times and The New York Times Company), we omit the redundant publisher name in citations. We also ordinarily omit publisher names for well-known publications (e.g., Newsweek, published by IBT Media). None of that is a new concept. — BarrelProof (talk) 19:10, 4 January 2021 (UTC)

I wonder if the confusion arises from the fact that the publisher and the publisher's property have similar names. BBC publishes BBC News which has a department/regular feature called BBC Newsroom Live that may sometimes produce named reports. So the title here would be the title of the named report, absent that the publication/broadcast/upload date would in effect double as the title, since that is the way news programs are classified. Or is it that the medium (online) makes people think that different rules apply? All this is somewhat academic. What matters in citations is how do you find it, or rather how do you find it in the easiest way possible? Online searches may often obfuscate the provider. The actual source may be hidden in the URL syntax, and what appears to have come from one place, may have actually come from a different discrete location. 4.35.85.227 (talk) 13:12, 4 January 2021 (UTC)

• What I take from this discussion is that some editors need to be reminded to properly distinguish between the |work= and |publisher= parameters and to not abuse them for stylistic reasons. I tried to improve the documentation by stating this explicitly and adding a crosslink but was reverted by Kanguole ([1]) for this would be bloating the documentation. In fact it does and I would prefer we would not need it, but looking at the discussion above apparently we do. My time is limited and I do not care enough about this triviality to further engage into this discussion, therefore I leave it to others to restore the sentence and link - or not - as they see fit.

See also: Help_talk:Citation_Style_1#Documentation_bloat

--Matthiaspaul (talk) 23:05, 4 January 2021 (UTC) (updated 03:47, 5 January 2021 (UTC))

I have started this discussion because an editor at my talk page has objected to the bot's replacement of |accessdate=: accessdate is not currently deprecated, there is currently no discussion about deprecating it, and your only basis for replacing it by bot is the concern that were we to get consensus to deprecate it at some unknown future point, error messages would annoy people? For the time being, I have disabled the |accessdate= to |access-date= replacement.

I believe that it is our intent to deprecate and remove all of the all-run-together multiword parameter names in favor of their hyphenated forms. Am I wrong? At the bottom of the §Deprecated section of every cs1|2 template (except Template:Cite citeseerx/doc) is this:

In addition to the above list(s) of deprecated and removed parameters, all non-hyphenated aliases of parameters with hyphens are discouraged to be used in citation templates and are kept only for legacy support. They are subject to becoming deprecated and unsupported in the future as well. To streamline the appearance and improve consistency across the project, these variants should no longer be used when adding parameters to citation templates. Instead, select the hyphenated parameter variants and also consider switching other non-hyphenated parameters, which may be present in a citation already, to their hyphenated equivalents at the same time. – emphasis in original

A variant of that text is present at Help:CS1 errors#Cite uses deprecated parameter |<param>=:

Plan for the future: All non-hyphenated, multiword parameter names are aliases of hyphenated multiword parameter names. The non-hyphenated aliases exist only for legacy support. Editors should expect that support for non-hyphenated parameter names will be withdrawn. Choose the hyphenated form when adding parameters to a citation template. Consider replacing non-hyphenated parameters with the hyphenated equivalents at the same time.

Do those declarations accurately reflect our intent with regard to nonhyphenated parameter names? I believe that the answer is yes because:

• we have arranged the cs1|2 documentation to list hyphenated multiword forms first; these are the canonical forms
• we have arranged the aliases{} table in Module:Citation/CS1/Configuration so that the hyphenated multiword forms are listed first
• cs1|2 parameters need only one name except where semantics dictate a need for alternate parameter names (|chapter=, |contribution=, |entry=, |article=, |section=); nonhyphenated variants of a hyphenated parameter name do not meet this criterium
• there is no need to retain relics from the mergers of the various independent cs1 templates
• we have created new multiword parameters without simultaneously creating new nonhyphenated aliases (|chapter-url-access=, |name-list-style=, |script-title=, |url-status=, etc)
• at the 2020-10-10 Module:Citation/CS1-suite update, we deprecated several nonhyphenated parameter names and removed support for quite a few others; see the lists at Cite uses deprecated parameter |<param>=
• at the next module-suite update, we will be deprecating these: |conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |sectionurl=, |seriesno=, |timecaption=, and |titlelink=; discussion

It is probably true that we have never actually declared an intent to deprecate and remove, but reading between the lines of our past and current actions, it seems highly likely to me that our intent is to deprecate and remove these parameter names.

Is it?

—Trappist the monk (talk) 12:41, 30 November 2020 (UTC)

• There is a very significant difference between saying hyphenated is preferred and saying non-hyphenated cannot be used. Given the scale of the change proposed, this requires strong consensus, including from those who are not regulars here. Nikkimaria (talk) 12:46, 30 November 2020 (UTC)
  • Pinging some other editors who have raised objections at your talk page: ɱ, Jason Quinn, oknazevad. Nikkimaria (talk) 12:49, 30 November 2020 (UTC)
• Agree to deprecate and remove. For the sake of clarity, made-up compound terms should be separated. Even more so where specialist language may be employed.

  I also agree that this should have consensus but I don't see the scale of change as an important factor. We are talking about a formatting change that is transparent, with zero effect on semantics, in a very specialized area of Wikipedia. Imo, the change makes semantic meaning more obvious, a good thing. 68.173.79.202 (talk) 13:42, 30 November 2020 (UTC)

  We are talking about a formatting change that impacts a very widely used parameter in a very widely used set of templates. Whether you think the change is positive or not, it can be anticipated to have a impact on a large number of editors. As such, it would be appropriate to solicit input from a wider range of contributors than just those who happen to frequent this page. Nikkimaria (talk) 22:39, 30 November 2020 (UTC)

  Well, we are in almost complete agreement. Almost, because if someone is going to throw a fit over the appearance of perfectly harmless punctuation, and solely in the edit window, then we may be getting into the realm of therapy. Not that this is uncommon in Wikipedia. Among certain groups of editors, it is often prevalent behavior. In any case, that is why the presumed gravity of this change was questioned - everything else you state is agreed. As for the server load, well, not our concern really. And I assume that this would happen at the next module-group update anyway? Perhaps the commit might add a few more tics on the server clocks. I think Wikipedia will survive it. 98.0.246.242 (talk) 01:53, 1 December 2020 (UTC)

• Support deprecation & preemptive and/or prescriptive updating of all relevant non-hyphenated parameters.   ~ 
  dgaf
  )  14:48, 30 November 2020 (UTC)
• If there isn't consensus already, I say we should deprecate the remaining unhyphenated parameter aliases. One of the objections raised was that the hyphens create line breaks. Funnily enough, that's exactly why I prefer the hyphenated forms; in addition to being more canonical in general, the line breaks mean that the lines will have more consistent lengths. This is perhaps the most useful in connection to |archiveurl=, which often has a very long link without any breaks. Using |archive-url= helps alleviate this. It also helps to distinguish "Archived from the original on..." as plain text, |archivedate=, and |archive-date= in plain-text searches. -BRAINULATOR9 (TALK) 15:07, 30 November 2020 (UTC)
• The system evolved over time and occasionally needs a refactor to keep it from spiraling into an unmanageable beast. "Caution: work in progress". Given the scale getting it done as quickly as possible is best, otherwise it will be irritating watchlists for 6 months ( at 10 edits/minute). AWB is not the right tool. The fastest way is via parallel processes on Toolforge (up to 15 slots though more slots might be requested). Toolforge is in the same data center so LAN speed. It should be possible to get it done in a few weeks with forward warning to temporarily enable "Hide: [ ]Bots" for anyone concerned about watchlist overload. -- `GreenC 15:09, 30 November 2020 (UTC)
• I believe all the regression testcases (Template:Cite book/testcases/regression tests) use authorlink and accessdate. Should deprecate mean changing those to author-link, or should legacy support mean duplicating them all? Or are these regression tests really not useful? David Brooks (talk) 18:20, 30 November 2020 (UTC) ETA: also true of Template:Cite book/testcases, I realize. David Brooks (talk) 18:22, 30 November 2020 (UTC)

  Those are updated when necessary. (Their utility is also somewhat suspect as they aren't exactly systematic.) --Izno (talk) 19:45, 30 November 2020 (UTC)

• I prefer non-hyphenated authorlink and accessdate because it is easier to type. I don't see why it should be deprecated. —David Eppstein (talk) 19:21, 30 November 2020 (UTC)

  By one character? Seriously? :-) They're harder to read; our entire template system has for years been moving away from mashedtogetherwordmess in template parameters and names, as it has been a major part of the daunting WP learning curve for new editors. There's no reason to disable them, but we should stop "advertising" those variants, and should ask citation tool makers to switch to the more sensible versions. Similarly, {{

  cn}} still redirects to {{citation needed}}, but we even have bots and AWB/JWB scripts that canonicalize such shortcuts to the real, non-jibberish templates names, and various tools use the real names of the templates in the first place now. Also, various cite template parameters (mostly newer ones) with hyphens don't even have non-hyphenated aliases, and the sky did not fall; there is no editorial outcry about it, so obviously there's not a real editorial demand for them theruntogetherversions as necessary or desirable.  — SMcCandlish ☏ ¢

   😼  21:23, 30 November 2020 (UTC)

  It's not just that it's one character; it's one character for which I have to move my whole hand away from the letter keys. It's significantly slower for me than just another letter. —David Eppstein (talk) 18:19, 1 December 2020 (UTC)

  Well, then don't use the hyphen version. Some bot or AWB script can deal with it later. I don't see anyone arguing for disabling the hyphen-free versions. They don't don't need to be advocated in the documentation since their use makes human parsing of the wikicode more difficult.  — SMcCandlish ☏ ¢ 😼  20:58, 4 December 2020 (UTC)

  SMcCandlish, deprecating the hyphen-free version is in fact exactly what this discussion is advocating. Nikkimaria (talk) 21:47, 4 December 2020 (UTC)

  "Deprecation" need not equate to disabling the functionality of. @

  WP:NOT#BUREACRACY things. The templates and their code exist to serve us, not the other way around.  — SMcCandlish ☏ ¢

   😼  21:59, 4 December 2020 (UTC)

  "Deprecation", by the definition used in the context of CS1/CS2, means that if the parameter is used, a red maintenance message will be shown and it will appear in a tracking category. It is a phase before removal of support for a parameter (in which case only an "unsupported parameter" message and optionally a hint on the new parameter will be shown). It is possible to stay in this state for extended periods of time, but the idea is that eventually the functionality will go (at least under this particular parameter name). While some of the non-hyphenated parameters are already deprecated, parameters like |accessdate= or |authorlink= are still too frequently used in mainspace to deprecate them now, they are only "discouraged". Being "discouraged" means that the functionality is still supported and no error message shown, but that preparations are in the works to deprecate the parameter at some later point in time, so it is wise to reduce the parameter's use whereever possible so that less work needs to be done when it gets deprecated eventually. --Matthiaspaul (talk) 23:16, 4 December 2020 (UTC)

  The first word in the this discussion's heading is 'deprecation'. Deprecation will not disable the functionality of |accessdate=. The functionality of any deprecated parameter is retained through the deprecation period. At the end of the deprecation period, support for the parameter name will be withdrawn and the parameter name will no longer work. For |accessdate=, an extended deprecation period may be desirable.

  —Trappist the monk (talk) 12:32, 5 December 2020 (UTC)

  So what you're saying is that yes, this discussion will lead to the disabling of the functionality of |accessdate=. Nikkimaria (talk) 13:12, 5 December 2020 (UTC)

  Are you not reading what I have previously written in this discussion? Earlier I wrote: The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intent. In that sentence, all nonhyphenated parameters includes |accessdate= because that parameter name is a concatenation of two words and is not hyphenated.

  —Trappist the monk (talk) 15:43, 5 December 2020 (UTC)

  Well, for my part then, I don't think this should be deprecated in this particular way. Long-used parameter aliases should still remain functional, even if we do not mention them any longer in the documentation.  — SMcCandlish ☏ ¢ 😼  17:55, 6 December 2020 (UTC)

  At least in the common two-hand keyboard layouts for touch-typing (including US and UK QWERTY layouts), there is no need to move the whole hand away from the letter keys to reach the hyphen. All it requires is a slight move of the right hand's little finger. --Matthiaspaul (talk) 23:16, 4 December 2020 (UTC)

  For |accessdate= on a qwerty keyboard, the introductory pipe is both hands, 'accessdate' left hand only, and the assignement operator is right hand and the key is directly adjacent to the hyphen character.

  —Trappist the monk (talk) 12:32, 5 December 2020 (UTC)

• Support of the deprecation of all non-hyphenated multiword parameter names to achieve consistency across the project, improve readability in general and help users to memorize multiword parameter names. The fact that long parameter names wrap around also helps to keep citations readable even in narrow edit windows. In the long run, deprecation will help to simplify the citation template source code somewhat, giving us more room for more useful enhancements than just supporting syntactical equivalent parameter variants. I think, there has been a trend towards this for several years.

  While I think we should be careful not to actually remove support for frequently used parameter variants until all uses in mainspace (and possibly also in other spaces) and all tools have been updated to use hyphenated parameter variants, I think, we should not skip a chance to transform citations automatically in order to make the transition as smooth as possible for everyone.

  --Matthiaspaul (talk) 22:34, 30 November 2020 (UTC)

  Just one observation about the automation proposal. There are hundreds (literally) of templates that wrap {{cite book}}, and many more that wrap {{cite encyclopedia}}, etc. Some of these templates recognize and pass through |authorlink= etc. That raises two concerns - identify all those leaf templates that recognize these parameters and pass them on, and make sure they also recognize the hyphenated version before touching their customer articles. (There are other templates that transclude {{cite book}} and can be fixed painlessly). Second, somewhat orthogonally, in order to make the change thoroughly it should be necessary to list all templates that through a call chain end up in cs1|2, and fix the articles that use them. None of this is urgent as long as the smashedtogether variants are supported, of course. David Brooks (talk) 04:19, 1 December 2020 (UTC)

  Reconsideration overnight: First, I used the term transclude too loosely above. I meant templates that are simply shorthand for a specific book and have a hardwired |authorlink=, as opposed to those that call {{cite book}} with parameters passed through. More significantly, I guess {{cite book}} was not a great example, because it is not likely that users will override the specific author. More likely cases: templates that wrap {{cite encyclopedia}} or {{cite journal}}. An example of the former is {{New Cambridge History of Islam}}, which needs to recognize |author-link= before fixing its callers. I only did a shallow dive to show this pattern is non-zero. David Brooks (talk) 14:38, 1 December 2020 (UTC)

  Yes, both are good points but are already on the radar, I think, although perhaps more in a manner of an ad-hoc approach rather than systematically planned. As far as I have seen it, what we have done in the past is mostly to fix up the call down to CS1/CS2 (thereby ensuring that the templates continue to work after a switch) and leave it to the maintainers of these non-CS1/CS2-wrappers to adjust the article-facing side of parameters as they see fit. To achieve maximum consistency across the project it probably makes sense to help them by running bots tasks to fix up their parameter uses as well, but we have plenty of time for that.

  --Matthiaspaul (talk) 15:38, 1 December 2020 (UTC)

  I did some experimentation yesterday with a variant of Monkbot task 18 (namespace restriction limit lifted and the empty positional parameters subtask disabled). The experiments that I did yesterday suggest that task 18 in its limited form can successfully edit many of these kinds of templates. This search finds about 3300 templates that use {{cite book}}. Similar numbers for {{cite news}}, {{cite journal}}, and {{citation}} but not for {{cite encyclopedia}} (142).

  —Trappist the monk (talk) 15:37, 2 December 2020 (UTC)

  Thanks for the suggested search terms. Using that as a basis, I found that {{Cite encyclopedia}} has just 6 customers with {{{authorlink but no mention of author-link. So the potential fixups are getting more tractable. David Brooks (talk) 16:28, 2 December 2020 (UTC)

  There appear to be about 13,000 templates that contain "accessdate=", typically in a CS1 template inside the template. At some point in this long process, preferably before we start categorizing pages with unhyphenated parameters, Monkbot or someone else with an approved BRFA will probably need to run through those templates. – Jonesey95 (talk) 15:58, 3 December 2020 (UTC)

  I didn't look at accessdate, but it's the case that authorlink is often hard-coded in a template's code to refer to a particular book, rather than being passed down to CS1. For example, that's true of the first one that came up in that search, {{Taxonomy/Lepidoptera}}. No reason not to fix them, but as they aren't visible to regular editors they may be less urgent - if they could be distinguished easily. David Brooks (talk) 16:43, 3 December 2020 (UTC)

  |authorlink=? Did you mean |accessdate=? It is those kinds of cs1|2 templates-within-templates that task 18 can fix. It will not be able to fix cases where the wrapper template accepts/requires |accessdate= as an input:

  |accessdate={{{accessdate|}}}

  might be able to fix the lvalue and maybe, with some tweaking (don't hold your breath) might fix simple rvalues like my example.

  —Trappist the monk (talk) 17:16, 3 December 2020 (UTC)

  Yes, I meant |authorlink=, which I had looked at in a little detail, and just inferred that |accessdate= could have similar characteristics. Thanks for the clarification. David Brooks (talk) 17:44, 3 December 2020 (UTC)

• Something I thought about: when the time comes (say, the next update), should we create a category like Category:CS1 maint: uses non-hyphenated parameter names to track remaining uses of the parameters in question, regardless of whether they are currently deprecated? Since it's a maintenance category, this would only be visible to users who have opted in to seeing these messages anyway. -BRAINULATOR9 (TALK) 02:49, 2 December 2020 (UTC)

  Were we to do that today, we would create an enormous category of some 2.7 million articles. This search finds that many for |accessdate=. I'm not at all sure how useful that will be.

  —Trappist the monk (talk) 15:37, 2 December 2020 (UTC)

I think that the sense of the above discussion is that we are going to deprecate all nonhyphenated parameter names. As of the time I write this, Monkbot task 18 has made more than 125,000 edits. About half of those edits included the |accessdate= → |access-date= fix. Those 125k edits were made to a broad variety of articles so likely are included on thousands of watchlists. There have been 22 reverts (0.0176%). Given all of this, I intend to restore the |accessdate= → |access-date= fix to minimize the number of articles that Monkbot must revisit.

—Trappist the monk (talk) 14:53, 3 December 2020 (UTC)

Is it possible that this bot activity changed the parameter name in "old" templates that don't recognize access-date? David Brooks (talk) 16:43, 3 December 2020 (UTC)

I don't know what you mean by "old" templates. The task's activities are constrained to edits inside the canonical 27 cs1|2 templates and some of their most commonly used redirects. All of the canonical cs1|2 templates invoke Module:Citation/CS1 so all of them accept both |accessdate= and |access-date=. Redirects, being redirects, simply take the round-about way to get to Module:Citation/CS1. Did I answer the question?

—Trappist the monk (talk) 17:08, 3 December 2020 (UTC)

Yes, you did, thanks. "old" meant those written in innocence of the newer hyphen-preference. David Brooks (talk) 17:44, 3 December 2020 (UTC)

And here's a fun one. {{

Schaff-Herzog cite}}. That redirects to {{Cite Schaff-Herzog}}, which (stop me if you've heard this before) recognizes only |accessdate= but presents it as access-date before passing to {{Cite encyclopedia}}, which invokes CS1. So there's no way of successfully representing the parameter, and the same blocked path attends |authorlink=. Sorry, just pointing out that while the 27 canonical templates are well-behaved, the rest of the ecosystem is a mess; there's no simple global fix. But I think everyone knew that. David Brooks (talk

) 22:39, 3 December 2020 (UTC)

I have fixed a lot of those kinds template pairs. It is a good use of Module:Template wrapper so I'll fix those templates.

—Trappist the monk (talk) 23:19, 3 December 2020 (UTC)

And fixed, I think,

—Trappist the monk (talk) 00:44, 4 December 2020 (UTC)

@Trappist the monk: The above discussion is definitely not a strong enough consensus to deprecate such a widely-used parameter; it's only been four days and participation is quite low. Suggest making this an RfC with appropriate publicity. Nikkimaria (talk) 02:52, 4 December 2020 (UTC)

The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intnet. We seem to have made the determination that yes, we intend to deprecate nonhyphenated parameters. But, I will wait a few more days until this discussion has been open a week to see if there is a change in our opinion.

—Trappist the monk (talk) 12:50, 4 December 2020 (UTC)

And I'm saying that, given the scale of this change, it shouldn't be left up to the small number of regulars on this page but should receive input from the wider community. What is your objection to that? Nikkimaria (talk) 13:47, 4 December 2020 (UTC)

Monkbot task 18 is closing in on 150,000 page edits. Each page that is edited is a poll of the editors who watch that page and so a poll of the wider community. Sure, it's likely that a portion of those pages are not being watched. The remainder are being watched. Every watcher in the wider community has the opportunity to revert the bot's edits. A very few (15 at the time I write this) have chosen to revert. The wider community's silence speaks quite loudly.

—Trappist the monk (talk) 15:05, 4 December 2020 (UTC)

See

WP:FAIT. Let's have a properly advertised and well attended discussion to establish real consensus for what you're proposing, rather than having your bot make this change without an established consensus and then pointing to revert-count as a substitute. Nikkimaria (talk

) 21:47, 4 December 2020 (UTC)

Not

WP:SILENT

.

—Trappist the monk (talk) 12:32, 5 December 2020 (UTC)

Making a mass edit without prior established consensus and then pointing to its persistence as evidence of consensus? Textbook FAIT. Have an actual RfC to get consensus for your proposed change, or don't make your proposed change at all. Nikkimaria (talk) 13:12, 5 December 2020 (UTC)

An edit is made, it is neither reverted nor changed. Text book

WP:FAIT

. Which prompts me to ... ad nauseum. Sigh.

—Trappist the monk (talk) 15:43, 5 December 2020 (UTC)

Not "an" edit. By your own count, 150,000 edits made without consensus. With objections from multiple editors. Nikkimaria (talk) 15:59, 5 December 2020 (UTC)

Trappist the monk, again: please start a well-advertised properly-run RfC. Editors have raised objections here and at your talk page, and even those supporting preferring hyphenated parameters have expressed concerns about aggressive bot-runs and removing functionality. A change impacting over a third of the articles on the site should have a stronger consensus behind it than what is seen here. Nikkimaria (talk) 22:06, 8 December 2020 (UTC)

Support most bot-assisted "aggressive" deprecation, but anything

b

} 17:28, 3 December 2020 (UTC)

That's an idea, though for |access-date= the scale is millions of articles, it could take years - even bot speed could take months. Years might not be a problem through patience and dogged determination, but in the mean time users are still adding new templates (est 5-10 thousand a week) creating churn - users adding, bots removing, spinning wheels. So the idea if I understand is to deprecate with a red warning message, but that can't be rightly done until most of the existing stock is removed since in the past when millions of red warning messages suddenly appear the community revolts and demands the problem be fixed before red errors flood articles. -- GreenC 18:12, 3 December 2020 (UTC)

I tried the "passive" [conversions] route by including |accessdate= → |access-date= in AWB genfixes but there was pushback; understandable because there are so many instances of |accessdate= that the genfix obfuscates the fixes that awb operators intend. I have since suspended that genfix.

—Trappist the monk (talk) 18:51, 3 December 2020 (UTC)

I support deprecation of unhyphenated multi-word parameters. I do not think we should show red error messages or put pages in any sort of tracking category until Monkbot has processed 95% or more of the estimated 2.7 million articles with such parameters. – Jonesey95 (talk) 18:30, 3 December 2020 (UTC)

Comment and neutral. I wonder why bot task 18 was approved in the first place. Consider task 18's function #5: hyphenates cs1|2 parameters when they are written using the to-be-deprecated all-run-together form. It is admitted above that "we have never actually declared an intent to deprecate and remove" those parameters so this description could be considered misleading. Second, "to-be-deprecated" means they are still valid so the choice of wording here is suspiciously imprecise for a multi-million article bot and was a hint that many this hasn't been scrutinized enough. I also question the wisdom of not recognizing that the widespread use of |authorlink= and |accessate= makes global changes to them important enough to warrant special treatment. I think sometimes it makes sense to unbundle big very specific changes from less specific umbrella tasks that have mostly a bunch of rare and non-controversial changes. I'd like to see the bots approval group lean towards more specific, smaller tasks in the future as the discussion above shows how valuable focused discussion just on just |accessdate= is. That said, I recognize the power of

WP:BE BOLD and don't want to discount the efforts of those who have the know-how and put in the work to keep Wikipedia evolving. For reasons related to both typing and reading source code, I have a preference for |accessdate= over |access-date= but since those editors actually working in this area are clearly against the un-hyphenated ones, I am fine with being neutral in regards to their deprecation or this bot making these changes. Jason Quinn (talk) 06:09, 4 December 2020 (UTC) (EDIT: Now oppose instead of neutral. Jason Quinn (talk

) 02:08, 6 January 2021 (UTC))

You should not be surprised that we have never actually declared an intent to deprecate and remove. We know our intent from the actions that we take, the code and the documentation that we write, etc. This discussion is about declaring our intent.

Yes, "to-be-deprecated" means they are still valid. These parameters are valid now and will be valid during the deprecation period until support for them is withdrawn. Given that support will be withdrawn, it is necessary to convert those nonhyphenated names to their hyphenated equivalents before deprecation so that we minimize the quantity of Cite uses deprecated parameter |accessdate= and similar error messages. Too many of those cause torches and pitchforks uprisings. It is precisely the recognition of the widespread use of some of these parameters that makes Monkbot task 18 important because when it comes time to deprecate these parameters, there will be far fewer error messages to distress editors.

If you have issues with

WP:BRFA

processes then you should take them up in the appropriate venues. This venue is not for those topics.

—Trappist the monk (talk) 12:50, 4 December 2020 (UTC)

Is it clear that parameters are not removed/deprecated? What is changing are parameter labels (names) aliases, marginally. All the software routines and module functions will be the same, and will result in exactly the same intended result. For prospective template editors, this is purely a minor nomenclature change to conform with the rest of the system, and one which I believe enhances clarity. It seems that most objections to this are along the lines of "we've always done it this way". 98.0.246.242 (talk) 00:01, 5 December 2020 (UTC)

• @
  dgaf
  )  15:44, 9 December 2020 (UTC)

  Alas, no. Because task 18 is a cosmetic task and because there was concern at the WP:BRFA that the community might rise against it, from the start I have been keeping track of the number of edits and logging each revert so that I could get a sense of what the community thinks. I have never felt the need to keep such statistics in the past. I have a sense that task 14 incurred more enmity than task 18 and involved 'only' 50k–75k' articles.

  Ah! this just in: For task 14 I kept a filter file that I could use to make awb remove articles from the lists that it created from cirrus searches. That list has 55 article titles. If, to be ultra conservative, we assume that task 14 operated on 100k articles, that gives a revert rate of 0.055% – 'hostile' reverts only, I did not keep track of reverts where the bot had edited vandalized articles or the I-don't-know-what-this-is-so-I'll-revert kinds of reverts or the inevitable drive-by reverts.

  As of this writing the revert rate for task 18 is 0.0145% (35 reverts in 241k edits). That includes all reverts, including those where the bot edited a vandalized page, etc.

  —Trappist the monk (talk) 17:06, 9 December 2020 (UTC)

Where are we on this? Everyone seems to have moved on and I'm not clear that all the outstanding questions are resolved.

The only RFC I'm aware of is the June 2014 resolution that only "All parameter names in Citation Style 1 templates" should accept hyphenated parameters; in addition, I think there is a consensus that documentation—narrative, examples, and TemplateData—should privilege the hyphenated versions. I believe both have been accomplished for the 26 or 23 (depending which list you consult, and I may have the wrong formal terms) canonical or "General use CS1 templates", but question 1: Is it still valid to use the nonhyphen versions in an example, if there are any such?

Remaining are the hundreds that wrap one of those templates, in particular those that recognize the parameters and pass them on (there are others that simply use a CS1 template internally to identify a single specific source). Are they included in the phrase "Citation Style 1 templates" in the RFC? If so, question 3: should there be a formal effort to identify those that don't recognize hyphens, and fix them? Some have been fixed recently but I think only because they were found using an incomplete search. Independently, question 4: should we make an effort to fix all the documentation, or will "fix them when you see them and have time" be OK for now, given that there is no agreement to formally deprecate the nonhyphen parameters? David Brooks (talk) 16:50, 14 December 2020 (UTC)

As I said above, there are many thousands of templates that contain |accessdate=. Not all of them are CS1 wrapper templates. It will probably be easiest to deal with them as follows: (1) Let Monkbot complete its run through affected articles, (2) put unhyphenated parameters in a maintenance category, which will allow us to catch templates, pages in other namespaces, and edge cases that the bot was unable to process, (3) process the pages in the maintenance category using a combination of bots and manual gnome work, (4) formally deprecate unhyphenated parameters in the module code, using the deprecated parameter category, and finally (5) remove support for the deprecated parameters. This process will probably take a year or more. – Jonesey95 (talk) 17:36, 14 December 2020 (UTC)

Sure, except (1) needs care, because there is no guarantee that every template, whether or not they end up in CS1, that accepts |accessdate= (etc) recognizes |access-date=. I guess the hunt through those that use CS1 could be automated pretty easily. David Brooks (talk) 22:40, 14 December 2020 (UTC)

• I oppose
  User:Monkbot/task 18
  at least temporarily until it's been discussed - this seems to be a large-impact task that didn't get much attention when it was approved, and is now causing consternation...

1. I thought AWB wasn't supposed to be used for purely cosmetic edits? Isn't DavidBrooks right that if it is done it should be with Toolforge instead of spamming everyone over millions of articles?
2. I don't see a need to get rid of especially |accessdate= which is so commonly used. A lot of editors prefer it, perhaps even most? What was the ratio of with and without the hyphen before Monkbot started "fixing" it?

··gracefool 💬 09:38, 15 December 2020 (UTC)

I don't think I mentioned Toolforge, not that it matters. My preference is only that we should first complete the work implied by the RFC, now well over 6 years old: permit hyphenated parameters and establish them as "normal" in documentation. Admittedly the RFC wasn't clear in its scope (26 canonical template or all their transitive callers?). David Brooks (talk) 23:57, 15 December 2020 (UTC)

• Comment. There should be no circumstance in which |accessdate= without the hyphen is ever deprecated. It should remain a valid alias. Plenty of users still create articles with citations that use the unhyphenated form, and if the goal is to inflict big ugly red error messages or just not display the date at all upon use of the unhyphenated form, I can't see how that's going to go down well or how it's even an appropriate remedy. There are claims this is for clarity, but who has ever said they were confused about what the unhyphenated form of |accessdate= means? Cosmetic, spam-like bot edits is all this is currently amounting to. I don't see the point of these edits. There will never be complete conformity on any issue like this on Wikipedia, and we should stop trying to force people to adapt when the old form has endured for years without any hassle. Ss112 13:42, 15 December 2020 (UTC)
• Comment. Per Ss112, and out of incredulity at the leeway cite template editors appear to be afforded, this ongoing wave of so-called cosmetic edits is spam-like; totally disruptive. I try to keep my watch list to a minimum, but even then, they're well-visited articles, and the mass (bot) activity can mask a whole range of unwelcome IP edits. What I can't figure out is why accessdate=, archiveurl=, p= (etc), was ever permitted if it's now deemed a major problem across the whole encyclopedia. Or the other way 'round: why it's suddenly a problem, after someone wayback-when allowed the unhyphenated/abbreviated forms, and editors acted accordingly and continue to do so. It's constantly upside down with this CS1/2 bollocks: it should be the cite templates serving article content, but it ends up that editors have to come here and ask a precious few what they're doing. Ask their permission, even. Which would be
  WP:OWN in every other circumstance. JG66 (talk
  ) 14:51, 15 December 2020 (UTC)
• Response. This is the page where the templated application of cs1/cs2, one of the non-compulsory citation formats (styles) is discussed. That is why people have to come here, if they want to join the discussion. And like any other restricted property in Wikipedia, suggestions must be submitted and edit requests must be made to those who are currently administering the particular areas. This is the norm; given the complexity of the cs1cs2 project, a necessity.

In Wikipedia, citations in general do not serve articles. They explicitly serve the Wikipedia verification policy, which may apply to individual articles, but impacts Wikipedia's standing in toto. Wikipedia, after all, is a project where pseudonymous persons? bots? pieces of scrapcode? calling themselves "JG66" or some easily faked machine network address, can find a platform for elaborate discussions on non-issues such as the temporary appearance of an error message regarding the rendering of an important, but non-vital parameter in an application of style that is a matter of choice.

Without easily verifiable citations (in any style) anything in main space is garbage, worthy of any inane handle it is edited under. To repeat: citations do not serve articles. They are not around to make your article look good, or complete. They are there to take your work out of the trash pile, and establish it as fact. Otherwise, there are many platforms one can publish fiction at.

In any case, I believe that good arguments have been made for this particular change, including the argument that separating madeup compound terms enhances clarity and it is not simply cosmetic. 66.65.114.61 (talk) 20:10, 15 December 2020 (UTC)

I don't think it's clear at all that adding hyphens enhances clarity. It seems to me that the argument that it decreases the readability of templates is equally strong. ··gracefool 💬 21:42, 15 December 2020 (UTC)

At first glance, imo "access-date" is more readable and clear than "accessdate". I believe this to be so for any such compound term, but more so for the ones that have uncommon usage. 107.14.54.1 (talk) 22:33, 15 December 2020 (UTC)

• Comment Wikipedia is becoming ever more complex. Simply reduce complexity where possible: standardize, remove duplication. Humans vs. entropy. -- GreenC 04:18, 16 December 2020 (UTC)
• Comments (1) Alternatives (aliases) in templates don't inherently increase complexity for editors using the template. New editors can be steered to one form; old editors can continue to use the form they would normally. They do increase complexity for template maintainers – and I speak from experience because currently I do most of the maintenance of the automated taxoboxes. (2) What's readable depends on what you are used to. As a programmer, "accessdate" looks right to me as a parameter name, "access-date" looks wrong, as it wouldn't be allowed as a variable name in any of the computer languages I use. I have no objection to "accessdate" being deprecated; I do object to it being treated as an error. Peter coxhead (talk) 06:54, 16 December 2020 (UTC)

Technically, we are discussing a minor element of the edit window user interface, not the way parameters are set in code. 69.94.58.75 (talk) 14:12, 16 December 2020 (UTC)

Those maintaining software are also editors and users, who go to great lengths to make things easy for non-technical users where possible even to the point of creating a system that becomes overly complex with time. This impacts everyone who parses wiki text which includes bots, templates, researchers, etc.. a large and diverse community. FWIW it's not technically a variable but a key/value pair of a data object, and it depends what the data structure is, for example an associative array can do spaces eg. citation["cite book"]["access date"] = "2020-12-16" -- GreenC 15:33, 16 December 2020 (UTC)

• I oppose User:Monkbot/task 18: cosmetic cs1 template cleanup. There are several reasons:
  • Per gracefool, AWB isn't meant for cosmetic edits. Seems like a less invasive approach should be used, like Toolforge (per GreenC) Or, maybe this is a secondary task -- done on articles that are being edited for other fixes, but not only for this change.
  • There just isn't any real benefit; deprecating hyphenated parameter versions delivers little to no value. "Improve consistency" doesn't give any tangible improvement. Everything already works, and there's little compelling reason to change it. The change forces humans and tools to re-learn. And, for what?
  • There's substantial risk. Since Monkbot doesn't test its edits to see if they introduce problems, it leaves behind duplicate citation definitions in dozens (so far, manually counted) of articles. This negative side-effect wasn't previously considered here and must be addressed.

Further, the task (which is presently running) should be paused until the community's concerns are addressed. -- Mikeblas (talk) 18:08, 24 December 2020 (UTC)

• I too oppose these edits. It is a solution to a problem that does not exist. I've not seen the bot owner give a clear, conscise, non-technical succinct reason to WHY this is needed. There's just line after line of techno-guff that is TL/DR and not helpful. Lugnuts ^{Fire Walk with Me} 10:33, 30 December 2020 (UTC)

  If there is something that I have written that you do not understand, why have you not asked me to clarify?

  —Trappist the monk (talk) 13:35, 30 December 2020 (UTC)

I've already done so. So, without reams of text, a nice succinct answer to: what are the point of these cosmetic changes? I see little to zero value in adding a hyphen for the sake of adding a hyphen. Lugnuts ^{Fire Walk with Me} 14:32, 30 December 2020 (UTC)

@

WP:IDHT mentality. Please stop the bot until the issues have been addressed. Thank you. Lugnuts ^{Fire Walk with Me}

14:41, 30 December 2020 (UTC)

@

dgaf

)  14:59, 30 December 2020 (UTC)

Please

WP:AGF, Tom. When you ask someone to stop running a bot, and take part in this discussion, you'd expect any reasonable person to do just that. Why would they ignore THREE messages? It's not just me who have raised concerns (per the above comments). Trappist gave a filibuster response and has not taken part in any further discussions. Thanks. Lugnuts ^{Fire Walk with Me}

15:03, 30 December 2020 (UTC)

No comment on the rest of this, but I think Trappist has been quite responsive here and elsewhere regarding this task, noting also that he is a volunteer like the rest of us and this is holiday season, and a lot of the concerns are repetitive. The link you sent it appears Trappist replied in length to your concern. 'Communication' doesn't mean he should badger every single comment in this section, even if not addressed for a response from him. ProcrastinatingReader (talk) 16:09, 30 December 2020 (UTC)

Lugnuts, recommend disable bot notifications even temporarily. In two weeks you created 520 articles, as you have done for years. At

WP:NOA you are ranked #3 (#2 soon) most articles ever created on Wikipedia. Undoubtedly your watchlist is seriously lit up, assuming you watch all those article. Consider you are far outside the norm and take measures to deal with it. The problem is that instead of having citations in a database, where they belong, they are embedded directly in the wikitext itself. This is poor design, everyone knows it, it creates endless problems like this minor metadata change that causes endless needless human friction. But that is what we got, it evolved that way. Until something better happens we are all gonna need to work together with an architecture we got. -- GreenC

17:21, 30 December 2020 (UTC)

As others have pointed out, I did answer you at User talk:Trappist the monk § Bot consolidating access-date→accessdate with this edit. Your contributions history shows that you have been editing quite regularly between the time of your original post and today. How am I to know that you do not understand what I wrote if you don't take the trouble to respond to my writings?

Sometime, probably within the coming year, |accessdate= will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form. When that deprecation occurs, citation templates that the the bot touched will not show error messages. But, citation templates that the bot touched and were subsequently reverted like this one from And a Little Child Shall Lead Them will show an error message:

{{cite web |url=http://www.silentera.com/PSFL/data/A/AndALittleChildShallLe1909.html |title=And a Little Child Shall Lead Them |accessdate=February 13, 2015 |work=Silent Era}}

"And a Little Child Shall Lead Them". Silent Era. Retrieved February 13, 2015. Cite uses deprecated parameter |accessdate=(help) – error message is a mockup

The bot's edits prevent the unnecessary error messages that will occur when |accessdate= is deprecated.

Because the bot's edit at And a Little Child Shall Lead Them has been reverted, I have added that article to the bot's skip-list. The bot will not visit it again.

—Trappist the monk (talk) 18:07, 30 December 2020 (UTC)

Sometime, probably within the coming year, |accessdate= will be deprecated as part of our move to consolidate all multiword parameter names to the hyphenated form. Where have you established consensus for that? It certainly hasn't been demonstrated in this thread. Nikkimaria (talk) 19:01, 30 December 2020 (UTC)

• Comment this is totally a drive-by comment, but it is really annoying to have Monkbot pop-up in my watchlist a million times just to find out each time it is just adding two hyphens to a template parameter that doesn't change anything for the reader or editor. If the parameters get deprecated, then this seems like a simple task for a bit to fix to limit the dreaded error messages. But until that does get deprecated, it is a solution without a problem. This may be a good idea (on the face, it seems like it is), but that is no reason to just proceed without consensus. I doubt anyone minds Monkbot fixing these parameters when it edits an article for another reason, but just editing an article for this reason, especially when we are talking 150k+ articles requires consensus.
  « Gonzo fan2007 (talk)
  @ 21:37, 30 December 2020 (UTC)

• Comment I want to second
  User:Gonzo_fan2007 on the annoyance of Monkbot in the watchlist just making hyphen changes. Given the concerns that have been raised, consensus should be reached before the bot continues. Sariel Xilo (talk
  ) 18:27, 1 January 2021 (UTC)
• Agreed. Clogging up everyone's watchlists with numerous changes that make literally no difference to the article is disruptive and pointless. I'm getting fed up of checking all these diffs only to discover they're just non-visible hyphen changes, for no good reason. Making parameter hyphens consistent might be appropriate as part of a more substantive edit, but on its own it's
  WP:ABDF. Modest Genius ^talk
  11:49, 5 January 2021 (UTC)

FWIW, to both, see

WP:HIDEBOTS ProcrastinatingReader (talk

) 12:30, 5 January 2021 (UTC)

• Oppose deprecation. It's easier to type and remember "accessdate", and no one has explained why it might cause a problem. SarahSV ^(talk) 02:38, 6 January 2021 (UTC)

I saw in the archive that this has been touched on in the past. I would like to see if there is a possibility of adding |illustrator-last= and |illustrator-first= to the template cite book. An example where I see the need is for

Recommend |contributor-last=Eyre |contributor-first=John |contribution=Illustrator |contributor-link=John Eyre (British artist) -- there are many contributor roles which come to mind: illustrator, cover artist, cover designer, forward, introduction, narrator, photographer, preface, translator. If there are multiple contributors, not sure how that works of contribution and contributor-link support > one. -- GreenC 14:36, 19 December 2020 (UTC)

Actually the above does not produce expected results:

Eyre, John. "Illustrator". Pickwick Papers. By Charles Dickens.

How about this:

Charles Dickens. Pickwick Papers. Illustrated by John Eyre. Narrated by Simon Vance.

-- GreenC 14:49, 19 December 2020 (UTC)

(edit conflict)

No. Do not do that. |contribution= is an alias of |chapter= and is rendered in the citation in the same way that a chapter is rendered and is included in the citation's metadata as &rft.atitle=Illustrator. Do not corrupt the citation's metadata.

{{cite book|title=Pickwick Papers|author=Charles Dickens|contributor-last=Eyre|contributor-first=John|contribution=Illustrator|contributor-link=John Eyre (British artist)}}

'"`UNIQ--templatestyles-00000040-QINU`"'<cite id="CITEREFEyre" class="citation book cs1">[[John Eyre (British artist)|Eyre, John]]. "Illustrator". ''Pickwick Papers''. By Charles Dickens.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Illustrator&rft.btitle=Pickwick+Papers&rft.aulast=Eyre&rft.aufirst=John&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+74" class="Z3988"></span>

|others= is where other contributors go so |others=Illustrations by [[John Eyre (British artist)|John Eyre]]

{{cite book |title=Pickwick Papers |author=Charles Dickens |others=Illustrations by [[John Eyre (British artist)|John Eyre]]}}

Charles Dickens. Pickwick Papers. Illustrations by John Eyre.

—Trappist the monk (talk) 14:58, 19 December 2020 (UTC)

Typically a citation would look like this:

Charles Dickens, John Eyre (illustrator). Pickwick Papers

But I don't see how to achieve that. -- GreenC 15:19, 19 December 2020 (UTC)

Trappist the monk, GreenC, that looks good! Thank you both. Jacqke (talk) 15:37, 19 December 2020 (UTC)

So, we are again at this discussion: "Others" further up on this page. ;-)

What can be drawn from this is that there are two general types of contributors, those who should be listed in front of the title (because they are the subject of a particular citation), and those who should be listed after the title (for completeness/relevance):

For the first type, we currently have |contribution= together with |contributor-last/first=, which works quite good for as long as only one type of contribution needs to be mentioned and it is okay to list it in front of the citation (and include them in the metadata).

For the second type, which IMO is the more common and more important one, we currently only have |others= requiring manual free-style formatting. This latter type should be expanded to allow to specify multiple names by their last and first names and their roles to let the template format the output according to our preferences. In the other thread I gave examples how to possibly combine this with the |contributor-last/first= parameters utilizing a new |contributor-role= parameter. Alternatively, |others= could be expanded to the same effect (|other-last/first= and |other-role=), but the parameter name is not particularly meaningful.

Yet another alternative would be to add parameters for the most common contribution roles. According to some style guides, illustrators come right after translators, and in front of foreword- and afterword writers. These are the most important ones, but there are yet more standard roles used in some citation style guides, and as there are too many to have parameters for all of them, a general solution seems more appropriate.

--Matthiaspaul (talk) 21:34, 20 December 2020 (UTC)

I propose to update cs1|2 module suite over the weekend 9–10 January 2021. Here are the changes:

Module:Citation/CS1:

• support for |editors= withdrawn; discussion
• support for |ignore-isbn-error=, |lastauthoramp=, |last-author-amp= withdrawn; discussion
• support for |nocat= withdrawn; discussion
• extra text for edition and pages test now emit two separate categories, and are promoted to errors; discussion
  • also detect the British abbreviation "[Ee]dn[.]" in extra-text detection for |edition= parameter; discussion
  • add "pg(s)(.)" pattern to extra text test for |page(s)=, also test |quote-page(s)=;
• fix Wikisource title handling; discussion
• add ((accept-this-as-it-is)) support for |quote-pages= in analogy to |pages=; discussion
  • fixed local/global ((accept-this-as-it-is)) syntax in hyphen_to_dash; adjusted |volume= evaluation accordingly for all cite types;
• "escape" nbsps in multiple names check; discussion
• i18n; category wikilink name moved to ~/Configuration; discussion
• replace double/triple-hyphen (as found in some BibTeX entries) in page ranges with en/emdash
• add |quote-page(s)= to metadata if none of the other page-related parameters was used; discussion

Module:Citation/CS1/Configuration:

• support for |editors= withdrawn;
• support for: |authormask=, |displayauthors=, |editorlink=, |ignore-isbn-error=, |subjectlink=, |authormask#=, |author#mask=, |editorlink#=, |editor#link=, |subjectlink#=, |subject#link=, |lastauthoramp=, |last-author-amp= withdrawn; discussion
• support for |seriesnumber=, |event-format=, |event-url=, and |eventurl= withdrawn; discussion
• support for |nocat= withdrawn;
• consistent error/maintenance category names; discussion
  • proper capitalization of identifier abbreviation "Zbl" in Category:CS1 errors: Zbl and Category:CS1 maint: Zbl
• correct missing SSRN from "ssrn" to same as bad SSRN which is "SSRN"
• extra text for edition and pages test now emit two separate categories, and are promoted to errors;
  • add 'et alii' and 'et aliae' variants to "et al." detection;
• add script language codes ky, te, ti;
• i18n; category wikilink name moved from Module:Citation/CS1/sandbox;
• reduce PMC suffix from single space character to empty string to avoid pending space in COinS metadata
• add id_limit to OCLC, OSTI and RFC for Module:cs1 documentation support; discussion and discussion
  • fix broken links with spaces in label by encoding JSTOR id;
  • error message support for |rfc= and |osti=;
• add   to "et al", "edition", "section"', "sections" messages to avoid wrapping; discussion
• add double-bracket variant to "et al." detection to avoid its only partial removal;
  discussion
• add 'Subscribe to read' to list of generic titles; discussion
• unhide unknown-empty parameter error message; discussion
  • prevent error categorization of log and archive pages;

Module:Citation/CS1/Whitelist:

• support for |editors= withdrawn;
• support for: |authormask=, |displayauthors=, |editorlink=, |ignore-isbn-error=, |subjectlink=, |authormask#=, |author#mask=, |editorlink#=, |editor#link=, |subjectlink#=, |subject#link=, |lastauthoramp=, |last-author-amp= withdrawn;
• support for |seriesnumber=, |event-format=, |event-url=, and |eventurl= withdrawn;
• support for |nocat= withdrawn;
• |conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |seriesno=, |sectionurl=, |timecaption=, |titlelink= deprecated; discussion

Module:Citation/CS1/Identifiers:

• support for |ignore-isbn-error= withdrawn;
• error detection support for |rfc= and |osti=;
  • change lower OSTI limit from 1 to 1018;
• add error detection (http(s):// and spaces) for |jstor=;
• catch non-digit & non-dot chars in doi registrant; discussion

Module:Citation/CS1/Utilities:

• simplify piped wikilinks in make_wikilink() where link and label are the same; discussion

Module:Citation/CS1/COinS:

• (not currently needed but) add missing suffix catenation to identifier links; discussion
  • indicate identifier name as transparent #fragment to rft_id URLs for those identifiers which have no predefined info or rft type;

Module:Citation/CS1/Suggestions:

• Add hints for removed parameter |editors=;
• Add hints for removed parameters |displayauthors=, |ignore-isbn-error=, |last-author-amp=, |lastauthoramp=, |authormask=, |authormask#=, |author#mask=, |editorlink=, |editorlink#=, |editor#link=, |subjectlink=, |subjectlink#=, |subject#link=;
• Added hints for removed parameters |ASIN-TLD=, |registration=, |subscription=;
• Added hints for removed parameter |nocat=;
• Added hints for Brazilian citations; discussion
• Added hints for Turkish citation templates;

—Trappist the monk (talk) 17:32, 3 January 2021 (UTC)

@Izno: In Module:Citation/CS1/Configuration/sandbox both of err_extra_text_edition and err_extra_text_pages have hidden = true. Why? Copy/pasta oversite?

—Trappist the monk (talk) 17:52, 3 January 2021 (UTC)

Yes, feel free to fix that. --Izno (talk) 20:11, 3 January 2021 (UTC)

Caught one. --Izno (talk) 06:23, 6 January 2021 (UTC)

+1 --Matthiaspaul (talk) 15:38, 7 January 2021 (UTC)

The citation indexing in Mortimer Taube is rather poor, which is highly ironic. I'm trying to improve this, but ran into a problem. How do I list multiple editors in an encyclopedia? editor_first1 et all does not appear to work and no alternative is listed on the template help page. Maury Markowitz (talk) 13:51, 7 January 2021 (UTC)

|editor-first=, |editor-firstn=, |editor-last=, |editor-lastn=, |editor=, and |editorn=; underscore-separated parameter names are not supported. See Template:Cite encyclopedia § Editors

—Trappist the monk (talk) 14:02, 7 January 2021 (UTC)

We catch a few of these through our parameter suggestion system, but if this would be a more common mistake, we could add a dedicated error message for parameters with underscores or spaces.

--Matthiaspaul (talk) 15:09, 7 January 2021 (UTC)

I have been working on the maintenance backlog for a wikiproject and a significant number of the issues are "CS1 errors: missing periodical". In a majority of cases, the fix is obvious, e.g. use cite book instead, or add the journal name. However, a minority are coming from "cite document" which is basically as far as I can see a wrapper to cite journal. The problem with this is that it is not obvious to editors that if you use a template called "document" you need to add the journal field. Some examples of its use for generic documents can be found on the A30 road page. The talk page for this template states "This template is used when a bot needs to switch from the Citation format to the Cite xxx format, but cannot deduce whether the source is a book, newspaper or other document" but if the source is a book or a newspaper, then there won't be a journal field either, so this is a problem for that use case as well. Can anyone suggest a way forward here please?--NHSavage (talk) 09:22, 9 January 2021 (UTC)

The documentation at Help:Citation Style 1, and for the individual CS1 templates, says that |url-access=limited means that, besides registering on some website, there are other constraints (such as a cap on daily views) to freely access this source, while the tooltip on the lock icon that |url-access=limited produces says Free access subject to limited trial, subscription normally required.

These descriptions of the meaning of |url-access=limited don't seem equivalent to me. For example, having a free account on Archive.org lets one "borrow" a book, but (for many books) one must wait to do so until there is a copy of the book available (not borrowed by someone else). If such a book is used as a source, I would understand this simulation of a physical library to create an other constraint besides registration to freely access this source, so, according to the documentation, |url-access=limited applies. On the other hand, the Archive.org account is not merely a free trial, and (as far as I'm aware) there is no "full subscription" one could buy to bypass the constraint, so, according to the tooltip, |url-access=limited does not apply.

Could the intent of |url-access=limited be clarified?

Thank you, —2d37 (talk) 13:53, 6 January 2021 (UTC)

The tooltip message is limited to trial and subscription only. It could be broadened. For example it could say Free access limited eg. trial, subscription, registration, or cap on views. The "eg." (or "for example") means these are not a complete set of reasons but are typical. -- GreenC 14:01, 6 January 2021 (UTC)

A viewcap limit is a limited trial, so they're already covered by the 'limited trial' part. But no objections to listing view caps separately, since that can make things clearer for some people.

b

} 17:24, 7 January 2021 (UTC)

I don't think a viewcap limit necessarily entails a trial, despite that it does so in what I imagine is an archetypal example of such a limit, a newspaper's website's allowing a user to read some limited number of articles per month for free and offering a paid subscription for full access. Literally, I suppose the case of books at Archive.org involves a cap on views (not limiting a user to viewing some number of articles but limiting a book to being viewed by some number of users), but there's no trial in that case; as far as I know, one can't buy unlimited access to the Archive's books. —2d37 (talk) 10:12, 8 January 2021 (UTC)

To try to see how these parameter values are used in practice for Archive.org URLs, I went through many, many

WP:RANdom articles until I found four that cite books on Archive.org: in the order I found them, Hemileuca neumoegeni, Rosario Weiss Zorrilla, Service-oriented architecture, and Gerard J. Milburn. I would have gone for more, but the search was too tedious. Of these four articles, the first two use |url-access=registration, which gives the true but incomplete description "Free registration required", and the second two use |url-access=limited, despite that the tooltip produced thereby speaks inapplicably of trials and subscriptions. I realize that my sample size here is terribly small; if it's interesting, perhaps someone familiar with running bulk queries against Wikipedia could get better data. —2d37 (talk

) 10:59, 8 January 2021 (UTC)

The |url-access= parameters appear to have been added to all four of those articles by InternetArchiveBot and/or GreenC bot:

registration:

• Hemileuca neumoegeni – 19 December 2019 (v2.1alpha3)
• Rosario Weiss Zorrilla – 7 September 2019 (v2.1alpha3)

limited:

• Service-oriented architecture – 14 June 2020 (v2.0.1) (GreenC bot)
• Gerard J. Milburn – 28 May 2020 (v2.0) (GreenC bot)

Which of the bots is actually responsible for an edit when both bots are named isn't exactly clear. Nor is the versioning clear: the older edits have numerically greater version identifiers than the newer edits. Regardless, if I understand you, your complaint suggests that the IA/GC bot pair isn't using the correct value for |url-access= but when IA bot is operating on its own, |url-access= gets the correct value. It would seem to me that you should raise this issue with the bot operators and not here.

—Trappist the monk (talk) 14:34, 8 January 2021 (UTC)

I meant no complaint in that comment. I hadn't been thinking of bots at all; in opening this thread, my intent was to request clarification of how I, as a human editor, should choose a value for |url-access=. If there were necessarily an implicit complaint in my original post, it was that the documentation for |url-access=limited seems inconsistent with the tooltip that it produces. —2d37 (talk) 09:18, 9 January 2021 (UTC)

The books marked limited have more restrictions than those marked registration. I suppose there are at least 3 levels of restriction at archive.org and 4 or 5 levels at Google Books. -- GreenC 03:24, 9 January 2021 (UTC)

Indeed, I wasn't paying enough attention and failed to heed how some books at Archive.org have more restrictions: not normally available for borrowing at all but only to patrons with print disabilities. Perhaps offtopically, I wonder whether, given that restriction, Google Books previews (where available) should be preferred for those citations' URLs. —2d37 (talk) 09:38, 9 January 2021 (UTC)

The entire book is only available to borrow for disabled patrons. But previews, like Google, are available to everyone. Google does not allow borrowing entire books for disabled or anyone unless PD of course. -- GreenC 15:52, 9 January 2021 (UTC)

At least for the three books cited at Service-oriented architecture and Gerard J. Milburn, Archive.org gives a preview of 11 'pages' (including the cover), in no case extending past the table of contents. I see now, though, that the corresponding Google Books previews, though more extensive, are not as extensive as I had thought they were, and I realize now that the choice of which to use for |url= is made less significant because of how the ISBN links to many different BookSources. —2d37 (talk) 08:06, 10 January 2021 (UTC)

This is a follow-up to Help_talk:Citation_Style_1/Archive_73#ISBN_line_breaks, which got archived before consensus became fully clear. I continue to believe that it would be beneficial to wrap ISBNs in {{nowrap}}, which would prevent line breaks like the one in the screenshot (that appears for Chrome; issue does not seem to manifest on Firefox). Because ISBNs are quite short, I do not see any significant downside; one would have to have an insanely narrow screen width to run into any issues. Can we decide if we're ready to implement? (Please note that the space between "ISBN" and the ISBN itself is already non-breaking; it is just the hyphens within the ISBN that are at issue.) {{u|Sdkb}} ^talk 14:49, 9 January 2021 (UTC)

• My opposition remains the same. There was a separate request elsewhere about possibly making the IDs easier to target in CSS for personal use. You could today take care of this for yourself if you dislike it in CSS with something like .citation a[href*="BookSources"] { white-space: nowrap }. --Izno (talk) 15:42, 9 January 2021 (UTC)

  Izno, your opposition, as I understand it, is that no-wrapping can sometimes lead to a worse experience on mobile, where there need to be more line breaks. I thought Matthiaspaul at the original discussion and myself above addressed that concern, though.

  And I appreciate the CSS hack, but I'm seeking this for readers, not just for myself, so my interest in something that only applies to me is about 1⁄number of readers that of a global fix. {{u|Sdkb}} ^talk 14:44, 11 January 2021 (UTC)

  And I am telling you that it is a personal preference not to wrap this strings, for which the appropriate remedy is personal CSS.

  No, you (plural) didn't address the concern in question. "Dedicated" browsers are a fantasy in this day and age (in fact, with decreasing diversity in the browsers served; Chrome owns 70-80% of the market and hasn't stopped growing in a decade), and skins are irrelevant to the question. As for particular strings, it's a microoptimization for display that would increase the template expansion size to boot, which of course impacts our largest articles worst. --Izno (talk) 17:04, 11 January 2021 (UTC)

Furigana#References has a reference which contains {{ruby}}, which is an instance of Ruby character content. I can replace the template (which uses templatestyles) with the associated HTML. Is that reasonable for metadata et al? --Izno (talk) 19:33, 9 January 2021 (UTC)

cs1|2 is good for most citation needs but cannot be (will never be) <announcer voice>the-prefect-solution-for-all-of-your-citation-needs</announcer voice>. Perhaps the best solution is to hand-write those citations; their use in that article appears to be as examples of Furigana in use.

—Trappist the monk (talk) 15:27, 11 January 2021 (UTC)

I'm just gnoming away some TemplateStyles strip marker errors and that didn't have an obvious fix to me. You didn't answer the actual question. :) --Izno (talk) 16:46, 11 January 2021 (UTC)

I thought I did: Perhaps the best solution is to hand-write those citations

—Trappist the monk (talk) 16:47, 11 January 2021 (UTC)

Is that reasonable for metadata et al?, for which I would have expected "yes, go ahead and use the raw HTML and the template will be fine" or "no, seek another solution, such as removing the ruby annotation or rewrite it". You will find no answer on that specific question in your responses. :) --Izno (talk) 16:56, 11 January 2021 (UTC)

Pretty sure that Perhaps the best solution is to hand-write those citations is the answer to the specific question because implicit in hand-write is: no, seek another solution.

—Trappist the monk (talk) 19:24, 11 January 2021 (UTC)

I do not really see why you were obtuse about it. --Izno (talk) 01:30, 12 January 2021 (UTC)

Ideally, this question would be answered by people from the Far East who have every-day-experience with Furigana and Ruby characters. Our goal here is to somehow "make work" everything that is not an error and leave it to the editorial judgement of the article authors to decide if Furigana/Ruby annotation is useful in a citation or not, instead of imposing our preferences on them.

Assuming that parties consuming our citation metadata are capable of displaying/processing Far East scripts, they shouldn't have problems to cope with Furigana/Ruby stuff in principal as well (at least when provided in raw form). Its presence may also help screen readers.

If that would still cause some error message to occur, perhaps the best solution to address this at present is to add this to |title=((...)) as well - similar to what is proposed in Help_talk:Citation_Style_1#Modifier_being_recognized_as_zero_width_joiner.

--Matthiaspaul (talk) 01:24, 12 January 2021 (UTC)

These 50 pages have manual invocations of CS1 categories that need to be converted from "Category" to ":Category" inside their brackets. If anyone has a quick script that can fix them, go for it. I fixed a half-dozen of them, but it's tedious. – Jonesey95 (talk) 23:37, 9 January 2021 (UTC)

GoingBatty, could this be handled by your bot's Task 9? The cats in question are all subcategories of Category:CS1 errors. – Jonesey95 (talk) 02:24, 11 January 2021 (UTC)

@Jonesey95: Funny you should ask - I'm just restarting this task after a long time without running it.  Doing... GoingBatty (talk) 02:36, 11 January 2021 (UTC)

@Jonesey95:  Done! GoingBatty (talk) 02:48, 11 January 2021 (UTC)

X.

That happens because of this edit. @Editor Matthiaspaul: Why did you do that?

—Trappist the monk (talk) 14:43, 10 January 2021 (UTC)

Thanks for reporting this. Damn, that we didn't saw this just a little bit earlier... Per Help_talk:Citation_Style_1/Archive_73#URL_in_identifier and [2], this was a fix for an existing bug with broken links for JSTORs containing spaces spotted while adding the new plausibility tests to the JSTOR code. The temporary hotfix now is to set encoding back to false in the live code while devising a better solution for the next update. Trappist, can you do this, please? Thanks. --Matthiaspaul (talk) 15:46, 10 January 2021 (UTC)

Are there legitimate jstor identifiers that include space characters?

—Trappist the monk (talk) 15:57, 10 January 2021 (UTC)

I don't think so. --Matthiaspaul (talk) 16:22, 10 January 2021 (UTC)

Thanks for switching it back. For illustration, here are two examples of the issue for why this was changed:

• {{cite book |title=Title |jstor=141 294}}

Title.

JSTOR 294 141 294. {{cite book}}: Check |jstor= value (help

)

• {{cite book |title=Title |jstor=141dfdfdf29 4}}

Title.

JSTOR 4 141dfdfdf29 4. {{cite book}}: Check |jstor= value (help

)

Since the spaced value is broken anyway, this is not a serious problem, but even an invalid JSTOR should ideally be displayed (and linked to) correctly.

--Matthiaspaul (talk) 16:36, 10 January 2021 (UTC)

Straw poll: make publication-date and publication-place full synonyms... to date and place/location respectively. Publication-place and location are used only some 600 times in conjunction (see Category:CS1 location test). I anticipate publication-date and date have similar numbers (the first several in this search look like they are being used as synonyms, and at least one or two misuses of publication-date). Anything so little used does not need full support in the module. --Izno (talk) 02:43, 11 January 2021 (UTC)

|publication-place= and |location=/|place= are not aliases, and shouldn't be treated as such. Publication place and written-at location are two independent properties of a source, and while it is true that they are seldomly both relevant and given at the same time (hence the low numbers), sometimes they are relevant and it would be counter-productive for readers as well as for machine-readability to not distinguish between them any more. It would weaken the quality of information in references. While the parameter name |publication-place= is perfectly descriptive already, the parameter name |location=, unfortunately, is not. Therefore, I propose a semantically more descriptive name for it like |written-at-place=, |written-place=, |writing-place=, |write-place=, |creation-place= or something else along that line following our modern naming conventions of adding more descriptive parts of parameter names on the left side of a parameter. Afterwards, the |location= parameter could either be left as it is or be faded out slowly, probably a process that would take several years to finish as each usage would have to be checked manually and the parameter replaced by either the written-at or the publication place parameter.

Regarding |publication-date= and |date=, we should analyze what other typical types of dates are referred to in various types of references and add dedicated and descriptive parameter names for them as well to improve machine-readability and allow for more meaningful and consistent output. At present, we have to put everything else into the |orig-date= parameter, which has no date format checking and cannot contribute to the metadata output. Using more descriptive parameter names would improve the situation.

--Matthiaspaul (talk) 04:26, 11 January 2021 (UTC)

|publication-place= and |location=/|place= are not aliases, and shouldn't be treated as such. You are incorrect and continue to be incorrect. They are only not aliases when they are used together, and that situation has a total of 600 uses. Total. Out of 5 million pages using this template. We do not and need not support the distinction.

Adding another alias to the pile only increases our alias count and is not worth our maintaining multiple ways to say "this is the place on the tin" (which wasn't necessary anyway internal to the citation). This suggestion is just another standard.

And no, we shouldn't invite our date parameters to the same idiocy.

Recommended use of the parameter set is and should be "publication place", with a user side fall back to another location if they do not have a publication place on hand (and they can choose to use place or location rather than publication-place, if they didn't already default to that). We have the evidence users don't need or care for the extra parameter. --Izno (talk) 13:04, 11 January 2021 (UTC)

"location", meaning the place of publication, is important for books, newspapers and magazines, though it is apparent that a lot of WP editors don't realise this, and leave it out. (In particular, the city of publication, and NOT the name of the publisher, is the standard means of disambiguating between different newspapers with the same name, e.g. there are several newspapers called The Guardian in different parts of the world.) I have only rarely come across people labouring under the misapprehension that "location" means "written-at", which is something one does not put in a newspaper citation, so I wonder if that isn't a bit of a red herring. -- Alarics (talk) 14:21, 11 January 2021 (UTC)

Publication place and written-at location are two independent properties of a source Yeah, that is true but irrelevant. Citation templates are not repositories for all possible properties of a source. For cs1|2, machine-readability is constrained to what COinS can support so a cs1|2 template with both of |location= and |publication-place= and both of |date= and |publication-date= emits metadata from |publication-place= and |date=; the other two are ignored.

—Trappist the monk (talk) 14:57, 11 January 2021 (UTC)

I would be generally supportive. I assume the value of publication-date or -place would be the winning value where |date= and/or |place= are also present. Be mindful of the fact that certain sources such as films, etc. may be classified by work date (date of production) by default, and would be much harder to find by publication date (date of exhibition distribution). 50.74.165.202 (talk) 14:31, 11 January 2021 (UTC)

No, true synonyms, not simply override in some situations. Those 600 pages with citations would have the "better" place/date moved/removed/replaced by hand. --Izno (talk) 15:03, 11 January 2021 (UTC)

In this discussion I wondered if we really need a 'written at' facility. I speculated then that that facility is not needed because it does not help readers locate a copy of a source. I believe that the functionality is not really useful. Similarly, I don't think that readers benefit when |date= and |publication-date= are paired.

Given my druthers, I would deprecate |publication-place=, |place=, and |publication-date=. These simple searches give some idea of how often these parameters are used when compared to |location= and |date=:

• publication-place ~8k articles
• place ~30k articles (search times out)
• location ~350k articles (search times out)
• publication-date ~13k articles
• date ~670k articles (search times out; search is cs1 and cs1-like templates only to avoid contamination from {{citation needed}} which also takes |date=)

Clearly, the overwhelming preference is for |location= and |date=. Deprecate and remove the others.

—Trappist the monk (talk) 14:57, 11 January 2021 (UTC)

Treating |place= and |publication-place= as synonyms violates the Principle of least astonishment. Either allow both or deprectae |date=, |location= and |place=. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:24, 11 January 2021 (UTC)

"Synonym" may be the wrong term. The more common in programming abbreviation "alias" is probably better. I don't think POLA is violated by these terms. They are correct in the context of the programming construct, ie they conform to the normal usage of the terms in citations. In citations, "date" is expected to mean "publication date"; "place" is "publication place". Citations can only cite published materials and info pertinent to the publication. 50.74.165.202 (talk) 16:23, 11 January 2021 (UTC)

Indeed, alias is the probably more domain-specific term used in templates. --Izno (talk) 17:06, 11 January 2021 (UTC)

What is the proper way to mark up a {{cite conference}} to specify the dates of the conference, the location of the conference, the time of a session and the number of a session, e.g.,

Dual Address Space & Linkage-Stack Architecture
Dan Greiner 
[email protected]
z/Server Architecture
SHARE 118 in Atlanta
Session 10446, 12 March 2012, 4:30 pm

I can fudge some like this,^[1] but Atlanta would be incorrectly indexed as the publication place and it doesn't show the session time. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:33, 09 January 2021 (UTC)

For the date & place, see recent discussion in #How do you indicate both the location of a conference and the place of publication?.

Session numbers & times are not pertinent to citations, unless you specifically cite the conference program or other such promotional/informational conference materials published by the sponsor. You do need to cite the relevant paper as published in the proceedings, which should be cited as well. 50.74.165.202 (talk) 16:09, 9 January 2021 (UTC)

The published information for SHARE conferences is organized by date, time and session number. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:41, 11 January 2021 (UTC)

First, I'm surprised they're still around. :) My first computing experience was on a block terminal timesharing an S/360. We also used punch cards... but never mind, this was such a long time ago. Back to now, since the proceedings are members-only, I cannot verify the citation offhand. If there is an online record of the conference, and if it includes presentations indexed by session number, then there's nothing wrong with your example. If this kind of indexing (ie search facility) reaches a critical mass, perhaps |session= would be apt. I am not sure this is the case now. 98.0.246.242 (talk) 04:33, 12 January 2021 (UTC)

Neither https://share.confex.com/share/118/webprogram/Session10446.html nor the https://share.confex.com/share/118/webprogram/Handout/Session10446/Dual%20Address%20Space%20%26%20Linkage%20Stack.pdf link on that page is members only, nor is https://share.confex.com/share/118/webprogram/, the link for the complete SHARE 118 conference. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:21, 12 January 2021 (UTC)

I still do not see the need for a session parameter. I assume you want to cite the specific paper, not information about the session it was presented in. The first example is a sponsor/publisher abstract; the second, ancillary material (a presentation handout); the 3rd, a conference program. The first two can be part of the presentation's citations. The last cites the proceedings as a whole. In all cases, the session number(s) is not necessary. It may be helpful in locating the presentation, and this can be offered via |id=. 66.65.114.61 (talk) 19:48, 12 January 2021 (UTC)

In

Do we actually need to issue the error message for this particular joiner character in the first place? Is it really polluting metadata?

If we need to issue the message in general, couldn't we add a special case for the concatenated characters being emojis, or add this as a special case for |title=((...)) or |script-title=?

--Matthiaspaul (talk) 05:12, 11 January 2021 (UTC)

The emoji implementers being creative with the zwj (which is not warned for in Unicode blocks that do not need it, which is several character sets) is something we've talked about before. I might be personally agreeable for also allowing it for the blocks of interest, but I must also be skeptical that we are using any quality source that purports to be a serious work for our reference that also editorially allows any emoji in their titles.... --Izno (talk) 13:10, 11 January 2021 (UTC)

See also:

• Help_talk:Citation_Style_1/Archive_68#Emoji_HTML_help
• Help_talk:Citation_Style_1/Archive_60#Zero-width_joiners_between_emoji

--Matthiaspaul (talk) 20:20, 12 January 2021 (UTC)

I've removed a lot of zwj (and other invisible) characters that had nothing to do with joining anything; they were simply extraneous characters included in text copy/pasted from an online source. So, yeah, we should continue to emit error messages when they occur. We can modify has_invisible_chars() to detect the ((...)) markup wrapping the entire parameter value when a zwj character is found (we already look for and allow zwj characters in Indic-script text because zwj is used as a character-modifier in those scripts). We must not abandon the invisible-character check when we detect the ((...)) markup because we don't want to mask errors caused by stripmarkers from TemplateStyles or inappropriate wiki tags and the like.

—Trappist the monk (talk) 16:44, 11 January 2021 (UTC)

In my browser, it looks like the zwj is used to add a modifier to the emoji, turning it from a shrugging woman with hands raised in a purple shirt into a shrugging man with hands raised in a blue shirt. That sounds like Trappist the monk's description of how the Indic scripts work. If so, it should probably be put in the same "allow" group as the Indic-script characters. – Jonesey95 (talk) 17:35, 11 January 2021 (UTC)

Emoji code points are not confined to a single contiguous Unicode code block or even a few code blocks as the Indic code points are. According to

List of emoji, emoji are spread across 24 code blocks and the code points in those blocks are not wholly contiguous. We could take on yet another module (Module:Emoji/data

– not been updated since its creation and supports a template that is not used) to maintain for this relatively rare condition and then from that figure out if the code points adjacent to the zwj are emoji. That seems like more work than its worth.

—Trappist the monk (talk) 19:51, 11 January 2021 (UTC)

Given that emojis are still a comparably rare thing in the Western world, in particular in "serious" sources, it seems that adding this to |title=((...)) is a better (lower footprint, less maintenance and more flexible) solution at present.

If we'd find that it occurs more frequently in the future, direct support could still be added at a later stage.

--Matthiaspaul (talk) 00:59, 12 January 2021 (UTC)

It might possibly be less work than it appears. I found This page, which recommended looking at this document, which is a recommendation explaining which ZWJ-modified emojis vendors would be expected to support. I did a bunch of text processing on the latter document, and came up with this 37-line list of unique "ZWJ followed by modifier emoji" combinations.

U+200D U+1F308
U+200D U+1F33E
U+200D U+1F373
U+200D U+1F393
U+200D U+1F3A4
U+200D U+1F3A8
U+200D U+1F3EB
U+200D U+1F3ED
U+200D U+1F466
U+200D U+1F467
U+200D U+1F468
U+200D U+1F469
U+200D U+1F48B
U+200D U+1F4BB
U+200D U+1F4BC
U+200D U+1F527
U+200D U+1F52C
U+200D U+1F5E8
U+200D U+1F680
U+200D U+1F692
U+200D U+1F91D
U+200D U+1F9AF
U+200D U+1F9B0
U+200D U+1F9B1
U+200D U+1F9B2
U+200D U+1F9B3
U+200D U+1F9BA
U+200D U+1F9BC
U+200D U+1F9BD
U+200D U+1F9D1
U+200D U+2620
U+200D U+2640
U+200D U+2642
U+200D U+2695
U+200D U+2696
U+200D U+2708
U+200D U+2764

Can we add support just for this list, to see if the problem is mitigated? – Jonesey95 (talk) 01:08, 12 January 2021 (UTC)

That is certainly simpler. I'll give it a try on the morrow.

—Trappist the monk (talk) 01:32, 12 January 2021 (UTC)

Seems to work. It did for all of the emoji zwj errors in cs1|2 templates listed in Category:CS1 errors: invisible characters. {{cite tweet/sandbox}} uses the live version of {{cite web}} so I haven't tested the code against that template.

—Trappist the monk (talk) 17:08, 12 January 2021 (UTC)

Looks good. --Matthiaspaul (talk) 20:20, 12 January 2021 (UTC)

IBM System/360 cites a section^[1] within a journal article with this <ref>{{cite journal | author = A. Padegs | title = System/370 Extended Architecture: design considerations | journal = IBM Journal of Research & Development | volume = 27 | issue = 3 | pages = 198–205 | date = May 1983 | publisher = IBM | doi = 10.1147/rd.273.0198 }} – a subsection titled "31-bit addressing" begins on page 201.</ref> markup. The {{cite journal}} template does not support |section= or |section-url=, nor does it support nested page ranges.

What is the proper markup for doing this? Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:24, 13 December 2020 (UTC)