Commons:Village pump

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

Shortcut: COM:VP

Community portal
Help desk
Village pump
Administrators' noticeboard
vandalismuser problemsblocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

Please note

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons' core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page

Search archives


A village pump in Burkina Faso [add]
Centralized discussion
See also: Village pump/Proposals • Archive  • M:D

Template: View • Discuss • Edit • Watch


Share my Content here with CC-BY-SA and on Youtube with standard Youtube license[edit]

moved to:Village pump/Copyright#Share my Content here with CC-BY-SA and on Youtube with standard Youtube license

To be archived by ArchiveBot Poké95 10:15, 25 April 2016 (UTC)

Copyright for books or printed official publications?[edit]

To be archived by ArchiveBot Poké95 10:15, 25 April 2016 (UTC)

What license?[edit]

To be archived by ArchiveBot Poké95 10:15, 25 April 2016 (UTC)[edit]

To be archived by ArchiveBot Poké95 10:15, 25 April 2016 (UTC)

Great Britain & Ireland postcards[edit]

moved to Commons:Village pump/Copyright#Great Britain & Ireland postcards

To be archived by ArchiveBot Poké95 10:15, 25 April 2016 (UTC)

April 18[edit]

Tech News: 2016-16[edit]

20:40, 18 April 2016 (UTC)
El_Grafo@Deep_Thought ~ $ telnet
Connected to
Escape character is '^]'.
                         ,'"/      ,^.___.--./`.
                       ,' ;"     ,-`     '-.  m `.
                      /v\./      \,.  __  (   _  ,^.
                     / .  `;      .J (  )__\,- `~' '.
                    /_ ' /"      _|___)     )    g  \
                   ;_':_|___  ,-' \        (_,.   _ |.
                   |    |  (__) ,-'   W  __    \,' L'|
                   |  ,-'    _  \_,.    (  |_,-"\_   |
                   |  `"}  _( )_    \   _|   .   _)  |
                   |^\__|____  __,--+--'   |/|  (   /|
                   '.   |   (__)    \_,-.  '     \,'\;
                    \ n `.-.  , /,    _,'  ,")_,-\  /
                     \_. ;-'  * #    (   __)   ,-' /
                      `\-+,.._   _,---\-'   q  "},'
                        `.'\  (__)  ,-->   _,..,'
                          `.L .  ~  '-[:>.' _,"
                   _ _ _   _  _ _  __   ___  __     __ 
                   | | | | |_/  | |__) |___ |  \ | |__|
                   |_|_| | | \_ | |    |___ |__/ | |  |
                          The Free Encyclopedia
Version 1.27                    16 Apr 2016                  131,217 Users
                            MotD last updated: 02:45 PM April 16, 2016

Welcome to Wikipedia!  We are the world's largest community driven dial-in
hypertext encyclopedia with over 5.1 million articles in English.

Wow, this actually kind of works! Seems like good (?) old Telnet might get a bit if a revival through Tor? --El Grafo (talk) 21:56, 18 April 2016 (UTC)

It was meant as an April fools joke originally. Generally speaking I don't think telnet is likely to get a revival for anything serious (but there are still places where you can play games over telnet - telnet:// comes to mind), although I hear using ssh over tor hidden services is beginning to become popular for people who want to access hosts with dynamic IPs. Bawolff (talk) 19:13, 19 April 2016 (UTC)
Symbol support vote.svg Support gopher. ;-) –Be..anyone 💩 00:01, 20 April 2016 (UTC)
Well, useful or not, it's nice to see stuff like this still exists. There are stills some MUDs around too, tried MorgenGrauen myself for a few hours not too long ago. The Usenet seems to be dying a slow and painful death (with the possible exception of alt.binaries.*) – kind of sad to see this, even though I never really used it. --El Grafo (talk) 09:17, 20 April 2016 (UTC)
Thumbs-up-icon.svg Great! -- Poké95 00:36, 25 April 2016 (UTC)
Look familiar... I've got IEG for building it, see m:Grants:IEG/Telnet. Dispenser (talk) 19:49, 29 April 2016 (UTC)

April 19[edit]

Should CommonsDelinker remove redlinks from DRs?[edit]

Is behavior like Special:Diff/164712655/192642388, Special:Diff/193266615/prev, Special:Diff/192642388/prev, Special:History/Commons:Deletion_requests/Files_in_Category:AIDS_Poster_from_Wellcome_Images_(check_needed) and most recently Special:Diff/193784503/193941566 new for CommonsDelinker? I would think it obvious that it is extremely undesirable, but am I totally off-base here? Is there ever a reason for CommonsDelinker to edit DRs at all? Not sure who to inform other than Magnus... ideas? Storkk (talk) 11:22, 20 April 2016 (UTC)

Currently fixed for DR and REFUND. Storkk (talk) 12:40, 20 April 2016 (UTC)
  • If we talk about CommonsDelinker, I want to add, (for the 3 time), that it will be good that CommonsDelinker don't edit the logs too (e.g. the Featured picture candidates logs) as the result is some bugs with the transclusions that include file names. Christian Ferrer (talk) 12:59, 20 April 2016 (UTC)
    • Is there any good reason for it to remove links from the Commons namespace at all? Wouldn't redlinks for, e.g. Village pump archives, be more desirable for the entire namespace? Storkk (talk) 12:56, 21 April 2016 (UTC)
