@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.

In T262967#6536922, @Mahir256 wrote:

I must agree with Bodhi here that having a code for sat-olck is still necessary as it is not guaranteed that Santali speakers outside of India will be able to read it. "Official" in India need not mean "official" in the other countries in which it is spoken, as a closer read of the article on the language should indicate. Besides, we already have separate language codes for a particular language and the scripts in which it is written, including the "default" (such as kk and kk-arab, kk-cyrl, kk-latn, or iu and ike-cans, ike-latn, and similarly for ks, ku, tg, and ug) so I don't see a problem with continuing this trend in the interest of preventing ambiguity.

With the exception of sat-Olck (for the reasons @Mbch331 mentions) these all make sense to me, as long as there is use for them (and I trust @Bodhisattwa knows that best). So that's a "go" from me.

Thanks for the investigation, @Nikki! Yeah, I was confused when I saw this task because they *should* be available already. So if you have any idea how to fix it @Lydia_Pintscher, a fix would be appreciated!

By not being on the Norwegian Wikipedia. ;)

Thank you very much, @ABorbaWMF , @Dbrant and others. The same problem is still present on *.m.wikipedia.org though – should that be filed as a separate bug? This language code discrepancy is fixed for desktop with $wgInterlanguageLinkCodeMap in InitialiseSettings.php. Ideally the apps & mobile website should look up that setting in order to not duplicate these things over several codebases.

FYI, this is implemented on the Korean Wikipedia with a gadget: https://ko.wikipedia.org/wiki/%EB%AF%B8%EB%94%94%EC%96%B4%EC%9C%84%ED%82%A4:Gadget-CollapsibleSidebar.js
Rather sleek, IMO.

@Ladsgroup I see in T52864 that you're involved in upgrading the lists. Do you have any idea what's causing this?

Hi @Aklapper, sorry for not following the correct procedure – I did skim through those pages first, but apparently not thoroughly enough (since I missed the fact that tags ought to be discussed first).

These seem reasonable to me, but I'd like to see if @Amire80 has any comments.

We have created the Phabricator tag Language codes to track this (and other language code isuses), instead of using this unwieldy task. I have updated the instructions for requesting languages codes for monolingual text at Wikidata, and will add the instructions from this task to the project description.