Working With MediaWiki

wikitext, which is mostly comprised of Semantic MediaWiki property tags. Let’s go through those now. (They’re especially useful to know about if you’re editing an existing filter, because the helper form only lets you create new filters, or overwrite the contents of existing filters — it unfortunately doesn’t help with editing existing contents.)
    A filter is defined in a page in the "Filter" namespace. To use the example from before: let’s say that those value for “Has rings” are set by a property also called “Has rings”. (The filter and property don’t have to have the same name.) To define a filter called "Has rings", that filters on the values for the "Has rings" property, you would need a page called "Filter:Has rings", that contains the following:
[[Covers property::Property:Has rings]]
    You can change the display name, or “label”, of each filter, using the “Has label” special property. For instance, maybe the “diameter” filter in the example is just at the page “Filter:Diameter”, but you want the text to be “Diameter, in miles”. This would be done with text like the following:
[[Has label::Diameter, in miles]]
    For properties/filters that are numbers, you probably don’t want each individual number to show up as its own filter value, since there probably isn’t that much overlap among them. That would certainly be the case with the two number fields in figures 19.1 and 19.2, especially with the second field, for the diameter. Instead, you can have such values aggregated into “buckets”, using the “Has value” special property. Here’s how this distribution would be defined in the page “Filter:Diameter”:
[[Has value::< 5000]]
[[Has value::5001 — 10000]]
[[Has value::10001 — 25000]]
[[Has value::25001 — 50000]]
[[Has value::50001 — 100000]]
[[Has value::> 100000]]
    The system parses these values, turning them into numerical distributions.
    Similarly, for properties of type “Date”, you can aggregate their values into buckets of either months or years, by adding one of the following to the filter page:
[[Uses time period::Month]]
[[Uses time period::Year]]
    Filters defined with “Uses time period” would show values such as “March 2013”, or “2013”, instead of individual dates.
    You can have a more search-type interface for a filter, by having the values show up in a combo box, which is a type of dropdown that has autocompletion. Within the combo box, each value just shows up as a string, without a number of pages next to it. This is especially useful for a large set of values, where it might be difficult for users to scan through all the values — in the example, that’s the input used for the “Orbited star” field, because otherwise there would be too many values to deal with. To set up a combo box for the filter, just add the following to the filter page:
[[Has input type::combo box]]
    Using a combo box input can sometimes help significantly in improving the performance of Special:BrowseData, because it means that the page no longer has to calculate and display the number of pages corresponding to each of the values for that filter. If there are a lot of values, the number of database queries to generate all of those numbers can really add up.
    For date filters specifically (i.e., filters that correspond to date properties), you can do something similar to the “combo box” approach by letting the user manually enter a date range to look in, by adding the following to the filter page:
[[Has input type::date range]]
    As with the combo box input, a date range input can improve performance, though it might make for a less usable interface.
    So, you’ve created a filter. Now what — how do you get it show up in Special:BrowseData for a certain category? To do that, you just need to link to the filter from the category page using the special "Has filter" property. For our example, in the page "Category:Planets", you would add something like the following:
[[Has filter::Filter:Diameter]]
    There’s an alternate way to create filters for categories, which is via the Page Schemas extension. This approach involves storing the filter data via XML and thus doesn’t involve filter pages at all — which might be conceptually simpler. You can see more information about Page Schemas here .
Setting display of results
    The tag-cloud-style display of results in the example shown, where the font size of a value is determined by how many pages it