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:

In T112349#1645213, @Smalyshev wrote:

That wouldn't work e.g. for Russian. There's pretty much no way I can think of to make a template that uses nominative language name (i.e. "русский" or "русский язык") that would not sound extremely awkward.

This is hardly the first case this exact problem appeared in MediaWiki. And while solving it perfectly this time (including the declension mentioned above) would be nice to have, going with something simple (again) would be acceptable, I guess.

I went to a foreign wiki I have never visited before and as the first step after my account was autocreated there, I went to [[Special:Preferences]] to change the UI language to something I can cope with. With the JS still loading and the page displayed as one big list instead of the tabbed interface, I changed the language; then the JS finished loading and the display switched to a nice tabbed interface… with the Save button disabled, since I modified the setting prior to the script run. So I needed to change something there and back again in order to be able to save the language setting.

I have found the cause: The problem is that edits through API (that is the difference, @Catrope re your comment) pass through the AbuseFilter twice: The first time, via the onAPIEditBeforeSave hook, the second time via the onEditFilterMergedContent hook. Only the second hooks gets the post-merged content.

@Oriodrim: Yep, I guessed the same in the linked dupe, AbuseFilter seems to see the pre-automerged version of edits from VisualEditor.

(I am not sure if I should open another bug, reopen this, or what.)

What exactly is the long-standing behavior? <indicator> is a completely new tag, it has no long-standing behavior. How many long-standing XML-type tags are supposed to have empty output (and usually expected to be on a separate line)? Definitely not <references> – empty references are a marginal case.

Not sure how index got into the list; the only index message translatewiki.net knows about is a message from an obscure/unmantained IndexFunction extension.

OK, as this seems to have stalled somehow (are we the only wiki to use this? or are we the only wiki to have noticed the redundant whitespace caused by this?), I have used the workaround on cswiki to wrap all <indicator> uses into (otherwise useless) <span>s.

In T76234#794544, @MZMcBride wrote: