Wikipedia talk:Special:PrefixIndex

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Technical 13 (talk | contribs) at 16:33, 15 June 2015 (Reverted good faith edits by 46.19.85.174 (talk): Not English. (TW)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

See also: Template:Lookfrom and Red link prefix index
For advanced pagenames searches use the grep tool

"no redirects" option

Is there an option to not include redirects? ∞ΣɛÞ² (τ|c) 20:59, 30 June 2007 (UTC)[reply]

I am not aware of such an option, but at least redirects are enclosed into <div class=allpagesredirect> (which already has italic CSS). So
div.allpagesredirect {display:none}
will hide them (leaving empty table cells unfortunately), while
div.allpagesredirect a {color:gray}
will simply make them easier to distinquish from normal pages. CSS code goes into your monobook.css ∴ Alex Smotrov 19:42, 2 July 2007 (UTC)[reply]


Thanks, but I was looking for a built-in MediaWiki option (that should be present anyway). Oh and I use simple.css. ;) ∞ΣɛÞ² (τ|c) 21:36, 2 July 2007 (UTC)[reply]
The CSS option is incorrect as it would hide pages that should appear (ignoring problems with using it on Wikipedia). A proper "no redirects" option would omit any page which redirects to another page with the same prefix, leaving pages which redirect elsewhere. See Special:PrefixIndex/Step for an example of why this would be really, really useful. —Preceding unsigned comment added by 67.160.117.198 (talk) 01:56, 12 September 2010 (UTC)[reply]
The option hideredirects=1 was added in 2012. For example here's a way to show a compact list of subpages:
{{Special:PrefixIndex/{{FULLPAGENAME}}/ |hideredirects=1 |stripprefix=1}}
-- S Page (WMF) (talk) 01:41, 24 October 2013 (UTC)[reply]

SuffixIndex

Is there any special page for suffixes? Such as to search for articles that end with (ice hockey) or something? I haven't found one, so I doubt there is, but I might as well ask. BsroiaadnTalk 13:38, 6 July 2007 (UTC)[reply]

No, there isn't. Maybe request it at WP:VPR or WP:VPT; it's a neat idea. This, that and the other [talk] 07:34, 8 July 2007 (UTC)[reply]
Request a better search engine, too, since the current one sucks petunas, relying on external search engines (like Google) to pick up MediaWiki's slack. Wikipedia's navigation system sucks too, requiring dabs and categories to also pick up the slack. ∞ΣɛÞ² (τ|c) 19:09, 8 July 2007 (UTC)[reply]
Don't reinvent the wheel. If google does the job there is no need for MediaWiki to do so. Also, your idea of what the dab pages are there for is plain wrong. As long as it's seen as a goal to be able to reach an article by typing the name directly dab pages will be necessary. No improvement in Wikipedias navigation system is going to change this, because the problem is in the ambiguity of the English language. Taemyr 01:56, 9 July 2007 (UTC)[reply]

I have to second the request for Special:Suffixindex. This will be invaluable for finding the noun part of names that have various adjectives. Greg Bard 12:40, 13 September 2007 (UTC)[reply]

This would be possible if the "page" table in MediaWiki's database had a "page_reverse_title" column: then the Suffixindex input could be reversed, the Prefixindex query could be performed (ordering by page_reverse_title instead of page_title), and tada, results. At least in my naive, not-excessively-fluent-in-SQL analysis :) If there's an easier way, I don't know what it is! GracenotesT § 17:27, 20 September 2007 (UTC)[reply]
Come to think of it, I'm positive that solution violates some database design rule about normalization. Oh well. GracenotesT § 17:31, 20 September 2007 (UTC)[reply]
No, it can be done by just adding 1 column to the article table and 1 index for just that table. That can't possibly break any normalization rule (OK, so, it breaks the second normal form because it's redundant information that can be obtained from reversing the name column primary key. Damn you, Codd! It's still an acceptable compromise for performance, thought) The name-updating updates the column every time that the "name" column is updated, the searches are as fast as prefixIndex, and the name change updates only have to update one extra column on a table that gets updated anyways and one extra index. It's not as if articles change names often. --Enric Naval (talk) 02:16, 2 April 2008 (UTC)[reply]
On MySQL you can use the LIKE comparator, not? LIKE "%(ice hockey)". That would work for MiddleIndex as well. --Ysangkok (talk) 16:05, 21 November 2009 (UTC)[reply]
Only if you don't care about performance. Non-prefix LIKE comparisons require a full table scan, which isn't cheap on 18 million rows. Zetawoof(ζ) 19:40, 21 November 2009 (UTC)[reply]
I made a request at bugzilla. It had come up before. The discussion was about the fact that a prefix search comes at no extra effort because of the way the database is set up. However, to set up a suffix search would require a major effort apparently. Oh well, it was a nice thought. I'm sure by the time we are all required by the government to have the computer implant in the brain which connects us all to the Wikipedia, they will have it figured out. Greg Bard 19:59, 20 September 2007 (UTC)[reply]

Google query examply: something like intitle:"*(ice_hockey)", probably can be improved ∴ Alex Smotrov 21:31, 20 September 2007 (UTC)[reply]

Not really a solution (or even a workaround) but you could download the "enwiki-YYYYMMDD-all-titles-in-ns0.gz" file from http://download.wikimedia.org and try searching for suffix$ (or something similar) with a regular expression-capable editor. --Kjoonlee 11:30, 29 March 2008 (UTC)[reply]

For prefix, currently two types are available, that is, {{PAGENAME}} type and, "particular word" or "Particular phrase" type. Example of particular word below is "Sandbox" and "United".
*[[Special:Prefixindex/{{PAGENAME}}|All pages starting with {{PAGENAME}}]]
*[[Special:Prefixindex/Sandbox|All pages starting with "Sandbox"]]
*[[Special:Prefixindex/United|All pages starting with "United"]]

For the desirable "Special:postfindex" or "Special:suffindex" would limit the number of letters, for example specifying number of letter(s) in script, I suggest, would be more than 4 or larger and 8 or less. Any number or unlimited number of letters may increase server burden or load to much, and may confuse reader who browsing or reading Wikipedia. What I want have "Special:postfindex" or "Special:suffindex" is available not only English language edition, but also for any language within Wikipedia.

In case of Wikipedia Japanese language edition (メインページ), single Japanese letter is composed by two Byte (8 bit & 8 bit), where as English single letter is composed by one Byte. In Japanese language case, I would suggest 2 or more number of letters to 4 or less number letters to limit as postfix. In Special: Postfix designation, these limited number of letters to be, of course, changeable by Wikipedia's system engineer or technical designator.
Example of Postfixindex or Suffixindex within single language would be:
*[[Special:Suffixindex/{{PAGENAME}}|All pages ending with (in Japanese) {{PAGENAME}}]]
*[[Special:Suffixindex/United|All pages ending with "United"]]
*[[Special:Suffixindex/あいうえ|All pages ending with "あいうえ"]]
あいうえ is Japanese "abcd".

The above suffixindex should work within given language, that is within any language. List of "All pages ending with" is not seen paper type encyclopedia, and it is superb function achievable function on electrical encyclopedia like Wikipedia.

For your information, I am told there is a site to list up Wikipedia article with ending "any word" in Japanese Wikipedia:Village pump, but this is effective for Wikipedia user, not for reader within Wikipedia.

NOTE: the following URL access takes server time for a moment: (Note; Left button　is query send and right button is Reset)

To list up "(ice_hockey)" with next URL, my PC and internet takes more than 15 minutes !!

Not usre if this is outdated or not, but I too want a suffixindex. It'd really help when searching for files (like *.svg, *.png, etc) or, for people like me who administer private wikis, for searching for MediaWiki files (*.css, *.js, etc). Mnmazur (talk)

Vote for Bugzilla:10808. Jidanni (talk) 09:07, 20 November 2010 (UTC)[reply]

I would love to see a Special:SuffixIndex. I imagine it might be harder to code and have no idea how to implement it, but were it possible, it would be very useful. SeeTheInvisible (talk) 18:20, 20 December 2011 (UTC)[reply]

Infixes, circumfixes, prefixes and suffixes

In fact, including these options and combinations of these would be most useful.Curb Chain (talk) 17:14, 7 January 2015 (UTC)[reply]

New Prefix Discussion

I thought you might find this discussion relevant. Please comment about the new proposed prefixes. I'm suggesting that we add U: and UT: for user pages and user talk pages. Jmfangio| ►Chat  09:35, 27 July 2007 (UTC)[reply]

Link is no longer good; since VPT is not archived, it's now best to look at an old version of the page to see the discussion. -- John Broughton (♫♫) 16:31, 20 September 2007 (UTC)[reply]

"Next page" at the top, but not at the bottom

Special:Allpages has a "Next page" link at the top right and the bottom right. Special:Prefixindex has this link only at the top (if the list is long enough). Could the link be added to the bottom as well? For comparison, see Special:Allpages/Alex and Special:Prefixindex/Alex. Thanks! Ewlyahoocom 05:14, 15 September 2007 (UTC) Do NOT use bad words. Thank you[reply]

This page does not seem to get noticed too much. I submitted bugzilla:18424 on it. • Anakin (talk) 16:49, 10 April 2009 (UTC)[reply]

PrefixIndex, middleindex, suffixindex, etc.

Where Special:PrefixIndex allows you to search article names that begin with a certain text string, Wikimedia.de grep is a recently improved tool that allows you to search text strings anywhere they appear in the article name. Grep lets you search the entire text string (not just the beginning) for common text patterns. Even better, grep lets you use wildcard characters and other characters (see Regular expression) to formulate your search string. H(ä|ae?)ndel will find "Handel", "Händel", and "Haendel". (S|s)chool will find School and school. The grep tool allows you to find postings in any other name space. The grep tool also is great for finding all related categories and all related templates, even if they are not categorized with a [[Category:]] GregManninLB (talk) 14:55, 26 April 2008 (UTC)[reply]

Briefly confirmed it worked well on Japanese language edition with Japqanese text string. I and some Japanese user will check and revert if anything other than designated/expected. Thank for your contribution.--Namazu-tron (talk) 08:27, 28 November 2008 (UTC)[reply]
Suggestions
You need a talk page.
You need an explanation on Wikimedia.de grep how to user wildcards. I still have no idea.
List of*bands gave zero results, even though there are several articles with this name.
Like most external programs examining wikipedia, this one is slower than wikipedia's own searches.
It would be nice if the default language was English to. Ikip (talk) 12:54, 31 January 2009 (UTC)[reply]

Felicia and Felix

Feliciano, being the Spanish variant of Felix, and therefore masculin, should be listed under Felix rather then under Felicia, or perhaps under Felix as well. Peter Horn 18:03, 2 May 2008 (UTC)[reply]

Special:PrefixIndex is just a list of pages beginning with the string searched for. So 3215 Lapko shows up when you enter 321, and Feliciano shows under Felicia because thats the 8 first letters. There is currently no way to implement making feliciano popping up when felix is entered. You might want to edit the disambiguation page Felix. Taemyr (talk) 22:47, 2 May 2008 (UTC)[reply]

No sub-subpages

Is there a way to Special:PrefixIndex some thing without getting the sub pages of the subpages.EE 20:33, 7 July 2008 (UTC)[reply]

Ex.
You PrefixIndex Wikipedia
You get Wikipedia/A and Wikipedia/A/B
But you only want Wikipedia/A.

EE 20:35, 7 July 2008 (UTC)[reply]

Renamed the section from «Question». —AlexSm 20:55, 7 July 2008 (UTC)[reply]
No. You could try a grep tool tool on toolserver, with the search expression like ^Wikipedia/[^\/]*$ —AlexSm 20:55, 7 July 2008 (UTC)[reply]
Is there a way to transclude it?EE 20:57, 7 July 2008 (UTC)[reply]
No, you cannot transclude anything from external sources. —AlexSm 21:01, 7 July 2008 (UTC)[reply]

Vertical instead of horizontal alphabetical display

Can lists be arranged vertically instead of horizontally? —Preceding unsigned comment added by Richard David Ramsey (talk • contribs) 20:08, 30 August 2008 (UTC) The lists would be easier to read if vertical. —Preceding unsigned comment added by 68.49.184.143 (talk) 01:09, 19 November 2008 (UTC)[reply]

Agree. Like {{reflist|2}} does. Think telephone directories.MinorProphet (talk) 16:52, 22 September 2011 (UTC)[reply]

Yes this would be helpful. Also can one change the number of vertical columns to more than 3? — Preceding unsigned comment added by 122.174.66.95 (talk) 05:08, 30 May 2012 (UTC)[reply]

All page names containing a string

{{editprotected}}

Such a request cannot be done by admins and would have to be implemented by a developer. You may make a request for such a feature at Bugzilla. If you're looking for this information now, you might try the database dump page, which contains an easy way to download the list of all page titles (which you'll then have to process yourself to extract the relevant information). --CapitalR (talk) 09:40, 19 March 2009 (UTC)[reply]
Also note that AWB has a Database Scanner feature that lets you filter the list of all page titles based on strings (or regexes). I use this all the time and highly recommend using it to solve your problems if you're not already using it. --CapitalR (talk) 09:44, 19 March 2009 (UTC)[reply]
Query Result
intitle:airport All articles with airport in their title.
intitle:international airport Articles containing international and airport in their title (including World's busiest airports by international passenger traffic).
parking intitle:airport Articles with "airport" in their title and "parking" in their text
intitle:"international airport"   Articles containing the exact expression "international airport" in their title.
-- Uzma Gamal (talk) 16:01, 5 February 2013 (UTC)[reply]

Suffix

Is their a Speical:SuffixIndex search on Wikipedia? --75.154.186.241 (talk) 23:50, 12 April 2009 (UTC)[reply]

Not officially, but you can use this grep tool on the toolserver to search for arbitrary strings in titles using Regular expressions. --CapitalR (talk) 03:08, 13 April 2009 (UTC)[reply]

See #SuffixIndex above. Jidanni (talk) 09:09, 20 November 2010 (UTC)[reply]

Inappropriate default search?

Special:PrefixIndex is a handy resource just two clicks from any page via Navigation|Special Pages. Reasonably enough, it defaults to page one of a sorted list of all WP articles. Unfortunately, the first few titles are ones some people find offensive. The articles are encyclopaedic, they fall naturally at the top of the sort order and I fully endorse WP's policy of not bowdlerising, but they may give a misleading impression of WP to the (possibly young) searcher. Should we consider displaying them only if they are requested using Display pages with prefix ! or similar? Certes (talk) 23:56, 28 September 2009 (UTC)[reply]

I agree, there is no need to list the first 100 articles when the page is first opened. I use this special page for the search engine, and that is all I want to see when I open it. 117Avenue (talk) 21:21, 6 October 2009 (UTC)[reply]

I agree too, besides the profanity, the default search is not really useful. I have submitted bugzilla:21143 on this, since I assume it would require a software change. • Anakin (talk) 23:15, 14 October 2009 (UTC)[reply]

Thank you. I had assumed this could be configured locally, but let's see if there is support for a software change. Certes (talk) 00:01, 15 October 2009 (UTC)[reply]
It seems nobody else cares. • Anakin (talk) 16:52, 29 October 2009 (UTC)[reply]
These sort of pages often aren't watched by many people. Posting at WP:VPT to notify of discussion helps. Rd232 talk 07:55, 31 October 2009 (UTC)[reply]
Are there any administrators watching this page? 117Avenue (talk) 19:52, 29 October 2009 (UTC)[reply]
No but I bet we could make one, and then he/she would do our bidding. All we need is a Mummy administrator and a Daddy administrator, and a light sprinkling of rouge for taste. • Anakin (talk) 23:10, 29 October 2009 (UTC)[reply]
Looking forward to halloween? 117Avenue (talk) 06:06, 30 October 2009 (UTC)[reply]
You might also want to start a thread at WP:Village pump (technical) Taemyr (talk) 13:25, 30 October 2009 (UTC)[reply]
Thanks, I'll do that. It's probably more sociable than creating !!!!Do you really want to see this article on your default search?. Certes (talk) 19:35, 30 October 2009 (UTC)[reply]
The Village Pump suggestion has now been archived without reply. Maybe we do need that admin... Certes (talk) 23:42, 21 November 2009 (UTC)[reply]

See also the discussion at WP:VPR#Bug vote. Rd232 talk 07:58, 31 October 2009 (UTC)[reply]

This discussion seems important -- I'm going to see about getting something done on this. Thanks to you all for highlighting this issue. -Pete (talk) 22:25, 11 June 2010 (UTC) Okay, I filed a bug and will try to keep an eye, to make sure somebody gets to it! See this bugzilla entry. -Pete (talk) 23:48, 11 June 2010 (UTC)[reply]

Thanks. 117Avenue (talk) 00:00, 12 June 2010 (UTC)[reply]
  • I, too, would be happier with just the search engine without any search results. There are no "default" results when you first navigate to Google, Yahoo! Search, or AltaVista etc, just the box, the logo, the buttons, and a few links to pages related to the search engine. Alexa does give you the top ten hot pages, top ten searches, etc, true. But then that engine is about rakings. Amazon, eBay give you results because they are commercial sites and are trying to sell you stuff, of course. We are not trying to sell anything nor is there anything special about !!!Fuck You!!!, !!Fuck you!!, !!!Fuck You!!! and Then Some, etc, or indeed !Action Pact!, !? (chess), !!! (album), or !Alla tu! apart from the fact that they are all at the start of the "alphabet". A better alternative to no search results would be random results, if we must have results at all, IMO --Jubilee♫clipman 08:58, 18 June 2010 (UTC)[reply]
Looks like we might finally be getting somewhere on this -- not sure when this would be deployed on en:wp or anywhere else, but it looks like it's been fixed in the MediaWiki software: mw:Special:Code/MediaWiki/75314 -Pete (talk) 17:40, 24 October 2010 (UTC)[reply]
It took over a year, but thank-you. 117Avenue (talk) 23:38, 24 October 2010 (UTC)[reply]

 Done For anyone paying attention -- I don't know when it took effect, but I see the fix has taken effect here on en-wp now. -Pete (talk) 05:19, 13 May 2011 (UTC)[reply]

Google search trick to help with suffixes

In Google search, try the following (quote marks included):

  • "http://en.wikipedia.org/wiki/*%s"
  • "http://en.wikipedia.org/wiki/ * %s"

where you replace "%s" with the suffix you're interested in. It's imperfect but useful. — ¾-10 20:11, 13 February 2010 (UTC)[reply]

This will find references to those pages on other sites as well, you'd be better off with:

  • site:en.wikipedia.org inurl:"wiki/*%s"
  • site:en.wikipedia.org inurl:%s (assuming your string isn't present in "en.wikipedia.org/wiki")

Bigmantonyd (talk) 01:44, 26 January 2011 (UTC)[reply]

Any way to force the page list to be on one page?

Having upgraded to 1.15.3 recently the result of looking for all pages in Special:PrefixIndex is a list split into more than one page. Special:All pages doesn't give you a list at all, but a list of links to the "search results". Is there some way to get a list of all pages on one page, or to configure how many results are in each page on Special:PrefixIndex? Thanks Windinthew (talk) 02:53, 29 April 2010 (UTC)[reply]

I searched for the same thing, but did not find it. Instead I used the tool Cat scan on the root category. The result for no:wp was about 15% of all the articles and for sv:wp about 50%. I did not try it with en:wp to Category:Fundamental, but I guess you will have the same experience. Any complete list (with the possibility to filter out disambiguation and redirect pages) will be appreciated. --Cavernia (talk) 14:51, 1 May 2010 (UTC)[reply]
Listing 6,816,113 things on one page is a bad idea... At the moment the limit on special:allpages/prefixindex is not configurable. Bawolff (talk) 05:46, 12 May 2011 (UTC)[reply]

Is there anyway to place a magic word of some kind on pages you wish to exclude from this type of search?

I'm using {{Special:PrefixIndex/User:Technical_13/}} to list all of my user subpages on my user page, but would like to be able to have some of them not show up on the list. Specifically, I would like to not have my custom js and css and my userpage helper pages show up. I know I can use {{nobots}} to exclude bots from editing pages and what I am looking for is something similar to have those pages not show up. — T13   ( C • M • Click to learn how to view this signature as intended ) 18:33, 9 March 2013 (UTC)[reply]

No, I don't believe there is. You could always just move only the pages you want to display to a different subpage (say, User:Technical 13/display), have any you don't want to display just be under User:Technical 13/, and then transclude Special:PrefixIndex/User:Technical 13/display. Writ Keeper ⚇♔ 13:16, 25 April 2013 (UTC)[reply]

Columns as template

When doing somehting like this: 

{{Special:PrefixIndex/User:MYUSERPAGE/}}

It adds 3 columns. Is there an additional parameter for arranging it in 1 column only? 87.68.237.60 (talk) 14:06, 12 March 2013 (UTC)[reply]


Yes, how do you change it to not three columns? Numbermaniac - T- C 08:19, 25 April 2013 (UTC)[reply]
I don't believe there is a way to do this; have you seen it be arranged in a different way on another page? Writ Keeper ⚇♔ 13:12, 25 April 2013 (UTC)[reply]

A redirect is within mainspace

Forgive me if I'm wrong, but the current message seems misleading to me, on two counts.

  • The current message says "...that pages in italics are redirects", but in fact they are shortcuts. A redirect is a shortcut for mainspace: case in point, Category:Redirects to help pages. A shortcut is a redirect for other spaces.
  • The current message says "Note that the field is case-sensitive...", but in fact, they are not case-sensitive. All redirects/shortcuts are entirely not case sensitive.

How about "The usage of these prefixes in links and searches is not case-sensitive. Pages in italics are shortcuts".

The whole point of case insensitivity goes with quickening the typing, and this is important to be made clear wherever it can. From the user's particular situation they are linking from WP:Namespace#Pseudo-namespaces, say, where the context is typing into a link or into the search box. Isn't it always? Or is our audience also those who would create titles for redirects?

If you think I may be have a point, then here's my proposed discussion: The audience of the (would-be misleading) message is readers, no matter the fact that the audience of the content (that is the list of prefixes) could be those who already know (the rare audience) how to title new pages and who already know a shortcut intimately as a redirect. The prefix is we are listing is usually just "a field", as in "the pseudo-namespace field", that our audience will type into links and search boxes. Now doesn't the way the current message reads carry the implication that "the field" is case sensitive? Shouldn't we discuss the implication "the field" is ever case sensitive? A redirect or shortcut is never case sensitive for our audience, because they are typists, not creators of redirect titles. — CpiralCpiral 18:19, 14 April 2013 (UTC)[reply]

— CpiralCpiral 20:41, 24 April 2013 (UTC)[reply]

No, they're redirects. Shortcuts are a subset of redirects, not the other way around. And it is case-sensitive: try doing a search for "Travis Alexander" and one for "Travis alexander"; the first will return a result and the second will not. The first letter is case-insensitive, but that's because the first letter is case-insensitive in actual article titles, too. The first letter in an article's name is always capitalized in the system, so the software is smart enough to know to search accordingly. But that's only for the first letter. Writ Keeper ⚇♔ 13:22, 25 April 2013 (UTC)[reply]
OK, right, but... Now consider that you are linking to our Special:PrefixIndex report from wp:pseudo-namespace. Aha, to them "the shortcuts are case insensitive"! Here's the rub: the term prefix in the heading Wikipedia:Shortcut#List_of_prefixes is misleading, (and I will tell them so). But I'm representing them here, the ones reading those two pages I link. To them prefix is defined as "initial character(s) ending in colon". For the purposes of this discussion, prefix is properly defined here (as it is at H:S#Syntax), but the issue is still "Shortcut V Redirect" and the mention of "case sensitivity".
From the audience's perspective that I'm representing in my complaint, "Travis Alexander" is not an acceptable example of the case sensitivity counter-claim I make. From their perspective, newly advancing editors need to know that all redirects are case-insensitive except for articles. So the message I'm questioning here, (and it is still in question, thank you), is making assumptions about the audience. To the audience I'm representing then, "the shortcuts are case-insensitive". To article editors though, "the redirects are case-sensitive". I think there is a way the message can be made correct for both audiences. For now it is only correct for article editors.
Based on the above two paragraphs, I'm certain the real audience needs to read both terms "redirect" and "shortcut", and I'm certain the audience need not be told anything about case sensitivity, (they can learn that elsewhere). — CpiralCpiral 17:37, 26 April 2013 (UTC)[reply]
I don't know what you're talking about; shortcuts are case-sensitive, just like any other redirect, no matter if it's to an article or a WP: page or whatever. WP:Ani is a separate page from WP:ANI; they just have both been created to point to the same place. Writ Keeper ⚇♔ 19:49, 26 April 2013 (UTC)[reply]
You're technically right. And the shortcuts at the links I gave above make no mention of the limited perspective they have on the matter here. From their POV: they're all caps on the shortcuts, they can all be lowercase in the search box, and so the case sensitive statement just seems like hot air. They're routinely made case insensitive in any sense that matters. I'm OK on this now. Thank you for the interaction, Writ Keeper. — CpiralCpiral 05:30, 27 April 2013 (UTC)[reply]

Can we get some answers, please?

I welcome you, our honored administrator, to look over this talk page and see if some of these long ago asked questions can possibly get some answers or updates. For any responses you can offer I thank you and appreciate it. Technical 13 (talk) 11:57, 25 April 2013 (UTC)[reply]

Uh, why do you need an admin specifically? Writ Keeper ⚇♔ 13:09, 25 April 2013 (UTC)[reply]
I suppose a MWF dev would have worked too, is there a {{Dev help}} or {{WMF help}} (if not, should there be)? Thank you for taking the time to go through and find the unanswered questions and putting a response in. :) Happy editing! Technical 13 (talk) 14:35, 25 April 2013 (UTC)[reply]
Yep, no problem. Just pointing out, though, that, despite its name (and its historical and even more misleading name "sysop"), being admin doesn't necessarily imply great knowledge of wikicode or really any technical ability at all; several of the admins I have the absolute most respect for couldn't wikicode their way out of a paper bag. Inversely, several of the editors for whom I have the greatest respect for their technical skills aren't admins. (No names, of course.) My point is, though it's of course not that big a deal, using the standard helpme template instead of the admin-help template for technical questions like this might get you a better pool of editors to draw from for answers. Unless it's a technical question that requires the admin rights to answer (like an edit request on a full-protected template or something), of course.
As for the dev-help, I doubt that exists or would be useful; I'm not sure how many of the actual devs or WMF people would regularly check it. :) Writ Keeper ⚇♔ 14:48, 25 April 2013 (UTC)[reply]
I think it is an interesting idea, and I think that someone should ask them. However, it won't be me anytime soon, I'm simply worn out from all of the in-depth discussions lately. Meh, someday... Technical 13 (talk) 15:08, 25 April 2013 (UTC)[reply]

Add an All criteria

Tracked in Phabricator
Task T50945

Can we add some logic to this Special page to allow a view all. It would make it much easier than having to check every namespace individually. Kumioko (talk) 13:30, 25 May 2013 (UTC)[reply]

I would suggest that here and I was thinking that even better than just an "all" would be if we could control-click and select multiple namespaces (but not necessarily all) from the drop down. Technical 13 (talk) 13:41, 25 May 2013 (UTC)[reply]
I like that idea too. You want to write it up or you want me too. It might be better if you did it. Lotsa folks don't like me much and my submitting it would dramatically increasing its chances of failure. Kumioko (talk) 13:49, 25 May 2013 (UTC)[reply]
Sure, but I won't have time until Tuesday next week when I get back to school. I'll post the {{Tracked}} here for it. Technical 13 (talk) 14:34, 25 May 2013 (UTC)[reply]
That's ok thanks. Kumioko (talk) 14:59, 25 May 2013 (UTC)[reply]

Another case for SuffixIndex

How to efficiently search for all redirects that end with 'n' or 'm' letter? See User_talk:West.andrew.g/Popular_redlinks for motivation. Using regexp like '.*[nm]' chokes the toolserver grep.php script pretty badly and it only has the option to exclude redirects, not include only redirects. jni (talk) 17:01, 17 December 2013 (UTC)[reply]

An inpbox available?

{{search archives}} produces an inputbox and a GO! button to search (sub)pages for a text entered. Is there a similart optn with PrefixIndex? So, the template has an inputbox, (for my search term), and a button that opens the Special:PrefixIndex/MySearchTerm. -DePiep (talk) 18:23, 10 November 2014 (UTC)[reply]

Add the option to search for pages in the "Special" namespace

Is it possible to add the option to this page to search for pages in the "Special" namespace? Just wondering since sometimes, it can be a bit difficult to locate pages in the "Special" namespace, and having an option to search for these pages by characters at the beginning of the page's title would be quite helpful. Steel1943 (talk) 21:30, 11 December 2014 (UTC)[reply]

See Special:SpecialPages, it's linked on the sidebar. 117Avenue (talk) 04:08, 13 December 2014 (UTC)[reply]

Case-insensitive search

The PrefixIndex is currently case-sensitive. There should be a case-insensitive search for pages containing a certain string at the beginning, disregarding case. GeoffreyT2000 (talk) 16:22, 31 May 2015 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Special:PrefixIndex&oldid=667067706"