On the other hand, if T389709 gets done first, the main use case here should just read the pronoun data from that instead. But there should be a single space where a user configures both their grammatical gender settings (used by MW messages) and their pronoun settings (used by scripts, templates, etc)

Sorry if the task description can be confusing. The pronoun display should ideally use data from T389709, but these two tasks are orthogonal.

As far as I understand, it was probably a deliberate design choice to not display explicit pronouns when the grammatical gender has not been explicitly selected. First, people are unaware of the grammatical gender option existing in the first place. This results in a majority of accounts not having an explicit grammatical gender set (thus defaulting to "neutral at best efforts").

In T182632#10688118, @Krinkle wrote:

In T182632#10687909, @Krinkle wrote:

[…]
What you want is probably something like {{urlencode: data | QUERY}}, which does what you need today.

I do note that the specific case of passing {{PAGENAME}} does not work currently, because {{PAGENAME}} is intended for displaying text in markup, and thus outputs special characters as HTML entities to avoid being misinterpreted as wikitext syntax […]. The bug for that is: T15288: urlencode on variables get double-encoded.

To pass the current title as-is to another parser function (i.e. without any encoding), you can use {{#titleparts:}} instead, like so:

{{urlencode:{{#titleparts:{{PAGENAME}}}}|QUERY}}

Or, in Lua as mw.uri.encode(mw.title.getCurrentTitle().prefixedText).

See also https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions##titleparts which talks about which magic words output text for display in markup, and which are for parser functions.

In T182632#10685497, @Krinkle wrote:

You're misunderstanding the issue. I understand that this proposed change will solve your use case, but it is not a workable or scalable solution for the ecocystem in general, nor is it actually needed because the problem at hand has a different cause and needs a different fix.

I've described the issue at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1130265/comments/5b83cdc0_9332aa16

; is a reserved character in URL queries because it is unspecified whether something like https://www.example.org?something=something;else&foo=bar to parse as something=something;else,foo=bar or as something=something,else,foo=bar, or as something=something,foo=bar. I have seen all three possibilities for libraries parsing URLs through me crawling through this issue. The maintainer of CherryPy has put up a valid reasoning for why they parse as something=something,else,foo=bar because the RFCs on HTTP has explicitly allowed parsers to treat ; the same as & in URLs. See https://github.com/cherrypy/cherrypy/issues/1860#issuecomment-640246780. I don't agree with his decision to do so, but there is nothing I can do and it is much much better to just encode this properly anyways.

Just noting here that the proposed dates could clash with UCoC Enforcement Guidelines and U4C Charter Annual Review vote. (per T388931)

Note: This is related to T61643 but I oppose merging this ticket to there. I'm proposing something very specific here and merging would just dilute the discussion.

In T322944#10536654, @LucasWerkmeister wrote:

By the way – the original task description was about owner-only consumers, but I’ve been doing all my testing with “normal” consumers / clients, since that’s the use case I’m more interested in. I assume owner-only consumers would also be fixed by this, since they also boil down to an Authorization: request header (and they would also need &crossorigin=1 in the URL to benefit from the feature implemented here), but perhaps @0xDeadbeef or someone else might want to try that out ^^

See my comment on the related task.

The consensus for establishing an ArbCom was obtained in this RfC a year ago, with the first elections concluding two days ago. The local discussion led to consensus for creating a private wiki and mailing list for coordination was here. This is the main page for zhwiki ArbCom.

By request of the candidate, please remove SickManWP from the candidates list before election starts, thank you.

visiting that link gives me "Our servers are currently under maintenance or experiencing a technical issue" and the error below says "Error: 404, Not Found at Thu, 01 Aug 2024 15:34:26 GMT%"

After some internal discussion, this was a misunderstanding on @3301796's part. The configuration was correct and there is no need to change the options.

Thank you!

Bundling would actually be nice. It would probably help with the bus factor since Legoktm (or any future collaborators) can access both if things happen. We can rename it to something like discordbots if possible, but I have not gotten into accessing the trove project yet so I'm unfamiliar with the technicalities behind it. Let me know if there's anything I can do! And thanks.

Per https://github.com/wikimedia/operations-puppet/blob/ee02ed8031f246dd4f309bb7e83eeb9a8f285f51/modules/profile/manifests/toolforge/redis_sentinel.pp#L79-L80 and https://redis.io/docs/reference/eviction/#eviction-policies, it looks like the Redis for Toolforge instance will start deleting old keys once the maxmemory limit is reached. This is usually fine if applications don't want to use redis as a reliable persistent storage (its advertised as a useful cache service), but it would be a bad thing for this specific tool.

The redis trove database can be named wikiauthbot2 since dashes are discouraged.

loggerdiscordbot is fine by me.

Hmm, looks like Dragonfly is able to outcompete Redis in terms of performance and resource usage. I'm interested in trying that. Not sure if that can be run on trove, but I can set it up on a VPS project myself!

Looks like we're moving forward with Trove, and that would probably need to be associated with a tool on toolforge. I've pre-emptively created one at https://toolsadmin.wikimedia.org/tools/id/logger-discord-bot.

A rough estimate I got from a person hosting the bot themselves is 1-2GB. So I suppose 2 or 3GB would suffice?

Well that was after I manually restarted it.

AFAIK the locale needs to be configured correctly using locale-gen. I just tried installing the language packs, and although I have included language-pack-pt-base in the Aptfile it still errors.

I have migrated the jobs and webservices to kubernetes. This should be resolved now.

What would be the use of an untagged union? It doesn't make sense in the function model.

There is a similar exception I am getting when logging in:

It would be very nice indeed if WebAssembly was the common target.

The main part of this problem is that when converting Wikicode to ImmutableWikicode it tries to parse the title from HTML and stores that. Until this is fixed from parsoid's API side a temporary fix would be to store the original provided title within Wikicode and use that when converting to the immutable one.

Oh huh, yeah. We are describing the same thing here.

Yeah, given that we already have a git repo by reedy, it should be easy to migrate to https://gitlab.wikimedia.org or simply closing/archiving the sourceforge repo and deciding to have future development at GitHub. @Reedy: any opinions?

Occurred to me again, after trying to report someone to AIV, Huggle instantly closed itself. When reopening Huggle to revert, it now reports the error.

So for the software that analyzes past hits, I only needed specific variables (other fields are ignored when parsing the json response) It would be nice if there is some sort of afldetailsprop that allows selecting specific variables such as {add,remov}ed_lines to reduce bandwidth usage.

I have hit this. Query dump is at P31153. Its last dump was "Cannot log in when using MediaWiki\Session\BotPasswordSessionProvider sessions." and then it segfaults.