Commons:Village pump/Proposals/Archive/2015/08

DR for out of scope files

A proposal has been made to change the DR procedure of out of scope files. Its proposed at Commons_talk:Deletion_policy#Categorizing_out-of-scope_files where your opinion is requested. Posting this note here as not much traffic goes to those talk pages. §§Dharmadhyaksha§§ {Talk / Edits} 09:53, 5 August 2015 (UTC)

Bureaucrats removing admin rights

Over at en:wp, bureaucrats are able and permitted to desysop users in a few specific cases, all of which have parallels here: when self-requested by the user in question, when the user in question has been inactive for a certain period of time (parallel to Commons:Administrators/Inactivity section), or when consensus is in favor of removal (parallel to Commons:Administrators/Archive/Successful requests for de-adminship). Is there any good reason why our bureaucrats shouldn't be able and permitted to do the same thing? As is, removals due to self-request and due to inactivity are uncontroversial (a bot could do the inactivity removal!), and three of the last four successful requests for de-adminship were closed by bureaucrats (the exception was by a non-bureaucrat, following the admin's self-request for removal) — if we trust them to assess consensus at such a discussion, shouldn't we trust them to implement the decision? Steward Billinghurst has told me that such a change would require a Phabricator request, but it's something that would readily be performed if we got consensus here in favor of it. If you're interested, you may wish to read a relevant en:wp discussion from four years ago (bottom section of the page).

With this in mind, the official proposal: should bureaucrats be enabled and permitted to remove administrative rights when self-requested by an administrator, when a request for de-adminship has succeeded, or when an administrator has become inactive? Nyttend (talk) 02:59, 6 August 2015 (UTC)

Thanks for starting this discussion, I was surprised to find out quite recently that enwiki bureaucrats do this. I'll recuse and leave it to non-crats to discuss. --99of9 (talk) 04:32, 6 August 2015 (UTC)

I think this should only be changed on this project if there is a realistic requirement for it and the comparatively lightweight desysop process is insufficient (noting that en.wp had quite different problems to Commons around this). Have there been past cases where this was needed? --Fæ (talk) 05:51, 6 August 2015 (UTC)

I don't think that it will simplify anything. Unless all stewards are busy in real life and will not perform requested action for weeks. --EugeneZelenko (talk) 14:01, 6 August 2015 (UTC)

At a similar discussion at another wiki (meta?) I said that I generally support this for all wikis. There is no actual need for this for Commons, though, as desysops don't happen really often. --Krd 14:15, 6 August 2015 (UTC)

I'm inclined to agree with Krd. I'd generally support the idea however it happens so rarely I don't really think it is worth worrying about. There is a process and stewards will act on the decisions of the community. --Herby ^{talk thyme} 14:18, 6 August 2015 (UTC)

I am generally in favor of the bureaucrats doing this but I don't really feel strongly either way for this project and I am fine with whatever decision the Bureaucrats want to make on the issue. If we have bureaucrats that want to do this, the precedent has been set, so we may as well use it. On the other hand, I do not see a real need for this either. Requests to the stewards for action is generally fast and its rare this project requires a desysop anyway. As I stated before, just because ENWP does something doesn't mean we need to do it here. This makes a lot more sense for ENWP to do because they are a much bigger project, have a lot more problematic admins and a lot more problems to address. Reguyla (talk) 17:13, 6 August 2015 (UTC)

I don't think we have so many request so stewards are bothered every month or so. Occational desysop request, two regular inactive desysopping per year. Not that much of stuffs. — regards, Revi 17:23, 6 August 2015 (UTC)

@99of9 - I hadn't realised Commons bureaucrats couldn't do this!
I would strongly support bureaucrats having this ability on commons (of course, as an enwiki bureaucrat I am used to the idea that bureaucrats do -sysop). The point about project scale makes sense, but on the other hand I think every project should be as self-governing as possible. Commons has sensible bureaucrats, who can be trusted with the extra ability. I think they should have it - it's not very time consuming to hold a quick discussion and, if the idea is generally supported, for a developer to enable this. WJBscribe (talk) 10:57, 7 August 2015 (UTC)

Generally I agree: bureaucrats should be able to do that. But actually the current situation also does not create problems, so this is not an important issue. Taivo (talk) 11:42, 7 August 2015 (UTC)

I generally support, but there is no hurry in implementing this.--Ymblanter (talk) 17:43, 7 August 2015 (UTC)

+1 --Steinsplitter (talk) 17:44, 7 August 2015 (UTC)

