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

Split Commons:Categories

I propose splitting the category structure stuff from Commons:Categories, a mess of a page, to Commons:Category structure. The split page would look like this, and Commons:Categories would then look like this. The current page Commons:Categories is a mess, and the issue of category structure is a perennial problem; splitting it off is a first step to making Commons:Categories more usable, and explaining category structure more clearly. Note that this split in itself is not intended to involve any substantive change in content. Rd232 (talk) 10:19, 20 July 2011 (UTC)

There is a discussion and proposal about this at Commons_talk:Categories#Commons:Category_structure. Please comment there. --  Docu  at 10:57, 20 July 2011 (UTC)

Yes, I get it, you don't want COM:VPR.If nobody cares to comment on substance, nothing will happen, so how about just leaving well alone (assuming that you don't wish to engage with the merits of the proposal yourself). I'll put a note on Commons talk:Categories though. Rd232 (talk) 12:44, 20 July 2011 (UTC)

I remember the many issues that have been seen at Commons:Village pump regarding categories and agree that a refresh is in order. The split pages are more understandable and this isn't a policy so I feel there shouldn't be restrictions on its improvement. – Adrignola talk 13:39, 20 July 2011 (UTC)

I think we should implement the proposal on Commons_talk:Categories#Commons:Category_structure. Please comment there. --  Docu  at 01:46, 21 July 2011 (UTC)

Splitting out the Tools section (as you proposed) makes the page shorter, but it doesn't materially reduce the page's complexity or lay a basis for clarifying/improving the content. The current page mixes up "how to" help with guideline/policy-type category structure guidance. Split out the category structure stuff, and it actually makes sense to keep the Tools with the "how to" help. Rd232 (talk) 09:45, 21 July 2011 (UTC)

Incidentally, Docu, you are by some distance the lead editor of Commons:Categories by number of edits. You're probably too used to seeing the page as it is to really see how difficult it is to understand for a newcomer. Sometimes, fresh eyes see things that others don't. (I've been on the other side of that equation too...) Rd232 (talk) 09:49, 21 July 2011 (UTC)

I commented at Commons_talk:Categories#Commons:Category_structure. Please continue there. --  Docu  at 06:24, 23 July 2011 (UTC)

Your comment there was Actually, I like your suggestion to split out tools and how-to sections.. Is that an endorsement of the proposed split, or are you thinking of something similar but not exactly the same? Rd232 (talk) 08:17, 23 July 2011 (UTC)

I agree that Commons:Categories needs some cleanup. However I think we should extract tiny portion of it into a Commons:Category Policy before doing other cleanup. --Jarekt (talk) 18:39, 22 July 2011 (UTC)

Which "tiny portion"? I'm not sure if we agree here, since if you look at what I split out, it is the stuff which I think can most plausibly be considered policy/guideline material. Splitting it out might lay a foundation for elevating that to guideline/policy status... but I'm not sure that really matters (Commons doesn't seem to pay as much attention to such page status issues as I'm used to from en.wp...). Rd232 (talk) 22:20, 22 July 2011 (UTC)

I commented at Commons_talk:Categories#Commons:Category_structure. Please continue there. --  Docu  at 09:09, 24 July 2011 (UTC)

I think categories are such an important part of what we do that we should have a short page of category related policies. Current Commons:Categories is way to big for that. Some points a policy would have is:

• Categories are English language based (we can have a footnote about some bugzilla technical proposals to allow adding translations to help non-english speakers. )
• All files, galleries, categories and templates (including creator and institution templates) have to be categorized.
• Categorization should focus on different aspects of the page, for example subject, date, author, medium, etc.
• We are striving for a single category tree - overlapping branches should be merged.
• Categorized pages should avoid over-categorization.
• Since so far MediaWiki software does not support category intersection. Commons solution is to create subcategories which are intersection of more atomic categories.
• Something about Hidden categories

I might have missed some other core rules. Such short page should be elevated to a policy and current Commons:Categories should become more of an essay expending on some of those concepts. --Jarekt (talk) 02:25, 31 July 2011 (UTC)

That sounds reasonably close to the proposed split. Or would you want it be a lot shorter - more like an expanded version of the Overview section in the proposed split? Rd232 (talk) 13:46, 31 July 2011 (UTC)

I was imagining something a little longer than the overview section, but not much. Written more like bare-bones policy than tutorial. This way when you have one of those discussions with someone why do we need to categorize all images or why categories have to be in English, etc. than we can refer future discussion to the policy page. Lately someone try to do that with Commons:Categories and was told by observant new-comer that Commons:Categories is not a policy and he does not have to follow its recommendations. I will try to start to work on it. --Jarekt (talk) 15:09, 1 August 2011 (UTC)

So more like a three-way split - perhaps Help:Categories for the introductory tutorial/how to, Commons:Categorization for the policy, and Commons:Categories for what's left? Anyway, I'm not wedded to my exact proposed split, I'm happy to have alternative proposals, and I do think it's sensible to think in terms of one day having a page about categories that has policy status. Rd232 (talk) 15:19, 1 August 2011 (UTC)

Commons-Wikipedia Category Interlinking and Translation Project

So here's a Big Idea: have a bot use interlanguage links present on the English Wikipedia (en.wp) equivalent of a Commons category to

1. link from Commons to the equivalent category on all Wikipedias (putting the links in the Commons category at the bottom)
2. add {{Commonscat}} to the relevant Wikipedia category on each Wikipedia (if not present)
3. add a {{Mld}} template (if not present) using these interlanguage links as a "better than nothing" description in the Commons category which will help prompt people to develop descriptions/translations.

The bot would basically start by checking if Commons category X exists on en.wp with the same name (en.wp because Commons categories are normally in English) and using interlanguage links from that if it exists. It can also check any existing interlanguage links in the Commons category and look at the category pages linked in this way (eg if the category is called something different on en.wp, or only exists on other language Wikipedias).

That's the basic idea, which I'm sure can be refined. Lots of work (though interlanguage linking bots exist, which would provide a place to start), but potentially really, really useful I think. Rd232 (talk) 11:58, 1 August 2011 (UTC)

• {{Mld}} would be greatly redundant if the search database would include interwikis from the categories, which it doesn't on Commons nor en:wikipedia. Category descriptions should have always a description in English and possibly the local language as a reference. Only the other (270) languages could be under mld. A description pop up when hoovering over the interwiki might be more efficient, take less space and (maintenance) work and don't fill up the search database with redundant info.
• Most categories on Commons link to a wikipedia article, and most wikipedia articles to a Commons category.
• If wikipedia articles would link to galleries (redirected to a category if empty), we would have a translation database and much less problems when renaming categories (gallery redirects do work)
• Most experienced Commons people put first the interwikis, then the categories as many bots do so anyway and the category part is the most dynamic, so easiest to find when grouped at the end. --Foroa (talk) 14:11, 1 August 2011 (UTC)

• OK. On galleries - there are vastly fewer galleries than categories. Are you suggesting that we start mass-creating galleries redirecting to categories? (This might not be crazy, but it sounds dramatic.) On positioning of interlanguage links - really not the point :) - call it "at or near the bottom".

At least, then there is a one to one relationship, so easy to automate and works mostly for all 270 languages. Gallery space becomes then a translation and search engine.

• You mentioned the search database thing before and I still don't know how to follow that up. But anyway it requires a software change, and this doesn't; and {{Mld}} (or similar template that does exactly what we want in terms of language display) provides a basis for prompting passersby to improve descriptions.

I doubt that this requires a software change. My impression is that all name spaces are read for building the search database, except the category descriptions. My guess is that it is a configuration parameter. Don't forget the huge (maintenance) effort for {{Mld}}. IW's can be easily maintained by bots, for {{Mld}} this is more problematic. --Foroa (talk) 15:17, 1 August 2011 (UTC)

• "Most categories on Commons link to a wikipedia article, and most wikipedia articles to a Commons category." - I suspect most categories on Commons don't link to anything. It could be linking to the wikipedia article as first choice, with linking to a category as the second choice (if the category exists but the article doesn't).

I inserted 10 to 20000 category descriptions and IWs. I always link to articles because in a multi-language environment, those are the most important ones. I mainly document root categories, not their derived subcategories. Most of the times, related articles do exist, no related subcategories. (We have around 1600000 categories, the biggest wikipedia around 600000) --Foroa (talk) 15:17, 1 August 2011 (UTC)

• Hovering over the interwiki (name of the destination as a tooltip) - well that's probably a good idea! It's not entirely a substitute because the links are down the page though. Thinking further out of the box, we could have a Javascript which puts the relevant interlanguage link in the page title (based on the user's language). That would be a Javascript solution for Bugzilla: 29928 (a problem that's had no MediaWiki solution for years). Rd232 (talk) 14:39, 1 August 2011 (UTC)

