This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Organization by categories makes images harder to find

The current oranization by categories makes it hard to find things. One must search up and down through a large tree of pages, each showing perhaps only a few images, or none. For example, the search for "squid" returns a page for the order, with two dozen links for the genera, which in turn have links for the species. One would have to navigate through a hundred pages to see all available images of a squid. And one may miss images of squids that have not been categorized, or have been filed under other categories. (Apologies if there is a better way to search this site that I haven't noticed.)

A category tree organization makes some sense with physical items like books and records, because each item can be placed into only ONE shelf. For virtual contents, however, there is no reason to use a tree organization. Instead, one should provide a search tool capable of boolean searches (e.g. '(squid OR octopus) AND NOT dish") and present the results as a flat list. Then each picture could be assigned to multiple arbitrary categories, which would be tretaed as keywords for search purposes. --Jorge Stolfi (talk) 01:08, 26 April 2014 (UTC)

The category tree you don’t like is meant to be used by grown-ups. If you want to gawk at random slideshows of stuff and pick the first shining object that shows up from a pool of almost 21 million items, you should rather try this: http://www.google.com/search?tbm=isch&q=site%3Acommons.wikimedia.org%20squid&tbs=imgo:1 (P.S.: Commons’ file pages have, or should have, multiple categories.) -- Tuválkin ✉ 02:14, 26 April 2014 (UTC)

Mediawiki's categorisation system is a mess of arbitrarily defined criteria filled with circles, inconsistencies and idiosyncratic quirks. It's of absolutely no surprise that no other media library uses such a system. It's the kind of bullshit that causes embarrassing stories such as this. Using a tag based system and allowing these to be queried using joins and intersections is by far a more elegant and powerful system. We have categories such as Category:February 2010 in Toulouse when they should just be tagged with a location and a date, and yet we don't have Category:February 2010 in New York because our categorisation is different depending on which side of the Atlantic you're on. Very grown-up. - hahnchen 12:57, 26 April 2014 (UTC)

Jorge Stolfi -- There are some things which are probably not a good fit to hierarchical category organization, but classification of species is not one of them, considering that hierarchality of classifications has been a basic organizing principle of species classification since at least 1735, and confirmed scientifically in modern times by the rise of Cladistics. If categorizations of species on Commons were not hierarchically organized, then some additional hierarchical structuring would have to be imposed... AnonMoos (talk) 02:36, 26 April 2014 (UTC)

Category system is useful, and it's probably one of the best options for a voluntary based classification work. However, some searches are difficult using this system and we should work to make more tools available to users. The "quality images" button is a good step in this direction, but it would be useful to include in category pages some kind of link to in-category search (like the google search pointed by Tuvalkin) and to CatScan or something similar.--Pere prlpz (talk) 15:30, 26 April 2014 (UTC)

It is fine and proper to use the biological taxons as categories. What is not working is structuring the website as a tree of category pages, and forcing the reader to walk through that structure, page by page -- instead of using the categories as mere search tags.--143.106.24.25 23:29, 27 April 2014 (UTC)

Jorge Stolfi, Hahnchen, 143.106.24.25 -- I've seen unstructured keyword/keyphrase classification systems in operation, and I don't know that they're so much better than hierarchical categories. My experience has been that most entities are tagged minimally with just one or two keywords, while occasionally people go off on a free-association rambling of trying to express anything and everything that could be relevant about an image ("Christmas snapshot, Xmas snapshot, Christmas tree, Xmas tree, fuzzy sweaters, red pointy hat trimmed with white, drinking eggnog..." etc. etc.). I'm sure that unstructured keyword classification systems work reasonably well in some situations, but I don't think that a heterogeneous archive of 20 million images of many different types uploaded by many people for many purposes is such a situation. In particular, species classification is something which by its nature is particularly appropriate for a hierarchical category system. AnonMoos (talk) 23:39, 30 April 2014 (UTC)

Recommendation COM:Galleries#Redirects

“In the absence of a gallery, or if there is only a gallery with little or no content, a gallery title can be redirected to a corresponding category (a cross-namespace redirect).”
-- Perhelion (talk) 17:18, 26 April 2014 (UTC) What is the sense behind this, where from come this recommendation? A cross-namespace redirect should also be very well-founded. Admins also delete this redirects so this recommendation can also be deleted? -- Perhelion (talk) 14:09, 26 April 2014 (UTC)

concerning the absence of gallery pages for the overwhelming majority of categories it makes no sense for me to create such redirects at all. The gallery pages are a "nice to have" in the case they show a representative view of the topic. Furthermore, absence of a gallery page could indicate someone could create one. A redirect does not. From my point of view, the text mentioned should not only be removed, but replaced by a statement that such redirects are definitively not wanted at all and will be deleted. - Andy king50 (talk) 11:22, 27 April 2014 (UTC)

Thank you, I would completely agree you, but I found the according link and added it. The text was what you told, before 2009-04-28. For my understanding, this is obsolete, since the search has been improved? -- Perhelion (talk) 18:39, 30 April 2014 (UTC)

Deletion requests

Hi there. I nominated a photo for deletion here [1] and here [2]. Less than an hour later, the person who uploaded the photo closed the debate and archived the nomination. I'm not sure it's supposed to work like that. Thanks. Magnolia677 (talk) 16:35, 27 April 2014 (UTC)

Your action here by raising over 30 dubious deletion requests against the same person in a period of 2 hours, without prior discussion, may not be strictly against policy, but it cannot be considered to be Staying mellow. Please play nice. --Fæ (talk) 16:54, 27 April 2014 (UTC)

Magnolia677, your deletion requests are not helpful for Commons. It contrary, you disturb ithers with your actions. Deletion rationales like the mass spreading of "no educational value" or "Self promotion" or "dubious copyright" are wrong and not constructive. Refrain from working like this. And yes, it is legitimate to remove non-controversial and obvious nonsense - two issues above. --High Contrast (talk) 17:01, 27 April 2014 (UTC)

If you look at my history of contributing both on the Commons and on Wikipedia, I honestly have no history of not playing nice and have made thousands of edits to improve Wikipedia. I stumbled across this large collection of images and found a number of them to be--in my opinion--not educationally useful. For example, someone under newspapers on a train after Oktoberfest. I didn't nominate this for deletion to be mean or prudish, it just seems to be of no educational value. Other images appeared to be amateur porn, something the Commons explicitly does not host. I suppose it may have seemed like a lot of deletion requests, but the gallery contained thousands of photos. The uploaded referred to me as a "troll", but I just can't see how low-quality amateur porn shots add anything to Wikipedia. As for the model shots, they seemed of dubious copyright, and uploaders are cautioned that non-free images are often posted to Flickr. My original question though--about whether an uploader can close a debate and archive a nomination--still wasn't answered though. Magnolia677 (talk) 17:44, 27 April 2014 (UTC)

@Magnolia677: Hi,

High Contrast is right. Your deletion requests are not helpful for anyone. I closed a number of them, where there is no reason for deletion. Regards, Yann (talk) 17:58, 27 April 2014 (UTC)

In response, let me say here, in a very public way, and in a very public place - don't ever dismiss someone's concerns about pornography on Wikipedia as "nonsense". It states here that "the Commons is not an amateur porn site", so why on earth would you dismiss someone questioning this photo called "Woman in a so called 'sexy nurse outfit'" as "nonsense", as you did here? Yann, how dare you talk about what is helpful. Here we have an admin who didn't like that someone questioned the educational usefulness of some of the amateur porn they uploaded, like this, and instead of acting in an objective way, you dismiss my concern and insult me. In one case, I questioned this photo because the uploaded added a note which stated "other licensing terms can get discussed, too, via email." The uploader removed the nomination for deletion, and archived the discussion. Where in the deletion request policy does it give them the right to do that on their own photo? And you want to talk about what is "not helpful"? When you dismiss valid concerns about pornography, it sends out an unhealthy message. And as a regular contributor, I'm disappointed you quickly decided to both dismiss and insult me. Magnolia677 (talk) 21:03, 27 April 2014 (UTC)

Welcome to Commons, that's how it is here. — Scott • talk 13:08, 28 April 2014 (UTC)

@Magnolia677, I just looked at File:A can of Red Bull Cola.JPG and I have no idea what is wrong with it and why would you want to delete it. You mentioned "Blatant self-promotion", but I have no idea why a photo of a can of Red Bull would be a blatant self-promotion of User:High Contrast. Also notice that "self-promotion" is not listed on the list of Reasons_for_deletion. The image is used by bunch of wikipedias so it is not out of scope. I agree that this example DR is a nonsense nomination. --Jarekt (talk) 15:12, 28 April 2014 (UTC)

It's about {{User:High Contrast/Template:Credits}}, i.e. not the file itself, just the file description page. -- Rillke^(q?) 17:11, 28 April 2014 (UTC)

I get it now, I no longer see those templates. And this one is one of the least distracting. --Jarekt (talk) 18:12, 28 April 2014 (UTC)

It sends out an unhealthy message to stand by our policy that "Commons is not censored"? File:Erotikmesse Straubing 2010 (5143697704).jpg is not amateur porn; it's a photograph of a convention, that is not amateur at all. Commons is "not an amateur porn site" is not really about pornography; it's about a type of file people will upload despite the fact that they are manifestly out of scope.--Prosfilaes (talk) 19:43, 28 April 2014 (UTC)

I, too, do not believe that an admin should ever close a deletion discussion about an image they have uploaded themselves (unless perhaps it is very obvious vandalism/testing like a deletion rationale of pure gibberish like "akhfdbxbnds", although even then it is better to leave it to someone else). This isn't about the DRs itself being right or wrong — although some of them, like File:Young woman in deckchair.jpg or File:Beach in Kolka, Latvia.jpg, would likely have been deleted as "unused personal photo, out of scope" if they had been uploaded by a newbie and decided by the "right" admin. Not that I think they should be deleted, I'm just saying they very likely would have been. I think High Contrast (talk · contribs) should revert his closures, relist the DRs and have a different admin decide about their merit after the usual seven days. Some of the DRs (like the Red Bull Cola one, although I do wonder about COM:DW wrt that image?) really were nonsensical, but others appeared to be in good faith. darkweasel94 11:44, 29 April 2014 (UTC)

Magnolia677: Here I see three different topics:

1. COM:PORN: It is more about discouraging exhibitionism; not about "sexual contents". No further comments, as it is always a hot topic here.

2. COM:ADVERT: Yes; "content which constitutes advertising or self-promotion may be deleted from Commons." But I failed to see any "advertising or self-promotion" here. May be you are talking about User:High Contrast/Template:Credits as Rillke pointed above. If then, I assume you misunderstand the license terms. You can see there a number of times wordings like "Except as otherwise agreed in writing by the Licensor" and "UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING". There also mentioned that "Notwithstanding the above, Licensor reserves the right to release the Work under different license terms". Yes; the Licensor has every right to waive any restriction or grant a more free license. He has every right to accept a remuneration for it.

3. Self closing of a DR: I agree with darkweasel above. And the closing admin MUST educate the nominator what is wrong in his rational instead of using words like "Nonsense nomination". So I consider this closing also insulting. Our admins may busy and struggling with work load; but no excuse for anything. File:A can of Red Bull Cola.JPG need a {{Trademark}} warning, at least. J e e 03:18, 30 April 2014 (UTC)

I agree that admins shouldn't be closing DRs about images they uploaded, because this risks presenting at least an appearance of a conflict of interest, and that it would be best for High Contrast to revert their closures here. Another admin can handle it.

I also agree that "Nonsensical nomination" and "Nonsense request" are very poor closing rationales for such DRs. It would be better to say why the file (or file description) is acceptable here than to attack the nomination itself. --Avenue (talk) 01:56, 1 May 2014 (UTC)

Coat of arms

picture 1 & picture 2 - wouldn't be enough to have only one of them? — Preceding unsigned comment added by 149.156.172.74 (talk • contribs) 12:37, 30 April 2014 (UTC)

Probably not. No obvious way to tell which is to be preferred: they are certainly not duplicates. - 15:39, 30 April 2014 (UTC) -- User:Jmabel

149.156.172.74 -- In traditional European heraldry, it's the textual Blazon which is authoritative, and there can be many valid artistic renderings corresponding to the blazon. In any case, these two images include differing amounts of outside-the-shield accompaniments... AnonMoos (talk) 23:21, 30 April 2014 (UTC)

May 01

Category:Trucks by year

Hi, does it makes sence to start with a Category:Trucks by year similar to Category:Automobiles by year? Cause at the moment if you want to categorize a truck by year you just put it under Category:2002 automobiles for example. But Category:Trucks is not part of the Category:Automobiles so in my view it is not completely clear at the moment.

I m not sure if this is the right place to ask a question like this. Is there a traffic- or truck portal here on commons similar to the one on wikipedia (en:Portal:Trucks)? Thanks a lot, --W like wiki (talk) 01:29, 29 April 2014 (UTC)

Go ahead, yes. These two categories meet as siblings (ideally, along with others) under Category:Vehicles by year. -- Tuválkin ✉ 16:18, 30 April 2014 (UTC)

Where do SUVs then go which in the USA are officially classified as trucks and elsewhere as nuisance? OAlexander (talk) 18:59, 1 May 2014 (UTC)

Discussion to be continued here: Category talk:Trucks by year, --W like wiki (talk) 23:11, 13 May 2014 (UTC)

Basis of OTRS tickets

I'm curious as to the basis upon which the images in Category:Natalia Poklonskaya have been granted OTRS tickets. The images all come from different users and seem to enjoy the same status as any crowd-sourced image that appears on the internet. There is nothing on the originating site that indicates free licence has been granted. I'm asking because there are images that appear to be the same type of source that are used under free use rationales – would this mean for example that en:File:Cao ni ma CCTV fire.jpg is in realty GFDL compliant? --Ohconfucius (talk) 17:07, 29 April 2014 (UTC)

Maybe you'll get an answer here from an OTRS member, but normally to check the basis of OTRS tickets, you can ask on the OTRS noticeboard or you can ask the members who validated the tickets. I guess it's because the original images were not freely licensed that someone requested licensing through OTRS by their authors. The files have different tickets, which at least seems to hint that the the communications were made with each author. Many of the files were uploaded by the same Commons user, so he might be the person who initiated the requests and, if so, he could tell you more about the communications. You can also choose one or two of the files as examples and ask the question to the noticeboard or to the members who added those tickets. I don't understand what relation you are making with the file Cao ni ma CCTV fire.jpg and with the GFDL. -- Asclepias (talk) 18:32, 29 April 2014 (UTC)

I've alerted Benlisquare to this deletion's existence. --Michaeldsuarez (talk) 23:40, 29 April 2014 (UTC)

I personally contacted each individual Pixiv author one by one, and asked them to irrevocably release their works under a CC-BY-SA 3.0 license. In each case, the proper OTRS procedure was done per the steps at Commons:OTRS, and then handled by OTRS volunteers. Some users are from Japan, some from Taiwan, and some from Mainland China, and in each case I communicated with the artist in their respective native language. For example, As109 is a famous and popular Pixiv artist in Japan who has made numerous works, both erotic and non-erotic, and he lives in Mainland China; one of the works I've uploaded onto Commons was by him. Of all the Pixiv artists I've approached and asked, I'd say 70% of them kindly rejected my request when I asked them if they were interested in granting free licenses, because for many of these artists they rely on their art to make money, but in some cases artists are willing to freely share their works in good faith. -- 李博杰 —Talk contribs 04:25, 30 April 2014 (UTC)

P.S.: None of these images are licensed under GFDL, Ohconfucius, they are all CC licensed only. I don't know where you got that assumption from. Am I misunderstanding what you're trying to say? -- 李博杰 —Talk contribs 04:34, 30 April 2014 (UTC)

李博杰 , What a great image collection, thank you for doing such an impressive leg work. --Jarekt (talk) 22:48, 1 May 2014 (UTC)

April 30

Pics of Christopher Clavius

I think that pics in the category Christopher Clavius, are engraving versions of the pic of Paul Guldin, not of Clavius. Can someone confirm my feeling?--Ferran Mir (talk) 15:40, 1 May 2014 (UTC)

Convenience links: Category:Christopher Clavius, File:Paul Guldin.jpg. - Jmabel ! talk 15:49, 1 May 2014 (UTC)

Deletion request

Could somebody please delete a category, for which there is now a better-named alternative? [3]. The content has been removed to "Category:Trees in Richmond, London" Amandajm (talk) 04:35, 2 May 2014 (UTC)

The simplest way (requiring no admin intervention) would be to edit the disused category to consist of "{{category redirect|Trees in Richmond, London}}" and nothing else... AnonMoos (talk) 05:05, 2 May 2014 (UTC)

I usually use {{Emptypage}} to do that, this always results in deletion within a few hours. darkweasel94 05:29, 2 May 2014 (UTC)

24,600 high quality art history photographs

This statue of Shiva as Lord of Dance, is the most widely used LACMA image, in 105 Wikipedia pages and a Commons Featured Picture.

Re: Public domain images from the Los Angeles County Museum of Art: 24,731^R
Sample from the new uploads:

After a request by PKM, I have run a refresh of this batch upload (last done in July 2013), and added 2,354 new images released by LACMA. These are an unbeatably diverse collection of photographs to illustrate encyclopaedia articles on the history of art, or the types of artefact such as the history of costume, pottery or particular artists, artisans and illustrators. Glamorous tells me that around 3.5% of the images are in use in articles, which is a reasonable level of reuse for large batch uploads like this, but also shows how more could be made of this quality collection.

How you can help

Enjoy surfing through the different collections listed in Collections of the Los Angeles County Museum of Art and if you like the look of any image, illustrate (or if notable enough, create) a related article on Wikipedia in your language.
Images have basic categories, but can be improved by adding more useful categories relating to age, materials, style, location etc.
Some images may be extra special, think about putting them up for review as a Quality Image or Featured Picture.
Identify unnecessary duplicates or poor names by using {{Duplicate}} and {{Rename}} templates. These should be a small number of problems but are almost impossible to avoid in batch uploads where we rely on the accuracy of the museum catalogue/metadata.
If you have spotted any images being used elsewhere on the internet, don't forget to add the {{Published}} template to link it from the Commons image page.
If you have used any already, tell us about it here!

Thanks Fæ (talk) 11:53, 1 May 2014 (UTC)

My favorite among the new images I've seen so far is File:European Man Bitten by a Snake (top), Courtesan (?) (bottom) LACMA M.87.159.1a-b (1 of 2).jpg!! (No idea how one would use it in an article...) -- AnonMoos (talk) 15:53, 1 May 2014 (UTC)

Stereotypes and the perception of Europeans in South Asia would be an interesting topic. In this collection there are some lovely and extremely early examples of Indian watercolours of gods and goddesses that would make great illustrations, as well as portraits of important looking "Royals". I am pretty certain that the English Wikipedia could do with some tidying up and having quality illustrations in the area of Indian mythology and religious iconography. --Fæ (talk) 16:33, 1 May 2014 (UTC)

The other side of a coin from Constantinople, dated to 1757.

That's interesting. Thank you for the work and for mentioning it here. However, there's a question about numbers: LACMA say "Nearly 20,000 images of artworks the museum believes to be in the public domain are available to download on this site." And, indeed, on their site, the search function "show public domain images only" lists 19,679 images. But the Commons category "Public domain images from the Los Angeles County Museum of Art" has 24,628 files. Isn't that some 4,949 too many? (That would be roughly one out of four.) Can the category have almost five thousands duplicates or that many possible copyvios? -- Asclepias (talk) 18:13, 1 May 2014 (UTC)

Good question. The difference in numbers comes from the fact that LACMA is counting artworks rather than photographs. An example is the second image of the Turkish coin featured in the sample selection of images which I have included on the right. LACMA only counts these two photographs as one item in their catalogue. Using a bit of programming magic in my uploads, I have linked the two together using the other_versions parameter so they display on each other's image pages.

--Fæ (talk) 22:37, 1 May 2014 (UTC)

Thanks again for doing this upload. I have added two of the mantua photos to Mantua (clothing) and I plan to do more ( and serious category work) as soon as I can type with both hands again. Too bad Commons Commander won't work on the iPad.... - PKM (talk) 23:34, 2 May 2014 (UTC)

File:Baku Ferris Wheel.jpg

"The image on the Commons can be deleted. No FOP in Azerbaijan"

110.164.229.107 17:07, 2 May 2014 (UTC)

Protest! Since when are ferris wheels works of architecture, @Interfase: ? --A.Savin 17:26, 2 May 2014 (UTC)

Since it was built by Dutch Wheels, a leading designer of giant Ferris wheels. The rights of the design of this ferris wheel belongs to Dutch Wheels. --Interfase (talk) 17:38, 2 May 2014 (UTC)

Automobiles are either works of designers. I didn't know they were copyrighted too. Commons:Image_casebook#Vehicles, and ferris wheels are to me much more vehicles than buildings, aren't they? --A.Savin 17:54, 2 May 2014 (UTC)

If so, then it must be mentioned on Commons:FOP. Becuse I don't want that one day someone nominated the image of this ferris wheel to deletion. --Interfase (talk) 19:44, 2 May 2014 (UTC)

Here I wanted to prevent this image from being speedily deleted as requested by the IP; OK to a regular RfD discussion; I'm sure most of us won't see FoP problems here. --A.Savin 19:55, 2 May 2014 (UTC)

Then could you help to move this and this images to Commons? --Interfase (talk) 20:25, 2 May 2014 (UTC)

Done. --A.Savin 21:15, 2 May 2014 (UTC)

Media Viewer release on Commons next week

Media Viewer lets you browse larger images on Wikipedia.

Hi folks: as discussed in earlier posts, we're starting a wider release of Media Viewer, a new tool that aims to improve the viewing experience on Wikipedia and its sister sites.

This multimedia browser displays images in larger size and with less clutter, providing a more immersive user experience, as described here. It has been tested extensively on Commons, in collaboration with many community members -- including over 1,290 Commons beta users, who have been testing it since November 2013 -- and we're very grateful for all their great suggestions, which have helped improve the product considerably. The tool is already enabled by default on over a dozen sites (including the Dutch, French and Polish Wikipedia), where it has been well received. As a result, Media Viewer will be deployed more widely throughout May, as described in this release plan.

Can you share your feedback about this tool, to help address any critical issues before its May 8 release on the Commons? To try it out, please log in and click on the small 'Beta' link next to 'Preferences' in your personal menu. Then check the box next to 'Media Viewer' in the Beta Features section of your user preferences — and click 'Save'. You can now click on any thumbnail image on this site to see it in larger size in the Media Viewer. For more info, check out these testing tips or this Help page.

Once you've tried the tool, please share your feedback in this discussion, to help improve this feature. You're also welcome to take this quick survey -- or join this in-depth discussion on MediaWiki.org, as you prefer. Thanks for sharing your insights! Fabrice Florin (WMF) (talk) 17:39, 2 May 2014 (UTC)

Update: Based on today’s discussions with our engineering team, we would like to push back this release a week to May 15. We want to devote an entire release window to just Wikimedia Commons, because it is is a more complex deployment, which we want to track more closely than others. This will give us an extra week to respond to feedback about this product, as well as share what we're learning on other sites. Cheers. :) Fabrice Florin (WMF) (talk) 23:10, 2 May 2014 (UTC)

May 03

Images so big they break Commons?

Tracked in Phabricator
Task T54045

I have just uploaded an 1856 map of America from the NYPL, which is 14,418 × 4,268 pixels and has a file size of 176MB. This appears too large a resolution for Commons to create thumbnails for it. Are there any recommended work-arounds or solutions? --Fæ (talk) 08:14, 20 April 2014 (UTC)

A "difficult to view" concertina map of the Hudson River, 1834. Height of 14,000 pixels.

Probably that the software can't process TIFF files that big. I would suggest to keep this one as an archive, and upload a JPEG for practical use. Regards, Yann (talk) 09:21, 20 April 2014 (UTC)

I suggest a technically more suited replacement for TIFF would be PiNG. As far as I understand it, TIFF has only benefits for multiple images integrated into one file, and that is it. Probably all TIFFs - a format that had a purpose in its day - should be replaced with PiNGs. OAlexander (talk) 03:36, 26 April 2014 (UTC)

TIFF has color space options that PNG doesn't (PNG is limited to RGB), as well as standardized ways to store scanning information that PNG doesn't. The problem with TIFF is that it is a large standard with many, many options, and that very fact means you cannot losslessly convert arbitrary TIFF files to other formats.--Prosfilaes (talk) 19:48, 28 April 2014 (UTC)

Commons:Maximum file size says: "...for several filetypes (TIF and GIF) the software only produces thumbnails and previews on the main file description page below a certain size limit − currently, 1,000 megapixels." --TeleComNasSprVen (talk) 09:35, 20 April 2014 (UTC)

Good to know. I may be able to flag these in a backlog for attention, based on a simple calculation of height x width. Some of the maps look pretty large, more than 300MB. --Fæ (talk) 09:40, 20 April 2014 (UTC)

Occasionally on things this big, it's also good to provide a downscaled JPEG, or even one split up into vertical strips. - Jmabel ! talk 16:52, 20 April 2014 (UTC)

If anyone would like to experiment with finding a better way to present these high quality but very large images of maps from NYPL on Commons, I have created NYPL maps (over 50 megapixels): 1249.

With a book of very detailed maps of the Bronx uploaded today, the number of files over 50 megapixels has increased quite a bit. A bot to create under-50MP jpeg files from over-50MP sized tiffs would be handy to make these a more usable project.

Update WMF Operations have contacted me as the influx of several hundred 50MP+ images is causing strain on the servers and some performance issues. I have paused this run until Operations can advise on how to proceed with the batch NYPL maps upload project. --Fæ (talk) 09:32, 21 April 2014 (UTC)

Thank you Fae for helping to make this topic more prominent! Commons not being able to deal correctly with big TIFF files (thumbnailer fails or crash) is a big problem for many users, in particular the Wikipedians in Residence. I have been working for months to increase WMF awareness about this problem. For now, and to my opinion, the most important step forward we should encourage, would be to use the Vipsscaler for TIFF file. Please support the ticket by subscribing and voting for this. 178.196.235.26 10:18, 21 April 2014 (UTC)

I didn't really expect that you would manage to get a member of the Wikimedia Foundation ops team to actually intervene, per Wikipedia:Don't worry about performance. Quite a turn of events, I'd say. TeleComNasSprVen (talk) 10:45, 21 April 2014 (UTC)

No, the general principle remains exactly correct – don't avoid doing something useful because you think it might affect performance. When we hit upon edge cases of legitimate work that cause issues, we notice and we try to find a good way to make it work. That doesn't mean we can't ask to hold fire for a bit while we figure it out though. :-) MPelletier (WMF) (talk) 12:39, 21 April 2014 (UTC)

Just to clarify something, this particular problem (Lots of large tiff files uploaded very quickly causing the image scaling servers to become overloaded [4]) would probably not be particularly solved by vips scaler. At best VIPS could be mildly more efficient, but I doubt it would make a significant difference (Haven't tested). VIPS is mostly about reducing memory usage so we can effectively scale very large (>50MP) files. The issue above is about a more general thumbnailing outage. Personally I think the most obvious solution would be to change GWToolset to upload files a bit more slowly, so we don't DOS our own servers. Bawolff (talk) 22:14, 22 April 2014 (UTC)

p.s. In regards to "A bot to create under-50MP jpeg files from over-50MP sized tiffs would be handy to make these a more usable project." non-progressive Jpeg (progressive jpg's have somewhat unclear limits) and PNG formatted files are exempt from the 50 MP limit, so your "preview" images don't necessarily have to be <50 MP. Bawolff (talk) 22:18, 22 April 2014 (UTC)

Map of the coast of America, John William Norie 1837, additions 1856. Resolution 14,418 × 4,268 pixels (61 megapixels).

Thanks for the tip. As an example, I have recreated the original problematic large file in this thread, converting it from a 176MB tiff to a 15MB jpeg at the same resolution but with thumbnails. When WMF Operations agrees how to proceed and I then finish uploading the NYPL maps, I will consider if we can automate these conversions. --Fæ (talk) 10:47, 24 April 2014 (UTC)

Sorry for being so lazy, but I'd like to know if it's just me or big (non tiff) files have a display issue in Chrome? For instance, if I try to view the original of files like this, I still only get the 1280px version - clicking on it doesn't enlarge it, and I get the same result when logged out, while everything works as expected in FF, Opera and IE. --188.217.208.60 12:53, 25 April 2014 (UTC) (Elitre)

As those images are publicly available in their full glory by reliable institutions, it is not necessary to upload them in all their largesse onto Commons. A reduced version would do for Scope and EDUse of WP. OAlexander (talk) 03:39, 26 April 2014 (UTC)

One of the problems of tiffs is that there were several methods used over the years to provide lossless compression. As a result, we often don't use compression in tiffs because we're not sure that a compressed tiff is readable by everyone. I've just looked at the file that Fae mentions first and it's an uncompressed tiff at 176 MB. Simply re-saving it as PNG (which uses lossless compression) cuts the file size to 91 MB. A jpg would obviously be a lot smaller, but jpg compression is always lossy and jpgs are inherently unsuited for images which have sharp edges (they work best on images that have continuous tone). Maps generally don't need 64K colours, however, so if you want more compression, you would be better off losing some colour information than losing the spatial information in a jpg. A 256-colour palleted png retains sharp edges, has no jpg artifacts, and has enough colours to be visually indistinguishable from the original map. In this case, the file size is only 25 MB, so I would suggest that would be a possible solution for these large maps. PS: @178.196.235.26 - you might want to contact me about Bugzilla. --RexxS (talk) 09:19, 27 April 2014 (UTC)

Using PNG is an interesting option and these could be created automatically. I would disagree on losing colour information if the PNG were the only file we had available on Commons. In the case of the historic maps (some dating to the 15th Century), there is damage such as foxing or other damage. Having the original colours as scanned, makes it much more likely that damage can be distinguished from original inks and textures if someone were to work on an image restoration.

Personally, I like the ideas raised in prior discussion that a "file object" might have several "instances" on Commons in addition to thumbnails. This would make it possible to handle a set such as (tiff, jpg, png, svg) as one object for categorization or even image page text. Funky sort of thought to improve end user experience, isn't it? --Fæ (talk) 09:47, 27 April 2014 (UTC)

If the file already has too many megapixels, we can't just create PNGs automatically. It is the thumbnailer that cannot accept images greater than 50 Megapixels. And I disagree emphatically that we do not want to host the largest image we can, even if we can't display it. The fact that other public projects outside of Wikimedia host the files is irrelevant. The Scope of commons is all freely licensed or public domain media. We have no way of knowing if these other sites will continue to host the files. For example, the U.S. Census website has taken down a lot of their maps.

I do agree that it would be nice to change how we think of files, and instead work via image, having multiple filetypes all linked together. Even better would be if those could be automatically generated. Of course, that won't help us with files over 50 MP. At least, not until the servers get better. Trlkly (talk) 06:53, 30 April 2014 (UTC)

Visualization of backlog ( tiff -> jpg )

To get an idea of the current tiffs that would benefit from having jpegs created from them, I have generated a visualization report at Category_talk:NYPL_maps_(over_50_megapixels)#Dashboard_report. Hopefully it will encourage some volunteers to have a crack at a few interesting ones. --Fæ (talk) 14:46, 28 April 2014 (UTC)

There's a tag for this sort of thing that will put the files in the proper cleanup category: {{Provide thumbnail version}}. It's so old, though, that I'm having to update it so that the new upper limit is 50 megapixels instead of 25, our old limit.

Anyways, it would probably be a good idea to somehow automatically tag such images. I thought I'd already gotten them all. Trlkly (talk) 06:31, 30 April 2014 (UTC)

One more thing: there may technically be no upper size limits on baseline JPEGs or PNGs, but I've definitely run into problems where baseline JPEGs would not scale to some higher resolutions--the same error you get with progressive JPEGs (137). Sure, I could get bigger than with the progressive JPEG version, but I still couldn't pick just any size. (See here for example). I think it's still a good idea to keep any PNG or JPEG copies of TIFFs or GIFs be under 50 megapixels. We can always update them later from the original if the software gets better. --Trlkly (talk) 07:10, 30 April 2014 (UTC)

Unfortunately there are no established guidelines. Some administrators are deleting jpg files on the basis that they 'duplicate' tiffs, presumably not appreciating the issues that tiffs have when transcluded into Wikipedia articles and so forth. As an example, File:Mademoiselle de Beaumont or The Chevalier D'Eon LCCN2006685290.jpg was deleted today (deletion log) and replaced with a redirect to the tiff by Indeedous; without any notification or discussion. It is not possible for me to keep a proper track of these sorts of inconsistent changes to batch uploads I have worked on, when I am not notified.

It would be rather stupid of me to waste the time of other volunteers by encouraging them to create jpgs from tiffs, when administrators are "housekeeping" by then later deleting these same files. --Fæ (talk) 08:21, 30 April 2014 (UTC)

First off, this isn't the same thing as your example. These TIFFs literally can't be displayed. I think even the least informed admins would recognize that it's okay to have a JPEG version of the TIFF doesn't display. And the tags you are supposed to use specifically spells out the reasons.

Second, we do actually have policy in this area. A deletion without a deletion request is a speedy deletion, which means it has to fit one of the speedy deletion criteria. The only one that fits is File:#8, which allows for deletion of "exact or scaled down duplicates." However, Commons:Deletion policy#Duplicates specifically states that a duplicate must be in the same file format. Hence, any speedy deletions of JPEG thumbnails of TIFFs are against policy, and should be filed for undeletion. I have done so here. --Trlkly (talk) 05:52, 1 May 2014 (UTC)

To be honest I simply wasn't aware of that issue. Someone tagged it as duplicate and it had in fact the same content, so I deleted it. Usually I check the file type and that's why I already removed duplicate-tags of several file like that, but obviously I didn't do that here. I'll be more careful in the future. --Indeedous (talk) 16:49, 4 May 2014 (UTC)

User:Flickr upload bot currently down

http://toolserver.org/~bryan/flickr/upload gives a 504 error. Toolserver reports everything working. Nowhere obvious for me to check the status of FlickrUploadBot or to get an ETA on the fix(or even if there is one given toolserver's upcoming death). The bot author is no longer active and hasn't been for years. I'm a fan of flickr2commons but I need a tool that can bypass warnings. No idea why Commons:Upload Wizard/Flickr is still limited to users who jump through hoops. - hahnchen 00:26, 26 April 2014 (UTC)

It's up again, it was down for about 30 hours. No notification anywhere that I could find. - hahnchen 12:59, 26 April 2014 (UTC)

Bot needs a serious update anyway but I wouldn't cry if it dies with the Toolserver, too many problems with it due to lack of maintenance/maintainer. Far too many duplicate and blacklisted uploads from this bot. --Denniss (talk) 11:50, 27 April 2014 (UTC)

Doesn't http://tools.wmflabs.org/flickr2commons/ provide similar functionality? Maybe I'm wrong, haven't tried them... --AKlapper (WMF) (talk) 04:21, 28 April 2014 (UTC)

It does, and it is a useful tool. But flickr2commons does not allow files to be uploaded if there are warnings. Wikimedia projects rely on tools and bots, but there needs to be an official adoption process so when maintainers/operators drop out, their support and usage can continue. You have the same issue on Wikipedia too, where the discontinuation of w:User:WebCiteBOT caused a significant increase in dead links. In this case, there actually is an officially supported alternative, Commons:Upload Wizard/Flickr, but users are not deemed trustworthy enough to use it. Why? - hahnchen 12:17, 28 April 2014 (UTC)

hahnchen, it doesn't make sense, you're right and i have written almost the same at Commons:Requests for comment/Allow transferring files from other Wikimedia Wikis server side#Flickr upload tools and user rights (Commons:Upload Wizard/Flickr: "The Upload Wizard can upload flies directly from Flickr. This featured was deployed on Wikimedia Commons in December 2012, accessible to administrators and image-reviewers only for the testing phase." So, i can't use this. To become an "Image-reviewer", i would need to request this right and be approved. I'm not a newbie and i was given "autopatrol" rights last year. Very few users can use Upload Wizard/Flickr, there are only 203 Commons reviewers total, but currently 3,484 autopatrollers that can't.). In the discussion there is general support for enabling Upload Wizard/Flickr for everybody, but this will need a RfC. Would you please make a proposal? --Atlasowa (talk) 19:26, 4 May 2014 (UTC)

Cliché Conrat

Does anyone know what the meaning of "Cliché Conrad" in the picture is? Smiley.toerist (talk) 12:02, 29 April 2014 (UTC)

They were the publisher of the postcard series. You can find many matches under this publisher name on old postcard sales. --Fæ (talk) 12:09, 29 April 2014 (UTC)

I agree with Fae, I vaguely recall running across "Cliché Conrat" before (with a "t", not "d" at the end). If I remember correctly they published post cards in Paris around the turn of the century. In this context "Cliché" means "Photo" or "Print", not "Trite expression". "Conrat" is a surname. —RP88 12:19, 29 April 2014 (UTC)

Actually, it is "Conrat" in this example image, this was probably a typo by Smiley. --Fæ (talk) 13:11, 29 April 2014 (UTC)

It means that the photograph is by Conrat. He could be the E. Conrat who had his atelier in Charenton [5]. It would make sense, as it is in the same general area as Alfortville. -- Asclepias (talk) 16:37, 29 April 2014 (UTC)

Is there any list of old photografers? On Google I get some pictures but no personal details, as when he died. As there are only pictures before WW I, I suspect he died during the war. Smiley.toerist (talk) 18:39, 30 April 2014 (UTC)

There are dictionaries. Some are partly online. I've looked around the net for something about Conrat. Reproductions of some of his photos can be found but I didn't find anything about his biography. He is not listed in the Wikibooks page either or in the Wikipédia list. I suppose he did not become famous enough to make it into books. -- Asclepias (talk) 06:43, 1 May 2014 (UTC)

I didn't find any life dates either. However, I would presume that he might have died even before WWI. See for instance this "carte de visite": on the back, it says "Photographe d'Art Anthony's" and "E. Conrat succ^r." ("successeur"/"successor"). So by the time that photo was made, someone else had already taken over the business from E. Conrat and kept operating using his name. Lupo 07:10, 1 May 2014 (UTC)

OK, I put the PD-old-70 licence tag on. Maybe the French wikipedia wil someday write a biography. There arent enough pictures (one) to make a category in the Commons. Smiley.toerist (talk) 09:18, 1 May 2014 (UTC)

Munier

I got another postcard of Menton (France)(posted 1939) with the mention: photo Munier. It is not the animal photografer Vincent Munier. He was born much later. Unfortunately this Vincent messes up the search on Google and other sources. I could upload the postcard but it is quite likely to be deleted. Smiley.toerist (talk) 12:59, 4 May 2014 (UTC)

I found a similar one: Ebay Smiley.toerist (talk) 13:31, 4 May 2014 (UTC)

And the question is...? Most probably you mean the postcard publisher Munier from Nice, France. Business active in the 1920s up to the 1950s, maybe later. Also called "Editions d'Art Munier", later apparently also "Rostan & Munier" (same address, 19 Rue Marceau, Nice). In the 1930s, if the date given in this ebay auction is correct, "Montluet, suc^r".[6] In any case, this doesn't tell you for sure who the photographer was. Nor would I rely on ebay for dating things. With postcards that recent it's also somewhat unlikely that the photographer has been dead for more than 70 years, so I wouldn't upload them here. Lupo 13:36, 4 May 2014 (UTC)

Indeed it would be the guy from "les éditions d'art Munier" and "Munier, photographe et éditeur d'art". Apparently, at some point he worked with an associate in "Rostan et Munier" [7] or "les éditions d'art Rostan & Munier", sometimes identified "RM". Many photos by Rostan et Munier are found on the web and the museums of France have some of them in their collections [8]. And various successors continued the business, for example this postcard with the mention of "Le Voyer" on the back. For photos attributed specifically to "Munier" himself, the problem is to find biographic information about him. Some of the photos published under the name Munier and found on the web look quite old. A collection of 24 photos were published by Munier in an apparently undated book. Copies are available from various resellers on the web (example [9]), who guess various publishing dates. If someone is motivated to continue the research, they might find more information. There is a reasonable chance that his photos, or some of them, might have been published before 1923 and that he might have died before 1944. One user uploaded one photo by Munier to Commons File:Beaulieu.Mer-CP-anté20-32.jpg, although he did not have the information. -- Asclepias (talk) 15:16, 4 May 2014 (UTC)

De reason I ask is to check if it is a big publisher like Nels or L.L. who use a lot of local anonymous photografers, or personal work as photografer. The Nels postcards can be treated as anonymous EU, but in this case it looks as personal work and the deceased date has to found. Anyway as the 70 year period is extended in France, because of the war,(an extra 8 years?) even if he died in 1939 we could not publish it.Smiley.toerist (talk) 19:14, 4 May 2014 (UTC)

@Smiley.toerist: FYI, there isn't any more any war extension in French copyright law. Now it is straight 70 years pma, except for people who died in war for the country. Regards, Yann (talk) 19:28, 4 May 2014 (UTC)

Major rename categories work

In the Valenciennes region the tramlines A and B have been renamed tramline 1 and 2 respectively. The Commons has to follow the rename in the real world. (:Category:Valenciennes tram line A ==> :Category:Valenciennes tram line 1) and (:Category:Valenciennes tram line B ==> :Category:Valenciennes tram line 2). However there are many subcategories also with (ligne B) or line A in the name). I estimate at least 17 of these subcategories. Can someone do these renames? It is better to do these renames together than to put 18 rename tags on the categories. Afterward they can be added to the (Trams on route 1) and (Trams on route 2) categories.Smiley.toerist (talk) 09:46, 4 May 2014 (UTC)

Wouldn't it be better to create the new categories and redirect the existing ones? Green Giant supports NonFreeWiki (talk) 10:36, 4 May 2014 (UTC)

Mostly done by Cat-a-lot and category redirects. Some of the files might need renaming but I don't think its helpful to flood the requests category. Maybe there is a kind-hearted file-mover who won't mind spending a couple of hours on a mundane task? Green Giant supports NonFreeWiki (talk) 15:29, 4 May 2014 (UTC)

Not really necessary as at the time the pictures where taken they were the lines A and B. People looking for tram pictures wil find them. I still have a lot of work to do in making and filling the local tram/commune categories to make an local search posible. Another problem is transport area "Transville". I created: (Trams in the Valenciennes region). The transport area is within the Arrondissement de Valenciennes (created a new category), but not all of it. For details see fr:Transvilles. Maybe create a category "Transvilles area", but I am not happy to create extra levels. With regions, departments and communes, we have enough levels in France. There are also arrondissements and cantons administratieve levels between the departements and the communes.Smiley.toerist (talk) 19:39, 4 May 2014 (UTC)

Your comment about most of the transport area being in Valenciennes reminded me of a long-running and interminable debate about w:Paris aire urbaine and whether it was the same thing as w:Paris metropolitan area (to which it redirects now). Amyway I digress, but I think there is a justification for as many categories as are necessary as long as each category has enough images. I'm not sure if there is a specific policy on the minimum number of items in a category but I believe having at least 3 images would justify a need for a category. Green Giant supports NonFreeWiki (talk) 13:00, 5 May 2014 (UTC)

Categorizing signs by county when taking county border signs

There are "Signs in" 'county name', Georgia counties for every county in Georgia that has a sign. My question is when categorizing a sign like File:Clay Couty limit, Bluffton Rd WB.JPG, it is a county border sign of Clay County, Georgia. The sign is on the border of Clay County and Calhoun County. Should I put the photo in the Category:Signs in Clay County, Georgia and Category:Signs in Calhoun County, Georgia? In the same respect, this photo File:GA-FL state line Brooks-Madison north01.jpg has been placed in the categories Category:Signs in Brooks County, Georgia and Category:Signs in Madison County, Florida I supposed because it is on the border of Brooks County, Georgia and Madison County, Florida. Just want to see what people's thoughts are when categorizing county border signs. --Mjrmtg (talk) 14:13, 4 May 2014 (UTC)

In Scottish categories I have been putting them in both, on the basis that if an object is so close to the boundary that it's difficult to establish precise location, it's unhelpful to try and choose one or the other. Rodhullandemu (talk) 15:01, 4 May 2014 (UTC)

I agree with RH&E, put them in two categories if they are on the border between two counties. Green Giant supports NonFreeWiki (talk) 15:07, 4 May 2014 (UTC)

Thanks, I will put them in both :) --Mjrmtg (talk) 12:06, 5 May 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Green Giant supports NonFreeWiki (talk) 12:44, 5 May 2014 (UTC)

May 05

Revision or creating source templates - open query

I've been trying to find information regarding the best policy to follow for an issue I'm having with source templates but I've really come across anything that clarifies things for me. I'm working to upload a series of batch uploads from the National Library of Scotland, and one of the things I'd like to do is improve the source template Template:NLS Collections. It seems to me to be an effective but skeletal template, and I would like to add additional or more specific parameters like the shelfmark and manuscript shelfmark. I was also looking to revise the visual appearance of the template so that it would be more in line with other major national library source templates like Template:NYPL-image-DigitalID or Template:British Library image. I'm not really familiar with creating or editing templates, so I was wondering if anyone had any advise on the benefits or, more importantly, risks of making changes to this template. Is there a way of changing the existing template without screwing up the images currently using it? I don't want to create a new template at the risk of needless duplication. Any advice greatly appreciated! Thanks, ACrockford (talk) 12:10, 5 May 2014 (UTC)

Images

Can new images be sent under old other name? Is there viki rule not to send new images over old ones, or that is ok? Can someone tell me? Or show me rules about that? --Anastan (talk) 22:14, 5 May 2014 (UTC)

The relevant guideline is COM:OVERWRITE. You shouldn't upload completely new files over old files, but you can do so for minor improvements of the old file. When in doubt, don't overwrite. The guideline will tell you more details. darkweasel94 22:24, 5 May 2014 (UTC)

This was the thing i was looking for, thank you so much! I now have rules to stop the problems, thank you --Anastan (talk) 22:39, 5 May 2014 (UTC)

21 million

We’re past the 21 million mark, and this time it went by unnoticed here. Anyone kept track in detail to know which were the 21sth millionth upload(s)? -- Tuválkin ✉ 22:52, 5 May 2014 (UTC)

May 06

Policy against generic file names

A cookie. Easy to find under the name "Cookie.jpg"

There appears to be an active norm applied by administrators that "generic" file names like

should be protected and remain unused. This, of course, was once not common practice on this project. Do folks feel we need to have a proposal discussion, or is there sufficient logical justification to avoid having a policy or guideline either for protecting filenames like this, or against it if there are no other circumstances (like being a long term spam or vandal magnet)? See reference case. --Fæ (talk) 11:53, 29 April 2014 (UTC)

If such kind of filenames are allowed, the files will rather often be inadvertently overwritten by unexperienced users who also want ot upload a shot of their dog, cat or whatever. This results in confusion (or anger) at the projects where the "original" image was/is in use and produces unnecessary workload for admins and/or recent-upload patrolers on Commons. --Túrelio (talk) 12:12, 29 April 2014 (UTC)

If this is the only reason, then it would make more sense to make file overwriting restricted to users with accounts flagged to allow it (perhaps based on having more than 10 uploads or similar), rather than protecting haphazardly selected names from ever being created. --Fæ (talk) 12:15, 29 April 2014 (UTC)

I mentioned only the reason which immediately came to my mind, as in the past I had often to deal with such problems. Besides, I don't really understand why you would see a problem in protecting generic terms. Using for example Dog_0815.jpg is allowed and wouldn't be a problem. --Túrelio (talk) 12:21, 29 April 2014 (UTC)

Files should have better names. A "cat.jpg" is probably a poor image, not the one you would choose when wanting an image of a cat (as the one who takes a good image has though about the shooting enough to provide more information). Thus I think there is no harm protecting, blacklisting, whatever. --LPfi (talk) 16:59, 29 April 2014 (UTC)

Overwriting is restricted to autoconfirmed users, but that doesn't seem to be enough on its own. Commons:File naming states that "Titles of media files should be meaningful and helpful in the language chosen". "Child" is obviously not meaningful or useful, because it tells us next to nothing about the contents of the file. Is it a drawing or a photo? Is the child two months old or 14 years old? Male or female? Playing/working/sleeping/posing/eating/throwing a temper tantrum? I don't think we need a dedicated policy for every "don't do stupid stuff" scenario imaginable, but if you want to add a line to Commons:Protection policy about it, go ahead. —LX (talk, contribs) 18:20, 29 April 2014 (UTC)

The current contents of File:Goat.jpg were overwritten a long time ago and remained that way till recently. While I’m not sure that banning/reserving these “simple” filenames is a good idea, nor a needed practice/policy, I’m sure that file overwriting should be allowed only from trusted users — if autoconfimed is not enough, then above. -- Tuválkin ✉ 16:25, 30 April 2014 (UTC)

File:Buff.jpg just showed up on my watchlist; this is apparently the third time that a file under that name has been created, and I suspect its contents show something completely different then last time. Maybe File:Goat.jpg or File:Cookie.jpg aren't that bad, but some of these are unconditionally bad names and could use being blocked.--Prosfilaes (talk) 19:16, 30 April 2014 (UTC)

From the discussion so far here, I think that how these norms apply to the administrative use of protection (or 'salting') is vague and highly likely to be inconsistent and a potential source of contention between users and admins, particularly new users. If there is no strong feeling against it, then LX's suggestion of adding a minor clarification to Commons:Protection policy seems the best way forward. I'm pretty busy this week, but if nobody else gets on with this, I'll think about a proposal on the policy talk page next week-ish.

--Fæ (talk) 19:26, 30 April 2014 (UTC)

A special protecting policy would be certainly haphazard. The file name should be appropriate but it should not stand in an exhaustive garrulous description of the file. Every file name is "generic", less or more. An adequate protection is that when any file name is occupied, it cann't be used again for another file. I cann't imagine some hard rule which would able to distinguish "generic" file names from "non-generic" file names strictly. However, I'm well disposed to extend the #2 reason of Commons:File renaming from "completely meaningless names" to "extremely generic names" also, if we will able to specify some universal gauge (or to trust filemover's good sense). The conciseness of the file name is not less important than its appositeness. --ŠJů (talk) 16:53, 1 May 2014 (UTC)

File names such as (First name of a celebrity).jpg are great honeypots. Once added to my watchlist, it is a matter of seconds to delete a copyvio reupload. Blocking those file names would demand active searching in all recent uploads. --McZusatz (talk) 16:15, 6 May 2014 (UTC)

hotcat broken?

For some reason my hotcat stopped working, i.e. the options all disappeared. Is it broken for anyone else at the moment? Regards, Dainomite (talk) 04:37, 6 May 2014 (UTC)

No, looks fine for me, and apparently also for other people; at least I see people using it in Special:RecentChanges, e.g. [10] or [11]. Lupo 04:49, 6 May 2014 (UTC)

Arg, I wonder what happened that it stopped working for me. >:| Dainomite (talk) 04:50, 6 May 2014 (UTC)

Welp... fixed it by unchecking the hotcat box in preferences, clearing my cache, re-enabling hotcat in my preferences and then clearing my cache again just for good measure. Dainomite (talk) 04:56, 6 May 2014 (UTC)

If you are not worried about hacking and stuff, use commons in the http format (uncheck the secure connection option in preferences) as the https format usually affects external scripts...--Stemoc (talk) 05:03, 6 May 2014 (UTC)

Huh? Never heard of that. Besides, HotCat is not an "external script". It is served also from the Commons. Lupo 05:22, 6 May 2014 (UTC)

If that happens again (for anyone) go to MediaWiki:Gadget-HotCat.js and force your browser to reload it. --Denniss (talk) 06:24, 6 May 2014 (UTC)

Yes Lupo, but in the beginning it was, it became a gadget recently, i have had problems similar to what Dainomite mentioned, plus there are many other tools that run externally (wmflabs) and it could interfere with different gadgets on wikis..--Stemoc (talk) 08:13, 6 May 2014 (UTC)

Thank you, if it happens again I'll just do that. Dainomite (talk) 08:59, 6 May 2014 (UTC)

Pictures of products

Say I take a picture of a Coke bottle. Can I upload it? Thanks, Bananasoldier (talk) 20:55, 6 May 2014 (UTC)

Barring the question whether we need more pictures of coke bottles, it's OK for regular bottles. The logotype is out of copyright and probably not copyrightable in any case, the bottle is utilitarian design. With more intricate designs on the label, it gets more complicated. These might be beyond the threshold of originality and thus not OK. Compare Commons:Deletion requests/Image:Coca-Cola Vanilla Zero US label.jpg, Commons:Deletion requests/Coca-Cola bottles, Commons:Deletion requests/File:Bottles ofCoca-Cola.jpg. --rimshot^talk 21:15, 6 May 2014 (UTC)

Document's frame is sandboxed

Hello,

I am getting errors in browser's javascript console when I want to submit a form (for example on edit or preferences pages):

Blocked script execution in 'https://commons.wikimedia.org/wiki/Special:Preferences' because the document's frame is sandboxed and the 'allow-scripts' permission is not set. Special:Preferences:1
Blocked form submission to 'https://commons.wikimedia.org/wiki/Special:Preferences' because the form's frame is sandboxed and the 'allow-forms' permission is not set. Special:Preferences:1

Of course, the form is not submitted then. I am using Google Chrome 34.0.1847.131 (Official Build 265687) m. The error does not appear always. When I open the page in a new tab, it can but needn't appear.

Why this happens? Miraceti (talk) 21:43, 6 May 2014 (UTC)

I created a bug report. Miraceti (talk) 08:01, 7 May 2014 (UTC)

en interwiki prefix is broken (or maybe just hungry)

The en interwiki prefix is broken and it's eating my links.

Either it's broken or hungry--I think it's broken.

I've documented the problem here: User:CmdrDan/Interwiki_Link_Problem

Is there anything else I can do; is there another way for me to help? --CmdrDan (talk) 22:23, 6 May 2014 (UTC)

[[en:foo]] creates an interlanguage link in the "In Wikipedia" section of the sidebar. [[:en:foo]] creates an inline link to the English-language Wikipedia. That is the case for all language codes, on most Wikimedia projects including Commons. (I think the colon isn't needed on Meta, but that's an exception, not the rule.) darkweasel94 22:30, 6 May 2014 (UTC)

Please have a look @ this page, then you'll see the problem.

I'm confused about the "interlanguage links" as you can see this is an interwiki link and this is just plain busted as these nothing between the two words "busted" and "as"; right?--CmdrDan (talk) 22:48, 6 May 2014 (UTC)

Please see m:Help:Interwiki linking. "en", "de", fr", etc., are language codes that locate interlanguage links in the section of the page meant for the interlanguage links. Somewhat like "category" locates a category link in the section of the page meant for the category links. "w" and "wikipedia" are prefixes that are not language codes. You can use an interlanguage link or a category link and change its basic function and make it work like a simple in-text link instead, but then you tell mediawiki that's what you want by prefixing the language code with a colon. -- Asclepias (talk) 23:05, 6 May 2014 (UTC)

Please have a look @ the interwiki table for Commons (and don't forget to click on the Show legend button on the top of the page) and you'll see that there are three prefixes for "//en.wikipedia.org/wiki/$1", they are:

en
w
wikipedia

Then look @ the page on which I've documented the problem--and on which you'll see a lot of the above is repeated.

--CmdrDan (talk) 23:35, 6 May 2014 (UTC)

Please read the above answers and the help page linked. When you create an interlanguage link with a language code, it will behave like an interlanguage link, exactly as it is supposed to behave. Unless you tell the software to modify its behaviour by prefixing the language code with a colon. In your subpage, the interlanguage link you created did not "fail to appear", as you say. It does appear exactly where you sent it, in the interlanguage links section. -- Asclepias (talk) 23:58, 6 May 2014 (UTC)

I am sorry. You have a point.

I see the English link to w:National City Bank Building on User:CmdrDan/Interwiki_Link_Problem, but:

Why is there only one link in the sidebar?
Shouldn't there be one for each such interwiki or interlanguage link in the article?

There are 11, but four are between <nowiki></nowiki> tags; why is only the first of the 7 in the sidebar?

[[en:National City Bank Building|National City Bank Building]]
[[en:55 Wall Street|55 Wall Street]]
[[en:Isaiah Rogers|Isaiah Rogers]]
''[[en:AIA Guide to New York City|AIA Guide to NYC]]''
''[[en:AIA Guide to New York City|AIA Guide to NYC]]''
[[en:AIA Guide to New York City|AIA Guide to NYC]]
''[[en:AIA_Guide_to_New_York_City|AIA Guide to NYC]]''

Things are even more interesting, with the above list, when I omit the <nowiki></nowiki> tags:

'
'
'

What's with the errant 's?

Finally, is there an inconsistency, conflict, or error, with the Interwiki table links?

I mean, are you saying that all the two letter prefixes on Interwiki table are really interwikilanguage links?

The Interwiki map article on meta, here are three links to that page--each uses one of the three prefixes listed on Special:Interwiki for: //meta.wikimedia.org/wiki/$1

m:Interwiki_map

meta:Interwiki_map

metawikipedia:Interwiki_map

says to check the Special:Interwiki page for the current state of the "Interwiki data [table]"

It also says,

"[prefixes] should avoid likely conflict with languages (en:, fr:, etc)"

perhaps that is the cause of my confusion, but not the source of technical failures.

--CmdrDan (talk) 01:37, 7 May 2014 (UTC)

[[en: is a page-level interwiki link, intended for the sidebar. There should not be more than one (for each interwiki prefix). If you give it more than one, MediaWiki tries to work around you and just displays only one of them. This is by design. It is working fine. Andy Dingley (talk) 02:20, 7 May 2014 (UTC)

There's only one link in the sidebar because there's supposed to be only one version of the same article (or corresponding page) per language, and only one interlanguage link per language to link to that version. In principle, an article (or page) has no more than one version in each language. You can use interlanguage links to link to the version of the article (or page) in each language. In a page, you can place in the sidebar one interlanguage link to the corresponding "en" page, one link to the corresponding "fr" page, one link to the corresponding "de" page, etc. You're not supposed to put multiple interlanguage links to "en". As with any tool, if one misuses the interlanguage tool by giving it conflicting commands, the software has to resolve it somehow. In this case, apparently, it resolves it by accepting the interlanguage link to "en" that comes first on the page and it ignores the conflicting links that follow.
The errant apostrophe marks in your lines are unrelated to the interlanguage links. As mentioned, the superfluous interlanguage links to the same language, after the first link, are ignored. You would have obtained the same effect if you had written lines with just four apostrophe marks like this ::::#''''. Under the conventions of the wiki syntax, your string consisting of four successive apostrophe marks is interpreted as a single textual apostrophe followed by a bolding command. If you had typed some text after it, it would have been in bold.
In general, yes, two-letter prefixes are language codes. I don't know if there might be a few exceptions to that or not. Language codes used as prefixes in wikilinks create interlanguage links (unless a colon is added as a first character to disable their basic interlanguage function and transform them into plain intersite links) . By contrast, prefixes such as "m", "meta", "w", are not language codes, they are codes attributed to websites and when used in wikilinks they create plain intersite links.
It was a good idea you had to do all your experiments with the wikisyntax on one of your subpages. I don't think it's such a good idea to do experiments here, on this page, or in any community page. It has not seemed to mess with the format and the genuine interlanguage links of the village pump, so far, but it would probably be better not to leave actual wrong wikisyntax in this page.
Questions about how to use wikisyntax should probably be asked on Commons:Help desk. -- Asclepias (talk) 04:08, 7 May 2014 (UTC)

May 07

New Video Template for metadata

The audiovisual-archive where I work would like to donate more video to commons (we are the providers of Category: Media From Open Beelden and other sets) using the GW toolset. However the template:information we have been using so far doesn't allow a lot of our meta-data to land properly. The creation of a video template (much like the template:artwork) would help us and other providers of video a lot. However, the template:video already exists as a template to add tags and descriptions. I have come up with the following meta-data fields that would suit our needs:

|creator          		 
|contributor		
|title               	
|description    		
|language	
|date              		
|medium        	
|institution     	
|place of creation  
|notes              
|permission     	
|attribution	 
|source             
|accession number

I have three questions: with the video template that already exists, what would be a good way to move forward with the creation of this template? Do you have any feedback on the chosen meta-data fields? If you have any suggestions of who could help set up this somewhat more complex template that would also be much appreciated. Cheers! 85jesse (talk) 07:34, 28 April 2014 (UTC)

Hello 85jesse, these are good questions and i don't think i can answer them :-)

template:video is used very little and could be put to better use. Template:Artwork looks like a good example, take a closer look at Commons:Machine-readable data too.

Maybe you should talk to User:Prolineserver, he is building a tool for video upload and conversion (tools.wmflabs.org/videoconvert), so he might be pondering similar questions, i imagine ;-).

HTH --Atlasowa (talk) 20:44, 4 May 2014 (UTC)

Thank you Atlasowa, that's very helpful. For now we have created a custom template for our video-upload Template:OBvideo based on the artwork template. There are only some minor changes to the artwork template but I still think it is helpful because the template-name 'artwork' suggests that we are talking about an artwork, which for most video is not the case. In my opinion it could still be a good idea to add this template as a standard template. I'll see what User:Prolineserver has to say! 85jesse (talk) 07:14, 6 May 2014 (UTC)

Hello 85jesse, have a look at this too: [12][13] and mw:Multimedia/Media Viewer/Template compatibility. HTH --Atlasowa (talk) 14:16, 7 May 2014 (UTC)

File download weirdness for large files

I have been regularly downloading very large tiffs (50MB+, sometimes 100MB+) to losslessly crop/rotate and fix problems in Photoshop. I have been experiencing a consistent a minor bug as on a first try the downloaded files give me a bad end of file error (presumably the download terminated early) but on the second try they always are downloaded correctly and are editable in Photoshop without any problem. An example is this 85MB image which I have downloaded just now to remove a problem colour profile.

Any thoughts on what this problem is, or if there is a related bug request outstanding? --Fæ (talk) 12:07, 3 May 2014 (UTC)

Likely interesting information (although I have no idea about the bug) would be the browser used, whether it also happens with other browsers, and also whether it also happens with software like wget and curl. darkweasel94 13:35, 3 May 2014 (UTC)

This was on Firefox v16 running on OSX 10.5. I don't have a problem downloading other stuff from other places. --Fæ (talk) 17:02, 3 May 2014 (UTC)

might be the difference between a cached vs uncached varnish hit. Its not a known issue. File a bug. Bawolff (talk) 08:44, 7 May 2014 (UTC)

May 04

Text-only images which should be replaced with math markup.

I returned to my account to upload further images only to see that everything had been deleted for the above reason.

Problem: I'm not sure what this means. Any input would be appreciated. I'm relatively new at this. — Preceding unsigned comment added by Oncandor (talk • contribs)

Hi! There are two problems with your uploads. First, there seems to be a problem with the content. Please verify that your uploads are within project scope here. The second problem seems to be that you uploaded mathematical or chemical formulas as images. That doesn't make much sense. The better way would be to use TeX markup. Instructions can be found here. Hope it helps. :) --Hedwig in Washington ^(mail?) 04:39, 8 May 2014 (UTC)

May 09

Welcome to Atlantes! Over 10,000 historic maps in research quality resolution

NYPL maps: 3,640^R, NYPL maps (over 50 megapixels): 1,249^R

Project page Commons:Batch uploading/NYPL Maps

Sample gallery:

Americæ, Walteri Raleigh, c.1590
Americæ nova descriptio, Peter Heylyn, 1663
Dogs attacking the black slaves (at Quarequa), 1671
East India, 1681
A new mapp of the world, c.1705
England, Scotland and Ireland, c.1705
World map of trade-winds and monsoons, c.1711
Map of the world, c.1736
Canada (during the French and Indian War), 1761
The British Empire in North America, 1762
Stock Farm in Orange County, 1875
House level map of New York city, area bounded by Fifth Avenue (Central Park West), E. 67th Street, Second Avenue and E. 80th Street, 1897
House level map of the Bronx, area bounded by Park Ave., E. 158th St., Melrose Ave., E. 156th St., 1909
New York street level aerial photograph, 1924

With the help of the GWToolset, over the last couple of weeks I have been uploading maps from NYPL's release earlier in the year (see VP archive). In the collection are maps of all countries, made in many periods. They represent the best available research quality images of these works available anywhere for historians and cartographers. The largest proportion of maps are detailed historic views of the New York area, down to street and house level. In the collection is a low level aerial photographic survey of New York made in 1924, spread over many photographs, this was the Google Maps of its time.

The scans are original archive quality tiffs, many over 100MB in size. This batch was a significant technical challenge, from the beginning needing to be throttled back due to overloading the WMF servers with the exceptional demand it created for rendering very high resolution images.

This impressive collection remains a massive opportunity for experimentation and pushing the boundaries of how to use Commons.

There is continued discussion about what we can do to make use of NYPL's crowd-sourced KML files which enable interesting reuse such as using the historic map as an Open Street Map overlay.
How to present multiple map images in a way that can be 'surfed' on-wiki is a puzzle, particularly as the NYPL has scanned entire books of maps that could now be stitched together.
Some images are literally massive both in resolution and filesize, handling of tiffs of this extreme size and how to associate versions in jpeg or re-compressed png form remains both difficult and slightly controversial. As an example of a tiff too large to be rendered on Commons, this 1779 map of New York is 9,375 × 12,549 pixels (117 megapixels), significantly over the maximum 50 megapixels, though this jpeg version can be viewed on-wiki, and looks like a map of the moon until you use the zoomviewer to examine fine detail and realize that there is tiny lettering showing districts.

More than half of the maps on NYPL's website have been uploaded, the remainder may have been skipped due to the NYPL website migrating to a new display format and not making records available under the old system, along with some possible mime-type mismatches. After investigation, this may result in a second phase of batch uploads to Commons later in the year. Update 11th May: A final run of uploading was paused by WMF Operations due to server stress. However, it is estimated that only a few hundred images remain to be uploaded at this point. Discussion on how best to complete this technically demanding batch project continue.

If you are reusing some of these, making derived versions (crops, details), creating Wikipedia articles about the most notable maps, or have started a related project, don't forget to tell the community about it here. --Fæ (talk) 09:26, 9 May 2014 (UTC)

Thank you for uploading this fantastic set of images, which will feed one of my favourite pastimes - poring over maps. :) Green Giant (talk) 12:59, 9 May 2014 (UTC)

Category:Léon Deschamps

Category:Léon Deschamps is a mix of writer fr:Léon Deschamps and artist fr:Léon Deschamps (artiste). --Havang(nl) (talk) 10:53, 9 May 2014 (UTC)

Cat-a-lot: Cryptic error msg

When I want to move files from one category (the visible one I am working from) to another one, Cat-a-lot refuses to do so with "The following pages were skipped, because the old category could not be found:" — I cannot understand what this message will tell me. What is the old category? Can be nothing than the category just displayed. Cache refresh doesn't help. sarang♥사랑 17:46, 8 May 2014 (UTC)

Now I see: I moved with Cat-a-lot into a category "xxxx (yyy)". This worked well. But when I try to remove from this category I get the error msg. Cat-a-lot seems confused because of the brackets. I am out of my wits what to do now. I am not amused from the imagination to remove more than 170 files with Hotcat, one by one. Has anyone a better idea? sarang♥사랑 11:49, 9 May 2014 (UTC)

@Sarang: If I'm understanding you well, I've never found this error message in such circumstances, and I've worked often with categories with parenthesis in their names. When "The following pages were skipped, because the old category could not be found:" pops up, it means that the requested action can't be done because the category to remove is not there - usually because it has been removed somehow else while the category page was open and not refreshed.

Can you put an example of problematic action and "xxxx (yyy)" category?--Pere prlpz (talk) 12:36, 9 May 2014 (UTC)

Thank you for helping me. I created erroneously the category Electronic shell diagrams (no label) and inserted files. Now want to remove/uncategorize all the files (they are categorized properly in the meantime) and then have the category deleted. sarang♥사랑 12:45, 9 May 2014 (UTC)

Somebody or something removed all the files, and now the category itself is also removed. Thank you everybody! I do not know why it did not work, and I do not know how it is done now; but my problem is solved. sarang♥사랑 14:41, 9 May 2014 (UTC)

[OK] Done with VisualFileChange and custom replaced the category name with nothing. I had the same problem with Cat-a-Lot so it and I don't know what you did to the category but I think you should copy the whole of War and Peace by hand and take it to Jimbo for marking by tomorrow. :P Green Giant (talk) 14:38, 9 May 2014 (UTC)

Thank you, GreenGiant sarang♥사랑 14:41, 9 May 2014 (UTC)

I'm not sure about it, but I think the problem came from some extra invisible characters before category closing brackets. See this apparently null edition that reduces page size by 3 characters, and that allows Cat-a-lot to work in next edition.--Pere prlpz (talk) 15:12, 9 May 2014 (UTC)

What is the proper place for proposing the rename of a file, while unsure if it's the proper course of action for it?

For instance, File:Die Kinder von Kaiser Karl und Kaiserin Zita, Quinta Vigia, Funchal, 1922.jpg cannot possibly be from 1922, and i've changed its description accordingly. But i'm undecided whether it should be renamed to just File:Die Kinder von Kaiser Karl und Kaiserin Zita, Quinta Vigia, Funchal.jpg, or not... It's not really that misleading to be worthy of reason #3 described by Commons:File renaming, and while it's an obvious error (reason #5), i'm suggesting the removal of the date, and not its correction, since i don't know the correct date -- so it isn't fully covered by #5 either... So this is why i'm here, i'd like some feedback on how warranted the move would be; but i don't even know if VP is the proper place for my question. Maybe a RfC would have been better (even though the significance isn't really wide at all IMO)? -- Jokes Free4Me (talk) 18:55, 9 May 2014 (UTC)

In my opinion, this is within the spirit of #5. -- King of ♥ ♦ ♣ ♠ 21:18, 9 May 2014 (UTC)

Removing a wrong date is a correction. I think it's ok if you request the renaming of that file for that treason. -- Asclepias (talk) 21:23, 9 May 2014 (UTC)

Okay then, thanks for the replies. (and for the chuckle i got while reading that last word. ^^). Rename requested. -- Jokes Free4Me (talk) 23:24, 9 May 2014 (UTC)

Oops. -- Asclepias (talk) 00:12, 10 May 2014 (UTC)

While at it, change also "Quinta Vigia" to the correct "Quinta da Vigia". -- Tuválkin ✉ 02:27, 10 May 2014 (UTC)

May 10

Creator:James Maubert: Invisible characters?

I just created "Creator:James Maubert" and added {{Authority control}} to it, but there seem to be some hidden characters at the end of the ISNI which I can't delete (see the URL http://isni-url.oclc.nl/isni/0000000385389838%E2%80%8F). I did a copy-and-paste of the ISNI from the VIAF website. Thus, the template is not linking to the right URL. Any ideas how to get rid of the extraneous characters? — SMUconlaw (talk) 06:07, 6 May 2014 (UTC)

OK, fixed it by retyping the {{Authority control}} template by hand. — SMUconlaw (talk) 07:15, 6 May 2014 (UTC)

Wrote this for a different purpose but you can get rid of them using Commons:User scripts/Invisible charaters. It also tells you what kind of invisible char is causing the trouble and creates an output w/o them. -- Rillke^(q?) 12:49, 10 May 2014 (UTC)

wikEd as gadget on Commons

I have made the MediaWiki editor wikEd compatible with upload pages in addition to edit pages in version 0.9.125. It would be nice to have wikEd as a gadget here. Maybe an admin could set that up (for help see here). Cacycle (talk) 14:59, 6 May 2014 (UTC)

Please suggest on COM:VPP. -- Rillke^(q?) 12:44, 10 May 2014 (UTC)

Pictures of brand-based items?

Say I owned one of these [14] and took a picture of it. Would I be able to upload it for Creative Commons here? Thanks, Bananasoldier (talk) 01:50, 7 May 2014 (UTC)

Hello Bananasoldier and thank you for asking before uploading. The short answer is that it depends entirely on the context. The copyright lies entirely with the person/persons who designed the branding or possibly with the company that owns Capri-Sun. Then there is the "innovation" involved in creating the bag from recycled materials. So overall there are several bits of intellectual property involved before we get to the photographers copyright. The context that I referred to us about whether the bag would be the focus of the photo or just incidentally in the photo e.g. someone in the background happened to have such a bag. If you wish to upload it as a free photo you will need to obtain at least the permission of the copyright holders for the bag and maybe for the brand as well. As an absolute last resort, you could upload a small photo locally to Wikipedia (e.g. the English one) if and only if you can demonstrate that said photo will help readers understand an article. You'd have to ensure the photo met all of the ten criteria at w:WP:NFCC. Cheers. Green Giant (talk) 12:27, 7 May 2014 (UTC)
- I disagree in part with Green Giant, though laws may vary in different countries. In the U.S., any copyright on the bag design would be irrelevant to the photo: it's a functional object, and can be photographed freely without regard to copyright issues. However, I agree with him that the Capri-Sun logos would be a problem. But if you are seeking more expertise on this, I'd suggest asking your question at Commons:Village pump/Copyright instead. - Jmabel ! talk 15:38, 7 May 2014 (UTC)

Ah yes, I should have been clearer about that. Jmabel is correct that the bag design in itself is not a problem and my intention was just to highlight that even everyday objects can have complex rights involved. By "copyright holder for the bag" I was referring to the person who designed the logo, who is not necessarily the same as the brand owner. Green Giant (talk) 20:08, 8 May 2014 (UTC)

Thank you all for replying, but I am still confused. Is it safe to take a picture of this product and upload it to Commons despite that it has Capri Sun logos on it? If I upload it to the English Wikipedia for Non-free content, how would I explain no free media available? Thanks, Bananasoldier (talk) 22:15, 8 May 2014 (UTC)

Sorry for the lack of clarity. You cannot upload a photo of the bag to Commons without explicit permission from the company that owns Capri-Sun. If you contact them and they agree to let you upload the image, they would need to send an email confirming this to permissions-commons@wikimedia.org. Then when you upload the image, the OTRS team can add a special ticket to the file page. If you were to upload it to Wikipedia, the image would need to be used on an article in a relevant way, e.g. an article about recycled products. The argument you could use is that the logos prevent a free photo being created anytime soon but you'd have to show that a photo of that particular bag is essential to help readers understand something in the article. It's not an easy task and you have to bear in mind that the general policy is to limit unfree files to an absolute minimum. Green Giant (talk) 23:09, 8 May 2014 (UTC)

Bananasoldier, the basic question remains, why would you want to upload it? Have you got any more realistic examples of pics you would want to upload? OAlexander (talk) 05:50, 11 May 2014 (UTC)

May 08

Toolserver gadgets

Hi everyone, a lot of Gadgets still link to the Toolserver. Toolserver will be shutting down so these gadgets should either be updated to point to the tool on labs or be removed. Who wants to help? Multichill (talk) 12:01, 10 May 2014 (UTC)

Rotatebot

Rotatebot seems to be broken. Apparently this may be because it is still running from the toolserver. Any likelihood of when it may be fixed? Jheald (talk) 17:30, 10 May 2014 (UTC)

May 11

Meta Data nightmare

Get a load, and it's quite a load, of the Meta data for this image file. Can anyone get rid of this mess, and if so, could you tell us how this is done? -- Gwillhickers (talk) 01:35, 11 May 2014 (UTC)

Done, with "JStrip". Cheers, OAlexander (talk) 02:25, 11 May 2014 (UTC)

PS: Great photography, btw.! OAlexander (talk) 02:44, 11 May 2014 (UTC)

ZoomViewer down - 404 Not Found

Seems, that the ZoomViewer link now points to wmflabs. But it is not working! "404 Not Found" --Alexrk2 (talk) 10:13, 11 May 2014 (UTC)

http://tools.wmflabs.org is down. I get 503 Service Temporarily Unavailable, nginx/1.7.0 and simply no respose. Where do you get 404 for? -- Rillke^(q?) 13:19, 11 May 2014 (UTC)

The flash=no link gives 404 after a while. The normal version gives 503, yes. --Alexrk2 (talk) 13:41, 11 May 2014 (UTC)

Looks like something is wrong with zoomviewer's webservice (curl http://tools-webgrid-02:4008/ => Connection reset by peer) @Dschwen: Could you restart its webservice? --Zhuyifei1999 (talk) 13:56, 11 May 2014 (UTC)

Who pointed the links there? The labs version is not ready yet. --Dschwen (talk) 15:06, 11 May 2014 (UTC)

Oh sorry. I just saw it's up and running yesterday and replaced the link from toolserver. Please take care of the gadget as soon as you finished migration. Thank you. -- Rillke^(q?) 21:43, 11 May 2014 (UTC)

Thanks for being so proactive Rillke :-). I noticed you had also changed the WikiMiniAtlas over in your user location thingie. That one is fully migrated. --Dschwen (talk) 22:25, 11 May 2014 (UTC)

Template translation

Hi. I've been doing some translation on one or two templates over the last couple of days, and something has dawned on me; the templates get translated, but do we translate the documentation on the page too? It's reasonable to expect, at least in my eyes - that if someone is having to use a foreign language interface to commons, they will require to read the documentation for things in the same language. Is that indeed reasonable, or am I missing something? Thoughts. CharlieTheCabbie (talk) 11:07, 11 May 2014 (UTC)

Most templates are documented using Template:TemplateBox which supports translations. --Jarekt (talk) 03:40, 12 May 2014 (UTC)

May 12

Transfer of media files server side: Any WMF project → Wikimedia Commons

Hi everyone. Currently, when transferring media files from projects hosted by the Wikimedia Foundation (WMF), it is either neccessary to download them or to use a tool that does the same on a server. However, MediaWiki (that's the server software that drives Commons and Wikipedia) has a feature called "upload_by_url". This means in this case, the server that Wikimedia Commons is served by would issue a request to the media file's origin (e.g. Wikipedia) directly. It is enabled for Flickr files, for Panoramio and for several other sites. But not for fetching files from sister projects of Wikimedia Commons directly.

Since I believe it should be, I started a Request for Comment. Please join and give your opinion. -- Rillke^(q?) 10:48, 12 May 2014 (UTC)

The Commoner

The Commoner, a weekly newspaper for the Wikimedia Commons community, is being organised. I am looking for people willing to help out with starting the newspaper as well as for ideas about what kind of issues it should cover. (The idea so far is to write about RfAs, RfBs, etc., new FPs, RfCs, project announcements, milestones and software updates.) I am looking forward to seeing your involvement; please do feel very welcome to comment on the talk page, and please do not mind the empty project page for now :-) odder (talk) 11:37, 12 May 2014 (UTC)

Congrats; I appreciate this move. Hope this not just to defend the Signpost. :) J e e 12:16, 12 May 2014 (UTC)

Dethrone more likely :-)) odder (talk) 12:51, 12 May 2014 (UTC)

