Wikimedia Commons

Commons:Village pump/Proposals/Archive/2014/12

< Commons:Village pump‎ | Proposals

RfC: Removal of local OTRS-member user group

Per meta:Requests for comment/Creation of a global OTRS-permissions user group a global OTRS-members group has been created to make the feature usable on all wikis. Having this, the local user group is redundant and should be removed. Abuse filter 69 has already been modified to follow the global group, including the 5 bots (Wdwdbot, Faebot, JarektBot, RomaineBot, SteinsplitterBot) that have the local OTRS-members group.

All users that are currently in the group OTRS-member shall be removed from that group and added to autopatroller if not already covered by other user groups.

Related discussions: Commons:Village pump#Global OTRS members --Krd 16:59, 25 November 2014 (UTC)

  • @Jee: Managing the allocation of the OTRS flag locally does not have any influence over whether a user is an OTRS agent or not, but it provides us with an additional level of oversight over the actions of OTRS administrators: most flag additions and removals are requested publicly, and certainly all of them are logged openly in the user rights log, which makes it easy for the wider community to keep track of what's happening around OTRS flags. By removing the local group, we'd renounce this additional level of oversight in favour of a global process, therefore making it even murkier and more secretive than it is now. Moreover, and as I said before, having watched OTRS admins revoke Fæ's OTRS access — and I am aware I was the one who did the necessary flag removal — I have serious doubts in their judgment and their will to have this projects' best interests at heart, and I am very reluctant to have them manage the process without any sort of input or oversight from this project's community. odder (talk) 20:38, 26 November 2014 (UTC)
  • @Odder: Thanks for the explanation. I can understand the feeling; especially the lack of proper reasoning when removing one person. But in the current system, maintaining this flag is less useful as Yann and Stefan4 commented below. Now OTRS admins ask to add or remove this falg to our crats and they just act like a rubber stamp; no questions or decision making, which is a waste of time and resource. I will change my mind if a new alternate concept is presented. Jee 02:33, 27 November 2014 (UTC)

Discussion

Being late to this discussion and not being on OTRS, I wonder whether the (other) global OTRS-members will have the same rights on Commons as our local OTRS-members have. My rationale is that OTRS on Commons is likely rather special (requires knowledge and experience specific for the material/situations on Commons) and rather different from OTRS on Wikipedia or alike. Opinions? --Túrelio (talk) 20:36, 25 November 2014 (UTC)

