Commons talk:Structured data/Media search/Archive 1

Sorting order

My first impression was very good.

But I have some questions and suggestions: What is the criteria for the sorting order? And then there should be the ability to choose the sorting order, some useful criteria could be creation date, upload date, resolution, quality assessment(QI,VI,FI).

And searching for multiple items/words would be obviously be great. --GPSLeo (talk) 18:51, 28 May 2020 (UTC)[reply]

I honestly can't tell you what the sorting order was at the time when you looked at it because it may have changed by now. The team is trying out various methods and seeing what the data returns while listening to hear about what you expect. What would you anticipate the sort order to be? Keegan (WMF) (talk) 19:32, 4 June 2020 (UTC)[reply]

I think the most common sortings would be "most viewed" and "newest". And I think most external users will expect such a sorting. Maybe creating a kind of score based on usage in wikis, quality assessment, page views and some other parameters, like resolution, would be the best. --GPSLeo (talk) 20:18, 4 June 2020 (UTC)[reply]

Searching on multiple terms

I just searched on "tapestry annunciation" and was delighted with the usefulness of the search results. I will probably use this ona regular basis even in its prototype form. - PKM (talk) 21:57, 28 May 2020 (UTC)[reply]

First impressions

I tried a few terms in the new search and in the regular search, Many results were similar, some were bettter and some worse:

tried term "bouldering" (without quotes) which is type of climbing and media search returned 1,5, rows of bouldering followed by great many unrelated images of just boulders. Old search returned mostly boulders. Both searches did much better with the quotes
I tried "Morone" scientific name for some type of fish: there were no fish in the first screen of media search, and there were plenty of fish at top of old search results
I tried "bring on the nubiles" name of a climb and both searches returned similar results with images of the climb. Strangely new search returned 6 images: 2 copies of 3 images.

--Jarekt (talk) 02:11, 29 May 2020 (UTC)[reply]

Thanks. It's worth noting that as a prototype/proof-of-concept, not all data is loaded in and the sorting order and ranking hasn't been determined. You might find a different experience with these terms next time you use the tool. Keegan (WMF) (talk) 19:34, 4 June 2020 (UTC)[reply]

Be sensitive to file types

I searched "femur svg". The search returned results that showed me a png of a femur bone. If I do the same search on the old WikiCommons search I get an image of an svg as the first result. This is especially problematic as the file name doesn't get shown and only the images get shown. ChristianKl (talk) 10:53, 29 May 2020 (UTC)[reply]

A filter (similar to Media size on the right) would be a nice user experience for that. Syced (talk) 06:55, 1 June 2020 (UTC)[reply]

Show description text

While I'm no heavy user of WikiCommons I would be surprised if the text information in the existing search isn't important to some users. Espeically those users who care about improving the descriptions of existing files on Commons likely need. Maybe there should be an option next to media size that allows switching from gallery view to listview with listview providing more information. ChristianKl (talk) 10:53, 29 May 2020 (UTC)[reply]

I agree. Displaying images only is nice, but not helpful to know what images are about. Ayack (talk) 13:52, 29 May 2020 (UTC)

I very strongly endorse this suggestion. I also want to see some metadata about each result I get, and that would serve several purposes:

Show me why I see this result. When I search for 'Gerrit Rietveld', do I get a file in the result list because it (has the structured data indicating that it) depicts Gerrit Rietveld? Because it shows a building or piece of furniture (described in a Wikidata item that states it is) designed by Gerrit Rietveld? Because the file somewhere in its description has the words Gerrit and Rietveld? If the results I get are not exactly what I'm looking for, this kind of information will help me to adjust my search strategy. As a bonus: seconding ChristianKl's comment: as a Wikimedia Commons editor I may see erroneous data and fix it!
Of course, simply, to provide more information about the file. In my corner of the Wikiverse: especially GLAM files often come with juicy, refined metadata that the GLAMs themselves will appreciate being visible, and that will serve users who are looking for quite specific information.
I would definitely include image size and license to indicate usefulness for re-use. The 2018 external re-users of Wikimedia Commons research indicates that this is something people are looking for. It would also be one of the first things for me to check when, for instance, searching for an image to use in social media, or for use in a presentation slideshow.