The redlinks remains red until there is not a new file with the same name....Christian Ferrer (talk) 17:16, 22 April 2016 (UTC)
  • I agree for not to remove links from the Commons namespace. Christian Ferrer (talk) 22:04, 24 April 2016 (UTC)
  • I Symbol keep vote.svg Agree. -- Poké95 09:38, 29 April 2016 (UTC)

Bird and nets[edit]

Hello, after adding some pictures I see there is some confusion in the categories about birds and nets: Category:Bird netting regroups hunting methods, ornithologists techniques (both are very similar) and anti-birds systems. WP makes the distinction: en:Bird netting and en:Mist net. Any suggestion? Category:Mist neeting vs Category:Anti-bird netting? Triton (talk) 21:00, 22 April 2016 (UTC)

Ignore enwiki while you are on commons. –Be..anyone 💩 21:05, 22 April 2016 (UTC)
It seems like a reasonable distinction to make, and there's nothing wrong with using the names already picked by enwiki if they are good enough. --ghouston (talk) 00:29, 23 April 2016 (UTC)
In fact Category:Bird nets exists as well. Triton (talk) 11:44, 26 April 2016 (UTC)

April 23[edit]

Categories by name[edit]

I have been looking at categories with names like "<something> by name". I've noticed that these are used in (at least) two different ways.

I am suggesting that we come up with different naming conventions for the two types of "by name" categories so that users can know what to expect in each. Normally we expect a "by <something>" category to be a meta category, but in my view only categories in the first group are really meta categories. It would be good to name at least the others in a different way.

I'm not sure what the best names would be. Possibilities are:

  • First group: "Foos by shared name"
  • Second group: "Foos by individual name" (still looks misleadingly like a meta category), "Named foos", "Categories named after foos"

Comments? --Auntof6 (talk) 07:00, 23 April 2016 (UTC)

It is possible, of course, but will a massive renaming effort be worth of some minor clarification that will result? Ruslik (talk) 14:24, 23 April 2016 (UTC)
I don't see the issue here, they are both by name, one example has subcats for individual objects, the other groups more then one object together as appropriate to the subject covered, They are both Metacats as all the image files would be in subcats Oxyman (talk) 16:16, 23 April 2016 (UTC)
They are not both metacats. If every category that contained only subcats was a metacat, then we wouldn't need the distinction we get with the {{CatCat}} template. Each category in a metacat includes multiple things/people by some common characteristic. For example, Category:Cities by country has subcategories for cities of each country. Each category in the second group has files for only one thing/person. This issue only happens with "by name" (not, for example, with "by city") because the expression "by name" is used in English in a different sense. That gets carried over to our category names and makes categories look like metacats when they aren't. --Auntof6 (talk) 17:19, 23 April 2016 (UTC)
It would help keep non-metacategories out of Category:Meta categories, for one thing. To me, it doesn't seem that massive compared to how many categories there are here. There are a few places I'd start looking for these categories:
  • Category:Categories requiring permanent diffusion to zero: This category contains categories that use the {{CatCat}} template. There are currently 780 entries here, but only some of them are "by name". Most or all of the "by name" categories here would go into the second group.
  • Category:Categories by name (flat list): This category contains all the meta categories that specify the "name" parameter, along with others that map to "name". There are currently 567 categories here, but we'd only need to look at the ones that say "by name". This category currently contains a mix of first-group and second-group categories.
  • Category:Categories by name: Things are manually added to this category. There are currently only 68 entries here. It's likely that many of them are also in one of the other two categories.
There are probably other "by name" categories that aren't in any of those, because not everyone knows/remembers to set them up properly. We'd have to either find those some other way, or just take care of them when we happen across them. --Auntof6 (talk) 15:57, 23 April 2016 (UTC)
F.w.i.w., I think Auntof6 is completely right about this. -- Tuválkin 02:45, 26 April 2016 (UTC)

Problem with a video[edit]

Maybe some colleague with experience on creating + uploading videos could help. My problem is, that the OGV file I have recently uploaded on Commons, when viewed straight on Commons (by clicking on thumbnail), appears to have significantly lesser quality than this very same file when viewed via Windows Media Player on my computer. By doing the latter, the detail level seems higher and the colours more staurated. Again, it is the same file, and both times viewed in full screen mode, i.e. full resolution. What did I do wrong, and how to fix it? Thanks. --A.Savin 20:44, 23 April 2016 (UTC)

About this: I often have the problem, that WMP + movie maker arrive at something that is far too dark + too red. Apparently you have the opposite problem, windows okay, elsewhere washed out + too bright. If you're using FFmpeg I can post my current "make webm or ogg" script/options somewhere. Tweaking gamma/satuaration/... is excessively lossy, you can do it at most once, or restart from scratch. –Be..anyone 💩 04:01, 24 April 2016 (UTC)
@Be..anyone: Thanks for answering. Although I completely fail to get the last sentence, as far as I can understand the rest, the issue is not in my file or my upload, but in some script. So, the question is now, how to get it well viewable for a normal user, like myself. Yes, I use FF. To view a video from Commons, I usually click on the preview, or the play button there. --A.Savin 14:49, 24 April 2016 (UTC)
✓ Done I just clicked on the video again, and saw what I didn't notice before: there is some dropdown choice of compression rates (or so), and by selecting "webm 1080" you get nearly the same quality as on my PC. So this seems to be actually the issue. OK, there is still the question why the highest quality rate is not chosen by default; but that's somewhat not in my competence. Thanks again --A.Savin 14:57, 24 April 2016 (UTC)
The highest quality rate is not chosen by default because not all users have a fast internet connection. I actually use an internet broadband that is running at a maximum of 2 Mbps, and average is 300 to 400 Kbps, which is pretty slow. (Lucky that I can still access Commons with that kind of speed ;)) Poké95 09:42, 29 April 2016 (UTC)

