Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
Help deskVillage pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P· COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.


Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Proposal typing aid[edit]

When somebody uses e.g. the de:WP it should be well known that there are many 'search' abbreviations; as an example, H:T will make some suggested expansions, like Hilfe:Tabellen, or H:V like Hilfe:Vorlagen. That simplifies the access to many pages - not only to Help pages.
Spoiled by such comfort, I am missing a comparable service in the commons, where I am doing a lot. On busy days I type hundreds times the long namespaces Template: or Category:, wishing it would as well be possible with only T: or C:. To install such a possibility could not be a problem to the relevant people!
In the English language, many terms are pleasantly short (Help, File, User); really longs things are abbreviated (i18n); I just miss the mentioned cases - therefore I ask the community about that idea. -- sarang사랑 15:07, 16 June 2019 (UTC)

@Sarang: C: is not desirable because this is the recommended interwiki code for Commons. We have COM:, templates can be linked with {{Tl}} and when using templates you don't usually need to enter Template:. See also COM:Shortcuts. - Alexis Jazz ping plz 16:20, 16 June 2019 (UTC)
Thank you. Ok, C: is not desirable, I understand that it is the wrong example. But when I want to enter a special template, or category, I always have to type the full namspace: first. I know that we have short-named templates, like {{C}}, {{F}}, {{T}}, {{U}}. But that's only for using/linking them - not for searching. -- sarang사랑 16:41, 16 June 2019 (UTC)
I opened a Phab ticket a while ago for "Have searchbox recognize {{ to search Template: namespace". DMacks (talk) 13:09, 30 August 2019 (UTC)
  • Symbol support vote.svg Support aliases T for template, CAT for category, and MOD for module. 4nn1l2 (talk) 20:21, 16 June 2019 (UTC)
    @4nn1l2: I think T could be risky with possible future interwiki shortcuts. - Alexis Jazz ping plz 20:28, 16 June 2019 (UTC)
    @Alexis Jazz: I guess that is the problem of future, not now. In my opinion, WMF already hosts too many projects, and new projects should not be added too easily, and I guess we have not had a new project for many years (excluding Wikidata). 4nn1l2 (talk) 20:42, 16 June 2019 (UTC)
  • Symbol support vote.svg Support the aliases mentioned by @4nn1l2, plus U for User, F for File, and T suffixes for associated talk namespaces (UT for User Talk, GT for Gallery Talk due to conflict with Template).   — Jeff G. please ping or talk to me 20:33, 16 June 2019 (UTC)
  • Symbol support vote.svg Support - Why not ? I'm too lazy to write the full word. -- Eatcha (talk) 10:29, 18 June 2019 (UTC)
  • I only support t for template and cat for category. Inclined to oppose the others. Use shorthands only for the most frequent words.--Roy17 (talk) 19:02, 18 June 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 10:02, 20 June 2019 (UTC)
  • Symbol support vote.svg Support, but with reservations, mostly because of the multilingual nature of Wikimedia Commons, we should try to support as much language as possible while trying to avoid confusion while implementing this. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:14, 21 June 2019 (UTC)
  • Symbol support vote.svg Support CAT for categories would be very useful --Ruthven (msg) 14:31, 13 July 2019 (UTC)
  • Symbol strong support vote.svg Strong support. -- 06:14, 25 August 2019 (UTC)

Close inactive non-English village pumps[edit]

Inactive VP are like ghost towns. Posts on those don't get answered in time. We may consequently miss out issues or lose the minority users. Therefore, I would like to make three proposals:

  1. Close inactive non-English village pumps. (As part of the process, resolve any unanswered requests or move them to major VP.)
  2. Merge all non-English help desks into their respective VP.
  3. If a certain language version were to be revived or created anew, it must receive community concensus first.

And some technical suggestions:

  1. Remaining ones should be opted out of message delivery, unless the community agrees to opt in. The messages are more like spam that make real discussions harder to find.
  2. Archives to be done on request only (by inserting {{Section resolved}}) or automatically after no response for min. 2-3 months. Archives should be set up per year (preferably) or per 250K+ bytes. (Prompted by the Commons:Köy çeşmesi, archived automatically for 7-day-old posts and set up per month... ridiculous settings for a minor forum.)

--Roy17 (talk) 20:39, 25 June 2019 (UTC)

  • Mea culpa — I just added to my watchlist all those VPs whose languages I can contribute in adn might need a helping hand (so, not fr and es). -- Tuválkin 23:15, 25 June 2019 (UTC)
Adding to the top, IMHO, the main VP and help desk are not reserved for English but they serve as centralised noticeboards. Only if threads in a certain language overwhelm the primarily Engish VP, should the language have its separate place. It's not the other way around, that each language automatically deserves a place, and now I am being Anglocentric and killing them. VP and HD are meant for reporting issues and solving problems but not general Internet forums.
Another reason to open a minority VP could be using it like classified ads, but I doubt how effective this is. Rather than posting here, users should take the matter to the more popular local wikis.--Roy17 (talk) 17:23, 28 June 2019 (UTC)
  • No opinion on the matter in general, but existence of two separate Serbian boards Commons:Трг and Commons:Trg is a patent absurd; let alone both are inactive. Merge all such stuff into one Serbo-Croatian (or Croato-Serbian, if one likes it more) village pump. Incnis Mrsi (talk) 09:17, 29 June 2019 (UTC)

The ones to keep[edit]

I think the following languages can be kept: the six working languages of UN, German, Japanese, Portuguese, Italian, Dutch, Persian.

