Commons:Village pump/Proposals/Archive/2012/11

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

"Free Encyclopedia" Russian translation

Why is the word svobodnaya used, i.e. free as in not in jail or free as in "at liberty to" ...

Instead of the word byezplatnaya, i.e. free as in "you don't have to pay for it"

I know Wikipedia is both: it is an encyclopedia with enormous liberty, but, it is also used free of charge by anyone with a computer. Is this verbiage used intentionally?

eric.nelson@lmco.com

Maybe thats something you should ask the Russian community at ru:Википедия:Форум. But the answer is relatively simple, in all languages including English the word "free" emphasizes libre, not gratis. --Martin H. (talk) 23:52, 30 October 2012 (UTC)
  • That has been discussed extensively and decided that free (in the sense of free knowledge) is best translated as svobodnaya. There is no one-to-one correspondence between English and Russian words here.--Ymblanter (talk) 16:52, 31 October 2012 (UTC)
  • The libre sense of free is chosen because of the freedom of users to edit articles and the freedom of everyone to reuse and remix our content without payment or permission. Dcoetzee (talk) 06:36, 8 November 2012 (UTC)

Import a gadget from Spanish Wikipedia

In Spanish Wikipedia we have this Gadget. It turning the unordered list (using bullets) in an ordered list at Special:Contributions, history and other pages specials. I like this gadget and I think that it is a good tool. So I request an administrator add it in Special:Preferences> Gadgets > Interface:. Or put this gadget like default changing it the dots. I like the two option (change). The description phrase is "Show the history and all specials pages as a numbered list."--Vivaelcelta {discussion  · contributions} 17:41, 1 November 2012 (UTC)

  1.  Support --Vivaelcelta {discussion  · contributions} 17:41, 1 November 2012 (UTC)

Upload by URL

en.Wikipedia administrators have an upload_by_url userright that apparently allows them to upload a file directly from a URL without downloading the file. Can this right be created for trusted users on commons? Ryan Vesey Review me! 23:22, 7 November 2012 (UTC)

  •  Support. This would be extremely useful for me, especially if it allowed large (> 100 MB) file uploads. It would enable me to batch upload my image files to fast Amazon S3 servers from a location with a good Internet connection and then sideload them gradually to Commons from any location, as I write the descriptions. It would also allow Flickr upload bot and similar bots to run about twice as fast and use much less bandwidth by doing a direct upload from Flickr instead of a download/upload cycle. Dcoetzee (talk) 06:33, 8 November 2012 (UTC)
  •  Support Support support support! This would be tremendously helpful. cmadler (talk) 13:13, 8 November 2012 (UTC)
  •  Support Of course. This is a much needed feature. Yann (talk) 13:32, 8 November 2012 (UTC)
  •  Support Much needed, of course. Jean-Fred (talk) 13:49, 8 November 2012 (UTC)
  •  Comment The userright may exist, but I do not think it is enabled. This is tracked at bugzilla:20512, and as far as I understand there are still underlying technical issues blocking this. Jean-Fred (talk) 13:49, 8 November 2012 (UTC)

 Comment en.Wikipedia administrators have an upload_by_url userright - no they don't. See en:Special:ListGroupRights. We've wanted this for quite a while (see eg COM:VPR archives...), but Bugzilla:20512 has stalled. Ryan Kaldari was about to turn it on for admins for Flickr sideloading only - not sure if even that's happening, or when. Rd232 (talk) 14:12, 8 November 2012 (UTC)

  • Wow, I apologize for getting everybody's hopes up. I found a list that showed that admins had the userright and I asked what it was to be sure. Apparently, all en.wikipedia admins, and I don't know who on commons, would have the userright immediately if it was turned on. I suggest people try to find a WMF member to bother until they take action. Ryan Vesey Review me! 14:29, 8 November 2012 (UTC)
  •  Support I think the groups that need it are: Administrators, Reviewers, and OTRS members. -- King of 04:40, 13 November 2012 (UTC)
  •  Support Yes we need it! Even if limited to Flickr and Wikimedia sites, it would be helpful. -- Rillke(q?) 07:59, 13 November 2012 (UTC)
    I don't really see any reason to restrict the domains, given that it will only be given to highly trusted user groups. -- King of 08:12, 13 November 2012 (UTC)
    Agreed. And it should also be enable for other projects to move files not acceptable in Commons, where local uploads are enable. Yann (talk) 08:31, 13 November 2012 (UTC)
    I can't believe I forgot about that! I move so many no-FoP images of buildings from here to enwiki. -- King of 08:32, 13 November 2012 (UTC)
    I do not suggest to limit it to domains but reading the bug linked above, it looks like the one responsible for the server administration would like to do it. I wanted to express that this feature should be enabled as soon as it is available - whether with or without restrictions. BTW we can't make decisions for other projects. -- Rillke(q?) 17:58, 13 November 2012 (UTC)
  •  Support, though knowing full well it will probably be years before anything comes of it. Uploading is torturous enough for one's own images, and a simple way to import images from other sites (particularly sites like Geograph and Flickr which hold huge amounts of freely licensed content) would make life that little bit easier for long-suffering Wikimedians. HJ Mitchell | Penny for your thoughts? 13:25, 13 November 2012 (UTC)
  • Update. Right now Upload by URL is not available on any wikis due to some technical problems (mainly that it doesn't work over HTTPS and it breaks other Http::get() requests). However, I'm working on a very limited roll-out for Commons to support Flickr side-loading. This is something of an experimental project and will initially only be available to admins and only through a special interface in UploadWizard. If it doesn't cause any problems, we'll invite the Commons community to discuss opening it up to more users. The first piece of this roll-out is being deployed to Commons tomorrow. This consists of back-end changes to UploadWizard to prepare it for the new upload by URL features. You shouldn't notice any changes to UploadWizard tomorrow (hopefully), but if the deployment goes smoothly, we'll see about turning on the new features perhaps as early as December. Kaldari (talk) 19:38, 13 November 2012 (UTC)
    • Thanks for the update. Is there any particular reason to target Flickr for the testing, rather than, say, English Wikipedia? Rd232 (talk) 11:22, 14 November 2012 (UTC)
      • The only reason is because we don't have it working over HTTPS yet. This isn't an issue for Flickr (their API always serves images via HTTP), but it would cause transfers from English Wikipedia to be unreliable. As soon as that is resolved, we'll see about turning on side-loading from other wikis. Kaldari (talk) 19:41, 14 November 2012 (UTC)

Listings of assigned files in a category

Opening Category:PD-Art (Yorck Project) you get listings of assigned files in sets of 200 and one has to shuffle trought. At some point of time, some users lose track how many pages they have turned (and wants to know how much is left, etc.) but there is only the message "The following 200 files are in this category, out of 10,415 total." My suggestion is to display at least page numbers ("... page of ... pages") if not the remaining amount of listings. --Mattes (talk) 18:56, 19 November 2012 (UTC)

Large categories should have a TOC - like that one does. So you can jump to files starting with Ba, Bb, etc. I do see what you mean though, that it would be helpful to say, eg "the first file below is #X out of #Y". There's no harm in filing a bug on Bugzilla, but any kind of change in the software takes eons, even if it's simple (and many apparently simple changes turn out to be surprisingly hard to do). Rd232 (talk)

Listings of category members

I'm uncontended about navigate through large amounts of files which are scattered below a category, e.g. Category:Paintings in the Uffizi Gallery (37 C, 19 P, 224 F). Gallery pages are rare, need a lot of effort, and are mostly inclomplete, so that's not a solution for the next couple of years. CatScan may be nice for people who (a) know about it and (b) know how to use it; I don't even know if that's the right tool. Category:flat categories I have two proposals to make it easier for everyone.

1) Create a simple "input tool" where user can enter a category name and get a non-hierarchical list of all members, collected from the server and therefore complete/up to date
— or —
2) Generate and maintain flat categories by bots for large categories, e.g. big collection of museums.
See also: Commons:Forum#Neue Kategorie "Flat categories".

Sincerely, --Mattes (talk) 12:30, 24 November 2012 (UTC)

As long as sorting does not matter and there is no "Anastomosis" in the category tree 1) is more or less easy to implement. If you care about sorting, 1) would need a database and either live replication or some kind of task stack. 2) Would cause a lot of bot edits, right? -- Rillke(q?) 15:27, 24 November 2012 (UTC)
Proper integration and documentation of Catscan (that fails often on the toolserver) might be a better way than to find yet_another_would_be_solution. --Foroa (talk) 16:19, 24 November 2012 (UTC)