Elite Dangerous Field Manual:Page section resolution

EDFM // Operations

How EDFM resolves article header eyebrows from page context instead of page-title duplication.

EDFM article pages use a centralized context resolver so the eyebrow above the page title answers where in EDFM the reader is, while the H1 answers what page the reader is reading.

The resolver tracks three related but separate concepts:

• primary section — the broad EDFM area, such as Engineering, Mining, or Ships & Equipment;
• secondary context — a narrower collection when EDFM has a meaningful one, such as Ships, Modules, Weapons, or Engineers;
• content type — the format or purpose of the page, currently Field Procedures.

The visible eyebrow stays compact and normally renders at most two contextual segments after the plain-text EDFM // label:

EDFM // Ships & Equipment / Modules
Frame Shift Drive

For pages with a meaningful content type, the content type takes display priority over the ordinary secondary context:

EDFM // Engineering / Field Procedures
Unlocking Broo Tarquin

Internally, Unlocking Broo Tarquin still resolves to secondary context Engineers; the eyebrow simply displays Field Procedures instead because content type is the more useful second visible segment.

Normal author workflow

Most pages should use:

{{Article header|deck=Optional one-line page summary.}}

Field Procedure pages should normally use:

{{Field procedure|summary=Short task summary.}}

Do not normally set an eyebrow manually. The header calls Module:PageContext, which resolves primary section, secondary context, and optional content type from structured data and central rules. Visible primary/secondary/type segments are rendered as ordinary MediaWiki internal links when Module:Data/PageSections defines a verified canonical destination. EDFM // itself remains plain text.

Display priority

1. Render the primary section if known; otherwise render fallback Reference.
2. For the second visible segment, render meaningful content type first.
3. If there is no content type, render meaningful secondary context.
4. If neither exists, render no second segment.

The eyebrow is contextual navigation, not a complete breadcrumb trail. Do not expand it into long chains such as EDFM // Engineering / Engineers / Field Procedures.

Primary section resolution order

1. Explicit override —

   EDFM // Combat

   or topic=.
2. Structured procedure metadata — for example mining procedure records carry a topic such as Mining.
3. Structured unlock target metadata — Unlocking Name resolves through the canonical Engineer data for Name.
4. Structured page/content type — existing canonical data/index pages, including Engineers, ships, ship modules, ship weapons, and mining datasets.
5. Exact central hub mappings — section and hub pages such as Engineering, Mining, Powerplay, and Ships and Equipment.
6. Conservative topic-family rules — Guardian, Thargoid/Xeno, and AX naming rules.
7. Small exceptional override map — currently empty.
8. Fallback — unknown pages resolve to Reference.

Secondary context resolution order

1. Explicit override —

   EDFM // Reference / Engineers

   or secondaryContext=.
2. Exact central hub mappings — for hub/index pages and ordinary pages such as Engineer Unlock Guide.
3. Structured unlock target metadata — Unlocking Name retains secondary context Engineers when Name is an Engineer.
4. Structured page/content type — mapped page types such as ship, ship_module, ship_weapon, and engineer.
5. Small exceptional override map — currently empty.
6. None — ordinary topical pages do not receive a manufactured second segment.

Content type resolution order

1. Explicit override —

   EDFM // Reference

   .
2. Structured/shared content-type signal — mining procedure data or Engineer-unlock procedure target data.
3. Centralized content-type family rule — conservative How to ... and Unlocking ... rules, after structured checks.
4. Small exceptional override map — currently empty.
5. None — normal articles do not receive a content-type segment.

If a content type exists but the primary section falls all the way back to Reference, Template:Article header suppresses the suffix unless a primary section was explicitly provided. This avoids noisy output such as EDFM // Reference / Field Procedures for unresolved procedure pages.

Canonical destinations

Canonical linked destinations are centralized in Module:Data/PageSections:

• Reference → Game Reference
• Ships & Equipment → Ships and Equipment
• Ships → Ships
• Modules → Ship Modules
• Engineering → Engineering
• Engineers → Engineers
• Mining → Mining
• Field Procedures → Field Procedures

A context may intentionally have no linked destination. For example, Weapons is recognized as a secondary context, but there is currently no suitable live weapons hub page; until one exists, the label renders as plain text.

The renderer suppresses self-links by comparing normalized MediaWiki titles, so the Ships page can show EDFM // Ships & Equipment / Ships while only linking the primary section.

Structured integrations

Current integrations include:

• Ship pages from Module:Data/Ships/index, generated from the canonical Ships directory table → Ships & Equipment / Ships
• Engineer pages from Module:Data/Engineers/index → Engineering / Engineers
• Engineer unlock procedure pages such as Unlocking Broo Tarquin → primary topic from the target Engineer record, secondary context Engineers, content type Field Procedures
• Ship module pages from Module:Data/ShipModules/index and Module:Data/Modules/index → Ships & Equipment / Modules
• Ship weapon pages identified through Module:Data/Modules/index records with subcategory Weapon → Ships & Equipment / Weapons
• Guardian module pages identified through the module index and Guardian naming → Guardian Technology
• Thargoid/Xeno/AX module pages identified through the module index and xeno naming → Thargoids
• Mining method/equipment/location/commodity datasets → Mining
• Mining procedure records in Module:Data/Procedures/Mining → primary topic from the record, content type Field Procedures

If EDFM adds a new canonical dataset, add a lightweight detector in Module:PageContext and map the resulting type in Module:Data/PageSections. Do not duplicate every individual page into a hand-maintained lookup table.

Manual overrides

Use overrides only when a page is intentionally cross-topic or cannot be identified cleanly from data/rules:

{{Article header
 |section=Engineering
 |context=Engineers
 |type=Field Procedures
 |deck=Optional one-line summary.
}}

If many pages require overrides, improve the structured data or page-family rules instead.

Public Lua interface

Module:PageContext exposes semantic interfaces:

• getPrimarySection — returns a plain section name such as Engineering.
• getSecondaryContext — returns a plain context name such as Engineers, or blank.
• getContentType — returns a type such as Field Procedures, or blank for normal articles.
• getContext — returns encoded context with primarySection, optional secondaryContext, and optional contentType objects.
• getPageType — returns an internal page type such as engineer, ship, ship_module, ship_weapon, or field_procedure where known.
• eyebrow — returns complete plain presentation text for compatibility/testing.
• renderEyebrowBody — used by Template:Article header to render linked primary/display context segments after plain EDFM //.

Testing

Representative parser tests:

{{#invoke:PageContext|getPrimarySection|page=Frame Shift Drive}}
{{#invoke:PageContext|getSecondaryContext|page=Frame Shift Drive}}
{{#invoke:PageContext|getPrimarySection|page=Felicity Farseer}}
{{#invoke:PageContext|getSecondaryContext|page=Felicity Farseer}}
{{#invoke:PageContext|getPrimarySection|page=Unlocking Broo Tarquin}}
{{#invoke:PageContext|getSecondaryContext|page=Unlocking Broo Tarquin}}
{{#invoke:PageContext|getContentType|page=Unlocking Broo Tarquin}}
{{#invoke:PageContext|getContext|page=Unlocking Broo Tarquin}}
{{#invoke:PageContext|eyebrow|page=Resolver Sandbox Unknown}}
{{#invoke:PageContext|eyebrow|page=Frame Shift Drive|section=Combat|context=Modules|type=Field Procedures}}

Then verify rendered pages include exactly one visible eyebrow, retain the semantic H1, and do not show Lua/script errors.