“if we never create these URLs” – well, that’s another problem there: From the view URL, we do not show the page tools like What links here. (I don’t want to say it should link to /view/en/Special:Whatlinkshere/Z1, it probably should link to /wiki/Special:… anyway. Just saying.)

Redirecting to the Main Page is better than an exception, but… the whole behavior of that URL is strange. First, when being logged in with a non-English UI language, it does not redirect to the project main page, but to the (nonexisting) localized default main page name in the language. (E.g. for me, https://www.wikifunctions.org/view/en/Special:WhatLinksHere/Z802 redirects to https://www.wikifunctions.org/wiki/Hlavn%C3%AD_strana) When I tried to reproduce that, I went to https://www.wikifunctions.org/view/en/Special:WhatLinksHere/Z802?uselang=cs which… just shows the contents of Z802 directly? (As does https://www.wikifunctions.org/view/en/Special:WhatLinksHere/Z802?uselang=en, only the language differs… I guess there is an unsolved confusion between view/xx/... and ?uselang=yy there generally.)

//foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Privacy_policy does not work, as privacy policy translations do not generally live there. wmf:Template:PrivacyLang points to Meta for all translations.

Yep, purge helped for File:Druhý Kirchhoffův zákon.png which I had reported at T333679. Thanks!

Working well… but only in English; all remaining languages wanting to use this need to add it individually to their respective MediaWiki:Search-summary/xx as well…

@Vojtech.dostal Using CSS? No way; the link is added to the page whenever there are no interlanguage links on the page, without further regard to the content of the (possibly) linked item. Even the linking dialog seems not to load the content of the referenced entities until the user presses the button. After that, the dialog could/should check the items and reject to merge them when there are any statements. (Or… at least… ask for explicit confirmation? Maybe not, doing the merge directly on Wikidata would be easier/more comfortable in that case, anyway.)

The links were correctly updated and seem to be correct now, thanks!

The fix seems to work fine in production. Should I close this as fixed, or is it going through some process on WMF side?

Oh, great, that at least explains why I’m the first the report and fix this.

In T299828#7653095, @Michael wrote:

Purging some of the pages?

Purging the pages in mkwiki should always fix these things.

please let me know if you want me to force refresh this specific item.

Oh, sure, I did not want to imply it should just be removed. It was only an observation intended to help with localizing the bug. (Even though probably unnecessary/self-evident, I guess, especially in this task where the original commit introducing the problem has been correctly identified already.)

Yep, the claims disappeared, thanks! The timestamps remain but I don’t care about those and if you say this is OK, no problem for me. (I guess this task can be closed as resolved?)

That’s not a bug in the software. The user’s talk page is just too long and complex, it exceeds the maximum allowed template include size (see e.g. Wikipedia:Template limits). There are bigger problems on the page because of that, see all those [[Template:Autotranslate]] links? Those should be messages for the user instead of the useless link. The user needs to reduce the size of his talkpage by archiving it (cf. the guide at the top of Category:User talk pages where template include size is exceeded).

Just copying a note from my duplicate bug:

And what is the problem? That’s the point of the {{PLURAL:}} construction, isn’t it?

Another problematic expression cached as a problem is x \in \mathbb{C}, see https://test.wikipedia.org/wiki/Cached_deprecated_math, any change (e.g. to y \in \mathbb{C}) makes the deprecation to disappear.

Well, yes, for Czech, the subscription confirmation e-mail seems to be sent correctly, now. But as I said above, it is a problem for all languages using non-utf8 encoding in Mailman. E.g. Polish is still broken (“Pro�ba o potwierdzenie zapisania si� na list�”).

Yes, they would break because they are in the wrong encoding.

Those files are provided by the debian package, and are not considered convfiguration files. This would mean that every time we update the debian package from the distro, those will get overwritten until the next puppet run; I would prefer not to go down that path, or down the path of rebuilding the package ourselves.

+1 from me. I think it should not be worse than the current state. :-) (Read: It might break something but that thing is probably already broken now.) But if there is a Mailman expert (definitely not me), please stand up!

This is unfortunate, especially combined with the fact the mobile app displays only the local enwiki description (even when there is none, displaying “+ ADD ARTICLE DESCRIPTION”!), but the edit goes to Wikidata, overwriting the already existing description with the newly added (which is usually worse, obviously). And… the description is still “+ ADD ARTICLE DESCRIPTION” after the edit.

The title of this issue undersells the problem quite a bit. In other words, mobile recent changes and watchlist are basically unusable right now, since all (diff) links are broken (leading to the full view instead of the diff).

So… this is a duplicate of my ancient T14495, right? :-)

And screenshots of e.g. the enwiki example:

OK, but this happens all the time to me (I was surprised not to find a bug already reported), so I guess it should not be too difficult to come with some more examples:

• https://cs.m.wikipedia.org/wiki/Special:MobileDiff/18085597 (missing space at the start of the red del marker “a[ ]kladnými”)
• https://cs.m.wikipedia.org/wiki/Special:MobileDiff/18093137 (missing space at the start of the green ins marker at “Konstantinopoli.[ ]Bratři”)
• https://en.m.wikipedia.org/wiki/Special:MobileDiff/135792555 (just a random diff: missing space at “in[ ]late”)

…

I found this bug only after reducing my broken query until only this was left:

SELECT (MIN(?name) AS ?name) WHERE {
}

Also, I noticed COUNT and SAMPLE work fine, while the other aggregate functions do not support this aliasing. If it is an error, a better error message would definitely come handy.

In T221097#5118415, @Urbanecm wrote:

Possible solutions:

• decline this task

Wat.

OK, I have fixed the problem for cs by purging https://www.wikidata.org/wiki/MediaWiki:Mainpage/cs but that’s not a great solution…

Specifically, the problem is with those two tiles: 1111/694, 1112/694.

Possibly related? We have found a similar problem with missing P6736 data: Q38192330 has P6736 (since 2019-07-03), but it cannot be found using WQS.

Once again, this solved itself by purging the page, probably just a cached version of the broken state.

Test Wikidata works fine for me, the broken display disappeared on purge.

I just reported T227814.

Came here with the same problem, and indeed, uBlock Origin blocks fingerprint.js as well.

I’ve had the same problem, turned out some ad-/privacy-blockers block the loading of fingerprint.js, see also T86799. After adding an exception for wikidata.org to uBlock Origin I use, everything works fine.

Thanks for the clarification!

@Ammarpad, no, I don’t think so. That task shows a screenshot with a mismatch of the displayed badge and the detail. That works fine for me. My problem is that the mark-as-read is ignored, and the notification still shows as a new one.

D’oh! I was wondering if I am the only one bothered by the current behavior, as I was unable to find any issue. So after a long time, I decided to offer a patch. But the bug has been there for half a year?!? No idea how I was able not to find it. Sorry for the duplicate and thanks for the merge.

Well, it is different now. Arguably better, but not great either. It seems when you remove all text from a sitelink (and the Publish button gets disabled), the trashcan icon for the cleared sitelink gets disabled as well. So that saves you from the dead end reported in this bug. However, I don’t see why the trashcan icon is disabled; when a user does not know the “proper” way to remove a sitelink is to click the trashcan icon and removes all text from the sitelink as the first step, why disallow clicking on the trashcan to remove the whole sitelink row? Note that using the workaround from the original report (write anything into the “new project” field and remove it), the Publish link will get enabled even with an empty sitelink field, and by publishing, the sitelink gets removed correctly.

In T129731#3757470, @MtDu wrote:

In T129731#3270978, @Mormegil wrote:

Well, the message directly references the user (“user "$2"”), who could obviously be he or she (even in English, you have e.g. actor and actress, in other languages, this is the basic case for (almost) all words). That is quite a basic case of “genderization needed”.

How so? Isn't user a generic term, gender neutral, and $2 the username of the user? Seems like this is an invalid task. Can you check on this @D3r1ck01 because if it's invalid, we need to remove it from Google-Code-in-2017

Right. Also, I came here to report a bug/request which would be, I guess, solved by this one: AFAICT, if I remove an optional permission to an application, but come back later and the application asks to reauthorize (reauthenticate, really), the permission is automatically re-added and there is no way to prevent it in the login dialog. I need to approve the application, which re-adds the permission and redirects me to the application, then manually go to Special:OAuthManageMyGrants and remove the permission again.

In T129731#3183925, @TerraCodes wrote:

Is GENDER support needed? I can't see a way that it is needed.

Right, C: was used as a convention for hand-created redirects into the category namespace, but it never was a category namespace alias (IIANM).

On enwiki, c: is an interwiki linking prefix to link to Wikimedia Commons. Therefore, page titles cannot start with such a prefix at all, there are no pages on enwiki starting with “C:”. It is not (and never was) a shortcut redirect to the Category namespace. There is a convention of using CAT: as a shortcut to redirect to categories, and there are quite a lot of those.

What about just something like “All search results for foobar”?

There is a much better workaround than wrapping into a <span>: Just place a <nowiki/> before the <indicator> or after the </indicator>. Example usages:

• en:Template:Top icon
• fr:Template:Icône de titre

OK, I’ll try to be very specific:

I thought this behavior could be fixed by having the .column-break-inside-avoid moved from .mw-category .mw-category-group li to .CategoryTreeItem. (With the complication of the latter being defined in the CategoryTree extension, while the former in generic MediaWiki, therefore, we would need to keep the current behavior in MW core, but override it in the extension.)

@Schnark: I see… if ( document.documentMode === 9 ) kinda explains why the bug appears _only_ in IE9 mode, but not in IE10 nor IE8.

I am able to reproduce this behavior on cswiki using IE11 with developer toolbar and IE9 emulation: