Commons:Village pump/Archive/2018/06

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

Category name needed

«The road is lo-o-o-ong…»

So this is not a boulevard, alright. What is it then? I’m sure there’s a lot of use for this concept, and it’s meaning is clear: A (usually paved) path / road / street / walkway inside a park or garden. What’s the English term for this? -- Tuválkin ✉ ✇ 11:49, 23 May 2018 (UTC)

  • Most commonly a mall; also (especially UK) an avenue. Of course, both of these also have other meanings, so no great suggestion for a category name. - Jmabel ! talk 14:58, 23 May 2018 (UTC)
  • Perhaps a bit fashioned, but still used is a promenade. This is precisely used for a paved walkway, designed primarily for the enjoyment of those promenading (walkers). I think it's mostly British English, but it will probably be okay for North American English speakers. Avenue is a good alternative, but has far more diverse uses. --Fæ (talk) 15:06, 23 May 2018 (UTC)
  • A promenade need not be tree-lined or linear (consider the one at Brooklyn Heights). - Jmabel ! talk 19:23, 23 May 2018 (UTC)

It's kind of a boulevard... It's paved, with trees at its sides. And if good old Catarino was right, the artillery even passed there at the time of the Peninsular War. In Portuguese we usually call this alameda, often translated to "boulevard", but which apparently also exists in English, and means precisely what this is. So maybe we should stick to alameda, at least for the categorization. For the name of the category, I believe [[Category:Western gate and palm avenue of Escola Politécnica de Lisboa]] could be a good option.-- Darwin Ahoy! 09:29, 24 May 2018 (UTC)

  • No, I didn’t mean this very specific type of “garden path” / “park walkway” — straight, wide, lined with trees, meant for visitors. The photo was just an example. I meant any kind of “garden path” / “park walkway” (so: also winding, bumpy, narrow, barren, meant also for gardeners etc.) — is there an simple and clear English word for it? -- Tuválkin ✉ ✇ 20:56, 31 May 2018 (UTC)
    • We don't really have any one word for that in English. There is probably no single term that would cover a service road in a park, a nature trail/hiking trail, and a formal promenade. I suppose there could be some sort of agglomerated "roads, paths, and trails in parks" category; would it be useful? - Jmabel ! talk 00:59, 1 June 2018 (UTC)

Meghan Markle's Mum - no photo of her at very big public event

Meghan Markle's mum whose name is Doria Ragland flew from the USA to attend her daughter's wedding where I'm told about a million photographs were taken. There is no picture of en:Doria Ragland with an open license that can be used on commons (according to google images). The en:wiki article uses a screen capture from a video. I know that the gatekeepers here are very concerned to hold back a million pictures (from our overworked reviwers) but surely not getting one picture of a major player at one of the biggest public events on the planet is a bit worrying. I supply this anecdote in the hope that some knows how we might improve our flow of pictures in the future. Any comments? Victuallers (talk) 12:34, 31 May 2018 (UTC)

If we can't obtain pictures under free licences, we need to send photographers to those events (music festivals, sports competions, awards ceremonies, book fairs, etc.). Some volunteers already do that, but il will never be not enough. The twitter account of WMUK, which is very active, could ask photographers to release some pictures of the wedding. Pyb (talk) 16:54, 31 May 2018 (UTC)
I squeezed the best I could out of the video. - Alexis Jazz ping plz 00:20, 1 June 2018 (UTC)

Tech News: 2018-22

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

  • You can now use global preferences on most wikis. This means you can set preferences for all wikis at the same time. Before this you had to change them on each individual wiki. Global preferences will come to the Wikipedias later this week. [4][5]
  • It is now easier for blocked mobile users to see why they were blocked. [6]
  • Wikidata now supports lexicographical data. This helps describe words.
  • There is now a checkbox on Special:ListUsers to let you see only users in temporary user groups. [7]
  • Some rare invisible Unicode characters have recently been banned from page titles. This includes soft hyphens (U+00AD) and left-to-right (U+2066) and right-to-left (U+2067) isolate markers. Existing pages with these characters will soon be moved by a script. [8]
  • Advanced item There's a new Wikimedia Foundation team to support the Wikimedia technical communities. It's called the Technical Engagement team. Most of the team members did similar work in other teams before this. [9]

Problems

  • Some translatable pages are showing old translations instead of latest ones. The cause of this issue has been fixed. We will update all pages automatically to show the latest translations. [10]

Changes later this week

  • There will be a new special page named PasswordPolicies. This page gives information about the password rules for each user group on that wiki. [11]
  • A new way to see moved paragraphs in diffs is coming to most wikis. This is to make it easier to find the moved paragraphs and the changes in them. [12]
  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 29 May. It will be on non-Wikipedia wikis and some Wikipedias from 30 May. It will be on all wikis from 31 May (calendar).
  • Advanced item Wikis can enable Citoid to provide automatic reference look-up in the visual editor and the 2017 wikitext editor. This is complex. The tool will now disable itself if the configuration isn't correct. It has warned about this in the JavaScript console since February. Check that your wiki is configured correctly. You can ask for help if you need it. [13]

Meetings

  • Recurrent item 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 29 May at 18:30 (UTC). See how to join.
  • Recurrent item Advanced item You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 30 May at 15:00 (UTC). See how to join.

Future changes

  • Content Translation drafts which have not been updated in over a year will be removed. This allows other users to translate those articles. [14]
  • A survey is collecting information on what users think about how Wikimedia wiki pages are loaded. This information could be used in future development. [15]
  • Advanced item Some wikis will switch to use the Remex parsing library. This is to replace Tidy. It will happen on 30 May and 13 June. Wikis with fewer than 100 linter issues in the main namespace in all high-priority linter categories will switch. This includes Wikidata. Tidy will probably be removed on all wikis in the first week of July. [16][17]

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

12:40, 29 May 2018 (UTC)

See eg d:Wikidata:Lexicographical data/FAQ (1 link away from the page linked in the above message) :) Jean-Fred (talk) 06:48, 1 June 2018 (UTC)
Whether you agree with the WMF's logic or not, complaining that they're doing it is like saying, "Why should Wikidata store its own data? All the information is already in Wikipedias." They probably see value in data being machine-readable, and they've been planning Wiktionary integration with Wikidata for years, so I don't see why this would be out of the ordinary. Jc86035's alternate account (talk) 11:28, 2 June 2018 (UTC)
  • That’s the same as argueing that, because Mein Kampf was written in prison, everybody had time to read it and nobody could say honestly they were surprised with everything that went down later on — therefore any resistence is futile and any protest is misplaced. (See what I did here?) -- Tuválkin ✉ ✇ 18:45, 2 June 2018 (UTC)
  • F.t.r., nobody ever said that Wikidata should not store data (its own or whose-ever — data just wants to be free). What is being argued is that Commons, and now Wikitionary, should not be gutted off their contents and be merely a shell to display data from Wikidata. -- Tuválkin ✉ ✇ 18:47, 2 June 2018 (UTC)

May 31

New Focus-stacking template

We ( Colin,XRay, El Grafo and Cart) had had an extended discussion at FP on templates that are not all fit-for-purpose. Many images are being uploaded to Commons (and then submitted to FP/QI) using focus-stacking and stitching techniques. The current template for focus stacking is useless though I'm told it has been used many times. We can either update it with a BOT or someone could create a new easy-to-use one - one that is flexible enough to cope with emerging post-processing technologies as well as the current stitching and focus-stacking techniques. Here is the focus stack debate. Can anyone help please? Charles (talk) 11:07, 31 May 2018 (UTC)

  • As there has been no response here I have created a new template. I would welcome any suggestions as to how it could be improved. It is modelled on the Template:Panorama Charles (talk) 16:57, 2 June 2018 (UTC)
NOTE: This image is a focus stacked image consisting of multiple images that were merged using software. As a result, this image underwent digital manipulation which may have included blending, blurring, cloning, and colour and perspective adjustments. As a result of these adjustments, the image content may be slightly different than reality at the points where the images were combined. This manipulation is often required due to lens, perspective, and parallax distortions.

العربية ∙ Deutsch ∙ English ∙ español ∙ français ∙ 日本語 ∙ македонски ∙ português do Brasil ∙ русский ∙ slovenščina ∙ ไทย ∙ українська ∙ 中文（简体） ∙ 中文（繁體） ∙ +/−

Cyrillic accents for old Russian documents

A persistent problem I have with uploading pre-20th C. Russian documents is that where the source metadata gives (correctly?) accented letters, these appear impossible to use in Wikimedia Commons filenames. This seems to boil down to Wikimedia Commons not being able to cope with long accents like i︠u︡ (looks like íù with the accents joined up).

An example has been uploaded from Library of Congress at File:Karta i︠u︡zhno-ussurīĭskago krai︠a︡. LOC 99443159.jpg. On the LOC website the text displays perfectly well.

Suggestions on how these should be systematically handled, on the presumption that the handling of Unicode on Wikimedia Commons is not going to be extended any time soon? I presume that stripping out the accents so the file becomes "Karta iuzhno-ussuriiskago kraia" might do, though I note that Ussuriysk is the modern name so a transliteration table might be needed if this is to be done well. Thanks --Fæ (talk) 15:43, 1 June 2018 (UTC)

I think this is entirely down to the fonts being used. In this paragraph (which on my work machine is rendered in DejaVu Sans), the accents work correctly. In the title of the page (rendered in Linux Libertine 0), they don't. If I override the font in the page title to DejaVu Sans, that works as well. In both cases, my browser uses the version of the font on my system. So I don't think Commons is doing anything very wrong: it's just specifying a font whose combining half marks don't work properly. One thing that seems to improve things is to use U+0361 COMBINING DOUBLE INVERTED BREVE instead of the separate U+FE20 COMBINING LIGATURE LEFT HALF and U+FE21 COMBINING LIGATURE RIGHT HALF, like this: File:Karta i͡uzhno-ussurīĭskago krai͡a. LOC 99443159.jpg. That produces sensible results in both fonts for me, and the Unicode Standard (version 10.0) says that's the preferred form anyway.--bjh21 (talk) 16:34, 1 June 2018 (UTC)
Good suggestion, though this does not seem to work with Wikimedia Commons filenames, at least when they are displayed as image page titles. After moving the file I get File:Karta i͡uzhno-ussurīĭskago krai͡a. LOC 99443159.jpg but it displays badly when you visit the page. --Fæ (talk) 16:43, 1 June 2018 (UTC)
Unless I am misunderstanding, this seems to display correctly for me on Commons, but not on LOC.gov. Would it not be better to use the map's Cyrillic title (Южно-Уссурійскаго Края) rather than the LOC transliteration, where this is feasible? Apologies for butting in if I did misunderstand. Storkk (talk) 16:52, 1 June 2018 (UTC)
The new title displays fine for me. It appears that whatever font your browser is using is even more deficient than Linux Libertine, and doesn't support either combining half marks or double-width diacritics. Since this is solely a client-side rendering issue, my inclination would be to use correct Unicode (either form, or Cyrillic if you prefer) and accept that it will look a bit odd for some people until their fonts and/or browsers get better. PS: like Storkk's, my browser makes a mess of the LOC version. --bjh21 (talk) 17:08, 1 June 2018 (UTC)
The two filenames here display nearly identically to me fwiw, if that's relevant. Editing the wikitext, however, "i︠u︡z" is different to "i͡uz". I'm also running a Linux at the moment. Again, sorry if I'm just adding noise. Storkk (talk) 17:19, 1 June 2018 (UTC)
Ah, that is interesting, thanks for this feedback! I had not thought to test browser issues. My display problems are with Chrome 66.0.3359.181 (Official Build) and when I open Firefox the display problem goes away and even the old name is usable.
I'll think about this. The next time it arises I may do a bit of poking about in Phabricator and may raise a ticket. Based on past experience, WMF dev are likely to blame Google Chrome rather than this being a Mediawiki bug that needs fixing.
In terms of batch uploads, I would like to adopt Storkk's suggestion of going full Cyrillic, unfortunately the LOC records do not have these as part of the current metadata and I'm not competent to make these sorts of translations by hand.
P.S. This is all part of User:Fæ/LOC maps, where around 27,000 different maps are getting uploaded. Only a tiny fraction of these will be pre-20th century Russian maps. --Fæ (talk) 21:07, 1 June 2018 (UTC)
I would need to take a look at a bunch of the LOC transliterations to verify a hunch holds at least mostly universally (which I won't be able to do until next weekend), but it seems like they are ligaturing what are single letters in Russian. So Ю is normally transliterated today as "Yu" but they have used "i͡u". Likewise for я for what is now transliterated "ya". What they do for letters like ь and ъ would need to be nailed down, as well as a few other things, but it shouldn't be too hard to cobble together an accurate python/perl/whatever script to "untransliterate". A regex for VFC might even be doable. If you'd like me to take a look next weekend, let me know. Storkk (talk) 21:25, 1 June 2018 (UTC)
I am not great at these. Debugging character encoding/decoding is ghastly, especially if browsers are unreliable in the way they present results. A simpler starting point might be to put candidates for recoding in a backlog category. We can then get a feel for whether this is worth automating; if there are fewer than 100, it could be better to do them manually.
I suggest we defer for a while, as there is no point in searching out transliterations until all the maps are uploaded. The upload project has been running for nearly a month and it's probably only just around 10% to 15% done (very hard to estimate). Although the bucket category contains a lot more than 27,000 files already, that's simply because some of maps have many separately scanned sheets. For example Sanborn Fire Insurance Map from Denver is one atlas with over 40 sheets and each sheet may exist as both jpeg and TIFF. --Fæ (talk) 21:44, 1 June 2018 (UTC)
The accents (diacritical marks) appear fine on my Microsoft Edge browser (mobile, Microsoft Windows 10 Mobile), maybe some browsers don't have the font pre-installed, like how until recently there were messages at the English Wikipedia for any article that displays Chinese characters (both Traditional Chinese characters and Sinplified Chinese characters) that were removed because most recent computers and operating systems have them built-in. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:16, 2 June 2018 (UTC)

Uploads cut off at 5 MB

Two users at the English Wikipedia have reported grey areas in their Commons uploads: w:Wikipedia:Teahouse/Questions/Archive 774#Help with photos and getting rid of "grey areas" and w:Wikipedia:Help desk#Images I upload show a gray bar across the bottom. Their uploads are Special:ListFiles/Rob Sherratt (see file histories like File:Community celebration at Mesopotam Monastery.jpg#filehistory for 5 MB cut offs) and Special:ListFiles/Eileen at OE. All affected uploads are marked "Cross-wiki upload from en.wikipedia.org". Anyone know what is going on? I haven't tried uploads above 5 MB. PrimeHunter (talk) 20:47, 1 June 2018 (UTC)

@PrimeHunter: What steps may one use on that project to produce a "Cross-wiki upload from en.wikipedia.org"?   — Jeff G. ツ please ping or talk to me 17:47, 2 June 2018 (UTC)
That is the default log message when you upload any image to Commons while using the Wikipedia upload form. Free images will always be uploaded here unless you explicitely mark them for local WP upload. I don't know though why these images are "mutilated". De728631 (talk) 18:27, 2 June 2018 (UTC) De728631 (talk) 18:27, 2 June 2018 (UTC)
I don't know whether it's all uploads started there. Based on Commons:Cross-wiki media upload tool and mw:Upload dialog it may depend how the upload is started. Those pages indicate use of a tool started on the first hills icon at [18] (source editor) or the "Insert" menu at [19] (VisualEditor). I don't know what the users did but based on other edits it's possible Rob Sherratt used the source editor and Eileen at OE used VisualEditor. PrimeHunter (talk) 18:35, 2 June 2018 (UTC)
I searched for recent large "Cross-wiki upload from en.wikipedia.org". I found File:Keel Her.jpg at 10.33 MB with no error, and no others near or above 5 MB. PrimeHunter (talk) 18:47, 2 June 2018 (UTC)

Introducing Toolhub

What does your participation on the Wikimedia projects look like? Do you edit articles? Upload files? Patrol vandalism? Translate articles? Translate interface messages? Do you organize people, online or offline? Do you train new editors, or new trainers? Do you write code?

There are many different ways to contribute to Wikimedia – more than you would expect just from reading Wikipedia articles. Over the past several years, volunteers have developed technical tools that help Wikimedians improve content, patrol vandalism, and perform many other tasks. They make it possible to do what the wiki software alone cannot accomplish. Without these tools, many of our projects would slow down to a crawl.

I am very happy to announce a new project called Toolhub which seeks to create a searchable index of these tools in all languages. We are building this tool catalog based on what our communities need. If you would like to help, please take a look at m:Toolhub and review the question at the top of the page. You can also leave feedback in any language on the talkpage. You can also email me private feedback. Harej (WMF) (talk) 23:40, 2 June 2018 (UTC)

June 03

Blocked Account Help

If I log into a blocked account on a device, then log out of the account, and then log into an unblocked account on the same device, will everything function as though I had not logged into the blocked account originally? I.e. will logging into the blocked account block my IP address, so logging into an unblocked account will then not function properly? — Preceding unsigned comment was added by 74.142.220.203 (talk) 21:09, 27 May 2018 (UTC)

I think it depends on the type of block.   — Jeff G. ツ please ping or talk to me 01:38, 28 May 2018 (UTC)
see also w:Wikipedia:Autoblock, and an extreme case w:Wikipedia:Wikipedia Signpost/2009-01-03/Virgin Killer Slowking4 § Sander.v.Ginkel's revenge 03:20, 28 May 2018 (UTC)
Isn't this more the domain of "Cookie-block" as cookie-blocks stay active even after a blocked account is signed out, however I do not know if cookie-blocks get overwritten when a person signs out of a blocked account and then into a non-blocked account, however it does prevent the (automatic) creation of a local account so the user won't be able to edit there (with that browser), however I would suggest you would create similarly named accounts, ask an administrator to block one, then sign into the other and try to edit a page or upload an image as that might clear up how cookie-block functions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:56, 3 June 2018 (UTC)

May 28

Consell Metropolità de l'Horta

Last friday we went to Alaquàs and we found some manhole covers issued by short lived Consell Metropolità de l'Horta. I've opened a category about that council (there wasn't any!); its here Consell Metropolità de l'Horta (València).

I've placed it in category Subdivisions of the Land of Valencia, but I'm not quite happy about that.

So those familiar with the subject, do not hesitate to come and reasign as you see fit.

Moltes gràcies!

B25es (talk) 14:50, 3 June 2018 (UTC)

Prussian flag on Norwegian Wikipedia

I created File:Flag of Prussia without regalia.svg years ago as a hypothetical flag, but didn't realize at the time that it should have been tagged as a fictitious flag. I recently realized it's being used on the Norwegian Wikipedia as if it was official. I would appreciate if a Norwegian editor could clear this up. File:Flag of Prussia (1892-1918).svg should be used instead. Raymond1922A (talk) 21:33, 3 June 2018 (UTC)

  • Very unlikely that anyone from the Norwegian Wikipedia will spot this here. You can make the edit yourself there, and I'm sure they will have no problem with you leaving an edit summary in English. - Jmabel ! talk 00:14, 4 June 2018 (UTC)
    • I tried editing the templates that used it. There's still a few pages that use it, but none in the mainspace. I think the remaining uses should be gone once everything refreshes. Raymond1922A (talk) 01:26, 4 June 2018 (UTC)

June 04

"Original file"

The file I uploaded

The Original file or the preview in 2,980 × 1,202 pixels look like the old File. Why? Habitator terrae (talk) 13:31, 10 June 2018 (UTC)

purge helps? --Herzi Pinki (talk) 16:34, 10 June 2018 (UTC)
This section was archived on a request by: Habitator terrae (talk) 18:25, 10 June 2018 (UTC)

Europeana Collections

I am not sure if many people are aware of this but a project co-funded by the European Union called the Europeana Collections hosts millions of images from musea across the European Union (EU) and many of them are released under a free license, although I would be cautious as I had almost uploaded non-free images of Chinese coin swords (as thess images fall under a "non-commercial" license, which is incompatible with Wikimedia Commons), the Europeana Collections has many images from museums from all over the European Union and maybe it would be handy if in the future a tool created similar to Flickr2Commons would be created to import images and other media from this website, or someone should reach out to them to start a partnership. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:55, 1 June 2018 (UTC)

The (Wikimedia Chapter funded) development of GWT was with Europeana as a supplier. Europeana is useful, but they are an aggregator. Uploads should be from the original source of the images where there is likely to be more complete, and up to date, metadata, and where some images for some collections can be found at higher resolution.
Sadly, there are public domain photographs with deliberately reproduced copyfraud claims, there are images that have been deliberately watermarked, and images which have been published at bizarrely low resolution. These should be avoided. As an example, take the disgusting copyfraud test case of this photograph claimed to have been created on 14 November 1924:
  • Europeana (450 x 339 pixels) TopFoto (540 x 407 pixels, different watermark)
  • the metadata is blatantly wrong as this is a photograph of the ship, not the flag
  • the image is hugely watermarked, making it valueless apart from an advert for TopFoto
  • the high resolution version is unavailable, with TopFoto wanting to be paid £39 for an A4 print or £60 for A3
  • TopFoto is some sort of commercial partner with Europeana, as TopFoto's website even has a link back to Europeana on the top menu
  • based on date, the original photograph is presumably of HMS Revenge and is public domain. TopFoto have absolutely no legal claim of copyright yet require credit and will not release the high resolution scan
I would be against developing another tool, with a bit of thought most people can generate an XML dump of the metadata and use GWT. If you have not got the message yet, I would also be against any use of Wikimedia Commons to promote Europeana, unless and until they clean themselves of the commercial misuse scamming, which turns Europeana into a dodgy pyramid scheme built on copyfraud. --Fæ (talk) 14:13, 1 June 2018 (UTC)
Fae, The unnecessary hostility of your final sentence is unbecoming, and for someone who has worked with Europeana over the years it is also disingenuous. You know full well that Europeana does as much as it is politically and technically able to do in terms of encouraging open-access, free-licensing, and interoperability/sharebility of Europe's digital cultural heritage. We cannot force a GLAM to change the way they license of their content, but we do try emphasise the value and impact of these principles by showcasing the positive examples - rather than shaming the bad ones. Wittylama (talk) 08:52, 2 June 2018 (UTC)
Obviously we disagree. Until management in Europeana chooses to lift a finger and properly respond to complaints about their public support of copyfraud and do something about these appalling promotional and useless image on their website, they are not a credible partner for open knowledge projects or funding.
If anything, the Wikimedia Foundation and especially yourself as "the Europeana GLAMwiki Coordinator, elected member of the Funds Dissemination Committee, and chair of the Wikimania2018 program committee" should take some personal responsibility to get Europeana to take down these low-resolution, promotional and watermarked files which should be an embarrassment for everyone involved.
Facts are facts, go by the evidence. Stop trying to shut me up, just because I am not prepared to massage the facts to pretend that hosting terrible copyfraud images can be fakenews-ed into something that can appear to support Europeana's charitable mission statement. Let's stick to facts, not require unpaid Wikimedia Commons volunteers like myself to be politicians and make personal attacks by calling us "hostile" when we do not play this commercial game. --Fæ (talk) 09:59, 4 June 2018 (UTC)
Ciao Donald Trung, I'm glad you found the Europeana collections interesting and useful :-) As Europeana's Wikimedia liaison guy, it's always nice when Wikimedians discover the project organically like you have - note there's also many 'thematic collections' (linked from the homepage) which give curated 'slices' through the content aggregated from across Europe's GLAMs. Note also that there's been many collaborative projects that we've run across Wikimedia projects (listed on meta at m:Europeana/Projects).
However, as mentioned - the multimedia is not "owned" by Europeana itself but aggregated from many many cultural organisations across Europe. Unsurprisingly, is both a technical and political challenge to encourage all these disparate organisations to coordinate (and in their own languages) to willingly share their own content in a consistent and free-licensed manner. We DO require that all the metadata being provided is licensed CC0[20] (thereby making it compatible with Wikidata) and that the GLAM gives each item a machine readable 'rights statement'[21]. We also encourage and promote as much as possible our 'public domain charter'[22] which says, among other things, "What is in the Public Domain needs to remain in the Public Domain" and "No other intellectual property right must be used to reconstitute exclusivity over Public Domain material" [e.g. watermarks]. However, we are not able to force this principle upon the cultural institutions of Europe, nor change how they've described or licensed their own collections. Finally, in terms of uploading to Commons directly, in most cases the high resolution file is not itself hosted on Europeana itself - but linked to from the site. Europeana is an aggregator of already published cultural content not the 'owner' of that content. It would be on a collection-by-collection basis of what is the best way to share the content, and the level of detailed of the metadata associated with it. Feel free to get in touch with me if you'd like to work on a particular project and I might be able to help put you in contact with the individual institution, for example. Wittylama (talk) 08:45, 2 June 2018 (UTC)

Romanian maps under ‘Lambert-Cholesky’ (1916-1959) projection system

Hello, I' m asking if it is possible to upload to Commons, Romanian maps under ‘Lambert-Cholesky’ (1916-1959) projection system. Here at geo-spatial.org:Info it is mentioned that the materials on the site are posted under the license CC BY-SA 3.0 (except articles, only).

So, I asked here (se posts 55-56) more than 5 months ago, and the answer was that the material is absolutely free.

The owner of the rights (whose name is printed on each map) was the Military Topographic Service of the Romanian Army (previously called The Romanian Army Geographic Service), but now it seems that maps are free.--Accipiter Q. Gentilis (talk) 22:15, 1 June 2018 (UTC)

Sample maps: [23], [24] (from here) --Accipiter Q. Gentilis (talk) 22:31, 1 June 2018 (UTC)

Similar maps are in the Category:3rd Military Mapping Survey of Austria-Hungary.--Accipiter Q. Gentilis (talk) 22:46, 1 June 2018 (UTC)

  • Not sure I follow: "CC BY-SA 3.0" and "absolutely free" seem to contradict each other, since the former requires (among a few other things) attribution, and the latter presumably means public domain. If either is actually the case, though, these should be acceptable for Commons.
  • What is the indication that the Romanian Army either has lost copyright or issued a license, though? Just an assertion by geo-spatial.org? - Jmabel ! talk 22:59, 1 June 2018 (UTC)
    • As to your second point, one could argue that the Romanian army is a legal entity, so copyright for their works is limited to 50 years from the first publication (see {{PD-Romania}}). De728631 (talk) 18:31, 2 June 2018 (UTC)
      • Then that would be a good rationale to be PD in Romania. And these are old enough that U.S. copyright would have required registration, which presumably did not happen during the Cold War, so these are probably good to go. - Jmabel ! talk 03:42, 3 June 2018 (UTC)

So, for now I understand that it would be possible to refer only to the maps first printed before 1946 (whose property rights have expired according to Decree 321 of 1956), and to the maps first printed in the period 1946-1947 (whose property rights have expired according to law number 8 of 1996, which extended unexpired property rights until 70 years). For the other maps printed for the first time between 1948 and 1959, a declaration of release of the rights must be obtained.--Accipiter Q. Gentilis (talk) 10:28, 3 June 2018 (UTC)

  • Sounds right. U.S. copyright registration presumably did not occur (though you could research that) and certainly would not have been renewed, so they should be PD in the U.S. as well. - Jmabel ! talk 17:13, 3 June 2018 (UTC)

Another issue: some of the maps were reprinted and corrections, data updates, etc. were made. As was stipulated in the Article 31 of Romanian Law of Copyright and Related Rights 8/1996 (updated until march 30, 2018) - Non-essential changes, additions, cuts or adaptations made for selection or arrangement, as well as the correction of the content of a work or a collection that are necessary for further work of the collection as was intended by the author of the work, will not extend the term of protection of the work or the collections.

This is important, for instance for a map created in 1917 and reprinted in 1949, who was updated regarding some landmark names or roads, railways, etc ...--Accipiter Q. Gentilis (talk) 17:54, 4 June 2018 (UTC)

June 02

Magazine cover art published in 1899 in a former country, artist died 1959

Art was published as a magazine cover art – that incorporates signature, magazine title, volume, issue, and date in the art – in 1899 in the former Kingdom of Italy.

Nasìca (pseud. of Majani, Augusto) (1899-03-30). "[Front cover]" (PDF). Bologna che dorme 2 (13). Bologna: Società Cooperativa Tipografia Azzoguidi. Archived from the original on 2018-06-02. – Via Biblioteca Digitale Metropolitana.
  • So {{PD-1923}} publication license for US, as the magazine was published before Copyright Act of 1909.

Artist died in 1959 (in 2018, 59 years since death).

COM:CRT#Italy states "The Italian Copyright Law as translated at WIPO (note that the English version at WIPO is obsolete -- it calls for a fifty year term -- use it carefully only if you must)", "Generally, 70 years after the author's death...", and "Artistic photographs enter the public domain 70 years after the author's death".
I assume that the cover art was commissioned work for the 8-page magazine so the original art was owned by the magazine publisher and not the then-32 year-old artist.
  • So {{PD-Art|1=PD-old|deathyear=1959|country=it}} artwork license?

Italian library published photo of magazine cover on web with CC-by-3.0 for all website content.

Caricature (in it). Biblioteca-archivio Casa Carducci. Istituzione Biblioteche del Comune di Bologna.
  • So {{Cc-by-3.0}} photo license per website for faithful reproduction of magazine cover.

Bundled into {{Licensed-PD-Art-two|1={{PD-Art|1=PD-old|deathyear=1959|country=it}}}|2={{PD-1923}}|3={{Cc-by-3.0|}}}}?

Is this the correct licensing? --BoBoMisiu (talk) 00:07, 3 June 2018 (UTC)

It does not matter who owns the copyright. The term is the same: 70 years after the author's death. The photo is still copyrighted in Italy. Ruslik (talk) 18:03, 3 June 2018 (UTC)
@Ruslik0: : what is the 50 year at COM:CRT#Italy? Is it also 70 years when, as in this case, the original art is drawing? So, the Cc-by-3.0 photo license for JPG doesn't really mean much, in a way, other than to attribute the photo source.
What if the artist was unknown and published in 1899 and on a library site with Cc-by-3.0 for JPG? What would be the license combination to use in that case? — Preceding unsigned comment added by BoBoMisiu (talk • contribs) 20:58, 3 June 2018 (UTC)
This is a drawing, not "non-creative" photograph. And the artist is actually known. Ruslik (talk) 11:59, 4 June 2018 (UTC)
@Ruslik0: Yes, in this case it is; I understand that it is not eligible for inclusion. I was not asking my followup about this case. The COM:CRT#Italy should be reworded to remove the 50 because, since 2001, it is 70. I'll write something on that talk page. –BoBoMisiu (talk) 18:18, 4 June 2018 (UTC)

Facebook account

As an efforts of Wikimedia Israel, the Israeli police released the photographs and video clips from there social media accounts as listed in Template:IsraeliPoliceLicense. But seems there is some problem with getting access for reviewing them. I do not have such a problem, as well as other users from Israel. Can I have a feedback if you have a problem to access to these accounts. Can you see the source photo of File:Jamal Hakrush, February 2018.jpg? Does anyone have explanation to that? -- Geagea (talk) 00:20, 3 June 2018 (UTC)

File:Jamal Hakrush, February 2018.jpg (Israel Police Arabic Facebook account ): I have a FB account (Europe) but can't see it. Leoboudv has no account and was unable to see it.
File:Police officer of Israel Border Police.jpg (Israel Border Police Facebook account): I can see it, Leoboudv couldn't.
You can also just visit the account pages:
- Alexis Jazz ping plz 00:29, 3 June 2018 (UTC)
The link for File:Police officer of Israel Border Police.jpg turns out to have been updated from https://www.facebook.com/israelpolicearabic/photos/a.996224060504033.1073741829.949676351825471/1479544332172001/?type=3&theater (not working) to https://www.facebook.com/185561604935582/photos/pb.185561604935582.-2207520000.1523306906./1000408623450872/?type=3&theater (working). The first link is from the israelpolicearabic account, the second is from the Israel-Border-Police account. - Alexis Jazz ping plz 00:38, 3 June 2018 (UTC)
Isn't an archived link available? Usually even when the content itself is unavailable written texts (including licenses) remain. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:58, 3 June 2018 (UTC)
@Donald Trung: Nope. I suspect you need an IP in Israel to see it, but I wasn't able to find any free service that provides that. (none that works anyway) Also the content itself needs to be available, license reviewers need to check the photo as uploaded here actually comes from one of those accounts. I don't know if Geagea can review his own photos, but if he can I think he should. Although we may have to question if we can accept this content at all if the source is unavailable to most people here. If I published my photos with a free license on a FB acount that could only be seen by people who live in Honduras, or a website that could only be visited by people who live in Tajikistan, should we accept it? (I'm asking you, not telling you) - Alexis Jazz ping plz 12:23, 3 June 2018 (UTC)
The only issue is that we can't review it, because if the image have been reviewed (with an irrevocable license) no matter if the source is not still available for the rest of the world. Me too I don't manage to see the source. Christian Ferrer (talk) 12:26, 3 June 2018 (UTC)
@Christian Ferrer: Geagea is already an administrator, I don't know if he would have to apply separately for image reviewer but even if that's the case it would only be a formality. So could he simply review his own or is that not allowed? - Alexis Jazz ping plz 12:31, 3 June 2018 (UTC)
I easily trust Geagea, but I don't think that our community is willing to accept that someone (administrator or not) review his own uploads. A good way would be that another user with an IP in Israel upload the files from Israel Police Arabic Facebook account and then Geagea can review the files. Christian Ferrer (talk) 12:39, 3 June 2018 (UTC)
I cannot review my own uploads. It's basic. All the point of license review that two users confirm that the file is available in the source provided. Anyway we do have another admin from Israel that can review this particular file. The point is that I want to be sure that only users from Israel can accsses to these accounts.-- Geagea (talk) 13:03, 3 June 2018 (UTC)
@Geagea: I can see all the links above from the US except the ones that start with https://www.facebook.com/israelpolicearabic/.   — Jeff G. ツ please ping or talk to me 13:23, 3 June 2018 (UTC)
I have reviewed the file, thanks for uploading Geagea. matanya • talk 18:57, 4 June 2018 (UTC)

Photographers' favourites categories

@Charlesjsharp: was inspired by @XRay: to create his own "favourites" category. I doubt anyone would object if they created a page like User:Charlesjsharp/My favourite photos and created a gallery there. I'm not sure this is a good use of the category system though.

I'm not strongly against it (especially when good photographers do it), but we already have categories for valued, featured and quality images. Favourites are only the opinion of the creator. So we should probably discuss this now and not incite loads of anger when these categories are nominated for deletion months or years from now. - Alexis Jazz ping plz 15:46, 3 June 2018 (UTC)

If it's a common's I'll remove the category. --XRay talk 16:18, 3 June 2018 (UTC)
The category Category:Photographs by Dietmar Rabich/Photographs selection is now empty. --XRay talk 16:29, 3 June 2018 (UTC)
  • @Tuvalkin: I wasn't dissing you, I was dissing it. And it either wasn't working properly for some reason or it was a very strange gadget if it would only allow you to fave 1 photo. Now it does work, but I have no idea what changed. You saw the link to my edit: the gadget is not even supposed to be able to unfave one photo and fave another in one action, so clearly it wasn't working properly. - Alexis Jazz ping plz 19:24, 3 June 2018 (UTC)
  • OK thanks. Charles (talk) 18:03, 3 June 2018 (UTC)
  • @Charlesjsharp: That says specifically "Categories shouldn't be created to collect files based on a user's personal opinion (e.g. User:Example's favourite pictures); user galleries may be used for such purposes instead as described above.". Category:Photos by User:Example would be for all your photos and it would indeed look like you don't have that yet. (yet..) - Alexis Jazz ping plz 18:05, 3 June 2018 (UTC)
  • ? No point in putting all (= several thousands) of images in one category. If I'd wanted to do that I could have done so 10 years ago! I want to make it easy for visitors to see the photos I consider are my best. FP, with its narrow selection criteria, doesn't do that. Charles (talk) 20:48, 3 June 2018 (UTC)

Category hierarchy

Hello! Whilst adding photos to my articles, I noticed there are categories inside of categories that probably shouldn't be there. Take this one for example - it contains another subcategory, which contains some of pictures listed in the first category. Which is probably an error, right? I was about to merge those two, but I can't seem to put my finger on it. Can anyone help? --GeXeS (talk) 18:22, 4 June 2018 (UTC)

Ah, so that's it. Now I know what it is, but I still feel no reason to have it that way, even though the COM page says Galleries should not be created if they merely duplicate the purpose of a category. However, this does not mean they should be deleted or "merged". Categories will always be categories, but galleries can turn into something much more. - in this case (and a few more I've recently stumbled upon), the pics in the gallery are by no mean better than those in the parent category. Usually, the category has way more interesting medial content. But OK, at least now I know. Thank you. --GeXeS (talk) 18:40, 4 June 2018 (UTC)
@GeXeS: a gallery named for a category should contain a ‘curated’ selection of images, chosen for superior quality or for their illustration of significant characteristics or features of the topic. If the contents seem haphazard, feel free to prune, replace, or rearrange them (for one thing, our collection may have improved considerably in scope or quality since the gallery was created), but otherwise such pages don’t usually need much in the way of raison d’être.—Odysseus1479 (talk) 00:42, 5 June 2018 (UTC)
@Odysseus1479: I see, OK. --GeXeS (talk) 05:36, 5 June 2018 (UTC)

Tech News: 2018-23

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

  • The MonoBook skin has been optimised for mobile devices. It now looks different. [25]
  • Planet Wikimedia collects blogs about Wikimedia. It will now use the Rawdog feed aggregator to do this instead of Planet. [26][27]
  • Redirect links in Special:WhatLinksHere now link to the original page and not the target page. This was done earlier and changed the used messages on some pages. This was a problem for wikis that customized the message. A new change fixed this by using the old messages with one more parameter for customization. Wikis that already changed their customized messages will have to move the customization back again. [28]

Problems

  • You will not be able to edit some wikis between 06:00 and 06:30 UTC on 13 June. You can see if your wiki is one of them.
  • MassMessage did not work 24–28 May. This is also why last week's Tech News was late. [29]

Changes later this week

  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 June. It will be on non-Wikipedia wikis and some Wikipedias from 6 June. It will be on all wikis from 7 June (calendar).

Meetings

  • Recurrent item 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 5 June at 18:30 (UTC). See how to join.
  • Recurrent item Advanced item You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 6 June at 15:00 (UTC). See how to join.

Future changes

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

21:54, 4 June 2018 (UTC)

June 05

Commons:Photo challenge April results

Portraits of influential women: Entries • Votes • Scores
Rank 1 2 3
image
Title ATLANTIS Andrea Berg in Chemnitz im Februar 2014.
Author Superbass Rwetendorf Kora27
Score 18 18 10
Aircraft: Entries • Votes • Scores
Rank 1 2 3
image
Title Heissluftballon und Mond am Himmel über Speyer Acrobatics demonsration under a hot air balloon in Thouars, France Flugschau 2013 in St. Petersburg, Russland.
Author Kmtextor PCouton Kora27
Score 20 18 11

Congratulations to Kmtextor, PCouton, Superbass, Rwetendorf and Kora27. -- Jarekt (talk) 02:18, 5 June 2018 (UTC)

RfC: Plans to graduate the New Filters on Watchlist out of beta

Collaboration team is announcing plans to graduate the New Filters for Edit Review out of beta on Watchlist by late June or early July. After launch, this suite of improved edit-search tools will be standard on all wikis. Individuals who prefer the existing Watchlist interface will be able to opt out by means of a new preference.

The New Filters introduce an easier yet more powerful user interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting,the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning. If you’re not familiar with the New Filters, please give them a try on Watchlist by activating the New Filters beta feature. In particular, it would be very helpful if you can test the new functionality with your local gadgets and configurations. The documentation pages provide guidance on how to use the many new tools you’ll discover.

Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us know on the project talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed. - -Kaartic (talk) 17:27, 5 June 2018 (UTC)

Missing file

Tracked in Phabricator
Task T196469

Hello. I cannot find any more a file that I have uploaded. I can see it in this category, but when I click on the image I get on this page which is empty. I cannot find any deletion log for this page. Can someone understand what happens? Thank you. BrightRaven (talk) 12:35, 5 June 2018 (UTC)

I have opened a task on Phabricator: https://phabricator.wikimedia.org/T196469. BrightRaven (talk) 14:04, 5 June 2018 (UTC)
It is resolved now: File:Emigration-of-the-Huguenots-1566-by-Jan-Antoon-Neuhuys.jpg. Ruslik (talk) 09:42, 6 June 2018 (UTC)

Planned undeletion

Wouldn't it be handy that if an educational image gets deleted because it's still protected by copyright that it could be deleted until the time that the copyright expires? For example an image of some blueprints for an early aeroplane in a country where the copyright tends to be valid for 120 years or something that was created in 1910 get deleted on Wikimedia Commons that the deleting sysop could choose "delete until January 1st, 2030", as I've seen several images of art or other things uploaded whose copyright will expire in 2019 it seems like a hassle to delete them now, wait a year, and then request undeletion. If this were done automatically it could reduce duplicates being uploaded and if no-one is that hypothetical 2030 wishes to re-upload it then the image is simply (and unfortunately) lost from Wikimedia Commons forever. In-scope photographs could then always be "temporarily deleted" the same way block settings are customisable as on the French Wikipedia blocks for 150 years are normal and sysops could also manually decide to block accounts for a certain amount of years, so why not extend this feature to the deletion of in-scope images and other media that could be very useful in the future? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:12, 6 June 2018 (UTC)

@Storkk: Do we have to bother admins with that? I always add the category myself. I see other users do it too. Or do you only mean already closed DRs? Actually I would add the category to that too, I just didn't run into any such case yet I think. - Alexis Jazz ping plz 13:04, 6 June 2018 (UTC)
I don't think there are hard and fast rules... you just want to avoid adding it incorrectly, especially since the undeletions happen essentially in bulk, and adding to the complexity of the start-of-year reviews for undeletion won't be well received. I suggest it's probably best not to add it yourself to a DR that is closed & archived unless you are close to absolutely certain that you are correct and that there are not ancillary reasons for deletion that weren't explicitly stated in the DR. Closed DRs get very few eyeballs. On the other extreme, I'd also suggest that if you were the nominator and the DR has not closed yet, it's probably OK to add it. If you're a License Reviewer, you're probably OK to add it to others' still-open DRs too. Again, these are just my views, they are not rules. If in doubt, ask an admin... and if there are few eyeballs to double check your work, calibrate your doubt threshold accordingly. Storkk (talk) 13:35, 6 June 2018 (UTC)

Swap images, and possibly delete one

Hi, sorry for bothering here. Please point me to a more appropriate venue if there's one. I would appreciate some help in replacing File:CollinaD'Oro-coat of arms.svg with File:Collinadoro stemma colori.svg, and have the former deleted. The latter was provided by the municipality which is apparently experiencing some issues due to the widespread usage of the wrong version. Thanks, Elitre (talk) 18:37, 5 June 2018 (UTC)

June 06

There is a problem with {{States of Germany}}, used in some thousands of categories, for example at the top of Category:Train stations in Baden-Württemberg. There are no blue links, but only black text.

For comparison (without problems), please see {{Countries of Europe}} e.g. at Category:Rail transport in Germany.

Can someone fix the link issue for "States of Germany"? --Te750iv (talk) 13:05, 6 June 2018 (UTC)

It is related to incorrect treatment of bdi tag. Ruslik (talk) 17:03, 7 June 2018 (UTC)

Commons Categorisers Meetup during Wikimania 2018 scheduled

This year's Wikimania will feature the 3rd edition of the Commons Categorisers Meetup. The meetup is scheduled for Friday, 20 July 2018 at 18:00 in room Paarl. All Commons users, attending Wikimania are invited to join! The minutes will be posted here after the meetup. --MB-one (talk) 15:08, 7 June 2018 (UTC)

@MB-one: Friday 20th, surely? Thanks. Mike Peel (talk) 16:23, 7 June 2018 (UTC)
Of course 20th. Thanks, Mike --MB-one (talk) 16:54, 7 June 2018 (UTC)

Templates obsoleted by {{Wikidata Infobox}}

With the creation de {{Wikidata Infobox}}, some templates, which provide information already present in the file, how {{Object location|40.429009|-3.696402|type:landmark_region:ES}}, {{On Wikidata}}, <nowiki>{{COAM|F2.143}} y {{BIC|RI-51-0005028}}, they seem to be outdated, and they are somewhat useless, so I would like you to give me your opinion on what to do with them.

MONUMENTA Discusión 15:33, 28 May 2018 (UTC)

Pi bot (talk · contribs) can automatically remove some of these from the categories where they are no longer needed - it already removes {{On Wikidata}} and a few others when adding the infobox. I'm currently working on the IDs - if you can give me the template name + Wikidata property number + tracking category, then I can bot-migrate these to Wikidata wherever the infobox is currently used. Others that contain local information, like {{Object location}}, need manual checks/removal or more complex bot code. Thanks. Mike Peel (talk) 17:17, 28 May 2018 (UTC)
Actually Mike Peel, I would like to devote myself to checking and eliminating those templates, and I need to know which ones I could eliminate and not, because with {{BIC|RI-51-0005028}},and {{COAM|F2.143}}, I doubted, and with the information template, {{en|INJUVE Headquarters}} I will get out of line.
Very thankful MONUMENTA Discusión 17:59, 28 May 2018 (UTC)
My view is that if it's basic information (IDs, very short descriptions) that's also shown in the infobox, then it could go, while more complicated things need more thought - but others may disagree. Thanks. Mike Peel (talk) 18:49, 28 May 2018 (UTC)
 Question Does {{Geogroup}} use data from {{Wikidata infobox}}? If not, {{Object location}} should stay, but at least it would get rid of things showing up twice on maps because of the {{Camera location}} which is rarely useful because that is generally within metres of things. Rodhullandemu (talk) 18:18, 28 May 2018 (UTC)
@Rodhullandemu: I'm not sure, do you know who's the developer(s) of that? Ideally they should show the coordinate from Wikidata, which would then be the same as that shown in the infobox. Thanks. Mike Peel (talk) 18:45, 28 May 2018 (UTC)
Template:Answer, Rodhullandemu, i'm talking about templates in the categories, not in the archives, of the location of the photographed property, not from taking the individual photographs. MONUMENTA Discusión 18:49, 28 May 2018 (UTC)
I don't think {{Geogroup}} uses data from either {{Object location}} or {{Wikidata Infobox}} when those templates are used on a category. Neither of those invokes {{#coordinates}} in that case, so {{Geogroup}}'s maps can't see subcategories' co-ordinates. --bjh21 (talk) 21:17, 28 May 2018 (UTC)
{{Geogroup}} has a level parameter, and shows all the coords found in the root category down to the given level. So it sees subcategories' co-ordinates. But the same functionality can be achieved with user scripts or central menu configurations (see User:Herzi Pinki/common.js, section // geohack). {{Geogroup}} is based on the geohack stuff.
About {{Object location}} and {{Camera location}}: Please do not remove {{Camera location}}, when {{Object location}} is provided through WD (for images, for categories IMHO {{Camera location}} does not make sense). Camera location can be quite different from Object location for far away objects (like mountains) and makes sense to show which side of a building the photo was taken from. Furthermore, I ran across some really off-object coordinates on WD, especially those taken from geonames, so please do not remove {{Object location}} if it differs from WD location. --Herzi Pinki (talk) 00:06, 29 May 2018 (UTC)
I suggested in past that Pi bot (talk · contribs) should keep report what is still remains on pages after applying {{Wikidata Infobox}}. This will best place to apply manual processing. From my opinion from test run reviews, manual descriptions and images are hardest things for automated processing. --EugeneZelenko (talk) 13:46, 29 May 2018 (UTC)

@Mike Peel: Here's a list of some templates I know which either are allready completely obsolete or could be removed when the WD infobox displays their features:

  • {{PeopleByName}} ... outdated way to create person categories (at least ones with a existing Wikidata item); intended to not be used directly but instead be substituted into a category page; >32000 times directly used
  • {{People by name}} ... redirect to the template above
  • junk text inserted by the peoplebyname template:
<!-- [[Category:Year of birth missing]] -->
<!-- [[Category:Year of death missing]] -->
such information should be considered obsolete when the category is linked to Wikidata
  • {{Translation table}} as it is used f. ex. in Category:Machines ... as I know this one should just be used to show a group of translations of the category name; but sometimes it's also used for longer descriptions which makes it a bit tricky. In my opinion this is an outdated template as it is also not mentioned on the summarizing table of localization templates shown f. ex. on: Template:En#Other_multi-lingual_templates
  • {{On Wikipedia}} ... per documentation this one should only be used to provide links to wikipedia when they cannot be shown as interwikis; this only applies when the shown interwikis are links to categories and some would also want links to articles
  • {{Authority control}}
  • {{Sisterheader}} and related ones f. ex. in Category:United Nations ... as I see it some of these sister links are allready unnecessary to show within this template because they are allready shown automatically on the left side of each page above the interwiki links.

This of course is my personal view. --Zaccarias (talk) 20:07, 28 May 2018 (UTC)


And:

MONUMENTA Discusión 23:12, 28 May 2018 (UTC)

About removing IDs I would ask you to be careful. See e.g. {{Doo}} or {{Tiroler Kunstkataster}}, which provide extra navigational features for easier maintainance of categories, which the Wikidata Infobox cannot provide (at least I don't see how this could be done without bloating the infobox or needing intermediate navigational steps). --Herzi Pinki (talk) 00:06, 29 May 2018 (UTC)
Note that {{Object location}} has also been used for things like ships where the location may change between images. MKFI (talk) 06:48, 29 May 2018 (UTC)
  • What about avoiding those of… anywhere? The Wikidata community is obviously incapable of creating valid geolocation. Scrubbing lats and longs off from Commons, feed them to Wikidata, and then vandalize erase that geodata from Commons when inserting a transclusion from Wikidata is bad enough — to skip the 1st of these three steps is even worse. -- Tuválkin ✉ ✇ 18:41, 30 May 2018 (UTC)
  • With the bot edits I've been making using Pi bot (talk · contribs) I've been taking as conservative an approach as possible, and any data that the bot removes should precisely match that on Wikidata as displayed in the infobox. The rest need manual edits. Thanks. Mike Peel (talk) 22:36, 30 May 2018 (UTC)
  • No, the most “conservative” approach (lovely word choice) is to leave Commons data the heck alone. If/when there’s discrepancies, those should be mannually fixed (by means of human brain intervention, not just the cheap human-instead-of-bot labor so many like to engage on), when not, leave on the (concordant) data from both separate sources. -- Tuválkin ✉ ✇ 20:45, 31 May 2018 (UTC)
  • Not okay, since Wikidata has proven to have a weak volonteer base and an unreliable interface, easy to be misused by both befuddled editors and by trolls or vandals (or even hackers?). Keeping concordant values separately in Commons will cause a visible unsynch every time Wikidata values are messed with, allowing anybody to notice it almost immediately. Removing hardcoded Commons values in our content and relying solely in transclusions will cause that problem to go on unremarked for much longer, misleading page visitors all that while. (This problem, of course, affects not only geolocation but each and every instance of data already being syphoned off to Wikidata or planned to be.) -- Tuválkin ✉ ✇ 20:45, 31 May 2018 (UTC)
  • @Jean-Frédéric: Are you absolutely sure and confident that it is impossible to hack into the Wikidata database? If so, I’m sincerely glad and relieved. Please note that I mentioned hacking in a parenthetical remak, with a question mark. My main criticism stands, though. -- Tuválkin ✉ ✇ 23:29, 8 June 2018 (UTC)
  • This argument doesn't make sense to me. The main issue is that it assumes that every difference is vandalism, while most will be constructive edits, so if you want to use the differences to find vandalism then you have to go through all of the good changes as well, copying them all over here. That's a lot of work. It also means displaying duplicate information in the categories, which makes them less useful for their main purpose of making the media files easy to find. Thanks. Mike Peel (talk) 10:53, 1 June 2018 (UTC)
    1. How would keeping geocoordinates duplicate information in categories? I don't think this needs to be done with all data, because most can be "eyeballed" accurately, but geocoordinates cannot.
    2. I agree that if you want to find vandalism then you have to go through all of the good changes as well; that's always the case, and does not strike me as a bad thing. - Jmabel ! talk 15:41, 1 June 2018 (UTC)
  • Maybe I wasn't clear enough: both on Commons and on Wikidata, you can eyeball most diffs and pretty readily spot vandalism. With geocoordinates, you have to look at more than the diffs to know. I'm pretty sure Wikidata items aren't as consistently monitored as Commons categories, in terms of someone checking each such change to make sure it's valid. If changes in geocoordinates are entirely a Wikidata affair, I think they will be less well monitored. If we keep the coords in both places and note any discrepancies that arise, we will probably benefit both projects by more readily spotting vandalism. - Jmabel ! talk 22:53, 1 June 2018 (UTC)
  • I'll second that. There is a very good reason for keeping geocoords here: when adding an image to an existing category, as I did earlier, you can copy and paste the {{Object location}} into Upload Wizard's "Other information" field to ensure that we don't get minor discrepancies for objects in the same place. You can't do that with the Wikidata, which doesn't make things any easier; you have to either (1) copy the coords, which somehow always seem to render in degrees, minutes & seconds format which is so much less useful and modern than degrees & decimal degrees, or (2) go to a website such as gridreferencefinder and do what you did when you created that category. No point in duplicating work, I feel. And if you set the "scale" parameter in that template properly, you don't need to zoom a tiny Wikidata infobox map "to see if it's in the right place". Rodhullandemu (talk) 23:00, 1 June 2018 (UTC)
Hmmm − speaking as a fairly strong advocate of Wikidata benefits, I think Jmabel makes a good point. Making templates like {{Object location}} Wikidata-aware and ensuring there is no discrepancy between Commons and Wikidata makes perfect sense to me − it *will* and *does* catch mistakes (some on WD-side, and some definitely on Commons side). Working through Category:Pages with local coordinates and mismatching Wikidata coordinates to resolve these discrepancies also makes sense. However, I don’t see the strong argument for then removing the local coordinates. I understand this means double-storing = double-maintenance cost, but after all, if the Commons community wants to shoulder that, then why not. Assuming a perfect Commons/WD synced state, when/if coordinates change on either side, then the page shows up in the maintenance category where it can be easily fixed.
Double-storage does not necessarily makes sense for all types of data (I certainly don’t mind not having to maintain Creator templates locally anymore ; and at the very end of the spectrum {{On Wikipedia}} makes strictly no sense anymore), but it might make sense for coordinates, especially if the alternative makes a lot of people here uncomfortable.
Jean-Fred (talk) 09:28, 2 June 2018 (UTC)

I am neutral about {{Object location}}, if some people thinks that's still useful,I'll not add it, but will not remove it either while placing {{Wikidata Infobox}}. But other templates, like the ones about cultural heritage (some of which I've made myself) are rather totally dispensable, and only add to the clutter along with description, languages, and an incredible lot of pretty much useless stuff that sometimes gets pilled there, and makes usage of the category quite hard.-- Darwin Ahoy! 17:03, 2 June 2018 (UTC)

May 29

Overwriting files

I'm very confused by Commons:Overwriting existing files#Respect content creators. At File:Coat of Arms of Camilla, Duchess of Cornwall.svg, User:Sodacan created an image of a coat of arms and uploaded it. Some years later he overwrote the file with a new version that had a new element (the addition of a circlet around the shield). Many years later User:DrKay and User:Keivan.f have reverted to the earlier version without the circlet. Administrator User:Jcb insists that the actions of the latter two editors are violations of the overwriting guideline because uploaders are always allowed to overwrite their own files and other users should defer to the original creator. My reading of the 'Respect content creators' section and the discussion at Commons talk:Overwriting existing files/Archive 1#Uploader's decision is that uploaders can only overwrite their own files when the changes are uncontested or done shortly after upload. Which is correct? That uploaders can always overwrite their own files, regardless of the wishes of anyone else, or that uploaders should only overwrite earlier versions of a file when the change is uncontroversial and recent? Celia Homeford (talk) 09:49, 1 June 2018 (UTC)

Any time there is controversy with overwriting, rather than having a revert war, those interested in different versions can create a new file with the image they prefer. This avoids having to judge who is more "right". Whether the new file or the previous one is used globally on different Wikipedia projects, is a question for those projects along with the need for reliable sources and consensus. The alternatives should exist here on Commons unless they are misleading in their own right as an image, such as a photograph of a living person or a historic event that has been tampered with. --Fæ (talk) 09:54, 1 June 2018 (UTC)
Yes, it's clear that both files should be uploaded separately. What's not clear is whether uploaders are always allowed to control their own files. Celia Homeford (talk) 09:55, 1 June 2018 (UTC)
It's not a question of control, but civility. Non-controversial changes, such as crops which remove an unnecessary border, can be done without expecting consultation. If the uploader reverts, that's normally a sign that there should be discussion first, or that a split to a new file is the best next step.
By the way, User:Fæ/BLP_overwrites is a maintained report which helps identify the most controversial overwrites for photographs of living people which are in use on the English Wikipedia. --Fæ (talk) 10:00, 1 June 2018 (UTC)
Yes, I know. Again, the issue is not whether there should have been a discussion. If I'm reading you rightly, all three have violated the guideline by failing to have a discussion and that uploaders do not have control over an image. Celia Homeford (talk) 10:06, 1 June 2018 (UTC)
Correct. I agree that although in almost all cases an uploader is probably fine to overwrite their own upload, in some cases their action may not benefit the image quality or accuracy, and a split may be needed. For example, I may digitally enhance an archive image, say, removing scratches from an old photograph or adjusting the saturation for a photograph of an oil painting, but overwriting the official archive original with my enhancement would be potentially controversial and may harm the overall quality of our collection. --Fæ (talk) 10:13, 1 June 2018 (UTC)
My reading is essentially the same as yours: "Respect content creators" says that if the creator is around then others shouldn't overwrite the file without consulting the creator. It doesn't give overwrites by the creator any special status (which is as it should be: files on Commons are owned by the community, not the uploader). --bjh21 (talk) 10:18, 1 June 2018 (UTC)
The "Respect content creators" clause is fairly clearly concerned with photographs and not with illustrations. The overwriting concerns with photographs are more to do with well-meaning-over-enthusiastic-over-confident users with basic photo software making a photo worse. Here the dispute seems to be whether the illustration is factually correct.
Bjh21, while an "uploader" has no special status at all, the files on Commons, unless they are in the public domain, very much are owned by the creator, and very much not owned by the community. The concern here is with the file-description page that hosts files and provides a "URL" whereby projects like Wikipedia can use our images. There is a tension with Wikipedians who find it the easiest way to change what images appear on Wikipedia is to overwrite files on Commons, where as Commons, as a repository, would rather distinct or disputed images were stored separately. In the argument about which images get which URLs, that's a matter for the community, but the actual files are generally owned. That is different to Wikipedia, which is a collaborative editing project, where ownership of content (articles) is shared among all editors. -- Colin (talk) 10:46, 1 June 2018 (UTC)
What do you mean by "owned" here? From the first section, I'd think that you're talking about copyright, but then you say that Wikipedia articles aren't owned by their authors and that's obviously untrue from a copyright perspective: The fact that contributors keep copyright in their contributions is why clause 11 of COM:GFDL exists. --bjh21 (talk) 15:35, 1 June 2018 (UTC)
Bjh21 copyright is the main set of rights that I have as owner of my images that are hosted on Commons. They don't belong to Commons, WMF or "the community" in any sense whatsoever. I didn't say "Wikipedia articles aren't owned by their authors", please read carefully. I said "Wikipedia is a collaborative editing project, where ownership of content (articles) is shared among all editors [of those articles]". With the exception of media in the public domain, media on Commons is generally owned by one person or entity. It is rare here that media has multiple editors (examples would include diagrams and illustrations that are reworked); there is no community focus encouraging collaborative editing of media; nor does the UI support it in anything other than the most primitive and unsatisfactory manner. It is really, really, important that we do not make false claims like "files on Commons are owned by the community" because that could seriously put off anyone thinking of donating images here or giving their work a free licence. -- Colin (talk) 09:30, 4 June 2018 (UTC)
Thank you for the explanation, and apologies for (accidentally) misrepresenting you. Since collaborative work on files is very rare (demonstrated by under 100,000 files' using {{Derived from}}), I agree that we may as well make a feature of that. On the other hand, I still think that in some senses files here are not owned by their creators: Commons frequently keeps files whose creators wish them deleted, for instance, and deletes files whose creators wish them kept. --bjh21 (talk) 11:01, 4 June 2018 (UTC)
Hmm, depends how meta you want to take your definition of "file". In once sense, it is possible that no files are ever deleted, just any public reference to them -- I don't really know the underlying mechanism. If we're talking bytes represented by magnetic particles, then they are owned by WMF who own the servers, though anyone may take a copy. And you are right that the creator, by applying a free licence to the work, loses some control over whether Commons hosts the file here, and the community has a big say in that. But in terms of our vernacular, a "file" embodies a "work of copyright". I upload my "file" and can download a "file". That file, no matter whether on my hard disc, hosted on Commons, or on your hard disc, represents a work of copyright that I own. The decisions the community makes about whether or not to host a file, what URL to give it, how to describe it, etc, all concern the curatorial role performed by the community. Only a subset of the Commons community actively produce the content the project is curating, and a fair chunk of the content comes from non-Commons users. Quite different to Wikipedia. So I think it is more useful to say we collectively manage a media hosting website, collectively own much of the text here, but the actual non-text media is not a collaborative project and not collectively owned. In a similar way, Flickr does not own any of the images it hosts. -- Colin (talk) 11:36, 4 June 2018 (UTC)

Again, overwriting files creates conflicts and questions. The solution is not to describe the problem and describe what to do and what not to do. You will only prevent this if you design a system that allows or not allows to overwrite. So, overwriting should be allowed in the user profile. Only when one has a certain status - original uploader, administrator - one is allowed to overwrite a file. And only then this issue is solved. Now, everyone is able to overwrite any file, which I think is a good thing. But if we want to change that, we will have to make a system change. Until then this will be case for continuous discussion. Jan Arkesteijn (talk) 09:15, 8 June 2018 (UTC)

What does the license CC-BY permit?

When I find a file on the internet licensed under CC-BY I can copy it to Commons. Sometimes an older version number of the license (f.i. CC-BY-3.0) is used. Does this license permit me to upload it with the highest version number of CC-BY (at the moment 4)? Jan Arkesteijn (talk) 11:49, 5 June 2018 (UTC)

No. All CC BY licences are acceptable on Commons, and you should use the version that the work was licensed under. If you're using the Upload Wizard and it doesn't have an option for the right version, choose "Another reason not mentioned above" and enter the appropriate licence tag from Commons:Copyright tags#Free Creative Commons licenses (e.g. {{Cc-by-3.0}} for CC BY 3.0). --bjh21 (talk) 12:01, 5 June 2018 (UTC)
(Edit conflict) :You should always upload with the license specified by the copyright holder. Ruslik (talk) 12:03, 5 June 2018 (UTC)
Ok, but BY means attribution required. I can do that with the highest version as well. Does CreativeCommons say something about it.?Jan Arkesteijn (talk) 12:38, 5 June 2018 (UTC)
The legal code for CC BY 3.0 is quite clear: "You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform." More practically, pre-4.0 CC BY licences require associating the original title with the work, while 4.0 does not, so distributing under 4.0 would not satisfy the requirements of 3.0 and lower. Note that things are different for derived works. --bjh21 (talk) 12:51, 5 June 2018 (UTC)

What to do with f.i. [33]? Clicking the link will not lead to a page that specifies the version. Jan Arkesteijn (talk) 12:37, 5 June 2018 (UTC)

You use {{YouTube CC-BY}}, which uses the CC BY 3.0 license that you can reach by clicking "SHOW MORE", "Creative Commons Attribution license (reuse allowed)", and then "CC BY" to get to https://creativecommons.org/licenses/by/3.0/legalcode. If a source really doesn't specify a version, then we can't use it at all, since we can't satisfy the requirement to link to the correct licence. --bjh21 (talk) 12:43, 5 June 2018 (UTC)
As far as I can see it only leads to Youtube Help CreativeCommons. As for {{YouTube CC-BY}}, why don't we add that to the Upload Wizard? Jan Arkesteijn (talk) 13:06, 5 June 2018 (UTC)
And on that page there is a link to https://creativecommons.org/licenses/by/3.0/legalcode, i.e. version #3. Yeah, access to licencing information on YouTube and some other sites is f...d up. --jdx Re: 13:45, 5 June 2018 (UTC)
(Edit conflict) On that page, for me at least, the second sentence says "YouTube allows users to mark their videos with a Creative Commons CC BY license." "CC BY" is a link to the correct licence on the Creative Commons site. I suspect the reason why {{YouTube CC-BY}} isn't in the Upload Wizard is simply that it's quite rare: only 27,000 files use it, which is far fewer than any of the CC licence tags currently offered by the Upload Wizard. --bjh21 (talk) 13:50, 5 June 2018 (UTC)
Or is that because the option is not available in the wizard?Jan Arkesteijn (talk) 19:46, 5 June 2018 (UTC)

If I interpret this well, CC-BY is just as restrictive as CC-BY-SA. In fact, CC-BY is also Share Alike because it does not allow me to use any other license than CC-BY, am I right? Jan Arkesteijn (talk) 12:05, 8 June 2018 (UTC)

@Jan Arkesteijn: English Wikipedia details the differences in the Creative Commons licenses at en:Creative Commons license, Creative Commons does that differently at https://wiki.creativecommons.org/wiki/License%20Versions.
@Jan Arkesteijn: You're not correct, because the discussion above only applies to the original work. Neither CC BY nor CC BY-SA licences allow you to distribute the original work under any other licence. The difference between the licences lies in their handling of derived works (which CC call "adaptations"), but that's quite complicated and I don't think I understand it well enough to explain it. This section of the CC document mentioned above makes a good attempt (and includes the phrase "reasonable minds do differ on this point"). --bjh21 (talk) 13:39, 8 June 2018 (UTC)
OMG, this is complicated. The reason I raised this question is that I am sometimes uploading stills from Youtube videos. So these are derivatives. Sorry, but my shutters go down when I see legal code. It simply does not enter my brain. So I try to find readable text. If I read en:Creative Commons license I understand that even on a derivative of a CC-BY work I have to copy the CC-BY license. When the source is CC-BY-SA the derivative should be CC-BY-SA or CC-BY. Am I right? Jan Arkesteijn (talk) 17:32, 8 June 2018 (UTC)
If you're not modifying the original work or creating a derivative from it, you must use the original license when distributing it. A still from a video wouldn't count as a derivative unless you do something to change the image, like modifying the brightness and color settings or cropping it (and even then, there's some debate about how significant the changes need to be for them to be copyrightable). If you do modify the image, and the video was licensed CC BY, you can distribute your modified image under a different license so long as you provide a credit line with the original work's name (if available), the author, a link to the relevant CC license, and mention what changes you made. You can find more on how to properly attribute Creative Commons licensed works here. The human-readable summaries of the various CC license – here's CC BY 3.0, for example – are pretty easy to understand and their FAQ has a lot of useful info about using or modifying CC works.
Creative Commons also maintains a list of compatible licenses for CC BY-SA. In short, derivatives of works licensed CC BY-SA should be distributed under the same license or a later version of it, with the exception of CC BY-SA 1.0, which is only compatible with itself. Additionally, CC BY-SA 4.0 is also compatible with a couple of non-Creative Commons licenses, as explained in the link I gave. Again, this is only for derivative works. If an original work is licensed CC BY-SA 3.0 and you upload it here unmodified, it will still be licensed CC BY-SA 3.0. clpo13(talk) 18:25, 8 June 2018 (UTC)
Also, when you're choosing a license in the Upload Wizard for a still from a CC BY YouTube video, you can select "This file is not my own work" and then "Another reason not mentioned above" and paste {{YouTube CC-BY}} in the box to use that specific template. clpo13(talk) 18:54, 8 June 2018 (UTC)
By far the simplest is always to use the same license initially offered. - Jmabel ! talk 23:00, 8 June 2018 (UTC)

Accidental upload of non-PD material that is likely still fair use

If I understand correctly, an image like File:Charles Autobees 1812 to 1882.jpg is not PD if it wasn't published before 1923, even if it was taken and the subject died and likely the artist died before 1923. Since we don't know when the image was first published, is there a way we could remove it from commons, but leave at at en-wp under a fair use justification? Does it go to Commons:Deletion requests, or is there another process? Note, I asked the uploader if they had better PD evidence, and the didn't - see discussion at en:User talk:CaroleHenson#Image of Charles Autobees). Smmurphy (talk) 21:37, 7 June 2018 (UTC)

June 08

Category:Pages where the unstrip size limit is exceeded

Can someone please add a description to this category? What does "unstrip size" mean, how is its limit defined? --тнояsтеn ⇔ 11:56, 8 June 2018 (UTC)

@Thgoiter: ✓ Done, except answering "how is its limit defined?".   — Jeff G. ツ please ping or talk to me 12:30, 8 June 2018 (UTC)
Thank you! --тнояsтеn ⇔ 12:39, 8 June 2018 (UTC)

Objection to placement of non-notable naked recumbent woman on homepage today

I agree with this post, the poster of which was chastized for vandalism by Steinsplitter. I spend a lot of time trying to upload paintings of women doing more than reclining in the nude and seeing this is very discouraging. I have no problem with such images on Commons, but they certainly do not constitute art suitable for all cultures to be posted to the homepage. I find assuming as much just distasteful. I also noticed that there appears to be no forum where you can place such objections as the above poster attempted. In fact, I could not even locate the discussion where it was OK to place this in any homepage queue at all. Jane023 (talk) 16:18, 8 June 2018 (UTC)

Jane023: I would say that for today it is quite late. For the future, I suggest that you participate in choosing the image on the Main Page among our featured pictures. I am quite sure that people doing that welcome any help. For this month, some media of the day are still missing. Regards, Yann (talk) 16:25, 8 June 2018 (UTC)
(ec) Your linked diff shows vandalism, not a "placement of objections", since it removed the template. There is also no requirement that an image placed on the main page "constitutes art suitable for all cultures", since it would be very hard to find such an image. Sebari – aka Srittau (talk) 16:28, 8 June 2018 (UTC)
Thanks for the responses. I think it would be useful to have a link from the hompage (next to the button that invites you to tweet the image) where the reader is directed to this information. I agree that it is hard to decide what "constitutes art suitable for all cultures", and therefore you basically need more eyes looking at the problem. I assume now that uploader placed the photo in the queue and received no objections, since the photo was already a featured image. The user who (mis)placed the comment indicating he/she found the image impolite should have been directed here for the same reason. Jane023 (talk) 16:33, 8 June 2018 (UTC)
Jane023: Here's the "discussion" about whether the nude should be "considered one of the finest images": Commons:Featured_picture_candidates/File:Fine-art-nudesunpine.jpg Glammmur (talk) 16:45, 8 June 2018 (UTC)
... and the matter is also being discussed at the photograph's talk page. Thincat (talk) 16:48, 8 June 2018 (UTC)
I don't care about whether Commons classifies it as featured or not, but it has no encyclopedic information content and as such should not be on the front page (any more than would a nice inoffensive but pretty and otherwise uninformative photo of a sunset). —David Eppstein (talk) 22:28, 8 June 2018 (UTC)
Commons is not an encyclopedia. - Jmabel ! talk 23:04, 8 June 2018 (UTC)
Jane023, etc: It is a Commons:Featured pictures selected by the volunteers participated in that project. Though every picture selected as a featured picture is eligible to be placed in a Commons:Picture of the day slot, it can be moderated if challenged. But it should be challenged/discussed a month ago because a lot of translation work is to be carried out prior to the day when an image is displayed in front page. Feel free to go through the next month's POTD and open a discussion on that talk if you've any suggestions. Jee 11:48, 9 June 2018 (UTC)
Yes thanks, I understand that. I also understand that this "problem" probably occurs much more often, and my attention was only drawn to it because of a complaint I saw. I guess there is no way to avoid placing potentially controversial images, simply because the community involved with the voting process is so small. I realize I can not change it. Sadly I must conclude that this is the reason why the English Wikipedia does not "reuse" the Commons homepage for their own "Today's featured picture" process. I see that neither process includes the possibility of feedback in a positive or negative sense, so the actual images shown are completely random depending on the nominator-du-jour, whether that is the person checking the main page nominations, or the person checking the featured image nominations. There is also only a path to point the reader to formerly featured images and not to the decision-making process at all, such the links given above. This would be a first step to draw in more users interested in oversight, but also potential uploaders. Jane023 (talk) 14:12, 9 June 2018 (UTC)
POTD in EN wiki also has similar issues and we had discussed some. The main difference is, POTD in EN is a user moderated; so chances that the moderator will open a discussion if they feel a discussion is needed. Jee 14:29, 9 June 2018 (UTC)

June 09

Can someone make the template for PD-BW-exempt?--Jeromi Mikhael (talk) 06:25, 9 June 2018 (UTC)

Yes, Botswana's copyright lasts for 50 years after the death of the author, and there would appear to be no reason it would be exempted. See COM:CRT#Botswana. Unfortunately, this won't be free until 1974+50+1=2025. I've nominated it for deletion. Storkk (talk) 09:14, 9 June 2018 (UTC)

Houston, we have a quality problem

Stumbled across 2 year old vandalism around the Popes [34] in Turkish and German, partly removed the next day, but remains kept for more than 2 years now. I do not want to blame anybody, but if the user who created that vandalism is globally blocked, is there any idea on how to check his or her edits on all wikis more accurately? At least 5 users could have seen the problem with the gallery. Luckily, only few people ever view gallery pages [35]. best --Herzi Pinki (talk) 23:26, 9 June 2018 (UTC)

The "Global contribs" link at the bottom of Special:Contributions/Coconaut is helpful for this. --bjh21 (talk) 11:31, 10 June 2018 (UTC)
this was not a technical, but an organizational remark. --Herzi Pinki (talk) 16:32, 10 June 2018 (UTC)
@Herzi Pinki: guc has been mighty slow lately. :(   — Jeff G. ツ please ping or talk to me 18:31, 10 June 2018 (UTC)

June 10

File:Vvedenskoye House.jpg

If someone knows the license of this image, please feel free to pass or fail it. Thank You, --Leoboudv (talk) 06:35, 11 June 2018 (UTC)

Tech News: 2018-24

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

  • In the Wikipedia app for Android or iOS users can create reading lists. The reading lists can be seen on different devices if you are logged in to your account. There is now a browser extension so you can add pages to your reading list from a web browser. At the moment it works with Firefox and Chrome. [36]
  • Advanced item There is a new version of Pywikibot. Pywikibot is a tool to automate tasks on MediaWiki wikis. [37]

Problems

  • The MonoBook skin was changed to make it work better for mobile users. This caused some problems. The change was rolled back to fix them. The new version is now back on the wikis. MonoBook users can opt out from the new responsive design. [38]

Changes later this week

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

Meetings

  • You can join the Readers Web team IRC office hour. There you can discuss tools to contribute on the mobile web for the existing MediaWiki skins. The meeting will be on 18 June at 16:00 (UTC). See how to join.
  • Recurrent item 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 12 June at 18:30 (UTC). See how to join.
  • Recurrent item Advanced item You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 13 June at 15:00 (UTC). See how to join.

Future changes

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

21:55, 11 June 2018 (UTC)

  • «The MonoBook skin was changed to make it work better for mobile users. This caused some problems. The change was rolled back to fix them. The new version is now back on the wikis. MonoBook users can opt out from the new responsive design.» You guys understand that if this was the synopsis for a lampooning of certain tendences in web development these days it would have to be toned down because it would feel over-the-top even for the most staunch opponents — and yet, here it is: Reality funnier/scarier than any satire. -- Tuválkin ✉ ✇ 00:02, 12 June 2018 (UTC)

June 12

How many images are uploaded to Commons per day?

Hi all

Is there any kind of counter of uploads per day?

Thanks

John Cummings (talk) 19:15, 7 June 2018 (UTC)

Wikimedia Commons started in September 2004, almost 14 years ago. It has now 47 million items, which means that over these years on average 9,400 items were added per day. Vysotsky (talk) 21:48, 7 June 2018 (UTC)
Make that a net average: many images are also deleted every day.—Odysseus1479 (talk) 23:42, 7 June 2018 (UTC)
There's https://stats.wikimedia.org/wikispecial/EN/TablesWikipediaCOMMONS.htm, column F. I'm not sure exactly what's included in "Articles new per day", but there are currently around 20k uploads per day. --ghouston (talk) 03:15, 8 June 2018 (UTC)
At that rate, we are due to hit 50 million uploads in about 135.6 days. That calls for a celebration!   — Jeff G. ツ please ping or talk to me 03:25, 8 June 2018 (UTC)
Mark it on the calendar, 21 October 18:00 UTC. --ghouston (talk) 05:48, 8 June 2018 (UTC)
I'll take the slight over on that. I'd bet some time in the evening of 24th of October. Storkk (talk) 14:50, 8 June 2018 (UTC)
Commons Growth

There is exponential growth of images on commons, but flatlining of editors, see: https://stats.wikimedia.org/wikispecial/EN/ReportCardTopWikis.htm#lang_commons . See also Special:MediaStatistics and Commons:Database_reports. --Atlasowa (talk) 09:37, 12 June 2018 (UTC)

I don't have a source but at some point last year I recall looking through the deletion logs and estimating that about 65,000 files had been deleted in a four week period. I'm not sure how many we delete now but the daily rate is probably around the 1,500—2,000 mark. Green Giant (talk) 10:36, 12 June 2018 (UTC)
@Green Giant: The daily file deletion rate is around 1,100—1,600 currently. --Atlasowa (talk) 21:22, 12 June 2018 (UTC)
@Atlasowa: near enough, give or take 400! :) —Green Giant (talk) 21:35, 12 June 2018 (UTC)

Hi all

As some of you may know there is a law being proposed in the EU that poses several threats to Wikimedia projects, Cory Doctorow has written an outline of how this law will effect Wikimedia projects.

There's also a discussion on Jimbo's talk page you might like to read/join.

Thanks

John Cummings (talk) 20:23, 7 June 2018 (UTC)

See also german discussion (with links) here: Commons:Forum#DSGVO_..._Auswirkungen_auf_Wikimedia_Commons,_KUG_und_Co. Sorry that is about the data protection directive. --Atlasowa (talk) 08:56, 12 June 2018 (UTC)

Cannot display updated thumbnail on WP page

I corrected an existing file and uploaded it to be used on the WP page Transverse Ranges File:SoCal Transverse Ranges.svg.

I had to try updating a few times but it worked, so the new figure can be seen from the WP page if I click it. But, the thumbnail didn't update and I can't figure out how to correct that. Any help? --BrucePL (talk) 18:59, 12 June 2018 (UTC)

The thumbnail updated spontaneously. I guess it takes time. --BrucePL (talk) 19:31, 12 June 2018 (UTC)

@BrucePL: I doubt it. I did purge. --jdx Re: 19:43, 12 June 2018 (UTC)
Thanks @Jdx --BrucePL (talk) 00:42, 13 June 2018 (UTC)

Crop tool down?

Is it? https://tools.wmflabs.org/croptool/ -- Tuválkin ✉ ✇ 18:20, 12 June 2018 (UTC)

Update on page issues on mobile web

Update on page issues on mobile web

Please help translate to your language Hi everyone. The Readers web team has recently begun working on exposing issue templates on the mobile website. Currently, details about issues with page content are generally hidden on the mobile website. This leaves readers unaware of the reliability of the pages they are reading. The goal of this project is to improve awareness of particular issues within an article on the mobile web. We will do this by changing the visual styling of page issues.

So far, we have drafted a proposal on the design and implementation of the project. We were also able to run user testing on the proposed designs. The tests so far have positive results. Here is a quick summary of what we learned:

  • The new treatment increases awareness of page issues among participants. This is true particularly when they are in a more evaluative/critical mode.
  • Page issues make sense to readers and they understand how they work
  • Readers care about page issues and consider them important
  • Readers had overwhelmingly positive sentiments towards Wikipedia associated with learning about page issues

Our next step would be to start implementing these changes. We wanted to reach out to you for any concerns, thoughts, and suggestions you might have before beginning development. Please visit the project page where we have more information and mockups of how this may look. Please leave feedback on the talk page.

CKoerner (WMF) (talk) 20:58, 12 June 2018 (UTC)

  • Hi @Tuvalkin: I posed here as Commons uses message box templates like {{mbox}} and {{ambox}}. The focus is on English Wikipedia at the moment, but whatever effort the Readers web team makes in better formatting for templates on mobile will be able to be used by all projects. CKoerner (WMF) (talk) 14:34, 13 June 2018 (UTC)

June 13

Help needed with translation

Template:PD-1996-text is running out of Lua memory (whatever it is) and we are in the process of moving the translations from Template:PD-1996-text {{LangSwitch}} based template to Template:PD-1996-text/i18n translation extension based template. We moved so far English, German, Polish and Hungarian text. If you speak other languages please help by translating text in Template:PD-1996-text/i18n to your language or by moving (and verifying) translation from Template:PD-1996-text. Thanks --Jarekt (talk) 12:47, 13 June 2018 (UTC)

✓ Done for French. Yann (talk) 13:54, 13 June 2018 (UTC)
Thanks, We still need about 10 translations moved by people who know the languages. --Jarekt (talk) 14:14, 14 June 2018 (UTC)

Which wiki project best for old Mayan archeology material?

An acquaintance reached out to me for help in disseminating some photographs she made of archeological survey maps of Mayan sites and a monograph about Mayan archeology. The works are in public domain because they were created in the 1930s and published without copyright notice. There are actually two works she digitized, via photographing the pages with a camera:

1. The Inscriptions of Peten Volume 4, by Sylvanus Griswold Morley, published 1938 This is mostly text, so perhaps Wikisources would be a better project to submit this to?

2. The Inscriptions of Peten Volume 5 Part 2, by Sylvanus Griswold Morley, published 1937 Mostly very oversized plates with maps on it. The person who digitized it unfolded the maps and photographed them from above. She made overall photos showing the entire map, then individual close-up shots showing details.

(Note: She wrote some additional copy about her process and how the individual images relate; she is prepared to give any creative common license necessary to cover her own contribution of these few explanatory paragraphs and of the photography.)

Here is a link to volume 1 in this series to give an idea of what type of work this is: https://babel.hathitrust.org/cgi/pt?id=mdp.39015019759706;view=1up;seq=51

Note that the person who did the digitization is not a professional photographer. She studies Mayan hieroglyphics and was frustrated that these 2 volumes have not been digitized and made available online, so she was scratching her own itch. The hope is that the historical/scholarly importance will outweigh any technical imperfections. The maps are combined into a single pdf though I have reached out to see if she can provide the separate files of individual photographs. She no longer has access to the volumes so there can be no do-overs.

So: 1) Should both of these works go straight to Wikisources? 2) Should the monograph (vol 4) go to Wikisources and the maps (vol 5.2) go here to Commons? — Preceding unsigned comment added by Eve Teschlemacher (talk • contribs) 23:15, 13 June 2018 (UTC)

(Sorry, forgot to sign original.) My acquaintance says she has original files but they are "a mess" with different scales and foreshortening. I assured her that those still have value and that a skilled photo editor could work with them. —Eve Teschlemacher (talk) 23:32, 13 June 2018 (UTC)

  • Since they are photographs, both should be uploaded to Commons first. Wikisource only hosts readable texts, that is to say: the text has to be typed out digitally, a proces called proofreading. --HyperGaruda (talk) 02:39, 14 June 2018 (UTC)

Weird Error Message

Tracked in Phabricator
Task T196512

Last couple of days - everytime I hit edit, I get an error message (below) slide in from right. I've changed nothing that I can see. Everything still works... 

Error:
https://commons.wikimedia.org/w/load.php?debug=false&lang=en-gb&modules=ext.3d%2CCodeMirror%2Ccharinsert%2CeventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.CodeMirror.data%2Clib%7Cext.CodeMirror.mode.mediawiki%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.eventLogging.subscriber%7Cext.math.editbutton.enabler%7Cext.uls.common%2Ccompactlinks%2Ceventlogger%2Cinit%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.supportCheck%2CtargetLoader%2CtempWikitextEditorWidget%2Ctrack%2Cve%7Cext.wikimediaEvents.loggedin%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CRegExp%2CString%2CTitle%2CUri%2Capi%2Ccldr%2CconfirmCloseWindow%2Ccookie%2Cexperiments%2Cicon%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Ctoolbar%2Cuser%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.edit%7Cmediawiki.action.edit.collapsibleFooter%2CeditWarning%7Cmediawiki.api.options%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.ui.button%7Cmediawiki.widgets.visibleLengthLimit%7Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Coojs-ui-widgets.styles%7Coojs-ui.styles.icons-editing-advanced%2Cicons-editing-styling%2Cicons-moderation%2Cicons-movement%7Cschema.UniversalLanguageSelector%7Cskins.monobook.mobile%7Cskins.monobook.mobile.echohack%2Culs%7Cuser.defaults%7Cwikibase.client.action.edit.collapsibleFooter&skin=monobook&version=1n6m8l6 at line 6: TypeError: $button.toggleClass(...).data(...) is not a function

Ronhjones  (Talk) 16:21, 14 June 2018 (UTC)

Does not happen on other wikis. Ronhjones  (Talk) 16:26, 14 June 2018 (UTC)
I reported this some days ago: phab:T196512. Maybe you can give some more details about which settings you are using. -- User: Perhelion 16:30, 14 June 2018 (UTC)

June 15

Categorie:Haagse Comedie

Can someone rename this to Category:Haagse Comedie? Made a typing error. Thanks. Hobbema (talk) 23:49, 20 June 2018 (UTC)

I found how to do this. Hobbema (talk) 00:14, 21 June 2018 (UTC)
This section was archived on a request by: Jmabel ! talk 06:33, 21 June 2018 (UTC)

Implausible License Information

Is there any kind of process to challenge licenses provided by an uploader I deem unlikely to have the necessary rights to do so? --Abderitestatos (talk) 02:25, 10 June 2018 (UTC)

  • You could ask the user first, but it's OK to go directly to nominating for deletion. Often, it's best to do just one or two images first as test cases. - Jmabel ! talk 03:40, 10 June 2018 (UTC)
But is there no place to evaluate a license before discussing about deletion (again)? --Abderitestatos (talk) 22:34, 14 June 2018 (UTC)
@Abderitestatos: As I said, you could ask the user first. - Jmabel ! talk 23:17, 14 June 2018 (UTC)
But in this case it was not really the uploader who provided the license, he just adopted the license information given by a collection’s website, whose operators seem to put their items by default under a cc-license, even when the creator is unknown, or when copyrights obviously have expired. --Abderitestatos (talk) 13:04, 15 June 2018 (UTC)
The uploader is the one who is responsible to the Commons community. When you upload here, you are implicitly saying you believe the image is within Commons scope in all respects, including that it is either public domain or sufficiently freely licensed.
@Abderitestatos: If you don't think the uploader will have any particular insight, an believe they were taken in by copyfraud, as I said, it is your prerogative to head directly into the deletion process without first consulting the uploader. Of course, you could be more specific here so that there is some chance to discuss the substance of the matter. But as long as all you are saying is a generic statement that there are some files on Commons that you think have copyright problems, all anyone here can do is to give you generic advice. - Jmabel ! talk 16:11, 15 June 2018 (UTC)

June 11

Wikimedia Commons app {Explore/Search Feature}

Hi everyone, I am a Ujjwal, contributor from Commons Android App team. As a part of my internship project, I was working on search images feature in Commons app in Phase 1 of my Internship(GSoC 2018). I am attaching a prodDebug APK for the same. Feel free to create an issue regarding any bugs or feature request that you have at our GitHub repository. APK Link: https://drive.google.com/file/d/1THe_I3PRixktLQcOSMMvzymLhHN6_ERq/view?usp=sharing --Ujjwalagrawal17 (talk) 10:58, 15 June 2018 (UTC)

In other words, we can now browse Commons media from the app :-) Just install the APK linked above on your Android phone and enjoy! (if you have Commons installed already, you must uninstall it first) Syced (talk) 11:05, 15 June 2018 (UTC)

SVG validation

I noticed some changes in the W3 SVG validator; a lot of files that were considerd valid in the past generate now the message "Sorry! This document cannot be checked." For example this:

--Carnby (talk) 16:27, 15 June 2018 (UTC)

Seems to be a bug in the W3C validator per this error message:

Error External Checker not available Checking the Document Type of this document requires the help of an external tool which was either not enabled in this validator, or is currently unavailable. Check in the validator's system configuration that HTML5 Validator is enabled and functional.

The error encountered was: 403 Forbidden

--Sebari – aka Srittau (talk) 16:44, 15 June 2018 (UTC)
@Carnby: Adding DOCTYPE declaration solves the problem:<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">. However it solves it partially because now the validator reports errors related to RDF – AFAIR earlier version(s) of the validator reported these issues as warnings. Anyway, I've uploaded manually fixed, valid version. --jdx Re: 07:40, 16 June 2018 (UTC)

June 16

請求快速刪除

✓ Deleted Yann (talk) 04:31, 16 June 2018 (UTC)

Anti-Arpitan vandalism in Wikidata

Our Category:Arpitan/Francoprovençal is transcluding d:Q15087 to state that this minority Romance language is an «Instance of Chino mandarin» — which, I fear, is a form of xenophobic insult from some bigot’s addled perspective. Now, some questions:

  1. How can it be reverted or corrected?
  2. How can the culprit be identified?
  3. How can other such cases be detected?
  4. How can further such cases be prevented?

-- Tuválkin ✉ ✇ 23:20, 13 June 2018 (UTC)

  • It looks like some languages, e.g. French, make a distinction between language as a means of communication (langage) and language as a dialect (langue, "tongue" as in mother tongue). --HyperGaruda (talk) 02:33, 14 June 2018 (UTC)
  • Wikidata uses ORES for vandalism detection. Like many other Wikidata editors, I myself have (in my volunteer capacity) many 10s of thousands of Wikidata items on my watchlist and check those daily (I think I catch and correct one instance of vandalism via my watchlist every two days on average), and I keep a watchful eye wherever I see Wikidata items integrated in our other projects and in external websites. Thanks for catching, flagging and correcting this! SandraF (WMF) (talk) 07:25, 14 June 2018 (UTC)
  • @SandraF (WMF): So, this is not a bug of Wikidata, but a feature? Therefore any transclusion from Wikidata into another project (in the form of infoboxes and stuff) is a Trojan Horse for all kinds of abuse, one that needs 3 experienced users to track down and revert. Truely enlightening. -- Tuválkin ✉ ✇ 13:03, 14 June 2018 (UTC)
  • The Trojan Horse analogy is may be slightly over-the-top, but I think it's undeniably true that false claims that would otherwise be immediately reverted as test edits or vandalism, because they stem from a Wikidata item, can last for years. Presumably, this is because first finding the source of the error and then fixing it is such an obscure and difficult process. I still can't figure out why I was recently unable to update an image on Wikidata before deleting the old one as a duplicate. I spent about 10 minutes trying, noting that I was not blocked, the page didn't seem protected, and I could edit some things just not the image, then gave up and told a bot to do it. I would have spent less time and just washed my hands of the situation had not a huwiki article been somehow pulling the image from Wikidata, so I could not fix the huwiki article without finding and fixing the wikidata item. When things go right, it seems almost magical... when things go wrong, it feels byzantine and purposely obscurantist. Storkk (talk) 10:31, 16 June 2018 (UTC)

June 14

Category:Historical agricultural equipment

@Witia: I notice this category and a complete matching set was created recently. Why is it useful? Surely everything becomes historical? Do we have a date like 2015 and events before that or images taken before that date are regarded as historical? Eddaido (talk) 01:42, 16 June 2018 (UTC)

And the same with Category:Historical images of ploughs. What happens when we move into the 2020s. Won't 2018 images need to be moved to historical? Eddaido (talk) 02:12, 16 June 2018 (UTC)

  • Yes. That’s why I avoid such terms when creating new categories. Usually, cats named Category:History of Soandso however include things like Category:2018 in Soandso down to Category:1234 in Soandso, etc. A simpler way to put it is Category:Soandso by date, but simetimes there’s media to justify both categories (with Category:History of Soandso as the parent of Category:Soandso by date). -- Tuválkin ✉ ✇ 07:01, 16 June 2018 (UTC)

Kitagawa Utamaro's "Mother and Child" offering

I am not sure of the Japanese title of the image; this artist did multiple artworks on this subject. The print I have (and have scanned) is of a woman holding a red baby and a pipe and exhaling smoke. The print I had would not fit on my scanner bed and is thus done in four parts which will need to be stitched together and used to eliminate process artifacts.

Each image is a little less than 5100×7000 pixels and has significant overlap, so the final image would be a bit larger than that. To compare to a small version hosted online (actually the only copy I could find with a quick shallow search), see http://player.slideplayer.com/14/4427142/data/images/img54.png (340×504 but that site allows download of a .ppt with embedded 754×1166 version). Obviously a museum-quality scan would be best, but this would allow a filename over which such a file, if later found, could be written.

Is there any interest in this? Arlo James Barnes 20:47, 16 June 2018 (UTC)

I realise archives are not supposed to be edited, but I thought I would leave this breadcrumb here: Commons:Graphic Lab/Photography workshop#Stitching_and_scan_artifact_removal_of_Kitagawa_Utamaro's_"Mother_and_Child"_offering

June 17

Anthroponym cats with unclear onomastics

There are >200 thousand subcats under Category:Uses of Wikidata Infobox with no family name. Anyone taking care of this? -- Tuválkin ✉ ✇ 19:18, 3 June 2018 (UTC)

  • Unimpressive, sorry. Short-sighted regex juggling of incomplete data might be a nice addition to one’s coder portfolio, but it’s not the way to get actual content added. (Aint it “funny” how the supressing of wikitext because it enthrones geeks at the supposed expense of regular users ends up lionizing whoever can fiddle with data through a backport, bypassing a gamified, dumbed-down UI? The Wikidata way is spearheading that wedge between low-caste casual contributers and code gods, salting the middle grown whence the whole ecosystem of Wikimedia project grew! But I digress:) The way to have data added to Wikidata is, ironically and as usual, syphon it off from Commons whenever there’s any data to do so, usually mangling it on the way and locking the door for its further improvement (as it has been done with geolocation data for categories). -- Tuválkin ✉ ✇ 10:07, 4 June 2018 (UTC)
  • @Tuvalkin: I'm not trying to put together a coder portfolio or to demonstrate my (very limited) knowledge of regex. I'm trying to use the structured data format that Wikidata provides, and my (also limited!) knowledge of Python and pywikibot, to consolidate the information that has already been contributed to the Wikimedia projects so that editors don't have to repeat an edit that's already been made, in the hope that they can spend their time on contributing new information instead. Category:Uses of Wikidata Infobox with no family name tracks cases where the family name isn't set on Wikidata, which means that {{Wikidata Infobox}} can't provide an automatic DEFAULTSORT or add the category to the family name categories. However, that information is probably already available here through manually-defined DEFAULTSORTs and categories, but not in a format that can be used by the infobox here (or other infoboxes on other projects). Hence my why I'm trying to think of ways to use code to add that information to (and then extract it from) the structured database, so that we can focus on manually sorting out the more difficult cases. Thanks. Mike Peel (talk) 00:46, 5 June 2018 (UTC)
  • Or we could collaborate on ways to add (or encourage others to add) information once, and to then use that information more widely? You can clearly think through the ways that the data can be organised, could we either work together to do that, or avoid disparaging each others' work? Thanks. Mike Peel (talk) 01:24, 5 June 2018 (UTC)
  • Ah, collaborate: That’s what I (try to) do everyday here. Usually not by discussing would-bes and could-bes (as often done here) but by creating stuff others can build on (example) and/or adding my work to efforts initiated by others (example: any of so many things created by Fæ). In the case at hand, it is needed some general knowledge about Onomastics worldwide and/or willingness to research it (got any? — add below). As for disparaging Wikidata and Structured Data in Commons, well, unless their underlying phylosophy changes radically, you can count on me for that also. -- Tuválkin ✉ ✇ 23:24, 8 June 2018 (UTC)
The bot was approved on Wikidata and is now running through the basic cases (label minus given name == family name) to add the family name property. Category:Uses of Wikidata Infobox with no family name is down from 232k entries by circa 2k entries, with many more to come. There was a bug with "Saint" that has now been resolved. Please let me know if the bot causes any problems, or if it is missing something, and I'll look into it. Thanks. Mike Peel (talk) 00:30, 16 June 2018 (UTC)
  • Coming August, if nobody does it sooner, I’ll be working on a new categorizing template that accepts as parameters each of a name’s constituent words and a flag to determine how they should be shuffled around for presentation, sorting, addressing, shortening / abbreviation, and categorization. Off the top of my hand, here’s some of those possible different ways of treating human idividual names:
    • Hungarian
    • East Asian
    • Russian
    • Portuguese
    • Spanish
    • Icelandic
    • French
(and probably more). -- Tuválkin ✉ ✇ 10:07, 4 June 2018 (UTC)
Having played around with two entries, I ran into problems with Dutch names containing a so-called tussenvoegsel like van (von in German and de/d’ in French). While it is part of a family name, it is disregarded for alphabetic sorting purposes: e.g. Category:Gijs van Aardenne is sorted manually as "Aardenne, Gijs van", but if it has to follow Wikidata, it will be auto-sorted as "Van Aardenne, Gijs" (to make things even more complicated, Belgian Dutch does sort it as "Van Aardenne, Gijs"). Please take this into account when working on the new template. --HyperGaruda (talk) 08:17, 9 June 2018 (UTC)
(!) "Two people who speak the same language and have the same name will sort next to each other" trumps pretty much all of this classic list IMO. Storkk (talk) 09:37, 9 June 2018 (UTC)
  • How will the bot handle names like "William of Ockham". Sometimes it it where they were born, sometimes where they are currently living. I do not know what these types of names are called, does anyone know the technical term? Is it a toponym? I was thinking that their should be a unique field for that part of the name at Wikidata. We handle Scandinavian patronymic names with their own field. Scandinavia also used them in place of surnames, usually the farm you live on. RAN (talk) 22:47, 18 June 2018 (UTC)

Imminent deletion of many high-quality educational images

Every so often, I batch upload images from the University of Texas at Austin's 'Insects Unlocked' project. These are high quality, have great educational value, and are often our only image of particular species.

Many - but not all - of the last batch, for example the one above, have been tagged as due for deletion on 24 June. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 18 June 2018 (UTC)

You can mass convert these to a DR. As the example shows it is marked as "public domain" with the photographer's name, these should be kept as the PDM is incidental to the documented release from the original photographer. --Fæ (talk) 11:35, 18 June 2018 (UTC)
Andy Mabbett have you tried contacting the Flickr user to ask them to use the correct tag (CC0) to release their photos into the public domain. -- Colin (talk) 12:13, 18 June 2018 (UTC)
"Correct"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:16, 18 June 2018 (UTC)
CC0 would only be correct if the pictures were actually released using CC0. CC0 isn't the same as a simple public domain dedication. --bjh21 (talk) 12:26, 18 June 2018 (UTC)
@Pigsonthewing: CC0 by itself is acceptable here, PDM by itself is not. See also COM:PDM.   — Jeff G. ツ please ping or talk to me 13:46, 18 June 2018 (UTC)
The Flickrstream is owned by "Insects Unlocked" who are a group. Their Website uses Flickr as their gallery: it's how they publish their work. Ideally, they would then use CC0 as their public domain dedication. CC0 is a simple public domain dedication, so I'm not sure what bjh21 is implying. But it is a statement only the original copyright holder (or authorised representative) can make. The photographers in that group all have to agree to use CC0 as their method of releasing the images into PD. It is useful for them to do that, rather publish them with the wrong Flickr tag, which is meant for other people's work that is already in the public domain. -- Colin (talk) 14:40, 18 June 2018 (UTC)
I was referring in particular to section 3 of the CC0 legal code, and more generally to the way that CC0 is more verbose than simply "I hereby waive my copyright in [work]". But even if it were that simple, the important thing as you say is that CC0 is one specific way of achieving that effect, and we shouldn't use {{Cc-zero}} on works that entered the public domain by other routes, and we don't know what mechanism Insects Unlocked uses. --bjh21 (talk) 15:10, 18 June 2018 (UTC)
I don't think it does any harm for the copyright owner to make their PD declaration in as many ways as they like. -- Colin (talk) 15:59, 18 June 2018 (UTC)
The images are clearly labeled "public domain by" (authors name) right on the image. I think that is exactly equivalent to our {{PD-Author}}, especially since I do not think there are any doubt that the people uploading the images to flicker are the authors or copyright holders. I understand that Commons community prefer CC0 over PDM and I agree with this preference, but if flicker authors mark their own images as "public domain" using PDM we should honor that and upload such images with {{PD-Author}} template. PDM just means "public domain" and it is up to us to map it to one of our PD copyright template. --Jarekt (talk) 18:41, 18 June 2018 (UTC)
  •  Comment It is a university group and some of the people who are responsible for uploading to the flickr account likely change regularly. there is a big chance that is is mistake or/and lack of knowledge about copyright issue from the temporary uploader, it's not the first time that this happen, and it will likely happen again. First, I do not think there is any doubt that the images are compatible for us. Secondly the PD mark issue is a Commons decision mainly for to avoid the Flickr users abuses, we can decide to adapt. The suggestion made by Jarekt is the good one, I think that all the the images concerned (all the the images from this account that are not CCO and with the clear watermark "PD image by...") should be tagged by us with {{PD-Author}} and {{License review}}. And apply the same solution if it happens again in the future. I think this should be clarified a good once, because I repeat it has already happened (sorry I don't have the link) and it will certainly re-run, Jarekt is right "PD-Author" is good here. Christian Ferrer (talk) 19:22, 18 June 2018 (UTC)
  • {{PD-Author}} should only be used if the copyright holder has agreed to the "fallback licence" on that template, i.e., [author] grants anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law. --ghouston (talk) 07:35, 19 June 2018 (UTC)

Cemetery maps from the VA

Are these maps from the w:Veterans Administration that show the layout of national cemeteries "PD-Gov"? What do you think? RAN (talk) 20:59, 18 June 2018 (UTC)

Do have an example? If they were produced by an United States Department of Veterans Affairs employee in the course of duty, they are PD. If they were bought from external providers then they're not free. De728631 (talk) 21:05, 18 June 2018 (UTC)
Oops! Here it is: https://gravelocator.cem.va.gov/NGLMap?ID=3030960 and https://gravelocator.cem.va.gov/NGLMap?ID=3030500
Hrm, since there aren't any credits I'd like to think that these are VA works and as such are public domain. De728631 (talk) 23:04, 18 June 2018 (UTC)
I concur ... Too bad the files are so small. Clearly they shrunk them down to fit on the page. I just sent them an email asking if they have them in a larger size. RAN (talk) 23:33, 18 June 2018 (UTC)

Upload of a public domain image from Italian wiki

[42] I copied this into my laptop and uploaded it but its come out as if it's my work, rather than someone else's public domain effort. What should I do to give it the proper copyright licence? Thanks. Keith-264 (talk) 21:24, 18 June 2018 (UTC)

I have fixed the licence tag {{PD-author|{{user at project|Edozio|Wikipedia|it}}}} and also updated the description. This map was made by Edizio at the Italian Wikipedia while Cocchia and De Palma's book is only his source. When you transfer a file from Wikipedia, please also add a section with a table that contains the original upload log, i.e. the "file history" data. This is usually required for retaining free licenses like Creative Commones or GFDL. But also for public domain data like this, it is good practice so as to document the file history. Unfortunately this is some extra work that has to be done manually because we cannot copy the source code of the upload log.
That said, why did you upload a PNG thumbnail instead of copying the original SVG file? De728631 (talk) 22:50, 18 June 2018 (UTC)
I did it by guessing and trial and error; not being an Italian speaker didn't help, although after I put this question I realised that Edzio must be the author. Thanks for the support. Regards Keith-264 (talk) 07:26, 19 June 2018 (UTC)

Tech News: 2018-25

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

Changes later this week

  • There is no new MediaWiki version this week.

Meetings

  • Recurrent item 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 19 June at 18:30 (UTC). See how to join.
  • Recurrent item Advanced item You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 20 June at 15:00 (UTC). See how to join.

Future changes

  • Some old web browsers will not be able to read the Wikimedia wikis. This is because they use an insecure way to connect to them. This means that we get less security for everyone else too. This affects about 0.08% of all traffic to the Wikimedia wikis. This affects for example those who read Wikipedia on a PlayStation 3. [44][45]
  • The new filters for edit review tools and interface for watchlists will leave beta. Because there is no new MediaWiki version this week it will happen on 25 June for most wikis. For the rest it will happen in early July. [46][47]
  • Advanced item All wikis that have not already done so will switch to use the Remex parsing library on 5 July. This is to replace Tidy. You can help fix remaining errors. [48]

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

21:47, 18 June 2018 (UTC)

June 19

Notification of DMCA takedown demand - Geology.com

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the WMF office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me. The takedown can be read here.

Affected file(s):

To discuss this DMCA takedown, please go to COM:DMCA#Geology.com Thank you! Jalexander-WMF (talk) 04:08, 19 June 2018 (UTC)

License reviewer script takeover

This section was cross posted from Commons talk:License review

For those of you that use Rillke's license review script, due to Rillke being effectively retired I have taken over the maintenance of that script. I have ported it over to User:Majora/LicenseReview.js and have added functionality for reviewing images in Category:Finna review needed and Category:Unreviewed photos of GODL-India. Eventually I will also clean up the script to remove obsolete Panoramio and add other functionality. Any other suggestions are welcome as I go through the script and see what's there is to work with. In addition, those that have the Rillke import in their personal .js file may want to update to have this added functionality. --Majora (talk) 04:23, 19 June 2018 (UTC)

Majora: Thanks a lot! Yann (talk) 09:13, 19 June 2018 (UTC)

Digital Watermarking Image

I've a problem in maintaining with Category:Cultural heritage monuments in South Korea. This category mainly contain images to upload as Wiki Loves Monuments through 2 years in South Korea, however images were negrected to categorize into more detail. So, I'm doing it and done almost. In this working, I found images with digital watermarking to include the website advertising, maybe commercial or not. One person, user:Anne1482, uploaded them all as [49], and he/she has no contribution on Commons nor other projects except upload for WLM 2016. So I cannot expect that he/she shall change images to non-watermarking although put the Template:Watermark on his contributions such as file:부여 무량사 극락전-20101207.jpg. Here are my questions; Can we delete all of his/her contribution? If not, Can I crop the images and replace them? I need your advice. -- Jjw (talk) 11:39, 19 June 2018 (UTC)

COM:Watermark is a proposal, but may be relevant. — regards, Revi 16:50, 19 June 2018 (UTC)

Is there any way of telling how often a Commons file has been downloaded?

It's easy enough to find out how often a Commons page has been viewed (using Pageviews Analysis in the page history). But is there any way of telling how many times or by how many people a Commons media file has been downloaded?

Downloads can be done in a number of ways of course (e.g. "Save image as ..." here or on other projects' pages, or clicking the Download icon that Commons provides). I guess there is absolutely no way of finding out the total number of times a file has been downloaded, using all possible methods. But is it at least possible to tell how many people have used the Download icon to download a file? --Andreas JN466 13:31, 19 June 2018 (UTC)

I don't know of any public methods, but afaik WMF analytics can give an estimate --Zhuyifei1999 (talk) 14:21, 19 June 2018 (UTC)

PD-ineligible abusive posture

Recently I passed trough two deletions requests:

Both by the same issue, and both is pushing the bar a little bit far from I can see..

If we enter at Commons:Threshold of originality that Amada44 pointed (strangely by an external link), most of complex logos in USA section have one "court decision" pdf related to the logo, if we had this documents we could accept it, same as OTRS files, we can't accept files that do not have a document saying that the author license the files, they didn't show it... and this works for USA cases only. You are acting as black and white, however this is a grey subject: Intellectual property protection of typefaces

And at the same page, in the UK section we use this w:File:EDGE magazine (logo).svg as an example of what to not upload here. How now you are accepting similar files to what we said that shouldn't be here?


For me you are abusing the PD-ineligible, and this could lead to further consequences.

-- Rodrigo Tetsuo Argenton m 22:26, 19 June 2018 (UTC)

Of course most of the complex logos in the US section of a page showing examples of known PD logos have a link to the Copyright Office pdf declaring it PD. That's because of it's a page of examples of works that we know are PD. You claim that typeface copyright is grey, yet you point to a Wikipedia page that specifically says it is black letter law that typefaces aren't PD in the US.
COM:L says that Commons accepts files that are PD in the US and their source nation. These are PD in the US and their source nation is the US. I see no reason to throw out files that are perfectly fine under Commons rules and the US law that the WMF has to worry about.--Prosfilaes (talk) 06:11, 20 June 2018 (UTC)

June 20

To make checkusers work for Commons

First, look at the graph. There were no appointments during the last two years, absolutely no. The only appointment during the last three years was INeverCry – enough said. Then let’s analyze who are the current Commons checkusers:

  1. Elcobbola – a little more than an en.Wikipedian in residence just see below.
  2. Trijnstel – a Wikimedia steward whose masterpiece of thinking is “trust my judgement, and those of my colleagues”.
  3. Krd – masterful and polite run-around replies.
  4. Magog_the_Ogre – avoids contentious cases.
  5. Jameslwoodward – the least active of all five.

Now, which problem is urgent? This one: technical data on the Iranian singer-spamming socks will soon expire, and then data on Chyah/Sonia_Sevilla/Rafic.Mufid will expire too. A future review of the case will become next to impossible. To learn how may it look, compare against en.Wikipedians – their arbitrator Alex_Shih is now trying to mitigate mistakes of their admins who convinced themselves in a false theory using their groupthink, and eventually lost all objective data – do we want a similar embarrassment for Wikimedia Commons? Moreover, here is no Arbitration Committee to make fixes after inept admins routinely.

One line on action is to promote one of Commons admins to checkusers. Possible candidates could be Yann (who once was a checkuser) or Guanaco (whose performance in the Solomon203 case should be praised, alongside other abilities). Another possibility—but only for specific cases such as this one of Chyah/Sonia_Sevilla/Rafic.Mufid—is to find a steward willing to have a positive involvement and to authorize him/her to do certain checkuser job on Commons in addition to the official Commons checkusers. Other proposals? Incnis Mrsi (talk) 08:13, 19 June 2018 (UTC)

It is sad that you felt the need to raise this thread with a list of personal criticisms, making the issue look toxic rather than an opportunity to discuss improvement. Someone who has checkuser access that uses it occasionally, or prefers to take non-contentious cases is not a failure. All that should concern others is that checkuser is used correctly and appropriately.
If you are looking for the community to engage with this improvement, perhaps you could collapse and rethink the opening paragraph, or even start all over again, and focus on how Wikimedia Commons can encourage more of the active Commons community to consider a stint working as check users. A lesson from past cases of volunteer-burnout that seem directly related to spending lots of time sock-hunting, is that it is healthy to have short periods of using the tool balanced with plenty of positive content related projects. Volunteers are far more likely to be thanked for their positive content contributions compared to the task of checkuser where one is going to have complaints and inevitably attract the attention of trolls. --Fæ (talk) 09:10, 19 June 2018 (UTC)
+1.Incnis Mrsi: Staring this with derogatory comments won't lead you anywhere... Yann (talk) 09:15, 19 June 2018 (UTC)
@Fæ: indeed, I deem the check-user job very important and underestimated by the Foundation. Making less job than other people isn’t a failure (and I never blamed any admin for simply doing little job; this was quite another condition), but Wikipedian groupthink is. Volunteer burnout and a heap of complaints? Any volunteer may resign the tool and prompt the community to solve the long-standing problem of volunteer burnout in certain domains. Incnis Mrsi (talk) 09:52, 19 June 2018 (UTC)
  1. I have not edited en.wiki substantively in approximately 8 years. As of this writing, I am the 15th most active Commons admin--number 15/255, or in the top ~94%--and have more than 4X as many edits on the Commons as en.wiki. I routinely refuse to import en.wiki issues/sanctions when there is no Commons disruption. Incnis Mrsi's linked "support" is related to a Commons issue in which Incnis Mrsi falsely labeled a Common's user as a sock with no evidence and without consulting a CU. I deleted the page with the comment "Untrue - don't make claims when you don't know what you're talking about," which no doubt bruised Incnis Mrsi's ego. Incnis Mrsi has been warned on other projects about inappropriate tagging related to CU issues, and regularly assumes bad faith when his lack of clue is pointed out to him (e.g., this was being "ridiculed" [50]). As with me, all of the attacks above appear to be related to a grudge, not a genuine concern about the state of CUs. Incnis Mrsi's comment is disingenuous piffle;
  2. There is no shortage, burnout, or CU inactivity (save Jim, temporarily, per his explicit vacation notice); most CU activity is "behind the scenes" and visible only to CUs; Incnis Mrsi, by definition, does not have a clue what he is talking about (one notices a pattern); and
  3. This is effectively forum shopping related to Commons:Requests for checkuser/Case/Chyah (the aforementioned grudge). Indeed, the comment that precipitated the post here was Krd's refusal to comment further after much pestering from Incnis Mrsi.
    Contemporaneously to the Chyah RfCU, Incnis Mrsi posted a global unblock request on Meta for Solomon203. This account had apparently been blocked for socking based on incorrect assumptions by admins (I did not research the case in detail, but it is my understanding that CUs/RfCUs were not consulted). Solomon203 has absolutely nothing to do with Chyah. The Solomon203 case merely "primed" Incnis Mrsi to disbelieve actions by "functionaries" (his word - admins, CUs, etc.) and to demand details and evidence to which he is not entitled and which we are not allowed to provide.
    • Jeff G. makes the CU request for Chyah. Again, no relationship at all to Solomon203.
    • I responded to the CU request that the accounts were stale on the Commons but that, if a fa.wiki CU had found a confirmed relationship, that CU result would be valid;
    • Incnis Mrsi enters and misreads this to mean "trust admins have been competent";
    • I advise him this is not what I said, and he responds by calling me clueless and inexperienced. I do not respond or edit the CU further;
    • Trijnstel, being a Steward and having multi-project access (i.e., not limited locally, as I am), takes up the case, and finds it confirmed based on fa.wiki CU--essentially what I'd said;
    • Because she mentioned "fa.wiki", Incnis Mrsi interprets this to mean "not relying on our own judgment and data, but instead deferring to others whom are almost certainly wrong because people were once wrong in the Solomon203 case";
    • The CU then devolves with clueless (the pattern continues) and bad faith blustering from Incnis Mrsi. Incnis Mrsi attacks Trijnstel explicitly here and on sister sites, and now all of us here because of a refusal to accept that there are privacy issues related to this case that we cannot share.
    • Frankly, I find "Please, do not refer me to trials conducted in Farsi wikis. You are a Westerner and very likely will be impartial, which is not the case for Persians" [51] to be utterly racist and wonder whether that's what underlies Incnis Mrsi's rejection of their findings. Эlcobbola talk 10:27, 19 June 2018 (UTC)
The block of Solomon203 in en.Wikipedia was a check-user block, and innuendo that “CUs/RfCUs were not consulted” doesn’t look convincing. @Elcobbola: you know that TonyBallioni reprimanded me for editing a CU-block-derived user page. As for prevalence of “burnout” as a real problem, just one thought experiment. Imagine Elcobbola to apply for sysop in the wake of all revelations above. Predictions for result? Incnis Mrsi (talk) 12:08, 19 June 2018 (UTC)
Elcobbola also criticized my statements from May 26 about q:fa:Special:Contributions/Sonia Sevilla. Dammit… I said many days ago that was confused by the global rename Sonia_Sevilla ↦ Chyah not documented properly on Meta-wiki (at least, as of May, 2018). The case of Sonia has its roots in the Farsi space, and I applied some efforts to learn what happened there (alongside Alexis Jazz). Incnis Mrsi (talk) 12:42, 19 June 2018 (UTC)
Yes: messing with sock tags on en.wiki is considered disruptive. Bbb23 independently found the account in question to be technically indistinguishable from the Nipponese Dog and refused to consent to lifting the CheckUser block. The account in question is still considered a sock of this LTA on en.wiki. No comment as to the commons issues being raised here. I intentionally stay out of any type of Commons governance discussion, but thought I would clarify as I was pinged. TonyBallioni (talk) 15:25, 19 June 2018 (UTC)
… and the story happened because en.Wikipedians effectively ignored SA_13_Bro and Guanaco in early November, similarly to the situation in Requests for checkuser/Case/Chyah where “our” checkusers are seemingly content with “explanations” coming from the Persian space and not interested in serious investigation of the singer spam case. Incnis Mrsi (talk) 09:18, 20 June 2018 (UTC)
That is because in my impression most checkusers don't consider "sock hunting" to be some kind of sports for the sake of their own amusement. Instead, they consider their role to be a necessary evil for preventing disruption. Sebari – aka Srittau (talk) 10:56, 20 June 2018 (UTC)

Wikidata person vs. Wikidata infobox

I see that we are adding the "Wikidata infobox" template to categories that have no infobox, but is the long term plan to replace the ones that use the "Wikidata person" template with the "Wikidata infobox" template, so that we have consistent look? RAN (talk) 16:12, 19 June 2018 (UTC)

@Richard Arthur Norton (1958- ): There is a discussion about that at Template_talk:Wikidata_person#Migrate_uses_to_Wikidata_Infobox?. Thanks. Mike Peel (talk) 13:58, 20 June 2018 (UTC)

Watching trees grow

What are these?

Often temporary, some times simple single-pole structures, others with three or more and with crossbeams, usually wooden, vertical guides buried next to a freshly planted young tree or other tender-stalk plant, often tied to it with more or less slack, aiming to keep its growth vertical against bending or breaking by wind of other forces — what are these called? -- Tuválkin ✉ ✇ 01:19, 20 June 2018 (UTC)

I don't think they have an "official" name. Various names include tree stakes or tree supports although tree stakes seem to be the more wildly used terminology. --Majora (talk) 01:30, 20 June 2018 (UTC)

Warning! Mobile uploads are getting the wrong location!

I've notified the app maintainer, but people should know--it looks like the Commons app is geotagging images with the phone's current location, not the media's geotagged location. This has been happening at least as far back as March; see VTA light rail station at Lockheed Martin Transit Center.jpg for an example. grendel|khan 20:53, 6 June 2018 (UTC) (Edit: since last October, at least.) grendel|khan 20:55, 6 June 2018 (UTC)

Hi, I don't see how it could be otherwise. The location is added automatically from the phone location, and there is no option to change it. Regards, Yann (talk) 20:57, 6 June 2018 (UTC)
@Grendelkhan: It seems in these two cases that the uploaders did not include GPS coordinates in their photos' EXIF metadata, so the app assumed upload location was good enough. Would you rather it not assume that?   — Jeff G. ツ please ping or talk to me 21:11, 6 June 2018 (UTC)
  • I think that is a poor assumption for geotagging. That must be why we so often get 20 pictures of a city all geotagged to one hotel or cafe! - Jmabel ! talk 22:52, 6 June 2018 (UTC)
  • Can we trust the geolocation capabilities of a phone/user combo whence a photo lacking gelocation is being uploaded? I’d say no. But in that rare case that some actually usable info comes that way, tag it in some easily spottable way, like a hidden cat. -- Tuválkin ✉ ✇ 00:27, 7 June 2018 (UTC)
  • I always set the phone's camera app to put the geotag into the photo, so the errors merely put the location across the street or with similarly small errors. When there's no geotag in EXIF, an upload location is usually better than none, but yes, there ought to be a note that this is the upload location, not the photo location. Jim.henderson (talk) 02:16, 7 June 2018 (UTC)
  • @Jeff G.: I was the uploader in all of the cases I linked. There's some kind of bug where the geolocations show up in Google Photos, but sometimes not as EXIF data in the JPEG files I share to the Commons app. (I'll follow up on that issue separately.) This would be an annoyance if the geodata was sometimes lacking, but this is a disaster; I have to go back through all ninety-odd mobile uploads so far and manually check them. Rather than leaving a blank sometimes, the app is actively inserting bad data--an unknown number of images uploaded via mobile have been essentially randomly geotagged. (I've used the mobile uploader to upload vacation pictures from the other side of the world after getting home.) Furthermore, this could very well silently be leaking the locations of users' homes without their intent. This would be understandable as a bug; it is tremendously misguided at best as a feature. grendel|khan 07:41, 7 June 2018 (UTC)
@Grendelkhan: So have you confirmed that the original photos you took with your Pixel XL and Nexus 5X were correctly geotagged and that you didn't tell the app not to share the correct geotags?   — Jeff G. ツ please ping or talk to me 08:08, 7 June 2018 (UTC)
@Jeff G.: The photos that were incorrectly located were not geotagged due to some kind of problem with my phone or Photos or something. It looks like if the EXIF data is present in the photo, the app sets the upload's location correctly, and if it's absent, the app sets the upload's location to the current location of the phone. The latter behavior is the problem; it should leave the location metadata blank in that case. grendel|khan 16:30, 7 June 2018 (UTC)
A further problem with the current policy: let's say someone uploads when they get home. Without their explicit consent, we are uploading the geocoords of their home. Similarly if someone deliberately omitted geocoords to keep a location confidential, and did an immediate upload, so the geocoords are correct, but were not deliberately uploaded. I think this, as it stands, is very bad policy. - Jmabel ! talk 16:34, 7 June 2018 (UTC)
Actually I believe that is Oversight-able offense from the app. — regards, Revi 16:36, 7 June 2018 (UTC)
I'll ping @Misaochan: We should probably have the developer in here as well. grendel|khan 16:38, 7 June 2018 (UTC)
Hi all, app maintainer here. If there is no GPS coordinates in the photos' EXIF metadata, the app should use the phone's location ONLY if TWO conditions are met: (1) the user has manually enabled "automatically get current location" in the app's Settings, and (2) the user has enabled the optional Location permission in Android. If either one of those conditions is false, the app should not be retrieving the user's current location, much less geotagging images with it. It is also worth noting that the "automatically get current location" setting should be disabled by default. Ergo, a user has to explicitly go to Settings and enable it, and then grant the app Location permissions, in order for this to happen. Could you please check and see if this is not the case for you? We will do a high-priority release to fix this otherwise. Misaochan (talk) 16:48, 7 June 2018 (UTC)
That 'automatically use current location' should come with a big warning that this will reveal your current location. While I’m not an oversighter, I think OSers often receive a request for removal of such data. — regards, Revi 16:56, 7 June 2018 (UTC)
@Misaochan: It is enabled for me--that's a relief, at least, that this isn't affecting everyone. The text under the option says 'Retrieve current location to offer category suggestions if image is not geotagged'. If this option automatically geotags untagged images with the phone's current location, it gives no indication of doing so. (Maybe the option is named something like 'use_current_location' internally, and the flavor text didn't keep up with the parameter's usage?) grendel|khan 17:10, 7 June 2018 (UTC)
grendel|khan and Revi, good point! We should certainly include a mention of the geotagging as well - indeed the text hasn't been updated to reflect that. Will push it through for the next release. Misaochan (talk) 17:27, 7 June 2018 (UTC)
@Misaochan: Thank you for the quick response! Given that the option, up until now, didn't say anything about geotagging photos, I think we should run a bot to remove location metadata from all mobile uploads which have geotags unchanged from their initial uploads and which don't contain EXIF data; in no case did a user tell the app to geotag those uploads, and the data is at best useless, at worst a privacy violation. Maybe there should be an announcement made somewhere as well? grendel|khan 17:38, 7 June 2018 (UTC)
Given that this is pretty clearly a privacy incident of unknown scope, I've escalated it to the admin noticeboard: Commons:Administrators'_noticeboard#Ongoing_privacy_incident_involving_the_Commons_Mobile_App.. grendel|khan 23:25, 7 June 2018 (UTC)
  • Just letting everyone know that we have released v2.7.2 to production on the Play Store with a hotfix that modifies the "automatically get current location" setting subtext to emphasize that it will reveal the user's location. As always, the setting should be disabled by default. If anyone is experiencing further issues with this, please let us know. Thanks for the report and the testing grendel|khan! Misaochan (talk) 08:37, 12 June 2018 (UTC)
    • I'm not sure if this is related, but I recently uploaded three pictures made shortly after oneother. I uploaded them as a group (File:De leyen bilthoven - 1.jpg, File:De leyen bilthoven - 2.jpg and File:De leyen bilthoven - 3.jpg) - which btw means that the app doesn't allow you to add a description, which is also annoying. When I checked the locations - something I or probably most people would rarely do anyway - I found the first one was correct but the second picture had been given the coordinates of the first and the third one was correct again. This really seems to be a bug in the app and not in my phone. --Joostik (talk) 19:06, 14 June 2018 (UTC)
Hi Joostik, thanks for reporting this. It's definitely a bug with the existing multiple upload implementation (via "Share"), we hope to solve it in the 2.9 release along with the implementation of proper multiple uploads from within the app. :) Misaochan (talk) 07:01, 15 June 2018 (UTC)
FYI: I'm trying to run a sysop bot for redacting location information caused by this issue. whym (talk) 13:11, 15 June 2018 (UTC)
As an additional update, in our next release we intend to remove the "automatically get current location" option entirely, as we are concerned that people who enabled the "automatically get current location" setting prior to the subtext change may not realize that the subtext has changed. So please don't be alarmed if you find the option missing in v2.8 - in that version, your current location should not be retrieved at all in the upload process. Misaochan (talk) 08:48, 21 June 2018 (UTC)

File renaming dispute

Greetings, is there some kind of procedure to resolve file renaming conflicts? There is currently a disagrement on what the title of File:First Red Guards in Petrograd, fall 1917 palace square.jpg should be that is at issue. Jo-Jo Eumerus (talk) 07:11, 18 June 2018 (UTC)

  • I've declined the request again. The uploader continues to request a name that awkwardly does not have spaces between words, and adds useless junk (the Internet Archive filename) to the end. Commons is language-agnostic (and the uploader does have a point that the rename could have kept the same language), but useful and descriptive filenames are important. Given that they refuse to discuss the request on the file talk page (the appropriate venue), I'm not terribly sympathetic. Pi.1415926535 (talk) 07:22, 18 June 2018 (UTC)
  • Ah, yes, the edit war cause for blocking. So simple to apply. As opposed to actually look at the file history and see that User:Rowanwindwhistler wants to add a historical photo to Commons and the rest (except for Magog) are just pencil pushing and doing pretend work. But carry on. -- Tuválkin ✉ ✇ 14:35, 18 June 2018 (UTC)
  • So you finally looked at the file history, did you? Too bad it paints a very clear picture. You should have looked before ranting. Sebari – aka Srittau (talk) 14:53, 18 June 2018 (UTC)
  • I did look, yes. I should have looked closely before I said this user you blocked is a p.i.a. He’s not: he’s my hero right now, for he did nothing wrong. Yet pushing down on a fellow commoner by not even allowing a redirect from his originally chosen filename is somehow more important than upholding a filename that was in use for four years. -- Tuválkin ✉ ✇ 15:23, 18 June 2018 (UTC)
  • Pi.1415926535: I can agree that this user seems to be a p.i.a., but this user improves the project, and in this case s/he is right. Before the last renaming (which was not performed by Rowanwindwhistler, since s/he’s not even a filemover), we had this file under its original upload name and a redirect from the current filename (which lacks the IA code, fine by me but against what’s used for, say, Flikr — why?, and with English replacing the original, which is frankly filthy). Now we have the “sanitized” filename and no redirect was kept from the original filname, even though it was in use in 2010-2014. Why? -- Tuválkin ✉ ✇ 12:07, 18 June 2018 (UTC)
  • Why do you think lack of spaces is a bad idea for a filename? Frankly, I can only see the opposite — how spaces in its filename can be a source of problems when reusing the file (there’s a reason spaces are replaced with underscores by MediaWiki in so many situations), especially when it’s a long filename. -- Tuválkin ✉ ✇ 11:42, 18 June 2018 (UTC)
  • Because Tuvalkin we are humans, not computers. Anyone who thinks "File:GuardiasRojosJuntoAlPalacioDeInvierno--throughrussianre00willuoft.jpg" is better than "File:First Red Guards in Petrograd, fall 1917 palace square.jpg" should be made to use Wikipedia with a screen reader for a week. "Capital G, a, r, d, i, a, s, capital R, o, j, o, s, capital J....." CamelCase and name_underscores are developer perversions, a consequence of working around poorly written software, and indicate someone has developed bad habits. -- Colin (talk) 12:09, 18 June 2018 (UTC)
@Colin: I agree with you, but for compatibility can screen reader developers provide an un camelcase option to read that as "Guardias Rojos Junto..." and an unescape option to read underscores, %20, and nonbreaking spaces as normal spaces?   — Jeff G. ツ please ping or talk to me 13:53, 18 June 2018 (UTC)
Don'tKnowButSuspectNot.IfYouReallyWantToKnow,There'sSomeoneOnWikipediaIKnowWhoUsesOne.ButItIsn'tJustThat,ItIsReadabilityByAnyone,AndTheAbilityForSoftwareToReliablyDetectWordBoundaries,OrEvenToTranslateText.ISeeTooManyTimesPeopleProposeBadPracticeBecauseTheyHaveABadSolutionToAProblem.WhyOnEarthShouldOurFileNamesBeRestrictedByTheHttpProtocol?ItMakesNoMoreSenseThanForcingUsToUse8.3FileNames.MightAsWellUseAUuidIfYouAren'tGoingToBotherToMakeTheTextReadable.IfYouHaveAHighLevelOfEnglishReadingSkills,AndAreFamiliarWithCamelCase,YouCanProbablyReadThisOk.ButIf,LikeManyOnCommons,YouStruggleWithEnglish,OrYouWereHopingToUseGoogleTranslateToReadIt,ForgetIt. -- Colin (talk) 14:20, 18 June 2018 (UTC)
  • @Colin: Filenames are not normal text. Long filenames, with or without spaces are a bad idea — and while computers can process them just fine, we human need short, clear filenames. -- Tuválkin ✉ ✇ 14:40, 18 June 2018 (UTC)
  • @Colin: (Edit conflict) I prefer filenames without spaces, almost every time. Curiously I have no suggestion about how to torture people who feel differently. As for the case at hand, I am sure you meant that camel case is inhuman, not that Spanish is less human than English, but you might want to clarify. -- Tuválkin ✉ ✇ 14:35, 18 June 2018 (UTC)
  • Fortunately the vast majority of people in the world do not name their files like Tuvalkin. The language should have been maintained. But then I recall you once thought renaming files to Esperanto was a great idea, rather than stick/retain a unique identifier on your mass uploads like everyone else does. -- Colin (talk) 14:47, 18 June 2018 (UTC)
  • You misremember: Incidently, you may remember that I have contended here often, and against your opinion, that filenames should not be changed, as a principle. Therefore I would never suggest or perform a file renaming for the sake of translating its text, regardless of how more suitable another language would be instead of the one originally chosen by the uploader. The case you misremember was when we (or some of us) were trying to save the contents of Fotopedia and there was really no time to identify locations (Fotopedia liked to show contextless photos — so artistic!): Things like zeb-E-0pVFql9MM-original.jpg would make for poor Commons filenames (can we agree on that?), so I did use varying languages (among the few I have any command of) to create filenames for photos of not readily identifiable locations — such as Esperanto (which you seem to remember more than others − why’s that?) and Portuguese. In hindsight these two, e.g., would better be named in Ukrainian and in Maltese, but back then there was no time to look up translations, as Fotopedia was going down in short notice. -- Tuválkin ✉ ✇ 15:17, 18 June 2018 (UTC)

Warum ist die Diskussionsseite so tiefrot? To state that it's not an English, but an international project in German. For those poor monolingual people here translated: Why is the talk page so deep red? Grüße vom Sänger ♫ (talk) 14:23, 18 June 2018 (UTC)

  • Acho que tem muito vermelho por que não se manteve um redirecionamento do nome original, como indiquei em acima. ("Monolingual" ≠ "Germanophone". Also: threading?) -- Tuválkin ✉ ✇ 14:40, 18 June 2018 (UTC)
@Sänger: Some have forgotten the "discuss" portion of enwiki's BOLD, revert, discuss cycle (BRD), sadly not available in German.   — Jeff G. ツ please ping or talk to me 14:41, 18 June 2018 (UTC)
Nee, het is op de duitse WP in E-W, en in combinatie met 3M te lezen. Nicht so explizit, aber schon klar. (ne habla espagnol, je ne parlez francais, я не говарю русский язик...) And for the English: It's well established custom there as well, it's just not in one page condensed. So here is a long running naming dispute, and nobody dared to use the talk page. Grüße vom Sänger ♫ (talk) 15:04, 18 June 2018 (UTC)
✓ Done The original uploader now requested (using a sock, but let's ignore that) renaming this file to a sensible Spanish filename, using capitalization and spaces. I granted it. This should hopefully put this discussion to rest. Sebari – aka Srittau (talk) 12:10, 21 June 2018 (UTC)
I will not enter into any arguments I am not interested in, but let me state a few facts, just to get the record straight here:
  • I have not evaded my account blocking and I have not created any new account.
  • I did not have any problems nor did I create any. The problem lies with the people that disregard the renaming rules, request them without proper justification (if any beyond saying "criterium X"), the users that have priviledges that do not know how to use (renaming is about applying the rules approved by the community, not about imposing one's preferences on filenames because one has the buttons to do so) and administrators that, instead of looking into the matter and ensure the community rules are applied, back previous wrong actions and block the user that is trying to have the rules respected and applied.
  • To cap it all up, I have to put up with the nice descriptions used by some users in this page and being accused of trying to evade an unfair blocking of my account.
Excellent experience. Taking into account my hundreds of hours devoted for free to the project, I will let those involved in this wonderful job sincerely apologize unless they prefer to carry on the building up of Commons on their own. If no excuses are received by the end of the week, I will let the p.i.a.'s rename each other's files ad infinitum using the own criteria while they play at blocking each other and falsely accusing each other of god knows what while saying a relieved good bye to such delightful company. Time is counting.--Rowanwindwhistler (talk) 13:51, 21 June 2018 (UTC)

Given this team effort planned with full agreement of X and Y. Person X creates photos with her camera. Person Y edits the photos to make a composite and intends to submit the composite to Commons. Y can operate the upload wizard but it has no provision for permission from X. How should the permissions be handled? Thanks, ... PeterEasthope (talk) 21:18, 20 June 2018 (UTC)

Thanks. That helps. The most pertinent sentence is "I created the file myself, it hasn't been previously published, and I am the sole owner of its copyright." Definitely the image has not been published previously. A question still must be asked: in the jurisdiction of Commons, can copyright of one image be held by two people? A straightforward legal question. If not, then only one person can hold a copyright. In the instance above, it can't be X because X did not create the composite. Therefore, by deduction, the copyright can only belong to Y or to nobody. For Y to have copyright, copyright on the originals used in the composite must have been given by X. Therefore: if only one person can hold a copyright, must Y submit evidence to OTRS, of surrender of copyright by X. If a copyright can belong to multiple people, then OTRS might register permission from each. That imposes administration on a system already overloaded; a simpler arrangement would be preferable. Thanks, PeterEasthope (talk) 17:29, 21 June 2018 (UTC)
  • Commons is not a legal jurisdiction. The copyright laws of each country are what they are. Yes, copyright laws can be quite unwieldy. For example, in the U.S., if you paint a picture, put it in a frame, and I take a photo of that picture including the frame, each of us has different intellectual property rights over the resulting image, both deriving from copyright law. You have the copyright on your painting; I have the copyright on the photo of the frame: being a 3-dimensional object, there is inevitably some creativity in how I photograph it. So to publish the photo legally, someone would need licenses both for your rights to the painting and my rights to the photo. - Jmabel ! talk 02:58, 22 June 2018 (UTC)
  • Basically, this is the concept of "derivative works". Similarly, if I did a sketch based on a photograph of yours, someone who wished to publish would need licenses both for your rights to the photo and my rights based on the creativity of my sketching. - Jmabel ! talk 03:00, 22 June 2018 (UTC)

June 21

POTY issue - 2016 or 2017?

I attempto to create https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2017/R1/Gallery/Astronomy and got "Your edit was not saved. This is not a way to contact Picture of the Year contest volunteers." message with link to https://commons.wikimedia.org/w/index.php?action=edit&preload=Commons%3APicture_of_the_Year%2F2016%2FHelp%2FPreload&editintro=Commons%3APicture_of_the_Year%2F2016%2FHelp%2FEditintro&summary=&nosummary=&prefix=&minor=&section=new&title=Commons+talk%3APicture_of_the_Year%2F2016%2FHelp&create=Click+here+to+ask+a+question&preloadtitle=Question%20from%20Steinsplitter&withCSS=MediaWiki:HelpRequest.css Mateusz Konieczny (talk) 09:01, 21 June 2018 (UTC)

Is it really a good target? I would expect it to not lead to Commons:Picture_of_the_Year/2016/Help

Mateusz Konieczny (talk) 09:01, 21 June 2018 (UTC)

Why wtc image takes from plane is in Commons:Picture_of_the_Year/2017/R1/Gallery/Astronomy?

File:Wtc-photo.jpg - it is neither "Astronomy" nor "satellite" nor "outer space", so why it is in Commons:Picture of the Year/2017/R1/Gallery/Astronomy - on the first position? Mateusz Konieczny (talk) 09:03, 21 June 2018 (UTC)

Deletion request (no "nominate for deletion" link)

I'm trying to delete the file Bremen-trail-cc-ky.jpg as a duplicate file. When I uploaded it, an error occurred in which it apparently uploaded the file, but did not create a page for it. Thus, no description or categories appear in the file, and the "nominate for deletion" link does not appear under Tools. Attempts to create the page by clicking the Create button generates a database error. I have already re-uploaded the file under a different name. BrineStans (talk) 20:18, 27 June 2018 (UTC)

I think the name of the file you half-created was File:Bremen-park-cc-ky.jpg. I've just successfully marked it as a duplicate of File:Bremen-trail-cc-ky2.jpg. I suspect you may have run into the temporary mess referred to in the section above. --bjh21 (talk) 20:33, 27 June 2018 (UTC)
Thanks a million. I just now noticed the discussion above. BrineStans (talk) 21:01, 27 June 2018 (UTC)
This section was archived on a request by: bjh21 (talk) 22:14, 28 June 2018 (UTC)

Moving from Commons to en:Wikipedia

Plenty of files are moved from en:Wikipedia (or other Wikipedias) to Commons. What about the reverse direction?

Most or all of the contributions by ACTVR appear to be carefully and praiseworthily edited versions of copyright material. If I'm right, they should be deleted from Commons. I've put up one for deletion, saying so. (No response yet.) For at least one of them, I can immediately see a beneficial and legitimate use at en:Wikipedia. I tried uploading it, under a different filename, to en:Wikipedia (of course with a "fair use" rationale). This turns out to be impossible (the server detects that the file is a duplicate). I've described what I did and what didn't happen at en:Wikipedia, asking for suggestions. (No response yet.) Any ideas? -- Hoary (talk) 06:26, 17 June 2018 (UTC)

I uploaded File:Ruston_&_Hornsby_logo.png as en:File:Birmingham_Small_Arms_Company_logo1.png (under wrong name actually) without any problem. Ruslik (talk) 20:05, 17 June 2018 (UTC)
I uploaded File:MPP_logo.jpg as en:File:MPP_logo_foo_foo.jpg without any problem. The error I got when when I tried with just en:File:MPP_logo.jpg was that the filename was too short/nondescriptive, not that the file was a dup. DMacks (talk) 20:25, 17 June 2018 (UTC)
Well that is odd. But thank you to both of you. ¶ I'm not so well-versed in Commons. Is demotion from Commons to a Wikipedia for reasons such as this a common occurrence; and if it is, can it be (part-) automated in some way? -- Hoary (talk) 22:42, 17 June 2018 (UTC)
Incidentally, I've undeleted en:File:MPP_logo_foo_foo.jpg, provided it with a pile of justificatory small print, and moved the result to en:File:MPP-logo.jpg, a filename that of course is no longer or more descriptive than the one you, DMacks, had tried but failed to give it. I encountered no problem in doing this. I now have to attend to my paid job, but a few hours from now I'll do something similar for currently deleted en:File:Birmingham_Small_Arms_Company_logo1.png. -- Hoary (talk) 22:49, 17 June 2018 (UTC)
Stating source as "Wikimedia Commons" and nothing else is a bit problematic, because en:WP:NFCC#4 requires previous publication. Previous publication is required because publishing images that have never been "out there" is super problematic in terms of fair-use. For this reason, I don't think that stating that the image was uploaded as a copyvio on Commons is enough. Finnusertop (talk) 21:59, 22 June 2018 (UTC)

June 18

Deletion request of File:Bodyhair map according to American Journal of Physical Anthropology and other sources.jpg

I asked to delete this image because it's highly inaccurate and has no source (the "source" provided by the author is not what he claimed to be). However, it was kept because it is "in use" (see here).

I don't quite understand how that's a valid reason to block deletion requests. Anyone can make up something and put it on Wikipedia (especially on a smaller one), shouldn't be a reason to keep anything. --fireattack (talk) 01:43, 20 June 2018 (UTC)

This isn't Wikipedia. An in use file is considered a valid reason for keeping. --Majora (talk) 01:48, 20 June 2018 (UTC)
To expand on that somewhat, if you can persuade editors on the Talk pages of the articles where the map is in use that it should be removed from there, you’d be in a better position. Even so, we don’t usually delete content for inaccuracy unless it’s malicious or offensive, amounting to vandalism, hoaxing, or similar. But we do have a number of file-page templates for flagging errors and other problems, like {{Inaccurate-map-disputed}}, which ought to make re-users think twice.—Odysseus1479 (talk) 02:09, 20 June 2018 (UTC)
Isn't it exactly the point? This isn't Wikipedia, so why "in use (on Wikipedia)" a valid reason? --fireattack (talk) 04:28, 20 June 2018 (UTC)
Because that is the policy that Commons currently has. If you wish to object to that you would need to get a community consensus to change it. Right now, that is what we have to work with. Commons does not claim whether an image is "right" or "wrong". That isn't what Commons is. If it isn't vandalistic in nature, being in use is enough. --Majora (talk) 04:32, 20 June 2018 (UTC)
What stops people to post any Commons files on Wikipedia (and therefore it would be "in use") to tactically prevent it from being deleted here then? --fireattack (talk) 04:34, 20 June 2018 (UTC)
That is for the maintainers of whatever article it is put in to decide. Again, Commons does not wade into such discussions. I've had it happen where an image was removed from an article by a vandal and then deleted over here because it was no longer in use. Obviously I had that reversed but it works both ways. In order to maintain a sense of neutrality among the different projects and Commons we just have a flat rule. In use, not vandalistic, means it is within our scope. Period. --Majora (talk) 04:40, 20 June 2018 (UTC)
Introducing made-up information is vandalism. Faking sources is vandalism. If you do either of those things on any other Wikimedia project, you'll be reverted and blocked. This image is the work of a vandal. Being in scope because of being used does not exempt an image from deletion on copyright grounds or any other unambiguous reason, and that DR closure was wrong. Pi.1415926535 (talk) 07:16, 20 June 2018 (UTC)
Because Commons is an image repository for Wikimedia projects. We have enough problems with people not wanting to move files to Commons lest they get deleted. Going around deleting files that Wikipedians have chosen to use for non-copyright reasons would further hurt the relations between the various Wiki projects and Commons.--Prosfilaes (talk) 06:09, 20 June 2018 (UTC)

{{Fact disputed}} is your friend here. - Jmabel ! talk 15:35, 20 June 2018 (UTC)

Below is copied from Commons:Deletion requests/File:Bodyhair map according to American Journal of Physical Anthropology and other sources.jpg. I no longer asked to remove this image here any more. But I still want to remove this image from Wikipedia articles due to its inaccuracy. Since @Tm: claimed my removal of this image from these articles on that three Wikipedias is a way to "bypass" "in use" rule, I reverted my deletion request to show that was not my intention. --fireattack (talk) 05:47, 20 June 2018 (UTC)

I removed the copy/pasted text. Anyone can click that link. I misunderstood what you had done here and commented (now just below this comment). I also !voted delete. Please restore the deletion tag on the file page. The only reason they're "in use" is because a Commons user overrode another Wikimedian's efforts to improve other Wikimedia projects by removing the image. If the removals were done in bad faith, that would be one thing, but in this case the restoration looks to be in bad faith. — Rhododendrites talk |  22:41, 20 June 2018 (UTC)

I applied local versions of en:Template:Unreliable source? to the uses in Portuguese and Persian Wikipedias.   — Jeff G. ツ please ping or talk to me 16:49, 20 June 2018 (UTC)

The problem in this case is not the policy of COM:INUSE. The problem is when a Wikimedian realizes an image is inaccurate and removes it from pages that use it, and another user -- also not active on those projects -- decides for those projects that they must display inaccurate information in order to keep the file. Leave a message on the talk pages explaining what happened. If I create a nonsense image and include it in some pages on less active Wikimedia projects and someone else notices and removes it, it doesn't matter if that person saw the image on Commons or on some other Wikimedia project. If the image is demonstrably inaccurate or misleading, the right thing to do is to improve Wikimedia projects by removing it. At that point, it is not in use. If someone makes a habit of going to other projects to remove files that are within COM:SCOPE in order to delete them, we can cross that bridge when we get to it. If someone happens to notice something does not have the educational value it purports to have, they should be commended for fixing it on other projects -- many of which are inactive or less active, so, when combined with language barriers, may not have any editor looking for the problem or aware there is one. Commons users are Wikimedians, not some outside party that mustn't touch Wikipedias. — Rhododendrites talk |  22:29, 20 June 2018 (UTC)

I removed the image from the Persian Wikipedia. It was an editorial decision, and I am ready to discuss the matter there in Persian. 4nn1l2 (talk) 22:49, 20 June 2018 (UTC)

Here is a similar map which is in use on the German Wikipedia: File:Weltkarte-Körperbehaarung.png. 4nn1l2 (talk) 00:24, 21 June 2018 (UTC)

But that one actually has a bunch of additional sources listed. --El Grafo (talk) 07:40, 21 June 2018 (UTC)
Somewhere there was pretty clearly some trolling going on, but whether it was in the stated sources, or whether it was in the maps (I suspect, but cannot check, that the maps do not accurately reflect the sources) is probably germane. Storkk (talk) 13:44, 21 June 2018 (UTC)
I would suggest that it would not be against policy to rename the image with a more accurate title, and probably not against policy to phyiscally alter the original image to make it more accurate. Correct?- Themightyquill (talk) 20:32, 22 June 2018 (UTC)

Help categorizing photos from the Huntington theatre

Take a look at this category:

Category:Files from the Huntington Theatre Company Flickr stream not categorized by photographer‎

I've already categorized most, but there are currently 405 files left. Many need to be looked at manually. Some hints:

- Alexis Jazz ping plz 17:35, 21 June 2018 (UTC)

Hold on a sec... I think I can use Flickreviewr to do part of this. I can, once the Huntington has been removed from the bad authors list.. I'll still need help for the rest though. - Alexis Jazz ping plz 17:37, 21 June 2018 (UTC)
That part is done, 289 files to go! Help is welcome, see instructions above. - Alexis Jazz ping plz 01:50, 23 June 2018 (UTC)

Category mess

I have noticed that around the 23th of March at least user Joshbaumgartner has created lots and lots of pages with missing (red) categories, such as Category:White number 1 on green discs and Category:Colorful number 16 on colorful objects, as well as empty categories such as Category:Number 178 on white rectangles (!) and pages such as this one. Can somebody please correct this or put an end to this before we end up with thousands of pages like these, because this is becoming a mess, if you ask me. Or is this considered 'normal'? - ErikvanB (talk) 12:49, 22 June 2018 (UTC)

  • @Joshbaumgartner: Sebari – aka Srittau (talk) 12:57, 22 June 2018 (UTC)
  • It is normal, helpful, and welcome. «Putting an end to» it would be vandalism. -- Tuválkin ✉ ✇ 15:09, 22 June 2018 (UTC)
  • The red categories are due to some changes made while developing the templates used with these categories. They are not optimal, but it is taking time to fix them of course. Going forward, new categories or applications of the templates should not be left with missing categories, so the problem should not grow, it is just a matter of going through and filling in the missing steps on those that currently have red ones. Josh (talk) 17:48, 22 June 2018 (UTC)

Template i18n

Template {{RomanCat}} includes, hardcoded, the English phrase "Roman numerals". I wanted to internationalize it using {{autotranslate}}, but it did not went well. I created the following:

Can anyone succeed where I failed miserably? -- Tuválkin ✉ ✇ 20:11, 22 June 2018 (UTC)

The logo for en:Scopus, marked as non-free content at en:File:Logo for Scopus.jpg, looks to me as though it might be in the public domain under U.S. law, as it is just the typeset word "Scopus" with a registered trademark symbol. Is this (or preferably, a higher-resolution version of the same thing) eligible for inclusion in Commons? -- The Anome (talk) 23:20, 22 June 2018 (UTC)

That should be below COM:TOO in any jurisdiction since it's just plain text without any original, creative elements. It could be uploaded here with {{subst:tmlogo}}. clpo13(talk) 02:31, 23 June 2018 (UTC)

June 23

Rename template broken?

Is there something wrong with {{Rename}}? The category Category:Media requiring renaming is empty. An example of a file currently marked for renaming is File:Missing page.jpg. --ghouston (talk) 23:13, 28 June 2018 (UTC)

It's a rat's nest of templates. A recent change to {{Rename/layout}} by Perhelion may be relevant. --ghouston (talk) 01:02, 29 June 2018 (UTC)
✓ Done sorry I reverted. My intention was to fix the categorisation of COM:T with a common empty parameter, which seems not working on this template. -- User: Perhelion 09:51, 29 June 2018 (UTC)
This section was archived on a request by: -- User: Perhelion 10:08, 29 June 2018 (UTC)

Fixing Geely (Q739000)

I am not sure why the entry had started with surname tag, but it certainly not remotely related to human name. But due to the historical error, the description tag of language that i unfamiliar may contaminated with "surname / family name" or their language equivalent . Would someone help me to clean it up.

Also, the entry are now properly split into Geely Holding and Geely Auto (Q55118127) (Geely Automobile), which Geely Automobile is a subsidiary of Geely Holding, but Geely Holding is private and Geely Automobile is public ans listed. And it would be so much dig in into annual report and other primary source to actually tell which operation belong to public part of the group and which one is not, so it seem safe to assume the bigger "article" that cover the whole group was the unlisted parent holding company. Matthew hk (talk) 12:33, 21 June 2018 (UTC)

Looks like it started when THGTTI for some unknown reason added the surname property back in 2014. Soon bots followed to add automated descriptions based on what THGTTI did. Looking at THGTTI's global contributions, they have been limited to WikiData only and spanned a period of less than two weeks. I think it is safe to assume that THGTTI was a newbie and had no idea what s/he was doing. I'll see if there are languages I can help with. --HyperGaruda (talk) 17:16, 21 June 2018 (UTC)
Finally found i posted in the wrong project. Matthew hk (talk) 20:36, 23 June 2018 (UTC)

Gadget-ImageAnnotator

Hi:

Anybody know how to get ImageAnnotator to work. According to the Help about this gadget, it is supposed to be at the bottom of the file page but I do not see it when I look any image file?

Pierre cb (talk) 03:48, 23 June 2018 (UTC)

@Pierre cb: it is not located entirely at the bottom, but just underneath the image's resolution list, in the form of a button saying [Add note]. --HyperGaruda (talk) 06:05, 23 June 2018 (UTC)
Thanks. Pierre cb (talk) 12:03, 23 June 2018 (UTC)

Is this picture allowed here ?

Jim Belhushi[52] from the Toga Party-scene in Animal House.--Ezzex (talk) 14:14, 23 June 2018 (UTC)

  • Certainly copyrighted as part of the movie. Is there any reason you believe it would have fallen into the public domain, or been free-licensed by its owner? - Jmabel ! talk 15:05, 23 June 2018 (UTC)

How to see the Thanks?

Hello, when I send out the "Thanks" from the history page it says that all of them are public. But for the love of everything that is evil and horrible I am unable to find them listed anywhere. ℺ Gone Postal (〠 ✉ ✍ ⏿) 05:18, 21 June 2018 (UTC)

They go in the Thanks Log: [53]. --ghouston (talk) 05:21, 21 June 2018 (UTC)
I see who thanked and who got thanked, but I cannot find for what. ℺ Gone Postal (〠 ✉ ✍ ⏿) 09:47, 21 June 2018 (UTC)
Yeah, I don't know about that. --ghouston (talk) 12:49, 21 June 2018 (UTC)

Anybody? I'm still trying to find that. ℺ Gone Postal (〠 ✉ ✍ ⏿) 08:06, 24 June 2018 (UTC)

@Gone Postal: The log of which edits elicited thanks appears not to be publicly accessible, if it exists at all. What use would it have? I don't think a proposal to show it would gain much traction.   — Jeff G. ツ please ping or talk to me 09:44, 24 June 2018 (UTC)
Thanks to both of you for the answer. Quarry isn't the best answer, but is sufficient. Be well! ℺ Gone Postal (〠 ✉ ✍ ⏿) 17:45, 24 June 2018 (UTC)

Information regarding License

I am working on the quiz for Commons App to improve users knowledge on topicness/copyrights as well as the quality of images. I would love to hear community reviews on the answers. Thanks!
Questions for the quiz along with answers:

1) selfie picture

OK to upload? ✔ ✗

Selfies do not have much encyclopedic value. Please do not upload a picture of your self unless you are famous enough and already have a Wikipedia article about you.

2)picture of the Taj Mahal

OK to upload? ✔ ✗

Pictures of monuments and outside scenery is OK to upload in most countries. Please note that temporary art installations outside are often copyrighted and not OK to upload.

3)screenshot of The New York Times' mobile website

OK to upload? ✔ ✗

Screenshots of websites are considered derivatives works and subject to any copyright on the website itself. These can be used after permission from the author. Without such permission, any art you create based on their work is legally considered an unlicensed copy owned by the original author.

4)blurry picture of a not-remarkable human hand

OK to upload? ✔ ✗

One of the goals of Commons is to gather quality images. Therefore, blurry images shouldn't be uploaded. Always try to take nice pictures with good lighting.

5)picture of a Hmong wedding in traditional clothes

OK to upload? ✔ ✗

Pictures showing technology or culture are very welcome on Commons

Tanu dadu (talk) 13:31, 22 June 2018 (UTC)

@Tanu dadu:
1. "your self" should be "yourself". "The uploading of small numbers of images (e.g. of yourself) for use on a personal user page of Commons or another project is allowed as long as that user is or was an active participant on that project."
2. India: OK for 3D (architecture and sculptures), {{FoP-India}}. Would not be okay if the Taj Mahal was relocated to Iran though. Monuments (in the sense of statues) in (for example) the US or France that have not yet passed into the public domain are no good either.
The Taj Mahal was completed in 1643, so it would be OK wherever it would be located. It was created long before copyright started to exist. The quiz has to differentiate old works from new ones. Regards, Yann (talk) 00:30, 22 June 2018 (UTC)
@Yann: Agreed, it should differentiate. Actually parts of the Taj Mahal were restored and the garden remodelled between 1900 and 1908. Probably public domain anyway, but the point was we wouldn't allow photos of the Sydney Opera House if it was in Iran. And more importantly, several countries don't have FoP for photos of statues either. - Alexis Jazz ping plz 00:48, 22 June 2018 (UTC)
3. True, such things may be okay sometimes as fair use on enwiki. Would be okay if the text is not copyrighted and the mobile site contains no original design elements. (probably out of scope in that case but no copyvio)
4. "not-remarkable" should be "non-remarkable" or simply "unremarkable". The goal is to collect the best quality images. If the only picture of a human hand that we have is a blurry one, we'll have to take it. Somewhat blurry pictures of rare animals/people or things like that are welcome. (for example: w:Doria Ragland, poor picture, but it's all we've got)
5. Consider adding {{Personality}}. Also (this will be a common issue for things like weddings), do not upload pictures you didn't take yourself. If you gave your camera to a relative for just one photo, do not upload that photo. Even if you have their permission! They should create their own account and upload it themselves, or (if the photo is really important/valuable) go to OTRS.
You might be interested to know (probably not really..) that (last time I checked) we had no selfie that was not from a new user with no other uploads (Cool. Copyright/personality rights are a bit vague when unexperienced users upload selfies, I prefer not to use them), taken at a regular angle (oh hi), clearly is a selfie (can't be seen clearly on File:AnnaStevenson2018.jpg), using a decent phone or camera (you need a new camera) and with a background that would be at least somewhat interesting. (your ceiling is awesome) Just a "standard selfie". Try finding it in Category:Selfies. I don't think we have it. It's possible we did have it at some point but it was deleted as an "unused personal picture". - Alexis Jazz ping plz 00:01, 22 June 2018 (UTC)
@Alexis Jazz: not sure what you do or don't consider a selfie (does it have to be taken with a cell phone, or can it be a DSLR? Is it OK to use a mirror?) I've got two decent self-portraits in Category:Joe Mabel, but one is with a point-and-shoot and a reflective surface (a napkin-holder, as it happens) and the other with a DSLR and a mirror. - Jmabel ! talk 03:11, 22 June 2018 (UTC)
@Jmabel: DSLR is fine. (if you can hold it with your arm stretched out..) Some examples of what I mean:
Also see Category:Selfies with arm visibly stretched out. Few represent the "typical" selfie. (without being from a new user) I just mean what you would think of when you hear the word "selfie". You wouldn't think celebrity, you wouldn't think diagonal, you wouldn't think ceiling, you wouldn't think group selfie, you would think of seeing one arm stretched out and the person looking at the camera. File:DICKSON T J.jpg would have been all that - except it's diagonal. - Alexis Jazz ping plz 10:42, 22 June 2018 (UTC)
So no mirrors. - Jmabel ! talk 15:31, 22 June 2018 (UTC)
@Jmabel: for a typical mirror selfie I would expect a phone to be used. But we don't have this either! Category:Self-portrait photographs with mirror doesn't seem to have it. Actually it does, but she's not wearing anything. (NSFW obviously) - Alexis Jazz ping plz 02:16, 23 June 2018 (UTC)
  • "…already have a Wikipedia article about you" is a high threshold. We'd want photos of pretty much any faculty of an accredited college or university, member of a legislature, leader of pretty much any unit of a political party above the precinct level, head of an organization about which we have an article, member of a band about which we have an article (unless it's something like an 88-piece marching band!), etc. Selfies don't tend to be the best, but they are better than nothing. - Jmabel ! talk 03:17, 22 June 2018 (UTC)
  • Maybe not the commentary you are looking for, but I would like to congratulate you on your choice of "unremarkable human hand" as a tasteful but functional stand-in for the other human body part that we actually have way too many blurry/unremarkable photos of. =) - Themightyquill (talk) 20:38, 22 June 2018 (UTC)