I can imagine that this information could also be made visible on hover in gallery view in order not to clutter it; a bit like the packed-hover behavior of the MediaWiki gallery functionality. But I expect that some users will also indeed want to see all metadata in a search result list at one glance, like ChristianKl indicates, and that may be better served with a switch to a list view. Spinster (talk) 07:34, 1 June 2020 (UTC)[reply]

Tabular data and Map(Geoshape)

While WikiCommons is mostly Images/Audio/Video it also supports tabular data and geoshapes (.map files). There should likely be a "others" section for those (and maybe some data types I don't know about). ChristianKl (talk) 10:53, 29 May 2020 (UTC)[reply]

Yes, I was going to write that but I couldn't grasp in my memory this example.--Alexmar983 (talk) 23:42, 29 May 2020 (UTC)[reply]

Display results on a map

What could be really great, is an option to display all geotagged results on a map. Ayack (talk) 13:46, 29 May 2020 (UTC)

This functionality is largely there. It is the mirror image of what Magnus does looking for new photos. Thanks, GerardM (talk) 10:40, 2 June 2020 (UTC)[reply]

Language support is key, all the rest follows from there

What this prototype brings us is support for searching of Commons in any language. It is what gives both Commons and Wikidata a purpose; it will be the tool to invigorate the Wikimedia movement as a global, a multilingual movement.

I am really happy that its localisation in Hebrew is complete, the Media Search works in a bidirectional way
I added a label for a Pakistani scientist in Urdu (thank you en.wp) and as a result many pictures became available.
I found pictures on Wikipedia for recipients of a science award, no article, no item, it became easy to add an item, a recipient and link a picture.

Move forward

We should have this search option available on any project that wants it. It will stimulate the use of other pictures particularly on the smaller Wikipedias. This will stimulate a sense of identify; what they have is not necessarily what everybody has.

descriptions

Descriptions for every language will not happen. This is abundantly clear from the Wikidata experience, many English descriptions are hardly descriptive. What has been available are "automated descriptions" they are based on available labels in Wikidata and can be made to be meaningful (first) in any language. Making them linguistically correct is a next level challenge.

Descriptions are vitally important to combat false friends and find synonyms.

Also known as

When you search, you want to know what synonyms are available in that language. It helps with disambiguation.

Is an image "wikidatified"

It is really helpful when an icon indicated that an image / media file has been wikidatified.

None Wikidata based search

The existing functionality of categories et al is really important as a tool to make Commons useful in other languages. When a search is done with a label that does not exist in the "search" language, it is important to show what language the label is in. It is helpful when a label in the "search" language can be added.

Caption showing before image has loaded looks like it belongs to the image above it

When still loading images, you might get the caption as a sort of alt text before the image shows up, if this doesn't happen immediately. However, the text looks like it's captioning the already visible ~~text~~ image above. /Julle (talk) 14:25, 30 May 2020 (UTC)[reply]

Useless

As for now, I don't see, how we can benefit from this feature. It gives you when not related results. E.g. you search for a specific person and you get his images, images of his work, and other images about which you don't know, how they are related. If you search for a random term like a blue gate you get some images of gates of the blue color but also many other images where is nothing blue. --Juandev (talk) 15:43, 30 May 2020 (UTC)[reply]

So this feature looks like to bring a new attractive look, but not a powerful search. It mixes up SD with full-text search an does not use the rich layer of information, we have on WMC to provide powerful search options. I wonder if someone wants to find files of "Václav Aulický" (person, architect) he/she wants to get images of that person and potentially in a different segment of the result page (or as an opt-in function) his works. If someone types in "Vojníkov" they expect photographs of that village, not an old manuscript which mentions that village or detail of agriculture machinery taken in that village. And lastly, people would expect the search results to be the same in all languages, but they are not "modré vrata" in Czech are equal to "blue gate" in English but results are different in each language.

So I say yes to the image display, lets elaborate this a provide more attractive image set displays and ways to work with images, but no to such search results. We would benefit more from a multilingual search using SD and being as simple as this is (as many people don't understand or want to study SQL to mine via queries). --Juandev (talk) 15:55, 30 May 2020 (UTC)[reply]

You speak English and consequently for me your are not the primary user for this search. This is a prototype, a proof of concept. It has its base all of 61,801,753 pictures where you will not find what you are looking for even in English. The quality of the search is awesome and awful depending on how you look on it. I added a label in Urdu and was able to find some 20 pictures of a Pakistani scientist. THAT is what it is about; opening up Commons in any and all languages.

Attractive is the least of our problems. Our problem is that Commons as a resource is as closed as you can make it and still be open content. This is about opening up Commons, make its content findable. Give it a purpose beyond our own.

At this time it is not about SPARQL or SQL it is about pictures and identifing them for what they depict. Then find them in any language. Thanks, GerardM (talk) 20:57, 30 May 2020 (UTC)[reply]

Thank you very much for the explanation. Maybe this should be mentioned on the feature page also. --Juandev (talk) 21:46, 30 May 2020 (UTC)[reply]

I like it

It looks like a good step forward! Tested looking for "telescopio lovell" and "洛弗尔望远镜", and it performs much better than the standard search engine. For some reason, it does return different results when searching in different languages though, it's not clear why. The thing I don't like is that it splits up the results into 'Image', 'Audio', 'Video' and 'Categories' - it would be better to return all of these at the same time, or at least turn off the tabs when they don't return results. Ideally I'd like to see categories highlighted at the top of the results, but I may be a little biased there. Thanks. Mike Peel (talk) 16:49, 30 May 2020 (UTC)[reply]

My problem with Commons categories is that they are English, the only multilanguage purpose for them is to find more pictures to tag. I do not see a reason to show them except for the reason that they are part of our legacy.

I would want one other grouping; the images used on projects for that subject.. ie all pictures used on any Wikipedia article in all its languages.. with an option to look for alternatives

Yet another grouping would be all the internal and external sources where you can find information on a subject.. A little like what is done on Reasonator for authorities, websites, Wikiprojects and obviously Scholia. Thanks, GerardM (talk) 20:45, 30 May 2020 (UTC)[reply]

@GerardM: Only the title and filenames are English, {{Wikidata Infobox}} is fully multilingual. Thanks. Mike Peel (talk) 21:01, 30 May 2020 (UTC)[reply]

@Mike Peel: you do not search for an infobox. You look for titles and filenames.. Infoboxes are out of scope. Thanks, GerardM (talk) 21:16, 30 May 2020 (UTC)[reply]

@GerardM: The infobox adds metadata that aids search. Mike Peel (talk) 21:17, 30 May 2020 (UTC)[reply]

@Mike Peel: Yes, and we need it, will use it but it is not what is needed at this stage for opening up Commons in multiple languages. GerardM (talk) 04:05, 31 May 2020 (UTC)[reply]

Searching and filtering

I've tried 4 ways of searching for "kočka" in the Czech language, which translates as "cat":

Fulltext search: brings a lot of "crap" as there is a user name "kocka"
Media search without selecting from the list: seems to bring less related images than in the case of 1st way
Media search chosing "Kočka domácí": almost no no related images
Google search "kočka site:commons.wikimedia.org": which on the first lines looks almost as method 3 (how they do it?), but than slowly deteriorates

So now I can understand that for non-English speakers this is the step forward. I wonder how to provide results of 3, when somebody type just "kocka"! Maybe some context help like Did you mean Kočka domácí? Or at least metioning that in the guideline, that searching via offered strings gives better results. But for some keywords this is still not enough and only SD statements can fix the problem.

On the other hand I see the problem, when something is called the way of my string. If I search for "vrata" in Czech I want the gates. But the search result provide also a rock formation called "vrata". Not sure how we can filter this out, maybe just searching in the values of SD statements.

The filter Media size looks to be more usefull for off wiki users than for Wikipedia contributors. Maybe it would be a good idea to write down what is small, medium and large format in pixels and than the notification "Showing small photographs of cats", because in such huge amount of images on the same topic, the filter does not look like a filter but a new search.

And if we have one filter it would be greate to provide more filters. I wonder there might be tons of filters so maybe 5 visible and other opt in: location, material, color, type (photograph, * in art).

It might be also interesting to provide search for more keywords and operators (+ -, etc.). Lets say I need an image where somebody is typing on a keyboard, but we dont have such Wikidata item. So I would combine two items using the operator + (e.g. keyboard + typing or keyboard + hand). Or as I mentioned above the problem with the rock formation called the gate, I may search for gates and remove the rock formation (vrata - skalní formace).

Other nice options would cover the images themselves, so the ways of display: in the map how somebody expresed above, on a time scale (for certain objects we have photographs from different phase of that object - like building a new house), etc. --Juandev (talk) 22:23, 30 May 2020 (UTC)[reply]

Your example is the perfect example why search is awful. Not finding cats... In Dutch "mus" means sparrow. Wikipedia understand it as "huismus", so you can link pictures of "sparrow" (Passer domesticus) add this using the depicts statement and you WILL find less mice and more sparrows. It works and it will help people find "mussen" in other languages as well. It will take five years and it will still be "improving" but hey it is a Wiki and it is allowed to take time. Thanks, GerardM (talk) 04:41, 31 May 2020 (UTC)[reply]

Quotation marks

It is a fact that the results are much more impressive if you use "Echinodermata" instead of Echinodermata.

Still worried that the taxa chain is not yet followed.
I like the media size filter, though maybe the arbitrary values (for Small", "Medium" and "Large") could be specified inside brackets. Or why not directy the values insteads, and why not a more bigger choice of values?
I like the overall presentation
I like the tabs, specially the one "Categories"
I would like an "easy" way to exclude some values (or why not to add) and I would like to be able to cumulate severals exclusions e.g. "Echinodermata" excluded "Asteroidea" excluded "NMNH",...ect..

Christian Ferrer ^(talk) 08:42, 31 May 2020 (UTC)[reply]

Please show thumbnails and descriptions in autosuggest

First, please let me say that allowing non-English speakers to search Commons is wonderful.

When searching for "bow" in the prototype, I can not choose whether I want a bow (Q301897) or a bow (Q46311) (ship bow or archery bow).

It would be great if a thumbnail (P18) and localized description were shown for each suggestion, like the Commons app does already.

Looking forward to better searching, thanks for doing this! :-) Syced (talk) 00:20, 29 May 2020 (UTC)[reply]

Not sure about thumbnails, but descriptions definitively! Ayack (talk) 13:54, 29 May 2020 (UTC)

Most Wikidata items do not have a description in Mandarin or Hindi. Thumbnails really help people using such languages. Images are more universal than words :-) Syced (talk) 08:38, 31 May 2020 (UTC)[reply]

+1 on descriptions and thumbnails. I've always liked this thumbnails suggestion, I think it's really powerful. And showing descriptions not only gives more context to everyone; it also helps Wikidata editors discover which items still need descriptions (or better ones). I frequently improve Wikidata descriptions whenever I encounter lacking or suboptimal ones in various places. Spinster (talk) 07:04, 1 June 2020 (UTC)[reply]

Please include subclasses too

When I search for vehicle (Q42889), I should see images that depicts (P180) all types of vehicles, for instance train (Q870), bus (Q5638), etc. Instead, the only train/bus images displayed as results are images that have lazily been classified as depictions of vehicle (Q42889) rather the more specific train (Q870) or bus (Q5638). Ideally all "train" images should depict "train", not "vehicle". To sum up the current situation: only lazily classified images are shown. When a generous volunteer takes the courage to move all vehicles to more specific classes (which is the right thing to do), the search for vehicle (Q42889) will return empty.

Please fix this by including subclasses, recursively. While it may be technically difficult, it is essential from a user's point of view in order to not fall back in the problem of categories (having to search all sub-sub-xyz in order to find all images). It might require a whole new infrastructure on the Wikidata side to cache recursive lists of subclasses/etc.

Thanks! Syced (talk) 00:20, 29 May 2020 (UTC)[reply]

License information

It'll be also nice to display license information or make license filter similar to Media size. --EugeneZelenko (talk) 13:37, 29 May 2020 (UTC)[reply]

A filter similar to Media size would be great indeed! I sometimes look specifically for public-domain images. In the future another filter could be for the type of image, or to filter by quality assessment. Syced (talk) 04:35, 1 June 2020 (UTC)[reply]

Target audience?

Just wondering - who do the team consider to be the target audience for this search functionality? My anecdotal experience (confirmed by some findings from the 2018 Commons reusers research) tells me that most people who are unacquainted with Wikimedia Commons arrive here via Google or other search engines - and IMO there is absolutely nothing wrong with that. I think Google actually does a decent-ish job at surfacing Wikimedia Commons files (I'm not familiar with how other search engines expose our files) and I'm just curious whether the team is also looking into ways of making structured data of Commons files more discoverable by external search engines, in order to serve a 'general' audience?

That said, I personally hope this search functionality is intended for more experienced users - think the Commons community itself, and more advanced / expert re-users who know that Wikimedia Commons exists and want to dig in here to find very specific materials. And in this case, I think this new search paradigm is absolutely great, but it would benefit from some more advanced features - think (as mentioned above) some more metadata and context shown about each file, but also at some point options for faceted search and filtering. Spinster (talk) 08:03, 1 June 2020 (UTC)[reply]

Given that so far we have done nothing for people who do not speak English, it is fine to have a personal hope that "more experienced" users will benefit. I expect that many people thanks to the new functionality will finally experience Commons for what it has to offer. Thanks, GerardM (talk) 09:55, 1 June 2020 (UTC)[reply]

I could be wrong, but maybe editors of non-English Wikipedias looking for an image to illustrate an article? I think this tool has the potential make their image searches much easier :-) Syced (talk) 09:11, 1 June 2020 (UTC)[reply]

Of course! I totally agree with those use cases. My request is inspired by the observation that Wikimedia Commons contains a true treasure trove of 60 million files now; in fact most of them will never make it into a Wikipedia article or be selected by someone who searches for cool Zoom backgrounds with kittens, but so many of these 'long tail' files are actually really culturally valuable for various reasons beyond just 'depicting' a general topic or a subject written about on Wikipedia. These will still not be discoverable or useful for the world if we only have a search functionality that is designed for 'the general use case'. We should not oversimplify, and not be afraid of adding functionalities that help to make more of our treasure trove discoverable (including helping and even encouraging people to discover those parts that are about content gaps).

My comment is also inspired by a pattern that Pete Forsyth describes at the end of this article for the Wikipedia @ 20 publication reflecting on more recent software development for mobile Wikipedia. He points at a pattern of oversimplification in WMF software development, to the detriment of transparency, literacy about the workings behind our projects, community values and diversity. I share this concern, and have the very strong opinion that we shouldn't be afraid to show some levels of complexity when it serves the discoverability of our content. Spinster (talk) 17:08, 1 June 2020 (UTC)[reply]

I think the aim of this tool is not to give advanced searching and filtering. For that there will be a full SPARQL query service. --GPSLeo (talk) 21:26, 1 June 2020 (UTC)[reply]

I am the biggest fan of a SPARQL endpoint and can't wait till we have it. However, do we want to send people to a SPARQL endpoint who are searching for, for instance, something as rather straightforward as photos of Angela Merkel in her early political career in the 1990s (which is something that, say, my 14-year-old son may be looking for as part of a history assignment for school)? We have more than 3,000 images on Commons depicting Angela Merkel, and with its current design, Special:MediaSearch doesn't really allow you to sift through these 3,000+ results if you want something more specific than 'any photo of her'. I will add more examples and argumentation later. Spinster (talk) 22:42, 5 June 2020 (UTC)[reply]

The target audience is people using Commons. The idea is that Commons's internal media search should be able to return just as much, if not more, relevant media than having to rely on an external third-party search engine for your search workflow. This is the same principle that drives the wikitext search improvements using Extension:CirrusSearch, to better surface content for everyone in the place where you are. Keegan (WMF) (talk) 19:30, 4 June 2020 (UTC)[reply]

You seriously need to reconsider your target audience. Out target audience is everyone.. "All of @WikiCommons" is available to every single person on the planet" is what I wrote as the objective for Special:MediaSearch in my blog

It may be that you do not recognise it as such, but this is the most important language development since Wikidata took over interwiki links. Wikimedia is important for its multi lingual support and its aim is to share in the sum of all knowledge and consequently Commons needs to be available to every single person on the planet. We as a movement are heavily biased. All our software is first done in English, research does not get published when it is not about English Wikipedia. Special:MediaSearch needs to be available on every project. Like now, a search result needs to be available with the original search criteria but it should also be available with a language parameter that can be individually be set. Commons is best used in English but I want to search it in Dutch.

There are many special interests that want to high-jack multi lingual search for their purposes. As long as we can not reliably find cats in every language, special purposes need to take a back seat. Special purposes target only a small audience and while such audiences have been important to us they now stand in the way of what we defined as our mission.

I have said it before and I say it again. In Agile terminology this is a business decision. It is also a decision that determines who we are and what our priorities are. It is a decision that can only be taken at the highest level because they are responsible for determining who we are and what we stand for. Language matters. Thanks, GerardM (talk) 04:50, 5 June 2020 (UTC)[reply]

Resulting images may be bigger on desktop for me

Just a small comment, but I personally actually think that I would find it OK (and even useful) if the thumbnails in search results were even a bit larger in desktop view - think 1.5 times the size they currently are. As this is maybe not something for everyone, I can imagine this could also be adjustable in a setting somewhere at some point. Spinster (talk) 08:11, 1 June 2020 (UTC)[reply]

Facets and filters

I have always dreamt of faceted and filterable search for media files on Commons, and as more and more files get structured data now, that should become possible. I would definitely like to advocate for adding that functionality to this new search paradigm. IMO it would demonstrate some benefits of the structured approach compared to our very deep category nesting structures. See this Phabricator ticket I created some time ago; just reposting and expanding upon some thoughts I collected there:

Faceted search is a common design pattern on many websites, including prominent e-commerce ones, so it is certainly something the broad public is acquainted with.

The data model of Structured Data on Commons is flexible and under constant development - that's a given. Therefore, faceted search will also need to be flexible, i.e. not rely on fixed properties that will be present for every file, but rather preferably be responsive to the most-used properties that are present in a given set of search results.

A good source of inspiration is GraFa, a faceted browsing interface for Wikidata. With the example of the set of 'instance of sculpture' (i.e. all sculptures on Wikidata) as a starting point, this tool discovers that the most used properties are Creator, then Country, then Material used, etc. (Compared to GraFa: for improved usability it would probably be extra nice if each 'facet' would already list the most commonly used values for that property as well.) Spinster (talk) 08:27, 1 June 2020 (UTC)[reply]

For me the Grafana tool draws a blank. What is in it for me, I use Reasonator and it works in any lanugage, it provides me with automated descriptions when I need disambiguation and I may get a wealth of options in Grafana but it does not get through the first hurdle; usability.

At this stage the Special:MediaSearch is the first iteration where multi lingual support is offered. You may dream about things that may be theoretically well considered but all Grafana offers is support in two languages and that is not nearly good enough. GerardM (talk) 05:40, 2 June 2020 (UTC)[reply]

I am a long-time fan of GraFa as a prototype. The perfect search tool would combine Special:MediaSearch's multilingualism and GraFa's facets. :-) Syced (talk) 06:47, 2 June 2020 (UTC)[reply]

What is it that GraFa does? Why is it relevant at this time when we do not even have multi lingual search in order? Thanks, GerardM (talk) 11:22, 2 June 2020 (UTC)[reply]

"Why is it relevant when we do not even have multi lingual search in order?" <- Are you saying that we should ignore everything else until multilingual search works? Does it say so at Commons:Structured_data/Media_search? I agree with you that multilingual search is the most important, but my understanding is that the prototype is about more than that :-) Syced (talk) 01:31, 3 June 2020 (UTC)[reply]

Thanks for the feedback so far

I'm working limited hours this week so I haven't had much time to go through all the questions, comments, and concerns left for the prototype so far, but I'm very happy to see so much written already. Please keep the observations coming as you have them, and I'll continue to gradually bring attention to the prototype around Commons. I hope to get to reviewing this page later this week, and start getting responses as needed. Thanks again, your time is appreciated. Keegan (WMF) (talk) 18:20, 2 June 2020 (UTC)[reply]

Thanks! --Juandev (talk) 14:19, 4 June 2020 (UTC)[reply]

Feedback

It's great to see relevant images for different search queries. I tried common nouns like 'mountain', events, city names etc. The only little problem was the auto-complete being bit-slow. But considering the fact this is still under development, the delay is fine. The results under the categories section were better than those under 'audio', 'video'. John Samuel (talk) 09:22, 7 June 2020 (UTC)[reply]

