Commons:Village pump/Proposals/Archive/2020/07

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Aggressive wording on speedy deletion template(s)

I think that some of the wording needs to be dialed back on some templates. I just got this. The file (File:Kugluktuk Airport terminal.jpg) was uploaded from Flickr and reviewed by an administrator at the time. It has since been uploaded as a larger file at File:Airport Terminal - Kugluktuk, Nunavut, Canada.jpg. It's not my file and I don't care if it is deleted but the wording on the template posted on my talk page is a bit much. It says, in part, "Wikimedia commons doesn't permit uploading personal files/copyright violations,spams and files without a source/license. If you continue to upload similar files you may have to face some strict administrative actions. Please act wisely!" So I may "face some strict administrative actions" because the file I uploaded was not large enough. Are you trying to drive people away? CambridgeBayWeather Talk 16:25, 4 July 2020 (UTC)

It clearly looks like it was written by a non-native English speaker. Can anyone find this template? I'm not able to find it. -- King of ♥ 17:05, 4 July 2020 (UTC)
@CambridgeBayWeather: This message was left by Deletion Notification Bot, which is managed by Eatcha. It uses subpages of its user page for at least some of its notifications. It looks like you got User:Deletion Notification Bot/SDEL, which is the generic speedy-deletion template. One oddity here is that it's not usual to notify the uploader that a file has been tagged with {{Duplicate}} (well, I don't, anyway), but this file was tagged with {{Speedydelete}} so the bot couldn't tell that it was tagged as a duplicate. --bjh21 (talk) 19:41, 4 July 2020 (UTC)
@King of Hearts: the template is probably this one: User:Deletion Notification Bot/SDEL. I found these similar templates also: User:Deletion Notification Bot/personalNO / User:Deletion Notification Bot/NOADS / User:Deletion Notification Bot/COPYVIO. Eissink (talk) 20:00, 4 July 2020 (UTC).
@CambridgeBayWeather: I agree that the template seems a too aggressive for a duplicate. I removed the "warning" so it does not look bad on your talk page. You can revert if you wanna keep it as a memory. Or remove it completely. --MGA73 (talk) 21:30, 4 July 2020 (UTC)
Thanks @MGA73: . I'm not bothered much about the warning on my page but that it still exists and will be put on, possibly, a new editors page anddrive them away. CambridgeBayWeather Talk 22:06, 4 July 2020 (UTC)
CambridgeBayWeather Sorry, I wasn't aware that duplicates were categorized in speedy deletion category. Removed "If you continue to upload similar files you may have to face some strict administrative actions. Please act wisely!" from the template. // Eatcha (talk) 05:05, 5 July 2020 (UTC)
And I case anybody wants to improve the templates please do so or maybe create real templates but I'm not really good at creating templates. // Eatcha (talk) 05:19, 5 July 2020 (UTC)

UploadWizard: updated design of notices

Hi, I have updated design of notices for UploadWizard to align with Wikimedia Style Guide, can you move changes from sandbox - Template:Upload Help notice/sandbox? :)

Please visit Commons:Help desk if you need to ask questions about uploading files.
Only upload freely licensed or public domain content. Fair use is not allowed on Wikimedia Commons. (help)

Iniquity (talk) 02:08, 31 July 2020 (UTC)

Exhibit 1
@Iniquity: The graphic seems too low in the 2nd box.   — Jeff G. please ping or talk to me 03:22, 1 August 2020 (UTC)
@Jeff G. can you check it now?:) Iniquity (talk) 18:24, 1 August 2020 (UTC)
@Iniquity: Now they're both too low in multiple browsers, see Exhibit 1 at right.   — Jeff G. please ping or talk to me 02:03, 2 August 2020 (UTC)
@Jeff G. which browser do you use? Iniquity (talk) 02:18, 3 August 2020 (UTC)
@Iniquity: On my iPad, I use Puffin Browser Pro (where it looks like that and where I took my screenshot) and Chrome (where it also looks like that). I also fired up Safari (where it looks fine). I then fired up Chrome on my Windows 10 laptop (where it also looks like that).   — Jeff G. please ping or talk to me 02:37, 3 August 2020 (UTC)
@Jeff G. Hmmm, I think I have fixed it, check it plz :) Iniquity (talk) 21:02, 3 August 2020 (UTC)
@Iniquity: It looks good on 3 browsers. Puffin is uncooperative for me at present, probably unrelated to this. Thanks for fixing it.   — Jeff G. please ping or talk to me 13:47, 4 August 2020 (UTC)
✓ Done 1989talk 22:06, 5 August 2020 (UTC)
This section was archived on a request by: 1989talk 22:06, 5 August 2020 (UTC)

