Can you post another screenshot using uselang=qqx to show what system messages are used, if any?

In T243863#5837273, @DannyS712 wrote:

Can you post another screenshot using uselang=qqx to show what system messages are used, if any?

There you go!

(permissionserrorstext-withaction: 1, (action-createpage))

(globalblocking-ipblocked-range: Vituzzu, meta.wikimedia.org, leaky colo + open proxy at 209.58.128.44, 22:38, 1 (june) 2016, 22:38, 1 (june) 2021, 209.58.142.154, 209.58.128.0/20)

Change 568420 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/GlobalBlocking@master] Allow site owners to render block reason at a particular wiki

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

I skimmed the patch, not really a huge fan of making cross-API requests just to render a block message. Is using templates a hard requirement here? I don't think these messages are updated that often, are they?

Instead I suggest we just place whatever messages stewards want in the WikimediaMessages extension, have GlobalBlocking provide a nice frame/icons around the message, and then have stewards start blocking users with {{int:wikimedia-messages-open-proxy}} or something like that.

This would also solve T265812: Common Protection/Block messages should change based on the language of the user/site they are access from.

In T243863#6807881, @Legoktm wrote:

I skimmed the patch, not really a huge fan of making cross-API requests just to render a block message. Is using templates a hard requirement here? I don't think these messages are updated that often, are they?

I think templates are a hard requirement. They're not updated often, but they often make use of other templates (available at Meta), which people know how to work it. of course, you can just subst it all, but that will have two issues:

• the entries in WikimediaMessages will quickly become unmaintainable (no one would be able to read them),
• nearly all stewards speak wikitext and can make changes in templates on-wiki, but little amount of stewards can do a Gerrit patch.

If calling parsing API each time is not possible, maybe we can memcache it (keyed by MD5 hash or something)?

Instead I suggest we just place whatever messages stewards want in the WikimediaMessages extension, have GlobalBlocking provide a nice frame/icons around the message, and then have stewards start blocking users with {{int:wikimedia-messages-open-proxy}} or something like that.

I think that's not an acceptable solutions for the above reasons.

This would also solve T265812: Common Protection/Block messages should change based on the language of the user/site they are access from.

Change 743665 had a related patch set uploaded (by Majavah; author: Majavah):

[mediawiki/extensions/GlobalBlocking@master] Parse global block reasons on another wiki

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

Change 568420 abandoned by Urbanecm:

[mediawiki/extensions/GlobalBlocking@master] Allow site owners to render block reason at a particular wiki

Reason:

Ic650b2c7bc6e20ec82d3b369deeabef987298510

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

Change 743665 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Parse global block reasons on another wiki

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

Change 743695 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] [labs] Set GlobalBlockRemoteReasonUrl

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

I merged @Majavah's patch (thanks!) to implement the new feature. Next, we should do tests at the beta cluster, to ensure feature works as expected (can be done as soon as https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/743695/ is merged).

Then, we can deploy this to production (by setting the newly introduced configuration variable).

I would have -1'd or -2'd the above patch had I been awake in between the short time it was proposed and merged.

• One-line commit message, doesn't explain how it works, motivation for it, nor considerations/tradeoffs
• No support for localization AFAICT (why is it parsed in content language and not UI language?) - refs T265812: Common Protection/Block messages should change based on the language of the user/site they are access from
• Introduces cross-wiki HTTP dependency without consideration for timeouts or consistent failure modes
  • If I read the code correctly, it'll even make the API request on the local wiki (not an issue for Meta, since global blocks don't apply there)
• Other code quality issues like use of __FUNCTION__ instead of __METHOD__ (I don't actually understand the point of logging the exception at all, the stack traces will all be roughly identical, though the log messages could be improved by adding context besides the HTTP Status output)
  • Also using multiple array_key_exists() instead of just one big isset()

I must've missed T243863#7366015 earlier, I'm still concerned that templates just aren't going to work. What if the template uses TemplateStyles? Or are we going force the use of inline styling?

I worry that this ticket started with a proposed solution rather than looking at the underlying problem and working out a better solution to that specific problem, instead of reinforcing the already chosen solution.

In T243863#7548654, @Legoktm wrote:

I'm still concerned that templates just aren't going to work. What if the template uses TemplateStyles? Or are we going force the use of inline styling?

I'm curious as to why action=expandtemplates is being used, I assumed earlier that it would be action=parse. Do you really want wiklinks to be interpreted in the context of the local wiki? I think index.php?action=render would have been a better endpoint for this, since it already does URL expansion.

I worry that this ticket started with a proposed solution rather than looking at the underlying problem and working out a better solution to that specific problem, instead of reinforcing the already chosen solution.

To clarify this, if GlobalBlocking were introduced today, and we had a requirement of having block messages render on all wikis, I don't think we'd come to the solution of "let's use Meta templates and have cross-wiki HTTP API calls to render them".

In T243863#7366015, @Urbanecm wrote:

I think templates are a hard requirement. They're not updated often, but they often make use of other templates (available at Meta), which people know how to work it. of course, you can just subst it all, but that will have two issues:

• the entries in WikimediaMessages will quickly become unmaintainable (no one would be able to read them),

Yeah, forcing long wikitext messages into a one-line JSON string isn't great. I think it would be reasonable to have an intermediate format (no reason it couldn't be an on-wiki page!), and just have a script copy them into JSON. That's what I'm doing for the mailman-templates repository.

