Page MenuHomePhabricator

Remove hardcoded language list
Closed, ResolvedPublicFeature

Description

There is a list of language codes in SiteDisplay.js, starting around line 195:

	// Get RTL/LTR direction for the site. We can't use String.prototype.startsWith, since
	// that is unavailable in IE11, and doesn't take multiple values anyway. Use
	// String.prototype.match with a list of the language codes that should be RTL
	// this.siteID is based on the URL form of the wiki, and we assume that wikis that are
	// meant to be RTL are in the form `⧼rtl language code⧽.*`, and any URL that does not
	// match this is for an LTR wiki. See T274602 and T274313
	const isRTL = this.siteID.match(
		/^(ar|azb|ckb|dv|fa|glk|he|ks|lrc|mzn|nqo|pnb|ps|sd|ug|ur|yi)_/
	);
	// mw-content-ltr and -rtl classes are not enough to ensure that the text is formatted
	// in the correct direction, so add a manual direction attribute. See T287649
	// We still add those classes because they are also used by jQuery.makeCollapsible
	// to know if the collapse button should be on the right or left.
	this.$feedDiv = $( '<div>' )
		.attr( 'id', 'ext-globalwatchlist-feed-site-' + this.siteID )
		.attr( 'dir', isRTL ? 'rtl' : 'ltr' )
		.addClass( 'ext-globalwatchlist-feed-site' )
		.addClass( isRTL ? 'mw-content-rtl' : 'mw-content-ltr' )
		.append(
			headerTemplate.render( headerParams ),
			$content
		);

Using a hardcoded list that may change over time has always been a poor solution, but at the time, we weren’t able to find a better approach. Now there may be a more reliable one:

  1. When saving user settings, get the list of wikis they have chosen to watch.
  2. Get a variable $wgSiteMatrixSites provided for Extension:SiteMatrix to retrieve site information.
  3. If isn't defined, or doesn't include all the needed info, use the existing hardcoded list as a backup.
  4. Otherwise, extract the direction (RTL/LTR) for each selected wiki and store it alongside the corresponding wiki URL in the user’s settings.
  5. Replace the existing hardcoded list with logic that checks the stored directions in the user settings, loading each site’s language direction dynamically.

Event Timeline

Restricted Application added subscribers: hubaishan, Aklapper. · View Herald Transcript
Restricted Application added a subscriber: alaa. · View Herald Transcript

Of course, since the SiteMatrix extension is not always installed on real wikis, the hardcoded list will remain as a fallback, I think it's better than just make all the special page LTR only.

A_smart_kitten subscribed.

