Wikimedia Commons

Commons:Village pump/Proposals/Archive/2021/11

< Commons:Village pump‎ | Proposals

Viewing big images

 

I was looking at this, but couldn't see the details I wanted at the default 797 x 100 pixels. No problem; there's a choice of intermediate sizes leading up to the original 45,354 × 5,691 pixels. Umm, no, the maximum intermediate resolution is 2,560 × 321 pixels. The original image is 17 times that, and a long download. So, it seems to me, the steps between offered display sizes are too rigidly set. The several sizes ought to be customized for the image size, so for a big one like this, the step ratios would not be set at a measly 2:1, but more like 3:1 or even 4:1. Jim.henderson (talk) 01:05, 3 November 2021 (UTC)

I certainly agree that better preset step sizes would be desirable. For reference, you can generate any custom size by changing the url - see here for example. Pi.1415926535 (talk) 01:41, 3 November 2021 (UTC)
Thanks, @Pi.1415926535: always there are more little tricks to learn, and now I've learned another useful one. If we were serious about helping users see large images conveniently I guess the image page would give a choice of the original size, a fixed minimum size, and about three steps in between, to be calculated by the geometric mean or something similar. This would be a template if it's only to be for selected big images, otherwise a feature of either the Upload Wizard or the file viewer. Not that I have a good idea what would be involved in making any of these, but at least now I have an insider trick. Jim.henderson (talk) 14:38, 3 November 2021 (UTC)
@Jim.henderson: Look or the "ZoomViewer" link, on the file page. See also {{LargeImage}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:04, 10 November 2021 (UTC)
Wow, thanks, @Pigsonthewing: the ZoomViewer works very well. It ought to be more prominently displayed. Or, I ought to pay more attention. Jim.henderson (talk) 21:30, 10 November 2021 (UTC)

Should Heavily used template go on the template page or the /doc page?

At Template talk:BookNaviBar#Edit request 2021-11-07 a question came up: should {{Heavily used template}} go on the page of the template itself or on the /doc subpage? To me the documentation of that template sounds like it’s meant to go on the template itself, but maybe people prefer the /doc subpage. This Quarry query finds 158 links to the template from template non-sub-pages and 69 links from /doc subpages; since I assume the 158 links from non-doc-sub-pages include the 69 /doc links (since the templates transclude their documentation), I believe the real distribution is 89 {{Heavily used template}} uses directly on a template and 69 on the /doc subpage. Thoughts? Lucas Werkmeister (talk) 20:40, 10 November 2021 (UTC)

@Lucas Werkmeister: It should go on the template itself, noincluded. However, forcing that on the 69 mentioned above in a short period of time would stress our systems, so it should only be done with blessings of our systems administration team. Technically, the doc is not heavily used.   — Jeff G. ツ please ping or talk to me 05:41, 11 November 2021 (UTC)
Alright, thanks. I’ve declined that edit request, but won’t edit templates that have it on /doc for now. Lucas Werkmeister (talk) 23:35, 12 November 2021 (UTC)
 
Please, think of the server kitties.
@Lucas Werkmeister: You're welcome. Another reason for keeping {{Heavily used template}} on a template itself is that the "the talk page" link goes to the wrong place when it is on a /doc subpage. Pinging @Brion VIBBER as a Systems Administrator and our Lead Software Architect.   — Jeff G. ツ please ping or talk to me 06:26, 13 November 2021 (UTC)
I would say at the /doc subpage, because we should keep the mainpage of the template neat and tidy. It is a common practice on wikipedia site. --A1Cafel (talk) 05:09, 14 November 2021 (UTC)

Separating roles.

I withdraw my proposal now. Illl make this thing perfect in not too long time. --Contributers2020Talk to me here 03:54, 17 November 2021 (UTC)

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.

The administrators in commons have many privileges and work to do. From answering and closing deletion requests to blocking people to delete file to everything. And we have only 200 of them? This depicts the load on them and no decrease in the commons backlog. Deletion request old like 1 year which are obvious are not being closed. And if non-admins close them, they will immediately take action on us(who are non-admins and non favorites of them). I think this type of centralizing is wrong.

  My Proposal- to bifurcate administrator role into some 2 or three.

  What does this mean- Role 1- Deletion administrators will have the privilege to

  • Delete and undelete images and other uploaded files, and to view and restore deleted versions.
  • Delete and undelete pages, and to view and restore deleted revisions
  • Renaming files
  • Send a message to multiple users at once
  • Delete and undelete specific log entries and revisions of pages
  • Merge the history of pages
  • Use higher limits in API queries;

Basically things related to deleting and undeleting and renaming.

Role 2- Community Adminstrator will have the privilege to

  • Block and unblock users, individual IP addresses and IP address ranges
  • Protect and unprotect pages, and to edit Community admin-protected pages
  • Edit less-restricted interface messages
  • Add and remove usergroups
  • View deleted versions
  • Use higher limits in API queries

Basically things related to community things such as handling and having the power to take action in COM:AN and reviewing COM:RFR and COM:LRR.

Role 3- Abuse Filter Administrators will have the privilege to modify abuse filters, not create redirects from source pages when moving pages and import pages from other wikis

  Why- If we bifurcate like this, one set of people will focus on one particular topic and will heavily help reducing commons backlog .Also, 1 user can have only 1 role of the bifurcation, so that the reason of making this thing will be intact.

Please, please consider this issue and make it into action as soon as you can.

Votes-

  Oppose I think this a a bad idea. Admins are expected to be conversant with all policies, but most will take on work most suitable to their interests and talents. So there's no need to have separation because we already have it on an informal basis. Also, pigeon-holing permissions would militate against cross-topic operation. Keep it simple, please. Rodhullandemu (talk) 12:27, 16 November 2021 (UTC)
  Oppose The current situation is simple. Say there's a user who keep creating redundant DRs. Is this a problem user, or a harmful file that needs to be deleted quickly? I'm not sure, but I know that if I report it to an administrator, it will get dealt with appropriately. The same applies to other complex situations.
Splitting administrator privileges into different roles would introduce more complexity into the sorts of situations I described above, as well as the processes for granting, revoking and monitoring these privileges. Surely it is not worth it. Brianjd (talk) 13:26, 16 November 2021 (UTC)
Brianjd, I don't know how is it complex. Granting, revoking privileges- Community Administrator. Deleting files- Deletion Adminstrator. Both groups can cooperate. They are not something like isolated. — Preceding unsigned comment was added by 116.74.135.243 (talk) 13:35, 16 November 2021 (UTC)
  Oppose per Rod & Brian. Why on Gods earth would we want admins who work simply in asisgned areas ? .... If I'm dealing with a vandal I would want them to be dealt with asap - I wouldn't want an assigned admin to eventually come across my request and block like 12 hours later by which time the vandal would've caused a lot of vandalism etc.
In short this is a flawed and a rather ridiculous proposal that benefits absolutely nobody. –Davey2010Talk 00:36, 17 November 2021 (UTC)
  Oppose per Davey. Hulged (talk) 02:02, 17 November 2021 (UTC)
  Oppose per Rod, Brian, and Davey. Not well thought out, still a draft (drafts don't belong here).   — Jeff G. ツ please ping or talk to me 03:23, 17 November 2021 (UTC)

Discussion-

@Rodhullandemu regarding your vote, if administrators are keeping it to their interests and talents, there should be no problem to implement this. Keeping it simple will not solve the backlog. Contributers2020Talk to me here 12:43, 16 November 2021 (UTC)

Yeah, but you won't get people volunteering on the sole basis that what would be able to do is limited. It often happens that sockpuppets, vandals etc upload copyvios and need to be blocked, and related accounts vetted. Separating those functions, are you suggest above, would not be an sensible or efficient thing to do. Rodhullandemu (talk) 12:55, 16 November 2021 (UTC)
Blocking can be done by Community Admin and copyvios by Deletion. Not a big deal. My main thing a administrator will be focused in one place and thus eliminating backlog Rodhullandemu. --116.74.135.243 13:03, 16 November 2021 (UTC) (Im C2020)

@Contributers2020: What would you do with all the existing Admins?   — Jeff G. ツ please ping or talk to me 13:17, 16 November 2021 (UTC)

@Contributers2020: This proposal should reduce the load on administrators, which they should support. The assumption that every administrator will vote "  Strong oppose" indicates that the proposal is flawed. Also, please don't silently change the proposal after users have started to respond to it. You are expected to change the proposal if the responses justify this, but you should clearly state that you have done so. Brianjd (talk) 13:20, 16 November 2021 (UTC)

Brianjd, that was just an assumption. I'll remove that statment. As of the silently changing proposal, I didn't and was just making additional needed mmodification. The fundamental was the same. I was editing this for two hours, and so people.started to respond. I guees I am sorry. --116.74.135.243 13:31, 16 November 2021 (UTC) (I'm C2020)
@Contributers2020: Please stay logged in.   — Jeff G. ツ please ping or talk to me 13:38, 16 November 2021 (UTC)
Jeff G.- Done. So the previous administrators will apply again for the respective post they want to get. This will also eliminate inactive administrators. --Contributers2020Talk to me here 13:41, 16 November 2021 (UTC)
@Contributers2020: We already have Commons:Interface administrators per Special:ListGroupRights. How would their role change, if at all? We also deal with inactive Admins through Commons:Administrators/De-adminship, how would that change, if at all? Some projects also have Abuse filter editors, are you advocating for that here? See also COM:TALK, en:WP:THREAD, and en:WP:INDENT.   — Jeff G. ツ please ping or talk to me 14:02, 16 November 2021 (UTC)
@Jeff G. I'm telling the benefits. And Interface administrators will still continue to exists, translation sysops as well. Only normal administrator role will be bifurcated. And yes, I am advocating that in this project as well. Contributers2020Talk to me here 17:15, 16 November 2021 (UTC)
This also is a draft. My basic and fundamental thing is that admin role is bifurcated in order to be productive. We can still make changes on whatever I have written. Contributers2020Talk to me here 17:17, 16 November 2021 (UTC)
@Contributers2020: Proposals should be drafted locally or in a sandbox, not live on this page.   — Jeff G. ツ please ping or talk to me 14:08, 16 November 2021 (UTC)
The proposal does not include a group that can both block users and perform deletions, which are actions that naturally go together when dealing with abuse.
The inclusion of not one, but two groups that can view deleted material is extremely concerning. In fact, this is being discussed right now in a separate proposal, where serious issues were raised, and the proposal author here has not demonstrated a familiarity with that discussion.
I am sure there are more problems, but as Jeff G. said, drafts do not belong here. Brianjd (talk) 03:38, 17 November 2021 (UTC)
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.

Add Markdown option in "Use this file on the web" dialogue.

Currently, the "Attribution" section of the "Use this file on the web" dialogue gives a plain text option by default, which can be turned into HTML by ticking the HTML box. For example, for this file, the HTML options shows:

<a href="https://commons.wikimedia.org/wiki/File:Carraca_lila_(Coracias_caudata),_parque_nacional_de_Chobe,_Botsuana,_2018-07-28,_DD_30.jpg">Diego Delso</a>, <a href="https://creativecommons.org/licenses/by-sa/4.0">CC BY-SA 4.0</a>, via Wikimedia Commons

As Markdown is widely used on many systems, including to author documents websites and presentations, it would be great to have another "Markdown" option next to "HTML", which would convert the code to:

[Diego Delso](https://commons.wikimedia.org/wiki/File:Carraca_lila_(Coracias_caudata),_parque_nacional_de_Chobe,_Botsuana,_2018-07-28,_DD_30.jpg), [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0), via Wikimedia Commons

Potentially, the UI would end up showing 3 (exclusive) radio buttons to choose from:

  • Plain text (default)
  • HTML
  • Markdown

Chtfn (talk) 00:48, 6 November 2021 (UTC)

  •   Support Not because more choices are always better (there is a cost to build and maintain each option), but because Markdown is indeed widely used, as demonstrated by both the linked article and my experience. Brianjd (talk) 11:56, 9 November 2021 (UTC)
  Support. Could we add wikitext for those wikis that don't use InstantCommons?   — Jeff G. ツ please ping or talk to me 14:18, 9 November 2021 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2021/11&oldid=615026003"