"RfAs, RfBs, etc., new FPs, RfCs," - these are interesting abbreviations which confirm my status as arrant idiot, or am I just a commoner? OAlexander (talk) 13:11, 12 May 2014 (UTC)

We'll include an "acronym of the week" column in every issue. ;-) --Túrelio (talk) 13:17, 12 May 2014 (UTC)

You are not alone, OAlexander, i am MIA (missed in abbreviations), to. --Maxxl2 - talk 13:26, 12 May 2014 (UTC)

Here's a suggestion...

When I'm uploading an image that I've received permission to post, I know I have to send a message to ORTS. Ok, how?

Google ORTS? Nope.

Search for ORTS here on the Commons? Nope.

On the en.wiki? Nope.

So how the heck is anyone supposed to actually do this?

If you do manage to figure it out (and I'm still trying, again), then someone posts a tag in the article saying it's been checked.

How about this:

When the image has been uploaded with any sort of "i got this from somewhere else" tag, and that tag also implies that permission was given (like CC-by-SA), then the area normally receiving the "I got the ORTS" is replaced by a "you need to file an ORTS", and it has a link you can click to do whatever it is that needs to be done.

That seems like a Very Good Idea, no?

Maury Markowitz (talk) 11:46, 6 May 2014 (UTC)

You're looking for OTRS. (Click the link.) It gives you the e-mail-address to sent the release to in its first paragraphs. Lupo 11:49, 6 May 2014 (UTC)

Which you know, because you've been here before. What is a new user supposed to do? Guess? And if they guess right, search doesn't go to that page. Am I alone as seeing this as a problem? Maury Markowitz (talk) 16:17, 8 May 2014 (UTC)

For me, it's the first search result when I search for OTRS. Lupo 08:59, 9 May 2014 (UTC)

Hm, maybe we should create redirects for Maury's typo "ORTS". I agree that the abbreviation is less than obvious. Lupo 09:01, 9 May 2014 (UTC)

created ORTS. I agree, there is no harm in having redirects at plausible typos. Green Giant (talk) 09:25, 9 May 2014 (UTC)

Ummm, missing the point here…. how is a new user to have even the remotest clue where to send these messages? Maury Markowitz (talk) 17:18, 9 May 2014 (UTC)

A new user who has never heard of it will just upload. But remember that this is a curated image collection (or at least supposed to be one). When somebody notices the image and thinks it needed a release via OTRS to be sent, that person will tag the image and leave a message on the uploader's talk page informing him about it. The message on the uploader's talk page usually includes a link to COM:OTRS and even the e-mail address. We've got a template for that: {{Image permission}}. Then that new user learns about OTRS, knows what to do and follows the instructions, and in the future will know about it. (At least that's the theory.) Lupo 17:42, 9 May 2014 (UTC)

