Hmm, I wrongly assumed that clicking close discards all the unsaved translations. Actually, it doesn't in which case this is the right behavior.

In T47096#2584796, @Krinkle wrote:

E.g. a simple page like https://www.mediawiki.org/wiki/User:Scott is broken right now because someone localised "Interwiki redirect". It is not clear to me why <translate> can't simply return the default content by default instead of being rendered as literal text.

For the record, Wikimedia wikis recently removed English for all groups from TranslateBlacklist in https://gerrit.wikimedia.org/r/306015. That configuration should not be needed as Translate should do that check on it's own; it shouldn't need to depend on configuration).

I have written https://meta.wikimedia.org/wiki/User:Glaisher/globalSuppress.js as it's not easy to do this server-side without resolving the aforementioned issues. I have done some testing of it at beta cluster and it seems to work okay but do NOT use it yet because I'm not completely sure it would work properly in all cases. It would be nice if I could coordinate with a steward who is willing to help, preferably on IRC, so that we can make it ready for production use.

OK, I see it when I change my UI language to Italian. The code is working as expected. I am changing this to a site request.

"Help center" link on the sidebar links to https://commons.wikimedia.org/wiki/Special:MyLanguage/Help:Contents for me.

In T143531#2571415, @Unready wrote:

I think that's a statement about philosophy. Before the current change, action=purge as a GET would purge, and action=purge as a POST would purge. Now there's no such thing as action=purge as a GET, because the confirmation page turns it into a POST.

So this is a change to make implementation match philosophy. Okay, and there's no going back from that.

It's not a matter of the easiness or difficulty of the request. GET/POST distinction is going to be used for checking whether the request is a read-only and if so to route the request accordingly in a multi-datacenter setup. Your expectation about GET/POST is also wrong as GET is actually supposed to be retrieving data only not for modifying; it wasn't respected previously.

CentralNotice currently depends on the user being able to save to the CNBanner namespace's /en pages so doing this would partially break it at Meta because 'en' is blacklisted for all groups on Wikimedia. That blacklist entry shouldn't actually be needed and manual source page edits should actually be directly prevented on Translate but even then we would need to add exceptions for CNBanner.

This wasn't done just for the sake of making it difficult for users. There are actual valid technical reasons as stated on T135170 so it won't be reverted just because of it.

I had created https://meta.wikimedia.org/wiki/Special:AbuseFilter/125 and it seems to be working there. Since this requires another extension for working, I believe something needs to be implemented directly on the Translate extension before this task can be closed. But triaging as low since there is a mechanism to reduce these now.

Uh.. how did that happen??

In T143073#2556165, @Nikerabbit wrote:

git diff origin/wmf/1.28.0-wmf.3..origin/wmf/1.28.0-wmf.4 reveals no likely suspects. Timing might just be a coincidence.

Okay, I guess you meant <fieldset> not <input>. This would need to be patched directly on this page then because FormSpecialPage doesn't provide that by default.

If we already have known reports about this, it is likely that there are more unknown occurrences of this elsewhere too (due to lock waits, not just long queries). Having inconsistent states seem like a pretty severe issue to me. I have written a possible explanation at T141988#2519765. @aaron Is it possible for that to happen or is there another explanation? Seems like something that need to be fixed in the short term before major bugs arise from this.

In T138919#2415509, @Steinsplitter wrote:

The blue box schould be below the Rename global user. Currently it is directly in the <input> field.

Why was the comment removed? Is it not valid? Perhaps you are correct because I closed this based on an assumption, not after confirming. :)

Not a CA-specific bug. Closing as duplicate of T142755: Can't look for logs for Global rename script

• https://ho.wikipedia.org/wiki/Special:Log?user=Global_rename_script (using underscores)
• https://ho.wikipedia.org/wiki/Special:Log?user=Global%20rename%20script (using spaces)

Broken pages
An old version of this page is marked for translation, but the latest version cannot be marked for translation.
Test4 (remove from translation)

Probably because the job which updates it hasn't completed when Special:PageTranslation is rendered.

That URL is not correct. You should instead use https://en.wiktionary.org/wiki/natatorium?debug=1 (note the ? instead of &).
That module 'ext.uls.compactlinks' is from the ULS extension so a maintainer of that extension should probably look into it.

