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

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

Allowing index to gallery subpages in main namespace

I have uploaded many pictures from an old album about China with pictures taken by the Japanese. They were displayed in gallery pages for each volume in亜細亜大観/01, 亜細亜大観/02, 亜細亜大観/03... I have also created an index to the pages 亜細亜大観 to link to the sub pages and was deleted because it's a "Gallery page without at least two images or other media files". Then how should I share the album? I think index to gallery subpages should be allowed. An analogy is Wikisource. The main namespace host original text, but index to subpages are allowed. E.g., en:s:Illustrations_of_China_and_Its_People.--Upload for Freedom (talk) 02:12, 10 May 2022 (UTC)

What is the subject matter for this gallery? Is it just pictures about China taken by Japanese people? The galleries have no categories so are they just free-standing galleries? -- Ricky81682 (talk) 02:39, 10 May 2022 (UTC)

亜細亜大観 is a monthly photo book published by Dalian-based Asai Photo Daikansha from 1926 to 1940. A monochrome print is attached to the mount of the photo book, and a short commentary is attached to each photo. It seems that 10 sheets were distributed to members once a month as one set. A Japanese photographer photographed customs, folk affairs, natural scenery, historical buildings, etc. in China, the Korean Peninsula, Mongolia, Tibet, etc., and is a valuable document that conveys the situation at that time.

— [1]

--Upload for Freedom (talk) 03:13, 10 May 2022 (UTC)

Pinging @Jameslwoodward as deleting Admin.   — Jeff G. ツ please ping or talk to me 10:13, 10 May 2022 (UTC)
How about using Category:亜細亜大観 instead of a gallery page to collect the single sub-galleries? They really should be in that Category anyway. Category:亜細亜大観 第01冊 and others should probably also be created, as they are being used but don't exist. That's of course unless there are usable English category names possible, compare Commons:Categories#Category_names. --El Grafo (talk) 11:37, 10 May 2022 (UTC)
On the other hand, the similar 亜東印画輯 for example seems to make a lot of sense to me as an index to the linked subpages. El Grafo (talk) 12:00, 10 May 2022 (UTC)

Policy is very clear -- a gallery is a collection of images or other media files. There is no provision at Com:Galleries for using them for any other purpose. In fact, quite the opposite,

"Galleries without media are not galleries at all. They are considered out of the project scope and meet the criteria for speedy deletion."

An appropriate Category can easily serve the function of an index. .     Jim . . . (Jameslwoodward) (talk to me) 15:36, 10 May 2022 (UTC)

I think the policy should be updated to allow this usage. Categories cannot convey enough information about the gallery subpages.--Upload for Freedom (talk) 23:38, 10 May 2022 (UTC)
@Upload for Freedom: Categories can convey enough information about the gallery subpages.   — Jeff G. ツ please ping or talk to me 23:57, 10 May 2022 (UTC)
How about the date and number of issues? They cannot be seen from category. --Upload for Freedom (talk) 23:59, 10 May 2022 (UTC)
I think it's safe to say that this can do things that a Category can't. I think it's also safe to say that this is an improvement that turns it into an actual gallery. Just do them all like this -> problem solved. El Grafo (talk) 07:05, 11 May 2022 (UTC)
 Oppose per Jameslwoodward above.   — Jeff G. ツ please ping or talk to me 23:57, 10 May 2022 (UTC)

Enable $wgCopyUploadAllowOnWikiDomainConfig on commons

In order to add a domain into upload_by_url whitelist, someone need to fill a task on Phabricator and submit a patch, which is considered really complicated for new user and even experienced user. But now, we have a new configuration variable called $wgCopyUploadAllowOnWikiDomainConfig, which was introduced recently - if enabled, we could simply add domain into MediaWiki:Copyupload-allowed-domains, and there's no need waiting for deployment of a patch. Sounds pretty great, isn't it? So, I am here to request enabling such function on commons. Please share your opinion, thanks. Stang★ 07:25, 13 May 2022 (UTC)