April 24[edit]

Colour corrections by old slides scans[edit]

Scan feb 1985 Belgium007.jpg
Old slides mostly discoulour in a consistend way, see most can be easily corrected with a colour adjustement during the scan. I notice that in some cases the discolouration varies between the darker and ligther parts of the image. But in this case it is even more complicated as a simple removal of purple shows:
Scan feb 1985 Belgium008.jpg
The sky is more or less correct, but the foreground is to yellow.Smiley.toerist (talk) 10:36, 24 April 2016 (UTC)
Suggestion on File:Scan_feb_1985_Belgium007_(upd).jpg, please speedy delete. –Be..anyone 💩 11:51, 24 April 2016 (UTC)
Looks very good. Is the same correction used for the whole image? Is it a colour curve? (linked with another aspect of the image)Smiley.toerist (talk) 11:56, 24 April 2016 (UTC)
Yes, I noted it on the temporary page:
Method: Green to 0
Maybe you could use it also on the original. –Be..anyone 💩 13:10, 24 April 2016 (UTC)
By the scanner or photoshop: if I remove green I get back the Magenda (Purple) There is however still the dark green of the train. I may have to buy the tool. There is no reason not to keep several versions of the image. But as creator you have the rigth to refuse to keep the image in the Commons. One can keep only the best version in the categories, so it doesnt clutter up categories. The other versions can be linked bij other versions line. I include the original scan as an example of the type of colour distortions caused by the aging process of slides. Do we have a category for this?Smiley.toerist (talk) 10:00, 25 April 2016 (UTC)
I used the free plugin (LE), and didn't test anything else (after one attempt with easyfilter smartcurve, also free, but it didn't directly help.) –Be..anyone 💩 11:26, 25 April 2016 (UTC)
Smiley.toerist Is this more or less what you are looking for? - Takeaway (talk) 13:14, 28 April 2016 (UTC) ->
Train by Franchimont in the snow in 1985 II.jpg
Yes. Perfect! And this without the invisible trademark placed by SF ColorMixer in the Scan_feb_1985_Belgium007_(upd).jpg? (I suppose this is why Be..anyone wants his version speedy deleted). I wil rename this version to a meaningfull name: Train by Franchimont in the snow in 1985 II.jpg. Smiley.toerist (talk) 09:22, 28 April 2016 (UTC)
I mainly just lowered the saturation of green and purple, and added in a bit of clarity and some minor changes to light levels, all using Lightroom. Cheers! - Takeaway (talk) 13:14, 28 April 2016 (UTC)

April 25[edit]

Mobile edits and uploads[edit]

So I had a look at recent edits in the File namespace tagged as mobile edits. These are the results for yesterday:

Total: 15 disruptive, 5 neutral, 1 apparently constructive (<5%)

75% of the disruptive edits were undetected.

Total: 14 disruptive, 2 apparently constructive

Tell me again why we don't just shut this nonsense down with an abuse filter? And where's the Phabricator ticket for the fact that mobile uploads are not checked for the presence of source, authorship or licensing information? All I could find was phabricator:T70321, but that was closed two years ago. LX (talk, contribs) 10:38, 25 April 2016 (UTC)

