I'd argue that this is not as useful in Wiktionary as it is in Wikipedia. No one has explained why this feature should be adopted in Wiktionaries. Wiktionary is just a dictionary and we search by the title. Now the implementation of this feature is happening tomorrow 28th November and no one has explained how the feature helps (is of use) in Wiktionaries.
Help talk:Extension:AdvancedSearch
Jump to navigation
Jump to search
No one has given feedback in 12 months on why it wouldn't be useful..
Translated: Communities have responsibilities as well....
Hi Hartz, thank you for your feedback. It is possible that this feature will be less useful in Wiktionary than in Wikipedia, but we still think that it will be useful to some Wiktionary users. You can still do everything you did with the old search interface with the new one and if you dislike the new interface you will be able to disable it in your user settings. If you think that Wiktionaries would need different search options, we’d be interested to hear your suggestions. We did not yet got much feedback from Wiktionaries.
The new Extension:AdvancedSearch interface did find for me existing string in '''no''' way. I knew, that that string really exists, because I '''did''' write it. Please, return the older system, which wasn't lying about existence/nonexistence of concrete string.
If some improvement for Wictionaries, so create better ability to find special letters (with unusual diacritics) as e.g. ệ OR ử OR ů; or for korean ability e. g. find part ㅈ in sylable 존 or in whole word 존재.
Hello Kusurija, we did not change anything on the functionality of the search but only reworked the search interface. The development of the search engine is done by the discovery team at the Wikimedia Foundation. If a search that previously worked now does not work anymore you might want to report this to them.
How do you specify case sensitive search? for example only capital letters XYZ not lower case occurrences.
There currently is no way to truly do so, the closest thing is using regex, see Help:CirrusSearch . Unfortunately, the "insource" parameter doesn't detect text in a page added by a template.
See Topic:Upd6fer91868umd4 .
Why there is no option to create a new page with the entered search string?
There should be a link to create a new page just as with the old search – can you maybe provide us with a screenshot?
I can't reproduce yet but I opened a ticket (phab:T207320) and we'll take a look at it.
Hi, The new search is nice, but there is button to create a new item (on Wikidata) with the searched value. It is really needed.
Hi, Thanks for the feedback. Can you post a screenshot? There should be a link to create a new item/new page just as with the old search.
Yes. https://imgur.com/a/CXJmXal (just hope Imgur is alright here) :)
Thanks! I can't reproduce yet but I opened a ticket (phab:T207320) and we'll take a look at it.
Hey, we looked into it an think that this is not a bug in Advanced Search but an issue of Wikidata and that it can be fixed by wikidata-admins. The the ticket for more information. Please report back to us if you think it's not limited to Wikidata. Thanks!
OK. it seems to be fixed now. Thanks a lot !
Since this is an advanced search, having a full list of sister projects (a really completely full list here without any room for leaving them out) would be really helpful, I believe. The same with other languages in the case they are defined i.e. ru.wikipedia.org (Russian) and en.wikipedia.org (English).
Perhaps these things are not defined at mediawiki.org the same way they are at Wikipedia. But then at mediawiki.org there is a content translation effort of some sort. Exposing a language selector for that could be useful...?
Thank you for this input. A language selector can be already found in Wikis that have content translation enabled, like mediawiki.org. Is that what you wanted?
I'm not sure I understand what you mean with "having a full list of sister projects/languages". What should this list do?
Nice feature but you lose the information that had a reference to it.
Hi, thanks for the feedback. Can you give an example?
The AvancedSearch is very helpful, ilike it , it's very good.
thx
This is a long standing problem, in that we don't keep dates of content within a single wikitext page, only of the 'cumulative' content for each and every page.
It's a VERY hard problem to solve, but it definitely is on the radar.
So filter for entire pages. That's better than nothing, isn't it?
This post was hidden by 108.48.171.156 (history)
That a search of pages archives produces a completely random-in-time results is terrible and a tremendous time suck on experienced editors, and makes community governance work (which involves finding and citing old discussions) way harder than it should be. Community governance work is already hard, and this makes it such a time suck that I often don't bother going and finding things that I really should do. Coders are clearly ignorant of how community governance actually works, and dismiss this as a "power user" problem and keep shoving it down on the priority list.
The wishlist is starting today. I suggest you focus your energy on writing a good summary on why this is one of the few things in the swamp of user requests that should be prioritised for next year.
There is no datefilter, but there is a newly added ability to sort search results by certain parameters like last edit, e.g. https://www.mediawiki.org/w/index.php?search=foo&title=Special%3ASearch&go=Go&sort=last_edit_asc .
Considering that the creation date is also being indexed now. One possibility may be a range filter, e.g. find pages, edited between created date and last_edited_date, e.g. "editedrange:2003-02-01|2005-03-03"
The fact of the matter is that users could have always added this anyway. It just amounts to laziness and ignorance, e.g. there could be dirty way of adding this create a bot that adds ALL revision dates within the markup of the page. For archives it would be immediately be available, even the crappy internal default mediawiki search engine supports this.
@197.218.80.153 rly ? Is it so new that it isn't even documented on Help:CirrusSearch ?
Indeed, it seems to be a deliberately hidden switch perhaps until a GUI is created for it, but the API equivalent is well documented, API:Search.
I guess that resolves a previous wishlist item, https://phabricator.wikimedia.org/T18237, https://phabricator.wikimedia.org/T195071.
Option for saving the advanced search parameters would be very helpful for me. On Wikidata I always have to copy-paste "scientific_article scientific_journal gene protein enzyme reaction process pathway transfer InterPro catalysis abstract publication report" from a user subpage to "not this word" in order to get some decent search results. It's already a huge improvement when it comes to searching in Wikidata (before AdvancedSearch I usually spent several minutes trying to find something in Wikidata), but this one thing with copy-pasting is just a bit annoying ;)
This phab ticket added by IP-user is not related to this problem. I don't want to save certain search results, as I search for dozens or even hundreds different words a day and everytime I have to copy-paste the same text to "not this word" field.
Hi, having a possibility to save search-options is on the list of possible future features but unlikely to happen in the first version. See also the comment from Niharika. We are currently thinking about adding hooks, so that it's possible to enhance Advanced Search with user-written gadgets. That could probably allow some wikidata-users to write a gadget to add an option to exclude listed things to the interface. Would that solve your issue as well?
Any option that allows to prefill some of the search parameters would be helpful ;) Thanks
Just chiming in to say that losing my search parameters every time I search is an issue for me too.
>This phab ticket added by IP-user is not related to this problem. I don't want to save certain search results, as I search for dozens or even hundreds different words a day and everytime I have to copy-paste the same text to "not this word" field.
Technically speaking, it doesn't really matter. The linked task was accurate, all users want here is to save the state of a search, whether that state includes X words or Y keywords is irrelevant. To put it another way, advanced search simply adds a way to run search filters without cluttering the search box, the difference is between saving "abc incategory:boo" and "incategory:loo". Both can currently be accomplished using bookmarks, either clientside using the browser, or saved queries on the server.
The only functional difference is that there will be some search results at the bottom when the keywords are loaded. Currently, it seems to possible to avoid seeing the search results by bookmarking a url like:
Special:Search&advancedSearch-current=%7B%22options%22%3A%7B%22not%22%3A%5B%22caca%22%5D%7D%2C%22namespaces%22%3A%5B12%2C116%2C498%2C0%5D%7D&ns12=1&ns116=1&ns498=1&ns0=1
The "pure" (without extensions) Mediawiki itself, only allows doing this for namespaces, e.g. Special:Search&profile=advanced&ns10=1, since it has no notion of search keywords introduced by cirrussearch.
It seems to be a limitation of both tools, cirrussearch and mediawiki should possess the ability to filter results using the API or url tokens without fiddling with the search string.
