Page MenuHomePhabricator

A date range filter for MediaSearch for date the image/video was taken/recorded
Open, In Progress, LowPublicFeature

Description

Feature summary:

See Wish 221: Add a date range filter to Special:MediaSearch.

Please add a date-range filter for MediaSearch by which one can constrain files via metadata about date taken. (That metadata currently can be in structured data and/or the file's information template's date parameter and the file categories.)

This is quite similar to T329961 and it would be best to implement both functionalities in a combined way.

Use case(s):

One could also use this to see latest or earliest files for a certain timespan in a category (like all files taken since 2 months ago) using the deepcat search operator. (With the deepcat search operator one can see a neat wall of images to scroll through – example.)

One could also specify a certain time period of interest such as when one looks for files about a certain event or characteristic of a certain time period.

One could use this as a tool to aid categorization. See also this Commons discussion "There are many categories containing hundreds or thousands of files but no subcategories…"

Furthermore, one may look for images of a certain place during a specific time. With sorting only one may have to scroll for ages and manually inspect individual files to see which date it is, if it would work at all this way. Note that the current sorting is for date uploaded, not date taken (this info is added to the date field of the Information template when using the UploadWizard).

Benefits:

See above. The use-cases are beneficial to users who use the filter directly as well as for linkable dynamic feeds and the things contributed using these filters such as comprehensive subcategories about a certain event where files have been found using that filter.

Other info (expected challenges & ideas for solutions):

Maybe it could be implemented by enabling searching the Information template. It could also make use of chronological subcategories such as Category:NASA videos in 2025

Yes there are caveats and challenges to this such as files without date in the File information template (see also the idea to also use date-categories right above) – but this functionality would be very useful even if it's gappy and in some cases not working well. it may be best to show a warning at the top like 'Some relevant files may be excluded or falsely included when using the date-range filter'. One could also have options in the preferences and/or on the MediaSearch page when that filter is used such as for whether or not files with no date should be shown too and how files with broad dates like "1980s" (as if it was 1980-01-01? also included at the bottom when filtering 1985-1990?) should be included.

And see also T71417: Additional sort options for categories:: Usage (most/least used pages); Creation date (newest/oldest date of original image/video) and T393287: Add filter by date to the Special:ListFiles in Wikimedia Commons

Event Timeline

Change #1277504 had a related patch set uploaded (by Aude; author: Aude):

[mediawiki/extensions/WikibaseMediaInfo@master] Add mediainfo_capture_time search field

https://gerrit.wikimedia.org/r/1277504

Change #1277501 had a related patch set uploaded (by Aude; author: Aude):

[mediawiki/extensions/WikibaseCirrusSearch@master] Add StatementTimeField to allow indexing time values

https://gerrit.wikimedia.org/r/1277501

I am interested in working on this at the upcoming hackathon in Milan.

To support this, we need to add a TimeValue field to CirrusSearch on Wikimedia Commons. The field could be defined in WikibaseMediaInfo, and maybe some generic TimeValue field definition in WikibaseCirrusSearch. To keep scope small, I would a specific config such as $wgMediaInfoSearchIndexCaptureProperty that would have the property id for the "inception" (https://www.wikidata.org/wiki/Property:P571)

I would set the field like this:

"mediainfo_capture_time" : [
   "2025-12-17"
],

Potentially the inception property could have multiple values, though maybe one is preferred and we use the preferred if set.

I don't think we want to use nesting, like:

"statement_time": {

"P571":  [
  "2025-12-17"
],

}

as that introduces complexity and a performance cost, so instead we could configure these fields for specific properties, and limit to the "inception" (or capture date) property as used on Commons.

cc @EBernhardson @dcausse From the search side of things, does this sound okay? and how feasible is it to rebuild the Cirrus mapping for Wikimedia Commons to add a field?

here is a proof of concept:

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseCirrusSearch/+/1277501

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/1277504

If this is too complicated or there is another better approach, then open to ideas for this.

I would set the field like this:

"mediainfo_capture_time" : [
   "2025-12-17"
],

Potentially the inception property could have multiple values, though maybe one is preferred and we use the preferred if set.

I don't think we want to use nesting, like:

"statement_time": {

"P571":  [
  "2025-12-17"
],

}

as that introduces complexity and a performance cost, so instead we could configure these fields for specific properties, and limit to the "inception" (or capture date) property as used on Commons.

I don't have strong preferences either ways but perhaps the nested approach might bring more flexibility (I don't see a perf impact here as long we control the properties that can get fed into this field).
New fields also requires a schema change to

A statement_time approach with a type map<string, string or dedicated time format> might make things easier to re-use I think both for the schema but also at query time. With a dedicated top-level field per property you might need to create a dedicated search keyword to filter using this data as opposed to statement_time where we could try to look into whether we can fit a date range syntax into haswbstatement directly?

Change #1277504 abandoned by Aude:

[mediawiki/extensions/WikibaseMediaInfo@master] Add mediainfo_capture_time search field

Reason:

do not need this

https://gerrit.wikimedia.org/r/1277504

Change #1281785 had a related patch set uploaded (by Aude; author: Aude):

[mediawiki/extensions/WikibaseMediaInfo@master] Update test with statement_time field

https://gerrit.wikimedia.org/r/1281785

Change #1281917 had a related patch set uploaded (by Aude; author: Aude):

[mediawiki/extensions/MediaSearch@master] Add date filter to MediaSearch

https://gerrit.wikimedia.org/r/1281917

Change #1277501 had a related patch set uploaded (by Aude; author: Aude):

[mediawiki/extensions/WikibaseCirrusSearch@master] Allow indexing and filter by time values

https://gerrit.wikimedia.org/r/1277501

aude moved this task from Backlog to Doing on the User-aude board.

Change #1281785 merged by jenkins-bot:

[mediawiki/extensions/WikibaseMediaInfo@master] Update test with new statement_time field in WikibaseCirrusSearch.

https://gerrit.wikimedia.org/r/1281785

neriah changed the task status from Open to In Progress.Jul 14 2026, 11:33 AM
neriah moved this task from Backlog to In Progress on the Community-Wishlist board.