feat(server): display custom list metadata (e.g. nutrition) on recipe pages

[Tloxipeuhca]

Closes #459

Summary

• Any non-standard YAML frontmatter key whose value is a list (e.g. nutrition:) is now shown as its own line below the tags on the recipe and menu pages — one line per family, no code changes needed to support new families.
• nutrition: entries get a matching icon (Tabler Icons, MIT license, inlined as SVG — no new dependency) picked by keyword in the unit text: kcal/energy → flame, protein → meat, lipid/fat → droplet, sugar → candy, fiber → wheat. Unrecognized families/units render as a plain bullet.
• The recipe list page shows a compact 🔥 X kcal badge next to the tags when a recipe has nutrition: with a kcal entry.
• Entries are written as value%unit (e.g. 258%kcal) and displayed as 258 kcal.
• New: nutrition: also supports a mapping form (nutrition: {kcal: 234, proteins: 9.8, ...}) alongside the original list form, with per-field unit inference (kcal → kcal, everything else → g) and 3 additional nutrient fields (saturated-fat, carbohydrates, salt) with matching icons.
• New: a file family (created-by/created-at/modified-by/modified-at) is now recognized, with person/calendar/pencil/history icons.
• New: nutrient and file-metadata field names are translated into the viewer's UI language via the existing Fluent i18n system, across all 7 supported locales (de-DE, en-US, es-ES, eu-ES, fr-FR, nl-NL, sv-SE).
• New: a YAML key prefixed with . is hidden from the recipe page, at either the family level (.file:) or a single mapping entry (.lipids:) — useful for metadata you want in the file but not shown to readers.
• Refactored per-family rendering into src/web/family_renderers/ (mod.rs + generic.rs + nutrition.rs + file.rs): a small FamilyRenderer trait with a generic fallback, and an explicit renderer_for() registry so adding a future specific renderer only touches one match arm.
• Documented the convention in docs/server.md ("Custom Metadata Families").

Test plan

• cargo build, cargo clippy --all-targets (clean, no warnings), cargo fmt --check — all pass.
• Manually tested with a real ~250-recipe collection using both the list and mapping nutrition: forms, via cargo run -- server:
  • Recipe detail page renders one "Nutrition" line with correct icons for kcal/protein/lipid/carbs/salt/sugar/fiber, in both YAML forms.
  • file:/meta: metadata renders with the expected icons and translated labels.
  • Switching the UI locale correctly translates nutrient/file-metadata labels.
  • Keys prefixed with . (family-level and entry-level) are correctly hidden.
  • Nested non-list, non-mapping metadata is correctly ignored — does not render as a spurious line.
  • List page shows the kcal badge next to tags.
• Screenshots on request if useful for review.

🤖 Generated with Claude Code

[Tloxipeuhca]

Update: mapping form, i18n, dot-hiding, generic fallback

Following review discussion, this PR now also supports:

Mapping form + 3 new nutrition fields

nutrition: can now be written as a mapping (recommended) instead of a list, with per-field unit inference (kcal → kcal, everything else → g):

nutrition:
  kcal: 234
  proteins: 9.8
  lipids: 17.6
  saturated-fat: 6.2
  carbohydrates: 18.4
  sugars: 8.9
  fibers: 0.9
  salt: 1.85

The original list form (- "258%kcal") still works too, unchanged.

New file: family

file:
  created-by: Yannick
  created-at: 2026-08-20
  modified-by: Yannick
  modified-at: 2026-08-24

Renders as its own line with person/calendar/pencil/history icons and a translated "Label: value" per entry. file: and meta: are both accepted as the family key.

Generic fallback (any other family, still works exactly as before)

allergens:
  - gluten
  - tree nuts
origin:
  country: France
  region: Alsace

Any YAML key that isn't nutrition or file/meta still renders automatically — list entries as-authored, mapping entries as field: value, no icon, no code change required. nutrition and file/meta are just the two families that opted into specific icons/formatting.

.-prefix hiding

Prefix a key with . to hide it from the recipe page:

.internal-notes:
  - draft, not ready for print
nutrition:
  kcal: 234
  .lipids: 17.6   # hidden; the rest of the nutrition line still shows

Works at the family level (.internal-notes: hides the whole line) and at the single-entry level inside a mapping (.lipids: hides just that one chip).

i18n

Nutrient names and the file/meta labels are translated into the viewer's UI language across all 7 supported locales, including correct French typography (space before :).

Refactor

Renderer logic moved to src/web/family_renderers/ (mod.rs + generic.rs + nutrition.rs + file.rs) — a small FamilyRenderer trait, generic default, and an explicit renderer_for() registry so a future specific renderer is one match arm + one file.

cargo build, cargo clippy --all-targets, cargo fmt --check all clean.

[Tloxipeuhca]

Screenshot of the mapping-form nutrition + file metadata rendering (fr-FR locale):

1. Recipe list page — the Tarte Flambée card shows a compact 🔥 1443 kcal badge next to its tags, pulled from the nutrition.kcal mapping entry; other cards without nutrition: show no badge.
2. English locale (Accept-Language: en-US) — same recipe, same FILE/NUTRITION lines in English (Modified at, Modified by, fat, saturated fat, carbohydrates, sugars, fiber, proteins, salt).
3. French locale (Accept-Language: fr-FR) — recipe page showing the FILE line (Modifié le : 2026-08-24, Modifié par : Yannick, note the French space before :) and the NUTRITION line with all 8 fields translated (lipides, graisses saturées, glucides, sucres, fibres, protéines, sel) plus their icons.

[Tloxipeuhca]

Closes #459

[dubadub]

Thanks for that, will review in a day or two

[Tloxipeuhca]

Hey @dubadub, just checking in on this when you have a chance. Thanks!

[Tloxipeuhca]

Hey @dubadub, just checking in on this when you have a chance. Thanks!

[dubadub]

Hi @Tloxipeuhca , sorry took me a while to get back to it. I like your idea of having separate rows per nested group. And also implementation is solid..

I'd fist pass some changes through the spec proposal (conventions file in a spec repo), so we can get the community feedback on these newly added conventions. This because people have diverse use-cases we might not think and instead of later making updates and migration scripts, I'd get feedback beforehand.

For example, exact keys for nutrition metadata should be listed in conventions metadata section, so all apps on the same page. Also some choices should be considered: should it display per serving, per 100g or per recipe? Or support all of these? In some case I would expect it to scale with the recipe, that requires parser update.

Also for prefixing with a dot, like the idea, but I'd first run it through proposal as well (probably easier than nutrition stuff).