Please be advised, there is no consensus at nowiki for this change and earlier discussions has always "landed" on "remain at nowiki". The last big vote we did on this was in 2009 with a clear result for "stay at the no-prefix". Please see https://no.wikipedia.org/wiki/Wikipedia:Avstemninger/Prefiks for that vote. Since then nothing new has happened really and every new flare-up of "let's change no to nb" has been quenched:
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2011-35#no._vs._nb.
https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Norsk_(bokm%C3%A5l)

@Ottomata yeah they are there. Thank you.

Any chance for this to be expedited? At nowiki we are currently using these datasets for a local stats-service (https://tools.wmflabs.org/pagecount/) and the users are complaining (https://no.wikipedia.org/wiki/Wikipedia:Torget#Sidevisningsstatistikk)...

Could we perhaps get https://dumps.wikimedia.org/other/pageviews into /public/dumps/pageviews then?

Why was the task reprioritized to "low"? On what grounds? We have a legitimate need to get this fixed, and the old "workaround" was just that, a workaround and performed in 2011.

See T133606

Either through Recent Changes and unpatrolled: https://no.wikipedia.org/w/index.php?title=Spesial:Siste_endringer&hidepatrolled=1
Or through history-page: https://no.wikipedia.org/w/index.php?title=Topic:T2rujrgwa2a5qqsf&curid=0&action=history
Find a change and click on the timestamp for the revision:
https://no.wikipedia.org/w/index.php?title=Topic:T2rujrgwa2a5qqsf&topic_postId=t2s04jqjaa5uu3s7&topic_revId=t2s0pn3hvf8xtpo0&action=single-view
Click on "[merk denne siden som patruljert]" to patrol the page/change/revision:
https://no.wikipedia.org/w/index.php?title=Topic:T2rujrgwa2a5qqsf&action=markpatrolled&rcid=29231150
And get session error.

Any chance this will be prioritized any time soon? We have just implemented flow at no.wikipedia and still having this bug here one year later, is not a good sign!

Reported onwiki at https://no.wikipedia.org/wiki/Topic:T2sd1cyyqtwjwyc6

Sorry, my bad, this was of course a {{DEFAULTSORT:*}} from a template doubly-nested.

That doesn't seem to solve the practical problem at nowiki unless you also propose to replace all of the apostrophes in use at nowiki for the correct use cases. It's would also be nearly impossible to get the users to actually use these correctly unless they are readily available at their keyboards for both desktop and mobile versions.

See https://no.wikipedia.org/wiki/Wikipedia:Tinget#Linktrail_og_hvordan_vi_kan_skrive_lenker for community discussion about this change.

I have reintroduced the patch as proposed by P.Copp in 2011 as this seems to be a better solution to the problem. Please see T130451 for more justification.

This should be changed to use negative lookahead to avoid the problems, as in T29473 for ca and kaa linktrails:

I just did a quick check on the latest XML-dump for nowiki, found eight pages affected and fixed them. I also scanned frwiki just for fun and found 26 articles, see the list here: http://tools.wmflabs.org/pagecount/articles_with_missing_quotes-frwiki.html

Can we get some attention to this bug. This is a very irritating behaviour and discourages any new additions from norwegian users. The language dropdown also seems to the naked eye to be sorted in some strange way. Typing in the language works, but shouldn't be necessary.

Can confirm. Any changes made in the preferences are seemingly ignored. It also seems to be only at nowiki:

This removal has broken our user contribution report on nowiki which is enable as standard for all of our users. I see the removal was declined beforehand and "suddenly" removed one month afterwards?

Thanks for the notice. My DB's are possible to recover in case of a complete wipeout, but that would take several months to do. What is the issue with my DB's? Are they too big or too busy?

No. The wally period expired long ago and the issue has gone away...

The following shows the behaviour with patch set 8:

Examples from running:

I will admit, after thinking a bit more, I'll concede it's not necessarily wrong behaviour, but the code doesn't cover all cases anyway. These may be more of a "cosmetic" bug character:

Here it is, and it also fails at the first lower case for some as well as not taking into account sections:

$ git show
commit e56b4be99577e75019ac7b048635212ca0e61002
Merge: 69fe59e 97e9ac1
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date:   Sat Nov 28 14:01:18 2015 +0000

I have made a patch for this:

I have seen these as well.. Seems to be a german locale:

Same problem for my account. Last task run was 03:10.

I have put in some random sleeps (between 60 and 600 seconds) in between each time my importscript is called and implemented a lockfile-mechanism to only allow one instance to be active at a time. Hopefully this will ease the load on the DB-servers.

I could insert a sleep some places, but do you have any recommendation as to how long this should be?

There are six temporary import tasks running right now processing 6 months of pagecount data (at the very end now). There is a crontabbed task running every hour checking for new pagecount files and importing them if they exist.