Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2024/03.

Please note:


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

Purposes which do not meet the scope of this page:


Search archives:


   
 
# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Category:People of the United States Department of State 8 5 Jeff G. 2024-03-23 13:08
2 Amateur drawings 32 15 RZuo 2024-03-26 07:04
3 Camel? 7 5 Broichmore 2024-03-25 18:31
4 Inscription 12 7 Tuvalkin 2024-03-25 16:57
5 Overlapping map categories 4 2 Kk.urban 2024-03-22 16:32
6 Category:Abusive people 3 3 Kk.urban 2024-03-22 16:32
7 Help with artist's signature 8 3 Choliamb 2024-03-28 14:16
8 Stools 4 4 Tuvalkin 2024-03-25 17:02
9 Updates on designing a new Community Wishlist Survey 2 2 Tuvalkin 2024-03-25 17:03
10 Japanese-language help sought (or possibly Chinese) 7 4 RP88 2024-03-23 19:03
11 Gps allowed in structured data 3 2 Richard Arthur Norton (1958- ) 2024-03-21 23:57
12 Photo challenge January results 1 1 Jarekt 2024-03-22 02:13
13 Steinsplitterbot FUBAR: How to remove images from the queue? 3 2 Milliped 2024-03-22 14:43
14 General categorization of old maps 2 2 Broichmore 2024-03-22 19:30
15 Uncategorized categories 2 2 Prototyperspective 2024-03-26 12:52
16 Zoom factor when clicking on coordinates 2 2 HyperGaruda 2024-03-24 04:27
17 The Bagel Effect 2 2 ReneeWrites 2024-03-25 23:26
18 Scope of Commons 8 4 Jmabel 2024-03-27 22:31
19 {{Redacted}} source 16 5 Trade 2024-03-25 23:17
20 Pseudomummies 7 3 RP88 2024-03-25 11:23
21 Yearbooks and copyright 17 8 David.Monniaux 2024-03-28 17:48
22 Image seems to have been deleted against consensus, also questions about keeping ai generated images in scope 7 4 Pi.1415926535 2024-03-27 21:59
23 File:RuizPineda.jpg 2 2 GPSLeo 2024-03-27 17:52
24 Viewmaster 3D images of the moon 4 3 Pigsonthewing 2024-03-28 17:26
25 Raiden (Mortal Komat) vs. Raiden (Metal Gear) 2 2 Jmabel 2024-03-27 22:36
26 File:Crocus City Hall attack, Moscow, Russia (2024-03-23-06-26-46 UMBRA-06).tiff 2 2 GPSLeo 2024-03-28 13:27
27 A building in Carcassonne 3 2 Pigsonthewing 2024-03-28 17:22
28 Guidance re possible copyleft trolling 4 3 Bjh21 2024-03-28 17:13
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
The last town pump to be in use in Saint Helier, Jersey, until early 20th century [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive

Template: View   ■ Discuss    ■ Edit   ■ Watch

November 18

[alt-b] thank you

For The first of my searching this , It is great for me -- 04:56, 15 October 2011‎ User:Trieu Sung hop

Timestamp: 04:56, 15 October 2011‎ (UTC)
dummy signature: -- RE rillke questions? 18:11, 7 January 2012 (UTC)[reply]

Christmas Light Displays

Moved to Commons:Village pump/Copyright#Christmas_Light_Displays

dummy signature: -- RE rillke questions? 18:11, 7 January 2012 (UTC)[reply]

December 13

Unwanted picture rotation...

All pictures that I uploaded were set correctly. Since the introduction of MediaWiki 1.18, a large number of images are rotated somehow. The problem should be solved in MediaWiki not manually (Category:SFeraKon...) --Roberta F. (talk) 16:24, 17 December 2011 (UTC)[reply]

please search the village pump or the help desk for "rotation", there are various discussions on this already. --Martin H. (talk) 16:37, 17 December 2011 (UTC)[reply]
Commons:Rotation. (...perhaps the editnotice should be bigger?...) Rd232 (talk) 23:34, 17 December 2011 (UTC)[reply]
Yes, it has been discussed, for weeks, and the developers responsible for the surprise introduction of this feature continue to be less than fully responsive. I understand that more modern image programs pay attention to rotation values in the exif data, while the wikimedia software didn't, meant that people who downloaded images from us were surprised to open them up on their computer, to find them rotated. Several key questions have either gone unanswered, or have answers that do not seem official or definitive.
  1. developers have not been responsive to questions about the extent to which they thought about the human burden of unexpectedly introducing this feature.
  2. Carl Lindberg, and possibly other people, have asked why developers didn't first send a bot around to first build a list of all images that had a non-zero rotation value, and then set the rotation value of those images to zero.
  3. One of the early respondents to these threads asserted that when those of us who found images we uploaded needed to be rotated, again, should have been using the {{Rotate}} tag with an undocumented "resetexif" parameter.
    • Is this necessary? Was this ever necessary?
    • If this "resetexif" parameter is important, why isn't it documented?
    • We have been told that the "jpegtrans" program can be used to rotate images on our own computers reliably, and that it will change the rotation values in the exif data. Okay, but I use irfanview. I asked, and am still waiting for an answer, as to which other external programs that can rotate images can be counted on doing so reliably.
  4. Was a list of images with non-zero rotation values kept? Some respondents here have written that 50,000 images had non-zero rotation values. Is this correct?
We should all be grateful, in general, to those who develop and maintain the wikimedia software -- who I assume are all volunteers, just like I am. But still, I encourage them to regard incidents as this as cautionary tales. In general developers need a strong sense of caution and humility. About five years ago a developer on the English language wiki thought he or she could write a bot that would go around, and assume that every biographical article there should have the sort order set to the last name first format -- even though while this is appropriate for most European names, it is not appropriate for Chinese and Arabic names, and names of people from some other regions.
This sort order bot may have guessed correctly 90 to 95 percent of the time, but that 5 to 10 percent error rate caused, and continued to cause a really large waste of person power -- at least thousands of hours I'd estimate -- possibly tens of thousands of hours. Almost everyone since that bot was run has assumed that any biographical article that had a different sort order set, had that sort order set by a reliable human being, who knew what they were doing. Subsequent bots and semi-automated tools, written by more cautious developers, weren't ready to blindly guess at resetting the sort order of names, but they assumed, incorrectly, that if an article had some kind or sort order set it had been set by a reliable human being.
I think we would have been far better off if this sort order bot had never been run. There are some tasks that are so complicated we just aren't ready to trusting them to unsupervised bots.
Sorry, I am afraid this recent feature change is an instance of the same kind of mistake. We could have assumed that all, or almost all, the most important images rendered correctly or a real reliable human being would have noticed, and either fixed it themselves, or arranged for it to be fixed. We could have assumed that the only images with rotation values embedded in them, that needed to be rendered according to those values were images that no one used and no one was really looking at.
I am with Carl, really, all our old images should have continued to be rendered, as per always. Images with non-zero rotation values should have been listed and checked by a reliable human being.
Someone (a developer?) defended the introduction of this feature, without warning or explanation, as being defensible, as this change had been listed on a list of desired changes to the software for some time. I am sure that more than 99 percent of us have no idea what features are or are not listed on the desired features list.
If you follow these things some applications got a delayed hit from the Y2K bug in 2010. When bugs are fixed the wrong way variations on those bugs come around and bite over and over again. Geo Swan (talk) 18:38, 18 December 2011 (UTC)[reply]
Brion Vibber is a paid employee; I believe that the Foundation has more paid programmers. They MUST be more responsive. /Pieter Kuiper (talk) 19:03, 18 December 2011 (UTC)[reply]
It's not a question of being responsive, - the thing shouldn't have happened, ever. What was the rationale for this "improvement"? Who made the decision, who authorized the spec - give me the whole chain. NVO (talk) 07:03, 19 December 2011 (UTC)[reply]
  • If I was a programmer working in the employee of the WMF I would not normally want to answer to volunteers, who post to the village pump, unless I was answering a general "well done". I would want to write to specifications approved by the WMF Board of directors, or by a committee of individuals delegated to and responsible to the WMF Board of directors. I would not agree to start a project unless I had clear specs. In my opinion it would be inappropriate for employees to set policy. Geo Swan (talk) 07:21, 19 December 2011 (UTC)[reply]
@Geo-Swan: you are apparently mixing up the fix of the exif-based rotation feature mess and the mess itself. {{Rotate}} is a community tool to fix - it didn't break anything. Regarding the resetexif parameter: as I have written in the duplicate post by you: please ignore it. Cheers --Saibo (Δ) 15:33, 4 January 2012 (UTC)[reply]

Status

Some volunteers are currently working on a list solving the problems on Commons. All files used in Wikimedia-Wikis- Main namespace are done. I think we can process all the (old) files so no action at your side is required. Of course you are allowed to request rotation for a file if you find a wrong-orientated one. -- RE rillke questions? 00:25, 31 December 2011 (UTC)[reply]

  • Questions? Yes, I would still like someone from the team to clarify whether or not the undocumented "resetexif" parameter is necessary. I would still like to know whether my favourite program, irfanview, resets the exif data when it rotates. I am sure other people with their own favourite programs want to know likewise, for theirs.

    I still regard this as an example of bad planning, and would feel more comfortable if the team members also acknowledged this. Geo Swan (talk) 21:24, 23 December 2011 (UTC)[reply]

Since Irfanview is also my favorite: Don't use simple rotation (L or R key) and save over the original file! The functionality you want is supported through a plugin. If it's installed it should reside in Irfanview's folder (not the plugin folder): "Jpeg_LS.dll". The function is available through them menu Options > JPG - lossless rotation… (PlugIn) or with Shift-J. Lossless rotation requires the image's height to be a multiple of 16 (acc. to JPEG's specs). Alfie↑↓© 23:59, 30 December 2011 (UTC)[reply]

Should categories be in front of interwikis or other way around?

Many categories and galleries on Common use interlanguage links, commonly called interwiki links (although that term has also other meaning, see meta:Help:Interwiki linking). A standard on all Wikimedia projects, so far, is to place interlanguage links on the bottom of the page, below categories, see here. Other projects like Wikia place them above categories. This layout is enforced by many bots, especially most bots written using pywikipediabot infrastructure, which use standard functions for category and interwiki operations also perform wikitext cleanup while doing other tasks. The wikitext cleanup consolidates all categories and interwikis together, move them below all other wikitext in proper order. The layout can be customized for each project through so called family files, but the layout currently enforced on for pages on Commons is the same as for Wikipedias and places interwiki below categories. Last month my bot user:JarektBot was blocked indefinitely (see here and here) for performing wikitext cleanup while adding interwiki links. Apparently, "there is no consensus on the order"[1] on Commons and the preferred option is to keep the order used by the earlier editors. Unfortunately the way pywikipediabot infrastructure is constructed, it HAS to know the order and most operations perform additional cleanup, like in this or this edits.

So in order to be able to run any pywikipediabot based tasks without getting blocked and to save the trouble for operators of most other pywikipediabot based bots, I would like to propose to reach consensus on preferred layout of Commons wikitext. Which order we chose is less important as to agreeing on some order. The choices are:

  1. Wikitext->Categories->Interwikis - the currently enforced order
  2. Wikitext->Interwikis->Categories - order used on many pages
  3. Other?

I mildly prefer the current order, mostly because if we decide to change it than suddenly there will be a lot more changes to the pages edited by the bots. I do not propose that the chosen order will be strictly enforced by everybody or that any mass layout changes be performed by the bots (I do not think there should be any editing that only "beautifies" wiki code). Only that if cosmetic changes are made to the layout (while performing other tasks) than they should go in single direction. --Jarekt (talk) 14:54, 20 December 2011 (UTC)[reply]

HotCat places new categories adjacent to existing categories, and if there are no existing categories, it places new categories above the interwiki links, which are assumed to be at the end. Before interwiki link handling was implemented in HotCat, it would place new categories, if there weren't already categories on the page, at the bottom, i.e., after the interwiki links if there were any. Numerous people requested insertion above the interwiki links. Since that was implemented, I've not had a single feedback relating to this issue, so I presume people at the umpteen projects using our HotCat are happy with it. Therefore, place categories above interwikis on WMF projects, and all should be fine. (Except for simplistic bots, it doesn't matter. A well-written category or interwiki bot should be able to find the links it's interested in no matter where they are on a page using the API, and the MediaWiki software also doesn't care. It's purely a preference of human editors.) Lupo 15:19, 20 December 2011 (UTC)[reply]
I personally prefer the first format, with interwikilinks as the last elements on the page. For me it creates a feeling of nice hierarchy, with page-specific wikitext first, Commons-specific categories second and the Wikimedia project-wide interwikis last. MKFI (talk) 16:48, 20 December 2011 (UTC)[reply]
Agree... AnonMoos (talk)
Agree also, but it's no big deal. - Jmabel ! talk 17:01, 20 December 2011 (UTC)[reply]
It is not a big deal to me either, but bots everyday are doing edits that got me blocked. I just would like to have this discussion, in case other editors have equally strong feelings on this topic. --Jarekt (talk) 17:34, 20 December 2011 (UTC)[reply]
Generally agree, but since it works either way (i.e. the rendered page would be identical), I'm not sure I would worry much about trying to "fix" them (i.e. don't make such edits unless changing for some other reason). I can't see much issue with putting all the interwiki links at the bottom, though leaving category links in place would be preferable, as there may be reasons for the ordering/placement of those. Carl Lindberg (talk) 19:23, 20 December 2011 (UTC)[reply]
Format 1 is the standard, and should be enforced by a bot if, and only if it's making some other constructive edit (like updating interwikis). We certainly wouldn't want edits just to enforce the standard. I can't understand the claim that "there is no consensus about the order"; it may not be written down anywhere on Commons, but that is clearly the standard. See also en:WP:ORDER. Rd232 (talk) 17:32, 20 December 2011 (UTC)[reply]
I wasn't aware that the issue with HotCat adding categories to the ends of pages had been fixed. If there's no problem of categories being split up, with some appearing before the interwikis and some after, then I've no objections if categories are placed before interwikis. (By the way, I notice that sometimes categories appear before the "Licensing" section. Can that be fixed by bot?) — Cheers, JackLee talk 17:46, 20 December 2011 (UTC)[reply]
(OT, HotCat's placement of categories): is fixed since July 19, 2011. Lupo 21:15, 20 December 2011 (UTC)[reply]
About categories appearing before the "Licensing". That can be added (assuming it is no already there) to beautification steps performed by pywikipediabot based bots while performing other tasks. --Jarekt (talk) 17:52, 20 December 2011 (UTC)[reply]
I imagine that is because many licensing templates add their own categories, and some users would prefer that the most relevant categories show up in the category listing before those more generic categories. So, not sure placement before licensing is a problem, let alone one that needs to be fixed systematically. Some editors do care about the order of the categories in order of most-specific to least-specific; there have been some bots which resort them alphabetically though, which is probably not a good idea if it can be avoided. Carl Lindberg (talk) 19:23, 20 December 2011 (UTC)[reply]
Categories before the "Licensing" header come from the category bar on the upload form. The category bar on the upload form has no choice but to add them to end of the description before submitting the upload, and then they end up above the licensing header. Dunno what the upload wizard does, but I'd hope (since it works completely differently) it can do better. Lupo 21:11, 20 December 2011 (UTC)[reply]
This debate have been held many times and indeed, there have been never a consensus: the Wikipedia order is not the Commons standard. The fact that HotCat has changed might add another light on the problem. As many people that put significant energy in properly documenting, IW linking and deep categorizing categories, we prefer the categories at the bottom.
I documented somewhere between 10 and 20000 categories with text and IWs from sumitup. I gain significant time by having the categories at the bottom, and for maintenance of well documented categories, it is much faster if the categories are at the bottom; in stead of having to search in several pages of text and links, one can jump quickly to the end where the most dynamic part of a category is concentrated. That the bot changes such layout is not a real drama, but I noticed that some people take a pleasure in applying rules and protesting. I saw hundreds of categories changed just to remove a white space or to change the order in the hundreds of disambiguation pages I made. So I don't need an excuse for nitpickers to start making futile edits on those categories; not a drama in se, but just significant more work in my watchlist to check those edits on correctness. --Foroa (talk) 12:14, 21 December 2011 (UTC)[reply]
I think we all agree that edits which purpose is only wikicode beautification, which do not change appearance or efficiency of the page are not desired. Wikicode beautification should be done only while doing other edits. May be we should have a policy or guideline to that effect, so it is clear and we can refer to it while talking to people that do this kind of edits. Does EN wiki has some similar policy? --Jarekt (talk) 18:07, 21 December 2011 (UTC)[reply]
Yes, it does (I've been involved in enforcing it...): en:WP:COSMETICBOT, a section of the Bot Policy. Also point 4 of en:WP:AWB's "rules of use". There is no equivalent rule in Commons:Bots, but it would probably not be controversial to add. (In my experience, people were generally happy to accept the principle, the problem was occasional attempts to argue "this is not just cosmetic" or "this is an exception, it's really important".) Rd232 (talk) 08:27, 29 December 2011 (UTC)[reply]
My preference is categories above interwiki links, because it is in line with most other Wikimedia projects and follows what seems to me like a logical progression. The current wording of Commons:Categories#Creating a new category, however, recommends putting categories "at the bottom" and placing DEFAULTSORT after the interwiki links. (The logical place for DEFAULTSORT is, in my firm opinion, just above the categories.) LX (talk, contribs) 21:23, 21 December 2011 (UTC)[reply]
I corrected Commons:Categories#Creating a new category section. It was rather unclear. Please verify. --Jarekt (talk) 16:51, 22 December 2011 (UTC)[reply]
Order at Commons is usually wikitext => interwiki => categories. This as categories are rarely added manually, but through HotCat. --  Docu  at 12:52, 23 December 2011 (UTC)[reply]
user:Lupo said above that current version of HotCat "places new categories above the interwiki links". --Jarekt (talk) 12:56, 23 December 2011 (UTC)[reply]
I reverted the changes on Commons:Categories. This contains the guideline and de facto standard and practise that is valid since almost 6 years, and never has been seriously challenged. It is not through a little discussion on VP, that will vanish within a couple of days, that we can change that guideline. Such changes need a more formal approach and mainly the opinion of the people that spend the major part of their time on deep categorisation and documentation work. I think that HotCat places now the categories at the first category block it encounters (previous versions put it on the end). Jarektbot just gave a demonstration that there is no problem to place the categories at the end of the block. --Foroa (talk) 13:53, 23 December 2011 (UTC)[reply]

There seems to be disagreement about what the current standard is (interwiki before categories or vice versa). Would it be possible to have a bot generate some statistics? I presume a complete picture of Commons is impossible, but some random sampling on a convincingly large scale ought to be feasible. What do people think? Rd232 (talk) 23:22, 23 December 2011 (UTC)[reply]

Useless. The de facto standard is already 6 years as stated. Problem is that most py bots enforce the wikipedia standards during some operations, other bots used to set cats on the end which mixed it all up. A bot can not extract meaningful statistics about the users. While this order is not so important now, it will become important when most categories will have 2 or 3 pages of intro documentation (intro, sister projects, descriptions in tens of languages) and somewhere between 200 and 300 interwiki's. --Foroa (talk) 12:41, 24 December 2011 (UTC)[reply]
As I mentioned in the first post, technically bots can do either order, but they have to pick ONE and the one used so far by both pywikipadiabot and HotCat is categories above the interwikis. I do not have much of a preference of one order over the other, but that is the order used by all other Wikimedia projects and what is OK for about 500 Wikipedia, Wikisource, etc. project should be good enough for us. Also changing order used by all the bots would require a lot of coordination. AutoWikiBrowser based bots are usually less sophisticated and usually add everything either at the end or at the beginning of the page. But that is not a big problem either, since eventually a more sophisticated bot comes along and cleans up a page, in addition to their main edits. I do not understand why it is such a big deal to keep it the way pywikipadiabot and HotCat are currently doing it. Just like Rd232 I was not aware that there was any controversy about this order. --Jarekt (talk) 05:06, 28 December 2011 (UTC)[reply]
There are two ways of looking at what is the "de facto standard": what is used by the majority of pages where it's an issue (many pages don't have interwikis), and what is used by the majority of currently active users. A bot could give you a sample of the first. For the second, you'd have to do a user survey, via a SiteNotice. Both of these are perfectly feasible, but on some level, given the effort involved, I can't help wondering why we don't just agree to use the Wikimedia standard - which may after all be the Commons de facto standard anyway (we're just not sure!). Otherwise, the likelihood is we'll continue bumbling along with contradictory views of how these things should be done, which is messy at best. Rd232 (talk) 23:51, 28 December 2011 (UTC)[reply]
I agree. It is feasible to sample the layout of categories with interwikis to check the dominant order, however it would be a lot of work and I am not sure if we would be much smarter afterwards. For better or worse the wikipedia standard is used by all bots using pywikipidiabot framework, so for example User:SieBot "corrects" order of categories and interwikis each time it moves a category like here. Other prolific bots are likely doing the same for years. --Jarekt (talk) 04:19, 3 January 2012 (UTC)[reply]
Two points.
I prefer to maintain the current standard out of a long term view; the order is only important for categories that have a serious description in several languages, many categories and many interwikis. Obviously, sampling on short categories makes no sense. Few people do really deep categorisation and documentation work, they just create or extend categories by patching categories using HotCat, so obviously, they don't care.
Till some time ago, SieBot changed the order according to the Commons standard by putting the categories at the end. No idea when and why this has been changed. --Foroa (talk) 06:19, 3 January 2012 (UTC)[reply]
If SieBot needs fixing, it should obviously be corrected. --  Docu  at 07:33, 3 January 2012 (UTC)[reply]
It has nothing to do with user:SieBot, I only used it as an example and I can probably pick one of 78 other bots. My point is that ALL bots based on Pywikipediabot framework standardize the look of the pages they work on, and that standardization include consolidation all categories and interwikis together and ordering them in the "correct" order. At the moment that order is the standard used on Wikipedia and all the other Wikimedia projects (and HotCats) of categories in front of interwikis. It is possible to change a single line of code in one of the Pywikipediabot framework files (used by all the Pywikipediabot bots) to switch the order to the standard used on Wikia (interwikis before categories), which is the order preferred by User:Foroa. However until that change is made majority of the bots based on Pywikipediabot will use the Wikimedia standard. From the responses we got on the beginning of this discussion, there does not seem to be much support for such change, since ~8 users expressed the preference for current categories in front of interwikis standard and only one argued for change to interwikis before categories standard. --Jarekt (talk) 13:15, 3 January 2012 (UTC)[reply]
Bots provide a service by setting a de facto standard for Commons; it is fruitless to argue with a bot. Commons should be as consistent as possible with sister projects to avoid useless arguments. Bots based on Pywikipediabot help to maintain consistency. I support the Pywikipediabot order of categories in front of interwikis. --Walter Siegmund (talk) 19:54, 4 January 2012 (UTC)[reply]
From the bots that move categories, only SieBot uses since recently reordering as proposed here, it used to be compliant with the Commons guideline, as does category-bot. JarektBot is configurable as it demonstrated the other order in the beginning of the year. RussBot does not change the order, nor MerlIwBot that adds frequently interwikis. I'll come back extensively on this: what is important that we need to encourage and facilitate the proper documentation of categories (intro, labels, interwikis and categories), which is rare on Commons. Very few people in this debate (and on Commons) create completely documented categories. I am compiling a list of people that do so, and those people should be involved in the discussion. --Foroa (talk) 08:16, 5 January 2012 (UTC)[reply]
JarektBot as all pywikipediabot framework bots are individually configurable, but I am not comfortable reconfiguring parts of the bot shared by all other (78) pywikipediabot framework bots, since this would lead to much more drastic changes in edits by different bots with conflicting configurations. I would like to avoid that if possible. Ideally if we decide to change the standard currently used by most bots that will be done through change to pywikipediabot framework. Also I do not like your implied suggestion that not enough "people in this debate [] create completely documented categories" (I hope I am not taking your comment out of context). I feel like I edited enough categories (by hand and by bot) to be qualified to discuss this matter and I assume most other users that expressed their opinion so far feel similarly. However I like the idea to get more people involved in this discussion. --Jarekt (talk) 17:40, 6 January 2012 (UTC)[reply]

Principle of Least Astonishment

We have been talking a lot about the Principle of Least Astonishment recently, but it's not an official Commons policy, or even a guideline - it's something the board said that quite a lot of projects have simply ignored. In our case it has led to the spawning of 1000 categories "nude and partially nude people with X". They were originally created because people whinged and complained if they for instance saw pictures of people masturbating with electric toothbrushes in the electric toothbrush category, and they seemed like a reasonable compromise to keep the image in the toothbrush category tree but still satisfy the "THINKOFTHECHILDREN" people.

This is simply not acceptable. Either POLA is a Commons policy, in which case the categories should stay; or it isn't, in which case they should all be deleted. Previous discussions on the matter simply fizzled away with no resolution. I propose this: a straight up or down vote, should the Principle of Least Astonishment be a Commons policy? -mattbuck (Talk) 15:15, 21 December 2011 (UTC)[reply]

Oh, almost forgot, closing date is 0000 UTC, 1st Jan. -mattbuck (Talk) 15:23, 21 December 2011 (UTC)[reply]
@Matt, what I miss in your proposal is an outline of what the adoption of POLA would exactly mean for Commons, as we are rather different than Wikipedias. --Túrelio (talk) 07:26, 22 December 2011 (UTC)[reply]

This straw poll is meaningless

  1. Given Commons_talk:Nudity#Proposed_addition_regarding_categories this whole thing is arguably redundant. But if we want to specifically address POLA, we have to discuss how to do that seriously, and not conjure up a straw poll on adopting a policy that hasn't even been drafted and doesn't really make much sense as a standalone policy/guideline. See my comment in the Discussion section. Rd232 (talk) 22:36, 21 December 2011 (UTC)[reply]
  2. Bulwersator (talk) 09:32, 22 December 2011 (UTC)[reply]

Discussion

If we would know how image-filter would work, we would better know how to achieve the "no-shock". I would suggest moving this to COM:VPP since I expect lots of discussion with no result again. But even your example shows that we need no extra-categories: Why not creating Category:People masturbating with electric toothbrushes as a sub-category of the two topics. No one should be surprised and it is proper categorized.-- RE rillke questions? 15:31, 21 December 2011 (UTC)[reply]

We did have Category:Masturbating with electric toothbrushes, but then the image it contained was deleted and so the empty category was deleted. People complained about that too. -mattbuck (Talk) 15:58, 21 December 2011 (UTC)[reply]

Not every bit of common sense needs to be explicit official policy. - Jmabel ! talk 16:54, 21 December 2011 (UTC)[reply]

 Comment Just recently we had Commons_talk:Nudity#Proposed_addition_regarding_categories covering very similar ground - and it's still open, though it's run out of steam now. That proposal (and the better alternative that followed in the same thread) was at least concrete. This one is not. How do you start a straw poll on a "policy" without providing a draft, and with reference to highly specific issues around sexual images, as if the policy would only affect those? And why start it on VP instead of COM:VPR, given that it's bound to get large amounts of input, as all these discussions do? This is a complete mess, and whatever comes out of it can have no validity; therefore the sooner this poll is aborted in favour of a more sensible approach, the better. I suggest starting to draft Commons:Principle of least astonishment as a guideline. (I would suggest that it would be good as a section of a Commons:Category structure guideline, but I never did get round to organising that split from the mess that is Commons:Categories.) Rd232 (talk) 19:47, 21 December 2011 (UTC)[reply]

I do not need a new policy which is including POLA anyway. So there is no need to draft one. ;-) Oh, but - I strongly agree that Commons it totally messed up regarding these topics. That poll too fast shot - as your poll is in Commons_talk:Nudity#Proposed_addition_regarding_categories was. That said, I did not do a better poll until now. ;) So you guys are not to blame. Meant in a good way - but after some more thinking it could have been done better. But who isn't fucked up by the constant discussions about those topics here?! --Saibo (Δ) 18:13, 22 December 2011 (UTC)[reply]

