Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to: navigation, search
  Welcome to Commons   Community Portal   Help Desk
Upload help
  Village Pump
copyright • proposals
  Administrators' Noticeboard
vandalism • user problems • blocks and protections
 
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
This project page in other languages:

Alemannisch | العربية | asturianu | Boarisch | български | català | čeština | dansk | Deutsch | Ελληνικά | English | Esperanto | español | فارسی | français | galego | עברית | hrvatski | magyar | íslenska | italiano | 日本語 |  | 한국어 | Lëtzebuergesch | македонски | मराठी | Nederlands | norsk bokmål | occitan | polski | português | русский | slovenčina | slovenščina | српски / srpski | suomi | svenska | ไทย | Türkçe | 中文(简体)‎ | 中文(繁體)‎ | Zazaki | +/−

Welcome to the Village pump

This Wikimedia Commons page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. For old discussions, see the Archive. Recent sections with no replies for 3 days may be archived.

Please note


  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing please do not comment here. It is a waste of your time. One of Wikimedia Commons' basic principles is: "Only free content is allowed." This is just a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read the FAQ?
  3. For changing the name of a file see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page


Search archives


 


Centralized discussion
Proposals Discussions Recurring proposals

Please help by translating these messages into other languages.
Note: inactive discussions, closed or not, should be archived.
Archive  • Discussion • Edit • Page history • Watch
Broadwick St, Soho, London: a water pump with its handle removed commemorates of Dr. John Snow's tracing of an 1854 cholera epidemic to the pump. [add]





Oldies[edit]

Terrible choice of filter being used for image downsizing.[edit]

I've recently uploaded File:Engraving after Matthew Paris drawing of John of Wallingford (1255).jpg, which is an 1890s line engraving.

I was appalled at the amount of aliasing being shown in the Commons thumbnail. At this scale (434 × 599 pixels), the apparent horizontal lines are misleading artefacts, created by a poor choice of filter when the image has been downsampled, that should not be visible. At this scale the background of the image should instead appear to be a uniform grey.

The introduction of artefacts of this kind should not be acceptable. They can easily be avoided, eg by specifying that a Lanczos filter or a Mitchell filter should be used when doing image size reduction. (ImageMagick has code that gets this right; GIMP may be broken).

We should not be trashing the appearance of our images like this. Jheald (talk) 18:08, 8 April 2014 (UTC)

If you have found better ImageMagick parameters/settings for creating thumbnails than the currently used ones, please share them so they could be tested. --Malyacko (talk) 09:58, 9 April 2014 (UTC)
Jheald -- I'm not 100% sure what you're complaining about: the original full-size JPEG is full of strange wavy horizontal lines, and the resized thumbnail is full of strange wavy horizontal lines. Strange in, strange out... It's possible that if a slight blurring were applied with downsizing (instead of the slight sharpening which is actually applied), then the lines and background would become a texture. However, I'm skeptical as to how clean-looking the resulting image would be, and in fact the slight sharpening works well for a broad range of ordinary photographic-type JPEGs. The algorithm should presumably be tuned for types of JPEGs commonly encountered on Commons, not for unusual and infrequent special cases... AnonMoos (talk) 10:54, 9 April 2014 (UTC)
Okay, so I've now uploaded a copy of the image reduced to 435 x 600 using ImageMagick's default settings: File:Reduced engraving of John of Wallingford, using Image Magick.jpg, using
convert engraving.jpg -resize 22.73% reduced_engraving.jpg done with ImageMagick-6.8.3-Q16 running on Cygwin
This is what the reduced image ought to look like (IMO). It's not actually a blurring filter. Technically, a Lanczos filter (or the very similar Mitchell filter that IM uses by default) is actually a slightly sharpening filter. But the important thing is that it is a filter designed with awareness of aliasing. (See also en:User:Jheald/image_resize_testing for an exploration of the effect of downsizing a test image with different filters in ImageMagick and in GIMP). What Commons is doing isn't absolutely as bad as it could be (we're not using decimation), but it isn't as good as it should be.
@AnonMoos: yes, the full-size image includes "strange wavy horizontal lines" -- it's a line engraving. But the point of a line engraving (as an illustration in a real book) is that when you don't look close up you don't see those horizontal lines, you see an even tone, which doesn't distract from the key lines of the drawing. That's what we ought to be showing our readers at 600 x 435.
Instead, what we are showing readers at 600 x 435 is a different set of (much cruder) strange wavy horizontal lines, which do distract from the key lines of the drawing, and which are aliasing artefacts produced in the image reduction process.
(To see that the lines we're showing are indeed much cruder, count for example up from the top border of the picture to bottom of the word 'Infirmarius' above it. From what we're showing at 600 x 435, it looks like there are 3 quite crude engraving lines in between. But at full size there were actually nine. What looks like three are actually artefacts, which misrepresent the underlying image.)
There's a simple fix for this, which is to use a filter in the image downsizing process that has been mathematically designed for the job. That's what IM does by default; and it's what Commons ought to be doing, because it should not be acceptable for images of line engravings to be trashed in this way. Jheald (talk) 12:58, 9 April 2014 (UTC)
Mathematically designed for what job? The problem is most of the images on Commons are photographs, and you can't compromise their quality to improve the quality of engravings.--Prosfilaes (talk) 21:05, 9 April 2014 (UTC)
The treatment of such photographs wouldn't be noticeably affected. (Try it for yourself with ImageMagick -- or load a big photograph into Firefox, which appears to use a filter similar to IM's in image downsizing). It's specifically periodic structures with spatial frequencies close to multiples of the pixel spatial frequency that give problems -- periodic structures like the almost parallel lines of line engravings -- and this is what appropriate filters specifically notch out. But for most images you will simply never see a difference -- unless they are images with particular periodic structures like the bricks in the example image at the top of the en-wiki aliasing article. Jheald (talk) 22:15, 9 April 2014 (UTC)
If Commons were to use e.g. the Lanczos filter, there could maybe be performance issues? At least the popular image viewer and converter tool IrfanView has a "slow" warning accompanying the Lanczos option. Gestumblindi (talk) 01:31, 10 April 2014 (UTC)
Yes, performance problems make more sense than actual artifacts from scaling photographs. Lanczos is the default scaling algorithm for both Firefox and Chrome, and nobody complains about such photos looking bad. However, due to performance issues, what they actually do is a linear interpolation initially, and then replace it with a lanczos once the slower rendering is finished. I'm not sure how viable that method would be for Wikimedia. Trlkly (talk) 04:54, 10 April 2014 (UTC)
Remember that most images served by Commons (especially the default 600px views) are cached, so the image downsizing would only need to be calculated once. So yes there might be a performance hit, but it wouldn't be as if the algorithm was being re-run every time an image was served. Jheald (talk) 08:34, 10 April 2014 (UTC)
I know. But I still think a staggered approach might be worthwhile. Use the current method when files are first uploaded (or even a faster method), but cue up a lanczos transformation that can take as long as necessary. That way we wouldn't run into any timing restrictions (like we do with large progressive JPEGs). Once cached, of course, there's no performance penalty at all. Trlkly (talk) 20:47, 10 April 2014 (UTC)

I would be concerned if we caused problems for photos of bricks (or insect eyes) as a side effect of improving our treatments of engravings. Is it technically possible to have per-image control of the thumbnailing? If not, could we submit this as a feature request? --99of9 (talk) 02:09, 10 April 2014 (UTC)

@ 99of9: With bricks, insect eyes etc, any issues will be issues in our present rendering of such images, which should be fixed by using a more considered filter. Jheald (talk) 08:34, 10 April 2014 (UTC)
While I would also really like more options for thumbnailing, there is an interim solution. Just upload your own thumbnails and use those in actual articles. Have the thumbnail's description include a link to the full sized image. This is how we currently handle problem with SVG rendering as well. If this only affects a few files, this is probably the only solution we'll ever get for a while, as other problems will take priority. —Trlkly (talk) 04:45, 10 April 2014 (UTC)
I should clarify that, while there may be some similar problems with thumbnails, it's really the standard Commons 600px sized views that sparked my concern. Yes, people could make there own 600px images and upload those, in the same way that we sometimes upload alternate versions for ultra-big images; but I think that would be a pity on a number of grounds. Firstly, because in most cases people wouldn't do it, and it would be a lot of work for those that did. But also, because it would silt up the system and image categories with unnecessary duplicates; because the images that were actually better quality would still look crap in preview, so people wouldn't realise they were actually better quality; because we'd still be providing poor images at intermediate higher resolutions, rather than the best reference-quality images we could for those resolutions. And I think finally because there are so many images of engravings already on the system -- eg the works of people like Category:Gustave Doré -- which I think people don't realise how significantly better they would look, if the resizing had been done better.
Yes, most of the images on the system are not engravings. But that is because Commons is so huge. There are a lot of engravings here, and the number is increasing as people start to systematically upload the illustrations from out-of-copyright 19th-century sources -- eg the million Commons:British Library/Mechanical Curator collection images, and perhaps in future systematic uploads from the Internet Archive's 19th-century scans. Some of these images are really good (what's available is well worth a browse), but people will be more motivated to upload them if they can be sure that when the images get to Commons they will be shown properly, rather than full of Moiré patterns and other garbage from scaling artefacts. Jheald (talk) 09:08, 10 April 2014 (UTC)
Well, then, I'd say it doesn't just affect a few images. I was thinking that maybe not all engravings were affected, just ones at a certain resolution. In that case, sure, we should file a bug report. It's clearly possible to set thumbnailing settings, as we can set TIFFs to produce either JPEG or PNG thumbnails. Though, honestly, I think the staggered approach I mentioned would be better--few users are going to know to use the special options. And it would mean an increase in quality for all reduced images. (Here's an example where I had to upload my own thumbnail due to aliasing.) Trlkly (talk) 20:47, 10 April 2014 (UTC)
Yes, its possible to add new thumbnailing options. It does add extra complexity though. There may be some resistance to adding it just for specific edge cases (or maybe there won't be, not 100% sure, just mentioning the possibility). We currently use image magick for resizing images, but with the -thumbnail option instead of -resize, which I guess is for speed(?). In my test of that particular file, -thumbnail took 0.278s vs -resize taking 0.940s (The true test though is big images) . For reference, the command we use is something like: '/usr/bin/convert' '-quality' '80' '-background' 'white' '-define' 'jpeg:size=435x600' '/var/www/w/git/../phase3/images/8/82/Engraving_after_Matthew_Paris_drawing_of_John_of_Wallingford_(1255).jpg' '-thumbnail' '435x600!' '-set' 'comment' 'File source: http://localhost/w/git/index.php/File:Engraving_after_Matthew_Paris_drawing_of_John_of_Wallingford_(1255).jpg' '-depth' '8' '-sharpen' '0x0.4' '-rotate' '-0' '/tmp/transform_4dbf5d5a8a4c-1.jpg' (but with some of the paths changed, obviously). Bawolff (talk) 02:44, 11 April 2014 (UTC)
As for performance (This is off the top of my head from things I've heard second. Possibly entirely wrong. Take with lots of grains of salt). I believe image scaling has typically been more worried about memory usage, then it has about CPU time. The image scalars don't exactly look overloaded cpu wise [1]. However, I do believe that the multimedia team has been concerned with latency on uncached thumbnailing hits (particularly in relation to media viewer), so they would probably be opposed to increasing that latency further. Bawolff (talk) 03:08, 11 April 2014 (UTC)
Having now just uploaded ca 150 more engravings, of London in the 1820s (Category:Metropolitan Improvements (1828) Thomas Hosmer Shepherd -- some renaming and description still to do), most of which show this problem at least to some extent, I'm now even more convinced that something needs to be done.
Re Trickly's delayed display suggestion (ie: show uploaders a quick rough and ready downscaling, but queue those newly uploaded images for a higher quality downscaling), I wonder if that is necessary. Small thumbnail images, as presented by UploadWizard, should be possible to generate pretty quickly whatever the algorithm. When (or if) the uploader then clicks through to see a 600px version, waiting one second should not be too noticeable.
More generally, there seem to be two ways to go about organising a fix for this. One would be to add some sort of MAGICWORD to the description page of images that need more careful downscaling, that the software would then pick up and take note of. But this would require uploaders to be aware as to which images could benefit from such an option; to be aware that the option did in fact exist; and to remember (or be bothered to) apply it; including adding it to all our old images. The other option is simply to use the more careful size reduction for everything, and if that requires another server rack to be bought, then so be it. I think the second option is the one we should follow. Images are held on Commons not just for Wikipedia, or for casual viewing, but as a reusable resource for the whole world. If we're aiming to provide reference versions of images at particular pixel sizes, then we should be aiming to provide as clean a resource as we can, and not compromise quality. In connection with which "-quality 80" also seems quite mean. If we see ourselves as creating a resource for the world here, we should be aiming to provide resource-quality images. Jheald (talk) 01:01, 14 April 2014 (UTC)

John of Wallingford's Shield of the Trinity diagram[edit]

By the way, File:Reduced engraving of John of Wallingford, using Image Magick.jpg is about what I was expecting -- the mysterious lines and the background intermix to form a overall "dirty" texture, and the image doesn't end up looking overall too clean. I'm not sure that there is any resizing procedure which would make this type of engraving (which is not a usual type of engraving) look clean...
P.S. Since John of Wallingford was mentioned, if there's any scan of the John of Wallingford Shield of the Trinity diagram available which is better than that at [2] available, that would actually be helpful for an article (the image at [3] isn't really worth uploading at Commons), thanks... AnonMoos (talk) 15:58, 11 April 2014 (UTC)

@ AnonMoos: Is the image at [4] so bad? The est and non est relations are clearly legible, and the image could easily be cropped to just the MS page, without the other leaves, binding, background etc.
As per the links at the top of Category:John of Wallingford, Collecteana (c.1250s) - BL Cotton MS Julius D VII, the Cotton MSS haven't yet been added to the BL's ongoing Catalogue of Illuminated Manuscripts; and this one isn't one of the ones that has been fully digitised yet. The hit at "Online Gallery" you have already found. The blog search is flaky, because of limitations in the Typepad's online searching, but it looks like there's nothing there. There is a hit at BL Images Online; but it's not one of the 430 images they released to Flickr in February and since uploaded to Commons. But I suppose it's possible that if you sent a nice request to the Manuscripts team (Twitter: @BLMedieval) they might be able to get some sort of release. Though I don't know if it's much better than what's already on Online Gallery. If anyone has included the Images Online pic in a published paper (typically 2000px), you might be able to scrape it from there. It doesn't look as if Bridgeman have it, so it doesn't seem to be gettable-at from any of their resellers. Looks like for the time being "Online Gallery" may be the only bet. Jheald (talk) 20:37, 11 April 2014 (UTC)
If the [5] image is cropped to just the manuscript page, then you get a 432x624 pixels image, which is fine as 432x624 size images go, but leaves much of the text either barely above or barely below the threshold of reasonable legibility. What's most interesting is not necessarily the standard text seen in Latin Shield of the Trinity diagrams, but the distinctive features of this particular manuscript illustration, which only come across in a semi-mediocre way at 432x624 px.
Thanks for info. As for contacting the British Library website people, I did have one success in pointing out a mirror-flipped image long ago (ca. 2005) before they completely restructured and commercialized the website, but my only contact attempt since then (to point out that the image at [6] seems to fail to match the description at [7]) appears to have been a complete and ignominious failure, so I'm not sure I really feel like begging favors from them... AnonMoos (talk) 02:11, 13 April 2014 (UTC)
Remember that there are different teams at the BL, working in different departments/silos, who may have very different outlooks. (Which is one reason that the image categories for BL manuscripts now have anything up to six different search links to different BL silos, for Commons people looking for more or better images or cataloguing information re a particular MS).
BL Images Online is the commercial side, which I imagine is pretty commercial. BL Online Gallery is the former curatorial outlet, which I think is now pretty much a set of legacy pages that nobody around at present feels much responsibility for. Digitised manuscripts and Catalogue of Illuminated Manuscripts are both live, but (I think) supported by different grants, which may be why they don't appear to talk to each other. Finally there are the blogs, which are more informal. The last three (I think) are all run by the curatorial side, who tend to be *much* more positive towards content reuse (the Catalogue of Illuminated Manuscripts images, for example, are all explicitly licensed CC0). So if you got in touch with those guys, (who are also the people responsible for the @BLMedieval twitter feed), you might well have more luck. Jheald (talk) 21:49, 13 April 2014 (UTC)
Thanks for the info, but I don't really feel motivated to play another round of British Library contact information roulette at this time... AnonMoos (talk) 15:23, 18 April 2014 (UTC)

Automatically created pronunciation recording files from Wiktionary[edit]

If a pronunciation recording gadget is developed and used by Wiktionaries, a considerable amount of pronunciation audio files will be uploaded to Wikimedia Commons and a gadget will be installed at Commons so Wiktionaries can use shared code from Commons for producing these recordings. I believe this is in the interest of Commons as we will be able to adjust how the file description page is build and to specify the information that has to be present on it.

These files will be categorized by language or even dialect; the description will be automatically created. There is not a lot to say, except that I don't expect a lot of trouble here at Commons with these files/ file description pages. -- Rillke(q?) 21:35, 14 April 2014 (UTC)

+1 for hosting as many such files as possible. :) --Nemo 10:32, 17 April 2014 (UTC)