• "At least, then there is a one to one relationship, so easy to automate and works mostly for all 270 languages. Gallery space becomes then a translation and search engine." - can you elaborate this idea in more detail, in a subsection or new thread? (Unless you've done so elsewhere?) I can't find anything about searching of the interwiki table. What I did find, though was Bugzilla: 15607 - which is some kind of centralising of interlanguage links, partly to avoid the need for zillions of bot edits. When it gets implemented, it'll change the game a lot. So between that and Bugzilla: 29928, maybe it's best to do nothing, and wait. Rd232 (talk) 18:47, 1 August 2011 (UTC)
  • They talk since several years about a wikilink repository and multi-language cats, but nothing really happens. I will try to formulate a more comprehensive and separate proposal within a week or so. In the mean time, could someone indicate me a documentation or a link of the organisation of Sum_it-up and the database behind it.--Foroa (talk) 15:49, 9 August 2011 (UTC)
    • Sumitup's source code is available from your link. It doesn't have a database, it just takes the first sentence or paragraph of the relevant Wikipedia page in each language. I think the relevant pages are identified via interlanguage links, but not just from Commons, also any interlanguage links on linked pages. Rd232 (talk) 21:36, 9 August 2011 (UTC)
  • What I keep trying to say that en.wikipedia and Commons include the interwiki links from the articles/galleries in the search database but not the ones from the categories. I dropped a question on En:Help talk:Searching. --Foroa (talk) 15:49, 9 August 2011 (UTC)

I couldn't make sense of the threading under this heading, so I'm writing all the way down here. :o) Maybe it's just me, or maybe I misunderstood some of the discussion above, but I think cross-namespace redirects and cross-namespace interwiki links are of the Devil. I'd think long and hard before doing such things on a large scale. —LX (talk, contribs) 19:50, 1 August 2011 (UTC)

AFAIK cross-namespace redirects being an issue arises from within Wikipedia it being a bad idea to redirect from articlespace to other namespaces (primarily Wikipedia namespace is the issue), because it breaches the sense of what is part of the encyclopedia and what is part of the community around it. I don't think the same logic applies for cross-namespace links from Commons to Wikipedias. Rd232 (talk) 19:55, 1 August 2011 (UTC)

Yes, that was the idea of the cross namespace witch hunts on en:w: back in 2006. I can't say if that's still a policy, but it certainly was not about article vs. file namespace, let alone interwiki variations. –Be..anyone (talk) 14:36, 9 August 2011 (UTC)

We have around 100000 galleries and 60000 gallery redirects, a good part being redirects to category space. No problems with that. --Foroa (talk) 15:49, 9 August 2011 (UTC)

Suggestion. If this goes further, start with least ambiguous and most narrowly defined topics: people by name, books by name, ships by name etc. Geographic entities can be ambiguous, e.g. "municipality of X" and "town of X" are not the same in their home country, but pretty much the same for foreign editors + all those "my turf" ethnic conflicts. Don't even think of automating anything abstract. NVO (talk) 06:37, 2 August 2011 (UTC)

 Support I agree that we need some serious bot support to create interlanguage links from commons to wikipedias and from wikipedias to commons. I would suggest connecting from commons categories to wikipedia articles, this seems to be the most common and makes most sense to me. Be aware that there is many articles in en wikipedia with identical names as commons categories which relate to different people, places, etc. So bots should not match on names alone ( however customized people match bot can be written that matches names and dates of birth/death). I also think pywikipediabot has some scripts which do something similar. --Jarekt (talk) 15:02, 9 August 2011 (UTC)

Note: By chance there's a related discussion on English Wikipedia, at en:Wikipedi a:Bot_requests#Links_to_Commons. Rd232 (talk) 15:45, 10 August 2011 (UTC)

• "add {commonscat} to the relevant Wikipedia category on each Wikipedia (if not present)" - I suggest to discuss it on every single Wikipedia before starting it. I am preparing sth like this for plwiki - for example in articles with infobox that use commons parameter (example) commons link should be in infobox. Moreover bot without local bot flag will be blocked (Site for the bureaucrats to decide on granting or removing bot flags. ). Bulwersator (talk) 08:50, 11 August 2011 (UTC)