Really tired with flickr

I'm really tired with flickr. I've been finding a lot of dead accounts connected to images that are suspiciously professional. I've also seen claims about licensing that could easily have mistakes. Is there some way that if we have a flickr images that we do one or more of the following:

1. Have OTRS keep a screen shot of the page with the license for verifiability later.

2. Have people get the original uploader to sign off on the image before it is moved to Commons.

3. Have some kind of policy to deal with removed flickr accounts as they tend to vanish more on violations of TOS (i.e. stealing images) than merely leaving flickr.


We are supposed to have a "when in doubt" approach to copyright, and there are so many potential problems with flickr, especially flickrwashing. Meh. Ottava Rima (talk) 03:09, 23 December 2011 (UTC)[reply]

In Wikispeak, flickr's purported chains of custody do not meet en:WP:RS. What we read on flickr is no more credible than what we read on a Wikimedia project; anyone can open an account and claim anything he/she likes.67.168.135.107 06:31, 23 December 2011 (UTC)[reply]
Yep. That is the frustration. Meh. Ottava Rima (talk) 15:08, 23 December 2011 (UTC)[reply]
Surely you would not doubt a photostream like Seattle Municipal Archives merely because it is on Flickr. - Jmabel ! talk 16:41, 23 December 2011 (UTC)[reply]
I would not automatically doubt it only because it has data that can be verified - source records. But I would doubt their right to license material in that way. Did they get permission from the original authors? Seattle isn't the Federal Government and isn't automatically PD. This lacks an author, which means that its copyright status is not known. The bureaucrat who uploaded it probably has no clue about copyright. This is why Flickr cannot be trusted. Ottava Rima (talk) 18:37, 23 December 2011 (UTC)[reply]
Looks like that one is a work for hire, and is not claimed to be PD, rather CC-BY. Yes, sometimes Flickr users license stuff they shouldn't. Probably at least as often, probably more, people upload stuff here and claim "own work". There is nothing we can do to completely prevent this; so do what we do now -- find other sources, use common sense (does a Flickr user have photos with tons of different cameras but claims to be all from one person, etc.). We do assume good faith. If you are tired of Flickr, you are also tired of Commons users. Carl Lindberg (talk) 18:41, 23 December 2011 (UTC)[reply]
  • Nothing in their stream is claimed to be PD. The few third-party images are normally marked as "All rights reserved" (though I have caught them in a mistake once in a while). I've spoken with several people from the Municipal Archive. These are city government materials, most of them taken by Engineering and Parks employees in the process of their work. And it is precisely their intention to release them. We got an explicit OTRS for their maps (which weren't on Flickr), but since the Flickr content indicates an acceptable CC license OTRS seems unnecessary to me. And it would be a pain to get it for a continuing stream of images. - Jmabel ! talk 01:48, 24 December 2011 (UTC)[reply]
  • "Works for hire" does not mean that the original artist gave up their rights to the image nor does it mean that they didn't merely license the image for use. We have no proof that Seattle owns the rights to those images let alone can legally release them under any license. Only in the Federal Government (primarily, the military) are creators of images giving up their rights and that is because of federal law. Ottava Rima (talk) 03:28, 24 December 2011 (UTC)[reply]
    • Um... that is exactly what "work for hire" means -- the copyright is owned by the employer completely, so yes the individual employee gives up all their rights (actually they never owned the copyright in question, as the company is considered the "author"). This is generally true of all companies and employees, for work done on company time -- please see 17 USC 101 for the definition, and 17 USC 201(b) for how that relates to copyright ownership. That's a pretty basic part of copyright law in the U.S. It may also apply to contractors or commissioned work, depending on how the contract is written. In general, the state or city government will own all copyright on work done by employees, and so there is really no reason to doubt ownership for most of what is in that Flickr stream. Carl Lindberg (talk) 04:47, 24 December 2011 (UTC)[reply]
  • "the copyright is owned by the employer completely" No. 1. We do not have an employee's name or the person who took it. 2. We do not have the contract that would determine if they gave up all rights to authorship. 3. You have to give up your right/claim to authorship. That is how it works in the US. I still own the rights to the images that I took pictures that were used while I was on the job and that is true in most states. From Wikipedia: "However, when a work is created by an employee as part of his or her job, or when certain kinds of works are created on behalf of a client and all parties agree in writing to the designation" - there is no proof of that nor is there an author given that would allow us to determine if that was the case. Ottava Rima (talk) 13:12, 24 December 2011 (UTC)[reply]
We don't need the names of employees. If you are a straight-up employee, then we don't need a contract either -- it is implied that you give up the right to claim authorship, unless the employment contract specifies differently (very rare). The "all parties agree in writing to the designation" part refers to works done on commission and other non-employee situations; those are not automatically a work for hire the same way. From the law I linked above:
A “work made for hire” is—
(1) a work prepared by an employee within the scope of his or her employment; or
(2) a work specially ordered or commissioned for use as a contribution to a collective work, as a part of a motion picture or other audiovisual work, as a translation, as a supplementary work, as a compilation, as an instructional text, as a test, as answer material for a test, or as an atlas, if the parties expressly agree in a written instrument signed by them that the work shall be considered a work made for hire. [...]
Case (1) covers basic employment (federal government works do not use the "work for hire" terminology, but the legislative notes say it is the exact same concept). It is only the cases in part (2) of that section which need agreed, written instruments -- which is exactly what the wiki article says, if you read the "ors" and the "ands" correctly -- "when a work is created by an employee as part of his or her job" is not qualified, it is only the part coming after the "or" which need the written agreements. If you are an employee, then for anything you do as part of the job, the company is the "author". The employee's name doesn't really matter, not even for copyright term (which for corporate works is based on date of creation or publication). The Flickr stream in question is from the Seattle city government, organized by the agency which created them it seems, who would be the copyright owner for anything done by their employees, at least if they were done as part of their duties. Carl Lindberg (talk) 14:58, 24 December 2011 (UTC)[reply]
"We don't need the names of employees" Legally, we do. And you don't understand how the law works. Merely being an employee does not mean your images are not your own. It has to have a specific contract. That is how the laws operate. You are quoting about federal employees when this is a state/municipal entity. Why did you conveniently leave that out? That isn't good, and anyone reading that would know it specifically deals with Federal Government employees only. I expect an apology for such bad behavior. Ottava Rima (talk) 16:04, 24 December 2011 (UTC)[reply]
The part I quoted has nothing to do with the federal government -- that goes for all employers (companies, local governments, etc.). If you are an employee, and you create works as part of your job, then the company/employer is the "author" and the employee has no rights at all over it. That is what a "work for hire" is. 17 USC 101 (which I quoted, and defines "work for hire") and 17 USC 201 (which declares that the employers are the authors of works for hire) apply in general, and not specifically to any entity. That is the "default" for an employment situation (as opposed to a commission or contractor). Carl Lindberg (talk) 04:12, 25 December 2011 (UTC)[reply]
1. Not true. The link you put before under "legislative notes" was for Federal Employees only. 2. The law says "within the scope of his or her employment". I find it odd how you overlooked that. That requires the specific contract and the expectation that the employer would have the right to determine the copyright. I write for newspapers and not once have I been forced to give up my copyright to those pieces I have written. That was my point before which you seemed not to get. Ottava Rima (talk) 05:33, 26 December 2011 (UTC)[reply]
1. That link I gave explains government works in terms of work for hire -- basically, a government work is basically a work for hire where the federal government is the employer. It helps define the term "government work" but does not restrict the definition of "work for hire" in any way. I posted the full definition of the term above (other than some of part 2, which is about non-employee situations). 2. Correct, works for hire must be those done within the scope of the employment. That is part of the definition, which I quoted -- in other words, work done on their own time is not covered by that. There does not have to be a special clause about copyright in the employee contract though; once an employee, work you do as part of your job description belongs to the employer. If you are an independent contractor, the situation changes -- no idea what you are, but unless there is a special clause in the employment contract about copyright ownership, I'd think that work by newspaper staff would be works for hire. The determination of "employee" vs "independent contractor" can be complicated these days by various employment arrangements; see for example this link which goes over some of that ground. I have no idea what your situation is, but for almost all regular employees, they never own the copyright of the work done on the job. Stuff done on their own time, and/or their own equipment, is of course different. Carl Lindberg (talk) 06:25, 26 December 2011 (UTC)[reply]
  • It seems to me that no apology is called for from Carl here. On the contrary, it seems to me that there is another contributor here whose replies which have skipped addressing meaningful and civilly expressed counter arguments, and who has been clouding the discussion through the use of inflammatory language. Geo Swan (talk) 18:07, 25 December 2011 (UTC)[reply]
  • I proved above that you are wrong, so cut it out. Ottava Rima (talk) 05:33, 26 December 2011 (UTC)[reply]
    • You claimed the bot was routinely generating bug reports -- apparently without looking closely enough at its talk page archives to recognize that all the bug reports since the bot's first year or so were due to good faith misunderstanding on the part of the complainants. A handful of complainants offered instances of images which they thought the bot should have confirmed. In every case the comlainants did not understand that of the half dozen creative commons licenses flickr supports only two are ones that we consider "free".
    • You keep claiming or implying that the bot has failed, and falsely passed images when they weren't under valid licenses. However, several of us have asked you to point to a single instance, a single image, where the bot failed. Not only have you failed to offer a single confirming instance, you have not acknowledged this very reasonable request.
    • So, your claim Carl owes you an apology is baseless. I strongly suggest you go back, re-read those archives. I honestly believe that if make a sincere good faith attempt to re-read those archives you will recognize your claims the program falsely represents a danger are baseless. At that point I request you re-evaluate who you thinks ought to apologize. Geo Swan (talk) 09:15, 26 December 2011 (UTC)[reply]
Commons has plenty of problems. Flickr has plenty of problems. But when you combine the two together, the problems become exponential. I would rather a small headache than a massive migraine. :) Ottava Rima (talk) 18:52, 23 December 2011 (UTC)[reply]
It's not exponential. Just additive. We'd get the same problems here, and all you'd do is to discourage people from legitimately making their works available under free licenses by saying we can't trust explicit licensing present on other sites. Carl Lindberg (talk) 20:22, 23 December 2011 (UTC)[reply]
I'm not sure why we trust any licensing elsewhere at all, especially when our core belief is to be skeptical regarding copyright and make sure to be very cautious. Ottava Rima (talk) 03:28, 24 December 2011 (UTC)[reply]
In that case, we shouldn't trust any licensing from anyone anywhere, and just shut down ;-) There is such thing as being too paranoid, if you want to have a remotely successful project of this type. License claims here are probably no better than ones elsewhere -- some things get better scrutiny, but far from all. Carl Lindberg (talk) 04:47, 24 December 2011 (UTC)[reply]
Bots aren't people. When they generate errors, they generate them in mass. People can be checked and verified. By requiring a screen shot along with the verification, that would go a long way to having a way to check and see if the bot was operating properly. Ottava Rima (talk) 13:12, 24 December 2011 (UTC)[reply]
Screenshots are essentially worthless (as they can be trivially faked), they are no stronger than an individual's word. Demanding them would be an overly bureaucratic step that would flood OTRS for no good reason. The bot was extensively checked in its first few months of operation. If you think its having problems now, look through its Special:Contributions/FlickreviewR and look for a false pass or a false fail?--Nilfanion (talk) 13:50, 24 December 2011 (UTC)[reply]
Now you are being ridiculous. If the bot takes a screen shot of what it is reading, it would not be "faked". It would be a record of what it is scanning. And if you think a bot has a word, then there is something really off here. A bureaucratic? We have to respect copyright. Laziness is not an acceptable excuse and that is made clear in our core policy. Ottava Rima (talk) 16:07, 24 December 2011 (UTC)[reply]
The bot doesn't take a screenshot, and shouldn't: Why would it have any "interest" in how the page looks to a human user? It parses out the relevant information and makes a decision based on that. The bot taking screenshot would add nothing, as the bot has already identified the relevant information.--Nilfanion (talk) 17:19, 24 December 2011 (UTC)[reply]
" Why would it have any "interest" in how the page looks to a human user? " For verifiability of it operating properly. Even now it still gets errors where it goes to the wrong page or cannot find the image. That is odd when it should be copying the link directly and the links work out. That should tell you that there are problems with the bot that will never be resolved. Ottava Rima (talk) 17:49, 24 December 2011 (UTC)[reply]
Ok, give me an example from today's reviews please? And are these cases where the bot has passed the image, failed the image, or requested human support?--Nilfanion (talk) 18:08, 24 December 2011 (UTC)[reply]
1. Today's reviews are a lot. 2. Who is to say it happens every day? Out of the tens of thousands, if 300 images have bad license approval of the flickr bot it is not excused because the majority do not have problems. I don't think you get how this works. We are supposed to ensure that we do not have any copyright infringing material or mark things as a license that it does not have. Ottava Rima (talk) 19:05, 24 December 2011 (UTC)[reply]
The bot's coding should prevent the errors with 100% accuracy. A script that is programmed to recognise "cc-by-nc-2.0" as "cc-by-nc-2.0" will not decide that "cc-by-nc-2.0" means "cc-by-2.0" in 1 in a million cases, it it will get it consistently right or wrong every time. If bot does have the flaws you claim it has, these should be noticeable on a relatively small sample - and you'd be able to provide evidence of it. If "even now it still gets errors where it goes to the wrong page or cannot find the image", you should be able to find examples. Provide one actual example, otherwise there is no point attempting to discuss further. "I don't trust bots" isn't a valid argument.--Nilfanion (talk) 19:20, 24 December 2011 (UTC)[reply]
I have uploaded several thousand images from flickr. I have not, however, encountered the problem User:Ottava Rima describes. Perhaps the topics where I look for free images on flickr are topics that don't attract people apt to claim professional images as their own. For whatever reason there is a discrepancy, and I ask O.R. to consider their experience may not be typical.
With regard to O.R.'s numbered suggestions:
  1. Keep a screenshot to verify the lisence? What, the flickrreview bot can't be trusted? Would an individual unwilling to trust flickrreview trust that a screenshot was not a forgery?
  2. I suggest asking each original flickr uploader for confirmation for each image would be pointless:
    1. Since November 2009 I have tried to leave a note on each image I uploaded, telling the flickr uploader where it had been uploaded, and thanking them for using a CC license that allowed re-use. Hardly any other wikimedia commons contributor bothers with this. If our existing contributors find leaving a thank you too much work asking them to enter into a long process of explaining our licensing rules is going to be way too much work.
    2. Flickr uploaders are also volunteers, and the burden of asking them to understand our licensing rules has proven to be a big burden on the flickr uploaders when I ask them to use a freer license. One typical response I get is a "sure, go ahead" that falls short of convincing me they understood the license.
    3. Wouldn't continual requests for confirmation as to whether the flickr uploader was really entitled to apply a free liscense, and as to whether they really meant to apply a free license serve mainly to annoy them, and change all their licensing to "all rights reserved"?
    4. I don't see how requesting confirmation would satisfy O.R.'s concern. If they lied when applied the initial free license, what is to stop them lying in their confirmation?
  3. O.R. writes "...removed flickr accounts ... tend to vanish more on violations of TOS (i.e. stealing images) than merely leaving flickr."

    And the basis for this assertion is?

    The only removed flickr account I am familiar with was a guy who seems to have requested flickr to shut down his account solely in reaction to learning wikimedia contributors had uploaded over 200 of his images, without telling him. Flickr didn't actually say why his ID was shut down. O.R., are you asserting that flickr leaves a note informing people when an ID has been shut down for copyright violations?

