@bd808 So sorry, I gave you the wrong ID. The right one is -1001475972123.

Thanks! The group ID is -1001184987195.

In T284277#7150108, @Aklapper wrote:

In T284277#7133637, @jhsoby wrote:

I remember we had this exact problem on nowiki as well. I tried a lot of things, but I don't remember if I did anything to solve it

Could be T250807: Dates in citations on Special:CiteThisPage are in <p> and hence create unneeded and ugly linebreaks and T193267: The <citation> tag is not being parsed on Special:CiteThisPage on some projects?

I agree this is a good idea, I have to admit that we (langcom) are often a bottleneck in this – more often than I would like. So what if we say something like, if nobody hears from Langcom within 2 weeks of a request being posted, a request can be assumed to be ok? What do you think, @Amire80? It would also be nice if we could bring some more langcom people into the loop on these tasks, so that it doesn't all rely on Amir and me – we are both fathers with full-time jobs, so many times these tasks unfortunately don't make it to the top of the pile on a given day.

I remember we had this exact problem on nowiki as well. I tried a lot of things, but I don't remember if I did anything to solve it – but it is working now. The last thing I did may be relevant to try for iswiki too, it could be that that was what solved it. Or it could be that the parsing is delayed for some reason? Either way, worth a try at least.

The script is finished (well, as finished as these things get), and one can use it on Wikidata by including this in common.js:

mw.loader.load( "//www.wikidata.org/w/index.php?title=User:Jon_Harald_Søby/addSenseImage.js&action=raw&ctype=text/javascript" );

Is this task the reason there are no code samples in the "Dialog" tab in the demos (that's what I came to Phab to report, but remembered to search first)?

Updated description to reflect that I changed my approach from a web-based tool to a user script instead.

Sorry, didn't see your reply until now, @ppelberg. Yes, mainly the fact that I'm used to it (in fact so much so that I'm still pressing it by mistake even after actively using DiscussionTools since it became available).

Enabling the publish button sooner would help a lot – if it takes a bit longer to save, that's perfectly fine.

Like in T279554, I think this one is a "go", but would like to hear from @Amire80 too.

I think that argumentation makes perfect sense, and the benefits of en-us as a lexeme language seem very clear. So that's a "go" from me, but I would like to double-check with @Amire80 just in case.

Seems good to me.

No problem.

@Mbch331 Sure!

Sure, I don't see why not.

@Mbch331 Sure!

@Inductiveload I don't see anything in the patch on T271710 that touches $wgTemplateStylesNamespaces…?

To solve this specific issue on enwiki, you could change the en message to: {{{1|$1}}} and the en-gb message to {{MediaWiki:Blockipsuccesstext|$1}}.

OK for me.

Looks OK to me.

OK for me.

Don't see why not.

OK for me.

Looks good to me.

Seems fine to me.

@AMuigai, awesome, thanks!

@Tsevener I just tested the KaiOS app simulator, and it appears that this exact problem is happening there too. Would you mind notifying the team working on that about this task and how you fixed it?

Just to add a small data point to this: I recently came across this issue because I used the CSS class "header" in TemplateStyles for the Arctic Knot Conference pages on Meta, but it would not do what I needed it to on mobile, even though I thought I did nothing wrong. It turned out that since the .header class from had a height attribute and my class didn't, Minerva's .header heightof course took precedence.

Since the code change in T271710 applies to all wikis using ProofreadPage, shouldn't this change be made for all Wikisources (and not just English)?

Aah, I thought it sounded familiar! I thought it might be a related language, but didn't check properly. Good catch!

Yes, this should be fine.

This can be added, no problem.

No issues as far as I can tell.

In T272193#6894359, @Tsevener wrote:

First steps for iOS dev(s):

We need to replace the sitematrixURL in WikipediaLanguageCommandLineUtilityAPI.swift with https://en.wikipedia.org/w/api.php?action=sitematrix&smsiteprop=url%7Cdbname%7Ccode%7Csitename%7Clang&formatversion=2&format=json" and use the lang property for populating languageName instead of code. lang has the nb distinction that we need. We'll also probably need to keep track of url from this response separately within Wikipedia.swift, and use that in MWKLanguageLink's siteURL computed property.

In T276816#6897209, @Trizek-WMF wrote:

@jhsoby, thank you for working on the translation. I will soon inform your community about this upcoming change. In the meantime, feel free to suggest better links! :)

Mr. Puigdemont is also (supposedly) the second most read article in the Norwegian Nynorsk Wikipedia, the third most read in Icelandic, third most read in Afrikaans, second most read in Alemannic, most read in Western Armenian … and the list goes on and on and on (probably), I stopped checking there.

@TheDJ any update? We recently implemented geomask in our main map module on the Norwegian Bokmål Wikipedia, and the lack of inner rings is very noticeable for municipalities in Viken, where Oslo should be excluded. See e.g. https://no.wikipedia.org/wiki/Nesodden (open the map in full screen to see the full geomask).

@Tsevener Any update? :-)

Indeed! I didn't notice this task until now, accidentally.

In T274557#6834521, @Jdlrobson wrote:

This issue appears to be getting worse as broken grphs are copied and pasted to other Covid articles.

FWIW, I made a small Javascript that does exactly this, here: https://www.wikidata.org/wiki/User:Jon_Harald_S%C3%B8by/jsonredirect.js

Probably the same as T272193, yeah?

"nb" is in that list. I don't have any iOS devices, so I can't test, but isn't Norwegian Bokmål in the language option list?

Import from the Incubator is done.

That is the way it should be, o is the year the current week belongs to (and we're still in week 53 of 2020 until Monday).

In T268410#6694683, @Aklapper wrote:

@Kaleem_Bhatti: This task is about creating a website; see the topic. This task is not about importing stuff. Please refer to other places instead. Thanks a lot! :)

All content has been imported from the Incubator.

Import from Incubator done.

Hi @KuboF, we are usually able to do the imports the same day. However, this time it's a bit special, since 5 wikis will be created at the same time (and we are only 2 people doing the imports), so it might take a bit longer. But I'm pretty sure it should be imported and ready for editing by the end of Wednesday (so the day after the wiki is created).

@hnowlan Sorry if this is the wrong place to ask, but do you know why lower zoom levels haven't been updated yet? On January 1st, 2020, a lot of counties and municipalities in Norway merged. At zoom levels 10 and higher, they appear correctly:

Thanks @CptViraj!

Adding the tag Wikimedia-production-error , though I'm not sure it is a good fit since this is not an error message per se, but it does affect production wiki(s).

I don't have any problems with this, but would like to hear what @Amire80 and @MF-Warburg have to say just in case.

I completely forgot that non is already available for monolingual. I think @Mbch331's solution with adding non-runr and leave non as it is (i.e. =non-latn) is the best approach.

I would prefer to have non-latn and non-runr to just non.