Thanks!!! Do you know which production wiki(s) Special:LanguageStats is enabled on?

Special: LanguageStats is enabled for those regards proof wiki of test.wikipedia and test.wikidata, wiki for the other instead is enabled on Meta-Wiki Wikispecies Wikidata MediaWiki Incubator WikimaniaYEAR Test.wikipedia then I do not know if it is in other

Not date-specific task. Adding parent project.

Same problem happened to me while trying to rebuild the translation memories index for testwiki.

Could it be that the new version of MediaWiki is incompatible with the extension?

I made tests and found out that the problem is not only on that page but there is also an error that prevents the translation of the pages that is when translate does not save you and shows this error:

Error saving the translation: This namespace is reserved for content page translations. The page you are trying to edit does not Seem to Correspond any page marked for translation.

The problem is only the translation of the messages because it allows me to point out the pages for translation without problems.

Ex: https://test.wikipedia.org/wiki/Wikipedia:Test_translation and https://test.wikipedia.org/wiki/User:Samuele2002/sandbox

This problem is more serious than you think. First you should see if the errors are caused by an incompatibility issue with the new version, and if you find and fix errors, or if the cause is the same extension (but in other wiki works perfectly in all aspects even those reserved administrators of the translations) still have to find the problem because if you were to also report in the wiki main (all except metalinguistice wiki beta.wikiversity [am cerdando to convince the other users of the wiki to install it] can translate the extension )would be big trouble that would send haywire all over the pages of the translation process.

This problem is more serious than you think. First you should see if the errors are caused by an incompatibility issue with the new version, and if you find and fix errors, or if the cause is the same extension (but in other wiki works perfectly in all aspects even those reserved administrators of the translations) still have to find the problem because if you were to also report in the wiki main (all except metalinguistice wiki beta.wikiversity [am cerdando to convince the other users of the wiki to install it] can translate the extension )would be big trouble that would send haywire all over the pages of the translation process.

In T157998#3024184, @Nikerabbit wrote:

CentralNotice is responsible for registering the available banners for translation. So unless this is a stale cache in Translate, I don't think I would easily know how to fix this.

@Samuele2002 are you still seeing this? Can this be reproduced on a production wiki?

@DStrine Still seen by opening url https://test.wikipedia.org/wiki/Special:LanguageStats, from the task description. However, not on mediawiki.org, commons.wikimedia.org, or meta.wikimedia.org. As such, triaging as meta/low-impact.

I'm currently not seeing this on https://test.wikipedia.org/wiki/Special:LanguageStats

But I am seeing it when trying to rebuild the message index manually:

mwscript extensions/Translate/scripts/createMessageIndex.php --wiki=testwiki
BannerExistenceException from line 346 of /srv/mediawiki/php-1.35.0-wmf.24/extensions/CentralNotice/includes/Banner.php: No banner exists where tmp_name = WikiCon. Could not load.
#0 /srv/mediawiki/php-1.35.0-wmf.24/extensions/CentralNotice/includes/Banner.php(174): Banner->populateBasicData()
#1 /srv/mediawiki/php-1.35.0-wmf.24/extensions/CentralNotice/includes/Banner.php(890): Banner->getName()
#2 /srv/mediawiki/php-1.35.0-wmf.24/extensions/CentralNotice/includes/Banner.php(854): Banner->getMessageFieldsCacheKey(Object(WANObjectCache))
#3 /srv/mediawiki/php-1.35.0-wmf.24/extensions/CentralNotice/includes/BannerMessageGroup.php(40): Banner->getMessageFieldsFromCache()
#4 /srv/mediawiki/php-1.35.0-wmf.24/extensions/Translate/utils/MessageIndex.php(301): BannerMessageGroup->getKeys()
#5 /srv/mediawiki/php-1.35.0-wmf.24/extensions/Translate/utils/MessageIndex.php(187): MessageIndex->checkAndAdd(Array, Object(BannerMessageGroup))
#6 /srv/mediawiki/php-1.35.0-wmf.24/extensions/Translate/scripts/createMessageIndex.php(30): MessageIndex->rebuild()
#7 /srv/mediawiki/php-1.35.0-wmf.24/maintenance/doMaintenance.php(99): CreateMessageIndex->execute()
#8 /srv/mediawiki/php-1.35.0-wmf.24/extensions/Translate/scripts/createMessageIndex.php(35): require_once('/srv/mediawiki/...')
#9 /srv/mediawiki/multiversion/MWScript.php(101): require_once('/srv/mediawiki/...')
#10 {main}

Still seen.

I note that this seems to have happend a couple of times again, today.

