Page MenuHomePhabricator

In Wikidata value entering boxes "Malformed value", date precision values, and other elements cannot be translated
Closed, ResolvedPublic


Users were trying to: add a new property to the box that checks the entered text for validity (like geo location) in German and received "Malformed Value" error.
What actually happened: The error was in English and not German.

malfeng.png (148×277 px, 6 KB)

image.png (200×672 px, 17 KB)

image.png (200×672 px, 16 KB)

Proposed solution: Use localized strings for that output and others on this window like "to 1/10 of an arcsecond."

Related Objects

Event Timeline

It doesn't sound like an exceptionally complicated thing to fix, but I don't even know where are these strings.

Is it in Wikibase? Or in one of the extensions or libraries on which it depends? Or is it part of's content?

Amire80 renamed this task from "Malformed value" and other elements not translated to In Wikidata value entering boxes "Malformed value", date precision values, and other elements cannot be translated.Feb 16 2018, 1:17 PM
Amire80 updated the task description. (Show Details)
thiemowmde triaged this task as Medium priority.Feb 19 2018, 5:52 PM

I had a brief look and found two details that might help solving this issue:

  1. The API request might need a uselang=de attached to make sure the error messages the API call possibly returns are all localized.
  2. The file RepoApiError.js in the "wikibase-api" JavaScript component contains code to extract the human-readable error message from an API response. I think the code does not support the current format.

In both cases I believe it's not a design ticket, but an actual bug.

So indeed uselang can be used to alter the error message within the parsing result.


However the main error for the API still remains in english.

However looking at qqx the value being use there is the i18n code...
But it is not being localized.

Chasing this down the pipes a bit further, this is done in ApiErrorFormetter::addMessagesFromStatus in core, which even when using uselang=de uses an EN language object for the following code:

			$msg = ApiMessage::create( $error )
				->inLanguage( $this->lang )
				->title( $this->getDummyTitle() )
				->useDatabase( $this->useDB );

Resulting in the english api output.

When testing locally it looks like ApiMain currently makes us use a ApiErrorFormatter_BackCompat instance for the call we are making.
We get this rather than a ApiErrorFormatter instance because we do not specify an error format (so the fallback bc is used)

If we specify an error format, such as "plaintext", which is consistent with the bc format, then we see the error message in the correct language.

So we probably want to stop using the old bc compat layer in our UI calls to the backend, and instead specify an error format and possibly also an errorlang or uselang.

Current code snippet making the decision in ApiMain:

		$errorFormat = $request->getRawVal( 'errorformat', 'bc' );
		$errorLangCode = $request->getRawVal( 'errorlang', 'uselang' );
		$errorsUseDB = $request->getCheck( 'errorsuselocal' );
		if ( in_array( $errorFormat, [ 'plaintext', 'wikitext', 'html', 'raw', 'none' ], true ) ) {
			if ( $errorLangCode === 'uselang' ) {
				$errorLang = $this->getLanguage();
			} elseif ( $errorLangCode === 'content' ) {
				$errorLang = MediaWikiServices::getInstance()->getContentLanguage();
			} else {
				$errorLangCode = RequestContext::sanitizeLangCode( $errorLangCode );
				$errorLang = MediaWikiServices::getInstance()->getLanguageFactory()
					->getLanguage( $errorLangCode );
			$this->mErrorFormatter = new ApiErrorFormatter(
				$this->mResult, $errorLang, $errorFormat, $errorsUseDB
		} else {
			$this->mErrorFormatter = new ApiErrorFormatter_BackCompat( $this->mResult );

Waiting on the sub ticket to be picked up and solved.

"Malformed value" was done in T242769
Precisions are not yet done (could likely do with a sub ticket