Now I am also seeing:

Function: CheckUserHooks::updateCheckUserData
Error: 1406 Data too long for column 'cuc_actiontext' at row 1

I'm not sure it's possible to automatically figure out the correct action with regards to line breaking here.

Using this input on Special:ExpandTemplates with Pi as page name:

{{#property:P1181}}
{{#statements:P1181}}
{{formatnum:{{#property:P1181}}}}

Your bug report is missing a test case.

Thanks! A bunch of those involve CX1 which we would prefer not to touch at all until it is removed completely.

I'm updating README and the wiki page.

No updates are necessary to handle the new format. I have marked the code for removal once backwards compatibility is no longer required.

FYI https://translatewiki.net/w/i.php?title=Special:SearchTranslations&match=all&query=Cancelar+suscripci%C3%B3n&group=phabricator&grouppath=phabricator

@Krinkle Umm, can it just be as simple as en falling out of $this->cache due to LRU mechanism, and $this->loadedLanguages['en'] still being true, unaware of this fact. This is likely to happen if there are a lot of cache misses, because MapCacheLRU::has does not ping. If it called load unconditionally, it would continuously ping and keep en in the cache.

I added some additional debugging:

diff --git a/includes/cache/MessageCache.php b/includes/cache/MessageCache.php
index 6272723..7d0f51a 100644
--- a/includes/cache/MessageCache.php
+++ b/includes/cache/MessageCache.php
@@ -454,9 +454,17 @@ class MessageCache {

I think we need additional debugging information to drill down where the time is spent.

There were a couple of instances of [2019-09-12 06:38:34] MessageCacheError.INFO: MessageCache::load: Failed to load hr {"private":false} [] but it doesn't seem to explain these errors. Also no callers on enable/disable.

We are on it :)

I enabled MessageCacheError logging on Mon Sep 9 11:02:37 2019 +0200. There is nothing in the logs. This error last appeared [2019-09-11 15:13:17]. I double checked that I didn't misconfigure anything. Maybe I should add logging if MessageCache::disable is getting called.

Some concerns have been raised that reducing the number of modules goes against making reusable code.

Documentation for this is a bit hard to find (T232566: $wgResourceModules documentation is incomplete), but there are examples to copy too.

Yep, no longer appearing in logs.

Yes.

Do you have an example of a project that uses plurals in Python?

@Urhixidur This task is about MediaWiki. Issues with X'tools should be handled separately in an appropriate place. The message you linked is not in use anywhere. We keep old messages around because it is more hassle to remove them.

That's already the case: https://translatewiki.net/wiki/Special:Translations?message=Size-kilobytes&namespace=8

With regards to mDisable being true:

• $wgUseDatabaseMessages is certainly true, so mDisable should not be set true in the constructor line 155. I could only find one place where MessageCache is constructed, in service wiring.
• If loading fails for some reason, it might be disabled on line 356. If this is the case, it should be apparent from MessageCacheError log channel. I can't find anything in Logstash, so this does not seem to be the case in production?? In translatewiki.net, we don't have logging for that channel. I'll enable it.
• Something could also call MessageCache::disable, but as non-static method it is hard to search in code search.

I was thinking what similar tags already exist. Wikimedia-production-error is very similar. If we use that pattern, it would be #translatewiki.net-production-error.

Why would you introduce new messages? Then you would need to update call callers separately. They are already documented to use base 2 so they are just using the wrong units.

Why has this been languishing for over three years?

In my experience, in Finnish the use of checkmark to mean wrong is limited to school exams. There is hardly any chance for confusion as people are used to seeing the checkmark used as affirmative symbol all over the places.

fwiw Language-Team says that MediaWiki-Internationalization is "Passive maintenance or unsupported". That means only UBN! tickets will be looked at if even noticed.

Did we have another task for generic support of limiting the validator only to certain keys? I can't find such one.

Yeah two tags. And naming is hard.

I would like to keep the work we translatewiki.net folks do separate from the issues we notice in "upstream" code while operating a MediaWiki instance.

This seems to be resolved.

This notice is not currently appearing in translatewiki.net logs.

To be clear, I'm looking for advice what's the best way to track these issues and help to implement that.

Looks like this has been fixed in the meanwhile.

This notice is not currently present in translatewiki.net logs that go back about one month.

I'm not sure if the merged patch was supposed to fix this, but I am still seeing the error with slightly changed line numbers:

[04-Sep-2019 12:54:55 UTC] PHP Fatal error:  Uncaught Wikimedia\Rdbms\DBUnexpectedError: Wikimedia\Rdbms\Database::close: mass commit/rollback of peer transaction required (DBO_TRX set) in /srv/mediawiki/tags/2019-09-04_12:36:29/includes/libs/rdbms/database/Database.php:888
Stack trace:
#0 /srv/mediawiki/tags/2019-09-04_12:36:29/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1517): Wikimedia\Rdbms\Database->close()
#1 /srv/mediawiki/tags/2019-09-04_12:36:29/includes/libs/rdbms/loadbalancer/LoadBalancer.php(2085): Wikimedia\Rdbms\LoadBalancer->Wikimedia\Rdbms\{closure}(Object(Wikimedia\Rdbms\DatabaseMysqli))
#2 /srv/mediawiki/tags/2019-09-04_12:36:29/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1518): Wikimedia\Rdbms\LoadBalancer->forEachOpenConnection(Object(Closure))
#3 /srv/mediawiki/tags/2019-09-04_12:36:29/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1502): Wikimedia\Rdbms\LoadBalancer->closeAll()
#4 /srv/mediawiki/tags/2019-09-04_12:36:29/includes/libs/rdbms/lbfactory/LBFactory.php(235): Wikimedia\Rdbms\LoadBalancer->disable()
#5 /srv/ in /srv/mediawiki/tags/2019-09-04_12:36:29/includes/libs/rdbms/database/Database.php on line 888

Good catch. The parameter needs additional escaping. Should be simple to fix once you find the place (is it on PHP side or JavaScript side).

You are still calling MessageIndexRebuildJob->run during user request, that is super slow. It would be better to defer it to the jobqueue.

Will report back after deployment tomorrow Wednesday.

You need access to LocalSettings.php`. Using require_once "$IP/extensions/Translate/Translate.php"; should cause a deprecation notice to appear in the error log. Using wfLoadExtension( 'Translate' ) should not.

The suggested languages section sometimes gives languages that it shouldn't. That's T216342: "ʔucināguci" in "Suggested languages" section cannot be selected and has tooltip "undefined"

The trace is the same. The small difference in the message is likely hhvm vs. php difference.

Assuming you mean wmf deployment branches... this bug has existed at least for 6 months. I see no reason to hurry with backports.

Yes, dupe, I was just demonstrating it :D

Probably... it also doesn't allow to change priority.

Looks a dupe to me.

@abi_ This seems quite similar to the issue with the message index, just a different table.

The code is roughly:

I don't seem to be able to change the priority of this task?

This just looks like the same injection thing hitting a new API module. We'll fix it, but suggesting that this doesn't need to block the train.

Doesn't seem to be happening currently, on quick look. But I think the test was changed on T231074: Selenium tests will fail on gate&submit recently.

I see bunch of files in i18n and translations. Which files should be set up for translation? Also, I don't see mention of which license the repository is using. It would be helpful to have the basic information needed for setup in the summary of this ticket.

It's the IP of the database server.

Command line scripts do not have any memory limit unless specified separately.

Hmm I see, so we have some tests that will use the title from parser if it gives one.

Trying to correlate with access logs:

/w/load.php?lang=be-tarask&modules=ext.echo.styles.badge%7Cext.translate.statstable%2Ctabgroup%7Cext.uls.pt%7Cjquery.makeCollapsible.styles%7Cmediawiki.helplink%7Cmediawiki.htmlform.ooui.styles%7Cmediawiki.htmlform.styles%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.widgets.styles%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui.styles.icons-alerts%2Cindicators%7Cskins.vector.styles&only=styles&skin=vector

With following debugging:

					if ( $this->writesOrCallbacksPending() ) {
						error_log( json_encode( [
							'MAOE',
							$this->trxLevel(),
							$this->trxDoneWrites,
							$this->trxIdleCallbacks,
							$this->trxPreCommitCallbacks,
							$this->trxEndCallbacks,
							$this->trxSectionCancelCallbacks
						] ) );
						$exception = new DBUnexpectedError(
							$this,
							__METHOD__ .
							": mass commit/rollback of peer transaction required (DBO_TRX set)"
						);
					}