Borderline (some activity, but not all posts get answered, and some of their population is relatively small): Czech, Hungarian, Polish, Finnish, Ukrainian, Bengali, Hebrew.--Roy17 (talk) 20:39, 25 June 2019 (UTC) +Korean, Turkish.--10:51, 27 June 2019 (UTC)

In my opinion, whether a forum is active or useful, does not depend only on the number of new posts, but also on whether experienced users are present to help. If not enough native speakers monitor the forums, it's better for newbies to ask on the main help desk/VP. A solution is, interested users can sign up to monitor a forum and be listed at the top of the page. If issues are not answered in time, newbies could go directly to those users' talk pages. The Commons community also knows whether a forum is actively maintained by experienced users. (This list is redundant for languages that obviously have large active userbases, e.g. Dutch.)
Btw, there are no signs of native speakers' activity on the Greek Commons:Αγορά and the Thai Commons:สภากาแฟ, even though these languages have hugh population. Everything is bots' spam or non-Native speakers' appeal for help. I'd say Close.--Roy17 (talk) 10:51, 27 June 2019 (UTC)
The Serbian forum in two scripts, if kept, should be considered for unification like how the Chinese Commons:Village pump/zh is implemented.--Roy17 (talk) 11:00, 27 June 2019 (UTC)
  • Symbol keep vote.svg Keep ALL of them, there is a chance that these village pumps will become active in the future and for speakers of these languages these village pumps might be their only gateway to help, even if interaction is sparse (to put it at best). We should fight the Anglocentrism of Wikimedia Commons, not enforce it. A common problem many people have is that if they don't speak English then they won't be able to contribute here. It is better to editprotect largely inactive village pumps until a speaker requests access than to outright delete it, I just don't see the benefits of deleting any village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:45, 28 June 2019 (UTC)
    • Pictogram voting comment.svg Addendum, and as usual, the conversation regarding the fate of many non-English speaking communities is wholly conducted in English excluding the people whom this proposal concerns, this only shows the extend of the current Anglocentrism of Wikimedia Commons and Wikidata. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:48, 28 June 2019 (UTC)
      At least Commons:Čaršija satisfies COM:CSD#G1 (nothing meaningful). 4nn1l2 (talk) 16:00, 28 June 2019 (UTC)
      When there is no native speaker (especially experienced ones) around, it makes no difference if you reply to them on their version or on the main VP in English or anything but their mother tongue, but it does make a difference for them not to be guided to a ghost town, and have their messages discovered months or years later by wandering scavengers like me. The main VP and help desk are not reserved for English either.--Roy17 (talk) 17:05, 28 June 2019 (UTC)
  • The proposal by 4nn1l2 seems reasonable. I support it. --Steinsplitter (talk) 16:12, 28 June 2019 (UTC)
  • Symbol keep vote.svg Keep ALL of them per Donald, and encourage knowledgeable native speakers of languages other than English to contribute to, or at least watchlist, the village pumps of their native languages.   — Jeff G. please ping or talk to me 18:43, 28 June 2019 (UTC)
  • Symbol keep vote.svg Keep. If you're concerned about people posting to these pages not getting answers, put them on your watchlist and answer them. Forcing non-English speakers to negotiate the English Village Pump to get a response is backwards.--Prosfilaes (talk) 04:09, 29 June 2019 (UTC)
  • Symbol keep vote.svg Keep ALL of them I agree with Donald.--Vulphere 14:13, 29 June 2019 (UTC)
  • Symbol keep vote.svg Keep them all, per Donald and Jeff and Prosfilaes. -- Tuválkin 14:36, 29 June 2019 (UTC)
  • Symbol keep vote.svg Keep ALL of them per Donald. Move the VP to the major ones? So, you think people can just move to Spanish or English VP? Most part of the world do not speak English. Better keep those VP than force people move to a VP in a language they do not understand. --Sahaquiel - Hast du eine Frage? Coat of arms of Germany.svg 22:28, 30 June 2019 (UTC)
Questions @Donald Trung, Jeff G., Prosfilaes, Vulphere, Tuvalkin: may I ask for a confirmation that your Keep All means you support keeping Commons:Čaršija? How many of you visited this page before you said Keep All?
And how many of the 50+ VP have you visited, and checked their histories to see their activity?--Roy17 (talk) 15:01, 29 June 2019 (UTC)
I saw it, while I cannot endorse it's creation in its current form I do think that such village pumps have potential, it should best be improved to match this page and some basic copy-pasting might suffice. I think that these village pumps largely suffer from a lack of communication between Wikimedia Commons and their respective Wikipedia's, there isn't that much cross-wiki communication. For example "Commons:De Kroeg" links to this page (current version) but not vice versa. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:35, 29 June 2019 (UTC)
Please don't ping me on general boards like this. When you propose 50+ pages for deletion, you can't expect people to look at every one; expect responses to the general principle. I watch one of the pages you propose for deletion, and see no reason at all to deprive Esperanto speakers of a page to communicate on Commons.--Prosfilaes (talk) 18:48, 29 June 2019 (UTC)
@Prosfilaes: I proposed Closing, not deletion. The general principle would be marking pages with {{Historical}}. And out of 50+ VP, my stand is 21 of them can be kept, so I did not propose 50+ pages for deletion. Not 50+, not deletion! I always expect thoughtful discussions.
Esperanto VP had seven threads in 10 years. Only two of them are not massive news delivery. I dont seem to see your effort at maintaining the VP either.
Could you please clarify then, whether you backtrack on Commons:Čaršija? If thst's the case, what about Commons:İniy dew?--Roy17 (talk) 19:09, 29 June 2019 (UTC)
The distinction between "closing" and "deleting" here is uninteresting; either way you make an interactive page unusable. The distinction between 50+ and 29+ is rarely interesting.
People who argue against the death penalty don't get into the details of what w:Bobby Joe Long did, so no, I refuse to be drawn in on a discussion of specific Village Pumps. I believe there's value in having a page where people who don't speak English can feel comfortable posting on instead of demanding they go to the Village Pump. If by thoughtful discussion you mean discussion that starts with the same assumptions as you, you're going to be oft disappointed and oft unfair.--Prosfilaes (talk) 03:55, 1 July 2019 (UTC)
  • Roy17, you may ask for a confirmation, and that is now given. Your gotcha question is noted and dismissed, as this is a matter of principle. What all these pages need is a few active Commoners who are fluent speakers of their languages to watchlist them, making sure that any enquiry is replied to. Considerations about the number of such enquiries are irrelevant (and, frankly, feels somewhat meanspirited); this is not costing anyone anything, so lets just make it work. -- Tuválkin 05:17, 2 July 2019 (UTC)
