Page MenuHomePhabricator

Use MoSCoW wording for different constraint ranks
Open, Needs TriagePublic

Description

In T204439 the suggestion constraint level was introduced. This really improved the constraint system. We now have 3 constraint levels: Mandatory, normal and suggestion. The distinction between the normal and the suggestion level isn't clear enough at the moment leading to confusion. The wording is (almost) the same and just the header is different. This distinction in levels should be made clearer.

The MoSCoW method is a well known practice to assign priorities.

  • Mandatory level is must have
  • Normal level is should have
  • Suggestion level is could have

( The system used for priorities in rfc's is quite similar, see https://tools.ietf.org/html/bcp14 )
This is a well known system so should be easy to translate into other languages.

So for target required claim the normal message is:
"wbqc-violation-message-target-required-claim": "$1 should have {{PLURAL:$3|0=a statement $2.|1=a statement $2 $5.|a statement for $2 with one of the following values:$4}}",

For the mandatory level you would get:
"wbqc-violation-message-target-required-claim-mandatory": "$1 must have {{PLURAL:$3|0=a statement $2.|1=a statement $2 $5.|a statement for $2 with one of the following values:$4}}",

For the suggestion level you would get:
"wbqc-violation-message-target-required-claim-suggestion": "$1 could have {{PLURAL:$3|0=a statement $2.|1=a statement $2 $5.|a statement for $2 with one of the following values:$4}}",

(based on the messages in https://github.com/wikimedia/mediawiki-extensions-WikibaseQualityConstraints/blob/master/i18n/en.json)

I broke it up in several messages because Lego i18n is discouraged. In the software we could check if the level is mandatory/suggestion and if that's the case, check if a message of that level exists. If that's the case, use the level message otherwise the default.

Event Timeline

That sounds reasonable. I think we should ask the community first, what do you think @Lydia_Pintscher?

In the software we could check if the level is mandatory/suggestion and if that's the case, check if a message of that level exists. If that's the case, use the level message otherwise the default.

With language fallbacks, this isn’t as clear as it sounds. Wikibase does a similar thing with its localized edit summaries (implemented in AutoCommentFormatter::getSummaryMessage): edit summary messages exist in several variants, e. g. wikibase-entity-summary-wbeditentity-create and wikibase-item-summary-wbeditentity-create, and it first checks whether the entity type-specific message exists before falling back to the generic “entity” message. I thought the intention of this was to let a generic translation take precedence over an entity type-specific version in a fallback language; however, it looks like if the entity type-specific message has an English translation, then it will always exist for the purposes of this check, and never fall back to the generic “entity” message even if that one is translated. For example, this diff in Scots still displays “Created a new Item” (item, English) and not “Creatit a new entity” (entity, Scots). I’m not sure if this is the intended behavior in Wikibase, or if it’s what we want in WikibaseQualityConstraints.

This makes sense to me too from a quick look. A quick check on the corresponding wiki project is probably a good idea though.

@Lucas_Werkmeister_WMDE do we already have different messages for the different levels or would this need to be introduced? Is this just a matter of changing a message or a larger change?

@Lucas_Werkmeister_WMDE do we already have different messages for the different levels or would this need to be introduced? Is this just a matter of changing a message or a larger change?

We would need to split up the messages, right now the message is the same regardless of constraint status. (Usually it’s a single message per constraint type, but some constraint types have several methods too.)