Of course we should all simply pass over, and ignore, the flickr image with an apparently free liscense, when we suspect flickrwashing. Any of us can challenge a flickr image when we suspect it was flickrwashed. But I don't think a suspiciously high quality image is sufficient evidence in and of itself to suspect flickrwashing. Some volunteers do upload professional quality images, either because have been professional photographers in the past, or they are amateurs who took their photography habit seriously enough that they can take professional quality pictures. Geo Swan (talk) 19:44, 23 December 2011 (UTC)[reply]
"What, the flickrreview bot can't be trusted?" No, it can't. No bot can be. Bots are scripts that fail all the time. The CorenSearchBot should be proof of that, and its code is far less complicated. One of the worst things to ever happen was to allow the bot to review without anyone verifying. Furthermore, the bot just aids in flickrwashing, which is really bad.
"Bots are scripts that fail all the time." - [citation needed] Bulwersator (talk) 09:40, 24 December 2011 (UTC)[reply]
"is going to be way too much work" We don't need flickr images, and if it is too much work doing the right thing, then that is a problem. Either do it right or not at all.
As for the removed flickr accounts, I have pointed out 4 in the past week. It is common in Deletion discussions. We normally blanket delete the images because of the problem of flickrwashing. Ottava Rima (talk) 19:51, 23 December 2011 (UTC)[reply]
The Flickrreview bot is perfectly fine. It documents the license on the Flickr page. If the license there is bogus, of course it doesn't matter much what the bot says, but it's going to make far less mistakes than a human. If you want to bring up a instance where the bot failed (marked an image as having a license when it didn't), bring that up. Carl Lindberg (talk) 20:22, 23 December 2011 (UTC)[reply]
  • Clarification please, User:Ottava Rima you write you "have pointed out 4 in the past week". You seem to be implying that you have pointed out 4 flickr IDs where it can be confirmed flickr management shut them down for copyright violations.

    If this is what you meant, please explicitly say so.

    If all you meant to say was that you pointed out 4 lapsed flickr IDs that you suspect were shut down due to copyright violations -- that is a whole different kettle of fish. If that is all you meant: (1) please say so; (2) please either name them here, or point us to where you named them before.

  • With regard to "doing the right thing". Personally, I think telling the flickr uploaders when we upload their images IS the right thing, or part of the right thing. Practically no one else does so. That guy who shut down his flickr ID -- I was the first person to thank him and tell him one of his images had been uploaded to the commons -- even though over 200 of his images had been uploaded here by other people. 99.5 percent of the time no one told him. If I want other commons contributors to leave a note on flickr images they upload I am going to have to convince them to do that extra work. The same holds for you, except what you want us all to do will be a lot more work than a simple thank you. Sorry, but I think you need to work a lot harder on convincing everyone your proposal makes sense, and is not an annoying waste of time that will counter-productively turn off the very flickr uploaders we want to continue to cooperate with us.
  • With regard to CorenSearchBot proving that the flickrreview bot is not as reliable as a screenshot -- how exactly did the corensearchbot fail, and how is that like the failures you anticipate the flickrreview bot is capable of? From what I have seen the flickrreview bot was written with caution in mind, and will, occasionally, call for a real human being to do the review. I believe staticians call this a "false negative". Can you point to a single instance where flickrreview's check reported an image bore a free liscense, when it did not bear a free liscense? Geo Swan (talk) 21:03, 23 December 2011 (UTC)[reply]
  • Flickr review bot, like all bots, have a lot of errors and are not trustworthy. The mere idea of trusting a bot in this highly sensitive area is disastrous and spells the doom of Commons. Furthermore, merely being used on many pages is not a legitimate reason to keep an image that goes against the mission of Commons, and that is especially true when there is doubt of license. And for your information, coren search bot returns hits based on text, not images. Text is easier to match whereas images are notoriously bad. Ottava Rima (talk) 23:20, 23 December 2011 (UTC)[reply]
  • Flickr Bot's block log shows that it malfunctioned before in such a way that it had to be blocked. Bots malfunction all the time in ways that aren't visible enough to block them, especially in obscure pages. Very few people were part of its approval. There have been many, many bugs over the years. Notice that many of these are "matching" errors. That isn't a coincidence. Ottava Rima (talk) 23:25, 23 December 2011 (UTC)[reply]
  • This shows a large list of images Flickr bot assumed were proper and have been deemed not the case. That has been a constant for a very long time. The bot should be disabled permanently and all of its reviews checked. Ottava Rima (talk) 23:27, 23 December 2011 (UTC)[reply]
    • I am checking your links.
    • User:FlickreviewR does have a block log.

      No offense, but forgive me for wondering if you made your claim that flickrreview was unreliable prior to checking its block log. Forgive me for wondering if you had realized the bot hadn't been blocked for 1089 days you would never have claimed its block log shows it is unreliable. The block log has 3 entries -- from 2007 and 2008. The explanation in the summary field of one block says the bot was uploading too many images. When flickrreview is checking an image, it makes sure the image we have is a copy of the highest resolution version of the image on flickr. Currently, if our image is not the highest resolution version, it uploads the highest resolution image, for its comparison. I am sure you will agree that this was not any kind of sign that the bot was incorrectly certifying unfree images as images under a free liscense.

    • You write "Very few people were part of its approval." I count 6 supports, no opposes. This decision dates back to 2006. I don't know how many endorsements are required now, or whether 6 was a low number back in 2006. I would be shocked if the bot didn't receive overwhelming support now.
    • You wrote "There have been many, many bugs". All the bugs in that bug log are to bugs from the first two months of the bots operation in December 2006 and January 2007. Further, none of those bugs are an instance of what you have claimed -- the bot incorrectly certifying an unfree image as under a free license.
    • You wrote "This shows a large list of images Flickr bot assumed were proper and have been deemed not the case." First, your link to the talk page's archive is bad. Just how thoroughly did you review the archive? Presumably you meant archive_1, archive_2 and archive_3? I see minor bug reports, bug reports based on misunderstandings, requests for new features. I do not see a single report that flickreview falsely certified an unfree image as free. Am I missing one? If you really think one more of those entries substantiates your assertion that the bot falsely certified an unfree image as properly lisenced, then I repeat my request you document that claim. Geo Swan (talk) 01:32, 24 December 2011 (UTC)[reply]
  • 6 supports for a massive bot that reviews tens of thousands of images is really pathetic. I would demand over 100 to be active in the discussion at the very least. It requires major project discussion, especially with its many bugs. The legal jeopardy it would put us in at the very least would demand such a thing. " All the bugs in that bug log..." because that is the first archive. You know they are archived by date, not topic, right? o.O "Further, none of those bugs are an instance of what you have claimed -- the bot incorrectly certifying an unfree image as under a free license" Wrong. In November, one of the reports says Bot clearly isn't checking against the right Flickr image nor author - hard to determine if it is the right license if it isn't even looking at the right page. Using the right page is a constant error for the bot. And the amount of reporting of the bot saying it isn't the right license means that it is getting false negatives which suggests it also gets false positives. How did you overlook all of that? The bot has had errors consistently since it began and was even blocked because of it going out of control to the point it needed to be blocked. Very few people even check the bot so that makes it possible that there is a lot not noticed. The bot should be removed at the very least. Ottava Rima (talk) 03:24, 24 December 2011 (UTC)[reply]
I see nothing to support your claim that the program has many bugs. I think I have to repeat this, as it is a point you simply are not addressing. You keep claiming this program has "many bugs", or even "many many bugs". I have asked you, several times now, to point to a single instance in the record where the bot marked a single bad image as under a good license. Rather than show a mistake was made you keep asserting the program had many bugs.
Yes, I know the bug log you pointed to was early in the bot's history, in its first archive. But please hold your criticism, as I will remind you that you chose to offer that link to establish that the bot was full of bugs. I am going to repeat -- you chose that link, a link that did not establish that the bot was full of bugs, in general, and definitely did not establish that the bot has the bug you claim.
I ask you again, how thoroughly did you check the archive? I see many requests for new features. I see people who have not understood how the program is supposed to work, and incorrectly identified features as bugs. I also see a modest number of genuine bugs -- but none of them related to the problem you claim the program has.
With regard to your claim of "legal jeopardy" -- legal jeopardy over us unknowingly carrying images that violate someone's intellectual property rights... What is your understanding of the requirements of the Digital Millenium Copyright Act? (Digital_Millenium_Copyright_Act#Takedown_Notice) My understanding is that the initial liability for the uploading of images that violate someone's intellectual property rights is placed upon the uploader. It is my understanding that liability lies on the organization where the image has been uploaded only when the party that claims to be the genuine owner of the intellectual property rights takes certain steps. Most importantly, the party that claims to be the genuine owner of the intellectual property rights has to inform the organization where the image was uploaded. If I recall correctly, the DMCA does not require the organization to immediately delete the challenged material. If I recall correctly, there is a brief grace period. So, no, I dispute that the WMF is in the dire legal jeopardy you claim.
With regard to your assertion, above, that a report from "November" says "Bot clearly isn't checking against the right Flickr image nor author". Wasn't that report from 2006-11-21 -- shortly after the bot was written? Isn't it marked as "fixed" on 2006-11-26?
With regard to your assertion that "not matching" is a "constant error"... first "not matching" would be a "false negative" -- the bot not finding an image was properly licensed when it actually was properly licensed -- the opposite error to that you claim, incorrectly passing images that weren't properly licensed. Second, this report is from April 2007 -- four months after the bot was put into commission -- almost five years ago. Note Bryan's response in User_talk:FlickreviewR/archive_2#Yet_another_Not-Matching Of course it is not reasonable for the bot to pass an image when someone edits the image between downloading it from flickr and when the bot checks it. This is not a bug. I am going to repeat this -- this is not a bug.
You claim the archives are full of bug reports. The archives contain a lot of notices of images being nominated for deletion -- these are not bug reports. The archives contain a lot of requests for help that are unrelated to concerns the bot has bugs. The archives contain claims from the individual that the bot contains a bug, but which are really instances of user error. Flickr allows its contributors to use half a dozen different creative commons licenses -- but only two of them are CC licenses we consider free. Lots of the complaints the program isn't working properly are due the complainants falling to understand that the images they thought the bug failed to recognize as under a free license were under one of those CC licenses we do not regard as free. Of the remaining reports, which do describe actual bugs, almost all date back to the first few months of the program -- four or five years ago. The genuine bugs of four or five years ago were fixed quickly. The genuine bugs were all much less serious than the serious bug you claim is in the bot. Geo Swan (talk) 09:11, 24 December 2011 (UTC)[reply]
The archives contain a lot of complaints about people regarding flickr choosing the wrong image to look at. That is a constant through its whole use. If the bot is unable to go to the correct page, then it is unable to identify if the license is correct. How does that not make sense? Ottava Rima (talk) 13:12, 24 December 2011 (UTC)[reply]
And the bot knows it is the wrong image and says it needs human eyes (it might be caused by the uploader uploading file X but linking to file Y for instance); it doesn't review itself. eg If the files have different EXIF, its a different image. Please provide an example where the bot passed an image, as opposed to falsely failing or requesting manual intervention, when the bot looks at "the wrong image"?--Nilfanion (talk) 13:50, 24 December 2011 (UTC)[reply]
"And the bot knows it is the wrong image " Only in some instances. There are many cases where it said it was a wrong license when it was looking at another image. That gives the possibility of reading another license that happens to match with what was claimed on the upload but isn't on flickr. And the bot had a long history of problems matching EXIF. There have already been dozens of examples provided, so asking for more when it is already there for everyone to see is silly. Ottava Rima (talk) 16:08, 24 December 2011 (UTC)[reply]
Please state one example here, where the bot falsely passed a review, just pointing at the bot's archive doesn't identify a specific problem. There are a lot of comments on there: Bot failing to match because the Commons uploader tweaked file (not a bug), bot failing to match because file has no EXIF (not a bug), file deletions due to FOP or flickrwashing (not a bug) etc. If it fails to match EXIF - it doesn't pass, it doesn't fail, it says "a human needs to look".--Nilfanion (talk) 17:19, 24 December 2011 (UTC)[reply]
I've had a look and I can't see a single example of "where it said it was a wrong license when it was looking at another image". FlickreviewR's failure mode for no-matching is to request human review, which is exactly the right thing to do.--Nilfanion (talk) 17:31, 24 December 2011 (UTC)[reply]
"I've had a look and I can't see a single ..." You looked through all 100,000 links? Because I found thousands of examples where it has claimed something was CC-BY when the license appears to be CC-NC. Do we have any ability to say it was actually changed? No, we do not. We only have the bot's word, and as a bot its word is meaningless. Ottava Rima (talk) 17:51, 24 December 2011 (UTC)[reply]
I looked through the archives, not the sum of its contributions, for the bug you claim is constantly mentioned in the archives; which is clearly not the case, as its not mentioned there anywhere. If I am wrong, please point me to a single image which the bot passed when it should have failed. If you don't want to trust the bot's review that's your prerogative, but you will find no support, from me or anyone else, unless you can provide actual evidence of failure. I personally think the bot is a lot more reliable than humans (the sort of errors you are ascribing to the bot, humans can and do make).--Nilfanion (talk) 18:06, 24 December 2011 (UTC)[reply]
Of course bots have problems. Humans do too (even more so), so I'm not sure what you are complaining about, other than just venting frustration (understandable sometimes, of course ;-) ). Flickrreviewr has done its job very very well, much better than humans could. It marks whether the license on flickr is correct as reported on the page here; if there is any reason to question the license in the first place obviously the Flickrreviewr stamp isn't worth much (but it helps a lot when Flickr users change licenses). Most of its old bugs were failing to match images, meaning it failed "safe" and did not report an image as "good" (meaning it then needed a human review, which would be required 100% of the time if there was no bot in the first place). Fixing the bugs reduced the number of times that had to happen, but I don't recall a situation where it marked images as "good" when they really weren't (which is the only way the bot could make the situation worse than before). Obviously many such images will later be found not OK (photo of a copyrighted sculpture, or flickrwash, etc) but that is also true of tons of "own work" uploads here. Flickr is not the problem (in fact I would be the percentage of good uploads from there is much better than uploads here). Yes things can be frustrating to track down and prove bad licenses, but it can actually better that way sometimes then direct uploads here. You get a whole lot of other photos in their photostream to have a better guess as to whether the uploaded photo was really theirs, or just part of images collected off the net, etc. We really have no practical alternative to "assume good faith" on uploads here -- anything else would make donating work incredibly onerous and therefore not done, and most uploaders are just fine -- so we just have to deal with the copyvios as we have been doing. Turning of bots and direct Flickr uploads won't help; those will turn into "own work" uploads (or worse) if people are just trying to game the system. Carl Lindberg (talk) 02:13, 24 December 2011 (UTC)[reply]
Many flickr uploads are deemed "own work uploads" with there being many doubts as to if it is actually their own work. This is especially true of the pornographic images. Ottava Rima (talk) 03:24, 24 December 2011 (UTC)[reply]
At least with Flickr, you can look at the photo stream and see if there are other photos taken with the same camera, or similar photos, or similar people, all of which help in guessing if something is really their own work or just copied from elsewhere. If a single upload here, you have a lot more work to see if another source can be identified -- it can be a lot harder to tell. Carl Lindberg (talk) 04:47, 24 December 2011 (UTC)[reply]
There are many instances where images were taken with the same camera because the pictures were all taken from the same guy (but not the flickr person). Ottava Rima (talk) 13:12, 24 December 2011 (UTC)[reply]
  • I agree with Carl that if a check shows an uploader's uploads were all snapped with a single camera, this strongly suggests the uploader was the photographer. Ottava Rima, I don't understand your point above. Are you saying you know of uploaders whose uploades were all snapped by a single camera -- where you know the commons uploader was not the flickr uploader?
  1. Once again, are you able to offer a single example of a commons uploader who only uploaded from a single uploader, where you know the commons uploader was not the flickr uploader?
  2. How do you know the commons uploader was not the flickr uploader? A week or two ago I noticed an image, or a couple of images, uploaded from flickr, where I thought it would make sense to leave a heads-up for the flickr uploader. I think my heads-up to the commons uploader, and my heads-up to the flickr uploader were tactful, because they quickly responded, both here and on flickr, to confirm they were one single individual. I recommend you follow my example here any time you doubt a commons uploader who appears to claim rights to an image from flickr that triggers your concern.
  3. A couple of years ago I participated in a discussion of a block of about one hundred military images uploaded by a Balkan contributor. I was concerned that his challengers were not extending sufficient benefit of the doubt to him, and had failed to contact him to get his side of the story. His challengers and I looked at exif data in this contributor's images. A lot of his images had been deleted, and the images that remained used about half a dozen cameras, but spread over about a decade. I offered a counter-example, a long-time, respected administrator who had been taking some very fine images over the past decade or so, whose images also showed he had used a range of cameras. That was a couple of years ago. Since then the images I have uploaded were snapped by a range of cameras, because I have owned a number of cameras. Using multiple cameras absolutely does not confirm a contributor is a copyright violator. Geo Swan (talk) 14:04, 4 January 2012 (UTC)[reply]


  • Looking at the data being collected to me it would be possible to ask that bots check a list of "questionable flickr accounts" from which they cant upload any requested images. That would mean when we run into an issue from a flickr account it can be added to list, when the issues are fixed we can just remove it from the list. The only issue would be maintaining the list but any admin could add/remove accounts form the list, could even run a bot to check for the existance previous uploads form the author when its added to the list. Gnangarra 11:12, 24 December 2011 (UTC)[reply]
  • FlickreviewR does its job well, in fact better than humans would (99.9% accuracy is high for a human, and humans will give both false positives and false negatives). The whole reason for the bot, and the review process more generally, is that without it we do not know if the image was ever available under a free licence. This means if a Flickr user arbritarily changes the licence (see this list for lots of examples), we would not be able to confirm it was ever free - and would have to delete a good, free image when in fact, we were fully in our rights to keep it. Without it, we would almost certainly have lost thousands of freely licenced files.
  • The issues of Flickrwashing were not even conceived of when {{Flickrreview}} was created, and the review process started. Of course now, it is the predominant issue with Flickr-sourced files. There are also other problems, such as FOP, which mean that a freely licenced image on Flickr is not "free enough" for Commons. This suggests to me, that {{Flickrreview}} could be toned down, to clearly indicate that it only means "This file was licenced on Flickr as above on this date", and it does not additionally imply "This file is OK".
  • Flickr-related tools, like Fliinfo, reject uploads from blacklisted Flickr accounts, but Commons itself doesn't prevent it. The Spam blacklist prevents you linking to http://www.flickr dot com/photos/38898880@N06/3574905687/in/photostream , but the spam blacklist cannot prevent you linking there as part of an upload (admins - see File:Flickr cv test.jpg). If the MediaWiki can be tweaked to have a upload blacklist to prevent links to bad URLs on upload, we could prevent any uploads from blacklisted accounts.--Nilfanion (talk) 12:37, 24 December 2011 (UTC)[reply]
If you look at flickrbot's archives, you will see a lot of people concerned with copyrighted images. Bryan, the bot's creator, even said he thought it would be important to come up with a list where such likely cases of copyright are flagged so the bot never accepts any of the user's contribs. That definitely suggests that the creator was concerned about it and did not want his bot to be connected to such problems. Just an fyi. :) Ottava Rima (talk) 13:12, 24 December 2011 (UTC)[reply]
It is obvious that the bot is unable to do what humans can do and cannot be trusted in any capacity regarding something as sensitive as copyright matters. Ottava Rima (talk) 19:10, 24 December 2011 (UTC)[reply]
Bot worked fine; human cheated. And is not it time to stop Rima? /Pieter Kuiper (talk) 19:19, 24 December 2011 (UTC)[reply]
Stop Rima? You've already made it clear that you don't care about images being copyrighted or not at Wikipedia Review and that you are using Commons to make a point of having as many images as possible without respect to proper licensing. That isn't good and puts us at serious legal jeopardy. And I nominated that image for deletion when I found out that a person went ahead and changed the license. How many other instances of that are happening that we cannot tell because there is no human review? Ottava Rima (talk) 19:35, 24 December 2011 (UTC)[reply]
With regards to the Adele image, what did the bot do? It was not able to positively review the image and called for human attention? Is that not ideal bot behaviour? Maybe this could be rectified by improved coding, so the bot doesn't need to scream for human help, but the fact the bot has limits doesn't mean its untrustworthy.--Nilfanion (talk) 19:26, 24 December 2011 (UTC)[reply]
It calls for human attention because it cannot parse the links well enough to determine what the proper image is and has never been able to fix that problem. Ottava Rima (talk) 19:35, 24 December 2011 (UTC)[reply]
Of course it won't with images like that. Compare the Commons version to the Flickr original. The Commons image is a substantial crop, so they are different images. The bot says "Commons image != Flickr image, therefore I won't pass". Coding a bot to recognise one image as a crop of another would be incredibly complicated, and liable to induce errors.--Nilfanion (talk) 19:41, 24 December 2011 (UTC)[reply]
That is the point. The bot does not have the ability to truly "scan" an image like a human eye. It compares bits of data. If someone types in the wrong flickr page or it screwed up, then how are we to really know? There were many different kinds of errors, and the problem right now that I have identified a lot of are regarding images from before it was blocked for major malfunctions. Ottava Rima (talk) 19:47, 24 December 2011 (UTC)[reply]
It only passes the file if the two bits of data match, that is if the data of the Commons file and the Flickr file are bit-wise identical. It only passes (or fails) files where there is a definitive match - anything else it says a human neeeds to look at. If "someone types in the wrong flickr page" and the bot passes it, then the "wrong flickr page" has the same image as the Commons image - hardly an error! Therefore, it is not going to pass a file where the data of the two images are different, so it is not going to pass a file by looking at the wrong thing (which is your concern).
And have you made any attempt to work out what that block was about - as opposed to saying "its was blocked, therefore its dodgy"? There is a bit of discussion at User talk:Bryan/archive/2008/12#Flickreviewr broken - which makes it clear the bot was blocked because it was pointlessly uploading files; nothing to do with the review process.--Nilfanion (talk) 19:57, 24 December 2011 (UTC)[reply]
" that is if the data of the Commons file and the Flickr file are bit-wise identical" From the complaints I've read on the bot's talk page, this does not seem necessarily true for all of the bot's history. Instead, it seems like it only use to look at the meta data at least at one point in time. And what you suggest ignores that it had to be shut down for a few weeks because of gross errors. Pointlessly uploading files verifies that it acts in a way that misreads images and language - there was no reason for it to have that error. Bugs happen all the time. Anyone who knows anything about computers would acknowledge that no program or script will be bug free or infallible. Ottava Rima (talk) 20:19, 24 December 2011 (UTC)[reply]
  • Can you quote the specific passage that led you to the conclusion the bot even once failed and reported identical images when the images were not identical? Flickr presents images rendered in a range of resolutions. The commons should use the highest resolution version. Some wikipedia contributors upload versions of the flicrk image of lesser revolution. Before it does the bitwise comparison flickrreview should confirm that the image that was uploaded was the highest resolution. When the bot guesses that the human uploader seems to have chose a lower resolution version it uploads the highest order version. The excessive uploads you complain about were completely unrelated to the failures you keep claiming the bot has made, and for which you keep ignoring requests to supply a single instance. Apparently the earliest versions of the bot uploaded the highest resolution versions of the image too often, when it wasn't nedessary. This was a minor waste of resource, worth stopping the bot, but it does not suggest, much less confirm, your claims that bot ever failed and passed a non-compliant image as compliant.
  • Similarly, your notion that the program once only compared the metadata -- please quote that passage that triggered this notion. Geo Swan (talk) 20:59, 5 January 2012 (UTC)[reply]

Commons uploaders can upload Picking up on a thread of discussion above: if we were to accept Ottava Rima's argument that we cannot trust the Seattle Municipal Archives that photos they provide license for are work for hire by Seattle government employees unless the particular employee's name is given, we would be up against the same for work of the federal U.S. government. As we've long accepted, the mere fact that a photo is in a U.S. government publication does not mean the image is in the public domain (the U.S. government often uses works of non-employees), but we take them at their word when they attribute a photo or other work to a department of the government rather than to an individual. Why on earth should we apply a different standard to what is, by all accounts, one of the half dozen best municipal archives in the country for their attributions to city departments? The only even vaguely relevant difference I can see is that one releases into the public domain and the other provides an acceptable CC license, which seems to me to be neither here nor there because the Commons accepts both equally. - Jmabel ! talk 03:27, 25 December 2011 (UTC)[reply]

Federal Government Employees are specifically determined as works of the Federal Government when they are licensed under their office. Not every employee gives up their rights to images. This has always been the case. We need to prove that it was actually part of their job. Images that I uploaded, for example, are registered in the Quartermaster General's office as being official US Army documentation of properties. They have to be officially marked, and if they are done by the US Government they are released via the National Archives or similar archives as governmental works. Municipal governments have their own laws. The Federal Government is under one. I don't know how that is so complicated. There are many states which do not make their images PD. Ottava Rima (talk) 05:33, 26 December 2011 (UTC)[reply]
The fact that "There are many states which do not make their images PD" is absolutely irrelevant to the Seattle Municipal Archives. (1) Seattle is not a state. (2) The archive does not make its images PD. (3) The archive does release (most of) the images it posts to Flickr under a CC license that is acceptable to Commons. Again, what I was saying is analogous to the federal issue is the work-for-hire question. Why would you take the federal government's word for which images are work of their employees, but not take the Seattle Municipal Archives' word for it? And why would the latter's choice of Flickr as a site to release images have any imaginable bearing on the question? - Jmabel ! talk 09:28, 26 December 2011 (UTC)[reply]

Sorry to link now to that disussion but Ottava is right. I've told for ages that FlickR can't automatically be trusted, especially if the "member is no longer active" (as FlickR nicely says). Our FlickR-bot just does its simple job: Checking whether the putative FlickR-license is compatible with commons, nothing more. Well, there is a growing body of evidence that our bot has some limits (Commons:Questionable Flickr images and User:FlickreviewR/bad-authors) and that the bot is not a guarantee for anything. For all pictures I have uploaded from FlickR I could show e-mails in which the FlickR-member agreed to change license and to upload the picture on commons. --Yikrazuul (talk) 12:24, 26 December 2011 (UTC)[reply]

As you say, the bot simply verifies the license on Flickr. It is trusted to do that job, and nothing more, but it does that job well (and is trusted to prove the license did exist on Flickr for images no longer visible). At that point, an image is basically synonymous with an "own work" upload here -- we assume good faith unless there is reason to believe that Flickr was not the original source. If that is the case, then nominate for deletion along with the reasoning that the image source was outside of Flickr (or even just not that Flickr user), and such provided reason would stand on its own merits -- the Flickrreviewr stamp wouldn't mean anything in that argument. However, if the reason is simply "the Flickr page no longer exists" or "the Flickr page now has a different license", then those reasons do not stand up, since that is only a factual situation where Flickrreviewr did prove the original page did have the license. We need find a source elsewhere, or some other reason why we think the Flickr page was not the source. It's no different than an "own work" upload, where we assume good faith that the uploader owned the rights, unless someone finds a good reason to believe otherwise. Carl Lindberg (talk) 15:42, 26 December 2011 (UTC)[reply]
Personally, i'm fucking sick of seeing the image copyright info reading Some rights reserved only to find out that it is licensed under the CC non-commercial or some other CC license we can't use. Joyson Prabhu Holla at me! 17:19, 26 December 2011 (UTC)[reply]
To paraphrase Dr. Frankenfurter, they didn't build it for you. But the bot consistently gets that right, one of the many ways it is useful. I agree with Carl that a Flickr bot upload is exactly as good or bad as a claim of {{{Own}} by a Commons uploader. - Jmabel ! talk 18:55, 26 December 2011 (UTC)[reply]
Authors can choose whichever license they want; lots of people do not want to see commercial use and that kind of thing, which is perfectly fine. For Flickr, add "&l=commderiv" to their search URLs (often easiest after you have done one search) which should limit the results to the acceptable licenses (but of course, still don't upload stuff which was obviously copied from elsewhere into that Flickr account). Carl Lindberg (talk) 05:45, 28 December 2011 (UTC)[reply]

Could someone responsible for the new orientation feature explain the undocumented resetexif parameter?

Example of a full-resolution-image: https://upload.wikimedia.org/wikipedia/commons/a/a9/Example.jpg
Example of a thumbnail generated by MediaWiki: https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/170px-Example.jpg

Could someone responsible for the new orientation feature explain the undocumented resetexif parameter? I am sorry, but I have asked this question a number of times before -- and I am afraid no one has responded with a definitive answer.

About a month ago a parameter for the {{Rotate}} bot was mentioned the "resetexif" parameter. This parameter was then undocumented. I think it is still undocumented.

It was mentioned in a context that implied it was necessary, without explaining how to use it.

I used it like this: {{rotate|degree=90|resetexif}} [2], [3], [4].

Today, on my watchlist, I see a bunch of images where someone else has used it like this: {{rotate|degree=90|resetexif}} [5], [6].

What we have here are two different good faith interpretations of how this parameter is supposed to be used.

I really think an explanation of the use of how to use the {{Rotate}} bot to cope with this unexpected surprising feature. Geo Swan (talk) 04:15, 26 December 2011 (UTC)[reply]

Way too much work. You ask for an individual responsible, well I am not but I attempt to answer your question:
Use either resetexif or a degree-number. If your image showed up properly before the MediaWiki-update, or the full resolution (=raw file, e.g. Media:Formula-on-blackboard758.jpg) of an image looks fine (only the thumbnails are wrong), then you can use {{rotate|resetexif}} OR the appropriate degree-number (e.g. with Rotatelink). If the full-resolution-image is rotated but the thumbnails are right and it is very likely that someone will view this image (e.g. because it contains small text) in full resolution, add {{rotate|0}}. All right? Regards -- RE rillke questions? 12:30, 28 December 2011 (UTC)[reply]
I documented undocumented resetexif parameter. See Template:Rotate/doc and please correct if I got something wrong. --Jarekt (talk) 13:43, 28 December 2011 (UTC)[reply]
  • Thanks. I made a mistake above. The other individual used {{rotate|resetexif}} -- which you documented. What the developers still haven't documented is what happens where someone uses both parameters as I did -- {{rotate|degree=90|resetexif}} . Geo Swan (talk) 18:03, 29 December 2011 (UTC)[reply]
  • It was intentionally not documented as most, most users should just use the correct degree number (with RotateLink). The case {{rotate|degree=90|resetexif}} is not useful. Don't do it if you do not know what it does - that simple. Use the degree number and that's it. Cheers --Saibo (Δ) 14:57, 4 January 2012 (UTC) Btw: discussing the rotate template here is not useful - I have just seen this discussion here by accident.[reply]
    • You write that the feature was intentionally undocumented. On December 5th a response to a concern over the lack of information about the strange and unexpected sudden appearance of many wrongly rotated images directed concerned contributors to COM:Rotation. And COM:Rotation tells contributors to use the resetexif feature. You contributed to COM:Rotation document.
    • Let's be clear, the software developer team deserves positive recognition, kudos, for preparing new versions, with bug fixes, and cleverly though out new features. They deserve this even even if the review that follows that tests the new version, to make sure it can be introduced profesionally, decides to not introduce this version, or to send it back for more work.
    • I think it needs to be said here that the review phase here failed. The introduction of the strange rotations feature, in this revision, unnecessarily distressed many contributors. Many good faith contributors found this failure of professional review unnecessarily squandered an unacceptable amount of their volunteer hours.
    • Some people, defending the introduction of this feature, asserted that this feaure had been on a "to do" list for some time. I do not accept that this is an acceptable justification for the sudden introduction of a disturbing undocumented feature.
    • There have been a number of suggestions as to what can be learned from this failure, in hindsight. For instance, it was suggested that it would have been less distressing if we had assumed that all the images where the rotation information in the exif data said the image should be rotated was incorrect -- and should be set to zero, prior to the introduction of this feature. Someone wrote that there were on the order of 50,000 images that had non-zero rotation specifications in their exif data. While it is possible that some earlier images were sideways, and the introduction of this new feature would fix them, there was also a large number of images that were already rendering correctly, but had misleading exif data. More commonly used or reviewed files were likely to be correctly rendered. In retrospect it seems that correctly rendered images with bad exif data were overwhelmingly more common than incorrectly rendered images that had valid exif rotation instructions which we had previously ignored.
    • I am going to repeat three things. (1) We should appreciate the efforts of volunteers on the development team; (2) This introduction of this unpleasant surprise should be a cautionary example of mistakes the development team should not repeat; (3) There is no sign that anyone on the development team has acknowledged the review step that should have preceded the introduction of the new features was either nonexistent or was a failure. Geo Swan (talk) 19:44, 4 January 2012 (UTC)[reply]
      • If you look in COM:Rotation history you will see that I did not mention the resetexif there. Yes, I could have either delete it again or go over to the template and document it there - not thought of, whatever. I am just a volunteer like you and invested way more than enough time in the rotation stuff.
        Your points (including the failed introduction process) are well known at, I guess, everyone who is involved in the rotation thing. --Saibo (Δ) 03:31, 6 January 2012 (UTC)[reply]

Gizmodo shamelessly snarfing Commons content

Do we have some kind of wall of shame for major news media sites who reuse Commons content without respecting the license (i.e., not giving attribution)? Maybe we ought to have! Gizmodo has just done it to me. What a bunch of lazy bastards they are… --Morn (talk) 19:44, 27 December 2011 (UTC)[reply]

You can add {{Published}} to file talk page with the parameter legal=no. And perhaps you should also complain by e-mailing the author Andrew Tarantola using the "Email the author" link on the webpage, as well as the webmaster if there's an address or form. — Cheers, JackLee talk 19:58, 27 December 2011 (UTC)[reply]
Thanks, Jack! I've already sent the author of the article an e-mail, but not the webmaster. I'll add the template you suggested to the file description page. --Morn (talk) 20:35, 27 December 2011 (UTC)[reply]
No worries. (Note that {{Published}} should be placed on file talk pages.) — Cheers, JackLee talk 20:38, 27 December 2011 (UTC)[reply]
Yes, I meant talk page, not description page. --Morn (talk) 20:42, 27 December 2011 (UTC)[reply]
It's a great image, by the way. Thanks for bringing it to us.
I am not a lawyer and any legal advice you get for free is close to worthless, but I would send a snail mail letter to the company, addressed to their General Counsel (by title if you can't find his/her name) together with an invoice for $500 or more (however large your chutzpah calls for) for unlicensed use of your image -- by definition, a use without meeting the requirements of the license is unlicensed. If you happen to live in or near New York, you can probably bring an action yourself in Small Claims Court.      Jim . . . . Jameslwoodward (talk to me) 23:27, 27 December 2011 (UTC)[reply]
Oooh, yes. You should try that. What fun! — Cheers, JackLee talk 08:48, 28 December 2011 (UTC)[reply]

Morn, I would seriously pursue them for breach of copyright. You have chosen to make it available under a free licence, and they have breached the licence automatically by not attributing your authorship. Gizmodo is a high traffic website, and as such the value of your work has been diluted by their ignoring the licence. A recent case of Maltese aviation photographers saw them winning in the Maltese courts damages as per this. Or you could contact them and demand that they simply credit you inline with the licence. But Gizmodo should know better than to steal works, so a letter of demand might very well be in your best interests (and also the community at large). russavia (talk) 12:33, 28 December 2011 (UTC)[reply]

Well, this is a problem and it seems that Wikimedia has no solution for that. I've just accidentally discovered this site using a photo of mine. What should I do now?--MrPanyGoff 11:41, 28 December 2011 (UTC)[reply]

Going after some Russian or Chinese copycat site might be too difficult for Wikimedia, but if I upload one of my photos to Commons I expect Wikimedia to protect and enforce its license, especially if a major US company is breaching it. If they don't, why should I upload anything to Commons at all? I bet Stallman and GNU would not be sitting on their thumbs in such a situation the way Wikimedia apparently does. Begging for donations periodically like a bum seems to be pretty much the only thing they ever do these days. Really sad, and not very motivating for would-be contributors if our stuff gets ripped off like that and WM can't even be arsed to send a letter! --Morn (talk) 12:09, 28 December 2011 (UTC)[reply]
Well, all of the advice above is good in your case also -- with the reservation that Morn is, given where his/her image was taken, probably an American and the snarfer is an American company, so the DMCA is a valid threat. I don't read Cyrillic, so I don't know who your snarfer is, but I think a resolution might be less likely.      Jim . . . . Jameslwoodward (talk to me) 11:53, 28 December 2011 (UTC)[reply]
Nope, I'm German. But even if I were American, I'd expect Wikimedia to enforce its own license, not me. I have very little to gain or lose here, but Wikimedia does if their license is considered such a joke even Gawker doesn't think it needs to obey it. After all, Gizmodo isn't Aunt Jemina's Cooking Blog but a major web site that's visited by hundreds of thousands of people per day. This sets a very dangerous precedent if they can get through with this kind of behavior. --Morn (talk) 12:15, 28 December 2011 (UTC)[reply]
Morn, just so you know, YOU are the copyright holder, not Wikimedia, therefore only YOU can enforce the licence that YOU have granted. Sorry not shouting or anything, just want to make it clear that it is your copyrights which have been breached, not Wikimedia. Send them a letter of demand, which I think I might be able to make up a template for you, and keep a note of this link (it's an archive copy of the page), and you are well within your rights to demand monetary compensation - a sum of a couple hundred Euro is usual in such cases would you believe. russavia (talk) 12:40, 28 December 2011 (UTC)[reply]
First, my apologies for the bad assumption -- if I had looked more carefully, I would have noted that it was on Hornet, not on an active carrier.
Second, WMF has to work hard to raise around US$20 million each year to pay for its various needs, both hardware and people. That does not leave any room for a budget for license enforcement -- or even for sending letters. Actually litigating this would take $50,000 before you filed suit. And, after all, it is your license, not WMF's. WMF is just a host.
Fortunately, the DMCA gives the copyright holder powerful tools to fight this sort of thing. You can, for example, notify Gizmodo's ISP that the image infringes and that the ISP must take it down. I think you will find that my suggestion above (snail mail to GC) will get action and might even get you payment.      Jim . . . . Jameslwoodward (talk to me) 12:40, 28 December 2011 (UTC)[reply]
That may be good advice for Americans, but you can't expect Europeans to want to meddle with American courts. If the Wikimedia license does not provide a means for WMF to combat license violations, then it's simply a bad and inappropriate license for this kind of project. Because then for all intents and purposes it's not really a project at all, just a random collection of files by random users that can be raped by commercial content providers every which way they want without fear of retribution. --Morn (talk) 13:31, 28 December 2011 (UTC)[reply]
Hi Morn, I'd have to disagree with that. If you publish anything, anywhere on the Internet, be it on some forum, wikipedia or a personal website you are by nature the only one who can claim your rights when these are violated. It would be great if a hoster/project could provide assistance when you need to take action to enforce your rights, but by nature this is your responsibility. In fact, wiki(|m)edia does provide assistance, as there is ample information an advice to be found here and always room for questions and discussions (such as this very one) to clear things up and help/advice you to take appropriate steps. The fact that "our" copyright law (I'm European too) is near useless in countries that choose to ignore it doesn't change that fact and doesn't make it the responsibility of WMF. The only true remedy for this is to not publish anything, ever - be it on paper or digitally. As soon as others can get their hands on it, abuse of your rights will be a fact of life. The decision to take (legal) action to defend your rights is yours alone and will depend on the perceived actual damage and the likeliness of success of the (legal) action - as is the case if someone scratches your car in the street or some such. It just is a very annoying, frustrating and time consuming road to travel, and usually quite expensive too. But this is done to you by our law enforcement systems that make it virtually impossible to have your rights protected - not by the WMF.
As for advice: Please note that Creative Commons has at least as much of a "stake" here as the WMF (if any). It is one of their license schemes that is being violated and as the licenses are their core business they have even more riding on their licenses being enforced as should be. They may also be better equipped to help you with sound legal advice and have previous experience with court cases ruling in favor of the authors of works published under their licenses.
In general you certainly have a point that it's about time to start enforcing free licenses with more vigor as indeed many, many high profile websites (also in Europe) seem to violate the licenses on a daily basis. Partially this is plain ignorance, I'm sure, but publishers should be aware that they have a responsibility in educating their editors to reuse freely licensed materials with proper respect for the copyright holders. Pudding4brains (talk) 14:51, 28 December 2011 (UTC)[reply]
Well, the GNU project would be a good counterexample where contributors transfer their copyrights AFAIK and then Stallman/GNU can take legal action where required. Of course this complete copyright transfer might not work for Commons. But maybe we could somehow give WMF permission to pursue these (higher-profile) license breaches in our name? WMF obviously doesn't have the resources to go after every single offending blog, but when bigger sites like Gawker go wrong there has to be some response I think. Just putting all files that are used illegally into an obscure Commons category isn't enough of a response.
WMF has lawyers they can consult so I'm surprised that they are not investigating how to handle this situation legally. Creative Commons has less at stake I'd say because they are not as well-known as Wikipedia. They might have originated the license, but Wikipedia/Commons is the biggest CC-licensed site that uses it. So this mess is very much WMF's problem, because Wikipedia and CC are more or less the same for most people. I certainly only use CC/GFDL because that's what Wikipedia prefers. Although the GFDL has also never been tested in court, so a pure GFDL license might not have helped here. But CC only has become so big because of Wikipedia! --Morn (talk) 17:01, 28 December 2011 (UTC)[reply]

I had the same experience 3 years ago with my map. An ad agency altered the map as printed newspaper ads and trackside billboards in subway (MTR) stations here in Hong Kong for Citibank to promote their credit cards. I encourage you to CC your complain email to the chief editor as well to make sure that their administration know your situation. It's taken me more than 3 months to settle with the ad agency for a compensation, and you may spend more if you turn to the legal side.

Commons is a platform to "host" the image for you, so don't expect Commons (and Creative Commons) can provide much help but do ask for their advices to see if they have come across similar cases before. - Xavier114fch (talk) 17:04, 28 December 2011 (UTC)[reply]

Now Gizmodo has updated their article to include my name at least. No link to Commons though. I'd call that a partial victory.
I don't see Commons as a "platform" at all. I upload photos solely for inclusion in Wikipedia, the Free content encyclopedia. To me it's clear WMF should have to share some of the legal burden because we are not uploading photos here for our personal enjoyment as on Flickr but to to build them their encyclopedia. Perhaps the CC license is just a bad choice for Commons if it means enforcement falls to the individual uploader. --Morn (talk) 22:23, 28 December 2011 (UTC)[reply]
It's not an issue with the license, it's an issue with the legal system. Since the WMF does not hold copyright to your images, they do not have standing to start legal action. --Carnildo (talk) 23:24, 28 December 2011 (UTC)[reply]
(Edit conflict) Of course Commons is a platform. This seems to be a significant misunderstanding of what uploading to Commons means. As has been said repeatedly above, the copyright holder is responsible for pursuing copyright violations, and afaik that is regardless of the license used. WMF shares no legal burden of the misuse, because you released your image under that license when you uploaded it, not the WMF. It is up to you to go after the violator. While Commons certainly wants images to be uploaded to be made available to the widest userbase, if you feel uncomfortable releasing an image under a free license, you can always upload to a local project and indicate that it should not be moved to Commons. Huntster (t @ c) 23:31, 28 December 2011 (UTC)[reply]
"upload to a local project and indicate that it should not be moved to Commons" - impossible, as image with free licence can be copied to commons - because it is with free licence Bulwersator (talk) 13:52, 29 December 2011 (UTC)[reply]
(Edit conflict):::The way I see it, Wikipedia is "our" encyclopedia, yours, mine, the citizens of the world and WMF merely kindly provides us the means to create it :o) You are and always will be the copyright holder, so enforcement has to start with you. Others may lend a hand.
Gizmodo is publicly displaying that they are too thick to even understand the simple restrictions laid out in the CC and GFDL licenses - even the "human readable" versions. Peinlich, peinlich - they should best be publicly ridiculed and made fun of. Sadly, many, many organizations and companies, including Dutch (I know for a fact) and German (I'm sure) truly seem to be this ignorant as many (if not even most) online sources/media seem to be making the same mistakes on a very large scale, daily. Frightening really, that there are so many people with such limited cerebral abilities actually earning a living in the information industry - what does this tell us about the quality of the content they are providing? :-/
In terms of help, what we (or "the WMF") could probably provide is a standard letter/form that authors can use to alert the likes of Gizmodo about these copyright infringements in a way that leaves no room for interpretation. It should probably be categorized under Educating the dumb and braindead masses of wanna be journalists and publishers about using freely licensed materials, but I think it would certainly help to have a standard letter/email explaining why it is wrong what they are doing and how it should be done. A clear Wikimedia branding on such communications may also prove to have just that little extra impact. In my experience, mostly it really just boils down to total ignorance (yes, probably based on laziness to invest some effort in reading up on the subject), which is bad enough as it is for "publishers".
Was it Napoleon who advised us to Never ascribe to malice that which is adequately explained by incompetence? Pudding4brains (talk) 23:42, 28 December 2011 (UTC)[reply]
Yes, it may be that they largely do this out of ignorance, rather than malice. Still, they need to be educated about this and how this is setting a very bad, Guttenberg-like example for everyone else.
I just sent them an email that said
Hi Andrew!
You are reusing my Commons photo (http://commons.wikimedia.org/wiki/File:Hornet_catapult.jpg) in your Gizmodo article (http://gizmodo.com/5869151/its-like-a-slingshot-but-for-planes) without attribution. This photo is licensed under Creative Commons Attribution-Share Alike 3.0 and the GNU Free Documentation License, Version 1.2, which require you to attribute properly. Please update your article accordingly.
Thanks for your cooperation!
Martin C. Doege
which was apparently sufficiently educational to resolve the matter somewhat imperfectly but (to me) satisfactorily.
Regarding the Commons as platform discussion, I think part of the problem is that the Wikipedia upload form coaxes you into uploading at Commons without fully explaining what it means for content. I'm not using Commons because I think it's so great but because the WP upload form strongly suggests to do it. Of course one can still upload to a specific WP, but in practice this seems to be strongly discouraged and all my old WP uploads got moved to Commons by other users. So it seems to me that it's almost impossible to contribute a Free photo to WP while avoiding Commons. --Morn (talk) 13:39, 29 December 2011 (UTC)[reply]

Morn -- some pro bono free-license enforcement legal work does take place around the GPL (which is not the same as GFDL or CC-SA), as discussed at en:GNU_General_Public_License#The_GPL_in_court, en:Free_Software_Foundation#GPL_enforcement, en:gpl-violations.org etc. However, what the GPL enforcers are most worried about is so-called "code-hoarding", or a company distributing a revised version of a free software program without also making available the source revisions. No issue comparable to code-hoarding arises when a photograph is used on a website without complying with the license terms... AnonMoos (talk) 14:25, 29 December 2011 (UTC)[reply]

How's this: {{License enforcement request}}. Rd232 (talk) 06:56, 1 January 2012 (UTC)[reply]

  • For what it is worth, I come across lots of images provided by wire services, that which are merely credited as "GETTY file photo", but which I know are public domain. I come across a larger number which are almost certainly public domain, but which are credited as "GETTY file photo". We, here, make what I regard as a serious mistake, and universally assume that GETTY owns the rights to all images that are credited as "GETTY file photo". I have come across images that are almost certainly public domain, where someone asserts a credit that an image is a "GETTY file photo" proves we are violating copyright, where I wasn't able to find the original {{PD-USGov}} site, but I did find other instances of the image where it was credited as "Reuters file photo", "AP file photo", "AFP file photo". Wire services routinly add public domain images to their image libraries, and redistribute them to their customers without informing them that the image is public domain.
  • The photo editors at newspapers, even major newspapers, can't be relied on to be clueful on copyright images. There was an official looking photo of W. Thomas Cumbie, a JAG colonel I uploaded. He was wearing his uniform, and standing in front of a flag of the USA. I had uploaded this uncredited image some years ago, from the Miami Herld, and credited it as PD based on its appearance. This image was challenged, and I wrote to the Miami Herald's photo editor, asking for confirmation of its provenance. Here is her reply, below.
If there was no credit line I wouldn't be able to figure it out at this point but I can tell you all our photos from guantanamo are either shot by a staff member or handout. In either case I wouldn't be able to give permission to reproduce. If you think it was government handout you might seek out their public information officer for permission. Sorry I couldn't be more helpful.
Even this is incorrect, as the image that illustrated the article that did not require clicking on "more photos" was credited to the Philadelphia Inquirer. [7] Geo Swan (talk) 21:09, 4 January 2012 (UTC)[reply]

December 28

An issue with the "Nominate for deletion" in the toolbox in the left pane

I appreciate how easy the tool made it for me to nominate a category for deletion. I appreciate how it created a Commons:Categories for discussion-sub page and listed it on the relevant page. (Good job developers!) I also appreciate that it notified the creator. What I don't appreciate is how it did that. That it signed the notification to the user with my username without giving me the chance to approve of, or customize, the message. Was I notified about this in the process and missed it? This is not my edit, but it's signed with my username!? Both under the message and in the history. I find that a tad creepy... Perhaps the notification should be rephrased to instead inform the creator who nominated the category, but not sign the notification with the nominator's name. I'd like to think I still control what I say on other people's talk pages. :-) I also suggest the tool be modified to just perform one edit (creation of the sub page?) and that the other two tasks (listing and notification) be performed by a bot. Then it will be clear for everyone who checks the history who did what. --Bensin (talk) 03:50, 30 December 2011 (UTC)[reply]

It used to do left, but that left us with a bunch of incomplete nominations. You can always go to the user's talk page and modify the edit made in your name there. - Jmabel ! talk 06:11, 30 December 2011 (UTC)[reply]
Do you want to discuss this category? Yes, I think so. You are free not to use the tool. We place default-messages on the user's talk-page because they are autotranslated. You can't be sure, if you talk in English, that the user will understand it. -- RE rillke questions? 11:19, 30 December 2011 (UTC)[reply]
Actually, it is your edit, because you initiated it -- Nominate for deletion does four things for you:
  • Puts {{Delete}} on the subject page with your reason.
  • Creates the DR subpage, also with your reason.
  • Adds the DR subpage to the day's log.
  • Notifies all users in the file's history, that did not revert, in his or her chosen language with a boilerplate message.
This is just one of a variety of tools on Commons that automates routine or difficult tasks. If, for some reason, you don't like what it does, you are free to do DRs by hand. I'd suggest, though, that because a DR is a four step process, many users fail to get it right by hand and then one of our colleagues has to clean up behind them. Please don't add to that task.     Jim . . . . Jameslwoodward (talk to me) 12:11, 30 December 2011 (UTC)[reply]
Don't get me wrong. I think the intention of the tool is marvellous. (Again, good job developers!) What I suggest are some tweaks in its implementation. It is not my intention to increase the burden of other editors to clean up after others. :-) My suggestion is that the tool either: clearly state to the nominator what four edits can be made in the user's name and 1) offer to perform them and discourage (but allow) the user to opt-out of one or more task to later perfor them themselves and 2) allow for customization of a suggested message to the creator, or: (my preferred choice) that the tool performs the first task (putting {{Delete}} on the subject page) and trigger a bot to perform the other three tasks. The bot can then in its edit comment refer to what user edit triggered the bot's response.
Hopefully this will make the user contributions more logical to read from a user perspective. One click from the user, one entry in the contribution list. Or four, if you actively agreed to have four performed for you. --Bensin (talk) 15:46, 30 December 2011 (UTC)[reply]
I don't see a need for any such refinements. The goal should be to keep the process as simple, clear and straightforward as possible. If one is going to nominate an image for deletion, one should be prepared for an autotranslated message to be left on the uploader's page in one's name. The nominator should take responsibility/credit for his/her nominations. If you don't want a bot signing your name, don't use the tool. One always has the option of adding additonal clarification on the uploader's talk page after the fact, or manually doing the DR. I think having a tool that does all four tasks automatically is tremendous, and I can't see any compelling need to screw around with it.--Skeezix1000 (talk) 16:09, 30 December 2011 (UTC)[reply]
I'll guess that you are probably in a very small minority in having discomfort with the four actions of the tool. All four actions must be done to start a correctly formed DR. If you don't like the boilerplate that appears on the user page, you are free to change it, although, as Rillke points out, it has been translated into many languages. As for whose signature should appear, all four actions are your responsibility, so your signature must go on (or in the history of) all four. It is true that you didn't write the user notice, but doing a DR requires that you notify the uploader, so either you accept the boilerplate or write your own -- either way, your signature belongs on the user page. Obviously you must sign the DR subpage, at the end of your nominating comment. Your signature does not actually appear on either the nominated page or the DR log, but it is included in the history, again, as appropriate.
As for changing the tool as you suggest, I would oppose it strongly. It would slow down all other users -- more than 100 per day -- for the benefit of a small minority. If you don't like the tool's actions, don't use it, but, if you don't, please be careful to do all four steps correctly.      Jim . . . . Jameslwoodward (talk to me) 16:24, 30 December 2011 (UTC)[reply]
The process would still be simple, clear and straightforward with any of my suggested improvements. Yes, the nominator should take responsibility/credit for his/her nominations, but we should not assume that all users using this tool are aware of what will happen when they click "proceed". The least we can do is inform the user what four steps will be taken when they do so. --Bensin (talk) 17:14, 30 December 2011 (UTC)[reply]
<-- Actually, from a casual reader's point of view Bensin's remarks seem to make perfect sense. Frankly I fail to see why an automagically generated boilerplate would need to be signed with a user's signature, especially if the user is unaware of this. It is an automated notification generated by "the system".
If there is any need (is there really?) to clarify who initiated the request it might as well be phrased as:
"Category:Whatever has been listed at Commons:Categories for discussion (by User:SoAndSo) so that the community can discus..."
(change to current version in green). The box could be left unsigned, or signed by some bot/process if need be(?). Because that is what it is: It is not the user leaving you a message, but rather a (system) message by a process/bot telling you that User:SoAndSo has put your work up for annihilation (ehhr, oh sorry, the official euphemism here is "discussion" I think it was ;o) Where is the error in the logic here? Pudding4brains (talk) 03:07, 31 December 2011 (UTC)[reply]
Script ≠ Bot. Scripts run under your account and you are responsible for its actions. Signing on talk-pages is a rule and why should the notifyee not be able to ask the notifier on his/her talk-page or find the user-page in order to see what languages the notifier is able to speak by attaining his/her user-page. The next point is that talk-pages tell a lot about users when it comes to examine whether to grant user-rights. Finally signatures are important for auto-archiving. -- RE rillke questions? 13:12, 31 December 2011 (UTC)[reply]
I think you all miss several important points:
  • A new user of the tool will only be surprised once -- and perhaps people who use tools should be surprised if they don't check out what the tool does before they use it. It seems to me foolish to slow the tool for 100+ users a day to avoid the occasional surprise.
  • If you don't use the tool, you still are required to leave a notice on the talk pages of all those who appear in the image history. You are required to sign those notices. Why should the signature on the notices be different if you use a tool to place them? Why do you want to avoid having your name show up with a DR notice on the various talk pages?
  • As a practical matter, using the boilerplate notice is essential for all of us. I'm essentially a monoglot, but even our most polyglot users write only five or ten languages well. There is no practical way to notify many of our users without using the template -- do any of you seriously propose that when you place a DR, that you are going to check the language preference of each of the people in the history and place a notice in that language, as our rules require? The template offers 40 different languages. Do any of you actually write anything like all of those?
  • Commons is very much a high volume operation. We delete about 1,100 images every day. Five or six Admins do half of those actions. Anything that slows down editors who do large volumes of work should be considered very carefully. If the changes suggested above are implemented, I plead strongly for a different version that remains the same. I have absolutely no desire to translate my user notices into appropriate languages and place them, unsigned, on user talk pages.
     Jim . . . . Jameslwoodward (talk to me) 13:18, 31 December 2011 (UTC)[reply]
There seem to be a few misunderstandings regarding my proposal.
  • One surprised user is one too many if it can be easily avoided. The now added information to the tool relieves this problem (Thanks!). Yes, the proposed bot-solution would probably slow down the process but not much and not in a way that would concern most users. It would still be just as easy to nominate anything and the end result would be pretty much the same with the difference that the edit history better would reflect who did what.
  • Yes, it makes perfect sense that users involved are notified what has been nominated and by whom. Never did I suggest they should not. My suggestion was Either: the script suggests a message (the boilerplate notice) and allows the nominator to modify or add text to it before it is delivered. or: that a bot informs the editors what has been nominated and by whom.
  • The boilerplate notice is excellent! I just don't want it (or anything else) put on someone's talkpage in my name signed with my username and withot my knowledge. I am perfectly fine with it being placed on anyone's talkpage by a bot, informing the user that I nominated something for deletion.
  • Like I said, the process would not be slowed down in a way that would concern users. Yes anything affecting many editors should be considered very carefully. That's what we're doing here and now.
I hope this clears up some of the confusion about my suggestions. --Bensin (talk) 22:12, 31 December 2011 (UTC)[reply]
Well it appears we disagree philosophically. My thinking is fairly straightforward -- the template message is placed on one or more talk pages as a direct result of my nominating an image for deletion. Therefore my signature should be under it, saying "I initiated this process and I approved this message", even if I didn't write it. Since your alternative is to write your own message -- in whatever language is required -- and then sign it, as required by our rules, you come out at exactly the same place. The difference is too subtle for my aged brain.      Jim . . . . Jameslwoodward (talk to me) 15:28, 1 January 2012 (UTC)[reply]
My philosophical stance is that if a message is not composed by me, or not viewed to me and approved by me before posted, then it is not my message and should not be signed in my username. As you can see I propose one of two alternatives be implemented. One of them (the second and my preferred solution) is that a bot places a message (unapproved and unmodified by the nominator) on the talk page and notify the editor who initiated the nomination. The nominator's name is then included in the boilerplate notice insted of under it. By the way, thanks for updating MediaWiki:AjaxQuickDelete.js/DeleteInfo. Perhaps you can also include a link the the message in question? --Bensin (talk) 16:25, 1 January 2012 (UTC)[reply]
(frustrated -- probably my last word on the subject) -- Again, if you don't know what a tool does, then you shouldn't use it. If you don't approve of the message that the tool uses, then you shouldn't use the tool. You are responsible for the tool's actions, and should be entirely happy with signing your name to them -- if not, then don't use the tool. The subtle difference between putting a sig at the bottom of the message and putting the Username in the middle of the text is too fine for me to compute.      Jim . . . . Jameslwoodward (talk to me) 16:53, 1 January 2012 (UTC)[reply]
It is not my intention to make you frustrated. Almost everything you say is true.
  • True: if you don't know what a tool does, then you shouldn't use it. But to make available a tool to users and not declare what it does is equally irresponsible. The sole information given by the tool when I used it was the link to it: "Nominate for deletion". Why would anyone assume that the tool does anything else than what it declares to do? If the declaration of content on your milk carton does not say anything about peanuts, it should be safe to assume the product does not contain peanuts without calling the manufacturer and ask them. Anyway the information is now updated and thus better reflects what will actually happen when the tool is used.
  • True: if you don't approve of the message that the tool uses, then you shouldn't use the tool. But if the tool don't reveal what message it will send and sign in your name then you have no way of approving or disapproving of it. (An update of MediaWiki:AjaxQuickDelete.js/DeleteInfo to include a link the the message in question would resolve this.)
  • True: users are responsible for the tool's actions. But, like I said, don't assume users will know what actions (good or bad) the tool will perform in their name unless you inform them. We do now, and that is a vast improvement.
  • Almost true: You should be entirely happy with signing your name to the tool's actions -- if not, then don't use the tool. There is also the option of raising the issue for discussion and suggest improvements. That's what I did, and something very good came out of it with the help from you and others. Thank you!
If you read my proposals you will notice that only one of them suggests moving the username from the bottom into the message body. That is when a bot, instead of the script, informs the editor. --Bensin (talk) 18:37, 1 January 2012 (UTC)[reply]


Adding more guidance to MediaWiki:AjaxQuickDelete.js

Yes, please do both :-) --Bensin (talk) 17:14, 30 December 2011 (UTC)[reply]
+1. Rd232 (talk) 02:33, 31 December 2011 (UTC)[reply]
+1 Bulwersator (talk) 08:09, 31 December 2011 (UTC)[reply]
{{Doing}} -- RE rillke questions? 13:12, 31 December 2011 (UTC)[reply]
Rillke, we edit conflicted above -- I take it you mean you are adding words and links to the dialogue -- all of which experienced users can simply ignore -- not adding any additional steps for the user of "nominate for deletion" to actually do? That's fine with me as long as it remains a relatively small window on my workspace.      Jim . . . . Jameslwoodward (talk to me) 13:22, 31 December 2011 (UTC)[reply]
If the result won't satisfy the ones who are very involved in the process, I will revert. I am not going to remove any action done by the script. (Just adding some words) -- RE rillke questions? 13:32, 31 December 2011 (UTC)[reply]
✓ Done. Please Please purge your browser’s cache. (You only need to do it once.)
Operating
system

Browser
Microsoft Windows or Linux macOS
Internet Explorer Press Ctrl+F5
Mozilla Firefox Hold down  Shift while clicking Reload
(or press Ctrl+F5 or Ctrl+ Shift+R)
Press  Cmd+R (reload page) or
 Cmd+ Shift+R (reload page and rewrite cache)
Opera Press Ctrl+F5 or  Shift+F5
Konqueror
Apple Safari Hold down  Shift+Alt while clicking Reload
Press Ctrl+R Press  Cmd+ Option+E (clear browser cache)
or  Cmd+R (update)
Chrome Press Ctrl+F5 or  Shift+F5
or hold down  Shift while clicking Reload
Press  Cmd+F5 or  Shift+F5
or hold down  Shift while clicking Reload

.

The guides can be edited by any admin like a normal template using wikitext. They are here: MediaWiki:AjaxQuickDelete.js/DiscussCategoryInfo and MediaWiki:AjaxQuickDelete.js/DeleteInfo.
Input is appreciated. Thank you. -- RE rillke questions? 19:09, 31 December 2011 (UTC)[reply]
The addition is a good idea -- I made a few changes -- a few word choices and using bullets for the four steps.      Jim . . . . Jameslwoodward (talk to me) 15:37, 1 January 2012 (UTC)[reply]
Thank you Jim, looks much better :-) -- RE rillke questions? 16:51, 2 January 2012 (UTC)[reply]
Per Bensin's good suggestion, I have added a link to the template message.      Jim . . . . Jameslwoodward (talk to me) 13:34, 3 January 2012 (UTC)[reply]
Thank you! --Bensin (talk) 17:31, 3 January 2012 (UTC)[reply]

