In T417843#11630324, @bd808 wrote:

A service.template matching the intent of the service.manifest format file given would be:

$HOME/service.template

type: php7.3
backend: kubernetes

Looks similar to T380141

In T417505#11622691, @Bugreporter wrote:

In a previous request at https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous/2022-09#h-Configure_a_Wikiset_to_opt_out_fawiki_from_GIBPE-Manual_requests-2022-01-19T01:25:00.000Z, it is mentioned that Chinese Wikipedia has an adminbot to block open proxies en masse. (There @Huji also describes a possibility to create a local bot that mirrors global blocks.)

Currently Chinese Wikipedia blocks the entire AS of most cloud providers, whether it is used by proxy or not.

In T417505#11618361, @Umherirrender wrote:

You can use a (new) WikiSet to define a group of wikis where a user group should be active and use that WikiSet for the global user group.

Create the wiki set on https://meta.wikimedia.org/wiki/Special:WikiSets/0 as opt-out set.
Set the wiki set on the group: https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/global-ipblock-exempt

I have no idea if there is a process on meta to request a new wiki set or any other policy to apply it.

This would work similiar to the global-sysop user group.
This solution use features of MediaWiki-extensions-CentralAuth and may not usable on all wiki farms, but it should work for wmf wikis.
It does not need a solution in GlobalBlocking

In T417505#11618388, @Izno wrote:

even if the proxies are blocked globally and/or locally.

GIPBE doesn't allow locally blocked IPs to edit. It applies solely to global blocks.

I created https://meta.wikimedia.org/wiki/Community_Wishlist/W509 accordingly

In T414199#11511823, @Marostegui wrote:

Maybe you can explore virtual columns? https://mariadb.com/docs/server/reference/sql-statements/data-definition/create/generated-columns

Great catch. Updating project tags accordingly.

Not able to identify the root cause yet, but it seems to have to do with Template:Void or other empty pages being transcluded in the table.

Per wikitech documentation as this is a major loss of UI elements.

@Nirmos note that even if a filter is not activated often (meaning not all of its conditions are met often), it will still be run every time up to the point where its logic doesn't match the action, therefore there can indeed be a performance issue.

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

Alternatively, either when store.resetForm() is called an update to mw.config should also be performed, or the resetForm() method of the block store should be modified to update mw.config when invoked.

I don't have much familiarity with Codex but I suspect it is either UserLookup.vue lines 285-289 that need to be updated, or the associated methods in Codex itself have to be updated to force an update to mw.config properties. Adding @MusikAnimal since he was the last to touch those lines and hopefully can provide some guidance.

Since our goal is simply for fawiki to match the behavior of enwiki (so that the templates and modules we import work similarly), this can wait for T346052 to be resolved. If that resolution reverts enwiki's behavior to one in which subpages are not enabled in the Category namespace, then this task can be closed. If in the end it is decided that since some templates and modules on enwiki already assume this as enabled, it is better to leave it as "enabled", then this task will need to proceed too.

@Chuiimuii_ofc consensus was achieved.

In T398361#11411826, @IKhitron wrote:

In T398361#11411089, @Huji wrote:

@IKhitron as for the placement of ~, I wonder if using dir=ltr is the right solution. Specifically, I wonder if wrapping the element in <bdi> would be sufficient (and preferred).

Thank you for your help, @Huji. I've read some documentation about the bdi tag, and debugged some special pages. And I have a question. Wouldn't it be better to enclose any user name with bdi, not just temporary accounts? It is done in Special:Watchlist, and it prevents problems in names like User:John-, which is not forbidden in Mediawiki, as far as I could find the restrictions for special characters in usernames.

Same.

@IKhitron as for the placement of ~, I wonder if using dir=ltr is the right solution. Specifically, I wonder if wrapping the element in <bdi> would be sufficient (and preferred).

