In T132220#4007582, @Nemo_bis wrote:

If more javascript is added to Special:Block, please make sure that it doesn't cancel any previously input data. It's annoying enough that the dropdown selections and other input is discarded as OOUI finishes doing its thing. It's frustrating to be forced to fill things over and over or to wait for all the unnecessary things before using the special page.

I created T189382: OOUI JS loads too slowly on Special:Block for this since it seems like a bigger issue.

In T132220#4040356, @dbarratt wrote:

The DateInputWidget does not have the time select, but it has the design in the mock, the DateTimeInputWidget does have the time select, but has a different design. Which would you prefer?

DateTimeInputWidget

The user should be able to select a date and time for the block to end. My doctored screenshots use the incorrect UI. Please use DateTimeInputWidget.

In T132220#4040468, @TBolliger wrote:

The user should be able to select a date and time for the block to end. My doctored screenshots use the incorrect UI. Please use DateTimeInputWidget.

You got it.

While I was doing this, I was transferring the fixed datetime (from the datetime picker) into a relative datetime to be sent to the server, I discovered that the value is being run through PHP's strtotime which describes itself as:

Parse about any English textual datetime description into a Unix timestamp

which is being used in SpecialBlock::parseExpiryInput()

And then I realized that the form can only accept English strings, which a careful reading of the problem statement of this issue would have revealed:

This avoids typing a (english) timestamp in the correct format inside the duration field, when not using the default block duration from the drop down list.

If I understand this correctly, the problem (the bug) is not a UX issue (that the user has to specify a relative time), but instead an I18n bug (in which, the input must be specified in English).

To determine if this is correct... do English speakers want the date picker? Or would they continue to use the drop downs / relative input?

The solution then, should be to fix the relative input to be I18n. I do not think the solution should be to create a new feature which would only exist as a workaround to a bug and would have to be supported. On top of that, if we implement this feature, we'd still have to fix the I18n bug in the relative input!