April 15[edit]

Do these images need a third party review?[edit]

I came across a flickr contributor from Vancouver who uploaded several hundred before and after collages. They are beautiful. From his collages I selected and started to populate Category:Old streetcars in Vancouver.

This individual has marked their collages "all rights reserved". IMO, when the before portion of the image is old enough that it would be in the public domain in Canada, any of us could legitimately crop out their copyright "after" image, and upload the public domain "before" image. I do think the flickr contributor can legitimately mark their collage as all rights reserved. In a few instances they gave vague indications of where they acquired the before images -- like listing the main page of the Vancouver public library

I try to always spend an extra twenty seconds to inform flickr contributors who use a free license that I uploaded their image, and give them the URL to where it is being re-used here, to encourage flickr contributors to use free licenses, and also to help other Commons contributors from wasting their time uploading the image a second time. But I didn't do that in this particular case, since they didn't use a free license. In fact they used some kind of flickr-fu, that locked out flickr's regular download feature, and I had to use Mozilla's Page Info tool to download a medium-resolution image.

My two questions:

  1. Do other contributors agree that uploading just the public domain "before" images is legitimate?
  2. There is a mechanism where someone can request a third party to confirm that an image was found on a particular site, to be used when the source site is unstable, and the image may go away. This flickr uploader may remove these images. Is it necessary for me to request one of those third party reviews?