@Tuvalkin: Those were honest questions, but you answered only the first one. I am sorry that you chose to interpret them in a negative way. Commons:Čaršija is subject to speedy deletion per G1, but since some users confirm they support keeping it, a DR will be necessary. I am looking forward to your opinions in DR.--Roy17 (talk) 10:15, 2 July 2019 (UTC)
  • I am getting flashbacks to the whole Portal discussion over at en-wp. --HyperGaruda (talk) 16:38, 29 June 2019 (UTC)
Now two weeks after the keep all votes, what has the users enthusiastic about linguistic diversity done to help resolve the cold cases on each board? Btw, which is worse, replying on their local boards in foreign languages, or asking them to post on COM:VP in their native languages?--Roy17 (talk) 17:21, 13 July 2019 (UTC)
  • Symbol keep vote.svg Keep all but merge zh-s & zh-t into a single vp. (Talk/留言/토론/Discussion) 06:35, 12 August 2019 (UTC)
  • I think Chinese is the worlds most spoken language, so we should close all other boards including the English version and communicate on the Chinese board. The editors of the board are likely to accept postings in other languages as well, so there is no need to be worried about other languages.--Giftzwerg 88 (talk) 21:53, 14 September 2019 (UTC)

Help desks[edit]

I'm splitting off the suggestion about help desks. {{Lang-HD}} is a bit misleading: most languages just redirect to their respective VP, while only English, French, Japanese, and Mirandese(nope, Mirandese redirects to the Portuguese VP) have separate Help Desk pages. --HyperGaruda (talk) 07:06, 29 June 2019 (UTC)

  • Mirandese should either have its own VP, or redirect to Asturian VP. (Just like a link to, say, a non-existent Flemish VP should redirect to Dutch VP, not to French VP.) -- Tuválkin 14:34, 29 June 2019 (UTC)

Action plan[edit]

The following should be carried out step by step regardless how users above want to keep the talking shops:

  1. opt all forums out of automatic message delivery, unless speakers of that language explicitly approve of opt-in.
  2. answer all current cold cases in their languages, English, or any appropriate lingua franca.
  3. one-off archival of everything.
  4. set up automatic archiving (by year) for future posts.

Step #1 and #2 can be begun right now.--Roy17 (talk) 22:43, 4 August 2019 (UTC)

Done for Hungarian and Finnish, as there is activity and there exist users who answer posts in time.--Roy17 (talk) 19:32, 28 August 2019 (UTC)

Addition to COM:OVERWRITE: no image optimizer tools[edit]

To ✓ Minor improvements, add:

✘ The same file with no change but a reduced file size using tools like PNGOUT, pngcrush, jpegoptim, etc.

I occasionally see users doing this, thinking its useful. For any thumbnail (most on-wiki use) it makes no difference so it saves little bandwidth, does cost some storage, browser compatibility (especially for SVG files) can be altered, metadata and color profiles could be lost, compression is not guaranteed to be lossless and because those users do this by hand, they could be introducing all kinds of errors. If we actually wanted it, we'd have a bot for it or even just have MediaWiki do it automatically. No user should do this by hand. - Alexis Jazz ping plz 01:58, 25 July 2019 (UTC)