I agree this does not look good, but than again I sometimes find it easier to upload a photograph directly from my iPhone than download it to computer and than upload. May be uploads and edits from mobile devices for users with proven track record. --Jarekt (talk) 20:50, 25 April 2016 (UTC)
+1 to LX. The question is: Do we need a few good phone uploads comparing the work we have deleting all the copyvios and selfies?--Kopiersperre (talk) 11:24, 26 April 2016 (UTC)
The net benefit is clearly negative (by a ratio of about 10:1 for uploads in this sample). An individual uploader burdening us with five illegal and two useless files for every decent one and whose edits consisted predominantly of vandalism would be swiftly blocked. LX (talk, contribs) 14:34, 26 April 2016 (UTC)
Uploads from mobile web browsers have been disabled in 2014 because of exactly this (official statement on mobile-l). If these uploads are coming in from mobile web browsers, there's something wrong. If, on the other hand, they are coming in through the Commons:Mobile app, User:Syced might be able to help … --El Grafo (talk) 13:26, 26 April 2016 (UTC)
They don't appear to be coming from Commons:Mobile app. AFAIK all uploads via the Commons:Mobile app will have the template "Uploaded with Mobile/Android" or "Uploaded with Mobile/iOS" as stated here, which I do not see in the photos linked (all of which appear to be uploaded via the mobile web browser, hence "Mobile web edit"). Re-tagging User:Syced for confirmation. Misaochan (talk) 09:02, 27 April 2016 (UTC)
The uploads and edits are all tagged as mobile edit ("Edit made from mobile [web or app]") and mobile web edit ("Edit made from mobile web site"), not mobile app edit ("Edits made from mobile apps"). In any case, it's not just a matter of uploads. Less than 5% of non-upload edits are constructive, and most of the vandalism goes undetected. We don't have the resources to deal with this many greasy-fingered mobile zombies. LX (talk, contribs) 14:34, 26 April 2016 (UTC)
I couldn't agree with you more on this LX. I usually revert a half dozen or so of these mobile edits each time I take a look at IP recent changes, and I can only remember seeing a few mobile edits that weren't vandalism. Worse than "Cross-wiki upload", but that's still around pumping out copyvios... INeverCry 02:32, 27 April 2016 (UTC)
Interesting research, thanks! I would like to point out that all of the edits and uploads above have been done via mobile browser. None have been performed via the Android app. On the opposite, here are the pictures uploaded via the Android app: as you can see, almost no selfies/copyvios (I counted only 9 useless files among 500 uploads). So the problem lies with the mobile website I guess. I am not involved in that website's development, but just a suggestion: To avoid copyvios, how about checking for EXIF data? Copyvios are usually pics found on the web, and most of them don't have any EXIF data. Cheers! Syced (talk) 09:31, 27 April 2016 (UTC)
There's also phab:T64598, and still a lot of past mobile/web uploads to be checked at Commons:Mobile access/Mobile upload needing check. Lupo 21:33, 27 April 2016 (UTC)
Hmm, I thought mobile uploads had been disabled a while back. Maybe Jdlrobson knows more about this. Ryan Kaldari (WMF) (talk) 02:38, 29 April 2016 (UTC)
Mobile uploads have been disabled since 2014. Edits have always been possible. I suppose you could disable the edit icon for everyone but that seems a bit extreme when 50%+ of all Wikimedia traffic is on mobile. Note edits via the desktop site on mobile phone may get tagged mobile edit. 2607:FB90:428:7D21:DCD9:5DDF:8F58:C2 04:02, 29 April 2016 (UTC)
Overall traffic is completely irrelevant. Mobile phones are great for looking stuff up and reading. They are not at all suited for any serious wiki editing work, as clearly demonstrated by our greasy-fingered friends in the list above. Allowing that mob to continue to create a ton of cleanup work for almost no benefit – that's what's extreme. And if mobile uploads have been disabled, and these are really from the desktop site, why do we end up with empty file descriptions? The desktop site doesn't allow that. We don't get that kind of upload from desktop site users without mobile web tags. I'm not buying that explanation. LX (talk, contribs) 17:10, 29 April 2016 (UTC)
I don't know what else to tell you. Mobile uploads have indeed been disabled since 2014. There is no code whatsoever relating to image uploading in the code for the mobile site (and when we did provide it it was quite obvious which files came from mobile as they had a random number in the title). I'm thus not quite sure what's being asked of here. How does one shut down uploading via AbuseFilter? There is no accurate way to tell if someone is using a mobile device.

Why the uploads are coming with empty file descriptions is not clear but remember anyone can upload via the API. I could make my own script right now that uploaded images tagged `mobile edit`. Is it possible there is a 3rd party app/script that might be doing this and incorrectly getting tagged `mobile edit`? One of your examples shows the image has been inserted into the infobox manually. How then it got uploaded I'm not sure. Only that user knows. Maybe via the link "No existe un archivo con este nombre, puedes subirlo a Commons" ? I'm not sure I can help here without understanding the route cause. Have you tried reaching out to these users via talk page to understand them a bit more? What's motivating them and how they are doing it? If you can replicate this workflow we can attempt to fix it / stop it but until then it's just guess work. Jdlrobson (talk) 17:51, 29 April 2016 (UTC)

Should this one have been deleted too?[edit]

I came across

The description says it is part of a larger image, which was removed ( )

Should the smaller image have been removed at the same time? I am not sure I fully understand the deletion page - was it deleted because some made a political rant instead of a proper copyright statement? --Robert EA Harvey (talk) 14:32, 25 April 2016 (UTC)

I would say that both images are slavish copies of an ancient 2D work and therefore are in public domain ({{pd-art}}). Ruslik (talk) 19:56, 25 April 2016 (UTC)

Tech News: 2016-17[edit]

21:02, 25 April 2016 (UTC)

April 26[edit]

What are the rules regarding euro coins?[edit]

I've read Commons:Currency#Euro section Euro coins, and this discussión Commons:Deletion requests/Template:Euro coin common face 2, but it is not clear. It seems they are not allowed but this category Category:Commemorative 2 euro coins is full of them. Who owns the copyright of the designs. I don't find anywhere that the designs are public domain but also I don't find any restriction in use. What is the appropriate license for them? If I scan a coin, it is really own work? Can I upload this ? Triplecaña (talk) 13:58, 26 April 2016 (UTC)

Folks disagree about the status of coins as 2D (scan, maybe okay) or 3D (sculpture, maybe not okay), cf. COM:EURO in COM:COIN, or in this talk archive. –Be..anyone 💩 14:41, 26 April 2016 (UTC)

April 27[edit]

UploadWizard should link to coordinates[edit]

When I upload a file by Special:UploadWizard the fields for the coordinates get pre-filled with the EXIF data. So far, so good. But sometimes I upload images, e.g. of a building, and I don't remember exactly the name of the town I took it, or the name of the building or some other information. I can easily copy the coordinates into Google Maps and look it up.

But that would be even easier if there was a link next to the coordinates linking to a map showing the exact location given by the coordinates. On the toolserver we have this tool that also shows the heading (using a rotated Commons logo). The would be neat. Unfortunately I don't know any way to create such a link with the tool (or any other tool) so that it would display just one coordinate given by URL parameters. (The link needs to update, when the user changes the coordinates in the input field.)

