A Badges UI for Wikidata

UI to edit what we call "article status indicators" or "Badges".

• See bug 40810 ("Featured and good article badges") and Hennings mockup.
• Blocks bug 56693 ("special page for setting sitelinks needs to allow setting of badges").
• Consider Extension:ArticleStatus (October 2013).

Current implementation

1. For every featured and good article in a language the {{Link FA}} and {{Link GA}} templates are added to the same article in every other language, very similar to how interlanguage links worked before.
2. The templates output empty <span id="interwiki-de-fa"></span> elements.
3. MediaWiki:Common.js detects the empty elements.
4. The script adds class="FA".
5. list-style-image styles from MediaWiki:Vector.css apply.

Users expectation

1. class="FA" is in the HTML output.
2. Styles apply.

We need a master plan

Solve a problem of build a tool?

1. Solve a problem?
   • Analyze what communities are doing right now. Adopt their decissions. Implement. Done.
   • Implement all restrictions that make sense right now.
   • Pro: Can't be misused.
   • Con: Can't be misused.
   • Are we sure what users do is what users want?
2. Build a tool?
   • What is a "Badge"? What can it be?
   • Generalize.
   • Adopd as few decissions as possible. Decissions can change.
   • Implement as few restrictions as possible, as many as required.
   • Pro: Can be used for things nobody had in mind.
   • Con: Can be used for things nobody had in mind.

Don't fix things that aint broken

• Current sitelink UI isn't flawless.
• 94 million tiny edits make historys and diffs confusing.
• But: Very easy to contribute. Tiny edits usually don't break big things.
• So the basic concepts of the current UI should be kept.

Where do Badges go?

• Badges must be stored at the sitelink to avoid redundancy.
• No need to touch Badges when moving articles.
• Allow multiple Badges per sitelink, e.g. "FA" and "Stub" the same time? No: Pick a low hanging fruit. Yes: An oportunity.
• How to avoid clashes, e.g. betweeg FA and GA? Not a problem: Rely on the power of the CSS cascade to properly render class="FA GA". Templates/modules can ask for if FA ... else if GA ....
• Restrict Badges? Yes, please! Similar to the languages. Shouldn't become a bunch of random tags.
• Global or per language? Possibility to use a different class name in a language for the same Badge? No, why? Possibility to give the same class name a different meaning in a language? Hell, no. Will it become a problem if we output class="Stub" to every language even if it is not rendered? Hopefully not. Only downside is a tiny bit of unused HTML. Advantage is the possibility to use user defined styles. So my answer is: Yes, global.

K.I.S.S.

• Reuse save and cancel buttons from existing UI, see screenshot above.

• Badges have localized names only. No icons. Icons are in eachs languages CSS.
• Strict alphabetical order, similar to the languages. Again, specificity of the Badges is encoded in eachs languages CSS.
• Adding duplicates is blocked.
• Adding conflicting Badges is allowed (see above).

Next steps

Split big problems into smaller ones. Look for solutions that fix one problem without making other problems more complicated. Fix one problem. Iterate.

• The list of Badges should be "seeded" with FA and GA. The Wikidata community can add more. Besides other quality Badges ("excellent", "worth reading") users suggested "stub" and "redirect", for example.
• If the major communities agree we can move the FA and GA styles to wikibase.client.css. Smaller communities can override the styles in their locale MediaWiki:Common.js.
• Add the Badge icons to the UI. Redundancy doesn't really matter since the languages use different icons anyway.

Where do Badges come from?

• From a PHP file? Very ugly. Adding a Badge requires developers power, admins can't do it. No good place for metadata. Easy to translate.
• From a protected page in the MediaWiki namespace? Admins do have access. Still ugly and still not a good place for metadata.
• Create a property "instance of" "Wikipedia Badge" and items for all Badges with this property. Very easy to add media files and possibly other metadata. Very easy to translate.

• Need to hard-code one item and the "instance of" property only. List all items that are instances of that item. Alphabetically.
• Allow for dependencies? A "parent" or "superseded by" property results in a tree. Con: +1 hard-coded item ID.
• Maybe reuse Q16467 (Template) or Q16465 (project page) or Q4387444 (category)? No, create new items, one item for each Badge.
• Mix sources? For example a list of properties from a protected MediaWiki page and everything else from the properties? Complicated.