I'll note that it is now possible to exempt specific IPs (and users logged-in from those IPs) from having to submit captcha by listing the IP addresses or IP ranges at MediaWiki:Captcha-ip-whitelist on the wiki. I realize that it doesn't meet the requirements of this task because only sysops (and others who are allowed to edit interface pages) can edit these pages but at least it is better than how it was previously and I encourage organizers to make use of it (by requesting sysops to add the IPs there) for a better experience for participants.

Global abuse filters are cached indefinitely and it is invalidated whenever a global abuse filter is modified. However, there is a bug in the logic which is checked for when to invalidate the cache; it is only invalidated if the filter does have "global" set. As a result, it's not reliable in cases such as these (https://meta.wikimedia.org/wiki/Special:AbuseFilter/history/89) so we should change it to be invalidated also if the "global" flag was set previously. In the meantime, a steward should probably check the global flag in the filter editor (and remove it again, if you want) to invalidate the cache.

This was caused by https://gerrit.wikimedia.org/r/#/c/302987/

After this edits done with a FUZZY would mean the page would be updated with the source text.

I was able to reproduce the second issue and it has already been reported as T114592: A translatable subpage page should not be messed while moving subpages so I will close this task as it reports two already reported separate issues.

I was able to confirm this while testing another move-related patch today. This is actually quite a severe bug, imo, and would cause large scale disruption and lots of work for users if done on translatable pages with lots of translations so increasing priority.

Okay, these search results show that there are several gadgets which call $.cookie without registering it as a dependency in MediaWiki:Gadgets-definition. Please ask an administrator to add it as a dependency for those gadgets.

I don't see a reference to $.cookie in https://github.com/wikimedia/mediawiki-extensions-Cite/blob/master/modules/ext.cite.a11y.js Can you try checking whether that error appears again after clearing your browser cache and also please provide the errors shown in the console in debug mode. You can switch to debug mode by adding debug=1 to the URL (similar to action=purge).

I guess you meant https://meta.wikimedia.org/w/index.php?title=CNBanner:FR2014_translations-legal-us/pt&diff=9145183&oldid=9145115 not https://meta.wikimedia.org/w/index.php?title=CNBanner:FR2014_translations-legal-us/pt&oldid=8920101 ]]There are several days in between those edits in the description..

https://gerrit.wikimedia.org/r/#/c/303430/

It's happening again now on s7.

There was slave lag on Meta-Wiki (s7) causing writes to be locked for more than three minutes a little while ago. I suspect (but not completely sure) that it was also related to a global rename that was done at about the same time. https://meta.wikimedia.org/wiki/Special:CentralAuth/Derakhshan contains 7000+ edits on fawiki which is also s7. Probably worth more investigation.

During testing, I also noticed that it doesn't error for SpamBlacklist hits either.

OK, after looking at the code, I think this is what happened. MediaWiki starts the transaction with the first query. After that, the queries from User::saveSettings are issued but as it is not committed at this point, it doesn't block further code from being executed. Then the job queue insert code is executed where the jobs are sent to the Redis queue. After this, the log entry insert query is also issue and it is also sent to the IRC feed. But these queries are actually committed during preOutputCommit() where MediaWiki detects that the transaction is taking longer than the set time and so throws an exception aborting the DB transaction. However, since the jobs has already been sent to Redis and the RC entry sent to the IRC feed, they work okay as if the DB transaction wasn't aborted. I don't know for sure whether this is what actually happened since I am not very familiar with what happens during the lifetime of an MW request and also have made some assumptions about how they get executed but this seems likely.
So for atomicity, the expected behavior would be: 1) jobs should be removed from the queue if an exception was thrown after they have been sent or not sent at all if we know that something went wrong 2) the RC entry shouldn't also be sent to the IRC feed before everything is completed fine. And fix T63122: Timeout when sending translation notification (yet again) of course.

Note: The actual issue for the long duration of the submission request is tracked at T63122.

In T141988#2519156, @Nikerabbit wrote:

In T141988#2519082, @MarcoAurelio wrote:

The actual delivery is postponed to job queue, so I find it unlikely to be the issue here.