@Themightyquill: I hadn't even made that connection. The wording does seem odd now that I think about it. @Tanu dadu: was that really referring to Commons:Commons does not need you to drop your pants and grab a camera? - Alexis Jazz ping plz 07:49, 25 June 2018 (UTC)

June 22

Help:VisualFileChange.js

I dont have Help:VisualFileChange.js in my Gadget list. Where is the problem?--Marek Preis (talk) 16:17, 24 June 2018 (UTC)

@Marek Preis: You are not autopatrolled yet, so you cannot use it as a gadget via the manual method. Please try the automatic or javascript install method at Help:VisualFileChange.js#Step 0: How to Install.   — Jeff G. ツ please ping or talk to me 16:51, 24 June 2018 (UTC)
@Jeff G.: Doesnt work either.--Marek Preis (talk) 18:11, 24 June 2018 (UTC)
@Marek Preis: Does " Just try it without installing" work for you? Do you have Javascript turned on?   — Jeff G. ツ please ping or talk to me 18:36, 24 June 2018 (UTC)
@Jeff G. and Marek Preis: This should indeed work, VisualFileChange also works for users without autopatrol. - Alexis Jazz ping plz 19:01, 24 June 2018 (UTC)
@Jeff G.: No, that doesnt work to me.--Marek Preis (talk) 21:28, 24 June 2018 (UTC)
@Marek Preis: Well it's probably an issue with your device, browser, plugins or configuration so there is nothing we can do without more information. - Alexis Jazz ping plz 21:34, 24 June 2018 (UTC)

Wikidata infobox and clear:both templates

Hi, there is a layout conflict between {{Wikidata infobox}} and some other clear:both templates causing weird layout of category pages. See e.g. Category:Thallwitz, where the layout problem seems to be caused by {{Catnav}} and all categories having {{Object location}} only after {{Wikidata infobox}} (e.g. Category:Ruissche Poort ('s-Hertogenbosch)), >5000 entries. It works for e.g. Category:Markt_7,_Culemborg, as long as there is the {{Building address}} before, but removing the address will cause the same strange behavior. I expect that there are more problematic cases. Can we fix this to have the Wikidata infobox floating right from top and only use the space left of the infobox to put all the other templates (now no more on full page width)? Currently this is handled by the bot by putting the {{Wikidata infobox}} to the bottom of the category page, but for me it would be more natural to put the infobox to the top (what I do, when I add the infobox manually). Which means to restrict the clear:both / right to much fewer cases. --Herzi Pinki (talk) 07:57, 23 June 2018 (UTC)

same for {{World Heritage Site}} --Herzi Pinki (talk) 07:58, 23 June 2018 (UTC)
See the way I changed Category:Thallwitz so it works. I've done a few like this when I've run across them. I suppose a bot could check for these & fix it in general and/or we could modify the bot that is adding {{Wikidata Infobox}}. - Jmabel ! talk 15:04, 23 June 2018 (UTC)
This is why pi bot puts the template after the last }} on the page - not sure if @Rudolphous's bot also does that. Ideally the other templates would not use clear:both, but there are quite a few templates that do. {{Building address}} is more complicated, since its HTML is deliberately distorted and affects any template that follows it, so I've been avoiding bot-adding the infobox where that is present. Thanks. Mike Peel (talk) 15:28, 23 June 2018 (UTC)

