Commons:Village pump/Archive/2017/07

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

Activating deepcat search

The gadget deepcat is an extremely useful tool to search entire categories (including up to 15 sub-categories deep). The Commons Help at Help:Searching#Working_search_enhancements_on_the_Commons as of now does not directly provide instructions on how to activate and use deepcat, but instead provides an external link to instructions on how to activate and use deepcat at the Nova Resource:Catgraph/Deepcat page. There is also a link to a discussion here. Finally, there is a note about using deepcat at MediaWiki/CirrusSearch help page which links to a footnote about editing your Custom javascript. According to the activation instructions:

To use [deepcat] on one of the other Wiki-projects each user has to include it on their user page. In order to do that, the following line has to be added to the user's own common.js (emphasis mine): 

mw.loader.load( "https://de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-DeepCat.js&action=raw&ctype=text/javascript" );

The above instruction (linking to a common.js at wikitech.wikimedia.org is different from the CirrusSearch footnote about editing your Custom javascript, which provides a link to editing user preferences at mediawiki.org. Clicking on the relevant Custom JavaScript link takes one to meta.wikimedia.org to create a global.js (not common.js) page where the above Javascript line can be inserted. And then the deepcat gadget works. If one creates only a common.js file as the main instructions indicate, then the deepcat search does not seem to work. Can someone check this? If I am correct, (a) it would be useful to have clearer instructions and corrected links in the above pages and footnotes, and (b) perhaps there is a case to create a separate page on Wikimedia Commons about deepcat gadget and search activation and functionality.
Finally, I wish that deepcat search can be made easier to use and more widely available on Wikimedia Commons through a similar activation process as for the Cat-a-Lot gadget. Apologies for the long discussion; would appreciate some responses.--Shankar Raman (talk) 08:28, 29 June 2017 (UTC)

Sounds interesting. I think there just never was interest in porting deepcat here because we already have Help:FastCCI which seems to have a very strong overlap. Jean-Fred (talk) 09:27, 29 June 2017 (UTC)
I agree Jean-Fred that there is some overlap between FastCCI and deepcat, but they are not identical in several ways that are very significant for those searching for content on Wikimedia Commons. Correct me if I am wrong, but here are a few examples of how I feel these are different:
  • FastCCI only searches categories (intersections such as incategory:A and incategory:B; or, in A but not B and so on.) Deepcat searches down a category tree plus any other search term that is added. For instance, a FastCCI search on the Category:Fish page for incategory:Fish and incategory:Tuna yields no results, while a deepcat search (deepcat:Fish Tuna) picks a bunch of results including those where the word "Tuna" is in Description or filename (and not necessarily in a category). This is a very useful function... to search not just by category, but for a word in caption or filename, down a large category hierarchy.
  • FastCCI only provides a gallery-type view of images; the results of a deepcat search is like that from a regular search, showing thumbnail, fielname, description etc.
  • FastCCI is available to all visitors to a category page, deepcat only to logged-in users (I think, if correct, this is unfortunate, too)
So I feel these are two complementary functions/gadgets which are both useful in their own ways. I also feel that my original points (providing correct details on how to activate deepcat in relevant pages) and making it easier to activate within Wikimedia Commons as with Cat-a-Lot would be very useful to address.--Shankar Raman (talk) 13:23, 29 June 2017 (UTC)
@Shankar Raman: The resource on Wikitech actually uses a link to Special:MyPage in its wiki code which then is converted to the actual link to your local user page exactly like it is done here with this. In the CirrusSearch help page on Mediawiki.org the link is directly given to the local preferences instead, where you can select on your own, whether you want to add it to you local commons.js or to your global.js fo all projects, which is found on Meta and therefore the special direct link is meta:Special:MyPage/global.js (if it does not exist yet you can create it).
@Perhelion and Zhuyifei1999: What do you think about adding deepcat as gadget like it is done in dewiki? Should Shankar Raman perhaps start a proposal? — Speravir – 21:19, 29 June 2017 (UTC)
I'd prefer a proposal. --Zhuyifei1999 (talk) 02:46, 30 June 2017 (UTC)
 Request Thanks @Speravir, Perhelion, and Zhuyifei1999: , please advise where/which page I should start a proposal in to add deepcat as a gadget in enwiki and commons (or across wikis). --Shankar Raman (talk) 13:03, 30 June 2017 (UTC)
Shankar, in Village pump/Proposals. You can search, how others asked for gadgets. — Speravir – 21:18, 30 June 2017 (UTC)
Thanks Speravir, will create a proposal and update here.--Shankar Raman (talk) 01:41, 1 July 2017 (UTC)
✓ Done here!--Shankar Raman (talk) 02:10, 1 July 2017 (UTC)

150 old postcards

I recently had to act fast. In a secondhand bookshop I got the opportunity to select lots of old postcards from the heritage of a postcard collector. The seller give me only limited time before he sold the collection on to professionals. (They buy these collections and then sell the individual postcards on the internet) After two hours work I selected 150 interesting postcards wich I intent to upload to the Commons. However this means I had pay out 300 euros (around 2 euro per postcard for high quality and special postcards) More than the usual 50 eurocent in the postcard boxes with enormous amount of junk. Then I spend about an hour to select 3 or 4 postcards. Is it posible to get some compensation for the outlay? I have selected postcards from all around the world (the deceased was wel travelled). I will need assistence to classify the Japanese ones.Smiley.toerist (talk) 12:21, 10 June 2017 (UTC)

Bulk unsorted price maybe 50 Euro-cents but if you have 150 interesting postcards in your possession then you may well have 150 postcards worth 2 Euros or more each – which is what you paid for them. To the right collector... some maybe worth more. Take it that this may be your first purchase of PP's. Get to know the market and sell them on. There is a big difference between a ordinary picture postcard of (say) Amsterdam Harbour and a rare ones that commands a few Euros more. If the Japanese ones are pre-war then all the better. Tell you what. After you have uploaded them -so I can see them, I might offer to buy the whole lot for what you paid for them via Paypal. Will even pay the post & packing... how's that! P.g.champion (talk) 13:57, 10 June 2017 (UTC)
To categorizes the Japanese postcards you may need some country specific knowledge. So you could ask here as a starting point on the talk page of: はがき P.g.champion (talk) 14:59, 10 June 2017 (UTC)
you could submit for a rapid grant, https://meta.wikimedia.org/wiki/Grants:Project/Rapid or talk to your local chapter for some funding. Slowking4 § Sander.v.Ginkel's revenge 01:55, 11 June 2017 (UTC)
I am not really a postcard collector in the sense that I only keep the postcards for reference and posible rescan. I am only interested in the historic images to upload to the Commons not the postcards themselves. If posible I photoshop them to remove stains, marks, discoulouring (I scan Black-White when the original image is Black and White) I have a box with scanned and uploaded postcards, one inbox with still to scan and upload and one small box wich has license limitations (most not yet 70 years old). If someone is really interested I can sell a specific scanned postcard, but I am not setting up a shop. I will be setting up a work category for the 150 postcards.Smiley.toerist (talk) 11:14, 12 June 2017 (UTC)
It is OK Smiley.toerist. Think we know where your coming from. You spend some 300 euros on cards that you knew would be of value on WC. Yet, you have no interest in the post cards themselves - just the images. Reading between the lines, you know that these are traded on eBay but you are primarily a WP contributor and not a eBay trader. You don't need to be a experienced trader to get your money back. Suggestion: Upload images to WC and the scans of the back of these postcards. Wait a while, for other editors to review and add provenance. Then ask around, friends, family and neighbours to see if the a have a spotty teenager that knows e Bay inside out and would love something to sell on your behalf. Tell them that you bought this for x and anything more they can get for you, you will spit the profits 50/50. You selected a 150 postcards and the seller had a cash buyer before him. He may well have given you a discount for a bulk purchase for 'selected' post cards that are worth more. You may have found yourself in the right place at the right time and seized the opportunity to buy. Trust your instincts. P.g.champion (talk) 15:34, 14 June 2017 (UTC)

As you see I started uploading to the Commons. The dating and the corrert licensing can be tricky. Is the Gibraltar one under a Spanish or GB license? I there a anonymous license for China? I will put all such uploads under the hidden workCategory:Postcard collection Smiley Toerist.Smiley.toerist (talk) 12:55, 20 June 2017 (UTC)

All the Japanese postcards have been uploaded. Two of them are already in the Commons from museum and library sources. File:Nunobiki Road Kobe postcard.jpg (the museum version is worse). I informed the Japanese community in Help_for_Non-Japanese_Speakers.Smiley.toerist (talk) 22:10, 24 June 2017 (UTC)
The China, Singapore, Egypt and Greece postcards have been uploaded. Dus the mosque in File:Mosque Saatli Djiami in Thessaloniki.jpg still exists?Smiley.toerist (talk) 13:33, 1 July 2017 (UTC)

June 11

Good and bad news about cross-wiki search results in Wikipedia

Good news: The cross-wiki search results from other projects are now live in English Wikipedia. Bad news: The search results from Commons are suppressed via RfC discussion in English Wikipedia, meaning users won't see those results in English Wikipedia. Don't feel down yet. Users from non-English Wikipedia may still see the search results in their respective language sites. Feel free to share your thoughts here. --George Ho (talk) 20:33, 22 June 2017 (UTC)

 Comment Tit for tat, if the English Wikipedia thinks it can rule above other projects and not being a sister project, and it will can block cross-wiki search results to several projects - including Wikimedia Commons - on the flimsiest of argumenst why then Wikimedia Commons doesnt block all images from being displayed on said Wikipedia? It would be at the same low level, but it would be a fitting answer to such callous act. Tm (talk) 21:56, 22 June 2017 (UTC)

Didn't Commons block cross-wiki uploads from Wikipedia? Kaldari (talk) 04:16, 23 June 2017 (UTC)
 Comment Alas it decided to do it, almost a year ago but fortunately cross-wiki uploads is still very much active. Tm (talk) 05:17, 23 June 2017 (UTC)
I find it interesting how much effort people who call Commons' content objectionable put into finding the most obscene material – some of it so obscene that one user couldn't help but prominently exhibit it on his personal user page.    FDMS  4    08:26, 23 June 2017 (UTC)
Meh, surely we are all bored rigid about the regular dramah ethusiasts shouting porn and sniping about Commons, but from the safety of the English Wikipedia community where the old boys club give a virtual slap on the back for throwing "cunt" or "fuck" into discussions, just to prove how Jimmy's personal interpretation of free speech is alive and well (diff). Perhaps instead of giving a fig for how they mess with their project, you might focus on what you want to see the WMF prioritize to make meaningful improvements to Commons? For example, you could go vote for an implementation of image hashes. --Fæ (talk) 08:40, 23 June 2017 (UTC)
people will go to a great deal of effort to denigrate those projects that they do not "control". not invented here, is become you shall not pass. such veto behavior would not matter much, except that it ruins a community. Slowking4 § Sander.v.Ginkel's revenge 20:15, 23 June 2017 (UTC)

There are two problems with allowing Commons search from Wikipedia. The first of course is the NSFW issue, which is a serious one and sadly the Commons reaction continues lack a mature understanding of what the word "censorship" means. Other image sites (Flickr and 500px for example) have ways of rating their content, so there's no fundamental reason why Commons could not and yet still exist as an uncensored repository of material. Freedom is allowing the hosting of content that some might object to, while also providing a user interface with options that permit users to choose what they want to see and when.

But the second problem is the nature of the way Commons is built, which is largely by independent users uploading distinct content, rather than a collaborative structured database. Both projects share a category system which is used by search and is maintained by a community who can watch over entries to some limited degree. But the text on Wikipedia is community created and reviewed and watchlisted. The text on Commons is by and large written by the uploader (or the third-party site from which content is scraped). This makes it much more likely that such text may produce undesirable search results: there are no eyeballs looking at it until it turns up in someones search. How quickly would Wikipedia/Commons be Google Bombed by folk uploading unpleasant images with "Donald Trump" in the description?

On the RFC, Fae suggests using Wikidata to associate search results with Commons images. That's certainly one way of trying to improve the quality/accuracy of results. It depends how well Wikidata is managed and resists vandalism/spam, which I don't know. A drawback is that it would hugely reduce the result set because very little content is linked.

WMF on the RFC said they tweaked the algorithm to "use boosted images". I don't know what they mean by that. Is it images that have passed FP/QI/VI? Or is it images that are in-use on sister projects (like a simple PageRank measure)? The problem with the former is that FP standards are high enough to exclude a lot of useful content, and QI is only valid for images taken by a Commons user, so excludes the millions of imported images. Requiring an image to be "in use" also hugely restricts the result set. All these measures could be used to ensure the top results are better and most likely relevant.

I would very much like my images to be displayed via Wikipedia search. Only a minority of my images get included in WP articles. So there is much content that will not be found. If Google Images turned up NSFW images in its first page of results, one could not use it in an open environment. They quite rightly realise that a "Safe search" option is necessary, though give the option to turn that off. When Commons refuses to implement something similar, the result is the entire site is blocked from WP search results. The result: my images are all censored because the fundamentalists outnumber the pragmatists. Way to go, Commons! -- Colin (talk) 09:48, 23 June 2017 (UTC)

don't know why you are fretting about the same old walled garden on english. there is not a new WMF initiative they will not opt out of, or filter. and yeah, to the extent you have an image at wikidata, that will route around. (and if you want your images used, you will have to edit them in yourself. getting to a thousand images in use is easy.) Slowking4 § Sander.v.Ginkel's revenge 17:09, 23 June 2017 (UTC)
I seem to remember this being discussed on Commons previously, about whether there should be a "flag for possibly objectionable material" or something. I notice a few comments in the Wikipedia discussion suggesting that Structured Data would somehow give a solution. Either way, whether structured data or a category, it would require software support so isn't something that the Commons community can implement on its own. I'm also sceptical that a single "flag" would be so easy to determine, given the endless possible disputes about exactly what would be considered objectionable, with the usual discussions about women breastfeeding, naked children running away from napalm, equal treatment between men and women, sexual images that are legitimately in use even on en.Wikipedia (which still prides itself on being uncensored), and different language Wikipedias potentially wanting to apply different criteria. --ghouston (talk) 03:00, 24 June 2017 (UTC)
yes, Commons:Sexual content and m:2010 Wikimedia Study of Controversial Content: Part Two; m:Image filter referendum/en; m:Image_filter_referendum/Results/en. as you see below, the "free speech" meme is strong here, and the commons local consensus differs from the wikimedia consensus. this will have consequences such as the brickbrats from english. Slowking4 § Sander.v.Ginkel's revenge 16:49, 24 June 2017 (UTC)
There is much foolishness written about "free speech", "censorship" and "democracy" by those who think (a) those things are vital and (b) have not the slightest clue what they mean. Wikipedia may not be censored but when I look at an article on Wide-angle lens, say, I would not expect to see genitals, shit, Donald Trump's orange face, or a promotional image for Coca Cola. Anyone adding such to that article would have their edits swiftly removed. That is not censorship but editorial consideration of what to show and when. There are other places on Wikipedia where such images would be necessary. Any search function on WMF sites should have similar control on letting users decide what to show and when -- such controls represent freedom for the user. They do not change our hosting policy, and users are free to turn off all restrictions if they wish. Preventing the implementation of such controls, by refusing to categorise images as NSFW, say, is about a fundamentalist minority exerting their world-view on others. It demonstrates no understanding of liberal values of tolerance and acceptance, which reject the notion that others must think like oneself and be forced to do so. Wrt ghouston, the fact that something isn't easy or has difficult edge cases, doesn't mean it shouldn't or can't be done: we went to the Moon remember, and this is hardly rocket science. I see more foolish writing below, "slippery slope" arguments, etc. These things already exist at Google, Flickr, 500px, etc and the world has not ended. In the end, if we don't provide the features users want, then someone else will add them. -- Colin (talk) 09:24, 28 June 2017 (UTC)
Good way to start an argument, by dismissing the intelligence of everyone who disagrees with you. Censorship has frequently taken the form of "editorial consideration". When you look at Wide-angle lens, you see a Japanese product (illegal in South Korea until about 20 years ago) and an uncovered woman. Your "editorial consideration" ignores the importance of those things. Where does "editorial consideration" become "censorship"? There's no clear line.
Rocket science is trivial, compared to any problem that involves humans who come in endless variety and are hard to experiment with and are likely to object to the result.
Google and Flickr and all the other groups have gotten shit for what they do, as well. There is no way to offer a single tag NSFW without dealing with the fact that what's NSFW can vary between countries and even workplaces, and that it's frequently deeply political. You dismiss any proper understanding of the depth of the challenge as "foolish".--Prosfilaes (talk) 08:12, 1 July 2017 (UTC)

First of all, a statement: Wikimedians's mission is to collect all knowledge and make it available to all people. Projects are just tools to achieve that end. They are not ends in themselves. So when there is talk about different content standards for diferent languages, I'm worried. We are being asked how we see Wikimedia Movement in 2030: with such different standards supported by the communities (normally, just the loudest shouters in each language plus some friends of theirs), what I see are a lot of Reinos de Taifas.
So files in Commons have to be equally accesible and usable from all projects in all languages. (Note: some languages are used in very different cultural contexts. A topless woman on a beach in Cullera is normal, but I don't know if it is the case in Mexico, Chile or Equatorial Guinea).
I have generally opposed flagging files or articles on religious, nudity or similar grounds, but right now, after what is happening in Turkey, China, and other places, I think that tagging files with "contains nudity" or "non kosher/halal/se salta la norma del Viernes Santo" is not all that relevant, as people already have to find their ways to our contents. So my main worry (a Big Brother compelling people to compulsory use filters) is already in place in a much bigger way (Big Brother closes access to every(wiki)thing).
In short, local communities' norms restricting access to other parts of the Big Wikimedia Project are bad. Something like building a border between Iowa and Illinois. B25es (talk) 05:46, 24 June 2017 (UTC)

I think in practice what you'd end up with is dozens of different flags that could be applied to an image, and separate raging battles on each project about which images should be filtered by default, and perhaps even whether the filter can be disabled in preferences for logged-in users. It's not just about nudity, the Wikipedia article mentioned gore, and there are other issues such as images of Muhammad or same-sex couples in some cultures. Maybe someone will want to filter images relating to abortion, evolution or global warming. It will also be offensive to some if same-sex couples are flagged as potentially offensive, so there would be no way to win. --ghouston (talk) 08:15, 24 June 2017 (UTC)
Most people would find photographs of mutilated corpses on the battlefield, or the bodies of children with disfiguring diseases, much worse to be 'surprised' by in a search than an erotic or nude shot. It's interesting to see how those that have lobbied for several years for NSFW or equivalent flags have learned to dodge the word "censorship" and elliptically talk about "unexpected results" without tackling the fact that in their tiresome "pron" campaign, they miss that the most truly disturbing images are famously historic or have high educational value, and should be accessible by minors who want to learn about the reality of war and disease. We all know that as soon as the WMF adopts any sort of NSFW flag, all those images will become impossible to access from most schools and countries where internet access is being ever increasingly censored by Government agencies. This remains the precise opposite of the open knowledge mission this project and the Foundation was established on.
I agree that astonishingly even illustrations of the fact of evolution is something we have to fight for, with Turkey right now removing any "anti-creationist" material from its education system. Pop, there go the dinosaurs. I don't want to contribute to any system that makes that type of illogical censorship easy to enforce. --Fæ (talk) 10:32, 24 June 2017 (UTC)
"surprised" is coder talk for "readers gave negative feedback". i tend to agree, given the virgin killers case but the slippery slope is too much. enabling a user filter gadget is not the same as a global blacklist by institutions. your ideology of "knowing what is best for minors" will get you called Socrates. Slowking4 § Sander.v.Ginkel's revenge 03:52, 25 June 2017 (UTC)
We are here to provide open knowledge (media) for everyone not to hear a bunch of reactionary creeps discovering Clark Kent is whip-able as everyone else or sexual intercourse exists. They want to display our content? Good. Lucky them. They don't? Their loss. After all, the arrival of "structured data" will allow censorship in the subtlest ways, so, why shoud we care at this point about providing a NoSafeForWork (in which particular country? in which particular job?) tag?Strakhov (talk) 13:02, 24 June 2017 (UTC)

Oh, almost forgot. Even when multimedia results, i.e. images, audio, and video, are suppressed, we can still see Commons results in English Wikipedia... just in text descriptions... and mixed into results. --George Ho (talk) 18:58, 24 June 2017 (UTC)

they tweaked the algorithm to "use boosted images" -Colin

This made me curious. Boosted-templates is a hidden feature that increases the rank of search results for pages containing specific templates. Commons customized that here: MediaWiki:Cirrussearch-boost-templates

See mw:Help:CirrusSearch#Boost-templates .10:21, 27 June 2017 (UTC)

June 25

"Holy Communion churches"/"Holy Eucharist churches"

I began to make changes before fully realizing that I shouldn't - that is, without first discussing. I apologize and will try to undo my changes.

"Holy Communion churches" could mean churches in which Holy Communion is received, i.e., almost all churches. Some, in particular for the Catholic Church that is about half of all Christians, apply the term "Communion" to what is only one part of the Eucharist or Mass. The churches at present categorized as "Holy Communion churches" are, I believe, dedicated to "the Eucharist" (generally with the adjectives "Holy" or "Most Holy") or "the Blessed Sacrament". I suspect that the apparent exception, File:Budapešť 0195.jpg, represents a Catholic church dedicated not to "Holy Communion" but to what Catholics also call "the Sacrament of the Altar", which is more than what Catholics call "Holy Communion". The Hungarian Wikipedia treats Oltáriszentség as a redirect to Eucharisztia.

I think therefore that the churches at present here categorized as "Holy Communion churches" would be better categorized as "Holy Eucharist churches". Theodoxa (talk) 15:23, 27 June 2017 (UTC)

One editor has thanked me for a change I made. So I will not (for now) undo it. Theodoxa (talk) 15:59, 27 June 2017 (UTC)
Thank you for what to me is a great help. I did not notice the existence of Category:Blessed Sacrament churches, which is sufficient in itself to overcome the inappropriateness of Category:Holy Communion churches. I suggest that the items in Category:Holy Communion churches and the subcategories that are grouped as "Holy Communion churches by country" be moved to the corresponding "Blessed Sacrament churches" categories.
I think that, for those who are not of Catholic background, "Holy Eucharist churches" would be a better name than "Blessed Sacrament churches", but I do not formally propose that further change.
I have looked at my User contributions and have found that I must not have saved my creation of a new category of "Holy Eucharist churches". It seems that, before completing the work, I went to discuss the question. This therefore is the only change that I actually made (and for which I was thanked). I leave it to you to undo it, if you wish. I presume that, if you think it would be suitable to do so, you know of some way of moving the files en bloc to a new categorization. I would have to move them one by one. Theodoxa (talk) 08:17, 28 June 2017 (UTC)
  • Google gives 231,000 results for "Blessed Sacrament church" and only 17,000 for "Holy Eucharist church". I think that makes it pretty clear which one is more common English. - Jmabel ! talk 23:26, 28 June 2017 (UTC)
    • ... and only 73,800 for "Holy Communion church", a further reason to make the category change from "Holy Communion church" to "Blessed Sacrament church". Can someone do it? Theodoxa (talk) 06:45, 29 June 2017 (UTC)
      • But is "Holy Communion" interchangeable with "Blessed Sacrament"? There are a lot of sacraments besides Communion. - Jmabel ! talk 13:45, 29 June 2017 (UTC)
        • Only one of the sacraments is called "the Blessed Sacrament". These churches are Catholic churches and those who frequent them and officiate in them consider Holy Communion to be only part of or one aspect of the sacrament of the Eucharist. Yes, some denominations call this sacrament Holy Communion or the Lord's Supper, but "Eucharist" is the most neutral term, the one used by the World Council of Church (of which the Catholic Church is not a member) in, for instance, its famous document en:Baptism, Eucharist and Ministry. The Category:Blessed Sacrament churches already exists and is a term that would be used by those in charge of and those who attend all those churches, including those at present categorized as "Holy Communion churches". This latter term is not acceptable to those in charge of and those who attend them, and there is no reason to impose it on their churches. Nor is there any need for two category names for the one reality. If you want to exclude "Blessed Sacrament churches" as the name of the title as "too Catholic", you may have to use a description such as "Churches dedicated to the Eucharist" or "Churches named for the Eucharist". Theodoxa (talk) 18:43, 29 June 2017 (UTC)
        • One (ex-)church that should continue to be categorized as a Holy Communion church is that in Category:Church of the Holy Communion (New York City). It was Anglican (US Episcopalian). Another Anglican (US Episcopalian) Holy Communion church, still functioning, is that in File:CHURCH OF THE HOLY COMMUNION, NORWOOD, BERGEN COUNTY NJ.jpg. Their people probably wouldn't like them to be classified as Blessed Sacrament churches. Theodoxa (talk) 09:55, 1 July 2017 (UTC)

Linked data in the watchlist?

A couple of days ago there was a big change in how my watchlist functions. Previously, items appeared on my watchlist when their wikicode changed (e.g., description, categories, geolocation, and the like). I think items also appeared when they were moved, deleted, or other file-level actions. This makes sense:

  • June 29, 2017 06:58 File:American Swedish Institute Turnblad Mansion.jpg‎ (diff | hist) . . (-64)‎ . . Martin Urbanec (talk | contribs) (Cat-a-lot: Removing from Category:Uploaded with Mobile/Android (Jul 2016 - Jun 2017))

But now I see watchlist changes appearing when there are changes to Wikidata items linked to Commons files. For instance:

  • June 30, 2017 m D 15:39 Commons talk:Structured data‎‎ (3 changes | history) . . (0)‎ . . [Jane023‎; 213.143.60.167‎; 181.161.191.34‎]
    • m D 15:39 Q5582 (diff | hist) . . 181.161.191.34 (talk) (‎Setting [en] aliases: Van Gogh, Vincent Willem van Gogh, Fan-kao, Vint︠s︡ent Van-Gog, Wensheng Fangu, Fan-ku, Vincent Van Gogh, וינסנט ואן גוך, Fan'gao, 梵高, Fangu, ビンセントゴッホ, ゴッホ, Vincent Willem van...)
    • m D 05:09 Q3305213 (diff | hist) . . Jane023 (talk | contribs) (‎Undo revision 510049884 by 213.143.60.167 (talk): vandalism)
    • m D 01:29 Q3305213 (diff | hist) . . 213.143.60.167 (talk) (‎Changed [en] label: painting body)

What's going on? I don't have anything in my common.js; I didn't enable ExpandedWatchlist in my preferences. I do have Wdsearch turned on, but its Preferences line item says it only affects search results (not the watchlist). So now I have lots of questions:

  • why did the watchlist functionality change?
  • Wikidata is now an option in the Watchlist options, but it's unchecked by default. Can we set those checkboxes to user-specific defaults?
  • how does Commons know which Wikidata items to place into the watchlist?

In short, this was a surprising change and I must have missed documentation about it. I like the concept, but I have to say that some of the Wikidata items linked from the Commons watchlist don't seem like reasonable matches. E.g., File:Beaver Creek concrete bridge. Black Hills of South Dakota - NARA - 283680.jpg links to Q61 (Washington, DC). How does that help a user who's watching that image? Worse, why does Commons talk:Structured data have links to Q5582 and Q3305213 that are important enough to put in a watchlist? Best, Runner1928 (talk) 21:25, 30 June 2017 (UTC)

Hi there! I think here there is some context? Hope this helps, --Elitre (WMF) (talk) 11:04, 1 July 2017 (UTC) PS: I am not 100% sure that's it, but still. :)
Runner1928 -- in my watchlist, I see a "Hide: Wikidata" checkbox. Perhaps the setting of this has been changed for your account? AnonMoos (talk) 16:16, 1 July 2017 (UTC)

Commons talk:Photo challenge May Results

Mammals: Entries • Votes • Scores
Rank 1 2 3
image
Title Zebra 2013 10 06 1274 Elephant mother and calf - chitwan Wildschwein auf einer Wiese im Nebel im Sonnengegenlicht
Author Alandmanson Gozitano GentsBilder
Score 23 20 20
Vehicles of public transportation: Entries • Votes • Scores
Rank 1 2 3
image
Title Pamban Bridge is a railway bridge which connects the town of
Rameswaram on Pamban Island to mainland India.		 Two Airbuses at San Francisco International Airport Sölden, Tirol, Österreich. Mit der Gaislachkogelbahn zum Ice Q.
Sölden, Tyrol, Austria. With the Gaislachkogelbahn to the Ice Q
Author Writingwithlight Pulsarwind Otto Domes
Score 19 18 17

Congratulations to Alandmanson, Gozitano, GentsBilder, Writingwithlight, Pulsarwind and Otto Domes. And please check out this month challenge. Also please vote on last month challenges and on future challenges. -- Jarekt (talk) 18:04, 1 July 2017 (UTC)

Maya Papsoe uploads

May you please take a look at the uploads of Meandshelbywalls (talk · contribs)? All of them are referring to the horror / cosplay actor Maya Papsoe. Some of the photos look self-made, others (1, 2, 3 (!) ) more like screenshots or webfinds. And I can't judge whether they are in scope.--Shlong56 (talk) 21:37, 1 July 2017 (UTC)

Projects

I have particular concerns about cat hierarchy within geo-political/geo-administrative categories. Are there Commons projects (as there are on Wikipedia), producing consensus guidelines around these, and other, issues. I can't imagine that we could resolve problems or disputes if there aren't, otherwise we would be just making it up as we go along. A village pump response would just rely on those who just happen along rather than those who have taken a deep interest and time over a particular subject. Acabashi (talk) 23:41, 18 June 2017 (UTC)

Commons does have Wikiprojects: Commons:WikiProject, but they are considerably less prominent than in en-wiki. Commons Wikiproject guidelines are not as generally accepted as Wikipedia project guidelines and they are not often used as arguments in disputes. MKFI (talk) 06:24, 20 June 2017 (UTC)
@Jmabel: @MKFI: Many thanks for responding. I've looked at the Commons projects and none seem to cover my concern, and possibly a future bone of contention, viz:
England geo-political/administrative entities typically for importance starts with England (1st level administrative order), then Counties (2nd level administrative order), then County districts (3rd level administrative order), and then Civil parishes (4th level administrative order). This follows accepted political/administrative hierarchy. On Commons this works fine when it comes to civil parishes, rightful placed below the others, and which is always rightly higher up the cat chain than any subservient settlement within them, these added as sub cats. The problem as I see it arises when the name of the civil parish is the same as a settlement within the civil parish. In these cases a civil parish is more significant, and I believe the actual plain name should prioritize the civil parish without any definition, ie '(civil parish)' in brackets next to it. Any hamlet or village lower level settlement with the same name within that civil parish should have its status under the civil parish added after its name, ie (hamlet) or (village). This is not obtuse as any search for a name will go to the plain name first (as with all cat searches), which if this refers to the village, the more important civil parish and its photos is sidelined by a bracketed afterthought.
In many cases there are so few photos that it is not worth separating settlement and civil parish, but in others there are so many photos that separation is advisable to avoid confusion. This general type of separation works well on Commons, for example with churches ['St Andrew's Church (stained glass)' under 'St Andrew's Church']; and would we change 'New York' as 'New York (state)' for the sake of 'New York City', or change 'Essex' to 'Essex (county)' for the sake of its Uttlesford district. I am suggesting that where a civil parish and village within it holds the same name, the undoubtedly more important civil parish should hold the name, and the village should be bracket-identified as such, as I have done here and here. Thanks. Acabashi (talk) 21:01, 20 June 2017 (UTC)
@Acabashi: I know practically nothing about administrative organization of England but this seems sensible. In my opinion you can use this scheme, and perhaps write a note of this in Category:Subdivisions of England to aid other users. We get a lot of mass uploads from Flickr/Panoramio/etc. and users sorting the results are often not very familiar with all the topics.
Commons has a smaller community, and that community is spread thinly among many languages, millions of categories and tens of millions of files. And since files and categories generally require less collaboration per page than articles there is a tendency to just "do your own thing". Category tree structure is perhaps where most collaboration is done, but even then there is less firm organization structure than bigger wikis. MKFI (talk) 10:17, 21 June 2017 (UTC)
 Oppose Prioritising putting civil parishes ahead of the village they are named after: The village is more significant to viewers and is the most commonly understood term of that name, even though the parish is larger.
In particular, note that when an English district (3rd level) is named for a town/city, its the town that gets the base name, while the larger district is put at a disambiguated title. So Category:Canterbury is about the city, while Category:City of Canterbury is the district. This was extensively discussed on WP, and the same approach should be applied to parishes. See my more detailed comment here.
A side problem is the parish is the administrative unit, and its the administrative unit that holds status as a city or town. ie If Foo-town is a town in Barshire, then legally its the parish of Foo-town that is the town, not the urban area, and that makes Foo-town (town) confusing.--Nilfanion (talk) 13:13, 21 June 2017 (UTC)
@Acabashi: I'm not sure this is a problem. Few parishes have so many pictures that it's a problem to scan through them looking for pictures of the particular village (the main culprit is the Geograph project, from which a million or so images were imported by a bot and mostly allocated to parishes). Wikipedia articles tend to cover both parish and village, and I can't see any reason why Commons categories can't do the same. If there's a need, just add a subcat of "Foo village" within the "Foo" category. Dave.Dunford (talk) 13:47, 21 June 2017 (UTC)
@Dave.Dunford: Your edit summary has confused me. I'm pretty sure that is Acabashi's proposal is (1) only split if needed, and (2) if a split is needed put the parish at "Foo" and the village at "Foo (village)". That's what pretty much your suggestion, but you described at as "oppose"? My position is the contrary one to the proposal, which says if a split is needed "Foo" should be the village and "Foo (civil parish)" the parish (rationale is above).--Nilfanion (talk) 16:09, 21 June 2017 (UTC)
@Dave.Dunford: Apologies, you're right, I suppose I am supporting the proposal. What I was objecting to was the idea (which maybe wasn't being suggested) that every parish category should have a subcategory called "Foo village" (or "Foo (village)") when in most cases there's no need, all the photos can simply go in the parent category. I'm with Acabashi on the hierarchy too: parish above, village below. This also works if a parish contains more than one village or hamlet, which doesn't work if it's the other way round. Dave.Dunford (talk) 17:41, 21 June 2017 (UTC)
OK thanks, that makes sense. Either way around the village category would be a sub-category of the parish category (parish above, village below). The only real difference is what "Category:Foo" actually contains. My view is that category should be as useful to people searching for media as possible, which means making Category:Foo about the most common, actual day-to-day meaning of "Foo" (which is the village). That means the less common meaning (the parish), gets a disambiguated title, even though it is a larger geographic area.
IMO this is exactly the same situation as with districts (everything from Ashford to Wokingham); Barnsley is about the actual day-to-day meaning of "Barnsley" (the town), while the less common meaning (the district) gets a disambiguated title (Category:Metropolitan Borough of Barnsley). I see no reason why parishes should be any different, apart from to make it harder for people actually looking for media.--Nilfanion (talk) 17:57, 21 June 2017 (UTC)
Thanks Nilfanion. That approach (use a single combined "Foo" category for parish and village where the volume of photos is small; otherwise, add a disambiguated "Foo (parish)" category above the "Foo" village category to hold the non-village photos) makes perfect sense to me. Dave.Dunford (talk) 09:38, 27 June 2017 (UTC)
Yes the common convention has generally been to have the parish disambiguated and the settlement at the base name. If like Whitchurch the parish doesn't include the village a hatnote can be included. As pointed out we have done the same with districts, this is also like Liverpool vs Liverpool F.C.. We don't want disambiguation pages at the base name if we have 2 categories about variations of the same place (DAB pages are for situations where substantially unrelated topics share the same name like Poughill), as users can just navigate through the category tree per w:WP:DABCONCEPT. In the case of Barnsley the other different meanings are far less important to Barnsley in South Yorkshire taken as a whole can be considered primary and images intended for the district can be defused. A further question that has been raised before is where the village and civil parish are spelled different on the OS but are simply alternative names. See Category:Stainton Dale and Category:Staintondale. In this case probably "Stainton Dale" should redirect to "Staintondale" and the parish be at "Stainton Dale (civil parish). Similar to Category:Stratford-upon-Avon and Category:Stratford-on-Avon District. Crouch, Swale (talk) 13:45, 23 June 2017 (UTC)
@Nilfanion: @Jmabel: @MKFI: @Crouch, Swale: @Dave.Dunford:
I think the idea of a hatnote on parish settlement pages is very sound and essential if the civil parish is to have '(civil parish)' after it where the name is the same, or close to the same, with the settlement with no added appendage.
We should remember, this includes me, that Wikimedia is a poor relation depository... have you like me got a blank look when explaining where the the photos I'm taking are going to be ? Everyone knows of Flickr, etc., but I've found that virtually 100% have never heard of WikiCommons. People search and link through via Google images almost exclusively. Why do Commons images come so far down a Google search nowadays ? Because they are not found and linked from external sites... just put a Google image search for 'Boreham, Essex' to see how 'family search', 'beerinthe evening' 'primelocation' and the like take priority... Commons, unlike previously, is almost invisible. If anyone not initiated (virtually everybody) does find their way to Commons we have cats (ie tags) out of the way at the bottom of the image page, not immediately against the image as in rival depositories, so cats are next to useless anyway to those not in the know.
I know this appears slightly off the point, but it isn't, and raises perhaps a wider point on the way image pages are structured. A hatnote appears at the top of a cat and is immediately apparent to anyone (the most) who doesn't realise there are bottom-of-page cat-tags, which, if the hatnote is for the civil parish it will give a fair crack of the whip to those photographers who have bothered to stray past the confines of a village which is often a minor aspect. I would go farther... I would add a hatnote at the top of any settlement, this linking to the parish, even if of a different name. Acabashi (talk) 21:18, 26 June 2017 (UTC)
@Acabashi: A hatnote only makes sense for the precise situation here (where the parish is secondary to a village of the same name), as a hatnote is to link an alternative concept of the same name. However the similar concept of a navigation template apply to the more general case and may be suitable. For example w:Template:Chelmsford is district-level, and parish-level equivalents could be viable on Commons.
With regards to the point about Commons being a poor repository, I agree the site has got plenty of flaws. However its big selling point is that the media is free to use. A generic Google image search returns all sorts of images, but you can't use any of them without violating their copyright. If you restrict the search to those you could use non-commercially, then Commons and Geograph dominate the results. If you also exclude small images then Commons is the only site to return relevant files.
An interesting thing to do is a Google search for your username. That shows a lot of your files are used all over the internet, after you uploaded them to Commons.--Nilfanion (talk) 07:46, 3 July 2017 (UTC)
Comment: I prefer the Great Waltham solution to the Nuthurst one, as above. As Nilfanion says, the principle of least surprise means that (if there are separate categories for village and parish) the undisambiguated category should be the village rather than the parish. This is a reversal of my earlier position. Dave.Dunford (talk) 10:55, 27 June 2017 (UTC)
Yes this would make sense, if there are subtopics of a given term then it should refer to the broader meaning, Liverpool vs Liverpool F.C. is another example even though the football team may be more well known it is still a subtopic. Acabashi are you suggesting that Category:Blackmore should have a hatnote to Category:Blackmore, Hook End and Wyatts Green or even that Category:Nounsley should have a hatnote to Category:Hatfield Peverel. This would seem excessive use of hatnotes if they aren't likely to be confused (due to having different names, see w:WP:HATEXTRA) and because the parish cat is a parent cat anyway. I don't think a hatnote to the parish is even particularly necessary, unless like Whitechurch, Devon the parish doesn't contain the village per w:DABCONCEPT. Crouch, Swale (talk) 08:43, 28 June 2017 (UTC)

June 19

40M

A few minutes ago we uploaded our 40th millionth file. Hurrah! -- Tuválkin ✉ ✇ 23:47, 21 June 2017 (UTC)

Congratulations Commons comunity! --Hume42 (talk) 08:11, 22 June 2017 (UTC)
Whouuuuu — 0x010C ~talk~ 20:31, 22 June 2017 (UTC)
Does the uploader of #40,000,000 get a prize, a t-shirt or something? Beyond My Ken (talk) 21:06, 22 June 2017 (UTC)
… and of these Ms the site has several millions items of garbage, and much higher garbage ratio in recent uploads. The time to look for pockets where the garbage accumulates due to various glitches in software or display→‎keyboard interface. I deem, there are more such pockets than one. And, then, to chase the waste-makers, fix software, add abuse filters, or whatever. Incnis Mrsi (talk) 17:15, 25 June 2017 (UTC)
I do not understand the previous remark. Can anyone clarify? - Jmabel ! talk 04:10, 26 June 2017 (UTC)
@Incnis Mrsi: See above. —Justin (koavf)❤T☮C☺M☯ 16:00, 2 July 2017 (UTC)

I'm quite glad that we have not identified a "40 millionth file". It always was an arbitrary choice due to the way so many uploads get removed within seconds of upload changing the way the count might work. It also encouraged manipulative number carpetbagging by those with bot uploads, which never felt right. --Fæ (talk) 16:29, 2 July 2017 (UTC)

June 22

Looking for a category report tool

I'm looking for a tool that, if given a category, will give a list of all files in that category and the categories each one is in. Does anything like this exist? Alternatively, is it possible to do it with a Quarry query? I can't seem to figure one out. (I'm currently tidying up an old mass upload at category:Images from the Canadian Copyright Collection at the British Library. These all have a JPG + TIFF version of the file, and I'd like to make sure that the categories on each one line up. Running this report seems a useful first step...) Andrew Gray (talk) 22:48, 29 June 2017 (UTC)

@Andrew Gray: Gallery details gadget can do this, but it is intended as a UI tool and not a separate report (despite the name it will work on category pages as well). MKFI (talk) 07:33, 1 July 2017 (UTC)
@MKFI: Thanks! I think this might prove challenging for sorting through 6500 images, but I'll give it a go. Andrew Gray (talk) 11:09, 1 July 2017 (UTC)
If you can specify what you want in a way that can be reliably automated, then doing it in Pywikibot would probably be trivial. For example ensuring every (jpeg, tiff) pair has identical visible categories while ignoring hidden categories would be a couple of lines in Python. For my past projects which include such pairs, I have tended to let the jpeg version have more categories as it's more likely to be useful in Wikipedia articles. --Fæ (talk) 11:45, 1 July 2017 (UTC)
@Fæ: I originally considered whether it would be worth keeping all the master tiffs in a single flat category, but in practice people tended to sort them into the content categories as well, so I think it's best to standardise on that approach rather than go against the flow...
What I think we need is for pairs of images (named "... (HS85-10-xxxx).jpg" & "... (HS85-10-xxxx)_original.tif[f]" respectively, both in Category:Images from the Canadian Copyright Collection at the British Library) to be synchronised such that they both contain the same visible categories. There are a number of invisible tracking categories and these can probably be skipped at this point. I can provide a list of paired filenames if that would make things easier.
It'd also be really useful if the script could export a list of the resulting image-category pairs - I'm wanting to do a little work to look at what categorisation is there, what groups might need sorting, etc, and feed back the categories to the BL for them to play with as well. Does this sound achievable? My pywikibot experience has always been limited to uploading new files/pages... Andrew Gray (talk) 15:11, 1 July 2017 (UTC)
I'll take a look, it's not hard sums. :-) I'll put the result on Github once it's working so with a bit of thought you may be able to reuse the code in future projects.
In nearly pseudocode this looks like:
  1. Open the parent category for jpegs matching regex /\(HS85-10-\d+\)/ and filter to just those with a matching <filename>+"_original" TIFF; then hold these in an array of pairs.
  2. Do a two way sync of visible categories between the jpeg TIFF pairs.
  3. Dump the list of discovered pairs in a sandbox on-wiki somewhere for analysis, extra nice if this were formatted to a wikitable of links.
--Fæ (talk) 15:20, 1 July 2017 (UTC)
Looks good. A few quick notes on this:
  • About 65 HS85 numbers have JPEG only; this is a known issue :-)
  • I cannot guarantee the two filenames are consistent (they usually are, but I wouldn't always bet on it) and so matching solely on the HS85-10 number is probably more reliable.
  • You'll need to tweak the first regex - there are a few where the xxxx element in HS-85-xxxx may contain non-numeric characters (alphabetic suffixes, dashes, etc). But it will always be in that bracketed form. If you want to save time, this list has all ~3100 valid numbers from a report I ran yesterday (including a few hundred from the BL l.r.233.b.57 series - these can safely be skipped and we can just concentrate on HS85)
  • There are also some where a third or fourth image has been created from the upload; these are usually called something like "...(HS85-10-12345)- cropped.jpg". It might be worth doing a separate query on these to see whether they line up with the two parent images with that number, but not actually writing the changes, as some will have a category only appropriate to the cropped item.
Thanks for this; looking forward to seeing what emerges! Andrew Gray (talk) 15:51, 1 July 2017 (UTC)

Noting your comments, some of these can be on a second pass so long as the first run finishes okay. --Fæ (talk) 16:48, 1 July 2017 (UTC)

All seems to be working now, including accepting non-numeric IDs. The run is slow, taking a few hours, but I prefer Faebot to do unusual stuff that way. The results table will update itself eventually, it's on a separate bit of code that retrospectively sniffs the revision histories. As for examining derived crops, I'll leave that in your hands, it's well within your skill set. :-)

By the way, were this a paid gig, I'd expect the category testing to be a lot smarter, volunteer spare time only goes so far, especially in sunny weather. It would not take much to test if categories to be added were parents or grandparents of others and trim them down, it should also be reasonable to test the categories to see if they were any sort of maintenance cat and skip duplicating those. It's these two areas that are most likely to cause complaints when category syncing. --Fæ (talk) 12:25, 2 July 2017 (UTC)

June 30

New Zealand official history of WWII copyright query

[1] doesn't have a share-alike licence so I think that [2] "In copyright texts and images are made available for non-commercial use only." applies but I'm not sure, I've only used images from Great War texts before. Can anyone enlighten me please? Regards Keith-264 (talk) 22:22, 30 June 2017 (UTC)

What Jmabel says is right. However per source paragraph 3, "Where the original text is out of copyright", then the original text is out of copyright and regardless of what this organization's policy is with regard to sticking a CC-BY-SA license against the text, this does not stop the text being legally public domain. I suggest you pick out which examples you want to publish either here or on Wikisource that are out of copyright and use those examples to check whether the Victoria University of Wellington Library is attempting copyfraud, or whether there can be any doubt about the text being public domain.
To illustrate, this letter written in 1822 is definitely public domain and can be imported to Wikisource. The license displayed on the source site is CC-BY-SA, but it is obviously a direct case of copyfraud and the host organization Victoria University of Wellington is failing their most basic educational mission, and should be ashamed of misleading the public by deliberately publishing pseudolegal flimflam like any cheap fraudster.
Thanks for raising the case. --Fæ (talk) 09:13, 1 July 2017 (UTC)

I have sent a tweet here to complain about their copyfraud in public, hopefully to shame them into reconsidering. I encourage others to retweet or send their own to @victoriauninews. --Fæ (talk) 09:28, 1 July 2017 (UTC)

The original was published in 1961, apparently crown copyright in NZ is 100 years.Keith-264 (talk) 17:27, 2 July 2017 (UTC)

July 01

Join the strategy discussion. We’ll talk about the challenges identified by research

One of many related in-person discussions. Iberoconf, Buenos Aires

Hi! I'm a Polish Wikipedian currently working for Wikimedia Foundation. My task is to ensure that all online communities are aware of the movement-wide strategy discussion. That, of course, includes you!

Between March and May, members of many communities shared their opinions on what they want the Wikimedia movement to build or achieve. (The report written after the first round of discussions is here, and a similar report after the second round will be available soon.) At the same time, designated people did a research outside of our movement. They:

  • talked with more than 150 experts and partners from technology, knowledge, education, media, entrepreneurs, and other sectors,
  • researched potential readers and experts in places where Wikimedia projects are not well known or used,
  • researched by age group in places where Wikimedia projects are well known and used.

Now, the research conclusions are published, and the third round is going to begin. Our task is to discuss the identified challenges and think how we want to change or align to changes happening around us. Each week, a new challenge will be posted. The discussions will take place until the end of July. Literally all of you are invited!

If you want to ask a question, ping me or read the FAQ. SGrabarczuk (WMF) (talk) 21:54, 2 July 2017 (UTC)

July 03

Please help for turning upright

File:PZN Wiesloch Church Inside.jpg. Thank you! -- Heimkinderverband (talk) 12:19, 9 July 2017 (UTC)

Heimkinderverband, I tagged it with {{rotate|270}}. A bot should rotate it soon. seb26 (talk) 13:05, 9 July 2017 (UTC)
thank you!! Heimkinderverband (talk) 13:06, 9 July 2017 (UTC)
This section was archived on a request by: Speravir 16:47, 9 July 2017 (UTC): Rotation done.

300MB image

I just uploaded this image, the oldest known printed map of Jerusalem and Palestine, from the LOC. The image is so large that the text on it can't be read at normal resolution, but the file is too large for most computers to use at full size. Any ideas how I can make a medium-sized version of this? My computer is old so it occasionally freezes when trying to manipulate it. Onceinawhile (talk) 17:34, 2 July 2017 (UTC)

@Onceinawhile: One option is to use a lossy file format. TIFFs are similar to WAV or FLAC audio where they end up recording all of the data in a file, including a lot that is basically redundant or which can't even be perceived by humans. So one way to save on the file size is to save audio as an MP3 or images as a PNG. You can try opening the image in some standard image editing software (e.g. MSPaint) and then Save As "File.png" instead. That will make the file much smaller but will also delete some data from the image. —Justin (koavf)❤T☮C☺M☯ 17:56, 2 July 2017 (UTC)
That's clear, thank you Justin. Onceinawhile (talk) 17:57, 2 July 2017 (UTC)
@Onceinawhile: See also templates {{LargeImage}} and {{LargeTIFF}}.— Speravir – 20:15, 2 July 2017 (UTC)
@Onceinawhile: I locally created a JPEG file with a size of over 27 MB (90% quality; with 100% it would be around 135 MB). I could upload this, but, please, fix the author attribution first: There does not belong a link (this is actually the source link, where you used a template). — Speravir – 02:42, 3 July 2017 (UTC)

There is no need to create your own local jpegs, Commons can do this for you by generating a jpeg of any size you wish. This link takes you to a 25% sized version (5060 pixels wide), while this link is 1/8th size at 2530 pixels wide. The way to create these is to click on the different sized thumbnail links on the image page and replace the "lossy-page" width number in the URL. --Fæ (talk) 10:26, 3 July 2017 (UTC)

Fæ, I think you misunderstood something. I know about the preview images in JPEG format, but that was not the question in my opinion. We must assume that a lot of users do not know this and simply klick/press on the preview image and then on the big image, or even more probably they have the Media Viewer activated, for which I do not know whether it uses the original image or preview formats. Anyway, after the author fix by Huntster I uploaded 2 jpeg versions of the TIF image and added the LargeTIFF template. — Speravir – 18:38, 3 July 2017 (UTC)

I tried to upload a version of the TIFF file with a different colour profile to try and avoid that purple hue, but chunked uploading does not seem to be working (getting "stashfailed" error). Anyone seen this before, or know how to fix it? Heh, I also locally created a 27 meg JPG and a 43.5 meg PNG, if there's any want for them. — Huntster (t @ c) 12:43, 3 July 2017 (UTC)

Huntster, I use the script bigChunkedUpload, see in Help:Chunked upload or the original documentation (transcluded into the help page). I just uploaded 2 JPEG versions of the TIFF file with this script. And I do not have a purple hue. If you use Firefox set these two setings in about:config:
  • gfx.color_management.mode set to 1
  • gfx.color_management.enablev4 set to true
For the meaning search for these preferences. — Speravir – 18:38, 3 July 2017 (UTC)
Oh, ping went wrong @Huntster. — Speravir – 21:23, 3 July 2017 (UTC)

Tech News: 2017-27

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • There was a problem with maps on Wikimedia wikis that used <mapframe> when you clicked on the link to another map service. Open Street Map or Google Maps are examples of other map services. If you had marked a place on the map the marker would not be in the same place on the other map service. It was in the middle of the map. This has now been fixed. [3]

Changes this week

  • Very old and inactive unpublished translations in the Content Translation database will be removed. This is because of technical maintenance. If you have not worked on a translation after 1 January 2016 you will lose it after 6 July. If you want to keep the unfinished translation you need to open it before 6 July with the Content Translation tool. You can continue working on it later. Translations that were started or have been worked on after 1 January 2016 will not be affected.
  • There is no new Mediawiki version this week.
  • EventStreams is a new way to show activity on Wikimedia wikis. It works with the recent changes feed. It will do more things later. It will replace RCStream. Tools that use RCStream should move to EventStreams before 7 July. Tech News wrote about this in the 2017/07 issue. [4]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:31, 3 July 2017 (UTC)

Rotating videos

There are currently two videos erroneously including the {{Rotate}} template, which only works for images. Could an expert of you, please, fix these manually and remove the template? These are File:Hakubutsukan-Dobutsuen 2017.webm (but I am noit sure, whether the request is substantial) and File:Machines de construction - juin 2017 - ZAC des Malettes.webm. — Speravir – 23:23, 8 July 2017 (UTC)

Moved to Video and sound workshop. — Speravir – 22:15, 10 July 2017 (UTC)
This section was archived on a request by: --Speravir 22:15, 10 July 2017 (UTC)

Need help fixing blurry image

I tried holding my phone still to the best of my ability but there's still some motion blur. I uploaded the original. I used HDR feature. Could somebody please help me fix this? There's no other image of a TMS setup and it could be used if it looked sharper. Thank you. Technophant (talk) 15:02, 10 July 2017 (UTC)

This section was archived on a request by: Speravir 22:17, 10 July 2017 (UTC)

A question

Does this image have any copyrights? because it's just simple lines on it. Thanks Super ninja2 (talk) 08:38, 2 July 2017 (UTC)

@Super ninja2: Not in the United States at least. I can't imagine anywhere that would consider this original or transformative work. —Justin (koavf)❤T☮C☺M☯ 15:56, 2 July 2017 (UTC)
@Koavf: What about this? Super ninja2 (talk) 05:48, 5 July 2017 (UTC)

Malta postcards

Can anyone date the poststamps and postcards? I have other examples of old postcards of Malta.Smiley.toerist (talk) 19:17, 3 July 2017 (UTC)

The first appears to be a 1914 stamp - source, though I am unable to vouch for the reliability of the source (I just did a bit of google digging) The Land (talk) 20:20, 3 July 2017 (UTC)
The second appears to be a 1903 design stamp: here. Same caveat. :) The Land (talk) 20:22, 3 July 2017 (UTC)
Also, while I don't have any special knowledge of Malta's maritime history, I do know a fair amount about ships in general I don't see anything that is inconsistent with those dates. In particular the profile of the warships in the background in the 2nd image is consistent with the years before (or possibly during?) WW1 - much before 1905, or after 1918, they'd probably be different shapes. The Land (talk) 20:38, 3 July 2017 (UTC)