Time magazine cover from 1963

I see there are many Time magazine covers on Commons at Category:Time Magazine covers from between 1923 and 1963 which I understand are based on the assumption that the copyright was not renewed. I would like to upload this cover but am not familiar with US copyright. If anybody can help clarify if is PD would be much appreciated. --ELEKHHT 06:03, 30 December 2011 (UTC)[reply]

We generally use this site to get a rough look at whether a magazine copyright has been renewed or not. As you will see there, Time renewals began in 1934, so only issues from its inception in 1923 to 1933 are dependably PD.
As shown at Wikisource, the renewals were very sporadic, so most later issues, through 1963, are also PD. Since your choice is a 1963 cover and is not on the list at Wikisource, it should be all right to upload.
For a very quick look at the complex US copyright rules, see File:PD-US_table.svg.     Jim . . . . Jameslwoodward (talk to me) 11:56, 30 December 2011 (UTC)[reply]
Cool. That would be a great image to have. - Jmabel ! talk 17:09, 30 December 2011 (UTC)[reply]
Many thanks! --ELEKHHT 23:51, 30 December 2011 (UTC)[reply]
Uffffffffffff. --ELEKHHT 02:27, 31 December 2011 (UTC)[reply]
Um... I think that Wikisource link is for issues up through 1946, but not later than that -- 1963 issues would have to be renewed in 1990 or 1991, and the records should be online at copyright.gov . Carl Lindberg (talk) 02:42, 31 December 2011 (UTC)[reply]
This discussion continues at Commons:Deletion requests/File:Minoru Yamasaki - TIME cover 1963.jpg. Apparently my reliance the Wikisource page above was wrong.      Jim . . . . Jameslwoodward (talk to me) 12:53, 31 December 2011 (UTC)[reply]

