Template:UI/faqs library
Curated FAQs library page. Drop
FAQs
Frequently-asked questions across the community — short answers, with links to the in-depth guides when you need more.
1FAQs0Distinct topics
into a content page (e.g. the wiki's FAQs page) to
render a searchable, filterable accordion view of every page in
Category:FAQ.
Renders, top to bottom:
- Header — h1 title + lead paragraph + a stat strip showing
total FAQ count and distinct guide-topic count.
- Filtered FAQ list — an SRF
format=filteredask
that pairs the Template:UI/faqs_library/entry row partial
with client-side filter controls for Guide topic, Workflow stage,
Audience level, and Project. Each row renders as an
mw-collapsible accordion: question always visible
(clickable as a page link), answer expanded inline on toggle.
Project (Has project, Page-typed, multi-valued) is surfaced as a sidebar-only facet — useful filter, but the chip would clutter the row. Same pattern as Keyword + Project in Template:UI/publications_library: positional arg passed by the parent#askso SRF can see the values, row partial ignores it.
Why format=filtered for FAQs
FAQs are the canonical "I have a single question and want to find
it" use case. Faceting by topic / workflow stage / audience level
turns the page into a directory; collapsed-by-default rows keep the
page scannable when there are 50+ entries. Same SRF dependency as
the publications library — the deployment must ship Semantic
Result Formats with the filtered format enabled and
its JS/CSS module loaded.
If a future deployment ships without SRF, the fallback is a plain
format=template list using
Template:UI/faqs_library/entry (still functional — the row
partial degrades to "always-expanded" because the
mw-collapsible class is inert without MW's JS module).
There's no chip-strip + Special:SearchByProperty
no-JS path here; the page-fork to SearchByProperty is
worse UX for an FAQ list than just rendering every answer inline.
Why the filtered-list entry partial takes positional args
Same rationale as Template:UI/publications_library: SRF's
list view named args=yes prefixes every param name
with a literal ?, which makes the row template
read etc. — fragile if SRF changes
that convention. Dropping list view named args=yes
and using positional {{{1}}}..{{{N}}} is the cleaner
shape. SRF guarantees positional order matches the declared
printout order, so the contract is stable.
Printout aliases (=Topic, =Stage,
=Audience, =Project) are still set
because SRF uses them as the filter sidebar labels. Pretty labels
for filters; positional args for rendering.
Why the answer is a property, not the page body
The library renders Has answer inline so the user
never leaves the page when they expand a row. An FAQ whose answer
lives only in the page body (free-form wikitext below the
dispatcher template) will still appear in the library, but its
expanded row falls back to a "View full answer on page →" link —
see Template:UI/faqs_library/entry for the empty-answer
handling.
Parameters (all optional)
heading— page heading (default: "FAQs"). Empty
string suppresses the <h1>.
lead— short intro paragraph below the heading
(default: a generic explainer about Q+A topics).
limit— how many FAQs to load into the filtered
list (default: 200). Set higher than a normal feed because filtering happens client-side over the loaded result set: too low a limit hides matching FAQs from the filter UI.
Cross-template dependencies
- Template:UI/faqs_library/entry — row partial for the
filtered list.
- Template:UI/kpi_card — used for the stat strip.
- Semantic Result Formats with the filtered format enabled
($srfgFormatsincludesfiltered). The filtered-format JS/CSS resources must be loaded; without them the list will render but the filter sidebar will be inert.
- MediaWiki's
mediawiki.page.collapsiblemodule must
be loadable on the target wiki — it's part of core, so this is effectively always satisfied. Without it, the accordion rows stay always-expanded (functional, just verbose).