It looks like a non-string value is passed which is not supported. We don't cast/ignore invalid values since that might result in unintended unescaped characters being used in contexts where they are not intended which could break the UI or cause security issues.

Source:
https://gerrit.wikimedia.org/g/mediawiki/extensions/UniversalLanguageSelector/+/fe6ae65c988051d720085b6bd5c6e7b3a4e1ac50/resources/js/ext.uls.compactlinks.js#489

Based on that, I suspect the issue might be indirectly coming from mw.language.convertNumber() sometimes (wrongly?) returning simple integers as integers instead of always casting to a string.

All the recent ones are from updateTooltipOnElement from mediawiki.util/jquery.accessKeyLabel.js. It would be nice to have logs of what the invalid values actually are.

You could update the code to catch and manually throw the error with this additional information if that information is useful to understand.

In T265498#6644022, @Nikerabbit wrote:

All the recent ones are from updateTooltipOnElement from mediawiki.util/jquery.accessKeyLabel.js. It would be nice to have logs of what the invalid values actually are.

There are only a handful of functions involved here, so static analysis could suffice here - which I already did:

In T265498#6543842, @Krinkle wrote:

[…] a non-string value is passed which is not supported. […]

Source:
https://gerrit.wikimedia.org/g/mediawiki/extensions/UniversalLanguageSelector/+/fe6ae65c988051d720085b6bd5c6e7b3a4e1ac50/resources/js/ext.uls.compactlinks.js#489

[…] the issue might be indirectly coming from mw.language.convertNumber() sometimes returning simple integers as integers instead of always casting to a string.

This seems pretty straight-forward. Have you ruled this out under normal conditions? E.g. assuming no weird overrides or gadget/browser extension interference.

I had a look at the code of mw.language.convertNumber and did not see how it could return not-a-string when passed one argument.

Looks like we misinterpreted the stack trace. It is calling message().plain(). The ULS code (src) only uses mw.language.convertNumber() in its call to message().text().

This means the issue is actually about this call:

CompactInterlanguageList.prototype.addTrigger = function () {
  // …
  trigger.title = mw.message( 'ext-uls-compact-link-info' ).plain();

TypeError:  Object doesn't support property or method 'replace'

at mw.format  Unknown script code:403:149
at Message.prototype.parser  Unknown script code:401:998
at mw.Message.prototype.parser  Unknown script code:359:190
at Message.prototype.toString  Unknown script code:402:103
at Message.prototype.plain  Unknown script code:402:310
at CompactInterlanguageList.prototype.addTrigger  Unknown script code:91:733
at CompactInterlanguageList.prototype.render  Unknown script code:87:57
at CompactInterlanguageList.prototype.init  Unknown script code:86:871
at createCompactList  Unknown script code:92:185

Per @Nikerabbit, the more recent ones are coming to mw.format() via updateTooltipOnElement(), like so:

function updateTooltipOnElement( element, titleElement ) {
	// …
	mw.message( 'word-separator' ).plain();
	// …
	parts = mw.message( 'brackets' ).plain();
	/* … */ mw.message( 'brackets', accessKeyLabel ).plain();

TypeError:  Object doesn't support property or method 'replace'

at mw.format  Unknown script code:357:149
at Message.prototype.parser  Unknown script code:355:998
at mw.Message.prototype.parser  Unknown script code:314:321
at Message.prototype.toString  Unknown script code:356:103
at Message.prototype.plain  Unknown script code:356:310
at updateTooltipOnElement  Unknown script code:349:432
at updateTooltip  Unknown script code:349:953

This is even more surprising since there aren't any parameters. It's as plain as it can be. (No pun intended.)

Another thing I noticed in Logstash is that all reports are from Edge 16, Edge 17 or Edge 18 on Windows 10 (based on Chromium 58 to 70). It does originate from different countries and from different wikis (fr.wikipedia, ja.wikipedia).

I tried running the same code via BrowserStack in the same browser and OS, on the same article, and in the same interface language. But, it doesn't happen there.

I'm guessing these handful of reports must have some kind of horribly broken browser extension or user script that is recursively crawling through mw.* classes and replacing random methods with broken implementations, or perhaps they are deleting or changing String.prototype methods.

At any event, the rate seems far too low to warrant further investigations. 23 reports over a full day from instrumented wikis, without sampling. Suggesting we decline this for now.