Help talk:Searching
![]() | This is not for searching for help (in general). To seek help with searching go to Wikipedia:Village Pump (Technical). Activity here improves search-box and search-results documentation. We like comments and help requests related to our Search technology. |
This is the talk page for discussing improvements to the Searching page. |
|
Archives: 1, 2, 3, 4, 5, 6Auto-archiving period: 120 days ![]() |
![]() | This help page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
![]() | Help:Searching is a reader-facing page intended for viewing by non-editors. Please prioritize their needs when adjusting its design, and move editor-facing elements to other pages. |
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III when more than 10 sections are present. |
Searching redirects
editIs there a way to search redirects? Insource and Intitle seem to exclude redirects. I don't see anything in the docs about this. Dicklyon (talk) 00:23, 19 May 2023 (UTC)
- @Dicklyon: You can use insource to search for pages that include
#REDIRECT
. Jarble (talk) 16:15, 11 September 2023 (UTC)
Wildcards
editIs there a reason why wildcard characters can't be used at the beginning of a search string? In other words, is there a way to search for articles whose titles end in a particular set of characters? Let's say, for example, I want to find every town whose name ends in "-borough". Zacwill (talk) 21:58, 17 October 2023 (UTC)
- I don't have an answer for the first question, but I have for the second one: Unfortunately, MediaWiki's search engine doesn't support the regex metacharacters
^
and$
that are normally used to mark the start and end position of a string. But if you're familiar with PetScan and have a category, search string, pages that use a certain template or anything like that in mind, there's "Regexp filter" in the "Output" tab that you can use to findarticles whose titles end in a particular set of characters
by using^
and$
in PetScan's "Regexp filter":^.*Example$
(replace "Example" with your regex search string in that search string). For example, articles in "Category:Boroughs" whose name ends in "borough" or articles found with the search string "intitle:/borough/" whose name ends in "borough". --JAAqqO (talk) 22:48, 17 October 2023 (UTC)
- That's very helpful, thank you. One more question: can I use this method to search Wikipedias besides the English Wikipedia? Zacwill (talk) 23:15, 17 October 2023 (UTC)
- Never mind, I think I've figured it out. Thanks again! Zacwill (talk) 23:18, 17 October 2023 (UTC)
- That's very helpful, thank you. One more question: can I use this method to search Wikipedias besides the English Wikipedia? Zacwill (talk) 23:15, 17 October 2023 (UTC)
Are Wikidata queries supported?
editThis page doesn't mention Wikidata search queries. Does Wikipedia support queries using wbstatement
, like Wikimedia Commons? Jarble (talk) 19:51, 18 November 2023 (UTC)
Searching for quote marks
editIs there a way to search for strings that include quote marks? — BarrelProof (talk) 22:32, 25 December 2023 (UTC)
insource:/\“/
ltbdl (talk) 02:02, 26 December 2023 (UTC)- Thank you. That helps a lot. But
intitle:/\"/ -incategory:"Articles with quotation marks in the title"
finds both article titles and redirects. I don't want the redirects. — BarrelProof (talk) 03:44, 26 December 2023 (UTC)- maybe
-insource:/\#REDIRECT/
? ltbdl (talk) 04:33, 26 December 2023 (UTC)- I tried that already. It didn't work. — BarrelProof (talk) 04:37, 26 December 2023 (UTC)
In fact I think maybe that only finds redirects.I triedintitle:/\«/
and it didn't find the article at «O», but it found a few redirects. Or maybe the problem has something to do with the timeout error I received. It says to "Try simplifying your regular expression to get complete results", but it is hard to conceive of a simpler regular expression than that. — BarrelProof (talk) 04:49, 26 December 2023 (UTC)- Just found this in the Help page: "phab:T204089 – why you can't specifically include or exclude redirects from your search results". — BarrelProof (talk) 02:49, 27 December 2023 (UTC)
- maybe
- Thank you. That helps a lot. But
- There's always PetScan that can filter out redirects from searches: use the
Redirects
field in thePage properties
tab and theSearch
field in theOther sources
tab. For example, here's a PetScan search for articles that 1) use the template {{Infobox film}}, 2) aren't redirects, 3) aren't in the Category:Articles with quotation marks in the title and 4) match the title regexp filter^.*("|“|”|«|»).*$
.
"Try simplifying your regular expression to get complete results
" – yeah, if you don't have a category, search string, pages that use a certain template or anything restrictive like that in mind (like the template "Infobox film" in my PetScan search), then—because of the limits of PetScan and MediaWiki's search engine—your best bet is to download the database and then use a tool like WP:AWB for searching. For example, based on the datadumpenwiki-latest-pages-articles-multistream.xml.bz2 02-Dec-2023 03:27
, I made a list that lists about 2,400 articles that, as of 2 December 2023, 1) have “, ”, ", « or » in their titles, 2) aren't in the category Category:Articles with quotation marks in the title and 3) aren't redirects. And here's a PetScan search that updates that list automatically. --JAAqqO (talk) 17:37, 27 December 2023 (UTC)- That's very helpful; I'll study it. Thank you. — BarrelProof (talk) 00:50, 28 December 2023 (UTC)
- There's always PetScan that can filter out redirects from searches: use the
Unable to ID articles. Unable to search for text in the actual final pages.
editthis search for insource:/\<span style=\"border:thin solid black;\"\>WARNING\<\/span\>/ is failing.
I'm trying to find which of the pages linked to from https://en.wikipedia.org/wiki/User:RudolfoMD/sandbox2 do not display the boxed warning. I want all of them to display it. They all should, but some of the wikidata entries haven't been updated (I don't understand why; I'm an OpenRefine beginner.) It seems like search searches the wikitext, not the resulting HTML pages. Any ideas on how to do what I want - at the high medium or low level? (It seems that this is, de facto, a place where folks are asking questions about search problems and getting answers, so I'm going ahead.) RudolfoMD (talk) 05:52, 27 December 2023 (UTC)
- So, are you looking for articles that don't show the input "Legal status: US: WARNING" in {{Infobox drug}} from the property legal status (medicine) (P3493)? If so, here are PetScan searches for the articles that are:
- 1) linked from User:RudolfoMD/sandbox2 and 2) don't have boxed warning (Q879952) set on Wikidata: [1]
- 1) linked from User:RudolfoMD/sandbox2 and 2) don't have {{Infobox drug}}: [2]
- --JAAqqO (talk) 16:32, 27 December 2023 (UTC)
- Thanks! I lost my initial comment thanking you. I was able to improve the situation somewhat using your searches. Both were useful! (how odd that an IP deleted this section!) RudolfoMD (talk) 06:07, 11 January 2024 (UTC)
Searching for strings only inside/outside refs?
editIs there any way to limit a search to only inside or only outside of refs in an article? Inside seems like it *might* be possible using regex, outside, I don't really see how... Naraht (talk) 14:28, 12 March 2024 (UTC)
- Try these:
- Inside (example search):
insource:"Hello" insource:/\<ref(>| name[^>\/]+>)[^<]*Hello/
- Outside (example search):
Hello insource:/\[https?:\/\/[^ ]+ Hello/ -insource:/\<ref(>| name[^>\/]+>)[^<]*Hello/
- Just change the example word and regex in green. The
insource:"Hello"
or just simplyHello
in the beginning of these search strings is used to restrict the search, so the search wouldn't time out and then give only partial results. - There's also a problem with that outside search: if a page has what you're searching for but also has the same matching search string inside a ref tag, the page won't be included in the search results.
- --JAAqqO (talk) 19:47, 12 March 2024 (UTC)
Searching for specific content added by self
editI'd like to run a search for all articles to which I've added the {{IPAc-en}} template. Sometimes I left edit summaries saying so, sometimes not. How do I do this? Mac Dreamstate (talk) 21:19, 26 June 2024 (UTC)
Help:Searching#All:
editIn that section it says Prefixing "All:" to a search string, searches all namespaces, and prioritizes mainspace matches to the top.
- this does not appear to be true.
Try the following searches:
- Special:Search/All: "your base" -> it highlights the word All implying it was actually searched as a word;
- Special:Search/All: "EFFPR" vs Special:Search/all: "EFFPR" -> first one shows no result, second one shows various matches in non-article namespace.
Am I missing something? – 2804:F1...A9:64C1 (talk) 05:26, 28 June 2024 (UTC)
- I seem to get the same (and the expected) results for searches on All: "your base", all: "your base", All:"your base", all:"your base", namely between 100 and 250 results, with mainspace ones at the top. The space after : is not needed, and quotation marks would not be needed around a single-word term like EFFPR. I'm not sure what's causing your difficulties. What are the circumstances (browser versus mobile app, etc.)? — SMcCandlish ☏ ¢ 😼 02:26, 8 July 2024 (UTC)
- I'm using Google Chrome on PC (Windows 10), settings should all be default (as I use Wikipedia in incognito so any cookies reset every day and every time I close the browser).
- I mean, I don't know about searching all: "your base" (that also gives me many results, though without the word all being highlighted (bolded) in the results) - but the thing with All: "EFFPR", is that it shows no results, presumably because for some reason it isn't searching for "EFFPR" in all namespaces like it does when the all: is in lowercase.
- Are you saying that Special:Search/All: "EFFPR" brings results for you, that presumably I'm running into a bug? – 2804:F1...18:7DDA (talk) 02:33, 8 July 2024 (UTC)
- I get 247 results for all:EFFPR, all: EFFPR, all:"EFFPR", and all: "EFFPR"; all identical (and expected) behavior. However, All: EFFPR produces bogus results of 259,538, matching on strings like effort. Meanwhile, All:EFFPR, All:"EFFPR", and All: "EFFPR" each produce no hits. So, there is clearly an interpretation consistency problem of some kind here. The documentation should be changed to say to use all: not All:, and this may affect other such keywords as well. I would think a phab ticket also needs to be opened about this, since case-sensitivity of these search keywords is not expected behavior. Nor is All: EFFPR producing bogus matches for effort and other strings that just contain eff... substrings. I have no idea where it got the idea to do a lower-casing substring match. PS: It's weird that All: "your base" produces 139 hits, All:"your base" same (seemingly all confined to mainspace, and with a few substring matches such as just all (presumably near your or base; but all:"your base" and all: "your base" produce 2,529 hits (sorted by namespace, though also wandering eventually into substring matches like "when your base assumption is"). I don't really know what's going on here. But clearly a capitalized All: either fails to find all the applicable results (excluding all but mainspace, and not findinal all occurrences in mainspace), or fails to find any at all, or falsely matches random word-fragment substrings; while the worst that can be said about the all: version is that it will eventually start ignoring the "..." constraint and will include substring matches (though seemingly only whole-word ones, not word-fragment ones) instead of only the exact phrase. — SMcCandlish ☏ ¢ 😼 03:11, 8 July 2024 (UTC)
- What you described matches what happens for me, yeah. An observation:
- - Special:Search/All: "your base" -> finds 139 results (all in article space), second result is Tatsuya Uemura (category All stub articles);
- - Special:Search/"All" "your base" -> finds 139 results, identical results to the search above;
- - Special:Search/ "your base" -> finds 145 results (all in article space), second result is Tatsuya Uemura no category mentioned;
- - Special:Search/-all "your base" -> finds 6 results;
- - Special:Search/all: "your base" -> finds 2527 results, a lot of results in the Talk: and Wikipedia: namespaces.
- The first 2 searches being identical makes me think that the word All is being included as a search term, that's why it fails to find some results, because they don't have the word all: 145 - 6 = 139.
- You're welcome to make a phab ticket if you want, I'd have to make an account to do so, I don't want to do that. – 2804:F1...18:7DDA (talk) 03:27, 8 July 2024 (UTC)
- About this "hyper-anonymity", I have to ask "To what end?" Accounts here are pseudonymous, and you need not use one you create for more than whatever purpose an account is needed, not even more than once. You could just create an account named "User:2804-etc." and use it for no purpose other than this sort of thing. I might get around to opening a phab ticket, but I have about 100+ projects of all sorts going on at once (only a small fraction of them to do with WP). — SMcCandlish ☏ ¢ 😼 17:33, 19 July 2024 (UTC)
- I get 247 results for all:EFFPR, all: EFFPR, all:"EFFPR", and all: "EFFPR"; all identical (and expected) behavior. However, All: EFFPR produces bogus results of 259,538, matching on strings like effort. Meanwhile, All:EFFPR, All:"EFFPR", and All: "EFFPR" each produce no hits. So, there is clearly an interpretation consistency problem of some kind here. The documentation should be changed to say to use all: not All:, and this may affect other such keywords as well. I would think a phab ticket also needs to be opened about this, since case-sensitivity of these search keywords is not expected behavior. Nor is All: EFFPR producing bogus matches for effort and other strings that just contain eff... substrings. I have no idea where it got the idea to do a lower-casing substring match. PS: It's weird that All: "your base" produces 139 hits, All:"your base" same (seemingly all confined to mainspace, and with a few substring matches such as just all (presumably near your or base; but all:"your base" and all: "your base" produce 2,529 hits (sorted by namespace, though also wandering eventually into substring matches like "when your base assumption is"). I don't really know what's going on here. But clearly a capitalized All: either fails to find all the applicable results (excluding all but mainspace, and not findinal all occurrences in mainspace), or fails to find any at all, or falsely matches random word-fragment substrings; while the worst that can be said about the all: version is that it will eventually start ignoring the "..." constraint and will include substring matches (though seemingly only whole-word ones, not word-fragment ones) instead of only the exact phrase. — SMcCandlish ☏ ¢ 😼 03:11, 8 July 2024 (UTC)
Semi-protected edit request on 18 July 2024
editThis edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
See the section above.
Please either comment out or remove the Help:Searching#All section -> prefixing searches with All: currently does not work as described. – 2804:F1...93:9B16 (talk) 00:25, 18 July 2024 (UTC)
- Done, along with a bunch of other cleanup. — SMcCandlish ☏ ¢ 😼 19:30, 19 July 2024 (UTC)
Invalid section tagging in the page
editThe wikisource of this page has a bunch of <section>
markup, all of which appears to be broken. In order of appearance, it is in this form:
<section end="Search results page" /><section begin="Refining results" /> ... <section end="User preferences" /><section begin="Redirects" /> ... <section end="Other uses" /><section begin="User preferences" />
This all appears to be invalid, either because it is in backwards order or because it a start tag without an end tag or vice versa. I'm not sure what the intent was and what other pages might be trying to selectively transclude portions of this page, so I have not removed this broken code or attempted to repair it. Someone(s) else who better know(s) what the intended results were will need to address this. — SMcCandlish ☏ ¢ 😼 19:38, 19 July 2024 (UTC)