Commons:Village pump/Proposals

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓

This project page in other languages: English | +/− Shortcuts COM:VPP COM:VPPROP COM:VPR Welcome to the Village pump proposals section This Wikimedia Commons page is used for making proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Commons:Village pump, which handles community-wide discussion of all kinds. Discussions here should be of wide interest; those which are more specific may be moved to the main Village Pump, with a note left here. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. For old discussions, see the Archive. Recent sections with no replies for 14 days may be archived.   Start a new discussion

Centralized discussion
Proposals	Discussions	Recurring proposals
Request for comment on enabling the Translate extension on Wikimedia Commons. (28 April 2012) Request for comment on enabling the UniversalLanguageSelector on Wikimedia Commons. (24 April 2012) Request for comment on enabling "article feedback" functionality for selected Commons images. (18 March 2012) Request for comment on creating a page to allow users to request others to upload files on their behalf. (14 March 2013) Request for comment on clarifying Commons' Project Scope, as laid down in COM:SCOPE. (11 March 2013) Request for comment on making Commons:Username policy an official Wikimedia Commons policy. (26 January 2013) There is a Request for Comment on hard category redirects #REDIRECT. (1 January 2013) Please help by translating these messages into other languages. Note: inactive discussions, closed or not, should be archived.
Archive  • Discussion • Edit • Page history • Watch

Angaben zur geographischen Position

Habe - nun zum ungefähr dritten Mal in einem längren Zeitraum - den Versuch gemacht, zu einem Artikel (hier:Angeles City Flying Club) exakte geographische Positionen einzugeben. Hier 120°40'39" O und 15°15'02" N. Die Eingabefelder sind nicht in der Lage, diese Angaben zu akzeptieren bzw. korrekt zu verarbeiten. Eine Hilfe für andere Eingabeformate gibt es auch nicht. Also liebe Leute, wenn ich meinen Usern so was anbieten würde, wären ebendiese User zu Rech stocksauer und ich bald arbeitslos. Mein Vorschlag lautet: Die Anzahl der Eingabefelder für die geographische Position wird auf 6 erweitert, nämlich jeweis 2 für Grad, Minute und Sekunde. (Wobei Sekunde und Minute bei Bedarf leer gelassen werden dürfen.) Eine Rückmeldung innerhalb einer Woche wäre wünschenswert.

Der Improvisator —Preceding unsigned comment added by Surigaotourist (talk • contribs) 12:05, 3 March 2013‎ (UTC)

Moving categories

Why do we use User:CommonsDelinker/commands to move a category, when a category rename is required? user:CommonsDelinker's purpose is to delink deleted files, and updating file links when a file gets moved. Sure other bots patrol that page and implement the category moves, but that's not CommonsDelinker's job. RussBot also monitors Category:Non-empty category redirects and does the leg-work there. Humans can do most of it as well (especially with Cat-a-Lot). So the execution of the move doesn't need CommonsDelinker.

Therefore I'd suggest we completely deprecate CommonsDelinker for this purpose, and simply use the following process for non-controversial moves:

1. Copy the content of Category:Foo 1 to Category:Foo 2.
2. User replaces content of Category:Foo 1 with a redirect.
3. User either empties old category, or waits for the bots to do so.
4. If redirect is not required, it can be deleted.

These instructions should be noted on Commons:Rename a category.

It should be straightforward to create a gadget that prompts the user for the new name and reason, before executings steps 1 and 2 (maybe even using a "move" link in the standard place!). If a more complex script incorporating Cat-a-Lot style elements was developed, that a lot of the leg work of step 3.

This would make category renames easier, and reduce the maintenance workload at CommonsDelinker. It also means the default for the original cat is a redirect to the new, unless deletion is needed (which is better than the reverse).--Nilfanion (talk) 08:30, 28 April 2013 (UTC)

I don't see what the problem is using delinker to move categories. --Skeezix1000 (talk) 21:03, 1 May 2013 (UTC)

