MediaWiki talk:Titleblacklist/Archive 1

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Archive 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.
Archive 1 Archive 2 →

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)

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:
  1. We need to have a multilingual message explaining what is happening and how to fix it.
  2. We need to do some active education prior to doing this - posts to COM:VP, sitenotice, etc.
  3. We need to have a good system in place to handle media renames. Do we yet have a bot to handle {{rename}}s?
 — 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)

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

[[MediaWiki:Senselessimagename/aa|aa]] | [[MediaWiki:Senselessimagename/ab|ab]] | [[MediaWiki:Senselessimagename/af|af]] | [[MediaWiki:Senselessimagename/ak|ak]] | [[MediaWiki:Senselessimagename/aln|aln]] | [[MediaWiki:Senselessimagename/als|als]] | [[MediaWiki:Senselessimagename/am|am]] | [[MediaWiki:Senselessimagename/an|an]] | [[MediaWiki:Senselessimagename/ang|ang]] | [[MediaWiki:Senselessimagename/ar|ar]] | [[MediaWiki:Senselessimagename/arc|arc]] | [[MediaWiki:Senselessimagename/arn|arn]] | [[MediaWiki:Senselessimagename/arz|arz]] | [[MediaWiki:Senselessimagename/as|as]] | [[MediaWiki:Senselessimagename/ast|ast]] | [[MediaWiki:Senselessimagename/av|av]] | [[MediaWiki:Senselessimagename/avk|avk]] | [[MediaWiki:Senselessimagename/ay|ay]] | [[MediaWiki:Senselessimagename/az|az]] | [[MediaWiki:Senselessimagename/ba|ba]] | [[MediaWiki:Senselessimagename/bar|bar]] | [[MediaWiki:Senselessimagename/bat-smg|bat-smg]] | [[MediaWiki:Senselessimagename/bcc|bcc]] | [[MediaWiki:Senselessimagename/bcl|bcl]] | [[MediaWiki:Senselessimagename/be|be]] | [[MediaWiki:Senselessimagename/be-x-old|be-x-old]] | [[MediaWiki:Senselessimagename/bg|bg]] | [[MediaWiki:Senselessimagename/bh|bh]] | [[MediaWiki:Senselessimagename/bi|bi]] | [[MediaWiki:Senselessimagename/bm|bm]] | [[MediaWiki:Senselessimagename/bn|bn]] | [[MediaWiki:Senselessimagename/bo|bo]] | [[MediaWiki:Senselessimagename/bpy|bpy]] | [[MediaWiki:Senselessimagename/br|br]] | [[MediaWiki:Senselessimagename/bs|bs]] | [[MediaWiki:Senselessimagename/cbk-zam|cbk-zam]] | [[MediaWiki:Senselessimagename/bto|bto]] | [[MediaWiki:Senselessimagename/bug|bug]] | [[MediaWiki:Senselessimagename/bxr|bxr]] | [[MediaWiki:Senselessimagename/ca|ca]] | [[MediaWiki:Senselessimagename/cdo|cdo]] | [[MediaWiki:Senselessimagename/ce|ce]] | [[MediaWiki:Senselessimagename/ceb|ceb]] | [[MediaWiki:Senselessimagename/ch|ch]] | [[MediaWiki:Senselessimagename/cho|cho]] | [[MediaWiki:Senselessimagename/chr|chr]] | [[MediaWiki:Senselessimagename/chy|chy]] | [[MediaWiki:Senselessimagename/co|co]] | [[MediaWiki:Senselessimagename/cr|cr]] | [[MediaWiki:Senselessimagename/crh|crh]] | [[MediaWiki:Senselessimagename/cs|cs]] | [[MediaWiki:Senselessimagename/csb|csb]] | [[MediaWiki:Senselessimagename/cu|cu]] | [[MediaWiki:Senselessimagename/cv|cv]] | [[MediaWiki:Senselessimagename/cy|cy]] | [[MediaWiki:Senselessimagename/da|da]] | [[MediaWiki:Senselessimagename/de|de]] | [[MediaWiki:Senselessimagename/diq|diq]] | [[MediaWiki:Senselessimagename/dk|dk]] | [[MediaWiki:Senselessimagename/dsb|dsb]] | [[MediaWiki:Senselessimagename/dv|dv]] | [[MediaWiki:Senselessimagename/dz|dz]] | [[MediaWiki:Senselessimagename/ee|ee]] | [[MediaWiki:Senselessimagename/el|el]] | [[MediaWiki:Senselessimagename/eml|eml]] | [[MediaWiki:Senselessimagename|en]] | [[MediaWiki:Senselessimagename/eo|eo]] | [[MediaWiki:Senselessimagename/es|es]] | [[MediaWiki:Senselessimagename/et|et]] | [[MediaWiki:Senselessimagename/eu|eu]] | [[MediaWiki:Senselessimagename/ext|ext]] | [[MediaWiki:Senselessimagename/fa|fa]] | [[MediaWiki:Senselessimagename/ff|ff]] | [[MediaWiki:Senselessimagename/fi|fi]] | [[MediaWiki:Senselessimagename/fiu-vro|fiu-vro]] | [[MediaWiki:Senselessimagename/fj|fj]] | [[MediaWiki:Senselessimagename/fo|fo]] | [[MediaWiki:Senselessimagename/fr|fr]] | [[MediaWiki:Senselessimagename/frc|frc]] | [[MediaWiki:Senselessimagename/frp|frp]] | [[MediaWiki:Senselessimagename/fur|fur]] | [[MediaWiki:Senselessimagename/fy|fy]] | [[MediaWiki:Senselessimagename/ga|ga]] | [[MediaWiki:Senselessimagename/gag|gag]] | [[MediaWiki:Senselessimagename/gan|gan]] | [[MediaWiki:Senselessimagename/gd|gd]] | [[MediaWiki:Senselessimagename/gl|gl]] | [[MediaWiki:Senselessimagename/glk|glk]] | [[MediaWiki:Senselessimagename/gn|gn]] | [[MediaWiki:Senselessimagename/got|got]] | [[MediaWiki:Senselessimagename/grc|grc]] | [[MediaWiki:Senselessimagename/gsw|gsw]] | [[MediaWiki:Senselessimagename/gu|gu]] | [[MediaWiki:Senselessimagename/gv|gv]] | [[MediaWiki:Senselessimagename/ha|ha]] | [[MediaWiki:Senselessimagename/hak|hak]] | [[MediaWiki:Senselessimagename/haw|haw]] | [[MediaWiki:Senselessimagename/he|he]] | [[MediaWiki:Senselessimagename/hi|hi]] | [[MediaWiki:Senselessimagename/hif|hif]] | [[MediaWiki:Senselessimagename/hil|hil]] | [[MediaWiki:Senselessimagename/ho|ho]] | [[MediaWiki:Senselessimagename/hr|hr]] | [[MediaWiki:Senselessimagename/hsb|hsb]] | [[MediaWiki:Senselessimagename/ht|ht]] | [[MediaWiki:Senselessimagename/hu|hu]] | [[MediaWiki:Senselessimagename/hy|hy]] | [[MediaWiki:Senselessimagename/hz|hz]] | [[MediaWiki:Senselessimagename/ia|ia]] | [[MediaWiki:Senselessimagename/id|id]] | [[MediaWiki:Senselessimagename/ie|ie]] | [[MediaWiki:Senselessimagename/ig|ig]] | [[MediaWiki:Senselessimagename/ii|ii]] | [[MediaWiki:Senselessimagename/ik|ik]] | [[MediaWiki:Senselessimagename/ilo|ilo]] | [[MediaWiki:Senselessimagename/inh|inh]] | [[MediaWiki:Senselessimagename/io|io]] | [[MediaWiki:Senselessimagename/is|is]] | [[MediaWiki:Senselessimagename/it|it]] | [[MediaWiki:Senselessimagename/iu|iu]] | [[MediaWiki:Senselessimagename/ja|ja]] | [[MediaWiki:Senselessimagename/jbo|jbo]] | [[MediaWiki:Senselessimagename/jut|jut]] | [[MediaWiki:Senselessimagename/jv|jv]] | [[MediaWiki:Senselessimagename/ka|ka]] | [[MediaWiki:Senselessimagename/kaa|kaa]] | [[MediaWiki:Senselessimagename/kab|kab]] | [[MediaWiki:Senselessimagename/kg|kg]] | [[MediaWiki:Senselessimagename/ki|ki]] | [[MediaWiki:Senselessimagename/kj|kj]] | [[MediaWiki:Senselessimagename/kk|kk]] | [[MediaWiki:Senselessimagename/kl|kl]] | [[MediaWiki:Senselessimagename/km|km]] | [[MediaWiki:Senselessimagename/kn|kn]] | [[MediaWiki:Senselessimagename/ko|ko]] | [[MediaWiki:Senselessimagename/kr|kr]] | [[MediaWiki:Senselessimagename/kri|kri]] | [[MediaWiki:Senselessimagename/krj|krj]] | [[MediaWiki:Senselessimagename/ks|ks]] | [[MediaWiki:Senselessimagename/ksh|ksh]] | [[MediaWiki:Senselessimagename/ku|ku]] | [[MediaWiki:Senselessimagename/kv|kv]] | [[MediaWiki:Senselessimagename/kw|kw]] | [[MediaWiki:Senselessimagename/ky|ky]] | [[MediaWiki:Senselessimagename/la|la]] | [[MediaWiki:Senselessimagename/lad|lad]] | [[MediaWiki:Senselessimagename/lb|lb]] | [[MediaWiki:Senselessimagename/lbe|lbe]] | [[MediaWiki:Senselessimagename/lez|lez]] | [[MediaWiki:Senselessimagename/lfn|lfn]] | [[MediaWiki:Senselessimagename/lg|lg]] | [[MediaWiki:Senselessimagename/li|li]] | [[MediaWiki:Senselessimagename/lij|lij]] | [[MediaWiki:Senselessimagename/lld|lld]] | [[MediaWiki:Senselessimagename/lmo|lmo]] | [[MediaWiki:Senselessimagename/ln|ln]] | [[MediaWiki:Senselessimagename/lo|lo]] | [[MediaWiki:Senselessimagename/loz|loz]] | [[MediaWiki:Senselessimagename/lt|lt]] | [[MediaWiki:Senselessimagename/lv|lv]] | [[MediaWiki:Senselessimagename/lzz|lzz]] | [[MediaWiki:Senselessimagename/mai|mai]] | [[MediaWiki:Senselessimagename/map-bms|map-bms]] | [[MediaWiki:Senselessimagename/mdf|mdf]] | [[MediaWiki:Senselessimagename/mg|mg]] | [[MediaWiki:Senselessimagename/mh|mh]] | [[MediaWiki:Senselessimagename/mi|mi]] | [[MediaWiki:Senselessimagename/mk|mk]] | [[MediaWiki:Senselessimagename/ml|ml]] | [[MediaWiki:Senselessimagename/mn|mn]] | [[MediaWiki:Senselessimagename/mo|mo]] | [[MediaWiki:Senselessimagename/mr|mr]] | [[MediaWiki:Senselessimagename/ms|ms]] | [[MediaWiki:Senselessimagename/mt|mt]] | [[MediaWiki:Senselessimagename/mus|mus]] | [[MediaWiki:Senselessimagename/mwl|mwl]] | [[MediaWiki:Senselessimagename/my|my]] | [[MediaWiki:Senselessimagename/myv|myv]] | [[MediaWiki:Senselessimagename/mzn|mzn]] | [[MediaWiki:Senselessimagename/na|na]] | [[MediaWiki:Senselessimagename/nah|nah]] | [[MediaWiki:Senselessimagename/nan|nan]] | [[MediaWiki:Senselessimagename/nap|nap]] | [[MediaWiki:Senselessimagename/nb|nb]] | [[MediaWiki:Senselessimagename/nds|nds]] | [[MediaWiki:Senselessimagename/nds-nl|nds-nl]] | [[MediaWiki:Senselessimagename/ne|ne]] | [[MediaWiki:Senselessimagename/new|new]] | [[MediaWiki:Senselessimagename/ng|ng]] | [[MediaWiki:Senselessimagename/niu|niu]] | [[MediaWiki:Senselessimagename/nl|nl]] | [[MediaWiki:Senselessimagename/nn|nn]] | [[MediaWiki:Senselessimagename/no|no]] | [[MediaWiki:Senselessimagename/nov|nov]] | [[MediaWiki:Senselessimagename/nrm|nrm]] | [[MediaWiki:Senselessimagename/nso|nso]] | [[MediaWiki:Senselessimagename/nv|nv]] | [[MediaWiki:Senselessimagename/ny|ny]] | [[MediaWiki:Senselessimagename/oc|oc]] | [[MediaWiki:Senselessimagename/om|om]] | [[MediaWiki:Senselessimagename/or|or]] | [[MediaWiki:Senselessimagename/os|os]] | [[MediaWiki:Senselessimagename/pa|pa]] | [[MediaWiki:Senselessimagename/pag|pag]] | [[MediaWiki:Senselessimagename/pam|pam]] | [[MediaWiki:Senselessimagename/pap|pap]] | [[MediaWiki:Senselessimagename/pdc|pdc]] | [[MediaWiki:Senselessimagename/pdt|pdt]] | [[MediaWiki:Senselessimagename/pfl|pfl]] | [[MediaWiki:Senselessimagename/pi|pi]] | [[MediaWiki:Senselessimagename/pih|pih]] | [[MediaWiki:Senselessimagename/pl|pl]] | [[MediaWiki:Senselessimagename/plm|plm]] | [[MediaWiki:Senselessimagename/pms|pms]] | [[MediaWiki:Senselessimagename/pnt|pnt]] | [[MediaWiki:Senselessimagename/ps|ps]] | [[MediaWiki:Senselessimagename/pt|pt]] | [[MediaWiki:Senselessimagename/qu|qu]] | [[MediaWiki:Senselessimagename/rif|rif]] | [[MediaWiki:Senselessimagename/rm|rm]] | [[MediaWiki:Senselessimagename/rmy|rmy]] | [[MediaWiki:Senselessimagename/rn|rn]] | [[MediaWiki:Senselessimagename/ro|ro]] | [[MediaWiki:Senselessimagename/roa-rup|roa-rup]] | [[MediaWiki:Senselessimagename/roa-tara|roa-tara]] | [[MediaWiki:Senselessimagename/ru|ru]] | [[MediaWiki:Senselessimagename/ruq|ruq]] | [[MediaWiki:Senselessimagename/rw|rw]] | [[MediaWiki:Senselessimagename/sa|sa]] | [[MediaWiki:Senselessimagename/sah|sah]] | [[MediaWiki:Senselessimagename/sc|sc]] | [[MediaWiki:Senselessimagename/scn|scn]] | [[MediaWiki:Senselessimagename/sco|sco]] | [[MediaWiki:Senselessimagename/sd|sd]] | [[MediaWiki:Senselessimagename/sdc|sdc]] | [[MediaWiki:Senselessimagename/se|se]] | [[MediaWiki:Senselessimagename/sei|sei]] | [[MediaWiki:Senselessimagename/sg|sg]] | [[MediaWiki:Senselessimagename/sh|sh]] | [[MediaWiki:Senselessimagename/shi|shi]] | [[MediaWiki:Senselessimagename/si|si]] | [[MediaWiki:Senselessimagename/simple|simple]] | [[MediaWiki:Senselessimagename/sk|sk]] | [[MediaWiki:Senselessimagename/sl|sl]] | [[MediaWiki:Senselessimagename/sm|sm]] | [[MediaWiki:Senselessimagename/sma|sma]] | [[MediaWiki:Senselessimagename/sn|sn]] | [[MediaWiki:Senselessimagename/so|so]] | [[MediaWiki:Senselessimagename/sq|sq]] | [[MediaWiki:Senselessimagename/sr|sr]] | [[MediaWiki:Senselessimagename/srn|srn]] | [[MediaWiki:Senselessimagename/ss|ss]] | [[MediaWiki:Senselessimagename/st|st]] | [[MediaWiki:Senselessimagename/stq|stq]] | [[MediaWiki:Senselessimagename/su|su]] | [[MediaWiki:Senselessimagename/sv|sv]] | [[MediaWiki:Senselessimagename/sw|sw]] | [[MediaWiki:Senselessimagename/szl|szl]] | [[MediaWiki:Senselessimagename/ta|ta]] | [[MediaWiki:Senselessimagename/te|te]] | [[MediaWiki:Senselessimagename/tet|tet]] | [[MediaWiki:Senselessimagename/tg|tg]] | [[MediaWiki:Senselessimagename/th|th]] | [[MediaWiki:Senselessimagename/ti|ti]] | [[MediaWiki:Senselessimagename/tk|tk]] | [[MediaWiki:Senselessimagename/tl|tl]] | [[MediaWiki:Senselessimagename/tn|tn]] | [[MediaWiki:Senselessimagename/to|to]] | [[MediaWiki:Senselessimagename/tp|tp]] | [[MediaWiki:Senselessimagename/tpi|tpi]] | [[MediaWiki:Senselessimagename/tr|tr]] | [[MediaWiki:Senselessimagename/ts|ts]] | [[MediaWiki:Senselessimagename/tt|tt]] | [[MediaWiki:Senselessimagename/tum|tum]] | [[MediaWiki:Senselessimagename/tw|tw]] | [[MediaWiki:Senselessimagename/ty|ty]] | [[MediaWiki:Senselessimagename/tyv|tyv]] | [[MediaWiki:Senselessimagename/tzm|tzm]] | [[MediaWiki:Senselessimagename/udm|udm]] | [[MediaWiki:Senselessimagename/ug|ug]] | [[MediaWiki:Senselessimagename/uk|uk]] | [[MediaWiki:Senselessimagename/ur|ur]] | [[MediaWiki:Senselessimagename/uz|uz]] | [[MediaWiki:Senselessimagename/ve|ve]] | [[MediaWiki:Senselessimagename/vec|vec]] | [[MediaWiki:Senselessimagename/vi|vi]] | [[MediaWiki:Senselessimagename/vls|vls]] | [[MediaWiki:Senselessimagename/vo|vo]] | [[MediaWiki:Senselessimagename/wa|wa]] | [[MediaWiki:Senselessimagename/war|war]] | [[MediaWiki:Senselessimagename/wo|wo]] | [[MediaWiki:Senselessimagename/wuu|wuu]] | [[MediaWiki:Senselessimagename/xal|xal]] | [[MediaWiki:Senselessimagename/xh|xh]] | [[MediaWiki:Senselessimagename/xmf|xmf]] | [[MediaWiki:Senselessimagename/ydd|ydd]] | [[MediaWiki:Senselessimagename/yi|yi]] | [[MediaWiki:Senselessimagename/yo|yo]] | [[MediaWiki:Senselessimagename/yue|yue]] | [[MediaWiki:Senselessimagename/za|za]] | [[MediaWiki:Senselessimagename/zea|zea]] | [[MediaWiki:Senselessimagename/zh|zh]] | [[MediaWiki:Senselessimagename/zh-classical|zh-classical]] | [[MediaWiki:Senselessimagename/zh-min-nan|zh-min-nan]] | [[MediaWiki:Senselessimagename/zh-yue|zh-yue]] | [[MediaWiki:Senselessimagename/zu|zu]] |

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)

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)
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 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:

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)

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)
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)

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)

✓ Done. —Ilmari Karonen (talk) 23:46, 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)

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: NB 104.png 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)

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)
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>
Ilmari Karonen (talk) 11:28, 6 January 2010 (UTC)
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)

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)

File:IMO_9433755_CENTAURUS.JPG

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)

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 &#39;.)

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)

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(&quot;#ident&quot;)"”, 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)

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)

Commons-PUA.png

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)

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)

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

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)

File:100 2335.JPG

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)

✓ DoneKwj2772 (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)