Does anybody disagree that this would be a nice feature? Cany somebody implement it? --Slomox (talk) 07:15, 27 April 2016 (UTC)

Sounds like a good idea to me. Can you create a task in Phabricator? @Matma Rex: does such feature require community consensus? --Zhuyifei1999 (talk) 08:13, 27 April 2016 (UTC)
I don't see why we'd need "community consensus" of the kind usually needed for configuration changes. This seems like a simple improvement, and not a change to existing tools. And besides, you folks are asking for it right now here, looks like consensus enough to me. ;) Matma Rex (talk) 13:42, 28 April 2016 (UTC)
Great idea! Syced (talk) 09:49, 27 April 2016 (UTC)
The coordinates of already uploaded files link to mw:GeoHack (e.g., [11]). So it would make sense to use this tool also in the UploadWizard… – Simon04 (talk) 13:16, 27 April 2016 (UTC)
GeoHack is great in Wikipedia articles and Commons file description pages to give the user the full range of available services, but my idea was about convenience, so I would prefer a one click solution to the two click solution. But we could always add two links, one for the convenient one click solution and the second to GeoHack for the full range of services. {{Location}} already does this and links to both GeoHack and WIWOSM. --Slomox (talk) 14:22, 27 April 2016 (UTC)
I created a Javascript that does what I want. See: User:Slomox/vector.js. It still lacks the "Commons logo indicating the heading" fun.
However due to the fact that UploadWizard is so dynamic and has few obvious classes (or names for its input fields) the code is rather slow.
It would be possible to edit MediaWiki:Mwe-upwiz-location to insert the link, which would speed up the script. But this needs to be done in each language separately. --Slomox (talk) 11:27, 28 April 2016 (UTC)
Neat, but please, nobody use this :) Watching the whole page with a MutationObserver is definitely going to be detrimental to performance, and then I'm going to have to field bug reports from unaware users saying that UploadWizard is horribly slow again.
I don't think editing MediaWiki:Mwe-upwiz-location would actually work (depends on what you had in mind), we display that message as plain text in UploadWizard (so you couldn't add any links etc.). Matma Rex (talk) 13:42, 28 April 2016 (UTC)

Sounds like a good idea to me (I work on UploadWizard). We probably wouldn't want to use GeoHack or other Labs tools (Labs can't handle as many users as the "production" Wikimedia sites; while UploadWizard probably doesn't get enough traffic to cause problems, it'd still be frowned upon), but we have a shiny new beta maps site at which should be up to the job. I filed phab:T133905 about this and I'll look into it. (Alternatively, if anyone wants to contribute, feel free to submit a patch :D) Matma Rex (talk) 13:42, 28 April 2016 (UTC)

Thank you for your answer and your "warning" about my code ^^ (I agree: nobody should use the code without being aware that its creator hates the solution)
I was not aware of When you say it should be up to the job: is there documentation how to do dynamic stuff like pointers with it? And (that question has nothing to do with UploadWizard, but I am interested in it) is it able to display the map in different languages? --Slomox (talk) 14:53, 28 April 2016 (UTC)

The new maps will (hopefully soon) make it to all of the wiki. Read up about them at kartographer help page. For the use cases like upload wizard, they should use maps directly. The is not a good target - its a test server mostly, to make sure the tile server is still working. Thanks! cc:@Slomox: --Yurik (talk)

Wikidata support: arbitrary access is here[edit]

Hey folks :)

As I announced a while ago we just enabled arbitrary access for you. This means you can now access all the data on Wikidata from any page on this wiki. Previously it was only possible to get data from Wikidata for the item that is directly connected to the page here. So for example Category:Berlin could only get data from the item on Wikidata about the category for Berlin.

Please do migrate gradually and maybe start with some smaller templates so we can see if there are any problems. If you encounter any problems or have questions please let me know.

I hope you'll build cool things with this and make your work here easier. This is another major step for Wikidata support for Wikimedia Commons. The next big step is actually enabling you to store the meta data for a file here like its license or creator in a structured and machine-readable way. This is still a lot of work for us and will take quite a bit more time. We're working on that and will show you very very early and ugly prototypes next month or so. --Lydia Pintscher (WMDE) (talk) 10:40, 27 April 2016 (UTC)

\o/ Jean-Fred (talk) 13:23, 27 April 2016 (UTC)
So typing "{{#property:P36|from=Q183}}" returns "Berlin". Blue Rasberry (talk) 14:49, 27 April 2016 (UTC)
Great news! BMacZero (talk) 20:25, 27 April 2016 (UTC)
A little more options with {{Data}} template: "{{Data|property=P36|item=Q183}}" returns "Berlin"--Jarekt (talk) 03:53, 28 April 2016 (UTC)
Wonderful ! I'm will look into what can be done for monuments templates like {{Mérimée}} and {{Palissy}}. Cdlt, VIGNERON (talk) 15:00, 28 April 2016 (UTC)
  • I updated {{City}} so it can take a Q code, so {{city|Q144786}} gives now "Zakopane", same for {{Creator}} and its Birtloc/Deathloc parameters and probably many other templates that use {{City}}. I also run into a problem with templates that use wikidata and suddenly trigger expansion depth limit error. See phabricator:T133918 for details. --Jarekt (talk) 18:13, 28 April 2016 (UTC)
  • {{Authority control}} should pull its data frmo Wikidata. Andy Mabbett (talk) 12:34, 29 April 2016 (UTC)

