I can't reproduce this locally, it works as it should (probably? I haven't tried this feature before now) on my localhost wiki, both when $wgLanguageCode is en and nb, and when using ?uselang=no (in both cases). EDIT: I can reproduce it on https://incubator.wikimedia.beta.wmflabs.org/ though.

FWIW, there were some other recent problems with date formats in T384963, but that was in PHP though.

This is an issue with the new mediawiki.DateFormatter module (T389161).

I think this was supposed to have been fixed with r1134090. Before that patch, the same issue happened for German. So it sounds there's something unique to the Norwegian Bokmål fallback chain, maybe.

Change #1135709 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):

[mediawiki/core@master] Language::getJsDateFormats(): Always include default format in styles

https://gerrit.wikimedia.org/r/1135709

In T391423#10724743, @MusikAnimal wrote:

So it sounds there's something unique to the Norwegian Bokmål fallback chain, maybe.

Thanks! I did some digging, and was able to find out why this happens, and commit a solution!

I was also able to reproduce it locally; the reason I wasn't able to initially was because of some freak coincidence in the language setup on my local wiki (no need to go into further detail than that).

Why it happened:
In the fallback chain for both nb and no (this affected both language codes) is nn. Neither nb nor no have any $datePreferences set in their MessagesXx.php files, but, crucially, nn does, so LocalisationCache naturally used the fallback. Now, in addition to having $datePreferences set, nn is also special in that it – for reasons unbeknownst to me – is one of only four languages to use dmyt instead of dmy in its $dateFormats. The result of these two coincidences is that the $datePreferences in MessagesNn.php has an array including the date formats it expects, like dmyt both, and MessagesNb.php falls back to the nn date preferences array, but doesn't use the same date formats as it does. So the default preference we wanted to use (dmy) wasn't actually present in the list of preferences given from the fallback language.

Solution:
In the getJsDateFormats() function in Language.php, we had $styles = $this->getDatePreferences() ?: [ $this->getDefaultDateFormat() ];. I guess the first of these two can be empty in some cases, in which case it would fall back to the default date format. But in our case it wasn't empty, but it also didn't include the default date format. So the solution I found was what I put in the patch above.

And who knows, maybe there are other better solutions, like getting rid of the four uses of dmyt in favour of just dmy, but that's probably also more complicated than this.

Thanks for investigating and creating a patch! We'll get it reviewed.

Change #1135709 merged by jenkins-bot:

[mediawiki/core@master] Language::getJsDateFormats(): Always include default format in styles

https://gerrit.wikimedia.org/r/1135709

@Dreamy_Jazz I just wanted to confirm that this is what you are looking for, as seen in the gif. You can ignore the Vue error I have in the Console.

Test Result - Local

Status: ❓Need More Info
Environment: Mediawiki- Local: 1.44.0-alpha (964d7fd) 23:10, 14 April 2025
OS: macOS Sequoia 15.3.2
Browser: Chrome 134
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Test Case 1: Ensure Active Blocks Section Loads Correctly with Norwegian Bokmål Language

1. Set $wgUseCodexSpecialBlock = true; in LocalSettings.php.
2. Set $wgEnableMultiBlocks = true; in LocalSettings.php.
3. Navigate to Special:Block on beta.
4. Block a user using the form.
5. Append ?uselang=no to the URL and reload the page.
6. Scroll to and open the "Active blocks" section.
7. ❓ AC1: Confirm that the active block(s) appear correctly without any exception or error in the console.

In T391423#10741961, @GMikesell-WMF wrote:

@Dreamy_Jazz I just wanted to confirm that this is what you are looking for, as seen in the gif. You can ignore the Vue error I have in the Console.

Hi. I've been out on holiday (except for Thursday 17th) until today. Just getting to this now. Apologies for the delay.

It looks like the issue is fixed on my local wiki. The exception would also appear with the "Active blocks" table not appearing in the UI:

Based on your GIF, it also seems to work as intended on your local wiki.