Cheers! Geo Swan (talk) 16:55, 15 April 2014 (UTC)

Why don't you simply get the originals from the City of Vancouver Archives? They have them available at much larger sizes. For instance, let's take this flickr image. You cropped out (badly, since the crop includes parts of the lower color image) the upper part and uploaded it as File:Southbound streetcar at Granville and Smithe - 1920.jpg. A very quick search in Google for "granville smithe streetcar" brought me to the web page of the City of Vancouver Archives, and a quick search there for "granville smithe" turned up the original image as a 3000×1993px scan as the 10th search result. I would have used that directly, and sourced it to the City of Vancouver Archives, bypassing Flickr completely. The City of Vancouver Archives also clearly state that the photo was PD in Canada. (BTW, note the left-hand traffic! So the photo was taken before 1922.) Lupo 09:06, 16 April 2014 (UTC)
  • Only one of the two dozen or so images I cropped and uploaded, so far, gave any indication of where the collage-maker found the "before".
It sounds like you are familiar with the Vancouver Public Library site. That is great! I am not. Many sites with archives of old images are very hard to search. Congratulations on finding that one higher-res image.
Are you suggesting I am at fault for not looking everywhere for more original sources for those two dozen images -- when I think we already know they are in the public domain? Geo Swan (talk) 18:57, 18 April 2014 (UTC)
I'm not suggesting you were "at fault" for anything. I just think that using the originals from the City of Vancouver Archives is (a) easier, since you don't need to crop, (b) gives us higher-resolution scans, (c) better sourcing, and (d) sidesteps the first of your issues completely. Whether a {{licensereview}} template should be used even for the City of Vancouver Archives I don't know -- basically, that site could also go away, but it'd probably be overkill as they're very unlikely to change the license.
I am not familiar with that archive; I've seen it a few days ago for the first time. But their search function is very simple to use, and it appears that Flickr user got most of his "old" versions (at least those that are not old postcards) from there. I only spot-checked, but File:A streetcar at Hastings and Granville, Vancouver, in 1905.jpg is [8] (found by searching for "granville hastings 1905" at the archive; they even identify the photographer), File:A streetcar at Hastings and Granville -a.jpg is [9] (much better scan, creator identified; found by searching for "granville hastings 1908 bank"), and File:A streetcar passes the Manhattan apartments in Vancouver, in 1912.jpg is [10] (search "manhattan streetcar 1912"; again better reproduction and photographer identified). Finding these images took me less than five minutes. So I was suggesting to do a quick check at the City of Vancouver Archives search page to get better versions easily. Lupo 20:06, 18 April 2014 (UTC)
BTW, the postcard at File:A streetcar passes Hamilton and Hastings in old Vancouver.jpg is probably [11] (Postcard by Philip Timms). Unfortunately, that archive at UofBC does not have a digital version online. Lupo 20:19, 18 April 2014 (UTC)
Addendum: but the Vancouver Public Library does have the original photograph: [12], albeit only as a small version. At least that confirms the photographer and dates it. Lupo 09:50, 19 April 2014 (UTC)