Re-users are still getting confused, and are improperly crediting our uploaders[edit]

I wrote about this problem, in January -- Our information pages misleads visitors. Some respondents there claimed I was describing a non-problem, and merely showing our re-users "don't know how to read". Some other respondents suggested upcoming changes in media-viewer might fix this problem.

Well, it is still a problem. I was recently given credit for this image by Marine insight a for-profit enterprise.

I think the contributors who say this is a non-problem, that only highlights that people "don't know how to read", have got it all wrong.

If a team who designed, built and maintained a bunch of superhighways had their attention drawn to the fact certain sections of the highway, that were close to especially tight turns, or hidden intersections, had a hugely disproportionate number of lethal traffic accidents, would we allow them to say: "we put up warning signs, that said 'dangerous curves' and 'intersection 300 metres'. If drivers continue to crash, in these sections, it is their own fault, because they clearly 'don't know how to read'".

The highway designer has to put in more warning signs, or bigger warning signs, or change the location of the warning signs. Alternately the highway designer has to go to the expense of altering the highway's route, to remove the dangerous curves and hidden intersection.

I curse that stupid mediawiki extension, every time it is presented to me. I tried to set up my preferences, so I never see it. But that doesn't always work. But I don't think it is the main problem here, as the miscrediting predates mediawiki. I think most of our re-users find the image they want in ways that don't take them through mediawiki, and it is our old usual image description pages which need to be changed.

Our image description pages -- what if, along the top, where they have other handy internal links, they had one additional link to "copyright holder", or reasonable equivalent?

What if the uploader's names were hidden, and you had to click on a button to see them?

Why can't we change how we render these pages to help prevent our well-meaning re-users from constantly making this mistake? Geo Swan (talk) 13:08, 27 April 2016 (UTC)

Geo Swan I confirm the problem. It is an outstanding issue.
"Why can't we change how we render these pages to help prevent our well-meaning re-users from constantly making this mistake?" You know the reason - conversation between Wikimedia Foundation developers and the community of readers and editors is paused on this issue. It is worthwhile to bring it up as "unresolved" and to make continued demands that the Wikimedia Foundation staff and development team acknowledge the problem.
An outcome that I think is tolerable is "problem acknowledged - there are currently no resources allocated to addressing this and we assert that alternatives are worse". I think this is where the situation is. If you feel instead that the situation is that the problem is not acknowledged, then feel free to press more.
This is a serious issue that worries me but I have hope that it will be addressed eventually. I appreciate your raising the issue and think that if you wish, you should feel free to discuss the issue as you like. Blue Rasberry (talk) 15:00, 27 April 2016 (UTC)
I actually don't know that developers, or those who have the authority to give them direction, have recognized and acknowledged this as a problem. I'd be happy to learn it is on a list of problems scheduled to being addressed. If you know of a list of this schedule I'd be very appreciative if you linked to it here.
Alternatives are worse? Who decided that? I suggested two simple alternatives above. If you are aware of where alternative have already been considered, and dismissed, perhaps you could link to that discussion? Cheers! Geo Swan (talk) 15:10, 27 April 2016 (UTC)
Side note: if you mean MediaViewer, it can be globally disabled (if you are logged in) by putting mw.config.set("wgMediaViewerOnClick", false); into meta:Special:MyPage/global.js. Though mediaviewer appears to credit the linked file correctly, so is probably not the source of that specific misattribution. Storkk (talk) 17:34, 27 April 2016 (UTC)

Commonist Vicuna Bash and Python[edit]

Simple question- is there anyone active maintaining Commonist or Vicuna? Is anyone with programming skills that is thinking of working on a fork? Has any one put together a repository of bash scripts or working python snippets that could be used to put together a efficient easy to teach tool.

My starting point is that of a trainer- I need a tool that is easy to explain to a room full of U3A types who would love to share folders full of their previous research work. Getting them into the room was hard enough, they are semi-comotose by time they have had notability, tables and referencing explained to them. We need something easy- that is within their outdated computer skills.

  • Pyrenamer is great for batch fixing filenames- but doesn't allow for uploads, describing, geotagging and simple cropping and straightening.
  • Shotwell viewer is great for simple cropping and straightening, but doesn't describing, geotagging, do batch, or uploads.
  • Commonist is a great batch upload tool- but won't do batch renames, geotagging is messy, and simple cropping and straightening could happen if it would just call Shotwell instead of the build inviewer.
  • Then there is Vicuna- that has workable widgets- does call Shotwell, but looks like nothing our clients have ever seen. The developer appears to have abandoned it around November. It is a great proof of concept- but is there any way we can help him get it right. There appears to be a need to design a skinnned front end that allows us to customise the user experience for our clients.

Are there any python libraries that are still supported- so we can write addons? Is anyone still working in bash? Have they made them user friendly!?

The simple question is there anyone active maintaining Commonist or Vicuna? The rest of the paragraphs above are merely there to send a message to any new and talented programmer that the community is full of ideas and would love someone to take the lead and put our ideas into practice. --ClemRutter (talk) 21:31, 27 April 2016 (UTC)

To answer your question about python: Pywikibot is active and maintained. Quite recently most of the upload logic was refactored and I tested it. Multichill (talk) 19:00, 28 April 2016 (UTC)