And it doesn't work anyway. Maury Markowitz (talk) 17:27, 9 May 2014 (UTC)

It will work. Just give the search index some time to be updated. Lupo 17:42, 9 May 2014 (UTC)

So now if I know the correct name or one particular mis-spelling of the page, I can find it. But if I don't know the name, or (as will be the default case) don't even know that such a thing exists, what do I do? Is my suggestion really that bad? Maury Markowitz (talk) 11:11, 12 May 2014 (UTC)

I think your suggestion is quite near what Lupo describes above as current praxis (17:42, 9 May). Just tagging the images with {{No permission since}} will give the link (of course actually sending the message to OTRS requires more than clicking, as there is no simple way to verify that a person clicking links is authorized to give permission). --LPfi (talk) 09:48, 13 May 2014 (UTC)

Image scaling alternative techniques survey

Hi everyone,

I'm currently doing research on alternative ways we could generate thumbnails on WMF wikis, particularly on Commons. I've set up a survey for it: https://www.surveymonkey.com/s/F6CGPDJ It would be super helpful if you can spend the couple of minutes needed to complete that survey. Anyone can do it, it's very simple. The survey makes you rate the sharpness and quality of 12 images. Each unique image appears 3 times, but it's slightly different every time it appears (generated using a different technique).

The goal of this research is to see if we can switch to a way to generate thumbnails that would be a lot cheaper in terms of server resources, which would allow thumbnailing to be more stable and less subject to spikes and outages. We'd only implement such a change if we can be certain that the quality of thumbnails isn't degraded in a noticeable way. Hence the survey.

Thanks in advance for your time!--GDubuc (WMF) (talk) 09:34, 9 May 2014 (UTC)

I do not want to follow a link to any survey that tracks my IP address, especially if this might be retained indefinitely or insecurely for undeclared reasons. Does this survey track IPs or not[15] and is it an approved research survey? --Fæ (talk) 14:52, 9 May 2014 (UTC)

Thanks for pointing that out. I've now made sure that the SurveyMonkey IP tracking is turned off: https://www.dropbox.com/s/7q1cvlpzs3gs6c0/Screenshot%202014-05-12%2011.31.32.png Do I need approval (from whom, do you mean WMF legal or Commons admins?) to link to a survey that is entirely optional in a comment of mine? I'm not adding it to any official page, I'm just inviting people to respond, if they want to, to avoid making a technical change that might worsen image quality. I don't have to gather people's feedback for this sort of code change, I'm gathering human input just in case. Seems like a reasonable thing to do, since I know that the Commons userbase cares about image quality.--GDubuc (WMF) (talk) 10:10, 12 May 2014 (UTC)

I'd be more interested to know if we can get larger thumbnails. 300px is the largest we can set as a preference on en:WP even when using high desity monitors (retina displays). Saffron Blaze (talk) 15:08, 9 May 2014 (UTC)

That's an entirely different topic. What I'm working on makes no change in that area, it's purely about how thumbnails are rendered, regardless of size. Thumbnail-related topics are best treated one at a time, imho, previous RFCs that proposed changes in that area met a dead-end because they were trying to change too many things at once.--GDubuc (WMF) (talk) 10:10, 12 May 2014 (UTC)

@GDubuc (WMF): please use either the ImageMagick default, or a Lanczos filter, because anything else will screw up the rendering of line-engravings. At the moment a poor choice of filter is being used on Commons for downsizing images, with the result that many engravings look very much worse than they should do -- very frustrating for users who may have put a lot of time and effort into restoration on the full-size files to try to make them look as good as possible.

Please confirm that your survey is including line-engravings and similar source material that comes with technical challenges to re-size well, and that it is not just considering eye candy. Jheald (talk) 17:28, 10 May 2014 (UTC)

You're welcome to look at the settings currently used, in MediaWiki's Bitmap.php. There are very few options used at the moment, it's pretty close to ImageMagick defaults. Some of the images used in the survey have been picked specifically for their technical challenges (lots of lines). I'm definitely interested in widening the set of sample images to include other known problematic image types. Do you have links to line-engravings that you consider to have sub-par thumbnails at the moment?--GDubuc (WMF) (talk) 10:10, 12 May 2014 (UTC)

@GDubuc (WMF): You say that, but when I raised the issue in this thread a month ago, I was told that the settings were quite different.

Specifically, I was told we were systematically using the -thumbnail option on IM, rather its -resize. The difference this makes can be huge: for example, the spurious 'venetian blind' artefact in the background of the 600px version we serve of this line-engraving:

File:Engraving after Matthew Paris drawing of John of Wallingford (1255).jpg

compared to this version which has been resized with IM's -resize option:

File:Reduced engraving of John of Wallingford, using Image Magick.jpg

Here's an example with vertical Moiré fringe artefacts -- look at the view through the top of the central Gothic arch, or around the drum of the building at the same height, and compare with clicking through, and seeing what a browser like Mozilla does when rendering this image at a reduced size:

File:ONL (1887) 1.151 - Interior of the Temple Church, 1870.jpg

Here's another case with banding artefacts, this time from an engraving by Gustave Doré

File:Don_Quixote_5.jpg

Worse examples could probably be found.

There can also be staircasing on oblique lines, especially if the full-resolution version hasn't been very well anti-aliased. For example, look at 'Crutched Friars' and the streets around it on this sketch-map:

File:DISTRICT(1888) p044 - Mark Lane (map).jpg

None of that staircasing ought to be visible at the reduced resolution.

(Incidentally, the quality of our SVGs can be even worse for this, eg the black curve in File:Scaled chi squared.svg. I don't know if it's in the code of the SVG that's been created by R, or whether it's our rendering of that SVG, but that staircasing is terrible. (Another example). One workaround might be to render at 200%, then resize with ImageMagick. But when we're trying to encourage people to 'go vector' and use SVG, the quality of this output is embarrassing).

I know these glitches might not seem much, but when people put a lot of work into trying to create or clean up images, and we're the shop-window for those images to the world, it's a pity if we aren't rendering or resizing those images absolutely as well as we can. But thanks for getting back to us. Jheald (talk) 11:37, 12 May 2014 (UTC)

Here's another:

File:London bridge viaduct.JPG

Not a great original, but the software is making it look far worse than it needs be. Jheald (talk) 14:37, 12 May 2014 (UTC)

Thanks for those. It's unrelated to my change (I didn't touch the -thumbnail option), but I've confirmed with local testing the artifacts that these test images introduce through the use of -thumbnail. After doing more research I'm pretty sure that the reason -thumbnail is used is simply one of server resources. I did some tests on large TIFFs and -thumbnail can be 6+ times faster. I've heard talks of switching away from ImageMagick to vips scaler anyway, for further performance improvements, so I doubt that the idea of switching to a much slower way of rendering thumbnails would be popular with Ops . That being said, maybe the benefits of my proposed change are big enough that we could afford using -resize. I'll definitely keep that issue in mind when going forward. --GDubuc (WMF) (talk) 12:45, 13 May 2014 (UTC)

Wikimapia photos

Hi, does anyone know how trustable are Wikimapia photos? I know, they are all CC-BY licensed; but I've just noticed mass uploads from there, from which a large sample was low-resolution shots, each detectable on several external copyrighted websites. Given that, I suspect similar problem as Flickr washing; other opinions? Thanks. --A.Savin 23:22, 10 May 2014 (UTC)

its a free site, has been around for a while so its obvious other sites would use images from wikimapia..I'd say, lets give the uploader the benefit of the doubt...--Stemoc (talk) 23:29, 10 May 2014 (UTC)

The tems says "1. F. All User Submissions of all users and all Wikimapia Data are freely available for commercial and non-commercial use under Creative Commons license Attribution-ShareAlike through WikiMapia website, WikiMapia API and other current or future WikiMapia services." (not CC-BY) J e e 05:11, 11 May 2014 (UTC)

Looking at such low-res photos, and then at Google image search thereon, it's hard for me to imagine it as own photographic work by the uploader on Wikimapia. Although we normally should AGF, it is a risk for Commons to allow mass uploads of such dubious stuff. --A.Savin 11:38, 11 May 2014 (UTC)

I have spent a little time setting up a new account on Wikimapia and uploading a photograph of mine to the site. New users are not given guidelines on what copyrighted means, although when uploading there is a warning against uploading copyrighted photos. It was not clear to me, as a new uploader, whether my photograph was being released as CC-BY-SA, PD or whether I retained all the rights. Although the terms exist, as a new account I did not tick any box confirming I accepted the terms and I did not notice during the new user "workflow" that I was advised or provided a link to the terms, but I was advised of the "Wikimapia Guidelines" but these do not link nor reference the terms (from a legal standpoint, this seems a weak process). Neither was it clear to me what happens to photographs I upload and then choose to delete (they appear to be retained indefinitely by Wikimapia). I do not think this is a reliable source for freely reusable photographs on Commons, unless the original photographer makes a credible statement and, preferably, is the same person as the uploader with an associated track record on Wikimapia in the same way as we might consider for Flickrstreams.

Were a photographer to complain about their Wikimapia photographs being uploaded to Commons, I would be inclined to give them the benefit of the doubt that there probably is no documented release of copyright that cannot be fairly challenged as being ambiguous.

(Edit conflict) Update Putting on my "OTRS" hat, I took a closer look at the example file and have now marked it as a copyvio. It was uploaded 8 years ago to Wikimapia by account "Guest". It was a low resolution derivative of a photograph which was taken by "bassem Mohammed alwan" and hosted by Panoramio, currently copyrighted as All Rights Reserved though only uploaded to that site 5 years ago. --Fæ (talk) 15:02, 11 May 2014 (UTC)

That makes it all even more dubious. I'm tending to nominate the whole lot uploaded by Rakoon for deletion. Just for the record, I find Wikimapia otherwise an extremely useful project and for myself I very often use it for identification of buildings etc. for descriptions of my photos. But as a source of freely licensed material, it is presumably a much worse mess than Flickr. --A.Savin 14:59, 11 May 2014 (UTC)

Info RfD'ed Commons:Deletion requests/Files uploaded by Rakoon --A.Savin 20:23, 13 May 2014 (UTC)

Bad change arresting the community just to attack me

I'm updating pt pages as most of then received the last updated in 2012, and Teles, that really like to persecute me in all Wikimedia communities now reverted one of the updates pages, two times [16]. The page is based in en/es/de... versions, and is totally updated. He reverted 2 times with no talk, and knowing him, he will reverted that eternally, without say the reason to let the page outdated or will use the steward tool to block me without asking other volunteers. Could pleas do something? Rodrigo Tetsuo Argenton (talk) 17:20, 12 May 2014 (UTC)

FYI: Here's what Teles wrote:

1st revert: large removal with no consensus. Please, discuss that first. // grande remoção sem consenso. Por favor, discutir isso primeiro.
2nd revert: large change with no consensus // grande mudança sem consenso

I don't think one can call that to persecute another user. You want to make a large change - just discuss it before you do. That's how Commons works. Very simple. --Hedwig in Washington ^(mail?) 17:58, 12 May 2014 (UTC)

"in all Wikimedia communities" do you want the list? Blocks, reversions, verbal attacks... put this in the context, add that he is not that active here and that he have a history of intervention in my editions.

And this is not a "large change", this is the same page as en/es/de... this is just a update, and is kind obvious that a update of 3 years is gonna be a little big, but, in this case, almost of all the text is the same, I just add some info and rearrange, you see -8000 k, just because I used a template in the page, as en/es/de... not a full text.

And I'm volunteer of WC since 2007...

@Hedwig in Washington: Did you saw the page? Rodrigo Tetsuo Argenton (talk) 18:13, 12 May 2014 (UTC)

Yes, I saw the page. I can't speak for the wikis, only for Commons. The revert was (IMHO) within guidelines. BTW: This is the wrong venue anyway. You might want to use Commons:Administrators' noticeboard/User problems instead. --Hedwig in Washington ^(mail?) 19:16, 12 May 2014 (UTC)

I think it's the right venue for discussing that new Main page layout. Frankly, I like it, except that column 2 is ways longer than col 1, even more in mobile view. -- Rillke^(q?) 20:29, 12 May 2014 (UTC)

What I meant is the discussion about another user. Layout discussion belongs here, no question. I should have clarified that. My bad. I agree with Rillke about the layout actually. --Hedwig in Washington ^(mail?) 22:51, 12 May 2014 (UTC)

When I did the page, this image Commons:Picture of the day#10 was at the main page. And as you can see at 11, the image was tall too. My bad, but I rearrange that, and divided the "content" column in two.
And I still think that was not that big change, as I used some of the text present at the page, and I translated the content of another main pages and used their structure to create it.
And I put here to try a solution, if you not agree with me, that it was a small change, more people can see the page and give me a feedback, and maybe another solution, because the page was totally outdated, and even then, he reverted and do not actualized it.
But, thank you Hedwig in Washington and Rillke for the feedback, what do you think that I should do to keep a updated main page? Rodrigo Tetsuo Argenton (talk) 11:39, 13 May 2014 (UTC)