I did the research [8] on Time magazine that is on Wikisource and these are the issue of Time magazines that are public domain.

  • March 3, 1923 to January 22, 1934.
  • January 7, 1935 to June 29 1936.
  • July 3, 1939 to May 13, 1940
  • January 7, 1945 to January 29, 1945.

I did not find any issues after February 1945 that did not have their copyright renewed. (There may be some.)
Fortune magazine was also published by Time but they always renewed the copyrights. Many magazine publishers never renewed copyrights; they felt it was too much trouble. I started a page on expired copyright here. -- Swtpc6800 (talk) 22:23, 2 January 2012 (UTC)[reply]

http://onlinebooks.library.upenn.edu/cce/firstperiod.html, which I linked above, is not perfect, but covers a lot of ground. I suggest you study it carefully before putting a lot of time into a new project on Commons. (And your user name takes me back a long time!)      Jim . . . . Jameslwoodward (talk to me) 13:38, 3 January 2012 (UTC)[reply]

Rename before or after moving to Commons

Early (2006-2007) in my Wikiphotography career I uploaded hundreds of pictures to en, which have recently been marked for possible transfer to Commons. Being dissatisfied in most cases with the filenames I gave them, I wonder whether it would be better to rename them before or after the interwiki transfer. Jim.henderson (talk) 22:58, 30 December 2011 (UTC)[reply]

Rename as you do it - Commonshelper allows you to specify a new filename to move to as you transwiki. -mattbuck (Talk) 23:14, 30 December 2011 (UTC)[reply]
Or better tool - en:Wikipedia:FtCG Bulwersator (talk) 12:34, 31 December 2011 (UTC)[reply]
The filenames appear to be a bit on the short side. I guess you want them to be a bit more longer and descriptive? It's just a couple of files, I can pull them to Commons for you if you like. Multichill (talk) 10:52, 31 December 2011 (UTC)[reply]

You might consider amending en:Wikipedia:Moving_files_to_the_Commons#File_Renaming which recommends against renaming while moving. Indeed, to my mind it suggests that "after" would be best since the renaming record would persist after the en version is deleted. Anyway it's a false alarm and my fault. A couple days ago when the en:Wikipedia:WikiProject Images and Media/Commons/Drives/Jan 2012 drive assigned priorities, bumping over a hundred pictures of my watchlist into my recent change list, I assumed they were mine. No; without checking them all it appears that every one of them is someone else's, and only watchlisted because I assigned it a category long ago or made some other change to the description. So, having a long backlog of new pictures of my own to process and upload , I shall simply trim these from my en watchlist unless I've got an abiding interest in the subject. Thanks for the information; I'm sure it will be useful someday. Jim.henderson (talk) 22:05, 1 January 2012 (UTC)[reply]

I want a picture of an HF burn

I have written to 4 people who had images and have not gotten a donation. Actually it is hard to find that many even non-free images. Please help me. I am usually pretty damned resourceful...but this is kicking my ass. give me some ideas or help...

TCO (talk) 04:34, 31 December 2011 (UTC)[reply]

We have this image on the Wiki article for NaOH. I want a comparable picture for HF, fluorine, etc. articles. HF burns are very noteworthy.
There's an app for that. Rd232 (talk) 06:06, 1 January 2012 (UTC)[reply]
I just signed up. That thing seems really dead though. any ideas to track one down?TCO (talk) 07:47, 1 January 2012 (UTC)[reply]
"really dead though" - yes, it could do with some invigorating, with more vigorous promotion. Perhaps by linking with relevant Wikipedia WikiProjects? I'll think about it (suggestions welcome). As for your image - have you considered online medical journals? It's a long shot perhaps, but someone might have decided to release a relevant image with a helpful license. Or if you're committed enough, if you find a relevant non-free image in a journal you could contact the author, since for educational purposes they might well be helpful. Rd232 (talk) 13:58, 1 January 2012 (UTC)[reply]
Have you considered hot objects, or even a microwave with a broken door switch? Just a thought. --Fred the Oyster (talk) 15:19, 1 January 2012 (UTC)[reply]
HF burns your skin from underneath the surface of it, so the burns look quite different. --Claritas (talk) 16:54, 1 January 2012 (UTC)[reply]

I have not been able to find a free image online and have (literally) written to 4 different sources (two physicians who wrote journal articles, a hand doctor, and a commercial database) asking for a donation. I tried twice with Wikiproject medicine. If there were a good OSHA or USN or the like source, I could even correspond. National burn center is weak. I'm unwilling to use a burn that is not actually from HF. I was thinking about those people on Commons who like to take photos of their body...take a bullet for the cause?

Please don't suggest that Commons contributors hurt themselves to make a photograph, even in jest. Thanks, --Walter Siegmund (talk) 02:14, 5 January 2012 (UTC)[reply]

Wow, finally got a donation. how do I show a Wiki picture here?

en:File:HF burned hands.jpg

TCO (talk) 23:57, 6 January 2012 (UTC)[reply]

I don't think you can display an en wiki image here, but the edited link above should suffice. --Walter Siegmund (talk) 02:24, 7 January 2012 (UTC)[reply]
I think it could be moved here as "OTRS-pending" but for the sake of form, perhaps it could wait. I don't see even the most zealous deletionist failing to assume Good Faith on this one. Rodhullandemu (talk) 02:42, 7 January 2012 (UTC)[reply]

I sent the OTRS, right away to Commons (several hours ago). Server was down here, so IRC advised to upload to wiki. Volunteer at wiki said they have access to both OTRS queues and would straighten it out, no problem.TCO (talk) 05:11, 7 January 2012 (UTC)[reply]

OgreBot ravaging the overviewability of my files' upload histories

OgreBot ravaging the overviewability of my files' upload histories when transferring from wikies. how can i disable the additions of old files when ive already done that manually? isn't there a keep-off- / exclude-template for that? example: File:Convoy PQ18 September 1942.jpg - i only didnt upload one intermediate sh%tversion which was only a stupid useless watermarkcrop. it was a beautiful two-element history. now a goddam five. i dont want that.

(already had problems with this before :) Commons:Help_desk/Archive/2011/12#deletion_of_individual_revisions_possible ) - — Preceding unsigned comment added by Aaa3-other (talk • contribs)

Note that OgreBot's files are 11 KB while the file you uploaded was 10 KB, so the file was obviously different in some way. I guess it makes sense to upload all versions of a file for completion. --Stefan4 (talk) 12:17, 1 January 2012 (UTC)[reply]
OgreBot did this because I authorized that particular transfer.[9] OgreBot is 100% run by humans when choosing which versions to transfer. And I transferred the versions because CSD#F8 on English Wikipedia states that all versions of an image must be transferred. What does it hurt? - it's not like the old version is harming the history. If you'd prefer, from now on, I will simply decline your transfers because they are not eligible for deletion at English Wikipedia; then your version of the file will not be visible at all from there. Magog the Ogre (talk) 05:29, 2 January 2012 (UTC)[reply]
If it is very important that all versions are transferred, shouldn't CommonsHelper be reprogrammed to do that? --MagnusA (talk) 09:14, 2 January 2012 (UTC)[reply]
I think that it would be useful if Commons moving tools such as Commons Helper, Commons Helper 2 and en:WP:FTCG could move all versions instead of just the latest one, but it might be useful to opt out from that in case an image on Wikipedia needs to be split into multiple files on Commons. For your information, it was suggested at en:User talk:This, that and the other/For the Common Good#A few thoughts that uploading old versions would better be left to OgreBot. You might have an opinion about this. --Stefan4 (talk) 13:05, 2 January 2012 (UTC)[reply]
hi, ok sry its not hurting me that much that we have all versions. was maybe exaggerated somewhat. (i just manually left out that unneeded one but) if it must then let that be; and im happy to give up on this from now on as it was requested. HOWEVER, i still insist that NOT every apparent version there should be uploaded: in both the 10 vs 11kB and the 2.02 vs 2.11MB file, obviously (as i am personally extremely insistent on stating if otherwise, unlike many other users, and btw also usually state this as well when practical, but in one-summary uploads...), i only employed 1000000000% lossless huffman optimization using an official jpeg tool that doesnt remove at all any information stored in the files, not even exif, or comment, or any other unknown garbage which might be there. jsut as it supposed to be. SO, my proposition for such future manual stuff, is, in cases like where i missed a watermarkcrop, to upload only that one and then revert to latset (will be then 4-element history), and on the others, do no change. if scared then compare 'em beforehand, or maybe ask or whatever. having so huge files 2x is also painful for the mind thinking of it lol. --Aaa3-other (talk) 00:27, 3 January 2012 (UTC) (i admit though that i have made a very serious mistake, but this was only due to human error, in one of the transfers (not made by me in fact, only templated) i missed that the commons vertsion was much lower resolution. i apologise for that but it was not intended 2b subject of this discussion) - and btw was that threatlike sh%t f%cking neccessary?! i wasnt meant to offend you the bot operator...[reply]
p.s. and is it only a bug that the convoy also disappeared from my ul gallery?
re MagnusA, Stefan4: the reason it doesn't do it currently is because sometimes the file needs to be split, and (worse) sometimes there's an unnoticed non-free version of the file sitting in history.
re Aaa3: it's OK; you were frustrated, and the words weren't directed at me; I used to work a customer service job where customers swore at me all the time, although they rarely were directing it at me, just the situation. So I don't mind here . Anyway, I'll treat the two issues you brought up.
  • As general practice, I don't compare versions like that because I can delete literally thousands of commons equivalent images per week, so it is inefficient for me to check them bit-by-bit. Also, if the file is large, it can take a long time to download.
  • I had not realized it would muff your uploads. I'd always figured "it's not clear that it's lossless compression, so there is no harm in another upload" - not realizing this would happen; so I'm sorry for that. I wonder if that's something the developers would be willing to fix?
Magog the Ogre (talk) 01:30, 4 January 2012 (UTC)[reply]
hi, well when working at such a pace i guess it was really the best as you have done it. it could even do harm if another user once really re-encode something and it would go unnoticed, and i cant expect that you remember every user who is more careful. i guess that extra storage space (and even less the elegant short version history) just doesnt worth that (anyway it is only my mind protesting, financially its free nowadays...)--Aaa3-other (talk) 07:57, 4 January 2012 (UTC)[reply]

Downloading large images on Slow connections

I have dialup and decided to bite the bullet to download an image labeled "Public Domain" at full resolution. Of the 4MB it transfers about 300KB and quits, telling me it's done and leaving a partial scrap with proper extension but mostly blank. I tried loading it in a browser window with a similar truncated load. When I have this problem with other files I can download them at public computers with high speed lines, but other servises are fully willing to dribble out the data at a speed compatible with connection. Is there anything you can do through your IP to allow this leisurely operation?

Ref: http://commons.wikimedia.org/wiki/File:Sleeping_Cupid-Caravaggio_(1608).jpg http://upload.wikimedia.org/wikipedia/commons/d/d1/Sleeping_Cupid-Caravaggio_%281608%29.jpg

January 1

Search problem

All of a sudden Search isn't finding anything, even when I search for things I searched for earlier. Does it do this when it's updating its database or something like that? - The Bushranger (talk) 06:52, 1 January 2012 (UTC)[reply]

I am under the impression that the search doesn't work a couple of times per week for an hour or so, I guess when it is refreshing it search database. If this is the case, it should give a warning indeed. --Foroa (talk) 22:10, 1 January 2012 (UTC)[reply]
Search works for me, but it seems that indizes do not get updated. Changing text is not reflected in results, even after days. cheers --Herzi Pinki (talk) 23:00, 8 January 2012 (UTC)[reply]

Lissitzky died in 1941, but there are claims that the Russian copyright goes beyond 2012. Can anyone clear that matter? --AndreasPraefcke (talk) 12:38, 1 January 2012 (UTC)[reply]

Lissitzky's works are only PD in 2016, because the copyright has been extended for four years as he worked during World War II. --Claritas (talk) 12:51, 1 January 2012 (UTC)[reply]
Indeed: en:Copyright law of the Soviet Union#Transition to post-Soviet legislation in Russia and en:Copyright law of Russia#Amendments of the 1993 law. --Rosenzweig τ 13:04, 1 January 2012 (UTC)[reply]
If they were first published in Germany, they are PD in the EU, but you must be able to prove that they were not first published in Russia. --Claritas (talk) 22:24, 1 January 2012 (UTC)[reply]

TIFF rendering

Does anyone know how TIFF images are rendered to JPEG on the servers? The reason I ask is that File:Helix Nebula in infrared (captured by the Spitzer Space Telescope).tif has quite different colors compared to File:Infrared Helix.jpg, even though viewing the TIFF in an image editor on my computer, or converting it to JPEG using imagemagick's convert file.tif file.jpg, shows the same colors as File:Infrared Helix.jpg. I thought the servers were using imagemagick too, but maybe I'm mistaken or they pass some colorspace options I'm not aware of. Prof. Professorson (talk) 17:15, 1 January 2012 (UTC)[reply]

TIFF is actually a loose collection of semi-compatible file formats (rather than being a single unified file format), so the answer could be rather different for various different TIFF sub-formats. AnonMoos (talk) 21:12, 1 January 2012 (UTC)[reply]

January 2

Hi @ all!

What is the purpose of this image gallery New ships ? Could somebody write a short description why these randomly chosen ship-photos are collected in this `New Ships`-gallery? Thanks — Preceding unsigned comment added by 91.57.86.224 (talk • contribs) 2012-01-02T01:03:19‎ (UTC)

It appears to track the creation of ship categories. Not sure what the value is in this, but it may be someone's project to help maintain the ship cats. Huntster (t @ c) 01:37, 2 January 2012 (UTC)[reply]
Related discussion: Category talk:Ships by name#New ships. I am not certain if this should be in gallery namespace. MKFI (talk) 06:38, 2 January 2012 (UTC)[reply]

Hello. It seems the bot is down, as it hasn't edited all day and barely edited yesterday. (Just notifying everyone, not sure if this is the appropriate place.)  Hazard-SJ  ±  06:04, 2 January 2012 (UTC)[reply]

Peeked at the logs and didn't see anything unusual, the bot appears to be running normally. Multichill (talk) 20:57, 2 January 2012 (UTC)[reply]

Commons_talk:Deletion_policy#Privacy

Please see proposal at Commons_talk:Deletion_policy#Privacy. Rd232 (talk) 13:32, 2 January 2012 (UTC)[reply]

Public Domain day

As many of you may know, yesterday was Public Domain day. Here's a list of painters whose works became part of the Public Domain yesterday in those countries with 70 years "post morten auctoris": User:FA2010/PD2012 Please upload any images you may have of paintings and drawings of these artists to the Commons (especially if you can scan images from art books in good quality). As a license, you may use {{PD-art|PD-old-70}}. --FA2010 (talk) 14:01, 2 January 2012 (UTC)[reply]

Gallery titles

Do we have a policy about the language to use for gallery titles? I notice for a number of galleries have been moved from an English title to a Persian one: for instance Persepolis is now تخت جمشید. Of course it's the proper name of the city in the domestic language of the country, but it creates accessibility problems. Jastrow (Λέγετε) 16:24, 2 January 2012 (UTC)[reply]

I presume it comes under the same sort of rules as category names, ie the names should be mostly English unless there's a pressing or logical need to use a foreign language. And as far as I'm aware naming it in one's native lingo arbitrarily like your instance above is a no-no. I could be wrong though. --Fred the Oyster (talk) 16:48, 2 January 2012 (UTC)[reply]
One can do galleries in multiple languages for the same topic. Or one can do multi-lingual galleries. Moving a gallery with English-language captions to a Persian/Farsi name seems counterproductive (although at least the person doing this has been leaving redirects). There would be nothing wrong with adding Persian/Farsi captions to the photos in the galleries (using the usual language templates) or with creating a second Persian-language gallery on the same subject. - Jmabel ! talk 19:53, 2 January 2012 (UTC)[reply]
Commons:Galleries#Naming conventions? Multichill (talk) 20:53, 2 January 2012 (UTC)[reply]
By the way, Syria has been سوريا for a long time... AnonMoos (talk) 03:33, 3 January 2012 (UTC)[reply]
Similarly according to gallery naming conventions: Москва, Firenze, मुंबई, Երևան, თბილისი, 東京, etc. The redirects for galleries work well. Man vyi (talk) 10:10, 3 January 2012 (UTC)[reply]

... will be removed soon from the gadgets and will be replaced by the default gadget MediaWiki:Gadget-UploadWizard.js, which you can disable if you do not like Upload-Wizard. technical background, logical background. -- RE rillke questions? 16:55, 2 January 2012 (UTC)[reply]

One further "pro" is that UploadWizard can now be much more simple deactivated when there are known incompatibilities for certain browsers. -- RE rillke questions? 18:55, 2 January 2012 (UTC)[reply]

Please point me in the right direction: Where on Commons did you get consensus to disable the upload wizard in German by default? Multichill (talk) 20:48, 2 January 2012 (UTC)[reply]
I didn't do so, MediaWiki:Upload-url/de &action=history. But I endorse Saibo's decision as I do not see consensus to activate it. If I am missing anything, let me know, please. Otherwise we will run a survey on COM:Forum how to deal with. I just had no time, yet. -- RE rillke questions? 21:07, 2 January 2012 (UTC)[reply]
But why singling out people who access Commons in German? That's a completely arbitrary criteria. Why not Linux users, users whose IP starts with 64, users who live in the UTC+3 timezone, etc. Maybe they don't like UploadWizard either, but they can turn it off on their own, we should not assume that a whole arbitrary group of people want Commons to treat them differently. Prof. Professorson (talk) 22:03, 2 January 2012 (UTC)[reply]
How about, errr, how about, shall we say, what if, what if the developer's native language is German? Do you think that could be a reasonable motive? --Fred the Oyster (talk) 22:23, 2 January 2012 (UTC)[reply]
Upload-Wizard is perfectly acessable through Commons:Hochladen. It is the first option. Please note, that Upload-Wizard suffer(ed)(s) from too many bugs as I would recommend it to my best friend at this stage. Currently there is one in german language only Bugzilla33338 which causes that MediaWiki:Mwe-upwiz-deeds-macro-prompt is not shown as text. But this is only one of many. I am going to ask the German community now. -- RE rillke questions? 11:43, 3 January 2012 (UTC)[reply]
There may be remaining issues with the JS parsing library, but your message update has since been deployed, causing the specific issue in bug 33338 to no longer appear, as far as I can tell.--Eloquence (talk) 00:50, 4 January 2012 (UTC)[reply]
Note: the discussion about the German interface is now here: Commons:Upload Wizard Gadget Polling (de). Thanks Rillke! --Saibo (Δ) 03:27, 4 January 2012 (UTC)[reply]
Prof. Professorson, I would have changed the xxx interface too - but I didn't get the same feedback like from the German community. And: it is a long time standard now for the xxx interface. But, sure - could be discussed. Especially why it was activated without a legitmation. --Saibo (Δ) 03:27, 4 January 2012 (UTC)[reply]
@Multichill: It is the other way round: where did Eloquence get consensus to (try to) enable UW per default? --Saibo (Δ) 03:05, 4 January 2012 (UTC)[reply]

Upload Wizard, to-date, has been used to successfully upload more than 600,000 files, including more than 170,000 in Wiki Loves Monuments, with many thousands of new users uploading for the first time. In addition to being vastly more user-friendly, it has many features that aren't included in the standard upload form, including multi-file selection / multi-file licensing / multi-file description editing; geo-data extraction; support for upload campaigns; more understandable licensing instructions. Its usability has been tested repeatedly in both lab tests and online tests with new users. It's also been compared with the old upload forms, which are regarded by new users as horrible manifestations of evil.

So, it's the right default. It links to the old form, as well, and falls back to a simple upload form if no JS is available.

When we compare making UW the default to not doing so, we have to take into account that not doing so is likely to lead users down a path they'll find confusing, that'll be less efficient for many cases, in short, that'll bear its own frustrations and annoyances. Moreover, the old forms have both known and unknown bugs, and some of the bugs in UW are in features that don't even exist in the old forms.

With that said, although it may seem that WMF has tons of resources to throw at problems like this, we're as always very stretched thin. I'd love to have a team of 5 people working on nothing but media uploads, but our current engineering resources don't allow for that. So, while I'm happy with the quality of the product overall, it would have been great if we could have smashed through bugs faster, and I understand the frustration with breakages over the last few months. It's also the case that UW's tests aren't yet integrated into our continuous integration server, which would help surface issues and regressions more quickly.

That means that in practice, folks like Saibo and Rillke have done lots of the testing and reporting of issues which -- in a better world -- WMF would have surfaced well before deploying code. I'm grateful for that, in spite of the occasional snarky or aggressive remark.

Thanks in part to their help identifying issues, UW today seems generally pretty mature. There are only four bugs left with severity "major", and one of them is arguably an enhancement request. (If other bugs deserve the "major" severity, please say so.) The rate of feedback about broken uploads has slowed down significantly, while UW's built-in feedback system generally leads to problems becoming visible quickly. The arguments for not sending users there directly in any language are IMO pretty weak.

From anyone who has reservations about UW that aren't fundamental, I'd love to know what the main bugs or wishlist items are that they'd still like to see addressed before they feel that they can wholeheartedly enjoy using it. While it may take us a while to work through all of them, my goal is for the uploading process to really become more and more user-friendly over time.

I know my own mental wishlist: 1) fixing remaining browser issues (either by blacklisting broken features or repairing them), 2) supporting simple batch-application of metadata, 3) fixing remaining upload errors/API issues. What's yours?--Eloquence (talk) 08:43, 4 January 2012 (UTC)[reply]