• I strongly disagree with the idea that a project is improved by doing without the stewards. The standard permissions are good. --Nemo 18:12, 7 August 2015 (UTC)
•  Strong support -- I know 99of9 will probably smack me with a mackerel for expressing support so soon :P , but I don't think there is a reason to mistrust our functionaries with removal of adminship. We have a twice-annual inactivity review, which saw 12 de-sysops in March 2014, 10 de-sysops in September 2014 and 10 admins de-sysopped in March 2015. So that is 32 times in 18 months when a burocrat could have removed the admin bit on inactivity grounds and 4 times when they could have done it because of de-sysop requests in 2014 and 2015. I think there is plenty there for burocrats to do instead of stewards, especially given that not all of them are global renamers (a function transferred to Meta) and we have a gang of new burocrats elected recently. So I say YES to giving them this right. P.S. If you haven't done so, come along and join the debate about admin activity requirements. Green Giant (talk) 21:07, 7 August 2015 (UTC)

Wikimedia Commons article traffic statistics for categories and for individual images

Translation of my proposal with translate.google.de:

In my view it would be very nice if there would be a "Wikimedia Commons article traffic statistics for categories and for individual images" (example: http://stats.grok.se/de/latest30/Allgemeine_Erkl%C3%A4rung_der_Menschenrechte)

Many greetings

--Molgreen (talk) 17:11, 16 August 2015 (UTC)

The German original of my proposal: Aus meiner Sicht wäre es sehr schön, wenn es für Kategorien und auch für einzelne Bilder eine Abrufstatistic wie in der Wikipedia geben würde (Beispiel: http://stats.grok.se/de/latest30/Allgemeine_Erkl%C3%A4rung_der_Menschenrechte) Viele Grüße

--Molgreen (talk) 17:11, 16 August 2015 (UTC)

It exists yet, for example: http://stats.grok.se/commons.m/201508/Hauptseite --Steinsplitter (talk) 17:14, 16 August 2015 (UTC)

Direct file views aren't included in stats.grok.se as far as I know, but they are available in a raw form - http://dumps.wikimedia.org/other/mediacounts/ Bawolff (talk) 07:02, 24 August 2015 (UTC)

Actually, direct file views are available (select the file on Commons in desktop view, click on the history page, and you can select the pageview stats). That said, most people want the indirect page views, which is the number of times the file has been viewed on Wikipedia and other projects (in all language versions). This is a bit like trying to collect page views for Wikipedia pages with lots of incoming redirects - you need to collect each instance of page view type separately. It can be done using the global usage tool, but is quite tedious. Jane023 (talk) 07:10, 24 August 2015 (UTC)

By direct view, I mean any view of the image (not the image description page). i.e. The number of hits the url at upload.wikimedia.org gets. That would include any time anyone viewed the image, no matter what page it is embedded in. The new mediacounts dump provides this, but nobody's made a pretty interface for it yet. Bawolff (talk) 16:03, 27 August 2015 (UTC)

Legal threats and blocking

Anyone object to this addition to the blocking policy? I self-reverted immediately after adding it; this was easier than attempting to explain the wording that I want and the location where I'd like to see it.

Rationale — I found such a threat and was curious how we handled them, since I routinely see en:wp using its legal threats policy but had never seen such a thing here. Not finding anything in the blocking policy, I ended up searching a while before I found the topic being addressed. There being lots of similarities between en:wp and us, addressing this difference seems helpful, and this difference being minor enough that it doesn't belong at Commons:For Wikipedians, I figured it would be helpful to include for future reference. Thoughts? Nyttend (talk) 00:18, 29 August 2015 (UTC)

I disagree with the outcome of the previous discussions – there was also Commons talk:Blocking policy/Archive 1#Legal threats – but I do agree that the prevailing position should be documented. —LX (talk, contribs) 08:41, 29 August 2015 (UTC)

Hi, Actually "Legal threats" can be a reason for blocking. As the previous discussion mentioned, there are 2 different situations (copy-paste from Jim):

• a threat of having a lawyer issue a takedown notice to Commons or of suing WMF to force the takedown of an image and
• a threat of suing an individual editor or Admin for any reason.

The first is OK, the second is not. Regards, Yann (talk) 10:11, 29 August 2015 (UTC)

I disagree. The second can be okay as well. If someone is harassing or threatening me, I would consider suing. In this case I am the victim, why should I be victimized even more by being blocked? --Sebari (talk) 15:17, 29 August 2015 (UTC)

Will you then sue the person who blocked you? Legal threats have a huge chilling effect, and induce a lot of stress. If you can't resolve things within Commons, then you probably shouldn't be here.--Prosfilaes (talk) 22:24, 29 August 2015 (UTC)

If you think I should not sue someone who, to give an extreme example, issues death threats, you should most definitely not be here. --Sebari (talk) 08:44, 30 August 2015 (UTC)

I think anyone who issues death threats would be blocked as well ;-) If something warrants an actual lawsuit, go right ahead -- actually filing a real lawsuit against someone should not be grounds for blocking. But threatening it as an escalation of an argument in discussions here is a different matter. That has been the policy on en-wiki for quite some time. If someone is being abusive, there are other avenues to follow -- it should be pretty obvious for a situation which would legitimately be grounds for a lawsuit. I would agree though that DMCA threats are not the same and are OK -- that is copyright owner's right. In looking at the original proposal, that did seem to require a user to cease editing if they did file an actual (non-DMCA) lawsuit -- I don't think I'd support that. Barring discussion of the lawsuit itself maybe, but not all editing. Carl Lindberg (talk) 15:46, 30 August 2015 (UTC)

Can we offer any good example of someone who should be issuing a takedown notice instead of just putting it up for DR? The first is just as much a sign of problems as the second.--Prosfilaes (talk) 22:24, 29 August 2015 (UTC)

Hi, It would probably in case when a DR is closed as kept, and for other reasons than copyright. Regards, Yann (talk) 00:02, 30 August 2015 (UTC)

•  Comment en:Wikipedia:No legal threats is very clear: "That users are involved in a legal dispute with each other, whether as a result of incidents on Wikipedia or elsewhere, is not a reason to block, so long as no legal threats are posted on Wikipedia." Taking legal actions against another person is one's basic right and we need not police it. But a threat like "I will sue you unless you stop" should not be posted on wiki. That's all. We need not bothered about take-down notices; it is a matter between WMF and the person. It is a common practice in OTRS too (if I remember well). Any mail with a threat tone will be forwarded to legal than replying by our volunteers. But we can prohibit posting taken-down threats like "I'll file a take-down unless you delete it" on wiki. (Sebari has the right to sue any; but should not make such threats on wiki.) Jee 02:27, 30 August 2015 (UTC)
  • If it is worded like this, it is fine. --Sebari (talk) 08:44, 30 August 2015 (UTC)

SVG help button

Prototype

Hello!

I'm trying to improve usability of SVG contribution to Wikipedia. Since SVG is troublesome and buggy as I explained here, I wanted to improve this by adding a "SVG help" button to file description pages in case of SVG. Additionally it will only be visible if a loggedin user is visiting this page so it will have a small impact to the majority of visitors on commons. Since it is overall a simple task I've hacked a prototype of it: User:Menner/svg-button.js. It is a button with a pull down menu and four options to choose.

Can such a script be embedded on Commons by default? --Menner (talk) 16:47, 22 August 2015 (UTC)

My suggested prototype has evolved and I would call it ready for productive use. --Menner (talk) 07:14, 19 September 2015 (UTC)

Discussion

• I think it should be implanted in MW directly instead of loading it via resource loader. But i think it will take ages until the wmf is implanting this in mw, so js would be a solution. The script does not support i18n. --Steinsplitter (talk) 09:54, 23 August 2015 (UTC)

Its too Wikimedia specific to be implemented in MediaWiki generically. Its possible that it could be implemented as a php extension that's only installed on wikimedia wikis (Or included in WikimediaMessages extension), but honestly, its probably a lot easier just to do in js. Bawolff (talk) 07:06, 24 August 2015 (UTC)

Obviously there is no general refusal of such a SVG button script. How can I start the vote/discussion to add this on commons as default by every user? --91.6.67.6 06:13, 31 August 2015 (UTC)

Hello? How will this proposal proceed? --Menner (talk) 19:14, 7 September 2015 (UTC)

@Menner: The script still does not support i18n. --Steinsplitter (talk) 10:03, 19 September 2015 (UTC)

@Steinsplitter: The help pages and the rest of the technical web are neither fully i18n. What kind of i18n do you request?--Menner (talk) 11:55, 19 September 2015 (UTC)

There should be a way to translate the makepLink. --Steinsplitter (talk) 11:59, 19 September 2015 (UTC)

i18n happens before calling makepLink and not everything going into it needs translations due to given Terms. -- Mennerk aka 91.63.190.207 14:03, 19 September 2015 (UTC)

But only the links are i18n. Not the text of the link? --Steinsplitter (talk) 14:14, 19 September 2015 (UTC)

When there is a link destination with translation then the text of the link is also i18n. -- Menner (talk) 07:20, 20 September 2015 (UTC)

Also I strongly oppose the current position of the button – already the crappy MediaViewer button is annoying the hell out of me. File description pages are for the file description. They should only contain specific information on the current file. Everything else is navigational and should therefore go into one of the navigation bars (possibly adding it to the #filetoc would beacceptable like the Stockphoto gadget does). Otherwise we're pushing down the information people want to actually see when visiting a file description page! --Patrick87 (talk) 11:11, 19 September 2015 (UTC)

The button is only visible to loggedin users and further only on file description for SVG files. I'm not pleased with #filetoc. The Add note and the Media Viewer can go to the no ones watching because it is useless area. They make every file descriptions popping around while loading. -- Menner (talk) 11:55, 19 September 2015 (UTC)

That's what I'm talking about! If every extension/gadget just carelessly adds buttons below the preview image sooner or later we have more buttons on our file description pages than we have file descriptions.
Since you basically seem to agree with my I'm afraid I have to ask though: Why treat your button differently than the others you dispise? If a button is useful or useless depends on the specific user. I (logged-in ) would not need the SVG help button – I know my way around SVGs – and I would think of it as "useless area" as you think of the MediaViewer/Add Note buttons as useless area. Other users certainly will profit from those buttons. Therefore we have to find a way to include them seamless into the navigational areas given to us instead of trying to judge by usefulness which is highly subective as pointed out above. --Patrick87 (talk) 12:41, 20 September 2015 (UTC)

I'm asking to treat the SVG button equal to other gadets. If previous things got that place I have the same rights. I even think the other (especially add note) are less important. Just look at grok.se how many people already find their way to the help page although it is "hidden" to the common uploader. It has nearly as much visits as Commons:Upload help according to grok.se which is very prominently placed at the Upload Wizard.

I could imagne to further limit the visibility of the SVG Button to the last uploader if there is support to gather last uploader.

-- Menner (talk) 16:57, 20 September 2015 (UTC)

"I'm asking to treat the SVG button equal to other gadets.": phab:T113177, MediaWiki talk:Gadget-ImageAnnotator.js#Position_of_the_.22Add_a_note.22_button. I for my part surely want to treat them equally . That other Extensions/Gadgets got their button there does not mean that was the right decision... --Patrick87 (talk) 17:27, 20 September 2015 (UTC)

I see options to reduce visibility of SVG button to the last uploader. I'll choose the best and implement it after the button gets accepted. I don't see other area as a option. Tools are gathering already there and users aren't used to look elswhere for that reason. Cleaning-up MediaWiki is not the job of a Tool with very little visibility. -- 2A02:810D:2C40:13F8:4848:9B95:A258:6F6C 17:49, 22 September 2015 (UTC)

Special:UnusedCategories

The page Special:UnusedCategories isn't very useful the way it is because category redirects are there listed too which are of course unused by this point of view. Therefore imo it would be better if this page didn't contain category redirects. --Achim (talk) 10:10, 1 August 2015 (UTC)

Achim I agree and so do a lot of other people. There has been several requests to fix this but its not very high on the developers list so it may be a while. Reguyla (talk) 21:31, 30 August 2015 (UTC)

Problem is that MW doesn't really understand the commons notion of a category redirect. If they used normal #redirect syntax, this would be trivial, but that's kind of broken for categories. Bawolff (talk) 09:38, 12 September 2015 (UTC)

Are there any reasons why a category page can't have both? #redirect for mediawiki (not only for this but for search functionality) and {{Category redirect}} for stuff like HotCat? sısɐuuǝɔıʌ∀ (diskuto) 09:34, 19 September 2015 (UTC)

Yep. A hard redirect will remove it from Special:UnusedCategories, as well as assist in search functionality, without breaking anything, near as I can tell. Should we have a bot add these? sısɐuuǝɔıʌ∀ (diskuto) 08:18, 27 September 2015 (UTC)

What about disambiguation categories? --Zhuyifei1999 (talk) 13:35, 27 September 2015 (UTC)

Hmm, good question. We could modify {{Disambig}} so that every disambig category contains itself, and change the counter of Category:Non-empty disambiguation categories from more than 0 to more than 1. I don't think that'll break anything else? sısɐuuǝɔıʌ∀ (diskuto) 17:47, 27 September 2015 (UTC)

Creation of PD template for Korea between 1910 and 1945

I found an old korean picture from the 1930s. Discussing the actual copyright status in COM:VPC, I propose to create a PD template for korean pictures (in my sandbox) taken/published between 1910 and 1945 (when Korea was occupied by Japan and before its splitting in the two current States), in similar way as {{PD-China}}.

For now, the tag shows texts indicating that the work is in the PD in the three countries, in Japan, the Republic of Korea and the Democratic People's Republic of Korea, and the three license tags {{PD-Japan-oldphoto}}, {{PD-South Korea}} and {{North Korea}}.

How can we improve this license tag? and more important, is actually viable to implement it? Please discuss, is very important to the several korean works unproperly licensed. --Amitie 10g (talk) 03:45, 26 August 2015 (UTC)

The tag should not say "taken" -- if photos were published elsewhere, that becomes the country of origin, not one of the Koreas. Also, I'm not sure I would include North Korea here. It appears they were not a part of any copyright treaty until 2003, and their law is from 2001. I have no idea what that law did to existing works... If they retroactively restored everything, then they have 50pma terms which cannot be guaranteed to have passed yet. There are no provisions in the law that I can see about what to do with existing uses of previously OK-to-use works, which you would normally expect if protection was being created for existing works. So, maybe it only applies to works published 2001 and later. It may be a law more for show than actual practice as well, which means it's anyone's guess what their protection for pre-2001 works is. Really, using the South Korea tag is probably enough for Commons purposes, since it was at least simultaneously published there, and that country probably has the shorter term anyways. Could add Japan I guess too.Carl Lindberg (talk) 07:15, 26 August 2015 (UTC)

Well, then I'll remove the DPRK, leaving just RoK and Japan, but I still considerig to keep the term taken, because is part of the {{PD-Japan-oldphoto}}; both term may coexist depending the date of making and publishing, IMHO. --Amitie 10g (talk) 09:14, 26 August 2015 (UTC)

No, Carl is correct, "taken" should not be in the summary at the top; this template is only appropriate for works that were published between 1910 and 1945 in occupied Korea. Works that were created between 1910 and 1945 in occupied Korea but published anytime or anywhere else should use the copyright template for where they were published (since the Berne convention defines the country of origin as where something was first published). For example, imagine a photo taken in 1940 in occupied Korea by a photographer who died in 2010 but first published in 2006 in the U.S. Such a photo could not use your proposed template as the photo's country of origin would be the U.S. and since the U.S. is pma+70, it's copyright would not expire until 2080. —RP88 (talk) 20:00, 26 August 2015 (UTC)

Whm, Carl is right, considering the overlapping the conditions of the both the Copyright Law of Japan and the RoK. Therefore, I added at the bottom the following centense

«This license applies only to works created in Korea and first published in that country. For works first published outside Korea, please use {{PD-South Korea}} only.»

Therefore, this template applies only for works first published (and created according to the Japan Copyright Law, but that term is somewhat questionable) in Korea and the author died after 70 years. How we can deal with the both Copyright Laws and the copyright status? --Amitie 10g (talk) 21:03, 26 August 2015 (UTC)

You should never use PD-South Korea for works first published outside Korea. Works first published in country X should use the appropriate rules for that country.--Prosfilaes (talk) 23:26, 26 August 2015 (UTC)

Whm you're right. Then, I changed to the country of the first publication instead. What about the prhase «applies only to works first published in Korea, and the author born in Korea and died after 70 years»? --Amitie 10g (talk) 04:38, 28 August 2015 (UTC)

Administrators and trusted users: After one month of this proposal and discussion started, please confirm if this license tag is correct, to be moved to the main Template: and start its use. --Amitie 10g (talk) 03:01, 28 September 2015 (UTC)

• The template begins with this text:

This photographic work is in the Public domain in the Republic of Korea and Japan, due it was first published in Korea between 1910 and 1945, and the copyright expired according to the following:

All photos published between 1910 and 1945 are in the public domain in both Japan and the Republic of Korea, regardless of where the photograph was first published. The country of first publication identifies the source country (the country from which we require a country-specific copyright tag), but knowing the source country is not relevant for establishing the copyright status in Japan or South Korea in this specific situation. The template should warn users that Commons policy requires a different country-specific template if the photograph was first published outside the Government-General of Korea, though. --Stefan4 (talk) 15:39, 28 September 2015 (UTC)

Well, I followed your suggestions and I changed the text as follows:

• I replaced first published in Korea with published by a korean author, between 1910 and 1945.
• I replaced the second line (after the DPRK statement) with If the work has been first published outside of Korea, you should apply a country-specific license tag in addition of this license tag.

Shold be that enough? --Amitie 10g (talk) 16:18, 28 September 2015 (UTC)

Korean authors can publish things outside Korea and non-Korean authors can publish things in Korea, so that doesn't help. --Stefan4 (talk) 16:28, 28 September 2015 (UTC)

So, what you suggest? I'll keep just due it was published between 1910 and 1945, and the copyright expired according to the following in the first line. --Amitie 10g (talk) 17:12, 28 September 2015 (UTC)