Page MenuHomePhabricator

Citoid doesn't load when uselang=qqx
Closed, ResolvedPublic

Description

In some wikis the VE "Cite" button and the "Add a citation" title are now displayed in English because at some point the interface is using the (new?) "citoid-citoidtool-title " instead of the older "cite-ve-toolbar-group-label" (already translated in most languages). But when someone tries to find the message to be translated they can't find it as uselang=qqx reports the older message 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

Event Timeline

geraki created this task.May 10 2019, 10:50 AM
Restricted Application added a project: VisualEditor. · View Herald TranscriptMay 10 2019, 10:50 AM
Restricted Application added subscribers: Petar.petkovic, Aklapper. · View Herald Transcript
geraki renamed this task from Translated VE interface strings displayed in english to Interface reports different interface messages than the actually used.May 10 2019, 11:13 AM
geraki updated the task description. (Show Details)

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.

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?

Esanders renamed this task from Interface reports different interface messages than the actually used to Citoid doesn't load when uselang=qqx.May 13 2019, 12:13 PM
Esanders triaged this task as Lowest priority.May 13 2019, 12:15 PM

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

Yes, but this doesn't appear to be a problem when using a real language, e.g. 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=fr

so this is probably just a quirk of qqx

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

Krinkle added a comment.EditedMay 13 2019, 12:29 PM

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.

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

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.

ppelberg closed this task as Resolved.Jul 3 2019, 3:07 AM
ppelberg claimed this task.