Page MenuHomePhabricator

JavaScript error when translation helper fails
Closed, ResolvedPublicBUG REPORT

Description

When writing a translation, the Translate extension periodically AJAX-calls a translation-checking service on background to display various errors in the translation. The result of this check is returned as JSON, parsed on the client side using standard JSON.parse. However, when the check fails on the server side, TranslationHelpers::callBox returns the error message wrapped into an HTML comment (<!-- Box $type not available: {$e->getMessage()} -->), which is obviously not a valid JSON, so TranslateEditor.prototype.validateTranslation dies on its JSON.parse with SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data.

This is the case of e.g. Commons custom UI translation, where any typing into a translation editbox causes a stream of Box check not available: unknown group errors.

I guess TranslationHelpers::getBoxes should use a different wrapper in its checks branch (or generalize TranslationHelpers::callBox to support JSON as error-output format). Or rewrite the whole TranslationEditPage anyway (“// todo Move to api or so”, “This interface is a big klunky.”).

Outcome

Translation aids were not working at all for one message group in Wikimedia Commons. This was fixed.

Event Timeline

Most of the PHP code you refer to is only used in the non-TUX ui. I cannot reproduce the error in the link you give. I only get a different, unrelated error.

OK, I’ll try to be very specific:

I open a new InPrivate window of Edge (so that I am sure I am not logged in, and have nothing re-configured, customized or non-standard, even though normally, I use Firefox).

I go to the above URL, and change Translate točeština.

I open the developer toolbar and switch to see the JS Console.

Then, I click on the first untranslated entry (“You are editing template documentation subpage. […]”). The TUX UI to edit the message appears. I type blabla there. In the JS Console, an error message (SCRIPT1014: Invalid character) appears.

Also, on the Network tab of the Developer toolbar, I can see the last request being an XMLHttpRequest POST to https://commons.wikimedia.org/w/index.php?title=Special:Translate/editpage&suggestions=checks&page=MediaWiki%3ACommons-editnotices-template-subpage-doc%2Fcs&loadgroup=wiki-translatable with request body translation: blabla and response body <!-- Box check not available: unknown group -->.

Thanks, I can reproduce now.

The underlying issues is that for some reason Translate thinks that those messages does not belong to any message group. If we fix that one, the visible issue of HTML comments in JSON most likely goes away as well, and that should also fix the translations aids not loading.

I no longer see the previous issue with the steps mentioned, but an unrelated issue while fetching translation aid.

Error loading translation aids: nomessagefortitle

MessageHandle::isValid returns false because NS_MEDIAWIKI is not in $wgTranslateMessageNamespaces for Commons.

Change 622473 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[operations/mediawiki-config@master] Add $wgTranslateMessageNamespaces[] = NS_MEDIAWIKI; for commonswiki

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

Change 622473 merged by jenkins-bot:
[operations/mediawiki-config@master] Add $wgTranslateMessageNamespaces[] = NS_MEDIAWIKI; for commonswiki

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

Mentioned in SAL (#wikimedia-operations) [2020-08-27T11:09:17Z] <urbanecm@deploy1001> Synchronized wmf-config/CommonSettings.php: 34994d39f92b23934929c66f3e15aa332683e746: Add $wgTranslateMessageNamespaces[] = NS_MEDIAWIKI; for commonswiki (T131300) (duration: 01m 03s)

QA done as part of deployment.

Nikerabbit updated the task description. (Show Details)
Nikerabbit changed the subtype of this task from "Task" to "Bug Report".Sep 23 2020, 7:37 AM