MediaWiki talk:Titleblacklist/Archive/2008-2017
 | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| 2008-2017 |
Not working
This doesn't seem to do anything. :( - Rocket000 00:19, 13 March 2008 (UTC)
- Nevermind. You need to log out to see that it's protected. There should be some type of message for users that can create these pages. - Rocket000 00:40, 13 March 2008 (UTC)
- There is now. – Mike.lifeguard | @en.wb 10:45, 9 April 2008 (UTC)
- I don't see anything. (e.g. HAGGAR). Also, I tried creating a few blacklisted image pages and it doesn't seem to work (that's creating - not uploading, since I was logged out but I figure it's the same). Rocket000 22:14, 17 April 2008 (UTC)
- Sysops apparently don't see the messages, and as this corresponds to full create protection, we can create the pages. You'll have so log out or use a non-sysop doppelganger to see the messages or to be stopped from creating blacklisted pages. I can't find the relevant bug, so I'll create a new one. – Mike.lifeguard | @en.wb 23:00, 17 April 2008 (UTC)
- For reference: bugzilla:13780. – Mike.lifeguard | @en.wb 23:59, 17 April 2008 (UTC)
- Thanks. Voted, should be pretty easy to do. Rocket000 08:59, 19 April 2008 (UTC)
- I don't see anything. (e.g. HAGGAR). Also, I tried creating a few blacklisted image pages and it doesn't seem to work (that's creating - not uploading, since I was logged out but I figure it's the same). Rocket000 22:14, 17 April 2008 (UTC)
Upload error for old files
Hi all, my Bot Rotatebot don't know what's a good name and what's a bad name, he rotates everything until you block bad names. So he can't rotate Image:00083.jpg... Image name you entered is senseless. Please, choose another one. That feature may be good for new pictures but it blocks reuploading old ones. Either you disable the Titleblacklist for existing files or you remove this line from the list.. Greetings, --Luxo 21:01, 20 April 2008 (UTC)
- This entry now applies only to anonymous and new users; your bot has passed the autoconfirmed threshold, and should no longer be affected. Hopefully when we get a notice when the blacklist is matched, users will choose a better location (though they'll no longer be forced to do so unless they are new or anonymous). – Mike.lifeguard | @en.wb 21:52, 20 April 2008 (UTC)
- Thanks for the fast fix, works now.--Luxo 19:51, 21 April 2008 (UTC)
Images with bad titles
Hi, I made a mysql query on the toolserver to find all images with bad titles; I became 6177 files, the list is here. I think it should be possible to reduce that to zero if we make that regex apply to everyone. Eventually a bot should add (if not already present) {{rename}} to this files. What do you think? --Luxo (talk) 21:18, 5 August 2008 (UTC)
- I am certainly happy to remove the autoconfirmed caveat on that regex once a few things to prepare are done:
- — Mike.lifeguard | @en.wb 03:09, 6 August 2008 (UTC)
- 3. A bot is in work, see Commons:MediaMoveBot
- 1. If I create MediaWiki:Senselessimagename/de, does german user see this message?
- 2. I think first we should activate the regexp for all users to avoid new files with bad name. Perfect would be a script to add the {{rename}} template, which make a proposal name, I will look if I can do that. PS: Please add
\(and\)to[0-9_ \-], there are some files named e.g. CIMG2433_(747698196).jpg.--Luxo (talk) 15:48, 6 August 2008 (UTC)
Regexp added- Not sure about how the system messages work in that case. — Mike.lifeguard | @en.wb 16:17, 6 August 2008 (UTC)
- In response to 1 (or 2 really), yes, anyone using the German interface will see that message instead of the default English one. You can test it by adding &uselang=de at the end of the url, or if you want them all: {{Interface-lang}}, which is good to have around the MediaWiki namespace). Rocket000 (talk) 16:50, 6 August 2008 (UTC)
- MediaWiki:Filename-bad-prefix is similar to the message we require. Probably we could adapt this message partially.--Luxo (talk) 23:27, 8 August 2008 (UTC)
- In response to 1 (or 2 really), yes, anyone using the German interface will see that message instead of the default English one. You can test it by adding &uselang=de at the end of the url, or if you want them all: {{Interface-lang}}, which is good to have around the MediaWiki namespace). Rocket000 (talk) 16:50, 6 August 2008 (UTC)
.jpg&action=edit&redlink=1){kind=link}
Updating
OK, so we should probably split this into multiple regexen. One, which we already have is for prefixed images like DSCN4444.jpg. Another should be for long strings of consonants. Another for long strings of numbers only. Maybe more. We're trying to do too much with one line, and was causing false positives like Image:Tram_STAR_Be_4/8_112.jpg — Mike.lifeguard | @en.wb
Translate Mediawiki message Senselessimagename ?
List
Discussion
This list is very red and I think it's not very easy to translate that all. But it would be nice if we could take MediaWiki:Filename-bad-prefix
The name of the file you are uploading begins with "$1", which is a non-descriptive name typically assigned automatically by digital cameras. Please choose a more descriptive name for your file.
which is already translated. For $1 we could take "PICT, DSC, image, ..."
The name of the file you are uploading begins with PICT, DSC, image, ..., which is a non-descriptive name typically assigned automatically by digital cameras. Please choose a more descriptive name for your file.
what do you think? --Luxo 13:45, 17 August 2008 (UTC)
- Sounds fine to me. Is there a way to automate the process? I am especially lazy today :) — Mike.lifeguard | @en.wb 15:06, 17 August 2008 (UTC)
- I think it is, yes. But I'm most likely until Thursday away, so I can't do it until then. I will look if I come back; if the list is still red, I will do it, if not, I'm not unhappy. ;)--Luxo 19:17, 17 August 2008 (UTC)
- Done; I create 153 pages. This one which are red had no translated version of MediaWiki:Filename-bad-prefix. --Luxo 15:44, 21 August 2008 (UTC)
- We should figure out whether the regex being matched is a parameter for that system message (ie can we show them the regex the filename matches against?) — Mike.lifeguard | @en.wb 19:39, 21 August 2008 (UTC)
- I think that's not possible at the moment, except we made for every match a line and a page.--Luxo 20:57, 21 August 2008 (UTC)
- We should figure out whether the regex being matched is a parameter for that system message (ie can we show them the regex the filename matches against?) — Mike.lifeguard | @en.wb 19:39, 21 August 2008 (UTC)
Meaningless file names
{{editprotected}}
Some time ago, I added some rules to the title blacklist on en.wikipedia to disallow some common meaningless file names, and wrote a custom error message for them. They've been active on the English Wikipedia for a couple of months now with no complaints, so I thought I should suggest the possibility that Commons might want to adopt a similar ruleset.
Some of these are similar to the existing filename prefix blacklist (which only generates a warning). Others check for file names that consists almost entirely of numbers, punctuation and possibly a few common meaningless prefixes and suffixes. Yet others check for common autogenerated file names, e.g. from image sharing sites, where these are not already caught by the more general rules.
Some points to note:
- The "reupload" keyword allows uploading new versions over existing files that might happen to match these rules. Commons does have quite a few of these, so this is a useful feature, even though it also allows accidental reuploading of new, unrelated files over these titles.
- The custom error message should also be copied (with appropriate adjustments) to the corresponding page on Commons, and preferably translated.
- Just to be sure, I'll repeat that these rules have been in place for several months on the English Wikipedia, with no reported false positives.
Here's the ruleset I'm proposing be added. It's a slightly cleaned up (cosmetic changes only, should match the exact same titles) version of the one currently at en:MediaWiki:Titleblacklist.
# GENERIC IMAGE FILE NAMES (with custom error message) # At most three letters of potentially meaningful text: File:\P{L}*((Ima?ge?|Pict?(ure)?|Media|Photo)\P{L}+)?(\p{L}\P{L}*){0,3}((orig|copy|thumb|small)\P{L}*)?\.[^.]+ <reupload | errmsg=titleblacklist-custom-imagename> # No more than two contiguous letters (raising to three would be tempting, but needs more testing): File:\P{L}*((Ima?ge?|Pict?(ure)?|Media|Photo)\P{L}+)?(\p{L}{1,2}\P{L}+)*((\p{L}{1,2}|orig|copy|thumb|small)\P{L}*)?\.[^.]+ <reupload | errmsg=titleblacklist-custom-imagename> # Month name followed by no more than two contiguous letters, JPEG suffix (be careful if you edit this, easy to trigger false positives): File:\P{L}*(January|Jan|February|Febr?|March|Mar|April|Apr|May|June?|July?|August|Aug|September|Sept?|October|Oct|November|Nov|December|Dec)(\P{L}+\p{L}{1,2})*\P{L}*\.JPE?G <reupload | errmsg=titleblacklist-custom-imagename> # Common digital cameral file names, based on list at http://diddly.com/random/about.html # See also MediaWiki:Filename-prefix-blacklist, used to generate a warning on the upload form File:DCP\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Kodak File:DSC.\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # w:Design rule for Camera File system (Nikon, Fuji, Polaroid) File:MVC-?\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Sony Mavica File:P[\dA-F]\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Olympus, Kodak File:I?MG[P_]?\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Canon, Pentax File:1\d+-\d+(_IMG)?\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Canon File:(IM|EX)\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # HP Photosmart File:DC\d+[SML]\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Kodak File:PIC[T_]?\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Minolta File:PANA\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Panasonic File:DUW\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # some mobile phones File:CIMG\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Casio File:JD\d+\.JPG <reupload | errmsg=titleblacklist-custom-imagename> # Jenoptik # Other common patterns, add more as needed File:\d{9}[A-Z]{6}_[A-Z]{2}\P{L}*\.\w+ <reupload | errmsg=titleblacklist-custom-imagename> # some image hosting site? File:\d{8,}_[\dA-F]{10}(_[A-Z])?\P{L}*\.\w+ <reupload | errmsg=titleblacklist-custom-imagename> # another image hosting site? File:([\dA-F]{8}-)?[\dA-F]{4}-[\dA-F]{4}-[\dA-F]{4}-?[\dA-F]{12}.* <reupload | errmsg=titleblacklist-custom-imagename> # w:UUID (with some variations included) File:([SML]|\d+)_[\dA-F]{10,}(-\d+-|_?(\w\w?|full))?\.[^.]+ <reupload | errmsg=titleblacklist-custom-imagename> # L_9173c67eae58edc35ba7f2df08a7d5c6.jpg, 2421601587_abaf4e3e81.jpg, 1_bf38bcd9c5512a5ab99ca2219a4b1e2f_full.gif, etc. File:\P{L}*No\P{L}*name\P{L}*\.[^.]+ <reupload | errmsg=titleblacklist-custom-imagename> # Noname2.jpg
—Ilmari Karonen (talk) 16:17, 29 December 2008 (UTC)
Ps. The similar existing rule
Image:(?:copy of)?(?:default|DVC|C?IMGP? ?|PICT|DSC[FN]?|DUW|JD|MGP|scan|untitled|foto|imagen|image|picture|p|BILD)[0-9_ \-\(\)\{\}\[\]]+\..* <reupload|errmsg=senselessimagename>
has effectively been disabled by the "Image" -> "File" namespace name change. It should be fixed to start with "File:" instead of "Image:". —Ilmari Karonen (talk) 16:22, 29 December 2008 (UTC)
- Fixed.--Luxo 21:57, 29 December 2008 (UTC)
We already have a custom system message for this purpose. I had intended to split up the regex in something like this manner anyways (see above), so I don't see any issue with doing this. — Mike.lifeguard | @en.wb 22:14, 29 December 2008 (UTC)
- Done — Mike.lifeguard | @en.wb 03:46, 4 January 2009 (UTC)
Blocking upload of pronunciation files
With currents settings it's impossible to upload a file with name "Ru-у.ogg". This name is required by pronunciation files naming rules. It has to be possible to upload files matching /[a-zA-Z]{2,3}-[^.]+\.ogg/. --Derbeth talk 01:44, 6 January 2009 (UTC)
- It's not a rule and it's a bad suggestion. I left comments on COM:VP explaining why. For now, I've commented out the regex so you may upload the file. — Mike.lifeguard | @en.wb 01:55, 6 January 2009 (UTC)
- Whitelist might be an option. — Mike.lifeguard | @en.wb 01:56, 6 January 2009 (UTC)
- Yes, a whitelist entry for "File:[a-z]{2,3}-.*\.ogg" would seem reasonable. —Ilmari Karonen (talk) 03:53, 6 January 2009 (UTC)
- Just filed an {{Editprotected}} request at MediaWiki talk:Titlewhitelist#Exempt pronuncation files from title informativeness checks. —Ilmari Karonen (talk) 05:13, 7 January 2009 (UTC)
Too restrictive
The blacklist system is too restrictive: it should at least let say "yes it is the right name for that file"; for example I was willing to upload Image:Ks Hp0+Zs1.gif and Image:Ks Zs3v.svg but it has been blocked (while Image:Ks Hp0.svg, Image:Ks Ks1.svg and other ones are already uploaded).
François [Discussion] 15:59, 15 January 2009 (UTC)
Other files I would not have had a possibility to upload: Image:CFA.svg, Image:SIV.jpg, Image:CX-D.45.jpg, Image:HLE 2248.jpg.
- Is there some pattern to these seemingly random abbreviations? If so, it might be possible to add an exception. (And if not, why not just upload under a name that actually tells other people what the file is about?)
- In general, the blacklist rules that seem to be causing the most complaints are the "at most three letters" and "at most two consecutive letters" ones. If these do turn out to be too restrictive for Commons, I wouldn't mind seeing them removed or reduced to, say, "at most two letters total". Indeed, it may well be that those particular rules are not as useful on Commons as at en.wikipedia, given that we probably don't get quite as many people here uploading files with no indication of their subject matter whatsoever, in the file name or elsewhere.
- Also, the current error message shown for these blacklist entries is rather terse and, for some of the rules, somewhat misleading. The one I wrote for en.wikipedia is IMHO a bit more friendly and informative, if I may say so myself. —Ilmari Karonen (talk) 19:43, 15 January 2009 (UTC)
- However, it was already translated into many language (see prefixindex) - yours is not. — Mike.lifeguard | @en.wb 21:20, 15 January 2009 (UTC)
- That's true, and a sensible reason for going with it for now. Of course, in the long run we should write a better message and translate it. To that end, I've just started a translation project in my userspace: any suggestions, improvements and new translations are welcome. (I've only done English and Finnish so far; may have a go at Swedish / German / French later if no-one else gets there first.) —Ilmari Karonen (talk) 12:58, 16 January 2009 (UTC)
- Added Swedish and German translations too, though I'm sure my German is atrocious and needs to be fixed by a native speaker. Could you by any chance do a French translation, François? (Or fix my mistakes if I try to write one?) Anyway, is there some specific place where I could ask for help with translation projects like this? I tried to look for one, but couldn't immediately find anything. —Ilmari Karonen (talk) 16:38, 17 January 2009 (UTC)
- That's true, and a sensible reason for going with it for now. Of course, in the long run we should write a better message and translate it. To that end, I've just started a translation project in my userspace: any suggestions, improvements and new translations are welcome. (I've only done English and Finnish so far; may have a go at Swedish / German / French later if no-one else gets there first.) —Ilmari Karonen (talk) 12:58, 16 January 2009 (UTC)
- However, it was already translated into many language (see prefixindex) - yours is not. — Mike.lifeguard | @en.wb 21:20, 15 January 2009 (UTC)
- Indeed these are the two rules I find too restrictive — why complicate a filename when it uniquely identify the resource? — and I completely agree with you for the message on Commons: it should at least give a link to an explication page I think...
- François [Discussion] 22:54, 15 January 2009 (UTC)
- Filenames are supposed to be descriptive. File:Ks Ks1.svg is the exact opposite & should be renamed to some meaningful title. OTHERCRAPEXISTS is an argument to deal with that crap, not to allow new crap. — Mike.lifeguard | @en.wb 23:11, 15 January 2009 (UTC)
- I don't think, that filenames are supposed to be descriptive. Categories and file descriptions are enough to describe the file. It has a lot of disadvantages, taht you have to use descriptive filenames. i.E. you maybe forced to use a different filename then on the local system, so maybe later you don't know anymore, which files you have already uploaded, which can lead to redundancies. Aölso, sometimes itr's hard to find a desciptiove filname or you only find very long descriptive filenames. And if you have a lot of images, which are similar, you still will have to use numbers or something to get different filnames. Also the user is forced, to waste time, by finding the file on the HDD again and reentering all informations. So I don't think, that it is a good idea, to force users to use dscriptive filnemaes, so I think that that blacklist schould be removed. --MrBurns (talk) 09:50, 6 November 2009 (UTC)
- Filenames are supposed to be descriptive. File:Ks Ks1.svg is the exact opposite & should be renamed to some meaningful title. OTHERCRAPEXISTS is an argument to deal with that crap, not to allow new crap. — Mike.lifeguard | @en.wb 23:11, 15 January 2009 (UTC)
Filenames for Stroke Order Project is denyed
{{editprotected}}
The files having names of「ヴ-bw.png」「ゔ-bw.png」(series of Commons:Stroke Order Project/Hiragana / Commons:Stroke Order Project/Katakana) are denyed. Such filenames already are widely used in Commons:Stroke Order Project and thousands of images are remain to be uploaded (Category:Bw.png stroke order images). I'm not sure which of these regular expressions has matched, could someone change this page not to match with such filenames, please. Sorry for my poor English, D.328 2009/02/2 08:33 (UTC)
- It's the "no more that two contiguous letters" rule again. Adding something like "
File:[\p{Han}\p{Katakana}\p{Hiragana}]-bw\.png" to MediaWiki:Titlewhitelist ought to fix it. —Ilmari Karonen (talk) 21:22, 4 February 2009 (UTC)- Done — Mike.lifeguard | @en.wb 21:47, 4 February 2009 (UTC)
- I really appreciate your help! -- D.328 2009/02/6 16:45 (UTC)
Can't upload a new version of this file
[1] Get the following error:
![[1]](https://commons.wikimedia.org/wiki/File:St._Patrick%27s_Northern_Ireland_Flag_Hexagon.svg){kind=link}
- You do not have permission to do that, for the following reason:
The name of the file you are uploading begins with PICT, DSC, image, ..., which is a non-descriptive name typically assigned automatically by digital cameras. Please choose a more descriptive name for your file. Palomca (talk) 13:59, 5 April 2009 (UTC)
- Sorry, I cannot find the entry preventing you from doing this... reupload is permitted on anything that even comes close. — Mike.lifeguard 22:00, 5 April 2009 (UTC)
Exception for Unicode characters
I tried to move Image:U+2139.svg from Wikipedia to here and was told that it had a "Senselessimagename". Most images of Unicode characters, such as this, have this filename format (U+XXXX). See for example the plethora already here at Commons and at wikipedia (and Image:U+2132.svg that Platonides just upload for me with his admin ability). Can there be an exception added for this format? Cheers. --Bequw (talk) 20:41, 16 April 2009 (UTC)
{{editprotected}} Makes sense. Adding File:U\+[0-9A-F]+\.\w+ to MediaWiki:Titlewhitelist ought to do it. —Ilmari Karonen (talk) 15:57, 17 April 2009 (UTC)
- Done & thanks for providing a regex. — Mike.lifeguard 19:25, 24 April 2009 (UTC)
Exception for NGC and IC
It looks strange, but if I try to upload files starting with NGC and IC (astronomical catalogues), I'm not able to procede because of this blacklist. Can you make please an exception for theese two names? --Roberto Segnali all'Indiano 16:34, 27 April 2009 (UTC)
- Ok done by Howcheng. --Roberto Segnali all'Indiano 17:13, 27 April 2009 (UTC)
UGC also
- We need another exception for astronomical catalogue UGC (Uppsala Catalogue of Galaxies).
- I provide the regex:
File:UGC[ _]?\d+.(jpg|png) - Maybe you can add it to the previous code for NGC and IC, already present, like this:
File:(NG|I|UG)C[ _]?\d+.(jpg|png) - Thanks! :-) --Roberto Segnali all'Indiano 05:25, 28 April 2009 (UTC)
- Done by Howcheng. --Roberto Segnali all'Indiano 17:57, 29 April 2009 (UTC)
"ARP" also needs whitelisting, it seems (Another astronomical catalogue). Is there a reason why images of the format "ABC 123.jpg" are generally banned, but the error message doesn't explain why? Also, I can't see the regex that does this... Thanks. Mike Peel (talk) 20:17, 23 May 2009 (UTC)
- I can't find the regex either, which is ridiculously frustrating. I've added this to the whitelist, but if this continues much longer I'm going to start nuking regexes. — Mike.lifeguard 21:27, 23 May 2009 (UTC)
- Is all title blacklisting done via this list, or is there anything in the code or LocalSettings.php that could be causing this? Mike Peel (talk) 13:56, 24 May 2009 (UTC)
- It's the one with the comment "At most three letters of potentially meaningful text", and there's a better error message awaiting translation and deployment at User:Ilmari Karonen/titleblacklist-custom-filename. It might be worth deploying anyway, even though it's only been translated to five languages so far. Also, that particular regexp seems to be causing enough false positives here on Commons that we might want to consider removing it. (I tried it out first on en.wikipedia, and received no complaints there, but it seems Commons has more legitimate files with such short names.) —Ilmari Karonen (talk) 15:12, 24 May 2009 (UTC)
- I've commented out that regex, as it's causing too many false positives. Perhaps we can do something softer using AbuseFilter - just a warning if the upload is given a name matching that regex so users can override if necessary. — Mike.lifeguard 22:08, 24 May 2009 (UTC)
- AF don't work for upload's at the moment...--Luxo 09:46, 25 May 2009 (UTC)
- I've commented out that regex, as it's causing too many false positives. Perhaps we can do something softer using AbuseFilter - just a warning if the upload is given a name matching that regex so users can override if necessary. — Mike.lifeguard 22:08, 24 May 2009 (UTC)
- It's the one with the comment "At most three letters of potentially meaningful text", and there's a better error message awaiting translation and deployment at User:Ilmari Karonen/titleblacklist-custom-filename. It might be worth deploying anyway, even though it's only been translated to five languages so far. Also, that particular regexp seems to be causing enough false positives here on Commons that we might want to consider removing it. (I tried it out first on en.wikipedia, and received no complaints there, but it seems Commons has more legitimate files with such short names.) —Ilmari Karonen (talk) 15:12, 24 May 2009 (UTC)
- Is all title blacklisting done via this list, or is there anything in the code or LocalSettings.php that could be causing this? Mike Peel (talk) 13:56, 24 May 2009 (UTC)
AN as well
The An prefix is used for en:Antonov aircrafts. // Liftarn (talk) 16:56, 15 November 2009 (UTC)
Atomium
Please add “File:.*ATOMIUM.*\.JPG” to the title blacklist! --88.78.1.178 19:35, 4 May 2009 (UTC)
- If added, definitely needs a custom error message (like the one at Atomium) and instructions on what to do in case of false positives. (Oh, and the "\.JPG" should either be "\.JPE?G" or left out entirely.) —Ilmari Karonen (talk) 20:50, 4 May 2009 (UTC)
- I'm guessing to prevent copyvios? lol, think about that for a second. That's like saying block all titles with "Mickey Mouse" or "Microsoft Windows" in it. Images of those things don't have to contain those words and titles with those words don't have to contain those things. Rocket000 (talk) 08:35, 5 May 2009 (UTC)
- if really necessary we could probably do something with the AbuseFilter (warn if the upload title contains "atomium").--Luxo 15:30, 5 May 2009 (UTC)
Not done - a terrible idea. Hash matching should be made available through AF for this and similar use-cases. Regardless, the title blacklist is not the appropriate tool to use for this. — Mike.lifeguard 16:44, 5 May 2009 (UTC)
Adobe Flash
Please add “File:.*\.SWF” to the title blacklist! --88.77.234.45 12:54, 6 May 2009 (UTC)
- It's not possible to upload swf files, so it's unnecessary. --Luxo 14:36, 6 May 2009 (UTC)
Why isn't it possible to upload swf files? --88.78.249.183 17:42, 6 May 2009 (UTC)
MP3
Please add “File:.*\.MP3” to the title blacklist! --88.78.249.183 17:46, 6 May 2009 (UTC)
- Uploading MP3 files ain't enabled, anyway. Please have a look at COM:FT. →Nagy 17:58, 6 May 2009 (UTC)
- Actually, audio/video media files should be checked to see if they contain a copy protection bit or digital signature. This would require a content parser to read the internal tags, and see if their licence is not abused or nominative. The same media files however can embed their own licence information (which may be digitally signed) that could be permitted and used to auto fill the descriptive licence info. They may also contain various documented tags that could be used to help the classification (such as keywords, author's description of the scene, song lyrics). As long as the licence is valid and non-restrictive, such extra data can still be useful.
- But detecting a copy protection bit (notably in MPEG4 files) should immediately force the media file to be rejected.
- Encrypted data fields in files (that are intended to be decrypted for use, with the help of a separate private key) should be also rejected (the only exception being for the digital signature which is not really encrypted but concerted into a small opaque binary sequence with a strong one-way hash).
- Otherwise there will be the risk of hosting on MediaWiki servers the code of some trojans embedded within images (but used by malwares running in harvested client machines) to get their updates (I don't know if files submitted to MediaWiki are screened by an antimalware, but to avoid tracking all files if one malware is detected by a security company and downloaded from Wikimedia servers, it will be helpful if all files can also be hashed and searched by their hash (MD5+SHA1 for example). Note that hashing should also permit the detection of duplicates (stored under two distinct names). verdy_p (talk) 16:25, 29 January 2010 (UTC)
Deploying the improved error message for uninformative file names
I'm just about ready to replace the existing error message for uninformative file names with the improved one I've been working on. Even though the new message only exists in five languages so far, it's probably still better than the old one, given that it actually describes the real cause of the error and what to do about it.
To make further translation work easier, and to work around some problems with MediaWiki's language fallback mechanism for custom messages, I've taken the slightly unusual step of putting the actual translations in Template: space, as subpages of Template:Titleblacklist-custom-filename, and transcluding them according to the user's interface language with the help of {{Fallback}}. As far as I can determine from testing (and from what I know of the MediaWiki code), this should be safe even though the templates are not protected, but certainly further testing is welcome. One issue I've already noted is that, when shown as an actual error message, the parsed content is not passed through HTML Tidy like normal page text is, meaning that errors such as unclosed tags are not fixed automatically.
At the moment, the new message can be tested by trying to upload (as a non-admin user) a file with the name File:Ilmari Karonen's title blacklist test image.png. If there are no problems, I'll enable it for real in a day or two. One thing I'm not sure of, and would like some feedback on, is whether I should leave the old message in place for those blacklist entries which it more or less accurately describes, i.e. the ones in the block marked with the "Common digital cameral (sic) file names". Opinions? —Ilmari Karonen (talk) 19:51, 29 May 2009 (UTC)
- It's live now. I've left the digital camera default file name rules to use the old message for now, and moved them up before the other rules so that they'll take precedence. —Ilmari Karonen (talk) 12:09, 4 June 2009 (UTC)
Regex blocking uploading of SVGs depicting U.S. state highway shields
Hi, at some point some regex was added to the blacklist that prevents files named "NY-<number>.svg" from being uploaded to the Commons. I suspect it's getting caught up in the regex used to prevent people from uploading images with the default names cameras give images. The "NY-<number>.svg" files are New York state highway shields, and many other U.S. state highway system shields have similar, and also blocked, conventions (see here for the conventions). From my estimation, 19 of the 50 state highway systems have blocked titles. This makes it impossible to upload new images to the set if necessary; in fact, I've had to upload new images to the English Wikipedia instead because of the blacklist here at Commons. It would be very cumbersome to have to rename all of the shields (probably upwards of 2,000 across the 19 states), so is there a way that the regex can be tweaked to allow the shields to be uploaded with the same conventions as before? Thanks in advance. --TMF Let's Go Mets - Stats 07:54, 4 June 2009 (UTC)
- Done I've added an entry to MediaWiki:Titlewhitelist that should match your naming scheme. Knowing nothing about U.S. highway numbering in general, I've assumed based on existing examples that the "x" in your naming scheme can consist of between 1 to 3 numbers followed by an optional letter, or in some cases prefixed by "US". Is this correct, or are there valid highway numbers that don't match this rule? —Ilmari Karonen (talk) 11:46, 4 June 2009 (UTC)
- I believe that should cover the vast majority, if not all, of the possible file names. The only two states I can think of at the moment with four-digit highway numbers (LA and KY) both have shields with longer conventions that bypass the blacklist. Thanks! --TMF Let's Go Mets - Stats 19:54, 4 June 2009 (UTC)
- Well, I've removed the three-digit upper limit anyway, just to be sure. Have a nice day. —Ilmari Karonen (talk) 21:13, 4 June 2009 (UTC)
- Another issue I've seen is with U.S. Highway shields, which take the form "US <number>.svg". Some states have variants of those shields which take the form "US <number> (<state postal abbreviation>).svg" (examples:File:US 136 (IA).svg,File:US 50 (CA).svg). I am able to update shields that are already uploaded, but I'm not able to add more with that syntax. I discussed it at w:WP:USRD/S/R, and we seem to think the (IA) is what's being blacklisted. --Fredddie™ 20:10, 28 June 2009 (UTC)
.svg){kind=link}
.svg){kind=link}
- Done. Thanks for pointing out the issue. —Ilmari Karonen (talk) 20:14, 29 June 2009 (UTC)
- Thank you. I was able to upload just fine. --Fredddie™ 22:27, 29 June 2009 (UTC)
Hi, I've found another convention that runs into the blacklist regex. I tried to upload new 1960s-era New York shields to "NY-<number> (1960s).svg", but was met with the blacklist message. I imagine that the "NY-<number> (cutout).svg" convention isn't covered by the whitelist either; those shields will be a set of cutout shields that were used in New York from the 1930s to as late as the late 1950s. Can the whitelist be adjusted to allow for both conventions? Thanks in advance. --TMF Let's Go Mets - Stats 00:21, 1 July 2009 (UTC)
- Should be ok now. Let me know if not. — Mike.lifeguard 00:29, 1 July 2009 (UTC)
- Nope, I'm still getting the blacklisted error page when I try to upload "File:NY-382 (1960s).svg". --TMF Let's Go Mets - Stats 00:54, 1 July 2009 (UTC)
- Sorry; I tried again. — Mike.lifeguard 13:06, 1 July 2009 (UTC)
- OK, it works now, at least for the 1960s shields. I haven't tried to upload a cutout yet; if I get an error message, I'll post back here. Thanks! --TMF Let's Go Mets - Stats 16:11, 1 July 2009 (UTC)
- Cutouts should be fine, since they won't trigger the blacklist entry in the first place: it only matches filenames that don't contain at least three consecutive letters. —Ilmari Karonen (talk) 18:32, 1 July 2009 (UTC)
- OK, it works now, at least for the 1960s shields. I haven't tried to upload a cutout yet; if I get an error message, I'll post back here. Thanks! --TMF Let's Go Mets - Stats 16:11, 1 July 2009 (UTC)
- Sorry; I tried again. — Mike.lifeguard 13:06, 1 July 2009 (UTC)
- Nope, I'm still getting the blacklisted error page when I try to upload "File:NY-382 (1960s).svg". --TMF Let's Go Mets - Stats 00:54, 1 July 2009 (UTC)
Another road-related issue: for Pennsylvania's Quadrant Routes, "File:PA QR <number>.svg" (example: File:PA QR 3015.svg) doesn't work for uploads here. ——Mr. Matté — 'pedia talk 22:18, 18 August 2009 (UTC)
Hello, I've found yet another convention that's stopped by the regex. I tried to upload "I-781.svg" tonight and was greeted with the permission error page. "I-781 (long).svg" worked, but I suspect that's because of the "(long)". --TMF Let's Go Mets - Stats 06:39, 11 October 2009 (UTC)
- Done, I think. Let me know if I need to loosen the regexp further. —Ilmari Karonen (talk) 17:33, 11 October 2009 (UTC)
- Yeah, it's still giving me the permissions error. TMF Let's Go Mets - Stats 00:54, 12 October 2009 (UTC)
- Can you try again now? It seems I had a bug in the regexp. :( —Ilmari Karonen (talk) 18:28, 12 October 2009 (UTC)
- OK, it worked now. Thanks! TMF Let's Go Mets - Stats 23:20, 12 October 2009 (UTC)
- Can you try again now? It seems I had a bug in the regexp. :( —Ilmari Karonen (talk) 18:28, 12 October 2009 (UTC)
- Yeah, it's still giving me the permissions error. TMF Let's Go Mets - Stats 00:54, 12 October 2009 (UTC)
Hello again. I tried to upload "US 23A.svg" today, but received the permissions error again. Maybe the A threw it off; I'm not sure. --Fredddie™ 22:23, 20 November 2009 (UTC)
- Done, should work now. —Ilmari Karonen (talk) 03:11, 21 November 2009 (UTC)
Photo.jpg
I recently noted a Photo.JPG in the Latest Files; perhaps it and some of its relatives should be added to the titleblacklist. It looks like File:\P{L}*((Ima?ge?|Pict?(ure)?|Media|Photo)\P{L}+)?(\p{L}{1,2}\P{L}+)*((\p{L}{1,2}|orig|copy|thumb|small)\P{L}*)?\.[^.]+ is intended to match, but doesn't.--Prosfilaes (talk) 22:26, 15 June 2009 (UTC)
New Brunswick (Canada) Provincial Highway Shields
Very much the same nature as the New York Highway Shields, I have had the same problem attempting to submit those missing for New Brunswick using the naming format presently shared by existing shields. (eg: 
uses the filename NB 104.png).
I attempted to submit NB 134, but get the message:
The file name you were trying to upload ("File:NB 134.PNG") has been blacklisted because it is a very common or uninformative one.
All existing images can be found in Category:Road signs in New Brunswick. Could this blacklist be relaxed somewhat so as to submit other NB route shields?
Thanks
Gordalmighty (talk) 16:19, 13 July 2009 (UTC)
- Done Files named e.g. "NB 123.png" should be allowed now. —Ilmari Karonen (talk) 17:31, 13 July 2009 (UTC)
- Everything appears to work fine now. Thank you very much! Gordalmighty (talk) 01:15, 14 July 2009 (UTC)
Request to remove D-44 from the blacklist
I tried to upload a picture of a D-44 divisional gun in Polish Army Museum that I made while I was there a few days ago but I can't because the name File:D-44.jpg is apparently very common or uninformative one. Regards. - SuperTank17 (talk) 11:52, 27 July 2009 (UTC)
- "D-44 divisional gun.jpg" or even "D-44 divisional gun in the Polish Army Museum.jpg" would pass the blacklist. Is there some specific reason why you need to name your picture just "D-44.jpg"? —Ilmari Karonen (talk) 13:23, 27 July 2009 (UTC)
- Not really but this type of name certainly can't be labeled as uninformative since it directly names the subject of the picture. I'll use a different name for now. Regards. - SuperTank17 (talk) 14:25, 27 July 2009 (UTC)
- I would say it's not that informative, in that just seeing "D-44.jpg" wouldn't really have given me any hint that it was a picture of a gun. If anything, I might've expected a fairly large brassiere. Or perhaps HMS Danae or Imogen, or a Chinese sofa. Granted, the gun is the first thing a Google search for "D-44" turns up, but it's far from the only thing in the world going by that letter/number combination. —Ilmari Karonen (talk) 15:34, 27 July 2009 (UTC)
Haggerston railway station
Hi! I see you're administrators so I have a query. I tried to upload a picture of the upcoming London Overground station at Haggerston (a suburb of East London), but it appears that the string "Hagg" is on the blacklist, and I got a Permissions Error. It has been brought to my attention that pictures already exist with "Haggerston", but it appears that they were uploaded before the Blacklist was updated. best, Sunil060902 (talk) 23:12, 2 September 2009 (UTC)
- It seems to have been sorted - thanks! best, Sunil060902 (talk) 23:45, 3 September 2009 (UTC)
User name on Commons
How am I supposed to edit commons:User_talk:×× to warn the user that I am proposing his file for deletion ? Teofilo (talk) 23:26, 17 September 2009 (UTC)
- By clicking on the link? It takes me to an edit page. Lupo 10:24, 18 September 2009 (UTC)
- But to the wrong one, even if one strips the "Commons" prefix. You're a victim of a bug in Magnus's upload bot, which seems to doubly urlencode. The correct page is User talk:חי. (How did I get there? Magnus's bot produces %C3%97%C2%97%C3%97%C2%99. It also produces "%C3%83%C2%9F" for "ß", which should be just "%C3%9F". I decoded the first part ("%C3%83%") and got ... C3. Then the second part and got "9F". Hence it was doubly encodedc. Decoding "%C3%97%C2%97%C3%97%C2%99" gives "%D7%97%D7%99", which then decodes as the Hebrew characters חי.) Lupo 11:00, 18 September 2009 (UTC)
- I've added code in MediaWiki:Notifier.js so that the "nominate for deletion", "no source", "no license", "no permission", and "report copyright violation" links in the sidebar can undo this double encoding of Magnus's bot and can find the correct user talk page. MediaWiki:Gadget-GalleryDetails.js has also been updated. Lupo 13:06, 18 September 2009 (UTC)
- But to the wrong one, even if one strips the "Commons" prefix. You're a victim of a bug in Magnus's upload bot, which seems to doubly urlencode. The correct page is User talk:חי. (How did I get there? Magnus's bot produces %C3%97%C2%97%C3%97%C2%99. It also produces "%C3%83%C2%9F" for "ß", which should be just "%C3%9F". I decoded the first part ("%C3%83%") and got ... C3. Then the second part and got "9F". Hence it was doubly encodedc. Decoding "%C3%97%C2%97%C3%97%C2%99" gives "%D7%97%D7%99", which then decodes as the Hebrew characters חי.) Lupo 11:00, 18 September 2009 (UTC)
Lepcha language
I don't know which so-called "regular expression" I was hitting, possibly the "Supported Unicode range" one. But I can't upload file with name "ᰕᰫ་ᰊᰪᰰ་ᰆᰧᰶ ᰛᰩᰵ་ᰀᰪᰱ ᰛᰪᰮ་ᰀᰪᰱ.SVG" (which is completely in Unicode Plain I (BMP) ). And I think let the upload find "which regular expression you're hitting" is a very bad idea because that's the administrator's work, and we uploaders are NOT experts! --虞海 (talk) 05:46, 6 December 2009 (UTC)
- Are you sure you're hitting the title blacklist? The filename you posted doesn't match anything on either the local or global blacklists. --Carnildo (talk) 20:43, 7 December 2009 (UTC)
- I am quite sure, for I uploaded 2 times.
- Just try to upload a file called File:ᰕᰫ་ᰊᰪᰰ་ᰆᰧᰶ.SVG and trace it. It's debugger's work to testing the program, not us uploaders' work. We just feedback errors. --虞海 (talk) 10:05, 8 December 2009 (UTC)
- "The file name you were trying to upload ("File:ᰕᰫ་ᰊᰪᰰ་ᰆᰧᰶ.SVG") has been blacklisted because it is a very common or uninformative one." again. --虞海 (talk) 10:07, 8 December 2009 (UTC)
- I found the problem. It's this regex:
File:\P{L}*((Ima?ge?|Pict?(ure)?|Media|Photo|Foto|Bild|Scan)\P{L}+)?(\p{L}{1,2}\P{L}+)*((\p{L}{1,2}|orig|copy|thumb|small)\P{L}*)?\.[^.]+
- Apparently \p{L} doesn't match Lepchan letters. Someone with admin access will need to fix this. --Carnildo (talk) 21:57, 8 December 2009 (UTC)
- I found the problem. It's this regex:
- Thank you! --虞海 (talk) 05:31, 10 December 2009 (UTC)
- I have temporarily disabled the regex, because it is IMO completely broken with regards to Unicode. See #Contiguous letters for more. --Mormegil (talk) 12:17, 10 December 2009 (UTC)
Contiguous letters
The „no more than two contiguous letters“ regexp seems completely broken to me. It assumes that every useful filename contains words longer then two letters. Two issues come to my mind about that: 1. Ideographic scripts might be able to express useful filenames using just two-letter descriptions. (And I believe we allow names using any scripts and any language.) 2. It ignores the existence of combining diacritical marks in Unicode; you can create a long word with a name which contains many letters with combining marks (which cannot be precomposed), in which case, the regex will detect only the letter sequences between two consecutive combining diacritics. E.g. File:Oḍ̇em.jpg will fail the test, because the regexp sees two letters (Oḍ), then a non-letter (the combining dot above) and then two letters (em), no three consecutive letters, even though this is a valid four-letter name. This problem has been hit above at #Lepcha language.
I have temporarily disabled the regex. If somebody feels like rewriting it to cope with Unicode properly, you are free to do so. However, are you sure it serves any useful purpose…?
--Mormegil (talk) 12:17, 10 December 2009 (UTC)
- I never liked that rule. It's just an unnecessary restriction based on wrong assumptions (narrow view of language) that causes more problems then it supposedly prevents. I support removing it completely. Rocket000 (talk) 21:04, 10 December 2009 (UTC)
- Thank you! I success. --虞海 (talk) 02:42, 11 December 2009 (UTC)
The issues with Han ideographs and combining marks should be easy enough to fix, by changing the regexp to e.g.
File:\PL*(([^\PL\p{Han}]\pM*){1,2}[^\pL\pM]\PL*)*([^\PL\p{Han}]\pM*){0,2}\.[^.]+
(with the parts matching meaningless prefixes and suffixes omitted for clarity). That said, if the general consensus is not to apply this blacklist rule on Commons, I have no problems with that. Note, though, that its intended purpose was to block filenames like S748850163_337271_5954.jpg; if it's permanently disabled, perhaps a narrower variant like
File:[ !-@[-`{-~]*([A-Za-z]{1,2}[ !-@[-`{-~]+)*[A-Za-z]{0,2}\.[^.]+
("ASCII only, at most two contiguous letters") might be useful? —Ilmari Karonen (talk) 07:43, 31 December 2009 (UTC)
- Ps. Thanks for reporting the issue with combining marks; I've fixed the corresponding blacklist rule on en.wikipedia to allow them there too. —Ilmari Karonen (talk) 08:01, 31 December 2009 (UTC)
Merge with Usernameblacklist
{{editprotected}} I'd like to merge the username blacklist into this blacklist, as it's obsolete. However, I also don't want to make things worse by allowing vandals to choose inappropriate usernames, so I thought it's best to check the syntax on the talk page first. Unlike as with the abuse filter, one can't check the syntax first.
# USERNAMES
.*kanonkas.* <newaccountonly>
.*fr[iíl]tz(?: *(?:g\b|urin)|(?-i:G)).* <newaccountonly>
.*(nigg(er|a)|bitch|asshole|bastard|shit|fu[c(k]k).* <newaccountonly>
.*(penis|vagina|cunt|fellatio|cunnilingus).* <newaccountonly>
.*(molests|masturbates|sucks|incest|slut|rape[sd]).* <newaccountonly>
.*va[gġ]ina.* <newaccountonly>
.*coċk.* <newaccountonly>
.*h[iíl1]t(?-i:[LlI1])[e3]r.* <newaccountonly>
.*[ií1]d[ií1][o0]t.* <newaccountonly>
.*(\bs|S)(?i:crotum).* <newaccountonly>
.*(\bo|O)(?i:rgasm).* <newaccountonly>
.*\.(com|org|co\.uk|net|info)\b.* <newaccountonly>
.*((wiki([mp]edia(?!n)|books|quote|versity|source|news|species)|wiktionary)) <newaccountonly>
.*\b(admin|sysop|moderator|arbitrator|checkuser|oversight).* <newaccountonly>
.*(jimbo wales).* <newaccountonly>
.*(\bo|O)(n wheels).* <newaccountonly>
.*(gra(w|vv|ww)p).* <newaccountonly>
.*卍.* <newaccountonly>
.*卐.* <newaccountonly>
.{30,} <newaccountonly>
# GERMAN CUSSWORDS
.*ka[ck]k.* <newaccountonly>
.*[s$]che?(?-i:[Iiíl](?:ß|[Ss$]{2})).* <newaccountonly>
.*[a4]rsch[lI].* <newaccountonly>
.*w[iíl1](?:chs|x{1,3})[e3]?r.* <newaccountonly>
.*f[iíl]ck.* <newaccountonly>
.*hurens[oÖö].* <newaccountonly>
Thanks for any help. --The Evil IP address (talk) 10:22, 6 January 2010 (UTC)
- You mean MediaWiki:Usernameblacklist? It seems you left out some "\b" anchors; your suggested regexps above would match "Scunthorpe", "Sniggers" and "Grapes". (Although, even with the anchors added, they'd still match "Shitake", "Niggardly" and "Rapeseed" unless you achored the other end too.) Also, you could easily add the "no more that 9 caps in a row" and "no leading or multiple exclamation points" regexps which you left out:
.*[A-Z ]{10}.* <casesensitive | newaccountonly>
!.* <newaccountonly> # I think this is right, but it might need a "User:" prefix
.*!!.* <newaccountonly>
- Also, looking at the list, I spot some possibilities for cross-language false positives: slut and fick are a perfectly clean words in Swedish, and Finnish has a few innocent works beginning with "kakk", like kakku and kakkonen. But those are not regressions, in the sense that the same issues are present in the current implementation too. (Which makes me wonder how much effect these rules have in the first place, now that we have SUL: if were to register an account matching one of those rules on the Elbonian Wiktionary, which had no username blacklist, logged in to it and came to Commons, would the blacklist prevent the corresponding Commons account from being created? I rather suspect not, though I haven't tried it.) —Ilmari Karonen (talk) 11:44, 6 January 2010 (UTC)
- So usernames are now treated the same as page titles? If so, there's some redundancy there. Rocket000 (talk) 12:26, 8 January 2010 (UTC)
- Done, thanks for the \b-thing, Ilmari, I totally missed this. About "fuck" and "slut": They're also blocked by the global title blacklist, so it wouldn't be possible to create this account elsewhere and then going to Commons and having problems with our title blacklist. --The Evil IP address (talk) 12:15, 10 January 2010 (UTC)
Burj
Please add “File:.*BURJ.*\.JPG” to the title blacklist! --84.61.165.65 16:41, 15 January 2010 (UTC)
Exception for PNR
I noticed that the image uploader no longer allows me to upload images which begin with the text string PNR. To simplify cataloging of images pertaining to Philippine National Railways, I normally append PNR to the station's name (example: PNR Buendia.jpg). I'm not sure if this is the case only with one image (I was uploading an image for FTI railway station) or with all future images which begin with the string, so I'm hoping this can be checked and, if necessary, exempted from the blacklist. Thanks! --Sky Harbor (talk) 16:09, 23 January 2010 (UTC)
Private use characters (PUA) not banned?
I don't know if this is already checked at a prior level, but it seems that there's no filter against the 6,400 PUA characters in the BMP (U+E000..U+F8FF), and non-characters (at end of the BMP or in the middle of the Arabic compatibility block), or against other special characters at the very end of the BMP (notably U+FFFD, which is a substitute inserted by some systems when their input was incorrectly encoded, such as those containing unpaired surrogates, or invalid UTF-8 sequences) .
Note that unpaired surrogates should already throw decoding exceptions if a page is created though a POST request using UTF-16 (note also that browsers, or scripted bots may assume an incorrect encoding, and will send any "random" byte sequences which may look correct for it under this assumption, if the empty form received by the browser had problems to be decoded in order to known which charset to use when sending back the filled form to the server, or simply because one is trying a bogous beta version of a new minimalist browser).
Titles contained in GET requests parameters are already decoded with UTF-8, and invalid UTF-8 sequences detected by the webserver will also throw an exception that will already cause the submitted form to be rejected. But the origin of the file names could be from a OS that uses characters without Unicode mappings (for example on Macintoshes using a filesystem containing a Apple logo character): U+FFFD substitute are generated without any error during the conversion to Unicode.
Other characters to reject should be also the object substitute, or interlinear controls and other format controls in the last row of the BMP (U+FFFx). Note that \p{Cc} just matches C0 and C1 controls (0x00-0x1F, 0x7F-0x9F).
But some other controls are needed for correct language support; for example, ZWJ and ZWNJ are needed for Indic languages (but useless in Latin/Greek/Cyrillic or near digits and punctuations), but ZWNBSP is probably not needed: see the Unicode 5.0 standard report about IDNA 2008 security and characters rejected in international domain names which talks about these needed controls. This means that you can't simply reject all \p{Cf}.
The titles should also be already normalized to NFC in a lower level, before matching with this blacklist, so you don't have to worry a lot about multiple possible orderings of combining marks.
But it should be possible to filter defective default grapheme clusters (starting by a combining character, zero-width or not, with a non-zero combining class or not).
How can we assert all this in an automated quality test? Most of these tests should be independant of the project or language, so they should not need to use costly regexps. verdy_p (talk) 15:40, 29 January 2010 (UTC)
Untitled
{{Editprotected}} "File:Untitled" in combination with a number doesn't seem to be particularly useful as a file name. There are quite a few though: Special:PrefixIndex/File:Untitled. Recent one: File:Untitled3.JPG. -- User:Docu at 11:30, 19 February 2010 (UTC)
- However, there's a lot of art titled "Untitled...". It's artsy, I guess. Rocket000 (talk) 17:59, 19 February 2010 (UTC)
- We could add just something like
- File:Untitled\d+\.JPG <reupload|errmsg=senselessimagename>
- This would allow "File:Untitled landscape by Rocket000.jpg"? and exclude untitled1.jpg (not sure how case sensitivity and extensions work on this). -- User:Docu at 19:28, 19 February 2010 (UTC)
- Untitled followed only by numbers are indeed no good filenames. This also applies if they're separated from the file with a hyphen (File:Untitled-1.jpg) or in brackets (File:Untitled (2).jpg). "File:Untitled[\d\s\-\(\)]+\.\w+" (I'm not sure we need to escape the hyphen with a backslash) shouldn't give any problems as far as I see it. Btw, the blacklist is case-insensitive, unless you force it to be with the <casesensitive> option and extensions are usually made with "\.\w+" at the end of a string. --The Evil IP address (talk) 20:57, 19 February 2010 (UTC)
- Ok for me. Sorry for not responding earlier. -- User:Docu at 09:09, 31 March 2010 (UTC)
- Untitled followed only by numbers are indeed no good filenames. This also applies if they're separated from the file with a hyphen (File:Untitled-1.jpg) or in brackets (File:Untitled (2).jpg). "File:Untitled[\d\s\-\(\)]+\.\w+" (I'm not sure we need to escape the hyphen with a backslash) shouldn't give any problems as far as I see it. Btw, the blacklist is case-insensitive, unless you force it to be with the <casesensitive> option and extensions are usually made with "\.\w+" at the end of a string. --The Evil IP address (talk) 20:57, 19 February 2010 (UTC)
- We could add just something like
Instead of MediaWiki:Senselessimagename we could create a distinct message MediaWiki:titleblacklist-untitled00, e.g.
- The name of the file you are uploading begins with "Untitled" and is followed by a number. This is a non-descriptive name assigned by image editing software. Please choose a more descriptive name for your file. If it's an untitled work by an artist, include the name, e.g. "Untitled painting by John Doe.jpg"
Thanks. -- User:Docu at 16:41, 13 April 2010 (UTC)
- Done, added as "
File:Untitled\P{L}*\.\w+ <reupload|errmsg=titleblacklist-custom-filename>", i.e. "untitled" followed by no letters except for the filename suffix, using this error message. —Ilmari Karonen (talk) 17:13, 13 April 2010 (UTC)
Uploading a file with this name is denied. Unfortunately the name of the ship is CENTAURUS and her IMO number is IMO _9433755. How can I bypass this problem? --Stunteltje (talk) 09:17, 9 June 2010 (UTC)
- Use normal capitalization, not all-caps, e.g. File:IMO 9433755 Centaurus.jpg. --Mormegil (talk) 12:17, 9 June 2010 (UTC)
- MediaWiki:Titleblacklist-custom-filename (this version) is currently displayed when the filename consists of all caps.
- I think we should either include a specific ALLCAPS sample in the message or create an error message specifically for this. The current text is easily misunderstood (sample). -- User:Docu at 08:45, 28 June 2010 (UTC)
- Technically, all the translations do seem to include an all-caps filename ("DSC00001.JPG") as one of the bad examples; it's just not one for which the capitalization would be the most serious or obvious issue. I suppose we could either add something like "ALL CAPS 01.JPG" to the list, or make up a new message.
- We could also consider whether the rule is actually needed, or whether it is too broad as it stands. For some history, the rule in question was added by The Evil IP address in December 2009; however, their original version did not match filenames with numbers, making it miss many filenames it was probably intended to match and generally unlikely to match anything very often. Later, I edited the rule to let it match numbers too, but accidentally broke it while doing so. Earlier this month, I noticed my mistake and fixed it properly. The fact that we've received complaints so soon afterwards suggests that the rule might be causing more problems than it's preventing. —Ilmari Karonen (talk) 19:50, 28 June 2010 (UTC)
- In fact, I just changed the rule so that it only matches file names with 30 or more letters (all caps, of course) in them. This should at least reduce the chance that it matches a legitimate file name. Feel free to adjust the cutoff, or even to disable the rule entirely, if you feel it's still too broad. —Ilmari Karonen (talk) 20:00, 28 June 2010 (UTC)
- Reading the first part, I was just about to ask if that was possible ;)
- A sample "POLYHEDRON WITH NO VERTEX VISIBLE FROM CENTER.PNG" and inserting "or ALLCAPS" in the first sentence might be sufficient additional explanation. BTW in some languages the filenames aren't translated. -- User:Docu at 20:07, 28 June 2010 (UTC)
- I wonder why I don't have a problem with uploading of: File:ENI 02316363 VEERHAVEN IV ALLIGATOR (04).JPG --Stunteltje (talk) 21:39, 28 June 2010 (UTC)
- It's the "()". -- User:Docu at 22:18, 28 June 2010 (UTC)
- I wonder why I don't have a problem with uploading of: File:ENI 02316363 VEERHAVEN IV ALLIGATOR (04).JPG --Stunteltje (talk) 21:39, 28 June 2010 (UTC)
- In fact, I just changed the rule so that it only matches file names with 30 or more letters (all caps, of course) in them. This should at least reduce the chance that it matches a legitimate file name. Feel free to adjust the cutoff, or even to disable the rule entirely, if you feel it's still too broad. —Ilmari Karonen (talk) 20:00, 28 June 2010 (UTC)
.JPG){kind=link}
Double apostrophes
I just added a rule disallowing new uploads of files with names containing multiple consecutive apostrophes. The reason is technical: because MediaWiki interprets double and triple apostrophes as markup for italic and bold text respectively, linking to (or displaying) such files won't work unless the apostrophes are escaped somehow (e.g. using the HTML numbered character entity reference '.)
The message currently shown if one tries to use such a file name is here. There's currently no translation mechanism in place; I may add one later if no-one else gets around to it first.
According to a quick Toolserver query, we currently have about 250 files with such names on Commons. Most look like they could be easily renamed, although the correct fix (replace by double quotes, collapse to a single apostrophe or remove entirely) needs to be hand-picked for each. I'll post a nice list of the existing files soon, but it's getting too late for that today. —Ilmari Karonen (talk) 23:06, 28 June 2010 (UTC)
- Good idea. Just recently someone brought this up on one of the notice boards. In the message, you might want to change "Instead of using double apostrophes" to "Instead of using 2 apostrophes (2 single quotes)". -- User:Docu at 10:30, 29 June 2010 (UTC)
- Wanted to add this rule all the time, so good thing. However, you might want to change it to
'{2,}, since more than two apostrophes also render wrong. Examples: A pagename'''with three apostrophes and a pagename with more than three'''''''''''apostrophes. --The Evil IP address (talk) 18:07, 30 June 2010 (UTC).*'{2}.*will match any filename with two or more consecutive apostrophes; the period can match an apostrophe too. :) —Ilmari Karonen (talk) 00:36, 1 July 2010 (UTC)
- Wanted to add this rule all the time, so good thing. However, you might want to change it to
Brackets
Perhaps I'm just struggling with the syntax, but it isn't clear to me if ( and ) are supposed to be permissible in filenames. Similarly their urlencoded equivalents %28 and %29. Could someone clarify please? The upload bot from WP to Commons seems to have mismatched these, creating http://commons.wikimedia.org/wiki/File:Information_processing_system_(english).svg based on an uploaded file http://upload.wikimedia.org/wikipedia/commons/3/38/Information_processing_system_%28english%29.svg instead, resulting in something that doesn't work. LeadSongDog (talk) 15:53, 30 June 2010 (UTC)
- Parentheses “(” and “)” are perfectly permissible and work correctly. See e.g. File:Aero L-29 on the MAKS-2009 (01).jpg.
- ...%28english%29.svg is a completely identical URL to ...(english).svg (and [2] is completely identical to [3]). The problem with this specific file is that the SVG renderer used on Wikimedia servers does not like it. See [4]. The problematic part of the SVG seems to be the syntax of “
style="fill: url("#ident")"”, the renderer does not like the quotation marks inside the url syntax (that should be probably acceptable according to the SVG standard, but I am no SVG/CSS guru). When I removed them (“style="fill: url(#ident)"”), the file works fine (you might need to refresh your browser cache). - --Mormegil (talk) 17:43, 30 June 2010 (UTC)
.jpg){kind=link}
.svg){kind=link}
![[2]](https://commons.wikimedia.org/wiki/File:Information_processing_system_(english).svg){kind=link}
![[3]](https://commons.wikimedia.org/wiki/File:Information_processing_system_%28english%29.svg){kind=link}
![[4]](https://upload.wikimedia.org/wikipedia/commons/thumb/archive/3/38/20100630173549%21Information_processing_system_%28english%29.svg/120px-Information_processing_system_%28english%29.svg.png){kind=link}
.svg){kind=link}
Mongolian PUA
Name File: .SVG is not available. --虞海 (talk) 03:15, 1 July 2010 (UTC)
- Here, it's a low-importance usage of PUA for using the corresponding coding for the company's name. But someday if someone tried to upload a file with HKSCS characters (national standard of Hong Kong), this block will bring matters. --虞海 (talk) 03:37, 1 July 2010 (UTC)
- There's a reason it's called a Private Use Area. You really can't assume that anyone else will see those characters the same way as you do, since their computer might map them to a completely different set of symbols. That's why they should also not be used in file names on Commons. —Ilmari Karonen (talk) 07:54, 1 July 2010 (UTC)
- Within the PUA area, some block has became nation standard, and are commonly used, for example: HKSCS (national standard+commonly used), Menksoft (commonly used in Inner Mongolia, de facto regional standard), Tibetan Ext-A (national standard). So it's proper to assume users from certain region will see these characters. On the contrary, some Unicode blocks, for example, Limbu and Cham, are still unperformed by any font, and for those block, you can never assume anyone (include you) to see it.
- Here, the only reason why I use the Menksoft PUA is “ ” is the official name of Menksoft, so it's naturally to use the corresponding code. If I use the Unicode one, it's no longer the official name. --虞海 (talk) 08:08, 1 July 2010 (UTC)
- There's a reason it's called a Private Use Area. You really can't assume that anyone else will see those characters the same way as you do, since their computer might map them to a completely different set of symbols. That's why they should also not be used in file names on Commons. —Ilmari Karonen (talk) 07:54, 1 July 2010 (UTC)
- But it's not the official name; what I'm seeing, from a perfectly Unicode-conformant system, is a mixture of what I guess to be UCAS and runes. I've included the screen shot above. As for HKSCS, all of w:HKSCS is included into Unicode outside of PUA as of 2004.--Prosfilaes (talk) 22:27, 1 July 2010 (UTC)
- Anyway, it turns out that Unicode private use characters were not, in fact, blacklisted; I think the rule that blocked File: .SVG was simply the "file name with no letters" one (since the PUA characters are, of course, not defined as letters in Unicode). I just fixed that omission, though: the Surrogate, Specials and Private Use Area blocks are now all blacklisted. —Ilmari Karonen (talk) 12:36, 2 July 2010 (UTC)
- But it's not the official name; what I'm seeing, from a perfectly Unicode-conformant system, is a mixture of what I guess to be UCAS and runes. I've included the screen shot above. As for HKSCS, all of w:HKSCS is included into Unicode outside of PUA as of 2004.--Prosfilaes (talk) 22:27, 1 July 2010 (UTC)
Italian bad filenames
I've just added this entry to it.wiki's blacklist:
File:(stadio|chiesa|paesaggio|panorama|vista|casa|neve|foto)\d+\.(JPG|GIF|PNG|BMP|JPEG|SVG) <reupload|errmsg=titleblacklist-custom-nomefile>
where stadio, paesaggio, panorama, etc. are generical filenames, so I hope we can add:
File:(stadio|chiesa|paesaggio|panorama|vista|casa|neve|foto|immagine)\d+\.(JPG|GIF|PNG|BMP|JPEG|SVG) <reupload|errmsg=titleblacklist-custom-filename-it>
creating MediaWiki:Titleblacklist-custom-nomefile-it message with a content similar to it:MediaWiki:Titleblacklist-custom-nomefile.
Suggestions? Comments? :)
--Vituzzu (talk) 23:48, 15 August 2010 (UTC)
- There is already Template:Titleblacklist-custom-filename/it
- "foto" is already blacklisted. "immagine" should probably be added (we got "imagem"). Most other filenames are allowed at Commons in other languages, so I'm not sure if we should block them for Italian. Docu at 03:26, 16 August 2010 (UTC)
- I've added "Immagine" and "Panorama" to the list of meaningless prefixes, since they seem like obvious cases. As Docu notes, "Foto" is already listed. Of the rest, I suspect that "Casa" perhaps shouldn't be blacklisted: it seems, among other things, to be the name of an airplane manufacturer (as in File:Casa352.JPG) and of an international organization (as in File:CASA128066.jpeg). Of the rest I have no particular opinion either way: it probably wouldn't hurt to list them, but we don't have that many of them either. (If anyone is interested, you can see a gallery of existing matching files as of last April here.) —Ilmari Karonen (talk) 11:46, 16 August 2010 (UTC)
- Thank you guys for the intrest!
- Uhm the only right use of "casa" should be referred to the airplane manufacturer (but I'm not sure), anyway, in my opinion, "chiesa" (the Italian for "church") should be usefull too in the future these will be brought to Commons. --Vituzzu (talk) 20:05, 18 August 2010 (UTC)
- I've added "Immagine" and "Panorama" to the list of meaningless prefixes, since they seem like obvious cases. As Docu notes, "Foto" is already listed. Of the rest, I suspect that "Casa" perhaps shouldn't be blacklisted: it seems, among other things, to be the name of an airplane manufacturer (as in File:Casa352.JPG) and of an international organization (as in File:CASA128066.jpeg). Of the rest I have no particular opinion either way: it probably wouldn't hurt to list them, but we don't have that many of them either. (If anyone is interested, you can see a gallery of existing matching files as of last April here.) —Ilmari Karonen (talk) 11:46, 16 August 2010 (UTC)
Minimum number of characters
I think that there should be some minimun of characters for file names. I've recently seen admins protecting stuff like "File:A.jpg". But how much should it be? --The Evil IP address (talk) 19:21, 24 August 2010 (UTC)
- Maybe. We could also make an image of an "A" and upload that? Docu at 20:08, 24 August 2010 (UTC)
- I used to do that for numbers instead of uploading a copy of this (or create-protecting after we got that ability)... :) A single character in some languages/scripts can mean a lot more than a single letter. Rocket000 (talk) 01:05, 25 August 2010 (UTC)
Sorry for being late to the discussion, but I propose to block the following (I can't do regex so someone take this in regex format for me, please):
File:[A-Z0-9].jpg
Images of letters should never be in JPEG anyway. This filter only hits Latin script because files in other scripts are seldom uploaded, and only blocks single-letter filenames (those seem to be the most important issue to me). -- Prince Kassad (talk) 18:45, 20 March 2011 (UTC)
File:*Number*.*ext*
File:1.jpg, File:1.svg, File:1.png, File:2.jpg, File:2.svg, etc. are all blacklisted as generic file names on the English Wikipedia. I was wondering if that could apply here too? :| TelCoNaSpVe :| 00:03, 24 September 2010 (UTC)
- This shouldn't really have an effect on Commons. You should still be able to use images from Commons with such filenames.
- I noticed you also tagged a series of files for rename due this problem at Wikipedia. Please try to fix this at en.wp rather than here. Thanks. Docu at 03:32, 24 September 2010 (UTC)
File:Album cover.jpg keeps getting uploaded and deleted. Apart from usually being a copyright violation, it's also a rather meaningless file name. Something to add to the "File names with no letters, except for some meaningless prefix" section, perhaps? —LX (talk, contribs) 21:37, 8 December 2010 (UTC)
- The normal way of dealing with meaningless filenames is to upload a "you can't use this name" placeholder image and protect it. --Carnildo (talk) 22:17, 9 December 2010 (UTC)
- Or to add it in the titleblacklist section for meaningless filenames, which also catches equally meaningless variations. Either way would be an improvement, though. It's been almost a month since I made the initial request. No takers? —LX (talk, contribs) 12:05, 29 December 2010 (UTC)
- I have protected the page. --Mormegil (talk) 19:13, 29 December 2010 (UTC)
- Thank you! —LX (talk, contribs) 19:53, 29 December 2010 (UTC)
Kodak-camera generic names like File:100 2335.JPG seem to be not blocked. --ŠJů (talk) 23:31, 18 February 2011 (UTC)
Sanyo
{{Editprotected}} Please add
File:SANY[\d\s]+\.JPG <reupload|errmsg=senselessimagename> # Sanyo
to the list of camera names to block generic Sanyo camera names from being uploaded. – Adrignola talk 03:30, 22 February 2011 (UTC)
- Done – Kwj2772 (msg) 11:21, 24 February 2011 (UTC)
File:IMG 0004.jpg
File:IMG 0004.jpg was recently uploaded again. How is this possible? Because it used a lower case file extension? --Rosenzweig δ 21:56, 8 July 2011 (UTC)
- I think the "Titleblacklist" feature is currently broken and/or the fix not yet deployed. -- Docu at 12:30, 9 July 2011 (UTC)
ALLCAPS
From Commons:Administrators'_noticeboard/Blocks_and_protections#User:US_National_Archives_bot, it seems that this blocks ALLCAPS names that should be allowed. Thus please remove the following:
- File:[0-9 ]*([A-Z][0-9 ]*){30,}\.\w+ <reupload|casesensitive|errmsg=titleblacklist-custom-filename>
Cheers. -- Docu at 21:37, 6 November 2011 (UTC)
- It does seem to be very odd that the blacklist excludes filenames that are in capitals, given that they aren't inherently a copyright or legal problem. If the blacklist does indeed block all caps filenames, then please could this be fixed? If there is an issue with this, then please could the problem be explained? Thanks. Mike Peel (talk) 21:53, 6 November 2011 (UTC)
- The blacklist is not intended solely to prevent copyright or other legal problems. It also stops generic filenames (such as those autogenerated by digital cameras), filenames with characters that can cause technical problems, and filenames known to be used by persistent vandals among other things. Blocking long all caps filenames generally makes sense, as they're very unlikely to be appropriate. —LX (talk, contribs) 14:04, 7 November 2011 (UTC)
- I have removed this rule, after spending a lot of time to figure out which regex was blocking certain apparently-fine upload. If this is readded, it should have its own message, not MediaWiki:Titleblacklist-custom-filename. Saying "your filename is not descriptive" when that's not the problem, only causes frustration. Platonides (talk) 19:21, 30 September 2012 (UTC)
- Well actually the English version of MediaWiki:Titleblacklist-custom-filename does mention ALLCAPS (but translations don't, AFAIK). I made MediaWiki:Titleblacklist-custom-ALLCAPS but don't know how to add it; and the idea I had to fall back to MediaWiki:Titleblacklist-custom-filename if a translation doesn't exist doesn't seem to work. Maybe it's better to just update the translations of MediaWiki:Titleblacklist-custom-filename... I don't think we should allow ALLCAPS filenames. Rd232 (talk) 20:09, 30 September 2012 (UTC)
Facebook files
Hello,
Would it be possible to block Facebook files? File:165663 185111001523259 100000730806800 501074 1584325 n.jpg Yann (talk) 10:26, 7 November 2011 (UTC)
Also files from fotki.yandex.ru, examples:
username length restriction
Info There is a disccusion about this blacklist's username length restriction at Commons:Administrators'_noticeboard#SUL login + titleblacklist problem. Please join. --Saibo (Δ) 22:58, 9 January 2012 (UTC)
- Commons:Administrators'_noticeboard/Archive_32#SUL_login_.2B_titleblacklist_problem was inconclusive. As the problem has just come up again, I've matched the en.wp length restriction (40 characters, including User:). This should really be enforced in Meta's blacklist, not local projects - and the "User" prefix should not be included in the count, as it varies by project language. Rd232 (talk) 14:48, 17 May 2012 (UTC)
File:Screen shot 2024-06-17 at 7.09.07 AM.png
There seem to be plenty of files named like this. I just tagged File:Screen shot 2015-05-20 at 4.54.28 PM.png as a copyright violation, and there are plenty of other files like this in Category:Media requiring renaming without the related template, sometimes with a capital "S" in "Shot". Where are these files coming from? Could this filename format be blacklisted? --Stefan4 (talk) 16:34, 20 May 2015 (UTC)
- That's the naming pattern used by MacOSX (and possibly iOS). --Carnildo (talk) 01:06, 22 May 2015 (UTC)
IPA colon
Please add
Categoryː.*
to the MediaWiki:Titleblacklist. --84.61.157.93 15:37, 3 October 2015 (UTC)
- Any particular reason? Magog the Ogre (talk) (contribs) 02:39, 30 December 2015 (UTC)
eBay filenames
Could a few default eBay filenames - notably File:S-l1600.jpg and File:S-l500.jpg - be blacklisted? While there certainly are some legitimate reasons to upload images from eBay - I'm currently on a {{PD-scan}} tirade of public domain postcards - this would force proper renaming. Pi.1415926535 (talk) 02:03, 30 December 2015 (UTC)
impossible to remove double extension by moving file
Can anyone help here, please? It's not allowed to remove the double extension by moving the file onto a name without the double ".jpg" because of the Titleblacklist. That's quite strange, because why has it been possible to upload the file onto this old name then? It's not better then the name without the double extension. If anyone is knowing a better name, then please move it there. --Bjarlin (talk) 18:27, 19 August 2016 (UTC)
VLC file names
{{Editprotected}} Default filename for popular en:VLC media player screenshots. There's over 200 to clean up, we don't want anymore.
Format is vlcsnap-YYYY-MM-DD (part of video)
For example: vlcsnap-2016-09-19-16h48m54s202.png
A filter to block any new uploads that begin with vlcsnap- should work without causing any problems. As of writing, VLC outputs only png tiff and jpg.--JacktheHarry (talk) 15:57, 19 September 2016 (UTC)
- Done Awesome! Thank you! Zhuyifei1999 (talk) 11:10, 22 September 2016 (UTC)
microsoft paint names untitled
{{Editprotected}} When you save anything in paint, it calls the file untitled by default. A quick search of untitled lists copious amounts of trash and unhelpful file names. My test file File:Untitled sdfho32e421.jpg was not blocked.
Would recommend blocking all uploads that begin with untitled or end with untitled.--JacktheHarry (talk) 16:26, 19 September 2016 (UTC)
- Done Awesome! Thank you! Zhuyifei1999 (talk) 11:19, 22 September 2016 (UTC)
Oie transparent
{{edit protected}} The name "oie transparent" is added by defect to any files edited using this online editor. It's an undescriptive name. You can check that it was used more than once. The editor uses the formule "oie transparent (any number).png/.gif". --Metrónomo's truth of the day: "That was also done by the president" not an excuse. 05:59, 24 October 2016 (UTC)
- Not done on this occasion, it does not seem to be a significant problem. — billinghurst sDrewth 06:24, 23 January 2017 (UTC)
Unicode file name
I can't upload file ↈ.svg; I could upload with the name Uↈ.svg but was not able to move/rename it to the desired name. Is this restriction really necessary? The alternate name U+2188.svg is existing. There are other Unicode names for files containing Unicode letters, some without problems e.g. Ⰹ.svg or 謹.svg. Please can somebody rename the Uↈ.svg to ↈ.svg? --sarang♥사랑 07:04, 20 May 2017 (UTC)
- @Sarang: Done Magog the Ogre (talk) (contribs) 20:23, 20 May 2017 (UTC)
Categories with “Ayrport”
All categories with “Ayrport”, such as Category:Cologne Bonn Ayrport (near the headquarters of RTL Television, which broadcasted Domino Day), Category:Groningen Ayrport Eelde (near the Prins Bernhardhoeve, in which the Domino Day events in 1999 and 2000 took place), and Category:Moton Field Municipal Ayrport (near Tuskegee, where Lionel Richie, who toppled the first stone of Domino Day 2000, was born), have been deleted. Since they were created in the period from June 6 to June 13, the Normandy landings on 6 June 1944 are also known as D-Day (which caused the withdrawal of the term Domino D-Day), and “Ayrport” is both a rare misspelling of “Airport” and a phoneword for the number 2,977,678 (the number of toppled dominoes in Domino Day 2000), I think that
Category:.*Ayrport.*
needs to be added to the title blacklist. --84.61.155.32 14:40, 14 June 2017 (UTC)
Oppose: Having scanned back until January 2010 I didn't find any category that had 'Ayrport' or 'ayrport' in its title. Your behaviour of creating 128 categories of such a pattern is at least annoying. Next time I'll treat that as vandalism, so einfach ist das. Then your Arcor-IP will be blocked and we'll do some investigations regarding block evasion. And your request on meta was a joke, wasn't it? --Achim (talk) 17:49, 14 June 2017 (UTC)
Note: about spamblacklist hits
Quick note to mention that I have put the recent hits at Special:Log/spamblacklist into the global m:title blacklist. I am sure that I will need to update, and it won't be perfect, however, it is a start. — billinghurst sDrewth 23:10, 19 July 2017 (UTC)
File names ending in non-ASCII characters
Every file name has a file extension, which always ends in an ASCII character. Shall we add a rule
File( Talk)?:.*[^\x{0021}-\x{007E}] # Invalid file extension.
? --109.40.3.39 20:41, 8 December 2017 (UTC)
- File upload extensions are managed by the upload mechanism, as well as the file types being checked. If you are seeing files escaping these checks then please identify those files and we can run some checks. — billinghurst sDrewth 05:18, 9 December 2017 (UTC)
- I think, that for such file names, no non-admin should be able to create file description pages. Objections? --109.40.3.39 07:48, 9 December 2017 (UTC)
- {{Overlay}} uses file sub-pages to add metadata (specifically KML). Other file sub-pages have the code to generate the file. File talk pages may use
/archive 1sub pages. After running a test query excluding redirects and these cases, it has merit for investigation.Regarding your original question, I've not seen those in the Wrong Extension report. —Dispenser (talk) 18:04, 9 December 2017 (UTC)
- {{Overlay}} uses file sub-pages to add metadata (specifically KML). Other file sub-pages have the code to generate the file. File talk pages may use
- I think, that for such file names, no non-admin should be able to create file description pages. Objections? --109.40.3.39 07:48, 9 December 2017 (UTC)