The REL1_39 backport seems to be working fine on FactGrid. Thanks @Tgr for the suggestion and review! \o/

In T370578#10000278, @LucasWerkmeister wrote:

It looks like the problem is already fixed since MariaDB 10.6.0, but remains reproducible in 10.5.25 (the latest patch release in the 10.5 series so far).

In T370578#10000228, @LucasWerkmeister wrote:

In T370578#10000202, @Tgr wrote:

I don't think we really need this query. We can just check change_tag_def.ctd_count instead. Just replace all the changeTagDefStore->getId() calls with a call to ChangeTagsStore::tagUsageStatistics() and intersect that with the result from the previous query.

That sounds like a good idea – I’ll see if I can put a patch together later. Thanks!

It looks like the error is already fixed since MariaDB 10.6.0, but remains reproducible in 10.5.25 (the latest patch release in the 10.5 series so far).

In T370578#10000202, @Tgr wrote:

I don't think we really need this query. We can just check change_tag_def.ctd_count instead. Just replace all the changeTagDefStore->getId() calls with a call to ChangeTagsStore::tagUsageStatistics() and intersect that with the result from the previous query.

Hm, in ANALYZE, there’s a huge mismatch between filtered (0%) and r_filtered (100%):

I’m not sure what you mean… I can reliably reproduce the behavior that the query is being slow (ca. 2 seconds, sometimes a bit less) when to me it seems like it shouldn’t be:

Alternatively, the query seems to also become fast again if I just add a LIMIT, like so:

Attempted fix uploaded: https://bitbucket.org/magnusmanske/fist/pull-requests/6

Probably not very helpful but I used to have a similar issue on Phabricator, with a slightly different set of emoji fonts: T235339: Phabricator fonts look broken on systems with JoyPixels (formerly EmojiOne) installed

Can confirm this seems to work now \o/ thank you!

This ought to work, I think:

That sounds amazing, thank you!

I assume it should be relatively simple to serve a redirect to Tool:Containers using an Ingress, like the second half of Tool:Iw § Tool setup (the part added for T257104)?

The first messages in a successful build that aren’t seen in a timed-out build are:

It worked with another retry now 🤷

Okay, then I just forgot what happened in which order, sorry ^^

(Or is that just because I joined afterwards?)

Hm, I don’t see any old relayed message on the IRC side at least?

Should be deployed now.

I looked a bit into this, but I’m not sure it’s a good idea, to be honest. This would be a very high-volume bridge, at least compared to the other bridged channels I’m aware of, and I’m worried that this might trigger some spam detection in Telegram and/or IRC (which could break the bridging of other channels too) – especially as the messages are full of links too. And since the Telegram channel is brand new, it’s not yet clear how much demand there is for a Telegram version of this IRC channel. (Though the channel was just announced in the Wikimedia General chat group, so we can check back tomorrow or in a few days how many subscribers the channel gained in the meantime.)

At least that’s what I get when I do a quick nonsense merge conflict locally:

Hang on, I think I got confused there. Isn’t that just a normal merge conflict display, and with diff3 style we’d also expect a ||||||| marker? 🤔

Still seems to be happening here: https://gitlab.wikimedia.org/toolforge-repos/wd-image-positions/-/commit/0e0deb1a494aeb2e498357330d0a23bd833c38e5

Seems to work now :)

Seems to work fine as far as I can tell \o/

Yeah, I implemented this for Wikidata Lexeme Forms but not most (any?) of my other tools. Shouldn’t be too hard to add though ^^

Great, thank you <3

In T359821#9619973, @LucasWerkmeister wrote:

I don’t know if anyone would object to this or potentially have their workflow broken… should we ask around on wikitech-l? Run a poll somewhere? WDYT? :)

In T365897#9832033, @Skierpage wrote:

I think I figured it out. If an audio file has closed captioning in the TimedText namespace (in any language, I think), then playing it will pop up the video player which displays the closed captioning text.

I’d also be fine with slight variations on the name if we think toolforge_i18n is too ambiguous or potentially misleading (the tag is not for I18n of Toolforge in general, after all), e.g. Python-toolforge_i18n or toolforge_i18n-library.