April 28[edit]

Dealing with accounts of dead users[edit]

As far as I know, we have no established procedure for dealing with accounts of users whose deaths have been confirmed. Following the recent death of User:Dravecky (not particularly active here, but an en:wp admin), I asked at COM:AN for advice on what we did following the confirmed death of a Commons user; the response made me guess that there was no procedure.

With this in mind, I'm making two proposals, which of course are mutually exclusive:

I have no preference for either of these over the other, but I'm confident that we should adopt one or the other. Of course, writing a new set of guidelines would take a while, so I'd also suggest that if we choose to write something new, we follow the en:wp page until our new guidelines are complete. Nyttend (talk) 01:33, 28 April 2016 (UTC)

We have Commons:Deceased contributors, and its talk page. It might be a bit more difficult to get an exact procedure put together here than at considering the many countries Commons users come from and the different languages spoken. A general guideline would be good though. INeverCry 01:44, 28 April 2016 (UTC)
I would add that I agree with what Riley Huntley says at AN; the blocks are unnecessary as are the userpage blanking and full talk protections. Only a few of the users with memorial entries at Commons:Deceased contributors are blocked. I'd love to see User:Dravecky unblocked along with the others. INeverCry 02:17, 28 April 2016 (UTC)
The opt out procedure is rather bizarre, fortunately the four contributors are alive and kicking (not listed on COM:MISS.) Thanks for the solution (see below) in this case. –Be..anyone 💩 02:31, 28 April 2016 (UTC)
  • I've added an entry to Commons:Deceased contributors for User:Dravecky. INeverCry 01:59, 28 April 2016 (UTC)
  • Thanks for starting this section Nyttend. I'd also like to add that the floating items like on User talk:Cotton are not friendly to mobile users. If these proposals are unopposed, I'd be glad to assist with making Commons:Deceased contributors/Guidelines or something of the like. Cheers! Riley Huntley (talk) 03:04, 28 April 2016 (UTC)
  • The standard procedure on it.wikipedia is user's blanking page and block. While I might agree with the user page left free to be edited, I see no reasons for not blocking it undefinitely. The username is bound to the person, who is the sole responsible for whatever is done with it. If we don't block the username of a deceased user anyone who knows their password can use it (and possibly also in ways that are not only against Commons policies but against law at all) without being responsible. I only ask you consider this point. -- SERGIO (aka the Blackcat) 10:25, 28 April 2016 (UTC)
on itwiki I'm quite sure we don't have a guideline but i think we block the user, probably we block the user's page (never checked, although minor corrections like removal of obsolete cats have to be performed by sysops I guess), the talk is available for comment, but I don't remember any blanking of the user pages. I am misinterpreting some word here? I am assuming "blanking" is when you delete the whole page and put something like a template on it?--Alexmar983 (talk) 11:58, 28 April 2016 (UTC)
  • I strongly agree with the user block policy. Account may be at risk for legal reasons. I would also clearly states if not blocked that at least users flag should be removed. Think the bad taste if someone send a mass message to sysops for a meta policy discussion or to autopatrolled users for some new tool available or something similar and some of the recipients are dead.--Alexmar983 (talk) 11:57, 28 April 2016 (UTC)
  • Symbol support vote.svg Support indefblocking accounts of deceased users for safety reasons, Symbol oppose vote oversat.svg Strong oppose protection of their talk pages as already stated; Symbol oppose vote.svg Oppose blanking user page and/or user talk page because I don't see any reason; but Symbol support vote.svg Support adding there a notice that the user has died, or a template for this case, like they do in Russian WP. --A.Savin 13:31, 28 April 2016 (UTC)
  • I agree with blocking the account, since literally nobody's supposed to be using it; a single edit is proof of compromise, so blocking makes sense. We can always unblock in the unlikely event that the death report is greatly exaggerated; the not-so-dead user will know how to post a diff or otherwise alert us while logged out, and sanctioning an IP for block-evasion in this case would be absurd. I agree that we shouldn't full-protect talk pages; while I can't point to it, I remember having to ask an admin to create a DR because the creator's talk page was fully protected, and the script wouldn't proceed when it couldn't edit the creator's talk page. Nyttend (talk) 19:01, 28 April 2016 (UTC)
  • If there were serious safety/legal concerns regarding these deceased accounts, wouldn't a global locking policy make more sense than a few scattered local blocks? INeverCry 19:34, 28 April 2016 (UTC)
  • As virtually nobody's particularly active on more than a few wikis (perhaps Meta, Commons, and a few Wikipedias or other single-language projects), a few blocks would cut off virtually everything at which a user was active. Is there a global policy against permitting multiple people to edit from an account? If there's no such global policy, mandating a global lock for a deceased user would be a bad idea, because it would potentially get rid of accounts that some wikis would permit, e.g. imagine that the Bahasa Indonesia Wikipedia would permit (either explicitly or by lack of prohibition) someone else to keep editing with my account after my death. Lacking a global policy, the global lock would potentially get in the way of local policy. Nyttend (talk) 19:53, 28 April 2016 (UTC)
  • If these accounts are a real risk, we've got 94 unblocked deceased accounts at Commons:Deceased contributors, many of which have been dead for years. I've never heard of an issue with any of them. The blocking rationale is a phantom. Why would a deceased account be any more risk than a retired account? We don't block those, and there are thousands of them. We even leave some user rights like autopatrolled on retired accounts. I Symbol oppose vote.svg Oppose blocking deceased accounts, as I don't see the any real point to it. INeverCry 21:09, 28 April 2016 (UTC)
  • If you retire, you're entirely able to un-retire, and there's no fundamental problem with your account making edits post-retirement. If you die, you're not able to un-retire, and a dead user's account that's still making edits is obviously compromised; once you die, your account cannot make further edits that are permitted by policy. Might as well just block the account, as long as it's done with a clear statement that it's purely because of the user's death, and done with settings that won't restrict account creation or impose autoblocks. Nyttend (talk) 22:13, 28 April 2016 (UTC)
  • I won't get into how long many of these retired accounts have been inactive, or how few editors return after 3+ years of retirement, or even how many known sockpuppets are left unblocked because they're "stale", but what seems strange to me is that we're talking about making a policy that would require admins here to block at least the 94 deceased accounts from Commons:Deceased contributors that I mention above, some of which belonged to editors who died more than 10 years ago. Blocking these accounts seems like a waste of time to me, or just busy work, but it's not a big deal one way or the other of course. My oppose to blocking them isn't terribly serious, though the blocking rationale "dead user" is a bit crass and insensitive if you ask me. I hope that doesn't become policy. INeverCry 05:53, 29 April 2016 (UTC)
  • I think, blocking deceased accounts should be allowed (e.g. for cases where there are safety concerns), but of course it doesn't have to be mandatory, especially not for accounts with just some dozens of edits. --A.Savin 07:30, 29 April 2016 (UTC)