Suggest updating it at Talk:Página principal and wait 7 days for comments. -- Rillke^(q?) 12:05, 13 May 2014 (UTC)

If I will have to do that in every single page that have to be updated, is better let all pages in cave paintings as they are now...

Thank you Rillke, the page will not be update, but I will do. Rodrigo Tetsuo Argenton (talk) 12:48, 13 May 2014 (UTC)

May 13

Request for Checkuser rights

This is to inform the community that there is a nomination for Checkuser rights here. It was agreed a couple of years ago that such requests and for Oversight (which are quite rare) should be publicised due to the high level of trust required in users with these rights. Trijnstel_talk 08:44, 13 May 2014 (UTC)

Can I translate the email Template ?

Hi, I'm OTRS member and I want to translate Commons:Email templates and the template also to another language to make it easier for other people to send permissions on this language, Can I make it ? --Ibrahim.ID (talk) 21:34, 13 May 2014 (UTC)

Sure. This has already been done for nearly 30 languages, and you don't say which you want to do. Just make sure you are not repeating work that has already been done. - Jmabel ! talk 00:31, 14 May 2014 (UTC)

May 14

<gallery> bug with some captions?

I'm trying to figure out why the captions in the first gallery in "Other pages" are not displaying in File:No Substantial Change in British Opinion on Vietnam Following U.S. Bombings, p. 1 of 3 - NARA - 304218.tif. I just uploaded 6 files from this same document with the same format, and the same thing happens to all of of them. The only difference between the gallery that works and the gallery that doesn't is that the one that does not work has files with a .tif extension... but there is no reason that should change the caption behavior. Any ideas? Dominic (talk) 00:57, 9 May 2014 (UTC)

Really strange bug. It seems to work if I replace the first space with its code. Ruslik (talk) 03:19, 9 May 2014 (UTC)

interesting. I bet what is happening is that page 1 (Tiff) is being interpreted as display the page 1 (Tiff) of a multi page tiff document. Jpegs cant have multiple pages so they cant trigger this. Bawolff (talk) 00:43, 13 May 2014 (UTC)

Yep, confirmed. I made gerrit:133401 to change this (If the change gets reviewed, it will make its way to commons eventually at some point). Bawolff (talk) 00:50, 15 May 2014 (UTC)

Enable VisualEditor as Beta Feature

Hi folks,

FYI, I have just reported bugzilla:65067 to have VisualEditor enabled as Beta Feature on Wikimedia Commons.

VisualEditor is (as far as I know) not scheduled to be deployed on Commons any time soon, but I think it would be interesting to see how it behaves here.

As a Beta Feature, VisualEditor will *not* be activated by default for anybody. Interested users will be able to enable it in their Beta preferences. This would not slow Commons in any way for any user who has not enabled it, and only marginally for users who would have enabled it (as Jdforrester assures me ;-).

So if anybody has any objection to this harmless change, please voice your dissent :-)

Jean-Fred (talk) 13:00, 9 May 2014 (UTC)

I have no objection to it being a Beta feature, but from experience at EN-WP, it was both good and bad. Good in that it did appear to make editing a little easier especially for newer editor but bad in that you lose a lot of that flexibility that editing the source gives you. I can't remember exactly who said it, but it did feel like a move towards the talking-paper-clip of Microsoft fame. Use it if it works for you but I am not expecting an editing revolution. It ranks right down there with ideas like Flow which will probably replace talkpages, but I'm not convinced of the benefits of it either. Green Giant (talk) 14:47, 9 May 2014 (UTC)

Update: VisualEditor will be enabled as a Beta Feature on Wednesday. Jean-Fred (talk) 22:05, 12 May 2014 (UTC)

Done by Matt during the SWAT. --MarkTraceur (talk) 23:51, 14 May 2014 (UTC)

Question about copyright status of File:Logo_LFM.jpg

Is File:Logo_LFM.jpg too simple to be copyrighted? Even though it's marked as an own work it's really a logo of a French school in Mexico (the logo can be seen here: http://www.legrandjournal.com.mx/categorie/la-une/lycee-franco-mexicain-attendez-vous-au-pire ) WhisperToMe (talk) 12:00, 14 May 2014 (UTC)

Probably not. Please create a DR. Thanks, Yann (talk) 13:03, 14 May 2014 (UTC)

Done And I will locally upload a logo for EN WhisperToMe (talk) 13:40, 14 May 2014 (UTC)

Done en:File:LFMMexlogo.png WhisperToMe (talk) 15:55, 14 May 2014 (UTC)

Problem with IIP - Interactive Image Viewer

Hi, some file do not appear to be working with the Interactive Image Viewer (IIP). Currently I have this file, that is not working with IIP. Who can help me with this or can give an advice? IMO a reliable zoom viewer is a pretty crucial feature on Commons. Otherwise it wouldn't make sense at all uploading further high res maps and such. Without a zoom viewer these files are not usable on Commons. --Alexrk2 (talk) 16:27, 9 May 2014 (UTC)

@Dschwen: could you give me the exact command line, that converts the JPEG to Pyramid-TIFF on the toolserver? I now have tested the file on a local IIP installation and could reproduce the problem with the black screen with that TIF from toolserver cache. If I convert the JPG by my self (with ImageMagik), than it works. I also have posted a help request at the IIP forum. --Alexrk2 (talk) 14:51, 13 May 2014 (UTC)

Oh, cool! That was you on the mailing list :-).

/opt/ts/bin/vips im_vips2tiff in.jpg out.tif:jpeg:75,tile:256x256,pyramid

Where in.jpg is the JPEG input and out.tif is the TIFF output. Thanks for following up on this! --Dschwen (talk) 14:06, 14 May 2014 (UTC)

@Dschwen: I guess, the problem is, that the one TIF file is in YCbCr color space, where the other TIF files I have checked on toolserver are all in sRGB. I have read here that IIPSRV 0.9.9 cannot handle YCbCr. The question is, why VIPS uses YCbCr in one case and sRGB in the other cases? I can't see a difference on the source JPG's. Is it possible, that you have changed the version of VIPS on toolserver/labs? Or did the VIPS tool decided itself, which colorspace is best for a specific file? According to this info, there is a bugfix in IIP to support YCbCr, but since there are no new official releases of IIP after 0.9.9, one have to compile the IIP sources from SVN to get the bugfix. Or the other alternative would be to use a hidden -rgbjpeg flag on VIPS to create RGB as described in the above link (this hidden flag is included in VIPS > 7.38.2):

vips tiffsave in.jpg out.tif --compression jpeg --Q=75 --tile --pyramid --rgbjpeg

I have tried this way and the resulting TIF file worked with IIP 0.9.9. But the TIF file is 2-3 times larger, because RGB is not so much efficient. --Alexrk2 (talk) 16:18, 14 May 2014 (UTC)

I pulled the IIP dev version from github and have the Zoomviewer working on labs now: http://tools.wmflabs.org/zoomviewer/index.php?f=Chicago.jpg . I'll check if your file works there. --Dschwen (talk) 21:49, 14 May 2014 (UTC)

Yes, it does. Yay. --Dschwen (talk) 22:09, 14 May 2014 (UTC)

Cool, thank you very much! Unfortunately today the service on labs is down again for some reason ("The URI you have requested, .. , is not currently serviced."). PS: Probably if you switch to YCbCr with VIPS for all TIF files, then the disc space for the cache could be reduced remarkable. --Alexrk2 (talk) 14:31, 15 May 2014 (UTC)

Can the search ever be fixed?

I just re-wrote the article on Chain Home. Now I want to spruce it up. So I come to the Commons and do a search on Chain Home. Ummm, ok?

Ok ok, I know what to do in these situations, you it in quotes. Ummmm, wha?

Now you might think this is somewhat esoteric, and caused by user error. But then why can't I find a ski boot? Or practically anything else I've ever searched for?

Surely we can do better than this?!

Maury Markowitz (talk) 17:20, 9 May 2014 (UTC)

What you describe seems to be pretty standard behaviour for search engines, the only difference being that the latter includes some pages irrelevant to your search. I tried Google with "chain home":Site=commons.wikimedia.org, which gave me substantially more results than either of your searches, so I'm not sure how our own search facility could be improved, other than adding some sort of context sensitivity. However, that would require significant programming effort which I'm not sure would be fruitful. Did you have anything more specific in mind? Rodhullandemu (talk) 17:31, 9 May 2014 (UTC)

What exactly is your problem? Both your first search and your ski boot search show me tons of on-topic images. Maybe you have de-selected the "File:"-namespace in the namespaces to be searched? Go to Special:Preferences#mw-prefsection-searchoptions and verify! (It is normally and by default included.) Lupo 17:35, 9 May 2014 (UTC)

His problem (and mine too, any anybody’s who wants to use the internal search engine for anything meaningful) is the inability to use quotes to find, e.g., items related to ski boots (better, occurrences of the single string "ski boots" = \u0073\u006B\u0069\u0020\u0062\u006F\u006F\u0074\u0073), as opposed to find any think about ski and boots (indeed, independent occurrences of both strings "ski" = \u0073\u006B\u0069 and "boots" = \u0062\u006F\u006F\u0074\u0073). (This has been the major issue with Commons’ search (indeed, Mediawiki’s) for a long time, not the existence of category trees, as said above.) -- Tuválkin ✉ 02:39, 10 May 2014 (UTC)

Maury Markowitz, you need these:

And indeed there is a Category:Chain Home radars (and also a Category:Ski boots). -- Tuválkin ✉ 03:12, 10 May 2014 (UTC)

So our solution to a fail here is to use Google to solve the problem? Why can't we just fix what we have? Maury Markowitz (talk) 11:06, 12 May 2014 (UTC)

Yes, that’s “our” solution. Unfortunately the Foundation prefers to sink resources (from our donations) in whimsical bells and whistles (media uploads, visual editor, typography ~~botch~~ “update”, media viewer, what next?) instead in well known and long sought issues, of which the faulty internal search engine is but one. Two good things in this case:

Unlike other long awaited Commons features the Foundation seems to have forgot about (translation of category names, anyone?), a faulty internal raw text search engine can be replaced by Google, as said above;
and, this being a user driven community — both in terms of actual content production and of financing —, said stress on frivolity and distancing from the users’ needs and wants on the part of the Foundation can be fixed (or worserned, though) within a couple Board election cycles.

-- Tuválkin ✉ 07:19, 16 May 2014 (UTC)

Hundreds of uncategorized aviation photos

There are hundreds, (maybe even thousands total) of uncategorized aviation photos in Category:Media needing categories as of 2 May 2014, Category:Media needing categories as of 3 May 2014, Category:Media needing categories as of 4 May 2014. Are these on anyone's radar (pun intended) for categorization? --Mjrmtg (talk) 21:28, 13 May 2014 (UTC)

Using Cat-a-Lot I copied them over to Category:Aircraft where given enough time interested people usually see them and categorise them properly. PS do you realise that you listed 2 May twice? Oxyman (talk) 18:17, 14 May 2014 (UTC)

The uploader of all of those aircraft should categorize them, not interested people. My mistake, meant to list May 2, 3 and 4th. --Mjrmtg (talk) 10:28, 15 May 2014 (UTC)

It would have been great if their uploader had categorized the photos, but if they are good images in Commons scope, I'd prefer to have them uploaded but uncategorized instead of not having them in Commons, just because the potential uploader doesn't have the ability, the time or the will to categorize them.--Pere prlpz (talk) 10:42, 15 May 2014 (UTC)

As you can see they are in Category:Files uploaded for Russavia (Aeroprints), so yes, they are on people's radar, and they are actively worked on and not just left for others to do. russavia (talk) 11:15, 15 May 2014 (UTC)

Anyone interested in this area may want to add some opinions and suggestions at Commons:Batch uploading/Airliners. It is the biggest avionics project on Commons and there are a couple of us helping that project who are very handy with tools to help with mass categorization and other well thought out improvements. When you are talking 100,000+ images, automation is essential. --Fæ (talk) 11:47, 15 May 2014 (UTC)

Coordinates for photos of buildings

Are coordinates supposed to reflect the location of the camera when a photo was taken or the location of the subject? For example, if I post a photo of a historic building that I took from the street, should the coordinates be the location of the house (the clear subject of the photo) or my location 100 feet away on the sidewalk? I can imagine an argument for both of those things, but I'm inclined to go with the former. — Preceding unsigned comment added by ProfReader (talk • contribs)

We have different templates for both:

{{Location}} for camera location and direction.
{{Object location}} for subject location.

Ideally, each file should have both coordinates. Quite often, we have images with camera location and categories with object location, which seems a fair good combination, too.--Pere prlpz (talk) 15:54, 15 May 2014 (UTC)

Even more ideally, {{Object location}} should be in the category of the object in question to show its position while {{Camera location}} (={{Location}}) should be in each photo’s or other such image’s file page, to illustrate their PoV. -- Tuválkin ✉ 22:28, 15 May 2014 (UTC)

How to make language never change?

As you may know, the user interface language spontaneously changes when entering Commons via any Wikipedia. This is really bothersome to me since I often cruise image-to-wikipedia-to-commons-to-category-to-image-etc and I'd like a way to make Commons always be in English, always, no matter what, no matter where the link was from. User script ideas? --Pitke (talk) 19:37, 15 May 2014 (UTC)

Use a user script at the Wikipedias you most often frequent to replace the "&uselang=XX" in links to the commons by "&uselang=en" (or simply remove the uselang parameters). Or use a GreaseMonkey script to do so for any site other than the Commons itself. Lupo 20:06, 15 May 2014 (UTC)

I second Pitke's request. Would it be possible to introduce an option in Commons preferences to show pages always in the same language? YLSS (talk) 20:51, 15 May 2014 (UTC)

Any ideas how I could have a bot edit all my +50 global account local js files? (Replacing files often takes me to most exotic wikipedias...) Or more importantly, what would such a script look like? GreaseMonkey sounds tempting but it'd only be a local cure. --Pitke (talk) 21:14, 15 May 2014 (UTC)

bugzilla:57891 is hopefully resolved soon. Then you can have one-for-all :) -- Rillke^(q?) 21:36, 15 May 2014 (UTC)

May 16

Using image annotations on montages to navigate to individual images

Hello, I just decided to use image annotations on the montage File:Senf-Variationen.jpg to simplify navigation to the individual images used in it. In general (i.e. for other montages), does this seem like a good idea / a "why not" / not really useful / a bad idea?

Thanks. Cos-fr (talk) 11:27, 14 May 2014 (UTC)

Seems like a fine idea to me. - Jmabel ! talk 15:44, 14 May 2014 (UTC)
- It works nicely. The only con I would like to point is that annotations cover 100% of your image. Therefore, you can't click the image itself to see it bigger. Of course, this is not a big problem because there is also a link, but leaving some part of the image to click would be even finer.--Pere prlpz (talk) 16:00, 15 May 2014 (UTC)

Here is another nicely annotated pic. I suggest, the mouseovers should possibly designed somewhat aesthetically more pleasing. Cheers, OAlexander (talk) 13:04, 16 May 2014 (UTC)

Categories in Cat-a-lot

I have selected "Allow categorising pages (including categories) that are not files" in Cat-a-lot and saved the result as publicly visible into my account, but when I want to categorize categories, it often turns out that my preferences have reverted, so I have to reselect the feature over and over. How can we solve the problem? --Jonund (talk) 16:35, 14 May 2014 (UTC)

That’s normal behaviour of Cat-a-lot, at least for me, sadly. -- Tuválkin ✉ 22:26, 15 May 2014 (UTC)

Yeah, this never seems to stick for me, either. -Pete F (talk) 09:23, 16 May 2014 (UTC)

To me, it looks like a recent phenomenon. I have used Cat-a-lot for a couple of years, I guess, but until recently the problem has appeared very seldom. In the past few days, however, I have had to set my preferences right after about half of the times I have used the feature. --Jonund (talk) 15:10, 16 May 2014 (UTC)

May 15

Commons community input needed: RFC on Open Datasets

After some talks during the Zürich Hackathon, it seems that there is the need to start a broad discussion about how how to deal with open datasets.

It affects to Commons because, depending on how you regard them, datasets could be considered another kind of file. I don't know if there is any position on the subject already, but in any case I would appreciate that you share your view on the topic as community members. Thanks! --Micru (talk) 16:23, 15 May 2014 (UTC)

So, would you mind if data files (CSV, or other formats) were stored in Commons for creating visualizations or for displaying them on Wikipedia?--Micru (talk) 06:31, 16 May 2014 (UTC)

@Micru: Is there any reason why you prefer for the data to be hosted here on Commons instead of Wikidata? This project is primarily a media repository while Wikidata deals with, well, data, most of the time. odder (talk) 08:52, 16 May 2014 (UTC)

@odder: Thanks for asking, I'm totally aware of the confusion that my question creates. Wikidata deals with structured linked data, that is, tiny bits of information that when connected to each other convey some meaning. In this case I was referring to "data blobs" that cannot be integrated easily into wikidata structure, but still, they might be useful to generate visualizations or just to display them in Wikipedia. For instance take this graph, it would be very hard to represent in Wikidata since you would need to create a whole semantic structure around it and deal with each part of the graph independently... that is a hell of a job just for a graph that refers to a very particular incident. Instead it is much easier to consider the data that generates that graph a dataset file and then create a visualization of that file, and that is totally out of the scope of Wikidata. Other examples could be this or this, which are generated thanks to data tables.

As I understand, Commons deals primarily with media files, and storing tables like this one, might be not be seen as content acceptable for the project, even if it is used to generate a visualization. OTOH, Commons offers file versioning and it is already integrated with all projects, which makes it a good candidate to host this kind of files... if the community wants it.

It is a delicate topic, so that is why I wanted to pull in some members from Commons into the RFC so they could share their view. If from my side I can do anything or add further clarifications, I will be very glad to help.--Micru (talk) 11:13, 16 May 2014 (UTC)

Re: Subcategories of Category:Black and white photographs...

...such as Category:Black and white photographs of the United States in the 1930s, didn't we have consensus a while back that Category:Black and white photographs is more like a tag and should not get subcategories? If not, how do we avoid ultimately duplicating all or most of our category tree with separate categories for black and white photographs of each thing? - Jmabel ! talk 00:23, 13 May 2014 (UTC)

Support Doesn't make sense, there aren't that many modern b&w photographs. Tagging modern ones as such would be more meaningful. --Hedwig in Washington ^(mail?) 03:12, 13 May 2014 (UTC)

Consensus, NANANANANAA, I can't hear you, NANANANAA, I just create nonsense subcategories, NANANANANA.

As long as it's much easier to create a category than getting it deleted again this will be an uphill battle. Multichill (talk) 20:44, 13 May 2014 (UTC)

Recent example. Is it OK to roll these things back, or do we just let this keep going indefinitely, or what? - Jmabel ! talk 15:41, 14 May 2014 (UTC)

It's a lot easier to create categories than to delete them. This is also a special case of a general problem, that the category system doesn't cope well with multiple independent classification systems. You see the same problem with file types (Category:PDF files by subject, Category:Videos by subject etc.) and dates, time of day, seasons etc., like Category:October 2012 in Bridges Street, Hong Kong. --ghouston (talk) 23:41, 14 May 2014 (UTC)

Detailed and multi-criterion classification is useful, but it has some inconveniences. We can't get rid of the inconveniences until we got tools to easy see files in all subcategories of a given category.--Pere prlpz (talk) 20:34, 16 May 2014 (UTC)

If there's already a consensus for Category:Black and white photographs then surely it's acceptable to delete the nonconforming subcategories, if you've got the patience for it. --ghouston (talk) 00:12, 18 May 2014 (UTC)

File history and storage space

Hi

Is there any way to flag files in the history for deletion? I made the mistake of uploading several videos with broken audio, and they just take up unnecessary space IMO, I've replaced them all with functioning ones.

What I'm referring to is the first version of all these listed files. - Anonimski (talk) 21:36, 16 May 2014 (UTC)

An admin can sort this out, though there is not standard way of requesting it, you just have to find an admin and talk to them about it. It may be easier to delete the file using a speedy delete request and re-upload it. --Fæ (talk) 22:03, 16 May 2014 (UTC)

Deleting files doesn't save space. Copies of all deleted content are kept on the server in case it needs to be restored in the future. --Carnildo (talk) 22:16, 16 May 2014 (UTC)

Seconding what Carnildo said. Space is not particularly at a premium. Really, the only time we need to delete old versions of a file is when they raise legal issues, etc. - Jmabel ! talk 15:38, 17 May 2014 (UTC)

May 17

File:M&GStationeryLogo.jpg

For en:File:M&GStationeryLogo.jpg, would this logo be considered to be too simple to be copyrighted? What about the Chinese version, http://www.mg-pen.com/images/index/logo20140306.jpg ?

Thanks WhisperToMe (talk) 04:18, 17 May 2014 (UTC)

Should both be ok marked with {{PD-textlogo}}{{Trademarked}}, Category:Logos of companies of China. I suggest however, that those logos will be transformed to PNG format. Jpeg is unsuitable for them. Cheers, OAlexander (talk) 11:52, 17 May 2014 (UTC)

Forced Slideshow

Since two days there is a new and absolutly annoying “feature”. If one clicks a small image in a category like Category:Village pumps in Burkina Faso or gallery one no longer gets the usual larger view like File:Balga, February 2010, Women around the water pump - conversation.jpg. Since two day one instead gets forced into a slideshow view. To achieve the mentioned normal view one first needs to cklick a _tiny icon hidden in the bottom right corner of the slideshow view. Why that? Is the programmer of the slideshow so very proud of it that he feels that he must force every user to see it?

PLEASE SWITCH THIS ANNOYING “FEATURE” OFF!

It was very good as it was. There is no need for a forced slideshow.

--- Ies (talk) 14:00, 17 May 2014 (UTC)

See above thread #Media Viewer launches on Commons this Thursday. Bawolff (talk) 15:19, 17 May 2014 (UTC)

You could just click the filename, that takes you direct. But yes, it is annoying if you're a worker rather than user. -mattbuck (Talk) 19:49, 17 May 2014 (UTC)

Ies, you can also turn it off in your preferences. It's a check box under "Files" that says "Enable new media viewing experience." Keegan (WMF) (talk) 03:42, 18 May 2014 (UTC)

Clicking the file name as a workaround works in categories only, not in galleries. I think this new behaviour on image clicks is one of the recent bad ideas (like the new "good pictures" that at least got modestly in appearance but still suggests that the rest of the images is not good - what might be completely wrong.) I turned it off in the preferences. Thank you very much for the instructions, Keegan (WMF)! -- Ies (talk) 05:41, 18 May 2014 (UTC)

Images based on YouTube videos - are they eligible for OTRS tickets?

The user-generated works in Category:Artwork depicting Natalia Poklonskaya are primarlily derived from YouTube uploads of a press conference that Natalia Poklonskaya gave, such as http://www.youtube.com/watch?v=ww9cBExFIiE and other YouTube videos listed there.

