CC @Nikerabbit . We renamed some messages in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Citoid/+/500732/15/i18n/en.json - is it too late to rename these automatically on TW?

I believe @Raymond did the renames.

In T222944#5174921, @Nikerabbit wrote:

I believe @Raymond did the renames.

Yes, but originally I have forgotten rename citoid-citoidtool-title and citoid-citoidtool-title-othergroup. Thesese 2 were renamed yesterday as follow up.

But what I do not understand, as the orignal poster too, why https://el.wikipedia.org/wiki/%CE%92%CE%BF%CE%AE%CE%B8%CE%B5%CE%B9%CE%B1:%CE%A0%CF%81%CF%8C%CF%87%CE%B5%CE%B9%CF%81%CE%BF?veaction=edit&uselang=qqx shows up "cite-ve-toolbar-group-label" instead of "citoid-citoidtool-title"

When you have uselang=qqx set it appears to be breaking the Citoid config (which is loaded via messages), so you get the plain Cite menu instead.

Shouldn't the config be loaded in content language always and thus not be breaking on changing the interface language?

Since https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/470181/ 'qqx' always returns (key) in the client, so the Citoid config is not returned, even though the JSON is manually loaded into the message store.

CC @matmarex @Krinkle

This is caused by rMWbb084a35739e: Support message parameters in JavaScript messages with uselang=qqx / https://gerrit.wikimedia.org/r/470181, which is interfering with the transportation of qqx-messages from the server and instead hardcodes their logic client-side.

The result is that messages that haven't been transported appear to exist even when they weren't registered. And it means overrides (like VE does) for content language (instead of user language) are ignored.

Server-side, when using userlang=qqx, it only affects user-language messages. Calling inContenLanguage() bypasses it, which is why this used to work before December 2018.

I think backing out the JS part of that commit (which seems redundant) might do the trick.

In T222944#5176414, @Krinkle wrote:

This is caused by rMWbb084a35739e: Support message parameters in JavaScript messages with uselang=qqx / https://gerrit.wikimedia.org/r/470181, which is interfering with the transportation of qqx-messages from the server and instead hardcodes their logic client-side.

(…)

I think backing out the JS part of that commit (which seems redundant) might do the trick.

I'm not sure what you mean here. The JS part is the only part of the commit. (There was originally a PHP part too, but you asked me to remove it in code review :) )

I've found a different way to allow non-qqx messages to be used in qqx mode though, patch incoming.

Change 510076 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] Allow sneaking in non-qqx JavaScript messages in qqx mode

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

Change 510076 merged by jenkins-bot:
[mediawiki/core@master] jqueryMsg: Allow sneaking in non-qqx JavaScript messages in qqx mode

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

In T222944#5179168, @matmarex wrote:

In T222944#5176414, @Krinkle wrote:

This is caused by rMWbb084a35739e: Support message parameters in JavaScript messages with uselang=qqx / https://gerrit.wikimedia.org/r/470181, which is interfering with the transportation of qqx-messages from the server and instead hardcodes their logic client-side.

(…)

I think backing out the JS part of that commit (which seems redundant) might do the trick.

I'm not sure what you mean here. The JS part is the only part of the commit. (There was originally a PHP part too, but you asked me to remove it in code review :) ) [..]

Thanks, you're right. I misremembered. I thought we could have the server export QQX messages as any other language, and not do anything special client-side. But I realize now that is pointless, because we want to dynamically show the currently passed message parameters, which means plain (message-key) is not enough.