INeverCry talking about blocking I was thinking in fact to do it at meta level... I am the one who would prefer a meta policy with some guidelines (at least a list of standard possibilities that local platforms may or may not adopt) and I support in a SUL system some more meta-oriented user-related policies when possible on "formal" aspect. Just for an example: rumor has it that the babel template is becoming centralized, probably a deceased user template is not too futuristic to imagine. I would prefer to have a meta discussion to "discuss" ("process"?) the death of a user because in the end the level of crosswikiness is increasing and user do not belong to a single platform community anymore. But we have non-linear process on wiki so I am used to think step by step... plus it is not a "nice" topic so... I am not going to open it on meta right now.--Alexmar983 (talk) 15:11, 29 April 2016 (UTC)
From the Terms of Use: "You are responsible for safeguarding your own password and should never disclose it to any third party." So, any use of deceased user accounts by anybody else would violate this clause. Ruslik (talk) 11:54, 29 April 2016 (UTC)
See the 4.9.6. quote near the top of this page for a good summary, although one that excludes "must"; in legal documents, such as the Terms of Use, "should" and "should not" are forceful recommendations, but if you disregard them, you're not in violation. "You should never disclose" is saying that it's a horrid idea, a piece of seasoned advice: very different from "you shall never disclose", a formal prohibition, the violation of which will cause you to be in breach of the terms of use. Nyttend (talk) 12:04, 29 April 2016 (UTC)

I would have commented sooner but couldn't but I was going to suggest something similar to what Alexmar983 did above. I know every community likes dealing with this sort of thing on their won but for something like this I really think a WMF Wikiwide Meta RFC would be the best way to go. I think the WMF, or at least the broader community should make a decision on how to deal with accounts of deceased editors globally. Obviously I don't think anyone wishes these folks ill nor is anyone wanting to gravedance, but I also don't think there is a lot of point to keeping the accounts unlocked with full privileges. The talk pages and userpages are there to assist that user and so others can discuss things with them. If they are deceased, then that is unlikely to happen. Reguyla (talk) 17:42, 29 April 2016 (UTC)

Autotranslate problems[edit]

I am having serious problems with Autotranslate, and I can't find the talk page for translator admins. I tried to make Template:Infobox flag much easier to translate, and thought I made it. But then the <translate>-tags showed up on every page using the template. I've tried to fix it, but now all parameters just show their own names (The {{-tags are visible). There are so many subpages and templates involved in autotranslate. What have I done wrong?

-abbedabbtalk 11:30, 28 April 2016 (UTC)

It's not your fault, <translate> tags are a usability nightmare. I'm aware of two folks here + one on mw: knowing how this works, and they have lots of more important/interesting things they might care about. –Be..anyone 💩 11:57, 28 April 2016 (UTC)
abbedabb Usually you have to use <noinclude></noinclude> to make it not show up on all the pages transcluded by the template. A better more longterm solution IMO would be to convert that translate function into Lua. Reguyla (talk) 17:48, 29 April 2016 (UTC)

April 29[edit]

GPLv3 ??[edit]

Hi, I have found on the Internet a book (PDF) explaining how to use Inkscape (in French). In this book, we can read Ce livre est publié sous licence libre GPLv3 (this book is published under a free licence GPLv3). It's OK for free licence but as far I know GPLv3 is for softwares and not for books. So, can I upload this PDF and which licence will I choose ?? Cordially -- issimo 15 !? 18:10, 29 April 2016 (UTC)

Creative Commons 4.0 can be converted to GPLv3, but not from it. See [12]: People may *not* adapt a GPLv3-licensed work and use BY-SA to license their contributions. This is not allowed by GPLv3. Thus, this compatibility determination only allows movement one way, from BY-SA 4.0 to GPLv3. So it would have to be uploaded as GPLv3. Wnt (talk) 01:14, 30 April 2016 (UTC)

April 30[edit]