(removing the SiteMatrix tag, as AFAICS this task doesn't involve SiteMatrix code itself. please correct me if I am wrong!)

Yes, you are right. Didn't know this also should be the criteria, thank you.

Change #1218844 had a related patch set uploaded (by Gerrit Patch Uploader; author: IKhitron):

[mediawiki/extensions/GlobalWatchlist@master] Replace hardcoded wikis directions list to SiteMatrix data

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

IKhitron changed the task status from Open to Stalled.Dec 17 2025, 1:09 PM

Blocked on T412581 for now.

Test wiki created on Patch demo by IKhitron using patch(es) linked to this task:
https://be0fc540a3.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by IKhitron using patch(es) linked to this task:
https://94e4215001.catalyst.wmcloud.org/w/

IKhitron triaged this task as Medium priority.Dec 20 2025, 4:27 PM

Blocked on T412581 for now.

It isn’t blocked anymore (the latest patchsets no longer use SiteMatrix), is it?

Blocked on T412581 for now.

It isn’t blocked anymore (the latest patchsets no longer use SiteMatrix), is it?

Well, @Tacsipacsi, until I know for sure there is at least one working solution with core calls only, I'm waiting for SiteMatrix just for the case. For now, the second solution can't be checked on Patch Demo or on local wiki entirely, because two lines need Wikimedia, or maybe Beta or Testwiki. I checked all the rest. And I didn't read yet the third solution you've suggested today.

Well, @Tacsipacsi, until I know for sure there is at least one working solution with core calls only, I'm waiting for SiteMatrix just for the case.

If you’re just waiting for SiteMatrix, you won’t find out whether there is another working solution. If you’re not actually waiting, but you can proceed, e.g. with the exploration of another working solution, then I don’t think this task is stalled.

For now, the second solution can't be checked on Patch Demo or on local wiki entirely, because two lines need Wikimedia, or maybe Beta or Testwiki. I checked all the rest. And I didn't read yet the third solution you've suggested today.

SiteMatrix being available on Patch Demo wouldn’t really help with this. However, I managed to create a test setup locally:

  1. I access my dev wiki at http://localhost:8010/, adjust the below steps if you have another address.
  2. I added the following to my LocalSettings.php:
$wgLocalDatabases = [ $wgDBname, 'capital' ];
$wgConf->suffixes = [ '' ];
$wgConf->settings = [
	'wgServer' => [
		'default' => $wgServer, // this resolves to http://localhost:8010
		'capital' => 'http://Localhost:8010',
	],
	'wgArticlePath' => [
		'default' => $wgArticlePath,
	],
];
  1. I ran maintenance/run addSite --language=he capital my_wiki_group. I previously ran something like maintenance/run addSite --language=en my_wiki my_wiki_group (this was months ago, so I don’t have the exact command available anymore).

The trick is that the browser treats http://localhost:8010 and http://Localhost:8010 the same, so there are no CORS issues, but MediaWiki or GlobalWatchlist don’t normalize the domain name, so we can have two sites with two different languages.

IKhitron changed the task status from Stalled to Open.Dec 21 2025, 7:43 PM

If you’re just waiting for SiteMatrix, you won’t find out whether there is another working solution. If you’re not actually waiting, but you can proceed, e.g. with the exploration of another working solution, then I don’t think this task is stalled.

Very well, reopened it.

For now, the second solution can't be checked on Patch Demo or on local wiki entirely, because two lines need Wikimedia, or maybe Beta or Testwiki. I checked all the rest. And I didn't read yet the third solution you've suggested today.

SiteMatrix being available on Patch Demo wouldn’t really help with this. However, I managed to create a test setup locally:

  1. I access my dev wiki at http://localhost:8010/, adjust the below steps if you have another address.
  2. I added the following to my LocalSettings.php:
$wgLocalDatabases = [ $wgDBname, 'capital' ];
$wgConf->suffixes = [ '' ];
$wgConf->settings = [
	'wgServer' => [
		'default' => $wgServer, // this resolves to http://localhost:8010
		'capital' => 'http://Localhost:8010',
	],
	'wgArticlePath' => [
		'default' => $wgArticlePath,
	],
];
  1. I ran maintenance/run addSite --language=he capital my_wiki_group. I previously ran something like maintenance/run addSite --language=en my_wiki my_wiki_group (this was months ago, so I don’t have the exact command available anymore).

The trick is that the browser treats http://localhost:8010 and http://Localhost:8010 the same, so there are no CORS issues, but MediaWiki or GlobalWatchlist don’t normalize the domain name, so we can have two sites with two different languages.

Unfortunately, it will take months or years until I could understand that, sorry.

Test wiki created on Patch demo by IKhitron using patch(es) linked to this task:
https://30eb9266dd.catalyst.wmcloud.org/w/

I've created a new Patch Demo to replace the failed one, it could be needed to fix the building bug.

Change #1221616 had a related patch set uploaded (by Tacsipacsi; author: Tacsipacsi):

[mediawiki/extensions/GlobalWatchlist@master] Replace hardcoded wiki directions list with live data

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

Test wiki created on Patch demo by IKhitron using patch(es) linked to this task:
https://6bb8f2bff7.catalyst.wmcloud.org/w/

I was reviewing some GlobalWatchlist patches and noticed that this task has two different ones proposed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1218844 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1221616. I haven't tested them yet, but it looks like both could work, and I see there have been long discussions. Could you summarize for me and say which patch is preferable?

I was reviewing some GlobalWatchlist patches and noticed that this task has two different ones proposed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1218844 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1221616. I haven't tested them yet, but it looks like both could work, and I see there have been long discussions. Could you summarize for me and say which patch is preferable?

We worked on them together, more or less, @matmarex. And we both prefer Tacsipacsi's 1221616, because it's much better. If it will be approved, I'll mark mine as abandoned. Thank you.

I was reviewing some GlobalWatchlist patches and noticed that this task has two different ones proposed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1218844 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1221616. I haven't tested them yet, but it looks like both could work, and I see there have been long discussions. Could you summarize for me and say which patch is preferable?

In @IKhitron’s one (1218844), different patch sets used various methods to get the language of all wikis server-side (which discovered how complicated and redundant core’s handling of foreign wiki data is…), and, as far as I remember, all versions that got implemented stored the resulting data in the user_properties table (which DBAs probably wouldn’t like, as it’s already way too bloated). Some versions have had hard dependencies on other extensions (first SiteMatrix, later CentralAuth – CentralAuth is currently a soft dependency, SiteMatrix isn’t a dependency at all), although the latest version didn’t have any new dependencies anymore.

In mine (1221616), the data is queried on-the-fly on the client side, batched with another request to avoid increasing the number of requests. This means it’s uncacheable, but on the other hand it doesn’t have any performance impact on the 99.99% of page loads that aren’t Special:GlobalWatchlist, and the data is always up-to-date (not that the directionality of a site is expected to change too often). And it’s just a few bytes of information per site that doesn’t get cached.

I created 1221616 after the purely client-side solution came to my mind, and I found it easier to just write the patch than to describe @IKhitron how to do that. (Actually, I could’ve amended that change instead, but A) I didn’t think about this possibility then and B) even if I would have thought about it, I probably hadn’t want to amend someone else’s change out of the blue, completely rewriting it.) So yes, I also prefer my solution, that’s why I created it. ☺