Woohooo! Be aware: "we have to take into account that not doing so is likely to lead users down a path they'll find confusing, that'll be less efficient for many cases," .... Why? What is wrong with the decision the users can do at Commons:Hochladen? I do also recommend the UW for newbies - but I tell them that they need to be aware that it can fail, contain bugs or be just not suited for their usecase. I would like to see the UW gadget as a non-default gadget for those users who want to always upload with UW (knowing through the gadget's description that they use a alpha/beta version).
You're asking for a wishlist? Do a redesign of UW and bring it back to where it should be - inside the wiki with us rather than this WMF-pushed foreign object. In the meantime you could fix the big buglist. --Saibo (Δ) 15:10, 4 January 2012 (UTC)[reply]
Hi Saibo,
1) Whenever you introduce additional decision-making complexity into a piece of software, you lose users in that complexity. The problem is that a user is not a machine. That is, they will not robotically review the entire page they're looking at, weigh different options against each other, and then choose the "correct" option. Instead, they will scan the page for cues which will allow them to complete the task they were looking to accomplish. This means that if their eyes happen to first track "my own work" and not "assistant for uploading files", that's where they're going to click without further thought.
Even if they notice both options, they're not going to necessarily be in a position to consciously evaluate them against each other. Similarity and ambiguity of different options always causes confusion. That's precisely been an issue that's been hitting us in the uploading process again and again (even in UW if you remember the "Free Art License" problem). You know all about how users are willing to just click through the fastest apparent path to upload a file, so I'm surprised you seem to think that adding decision-making complexity is a good idea.
2) You also know very well that the bulk of MediaWiki's code isn't JavaScript or accessible beyond the version control system. This includes essential elements of the upload code, e.g. the upload API which provides all the functionality utilized by the various upload forms. So to characterize a piece of software as "foreign" just because it's not a gadget is simply incorrect. Indeed, even complex JavaScript gadgets are sometimes managed through version control because it's a more suitable way to keep track of changes (cf. Twinkle's GitHub repository).
Would it be a good idea to attempt an UW-to-gadget port? Perhaps, and you're welcome to give it a try, although there would be many technical considerations. Even if such a port was fully successful, you'd likely want the code to be in version control regardless, and you'd likely want to distinguish between an experimental/staging version of the code, and the current default-deployed version. Moreover, you'd want to have test-runners perform unit and integration tests as code is committed, report test results against specific revisions, etc.
All this could be accomplished within the current model. It might be nice to shortcut the deployment cycle by having an on-wiki hosted version at least of the experimental codebase, but we could, for now, simply set up an automated code push to a staging environment. The barrier to directly participating in development isn't very high. You simply request commit access. In future, we'll be using git, which will make it easier for any user to push code changes for review.--Eloquence (talk) 18:02, 4 January 2012 (UTC)[reply]
There is no question: Upload Wizard has been improved. Thanks for that.
And you are right saying that lots of bugs are caused by the new features. But this is no excuse. If an uploads fails due to such a buggy feature, you don't have won anything. Upload Wizard is nice and has potential but the old upload form is robust.
Just to give you an example (don't know whether this is still an issue): Upload the maximum number of allowed files, choose custom license for all uploads, describe and hit publish. Now it is very likely that your browser becomes unresponsive for some time.
While multiple-file-upload is a feature, if the upload fails and images+categories+descriptions are lost for lots of files, it is more and issue than if it fails for only one file. And I saw users, e.g. Nevit who uploaded some 50MB-files and then upload wizard hang up while publishing.
This is my current view on the things and I am happy to correct it. -- RE rillke questions? 15:31, 4 January 2012 (UTC)[reply]

January 3

Logo use in templates

Moved to "Commons:Village pump/Copyright#Logo use in templates" for more comments from copyright experts. — Cheers, JackLee talk 12:11, 3 January 2012 (UTC)[reply]

Downsampling as a criterion for quality image status

Should downsampled image files be automatically disqualified for quality image status? Currently a specific file is discussed (see here), however a uniform decision of policy should be made. Gidip (talk) 11:34, 3 January 2012 (UTC)[reply]

Doing so you would only punish those who do not hide it. I do it for my photos, too to speed-up upload while not having a big loss (most sensors produce a lot of pixels but no additional information). -- RE rillke questions? 14:01, 3 January 2012 (UTC)[reply]
I believe that for better or worse quality image status is given to images which look good at the full original resolution. Down-sampling is a process which would lover the quality of "quality image", however is fully justified in case of images which look blurry at full resolution, since for those additional resolution is wasted. The bottom line is that no matter how valuable an image might be, it does not qualify for quality image status if it is down-sampled or blurry at full resolution. For example I consider this image as one of my best shots, but I do not think it would quality as "quality image" because it was taken with very cheap camera and is blurry at full resolution. --Jarekt (talk) 16:00, 3 January 2012 (UTC)[reply]

To clarify things, please notice that currently Commons and Wikipedia have contrasting attitudes towards downsampling, although in most other respects the concept of a good image file is very similar between the two projects. See the following citations from Commons and Wikipedia, respectively:

Images should not be downsampled (sized down in order to appear of better quality). Downsampling reduces the amount of information stored in the image file. 1 (see also the talk page for previous discussions on the matter)

If, when viewed at 100% (actual pixels), an image appears slightly blurred and/or there are visible JPEG compression artifacts, it could benefit from downsampling. Images from modern digital cameras which produce very large (6MP or 10MP) files can look much better when slightly reduced in size. 2

To elaborate, the question can be split in two:

  1. Should images always be evaluated in full resolution or should they be evaluated in a reasonably detailed view, which may be in lower-than-full resolution?
  2. Should downsampling be totally discouraged, or should it be encouraged when the 100% view is improved?

Gidip (talk) 17:35, 3 January 2012 (UTC)[reply]

The obvious answer to me is 1. Downsampling never improves the 100% view. It baffles me why some people don't get that. --Dschwen (talk) 19:04, 3 January 2012 (UTC)[reply]
 Oppose Downsampling, for me, does not become a criterion for quality image status because, sometimes, it's necessary to downsample an image. --ComputerHotline (talk) 19:23, 3 January 2012 (UTC)[reply]
 Oppose - sometimes downsampling is necessary because the 100% view is very unattractive. This is especially true with macro shots using poor-quality equipment. While full resolution is generally preferable, downsampling should not be a reason in itself for opposition of a QI candidate unless the resolution is too low. --Claritas (talk) 19:38, 3 January 2012 (UTC)[reply]
A clarification on my above statement. Downsampling never improves the image, but in cases of seriously blurred images, like for example this one it does not matter if image is stored at full resolution of 1,728 × 2,304 pixels or if someone down-samples it to smaller resolution. The image is of such low quality that noting is lost. This can be tested by down-sampling followed by up-sampling and the resulting image should be hard to distinguish from the original. That said I agree with commons guideline of not downsampling images, since it is less confusing. All that discussion is not very relevant to quality image status, since it will not be granted to either blurry or downsampled images. --Jarekt (talk) 19:40, 3 January 2012 (UTC)[reply]
Of course the example you've given is an obviously bad photo - because it's blurred in any resolution you choose. But let me give you 3 other examples, which are much more ambivalent:
http://commons.wikimedia.org/wiki/File:Narcissus_tazetta_1.jpg (in this one, check the history for the full resolution)
http://commons.wikimedia.org/wiki/File:Colchicum_hierosolymitanum_3.jpg
http://commons.wikimedia.org/wiki/File:Colchicum_hierosolymitanum_1.jpg
These photos are pretty good in moderate resolution (still much above 2mpx), but blurred to varied extent in full resolution. Should they be disqualified from QI status, even though they look pretty good in a sufficiently detailed view? Gidip (talk) 20:37, 3 January 2012 (UTC)[reply]

I started a similar discussion in Wikipedia. Gidip (talk) 20:26, 3 January 2012 (UTC)[reply]

  • I never disqualified automatically a picture only because of downsampling, not for quality image status not even not for featured picture status. There is no need for a rule dictating how a user has to sample his pictures or not. --Wladyslaw (talk) 21:23, 3 January 2012 (UTC)[reply]
    •  Oppose IMPORTANT ! Please notice that almost the same discussion recently took place here regarding the FPC rules. I have nothing to add, that discussion was really complete in my opinion. So I strongly oppose to any project about this question. We have a (good) rule regarding the size of pictures, that's enough. I don't know if a picture "should" not be downsampled, but downsampling must not be an anti-criterion for QI.  Question Technically, who can prove (and how) if a picture is downsampled or not ? Why prohibit downsampling and not prohibit other manipulations (crops, perspective corrections, re-framing, balances of colors, increasing contrasts, removing dust spots etc etc) ? Every digital manipulation reduces the amount of information stored in the image file. Unless the rules oblige to upload only pure RAW files just out from cameras, the discussion is irrelevant. --Jebulon (talk) 23:00, 3 January 2012 (UTC)[reply]
      • @Gidip: What is "Wikipedia" ? You surely mean English Wikipedia. Please don't forget that some (a lot !) of us are working in our own language wikipedias... I think a discussion about images is really more relevant here in "Commons", which is an international Wikimedia project...--Jebulon (talk) 23:00, 3 January 2012 (UTC)[reply]
        • I fully agree. I started a discussion on en: Wikipedia becuase this is the largest Wikipedia project with the largest number of users, and they already had a guideline that contradicted ours. So I thought it might be good to rediscuss the issue in both projects, since currently one contradicted the other. Perhaps the guidelines should be rephrased more clearly in both projects. Gidip (talk) 07:12, 4 January 2012 (UTC)[reply]
  • Are you sure this is the right place for this discussion? This talk page should be better imo. Alvesgaspar (talk) 23:36, 3 January 2012 (UTC)[reply]
  •  Oppose Downsampling is a tool. Like all tools it has meaning only in the use we make of it. We should notdismiss a tool. We must judge the finished product, not how to get there. --Archaeodontosaurus (talk) 06:42, 4 January 2012 (UTC)[reply]
  •  Oppose +1 --Berthold Werner (talk) 09:28, 4 January 2012 (UTC)[reply]

I am a little bit confused of what is being opposed. Commons guideline, En Wikipedia guideline, User:Alvesgaspar suggestion that Commons talk:Quality images candidates would be a better place to discuss Commons:Quality images guidelines? I assume it is the first one, although I am not sure. I think the current guideline of not down-sampling is trying to prevent need to evaluate images like this, this or this which might have been an excellent quality images that met all other quality criteria, but down-sampling made it hard to use them. I  Support current policy. --Jarekt (talk) 12:37, 4 January 2012 (UTC)[reply]

  •  Oppose As long as a picture meets the requirements for the minimum size, I don't know, why reducing the image size should be bad. This does not affect the quality because the image is redrawn, and then has indeed just that size. Another thing is the quality of the image is stored - if it is compressed, it has a bad effect on the pressure.
  • If you want to ban shrinking the image size, you have also to prohibit the perspective correction, because perspective correction is nothing else than reducing. Nice greetings, --Haeferl (talk) 15:27, 4 January 2012 (UTC)[reply]
  • Simply put, an image should be judged solely on what the image contains, not on how it got to be the way it is. If people aren't concerned with the lens used then they shouldn't be concerned if it has been downsampled or not. --Fred the Oyster (talk) 17:31, 4 January 2012 (UTC)[reply]
  •  Oppose for stated reasons above, but note that the quality/featured processes are a good place to nicely ask a user to contribute a higher resolution version if they have one, to improve their chances of success. For all we know the higher-resolution image may be quite sharp and contain more detail. They should still be able to refuse though. Dcoetzee (talk) 12:47, 8 January 2012 (UTC)[reply]
  • Just to clarify: By just downsampling it, you never improve a photo, while it could look better in 100% view after doing so. Photos shouldn't be automatically disqualified because you know that downsampling was used. So I say "should be evaluated in a reasonably detailed view, which may be in lower-than-full resolution". If that resolution is below your borderline of MPs, you may disqualify the photo. -- RE rillke questions? 13:33, 8 January 2012 (UTC)[reply]

Sorting Category:Copyright violations by date rather than name

For a while now, Category:Copyright violations has been rather full, sometimes containing more than 400 files. This seems to result in some files remaining there for a rather long time (some days ago I sent a couple of files which weren't clear copyvios IMO, though being tagged as such, to the regular deletion requests, and those files had been tagged as copyvios for several weeks before that).

Category:Duplicate, seemingly to avoid similar problems, presents the files in a chronological order (sorted by the last date they were changed, oldest first). I think the same sorting order in the copyright violations category would help in reducing problems like described in the first paragraph.

As I understand it, one would have to change the templates that are sorting the files tagged with them into the copyvio category, like it was done here with the duplicate template. The templates involved are {{Copyvio}}, {{Logo}}, {{Fair use}}, {{Music sample}}, {{Flickrvio}}, {{France-cv}}, {{Do not move to Commons}}—did I miss any?

What do you think of changing the category sorting order as proposed? And is there someone who could change the templates accordingly if there is a consensus to do it? --Rosenzweig τ 20:26, 3 January 2012 (UTC)[reply]

It is fairly simple finding out when one file was added to a category using the API. So writing a processing-tool should be simple, too. I already contacted Lupo for the broken GalleryDetails and please note this thread. You may use VisualFileChange for this task. Click here to start. (using the sorting option). But vFC is not suitable as processing-tool and often suffers from bugs. Changing all templates and the affected scripts would be also possible but probably more work for all users. -- RE rillke questions? 21:19, 3 January 2012 (UTC)[reply]
What work would be involved besides changing the templates (which seems to be fairly easy, it seems you simply change one variable to another, as demonstrated with the duplicate template)? Having the files sorted by date without having to resort to any additional tools would be preferable IMO. --Rosenzweig τ 21:28, 3 January 2012 (UTC)[reply]
Templates, plural. Just look at Category:Problem tags and all the scripts placing those templates would have to be changed (I think there aren't a lot but finding them ...) and users who do not use those scripts would have to subst: something or add a date, right?
At {{Duplicate}}, REVISIONTIMESTAMP was prefixed as sortkey. This is no problem as long as no bots rely on it and no changes to other things would be necessary. But it is always the date of the last edit, not the date the file was tagged. But I think this is suitable here. -- RE rillke questions? 21:42, 3 January 2012 (UTC)[reply]
REVISIONTIMESTAMP would still be better than alphabetical sorting, it's not like those file are edited every other day. And perhaps I just don't understand, but why would the scripts have to be changed? As I understand it, scripts place those problem templates (we're talking about seven templates here) in the file description pages, but they don't affect the category sorting in any way. Or am I missing something? --Rosenzweig τ 22:04, 3 January 2012 (UTC)[reply]
Before reading your example with REVISIONTIMESTAMP, I thought, additional parameters should be added to the template. No, nothing has to be changed when altering the sortkey as long as no bots or toolserver tools rely on it. -- RE rillke questions? 22:40, 3 January 2012 (UTC)[reply]

I've gone ahead and changed those 7 templates accordingly. I hope that action wasn't too rash and everything works as intended. If any problems arise, those changes can be undone easily. --Rosenzweig τ 20:41, 5 January 2012 (UTC)[reply]

Ditto for {{Screenshot}}. --Rosenzweig τ 13:39, 6 January 2012 (UTC)[reply]

January 4

New Bot Registation

I plan to test running CommonsHelper (with prior permission granted from Magnus Manske) on a Wikimedia Labs instance, however while trying to create a new account called "Image Upload Bot (Rich Smith)", I get a pretty denied message saying that the name is blacklisted. How can I get this created, I don't really want to use either my own account or a non conventional username. Thanks. - Methecooldude (talk) 00:15, 4 January 2012 (UTC)[reply]

P.S PLEASE(!) leave me a message on my EN Wikipedia page if you have replied. Many thanks - Methecooldude (talk) 00:18, 4 January 2012 (UTC)[reply]
That is too long (34 characters, including "User:"). Max 29 are allowed currently. Cheers --Saibo (Δ) 03:39, 4 January 2012 (UTC)[reply]
Well, thanks for that but I don't think that's the issue, I just get "The user name "File Upload Bot (Rich Smith)" has been banned from creation as it matches one or more blacklisted character strings. " - Methecooldude (talk) 23:57, 5 January 2012 (UTC)[reply]
Solved in IRC. Bot is now named user:Upload Bot (Rich Smith) (which is short enough). --Saibo (Δ) 00:16, 6 January 2012 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Saibo (Δ) 00:16, 6 January 2012 (UTC)

Concerned about some images (Japanese, Chinese speaker)?

We have several pictures of PTFE ("Teflon") O-rings and gaskets that look somewhat professionally done. I did an image search and found them on this site. http://www.keiyougomu.com/info/

Is it a Wiki mirror or the source?

TCO (talk) 04:01, 4 January 2012 (UTC)[reply]

See also:

File:PTFE jacket.JPG

File:Oring.JPG

TCO (talk) 04:01, 4 January 2012 (UTC)[reply]

Does seem a bit suspicious, except -- the EXIF file creation time is May 28, 2007, and they were uploaded to Commons on May 30, 2007. That is not a lot of time for someone to find them on a site and then upload them here. The server date on the site you mention is sometime in 2008, so it's probably not the source. The user has a bunch of similar-looking uploads... and one or two others which seem concerning. But, at first blush... it really does look like that user took those pictures, as they were uploaded two days after they were taken. Carl Lindberg (talk) 05:08, 4 January 2012 (UTC)[reply]
Probably someone working in the field, see my File:IGBT 3300V 1200A Mitsubishi.jpg (taken on my office deskClin). --Aʁsenjyʁdəgaljɔm11671 13:29, 5 January 2012 (UTC)[reply]

Thanks guys, I love the expertise here and that I know how to tap it! Now, I just need to write more article prose...so I have room to stick more images in! :-) TCO (talk) 14:25, 5 January 2012 (UTC)[reply]

What did I do wrong here?

Hey, I uploaded an image File:Overview of Independence Street, with Building 1001 (administration building) on right, looking south, Naval Air Station Chase Field, Texas State Highway 202, east of intersection of Texas State Highway 202 and US Highway 181, Beeville, Bee County, TX.jpg, but the image will not display. What did I mess up this time? Thanks. 25or6to4 (talk) 06:14, 4 January 2012 (UTC)[reply]

I don't think you did anything wrong -- the underlying image looks fine -- but it's not thumbnailing right for me, either. Anyone? - Jmabel ! talk 06:42, 4 January 2012 (UTC)[reply]
I can not see neither the image nor the thumbnail. FF7. May be the name is too long?--Ymblanter (talk) 06:48, 4 January 2012 (UTC)[reply]
Yeah, that's it. Linux has a 255 characters limit for file names, which is exactly how many are in Overview of Independence Street, with Building 1001 (administration building) on right, looking south, Naval Air Station Chase Field, Texas State Highway 202, east of intersection of Texas State Highway 202 and US Highway 181, Beeville, Bee County, TX.jpg; that's why it can be seen at [10]. But when creating a thumbnail, the system prepends the file name with, say, "597px-", which brings the file name over the 255 characters limit; that's why [11] returns an error. Just guessing. Prof. Professorson (talk) 08:11, 4 January 2012 (UTC)[reply]
The source. You wrote "US Government". Im sure the whole US Government not came to your house and gave you this file. Provide sources where you take something from, its not so difficult. --Martin H. (talk) 12:31, 4 January 2012 (UTC)[reply]
Not to mention who the author was. --Fred the Oyster (talk) 12:57, 4 January 2012 (UTC)[reply]
Thats regretably only to find out with access to the original photo caption page which is not yet online. --Martin H. (talk) 13:00, 4 January 2012 (UTC)[reply]

Note: User:Ruslik0 fixed the issue for this file by renaming to a shorter title. Rd232 (talk) 13:15, 4 January 2012 (UTC)[reply]

Note2: I added some info at COM:MAXTHUMB and Commons:File naming. Rd232 (talk) 14:11, 4 January 2012 (UTC)[reply]

Deleting images

Hello, I found that de pictures on Commons too quickly removed. I would like you to http://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Het_verwijderen_van_afbeeldingen_op_Commons redirect, and as the discussion to read. (My english is not so good) Mvg Bakel123 (talk) 08:44, 4 January 2012 (UTC) >een gebruiker van Wikipedia Nederland<[reply]

The thing is, we're deleting them because they're copyright infringement. We're not going to worry about how fast we delete images unless you show that we could keep them if we took more care.--Prosfilaes (talk) 10:32, 4 January 2012 (UTC)[reply]
If they're copyvios then we aren't deleting them fast enough. --Fred the Oyster (talk) 10:36, 4 January 2012 (UTC)[reply]
Commons:Deletion requests/File:Oude Bakelsedyk.png - the deleting admin does not seem to have listened. /Pieter Kuiper (talk) 11:06, 4 January 2012 (UTC)[reply]
Considering the uploader's history of uploading copyvios here at Commons (just look at his talk page) I chose to doubt what was said there. If he really is the author of that image, there are a number of ways to confirm it. I suggested one of them (sending a mail to OTRS) some time ago, yet as of now he does not seem to have done that. Instead he asks elsewhere for them to send an permission to OTRS, a strange action if he himself is the author, and complains about the matter at several discussion boards (the Village pump, here, here). Those actions don't exactly lessen my doubts about the true authorship of that image. --Rosenzweig τ 11:42, 4 January 2012 (UTC)[reply]
Oh, and re “too quickly”: I decided that deletion request after two months. Hardly too quickly. --Rosenzweig τ 11:44, 4 January 2012 (UTC)[reply]
I regret the negative comments you get from Dutch editors. Dutch editors: if you made a mistake accept it, admit it and fix it. Don't blame someone else. --VanBuren (talk) 13:12, 4 January 2012 (UTC)[reply]

The bot hasn't been working properly since before Christmas, and as a result the valued images process has ground to a halt. --Claritas (talk) 18:02, 4 January 2012 (UTC)[reply]

'donate' vs 'upload' - how to fix the uploadwizard text?

Hi all. The upload wizard has a button which states 'Select a media file to donate'. This phrasing doesn't make any sense to me, since when someone uploads a file to Commons they're making it available as free content for anyone to reuse, rather than "donating" it to anyone or any organisation. So this phrasing needs to be changed, e.g. to "Select a media file to upload", or alternatively "share" or "release". I've tried to raise/address this issue multiple times via the feedback form [12] [13] [14], but this doesn't appear to be leading towards a solution.

Others have also raised this issue e.g. [15], [16], [17], [18], again without success. It also doesn't seem to be something that can be raised as an issue on translatewiki since that just tells me that "Translations to this language in this group have been disabled".

So, if the feedback tool, the mediawiki extension page or translatewiki aren't the best places to raise this ... is this page the place to raise the issue? Or is there a better page for this discussion? I've spent several hours trying to figure this out, but have yet to figure out which page this should be raised at in order to lead to a discussion and, ideally, a fix to the problem... So if this isn't the appropriate page, please could someone point me towards the right one? Thanks, and yours frustratedly.... Mike Peel (talk) 20:54, 4 January 2012 (UTC)[reply]

I think it could be kept here since Commons talk:Upload Wizard is not a very prominent place. Or you move it there and link from here.
The button must clearly tell the uploader that he/she makes the content freely available. -- RE rillke questions? 23:41, 4 January 2012 (UTC)[reply]
Yeah, that's the intent of the word "Donate". Although the nature of the release is stated several times, in general, in user interface design, it's good to employ redundancy in order to make a point clear.
But, I'm not sure the word "donate" really is that clear. We've never specifically user-tested it, as far as I know. A user could just as easily come away with the impression that they're donating a picture "to Wikipedia" as opposed to the public. Moreover, the user may upload files which have already been "donated", which makes it somewhat awkward.
So I'd be fine with changing it to "upload" if folks feel that's generally preferable. We can think of other additional ways to bring the point across. Unless someone wants to design a scientific experiment to see whether it makes any difference, I'd say let's just run a quick straw poll to see what the Commons community prefers and change it to that.--Eloquence (talk) 01:11, 5 January 2012 (UTC)[reply]
"Publish freely"? - Jmabel ! talk 01:15, 5 January 2012 (UTC)[reply]
Donate could mean "donate [certain rights] to the public" but I doubt anyone would think that instead of "donate your media file to us" so it's misleading at best. In many cases it's simply incorrect as people upload other's work, public domain, and their own work that has been previously licensed (donated publicly). Likewise they can't "publish freely" or anything other than upload/add files if they're not the rightsholder. (Rocket000 (talk) 03:36, 7 January 2012 (UTC)[reply]

RIP User:Gerardus

Just 2 hours ago, we were notified that User:Gerardus, a high-volume contributor to Commons, has died 4 days ago. For a link to the condolences page on :nl, see the last entry in Commons:Deceased contributors. --Túrelio (talk) 23:28, 4 January 2012 (UTC)[reply]

January 5

May I make an animated gif of a .en article?

Much like cars and planes moving around an airport in a time lapse, I thought it would be pretty cool to capture a single .en page during its many changes and display it as an animated gif. I doubt if the resolution will be good enough to see words, but things will be moving, thus demonstrating the busy-bee work of the editors. However, I don't think we are suppose to use screeen dumps. Is that correct? If so, could I get special permission to do this project? Doug youvan (talk) 15:36, 5 January 2012 (UTC)[reply]

Not sure why there would be a prohibition on screen dumps. Seems like the idea of being "free" is to explicitly encourage this type of thing. The only issue I could think of is if some of the text or images was later found to be a copyright violation. I would think the result would be a derivative work though, so I think the license would have to be CC-BY-SA and/or GFDL if you were to create such a work. Carl Lindberg (talk) 15:54, 5 January 2012 (UTC)[reply]
IDK where I got that sceen dump ban idea! That would have saved me a lot of work in the past had I known it was OK, because I've worked (re-drawn) to avoid such things. Doug youvan (talk) 16:19, 5 January 2012 (UTC)[reply]
It's fine, but make sure the Wikipedia logo isn't visible on the gif, as it's not freely licensed. --Claritas (talk) 16:28, 5 January 2012 (UTC)[reply]
OK, thanks, no Logo. (And we are the same entity?) That sounds like licensing stuff I do not understand, but will comply. Doug youvan (talk) 18:17, 5 January 2012 (UTC)[reply]
To a lesser extent, also be wary of the "a Wikimedia project" logo at the bottom of the page, which is also not freely licensed (although at low resolution this won't be clearly visible and so is de minims). Dcoetzee (talk) 12:41, 8 January 2012 (UTC)[reply]

Removing older versions of files

I would like to ask if it's possible to remove older versions of File:FSO Polski 2000 replica on Reymonta street in Kraków.jpg and File:FSO Polski 2000 replica on Reymonta street in Kraków (1).jpg. In case of both pictures I have removed the license plate numbers per owner's request but the older versions still remain available.

Regards. - SuperTank17 (talk) 19:37, 5 January 2012 (UTC)[reply]

Would this now be o.k. for you? --Túrelio (talk) 19:43, 5 January 2012 (UTC)[reply]
Yes. All that matters in this case is that the old versions are not visible. Regards. - SuperTank17 (talk) 22:00, 5 January 2012 (UTC)[reply]

The Charles Hotel München

Hello everybody

Could it be that in this "international" project there's a certain bias towards the English language, as it seems from several recent contributions? I hope not but I'll do my best to put the following remarks in English, though they concern a topic in Germany, where a considerable part of the population still understands German. If anybody desires a summary in German, Czech, Dutch, French, Italian, Portuguese, Spanish, or Romanian, I shall do my best; but the only languages I am really somewhat fluent in are German and Esperanto.

Maybe the subject says it all: "The Charles Hotel München" not only has its own category in Commons but also pretends a lakeside location on Ammersee (47° 59' 30.52" N, 11° 10' 14.41" E or similar). This situation, which is clearly far from reality, may have been conjectured by DschwenBot. Still it is inaccurate and highly misleading. I therefore suggest correcting it.

Shouldn't we change this erroneous and somewhat ambiguous location? It concerns at least the following pictures:

It seems a bit like commercial product placement to me. That may be alright in today's economy but the erroneous lakeside coordinates are not.

Ĉion bonan, -- Aisano (talk) 23:03, 5 January 2012 (UTC)[reply]

Du kannst diese jederzeit korrigieren. Der Bot holt die Koordinaten nur aus den Exif-Daten. Englisch nutzen wir, weil es uns erleichtert zu verstehen, was andere tun. (besonders in den Zusammenfassungen). Esperanto ist leider nicht so weit verbreitet und wurde an meiner Schule auch nie angeboten, sonst hätte ich mich sicher dafür entschieden. -- RE rillke questions? 23:23, 5 January 2012 (UTC)[reply]
Übrigens: falls du es nicht weißt, es gibt auch z.B. das Commons:Forum (ist hier ganz oben im Village Pump verlinkt). Viele Grüße --Saibo (Δ) 03:33, 6 January 2012 (UTC)[reply]
"The Charles Hotel" seems to the be hotel's name. It's in English. --  Docu  at 12:04, 6 January 2012 (UTC)[reply]
Thanks, Docu, I had no doubt about the page title. I only am somewhat embarrassed that I have to write here in a language I am not fluent in. But it looks like Saibo got the meaning of my question and was kind enough to concentrate on the meaning instead of criticizing may language usage. And I do not doubt the communicational value of English among people who master it.
Saibo, vielen Dank für die Erläuterung. Ich hatte die erweiterten EXIF-Daten nicht aufgeklappt; stimmt, da stehen die Koordinaten. Ein bisschen verdächtig, dass sie ausgerechnet an der Seepromenade von Herrsching liegen; durch Zufall kann das kaum gekommen sein.
Wirklich korrigieren kann ich die Koordinaten nicht, denn es handelt sich um die Kameraposition ({location}), die ich nicht kenne. Ich könnte sie durch die ungefähre Objektposition ({Object location|48|8|34.5|N|11|33|45.2|E|region:DE}) ersetzen; das Hotel liegt anscheinend an der Sophienstraße in München. Ich werde mir das noch überlegen; die Koordinaten der einzelnen Gebäudeteile müssten ja eigentlich leicht unterschiedlich sein, aber besser als die jetzigen Ammersee-Koordinaten wären sie allemal. -- Aisano (talk) 13:04, 6 January 2012 (UTC)[reply]
It looks like you said at least 3 or 4 things. I responded to one of them. Anyways, I fixed the coordinates. It's a known problem with camera GPS. I'm sure if you build a better camera GPS and offer it to Mattes he would use it. --  Docu  at 20:06, 6 January 2012 (UTC)[reply]

January 6

Group portraits and Group photographs

Group portraits and Group photographs

We take a look to category to Category:Group portraits by number of persons there are +200 pictures that need to be moved.

Category:Group portraits We want to know, if it is a good idea to make new categories like group portraits by number of persons and Category:Group portraits by number of rows for the Category Category:Group photographs because we think, the group portraits have been originally made for paintings and not for photographs. We are missing it there. --AtelierMonpli (talk) 11:10, 6 January 2012 (UTC), and --Funfood 11:18, 6 January 2012 (UTC)[reply]

What do you suggest?
Personally, I think it's a good idea to create more categories describing how group images are composed. Categorizing them by group size and basic alignment is a start.
These don't necessarily need to determine if an image is a photograph or a painting. Generally there are already subcategories of Category:Paintings by year that describe that a given file is a painting. Additional ones repeating that don't have any added value.
In general, we hardly use "photographs" in category names. Photographs are the primary content of Commons. --  Docu  at 12:23, 6 January 2012 (UTC)[reply]
In my opinion subcategories in Category:Group portraits by number of persons are not very useful to anybody. I can see merits of Category:Group portraits by century and possibly Category:Group portraits by country‎ and "by technique" (painting , photo , sculpture, etc.) but Category:Group portraits by number of rows or Category:Group portraits by number of persons is an overkill. May be if there were fewer subcategories of Category:Group portraits by number of persons. For example if they were in log order (ones, tens, hundreds and thousands) than it might make more sense. Also separating family units, co-workers, etc. could be useful too. --Jarekt (talk) 12:32, 6 January 2012 (UTC)[reply]
I think you are mixing theme and composition. The idea is to focus one specifically on the composition. Have a look at, e.g. Category:Group portraits with 5 persons how a portrait of 5 persons can be done/look. It's inherently different from 4 and 6. A log scale seems pointless for that.
Obviously is subject to debate with what number Category:Group portraits with many people should start, but there isn't really much benefit in discussing that.. --  Docu  at 12:39, 6 January 2012 (UTC)[reply]
If someone finds that useful and someone is willing to do the work, I do not have a problem this creating such categories. I just could not imagine use for them (probably doe to lack of imagination). --Jarekt (talk) 17:46, 6 January 2012 (UTC)[reply]

I agree with Jarekt that I cannot see any useful purpose for categorizing group photographs by the number of persons featured in them. I think it would be far more useful to categorize them by the location, the occasion when they were taken, and the relationship between the people in the group, if any (such as graduating students or employees of a company). — Cheers, JackLee talk 18:58, 6 January 2012 (UTC)[reply]

I think it's a good idea to add "by"-subcategories for occasion and relationship. Not sure if location really adds much. It already exists though. --  Docu  at 19:30, 6 January 2012 (UTC)[reply]
thats fine, so it is ok to put the portrait photographs into the category group portraits, this was my fist question. the second thing i need is only the connection from group portraits to the group photographs , then it can be found with hotcat by the way over group photographs. My first idea, to do the same categories number of persons and number of rows put to the group photographs is not nessecary, because i saw the most of the pictures in group portraits by... are paintings and in the categories down and in Category:Portraits i found most art works and no connection to the photographs.--AtelierMonpli (talk) 21:41, 6 January 2012 (UTC)[reply]
And so the question is, in which category the photographs of groups belong: Category:Group photographs or Category:Group portraits. At the moment it is irritating to have two Categories with the same kind of images (if I look for such a pic I have to look in both categories). --Funfood 21:49, 6 January 2012 (UTC)[reply]

Century categories

I have no particular problem with most of the recent changes of century categories (e.g. moving Category:19th century helmets to Category:19th-century helmets), though I think it was a large effort for not much gain. However, some of them seem completely wrong to me, for example moving Category:18th century by country‏‎ to Category:18th-century by country‏‎. In this case, "18th century" is a noun phrase, and hyphenation is improper. If we are going to do some massive thing like this over a quibble in punctuation, we ought to get the punctuation right. - Jmabel ! talk 16:55, 6 January 2012 (UTC)[reply]

Agreed. Terms like 19th-century should only be hyphenated if used as an adjective, that is, modifying the noun. Thus, "19th-century paintings" is correct, but *"Paintings of the 19th-century" is wrong. — Cheers, JackLee talk 19:00, 6 January 2012 (UTC)[reply]
Any idea where this was decided so we can bring in the relevant parties? All the changes are by bots. - Jmabel ! talk 01:46, 7 January 2012 (UTC)[reply]
As has been discussed several times recently here, the "CfD" process is currently set up in a way which is guaranteed to attract minimal participation and involvement in conversations about proposed category changes, and maximum startlement among those who had no idea that any such conversation existed until after the categories have already been changed. I'm still finding and correcting incorrect categorizations resulting from the "adolescent girls" category fiasco debacle of several years ago... AnonMoos (talk) 11:46, 7 January 2012 (UTC)[reply]
Maybe we can do some bot or template magic and have a table at the top of the Village pump highlighting open discussions at CfD? — Cheers, JackLee talk 13:46, 7 January 2012 (UTC)[reply]

Examples of some bad choices that have been made recently: Category:Balls in the 18th-century, Category:18th-century by country. - Jmabel ! talk 06:46, 7 January 2012 (UTC)[reply]

I decided to switch over because since several months, such categories have been directed piece by piece creating a considerable mess. There might be a couple of mistakes in the 12000+ categories I did rename, but it might be a better idea to help instead of criticising it. --Foroa (talk) 14:35, 7 January 2012 (UTC)[reply]
Foroa: I am trying to help. I asked above - and you have not answered - where is the central discussion on this, in which I would gladly participate. Part of trying to help is to get it right, not just to blindly impose an arbitrary rule that is wrong in many cases. Most of these moves are fine (because the century was an adjective), but some are wrong (because the century was a noun). In the latter case, blindly carrying forward an error is the opposite of "helping". - Jmabel ! talk 17:56, 7 January 2012 (UTC)[reply]
There was somewhere a discussion (cfd ?), don't remember where, and user:ecummic (or so) started to redirect the last six months hundreds of cats with the correct nth-century notation. This gradually created plenty of inconsistencies in the system and templates, so that I decided to bring the system in a consistent state. So far, we moved around 12000+ categories, so one should not wonder that there are here and there some mistakes, no systematic mistakes as far as I can see. So no need for long discussions a posteriori, there remain only 1000 to 2000 cats to be moved. I think that your comments hasve been answered by a correction some time ago, which is better than lengthy discussions. --Foroa (talk) 23:13, 7 January 2012 (UTC)[reply]

Speedy deletion of pending OTRS

It appears that the initial response time from OTRS is on the order of a month now. However, speedy deletions for missing OTRS takes only seven days. When I have mentioned this in the past, the complaint was dismissed with the comment that it only took a single click to restore the image when the tag was posted. In fact, this is not true. That's because deletion triggers a cascade of robots that removes the image links on the other wikiprojects. These are not re-linked when the file re-appears, and it's a laborious manual process to do so.

So, what's the chance we can:

1) get a re-linking robot, or… 2) have an extended SPEEDY for good-faith OTRS?

Maury Markowitz (talk) 20:52, 6 January 2012 (UTC)[reply]

Uploads with pending OTRS cases shall be tagged with {{OTRS pending}}. This way, they will survive longer. --AFBorchert (talk) 11:10, 7 January 2012 (UTC)[reply]
This does not appear to be the case, operationally. Maury Markowitz (talk) 19:37, 8 January 2012 (UTC)[reply]
Files tagged with {{OTRS pending}} should be given 30 days before they are treated as deletable for having {{No permission since}}. That's better than 7 days, but if the response time is a long as you say, not really long enough. Maybe {{OTRS pending}} should give longer - say, 60 days, unless/until the backlog is reduced. Rd232 (talk) 05:58, 9 January 2012 (UTC)[reply]

60 days would definitely help. However, it should be noted that it takes about 30 days for the initial response, and can be much longer before it's actually cleared. Still, this would help. Maury Markowitz (talk) 13:28, 9 January 2012 (UTC)[reply]

  • I would support a re-linking bot. This would make such deletions far less contentious, particularly as I have seen a number of OTRS pending cases where no email was ever sent to OTRS... -- (talk) 13:49, 9 January 2012 (UTC)[reply]

January

Licence of a picture

Hi. I´m not sure about this picture. Clearly is not own work, and I think the symbol is not PD-textlogo. It has been introduce massive way in es:WP. Thanks. --Andrea (talk) 02:18, 7 January 2012 (UTC)[reply]

Resolved
Deletion Request started by User:Claritas. Rd232 (talk) 05:36, 9 January 2012 (UTC)[reply]

Numerals Localization

Currently, a lot of huge template structures are used to localize numerals per the user's preferred language. These could all be gotten rid of if magic words supported language-wise numeral localization. This is especially important when the filepage is being viewed at another language project. The language's numerals are not necessarily the correct ones. For example, most indic language projects use arabic numerals and not the language's native ones.

So I've filed a bug for this (and other magic word localization) at bugzilla:33576. Any comments will be appreciated.--Siddhartha Ghai (talk) 04:47, 7 January 2012 (UTC)[reply]

January 8

January 2012 Move-to-Commons Drive

Hi everyone, the English Wikipedia still contains a lot of images that should be here on Commons. To get a lot of these images to Commons some users at the English Wikipedia organized the 2012 January Move-to-Commons drive. Feel like helping? You can either move the images yourself or help check the files already transfered here. Multichill (talk) 12:24, 8 January 2012 (UTC)[reply]

Commons:Revision deletion

Commons:Revision deletion is a new draft policy. This draft is intended to document current practice; it also creates the possibility for future restriction of use of RevDel (en:WP:REVDEL is very prescriptive). I suggest some initial tinkering with this draft, and then moving to adopt as a policy, and then consider possible amendments (which would have the effect of changing practice via the policy). Comments? Note: I would like to get a Sitenotice up within a week, unless serious opposition emerges either to that time frame or to the principle of the policy. Rd232 (talk) 12:29, 8 January 2012 (UTC)[reply]

question

I noticed that the URL supplied in File:Pir Gillani.jpg is a generic one to the main dea.gov site. I couldn't find a page with this image on any US government site.

This is particularly problematic for a couple of reasons.

  1. Pir is not a name, it is an honorific, that is accorded to the highest ranking members Sufis. The Gailani (alternately Ghailani) are a prominent Sufi family. So our page doesn't really identify which member of the family this is.
  2. The description field makes some serious allegations -- that the individual in this picture is a drug-lord. But we can't back this up, without a specific link to the source page.

While this image probably also qualifies as PD under {{PD-Afghanistan}}, that too would require a specific link to the source. Geo Swan (talk) 15:33, 8 January 2012 (UTC)[reply]

As can be seen here it's an AP photograph shot by Paul Wong. The subject of the photograph is of Pir Sayed Ahmed Gillani, head of the National Islamic Front of Afghanistan. So basically the image is a copyvio and the description is an attack. Having said that though there are various other pages I came across that did state that this isn't a very nice man. --Fred the Oyster (talk) 15:48, 8 January 2012 (UTC)[reply]
Sayyed Ahmad Gailani, with a better version of this photo there. -- Asclepias (talk) 15:55, 8 January 2012 (UTC)[reply]

Image has been deleted as a copyright violation based upon the above. russavia (talk) 15:53, 8 January 2012 (UTC)[reply]

February deployment (test deploy now)

We (Wikimedia Engineering) are planning to deploy Mediawiki 1.19 next month. To avoid post deployment troubles we had during previous deployment we are setting up a test site.

We are going to clone subset of some pages and configuration of several production wikis there, including Commons, to give everyone a chance to test software before it is deployed to production. The test site should be fully operational on 09-January-2012. For now you can, of course, create an account there to test various scripts or even import pages. For larger XML imports please ask petan or hexmode in #wikimedia-labs (webchat link).

In case you found any issue please use this page to report it. If you have any questions or suggestions let us know! — MarkAHershberger(talk) 20:57, 8 January 2012 (UTC)[reply]

I hope somebody finds the time to test the Commons gadgets before launch, especially those in Category:Resourceloader-unready scripts, since in MW 1.19 "Gadgets are always loaded through ResourceLoader". This includes Cat-a-lot! Rd232 (talk) 01:19, 9 January 2012 (UTC)[reply]
Cat-a-lot is there since 2011-02-16T07:39:20Z but RL usage was added here. -- RE rillke questions? 07:11, 9 January 2012 (UTC)[reply]
Hi Mark, though I appreciate this (rather discreet) in-advance warning, I (and likely many other victims of the MW1.18 disaster, sorry guys) would prefer if the still unsolved/existing problems resulting from the MW 1.18-update would be resolved before adding more of them. Just as a start, try to debug the problem underlying the following nasty error message, which I get (with a 2 seconds delay) on many (but not all) pages on Commons:
Regards --Túrelio (talk) 08:19, 9 January 2012 (UTC)[reply]
Can you add '?debug=true' to the URL you are using? That will give us more usable debugging information (rather than just the minified dump from ResourceLoader). Kaldari (talk) 10:16, 9 January 2012 (UTC)[reply]
Ähem, I'm not sure I understand what you mean by the "add ...". I see the above posted message for example when calling these URLs (recent random choice): http://commons.wikimedia.org/wiki/File:Andreyfeskov.jpg (already deleted), http://commons.wikimedia.org/wiki/User_talk:Tower2012, http://commons.wikimedia.org/wiki/User_talk:T%C3%BArelio (own talkpage), http://commons.wikimedia.org/wiki/User:T%C3%BArelio/gallery/Wien (own gallery), http://commons.wikimedia.org/wiki/User_talk:Fermedeprunay, http://commons.wikimedia.org/wiki/User_talk:Paula1989, http://commons.wikimedia.org/wiki/User_talk:Maurits90, http://commons.wikimedia.org/wiki/Commons:Deletion_requests/Images_of_IUST_buildings,_Iran. --Túrelio (talk) 11:40, 9 January 2012 (UTC)[reply]
Kaldari, it would generally be appreciated, if I could call a page like &title=FAQ&debug=true to get all RL-minified scripts unminified. Is there such a possibility? -- RE rillke questions? 11:42, 9 January 2012 (UTC)[reply]
This is likely to be caused by one of our gadgets... -- RE rillke questions? 11:38, 9 January 2012 (UTC)[reply]
With the kind help of Rillke the above mentioned problem, which occured after the MW 1.18 update, has been identified as resulting from incompatible old code in my monobook.js (now deleted) and has been effectively solved now. --Túrelio (talk) 14:12, 9 January 2012 (UTC)[reply]

January 9

Extracting a PD image from a flash site

A very large version of an image that would be quite useful on Commons (first ever depiction of a dodo, among other now extinct animals) can be found here: http://www.atlasofmutualheritage.nl/detail.aspx?page=dafb&lang=en&id=5627 But I am unsure how to obtain the image, since it is protected by an annoying Flash viewer. Can anyone help me out? FunkMonk (talk) 04:26, 9 January 2012 (UTC)[reply]

See Help:Zoomable images, may be that will help. I could not find any large versions of images following your link. --Jarekt (talk) 12:31, 9 January 2012 (UTC)[reply]

Typing long descriptions using the wizard locks up my browser

I like to type in long descriptions on my photos. When uploading using the wizard, doing so eventually causes Safari to put up the beachball-of-doom and spin forever. It appears to happen around the 1 kB mark, and is 100% repeatable. This needs to be fixed, but I'm not sure where to go. Maury Markowitz (talk) 13:24, 9 January 2012 (UTC)[reply]

As far away from Safari as you can get? --Fred the Oyster (talk) 13:52, 9 January 2012 (UTC)[reply]