Think about commons search by default for files?
Open, NormalPublic

Description

Right now if you search in the file namespace cirrus will automatically combine results from the local wiki with results from commons. Was a feature in lsearchd that had been broken/work sporadically for some time. Cirrus got it working consistently.

The trouble is that we're not super sure its a good idea. Its certainly useful in some situations and annoying in others. I don't have the time to enumerate both situations at this point, but its worth some thinking on exactly how we should use it.

Right now you can disable it using syntax like file:local:cat.

So, what should we do here?

Stakeholders: Wiki editors mostly - they are the ones that'll search in the file namespace. Mostly. Visual editor team cares about this too.
Benefits: New behavior should be less confusing.
Estimate: Can't estimate without a proposed solution.

Manybubbles updated the task description. (Show Details)
Manybubbles raised the priority of this task from to Needs Triage.
Manybubbles added a project: Discovery.
Manybubbles moved this task to Needs triage on the Discovery board.
Manybubbles added a subscriber: Manybubbles.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 20 2015, 1:38 AM
Manybubbles renamed this task from Commons search by default for files? to Think about commons search by default for files?.Apr 20 2015, 1:39 AM
Manybubbles triaged this task as Normal priority.
Manybubbles set Security to None.
Manybubbles added a subscriber: Deskana.

Adding a small checkbox to Special:Search would be fine, I think. Default should probably be decided per project.

Adding a small checkbox to Special:Search would be fine, I think. Default should probably be decided per project.

Wikimedia Commons is one foreign file repository, but MediaWiki can (and Wikimedia likely one day will) support multiple foreign file repositories. Any design should accommodate this, I think.

I'm trying to think of how other sites have solved this problem. Amazon has departments and has a drop-down menu to the left of the text search input, allowing to search a specific department or search all of Amazon. We might want something similar one day, allowing search on the local project (the English Wikipedia), on the local family (Wikipedias), on sister family projects (Wiktionaries, Wikimedia Commons, etc.), or across all public Wikimedia wikis. Whether this should be part of one search interface (Special:Search) or more than one is an open question. How we might reasonably accomplish complex use-cases (e.g., allowing users to search only two specific projects or only three specific project families) in a unified search interface is another big open question.

For files in particular, if the file isn't being used on the local wiki, does displaying it in file search results really make sense? I'm not sure we're matching user expectations here.

Deskana removed a subscriber: Deskana.Apr 21 2015, 4:42 AM

We might want something similar one day, allowing search on the local project (the English Wikipedia), on the local family (Wikipedias), on sister family projects (Wiktionaries, Wikimedia Commons, etc.), [...]

Interesting idea. We already have interwiki search but it's not really flexible. It'd be nice to have a search interface with possibilities to search by selecting the languages and projects across Wikimedia.

For files in particular, if the file isn't being used on the local wiki, does displaying it in file search results really make sense? I'm not sure we're matching user expectations here.

When contributors try to find an image for an article, they usually don't go to Commons and search for it. Instead, they just try to find a file by searching locally. So it's not completely pointless to have Commons files in search results.

Manybubbles moved this task from Needs triage to Search on the Discovery board.May 7 2015, 7:53 PM
Restricted Application added a subscriber: Steinsplitter. · View Herald TranscriptAug 18 2015, 3:11 AM
Legoktm updated the task description. (Show Details)Nov 6 2015, 7:41 AM