I think this would definitely be useful but then we should implement a procedure for urls to be added like the bot requests. --GPSLeo (talk) 07:39, 13 May 2022 (UTC)
Could be similar to the procedure on MediaWiki_talk:Spam-blacklist and MediaWiki_talk:Spam-whitelist, just use {{Ep}} to notify admins. Stang★ 15:43, 13 May 2022 (UTC)
If I'm reading this correctly, would this make importing free and public domain files from websites easier? And would this also work with the MediaWiki Upload Wizard as it currently does for Flickr (for some people)? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:36, 13 May 2022 (UTC)
No the UploadWizard currently does not support uploading by URL. As there is the function for Flickr I think it would be possible to add this quite easy. --GPSLeo (talk) 16:00, 13 May 2022 (UTC)
 Support.   — Jeff G. ツ please ping or talk to me 10:43, 13 May 2022 (UTC)
 Support. Agathoclea (talk) 12:52, 13 May 2022 (UTC)
 Support. Obviously anything that makes things easier for the people that improve the technical quality of this website should be supported. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:54, 13 May 2022 (UTC)
 Support: This is something that should be in the hands of the local community. I don't think it needs any policy to be in place. Copy uploads are essentially a convenience, so I'd be quite happy with the default policy of leaving it to admin discretion, just like it's currently at sysadmin discretion. When this is done, the existing list of allowed domains should be moved to MediaWiki:Copyupload-allowed-domains so that they can be maintained here as well. --bjh21 (talk) 09:45, 14 May 2022 (UTC)
 Support obviously. --Marsupium (talk) 17:24, 14 May 2022 (UTC)
 Support --Guerillero Parlez Moi 21:45, 14 May 2022 (UTC)
Created an example list based on contents inside InitialiseSettings.php. I replaced *.*.example.com with .*\.example.com, // with #. Stang★ 22:53, 14 May 2022 (UTC)
@Stang: Are you sure that's correct? The patch referenced from phab:T300407, [2] doesn't seem to make any changes to the parsing rules for the entries, so I'd expect them to be the same as in the current setting, where . matches literally, and * matches precisely one component. --bjh21 (talk) 23:29, 14 May 2022 (UTC)
@Bjh21: I just followed the syntax in Spam-(black|white)list, but yeah, I would ask in the Phabricator task to verify if it is correct. Stang★ 23:33, 14 May 2022 (UTC)
I tested on my instance and you're correct - I have fixed the syntax of "MediaWiki:Copyupload-allowed-domains". Stang★ 00:10, 15 May 2022 (UTC)
 Support obviously. Yahya (talk) 21:53, 15 May 2022 (UTC)
 Support. Hulged (talk) 04:02, 16 May 2022 (UTC)
 Support --El Grafo (talk) 09:12, 17 May 2022 (UTC)
 Support maybe additionally to my comments above I should add a vote. --GPSLeo (talk) 19:30, 20 May 2022 (UTC)
 Support -FASTILY 00:46, 21 May 2022 (UTC)

Deployed and updated relevant page. Stang★ 20:20, 23 May 2022 (UTC)

@Stang: Thanks!   — Jeff G. ツ please ping or talk to me 21:02, 23 May 2022 (UTC)

Allow more than four files to be uploaded from a Flickr gallery at a time

I often upload photographs from Flickr but a huge issue is that flickr2commons does not support uploading Galleries, only albums. This means that I have to insert the gallery link into the Commons Flickr Upload Wizard (which thankfully works) in order to mass upload flickr galleries. However, while using the Flickr Upload Wizard you can only select up to 4 images to upload at a time. This is annoying and I don't see a reason why this has been put in place. Lallint⟫⟫⟫Talk 18:38, 20 May 2022 (UTC)

Rename Category:People in Fishnet tights

Could Category:People in Fishnet tights and its subcategories be renamed to have the word 'fishnet' with a lower case f? Ove Raul (talk) 21:55, 20 May 2022 (UTC)

The correct place to discuss this is COM:CFD, see COM:RAC. -- CptViraj (talk) 07:27, 27 May 2022 (UTC)

Adding alt texts through structured data

There is consensus among Commons editors to request that Wikimedia developers allow for pictures here to have default alt text. Some opposers objected to specifically using structured data; the technical approach best suited for implementing the feature is beyond the scope of the community and left to Wikimedia developers to decide. Other opposers objected on the basis that alt text is context-dependent, or linked or alluded to other discussions on Phabricator or Wikidata in which some participants made this point. However, other participants in those discussions attempted to refute that objection (arguing that there are situations like categories where pictures are presented without context, or that defaults can be overriden and something is better than nothing), and in any case, off-wiki discussions cannot be used to determine consensus here. With nine of the 12 participants here supporting and a trend toward support, the opposition was unsuccessful in persuading others to object. - Sdkb (Talk) 23:09, 19 August 2022 (UTC)

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

The alt texts are a feature for accessibility, they are a text for people who can not see the photo itself. In the Wikipedias it is possible to add the alt text when adding a file to the article. On Commons we do not have a standardized way to add an alt text to a file. This proposal proposes to add an additional field similar to the captions field where alt texts in multiple languages can be added. How this is used in the Wikis has to be decided by the Wikis.

In short: "The Commons community asks the SDC development team to add a structured data text field (like the caption field) for multilingual alt texts."

Discussion (alt texts)

Prior discussion

Resources on alt text