Media Viewer Launching Soon[edit]

Media Viewer lets you browse larger images on Wikimedia sites.

Greetings! We are happy to announce the upcoming release of Media Viewer, a new tool for browsing multimedia content on Wikipedia, Commons and other Wikimedia sites.

This new tool provides a more immersive media experience for our users: they can now see larger images when they click on article thumbnails, right where they expect them. It was developed by the Wikimedia Foundation's multimedia team in recent months, with the help of many community members. We now plan to gradually release this tool in coming weeks -- starting with a few pilot tests this month, followed by wider deployments next month, as described in this release plan.

As we approach release, we would like to know what you think of this tool, so we can address any critical issues, based on your feedback. If you haven't already, we invite you to try the tool in beta as described here, then join this local discussion on Commons -- or this wider discussion on MediaWiki.org. Both discussion pages include a list of features we would like more feedback on.

IRC Chat: To learn more about this release, please join our next IRC chat, on Wed. Apr. 16 at 18:00 UTC at Wikimedia's Office IRC Channel. Hope to see you there! Fabrice Florin (WMF) (talk) 00:49, 16 April 2014 (UTC)

To clarify, this is in 50 minutes! --Dschwen (talk) 17:10, 16 April 2014 (UTC)
I'm not having this "Beta option" in Settings on my Profile. What's up? Kind Regards, Timelezz (talk) 13:12, 22 April 2014 (UTC)

Value on print of The Temptation of Adam[edit]

What is the value on a print of The Temptation of Adam 1905 Karl Witkowski, How do I find this information please advise thank you Lois Arrigo -- 15:37, 16 April 2014‎ User:Lois Arrigo

Unfortunately, we're not art dealers or appraisers. You need to find one of those... AnonMoos (talk) 15:31, 18 April 2014 (UTC)

April 17[edit]

Low German or Low Saxon[edit]

Commons seems inconsistent with regards to whether categories should contain "Low German" or "Low Saxon"; c.f. Special:Search/Low German versus Special:Search/Low Saxon, and Category:1614 Low German Bible categorized into Category:Low Saxon. Which one should I use for new categories, and should I ask for mass renaming them? TeleComNasSprVen (talk) 09:45, 17 April 2014 (UTC)

