I work for or provide services to the Wikimedia Foundation, and this is the account I try to use for edits or statements I make in that role. However, the Foundation does not vet all my activity, so edits, statements, or other contributions made by this account may not reflect the views of the Foundation. For my personal account, see @Deskbanana.
Sun, May 21
Searching in subcategories is very likely to expose strange and unintended results to users due to the counterintuitive structure of categories. I gave a more detailed explanation of why this is in T160234#3117759. It's worth spending some time thinking about whether investigating technical solutions is worth it, given that the results from such a search may be polluted with irrelevant results.
Sat, May 20
In the end, the temporary solution was good enough, so this is resolved.
Fri, May 19
Search does support sending these kinds of special queries over the API. The reason this isn't working right now is because when you do a search, the query is being sent to both the local wiki and Commons, which undoes the effect of the local keyword. To make this work the underlying architecture would have to be rethought, I suspect.
Fri, May 12
@Alireza1357 Discovery is not working on this and currently has no plans to.
Thu, May 11
@EBernhardson @Jdrewniak Can you two take a look at this? Although Discovery does not support the core search functionality without CirrusSearch, if we broke something inadvertently then we should fix it. :-)
Breaking it down by type does seem handy. What does @TJones think?
Wed, May 10
This does have a side-effect of making such pages not show up if you do a query for insource:hatnote since the data has been removed from the search index. This behaviour would not be expected.
Tue, May 9
This bug is partially fixed. Due to the security fix above, the text is now parsed on client wikis. One can see that this is not what we decided to do above, but it was necessary as part of the security fixes.
Mon, May 8
Here are my thoughts. As I noted previously on the Discovery mailing list, the Interactive Team is currently putting its work on pause. This means that, if this were deployed, it is very unlikely that any feature requests would be answered. You can only expect a very minimal level of support on bugs or other issues. If you are alright with this, I don't object to the deployment going ahead to WMUA wiki.
It's generally considered good practice to ask the maintainers of products and services whether enabling them will cause any issues, such as server load, capacity, product inconsistencies, and so on. Let's not have a repeat of T161032 where something was enabled without the maintainers knowing until afterwards. :-)
Fri, May 5
We have decided not to continue work on this for now. There's a lot of open questions, and it's very unclear from where we stand right now how much work this would be. It's quite possible that we'd open a can of worms trying to do this due to the complexity and it'd turn into a time sink. The user value is still clear, but it seems it's not in line with the expected effort to implement it.
Thu, May 4
This remains a valid issue, but has not been touched in a while. Changing priority accordingly.
You can use the local keyword to do this, so this is resolved.
This task talks about adding indexing of content of djvu and pdf files, which, according to @EBernhardson, is now done for those file types. Accordingly, this is resolved. For more complex metadata, waiting for Structured Data on Commons as @debt suggests is the best course of action.
@dcausse How do you suggest we begin to tackle this?
Tue, May 2
@dpatrick Thanks so much!
What is outstanding here? The task that depends on this fix is fairly urgent. :-)
Apr 20 2017
Is this still an issue?
This isn't high priority given our other work right now.
I can no longer reproduce this problem, so I guess it was fixed at some point. Yay!
This seems stalled. Is there anyone in Ops or Discovery that can review this?
This makes it hard to look at log files since there are tens of thousands of files in the relevant folders. This doesn't seem super pressing, but is worth a quick look some time.
This will be useful if we wanted to, say, boost articles that were once featured articles.
The creation of this plan is in progress.
This seems to have been completed.
Adding to our sprint to check this out.
The message that suggests creating an article that doesn't exist is not shown if your search contained special syntax. This is to avoid nonsensical suggestions like You may create the page "insource:foo". Quotes are actually special syntax; if you put something in quotes, it will only show exact matches.