It is not much different from bots updating interlanguage links. I assume the bot that runs that code did not asked for bot flag on couple hundred wikipedias (but may be it did). Also I think it is a problem that every wikipedia treats links to commons differently: some wikis show it as one of the languages in the interlanguage links section, some have a box somewhere or a field in the infobox. It is quite confusing and often hard to find even if present. It also makes it hard to add. --Jarekt (talk) 13:23, 11 August 2011 (UTC)

Well, bots without local flag are blocked on sight on plwiki (including interwiki bots) - cleanup due to badly designed bot may be terrible + unflagged bots will pollute RC and PC buffer Bulwersator (talk) 05:50, 13 August 2011 (UTC)

+local bot is importing commonscat in category: namespace using pywikipedia algorithm Bulwersator (talk) 05:55, 13 August 2011 (UTC)

Special:MyUploads

Adding Special:MyUploads "my uploads" link next to "my contributions"

Special:MyUploads is a relatively new feature [1] which maybe should be more easily accessible. I'm thinking this could be added next to "My contributions" as "My uploads". (Possibly with the ability to deactivate it, for any who are annoyed by change... :) ) What do people think? Rd232 (talk) 00:25, 1 August 2011 (UTC)

To me it is very similar to "gallery" in pool down menu - may be we should place it next to it. --Jarekt (talk) 01:41, 1 August 2011 (UTC)

And to me, it is practically unusable - no licensing data, no categories, odd formatting. I'd rather see gallery moved from toolserver to a better platform (toolserver services were dead yesterday, again, and now toolserver reports lag = 21 hours). NVO (talk) 02:49, 1 August 2011 (UTC)

Yes, (a) Gallery depends on the toolserver (b) it's hidden in a dropdown menu only available on one's user and user talk pages and I've never noticed it before... and I suspect I'm not unique. (c) if we do the "my files" thing, we can edit the message at the top of MyFiles (via MediaWiki:Listfiles-summary) to point to the toolserver options (Gallery, Orphans, Untagged), with some explanation as well. Though that would probably lead to a big increase in use of those tools, which the toolserver might struggle with... Rd232 (talk) 09:06, 1 August 2011 (UTC)

Hidden? It's right there on top of the screen. Could be a different skin, or disabled in your .js setting? NVO (talk) 06:12, 2 August 2011 (UTC)

No it's there, it's just not very visible. The dropdown menu itself is just a little arrow, and the contents of the menu change depending which page you're on. There's no clue of these features being available when you're on your own user/user talk page. Once you know it's there, it's convenient enough, but I'm willing to bet many newcomers haven't a clue the feature exists. Of course I'm talking about the default Vector skin; in the old Monobook, the dropdown menu is extra tabs, which is a lot better visibility-wise (but still it's a feature only available on your user/usertalk page). Rd232 (talk) 09:16, 2 August 2011 (UTC)

Time to advertize old good browser bookmarks! NVO (talk) 12:27, 2 August 2011 (UTC)

There's also the possibility of discussing possible improvements to Special:MyUploads, based on how the Gallery works, and then filing a bug. I don't think there's anywhere to migrate the Gallery to from the toolserver. Rd232 (talk) 09:44, 1 August 2011 (UTC)

Although this is not so useful to users with thousands of uploads, I think this would be very useful to the vast majority of uploaders who have only a small number. I also find it very helpful for viewing my recent uploads. Definitely Support putting it along the top-right of the screen. Dcoetzee (talk) 04:16, 1 August 2011 (UTC)

Yes, it's absolutely aimed at newcomers. As the blog entry said [2], "During our interviews & testing, most people were wondering where their uploads had gone once the upload was completed." The link is currently available as a tiny link at the top of "my contributions" (I've only just noticed that after re-reading the blog entry! it's tiny, and mixed in with other tiny links!) which might be OK for other wikis, but uploading being so core to Commons it really should be more prominent than that. Rd232 (talk) 09:06, 1 August 2011 (UTC)

As we are a media-hoster, I support this. Especially new users don't want to use it to view licenses; they want a summary of what they uploaded and when. -- RE rillke questions? 13:11, 1 August 2011 (UTC)

Add it to {{welcome}} — IIRC I already proposed this somewhere. –Be..anyone (talk) 13:40, 1 August 2011 (UTC)

Good point. Template_talk:Welcome#Edit_request_3 - requested straight away since the Gallery tool's still not working (for me, anyway). Rd232 (talk) 14:03, 1 August 2011 (UTC)

Thanks, I found my old proposal and flagged it as done :-) –Be..anyone (talk) 14:46, 1 August 2011 (UTC)