Based on the current implementation, I don't think making use of other Meta templates is actually a requirement/feature. These templates have to be specially written to not use any custom CSS nor TemplateStyles, use only absolute links, and probably some other edge cases, which will require an entirely separate template hierarchy.

• nearly all stewards speak wikitext and can make changes in templates on-wiki, but little amount of stewards can do a Gerrit patch.

I don't follow why updating block templates is the responsibility of stewards. Surely they have some input into their contents, but once a change is suggested, anyone else can do it on Gerrit for them. And if it's based on on-wiki pages, there's no reason the edit wiki page -> proposing Gerrit change process can't be automated.

In T243863#7548654, @Legoktm wrote:

I would have -1'd or -2'd the above patch had I been awake in between the short time it was proposed and merged.

Sorry for hitting the button quickly -- merging the patch during the weekend wasn't probably the best decision. For further similar patches, I'll make sure to wait for some time to give other reviewers a chance. Since you're talking about a -2, do you think we should revert the patch for now?

• One-line commit message, doesn't explain how it works, motivation for it, nor considerations/tradeoffs

Given my involvement with global blocks (and other steward business), things I mention below are immediately obvious to me, hence, I didn't think about asking about them. Balancing "obvious for everyone" and "obvious for me" correctly is a capability I need to improve, so thanks for noting all the questions below.

• No support for localization AFAICT (why is it parsed in content language and not UI language?) - refs T265812: Common Protection/Block messages should change based on the language of the user/site they are access from

I missed the use of content language. Sorry for that. That's definitely sth that should be changed.

• Introduces cross-wiki HTTP dependency without consideration for timeouts or consistent failure modes

It checks the API response is in expected format (and fallbacks to the original wikitext if it isn't). To me, that looks like a sufficient error check.

• If I read the code correctly, it'll even make the API request on the local wiki (not an issue for Meta, since global blocks don't apply there)

IMO, this should be solved at the configuration level (by not setting the URL config field). If the config is null, meta will silently fallback to local wikitext.

• Other code quality issues like use of __FUNCTION__ instead of __METHOD__ (I don't actually understand the point of logging the exception at all, the stack traces will all be roughly identical, though the log messages could be improved by adding context besides the HTTP Status output)
  • Also using multiple array_key_exists() instead of just one big isset()

I must've missed T243863#7366015 earlier, I'm still concerned that templates just aren't going to work.

Why do you think templates won't work and what do you think is a better solution (written before seeing your reply to my comment)? I see WikimediaMessages mentioned at T243863#6807881, and I believe the comment you linked explains why that doesn't work well.

Templatized block reasons work well at multiple other wikis. I think it's natural to use a solution that we already support for local blocks, and extend it to global blocks, rather than attempting to reinvent the wheel.

What if the template uses TemplateStyles? Or are we going force the use of inline styling?

The issue of TemplateStyles (and scribunto) was discussed in the patch itself. @Majavah explained that even without TS support, it would be already a (huge) improvement, and I agreed (and accepted the patch).

FWIW, this is in line with what local blocks do (including ignoring TemplateStyles). So, at least, this is not doing error message displaying in a less-reliable way compared to local blocks.

I worry that this ticket started with a proposed solution rather than looking at the underlying problem and working out a better solution to that specific problem, instead of reinforcing the already chosen solution.

Well, the underlying issue is that people only see "email [email protected]" in the current message, and don't follow basic steps to get rid of the block themselves (for example, by disabling their VPN). This causes a high load in the queue (currently over 1k of mails). Displaying more detailed error messages (including steps the user can take), instead of always inviting to email, is a solution to that problem. Managing the email queue isn't an area tracked in Phabricator, so it has no task to link as a parent :).