Are these considered "Derivative works"? (See another concern about these images at Commons:Village_pump/Archive/2014/05#Basis_of_OTRS_tickets.) Thanks, Parabolooidal (talk) 20:13, 17 May 2014 (UTC)

These are not DWs, this has been discussed before, please cease these baseless allegations. These are original artworks depicting a person, created individually by the author without incorporating third-party imagery within the work. Some of the images even predate that video you've posted, don't tell me the artist used a time machine? Also, stop splintering this discussion, you've posted this at multiple different talk pages, and without proper context, it's easy to confuse and mislead other people. We cannot have multiple discussions going on at different places regarding the same thing, keep the discussion centralised at Category talk:Artwork depicting Natalia Poklonskaya. --benlisquare_{Talk•Contribs} 02:50, 18 May 2014 (UTC)

May 18

Is a map with overlay of objects possible?

I have a follow-up question about the different geocoding options. Is there a way to open a map in Google Maps or something else which overlays the locations of the actual objects and not all of the camera positions? Although I can see where a camera's position might be useful to someone down the road, I really can't imagine why an overlay map of actual object positions would not be possible in favor of one showing camera positions.

Please see Commons:Geocoding/Overlay--Jarekt (talk) 14:43, 19 May 2014 (UTC)

O/S icons in screenshots

What rules apply when screenshots of software include default operating system icons (eg. File:EPANETScreenShotEspanol.jpg, which features Windows 97 icons for "open file", "save", etc)? Are these icons known to be in the public domain, or are such screenshots inadvertently releasing small Microsoft icons under CC-Attribution? --87.81.167.93 10:49, 19 May 2014 (UTC)

I can't answer your question, but the icons in your example aren't part of the OS, they are from en:Borland Delphi. --Magnus (talk) 12:17, 19 May 2014 (UTC)

My guess is that they could be considered de minimis. -mattbuck (Talk) 13:07, 19 May 2014 (UTC)

Do we really need toolbar in screenshot? --EugeneZelenko (talk) 14:00, 19 May 2014 (UTC)

For the IP: The guideline is at COM:Screenshots. I personally don't think the 3D window bars are de minimis, because the image would look entirely different if someone removed them. FDMS 4 19:20, 19 May 2014 (UTC)

Category:Filetype icons

Can someone write an clear and significant description to this category (I'm not a especially well English speaker) as we can see in all subcategories there is a completely misunderstanding what it are (especially Category:SVG_icons and Category:PNG_icons). Or is it better to rename the subcategories (MIME type/file type)? -- Perhelion 18:43, 19 May 2014 (UTC)

Opinions on mass content donation offer

The Open Culture Data network in the Netherlands has offered to do an extremely large content donation. There are several advantages and disadvantages to this upload, that's why I'd like some reactions to this proposal.

Ter-burg (talk) 08:30, 20 May 2014 (UTC)

Modified automobiles

In Category:Modified cars it says that «this is a specific class of racing cars, not a category for cars with modifications.» Okay then, but what is the category for cars with modifications, then? (I wanted to tag this photo.) -- Tuválkin ✉ 23:46, 19 May 2014 (UTC)

It is Category:Custom cars — thanks, User:Mattes! -- Tuválkin ✉ 02:04, 21 May 2014 (UTC)

May 20

Animation speed

Timing	Spec Speed	Firefox and IE 10+	Internet Explorer 1–9
0/100	N/A	10 fps	10 fps
1/100	100 fps	10 fps	10 fps
2/100	50 fps	50 fps	10 fps
3/100	33 fps	33 fps	10 fps
4/100	25 fps	25 fps	10 fps
5/100	20 fps	20 fps	10 fps
6/100	17 fps	17 fps	17 fps
7/100	14 fps	14 fps	14 fps
8/100	13 fps	13 fps	13 fps
9/100	11 fps	11 fps	11 fps
10/100	10 fps	10 fps	10 fps

I've updated User:Dispenser/GIF check. On of the quirks I'd like to highlight is differences in animation speeds between older versions of Internet Explorer and Webkit with the table on the right. These images (listed in the report with a yellow background) need to be checked.

If it looks fast re-uploaded with 10/100 timings as the uploader was unaware that their browser slowed it down.
If the animation speed looks correct, tag with {{Slow GIF}} so its removed from the report.

Also, Animations with 0/100 frame timing (listed with a black background) need to be re-timed and re-uploaded. Read more on Frame delays —Dispenser (talk) 17:42, 20 May 2014 (UTC)

Usage of images in a given category

Hi all, I have two questions:

is there a tool to measure how many images in a given category (and subcategories) are used? For example I would like to know how many images there are in this category and how many of those are used on any Wikimedia project.
is there a tool to list unused images in a category: I know that some work is done for Wiki Loves Monuments images but I would like to know if there are tools available for an arbitrary category. Thank you. -- CristianCantoro (talk) 20:09, 20 May 2014 (UTC)

Gadget-Glamorous -- Rillke^(q?) 21:02, 20 May 2014 (UTC)

May 21

Anyone else having problems with Flickr uploads ?

Tracked in Phabricator
Task T67406

So everytime i try to upload something via flickr using the Special:UploadWizard section ("share images from Flickr"), while loading the image, i get an external message saying this and even if i select "Stay on Page", it keeps loading (loop) and nothing actually gets uploaded.....I'm forced to upload images from flickr via url2commons ..anyone else having this problem?..--Stemoc (talk) 12:46, 16 May 2014 (UTC)

Oh, that's funny. If you click "leave page", you see the API result which should run as AJAX in the background ... -- Rillke^(q?) 17:41, 16 May 2014 (UTC)

Use the Flinfo upload, it is by far the best way to upload Flickr images - does several useful things, including checking the validity of the license, adding geolocation data automatically, and preventing accidental duplicate uploads of files already uploaded at Commons. - MPF (talk) 19:39, 16 May 2014 (UTC)

I have been using a combo of Flinfo and url2commons and since i'm on Limited internet, I can't actually afford to download and then upload files bigger than 5Mb..I also got that API result a few times..figured something was broken..--Stemoc (talk) 01:29, 17 May 2014 (UTC)

@MPF: Thanks, but I don't think Flinfo prevents "accidental duplicate uploads of files already uploaded at Commons". I never programmed such a check into Flinfo, since the various upload forms/wizard here already do that, and in fact I cannot do so due to bandwidth limitations on the server Flinfo runs, as then Flinfo would have to download the whole image file onto its own server. Lupo 21:47, 17 May 2014 (UTC)

@Lupo: Odd! I've found if I try to upload a pic that happens to be on Commons already, it stops the upload with a warning, saying (approx) "This file is a duplicate of File:Xxxxx.yyy" with options to cancel, or to proceed only if a box 'ignore any warnings' is ticked - MPF (talk) 22:42, 17 May 2014 (UTC)

Yes, but that's not Flinfo. That's the Commons' upload form. When you click the "Open upload form" buttonat Flinfo, it opens the upload form here at the Commons (pre-filled with the information generated by Flinfo). Lupo 22:59, 17 May 2014 (UTC)

@Stemoc: why not just use Flickr2Commons? russavia (talk) 11:47, 19 May 2014 (UTC)

Uploading from Flickr using Upload Wizard with any version of Microsoft Internet Explorer >= 6 should work and Opera and Chrome possibly work. It's completely broken for Mozilla Firefox 29, though. -- Rillke^(q?) 10:43, 19 May 2014 (UTC)

+ Safari 7 doesn't (didn't) work either. FDMS 4 11:31, 19 May 2014 (UTC)

I have IE7, doesn't actually work, I tried on Chrome earlier, same problem as IE7, the "Get From Flickr" link gets greyed-out and nothing happens..currently on FF29...and Russ, yeah with flickr2commons, it refuses to review the images and that is a major flaw, it used to work perfectly before....not anymore..--Stemoc (talk) 12:04, 19 May 2014 (UTC)

Now i get a new warning saying this .....well this is getting weird...--Stemoc (talk) 14:17, 21 May 2014 (UTC)

Can MediaViewer display full-sized images ?

Can the new Media Viewer display full-sized images ?

I've been uploading some maps recently, and the text isn't really readable at 1024 px -- having found a bit of the map I want to look at, really I want to click through and see it full-sized. I usually use Mozilla, and so it's automatic -- the browser by default displays an oversize image shrunk to fit in the window, but with a magnifying glass you can click on to see the image full size. And of course to get to the full-sized image I just had to click on the Commons 600px preview.

MediaViewer doesn't seem to be able to do this. Is this something that is going to be fixed?

Yes, I know that there is an (incredibly small & anonymous) Commons icon that can be clicked on to get back to the classic Commons experience, but (frankly) most naive users are never going to find it, because it has been made as insignificant as possible. So is there going to be an easy way for them to see key bits of 2500px images at full resolution?

ALSO, I note that MV is back again when you click on an image in a Commons category. (Perhaps I was being spared until now, because I was still using the old skin with the sans-serif typeface). I have to say, this is incredibly annoying, and I wonder if there is any user (however newbie) who is browsing Commons for whom this behaviour is appropriate. For somebody trying to work with images and edit their pages, being thrown into MV is a complete pain. As for mere 'readers' of the encyclopedia, IMO if they are sophisticated to find their way to a Commons category (which we make really quite difficult), then they are sophisticated enough to be able to deal with a classic-style description page. And if they are newbies trying to learn their way round Commons, the classic description page is going to be much more intuitive and concrete to learn from, because (i) it's just a literal rendering of the wikitext, so a newbie can immediately see how it works; and (ii) the structures of Commons are exposed in a much more transparent way, so the classic page is much easier to see how it fits together and learn from.

There may be a case for MV on the individual wikis; but here on Commons it just seems to be a stumbling block, both for experienced users and for beginners. I know there are preferences I can set to turn it off for myself personally; but I wonder if there is actually any user on Commons who gains by being dropped into MV from category view? Jheald (talk) 21:24, 19 May 2014 (UTC)

Might be worth to bring up on mw:Extension_talk:MultimediaViewer. --AKlapper (WMF) (talk) 09:05, 20 May 2014 (UTC)

As much worth it was to ask for the zero option (i.e. do nothing, scrap the project) for Visual Editor, I guess. This MediaViewer debacle caught me unprepared, I must say: In view of some of the promised advantages, I slid my expectations from curmudgeon halfway to fanboy. Turns out that the final result is even worse than the worst caricature a bitter contrarian could have dreamed up. And it is not bugs, it is all features — these two take the cake: Lack of zoom (hiding away the potential reuse of most images, from where details can be cropped) and a chirpy «Use this file» button that skips all the caveats and licensing minutiae, encouraging potentially illegal misuse. It is truely appaling. -- Tuválkin ✉ 09:34, 20 May 2014 (UTC)

For what its worth, I would probably pay good money to see fanboy Tuválkin. Bawolff (talk) 20:46, 21 May 2014 (UTC)

(Jheald is on the spot here, it should be said.) -- Tuválkin ✉ 09:34, 20 May 2014 (UTC)

Thanks for the feedback, Tuvalkin and Jheald, it's important that we hear things like this so we can hopefully make Media Viewer more useful to Commons. The "zoom" feature is a high priority for development and we made the conscious decision to leave that out of Media Viewer at the moment so that when we develop it, we get it right and have high functionality out of it. Many of the other cases and inconveniences you mention have been brought up over on mediawiki.org and I invite you to participate over there as well as leaving your feedback here. I appreciate you taking your time to write these observations out. Keegan (WMF) (talk) 00:44, 21 May 2014 (UTC)

Keegan (WMF), the only thing I want to say about MV on mw is to vote {{Sup}} in a call to terminate the project completely and reassign its resources for actually useful matters; that will not happen soon, as we know. Your smarmy business-like tone (business, as in in-bound call center product support: not good) sets me off the rails, too, and hinders any serious discussion. The discussion page on mw you suggest includes, contrastingly, pearls of wisodm such as «Commons file description pages are disorientating jumbles of random information» and «transition to a saner user interface.» This of course only prompts on my side unhelpful and uncivil considerations about the competence of paid staff working for a non-profit — I don’t want to go there. I’ll just keep MV off, and advise anyone to do the same. Keep “developing” it, by all means. I’ll show up again when you try and make it compulsory — you’ll have you war then. -- Tuválkin ✉ 02:35, 21 May 2014 (UTC)

Clearly we have a misunderstanding </obvious hat>. Seriously, Tuvalkin, no offense by my wording intended. I'm addressing more than one person in an international forum. That does not mean that I did not listen and understand your criticism, or pass them along to the team. It's not dismissive: I actually hear you(all), and the team will weigh it with the constraint that is getting into things that you say that you prefer the team to do. Media Viewer is not some half-cocked idea from the WMF, it's a genuine community request as well as a reader request.

Here's some links of community consulation: Video Roundtables -2, 4, 5, IRC office hours, and in person at Wikimania.

Fabrice, the Multimedia product manager, saw fit himself to raise the discussion below based on community feedback like yours above. This really is intended as a team effort and I'm honestly inviting you to participate in a constructive manner to build a tool that you might never personally use, you might hate, but consider the benefit for the reader. It's like one of those ridiculous Jerry Macguire "Help me, help you" things where it's sounds self serving on both ends, but really we're supposed to be serving each other. YMMV. Keegan (WMF) (talk) 06:10, 22 May 2014 (UTC)

Hi Jheald, Tuválkin, AKlapper (WMF) and Bawolff: thanks for your helpful comments about displaying full-sized images in Media Viewer. Based on your good feedback, we would like to proposed a new feature for Media Viewer: "View Original File", and would be grateful for your thoughts about it.

This feature would enable you to access the original file from Media Viewer, so you can examine it in your browser, and easily edit/re-use it. To view that original file, you would simply click on a new "View original file" button next to the image, as shown in this mockup. This would open the original full-size image in the same browser window, as happens now when you click images in file description pages on Commons. Your browser’s back button would return you to the Media Viewer. "View Original File" would provide the same core functionality you are used to on file description pages. It would enable you to operate on files (convert/edit them), and also give you the ability to zoom on common file types in modern browsers.

We investigated several other solutions to address user requests like yours. We developed a Simple Zoom Link, which you can test now on Commons: but we’re concerned that this implementation provides a poor user experience that’s more complex than it needs to be. We also considered a Basic Zoom and a Full Zoom features. But these implementations require more development time than we have right now. So we hope that the "View Original File" option can support your needs, without requiring a major development.

What do you think? Would this approach work for you? If you have a moment, you are also welcome to add your comments this discussion page.

Thanks for your guidance about this important issue. With your help, we hope to implement a practical solution that can address your most pressing needs in coming weeks. All the best. Fabrice Florin (WMF) (talk) 00:02, 22 May 2014 (UTC)

jQuery v1.3

I with each page load I am getting "blockUI requires jQuery v1.3 or later! You are using v1.11.1" error, in last 10 minutes. Any ideas? --Jarekt (talk) 19:04, 20 May 2014 (UTC)

I have emergency disabled jquery.blockUI until the problem is resolved. Mabye some gadgets broken now. --Steinsplitter (talk) 19:20, 20 May 2014 (UTC)

I just updated MediaWiki:Gadget-jquery.blockUI.js, so I think it could be re-enabled. In any case, this alert should have occurred only for people who have the DelReqHandler or autodel gadgets enabled. Lupo 19:25, 20 May 2014 (UTC)

User:TheDJ has just re-enabled it. If you do get the alert again, re-load your browser's cache. Lupo 19:31, 20 May 2014 (UTC)

Thank you for your swift action, Jarekt, Steinsplitter, Lupo and TheDJ. -- Rillke^(q?) 19:42, 20 May 2014 (UTC)

In what world is 3 > 11? -mattbuck (Talk) 20:24, 20 May 2014 (UTC)

Some programs only know 0 to 9, that's why M$ uses 9 + higher revision for internal version numbers of IE 10/11. --Denniss (talk) 20:27, 20 May 2014 (UTC)

Nowhere sane. "3" > "11", on the other hand though... Bawolff (talk) 20:43, 21 May 2014 (UTC)

Looking at the source code this is where it goes wrong: if (/^1\.(0|1|2)/.test($.fn.jquery)) Basically, what this does is check whether the jQuery version starts with 1.0, 1.1 or 1.2. Obviously people didn't think that jQuery would use minor version numbers greater than 9. Regards, --ChrisiPK (Talk|Contribs) 22:44, 21 May 2014 (UTC)

Ripped clothing

Am I right, there is no category for ripped clothes? There are many examples on Commons about the subject, but then again, would it be an ambiguous or misleading/unuseful category? --Btmpnr01 (talk) 19:49, 21 May 2014 (UTC)

If you do set it up, one parent should be Category:Ripping. And your text on the category page should also include the phrase "torn clothes" so that the other most likely search term will find it. - Jmabel ! talk 23:46, 21 May 2014 (UTC)

I created the Category:Ripped or torn clothes. I hope the name suits well. --Btmpnr01 (talk) 08:11, 22 May 2014 (UTC)

Instructions Commons:Rename a template

Can someone please take a look on this very new page and may link it to other pages? And what is the way with dozens of subpages? -- Perhelion 21:24, 21 May 2014 (UTC)

Category pages will be movable soon

On May 20, with the rollout of MediaWiki version 1.25wmf5, all users will be able to move category pages. While files and pages inside categories will still have to be moved independently, I suggest that we limit this possibility to administrators and file movers just like we do with the ability to move files.

This can be achieved by assigning the move-categorypages user right to the filemover user group via a config option in InitialiseSettings.php, and removing it from the user user group (as demonstrated by the English Wikipedia).

If there is enough community consensus to do so, I can prepare the necessary patch myself. odder (talk) 12:23, 13 May 2014 (UTC)

Support odder's proposal to limit this user right to trusted people. Green Giant (talk) 13:27, 13 May 2014 (UTC)
Support as reasonable precaution. --EugeneZelenko (talk) 14:14, 13 May 2014 (UTC)
Comment I think we don't need more protection against new methods of category renaming than we have against old ways. The same people that can use Hot-Cat should be allowed to rename categories. Are we going to forbid renaming categories by copy-pasting as usual? If we aren't, I can't see any need for new protections.--Pere prlpz (talk) 14:24, 13 May 2014 (UTC)
- Oppose as stated, and after reading other people comments.--Pere prlpz (talk) 20:51, 16 May 2014 (UTC)
Comment Thanks for the notification. Bots should be updated to move instead of copying the description. odder, did you talk to the maintainers? About restricting the right; not sure whether we shouldn't give it a try without restrictions. -- Rillke^(q?) 16:14, 13 May 2014 (UTC)

@Rillke: This is a MediaWiki core change, so I expect pywikipedia to include it in its code soon. I haven't contacted any bot maintainers yet, though (there is no easy way of doing that except messaging each and every one of them on their talk pages, as far as I am aware). I'm unsure about what is the best path forwards with this new feature, and that's precisely why I asked for your comment. odder (talk) 16:47, 13 May 2014 (UTC)

Please assign the move-categorypages right to bots as well, in case you see community consensus to restrict it. I've notified the operator of SieBot. Any other bot that is offering its service to move categories that needs to be updated? -- Rillke^(q?) 23:07, 13 May 2014 (UTC)

@Rillke: There doesn't appear to be enough consensus to restrict the user right, so that might not be required. I do not know any other bots that advertise this particular type of service, but many bots are doing category renamings (as far as I am aware), so they could definitely make use of this new feature. Thank you for contacting Siebrand; I greatly appreciate your involvement. odder (talk) 13:10, 14 May 2014 (UTC)

@odder, if you say all you actually mean all? Including blocked users and non-autoconfirmed users? Note that moving regular pages requires at least being autoconfirmed. You can quickly look this up in the local user rights table. Also, I would be opposed to having blocked users being able to move category pages. -- Rillke^(q?) 17:36, 16 May 2014 (UTC)

@Rillke: Blocked users are unable to perform any action except posting to their own talk pages and sending e-mails (unless their block prevents them from doing that as well), so they will not be able to move category pages until their block expires. The new user right is assigned to the user user group by default and not the autoconfirmed user group. It means that precisely all users will be able to move category pages once this comes into life—and hence my usage of the word. odder (talk) 18:34, 16 May 2014 (UTC)

Then let's restrict this to autoconfirmed? I see no reason why users shouldn't be able to move Galleries but are able moving Categories at the same time. -- Rillke^(q?) 18:54, 16 May 2014 (UTC)

Comment I agree with Pere prlpz, that restricting some actions to trusted users is a bit of counterproductive if there is a workaround that every-body else can use. UploadWizard flickr option is restricted to trusted users so everybody else uses Bryan's flickr upload tool or manually downloads and uploads the images. Anybody can "move" a category by copying the content to a new page and placing {{Category redirect}} template in the old category, so restricting the new better method to trusted users will only mean that most of the time the old method will be used. --Jarekt (talk) 16:52, 13 May 2014 (UTC)
Comment This is good news! I suppose it makes sense to restrict this to file movers, because like moving files, it's important to have an understanding of how things fit together. But on the other hand, I think the impact of a bad move is much less than with a file; there is much less possiblity of naming conflicts with categories, for instance. So I think just enabling it for all users would make sense too. Either way, great to know this feature is coming -- very helpful! -Pete F (talk) 16:57, 13 May 2014 (UTC)4
Support as reasonable precaution. --Steinsplitter (talk) 00:11, 14 May 2014 (UTC)

Weak oppose As was already pointed out, there is currently no restriction on moving categories, as the current way of doing this doesn't involve a technical "move". So, restricting the new "true" category moves to filemovers IMHO would only make sense if at the same time the current, manual "category move" is forbidden. Gestumblindi (talk) 23:32, 14 May 2014 (UTC)

Support as reasonable precaution. Manual changes or with Hotcat are easily reverted, a move involves further actions. As absolute Mimimum a user should have autopatrolled rights.--Denniss (talk) 05:44, 15 May 2014 (UTC)
- CommentAs the new "category move", as I understand it, adds no functionality besides moving the actual category page like any other page move, but all other elements of moving categories still have do be done as before (e.g. re-categorizing the images manually or with Hotcat/Cat-a-lot), I do not think that it is much more "dangerous" than what we have now. I think there needs to be a decision: Either we want to restrict category moves. Then the restriction needs to be thorough - stop allowing fully manual category moves, too. Or we leave it as it currently is - unrestricted. Gestumblindi (talk) 14:28, 15 May 2014 (UTC)
Support Sounds good to me -FASTILY 09:14, 16 May 2014 (UTC)
Oppose Just moving a category page does not sound to me as something that requires any precautions. It would be another matter if this function allowed actually moving the contents of categories. Ruslik (talk) 11:54, 16 May 2014 (UTC)
Oppose – Average users should be able to use this new ability freely and without much interference. We need to have more faith in the common user. Restricting rights every time they're introduced signifies how little faith we have in each other. --Michaeldsuarez (talk) 12:40, 16 May 2014 (UTC)

The 'average user' as you've described is not the problem. It's the vandals/SPAs that are of concern. -FASTILY 07:12, 17 May 2014 (UTC)

Page move vandalism already exists for articles. We'll handle vandalism as we've always done. We shouldn't trade freedom for security. --Michaeldsuarez (talk) 11:45, 17 May 2014 (UTC)

Support - while average users could be trusted, a very small minority of vandals could cause a lot of damage very quickly with this tool - MPF (talk) 16:15, 16 May 2014 (UTC)

How exactly? If it's not different from just creating new pages in the category namespace. -- Asclepias (talk) 16:30, 16 May 2014 (UTC)

In fact, a very bigger damage can be done with Cat-a-lot than with page moving. A category page renaming is easy to revert, while emptying of a category is very hard to undo. Therefore, we shouldn't prevent users to move a category page more than we prevent them to use Cat-a-lot.--Pere prlpz (talk) 20:49, 16 May 2014 (UTC)

Support, because a direct "move category"-button for everyone will be an invitation for "good faith vandalism". Actually, any edits in category namespace should be restricted to experienced users with a special user group. I'm really tired of the whole mess I have to clean up again and again, mainly in Russia-related categories. Did you know that nearly every second category of personalia there still do not have the appropriate sort key? --A.Savin 14:24, 17 May 2014 (UTC)

  Support giving the right only to filemovers (and admins), actually a lot more harm can be caused via categorymoving than filemoving.    FDMS  4    21:56, 17 May 2014 (UTC)
There seems to be a misunderstanding, FDMS4, as you write "actually a lot more harm can be caused via categorymoving than filemoving" - as pointed out above, the new feature allows nothing more than moving a category page. That is the move of a single page, not touching the categorised content at all - re-categorizing still has to be done manually or with Cat-a-lot etc. So, the new feature has very little potential do to "a lot more harm". So I agree with Pere prlpz: "Therefore, we shouldn't prevent users to move a category page more than we prevent them to use Cat-a-lot". Gestumblindi (talk) 23:37, 17 May 2014 (UTC)
@Gestumblindi: I got that, but still a category is in my eyes in many ways more "valuable" than a file. Also, if a category gets moved the old category also gets redirected, and we have bots (one for the {{Catredirect}}, one for the files) that update redirected categories and therefore potentially "spread" the vandalism to hundreds of pages. Cat-a-lot is disabled by default, but I personally would not object requiring users to be at least (auto)patrolled to use it.    FDMS  4    00:04, 18 May 2014 (UTC)
@FDMS4: Well, under the current system, when you "move" a category page, you create a new page and manually leave a category redirect on the "old" one, so I don't see a huge difference... Gestumblindi (talk) 00:22, 18 May 2014 (UTC)
@Gestumblindi: Did you know you can download files from Commons? And reupload them under a new name :) ? (And even run GlobalReplace?) The difference is of course in both cases how much time each process consumes.    FDMS  4    00:30, 18 May 2014 (UTC)
Oppose There's no damage that users could cause by moving category pages that they couldn't cause already. (Note: I'm the one who wrote the code for the feature.) Jackmcbarn (talk) 16:32, 18 May 2014 (UTC)
Oppose The current system of creating a new page and leaving a category redirect on the old page is neither hard nor time consuming, this new tool may make the proses a little faster and more convenient but it hardly seems to hand the potential vandal great powers, I'm a bit puzzled at why so many seem to think it does. I'm also concerned about restriction creep potentially making this project less open. Should we not at least trial this tool and see it it does lead to problems before we introduce restrictions? Oxyman (talk) 21:13, 18 May 2014 (UTC)
Support Common sense solution. Apparently the opposers have forgotten willy on wheels, hagger, and other such copy cats. Allowing anyone to move category pages will just create a rather disruptive mess. - jc37 (talk) 20:08, 19 May 2014 (UTC)
Well, I agree with Oxyman (this also in response to FDMS4, again): The current, unrestricted process of moving a category page already isn't particularly time-consuming. The new feature makes it only a little bit quicker, but really not that much. Again, this feature only affects moves of single category pages, in case that isn't clear enough yet. Gestumblindi (talk) 22:37, 19 May 2014 (UTC)
Oppose I don't see a lot of harm that can be done with the feature and can't be done without it. Since all the files and pages in the category still need to be edited manually anyway, there is not a lot that could be abused. Regards, --ChrisiPK (Talk|Contribs) 15:53, 20 May 2014 (UTC)
Oppose per ^ --Zhuyifei1999 (talk) 06:52, 21 May 2014 (UTC)
Oppose Have trust in common users. If we allow them to move articles at (most) Wikipedias after several days & edits, and we are able to deal with all the vandals there, we will be able to deal with them here as well. Of course, new willys-on-wheels will appear, but they will be a tithe in the overall mass of constructive edits. Certain categories should be protected, just like articles, but a complete restriction on moving category pages will only lead to more garbage cleaning after copy-and-paste moves. On the other hand, such things as Cat-a-lot IMHO should be restricted to e.g. autopatrolled users: a single click, and you've done 200 disrupting edits, F5 — and 200 more and so on... YLSS (talk) 09:51, 21 May 2014 (UTC)
Oppose I'm with Oxyman: Let's try it for a while. If it causes serious problems (on more than just a couple of contentious pages), we can restrict it later. WhatamIdoing (talk) 18:41, 22 May 2014 (UTC)

Alternative proposal: Restrict to autoconfirmed

Looking at the default configuration all users (i.e. everyone with an account) will have the right to move category pages. I propose restricting this to autoconfirmed users. Right now we are already doing this with the right to move pages in the main namespace. Regards, --ChrisiPK (Talk|Contribs) 12:53, 22 May 2014 (UTC)

Support as proposer. --ChrisiPK (Talk|Contribs) 12:53, 22 May 2014 (UTC)

This is already the case, as you need both the move-categorypages and the move permission in order to move a category page. Jackmcbarn (talk) 14:35, 22 May 2014 (UTC)

I see. IMHO we should still move the right to the autoconfirmed group and not leave it at the user group. It will not make a difference for the actual rights of the users but will mean less confusion as currently Special:ListGroupRights shows it next to the user group. Users might wonder why they can't move category pages even though they have that right assigned to them. Regards, --ChrisiPK (Talk|Contribs) 14:42, 22 May 2014 (UTC)

Mass upload of New Orleans Bee (historic newspaper)

Is anyone interested in doing a mass upload of the en:New Orleans Bee issues? They are located here: http://www.jefferson.lib.la.us/genealogy/NewOrleansBeeMain.htm - There is content in French, English, and Spanish. I wonder if there is somebody who can write a script to put these on the commons? (The newspaper closed in 1923) WhisperToMe (talk) 12:39, 18 May 2014 (UTC)

What would that be good for? For one,they are already available somewhere, secondly, what they would need is OCRing, thirdly, this is not possible, because it is largely illegible scan garbage. OAlexander (talk) 20:24, 18 May 2014 (UTC)

Well it's not great, but it's not exactly terrible either; the few scans I sampled are legible enough, and this is, IMO, a historic newspaper worth curating. If there are no objections, I'll volunteer to do the transfer. -FASTILY 21:32, 18 May 2014 (UTC)

Per se, I would assume the matter is pretty well curated as is. A benefit might be obtained by extracting the images from the PDF files. Cheers, OAlexander (talk) 12:06, 19 May 2014 (UTC)

Fastily, thank you! OAlexander, the reason why I'd love to have these on the Commons is because if the jefferson.lib.la.us website goes down or the library removes the images, I want to have a "redundancy" so people can see these newspapers anyway. I am aware of the Internet Archive but if it's down or if somehow jefferson.lib.la.us puts up a robots.txt blocking the archives, I want to have an alternate way of viewing the content. Also, these articles could be used as sources by Wikipedia itself. WhisperToMe (talk) 13:11, 19 May 2014 (UTC)

I agree with WhisperToMe that uploading those newspapers can be useful, and extracting images, as OAlexander suggest might add extra value. We don't need to chose one way since we can have both.--Pere prlpz (talk) 16:08, 19 May 2014 (UTC)

I think it's quite likely that wikisource: folks would assist with transcription sooner or later. I'd be happy to pitch in a little. One thing that's important with his kind of upload is to make sure the metadata is in good shape upon upload, as it can be difficult to go back and track it down (especially if, as WhisperToMe suggests, the source web site goes down or takes these files down). -Pete F (talk) 17:56, 19 May 2014 (UTC)

All of you should be aware that a large number of issue page scans were already previously uploaded (see subcats of Category:The New Orleans Bee by year)... AnonMoos (talk) 00:30, 21 May 2014 (UTC)

Thanks for finding that! I wasn't aware many of them were already uploaded. What may help is to add French and Spanish to the categories and files so people who speak those languages can navigate the files WhisperToMe (talk) 05:27, 21 May 2014 (UTC)

Yes, I was going to suggest exactly that. Thanks for these uploads. Old documents are always useful, if only a reference. Regards, Yann (talk) 15:27, 22 May 2014 (UTC)

May 19

Pirelli

Following a blog post (in french) on the Cracking Wikipedia/Pirelli video, the newspaper has made an article (in french). According to Pirelli's spokeperson, this was a mockup of a proposed operation that did not take place in the end. He blames Havas Digital and says that "it is our intention to support Wikipedia accordingly to the rules of the project" («Il est de notre intention de soutenir Wikipédia dans le plein respect de ses règles de participation» if someone wishes to provide a better translation). Pleclown (talk) 11:10, 21 May 2014 (UTC)

Thanks for the tip! --NaBUru38 (talk) 16:46, 22 May 2014 (UTC)

Free images from the Met

Hi res scans of some of the greatest art in history from the Met. —Justin (koavf)❤T☮C☺M☯ 23:20, 21 May 2014 (UTC)

They're free as in "free beer". So yes, we can use photos that are PD themselves because of age and hi-res scans/reproductive photos of 2-dimensional PD artwork. But we could do that per {{PD-Art}} already. The hype around the Met granting "free access" is completely unwarranted; it's not a free license. See also Commons:Bistro#Le Met libère les droits de 400 000 images. Lupo 15:18, 22 May 2014 (UTC)

May 23

International photos

A journalist from country A goes to an event or interview at country B, takes a photo, and it is published by his newspaper at his home country A. Which copyright law applies? A, B, both? Cambalachero (talk) 12:32, 25 May 2014 (UTC)

Assuming it is not published anywhere else, in most cases it's country A. In particular, when a work is published in a country that is a signatory to the Berne convention and nowhere else, this is the country of origin. However, under Article 5(4), when a work is published simultaneously in several signatory countries (under Article 3(4), "simultaneously" is defined as "within 30 days"), the country with the shortest term of protection is defined as the country of origin (see here for the formal definition for "country of origin"). However, with regards to freedom of panorama, the choice of which country's law applies is not settled; practice on Commons is to retain photos based on the more lenient of the country in which the object is situated and the country in which the photo is taken. —RP88 13:30, 25 May 2014 (UTC)

The law of each country where the newspaper is distributed applies to the distribution of the newspaper in that country. The law of each country where the photo is used applies to that use in that country. -- Asclepias (talk) 15:38, 25 May 2014 (UTC)

May 26

CommonsHelper doesn't transfer old versions ?

I've just used CommonsHelper for the first time, and I was surprised it didn't also copy the old versions of the file. ( :File:Glanusk_ParkDE.jpg -> File:Glanusk_ParkDE.jpg). Is this normal, or is there some box I should have checked to get the history transferred as well ?

If a file has been cropped or colour-adjusted, it's often useful to have the original unadjusted version in the history, in case people want to do the crop or adjustment differently. It's also part of keeping a full audit trail of where the file came from. So I am concerned if this is being lost every time a file is being transferred from WP. (Or, alternatively, if there was an option to keep it that I somehow missed). Jheald (talk) 07:23, 23 May 2014 (UTC)

(Also, how come the bot is not linking to the actual original en-wiki file page? Is that normal too? Jheald (talk) 07:26, 23 May 2014 (UTC))

CommonsHelper and other tools have many issues. See Commons:Requests for comment/Allow transferring files from other Wikimedia Wikis server side for overview. Among them is the fact that file is reuploaded not imported, so the file description edit history and previous image edit history is lost. This is often combined with loss of important details from file description, and loss of categories and resulting image is much less useful than the original. It is unfortunate, but it is a hard problem to crack. We do not link to the actual original en-wiki file page, because shortly after transfer original files are deleted. --Jarekt (talk) 11:58, 23 May 2014 (UTC)

Anyone with even a little bit of programming experience would reach the conclusion that, given the sheer degree of variability and non-standard ways people format file description pages, it it insanely difficult to devise an algorithm that correctly transfers any given file 100% of the time :/ -FASTILY 04:11, 26 May 2014 (UTC)

I saw images where a bot transfered the old versions after a move by re-uploading them as new versions and then reverting to the latest version. It think it was the File Upload Bot by Magnus Manske but I'm not totally sure. Is this bot still active?
Additionally with OAuth in place shouldn't it even be possible to directly upload all old versions using the user's username? Is this worked on? Or is there another reason this isn't (yet) done? --Patrick87 (talk) 15:00, 25 May 2014 (UTC)

To answer the first question, see OgreBot & OgreBot 2. For the second question, yes it is possible, but as far as I know, Magnus isn't working on it at the moment. The amount of text parsing (one of the most confusing/difficult subjects in computer science) involved makes transfer tools complicated and time consuming to write/maintain. Remember that we are all volunteers here, and that most volunteers' time is highly limited. -FASTILY 04:11, 26 May 2014 (UTC)

I see, so I have to trigger transfer of old versions manually using OgreBot and it isn't an automatic task of any bot as I thought initially.
Regarding the automatic transfer of old versions in CommonHelper using OAuth: I didn't intend to sound demanding, I know the "business"

. My question basically was if such a feature was planned (but simply not done or even started yet) or if it is not because of technical reasons. Text-parsing-wise this should however not be much of an issue I assume (I was only talking about old file versions, not old versions of the file description page or similar)? --Patrick87 (talk) 09:35, 26 May 2014 (UTC)

May 25

Category:Rai

Very strange mismatched images belong to the category. What is this category about? A TV station? A pagan religion? A village? Very strange category indeed. Aditya (talk) 15:32, 26 May 2014 (UTC)

Have a look at the categories at the bottom: It's a town. I will put a notice on it. FDMS 4 15:42, 26 May 2014 (UTC)

Should be a disambiguation. The word has different meanings. See Category:Radiotelevisione Italiana, Category:Raï. The category for the French town should be Category:Rai (Orne) like in fr.wp or Category:Rai, Orne like in en.wp. --Sitacuisses (talk) 02:46, 27 May 2014 (UTC)

Changed it into a disambiguation page and moved some of the content to Category:Radiotelevisione Italiana and some of it to Category:Rai, Orne. The only remaining file in the category is File:Sakela Ubhauli 2009, Tundikhel Nepal (3588521516).jpg. I'm guessing it ended up in this category because it has the tag "rai" on Flickr, and people seem to think that it's a good idea to dump images into any and all categories that happen to have the same name as the tags used on Flickr. I'm further guessing that the Flickr uploader is asserting that these young ladies belong to the Rai people, but we don't seem to have a corresponding category, and I'm not terribly comfortable with ethnic classification of people based on such guesswork, so I've left it alone. —LX (talk, contribs) 20:34, 27 May 2014 (UTC)

May 27

Artefacts

This question stems out of a discussion I've been having with Daderot. As you can see there, it has by no means been a heated discussion, but neither has it been one where we are sure what should be done, hence bringing it to this broader forum.

I fully agree with the use of Category:Artefacts for objects found in archeological digs. However, it seems to me that for various cultures, we've ended up using this term for things where we would never use it in a Western or major East Asian culture, and that the result is accidentally condescending. For example, File:Raven screen detail 01.jpg is in Category:Tlingit artefacts. It is certainly not an archeological artefact—as I understand it, it went straight from being part of a building into the hands of a collector and thence to a museum—it is certainly a work that we would call "art" if it came from a European, European-derived, or East Asian culture, and it can be confidently attributed to a particular known individual. (The Seattle Art Museum, perhaps somewhat uncommonly, has been diligent about trying to attribute their Native American works to individuals, and unlike some parts of the U.S. the native cultures of the Pacific Northwest have enough continuity that this has largely been possible.) To quote something I said in the prior discussion with Daderot:

I think the problem may be the very existence of a single category that embraces both mundane objects and even the highest art of a culture. Contrast, for example Category:Art of France vs. Category:Clothing of France vs. Category:Crafts of France vs. Category:Products of France. I'm not sure what would be the correct solution, but I'm pretty sure that people would be appropriately offended if we lumped all of those under a Category:Artefacts of France.

Basically, the problem seems to me that we treat some cultures from an "insider's" point of view and others from an anthropologist's. I'm not sure exactly what is the correct solution, and the specific concept of "art" is not entirely simply cross-cultural, but I'm pretty sure we should have categories that treat objects created by Native American cultures the same way as objects created by European, European-derived, and East Asian cultures. - Jmabel ! talk 05:56, 27 May 2014 (UTC)

Further complicating matters, at least at present Category:Tlingit artefacts is only under Category:Tlingit, with nothing at all except the name of the category to tie it to anything even about these being objects (that is, nothing in the hierarchy takes it that direction). - Jmabel ! talk 05:58, 27 May 2014 (UTC)

Hibachi style restaurants

Would anyone be opposed to a Hibachi style restaurants category? I had several photos of restaurants that I had placed in the Habichi category but they had been removed. File:Hibachi Express (formerly Whataburger), Valdosta.JPG, File:Hibachi Express, Rowland Dr, Moultrie.JPG --Mjrmtg (talk) 12:34, 27 May 2014 (UTC)

I'm not sure if there minimum requirements but I tend to follow the Ancient and Not-so Sacred Rule of Three, such that if there are at least three files that could be categorized together then it is worthwhile having such a category. Other people may have other strictures but unless you have something fiendishly dangerous in mind, I'd say go for it. Green Giant (talk) 14:00, 27 May 2014 (UTC)

Having the restaurants in Category:Hibachi doesn't seem the best idea (since that is used for the heating bowls), but a separate restaurant category would be appropriate. Personally, either by two or three images might I create a category, especially if it could grow to several more in the future. Chris857 (talk) 19:51, 27 May 2014 (UTC)

Would Category:Hibachi style restaurants go under possibly Category:Chinese style restaurants or Japanese? Don't mean to offend anyone, but I don't know what kind of cooking it is, personally. Just seen several Hibachi restaurants (more than 3 actually). --Mjrmtg (talk) 21:27, 27 May 2014 (UTC)

It is Japanese, although I suppose there could be Hibachi style restaurants that have other cuisine. --Auntof6 (talk) 21:31, 27 May 2014 (UTC)

Maps from categories

May 28

Translation request

For Spanish and Brazilian Portuguese versions of the English at Category:Unidentified Passeriformes (Neotropical), please. Thanks! - MPF (talk) 15:46, 1 May 2014 (UTC)

Why is generic Spanish good enough for this, but you insist on a particular kind of Portuguese? (Why indeed the extant English version is in generic English and not in Guyanan English, too?) On the other hand, how can a couple (2) of simple unidiomatic phrases (not even sentences), consisting mostly of Latinate zoological names, have any meaningful variation from a particular kind of Portuguese to another? -- Tuválkin ✉ 18:34, 1 May 2014 (UTC)

Because I'm aware of a code at Commons for pt-br, but don't know of any existing for Latin American version(s) of Spanish. If you know of any, please add it/them! Ditto, there is no en-gu (en-gy?) code. Of course, if anyone can add translations in other S American languages, please do. - MPF (talk) 19:47, 2 May 2014 (UTC)

Your ironymeter is broken: Obviously localization of language variants in this case (and in many others) is unnecessary and needlessly raises problematic issues. I added a translation of the text in unspecified Portuguese (that is, plain pt, not pt-BR, nor pt-PT, not pt-AQ, nor any such nonsense); feel free to delete it. -- Tuválkin ✉ 03:46, 3 May 2014 (UTC)

If you look at open source projects, you'll find that any that has been well-translated will have separate Brazilian Portuguese and Portuguese translations. I don't know the linguistic reasons, but it's clear the linguistic communities feel a need for separate translations. If we're going to snark, I might snark about the need for Swedish, Nynorsk, Bokmal and Danish to all have different translations, or a number of other language pairs that could quite well support one common language standard.

es-419 is the tag for Latin American Spanish. I don't know that Commons supports it. The language code for Guyanan English would be en-GY; I'm not sure where it would be necessary.--Prosfilaes (talk) 20:45, 6 May 2014 (UTC)

Prosfilaes, you wrote: «I don't know the linguistic reasons»; well, you obviously got that part right if you think that the variation of Portuguese dialects (even if we were including Galician and idiosyncratic variants spoken by diglossiac non-native speakers, instead of merely BR vs PT) is comparable to modern Continental Scandinavian (my own surprise at seeing nynorsk bagged along the other three shows how well I know about that matter). Telling apart pt-BR and pt-PT is useful (even though misleadingly simplistic, as hinted above) when tagging text or voice samples; prescribing separate UI text for pt-BR and pt-PT instead of striving to be as much as possible dialect-neutral is needlessly forcing the community to a double effort which will, at beast, produce mixed results. I’ll be therefore snarking when and wherever it pleases me, including at the presence of a separate "pt-BR" (as opposed to a plain "pt", not to a "pt-PT" or some such) as an option for Mediawiki UI, for wich a single "en" and a single "fr" are apparently enough (not to mention a single "de" and a single "it", which is a major Linguistics fail). -- Tuválkin ✉ 02:14, 12 May 2014 (UTC)

If you don't know about Nynorsk and Bokmal, I don't how you can compare Portuguese to them. The fact that you think there's a single "it" is a major linguistics fail; I suggest taking a good look at that list of languages again, for things like nap, etc. Likewise, Galician has its own tag, gl.

Brazil has a population of 200 million, and thus pt-BR is around the sixth most spoken language in the world. That's a very viable translation target. Portugal has about 10 million speakers, and thus is not much of an impact on whether pt-BR is a successful translation target. It is really up to the European Portuguese speakers as to whether they are willing to abandon the distinctive and globally rare features of their dialect for a unified translation. Given the existence of the separation, I'm going to assume they aren't.--Prosfilaes (talk) 03:15, 12 May 2014 (UTC)

You brought over the comparison with Scandinavian languages, not me — it is not productive in this context. Your 200 vs 10 argument is trumped by the fact that 210 is greater than either (not even mentioning that there are more to this than just PT+BR, as said). The «unified translation» whose lack you blame on an “European Portuguese” cabal is exactly what I said is necessary, and what is thwarted by the very existence of two separate versions of pt in Mediawiki (whose full list of languages I failed so far to locate). My point in this thread is exactly that such «unified translation» is not only desirable and possible but also almost unavoidable in this context, as proved by my translation of the text in question — and thus my criticism of MPF’s call for a specific pt-BR version, not a generic pt one. Your advice about «what is really up to the European Portuguese speakers» to do and about «the distinctive and globally rare features of their dialect» is so ridiculous it is not even offensive — try the same sentence but swapping Brazil to the US and Portugal to the UK and relive the WTF+LOL moment I had when reading your rant above. -- Tuválkin ✉ 06:36, 12 May 2014 (UTC)

If adding the translators from Portugal to those from Brazil causes even one in twenty of the later to leave, then no, you won't have more translators after the combination. The Brazilian Portuguese translations have decided to work on separate translations, which implies they weren't happy with working with the translators from Portugal, that most likely the standards for most pt translations include those dialectal features which are distinct to Portugal and exclude those that are distinct to Brazil.

You'll find that most open source translations for en use "color", and en does represent the single largest English native speaker community, which is why swapping US for Brazil and UK for Portugal doesn't work. The issue is not the largest speaker community feeling compelled to do separate translations.--Prosfilaes (talk) 01:57, 13 May 2014 (UTC)

If Brasilian translators do not wish or do not feel confident producing pt texts, then – if the language selector works well – it is quite seasonable to mark the texts pt-BR. The Portuguese will in most cases understand the text and any translator can make the changes necessary to get also a pt or pt-PT one. If no changes are necessary (as probably in many cases), the label can be changed to pt (having identical pt and pt-BR entries is not necessary for users, but if editors insist it is not too much an overhead in this single case). But I find a translation request for pt-BR quite offensive, like requesting en-GB: why exclude the Portuguese translators and users? (For the no and nn case, I would not work on translations between those two for subjects not important for Norway. Those who understand one of these usually understands the other as well.) --LPfi (talk) 06:45, 13 May 2014 (UTC)

The category is (as should be obvious) of specific relevance to Brazil, and other countries in South America, and not to Europe. That is why I asked for a pt-br translation, rather than a general pt translation. I'm also still waiting for a Spanish translation, if someone can provide it please; Spanish as used in Latin America is obviously preferrable. - MPF (talk) 23:44, 15 May 2014 (UTC)

Read again what was exposed above, will you? Asking for a specific pt-BR translation for this situation is silly, as the text contains nothing that would vary in any variation of the language: it is but a string of Latinate zoological names and some trivial phrasing. If the tagging is accurate, it is always better to go for the more generic pt than a more specific pt-BR. I challenge you to retag my contribution as pt-BR, though, or to delete it. (That would be pointy vandalism, to be deal with appropriately.) Your call for a specific Latin American Spanish version is equally misguided. -- Tuválkin ✉ 11:26, 22 May 2014 (UTC)

Please don't challenge people to commit acts of vandalism. You're making this awfully personal.--Prosfilaes (talk) 01:56, 24 May 2014 (UTC)

A language is a dialect with an army and a navy. So long as translators of Brazilian Portuguese choose to label their language distinctly from that of Portuguese of Portugal, I find taking offense here to be much like taking offense when someone asks for a Scots translation.--Prosfilaes (talk) 10:08, 22 May 2014 (UTC)

«So long as translators of Brazilian Portuguese choose to label their language distinctly from that of Portuguese of Portugal»? Citation needed (hint: they don’t). The fact that some curmudgeon managed to dupe some outfits to accept a separate pt-BR tag while the same outfits would never accept en-US or fr-CA in the same standing only proves the existence of dupable outfits. You also seem to assume that generic pt equals pt-PT, which is claimed by nobody standing on this side of the sanity line. -- Tuválkin ✉ 11:26, 22 May 2014 (UTC)

Compare https://l10n.gnome.org/teams/pt_BR/ to https://l10n.gnome.org/teams/pt/ (where pt-BR is better translated then pt) , and then https://l10n.gnome.org/teams/es_MX/ and https://l10n.gnome.org/teams/es/ (where es-MX is a nonentity). If it was just some curmudgeon, pt-BR couldn't be better translated then pt. On my Linux box, there are 6 MB of pt-BR translations compared to 4 MB of pt translations. Trying to deny the fact that a lot of translators choose to spend their time working on pt-BR instead of pt seems bizarre. I suppose if you deny that fact, it's pretty hard to figure what pt translations stand for in practice.

Please don't complain about beating a dead horse and dump 1.4k of text on it. If it's live enough for you to argue, it's live enough for us to argue.--Prosfilaes (talk) 01:56, 24 May 2014 (UTC)

Yes, curmudgeons can generate a lot of text, just scroll above. But is there any reason for that? Is it as widespread as you claim? If so, where is your separate pt-BR and pt-PT wikipedias? As for your Gnome example, once a separate pt-BR was created, it logically attracted the efforts of Brazilian volonteers (of which there are statistically more of) — it doesn’t prove these translated wouldn’t prefer to work in a single non-dialectal pt version. Are you saying that es-MX is “identical” to plain es but pt-BR magically needs a separate translation effort? That’s linguistically rubbish, even if 200 million Brazilians or 10 million Portuguese were claiming otherwise (hint: they obviously are not — only a few curmudgeons are, usually along with some other, far less harmless talking points: we don’t want to go there). One single pt translation is enough for most goals (surely it is in the OP). Besides, you keep conflating pt with pt-PT. That’s very problematic, please stop. -- Tuválkin ✉ 05:28, 24 May 2014 (UTC)

I gave you data points, both Gnome and a general Linux system that has 150% as much pt-BR translations as pt translations, so don't waste my hand with handwaves. A request to open up a pt-BR Wikipedia would fail because Wikimedia policy is not to create multiple projects with the same ISO 639-3 code.

We used to have a Moldovian Wikipedia. We don't any more, because Moldovians would rather work on the Romanian Wikipedia despite the "logical attraction" of a Moldovian Wikipedia. That's the point of the es-MX reference; that just because a project is labeled Mexican Spanish, doesn't mean that Mexican translators will insist on translating for es-MX instead of es. If translators would prefer to work in a single non-dialectal pt version, then they would work in a single non-dialectal pt version.

If the Brazilians are irresistibly lured against their real desires to work on pt-BR, then the translators working on pt are mostly Portuguese, as I'm pretty sure the remaining Portuguese-speaking nations are not major players on the Internet. I also suspect that few Portugal Portuguese translators are going out of their way to try and avoid words and phrases specific to their dialect. When there's two active translation teams, a pt-BR and a pt team, the pt team is in practice going to be pt-PT.--Prosfilaes (talk) 10:36, 24 May 2014 (UTC)

Guy, you know nothing about the matter and yet you insist on drawing conclusions from your Gnome “data points” and on your preconcieved notions. Try to at least focus on the matter here and explain why it is useful for the project to ask for a specific pt-BR translation of a piece of text that consists solely of simple unidiomatic phrases (not even sentences), containing mostly Latinate zoological names. This is not the venue to address the wider matter, about which you seem much more keen on winning a thread than on educating yourself. -- Tuválkin ✉ 13:04, 25 May 2014 (UTC)

Yet another fact-free post. What is it, when you're losing, pound the table? Tell me I should educate myself, but provide noise instead of fact? pt-BR is frequently translated as a separate language, therefore asking for a pt-BR translation is not unreasonable. If someone is asking for a translation, they have probably don't have the linguistic knowledge to know whether or not it will be distinct from other languages. Though I don't see you getting so fussed if someone asked for a Portuguese translation of a painting titled "Mouse", even if it was already translated into Spanish.--Prosfilaes (talk) 23:00, 25 May 2014 (UTC)

For Lusophone volunteers the existence of two types of Portuguese, that the same guys will maintain both, is just a double work to do, which is hardly being done... Almost all pt and pt-br pages are outdated... so pleas, I'm will start to beg, stop using pt-br, forget that. From a Brazilian guy. 23:00, 27 May 2014 (UTC)

May 02

Is this copyright status acceptable in Commons?

Hi,

There are loads of pictures released by Press Information Bureau, Government of India at http://pib.nic.in/newsite/mainpage.aspx The copyright message of the website states that:

Material featured on this website may be reproduced free of charge and there is no need for any prior approval for using the content. The permission to reproduce this material shall not extend to any third-party material. Authorisation to reproduce such material must be obtained from the departments/copyright holders concerned. The material must be reproduced accurately and not used in a derogatory manner or in a misleading context. Wherever the material is being published or issued to others, the source must be prominently acknowledged.
— http://pib.nic.in/newsite/terms.aspx#copyright

So is this acceptable in Commons? If so I propose to add a new template so that these images can be uploaded here. --Jayarathina (talk) 06:06, 27 May 2014 (UTC)

I would say it is not acceptable and falls under Commons:Image casebook#Press photos. Specifically Commons requires that the images can be freely modified and the "The material must be reproduced accurately" clause forbids that. MKFI (talk) 06:27, 27 May 2014 (UTC)

Thanks a lot for the clarification. --Jayarathina (talk) 06:56, 27 May 2014 (UTC)

It was accepted before at Commons:Village_pump/Copyright/Archive/2014/02#License_and_copyright_for_Indian_government_documents and various DRs were then closed as Keep. But some have also been closed as Delete previously Commons:Deletion requests/File:Dharmendra padma bhushan.jpg. Am still not clear on what is to be done about these images and they are now increasing in a vast number. §§Dharmadhyaksha§§ {T/C} 06:25, 28 May 2014 (UTC)

Media Viewer launches on Commons this Thursday

Media Viewer lets you see images in larger size

The majority of users find Media Viewer useful.

Greetings! As discussed in earlier posts, Media Viewer is scheduled to launch on Commons this Thursday, to provide a better viewing experience to our users.

Media Viewer has been tested extensively on many large wikis around the world, and the feedback collected from thousands of users suggests that this tool is generally useful to them, as outlined in these survey results. More importantly, the rate of favorable feedback keeps increasing across all languages over time: for example, the French approval rate started out at about 64% a few weeks ago, and is now up to 70%, which is very encouraging.

Here on Commons, over 1,344 Commons beta users have been testing it, since the tool was first deployed as a beta feature in November 2013. Thanks to all this helpful feedback, Media Viewer has been greatly improved in recent months and we are now getting ready to roll it out on all wikis worldwide.

Media Viewer will be enabled by default on Wikimedia Commons this Thursday, May 15 at about 20:00 UTC. We are devoting an entire release to Commons, so we can keep a close eye on this deployment, given the site's importance to our movement. The tool will then be released to some of our largest wikis the following Thursday and to all wikis the following week, as described in this release plan.

Please let us know if you have any questions or comments about Media Viewer, which you can test here in beta, or learn more about on this Help page (which includes tips for bypassing this tool, or turning it off in your preferences). You are invited to share your feedback in this discussion here on Commons. You are also welcome to take this quick survey -- or join this in-depth discussion on MediaWiki.org, as you prefer.

Many thanks to all the community members who helped make Media Viewer possible! This tool was created with active community participation from its early planning phase -- all the way to its final release. This was a really productive partnership, which we hope to build on for future projects. Fabrice Florin (WMF) (talk) 00:44, 13 May 2014 (UTC)

I raised a critical complaint which is not attended so far. J e e 03:39, 13 May 2014 (UTC)

Jee, apologies for our lack of response to your post over the weekend. We'll have an answer about your issue on the Mediawiki talk page once the issue is fleshed out. Keegan (WMF) (talk) 07:10, 13 May 2014 (UTC)

For those that don't care to wander over to MediaWiki to follow the response: We're going to have multiple licensing fixed by the time we finish this iteration of Media Viewer. Everyone can follow the completely public Multimedia Team's Mingle card for work tracking. Thanks! Keegan (WMF) (talk) 05:22, 14 May 2014 (UTC)

Thanks. J e e 06:01, 14 May 2014 (UTC)

@Keegan (WMF): Why you use Mingle (it is not possible for users to register a Mingle account)? Why not Bugzilla? --Steinsplitter (talk) 10:19, 14 May 2014 (UTC)

Here I edit once more, what I wrote in Mediawiki in the passed night:

Disagreement

I consider the old solution much more useful: You open the "article" of the file and get all information, unfiltered, and all possible resolutions as well.
If visitors use a browser that is already some years old, the Media Viewer doesn't work at all. That is the opposite of optimal web accessability.

((concerning the other site of this edit:)) I know that this "report" is not thought as a forum for discussions, but on the layout of the headlines we have just suffered an obscure decision made in secret chambres. ((:return to the thread))

The construction of an evitable barrier called "Media Viewer" in a kind of newspeak is much more serious. it is an attack against the freedom of information.--de:user:Ulamm/en:user:Ulamm/es:Usuario:Ucordero, 2014-05-14, 02:45 CEST

Furthermore, the assessment of the "voting" is anything but just, as the subgroup of those, who decide to try beta-versions, is not representative at all.--Ulamm (talk) 11:33, 14 May 2014 (UTC)

Thank you all for your helpful feedback!
- Jee, you'll be glad to hear that support for multiple licenses (#567) is now the highest priority ticket in our current cycle, and we aim to take it on in our next weekly sprint, so it should be addressed in a few weeks.
- Steinsplitter, we use Mingle now because it is a much superior project management tool than Bugzilla -- but we bring over the most important Bugzilla bugs into Mingle regularly, so you can keep using it to report technical issues; in coming months, we hope to convert to Phabricator, where all these tools could be implemented in a single environment.
  - @Steinsplitter: To be less subjective and a little more verbose, Mingle is useful to us mostly because of its planning tools, and its flexibility. Bugzilla has a lot of the features that Mingle has, but not all of them. We use it because it's a more convenient project management tool, especially for people not familiar with Bugzilla, and not because it's proved itself superior on all fronts. We continue to discuss a move to Phabricator at mediawiki.org, which should bring things closer to the community over time. --MarkTraceur (talk) 15:17, 15 May 2014 (UTC)
- Ulamm, we appreciate your feedback, though we could not find any conclusive evidence that Media Viewer is "an attack against the freedom of information", as you suggest. Also, the survey data we collected so far is from thousands of users on large wikis where Media Viewer is enabled by default, such as the Dutch, French, Portuguese and Spanish Wikipedias: so these responses seem quite representative of the user groups whom we serve (readers, editors and active editors) -- and only a very small percentage of responses from other sites are from beta users (e.g. English or German Wikipedias).
- Overall, the majority of users on enabled sites find Media Viewer useful -- and last week's releases show the most positive responses to date (82% of Portuguese users like the tool, vs. 79% of Spanish users, which is quite encouraging). So we view this feedback as confirmation that this tool is adding value to our wide community, across all languages. Hope this helps :) Fabrice Florin (WMF) (talk) 18:52, 14 May 2014 (UTC)

@Fabrice Florin (WMF): While I don't think the Media Viewer is a bad idea per se, I also doubt the survey is as representative as you like it to be. Have you considered that those who do not consider Media Viewer useful have probably disabled it right after it's launch and might have never seen the link to the survey? For example I (while I'm from German Wikipedia where it's not enabled by default I tested Media Viewer on dewiki, enwiki and mediawiki as a beta feature) found Media Viewer not to be useful for me and disabled it again while never being aware of the survey where I could have stated my opinion... --Patrick87 (talk) 19:36, 14 May 2014 (UTC)

Patrick87, thank you for bringing this up because it's an excellent point about the survey and one that Fabrice and I have discussed. We're looking into approaches of gathering and then measuring this kind of data (how many people are disabling it, what are the time periods until disabling, was it even used before being disabled). Once we have that information we can start seeing the scale of this kind of activity. We can go from there for outreach on further development of the Viewer for the next release cycle from those that disabled it. Keegan (WMF) (talk) 21:31, 14 May 2014 (UTC)

It's horrible! How can I turn it off, so I can get to the image page like I used to? - MPF (talk) 23:48, 15 May 2014 (UTC)

As always with "features" introduced by Wikimedia: where the hell is the button "get rid of this crap and keep old appearance"? --AndreasPraefcke (talk) 12:50, 16 May 2014 (UTC)

Nicely put ;-)) Found it - go to 'Preferences' (next to your talk page link), click on 'Appearance' there, scroll down to 'Files', and de-tick 'Enable new media viewing experience'. That does it. But yeughk! "Enable new media viewing experience" talk of hideous Newspeak! - MPF (talk) 13:03, 16 May 2014 (UTC)