No image optimizer tools: votes[edit]

  • Symbol support vote.svg Support as proposer. - Alexis Jazz ping plz 01:58, 25 July 2019 (UTC)
  • Symbol support vote.svg Support, how is this not considered a form of vandalism? (just to be clear, I don't support ever blocking someone over this, people often do it in good faith, but if partial blocks will one day be implemented then I would support limiting WARNED repeat offenders from doing this.) Maybe when someone overwrites an existing file there should be a list of rules displayed like we have for renaming an existing file. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:24, 25 July 2019 (UTC)
  • Symbol support vote.svg Support as reduction of file size is not good in the most cases in general --GPSLeo (talk) 17:36, 25 July 2019 (UTC)
  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 17:48, 25 July 2019 (UTC)
  • Symbol support vote.svg Support.--Vulphere 06:14, 26 July 2019 (UTC)
  • Symbol support vote.svg Support That kind of "optimization" doesn't really seem to help anybody as a) it only increases the storage space used over all and b) the user gets served png thumnails that have been rendered server-side anyway. --El Grafo (talk) 07:27, 26 July 2019 (UTC)
  • Symbol oppose vote.svg Oppose The proposal is much too general and should more specific to a global restriction. E.q. file-format, SVG, s. below or if the optimized file is 3/4 smaller (or other) -- User: Perhelion 00:26, 11 August 2019 (UTC)
  • Symbol oppose vote.svg Oppose I'm unconvinced this is a problem that needs fixing. If you see someone doing something that you consider to be a waste of time, perhaps let them know... but I struggle to see why this is something for which we need to create a rule. Also, there are situations where a file is perversely huge for no good reason - on the other hand, maybe we should just delete them. Storkk (talk) 09:35, 13 August 2019 (UTC)

No image optimizer tools: discussion[edit]

  • Pictogram voting comment.svg Comment altering browser compatibility for SVG can be a good thing if it fixes some of the many commons issues … --El Grafo (talk) 09:40, 25 July 2019 (UTC)
  • Pictogram voting comment.svg Comment It seems most people here have no real clue about the SVG format. A general restriction is absolute senseless here. Some SVG are full of code garbage (e.q. 4 MB vs 40 KB, which can have huge performance impact and can crash the Mediawiki renderer) and that's one of the main points why SVG is not natively support here (not the compatibly issue). phab:T208578 -- User: Perhelion 00:07, 11 August 2019 (UTC)
    • @Perhelion: You misunderstood the proposal. Some further explaining can be added to COM:OVERWRITE though. If you overwrite some 4 MB SVG file with a 4 KB one to stop the Mediawiki renderer from crashing or browser from locking up, you have overwritten it for those reasons. Not to reduce the file size. If a 4 KB SVG is crashing the Mediawiki renderer, you'd also overwrite it. Not crashing the Mediawiki renderer is a change different from reduced file size, so you can overwrite. Removing junk that makes the file hard to edit, thus making it easier to edit, is also a change different from reduced file size. - Alexis Jazz ping plz 07:41, 13 August 2019 (UTC)
      • By that logic, any size reduction of (non-png) files would make them easier to edit. And that change may not be trivial if the edits are being done in bulk (for raster) or by hand (for SVG). Some common sense is always going to be necessary, no matter how many rules we create. Some people are always going to occupy themselves in ways that others think are trivial, and while it may be OK to point out to them why you think that work is trivial or useless, I can't fathom why you'd want to enshrine a prohibition in the guideline. Storkk (talk) 07:54, 14 August 2019 (UTC)
        • @Storkk: "I struggle to see why this is something for which we need to create a rule." I've had to deal with several of them. I felt it would be rather inappropriate to name and shame them. One of them was particularly annoying, and without a rule to point to they fail to see why they are harming the project. And no, not "any size reduction of (non-png) files would make them easier to edit". Reducing a .jpg by 2% does not make it easier to edit. - Alexis Jazz ping plz 09:26, 23 August 2019 (UTC)
          • Wait a second... how exactly are they "harming the project"? Storkk (talk) 09:31, 23 August 2019 (UTC) @Alexis Jazz: (courtesy ping) Storkk (talk) 09:32, 23 August 2019 (UTC)
            • @Storkk: Your ping didn't arrive. I think it has to be on a new line. When they upload an SVG that's turned into unreadable high density rubbish, any user who tries to create a derivative work from that is harmed. (happened to me) When they "optimize" files and it's not lossless, they harm those files. (seen it) When they accidentally swap files when overwriting (because this shouldn't be done by hand), they harm the project. And these things are done for.. no gain whatsoever. - Alexis Jazz ping plz 09:51, 23 August 2019 (UTC)
              • @Alexis Jazz: Thanks - I didn't know that; I thought it just needed to be signed. I believe all of the above fall afoul of policies and guidelines we currently have. Storkk (talk) 10:41, 23 August 2019 (UTC)
                • Maybe this should be about optimizing bitmap images in particular. SVG would be more nuanced, for sure. I have had some of my SVG uploads optimized -- quite legitimately, as the older converter I was using resulted in a needlessly huge file. I have also seen some silly re-uploads of SVGs just to make the file size a tiny bit smaller (even sometimes removing invisible elements that aid in positioning/editing, just to make it smaller). On the other hand, there could be valid changes to make an SVG more readable when editing by hand, or optimizing some of the drawing commands for faster rendering. The rules there should be more nuanced, as some are hand-editable (and thus have readability concerns), and don't have the "lossless" problems that bitmaps do. Carl Lindberg (talk) 15:18, 23 August 2019 (UTC)
                  • As usual, this requires a modicum of common sense and understanding what one is doing: two things that are virtually impossible to ameliorate by creating hard rules. There are very legitimate reasons for potentially reducing filesizes for simple raster images: poor default settings can lead to immense filesizes which can be reduced (often 20 fold or more) by simply using indexed colors and judicious recompression. I have personally experienced this frequently when including screenshots into a PDF produced using LaTeX... losslessly converting the PNGs to indexed color reducing the PDF from dozens of megabytes (quite hard to email) to hundreds of kilobytes (easy to email and share). We should not (IMO) have a prohibition on a step that frequently makes our media easier to re-use without damaging quality, regardless of how frequently this step is also mis-used. Storkk (talk) 16:45, 23 August 2019 (UTC)
                    • Those are fair points. The rule though is more about smaller optimizations like pngcrush, jpegoptim, etc., so uses well outside those areas would still seem to be reasonable. Maybe it should read "The same file with no change but a slightly reduced file size"... but it's possible it would need to be more carefully worded than that too. I know I have overwritten to remove an image profile which prevented display in many browsers. And there could be images with outsize resources internally mostly unrelated to display (excessive thumbnails or metadata or something). Carl Lindberg (talk) 17:26, 23 August 2019 (UTC)
                      • Assuming that the overwrite only slightly reduces filesize, and that it does not have an otherwise deleterious effect that is already prohibited by policy & guideline, I'm back to struggling to see the harm. This whole endeavor (the wikipedias as well as commons and other sister projects) is built on thousands upon thousands of people making small incremental changes that many people would consider trivial. Granted, I personally agree that these particular edits (again, assuming no deleterious effects already prohibited) can be close to pointless... but until I see the actual harm I can't endorse this. Storkk (talk) 18:48, 23 August 2019 (UTC)
                        • It creates another copy of the file, which uses added space. The old file is still stored (though without being able to see its metadata on the file page); we just add a slightly smaller version on top. I mean, if someone changes an 85MB PNG to 82MB with pngcrush, that is a fair amount of storage that is more or less wasted. Oftentimes those tools may accidentally strip some metadata on the way, etc., or may not be lossless. It's somewhat easy to make mistakes with command line arguments, too. Jpegtran has some modes which are not lossless. Reducing the file size significantly (if lossless) is a good thing, but a marginal reduction usually doesn't help much if at all, and just adds more copies of the file to be stored. Using pngcrush etc. just to squeeze a few more bytes out should be discouraged, I think. If it reduces from 85 to say 10 somehow, well that's different. Not sure the best way to get that into the guideline, but this seems reasonable. This is a guideline, not (hard rule) policy. And it would be listed in the "minor improvements" area, whereas the ones that you describe seem far from minor. Carl Lindberg (talk) 19:05, 23 August 2019 (UTC)
  • @Storkk: For another example, see File:Donald Trump official portrait.jpg. This was compressed lossy. An example of just being silly: File:Lichtenstein jpeg2000 difference.png was reduced from 394KB to 391KB. Totally worth it. (luckily this user was very understanding when this was explained)