In T243863#7548692, @Legoktm wrote:

In T243863#7548654, @Legoktm wrote:

I'm still concerned that templates just aren't going to work. What if the template uses TemplateStyles? Or are we going force the use of inline styling?

I'm curious as to why action=expandtemplates is being used, I assumed earlier that it would be action=parse. Do you really want wiklinks to be interpreted in the context of the local wiki?

Using action=parse was my original intention; @Majavah opted in for a different implementation. While action=parse would solve the TemplateStyles issue mentioned in the previous comments, it wouldn't help with the local URLs, as it provides local URLs (/wiki/Foo rather than domain.org/wiki/Foo).

I think index.php?action=render would have been a better endpoint for this, since it already does URL expansion.

I don't see how would I pass arbitrary wikitext to index.php?action=render. Am I missing something?

I worry that this ticket started with a proposed solution rather than looking at the underlying problem and working out a better solution to that specific problem, instead of reinforcing the already chosen solution.

To clarify this, if GlobalBlocking were introduced today, and we had a requirement of having block messages render on all wikis, I don't think we'd come to the solution of "let's use Meta templates and have cross-wiki HTTP API calls to render them".

In T243863#7366015, @Urbanecm wrote:

I think templates are a hard requirement. They're not updated often, but they often make use of other templates (available at Meta), which people know how to work it. of course, you can just subst it all, but that will have two issues:

• the entries in WikimediaMessages will quickly become unmaintainable (no one would be able to read them),

Yeah, forcing long wikitext messages into a one-line JSON string isn't great. I think it would be reasonable to have an intermediate format (no reason it couldn't be an on-wiki page!), and just have a script copy them into JSON. That's what I'm doing for the mailman-templates repository.

It'd still make that portion of the JSON file unreadable for developers, who have to edit it from time to time. Or do you suggest a completely separate i18n folder totally detached from manual changes by the devs (and TWN translators)?

Based on the current implementation, I don't think making use of other Meta templates is actually a requirement/feature. These templates have to be specially written to not use any custom CSS nor TemplateStyles, use only absolute links, and probably some other edge cases, which will require an entirely separate template hierarchy.

It is kinda similar to multilingual newsletters, where authors (usually writing at & sending from Meta) need to keep track of similar things. The "other templates" usage would likely be a master {{Global block notification}} template, which would be fed with an icon and a translatable headline/text, to avoid duplicating things.

• nearly all stewards speak wikitext and can make changes in templates on-wiki, but little amount of stewards can do a Gerrit patch.

I don't follow why updating block templates is the responsibility of stewards. Surely they have some input into their contents, but once a change is suggested, anyone else can do it on Gerrit for them. And if it's based on on-wiki pages, there's no reason the edit wiki page -> proposing Gerrit change process can't be automated.

Usually, it's the blockers who define what gets displayed to the blockers. I find it more efficient to do it on the wikipage (rather than having to find someone to do a change in Gerrit/wherever). Admitted, with an automated system to do the transfers, this point would be pretty much nonexisting.

In T243863#7548695, @Urbanecm wrote:

Using action=parse was my original intention; @Majavah opted in for a different implementation. While action=parse would solve the TemplateStyles issue mentioned in the previous comments, it wouldn't help with the local URLs, as it provides local URLs (/wiki/Foo rather than domain.org/wiki/Foo).

Either T42128: Add option for absolute URLs to action=parse or using action=render takes care of the URL issues. Also see below

I think index.php?action=render would have been a better endpoint for this, since it already does URL expansion.

I don't see how would I pass arbitrary wikitext to index.php?action=render. Am I missing something?

No, it doesn't support that. I didn't think arbitrary wikitext was a requirement though, just a template?

In T243863#7366015, @Urbanecm wrote:

I think templates are a hard requirement. They're not updated often, but they often make use of other templates (available at Meta), which people know how to work it. of course, you can just subst it all, but that will have two issues:

• the entries in WikimediaMessages will quickly become unmaintainable (no one would be able to read them),

Yeah, forcing long wikitext messages into a one-line JSON string isn't great. I think it would be reasonable to have an intermediate format (no reason it couldn't be an on-wiki page!), and just have a script copy them into JSON. That's what I'm doing for the mailman-templates repository.

It'd still make that portion of the JSON file unreadable for developers, who have to edit it from time to time. Or do you suggest a completely separate i18n folder totally detached from manual changes by the devs (and TWN translators)?