Thanks for sharing that, I found it most helpful, don't get me wrong this is a good feature that I think many will appreciate, it just doesn't suit me Oxyman (talk) 16:13, 16 May 2014 (UTC)

Actually I think this label should be changed since it's misleading and imprecise. How can one activate an experience? What should a "new media viewing experience" be? What was the "old media viewing experience" anyway?
The tool is called "Media Viewer" and that (and nothing else) should be reflected by the corresponding setting: "Enable Media Viewer". Could you take care of this Fabrice Florin? --Patrick87 (talk) 17:17, 16 May 2014 (UTC)

Thanks, Patrick87, that seems like a reasonable idea, which shouldn't be hard to implement. Do others here agree this would be a useful improvement? For now, I posted this ticket #622 for this change request, and will discuss it with the team next week. Thanks again for suggesting this improvement :) Fabrice Florin (WMF) (talk) 20:46, 16 May 2014 (UTC)

I think "Enable Media Viewer" is a much better choice. Keegan (WMF) (talk) 22:30, 16 May 2014 (UTC)

1) Is there any way from the media viewer back to the file page? If so, it is certainly not obvious and should be more prominent. Extremely unobvious how you get from the media viewer to any ability to edit.

2) In the media viewer, if you click "Use this file" you get a bare link with no credit and no licensing information. This is pretty much asking for copyright violations, because reusers won't have any obvious way to get credits for a photo. As a contributor of tens of thousands of images to Commons, hundreds of which (probably thousands of which) have been reused in various media, this concerns me greatly. Surely it is not WMF's intent to encourage illegal reuse, but that will certainly, and I do mean certainly, be the effect of this. - Jmabel ! talk 15:53, 17 May 2014 (UTC)