If it will be approved, I'll mark mine as abandoned.

Why not now? An abandoned change can always be restored. (Assuming that you are able to mark the patch as abandoned, which I’m not entirely sure about, given that the owner of the patch is not you, but Gerrit Patch Uploader… I suggest you to use Gerrit’s own web interface, or simply the standard command-line tools everyone uses, for future patches. The best thing about Gerrit Patch Uploader is that it doesn’t require you to have a developer account; but you already have one anyway.)

Why not now? An abandoned change can always be restored.

Didn't know that, thanks. But still. Because I need to ask somebody to do that. From personal reasons I can't, at least for now, work from git on Mediawiki changes, maybe later. And I already asked something on IRC today, and I need to ask something else right now, the third will be too much for one day, I think.

I see, thanks! Let's go with that then.

I'll abandon the other patch for you. I think you need some additional permissions (not sure which ones, but apparently I have them) to abandon patches submitted by others, and IKhitron's patch is technically submitted by "Gerrit Patch Uploader".

Change #1218844 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/GlobalWatchlist@master] Replace hardcoded wikis directions list with evaluated data

Reason:

Superseded by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1221616

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

I'll abandon the other patch for you.

Thanks a lot.

From personal reasons I can't, at least for now, work from git on Mediawiki changes, maybe later.

The Gerrit web interface doesn’t require you to have anything installed on your computer (other than a browser, of course), so it could work for you. It’s less convenient than the command-line tools once they’re set up, but probably not less convenient than the Gerrit Patch Uploader. And using it would avoid the ownership issues. (As far as I remember, I’ve used it one or two times when working from foreign computers or mobile.)

I see, thanks! Let's go with that then.

Thanks!

I think you need some additional permissions (not sure which ones, but apparently I have them) to abandon patches submitted by others, and IKhitron's patch is technically submitted by "Gerrit Patch Uploader".

Yes, I also have the right to amend others’ changes (I could probably even empty them), but not to amend them. I don’t have any idea either what those extra permissions are.

