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

Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptJul 6 2019, 5:01 PM

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.