Support as Rillke. --Aʁsenjyʁdəgaljɔm¹¹⁶⁷¹ 11:47, 2 August 2011 (UTC)

In general: support - but the tool is bad. If a file is overwritten (common for minor svg improvements) it vanishes from the list which might lead to confused users ("my file is gone!!!"). --Saibo (Δ) 01:33, 3 August 2011 (UTC)

If I don't have my  files on my watchlist it's taking WP:OWN to a new horizon; IOW, that's no serious issue, or is it? –Be..anyone (talk) 14:48, 9 August 2011 (UTC)

That's no different from how the Toolserver Gallery tool works (when it works, that is). —LX (talk, contribs) 05:17, 10 August 2011 (UTC)

Support Great ideas. --James Heilman, MD (talk) 23:03, 15 August 2011 (UTC)

Support Wonderful idea. Uploads are a big part of what matters here on Commons, and it's nice to see the actual uploads instead of just a new file alert in a stream of wiki page edits. Steven Walling • talk 00:27, 22 August 2011 (UTC)

Implementing addition

See it in action: add importScript('User:Rd232/myuploads.js'); to your custom Javascript page, at Special:MyPage/skin.js. Rd232 (talk) 23:05, 4 August 2011 (UTC)

MediaWiki:Listfiles-summary needs to be edited for clarification. It should say (I think)

When filtered by user (Special:ListFiles/username), only files where that user uploaded the most recent version of the file are shown.

We're agreed that we want that situation changed (option to show files even if the most recent version is from another user), but that's the status quo, I believe, and we should be clear about that. Rd232 (talk) 23:19, 4 August 2011 (UTC)

I hope I did everything right on TW and the message will change soon. -- RE rillke questions? 23:44, 4 August 2011 (UTC)

OK; I see what you did. I know nothing about TranslateWiki, but I see [3] it's supposed to be updated within 48 hrs. Rd232 (talk) 00:37, 5 August 2011 (UTC)

Well, that clearly hasn't worked. Rd232 (talk) 11:52, 11 August 2011 (UTC)

Improving Special:MyUploads

I like the original idea, but we can also add options for interested users to view a summary of licenses, tags or other information in Special:MyUploads instead of the toolserver gallery.   ■ MMXX  ^talk  14:05, 1 August 2011 (UTC)

OK, we can talk about that and file a bug. Let's try and be as specific as possible about what's needed, including what improvements to prioritise. The only relevant bug I can see is Bugzilla: 28074, which is asking for a per-user version of Special:NewFiles, for a gallery approach to summarising a user's uploads. Rd232 (talk) 14:19, 1 August 2011 (UTC)

I would like per-user version of Special:NewFiles much better than current Special:MyUploads. Another important issue is what to do when someone reuploads the file - in the past I was working with watermark removal and a lot of users were upset about me "stealing" their files, since they dissapeared from their gallery. Those files also appeared in my gallery which become useless. It would be great if the default was all files you uploded with possibility to show only the subset where you are or are not the first or the last uploder. Current version of Special:MyUploads also removes the uploads from someones list if file is reuploded. --Jarekt (talk) 15:23, 1 August 2011 (UTC)

Fair enough. If we're thinking about filtering options on Special:MyUploads (as I am), then options around reuploads can be part of that: "show files I've reuploaded", "show files I've uploaded even if they've been overwritten by others". Rd232 (talk) 18:59, 1 August 2011 (UTC)

Another issue in Special:MyUploads has description column, which seems to be empty for most of my uploads. I do not know if it was meant to show the current or the original description, but it is clearly not working. --Jarekt (talk) 15:29, 1 August 2011 (UTC)

The description column shows the log. Warning: Advertising: BTW my script returns only your uploads. -- RE rillke questions? 15:36, 1 August 2011 (UTC)

For the normal users it would be easier if they could filter Special:NewFiles by user's name, so they can actually see a gallery, which means more images in one page. but for reviewers Special:MyUploads is better, but of course it needs to show more details, IMO we can have many features of toolserver gallery in Special:MyUploads.   ■ MMXX  ^talk  15:39, 1 August 2011 (UTC)

