Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by ProcrastinatingReader (talk | contribs) at 16:45, 15 January 2022 (→rfc: shall we update cs1/2?: Closing discussion (DiscussionCloser v.1.7.3)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"WP:PROPOSE" redirects here. For propose for deletion page, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


    rfc: shall we update cs1/2?

    The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

    There is support for most changes proposed, and they may be rolled out. There is also support for the idea that most typical changes to cs1/2 are uncontroversial and don't need to undergo routine VPR RfCs to be rolled out.

    The crux of the opposition, aside from the comments about the nature of the all-or-nothing RfC, centred on the removal of deprecated parameters. Although the argument in later comments, that we don't generally support old historical revisions, is strong in the context of TfD, its application to citation templates was disputed in the widely-attended Monkbot 18 RfC. So I think there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out. ProcrastinatingReader (talk) 16:45, 15 January 2022 (UTC)[reply]


    Yes or No. Shall the Citation Style 1 / Citation Style 2 (cs1/2) Lua module suite be updated to reflect the changes that have accumulated in the module-suite's sandboxen?

    This is an all or nothing rfc. In the event of a draw, cs1/2 shall be updated. §list of prospective changes gives brief descriptions of the individual changes and links to related discussions.

    —Trappist the monk (talk) 23:11, 28 November 2021 (UTC)[reply]

    list of prospective changes to the cs1/2 module suite

    The last update to the cs1|2 module suite was 2021-04-10 except where otherwise noted. This section lists the changes made to the cs1|2 module suite sandboxen since that update.

    list of prospective changes

    changes in Module:Citation/CS1/sandbox

    changes in Module:Citation/CS1/Configuration/sandbox

    • detect generic author, editor, etc names
    • add Category:CS1 tracked parameter: $1 properties tracking category
    • remove support for unused |isbn13= and |ISBN13=; discussion
    • remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
    • add support for nrf-gg, nrf-je language codes; discussion
    • revise how date month-name auto-translation is enabled
    • add support to allow editors to see citations that emit properties cats
    • removed reliance on .error; discussion
    • |url-status= without |archive-url= maint cat: Category:CS1 maint: url-status
    • add support for |ssrn-access=; discussion
    • add ab to script_lang_codes{};
    • more consistent support of |type= with {{cite speech}}
    • check all but url-holding and insource-locator parameters for inappropriate urls
    • add yue to script_lang_codes{};
    • added bogus name "Verfasser" to the list; discussion
    • add keyword "deviated" to |url-status=; discussion
    • added preview error summary
    • added 'Login • Instagram' to generic titles;
    • removed crh, nrg-gg, and nrf-je from language override
    • added comma between volume and number; discussion
    • added Mr. Privacy Statement, Ms. Cookie Policy and Dr. Submitted Content to list of bogus names; discussion
    • revise kerning; discussion
    • i18n |script-<param>= error message supplements; discussion
    • added 'Usurped title' to generic titles; discussion
    • added add bogus names: 'author', 'collaborator', 'contributor', 'editor', 'interviewer', 'translator'; discussion

    changes in Module:Citation/CS1/Whitelist/sandbox (last update 2021-05-25)

    • removed deprecated parameter |transcripturl=
    • deprecated |lay-date=, |lay-format=, |lay-source=, |lay-url=; discussion

    changes in Module:Citation/CS1/Date validation/sandbox

    • extend allowed dates in |pmc-embargo-date= validation to two years; discussion
    • revise month-name validation;
    • add support to allow editors to see citations that emit properties cats;

    changes in Module:Citation/CS1/Identifiers/sandbox

    • add support for |ssrn-access=;
    • reworked error messaging;
    • fix false positive doi error detection; discussion
    • strip accept-this-as-written markup from all identifiers for metadata; discussion

    changes in Module:Citation/CS1/Utilities/sandbox (last update 2021-01-09)

    • add support to allow editors to see citations that emit properties cats;
    • reworked error messaging;
    • added hyphen_to_dash() moved from main module;

    changes in Module:Citation/CS1/COinS/sandbox

    • strip accept-this-as-written markup from |title=;

    changes in Module:Citation/CS1/sandbox/styles.css (last update 2021-01-09)

    • Removed reliance on .error;
    • Removed extra kerning classes;
    • Removed unused cs1-subscription/registration styles;
    • Moved .citation styles from MediaWiki:Common.css;
    • Removed <code> selector;

    —Trappist the monk (talk) 23:11, 28 November 2021 (UTC) 23:25, 3 December 2021 (UTC) (update link) 17:42, 23 December 2021 (UTC) (update links)[reply]

    survey (update cs1/2?)

    • Update see longer rationale in the discussion section. * Pppery * it has begun... 23:31, 28 November 2021 (UTC)[reply]
    • Strong oppose. There are far too many changes here for a single, all-or-nothing question, so I must oppose. Come back with a series of proposals that treat the community like adults and I will support the ones that will improve the encyclopaedia. Thryduulf (talk) 00:42, 29 November 2021 (UTC)[reply]
      Is there a specific change that Thryduulf objects to? If so, on what grounds is that objection based? – Jonesey95 (talk) 17:10, 29 November 2021 (UTC)[reply]
      I object to the concept of this RFC being all or nothing so that controversial changes such as removal of support for parameters that there was no community consensus to deprecate let alone remove are being pushed through with proper review because it would hold up needed uncontroversial changes. That's WP:GAMING the system. Thryduulf (talk) 19:50, 29 November 2021 (UTC)[reply]
    • Not a valid RfC as per Thryduulf and Sdkb. Nikkimaria (talk) 00:57, 29 November 2021 (UTC)[reply]
      • Re Headbomb's comment below: to be clear, there is at least one change in this set known to be contentious, so a procedural closure of this RfC should not be taken as a green light to roll out everything. Nikkimaria (talk) 01:01, 29 November 2021 (UTC)[reply]
        • Assuming you are referring to add Category:CS1 tracked parameter: $1 properties tracking category; discussion, it doesn't actually add any categories, merely currently non-functional code to add categories. * Pppery * it has begun... 01:19, 29 November 2021 (UTC)[reply]
          The removal of support for the unhyphenated parameters is also contentious, given that the premise of the discussion that (is claimed to) be the basis of consensus for the changes explicitly ruled that out (according to my memory of the major RFC anyway). Thryduulf (talk) 01:24, 29 November 2021 (UTC)[reply]
          The RFC was about a different set of parameters. See my explanation and link below. – Jonesey95 (talk) 17:12, 29 November 2021 (UTC)[reply]
          The RFC established that the basis on which both sets parameters were deprecated did not have community consensus, or even a local consensus given that the course of action undertaken was explicitly ruled out as something that would happen. Wikilawyering about exactly what was covered by the RFC is also not a good look. Thryduulf (talk) 13:43, 30 November 2021 (UTC)[reply]
    • Support. This is a normal code update that has typically happened every few months. It contains bug fixes, minor enhancements, and small refinements. A larger number of minor changes than usual have accumulated because a small band of editors objected to the last regular update, and the volunteers who maintain the modules understandably decided to take a break from that drama for a while. Normally, notice of these updates would take place at Help talk:Citation Style 1 (418 page watchers, 125 recent visitors), where updates to these modules have been discussed for roughly a decade. Since there was drama last time, the updates are being vetted at this more-heavily-watched page (3,503 watchers / 554 recent). – Jonesey95 (talk) 02:24, 29 November 2021 (UTC)[reply]
    • Support—we're overdue for the quarterly update. These updates dump millions of articles into the job queue for processing, so the changes are bundled and applied at once. Imzadi 1979 → 15:24, 29 November 2021 (UTC)[reply]
    • Oppose removal of formerly valid parameter names, breaks old revisions for no good reason, was opposed at previous RfCs. Would probably support the rest, but in something as unwiki as an all-or-nothing RfC (Wikipedia usually operates by consensus), this is my only option. —Kusma (talk) 20:14, 29 November 2021 (UTC)[reply]
      As noted by Jonesey95 in the discussion section below, the parameters mentioned have already been deprecated back in February. This change should not be confused or conflated with the objected-to deprecation of |accessdate=, which is still in wide use. MichaelMaggs (talk) 08:51, 30 November 2021 (UTC)[reply]
      But that's not what Kusma (correctly) opposes for: the "deprecation" of parameters we used to allow is one thing, the "removal of support" from the code though means that all older versions of articles which did use these parameters will now give errors instead of just having a working (though no longer wanted) parameter. For parameters which were never widely in use, this may be acceptable; for parameters which where more widely used, this is problematic. Where the cutoff for "widely" should be placed is another kettle of fish of course. But that these parameters have been deprecated in February doesn't mean that one should support a change which now no longers supports them at all. Fram (talk) 09:15, 30 November 2021 (UTC)[reply]
    • Support all of these changes, including those identified as potentially contentious by Pppery below. I would also prefer a return to the previous approach of more frequent updates for minor changes, with RFCs reserved for changes that are likely to prove controversial, but am content for the editors that maintain the CS{1,2} templates to decide how they bring changes to the community to review. Wham2001 (talk) 08:01, 30 November 2021 (UTC)[reply]
    • Support, and agree with Wham2001's comments. MichaelMaggs (talk) 08:39, 30 November 2021 (UTC)[reply]
    • Oppose. "It's an all or nothing" and you sneak in opposed changes which you happen to support? No thanks, if that's what you try then just abandon your maintenance of this please. I love the division created by a support vote between "a small band of editors" vs. "the volunteers who maintain the modules", a nice indication of a warped view of priorities there. Fram (talk) 08:42, 30 November 2021 (UTC)[reply]
      Fram's last sentence is important. Those who maintain these modules are doing a service to editors who add citations to articles not the other way around and this needs to be remembered. If the people who use the templates say something is bad, disruptive or unwanted then it should not happen and/or be reversed without question. The encyclopaedia does not exist for the convenience of coders. Thryduulf (talk) 10:51, 30 November 2021 (UTC)[reply]
      Those who maintain these modules are volunteers, not WMF employees, and they perform a complicated and very valuable service for the content creators. We are immensely grateful for the work they do. We appreciate and understand that a package of changes have been tested together and cannot easily be unbundled. Hawkeye7 (discuss) 03:52, 1 December 2021 (UTC)[reply]
      No, you've been mislead to believe that. It would in fact be technically trivial to perform the rest of the update without changing the list of supported parameters. I'm becoming more and more inclined to oppose this RfC with every passing comment. * Pppery * it has begun... 03:54, 1 December 2021 (UTC)[reply]
      Those who maintain these modules are volunteers, not WMF employees yes, so?. they perform a complicated and very valuable service for the content creators. which is why they need to respect the community's wishes. Thryduulf (talk) 12:18, 1 December 2021 (UTC)[reply]
    • Support all changes per Pppery and Jonesey95 comments below. As an additional comment to this procedure, the module maintainers do a very complicated and ungrateful service and I find it pretty absurd that module updates now require RfCs and even more absurd are some of the opposers are on the grounds that there are too many changes (and I'm not one of the maintainers). --Gonnym (talk) 11:01, 30 November 2021 (UTC)[reply]
      The issue is not that there are too many changes. The issue is that there are too many changes that we are being asked to approve as a single unit, and that unit includes changes that should not be made as well as changes that should. The module maintainers are giving the appearance that they care more about the module than they do about the reason the module exists: to support those writing an encyclopaedia. The only correct way to proceed in a situation like this is to swallow some pride and agree to separate the controversial and uncontroversial changes so that the former do not hold up the latter. The controversial changes than then be discussed on their merits and the consensus of the community listened to, whatever that consensus is, rather than attempting to bypass it. Thryduulf (talk) 13:40, 30 November 2021 (UTC)[reply]
    • Support, although I don't really like the format of this RfC (particularly, the "all or nothing" framing and "In the event of a draw, cs1/2 shall be updated"). I don't think that the RfC should be closed as flawed, but it should be evaluated based on consensus for each of the proposed changes rather than "all or nothing", and no consensus should lead to retaining the status quo. Tol (talk | contribs) @ 21:57, 30 November 2021 (UTC)[reply]
    • Support been waiting for some of these for quite a while. Hawkeye7 (discuss) 22:30, 30 November 2021 (UTC)[reply]
    • Oppose this RfC as stated but support unbundling the set and implementing the many non-controversial changes but not the controversial ones aka "common sense". Levivich 05:18, 1 December 2021 (UTC)[reply]
    • Oppose I've come to realize what this RfC really is, an attempt towill do: falsely establish consensus for controversial changes by making them a rider to clearly-supported changes when they failed on their own merits. That sometimes works for legislation, but it should not work on Wikipedia. * Pppery * it has begun... 22:36, 1 December 2021 (UTC)[reply]
      Really? Really? Do you really think that were I trying to falsely establish consensus for controversial changes by somehow hiding them amongst a large number of other changes, I would have written this with its rather obvious markup which pretty much guarantees that anyone who merely scans the list could not fail to see it:
      • remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
      You have accused me, and probably, by extension, the other maintainers of the cs1|2 module suite of malfeasance, of dishonesty, of lying. Produce the evidence or withdraw your accusations.
      —Trappist the monk (talk) 23:50, 1 December 2021 (UTC)[reply]
      Premises:
      If this RfC passes (which might happen), then support for unhyphenated parameters will be removed.
      If there had been a RfC solely on the question of whether support for unhyphenated parameters should be removed, that RfC would likely have failed for the same reason Option C passed at the previous RfC
      Conclusion:
      This RfC passing will result in a false consensus in favor of removing support for unhyphenated parameters, as a result of it being stuck in as a rider to a broadly-supported set of changes. It was incorrect to phrase it as an accusation of malicious intent, and I've reworded the above comment slightly, but that doesn't change the underlying situation.
      * Pppery * it has begun... 00:11, 2 December 2021 (UTC)[reply]
    • No (equating to "oppose") as clearly mandated in the RfC's instructions, and almost entirely because of the RfC's instructions. Apparently, this RfC has to lean hard over to the "oppose" side, lest there be "no consensus", leading to to the same results as "Yes" ("support"). Then we can discuss the specific issues in an actual, properly formed RfC. — JohnFromPinckney (talk / edits) 20:36, 4 December 2021 (UTC)[reply]
    • Oppose Insufficient detail. The use of German rather than English ("sandboxen") is erroneous here. Andrew🐉(talk) 13:05, 9 December 2021 (UTC)[reply]
      I am astonished, truly, I am. Usually the complaint is 'too technical' or 'too much detail'. Discussions about all of the proposed changes are linked in the collapsed box at § list of prospective changes to the cs1/2 module suite. Except for the most minor of changes, all changes to cs1|2 are always discussed so whatever detail you are seeking is likely in the related linked discussion. My word choice is not the subject of this rfc so a comment about that is erroneous here. (I'm not old enough to remember Template:Lang-enm in everyday usage, but I am old enough to have used VAXen so it is not uncommon for me to also substitute boxen in its more modern sense anywhere that boxes might occur. I am not the only editor at en.wiki to do this)
      —Trappist the monk (talk) 14:43, 9 December 2021 (UTC)[reply]
      @Trappist the monk: See http://catb.org/~esr/jargon/html/overgeneralization.html for the general rule and http://catb.org/~esr/jargon/html/B/boxen.html for the specific word. WhatamIdoing (talk) 01:08, 14 December 2021 (UTC)[reply]
    • Support. I support all changes. Most are minor and have strong consensus. The on that seems most controcersial is deprecation of certain unhyphenated parameters. Per the statistics bewlw, this will affect less than 1% of all pages using CS1/2, is easily fixed by bots, and a display will be displayed only when viewing old revisions. Not breaking old revisions has never been considered a strong argument at TfD and for the purposes of updating the module the reasons are the same. We don't hold supported templates hostage to faithful transclusions in old revisions. – Finnusertop (talk ⋅ contribs) 15:50, 14 December 2021 (UTC)[reply]
    • Support. I see no problems with the changes. It is correct that removing parameters will mess up with page history but we have made many other actions that does that. We can't keep a fully working page history forever. I think it is a good idea to keep old parameters for some time but I see no reason why we need to keep them forever. --MGA73 (talk) 23:22, 27 December 2021 (UTC)[reply]

    discussion (update cs1/2?)

    • The only things here that seem plausibly controversial are:
      • add Category:CS1 tracked parameter: $1 properties tracking category; discussion (My observation: this doesn't actually add any new tracking categories, but merely adds code to populate such tracking categories if they are later needed)
      • added error summary preview; discussion
      • remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=.
      . Overall, I question whether it's appropriate to remove (or to have deprecated in the first place) unhyphenated parameter aliases given the result of Wikipedia:Village pump (proposals)#RFC: Citation Style 1 parameter naming convention. Despite Trappist the monk's framing of the issue as all-or-nothing, the rest of the update is not in some way dependent on those changes, and it is anyway not sufficient to convince me not to support this update. * Pppery * it has begun... 23:31, 28 November 2021 (UTC)[reply]
      FWIW, the deprecation of the above parameters happened in February 2021, more than nine months ago, all of the parameters were updated shortly thereafter, and any stray instances of those parameters have been generating error messages (and have been quickly fixed) since April 2021. This update would change the error message from "deprecated" to "unsupported" in the very rare instance that someone used one of these long-gone parameters. This change should not be confused or conflated with the objected-to deprecation of |accessdate=, which is still in wide use. – Jonesey95 (talk) 17:08, 29 November 2021 (UTC)[reply]
      How long have they been used and how many old revisions will be broken by removal of these parameters? And what is gained by removing them? —Kusma (talk) 09:38, 30 November 2021 (UTC)[reply]
      These parameter aliases were not commonly used. Hyphenated versions of them have been the standard since 2014. Dozens of unhyphenated multi-word parameters have been deprecated and removed from the CS1 citation templates over the past seven years with a minimum of drama (until the final six were proposed for deprecation back in April 2020, which is not something that is happening in this RFC). – Jonesey95 (talk) 14:19, 30 November 2021 (UTC)[reply]
      That does not answer any of Kusma's questions. Thryduulf (talk) 17:54, 30 November 2021 (UTC)[reply]
      I'll make an attempt to answer some of Kusma's questions. Per User:Monkbot/task 18: cosmetic cs1 template cleanup#hyphenate cs1|2 parameter names, before Monkbot 18 ran:
      1. |booktitle= was used 3,345 times
      2. |chapterurl= was used 17,289 times
      3. |episodelink= was used 2,539 times
      4. |mailinglist= was used 379 times
      5. |mapurl= was used 81 times
      6. |nopp= was used 2,902 times
      7. |publicationdate= was used 542 times
      8. |serieslink= was used 5,042 times
      9. |transcripturl= was used 910 times
      That totals 33,029 pages (which is an overestimate, as some pages likely used more than one such parameter). * Pppery * it has begun... 22:36, 1 December 2021 (UTC)[reply]
      For a sense of scale, Module:Citation/CS1 is used in just over 5,000,000 pages. 33,000 pages was a little less than 0.7% of the total page usage. That is why it was so straightforward and easy to deprecate and update the above parameters, as opposed to the six remaining unhyphenated parameters, which are more widely used. – Jonesey95 (talk) 23:00, 3 December 2021 (UTC)[reply]
      OK, so the damage is middle sized (17000 broken chapterurls will create some annoyance). But removing these aliases still doesn't have any obvious advantages over not removing them. —Kusma (talk) 16:40, 7 December 2021 (UTC)[reply]
    • In the event of a draw, cs1|2 shall be updated. This isn't normally something an editor opening an RfC can unilaterally declare, nor is an RfC's all-or-nothing status. Per WP:Consensus, if there's no consensus, we generally retain the status quo. {{u|Sdkb}} talk 23:33, 28 November 2021 (UTC)[reply]
      It is totally inappropriate, and whoever closes this should ignore this made-up rule that has no policy-based support whatsoever. In the event of "no consensus overall", the changes that are supported by consensus should be applied and the changes not supported by consensus not applied. —Kusma (talk) 09:36, 30 November 2021 (UTC)[reply]
    • Waste of time RFC it's utter nonsense that we have to wait for months for CS1|2 updates to be rolled out, it's even more utter nonsense that we need RFCs to roll them out. If they're ready and have consensus, roll them out as soon as they've been tested in the sandbox and confirmed as working as intended. Don't delay, and don't plague us with pointless RFCs. If a particular issue is contentious, have an RFC on that issue, don't hold the rest of the updates hostage. Headbomb {t · c · p · b} 00:45, 29 November 2021 (UTC)[reply]
    • I don't like the format of this RfC. It would be better done by a different method:
      1. Propose these changes and see if anyone opposes one or more of them.
        • Unopposed (uncontroversial) changes can be immediately implemented or held until after the second part.
        • Opposed (controversial) changes would need consensus in part 2.
        • Obviously uncontroversial changes don't need to be included.
      2. Open a multi-section RfC with a section on each controversial change, and let each section gain consensus individually.
      3. Implement changes that were either uncontroversial in part 1 or gained consensus in part 2.
      I don't think that the RfC should be closed as flawed, but it should be evaluated based on consensus for each of the proposed changes rather than "all or nothing", and no consensus should lead to retaining the status quo. Tol (talk | contribs) @ 21:57, 30 November 2021 (UTC)[reply]
    • Why is this an all or nothing? Why will it pass in the case of a tie? Dege31 (talk) 18:24, 3 December 2021 (UTC)[reply]
      The cynical view is because that's the only way the proposer(s) do not wish to test the consensus of the changes individually, possibly because some of the desired changes may not pass. You are not the first to ask the question, but none of the responses have provided a plausible alternative view, although malicious intent has been denied. Thryduulf (talk) 21:31, 3 December 2021 (UTC)[reply]
      Changes to cs1|2 are not made secretly behind a veil; all editors are welcome, encouraged, to participate in the discussions about cs1|2 at Help talk:Citation Style 1. There is no need to re-discuss that which has already been discussed (see the discussion links in the collapsed box at § list of prospective changes to the cs1/2 module suite). Except for the most minor of changes, all changes to cs1|2 are always discussed, mostly at Help talk:Citation Style 1 and sometimes, at other locations (Help talk:CS1 errors and Template talk:Citation are common alternate-discussion locations).
      In my experience – yours may be different – inconclusive RFCs result in the question: 'now what?' To avoid the 'now what?' question, I defined an action to be taken in the event that the community's opinion is not definitive. So now you know. The answer to the 'now what?' question for this RFC is: update.
      —Trappist the monk (talk) 23:25, 3 December 2021 (UTC)[reply]
      There is no need to re-discuss that which has already been discussed (see the discussion links... But not all of those discussions reached a consensus in favour of the proposed changes. That suggests that either they do need to be re-discussed, or they should be removed from the proposal. Nikkimaria (talk) 00:03, 4 December 2021 (UTC)[reply]
      @Trappist the monk: inconclusive RFCs result in the question: 'now what?' This could not have been an inconclusive RfC - either there is consensus for the changes or there is no consensus for the changes. In the first case the changes are implemented, in the second case they aren't. If the changes did not get consensus there is nothing stopping anyone who understands why they failed to get consensus addressing the reasons and asking the community about the revised proposal. Everywhere else on Wikipedia changes for which there is no consensus do not get implemented, and there is no reason for this to be any different. Thryduulf (talk) 11:32, 4 December 2021 (UTC)[reply]
      The question asked by this RFC is simple: Yes or No, shall we update? If the community's answer as determined by the closer is predominantly Yes then we update; if the community's answer as determined by the closer is predominantly No, then we do not update. If the community's answer as determined by the closer is inconclusive then we update and avoid the 'what now?' question. Because it is stated in the question, all respondents to this RFC know what to expect in the event of a tie.
      —Trappist the monk (talk) 13:34, 4 December 2021 (UTC)[reply]
      Lol ttm like that would ever fly. The initiator of this RFC knows what to expect if updates are pushed without consensus. Levivich 14:06, 4 December 2021 (UTC)[reply]
      If the answer as determined by the closer is "inconclusive" then anywhere else on Wikipedia the status quo would apply, which in this case would mean "we do not update". You have not explained why this RfC should be different to everywhere else. Thryduulf (talk) 18:06, 4 December 2021 (UTC)[reply]
    • How much of a maintenance burden would it be to keep the deprecated parameters around? I sometimes worry that while the desire to keep old revisions working is reasonable, keeping the old parameters around might create extra work when updating/maintaining/adding new functionality to CS1/2 templates and we might be neglecting this extra work. Jo-Jo Eumerus (talk) 10:42, 4 December 2021 (UTC)[reply]
      In the last RFC, which found "There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates" (emphasis in original) the maintenance burden was brought up multiple times, but nowhere in the discussion could I find anywhere that detailed exactly what that burden is or why it is so significant that it was more important than the various benefits of keeping them around (not breaking old revisions, editor familiarity, ease of use, etc). Certainly none of the arguments about maintenance burden convinced people in opposition to deprecation to change their minds. Thryduulf (talk) 11:43, 4 December 2021 (UTC)[reply]
    • Some think it's okay to remove old parameters and some think we should keep them to preserve page history. Personally I do not think it is possible or needed to make sure that a page history will work forever. But I agree that it would be good to preserve page history for some time. So perhaps as a compromise there could be some time limit so parameters used on less than 1k pages could be removed faster than pages used on 1M+ pages? --MGA73 (talk) 23:33, 27 December 2021 (UTC)[reply]
    • I've requested closure of this RfC. Tol (talk | contribs) @ 20:59, 9 January 2022 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Fstops in gadget page

    This isn't going to need a VPR, see note below. — xaosflux Talk 11:28, 7 January 2022 (UTC)[reply]

    The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    About Preference, Gadgets: four codes are listed and described in the Gadget legend: (D), (E), (S), (U). The descriptions appear in the list as {{abbr}} like (D), OK. Now, between the four the period (full stop) is alternating missing/present in the abbr tooltip text. Maybe could be smoothed?

    (I personally do not think for this issueette the Project should be restarted from 20 year ago, but I do like to take my examples from high end quality webpages ;-) ). -DePiep (talk) 06:58, 7 January 2022 (UTC)[reply]

    @DePiep: I'm closing this section as this is a very minor tweak that shouldn't require a community proposal. See MediaWiki_talk:Gadgets-prefstext#Tool_tips and feel free to just open an edit request there for any sorts of minor updates you would like made on the labels. — xaosflux Talk 11:28, 7 January 2022 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Categorize Set index articles as disambiguation pages

    .... 0mtwb9gd5wx (talk) 07:44, 9 January 2022 (UTC)[reply]
    I have no opinion as yet on whether this would be a good change, and am unlikely to form one unless you say why you are proposing it. Phil Bridger (talk) 08:24, 9 January 2022 (UTC)[reply]
    Set index articles are not dabs, because dabs are not articles. However, they have many features in common and some SIAs might work better as dabs. (For example, Ministry of Defence is denied the benefit of our dab maintenance tools because its meanings happen to form a set.) It might be useful if some or all SIAs were more dab-like in ways that I'm struggling to define. Perhaps that means creating maintenance category(s) which include Category:All disambiguation pages and some or all SIAs, such as Category:Pages which should have no direct incoming links, and encouraging {{R from disambiguation}} redirects to its SIAs. Alternatively, it might mean allowing certain lists to be formatted as dabs instead of SIAs. I would also be interested to see more specific proposals. Certes (talk) 14:29, 9 January 2022 (UTC)[reply]
    Set index articles exist as a concept distinct from disambiguation pages because there are topics/titles that need disambiguation but which cannot be made to fit within the strict formatting requirements of disambiguation pages (or the reader otherwise benefits from a different format). Given that the rigidity of the disambiguation page formatting seems to be desired by those who maintain the pages, I don't foresee any likelihood of a merge gaining consensus soon. Thryduulf (talk) 15:21, 9 January 2022 (UTC)[reply]
    An important feature of Set index articles is that they may consist of redlinks, whereas dabs can not. For example, this set index article is certainly useful, since it contains a list of all localities with this name (and can be used, for example, to choose proper name for new articles and even for redlinks). If converted to dab, it is amenable to speedy deletion, since there is nothink to disambiguate. I have such articles on my watchlist being nominated for speedy deletion by users who do not understand the difference.--Ymblanter (talk) 19:04, 9 January 2022 (UTC)[reply]

    RFC: New PDF icon

    Should we replace the current PDF icon? –MJL ‐Talk‐☖ 05:33, 8 September 2021 (UTC)[reply]

    Background

    Our current PDF icon is File:Icons-mini-file acrobat.gif . To put it simply, it isn't particularly good. It's a .gif made over 16 years ago. Berrely mentioned this in WP:Discord, so I set about coming up with a modern SVG version of the file. The result was File:Icons-mini-file pdf old.svg  File:Icons-mini-file pdf.svg .

    Options

    There are three options that should be considered here:

    Consensus for Option 2 should be followed up in a separate discussion. [Updated 15:35, 9 September 2021 (UTC)]

    CONSENSUS TO CHANGE THE ICON, BUT NO CONSENSUS YET ON WHAT TO CHANGE IT TO
    Seems pretty clear that most participants want to change the icon from its current form File:Icons-mini-file acrobat.gif, with typical arguments being that the current form is tied to Adobe (and thus advertises for the company, or is tied too much to a company) and outdated. There was some discussion on whether an external link icon for PDFs was needed at all, with reasonable arguments presented on both sides but most people are supporting a different icon not "no icon at all".

    What's not so clear is what to replace it with - many of the editors who support a change did not specify what to change it to, and some comments are ambiguous. The main point of discussion about each of the numerous proposed files is the legibility of each icon at the size of an external link logo and whether to use SVG or PNG (apparently nobody demands GIF). On balance it looks like the most popular option is File:Icon_pdf_file.png () but there are a lot of people who didn't specify what they wanted or preferred something else. Thus there does not seem to be a clear consensus for a particular option, so we need further discussion to determine the outcome.

    Technical implementation details: As noted in the discussion the file is used through MediaWiki:Common.css, row 314, which as a .css page will need to be edited by an interface administrator. I note that there is a bit of uncertainty if the files used there can be SVGs - apparently the URL cannot be .svg but it can be .svg.png? - among the participants. Jo-Jo Eumerus (talk) 16:41, 11 January 2022 (UTC)[reply]

    The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Discussion (new PDF icon)

    References

    1. ^ "With cite template" (PDF).
    2. ^ Without cite template
    • Option 1. That logo is still the most widely associated with the PDF format, and anything else is just making things less clear for our readers. There doesn't seem to be a clear alternative being posited (the letters in the version proposed by Joe are illegible at this resolution), and most of the reasons above seem to hinge on people's person feelings about Adobe, which shouldn't enter into this debate. Either leave well alone, or adopt the new clearer version proposed by the OP.  — Amakuru (talk) 12:14, 8 September 2021 (UTC)[reply]
      "Personal feelings" is a bit dismissive. We're an free knowledge project and have a long history of supporting free software, free licenses, and free formats wherever possible. I highly doubt that the generic 90s software-looking acrobat squiggle is more widely recognised than the letters "PDF", but I agree the legibility of my first suggestion could be improved. – Joe (talk) 12:22, 8 September 2021 (UTC)[reply]
      If someone comes up with an alternative that actually works, then I might support it. But I'm not going to give a blank cheque to swap an easily recognisable logo for one which might not immediately convey its meaning to our readers. "Option 2" involves dispensing with the current logo without any consensus as to what we're swapping it for, and I can't support that.  — Amakuru (talk) 12:31, 8 September 2021 (UTC)[reply]
    • Option 2 - some generic PDF logo (i.e. not the Adobe 'squiggly triangle') to be determined later. SVG > GIF, of course, but I think we should take this opportunity to swap it for a more generic logo. firefly ( t · c ) 12:25, 8 September 2021 (UTC)[reply]
    • Option 2 or 3 Option 1 is a non-starter due to license. We need something that's public domain or CC0 to avoid a requirement to link back to the file description page for attribution and/or notice of license. I wouldn't oppose an identical image with a proper license; while it's annoying to have the Adobe software's logo in there, it's also recognizable. As for that several people above seem to like, all I see at that size is a document icon with a red bar over it. The text "PDF" is not visible. Again, I wouldn't oppose an alternative that's more legible. Anomie⚔ 12:26, 8 September 2021 (UTC)[reply]
      • Striking as the concerns I raised seem to have been addressed, the new image for option 1 has a usable license and people have suggested as a better choice for option 2. I don't have enough of an opinion on the current options to !vote. Anomie⚔ 16:57, 9 September 2021 (UTC)[reply]
    • Option 2 Let’s move away from Adobe. --Malcolmxl5 (talk) 12:32, 8 September 2021 (UTC)[reply]
    • Option 3 This is change for the sake of change and doesn't actually accomplish anything. * Pppery * it has begun... 13:21, 8 September 2021 (UTC)[reply]
      @Pppery, the current file is 512 pixels, which is too small to be rendered properly on modern screens and appears conspicuously pixelated. ~~~~
      User:1234qwer1234qwer4 (talk)       15:29, 8 September 2021 (UTC)[reply]
    • Option 3 or 2: the current icon is serviceable as is, but if we were to change, I'd rather something without the Adobe logo. Isabelle 🔔 14:35, 8 September 2021 (UTC)[reply]
    • Option 2 per Firefly and others. There is nothing wrong with using a 16-year-old icon per se, and the proposed replacement's only advantage is in file format and that's not enough reason imo to justify a change. However what does justify a change is using a generic icon that doesn't require someone knowing what the logo of a private company represents. Whatever icon we end up choosing, we should probably consider including it as an example in the PDF article. Thryduulf (talk) 15:07, 8 September 2021 (UTC)[reply]
    • Option 2, PDF files are no longer the sole domain of Adobe and we shouldn't be using their logo, but none of the suggested icons have been readable. I modified one of the existing PDF SVG icons on commons to make it more readable (), but if the intent is to use this at 16px, pixel art is always going to render better than an SVG, e.g. . --Ahecht (TALK
      PAGE      ) 15:37, 8 September 2021 (UTC)[reply]
      I have to admit that the 16px PNG rendering does look like a usable option and also looks way less pixelated than the current icon (where even the border displays very blurry), at least on my end. ~~~~
      User:1234qwer1234qwer4 (talk)       15:48, 8 September 2021 (UTC)[reply]
    • Ehhhhhhh ---- GPL are we opening a can of worms by changing from a free image to one that has to drag GPL around with it everywhere? — xaosflux Talk 16:58, 8 September 2021 (UTC)[reply]
      Leaning more towards Option 2 and using File:Icon pdf file.png or something similar, provided it is CC0 or other very-free license. — xaosflux Talk 18:50, 8 September 2021 (UTC)[reply]
      @Xaosflux and Anomie: Wouldn't a comment in the CSS be sufficient for linking to the license and authorship? –MJL ‐Talk‐☖ 20:56, 8 September 2021 (UTC)[reply]
      Nope. The GPL seems particularly weird when it comes to images, and even more weird when it comes to SVG images. The bottom line is that we need to clearly distribute the image along with the author's copyright notice and the notice that it's under the GPL, which we satisfy by linking the image to the file description page that has all that information. Hiding a comment in a CSS file, where it'll be hard to find and may be minified out, won't cut it. Anomie⚔ 21:55, 8 September 2021 (UTC)[reply]
      Okay, I have managed to remake the SVG using stuff that was in the Public Domain. –MJL ‐Talk‐☖ 05:06, 9 September 2021 (UTC)[reply]
    • Option 2 I find the PDF text version quite promising. The one I think is the most legible is (show) (File:Icon_pdf_file.png) which is easily readable on both mobile (both vector and mobile version). There are of course scenarios where it wouldn't be legible, but I feel the current icon would be non-distinctive under the same circumstances and I could see many readers not knowing what the acrobat icon means now a days. --Trialpears (talk) 17:03, 8 September 2021 (UTC)[reply]
    • Option 2 Go for File:Icon_pdf_file.png . It's more readable than the similar svg versions. -- WOSlinker (talk) 18:23, 8 September 2021 (UTC)[reply]
    • Option generic PDF SVG Headbomb {t · c · p · b} 18:34, 8 September 2021 (UTC)[reply]
    • Option 4 get rid of it altogether. No GPL license, no trademark (US #3652386 and #3652388, I have no idea how to link these from https://tmsearch.uspto.gov/ so search yourself, it's the squiggly triangle), no BS. The document icon with "PDF", even Joe Roe's improved version, is hard to read and ultimately provides no additional information over just the text "(PDF)". This is currently defined in MediaWiki:Common.css#L-510 btw, it's not template specific or MediaWiki default. — Alexis Jazz (talk or ping me) 19:55, 8 September 2021 (UTC)[reply]
    • Opposed to any GPL-licensed image or image restricted by trademark. Would prefer CC-0 license. No strong opinions on the design itself, I'm open to a new one but don't see a serious problem with the existing image. — Wug·a·po·des​ 20:29, 8 September 2021 (UTC)[reply]
      @Wugapodes: Wouldn't the trademark issue be a problem with File:Icons-mini-file acrobat.gif  as well? I'm a little confused there. –MJL ‐Talk‐☖ 21:00, 8 September 2021 (UTC)[reply]
      I'm not an expert on trademark, but I presume so. My understanding is that having a trademark isn't a problem per se as long as we aren't using it to mislead readers about brand identity or disparage the trademark holder. The issue isn't a legal one, but a philosophical one: I'd prefer we use free equivalents that do not have copyright or trademark restrictions whenever possible. But unless we have consensus for an option that is free of copyright and trademark, I'd rather we have some graphical representation of the PDF over nothing. So by no "serious problem" I mean that it's not enough for me to say get rid of it immediately, but I do think there is room to improve. If we are going to improve, I want us to also move in the direction of copyright- and trademark-free images, but if the option is do nothing or remove the icon without replacement, I'd rather do nothing. (NB I do like Ahect's idea of just using stylized text instead of an icon.) — Wug·a·po·des​ 21:40, 8 September 2021 (UTC)[reply]
       Question: Why is specifying the file format necessary for PDF files? ~~~~
      User:1234qwer1234qwer4 (talk)       22:13, 8 September 2021 (UTC)[reply]
      Wugapodes, I'm fine with stylized text too. The text "(PDF)" already gets added, seemingly by {{Citation}}. I just think the icon should go away. Trademark is possibly a theoretical legal issue. The squiggly triangle in the infobox of PDF is fine because there is clearly no connection between Adobe and Wikipedia. When used as system icon of sorts, like we have it in MediaWiki:Common.css#L-510, it could cause people to believe there is a connection between Adobe and Wikipedia or MediaWiki, like us relying on Adobe software or being endorsed by Adobe. It's a theoretical issue though, this may or may not actually be a trademark violation and Adobe is unlikely to try and crack down on this kind of unauthorized usage. My main issue is also philosophical: try to avoid trademarks if possible, particularly when they're not being used for commentary. 1234qwer1234qwer4, I think traditionally this kind of indication (not just on Wikipedia) was provided to warn users to get a cup of joe while their computer chugs along for 15 minutes to load Adobe Acrobat Reader. — Alexis Jazz (talk or ping me) 22:33, 8 September 2021 (UTC)[reply]
      @1234qwer1234qwer4: PDFs are a bit of a weird file format. Sometimes when you click a link it will automatically download a file on your device, but other times it can just open up in a new tab. The biggest concern, however, is that not all mobile devices support PDFs across the board. My phone can just barely do it (and requires a download everytime I view one.. which can be a problem for larger files), so I have always found these icons helpful. –MJL ‐Talk‐☖ 05:06, 9 September 2021 (UTC)[reply]
    • Option Alexis Jazz - WP:ACCIM recommends that information should not be conveyed using only images, and while the revised icon with plain text is a slight accessibility improvement over the corporate logo version, it's still a long way off from meeting that standard. Alt text would help, but a simple (PDF) alongside the link is frankly much better and more useful than a small icon with tiny, barely-legible text. Ivanvector's squirrel (trees/nuts) 20:40, 8 September 2021 (UTC)[reply]
      Or something like PDF, which is reminiscent of what Google uses. --Ahecht (TALK
      PAGE      ) 21:14, 8 September 2021 (UTC)[reply]
      I see this as a case of progressive enhancement given broadband speeds and the compression of PDFs (which has gotten better since PDFs stopped being all-image files), as the size was predominantly the rationale for ever indicating that a URL pointed to a PDF. Separately, CS1/2 already auto-indicates whether something is a PDF. I don't really see much cause for anyone to generally indicate something is a PDF. (This is not an opinion on this RFC per se, just making a comment about whether we should need to indicate something is a PDF.) Izno (talk) 19:02, 9 September 2021 (UTC)[reply]
      There is an old-school web best practice to indicate if a link doesn't take you to a web page, since that's the general expectation (and, yes, size was part of the concern). I'm not sure of the current consensus on this matter in the web design community. isaacl (talk) 19:46, 9 September 2021 (UTC)[reply]
      I haven't designed web pages since the mid-90s so I can't really comment on standards, but I'd prefer if there were some kind of indicator, text or otherwise. Compression has improved for sure but PDFs are still multimedia, even a single-page plain-text PDF can be several megabytes. Not everyone who reads Wikipedia benefits from the expansion of broadband in wealthy countries, and third-party software is still generally required to open a PDF or use their full functionality, and this can be severely prohibitive for someone on say a 14.4kbps dialup connection, or using a 2G mobile device. We still warn when a link goes to an external website, and we should do the same with multimedia. Ivanvector's squirrel (trees/nuts) 20:52, 9 September 2021 (UTC)[reply]
      "We still warn"? We don't (I assume by "we" you mean MediaWiki software, please be precise if otherwise), at least not "accessibly", in the same way we don't as the would-be "replace with 'PDF' in text". Izno (talk) 21:22, 9 September 2021 (UTC)[reply]
      If you look at the web, I'd say that mostly doesn't happen any longer. I mostly don't think it should, especially with the advent of "the browser does everything (video, audio, PDFs of late in e.g. Firefox, yadda yadda)". Browsers are monsters not far off from being their own operating systems (oh wait :). Izno (talk) 21:24, 9 September 2021 (UTC)[reply]
      Although links to PDF files often lack indicators (with the ubiquity of the format, probably due to both happenstance and successful Adobe marketing), links to video and audio generally still provide some kind of indication. Users generally want to know in advance if they're going to see some kind of audiovisual presentation. Their current browsing environment (such as alone in a room or within a crowd) and personal desires at the moment influence what type of interaction they want to have. isaacl (talk) 00:56, 10 September 2021 (UTC)[reply]
      Yes, by "we" I did mean the MediaWiki software, with the little "arrow escaping the box" icon beside all external links (like this, which is, indeed, not accessible). Remember that while progress marches on, it marches past many people who read Wikipedia but don't have access to cutting-edge tech that we do in developed countries, and something as minor to us as loading a couple-megabyte multimedia file could be an outright ordeal for them. On a trip to Cuba a few years ago I turned my phone on when our plane landed, and didn't even get out of the airport before I had a text from my carrier saying I was up to $100 in roaming charges and they had disabled my data. I remember the not-too-distant past trying to edit through Opera on a flip phone, and recently made one edit from my Wii's embedded browser just to see if it would work - it did but it was frustrating. I still see more Windows XP than ChromeOS in checkuser results, and rarely even older OSes. Ivanvector's squirrel (trees/nuts) 16:43, 15 September 2021 (UTC)[reply]
      Most of the major search engines indicate PDFs (Google, Bing, DuckDuckGo, Yandex, and Baidu do, Yahoo and Ask don't). --Ahecht (TALK
      PAGE      ) 19:47, 25 October 2021 (UTC)[reply]
    • With apologies to those who already knew, the choice of icon is implemented in MediaWiki:Common.css line 510. Help:External link icons#Custom link icons informs us that The image must be 16 pixels wide and cannot be SVG format. (That's in an example about adding a custom icon for .xls, but I assume it applies to .pdf too). From my rather basic knowledge of graphics, .png may be the best format for this use case. Certes (talk) 22:52, 8 September 2021 (UTC)[reply]
      Certes, I had already mentioned Common.css above, but you inspired me to add an anchor to the line number. — Alexis Jazz (talk or ping me) 23:02, 8 September 2021 (UTC)[reply]
      @Certes: Really, SVG is the best format because it is the most scalable (imo). –MJL ‐Talk‐☖ 05:06, 9 September 2021 (UTC)[reply]
      Normally, yes, but the software doesn't seem to accept SVGs here. Also, if it's shown at a fixed 16px, we should probably optimise for that, e.g. align the paper edges and the orthogonal lines of the letters mid-pixel. If the day comes when MediaWiki renders an SVG at 128px on our 16k holodisplays, we can replace the icon again. Certes (talk) 10:19, 9 September 2021 (UTC)[reply]
      When it says "cannot be SVG format", I suspect that refers to the URL used. So https://upload.wikimedia.org/wikipedia/commons/c/cb/Icons-mini-file_pdf.svg would fail, but https://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Icons-mini-file_pdf.svg/16px-Icons-mini-file_pdf.svg.png would be ok. For that matter, the restriction on SVG may be outdated (it was written in 2011), or may have been because someone's browser in 2011 didn't support SVGs there, or may be to avoid explaining that the SVG's intrinsic size needs to be 16px; at any rate, I tested it and it seemed to work fine. But I do agree that optimizing the icon for the size would be a good idea. Anomie⚔ 11:51, 9 September 2021 (UTC)[reply]
      The "restriction" is outdated. We have been serving SVGs via TemplateStyles for CS1 for a year or two now. My guess is that it is related to IE8 and lower, which MediaWiki no longer supports. The page pointed to by Certes should be updated. Izno (talk) 18:58, 9 September 2021 (UTC)[reply]
      But if you're using the png rendering of an SVG file, you get all the downsides of an SVG (e.g. blurry lines and fonts) with none of the advantages of it being scalable. --Ahecht (TALK
      PAGE      ) 13:14, 24 September 2021 (UTC)[reply]
    • Option 2 I think File:Icon_pdf_file.png is a much better replacement, is very readable, and is simple. This is the obvious choice for me. DiamondIIIXX (talk) 03:47, 9 September 2021 (UTC)[reply]
    • Comment This may seem like an odd question but, why is the file in a .gif format anyways? Aren't .gif format files used for animated images? But I support Option 2, per the above discussion. The current file makes it seem like the file is in Adobe Acrobat (which, a few years ago, that was probably the only way to view PDFs) when really it can be viewed in many places besides Adobe Acrobat. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:06, 9 September 2021 (UTC)[reply]
      GIF format was long used for images on computer networks, pre-Internet, pre-Web, and up to now. Due to patent issues (which are no longer applicable as the patent in question has expired), there was a push to move to PNG format, and JPEG became popular for photos due to better compression and appearance (both due to higher resolution colour not being limited to only showing 256 colours and its compression algorithm being a better fit). GIFs remained in use for animated images as the original PNG specification did not support this capability. The current image being a GIF is reflective of how long ago it was put into place. isaacl (talk) 19:27, 9 September 2021 (UTC)[reply]
      Ah ok, thanks for informing me! I've always know .gif format files as being animated images so I was confused when I saw that the current image we're using was in the .gif format but wasn't animated. @Isaacl: Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:31, 9 September 2021 (UTC)[reply]
    • Option 1 as an improvement, until someone thinks of something which is equally clear and less like its own logo. DGG ( talk ) 06:33, 10 September 2021 (UTC)[reply]
      I'm confused as to what you mean. Many people have already thought of something equally clear and less like a logo. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 13:07, 10 September 2021 (UTC)[reply]
    • I'm not going to pick an "option" because at this point there are too many icons going around, but I support using some sort of SVG icon (preferably without the Adobe logo) that's CC0 (or similarly) licensed. I don't prefer any particular icon. Tol (talk | contribs) @ 21:14, 10 September 2021 (UTC)\][reply]
      @Tol: Option 2 does not require a commitment to any particular proposed icon. All it means is that you are against File:Icons-mini-file pdf.svg  and are also against File:Icons-mini-file acrobat.gif . That sounds like where you are basically at right now. –MJL ‐Talk‐☖ 06:34, 12 September 2021 (UTC)[reply]
      @MJL: Ack, my mistake. Option 2 sounds good. Tol (talk | contribs) @ 17:39, 12 September 2021 (UTC)[reply]
    • Question Have we asked Adobe what they will allow? I quickly skimmed https://www.adobe.com/legal/permissions/icons-web-logos.html and thought I need to ask someone with expertise in copyright law. Vexations (talk) 22:24, 10 September 2021 (UTC)[reply]
      Does it matter? If we don't want to use one vendor's logo for an industry-wide standard, whether they want us to use it is irrelevant. Certes (talk) 22:32, 10 September 2021 (UTC)[reply]
    • Option 2 (use MediaWiki? fallback). I used inspect element to disable the current icon pulled from Common.css, and discovered that the fallback pdf icon is evidently [3]. This is the visual counterpart to the external link icon [4]. I suppose this is a !vote to remove the text in Common.css, and let this fallback icon take its place, since it establishes a nice visual consistency, and doesn't stick out as much as the ones that have been proposed so far, which I don't like. — Goszei (talk) 04:46, 11 September 2021 (UTC)[reply]
    For the sake of illustration in this discussion, I have uploaded the icon I am proposing to Commons; it looks like this: (for comparison, here is the external link icon that appears all over Wikipedia, part of the same MediaWiki set: ). — Goszei (talk) 03:43, 20 September 2021 (UTC)[reply]

    Option 2 (can't close - don't know how to execute), using the letter option mooted above by numerous others. It's clearer, which is really the only basis for decisions we have here Nosebagbear (talk) 15:48, 11 January 2022 (UTC)[reply]

    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Further discussion (PDF icon)

    Since opinions are split and some people noted that further discussion would be needed, leaving this section open. Jo-Jo Eumerus (talk) 16:41, 11 January 2022 (UTC)[reply]

    • There are 15 icons in Commons:Category:PDF icons under Public Domain that are not based around the Adobe Acrobat logo (which was rejected above), listed below in alphabetical order of file name; the ones in italics were mentioned in the above discusison
      • Option 1: File:.pdf OneDrive icon.svg -
      • Option 2: File:Document-303123.svg -
      • Option 3: File:Icon pdf file.png -
      • Option 4: File:Icon pdf.svg -
      • Option 5: File:Icon-354355.svg -
      • Option 6: File:Ilovepdf.svg -
      • Option 7: File:PDF icon black.svg -
      • Option 8: File:PDF icon blue.svg -
      • Option 9: File:PDF icon bold.svg -
      • Option 10: File:PDF icon.svg -
      • Option 11: File:Pdf link icon.png -
      • Option 12: File:Pdf-155498.svg -
      • Option 13: File:Pdf-2127829.png -
      • Option 14: File:Pdf-47199.svg -
      • Option 15: File:Pdfreaders-f.png -
      I think that is too many options for a single RfC so we should try and narrow it down first. Unless anyone has better suggestions I propose a round of approval voting first to find the top 4/5 that people could support, with those being the options in a full RfC? Thryduulf (talk) 18:09, 11 January 2022 (UTC)[reply]
      Seems like a good plan, as I agree that 15 choices is too many. (As an editorial aside, the list could get quickly pruned somewhat by eliminating those which are unusable; some of these are indecipherable to me.) Do we need to first clarify .svg/.png formats? Or do we know that both are equally good (although that seems in some conflict with the note in the RfC close above)? — JohnFromPinckney (talk / edits) 04:52, 12 January 2022 (UTC)[reply]
      At their current sizes, I find all but 3, 9 & 10 nearly impossible to read. 7, 8 and 11 are a stretch, but I can make out the letters. I would have no idea what 6 means to indicate without context. Aza24 (talk) 05:15, 12 January 2022 (UTC)[reply]
      On my device, with my eyes, I can read option 9, and with difficulty 3, 4, and 10. Since I know I'm looking for "PDF", 5, 11, and 12 are on the boundary of recognizability. I could plausibly make out some of the others by removing my glasses and bringing my phone nearer my face, but I'm unconvinced that is the solution we're seeking. Folly Mox (talk) 05:50, 12 January 2022 (UTC)[reply]
      3, 9, 10 are the clearest in terms of legibility and actually conveying meaning. Since I'm aware that I'm on team-letters, one other option should be included which is option 14 that is both legible and would probably be understood over time. The issue is that it makes me think it's powerpoint, but that argument could be had in the 2nd RfC. Nosebagbear (talk) 11:55, 12 January 2022 (UTC)[reply]
      To clarify for any reviewer, 3 is the best of these Nosebagbear (talk)
    • Yes, let's put one contender forward against the incumbent. Legibility is key here; I find 9, 3, 10 easiest to read in that order. Is it worth considering another alternative with the letters in red on white rather than white on red? That could save a couple of pixels at the sides, enabling the letters to grow slightly. I've tried playing around and can't make anything worth uploading but someone with a clue about graphic design probably could. Certes (talk) 14:31, 12 January 2022 (UTC)[reply]
      I think any colored text makes it harder to read the letters at such small size. I prefer something like 11, perhaps 9 with plain black text. MB 14:48, 12 January 2022 (UTC)[reply]
      Black lettering on 9 would work too, though readers may associate the red-white-black palette with PDF. Certes (talk) 14:56, 12 January 2022 (UTC)[reply]
      Maybe 9 with black text and a red outline of the document symbol is a way to get some red in there. MB 15:21, 12 January 2022 (UTC)[reply]
    • 3, distant second:9. — xaosflux Talk 15:11, 12 January 2022 (UTC)[reply]
    • For me 3 is the most clear, with 9, 10 and 11 readable but noticeably less so. Thryduulf (talk) 15:55, 12 January 2022 (UTC)[reply]
    • I don't have clear preferences on what should be the one we should adopt, but I have some arguments against 2, 6, 7, 8, 11, 12, 14, 15.
      • The word "PDF" in 7 & 8 are simply not legible at all, and have an overall bad contrast.
      • 11 & 12 look good on zooming in but on my screen, they can be easily overlooked if one isn't searching for a logo on there.
      • 14 & 15 are not quite associatable with PDFs in general. The huge "P" in 14 makes it appear more like MS PowerPoint logo than PDF. In option 15, the average person will associate the green very closely with spreadsheets rather than PDFs (thanks to Excel & GSheets), plus the word "PDF" on it is too small to be legible.
      • 2 appears more like a basic Windows notepad app, again the word "PDF" is not legible either.
      • 6 is the logo of ilovepdf.com and shouldn't be used due to the very reasons some editors already raised regarding the Adobe relation in current one. Also, what does a reader coming across a random heart symbol in a certain external link understand of it? ---CX Zoom(he/him) (let's talk|contribs) 19:25, 12 January 2022 (UTC)[reply]
    • On my laptop, I find 3 the easiest to read, then 10, then 9, then 11. 7 and 8 possess bad color combinations, options 4 and 12 are too small, and the others just don't look right, especially option 6. ResPM (T🔈🎵C) 00:01, 13 January 2022 (UTC)[reply]
    • 3 if we're going to use an image, but I think of a Google-like text tag is still better. If we are using an image, there's no advantage to using an SVG if mediawiki is going to convert it to a raster image anyway. --Ahecht (TALK
      PAGE      ) 18:40, 13 January 2022 (UTC)[reply]

    meta:Community Wishlist Survey 2022/Larger suggestions#1%

    A simple proposal to allocate 1% of the yearly budget to the Community Tech team. Headbomb {t · c · p · b} 00:34, 11 January 2022 (UTC)[reply]

    Proposal to upgrade search feature

    Here is my idea for discussion. Often there is a variant when someone writes a word in the wrong font in the search bar, for example, he uses the Latina font, but Cyrillic is needed. In this case, Wikipedia can't find anything right now. It would be useful to implement a search function when Wikipedia suggests some variations of articles as if it were the correct font. For example: there was wrote "djlf", but you need "вода" ("water"). The feature was implemented in Google search many years ago.Дмитрий1515 (talk) 15:58, 13 January 2022 (UTC) (talk • contribs) 19:09, 12 January 2022 (UTC)[reply]

    I think that the Wikipedia search function is pretty useless on many counts as well as this one, so it is better to perform a site search with your favourite search engine anyway. This is just one of the features that would be useful to readers of this site and wouldn't cost much to implement, but the WMF prefer to spend the vast amounts of money that they receive from the public on expansion of their role and self-perpetuation. Phil Bridger (talk) 19:27, 12 January 2022 (UTC)[reply]
    In the particular regard of the search bar, I think there is more of a persistent fear to do anything with it. The knowledge project had such dramatic outcomes that I suspect it's poisoned the well in terms of additional search functionality expenditure. Nosebagbear (talk) 13:41, 13 January 2022 (UTC)[reply]
    This would be better to suggest at meta:Community Wishlist Survey 2022. --Ahecht (TALK
    PAGE    ) 18:43, 13 January 2022 (UTC)[reply]

    Discussion at meta:Requests for comment/Stop accepting cryptocurrency donations

     You are invited to join the discussion at meta:Requests for comment/Stop accepting cryptocurrency donations. {{u|Sdkb}} talk 20:56, 13 January 2022 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1065848427"