I propose that the drop down uses translated strings for the labels that are displayed to the user (I noticed that it doesn't right now), and the value (that is sent to the server) is a ISO 8601 time interval. When the user selects "Other", two inputs will be displayed, one that allows the user to specify a number and another select form field that allows the user to specify the unit (i.e. "days", "weeks", "years", etc.) in their language.

This provides a more consistent UI, fixes the I18n bug, reduces the scope of this issue, and does not introduce any new features. The only downside is that I'm almost done with the date picker, but regardless, I don't think it's worth the cost of implementation, especially when we'd have to open up a new ticket to fix the I18n bug.

I think offering both the datetime expiration picker and a length dropdown is valuable to all wikis regardless of language. Some blocks are for common infractions — e.g. someone vandalized, they get blocked for ~30 hours. But some blocks are more nuanced — e.g. two users are in conflict, block them until we can synchronously discuss it on wiki.

I'm very curious why this didn't come up during our blocking consultation. Did we not get enough non-English participants? Granted, the page on Meta was in English but we reached out to 10 Wikipedias of 10 different languages and did see some language-specific feedback. Just not about this.

I'd really like to hear from @kaldari about this, but my current instinct is to implement the datetime picker on top of the existing (arguably flawed) system and open a new task to talk about proper i18n support.

I've given this some thought, and I think @dbarratt's idea makes a lot of sense. 99% of blocks use the pre-set values, so I don't think we need to build a complicated UI for handling the other 1%. As David mentions, the datetime picker idea is basically a workaround that doesn't completely solve the problem. I think what's really needed is an easy way to enter non-pre-set values without having to resort to English. The easiest way to do that is probably the system David describes. While we're in there, I would recommend moving "Other time:" to the bottom of the list (since it's the least used and most difficult of the options), i.e. moving Ipbother after Ipboptions. But that's just a thought.

BTW, you can get the translated time unit names from the cldr extension I believe. Take a look at the TimeUnits.body.php file.

In T132220#4067247, @TBolliger wrote:

I'm very curious why this didn't come up during our blocking consultation. Did we not get enough non-English participants? Granted, the page on Meta was in English but we reached out to 10 Wikipedias of 10 different languages and did see some language-specific feedback. Just not about this.

In general, because the AHT team is working on the Blocking tools, I think most people are more focused on items that are more relevant to mitigating harassment. We didn't do a general call for people to tell us everything that they have problems with related to the blocking tools.

In T132220#4067247, @TBolliger wrote:

I think offering both the datetime expiration picker and a length dropdown is valuable to all wikis regardless of language. Some blocks are for common infractions — e.g. someone vandalized, they get blocked for ~30 hours. But some blocks are more nuanced — e.g. two users are in conflict, block them until we can synchronously discuss it on wiki.

I'd really like to hear from @kaldari about this, but my current instinct is to implement the datetime picker on top of the existing (arguably flawed) system and open a new task to talk about proper i18n support.

If I remember correctly, the idea for a datetime picker came from de:wp. If so, let's check in with the people who wanted the feature to understand which solution(s) are needed to fix the issues that they were having with the current way to set the time.

Sydney remembers correctly, I brought that in from a discussion on de:wp that unfortunately sprang up just a few days after the closing of the blocking consultations. The length dropdown menu with a flexible option would help solve a lot of the problems, but would still require some outside calculations for one common use-case on de:wp - reinstating a block that was lifted to allow the user to take part in public discussions on his/her request for unblocking. Here the datetime expiration picker would be perfect. But the length drowdown might have a wider range of applications across all wikis.

We talked about this at length in today's AHT standup. We agreed to complete this task (T132220) as currently described. Fixing the i18n issues that David discovered and helpfully described in T132220#4066969 is another important problem to address, but will likely require a lot of discussion on wiki as it could be interruptive of existing workflows on the current interface. David will create a new task.

Also, I'm going to file a new task to gather some data on how blocking tools are use — how many wikis customize MediaWiki:Ipboptions and what are the most common lengths described? What is the distribution of block lengths, per wiki? How many blocks naturally expire vs. are manually unblocked? Etc. Edit: I've created the ticket here: T190328: Generate statistics on blocking usage

Change 422063 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Create Expiry Widget with Date Time Selector

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

Probably should add some tests, but uhh, not sure where...

@TBolliger Added the config $wgExpiryWidgetNoDatePicker it must be set to true before this is deployed, or the wiki will get the default which is false. :)

In T132220#4082428, @dbarratt wrote:

@TBolliger Added the config $wgExpiryWidgetNoDatePicker it must be set to true before this is deployed, or the wiki will get the default which is false. :)

So, we can enable this on a wiki-by-wiki basis?

In T132220#4082441, @TBolliger wrote:

In T132220#4082428, @dbarratt wrote:

@TBolliger Added the config $wgExpiryWidgetNoDatePicker it must be set to true before this is deployed, or the wiki will get the default which is false. :)

So, we can enable this on a wiki-by-wiki basis?

Yes, but the config defaults to being enabled, so you have to intentionally disable the feature (on a per-wiki basis). :)

Ah ok gotcha gotcha. I think it's fine to just release to all wikis, but should probably hear from @SPoore about a release strategy.

