Shortcut: COM:VP

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Template: View   ■ Discuss    ■ Edit   ■ Watch

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Just to clarify something, this particular problem (Lots of large tiff files uploaded very quickly causing the image scaling servers to become overloaded [1]) 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I found a similar one: EbaySmiley.toerist (talk) 13:31, 4 May 2014 (UTC)[reply]

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".[5] 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)[reply]

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" [6] 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 [7]. 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 [8]), 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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

[OK] 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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

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

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)[reply]

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

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

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)[reply]

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)[reply]

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

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)[reply]

[[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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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?

1. [[en:National City Bank Building|National City Bank Building]]
2. [[en:55 Wall Street|55 Wall Street]]
3. [[en:Isaiah Rogers|Isaiah Rogers]]
4. ''[[en:AIA Guide to New York City|AIA Guide to NYC]]''
5. ''[[en:AIA Guide to New York City|AIA Guide to NYC]]''
6. [[en:AIA Guide to New York City|AIA Guide to NYC]]
7. ''[[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:

4. '
5. '
7. '

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)[reply]

[[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)[reply]

• 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)[reply]

Say I owned one of these [11] 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)[reply]

• 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)[reply]
  • 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)[reply]

• 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)[reply]

• 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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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.

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)[reply]

• 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)[reply]

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)[reply]

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[12] and is it an approved research survey? --Fæ (talk) 14:52, 9 May 2014 (UTC)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

[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)[reply]

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

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Maury Markowitz, you need these:

• http://www.google.pt/?q=%22chain+home%22+site:commons.wikimedia.org
• http://www.google.pt/?q=%22ski+boots%22+site:commons.wikimedia.org

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

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)[reply]

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

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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) Jee 05:11, 11 May 2014 (UTC)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]