In T120733#2851426, @kaldari wrote:

So the main thing left to do here is review https://gerrit.wikimedia.org/r/#/c/316574/ and get it merged, right @Sn1per?

Yes, that patch should add the date range filter functionality. (Though I still need to finish up that patch to get it production-ready)

By the way, I have a feeling that a change to the Special:Contributions interface would cause quite an uproar on enwiki (and likely other WMF wikis). Would a user preference be appropriate?

Yes, that patch should add the date range filter functionality. (Though I still need to finish up that patch to get it production-ready)

Any specific pieces you could elaborate on? Anything we could help with?

By the way, I have a feeling that a change to the Special:Contributions interface would cause quite an uproar on enwiki (and likely other WMF wikis). Would a user preference be appropriate?

Please, for the sake of the children, no more preferences. This feature was the 15th most popular request on the 2015 Commuity Wishlist Survey so it may be less controversial than you think. It's also more or less backwards compatible with the previous functionality, so I don't see a good justification for making it a user preference.

Change 326459 had a related patch set uploaded (by Sn1per):
Pager class for filtering by date range

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

I still think, writing full month names as default is an improvement for users by reducing cognitive load when dealing with the widget. There seems to be enough space. Opinions?

@Volker_E: I agree, especially because month abbreviations may not be as commonly used in other languages.

As DateInputWidget gets more exposure, it's important to document how the months/dates are translated (it should use either CLDR or MediaWiki's own messages) and to make a call to action on translators-l etc. (I really hope that the moment.js locale files were only mentioned as an example: it would be disheartening if we were using that stuff, and it would not be appropriate to mix different formats/l10n on the same page.)

In T120733#2825607, @Sn1per wrote:

Current status:

One thing to consider is that the calendar-popup input is extremely hard to use with a keyboard, which for many users is a downgrade of functionality compared to the current date selector.

It's also practically impossible to correctly write in a format like "Tuesday, 5 April 2016" without many guesses and it's usually very hard to change selection (if you try to manually change the number of the day, month or year, JavaScript stuff tends to freak out). So you're always a slave of the calendar popup. It helps to reduce complexity of the date format: is the day of the week really necessary?

In T120733#2900404, @Nemo_bis wrote:

It helps to reduce complexity of the date format: is the day of the week really necessary?

I wonder this too. We don't expose days of the week anywhere else in the UI, so why here?

In T120733#2900404, @Nemo_bis wrote:

As DateInputWidget gets more exposure, it's important to document how the months/dates are translated (it should use either CLDR or MediaWiki's own messages) and to make a call to action on translators-l etc. (I really hope that the moment.js locale files were only mentioned as an example: it would be disheartening if we were using that stuff, and it would not be appropriate to mix different formats/l10n on the same page.)

