Page MenuHomePhabricator

Show current site name properly if cross-wiki notifications are not enabled
Closed, ResolvedPublic

Description

We should probably:

  • Assume if cross-wiki notifications are enabled, wgConf is set up.
  • If it's not (as here)
    • Omit 'unpwikis' from the API request.
    • Instead use wgSitename, which is always available (on the client-side already too).

Event Timeline

Change 505259 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/Echo@master] ApiEchoUnreadNotificationPages: index results by dbname

https://gerrit.wikimedia.org/r/505259

Restricted Application added a project: Growth-Team. · View Herald TranscriptApr 19 2019, 3:11 PM
SBisson claimed this task.Apr 19 2019, 3:29 PM
SBisson moved this task from Incoming to In Progress on the Growth-Team (Current Sprint) board.

Change 505259 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Use wikiId both server and client side

https://gerrit.wikimedia.org/r/505259

The patch that was merged was to fix a JS error that occurs on TWN.

Next step is to figure out why wgSitename is not used to render the site name on Special:Notifications as it should.

Hey @SBisson are you still planning to work on this or should we reassign?

Hey @SBisson are you still planning to work on this or should we reassign?

Yes, I plan to finish it. If this is now a priority for the Growth team, feel free to reassign so it gets done faster. If, on the contrary, this is just noise on the board, you can push it to "external".

This issue can be seen on translatewiki.net. The notifications special page has a sidebar showing the number of unread notifications per wiki per page. The name of the current wiki should be somewhat friendly but since the unreadnotificationpages API returns the name of the local source as null, the UI resorts to showing the string 'local', regardless of the user's language.

The name of the source is generated on the server by the following function.

ForeignNotifications.php
/**
 * @param string $wikiId
 * @param array|null $siteFromDB $wgConf->siteFromDB( $wikiId ) result
 * @return mixed|string
 */
protected static function getWikiTitle( $wikiId, array $siteFromDB = null ) {
	global $wgConf, $wgLang;

	$msg = wfMessage( 'project-localized-name-' . $wikiId );
	// check if WikimediaMessages localized project names are available
	if ( $msg->exists() ) {
		return $msg->text();
	} else {
		// don't fetch $site, $langCode if known already
		if ( $siteFromDB === null ) {
			$siteFromDB = $wgConf->siteFromDB( $wikiId );
		}
		list( $site, $langCode ) = $siteFromDB;

		// try to fetch site name for this specific wiki, or fallback to the
		// general project's sitename if there is no override
		$wikiName = $wgConf->get( 'wgSitename', $wikiId ) ?: $wgConf->get( 'wgSitename', $site );
		$langName = Language::fetchLanguageName( $langCode, $wgLang->getCode() );

		if ( !$langName ) {
			// if we can't find a language name (in language-agnostic
			// project like mediawikiwiki), including the language name
			// doesn't make much sense
			return $wikiName;
		}

		// ... or use generic fallback
		return wfMessage( 'echo-foreign-wiki-lang', $wikiName, $langName )->text();
	}
}

This function has 3 return paths.

It can return wfMessage( 'project-localized-name-' . $wikiId )->text() if the message exists. TWN's wiki ID is translatewiki_net-bw_. It results in a message ending with an underscore, which is invalid, so this can't be used to generate the name of the source.

The third return path, if all else fails, is wfMessage( 'echo-foreign-wiki-lang', $wikiName, $langName )->text(). This message is defined by Echo and translated to $1 - $2 in the vast majority of languages. Even if both params where null it would results in a string like ' - ', which is not what we see in the UI.

The other option is for both $wikiName and $langName to be null. The former is assigned from $wgConf->get( 'wgSitename', $wikiId ) ?: $wgConf->get( 'wgSitename', $site ). It is possible that wgSitename is not defined on the server, or is it defined with a different case? Client-side, it is defined as wgSiteName (with a capital N).

SBisson closed this task as Resolved.Tue, Sep 24, 10:43 AM

As far as I can tell, wgSitename is being used for the current wiki name with or without cross-wiki notifications enabled.

Please re-open if this is an issue for you and you can provide configuration information about where wiki where this is happening.