Help talk:Extension:AdvancedSearch

Feedback and discussion page for the AdvancedSearch feature.

Is it possible to add the incategory parameter to the search options? I read this feature is among the not planned ones, since it brings noise to the search results especially in WMF projects. Anyway it would be a very useful feature for smaller wikis. What do you think?

As noted on that page. Incategory doesnt behave as most ppl expect it to behave in that it doesnt take into account subcategories, which just makes it confusing to most ppl. As such it was decided to until the subcategory search problem has been fixed.

I tried to "namespaces"%3A["3"%2C"5"%2C"11"%2C"15"} search] cs:Category:Údržba:Wikidata only in talkpages (I was discussing this category some years ago). I selected only talk namespaces. But there was 125 results, all in namespace 14, which was not selected.

And second "bug" - search URL is not easily copyable to wikitext

Hi @JAn Dudík, thanks for the report! I created a ticket for the bug: and we will look into it. I also created a ticket for the second issue, so that we have it on our radar - .

Would be really useful in many cases when searching noticeboards.

Hi, The scope of the AdvancedSearch-Extension is to make search options that already exist more usable and visible by creating an user interface for it. There currently is no feature in the search-engine to sort the search results by date. Adding new features to the search-engine is out of scope of this project but the Wikimedia Search Platform-Team is always working on improving the search-engine. There is already a ticket for this proposal: T18237 – you can comment, subscribe or award a like to that. There's also a user-script that can help with that: User:PerfektesChaos/js/resultListSort

The recommendations beneath the search textbox don't take the selected namespaces into account. As a result Articles show up even if the (Article) namespace is not selected and I still need to type the namespace prefix to get anything else to appear.

Thanks for that feedback. I created a ticket for it, so that we have it on our radar.

Tracked in Phabricator
Task T195346

On my iPad, clicking on “Add namespaces...” brings up a menu of namespaces that scrolls weirdly, and there’s no way to make it go away! It covers up the whole search area and I can’t do anything else. The only way I can get rid of it is to reload the page, but then I’m right back where I started, in article space only. Since I edit ONLY on my iPad, I’ll have to turn off this beta version so that I can conduct searches in other namespaces. :-(

It would be best if the developers working on the mobile version would take a look at what I mean, as I really can’t describe it adequately. (I work in landscape mode almost exclusively, on the “desktop version” of the webpages, not the mobile version.)

(Mobile Safari, iOS 11.3.1 on an iPad Air 2)

I created ticket phab:T195346 for this issue.

On the Wikisources, we have numerous sets of multi-volume works: dictionaries, encyclopaedias, periodicals, complete works of ..., etc.. We have been utilising something like {{engine}} to present a "search within" facility (an example of such a work is s:en:1911 Encyclopædia Britannica )

For me what I would like to do and I am wondering whether it is able to be done

• the ability to have the advanced search form availableand to embed it in a page—ideally through a template
• prefilled data fields, for my case example using either prefix field or intitle field (though not wanting to limit the scope)
• collapsed to one line for search text (to reduce its visual space) though able to be expanded easily to show fields (though again selecting fields to display would be cool)

If that is not able to be done at this stage in all or part, but it is possible, then I will guess that a phabricator: ticket is the next step.

Hi, thanks for your feedback! What you can do already is: 1. You can use all search-options that Advanced Search can use (and more) with the inputbox-feature that you were referring to by using the parameter searchfilter. This works with and without Advanced Search but the filters will always be shown in the searchbar and not in the filters of advanced search. 2. You can link to a prefilled Advanced Search form like this (Advanced Search beta feature has to be enabled on target wiki to work).

Embedding the search page (including Advanced Search) is not possible. One possibility to reach your target (as I understood it) would be to improve the InputBox-Extension to support setting search options in advanced search. This would probably be out of scope of this project and would have to be done by or in coordination with the developers of the InputBox-Extension.

Feel free to create a ticket for that – if you need any help with that, I’m happy to help.

While the syntax for AdvancedSearch in search options within a url is that complex, it is going to be limited to the courageous to construct. To get anything close to any normal user doing something like that will require template construction by a local wiki. It may be worthwhile to consider a (universal) module to manage those elements more succinctly.

When I follow the pre-filled link, to arrive back to the advanced form (collapsed) with the filters, the down arrow to uncollapse gets lost in the business of the page. See screenshot: red for the uncollapse, and all the yellow for all the other noisy components you can do. Could there be consideration given to making the expand down arrow more overt, either in its definition, or its placement.

This is likely not a long-term issue, but the link to provide feedback here (in the feedback span) is largely hidden in the Modern skin, with just enough text poking out to appear broken. Otherwise, enjoying it quite a bit.

Hi, thanks for your feedback. I created a ticket for it, so that we have it on our radar. I'm just wondering, since I could not fully reproduce: on my system the feedback-note is not visible at all if using modern-skin. Is it still the case for you?

Yup! Happens here as well as enWiki, with or without safemode. Firefox on macOS FWIW.

Thanks. That's weird – I cannot reproduce it. But since the modern-skin is only used by a small amount of people and it's only about the hint-text wish will anyway vanish soon – I think that this it not worth digging much deeper into this – sorry.

This is a good thing to have; I like the ease of use and the design.

I second that!

Thank you very much for the nice feedback - this means a lot to us :-) In case you encounter any issues with the feature, please let us know as well! Thanks again, Birgit

