Commons:Village pump/Proposals

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

Shortcuts: 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; the latest archive is Commons:Village pump/Proposals/Archive/2022/06.

COMMONS DISCUSSION PAGES (index)
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 5 days and sections whose most recent comment is older than 30 days.

Suggestions at File license template[edit]

The template {{File license}} still suggests to use {{self|GFDL|cc-by-sa-all}} or {{PD-self}}. As GFDL as single license is not allowed anymore and there are good reasons for using the current 4.0 CC licenses only I think we should change this suggestion to {{Cc-by-sa-4.0}}. As CC0 has many benefits over PD-self we should change this suggestion too. --GPSLeo (talk) 16:57, 13 April 2022 (UTC)[reply]

Agree with suggesting CC0 instead of PD-self. But multilicensing with GFDL and CC-BY-SA is more flexible than just CC-BY-SA. The suggestion is to license with all versions too, not just 4.0, making the suggestion more flexible still. I don't see any good reason to change that. Carl Lindberg (talk) 17:37, 13 April 2022 (UTC)[reply]
How do the -SA licences work with versions and derived works? Can you combine a -SA 2.0 with a 4.0? Does this make all of it 4.0? If so, specifying 4.0 will not hinder that combination, but does hinder licencing the derived work as 2.0. This might be a reason to do so, if we regard 2.0 as flawed. Of course, it helps with reuseability, especially in the case where a reuser has settled on a specific version (e.g. to minimise needed lawyer time). –LPfi (talk) 11:51, 24 April 2022 (UTC)[reply]
Other than 1.0, you can license to the later -SA version. So if you have a 2.0 and a 4.0 work, you can make a derivative of both only under 4.0. But if the 4.0 is multi licensed to all versions, then you can choose 2, 3, or 4, depending on what you want. Even if we think there is no good reason to do so, maybe someone else thinks differently, or maybe a future version will have some consequences some users don't want. Or, maybe there is a site out there which uses e.g. 3.0 for all their stuff; that makes 4.0 works difficult to incorporate. It's all theoretical of course, and not usually a problem, but unless there is something specific we don't like about older licenses, it really can only help. Flickr still uses 2.0 for example; if you want to make a derivative work and post it on Flickr you really can't unless the underlying work also allows 2.0. As for GFDL, it is not compatible with CC-BY-SA so you can't combine those works, unless one of them you can argue fair use or de minimis etc. I think the 3.0 versions are one-way compatible with GPLv3 (you can put CC-BY-SA-4.0 works into GPLv3 projects, but not vice versa). Carl Lindberg (talk) 14:50, 16 May 2022 (UTC)[reply]
I agree with Carl: we should suggest CC0, but there's nothing obviously wrong with the current multi-licensing suggestion. While there are ways of combining works with multiple copyleft licences, they're hard to understand and implement. Multi-licensing avoids those problems. --bjh21 (talk) 12:14, 16 May 2022 (UTC)[reply]
Regardless of what we suggest in this specific template, I see absolutely no reason to stray from the default (e.g. in UploadWizard), which is CC-BY-SA-4.0 only. So that's a valid argument for changing the default itself, but it just doesn't make sense to suggest something different in one specific template, which ends up confusing things. -- King of ♥ 08:13, 2 June 2022 (UTC)[reply]

Discussion result[edit]

In the {{File license}} template the link to {{PD-self}} should be replaced with {{self|cc-zero}}. --GPSLeo (talk) 14:20, 23 May 2022 (UTC)[reply]

Votes[edit]

Adding alt texts through structured data[edit]

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)[edit]

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)[reply]

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)[reply]
@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)[reply]
@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)[reply]
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)[reply]

Votes (alt texts)[edit]

  • Symbol support vote.svg Support --GPSLeo (talk) 18:36, 26 May 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose For the reasons given multiple times when a property for this purpose has been discussed on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 26 May 2022 (UTC)[reply]
    Would you please link to some of these discussions on Wikidata? Peaceray (talk) 23:38, 26 May 2022 (UTC)[reply]
    Discussions (from 2017) are here and here. Karl Oblique (talk) 10:40, 27 May 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose. The proposal is compound and confused. I support accessibility and the addition of alt text. I oppose locking in a specific approach such as Wikidata or structured data. Wikidata labels and descriptions have translations, but Wikidata does not translate the property data. The properties should be language-independent. The properties should also be structured; alt text would be both opaque and atomic rather than structured. Glrx (talk) 19:14, 26 May 2022 (UTC)[reply]
    The alternative for using the tools Wikibase provides would be to create a total new feature in MediaWiki or a new extension. I do not see why the needs for alt texts should be different to them for the captions. --GPSLeo (talk) 06:37, 27 May 2022 (UTC)[reply]
Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 22:20, 26 May 2022 (UTC)[reply]
Symbol support vote.svg Support - Jmabel ! talk 22:45, 26 May 2022 (UTC)[reply]
Symbol support vote.svg 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)[reply]
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)[reply]
Symbol oppose vote.svg 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • Symbol support vote.svg Support As the 2017 discussion on Wikidata was summed up, It might be relevant to propose it again once structured data is available on Commons. Stuctured data is here, let's put it to good use with this. Peaceray (talk) 04:47, 2 June 2022 (UTC)[reply]
  • Symbol support vote.svg Support offering(!) general alt texts on Commons as a default/fallback. Using StructuredData for this would make a lot of sense. If and how that would be deployed to the local projects is another matter that probably should be discussed elsewhere. --El Grafo (talk) 08:44, 2 June 2022 (UTC)[reply]

File usage on openstreetmap.org, The following page uses this file[edit]

In addition to the listing "File usage on Commons" a listing "File usage on openstreetmap.org" would be very useful from my point of view. Especially to be able to take this into account for deletions.

