Page MenuHomePhabricator

Support i18n in validation errors
Open, MediumPublic


To increase the chances of adoption of Community Configuration i18n support is very desirable. opis/json-schema or justinrainbow/json-schema does not provide the feature (see T332847).

Opis has ValidationError::$keyword, maybe that can be used as a key? It's not obvious at a glance if it has an 1:1 relationship to error messages.

If not, it might be worth a feature request to ask them to add a unique key for each error type.

The goal of this task is to research if using the library as it is now allows to wire MW's localisation system.

Event Timeline

Also the message parameters (if any) need be available separately.

This comment was removed by Urbanecm_WMF.
Urbanecm_WMF renamed this task from Proof of concept for i18n support with opis/json-schema to Support i18n in validation errors.Dec 18 2023, 8:37 AM
Urbanecm_WMF reopened this task as Open.
Urbanecm_WMF updated the task description. (Show Details)

I stumbled across this task while investigating T317793: [EPIC] Deprecate EventLogging::schemaValidate().

EventLogging::schemaValidate() allows callers to validate data against pre-draft-03 (maybe) JSON Schema schemas. This is not ideal. EventLogging should only be concerned logging analytics events. Those callers should be updated to use some standard JSON Schema validation library. I figured that since MediaWiki Core uses justinrainbow/json-schema, then that's the best option but, as you've encountered here, there are situations where validation errors are shown to users so they'll need to be localised.

Fixing the above is very much a 10% project for me but I'd be more than happy to help out with this effort in that time.

So far I've noted that:

  • justinrainbow/json-schema@5.2.13 can't support this cleanly
    • JsonSchema\Validator#getErrors() returns a list of error descriptors
    • The error descriptors have message, constraint, and more properties
    • message is the complete error message in English
    • In principle, constraint and more should be be enough to reconstruct message
    • In practice, the above is not true for the following values of constraint:
      • dependencies
      • additionalItems
      • format
      • additionalProp
      • requires
      • type
  • justinrainbow/json-schema@dev can support this

OTOH, according to T351878: Consider downgrading opis/json-schema to version 1.1, CC 1.0 is using opis/json-schema 2.x. That task notes that the WikiLambda team decided to use opis/json-schema 1.x. This is also confirmed in T290274#7432359, which is relevant to this task.

The WikiLambda team have done a bunch of work to map opis/json-schema 1.x validation errors to their domain:

KStoller-WMF moved this task from Inbox to Up Next on the Growth-Team board.
KStoller-WMF moved this task from Up Next to Backlog on the Growth-Team board.

Sadly, due to the library version locks that we find for both Opis 2.x and justinrainbow/json-schema@dev we're considering this task a post MVP. At that point we will consider WikiLambda's approach for i18n with Opis 1.X. Thank you so much for the insightful information @phuedx.