Dear developer team, Thanks a lot for this extension. This is really a very helpful extension to have. : )

Hi @Navinsingh133, thank you very much for the nice feedback, we're really happy that the extension is useful for you :-)

Thanks

positive feedback on the design work for AdvancedSearch

I literally just got this so I'm not in a position to give any detailed feedback yet but it looks great! I'm in awe of the work you guys are doing. And a special shout-out to the designer and the UI/UX team, Wikidata looks *and* feels so fresh and modern, keep doing what you're doing👏👌👍

Thank you so much for the kind words! We're happy that you like it! :)

Positive feedback on AdvancedSearch

انها جيد جد

Thanks for the feedback! Glad that you like it :)

Advanced parameters → Exactly this text → "Information" icon → the tooltip content overlaps with the personal toolbar.

Hi @Jack who built the house, thanks for the report! We created a phabricator ticket for the issue: T194765.

AdvancedSearch should not influence the loading time of Special:Search negatively.

I know that not a lot of users disable JavaScript and so it is not an imminent worry for developers to support such users. However, having every special page render after 3 seconds or more because developers did not worry about the first paint render is unsatisfying, and it is completely unacceptable to have even a basic search page load and render via JavaScript-only.

I can only hope that developers would consider making this a form that is available on first paint, working and fully functional without any JavaScript loaded. If that is not on plan for developers before the (eventual) deploying of this form for all users, then frankly this should be rejected (as it is a clear regression from previous state, where you could use the advanced search form without JavaScript and without waiting for OOUI/other JavaScript to load).

Wikipedia interface already seems really inaccessible and unresponsive because of stuff like new RC Filters, RevisionSlider and the like, one must dread the day when article text will be loaded entirely via JavaScript too.

As MediaWiki developers we actually put a lot of effort into avoiding such problem. Whenever possible, we make it so that PHP widgets with basic functionality are progressively enhanced with JS (aka infused), without any reflow of the page. We forbid reflows due to late loading in newer code (while we are still working on getting rid of some of those cases in the old code). It's the sole reason it took so long before we started adding some of this stuff.

However !

1. You have to actually disable Javascript, not BLOCK javascript urls. Blocking JS urls will cause broken pages and will never be supported.
2. Not ALL functionality can be done in plain HTML. And if the functionality is useless without Javascript, you are not getting the functionality. And even for some more advanced stuff, it's often just not worth it (like it costs too much money for too few users). So for advanced search for instance that might mean, that as there already is a fallback (using syntax), you won't get it (because the form is too big to always show).
3. Some widgets (Like revisionslider) are useless without Javascript, so while we reserve space for them, we don't generate them serverside with PHP, as that would be pointless.
4. Many wiki's have local customizations in place, that sometimes cause this to break.
5. Beta and Alpha products do not follow all those rules (as it adds too much development time in a phase where it's not certain yet that the direction is)

The ticket for this issue specifically with Advanced Search is mostly: https://phabricator.wikimedia.org/T189028

Avoiding reflows via hiding the form is not enough. Form should not load for noticeable amounts of time at all. Accordingly, stuff like ‘Advanced search options’ should not require rendering via JavaScript at all, even with it enabled, since that is what brings the visible performance down the most. So I am aware of the solutions that hide the problem, and I am talking about getting rid of it.

While it might not be enough for you, it is currently enough according to our development standards. Now if your wiki's community doesn't want advanced search installed, they can probably file a ticket and request that for their wiki it won't become available by default. But for now it's still in beta, so that would be a bit premature at this time I think.

I don’t get why you point at (completely unsourced) ‘development standards’ when I am sharing my opinion about the tool. Practice shows that this has to be said at the earliest stages of development possible, otherwise people would point at it as ‘why haven’t you shared your feedback earlier’ when the feature would be eventually released in the wild without any major changes.

Given that WMF developers have a history of wanting to get rid of old tools as soon as they eventually can, in my opinion, it should be talked through that having this interface as a default would be a regression for all people with JavaScript enabled (not disabled, as it shows standard one then) given the load times it currently has.

Eventually this is a typical triangle (money vs time vs features). Everything is possible when you pour enough money into it. Its just that we all have to make trade offs. As a volunteer I sometimes just get annoyed that people seem to have no understanding of "good enough".

Hi @Saint Johann, thanks for coming here to give feedback! To make sure that I understood you correctly, your main point is the loading time of javascript based features in general, right?

My main point is that this tool can’t be our new future default until the functions that non-JavaScript advanced search provided won’t be available as soon as possible instead of ‘as soon as everything loads’ as it is now. Fancy dropdown doesn’t cut it when it comes with a 3-second delay because it has to be rendered completely on the front-end.

Other tools and their respective load times (which are, also, not exceptionally good sometimes) were provided more as an example.

The brief description of this search box says, “Searches for pages with titles that start with this word”.

Shouldn’t it be “Searches for pages with titles that contain this word”?

Thanks for the feedback! Indeed it should be contain instead of start with.

gab es aber nicht, wollte es anlegen, mußte aber jedemenge mist lesen bevor ich den anlegen knopf finde, das alte war besser (und dies hier hält mich auch nur von der eigentlichen Arbeit ab) ein verärgerter ~~~~

Hi @FunkelFeuer,

danke, dass du das Feature testest und für deine Meldung hier. Es wäre super, wenn du uns einen Screenshot zukommen lassen könntest, damit wir sehen welchen Text du genau meinst.

Von deiner Beschreibung her vermute ich, dass du dich auf "Der Artikel „...“ existiert in der deutschsprachigen Wikipedia nicht. Du kannst den Artikel erstellen (Quelltext-Editor, Anleitung)." beziehst.

Falls ja: Dieser Text wird nicht von der AdvancedSearch Erweiterung gesetzt und erscheint auch ohne das neue Feature. Konkret stammt er in aus https://de.wikipedia.org/wiki/MediaWiki:Searchmenu-new. Dort kann man auch in der Versionsgeschichte nachvollziehen, wie der Text zustande kam.

Falls nein, wäre es wie gesagt super, wenn du uns noch etwas mehr Informationen darüber geben könntest, was dich stört.

Danke nochmal und viele Grüße,

Christoph

Hello. As Birgit asked, I'd like to explain, why do I think that the "local" keyword should be in advanced search before any other one that is not there yet. The "local:" keyword removes from the search all the results that come from Commons files description pages. We are an army of users, about a dozen, that usually fix tech errors on our wiki, before writing articles. Any search for some error should give the results on our wiki only, not the Commons one, so we can fix them. For example, the "source" deprecated tag searchs: usual vs. relevant. Other users need that too, when they search something in the wiki. But the cirrus search in other namespaces, not just articles, is usually something that done by registered users, not anonyme readers. So I believe that a little checkbox "search on this wiki only", which adds "local:" at the search string beginning (somehow, it does not work anywhere else), will be extremelly helpful. Thank you very much.

What if that were represented as a separate namespace tag: "File from Commons" ?

Do you mean in regular cirrus search or in advanced search, TheDJ?

In advanced search.

This can work. A little less comfortable - two clicks vs. one, but if it's the only option. But I do not understand. With the checkbox you have two elements with one-to-one translation to the search string. Here you should create the string with many conditionals. I'm not sure it's better for the developers. The only reason I can see is very expensive change of the interface.

Hi IKhitron, thanks for pointing us to the local keyword. Do I understand the issue right that in order to find things to fix you search for specific tags or categories, but the same tags/categories sometimes also exist on Commons and that is why you get results you are not interested in?

Hello. It's not just tags or categories, it's anything. You can search a plain text with typo, and get redundant results from Commons.

السلام عليكم ،انا محمد خلوق من المغرب،إستجابة لطلب 'الاخبار'او 'الرد'عن ملاحظة عن الصفحو ،بصراحة انا شخصيا اجهل هذا الوصف فمن فضلك ضع يدى على الصفحة المنافسة او السابقة حتى استطيع اميز الفوارق والمميزات.سلام.

A follow-up to my previous question: How should the "Syntax-equivalent" examples be translated?

I'm talking about the strings that appear toward the end in messages such as these:

• https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=advancedsearch-help-or&group=ext-advancedsearch&language=he&filter=&optional=1&action=translate
• https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=advancedsearch-help-phrase&group=ext-advancedsearch&language=he&filter=&optional=1&action=translate
• https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=advancedsearch-help-plain&group=ext-advancedsearch&language=he&filter=&optional=1&action=translate

It makes general sense to me to translate them rather than leave them in English, but it would be nice to get some explicit guidelines about this in qqq or on Extension:AdvancedSearch.

Hello User:Amire80,

thanks for translating! It's very appreciated.

The purpose of these info boxes is to give more background on how the search fields operate. By learning which parameters are behind the fields, people can make advanced searches, even without the Advanced Search interface.

So "Syntax-equivalent in the normal search" means: "How can you search for this without the Advanced Search interface?".

For example, instead of typing It's a little bit funny into the Advanced Search field "Exactly this text", you write "It's a little bit funny" (in quotation marks) in the regular search field and get the same result.

I hope this was understandable.

Have a good day!

Johanna

@Amire80 Hello again,

reading through your question again, I think I may have misunderstood your request. What you meant was whether the examples in strings like this one

Words with <code>OR</code> in between them like <code>Laptop OR Notebook</code>.

are supposed to be translated, right?

If that's what you meant, the answer is: Yes, you're right, it makes sense to translate this. We will add guidelines in the qqq hints. I created a ticket for this: T182988 Feel free to comment.

Thanks again for the hint!

Johanna

Well, yes; I'm sure that they words "Words with" and "in between them like" are supposed to be translated.

But the bigger questions are:

1. Should "OR" be translated? I guess that it should stay in English. In any case, this must be documented in qqq.
2. Should "Laptop" and "Notebook" be translated? I guess that they can be, but this should be documented as well.

Thanks!

@Amire80 Good morning!

Aha, okay, I got it now. :) Indeed, OR, intitle: etc. must not be translated.