Global OTRS-members = users with access to a permission (including permission-commons) queue. See metarfc. --Steinsplitter (talk) 20:39, 25 November 2014 (UTC)
Being assigned the new global group will give the users absolutely no special power, rights or abilities. It is mainly intended for identification purposes. All OTRS members with access to permissions queues (including photosubmissions) will be placed in the global group (and currently the group membership is up to date). Rjd0060 (talk) 22:16, 25 November 2014 (UTC)
Rjd0060 the issue isn't that the new global group will have any special powers, but the fact that the Meta OTRS admin team do not have Commons' best interests at heart; this was proven in the incident that I mention above when that team removed the OTRS access from Fae without giving him any reasoning. It was said that OTRS members need to have the trust of the OTRS admins, and that Fae did not have that trust. When Fae was banned on en.wp for a year, he had his OTRS access revoked. He was given it back in December 2013 (I think it was) and then had it revoked when he voted out of WMUK for wikipolitical reasons. No evidence of any abuse was ever shown, and in fact Fae was one of the hardest working OTRS agents, and a fantastic one at that. It was the OTRS team that decided to play political games with our requirements here on Commons, and I, and dare I say it others, do not trust Meta OTRS admins to do the right thing by the Commons community. I plan in the future on creating an RfC which will ask this community to be responsible for the entire "permissions" process. As Túrelio mentions Commons has unique needs given the nature of this project, and you and other OTRS admins do not have my trust AT ALL to do what is good for this community. russavia (talk) 05:43, 26 November 2014 (UTC)
So you are talking about the need of a new OTRS for Commons alone. May be a good idea; but this discussion has nothing to it. So start a new discussion for the possibility of it. :) Jee 06:45, 26 November 2014 (UTC)
No, it's not about that at all. The RfC on Meta was about Meta OTRS admins extending their authority over Commons. Whilst the Meta RfC was "global" in nature, each individual project needs to decide whether they want to opt-in or opt-out. The Commons community isn't aware of the circumstances of the removal of Fae's OTRS access. We should not be rash and simply rubber stamp anything relating to extending Meta authority over this project, when it is clearly evident that they will play political games in an attempt to isolate one our best OTRS agents that we have had on Commons. russavia (talk) 07:17, 26 November 2014 (UTC)
But what we can do now in the current system? Does keeping the OTRS flag for Fae while the rights removed by OTRS admins help him to access OTRS system? Jee 07:22, 26 November 2014 (UTC)
In the current system we can refuse to add OTRS to those people who are selected by Meta OTRS admins. Remember it is those admins who approved Fae's application in December 2013, and then without any complaints, and only with evidence of good work, yanked his access a few months ago because of a loss of trust. Under these circumstances, the loss of trust isn't in Fae, but in the OTRS admins themselves who gave back access to such a person in the first place. Commons is under no obligation to grant the OTRS flag to any individual; it's simply been done because that's the way it's always been done. In relation to the RfC on Meta, if the Commons community was aware of the circumstances of the revocation of Fae's access, it might very well have been a different result.
With the removal of the OTRS flag from this project, this project is in essence handing full authority for one of the core functions of Commons to a group of people who have shown a shocking judgement on granting an editor who they can't trust access to the OTRS queues. Because of their disgraceful conduct in isolating an editor on this project for NO reason, we need to have oversight of their actions on Commons, and by keeping the flag on this project we can say "NO" if we see them giving access to someone who shouldn't have it. With the removal of that flag on this project, this oversight is completely gone. russavia (talk) 07:36, 26 November 2014 (UTC)
Yes; we can deny a new member (or remove an existing member). But we have no alternate process (as now in Meta) to approve a new member. If I want to apply for it, I need to apply in Meta; not in Commons. That is why I suggest to make a new proposal to set up such a system in Commons. Jee 07:58, 26 November 2014 (UTC)
Meta is not its own project, Meta is a central place to handle common processes for all projects. --Dschwen (talk) 16:39, 28 November 2014 (UTC)

I was kicked out of the group. What should I do now?

My user permission was just removed. I know nothing about this RfC. There seems to be no documentation anywhere. What changed for me? Do I need to get another userright somewhere? What should I do or know in response to my userright being taken away? Krd, you started this RfC. What can you say about Dschwen removing this userright from my account? What does this mean? Blue Rasberry (talk) 17:11, 26 November 2014 (UTC)

You already seem to belong to the global OTRS group, so you should have the same permissions as you used to have. --Stefan4 (talk) 17:15, 26 November 2014 (UTC)
  •   Comment I think the rights was removed in a messy way. The discussion should have been closed properly, the OTRS-members should have been informed and the tools and "spam filters" should have been fixed.
But I do not think we should make a big thing about this. Shit happens sometimes and we all make mistakes. So I think we should just clean up and laugh about it when Dschwen buy us all a beer ;-) --MGA73 (talk) 20:05, 26 November 2014 (UTC)
Ha, a beer it is! Let me know if you make it to Idaho, or maybe next year's Wikimania. --Dschwen (talk) 21:40, 26 November 2014 (UTC)

It is done

First let me apologize for the bad communication on this issue, but it is now done. The local group membership was removed, every OTRS agent is in the global group, and the local group will be deleted. To me this looked so obviously like a housekeeping task that is a direct consequence of the Meta RfC (which is a done deal), that it did not occur to me there would be any objections. Unfortunately the lack of Echo notifications about the global group membership addition on one hand and the obvious Echo notification about the local group removal has led to quite a bit of confusion, with users complaining about being "kicked out" of the ORTS group. This is very unfortunate, and I again apologize if this has left a sour taste with anyone. The last thing I wanted to do is creating the impression that anyones OTRS services are not appreciated. --Dschwen (talk) 21:51, 26 November 2014 (UTC)

I apologize for filing the bureaucrats request before creating a proposal, as I took as a noncontroversial housekeeping task, too. --Krd 22:37, 26 November 2014 (UTC)
"The only man who makes no mistakes is the man who never does anything." according to q:en:Theodore_Roosevelt, and as far as mistakes go this one is quite minor. --Jarekt (talk) 19:09, 2 December 2014 (UTC)
I was not complaining when I talked about being kicked out, just confused, and I felt like I was suddenly obligated to respond to keep my OTRS access in place. Blue Rasberry (talk) 20:31, 2 December 2014 (UTC)
Yeah, I understand. "Complain" was not meant in a negative way, and you shouldn't feel targeted. There were a few other people on my talk page :-D --Dschwen (talk) 21:01, 2 December 2014 (UTC)

RfC: Should we request Wikidata Phase 2 to be activated on Commons?

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.


Wikidata Phase 2 would allow templates to draw information from Wikidata, though only from the unique Wikidata item that was directly 1:1 sitelinked with the page.

(For a short introduction to Wikidata, see Commons:Structured data/Short introduction to Wikidata)

In practice, the effect of this would be limited, because really only gallery pages would be able to access wikidata items with very much useful information. But it would mean we could try out gallery headers that come with an automatic link to the Commons category, an automatic link to any language-localised Wikipedia entry, an automatic language-localised description, and automatic links to corresponding pages (if any) on Wikisource, Wikiquote, and the corresponding page on Wikidata, and Reasonator. A very basic prototype for such a template can be seen tested at d:Template:SimpleCommonsGalleryHeader/test -- obviously, it could be made a lot more polished.

I think this is something it would be valuable to be able to start to play with. User:Lydia Pintscher (WMDE) has said she is happy to activate Phase 2 whenever we decide we want it.

So: should we give it a try? Jheald (talk) 14:35, 22 October 2014 (UTC)

Discussion

The sooner we can use this for creator templates, category pages, etc, the better. Andy Mabbett (talk) 17:26, 22 October 2014 (UTC)

Activated

  OK As of 2 December 2014, Phase 2 Wikidata has now been activated, with Phase 3 to follow early next year. Here's Lydia's announcement at Commons:VP -- Jheald (talk) 16:25, 3 December 2014 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

robots.txt thumbnail exclusion

I don't know if this is the right place to suggest this, but: There is no need for search engines to index thumbnails. Add

Disallow: /wikipedia/commons/thumb/

to

http://upload.wikimedia.org/robots.txt — Preceding unsigned comment added by 31.25.6.249 (talk • contribs) 12:53, 4 December 2014 (UTC)

Of course it is a need: If they won't index thumbnails, it would be nearly impossible to find anything through search-by-image. What is the problem you would like to address? -- Rillke(q?) 13:16, 4 December 2014 (UTC)
It's really /wikipedia/commons/thumb/ (surprised me). I guess (could be wrong) that changing robots.txt is outside of what admins/bureaucrats/stewards are supposed to do, maybe somebody with a phabricator: account can move it upstream for a solution on all MediaWiki installations, not only here.
Added after edit conflict: Does search by image need indexed thumbnails? –Be..anyone (talk) 13:25, 4 December 2014 (UTC)
When Google indexes a page, they don't even know where they find the full resolution image. And another question is whether they would index huge images. Even the preview image on file description pages is most of the time (if it is of a filetype that cannot be rendered by all browsers or if it's bigger than the user's desired preview size) a thumbnail image. Hence,   Oppose   Oppose   Oppose and   Oppose moving this to Phabricator. This would essentially eliminate all quality images from Google search. Evil, IMHO. -- Rillke(q?) 14:12, 4 December 2014 (UTC)
Odd, in TinEye + Google image searches for dupes I don't recall that they bothered me with thumbnails; IIRC I even found an already existing huge JPEG dupe of an (at this time) too big TIFF this way. I'm not at all interested to disrupt this feature. I assumed that typically small thumbnails, if they show up in search results, could mislead folks to copy small thumbs without looking at the original, let alone the license. –Be..anyone (talk) 20:13, 4 December 2014 (UTC)
By the way, any resized image version -- or rendered PNG version of an SVG -- would be disallowed by the above exclusion. If you have a 5000 pixel wide image, a 4000 pixel wide resized version is a "thumb" as far as the software is concerned... AnonMoos (talk) 14:21, 6 December 2014 (UTC)

Commons:Categories for discussion/2014/12/Category:Streets by country

Hi everyone, just giving you a quick notification that there is a discussion going on about the naming format of streets and squares that you might be interested in. Please join and give your opinion on it so that there can be more clarity about policy. Thank you. Commons:Categories for discussion/2014/12/Category:Streets by country. Gryffindor (talk) 14:58, 13 December 2014 (UTC)

