Commons:Village pump/Proposals/Archive/2022/03

Should we have a form for contacting the VRS, similar to the "email this user" form?

I drafted a suggestion, at User:Geo Swan/An OTRS form.

I think the commons, the wikipedias, and other WMF projects, would benefit from a form, similar to the Email this user button, for contacting the VRS.

I've cropped headshots of over 1000 VIPs over the last decade. Less than 1 percent of them have triggered a request for courtesy deletion. I always requested they contact OTRS/VRS. In those discussion those individuals sometimes expressed confusion over how to make that contact. Since, for the last couple of decades even little children, and their great grandparents, know how to send an email, those requests seemed odd. Generally no one else spelled out how to send the email either.

But, I now think the anxiety they voice was not due to an unwillingness or inability to send the initial email. I think their anxiety was due to their not understanding what came next.

Hence my suggestion, of a form, accompanied by some brief exposition, of the process, and the next steps.

Maybe I should have put this on the VRS noticeboard. I'll leave a note there.

Cheers! Geo Swan (talk) 19:50, 2 March 2022 (UTC)

I'd sugest continue in just one place, for not to spread the conversation. I think is not necessary; there are few cases to do that. I've could agree to put a link in the left side bar to Commons:Consent, i.e. However, I do agree with the fact that the process is no clear. I've been trying to get changes in the template, to make explicit the fact that the copyrights belongs to the photographer, not the subject, even if the photographer is not professional. This is a true problem. Years and years I've been rejecting permissions at first time for this reason. And people come back with: "but I'm in the photo", "He use my own camera", I've paid for it", or worst: "the photographer was a stranger". I think this is a more serious and frequent problem without solution yet. --Ganímedes (talk) 12:07, 4 March 2022 (UTC)

Proposal to edit interface pages

I am proposing to create MediaWiki:Group-checkuser and MediaWiki:Group-checkuser-member with "CheckUsers" and "checkuser" as their content, respectively. I had originally posted this about this at Commons talk:CheckUsers. All the other wikis such as metawiki, enwiki and simplewiki etc have done this already. The former will change the title of the group in Special:ListUsers and Special:ListGroupRights from Check users to CheckUsers and the later will change the title in log summaries from check user to checkuser. Regards, Startus (talk) 05:05, 7 March 2022 (UTC)

Proposal for technically simple mouse-over category browsing tool which could make for huge usability improvement

As to my background, I am a long term contributor (since 2005, 750 Uploads, 6.700 edits), with both self-made photographs and image improvements and derivative works on other's pics mainly with GIMP and the crop tool. I also do a lot of article work in the German Wikipedia and also internationally, among that a lot of work by targeted searches for pics in Commons and adding them to existing, 'under-imaged' articles. A problem I frequently have results from the fact that I often work in new fields, mainly technically orientated, where I do not have the slightest idea on the bandwidth of available pics (and products/items/goods depicted), a good example may be home computers of the 80s, of which there are hundreds in a lot of categories. In these cases, I have to browse at least dozens of categories to find one pic I have some idea of, often opening one category after the other and then mainly (naturally and logically...) realizing that the pics are to 97 % far from what I look for specifically. Of course, this is ineffective and time-consuming, and I assume that many users share similar experiences. My proposal could reduce the time required for such searches drastically and also greatly (yes) improve the general user experience on Commons, I assume. There are surely many to ways to realize the concept. Here are some basic points/facts:

1) When the user lets the mouse rest on a category link, after ca. 0.5-1 sec. a mouse-over pop-up window (or similar) appears with a preview of the pics in that sub category, details thereon see below
2) In order to have the at least (averaged) 10 to 50 pics in that category be effectively shown to the user, there seem to be two main options: A) Only one pic at a time is shown as a large thumbnail (say 300 x 300 pix), and there are control buttons below the pic for a kind of quick overview over all the pics in that category after another - e.g., like a video time slider (cf. Youtube, at lower edge of video screen) which the user can move which results in a (speed-controlled) pic-by-pic browsing through the category pics, hence like a user controlled slide show (just an example, options are vast of course). The pics are thereby displayed like looking at a video in fast forward, but with absolute control by the user. B) The mouse-over window is relatively large (e.g., one third of the screen or similar), and there is a thumnail preview for each pic (maybe up to 15 pics and a scroll bar or button) C) A good add-on might be that when the user has found an interesting pic, there is a "screen size" button to view the pic in a larger version