Search results with djvu/pdf

It would be good if the page displayed was the title page of the work and not the first page of the pdf (see sample above). -- Jura1 (talk) 11:30, 13 July 2020 (UTC)

This is a duplicate proposal, please see "Commons:Village pump/Proposals#Document display" above, I think there is consensus for it already, all it now needs is technical implementation. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:00, 13 July 2020 (UTC)
I hadn't noticed the above, but that seems to address a slightly different point (what is visible on file description pages). This concerns itself primarily with Special:Search. Obviously both could be solved at the same time, but it's already possible to display the title page on file description pages. Jura1 (talk) 07:56, 16 July 2020 (UTC)

Belize maps for British Honduras timeframe

Should the old maps of Belize in Category:Maps of Belize by year be renamed to Category:Maps of British Honduras since Category:British Honduras covers 1862-1981? For example, Category:1861 maps of Belize goes into Category:1861 in Belize which would go into Category:Belize in the 1860s but in contrast Category:1900 maps of Belize goes into Category:1900 in Belize (I just created) which is a subcategory of Category:Belize in the 1900s which redirects to Category:British Honduras in the 1900s. Break the decade redirect with separate categories or rename the whole thing to British Honduras? I think it makes more sense to rename the map categories to British Honduras since it's the exact same area. If so, then I'll start on the complicated renaming suggestions (including the older Category:British Honduras in the 1820s which don't actually make sense). -- Ricky81682 (talk) 21:31, 5 July 2020 (UTC)

@Ricky81682: It's a bit more complicated I'm afraid. What we now refer to as "Belize" became an independent country in 1981. However, the name of the territory was officially changed to "Belize" in 1973 and it's been unofficially known as "Belize" (including on maps) since at least the early 1800s. In the 1700s, it was known as the "territory allotted to English settlers". Not sure how any of that should be reflected in our map categorization. Kaldari (talk) 17:00, 6 July 2020 (UTC)
Also the whole Category:Maps of Belize by year tree should be deleted anyway, as there is very rarely more than 1 map of Belize per year. It only serves to make the maps harder to find. Kaldari (talk) 17:01, 6 July 2020 (UTC)
@Kaldari: Many times we just use the current location names so I'd suggest call it "maps of Belize" for them (Germany as an entity didn't really exist in the 17th century or earlier). Keeping it limited to the exact 1862-1981 definition may be the cleanest option. Luckily the borders are the same or it gets really, really ugly fast. As to the yearly maps, that's rare for the older maps I agree but for the recent years (2000s and 2010s), I expect a lot of maps for different cities and states and there may be a few years with an absurd number of maps (you can always find an oddball like Category:1864 maps of Virginia) but I agree, we have way, way too many maps split to the individual year for some reason. -- Ricky81682 (talk) 21:24, 6 July 2020 (UTC)
Personally I'm in favour of using contemporary names and then using modern names as redirects, unfortunately the MediaWiki Upload Wizard doesn't work well with redirects, but for now it's more of a technical limitation than a practical one. As for Kaldari's statement regarding the category tree making specific maps more difficult to be found, this is only partially true and only on a technical note. If we had a "view all" option where we could choose which images are displayed and also display all images in all sub-categories we could have "the best of both worlds", 1915 maps of Belize would also be in a wider category tree of 1915 maps by country, it may make maps of British Honduras more difficult to find in one way, but it's more easier to find in another way.
I always have a preference of using historical names for historical entities, the Federal Republic of Germany has only existed since 1949 and the countries that existed before German unification under Prussia were all separate sovereign states. Redirects are an easy solution because people will realistically use the modern names in historical contexts and they will show up in search results. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:36, 9 July 2020 (UTC)
@Donald Trung: A slight digression, but I wanted to mention that the reason Upload Wizard doesn't handle redirects properly is because of the fact that Commons doesn't actually use redirects for categories, it uses {{Category redirect}}, which sabotages all redirect-related features in Mediawiki. I wonder if it would be worth proposing that Commons switch to using real redirects for categories or if that would just be a waste of time. Kaldari (talk) 16:54, 16 July 2020 (UTC)
Regarding the issue of "contemporary names" vs. "modern names", in the case of Belize, there is no clear distinction. In the 1700s the territory didn't even have a name (although there are plenty of maps of it from then). It was just called "British territory". In the early 1800s it was sometimes called "Belize" and sometimes called "British territory". In 1862 it officially became "British Honduras", although it was still commonly called "Belize". In 1973, its name was changed to "Belize" although it was still a British territory, and in 1981 it became an independent country under the name "Belize". Throughout almost its entire history, it was commonly referred to as "Belize", so I think the least confusing option is to just use that name for the entire span. Kaldari (talk) 23:05, 17 July 2020 (UTC)

Create namespace alias TEM: for Template: on Commons

As endless discussions in https://phabricator.wikimedia.org/T237177 (Create namespace alias MOD: for Module: on Commons) finalized in "This would be providing an alternate way to refer to some namespaces. That's all. No one will be forced to change anything they are currently doing. Some people (those who know about the option) will simply be able to do things in a new way. No big deal, it seems really a small change with the result of being a great simplification at daily work – just like "cat:" is now:

  • mod: for Module:
  • tem: for Template:

To clarify an often mentioned misunderstanding: Even when tem is also a language code, it can never interfere when "tem:" is typed into the search field. There would also be no problem with "t:", which is always called to be "too short". In VPP were discussions at 2019/06, 2019/10 and 2019/11 about that, and it seemed that we got an accepting conclusion, but nothing happened since. So I am renewing that old request, hoping that it would not cause new endless discussions -- sarang사랑 06:17, 9 July 2020 (UTC)

@4nn1l2: As I said, an input into the search field like c: or m: or t: cannot disturb anybody, because as soon as the colon is typed it will be clear what is meant — and it had never been a problem to overtype the system's replenishments when they are not wanted. -- sarang사랑 16:47, 23 July 2020 (UTC)
And that's what I said :) I still support T:. Please note that uppercase and lowercase are the same thing at the beginning of a string. 4nn1l2 (talk) 16:58, 23 July 2020 (UTC)
As everybody can verify, neither t: or te: or tem:, nor m: or mo: or mod:, nor c: or ca: but cat: will (like com:) cause a replenishment. And the best, when in some future such input codes will be needed for something else, e.g. language codes, after cancelling the input abbreviation function they can be reused, such namespace aliases must not serve for ever! But they can ease the nowadays life for a while. -- sarang사랑 17:29, 23 July 2020 (UTC)
Multichill, be happy that it's not a problem to you! But it would be if you type every day some hundred times the 9 characters "template:" – then you would also wish it a little bit shorter. I do not know what you are doing, but it seems not to be your every day work with categories, modules and templates. May be you got your abbreviations for your frequent needs, but these are in turn "non-existent problem" to me. -- sarang사랑 13:16, 20 August 2020 (UTC)
Gone Postal, there is an exotic language code "te", but neither "t" nor "tem". As often said, we would prefer "t:" (like "c:" that we didn't get), but "tem:" would be fine, and will somehow fit to "cat:". -- sarang사랑 13:16, 20 August 2020 (UTC)
 Support In that case. ℺ Gone Postal ( ) 13:59, 20 August 2020 (UTC)
 Comment Namespaces and template names should pose no ambiguity. And of course there is the language template {{Te}} (would be tem:te), for Telegu (b.t.w., Sarang, you might want to reconsider your word choice — in a global context nothing is exotic). There is no language template {{Tem}} (would be tem:tem), but en:Tem language is spoken by a quarter million people, so there could be one day. -- Tuválkin 12:23, 28 September 2020 (UTC)
err Hi Nemo, you misunderstood completely - sure you read it wrong: we are talking just about an input abbreviation that nobody will see; it has nothing to do with a link abbreviation!
We have since long link abbrevs, whether you like them or not; if you want to fight against them you might do, but elsewhere.
Your erroneous opposing concerns something else, another theme than this proposal! -- sarang사랑 11:14, 3 September 2020 (UTC)
Of course it would be nice to have not only cat:, tem: and mod: but also (or better: instead ! ) c:, t: and m: – but don't let us be presumptuous, we will be happy to type 5 chars less -- sarang사랑 12:11, 4 September 2020 (UTC)
  •  Oppose I agree with Multichill here. I do no like obfuscation in our codes, as it makes them hard to maintain. As a result do not like single letter templates, like
err {{A}}, {{C}}, {{D}}, {{E}}, {{F}}, {{G}}, {{I}}, {{L}}, {{M}}, {{N}}, {{O}}, {{P}}, {{Q}}, {{R}}, {{S}}, {{T}}, {{U}}, {{W}}, {{V}}, {{X}}
(how many people know what each one does?) or many alternative ways to refer to a page. Multiple rarely used namespace aliases contribute to code obfuscation. --Jarekt (talk) 13:06, 4 September 2020 (UTC)
  • Hi Jarek, it is obvious that you also misunderstood completely what we are discussing and proposing!
At this place, nobody wants to abbreviate the template namespace or any template name of written links – that is another thing, that we can discuss at another place in peace.
  • At this place, we are just talking to shorten the manual input typing into the search field - nothing else! Especially you are frequently working with templates and modules, so you have to type very often the 8-letter-namespace Template:, Category: or Module:, when you do not use another convenience. Nobody will be forced to type less as wanted, and you may type {{Oppose}} when you dislike {{O}}, but some people would like to be swifter.
  • There will also be nothing to maintain, because nobody else can meet such an abbreviation; when I type cat: into the search field, it will not be written anywhere, it is just that I save to type the letters "egory" at this very moment. It will not be future impact to anybodys disadvantage, it is solely personal and momentary.
  • BTW, your reference of Multichill fails: he thinks that it will be a not required nonsense, and with respect to his opinion I am thinking otherwise. Currently his contribution is the only opposing one, because yours and Nemo's are basing on a misunderstanding. -- sarang사랑 14:04, 4 September 2020 (UTC)
    • I don't think it was a misunderstanding, at least not completely. It sounds like what they meant by 'obfuscation' and 'jargon-talking' applies to names like CAT:Copyright violations not just CAT:CV. Will the proposal affect the search box only? Will TEM:Information remain a red link unless someone creates a redirect specifically? If yes, then it will be unlike "cat:", and it will have to be implemented differently from what we usually call namespace aliases. --whym (talk) 02:00, 5 September 2020 (UTC)
It is just thought as an abbreviation possibility exclusively within the search box; it is another thing to write templates which support abbreviations, of namespaces and other items, their usage can be seen in the source of a contribution, some users like it and others dislike it. It is also another thing to use net-jargon in talking as "VPP" for "Commons:Village pump/Proposals" or "DR" for "Commons:Delete request", such more or less understandable shortcuts exist in numerous examples in the related talks between the experts.
I did not know that since 2006 the category redirect exists for 'Copyright violations', and I did not know that :CAT:CV belongs to the established Commons:Shortcuts, because it is not within my interests, but people checking copyrights may use it. The activities of me and many others focus on categories, templates and modules, therefore we would be glad when the search box will accept shorter terms.
Your question, Whym: I did not know that [[:CAT: ...]] is working – I do not need nor use it. I would use (for category, template, module and other namespaces) less-complicated templates with many parametrizable and/or defaulted options; but here we are talking about the search box as a manual input field, nothing else. -- sarang사랑 06:57, 5 September 2020 (UTC)
That would lead us to a next question - how will that be implemented precisely? Normal namespace alias would enable shorthand links, which you don't want. Is there any other option that doesn't enable shorthand links? whym (talk) 14:21, 11 September 2020 (UTC)
Sorry, I am not a specialist for that - I do not know about the implementation! When the namespace alias would enable also shorthand links, because that abuse cannot switched off, it will be IMHO not too bad, it is just one possibility more (of many) to express the link to a template. When the implementation is not widely published, it will be unknown to most users and not be used very often. That is not a solution if you see a problem in the abuse of an alias for a link, but the 'problem' will be not too overwhelming. -- sarang사랑 10:18, 13 September 2020 (UTC)

Add support for uploading AVIF

w:en:AVIF is an open, royalty-free image standard that will soon have support from and use by Chrome, Firefox, GIMP, Netflix, etc. It has even smaller file sizes than WebP. —Justin (koavf)TCM 07:56, 10 July 2020 (UTC)