Template:Category/Project

Render template for Category:Project pages.

Called by the SemanticSchemas dispatcher when a page belongs to Category:Project. Renders a project-shaped masthead in place of the default property table, then a structured "Related content" set of sections that surface every page tagged <this> grouped by content type.

Renders, top to bottom:

• Status badge — pill in the top-right corner, color-coded

 per Has project status (Active / Maintained / In Development /
 Planned / Deprecated / Cancelled).

• Kicker — Status · Start year · License (any subset present;

 separators only between adjacent values).

• Description — Has description (required field) rendered as

 an italic accent-bordered lead paragraph.

• Goal — Has goal, if set, rendered below the lead with a

 small "Goal:" label.

• Action chips — Repository, Website, DOI; each only renders

 when its source property is set so a project with no repo URL
 doesn't show a broken chip.

• Funding — small note line under the chips, if Has funding

 is set.

• Related content sections — h2 per content type (Guides,

 FAQs, Publications, Workshops, SOPs), each running an
 #ask filtered by {{{page}}}.
 Empty sections render their h2 plus an italic "No X yet." line —
 acceptable noise; signals to a viewer "this project has no
 guides yet, maybe add one" rather than hiding the affordance.

Why structured sections instead of the auto-footer: Category:Project carries show_backlinks_for=Has project, so SemanticSchemas's auto-rendered category footer already lists every page that links here. That footer is a flat "Pages linking here" list — fine, but it doesn't group by content type and it includes everything (Events, Training records, Stock entries, ...). The structured sections above target the content types a typical visitor actually wants to find (the project's guides, FAQs, etc.). Both render — the auto-footer sits below this template's output — so a visitor looking for the kitchen-sink view scrolls past these sections to find it.

Why some related-content lists may include admin-namespace pages

The lists below don't filter by namespace, so an admin-namespace guide (e.g. Workshop admin:Setting up a new Workshop) tagged with this project will appear here. The public Guides directory (UI/guides_library) does filter those out row-side, but doing the same here would mean projecting through a row template for each section — more wikitext, more cost. For the typical case (no admin-namespace cross-tagging) the lists are identical to the public view; for the rare case, the admin page surfacing on the Project page is acceptable since the page itself is admin-restricted via the wiki's permissions.

Properties read:

• Has project status, Has start date,

 Has end date, Has license,
 Has description, Has goal,
 Has repository url, Has website,
 Has DOI, Has funding

Parameters:

• category — "Project" (informational)
• page — the page being rendered. Falls back to

 Template:Category/Project.

Visual treatment lives in Template:Category/Project/styles.css — change there to restyle every Project, or override the underlying --labki-* tokens in a wiki's MediaWiki:Common.css to retheme just one wiki.