DateInputWidget uses moment.js to format dates (such as at https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.widgets/mw.widgets.DateInputWidget.js#L376) and does use moment locale data. The other date widget (DateTimeInputWidget) seems to use its own formatter with mediawiki locale data.

In T120733#2900406, @TTO wrote:

I wonder this too. We don't expose days of the week anywhere else in the UI, so why here?

Both DateInputWidget and DateTimeInputWidget show the day of the week by default.

As to keyboard-friendliness, with DateInputWidget the formatted date with day of the week etc. is just a pretty display; if you want to type, you input the actual date in YYYY-MM-DD format:

In contrast, DateTimeInputWidget has the user type in the same format as the display format:

In T120733#2900858, @Sn1per wrote:

DateInputWidget uses moment.js to format dates

This is extremely sad and should be reported as a bug if it isn't yet (to be marked as blocker of T31235: Make MediaWiki consistent in how it displays time).

In the meanwhile, someone who knows the process should document on https://www.mediawiki.org/wiki/Manual:DateInputWidget how one can add or change data to moment.js and get the updates on MediaWiki/Wikimedia, so that Special:Contributions doesn't become untranslatable. I can then distribute the information to translators on mediawiki-i18n, translators-l etc.

Change 335230 had a related patch set uploaded (by Sn1per):
e PHP DateInputWidget in Contribs and use for range filtering

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

Change 335230 merged by jenkins-bot:
Option for DateInputWidget to display full month and day names

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

@Sn1per: Are you still working on this? It looks like the task has attracted a bit of scope creep. We should concentrate on tackling the back-end support first and then worry about the front-end UI once we have a working prototype. The prototype could even just use text input fields for now. If you feel like you're stalled, Community Tech would be happy to work on it. Just let me know.

In T120733#3015240, @kaldari wrote:

@Sn1per: Are you still working on this?

Sorry, I've been meaning to ask a question about @matmarex's comment on https://gerrit.wikimedia.org/r/#/c/316574/ but somehow forgot to.

Code-Review-1

• If you specify an end date, it's not possible to use the "newer 50" link to view newer revisions (the link is not active). It can be done with the current interface.

Is this a required feature (which would make the end date behave differently from the start date)? My implementation of RangeChronologicalPager uses dates to simply filter the database query used by the pager, and checking for newer revisions to use and link to via a "newer 50" link would require some more complex logic.

If it's an intentional change, it's probably okay, I just pointed out a change in behavior that was not mentioned anywhere.

@Sn1per: Can you clarify that no longer supporting "newer 50" when there is an end date is intentional (or not)?

@kaldari It was unintentional because the pager logic checks to see if the mOffset field is empty to determine whether to check for "newer 50," and my change did not use this field, which caused the pager logic to never use "newer 50." (My response to @matmarex above was inaccurate because I mixed some things up in my head) I've updated both patches to simply reuse the offset field for the end date and to add a separate condition for the start date and the pager links and offset should work as before.

Change 341741 had a related patch set uploaded (by Sn1per):
[mediawiki/core] [WIP] Make infused and non-infused DateInputWidget consistent

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

Change 341741 merged by jenkins-bot:
[mediawiki/core] Make infused and non-infused DateInputWidget consistent

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

Change 326459 merged by jenkins-bot:
[mediawiki/core@master] Pager class for filtering by date range

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

The current patch works great, although the DataInputWidget becomes completely unusable if JavaScript is disabled due to T166416. Should we wait for that bug to be fixed before we merge this?

Change 316574 merged by jenkins-bot:
[mediawiki/core@master] Use PHP DateInputWidget in Contribs and use for range filtering

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

I think the <br> between the start and end inputs should be removed. So that the "settings box" would be more compact (not a luxury), more appealing (one less line, feels less cluttered) *and* more ergonomic (one line equals one functionality, whereas breaking this rule as currently is quite disturbing).

Then, even better, the "label + associated input" parts could be made unbreakable, so that on (very small) screens there wouldn't be a line break between the "To date:" label and its associated input.

Also, the mouse pointer could be improved:

• When the date selector is opened, the mouse over the text input should be a caret and not a hand. It would make understandable the date can be manually typed.
• Less important, when the date selector is closed, the mouse over the text of the input (e.g. "No date selected" or a date) is an arrow, while over the rest of the input the mouse is a hand. It should always be a hand.

@Od1n: Please file a bug against the DateInputWidget for that.

Here it is: T169034

Just wanted to leave a comment thanking you all for creating and deploying this feature - it's been incredibly useful to me lately, something I didn't even realized I needed so badly until I had it! Thank you, thank you, thank you :)

It would increase the tool's convenience a bit for me if, when I select a date in the "from" calendar dropdown, the cursor/focus automatically switched to the "to" dropdown. Currently after clicking a "from" date, the "from" calendar remains dropped-down and focused, but fast-forwards to today's date. The behavior I expect from this type of date selection, based on using it on many other sites, is to get automatically switched to the "to" calendar after selecting a date in the "from" one - that behavior makes entering a range a more streamlined, no-extra-clicks-needed flow.

In T120733#3430392, @Kbrown wrote:

Currently after clicking a "from" date, the "from" calendar remains dropped-down and focused, but fast-forwards to today's date.

It looks like this wasn't intended. In fact, Prateek wrote a patch in 2015 to make it close (see T114942) but that code doesn't work any more because it focuses the text box after closing the calendar, and in response to the text box being focused, the calendar opens again. This appears to be a regression from https://gerrit.wikimedia.org/r/341990 (written for T159987 in March 2017). I have a fix for this, will submit it shortly.

Change 364909 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] DateInputWidget: Unbreak closing the calendar when selecting a date

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

Change 364914 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] Special:Contributions: Open "To date" widget after selecting a "From date"

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

Change 364909 merged by jenkins-bot:
[mediawiki/core@master] DateInputWidget: Unbreak closing the calendar when selecting a date

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

Change 364914 merged by jenkins-bot:
[mediawiki/core@master] Special:Contributions: Open "To date" widget after selecting a "From date"

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

Any feedback about my comment above?

I think the <br> between the start and end inputs should be removed. So that the "settings box" would be more compact (not a luxury), more appealing (one less line, feels less cluttered) *and* more ergonomic (one line equals one functionality, whereas breaking this rule as currently is quite disturbing).

Then, even better, the "label + associated input" parts could be made unbreakable, so that on (very small) screens there wouldn't be a line break between the "To date:" label and its associated input.

Change 281113 abandoned by Jdlrobson:
Allow date ranges in Special:Contributions

Reason:
Associated phabricator ticket has been resolved so this patch can now be abandoned. Thanks for attempting to solve this Sumit! I hope you are doing well!

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

Following up to my above comment, there is no longer a linebreak between the "From date" and "To date" inputs since the form has been converted to OOUI, refs T117736 :)