I think it would be ideal if the features of Special:NewFiles (with per-user filtering) and an enhanced version of Special:MyUploads (actually Special:ListFiles with per-user filtering) were available on the same page, as display/filtering options. In terms of purpose of that page, it makes most sense to enhance Special:MyUploads, by borrowing the gallery feature of Special:NewFiles. That ought to be easy (?? well you never know). Rd232 (talk) 18:55, 1 August 2011 (UTC)

Draft feature list

• Option to switch between gallery display (from Special:NewFiles) and current list display
• "show files I've reuploaded", "show files I've uploaded even if they've been overwritten by others".

What else? I'm hampered by not being able to see the Gallery tool. Rd232 (talk) 19:02, 1 August 2011 (UTC)

• Don't show files I reverted. -- RE rillke questions? 19:04, 1 August 2011 (UTC)
• Camera make and model from EXIF if available; link to file log and history (not shown in the Gallery tool, but they should be); file dimensions; templates; categories. As for filtering, provide these alternatives: (1) Initial uploads (i.e. files where the user uploaded the first revision, regardless of later uploads) (2) Latest uploads (i.e. files where the user uploaded the latest revision, regardless of prior uploads) (3) All uploads (i.e. all files where the user appears in the file history table), followed by a checkbox to exclude reversions (i.e. excluding files where all upload log entries by the user have the summary "Reverted to version as of..."). —LX (talk, contribs) 19:40, 1 August 2011 (UTC)
• "current list display" should use normal gallery-sized thumbnails, - right now width is fixed, portrait-oriented images overwhelm the screen. As for contents, - list categories, show any {{Delete}} and {{No permission}} warning. In addition to what's already there in gallery, I'd like to see a clear warning if there's "No License" at all. Sometimes when I re-categorize backlog files, I accidentally overwrite original license, and there is no quick check tool. Exif? A full exif is not practical here. There could be a simple color-coded notice: green for full-blown exif with camera, exposure etc, yellow for just "Adobe Photoshop 72 dpi", and red for no exif at all (but then it's only meaningful for {{Own}} photographs). NVO (talk) 06:22, 2 August 2011 (UTC)

 Done - submitted as Bugzilla: 30522. Rd232 (talk) 00:17, 23 August 2011 (UTC)

Provide a rename-link for files

Often users are unsure how to rename or move a file they uploaded. Therefore I suggest a JavaScript-Solution which will 1st ask for the reason (dropdown) and then for the new name. The link's name should be "Suggest renaming" and should be located where the move this page link normally can be found.

Ideas, objections? -- RE rillke questions? 13:32, 1 August 2011 (UTC)

Well, on the one hand, making things easier is good (if you can find someone to code it). On the other hand, renaming rules (Commons:File renaming) are relatively restrictive and the Javascript would need to provide an effective filter, so some care would need to be taken to be very clear. Even then, you might get a big increase in bad requests; hard to be sure how much of a problem that would be. Rd232 (talk) 14:11, 1 August 2011 (UTC)

Renames cause substantial extra work, create administrator and bot works, fail from times to times and bring little or no additional value. With the energy spent on one rename, one can improve the description on 20 files. So no need to search for additional work. --Foroa (talk) 14:15, 1 August 2011 (UTC)

Although I agree with Foroa and Rd232 but IMO this is not a bad idea and might be helpful to many new users. maybe we could create another template to be used instead of {{Rename}} and be placed in file talk page, the link can also be placed in the sidebar toolbox.   ■ MMXX  ^talk  14:19, 1 August 2011 (UTC)

(ec) "little or no additional value", Foroa? I think you're overlooking the role of filenames in categories; with crappy filenames, it's much harder to browse. Rd232 (talk) 14:25, 1 August 2011 (UTC)

"little or no additional value" indeed. We accept file names in all possible languages, scripts and fonts, we respect the language of the originator, but you want to waste many administrator and system resources for the couple of file names you might possibly understand (not to mention the delinker operations, the hundreds of broken redirects I cleaned up already). In addition, on file names It would be better if the system displays the first part of the description text when browsing in categories. --Foroa (talk) 14:43, 1 August 2011 (UTC)

? most filenames are in English, and the overwhelming majority are in Latin script (where decent naming may give you for instance a recognisable name of an organization, even if you don't know the language). And whatever the cost-benefit of renaming, let's not pretend that good filenames don't make a difference. Your remark about the description is an interesting idea, but it would be technically difficult - probably too technically difficult for it to happen on any timescale worth worrying about. I mean, for the last 5 years we've been asking for page titles to be translated when you're viewing the page, which I'm pretty sure is far easier. (Albeit I think some of the more complex solutions to that would actually make it possible to translate titles when displayed in categories.) Rd232 (talk) 18:19, 1 August 2011 (UTC)

@Rd232: I intended to insert a few traps, like "because the new file-name is slightly better than the old". Script can also check whether it is really uploader's request. BTW, I can code this myself. -- RE rillke questions? 14:36, 1 August 2011 (UTC)

@Foroa: Since I am not an admin, I did not know this. I've just seen the questions at COM:Forum and COM:Helpdesk and sometimes you get tired to answer the same questions. -- RE rillke questions? 14:22, 1 August 2011 (UTC)

A rename button (or tab) that triggers the relevant help page (for regular and speedy delete as well) would already be a major progress. --Foroa (talk) 14:34, 1 August 2011 (UTC)

No bad idea... But what do you think about a combined solution? First, the user is enforced to read the guideline (we can add some scary-massages like if you request a renaming against the guideline, this is considered being vandalism) and then continue? It is possible to find out whether a paricular user ever visited a page. Or we can ask a question which shows whether a user understood... -- RE rillke questions? 14:52, 1 August 2011 (UTC)

@MMXX: I want to keep is as close as possible to the general interface. That's why I would prefer the p-cactions -section. -- RE rillke questions? 14:36, 1 August 2011 (UTC)

"the p-cactions -section" is the dropdown menu (in the Vector skin)? Rd232 (talk) 14:44, 1 August 2011 (UTC)

Yes. But it's the same in monobook, too. -- RE rillke questions? 14:57, 1 August 2011 (UTC)

Yes and no. It displays in monobook too, but as extra tabs, not as a dropdown menu. Rd232 (talk) 18:22, 1 August 2011 (UTC)

I think this is a good idea - keep in mind that the earlier files are renamed, the better. It's rather more annoying to rename them when they're already in wide use. Dcoetzee (talk) 18:57, 11 August 2011 (UTC)

I think it's a good idea. At present it's pretty cumbersome to list files for renaming, even when you notice an obvious typo after uploading. --Terfili (talk) 09:42, 29 August 2011 (UTC)

Creating a policy page

• I recently posed a question on other pages about the policy on suspected child pornography, but not a one person was able to answer me. After contacting legal, one of my associates learned about Wikimedia's policy and was pointed to a page, which is actually located in a place that would take some amount of searching to find. I think it would be beneficial, considering the lack of knowledge on the issue I ran into (and assumptions made about it), that a policy page similar to Commons:Photographs of identifiable people be created. I'm just trying to find out who I need to talk to so I can create this page and incorporate it into the guidelines, since it's a legal policy of Wikimedia.--Henriettapussycat (talk) 20:37, 29 August 2011 (UTC)

This information was originally included at Commons:Sexual content, along with an explanation of the {{2257}} template and other useful things, but that proposed policy was so controversial that it was stripped of all useful content. A number of people have suggested that rather than trying to propose anything, we should create an informational page linking to existing policy relevant to sexual content. I'm not sure what it should be called but it can't use the same title as the existing draft proposal. Dcoetzee (talk) 21:54, 29 August 2011 (UTC)

Yes that's exactly what I'm proposing--an informational page relating to 2257. I just want people to know about this stuff so a fiasco like what happened to my friend and me doesn't happen again. We were quite battered for simply asking if there was a policy, and IMO it would help for people to know there is one set in place. Perhaps we could structure it like the Identifiable People page and put laws for other countries? Just some brainstorming here. I just want to get the info out there so people are aware that WM does have a policy. I'd like to be involved to an extent, but I understand Admins would know more about putting it together.--Henriettapussycat (talk) 23:19, 29 August 2011 (UTC)

I'm going to go ahead and create a draft myself and work on it. I'll post it here when done--that will probably be a while of course.--Henriettapussycat (talk) 03:05, 30 August 2011 (UTC)

The content from Commons:Sexual content was transferred to Help:Sexual content. Dunno if that what you want to put together, but might be a good start. Jean-Fred (talk) 10:10, 30 August 2011 (UTC)