Thanks a lot, it is clear that turning the order solves the problem. But that was not the thing I intended. I put the infobox always on top. This is conforming to the doc of the infobox: Placement: At the top of the page. --Herzi Pinki (talk) 17:36, 23 June 2018 (UTC)

Problem in User:CommonsDelinker/commands

Hello,
I have just corrected this error (and I am about to correct this error on the other projects too), where "$1" has been incorrectly replaced by ":" in the new filename. I suppose that this is an automated edit due to this command by Pi.1415926535, in User:CommonsDelinker/commands.
So I suppose that something must be changed, somewhere, to avoid future errors for filenames containing "$1"... Perhaps my remark is already obsolete, because the error has occurred on 22 March 2017.
Regards --NicoScribe (talk) 17:08, 25 June 2018 (UTC)

Tech News: 2018-26

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

Problems

  • When a link text was in italics or had other formatting you could sometimes not edit it in the visual editor. This has now been fixed. [54][55]

Changes later this week

  • Content translation users who translate between any two of Arabic, English, French, Japanese and Russian will be asked to be part of a research project. This is to create better tools for translating articles. [56]
  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 June. It will be on non-Wikipedia wikis and some Wikipedias from 27 June. It will be on all wikis from 28 June (calendar).

Meetings

  • Recurrent item 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 26 June at 18:30 (UTC). See how to join.
  • Recurrent item Advanced item You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 27 June at 15:00 (UTC). See how to join.

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