David — Is there any way you can set up a test environment? Maybe CommTech Wiki? (see Niharika's recent email)

Sitewide release blocked by T190762: Announce to wikis before releasing DateTime selector on Special:Block

In T132220#4082544, @TBolliger wrote:

David — Is there any way you can set up a test environment? Maybe CommTech Wiki? (see Niharika's recent email)

http://commtech.wmflabs.org/wiki/Special:Block

I can't QA "Temporary Config flag" but everything else hits the Acceptance Criteria!

For the first release, let's only enable on meta, mediawiki.org, and de.wikipedia.

For the first release, let's only enable on meta, mediawiki.org, and de.wikipedia.

Good plan.

The Timeless oddity I mentioned:

Also getting the following JS warning when switching from 'other time' to any of the other options:

Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.

@Samwilson — Curious if this happens for this widget on all uses in Timeless, or just on Special:Block.

Can you make another ticket, if you feel this is worth addressing? I'm not sure if Timeless bugs are the best use of AHT's time right now...

In T132220#4103434, @Samwilson wrote:

Also getting the following JS warning when switching from 'other time' to any of the other options:

Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.

So I saw this before I sent the patch and I'm not sure what the best way to resolve it is (if it should be resolved at all). I need to parse legitimate dates from the text fields to the date selector (which doesn't throw the deprecation warning), but one of the dropdown values (or any other non-specific value) is going to fallback to Date() and then ultimately fail (which is fine, there's nothing we can do about that). The problem is, I can't think of a reliable way to determine the difference between something JavaScript can understand verses something it cannot understand.

I guess I could just attempt to parse with Date() and if successful, pass that object to moment? That would bypass the deprecation warning, but it would also not give moment an opportunity to parse it itself. I figure, if the feature is removed in the future, it (shouldn't?) matter because every time I see the deprecation, the Date() parsing failed anyways, so the removal of the feature, shouldn't result in any problems.

A bigger issue is the console.log() that happens, and older versions of IE do not have the console object, so the notice will throw a fatal error, but I assume moment is first checking for console.log before attempting to use it.

It's probably fine to leave the deprecation warning in, but maybe there's a way around.

Am I reading things correctly: the date only needs to be passed to Moment when the relativeField is "Other time", and not for the other ones? But it's hard to check for that in that spot because the relativeField's change event is getting its value from itself *or* the other text input, so the only way to check is to see if it parses as a date? Maybe it'd be possible to decouple those a bit, and see if it's 'other' or not, and then parse the date.

In T132220#4115411, @Samwilson wrote:

It's probably fine to leave the deprecation warning in, but maybe there's a way around.

Am I reading things correctly: the date only needs to be passed to Moment when the relativeField is "Other time", and not for the other ones? But it's hard to check for that in that spot because the relativeField's change event is getting its value from itself *or* the other text input, so the only way to check is to see if it parses as a date? Maybe it'd be possible to decouple those a bit, and see if it's 'other' or not, and then parse the date.

Uhh... so... basically any wiki can specify their own options, and technically anything that strtotime() supports will work. I'd like to change this to use a standard (non-english) format in T190449.

But yeah, even with that, it would be transferring a relative date to a precise one (and that obviously wont work well in reverse), so we could just limit it to only working when the "other" is selected, but if a wiki removes all of the options, then it's only a text field.

There's also nothing that stops someone from specifying a relative date in the other field, so I can write "2 days" and that will work (since strtotime() can parse that without a problem).

So I think we should try to parse it the best we can (with moment? with Date()?) since there isn't an equivalent to strtotime(), and if it fails, no big deal.

I mean the alternative is is that we don't even try, but I think trying makes a better UX.

In https://gerrit.wikimedia.org/r/#/c/422063/, @dmaza wrote:

The date selector field expands all the way to the right but the trash/bin icon is left aligned after the date making the field looks funny. The input should probably not expand all the way to the right

In https://gerrit.wikimedia.org/r/#/c/422063/, @dbarratt wrote:

This is a defect of the DateTimeInputWidget. It was actually wider by default and I made it shorter. I like it lining up with the other fields... maybe the trash can should be right aligned? Would that fix the problem?

In https://gerrit.wikimedia.org/r/#/c/422063/, @dmaza wrote:

So you can't make the field smaller? Maybe set a max width? or create two columns in that row? If there is nothing you can't do the fine.

So this is how it is by default:

and I made it shorter in order to make it all line up:

Are you saying it should be even shorter?

What are your thoughts @TBolliger?

Don't forget the calendar pop-up is an even different size!

I think leaving it as it is on http://commtech.wmflabs.org/wiki/Special:Block is fine.

In https://gerrit.wikimedia.org/r/#/c/422063/, @dmaza wrote:

A nitpick and not an error, but it might be confusing for someone to see the T and Z on the date format after you have selected a date

In https://gerrit.wikimedia.org/r/#/c/422063/, @dbarratt wrote:

That's actually the date format that DateTimeInputWidget provides, but I could reformat it into something else... but it would need to be something that is 1) Not exclusively English and 2) Understandable by strtotime()

In https://gerrit.wikimedia.org/r/#/c/422063/, @dmaza wrote:

I'm talking about the format you get when you switch to the textfield (pencil) after you pick a date on the time picker.

In https://gerrit.wikimedia.org/r/#/c/422063/, @dbarratt wrote:

Right, so the problem is, is that you need to be able to switch back and forth between the two and it needs to be able to parse the format. I don't care what format we use, but it needs to be consistent.

Here's what we have right now:

but that does not translate to other languages:

this is what I went with:

@TBolliger, so @dmaza is saying that we should not change the format because that's not part of this ticket (and could anger some people, especially on English), but on the flip side, maybe it's a good opportunity to use a language neutral format? What do you think?

I don't anticipate too many people will actually toggle back-and-forth repeatedly. Sure, it's possible and yes, we should provide the best experience but I don't think this is the most crucial detail to split hairs over.

In cases like this, I try to emulate existing patterns on wiki. There are plenty of other places that already show datetime — history, contributions, etc. And this is what they look like with the default preferences:

But as we know, T190449: Expiration field on Special:Block only accepts English input which makes displaying the month name (rather than number) for non-EN communities less than ideal. But if this is the existing behavior than I will agree with Dayllan and not change the existing behavior. We can fix the i18n issues in T190449.

If anyone has a moment to review the patch (https://gerrit.wikimedia.org/r/#/c/422063/) that would be amazing. :)

@TBolliger & @SPoore This will go out on the train and be enabled on all wikis.

Change 422063 merged by jenkins-bot:
[mediawiki/core@master] Create Expiry Widget with Date Time Selector

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

In T132220#4086762 (yeah, it was a month ago — sorry!) we agreed to enable on meta, mediawiki.org, and de.wikipedia for the first release.

In T132220#4155479, @TBolliger wrote:

In T132220#4086762 (yeah, it was a month ago — sorry!) we agreed to enable on meta, mediawiki.org, and de.wikipedia for the first release.

Whoops... missed that, let's update the config before this is released then. :) I created T192962 to do that.

Yay, awesome! Thank you. (and no worries, we really need to be better about updating the requirements when we make decisions in the comments)

quote: "hi, when I select a calendar on Special:Block and then choose a day other than this day, for example tomorrow, after that I can't select again this day, it's not selectable anymore. I can select this day again if I change the seconds or minutes to future. But I think it's better to make always this day selectable and if the time is in past just give a warning. Stryn (talk) 13:42, 4 May 2018 (UTC)"

https://meta.wikimedia.org/wiki/Wikimedia_Forum#Datetime_picker_for_Special:Block

Thank you, @TheDJ . These seem to be requests for improvements to the OOUI elements, which is outside the scope of this ticket and the Anti-Harassment team's purview. I'll make sure their feedback is documented on Phabricator tasks and I will respond on meta wiki by end of day today.

@dbarratt, as far as I know it still does not work, despite "MW-1.32-release-notes (WMF-deploy-2018-05-01 (1.32.0-wmf.2))".

In T132220#4222752, @IKhitron wrote:

@dbarratt, as far as I know it still does not work, despite "MW-1.32-release-notes (WMF-deploy-2018-05-01 (1.32.0-wmf.2))".

This isn't deployed on every wiki (disabled via config) where are you attempting to use it?

In T132220#4222754, @dbarratt wrote:

This isn't deployed on every wiki (disabled via config) where are you attempting to use it?

On hewiki. Why isn't? It's dangerous?

In T132220#4222761, @IKhitron wrote:

On hewiki. Why isn't? It's dangerous?

See T192962 on when it was disabled and T192620 on when it will be enabled globally. This was a product decision, so @TBolliger should be able to give more info. :)

On hewiki. Why isn't? It's dangerous?

Changing anything related to blocking is dangerous ;)

It should be going out next week. Blocks are a critical piece of functionality and we're extra-careful with anything related to them.