@Storkk, Perhelion, Clindberg: What if the proposal was adjusted to be a bit more precise:
✓ Lossless file size reduction of at least 50% while preserving all metadata, color profiles and software compatibility. Vector graphics (e.g. SVG) only: the same, but highly generic metadata may be removed, code readability has to be preserved and invisibile guide elements should also be preserved.
✘ File size reduction overwrites that do not meet all those requirements should not be performed without community consensus.
Would that be better? - Alexis Jazz ping plz 20:58, 1 September 2019 (UTC)
Still feels like creating rules for the purpose of creating rules, and I am extremely skeptical that the creation of this rule will be a net benefit to the project. But it appears I'm in the minority. Storkk (talk) 08:27, 2 September 2019 (UTC)

Template:Wrong source[edit]

There is a Template:Wrong license, which is good, but I miss a Template:Wrong source. It seems as there are a lot of files where the users claim that it is "own work" where it clearly is not, such as certain logos etc. Can someone create a template which works exactly like Template:Wrong license, but with the source? Thanks!Jonteemil (talk) 04:43, 14 August 2019 (UTC)

In practice, in years gone by, people would just use the "no source" template for that purpose, although the creation of a "wrong source" would be good. You could probably just copy the wrong lincense template and make adjustments as needed. Killiondude (talk) 19:22, 15 August 2019 (UTC)
@Killiondude: Thanks for your answer. I wonder which template I should copy. Template:Wrong license which just says that it has the wrong license or Template:No source since which says that it has no source AND that it will be deleted in seven days unless sources are added. The graphics are also different. The first one is orange and the second is red with a clear ”THIS IS WRONG” vibe if you know what I mean.Jonteemil (talk) 21:16, 23 August 2019 (UTC)

Allow file movers to suppress redirects[edit]

Give file movers the suppressredirect right and adjust MediaWiki:Gadget-AjaxQuickDelete.js to let them use it to suppress redirects while moving files, to avoid the situation described at Image name swap request.   — Jeff G. please ping or talk to me 14:40, 21 August 2019 (UTC)

  • Symbol support vote.svg Support Obviously, given my comments at AN. As I said there, that this is not available on Commons currently almost seems via technicality, as we have no page mover right, and therefore no user right with suppressredirect un-bundled from the sysop toolkit, while other large projects do. I understand that we don't normally want to suppress redirects at all, and this would, I imagine, mostly be used in the case of round-robin moves (a to c, b to a, c to b). In these cases it seems simple enough just to have some template saying that a redirect was suppressed/the file renamed and replaced. Guidance may need to be updated in that respect, although the current guidance (These redirects should almost never be deleted.) seems fairly straightforward. Even so, we have seven times more file movers than we have sysops, and it seems that someone who is experienced enough to understand the comparatively complex criteria for moving files should be competent enough to know whether suppression is necessary. GMGtalk 14:58, 21 August 2019 (UTC)
  • Symbol support vote.svg Support but I'd suggest having a new user right like "extended file mover" or something on the line just to be safe. (Talk/留言/토론/Discussion) 15:02, 21 August 2019 (UTC)
  • Symbol support vote.svg Support - I too have occasionally had to do moves like this and it's frustrating having to rely on an admin to do it (I could apply to be an admin but I prefer a non-admin easy life tbh). –Dave | Davey2010Talk 18:27, 23 August 2019 (UTC)
  • Symbol support vote.svg Support but would strongly prefer this to go along with a new flag per 大诺史. I can easily envision filemovers persistently forgetting not to leave redirects when they should, and I'd rather not have to remove their whole filemover right. Storkk (talk) 19:00, 23 August 2019 (UTC)
  • I agree with both 大诺史 and Storkk above that it should be a new flag, so Symbol support vote.svg Support this, but as a new flag, possibly for people with a couple of years experience as a file mover with plenty of precedent to require this. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:34, 26 August 2019 (UTC)
  • Symbol strong support vote.svg Strong support: i don't agree with new flag thing but allowing file movers to suppress redirect will be very useful. -- CptViraj (📧) 18:05, 27 August 2019 (UTC)
  • Symbol support vote.svg Support, if someone is trusted with the file mover bit, this should be part and parcel of it. BD2412 T 04:29, 28 August 2019 (UTC)
  • Pictogram voting comment.svg Note The Ajax moving script will not allow the suppression of redirects if a file is in use. There are ways around this restriction but that fact, I believe, is not well known and in any case the suppression of redirects of an in use file should simply not be done. The creation of redlinks by the purposeful suppression of redirects of an in use file would be considered abuse of the right and grounds for removal in my mind. Just thought I would put that out there. --Majora (talk) 21:29, 28 August 2019 (UTC)