Reopening this task, as the issue (of sometimes not being able to proceed with an action (of marking edits as reviewed) even if having the right continues. Latest case is fawiki user Fotrus. I had to grant him "reviewer" right as a workaround,

@Chuiimuii_ofc I cannot understand where this is enabled for enwiki. The config file doesn't show it being enabled for Category namespace (14) for enwiki.

@Chuiimuii_ofc yes, and @Jeeputer is already soliciting consensus on that (link)

@STran I had also scheduled it for today, in an earlier time slot. It was just merged.

Gotcha. I can try to help with that.

It would be nice if we could get a code review on the patch, to hopefully be able to restore the September-ish timeline for next annual election at fawp

Local consensus has been achieved to move forward

Awesome!

@Xqt This would be a great chance to fix an old problem in constant names and documentation of pywikibot: 1, 2, 3 and so forth are not Latin digits, they are Arabic numerals. Latin numerls would be like X and I and D.

Persian (fa) is all set

In T396690#10920121, @Mooeypoo wrote:

I think it might be a reasonable assumption (and @Huji can let me know if that's also true for Farsi and Arabic?) that if the x-axis has labels in the RTL language, then the graph is USUALLY aligned RTL, and if it has mathematics/statistics intent, it USUALLY is aligned LTR -- but even that is non consistent in at least Hebrew and Arabic, and I suspect Farsi as well.

Already works

The change has been drafted. Discussion is ongoing on fawiki about the specifics, but so far it seems like the community is in agreement with using the same config as enwiki. I will mark the change as active for review once local consensus has been achieved.

I keep occasionally getting pinged about this general topic on fawiki. Various users there are envisioning a lot of value from having LLMs helped with translation, template editing, etc. Has there been any progress here? Has the OSI certified any of the open models?

Should this be closed given T194697 in core?

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

Thanks for your followed up. I would argue that the phrase "The provided authentication token is either expired or invalid." does not mean "something went wrong with the redirect back to the local wiki" and so a separate message should be created and displayed in such circumstances.

The part I didn't know and Bugreporter educated me on was that deletion happens automatically after 40 days from archiving. So yes, all set here.

Thanks. Definitely reassuring.

There is a flaw with this proposal. Specifically, the part that says "if there's no edit conflict" cannot be asserted done in an automatic way.

I added myself to help with Persian. I also think the wrong Matej was tagged by @ppelberg above; @matej_suchanek is the on who should have been tagged.

That would still be an issue for larger pages. I ran a bunch of quick tests using a JS implementation and it can take several seconds to several minutes to simply compare two consecutive versions of some of our larger pages (I took some featured articles as examples). It is possibly that a PHP implementation running on Wikimedia cluster would be faster the running the JS implementation on my modern laptop, but even if it were to be 10 times faster, it would still be in the many seconds range which is not acceptable. Recall that AbuseFilters need to run completely before the page can be saved.

If someone decides to implement these (either Dice-Sørensen coefficient, or Levenstein distance, or something else) and is in need of some test cases, I have an idea for that: on Persian Wikipedia, we reglurly create redirects to articles where the redirect is only different in the use of certain characters. Specifically, the Persian standard keyboard uses ی yet non-standard keyboards may use the Arabic ي instead, and same goes for standard ک and non-standard ك so for a page with title یاک (مجارستان) you will also find a redirect titled ياك (مجارستان) created. If one runs edit distance or string similarity algorithms on fawiki article titles and main namespace redirects, they should be able to find those redirects quickly. One could even calculate performance metrics (sensitivity and specificity) for the implementation of the algorithm by assessing how many of the redirects it found, and how many other titles/redirects did it find and score highly that were not a correct redirect.

This is the second time I have seen issues related to deprecating mw.Uri and replacing it with the native URL(). May I propose that someone writes a guidance for it?

Temporarily elevating the priority, because many users across many wikis use that gadget and lost the functionality today. Please reduce priority once the issue I just reported is fixed.

@WikiBayer in this edit you broke a widely used gadget. Specifically, your edit on line 517 which changed var url = new mw.Uri(); to var url = new URL(); is causing an error, because the native URL API requires at least one parameter to be passed to its constructor.

The most extreme version of it happened today, when I made an edit and literally 10 minutes later, the wiki forced me to log in again. All I did was refresh the page in the tab that was open since my edits.

FYI it keeps happening every few days, at random times.

No. Thanks!

It happened again. And similar to last time, it resulted in me having to log in again. Duration of inactivity was around somewhere between 12 and 13 hours in both of these cases.