The following remark is, perhaps, redundant to prior discussion, but is repeated here because I think it addresses (at least in part) the objection by User:Glrx below: Alt texts are language-specific, so each property-value should always have a language as a qualifier, using language of work or name (P407). This is already how Wikidata property used as "depicts" (P180) qualifier on Commons (Q70564278) works. - Jmabel ! talk 22:57, 26 May 2022 (UTC)

I think it would make sense clarify a bit that:
  1. This would be a general-purpose default/fallback alt text. Obviously, we cannot store alt text hand-tailored for use in specific contexts.
  2. This proposal is only about making it possible to enter and store this on Commons (that involves developers working on StructuredData)
  3. Making the stored alt texts usable at the local projects is another matter (that would probably involve developers working on other parts of Mediawiki). But it seems obvious that established alt text syntax should override the default/fallback stored at Commons: [[File:foo.jpg|thumb|description|alt=specific alt text]]
--El Grafo (talk) 08:34, 2 June 2022 (UTC)
@Jmabel: I would have thought that a language-tagged text datatype (like MonolingualTextValue used by title (P1476)) would be more appropriate than a mandatory qualifier. Is there a good reason not to use one? bjh21 (talk) 21:09, 11 June 2022 (UTC)
@Bjh21: Just trying to parallel how we use Wikidata property used as "depicts" (P180) qualifier on Commons (Q70564278), which seems to me to be the most similar existing property. - Jmabel ! talk 23:12, 11 June 2022 (UTC)
Also: the idea with title (P1476) is that you may want to use (for example) the title in its original language even in the context when you are otherwise working in a different language. That consideration doesn't apply to alt text. - Jmabel ! talk 23:16, 11 June 2022 (UTC)
Previous proposals on Wikidata for a monolingual text property: Feburary 2017 (not done), November 2017 (not done), February 2021 (still unresolved). There is also a ticket in Phabricator. - Nikki (talk) 15:15, 30 June 2022 (UTC)

Votes (alt texts)

 Support.   — Jeff G. ツ please ping or talk to me 22:20, 26 May 2022 (UTC)
 Support - Jmabel ! talk 22:45, 26 May 2022 (UTC)
 Support I am slightly confused by the relationship between Commons and Wikidata. As far as I can tell, Commons runs a separate instance of wikibase, the software? In that case, the decision is somewhat easier because the alt text is a core attribute for image files. On Wikidata itself, I can sort-of see how it deviates from orthodoxy. It would be most similar to the descriptions, in that it is multi-lingual free-form text entered by users (as opposed to copied from a reference). There are properties that are free text and multi-lingual ("first sentence" for books etc) and many involve some subjective reasoning by users, but rarely both. Still, I would support it even on Wikidata and believe if it is required to make it work for commons it would be looked at somewhat more favorable than before. Karl Oblique (talk) 10:53, 27 May 2022 (UTC)
I think you got it right: the alt text would of course not be stored at wikidata, but here on Commons in the StructuredData that is attached to every file. El Grafo (talk) 07:51, 2 June 2022 (UTC)
 Oppose - Alt text is language dependent, so to hold alt texts here on commons (or on wikidata) would require alt texts for all languages. In addition, if done propoprly, alt texts should be context specific, depending on how the image is used. Alt texts should be produced locally, not imposed.Nigel Ish (talk) 14:19, 28 May 2022 (UTC)
That you think we should not have generalized alt texts for cases where no individual alt text was set is okay, but that the feature should allow alt texts in all languages (like at the captions) in clearly written in the proposal. --GPSLeo (talk) 16:31, 28 May 2022 (UTC)
So how is this different that the thirteen different language captions I currently see available for a media file? Peaceray (talk) 04:35, 2 June 2022 (UTC)
It would be similar, but content-wise alt texts need to be written in a different way - especially when it comes to things like graphs and diagrams. A caption would normally just give you the general subject and context of an image, the rest you can see for yourself. But since an alt text is for people whom for one reason or another, cannot see the image, it needs to describe the content in much more detail - to the point that it would be considered ridiculously redundant to someone who can see it. El Grafo (talk) 08:14, 2 June 2022 (UTC)
My understanding is that that like many infoboxes derived from Wikidata, the alt text parameter would be override-able. In practice, we already do this today with the default caption currently generated by the "Use this file on a wiki" function. Peaceray (talk) 04:43, 2 June 2022 (UTC)
Yes, the proposal is really not very clear about this, even though we discussed that at the Village Pump recently. It would need to be treated as a general default/fallback alt text that is only shown if no more specific alt text is specified when a file is being used. So when using [[File:foo.jpg|thumb|description]] the default alt text stored at commons would be shown in the user's language, but when using [[File:foo.jpg|thumb|description|alt=specific alt text]], the specific alt text hand tailored for the specific context would override that. El Grafo (talk) 08:03, 2 June 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2022/05&oldid=683700049"