@Majora: The guidance at Commons:File renaming#Redirects will surely need to be updated. Happy to help along with whomever wants to sort that bit out. GMGtalk 22:04, 28 August 2019 (UTC)
In use only concerns Wikimedia projects. It doesn't know anything about hotlinks and external references. This needs some script policy about it. See also Commons:File_redirects#Redirects_left_after_a_file_renaming --Zhuyifei1999 (talk) 16:39, 30 August 2019 (UTC)
  • Symbol support vote.svg Support Masum Reza📞 12:54, 10 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose Deleting or suppressing redirects is a very disruptive practice in most cases and there's no need to make it simpler. In the very rare cases where it's appropriate, an admin can take care of it. See also m:Don't delete redirects. Nemo 20:33, 12 September 2019 (UTC)
  • BA candidate.svg Weak oppose I have seen filemovers wanting to get rid of redirects for the wrong reasons. What comes to mind are the misspelled "Caribean" redirects. I'm also not entirely convinced that file movers need to suppress redirects so frequently that admins can't handle it. Perhaps if I can be convinced this is needed more often and potential damage from the removal of redirects that didn't need removal can be kept under control somehow.. Until then, weak oppose. - Alexis Jazz ping plz 20:53, 12 September 2019 (UTC)

Category titles with scripts other than Latin[edit]

FYI, someone wants to add an exception to our categories policy, enabling the use of Chinese characters in certain category names. --HyperGaruda (talk) 09:11, 25 August 2019 (UTC)

I still think that we should utilise Wikidata to have a bot flood-create category redirects using a new template (Exampli gratia "{{Redirect-de}}", "{{Redirect-fr}}", "{{Redirect-zh-tw}}", "{{Redirect-es}}", "{{Redirect-ar}}", Etc.) that will automatically display the redirected text as the category title for users who have set their standard language as something other than English and allow for the search engine to look for these alternative names and the MediaWiki Upload Wizard interface should utilise redirect categories in the same way HotCat does now during the submission form.
This would be the best outcome for non-Anglophones. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:38, 26 August 2019 (UTC)
I think the site could allow non-latin words in such instance. Just wait for one day the interface allow local language display and someone adds an English translation.--維基小霸王 (talk) 01:08, 2 September 2019 (UTC)