Symbol support vote.svg Support to enable listing of all InstantCommons uses.   — Jeff G. please ping or talk to me 05:59, 11 June 2022 (UTC)[reply]
  • I do not think that this is technically possible. The only way to do something like this would be a bot going through the OSM database and adding a template to the file page. --GPSLeo (talk) 06:43, 11 June 2022 (UTC)[reply]
    Thanks for your feedbacks. Yes, I had already thought of a bot that searches for "wikimedia_commons" in the OSM database. Then perhaps the link of the parent note (example here: https://www.openstreetmap.org/node/3094456337#map=18/52.35720/12.69014) could be determined and the necessary link to the file (here: File:Beobachtungsturm Strengsee, Seitensicht.jpg) is also available. It would only be necessary to find someone who would have time to implement this . . . — Preceding unsigned comment added by Molgreen (talk • contribs) 09:00, 11 June 2022‎ (UTC)[reply]
    I think having such a bot edit the file page would be disruptive: people get annoyed enough at watchlist notifications for changes to structured data; notifications for changes to the usage of a file would be even worse. But a bot could maintain a user gallery or several that contained files used in OSM, and those would appear in the list of local uses.
    However, I would then wonder why this should be limited to OSM. Other sites can use Commons images, either through InstantCommons as Jeff mentions, or by just recording URLs in a database (e.g. MusicBrainz). Do we in principle want to know about all external uses? Or maybe just ones in free-content projects? --bjh21 (talk) 10:16, 11 June 2022 (UTC)[reply]
    I agree a bot scanning file links to deleted or rename files would be useful but this is nothing to discuss here this is a topic for the OSM forums. It is also a question if direct linking of the files is needed. Most objects in OSM where a photo makes sense do have a Wikidata item where the photo is linked. --GPSLeo (talk) 10:49, 11 June 2022 (UTC)[reply]
    From my point of view, it would be interesting to record all uses. But that should be very controversial (I suspect)? OSM is a special project for me. I would even call it a partner project. I am meanwhile in both worlds (Wikiversum and OSM) on the way and think that with OSM similarly high quality standards apply as in the Wikiversum. --Molgreen (talk) 10:58, 11 June 2022 (UTC)[reply]
    @GPSLeo: To be clear, I did not suggest a bot scanning file links to deleted or rename files. As you say, such a bot and the question of whether the wikimedia_commons key should exist at all, are both matters for the OSM community. My suggestion was of a way to implement what Molgreen proposed without spamming people's watchlist. --bjh21 (talk) 11:02, 11 June 2022 (UTC)[reply]
Pictogram voting comment.svg Comment To give an idea of scale, OSM taginfo says there are 67,390 distinct values of the wikimedia_commons key on OSM at present. --bjh21 (talk) 10:22, 11 June 2022 (UTC)[reply]
Hello bjh21, this is very interesting. Thank you for the link! (There is still much possible . . .) --Molgreen (talk) 11:02, 11 June 2022 (UTC)[reply]
(I mean the use "wikimedia_commmons" is apparently only at the beginning. Hopefully still very much develops). --Molgreen (talk) 11:24, 11 June 2022 (UTC)[reply]
Pictogram voting comment.svg Further comment I've written a trivial script to convert data from Overpass into a gallery and created User:Bjh21/files used on OSM containing files referenced by OSM in and around London. This means that if you visit File:Halfway II Heaven, Trafalgar Square, WC2 (3614629275).jpg, for instance, that gallery appears in the list of uses of the file. I think I could fairly easily run a bot to maintain a collection of such galleries for the whole world if there were a consensus in favour of that. --bjh21 (talk) 11:37, 11 June 2022 (UTC)[reply]
@Bjh21: That is a very elegant solution and I can see it being very useful, both for us and for our OSM colleagues. Woudd there be some way to display the results on a map, also? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:45, 11 June 2022 (UTC)[reply]
@Pigsonthewing: I could probably arrange to add maps, but that's a lot more complicated and not really within scope. If you want you can get the same set of objects on an interactive map by typing wikimedia_commons~"^File:" into the overpass turbo Query Wizard. --bjh21 (talk) 20:01, 11 June 2022 (UTC)[reply]
@Bjh21: Thank you very much! A great solution from my point of view as well. The key thing here is that the usage is automatically displayed on the file page. This works great. One question: what are the chances that the solution will be implemented permanently and for all these files? --Molgreen (talk) 17:45, 11 June 2022 (UTC)[reply]
@Molgreen: From a technical point of view I don't think there's anything stopping me implementing this. I've tested it without the geographical restriction and the Overpass query runs in a couple of minutes, generating a 4 MB wiki page with 42,000 pictures on it. I'd probably want to carve it up into smaller subpages, but doing that and wrapping it up into a bot that runs daily or weekly would be easy. The only likely obstacles are organisational. I'd like to allow for some more opinions here so I can be confident we've got some kind of consensus. Then I'll go through the procedure for getting permission to run a bot. --bjh21 (talk) 20:55, 11 June 2022 (UTC)[reply]
@Bjh21: It would be very nice if that would work. Either way, thanks again for your effort up to here. --Molgreen (talk) 15:45, 12 June 2022 (UTC)[reply]

I have requested permission to run a bot to do this: Commons:Bots/Requests/Usage Bot. --bjh21 (talk) 15:31, 19 June 2022 (UTC)[reply]

New Wiki Product[edit]

Hello,

I write today as I have an idea for a new Wiki service. Called "Wiki Archives" its main purpose would be preserving artifacts like Documents and Photos that others might not seen in saving. Wikimedia Commons is a great service, but I believe that some of what's in it should be split into this new product. When you search for something, you can find pictures in like old building plans and old photos which should be in an archive where they could be appreciated more. It would work like commons as people could upload things, but it would be stricter in what it lets in (e.g. New phots taken by users and other things). If you have any questions, feel free to contact me. Thanks! DiscoA340 (talk) 16:50, 21 June 2022 (UTC)[reply]

@DiscoA340: When would be the cutoff? Which would rule in cases of filename conflicts? Is it really a good idea to split Admin attention at this time?   — Jeff G. please ping or talk to me 21:19, 21 June 2022 (UTC)[reply]
For the cutoff, I would say 20 years is a good rule of thumb, but as long as it's what you expect in an archive, then it should be good. I don't think there will be an issue with filename conflicts as most documents should be different from each other. For multi-page docs, I would think people would name each "Document X (P1)" and maybe for bigger docs, they could be combined into a single filename but with multiple pages (Sorry for being vague, I don't know how to explain it other than making bigger docs into a slideshow type file." The issue about Admins is a bigger issue I don't think I could answer and be 100% accurate, though I would say that making an archive could attract more future admins who like the idea and want to help. DiscoA340 (talk) 22:31, 21 June 2022 (UTC)[reply]
Commons is already our document and image repository and archive, full stop. There's no benefit to splitting the collection. In fact, there are very real downsides.
Take Jeff's question about file name conflicts that you didn't answer. If Commons has a document called File:Example.pdf, and someone uploads a different document called File:Example.pdf to this archive, which document gets served to Wikisource for transcription? If Commons has a photo called File:Example.jpg and this archive gets a different photo uploaded as File:Example.jpg, which photo appears in a Wikipedia article? If this new archive restricts uploads so that file names don't conflict with Commons, then what is the point in separating it out? Essentially that would just be a subsidiary of the larger repository split under a different domain name.
That then bridges into Jeff's second unanswered question. With a limited corps of trusted volunteers, is it a good idea to create another project that needs admin supervision? Instead of admins monitoring one domain name looking for files tagged as copyright violations, they'd need to monitor two domains. Or you'd have to recruit a second set of admins for the new site. You'd have to duplicate the various core policies to another domain. You could get weird inconsistencies where a file that doesn't technically conform to one site's policies technically conforms to the other.
So that brings me back to my first statement here: Commons already is the archive. Imzadi 1979  18:54, 26 June 2022 (UTC)[reply]

Global coordinates; latitude, longitude.[edit]

Hi,
I contributed this picture which is used in the Oberon book. The global coordinates are obviously wrong, as easily seen in Open Street Maps. Also the page for the picture has the message "There is a discrepancy of X meters between the above coordinates and the ones stored at SDC (Y). Please reconcile them." There are two problems with the location template.
(1) I haven't found documentation specifying the order of latitude and longitude in the template. Does documentation exist? If not, it should be created. In any case, a search of Help should find it.
(2) Apparently the location template accepts decimal degrees. Nevertheless coordinates are displayed as dms (degrees minutes seconds). What is achieved other than confusion? Our world is digital. Conversion is a nuisance. Display decimal degrees! In brief, my proposal is "Make location work".
Thanks for your attention, ... PeterEasthope (talk) 22:39, 26 June 2022 (UTC)[reply]

@PeterEasthope: That file description page is using {{Location}}. The documentation is at {{Location/doc}}. Parameter 1 is Latitude, degrees North of the Equator. Parameter 2 is Longitude, degrees East of the Prime Meridian (Greenwich Observatory). Where I live, Latitude is positive and Longitude is negative, putting me in the Northern and Western Hemispheres, and I'm fine with that. The numbers in that photo's file description page when I first got to it ("49.2637|123.2461") indicate a location in Hulunbuir, Inner Mongolia, China. I have a feeling "49.2637|-123.2461" in University of British Columbia Hospital, Greater Vancouver, British Columbia, Canada is more appropriate given where you live in British Columbia.   — Jeff G. please ping or talk to me 23:25, 26 June 2022 (UTC)[reply]
Fixed the sign of longitude in the location template, thanks. The SDC reconciliation page suggests fixing the structured data. OK but I don't know where it is and the page doesn't give a clue. =8~/ The map shows the correct location for the coordinates. If SDC doesn't agree, sorry, I'm baffled. Regards, ... PeterEasthope (talk) 00:29, 27 June 2022 (UTC)[reply]
@PeterEasthope: On the "Structured data" tab, did you try to tap the "Edit" link next to "coordinates of the point of view" and save your changes?   — Jeff G. please ping or talk to me 00:43, 27 June 2022 (UTC)[reply]