On Phabricator https://phabricator.wikimedia.org/T182988, you can find the new hints that clearly say which parts are supposed to be translated and which ones aren't. Our developers will add them to TranslateWiki soon.

Have a good day!

Johanna

Nobody cares but me.

What it says on the tin. The feature is generally useful, and there's no reason our third parties should have to suffer with an atrociously bad advanced search.

(and no, making it a bundled extension isn't the same :))

I think it’s generally good to keep core as small as possible – it may be useful for most wikis, but not for all (e.g. I won’t ever need it in my personal wiki as it doesn’t have more than a dozen pages). If there’s less code in core, it makes maintenance easier.

If you only have 12 pages, I'm not sure the advanced search page is all that useful to begin with 🙃

But really, while keeping core small is a laudable goal, it's far from the reality. There's tons of things that have no business being in core MediaWiki but are--most of the special page reports, Atom/RSS feed generation both come to mind immediately. Whereas a search page is indeed a core feature to MediaWiki. The search page has long been in need of a revamp (indeed, it was on my todo list when I started the Cirrus project, but never got around to it), and this is a huge step in the right direction.

The advanced search is not useful at all, so why would I want to waste hard drive space and memory/processor time for it?

I don’t think the advanced search page is more fundamental than the Atom/RSS feed, so both should be kept out of core. But I’m not in charge of this, so not I will make a decision.

I think the hard drive space should be super low on your priority list, considering the whole extension is only 692K on disk (that's counting the .git directory plus all the other extension scaffolding that wouldn't be in core at all). The processor time and memory consumption are also negligible as well.....you're micro-optimizing here to the extreme.

Search is pretty dang fundamental for software containing mostly text. If you already don't need/use the existing advanced search, I don't see how a slightly nicer looking namespace selection form would inconvenience you (which actually makes your concerns about memory and processor usage even less relevant).

This extension depends on Extension:CirrusSearch, which is not part of core. I don't see what's the point of having a core feature that needs an extension to make it work...

The namespace selection could be in core, if we had a hook for extension(s) such as Cirrus to add their own advanced search fields beyond that.

Why is this extension’s namespace selection better? The old one is much more convenient for me – I can see all namespaces at a glance (in Advanced mode) and it’s faster (and more keyboard-friendly) clicking (or pressing spacebar/enter) on the checkboxes than selecting the namespaces one-by-one from a dropdown list. (The easy access to the advanced features of CirrusSearch is great, of course, but it’s not useful in core.)

Is easier to just start typing the namespace(s) and let it autocomplete rather than tabbing through 40 checkboxes.

By default, a wiki has 16 namespaces, and I’m sure that most MediaWiki wikis have no, or just a few, more than that. At that amount, it can be overviewed easily, and one doesn’t have to tab through 40 checkboxes. (N.B. I have turned AdvancedSearch off, as it doesn’t take my search namespace preferences into account, and searches only the main namespace unless I change it for each and every search.)

Tracked in Phabricator
Task T181329 Resolved

Hello!

I'd like to ask that is it possible to enable this great gadget sooner as you planned on Hungarian Wikipedia? I've read the schedule, however it doesn't say that when the other wikis will get it. Today, I translated almost every texts, so I think it would be possible to we can test it as a beta feature. I’m sure it would be very helpful and the community would appreciate it.

Best regards! 

Hi @Bencemac, thanks for the nice feedback & the translations :-)

It is definitely possible to get the feature earlier: For this, it would be great if you could ask the Hungarian community on your village pump if they would like to test the feature in this early stage (doesn't have to be a big thing, just a confirmation that a bunch of people think this is a good idea) and file a site request ticket, like the Arabic Wikipedia community has done it here. If you file the ticket by mid of next week, we can deploy one week later. It might get difficult for this year if we receive the site request ticket much later, as the official Wikimedia deployment break starts on December 18 and everyone will want to do last deployments in the week of December 11.

About the roadmap: We usually offer beta features to a small number of wikis first, as there might be more bugs in an early stage. Once we're sure that we have found and addressed the most crucial bugs, a larger number of wikis/all wikis can get & test it as a beta feature, probably from February 2018 on.

Again, thanks for your interest :-) This means a lot to us.

Best, Birgit

I'm working on it, thanks your answer!

Hi @Bencemac, thanks for taking care of this! :-) The planned deployment date for huWiki is now Dec 6! Will update the ticket on Phabricator as well. Best, Birgit

It has arrived. Thank you! :)