To summarize, directly using Chinese would be the most simple and easy to understand way to categorise book scan files. It has the following advantages:

  1. Easier for Chinese users to obtain. Books are only useful if you can understand them. Chinese users will only search in Chinese for books, not in Pinyin. Categorise books in Chinese will get the files noticed by users from a search engine and maximize their visibility.
  2. Using original language will make other language users easier to translate the titles. For example, if you use Google to translate the Chinese title 中國新海軍插圖, you can get the correct translation. [1] But if you translate its pinyin, you can not. [2] (Since the categories themselves will be categorised as such in English, English language users will understand what they are anyway. If a user can't type Chinese and want to refer to a Chinese language category, the user can copy and paste the Chinese title.)
  3. Wikimedia Commons is an international project. While using the widely-used English language in general categories could allow International cooperations, allowing non-latin in some instance like books scans meets its property of internationalization.
  4. Book scan files mainly serve Wikisource. The multilanguage Oldwikisource: use titles for original text in the original language. Also using titles in original language shows consistency across Wikimedia projects.
  5. The easiest way for mass uploaders to create categories. The alternative is to translate the titles to English or Pinyin. The former is an art itself and needs research in each case. The latter is also difficult because many Chinese characters have more than one pronunciation. If dividing pinyin by words, it will require additional manual work. Such useless labour should better be skipped. --維基小霸王 (talk) 01:46, 2 September 2019 (UTC)
I am talking about modifying the policy. And your response is accusing modifying a existing policy is a violation of the policy? --維基小霸王 (talk) 04:35, 2 September 2019 (UTC)
In general, putting in translated descriptions in the category text area should end up in search just as much as the category name. That is generally where translations go, and would be the source for further translations. You can only have one category, as you can't have multiple translated category names and have media show up in the same category page, which is why we have the English-only rule. If someone needs to upload an English translation of that book, what category name should they use? Or Arabic? The filenames themselves can contain the Chinese name, of course, which would also show up in search, usually in preference to the category. Is there a reason why books aren't uploaded in PDF or .djvu format for Chinese, as a base for Wikisource? Those would have the original title. You can put the images in a Chinese-named gallery if desired as well. I'm not sure I understand a concern here which hasn't been brought up before. I guess having a transliterated title is often not that much more understandable than having the title in the source script, and makes it worse for native speakers without adding much for English. But another problem with categories is if there is a need to subcategorize -- managing that gets more difficult if everyone just uses their own scripts. Or creating related categories, like "Characters in <book>" I think your points 1 through 4 are answered by putting in the original title in Chinese in the text area of a category, which would be expected anyways. (Wikisource native titles are in the main article area I think, like gallery names here, not categories.) Not sure that point 5 is worth changing the policy, as it would apply to all languages of course and then why only book names and not people names or movie names or ship names etc. I may not have an issue with creating a temporary category name in Chinese for upload, then redirecting it to a transliterated category name such that the rest of the work is done by bot, to save some busy work on each file, if that helps any. If books are in .pdf or .djvu format, often only one upload is needed per book -- it would be relatively rare I would have thought to need a category just for that book. Carl Lindberg (talk) 15:44, 6 September 2019 (UTC)
  • Symbol support vote.svg Support Though logically, it is not an exception as the policy already states "Category names should generally be in English, excepting some of proper names, biological taxa and terms which don't have an exact English equivalent." There is nothing there that stops the use of non-English and non-Latin character sets where this makes more sense than bending over backwards to transliterate into pseudo English. As reminder, the tendency to stick to "English" for categories was a Jimmy Wales championed thing from over a decade ago. It's very Americano-centric, and 2019/2020 might be a good time to put together an example case book and have a RfC about making this a better policy and help reduce the classic historical colonial legacy that exists in our infrastructure and recognize that American English does not need to remain our communication default for infrastructure and fundamental structure like categories. -- (talk) 17:15, 6 September 2019 (UTC)
  • Symbol oppose vote.svg Oppose - Commons:Language policy does not mention anything explicitly about the usage of scripture or writing systems. Only the usage of English is a subject, which ofcourse uses the alphabet. In my opinion this policy could use an update. But the implementation of this policy (and other similar policies) is also one of the real issues. For the sake of convenience and mass production, the policy is often poorly followed. I raised the issue before, but I was completely disregarded. For example: If a file title should be descriptive of it's content and in English or at least in Alphabet script, why then allow file titles that only contain the archival coding of a donating institution? I am literally talking about hundreds of thousands or even millions of files by now. Entire libraries are being uploaded without a descriptive title but also without any proper description. Often the description is no more than just the general subject of the file or even just a repetition of the archival coding. Additionally the box for "author" is being abused to advertise the name of the employee or volunteer who scanned or made a 1:1 (PD) photo the work, in stead of the real author, being for example the painter of a painting. Also they'll only create categories for their institutions, but refuse to help categorize files in the existing Commons categories. Many institutions are using Wikimedia Commons as a cheap storage space, while implementing their self promotion within the process. And the most culpable, I think, is the collaboration that Commons editors provide. They often even defend this way of working. Under the motto that this is how Commons acquires new media. --- Now I'll get back to the specific subject at hand. If you combine the demand for allowing all scripts with the other issues I've been describing, you will end up in the biblical Babylon and Commons Wikimedia will end up in utter chaos while being useless for the end users of the files. I have been noticing that many or even most people who write file names in non alphabet script, also do not add any description in any alphabet script. Combined with names of categories in non alphabet script, how are people who can not understand the text going find out what the content of file is? And how to moderate for abusive language or content, when we mostly depend on community driven moderation? To conclude, I have the opinion, being a non native English speaking person, that the Commons policy should not allow the usage of non alphabet text in file names and categories, while adding an English description should be mandatory when adding a non alphabet script text as a primary description. After all, don't we intend to be a global community of like minded spirits? A community that aims to share content and knowledge for all to use freely? Then accessibility should be at the foundation of all policies. Please speak out if you support me on this. --oSeveno (User talk) 11:26, 8 September 2019 (UTC)
    @oSeveno: I support you on this.   — Jeff G. please ping or talk to me 13:20, 8 September 2019 (UTC)
Only using alphabet script is the contradictory of being global.--維基小霸王 (talk) 04:59, 11 September 2019 (UTC)
  • I'm not sure why we need this proposal. Scripts other than Latin are already allowed, where non-English words are allowed (such as for proper names). Nemo 20:32, 12 September 2019 (UTC)
    Got it.--維基小霸王 (talk) 07:05, 16 September 2019 (UTC)

Proposal to replace Template:Indefblocked-global with Template:Indefblocked-global-WPstyle[edit]

As the creator of Template:Indefblocked-global-WPstyle, I vow to replace the legacy {{Indefblocked-global}} with {{Indefblocked-global-WPstyle}}. After the legacy template gets replaced, the WPstyle template will be renamed to "Template:Indefblocked-global". Calvinkulit (talk) 14:07, 6 September 2019 (UTC)

  • Pictogram-voting-question.svg Question: Did you copy this new template from enwiki? -- CptViraj (📧) 04:47, 8 September 2019 (UTC)
  • Pictogram-voting-question.svg Question: Could you add some explanation at the template page on what the template is about? I understand it, but not everyone will. Also, the template could contain a link to a page explaining what the block means or how to appeal. For general accessibility reasons. Then I'll support your proposal. Kind regards, --oSeveno (User talk) 11:32, 8 September 2019 (UTC)
  • @CptViraj, OSeveno: 1. I copied it from enwiki. 2. It's the same as the legacy template, only that it has more flexibility. Calvinkulit (talk) 06:15, 10 September 2019 (UTC)
@Calvinkulit: The lack of extra information is one of the reasons that Commons/Wikipedia has such a steep learning curve for newcomers. I'd like us all to help do something about that. It only requires a little extra effort. --oSeveno (User talk) 10:30, 10 September 2019 (UTC)
@OSeveno: Fixed, check it out. Calvinkulit (talk) 11:17, 10 September 2019 (UTC)
Symbol support vote.svg Support Thanks! It's really well done. I now fully support your proposal. Regards, --oSeveno (User talk) 11:49, 10 September 2019 (UTC)

@Masumrezarock100: I tried to make a French translation, but it failed. Calvinkulit (talk) 01:51, 11 September 2019 (UTC)

@Calvinkulit: To translate a page, first it needs to be marked for translation by a translation admin. Masum Reza📞 04:20, 11 September 2019 (UTC)
@Calvinkulit: marked for translation. MorganKevinJ(talk) 04:55, 11 September 2019 (UTC)
@Calvinkulit: I have made a translation into the Dutch (Netherlands) language. --oSeveno (User talk) 11:38, 12 September 2019 (UTC)

The picture of the location of temperate rainforest File:Temperate rainforest map.svg have the mistake。 温带雨林地点图片有事实性错误[edit]

The picture of the location of temperate rainforest Temperate rainforest map.svg ( have a mistake. The location of the temperate rainforest means most of this mostly in oceanic moist regions, and in the temperate zone. As a result, the location in P.R.China is not the temperate rainforest. The right picture (my evidence) is : DellaSala, D.A., 2011. Temperate and Boreal Rainforests of the World: Ecology and Conservation. Island Press

温带雨林地点图片有事实性错误。 ( 中国云南的那一块不是温带雨林。 证据(正确的图片)在:

DellaSala, D.A., 2011. Temperate and Boreal Rainforests of the World: Ecology and Conservation. Island Press
— Preceding unsigned comment added by Tangmingxyz (talk • contribs) 12:37, 9 September 2019 (UTC)

More Of This ⬅️, Less Of That ➡️[edit]

I'm curious if there is a section on Wikimedia Commons or Wikipedia where users can specify images that they need more of or a specific image that is needed to fill an article?

For instance, it would be great to have a picture of an Icosahedrite (I'm a geologist and recently read this article) to go on this page:

Not sure if that exists somewhere but it would be helpful to find photos that need to be taken to fill in gaps on Wikimedia/Wikipedia.--Tenace10 (talk) 14:50, 9 September 2019 (UTC)

@Tenace10:, technically there is "Commons:Picture requests/Requests", but in reality these requests are rarely answered. Personally I'd rather see some sort of category which uses either local Wikimedia websites or Wikidata that creates a list of topics needing images and that this category can be sub-divided into multiple subjects which people can patrol. It might be wise to devise a better system, I do know that the English language Wikipedia has a "Picture needed" template, but I am not aware of any active photographers trying to tackle these huge backlogs. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:19, 10 September 2019 (UTC)
Thanks Donald, this is really helpful. I'd imagine there is a constant and large backlog of images that would be great to have on the platform. But this gives me a good place to start looking!--Tenace10 (talk) 15:17, 11 September 2019 (UTC)

Make the Confirmed right automatically revoked after the account is 4 days old[edit]

The Autoconfirmed right will get applied after the account is 4 days old on this wiki, so Confirmed would be redundant. With this change, there will be a new filter that automatically revokes the Confirmed right if the user is 4 (or more) days old. Calvinkulit (talk) 02:36, 12 September 2019 (UTC)

Symbol support vote.svg Support but I am not sure filters can do such things. Masum Reza📞 04:49, 12 September 2019 (UTC)
Pictogram voting comment.svg Comment This only concerns 0 users, they can easily be dealt with by hand. - Alexis Jazz ping plz 10:41, 12 September 2019 (UTC)
@Alexis Jazz: So a request to a moderator to have this taken care of should be sufficient? --oSeveno (User talk) 11:42, 12 September 2019 (UTC)
@OSeveno: I think so. - Alexis Jazz ping plz 14:17, 12 September 2019 (UTC)
@Alexis Jazz: Already done at COM:RFR. Calvinkulit (talk) 15:52, 12 September 2019 (UTC)
Pictogram-voting-question.svg Question Why do users with confirmed rights get the autoconfirmend rights? Would it not be possible to say that users with confirmed rights do not get the autoconfirmend rights and stay with that confirmed rights till they get other rights? --GPSLeo (talk) 11:46, 12 September 2019 (UTC)
@GPSLeo: Before, when a confirmed user gets autoconfirmed, the confirmed right would be revoked. And that practice is still here today. Also, the autoconfirmed right is permanent compared to the confirmed right as special rights like the Confirmed right get revoked when the person gets blocked from editing. But, revoking the Confirmed rank from a person that is already autoconfirmed is like trying to battle with your own shadow. Calvinkulit (talk) 11:57, 12 September 2019 (UTC)
Pictogram voting comment.svg Comment Made a task for it: Automatically remove confirmed user right when eligible for autoconfirmed. This isn't specific to Commons. - Alexis Jazz ping plz 16:24, 12 September 2019 (UTC)
@Alexis Jazz: Thank you. Calvinkulit (talk) 02:49, 13 September 2019 (UTC)

Make Autopatrol automatically given once the user hits the 30/500 mark[edit]

As a user that just hit the 30/500 mark, I believe that Autopatrol should be automatically given when someone hits the 30/500 mark, much like how the same 30/500 rule gives the extendedconfirmed right in Wikipedia. Calvinkulit (talk) 09:13, 16 September 2019 (UTC)

  • Strong Symbol oppose vote.svg Oppose - Autopatrolled right isn't like the extended confirmed user right. Autopatrolled allows users to batch upload files upto 500. Only trusted should be given this right. Also it marked one's edits automatically patrolled, inexperienced users can seriously abuse this right. Masum Reza📞 09:26, 16 September 2019 (UTC)
(Edit conflict) Symbol oppose vote.svg Oppose Autopatrolled and extended confirmed is totally different. Extended confirm only gives the user an extra right which allows them to edit "extended confirmed protected" pages. The autopatrol flag should only be given if the user is fit/trusted for it such as recommendation by patrollers, etc. (Talk/留言/토론/Discussion) 09:28, 16 September 2019 (UTC)
  • However, I won't oppose if someone recreates the extendeduploader right. It may automatically be given to an user when they reach about 1000 uploads. IMO, upload by url isn't sensitive. Masum Reza📞 09:37, 16 September 2019 (UTC)