23:10, 25 June 2018 (UTC)

June 26

Structured Data on Commons - IRC Office Hour, 26 June

Greetings,

There will be an IRC Office Hour for Structured Data on Commons on Tuesday, 26 June from 18:00-19:00 UTC. More information, including time and date conversion, is available on Meta. There is not a set topic, you are welcome to bring any discussion that you would like to the office hour. I will post a short reminder before the office hour is scheduled to start. Thanks, I look forward to seeing you all there. Keegan (WMF) (talk) 18:01, 19 June 2018 (UTC)

A reminder that this will be taking place about ninety (90) minutes from now, at 18:00 UTC. Thanks! Keegan (WMF) (talk) 16:27, 26 June 2018 (UTC)

Riga????

  • Same as others, but with yellow shade.
    Same as others, but with yellow shade.
  • Have the
    Have the
  • same sources :
    same sources :
  • [3]
    [3]

Which one has the right shade for both the flag of the coat of arms? Seriously, all of the false images had to be deleted to prevent confusion.
Note : none of the pictures presented have the same name of file.--Jeromi Mikhael (talk) 10:33, 26 June 2018 (UTC)

Keep in mind that some jurisdictions actually provide the coloured image of what their flags or coat of arms is suppose to look like, while others simply loosely describe the idea of their flag. In theory some place can just say "Our official flag is a dark coloured cloth with one side larger than another", therefore where would be infinite number of correct flags none of them would be "false images". I am unsure what the case is with the flag of Riga, but one should never jump to conclusions that something is wrong before investigating it. ℺ Gone Postal (〠 ✉ ✍ ⏿) 11:38, 26 June 2018 (UTC)
In Latvian the flag is describe as following: "Rīgas karogs ir taisnstūra audums ar divām vienāda platuma horizontālām joslām: augšējā josla ir gaišzilā, apakšējā josla - baltā krāsā. Karoga vidū abās pusēs attēlots Rīgas lielais ģerbonis, kura augstums ir 2/5 no karoga platuma. Karoga izmēri - 1(2m un 1,5(3." (Google translate: "The flag of Riga is a rectangular fabric with two horizontal bands of equal width: the upper band is light blue, the lower band is white in color. On the both sides of the flag is a large coat of arms of Riga, which is 2/5 of the width of the flag. The size of the flag is 1 (2m and 1.5 (3.") [57] All the flags seem to fit this description. ℺ Gone Postal (〠 ✉ ✍ ⏿) 11:45, 26 June 2018 (UTC)
Description of coat of arms: "Rīgas lielā ģerboņa vairogs: sudraba laukā atvērti sarkana mūra vārti ar diviem torņiem, zem paceltā vārtu režģa zelta lauvas galva. Augšā divas sakrustotas melnas atslēgas, virs kurām zelta krusts un zelta kronis. Vairoga turētāji: uz pelēka cokola divi zelta lauvas ar sarkanu mēli un atpakaļvērstu skatienu. Rīgas mazais ģerbonis ir lielā ģerboņa vairogs." (Google translate: "The shield of Riga's large coat of arms: in the silver field a red-stone gate with two towers, under the raised gate grating golden lion's head, is opened in the silver square. The top two crossed black keys, above which there is a golden cross and a golden crown. Holders: two golden lions with a red tongue on a gray cap and a reverse look. Riga's small coat of arms is a big coat of arms shield.") [58] I would say that lions should be more golden than just yellow, but how golden... who can tell? ℺ Gone Postal (〠 ✉ ✍ ⏿) 11:50, 26 June 2018 (UTC)
At least in traditional heraldry it does not seem to matter, as gold = yellow ;-) --El Grafo (talk) 11:58, 26 June 2018 (UTC)
@Gone Postal and El Grafo: But I think, for the COA, it should be brown.--Jeromi Mikhael (talk) 13:37, 26 June 2018 (UTC)
@Jeromi Mikhael: That is nice, but "I think" is definitely not a reason for deleting somebody's work, especially if it is in use. ℺ Gone Postal (〠 ✉ ✍ ⏿) 02:24, 27 June 2018 (UTC)
  • @Jeromi Mikhael: This discussion is moot in Commons. This matter should be addressed in Wikipedia and/or any other venue where we’d discuss guidelines for depicting flat flag images and common features of a homogenous collection thereof. Commons’ role is to gather (and curate) all possible choices. -- Tuválkin ✉ ✇ 14:05, 26 June 2018 (UTC)

