Worth mentioning:

• The temporary account does get created – when I manually navigate back to no.wikipedia, I have the black bar and a temp account username

I don't have any strong opinion about whether it should or shouldn't create a temporary account – I was under the impression that temporary accounts would only be created when edits were saved, but I see from that task that there are some scenarios where it would be useful to have a temporary account even though no edit is saved (such as AbuseFilters kicked in, needing to log an actor). So like I said, feel free to just decline this. :-)

In T222847#6178518, @MMiller_WMF wrote:

[…] or potentially even replacing the Main Page with the homepage, are good ideas.

Thank you very much for fixing that, @matmarex, and for the pointers for how to learn more. Greatly appreciated!

Not sure when this was fixed, but it is working as requested nowadays.

@matmarex @Fomafix Adding you as subscribers because you've both contributed to jqueryMsg in the past, so I'm hoping you might have more of a clue than me about how to fix this. :-)

For future reference, external link syntax in MediaWiki is: [URL label]. So a link to Google would be: [https://google.com/ Google] and would display as Google.

translatewiki is not part of the link, it is the link label. So the proper link (with {{CONTENTLANGUAGE}} replaced with fr is: https://translatewiki.net/w/i.php?title=Special%3ATranslate&group=ext-automoderator&language=FR&action=translate&filter=

Boldly WONTFIXing this. It is not a problem in Wiktionaries, and it's good that the message keys displayed match the ones in the definition (json) files.

In T4085#10238970, @Quiddity wrote:

@tstarling Thanks! Is there a documentation page#section that it can link to?

I added an entry to https://meta.wikimedia.org/wiki/Tech/News/2024/43

In T377312#10237273, @Tgr wrote:

Why did it go through on the 17th attempt? That seems concerning.

That seems to be it!
After doing that, I was automatically logged in when visiting bclwikisource (the final wiki I hadn't logged in to yet), so presumably it's all good.

Did some manual logging when I tried to log in to tddwiki just now. All times are in UTC.

Update: Second login attempt to annwiki worked approximately 10–15 minutes after my first attempt (where I got the same error as above).
So why the long delay, and why am I not logged in automatically (like I am with the "Jhsoby" and "Jon Harald Søby (WMNO)" accounts)?

Not reproducible

Submitted the revert above because the patch basically makes it impossible for me to copy/paste things, since it hijacks Ctrl+C and Ctrl+V on dvorak keyboards (and possibly other layouts too?). The revert commit message has suggestions for how to fix this.

In T376772#10213226, @Aklapper wrote:

Out of curiosity, how does production access with Incubator work? Maybe I don't understand at all what "production wiki access" implies.

It means getting a new wiki, whether or not the language in question already has an active test wiki in the Incubator.

I think this might actually be a Vector-22 thing, so adding that tag. On Wikipedia, that dropdown contains links to user talk and contribs when you're not logged in, but anonymous contributions are disabled in Translatewiki, so there's nothing to show.

I just stumbled across this task just now by accident.

To me it looks like the problem in Minerva is different, and it's basically accidental that there were problems with .mw-selflink there at the same time as in Vector. The problem in Minerva (minus the cursor) should actually already be solved with rSMIN3d74f38a51b1: Scope codex link styles to footer and content body, remove cached CSS, which should go live on enwiktionary later this week.

@Amire80 I believe the patch above should solve all of these issues. However, it only solves them locally for Translatewiki.

I encountered this today when running stats for letters used in Norwegian Bokmål lemmas/forms. According to the query service, the lemma for L907996 and L907999 is U+1DD4 (combining æ) instead of what it should be, U+00E6 (æ). But it only happens for those two lexemes, not any other lexemes that have the character "æ" in them.

This was mentioned just now in a talk at Wikimania (https://wikimania.eventyay.com/2024/talk/KZZYW7/). It probably should apply to Latin-script languages too though, at least when the article subject is not a person or work. Maybe the scope of this task can be widened?

In T349000#10018867, @Jdlrobson wrote:

Thanks for the URL update! @jhsoby are you still interesting in helping get this fixed?

That's fine of course, since it solves the problem. But it's good to keep this in mind for any future popups, that they shouldn't be shown to people who never saw the old version. :-)

In T367213#9881386, @bd808 wrote:

I believe this would need to work by adding something to the WikimediaDebug extension that changes what is rendered on the page. There are some methods for sniffing for an installed extension in Chrome that might work, but Firefox appears to have closed those same loopholes to reduce browser fingerprinting options.

Deployed

In T367674#9896701, @Dcljr wrote:

Is this in response to a request from that community? If so, please link to the discussion. If not, why do you think this needs to be done? (What problem are you trying to solve?)