In T310961#9271415, @Stashbot wrote:

hiwikisource: Adjust width-height ratio of logo to fix display issue (T310961)

It seems that Modern is the only skin that separates the page header outside of the "content area". For the same reason, ContentTranslation's buttons on contribution pages appear on top of other toolbars:

In T358541#9598534, @1234qwer1234qwer4 wrote:

The query in the task description now throws a "500: Internal Server Error" for me.

The query in the task description now throws a "500: Internal Server Error" for me.

@Umherirrender I'm not familiar with antispoof, so I requested this mainly for AbuseFilter, see cases like https://en.wikipedia.org/wiki/Special:Contributions/ClearHarmony. AbuseFilter already normalises a lot of Cyrillic letters to Latin ones, so I don't really see the problem here.

See T311365 for a newer request regarding \operatorname*.

In T229992#9303513, @Xaosflux wrote:

Does that mean spelling variants would need to be recreated on every WMF wiki? -- not if they are localized, only if they are on that tiny list coming from external source

In T229992#9303385, @Xaosflux wrote:

Well, that's annoying - suppose we would need a highly advertised request to avoid this by having WMF wiki's "not accept en/xxx variants from translatewiki" anymore?

In T346187#9187371, @Xaosflux wrote:

Currently declined the stewards onwiki request; forking the wikiset just to add this for one project isn't the best course of action; we are of course open to a community discussion about adding the translation admin permissions to the entire GS opt-in wikiset; please open a discussion on meta-wiki if that is desired.

The API allows to view authors of deleted revisions (and page creations are logged on most wikis as well), so is the connection between separate "temporary accounts" (without disclosing the IP address itself), which could result from nuking pages from all such accounts simultaneously, an intentional consequence?

Unless that is yet to be deployed, no, revision deletion is still not possible.

Is there local consensus from the individual wikis or just the discussion on Meta? Clearly the contingent of people who visit Meta at all is very biased towards global things.

Unrelated to title blacklist as made clear in the title.

Oh, sorry, my bad. There's been a lot of redundant reports lately and I saw the HY000 error which had appeared in some other reports too, but thanks for fixing my mistake.

This is not XTools-specific and XTools can't fix this.

Works for me now; looks like this is resolved.

Thanks! I think Ӽӽ is still missing too. Also since you added ѿ you might as well add ѡ, and Ѽ should at least be mapped to Ѡ if that should not be mapped to W as well.

Cyrillic and Greek seem reasonable since they are quite closely related (though indeed it may be confusing for letters like Г or Ђ which have a completely different etymology -- for Г I've at least seen it being abused though). In fact, Cyrillic has quite a few more additions worth looking into, such as Ѻѻ for O or Ҏҏ for P. Also, it looks like ґ is normalised to Ґ; I wonder why this isn't leading to the R set the letter Г is pointing at.

thanks a lot for your help @Umherirrender! The ɕ character should be in the C equivset for sure since it is literally the letter c with a diacritic, and ѓӷ (plus their capital forms) should be in the R equivset considering that the letter г is. The rest probably needs some more investigation (ligatures appear to be sort of a difficult case in general).

This is about https://www.wikidata.org/wiki/MediaWiki:Gadget-Merge.js. However, I do not understand what is meant by a

Not sure if this is related, but in Firefox, the checkbox and buttons are accessible with the tab key, but hitting enter on the checkbox just confirms the login without changing the state of the checkbox.

@rook Both tasks are by me. The title (and if not, the description with the relevant links) should be clear enough in stating that this one is about the Wikidata sitelink change reflecting a page move while the other is about the redirect created when it is not suppressed in the move.

Note: namespace should be called "Ков", see https://inh.wikipedia.org/wiki/ОагӀат:Ковнаш.

In T31216#1898651, @Krenair wrote:

In T31216#1894107, @Trijnstel wrote:

Is this only about a suppression where one deletes+suppress a page at the same time?

Don't think so.

Another similar one, if it helps: https://de.wikipedia.org/w/index.php?search="Essays%2C+Reden%2C+Propagandaschriften+u.+a."

Sure, done.

Just noting that Special:GlobalBlockList has a similar issue.

There are multiple issues highlighted in this report: One is deleting a translation page without its units (what is stated in the title); the other is restoring translation pages, which is an unrelated issue affecting restoration of pages deleted by FuzzyBot in the same way and should be handled with a separate ticket (and is arguably more important since it actually makes the workflow with the translation extension so much harder, requiring you to temporarily unmark the whole page from translation first, as outlined here).

The bug I saw here was mostly your second point, though I'm pretty sure I have sent thanks for user rights log entries before (third point).

I reported this just after submitting this search query for the first time and realising it fails.

@Urbanecm Are you sure about this? This task is about the tool failing for a specific query, possibly due to the emoji/Unicode plane 1 character, while T316420 seems to be a more recent issue.

srwikisource has been fixed (thanks). hiwikisource is still to be handled, and I have also found https://eu.wikisource.org/, https://be.wikisource.org/, and https://cs.wikisource.org/ with this issue.

FWIW this has been existing since 2018 at https://www.wikidata.org/wiki/User:Mat%C4%9Bj_Such%C3%A1nek/patrolRevisions.js. Not sure the subtasks are arranged appropriately; I think this task can be closed.

I've been using that feed for at least a year without any problems. This started to occur about when this bug was reported.

Well, my feed is still timing out: https://meta.wikimedia.org/w/index.php?userExpLevel=unregistered%3Bnewcomer&hidebots=1&translations=filter&hidecategorization=1&hideWikibase=1&limit=500&days=30&reviewStatus__manual_color=c2&changeType__hidelog_color=c3&tagfilter__mw-reverted_color=c1&title=Special:RecentChanges&urlversion=2

In T311360#8048895, @Ladsgroup wrote:

This is fixed now.

Don't know about anything orthographic, but this symbol is way too common in all kinds of texts to make this change at this point. Search for insource:/`/ on a reasonably big wiki and you'll get thousands of results (despite a timeout).

In T311360#8027523, @Nikerabbit wrote:

I assume MediaWiki-extensions-Translate was tagged because of this, but there is no code that ignores errors there. My guess is that it just happens to be the next query executed after the query that was interrupted by the timeout and that Special:RecentChanges is the one ignoring that error.

Note that this is also a problem on https://hi.wikisource.org/.

Note that said "comment box" appears instead of the "diff screen" when the revision text is hidden. As a sort of workaround for "checking what the hidden edit summary contained", you can click the "(change visibility)" link, which will display hidden usernames and summaries too (this can also be used for accessing deleted log entries).

Not just the one mentioned at T172268? Ping @Urbanecm

Ok, I uploaded the new version.

Thanks. Your file appears to be 135x150; could that still cause issues?