Whats 1/2d? 3 pence I understand under the imeperial coin system: 1 pound = 20 shillings, 1 shilling = 20 pence.Smiley.toerist (talk) 13:36, 4 July 2017 (UTC)

July 04

Proposed deletion of my work

Moved to Commons:Deletion requests/Files uploaded by Dan Nicolae 77. —LX (talk, contribs) 11:50, 11 July 2017 (UTC)
This section was archived on a request by: Speravir 16:43, 11 July 2017 (UTC)

Cernavodă questions

How old is this station clock? The station lies on the railway line to Constanta. The railway bridge over the Donau was only opened in 1895. However the clockmaker died in Jean-Paul Garnier died in 1869. Maybe moved from an older station? The local guide said that this was the oldest stationclock in Romania and probably in the world. I doubt that. But maybe for electric clocks.Smiley.toerist (talk) 10:44, 28 June 2017 (UTC)

The second question is how to classify this building. This regulates the river/canal traffic on the Danube. At this strategic place the canal to the Black Sea branches of form the Danube river. (East branch)Smiley.toerist (talk) 10:44, 28 June 2017 (UTC)

@Smiley.toerist: about the clock maker: while it is true that the man himself died in 1869, his eponymous company was in business until 1933 [5]. It's a Dutch link, but that should be no problem for OP. --HyperGaruda (talk) 09:35, 5 July 2017 (UTC)

CropTool

Crop tool (which is excellent) hasn't been functioning for a day or two. I don't seem to be able to get to talk with the creator. How do I let him know? Thanks, Eddaido (talk) 22:03, 28 June 2017 (UTC)

@Eddaido: Should work now, give it another try please! --Hedwig in Washington (mail?) 01:55, 29 June 2017 (UTC)
Thank you Hedwig. I even tried re-booting my Mac but it seems to behave no differently. Comes up with this "Template:CurrentUrlParams.title" and then a great deal of very technical stuff! Regards, Eddaido (talk) 06:07, 29 June 2017 (UTC)
@Eddaido: Generally it helps to ping/mention me ;) – Danmichaelo (δ) 11:20, 5 July 2017 (UTC)
Thank you but I did try. It presumes much more knowledge of computers than I have. I couldn't make sense of what I found. Regards, Eddaido (talk) 11:25, 5 July 2017 (UTC)

A general note: Magnus Manske is not amused about the situation with Tool labs either: phab:T169210 (I had asked him for restarting one if his tools and pointed at same post to the recurring issues with Tool Labs.) — Speravir – 21:32, 29 June 2017 (UTC)

Many thanks for clarifying things, Eddaido (talk) 12:10, 30 June 2017 (UTC)

June 29

Welcoming Sandra Fauconnier, our new Structured Data community liaison

The Technical Collaboration team is very happy to welcome Sandra Fauconnier, our new community liaison focusing on the Structured Data program. Sandra will support the collaboration between the communities (Commons, Wikidata, GLAM…)  and the product development teams involved at the Wikimedia Foundation and Wikimedia Germany. The plan is to improve Wikimedia Commons allowing users to better view, translate, search, edit, curate and use media files. To achieve that, the Commons backend will be migrated to Wikibase, the same technology used for Wikidata. Many other features and pieces are part of this plan. In the near future, as the first prototypes and tests start to emerge, Sandra will also drive the engagement with new individual content contributors, existing and new GLAM organizations, and developers interested in exploring the possibilities of the new platform. You can find more details here.--Qgil-WMF (talk) 11:56, 3 July 2017 (UTC)

  • Welcome and good luck, sure, but don’t be surprised to be received with deep suspicion and distrust by some of us (me included): Every time the WMF is «excited to announce» something, it is usually a step back in our work of building and curating a free media file repository. -- Tuválkin ✉ ✇ 16:46, 3 July 2017 (UTC)
    • I suggest you be as active as possible in trying to shape this. Try to come up with new and fresh ideas, alternatives etc. Present your own personal 3 year plan and whatever else you can come up with. This is going to be VERY hard. And we're VERY far behind compared to other platforms. I mean I just looked at our license templates this week, and it seems no one has been paying attention to that stuff on a technical level since 2009 (we added the metadata in 2010/11, but that was just tacked on). Commons has a LOT of work ahead of it if it wants to catch up. Just saying that the foundation(s) should do all of that work (and to perfection at that) is not going to be enough. At the same time I ask the foundation to conduct a LOT of user testing. Fail twice, get it right the third time, but for once, it would be nice if we could get things right before the money runs out :D —TheDJ (talk • contribs) 11:29, 4 July 2017 (UTC)
  • Congrats Sandra. I look forward to being positively engaged. As one of the most active uploaders, I feel odd that I have no sense of where this is going and that I have yet to be seen as a part of it. Hopefully having a dedicated liaison will address that gap. --Fæ (talk) 17:02, 3 July 2017 (UTC)
  • Welcome. I hope to see things moving forward soon. Regards, Yann (talk) 08:08, 5 July 2017 (UTC)

MassMessage request

Is there a place where I could request a MassMessage? I would like to invite all the participants of a photo contest on Commons to attend the awarding ceremony. Thank you. //  Gikü  said  done  Wednesday, 5 July 2017 13:04 (UTC)

I will go with a bot, thank you. //  Gikü  said  done  Wednesday, 5 July 2017 18:39 (UTC)

Proposal for handling 10,000 duplicates

Good news everyone!

Faebot has currently identified over 10,000 visual duplicates (20,000 individual files) using image hashes. The quality of this technique appears to be in the order of 99.9% accurate and Faebot has already worked through around 70% of our collections of 200,000+ military related files.

To pick which duplicate might be the best to be deleted is not as easy as picking the earliest upload. There are a variety of factors and administrators will get bored and tired trying to handle the backlog with our traditional procedure per COM:Dupe. To help with the choice and confirmation of which file should be the duplicate, I have started testing out a script that Faebot can apply to the files which would give anyone reviewing duplicates all the information they need at the top of the chosen duplicate image, before either confirming the {{duplicate}} tag or working on merging information to the file to be kept. The factors to be applied in this order are:

Width
The width in pixels, this is nearly always identical, but if not then the largest must be kept.
Global usage
If files are in global use (off-Commons), then the priority will be to keep the file most in use.
Local usage
As with global use, the most used will be preferred to minimize changes.
Linkrot
The number of dead links on each image is counted and compared. The image with the lowest number of dead links, normally one has all working links, gets kept.
Upload year
The file uploaded most recently is the one to be deleted.
Categories
Everything else being equal, a category count helps decide which file is best to be kept.
File name (title) length
If one file name is below 25 characters and below half the size of the other file name, then the longest is preferred as probably most descriptive.

Again, the intention is not to start auto-deleting files, the numbers will be presented in a template at the top of the image page as a "pre-duplicate" notice. If reviewed by a non-admin, the intention would be to add a duplicate template for admin action, but an admin may want to skip this step and delete based on the information presented.

Test run

To illustrate with some real examples, here's a test run which is quite interesting to look through:

Test case 5 July 2017

The first listed file is the suggested duplicate, the second its target. Ticks show some factors for choosing this duplicate, crosses show warnings and other counter indicators. 

1
<- File:Defense.gov News Photo 070209-D-2987S-007.jpg
-> File:Lute and Kimmitt conduct war briefing, Feb 9, 2007.jpg 
✓ Target file is in use on 2 pages globally compared to this file with 0 
✓ Target file is in use on 1 local pages compared to this file with 0 
✓ File uploaded in 2012, target in 2007 
× The target has 1 dead links and this page has 0, please review or replace source links on the target page before deleting
× May need merging as the target is missing 1 categories that are on this page Category:Defense.gov news media for February 2007 

2
<- File:LCAC delivers trucks (4298463558).jpg
-> File:US Navy 100122-M-8605C-004 Marines unload vehicles and supplies from a landing craft air cushioned onto a Haitian beach.jpg 
✓ File uploaded in 2016, target in 2010 
✓ No dead source links on the target page or this page 
✓ The target has 5 more categories 
× May need merging as the target is missing 1 categories that are on this page Category:22nd Marine Expeditionary Unit 

3
<- File:US Navy 100130-N-7917R-027 Chief Navy Diver Michael Hajduk observes divers assigned to the Port Operations Dive Locker at Naval Station Guantanamo Bay, Cuba, replace a buoy.jpg
-> File:Navy divers check buoys DVIDS248108.jpg 
✓ Target file is in use on 1 local pages compared to this file with 0 
✓ No dead source links on the target page or this page 
× File uploaded in 2010, target in 2015
× May need merging as the target is missing 1 categories that are on this page Category:United States Navy Divers 

4
<- File:'Earth Movers' remove remnants of war DVIDS163255.jpg
-> File:Flickr - The U.S. Army - Removing barriers.jpg 
✓ File uploaded in 2015, target in 2010 
✓ No dead source links on the target page or this page 
✓ The target has 2 more categories 

5
<- File:The 21st and 13th Secretary of Defense, Donald H. Rumsfeld, and the 15th Chairman of the Joint Chiefs of Staff, retired Gen Richard Myers, review the General's legacy board after it was unveiled in the Pentagon 070424-F-VO565-012.jpg
-> File:Defense.gov photo essay 070424-F-0193C-012.jpg 
✓ Target file is in use on 1 local pages compared to this file with 0 
✓ File uploaded in 2013, target in 2012 
× The target has 2 dead links and this page has 0, please review or replace source links on the target page before deleting
× May need merging as the target is missing 1 categories that are on this page Category:Interior of The Pentagon 

6
<- File:Looking south from Dante's View.jpg
-> File:Dantes View 1.jpg 
✓ Target file is in use on 4 pages globally compared to this file with 0 
✓ File uploaded in 2015, target in 2006 
✓ No dead source links on the target page or this page 
× Consider reversing or renaming as the target filename looks short 

7
<- File:EA-6B Prowler being refueled over Afghanistan 2011.jpg
-> File:Air Refueling Mission 110508-F-RH591-373.jpg 
✓ This image is smaller than the target 
✓ This page has 1 dead links and the target has none 
× File is in use on 1 Commons pages 
× File uploaded in 2012, target in 2016
× May need merging as the target is missing 3 categories that are on this page Category:Aerial refueling by KC-135 Stratotanker, Category:Grumman EA-6 Prowler in flight, Category:Aerial refueling as seen from tanker 

8
<- File:Ssc2006-21a.jpg
-> File:Chaos at the Heart of Orion.jpg 
✓ Target file is in use on 1 pages globally compared to this file with 1 
✓ The target has 1 more categories 
× The target has 2 dead links and this page has 4, please review or replace source links on the target page before deleting
× WARNING This file is in use on 1 global pages, please review the list 
× File uploaded in 2006, target in 2011
× May need merging as the target is missing 1 categories that are on this page Category:Spitzer space telescope (NASA images)


I would appreciate suggestions of better processes, like template enhancements to support this automation, thoughts on how this might work with other collections, or alternative factors to automatically measure, so long as they are realistic! It's much better to raise changes now before I invest more time in getting the script finished or set Faebot loose on the real files. Thanks :-)

  • We want to pick the best quality JPG.
  • We want to pick the Commons URL that causes minimal disruption to other projects, etc.
The problem with the above proposed criteria is that it may pick the best Commons URL but the worst image.
In terms of file quality there are two aspects: the image and the embedded metadata (which can have a bearing on how the image is rendered as we shall see). While quality is subjective, there are three proxies we can use: image display size in pixels, image file size in bytes and also a bytes per pixel value that combines these. In my experience first prioritising the larger file size can generally pick the better image and will usually also pick the image that has larger display size too. Where it doesn't, it is likely to be due to compression settings or the addition of extra metadata or embedded thumbnails in one image. An image compressed to have 2/3 of the bytes or 1/2 the bytes, say, may appear worse than an image simply 10% downsized or has had a few pixels cropped off. For large out-of-camera JPGs, a little downsizing might not be too bad whereas a heavy JPG compression could ruin it. NASA are notorious for hosting large JPGs with horrendously high compression levels. Not sure how best to balance all these attributes but one could pick the larger filesize first and then perhaps flag any that are dimensionally smaller as needing further scrutiny. Where two images are identical in dimensions, the larger file is almost certainly the one to keep. A rare exception might be where a photographer has applied some noise reduction and (provided they haven't been too extreme) this may result in both a higher quality file and a lower file size -- this is perhaps more likely to occur with amateur photos than ones created by press or military.
For metadata, we would like to keep the original data if possible as it can contain some historically and legally very useful information. You can view the meta data with Jeffrey's Image Metadata Viewer. Here the "duplicate" has some great metadata:
  • The camera used and settings on the camera and the date-time the photo was taken.
  • The image software used to prepare the photo (Adobe Photoshop CS Macintosh) and some settings for that too.
  • The photographer's "position" ("DoD Photographer"), name ("Helene C. Stikkel"), a title and description field
  • IPTC information which is often used by the press
  • The colourspace and profile to be used for displaying the image, in this case "Adobe RGB".
In contrast, the "target" has no camera details, no author/title information, no IPTC data, and evidence that additional software (Adobe Photoshop CS2 Windows) has been used to alter the image. The most notable change is that the colour profile is now "sRGB". If you compare the two images, you will see that the "target" image is much lower saturation. This is because whoever Photoshopped this JPG screwed up. If they'd done it correctly, then could have converted from AdobeRGB to sRGB without you being able to see the difference unless you looked very carefully on a high-end monitor. They didn't and the "target" image is wrong -- it is too dull.
I note that the source URL for the "duplicate" no longer works. It seems that [6] has moved to [7]. The source URL for the "target" doesn't even resolve the server name.
A further complication can be that images at a given Commons URL can have several versions and so may no longer be the same JPG as was first uploaded nor may it correspond to the "source" currently given for the file description. The JPG might even have been manipulated by a Commons user.
Wrt choosing the best URL, I think the usage (and secondarily filename) are perhaps all that matters. These are the things that affect and disrupt people. In contrast the categories, descriptions and source details can be patched up. All things being equal, such as a file not used anywhere, it would be easier to pick the one with the better JPG than to pick the one with better categories or links, as the textual inadequacies of a file description page can be easier to fix. I don't think upload date or link rot is likely to be strongly correlated with images to keep.
The TL;DR summary is that I think the tool should pick the weaker Commons URL to tag as "duplicate" but then advise the admin to transfer the better JPG over to this URL if that is not also the same. The best JPG should typically be chosen prioritising file size rather than image dimensions size, but additional warning/check required should that not also be the image with the larger dimensions. The source data may need fixed up if the JPG is transferred over. The choice of best URL is more about usage than about the text/links/categories. -- Colin (talk) 17:10, 5 July 2017 (UTC)
  • Note that the file size can have been changed if some metadata have been added, therefore a jpg coming from a jpg (=loss of quality) but with additional metadatas can have a bigger file size. Exemple File:Iwo Jima Expeditionary Strike Group transits the Suez Canal DVIDS119027.jpg have a bigger file size with similar dimension size, but if it has additional metadatas, it is a fact, I'm not sure it have a better quality than File:US Navy 080923-N-4236E-085 USS Iwo Jima (LHD 7) transits the Suez Canal.jpg. Christian Ferrer (talk) 19:12, 5 July 2017 (UTC)
    • Christian those two files are identical wrt image quality. I downloaded both and opened them as two layers in Photoshop and set blend mode to "Difference" -> totally black. So the difference in file size may be due to metadata, thumbnails or aspects of the compression/encoding that aren't lossy (e.g. choosing progressive ordering, or removing duplicate tags). I haven't studied the metadata in detail but ironically the file with the slightly smaller size seems to have some more metadata and longer descriptions. Both contain a 5.5k thumbnail. Strange. One option to consider, rather than eliminating the duplicates is to recognise that the JPG files we have are the result of historical processes of capture, edit, preparation for publication that may fork and be worth preserving or cause little harm in preserving. If both image files point to each other to say "here is another similar copy of the same photo" then it might not always be best to delete one. -- Colin (talk) 21:40, 5 July 2017 (UTC)
    • Btw, it is possible to use "exiftool -all= filename.jpg" to remove all metadata from an image (not advisable prior to upload as it will also remove colourspace information which is needed so it displays accurately). Even doing this on the above two images shows a small filesize difference. For them to show no visual difference in Photoshop they must be compressed identically so I can't explain the small changes other than that perhaps different Photoshop versions were used and one was a bit sloppy about how it packages up the file contents. -- Colin (talk) 06:59, 6 July 2017 (UTC)

Using Wikipedia to reference other WMF projects and the dangers thereof

It has come to my attention that neither our articles List of online image archives and Stock photography mention Wikimedia Commons as an increasingly and much used source of images. Being 'free' to use it it impossible quantify use against the established commercial image archive use but my personal OR research suggest that WC has gained a significant market share in image distribution over resent years. My OR also indicates that WC is at a grave disadvantage. Newspaper and other publications are always quick and ready to credit images they use to AP, Getty, Alamy and all the other agencies they get their images from but seldom credit WC when they use ours (and you can check this yourselves). By 'explicitly' stating that WC (on the WP articles) is also a bona fide image library, both equal and very often exceeds by many magnitudes smaller commercial online archives mentioned on List of online image archives , publishes may no-longer feel shame in disclosing that they sauce the image from this cowboy outfit (as the photo desk editors that use WC images think of WC as being). Thus, many WC up-loader are not being credited as of now. In the long run, this has potentialy serious implications if we don't do something about it now. Carol Highsmith tried to sue Getty Images when they billed her for using a photograph that she herself donated free & PD to the Library of Congress. [8] Ah! Getty replied (paraphrasing): As you have made it PD, we are free to distribute it and charge every users of your image' including you. So please put your cheque in the post to us so as not to incur further litigation costs. Have a nice day... Where or where does that leave or sons and daughters after we have shrugged of our mortal coil and can not speak from beyond the grave? They will not be able to use any of our images if a commercial company declares that they claim 'distribution rights' and threaten litigation to our currently and properly licensed WC images. These big commercial libraries have proven that they can afford to buy the best justice that their money can buy.P.g.champion (talk) 16:13, 5 July 2017 (UTC)

I agree that List of online image archives and Stock photography should mention Commons. As for other archives using Commons images or even distributing them for fee - the only thing we can do is to check if they follow attribution directives. I would be surprised if Stock photography archives were charging people for images that are labeled and require attribution in form "Your name / Wikimedia Commons / CC-BY-SA-4.0". If they do than it is OK if not than they are breaking the copyright requirements and we can complain. --Jarekt (talk) 17:56, 5 July 2017 (UTC)
The Carol Highsmith example above is one of many arguments for offering (for example) a CC-BY license rather than donating your images to the public domain. - Jmabel ! talk 19:52, 5 July 2017 (UTC)
Yes. I didn't want to add that point as a distraction but as this has now been proven to be true in practice, it adds weight to the importance of using CC rather PD. So thank you for bring it up. It is (as we all acknowledge here), not about profit but about making our images 'free' to all, for all time and into perpetuity. P.S. List of online image archives now shows (within the last hour or so) Wikimedia Commons - with a archive of 40,000,000. Obviously, I now have a long long night ahead of me, checking that figure out. 1, 2, 3, 4,. Gosh. when I get up to ten I will have run out of fingers! P.g.champion (talk) 22:11, 5 July 2017 (UTC)

Some bots may break in August

Tracked in Phabricator
Task T124742

Krinkle posted at message to several mailing lists that some of you may want to read. It begins like this:

TL;DR: In April 2017, the jQuery library in MediaWiki was upgraded from 1.x to 3.x (the current stable version), with the jQuery Migrate plugin enabled to ease migration. We temporarily still load jQuery 1.x on Wikimedia wikis. Read about the API changes at https://jquery.com/upgrade-guide/3.0/

The full message can be read here: https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2017-June/001617.html

Note that this is completely unrelated to mw:Contributors/Projects/Accessible editing buttons, which will mostly break non-bot scripts and gadgets in August. Whatamidoing (WMF) (talk) 19:57, 5 July 2017 (UTC)

July 06

Incorrect advice at COM:SD

Commons:Deletion requests/Speedy deletion advises: "If you uploaded identical images using wrong or mistyped names, tag the incorrectly named files with {{badname|File:Bettername.jpg}}."

That is not correct advice. If you use {{Bad Name}} on a file you will get a warning that that template is only to be used on categories. Mark Schierbecker (talk) 22:15, 1 July 2017 (UTC)

This sentence should be removed as obsolete. Ruslik (talk) 18:09, 2 July 2017 (UTC)
Might be better to replace the {{Bad Name}} in the instructions with {{Duplicate}}? --El Grafo (talk) 09:55, 3 July 2017 (UTC)
{{duplicate}} is mentioned in the point immediately above the one in question, so that would be a bit of – what's the word – duplication! It would probably be better to point out that renaming does not require deletion, which seems to be a common misconception among newcomers.
The whole page could really use a lot of copyediting, but unfortunately it was fully protected four years ago following one instance of vandalism in five years (which semiprotection would have been sufficient to prevent). —LX (talk, contribs) 15:13, 3 July 2017 (UTC)
The page has been unprotected at my request, and I've made some changes, including removing the point in question. —LX (talk, contribs) 09:49, 4 July 2017 (UTC)
Thanks!Mark Schierbecker (talk) 00:47, 7 July 2017 (UTC)

July 02

Non sense personal categories

Hi. Please, can somebody look at this user Visaswises, that create a lot of personal non-sense categories (like "Visaswises Nature reserve NameLocation") how you can see here, and other absurd categories. Thank you. Best regards. --DenghiùComm (talk) 08:24, 4 July 2017 (UTC)

They are as follows:
There is no structure to them, most could be under:
  • Category Category:Visaswises not found
They should comply with COM:USER#Categories.   — Jeff G. ツ 16:32, 4 July 2017 (UTC)
thanks for pinging the user. not much point in collaborating on VP without them. Slowking4 § Sander.v.Ginkel's revenge 19:46, 4 July 2017 (UTC)
Not one of the critizisers did ever make an effort to talk to me before intervening, all of them thought from the start, that they have the abilitiy and the right to judge. Even you, DenghiùComm, do not understand what I am doing and you made no attempt to understand it. Shooting before asking.

I behaved according to that, what Wiki promised to me. There seem to be a lot of people missunderstanding Wiki. Well, I' m out, it is not worth fighting. Visaswises (talk) 22:20, 6 July 2017 (UTC)

July 05

Categorization Fort 44 "Tonie" (Krakow)

I've found a lot of pictures of Fort 44 "Tonie" in Krakow, Poland, categorized as Syberia, which is a popular video game by Benoît Sokal. I put them in the correct category Fort pancerny główny 44 "Tonie". These picture were uploaded from Panoramio and had the following tags: Kraków, twierdza kraków (Krakow fortress), fort 44 tonie (the name of the fort itself), syberia, syberyjski. The last two are intriguing: I have discovered there are some places called Syberia in Poland, but none of these is near Krakow fortress. Why those pictures had syberia and syberyjski tags?--Carnby (talk) 09:38, 6 July 2017 (UTC)

Some updates about Recent Changes pages

Hello!

As you may already know, the Collaboration team has created a Beta feature. This feature is on your wiki since few months: "⧼eri-rcfilters-beta-label⧽". You can activate it in your Beta preferences.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked. It adds new features that ease vandalism tracking and support of newcomers:

  • Filtering - filter recent changes with easy-to-use and powerful filters combinations.
  • Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.

You can know more about this project by visiting the quick tour help page.

What's new?

Since the release, we have fixed small bugs and improved the interface. We have also released a way to bookmark your favorite configurations of filters.

We plan to add more new features! The full list is on this Phabricator page (in English) but here are the most important ones:

  • Filters for Namespaces and tagged edits and, later, filters for Categories and Usernames; they will help you to patrol specific changes more accurately
  • Redesign navigation by using an improved time selector and better integrated navigation options
  • Add live updates
  • Have a more clear interface by putting community-defined 'related links' into a collapsible panel

This last change is about links displayed on top of the RecentChanges (see how they look like on your wiki). We do that change because we have discovered that those links are not that much used. Also, they sometimes take a lot of space on small screens. To help people to focus on recent changes patrolling, we will hide those links, with an option to show them. We have created some examples to show you how it will look like. If you like to see those links all the time, you will have to click on the link to show them and they will remain open. We welcome your feedback about this change.

Most of this information was already introduced in the Collaboration monthly newsletter. Please subscribe to get regular updates!

You can ping me if you have questions.

All the best, Trizek (WMF) (talk) 10:27, 6 July 2017 (UTC)

July 07

Using sample URLs for Commons templates to find HTTP->HTTPS redirects

On the page Category:Museum database templates, there is an "Additional information" option at the top of the page that displays a list of information about many museum database templates. In the list, the information for each template includes among other things the museum that the template is for, the name of the template, and, somewhat usefully, a sample URL for the template. Something that I did was to copy sets of the sample URLs into the form for this HTTP response checker. Among other things, the response checker can be used to detect if, for example, an HTTP URL redirects to an HTTPS URL. For a number of the museum templates, such as {{KMMonline}}, it was indeed the case where the template used an HTTP URL that redirected to an HTTPS URL. For those templates, I edited the templates to generate HTTPS links instead of HTTP links. The purpose of this editing was to provide increased privacy and security for Commons users without requiring them to install additional software or to otherwise do things differently. This technique might be useful for editors who are interested in searching for broken URLs or HTTP URLs that can be changed to use HTTPS (assuming that there are no copyright issues with regard to copying multiple sample URLs from Commons into an HTTP response checking page.) --Gazebo (talk) 06:54, 8 July 2017 (UTC)

July 09

Wake up!

Hi, I imported valued files in the public domain (Commons:Deletion requests/Files in Category:Daniel Cande), and some were license reviewed. Then someone comes and decides to delete them against the majority of opinions. If these files were copied from Flickr, nobody would question them, let alone delete them. Why having a different standard because the files come from Gallica? And nobody seems to care about it... I know it is the summer holiday, but does anyone value our process? Regards, Yann (talk) 16:55, 5 July 2017 (UTC)

I very much hope there's been a misjudgement in the decision. When an image is under license X and it is uploaded under license X on Commons, license review should state that immediately and further license changes at source should not matter. If this is not respected, I risk to lose more than 1K of images and I will be only one of the hundreds of uploaders who painstakingly had won a donation agreement from various sources only to see their work vanished by admins' confusion and uber-precaution. //  Gikü  said  done  Wednesday, 5 July 2017 18:38 (UTC)
do not know why you are surprised by the "skepticism" which is really cynicism. do not ask a question, if you should not trust a closing commons admin. if you think it is an improper close take it to DRV. Slowking4 § Sander.v.Ginkel's revenge 14:10, 8 July 2017 (UTC)
I thought we could have a constructive discussion, and that's why I nominated my own files for deletion. I trusted Commons admins to take a meaningful decision. But I was wrong. We have had an interesting discussion, which demonstrated that there is no reason to delete them. But then Jcb deleted the files without understanding what this was about. I am very deceived by people taking foolish arbitrary decision without any regards for the community, and the work of others. Regards, Yann (talk) 14:56, 8 July 2017 (UTC)

So the owner of a website gave me permission to upload his images to Wikimedia Commons, but the license of his website says otherwise.

So recently I’ve been contacting various Oriental cash coin website owners and the authors of prominent books on Ancient Oriental coinages or just general owners of coins. With some people like Sema from Art-Hanoi (known on Wikimedia Commons as @Pyvanet: ) the response was less than excited as he claimed that W.M. Commons kept deleting his uploads unjustly which I do agree with as I had made the argument that the Socialist Republic of Viet Nam has only copyright over currency produced by either the Democratic Republic of Viet Nam (North-Vietnam), or the Republic of South-Viet Nam (Viet Cong Terrorists’ central organisation), and not the Republic of Viet Nam which neither predecessor state of the S.R. of Viet Nam recognised, though at the time of those discussions I was more interested in reading about those subjects not writing, I was already busy fighting serial vandals from India with changing IP addresses on other parts of Wikipedia and only read about Vietnamese currencies. But that’s a topic for another discussion. Gary from Primal Trek seems to have “disappeared” since 2016 assuming that he’s either retired or has died, but then I still contacted what can basically be called “the mother of al Oriental cash & charms websites on the internet” Charm.ru, specifically Mr. Vladimir A. Belyaev. Though I’ve used the work of all of the aforementioned people extensively on Wikipedia and I’ve cited them to the point that I’ve used all the parts of their respective websites that I can possibly use on Wikipedia (don’t worry I have absolutely no affiliation with any of them, I just want their resources to be used for the accumulation of information until none is more possible), since I’ve written and linked them all (Nd many, many more (nay, not a pun to Gary Ashkenazi’s “manymore ” handle), but “the last resource” (basically) I couldn’t/can’t use from their sites are their images, these are protected so I messaged them, as I look browsing my spam folder I had found that Mr. Belyaev had contacted me with some positive news for a change, well, kind of…

E-mail traffic between myself and Mr. V.A. Belyaev

The e-mail I sent to Mr. Belyaev: 📧 

“On Fri, 07 Jul 2017 05:47:40 +0300
  [sender (that’s me) censored.] wrote:
> Dear Mr. Belyaev,
> 
> I would like to request of you to upload pictures of all the Oriental coins 
>and charms you have (and/or know of) to Wikimedia Commons to not only improve 
>the current Wikipedia articles on Asian coins but to preserve those images 
>for future generations and illustrate those coins for the curious and 
>interested.
> 
> Yours sincerely,
> Mr. [Censored]
> 
> Sent from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱.
> “

Mr. Belyaev’s response: 📧 

“Dear Mr. [Censored]

Thank you for your letter.
Your thoughts are quite useful and I appreciate it.
However, all my free and non-free time I devoting to support and developing of 
my project zeno.ru, where are uploaded dozens thousands of Asian coins and 
charms.
So I simply have no time to upload pieces to Wikimedia Commons.
If somebody will do it (with reference to the source), I will highly 
appreciate it.

With best regards,
Vladimir”

As someone who has written and maintained websites in the past I can perfectly understand the effort it takes and his reaction, and I have to note that his latest website has this on the bottom:

“Photo Sharing Gallery by PhotoPost
Copyright © 2007 All Enthusiast, Inc.


Copyright 2002-2017 charm.ru
No part or portion of this page, text(s), image(s) or code(s) may be copied, reproduced, published or distributed by whatever way in any medium without the expressed written permission of the copyright holder, unless you are the owner of the uploaded image or you use the above mentioned matter for personal educational or scientific purposes with no intention of publishing it by whatever way under your or any other name.”

What could happen are a few suggestions I have regarding this issue...

Sent from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱.

My case as to why we should investigate the possibilities regarding ALL of the aforementioned. In respect of what we could do to preserve knowledge.

Currently I am quite disappointed in the current state of affairs regarding the number of coins on Wikimedia Commons, for someone interested in finding free information on them Wikimedia Commons unfortunately only offers limited options. Though I’ve uploaded years of pictures of a variety of subjects and many of those pictures have been internationally used on Wikipedia I’ve only uploaded a very limited number of numismatic images to Wikimedia Commons, though I plan on uploading all (well... Ehhh... Well... Yeah... Most...) of the non-copyrighted items I own to Wikimedia Commons E.G. there are over/around 5000 different varieties of the Korean Sangpyeong Tongbo’’coin but currently there are only 2 different images of this coin on Wikimedia Commons, I personally own 3 varieties (soon 13 as of a recent eBay purchase) which would still leave more than/or around 4987 missing “versions” of this coin. After I return back to my village in a few months I'll start a project to upload as much good quality pictures of my non-copyrighted items as possible (maybe after upload ALL of my other images to Wikimedia Commons first as I seemed to have (possibly) missed 2 batches of travel pictures, but I’m wandering off), but so far my collection(s) is/are only as limited as my wallet, I see good quality items coming and going around eBay every day that would be able to serve a great educational purpose on Wikipedia. My (personal) first, and foremost assignment on this issue is to upload what I have, or make (free) images of numismatic items from others that I know.

At first I started a banknotes collection, that grew to a Coins & Banknotes Collection, which grew into an Art Collection after various exonumia like vouchers, gift cards, VVV cadeaubonnen, paper promises of future discounts after a fire 🔥 broke out at my village’s shopping centre, and then it grew to become an “Art & Culture collection” after I received fake money for children to play 🎭 with, token coins both historical and modern, I created special “Nose banknotes” regarding what happened to the neighbour in the Son of the Mask/The Mask 2, or even other things like basketball tickets for GasTerra Flames, Rocks’ Vijfjes, Etc. Eventually growing to become “a/MY History collection” including not only historical documents, and ancient works, but also a variety of items too much to name. My plan is to upload as much of these as I am legally allowed, but again I can only add to Wikimedia Commons what I own and from what I could tell more people would rather share high quality images of coins on Flickr than here, this is most evident by the fact that A LOT of images in the “Coins of the Qing dynasty” category were (re-)uploaded by a FlickrUploadBot and not self-published works from users. Though I plan on greatly expanding Wikimedia Commons’ numismatics (aand EVERYTHING even remotely related or not related at all but I'll fictionally relate them to be related-relates-related), I simply do not currently have the resources to expand these categories into completion. Some coins are simply too expensive for me, others lie in musea, and there are many other reasons I could name why my (near) future contributions as great as I’ll try to make them won’t be able to be as complete as the resources already present on Mr. Belyaev’s site(s).

Another problem I (personally) have is that the coins I liked (like my Bao Dai Thong Bao, some “Manchurian Proviences” (sic) silver coins from the Xuan Tong Emperor, a Thanh Thai Thong Bao, Sangpyông Tongbo, Etc.) I held excessively in my (sweaty) hands looking at them, a French Indo-Chinese 2 Sapèque I hung on a golden necklace, Qing Dynasty silver coins I kept in my wallet next to Euro coins as a child and teenager causing these coins that once were new to look old, stale, and used... Things I now greatly regret, and when I’ll upload pictures of them they won’t only look worse in real life, I can only take pictures on a Microsoft Lumia 950 XL and not a standalone camera as I can’t afford one further causing them to not really be “the best quality”, but I’ll still upload them in the future reference. Though in the past I liked holding them non-stop 🤚🏻 in my hands ✋🏻 without a case, I now use plastic cases to preserve them so my newer coins will have a better quality, compared to the coins found on Charm.ru I would suggest picking those as they are always “the best quality possible”. Meanwhile Mr. Belyaev has dozens of thousands of images of (often) even rare (and expensive) coins that I can’t afford, or can’t find.

I'm afraid that one day the site will go down for any reason and although Charm.ru has operated between (I think) 1996 until 2003, and Zeno.ru still operates now, something horrible can happen like the death of Mr. Belyaev that could cause the precious historical information to be lost to future generations (especially since internet archives only preserve the texts, and links while often not archiving images needed for these illustrations).

It's not uncommon for me to want to add an illustrative image to Wikipedia but then don't find any results in Wikimedia Commons, Wikipedia is an encyclopedia and for encyclopedias images are really important to illustrate something. An example I can name of is “Western Xia coinage” where not a single image is used to represent Tangut script, or “Jin Dynasty coinage” which doesn't even have a single image. I don’t own any of those coins, nor can I afford one on eBay, so all I can really do is beg others to upload them to Wikimedia’s W.M. Commons/WM Commons. For this reason Belyaev’s work is really important, and we should explore all possibilities regarding the above.

Sent from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱.

Wikinedia Commons is made by people who passionately share their collections online free to share, and people like Mr. Belyaev simply have more to share.

my suggestions 🎫

Based on the Wikipedia article “Ancient Chinese coinage” where the honourable Mr. David Hartill (known on Wikipedia as DavidHartill) had personally contacted the Foundation and give “a ticket” 🎫 to use his copyrighted “Cast Chinese coins” for the article, to this end the Foundation contacted the honourable Mr. Hartill.

What I suggest is that someone from the Wikimedia Foundation (or just someone responsible for fetching “tickets”) contact Mr. Belyaev and explain him in detail what uploading images to Wikimedia Commons entails and what it means.

Mr. Belyaev can be contacted here on Charm.ru (by simply “clicking” on his name) or here on Zeno.ru (on the top, the “postman” e’mail-address.-).

After the “ticket” has been “fetched” I suggest the following. 🎫

Someone with the programming knowledge and authority writes a bot specifically to fetch images from Charm.ru, and Zeno.ru as there are about 200,000 different images of coins, the bot should also be able to add descriptions (if Mr. Belyaev and/or the other current copyright holders allow) to maximise the educational value of the images.

The bot must always link to page of origin, and name the original uploader, not unlike what the bot that uploads Flickr images does now.

Sent from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱.

I really hope that people will take these ideas into consideration. If someone would please contact Mr. Belyaev I’d be very happy. 😸

--1.55.183.244 07:02, 9 July 2017 (UTC)

The ticket 🎫 I'm referring to is the Commons:OTRS. --1.55.183.244 07:09, 9 July 2017 (UTC)
The aforementioned images by Mr. Belyaev (and friends) are particularly important for both Silk Road Numismatics & Chinese Character-Sphere Numismatics. --1.55.183.244 07:14, 9 July 2017 (UTC)

The copyright related discussions of the above I have enquired at the open-ticket 🎫 board, I would like to request that replies focus on the possibilities of creating a bot for the above websites if permission is obtained. --1.55.183.244 14:19, 9 July 2017 (UTC)

Problem with videos - thumbnail generator does not work properly

I've noticed that a thumbnail generation for videos in all Wikipedias and Commons is not working anymore. Instead of generation of the required snapshot from the selected second of video in thumbtime option, the engine ignores it and just generates the frame from the middle of the video, which is not suitable for illustration of articles in most cases. Only preview thumbnails from videos that has been generated 2 weeks before or earlier are remained the same, however if I change the size of video or select another thunbtime which has not been generated yet, the engine ignores thumbtime value and generates a default image, which is wrong. How to solve this problem and replace wrong thumbnail images with proper ones from selected second of video? Xenotron (talk) 08:54, 9 July 2017 (UTC)

phab:T169445--Steinsplitter (talk) 09:05, 9 July 2017 (UTC)
(Edit conflict) see T169445 and wait... --Pristurus (talk) 18:44, 9 July 2017 (UTC)

July 10

Tech News: 2017-28

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • There are sometimes links to pages about the same thing on other Wikimedia projects. A Wikipedia article about Berlin can link to the Wikivoyage guide or Wiktionary entry about Berlin. You can now see when that page has a badge. A badge could be the star that shows that an article is a featured article. [9]

Changes this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 July. It will be on non-Wikipedia wikis and some Wikipedias from 12 July. It will be on all wikis from 13 July (calendar).

Meetings

  • You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 11 July at 19:00 (UTC). See how to join.

Future changes

  • Mobile users will be able to edit Wikipedia without JavaScript. This will make it possible to edit the wikis from older mobile phones. This will probably happen on 18 July for most wikis. [10]
  • We will not use Tidy on Wikimedia wikis in the future. It will be replaced by June 2018. It could be earlier. Editors will need to fix pages that could break. You can read the simplified instructions for editors.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:07, 10 July 2017 (UTC)

July 11

Template:Object photo appears to be incorrectly categorizing a few files

Would someone please take a look at the following files, which are all in Category:Paintings by François Boucher by name:

These files should all be in Category:Diana after the Bath - Boucher (Louvre INV 2712), but instead they are in the parent categories of that category. Could someone take a look and see if you can figure out what's going on here? Thanks. --Auntof6 (talk) 03:26, 10 July 2017 (UTC)

@Auntof6: fixed, the category page inclusion added the categories as well, not only the description. The other files in the category did not use the same template and so did not have the same problem. (I did not even know we have templates like {{Object photo}}.) MKFI (talk) 08:03, 11 July 2017 (UTC)
@MKFI: Thanks very much! --Auntof6 (talk) 09:09, 11 July 2017 (UTC)

Strategy discussion, cycle 3. Let's discuss about a new challenge

Hi! It's the second week of our Cycle 3 discussion, and there's a new challenge: How could we capture the sum of all knowledge when much of it cannot be verified in traditional ways? You can suggest solutions here. You can also read a summary of discussions that took place in the past week. SGrabarczuk (WMF) (talk) 12:27, 11 July 2017 (UTC)

Commoners portraits

I learned about nice tradition in Polish Wikipedia: users gallery which may contain some humorous connotations. I think such descriptions are great way to keep history of project as well as a chance for newbies to learn about old timers. Unfortunately Commons was created long time ago and many prominent contributors are covered by fog of time. --EugeneZelenko (talk) 14:05, 11 July 2017 (UTC)

Images of a sex shop in Amsterdam.

I have a few images of some rather odd sex toys in a sex shop in Amsterdam that I wish to use on Vietnamese Wikipedia, but I'm not sure if I can upload it here or not? 🤔 Does this go against policy? I've looked everywhere but couldn't find it. 🔎🔍 --1.55.183.244 15:09, 11 July 2017 (UTC)

No problem, if these are your photos. Category:Sex toys exists. — Speravir – 16:45, 11 July 2017 (UTC)

Request to add list of images to a category

Hi all

@Mike Peel: has been extremely kind in helping me to find images from Biosphere Reserves which have been uploaded as part of WLE this year. We now have a list of over 3000 images on a page that we need adding to Category:Images from Wiki Loves Earth Biosphere Reserves 2017, I feel like this probably needs some kind of bot or other automated system to do. Could someone please help? Maybe @Magioladitis: ?

Many thanks

--John Cummings (talk) 15:19, 11 July 2017 (UTC)

Update: A bot request has been made to make this happen. --John Cummings (talk) 21:49, 11 July 2017 (UTC)

Not sure what to do about this...

...but it doesn't look right. https://commons.wikimedia.org/wiki/Special:Contributions/Trp.CDE — Preceding unsigned comment added by Avery Jensen (talk • contribs) 21:29, 11 July 2017 (UTC)

Indeed. Handled on Commons now, but the user was also active on two other projects. --Didym (talk) 22:01, 11 July 2017 (UTC)
Thx. Avery Jensen (talk) 22:17, 11 July 2017 (UTC)

بررسی اصلاحات

در صفحه ی ایجاد شده چند مورد تخلف نقض قوانین داشتم که اصلاح شدند ، صفحه ی " حذف سریع " چه موقعی از روی صفحه پاک میشود ؟ — Preceding unsigned comment added by Tamashaa (talk • contribs) 07:36, 11 July 2017 (UTC)

@Tamashaa: → Commons:قهوه‌خانه?
Everyone else: Forgive the Google translation:
"On the page that I created, there were a few violations of the rules that were corrected, the page 'How to delete' when removed from the page?"
I believe this is referring to the issue raised at: User talk:Tamashaa#File tagging File:Tamasha web.png. Does someone want to respond there? This query may actually be possible to "respond to" without any further discussion, if you see what the user is talking about. - dcljr (talk) 08:37, 12 July 2017 (UTC)
Actually, nevermind. This VP post was posted before the talk-page comment I linked to. (BTW, the phrase "حذف سریع" in quotes in the original post translates on its own to "fast removal" — perhaps referring to a "speedy deletion" template?) - dcljr (talk) 08:52, 12 July 2017 (UTC)
Right, I tagged those files after seeing this. I couldn't quite make sense of the above using Google Translate either, and I was hoping a Farsi speaker would respond instead, but looking at fa:User talk:Tamashaa, it seems an earlier version of Tamashaa's user page on that project was deleted shortly before the message above was posted here, so it's probably about that rather than anything related to Commons. —LX (talk, contribs) 09:08, 12 July 2017 (UTC)

Self promo

Who is this? And is this not self promotion?Smiley.toerist (talk) 10:22, 7 July 2017 (UTC)

Well, if you think the description is promotional, you can edit it. Or if you consider the whole image not to be realistically useful for an educational purpose, you can nominate it für deletion as being out of COM:SCOPE. In both cases IMHO not really a topic for the village pump. --Rudolph Buch (talk) 10:45, 7 July 2017 (UTC)

I suppose there is no abundance of businesspeople of Kinshasa at Commons, so very much in scope. The description should be improved, though. --LPfi (talk) 21:00, 7 July 2017 (UTC)

  • The up loader’s user name goes against policy. Note: both hands are in view and are so are not operating the smart phone, so up-loader is almost certainly not Hugo Komba Homme himself. So I don't think we even need to get into whether it this image is self-promotional (this is not WP so different guidelines apply here) – the image licence though, is gravely suspect. Suggest we put it up for deletion due to total lack of provenance. So, a thank-you to User:Smiley.toerist for questioning it.P.g.champion (talk) 16:10, 9 July 2017 (UTC)
    • P.g.champion, you maybe mean Commons:Username policy, that link was for the policy of a different project. I can't quite see how a person having their full name as a username is against policy though, can you explain more? seb26 (talk) 17:29, 9 July 2017 (UTC)
    • The image seems intended for promotional use by HK. It could have been taken with a timer, with somebody else pushing the trigger or as a work for hire, but I think demanding proof about such details, when allowing publishing on Commons should have been an intended use case when making a contract, is nitpicking. --LPfi (talk) 16:21, 13 July 2017 (UTC)

Personal documents hosted in Commons for Wikipedia article development?

Thanks @Daphne Lantier and Maile66: for starting this conversation with me.

Wikipedias of all languages have perpetual problems with people wanting to share personal information. Here are some examples of issues which continually arise:

  • name corrections, either for spelling, name changes for marriage, name changes for any other reason
  • gender changes, as for individuals who were known by one gender and now are known by another
  • mundane job changes, as when Wikipedia reports that someone works for one organization but then they join another
  • marriages, as when Wikipedia reports that people are married, but then they get divorced, or marry someone else, or whatever
  • residency

There is currently no particular name for this class of information on Wikipedia. Lots of this appears in an "infobox", which is the box on the right side of the screen (desktop view) for biographies. This information typically also appears in the body of the article.

When information enters Wikipedia it comes from reliable sources. Wikipedia editors avoid doing original research to seek out this kind of information from primary sources. However, once this information gets into Wikipedia, then a sort of liability arises in which the subjects of biographies sometimes object to Wikipedia carrying outdated information. To correct this, many people seek to offer proof to correct Wikipedia.

At Commons:Deletion requests/File:Stewart and Constance Lake's marriage certificate.jpg I have someone's submitted proof of a marriage. The user submitted this primary source of information to advance discussion at en:Veronica Lake. Lake as a United States actress and celebrity. The document purports that she had a marriage after she left the public eye. This marriage was never published or the source of any media documentation. A Commons user requested that the document be deleted for being a hoax. There has never been a discussion on whether the document is or is not a hoax. I am not sure if Commons even should host such discussions. Currently, the marriage certificate is deleted.

There are a few issues here -

  1. I do not think anyone in Wikimedia projects wants to get involved in original research. However, it might be a cross-wiki concern if the public seeks to submit primary documents as evidence to change articles. Should the Commons community form an opinion on this?
  2. In this case, the user has a document which they want to share to update some fact in Wikipedia, in this case a marriage. Is it within Commons' scope to host such a document?
  3. In this case, some wiki community members have made the claim that the document is a hoax. This does not rise to the level of accusation, but instead, the argument was that the documents tell a very different story than other published sources and without extraordinary evidence and research, some people would feel challenged to accept the information in this document. In what ways should the Commons community issue opinions on whether documents of this sort are authentic?

At Commons:OTRS private ticket:2015121110001052, a user writes in requesting that the files be undeleted.

Could I get thoughts from others on what should happen next? Blue Rasberry (talk) 18:46, 7 July 2017 (UTC)

  • I think that where these have bearing on Wikipedia articles, they are probably within Commons' scope.
  • As for the specific document, though, if it is not a hoax then the copyright claim that is on it as a watermark is copyfraud. You can't copyright a marriage certificate. - Jmabel ! talk 19:09, 7 July 2017 (UTC)
Indeed the document itself, if blank of any infos should be {{PD-CAGov}} as it comes from the California Department of Public Health. Christian Ferrer (talk) 19:27, 7 July 2017 (UTC)
  • Technically, any file that's in use on Wikipedia is in scope for Commons, in the absence of copyright problems. Also, if it relates to a notable person I assume it would always be kept. However, I'm not sure that this is a great process to use. Commons has no way to determine if a particular file is a genuine copy. Some kind of process like OTRS could be used, where people can establish their identity (somehow) and provide the information while keeping the actual documents semi-confidential. This would probably be useful for all kinds of "personal correspondence" type information on Wikipedia. --ghouston (talk) 08:11, 8 July 2017 (UTC)
  • In scope. The educational value of primary sources can be assessed by their validity or notable non-validity (like the fake Hitler diaries). Consequently anyone uploading a public record like this would do well to include an explanation of sourcing which may be verifiable. Marriage certificates in the USA or UK are pretty easy to verify, someone should put the spadework into verification if they care about it. As for giving obituaries more credence than a marriage certificate, unlike registrar verified certificates which can be retrospectively checked, there is no review process and many obituaries will contain mistakes, propagated myths and hearsay. --Fæ (talk) 08:20, 8 July 2017 (UTC)
  • I'm not sure what procedures journalists use for verification. If they are interviewing somebody, I'd hope they are reasonably certain they are talking to the right person, and not somebody impersonating them. But it may be that such impersonation isn't something they encounter often enough that they need to bother making any formal checks (unlike on Wiki projects where the choice of user name isn't much guarantee of anything.) I'd also guess they just record what the person says without insisting on verification, e.g., if they obtain any information like educational or vocational history. The articles they write then become acceptable references for Wiki purposes. If there were trustworthy Wiki journalists who could go out and interview people, after verifying their identity, would that be any less reliable than something published in traditional media (which does of course make mistakes)? --ghouston (talk) 03:09, 9 July 2017 (UTC)
  • One thing that should be mentioned here, is a tip off in this uploader's claim. Please see Talk:Veronica_Lake#Notes_from_Stewart_Lake.2C_the_last_husband_of_Veronica_Lake. The person says his name is Lake, and that he is the reason she changed her name to Lake. He says they were together from 1955, and got married in 1971. Her career under the name Veronica Lake is well documented. 1941 Life magazine article she was known as Veronica Lake then. American Film Institute catalog of feature films is a database of the film industry, and lists back to her earliest movies when she originally used the name Constance Keane (her stepfather's name). It does not take OR to figure out she was known by the name Lake most of her life. Maile66 (talk) 11:59, 9 July 2017 (UTC)
Not sure why Pristurus deleted my post, but I'm adding it back. Maile66 (talk) 19:57, 9 July 2017 (UTC)
Sorry, my mistake. It happened unintentionally. --Pristurus (talk) 20:45, 9 July 2017 (UTC)
It is likely that they had an older tab open with their reply, as they accidentally deleted other comments made after the fact. I have attempted to fix this in my latest revision with this comment. seb26 (talk) 20:49, 9 July 2017 (UTC)
No harm, no foul. Thanks for explaining. Maile66 (talk) 22:07, 9 July 2017 (UTC)
  • @Bluerasberry: If the end result here is no clear directive, the above suggestion that this be fielded by OTRS seems like a good way to go. Whether or not any submission is a hoax, I'm sure Commons doesn't want to upload something that is. Anybody with a computer can create something that looks like an official document but isn't. The user above who suggests the uploader should include an explanation of sourcing which may be verifiable, seems reasonable. I don't see how it's your responsibility to figure that out. Especially since on Wikipedia the uploader has made threats of legal action. OTRS might be a better way to go. Maile66 (talk) 11:46, 11 July 2017 (UTC)
  • @Bluerasberry: Gaming the system, noticed because of my AIV work on Wikipedia. Posting this on the Commons VP thread for the record, and my Commons talk page so it's there indefinitely for my own reference. I just noticed on the Veronica Lake talk page how this went down, and I think some safeguards should be in place so it doesn't happen this way again. The original uploader got you to be the one to post to the talk page. In such a situation, the person who contacted you will not be reverted/blocked from that talk page. It falls on your posting, and you did nothing but respond to a request. That loophole needs to be changed so it doesn't happen again. Maile66 (talk) 12:10, 13 July 2017 (UTC)

July 08

How do I add images that appear in two categories to a third category?

Hi

We want to include images taken in Biosphere Reserves in the national Wiki Loves Earth competitions in the Wiki Loves Earth Biosphere Reserves competition.

Please can someone tell me how to copy any images that are in a subcategory of Category:Biosphere_reserves_by_country that are also in a subcategory of Category:Images_from_Wiki_Loves_Earth_2017 to Category:Images_from_Wiki_Loves_Earth_Biosphere_Reserves_2017.

Please note that Category:Images_from_Wiki_Loves_Earth_Biosphere_Reserves_2017 is already in Category:Images_from_Wiki_Loves_Earth_2017

There are likely 1000s so doing it manually isn't an option.

Many thanks

--John Cummings (talk) 14:24, 10 July 2017 (UTC)

If I knew such a tool, I would be so happy. --MB-one (talk) 11:28, 13 July 2017 (UTC)

On Wiktionary

Can someone create a {{On Wiktionary}} as a complement to {{On Wikipedia}} ? -- 65.94.42.131 05:06, 13 July 2017 (UTC)

Where do you want to use it? Ruslik (talk) 20:22, 13 July 2017 (UTC)

Template User:Fæ/IWM

Shouldn't this be in the template namespace (used more than 51,000 times)? @Fæ: for your information. --тнояsтеn ⇔ 05:41, 6 July 2017 (UTC)

Project specific ingestion templates don't have to be as there are no rules. The template is 4 years old and I would recommend others use standard templates. --Fæ (talk) 07:45, 6 July 2017 (UTC)
could you please modify the template to accept wikidata field ? Slowking4 § Sander.v.Ginkel's revenge 02:58, 8 July 2017 (UTC)
What do you mean with "ingestion templates"? --тнояsтеn ⇔ 07:55, 10 July 2017 (UTC)
@Thgoiter: It's how we describe a custom template created to replace the standard information template for batch upload projects. People often use these if the standard templates do not have fields that appear to match their source metadata. Over the years I have moved against this as it has built up a maintenance headache should we wish to standardize image pages, such as harmonizing with wikidata. See Category:Data ingestion layout templates for lots of examples. --Fæ (talk) 06:53, 15 July 2017 (UTC)
OK, ingestion didn't make sense to me here but I'm only EN-3 ;-) Aside from the question whether a custom template is useful or not, back to my starting point: is the user namespace the right place for a template that is used that widely? --тнояsтеn ⇔ 07:10, 15 July 2017 (UTC)
The answer is maybe not, however we are talking about a stable collection that has been here for several years. Unless this is a current material issue, there is more risk in shaking the tree for the sake of it, compared to admiring the tree and walking on. --Fæ (talk) 07:22, 15 July 2017 (UTC)

Purpose of Template:Custom license marker

What’s the intended purpose of template {{Custom license marker}}? (ping @Matma Rex). — Speravir – 21:39, 12 July 2017 (UTC)

@Speravir: Its utility is marginal, at best. It indicates that, while preparing to upload, the uploader chose from the Upload Wizard a license which was not one of the defaults. Multiply that marginal utility by 539091 transclusions, and you might have something. However, given the demise of the Upload Wizard's cat, this template could probably go off into that good night without significant loss. We would probably need a VPP to have the Upload Wizard stop using it and possibly related templates. It is also a security risk.   — Jeff G. ツ 22:40, 12 July 2017 (UTC)
“Utility marginal, at best” and “this template could probably go off into that good night without significant loss” are actually my thoughts, as well, and my intention for asking here. — Speravir – 22:55, 12 July 2017 (UTC)
UploadWizard actually inserts {{subst:Custom license marker added by UW}}. I agree it is silly. It's been here since forever though (phab:rSVN103557), and apparently was discussed back in the day on Commons:Village pump/Archive/2011/11#Multi-file selection and more for UploadWizard (I got this link from that template's description page). If you want it gone, please just file a Phab task and I'm sure Multimedia folks be happy to oblige (I mostly work on VE these days). Matma Rex (talk) 14:23, 13 July 2017 (UTC)
@Speravir and Matma Rex: Thanks, I raised a concern at phab:rSVN103557 as an initial step.   — Jeff G. ツ 15:50, 13 July 2017 (UTC)
Honestly, probably no one will ever see it there – we don't use Phabricator's Diffusion (diff viewer) much, it's just yet another mirror of the repositories; we mostly use Phabricator's Maniphest (task/bug tracker). And this is a change written by a person who hasn't been active for years (and doesn't even have an account on Phabricator). Just file a task, they get looked at. Matma Rex (talk) 17:22, 13 July 2017 (UTC)
(Edit conflict) @Jeff G. and Matma Rex: Thank you, both. So, the intention was fine, but no one seems to care about it anymore. (And I could have safely delete it in these cases I stumbled over it.) Because this is some kind of license review, it probably at least should have been mentioned in COM:LR and perhaps been added to {{LicenseReviewMenu}}. BTW, Jeff, internal search: file: hastemplate:"custom license marker". And also ping @NeilK, though his latest activity in all Wikimedia projects was here on Commons in January this year. — Speravir – 17:46, 13 July 2017 (UTC)
Proposal for removal of Custom License Marker from Upload Wizard
The Upload Wizard currently adds {{subst:Custom license marker added by UW}} to file description pages it helps create. This results in {{Custom license marker}} with time parameters filled in being added to those file description pages when substed. It was supposed to add those file description pages to dated subcats of Category:UW uploads using a custom license, but that never happened, so now there are ~543,034 files in Category:UW uploads using a custom license which no one has checked. This practice of template addition should cease, for reasons explained above.

Custom License Marker votes and discussion

July 13

Arabic translation of {{Delete}}

Help needed – could someone review this change? --jdx Re: 10:35, 15 July 2017 (UTC)

July 16

Should content pages consist of galleries only or also include File pages?

Historically, the count of "content pages" here at Commons (shown at Special:Statistics and accessible through API requests) has included only pages in the main namespace ("galleries") containing at least one wikilink (matching the classic definition of an "article" used on most Wikimedia wikis). The count of "uploaded files" has been a completely different thing (one that, admittedly, most people care about a lot more than the number of galleries).

Now, following a change I pointed out almost 2 weeks ago, the definition of "content pages" includes both galleries and File: pages containing at least one wikilink. This means the content-page count will increase (almost) as fast as files are uploaded (assuming they result in "File:" pages containing at least one wikilink, which I believe is true when the Upload Wizard is used). As a result, the content-page count has jumped to around 530,000 as I type this — an increase of around 300% since June 6th.

Unfortunately, this current count is almost completely meaningless, since it contains only qualifying (wikilinked) "File:" pages created after the settings change of June 6th. (Already-existing "File:" pages were not "retroactively" counted.)

To get a "meaningful" content-page count, we will need to have the entire wiki recounted from scratch — something that is being done periodically to every Wikipedia, Wiktionary, Wikiquote, Wikisource, Wikinews, Wikiversity, and Wikivoyage, but to my knowledge has never been done to Commons.

I stress that this will need to be done whether we accept the change that was made on June 6th or not. However, we need to decide which definition of "content pages" we want to go with before the recounting is done (since it will be a relatively [or maybe extremely] long and resource-intensive process).

Specifically, then, we need to decide between the following options:

  1. The count of "content pages" should include only galleries in the main namespace. (i.e., request a revert of the June 6th settings change and recount the wiki)
  2. The count of "content pages" should include both galleries and pages in the "File:" namespace. (i.e., accept the June 6th settings change and recount the wiki)

Some things to note about the two options:

  • The first option is how things have been done for several years, up to 6 June 2017. The current count under this scenario "should be" around 130,000 (based on the count before June 6th) and represent how many wikilinked galleries we have. Using this definition would have the debatable benefit of separating the count of galleries entirely from the count of uploaded files.
  • The second option is how things stand as of 6 June 2017, but as just explained above, the current count (around 530,000) is now a mixture of galleries and only-recently-created "File:" pages. It is impossible to know what the count "should be" under this scenario, but I'm guessing it's at least several million. (For comparison, the count of uploaded file is just shy of 40 million.) After recounting, using this definition would have the debatable benefit of eliminating "File:" pages lacking links to, say, uploader userpages and/or local pages explaining licensing terms.
  • It is (also) debatable whether the existence of links on "File:" pages (or even gallery pages, for that matter) is even a meaningful way of qualifying such pages as "content". Thus, we may want to consider switching to the "any" method of content-page counting (counting all pages in "content namespaces" rather than only those containing a wikilink).
  • As discussed in the Phabricator task that precipitated the settings change, the intent of the change was to allow Special:Random and Special:Nearby to work with both galleries and files. Currently the navigation menu (left side of page) contains a "hardcoded" link to Special:Random/File rather than Special:Random. With the change, Special:Random now brings up (presumably) either a file or a gallery page. Is this desired? Do we care? (As for Special:Nearby, I can't say much since I've never worked with that.)

So… comments? Should I open an RFC about this? - dcljr (talk) 04:30, 21 June 2017 (UTC)

@Dcljr: I agree that a "content page" on a media repository should probably include the media itself but what practical effect would this have? We already have a magic word for the number of files and it's shown on the Main Pages, so anyone could easily have an idea of how big the repository is. —Justin (koavf)❤T☮C☺M☯ 04:54, 21 June 2017 (UTC)
The "content pages" count shown at Special:Statistics is also accessible through {{NUMBEROFARTICLES}} on-wiki and tracked at stats:. Many people also gather "content pages" counts for various Wikimedia Wikis (including this one) through the API. If the wiki is going to report its count of "content pages", however defined, it should report the correct count, right? That's all I'm saying. We just need to decide which "correct count" we want to use. - dcljr (talk) 05:16, 21 June 2017 (UTC) Edit: Oops… I forgot: stats: uses it own, different definition of what constitutes "content pages", and does not rely on wiki-reported counts. - dcljr (talk) 06:36, 21 June 2017 (UTC)
I don't really care one way or the other, but if the File: namespace is included, the Data: namespace should probably be included as well. --El Grafo (talk) 06:54, 21 June 2017 (UTC)
Clearly the change should be reverted (+1 to dcljr).--Kopiersperre (talk) 13:02, 23 June 2017 (UTC)
@Kopiersperre: "Clearly" because why? - dcljr (talk) 21:21, 29 June 2017 (UTC)
What about file pages that don't use [[normal links]] but do have other kinds of content? When I upload images (I'm just past twenty thousand of them), I tend not to use normal links; instead, I provide lots of {{W}} links to en:wp. For example, my most recent upload, File:Marlbrook near Glasgow.jpg, transcludes {{W}} six times in a 32-word description. Nyttend (talk) 18:32, 24 June 2017 (UTC)
Interwiki links do not qualify pages as "content pages" under the "link" definition being used here at Commons, only "normal" internal wikilinks. Specially processed links like [[Category:]] (to place a page into a category) or [[File:]] (to display a file) don't count either, although the "normal wikilink" versions starting with colons, like [[:Category:]] and [[:File:]], do count (but we don't want to use this fact to "game" the system into counting pages that would otherwise not be counted — we should choose the settings for counting method and content namespaces that best reflects our current practices/opinions about content). - dcljr (talk) 22:11, 25 June 2017 (UTC)
Just a note to say I'm investigating how to reset the count. Will do that regardless of the decision around the value however my goal is to make sure the chosen value is well documented (since it is not obvious) to avoid this happening again. Note that the page Special: Nearby and default behaviour of Special:Random and other things depend on the value. The former will be broken (and probably disabled) if we need to switch it back. Something to consider. Jdlrobson (talk) 14:25, 26 June 2017 (UTC)
I don't know what Jdlrobson is finding out about fixing the count, but it looks like the opinions expressed here are leaning towards accepting the settings change (mostly because of a lack of strong feeling either way) — especially since the only user who has explicitly said the change should be reverted (Kopiersperre) has not provided any reason why that should be done. I am concerned, however, that the sysadmins might not want to go to the trouble of recounting the wiki (which may take many hours—I'm not really sure) without more input from the Commons community about this. If I do decide to open an official RFC, do I have to move the discussion away from this page? - dcljr (talk) 00:39, 5 July 2017 (UTC)
I'll investigate what's needed to reset the count and get back to you. No RFC necessary. Note, there are no deployments this week so this is not likely possible until next week. Jdlrobson (talk) 18:05, 5 July 2017 (UTC)
Update this has now been done. The count should be correct again and now includes file pages. Jdlrobson (talk) 22:57, 5 July 2017 (UTC)

Statistics is just one part of it. At the very least reverting such a change would fix timeouts in Special:shortpages and special:longpages, in the short term (https://phabricator.wikimedia.org/T168010). It is pretty obvious that aside from counting pages like that, it now also fetches files. So it is now timing out due to the fact that it is an inefficient query page, and also due to the many stored files (which is combined with pages in namespace 0). 22:58, 5 July 2017 (UTC) — Preceding unsigned comment was added by 197.218.89.210 (talk) 22:58, 5 July 2017 (UTC)

Why does it not surprise me that an actual argument is offered right after the recounting is done? (!!) Fortunately, it looks like recounting doesn't, in fact, take hours (AFAICT), so whatever needs to be done to fix whatever problems remain, the wiki can (apparently) be quickly recounted again in the future, if necessary. - dcljr (talk) 00:55, 6 July 2017 (UTC)
BTW, the English Wikipedia also has a huge number of pages to look through (although all in NS0), and it doesn't seem to have any problems showing "live" lists of en:Special:ShortPages and en:Special:LongPages. Why is Commons unable to handle it? - dcljr (talk) 00:58, 6 July 2017 (UTC)
@Dcljr: English Wikipedia has ~5.4M pages to sort through, we now have ~40.5M pages to sort through. Perhaps another index or two would help.   — Jeff G. ツ 01:11, 6 July 2017 (UTC)
Touché… Presumably, any "good ideas" would be welcome at the relevant Phabricator task. (Not knowing much about it, my only suggestion would be to make it cached instead of live.) - dcljr (talk) 07:49, 6 July 2017 (UTC)
@Dcljr: Thanks, I commented there.   — Jeff G. ツ 16:29, 8 July 2017 (UTC)

Interested parties (which I continue to wish were more numerous!): Note that the problem causing Special:ShortPages and Special:LongPages to fail seems to have been fixed, but another problem has been reported at phab:T170687 (after being discussed briefly in phab:T167077 and phab:T168010):

  • Special:ShortPages is no longer useful for vandalism/test-edit fighting because it now contains a ton of very small File: pages (containing only short template calls) that are (presumably) nevertheless well-formed pages.

Some folks at Phabricator want more input (at phab:T170687) from the Commons community about what has changed around here (especially the functionality/usefulness of other Special pages) as they consider what might be done in response to this problem. @Jdlrobson: Please add whatever additional information you think is important for the community to consider. - dcljr (talk) 12:03, 15 July 2017 (UTC)

According to mw:Manual:$wgContentNamespaces, the following special pages are potentially affected by changes to that variable (which is the settings change we've been talking about): Special:Random, Special:Nearby, Special:Statistics, Special:AncientPages, Special:DeadendPages, Special:FewestRevisions, Special:LonelyPages, Special:MostCategories, Special:MostInterwikis, Special:ShortPages, Special:LongPages, Special:UncategorizedPages, Special:WithoutInterwiki. So, have people noticed any of these pages losing (or perhaps gaining) utility after the settings change of June 6th? - dcljr (talk) 13:19, 15 July 2017 (UTC)
I think the best thing for now is to revert the change that leaded to all these problems, so that we could finally use Special:ShortPages again. It will show a lot of test-pages now the report has been out of service for several weeks. And then maybe reapply the change as soon as it is in a state in which it does not break several reports. Jcb (talk) 21:26, 15 July 2017 (UTC)
Reverting breaks various other things, so that's not really an option here. We've heard Special:ShortPages is not useful in current form - so fixing that is now the top priority, but please let us know if there are other special pages that are unusable. Right now we're considering making it possible to use Special:ShortPages on individual namespaces e.g. you'd be able to get reports of all short file pages or all short pages in the main namespace or all short pages in any other namespace. Would that be useful? Would that solve this problem? Jdlrobson (talk) 16:39, 17 July 2017 (UTC)

Uploading photos with OTRS-pending template

I am trying to upload som pictures under License: CC0, and with a OTRS-pending template. I've read some "how to's" but I'm afraid to make a mistake. So here's my question: Am I supposed to put the template {subst:OP} to the "Source" field when uploading? On COM:OTRS it says: "place the tag {subst:OP} ("OTRS Pending") on the file description page", is that the same? And how will I or the author get the e-mai ticketnumber? I might seem pretty lame, but I've never uploaded a photo to Commons before:) --Sabine Rønsen (WMNO) (talk) 09:32, 13 July 2017 (UTC)

Sabine Rønsen (WMNO), yes, the {{subst:OP}} template is the best thing to do, and those parts of the page are indeed referring to the same thing. When you send an email to OTRS, you will get an automatic response saying "email was received" and it will assign you a ticket number which you can keep for your reference. That's all you do to the file page, OTRS agents will do the rest. When it has that template on the page, other users know that it is essentially a grace period because OTRS is not instant and is backlogged at the moment so there are lots of images waiting weeks. So it will not be deleted instantly.
As for whether or not you need OTRS, it's only required if you are uploading an image that (a) is not your own work and (b) it was published elsewhere online or in print beforehand with "All rights reserved" or without an accompanying free license. Are these photos your own work? Just jump in and upload them, select your license, and that's it, no OTRS required. Feel free to ask anymore questions about this if you are unsure. seb26 (talk) 13:48, 13 July 2017 (UTC)
@Sabine Rønsen (WMNO): I've approved the OTRS ticket in question, and modified the file description pages accordingly. --Jonatan Svensson Glad (talk) 22:12, 15 July 2017 (UTC)
Thank you seb26 and Jonatan Svensson Glad! That was really helpful:) --Sabine Rønsen (WMNO) (talk) 07:21, 18 July 2017 (UTC)

Strategy discussion, cycle 3. A new challenge

Hi! It's the third week of our Cycle 3 discussion, and there's a new challenge: As Wikimedia looks toward 2030, how can we counteract the increasing levels of misinformation? You can suggest solutions here. Earlier challenges can be discussed as well. SGrabarczuk (WMF) (talk) 12:15, 16 July 2017 (UTC)

@SGrabarczuk (WMF): The talk page for the page linked (here) is confusing, as after being created for a few weeks with the expectation of responses to other questions, there have been no comments by anyone. Are responses supposed to go there, because it seems very discouraging to write on a blank page? Thanks --Fæ (talk) 12:49, 16 July 2017 (UTC)
@Fæ: , I watch it anyway and if anything appears, I'll summarize that, and it will be taken into account. I'm a bit surprised that no one has written anything there - maybe because most users prefer to write on Meta? On the other hand, someone has to be first, so go ahead, please. SGrabarczuk (WMF) (talk) 14:06, 16 July 2017 (UTC)
I suggest redirecting it to the meta discussion. The question is relevant for Wikipedia, but rarely comes up as an issue on Commons. Thanks --Fæ (talk) 14:09, 16 July 2017 (UTC)
I'm not surprised. there is no interest in strategy here, only in the tactics of deletion. Slowking4 § Sander.v.Ginkel's revenge 19:21, 17 July 2017 (UTC)

My recent file moves

Recently, I have been moving a lot of files with punctuation errors, generally those involving spacing around commas. Although this may seem trivial, I am doing this for an important reason, that being that file names here have consequences elsewhere.

I am currently engaged in a project on Wikipedia to fix small but unsightly punctuation errors - mostly spacing issues around commas.

What we are supposed to have is: 

Jones, Johnson, and Smith formed Smithco, Inc., in Provo, Utah.

Instead, we often see spacing errors like: 

Jones,Johnson, and Smith formed Smithco,Inc., in Provo,Utah.

or: 

Jones, Johnson ,and Smith formed Smithco ,Inc., in Provo ,Utah.

or even: 

Jones , Johnson , and Smith formed Smithco , Inc. , in Provo , Utah.

There are literally tens of thousands of these to fix, and the most efficient way I have found to do this is to load large groups of articles through AWB (I generate batches of 150,000) and use a script to fix any pages in those groups that return such errors. Unfortunately, due to the structure of our coding, text in file names is not distinguished from text in the body of an article. A number of templates omit the "File:" part of the term, making it even harder to distinguish these from regular text while editing. In order to avoid thousands of false positives, the easiest thing to do is to just rename files that have the sort of punctuation errors that need to be fixed when found in an article. Otherwise, editors carrying out the same task in the future will continually come across the same apparent errors, and will waste thousands of edit's worth of time checking and dismissing them.

I also note that filenames containing basic punctuation errors tend to contain spelling errors or have other problems. In a number of cases, I have seen groups of images with very similar names except for a punctuation error - missing spaces and extraneous spaces or punctuation being the only features distinguishing the image names. This is a recipe for confusion. For example, File:Celtic settlement-Open-Air Archaeological Museum Liptovska Mara - Havranok,Slovakia....jpg, File:Celtic settlement-Open-Air Archaeological Museum Liptovska Mara - Havranok,Slovakia..jpg, and File:Celtic settlement-Open-Air Archaeological Museum Liptovska Mara - Havranok,Slovakia.jpg, each of which I moved to more distinctive titles without the punctuation errors. I would prefer not to allow the idea of minimizing file moves interfere with the real work of fixing minor errors which continue to make Wikipedia look amateurish.

Another editor (@Materialscientist: ) has objected to these file moves on the grounds that "every move may result in a loss of file due to the imperfections of Wikisoftware", and has also suggested that they do not comply with file moving policy. I believe that they clearly fall under move rationale 3 (to correct obvious errors) and rationale 6 (maintenance and bug fixes, because these errors cause maintenance issues where the files are actually used). In quite a few of these cases, rationales 2 and 4 (changing ambiguous names and harmonizing files in a set) are also implicated. Finally, I have never "lost" a file in the literally thousands that I have moved in my career here (I have been moving meaningless two- and three-letter-acronym titles to titles identifying the subject for years, sometimes by the dozen, without incident).

I therefore would like to continue this task, but I will defer to the the community if there is a consensus that these file moves are improper. Cheers! BD2412 T 15:57, 16 July 2017 (UTC)

  • I would be better when such a file is just uploaded it is automatically flagged by software for a review. Ruslik (talk) 19:08, 16 July 2017 (UTC)
    • It would be absolutely ideal if Commons exercised some editorial review of filenames when files were uploaded - but discovering errors at that time would still necessitate moving the files. The same editors who make spelling and punctuation errors in text are likely to make those errors when uploading files, leading to the same editing issues. BD2412 T 20:14, 16 July 2017 (UTC)
  • Correcting punctuation mistakes in Wikipedia is very good, but it has nothing to do with filenames in Commons. The moves you have been made, as described, go against COM:FR (and, no, rationale 3 doesn’t cover typos in filenames, only misleading information), and you should stop doing it. The software you use should be able to detect what is a filename and what is not, and leave them alone; any false positives of that should be manually undone. -- Tuválkin ✉ ✇ 19:35, 16 July 2017 (UTC)
    • AWB is a text editor (probably the most widely used one outside of the native interface), and can't tell a filename from any other string of text. If you believe that this software should have this capacity, by all means please develop it. BD2412 T 20:11, 16 July 2017 (UTC)
      • You’re the one who needs that capacity, as you’re the one who’ve been renaming files en masse against the relevant guideline because of the lack of that it. But I venture that a relatively simple grep filter would be able to isolate most filenames within wikitext. -- Tuválkin ✉ ✇ 21:17, 16 July 2017 (UTC)
        • Yes I - and any other editors trying to fix comma space errors throughout the encyclopedia - need that capacity. However, since it doesn't seem to exist, how do we address the large number of filenames containing these errors? Surely it is not the function of Commons to serve as a permanent repository of typos and mistakes in file names? BD2412 T 22:47, 16 July 2017 (UTC)
          • Concerning your first question: As repeatedly said, it is necessary to escape off any non-linguistic content (such as filenames) before performing any kind of automatic proofing of a linguistic nature (incl. punctuation). Also I’m concerned that you keep mentioning «the encyclopedia», and I hope you’re aware that thare are more languages than English, and that Wikimedia Commons concerns itself with more roles than being a mere storage area to host Wikipedia images. Which leads to answering your second question: Filenames are not to be mistaken for any kind of articulated sentence, and one of the functions of Wikimedia Commons is to be a trustworthy media repository where third party reusers can presume filename stability, meaning that what was once available at File:OMG,typoes!!.gif will not later on (along with its additional info, incl. license) be lost to a 404 because it was renamed File:Oh,_my_God:_Typos!.gif. -- Tuválkin ✉ ✇ 16:31, 17 July 2017 (UTC)

Filenames are filenames and I've don't think I've ever been of the opinion that they are supposed to be representative of actual sentences or text to the point that they need to follow rules of grammar. Ideally, they should be as short and concise as possible and convey information clearly. They are never seen by end users unless they seek them out, so why should filenames be required to follow the rules of grammar if they are not to be read by the vast majority of users? Keep in mind Commons is also a multilingual project so the grammar that you speak of is assumedly only English grammar, and says nothing for the filenames that can be found (perfectly acceptably) written in other languages or scripts. Commons is not a text-heavy project itself, but while I can understand that they would cross over and affect Wikipedia work, Commons filenames do not appear anywhere except within [[File:]] and within galleries. Is AWB really not able to pick up on these instances and avoid corrections, even if you designate it to avoid text in templates? AWB is also meant to be a human-assisted program, meaning the user proofs their edits as they go. I think there's some responsibility there for a user operating an automated program to adapt their work accordingly, especially so when it concerns the unpredictable nature (in a programming sense) of written language and grammar. seb26 (talk) 01:08, 17 July 2017 (UTC)

The issue is one of efficiency. Yes, AWB is human-assisted, and edits are proofed as they are made, but that also means that every editor engaged in this task must proofread the same text that every other editor has already proofread, because you can't tell when someone has looked at the page and decided not to make an edit. That said, I am throwing in the flag on this task until it is technologically feasible to weed out false positives appearing as normal text with typos. BD2412 T 01:40, 17 July 2017 (UTC)
@BD2412: If you could configure AWB to ignore lines starting with "|image=" with possible surrounding spaces and having non-space characters after the equal sign, that would tackle the vast majority of instances of your problem in infobox templates.   — Jeff G. ツ 03:38, 17 July 2017 (UTC)
It is possible to entirely ignore such pages, but that would mean ignoring actual errors also to be found on those pages. BD2412 T 03:45, 17 July 2017 (UTC)
Jeff G. refered to lines, not pages. -- Tuválkin ✉ ✇ 16:31, 17 July 2017 (UTC)
  • We are aware that
  1. any filname includes at least one punctuation mistake, an unavoidable one, by always including a period immediately followed by a letter, and
  2. some punctuation correction attempts, such as of adding colons, will render a filename call broken and fail when one tries to enact it (movefile),
are we not? -- Tuválkin ✉ ✇ 16:31, 17 July 2017 (UTC)
Periods followed by letters occur in many correct text situations (even in textual descriptions of filename extensions). There are, however, very, very few circumstances in any language using the Latin alphabet where a comma is either followed by a letter or preceded by a space. That is the focus of the cleanup task in which I am engaged. BD2412 T 02:00, 18 July 2017 (UTC)

July 17

Creator:Jacob Toorenvliet

Imo the image should be replaced by this one, it is rather confusing now, looks to me as if Jacob Toorenvliet was a woman. Date of birth is 1641 on the image. Lotje (talk) 15:21, 17 July 2017 (UTC)

Hi, Go ahead. For changing the image, it is on Wikidata: d:Q663613. Regards, Yann (talk) 15:32, 17 July 2017 (UTC)
✓ Done and thanks Yann Lotje (talk) 16:47, 17 July 2017 (UTC)

Taiwan museum makes exhibit images free to download

This BBC report says that the National Palace Museum in Taipei "has placed 70,000 high-quality electronic images in a free-to-download archive [and] provides a database for users to download information on the history and use of the cultural artefacts". Can someone who reads Taiwanese check the licence on these please? At least one of the images shown in the BBC article is an historic, out-of-copyright 2D artwork. Andy Mabbett (talk) 15:41, 17 July 2017 (UTC)

There is an english version of the museum's website: FAQ, About Open Data, and a link to this page. No sign of a free license, only "free to use for educational purposes". --El Grafo (talk) 15:50, 17 July 2017 (UTC)
However since we belive in COM:PD-Art for 2D-works, we don't care about if they claim rights for publishing the wors if they are 2d works in the public domain. --Jonatan Svensson Glad (talk) 17:37, 17 July 2017 (UTC)

Tech News: 2017-29

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • "Wikimedia Labs" is now called "Cloud VPS". "Wikimedia Tool Labs" is now called "Wikimedia Toolforge". This is to help clarify the purpose of these services. [11]

Problems

  • On some pages, the Table of Contents is not being shown. It will normally appear if you edit the page again. Investigation is currently ongoing. [12]

Changes this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 July. It will be on non-Wikipedia wikis and some Wikipedias from 19 July. It will be on all wikis from 20 July (calendar).

Meetings

  • You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 18 July at 19:00 (UTC). See how to join.
  • You can join the next meeting with the Architecture committee. The topic this week is: Migrate to HTML5 section ids. [13] The meeting will be on 19 July at 21:00 (UTC). See how to join.

Future changes

  • Page Previews, currently a Beta Feature, will be enabled for logged-out users for all remaining Wikipedias (with the exception of English and German) the week of 24 July. An A/B test will be run on English Wikipedia to collect data before approaching the community for further discussion. [14]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

22:59, 17 July 2017 (UTC)

July 18

Commons Android app - IEG renewal proposal

Hi folks,

The Wikimedia Commons app (a community-maintained Android app that allows users to upload photos to Commons from their phone) was funded via an Individual Engagement Grant last year and has had several improvements and new features added to it over the course of the grant. Examples include a list and map of nearby places that need photos (based on Wikidata), category suggestions based on the image title and location, prevention of duplicate uploads, and a new tutorial to educate new users on what types of photos should or should not be uploaded. 20554 new files were uploaded via the app during the grant period with an overall deletion rate of 15.74% (11.7% in the final two weeks after the new tutorial was implemented), and 3485 images that were uploaded via the app were used in Wikimedia articles. The final report for the completed IEG can be viewed here.

While we are very happy with the progress made, users have requested many other improvements that we would like to make but were not able to fit into the scope of the previous grant. Thus we are proposing a renewal of the IEG in order to work on these. Highlights of the proposed improvements include:

  • Enhancing the "Nearby places that need photos" feature by (1) allowing users to upload their image directly from a location on the list or map, with suggested title and categories based on the associated Wikidata item, and (2) displaying the user's real-time position on the map to allow easier navigation to the location they wish to photograph
  • Improving user education by displaying Commons account and user talk notifications (e.g. picture nominated for deletion) in the app, adding a gallery of featured images, and adding various notices and explanations in the upload screen
  • A sleeker, more intuitive, and more interactive user interface - a floating action button for uploads, "Nearby places that need photos" in a tab alongside the user's contributions, and a panel to display Commons account notifications and information about the nearest place that needs photos
  • Various technical and quality-of-life improvements, such as two-factor authentication login, multiple uploads, preventing overwrites, and fixing memory leaks and battery drain issues

We would very much appreciate feedback and suggestions on the renewal proposal - our aim is to benefit the Commons community as well as other Wikimedia projects relying on Commons, so feedback from this community is extremely important to us. Please do take a look at our proposal, feel free to ask questions and make new suggestions on the Discussion page, and/or endorse the proposal if you see fit. If you would like to be part of the project, new volunteers and additions to our diverse team are always welcome - please visit our GitHub repository or Google groups forum and say "Hi". :)


Many thanks! Misaochan (talk) 10:12, 17 July 2017 (UTC)

(As a side note, this is not the app that caused the selfie-pocalypse several years ago - that was caused by the web app, which is very different from the native Android app, especially in its current incarnation. Ongoing stats for uploads and deletes from the Android app are available here)

See my comment on the mailinglist: https://lists.wikimedia.org/pipermail/commons-l/2017-July/007895.html --Steinsplitter (talk) 14:02, 18 July 2017 (UTC)
Thanks for your feedback, Steinsplitter. Honest question, not being sarcastic - do you think the Wikipedia mobile app would be anywhere close to where it is today (in terms of quality, usability, and userbase) if none of their developers were paid? Granted, we cannot claim to be on par with the Wikipedia app (in any of those aspects), but I believe the budget we are requesting is commensurate to our current output and I hope that one day we will approach that level of quality. I personally would support other Commons tool makers if they applied for grants to cover their development costs, if I hear of their applications. Misaochan (talk) 14:49, 18 July 2017 (UTC)

Map of recently uploaded pictures

I want to see a map of all pictures uploaded to Commons in the last 24 hours. Is there such a tool?

WikiMiniAtlas does not seem to have that option.

Thanks! Syced (talk) 04:27, 18 July 2017 (UTC)

Special:NewFiles should help. In Vector skin you have a link on top left side. — Speravir – 18:59, 18 July 2017 (UTC)

Reference error keeps showing up in description page

Colpoclypeus florus (female). Stinger will inject toxin, causes the leafroller to spin extra-thick webbing, K10910-1.jpg

A reference error keeps showing up in this file despite several attempts and previews. Maybe I used some template incorrectly? Suggestions anyone? Thanks a lot! — bertux 15:35, 18 July 2017 (UTC)

Solved, thanks Yann! — bertux 16:24, 18 July 2017 (UTC)

Problematic uploads by now inactive user

How to deal with this? There is an Armenian user who was only active in late 2015, here and in Armenian wikipedia. I can not tell anything about the quality in the wikipedia, but the file uploads seem to have serious issues. I did not check every file, but every file I checked has issues:

  • All uploads are declared as own work, but all are in fact works of other people.
  • In parts the filenames are, eeehm, worthy of improvement (there are some incomplete rename requests; this is, how it caught my attention).
  • In some cases we could mark them as duplicate, but in most cases the filetype was changed.
  • Some images are probably copyvios from external sources, as far as I can tell.

I already started some deletion and duplicate requests, but have still some questions:

  • Should the user be blocked, or still AGF?
  • What to do with the duplicates, but in different filetypes: only fix author, date and licence or start a deletion request (the quality is usually poor, too)?

— Speravir – 21:31, 18 July 2017 (UTC)

Hi,
Most of the files are indeed not own works, as claimed: Commons:Deletion requests/Files uploaded by Ադելլա. A warning should be enough for now. Regards, Yann (talk) 22:07, 18 July 2017 (UTC)
Thanks so far. I will add remarks to files you mentioned in the request. — Speravir – 22:19, 18 July 2017 (UTC)

July 19

Copyrights

Does this image have any copyrights? Super ninja2 (talk) 06:58, 20 July 2017 (UTC)

July 20

Strategy discussion, cycle 3. Challenge 4

Hi! The movement strategy discussion is still underway, and there are four challenges that you may discuss:

  1. How do our communities and content stay relevant in a changing world?
  2. How could we capture the sum of all knowledge when much of it cannot be verified in traditional ways?
  3. As Wikimedia looks toward 2030, how can we counteract the increasing levels of misinformation?
  4. and the newest one: How does Wikimedia continue to be as useful as possible to the world as the creation, presentation, and distribution of knowledge change?

The last, fifth challenge will be released on July, 25.

If you want to know what other communities think about the challenges, there's the latest weekly summary (July 10 to 16), and there's the previous one (July 1 to 9).

SGrabarczuk (WMF) (talk) 13:39, 20 July 2017 (UTC)

Gallery pages

Gallery pages have been much maligned, and I would agree that most of them are pretty useless. I just now took 45 minutes to create one for a topic that I don't think is well served by just its categories and subcategories: The Grotto (Portland, Oregon). I'd really love to encourage people to consider creating a lot more like this: if well curated, these can be a very useful annex to this site. - Jmabel ! talk 06:24, 21 July 2017 (UTC)

Photo vs depicted work licence template

Hello,

This might already have been asked before, but I couldn't find the answer.

Is there a specific template to show that the depicted work is under another licence than the photo itself?

Best,

--AntonierCH (d) 10:20, 26 July 2017 (UTC)

You may be looking for {{Art Photo}}. —LX (talk, contribs) 10:56, 26 July 2017 (UTC)
Thx for your help LX, but I am more looking for a template like {{Self}} that can contain one permission for the depicted work and one for the picture itself. I know it exists, I saw it several times. --AntonierCH (d) 20:27, 26 July 2017 (UTC)
AntonierCH, could you look at simply using two section headers and placing the different arrangement under each one? I don't know of any template specifically but this use of sections is what I have typically seen. seb26 (talk) 20:59, 26 July 2017 (UTC)
@Seb26 No, I would like to use the right template :-P But I found it, it's {{Copyright information}}. Thx for you suggestion anyway. --AntonierCH (d) 21:02, 26 July 2017 (UTC)
This section was archived on a request by: --AntonierCH (d) 08:31, 27 July 2017 (UTC)

Batch uploading not working?

I recently submitted a request Here to upload PD scans, is it usual that I haven't received a response yet? --Donald Trung (talk) 23:29, 27 July 2017 (UTC)

Looks like you forgot to add {{Commons:Batch uploading/Illustrations of Vietnamese cash coins from Ed Toda's "Annam and its minor currency".}} to the list under "new requests". I've done so, so now people can see it. Guanaco (talk) 23:37, 27 July 2017 (UTC)
Thanks. 😃 :This section was archived on a request by: --Donald Trung (talk) 00:14, 28 July 2017 (UTC)

Technical schematics: PD or not PD?

There is an image I would like to upload to Commons of the Hindenberg airship located here. It is marked as copyright protected 2008 along with the name of the person who drew it, but of course saying something is protected and having it be protected are not always the same thing. My argument for the image being in the public domain is that it consists only of information— that unlike some other diagrams of the Hindenberg such as this one or this one, it contains no creative content, and that anyone creating an accurate technical diagram of the Hindenberg would end up producing the same image. Information cannot be protected by copyright, and the sweat-of-the-brow doctrine does not apply: there is no question that the image is complex and was difficult to create, but that doesn't mean it reflects anything about the author's personality (because as a technical diagram, it does not) and therefore, in my view, it is in the public domain, regardless of the author's claims to the contrary. But I am not certain how others would interpret these things. Thoughts? KDS4444 (talk) 19:11, 19 July 2017 (UTC)

  • My understanding is that raster versions of fonts aren't actually copyrightable (per Commons:Licensing#Fonts), and as near as I can tell the line thicknesses shown in the diagram actually represent the relative thicknesses or minimalist outlines of various parts of the airship (e.g., the cables, the outlines of a piano, etc.) and are therefore factual and not actually creative. The author had creative license with regard to where on the image he placed certain labels as well as their size— this implies that a version of the image without these labels, with different labels, or with labels placed in different places but otherwise identical would qualify as either public domain (in the first instance) or as a newly copyrightable derivative work (in the second and third), no? I will also see if I can get some response at the copyright portion of the village pump. KDS4444 (talk) 22:13, 19 July 2017 (UTC)
  • Who decided what specific elements deserved to be represented in the image? It's the drafter's choice, and another technical drawing might include more or less in the way of details. This isn't like {{PD-chem}}, where the precise content is standardised, and anything with a little more or a little less is outright wrong. Nyttend (talk) 11:47, 21 July 2017 (UTC)

Fantastic title, but hard to decipher

It's some book by Euclid, I could (barely) read that, but could anyone with some knowledge of mathematics tell us which one? Thank you! (Hats off to the typographers of the Renaissance, though.) --Edelseider (talk) 06:43, 21 July 2017 (UTC)

Euclidis megaresis philosophi platonici.
See also [15]: "The first printed translation from the Greek is that of Bartholomew Zamberti, which appeared at Venice in 1505. Its contents will be seen from the title: Euclidis megarēsis philosophi platonici..." --тнояsтеn ⇔ 10:45, 21 July 2017 (UTC)
This print is probably 1510 by Joannes Tacuinus de Tridino, based on one up for sale on Abebooks. OCLC 51276185 --Fæ (talk) 10:51, 21 July 2017 (UTC)
Thank you very much! --Edelseider (talk) 11:57, 21 July 2017 (UTC)

An idea 💡 to possibly prevent spam, and re-uploaded unfree images.

I have an idea 💡 to prevent the re-uploading of previously deleted unfree images, and to maybe prevent spam to some level. I am mostly inspired by 2 (two) things, first of all I don't want to accidentally re-upload images I thought were free but because the country I visited had more limited F.O.P. than I am used to, and got deleted, and the second inspiration came/comes from a recent block 🤚🏻 here on Wikimedia Commons where an account attempted to upload an image called “Kate Winslet.jpg” around 30 times, and then (a suspected/an alleged) sockpuppet attempted this 3 (three) or 5 (five) times more. Now here is how we could easily prevent both from happening, simply keep ALL deleted images (without displaying them, hosting copyrighted images without making them available is not illegal, only sharing them is), and then scan all new uploaded images before publishing to see if they’re among the deleted images.

Now I know that some trolls will make minor adjustments to the images to not get detected, however this will prevent a large part of users who just upload the same Facebook post or the same copyrighted images. Is this feasible?

--58.187.171.238 10:50, 22 July 2017 (UTC)

Deleted images are generally kept on the server so they can be restored and reviewed by admins as needed. This might be relatively simple to implement with a hash function, but I wouldn't do a hard disallow of uploads if it catches something. False positives could happen, and there are sometimes legitimate reuploads. Better to tag them as with the abuse filter: "possible reupload of deleted file File:Bad photo.jpg." Guanaco (talk) 11:06, 22 July 2017 (UTC)

Template for human remains

Greetings,

I am currently preparing a photography session at the Ethnographic Museum of Geneva [16], and have presented them with a sample of the work I envision [17]. Upon seeing Category:Deformed trepanated skull-ETHAM 019484, my interlocutor brought my attention to this page, which explains the legal and ethical implications of displaying items stolen from cultures oppressed by colonialism, especiallly when they are made of human remains.

Do we have a template to this effect, in the vein of Template:Personality rights? In the negative, should we consider one?

Thank you for your attention and good continuation! Rama (talk) 12:26, 21 July 2017 (UTC)

It would not be the exact same problem, but I do feel potential use for such templates. Some items might look comical at a first glance and without context, it might be useful to bring attention to the fact that they have a strong connotation and are constituted of human remains. Rama (talk) 08:49, 23 July 2017 (UTC)
For instance the object depicted at Category:Marratampirivit overmodelled skull-ETHOC 010205 might look amusing at a first glance. It is not. Rama (talk) 11:31, 23 July 2017 (UTC)

@Rama: , about that Peruvian skull from Geneva, I just added the Category:Artificial cranial deformation in Peru, which is in itself a subcategory of Category:Artificial cranial deformation. So much for contextualizing a bit more - artificial deformation of skulls is not something only colonialized peoples and cultures have done, see this prehistoric item from bien de chez nous. :) --Edelseider (talk) 15:07, 21 July 2017 (UTC)

Nice catch Edelseider, thank you! Rama (talk) 15:22, 21 July 2017 (UTC)

July 22

Japanese ribbons

File:JPN Zuiho-sho (WW2) 1Class BAR.svg, File:JPN Kyokujitsu-sho 1Class BAR.svg, and their duplicates were overwritten in some sort of bulk update. I'm unfamiliar with this award system and the history, but it appears the update might contravene COM:OVERWRITE. It may be particularly problematic on articles like en:Order of the Rising Sun, where we now have ten categories of people over 140 years with visually identical awards. I'd like some help figuring out what to do with this. Should we revert them? Guanaco (talk) 06:18, 22 July 2017 (UTC)

Also

Guanaco (talk) 06:21, 22 July 2017 (UTC)

  • I have already explained why I overwrites it at User talk:Uaauaa#Duplicates.Do you have any further questions?--uaa (talk) 19:44, 22 July 2017 (UTC)
    @Uaauaa: What I'm seeing is that there are rosettes for these awards, or at least some of them. It may not be accepted to overlay the ribbon with a rosette as in the images, but it does provide a somewhat valid, visual method of distinguishing the different classes of awards. Your point of view is valid as well, and there's good reason not to display awards in any misleading fashion.
    In line with COM:OVERWRITE, I propose that we revert the images to their previous state. We then create a category and template marking them as non-historical visual representations. From there, the various wikis can make their own editorial decision of how they would like to represent Japanese ribbon bars. Guanaco (talk) 23:35, 22 July 2017 (UTC)

I do not think the COM violation situation is preferable. However, it is more unacceptable to make up an imaginary ribbon. It is better to change links in all articles to the same file by bot editing and delete the remaining files. There are not many articles that need a visual way to distinguish between different classes of awards.It is not necessary for the honor field in the article of a person. Also, it is not preferable for articles like en:Order of the Sacred Treasure. If you just think you need it, you can create a new correct file for a few articles that need it. I think that it is preferable that a file with no ribbon and only rosette is preferred.--uaa (talk) 17:43, 23 July 2017 (UTC)

I'm going to go ahead and revert these images and add {{Ahistorical award}}. Policy about respecting other wikis' editorial decisions won't allow us to use User:CommonsDelinker or similar to make your proposed change at a centralized level, but you can do what you will on other projects. Guanaco (talk) 18:12, 23 July 2017 (UTC)
✓ Done. Guanaco (talk) 18:43, 23 July 2017 (UTC)

I am disappointed in your actions that forged false edits by ignoring my opinion. You have not explained enough to convince me. I will fix it again.--uaa (talk) 19:37, 23 July 2017 (UTC)

@Uaauaa: Please fix it by replacing the images on Wikipedia with the originals, which I've linked via the template on each file page. Overwriting/reverting the images again would be against Commons policy. Guanaco (talk) 19:48, 23 July 2017 (UTC)

There is no class in kikkasho, so rosette are not necessary. Therefore, revert soon.--uaa (talk) 19:55, 23 July 2017 (UTC)

@Uaauaa: Don't revert. Replace it on Wikipedia instead. If you think the image is garbage, start a deletion request. Guanaco (talk) 19:59, 23 July 2017 (UTC)

Other fileｓ will be changed to a new version.--uaa (talk) 19:59, 23 July 2017 (UTC)

By the way, do you think that you can allow fake information to flow for the commons policy?--uaa (talk) 20:10, 23 July 2017 (UTC)

I have started a discussion/poll at User talk:CommonsDelinker/commands/talk#Global replacement for possibly incorrect Japanese ribbon bar, to address this. Guanaco (talk) 20:42, 23 July 2017 (UTC)

Help with new file

File added to Lupton family page on Wikipedia. The file is called Lord Mayor Sir Charles Lupton etc etc. I have added a comment on the deletion page. Please let me know what can be done to get this file all ok. It was not published until 2013 in newspapers and then online. It was filmed in 1915-16. Thanks so much from a novice. 2001:8003:4E8F:6D00:6939:DA68:5FBA:B50B 11:17, 22 July 2017 (UTC)

This file is not in public in USA (due to URAA restoration), so nothing can be done until 1 January 2022. Ruslik (talk) 14:09, 22 July 2017 (UTC)
Which file? Can it be tagged with Category:Undelete in 2022? -- Tuválkin ✉ ✇ 22:29, 22 July 2017 (UTC)
Commons:Deletion requests/File:Princess Mary and Lady Mayoress Isabella Lupton 1926.jpg. Ruslik (talk) 19:27, 23 July 2017 (UTC)
Thank you! -- Tuválkin ✉ ✇ 00:53, 24 July 2017 (UTC)

Open search on a new window

Until today or so it was possible to enter a queary in the search box and have the results page open in a new window by Ctrl-clicking the button Search. It stopped working for me (Monobook user). Any ideas? -- Tuválkin ✉ ✇ 22:36, 22 July 2017 (UTC)

Works fine for me with vector. With monobook, Firefox told me it was blocking a popup window – allowing popups for Commons made it work (opens in new tab, not window). --El Grafo (talk) 06:53, 23 July 2017 (UTC)
Thx for replying. For some reason it is again working properly as before, without any change on my part. -- Tuválkin ✉ ✇ 00:52, 24 July 2017 (UTC)

July 23

Setting a convention for when DMCA notices are required

Recent deletions of photographs, which were officially released by the White House, highlight how some of our most reliable sources of public domain photographs of notable people and current events can be challenged. The process for a copyright holder to challenge these releases should remain simple, but having the decision about our highest profile images being made behind closed doors in a non-legally meaningful and informal procedure does not sit well, and puts undue pressure on volunteers. I propose below that we agree a slightly higher, but reasonably non-bureaucratic, standard for the evidence required for the Commons community to accept that "irrevocable" releases of this type are correctly, and legally, withdrawn with associated public records.

Proposal for a DMCA notice requirement
Photographs or other media uploaded to Commons with reliable evidence of a public domain release from high profile government or government agent sources,1 where an alleged copyright holder has requested a withdrawal of the release, will require a public DMCA notice to WMF legal per wmf:DMCA takedowns. The Commons community may avoid this process in non-controversial cases by consensus in a deletion request, for example where the media is assessed as out of scope for the project.

Notes

  1. "high profile government or government agent sources" includes the White House website, all U.S. Federal agencies or federal funded bodies such as the Library of Congress, Government recognized national agencies of non-U.S. countries such as the U.K. Ministry of Defense (when an Open Government License applies) and widely used state supported sources such as multi-national agencies like UNESCO. Where there may be doubt that this requirement applies, it will be presumed to apply to any media from an official source when raised in a deletion request.
  2. For background on the DMCA refer to Digital Millennium Copyright Act.
  3. Case studies: Official portraits of Donald Trump, Mike Pence official portrait

Votes and discussion

  •  Support as proposer. --Fæ (talk) 10:51, 13 July 2017 (UTC)
  •  Support A step in the right direction. --Yann (talk) 11:45, 13 July 2017 (UTC)
  •  Strong oppose Any agency, government body, or administration run by people not trained in copyright law which releases others' materials which could be covered by copyright law as its own should not be trusted to license those materials properly. It truly saddens me that this includes the current administration of the country to which I have pledged my allegiance. Requiring actual rightsholders to file DMCA takedown notices raises an unfair, costly, time-consuming, and public identity-revealing hurdle or barrier to enforcing protection of their rights, which is not what this project is about; we are supposed to be protecting the rights of actual rightsholders. I agree with Nick.   — Jeff G. ツ 12:38, 14 July 2017 (UTC)
  • Comment. I am not sure what you mean "public DMCA notice"? The law certainly does not require such notices to be public. So, what you are proposing may go against the law. In addition why the reasons for deletions are limited "media as out of scope for the project"? In some cases it may be fairly obvious that the media is not properly licensed. Ruslik (talk) 20:17, 13 July 2017 (UTC)
  •  Support completely agree with nom. Corkythehornetfan (ping me) 21:44, 13 July 2017 (UTC)
  • Oppose  Strong oppose This sound like a good idea, but it might go against our current policies, and might be redundant. Only if we know a media is free, we can store it. Per COM:PRP we should delete files with resonable doubt, and despite the source, that can be gathered by information presented on or off wiki, such as on OTRS. If no such doubt exists (which in the example given it does), we will already not delete it (and refer to DMCAs; if copyright owner claimsit is a violation there is doubt). We should not single out specific sources which can overrule a well-established policy(PRP), which then in turn may make us keep a file where resonable doubt exists just because of the source. f doubt exists we should delete it no matter what. --Jonatan Svensson Glad (talk) 21:48, 13 July 2017 (UTC)
  •  Oppose This is absolutely inappropriate, and the wording Fae has chosen is bloody awful. I would point out, firstly, that the images concerning Donald Trump and Mike Pence were never claimed as a public domain release (i.e resources produced by an employee of the Federal Government). The White House website claims they were released under the CC-BY-3.0 licence whilst the photographer claims he did not authorise their release under the CC-BY-3.0 licence. We're stuck in the middle of a contractual dispute between a photographer and The White House (and possibly, The Trump Organization) but we have no reason to believe the photographer is lying to us. I suppose we could ask for a DMCA notice but that's really not ideal - we're not here to be bloody minded, obstinate and awkward. We exist to provide free and open source content, not just to our sister projects, but also to third party re-users downstream. Those re-users may not benefit from the provisions of the DMCA and may not be eligible to receive a DMCA notice, to force a DMCA notice when a problem is politely brought to our attention is failing those re-users downstream. We should be protecting them by removing material quickly, efficiently and effectively when a legitimate concern is raised, even if a DMCA notice is not immediately forthcoming - that's why we have our Precautionary Principle (which this proposal would effectively undermine).
    The 'public domain release' wording is badly written. UK Government material released under the Open Government Licence is not a public domain release, it's a modified version of the Creative Commons Attribution licence (with which it's compatible) and the same applies for other Government released material from numerous agencies globally, where a standard Creative Commons licence or more general Attribution licences/permissions is provided. This means there's the usual Creative Commons disclaimers, right to terminate the licence etc, which also needs to be factored into this proposal.
    We also know Governments and their employees are often pretty lax at noting an image was provided by a supplier or outside agency. We pretty regularly remove material which comes from a Government feed, but is material we know was created by a third party - one example is excerpts from the manufacturer supplied aircraft maintenance instructions which is reproduced in NTSB and AAIB reports.
    I don't think playing hard-ball is going to be good for us and it's certainly not going to be good for our re-users. We should be encouraging early, open and productive discussion with people who have issues about 'their' material being used on Commons without permission, working to try and persuade them to release under a free licence, to make other material available or to change their policies on re-using material. Deleted material isn't lost forever either, it can be restored if/when clarification is sought and received. I do not think this is a constructive proposal, and certainly don't support it in its present form. Nick (talk) 09:48, 14 July 2017 (UTC)
    Feel free to recommend some wording changes, so it applies more narrowly. I'm not wedded to the specific words and I am not a lawyer. With regard to your comments about DMCA, if the copyright holder asks for a takedown it works, so scenarios you mention where complainants "may not be eligible" sound like courtesy deletions or complaints by non-copyright holders. The WMF, and hence Commons, shall comply fully with the DMCA so long as the project is hosted in the USA.
By the way, nothing in this proposal is "hard ball". It does not bypass the precautionary principle, in fact there's nothing to stop a file being removed in line with our policies even if we ask the claimed copyright holder to raise a DMCA. If a copyright holder really wants to stop a previously mistakenly released photograph from being propagated around the internet, especially after being hosted on Commons for any length of time, then any decent IP lawyer will tell them to fill out a simple, and free, DMCA notice to send to every host that publishes it. --Fæ (talk) 12:21, 14 July 2017 (UTC)
Such advice generally would not be free. The WMF outs complainants' names and websites.   — Jeff G. ツ 13:07, 14 July 2017 (UTC)
The point being that a complainant can waste their time on an IP lawyer, or they can just fill out the free forms. The WMF legal does not always publish everything if there are privacy issues, one could imagine this applying for, say, photographs with nude subjects. If a complainant were in doubt, they can correspond with the WMF about the notice before any public action was taken. --Fæ (talk) 13:13, 14 July 2017 (UTC)
  •  Support All this proposal does is simply make what has always been done in practice MORE efficient. And this benefits BOTH the project and the copyright holders. The way the system has always de facto worked is that when you upload pics from a reliable or official source (e.g. Library of Congress), you go with the license that the site claims it is by default. You simply have to unless you find evidence suggesting otherwise. I don't know the exact statistics, but I bet out of the thousands of public domain images released by government sources, only a relatively very small number get the licensing wrong. Of course you're going to have outliers. And that's when the DMCA comes in as a good tool for this purpose. Spellcast (talk) 12:03, 14 July 2017 (UTC)
  •  strong oppose per Nick, and because the comments by those in OTRS appear to show they have a clue whereas the keep comments at the DRs appear to show a lack of clue. -- Colin (talk) 14:27, 14 July 2017 (UTC)
  •  Oppose "Government and government agent sources" are expected to maintain a higher standard. But here in both cases, they are found to be unreliable. Jee 06:10, 17 July 2017 (UTC)
  •  Oppose Agree with Nick, also per COM:PRP. We don't need to desperately cling to any image that may have been associated with a free license by mistake or where there is a dispute; we should be cautious and always have potential re-users in mind. Gestumblindi (talk) 23:08, 18 July 2017 (UTC)
  •  Strong oppose: This steamrollers basic community principles and is barely even coherent. It's obvious that some people didn't like the outcome of Commons:Deletion requests/Files in Category:Official portraits of Donald Trump and Commons:Deletion requests/File:Mike Pence official portrait.jpg, and that the "solution" is the nuclear option: Take away the right of the community to judge content on its individual merits on-wiki, undermining a basic pillar of every Wikimedia project. The proposal also just poorly-written, with unclear, self-contradictory language. It's a drama bomb waiting to have the fuse lit. So, one at a time:
    1. The principle is awful: This proposal blatantly protects license laundering and derivative works violations by the institutions who are least likely to face any accountability for doing it, under the utterly backwards theory that random lowest-bid web-design contractors who copy-paste a boilerplate licensing phrase from another website months in advance are somehow blessed with government authority to rule on copyright status, and Commons users, administrators, and OTRS members who deal with this sort of thing all day are all fools and need to be ignored. It proposes that the mere whiff of casual government website boilerplate garbage vetoes all the proof in the world, and the only way out is to get some specific copyright owner to harass the Wikimedia Foundation staff with a DMCA takedown notice, which most copyright owners would call legal action. This proposal directly undermines two of Wikimedia projects' basic principles that have been around since the early days:
      • that the burden of proof (verifiability on Wikipedia, licensing on Commons, etc.) is on the person wanting to keep the content, not the person wanting to delete it; and
      • that we do not resort to — let alone force someone into — off-wiki behavior or legal threats/action to get just and fair results on-wiki.
      One of the main reasons for Wikimedia's legal reputation, and why it doesn't get pounded by the copyright lobbyists, is that the Wikimedia projects are known to be self-cleaning: Getting copyright violations removed is nearly as easy as adding them, and the community has been doing this sua sponte since the founding, without even the need for a copyright holder to complain first. This is strengthened by the Commons:Project scope/Precautionary principle, which is that we don't put the burden on the copyright holder or license doubter; we put it on the uploader and those who want to keep the content. Despite Fae's repeated claims (also in previous deletion discussions) that his proposal doesn't violate the Commons:Project scope/Precautionary principle, this proposal is pretty much a direct attack on PRP: The proposal forces administrators to protect files, on the fake theory that "nobody will bother" to care even when lots of people already care, because the copyright holder hasn't actually burdened the WMF in the form of a DMCA takedown. And despite Spellcast's claim, it is not "what has always been done in practice": We've always deleted files that have more than frivolous/nominal doubts. And, more importantly than that, what we have always done in practice is allowed the community to decide individual content on the merits in deletion discussions. And we have always done everything possible to avoid a DMCA takedown on individual items that the community has doubts about. What we have never done is passed a policy that the community and administrators aren't allowed to consider whether content has a proper license or not, or that the community and administrators are prohibited from considering whether the copyright status is valid. We also, as far as I know, have never passed a policy declaring files to be public domain even in the face of evidence to the contrary, without consulting WMF's legal team and having their consensus agreement also (e.g. {{PD-Art}}), or banned an entire relevant topic and forcing all discussion to "go bother the WMF" without consulting the WMF and having their agreement (e.g. emergencies). And before someone says that it won't burden the WMF because there won't be that many files: If there won't be that many, then there's no reason for this new policy, other than to force a small number of files to fit a small number of users' wish to prevent discussion. Prohibiting discussion on a basic element of content is not an acceptable "streamlining" on any wiki.
    2. The wording's poor: The policy's wording itself appears to be misleading in the first sentence, and has self-contradictory clauses that make it interpretable as everything from null and void all the way to open season to ban anyone who nominates potential copyright violations that ever touched anything that vaguely looks like the government. I'm having trouble believing that Fae is even the author: It looks like it's written by someone who has gotten rusty on Commons policy.
      1. It says "reliable evidence of a public domain release from high profile government or government agent sources" but then has a footnote that says that it means "the White House" (which is exactly who consensus already decided was not reliable evidence in at least two cases), "all U.S. Federal agencies" (storm photos from citizen photographers on the NOAA website are regularly deleted on Commons), "or federal funded bodies" (every state and local governments? Planned Parenthood?), "such as the Library of Congress" (everything any Library of Congress division says is possibly public domain, even if it's obviously miscoded at the moment and someone notices it, is reliable and can't be deleted?)
      2. The footnote then says "Where there may be doubt that this requirement applies, it will be presumed to apply to any media from an official source when raised in a deletion request." What is meant by "where there may be doubt ... it will be presumed" — a rebuttable presumption (in which case it's not presumed because it's in doubt), or an irrefutable presumption (in which case it doesn't matter whether it's in doubt)?
      3. "where an alleged copyright holder has requested a withdrawal of the release" — So this only applies when the copyright holder has requested a withdrawal of the release. Excellent: That means we can still discuss and delete government works as copyright violations just like before, since this policy won't apply unless it's the copyright holder that has requested the "withdrawl". Except, something tells me that's not what was intended.
      4. "The Commons community may avoid this process in non-controversial cases by consensus in a deletion request" means it must be unanimous: If it's not, it's controversial; any controversy at all invalidates the discussion. Fortunately, we have the following:
      5. "for example where the media is assessed as out of scope for the project." Commons:Project scope#Must be freely licensed or public domain has obviously been part of project scope for as long as I can remember; I have no idea why Fae (or other long-time users who are voting to support this) wouldn't have caught this instantly. So works improperly declared by a government are still out of scope. So I guess this means this whole proposal is void, since "assessed as out of scope" is declared an explicit example of "non-controversial cases" and therefore "The Commons community may avoid this process" all the time. (Again, something tells me that's not what's intended.)
      So, in summary: This proposal is so badly worded as to be interpretable multiple ways at once, the result of which will be that people will nominate files without regard to it, administrators will start banning people for doing it, and what the community will do every time this happens will be exactly the opposite of "efficient". And in case it's not obvious, this policy means that the only route for normal users, bureaucrats, and OTRS members to appeal will be to bother the Foundation directly, which will probably make the WMF think that if Commons is willing to sign away their own scope, ban reporting of copyright violations on-wiki, and assign more burden (forcing DMCA as easiest path) to the Foundation staff without asking first, maybe Commons isn't fit to do its own job right now. --Closeapple (talk) 06:09, 19 July 2017 (UTC)
in conclusion: we have an un-elected clique at OTRS, who make decisions in secret, and who speedy delete, out of process. their workflow is broken, with large backlogs, because they are not open to new users who do not share their values. how expeditious; how efficient. better admin lock the deletion discussion, so uninformed non-admins cannot rage against the machine. do not know why people would not prefer this process to a DMCA. such a preference for a out of commons process must be out of order. there is a fight to be had here, about the fraudulent use of a CC license; but that is not our fight; we prefer to fight with the national portrait gallery, london.
"maybe Commons isn't fit to do its own job right now": they already think that - but we cobble together wikimedia with the commons we have; not the consensus collegial commons we might want. Slowking4 § Sander.v.Ginkel's revenge 18:29, 20 July 2017 (UTC)
What do you mean by "out of process"? Who are these admins who you claim are locking deletion discussions? And do you complain about secret decisions when a file is kept because of an OTRS ticket also? We don't make those people who give permission post their real identities and proof of ownership publicly either. --Closeapple (talk) 02:13, 23 July 2017 (UTC)
converting a DR to speedy without consensus, is out of process. here is a user page admin lock, where deletions are pre-determined Commons:Village_pump/Archive/2016/12#Governance_of_page_protection_rights - OTRS has a credibility gap. at least a DMCA has the name of the person prepared to go to federal court. but why be open, when you can cram down. Slowking4 § Sander.v.Ginkel's revenge 17:53, 24 July 2017 (UTC)

July 15

Mock-ups or scale models

Because of my poor English I cannot get the difference between "Mock-ups" and "Scale models" (1:1 for example). Can you please tell me, shoud this (c:Category:Mock-ups of Sputnik-2) category be named as Mock-ups or Models of Sputnik-2 (in this case scale is 1:1)?‎ --Stolbovsky (talk) 22:09, 17 July 2017 (UTC)

  • If it's 1:1, we wouldn't usually call it a "scale model" and even "mock-up" or "model" would be a bit unusual. Typically "replica". - Jmabel ! talk 23:30, 17 July 2017 (UTC)
    • I think it's a question of timing and usage. Mock ups happen early on in the design process. They may not be to scale or reflect the final realised design, omitting many details. Scale models are produced after a design has been finalised. Railwayfan2005 (talk) 20:37, 24 July 2017 (UTC)

Tech News: 2017-30

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • CSS in templates will be stored in a separate page in the future. This will make it easier to make templates look good on mobile devices. This now works on mediawiki.org and Wikitech. It will come to more wikis later. [18][19][20]
  • .mw-ui-constructive modifier class is deprecated and has been removed. [21]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 July. It will be on non-Wikipedia wikis and some Wikipedias from 26 July. It will be on all wikis from 27 July (calendar).
  • It will be possible to restrict who can send you notifications on a wiki. This new feature will accessible in your preferences, in the Notifications tab, on Wednesday, July 26. Please see the documentation. [22]

Meetings

  • You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 25 July at 19:00 (UTC). See how to join.
  • You can join the Wikimedia Foundation July 2017 Metrics & Activities Meeting. The meeting is about how Wikipedia and the Wikimedia movement are perceived and understood by the world. The meeting will be on 27 July at 19:00 (UTC). See the agenda and how to join.

Future changes

  • New Filters for Edit Review, at the moment available as a Beta feature, will be released by default for the Recent Changes in September.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:57, 24 July 2017 (UTC)

July 25

Category:Nocturnal Culture Night 11...

Hi all.

A new user (@Stefan Bollmann: ) added almost 400 files in a mother cat' so now they're all in double in sub-cat (p.e.: File:Alec Empire Nocturnal Culture Night 11 2016 05.jpg is in Category:Alec Empire - Nocturnal Culture Night 2016 subcat of Category:Nocturnal Culture Night 11 added in Category:Nocturnal Culture Night 11) and I don't know where he's from to tell him in his native language (to be sure he'll understand) the rules of categorization. They were alrea&dy well cat' before...

May be a bot can undo what he did but I DON'T want to do that because that takes too many time.

Thanks a lot. --lol LW² \m/ (Lie ² me...) 16:58, 20 July 2017 (UTC)

Hey, you joker. I'm not a new user, I am the photographer and uploader of all the files and the creator of the origin category (and many others you destroyed in the past with your sub-categorizing fetish). Your annoying creating of sub-categories within the artist categories and especially your file-moving and draining of the origin category destroys all of the statistics, who are important for the project Wikipedia:Festivalsommer of the German wikipedia. We need for our evaluation the usage statistics (with the GLAM tools [23] (tool server unfortunately down at the moment)) for the festival photos per festival. But if someone comes along and drain the festival category the statistic works not anymore, because the category has 0 files. :( Thats very bad for our work. It makes no sense and is not practicable for (in this example) 46 sub-categories to get for each audience of each band a single statistic only for one festival, that we want to add at least to one statistic per hand work. We have one category per event and want the whole statistic for all pictures from this event. That's why it is very important, that all pictures stay within the original ca tegory, whatever categories the files get additional.
For this reason I added for each picture the origin category again, so the category is no more empty and statistics are available (if the tool server is new started). Because I thought, you are a big fan of this (in my view mostly superfluous, but that's another issue) sub-sub-categories, I made a compromise and have not drained your sub-sub-categories, but add only the origin category. So you lost nothing (all your sub-sub-categories stay full with files) and I lost not so much. Almost a win-win situation. For you in any case.
Greetings and I hope, you can now better follow, whats the problem with your kind of categorizing. Sorry for my little harsh chant, but I'm quite pissed off at the moment, because you made my work so hard. --Stefan Bollmann (talk) 21:53, 20 July 2017 (UTC)
Stefan Bollmann, IMHO subcategories are usually very usefull. For a compromise you could better create some "hidden" category for your technical needs and there will be no problem --Stolbovsky (talk) 22:24, 20 July 2017 (UTC)
The Project runs since 5 years. Sorry, but it is not workable for hundreds and hundreds of festival categories to create retroactive hidden categories und hundreds of new statistic links. Maybe in future times. We have this to discuss in the project. Furthermore I have suggested a compromise: The files can be sub-categorized a thousand times - I don't mind - only one main issue: they also stay in the original festival category. There is absolutely no need (or any rule) for empty festival categories. Greetings --Stefan Bollmann (talk) 22:43, 20 July 2017 (UTC) (Next two days I will not be online, I answer after my vacation to upcoming discussion input.)
By Commons policy, with some very rare exceptions (which don't apply here), an image doesn't belong in both a given category and one of its parent (or grandparent, etc.) categories. If you want something that will stay there for a purpose other than Commons' general purposes, public categories are a bad choice. You can create a set of "hidden/user" categories for this, or you can create one or more templates that use something other than our category system, but you don't get to decide that the category system works differently in "your" area. - Jmabel ! talk 00:38, 21 July 2017 (UTC)
Stefan Bollmann, the GLAM tool you linked to, it has a function "Search depth" which presumably allows you to configure how many subcategories can appear in your results. If you are getting 0 categories as a result, perhaps you have not yet modified this field to show subcategories. If this works, this is a best of both worlds scenario. seb26 (talk) 01:13, 21 July 2017 (UTC)
Hi @Stefan Bollmann: you please me calling me 'Joker' . I didn't get deep in your history to know what you did before on Commons but I just saw your account is new (all is in red); may be you use many accounts but that's none of my business. All I see are those 400 files (and may be more)...
That's not my «fetish» or my «kind of categorizing»: I only follow what was done before for many other concerts cat' to harmonize thousand and thousand files. In this case YOU destroyed (kind of vandalism for some of us, no?) what was done.
Now, you have some explanations about GLAM and you know what you have to do to make it rolling, don't you? And, of course, undo this double categorization.
Thanks to @Stolbovsky, Jmabel, and Seb26: for their lights on this case. Have a good weekend, evryone. lol LW² \m/ (Lie ² me...) 22:10, 21 July 2017 (UTC)
So, back again. Glamorous still don't work. I think we discuss the usefullness of suggested solutions (hidden category, adapted search depth ...) better, when the statistic tool runs again. Generally meaning of 100% sub-categorizing should (in my opinion) not be part of this discussion, because it's another field. --Stefan Bollmann (talk) 12:00, 23 July 2017 (UTC)
Glamorous works now again. With search deep 2 the category statistics works. This issue should be ok now. --Stefan Bollmann (talk) 17:52, 25 July 2017 (UTC)

July 21

Please, fix this jpg file

Hello, I've just found that one of satellite photos is currently rotated upside-down (i.e. south is up and north is down) this is the file: File:Мерц6.jpg. This is proof, that it's rotated: https://www.google.com/maps/@42.185443,79.8611786,20537m/data=!3m1!1e3 . Could you please fix it? — Preceding unsigned comment was added by 213.145.139.2 (talk) 07:16, 25 July 2017 (UTC)

Arnold Genthe Collection

The Arnold Genthe Archives is mostly Public Domain at the Library of Congress (http://www.loc.gov/pictures/collection/agc/), but there are some photo marked as "Rights Advisory: Publication may be restricted. For information, see "Arnold Genthe . . .," http://www.loc.gov/rr/print/res/073_gen.html". I inquired few days ago, again, about these photos with the LOC and the answer is below: 1) the 70 year rule would only apply if the images were not a work for hire, and that's precisely the element that is in doubt and why the rights statement mentions that whatever client information we were able to find, we recorded in the catalog records. 2) If the work was done by Genthe not for a client, you're correct that the should be no restrictions on publication. If the work was done for a client, however, it was a work for hire, and the term of copyright in those circumstances is 95 years from publication or 120 years from creation, whichever is shorter (see the section labeled "Situations Where the Image Was Made "For Hire" or Is an Anonymous or a Pseudonymous Work" in the discussion of duration of copyright http://www.loc.gov/rr/print/195_copr.html#duration in our overall guidance document on assessing the risks of using an image from our holdings (the document also references relevant U.S. Copyright Office circulars to read more about it). You didn't specify the image in which you are interested, but some images are getting close to the 95 year mark if they can be assumed to have been published. 3) We have had one researcher assert that Genthe no longer did work for hire after he moved to New York in 1911, but we have been unable to verify that. The only other information I can offer towards your risk assessment is that we have never been contacted by anyone asserting copyright to images made by Genthe for hire. Conclusion: all photos before 1922 (as of 2017) are in Public Domain. Photos after 1922 for which there is a "Publication may be restricted" notice maybe not in Public Domain, but a) Genthe's experts said Genthe did not perform work for hire after 1911 and b) no one of the heirs of people on those images contacted LOC for copyright (considering that many of them, like Alice DeLamar and Marion Carstairs do no have direct heirs).--Elisa Rolle 15:53, 25 July 2017 (UTC)

95 and 120 years are maximum possible terms. They may be significantly shorter if a work was published, for instance, without a notice or not renewed. This depends on the date of publication. Ruslik (talk) 17:00, 25 July 2017 (UTC)
Yes, that is the point Ruslik, considering Genthe is died in 1942 and that he did not probably do work for hire after 1911, it is quite safe to say all the LOC collection is Public Domain, and that is what the LOC's librarian wanted to convey with their answer. But it was questioned if some of those photos were safe and therefore I asked, again, the opinion of the LOC.--Elisa Rolle 17:28, 25 July 2017 (UTC)

Category:People by initials

Is this category a good idea? --84.61.154.157 20:41, 25 July 2017 (UTC)

Strange category redirects

I've stumbled upon a few categories redirected in a strange style (using both "#REDIRECT [[Category:...]]" and "{{Category redirect|...}}" on the same page); I decided to fix them (by removing everything except the "{{Category redirect|...}}" from the page).
I've also contacted the author of those strange-style edits (User talk:Beyond My Ken#Category redirects); he said that "one redirect is not sufficient" and reverted my edits (Category:Elastane, Category:Elastane fibers).
Some expert advice would be welcomed. --Djadjko (talk) 01:02, 20 July 2017 (UTC)

P. S. I can't find an official category redirecting guide on Commons (Commons:Redirect gives some clues... But Commons:Only use category redirects where necessary is just a point of view, and an outdated one; Commons:Rename a category is about renaming). Commons really should have something like w:WP:R#CATEGORY policy, while the possible functionality bugs should get reported and fixed in an appropriate way, to prevent further creation of user-generated essays, workarounds and even invention of dirty hacks :) --Djadjko (talk) 21:36, 26 July 2017 (UTC)
  • I certainly favor the soft redirect. @Beyond My Ken: can you explain why you disagree? - Jmabel ! talk 04:37, 20 July 2017 (UTC)
  • From what I understand, the reverter is annoyed by not landing directly on the destination category page when only a category redirect (=soft redirect) is used. #REDIRECT (=hard redirect) does just that. The soft category redirect is essential for bots to move pages to the target category; the hard redirect is more of an optional user preference. Having read Commons:Only use category redirects where necessary, I do wonder what the effect on the bots' transfer work is when a hard redirect is in place additionally. Couldn't find that anywhere though. --HyperGaruda (talk) 04:45, 20 July 2017 (UTC)
  • The explanation, which I had to give repeatedly over the years, is currently sitting on my talk page. Until the deficiencies in the system are corrected, both redirects are required in order to gain full redirect functionality. Beyond My Ken (talk) 05:15, 20 July 2017 (UTC)
  • This is my explanation from May 2016, referring back to a previous explanation:

    OK, here's what I wrote a few months ago:

    For instance, Category:23rd Street, New York City redirects to Category:23rd Street (Manhattan). If I put "Category:23rd Street" in the search box, I get a list of possible categories, headed by Category:23rd Street, New York City. So far, so good. However, if I click on Category:23rd Street, New York City, and it doesn't have a hard redirect, I get sent directly to the "New York City" page [with its category redirect] and not to the "Manhattan" page. To go there, I have to click on the category redirect. If, however, the "New York City" category has a hard redirect, then when I click on it from the list of possible categories, I am sent directly to the "Manhattan" page, which is where I want to be. The problem is that the category redirect is too soft to send me there.

    As I recall, the same thing is true of the Commonscat box on Wikipedia. If the Commonscat link sends me to a category redirected cat, I land there, but if that cat has a hard redirect, I'm sent to the redirected page. In short, the "category redirect" template needs to be rejiggered so that it will make those redirects properly. Until then, both the hard redirect and the category redirect are needed to provide a redirect under all circumstances.

    Beyond My Ken (talk) 05:18, 20 July 2017 (UTC)
@--ghouston, I see the Manhatten cat in the results - see here.
@Beyond My Ken, thats exactly the behavior which is intented by the soft redirects, because, if images or other pages are categorized into it, and people klicking on it they dont wonder why the page they just came from is not in the category but the hint where the correct cat is located and the image they came from. Thats the reason why hard category redirects are "forbidden" in most wikis including commons.
regards --JuTa 06:59, 20 July 2017 (UTC)
Sorry, but I don't understand that - can you be more specific? Beyond My Ken (talk) 13:16, 20 July 2017 (UTC)
What I understood was if you land on a category redirect page, and are whisked away from it, there are chances that you won't be able to see the contents, pages/images that are currently incorrectly categorised into that category redirect, and if you came from category X and you are redirected to Y, you will not see the page you clicked on inside the contents of Category Y. seb26 (talk) 14:31, 20 July 2017 (UTC)
The template-style redirect turns into a subcategory if it's non-empty, so the contents are still available. --ghouston (talk) 21:54, 20 July 2017 (UTC)
I.e., that's only an objection to using the hard redirect on it's own (assuming the presence of the hard redirect doesn't somehow mess up the functionality of the template-style redirect). --ghouston (talk) 21:59, 20 July 2017 (UTC)
@Seb26: Click on Category:23rd Street, New York City. You are redirected to Category:23rd Street (Manhattan). Below the category name, you will find "(Redirected from Category:23rd Street, New York City)". Click on "Category:23rd Street, New York City". You will be shown https://commons.wikimedia.org/w/index.php?title=Category:23rd_Street,_New_York_City&redirect=no, which currently shows a hard redirect, a soft redirect, and no pages or files. This can be done with any hard redirect, or you can add "?redirect=no" to any hard redirect's main URL.   — Jeff G. ツ 04:55, 21 July 2017 (UTC)

Redirections in categories once more...

A new fashion of adding stright redirections to the redirected categories is still going on... It is nonsense to add redirection next to the {{Category redirect}}. We have millions of such categories. We should add it to the template or give up... Wieralee (talk) 08:56, 25 July 2017 (UTC)

I agree that "#redirect" is not necessary on redirected categories. Ruslik (talk) 16:48, 25 July 2017 (UTC)
Following up on my little test where I moved one file into the both hard- and soft-redirected category, it seems RussBot has no trouble registering "23rd Street..." as non-empty, so I don't see any technical reason to ban hard category redirects. In fact, I noticed that putting something in a hard-redirected category makes that category appear in italics, warning the editor something is not right. --HyperGaruda (talk) 18:26, 26 July 2017 (UTC)

The ghettoization of women continues

In Category:Jazz composers, buried under the letter "F" is Category:Female jazz composers. There is, of course, no corresponding Category:Male jazz composers. So if you look very carefully, you can find the women; otherwise you are presented with a list of over 200 names, all or nearly all male.

When I've called out similar things before, I've been told that this is somehow feminist, in that it makes it easier to find just the women in a field. I call bullshit. Yes, it may make it easier to find women if you are very specifically looking for women. For every other use, it makes the field look all male, unless they look very closely.

Further: what does gender have to do with being a composer that it should call for an entirely separate category? I understand separating out vocalists by gender, because with very rare exceptions male and female vocalists sound very different, and it's one of the first things you notice about a singer. But composers?

In the unlikely event that this separation is really what the community wants, then male jazz composers should also be "down a level". As it stands, this is ghettoization, pure and simple. - Jmabel ! talk 16:34, 23 July 2017 (UTC)

  • Thank you for taking care of this issue. I agree that something has to be done here. I'm afraid that due to the nature of Wikimedia Commons as being a multilingual website with a worldwide user community it simply can't be assumed that everyone comes here with an understanding that women have to be treated equal. By sorting them out into subcategories as it has been done at the categories for composers this is absolutely not the case. I don't want to blame anyone here. Many users may simply sort new content into an existing category sheme without thinking. As a matter of fact in many countries it is not normal that there is nothing special about it when women perform certain jobs. In some countries women are not even allowed to work at all (exept for taking care of the household at home). Just yesterday I saw a documentation about Bangladesh: In most families the husband can decide about everything. If the men don't agree, women are not even allowed to leave their home. Many Commons users live in countries with a whole different unterstanding of gender roles. These understanding sometimes comes visible within their contributions here. This simply can't be ignored or discussed away. In my opinion gender equality should become an official policy on Wikimedia Commons. Due to the worldwide community it can't be taken for granted without an official agreement. --Zaccarias (talk) 17:33, 23 July 2017 (UTC)
  • Language ≠ country
  • Single person ≠ their country’s average
Enjoy your Splash Damage award. -- Tuválkin ✉ ✇ 00:51, 24 July 2017 (UTC)
  • On English Wikipedia, there are sometimes what are called "non-diffusing categories" for women in fields where they have been historically less represented. The women stand alongside the men in, for example en:Category:American diplomats, and they are also in the non-diffusing sub-category en:Category:American woman diplomats. The converse is true as well, as in en:Category:Male feminists. That might be what was intended here, rather than ghettoization. For the sake of simplicity, ease of navigation, and avoiding conflict I would prefer that we not do this, and instead always treat female and male categories equally. Guanaco (talk) 17:57, 23 July 2017 (UTC)
  • Jmabel, I think (or rather, I hope!), that the resulting ghettoization you complaint against (and correctly so!) is not the original intent, but rather the result of clumsy attempts at diffusion: Someone notices that Category:Jazz composers is getting too crowded and decides to split its contents into subcats. So far so good (well, mostly, but lets keep this story short), but instead of splitting Jazz composers by any meaningful criterium (or criteria!), the category is split in the simplest, laziest possible manner — by gender. I would prefer to have a seriously researched and mantained sub cat tree splitting these by musical subgenres and/or historical period. Category:Jazz composers by gender is only sensible if among a good handful of other such Categories:Jazz composers by …. -- Tuválkin ✉ ✇ 00:51, 24 July 2017 (UTC)
  • There's no way to stop people making intersection categories. Category:Jazz composers could no doubt be split multiple ways. I don't think there's any real solution apart from waiting for a user interface based on structured data. I suppose it wouldn't be hard to write a bot that could maintain intersection categories using properties from Wikidata, and I suppose keep them in sync with useful flat categories, but I'm not sure if it would be worth it at this point. --ghouston (talk) 02:05, 24 July 2017 (UTC)
  • Look, we split Category:Skyscrapers by height, we split Category:Years by month — it’s logical that Category:Jazz composers should be split by musical subgenre, or maybe by historical period, if subgenres of jazz, or the assignment of each composer to a jazz subgenre, turns out to be impractical.
Appealing to wait up for everybody’s most loved / most hated piece of vapourware is not the way to go, though.
-- Tuválkin ✉ ✇ 10:46, 24 July 2017 (UTC)
I agree completely with User:Jmabel. If, however, someone is categorizing wrongly and continues this way without making (and filling!) a category Male whatever my protest has always been simple: (example) re-adding the category Photographers from Austria to the female photographers. If someone might object ("over-categorization!"), you can plainly answer that it is of course no over-categorization as long as the category Male photographer from Austria doesn't exist or is only filled up to 20% or so. Don't let women be marginalized. Vysotsky (talk) 13:51, 24 July 2017 (UTC)
  • When you have a Category:Photographers from Austria and a Category:Female photographers from Austria but no Category:Male photographers from Austria, who is being marginalized are the Austrian men who are photographers, because they do not appear under the category:Men of Austria by occupation: Right? --E4024 (talk) 14:10, 24 July 2017 (UTC)
  • I disagree that there is any malicious discrimination happening here. The correct answer to this is USD 10 million for Commons:Structured data. The prejudice is based in software infrastructure. Wikimedia projects have an obligation to users to permit research of biographies by demographic, so if someone wants to search by race, gender, sexuality, religion, nationality, etc with the intersection of career, accomplishment, residence, or whatever else, then users should have a path for doing this. The original high-profile New York Times story in 2013 about novelists was misguided because of course there is such a thing as "promotion of a demographic in a career field", and with Wikipedia's current software, creating a category is the way to actualize that. If there is a "women in jazz" category then it is because someone is promoting women in jazz, not because of exclusion from other categories. It makes no sense in Wikimedia projects to put someone in a specific category and simultaneously all parent categories. The core of the problem is that software cataloging is expensive and what seems like a small problem actually requires 10 million dollars that only now we received. When structured data is actualized then all category intersections on Commons will go away, and so will the problem. There should be a category for "jazz players" and categories for "male", "female", and anyone who wants to combine the two should combine them. Blue Rasberry (talk) 15:56, 24 July 2017 (UTC)
  • (Edit conflict) Ten million dollars to be spent in vaporware that does nothing now and will still be doing do nothing once that amount is exhausted in “outreach campaigns” and other such pretend work. Meanwhile, human-powered categorization done by volonteers working for free in their spare time will go on improving, little by little, the semantic web linking together all Commons’ content. (I really don’t know anything about jazz, or else the op discussion would be moot by now.) -- Tuválkin ✉ ✇ 19:27, 24 July 2017 (UTC)
  • You are not addressing the main issue. There are many (too many) Wikipedians making categories like Category:Female composers from Italy WITHOUT making categories Category:Male composers from Italy while at the same time REMOVING the female composers from the Category:Composers from Italy. And this happens everyday in Wikimedia Commons, thereby literally removing women from thousands of main categories. Though this may be done with the best intentions, the outcome makes Commons less useful -and very old-fashioned and mediocre. We need an honest discussion about this way of working. Vysotsky (talk) 18:31, 24 July 2017 (UTC)
  • I agree that is the main issue here and it needs fixing. Seems that nobody disagrees with that, either, so we’re only facing these two options:
    1. Either create complementary categories for Male so-and-so (either by
      1. splitting in twain its parent Category:So-and-sos, or
      2. creating an intermediary parent Category:So-and-sos_by_gender, allowing for better gender categorization at this level and non-gender related categorization at an upper level, with concurrent Category:So-and-sos_by_this-or-that), or
    2. ignore gender altogether for most categories of humans and undo all Category:Female_so-and-sos, moving its contents back to the parent cat.
I think I prefer solution 1.2. What about you lot? -- Tuválkin ✉ ✇ 19:27, 24 July 2017 (UTC)
Good summary, clear options. I would also go for solution 1.2. Vysotsky (talk) 20:33, 24 July 2017 (UTC)
I don't see 1.2 as being necessary (feels like just more make-work), though I feel something from 1.# is the way to go. Simply adding the male and female subcats to the parent cat with an appropriate and standardised sortkey would solve the problem of either subcat getting lost in the forest, which was one of Jmabel's original complaints. I would suggest something like "| Gender" to keep them both side-by-side in the parent category. — Huntster (t @ c) 21:27, 24 July 2017 (UTC)
I'd say: nuke all gender-specific subcategories. Instead establish a limited set of high-level categories:
  1. Category:Humans by gender
    1. → Category:Female_humans
    2. → Category:Male_humans
    3. → possibly further categories for transgender etc.
Every picture showing a human gets sorted into one of these categories, no further sub-categories like "females by occupation", "males by haircolor", "firefighters by gender", etc. If you want to find all female carpenters, just do a category intersection of Category:Carpenters with Category:Female humans using FastCCI or whatever tool you like best. The same goes for other high-level qualifiers. I'm sick and tired of having to click my way through paths of increasingly obscure intersection Categories to find a suitable image for something. --El Grafo (talk) 12:16, 25 July 2017 (UTC)
I largely agree, but I think that's probably a bit too extreme. I think there are a few things (vocalists, actors) where gender really is that significant. But very few. - Jmabel ! talk 15:15, 25 July 2017 (UTC)

@Bluerasberry: I didn't say this was intentionally malicious—I am talking about an effect, not an intention—and I don't have 10 million dollars lying around. I would be happiest with solution 2, willing to accept solution 1.2, not interested in discussing infeasible solutions or worrying about people's unfulfilled intentions. - Jmabel ! talk 23:52, 24 July 2017 (UTC)

Agree with points made by BlueRaspberry and El Grafo, though El Grafo's solution isn't in keeping with current category implementation policy. Gender and occupation are not attributes that make for reasonable subdivisions. For those determined to waste their precious time on earth organizing media files using a totally broken system, the only reasonable choice is 1.2 above -- there's nothing special about grouping jazz players by gender vs any other random category you might pick, so have a "by gender" intermediate group so that "by xyz" can freely be added by people interested in various xyz attributes of jazz players. Ultimately, this all needs replaced by something sensible, where intersections are done by the search user, not by Commons users trying to second-guess what may be useful. -- Colin (talk) 14:05, 25 July 2017 (UTC)

I´d go for Tuválkin´s option 2 (aka El Grafo´s "nuke them") if all subcategories for individual people are copied to Category:Men by name or Category:Women by name, thus making sure that the information about gender is retained close to the root of the category tree. If you want a list of the categories of female jazz vocalists, you can get it easily as long as Category:Women by name is well-maintained. Splitting the whole category tree along men/women doubles the number of people categories and clearly doesn´t work: Most of the "by gender"-subcats are practically useless as they are poorly maintained, illogical and unreliable. --Rudolph Buch (talk) 14:09, 25 July 2017 (UTC)

If you want to see where (in principle very useful) categorization has led us, just check Category:Photographers. If I would like to find a photographer whose name and country of origin I vaguely know (was he from Hungary or Austria?), I could look in 4 categories: Photographers (with the left-overs), Male photographers (practically empty), Photographers by name or Photographers by country. Mind you: he could really be in one of these 4 categories. I would like to have one home category, containing all photographers (perhaps the category:Photographers?), and I really don't care how many sub-categories there would be. I can afford a smile looking at categories like Female photographers from India or Photographers using Leica cameras, but I don't mind, just as long as photographers in these categories are not removed from the home list. Vysotsky (talk) 15:36, 25 July 2017 (UTC)

While we're on the topic of ghettoization and discrimination, I'd just like to point out that we've had Category:African American criminals around for over seven years. —LX (talk, contribs) 10:47, 26 July 2017 (UTC)

July 24

Watchlist:Database error

Hi, since a couple of weeks I get an error message like this one when I attempt to check my watchlist:

A database query error has occurred. This may indicate a bug in the software.
[WXhEMgpAMFAAAL@zCgEAAAAO] 2017-07-26 07:27:42: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

It occurs 9 times of 10, both on Internet Explorer and Mozilla.

Is this a known bug, do other users experience the same problem?

Thanks for your time --Jwh (talk) 07:34, 26 July 2017 (UTC) @Jwh: Can you access Special:EditWatchlist/raw? You might try backing up your watchlist, then clearing it with Special:EditWatchlist/clear. Guanaco (talk) 19:29, 27 July 2017 (UTC)

Thanks @Guanaco: . Got to the raw part, but when I went to the "Clear" I got this:

Database error To avoid creating high replication lag, this transaction was aborted because the write duration (4.9122259616852) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead. [WXpB5wpAADoAAJE2SnYAAACW] 2017-07-27 19:42:31: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

Is my Watchlist too big? --Jwh (talk) 19:57, 27 July 2017 (UTC)
@Jwh: Probably. I would open a phabricator ticket with as much info as you can provide, including the raw watchlist as a text file. Guanaco (talk) 20:01, 27 July 2017 (UTC)
@Guanaco: T171898 - Thank you for the suggestion! --Jwh (talk) 23:23, 27 July 2017 (UTC)

Latest of countless problems with UW, just now saying something

I don't think I have to tell you that Upload Wizard is a piece of shit, obviously designed to slow down those of us who know what we're doing. Since it's been implemented, there have probably been times when I've had more aborted uploads than successful ones. I went looking through the list of alternatives and couldn't find anything that was any better for my low level of uploading. I managed to figure out a trick where I can upload the files, leave the description fields open in a tab, work on them at my leisure (including when I'm offline) and come back and upload them the next time I'm online. In recent months, I've been away from "civilization" enough to where I've had to leave my laptop in storage for extended periods of time, despite having an upload queue ready for many months of nearly 500 files. This past week, I've had time to go through some of that. I prefer to write out file descriptions and add categories for all fifty files when I upload so I don't have to come back to it, which is the difference between a mindset of being stuck treading water forever and one of trying to move forward (it also helps to facilitate the various topical new file pages). Still, sometimes I just don't have that much time in one sitting and need to come back. The other day, I uploaded the first fifty with no problem, using the method I described. I tried uploading another fifty, again doing the same thing. From what I can tell, I took too long between the two steps. Not only did it apparently discard the files at some point, but due to that it immediately discarded the descriptions upon uploading. The bottom line here is that I won't waste that much time again, because UW has caused me to waste too much time as it is. This community is evidently happy with a few users dumping files of questionable educational use (read: U.S. military propaganda and the like) by the untold thousands or perhaps millions, while imposing burdens on the rest of the community, and it's been like that for years. So, if you really want that kind of content but you don't want content contributed organically such as what I'm doing, just go ahead and let me know by not helping me. Hopefully, saner minds are still to be had around here.RadioKAOS (talk) 09:01, 26 July 2017 (UTC)

i would use Commons:VicuñaUploader or Commons:Pattypan - UW is designed for newbies and is very proscriptive. does not work for me for more that ten files at a time. Slowking4 § Sander.v.Ginkel's revenge 18:08, 26 July 2017 (UTC)
I mostly use Special:UploadWizard for my uploads and I do not have much issues with it. I upload in batches up to 500 files. --Jarekt (talk) 11:37, 27 July 2017 (UTC)
Is it possible to have a discussion on Commons without someone expressing their hate for WMF and offending others who have different needs? Upload Wizard is heavily used, used successfully, and is especially useful for projects like the "Wiki Loves" outreaches that bring in so much new original material from so many new photographers, that it generates a large spike on various Commons statistics. It is mainly aimed, I would suggest, at new users and low volume uploads. I used it for many years but now use LrMediaWiki Lightroom plug-in which has some advantages for me. Since Lightroom is a "Digital Asset Management" tool, it might be useful to you in organising your photos and in giving them descriptions, titles, categories, licences, etc, etc. Then you just select the files and export to Wiki. -- Colin (talk) 11:53, 27 July 2017 (UTC)

Add-{{information}} gadget down

At least in the past few days, when called https://tools.wmflabs.org/add-information/ does nothing. -- Tuválkin ✉ ✇ 00:17, 28 July 2017 (UTC)

Strategy discussion, cycle 3. Challenge 5

There are only three days left (plus today) to take part in Cycle 3 of the Wikimedia strategy discussion. Insights to the last challenge our movement is facing has just been published. The challenge is: How does Wikimedia meet our current and future readers’ needs as the world undergoes significant population shifts in the next 15 years?

The previous challenges are:

  1. How do our communities and content stay relevant in a changing world?
  2. How could we capture the sum of all knowledge when much of it cannot be verified in traditional ways?
  3. As Wikimedia looks toward 2030, how can we counteract the increasing levels of misinformation?
  4. How does Wikimedia continue to be as useful as possible to the world as the creation, presentation, and distribution of knowledge change?

On this page, you may read more, and suggest solutions to the challenges. Also, if you're interested in related discussions that are taking place on other wikis, please have a look at the weekly summaries: #1 (July 1 to 9), #2 (July 10 to 16), #3 (July 17 to 23).

In August, a broad consultation will take place, but it'll differ from what we've been conducting since March. This is your last chance to take part in such a discussion! SGrabarczuk (WMF) (talk) 17:45, 28 July 2017 (UTC)

July 29

Flickr images / paid editing

The following types of images raise concerns for me. Basically what we have is paid editors creating a flickr account, adding the image they want to upload to this account. Then uploading to Wikipedia using the flickr account as justification that the image is under an open license.

We have no verification that they have gotten proper release to release the image under an open license on flickr. Looks like a way to simple side step OTRS and better copyright release verification. Doc James (talk · contribs · email) 16:30, 25 July 2017 (UTC)

From Commons' POV the essence of this is an old phenomenon. FDMS 4 16:46, 25 July 2017 (UTC)
Does commons have a process for reviewing license laundering? Appears to be being done by arms of undisclosed socks.
What we need is a bot to highlight all uploads with Flickr as justification from Flickr accounts with few / no other images.Doc James (talk · contribs · email) 17:14, 25 July 2017 (UTC)
"Paid" isn't really the key, license laundering is. If you find a version that appears to be the real origin of the photo, report it as a copyvio; it's presence on Flickr is really neither here nor there. - Jmabel ! talk 23:30, 25 July 2017 (UTC)
User:Jmabel Sure that picture is here[24] I do not believe the subject of the picture took the picture themselves. I also do not beleive this flickr account is theirs[25]. To summarize their is no evidence that the image is actually under an open license / been released by the photographer. Doc James (talk · contribs · email) 22:14, 28 July 2017 (UTC)

Hi James. I sort of did this a long time back with User:Faebot/Flickrstreams_of_concern. It was updating every hour, sniffing out doubtful new uploads shortly after they were created. I stopped maintaining it due to a lack of interest, well nobody complained when it stopped working, and the fact that the list used for stopping more uploads from bad Flickrstreams is run as sysop edits only, for reasons that don't seem very good ones to me, speaking as a contributor who might otherwise have automated adding the most obvious cases. I'm a bit tired of even attempting these types of tests to improve the project as in general I get significantly more criticism for my volunteer time spent here, compared to support or encouragement. I guess that as a community we expect long term contributors to say and do less and less that could result in improvement or change, the longer they stay. Certainly I have been told that a key reason I'm not an admin and may never be one, is that I have openly criticised poor decisions by some admins, rather than just manipulating events in closed chats on IRC; these days I rarely do either. --Fæ (talk) 18:38, 26 July 2017 (UTC)

Doc James, you might want to look at Commons:PAID. Commons basically doesn't care about paid editors. WhatamIdoing (talk) 22:01, 28 July 2017 (UTC)
User:WhatamIdoing I realize that Commons does not care about paid editing. The issue is more one of unverified copyright. Often the author is stated as the subject of the image.
User:Fæ I think you do great work. That you are not an admin here is unfortunate. To the list you have created it would be useful to identify whether or not the flickr accounts the images are from have more than a couple of pictures as this will indicate more likely that license laundering is occurring. Doc James (talk · contribs · email) 22:07, 28 July 2017 (UTC)
In the example "2016 Jul 12 09:06 142255532@N04 justincwinter (4 hours, 2 photos)", the "2 photos" means the Flickr account only has 2 photos in it. Keep in mind this is not an active report, if there was enough interest, I would have to do a bit of work to get it running again. --Fæ (talk) 22:33, 28 July 2017 (UTC)
Cool. Definitely useful. Would love to see it updated User:Fæ. Seems like a high proportion of them were deleted so good true positive rate for the concept. Doc James (talk · contribs · email) 16:17, 29 July 2017 (UTC)
@Fæ: Thank you for all you do here. I think that report would continue to be useful, as long as your bot was able to write to it and editors who care about it were able to patrol it for vandalism.   — Jeff G. ツ 23:45, 30 July 2017 (UTC)

MPs in the United Kingdom

Zac Goldsmith in standard 3:4 crop from full length portrait.

Am I right in thinking the portraits of MPs in the following link are under a license suitable for the Wikipedia Commons? (https://beta.parliament.uk/houses/KL2k1BGP/members/current/a-z/a) If so it could greatly help with providing Wikipedia images for all United Kingdom MPs, many of which don't currently have one. If so what would be the best way to get these uploaded to Commons? Editor5807speak 23:15, 26 July 2017 (UTC)

They look fine to upload, as long as they have that CC-BY license specified. I know that the non-beta site has a non-free license. I'll go through them and upload them, checking to be sure they're free. Guanaco (talk) 23:21, 26 July 2017 (UTC)
Or maybe it would be better to wait a month or so, to see if they get all of the portraits uploaded... or script it. Actually, it appears to be extremely easy to script. I'm thinking I can do it tonight or tomorrow. Guanaco (talk) 23:34, 26 July 2017 (UTC)
Okay great, it would be good to get them on Commons. I don't know much about running scripts/batch uploads and I'd never have time to upload them all individually, so if you're happy to do the work then that's great! Editor5807speak 04:34, 27 July 2017 (UTC)

These were being uploaded as of last night, coincidentally just before this thread opened. They are at Category:Official United Kingdom Parliamentary photographs 2017 and the process is doing them alphabetically by surname, currently at "M". There are a few duplicates to sort out, related to the decision to upload the standard crop sizes that Parliament included, which are displayed as a gallery on each image page, and the files could do with slightly better categorization as some of the MPs have categories already. --Fæ (talk) 07:09, 27 July 2017 (UTC)

Thanks for pointing this out. I'll focus my efforts on developing PlantaeBot for now. Guanaco (talk) 09:32, 27 July 2017 (UTC)

Duplicate photos of United Kingdom MPs

Through good-faith editing, we have a number of duplicates in Category:Official United Kingdom Parliamentary photographs 2017. I suggest we keep these which are named as part of the series; so, for example, keep:

  • File:Official portrait of Mr Tanmanjeet Singh Dhesi.jpg
    File:Official portrait of Mr Tanmanjeet Singh Dhesi.jpg
  • File:Official portrait of Mr Tanmanjeet Singh Dhesi crop 1.jpg
    File:Official portrait of Mr Tanmanjeet Singh Dhesi crop 1.jpg
  • File:Official portrait of Mr Tanmanjeet Singh Dhesi crop 2.jpg
    File:Official portrait of Mr Tanmanjeet Singh Dhesi crop 2.jpg
  • File:Official portrait of Mr Tanmanjeet Singh Dhesi crop 3.jpg
    File:Official portrait of Mr Tanmanjeet Singh Dhesi crop 3.jpg

and not File:Tanmanjeet Singh MP - official photo 2017.jpg, which duplicates 'crop 2. Andy Mabbett (talk) 13:26, 27 July 2017 (UTC)

Sounds reasonable. To nominate a file for deletion, just use {{Duplicate}}, but you probably already know that. - Jmabel ! talk 15:19, 27 July 2017 (UTC)
Indeed, but given the volume, I think a more programmatic approach, rather than manual tagging, will be needed. Andy Mabbett (talk) 10:09, 28 July 2017 (UTC)
It may be worth adding duplicates to a one-off duplicate maintenance category, and as the images are highlighted automatically it's easy to see who uploaded the alternates and when; I don't think there are all that many, not sure as tools like PetScan have no easy way to pull a report. Rather than rushing to use of the duplicate template, I suggest just handling these as they become useful, as a human review to ensure any extra information is merged is needed. The duplicates were a choice for simplicity, it's not necessarily something to housekeep immediately. --Fæ (talk) 12:17, 28 July 2017 (UTC)
I note that some of the files, for example File:Alex Sobel MP - official photo 2017.jpg, are marked by MediaWiki software as duplicates. Is it not possible to use that feature to list all the duplicates in a given category? Or for a bot to categorise them all? Andy Mabbett (talk) 12:33, 28 July 2017 (UTC)
The easiest way that springs to mind is to pull a SQL report based on the category looking for a count of matching SHA1 values. In a more complex way, it can also be done with the API, pulling all files in the category and their SHA1 values (which does not need a local download of the file itself) - any programming language that can handle the API could do this. I have other stuff to focus on so don't want to spend the time to create the actual report right now. It's possible that someone once created a generic reporting tool for this, if not we could do with one. :-) --Fæ (talk) 12:56, 28 July 2017 (UTC)
Here is a Petscan query that shows a SHA1 value for every file in that category. Note, I have come across some of the portraits were uploaded without that category, further complicating the problem. seb26 (talk) 14:27, 29 July 2017 (UTC)

Please see Commons:Undeletion requests/Current requests#‎Official portraits of United Kingdom MPs. Andy Mabbett (talk) 14:12, 29 July 2017 (UTC)

It is quite easy to get these duplicates without complicated tools :

The odd thing is that some of these are being uploaded a few hours apart from each other. The file pages themselves seem to clearly indicate this. This means the subsequent uploader either ignored the duplicate warning, it doesn't check or warn properly, or maybe there is a bug, see Special:FileDuplicateSearch/Eleanor_Smith_-_MP_-_2017.jpg and [26].

General discusion of duplicates

It seems odd that duplicates are even allowed to be uploaded, and aren't even logged (https://phabricator.wikimedia.org/T16417). Wikimedia must enjoy wasting space for nothing. 17:22, 29 July 2017 (UTC) — Preceding unsigned comment was added by 197.218.88.21 (talk) 17:23, 29 July 2017 (UTC)

Yes, Special:UploadWizard, which most end users use, does warn about duplicates and even warns if a file was previously deleted. However, it's up to users' discretion to take the information into account. Fae presumedly used an upload script which may have bypassed warnings. Duplicates are not the worst thing in the world (and probably not the biggest issue facing space and long-term storage concerns for Wikimedia servers), also not every MP photo is duplicated. When I was applying personality rights template to this batch, VFC showed that Fae's uploads were far more comprehensive in terms of the number of MP portraits covered: i.e., human uploaders were missing a lot of files by the time Fae started (indicated by the number of uploads per user), so I think the mass upload was worth it even if duplicates occurred. seb26 (talk) 00:21, 30 July 2017 (UTC)
Duplicate upload is allowed not because they have infinite space or bandwidth but simply because it is possible to generate different files with the same "fingerprint". So they avoid false positives by allowing such cases.
Also most of those crops could probably be generated by server software either using imagemagick crop or the newly deployed Thumbor [27]. Although none of this is currently available as a parser function or an API for now.
As a side note, it could be useful to enhance the uploader by generating the "fingerprint" client side, and comparing it to stored server files using the API. Html5 file API now allows this (with some custom scripts), and at least for smallish files, this would be much better than wasting time uploading a file that already exists.
Anyway, it seems odd that people are asking for special scripts or whatever to detect this, as Special:ListDuplicatedFiles keeps track of at least 5000 of them, although it might not update frequently. Considering a single file has had more than 600 duplicates some of which have existed for almost a decade, users simply don't care or perhaps simply don't know about its existence. 11:07, 30 July 2017 (UTC) — Preceding unsigned comment was added by 197.218.92.107 (talk) 11:08, 30 July 2017 (UTC)
I don't think the problem is as big as you're making it out on that page you point to. The first item on that list is a blank page for the purposes of maintaining an order of a book in Wikisource. 600 * 1 KB files is not significant. The second is a similar placeholder, and the third is an arrow icon on a translatable help page where previously it showed more than an arrow icon and instead a localised menu, i.e. separate file warranted. There are more serious duplicate issues, look at Category:Faebot identified duplicates and User:Fæ/Imagehash for some information from some users who are caring about duplicates. seb26 (talk) 13:57, 30 July 2017 (UTC)
Indeed, the problem of the recently uploaded files isn't as big. However, that pseudo-book and other similar ones making use of blank pages and pseudo-navigation are certainly lacking. First, it was uploaded nearly a decade ago, so it was attempting to make up for limitations in wikis at the time. For one thing, it could simply use a redirect to the same page rather than recreate the same file 600 times. Either mediaviewer or commons gallery slideshow, or even mw:gallery slideshow could also display such files without blank alternatives from the category page or a simple page. Or better yet, these individual files could be converted into a pdf which has its own non-javascript compatible tool to view files in a sequence.
Finding duplicates with advanced algorithms is certainly a very useful thing, no doubts about it. Although it reinforces the fact that duplicates elsewhere are a problem, in a category with 110000 files it seems to have found more or less 10% of duplicates. Commons probably has a lot less than that, maybe less than 1% are duplicates. Still 1% of 104,841,754 is considerable. 20:00, 30 July 2017 (UTC)~ — Preceding unsigned comment was added by 197.218.89.195 (talk) 20:01, 30 July 2017 (UTC)

July 27

lua error in Category:Fire stations in Austria

Tracked in Phabricator
Task T171392

Hi everyone, Category:Fire stations in Austria shows a lua error: Lua error in mw.wikibase.entity.lua at line 37: data.schemaVersion must be a number, got nil instead. (I guess for Germany and Switzerland). Sometimes this category even does not load at all (Die Zeichenkodierung des HTML-Dokuments wurde nicht deklariert. Das Dokument wird in manchen Browser-Konfigurationen mit verstümmeltem Text dargestellt, wenn das Dokument Zeichen außerhalb des US-ASCII-Bereichs enthält. Die Zeichenkodierung der Seite muss im Dokument oder Transferprotokoll deklariert werden.) Only in FF 54, not in Chrome or Edge. Later I get Error: 503, Service Unavailable Lua errors are server side, any help / hint? --Herzi Pinki (talk) 19:28, 29 July 2017 (UTC)

I replaced the template with my sandbox I used while debugging the said ticket. --Zhuyifei1999 (talk) 19:57, 29 July 2017 (UTC)

July 30

Diagrams showing multiple views of the same subject

Front, side, and top views.

What is the right name for this kind of diagrams, showing more than one view of the same subject? -- Tuválkin ✉ ✇ 00:17, 30 July 2017 (UTC)

July 31

Attribution

Is it proper for a user who fixes a file to ask for attribution for that fix?   — Jeff G. ツ 03:25, 31 July 2017 (UTC)

Attribution is cheap. If it's a copyrightable change, then the CC license gives them the right to demand attribution. Commons pages should note who made changes, whether or not that carries through to the license.--Prosfilaes (talk) 04:13, 31 July 2017 (UTC)

Tech News: 2017-31

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Problems

  • Some pages show the error Lua error in mw.wikibase.entity.lua at line 34: The entity data must be a table obtained via mw.wikibase.getEntityObject. This problem happens on pages with a Lua module that uses Wikidata. The developers are working on fixing the problem. You can fix a page by opening it for editing and then saving without changing anything. [28]
  • Wikidata and German Wikipedia could not be edited for an hour on 28 July. You can read why and how we could avoid it in the future in the incident report.

Changes later this week

  • Some wikis already have the larger and brighter OOjs UI edit page buttons. All remaining wikis except Commons will have these from 1 August. [29]
  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 August. It will be on non-Wikipedia wikis and some Wikipedias from 2 August. It will be on all wikis from 3 August (calendar).

Meetings

  • You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 1 August at 19:00 (UTC). See how to join.

Future changes

  • The default font in the edit window will soon change for some users. Instead of using the browser default it will be monospace. Users can change this in their preferences. This should only change this for some users on Macs and iOS devices. [30]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

21:45, 31 July 2017 (UTC)

August 01

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Archive/2017/07&oldid=392834995"