Allow .ico files to be uploaded

On one of the perpetual everything wrong with commons threads on wikimedia-l, there was a comment about supporting .ico files [1] (ping User:MZMcBride). These types of files are used as a general icon format on windows, and as the favicon for websites (e.g. https://commons.wikimedia.org/favicon.ico ). I wasn't aware that anyone actually wanted this. If people actually want this (By which I mean, there's a vote which I can point to as "Community consensus"), I think it would be very trivial to get the change through the technical bureaucracy. So, do folks here want to enable uploading of .ico files? (To be clear, MediaWiki would probably render thumbnails of these files as pngs). Bawolff (talk) 07:41, 16 December 2014 (UTC)

ICO is a seriously complex container format for some kinds of BMP and PNG (ffmpeg has it as "muxer", not as "encoder"), please don't waste your time for this incomprehensible Windows crap. Support XPM if you're looking for missing formats. Yes, I'm a Windows user.  –Be..anyone (talk) 09:20, 16 December 2014 (UTC)
image magick already supports it (At least it worked with the one file I tested. Haven't done extensive testing), so the amount of effort needed would be really minimal (XPM would also be similarly easy if we wanted that format). Yes, an ico can contain multiple icons (normally a single icon in multiple sizes and possibly colour depths), my initial idea of support was the lazy version, that is: ignore all but the biggest version. Or perhaps, the different sizes in the icon file, could be treated like different pages in a pdf, or it could be treated as a totally separate thumbnailing parameter if need be. Now that I think about it, I kind of like the multi-page approach. Anyways, my point is that all the heavy lifting is already done by image magick, all that's needed is a tiny bit of glue code for MediaWiki. The question to answer is if .ico support would be a net gain for commons. Bawolff (talk)
Do we have a process of benefit:cost analysis? Okay, benefits: Apparently, we have some icon categories with, according to CatScan, 171700 icons, and sometimes it would be handy to download a fully-featured icon instead of PNGs which one has to compose together to a icon file requiring expertise (true colour/ high colour/ 256 colours support, icons of which sizes [control panel, start menu, windows vista+, ...]) and software. Cost: Development (I guess a new Bitmap handler or similar must be written) but if ImageMagick supports the ICO format, it won't be too much (as no legal/ security review would have to be involved). Possible disadvantages: Multi-page stuff is a little harder to patrol. If we only see the highest resolution thumbnail, we might miss something but it's not a lot different from thumbnails embedded in JPEG metadata. All in all, I would   Support this development if Bawolff has plans about that development as the human and maintenance aspect is utterly important for proper working software in volunteer driven projects. However, I don't see windows icon support as a first-class priority. -- Rillke(q?) 11:43, 16 December 2014 (UTC)
Facilitating customisation of eyecandy on proprietary platforms seems pretty far from Commons:Project scope. There are many other things desperately calling for resources. —LX (talk, contribs) 19:57, 16 December 2014 (UTC)
Re User:Rillke: Yes, I'm volunteering to do the relavent coding stuff. Re User:LX: I don't disagree. This is just something that would be really quick to do. So if it would be useful, we should do it, as it takes almost no resources. The question of course is if its useful. Bawolff (talk) 21:46, 16 December 2014 (UTC)
"complex container format" suggests to me the possibility that malicious code could be hidden in that container, IANAP (not a programmer). What do you experts say to this? --Túrelio (talk) 21:26, 16 December 2014 (UTC)
I do not think that's a risk for the .ico format (Note that there's a related format called .icl, which probably would have risk associated with it). The container format is much simpler than many modern container formats, and is basically just an index at the beginning listing how many images are in the file, and what size, followed by all the images smushed together. Bawolff (talk) 21:36, 16 December 2014 (UTC)
No security issues, remotely the same idea as TIFF. –Be..anyone (talk) 22:04, 16 December 2014 (UTC) Update: There could be a legal issue (I'm not aware that ICO is open source), and a support issue (works with ImageMagick x.y does not imply works with version u.v. or Windows a.b). –Be..anyone (talk) 19:57, 17 December 2014 (UTC)
The main concern when writing MediaHandling extension is always to get thumbnails :) And with ImageMagick being available on production servers, there is. Windows should know the icon format very well; provided they are properly created, they should just work under Windows. MediaWiki will not touch any file data; never did this for uploaded files. If you download the "full resolution" you always got the original as uploaded by the uploader, if this is what you were wondering about. -- Rillke(q?) 23:11, 17 December 2014 (UTC)
There is an open source implementation of a decoder for that format in image magick. From a copyright perspective we should be fine. From a patent perspective, IANAL, but I doubt there's anything patentable in that format (Then again, software patents are always surprising), additionally, the format is over 20 years old, so if there were software patents, they'd be expired. So the format should certainly be considered free. Bawolff (talk)

Tracking project for Commons on Phabricator

Phabricator is our new issue and feature request system. It replaced Bugzilla about a couple of weeks ago and it's a lot more flexible regarding to which project a task is in, allowing, for example multiple projects. In phab:T802 it is suggested to create such projects on Phabricator.

From my point of view, this would have a couple of advantages for us, especially those who care about reporting issues there:

  • Improved tracking of "our issues" and feature requests -- If something was broken recently one could quickly look up the newest issues for Commons and this way find a way around the issue or determine whether one has to create a new issue report.
  • We could invite people to report issues their own, centrally, under the Wikimedia Commons project, this especially given the fact that it's possible to login through oAuth with a SUL account now. Interested parties could watch new incoming issues, translate and categorize them, or reject if local administrators are responsible for that issue. This means, issue reports are hopefully not scattered around various places but could be more centralized and the learning curve to the issue tracker is not so steep and we possibly ease and improve participation in Phabricator. More participants also means that developers will less frequently ask people to "prove" the issue exists (e.g. asking for screen recordings etc.; of course developers must be still able to reproduce an issue but they'll be less sceptical if they don't get the reports from one and the same person all the time).

Before, in Bugzilla, we achieved this with tracking bugs (tasks). But it was a little fiddly to do this for huge projects and Commons is huge. -- Rillke(q?) 16:46, 20 December 2014 (UTC)

{{Discussion menu}} had a link to recent bugs related to commons, hopefully that can be revived in 2015. –Be..anyone (talk) 17:22, 20 December 2014 (UTC)
Do we really need a proposal? Wikidata have its own project: https://phabricator.wikimedia.org/tag/wikidata.org/ - so it shouldn't be a problem for commons. --Steinsplitter (talk) 18:57, 20 December 2014 (UTC)
I am just interested in people's concerns and opinion :) -- Rillke(q?) 20:52, 20 December 2014 (UTC)

Preventing the use of non-existent categories with UploadWizard

The UploadWizard can be used to add non-existent categories. Can the upload process be modified to alert and/or prevent non-existent categories from being added to an uploaded file? Alan Liefting (talk) 17:27, 5 December 2014 (UTC)

I thought there is some grey text saying something like This category does not exist and will be created when entering a name of a category that does not exist. Is this gone? -- Rillke(q?) 17:35, 5 December 2014 (UTC)
I have not actually checked the wizard to see how it works but this file was uploaded today with a couple of non-existent categories. Alan Liefting (talk) 18:12, 5 December 2014 (UTC)
Yes, there is a warning that a particular category does not yet exist. However, regarding Alan's suggestion, I'm not sure it's a good idea to prevent nonexistent categories from being entered. As an experienced editor, I sometimes put such categories in first, and then create them once the upload process has been completed by the wizard. — SMUconlaw (talk) 20:27, 5 December 2014 (UTC)
Exactly my thoughts. (But of course why would an experience editor be using the UploadWizard at all, that’s another matter.) -- Tuválkin ✉ 13:55, 6 December 2014 (UTC)
Because it's easier to use UploadWizard to upload a number of files in a batch rather than to upload them singly, of course. — SMUconlaw (talk) 20:45, 23 December 2014 (UTC)
Adding categories that should exist is fine, and something I would expect from an experienced editor, but users without experience often add categories that will never be created. To improve things around here and to reduce the editors workload I think we need to have the UploadWizard reject non existent categories. Alan Liefting (talk) 18:47, 20 December 2014 (UTC)
Yeah, it is not obvious to me that we would benefit from that move. It seems to me that allowing non existent categories would be helpful for newbies to at least give us some idea of how to categorize. It might me easier in many cases to fix a wrong category name than guess categories on an uncategorized image. --Dschwen (talk) 21:51, 5 December 2014 (UTC)
Hoe a file is categorised should be able to be determined from the description. Unfortunately the description is not always very descriptive. Alan Liefting (talk) 01:34, 6 December 2014 (UTC)
You understand that for most purposes and in most cases, a file description is meaningless boilerplate, yes? -- Tuválkin ✉ 13:55, 6 December 2014 (UTC)
Once uploaded the correct categories can be added easily with HotCat. Alan Liefting (talk) 18:48, 20 December 2014 (UTC)
This is true for your uploads. However not for those of other users and we're thrilled that we would end up without any description of the file at all if we're going to dismiss non-existing categories. -- Rillke(q?) 18:53, 20 December 2014 (UTC)
Should we reject files that do not have an adequate description? Alan Liefting (talk) 19:03, 20 December 2014 (UTC)
Perhaps when our tools are able to identify (in)adequate descriptions, i.e. not for many years. Even then there are many good images with obvious subjects but without description. What about "unidentified plant.jpg" described as "unidentified plant". Once somebody identifies it, file name, categories and description can easily be modified/added (of course location etc. would have been good to have, and some plants are difficult to identify from a photo - but would we rather refuse the image? See e.g. File:Plants on swamp.jpg).
My experience with non-existent categories is mostly about categories with names in the uploader's mother tongue or similar, which are easy to correct or use for adding to the description (for those who know the language, which often is related to the subject). I myself often have difficulties to find categories for things I usually do not discuss in English - what about those who do not master English at all?
--LPfi (talk) 18:44, 21 December 2014 (UTC)
No, let users upload stuff, this is technically hard enough. Whatever it is could be automatically tagged as "needs author + category + date + description + license + source" flipping to speedy self-destruction after one day. Spammers thinking that they found a free one day (pron or warez) hoster have to be blocked indefinitely, they'd need new accounts daily, but would that be worse than it is? –Be..anyone (talk) 01:54, 22 December 2014 (UTC)

No more lo-res preview while picture is loading, please!

For a while now, pictures on the Commons have been displaying a low resolution preview, for the 2-3 seconds or so it takes (on a normal connection) for the picture to load fully. This is actually REALLY annoying and tiring for the eyes. Personally I find absolutely no need to see a blurry preview while I wait for the picture to load, given that the "wait" is only a few seconds anyway. I think it'd be really good to scrap this algorithm and just have the pictures load normally, as on any other website, i.e. without that useless&iritating preview. Thanks! — Preceding unsigned comment added by 192.167.90.244 (talk • contribs) 10:27, 10 December 2014‎ (UTC)

If you are talking about Extension:Media Viewer, please report it at Phabricator as we have no control over this piece of software. -- Rillke(q?) 14:17, 10 December 2014 (UTC)
Example, please, for a few days I'm still on the "GPRS speed, like ISDN" variant of my mobile broadband plan (after eating up the 5GB per month with a remotely acceptable bandwidth.) Only a few seconds for you could be almost an hour for me in this state. –Be..anyone (talk) 14:26, 11 December 2014 (UTC)
I guess it's about the low-res version MediaViewer presents first, which it takes from the thumbnail that is shown on the page anyway, not about interlaced PNG. -- Rillke(q?) 14:31, 11 December 2014 (UTC)
Simple solution:don't look at it!! Sardaka (talk) 07:36, 26 December 2014 (UTC)
Ah yes, the Wikimedia version of slut shaming. Always blame the person for what they did not the system. Saffron Blaze (talk) 00:07, 27 December 2014 (UTC)

Ban some of the automated Flickr uploading?

Huge numbers of images are being uploaded to Commons from Flickr. The automated uploads are being added without regard to suitability, whether they have a suitable description, and they are often being categorised incorrectly. In order to try and improve that standards of Commons I would like to see restrictions placed on some of the automated uploading. Is this something that the community would want to do? Alan Liefting (talk) 03:27, 27 December 2014 (UTC)

Proposed modifications to Gadget-Stockphoto

An editor posted to the help desk, stating that reusing media from the Commons on non-English Wikis is cumbersome as the output of the Use this file link always outputs a string with the File: prefix, whereas wikis in languages other than English use different prefixes. For example, Czech Wiki uses Soubor instead of File, although using File still works, for non-English speakers this could be confusing, and not having the output in a selected language does go against the multilingual tenets of Commons a little. I therefore ask that the prefixes of the links that Gadget-Stockphoto outputs be in the users selected language, not English.

It also seems that the output only uses the filename as the description. Is it possible for the gadget to retrieve the description from the media's information template (preferably in the users selected language)? Thanks for considering these proposals. ColonialGrid (talk) 16:32, 22 December 2014 (UTC)

It was a mistake in the first place to allow localization of the file syntax as part of the Wiki-Markup. Since this is, AFAIK, a configuration thing, it would be probably wrong to localize the namespce when displaying on Commons. Asking @GDubuc (WMF), Bawolff, and Fabrice Florin (WMF): I suggest to turn the gadget completely off and ask the Multimedia Team to develop a replacement for which they've anyway developed the libraries in course of creating Media Viewer so this shouldn't be too hard to tackle for them. -- Rillke(q?) 17:59, 22 December 2014 (UTC)
  • To clarify, the output still works with both prefixes displaying a picture, so turning off the gadget without a replacement would be detrimental to all. Also, I'm not suggesting that we localise the actual namespace at Commons, simply that the string of text outputted by the gadget should include the localised prefix, and preferably a description that isn't simply the filename. ColonialGrid (talk) 18:25, 22 December 2014 (UTC)
I see the problem, but I think the solution is not quite what you requested. Let's say my preferred language is French. Even if that is so, the file prefix should be "Fichier" only if I am working on WP:FR. If I am working anywhere else, it should be in the appropriate local language, which is often not the User's selected language, as you requested above. — Preceding unsigned comment added by Jameslwoodward (talk • contribs) 15:03, 23 December 2014‎ (UTC)
  • Maybe so, but the chance of a user setting the language in Commons to Czech, and then editing in French Wiki would have to be minuscule compared to the number of users setting their language to Czech and editing in Czech Wiki (the situation that prompted this request). I also see no technical way of the system divining what language Wiki project you will be using the media in. Additionally, the issue of the gadget not retrieving the file description remains. However, would a dual lingual or choosable output appease your concerns? ColonialGrid (talk) 15:50, 23 December 2014 (UTC)
The English-language prefixes are the only ones guaranteed to work everywhere, so they should be the output of any such gadget. It is a million times more confusing if someone uses that gadget and it simply doesn't work at all (such as if someone has their language set to Czech, wants to add an image to frwiki, and gets a Czech prefix), than the minor inconvenience of an English-language word appearing in the wikicode (is anyone genuinely confused by that?). This gadget needs to be reliable, and the English-language prefix is simply the only reliable one. darkweasel94 16:57, 23 December 2014 (UTC)
I posted the question because it is really a problem for me. Mixing up different prefixes is confusing so every time I have to select the title just after the prefix and add the czech one or use the toolbar button. I would really appreciate if I could do this only with the very few non-czech wikipedia picture insertion I do. All the possible confusion could be solved by allowing this as an option in personal preferences. Matěj Orlický (talk) 09:27, 28 December 2014 (UTC)

Just to clarify, since I was pinged above. I'm not on the multimedia team anymore. Bawolff (talk) 22:35, 28 December 2014 (UTC)

Script needed to hide all the latest contributions

I like to keep an eye on my edits to check for vandalism and to see if other editors agree with them. At present the Mediawiki software only lets you filter user contributions on having the latest revisions shown and does not give the inverse of it. Over at Wikipedia a script has been developed to will allow the user contribution list to only show entries that have had a subsequent edit. See w:User:Markhurd/hidetopcontrib.js. Can this useful script be developed for Commons? Alan Liefting (talk) 04:29, 27 December 2014 (UTC)

Already should work at commons, just add the following to Special:MyPage/common.js (If you add it to meta:Special:Mypage/global.js it will work on all wikimedia wikis)
importScriptURI( 'https://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:Markhurd/hidetopcontrib.js' );

Bawolff (talk) 07:35, 29 December 2014 (UTC)

Thanks for that but I tried both options and it does not work. I am no script kiddie so I may need a bit more help. Cheers.Alan Liefting (talk) 08:09, 30 December 2014 (UTC)
Ah, it did work. I found it by clicking More. I am used to a different skin when using it. Cheers. Alan Liefting (talk) 18:21, 31 December 2014 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2014/12&oldid=146592703"