I'd definitely give it its own folder, and instruct devs to edit it on-wiki and use the theoretical wiki->Gerrit sync script instead of Gerrit directly. Translators would still do it via TWN which goes into Gerrit, but I believe the one-line-of-JSON isn't an issue for them.

Based on the current implementation, I don't think making use of other Meta templates is actually a requirement/feature. These templates have to be specially written to not use any custom CSS nor TemplateStyles, use only absolute links, and probably some other edge cases, which will require an entirely separate template hierarchy.

It is kinda similar to multilingual newsletters, where authors (usually writing at & sending from Meta) need to keep track of similar things. The "other templates" usage would likely be a master {{Global block notification}} template, which would be fed with an icon and a translatable headline/text, to avoid duplicating things.

Good point.

In T243863#7548693, @Urbanecm wrote:

In T243863#7548654, @Legoktm wrote:

I would have -1'd or -2'd the above patch had I been awake in between the short time it was proposed and merged.

Sorry for hitting the button quickly -- merging the patch during the weekend wasn't probably the best decision. For further similar patches, I'll make sure to wait for some time to give other reviewers a chance. Since you're talking about a -2, do you think we should revert the patch for now?

Just a day would be nice :) I don't think a revert is necessary if we don't enable the given functionality before fixing it. There seems to be other useful stuff in that patch like setting up the service wiring stuff that would be good to keep I think.

• Introduces cross-wiki HTTP dependency without consideration for timeouts or consistent failure modes

It checks the API response is in expected format (and fallbacks to the original wikitext if it isn't). To me, that looks like a sufficient error check.

There should be an explicit timeout IMO, see what GlobalUserPage does.

Templatized block reasons work well at multiple other wikis. I think it's natural to use a solution that we already support for local blocks, and extend it to global blocks, rather than attempting to reinvent the wheel.

Well, those templates don't have to worry about working cross-wiki, which makes things very different :) Admittedly, now that I've spent a few days thinking about it, I don't even like templates for local block reasons. There's no usage tracking, it's hard to preview what modifications to the template look like in the context of viewing the block (I believe it's nested in other divs), and the log entries have a arbitrary template that isn't useful or clickable.

There are two types of cross-wiki usage, local parsing and remote parsing (related: https://www.mediawiki.org/wiki/Topic:Ss7tq42hj4mnd3oh). My initial expectation was that this would be a good use for remote parsing (typically action=parse/render) so that what you see on Meta is roughly what you get on other wikis, but using action=expandtemplates means its actually local parsing. It seems like this was intentional but it's not what I would intuitively expect. It's possible I'm missing some use case in which the ability to insert local context and variables is useful.

I'm going to post a more detailed, alternative proposal in my next comment because this one is getting very long.

Alternative proposal:

Each block reason is has 3 parts: an internal ID, a short description (one line, for log entries. intended to contain links) and a long description (longer, what users see when they're blocked).

A list of acceptable block reasons is stored in an array $wgGlobalBlockingReasons. If this system works out, this array could move to an on-wiki JSON page.

When blocking someone, GlobalBlocking uses a magic comment to in the reason database field: int:{internal-id}|{param1}|{param2}... (similar to Wikibase magic comments).

In the context of a log entry, it will be expanded to the short description, which is a MediaWiki message using $1 like parameters. When a user tries to edit and is shown a notice, they get to see the long description (also a MediaWiki message with $1 parameters), which has much more detail about what to do and how to appeal, etc. Both messages will be shown in the viewing users' UI language.

There will also be a hardcoded "custom" block reason, in which the message is just "$1" so that non-stock reasons can be used for exceptional cases.

At Wikimedia, block reasons will be designed and curated on-wiki in English. A Toolforge tool could be used to implement a smarter preview, showing how it'll look on other wikis. A bot will notice an edit has been made, and after some time delay, verify it hasn't been reverted or edited since. It'll propose a change to WikimediaMessages in Gerrit, and someone with +2 will merge it and the update will go out with the next train. If this system works out, we could have the messages in a separate extension so the +2 ACL can be even broader. Translators using TWN will translate the block reason messages and have them deployed using the normal process.

Thoughts?

Noting here that I proposed this on this year's Community Wishlist Survey: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Admins_and_patrollers/Allow_using_templated_reasons_in_global_blocks

In T243863#7550478, @Legoktm wrote:

Thoughts?

This is an interesting idea that could work, my main concern is the delay for an edit to be deployed.

Change 743695 abandoned by Urbanecm:

[operations/mediawiki-config@master] [labs] Set GlobalBlockRemoteReasonUrl

Reason:

can be easily restored later when needed

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