From personal reasons I can't, at least for now, work from git on Mediawiki changes, maybe later.

The Gerrit web interface doesn’t require you to have anything installed on your computer (other than a browser, of course), so it could work for you. It’s less convenient than the command-line tools once they’re set up, but probably not less convenient than the Gerrit Patch Uploader. And using it would avoid the ownership issues. (As far as I remember, I’ve used it one or two times when working from foreign computers or mobile.)

Thanks, I'll check this out.

Change #1221616 merged by jenkins-bot:

[mediawiki/extensions/GlobalWatchlist@master] Replace hardcoded wiki directions list with live data

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

IKhitron assigned this task to Tacsipacsi.
IKhitron moved this task from Gerrit WIP to Misc on the User-IKhitron board.

From personal reasons I can't, at least for now, work from git on Mediawiki changes, maybe later.

The Gerrit web interface doesn’t require you to have anything installed on your computer (other than a browser, of course), so it could work for you. It’s less convenient than the command-line tools once they’re set up, but probably not less convenient than the Gerrit Patch Uploader. And using it would avoid the ownership issues. (As far as I remember, I’ve used it one or two times when working from foreign computers or mobile.)

Thanks, I'll check this out.

Can you clarify, please? Because I couldn't find nothing more "But you already do this on Gerrit!"

I'm not totally sure what the question is as you replied to yourself, but if it's about the "Gerrit web interface": https://www.mediawiki.org/wiki/Gerrit/Web_tutorial

It's much better. Thank you both.

@Tacsipacsi, one question about this task. Can we change the language checked for direction for multilanguage wikis only from "language of this wiki" to "language of the current user in the preferences on that wiki"? I do not mean if should we for now, just if it is possible, without extra API calls?

We could query the “language of the current user in the preferences on that wiki”, using the responselanginfo parameter – however, that excludes exactly the directionality of the language. And so does meta=siteinfo&siprop=languages… This doesn’t mean this is impossible, though: simply the core API needs to be expanded (unless a better one can be found), we have control over that as well.

On the other hand, I’m thinking why we use the wiki language in the first place. When I look at my Wikidata or Meta watchlist, it’s full of changes in various languages, yet the “chrome” (the non-user-generated part, i.e. the links, dates etc.) is always in one language. Wouldn’t it be more consistent to show everything but the edit summaries in Meta’s language (which can be controlled with ?uselang=), with all blocks left- or right-aligned according to the Meta language, and page titles, user names and edit summaries placed in <bdi>s?

How bad will be to add one API call for Wikidata only, in this case?

why we use the wiki language in the first place.

It is one of the options I'm considering, and we all should soon make a common decision. Because this is how the real watchlist looks for me today:

Screenshot_20260112_084809_Samsung Internet.png (428×1 px, 352 KB)

and is incredibly bad.

When I look at my Wikidata or Meta watchlist, it’s full of changes in various languages, yet the “chrome” (the non-user-generated part, i.e. the links, dates etc.) is always in one language. Wouldn’t it be more consistent to show everything but the edit summaries in Meta’s language (which can be controlled with ?uselang=), with all blocks left- or right-aligned according to the Meta language, and page titles, user names and edit summaries placed in <bdi>s?

I'm not even sure it's possible, with so much parts of opposite direction, to show rtl parsedcomments inside ltr text. Are you?

Test wiki on Patch demo by IKhitron using patch(es) linked to this task was deleted:

https://30eb9266dd.catalyst.wmcloud.org/w/

Test wiki on Patch demo by IKhitron using patch(es) linked to this task was deleted:

https://be0fc540a3.catalyst.wmcloud.org/w/

Test wiki on Patch demo by IKhitron using patch(es) linked to this task was deleted:

https://94e4215001.catalyst.wmcloud.org/w/

Test wiki on Patch demo by IKhitron using patch(es) linked to this task was deleted:

https://6bb8f2bff7.catalyst.wmcloud.org/w/