Shortcut: COM:VP

Centralized discussion See also: Village pump/Proposals   ■ Archive Costumed character files (14 October 2024) Third-party images published by the National Weather Service (26 August 2024) Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Definition of country (19 June 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Was the closure of the deletion discussion concerning the current lede image for Philippe Pétain proper under Commons policy? (22 September 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day.

Does anyone recognise which base map File:TurdusMerulaDistribution.png is a derivative of? I can't find it in Category:Maps because there's far too many subcategories to search through and they're not organised well . . . thanks! - MPF (talk) 13:43, 4 January 2016 (UTC)[reply]

There is a Category:Blank SVG maps of the world which can be used as templates for derivative maps. --Alexrk2 (talk) 14:11, 4 January 2016 (UTC)[reply]

I know! But the particular base map I'm looking for isn't there (for starters, it's a .png format, not .svg ;-)). I need to know which exact base map it is from, (a) to add the necessary derivation link required by the derivative's cc-license, and (b) to do some clean-up work on the map. - MPF (talk) 14:32, 4 January 2016 (UTC)[reply]

The uploader @Cactus26: is still active. I think it's easiest to ask him. --Alexrk2 (talk) 14:50, 4 January 2016 (UTC)[reply]

@Alexrk2: Thanks for notifying me.

@MPF: I don't understand why you modify the map without duplicating it. Not all authorities have split the species yet. Of course the text regarding the distribution in various languages also still describes the "old" more comprehensive point of view. If you change the map directly, the text in some languages doesn't match to the map anymore. Moreover the authors of pages in these language have no opportunity to detect your modifications using their watchlist. I have reset your changes of the map. Please duplicate it before modifying. I assume, I used this base map [1].

--Cactus26 (talk) 12:08, 5 January 2016 (UTC)[reply]

File:Blank map world gmt.pdf is not the same map as that has lat. & long. lines (which yours doesn't), and is a pdf not a png - I have seen the original before, but just can't find it in the labyrinth of ill-sorted map categories. Most of the wikipedias follow IOC, and therefore use the up-to-date taxonomy, so it means your revertion of the map causes an inappropriate four-species map to be used on numerous pages about just one of the species. I will upload a new map but it is very annoying to have to do it like this; updates to maps are a accepted reason for uploading new versions of an image file; yours should also be renamed to reflect that it is now covers an amalgamation of four species. - MPF (talk) 22:55, 5 January 2016 (UTC)[reply]

I'm afraid, nevertheless this was the base map. I converted it to png and removed the lat/lon lines. You can rename the file if you want, please don't forget to adjust pages relying on that map.--Cactus26 (talk) 09:04, 6 January 2016 (UTC)[reply]

Is this a bug? I have chosen "move" to transfer a gallery page to another with alle the versions. But the execution resulted in a simple redirect. Could someone please do that properly? Gallery Sandro Botticelli Redirect to: Sandro Botticelli. Now it's a mess. History of events:

2016-01-05T11:45:30 (diff | hist) . . (0)‎ . . m Sandro Botticelli ‎ (Mattes moved page Gallery Sandro Botticelli to Sandro Botticelli) (current)

2016-01-05T11:45:30 (diff | hist) . . (+31)‎ . . N Gallery Sandro Botticelli ‎ (Mattes moved page Gallery Sandro Botticelli to Sandro Botticelli) (current)

Thanks and happy 2016! --Mattes (talk) 10:57, 5 January 2016 (UTC)[reply]

At 20:41, 3 January you moved Gallery Sandro Botticelli to Sandro Botticelli/Pa. This created a redirect at Gallery Sandro Botticelli to Sandro Botticelli/Pa. Then at 20:43 you requested speedy deletion of Sandro Botticelli, which at that time was a redirect to Gallery Sandro Botticelli but had a non-trivial history. At 07:26, 4 January 2016 Túrelio deleted it. After that at 10:10, 5 January 2016 you moved the redirect at Gallery Sandro Botticelli to Sandro Botticelli. Then at 10:12, 5 January 2016 you blanked Sandro Botticelli page and immediately requested it to be speedy deleted the second time, which was accomplished by Taivo at 10:20, 5 January 2016. After that you again moved the redirect at Gallery Sandro Botticelli to Sandro Botticelli. So, now we have the gallery at Sandro Botticelli/Pa and two redirects to it at Sandro Botticelli and Gallery Sandro Botticelli. In the process the history of Gallery Sandro Botticelli page was merged to the history of Sandro Botticelli (it is currently deleted). Is my explanation sufficient for you? Ruslik (talk) 17:56, 5 January 2016 (UTC)[reply]

Thanks! But Sandro Botticelli/Pa should be moved to Sandro Botticelli, for some reason I'm not able to do that. --Mattes (talk) 09:13, 12 January 2016 (UTC)[reply]

I frequently come across old postcards uploaded under a self licence, with the name of the collector. (As a curtisy I add the collectors name) I have added the correct licence, but wat should I do with the ols self licence? Change to: Custom license marker? And if so with wich date? Smiley.toerist (talk) 11:00, 6 January 2016 (UTC)[reply]

Old see https://commons.wikimedia.org/w/index.php?title=File:Caluire_Gare_1910.jpg&direction=prev&oldid=183903255 and as proposal, I adapted author and license, visualising as https://commons.wikimedia.org/w/index.php?title=File:Caluire_Gare_1910.jpg&oldid=183903255 , it may be undone. --Havang(nl) (talk) 11:26, 6 January 2016 (UTC)[reply]

See here If anyone is good at batch uploading, this is a great collection. —Justin (koavf)❤T☮C☺M☯ 03:43, 7 January 2016 (UTC)[reply]

Maybe @Fæ: can assist here? --Steinsplitter (talk) 13:10, 7 January 2016 (UTC)[reply]

Small test run of full size tiffs at Category:NYPL Manuscripts and Archives Division. Dcoetzee populated the parent category with 80,000 files from the NYPL a few years back, before they had the full size tifs available. There's a batch upload page documenting what happened, but as what I'm doing is so different with the API, I'm skipping past that for now.

Unfortunately the colours in the TIFFs may not display correctly on Commons, though they are fine in local preview or image editing software. Addendum freakishly, they display correctly when I look at them in Chrome, but with a pink cast when looking in Firefox on the same machine. This might be something to raise for investigation in Phabricator. From past experience the colour profile may need to be stripped from the files. I cannot remember how I sorted this out before, it may not be something I can fix in any efficient way before upload and might need to be automated or hand-flagged for a bot to strip.

This is a test run, just on collection UUID d533f0b0-c5ca-012f-d4a0-58d385a7bc34 on a fairly random basis. I have to revisit how this works as it does not cope with multiple photographs of the same object (i.e. identical NYPL b numbers for the same book illustration) and may be unreliable for other collections as the metadata is likely to shift structure. Feedback on my user talk page would be handy @Koavf: . --Fæ (talk) 23:51, 10 January 2016 (UTC)[reply]

Phab:T123210 raised for the colour problem. --Fæ (talk) 01:03, 11 January 2016 (UTC)[reply]

A note about numbering, which is probably worth recording here as I have yet to start a project page. The UUIDs are unique and are used for both Collections (of Items) and individual Items. There may be many images of an object. To give the file a unique reference, I have started using <NYPL "b" number>-<imageID>, the "b" number is unique to the object and easy to Google for results, while the imageID is unique to the scan or photograph and probably a lot harder to search for relevant matches on the internet. The item UUID could have been used, but it is so large and ugly, this would overwhelm the image pages. Unfortunately the imageID is not used on the library MODS records, so this makes the API queries a bit more convoluted as both "items" records and the "mods" records need to be pulled separately.

The JSON metadata structure is unpredictable, a bit like the Internet Archive API, so this means more effort has to be invested as different collections are tested out. For example, "date" may be available as part of the origin details in a list or a nested dictionary with multiple matches. This means the parsing gets rapidly complex if a general workflow is to be used, rather than devising a mapping for each collection. --Fæ (talk) 14:37, 11 January 2016 (UTC)[reply]

Dear Wikimedians,
the deadline for the call for proposals for Wikimania 2016 has been moved on 17th January 2016, so you have 10 days to submit you proposal(s). To submit a presentation, please refer to the Submissions page on the Wikimania 2016 website. --Yiyi (Dimmi!) 09:28, 7 January 2016 (UTC)[reply]

For example: “2008 in rail transport in the United Kingdom” into: “2008 in rail transport in England” and “2008 in rail transport in Scotland”? Their are some station split offs but they are minor. In this example there are more than a thousand images. Years with much less images can remain UK. Smiley.toerist (talk) 10:17, 7 January 2016 (UTC)[reply]

I made the category Category:2008 in rail transport in Scotland, but I found very few pictures of Scotland, but maybe I missed some.Smiley.toerist (talk) 00:36, 10 January 2016 (UTC)[reply]

How to add wikidata to "Google Art Project"-files? like this one were I have added wikidata, but it is not visible File:P.S. Krøyer - Summer evening on Skagen's Beach. Anna Ancher and Marie Krøyer walking together. - Google Art Project.jpg and File:P.S. Krøyer - Roses. Marie Krøyer seated in the deckchair in the garden by Mrs Bendsen's house - Google Art Project.jpg --Villy Fink Isaksen (talk) 12:51, 7 January 2016 (UTC)[reply]

I went ahead and added it as "commons:wikidata" to stay in line with the rest of the templates parameters there. See my edit to File:P.S. Krøyer - Summer evening on Skagen's Beach. Anna Ancher and Marie Krøyer walking together. - Google Art Project.jpg. BMacZero (talk) 17:17, 7 January 2016 (UTC)[reply]

Google Art Project already has it as 'wikidata', Google Cultural Institute was the one that was missing it. BMacZero (talk) 17:19, 7 January 2016 (UTC)[reply]

Our {{Information}} template misleads visitors, who subsequently credit images from the wikipedia to the uploader, not the actual photographer.

I am not vain, but I do google myself, occasionally. Through those searches I do find images I took myself, and uploaded here, which have been re-used elsewhere. But, by far, most of the images credited to me are images I merely uploaded.

I am sure other prolific uploaders would find that they too are routinely credited by visitors who re-used images from the commons, and were confused as to who to credit. These third party re-users are acting in good faith. They want to honor the IP rights of the actual photographer. The problem is that our Information pages place more emphasis on the uploader than the photographer. Geo Swan (talk) 17:34, 7 January 2016 (UTC)[reply]

Please, identify a specific problem with {{Information}} template, which can be fixed. Ruslik (talk) 18:39, 7 January 2016 (UTC)[reply]

I am also not sure, how the template can mislead reusers to credit the uploader, since it does not even contain a field for the uploader. --Sebari (talk) 19:37, 7 January 2016 (UTC)[reply]

• The template renders the actual photographers' name so it is much less prominent than that of the uploader. Good faith re-users should be forgiven for overlooking the actual photographers' name, and mistaking the contributors who merely uploaded the images are the ones who deserve to be credited.

examples of good faith re-users who confused uploaders with rights-holders

image and proper credit	re-used at url and credit as used
	http://www.movienewsguide.com/a-timeline-of-victorias-secret-angels-watch-video/38860 Photo Source: Wikimedia Commons/ Geo Swan
	http://kddidit.com/2015/02/16/word-confusion-tort-versus-torte/ Image by Geo Swan (Own work) [GFDL or CC-BY-SA-3.0-2.5-2.0-1.0], via Wikimedia Commons
	http://www.boomsbeat.com/articles/8166/20140901/36-gorgeous-photos-of-grand-harbour-in-malta.htm (Photo : Source: Wikimedia/ Geo Swan)
	http://www.routeyou.com/en-us/route/view/2060062/cycle-route/east-coast-greenway-pa-nj-ny Source: Geo Swan Copyright: CC 3.0
[[

• This is less a problem with the Information template and more a problem with the file page, which is overloaded with a lot of junk. The media viewer is much better for end users/reusers for that reason. The best solution would be to have much cleaner file pages that hide a lot of the extra information by default. (Some templates are also at fault here. The current picture of the day has one complete page only with "badge templates". This is ridiculous.) --Sebari (talk) 07:20, 8 January 2016 (UTC)[reply]

• User:Geo Swan, looks like you discovered that the internet is full of stupid — who knew? What you call «Good faith re-users» are people who cannot read: those cannot be helped, not with text.

I worry about your own compreension abilities, though, User:Geo Swan: You singled out the {{Information}} template for this complain: you mentioned it in the title and stated repeatedly that it «renders the actual photographers' name so it is much less prominent than that of the uploader», even after you were warned that uploader’s name is not even covered as a field of this template. Apparently you think that the section #filehistory of a filepage is somehow triggered or generated by the {{Information}} template. Well, it is not. It is a mediawiki default (and no, User:Srittau, it should not be hidden).

When correctly filled out, the {{Information}} template will display the file’s authorship byline correctly, and even the clumsy kludge that is MediaViewer is able to read that information and present it correctly in its dumbed-down interface. The fact that the uploader’s name does show up in MediaViewer at all, though, might be the explanation for the mentioned misattributions, as for the casual re-user it may not be obvious that a square smiley on the left marks the author while a square smiley with an arrow at the right, along all other info, marks somtehing meaningless for re-use. (This, User:Srittau, is what should be hidden: the uploader’s name in MediaViewer).

So looks like what needs to be changed, maybe even questioned, is not {{Information}} but Media Viewer. Good luck with that.

-- Tuválkin ✉ ✇ 08:33, 8 January 2016 (UTC)[reply]

I didn't even notice that the uploader is mentioned in the Media Viewer. That is indeed ... strange and probably the source of the problem. --Sebari (talk) 12:19, 8 January 2016 (UTC)[reply]

• User:Tuvalkin, first, have you ever heard the advice "don't shoot the messenger"?

With regard to reading comprehension and intelligence... Have you ever studied human factors? I am not an expert, but I know enough to know that even PhDs prefer to read documents written at a primary grade comprehension level. This is particularly true if it outside their area of expertise. When lots and lots of otherwise intelligent people make the same mistake, over and over and over again, should we really just write them all off as "stupid"?

You wrote: "you discovered that the internet is full of stupid ... people who cannot read ... cannot be helped, not with text." This is why I asked if you knew anything about human factors. Error-prone interfaces are redesigned, and replaced by less error-prone interfaces, all the time -- including text interfaces. Geo Swan (talk) 03:47, 10 January 2016 (UTC)[reply]

So, you got offended and misunderstood what I wrote (shoot the messenger indeed), and even changed the section title. Still, so far you only managed to add wood to the fire about the “fact” that user-generated templates are bad (in this case, the blameless {{information}}) — someone will use your diffs futurely as “proof” that Commons is broken and all you need is Frankenwiki Wikidata…

Meanwhile, are you going to address the actual problem? That the Most Holy and Exalted Mediaviwer does include a very proeminent field displaying the completely unnecessary and misleading data entry about a file’s uploader, causing the problem you encountered? Are you going to ask the WMF to fix Mediaviwer so that it doesn’t include uploader’s name? If so, pls link here the relevant url, so we all can pile on help out. If you’re not, well, …I’ll go back to categorize photos of trams or clocks or whatever.

-- Tuválkin ✉ ✇ 04:57, 10 January 2016 (UTC)[reply]

Created as Phabricator task. --Sebari (talk) 11:52, 10 January 2016 (UTC)[reply]

I note that the uploader name is displayed as "Uploaded by <name>", so jabs at the smileys are somewhat dishonest. Anyway, Pete Forsyth already pointed out the problem a few weeks ago, and it's fixed in the version that will go live next week. --Tgr (WMF) (talk) 12:36, 10 January 2016 (UTC)[reply]

While I’m all for having the word "dishonest" in sentences pertaining MediaViewer, you seem to have it backwards: On one hand, the fact that the interface displays "Uploaded by <name>" reinforces the jab about this being a problem caused by reusers who cannot (or do not bother to) read, and also on the other hand it is still a piece of information that, in the dumbed-down UI of Mediaviewer, should not be displayed at all (though, in the context of its announced removal, yay!, it would be interesting to find out how come it was even ever included, especially at the expense of other things such as, to name but one glaring lack, file size). -- Tuválkin ✉ ✇ 18:30, 10 January 2016 (UTC)[reply]

Above I accused User:Geo Swan of having changed the title of this section during the discussion. That’s not true (and I only noticed after being warned by Geo Swan), and I want to publicly apologize for that. -- Tuválkin ✉ ✇ 20:28, 11 January 2016 (UTC)[reply]

and here some of the confusion of uploading others work could be mitigated by using artwork or photograph template; but this is not an option for wizard and vicuna uploader. information template is clearly inadequate. institutions are driven to using custom templates with GWupload tool. Slowking4♡Richard Arthur Norton's revenge 00:08, 12 January 2016 (UTC)[reply]

I moved the watermarked Russian description of this image (Розетка РП-2Б ~10А 42В) to Exif, according to Commons guidelines, but a series of ? appear. Doesn't Exif accept Cyrillic characters or is it just my software fault?--Carnby (talk) 20:54, 7 January 2016 (UTC)[reply]

Some of the fields in the exif standard are defined as only allowing ASCII characters. Try encoding the metadata as XMP instead of ascii. The exiftool program should support doing this. (for some fields, xmp has the addirional benefit of allowing someone to give multiple language versions of a field). Bawolff (talk) 16:22, 8 January 2016 (UTC)[reply]

I have added an IPTC field and it seems to work. Do you think it's OK now?--Carnby (talk) 22:24, 8 January 2016 (UTC)[reply]

File:Diagram_Modern_symphony_orchestra-zh-cn.svg--fireattack (talk) 02:26, 8 January 2016 (UTC)[reply]

For me it's looking okay.

Please purge your browser’s cache or enable JavaScript in your Browser's settings. (You only need to do it once.)

If it's still different, please have a look at COM:SVG. -- Rillke^(q?) 02:50, 8 January 2016 (UTC)[reply]

Did you look closely? On this png thumb the Hanjis on the right orange box are stacked together and the ones on the left orange box are out of the box.--fireattack (talk) 03:58, 8 January 2016 (UTC)[reply]

Now I see the issue. Perhaps someone from the COM:GVP can help. -- Rillke^(q?) 06:12, 8 January 2016 (UTC)[reply]

Fixed Removed all Inkscape garbage codes and tspan and reorganized the code structure. -- Sameboat - 同舟 (talk · contri.) 07:13, 8 January 2016 (UTC)[reply]

I am still having a problem with the PNG rendering of SVGs. There is a bug report I believe. Since a software update around May or June 2015 these are not rendered properly. Delphi234 (talk) 14:55, 8 January 2016 (UTC)[reply]

Fixed The problem is that this SVG relied on scaling up for more than 20 times from a relatively small native dimension (36.54 by 27.2 to 750 by 560). Text scaling of Librsvg is known to be extremely inaccurate, therefore all SVG on Wikimedia should be shown at its true native dimension. I gave the font-size the resultant value of 23.5px, redefined the viewBox values and manually scaled up all position values and other graph elements by 20.5 individually. -- Sameboat - 同舟 (talk · contri.) 15:30, 8 January 2016 (UTC)[reply]

Thank you very much! --fireattack (talk) 16:48, 8 January 2016 (UTC)[reply]

I raised an issue with the iOS-verion of the Wikipedia app on Phabricator (phab:T100335) back in May 2015. The app currently only dispays the name of the copyright holder (or rather the name in the author field), not the license, nor a link to the license or a link to the description page. Just wanted to make the community aware of this issue. What were to happen if another copyright provider were to file a DMCA-takdown for a file proveded on Commons for the apps inability to properly fufill the licensing agreements for the files? (Android however offers a link to the description page if the menu button is pressed, so kudos for Android). Josve05a (talk) 14:20, 8 January 2016 (UTC)[reply]

I am not sure there is any legal basis for a DMCA-takedown. This is a problem for the application, not Commons. Ruslik (talk) 19:13, 8 January 2016 (UTC)[reply]

True, but was a retorical question for the developers. Still, they are using "our" (using that term in a non-legal way) files, and we should be outraged. Josve05a (talk) 20:07, 8 January 2016 (UTC)[reply]

Is it ok to create a category that contains just one image so it can be linked to Wikidata? --Richard Arthur Norton (1958- ) (talk) 16:36, 8 January 2016 (UTC)[reply]

• Yes. - Jmabel ! talk 16:50, 8 January 2016 (UTC)[reply]

Is the link visible? And wath happens when the Category is renamed or split up?Smiley.toerist (talk) 21:19, 8 January 2016 (UTC)[reply]

S.t., by "linked to Wikidata" Richard presumably means having the category used in a Wikidata item: that is, there is presumably already a Wikidata item to which this one image relates, so I don't see how this would be any different than for any other category. @Richard Arthur Norton (1958- ): just for clarity, could you say what image this is about? - Jmabel ! talk 01:07, 10 January 2016 (UTC)[reply]

I think this example illustrates it best: Category:William C. Gover. He does not have an entry in Wikipedia, but he has an entry in Wikidata. Wikidata only gives one slot to link to Wikicommons, it can be a Person-page or a Category, so I create a category for that person. Person pages tend to get deleted as "not notable" and they tend to not contain all the items in a category. For now there is one item. There is a bit of text to help link them back up, if the link to Wikidata gets broken. When there are multiple people with similar names, a birth and death date and a little context in Commons is helpful. Sometimes when Jr and Sr or I, II, III, and IV have the same name, it isn't obvious to whom the documents here belong. Many times Wikipedia links to the wrong generation at Commons. --Richard Arthur Norton (1958- ) (talk) 20:18, 11 January 2016 (UTC)[reply]

Hello. The day before yesterday I noticed we have several paintings called File:NAMEOFTHEPAINTER_NUMBER.jpg (e.g.: File:Nicolas_Poussin_073.jpg). I renamed some of them under the second file renaming criterion (ambiguous names) to a name which included the work title and, if needed, further disambiguation. @Multichill: didn't agree e we started talking about that (you can find our debate here).

My point is:

1. these filemoves are useful, because when I create an article on a Wikiproject I search for the subject on the Commons searchbar. If the image illustrating Et in Arcadia ego is called "031" I won't find it.
2. these filemoves are covered by the policy. One of the example provided in Commons:File renaming is File:Paris 319.jpg->File:Paris 75018 Rue Norvins no 018 Le Consulat z.jpg, which is the same thing as File:Nicolas Poussin 031.jpg->File:Nicolas Poussin - Et in Arcadia ego (première version).jpg

As Multichill and I weren't able to reach a consensus, I'm here to ask to you all--Formica rufa 10:47, 9 January 2016 (UTC)[reply]

In my opinion, both cases above (Poussin and Paris) were both renamed to better names, but they shouldn’t have been. The spirit of COM:FR is to ensure filename stability; it does open to a few exceptions where the current filename is so bad that improving it is a superior gain than ensuring filename stability, but that’s just that: exceptional circumstances where filename stability can/should be breached.

But replace a not-so-bad filename with a better one? No, don’t: That’s bad for Commons, as anybody can think of an improvement and fight for it. COM:FR wisely (though less so in its current, revised form) blocks this snowball effect of file renaming done for improvement sake.

Any (further) change of COM:FR should be discussed as such, not prompted by random particulars.

-- Tuválkin ✉ ✇ 15:28, 9 January 2016 (UTC)[reply]

1. Adding the title is enough, no need to rename here. Why didn't you just do that?
2. Comparing a city where millions of people live(d) with one single person is trying to stretch the policy too much. The whole point of the renaming policy is to use it sparsely because of the impact. Your proposed renames would impact about 10.000 highly used files that had these names for over 10 years without any problems.

Multichill (talk) 15:35, 9 January 2016 (UTC)[reply]

I think Multichill is right. In general, name stability is good. It would have been better if the uploader had used great names rather than good names, but in general we don't mess with good names. Just get the information into the text associated with the image, not necessarily the filename. - Jmabel ! talk 01:09, 10 January 2016 (UTC)[reply]

I agree with Jmabel and Multichill, those files should not have been renamed, those were not good names but not "ambiguous". User:Formica rufa were much better names but we do not need perfection here just uniqueness and not being wrong. --Jarekt (talk) 21:26, 11 January 2016 (UTC)[reply]

Where is this? This was not far from a railway station on a railway line to/from Manchester. At the same time these pictures (File:Close to Manchester (1).jpg, File:Close to Manchester (1).jpg) were also taken. About one hour later this picture (File:SPT livery train in England.jpg) was taken. Any idea wich station? Not a Scottisch one as the SPT livery would suggest.Smiley.toerist (talk) 10:36, 10 January 2016 (UTC)[reply]

A global ban request] for User:Messina hs been placed. He is infinitely blocked on commons for copyright violations and sockpuppetry.--Gonzo.Lubitsch (talk) 11:44, 10 January 2016 (UTC)[reply]

You surely mean indefinitely blocked, yes? -- Tuválkin ✉ ✇ 18:04, 10 January 2016 (UTC)[reply]

Template:Tlsx and Template:Tlxs do the same thing with small differences: 1) tlxs supports 8 params, tlsx supports only 6 params; 2) tlsx is a little smarter 3) tlsx has a link for "subst" word. Why do we have 2 of them? Why 8 vs 6 ? Could we merge them into one ? Нирваньчик (talk) 21:42, 10 January 2016 (UTC)[reply]

Another problem. They are both poorly documented and don't mention each other btw. I'd like to add more documentation but Template:Tlxs is protected and documentation is in template code. What to do? Нирваньчик (talk) 21:42, 10 January 2016 (UTC)[reply]

• "Tlxs" is probably the better name. I'd go to its talk page and propose your specific changes there. If no one is paying attention, then probably ping whoever applied the protection. (Ultimately, "Tlsx" can just become a redirect to "Tlxs".) - Jmabel ! talk 01:29, 11 January 2016 (UTC)[reply]

This weeks photo is up at Commons:Silly things

I'd like to see some suggestions this week , last week didn't get any. ShakespeareFan00 (talk) 10:46, 11 January 2016 (UTC)[reply]

Taking photographs from the exhibition sometimes creates problems because of large frames that create shadows on the paintings. How should such shadows treated? I normaly crop the shadows away. see the uncropped photo here File:Camille pissarro med mørk skygge.jpg and the cropped here File:La Rue Saint-Honoré, matin, effet de soleil.jpg. The cropped photo is ofcourse missing some of the painting.

How should such problems be treated? --Villy Fink Isaksen (talk) 11:34, 11 January 2016 (UTC)[reply]

For some reason, other versions arranged using <gallery> tag in file description of file pages, appears differently in other projects like Wikipedias. Is that intentional? (if so why?) or a bug? Please see these examples: in commons: https://commons.wikimedia.org/wiki/File:Hump_Nosed_Pit_Viper_@_Kanjirappally,_Kerala_01.JPG , in en.wp: https://en.wikipedia.org/wiki/File:Hump_Nosed_Pit_Viper_@_Kanjirappally,_Kerala_01.JPG, in ml.wp: https://ml.wikipedia.org/wiki/File:Hump_Nosed_Pit_Viper_@_Kanjirappally,_Kerala_01.JPG . Regards--Praveen:talk 12:52, 11 January 2016 (UTC)[reply]

I assume it is not intentional, but that is more of a question for people at the other wikipedias, since I assume that we do not control how things are displayed on other Wikipedia projects. Also I am confused why other projects even need a page to re-display commons content. Would not it be easier to just display the file at Commons? --Jarekt (talk) 21:18, 11 January 2016 (UTC)[reply]

page specific css/js doesnt get transferred properly, which includes css for galleries. Bawolff (talk) 15:43, 12 January 2016 (UTC)[reply]

I mean this is a bug, because I also remarked that newly. All images on galleries get vertical instead of horizontal. If I refresh the page, it appears as expected. ↔ User: Perhelion (Commons: = crap?)  16:41, 12 January 2016 (UTC)[reply]

Yes I find that annoying too. I guess, the reason why Wikipedia doesn't links to Commons per default is because of the MediaViewer gadget. Because the user option wether someone would like to use MV or not would be bypassed that way. --Alexrk2 (talk) 17:03, 12 January 2016 (UTC)[reply]

For everyone that's interested: I have been playing around a bit with Wikidata and how it can help Commons and this is one thing I have come up with. Recently we deleted lots of airport categories that had names like "ABCD (airport)", where ABCD was an ICAO code (international airport code), because it was felt that categories should be named using the "common name" of an airport. (And the fact that not every airport has an ICAO code.) Nevertheless participants in the discussion also had the opinion that a list of airport by ICAO code would be useful. Using Template:Wikidata list and a SPARQL query I came up with this list, which is updated daily by a bot. This is far from perfect, for various reasons:

• Template:Wikidata list is limited to 5000 entries. Currently these lists have over 2000 entries, but the total number of airports in Wikidata is over 20000. The lists should be split into sub-pages (by continent?) anyway.
• The Commons categories are not directly linked (except on the name, when the interwiki link in Wikidata points to a Commons category).
• The link to Wikidata is in the form of an ugly number, instead of a neat little icon or something similar.
• The biggest problem is that the data quality is still not the greatest. I am sure we have more than 2000 airport categories on Commons, but the items on Wikidata are missing the appropriate links. (For reference, I am going by the Commons category property, not by any of the alternative schemes suggested for linking to Commons). Also, many airport items on Wikidata are missing information like the country, the ICAO code, or the IATA code.

Nevertheless, I think these lists show the potential of Wikidata for Commons, so I just wanted to throw this out here. --Sebari (talk) 22:22, 11 January 2016 (UTC)[reply]

I now extremely frequently experiment this bug: https://phabricator.wikimedia.org/T115563

In Chrome inspector, the console shows this kind of errors (e.g. for one of the images):

"GET https://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Applications-office.svg/50px-Applications-office.svg.png net::ERR_SPDY_PROTOCOL_ERROR"

The bug in fact appears almost immediately after loading successfully only a handful of images (or javascripts or CSS stylesheets). If a page uses more than about 12 HTTPS ressources, only a few will load successfully and all the others are not correctly pipelined.

Extremely rapidly after there has been enough errors (a few minutes of navigation), I also experiment HTTP error 400 (bad request), on any URL pointing to any Wikimedia server (wikis, image servers, phabricator, etc.) including for just loading the home page.

Then I can no longer browse any website (including from another device such as my Android smartphone). My router has all its allocatable TCP ports occupied.

Visibly, the HTTP/2 (SPDY) protocol has severe problems with HTTPS, its sessions are corrupted.

Google seems to deprecate now its early developement of SPDY, since HTTP/2 as been standardized. So it's possibly that there's an unsolved compatibility problem between SPDY and the approved HTTP/2 standard, within specific contexts, notably when connecting with HTTPS. Affected sites: all Wikimedia wikis, as well as Reddit and a few others (this does not affect Google sites such as Google.com itself, Youtube, Google+, or its Play store). Apparently the affected sites are using the same kind of front proxies.

I get the same error with any browser (IE, Firefox, Chrome) on Windows 10, either 32 bit or 64 bit, and even on my Android smartphone.

Something is wrong and seems to be also related to the fact that I'm connected to the net via a NAT router (with about 24 devices connected to the same router, number varying, most of them Android smartphones, a handful of PCs, an XBox). Apparently the number of NAT-routed TCP ports gets rapidly exhausted, there's no more any port available. The router sees a lot (thousands) of port numbers still occupied but with ending sessions. Then the NAT router rejects lots of incoming packets notably TCP packets for new sessions (such as "First packet in connection is not a SYN packet: TCP 192.168.1.15:52550->173.194.(masked):443 on ppp0"). And Internet becomes unusable. (I must then reboot the router to cleanup the occupied terminating TCP ports).

Almost all the occupied dead ports are those from Wikimedia HTTPS servers.

Really someting is wrong in Wikimedia servers with HTTPS + SPDY: sessions are not properly terminated and this causes severe havoc in NAT routers.

My opinion is that it may be a bug in HTTPS in your front proxies. They don't work correctly with SPDY and don't terminate the sessions properly (the last packet closing the sessions is apparently not transmitted, our client TCP sessions will only terminate after a very long timeout, it's possible that the last packet is transmitted but not encrypted properly in the correct TCP session for HTTPS, so it is not received or invalidated on reception). I suspect the bug is somewhere in Squid which equips Wikimedia sites.

For now if I'm lucky enough, I can browse and edit the wikis for some minutes, but I see almost no thumbnails for images or icons in the page; most of theSE IMAGES are missing and show this "net::ERR_SPDY_PROTOCOL_ERROR" when looking at details. But very frequently I see now CSS stylesheets not loaded and well and lots of presentation errors. For Wikipedia it is not dramatic, but for Commons, the site is almost unusable without the images.

This has started since about mid-december. Rebooting the NAT router has no effect on this issue, it comes back immediately after when reloading the same pages, and even when my PC is still the only one connected to the router (after the reboot there may be a few Android devices connecting to it in a few minutes, none of them ore visiting Wikimedia websites, but they may connect to other websites depending on their loaded applications, but they don't perform a lot of request and their traffic is very small).

Additional request: Is there an option to navigate on Wikimedia without HTTPS ? Visibly if I use HTTP, the sites now forces the redirect to HTTPS.

There's also no option for me to connect with IPv6 (to avoid the NAT routing if the combination of [HTTPS+SPDY+client-side NAT] on IPv4 causes such unsolved problem), as my ISP still does transport IPv6 to the router. I could test that using a third-party IPv6 tunnel, but these tunnels are really too slow. verdy_p (talk) 16:22, 12 January 2016 (UTC)[reply]

Related bugs reported elsewhere (search on Google with "Squid net::ERR_SPDY_PROTOCOL_ERROR"):

• http://superuser.com/questions/489042/using-secure-proxies-with-google-chrome
• https://ma.ttias.be/nginx-spdy-error-neterr_spdy_protocol_error/
• https://support.zenmate.com/hc/en-us/articles/204423722-Chrome-error-ERR-SPDY-PROTOCOL-ERROR-
• https://trac.nginx.org/nginx/ticket/190 (interesting hint: there's a bug in SPDY v2 solved by Google in SPDY v3, and fixed with a workaround in the Nginx server for clients using SPDY v2)
• http://www.isitdownrightnow.com/wikipedia.org.html (various reports of problems affecting Wikimedia sites, notably "net::ERR_SPDY_PROTOCOL_ERROR" with HTTPS)
• http://wm-bot.wmflabs.org/~wm-bot/logs/%23wikimedia-operations/20150913.txt (saved IRC discussion, including some details about the configuration blocking filters on Wikimedia servers against some kinds of attacks)

It looks like this is a problem of certificate validation for HTTPS when using server-side or client-side proxies and client-side NAT. Something is wrong with Google's SPDY (but that does not affect HTTP/2 itself), the secure sessions are not properly terminated with SPDY and an incorrect certificate or secure key is used for the first (SYN) or last packet of the session, leaving many idle/dying TCP ports, and causing various other symptoms (such as in firewalls, blocking invalid sessions as if they were SYN-flood attacks, or attempts to inject data in a secure session that is not first authenticated).

This bug was apparently a possible cause of DOS attacks against Wikimedia servers. A workaround/patch was setup against those attacks, but normal users may be affected (the workaround does not seem to be fully compatible with the SPDY v2 protocol: what caused a bug on Wikimedia servers or Squid proxies now causes severe bugs on clients in their routers/browsers).

For Wikimedia Commons, this bug (that I see now very frequently since mid-december) has a very severe impact (more severe than on Wikipedia) as this affects the loading of almost all images and medias (we can still use Wikipedia with the non-loaded images). verdy_p (talk) 17:13, 12 January 2016 (UTC)[reply]

• I can't really comment on the technical aspect of the error but I can report that I have the same issue fairly regularly too. Diliff (talk) 18:42, 12 January 2016 (UTC)[reply]
• I have this problem a lot. Firebrace (talk) 00:08, 13 January 2016 (UTC)[reply]

Prompted by this, I would like to see a matter discussed and clarified: What should be used as the |source argument of the {{Information}} template (and other such templates)? In the past I was asked to put there only one single url, as opposed to a direct image link and one or several context pages, or even multiple urls for PD-old images (by User:Yann, if I recall correctly). In contrast User:Sevela.p (and possibly many others) insist that such disparate information such as camera model and uploading software, only remotely related to the source of a file, should also be refered to in this field, not just {{own}}. Who is right? -- Tuválkin ✉ ✇ 19:43, 12 January 2016 (UTC)[reply]

• I'm not sure we have any clear policy, but I find it very useful to have but a direct image link and one context pages (especially if the latter helps clarify copyright status); several context pages is usually overdoing it, though I guess it might sometimes be useful. Camera model and uploading software certainly don't belong in this particular field; indeed, I find it hard to imagine why anyone cares at all about uploading software.
• In general, however, on other people's uploads I tend to defer to whatever the uploaded chose, unless it is clearly wrong.
• Also, for what it's worth, I've never liked {{Own}} at all. I suppose it's OK for people who casually upload a few photos and aren't at all concerned about being credited by reusers, but it is almost guaranteed to result in incorrect attribution for any derivative works, and often results in incorrect attribution on reuse by newspapers, etc. I'd guess that well over 1000 of my pictures on Commons have been republished outside of WMF projects, so at least for me this is no small concern. I always use "Photo by [[User:Jmabel|Joe Mabel]]" and I revert on the rare occasion someone tries to change that to {{Own}}. - Jmabel ! talk 20:06, 12 January 2016 (UTC)[reply]

The exhaustive instructions are in the {{Information}} documentation. Ruslik (talk) 20:08, 12 January 2016 (UTC)[reply]

@Tuvalkin: I doubt I said there should be "only one single url" in the source field. Regards, Yann (talk) 21:37, 12 January 2016 (UTC)[reply]

• As Ruslik mentioned above and in detail at Commons:Essential information. The link(s) should be enough for a viewer or license reviewer to verify the media depicted has a valid license. If everything is in a single source, one URL is enough. But some sites mention license in a special page; then it should also be mentioned. In some sites, the media is listed as a slide view or other similar mechanism where it is difficult for a license reviewer to find it quickly. In such cases, mentioning the direct file URL too is advised. I had fixed several failed reviews from that site alone. (BTW, it seems that "note" at Commons:Essential information seems outdated considering recent developments from CC.)

Jmabel: {{Own}} has translations. When we replace it with our own words like "own work by <author>", we will loss that feature and <author> become redundant. If {{Own}} is ambiguous, it can be discussed. "Own work by the author mentioned below" may looks better. But in my opinion, a simple mentioning of "Original" is enough as it is "original source". Jee 03:35, 13 January 2016 (UTC)[reply]

@Jkadavoor: Other people are welcome to use {{Own}} on their uploads, I have no problem with that. However, I found when I tried using it for a while a few years back that I got a very high percentage of misattributions, and I'm no longer willing to go that way with my uploads of my own photos. - Jmabel ! talk 04:44, 13 January 2016 (UTC)[reply]

Hi Commons,

I maintain a page on enwiki to keep track of/organize my media uploads to Commons and to WP. It's mostly for my own sake (it's not linked to from anywhere other than a tiny link on my userpage..and now from this thread). Is there any way to prevent images I display on that page from showing up as "File usage on other wikis"? The primary reason is to avoid "usages" from registering when I use the gadget which shows usages in MyGallery (or other tools which do so). I know that I could move the page to Commons (or, you know, not have the page at all); I'm hoping for an alternative (something like a magic word). — Rhododendrites ^talk |  21:13, 12 January 2016 (UTC)[reply]

@Rhododendrites: I am afraid there is currently no method inside MediaWiki itself to avoid this, however you could add files that you created (seeing as you have also uploaded other people's works, too) to a hidden user category (using {{User category}}) and then track their usage in main namespace only with the GLAMorous tool. It should be pretty easy and quick to do mass-categorize your files using Cat-a-lot. Hope this helps! odder (talk) 21:34, 12 January 2016 (UTC)[reply]

Hi. Sometimes I see images that have many categories that describe everything in the image. For example, this or this image. Is it a good idea to try and describe everything and for an image to have that many categories?--Дима Г (talk) 21:58, 12 January 2016 (UTC)[reply]

Yes, both pictures are overcategorized. Pictures that are in a category and its parent category are overcategorized.

• In the first picture, Sitting is the parent category of "Paintings of girls sitting on the ground outdoors", through "Paintings of sitting girls" → "Sitting girls in art" → "Sitting females in art" → "Sitting people in art" → "Sitting in art".
• In the second picture "Females facing left" is the parent category of "Women facing left and looking left".--Snaevar (talk) 22:58, 12 January 2016 (UTC)[reply]

Looks like we are going to hit the 30M milestone pretty soon. :) Jean-Fred (talk) 22:55, 12 January 2016 (UTC)[reply]

Yeah, only 6845 files to go! 70.30.41.112 00:35, 13 January 2016 (UTC)[reply]

The 30M file will probably be one of Hansmuller's dead birds... INeverCry 01:49, 13 January 2016 (UTC)[reply]

When I uploaded this one, at 2016-01-13T06:13:32, it got stamped as the 29,997,316th file… -- Tuválkin ✉ ✇ 06:50, 13 January 2016 (UTC)[reply]

We passed it now. Pyb twitted I believe the NewFiles at that moment. Jean-Fred (talk) 10:10, 13 January 2016 (UTC)[reply]

It's correct. "We" should probably select a file from the dead birds batch upload. Pyb (talk) 10:13, 13 January 2016 (UTC)[reply]

Ah, at least one of my long term slow large NYPL tiffs made it onto that screen cap as well as the Asamblea Nacional del Ecuador project. If there's a press release, maybe we should give honourable mentions to the nearby files/interesting projects rather than limiting the interest to one photo? --Fæ (talk) 10:41, 13 January 2016 (UTC)[reply]

Commons:Press releases/30M? Sławek Borewicz (talk) 05:05, 13 January 2016 (UTC)[reply]

Hi,

I have been working on a project to improve the categorization of pictures in the Upload to Commons Android app as part of the Outreachy Dec '15 program. Phase 1 of the project has been implemented, and the app should now suggest nearby categories when a picture is uploaded.

Feedback on this feature would be greatly appreciated, so please feel free to download the updated version of the app and to post feedback/issues on the GitHub page.

Please note that to use this new feature, you will need to have location tagging enabled for your camera.

Thanks!

Misaochaaan (talk) 04:05, 13 January 2016 (UTC)[reply]

It will soon be possible to patrol files, see gerrit:251795 which should be deployed on Commons within a few days. You may test this at Testwiki: already. New files and new file versions will be patrollable, and you'll be able to search for unpatrolled new files at special:newfiles. Cenarium (talk) 13:00, 13 January 2016 (UTC)[reply]