In T348407#9813295, @fnegri wrote:

@LucasWerkmeister pointed out in IRC we should announce more widely this feature before enabling access from Quarry to all the _p databases.

Alright, thanks!

Alright, I think this is done now \o/

Yes, there are still some parts of the tool I need to make translatable / add messages for. I’ll close the task when it’s done.

\o/

In T364539#9783142, @Lydia_Pintscher wrote:

I fixed the links locally until this is fixed. These edits should be undone once the underlying issue is fixed:

• https://www.wikidata.org/wiki/MediaWiki:Sitesupport-url
• https://www.wikidata.org/wiki/MediaWiki:Wikibase-queryservice-url

This should be fixed now, but the sidebar is cached for one day, so we should only delete the overrides tomorrow (or later). Let’s leave the task open until then, IMHO.

Probably not a train blocker since we should be able to work around it in the MediaWiki: namespace, but FYI: T364539: Protocol-relative URL in sidebar now interpreted as title (Query Service link in Wikidata sidebar broken)

@Nikki points out that the donate link is also affected (points to https://www.wikidata.org/wiki///donate.wikimedia.org/wiki/Special:FundraiserRedirector%3Futm_source%3Ddonate%26utm_medium%3Dsidebar%26utm_campaign%3DC13_wikidata.org%26uselang%3Den).

I can reproduce the issue locally and reverting Replace deprecated url functions in Skin class fixes it, so I guess the replacement functions work slightly differently.

Closing, the session took place and was fun :)

https://mamot.fr/@belett/112387464745968174
https://wikis.world/@LucasWerkmeister/112387523506136487

Alright, GitLab CI wasn’t as bad as I feared ;) I’ll copy some more things from wikibugs2 CI later but for now it should be working (and I should see the result on the next translation export… Thursday?).

Hm, I just realized that having the CI on GitHub is not ideal if the l10n-bot merge requests are on GitLab, given that many of the tests are making sure the translations are right 😅

CC @Slst2020 who just ran toolforge envvars list in T362062: [Session] Toolforge & Cloud VPS demos (the only variable that was truncated at 50 characters was the Django secret key) – she said she’s gonna change the credentials afterwards, but IMHO it would’ve been better if the command hadn’t shown them to the whole room in the first place :)

In addition to making the rest of the tool translatable, I realized there’s also one more important thing I need to do before this can be considered done: add a way for users to set the language :D

In T251008#9771333, @JeanFred wrote:

I see, thanks for the note. I think this is unlikely enough as a modelling practice to not have to worry about it

The import into TWN seems to have worked – I just translated most of the messages into German. (Except for the tool name, because I don’t know if I want it translated or not. I’ll leave that decision to another translator, given that I usually use the software in English anyway ^^)

(It’s also quite strange that the email didn’t go to me, the repository “owner”, but that’s probably a separate issue.)

I wonder if there's some other mechanism for doing this

For the positive query, I would suggest:

Let’s meet in Politseiaed, the park right opposite the hotel.

Now that I’ve seen the venue during dinner: I don’t feel like any of the regular rooms would really work, nor the dining area. I think outside might be best? (And it looks like the weather will be nice enough.)

Scheduled for 17:00 tomorrow (the beginning of the “Nap or solo time for some, social time for others” in the main schedule); place TBD since I haven’t seen the venue yet :)

I can’t find an upstream bug report about this, and it’s not immediately obvious why it shouldn’t work – Telegram’s handleUploadFile and IRC handleFiles both seem to loop over a potential list of files 🤷

I’ve been working on this a bit more recently, see also T363626. (The code hasn’t been pushed anywhere yet, but I think it’s pretty close to that point now.)

Is this task still valid? Apparently the tool as linked in the task description was disabled in T319875, but I don’t see the “this tool has moved” page mentioned in T319875#9520560 anywhere, so I don’t know if there’s still a running version of this tool that this task could apply to.

Two use-cases I have in mind:

Now it’s working again, thanks a lot!

Sounds good to me; though I’m also curious what other “shared SSH”-style environments do (e.g. if the AcceptEnv adjustment is common or not). Sadly I don’t have access to a university network anymore that I could compare to 😔