This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Can I replace a current photograph with on that is technically and artistically better?
I am wondering if it is bad form, to replace an existing image on a page, with one of my images. The current image is badly overexposed and poorly cropped. I have a nicer image and would like to post it, but I am not sure if this is considered rude behavior.
Unless uploading an improved version of the existing image, overwriting is not recommended; it would be preferable to upload under a different filename and replace usages of the poorer version. Rodhullandemu (talk) 23:12, 28 February 2014 (UTC)
Ken, on the chance you are asking is it OK to change an image in a wiki article with one of your own... feel free or "be bold" as they say. Try to include an explanation as to why (higher res - better lighting) in the edit summary. If you are unsure as to whether it is actually better for the article then ask on the talk page. However, never overwrite one image with a different image on Commons. You may improve an existing image and then overwrite. Asking the uploader if it is OK to overwrite might save you some grief. Saffron Blaze (talk) 01:22, 1 March 2014 (UTC)
SB: Commons is a wiki. So are lots of things. When you say "a wiki article", I assume you mean "a Wikipedia article." - Jmabel ! talk02:30, 1 March 2014 (UTC)
Ken, are you asking about overwriting the image on Commons (generally not OK) or in a Wikipedia article or a Commons gallery page (almost always OK)? - Jmabel ! talk02:30, 1 March 2014 (UTC)
Also, to clarify one thing SB said above: usually the only "improvements" that belong as uploads under the same filename at Commons are things like color correction, removing a watermark, rotation if needed, etc. for a photo; a better scan if the image came from a book; correcting spelling in a chart; etc., not a different technically better photo, which should get a different name (and its own accurate author, date, etc.). - Jmabel ! talk02:30, 1 March 2014 (UTC)
March 02
Do we need a warning tag for North Korea-related images?
We should not take sides in any external dispute, merely be concerned that images are properly hosted here, i.e with proper licensing and copyright. So the short answer is "no". Rodhullandemu (talk) 02:37, 20 February 2014 (UTC)
I know nothing about South Korean law, but what Puramyun31 proposes appears to be parallel to a number of already-existing templates which inform re-users of possible restrictions on their ability to re-use images for certain purposes (even though such restrictions do not prevent Commons from hosting such images) -- {{Insignia}}, personality rights, trademarked, Nazi symbol, etc. AnonMoos (talk) 07:18, 20 February 2014 (UTC)
Following AnonMoos, I think you should feel free to create such a template and place it appropriately on the images to which it would relate. - Jmabel ! talk16:55, 20 February 2014 (UTC)
Seems to be similar to {{Nazi symbol}}, so as long as we have a {{Nazi symbol}} tag, having one for North Korean propaganda material seems OK. How does South Korea define North Korean propaganda material? From what I have understood, you can't send things by mail from North Korea to South Korea if the postal stamp shows a picture of Kim Il-sung or certain other people or objects. Should we also create a tag for South Korean propaganda material, since North Korean reusers might end up in trouble if they wish to use it? --Stefan4 (talk) 00:15, 23 February 2014 (UTC)
South Korea National Security law defines it is illegal to praise NK. So, someone tries to use them for NK will be arrested, and will go to court. However, it is not illegal to see or reuse for normal purpose, and I am not sure if it is needed. — Revicomplaint?02:36, 2 March 2014 (UTC)
Should these categories be deleted?
All the following categories have misspelling errors of "Colombia": Adolescent girls in Columbia (empty); Huts in Columbia (empty); Massacres in Columbia (empty); People of Columbia (empty); People of Columbia by occupation (empty); Sports in Columbia (empty); Sportspeople from Columbia (empty); Volleyball in Columbia (empty); Women of Columbia (empty); Young women in Columbia (empty). They are already redirected to the correct ones. Should be deleted? --JotaCartas (talk) 10:56, 22 February 2014 (UTC)
If they are redirected and empty, then why do anything with them? It will direct users who type in the wrong spelling to the correct category. — Huntster (t@c)10:59, 22 February 2014 (UTC)
Commons:Rename a category suggest discouraging the use of category redirects, but in this case this is not a typo and "Colombia" is just as much a valid word as "Columbia" is; that is, they are synonyms. Therefore, these should remain as redirects. TeleComNasSprVen (talk) 11:27, 22 February 2014 (UTC)
Remember: use rename only for different name of the same subject, or for the translation of the category name in another language, not for bad names or mistakes! Bad names or mistakes have only to be deleted! This is the rule. --DenghiùComm (talk) 11:54, 22 February 2014 (UTC),
See above: but in this case this is not a typo and "Colombia" is just as much a valid word as "Columbia" is; that is, they are synonyms --Zhuyifei1999 (talk) 12:08, 22 February 2014 (UTC)
When they are synonims, then is important to uniform the language and to decide which word must be used. It's important that there is coherence and consistency in the categories. Recently it was made order e.g. in all cats about "jewelry" and "jewellery". --DenghiùComm (talk) 12:15, 22 February 2014 (UTC)
Your complaint also seems quite ironic, coming from someone who supports restoring completely non-free (in the US) URAA-affected files to Commons. If it makes you feel any better, photos licensed like this one cannot be nominated to become Commons FPs anymore. --Avenue (talk) 13:30, 2 March 2014 (UTC)
Well, my position in there is really due to the fact that many of those images are actually truly free. Recently I found out (from the discussion on Jimbo's page) that works published in the United States within 30 days after their initial publication cannot be restored. Using this new ammunition I managed to compile for myself a list of 11 images so far that I can request to be restored (deleted under URAA) regardless of if we mass restore the rest. This further reinforced (at least for me) the idea that many others are free. Unfortunately proving this on an image-by-image basis is very difficult. The list I compiled so far is from images by Israel Gov from various wars where the date ranges can easily be checked out, for others you'd need to follow the news trails (for example when did this famous person made their visit to Jerusalem or met with a PM). It certainly doesn't help that the local library only had newspapers in Microform and searching newspaperarchive.com for those things are nearly impossible. --CyberXRef☎10:11, 3 March 2014 (UTC)
I'm glad to hear you found some that appear to be PD-US. Please do request their restoration (at COM:UR). Even if they might be restored anyway with the rest, it would be useful to document that they are PD-US. It might make the difference between someone being able to use them or not. --Avenue (talk) 11:00, 3 March 2014 (UTC)
Personally, I don't like this kind of licensing at all - especially the "ND" part in the CC license. This means that not only if one wishes to use the image commercially, they have to adhere to the cumbersome GFDL, but also if they just want to use it for a (even if non-commercial) derivative work, e.g. a collage, as the "ND" clause prohibits derivative works. But yes, it's accepted on Commons, as the GFDL is still considered a free license, even though it never was really meant for images (but for software documentation). Gestumblindi (talk) 14:31, 2 March 2014 (UTC)
Strange behaviour of information template (with creator template)
|Author =
*Sculpture: {{Creator:Toni Schneider-Manzell}}
*Photo: Andreas Praefcke
This used to work perfectly, as intended: a bulleted list of two entries, with the creator template. Now (don't know how long ago), the second entry appears not in the author field anymore, but _above_ the whole information template. Hence authorship information is not readily available anymore where it belongs. Without the list syntax or without the creator template, everything works fine. Whoever introduced that bug wherever, please fix it ASAP. Formatting author fields like this is not at all uncommon in the Commons. --AndreasPraefcke (talk) 08:37, 27 February 2014 (UTC)
When you exchange both *-entries, thereby moving the creator-template-containing entry to the second position, both are correctly displayed. Of course, that doesn't solve the underlying problem. --Túrelio (talk) 08:44, 27 February 2014 (UTC)
@AndreasPraefcke: One cannot put templates like {{Creator:Toni Schneider-Manzell}} that contain line breaks in a mw-list (*#) – knowing that any line break will signal the end of the list, if not followed by a new list item – and expect anything good because this will create a parser output like:
It's easily spotted that this is invalid HTML and HTMLTidy, which runs after the parser will do its best to transform it into valid HTML, moving stuff around.
There are 2 possible solutions:
Amending {{Creator}} not to output new lines, e.g. using comments to have some visual separation
Using HTML directly:
<ul><li>Sculpture: {{Creator:Toni Schneider-Manzell}}</li><li>Photo: Andreas Praefcke</li></ul>
Be that as it may be, but it used to work, and now it doesn't. Plus, the Wiki Markup is perfectly all right and valid, only the parsing seems to make a mess out of it. "any line break will signal the end of the list, if not followed by a new list item" - well, then the new list item should begin a new list, but not appear at a random place. --AndreasPraefcke (talk) 09:41, 27 February 2014 (UTC)
Mmhhh, the second part of the output seems to be even more interesting:
</table></div><ul><li> Photo: Andreas Praefcke</td></li></ul></tr>
Note the closing </td> tag just after Andreas Praefcke. This one will be certainly responsible for moving the second li out ouf the whole table. Anyone an idea why the parser does not close the second <li> before? (For reproducing, put the contents of this version into Special:ExpandTemplates and tick the checkbox for raw HTML output. -- Rillke(q?)10:10, 27 February 2014 (UTC)
We had this issue for years. Not mixing bullets with creator templates usually fixes it (text like "Sculpture: {{Creator:Toni Schneider-Manzell}}Photo: Andreas Praefcke"). Template:Artwork/testcases (created 3 year ago) has a few more scenarios that really break the templates. I never figured out how to fix it. --Jarekt (talk) 16:28, 27 February 2014 (UTC)
The page for File:Red Funnel, Red Jet 5, IMO8954415.jpg seems to be corrupt; I can see the image, but not add categories using HotCat. The history tab has no entries, and the upload does not show on the editor's "contributions" tab. The page includes the error message "The revision #0 of the page named "Red Funnel, Red Jet 5, IMO8954415.jpg" does not exist". Andy Mabbett (talk) 16:54, 28 February 2014 (UTC)
deleting and undeleting can fix this type of corruption (that is make it editable again. It wont bring back the pages content). I have no idea what is causing this. Its like transactions just arent happening. I'm hopeful someone more knowlagable than me will figure it out. Bawolff (talk) 21:03, 28 February 2014 (UTC)
Call for project ideas: funding is available for community experiments
I apologize if this message is not in your language. Please help translate it.
Do you have an idea for a project that could improve your community? Individual Engagement Grants from the Wikimedia Foundation help support individuals and small teams to organize experiments for 6 months. You can get funding to try out your idea for online community organizing, outreach, tool-building, or research to help make Wikimedia Commons better. In March, we’re looking for new project proposals.
Examples of past Individual Engagement Grant projects:
One “improvement” I’d love to see in Visual Editor (and one that would cost less than 4500 USD), is its immediate and complete shut down. Fat chance it will happen soon, though. -- Tuválkin✉01:06, 2 March 2014 (UTC)
I clicked the revert button next to the first image to restore to that version but the current one still looks darkened. Does anyone know what I did wrong here? TeleComNasSprVen (talk) 00:08, 2 March 2014 (UTC)
Also, what happened to the old Special:Upload form that had only two fields, the pre-filled {{Information}} box and the target filename to upload to? I'm getting quickly annoyed by the numerous warning signs preventing me from uploading because "You must give the original source of the file, the author of the work, and a license." For example, at File:Udupi Banner 2 - darkened.jpg I have to create this ugly hackish workaround where I create the description page for the file before being able to actually upload it, so it was basically a description page without a file for a few moments. TeleComNasSprVen (talk) 00:39, 2 March 2014 (UTC)
And that he is uploading images of an artificial urinary sphincter of Zephyr Surgical Implants for commercial purposes. The images he is uploading proceed from the same firm. Images and identities must be deleted. He is creating pages in Spanish, English and Catalan Wikipedias as well sith images and links to the same or related firms. --Pompilos (talk) 17:16, 2 March 2014 (UTC)
Maybe I'm missing something here, but assuming we can get OTRS, it seems to me that these are images we would want. - Jmabel ! talk19:35, 2 March 2014 (UTC)
When works of known artists get deleted because of the URAA rule, I find it unfair, if it is PD in Europe, but I can accept it as an precautionary measure. However I totaly disagree in the case anonymous (orphan) works. Example: this one The discussion was not accessed properly. There is by definition no risk to the WMF, as the author has to be known for legal procedings. In the extremely unlikely event the author becomes known (most cases are local postcard street views of no present commercial value and taken by the local postcard compagny employe. Can you posibly remember the pictures your father took for his work?) the picture can be treated by the normal rules and excuses made. Wouldnt the judge dismis this as trivial?
We have to respect the law, even if it is dubious (retroactive and overruling foreign PD for local content having nothing to do with US), but this is ridiculous. I am afraid the WMF will get a lot of trouble within the Wikipedia community outside de US, if URAA rules are applied this way. How would a US-citizen feel if French copyrigth law overrules US-law in a work having only US local connections? Why not simply apply the URAA rules to orphans when the author is discovered? By us or a third party? Smiley.toerist (talk) 00:03, 3 March 2014 (UTC)
I'm no fan of the URAA, especially while the US does not implement the rule of the shorter term. I don't think it can be described as retroactive though. It was passed in 1994, took effect until 1996, and had no effect on works whose foreign copyright expired before then.
Yes, it seems unlikely anyone would be sued over these pictures, but where would we draw the line? --Avenue (talk) 01:44, 3 March 2014 (UTC)
The law was never intended for orphans. There is a powerful lobby of publishers wich demanded compensation from piracy. They get a few more years to extract revenue from existing cash-cows. And these are all works of known authors. I have a no moral problem avoiding the law when there is a legal gray area and no risc or harm to anybody. There is such a thing as a moral rigth to acces our history.Smiley.toerist (talk) 08:39, 3 March 2014 (UTC)
I wholeheartedly agree with most you say, URAA rules are ridiculous and unfair to other countries. However unfortunately it is the copyright law at the moment and it is not up to WMF to pick which copyright laws they should obey and which do not. Many counties have some bizarre laws on the books, I for example live in Virginia a state with unusually high dose of bizarre laws, see here for juicy details. Commons:Project scope/Precautionary principle (which happen to be our policy) explicitly mentions case of unknown author.
The only think we can do is to lobby to repeal the law. People in the US can lobby their elected officials, and people outside US can let their officials know about the agreement they signed with the US about protecting their copyrights. --Jarekt (talk) 18:16, 3 March 2014 (UTC)
The URAA rules were written by other countries, so I think it's safe to invoke the rules of estoppel against complaints that they're unfair to other countries. In any case, what we're really talking about is the lack of the rule of the shorter term, which means that citizens of the UK or Israel or India get treated in the same way as citizens of the US under US law. Which I refuse to buy is ridiculous and unfair to them.--Prosfilaes (talk) 00:35, 4 March 2014 (UTC)
I think we should separate the issues here. Unfortunately, legislative efforts to get laws passed on orphan works in the US have stalled, but that is our key issue. The URAA is irrelevant here, and the rule of the shorter term only marginally so. Copyright extensions are relevant and are not just limited to the US. (Works by George Bernard Shaw published in 1883, in copyright in the EU, were published 40 years before any work in copyright in the US. Works published by Russell in 1896 will be copyright in the EU through 2040.)
The use of orphan works is a contentious issue and the WMF has shown no hint of openly approving it, probably on advice of their legal council. What approval we would need from the WMF is probably an open question, and should be discussed separately from the URAA question.
One of the my big problems with anonymous works is that figuring out when a work is anonymous is hard, and we've called numerous works anonymous and yet found that the author was easily found with reference to the right databases.--Prosfilaes (talk) 00:35, 4 March 2014 (UTC)
Some simple rules could be applied on specific categories. For example do some research on the workings of some postcard companies. Did the owner of company take the pictures themselves, or where the pictures taken by local employees or bougth from local photografers? (the copyrigths then belong to the company). Another problem is dating these pictures. If you can date them from before 1923 the problems can be avoided. A lot of anonymous works are in fact compagny works. It is imposible to check the company records and the individual labour contracts. Smiley.toerist (talk) 16:14, 4 March 2014 (UTC)
Assuming you are just talking about integrating the text, you should feel free to do so. No need to come to the Village pump for a routine edit. - Jmabel ! talk17:35, 3 March 2014 (UTC)
seems to be a missunderstanding by the IP user. One of the pages ist a "category" categorizing alot of media concerning Einstein, the other is a "page" listing a (hopefully good) choice of media from this same category. As the "page" shall only comprise media from the "category", there is no possible "merge". - Andy king50 (talk) 21:17, 3 March 2014 (UTC)
"Hopefully" being the operative word here. I didn’t visit that page, but I’m betting that it is a poor clone of whatever images we had tagged with Category:Albert Einstein back in 2006, meanwhile unkept, unmantained, and recieving occasional random edits from the clueless and the weird. I hope I’m wrong and this page is an expection — going to visit it now. -- Tuválkin✉21:54, 3 March 2014 (UTC)
I do have a problem with authors producing work after their death. example: File:Baedeker Pisa.jpg. Is there someway to make a clear distinction between personal and company work? (PD 70 years after publication in Europe). I have added the mapmaker.Smiley.toerist (talk) 13:54, 25 February 2014 (UTC)
If K.B. had nothing to do with the creation of an older version of this work, he should not be stated as an author. The description page should state clearly who the creators are and what country's law is invoked. 70 years after publication can apply when the identity of the creators is unknown. If the identity of the creators is known, in many countries the copyright is 70 years after death, irrespective of who owns the copyright. -- Asclepias (talk) 14:51, 25 February 2014 (UTC)
It always comes back to this legal idea that there is always a single person or group of individual persons atributable for copyright. This is nonsense with dictonaries, maps, travelguides, etc, wich are created in a group proces. Take the case of mapmaking. There is a whole proces of gathering the geografic information, precise location, streetnames etc. In the end there is nothing creative in processing the information into a map. If another group of people uses the same processes en procedures the result wil be the same, except for human errors. What is creative is the proces itself, the symbols used, colours, layout etc. That is what is instanly recognisable in a Michelin map, not subject the area. In other collective works such as newspapers, there is no clarity what part a journalist has written and the later changes by the editor and other staff. Unless it is specificaly signed by an author, it is collective work. Wikipedia foundation lawyers should provide clarity and guidance in this.Smiley.toerist (talk) 00:02, 26 February 2014 (UTC)
I recently had the problem, that multiple translations of file descriptions on a gallery page quickly look absurd when using template:en, template:de, a.s.o. When I searched for a solution in the help pages, the thing proposed on Commons:Language templates is the one I used and that creates that problem, since having the multiple language versions each in a separate template can't produce an element around all of them with the class="multilingual" that would be necessary in order for the language select gadget to work. I soon found the template:mld that solves this and is used on several featured images. Now I guess our help pages need some improvement here - and maybe constructions using template:en, template:de, a.s.o should be updated to use template:mld, template:LangSelect or similar. Do people agree here? or why not?--Scanmap (talk) 18:16, 26 February 2014 (UTC)
The language select also works if multiple of these language templates ({{En}}, {{De}}) are listed consecutively. Just if some invalid HTML is produced, it may behave weird. {{LangSwitch}} has the disadvantage that the text in languages other than English (which is the content language of Commons) is usually not indexed. If a gallery should be translated, I think the best way doing so now is using the translate extension. -- Rillke(q?)16:20, 27 February 2014 (UTC)
I usually try to stay away from template:mld. I do not understand what it does or tries to do, but I notices that when used with images it was hiding descriptions in some languages. The issue was that it was hiding some of the English (my default) descriptions as well. --Jarekt (talk) 16:35, 27 February 2014 (UTC)
Mld has nearly the same output compared to using single language templates ({{En}}, {{De}}), except that it has a wrapper <div class="multilingual" consequently grouping the translations together. However, it should be updated to use Lua, iterating over all arguments instead of these if-constructions. -- Rillke(q?)17:16, 27 February 2014 (UTC)
I think Mld template triggers some javascript which hides some parts of the description. I spend a lot of time at some point trying to figure out why some text I added would not show up in the file description. I think it is related to meta:Meta:Language select because I moticed that adding "ls_enable = false;" to User:Jarekt/common.js fixed the problems. --Jarekt (talk) 17:30, 27 February 2014 (UTC)
Never use LangSwitch for image descriptions!!! LangSwitch was created to present warning messages etc. in the browser's chosen default language, and is not too suitable for other uses. There are many reasons why people would want to see image descriptions in languages other than the language they've chosen to browse Commons in (to check translations, for example). AnonMoos (talk) 05:39, 5 March 2014 (UTC)
aka Sarr Mountains. What should I do? Is there a Šar Mountain (singular) and also Šar Mountains or Sarr Mountains (plural)? I've gotten myself confused.
Sorry to bring this up again, but considering this photographer appears to have changed her license from the original CC-BY-SA release, see the full discussion here, not directly in the flickr software but by the manual posting of noncommercial restrictions on almost all of her Flickr image pages, would it be okay if I added the {{Flickr-change-of-license}} template to all pictures in this category? For me personally, it'd help to remember the older discussion so I don't accidentally nominate the images again should I forget. TeleComNasSprVen (talk) 09:28, 6 March 2014 (UTC)
Paid contributions discussion at Meta-Wiki
There's a discussion at Meta-Wiki with regards an amendment to the terms of use with regards to the need to disclose paid contributions, as a foundation initiative adoption of the amendment will affect all projects, including Commons, buried in the discussion is a short section with regards how the new amendment will affect Commons ( m:Talk:Terms_of_use/Paid_contributions_amendment#More_hypothetical_examples.2C_from_Commons_and_OTRS), I've added my 2cents to the effect of as long as scope, copyright and licensing are correct we don't mind who or why users choose to donate file to us. I think it needs a few more voices to comment from here as so far most of the debate is concerned with Wikipedia.--KTo288 (talk) 15:07, 6 March 2014 (UTC)
Potential copyvio with Rickey Henderson image?
The license for the image File:Rickeysteal.jpg says it was released into the pubic domain. However, the claimed author is a banned sockpuppet and the image itself doesn't have the feel of one taken by a "civilian". I'd use the {{Lrw}} template, but I don't have a website where the image might have been taken from. There are other uses of this image on the Internet here and here, but I suspect those aren't the original.
I'm not sure of the proper place to ask this question, so I'm doing it here. Thanks. — X96lee15 (talk) 17:33, 6 March 2014 (UTC)
The full resolution of File:Ecuador-234.jpg has correct colours, but the thumbnails (all sizes) are blue. I tried doing a small edit and re-upload of the image, but the problem persists. Anyone know why, and if it can be corrected? Thanks! - MPF (talk) 00:04, 5 March 2014 (UTC)
Hmm, looks like part of the problem was that the original colour profile was invalid, but the thumbnailing process "fixed" it, so it was only taking affect on the thumbnails ([1] vs [2]) Bawolff (talk) 22:48, 6 March 2014 (UTC)
Renaming multiple files?
Are there any tools available to help rename multiple files?
I did a batch upload last night, but the experimental GWtoolset software didn't quite give me the filenames I'd requested (it trashed all the punctuation).
I've renamed the first 50, but it's miserable, and there's still another 380 to go.
The intended filenames can be found in an extra field gwtoolset-title-identifier that the software has added to the {{Artwork}} template (though apostrophes have been replaced with '); or I can make a separate list of them as a text file.
Also is there anything that can put the fields of the {{Artwork}} template into their usual order, and complete the set of any missing basic ones?
I have the permissions for AWB, but I haven't yet got round to using it. Is this the kind of thing that AWB could help with? Or that anything else could help with? Jheald (talk) 20:17, 5 March 2014 (UTC)
On reflection, I'm thinking that the easiest way forward is probably going to be to try to persuade the GWtoolset developers to modify the tool, and then just to re-run the entire upload from scratch with the correct filenames (and better formatted wiki pages); and then just get a friendly admin to batch-delete all of the old misnamed ones. Jheald (talk) 06:44, 6 March 2014 (UTC)
Do you need to change the filenames? the names do not need to be perfect, just unique and not misleading. I do not know any batch tool to do it. As for modifications to the {{Artwork}} template, lets discuss it at the template'e talk page. it can be changed but you need to be more explicit about what to change and why. --Jarekt (talk) 17:51, 6 March 2014 (UTC)
That's a horrible story!! The metadata was lifted straight from the BL Images Online site -- perhaps they thought the pic would sell better under the happier title 'Masquerade' ? Note that there are other catalogues (sometimes) linked in the BL Image credit template in the source section, that can be more revealing. Jheald (talk) 11:06, 7 March 2014 (UTC)
OK: Fixed/Fixing.
I found that I could sort out the wikitext layout issues with a tempate hack and an AWB run; and the renaming isn't so miserable now that I've made myself a list of the names I want in the right order.
I am therefore not any longer planning a reupload that would re-set the content of these pages -- they are good to link to or to edit, and the edits should not be over-written.
The wikitext of the description pages should be more readable now. As for the filenames, I have now renamed about a quarter, and intend to do the rest over the next couple of days. Links to the present names should auto-update, I think. I'll also be going through trying to pick up 'other versions' more systematically, & wikifying & trying to better fit the categories into the existing category structure.
Everyone who wants to jump in and use the images or better fit them into the wiki structure is very welcome. I think they're a great set of images, going all the way from 10,000 BC up to the First World War, so there's a lot of interest there. Jheald (talk) 11:06, 7 March 2014 (UTC)
I have a nice bit of Python script to take any category and do a regex based name change on any matches. Someone knocked together an online tool to do something similar and it's the sort of thing that OAUTH is useful for. Another topic vaguely on my personal backlog. If you have another large number of renames that can be solved with a regular expression match, drop me a note or email and I'll run it for you or email you the code back so you can play with it. --Fæ (talk) 11:17, 7 March 2014 (UTC)
As an apparent problem, somehow created at the end of last year and continuing ever since, persistent "HTTP Error 503: Service Unavailable" errors are dogging large quantity transactions with the WMF servers. This has been raised on bugzilla and discussed on the village pump previously. I am unsure if this remains more of a problem when attempting to handle transactions from Europe or if the problem is just as severe for users in the US. As has been establish previously, this seems unrelated to transaction size and this problem did not seem to exist before the end of 2013.
One consequence is that any bot transactions now need to have a highly defensive approach to transactions with escalating levels of looping suck-it-and-see type tests every time a bot would like to update a page, upload an image or otherwise commit a change to WMF hosted data. This has significantly increased the barriers for new bot-writers attempting to help the project.
Could the community have another easy to understand update from WMF development on the current thinking on why this is happening and if any solution is being worked on? --Fæ (talk) 14:56, 6 March 2014 (UTC)
(For the record, don't work for the WMF, so this is not an official "update from WMF development", but just my own opinions). Around November 2013 (bugzilla:57026), there was a bug report of several people getting a lot of 503's (503 being a generic unspecific timeout error, indicating something somewhere took too much time in a very vague way). That issue was caused by certain extensions (e.g. SpamBlacklist) decided to re-parse the page on save to get the information it needed, instead of just doing it once and sharing the result. Multiple extensions doing that caused page saving to take a very long time, and go over the limit. That issue should be fixed now. Given the timing of when you reported your issue, I believe it was lumped with the above mentioned issue. If you're still experiencing issues, its probably a separate issue then what was affecting the other people. As far as I am aware, nobody is working on the specific issue that you are experiencing (However I don't keep track of everything that goes on, and this is leaning towards an Ops concern, which is an area I don't exactly keep track of).
503 errors usually include in the response body some extra technical details. Its usually a good idea to report those when reporting issues like these. It looks like the number of 503 errors currently being issued is relatively low - around 30 a minute, which is low compared to how many people visit the site (blue line. Although over the longer term, there does seem to be the occasional spike).
"I am unsure if this remains more of a problem when attempting to handle transactions from Europe or if the problem is just as severe for users in the US. "
If you're curious, that's easy to test. You can force your computer to connect to the US (Virginia - "EQIAD") servers instead of the servers that are geographically closest to you by adding the following to the end of /etc/hosts:
(208.80.154.240 is upload-lb.eqiad.wikimedia.org, and 208.80.154.224 is text-lb.eqiad.wikimedia.org.) There's always the potential for WMF to change which IP addresses its servers are at, so if things stop working, remove that configuration before complaining. If you do notice a difference in the number of 503's encountered when connecting to a different server, that would be really interesting. Bawolff (talk) 22:31, 6 March 2014 (UTC)
I'm inclined to say that it might. The stylized hooks at the end of the letters, the breaks in the o's and the slight yellow coloration on the tip of the second o - all these combined leads me to say this might not fall under the threshold of originality. As to the Big Lots one, I'm not really sure but in my opinion that can be uploaded to Commons. TeleComNasSprVen (talk) 05:38, 7 March 2014 (UTC)
For some odd reason, when i tried uploading it earlier, i was told there were some errors, a few minutes ago i found the image on my upload list, weird cause i could not see it on my watchlist...then when i cropped it a bit, i saw this below the image "(The revision #0 of the page named "Scott Ludlam May 2013.jpg" does not exist. This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log)", the deletion log is empty..when i tried to add a category, it wouldn't allow it but the funny part, it has no history....could a techno guy explain? --Stemoc (talk) 07:57, 7 March 2014 (UTC)
@Stemoc: , please add a file description page. This is now possible. Suggest you copy it from one of your other uploads. This bug is getting slowly annoying. -- Rillke(q?)11:32, 7 March 2014 (UTC)
Hi at all. In this category I don't know what is happen. Now there are a lot of files and some subcats they are not historical. I tryed to remove them: it's impossible! What is happen? What can I do? --DenghiùComm (talk) 09:16, 7 March 2014 (UTC)
As a spin off from my multi-language World Digital Library uploads, at the weekend I started uploading selected collections of early works from the US Library of Congress (thanks to their xml metadata), see above two example categories. These include both jpeg and tiff versions of the same image. The advantage of uploading both, is that the jpeg renders nicely both on Commons and when transcluded on other Wikimedia projects, while the tiff provides a very high resolution version which is suitable to research details within an image, or to create new derived works from, but is not rendered as well by the MediaWiki software as it is provided as a lossy jpg unless you download and read in your own tools.
I am following the approach used by the excellent NARA project which had the same challenge, by:
Upload both .jpg and .tif versions
Prefer categorization on the .jpg version
Use the other_versions parameter to link both together
I feel this solution is "okay" but not "great" and as I am still at the stage of several hundred images rather than several thousand, I would appreciate any suggestions, in particular if we should adopt a rule of thumb on how best to categorize such pairs of images so that the main parent categories are not loaded with endless twin images which might confuse the casual re-user, or if we might add a meaningful standard notice to the files. --Fæ (talk) 09:27, 3 March 2014 (UTC)
My rule of thumb: Add TIFFs/JPGs to the same category; use the exact same filename for both (minus the extension obviously).
This will ensure that both images stay together at all times. Even if it might seem like duplicates to the layman, this is a minor drawback as it will greatly simplify maintenance work. Otherwise there will for sure be cases like "image.jpg" is located in category "A"; "image.tiff" in category "A/TIFFs"; "image.jpg" gets moved to category "B"; "image.tiff" stays in category "A/TIFFs" though since it is overlooked. This situation exists already for specific "SVG graphics" galleries which get created to separate raster graphics from vector graphics and in the end it only results in categorization being messed up and equivalent images being scattered across different categories. --Patrick87 (talk) 09:56, 3 March 2014 (UTC)
By the way, though I am uploading jpgs and tifs with the same core filename, the Commons API throws up an error (cryptically, "exists-normalized") when attempting to do so. I have had to customize pywikibot to get around this, which seems a bit hackish and a high barrier for other contributors, considering we actually want uploaders to do precisely this for images of the same artefact in usefully different formats. --Fæ (talk) 10:32, 3 March 2014 (UTC)
Is that "exists-normalized" a warning that you just have to resubmit with an override, or did you have to play some really ugly game to get around it? I haven't yet looked at any pywikibot source code. I can see why that condition should fail for most automated uploaders, so that bots don't blindly decide that they should "own" whatever filename they wanted even when someone else has uploaded another file with a similar name: But perhaps there should be code in the mainstream pywikibot that can:
let novice pywikibot users have a couple of settings like "allow filenames versions with same base name if you own one of the other versions" (maybe set to yes by default?) and/or "allow filenames with the same basename uploaded in the last 24 hours", and have pywikibot go find the other page names, so a novice can't be inconsiderate to anyone but himself or people likely participating in the same upload project.
This is arcane tech talk than village pump stuff, so going small... I have 3 machines with pywikipediabot installed, my hacked around version is about 18 months old, and I have not documented the odd bit of patch that I introduced to solve particular problems as they have arisen. The relevant module is upload.py and in that is a function called upload_image() which nicely handles bot uploads. It has a series of if/elif statements and I have just added a trap there for the warning message "exists-normalized", which did not exist in my version of pywikipediabot and does not seem to exist in my more recent versions either, so without my work-around it would halt any batch uploading with a user prompt for a y/n request to proceed and giving a disappointing blank message as explanation of what you are saying y/n to. In summary, a bit of Python code clean-up would be nice, but I suspect maintaining pywikipediabot is not a priority for most developer types and I tend to be busy with content rather than real back-office stuff. --Fæ (talk) 14:35, 3 March 2014 (UTC)
I like the NARA scheme we've used so far to prevent diverging/unsynchronized categories. Fæ obviously knows about this system, but for those that don't know: As part of the Commons:National Archives and Records Administration project, bots eventually upload both the TIF (.tif) and JPEG (.jpg) versions of the same image, both sourced from the existing digital collection of NARA. To prevent the massive number of files from showing up as duplicates across many, many Commons categories, Commons seems to have settled into consensus that Category:NARA TIF images with categorized JPGs is the appropriate single category for a NARA .tif file, instead of full categorization, if and only if:
Both the .jpg and .tif have made it onto Commons with the same base filename. (This is important because the pairs are not imported synchronously; one version of the image might show up weeks before the other.)
The .jpg and .tif both link to each other in the files' information text. (The NARA bots do this automatically, so this shouldn't be an issue.)
The .jpg version has now been categorized properly. (In other words, don't just blindly wipe the categories from the .tif version: Make sure the good categories from the .tif made it over to the .jpg first.)
Note that .tif files, when they don't yet have an officially-imported .jpg version from NARA, do still get full categorization. (Also, this scheme only applies to original NARA files: Retouched images get the full categories on all versions, even if the user that did the work provided both a PNG/TIFF/lossless and JPEG version. Patrick87 mentioned this as a rule-of-thumb above.)
The .jpg ended up being the consensus choice to receive the categories only because that is the type that get used almost universally for thumbnails and embedding on wiki projects: The .jpg versions are high-quality versions originated by NARA. Automatic thumbnails/resized JPEGs have traditionally required far less server resources on the wiki when using a JPEG source than a TIF source, and (unless things have changed) the JPEG-to-JPEG resizing on wiki has tended to output better-looking article-sized images than the TIF-to-JPEG resizing does. (I think User:Fæ was alluding to that above.) Of course, when creating a retouched/modified derivative, the most-original version (the TIF) should be used as the source. --Closeapple (talk) 14:14, 3 March 2014 (UTC)
Why continue to make duplicates?
Thank you for bringing this issue up, Fae. I am hoping to begin NARA uploads again with a new, tweaked upload script and more images at my disposal, so this is something that has been on my mind as well. I've actually become more dissatisfied with our approach when doing the original NARA upload, and I would really prefer to have a solution that would allow us to upload only a single file. The duplication is not elegant, being both confusing from a user standpoint, creates extra work for the editors to maintain, and can make counting quite difficult.
Things have actually changed a lot since we first made the decision to upload JPG duplicates:
Some browsers used to open TIFF files in QuickTime rather than downloading, but I don't hear this complaint so much anymore
The current version of MediaWiki now displays a full-resolution JPG option for TIFFs, not just scaled-down versions. So for any large TIFF file, the more user-friendly download option is available without losing quality.
The megapixel limit caused many of the uploads not to display thumbnails, but that was raised first from 12.5 to 25, and then to 50, which is large enough to render almost any file on Wikimedia Commons.
The "Full resolution" link now reads "Original file," clarifying for users that they are downloading the large TIFF version if they click, not the JPG.
The first time around, the first three were the only real blockers that caused people to demand JPG versions be uploaded as well, and they have been solved. Is the only outstanding issue with using the master TIFFs on a wide scale in the projects instead of JPG derivatives what Fae and Closeapple have mentioned above, that "JPEG-to-JPEG resizing on wiki has tended to output better-looking article-sized images than the TIF-to-JPEG resizing does"? If so I think it is far more preferable to come up with a technical solution to that in the MediaWiki software than to continue uploading duplicates. (I think this is bugzilla:45212?) I was actually hoping to have resolved the need for duplicates in different file formats before I begin new uploading, so I don't upload more of these JPG duplicates that I hope (and expect) will be removed as housekeeping once the community decides standalone TIFFs are preferred. Dominic (talk) 05:57, 6 March 2014 (UTC)
+1 to prioritizing handling of tiffs for a better technical solution; especially as later this month we are due to make a public launch of the GWToolset which will enable GLAM professionals to release literally millions of images in one batch. Some of these projects are bound to have the tiff image issue which may leave us with astonishingly large backlogs, both in quantity and volume, by the end of this year. --Fæ (talk) 15:58, 7 March 2014 (UTC)
@Fæ: So what is the path forward? I'm willing to work on whatever would be the technical solution to sync any changes and categories from the JPG into the TIFF so they can be deleted/redirected when we wanted to undo the duplication. But, even though I'm happy if we started doing that now, I feel like I need more of a definite go-ahead from the community that that is something I should work on. And if there is still some MediaWiki quirk that the community thinks is a blocker, I want to know exactly what that is so I can put my energy into solving that. Dominic (talk) 04:18, 9 March 2014 (UTC)
I suggest that for larger GLAM batch uploads, say more than 5,000 images, where there are going to be a lot of "twin" jpeg and tiff files, that we have a template to highlight them. If the community does come to a consensus later about how better to handle their display, or if the MediaWiki software offers more options, then at least we can consistently and systematically have a bot make sweeping and useful updates to the batch uploads.
At the moment we use other_versions to link the images to each other, and perhaps the simplest thing we can do is wrap each of these two-way links in a {{tif twin|<filename>|<ext>}} wrapper to display the thumbnail link and to provide us with more options of both listing, categorizing or adapting-by-bot if needed later on. This also clearly distinguishes "twins" from other derivatives that may be created from the tiff original.
Does this some a reasonable minimal step and something we can point GLAM professionals to as best practice when they use the GWToolset? Such a minor adaptation of our current practices would not seem worth an RfC, but at least shows we are prepared to comply with future improvements or standards. --Fæ (talk) 06:53, 9 March 2014 (UTC)
If it's still true (as I assume it is) that we can't render all TIFFs, then that would seem to be a problem for the single-file approach. (Of course it's quite difficult to write software that can display all theoretically-valid TIFFs produced by all software.) AnonMoos (talk) 22:08, 7 March 2014 (UTC)
Is there any way to make a tally of all the TIFF tags that our TIFFs use? I think a large number of TIFF features just aren't used, and many of them (like all the fax features) are probably not used here.--Prosfilaes (talk) 22:51, 7 March 2014 (UTC)
Not sure that would solve the problem, since we don't have control over the format of the TIFFs that are uploaded here, and even if they don't display as thumbnails, we generally won't rewrite them (since TIFF is an archival format). AnonMoos (talk) 02:01, 8 March 2014 (UTC)
How about add a Mediawiki function to merge .jpg and .tif to a single page, so that no need to add category or to edit description twice.--維基小霸王 (talk) 10:55, 8 March 2014 (UTC)
@AnonMoos: I would support uploading JPG versions of all TIFFs that do not render, of course, because otherwise they are unusable on Wikimedia projects. But I'm suggesting we do it only for those files. The number of TIFFs which do not render, mostly because of the megapixel limit, is only in the hundreds, which is a tiny fraction of the total (we uploaded tens of thousands from the NARA bulk upload alone). This is a good argument for very selective duplication-as-JPG, not for doing it en masse. Dominic (talk) 04:18, 9 March 2014 (UTC)
Quality / quantity?
I was wondering if there are rules, regulations or a policy on the quality of pictures about a single subject? Or does Commons keep every picture ever uploaded as long as it has the right license?
Today I visited Category:Nina Dobrev and there I found over one hundred photos of this actress at Comic-Con events. Often many pictures with the same people sitting behind a desk. Of course I understand you would want a good quality photo of everyone at the desk, but you should still be able to cover that with 20-30 photos. Instead, here it seemed every photo the photographer had made that day was uploaded to commons. So, I am wondering if there are rules on the subject? As this problem (finding the few good pictures in a category filled with hundreds of mediocre ones) will only grow bigger over time. LeeGer (talk) 23:30, 8 March 2014 (UTC)
There are two possibilities to make good photos more prominent: Featuring the good ones or restriction of upload/ deletion of the "low quality" ones. As long as not completely unusable, I'd go with the first option; this however needs a simplified process for featuring content without the need for individual review by an experienced user. There could be something below QIC where every trusted user can simply press some star-buttons, I think. Thanks to Dschwen's fastCCI, we're now able to see categories filtered by featured content. -- Rillke(q?)00:03, 9 March 2014 (UTC)
The question isn't of course only about if photos are usable, but also about quantity. Now there are 150 photos in one category showing variations on the same thing: a row of actors behind a desk. Sometimes a lot of photos with the same row of actors in the same order behind the same desk. A few years and a few Comic-Cons later, that number might grow to 500 photos of people behind desks. 500 photos that don't belong in quality images, featured images or valued images but still usable photos. Will they all be used? No, some of them maybe, but most of them will probably never be used. So why not make a careful selection of the best photos in each set to keep? LeeGer (talk) 00:56, 9 March 2014 (UTC)
One cannot forsee every possible use case? Just imagine a magizine is writing something about an ear of one of the persons behind the desk and Wikipedia wants to show that ear in the article referrin to the magazine. -- Rillke(q?)10:54, 9 March 2014 (UTC)
I personally would prefer if we could keep them all, at least if we had a way to avoid having "extras" clog up the search results, and if we could perhaps have some kind of "category representative" shown for a category corresponding to such a picture set when it appears as a subcategory … —SamB (talk) 18:16, 9 March 2014 (UTC)
I don't know much about other types of works; but in biology, we have a practice in EOL, that every image is initially "unreviewed" and a subject expert can change it to "trusted". "Trusted" images are more useful than others. Jee11:10, 9 March 2014 (UTC)
I think the answer in this case is that someone wasted their time uploading a bunch of these, but they are harmless, and once we have them we might as well keep them. I can think of one case where I might be guilty of this myself: Category:EMP Oral History Live - Krist Novoselic. Had a good spot to get a bunch of pictures of a reasonably famous person, and didn't choose to be all that selective about which I uploaded. Sometimes curating the images would be more work than just uploading them, and I think all of these would be at least potentially usable by someone. In my defense, I think if you slideshow through these you get a stronger impression of him than from one image. I'm not sure that applies to the Nina Dobrev pictures. Jmabel ! talk18:14, 9 March 2014 (UTC)
March 09
Coat of arms of Mauritius
I want to seek the opinion of any of you here about an issue. This COA is not accurate and does not match the official description as well, you can compare it with original version of COA along with the official description on the government website here. So i tried to improve the COA to bring it closer to the original one and upload it as a new version of the file (see [3]). However User:Fry1989 reverted it by saying Please upload separately, i could not do this because there will be a duplicate of the COA with different name and the older one will still be widely use because it still hold the common name. The user later reverted it to the new one himself by saying I'll clean it up myself, then afterward he reverted it to the older one saying it is a Superior file and lately he reverted it again by saying Violates COM:Overwrite and other policies. I think we should have a proper discussion what should be done and stop these edit warring. Kingroyos (talk) 20:59, 4 March 2014 (UTC)
Your file is significantly different and not a significant improvement, COM:Overwrite applies. There is absolutely no reason why you can not upload your image separately, or discuss on the talk page instead of edit warring to keep your overwrite. Fry1989eh?21:08, 4 March 2014 (UTC)
Kingroyos -- Fry1989's version of File:Coat of arms of Mauritius.svg is more similar to the information I have in a book here (Guide to the Flags of the World by Mauro Talocci, revised by Whitney Smith ISBN0-688-01141-1), except for the saturation of the red in the scroll. Probably it's gone through several renderings since 1906. (Was it granted by the UK College of Arms?) Maybe the solution would be to separate things out by date... AnonMoos (talk) 05:25, 5 March 2014 (UTC)
I have no problem with the file being improved to look more like it does on the website and on passports and the such, but Kingroyos' version does not do that. It is choppy and uses horrible pseudo-3D effects and I do not consider it an improvement over the previous version. Fry1989eh?17:15, 5 March 2014 (UTC)
Whether you like the improvement or not is not a good reason, the one which you want to use is clearly a fake COA, both the shape of the shield and bottom banner is completely different from the original, the COA of Mauritius has never had such shapes, the colours of the new one is much more beautiful and match the official description, whereas the actual one doesn't. Also i tried to made a more realistic sugarcane, maybe you don't like it, but of course there is always room for improvement, you can tell me what can be done or simply add a request at the graphic Lab.Kingroyos (talk) 19:03, 6 March 2014 (UTC)
If you can remove the 3D effects and make if look more like this, that will be progress, but there are many problems with your image, the colours are not right, your shield is in 4 pieces when it should be one piece, the branches are wrong. What I would suggest is you do a graphic lab request and someone else can make it better. The biggest problem right now is your behaviour, you have edit warred constantly on this and are acting like you own the file. Your dispute is not actually based on any problem with the file, it's purely a cosmetic dispute. You need to stop acting the way you are. Fry1989eh?19:49, 6 March 2014 (UTC)
Kingroyos -- Maybe your plants are more naturalistic, but the evidence seems to be that in the coat of arms they bend over towards each other at the top, not go straight up... AnonMoos (talk) 00:38, 7 March 2014 (UTC)
Fry1989 -- First let me tell you, by reverting the file for different reason repeatedly without discussing the issue, you were also edit warring, it is clear you were reverting it mainly because you didn't like it and used different pretext to revert instead of coming straight to the point. I can't understand what is wrong with the colours, i use gradient colour to have an 'Or' colour instead of just yellow or brown, same for the other one as stated in the official description, i think it's much better, secondly i don't see any 3D effect which seem to irritate you. Also i don't know if you are familiar with vector graphics, in fact i first made the shield in one piece but later made it in four pieces because you can't apply four different colours in one bounded area, the four area will never be fill perfectly check it here. I'm also kindly requesting you to STOP removing the template about the COA accuracy dispute until a solution is not found [4].Kingroyos (talk) 16:44, 7 March 2014 (UTC)
You don't have a clue what you're talking about and it's clear you can't make any arguments for your image without attacking my motives and therefore myself. I have nothing more to say to you, your file is wrong and your dispute is a cosmetic dispute. Fry1989eh?18:22, 7 March 2014 (UTC)
Kingroyos -- Using SVG gradients to represent simple (non-"proper") background and charge "tinctures" on shields in heraldic images can be rather controversial. French Wikipedia has standards that require an overall pseudo-reflective gradient on the shield in most SVG coat-of-arms images, but many think that this makes things look ugly and non-heraldic (transforming "argent" from white into a dirty grey, etc.), so that sometimes different versions of coats of arms images are kept in place for use on French Wikipedia (with pseudo-reflective gradient) and on other Wikipedias (without pseudo-reflective gradient). See File:Blason ville uk La Trinité (Jersey).svg vs. File:Trinity-Parish-Jersey-Coat-of-Arms.svg or File:Blason Sainte-Mère-Eglise 50.svg vs. File:Blason Sainte-Mère-Eglise 50.svg etc... AnonMoos (talk) 22:01, 7 March 2014 (UTC)
AnonMoos -- There are lots of COA with gradient colours on wikicommons, i never seen users contesting them, the second image which you mention is the same one, but maybe its a mistake. I think the most important problem here is the shield and bottom banner which are completely fake one.Kingroyos (talk) 12:16, 9 March 2014 (UTC)
And by reverting the file repeatedly without any discussion and refusing to reply about your changes, you will also be reported for edit warring, vandalism and ownership of various files on Wikicommons and i know its not your first attempt of doing this. Kingroyos (talk) 08:13, 10 March 2014 (UTC)
Oh boo hoo, you think you have some dirt rap on me? Nobody cares, what matters is this file now and present. You are violating Com:Overwite, you are abusing a template wrongly, you are edit warring to make a pointy point that is invalid, and you're trying to intimidate me with a thinly-veiled threat of "I know your past, watch out I might bring it up!". Fry1989eh?19:02, 10 March 2014 (UTC)
User: Denniss deleted it as a "Test page or page with no valid content". Since I don't want to second-guess another admin, you should take it up with him. - Jmabel ! talk17:07, 7 March 2014 (UTC)
Which in my case I cannot see, not being an admin.
It would be useful to know more about what the technical issue was, since my uploads were apparently the first batch run that anyone's tried with the new GWtoolset beta software, which is due for public within this month. If it's something wrong in the uploader, or a glitch that can happen from time to time that the uploader needs to be aware of, that's something the developers need to know about.
Any idea why the image is still shown in the category? Both file and file description page must exist somewhere but they are not accessible for Wiki users. DB/Storage issue? The image page was created by me as a test, that sometimes triggered something and an image appeares again but not in this case. --Denniss (talk) 19:32, 7 March 2014 (UTC)
Something similar happened at File:Audio-mp3.svg -- when the new file version was uploaded in Sept. 2012, all previous history was gone, the image description page was blanked (until it was manually re-created), and the original file version was also gone (though it eventually came back)... AnonMoos (talk) 01:57, 8 March 2014 (UTC)
The file File:Smoking Crack.jpg has the face of the lady blurred. The source image listed on the page does not. Given that it doesn't really do anything to help protect the lady's privacy, does it really serve any purpose keeping it blurred? It would look better I think if we uploaded the original image. Zellfaze (talk) 20:53, 7 March 2014 (UTC)
A cropped version showing just the hands and mouth should suffice for the Wikipedia articles this is used in. On the file's talk page, someone questioned whether consent had been given by the subject. Rybec (talk) 21:22, 7 March 2014 (UTC)
I have boldly changed the image to a link on this page; due to its nature, I hope it can stay that way on the Village pump. My personal assumption would be that the photograph shows someone committing a crime in their country of residence, unless there is assurance otherwise then Photographs of identifiable people encourages us to consider potential issues of defamation, consent and the long term dignity of the subject, who we can presume is still alive. None is an easy issue, and we have no control over what re-users might do with this photograph. The simple precaution of leaving the face blurred, even if the link to the source currently shows the original unblurred, seems reasonable in this context and does not damage any potential educational value.
Note that the OTRS ticket is over 7 years old and the short email release mentions nothing with regard to model consent, neither does the source website as far as my brief reading could tell. If anyone has serious concerns about consent, they should consider raising a deletion request. --Fæ (talk) 23:12, 7 March 2014 (UTC)
What about removing the link to source? The Flickr link is dead. The other link also don't have enough license info. License information will probably in the OTRS; so a link to source is not a must. Jee08:54, 8 March 2014 (UTC)
I don't see any benefit in removing the link. Even if we agree that blurring the face is good, we shouldn't stop linking our sources just because they don't take precautionary principles as far as we do.--Pere prlpz (talk) 12:43, 8 March 2014 (UTC)
I believe that anyone can sell their photo to AP, in addition to releasing it on other "channels" with other licences. Hopefully Errera is getting some cash back from AP acting as their agent rather than AP just putting their stamp on a freely released image.
For anyone who was not aware, due to the successful project Commons:Batch_uploading/Airliners, this project is a global leader for reliable and free images of all aircraft, in fact we have 28 images of this aircraft in Category:9M-MRO (aircraft) that can support anyone reporting on the recent incident.
As an engineer that took part in production of the Boeing 777, a leading example of reliable and safety concious design, I was astonished by the news that this aircraft appears to have been lost. --Fæ (talk) 12:05, 8 March 2014 (UTC)
If AP took the image from Commons or Flickr and distributed it, crediting it to Laurent Errera/AP is not different from crediting it to Laurent Errera/Wikipedia Commons or Laurent Errera/Flickr as is often done.
I think that if AP and The Guardian were breaching a part of the license, it would be the "Share Alike" part more likely than the "Atribution" part.--Pere prlpz (talk) 12:17, 8 March 2014 (UTC)
If the image was taken from Commons or Flickr (without a special usage contract) then attribution it as Laurent Errera/AP is a breach of the licensing conditions, the same with not stating the license as cc-by-sa-2.0. The first is at minimum improper attribution, the second a violation of the share-alike part. --Denniss (talk) 12:25, 8 March 2014 (UTC)
Yes, "if". However there is no evidence that AP took the image from Flickr or Commons. They may well have approached Errera for permission, and negotiated an appropriate licence at that time. It is up to the photographer to make an objection (or ask for a correction or compensation) if this did not happen. Perhaps someone could apply our "used on" templates to update the image page (I can never remember the name of the right template for this). --Fæ (talk) 12:30, 8 March 2014 (UTC)
On Template:Location on pictures, the links to Google Earth and Open Street Map are broken. Only the link to Google Maps online is working. Jim.henderson (talk) 05:02, 9 March 2014 (UTC)
I've emailed the Toolserver admins, but it is Sunday. I suggest we wait for a reply or until tomorrow to take any drastic steps. Rodhullandemu (talk) 16:00, 9 March 2014 (UTC)
From: Matthew Raymond <mattraymond@earthlink.net>
Date: Wed, 15 Nov 2006 07:13:19 -0500
Message-ID: <455B045F.4090906@earthlink.net>
Henri Sivonen wrote:
> On Nov 15, 2006, at 12:19, James Graham wrote:
> http://whattf.org/ is a humor site. http://syntax.whattf.org/ is not
> a joke but isn't normative, either. Both are hosted by fantasai.
I notice it's using the Green Question Mark logo that I designed to
replace the old logo that too closely resembled the trademark of another
website. While I don't have a problem with its use in this specific
case, I would like to point out that the logo is NOT public domain, and
I'd appreciate it if people would ask first when using the logo for
purposes that are not directly related to WHATWG.
Please note that I have already informally licensed the graphic for
use as a logo for WHATWG, so it can use it in this capacity.
Received on Wednesday, 15 November 2006 04:13:19 GMT
What, if anything, should I do about it? In particular, is there some usual way to note such claims on a File: or File talk: page, like for previous deletion debates? —SamB (talk) 05:58, 9 March 2014 (UTC)
Don't we make it a point not to post the contents of email letters because they might be copyrighted? On-topic though, I agree with Rillke's suggestion to start a deletion request to gauge community consensus on this. TeleComNasSprVen (talk) 04:57, 10 March 2014 (UTC)
Hmm, nobody has done so yet; see Commons:Deletion requests/File:WHATWG logo (Matthew Raymond).png. (I elected to file a DR for just the image Matthew actually made, since the toolbox link makes this so much easier than manually filing a mass DR, and the tool linked from the mass DR page isn't flexible with page naming, and if by some chance the DR would pass I could make the necessary arrangements for the SVG version myself …) —SamB (talk) 17:17, 10 March 2014 (UTC)
Deletions due to perceived copyright issues
I had at a time uploaded several pictures I had personally taken for use in Wikipedia articles. I can only describe the pictures - all the pictures of rifle or handgun cartridges with the picture of the box in which they are sold. All pictures were exactly in the format of the following picture
.458 Win. Mag., .458 Lott and a .460 Wby. Mag. for comparison.
How does such a picture violate copyright laws? It does not. I would like an explanation as to why an admin would think it would. DeusImperator (talk) 01:18, 10 March 2014 (UTC)
Photographs of mass produced objects (such as modern weaponry or ammunition) would not be an issue. Product packaging often has graphics or even photographs and these are subject to copyright. Often the packaging is only a small part of a photograph (such as a portrait of a person who happens to be holding a box of ammunition) and then the De minimis guidance can apply, or sometimes the graphics are too simple for us to be concerned about (such as coloured strips or small arrangements of polygons). Interpreting these copyright rules is never easy and often creates disagreement. To discuss any particular case, the best place for advice is at Village pump/Copyright and if you are still convinced that an admin got it wrong in this instance, you can appeal any deletion at Undeletion requests. --Fæ (talk) 10:06, 10 March 2014 (UTC)
The images of yours that were deleted are:
Commons:Deletion requests/Files uploaded by DeusImperator - deletion reasons explained in the deletion request, but to summarize the elaborate and likely copyrighted graphics of the packaging is to prominent in those images for Commons:De minimis exception. Feel free to retake the photographs but without the packaging.
In recent weeks i have been searching for High Quality (HQ) images on flickr to upload to commons and one common trend is people no longer uploading directly to flickr but uploading via Instagram, that would mean Images will be available faster?....yes ..but with a BIG disadvantage, the quality of the image would be very very poor as Instagram isn't known to preserve image quality......... images which should have dimensions around 4000x4000 are now uploaded at a ratio of 640x427 so even if its uploaded to commons, theres' not much you can do with it as cropping it will just make the quality of the image much poorer...Good Bye Flickr...We will miss you...Love --Stemoc (talk) 02:14, 10 March 2014 (UTC)
So, apparently only people who cannot tell 4000×4000 px apart from 640×427 px will embark in this foolishness. Which will cause the fewer images made available as its original file through Flickr will be those photos taken by conscious and knowledgeable photographers, as opposed to random uploaders. Looks like a good thing to me. -- Tuválkin✉11:24, 10 March 2014 (UTC)
Even known photographers are doing this now..its faster though they don't realise that it is a problem for people like us..I recently cropped and used this photograph, generally that user uploads high definition pictures but now the quality has been compromised...--Stemoc (talk) 14:39, 10 March 2014 (UTC)
FYI: The English language Wikipedia is seeking input on orphan works
I uploaded a postcard of a painting. I couldn't find anything under the signature name. Can anyone recognize the painter and put a date on his death? The painting must be before 1923. I also adjusted the ligth levels, but I have no idea of the correct ligthing/colour for the original painting.Smiley.toerist (talk) 15:37, 10 March 2014 (UTC)
The signature seems to read "F. Coppola". Probably Francesco Coppola Castaldo (1845-1916) according to [6]. However, other sites show a different signature for this painter, for instance [7]. There was also an Antonio Coppola (1850-1916), but his signature is also different, and I don't think "our" signature here starts with "A". Lupo17:23, 10 March 2014 (UTC)
According to [8] Francesco Coppola Castaldo lived 1847-06-11 – 1916-08-17. Domenico Maggiore, Arte e artisti dell'Ottocento napolitano e scuola di Posillipo, Napoli 1955,[9] concurs. Lupo18:41, 10 March 2014 (UTC)
The pic "File:Niki Karimi - Derived.jpg" is just complete rubbish. It is a cropped version of "File:Niki_Karimi01.jpg" but in black-and-white. This woman is not dead yet! So there is no reason to keep this pic since the original one with colors is available. --88.78.116.17000:01, 11 March 2014 (UTC)
The licensing certainly allows derivative works, so if you don't like the image, you'll have to go through the normal process of nominating it for deletion. It's not a copyright violation, and your personal opinion that it is "rubbish" is not a reason to delete.
I think the crop looks better than the version where the beverage glasses, etc., are in the image. I don't have a strong feeling about the decision to take it to black & white, although it is not something I would have done.
I can't think what being dead or alive would have to do with this. Certainly Commons does not have any specific policy about preferring either color or B&W for living vs. dead subjects. Is there something like that on some other WMF project I'm unaware of? - Jmabel ! talk01:30, 11 March 2014 (UTC)
Getty Announcement
Simply put. What does it mean for commons? So far the only detail I can see is that the images will be available under an attribution licence, but it doesn't say which type. Flickrworker (talk) 21:46, 6 March 2014 (UTC)
BBCNon-commercial use only. It is a great marketing strategy to make money by charging anyone who might want to republish them for anything serious, such as in a book or in a newspaper. Of course many images are still copyfraud and are actually public domain - we tend to have better copies. --Fæ (talk) 22:04, 6 March 2014 (UTC)
This could be added to our Mediawiki:Common.css site css to make the commons logo in the top left look not shitty on high pixel density displays (i.e. "Retina" MacBooks etc.). It is not a super exact copy of the lowres bitmap (do we seriously not have a vector version of the Commons logo including the word mark?!) but it beats the blurry upscaled logo by far. --Dschwen (talk) 07:05, 7 March 2014 (UTC)
IMHO that should be supported by MediaWiki. Apart from that, please do not use SVG thumbnail, but, instead upload this as PNG. I do not trust rsvg and I don't dare to imagine what happens if updated next time. Also, what is the purpose of Retina displays if "standard" stuff look ugly? -- Rillke(q?)11:27, 7 March 2014 (UTC)
Support in MediaWiki should appear in the future, see Bugzilla:35337. In the mean time, enwiki (see bottom) already uses this method, both for 1.5x and 2x pixel density displays (I've updated the above code). The purpose is simple: to display the logo with better fidelity on retina displays; displays that have such high resolution that they actually use 2x2 pixels to render one "HTML" pixel. This causes the original PNG to display as if it were zoomed and appear blurred and blocky. The code calls a png rendered thumbnail from an SVG image, in this case the Commons logo. This causes the image to be upscaled directly from the source and display in its native resolution on these displays. You can test it by going to enwiki, then zoom your browser to 150% and 200% (works best in Chrome) to see the result. — Edokter (talk) — 13:45, 7 March 2014 (UTC)
Still opposed to rely on (lib)rsvg for the logo (uploading PNG copies would be okay). Why not using the SVG directly? Commons-logo-en.svg is only 3 KB (while the pngs are > 12 KB). Will this work:
Sure, that would probably be fine. I was just following the en.wp example, which uses png. We should check if they had that discussion before. --Dschwen (talk) 18:29, 7 March 2014 (UTC)
No, Brion just came in and planted it there. I tried using the SVG directly once and Opera has a sizing problem when zooming. What is the problem with rsvg anyway? It as already rendered and cached. — Edokter (talk) — 23:34, 7 March 2014 (UTC)
I don't think there is an rsvg-problem, but in the (distant) past we had some font issues with server-side rendered SVGs, and there was a lack of text-box support. I don't think an rsvg version with such severe regressions will be deployed (I have that much faith in operations). We keep telling our users not to upload images that are just downsampled or rasterized versions of images on commons, and I don't think we should do this either. --Dschwen (talk) 17:17, 10 March 2014 (UTC)
Ok, then go ahead. I just processed the logo with tinypng and the bigger one was shrunken from 17.2 KB to 4.5 KB and I really couldn't tell the difference, apart from that the original SVG only contains 3 colors (and the 4.5 KB PNG processed output has an indexed palette for 256 colors). But it's your decision ;-) -- Rillke(q?)06:50, 12 March 2014 (UTC)
Is there a way to show 3-D models in articles, I have some models of buildings in USA and Mexico, and would like to know what to do with them. The file format is sbx, they could be showed with Sketchfab.Victor.Aguirre-Lopez (talk) 19:13, 8 March 2014 (UTC)
There is currently no way to upload 3-D models to Wikimedia Commons. The only way doing that would be pasting the file contents to a regular wiki page and installing some JavaScript code that is capable reading the file format and rendering 3-D models. Since this is unlikely to happen, the best solution for now is the creation of an animation, exported as webm or ogv video. -- Rillke(q?)23:49, 8 March 2014 (UTC)
@Rillke: and how would one provide the source for such animations, which others would clearly need for a lot of the uses/changes they might want to make? —SamB (talk) 18:29, 9 March 2014 (UTC)
If it's below 500KB in ASCII or another encoding that is not squashed by MediaWiki, paste it to a subpage of a file description page (we're doing this with KML, for example) or you have to host it externally and add a link to the file description page. You may also want to vote for the bug or add your e-Mail address there. -- Rillke(q?)21:26, 9 March 2014 (UTC)
If we wanted we could do pretty cool things with JS alone. We could intercept the the upload of unsupported file types (at least in modern browsers with the html5 file-api) and instead generate a base64 encoded blobs which we embed in a file-page without an uploaded image. Going to that file page we could visualize the data through JS and make it look like a file was uploaded. Using these file pages as thumbnails could be done through an additional api call if a class="new" thumbnail is found on a page (see test on the right). Of course this would be quite a bit of work, but the main point is: it would be totally doable in a seamless way :-). --Dschwen (talk) 17:26, 10 March 2014 (UTC)
The main issue will be the size: You cannot create wiki pages over a specific size (I think it's 1, 2 or 5 MB); I was about to paste the POTY results as a JSON dump (very detailed including diffs etc.) but this failed because it was too big. Also, it's not desirable showing a huge base64 blob ;-)
Nice. Of course we would never show the base64-blob (it could be wrapped in a div with display:none). But yes, size is an issue. --Dschwen (talk) 19:14, 10 March 2014 (UTC)
If you plan to upload 3D models of copyrighted works such as architecture, carefully check the FOP rules for such models. For example, COM:FOP#Sweden only permits depictions of works, and a depiction is something in two dimensions (see SOU 1956:25 p. 264). A 3D model therefore doesn't seem to satisfy COM:FOP#Sweden, but needs permission from the architect or sculptor. --Stefan4 (talk) 01:51, 12 March 2014 (UTC)
Large map
Hi, I have a free geological map with the size of 120 MB at my desktop, but the limit seems to be 100 MB here. Is there any way to circumvent this? --Eleassar(t/p)12:32, 11 March 2014 (UTC)
Thanks. I've converted the map from png to jpg for now. Please let me know if this means a significant loss of quality. --Eleassar(t/p)12:48, 11 March 2014 (UTC)
See thread "Disappearing image" under March 7 above -- not that it really clears much up. I will upload another copy of this image, initially to the same filename, which may help clean things up; but just at the moment I have been focussing on other members of the set. Jheald (talk) 18:59, 11 March 2014 (UTC)
In my uploads from the World Digital Library, which has resulted in over 350 historic books uploaded to Commons, I have been left with 79 pdf files each of which is larger than the allowed maximum of 100MB. Splitting these makes little sense as the reader/re-user would want to browse the whole book rather than odd multiple files. The list of files with suitable titles and original sources is above along with the destination category where sub-100MB files can be seen is linked above.
In doing these uploads the images pages are in 7 different languages which seems to work rather neatly. Can my Faebot account have temporary approval to upload these via the API, or is there some odd work-around that can be applied? --Fæ (talk) 16:17, 4 March 2014 (UTC)
I'll investigate your suggestion when I have fewer things in the air; I recall past discussions about chunked uploading (which I think can be done via the API too) but never used this on >100MB files. As for the approval for an account to exceed the 100MB limit, that was an educated guess at what is possible, after all our 100MB limit on Commons is actually governed by local policy, rather than technical constraints or WMF diktat. --Fæ (talk) 17:49, 4 March 2014 (UTC)
Example of 105MB tiff (1800s cartoon) using the UploadWizard with Chunked uploads option.@Jarekt: It appears to hang indefinitely for me, using my test of a 105MB tif. I'll keep trying, but if it takes an hour per go before giving up, then it's a long winded thing to try. --Fæ (talk) 14:14, 7 March 2014 (UTC)
The second attempt (an hour later) succeeded, taking 20 minutes to upload the file, but then again hanging indefinitely at the "publishing" stage. The file was actually successfully published but the JavaScript could not cope. So, this route works but is not great as the in-browser behaviour may be unpredictable, and cannot be automated for batch uploads. A slight additional fly in the ointment was that I could not create the tif with the same name as the associated jpg, this is built in as a standard check and cannot be by-passed in the Wizard. --Fæ (talk) 15:20, 7 March 2014 (UTC)
I don't see anything in mw:Manual:User_rights that I would be able to change as a crat. It seems that the 100MB limit is set in the server config. As Jarekt said, chunked uploading would most likely be a way around that. I don't see why a bot would not be able to make use of that, too. Googling I've only found questions about pywikipedia support of chunked uploads but no answers yet. --Dschwen (talk) 18:21, 4 March 2014 (UTC)
Fae, simply ask techs to do it. Upload the files to somewhere they can be accessed individually (perhaps dropbox), do up the file information page, and file a bugzilla request like this. It's easy as pie. russavia (talk) 18:38, 4 March 2014 (UTC)
My understanding (Based on something vauge/half remembered from bugzilla, could be misremembering) is that the 100mb limit for non-chunked uploads is due to technical limitations (Something about http connections becoming unreliable after about 100mb). There are some reliability problems with chunked uploads, but often they work, and have a limit of 1 GB (Downside is sometimes they don't work. Which is quite sad. Someone needs to go over the chunked code with a fine tooth comb and make it actually reliable. Previous reports have indicated that PDF's, especially one's with large OCR layers tend to work in chunked upload even less than normal files). The upload wizard is just one method of using chunked upload, some bots can also make use it. Personally I recommend User:Rillke's excellent bigChunkedUpload.js script if uploading from the web browser (It defaults to overwriting an existing file, but you can change the filename to upload to an entirely new file). Bawolff (talk) 21:38, 4 March 2014 (UTC)
442 page 19C. book in French from the World Digital Library (248MB on-wiki, 320MB on my hard disk), uploaded using Rillke's uploader after some pre-processing using Adobe Acrobat.
Rillke's tool appears to fall over (at about 2% into the upload) for pdfs with the message FAILED: {"servedby":"mw1140","error":{"code":"stashfailed","info":"This file contains HTML or script code that may be erroneously interpreted by a web browser."}}
Uploading with a different chunk size or removing 'http://' from metadata references within the pdf seemed to not make any difference. --Fæ (talk) 14:14, 7 March 2014 (UTC)
There is various stuff interpreted by MediaWiki as "HTML". You can get an idea using File Analyzer. Unfortunately, it is not able to calculate the correct chunk size to avoid these issues, yet. -- Rillke(q?)14:37, 7 March 2014 (UTC)
Pumping the (320MB) pdf through Adobe Acrobat to delete all metadata seems to get over the 2% obstacle (at 30% as I write). Presumably there was some bit of metadata there added by the Library of Congress's pdf tools that MediaWiki was picking up on as a problem. If I have to pre-process each pdf in this way, which is not worth attempting to automate, then uploading the 79 books is possible, but it takes a massive slice out of my volunteer time at an hour to 2 hours per book, even if I can do other things while the upload is going on. Hm, WMUK has recently offered to pay for some FTP space, so it might be possible to find collaborative volunteers to help; though I haven't noticed a rush of spare volunteers for this sort of (slightly academic) work, compared to asking for photos of popular tourist destinations... --Fæ (talk) 14:53, 7 March 2014 (UTC)
Thanks, some nice toys to play with over the summer. By the way, the error I have been getting when accidentally trying to upload a 105MB file from the Library of Congress was:
uploading file to commons:commons via API....
Error downloading data: No JSON object could be decoded
Request commons:/w/api.php?
7th-century (Tang dynasty) document created from source png files and chunk-uploaded as an original pdf on Commons.
Yes, it's pywikibot output. I have tried setting up my own chunked upload function in Python, I had no idea that encoding a multipart file was such a glaring hole in standard Python. What a mess. --Fæ (talk) 18:02, 5 March 2014 (UTC)
The problem with an embedded url in the metadata only seemed to occur with that upload from the Library of Congress. I have completed several large uploads since then with little problem using Rillke's tool, see Uploads by Fæ (over 100MB), along with many pdfs having to be recompiled due to apparently poor choices in the way the original pdf was created, or compiled from scratch (effectively de-zoomifying the images) using source png files, see Books from the World Digital Library. Unfortunately a lot of this is inconsistent at the source and almost impossible to automate.
The links at the top right corner have vanished since yesterday. I thought it was just a passing glitch but it seems to be missing even today. Have tried cache purges, the links entered manually work though. Seems to be MonoBooks skin specific. Shyamal (talk) 08:07, 13 March 2014 (UTC)
On many occasions this week this and other wikimedia sites seemed very slow. Many pages never stop loading. The links you are missing might be related to the same issue, the page just never finished loading. --Jarekt (talk) 12:17, 13 March 2014 (UTC)
Proposed optional changes to Terms of Use amendment
Hello all, in response to some community comments in the discussion on the amendment to the Terms of Use on undisclosed paid editing, we have prepared two optional changes. Please read about these optional changes on Meta wiki and share your comments. If you can (and this is a non english project), please translate this announcement. Thanks! Slaporte (WMF)21:56, 13 March 2014 (UTC)
As Jee says, we are waiting to get a lot of translations before switching to the new text. The new version uses the Translate setup, and therefore lives in /i18n, /i18n/fr, /i18n/de & so forth. The old version had more than 40 translations, something to keep in mind before switching). Jean-Fred (talk) 14:06, 14 March 2014 (UTC)
Wikimedia Commons for Muzei
Wikimedia Commons for Muzei
Hi. I've written an extension for muzei which uses Wikimedia Commons 10 recent picture of the day randomly as dynamic background of your Android device. The extension source is here.
You should first muzei from Google Play or F-Droid. I didn't release the extension on Google Play yet so for testing it you should enable unknown source first (here is a guide for it) then install my muzei extension from here (click on the green button to download the .APK) file. I just tested the extension on my Android device so any feedback specially as an Github bug would be nice. −ebraminiotalk16:26, 14 March 2014 (UTC)
Unidentified railway by the beach
Is this in Australia, by chance? The darkyellow/red panel seems to be a British style seabathing condition signal, and the lifeguard tower says «State Parks». -- Tuválkin✉08:16, 5 March 2014 (UTC)
Indeed it appears to be in California. I traced the picture back to the original author's website. (top left image) On the photo's page, I could extract the co-ordinates from the HTML source. It appears to be in the vicinity of 33.41052296403486,-117.61070251464844 i.e San Clemente. Also, according to the author's website and other nearby Panoramio photos, the actual beach shown in the picture is known as "Calafia Beach". -- Rept0n1x (talk) 09:38, 5 March 2014 (UTC)
Just to clarify, the lifeguard towers in San Clemente, California also have "State Parks" displayed on them. Please see [10] for an example (click on image to enlarge). As can be seen it is an identical type of lifeguard tower as in the original photo. Also this page for further confirmation that San Clemente also has state parks. The original image has also been geotagged on the author's site with co-ordinates which lie in San Clemente. If it's any help in clearing this matter up, with the help of Google maps and Bing, I can attempt to verify the exact spot in San Clemente from which the image was taken, it is only lack of available free time which has prevented me from doing this so far. Regards! Rept0n1x (talk) 07:31, 15 March 2014 (UTC)
Some more photos around Amtrak southbound signal 2062 in San Clemente (as shown in the original photo):- [11](description here), [12]. Youtube video also shot at signal 2062 [13]. Also bear in mind that the San Clemente lifeguard towers can be moved around as shown here:- [14] so you might not necessarily see them in other photos of the same spot. For me this is enough evidence that the original photo is on the beach at San Clemente, but feel free to disagree of course. I am happy to investigate further if needed. Rept0n1x (talk) 08:40, 15 March 2014 (UTC)
OK I've now identified the approximate location of the photograph with the help of Google Earth. This street view link shows Amtrak southbound signal 2062 on Calafia Beach, San Clemente. The street view is taken from the nearby parking lot on Avenida Califia, so the relative angles of the signals and the "no pedestrians" sign are completely different. Nevertheless, you can just about on very close inspection make out the "2062" sign and also note that the supporting structures of the signals and arrangement relative to the nearby "no pedestrians" sign matches the original photo. Also, in the Google Earth application (as opposed to Google Maps), there are a cluster of Panoramio photos around the railroad crossing here showing similar views (e.g. this one with matching scenery) amongst a few others confirming this is the correct location. The other thing to consider is that photographs taken with most cameras give the illusion of shortened distances, particularly if some zoom is used as is quite possible here. We don't know how much zoom was used in the original shot (if any). However, as we can see a fair bit of the fencing on the left hand side of the original image and also this aforementioned similar image shows just a part of a concrete block on the extreme right hand side (which is adjacent to the steps down to the beach), it is quite probable that our original photo was taken from the official pedestrian crossing connecting the Avenida Califia Parking lot to the beach, which is approximately 50 meters or so (or yards if you prefer) northwest from the railroad signals. I will geotag the image accordingly shortly, with a "location estimated" template also on it. Thanks Rept0n1x (talk) 12:55, 15 March 2014 (UTC)
OK Thanks to User:JotaCartas, the geotag on the original Commons image was already refined on 5th March. (I have just noticed this). And it's also the location I concur with per the above investigations. So that's two of us separately identifying the photo as being in the same vicinity within San Clemente. In short, there is no doubt now that this image is in San Clemente, California at the position described next to Avenida Califia, so that's a wrap. Thanks all! Rept0n1x (talk) 13:05, 15 March 2014 (UTC)
Sorry to bring this up again, but considering this photographer appears to have changed her license from the original CC-BY-SA release, see the full discussion here, not directly in the flickr software but by the manual posting of noncommercial restrictions on almost all of her Flickr image pages, would it be okay if I added the {{Flickr-change-of-license}} template to all pictures in this category? For me personally, it'd help to remember the older discussion so I don't accidentally nominate the images again should I forget. TeleComNasSprVen (talk) 09:28, 6 March 2014 (UTC)
I don't want to engage on a mass change spree to all files in this category without some evidence of consensus first, but the discussion was archived without any input. I'd like to have more comments before progressing through with this. TeleComNasSprVen (talk) 21:04, 13 March 2014 (UTC)
I made a random check and all the photos I randomly choose have an OTRS ticket. AS I quoted in that previous DR, I had a conversation with her where she wrote "The files that have previously been uploaded to Wiki are approved for Wiki to host. Photos that are on my Flickr account that do not appear on Wiki must be requested by Wiki, and I will approve on a photo by photo basis. - Sharon Graphics" I don't know all of her files available here are covered in that ticket; anyway it seems she agreed for some uploads, may be through an informal communication with the uploaders. Jee12:47, 14 March 2014 (UTC)
Since I don't have OTRS perms, I can't check the validity of that ticket, but if it's assumed whoever is handling the ticket knows what they're doing, perhaps it was uploaded without restriction on that date and then changed later on the Flickr image description page. As you say, a license for Wikimedia to use is not necessarily compatible with a license for commercial entities to use under our CC-BY-SA license. In any case, I don't really want to re-discuss the merits of the deletion request, since I already accepted the outcome, but I want to make sure I got the green light from the community to mass-change files in the category to have the {{Flickr-change-of-license}} template. TeleComNasSprVen (talk) 21:32, 14 March 2014 (UTC)
New series of copyvios
Dear all,
Can an admin stop Tunis tunis (talk·contribs)? He again uploaded a new series of pictures and all those I looked at until now are copyvios taken on the web (satellite pictures marked as own work, pictures with tags of different photographers, etc.). I strongly suspect all of his uploads to be the same. As he already did the same some weeks ago and despite warnings on his talk page, it does not seem he understood the fundamental principles of Commons. Moumou82 (talk) 19:31, 14 March 2014 (UTC)
Are there any upload counters that keep track of how many images an editor has uploaded, similar to how edit counters track edits? If so, can anyone suggest some? Nightscream (talk) 21:30, 12 March 2014 (UTC)
it doesn't include the images a user has "uploaded" via Magnus or Bryan's flickr bot..that said, it doesn't seem to be working.. looks like wmflabs is down again .. O_O..--Stemoc (talk) 02:22, 13 March 2014 (UTC)
You could run an SQL-query on toollabs (MySQL workbench is an excellent software, especially on windows) or write a script iterating over your upload log via API upload log query (or for existing files, including overwritten). I can tell you that you have created 8257 files at Commons and of your uploads, 8374 files still exist (you've overwritten some files that's why the second number is bigger). -- Rillke(q?)21:56, 15 March 2014 (UTC)
Um, how do you use that tool? Is there a tutorial somewhere? I can't make heads or tails of all the jargon on that page, and have no idea how to use it. Nightscream (talk) 22:15, 15 March 2014 (UTC)
March 13
FoP-Russia
There is good news from Russia: recently a modification of the Civil Code with commercial Freedom of Panorama for works of "architecture, urban development, and garden and landscape art" (i.e.: buildings and structures, but not sculptures, plaques etc.) has passed all three Duma readings, the confirmation by the Federation Council, and has been signed by Putin; and is to come into force on October 1, 2014. (See [16], article 1276, only in Russian so far.) While we should wait till October 1 with the undeletions, I think we should from now on not anymore delete any pictures of buildings in Russia for the "no-FOP" reason, or at least not process the pending RfD's. Closer to October 1 we will also need to have the Template:FoP-Russia modified, as well as the map File:Freedom of Panorama in Europe.svg. Users who understand Russian may also see the related discussion on the Forum. --A.Savin19:45, 13 March 2014 (UTC)
Yes, because it deals not with images, but with the business process. CC-1276 regulates the commercial use of images, and has nothing about the photographing. --PereslavlFoto (talk) 21:55, 13 March 2014 (UTC)
The upload wizard for Flickr uploads says "Both the icons and license name that they used have to match one of the choices here." However, since the redesign a while back Flickr doesn't seem to use icons for licences, instead just conveying license information in text and linking to an explanation at creativecommons.org. Continuing to include a requirement that can't actually be met seems potentially confusing. Arms & Hearts (talk) 12:55, 14 March 2014 (UTC)
Both the "new experience" and "opt out to old experience" have icons, license names and links; even though they changed the layout. Jee13:09, 14 March 2014 (UTC)
Flickr can be displayed in two ways. If you are logged in, you see the licence at one place, with CC icons. If you are not logged in, then you see the licence at another place, without CC icons. This should maybe be updated. --Stefan4 (talk) 15:28, 14 March 2014 (UTC)
Oh, that's confusing. Without logging in I also can't find anywhere to "opt out to old experience". I guess whether it's a big enough deal to require updating would depend on whether a substantial number of Commons users don't have Flickr accounts? (Or, like me, once had an account but long ago forgot the details.) Arms & Hearts (talk) 23:03, 14 March 2014 (UTC)
Oh, but maybe not, after all (or any more): While unlogged, with the default skin, CC licensed images are marked with the "㏄⃝" sign instead. -- Tuválkin✉11:55, 16 March 2014 (UTC)
Yeah, to clarify, I'm not personally having trouble working out what's appropriately licensed and what's not. My concern is just that the upload form says "Both the icons and license name that they used have to match one of the choices here", which is a requirement that's often not going to be met, even for acceptably-licensed files, which seems likely to cause confusion. Arms & Hearts (talk) 12:56, 16 March 2014 (UTC)
Marked blank maps with indications of MH370 flight of 8 March 2014
Blank map of origin and destination points and last known ATC position
Blank relief map of origin and destination points, last known ATC position, and last reported radar contact
The Wikimedia Volunteer Response Team (also known as OTRS[1]) had an extremely busy year answering emails from Wikimedia users, readers and other interested people. We have once again prepared a statistical report of administrator activity and ticket volume for the year 2013.
I invite you all to review this report on Meta[2]. If you have any questions at all feel free to leave them on the talk page. If you wish to review the first report, published last year with data from 2012, you may also view that on Meta[3].
As part of my uploads from the World Digital Library, I have been uploading high quality pdf copies of 19th and 20th century newspapers. All of these cover revolutionary times in their countries and are highly political, some are deliberate and manipulative propaganda. Wikipedias in the various languages say little about these publications or their equally notable journalists, and these represent an ideal resource for anyone wanting to review and refer to direct accounts of the political change as it occurred.
Even if you do not read Spanish, Periódico El Mosquito is worth highlighting for anyone interested in early political cartoons and parody, as many international celebrities are derided in cartoon form. I would appreciate it if those active in the non-English language Wikipedias/Wikisources were to highlight this new resource on local village pumps. --Fæ (talk) 14:04, 17 March 2014 (UTC)
Non-English descriptions suppressed by English description
Select "show all"
Actually, if an image is described in several languages, using {{en|1=…}} {{fr|1=…}} etc. templates, all other descriptions are suppressed, if an English description is given. That phenomenon looks like a software mistake or a nonsense decision. --Ulamm (talk) 23:51, 15 March 2014 (UTC)+Ulamm (talk) 07:35, 16 March 2014 (UTC)
In many contexts, if you are signed in and have given a language preference, only your preferred language will be displayed. I suspect that is what you are seeing. - Jmabel ! talk07:48, 16 March 2014 (UTC)
The way, this language selection has been introduced, is not very friendly.
Instead of a clandestine introduction and hidden tricks to get rid of it, it ought to have been offered, something like "If you don't want to have such long lists of explications, you can select your favourite language, if it is available (1st choice, 2nd choice, 3rd choice)".--Ulamm (talk) 15:36, 16 March 2014 (UTC)
Thanks for the feedback. If you don't improve it, no one will, I fear. All scripting volunteers somehow lack time. -- Rillke(q?)16:40, 16 March 2014 (UTC)
I always want it to display "show all" (and have to manually reset it to "show all" practically every month nowadays, it seems), so having it set to the current browser default language with no way of adjusting would not be helpful... AnonMoos (talk) 03:12, 18 March 2014 (UTC)
"Cat-a-lot" is a great tool but it has one fault. If a file is moved to a subcategory the sort keys are moved with it. What often happens is that a main category is sorted by country in the sort keys (ex: France). When a new subcategory is created: "xxx in France" the sort key "France" has to be removed and replaced by a more local one such as "Lyon". It would be great to have a "sort-a-lot" tool, whereby one can select files and set the sort key. The files can then be seen in the rigth order. This way one can pre-sort a coming subcategorisation. Smiley.toerist (talk) 11:02, 19 March 2014 (UTC)
Maybe easier to make a separate tool. A listing of the category can then be shown with the sort key parameters. The files can then be selected and the sort key parameter changed. A sort refresh can then be made to show the files in the new order. This way files can easily be grouped together for a later Cat-a-lot action.Smiley.toerist (talk) 15:45, 19 March 2014 (UTC)
These are not heraldic flags, but actual coats of arms. They should be easy to find under categories named "Symbols of [Country]". Great photos, too, very interesting! -- Tuválkin✉10:58, 20 March 2014 (UTC)
I have a number of unopened bottles of beer, from around Europe, which I intended to photograph, before I enjoy consuming them (and then maybe a WMF grant for another batch..? ;-) ). I have been holding off, because of Commons:Deletion requests/Files in Category:Miniature liquor bottles, which has now closed as "keep". Is it now reasonable to assume that it is safe to upload pictures of beer bottles? Andy Mabbett (talk) 18:37, 17 March 2014 (UTC)
Hmm, a few of those photos I personally wouldn't have kept. Some of the labels seem a lot more complex than those in the Skyy case cited as precedent, were IMO probably subject to copyright, and were too central for de minimis to apply. (I'm not blaming the closer; they weren't given a lot of thoughtful discussion to work with.) I think it really depends on the nature of the label. -Avenue (talk) 12:10, 21 March 2014 (UTC)
Church bells
I am in discussion with the owner of a number of recordings of the bells of English/Welsh churches, with a view to them uploading them under open licence. To put it in lay terms (I'm no expert), they are rung in mathematical patterns of historic origin, so the "composition" is usually out-of-copyright. Is there any issue over performer rights? There seems to be no scope for interpretation, so I would hope not. Andy Mabbett (talk) 18:47, 17 March 2014 (UTC)
I'm no expert on performer's rights either, which is why I'm asking here, in the hope of getting advice from someone who is ;-) I note that we have several such files already, for example File:StClementsDanes.ogg (and I wonder if anyone can tell whether that's rung by people or a machine), but I don't want to negotiate a large upload and then find them being deleted. Andy Mabbett (talk) 14:31, 19 March 2014 (UTC)
I have a friend who does a lot of bell ringing and may be knowledgeable about the rights involved. I've invited him to contribute his knowledge here either directly or via me (he isn't presently a Wikimedian). Thryduulf (talk) 15:06, 19 March 2014 (UTC)
There is no reason to believe that performance rights do not exist for percussion instruments. This is a separate issue from the copyright of the music as mentioned above. There may be a De minimis case if the bell ringing is part of the background to an environment recording, however a deliberate recording of the performance would need a credible release from someone representing the group (such as the leader of a church bell volunteers team). An automated performance is less problematic as I think we could argue that the creative content was minimal in translating an out-of-copyright music score into a set of bell pull instructions. --Fæ (talk) 15:14, 19 March 2014 (UTC)
My friend has now replied, I've copied his comments below verbatim:
there is absolutely no question of 'performance rights'. When you learn to ring bells you are taught as a maxim that 'every pull you make is a public performance' - no-one pays to hear bells being rung at a church. Bellringers are occasionally paid for ringing at weddings or funerals, but when we ring we either use 'traditional' compositions that have been in use since time out of mind or if we use something that has a known composer we credit the composer with the composition but no fees are ever paid or have ever been considered to be paid to the composer. All 'true' compositions are released into the public domain for use by any ringer that can understand the composition. Here is an example:
5000 Red Dressing Gown Delight Royal
Composed by: Mark B Davies
23456 M I/V W H
--------------------
43526 2 -
46325 2 -
36245 2 -
26543 - 3
53462 - - 2
43652 2 -
23456 x -
--------------------
Contains:
5 567890
5 657890
67 LB5
130 3456/6543
77 2345/5432M
Composer's notes:
Designed to maximise little-bell music, although it does start
with two courses with the 6th fixed so the band can settle down
and enjoy the full coursing music of the back bells. The I/V
course is chosen to give the 1209876543 leadhead for the last
course.
Classification: Little-Bell
Also true to: Jennie's Endeavour London No.3 Raspberry Crumble
While your friend is no doubt knowledgeable about bell ringing and the norms within that community, I don't think their response touches on the legal side of things. I think we should establish what the law requires as well. A straightforward reading of relevant UK law (the Copyright, Designs and Patents Act 1988, Part II) seems to indicate that you need consent from the performer to record musical performances and to make them available to the public. Perhaps we can rely on cultural norms, e.g. to establish implied consent for hosting such recordings, if those norms are universal enough. If that's what we decide to do, I think we should also warn re-users about this. --Avenue (talk) 21:51, 19 March 2014 (UTC)
Andy, can you please clarify what you mean when you say your contact is the "owner of a number of recordings"? I assume you don't mean that he (or she) just bought a copy online, e.g. as I could from this site. Did he record them himself? --Avenue (talk) 22:25, 19 March 2014 (UTC)
Does anyone know what the copyright status of drawings of cars is? Basically if I used GIMP, Paint.NET or some other graphics editor to create an accurate digital drawing of a car will this count as my own work? Or will this count as a derivative work of the car's schematics?
A car is a "useful article" and (with rare exceptions) would not be copyrightable. So, your digital drawings are not different from photographs of cars—they are your works, not derivatives. Ruslik (talk) 12:49, 19 March 2014 (UTC)
Pictures of cars get a new copyright, and there is much less creatovity than in a drawing, so yes, you should get a copyright for this. Only accurate reproductions of 2D works do not get a copyright. Regards, Yann (talk) 03:13, 21 March 2014 (UTC)
{"servedby":"mw1017","error":{"code":"http-curl-error","info":"Error fetching file from remote source","0":"Received HTTP code 403 from proxy after CONNECT"}}
and when using HTTP:
{"servedby":"mw1017","error":{"code":"http-bad-status","info":"Error fetching file from remote source","0":"403","1":"Forbidden"}}
they can connect to themselves (image descriptions from commons on sister projects are fetched over http) however upload by url requests go through a proxy and that proxy has a whitelist of allowed servers which i guess doesnt include wmf servers. It should be easy to add to the whitelist, file a bug. Bawolff (talk) 18:50, 18 March 2014 (UTC)
I've found something which I think is interesting; if you paste the URL into your Windows Explorer or whatever in the "Browse..." field in Special:Upload, it appears you can directly upload any file by URL regardless if you have this userright. TeleComNasSprVen (talk) 07:43, 22 March 2014 (UTC)
Over at the c: Commons interwiki prefix RfC on Meta, it's looking pretty likely that the proposal's going to pass (it's running at 80% support with not long to go). As Commons has 22 redirects beginning with "C:", they're all going to need to be renamed or else become they'll become unusable when the prefix is enabled. May I suggest that they're all renamed to "CAT:..."? A couple of other wikis have done that so far. Do note that doing so will contribute to the general air of consensus for the new setting when the developers consider the final state of the RfC, so getting them moved quickly will be of benefit to Commons users across all projects!
Actually, most of them are shortcuts for "Commons:" namespace, and are duplicated by shortcuts with COM:. If there a tool to check whether they are linked from other projects? YLSS (talk) 13:51, 20 March 2014 (UTC)
"Shared publicaly" means PD, but maybe there are other licence issues. When you click on the licence it says: visible for everyone. For example can it be modified? Thats why I like the full licence details.Smiley.toerist (talk) 23:33, 20 March 2014 (UTC)
On here PD means Public Domain. On piccasa it means that it is visible to everyone, but that itself is not a valid license. Flickrworker (talk) 10:36, 21 March 2014 (UTC)
I will try to contact Jean-Henri Manara. He seems to put a lot of pictures on the web. He has an facebook account, only my facebook account is blocked. (dont ever forget the answer of the security question. You never can get back to facebook as facebook can only be contacted by a active facebook account)Smiley.toerist (talk) 12:17, 22 March 2014 (UTC)
OAuth Flickr2Commons Flickrreview tags
Hi, now that Flickr2Commons works again for everyone, I've noticed something problematic about the tool. It now uses OAuth, so the uploads now come from the user themself, not the bot. However it still adds a tag like {{flickrreview|File Upload Bot (Magnus Manske)|2014-03-20}}. Does anybody else think that this is problematic? I don't know if it's possible to fake "OAuth Uploader" edit tags (using the API), but if they can, then this kind of license review doesn't actually mean anything. Even if the tags can be guaranteed to be real, the message that this template adds doesn't really conform to reality. Should it not add something like a simple parameter-less {{Flickrreview}}? I'm also pinging User:Magnus Manske here. darkweasel9419:55, 20 March 2014 (UTC)
I just saw that it doesn't even add an edit tag (unlike CropTool). I think this is highly problematic; anyone can now upload a file that looks exactly as if it came from Flickr2Commons (you need to do so directly through the API to fake the edit summary, but that's not very hard), and there's no guarantee that the license review is actually valid. darkweasel9420:11, 20 March 2014 (UTC)
Thank you so much for your technical insight, Be..anyone. Darkweasel94, I have made the change to the "plain" template. That should get the User:FlickreviewR bot to make the appropriate edit. --Magnus Manske (talk) 22:31, 20 March 2014 (UTC)
Magnus Manske, somebody just pointed out on IRC that FlickrreviewR sometimes fails to determine the license the way the tool does it now. I don't know why that is so, but the current situation doesn't appear optimal either (though less bad than the previous one). If I may suggest something, you could have User:File Upload Bot (Magnus Manske) add the flickrreview tag for all files transferred through F2C after they've been uploaded, at least until FlickrreviewR gets fixed; as F2C appears to be able to recognize licenses correctly, this should work. darkweasel9408:12, 21 March 2014 (UTC)
That failure of FlickrreviewR is caused by an error in Flickr's database entry for that file: it has the width and height swapped. In addition to that, the file's EXIF data also has inconsistent width and height, and even different from the actual image size. The review bot then cannot find an image of that size. I agree that adding the "reviewed"-tag in a second edit from the upload bot account should be fine. Lupo08:43, 21 March 2014 (UTC)
This photo, File:Missionpeak.jpg, shows perfectly normal to me offline (using XnView), but once uploaded the EXIF box shows nonsense information, dumping a huge load of ASCII in the image title field. Should I try to reload? (Tried purge already, to no avail.) -- Tuválkin✉14:10, 16 March 2014 (UTC)
Actually, this is the caption field of the IPTC metadata. It's a base 64 encoded version of the thumbnail image. How it got there, I don't know, but I supposed it's an error in the software that created the image. You can use this base 64 encoder / decoder to take a look at the decoded data. It should be possible to remove this field in XnView, though I suppose there's not much harm in just leaving it in there. --rimshottalk14:55, 16 March 2014 (UTC)
I recognized it as Base64 but it should not be appearing in our #Metadata table at all: Not only it is needlessly huge, but it even breaks the table and prevents the rest of the page content to be displayed. I’ll reüpload it after expunging the internal thumbnail with Photoshop. -- Tuválkin✉20:52, 22 March 2014 (UTC)
The flickr bot appears to be failing images which are licensed as cc by 2.0 generic or cc by sa 2.0 generic, I notice. I don't know who can solve this problem. This is one example and the flickr backlog is now almost 1,000 images of photos that 'failed' review. Best Regards, --Leoboudv (talk) 05:57, 22 March 2014 (UTC)
Apparently, Flickr's recent switchover to using HTTPS instead of HTTP is causing a few systems to fail, such as our FlickreviewR bot up above. I've experienced similar behavior when I go to Special:Upload and I try to input an HTTPS-prefixed URL into the original source field and it returned an error (removing the 's' from https seems to work fine). Is this something that could be solved locally, or should I go to the devs and file a bugzilla report asking for HTTPS support for Flickr? TeleComNasSprVen (talk) 18:09, 22 March 2014 (UTC)
Traffic control centre
I you search for "traffic control centre" you find material but no categories. For the railway these are no signal boxes, wich only operate railway signs and switches for a limited local area. This is more for overall traffic regulation. Smiley.toerist (talk) 09:50, 22 March 2014 (UTC)
The problem is that there different levels of control and area. Dispatching is the closest to it. Local signal boxes are often closed down and replaced by a centre having a much bigger area. At certain level it also involves staffing en crewing the trains and coordinating trainmaterial use. More local is setting the points and trackroutes through the station (and wich platform the train will occupy).Smiley.toerist (talk) 00:04, 23 March 2014 (UTC)
Screenshot
Q.1. The english article Simpsons_opening_sequence contains screenshots. The images are not avaliable til all Wikipedias. I would like to use the images in the article on Norwegian Wikipedia. Is it legal to upload the images in the article to Commons? If it is what is the correct licence?
Q.2. Is it legal to take a screenshot of a YouTube page to document the amount of visitors on a given date and upload the image to Commons?
Thanks for considering the questions. --ツツ Dyveldi☯18:23, 22 March 2014 (UTC)
No, you can’t upload these screenshots to Commons. Commons only accepts free content. The English Wikipedia uses the screenshots as unfree content under a Fair Use clause. This is not possible here. See Commons:Fair use for more information.
It depends. If the screenshot only shows the title of the video and the visitor count, it probably is not eligible for copyright ({{PD-ineligible}}). Otherwise you’ll need a permission by the authors of the depicted works.
Typography Refresh will be enabled for all Vector users on April 1
Attention all users of the Vector skin! Typography Refresh, the beta feature that changes some visual aspects of the Vector skin (such as heading font and font color), will be enabled for all users who use Vector as their skin on April 1, with the roll-out of the next version of the MediaWiki software (1.23/wmf20).
You can get used to the new look of the site by enabling the feature in your Preferences; from April 1, it will be enabled for all users of the Vector skin as well as for the general public. If you are also a Wikipedia user, the feature will be enabled on Wikipedias two days later, ie. April 3.
I found a non-free file titled New Orleans.jpg at Wikipedia tagged as a candidate to be moved. I found a larger version and just uploaded it to Commons, and then realized that it is not a U.S. poster, it is Swedish. If someone knows the copyright status and it can stay at Commons, please revise the tag. Otherwise, please delete the file, titled Neworleans.jpg. Thank you. — WFinch (talk) 00:06, 24 March 2014 (UTC)
I don't want to overturn the outcome of this deletion discussion, but I disagree with the closing rationale for it. Taivo's closing comments leaves me less than satisfactory, "Having been approached by a number of organisations concerning this matter, RBH offers the design above which may be freely used by interested parties" is a very vague license. I'm not even sure if that can be considered a copyright license instead of a general use license (non-copyright, such as trademarks). Should we accept such a license at face value, or should we just adhere to the permissions standards at Commons:Declaration of consent for all enquiries?
Oh not this nonsense again. "may be freely used by interested parties" is extremely clear, and it's not supposed to be a "license" but rather a release. It makes it clear there are no restrictions on use commercial or otherwise which is fully compatible with Commons' licensing requirements. Fry1989eh?21:27, 13 March 2014 (UTC)
We don't need fresh eyes, we need to recognize that the owner has said "anybody can use this in any way they want for any reason" and that's about as clear of a release as it gets. Fry1989eh?19:35, 17 March 2014 (UTC)
[15:06] <Withoutaname> does free to use always imply free to modify and distribute
...
[15:18] <NotASpy> my interpretation is the image is fine to use, as a flag. If I want to use it for a designer handbag to sell to the good citizens of Berkshire, it might be the guy who designed it gets a bit pissed off and as we have no explicit release for commercial use or derivative works, he could cause a bit of legal trouble for someone.
[15:39] <Withoutaname> NotASpy: Can I quote you on that?
[15:39] <NotASpy> yes, certainly.
[15:41] <NotASpy> when I say "cause a bit of legal trouble" - I mean just that, threaten legal action, just be a bit annoying, rather than having a watertight case against someone for copyright violation.
User:Pierpao has just reverted my removal of {{Hiddencat}} from Category:Unidentified animals, claiming that "unidentified categories are usually hidden". As this seems like a very general topic that may need further community input, I'm raising it here. At first glance I could not confirm Pierpao's statement, I took a random sample of subcategories of Category:Unidentified subjects and most weren't hidden, though some were. Is there an actual policy or guideline on whether they should be hidden? If not, what is your opinion? I believe they should not be hidden for two reasons:
They should not appear "uncategorized"; that it's an unidentified X is already some defining information (after all we would consider "X" a defining category as well, so why not "unidentified X").
Readers who don't see hidden categories will, if they see "unidentified X", perhaps see that as a suggestion to identify it, which is helpful.
I don't believe User:Pierpao is right. We have appear to have 4521 Unidentified <something> categories. About 20 of them are hidden categories. These categories are part of the normal categorization tree so these shouldn't be hidden. Multichill (talk) 21:14, 24 March 2014 (UTC)
"Unidentified X" categories aren't maintenance categories though. They do tell the reader something topical about the image (e.g. that it shows an animal) - just perhaps not enough. darkweasel9421:38, 24 March 2014 (UTC)
Hi all,
I am Umang Sharma from IIITH (International Institute of Information Technology - Hyderabad), India and am interested in working for one the projects proposed by the community i.e. "New media types supported in Commons" as a GSOC candidate. I have drafted a proposal for the same.
This project has been a long standing community request and it would be great if I were given the opportunity to work on this and make some progress. I have planned a basic outline on how to approach the problem. I have decided to provide a solution for either x3d or collada file formats(required for representing computer graphics). I will work on the other if time is there during my project. However, I would like feedback on which file format is more in demand currently. Also, if anyone has any recommendations for efficient raster image generations do tell. Please go through my proposal and tell me how can I improve it and make it up to the expectations of the community.
Regards,
Umang -- 21:46, 24 March 2014 14.139.82.6
You need to hook up with the Wikimedia software developers. Anyway, you blanked the page at that link several days ago... AnonMoos (talk) 08:45, 25 March 2014 (UTC)
he has been in contact with some devs. So far there is some concern how to handle files with external references (eg textures). There is also not enough devs willing to mentor the project (projects are supposed to have two). User feedback (ie you guys) could help ensure the project does something useful to commons (if it is accepted). Having users liking the idea could potentially attract more devs to mentor (or it might not).
Personally i think it would be good for the proposal to concentrate more on use cases - survey types of 3d files, which are most likely to be useful on commons for an "educational" purpose. What features they have, what formats they are in, how they would best be displayed etc, thus making sure any work done actually addresses the needs in question. Bawolff (talk) 18:03, 25 March 2014 (UTC)
March 25
Repeated database errors
I've three times attempted to create Category:Kentucky Route 94 with text of [[Category:State highways in Kentucky|94]], but every time I get a database error.
A database query error has occurred. This may indicate a bug in the software.
What, if anything, can I do? I've created a few other categories in the last hour, and all of them created normally, without a problem. Nyttend (talk) 04:56, 25 March 2014 (UTC)
The default CC BY-SA license and how this affects the image metadata
TL:DR: As on (almost) all Wikimedia projects any text added to a page is automatically licensed under CC BY-SA 3.0 and GFDL. But which of the information does this actually cover?
I recently got a question from one of our GLAM partners wanting to include our WLM images in their database of cultural heritage. Whilst they allow various licenses for the images their metadata is strictly limited to {{CC0}}. The stumbling block appeared when observing that all of the information on each image description page is automatically dual-licensed as CC BY-SA 3.0 + GFDL, WMF's default everywhere apart from the two main name-spaces of Wikidata (as far as I know).
1. The first question is simply: Does the license really apply to all parts of the image description page (author, copyright value, WLM identifier, EXIF metadata etc.)
If we for simplicity limit ourselves to those file descriptions using {{Information}} I could see how the description could sometimes be copyrightable but for the rest of the fields (source, date, author, permission) such a limitation makes little or no sense. When we look at the exif-metadata etc. claiming copyright makes even less sense.
2. The second question is more forwards looking: Is this license really desirable for the metadata on the file pages. When a Wikibase extension is installed on Commons in the future allowing the file metadata to be better structured should this be combined with separating which data is CC BY-SA and which isn't?
An interesting conflict which arises due to this is that we try to argue that GLAM institutions should batch-upload images to Commons together with their CC0 licensed metadata/descriptions, and then promptly claim that this information is under CC BY-SA. This is something we would often consider to be copyfraud when others do it (see e.g. PD-Art). Further we often encourage GLAM institutions to make use of the corrections and additions to the provided metadata. If these additions are under CC BY-SA then they are essentially incompatible with the CC0 licensed metadata of the institution and any such corrections therefore become a lot less useful.
One easy way out is for GLAMs reusing Commons metadata is to note (somewhere in their terms of use) that the full attribution for text is available in a Commons metadata archive; it is probably sufficient so long as the photograph attribution is correctly applied. I hope it would be obvious that text/data taken from elsewhere that is CC0 does not have any additional creative content and so the blanked CC-BY-SA licence is not meaningfully applied to those situations.
It is messy, certainly it would be a great improvement if in the future, user created data added to image pages on Commons (but not the image) were to be CC0. The complication is when we are automatically reusing data from sources such as Flickr, where the Flickr description text is covered by whatever licence the Flickr user originally chose for their photograph. --Fæ (talk) 14:31, 24 March 2014 (UTC)
This is getting a bit off the main topic, but why do you think the Flickr description text would necessarily by covered by the same license as the photograph? --Avenue (talk) 21:34, 24 March 2014 (UTC)
When I try to set the license for my future uploads, the Flickr page says "This will apply to everything you upload from now on.", "You should only license photos you own the copyright on." It says nothing about the title, description or tags. I can edit those fields in future and there is no license confirmation messages as in WMF projects there for every save. The category search tags can be added by others too; if we allow to do so. So I think Flickr intended the license only for the media. Jee02:59, 25 March 2014 (UTC)
That interpretation would make the situation a magnitude worse, as we would have to default to All Rights Reserved, being the copyright of Flickr; not CC0. --Fæ (talk) 10:46, 25 March 2014 (UTC)
I checked the Flickr page once again and the license information is stored under "Additional info" where all other information are about the photograph and the "Content type" is clearly mentioned as "Photo". Jee11:03, 25 March 2014 (UTC)
Keeping track of the licensing/PD status of descriptions seems like it would be valuable, when we build a Wikibase database for Commons. (I think that would've been valuable for Wikidata too, but that's another story.) I think it's currently more common to just indicate the source of PD descriptions than to explicitly mention their PD status. This might be enough for human readers, but having machine-readable licensing information for our descriptions could make bulk re-use much easier.
The other {{Information}} fields (and EXIF metadata) are factual information that would generally seem unlikely to be protected by US-copyright. I presume re-users in the EU would also need to consider database rights, however. The CC-BY-SA 3.0 license seems to be silent about these (unlike CC-BY-SA 4.0, which I believe explicitly licenses them on a Share-Alike basis). --Avenue (talk) 22:30, 24 March 2014 (UTC)
An interesting question: If there are database rights for the metadata as a whole according to European law, who owns the rights to this "database"? As the individual image metadata contributions don't form a database, but only the aggregation at Commons does, maybe the WMF is the database rights holder according to EU law and would be able to release the "metadata database" e.g. under CC0, provided that the individual contributions to the database are considered factual information where the individual entry isn't copyrightable? Just a thought... Gestumblindi (talk) 23:21, 24 March 2014 (UTC)
Indeed an interesting questions. At a first glance, I think that there is no sui generis right for the database creator according to European law for the image metadata on Commons. This sui generis right requires a significant investment in the aggregation, verification or visualization of the database. Neither the Wikimedians nor the Foundation make such an investment. --ireas (talk) 23:58, 24 March 2014 (UTC)
The "Wikimedians" certainly invest lots of their time into their contributions, getting categories + licenses + sources + descriptions right is a significant investment. The WMF pays the servers + parts of the MediaWiki development, some developers contribute their work, and the result of all these efforts is allegedly CC-BY-SA, not CC0. I had to create the silly Help:RSS here as CC-BY-SA, because I can't simply copy it to mw:, where CC0 is required for help pages. –Be..anyone (talk) 00:50, 25 March 2014 (UTC)
Please don’t get me wrong – I don’t doubt that many people spend much time on the metadata, and I really appreciate that. (I’m doing the same thing on dewiki.) But this is about the legal subsumption. The copyright law was not made with projects like Commons in the mind of the politicians and lobbyists. It is difficult to determine if there is a sui generis database right and, if yes, who’s the owner. And as I wrote, that only was my first impression. --ireas (talk) 01:24, 25 March 2014 (UTC)
Also, the EU only recognises database rights in databases made by EU nationals/residents or EU-based organisations (unless they choose to extend this to another country, e.g. due to a reciprocal treaty). This might rule out the WMF owning such rights, along with many Wikimedians. Of course there are plenty of Wikimedians who are EU nationals or residents. IANAL, but I think some of them would probably have made "qualitatively and/or quantitatively a substantial investment in either the obtaining, verification or presentation of the contents" of our database of media metadata (to quote the relevant EU directive), although "substantial" is naturally open to interpretation. --Avenue (talk) 10:27, 25 March 2014 (UTC)
The possible consequences sound funny: So the EU database rights on the Commons metadata would be owned by a collective consisting of (only) those contributors who are EU nationals or residents and have done a substantial amount of work on the metadata (e.g. people involved in categorizing, cleaning up templates etc.)... In order to release the database rights under CC0, this collective would need to release the rights as a collective, I suppose, which seems practically impossible. As ireas wrote, "the copyright law was not made with projects like Commons in the mind of the politicians and lobbyists" indeed... Gestumblindi (talk) 20:22, 25 March 2014 (UTC)
The situation does seem odd. There would also be no EU database rights over Commons metadata which was created without substantial investment by EU nationals or residents, i.e. such metadata would be "public domain" with respect to EU database rights.
For the part that is protected, it might not be impossible to license the database rights for non-commercial use at least. I understand that (at least under US copyright law) any joint owner can license the entire joint work, as long as any commercial benefits are shared equally by all joint authors.
Alternatively, if we eventually decide to require that text contributions to Commons be licensed under CC-BY-SA 4.0, future metadata contributions would be freely available under that license. --Avenue (talk) 01:12, 26 March 2014 (UTC)
Help with Flickr set upload
I need help, please, to upload a Flickr set of around 470 open-licensed images. I have tried Magnus' "flickr2commons", several times, but it fails with the "null" error. I have GLAMWiki took rights, but have not yet received training. Andy Mabbett (talk) 17:23, 24 March 2014 (UTC)
It would be helpful if you could say which set you're trying to upload. Perhaps it has blacklisted or technically impossible file names. darkweasel9418:08, 24 March 2014 (UTC)
Um, yes, the filenames are blacklisted, just as I suspected: these have filenames starting with "_DSC", and these kinds of filenames aren't allowed for new files on Commons because files are supposed to have meaningful titles and "DSC" is a typical camera default prefix. In general, you can use "Prefix selected names" to prefix something to them to circumvent that. Unfortunately, in this case the underscore at the beginning of the file names will cause problems, because you will have double spaces (" _") after using this feature, which are technically impossible. So you will need to do the prefixing manually using JavaScript:
Load the files into Flickr2Commons.
Open your browser's JavaScript console.
Let it evaluate: var list=document.getElementsByClassName("newtitle");for(var i=0;i<list.length;i++)list[i].value="West Midlands Police Museum"+list[i].value;
The filenames will now be prefixed with "West Midlands Police Museum" and you should be able to upload them.
Thank you, I;ll try that tomorrow. However, I was using (as I was advised to) Flickr2Commons' built-in option to prefix the file names with more meaningful text. Andy Mabbett (talk) 23:23, 25 March 2014 (UTC)
Fatal exception of type MWException when trying to view Special:Watchlist
I seem to have run into bugzilla:39336. Is it just me, or are there general issues with the site at the moment? Special:EditWatchlist/raw works. Changing the days or maximum number of changes to show in my preferences does not appear to help. My watchlist has a little over 33.5k entries. I wouldn't mind culling it, if that's the problem, but there doesn't appear to be any way to sort the list by the date when each entry was added to the list. —LX (talk, contribs)20:18, 25 March 2014 (UTC)
Looking at the code of the patch recently submitted for the bug, a workaround for this bug is to turn off the "Group changes by page in recent changes and watch list" option in the "Recent Changes" panel in Preferences. This will get the watchlist working until the fix is deployed to the servers that run Commons. —RP8821:53, 25 March 2014 (UTC)
Anyone else finding it a bit to hard to navigate through the new design?. Its now harder to find "sets" as well and images load at a higher quality (Large) thus sucking a lot of internet data..it automatically changed to the new version for me just today, i was using the old version for a while now and its a bit harder to read licences too, you have to go through certain steps to find the information and to top it off, no "opt-out" option...looks like i would be using flickr less now (if at all) ...expect a lot of "nc-nd" images to be uploaded to commons as the new format makes it a bit harder to read licences for those who do not fully understand it such as the "by-nc" appears as " Some rights reserved" which users may assume to be "freely" licenced ..--Stemoc (talk) 02:12, 26 March 2014 (UTC)
Great, no one likes it..this is their 2nd Beta test (last was in Nov 2013) and people still condemned them and now they have done something very similar..people love simplicity cause simplicity always works, they can have an option to opt in but seriously, forcing people into a new format is ridiculous...I won't be surprised if this gets rollbacked to the previous version again..If wikimedia ever forced me into a new format, I'm out..--Stemoc (talk) 03:58, 26 March 2014 (UTC)
File redirects to files in different format / with different extension?
On the one hand I must admit that this would be a tempting way to replace a superseded raster graphics with its equivalent in SVG format, without having to mess around with GlobalReplace, CommonsDelinker or even manually replacing all global uses. On the other hand I have grave doubts about this approach because of mixing up file extensions (exploiting the fact that the MediaWiki software doesn't really know what a file extensions is and just handles it as part of the page title).
I tried to find something on this topic in our relevant help and project pages but I didn't find any info on "cross file format" redirects. That's why I want to ask what you think about this? Can you think of any other pros and cons? Should we allow file redirects between file formats or should we deprecate them and update the help and project pages accordingly?
Can you think of any other pros and cons?—I assume that this doesn't really work, and I'll be stunned if somebody has tested that it's actually no problem even with InstantCommons. ;-) –Be..anyone (talk) 11:45, 13 March 2014 (UTC)
Actually it seems to work when embedded – even with InstantCommons on non-WMF Wikis. Therefore technically this does not seem to be an issue (as mentioned before: MediaWiki doesn't know anything about file extensions, and so it doesn't care about the source or destination of file redirects). --Patrick87 (talk) 20:47, 13 March 2014 (UTC)
If it's no problem, why do we have all those convoluted "vector here", "compressed there", "png is elsewhere" templates instead of simple redirects? –Be..anyone (talk) 02:11, 14 March 2014 (UTC)
Because it would be a hell of a mess: First of all you'd need to move the original image (=nonsense and against policy if the filename is OK and the file was not already moved for other reasons before as in the example). Secondly you'll make it close to impossible to properly acquire global usage with all those obscure redirects in place (there are limitations in MediaWiki Software if I'm not mistaken). Thirdly you'll have "PNGs" embedded everywhere in articles only to realize they're actually redirected to SVGs which is highly ambiguous and might confuse editors. Even when simply renaming files we tend to replace the old filename with the new one in articles. Altough this might seem inconvenient in the first place I think this will subsequently save us loads of maintenance work. The longer I think about it the more I think we should not use this "feature" (who tells us that the MediaWiki software might not even recognize file extensions in future and will complain about all the "broken" redirects then?). But I still want to hear more opinions first (so comments please ). P.S.: Regarding the "convoluted templates": We wouldn't be able to get rid of them because it is Commons policy not to delete superseded images (as long as not very specific requirements are met). Instead we would convolute everything even more and make it close to impossible to understand the history of a file (e.g. why am I being redirected to an SVG file when I followed a link to a PNG? What happended to the original file? Where can I find it? etc.) --Patrick87 (talk) 10:20, 14 March 2014 (UTC)
Just as a note, you can't move a file to a different extension type. You can move foo.jpg -> foo.jpeg, but foo.jpg -> foo.png is not allowed. Creating a redirect named foo.jpg that points to foo.png is allowed. In regards to "who tells us that the MediaWiki software might not even recognize file extensions in future and will complain about all the "broken" redirects then" - I see no reason why we would change this behaviour. In particular, I highly doubt it would get changed if people started using it. Bawolff (talk) 02:06, 21 March 2014 (UTC)
The redirect is wrong and it should never have happened. We simply should not be cleansing away all evidence of alternate versions of files. It is wrong for us to think that we can control and direct what file types people should use. It is a practice of image censorship and we need to stop. The act of replacing duplicates is about exactly the same image in the same format, and that is the extent of duplicate. We can label and direct, however, if someone wishes to use a crappier version, or a different cropped version the LET THEM DO IT. — billinghurstsDrewth14:49, 27 March 2014 (UTC)
Files without license
Lately I was working with and thinking about files without licenses. Our handling of such files needs to be improved and there are several aspects of such files which I would like more people to think about:
How were they uploaded? Both are uploads from very inexperienced users and they managed to upload files without {{Information}} or any license. We should find a way to prevent that. I do not think you can do that with Special:UploadWizard but may be with Special:Upload or basic upload form. I do not want to eliminate the old upload forms but would like to prevent uploads without a license especially by first time users. --Jarekt (talk) 14:44, 26 March 2014 (UTC)
How? Easy. It happens to me frequently and is a huge drag to fix. 503 upload failures by the the WMF servers. Using the Commons API you pass the text for the image page and the link to the source file and the WMF servers upload the image and then fall over when attempting to load the text. The result is an uploaded image with a blank image page. As far as I know this type of failure can happen with any upload tool. --Fæ (talk) 06:56, 27 March 2014 (UTC)
That does not appear to be what happened in these two cases. The initial revisions of the file description pages are not blank, they just don't contain the required information. We used to have bots patrolling all new uploads for this issue, but I guess that's no longer the case. Wikimedia losing file description pages as a consequence of not handling uploads atomically is, I believe, a more recent issue. —LX (talk, contribs)12:13, 27 March 2014 (UTC)
I wonder if we can revive some old or write a new bot patrolling all new uploads. However I still wander what tools first time users might be using to upload such images. May be if we can steer them better towards Special:UploadWizard, we would not have those problems. --Jarekt (talk) 13:58, 27 March 2014 (UTC)
My incompetence with the keyboard should not be tagged as has been done with (Missing a valid copyright tag (/license). Using VisualFileChange.js.). It is inappropriate for a borked typing of a tag to be generating a "planned for deletion notice" IMNSHO. Just fixing them would seem the more beneficial means to a resolution, or a prod to someone's errors, so I can go and fix. — billinghurstsDrewth06:03, 24 March 2014 (UTC)
Billinghurst, We have about 100-150 files a week that do not have a license. I do fix a lot of them, but I concentrate more on old files that "lost" license somehow and tag new uploads with {{No license}} using VisualFileChange.js. I also do a lot of "just fixing them", after adding {{No license}}, but I want uploaders to be aware that that is an issue, otherwise we had people that that make the same mistake over and over again. This process of triage by a human and {{No license}} added by a human that can be talked to seemed as a nicer alternative to fully bot process originally proposed here. If you have ideas of how it can be tweaked to be more clear or friendly, please let me know, but this is the best compromise we come up so far. --Jarekt (talk) 13:00, 24 March 2014 (UTC)
I d not know how that bot does it, but we have a very easy system to differentiate files with and without licenses: files transcluding {{License template tag}} have licenses and files without it does not. So we can track it and YiFeiBot is working just fine adding weekly files with no license to Category:Media without a license: needs history check. The problem is what to do with them than and the process I described is how I and others deal with them now. --Jarekt (talk) 03:24, 25 March 2014 (UTC)
I wasn't expecting you to fix it, I know it was my snafu. While I am robust enough to know to fix things, and not (overly) bite all the fingers on hands when hit with a blunt stick. Just to get that deletion warning for a typo issue is harsh, and for a newbie, it seems overly harsh. So we have an issues 1) the template applied to a user page, and to a file could be more conciliatory. At the moment it says Copyright status and This media may be deleted. For a typo, that seems overkill. I haven't used so cannot comment on its functioning and whether it has the required flexibility.
As I mentioned to @Leyo: at English Wikisource, we utilise s:en:Template:header which throws its own warnings when mandatory components are removed. We also have an abuse filter that detects if this template is missing in works of the main namespace; though that is not so easy as Information is not a prescribed template, though we could check for the presence of the template before and after an edit, and get a confirmation process. Would it not be possible that we check a file: ns submit for a valid copyright template? If not present, the filter sends back a warning, and if they save without, it is flagged. Responsibility at the time of edit. — billinghurstsDrewth12:50, 25 March 2014 (UTC)
I had the same idea about the abuse filter but it seems that we can search for a string but not template transclusion. We could also try to detect disappearance of some invisible HTML tag. However that is not possible with current abuse filter rules. I guess we could request expansion of abuse filter. I would love to block edits like this--Jarekt (talk) 13:01, 25 March 2014 (UTC)
If our license-templates would have a common prefix (e.g. {{license-...}}, we could. However, reality is that they are too heterogeneous, so one would have to list all copyright tags entering into a maintenance monster and this would have also negative impact on performance as this would be or-conditions in Abuse-Filter. -- Rillke(q?)11:15, 27 March 2014 (UTC)
(Edit Conflict) I do not think we can ever expect license templates to be a closed set, especially with all the home-brewed user specific "templates" in the user namespace. My idea of Abuse-Filter would either try to detect images that:
transcluded {{License template tag}} before the edit and do not transclude {{License template tag}} after the edit. This solution might not be feasible since at the moment abuse filters do not check transclusions, but we can request it.
As explained above by Zhuyifei1999, we could add some invisible HTML tag (may be some en:Microformat tag) to the {{License template tag}} and use new_html and old_htmlvariables to detect when the tag is missing. However it seems like old_html is disabled at the moment (?), and so might be new_html. We could request for them to be restored, or is there another way? --Jarekt (talk) 13:12, 27 March 2014 (UTC)
No license is better than a wrong license
Hi, I check and delete a lot of images without a license. 99% of files in this category are copyvios. And no license is bad, but it is better than a wrong license. Regards, Yann (talk) 14:59, 26 March 2014 (UTC)
So if I understand you correctly, are you saying that license removal should be allowed as a form of deletion request? I do see it being used that way (see example). I think I would still prefer to block such edits and show a message saying that if you believe the current license is incorrect and there is not correct license to replace than please file deletion request. --Jarekt (talk) 15:15, 26 March 2014 (UTC)
in the case of reuse of NASA website images NASA explicitely notes that images shown on their website but not made by NASA are not covered by the license as a "work of US govt." The license question is determined by the fact if a US governement agency made the image or not - not if the image merely appears on some US agencies website. So the license is clearly wrong in a case like this. If there is no other proven free license for the image, such images are not useable in commons and have to be deleted according to our rules. "No license" is nothing better than "wrong license" because both will prompt deletion anyway. Andy king50 (talk) 19:20, 26 March 2014 (UTC)
What I do not like is when people remove the incorrect license and leave image without one. Much better solution is to do a deletion request and explain why the stated license is wrong. --Jarekt (talk) 02:20, 27 March 2014 (UTC)
Agree; ability to edit the license tag of "own works" by others is a security hole in our application. License tags of third party uploads and of PD works may be edited by people other than uploaders for corrections per COM:AGF. If someone removes the tag, he should add {{No permission}} too. I think a bot will add it anyway, soon. But the problem is, chances that a busy admin delete the file without checking the history. (?) Jee02:35, 27 March 2014 (UTC)
If file is missing a license tag than {{No license}} should be added not {{No permission}}. {{No permission}} is for uploads of non-PD work of one author by someone else. In such case you need some proof that the author agreed to the license added by the uploader, which condition is usually satisfied by {{OTRS}} or {{LicenseReview}}. I also consider a replacement of license tag by a {{No license}} template to be an unfriendly act aimed at going around regular deletion request. Such files would be deleted within some number of days without much scrutiny and explanation what had happen. the current process of handling files without license is for YiFeiBot to add them to Category:Media without a license: needs history check. Than the new uploads are tagged with {{No license}} and what we are left with are old files which "lost" their tags. There are many reasons why they might lost them: vandalism, typos, attempts to delete an image, etc. Those should be handled by a person. --Jarekt (talk) 12:31, 27 March 2014 (UTC)
@Jarekt: No, sorry if I was not clear. Removing anything from the description page is bad anyway. If the license is wrong, a DR should be made. I am talking about files uploaded without a license in the first place. In that case, if it is a copyvio copied from the Internet, it is better not to have a license than to have a bogus one. Copyvios with a wrong license are more difficult to track. Regards, Yann (talk) 05:04, 27 March 2014 (UTC)
Sometimes I come across a logo from a website that is clearly not "own work", but is also clearly {{PD-ineligible}}; so I remove the "own work", but since I cannot relocate the website (it may have been shutdown) I can't supply source or authorship information. I suppose you can have an abusefilter tag edits removing licenses, but I don't want it to block my edits completely. TeleComNasSprVen (talk) 06:33, 27 March 2014 (UTC)
The abuse filter would be only looking for transclusion of {{License template tag}} (which is present in all license templates), so removal of one license and addition of other license would not trigger it. --Jarekt (talk) 12:09, 27 March 2014 (UTC)
Yay, many thanks. I was being fooled by variant regexp flavours and by some genuine cluelessness of my own. This worked almost perfectly for Århus (39 images), will use the same trick for Kbhv next (several hundred). -- Tuválkin✉05:46, 27 March 2014 (UTC)
Category:License review needed contains hundreds of files, some dating back weeks. I think it'd be easier to prioritise the backlog if it were arranged in subcategories by day. This would require the various templates at Commons:License review to automatically populate with the date of the request and place it into a subcategory. - hahnchen18:10, 27 March 2014 (UTC)
Use of "speedy" tagging for clear-cut cases
Hi there,
I normally tag images I feel have a clear-cut case for deletion (i.e. according to Commons policy) with the "Speedy deletion" template, using the regular Nomination for anything I feel could reasonably be argued against (even if I don't hold that view myself).
Some images I'd tagged were out-of-scope images that had been unused for personal use for around six months (mostly never used in the first place, and mostly from users who uploaded them- and frequently nothing else- then never came back). I felt this was fairly clear-cut; the images were personal, had the chance to be used and weren't, and that any competent admin carrying out the deletion would provide any necessary check and balance in the process.
However, although I haven't had any outright complaints about this, I noticed that one admin had converted my speedy nominations to standard nominations for deletion. I had this conversation with the user.
I wondered what the general consensus was about cases like this, and whether it would be preferred in general that I used the standard nominations process.
It's not a problem for me to carry out a standard nomination instead (if anything, it's less work), I just hadn't felt it was necessary to clutter the deletion discussions with lots of nominations for obvious cases that don't really require discussion. Sven Manguard makes the case that
" I am of the opinion that when there isn't a compelling reason to bypass the normal process, you should use the normal process. It leaves a much better record, allows the action to be contested (even if that is, as in this case, exceedingly unlikely to happen), and is general good practice."
and to be fair, I can understand this position.
I'd continue to use "speedy" and "copyvio" for egregious cases of spam and copyvios, but in "obvious and clear-cut but not urgent" cases like this, is it generally felt better to use the standard process, even if that means opening lots of nominations? Ubcule (talk) 21:25, 26 March 2014 (UTC)
As someone with 166,015 pages on my watchlist, and more that that number of uploaded images, I frequently miss speedy deletion templates being added. Consequently the first time I do notice and may have something to say, such as offering to correct the licence or source, the file has already been deleted by a keen admin and we have to go through the drag of justifying an undeletion before we can even discuss it properly. Where there is not an obvious problem or a good faith mistake might have been made (I have often had server outage problems leaving the image page blank) I would much rather see a DR being created, at least that way the uploader gets a notice on their talk page.
Keep in mind that it is reasonable to open a bundle DR for a group of connected images, such as a batch upload from the same source with the same issue. --Fæ (talk) 02:59, 27 March 2014 (UTC)
Ubcule, I hope you’re familiarized with COM:SPEEDY and Commons:Criteria for speedy deletion. Anything outside this narrow scope (i.e. most of what you have been using speedy for, and even one of the two reasons you propose to keep using it for) must go through a regular Deletion Request. I’m glad that filing a DR is simpler than tagging a file with {{Speedy}}; we all win. -- Tuválkin✉05:35, 27 March 2014 (UTC)
What Tuvalkin said! Speedy is a one person review, and it is bleeding obvious why and within the boundaries of the narrow space. If it is borderline, then it should be a normal DR for community discussion. — billinghurstsDrewth14:53, 27 March 2014 (UTC)
Thanks for the feedback.
Yes, having re-read the criteria, I realise some (but very far from all) of the nominations I made do not fall strictly within them. In my defence, I've never had anyone outright complain about this- in fact, the vast majority of such nominations so far had been processed and deleted by admins with no further comment, implying that it was within the spirit (if not the precise wording) of the guidelines. I'd assumed if they were happy with it, then it was acceptable. Since it's apparently not, I'll stick with the standard nom for cases like these in future.
From re-reading the wording and Tuválkin's comment above, I assume that a blatant spam- but non copyright-violating- file upload shouldn't fall under speedy and thus should remain in place for several days until the nomination has been processed?
Regarding batching, yes, I do this where possible- especially since one questionable image means it's worth checking the user's other uploads as many such users have more than one- but a lot of the "speedy" noms I was discussing here (*not* all the nominations I've made!) are from "one-selfie-wonders".
This media file comes from Freesound.org, a collection of Creative Commons licensed audio samples.
For more information, please see their official website www.freesound.org/
This tag does not indicate the copyright status of the attached work. A normal copyright tag is still required. See Commons:Licensing for more information.
Nice. Maybe drop the center alignment and join the two paragraphs, the small vs. normal font-size is enough for a contrast/separation. With slightly less than 150px you could get a more compact output. Maybe the PNG should be a SVG. –Be..anyone (talk) 08:52, 22 March 2014 (UTC)
I've created Template:Freesound as I've seen no objections here, but it seems to be buggy in a few places here and there that I don't know how to go about fixing properly. I'm not a translation admin though, so I had to rely on autotranslate to do the job and can't fiddle about with the Translate extension as easily, but I hope the current scheme solves the localization problem. Suggestions and comments? I've also gone back and marked thesetwo files using the new scheme, along with a LicenseReview template. I'm not sure if Freesound.org permits uploaders to change their licenses or not, but it's better to be safe than sorry. But I also can't figure out a good way to force the license review template to appear on all transclusions of the freesound template, unlike the Flickrreview template, so we'd just have to remember to manually add the tag to files from Freesound.org TeleComNasSprVen (talk) 15:49, 27 March 2014 (UTC)
For a test I created a German translation as documented (= "click here" button :-) Apparently it works (for me). Translations are tricky, hopefully somebody fixes my gibberish. Serious nit, there's no such thing as "a CC license", because it could be anything from CC0 down to CC-BY-NC-ND. Maybe "various CC licenses" matches what you mean. –Be..anyone (talk) 00:15, 29 March 2014 (UTC)
March 24
Wikipedia2Commons
Do we have, or is anyone working on, a migration tool to import images from (a) Wikipedia? There are some I'd like to bring in, in bulk, from en.WP, and manual migration is a pain. Andy Mabbett (talk) 15:28, 26 March 2014 (UTC)
I think having manual review of each enwp file before transferring them over to Commons would be a good thing. In the rare instance you might find a long time Wikipedia contributor known for accurately licensing their files and you want to bulk transfer them over to Commons without checking them beforehand, you could ask for a script at Commons's bot requests venue or still have a manual check done on the files. TeleComNasSprVen (talk) 16:29, 26 March 2014 (UTC)
@Pigsonthewing: I wrote a batch transfer script here, which can mass transfer categories of images or all of a user's uploads. Unfortunately, it's command line only. If you think this would be helpful, drop me a note on my talk page and I can wrap a graphical user interface around it. -FASTILY06:20, 28 March 2014 (UTC)
There is an ongoing bugzilla report to support direct content importing (media files) via Special:Import. Is has been/is progressing at a snails pace since the dawn of the dinosaurs. Sadly I couldn't find the link... Rehman01:39, 29 March 2014 (UTC)
Well, there is similar discussion on my talk page. I asked site owner, and he seems he did not recognize he licensed his photo under CC BY.(And he refused to use it for commercial purpose) However, valid CC BY 2.0 KR tag exist, and CCL is irrevocable, so I am not sure what to do. —Revicomplaint?07:38, 27 March 2014 (UTC)
SVG rendering has not been very consistent. The vertical Chinese texts (using tb-rl orientation with no rotation) tend to just collapse into one blob. The centre-aligned texts are also displaced from their intended locations, when viewed within a Wikipedia page (Latin script has no such problem). Please see comparisons:
PNG
SVG
However, the problem goes away when the SVG is viewed directly in the browser, see: [23], [24]. I use Chrome 33.0 on OS X 10.9.2. If I cannot trust SVG, I might as well use PNG. Yinweichen (talk) 01:49, 28 March 2014 (UTC)
It may be a missing Chinese font, but I'm not so sure. The "History of the Universe" image uses SimHei as the font. On mediazilla, should I file it under "MediaWiki Extensions" or "Tools"? Yinweichen (talk) 05:52, 28 March 2014 (UTC)
You can ask on mediawiki.org's support desk for help, but I'm not sure if this is an issue with the SVG code or MediaWiki's rendering of it. If you still plan on using bugzilla and you don't know where to file it under, you can just use MediaWiki→General/Unknown and let resident bugmeister User:AKlapper (WMF) sort it out. TeleComNasSprVen (talk) 09:11, 28 March 2014 (UTC)
correct component is Wikimedia -> SVG Rendering. Note that we dont have anyone dealing with librsvg bugs currently, so dont expect too much. Bawolff (talk) 18:02, 28 March 2014 (UTC)
Yinweichen -- when "SVG is viewed directly in the browser", it means that a local program on each person's computer does the rendering, so which program is used will be different on different computers. There are a number of unresolved issues with SVG text rendering in RSVG, as you can see at Commons:Graphic village pump. The stupid answer (but one which generally results in working SVGs) is always "convert text to paths". P.S. It's not really considered good etiquette to display images above thumbnail size on this page (Village Pump)... AnonMoos (talk) 16:08, 28 March 2014 (UTC)
Thanks. I'll use "convert text to paths" to temporarily solve the problem. Hopefully someone will fix the issues with Wikimedia SVG renderer. P.S. I somewhat reduced the image size above. Please resize/reposition them as you wish, to keep the talk page clean. Yinweichen (talk) 19:46, 28 March 2014 (UTC)
First, can we point the Commons:SPEEDY shortcut to point to our brand new policy page? I have a feeling we're going to refer to that a lot more than the current section the shortcut is pointing to. Second, can we construct a database report of indefinitely blocked users' userpages to speedy delete, per the criteria? TeleComNasSprVen (talk) 09:33, 28 March 2014 (UTC)
It was redirected to the CSD page some time back, but was reverted by someone as it was just a proposal back then. I have now boldly went ahead and changed it back. I think it needs more protection, but for now I just assigned autopatrol-level. Didn't want the other user to think that I am forcing it. Rehman01:34, 29 March 2014 (UTC)
Are Search for Malaysia Airlines Flight 370 and Search vehicles of Malaysia Airlines Flight 370 redundant?
Hi all, I put together a list of MobileUploads with 0 uses locally & globally. There's a ton of problematic images in here, so it might be worthwhile to thumb through and DR/delete bad images. -FASTILY06:08, 28 March 2014 (UTC)
Good list. I tried the letter Q (lazy, yes, I know), and there was only one photo there. No apparent copyright issues, lacking categories (I added a few, incl. location), needs rotation marked). I’ll try Y next, maybe. -- Tuválkin✉01:47, 29 March 2014 (UTC)
I think so. They mention potential issues with personality rights, which is OK, and the request that "images and videos may not be used to state or imply the endorsement by IAU" which is a normal disclaimer. Additionally, they request "a copy of the product sent to [them]". That doesn't apply to us if we copy their material. Regards, Yann (talk) 05:21, 31 March 2014 (UTC)
I have found this and decided to make vector version of it. You can see it here. The bitmap image still has "move to Commons" tag, although it has bad quality and SVG is better format for flags. What is usual action in this case? When a bitmap from Wikipedia is eligible both for moving to Commons and vectorization, should be to Commons uploaded only vector (if is superior)?
PS: Please delete this file, it is worse than this. Hosmich (talk) 17:06, 30 March 2014 (UTC)
However, if someone improves "Flag of Limbuwan.svg" to look closer to copyrighted flag, will it be violation of copyright? The current file is basic Inkscape vectorization and I am willing to remake it with polygon. Can it then be on Commons, or on English Wikipedia only?
Whether to upload/move also the raster version to Commons greatly depends on whether this raster version will fulfill any purpose on Commons. For example if you use the raster version as a source for your vectorization you have to properly attribute it, therefore moving the raster version to Commons makes sense. When the raster version is an official representation of a flag (even if it might be low quality) and you create a vector version from scratch you don't need to attribute the original version but it should be moved anyway and can be linked as "official" representation from your new and superior file. In contrast when you create an exact (but vectorized) "copy" of the raster version but you have external sources then the raster version doesn't contain any useful information that the vector version does not have and can safely be nominated for deletion. --Patrick87 (talk) 20:20, 30 March 2014 (UTC)
I blocked this account. These files were recreated after being deleted. I don't think this account would produce anything useful. Regards, Yann (talk) 17:35, 31 March 2014 (UTC)
Spaces before file extensions in titles
I've come across this file File:Eiffel Tower at Night .jpg, which apparently has a space between the main title and the file extension "Night .jpg", and I'm bringing this up to ask whether the file ought to be renamed. According to Commons:File renaming, this might fall under criterion 6 because it is unintuitive to Wikipedia re-users who have to relearn the new syntax for displaying this file properly ([[File:Eiffel Tower at Night.jpg]] is often considered the "proper" syntax used for these files). But this file might also be considered to fall under criteria 1 to decline, because it looks a bit better; however I am more concerned with the utilitarian aspect of intuitive file "transclusion" code to Wikipedians more than it just looking better, but it is also a part of my concern.
Criterion 6 is something totally different. Unless you're planning to use this in a template, it doesn't apply. It's a case of looking a bit better. I can't see how this is unintuitive to anybody: as the file is called File:Eiffel Tower at Night .jpg, the code for displaying it is [[File:Eiffel Tower at Night .jpg]]. Why is a space any different from any other symbol, e.g. a digit? Most of the time I think people will copy and paste the filename anyway (I do so at least). darkweasel9408:51, 31 March 2014 (UTC)
It might be used in a template, but even if it wasn't used specifically in a template, invoking a thumbnail or other instance of the file to be used becomes highly unintuitive, as it's not the case most files here do not have trailing spaces near the file extension. You may use copy and paste for the filename, but others might simply write it out in the code - different styles, but why hinder the readability of one over the other? TeleComNasSprVen (talk) 17:21, 31 March 2014 (UTC)
{{Rename/doc}} is only semi-protected, how about changing "5. Correct obvious errors", just add ", e.g., removal of trailing spaces before the extension"? Or add it as separate clause. Then you can use {{rename}} for this minor uncontroversial (my POV) improvement, it already displays all details of a proposed change. –Be..anyone (talk) 09:31, 31 March 2014 (UTC)
Thanks, but I wonder if this should be an "official" policy to be documented as a separate criterion, or sub-criterion of #6, at least for the Commons:File renaming guidelines. Trailing spaces are an inconvenience to reusers, but they're minor enough to leave the resulting redirect in place in case anyone wants to refer to the old (spaced) name. TeleComNasSprVen (talk) 17:26, 31 March 2014 (UTC)
I renamed the file. Having an extra space at the end is a trap that shouldn't be there, making it harder to use the image. like the idea of the upload procedure taking care of this. I wonder what Rillke has to say about that? :) --Hedwig in Washington(mail?)13:29, 31 March 2014 (UTC)
That sounds good, but what if I find another similar file already uploaded to Commons exhibiting the same problem? Would we have to go through this discussion again, or just refer to Special:Upload's new technical prohibition on trailing spaces near file extensions? TeleComNasSprVen (talk) 17:26, 31 March 2014 (UTC)
There is a page with bots looking for jobs—I forgot where. Spaces before the extension should be simple. Adding similar Unicode characters for auto-renaming might interest the bot owners:   –Be..anyone (talk) 22:51, 31 March 2014 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. JotaCartas (talk) 14:25, 3 March 2014 (UTC) 
Fixed, I guess. Seems that it was a matter of embedded color profile. -- Tuválkin ✉ 07:15, 5 March 2014 (UTC)
If you have another large number of renames that can be solved with a regular expression match, drop me a note or email and I'll run it for you or email you the code back so you can play with it. --Fæ (talk) 11:17, 7 March 2014 (UTC)_9M-MRO_-_MSN_28420_404_(9272090094).jpg)
.png){kind=logo}
. It is a great marketing strategy to make money by charging anyone who might want to republish them for anything serious, such as in a book or in a newspaper. Of course many images are still copyfraud and are actually public domain - we tend to have better copies. --Fæ (talk) 22:04, 6 March 2014 (UTC)
Blank map of origin and destination points and last known ATC position
Blank relief map of origin and destination points, last known ATC position, and last reported radar contact
Done --Zhuyifei1999 (talk) 03:09, 16 March 2014 (UTC)
Al-Arab: 607 copies in Arabic, early 20th-century
Al-Iraq: 500 copies in Arabic, early 20th-century
Al-Zaura: 50 copies in Ottoman Turkish and Arabic, 19th-century
Locomotive: 0 copies in German, 19th-century
Periódico El Mosquito (Argentina): 0 copies in Spanish, 19th-century
Seda Babel: 215 copies in Arabic, early 20th-century
Têgeyştinî Rastî: 67 copies in Kurdish, early 20th-century
--Fæ (talk) 14:04, 17 March 2014 (UTC)
Gulf of Thailand (German)
Strait of Malacca highlighted (English)
Malaysian Peninsula relief map (no markings)
China to Malay Peninsula relief map (no markings)
.png)
).
![[1]](http://regex.info/exif.cgi?dummy=on&imgurl=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fthumb%2Farchive%2F8%2F8d%2F20140304235831!Ecuador-234.jpg%2F800px-Ecuador-234.jpg){kind=link}
![[2]](http://regex.info/exif.cgi?imgurl=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Farchive%2F8%2F8d%2F20140304235831!Ecuador-234.jpg#ExifTool){kind=link}
_-_BL_Or._7694.jpg){kind=link}
![[3]](https://upload.wikimedia.org/wikipedia/commons/archive/4/4c/20140304194138%21Coat_of_arms_of_Mauritius.svg){kind=link}
![[4]](https://commons.wikimedia.org/w/index.php?title=File%3ACoat_of_arms_of_Mauritius.svg&diff=118321454&oldid=118315771){kind=link}
.svg){kind=link}
,_pl.1_-_BL.jpg&action=edit&redlink=1){kind=link}
![[5]](https://upload.wikimedia.org/wikipedia/commons/f/f8/A_new_and_accurate_plan_of_Blenheim_Palace_-_L--39-Art_de_Cre%CC%81er_les_Jardins_-1835--_pl.1_-_BL.jpg){kind=link}
.png){kind=link}
.jpg){kind=link}
![[11]](http://static.panoramio.com/photos/original/19375694.jpg){kind=link}
![[18]](https://commons.wikimedia.org/w/index.php?title=Special%3ALog&type=upload&user=&page=File%3AChristopher+Lydon.jpg&year=&month=-1&tagfilter=&hide_thanks_log=1){kind=link}
![[19]](https://commons.wikimedia.org/w/index.php?title=File:Christopher_Lydon.jpg&diff=next&oldid=0){kind=link}
![[20]](https://commons.wikimedia.org/wiki/File:Bled_%289329708734%29.jpg){kind=link}
![[21]](https://commons.wikimedia.org/wiki/File:Bled_%289327109791%29.jpg){kind=link}
![[22]](https://commons.wikimedia.org/wiki/File:Bled_%289327208881%29.jpg){kind=link}
.jpg){kind=link}
.svg){kind=link}
![[23]](https://upload.wikimedia.org/wikipedia/commons/5/5a/2014%E5%A4%A7%E8%BF%9E%E7%BB%B4%E5%9F%BA%E4%BA%BA%E6%98%A5%E5%AD%A3%E8%80%83%E5%AF%9F%E5%9B%A2%E6%B5%B7%E6%8A%A5%E7%AB%96%E7%89%88.svg){kind=link}
![[24]](https://upload.wikimedia.org/wikipedia/commons/0/07/History_of_the_Universe-zh-hant.svg){kind=link}
.gif){kind=link}
.svg){kind=link}