Suggestions

Nice work so far. Here's my initial feedback...
Bugs:

Filter out all instance of (P31):scholarly article (Q13442814) from the auto-suggest. Otherwise most of the suggestions are useless junk.
Fix the FOUC (flash of unstyled content).
Image thumbnails are often broken (maybe an API timeout issue?).
It seems to give the same result set twice (e.g. [1]).

Feature requests:

Add a license filter similar to the size filter.
Add a date range selector (for inception).

Kaldari (talk) 20:04, 9 June 2020 (UTC)[reply]

+Images thumbnails are often broken. Same here. --Juandev (talk) 15:17, 11 June 2020 (UTC)[reply]

Yes, the dups should be avoided. Jura1 (talk) 05:51, 12 June 2020 (UTC)[reply]

Some further tests

Surprised to get nothing for 'Skræling', not even the images that appear in en:Skræling or the distinct one in da:Skræling.
'Færøerne' does well.
'Gander' gets what I could only call odd results, many of them about a courthouse in Albany where I can't even think what the connection woul be.
'bóveda': I never knew it was a placename. It is also the Spanish word for architectural vaulting, and I got none of that.

Jmabel ! talk 02:37, 10 June 2020 (UTC)[reply]

There is no reason to expect good results. When you test, the reason to test is to understand results. Understand the working of the existing functionality. Gander or ganzerik in Dutch is a male goose. It does not exist in Wikidata and consequently you get nothing different from text based search. When you add "gander" to Wikidata, you can add additional labels based on Wiktionary, you can add "depicts" and change your display.

I like your idea to have a separate display that shows what illustrates Wikipedia articles on a subject.

When a picture shows architectural vaulting what shows bóveda, you will want to link it to Wikidata as well.

What these further tests show is your interest, but when there is no link to Wikidata it will not improve the miserable results that are in text only based search. The search engine may improve but it is based on data and it will not get better than the data we have. It follows that adding labels in other languages and indicating what a picture depicts is what makes and will make the difference.

I have done some further testing for cats. I found cats in Farsi, in Dutch in other languages. Adding items to these pictures includes them in the Special:MediaSearch as can be expected. Thanks, GerardM (talk) 05:05, 10 June 2020 (UTC)[reply]

Setting the language for use with Special:MediaSearch

Hoi, the word "mosk" is "house sparrow" in Frysian. You will only find a "mosk" when in the preferences the language is changed to "fy". It would be really cool when you can use Special:MediaSearch in another language than specified in the preferences. Thanks, GerardM (talk) 14:27, 11 June 2020 (UTC)[reply]

+1--Juandev (talk) 15:18, 11 June 2020 (UTC)[reply]