Is it possible to use CirrusSearch to search (the topic pages of) a particular talk page that uses Structured Discussions (like this one)? I.e. restrict search results to only topics from that talk page.
Help talk:CirrusSearch
Appearance
No.
Unfortunately, it’s not possible to search Structured Discussions pages using CirrusSearch at all, with or without constraining the search to a particular page. This is one of the many reasons for which Structured Discussions is deprecated and to be replaced with DiscussionTools.
Please see this thread. How to search for example for a specific string specifically in the source field?
Also how can one search for files from a specific uploader? (I'd like to check which of my video2commons uploads were imported below resolution at source.)
Unfortunately, the image description is simply an argument to a template. CirrusSearch doesn't do anything at that level and can't be that specific. Something like insource:kathmandu
would require the wikitext source to have the word kathmandu in it, but it's not a great substitute.
Regarding filtering by uploader, I'm not too familiar with how the P170 there is structured, but with structured data available it seems plausible the appropriate information could be indexed. Today though P170 is indexed as a plain statement and does not include any context about it. The best workaround i could provide is that the Information template used on many images renders such that the searching for "Author <name>" , with the quotes, tends to bring up only pictures from them.
- I don't know why but the results for insource:"kathmandu" don't seem to show the intended results
- The uploader username is not in the structured data
- The link you shared only shows original works by that username
- So I will create an issue for enabling showing uploads by a particular user (please let me know if this could/should be changed in a tool other than CirrusSearch)
- I think the best workaround currently would be to use insource with the field name first so for example I searched for
insource:"|source=[https://soundcloud.com
to identify files for c:Category:Audio files from Soundcloud.com. I think easily searching fields of the File pages' Information template could be enabled by- Developing some regex that searches for any content after e.g.
|source=
- Creating some alias for it so instead of writing some complex regex query every time one can simply enter e.g.
info-source:"soundcloud.com"
- Developing some regex that searches for any content after e.g.
{{user|keith_d}}
A problem with searching the information template fields for things like author is that author also appears in the {{tl|Credit line}} template and the 2 could be different.
I first misunderstood what you were saying but understood it via your comment in your proposal. That's may be an issue for other templates, but I think in that case it doesn't matter because it would also contain the same author name so it would even be best if both fields are searched (actually it would be a problem if it doesn't search both fields).
I'm not really sure why this is occuring, but I'm pretty sure this isn't supposed to happen in abuse filter logs to this level.
I’m pretty sure plwikiquote shouldn’t block the account from being created (filter 3). I don’t think CirrusSearch is really at fault here – it just tries to create its account on first use. (Since it doesn’t succeed, the next time also counts as the first use. And the next one. And so on.)
Thanks, I didn't know why it was occurring or what abuse filter it was relating to as I can't understand the language.
Thanks, I reported phab:T373778 to have a closer look into it.
I was looking for an older thread...I don't see it on this page, so I assume it's been archived. Unfortunately, Help talk:CirrusSearch/LQT Archive 1 is showing up as blank for me. -- Beland (talk) 01:26, 25 June 2024 (UTC)
That's intentionally blank, as a result of an untidy refactoring in 2015 that's not worth fixing now. This page uses Structured Discussions, which doesn't have the concept of archiving, and instead uses an infinite scroll system.
Aha! Hmm, that seems somewhat poor. There's no indication in the UI that scrolling down to the bottom of the page and staying there will show more threads, and there's no apparent facility for searching the entire history of the page? The URL I loaded was:
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch#Relevance_52070
It seems like that should take me to the thread if it's on the page, but I can't tell if it is or isn't, and searching on my username doesn't really work because some threads are collapsed. -- Beland (talk) 03:40, 25 June 2024 (UTC)
That would be Topic:S8cojikw0xzel2u8 (found via your contributions). The URL seems to have dated from way back when LiquidThreads was involved, and stopped working in 2015 when this page was migrated.
The chance of this getting fixed, realistically, is zero, since both discussion systems are deprecated and going to be removed someday.
Ah, whew, I was a bit worried these were going to be spreading to other wikis. 8)
Ping @User:JWBTH (or anyone who notices this). Referring to these edits, can you also update en:Help:Searching/Regex#Workarounds_for_some_character_classes? I noticed en-wiki's doesn't work but this MediaWiki's does work for newlines.
That ping didn't work so I'll try again: User:JWBTH
Done, thanks for pointing out.
This post was hidden by JWBTH (history)
Hello everybody, is there a possibility to automatically jump/redirect to the first result? Obviously this works for dewiki
https://de.wikipedia.org/w/index.php?search=Espenfeld
but not for Wikidata:
https://www.wikidata.org/w/index.php?search=Am_Hanffgraben_(Berlin)
Maybe there is a parameter that can be added to the URL?
Thank you in advance, --~~~~
There is no such functionality. What you are seeing is title matching. If your search exactly matches the title of a page, it will take you to that page. For wikidata the title of a page is its Q id. So you can do https://www.wikidata.org/w/index.php?search=Q111351350 and it will take you to that Q id.
Hi how to search using multiple key words, For eg: Libra ascendant born on 1965 how could we search this parameters
Simply by typing libra ascendant born 1965
into the search form (I assume "on" is a so called stop word). If there are dedicated categories for a topic you could also use the filter word incategory
, e.g. ascendant libra incategory:"1965 births"
.
Hi. In case I want to search (fuzzy search) two words with a word to fit in but not the exact sequence of the two words, is it possible? For example I want "flowers for Algernon" to be in findings but not "flowers Algernon".
Hi,
Unfortunately no, you could do an approximation by using a negation: "flowers Algernon"~1 NOT "flowers Algernon"
.
The first part would find documents with flowers algernon or flowers for algernon and the second part would exclude documents matching flowers algernon.
In the end you might find pages that have occurrences of flowers for algernon but not all of them. If a page have both forms flowers for algernon and flowers algernon it would be excluded.
Thank you. It works for me.
Hi, I saw that you contacted me on IRC but I responded too late.
We don't have immediate plans to improve this kind of queries and implement the feature you need so I would suggest to file a new ticket at https://phabricator.wikimedia.org/ (tagging CirrusSearch) to describe your usecase.
Thanks!
i tried to use the deepcat feature, but it shows no result. Replacing deepcat with incategory shows results. So there shall be results especially with deepcat. How can i make this query work?
i just saw, that i did not use Special:Search, where deepcat is working.
Hi all. I had a lot of trouble understanding the #Prefix and namespace section, so I did my best to make it more readable.
Specifically confusing was term vs. term:
, so I tried to make that more consistent within that section. When I see code
, the programmer part of my brain thinks "oh, I type this in." Italics is used in prose for emphasis, is not very visually distinctive, and therefore doesn't trigger the same "oh, I must do something!" response. So I hope it makes sense why I think term:
is preferable here.
Secondly, the HTML <kbd>
tag is typically used to denote hotkeys, such as Control+c, but I had a look at the MDN docs and it seems that using it for strings of literal text input is OK, too. What would be the preference then, <kbd>
or <code>
?
Would it be helpful to do a pass over the whole article, or the whole batch of CirrusSearch user-facing documentation, in order to make the use of ''term''
/ <code>term</code>
/ <kbd>term</kbd>
more consistent? --Ernstkm (talk) 03:17, 12 November 2023 (UTC)
Thanks for improving the documentation!
I think clarity is the most important goal, but consistency almost always helps with clarity. A lot of what the italics and <code>
/<kbd>
markup is trying to get at is the use–mention distinction. The problem is that there's no consistency on how to format mentions, and different traditions vary, so we are collectively not always consistent.
Adding the monospaced <code>
or <kbd>
to the mix lets us make finer distinctions (linguistics does this kind of thing, too, sometimes using both italics and quotes for different mentions, and mixing single and double quotes: He said, "I told my cat that gato means 'cat' in Spanish.") Search discussions often use italics rather than quotes so we can mention quotes: You should search for "pet" dog cat. And like you, I tend to interpret monospaced
text as things I could type; I guess it's a tech-flavored mention.
I guess I'm mostly agreeing that it's a mess, but I think that trying to make another finer distinction between <code>
and <kbd>
would only make it messier and harder for newcomers to understand or contribute. Since ⌘ Command+⇧ Shift+6 (on a Mac) generates <code>
tags, that's probably the best thing to standardize on—unless clarity of formatting creates a reason to use <kbd>
, too.
OK, I agree, and thanks for the lesson on "use-mention distinction." I guess I intuitively knew that was a thing, but didn't know its name.
I'll go ahead and replace the <kbd>
s with <code>
s. I thought the use of <kbd>
was a little odd anyway, given that it's used on other sites like Stack Overflow and GitHub specifically to indicate keypresses, and gets styled like keycaps, in the same way that {{key press}} is used here.
…or not. There are 420 uses of <kbd>
in the article. I could search-and-replace all of them, but I'm not sure that improves the article materially. Leaving as is for now.
> …or not. There are 420 uses of <kbd>
in the article.
Fair enough!