I think this would greatly speed up the searching/browsing process, would spare users a lot of time and make the user experience with Commons much better. The above are just "thought quick shots" and I do not at all say that the above is the real McCoy. Maybe, there are way better options/designs to realize this, but I think the aim is clear. Maybe, this could even result in a reduction of bandwidth consumption due to caching. Any comments? Pittigrilli (talk) 10:36, 6 March 2022 (UTC)

PS after two days: I am aware that this would be a relatively huge change in the user interface. Hence, one way to start might be to first offer it as an add-on such as the really good "MyUploads Gallery Tool". Pittigrilli (talk) 12:38, 8 March 2022 (UTC)

@Pittigrilli This sounds like something similar to mw:Page Previews but for category links. Perhaps you could develop such a gadget if you write JavaScript. If not, I would encourage you to submit a feature request, although I also warn that there are more proposed ideas than technical contributors who implement them, and there is no guarantee that someone pick it up soon. One or two mockups or even hand-drawn images of the proposed interface would help. whym (talk) 14:23, 13 March 2022 (UTC)

@whym What is JavaScript? (Just kidding). Thanks a lot for this helpful answer including warning me of the expected time lag. I already thought of making some mock-ups. Actually, having some significant programming background long ago, you thankfully inspired me to seriously consider learning JavaScript for this, let's see. Regards, Pittigrilli (talk) 14:58, 13 March 2022 (UTC)

Add noindex to speedy deletion templates

Wikipedia includes a noindex template on all of its speedy deletion templates, to stop spam, personal attacks and other such content from being spidered by search engines in the time between nomination and deletion.

Commons does not do this, even though the same problems can arise when a search engine spider picks up an image which shouldn't be here. Commons has the additional problem that if a copyrighted image is falsely claimed to be public domain or CC-Attribution, a site like Google Images will trust Commons to be reporting that accurately, and serve it up to its user as freely licenced content. If Google says it's public domain, the user may even right-click and copy it without clicking through to the Commons page at all.

So I propose doing the same here at Commons - specifically, adding the {{NOINDEX}} template to {{Speedydelete}}. --Lord Belbury (talk) 12:33, 13 March 2022 (UTC)

Seems reasonable, although if the image has been here for a while, having Google index/cache the deletion notice might actually be helpful, since it would have almost certainly already been indexed/cached without it. Or would Google then know to remove it from their images results? For tags added shortly after upload, this would certainly be good. I assume the same would be done to {{Copyvio}} and probably {{SD}}, if we do. Carl Lindberg (talk) 15:58, 13 March 2022 (UTC)

This all sounds very reasonable, my only issue is what to do with the misuse of speedy deletion templates? Some users use speedy deletion templates in lieu of deletion requests and sometimes erroneously tag free files due to misunderstandings, if these files are already in use at a Wikipedia can the tagging of such a file for one (1) or a few days lead to the file not being machine searchable for months? One interesting thing I noticed is how rarely the Wikimedia Commons seems to pop up in search engines even if I use an exact word search, usually I get in-use files from Wikipedia linking to the localised Wikipedia page of a Wikimedia Commons file. But then again making Copyright violating uploads as "invisible as possible" would be good to avoid having this website be associated with bad uploads, but then again if an outsider sees that such copyright violations get quickly deleted they might be discouraged from uploading these themselves and having them be indexed helps with this. In general I'd say that I'm neutral about this as it has some benefits and some drawbacks and I'm neither convinced that the current situation is or isn't problematic. For example, a company wonders why "a good image" of their office gets speedy deleted and they could have offered OTRS / VRTS permission, though I think that in practice this is extremely rare. My biggest issue with it remains the idea of some users spamming speedy deletion templates where Deletion Request templates should be used. Of course the best benefit being that false tagged free files don't get mistaken for actual free files, though at that point the damage has likely been done as I think that people are unlikely to use files with giant red boxes thinking they are free. Already addressed. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:54, 14 March 2022 (UTC)

Commons:Language policy and Commons:Talk page guidelines

as i read this discussion special:permalink/642101852#Request_for_Deletion_in_languages_other_than_English-_is_there_a_policy_or_process?, i feel that it's necessary to emphasise that no language is discriminated against, and users may use any language on commons, so i propose to add a sentence to the relevant policy and guideline pages: Users may express themselves in any language of their choices. RZuo (talk) 12:29, 20 March 2022 (UTC)

@RZuo: "choice" is better than "choices".   — Jeff G. ツ _{please ping or talk to me} 00:36, 21 March 2022 (UTC)

AWB tags and edit summary

I had made a few edits using AWB, and noticed it uses an edit summary to say it is AWB. Instead of it, it could be used as a Tag like Cat-A-Lot and VFC. Could it be done. Curlyrnd (talk) 13:27, 25 March 2022 (UTC)

