I support this idea. It requires changes to [https://gerrit.wikimedia.org/g/mediawiki/extensions/Cite/+/2463358cafc64ed3f5a7115fea03ac9a57c6e63f/src/ReferenceStack.php#78 this function] and a few other places, including a number of unit tests. Right now, we have code and tests that checks for inconsistent dir values (ltr and rtl for the same ref in different invocations) and these are not ready to see an auto attribute yet. That has to be addressed as part of this task.

Regression possibly caused by [https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-cli/-/commit/0503db2a06ca2421781f4bc39eb647e8c971a3e3 this change] which was merged 5 days ago. Change was created by Raymond Ndibe <rndibe@wikimedia.org> but I cannot find their Phab account to tag them here.

Duplicate of T425056

Exporting the data from the table can be done using a user script in JS. Even the pagination piece can be handled by a creative piece of JS code. I'm not sure if this kind of export is worthwhile implementing in SecurePoll; after all, the use case is an uncommon, external use case, not a core feature of the SecurePoll process.

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.