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 two independent dimensions:

• primary topic/section — what part of Elite Dangerous the page is about;
• optional content type — what kind of EDFM content it is, currently used for meaningful structural types such as Field Procedures.

Normal output looks like:

EDFM // Engineering
Felicity Farseer

For a procedure, output can include both dimensions:

EDFM // Engineering / Field Procedures
Unlocking Broo Tarquin

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 the primary topic and optional content type from structured data and central rules.

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, ship modules, 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.

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 second 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.

Structured integrations

Current integrations include:

• Engineer pages from Module:Data/Engineers/index → Engineering
• Engineer unlock procedure pages such as Unlocking Broo Tarquin → primary topic from the target Engineer record, content type Field Procedures
• Ship module pages from Module:Data/ShipModules/index and Module:Data/Modules/index → Ships & Equipment
• 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
 |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.
• getContentType — returns a type such as Field Procedures, or blank for normal articles.
• getContext — returns encoded context with primarySection and optional contentType.
• getPageType — returns an internal page type such as engineer, ship_module, or field_procedure where known.
• eyebrow — returns complete presentation text for compatibility/testing.

Testing

Representative parser tests:

{{#invoke:PageContext|getPrimarySection|page=Frame Shift Drive}}
{{#invoke:PageContext|getPrimarySection|page=Felicity Farseer}}
{{#invoke:PageContext|getPrimarySection|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|type=Field Procedures}}

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