Also of note is that Category:Low Saxon seems like a nonstandard category name, as other language categories tend to be called "Category:French language" instead of just "Category:French" for example. TeleComNasSprVen (talk) 09:48, 17 April 2014 (UTC)
I think Low Saxon is a subset of Low German, so ideally Category:Low Saxon should be a subcategory of Category:Low German or Category:Low German language... AnonMoos (talk) 15:38, 18 April 2014 (UTC)
Wikipedia doesn't think so; w:Low_German#Nomenclature. A quick Google Books search leads me to agree with that claim; there are works using "Low German" for the whole collection, and books using "Low Saxon" for the same languages.--Prosfilaes (talk) 20:49, 18 April 2014 (UTC)

April 18[edit]

Borked uploads at Category:Tibi (brand)[edit]

I've been uploading thousands of fashion photographs from Flickr using meta:Flickr2commons. It's generally gone well, but during a run of 300 or so images into Category:Tibi (brand), the following files seem to have been uploaded incorrectly. User:Magnus Manske, the flickr2commons developer believes it is a Mediawiki/Commons issue. The following files are -

I cannot reupload them through Flickr2Commons because the tool believes that these files are duplicates. I have not tried manually reuploading the files. Take a look, see if you can diagnose what went wrong. - hahnchen 12:46, 18 April 2014 (UTC)

maybe some sort of temporary swift outage occured during upload(?). I added those images to bugzilla:64071. Note, you can reupload if you use special:upload and check the ignore all warnings box. Bawolff (talk) 15:16, 18 April 2014 (UTC)
By the way, it also looks like you referenced a bunch of categories you did not bother to create. - Jmabel ! talk 15:34, 18 April 2014 (UTC)
Now that it's noted in Bugzilla, is there any reason to keep these files? If not, please just delete them. I'd rather reupload them through flickr2commons rather than doing it manually. - hahnchen 01:53, 19 April 2014 (UTC)

Adrianne Wadewitz authority control[edit]

Can someone please help me add {{Authority control}} to Creator:Adrianne Wadewitz ?

Also, how come it's not showing all the parameters I used for the "occupation" field ?

Thank you,

-- Cirt (talk) 19:18, 18 April 2014 (UTC)

Gadget-VIAFDataImporter is useful to accomplish the first task; you possibly have to allow your browser loading unsafe contents from VIAF.org -- Rillke(q?) 19:55, 18 April 2014 (UTC)
Only the first four occupations are parsed by {{Creator}}: {{NationAndOccupation|{{{Gender|m}}}|{{{Nationality|}}}|{{#titleparts:{{{Occupation|}}}|1|1}}|{{#titleparts:{{{Occupation|}}}|1|2}}|{{#titleparts:{{{Occupation|}}}|1|3}}|{{#titleparts:{{{Occupation|}}}|1|4}}}}<br>}}
Someone with Lua knowledge could however fix this quickly or less quickly rewriting the whole template in Lua. -- Rillke(q?) 19:55, 18 April 2014 (UTC)

April 19[edit]

CommonsHelper out of service[edit]

Hello everyone, I inform you that CommonsHelper is not operational (...again...) and that it is annoying that cyclically this and other tools stop working. Please, unlock this...--Threecharlie (talk) 04:53, 19 April 2014 (UTC)

@Threecharlie: This is the tragedy with tools running on Labs or Toolserver. Please consider commenting on Commons:Requests for comment/Allow transferring files from other Wikimedia Wikis server side so we can build tools not running on external servers. -- Rillke(q?) 09:55, 19 April 2014 (UTC)
FYI. --Magnus Manske (talk) 19:00, 19 April 2014 (UTC)


Are sounds of nature educational enough for Commons?[edit]

Dear Commons community. Someone shared an idea with me that within the Commons:Wiki Loves Earth 2014 contest Wikimedia Ukraine could have a special sub-nomination for sounds of nature. I think that would be interesting, but it would require some criteria for the sounds. And I wonder, what sounds of this kind would be educational enough for Commons? Sounds of animals - probably yes. And what about forest ambiance without distinguishable animal sounds? The latter probably not. What do you think? (there's http://freesound.org/ with a lot of nature sounds, but they don't have the educational requirement and they don't have a lot of sounds from Ukraine. So educational usefulness should be in focus if we want to create something unique). --YurB (talk) 10:03, 19 April 2014 (UTC)

I've uploaded a few media files from Freesound myself, see Template:Freesound which I've created along with Special:WhatLinksHere/Template:Freesound for a list of sample files. However, I've limited myself mostly to files that clearly describe what species of animal the recording is about, for the purposes of Commons categorization and scope issues. Cases like sounds of dogs (as in an indiscriminate recording of a pack of dogs on any given day) might not have educational scope if we cannot even identify the type of dogs that are barking. TeleComNasSprVen (talk) 10:10, 19 April 2014 (UTC)
(edit conflict) Also, you might want to explore a few files from Category:Sounds of nature and tell us what you think about them, in terms of scope or otherwise. TeleComNasSprVen (talk) 10:13, 19 April 2014 (UTC)
I think all of that is more educational than our huge collection of porn and crude drawings. FunkMonk (talk) 10:12, 19 April 2014 (UTC)
If there is something identifiable (i.e. the sound quality should be good enough) and a timestamp (date+time) when the recording was created plus the exact location, I think it's perfectly in scope. As for your example: It will help people getting an impression of how the forest sounds like at a specific time - which birds are primarily singing or when deer roars. Although possibly not that important for Wikipedia, for Wikivoyage it is, I could imagine. -- Rillke(q?) 10:26, 19 April 2014 (UTC)
Thank you all for your comments, they're useful. We'll think how to develop this idea. --YurB (talk) 10:30, 19 April 2014 (UTC)

WhatIsThat? tool for multilingual descriptions doesn't seem to work anymore[edit]

See here. Anyone knows what's the issue? Thanks. --Codrin.B (talk) 14:26, 19 April 2014 (UTC)

The webservice died. @Magnus Manske: kannst Du mal webservice restart? Weißt Du eine gute Methode, um diesen Webservice zu überwachen zu lassen und bei Nichtfunktionieren e-Mail o.ä? -- Rillke(q?) 17:07, 19 April 2014 (UTC)
Done. Someone at Labs changed something, killed a lot of webservices, but didn't restart them. Still cleaning up... --Magnus Manske (talk) 18:20, 19 April 2014 (UTC)
Thank you. I am now using a google apps script to monitor my most critical tools. Do you know a good free service/ less hacky approach with a public dashboard like status.wikimedia.org ? -- Rillke(q?) 23:50, 19 April 2014 (UTC)
@Rillke: https://tools.wmflabs.org/tools-info/migration-status.php ? --Zhuyifei1999 (talk) 02:11, 20 April 2014 (UTC)
Thank you; what I need is an independent system accessible on a different domain and running on a different server so I can get e-Mail when it detects non-op and isn't affected by any labs-crash and can view the statistics even if labs is down or slow. -- Rillke(q?) 11:07, 20 April 2014 (UTC)
wikitech:User:Yuvipanda/Icinga_for_tools --Zhuyifei1999 (talk) 14:21, 22 April 2014 (UTC)

April 20[edit]

Request at CommonsDelinker page[edit]

Could someone take a look at my request here? There it says that I should notify editors here. Thanks. Jsayre64 (talk) 03:58, 20 April 2014 (UTC)

  • You would request this on User talk:CommonsDelinker/commands with {{move cat|Maps of Cascade Range|Maps of the Cascade Range|3=EXPLANATION (optional, but kindly requested) ~~~~}}. For what it's worth, though, we often omit "the" in category names like this and use the more "headline-speak" wording. - Jmabel ! talk 16:48, 20 April 2014 (UTC)

Replacement for MiszaBot[edit]

Hi all, I'd like to take over for MiszaBot, which has been down for quite some time now. Your input would be appreciated at Commons:Bots/Requests/ArchiveBot 1 -FASTILY 04:32, 20 April 2014 (UTC)

Wikivoyage's Banner[edit]

Hi,

Wikivoyage add a banner at the top of pages. The banner also include the table of content. See for example Dubai. I would like to do the same on Commons, more specially on some pages of Père Lachaise Cemetery. This require to to import Template:Pagebanner and modify MediaWiki:Common.css. What do you think? Pyb (talk) 05:40, 20 April 2014 (UTC)

What do you mean by table of contents? I do not see any. Ruslik (talk) 17:49, 20 April 2014 (UTC)
It has been integrated in the banner as a horizontal list. Edokter (talk) — 17:56, 20 April 2014 (UTC)
TOC is integrated in Wikivoyage, not in the banner itself.--Ymblanter (talk) 20:07, 20 April 2014 (UTC)
Yes, the TOC is horizontal and displayed over the banner. May I do that on Commons ? Pyb (talk) 01:44, 21 April 2014 (UTC)
No. Ruslik (talk) 19:12, 21 April 2014 (UTC)
Actually, this is a good idea. —Mono how to reply 03:18, 22 April 2014 (UTC)
Thank you for your comments. I've done some examples on Wikivoyage (Test 1, Test 2) Pyb (talk) 06:34, 22 April 2014 (UTC)
Looks nice, I would support this as well.--Ymblanter (talk) 18:30, 22 April 2014 (UTC)

Images so big they break Commons?[edit]

An improved map of the Hudson River - with the post roads between N. York and Albany - drawn and engraved expressly for the tourist (by) W. Chapin, sc. NYPL434651.tiff
A "difficult to view" concertina map of the Hudson River, 1834. Height of 14,000 pixels.

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? -- (talk) 08:14, 20 April 2014 (UTC)

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)
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, 50 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. -- (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): 722.

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. -- (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 [13]) 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)

File:Tallahatchie River south of Greenwood, Mississippi, United States.jpg[edit]

Sorry to trouble you. I just uploaded this file and meant to call it "Tallahatchie River north of Greenwood, Mississippi, United States.jpg". Thanks so much. Magnolia677 (talk) 23:08, 20 April 2014 (UTC)

✓ Done See {{Rename}} for future requests. -- (talk) 23:15, 20 April 2014 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 15:59, 21 April 2014 (UTC)

April 21[edit]

April 22[edit]

CommonsHelper Broken?[edit]

I get a 404 when I try accessing Magnus's CommonsHelper tool. Does anyone know why it's no longer online?  :o -FASTILY 06:40, 22 April 2014 (UTC)

See above and bugzilla:64095. Lupo 07:18, 22 April 2014 (UTC)

That's the icing on the cake," Mr Fuller said...[edit]

This description seems to apply to 73 images [14]. Is this how they came to Commons or something mangled in the upload process? Railwayfan2005 (talk) 12:50, 22 April 2014 (UTC)

  • They are bot-transferred from Flickr, and it looks like that text is given as a "description" for each of these on Flickr. Someone should go through and caption these appropriately.- Jmabel ! talk 15:30, 22 April 2014 (UTC)

Public transport in the Valenciennes region[edit]

The trams are commonly called Valenciennes trams referring to the main city Valenciennes. However this is a regional tram and busnetwork fr:Transvilles wich serves many villages and towns in the region. I have added the Category:Arrondissement de Valenciennes to disentangle the images connected tot the city Valenciennes proper and all the other places. There are also Transvilles bus lines. I have started to create subcategories as Category:Trams in Valenciennes (Anzin) and Category:Trams in Valenciennes (Condé). I think this should be renamed "Trams in the Valenciennes region (Anzin)". Or maybe: Trams in the arrondissement Valenciennes. I could create a category "Transvilles public transport network" but this has no historical roots for old images. I would like advise before I create new categories. A lot of tramline images still have to be categorized by commune. Smiley.toerist (talk) 14:41, 22 April 2014 (UTC)

PS:I have not yet managed to put all the communes in the category "Arrondissement de Valenciennes". They are quite a lot of them. I use the list in fr:Arrondissement de Valenciennes. This will be usefull to connect this region to the historical Hainaut (duchy) region.Smiley.toerist (talk) 14:47, 22 April 2014 (UTC)

Connections between old paintings[edit]

I uploaded a postcard. When I compare this with an older painting it is clear it is the same composition. The same people on the bridge. However there are some differences (an extra boat under sail on the rigth side, The pole is schifted to the rigth by the background of towers). Is it a reuse of the same composition? The postcard painter is mentioned as Martin, but there a lot of years between 1690 and 1741 (51 years in those days was a lot. If he painted the first when he was twenty years old the next would be when he was 71) Does anyone knows anything more about the painter?Smiley.toerist (talk) 22:36, 22 April 2014 (UTC)

It would seem to be his brother, Pierre-Denis Martin, who painted the second painting.Smiley.toerist (talk) 22:36, 22 April 2014 (UTC)

April 23[edit]

Tank Photography in Dorset, England[edit]

Wikimedia UK has been given some free off peak tickets to the Tank Museum in Dorset, England. Interested photographers are welcome to Email me, I need a snail mail address to post you tickets. Tripods are allowed, provided you are sensible abut their use. Jonathan Cardy (WMUK) (talk) 13:23, 23 April 2014 (UTC)

April 24[edit]

File:Arms of the Qing Dynasty.svg[edit]

In the past, I have requested that File:Arms of the Qing Dynasty.svg be renamed, however the rename request was rejected. Hence, I would like to start a proper community discussion regarding what to do.

I would like to propose that the file be renamed to any of the following:

My reasoning is based on the following:

  • The current title is misleading - readers who do not read the file description in detail are inclined to think that the title implies that the file is the proper, official coat-of-arms
  • The image is used throughout multiple Wikipedia projects as the official coat of arms, which proves my above assumption. This is often the case on non-English speaking Wikipedia projects, where users may not be able to read and properly understand the file description
  • The file description states that the image is fictitious, however nobody reads file descriptions before adding images to Wikipedia pages; making a note of it in the title would help soften this problem
  • A file rename would "do no harm", as opposed to not renaming it; even though there is no specific policy which obligates us to do so, the Commons project should do no harm anyway, for the sake of constructiveness
  • The arms originates from a 19th century French book, and there is no evidence that it was ever used by the Qing. File:Brockhaus and Efron Encyclopedic Dictionary b15 462-3.jpg contains a copy of the arms found in the French book.
  • There was discussion on the English Wikipedia here and here regarding the problem. There was also discussion on the Chinese Wikipedia, I'll have to look around for an actual link, give me a moment.

Does anyone have any comments regarding this matter? -- 李博杰  Talk contribs 08:22, 24 April 2014 (UTC)