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:
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.
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).
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:
The URAA decision is a reminder that we have to be clear, for every new upload, why it is in the public domain in both the US and the source country. Some notes:
We've been generally assuming {{PD-old-100}} works are PD in the US. This is true for published works for at least the next 11 years, but after that (or for unpublished works) it may not be. For this reason we will also require {{PD-old-90-1923}} and {{PD-old-100-1923}} tags (the latter covering many existing files).
For works first published 1923 or later, things get messy. We need a tag to show PD in the source country. Additionally:
If they were published within 30 days in the US, we also need one of the US PD tags (and any of them could apply).
If they were not, then we have to establish {{PD-1996}}. I believe the {{PD-1996}} template is not specific enough regarding the reason the work was in the public domain in 1996 in its country of first publication, considering many nations' laws have changed since 1996. To address this, we need new more specific {{PD-1996}} templates, such as {{PD-1996-old-50}}, {{PD-1996-old-70}}, and for nations with particularly unusual or complex rules, nation-specific templates like {{PD-1996-India}}. See en:Wikipedia:Non-U.S._copyrights for a table of such rules by country.
Enforcement: we need to make sure every file not already using a combined tag, like {{PD-old-70-1923}}, includes both a source country and US tag. The template {{PD-two}} exists for this purpose. I believe the best way to enforce the policy is to make it so that source country only / US only tags cannot be used outside of the PD-two template. If they are, it will show an error message and place it in a cleanup category. This is not hard to implement technically: we have the PD-two tag pass an extra parameter to both of its argument tags, and if the parameter is omitted, the tag will show the error.
In that case only the U.S. license is needed. In all other PD cases I support requiring the usage of two licenses that make the situation clear. Hekerui (talk) 20:31, 20 January 2012 (UTC)[reply]
Apart from Powers' question above, it looks fine. I was wondering if we could have some templates that would "automatically" find out the copyright status of a work by combining parameters {{copyright status|country of first publication=France|date of first publication=1925|author death date=1936}} would produce something similar as {{PD-1996-old-50}}. Teofilo (talk) 20:35, 20 January 2012 (UTC)[reply]
I considered this but this only works when the info is known. Often we make an "intelligent guess" that e.g. a work published in 1860 is probably PD-old-70 even if we lack the author death date. These kind of guesses, and ranges of values are hard to capture in templates that take specific values. Dcoetzee (talk) 00:51, 21 January 2012 (UTC)[reply]
We've had this situation all along -- the URAA restorations have been part of U.S. law since 1996. PD-two has a common issue that you can't pass tags which themselves take arguments. I'm not sure there needs to be a sweeping change to existing files... but, for cases of copyright expiration, adding two tags (as part of PD-two or not) would definitely be helpful. I'm not sure a proliferation of PD-1996 templates would be a great idea either... you can usually tell which country is the one in question, and go look up the conditions of their law and figure it out. Keep in mind all of this stuff is ridiculously complex, and we do need to make things as easy as possible on uploaders, so any substantive changes have to be incorporated into the upload wizard, etc. The previous practice was basically as that as we notice files which are potentially problematic, we investigate and nominate for deletion as usual. If we make any changes... it should probably be careful, and not take effect anytime soon. Burdens of proof on the uploader have been a line in the sand; implementing this could pretty much scramble that even more. I don't see a need to make it more complex than it has been all along, as the law has not changed at all this whole time, but anything to make it easier (or to let uploaders enter information if they happen to know it) would be good. But yes, if we (as assumed) go with deletion of URAA-restored works, we should probably have a way to mark both copyright statuses. I think there are waaaaaaay to many existing files to actually require usage of PD-two though. Deletions on account of missing such tags would be very poor form on our part I think. Carl Lindberg (talk) 00:13, 21 January 2012 (UTC)[reply]
Not recommending deletion of such cases, just review and updating of tags (and deletion nominations where warranted). Considering the backlog, printing an error might be inappropriate, and bot assistance would probably be required. My issue with {{PD-1996}} is that, unlike most of our tags, you can't just look at it and say "this work does or does not meet these conditions," which makes it much more cumbersome to check, and so more likely to be wrong. This is particularly frustrating since in most cases the country of first publication is not specified in the file information. I do think a new wizard is needed to help users supply correct PD information - right now AFAIK the UploadWizard is still using the PD-old tags by themselves which is definitely not right. Dcoetzee (talk) 00:55, 21 January 2012 (UTC)[reply]
We can't put all the burden on uploaders -- some research can be required for third-party reusers, or other editors here, to fill in some gaps; the full information doesn't need to be immediately apparent. But yes, the following pieces of information can help inform the status: date of creation, date and country of first publication, date the author died, and what country the author was from. Any and all of that helps, though a proper source usually means that much of that information can be determined by consulting that source, which is why we require that -- I'm sure many would doubt data provided by an uploader if there was no source, meaning we'd have to do the research anyways. Carl Lindberg (talk) 01:32, 21 January 2012 (UTC)[reply]
I think we should have some kind of flexibility regarding existing files, but we should try to streamline our procedures so that uploaders document newly uploaded files in an accurate way, and provide them with the tools to easily do so. Teofilo (talk) 01:07, 21 January 2012 (UTC)[reply]
The upload wizard should simply ask for the required input data such as country of origin, date of first publication etc. and throw out the corresponding templates by itself. The question is, what to do about important missing data? --Prüm (talk) 01:20, 21 January 2012 (UTC)[reply]
The relevant country is the country of author, not the country of first publication, isn't it? Then, asking for author and publication data will be usually enough.--Pere prlpz (talk) 01:40, 21 January 2012 (UTC)[reply]
The relevant country of a published work is the country of first publication per Berne treaty article 5-4)-a) The country of origin shall be considered to be:(a) in the case of works first published in a country of the Union, that country;[1] The relevant country of an unpublished work is the country of the author. Teofilo (talk) 04:33, 21 January 2012 (UTC)[reply]
Question Throwing in a question for {{PD-1996}}: Requirement is stated 1) not simultanously published 2) and published before 1978 without compliance with U.S. formalities 3)and PD in country of first publication at URAA date. My question is about 2). Published in the U.S. or published abroad without compliance? --Martin H. (talk) 13:29, 21 January 2012 (UTC)[reply]
Update: I've now created Category:Files requiring U.S. copyright review and put in it all files bearing the {{PD-old}}, {{PD-old-70}}, etc. tags (unless they have the "used-with-US=1" parameter). I'm having a bot automatically approve all {{PD-old-90}} and {{PD-old-100}} files by converting them to {{PD-old-90-1923}}, {{PD-old-100-1923}} (which is accurate at the present time, reasonably assuming the work was published during the author's lifetime). The next step will be to run another bot which approves any files that have a US PD tag. After that, another bot may be able to use the "date" field to identify some more PD-1923 works. A ton of manual review will still be needed. I'm not even going to think about the PD-1996 cases for now, as the PD-1923 cases are quite extensive. Dcoetzee (talk) 19:13, 21 January 2012 (UTC)[reply]
Wow wow wow, hold on. I am not sure I get it. All {PD-Old-XX} are deprecated ? Should {PD-Old-XX-19XX} the rule ? What about PD-two, is it deprecated as well? We are losing load of translations in the process too. Jean-Fred (talk) 19:32, 21 January 2012 (UTC)[reply]
PD-two is not deprecated - I modified it to automatically mark its first parameter with used-with-US=1. The PD-old templates aren't deprecated, but have to be used either with PD-two or in combination with a US PD tag (in which case they will be marked by a bot as used-with-US=1). Even PD-old-100 may not imply PD-US for works first published posthumously, so it's important to distinguish these cases. The translations aren't lost, they can be ported to the new templates easily enough. Dcoetzee (talk) 19:45, 21 January 2012 (UTC)[reply]
Hmmm, ok. So shall use the two templates (either combination with used-with-US=1 or Pd-Two) or {PD-Old-XX-19XX} ?
About PD-old-100 files, for eg 17th century paintings, are we supposed to replace PD-old-100 by {Pd-two|PD-old-100|PD-1923} ?
Right, except for old paintings you should prefer {{PD-old-100-1923}}, because it's more compact (or for PD-Art works, {{PD-Art|PD-old-100-1923}}). I'll add translations to the PD-old-XX-1923 templates soon if no one beats me to it. Dcoetzee (talk) 20:01, 21 January 2012 (UTC)[reply]
Oh dear, I fear I may have created the largest backlog to ever exist. Category:Files requiring U.S. copyright review currently contains 1.2 million files. Assuming each one takes 1 minute to resolve, it will require over 2 continuous man-years of work to review them all. If I can assume the "Date" field is the date of first publication, a bot could resolve many of these. Any other strategies that might help here? Dcoetzee (talk) 21:22, 21 January 2012 (UTC)[reply]
Just a note: User_talk:Dcoetzee#Stop_your_attempts_to_break_Commons. Dcoetzee is pushing his agenda (with bot support) to fuck up Commons. Why on earth?! Where is the neutral conclusion of this discussion? I cannot see it. No actions until the discussion (the "all" DR which was severely bashed included) is over. There is no rush in any way. --Saibo (Δ) 22:21, 21 January 2012 (UTC)[reply]
My change to Template:PD-old-100 that you reverted twice merely placed files which need to be reviewed in a (hidden) review category. As I've already explained, not all works whose authors died at least 100 years ago were first published before 1923 (they may have been first published posthumously), so they require manual review to ascertain this and replace the tag by {{PD-old-100-1923}} or another suitable tag. How does this "fuck up Commons"? I never threatened to delete anything, and the tagging for the DR you mentioned above will of course be reverted as soon as it is closed. Dcoetzee (talk) 22:24, 21 January 2012 (UTC)[reply]
@Dcoetzee: Wait with any of your actions until we have discussed, thanks. We are lucky that you did not delete all URAAAAhh! files right away with bot support for being copyvios, hmm? --Saibo (Δ) 22:31, 21 January 2012 (UTC)[reply]
I have explained this in considerable detail above. My objective is to locate works which are not free in the US, which are not permitted under Commons:Licensing, and nominate them for deletion, for the protection of the project and our US content reusers. To that end I am reviewing all files without a US copyright tag. The review category helps to track which files have been reviewed already and which have not. My bot, before you insisted I stop it, was tagging files which are PD in the US and so not candidates for deletion, quite the opposite of what you're assuming. Just to make this perfectly clear: I am not going to delete any files. Dcoetzee (talk) 22:32, 21 January 2012 (UTC)[reply]
(EC) You may want what you want but leave all the other users out of our personal US-centric agenda. You can do your personal projects in your user space. --Saibo (Δ) 22:41, 21 January 2012 (UTC)[reply]
Saibo, the law is the law. If you don't like that, why don't you make it clear that our tags aren't about the public domain, which is a legal concept, but is instead about what Saibo thinks is okay for us to host?--Prosfilaes (talk) 22:50, 21 January 2012 (UTC)[reply]
"Wow wow wow, hold on. I am not sure I get it. " was a comment of today by some other user above. Don't you get it, Dcoetzee? Go to your userspace for experiments, please. --Saibo (Δ) 22:44, 21 January 2012 (UTC)[reply]
This is a review process that I believe other users will want to help with, which is why I'm conducting it with a category. I don't see how it differs from any other active license review process. I already answered the questions asked by that user. If you have any substantive objections to this process, please explain them. Dcoetzee (talk) 22:46, 21 January 2012 (UTC)[reply]
Processes are not pushed (proposed, discussion evaluated, and executed that fast) by one person. Objection: don't do anything and keep cool. --Saibo (Δ) 22:57, 21 January 2012 (UTC)[reply]
I am reverting any potentially incorrect edits by my bot and appreciate you and User:De728631 identifying them. Please let me know if you find any others. If there is not consensus in favor of a review, I will also revert all the changes adding "used-with-US=1". (also reverting used-with-US changes now, pending consensus) However, I would advise you not to use the term "vandalism" in reference to good-faith edits. Dcoetzee (talk) 00:00, 22 January 2012 (UTC)[reply]
If I cannot assume something to be good faith (for the project) it may be called vandalism, sorry - just facts. Already your mass DR without previous discussion was too much as I had told you in the DR. --Saibo (Δ) 00:29, 22 January 2012 (UTC)[reply]
Note further that due to the actions here the last days it seems not to be advisable to send the uploaders form dewp to Commons - as we tried as hard as possible. A NoCommons template is already added to de:Template:Bild-PD-alt since 70 pma apparently doesn't be to worth anything anymore on Commons. If this would go on you could rename Commons to US-Commons (all the language problems will be solved, too). --Saibo (Δ) 22:41, 21 January 2012 (UTC)[reply]
Why should 70 pma be worth anything on Commons? It's not EU-Commons, and most people in the world have not had that long a copyright term shoved down their throat yet.--Prosfilaes (talk) 22:50, 21 January 2012 (UTC)[reply]
I don't think that such an aggressive style of communication (on both sides) is helpful here. But, Prosfilaes, in fact "70 years pma" is near to a worldwide standard (with some exceptions, but it's applicable in most countries, I think), and you could also vice versa say that "most people in the world have not had that long a copyright term shoved down their throat" regarding the "95 years after publication" term of the U.S. There are many cases where the "70 years pma" makes works free in their source country much quicker than in the U.S., but also cases where the opposite is true - depending of the author's year of death and year of publication. Gestumblindi (talk) 16:04, 22 January 2012 (UTC)[reply]
Well, at least life +70 years is very common (e.g. applicable in the whole European Union), and life +50 years is even more likely to make a work much quicker free than according to U.S. copyright, so I don't quite see your point here. Gestumblindi (talk) 20:29, 29 January 2012 (UTC)[reply]
My point is that life + 70 is not a worldwide standard, that it's barely less provincial then US law. Life + 70 is the third most common copyright law on the planet (I think; I didn't exactly add up all the life+70 nations, but it looked less than India's 1.2 billion). Your "applicable in the whole European Union" I think hits a big sore spot for me; the EU is to a first approximation a less-tightly knit US or India, in land area and population. So why is that our standard?
We have deleted huge swaths of files because they didn't fit EU law. Not only Picasso, but pretty much the entire subject of modern art has been deleted, even though we could have legally kept all the early history. I understood that this was a compromise; we would follow US law (which we have to), but we would also work with other laws to make Wikipedia more widely usable. Fine and well. This URAA thing was simply an honest disagreement about US law, and the courts would resolve it one way or the other, and we would bring ourselves into conformance with US law.
Suddenly the courts do resolve it, and this delusion that we had any intent of following the law that binds the WMF dissolved. If they had had the honesty of the Swedish Pirate Party and proclaimed civil disobedience to all copyright law, I would have had some respect, but instead this is a proclamation of the superiority of EU law over the US. The Rule of the Shorter Term is (mostly) used in the EU, so therefore the US is wrong for not having it. It's okay to delete a file because it would make it hard to distribute the Italian Wikipedia in Italy, but not because it would make it hard to distribute the English Wikipedia in the US... even if the Foundation and servers are US and we have to follow US law, we should still flout it.--Prosfilaes (talk) 08:41, 30 January 2012 (UTC)[reply]
I get your point now, thanks, and I think I can even agree with much of what you say. However, consider also that it's natural for Commons contributors from the EU (or European countries not in the EU, e.g. Switzerland, Norway) to react more strongly if it's proposed to delete files that are perfectly legal in their countries than when it's about files where they can see and accept that they aren't in the public domain where they live (the "huge swaths of files" you mention). It may not seem fair towards the U.S. contributors, but it's an inevitable reaction. An additional factor is that this time it's about files that are from these countries, so the images are part of our European cultural heritage. In this regard, Commons contributors from the U.S. are in a comfortable situation: Images from the U.S. which are PD in the U.S. are never threatened by deletion here - so, vice versa, European contributors may see it as unfair towards them if EU works which are PD in the EU are threatened by deletion, but not on the other side U.S. works which are PD in the U.S. but not in the EU. It is a dilemma. Gestumblindi (talk) 21:12, 30 January 2012 (UTC)[reply]
reasonably assuming the work was published during the author's lifetime --> I would rather we would carefully assess each case, rather than make bold assumptions not based on evidence. If we don't have evidence that a file is PD, let us tell the readers that we don't know, rather than make the reader believe that we know. I am not sure if every painting or every photograph is systematically published during an author's lifetime. It depends much on the notion of what the lawmaker means by "published". Probably many old 18th century paintings are PD in the USA not because they were published during the author's lifetime but because they were published in the 19th or the 20th century before 1923. Teofilo (talk) 00:23, 22 January 2012 (UTC)[reply]
Yes. I struck that text because I stopped running that bot task and I'm reverting all its edits, for the reasons you described above. I apologise for not waiting for feedback from others on that dubious idea. Dcoetzee (talk) 00:25, 22 January 2012 (UTC)[reply]
I guess that probably 90% of 18th century paintings were published via etchings/prints or photographs before 1923. We would still need to find out the remaining 10% and delete them. Some museums like the MET provide something close to a publication history. See this diff (for a 20th century work)Teofilo (talk) 00:33, 22 January 2012 (UTC)[reply]
I agree with Dcoetzee that we must find the files that could not be PD in the US to review and tag those that actually are in PD - e.g. we must search for publication date. Creating a category of files needing review would be useful. Finding which files in this category are used in every project would be useful to recruit interested editors in finding publication date and reviewing the files.--Pere prlpz (talk) 00:42, 22 January 2012 (UTC)[reply]
We do not need to find publication dates for files which are public domain (except in the one, single, overly important country, the US). And the files do not need review. The ones that you find that they are PD in the US get a "US-approved" tag and the others a deletion tag? Don't destroy Commons with US-centrism, thanks very much. --Saibo (Δ) 01:06, 22 January 2012 (UTC)[reply]
I think that the sad fact that the content of WMF servers located in the US must comply with US law has been abundantly debated. Proposals to have non-PD-US files (or the whole WMF) moved to anywhere else should be discussed anywhere else (e.g. the deletion proposal page). Here, we are just discussing the best way to tag file licenses.
And of course, copyright status in any other country is an interesting information for any file, although it doesn't change the legality of keeping the file in Commons. If you want to start a non US-centrist project to tag all files with copyright information for all countries (or even some files for some coutries), it will be an interesting project. We are trying to start with just one country - the country that is relevant in our ability to keep the files here.--Pere prlpz (talk) 01:30, 22 January 2012 (UTC)[reply]
Indeed, but not Switzerland (which is not in the EU). Switzerland doesn't have a special protection for the publisher after first publication; e.g. if the author is dead for more than 70 years, the work is and keeps free, even if first published today. Date of publication is irrelevant. I don't know about the situation in Norway or Iceland, which are neither in the EU. Gestumblindi (talk) 15:55, 22 January 2012 (UTC)[reply]
Also, before choosing which country's law applies, you need to either:
show evidence that the work was never published and that the author is a national of a given country, or:
show evidence that the work was first published in a given country
Following on from #Proposed changes to PD tags above: I would like to propose a review of materials tagged {{PD-old}}, {{PD-old-70}}, etc. up to {{PD-old-100}} for works that may be in copyright in the U.S. because they were published 1923 or later and were in copyright in their country of first publication on the URAA date. Even in the case of PD-old-100 this is possible if the work was first published posthumously. To help organize this, I think it would be helpful to have a category Category:Files requiring U.S. copyright review listing all unreviewed files with these tags, similar to e.g. Category:Flickr review needed. All files that use {{PD-two}} or {{PD-Art-two}} would be excluded from review, as would any using the combined tags {{PD-old-70-1923}}, etc. All files that already include PD-US-*/PD-1923/PD-1996 tags could be reviewed automatically by a bot. A very (very) large backlog is expected, but that's okay. If you think this isn't the best way to proceed, I'd be interested in hearing alternative proposals for review.
I tried to do this unilaterally before and made some pretty serious mistakes - I assure discussants that this time no action will be taken until the discussion is over and has been closed by a neutral party (and we have also heard from the WMF regarding the URAA). Dcoetzee (talk) 02:20, 22 January 2012 (UTC)[reply]
Oppose It would be nice to have information for every country for each file in a machine readable form. However, this proposal here is only for US. The proposed license tags are overly complicated (remember that uploaders even have problems to understand the meaning of "70 years pma" (which does not require more than 70 years after creation but after death) and nearly no-one will understand this system; especially if it uses some template parameters which need to be set. I saw the file pages you created in your last bot run (which you have reverted): much more than one screen page full of public domain (we are not talking of license templates with restrictions...) tags? Ugly and scaring away everybody who looks at (probably the reaction: they are crazy). If you require non-US works to have a US-copyright clearance for being uploaded here that is a clear bias towards US (US-centrism) and we are no "US Commons". The reason that WMF is based in US is their problem, not ours. Your proposal: No, that is not Commons. So, in essence: we do not need that review which only helps US but not other countries and which leads in the end to more needless deletions of content copyrighted in the US (but PD in most other countries!) than without this review. Furthermore: why can't you just wait until at least the WMF has said a first word? --Saibo (Δ) 02:59, 22 January 2012 (UTC)[reply]
A small note: I didn't actually add any tags to any files in my last run, only modified existing tags (there are files with lots of crazy PD tags out there, but they were already like that). Part of the reason the {{PD-old-70-1923}}, etc. tags were created (by User:Jusjih, I think?) is that they're much more compact than {{PD-old-70}}{{PD-1923}} or {{PD-two|PD-old-70|PD-1923}}. I agree about the cryptic template parameter - I think a simpler way to do it is to simply add the review category to the affected files, and remove it when done. User education is a difficult issue - we can't expect all uploaders to understand the intricacies of both the source country and US copyright. But in many cases {{PD-old-70-1923}} will apply, and in other cases I think a simple {{PD-old}} tag and a review category would be sufficient.
It don't see why you are in such a rush. If WMF sees it the same way as you see it (US-centrisic mass deletions of carefully uploaded and maintained public domain content and crazy copyright tag requirements) then they have simply failed their mission - okay, failureisnothingsurprising for WMF. ;-) But maybe they surprise by choosing a decision according to their mission. --Saibo (Δ) 06:12, 22 January 2012 (UTC) +1 link 16:23, 22 January 2012 (UTC)[reply]
I suppose it's insane to hope that we might one day be able to write {{Super Magic PD template|type|publication date|creation date|country of first publication|author death date}}, and the template spits out what applies?? (And a wizard/gadget with dropdowns which helps uploaders fill in the parameters?) Rd232 (talk) 05:02, 22 January 2012 (UTC)[reply]
Well we have {{PD-old-auto}}, {{PD-old-auto-1923}}, and {{PD-art-auto}}, which is a start. Presumably if we had a template that allows you to specify important factors like the media type, death year of the author, year of first publication, and country of first publication, it could in many cases figure out whether it's PD or not and the appropriate reason. However, this doesn't address cases like {{PD-US-no notice}}, {{PD-US-not renewed}}; it may ask for information that isn't actually needed like the death date of author for US works pre 1923; and doesn't address cases where we don't precisely know all the information (e.g. perhaps we only know a range of dates, or have a guess, like saying an 1860 work is probably PD-old-70). I think a more viable strategy would be a "PD wizard" that asks you a bunch of questions until it figures out the right answer, then gives you the template(s) to paste in (or an explanation of why the file is not allowed). Dcoetzee (talk) 05:08, 22 January 2012 (UTC)[reply]
Yes, I was imagining a super-template plus wizard, but I suppose you could just put the "super logic" in the wizard and use simple(ish) templates. Downside, perhaps, might be maintainability, since Javascript expertise is more scarce than template expertise. Rd232 (talk) 05:13, 22 January 2012 (UTC)[reply]
If the work was first published (posthumously after 1923) in both the source country and US simultaneously, and the work was registered and renewed, it could still be in copyright in the US (without the aid of the URAA). This doesn't seem unlikely for posthumous works of great commercial value. It will also matter in the future: starting in 2017, some Columbian works will be PD-old-100 which in 1996 were still under copyright in Columbia. In 2027 this will expand to most other countries (for works published 1932 or later). Better to start tagging sooner than have to sort it out later. I was going to say the work might have been first published in Mexico, but I just learned that Mexico was only life+75 in 1996. Maybe there are also other possibilities I'm not aware of. Dcoetzee (talk) 07:54, 22 January 2012 (UTC)[reply]
Any work, no matter where it was published, which managed to follow U.S. formalities could still be under copyright if published since 1923. Any unpublished work could still be under copyright, as well. Things created before 1978 but published from 1978 through 2002 will still have copyright until at least 2048, no matter when the author died. All of this is without the aid of the URAA. Also, starting in 2019, old published works will start expiring in the U.S. again; copyright on restored works won't last forever. By 2027, the line should be works published in 1931 and earlier. One note on Mexico -- they really weren't even life+75. The extension from 50 to 75 happened in 1994, but it wasn't retroactive (though did extend existing copyrights). And the 1982 extension from 30 to 50 pma was also not retroactive, meaning the line is (at most) authors who died in 1952 and later, and that only if the 1982 change extended existing copyrights (not sure on that one, just as I'm not sure if the 100 pma change altered existing copyright terms). Mexico also had a registration requirement for works published before January 14, 1948. Carl Lindberg (talk) 13:37, 22 January 2012 (UTC)[reply]
Support Copyright status in the US is relevant information about files and this information should be checked. Any categories, lists or templates that could help us to check it are welcome. A few reasons:
We can eventually be forced to delete or to move away files that are not free in the US, or even files not justified to be free in the US. Then, tagging the files that actually are free in the US wil help us to save those files and would ease the work of moving the other ones (if it is possible to move instead of deleting).
WMF inability to host unfree files may be its problem, according to WMF views or according to US courts, but if WMF decides (or is forced to) solve its problem by deleting, it will be our problem. It will be our problem even if we are not concerned with WMF problems but concerned with our projects.
As Saibo noted, " It would be nice to have information for every country for each file in a machine readable form." I support any serious proposal to tag copyright status in any other country, just as I support Dcoetzee's proposal for the US.
We can't expect all uploaders to be able to tell copyright status of every work in the US. In fact, a lot of uploaders just don't mind about copyright status. This is a good reason to organize files to be reviewed.
I don't like complicated templates, but the facts license templates describe are complicated. Having double templates seems a good idea, since simpler templates can be used separately or complex double templates can be used more efficiently, leaving the choice to reviewers.--Pere prlpz (talk) 12:33, 22 January 2012 (UTC)[reply]
Support in principle, but how is it to be organised in practice? Perhaps this is another case for a Request for Comment, eg Commons:Requests for comment/reviewing PD tags. I would allow the scope to be a bit broader, because I echo Pere prlpz's point that as far as possible, we should try to be clear about copyright status in as many countries as possible. (I also think we could be clearer in COM:REUSE about what the implications are for reusers when copyright statuses are different in different countries.) Rd232 (talk) 16:12, 22 January 2012 (UTC)[reply]
I'm still getting used to us having an RfC, that sounds appropriate :-) I would definitely be amenable to a plan that clarifies not only US copyright status (which is essential to whether we can host files) but also copyright status in other nations (which is essential to whether content reusers in those nations can reuse files). We have little notes for other countries in e.g. the {{PD-old-70}} tag, but that's about as far as things go at the moment. It would be neat if we had like, some kind of drop down list of countries that could give you info about a work's copyright status in any given nation. I think any review proposal should also include more information about effective prioritization, considering the enormous size of the backlog. For the RfC, do you think we should move this discussion there and revise it as we go, or start a new one based on the feedback received so far? Dcoetzee (talk) 01:11, 23 January 2012 (UTC)[reply]
Some more thoughts: I think one way to get started on this would be to start documenting copyright-essential metadata about each PD image with a machine-readable template. Think something like enwp's persondata. It might look something like this (based on your super-template from before):
{{copyright data
|publication date=
|creation date=
|country of first publication=
|author death date=
|(possibly other fields)
}}
Any fields that aren't known would be left blank. With a template like this, it would be possible for a bot to reliably, automatically add appropriate license templates in many (but not all) cases, while putting other cases on manual review (just as we do for Flickr review). It would also facilitate tools (e.g. on Toolserver or using Javascript) to provide copyright status in many different countries and explanations, just by examining the machine-readable data and producing appropriate info for the desired country. The info could also potentially be useful for automatic categorization, and for other analyses. I am aware it would not cover all cases, e.g. {{PD-US-no notice}}, but those could still be described using tags as is currently done. Thoughts? Dcoetzee (talk) 02:07, 23 January 2012 (UTC)[reply]
I think that's a potentially very fruitful avenue to explore. I'll just quickly point out that the persondata approach is not unique to en.wp: there are 10 interwiki links from de:Vorlage:Personendaten, the equivalent on de.wp [and 20 interwiki links from the en.wp template, in fact]. Jarekt points out overlap with Creator templates and others; I'm not sure if there's any elegant way to reuse that data; but duplication might be a price worth paying. Rd232 (talk) 03:27, 23 January 2012 (UTC)[reply]
Dunno. You would need type of work as well (and the variants between all the countries is pretty daunting). Government work vs corporate work vs personal work. If multiple authors, needs to be the last death date, but that may be OK. You could start with using Commons:Hirtle chart, File:Canadian Public Domain.svg, and a UK chart (non-Crown copyright only) for an idea of the questions you need to answer, and the data you need up front to answer it. It might be possible, at least for many situations, but it would probably be quite difficult. Some countries would definitely be easier than others. There actually is an online public domain calculator for many EU countries -- you could see many of the needed questions there as well. Carl Lindberg (talk) 05:38, 23 January 2012 (UTC)[reply]
Strong support for an autotemplate/metadata system (in theory, at least): it can start off with common permissions issues, and let itself be over ridable. Then, over time, the niches can be incorporated. I think it's the only long term solution to making copyright user friendly. Happy to help! Jarry1250 (talk) 17:15, 25 January 2012 (UTC)[reply]
I have started writing an autotemplate for France (but I am far from being finished). To give you a taste, try the following
{{copyright data France
|the work is a musical composition=no
|country of first publication=France
|date of first publication=1926
|date of author death=1928
|author died for France=no
}}
This is an interesting approach, having copyright data metadata templates for various countries, including data relevant for status in those countries. That way we wouldn't end up with one giant template with way too many fields. The way I imagine it, rather than just picking one, you could add many metadata templates for different countries. To avoid redundancy, the general {{Copyright data}} template could include information that is relevant in many countries, like the data I listed above. Dcoetzee (talk) 02:38, 26 January 2012 (UTC)[reply]
I was thinking the general {{Copyright data}} would be a switch containing only a few lines of codes starting with " #switch:{{{country of first publication}}} ", switching to each country-specific template. If we are sure that two country have exactly the same rules we could merge them, but in that case it would be as simple to duplicate the template and just change the country name. Teofilo (talk) 04:07, 26 January 2012 (UTC)[reply]
Well the issue is that the country of first publication is not the only relevant one. In particular the copyright status of the work in the US is relevant to us, even if not the country of first publication. The copyright status in yet another, third country may be relevant to content reusers in that country, and it may differ if the work was also published concurrently in that country. So... the easiest way to support many countries seems like it would be more than one template. Dcoetzee (talk) 08:03, 26 January 2012 (UTC)[reply]
The "copyright data France" solution would be very useful in most situations in that it could automatically produce {{PD-old-70}}, {{PD-old-100}} and similar tags as appropriate and also update them at the end of each year so that the templates help reusers in a maximal way. I think that this might be the best option. However, there might be other odd situations which need to be covered somehow. For example, I have recently looked at categories of British signatures on Commons to confirm licence validity. In many cases, I found that the signature was at least {{PD-old-70}}, but I could not find any proof of any publication, or they might not have been published before 1923. In this case, the licence tag for the source country is {{PD-old-70}} whereas the licence tag for the United States is {{PD-signature}}. There might be other situations which are not covered by the template above. For these odd situations, it might be necessary to offer the possibility to take a US licence template as an argument. Also note that "author died long before 1996" doesn't imply {{PD-1996}} since the works nevertheless get 95 years from publication copyright if all US copyright formalities were fulfilled (including copyright notices in all US and foreign publications of the work). --Stefan4 (talk) 15:28, 27 January 2012 (UTC)[reply]
Comment It should be noted that most if not all translations of {{PD-old}}, and {{PD-old-auto}} have a license text that reads: "This includes the USA and all countries with a copyright term of 70 years...". And there are generally no warnings that a PD-70 license alone is not sufficient. We might want to fix that. De728631 (talk) 18:42, 27 January 2012 (UTC)[reply]
I have now removed the United States from the templates in a few languages (Nordic, Dutch, French, Spanish and CJK) and translated the warning about US copyright tags into Swedish. I wouldn't dare to try to fix the other languages since I might mess up grammar or something if I try to remove a country name. --Stefan4 (talk) 22:14, 27 January 2012 (UTC)[reply]
This is expanding from the original thread title, but I think it flows naturally from it, and we could use a concrete proposal. I suggest we launch Commons:Requests for comment/PD license tags to discuss the broader issue of how we organise license PD tags, with some of the ideas from above. I'd like some quick input on whether that's a good idea, and if so on what the scope and aims of the RFC should be. Rd232 (talk) 03:27, 23 January 2012 (UTC)[reply]
I think this is a good idea. I think the discussion should center around two main problems: 1. how should information relevant to the copyright status of a PD image be represented and displayed on file description pages; 2. should there be a review process for PD images to research this information, and how will it work? An RfC could support a series of proposals on these topics. Dcoetzee (talk) 02:05, 24 January 2012 (UTC)[reply]
Commons requires censorship-proof History feature
Dear everyone, I have suspected several times that images which were inconvenient for some individuals/organisations disappeared from Wikimedia Commons. Now a history feature does exist, but the original files seem not to be retained.
I suggest that any historical files should be retained by default.
A special procedure to delete copyright-infringing files could be set up, but this should require checks-and-balances and peer-reviewing of the most extreme possible kind, to make sure censorship is stood up against.
There is a deletion log, where one can see file name and the name of the admin who deleted the file. Go to Special:Log. Deletions can be appealed. See Commons:DEL#Appeal. Typically, a CD cover would require a permission from the CD producer or from the artist who designed the CD cover. Teofilo (talk) 05:05, 26 January 2012 (UTC)[reply]
Thank you for your responses. I was NOT referring to any files I have uploaded myself. Maybe you can clarify the matter for me by explaining why some images on these historical pages cannot be found:
I am referring to the empty images on the above mentioned pages. They are there given these names: Saddam Hussein (107).jpg; Saddam Hussein 4.jpg; TrialSaddam.jpg; Saddamstatue.jpg; Saddam Mosque Mosul.jpg; Saddam bill.JPG; Saddam Hussein with Yasser Arafat.jpg; Saddam morto.jpg --Gulpen (talk) 22:27, 26 January 2012 (UTC)[reply]
Because they got deleted as a violation of our licensing policy, unfree content uploaded without the copyright holders permission or without providing a source that confirms a free copyright status. This project is not for all existing content, its only for those content that is free. --Martin H. (talk) 22:44, 26 January 2012 (UTC)[reply]
Is there any way that I can verify this myself? I have seriously tried to find some of them in the logs, but have been unable to do so. mattbuck writes: "All admins can see deleted images, unless they are oversighted." What does oversighted mean? And what does he mean with that deleted images can be viewed? Are they deleted or only hidden from the public? I find this information hard to find. --Gulpen (talk) 20:58, 27 January 2012 (UTC)[reply]
Deleted images can be undeleted by admins; deletion doesn't scrub material from the servers, but prevents access for all except the relatively small number of admins. "Oversighted" (COM:OVERSIGHT) means hidden from all except the even smaller group of oversighters. Rd232 (talk) 19:51, 29 January 2012 (UTC)[reply]
Thumb
Gallery
File:GAIS 1951.jpgRed link for deleted thumbnail image takes you to a deletion log
Deleted gallery image displays only file name without any link
In a gallery there are no links to deleted images. This makes it a little harder to find deletion logs than for thumbnail images which have red links to pages where deletion logs ares shown. But it is still possbile to copy the file name from a gallery, add "File:" prefix, and paste into Commons Special:Log to find logs for a file. /Ö19:42, 28 January 2012 (UTC)[reply]
User Yann raised my eyebrows by blatantly ignoring copyright and keeping clear copyvios (like this) with lack of FOP in Russia in place. Therefore I am asking the broader community and uninvolved administrators to overturn his decision for the following DRs:
You're ignoring that there were other arguments in the discussions linked above. For instance, in the DR about Krasnye Vorota, I've found a reliable print source which states an architect died more than 70 years ago as the only author, but you mentioned this with not a single word here. In general, the difference between a regular deletion request and a speedy deletion is just the fact that in a regular DR it is possible to bring up some arguments which are against the deletion. Therefore, there is nothing abusive on that closures. - A.Savin13:18, 27 January 2012 (UTC)[reply]
You will remember that your editwarring in the Russian WP where you claimed that the official site of the St. Petersburg Metro is the only reputable source for the depth of a certain station brought you another ban in WP some days ago. An official site is just one of possible sources, people who make official websites are probably experts in web publishing but they may make errors in describing the facts they publish there. Apart from that, here is not a discussion on the reliability of web sites, but on the question if Yann handled correctly with some DR's he has decided, and the answer is: yes. A.Savin13:34, 27 January 2012 (UTC)[reply]
OK, perhaps we should establish a modified kind of Godwin's law where a discussion is to be finished as soon as the one participant alleges childish behavior to the other. However, I see no need for further conversation. Your point of view is clear, my argumentation should be clear as well. A.Savin13:50, 27 January 2012 (UTC)[reply]
Both A.Savin and Artem Karimov presented the reliable source, so there is either need for additional source, or we can keep the image having a support from print source. The aim is to prove freedom of the image, not to reject it. The decision for this case was correct.--PereslavlFoto (talk) 13:38, 27 January 2012 (UTC)[reply]
This discussion might have been better suited for COM:VPC instead of the normal village pump. There seem to be two disagreements: whether pictures are de minimis or not and whether the architects died long ago or not. I think that most images wouldn't pass as de minimis, but there is a possibility that some of them might. You seem to be presenting different (and possibly contradicting) sources for information about architects and the date of death of the architects. If it is unclear who the architect is or when the architect died, deleting per COM:PRP might be the solution. However, it might also be possible to research the matter better first. --Stefan4 (talk) 14:32, 27 January 2012 (UTC)[reply]
I would say: first research, than act, would be the smart way to go. Many of the images are clear de minimis, which paradoxically makes them rather useless in terms of COM:SCOPE. --ELEKHHT15:29, 27 January 2012 (UTC)[reply]
The purpose of DR is to determine if in the court of law it is possible to defend the idea that the image is free. A document was brought up which showed that such thing is more than possible, the validity of that document wasn't questioned, but a website which states the opposite was found. I would tend to believe that in a court it is the website will matter less, as it is a hearsay, and as such freedom of the image has been shown. VolodyA! V Anarhist Beta_M (converse) 03:03, 30 January 2012 (UTC)[reply]
As Dcoetzee has mentioned, discussions on the images should be taken to Commons:Undeletion requests so that a wider range of eyes can opine. If there are issues relating closings by an admin, please take it to Commons:Administrators' noticeboard/User problems. Please treat issues separately. I would suggest dealing with the closures first, and then it may or may not be needed to discuss other closures; a pattern may or may not exist. Either way, this venue is not the correct one.
Also Artem Karimov (talk·contribs) and A.Savin (talk·contribs), how about a compromise. You both work together to ascertain copyright of the Metro in the photo. If you both determine that the copyright has expired, I will 1) personally take photos of the Metro station when I am in Russia later in the year, or 2) organise for a friend to take photos for us. Please just leave ruwp stuff over there, and work together here to get the correct information. Can you both do that? Discuss those details at File_talk:Krasniye_Vorota.jpg, and I will keep it on my watchlist and try to help if needed. russavia (talk) 02:29, 31 January 2012 (UTC)[reply]
Abuse filter log details
Is there a reason that only admins have access to the abusefilter-log-detail right? I'm often on IRC and every time I click the link to see the details, I always get a blank page. Having access to the detailed log would make it easier for me to identify the edit if it's vandalism or not. Could it be assigned to all users like on the English Wikipedia, or to a user group that deals with vandalism, like patrollers or rollbackers? Techman224Talk05:58, 28 January 2012 (UTC)[reply]
I'm wondering if there's a bot that can search out file usage, but instead of deleting the reference (like CommonsDelinker), it simply changes it to a new filename, useful for vector versions of files (and for updating names of SVGs). If so, assuming this would be an admin privilege, are there any admins willing to perform this action regularly for the Graphics Lab? It'd be a great help if this was semi-automated. NikNakstalk - gallery - wikipedia16:17, 28 January 2012 (UTC)[reply]
Changing .png/.jpg/.gif files to .svg is rather controversial and should not be automated. Technically the replace could do this, but we disabled this on purpose. Multichill (talk) 16:36, 28 January 2012 (UTC)[reply]
Where the image is a faithful recreation of a raster, or even a superior version of a simple diagram, most uploaders (like myself) routinely make the changes manually. I understand that with something like this, where the vector is highly simplified and stylised, a routine bot change would be controversial. However, with a little discretion, I don't see why using a bot would be a problem. NikNakstalk - gallery - wikipedia17:40, 28 January 2012 (UTC)[reply]
Bots don't do it to avoid getting blamed in the event of a dispute. I think the right solution is an automatic or semiautomatic tool that a user can run under their own global account that does the same thing. Dcoetzee (talk) 01:23, 30 January 2012 (UTC)[reply]
It would be even more helpful if it were possible to know all the independent wikis which use any given file, so that if a file is renamed or deleted then a message can be sent to that wiki or a bot triggered. You could not expect an independent wiki to put a note on every file it uses (there would be many millions) but if Commons held a list of frequent external users, on which list a wiki could lodge its contact details, then it might be possible to detect a listed wiki's use of any Commons file as we do WP usage and send a message. I do not know the technical requirements to have such a system or if it is at all possible. Hogweard (talk) 13:56, 30 January 2012 (UTC)[reply]
The current version of File:Wikipedia-logo-v2-en.svg has a shape artifact in the file. It is really only visible if you view the image at high resolution or change the color of the wordmark, but it's there. We have a corrected version and are ready to upload it but I wanted to see if there were any concerns or issues I am unaware of about this file (other than it's used everywhere) before I did so.--Jorm (WMF) (talk) 23:02, 28 January 2012 (UTC)[reply]
Seems fine to me, no problem with WMF representatives uploading new versions of WMF logos. Probably would not want anybody else doing that though, since it's an official trademark and everything. Dcoetzee (talk) 01:11, 29 January 2012 (UTC)[reply]
Done. You may use tools:~luxo/derivativeFX/ in future for derivative works. Otherwise it is always the best to copy the licenses and to mention the authors of the works the new one is derived from. But in general, SVG-translator could add such an option. We should ask jarry. -- RE rillkequestions?22:27, 29 January 2012 (UTC)[reply]
It's an unusual case because a user claiming to be the subject uploaded a new version, because they said (in effect) that they were distressed to have that image there, as it was taken at a funeral without their permission. The user had several months ago tried to request deletion [2], but got the formatting wrong on the speedy template. I suggest the best thing would be to delete the file, and reupload the new image under a different name (and replace the two WP uses of the old file). I think the discussion at Commons_talk:Deletion_policy#Privacy and the WMF board resolution regarding subject consent for images of identifiable living people are relevant here. Rd232 (talk) 04:14, 30 January 2012 (UTC)[reply]
It should be uploaded under a new name. If the old image is deleted it should go through a deletion request (I reasonably expect such a request would be granted in exchange for a superiour image). Permission for the new image also needs to go through OTRS to verify copyright ownership - copyright of the image would not belong to her unless there is a contract to that effect. Dcoetzee (talk) 04:46, 30 January 2012 (UTC)[reply]
Yeah, I think in this particular instance the overwriting upload is OK, though a deletion request and separate upload would still have been better. The new image appears in several places, but only one that I could find at the uploaded resolution. Probably should have a DR to remove the older upload. OTRS would help, even if just confirming that the account is theirs, but I'm inclined to believe the account is genuine (and would also assume good faith on the copyright claim). It may be a good idea to confirm the desired license, via OTRS, though the one that is there is about as restrictive as we would allow. The file needs renaming if it's not re-uploaded. Carl Lindberg (talk) 05:59, 30 January 2012 (UTC)[reply]
She was smiling and making a peace sign at a camera while wearing a white button-up top next to a man in a red "HO HO HO" shirt at her father's memorial service? This may have been taken around that time, but this cannot realistically be a photo of a memorial service or funeral, but more likely a more generic Christmas service. So I don't think it is inappropriate of the uploader as was implied, just a person at a social church service and not some heartless bastard exploiting a funeral. We can still delete in favor of the better picture due to the subject's desire, but we shouldn't imply wrongdoing. ▫ JohnnyMrNinja (talk / en) 08:17, 30 January 2012 (UTC)[reply]
The image should be properly restored unless Juniper99 provides a) permission for the new image and b) a verification he/she is really the person claimed or connected with her. --Denniss (talk) 08:49, 30 January 2012 (UTC)[reply]
Yes, adding an interwiki to a Wikipedia category is abviously okay. Adding an interwiki to a Wikipedia article is also convenient and seems to be standard practice. The more controversial case seems to be adding the same links in both the article page and the gallery page (see for example Taipei and category:Taipei). (as far as I am concerned I like to have interwikis in categories as often as possible, just because I use categories much more often than galleries (many galleries are badly maintained and not really useful).--Zolo (talk) 11:58, 30 January 2012 (UTC)[reply]
It's not always a perfect match but where it is it s best to pair galleries here with articles, and categories with categories. So for example with Taipei. The article en:Taipei at wikipedia should be paired with the gallery Taipei here, and the Category Category: Taipei here with en:category:Taipei there. Where there isn't an exact match I add the interwiki to which ever seems the most appropriate, be that the article or category.--KTo288 (talk) 14:57, 3 February 2012 (UTC)[reply]
"thumbtime=2.1"Still yet there is no way to select another thumbnail on file pages. However on other pages (on commons or wikipedia) you may create your preferred thumbnail by using the thumbtime parameter. --Pristurus (talk) 23:24, 30 January 2012 (UTC)[reply]
Support I do not like "see below" - I thinks is not necessary and it clutters the screen. If "permission" is used than the template works as it does now. --Jarekt (talk) 03:40, 31 January 2012 (UTC)[reply]
Add an option "other fields 1" between description and date
This parameter will probably not be used very often? It adds a new customizable field to the template just like the already existing "other fields" , but at a different place: between description and date rather that at the end of the template. A similar result can be achieved by directly adding {{Information field}} to the "description" field.
Support As I said here the new proposed parameter Other_field_1 similar to Other_field and the same as {{Artwork}}'s Other_field_1. The purpose of it would be to allow adding other fields below Description field rather than the bottom of the template. See the code in {{Information/sandbox}} and test in Template:Information/testcases#Test_Other_field_1. This would allow us to rewrite {{Infobox aircraft image}}, {{Bus-Information}}, {{Rolling Stock-Information}} and possibly many others to use {{Information}} as their basis and simplify maintenance of those templates. It would also allow users to add additional description fields in more logical location. See for example File:Kyushu Electric tram 3.jpg with additional "location" field located on the bottom. The change will not affect any files currently using the template. Finally this proposed change is mostly meant to make wiki code more clear since once achieve the same effect without this field, see here. --Jarekt (talk) 04:17, 31 January 2012 (UTC)[reply]
Parse source automatically converts texts like "Obra pròpia (own work)" to {{Own work}}.
Weak support. {{Information}} was designed to appear simple and without much "magic" feel, the automatic conversion of exotic strings may be a bit confusing (all the more as it works for " Eigenes Werk (own work)" but not for "eigenes Werk". Hopefully, more and more uploading tools will use the correct {{Own}} making {{Parse source}} unnecessary. On the other hand, a bot should convert existing pages so that internationalization is not lost.--Zolo (talk) 11:46, 30 January 2012 (UTC)[reply]
Oppose I did not notice that template before, and did not see that this edit removed it. Although I would prefer a robotic substitution of the texts to {{Own work}}, I do not see the reason to change current version. --Jarekt (talk) 03:44, 31 January 2012 (UTC)[reply]
Support removing fancyness. That is very unobvious that the info template does that. It should display what the user put in - nothing more or less. Could lead to confusion at this important info field. --Saibo (Δ) 23:49, 2 February 2012 (UTC)[reply]
Align the content to the same line as the headers (now it is lower)
Description is now lower than the title Description, proper date lower than the title date etc.
To be able to use Wikipedia as an acredited source....
I'm enrolled in a class in my local community college( don't really know if that makes a difference).My professor makes it very clear that we are not to use this site as a basis of any knowledge for our paper that we wil have to turn in at the end of March. I personally, go on here for a lot of different info. Is there any way to make a case in which to provide necceasry information to use this site as being accredited. — Preceding unsigned comment was added by 169.139.222.5 (talk) 17:47, 30 January 2012 (UTC)[reply]
Encyclopaedias, Wikipedia or any other, are not a basis of knowledge. They merely digest and organize the information that is available from many sources. So, your professor may tell you not to use encyclopaedias "as a basis of knowledge", to force you to dig more deeply into the sources and read them directly. Then the idea would be to verify where the information came from in the first place, instead of using only the encyclopaedias where the information is reused. You can use Wikipedia or other encyclopaedias to get a personal overview of the topic and to find a list of sources that were used to write the article and other references. Then you can select and read directly the sources and references that you consider relevant for your paper and cite those readings in your paper. -- Asclepias (talk) 21:37, 30 January 2012 (UTC)[reply]
can someone edit out the first few seconds in my file File:Burping.ogg so there is one second before the burping starts — Preceding unsigned comment added by 31.172.30.3 (talk • contribs) 30 January 2012 19:20 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. 01:17, 3 February 2012 (UTC)
Language mix in category naming
I know that it is OK to have file names in many languages on Commons, but what is the recommended approach for naming categories? I've been working a lot to organize media around the Romanian history and archaeology topics and noticed for example that Category:Museums in Romania by city has a big mix of Romanian and English names for the sub-categories. For example Category:Muzeul Național al Hărților și Cărții Vechi vs Category:History and Archeology Museum Piatra Neamț. Looking at institutions, most of them are in English (not all) and point ideally to categories with the same name. A similar situation happens with Category:Fortresses in Romania and many such similar categories. Now I understand Romanian but I would imagine that it would be hard for someone who doesn't to either properly categorize their own contributions (say they took a picture of the Alba Carolina Fortress while visiting Alba Iulia) or to find media related to a certain topic/category if there is no English name for it. Ideally, it would be great to have both categories, one in English and one in Romanian, and possibly redirect the Romanian-named category to the English one, but I know there are issues with the redirects in Commons. My approach would be to have everything in English (acknowledging that this is a multilingual project), to increase exposure and achieve consistency. What are your suggestions and opinions about this? Thanks--Codrin.B (talk) 21:35, 30 January 2012 (UTC)[reply]
The real category names should usually be in English (see Commons:Language policy, and Commons:Categories#Category_names). If there is no real English alternative, the foreign names are often fine I'd guess, if in a Latin script. It's unfortunate as a multilingual project, but the actual category name used in the File: pages has to be all the same so that users of all languages can find the content; category redirects do not work on that level. You can certainly leave a category soft redirect (i.e. use {{Category redirect}}) with the existing Romanian name, which should cause bots to move images placed in the Romanian one, to the English one. Putting the Romanian name in the category description is also a good idea. Carl Lindberg (talk) 22:30, 30 January 2012 (UTC)[reply]
As Carl mentioned all the category names should be in English, or should be in form most commonly used in English literature (if any exist). In practice it is a challenge with no good solution, since often in case of places little known outside their country local language names are used, which often creates disastrous names using mix of English and local language which is not readable by neither English speaking nor local users. I sometimes use counts of Google hits to try different possible variants of English names which can be used. Also EN wiki is a good guide if they have an article. Finally {{Category redirect}}s, interwiki links and native spelling listed in the category will help native speakers find the category. --Jarekt (talk) 14:23, 31 January 2012 (UTC)[reply]
Thanks guys, that is my view as well but wondering what is the general idea. I think there are English names at least for all those museums and castles that I used in the example, even though not all of them have corresponding en WP article yet. I am actually actively involved in creating such articles but will take time. To alleviate multilingual issues and have the categories searchable in multiple languages, I've been using Sum-it-up to add descriptions and interwiki links to categories (see for example Category:Dacia). But I find the task terribly redundant and repetitive. Can bots like User:MerlIwBot do this for each category and gallery, since articles and their leads in multiple languages appear/change all the time? It currently does it for interwiki links which are also followed and generated by Sum-it-up.--Codrin.B (talk) 15:53, 31 January 2012 (UTC)[reply]
I personally find this guidance to be a major problem in making Commons truly multilingual. We have several contributors on ro.wp which say they don't use commons for pictures because they don't speak English. When you try to open up to more people, like it happened for Wiki Loves Monuments, this problem becomes much more visible.
I believe that each user should be free to use whatever language he wants for categories, just like it happens for galleries, with the local language prefered. The category-redirect method Carl described should work just as well from English to Romanian as it does the other way around.
I urge you to consider changing this guidance even before MediaWiki has support for this (as fixing that bug could take years)--Strainu (talk) 11:05, 1 February 2012 (UTC)[reply]
But that doesn't work. There are many cases where languages use the same word to mean different things; is Category:Magazine about supermarkets or periodicals? what about Category:Cat?--Prosfilaes (talk) 12:43, 1 February 2012 (UTC)[reply]
Strainu, I wish we could, but as Prosfilaes said, that is not feasible on the large scale. To some degree we already do it on a small scale: we do have about 60k category redirects, and many of them contain alternative spelling often used in different counties. However we can not mix all the languages and be able to maintain our category system, it is hard enough in English alone. As for people who do not speak English: we put a lot of effort into internationalization of our templates and ideally all categories would have interwikis and description in many languages. That way people without English skills can at least use search to identify existing categories. They can also use Galleries written in their language and they can find links from their wikipedias to Commons categories. It is unfortunate that although Commons have interwiki links to Wikipedia, wikipedia do not have interwiki links to Commons, and have to rely on templates like en:template:Commons category. The problem with those templates is that each section of an article can have such template (so there is no guarantee of 1 to 1 relationship) and that those templates are not maintained by the mw:Manual:Pywikipediabot/interwiki.py which is used for maintaining interwiki links. --Jarekt (talk) 03:02, 2 February 2012 (UTC)[reply]
Chinese Wikipedia displays category names in either Simplified Chinese or Traditional Chinese depending on settings. For example, zh:分類:美國 and zh:分类:美国 both mean the same thing and so they go to the same page. How they are displayed depends on your choice in a dropdown list. Wouldn't it be possible to do something similar with Commons? I assume that many categories would have overlapping names, but wouldn't it still be possible to fix something with the categories which don't overlap? Chinese Wikipedia mainly converts things algorithmically, but I think that there also is some way to specify a variant manually if the automatic handling doesn't work. --Stefan4 (talk) 12:50, 2 February 2012 (UTC)[reply]
Strainu -- I agree with Prosfilaes. Allowing multilingual categories (other than limited endonym use) without a very radical and fundamental change in the basic software setup would be far more likely to cause numerous disputes such as that which resulted in Category:Mélusines in heraldry being set up in opposition to Category:Melusines in heraldry, rather than leading to some utopia of internationalization. AnonMoos (talk) 17:09, 2 February 2012 (UTC)[reply]
And don't forget that for the many cities, border areas and countries that have 2 to 4 languages, the English rule is a blessing. --Foroa (talk) 06:55, 3 February 2012 (UTC)[reply]
For popes, emperors, gods, saints and some rulers, we tend to use the original latin name as the root category as those are more "international universal". --Foroa (talk) 06:53, 3 February 2012 (UTC)[reply]
I'd like to add a comment on choice of forum:
The question is about the most controversial category of language choices on Commons. This village pump is read mostly by those that have no problem working in English (others use village pumps in other languages) and I think answers here will be somewhat biased.
If the question had been asked on Commons talk:Language policy, on the other hand, it would have been answered by people interested in language use of Commons, and support for using local names would probably have been stronger (still with a bias, as policy is mainly written and discussed in English).
For categories about things, yes we use English when there is an established English word. For local names, especially less known places, some use a local language, some use English. There is no policy or even guideline discussing the border line cases - because there is no consensus.
I just noticed that an edit I made was tagged with "manual deletion request by new user" as if that is something to be alarmed about. I have a couple questions about this:
Do I meet the definition of a new user here? I registered nearly two years ago and have made several hundred edits and uploads.
There was a speedy deletion tag on the image, I followed the directions on the tag itself for how to contest a deletion, and found that the software tried to get me to do it the automatic way anyway, and then I got tagged as if it was a problem. Shouldn't that be fixed? Isn't there some way to integrate that functionality into the template so it is more user friendly and doing what it says to do doesn't bring up all these bells and whistles?
It is something to be alarmed about. You did it wrong; you failed to list the DR properly on the deletion request page. It's not something to be ashamed about, but it's the reason the automated procedure was made and doesn't happen when it's used.--Prosfilaes (talk) 06:04, 31 January 2012 (UTC)[reply]
Disambiguation category?
Yesterday I created Category:The Hiker for installations of the statue by Newman. Then I discovered that there's another, equally well-known statue of the same name by Kitson. The first step I took was to create separate categories: Category:The Hiker (Kitson) and Category:The Hiker (Newman). But what to do with Category:The Hiker? It shouldn't be deleted, because it seems likely that others may make the same mistake I did. I also don't think it would be appropriate to redirect (soft or hard) to one or the other, because it can refer to either. Is there a way to make a disambiguation category, or some sort of double soft-redirect? For the time being I've just left an explanatory message linking to each of the other categories. cmadler (talk) 14:14, 31 January 2012 (UTC)[reply]
I would recommend against adding such a thing to HotCat: the functionality desired is completely different, and Commons-specific. HotCat is for changing and adding categories, and it's being used on many wikis, even on non-WMF projects. This new functionality is a special-purpose hack for one template existing only here at the Commons, and the desired functionality is just removing the template in one click. That's completely unrelated to what HotCat does; the desired functionality could be implemented easily in a completely separate script. Lupo20:13, 2 February 2012 (UTC)[reply]
I've recently created this. I'm trying to get the photos just right, so I cropped the images of the XL-R and Z-R at the bottom of the page. However, now they appear "stretched" in the thumb, which is bad.
I suspected the images would keep their aspect ratio after this change, appearing the same width in pixels, but being slightly taller. Is that understanding not correct?
to WP Commons and entered it into a WP aticle. For some reason it has come up rotated 90 degrees and I don't know how to rotate it back so the image can be seen properly. I wonder if anyone could do this job for ame please and/or let me know how to do it myself? Many thanks John E. Hill (talk) 23:47, 1 February 2012 (UTC)[reply]
I have added a rotation request to that page. This means that the image will be rotated by a bot in less than an hour. In the future, try to save the image in the correct orientation on your computer. Some programs, and in particular most Microsoft programs, often display images with the wrong orientation. As a rule of thumb, if it looks correct in your digital camera but incorrect in any Microsoft image program, do not attempt to rotate the image. The image is already correct and the fact that it looks wrong in the Microsoft image program is due to a bug in the Microsoft image program. There is more information about this at COM:ROTATEFIX if you want to know more about it. --Stefan4 (talk) 23:59, 1 February 2012 (UTC)[reply]
Thank you so much. The image was correctly rotated on my computer so I just assumed it would be O.K. after uploading. Looks like I have more to learn. But thanks again and all best wishes, John E. Hill (talk) 03:30, 2 February 2012 (UTC)[reply]
Hard to tell without knowing more about them than I can discern from the images. Maybe en:Sidewalk cafe? They don't look like en:Beer gardens from the photos, although there's certainly beer drinking happening. Could be en:Patio, although in the US at least that tends to carry more of a residential connotation. cmadler (talk) 15:00, 2 February 2012 (UTC)[reply]
It is very common on the continent and certainly in warmer countries for restaurants, bar and other drinking places to have seats and tables on the street. On warm sunny days, clients dont want to be inside. In most countries such places have pay extra taxes to use the street for tables and chairs. Smiley.toerist (talk) 19:15, 2 February 2012 (UTC)[reply]
Language issue on Special:Upload&uselang=daownwork (and others) and auto-add category on upload from Danish language upload form
On the Danish Wikipedia there currently is a suggestion to replace the current 'Upload file'-link in the sidebar with a link to either Commons:Upload/da or Danish language own work. This has thrown off two issues, which I'm not quite sure where to address:
It has been proposed that files uploaded using the Commons:Upload/da, the Danish language own work or a new custom form, have a special category (alternatively a template - i.e. similar to {{ImageUpload|basic}} when using the basic upload form previously) added. I would have assumed Commons:Redesigning the upload form or User:Pfctdayelise/Manual:Uselang hack would describe that - but again I didn't manage to find anything :( Is this possible somehow?
The first was a wrong configuration; I have fixed it now. It may take up to 24h until the fix becomes effective due to the way the MediaWiki software caches its interface texts. The second is currently not possible. However, why would you want to have such a marker category at all? Maybe an alternative approach might be a specially configured upload wizard? Maybe it's possible to use the "upload campaign" feature to customize the wizard in ways that might be acceptable to your needs? Lupo20:41, 2 February 2012 (UTC)[reply]
First: Thank you for fixing the configuration-error :)
Second: As I'm not an administrator on Commons, I don't know if upload campaign could work, but I'll encourage someone on DaWiki, who is also an administrator on Commons, to look into this so thank you for the suggestion :) The reasoning for this, is that most of the files uploaded "vetted" by someone with Danish language-skills, as they have a high error-rate (lack of license, copyvio's etc.). Of the current last 20 uploads (covering the time back to 17 January 2012, 11 have been deleted for being clear copyright violations, and of the remain 9, for 3 of the files, the uploaders are currently being "helped" so that they have correct and sufficient information. By adding them to a special category, it would be easier for Danish speaking wikipedians to identify and correct the issues in a helpful and leaning manner. In kind regards heb [TCE] 07:53, 3 February 2012 (UTC)[reply]
Adding multilingual descriptions to categories/galleries automatically
To alleviate multilingual issues and have the categories searchable in multiple languages, I've been using Sum-it-up to add descriptions and interwiki links to categories (see for example Category:Dacia). But I find the task terribly redundant and repetitive. Can bots like User:MerlIwBot and User:JarektBot do this for each category and gallery, since articles and their leads in multiple languages appear/change all the time? It currently does it for interwiki links which are also followed and generated by Sum-it-up. I think it would be a tremendous feature, and should be basically part of the same process. Note that I started initially this conversation at User talk:MerlIwBot#Adding also multilingual descriptions but then I realized that JarektBot also has similar capabilities, and this is more of a global discussion.--Codrin.B (talk) 19:27, 2 February 2012 (UTC)[reply]
I see that more and more people start to see the interest and are following. Before adding text descriptions by bot, we have to define a collapse rule. Categories with an intro in 270 languages is not very practical. A more elegant and maintenance-free solution would be the display of the initial paragraphs(s) when hovering over the interwiki links on the left. It would be great if the search engine would include the category IWs in its search, which it doesn't for the moment. --Foroa (talk) 07:09, 3 February 2012 (UTC)[reply]
I am not sure based on which settings, but in my system Category:Dacia displays a pull down box for the languages using Meta:Language select. It doesn't display descriptions in all languages unless you select "Show all" in the pull down box. This seems sufficient to me. I am missing something? --Codrin.B (talk) 15:17, 3 February 2012 (UTC)[reply]
For me is the main purpose of the explaining text to know what subject is covered by the category. I don't need all the links in the often long text generated by Sum-it-up. Without shows a "cleaner" text. If people want more information they can use the interwiki links on the left. Wouter (talk) 16:09, 3 February 2012 (UTC)[reply]
To me, Category:Dacia shows all texts in all languages, which is probably a bug or maybe related to a show all that I used on a previous selection and that stays on. Anyway, I think that in all cases, the English reference text should always be displayed for reference and the description in the local languages(s) where applicable. Nowadays, I bother rarely to include texts in more than 2 or 3 languages, except where there are many terms in many languages, such as in Category:Mbira and Category:Pedal cars so that they are included in the search engine database (category interwikis are never included in the search). --Foroa (talk) 18:19, 3 February 2012 (UTC)[reply]
I am curious to know what setting enables/disables (or rather collapses) the other languages. If you find out, please let us know. I looked in my preferences but couldn't find it. For me it is always collapsed, showing English. Sum-it-up can indeed sometimes generate longer descriptions, but id depends on the leads that people create. Over time, the source articles get copy edited and end up with better leads. A reason why we need a bot to run this on a schedule. And yes, sometimes I had to shorten the generated descriptions myself. But overall, I think it is highly valuable to have that multilingual text since it empowers users to find the information with search engines. You can click on the links to the left, but someone searching in Japanese will never find an English named category, unless these descriptions are added. And if we can reliably collapse all languages and show English by default, it is all we need for a nice solution.--Codrin.B (talk) 18:03, 4 February 2012 (UTC)[reply]
I've been using sum-it-up for quite some time (do check out the gadget). I even used it for batch created categories. Some improvements:
Such improvements would be nice - as would fixing the annoyance that the tl.wp doesn't translate to template:tl, but to template:tgl, which sum-it-up doesn't know! But really, if we're going for improvements, one thing which would be worth thinking about is whether we couldn't persuade the source Wikipedias to provide a custom 1 or 2 line summary (like persondata), stripped of ref tags and images which don't translate to the Commons summary, and hopefully more stable. (If the custom summary isn't available, the bot/script can always fall back to the status quo.) Rd232 (talk) 18:18, 5 February 2012 (UTC)[reply]
February 3
Miscoded Region locations in Geocoding templates
My mistake, I didn't realise that the "region" field used ISO-3166 in these templates, so some of them have "region:UK" instead of the correct "region:GB". There may be a few hundred but is there a bot that could go though and substitute these for the correct version? Cheers. Rodhullandemu (talk) 00:19, 3 February 2012 (UTC)[reply]
They aren't my uploads, they are category maintainance. Paradoxically, when I was an Admin on en:WP, I probably considered more requests for AWB use than any other admin over a year or so, without using AWB myself- it looks like I may now have to look at that as an option. Thanks. Rodhullandemu (talk) 02:31, 3 February 2012 (UTC)[reply]
Does somebody know if that is a bug or a feature? http://commons.wikimedia.org/w/index.php?title=File:AaatestSonnepalmenstrand-portrait_new.jpg&action=history The page is upload=sysop protected and it works (I cannot upload with my test account). But the testaccount can revert to another file version. This is pretty stupid since I thought it isn't enough at upload edit wars to upload protect (COM:P should be adjusted then)... Also that is a bad choice for high-visibility files which have more than one version. Mediawiki displays the reverts as "uploads" - but apparently doesn't apply the protection status. I would have assumed that it protects against that reverts. First because it is useful, second because mediawiki titles the reverts as uploads in the logs Asked in Wikimedia tech channel on IRC but got no answer. --Saibo (Δ) 00:54, 3 February 2012 (UTC)[reply]
Try reverting File:Testfile-bidgee.jpg in your test account. If it allows you to move it in the test account, try the Edit protection. If all fails then someone needs to fix it as it is a rather big problem that revert wars can continue. Bidgee (talk) 01:18, 3 February 2012 (UTC)[reply]
I think you are correct, so I removed the metatemplate from Template:Monthbyyear. Month categories can be further divided by date, by country, or by something else. But it is not neccessary to always do that. And I think there may be files that does not fit into such subdivisions. /Ö10:24, 4 February 2012 (UTC)[reply]
As a native speaker, they are exactly equally correct. There is one subtle difference, in that when one is talking about the structure of a particular American university, one speaks of its "school of arts and sciences", "school of engineering", etc. and in that context one would almost always say "school of medicine" because of the parallelism. Conversely, one would say "he went to medical school at the University of Washington", but not "he went to the school of medicine at..." (though this doesn't apply to "he graduated from" or "he attended", which can use either). But that's about it. Equally valid article/category names. - Jmabel ! talk09:20, 4 February 2012 (UTC)[reply]
Is there any category we can give to either smaller versions or alternate formats of the same file? I know it's a derivative, but that's not very specific.
I recently needed a PNG thumbnail for a JPEG so that the white background could be removed, as is typical usage on the English Wikipedia--said images are usually tagged {{Should Be PNG}}.
--Trlkly (talk) 18:26, 4 February 2012 (UTC)[reply]
WebApp for Picture of the day / POTD
I developed a Webapplication which displays the current POTD from commons in a (imho) bautifull way. I designed it especially for tablets, it supports iPad, Android and any other recent browser. It tries to embedd nicely into the browsers on these devices by supporting swiping. The whole application is open source and non commercial. I wrote it mainly for myself, but is there a place where such applications can be promoted? URL is http://potd.dbruhn.de. On the IRC-Channel someone suggested adding it next to our current "by email"/"RSS feed". Perhaps someone wants to discuss this issue! Thanks! -- Theomega (talk) 19:30, 4 February 2012 (UTC)[reply]
There are some people trying to categorize old uncat files (including me), but it's a long way. There are thousands of images with unclear rights and sources, not to talk about all those pics and diagrams and portraits which only the uploader may know details about. I guess most of them could go to DR without bothering, but that would also mean a big overhead and admins work. And there are always some pearls in the trash that can be used in wp articles, worth to be sorted out manually. OK, you can go the fast way and do one category per image, like "Unidentified ..." or "Diagrams in ..." to get it categorized, but that's not really satisfying at all, because those categories should also be cleaned, not filled up. I really don't know what the best solution should look like, to get rid of those uncat images. I did about 10k old files in the last months, but with each stone you take away from the bottom, 10 new grow on top.--Funfood␌08:44, 6 February 2012 (UTC)[reply]
It would be already a great help if a bot could categorise them per subject or country. It is much more efficient to categorise in a limited context and people tend to be more motivated to discover images pertaining to their country or area of interest. Even categorisation per language would already help. Frankly, if I have to process tens of images described in Hebrew, Arabic, Chinese, Hebrew, ..., it takes much more time and one gives up quicker. --Foroa (talk) 11:44, 6 February 2012 (UTC)[reply]
This RfC proposes a specific copyright review process for public domain works, in order to ensure our works are in the public domain in both the US and their source country as required by Commons:Licensing. Feedback welcome - please respond at the RfC. Dcoetzee (talk) 14:03, 5 February 2012 (UTC)[reply]
The economic potential is enormous, see http://www.nytimes.com/2009/10/21/business/global/21iht-renwave.html?pagewanted=all, and I think the main point of my comment is that Commons needs to set policy for depositing images that have no source code in the PD. We are not talking Photoshop, folks. These are custom programs designed to produce one (possibly a few) images, and it is the programmers, not the Uploader, whose work has been used without attribution. Worse yet, without source code the image (simulation) might be completely wrong. It then goes into the encyclopedia and evades NOR. Doug youvan (talk) 16:41, 6 February 2012 (UTC)[reply]
Question Throwing in a question for {{PD-1996}}: Requirement is stated 1) not simultanously published 2) and published before 1978 without compliance with U.S. formalities 3)and PD in country of first publication at URAA date. My question is about 2). Published in the U.S. or published abroad without compliance? --Martin H. (talk) 13:29, 21 January 2012 (UTC)
Oppose It would be nice to have information for every country for each file in a machine readable form. However, this proposal here is only for US. The proposed license tags are overly complicated (remember that uploaders even have problems to understand the meaning of "70 years pma" (which does not require more than 70 years after creation but after death) and nearly no-one will understand this system; especially if it uses some template parameters which need to be set. I saw the file pages you created in your last bot run (which you have reverted): much more than one screen page full of public domain (we are not talking of license templates with restrictions...) tags? Ugly and scaring away everybody who looks at (probably the reaction: they are crazy). 
Support Copyright status in the US is relevant information about files and this information should be checked. Any categories, lists or templates that could help us to check it are welcome. A few reasons:
Comment It should be noted that most if not all translations of {{PD-old}}, and {{PD-old-auto}} have a license text that reads: "This includes the USA and all countries with a copyright term of 70 years...". And there are generally no warnings that a PD-70 license alone is not sufficient. We might want to fix that. De728631 (talk) 18:42, 27 January 2012 (UTC)
.jpg&action=edit&redlink=1){kind=link}
Done. You may use tools:~luxo/derivativeFX/ in future for derivative works. Otherwise it is always the best to copy the licenses and to mention the authors of the works the new one is derived from. But in general, SVG-translator could add such an option. We should ask jarry. -- RE rillke questions? 22:27, 29 January 2012 (UTC)
![[2]](https://commons.wikimedia.org/w/index.php?title=File%3AElisa_Gabrielli_on_Christmas_Eve_2008.jpg&action=historysubmit&diff=62377075&oldid=62173680){kind=link}
Info It would be hidden, like other versions now. --Petrus Adamus (talk) 10:25, 1 February 2012 (UTC)
Weak support. {{Information}} was designed to appear simple and without much "magic" feel, the automatic conversion of exotic strings may be a bit confusing (all the more as it works for " Eigenes Werk (own work)" but not for "eigenes Werk". Hopefully, more and more uploading tools will use the correct {{Own}} making {{Parse source}} unnecessary. On the other hand, a bot should convert existing pages so that internationalization is not lost.--Zolo (talk) 11:46, 30 January 2012 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. 01:17, 3 February 2012 (UTC) 
