This is an archive of past discussions about MediaWiki:Titleblacklist. 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.
I don't see that okina's are explicitly disallowed. The only blacklist rule that matches "ʻIolani Palace" is one of the rules that disallows moves to titles with mixed Latin and non-Latin characters. Unless someone has an objection, it would be easy enough to modify those rules. Anomie⚔00:10, 31 July 2012 (UTC)
There was nothing stopping me on moving Tuʻi Haʻatakalaua last year but now I can't move Tu'i Kanokupolu to Tuʻi Kanokupolu. This message appears: "Tu'i Kanokupolu" cannot be moved to "Tuʻi Kanokupolu", because the title "Tuʻi Kanokupolu" is on the title blacklist. If you feel that this move is valid, please consider requesting the move first. --KAVEBEAR (talk) 08:42, 1 August 2012 (UTC)
Unless the definition of ʻ in PHP changed in the past year (right now it's a non-Latin letter; if it was a Latin letter or a non-letter a year ago, the move would have worked), I can't see why it let you make that move then and not this one. Hmm. Anomie⚔12:11, 1 August 2012 (UTC)
"prefix:" prevention
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi, all, I'd like to request the following be inserted:
I couldn't register the account "Oh god they've changed the sign up form" just now allegedly due to the title blacklist. Anyone know which entry may have triggered that? Do we have a test tool somewhere these days? --MZMcBride (talk) 13:19, 20 October 2012 (UTC)
Well, usernames of 40 characters or more are disallowed. The name you chose seems to be only 38, did you have any additional punctuation in? ☮Soap☮14:58, 21 October 2012 (UTC)
Yes, I just tested at the test Wikipedia. It's the 40-character rule that the username is hitting. The string itself is only 39 characters. My suspicion is that the extension is adding "User:" to the front, bumping it over the limit.
Well, the problem here is that you're arguing the same thing that I argued previously (when I added the rule). Looking at the actual data, yes, most usernames are less than 40 characters. I could only find two that were longer that had user rights:
Fixed. The problem was that the letter İ (Turkish dotted capital I) case-insensitively matches the normal ASCII lowercase i; there's also the reverse problem where the letter ı (Turkish undotted lowercase I) would case-insensitively match a normal ASCII uppercase I. So I made the rule in question case-sensitive and duplicated all the characters that are intended to be matched. Anomie⚔05:18, 18 November 2012 (UTC)
The problem was there already had been a SUL account with the username, so an account creator would be given “The requested username is already taken in the unified login system. Please choose a different name.” error, I presume? But the problem was solved and the user was able to login here. Thanks for help. --Mormegil (talk) 21:35, 19 November 2012 (UTC)
You confusingly made a piped link from okina to ʻOkina but I don't see signs that either of them are blacklisted. Which exact title do you refer to and what makes you say it's on the blacklist? PrimeHunter (talk) 17:30, 30 November 2012 (UTC)
It's not specifically on the blacklist. But it's apparently considered a letter and not a part of the Latin script (at least in the current version of PHP's PCRE extension), so the blacklist rule against titles containing both Latin script characters and non-Latin-script letters (to prevent homoglyph vandalism) is triggered. Anomie⚔18:37, 30 November 2012 (UTC)
I would like to change the name of the biography for Ibn Maḍāʾ Al-Qurṭubī to just Ibn Maḍāʾ. Almost all academic and historical works about the man simply refer to him as Ibn Maḍāʾ without tagging al-Qurtubi to the end. Qurtubi is an attribution to his hometown and it is used for some authors from Medeival Spain, but not usually this one. I would like to know why Ibn Maḍāʾ is on the blacklist and have it removed, if possible. Thanks so much. MezzoMezzo (talk) 12:32, 23 December 2012 (UTC)
Done I think we might want to just spell it "Ibn Mada" though .... in any case I've created a redirect from Ibn Mada to the requested spelling. ☮Soap☮13:12, 24 December 2012 (UTC)
I moved it, I didn't bother to find out why it was hitting the blacklist but if things like this keep happening we can fix it.☮Soap☮16:50, 25 December 2012 (UTC)
It's the rule with the comment "HERMY". It looks like any page title that contains the words "her" and "my" (in that order) will trigger it, for example, but only on page moves. Anomie⚔20:00, 25 December 2012 (UTC)
False positive (Template:GHSA Class AAAAAA Region 5)
I cannot rename Template:GHSA Class AAAAA Region 5 -> Template:GHSA Class AAAAAA Region 5 because it matches something on the blacklist. Please fix this. Jojalozzo00:44, 10 February 2013 (UTC)
It's not a false positive. Moves to titles with excessive copies of the same letter are blacklisted. You should propose the move at WP:RM. Anomie⚔03:04, 10 February 2013 (UTC)
Fix latest addition
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
This is Nyttend on a public computer. Please check my edit to this page and modify something: either revert it if I made a big mistake, or remove the # character from the second line if it's otherwise ready to go. 129.79.203.174 (talk) 20:29, 3 March 2013 (UTC)
Do you want to ban anyone from creating categories matching the regex "Category:Wikipedia files with no copyright ta*"? Ruslik_Zero08:50, 4 March 2013 (UTC)
Looks like you need the code Category:Wikipedia files with no copyright tag.* (note the full stop). But more to the point, why do you want to stop DumbBOT from creating these categories? Wouldn't blocking the bot until it can be fixed be a better idea? — Mr. Stradivarius♪ talk ♪11:50, 4 March 2013 (UTC)
To your final question: absolutely not. See the discussion at "DumbBOT replacement" (WP:BOTR or at the "Category:Wikipedia files with no copyright tag" section of the relevant revision of WP:AN. The categories no longer have a use (the point of preventing creation is to enable the deletion of the parent category), but DumbBOT persists in creating them, and because the operator is AWOL, it can't be fixed, and there's no other way to prevent the bot from creating these categories. Blocking would work, of course, but this bot does so much necessary work (creating lots of other dated maintenance categories, creating AFD logs, etc.) that blocking it would be horribly unproductive right now. I understand that this might have repercussions on the bot that I can't imagine, but that's why we can watch it and remove this line from the code if it cause bigger problems. Nyttend (talk) 14:33, 4 March 2013 (UTC)
I've just tried to change Twang! to Twang!!, but have not been allowed to do so. I can only guess that this is for the same reason that Chitram Bhalare Vichitram was not changed - some sort of generic ban on double exclamation marks. Is there a way to get round this? Paul B (talk) 13:39, 4 March 2013 (UTC)
Yes you cannot move a page to a title ending with two exclamation points. I think this is because of vandalism, and the fact that legitimate moves to titles like that are rare. But perhaps the vandalism is also rare enough that the rule could be removed? —Soap—17:49, 4 March 2013 (UTC)
I'm doing the pagemove now. I was at first hesitant because most of the sources are printed paper ones that I wouldn't be able to track down, but it seems that the spelling of the name is variable and !! is the only spelling that appears in the one linked source. —Soap—01:39, 5 March 2013 (UTC)
As for the original title, I'd be inclcined to move that as well but I dont see any versions of it that are spelled in Roman letters with the exclamation points. —Soap—01:43, 5 March 2013 (UTC)
That sounds like a MediaWiki:Spam-blacklist issue, not a Title blacklist one. But I don't see it on the blacklist, either here or on meta. Are you sure youtu.be is blocked? I was able to save an edit with a youtu.be link in it, on a non-admin account, here. And other sites on the blacklist did indeed trip the spam filter. —Soap—21:50, 28 March 2013 (UTC)
youtu(.)be allows you to link to a video at a specific time, but youtube.com doesn't (as far as i can tell). so if you are wanting to show a user something specific during a discussion youtu(.)be is a lot easier. ≈Sensorsweep (talk) 06:05, 22 June 2013 (UTC)
It does, you just have to add the time to the end of the URL in the form of a hashtag. #2m59s for example. —Soap—01:36, 5 July 2013 (UTC)
Do you think it's subsided enough to change it to .*\bN[äao]wlins?Wiki\b.* or something along those lines, to make it FP a little less? Jackmcbarn (talk) 20:32, 10 August 2013 (UTC)
Talk page creation
False positives, such as the Nawlinwiki one above, are often responsible for requests at WP:AN asking admins to create talk pages for existing articles; for example, I just had to create Talk:Stephen Nowlin. Why does the blacklist prevent talk page creation in this situation? Yes, I understand that we should apply the blacklist to talk pages: imagine what would happen if someone found that he couldn't create Usernamehere is an idiot but had no problems creating Talk:Usernamehere is an idiot. However, if the article already exists, the creation of a talk page shouldn't be problematic — either the article's fine, or its existence is a bigger problem and the talk page will be deleted along with the article. Therefore, could we add a rule permitting the creation of any talk page when its corresponding article is a bluelink? Nyttend (talk) 17:15, 11 August 2013 (UTC)
I don't think the software is capable of something that fine-tuned; I don't think it can even distinguish what namespace someone's in, let alone whether there's a page with the same title in another namespace. EDIT: It seems to treat the whole title of the page, including the namespace prefix, as a single string, so it does detect namespaces in that way. I still don't think it can tell if there is a coressponding article for a talk page or not. Could be possible in the future though. —Soap—04:02, 13 August 2013 (UTC)
*Muz* - newaccount entry
Given User:MuZemike is no longer very active anymore so the chances of someone trying to impersonate him are much less likely, would it be possible to remove the .*MuZ.* <newaccountonly|errmsg=titleblacklist-forbidden-new-account> entry? I think most of the times I've needed to override the title blacklist when creating accounts at WP:ACC have been because of this, 2 out of 26 today. Callanecc (talk • contribs • logs) 11:18, 21 August 2013 (UTC)
The filter it tripped is .*(eat(s|ing)|ate).*shit.* (matching the "ate" in "Category"). Changing it to .*\b(eat(s|ing)?|ate)\b.*\bshit\b.* should fix it. (I know that not all of the \b's are needed in this case, but that'll help reduce FP's from it in the future, and it allows adding the ? to catch more real hits). Jackmcbarn (talk) 15:21, 25 August 2013 (UTC)
Sounds good, and better than my whitelisting suggestion. For future reference, is it possible to whitelist items here, or do they have to get added to MediaWiki:Titlewhitelist? Meanwhile, please copy the entire blacklist page's code into a sandbox and make the change that you've suggested, and I'll happily copy it into the live page. There's no way that I'll do the change myself, since I don't understand regex at all. Nyttend (talk) 15:30, 25 August 2013 (UTC)
I've made one at /sandbox. Also, you're correct things have to be added to Titlewhitelist, but it's usually a bad idea to do so, because then it can be used to bypass any filter, not just the one it originally caught. Jackmcbarn (talk) 15:38, 25 August 2013 (UTC)
Perhaps .*n+i+g{2,}e+r+.* could be added, to catch repeats no matter how they go, with the {2,} to prevent "Niger" from being caught. Jackmcbarn (talk) 02:13, 7 September 2013 (UTC)
Support, except change i+ to i* so that "ngger" is caught. Ginsuloft (talk) 18:25, 7 September 2013 (UTC) Forget that, I just thought of a (slim chance of) a false positive. I support your original proposal. Ginsuloft (talk) 18:28, 7 September 2013 (UTC)
"Protection for future and archived TFA blurbs and names"
What is this code meant to do, and does it do it?
# Protection for future and archived TFA blurbs and names
And if I have any clue at all, Bencherlite probably wants to remove the "autoconfirmed" part so that he no longer has to protect them, which is why he asked...? I can see you're going to be an admin in the future; keep up the good work. Ginsuloft (talk) 01:37, 12 September 2013 (UTC)
Thanks, but I don't think I'd be thanked if I upped the protection of all TFA blurbs to admin-only! At present, cascading protection looks after them while they are on the main page (and for 24 hours beforehand) which is enough. However, what I would be interested in knowing is whether it's possible to add some code to stop people (even autoconfirmed) using the blurb talk page - I'd rather they went to WP:ERRORS, because that's more likely to be seen than even an {{edit protected}}. Would something like this work?
# Protection for TFA blurb talk pages
Wikipedia talk:Today's[ _]featured[ _]article\/[a-zA-z]+[ _][0-9]+,[ _][0-9]{4}.* <noedit|errmsg=titleblacklist-custom-TFA>
That would technically work, but I think redirecting those talk pages to WP:ERRORS would be a better idea, just because we almost never full-protect talk pages. Jackmcbarn (talk) 12:44, 12 September 2013 (UTC)
Technically, you could use the code you wrote above but change the "errmsg" part to your custom MediaWiki notice, although you can't redirect the editnotice as it'll just redirect the notice itself. Also remove .* from the end if you don't want to protect subpages. (.* means "any string of zero-length or longer". .+ would mean any string at least 1 character in length.) Why don't you try it and see if it works? Whatever you do, don't make an edit filter for this. Ginsuloft (talk) 14:26, 12 September 2013 (UTC)
Redirects can't be done with titleblacklist (they'd have to be done manually, though a bot could do it), but a custom editnotice could appear only on appropriate pages and warn users not to post here, but it couldn't redirect them automatically. Jackmcbarn (talk) 15:18, 12 September 2013 (UTC)
David Beals
@NawlinWiki: I'm concerned that the filter Classic is going to have a quite high FP rate relative to the actual vandalism it catches. Is the titleblacklist really the best way to deal with this? Jackmcbarn (talk) 15:13, 6 September 2013 (UTC)
I can't think of any legitimate article titles that would begin this way - if you can, let me know and I'll rethink. Thanks, NawlinWiki (talk) 15:37, 6 September 2013 (UTC)
You say titles "that would begin this way". As the filter is written now, because of the .* on the front, it doesn't just catch titles that begin with that, but with that anywhere in it. Jackmcbarn (talk) 18:21, 6 September 2013 (UTC)
The anchored version of the "Hunter" regex matches five articles, down from the 43 that the unanchored version matched. --Carnildo (talk) 22:58, 6 September 2013 (UTC)
While you're here, you may want to change .*chaosmus.* to .*chaos.?mus.* or .*chaos.{0,2}mus.* (see Chaos(Musician)) - you may be already aware of this, WP:DENY and all that, but notifying just in case. I have already seen 2 accounts be blocked for chaos vandalism since the addition of the entry. Ginsuloft (talk) 19:02, 6 September 2013 (UTC)
@NawlinWiki: Was your goal with this edit to make the first letter of the second words case-insensitive? If so, can you change them to the following to reduce the FP rate?
No, it was because his last effort was Chaos (nusician). I have revised them to (hopefully) reduce FPs. What do you think? NawlinWiki (talk) 02:15, 4 October 2013 (UTC)
Those look better. What I'd be inclined to do in this case is keep them highly sensitive (and susceptible to FPs), but stick <newaccountonly> on them all. Jackmcbarn (talk) 02:20, 4 October 2013 (UTC)
I second this. I just tried (and, of course, failed) to move Ka 'Ano'i to the correct title, Ka ʻAnoʻi. The ʻokina is an actual letter in the Hawaiian language, and one that is used in the titles of other relevant articles, including Israel Kamakawiwoʻole, the only article linked to from that article. We need to choose one way or the other, and the allowing of the ʻokina is the only logical way to go, because it is not an apostrophe. — TORTOISEWRATH23:45, 9 June 2013 (UTC)
I moved the page, but I'm not sure if the okina will ever be let back in. Basically the problem is that it's not specifically blacklisted, it's just matching a rule that traps all titles that are a mix of Latin and non-Latin characters, and the okina is considered a non-Latin character. So basically all titles containing the letter ʻ are disallowed, albeit only for page-moves and not creations. As far as I can see the only way to solve the problem would be to use MediaWiki:Titlewhitelist and add a rule that any page with "ʻ" in it is allowed. But then any vandal could just add an ʻ to any page and violate all of the rules on the blacklist. —Soap—01:25, 10 June 2013 (UTC)
OK done. I was hesitant on this one because it's such a highly active page and people might get confused, but as long as a redirect there it shouldnt be any more difficult than the others. —Soap—04:19, 7 July 2013 (UTC)
Thanks for the help. But now that I have dug deeper, the same treatment is needed for these:
You're making an error in believing that moving those pages is something vital. I would personally disagree that the articles should be moved at all, as they're at the titles that they are typically known as in the English language - which, if you ever read the Ivory Coast move requests, is the VITAL aspect of our manual of style. Individual move request discussions should have been started to see if consensus was to move to a non-English title ES&L11:46, 4 October 2013 (UTC)
Can Wikipedia:Articles for creation/(?!Redirects/).* <errmsg=titleblacklist-custom-afc-prefix> and Wikipedia talk:Articles [fF]or Creation/.* <casesensitive|errmsg=titleblacklist-custom-afc-prefix> be added to the titleblacklist? These are to prevent submissions accidentally being placed in Wikipedia space rather than Wikipedia talk space, or accidentally created with an incorrect uppercase C (and possibly F). The custom error message is requested at MediaWiki talk:Titleblacklist-custom-afc-prefix. Jackmcbarn (talk) 00:51, 25 November 2013 (UTC)
Well: please not - afc is for newbies (people who doing their first edit on Wikipedia) and shouldn't prevented to do this by a stupid rule of one upper case letter. Moreover the WP namespace is totally valid (and well seen if they create a talkpage for discussion or so on) - hell moving a page (for correction) isn't that time consuming... mabdul06:16, 25 November 2013 (UTC)
This is gentler than an edit filter, since they get this before they start writing their article. An edit filter wouldn't trigger until after they hit save. Jackmcbarn (talk) 17:11, 25 November 2013 (UTC)
The title blacklist filter can be confusing to new users. It doesn't explain why the title is blacklisted, just that it is. The first time I encountered it I had to ask four other users before I found one who could tell me that the proposed title had too many capital letters. It would be nice if there were a way to have the software just automatically remove any spurious capital letters in "Articles for creation" before performing the move, but since the "Move" function is used by everyone and not just Afc this would likely need a wide consensus and very careful implementation. —Anne Delong (talk) 17:38, 25 November 2013 (UTC)
That's why I wrote a custom message for this one. It explains exactly what happened and what page to use instead. Example:
Which is confusing. Users should never have to request that a page be created for them on any noticeboard. This is a very bad proposal, why don't we just wait for the new draft namespace (which will be case insensitive and not require a WikiProject prefix)? This also seems like a solution in search of a problem. I've never seen the {{AFC submission}} template fail because of a case sensitivity thing for page names. Technical 13 (talk) 18:05, 25 November 2013 (UTC)
The idea is that they won't have to request it, because the page they mean to create is the one that they can just click the link to create. Jackmcbarn (talk) 18:07, 25 November 2013 (UTC)
A lot of the incorrect moves happen because our submit template says "This article should be located at Wikipedia talk:Articles for creation/sandbox", which is not true. Of course, the move fails because the page exists, which leads the submitters to start messing around with the namespaces. Can't the template be written so that if the article name is "sandbox" a pop-up appears asking for an article name, and this is substituted for the word "sandbox" before the "Move" routine is called? —Anne Delong (talk) 17:53, 25 November 2013 (UTC)
I believe I already have a fix for this worked out (at least mostly) in my sandbox. This is still a bad proposal for a solution in search of a problem that if it existed at all would become obsolete in no time with the creation of the new draft namespace. Let's not waste any more time on this and instead work on getting prepared for the new namespace and perhaps spend time of creating a Guided Tour (like WP:TWA) for the article creation wizard that will eliminate most of these problems. Also, let's decide if the USD templates need to be adjusted to reduce misnamed pages or if that can be incorporated into the tour. Technical 13 (talk) 18:10, 25 November 2013 (UTC)
Your custom message removes my main objection. I'm not sure, though, that it is appropriate to totally prevent submissions in Wikipedia:Articles for creation. Most of the time, prevention is a good idea. At least half of the articles that I see in Wikipedia:Articles for creation are placed there because there is already an article with the same name in Wikipedia talk:Articles for creation, and this is not always noticed for some time, creating messy history merge problems. Occasionally, though, articles are moved back from mainspace to Afc (or to user space and then to Afc) to be improved, and they may already have talk pages which shouldn't be discarded. —Anne Delong (talk) 18:15, 25 November 2013 (UTC)
In the few rare cases that having the submission in the Wikipedia namespace is desirable, it could just be requested at WP:RM or somewhere (and in those cases, it would be an experienced user that wants it moved). Also, the history merge issues resulting from duplicates, as you mentioned, are my primary reason for wanting this. Jackmcbarn (talk) 18:23, 25 November 2013 (UTC)
I could be wrong, I'm not code minded, but wouldn't adding this suggested code to the titleblacklist prevent everyone (except administrators and account creators) from creating an AfC submission in the Wikiepdia:Articles for creation/Article name namespace? When moving a submission to the project page is a time honoured method of dealing with more complex submissions where a talk page is needed for talking on. Bellerophontalk to me20:51, 25 November 2013 (UTC)
Yes, but with only 150 submissions total in that namespace now, I don't think moving the few that do belong there would be a big workload. Also, template editors can override the titleblacklist. I've updated the message above to display that. Jackmcbarn (talk) 20:58, 25 November 2013 (UTC)
Looking over your custom error message above, I hope that you were just using "sandbox" as an example, because the Afc submitters shouldn't be moving their submissions to either of those page names. I believe that the commonly used example filename is "Foo". —Anne Delong (talk) 21:15, 25 November 2013 (UTC)
Thanks, example updated. And, when used for real, it will intelligently fill it based on the page name they're actually on (uses Wikipedia talk:Articles for creation/{{#titleparts:{{PAGENAME}}||2}}). Jackmcbarn (talk) 21:19, 25 November 2013 (UTC)
Jackmcbarn, you may want to wait until you see if there is consensus for this before putting too much work into it. Your comment about this being something that template editors can override will strike a nerve for many - perhaps the first example of what was a big complaint during the discussion about this right - that suddenly a lot items that were open to all would become restricted to holders of the new "hat". As an experienced Afc reviewer, will I now find that I have to ask for permission to bypass this new restriction, but that template editors who may know nothing about Afc don't? —Anne Delong (talk) 21:41, 25 November 2013 (UTC)
Template editors can override the entire title blacklist. That has nothing to do with my proposal; I just thought it was worth mentioning since accountcreators were mentioned. Jackmcbarn (talk) 21:52, 25 November 2013 (UTC)
Well, it does have something to do with the proposal, because something that any autoconfirmed user could do (move pages to Wikipedia:Articles for creation) would now have to be requested from a group with special access rights. However, I admit that it is a peripheral issue and will not bring it up again. —Anne Delong (talk) 00:09, 26 November 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Currently, many AfC submissions are inadvertently created at locations such as Wikipedia:Articles for creation/Foo or Wikipedia talk:Articles for Creation/Foo, rather than at Wikipedia talk:Articles for creation/Foo. The titleblacklist can be set up to prevent this, and to automatically point users to the correct location to start their article. This takes effect before they can start typing their article, so there isn't risk of work being lost by their edits being blocked. However, in some cases, pages that already have talk pages are moved to AfC space, and with this change, these moves would need to be performed by an administrator (or other user able to override the titleblacklist). Should the titleblacklist be set up in this way? Jackmcbarn (talk) 00:25, 26 November 2013 (UTC)
Strong Oppose as I said above. Too confusing, solution in search of a problem, prevents all users except those with tboverride userright from creating in that space, and will be an obsolete fix as soon as the new draft namespace is created which was per community consensus. I just don't see the point, and doing so will make it more confusing for new editors in my opinion. Technical 13 (talk) 01:14, 26 November 2013 (UTC)
Oppose - Most of the errors could be prevented with less confusion with a change to the Afc Submit process, causing the script to recognize when the filename ends with "sandbox" and presenting a dialogue box asking for an article name before calling the "move" routine. Any articles that are still misplaced are probably by new editors who need to be contacted and helped. —Anne Delong (talk) 04:43, 28 November 2013 (UTC)
Oppose A well-intentioned idea, but I feel it is too big a solution to too small a problem. Also, as has already been mentioned, there are plans for a new draft namespace that would render this solution mute. Bellerophontalk to me09:26, 28 November 2013 (UTC)
Oppose... as mentioned above. I didn't read the "draft"-stuff mentioned in the neutral section as I simply don't have any time for it atm. mabdul22:04, 28 November 2013 (UTC)
Since they will soon be handled in the forthcoming DRAFT namespace, we will need a modified solution. Something like this might be still needed. It is after all a rather frequent error, and can be quite a confusing one. DGG ( talk ) 03:41, 28 November 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Thank you; I thought it might be a false positive, not something working just as it should. I guess it's unavoidable. Nyttend (talk) 04:54, 22 December 2013 (UTC)
That doesn't look right to me. None of those have nine consecutive capital letters. Since slashes [/], spaces [], and numbers [0-9] are not capital letters, so "3/331/236" to "3/331/236", "3/331/222" to "3/331/222", and "3/331/234" to "3/331/234". I actually don't see any of them with more than 3 consecutivecapital letters. This is apparently a bug in the titleblacklist parser. Technical 13 (talk) 05:44, 22 December 2013 (UTC)
Depends what's meant. More than nine consecutive characters that are capital letters? Then something's indeed wrong. More than nine consecutive letters are capital, i.e. there aren't any non-capital letters amid the capitals? Then it's working fine, because all eleven letters in these titles are capital. Nyttend (talk) 15:46, 22 December 2013 (UTC)
Strictly speaking, the pattern matches any name that contains an uppercase letter followed by any mix of non-letters and uppercase letters that contains at least nine uppercase letters. --Carnildo (talk) 01:45, 24 December 2013 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Some Thai letters and numerals (น ค ๆ ยี่ and ๔) were added to the blacklist, mistakenly as Unicode Letterlike Symbols[1]. One was removed[2], please remove the others for the same reason. Peter James (talk) 23:44, 9 March 2014 (UTC)
This is the title blacklist, not the spam blacklist. Spam blacklist is used for blacklisting external links. Also I doubt that any one would blacklist these websites or all web forum sites without a valid rationale. --Glaisher[talk]16:13, 1 April 2014 (UTC)
I've no experience ad title filters (only the spam blacklist) and don't want to break it, so please help me out. Thanks. Guy (Help!) 19:35, 22 March 2014 (UTC)
.*L[yi]nds[ae]y Turner.* <casesensitive> should work for keeping articles with that pattern from being created. Stick it on its own line at the end of the "Attack titles" section and you should be good. --Carnildo (talk) 01:13, 3 April 2014 (UTC)
Protected edit request on 10 April 2014
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please add the following entry:
# Deprecated type of location map definitions
Template:Location map .* <errmsg=titleblacklist-custom-location-map>
(Note that the space between map and .* is important.) Location map definitions should be created as data modules now for performance reasons. There's already a huge backlog of templates that need to be converted, and there's no sense letting it get bigger. See also MediaWiki talk:Titleblacklist-custom-location-map.
Jackmcbarn (talk) 20:05, 10 April 2014 (UTC)
{{Fmbox|id = mw-protectedpagetext|type = warning|image = none|text = The user name "$2" [[Mediawiki talk:Titleblacklist|has been blacklisted]] from creation. The Wikipedia [[:mw:|software]] does not allow names that are greater than or equal to 40 characters in length, has the same character repeat more than 10 times in a row, or use certain invalid characters. Please select another username that complies with these restrictions, or if you need assistance, you may file a request at [[Wikipedia:Request an account]].}}
Which will display as:
The user name "$2" has been blacklisted from creation. The Wikipedia software does not allow names that are greater than or equal to 40 characters in length, has the same character repeat more than 10 times in a row, or use certain invalid characters. Please select another username that complies with these restrictions, or if you need assistance, you may file a request at Wikipedia:Request an account.
Then, please change:
.*(.)\1{10}.* <newaccountonly> # Disallows eleven or more of the same character repeated in usernames
.{40,} <newaccountonly>
To:
.*(.)\1{10}.* <newaccountonly|errmsg=titleblacklist-forbidden-new-account-invalid> # Disallows eleven or more of the same character repeated in usernames
.{40,} <newaccountonly|errmsg=titleblacklist-forbidden-new-account-invalid> # Disallows usernames of more than 40 characters
Is there some background to this request? Any relevant discussion anywhere? Thanks — Martin (MSGJ · talk) 13:14, 3 June 2014 (UTC)
MSGJ, nothing on-wiki itself. There has been a little discussion on IRC about changing one of the tool specific messages to include this reason. I came up with the idea as a solution to a perceived issue where I was trying to create an account via the ACC process and spent an hour trying to find out why the requested username was hitting the title blacklist before I found that little line limiting it to 40 characters (it was a long username request, but the UPOL says that is not a reason in of itself to decline/take action). I could have save a fair chunk of my volunteering time if this request was already in place. :) — {{U|Technical 13}}(e • t • c)13:23, 3 June 2014 (UTC)
Having been involved in said request, that would be helpful. In general having the blacklist print what rule is being triggered would really help with ACC requests.—cyberpowerChatOnline20:24, 3 June 2014 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Sorry, I'm not too hot at coding, so I don't want to mess anything up on the technical side. Would it be possible to add the character used in [3] as a forbidden character? It Is Me Heret / c21:13, 15 July 2014 (UTC)
I don't see a reason to block that character, unless there's something particularly offensive about it. (For reference, the character is U+115D) Jackmcbarn (talk) 21:30, 15 July 2014 (UTC)
Not done: We shouldn't just block random Korean characters - remember that we have a single unified log-in across all wikis now, so people who registered (for example) a Korean username on the Korean Wikipedia will be using Korean usernames here, and we don't want to prevent them from creating their user pages. If you want to block a specific pattern of disruptive usernames from being created, though, that might be doable. — Mr. Stradivarius♪ talk ♪22:05, 15 July 2014 (UTC)
Comment. Oh, sorry, it doesn't appear as a Korean character for me—it appears as a very long space (like an 8× spacebar). That's why I thought we could safely disallow it. It Is Me Heret / c21:39, 18 July 2014 (UTC)
Shuvo Saxema
Pages titled Shuvo Saxema have been speedy-deleted 3 times and has been created a fourth (current speedy nomination) I think this warrants a SALT. As i don't understand the list could someone else add it. Thanks. NickGibson3900 - Talk - Sign my Guestbook 07:22, 10 August 2014 (UTC) I realised this is the wrong place for my request. Sorry NickGibson3900 - Talk - Sign my Guestbook07:56, 10 August 2014 (UTC)
Because it's an arbitrary limit of questionable value that I ran into. I don't care enough about this wiki to spend any more time on this discussion that I already have. The drive to inanely "discuss" the most trivial changes has bad effects on me.
Well this is the English Wikipedia. However, this seems to be a global proiject issue, especially in light of SUL; so soon it may not even matter. Does anyone know if there is a overall limit associated with SUL? — xaosfluxTalk15:30, 30 August 2014 (UTC)
Yeah, local username blacklists, in addition to local user renames, will soon® be going away, I imagine. The global title blacklist lives at m:Title blacklist. I don't see a user account name length limitation there off-hand. --MZMcBride (talk) 21:21, 30 August 2014 (UTC)
The name limit at meta and mediawiki (tried at both) seems to be 65 characters long, cf. the new user User:Doe a deer a female deer, Ray, a drop of golden sun, Me, a name. (and trying to type more characters than that triggers the "invalid name" pink warning box), but I can't see why (the string "65" doesn't appear in the meta blacklist).
I'd suggest that 65 characters is a reasonable limit, if the 40-limit has any real reason to be removed. (Are non-latin scripts regularly hitting the character limit in any particular language?)
(un-indent, cc: Quiddity && Matma Rex) It took a bit of digging, but I found that $wgMaxNameChars is set to 64 on Wikimedia wikis (cf. InitialiseSettings.php.txt). I hadn't realized this (or I'd forgotten). Unfortunately I'm not sure who added this restriction or why. The file's history doesn't go back far enough and I couldn't find a relevant entry in the server admin log. The only hint I uncovered was that at some point Commons likely had a non-default limit. --MZMcBride (talk) 06:03, 1 September 2014 (UTC)
Is mw:Manual:$wgMaxNameChars including or excluding the namespace? The length is different in different languages. In some languages, the length also depends on the gender of the user. "利用者" is only three characters whereas "Utilisateur" is eleven. It would be a bad idea if a user can create a long name on Japanese Wikipedia, but then not use it on French Wikipedia. --Stefan2 (talk) 22:07, 5 September 2014 (UTC)
OK. If that's the case, I think we can live with a 64 character limit, so I'm fine with removing the 40 character limit here. On enwiki, we can continue to flag up long names in our local semi-automatic username monitoring processes, as part of the process for human oversight of potentially abusive accounts. We should do some testing, though, just to test that the 64 character limit is actually enforced. -- The Anome (talk) 12:24, 2 September 2014 (UTC)
Why is this blacklisted? Please fix and explain and move.
"User:Elvey/COMMONDEER" cannot be moved to "User:Elvey/COMMENDEER", because the title "User:Elvey/COMMENDEER" is on the title blacklist. If you feel that this move is valid, please consider requesting the move first.
Why is this blacklisted? Please fix and explain and move.--{{U|Elvey}}(t•c)19:43, 8 September 2014 (UTC)
@Elvey: You're hitting .*\p{Lu}(\P{L}*\p{Lu}){9}.* <casesensitive | moveonly> # Disallows moves with more than nine consecutive capital letters. I've performed the move for you. Jackmcbarn (talk) 20:14, 8 September 2014 (UTC)
You're hitting (?!(User|Wikipedia)( talk)?:|Talk:)\\P{L}*\\p{Latin}.*[^\\p{Latin}\\P{L}].* <moveonly> # Latin + non-Latin. Are you sure all of the characters in the new title are correct? (Some characters in Unicode look exactly alike but are in different character sets.) Jackmcbarn (talk) 23:15, 1 October 2014 (UTC)
I tried to create the username "read mint julep", based on an amusing verbal slip I made the other night while talking to friends and browsing Wikipedia (I decided to finally create an account today). Unfortunately, it told me this name was blacklisted. Is there some ban on the use of alcoholic beverages in usernames? — Preceding unsigned comment added by 130.132.173.139 (talk) 21:12, 2 October 2014 (UTC)
I see the problem now. The version without spaces was "readmintjulep", and the word "admin" isn't allowed in usernames. The one you have now is fine, though. Jackmcbarn (talk) 03:44, 3 October 2014 (UTC)
@Tom Danson: It was stopped by .*\p{Lu}(\P{L}*\p{Lu}){9}.* <casesensitive | moveonly> # Disallows moves with more than nine consecutive capital letters. I've made the move for you. Jackmcbarn (talk) 14:37, 30 October 2014 (UTC)
Apparent bug in the regex for TFA
Regex can be pretty obscure, so maybe I've got this wrong, but in "Wikipedia:Today's[ _]featured[ _]article\/[a-zA-z]+[ _][0-9]+,[ _][0-9]{4}.*", I can't imagine that "A-z" is right; shouldn't that be "A-Z"? - Dank (push to talk) 15:10, 20 November 2014 (UTC)
I can't imagine that we would want to prevent any possible article from being TFA... That said, if you want to prevent them all from being created by those not authorized to create them, shouldn't it be:
