Commons:Village pump

From Wikimedia Commons, the free media repository
Revision as of 11:10, 13 May 2011 by Kimdime (talk | contribs) (→‎May 13: maybe I'll get an answer one day? sorry for the spam)
Jump to navigation Jump to search

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
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/04.

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:

   
 

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Guidance re possible copyleft trolling 132 28 Normanlamont 2024-04-16 16:00
2 Help locating photo origin 0 0
3 POV image description 19 12 Yann 2024-04-13 18:50
4 Potential identification issue with photos from commanster.eu 10 4 Monster Iestyn 2024-04-14 01:14
5 Proposal affecting FoP Chile 82 16 JWilz12345 2024-04-18 08:09
6 automatically use "Igen|Matplotlib|+|s=|code=" template 1 1 Watchduck 2024-04-16 12:51
7 Wikimedia Summit 7 5 Ciell 2024-04-14 13:31
8 Why does my PDF have dimensions 0×0? 5 4 Marnanel 2024-04-12 18:21
9 djvu is tiny and in the corner 2 1 Marnanel 2024-04-15 20:48
10 New cats for computer hardware by year 13 6 Oxyman 2024-04-15 23:58
11 Exporting Images at Full Resolution from Website 6 2 Jeff G. 2024-04-16 13:00
12 How do I import a set from the LOC website? 3 2 Richard Arthur Norton (1958- ) 2024-04-16 17:28
13 Public interiors in Ecuador 3 2 Ymblanter 2024-04-17 15:51
14 Obvious copyvio patrol bot 4 4 Omphalographer 2024-04-15 18:52
15 Categorisation - this discussion needs wider input 1 1 Aafi 2024-04-16 08:34
16 Should some images have huge margins, so they look right in wikiboxes? 5 2 Watchduck 2024-04-17 18:57
17 Photo challenge February results 1 1 Jarekt 2024-04-17 02:29
18 Category:Hawker Hurricane 2 2 MKFI 2024-04-17 06:38
19 Download name should always be page name, not SVG title 7 2 Watchduck 2024-04-18 19:39
20 Category structure for members of bands 10 6 Adamant1 2024-04-17 12:40
21 watermarks and advertising 13 4 Jmabel 2024-04-19 02:09
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

April 12

File:Royal Crown of Portugal.svg isn't showing up

For some reason, File:Royal Crown of Portugal.svg isn't showing up in any of the categories that I linked it to. What did I do wrong?--Glasshouse 02:09, 2 May 2011 (UTC)

It did not show up since you have modified the derivativeFX output heavily and deleted the last nowiki tag.
Which were the source images for this svg? You need to input all at the beginning of the upload process. Currently your description page is incomplete. Cheers --Saibo (Δ) 03:17, 2 May 2011 (UTC)[reply]

Originally, I used the Royal Crown of Italy with the Royal Monogram of King Peter V of Portugal.svg image and tried to reference both it and the source for the monogram itself, but now that I have the Crown of Portugal, I wanted to swap them out. I'm sorry for the confusion and the mess I've created. I have more monograms for which I'll be wanting to swap the crowns, but I want to make sure I do things correctly. Please advise, and thanks for your help. — Preceding unsigned comment added by Glasshouse (talk • contribs) 2011-05-02T23:49:03 (UTC)

hmm, I still do not know which files. which filename hast the "Crown of Portugal"?
You can easilly fix it by yourself: open http://toolserver.org/~luxo/derivativeFX/deri1.php and name all files in the first step. One after one. Continue but do not finish the last step (this is were the full page of code is displayed). Mark this whole code and copy it. Then go to File:Royal Crown of Portugal.svg, edit, and paste the code. Then save. Cheers --Saibo (Δ) 00:59, 6 May 2011 (UTC)[reply]

Problem with template

Template:MetaCat links to Commons:Naming_categories#Categories_by_CRITERION. However, the header of Commons:Naming_categories states unequivocally:

References or links to this page should not describe it as "policy".

This is skipped because the link leads to a section. By its use in "official" template, it is implied that the non-policy is policy, and in a very sneaky way it must be said (skipping a non-policy warning by using a redirect-to-secion; the user will not normally see the warning). The result of this is major cleanup workload like this, this, this and this; see also the discussion here and here and here. Please someone fix it. Dysmorodrepanis (talk) 18:24, 2 May 2011 (UTC)[reply]

I am not sure what you would like to fix: Template:MetaCat never describes Commons:Naming_categories as "policy". In the mean time Commons:Naming_categories serves as De facto policy: it is stable and mostly unchanging capturing best practices of naming categories, like many other would be policies nobody is in the hurry of pushing it to the next level of consensus building and approvals to make it into "proper" policy. We are much more disorganized as compared to other wikipedias in this department. If you are bothered by lack of official approval you can try to push Commons:Naming_categories further in the process. --Jarekt (talk) 19:29, 2 May 2011 (UTC)[reply]
Consider the discussions I have linked. It is not a feasible policy, as may be recognized by the fact that this proposal has been around for 4 years without being accepted. Do you have any knowledge of set theory? If so, you would recognize it as impossible to implement (would it be "photos of humans by activity by country by name" or "by name by activity by country"?).
It is precisely the "de facto policy" that is causing a lot of trouble, as can be seen by the numerous categories that have been created by this "de facto policy" only to be deleted for various reasons (redundancy, bad naming, pigeonholing, disregarding of extant sorting schemes).
As for "official policy", the fact that it is an official template (i.e. not itself marked as inofficial) constitutes a claim of officiality. Suppose the license templates would link to Commons:Exemption doctrine policy instead of COM:L.
I am not bothered by the proposal status, but by the fact that this proposal is claimed as policy and used to destabilize working and 100% policy category systems. I.e. some editors are pushing it without approval as if it were policy. Some of them, however, seem simply to be misled. Some Commons subprojects use their own system within the scope of COM:CAT (COM:CAT is the only official categorization policy that may be linked by anyone or anything), which is not accomodated by and runs against the one proposed here, and this is being wrecked piecemeal. The categorization backlog is bad enough to start with, and as an editor who is mainly doing category cleanup I find this a major nuisance and pointless proliferation of categories (introducing an additional layer of complexity in direct violation of COM:CAT#Creating a new category #1).
Again, read the CfD links I provided and perhaps read some introductory work into set theory. The proposal is pigeonholing through and through; the basic idea is alright but the implementation is a load of crap (Do we have people on Commons who have professional experience with set theory I wonder, or am I the only one?). Dysmorodrepanis (talk) 13:00, 4 May 2011 (UTC)[reply]
As I stated already several times, the links are referring to some sort of prevailing definition of a meta category, not to a standard. I have changed many hundreds of would-be meta categories with that as a reference and rationale. As far as I know, this part of the Commons:Naming_categories#Categories_by_CRITERION has never been contested. If you want absolutely avoid a mix up, you can move the meta cat definition to another page and change the related links. --Foroa (talk) 13:38, 4 May 2011 (UTC)[reply]
"Never been contested"? Well you too need to read the CfD links I provided. The metacat project was abandoned for 2 years before some ignorami started to push it in force and to mess up the extant category system with it. That is the problem here. We are struggling hard to maintain categories, and this is absolutely unhelpful and disruptive; pushing such a pet project that has been shown times and again to have grave errors cannot be considered in good faith anymore.
It looks good in theory but it sucks in practice, because whoever set it up had insufficient hands-on experience with catsorting on Commons.
In a nutshell, COM:CAT is MANDATORY POLICY and Commons:Naming_categories#Categories_by_CRITERION IS NOT POLICY, and you are not permitted to overthrow this simply because you like the proposal so much (it is bad faith editing!).
Because we have an extant category system that is working well, only certain metacategories are permitted under certain circumstances. Whereas the present state invites users to invent them whole cloth, sensible or not. Dysmorodrepanis (talk) 14:02, 4 May 2011 (UTC)[reply]
Addendum: see Commons:Requested_moves#Metacategories, Commons:Categories for discussion/2010/02/Category:Rivers by country by name, Commons:Categories for discussion/2009/12/Some of categories "by alphabet", Commons:Categories for discussion/2010/10/Category:Flat categories, Commons:Deletion requests/Category:Countries by category, Category talk:Templates generating hCards, Commons:Village_pump/Archive/2009/10#Categorize_and_CatDiffuse, Category talk:Categories of the United States by state, Commons:Categories for discussion/2010/08/Category renames for quick review - Round 1: Meta categories and several points raised at Commons talk:Categories.
How can anyone seriously claim that this is workable and uncontested? On the contrary! Even the editor who originally proposed it says:

I totally agree that we [have] been getting carried away with these metacats.

I stand by my proposal to let metacategories evolve (create them whenever the parent category is >200 subcategories according to the criteria used by the subcategories), but not to permit their creation "just so". The sorting criteria have been established in ignorance of the category tree that is already in use. Maintaining the present metacategory scheme would in essence establish 2 conflicting categorization schemes for Commons.
The biggest problem - the main pigeonholing issue - which will completely screw this up is this:
As soon as there are too many metacats themselves, they need to be stacked. This works only according to the proposed guidelines if the stacking topics are themselves hierarchical (part of the same category subtree). E.g. "state" as a subdivision of "country", this will be "by country by state". But if stacking topics are part of different subtrees, it cannot work:
Consider Category:People by occupation by country, Category:Occupations by country, Category:People by occupation, Category:People categories by country. Why is the name "People by occupation by country"? There is no logical reason to prefer it over "People by country by occupation", because countries and occupations are not in a hierarchical relationship.
This problem will increase in scope as more content is pigeonholed into metacats, and at some point it will be realized that the metacat system is completely unworkable as proposed (it creates more problems as it grows) and it will have to be abandoned. The workload will be beyond belief. To put it on hold and eliminate any formal reference to it until it has been sorted out seems to only feasible solution to prevent Commons from imploding on itself.
In a nutshell, this conflict is between those who create metacategories, and those who actually categorize files and have to deal with the mess on a daily basis. In some cases it has become so tangled that you can't even use HotCat anymore. Dysmorodrepanis (talk) 14:19, 4 May 2011 (UTC)[reply]
{{Metacat}} links to Commons:Naming categories#Categories by CRITERION in order to describe the term "meta category." It does not refer to it as a policy. It does not imply that it is a policy any more than {{CatDiffuse}} implies that Commons:How to create new subcategories is a policy. On my screen, Category:Commons proposed policies and guidelines and Category:Commons help are clearly visible at the bottom to dispel any doubts.
Certainly does refer to it as a policy! Not verbatim, but the template is not marked as "proposal" and it skips the introductory warning; it furthermore cannot refer to it verbatim because templates generally do not make such a reference; they are (or ought to be) based on policy and refer to it by linking to it (consider the "categorise" template for an example). Dysmorodrepanis (talk) 15:49, 4 May 2011 (UTC)[reply]
The term "meta category" is probably not self-explanatory to most people, so linking to an explanation is, in my opinion, useful. As long as we have meta categories and a {{Metacat}} template, not linking to the definition of "meta category" from {{Metacat}} would probably not avoid the cleanups you linked to.
My idea would be to add a brief section to COM:CAT and link it from the template. Dysmorodrepanis (talk) 15:49, 4 May 2011 (UTC)[reply]
I have read the discussions you linked to. I have done a fair amount of categorisation work. It is still not clear to me what you would like to achieve. Are you suggesting that we do away with categories like Category:People by country, move over 200 subcategories directly into Category:People and do away with the concept of meta categories and {{Metacat}} altogether? —LX (talk, contribs) 14:54, 4 May 2011 (UTC)[reply]
No, I am advocating to exercise far more restraint with metacategories:
  • change the link in the template (so that novice users are not encouraged to "metacategory spamming"), e.g. make a short metacat guideline under COM:CAT#How to categorize: guidance by topic
  • create them only when needed (as in the "People by..." example - "over 200", that would entirely warrant metacategories I think)
  • explicitly prohibit metacategories for immediate daughter categories if the "over 200" rule does not apply. E.g. no "Green animals by taxon" as long as there are less than 200 subcategories in Category:Green animals. (Rationale: this is in direct violation of the mandatory policy "Do a thorough search, to be sure there isn't an existing category that will serve the purpose")
  • allow a working metacategorization scheme to evolve on an as-needed basis and then revise the propsal accordingly and make it official. It would certainly get my vote.
The idea is sound in theory but the implementation is flawed in practice (Category:Ursus maritimus in Manitoba would eventually be in "Organisms by taxonomic kingdom by species by location" - or "by location by taxonomic kingdom by species"? Or perhaps "Organisms of Canada by..."?)
Because at present sweeping changes to Commons' categorization system are being implemented without any proper discussion or established guideline, and not based on accepted policy, and too often without further maintenance (once the metacats are created, their creators too often tend to treat them as their private property yet do no maintenance work). This is not acceptable; it violates all that Commons stands for.
In the meantime, we need to categorize. Clean up the horrendous backlog.
Because we cannot really tell what metacategories are "good" in the long run, except in a few cases (like "People"). I've been cleaning up "Nature of [country]" categories for the last half-year, and boy is the content mis- or undercategorized. And we cannot (meta)categorize what we cannot see.
And this is the biggest problem: people tend to create erroneous daughter categories, because they think they are warranted, instead of populating the main category first and then choosing what main category is warranted... this applies not just to metacategories, but to all categories: consider Category:Ratingen; I refrained from creating "Animals of Ratingen" but it would certainly be more warranted than Category:Automobile dealerships in Ratingen... Dysmorodrepanis (talk) 15:49, 4 May 2011 (UTC)[reply]
Actually, I hadn't read your last post when I wrote this. You certainly have a valid points about problems with multi-level meta categories. I don't think that what you say is contradicted by Commons:Naming categories#Categories by CRITERION or that the proposed policy suggests creating complex meta category structures willy-nilly. There are de facto common practices even for multi-level meta categories. Perhaps we should try to examine what they are and which ones make sense, and formalise them. —LX (talk, contribs) 15:16, 4 May 2011 (UTC)[reply]
Agree, except for the willy-nilly bit. Because I have seen this in practice - daughter metacats being created to unite a handful of subcategories because "we have the parent metacat". E.g. "by country" metacategories in a category which contains only very few country daughter categories, like Category:1174 by country. The user going to Category:1174 has to go to the metacategory, but there is no practical reason not to put Category:1174 in Georgia directly into "Category:1174" until we have subcategories for many countries and topics there. The metacategory needlessly introduces another layer of complexity.
As for a working policy, perhaps "meta-categories should parallel the extant category subtree" perhaps. As it is now, it invites to create metacategories that are not in line with the extant categorization scheme, based on the fact that a similar metacat has been used elsewhere. Dysmorodrepanis (talk) 15:49, 4 May 2011 (UTC)[reply]
(Edit Conflict) Dysmorodrepanis, I also read discussion above and checked your links but still have problems what you object to what is your proposed solution. What I gather is that you are frustrated with current categorization approach. I agree with your frustration, see Commons:Village_pump#Category_Intersections discussion related to this subject. I do not think you need set theory to see that current system does not scale well and can not be maintained forever. I do not like Categories_by_CRITERION with 2 "by"s and do not think 3 "by" should be ever used. But I like Categories_by_CRITERION so subcategories by different criterion are not mixed together. My ideal categorization approach would be similar to the one proposed by Multichill here, possibly combined with software improvements for handling categories with more than 200 files. Metacategories you object to, are only specialized categories not intended for files. As with any tree structure some nodes serve as leaf node and store files, some are internal nodes with subcategories and files, and some are intended to store only other categories - for lack of better name we called them "metacategories". They are identified by {{Metacat}} so it is easier to spot files incorrectly using them and move them to the proper categories (either parent or sub-category). By the way COM:CAT is not a policy: it does not claim to be and is not listed in Commons:Policies and guidelines. We actually do not have any policy related to categorization other than this. Also your points might be taken more seriously if you refrain yourself from calling other users "ignorami" and "wondering" if you are "the only one" with "professional experience with set theory". --Jarekt (talk) 15:59, 4 May 2011 (UTC)[reply]
(Fixing Edit Conflict) Removing a sentence no longer valid since Dysmorodrepanis explained source of his frustration, with which I mostly agree. --Jarekt (talk) 16:19, 4 May 2011 (UTC)[reply]
Fair enough, but it is frustrating to be threatened because one has "dared" to tag a redundant metacat for merge. And people who simply like to spam metacategories but do no actual category maintanance work are bad-faith editors, and I do not think notorious bad-faithers deserve kind treatment.
I am not frustrated with present categorization, but by the fact that metacategories tend to overthrow it even if it worls fine as it is (NCARS).
As to the main problem - e.g. Category:Animals of Canada would not seem to need metacategories now, and possibly ever. Because its subcategories will be limited to "Animals of [Canadian province]", and "[Animal taxon] of Canada", and special-purpose categories (zoos, statues, hunting, books, husbandry etc, which are not amenable to be put into a single metacategory). We can pipe the province categories with "| " and the special-purpose ones with "*" and pipe the taxon categories with "|[taxon]", just as it has been done forever.
The main problem with (multilevel) metacategories: file-sorting and file-browsing is actually made more complicated if one has to look into the metacategory to see whether an appropriate subcategory exists for the parent category where you move content down from.
And yes, set theory is very helpful here. The "overlapping categories" problem is precisely that. Commons, in general, has a problem with a tendency to value quantity over quality. It fails where the English Wikipedia has been hugely successful: getting the respect of people with expert knowledge. Dysmorodrepanis (talk) 16:19, 4 May 2011 (UTC)[reply]
I tweaked Commons:Naming_categories#Categories_by_CRITERION a bit to clarify that categories with too many BYs are not recommended. If there are other specific objections you have to this recommendation page, lets discuss it here how it should be fixed. Dysmorodrepanis you mentioned merging metacategories with each other or with parent category. The problem with that is that let say you have Category:Paintings and it has 100's sub categories. Categories_by_CRITERION allow us to group them logically into sets based on some criteria so that Category:Oil paintings, Category:Paintings in Russia and Category:1061 paintings do not have all sit in Category:Paintings. Categories_by_CRITERION are most likely unnecessary for categories with small number of subcategories or files. --Jarekt (talk) 19:31, 4 May 2011 (UTC)[reply]
Again: I agree fully that metacategories should be implemented whenever the number of daughter categories is too large (200 - they need do be created. 100 - they can very well be).
The problem is that some editors create metacategories with great enthusiasm, even if they will only contain a single subcategory, and often will block any attempt to merge them back and sometimes even become abusive because someone has dared to touch "their" creation. I can sort of understand the psychology behind that (nobody who has built a large part of Commons likes to see it taken down again), but it is still wrong. We're not doing all this for self-glorification; there is no medal going to the editor with the largest number of contributions. We're doing this so that the users can find their content with the least number of clicks and confusion, or at least this is how it should be.
Thus, metacategories should be something that is used whenever there is need to diffuse a messy jumble of dozens and dozens of subcategories. But as you can see this is clearly not the case; we have a veritable "metacategory spam" problem already that has resulted in a major usability issue. Trying to correct this is going to take a lot longer than it took to create them in the first place, so we are left with a losing battle if no action is taken to restrict the creation of metacategories to the cases where it is necessary. The four proposals I outlined above will, I think, serve this purpose. If they (or something similar) are implemented, we will eventually arrive at a metacategorization scheme that is stable and can be adopted as policy (or de facto policy considering COM:TOL is not official <---- why isn't it? It's been around as long as I can remember). What is happening now is basically people trying to guess what content will be there in the future, but this is impossible.
(And FWIW, the original problem still exists: the redirect in the template skips the header at the top of Commons:Naming_categories. And this is very bad style. The warning is there for a purpose, not to be deliberately hidden.) Dysmorodrepanis (talk) 20:02, 4 May 2011 (UTC)[reply]
Hello Dysmorodrepanis. Hi agree with most that you say above, but not with that 200 threshold, nor even with 100. It is much more practical to sort files in daughter categories if they are organized in subgroups. Have a look at Category:Horses in heraldry which I organized yesterday or so, using two metacats. I agree that they were not that necessary right now, especially the country ones, but it eases categorization, especially when the number of daughtercats is expected to increase steadily, with horses by tincture, demi-horses, horses by theme, horses by emblazonment, etc. Possibly there will be no need to create more metcats for some time now, but the ones I created, especially "horses by attitude", I believe they are useful since they can be grouped with similar metacats in a parent metacat, as I have done with horses by attitude and lions by attitude, allowing for the comparison of different treatments of animal attitudes in heraldry according to the animal. As for the "by country" cat, an IP had the most unfortunate idea of creating 3 country cats which right now only serve to disperse content, and I thought that placing them on the same level as the "attitude" ones would refrain users to place files there randomly. In anycase, those "by country" cats are expected to increase in the future, if someone gets interested in classifying the horses that way (I must say that I greatly dislike it on first sight, due to the dispersion factor).
In any case, using 200 as threshold is a number far too large. It makes categorization (pigeonholing, if you like) quite tiresome, having to pick something from dozens of subcats which are not logically grouped.--- Darwin Ahoy! 20:34, 4 May 2011 (UTC)[reply]
Yes, but categories are not created for ease of categorization (for us editors), but for ease of browsing (for the users). This is the main problem. Furthermore, in your example, if one wants to down-categorize an image in Category:Horses in heraldry, one first has to look up whether the appropriate daughter category exists. This is naturally more complicated if the daughter categories are "one metacategory apart", particularly if (as here) both sets of dauther categories may apply. So, my approach here would have been to use "|*" piping for "crest"/"supporters"/"by attitude", but use "| " piping for the country cats instead of a metacategory, until there are far more country cats.
In a nutshell, use piping until the group created thus gets too large, then take the group and put it in a metacat. I have seen "| ", "|*" and "|+" being used for piping; they will collect as a group at the start of the subcategory list. However, "|!" is generally used to denote "needs attention" (e.g. unidentifieds) and there are some others which have a sort of fixed usage (like "|†" for extinct organisms and "|×" for plant hybrids).
("Pigeonholing" is a term referring to categorization errors by overly rigid application of a category structure, which is precisely the problem the present approach invites.) Dysmorodrepanis (talk) 23:35, 4 May 2011 (UTC)[reply]
E.g. File:HUN Balatonszentgyörgy COA.jpg has no country category yet, but this is not obvious from "Horses in heraldry"; it needs to be looked up and this takes time, which is annoying if one wants to categorize a large and diverse amount of content. Note Category:Saint_George_in_heraldry - certainly it won't be a problem if you categorize all the content of St. George mounted, but if some other editor does this, s/he will have an increased workload. (Ultimately though, we may find the two metacats to be justified when all the "St. George mounted" content is in "Horses in heraldry". But we can only really tell when this is done.) Dysmorodrepanis (talk) 23:48, 4 May 2011 (UTC)[reply]
I use categories both for categorization and for looking up, especially for looking up, indeed, so I try to organize them in a manner that would be practical to find the content I want. Of course I do this according to my knowledge and needs, therefore it probably has some faults, which I try to correct over the time (occasionally eliminating metacats which are not justified, indeed). About the File:HUN Balatonszentgyörgy COA.jpg, yes, it has no country category, and thanks God it hasn't. The worst thing that can happen to those categories is to bury the items in some meaningless categories such as "Horses of heraldry of Hungary", making it a torment to properly classify them afterwards. In the case of that CoA the most important classifications are those that objectively describe the CoA (St George killing the dragon, with the appropriate tinctures, not yet there) and a category for the CoA actual function, which is already there (COA of municipalities of Hungary). Everything else is non essential categorization, and if inappropriately used (bury down the thing in "horses in heraldry of Hungary", for instance) can greatly hinder that work, and serves very little purpose.--- Darwin Ahoy! 03:20, 5 May 2011 (UTC)[reply]

(reset indent) While I generally agree with the problem of complex "x by y by z" categories and the many unnecessary meta cats, I do not agree with principles that one has to wait till one has 200 categories before creating a meta category; sometimes, one knows what is going to come and sometimes it is better to maintain a symmetric, predictable structure. But some people seem indeed to enjoy to create new category structures, categorise 3 or 4 items in it and leave the rest for the others.

Some problems are related to categorisation which goes too deep (for example down to river per city), which forces then to add besides the "main" category, one or more "side" categories (Both concepts are missing badly on Commons). For example, Category:Rivers of France is completely unmaintainable. I made already a crusade against unnecessary "x by name" categories, but never got support. Many of them are just not maintained, precisely because they are side categories (rivers, lakes, ... by name) and basically, nobody needs them. A recent example of such a unnecessary "side" category is Category:Zoos in the United Kingdom by name, while the main category is now mainly empty. --Foroa (talk) 06:45, 5 May 2011 (UTC) Another example: Category:Art by period: there are still many new permutations possible...[reply]

"Zoos in the United Kingdom by name" is a good example of things that shouldn't happen. But it is quickly made and takes a long time to unmake. Thus the changes I proposed; otherwise the "bad" metacategories will eventually outnumber the "good" ones. Dysmorodrepanis (talk) 11:14, 5 May 2011 (UTC)[reply]

I think that many people want to have meta categories because they think that people will leave no images in it, so it will force better categorisation. Just like people think that when adding diffuse , crowded, overpopulated, ... templates in it, that people will do a better categorisation job. As if that will change something. --Foroa (talk) 07:13, 5 May 2011 (UTC)[reply]

And all the time you get things like Category:Animals of Scotland by location (which I have tagged for merge back). The editor who created it could have put all the horse and sheep categories into "Mammals" where they belong, but no; I had to do this now while s/he created a metacategory instead of cleaning up first. This is precisely what I mean: instead of category cleanup, additional categories are spawned with no real reason. (I found this while looking for categories for File:Apamea monoglypha larva from Beith, Ayrshire, Scotland.JPG; it is really annoying if one has to sift through layer after layer, to decide at which level one has to add the "Insects of..." or whatnot.
To categorize content now is much harder, as one must go to the metacat to look up whether the geographic location already exists. If these locations were all on the main cat (sorted alphabetically), categorizing the content would be much faster and it would be more obvious that the content needs to and can be categorized even if neither mammal nor bird, because you would actually see them there. And that's the big problem - metacategories hide away subcategories. This is good when there are too many of them, but we have the metacat and 2+2 other subcategories, so the metacat content could easily be the "body" (alphabetical) content of the main cat. Dysmorodrepanis (talk) 21:31, 5 May 2011 (UTC)[reply]

Public Domain in Spain requires attribution?

Hello, I was checking the Spanish copyright legislation, and got intrigued by article 41, which says: "Las obras de dominio público podrán ser utilizadas por cualquiera, siempre que se respete la autoría y la integridad de la obra, en los términos previstos en los apartados 3. y 4. del artículo 14." , "Public domain works may be used by anyone, given that the authorship and integrity of the work is respected, in the terms stated in items 3 and 4 of article 14" (Article 14 is about moral rights). Is this important enough that something such as "PD-old-Spain" should be created to require attribution and the additional provisions, or can it be neglected entirely, since the servers are in Florida? --- Darwin Ahoy! 12:29, 4 May 2011 (UTC)[reply]

According to article 14 of the Royal Legislative Decree 1/1996 the recognition right is un-resignable, moreover, it's an imperative; so in case you know the author you must attribute it. According to article 133 and 134 the author, appart from the civil and criminal actions he's entitled to use, he can request the cease of the system used for the publication, the destruction of the files and so on. --Dferg (talk) 13:27, 4 May 2011 (UTC)[reply]
There are similar provisions in the copyright laws of most countries, particularly in Europe. According to Commons' policies, the source and author must always be provided whenever possible, regardless of local laws. It is generally understood that such attribution requirements do not prohibit use of anonymously published public domain works. —LX (talk, contribs) 13:59, 4 May 2011 (UTC)[reply]
Yes, the US has no such requirement, but in many other nations (e.g. Spain, France) the right to attribution is inalienable and cannot be lost or surrendered by any means. Dcoetzee (talk) 21:24, 5 May 2011 (UTC)[reply]
Yes, these are called "moral rights" and are separate from the "economic rights" that our licenses deal with. Many (most even) countries have them. These rights don't explicitly exist in the U.S., at least in most cases (Congress dabbled with them for a narrowly-defined set of "works of visual arts"). In general, violating moral rights is not at all the same thing as violating the economic right; there are usually very different penalties and lots of ways to fix them. With the attribution clauses of the CC licenses etc., missing attribution is actually committing full-blown copyright infringement of the economic rights, as the works are basically being copied without permission. People should know the law in their own country and follow it, regardless if it says "PD" on Commons. This is also why it's a very good reason to document all authorship details etc. as much as possible, including on PD works. Carl Lindberg (talk) 21:33, 5 May 2011 (UTC)[reply]

Problem with image previews

There seems to be a problem with image previews on some images, like File:Fresco chehel sotoun 27.jpg and File:Fresco chehel sotoun 2.jpg. Full resolution is OK, but preview is barred with black lines. Anybody sees the same ? I'm currently viewing from mozilla. Fabienkhan (talk) 00:05, 6 May 2011 (UTC)[reply]

I get a red X with Internet Explorer for thumbnail and full size. – Adrignola talk 00:51, 6 May 2011 (UTC)[reply]
Its not a Browser problem, its Commons (Mediawiki). But I see too IE(8) cant render this JPEGs. Im also not a expert, but I see this JPGs have no ColorSpace (32bit instead of 16bit?) and a "CMYK" compression!? -- Perhelion (talk) 01:05, 6 May 2011 (UTC)[reply]
Yes, it uses the CMYK system, which Commons cannot render properly. I can convert it to a usable format, but due to differences between systems, the colour palette changes dramatically, resulting in unnaturally bright and vibrant colours. If someone knows of a way to preserve colours between CMYK and RGB, please do so, and this image might be saved. It's a very nice piece. — Huntster (t @ c) 04:55, 6 May 2011 (UTC)[reply]
I have uploaded a new version of File:Fresco chehel sotoun 2.jpg, the black lines are now gone. Opened in Gimp and saved with minimal metadata - no changes to color profile (unless Gimp automatically set one). To reduce generational loss I set Gimp jpeg settings to high quality, hence the larger file size. If this version is acceptable, I will also convert the second file. MKFI (talk) 17:42, 6 May 2011 (UTC)[reply]
Yes MKFI, that's perfect, please do the same with the other image. I don't know why I wasn't able to get GIMP to do the same. — Huntster (t @ c) 04:08, 7 May 2011 (UTC)[reply]
I have uploaded a new version of File:Fresco chehel sotoun 27.jpg stripped of Photoshop metadata. MKFI (talk) 07:46, 7 May 2011 (UTC)[reply]

{{Attribution}}

This template isn't deprecated, is it? And if so, what should be done with images on other wikis with this license? I've been transferring files under this license from enwiki, and User:Nikbot has been tagging them as lacking license information. —innotata 01:26, 6 May 2011 (UTC)[reply]

Probably {{Copyrighted free use provided that|Attribution:}} and do not delete {{Attribution}}. -- RE rillke questions? 07:14, 6 May 2011 (UTC)[reply]
Why not simply use {{attribution|text=image credit}}? – Adrignola talk 12:08, 6 May 2011 (UTC)[reply]
Specific attributions were not explicitly specified on enwiki. It looks like simply {{Attribution}} works: and it's what shows up with {{Copyrighted free use provided that}}. —innotata 15:12, 6 May 2011 (UTC)[reply]
Categories are not included with redirects? {{CopyrightedFreeUseProvided}} is a redirect to {{Attribution}}. But the problem is that it does not categorize in "License tags attribution". Nikbot tags files dependent on the categories. -- RE rillke questions? 16:37, 6 May 2011 (UTC)[reply]
Nikbot just needs to add Category:Copyrighted usable (and subcategories) to it's license category list. Kaldari (talk) 21:30, 6 May 2011 (UTC)[reply]

{{PD-Libya}}

Should I use this template for pictures published in the 30's in Libya (at that time en:Italian Libya)?--Kimdime (talk) 12:17, 6 May 2011 (UTC)[reply]

Relicensing on Flickr

A while ago I uploaded two photos from Flickr (1 and 2). However I have now noticed the original author of the work has relicensed it preventing it from being used commercially. I'm assuming it's still alright for these images to stay on Commons? If so should I add anything to the file page to let possible re-users know? Thanks, Editor5807speak 18:19, 6 May 2011 (UTC)[reply]

Your uploads are fine User:Flickr upload bot/upload certifies that the license was correct at the time of upload. --Jarekt (talk) 18:25, 6 May 2011 (UTC)[reply]
By the way shall we move template User:Flickr upload bot/upload to template namespace? This is not a correct place for a template. --Jarekt (talk) 18:31, 6 May 2011 (UTC)[reply]
You can also add {{Flickr-change-of-license}} to files if you would like something extra to assure reusers when this happens. – Adrignola talk 18:42, 6 May 2011 (UTC)[reply]
OK thanks for that, I thought they would probably be safe. I'll use the template if I notice it again. Editor5807speak 00:19, 7 May 2011 (UTC)[reply]

Need to get files back

Can we get these files back:

They were deleted because no source was given, but the source for all of them is NASA, which makes them in the public domain. Bubba73 (talk) 23:14, 6 May 2011 (UTC)[reply]

 Not done. They were all transferred from en.wikipedia and had PD-USGov-NASA tags on them, but they had no actual source for the files to prove they were created by NASA (and not a third party photo that was shown on NASA's website). Wikipedia is not a source. – Adrignola talk 00:45, 7 May 2011 (UTC)[reply]
I can get that information if I have the files back. I have CDs with those photos on them, so I can get the NASA photo number and link that to the photo on a NASA website. I can do that if I have those files back, but I can't do it without them because I don't know what the Passive Seismic Experiment (for example) looks like. I can fix the source if the files are back. Bubba73 (talk) 02:16, 7 May 2011 (UTC)[reply]
And, by the way, what "third party" was on the Moon to take the photos, other than NASA? (If they are photos and not drawings - I don't remember) Bubba73 (talk) 02:18, 7 May 2011 (UTC)[reply]
Okay, restored. Rehman 02:59, 7 May 2011 (UTC)[reply]
Thanks. So far I've found some very similar ones in the NASA images, but not those exact ones. I need more time to look. Bubba73 (talk) 04:29, 7 May 2011 (UTC)[reply]
These are taken from an Apollo program manual...I recognise the font type and styling...but I don't know which one. Certainly NASA, in my opinion. — Huntster (t @ c) 05:56, 7 May 2011 (UTC)[reply]
Aha, at least some of these images, or re-labelled versions of them, come from Apollo 17 Mission Report (JSC-07904). I'll add sources for those I can find. Note that other Apollo mission reports are at http://www.hq.nasa.gov/alsj/alsj-mrs.html. — Huntster (t @ c) 06:39, 7 May 2011 (UTC)[reply]
Thanks. I've been going through my Apollo Lunar Surface Journal discs looking for them. I found some very similar ones, but not those exact ones. Bubba73 (talk) 15:05, 7 May 2011 (UTC)[reply]
At least some of them seem to be from the appendix of the Apollo 17 Mission Report by NASA. Bubba73 (talk) 15:17, 7 May 2011 (UTC)[reply]
Yes I've added the source with pages, but only 3. The one image is very similar so the source of NASA is more than likely. In A16 I found no image. -- Perhelion (talk) 15:30, 7 May 2011 (UTC)[reply]
I think we can find all images at NASA. The images in the PDFs have also much higher resolution. I've exported 2 (with Inkscape) they have also lower size because they are real monospace images File:Active_Seismic_Experiment_Thumper.png(old) and File:ALSEP RTG ALSEP.png(old) Can anyone replace them? -- Perhelion (talk) 17:15, 7 May 2011 (UTC)[reply]

May 7

UploadWizard as default uploader is coming

Hi,

(cross-posted to commons-l)

We’re planning to make a change on May 9, 2011 [1]: We’ll replace the link in the Wikimedia Commons sidebar that currently points to Commons:Upload with a link to Special:UploadWizard (in all languages). If all goes well, we'll also invite Wikimedia wikis to begin changing upload links that currently point to Commons:Upload or Special:Upload to Special:UploadWizard.

If you haven't tried the UploadWizard yet, go to Special:UploadWizard to test it.

We’ve a made it easier to get back to the old form from Special:UploadWizard, and added an invitation to help with localization.

NOTE: We still need lots of additional translations, so if you can help with that, please do so on translatewiki.net.

Sign up for translatewiki:

Translation group:

Current status:

The quality, status and up-to-dateness of translations of the old upload form is very mixed. By switching all languages immediately to UploadWizard and working with translatewiki.net, we're hoping to accelerate the process of getting solid localizations across the board. We apologize for the short term inconvenience this may cause. [2]

The old upload process will remain indefinitely available. There’s no reason to remove it. This is purely a change to the default process we’re exposing to the world. We feel we’ve fixed all the obvious bugs that we know about (there are some annoying bugs that we do know about left, but they’re not showstoppers). The best way for us to find the remaining bugs is to have people actually use it as their first upload experience and to continue to receive and process feedback.

As a reminder, here’s what UploadWizard gets us:

  • Up to 10 files can be uploaded in one batch. We are hoping to expand this feature set to allow for parallel uploading, multi-file selection, and more.
  • Some metadata is automatically extracted and pre-filled.
  • You can see thumbnails before you’re completing your upload.
  • Error cases should be handled in a clear and understandable interface.
  • Less clutter due to systematic learning design as opposed to mixing instructions and process.
  • Much, much friendlier to new users as validated by our usability studies.

Major remaining gotchas:

  • If your entire upload takes longer than 25 minutes, it fails. Very annoying, we know. Not entirely trivial to fix but we know how and we’ll get to it soon.
  • Thumbnails for some file formats (video and audio, for instance) are not shown during the upload process. This should not affect the success of the actual upload.
  • Right-to-left support is far from perfect and consistent. Suggestions for improvement are most welcome. If you speak an RTL language, please hammer the wizard and tell us is if it's a showstopper issue for you -- we don't think that's the case, but we need your input.
  • There are a number of other known cases where uploads will stall and the user has no option to fix the problem. It happens much less often than it does with the old upload form, and we believe the most important bugs (e.g. title blacklist related failures) will be squashed as part of this release. There is a link to provide feedback right in the subtitle of the page – if you do have a problem, please report as much detail as possible!

How do we know the new process is much improved? Through qualitative studies of the upload interface. See the report on the multimedia usability project for details and videos:

http://meta.wikimedia.org/wiki/Multimedia_usability_project_report

We’re also continually user-testing the software through quick and cheap user-tests using usertesting.com -- we’ll share our first batch of test videos soon.

Please continue to add your thoughts & comments to the feedback page, and we’ll aim to respond in a speedy fashion.

I'm very excited about this change and I hope you are, too. :-) We've received an overwhelming amount of positive feedback regarding the UploadWizard experience, and while there are still lots of ways in which we can do better, we hope you'll agree that it's a huge step forward.

All best, Erik Moeller 03:21, 7 May 2011 (UTC)[reply]

Notes

[1] We may choose to push the date forward a bit if we run into deployment issues.

[2] There's a subheader in the UploadWizard which takes you back to the old upload form. To ensure that at least the link to the old form is translated into your language (if you're an administrator or can find one), you can edit the following user interface message in your language (add "/language code" to the URL, e.g. "/pl" for Polish):

http://commons.wikimedia.org/wiki/MediaWiki:Mwe-upwiz-subhead-alt-upload

Great to see the new upload wizard go live! Multichill (talk) 11:21, 7 May 2011 (UTC)[reply]
What about those who use the current upload form and the basic upload form (IE: Will both stay? Will it be linked on the Upload file ect)? Bidgee (talk) 12:05, 7 May 2011 (UTC)[reply]
I would like to see the current bugs fixed first. Are they (e.g. browser's back button handling)? And please provide an easy(!) way (... maybe a link on top: "please use the old form as standard for me") for non-newbies to switch permanently (until revocation) back to the current standard form. Cheers --Saibo (Δ) 01:09, 8 May 2011 (UTC)[reply]

Continued at section → #Switch_to_UploadWizard. --Saibo (Δ) 02:42, 12 May 2011 (UTC)[reply]

Requesting help from specialists on astronomy

What's that exactly?

Hi everybody, I've found some nice Flickr pictures of one of the least well known of all really interesting science museums in the world, see Category:Crypte aux étoiles. But being the amateur I am, i find it hard to categorize some items otherwise than very generally. Could somebody help out with a bit of specific knowledge? Thank you very much. --Edelseider (talk) 12:37, 7 May 2011 (UTC)[reply]

First step done: Added identification / info sources for File:Planetarium_(1).jpg. To be extracted and categorized. Cheers --Saibo (Δ) 02:42, 8 May 2011 (UTC)[reply]
Second step done: this http://commons.wikimedia.org/wiki/File:Planetarium_%2811%29.jpg is this: http://cortrie.de/uhren-und-schmuckauktion/index.php/lose/incategory/taschenuhren/4512 --AtelierMonpli (talk) 11:57, 8 May 2011 (UTC)[reply]
Third step: http://commons.wikimedia.org/wiki/File:Planetarium_%282%29.jpg it's a flame photometer from 1937, a heliostat and a polarimeter, for more information enlarge the pic to 1600 x 1200 pixel and read the text. (cannot translate)--AtelierMonpli (talk) 12:33, 8 May 2011 (UTC)[reply]
4.step:http://commons.wikimedia.org/wiki/File:Planetarium_%288%29.jpg this thing is called theodolite (Winkelmessgerät - Vermessungstechnik?)--AtelierMonpli (talk) 14:44, 8 May 2011 (UTC)[reply]
 Question Are those pictures under the correct license. Just because on FLICKR they are CC does not necessarily means that they are really CC. --Yikrazuul (talk) 12:41, 8 May 2011 (UTC)[reply]
I see no issues here: @photo: the person seems to have visited Strassbourg (EP and museum using the same cam according to EXIF) and @works shown: they are probably quite old and/or nothing copyrighted. The map (first file) is from a person who died 1665. ;-) Did you mean anything in particular? Cheers --Saibo (Δ) 00:31, 9 May 2011 (UTC)[reply]
Thank you everybody so far. @AtelierMonpli : about the third step, I got that right, of course. It's the other instruments I am was not sure of. Cheers, --Edelseider (talk) 05:55, 9 May 2011 (UTC)[reply]

The other ways images can enter the public domain...

I just uploaded an image from flickr's small commons section.

Flinfo applied a {{Flickr-no known copyright restrictions}} liscense tag. That tag, when instantiated, lists four possible reasons why the tag applies, including: "The copyright was injected into the public domain for other reasons, such as failure to adhere to required formalities or conditions;"

I have always suspected that there are images where we are too careful. For instance, when a grieving family member hands out family photos to random reporters, without taking their names, or imposing conditions, I have always wondered why those images shouldn't be considered to have been placed in the public domain. Other contributors here have insisted we would still require an OTRS ticket when an image is widely republished after they handout out copies to random photographers, without imposing conditions.

I agree when a private individual gives another private individual a copy of an image they made, they retain all the IP rights.

I've been told that when PR types prepare a package to give away during a press conference they typically try to impose conditions on how the information they released is used. In particular, I have been told by other contributors here, that images handed out at press conferences will have conditions stated about their re-use.

What if those PR types forget to state their conditions on how the images in the press release can be re-used?

I know IP rights can be lost when the rights holder is reckless or careless. To what extent can we take this into account when determining if do require an OTRS ticket?

Cheers! Geo Swan (talk) 13:05, 7 May 2011 (UTC)[reply]

As an OTRS volunteer I must still keep in mind Commons:Project scope/Precautionary principle. Regarding the grieving family member handing out photos, that's a case of thinking that "the copyright owner will not mind/should be pleased that we have disseminated his/her work."
As for rights holders being reckless or careless, well that's what the OTRS volunteers are for. Sometimes people get annoyed and think we're just being bureaucratic when we ask for specifics. No, we're actually looking out for them. – Adrignola talk 14:47, 7 May 2011 (UTC)[reply]
If I'm not mistaken, that clause applies to US failure pre-1989 to include a copyright notice, or failure pre-1989 to renew a work after 28 years. There is virtually no way a copyright holder can lose their copyright by being reckless or careless; in the EU, there are rights a copyright holder can't surrender by contract or any force short of an act of law.--Prosfilaes (talk) 16:57, 7 May 2011 (UTC)[reply]
As Prosfilaes stated, the "required formalities" referred to by {{Flickr-no known copyright restrictions}} are earlier U.S. requirements for copyright notices and renewal registration. Under current copyright laws, no formalities are required for copyright protection. Family photos and PR photos used by the press are typically handed out with the understanding that they will be used in a relevant context according to fair use; see Commons:Image casebook#Press photos. Distributing a work does not place it into the public domain. Requiring an explicit permission statement for such photos is not being "too careful." If no conditions are stipulated, the photograph is still fully protected by copyright. There are some so-called "intellectual property rights" (a misnomer, since it doesn't deal with property), such as trademark rights, that can be lost if they are not enforced. Copyright is not one of those rights. —LX (talk, contribs) 18:15, 7 May 2011 (UTC)[reply]

Watchlist help

Is there any way to restore my watchlist to its state of 24hrs ago? I tried to edit it, but since it contained 30,000 items it just timed out and now I'm down below 10k. -mattbuck (Talk) 13:33, 7 May 2011 (UTC)[reply]

Quick, now you can edit all the british railway images without mattbuck noticing! --- sorry, I can't help... Amada44  talk to me 17:31, 7 May 2011 (UTC)[reply]
did you try to edit raw watchlist?? it should load faster.   ■ MMXX  talk  17:56, 7 May 2011 (UTC)[reply]
That was what I did. I tried to re-add stuff, but when you click save it times out after a couple of thousand entries. -mattbuck (Talk) 18:59, 7 May 2011 (UTC)[reply]
How many items did you try to add? see this.   ■ MMXX  talk  19:10, 7 May 2011 (UTC)[reply]
You had how many files on your watchlist? :o — Cheers, JackLee –talk– 17:16, 8 May 2011 (UTC)[reply]

Template:PD-UKGov

Currently this template categorizes files into Category:UK Government images, but it also designates that the tag can be applied to "artistics works" created via Crown copyright. Do sound recordings fall under the classification of "artistic works" and, if so, should the category be renamed, possibly to something like Category:UK Government artistic works? P.S. I'm also having a bit of trouble determining the copyright of a recent file I've uploaded, which is somewhat related to this issue, at File:Winston Churchill - Be Ye Men of Valour.ogg. :| TelCoNaSpVe :| 23:56, 7 May 2011 (UTC)[reply]

Yes, it applies to all kinds of works. I would use PD-UKGov for that one, I think, which would cover the underlying speech. The sound recording itself... yuck, as those are messy in the U.S., but it would not have been restored by the URAA, I don't think, as that recording was PD in the UK in 1996. I'm not sure if BBC stuff is crown copyright, or just a normal copyright, but it probably doesn't matter much for sound recordings are the terms are pretty much the same. They have changed the rules a couple of times, and is a bit tangled to follow, but it appears to be 50 years from first publication, or 50 years from first broadcast, provided that publication or broadcast happens in the 50 years after it's made. However I think recordings made before 1957 continue to have their term based solely on when it was made, and not published etc. (per here). I'm not sure we have a specific tag for UK (or EU) sound recordings, but the terms are different than the usual 70 pma stuff. Carl Lindberg (talk) 04:59, 8 May 2011 (UTC)[reply]
But the URAA only applies to federal copyright; early sound recordings are all under state copyright. Capital v. Naxos is explicitly about this case, where sound recordings fell into the PD in the UK in 1990, but a New York court ruled they were still under copyright in NY.--Prosfilaes (talk) 17:09, 8 May 2011 (UTC)[reply]
Good point. Any idea what the situation is under Florida law? (I presume that's the only state that matters to us.) --Avenue (talk) 03:53, 11 May 2011 (UTC)[reply]
I believe last time I checked, Florida had a blanket law with no time limits.--Prosfilaes (talk) 05:10, 11 May 2011 (UTC)[reply]
Florida Statutes 540.11.--Prosfilaes (talk) 05:25, 11 May 2011 (UTC)[reply]
Thanks, that's good to know. --Avenue (talk) 08:52, 11 May 2011 (UTC)[reply]
One thing -- the URAA did claim to restore copyrights in pre-1972 sound recordings (17 USC 104a(h)(6)(c)(ii)). If they didn't, yes, due to the general messiness of US sound recordings, non-restored works may still have state copyright. We do take PD-UKGov to expire worldwide (URAA or not), but if it's a private copyright, then possibly. On the other hand, unless it has commercial value, not sure that state copyright would protect it. We truly do need to use common sense with those I think. Carl Lindberg (talk) 04:22, 11 May 2011 (UTC)[reply]
I think the URAA only applies to certain pre-1972 sound recordings. In particular, the clause you cite does not apply to recordings whose copyright has expired in its source country, due to the preceding clause (17 USC 104a(h)(6)(b)). So it would still be under state copyright. Florida's Statute 540.11 says nothing specifically about commercial value, although it mostly prohibits commercial acts. I think this makes such recordings non-free (but IANAL). --Avenue (talk) 08:52, 11 May 2011 (UTC)[reply]

May 8

Convert to JPEG

We have many convert to x templates, but we don't have a Template:Convert to JPEG. I've haven't run across many images where it is needed, but maybe others have. Today I saw File:D.tiff and thought that image would be better as a JPEG because it is a low-resolution image, provenance doesn't appear to be important for that image, and tiff is not as accessible. John Vandenberg (chat) 04:44, 8 May 2011 (UTC)[reply]

  • It's already converted to JPEG by MediaWiki software -- Right Click on the thumbnail and you can use JPEG as you wish. On the same time manual conversion of lossless formats to lossy is hardly a good idea. Trycatch (talk) 05:12, 8 May 2011 (UTC)[reply]
    • I agree that conversions from w:TIFF need care. Not all tiff files are lossless, as it is a container format that can contain either (including jpeg compression). In the case of File:D.tiff, it is losslessly compressed, however the conversion to JPG doesn't need to have any significant loss, and JPEG is good enough for photos of a person. Someone *could* do a poor quality conversion depending on what level of JPG compression they enabled.
      Consider File:Blondel.tiff. It is uncompressed 928 × 666. Mediawiki gives a preview of 800px × 574px. People like you and I know we can obtain a lossy jpg version by going to a different URL [1] (100.04 KB) but the average user doesnt know that. I would assume that this URL is not lossy, however it is also 100.04 KB. this 'png' is also the same lossy JPG. To obtain a lossless image, I need to ask for this (526 KB) However, it is a (Maybe the "Download" gadget can help by recognising TIFF and giving a 'Full resolution lossy' and 'Full resolution lossless' option.) John Vandenberg (chat) 13:39, 8 May 2011 (UTC)[reply]

Special:Import

So, I have a silly question, probably been brought up a million times. Why don't we enable Special:Import on Commons, seeing as it's enabled on multiple other projects. This would make moving images from those projects a lot easier. Magog the Ogre (talk) 06:54, 8 May 2011 (UTC)[reply]

It's enabled, I did some tries ages ago. If I remember correctly it only imports the text so the steps I had to take:
  • Import file page
  • Transfer the file
  • Overwrite the description with a description suitable for Commons
It wasn't really worth the effort. Multichill (talk) 10:43, 8 May 2011 (UTC)[reply]
One major issue is mapping local templates to Commons templates. Our existing tools (like Commons Helper typically do this (with mixed success) through hardcoded rules. —LX (talk, contribs) 15:57, 9 May 2011 (UTC)[reply]
See File:Kenley Station.JPG for an example import. Multichill (talk) 20:00, 9 May 2011 (UTC)[reply]

old interface translations

Do we need all these old interface translation messages that are identical to the translated message

John Vandenberg (chat) 14:57, 8 May 2011 (UTC)[reply]

All Dutch or also other languages? If a message is the same as the default one than the message can be deleted. I think I have a simple script to do this (just loop over all MediaWiki messages, compare the content with Translatewiki, if it's exactly the same, delete the message). Multichill (talk) 15:29, 8 May 2011 (UTC)[reply]
See also betawiki:Thread:Support/Messages customization statistics. --Purodha Blissenbach (talk) 20:23, 8 May 2011 (UTC)[reply]

I've deleted most of them.[2] I am unable to delete watch/* and unwatch/*. Of those, only mediawiki:unwatch/el should not be deleted, as it is also customised on el.wp. I've raised bugzilla:28889 --John Vandenberg (chat) 02:37, 9 May 2011 (UTC)[reply]

exif descriptions

On bugzilla:28625, it has been pointed out that our metadata section contains labels that are terms which the average user wont understand. I think we should link these descriptions to Wikipedia articles or local help pages. e.g. MediaWiki:Exif-fnumber, which can be seen at File:Tapir anta 1.jpg. John Vandenberg (chat) 15:03, 8 May 2011 (UTC)[reply]

Good idea. Maybe create a page like Help:Exif with descriptions of all possible fields? Multichill (talk) 15:32, 8 May 2011 (UTC)[reply]
Sounds good. Here is an overview: Special:AllMessages&prefix=Exif-. --  Docu  at 15:40, 8 May 2011 (UTC)[reply]
For not so few of those fields and their possible values, there are normative or quasi normitve web pages describing them pretty good an detailed. Some are even available in several languages. See bugzilla:28625 for links to samples, and to links to message documentation linking to those pages. --Purodha Blissenbach (talk) 20:17, 8 May 2011 (UTC)[reply]
Two comments. How do you plan to keen commons links up-to-date with en-wiki content? Looks stable today, may change tomorrow (I wouldn't even think of interwiki mess with yet-emerging wikis). Look at the links to camera models. Some articles never existed (and never will), others existed once and where then deleted or redirected to articles about their manufacturers example. Second. I doubt that wikipedia will ever have meaningful content on most arcane exif entries. What is "maximum land aperture"? Why did "flash did not fire" if the camera has no flash at all? Why is "Light source: Unknown"? Why does it say "Auto white balance" if the pic was processed from raw file, etc. This stuff will stay unanswered. NVO (talk) 22:52, 8 May 2011 (UTC)[reply]
Since it would be help about mediawiki software, and not necessarily an encyclopedia, I think it would make more sense to put it in the help namespace of mediawiki wiki (and only link when there is such a page). We could have a new message, like say mediawiki:exifhelp-whatever, which contains a url to mediawiki wiki, if such a help page exists, could have say a - to disable, and different languages would link to translated versions if available. Bawolff (talk) 02:24, 9 May 2011 (UTC)[reply]
I like the idea of putting the documentation in the mediawiki help namespace, which is public domain. Those help pages could be included in the default install in future. I've created MediaWiki:Metadata-help with a link to Commons:EXIF. John Vandenberg (chat) 02:58, 9 May 2011 (UTC)[reply]

Date differentiation

I have modified the template {{Author}} so that it could support the parameters original and photo, enabling easy multilingual description of more authors (even more parameters would be useful – crop, purification etc. – but I do not know how to add them without making the template too “heavy”, what regards the condition parser functions, well also now they are too many). See its use with a simple parameter and with the {{tl|Creator}} template.

Do you think using similar parameters in a template for date would be useful as well?

--Petrus Adamus (talk) 18:57, 8 May 2011 (UTC)[reply]

I'm getting increasingly concerned with all the complicated template constructs build in the last couple of months. It looks to me like we're trying to implement things for which MediaWiki is not build. Multichill (talk) 19:19, 8 May 2011 (UTC)[reply]
The constructs are so complicated, because no variables can be used. I do not know how to describe files multilingually in another way, a simple indication like {{photo}}: Name or Name ({{photo}}) are probably not usable for non-latin-alphabet or right-to-left written languages. There is also problem, as many template name, teoretically useful for translations, have already had other usage ({{Original}}, {{Crop}}) etc. Yes, maintaining a multilingual project isn't easy. --Petrus Adamus (talk) 19:37, 8 May 2011 (UTC)[reply]
Multilingual support for #time is checked in and awaiting deployment, BTW. Kaldari (talk) 17:49, 9 May 2011 (UTC)[reply]

White House flickr photos public domain? What about the extra restrictions?

The white house flickr photos all have an extra set of restrictions attached to them: "This official White House photograph is being made available only for publication by news organizations and/or for personal use printing by the subject(s) of the photograph. The photograph may not be manipulated in any way and may not be used in commercial or political materials, advertisements, emails, products, promotions that in any way suggests approval or endorsement of the President, the First Family, or the White House." However, we're calling them public domain. How did that discrepancy get decided? Sancho (talk) 23:04, 8 May 2011 (UTC)[reply]

I wonder whether the extra restrictions were drafted by someone with an understanding of IP issues. Recently all kinds of military commands and diplomatic missions have started to make official photos available via flickr, facebook, etc. Several of the flickr-ids used by these USGov personnel have used liscenses that impose restrictions, or which claim all rights reserved. In some cases, a simple note to the flickr-id results in them changing their liscenses. In other cases those notes are ignored. And, in a few cases, the flickr-id solves the problem by deleting all the images.
If they cant explain where the authorization for these restrictions came from, I think we can safely ignore them.
If the White House press secretary really wanted to impose these restrictions I think they would have to contract out all their photograpy. If J Bloggs photography has the contract to take all official photos, so the actual photographers were employees of J Bloggs, not actually Federal employees, then they could impose those restrictions. However, I doubt they would do that because of the security hole it would open. Geo Swan (talk) 23:48, 8 May 2011 (UTC)[reply]
So, nobody has checked what the actual case is? I was told this was sorted out among Commons contributors, but I can't find the discussion. Sancho (talk) 05:05, 9 May 2011 (UTC)[reply]
Thats Commons:Non-copyright restrictions, we had this in the past. As per Template:PD-USGov or Template:PD-USGov-POTUS its not a copyright restriction. --Martin H. (talk) 10:51, 9 May 2011 (UTC)[reply]
Yes, this has been discussed many times before. The White House photos are public domain and the additional restrictions are bogus. Just ignore them. Kaldari (talk) 17:45, 9 May 2011 (UTC)[reply]

May 9

Procedures voor renaming: Category Old Paris Tramways

This category has two proposals to rename it. These proposals date from 15 february. Moderators probably leave it wel alone and nothing is going to happen. What is the procedures for this kind of rename issue? How can one make a choice? A voting system? The old name is unsatisfactory, but the proposed names are is 100 % either and there maybe a better choice. How do we go from here? Smiley.toerist (talk) 11:29, 9 May 2011 (UTC)[reply]

I guess you are talking about Category:Old Paris Tramways. It has now been deleted and moved to Category:Historical trams in Paris. I'm not sure where any discussion took place; nothing links to either page, and neither of them has a talk page. The standard procedure for proposing a category move is to use {{Move}}, which places the category in Category:Requested moves (all), or to bring it up on Commons:Categories for discussion. Both are heavily backlogged. Weighing options is best done by following existing naming patterns where available, examining the arguments for the different alternatives, and if all else fails: being bold. —LX (talk, contribs) 15:40, 9 May 2011 (UTC)[reply]
There were two different {{Move}} requests outstanding (restored by now), none was discussed. Sorry, but I moved first to the most plausible destination compliant with other categories worldwide. It is easier to discuss/decide moving from an acceptable name to a better one than having to decide about two un-discussed moves. --Foroa (talk) 16:28, 9 May 2011 (UTC)[reply]
Note that the second move request was a request to split the content in two parts. I responded in a bold way because last weeks, with the help of several contributors, we reduced the [:Category:Requested moves (all)]] backlog with nearly 500 items. Problem is that when the backlog decreases, people tend to issue more move requests. --Foroa (talk) 16:37, 9 May 2011 (UTC)[reply]
Nice work! I don't think {{Move}} should be used for making proposals to split content. That's just the sort of thing that builds up the requested moves backlog. Splitting proposals should either be made at COM:CFD with some actual arguments – or just done boldly if the change does not require discussion. —LX (talk, contribs) 16:52, 9 May 2011 (UTC)[reply]

Switch to UploadWizard

The WMF switched the default upload mechanism (for English users) from Commons:Upload to Special:UploadWizard today. Please report issues at Commons:Prototype upload wizard feedback. More info here. If this roll-out goes well, other languages will be switched over as interface translations are completed. Kaldari (talk) 21:53, 9 May 2011 (UTC)[reply]

FYI: If for some reason the sidebar link needs to be changed back, an admin can revert MediaWiki:Upload-url/en to the previous version. Kaldari (talk) 21:58, 9 May 2011 (UTC)[reply]
Note that many users arrive here through links on local projects. I've just updated the link on en:Wikipedia:Upload to point to Special:UploadWizard instead of Commons:Upload. Please help me update similar links on other projects. Dcoetzee (talk) 22:01, 9 May 2011 (UTC)[reply]
Sigh, where's the gadget or preference to make the old form my default like so many other crappy changes you've implemented over the years? -Nard (Hablemonos)(Let's talk) 22:30, 9 May 2011 (UTC)[reply]
@Nard: Use this Javascript in User:Nard the Bard/common.js to make the old upload form the default one linked from the "Upload file" link in the sidebar. Dcoetzee (talk) 03:56, 10 May 2011 (UTC)[reply]
English Wikibooks will not be able to switch to the Upload Wizard without filing a bug report, which will then have someone request to show consensus for the change, followed by several months before it's handled. So it's not going to happen for that project. – Adrignola talk 23:36, 9 May 2011 (UTC)[reply]
Any admin can change the upload form for Wikibooks. Technically, it's not difficult. Kaldari (talk) 17:20, 10 May 2011 (UTC)[reply]
We only allow fair use files through the local Special:Upload. The upload link in the sidebar is manipulated through $wgUploadNavigationUrl in the wiki's settings, which an admin cannot change, and which currently points to Commons:Upload. – Adrignola talk 18:33, 10 May 2011 (UTC)[reply]
Ah, I see. I'm sure once all the kinks are worked out from UploadWizard either $wgUploadNavigationUrl will be changed for all wikis or Commons:Upload will be changed into a redirect. I don't think there's any hurry to change everyone over right now though. Kaldari (talk) 20:27, 10 May 2011 (UTC)[reply]
The link to the real upload form could be bigger and brighter. In fact it could be the only thing there. Well, it could be worse. NVO (talk) 03:38, 10 May 2011 (UTC)[reply]
+1. For now you should go through several tedious steps before you will understand that the new upload form is unusable, because it simply doesn't have a license you need. Trycatch (talk) 04:09, 10 May 2011 (UTC)[reply]
No bull? How did you get there? I'm stuck at "upload" button - I mean, the button is stuck, there seems to be no code attached to it. NVO (talk) 10:53, 10 May 2011 (UTC)[reply]
There is even no link to Creative Commons licenses in the deed, so a novice would have no idea about what kind of license (s)he will sign:

I, ____, the copyright holder of this work, hereby irrevocably grant anyone the right to use this work for any purpose, as long as they credit me and share derivative work under the same terms.

This means you release your work under a Creative Commons Attribution ShareAlike license.

a Creative Commons Attribution ShareAlike license? What does it mean? CC-BY-SA 1.0+2.0+2.5+3.0? And the text above doesn't mean that "you release your work under a Creative Commons Attribution ShareAlike license"! It's a very misguiding statement at least. Trycatch (talk) 04:09, 10 May 2011 (UTC)[reply]
I have to agree with Trycatch here, the statement they sign should explicitly say that they release the work under whatever license, including a link to the CC page. We can then tack on our short laymen's explanation. Otherwise it may not amount to a legal release statement. If enabling the wizard helps catch easily-fixed issues like these then that's a good thing. Dcoetzee (talk) 05:13, 10 May 2011 (UTC)[reply]
Have you guys visited the rest of the internet lately? Like Flickr or Picassa or anywhere? Flickr doesn't even give you an explanation, much less any links. And we honor their licensing just as much as our own. Picassa gives you a brief description, but doesn't even tell you what license you're applying. You don't have to give people pages of legalese just to allow them to relinquish their rights. It's not like we're not twisting people's arms. Regardless, I don't think it would hurt to link to the license. I'll add that. Kaldari (talk) 17:37, 10 May 2011 (UTC)[reply]
Agreed that a link makes sense, opening the license in a pop-up or a new tab. I find the release statement in the wizard actually much clearer than anything in the old form, which is a huge wall of text (ignored by most users), while the actual license selection is a mysterious dropdown (without links), which is only explained by another huge wall of text if you open the "help" menu. The explicit consent is a much more obvious signal to the user that they are making a choice with consequences.--Eloquence (talk) 18:06, 10 May 2011 (UTC)[reply]
Neither Flickr nor Picasa is a free media archive, neither Flickr nor Picasa has anything to do with free culture/content movement. They can don't care about enforceability of their CC-licenses, it's simply not their problem (to honor Flickr & Picasa their license change menu is actually not so bad comparing to the new one in Upload Wizard). But for Commons free content and copyright are the Alpha and Omega, we routinely deal with things like attempts to revoke a free license, and Commons doesn't have such a luxury as usage of vague copyright deeds with dubious real-life enforceability. Trycatch (talk) 18:43, 10 May 2011 (UTC)[reply]
In that case we should stop automatically honoring Flickr licenses. Kaldari (talk) 18:49, 10 May 2011 (UTC)[reply]
It's not so clearcut, but there are problems with Flickr pictures. E.g. if a flickr-user uses a free license for his pictures and at the same writes in his profile something like "To guys from Wikipedia -- STOP STEALING MY PICTURES!!!" -- there is something wrong somewhere.
Maybe there is some misunderstanding. The only thing I propose to swap the first and the second paragraphs as Dcoetzee said -- "statement they sign should explicitly say that they release the work under whatever license, including a link to the CC page. We can then tack on our short laymen's explanation. " Trycatch (talk) 19:06, 10 May 2011 (UTC)[reply]
I have to disagree. It is more important to us that the user is aware of the meaning of the license and agrees to the general concepts than it is that they "sign" version 3.0 of a legal document that they won't read or understand. We want users to donate their images consciously, not by accident. Making sure that people are actually aware of what they are agreeing to - unrestricted reuse which only requires attribution and retention of the same terms - is more important than how strongly we can "enforce" the CC license against people who didn't want to donate their images in the first place. We're supposed to be promoting the free sharing of knowledge, not hording media against people's will. Most of the world has no idea what "Creative Commons Attribution-Share Alike" means, which is one of the main problems with the old form that we are trying to address with the UploadWizard. Put yourself in the place of someone who has never heard of Creative Commons before. Which wording would be more useful for them? Kaldari (talk) 20:56, 10 May 2011 (UTC)[reply]
And if we slap a CC-BY-SA tag on an image when the user never actually agreed to release the work under the CC-BY-SA but just some super-vague laymen's version of it, we are fraudulently affirming that they signed a contract that they never signed. The details of the license will matter in the event of a legal dispute. Both are important but we can't just add the license name as an afterthought, and we certainly shouldn't claim that our terse laymen's description is an accurate representation of the license in its entirety, which is what the present wording suggests. Dcoetzee (talk) 19:31, 11 May 2011 (UTC)[reply]
If a person doesn't read the text of a deed they sign, it's solely their problem (and IRL it will be solely their problem if they don't read software EULA or insurance contract as well). But if there would be a bad license deed it would be not their problem -- it would be problem of Commons, community of Commons, our reusers and downstream. Minor or non-existing benefits of the current vague deed (it would not be harder at all to read a more explicit version of the very same text) are incomparable with drawbacks of flooding of Commons with hundreds of thousands dubious pictures. Trycatch (talk) 20:11, 11 May 2011 (UTC)[reply]

How can one change the link to the old form for i18n purposes ? It is not among the messages on TranslateWiki (rightly so) and I was unable to locate it in the MediaWiki namespace. Jean-Fred (talk) 08:04, 10 May 2011 (UTC)[reply]

See MediaWiki:Mwe-upwiz-subhead-alt-upload.--Trixt (talk) 08:32, 10 May 2011 (UTC)[reply]
I know about this message. My question was precisely about the variable that is inserted inside this message. Jean-Fred (talk) 11:27, 10 May 2011 (UTC)[reply]
There is currently no way to localize the link itself. I'll file a bug on this. Kaldari (talk) 17:56, 10 May 2011 (UTC)[reply]
Ok, thanks Ryan. Jean-Fred (talk) 18:05, 10 May 2011 (UTC)[reply]

I tried copying and pasting the script mentioned above into "User:Jacklee/commons.js" but it doesn't seem to work for me (and, yes, I did try bypassing the cache a few times). Did I do something wrong? Or is this a problem relating to the sluggish nature of the server that I am currently experiencing? — Cheers, JackLee –talk– 11:51, 10 May 2011 (UTC)[reply]

common.js not commons.js :) Jarry1250 (talk) 22:09, 10 May 2011 (UTC)[reply]

Question. I finally got to "upload form" (thanks to RL advisers - it turned out that "donations" actually mean "next step, stupid!"), uploaded eight files, then stumbled at "description" page. Apparently this thing does not recognize {{CC-BY-SA-3.0}}, or {{Own}}, or {{Information}}, or all of them so I had to abort. After uploading files, after providing two sets of dates and authors for each file, etc. What happened to these files? What happened to pages of text inserted in the forms? They did not show up in Special:NewFiles, but can we be positively sure that they were indeed discarded, and are not preserved in some digital limbo? in the latter case, there's a chance that a file may show up somewhere without proper attributes. NVO (talk) 15:11, 10 May 2011 (UTC)[reply]

If the upload process was abandoned, the files are left in stash and will be cleaned out by normal file system maintenance. There's no chance they will show up on Commons. They're probably already deleted by now. Kaldari (talk) 17:25, 10 May 2011 (UTC)[reply]

Due to unknown site problems, I've had to revert the roll-out of UploadWizard for now. For some reason the Javascript is taking forever to load today. We're working on troubleshooting it currently. Kaldari (talk) 17:25, 10 May 2011 (UTC)[reply]

It looks like there are some networking issues that are causing slowness between the caching servers and the web servers. The ops team is working on it. This is probably affecting more than just UploadWizard. Kaldari (talk) 17:41, 10 May 2011 (UTC)[reply]
And toolserver lags by more than five hours. IMO this is a priority. NVO (talk) 18:51, 10 May 2011 (UTC)[reply]
The WMF doesn't operate the toolserver so it's not in competition for prioritization. Kaldari (talk) 20:22, 10 May 2011 (UTC)[reply]
I had requested an easy and permanent way to get back to the old form already above at #UploadWizard_as_default_uploader_is_coming. Nothing seems to have been done for this. People need to manually insert some code snippet in the skin.js. The current situation is like this for me: Click the upload link, wait 15 seconds until the big image and stuff has loaded and then I can click on the link to take me back. But there is no setting to save this permanently in my settings.
As always: just push forward and do not even respond to questions, huh?
Oh, by the way, it is still switched on for de users: MediaWiki:Upload-url/de; without being mentioned here. --Saibo (Δ) 01:11, 11 May 2011 (UTC)[reply]
User:Eloquence reverted it. Unless there is a option for the user to easily go back to the old form I suggest to modify theupload form in such a way User:Saibo/Sandbox4 if the wizard needs to go live now. Cheers --Saibo (Δ) 02:18, 11 May 2011 (UTC)[reply]

Hello,

a quick summary of where things are:

1) UW is currently disabled to resolve an issue which arose today which causes UploadWizard to not load at all. I've removed changes to the sidebar made by WMF, as well as the sidebar changes by community members in other languages on Commons, and the change on the English Wikipedia. We'll resolve the issue ASAP and then return to the previous state.

2) If you used UW yesterday on Internet Explorer and failed at the "describe" step because UploadWizard wouldn't allow any of your titles to go through, this issue should be fixed with the next deployment. It was caused by a malfunctioning title blacklist detection.

3) If you'd like to use one of the old forms after UW is re-enabled, the easiest thing to do is to bookmark whichever form you prefer (and there are many) -- no need for any custom JS.

Thanks for your patience; today was not a lot of fun due to general site issues, which also delayed resolving the new UW issues surfaced today. We think this first version of UW will already be a huge improvement on the default upload experience (which most new users are completely befuddled by), and there's lots of stuff we hope to be able to do to make it even better, including highly wishlisted items like multi-file selection.--Eloquence (talk) 02:31, 11 May 2011 (UTC)[reply]

ad 3: Suggest people to bookmark (then) hidden URLs should be the solution... Come on. First finish development, then switch it live for all. Why the rush?
By the way: The link "Back to the old form" does not seem to be localized (at least in the German interface). It links to the English Upload form. Cheers --Saibo (Δ) 02:48, 11 May 2011 (UTC)[reply]

May 10

I need Help against upload wizard

The menu upload file opens now only the upload wizard, and does this very slowly. Fotr the basic upload form, I have to return to the old form. This is a very time-consuming path. Can someone help me how to come fast to the basic upload form? --Havang(nl) (talk) 08:38, 10 May 2011 (UTC)[reply]

click here: Special:Upload. TheDJ (talk) 08:45, 10 May 2011 (UTC)[reply]
Perfect, Thanks! The link is on my home page and on my favorites now. --Havang(nl) (talk) 08:56, 10 May 2011 (UTC)[reply]
or you could use the JavaScript pointed out by Dcoetzee above (Switch to UploadWizard section) and pasted it in User:Havang(nl)/common.js. Bidgee (talk) 09:15, 10 May 2011 (UTC)[reply]
But Java-script shouldn't be needed for normal wiki use. --Havang(nl) (talk) 16:11, 10 May 2011 (UTC)[reply]
It's not. If you turn off your Javascript, you'll be sent straight to the old form. Kaldari (talk) 22:45, 10 May 2011 (UTC)[reply]

Why was file:Olav_h_hauge.jpg deleted?

The file was a picture of a sketch by nn:Brukar:Andreasv for use on wikipedia and was given the {{ cc-by-sa }} license. I tried to look for your reasoning by searching for the file name and by looking in the Special:WhatLinksHere/Olav_h_hauge.jpg, but found nothing. The file is now restored at nn:Fil:Olav_H_Hauge2.jpg. -- Hogne (talk) 11:24, 10 May 2011 (UTC)[reply]

The reson is given in the deletion log and the deletion discussion linked there. The drawing is derivative of someone else creative work, a photo. --Martin H. (talk) 11:40, 10 May 2011 (UTC)[reply]
OK, could you give a link to the deletion log? Why isn't it possible to find the log by searching for the file? Hogne (talk) 11:46, 10 May 2011 (UTC)[reply]
On the image page it states "Warning: You are recreating a page that was previously deleted... * (show/hide) 13:53, 26 June 2010 Jameslwoodward (talk | contribs | block) deleted "File:Olav h hauge.jpg" ‎ (Per Commons:Deletion_requests/File:Olav_h_hauge.jpg) (view/restore) (global usage; delinker log)". Click the deletion request link. -mattbuck (Talk) 12:09, 10 May 2011 (UTC)[reply]

{{PD-Libya}}

Should I use this template for pictures published in the 30's in Libya (at that time en:Italian Libya)?--Kimdime (talk) 11:34, 10 May 2011 (UTC)[reply]

Licence at files from WikiSkripta.eu

Since WikiSkripta installed the extension InstantCommons and enabled so direct usage of files from Commons, many of their local files have been moved to Commons, so that also other wikiprojects could use them – e.g. Pneumothorax_001_cs.jpg, during that the licence was preserved, assumably. Afterwards, the original file at WikiSkripta was removed, so that there won't be any duplicates (when the Commons files are linked directly). Consequently, the licence cannot be confirmed in any way (similarly like at the files from Flickr). Also OTRS confirmations wouldn't be usable well, as some pictures have been uploaded to WikiSkripta by users, that had not indicated any contact to them. Do you have any ideas? --Petrus Adamus (talk) 20:33, 10 May 2011 (UTC)[reply]

en:Template:KeepLocal

I just noticed en:Template:KeepLocal used at English and Belorussian Wikipedias requesting for local files not to be deleted after moving them to Commons. See for example File:RalphStover.jpg and en:File:RalphStover.jpg. I assume this reluctance is due to inability to watch you uploads in the wikipedia watchlist. May be we should push for Global cross-wiki watchlists as discussed in Bug 3525 - Cross-wiki watchlists and Proposal:Global_watchlists. In the mean time it meant that more images from commons will be masked by local copies. --Jarekt (talk) 21:05, 10 May 2011 (UTC)[reply]

This template is also used in cases where the copyright status in the source country is unclear, and thus there is a chance that the file will get deleted from Commons at some point. (Since Commons requires a file to be public domain in both the U.S. and the source country, while some wikis only care about the U.S. copyright status). Kaldari (talk) 22:48, 10 May 2011 (UTC)[reply]

May 11

Category:The rule of law

The above category is just a very bad taste joke or is there a reason behind it that escapes me? I'm sorry not to be able to suggest a better place for its subcategories. Vapmachado (talk) 00:16, 11 May 2011 (UTC)[reply]

Those records are all private legal correspondence and psychiatric evaluations going back to 1992 related to legal fights someone has related to his medical pension due to schizophrenia (first noticed in 1977) which was revoked due to patient not continuing with his medical treatment. This decision was appealed (and thrown out) all the way to European Court of Human Rights. The files were uploaded by the user who also had few very hard to follow posts here and on Commons:Bar. As far as I can tell all his images in Category:Sluggishly progressing schizophrenia should be out of scope, unless there is some educational use for them I can not figure out. --Jarekt (talk) 19:01, 11 May 2011 (UTC)[reply]
I've done the following:
— Cheers, JackLee –talk– 08:45, 11 May 2011 (UTC)[reply]

Image previews

Is there any way to preview an image's metadata before saving it? I've been using the basic upload form, but all I can preview is the text I write, not the metadata text. Any suggestions? --Philosopher Let us reason together. 14:23, 11 May 2011 (UTC)[reply]

The file's properties (Windows or Linux) or info (Mac) should show the metadata. For information on editing metadata tags, see Commons:EXIF. --Avenue (talk) 14:56, 11 May 2011 (UTC)[reply]
Thanks, that should work. It would be nice if there was a way to preview it when uploading, though. I'm filling in the date= parameter in {{Information}} on the photos I'm uploading and matching that information with the information in the metadata (the photos were taken over the course of two days, but are mixed together), which is why the preview would be useful. --Philosopher Let us reason together. 15:15, 11 May 2011 (UTC)[reply]
Oh, well. Not really necessary. Might be a good idea for a gadget one day, though, if one of our gadget-makers finds themselves with too much time on their hands. --Philosopher Let us reason together. 15:48, 11 May 2011 (UTC)[reply]
I have heard the Upload Wizard reads the date from the EXIF metadata. But it is switched off currently due to tech problems. Cheers --Saibo (Δ) 02:48, 12 May 2011 (UTC)[reply]

Embedly support for Wikipedia and Wikimedia Commons thumbnails

At my request, Embedly now returns thumbnails for images on Wikipedia:

http://api.embed.ly/embed?url=http://en.wikipedia.org/wiki/File:BirdNotes-22-3.jpg

and Wikimedia Commons:

http://api.embed.ly/embed?url=http://commons.wikimedia.org/wiki/File:John-Madin.jpg

Cheers, Andy Mabbett (talk) 17:56, 11 May 2011 (UTC)[reply]

Is there some way to remind Embedly users to comply with the acknowledgment requirements of CC-BY and CC-BY-SA licences? — Cheers, JackLee –talk– 20:20, 11 May 2011 (UTC)[reply]

Is this photo OK under U.S. building FoP?

According to COM:FOP#United_States, FoP is only applicable to buildings in the U.S. There's currently a discussion in the German Wikipedia (in German, of course) regarding the question whether a particular U.S. photo could be transferred from English WP to Commons. The photo in question is en:File:GantryPlazaStatePark.jpg. The buildings in the background should not be a problem, neither the gantry cranes, which are not artworks. But I wonder: maybe the (very simple) fountain/pond design in the foreground counts as a work of sculptural art? What do you think? Gestumblindi (talk) 19:58, 11 May 2011 (UTC)[reply]

In my opinion, no, that particular fountain does not meet the threshold of copyrightability. It's just a circle of water. Dcoetzee (talk) 20:33, 11 May 2011 (UTC)[reply]
"that particular fountain does meet the threshold of copyrightability" - it seems you mean "does not meet"? ;-) Gestumblindi (talk) 20:38, 11 May 2011 (UTC)[reply]
Er yes :-) Fixed. Dcoetzee (talk) 00:34, 12 May 2011 (UTC)[reply]

May 12

When US Federal agencies don't know how to liscense their PD images on social networking sites, like flickr...

In the last year or two many groups within US Federal agencies have started to republish their PD images on social networking sites, like flickr. Ideally flickr would let those officials place a PD liscense on those images. Flickr does allow a small number of institutions to use a PD liscense -- but they are all, or almost all museums.

Some of those officials use the most generous CC liscenses that flickr supports for non-museums. Others state "all rights reserved", and others try to place "no derivatives" conditions, or "no commercial use".

Recently I noticed another contributor had uploaded some images from flickr, where the US Federal employee(s) tried to apply a nonfree liscenses. I had considered uploading images from that flickr-id, and had chosen not to, due to the liscense complication. But this other contributor is basing their PD liscense on the EXIF data, not on the flickr liscense. I hadn't noticed this.

Is this a good idea?

Nothing stops someone else from noticing this, and placing a {{Flickrreview}} tag on those images.

{{Flickrreview}} can handle most good flickr images. But about five percent of the time it requires a human to do the review. Would it make sense to have another similar tag that always requests a trusted human to verify that the EXIF data confirms that a flickr image is PD, even if the Federal employee who uploaded it used a non-free liscense?

Cheers! Geo Swan (talk) 02:14, 12 May 2011 (UTC)[reply]

What is the file? Link to the Flickr account? If it is a work of the federal government, then the license they apply to Flickr is useless...it will be public domain. Is there something about the image that makes you think it isn't public domain? — Huntster (t @ c) 17:32, 12 May 2011 (UTC)[reply]
Flickr does have a special "US Government Work" license as well, which is what should be used ideally, but it's not something available by default. Some of the US Gov flickr accounts have that set up, but I'm sure not all have bothered. Anyways, if they are works made by US Government employees in the course of their duties, they are public domain and (at least in the United States) they cannot claim those licenses. A human reviewer should see the validity of the PD license and ignore the Flickr one. And if the source page is under a free license, it doesn't hurt for Flickrreviewr to document that. The USGov license can be added any time. There is a mostly theoretical question on whether the USGov tag is fully applicable in other countries, so evidence of a fully free license could be of use if those theoretical issues ever started to become reality. I don't think anything needs to change. I guess the only issue is if there is a non-free license on Flickr and an admin deletes without realizing that PD-USGov applies as well. Carl Lindberg (talk) 18:06, 12 May 2011 (UTC)[reply]
That is good to know. I have uploaded thousands of flickr images, but I have never seen one of these liscenses. Is there any chance you had handy a url to an image with one on it? Thanks! Geo Swan (talk) 20:41, 12 May 2011 (UTC)[reply]
There are plenty: the White House's photostream (as with the situation room photo), for example. The FlickrreviewR bot can recognise at least some specific Commons PD-USGov tags, like that for the State Department. —innotata 22:26, 12 May 2011 (UTC)[reply]
@Geo Swan: how about some examples? Lupo 22:24, 12 May 2011 (UTC)[reply]
Just because some U.S. governmental agency like the U.S. Army publishes a photo on Flickr doesn't mean yet that the photo was created by an employee of the U.S. government in the course of his duties. For instance, this photo is actually a contractor's image (copyright held by Remington). But also this photo (at the Commons as File:XM2010 November 2010.jpg) is in all likelihood not a U.S. Army picture but most probably also "all rights reserved" by Remington, as I argued just a few minutes ago in a slightly different context. Lupo 22:24, 12 May 2011 (UTC)[reply]
It's a very interesting find. There was a DR about this photo: Commons:Deletion requests/File:XM2010 November 2010.jpg, the picture had been kept basing on response of a Public Affairs/Strategic Communications of PEO Soldier. I can't download this catalog, their Windows-based server is down, but maybe the DR should be reopened basing on this new information. Trycatch (talk) 23:45, 12 May 2011 (UTC)[reply]
Hm, I have no problems accessing the remingtonmilitary.com web page. However, downloading the catalog works only if you have JavaScript enabled. Lupo 06:34, 13 May 2011 (UTC)[reply]

Categories starting with the word "Famous -"

I propose renaming these categories with the suffix "Notable -".205.206.8.197 05:42, 12 May 2011 (UTC)[reply]

Please, no - don't infect the category names with unnecessary Wikipedia jargon. It would be better to just get rid of the prefix altogether. --Avenue (talk) 12:11, 12 May 2011 (UTC)[reply]
Why have such peacock descriptive at all, its a reasonable presumption that just having a photo uploaded to commons confers that basic premiss. Gnangarra 12:55, 12 May 2011 (UTC)[reply]
I agree. Arbitrary modifiers like "famous" or "notable" have no place in Commons category names. --Skeezix1000 (talk) 13:16, 12 May 2011 (UTC)[reply]
Category:Famous people is very filled with subcategories like Category:Houses of famous people by country and should be kept, I think. But I agree, that f.i. Category:Famous trees could be as well Category:Remarquable trees. --Havang(nl) (talk) 13:54, 12 May 2011 (UTC)[reply]
"Remarkable"? - Jmabel ! talk 15:58, 12 May 2011 (UTC)[reply]
Thanks for bringing it here! I think that, along with "Topics", "Sources" and "Licenses" dimensions, Commons category schemes also need a "Get Real!" scale. Chemical formulae on "Colder than Iceberg" extreme, mating elephants in the middle, and this - "famous people" - on the other end. Give it a chance, it's a great comic relief. Who are these "famous people", after all? Will my mother-in-law qualify? Trust me, she would. Keep. Famous. NVO (talk) 15:19, 12 May 2011 (UTC)[reply]

Get rid of "peacock" descriptions where the criteria are necessarily completely subjective. Winners of particular awards? Sure. Buildings with landmark designations? Sure. But "famous"? "Notable"? No. Nothing to prevent someone from creating a page with the most prominent examples in a category and its subcategories, but it's not useful categorization. - Jmabel ! talk 15:58, 12 May 2011 (UTC)[reply]

What's notable or famous in the Welsh area might be completely different from what's notable in the Basque country or in Tibet. The fact that they are somewhere are on Commons makes them notable. I don't think that we need additional subjective filtering. A CFD should help to clear that out (for good I hope). --Foroa (talk) 07:34, 13 May 2011 (UTC)[reply]

Template in EXIF

File:LG Headshot.jpg, this should not happen. --Martin H. (talk) 23:57, 12 May 2011 (UTC)[reply]

Ouch (for those how do not want to see themselves: a CC license template in EXIF data is expanded). The EXIF data does not seem to be sanitized / preserved from any interpretation enough by our software. --Saibo (Δ) 00:01, 13 May 2011 (UTC)[reply]
See Jeffrey's EXIF viewer. --Martin H. (talk) 00:10, 13 May 2011 (UTC)[reply]
So how should we prevent this from happening? Something we can do or do we write bug report? --Jarekt (talk) 01:48, 13 May 2011 (UTC)[reply]
Interesting image. "Mike Fedele took and owns this picture"... I don't believe it for a second. Lupo 06:52, 13 May 2011 (UTC)[reply]

May 13

{{PD-Libya}}

Should I use this template for pictures published in the 30's in Libya (at that time en:Italian Libya)?--Kimdime (talk) 11:10, 13 May 2011 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=54313750"