June 27

Images by Ligabo

The user Ligabo has uploaded a lot of watermarked images (check here). Some of them have been manipulated to remove the watermark (like this one). However the uploader has explicitly stated here that "A claim of authorship on the image with text overlay is a clear choice of the author. Remove this information shall be prohibited by the terms of the license CC-BY-SA-3.0: "You must attribute the work in the manner specified by the author ...». If this writing is held to be incompatible with the use of Wikipedia Commons, please remove the picture. Thanks". What can we do, then? Remove the pictures by the author? Protect them in some way to avoid that some random user could manipulate them, according to Commons guidelines?--Carnby (talk) 17:22, 23 June 2018 (UTC)

According to the Creative Commons FAQ, you can't insist on the exact placement of attribution, which seems to be what this user wants to do. If Ligabo wants to seek deletion of their images from Commons on the grounds that they improperly licensed the images, they're free to do so, but files currently in use might be kept (see COM:D#Courtesy deletions). clpo13(talk) 19:53, 23 June 2018 (UTC)
As per m:Wikilegal/Removal_of_watermarks_from_Commons_images CC licenses do not generally forbid removal of watermarks. They only forbid removal of copyright notices, which many of those watermarks are not. For instance, in File:MiuraP400S1968Fro.jpg only word "Ligabo" was removed, which is not a copyright notice. Ruslik (talk) 20:04, 23 June 2018 (UTC)
So this image should be reverted?--Carnby (talk) 10:56, 24 June 2018 (UTC)
Strictly speaking copyright notice is © symbol, year of first publication, and name of copyright owner (in the US at least). Ligabo is not the real name and the date of publication is not specified. Ruslik (talk) 20:20, 24 June 2018 (UTC)
If we can't crop that from the 'DauphineAlfa_Romeo1964Rwp' image, then surely it's tantamount to a "ND" clause on the licence, and so not compatible with Commons? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 26 June 2018 (UTC)
@Pigsonthewing and Carnby: There are no problems in cropping/removing the copyright from those photos; moreover, it is encouraged. The Commons' pages contain the very same copyright information, and WMF considers that mentioning that page with a link is an accepted way to comply with CC licenses. --Ruthven (msg) 16:45, 27 June 2018 (UTC)

June 24

Postponement of the deployment of the New Filters on Watchlist

There was a recent announcement about the plans to graduate the New Filters for Edit Review out of beta for this Wiki. It stated that the deployment would happen by late June or early July. Since that announcement, we received feedback about a performance issue related to the change which is being actively worked upon. As a consequence, the deployment is postponed until further notice. Sorry for the inconvenience caused, if any.

Please let us know of any other issues or special incompatibility that you may face so that we could make sure they are solved before the feature gets deployed. Thanks, Kaartic (talk) 15:36, 27 June 2018 (UTC)

New userpage infobox

User:Tuvalkin: As of 2018.06.22, 1016 thanks given, and 377 thanks received.

Check this out: {{Userbox thanks}}. (Yes, it needs i18n.) -- Tuválkin ✉ ✇ 18:59, 27 June 2018 (UTC)

Database error

Tracked in Phabricator
Task T198350
fubar

Getting this again: 

[WzPkNgpAICIAALh5KmkAAACI] 2018-06-27 19:23:50: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

What now? -- Tuválkin ✉ ✇ 19:40, 27 June 2018 (UTC)

Watch a movie or something?
Screenshot and phabricator added. Screenshot itself is also fubar, it has a hidden revision. (I cropped it from 808 pixels to 800 pixels) - Alexis Jazz ping plz 20:01, 27 June 2018 (UTC)

It work's again for me. --Herzi Pinki (talk) 20:07, 27 June 2018 (UTC)

@Leoboudv: My phab:T198349 was closed as duplicate, but actually, it was five minutes earlier than phab:T198350! But that one is more informative I admit. But sorry Leo, I can't be trusted. (you've seen what happened to my LR request)
Any on-wiki errors in that kind of red box can never be caused by your computer. By the way, I wouldn't have been able to actually do much about this error, regardless of rights. - Alexis Jazz ping plz 20:31, 27 June 2018 (UTC)
 Comment It happened to me as well. Mediawiki upgrade was reverted, according to devs on IRC. So the issue is gone. Regards, Yann (talk) 20:26, 27 June 2018 (UTC)
@Yann: Now we just need to clean up the damage. - Alexis Jazz ping plz 20:31, 27 June 2018 (UTC)
Yes, there are a number of files without the corresponding page around 22:00 UTC. More precisely from 21:50 to 21:59, so around 150 files. Regards, Yann (talk) 20:59, 27 June 2018 (UTC)
I informed all users who uploaded some files and have this issues (hopefully I didn't miss anyone). An additional issue is that the files do not appear in the user's contributions (but they appear in the upload log) (so they do not appear in the deleted file log once deleted). Regards, Yann (talk) 21:59, 27 June 2018 (UTC)
It is more serious than I thought. I've found files without a page as early as 21:40, the problem is not for all files... Yann (talk) 22:40, 27 June 2018 (UTC)

June 28

Request to delete page

Hi, I was creating a category for Fedora Linux 28 screenshots and I did something wrong. Could you delete this page please? Thanks! Tetizeraz. Send me a ✉️ ! 23:49, 28 June 2018 (UTC)

@Tetizeraz: ✓ Done. In the future you can tag such pages with {{speedy|your reason here}}. Guanaco (talk) 23:59, 28 June 2018 (UTC)

June 29

Moving files from a local wiki to Commons: New functionality can now be tested on first wikis

Logo for the beta feature FileExporter

Hey all, over the past year WMDE’s Technical Wishes team has been working on a new functionality that allows to transfer files from a local wiki to Wikimedia Commons (if all prerequisites are met), while keeping all original data intact and documenting the move in the version history.

The project originates from the German-speaking community's technical wishlist, where people asked for a way to move files from Wikipedia to Commons including the version history and information about who moved the file.

The new functionality has been implemented via two extensions: FileImporter and FileExporter, and can now be tested on first wikis - Arabic Wikipedia, German Wikipedia, Persian Wikipedia and MediaWiki.org.

To tryout the feature, you need to activate FileExporter as a beta feature in the preferences of one of those wikis. The FileImporter on Wikimedia Commons is not a beta feature, so there is no need to activate it. The FileImporter for now uses the configuration files from CommonsHelper2 to check if or if not a file should be moved to Commons. These files can be updated and maintained by the community (please note that FileImporter can check updates to the files only by next week). If you want to learn more about the project, please see the main project page on Meta, previous feedback on the talk page there, or the central help page on Mediawiki.org (condensed version of the project page, ready to get translated) - also any feedback is very much welcome! :-) - If your local community is interested in testing the new feature in this first round as well, please discuss with your community and let us know by filing a request ticket (like this one).

We hope the new feature will serve you well! Thank you, --Birgit Müller (WMDE) (talk) 15:14, 25 June 2018 (UTC)

@Birgit Müller (WMDE): Thank you. I wanted to import a file from Persian Wikipedia, but it gave an error.
File: fa:پرونده:Seyyed Fathollah Hossein dar Marasem-e Khatm-e Khalo Hossein Kohkan (IMG 8469).JPG
License: CC BY 4.0
Error: The file cannot be imported, because it is not marked with one of the required licences.
What is wrong? 4nn1l2 (talk) 17:10, 25 June 2018 (UTC)
Hi 4nn1l2, thanks for trying it out! You got an error message because the file had no licence that was listed on mw:Extension:FileImporter/Data/fa.wikipedia by the time you tried to transfer the file. These configuration files are used by FileImporter for checking if files from the local wiki have licences that are compatible with Commons, and if the file should or should not be transferred to Commons. The list is only a starting point, based on the configuration files originally used by the Commonshelper2 tool. We added the 4.0 licence to the list today - but usually the communities can & should maintain that list :-). Changes that are made to these configuration files now will be used by FileImporter only by Thursday this week, but after that updates are immediately taken into account by FileImporter. Hope that helps! Thanks again, --Birgit Müller (WMDE) (talk) 14:41, 26 June 2018 (UTC)
The tool does not seems ready for production yet, it i not working as expected, lot (tons) of bugs. I suggest you to use https://tools.wmflabs.org/commonshelper/ until the tool is ready. --Steinsplitter (talk) 06:57, 26 June 2018 (UTC)

Hi Steinsplitter, --ghouston & El Grafo, generally, the import works (like in Steinsplitters' and El Grafo's examples) and the points that were planned to adress for the very first beta feature deployment have been covered. But this is early beta phase and there are additional things the feature definitely should have in the future - e.g. the task to map the templates from the source wiki with the templates that exist on Commons is currently in development and is planned to be deployed this week - see phab:T194505. Once this is deployed, most of the missing things pointed out in Steinsplitter's example will be covered (and all of the points mentioned by El Grafo :-). About the tag idea: Thanks for that! I will create a ticket for that, so we have it on our radar. --Birgit Müller (WMDE) (talk) 14:41, 26 June 2018 (UTC)

P.S: Phabricator Ticket for the tag idea: phab:T198324 - best, --Birgit Müller (WMDE) (talk) 13:01, 27 June 2018 (UTC)
@Steinsplitter, Ghouston, and El Grafo: Unfortunately, this week there were some problems with the general weekly update of the Mediawiki software on all wikis, so the planned software changes concerning template mapping could not be deployed. We don't know yet if the update can happen later this week, but we expect the changes to be available in one week at the latest. -- Best, Johanna Strodt (WMDE) (talk) 12:30, 28 June 2018 (UTC)
@Steinsplitter, Ghouston, and El Grafo: Good news: The software was updated this week after all, meaning that template mapping has now been added. -- Best, Johanna Strodt (WMDE) (talk) 11:00, 29 June 2018 (UTC)

@Birgit Müller (WMDE): I tried another file and I could transfer it to Commons successfully: File:Modarres Expressway, Tehran 20110912.JPG. Nice tool. Good job. However, there is one thing that I want to mention. The file history is OK. At first the file has been imported, and then the description page has been modified. But when I check my contributions, the order is reverse. It appears as though at first the description page has been modified, and then the file has been imported. That would be nice if my contributions could be shown in the logical order. Thanks again. 4nn1l2 (talk) 22:50, 26 June 2018 (UTC)

@4nn1l2: Thanks for the nice feedback :-) it's great to hear that the second import worked! - also thanks a lot for checking the order in the user contributions - I created a Phabricator ticket for that, so that we can look into it - phab:T198321. Best, --Birgit Müller (WMDE) (talk) 12:58, 27 June 2018 (UTC)

This looks promising. I note that pre-import page revisions are attributed to user on source wiki, while entry is added to Commons upload log and this entry is attributed to local user on Commons. Isn't this kind of inconsistent? Perhaps copying the upload log entry could be skipped, because the upload action was really taken on another wiki? In relation that, here I managed to trigger autocreation of local user on Commons for another person (the uploader). Is this intentional? Seems kind of odd that this user got welcome messages without himself intervening.

Minor suggestion: source page link in edit summary could be an interwiki link instead of plain URL. So that it was shorter and clickable, just like in edit summary for revisions' import done via Special:Import. --Pikne 17:43, 27 June 2018 (UTC)

CommonsDelinker

Please note that a simple renaming like this can lead to Wikidata damage: see User_talk:CommonsDelinker#Damage_on_Wikidata. --Infovarius (talk) 11:05, 28 June 2018 (UTC)

@Infovarius: Please file a bugreport. --Steinsplitter (talk) 12:11, 29 June 2018 (UTC)
Hi, This may be related to the issue reported above: COM:VP#Database error. Regards, Yann (talk) 12:16, 29 June 2018 (UTC)

Villages in Abraka

Could the editor of this page include all the villages that make up Abraka as a clan! — Preceding unsigned comment was added by 92.19.171.124 (talk) 14:56, 28 June 2018 (UTC)

There is no gallery nor category with this name. What exactly do you mean? Ankry (talk) 06:50, 29 June 2018 (UTC)
Try the talk pages of w:Abraka, w:Urhobo people, or Category:Urhobo people.   — Jeff G. ツ please ping or talk to me 08:54, 29 June 2018 (UTC)

So... we're screwed

The EU just voted to force websites to add upload filters. Lojbanist (talk) 18:39, 28 June 2018 (UTC)

Not exactly. i) The EU didn't vote definitely. The next step is 5th July. ii) Wikimedia projects are excluded from article 13. Pyb (talk) 18:44, 28 June 2018 (UTC)
Are you sure that we're excluded? We should put up a sitenotice anyway. Lojbanist (talk) 18:49, 28 June 2018 (UTC)
There's a lot of discussion taking place at en:Wikipedia:Village pump (proposals) on this topic that might be of interest. Thanks. Mike Peel (talk) 01:16, 29 June 2018 (UTC)
They were just discussing whether to put up a global banner, but decided against it because it would be "too political". --ghouston (talk) 09:11, 29 June 2018 (UTC)
Ok, but what will we do as Commons users? We are not en.wiki, and it.wiki decided to advertise the potential issues with a banner, to obscure Italian Wikipedia for few days, and –eventually– to share an open letter with other projects resuming our concerns. Please remember that we belong to a movement that promotes open knowledge, and that we should stand to defend the right to free education and culture, even if the UE decision wouldn't directly affect us (which is not true: it will affect us if it passes). --Ruthven (msg) 14:07, 29 June 2018 (UTC)
i) Contributors living in Europe should contact their MEPs. There are different websites to do that, for eg. https://saveyourinternet.eu
ii) Make noise on social media. A lot of affiliates from EU are very active on this subject, there is also @wikimediapolicy and the blog of Wikimedia.
Pyb (talk) 16:59, 29 June 2018 (UTC)
Commons isn't an EU website, so I'm not convinced it can be forced to install an upload filter. --ghouston (talk) 00:39, 30 June 2018 (UTC)

Category:Files_with_no_description_pages_(uploaded_June_27,_2018)

One side effect of phabricator:T198350 discussed at Commons:Village_pump#Database_error above are couple of hundred of broken uploads, I placed them in Category:Files_with_no_description_pages_(uploaded_June_27,_2018) for files uploaded without creation of description pages. The list was compiled with help of https://quarry.wmflabs.org/query/27897 . The uploads are from @Balabinrm, Fæ, and Mdbeckwith: and probably others. The files will need to be reuploded, or description pages will need to be added. --Jarekt (talk) 19:10, 28 June 2018 (UTC)

✓ Done --Jarekt (talk) 20:12, 28 June 2018 (UTC)
✓ Done --Jarekt (talk) 20:23, 28 June 2018 (UTC)
Yes, you can find them all in Category:Files_with_no_description_pages_(uploaded_June_28,_2018). --Jarekt (talk) 11:53, 29 June 2018 (UTC)

Closely cropped images of tombstones

Do face on, closely cropped images of tombstones meet the threshold of originality to be eligible for copyright? Are they more like scanned images of public domain documents. Would a bot tasked with capturing tombstone images give essentially the same photo. What do you think? RAN (talk) 13:46, 29 June 2018 (UTC)

  • A face on, closely cropped shot, maybe does not meet the threshold of originality. 10 people would produce 10 very similar shots, similar to 10 people scanning a document
    A face on, closely cropped shot, maybe does not meet the threshold of originality. 10 people would produce 10 very similar shots, similar to 10 people scanning a document
  • closer
    closer
  • Whereas a wide shot, shot at an angle shows creativity and originality. 10 people would choose 10 different angles and 10 different widths to the shot
    Whereas a wide shot, shot at an angle shows creativity and originality. 10 people would choose 10 different angles and 10 different widths to the shot
I think that photographing an object where the relief is significant (as it obviously is with File:BoltonSarahT Gravestone.JPG) is a creative act, since it requires attention to the lighting to produce a useful result. In the case of that pictures, there's the added matter of the leaves to consider. As Commons:Currency explains, photos of coins are subject to copyright in their own right, and the same applies to pictures of gravestones. --bjh21 (talk) 14:05, 29 June 2018 (UTC)
Been there, done that.. Even scans of 3D objects like coins are considered to be copyrighted. Also see what I just added to your gallery. - Alexis Jazz ping plz 19:43, 29 June 2018 (UTC)

June 30

Is it time to re-instate {{PD-Afghanistan}}...

Is it time to re-instate {{PD-Afghanistan}}? For a long time we treated all images first published in Afghanistan, by Afghans, as public domain.

We retired {{PD-Afghanistan}} about 2010, when someone found that Hamid Karzai had issued a proclamation about intellectual property rights in Afghanistan.

However, a Presidential proclamation falls far short of the legal requirements for Afghanistan to join the Berne-World, where Afghans can call on the US, and other nations, to enforce protection of intellectual property rights of their citizens, because Afghan authorities protect the intellectual property rights of citizens of the US, and other nations.

When we discussed this, eight years or so ago, someone quoted a lawyer the WMF had hired to give advice on the legal status of Afghan images. Paraphrasing from memory, he wrote that Afghan images remained in the public domain. He went on to say nothing prevented us from adding our own internal restrictions, but that, legally, the images remained in the public domain.

Some people argued that we should protect Afghan images early, before we were legally required to, because it was inevitable that Afghanistan would fully sign on to international intellectual property rights agreements. Yeah, well it looks like, eight years later, Afghanistan is no closer to signing on than they were in 2010.

I asked some questions today of a contributor who self identified as an Afghan citizen.

I wrote there

My understanding is that this [Karzai's proclamation] fell far short of what was required to make Afghan images protected. It was my understanding that:
  1. The Afghan legislature would have to pass a domestic intellectual property rights law, one much like the laws of other nations -- and that law would have to extend the same protections to images from other nation that the similar laws of other nations provide.
  2. The Afghan legislature would have to pass a resolution to sign on to the Berne Agreement, or an equivalent treaty.
  3. The protections have to be meaningfully enforced.
  4. The other nations in the agreement have to meet and agree that Afghanistan can be counted on to reciprocally enforce the same kind of intellectual property protection to their images that they ask the other nations give their images

Shxahxh's reply seemed to confirm what I suspected "there is no prosecution."

I had serious reservations about the reasoning that since Afghan signing on to Berne, or equivalent, was "inevitable" we should extend those protections early.

I think it is disrespectful to Afghanistan's sovereignty.

Europe, the USA, and eventually Japan, strongly subscribed to the idea that "progress is good". Belief in progress enabled a couple of centuries of technological progress, and that, in turn allowed a period of colonization.

Elites in the colonized countries also believe in progress.

But not everyone believes in progress. The Taliban never signed on to intellectual property rights agreements because they didn't believe in progress, not because they weren't smart enough to pass the right laws.

Many of the Afghan leaders, like Dostum, are conservative in the same ways as the Taliban.

Other nations have minorities who don't believe in progress. The University I attended had small farming communities surrounding it where old order Mennonites lived. Mennonites are lovely people. They are pacificists, and very generous. And old order Mennonites drive plain horse drawn buggies, don't use electricity.

Disbelief in progress is not an inherently crazy idea. When a nation's elected legislature hasn't passed the laws necessary to join Berne World, is not effectively enforcing intellectual any domestic copyright laws, I think we should respect their national will. Geo Swan (talk) 02:10, 30 June 2018 (UTC)

The Parliament of Afghanistan passed a copyright law in 2008, and the country is a party to the Bern Convention since 2 June 2018. I have already made this clear at Commons [60]. Everyone should respect the Afghan copyright law, including Wikimedians. 4nn1l2 (talk) 02:38, 30 June 2018 (UTC)

File:Enchiridion geistlicher Gesänge 28.jpg

and maybe more or even all files in Category:Enchiridion geistlicher Gesänge. The source's title is incorrect. It's not:

Enchiridion Oder eyn Handbuchlein, eynem yetzlichen Christen fast nutzlich bey sich zuhaben, zur stetter ubung unnd trachtung geystlicher gesenge, und Psalmen, Rechtschaffen unnd kunstlich vertheutscht. 1524 [books.google.com/books?id=5Ws9AAAAcAAJ]

but:

Eyn Enchiridion oder Handbüchlein. eynem ytzlichen Christen fast nutzlich bey sich zuhaben, zur stetter ubung unnd trachtung geystlicher gesenge und Psalmen, Rechtschaffen und kunstlich verteutscht. 1524 [cf. File:Enchiridion geistlicher Gesänge 01.jpg ]

w:en:Erfurt Enchiridion explains that there are two editions... -22:08, 6 June 2018 (UTC) — Preceding unsigned comment was added by 84.161.16.167 (talk) 22:08, 6 June 2018 (UTC)

Just for the record, the reason that this post isn't archived is because the last comment (the one above me) was signed by User:SignBot and not the user itself, I'm adding this comment here so it could be properly archived, but as a subject unrelated to the above we should probably inform the operator of the bot that archives here that comments signed by SignBot are ignored so they could fix it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:01, 20 July 2018 (UTC)

Just realised that this template exists, and since no-one else replied to it, I'm marking it as "resolved" to archive it more quickly. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:07, 20 July 2018 (UTC)

This section was archived on a request by: --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:07, 20 July 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Archive/2018/06&oldid=324536530"