The question is more why do we make users go via delinker (which isn't really for this task, but for files), when they could do the move themselves directly by following the above procedure? Why do we make it needlessly complicated? This doesn't mean we prevent that use of Delinker for this task, but we strongly encourage a different approach. A script that does something on lines of above, would make a category move/rename as easy as using Special:Move for a page in mainspace. This would substantially reduce administrative workload for the non-controversial cases.--Nilfanion (talk) 21:55, 1 May 2013 (UTC)

I had indeed something like a move link for categories in mind which offers the options available to one user (or more asking whether it is something that needs discussion or could be controversial). Then, it would also not really matter what the script does in the background to achieve the move. But I rarely deal with category-renaming… -- Rillke^(q?) 21:23, 1 May 2013 (UTC)

There is such a gadget on the French language Wikipedia: fr:Projet:JavaScript/Notices/RenommageCategorie. Jean-Fred (talk) 22:52, 1 May 2013 (UTC)

I don’t understand the issue. It just happens that we have a self-service robot, SieBot, which among many other things can be used to move categories − nobody has to use it, SieBot is just a convenient way to do it. Sure, if anyone ca do it let’s provide a more convenient way to do it ; but I just don‘t the point of forbidding to use SieBot for that. Jean-Fred (talk) 22:52, 1 May 2013 (UTC)

There seems to be several dimensions forgotten. I notice indeed that more and more categories are moved manually without any sort of consensus or procedure; what is considered an uncontroversial for one person, is often controversial for another. Moreover, many people are merging categories into higher level ones as they don't make the effort to understand the reason of its existence, which is often not documented indeed. Such merges can be highly demotivating for people that made a significant effort in an attempt to structure and clean up a category tree; without such efforts, many category trees quickly end in a big pile that are next to impossible to clean up such as for example the big topics like art, paintings, people, music, ... Anyway, the delinker has a number of advantages, which are obviously not appreciated:

• When creating a new category, the delinker documents in the edit summary where the category is coming from and the authors of the source category.
• The delinker can document the reason and/or the reason of a move, possibly with a link to the discussion. This feature is rather recent and not very much exploited.
• One has a central view of all bot-moved categories, which allows to rename the associated subcategories accordingly. Many people forget that.
• If one has to rename thousands of categories, such as from "19th century paintings" to "19th-century paintings", such a bot is the only feasible approach. That specific move got SieBot moving for 72 hours non stop. There seems to be no other feasible way.

When we look at what is requested in on User talk:CommonsDelinker/commands (or in category:Requested moves (all)), a significant part is changed by the requester or the person executing it, others are rejected. In other words, we have a two (or three) stage process that filters out the majority of the mistakes and gives some time to other people to review (think on it) the move request. While a category move can be easily undone, a series of moving merges is next to impossible to undo. So the delinker and its process plays an important role in quality assurance. --Foroa (talk) 06:21, 2 May 2013 (UTC)

Bot moving has its place (especially the bulk moves) though I'd strongly suggest category renames are done at a different location to User:CommonsDelinker/commands. Why? Its a different task to file moves, done by different bots; having them both there slows both down and increases errors.

At the same time, there is no reason to delay simple moves giving them no option but delinker - the manual process should be explained, and a gadget implemented to support it properly. A gadget, like Special:MovePage, would give a prominent "reason" box that a user is unlikely to miss, and a gadget can ensure correct backlinking to the original location. Like a pagemove, the gadget could also slow a merge with a "the target already exists" warning/termination.

One negative aspect to the delinker process is it encourages deletion of the original category, regardless of whether keeping a redirect is appropriate or not. In the many cases leaving a redirect behind will be useful, and is harmless. User:Category-bot's behaviour is better than Delinker-powered moves because it does things like this. Not all renames should leave redirects behind, but a significant proportion should.--Nilfanion (talk) 08:16, 2 May 2013 (UTC)

Iconclass codes

I added the iconclass code 73D241 to Category:Last Supper, but I would like to be able to do this in a structured way, in cooperation with Wikidata. Any ideas, anyone? Jane023 (talk) 07:47, 1 May 2013 (UTC)

New Login detected ... but where to leave comments about this feature?

I've detected the New Login-feature: (on the normal login page)

• New commons login

... but where to leave comments about this feature?
• Jaybear • ...disc. • 10:39, 2 May 2013 (UTC)
PS:
It works astonishing fine with my SUL-account
All links from commons into national WPs are keeping https://-adresses,
and my log-in is proper following everywhere!

Hi, Jaybear. :) If you're willing to head over to MediaWiki, you might leave your comments at mw:Talk:Account creation user experience/Testing. If not, you might drop by User talk:Steven (WMF). --Maggie Dennis (WMF) (talk) 18:03, 8 May 2013 (UTC)

Concerning Usage and Maintenance of Public School Stock Photo or Mascot

This topic concerns forming a revised or new taskforce to update the site's policy on public school system stock photos and mascots usage. Accordingly; there are countless schools and school systems willing to participate in the drive to uniformly update their presence on Wikipedia and its sister sites. The question of who is responsible for such maintenance and procedures should be publically debated. A formal question of consensus should be asked of all User and developer groups within the Wikipedia sister sites as to how such a campaign would impact existing directives and if the proposal should seek additional support from the schools and institutions themselves.

To reinstate the original question: Concerning Usage and Maintenance of Public School Stock Photo or Mascot; does the foundation have any plans on updating systemwide software and server hosting to accommodate the proposed public school stock issue?--Habatchii (talk) 07:29, 15 May 2013 (UTC)