Jmabel,

1. You get back to the file page by clicking on the Commons icon in the bottom right corner, where the hover-over says "More details." This could probably be a bit more intuitive.

Yes. Like "File page", which is what it's called. - Jmabel ! talk 05:49, 21 May 2014 (UTC)

2. "Use this file" is one of the last pieces of the puzzle we're putting into place. We want to make sure we get it right by the time we are completely global in a few weeks. HTH, Keegan (WMF) (talk) 03:38, 18 May 2014 (UTC)

Credit line

I've now found that this Media Viewer completely ignores the credit information which is presented by our "{{Credit line}}" template. This is the more stupid as this template was created especially to make it easier for re-users to properly credit images which require attribution. See for example File:Arena AufSchalke Innen bei Konzert.jpg which is used en:Veltins-Arena. I've left a comment at the Mediawiki discussion. --Túrelio (talk) 18:20, 17 May 2014 (UTC)

I filed a bug for this. The team will talk about it; thanks for bringing it up. Keegan (WMF) (talk) 03:38, 18 May 2014 (UTC)

OK, this is the first I have heard of the "{{Credit line}}" template. I have over 30,000 uploaded images. All should have an author line in the {{Information}} template and should have a license, but not all have the same license because the older ones all have GFDL, some images were transferred from Commons and therefore have a different version of CC-BY-SA, etc. Is there some way, without my making many thousands of hand-edits, for me to add an appropriate {{Credit line}} to my various file pages? - Jmabel ! talk 16:02, 18 May 2014 (UTC)

Unfortunately I can't answer that question. But I'm curious, now: do you feel that support for the Credit line template is necessary, or is everything we're pulling from Information sufficient? In your opinion of course. I'd like to hear from others as well. There are other technical solutions that aren't on our end for this, perhaps. More background on Bugzilla. Keegan (WMF) (talk) 21:00, 18 May 2014 (UTC)

If you can pull from the information in such a way as to compose an appropriate credit line, totally great. The information is clearly there, at least on all of mine. But, for example, at https://commons.wikimedia.org/wiki/Category:PURE_Cirkus_at_Summer_Solstice_Parade_and_Pageant_2007#mediaviewer/File:Fremont_Fair_2007_pre-parade_Pierced_Circus_08.jpg (one of mine) if you click on the "Use this page" icon, it just says "https://commons.wikimedia.org/wiki/File:Fremont_Fair_2007_pre-parade_Pierced_Circus_08.jpg#mediaviewer/File:Fremont_Fair_2007_pre-parade_Pierced_Circus_08.jpg" and "Copy and freely share the link". I guess that's not the worst thing it could say, but that is just what they'd get by copying from the URL field of their browser. It seems to me that almost anyone who wants to do just that already knows they can copy & paste a link from their browser. What we need is information for people who want to reuse it by embedding, as to how to do that in accordance with the license. I find that even the well-intentioned often fail to do anything more than my name and "Wikimedia Commons" or some such, with no idea that they are supposed to even mention a license. - Jmabel ! talk 05:41, 19 May 2014 (UTC)

Jmabel, I don't know whether I understand your question properly. But I had added "crditline" to my existing works with the help of COM:VFC. I too have various licenses; so play a bit with the help of VFC to filter works with same license first. Earlier {{Information}} tag has no Other_fields; so we need to add it too. (I'm using custom creditlines; but similar to the generic one.) J e e 06:16, 19 May 2014 (UTC)

I use Visual File Change, too, but it seems to me that this would not be the easiest regex to construct, especially because some of my files have the license within the {{Information}} template and others have it in a separate section, some {{Information}} templates may already have an "other fields" value, etc. And as far as I can tell, VFC requires me to describe things in a single regex. - Jmabel ! talk 03:03, 20 May 2014 (UTC)

I am not sure why you want to add a {{Credit line}} − it is meant for folks who want more complex attributions than <author> − <license>. In your case, as far as I can see, your name is provided through the <attribution> parameter of the license template so you should (as in, a properly working tool should, which MediaViewer is not completely yet on that regard) end up with « Joe Mabel, CC-By-SA ». If you are happy with that, no need for Credit line :-).

(Basically: Credit line was created also because our tools were dumb. We can try to make smart tools and avoid putting the burden on users to edit their 30K uploads :)

Jean-Fred (talk) 07:54, 20 May 2014 (UTC)

Going back to earlier in the dialog: my problem is that "Use this file" lacks any credit line at all. It should be there. Someone above suggested it should pick that up from the Credit Line template. That seemed to be acceded to. If that is how this will be done, then I will need to add that template. If, as I think is reasonable, in the absence of that template it can be picked up from the standard fields in the Information template, far simpler for me. But, again, the issue I raised in the first place, and stand by: anything focused on reuse that simply shows a bare URL is an invitation to copyright violations. It is sufficiently so that we would do better to eliminate that field until it can be fixed. - Jmabel ! talk 15:45, 20 May 2014 (UTC)

Agree. A tool for reusing should make legal reuse easier. If legal reuse in some cases requires getting information in other ways (as in visiting the file page) and the tool does not warn about those cases, then those wanting to reuse images legally would have to check every time, which hardly makes the tool useful for them. As long as you use the provided links (to the file page at Commons) it seems you are as legal as Wikipedia, but if you download the image via the reuse dialogue, it is critical that the credit line shown by the media viewer is sufficient (in fact, encouraging people to download the description page along with the image file, would probably be very good). --LPfi (talk) 10:07, 24 May 2014 (UTC)

@Jmabel: : "my problem is that "Use this file" lacks any credit line at all." I think you missed some points. "Use this file" has three options; share, download or embed.

"Share" is intended for just URL sharing in FB, twitter, etc. Whenever we share a Wikipedia article or any other website URL, usually we do not attribute the authors with the link. People who visit those pages will find the authors/attributions.

I checked "Embed" html and it says "Tabernaemontana divaricata at Aanakkulam" by Jeevan Jose - Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons which is perfectly OK for me. (Title with a link to source, author name with a link to author profile page and license name with a link to the deed or legal code. I don't like the via part though.

)

So I think attribution is well picked from the "author" and "license tags" without depending on the "creditline". J e e 03:21, 27 May 2014 (UTC)

Then those options need to be a lot more visible. I've turned this thing off for myself, so I can't even look at it now, but I sure didn't have any "embed" option leap out at me. But furthermore, just the single words "share" and "embed" are not clear enough ("download" is). - Jmabel ! talk 15:30, 27 May 2014 (UTC)

Agree; so pinging Keegan (WMF) for attention. J e e 02:18, 28 May 2014 (UTC)

Yup yup, thanks for the ping, Jee. Keegan (WMF) (talk) 06:18, 28 May 2014 (UTC)

To make matters worse, some templates, such as {{Cc-by-sa-3.0-de}} have a credit line parameter built in (I'm not sure if it internally uses {{Creditline}}. The cc-by licenses allow the author to specify the way they want to bet credited. In short, if we take that away from them, by ignoring specific attribution requirements we are violating their license! We made the choice to offer cc-by to our authors and we owe it to them to fully respect their attribution choices. --Dschwen (talk) 03:35, 28 May 2014 (UTC)

It uses {{Cc-by-sa-layout}}, which wraps the attribution in a span with class="licensetpl_attr". Hope {{Credit line}} does the same... --Dschwen (talk) 03:44, 28 May 2014 (UTC)

Nope, looks like it doesn't. Well, that would make it pretty freaking useless. *shakes head* --Dschwen (talk) 03:47, 28 May 2014 (UTC)

Ouch, that's quite a crazy little bit of template inclusion and wrapping. Thanks, Dschwen. Keegan (WMF) (talk) 06:30, 28 May 2014 (UTC)

Unless I am mistaken, all of this is documented on Commons:Machine-readable data.

As for the fact that {{Credit line}} uses a different mechanism: I had started to take some steps to harmonize this ; but frankly the discussion on bugzilla:57460 has left me more confused on what should be done.

So either we patch CommonsMetadata so that it takes the current mechanism of Credit line, or we patch Credit line to use the same classes than |attribution= − frankly I don’t care but let’s do something about it, yeah. Jean-Fred (talk) 08:15, 28 May 2014 (UTC)

Right now the class parameter is applied to the title field in {{Information field}} which is not what is needed for semantically marking up the value. A quick fix would be to explicitly wrap the template parameter in a span tag before passing it to the template. --Dschwen (talk) 17:48, 29 May 2014 (UTC)

Done. As I had warned in December, I {{Information field}} to allow to add a span tag, and edited {{Credit line}} to use it. The credit line is now wrapped in a class="licensetpl_attr".

Jean-Fred (talk) 22:06, 29 May 2014 (UTC)

Commons:Village pump/Archive/2014/05