https://github.com/wikimedia/InteractionTimeline/pull/113

In T185785#5416619, @dmaza wrote:

I vote for doing something like <noscript><meta http-equiv="refresh" content="0; url=/no-js-version" /></noscript>. That allows us to redirect to a php page with a translated message saying that we don't support a nojs experience.

As I mentioned here, I don't think this change is necessary. It only makes sense if there is more than one link that needs to be displayed, but since there is only a single link I'm not not sure why we'd make this change. To me it's really clear that it's a link by it's hover state and cursor change.

would we rather:

1. Enable server-rendering which will allow us to display the message in the user’s language. This will require splitting the tool into two tools (which is trivial, imho, and can remain in a single repo if we want): https://lists.wikimedia.org/pipermail/cloud/2019-August/000774.html
2. Leave the app as “static” and display the message in all languages?

In T196575#5413610, @mobrovac wrote:

This is indeed more aggressive, but given @Anomie's fix in Gerrit 491300 for T216245: VisualEditor, MobileFrontend, and other tools using action=edit do not auto-block IP addresses (which covers ApiEdit) all is left to do here really is to make VE aware of it, if I'm not mistaken. To that end, Gerrit 528893 LGTM.

In T196575#5410742, @gerritbot wrote:

Change 529824 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Track all requests that load the block with a block cookie
https://gerrit.wikimedia.org/r/529824

In T207893#5409768, @alaa_wmde wrote:

@dbarratt @Niharika have you tested this? is it good?

I gave up and split the users. :)

In T189144#5403459, @Mooeypoo wrote:

Hmmm but I set up Hebrew as the interface language. Interesting. I'll give it another shot.

FYI We discussed a possible different direction for this, I'll submit a patch for discussion.

It will use the languages in order, you can specify more than one language in Chrome. If English comes before Hebrew, that is the one that will be used. :)

Core Platform Team Would be nice to get a code review of this from your team. :)

Hmm, I suppose this is more of a product decision for @Niharika

In T210790#5377589, @matmarex wrote:

To elaborate on what I said: currently, if you have a script that is supposed to make cross-wiki edits, and you accidentally forget to set the 'origin' parameter (there's a bug in the code), the script just doesn't work. If I understand your proposal correctly, then in the same situation, the script would instead make the edits as an anonymous users, and thus expose your IP address.

In T226657#5375197, @Dinoguy1000 wrote:

It's worth noting that at least one extension has custom namespaces with IDs under 90 (in fact, it assigns the IDs 16 and 17!); see a complete list (as far as known, at least). Though whether this matters for the use case here depends on whether the use case here cares about non-WMF wikis, since AFAICT WikiLexicalData is not installed on any WMF wiki (so I guess that depends on whether CentralAuth sees any real non-WMF use).

In T224468#5375144, @dmaza wrote:

Regarding the error message, I was thinking something like Editing their own talk page can only be blocked for sitewide blocks or partial blocks with restrictions on the User Talk namespace. Let me know what you think.

In T228736#5370925, @dom_walden wrote:

The only thing I notice is that the order of "Details" and "OK" are incorrect (compared to how they were previously). If you like, I can just raise a separate bug for this.

In T216245#5371018, @dom_walden wrote:

Presumably because simply clicking "Edit" on the page and loading the VisualEditor does not call action=edit.
I don't know if we want VisualEditor to mirror what the source editor does, and aggressively spread an autoblock as soon as a user attempts to edit a page.

@dmaza & @Mooeypoo Today @Tchanders and I were talking about this task, and we thought that perhaps it would be better to deprecate the GetBlockedStatus hook (See: T229035). Basically, while GetBlockedStatus technically works it's not ideal. Primarily because it allows an extension to mutate the entire User object rather than just the block. Also, it conflates adding blocks with altering (changing or removing blocks).

In T210790#5366170, @matmarex wrote:

I think defaulting to origin=* is unwise, because it would easily let a script accidentally make unauthenticated write actions, while the user thinks they are logged in, thus making the user's IP address public.