~~~

	#0 /srv/mediawiki/php-1.36.0-wmf.2/extensions/CentralNotice/includes/Banner.php(178): Banner->populateBasicData()

#1 /srv/mediawiki/php-1.36.0-wmf.2/extensions/CentralNotice/includes/Banner.php(927): Banner->getName()
#2 /srv/mediawiki/php-1.36.0-wmf.2/extensions/CentralNotice/includes/Banner.php(890): Banner->getMessageFieldsCacheKey(WANObjectCache)
#3 /srv/mediawiki/php-1.36.0-wmf.2/extensions/CentralNotice/includes/BannerMessageGroup.php(66): Banner->getMessageFieldsFromCache()
#4 /srv/mediawiki/php-1.36.0-wmf.2/extensions/Translate/messagegroups/MessageGroupOld.php(295): BannerMessageGroup->getDefinitions()
#5 /srv/mediawiki/php-1.36.0-wmf.2/extensions/Translate/utils/MessageGroupStats.php(545): MessageGroupOld->initCollection(string)
#6 /srv/mediawiki/php-1.36.0-wmf.2/extensions/Translate/utils/MessageGroupStats.php(460): MessageGroupStats::calculateGroup(BannerMessageGroup, string)
#7 /srv/mediawiki/php-1.36.0-wmf.2/extensions/Translate/utils/MessageGroupStats.php(359): MessageGroupStats::forItemInternal(array, BannerMessageGroup, string, integer)
#8 /srv/mediawiki/php-1.36.0-wmf.2/extensions/Translate/utils/MessageGroupStats.php(121): MessageGroupStats::forLanguageInternal(string, array, integer)
#9 /srv/mediawiki/php-1.36.0-wmf.2/extensions/Translate/api/ApiQueryLanguageStats.php(35): MessageGroupStats::forLanguage(string, integer)
#10 /srv/mediawiki/php-1.36.0-wmf.2/extensions/Translate/api/ApiStatsQuery.php(65): ApiQueryLanguageStats->loadStatistics(string)
#11 /srv/mediawiki/php-1.36.0-wmf.2/includes/deferred/MWCallableUpdate.php(38): ApiStatsQuery->{closure}()
#12 /srv/mediawiki/php-1.36.0-wmf.2/includes/deferred/DeferredUpdates.php(467): MWCallableUpdate->doUpdate()
#13 /srv/mediawiki/php-1.36.0-wmf.2/includes/deferred/DeferredUpdates.php(344): DeferredUpdates::attemptUpdate(MWCallableUpdate, Wikimedia\Rdbms\LBFactoryMulti)
#14 /srv/mediawiki/php-1.36.0-wmf.2/includes/deferred/DeferredUpdates.php(278): DeferredUpdates::run(MWCallableUpdate, Wikimedia\Rdbms\LBFactoryMulti, Monolog\Logger, BufferingStatsdDataFactory, string)
#15 /srv/mediawiki/php-1.36.0-wmf.2/includes/deferred/DeferredUpdates.php(194): DeferredUpdates::handleUpdateQueue(array, string, integer)
#16 /srv/mediawiki/php-1.36.0-wmf.2/includes/MediaWiki.php(1113): DeferredUpdates::doUpdates(string)
#17 /srv/mediawiki/php-1.36.0-wmf.2/includes/MediaWiki.php(849): MediaWiki->restInPeace()
#18 /srv/mediawiki/php-1.36.0-wmf.2/includes/MediaWiki.php(861): MediaWiki->{closure}()
#19 /srv/mediawiki/php-1.36.0-wmf.2/api.php(125): MediaWiki->doPostOutputShutdown()
#20 /srv/mediawiki/php-1.36.0-wmf.2/api.php(45): wfApiMain()
#21 /srv/mediawiki/w/api.php(3): require(string)
#22 {main}
~~~

Not enough to be a problem for this week's train, at this rate.

However, on the principle that every extra error message in the logs makes the train harder to do, I'm reporting.

We [Language team] are on standby for this ticket. If fundraising tech needs assistance after triaging this, please let us know!

Still seeing this as of 2020-12-02 (exception id: X8dqyApAMM0AAc0@7lwAAADJ)

@DStrine This is the task. Thank you so much!

Hi! Thanks so much, all, for the detailed info here!

As far as I understand, this is only ever seen on testwiki... Apologies that we haven't prioritized this at all. testwiki is almost never used for testing CentralNotice these days. Thank you to those who explained that this issue causes problems for other teams!!

My first guess is that something got testwiki tables into an invalid state, maybe when certain extension tables were cleared out and others weren't? Something like that?

If that's the case, then maybe the easiest options here would be to manually remove the Translate message group that references the non-existent banner, or reset the Translate Extension tables for this wiki? Or what about just disabling CentralNotice on this wiki? We could also try creating a banner called "WikiCon" (whose absence the exception is complaining about) though I guess I wouldn't be surprised if that gives way to other slightly different, related errors.

Any other thoughts on a quick way to suppress this error on testwiki, or any other suggestions, would be much appreciated.

Translate extension only keeps a cache of active message groups. The list of groups is provided through hooks TranslatePostInitGroups and TranslateInitGroupLoaders on demand. CentralNotice uses the TranslatePostInitGroups and it is implemented by BannerMessageGroup::registerGroupHook.

That hook does the following query:

		// Find all the banners marked for translation
		$tables = [ 'page', 'revtag' ];
		$vars   = [ 'page_id', 'page_namespace', 'page_title', ];
		$conds  = [ 'page_id=rt_page', 'rt_type' => RevTag::getType( 'banner:translate' ) ];
		$options = [ 'GROUP BY' => 'rt_page' ];
		$res = $dbr->select( $tables, $vars, $conds, __METHOD__, $options );

revtag is a table provided by Translate for adding tags to revisions.

wikiadmin@10.64.0.205(testwiki)> select page_namespace, page_title, rt_revision from revtag, page where page_id=rt_page and rt_type = 'banner:translate';
+----------------+--------------------------------------------+-------------+
| page_namespace | page_title                                 | rt_revision |
+----------------+--------------------------------------------+-------------+
|              8 | Centralnotice-template-TestTranslateBanner |      156102 |
|              8 | Centralnotice-template-FooBarBazKufuffal   |      341662 |
|              8 | Centralnotice-template-CNBannerNamespace1  |      156224 |
|              8 | Centralnotice-template-CommonsApp          |      169487 |
|              8 | Centralnotice-template-CommonsApp          |      169501 |
|              8 | Centralnotice-template-CommonsApp          |      169520 |
|              8 | Centralnotice-template-CommonsApp          |      169521 |
|              8 | Centralnotice-template-CommonsApp          |      169522 |
|              8 | Centralnotice-template-CommonsApp          |      169523 |
|              8 | Centralnotice-template-CommonsApp          |      169524 |
|              8 | Centralnotice-template-fallbackBanner      |      174217 |
|              8 | Centralnotice-template-WikiCon2016         |      275894 |
|              8 | Centralnotice-template-WikiCon             |      275884 |
+----------------+--------------------------------------------+-------------+
13 rows in set (0.00 sec)

So I guess by removing the last row above from the revtag table would stop it appearing for Translate. But I do not know if it causes any issues on CentralNotice.

Code search https://codesearch.wmcloud.org/search/?q=banner%3Atranslate&i=nope&files=&excludeFiles=&repos= seems to indicate that one option would be turning of $wgNoticeUseTranslateExtension and another one would be to run CleanCNTranslateMetadata.php maintenance script. I think this script option looks most favorable. Could you attempt to run this script for testwiki?

Fr-tech can try and spend an hour or two assessing this and will comment. We are very tight on time and capacity in the next two weeks. If we need to spend more time on this it will have to wait until later in February.

So I guess by removing the last row above from the revtag table would stop it appearing for Translate. But I do not know if it causes any issues on CentralNotice.

Code search https://codesearch.wmcloud.org/search/?q=banner%3Atranslate&i=nope&files=&excludeFiles=&repos= seems to indicate that one option would be turning of $wgNoticeUseTranslateExtension and another one would be to run CleanCNTranslateMetadata.php maintenance script. I think this script option looks most favorable. Could you attempt to run this script for testwiki?

Hi! Apologies for the delay here... Looking at CleanCNTranslateMetadata.php, it seems like running that on testwiki has a reasonable chance of fixing this.

If that doesn't work, manually editing the revtag table should be fine from a CN point of view.

My expectation for testwiki is that tables should be reset on a regular basis... does that not happen? Maybe only partly?

Again, FR-Tech does not use testwiki at all, so we're totally OK with CN being disabled permanently there. Turning off $wgNoticeUseTranslateExtension is also a fine option.

Would it be okay to you if I run CleanCNTranslateMetadata.php on testwiki then? Seems risks are small given you are not using testwiki for anything.

In T157997#6900460, @Nikerabbit wrote:

Would it be okay to you if I run CleanCNTranslateMetadata.php on testwiki then? Seems risks are small given you are not using testwiki for anything.

Hi! That would be fantastic if you could do that, yes... Apologies again that we haven't gotten to it, and thanks again!!

In T157997#6921484, @Nikerabbit wrote:

LGTM.

Fantastic, thanks so much for this!!!! :) :)