multilingual Commons

@Bastique: Non-English homepages for Wikimedia Commons need to be moved to either subpages of "Main Page" or to language-specific namespaces. E.g. the Spanish-language homepage for Wikimedia Commons should be either "Main Page/es" or "es:Main Page" (which can then redirect to "es:Portada"). Language-specific namespaces are not currently set up on Wikimedia Commons, and "es:Main Page" redirects to the Spanish Wikipedia instead of to the Spanish-language homepage for Wikimedia Commons. All MediaWiki installations (regardless of the language used) recognize the English-language page of "Main Page" as the default (since the MediaWiki software is written in English, and then translated into other languages). For a multilingual wiki though, there must be a way to distinguish between multiple-language uses for the same Main Page. The non-English homepages for Wikimedia Commons as set up now are confusing and difficult to find. For example, "Portada" has the same meaning in Asturian, Catalan, Galician, Portuguese, and Spanish. Likewise, "Página principal" has the same meaning in both Portuguese and Spanish. Nicole Sharp (talk) 02:30, 28 March 2022 (UTC)

Do you expect me to remember a decision I made 14 years ago when Wikimedia Commons was just getting started? I'm sure there were good and valid reasons, or else it would have been challenged long before now. I suggest you procure the involvement of active community members in a Request for Comment if you want to change the decision to something else. Bastique ^{☎ appelez-moi!} 02:35, 28 March 2022 (UTC)

• I did not notice that the deletion date was from 2006. I am guessing that multilingual Commons has different needs now than it did then, so hopefully recreating the page is now uncontroversial. Nicole Sharp (talk) 03:07, 28 March 2022 (UTC)

I would need an Admin to create new namespaces and also to set the new namespaces as part of mainspace (non-mainspace namespaces are ignored from search by default). However, if recreating the language-code subpages of "Main Page" for each language is uncontroversial, I can go ahead and either move the current non-English homepages to be subpages of "Main Page", or to create redirects from the mainpage subpages to the current non-English homepages. The alternatives are to rename the pages, for example as "Portada (español)" instead of "Portada" or to use pseudonamespaces, e.g. the page "spa:Main Page" can be created, even if the "spa" namespace does not exist (the "es" pseudonamespace is currently being used for interwiki to Spanish Wikipedia). Page titles using pseudonamespaces are a very bad practice though and should be avoided. Nicole Sharp (talk) 03:05, 28 March 2022 (UTC)

Yet another option is to create the pseudonamespace within the commons namespace, e.g. "commons:es". The Catalan-language homepage for Wikimedia Commons redirects from "commons:Pàgina principal" to "Pàgina principal" but would be better situated as "commons:ca" or "commons:ca:Pàgina principal" instead for multilingual access. Nicole Sharp (talk) 04:07, 28 March 2022 (UTC)

• I think that redirecting "Portada" to "Main Page/es" (and "Página principal" to "Main Page/pt", etc.) would be the simplest and best solution without invoking potentially thousands of new namespaces for each language that needs a homepage on Wikimedia Commons. Nicole Sharp (talk) 03:05, 28 March 2022 (UTC)
  • The page "Portada" is currently protected, and can only be edited by administrators. So an admin will have to make the necessary changes if moving the non-English homepages to be subpages of "Main Page." Nicole Sharp (talk) 03:11, 28 March 2022 (UTC)

Example: Disambiguation of "Portada"

"Portada" (the current Spanish-language homepage) has the same meaning in Asturian (ast), Catalan (ca), Galician (gl), Portuguese (pt), and Spanish (es). Of these languages, only Galician specifies within the page title as to what language the homepage is in (as "Portada galega"). For multilingual access, there should also be a "Main Page/mul" (or equivalent). Nicole Sharp (talk) 04:07, 28 March 2022 (UTC)

move "Portada" to "Main Page/es"

This has the major disadvantage that non-English pages have English page titles, which can make finding non-English content more difficult. Nicole Sharp (talk) 10:39, 28 March 2022 (UTC)

support, this seems to be the simplest solution, and allows translation of any other page on Wikimedia Commons by using a language-code subpage. However, exclusively using subpages restricts non-English page creation to only pages that already exist in English, which may not always be practical. Non-English pages without English equivalents could still be created in mainspace without being subpages but might require disambiguation. Nicole Sharp (talk) 04:43, 28 March 2022 (UTC)

I don't understand how using "Main Page/es" is less English centred than using "Portada" with possible disambiguation tweaks. Just creating redirects from [title in English]/xx to the translated (or otherwise corresponding) pages makes it easy to find the correct page if you know the one in English, and at the same time lets non-English speakers avoid using English (except for namespace prefixes, which are a problem, but probably one that needs a major change in the software to be solved). –LPfi (talk) 08:58, 28 March 2022 (UTC)

• I agree that Anglocentrism is a serious problem (and no better than Hispanocentrism), but "Main Page" is translingual in the same sense that HTML tags are, since the software is originally programmed in English. "Main Page" is the only page title with a special translingual status, since it is created by the software installation, and not by a user. Without invoking new namespaces, the best alternative for a consistent codified approach to all languages is a pseudonamespace within the commons namespace, i.e. "commons:es:Portada". This has the advantage of allowing any page name within the Spanish pseudonamespace, being able to quickly find and identify pages for a specific language, and interwiki compatibility, so that other wikis can use language codes to create language-specific interwikilinks to Commons. However, it has the serious problem of being located outside of mainspace. Instead of creating a new namespace for each language, another alternative is to create a single new namespace, for example "lang:es:Portada" for which the lang namespace can be indexed properly, and then contain pseudonamespaces for all languages. Nicole Sharp (talk) 10:20, 28 March 2022 (UTC)
• The other alternative is to address the problem one language at a time, which seems to be the current approach. Most languages will not have conflicts for what they call their language's homepage. The correction for Hispanocentrism is then just "Portada española" versus "Portada galega". Nicole Sharp (talk) 10:20, 28 March 2022 (UTC)

I don't see the relevance of Main Page being used in the software. Usually the names used in the software don't dictate names used in the user interface. Also "error", "user" etc. are used in the program code, which doesn't hinder using translated names for the concepts (other than for namespace prefixes, where collisions would be a real problem). But let's see more opinions. –LPfi (talk) 12:14, 28 March 2022 (UTC)

move "Portada" to "l:es"

It is likely impractical to create a new namespace for every language. Instead, a single new namespace can be created (such as "lang" or just "l", from the HTML lang attribute), and all non-English pages can then be organized by language-code pseudonamespaces within the lang (or l) namespace. This allows interwikilinks by language code, similar to the different languages for Wikipedia or Wiktionary. Nicole Sharp (talk) 10:39, 28 March 2022 (UTC)

 Support, I didn't think of a translingual namespace before, but that would be a good solution. It avoids the problems of either creating a new namespace for each language, or putting non-English content outside of mainspace by using the commons namespace. The lang or l namespace can be assigned in LocalSettings.php to be indexed as part of mainspace. English-language pages can also redirect from (for example) "lang:en:Main Page" or "l:en:Main Page". Nicole Sharp (talk) 10:56, 28 March 2022 (UTC)

• Problem: Non-English Commons policy pages however would need to use (for example) "l:es:commons:" if re-using the commons namespace as a sub-pseudonamespace within the l:es: Spanish-language pseudonamespace. This will still create problems for indexing though in that l:es:commons would be indexed as mainspace, unless commons:es: is used instead specifically for non-English Commons-namespace pages. Using subpages of the English-language page title automatically separates the mainspace pages from the Commons-namespace pages for non-English content, otherwise two separate pseudonamespaces will be needed (e.g. "l:es:" and "commons:es:"). Nicole Sharp (talk) 11:23, 28 March 2022 (UTC)
• A single-letter translingual namespace would likely be even more practical, such as "l:es:Portada" and "l:gl:Portada". Nicole Sharp (talk) 10:56, 28 March 2022 (UTC)

move "Portada" to "commons:es"

This has the major disadvantage of putting non-English pages outside of mainspace, which will be problematic for indexing. Nicole Sharp (talk) 10:39, 28 March 2022 (UTC)

move "Portada" to "Portada (es)"

An easy fix might be to simply add the language code in parentheses to all non-English pages on Wikimedia Commons. This avoids any possibilities of ambiguous titles and allows for quick language identification and indexing. However, page titles with parentheses containing Latin letters for translingual language codes may not work well when combined with right-to-left scripts. Nicole Sharp (talk) 11:31, 28 March 2022 (UTC)

move "Portada" to "Portada española"

Simply creating a new mainspace page with the page title being "Main Page" translated into the new language is a workable solution (and the one currently used by Wikimedia Commons), except for similar languages which share the same word or phrase to refer to the Main Page (such as Spanish and Galician). Only those small handful of languages then need to have their Main Pages to be disambiguated. However, without language codes in the page titles, each non-English page on Commons needs to instead use wikicategories to identify as belonging to a specific language, otherwise the linguistic content is not identifiable to users unfamiliar with the language. Nicole Sharp (talk) 10:47, 28 March 2022 (UTC)