Combining templates

Not super smart on templates, but is it possible to combine {{Should be PNG}} and {{PNG version available}} into a single template? I am imagining something like {{PNG image}} with a parameter to change the type to either of the two current templates and also add the appropriate category to mark the content. This would also open the possibility for future types to be created as needed instead of creating even more templates. Evan.oltmanns (talk) 19:19, 25 January 2026 (UTC)

I'm not sure it would make sense to combine them, given they're giving two rather distinct messages. Primefac (talk) 19:26, 25 January 2026 (UTC)

The idea would be to use #switch in order to handle the appropriate output text, category, and formatting as needed. Evan.oltmanns (talk) 00:29, 26 January 2026 (UTC)

I can see the logic in desire for a single template for low-quality images both before and after they have PNG alternates, but the function in those two instances is so divergent, I would hesitate to make a template with the double function. The proposed name is also problematic as it suggests that the tagged file is a PNG, rather than it needs or points to a PNG alternative, but that's a much more transient concern. The inexorable problem I am envisioning is that you either have to have an explicit flag to choose between the two behaviors, or you set it based on a parameter value for the alternate PNG version filename being provided. If you use the explicit flag, you run into the issue that not providing that filename presents an ambiguity - was the flag parameter set in error, or is there a mystery PNG version out there that we don't know where it's located? On the other hand, filename parameter-based functionality precludes tracking categories for files that ostensibly have a PNG version available, but the filename isn't provided. It is a fundamental drawback to combining these two templates that cannot be overcome: you lose either functionality or introduce ambiguity to your maintenance tracking. Templates need to be designed on the basis of fixing imperfect usage, not on the assumption of perfect rollout. VanIsaac, GHTV ^contr_about 01:18, 26 January 2026 (UTC)

If there were an argument here for a merge, it would be {{should be PNG}} and {{should be SVG}} as {{should be file type|SVG}}, but even those are pretty different. Izno (talk) 02:56, 26 January 2026 (UTC)

Suggestion: add a simple beginner example

Hi! I am a new contributor learning templates.

I noticed that the page is very detailed, but beginners might benefit from a very small, simple example early on (for example showing

This is an example of a template. For help with templates, see Help:Template.

usage with a short explanation).

If this sounds reasonable, I would be happy to help draft the text here. Thank you! Stitipragyan barik (talk) 18:10, 4 February 2026 (UTC)

Hi, which page(s) are/were you looking at for help? We have (for better or worse) a ton of pages related to templates, including WP:Templates and Help:Template, so what you're looking to create might already exist (just want to make sure of that before time and effort is spent). Primefac (talk) 11:11, 10 February 2026 (UTC)

Somewhat related discussion from a couple years ago: Help talk:Introduction#Why is there no "template" sub-topic?. —⁠andrybak (talk) 04:01, 11 February 2026 (UTC)

Help with a WP banner template image

I recently fixed up a couple Templates using File:Barnstar search rescue.png, but I'm having trouble with the last one, Template:WikiProject_Article_Rescue_Squadron. Nothing I do seems to make the image appear properly. It currently includes:

|IMAGE_LEFT          = Barnstar search rescue.png
|IMAGE_LEFT_SIZE     = 70px

This seems like it should work. I tried adding "File:" to the IMAGE_LEFT parameter and removing the IMAGE_LEFT_SIZE parameter. Neither made the image show up in the preview. What am I doing wrong? TIA! WidgetKid ^converse 15:40, 19 February 2026 (UTC)

It looks fine to me. What doesn't look right to you? — Martin (MSGJ · talk) 16:11, 19 February 2026 (UTC)

@MSGJ, it now appears to be working fine. ¯\_(ツ)_/¯ Maybe I just needed to clear my browser cache or something. Thanks anyway! WidgetKid ^Converse 19:24, 1 March 2026 (UTC)

Assistance on Infobox social media personality

I made a suggestion on adding another site to it in mid-January, got decently positive feedback with a request to do more research, and then I got busy for awhile before I could finish that research. I finished a week ago, and my reading of the consensus is that it should be added, but neither of the other editors in the thread have responded, and given that I do not have much experience with templates, I do not want to make the change myself without further feedback, so I am wondering if someone else could look over the situation and see if they agree it should be added and that my code is not broken. 1brianm7 (talk) 19:18, 1 March 2026 (UTC)

Performers in festival navboxes

Any input at Template talk:Woodstock#Performers would be appreciated. --woodensuperman 11:36, 10 March 2026 (UTC)

Your feedback requested at Talk header Rfc

There is currently an Rfc being held to discuss the appearance of the {{Talk header}} template. Your feedback at Template talk:Talk header would be appreciated. Thanks, Mathglot (talk) 02:17, 31 March 2026 (UTC)

Discussion at Template talk:Interlanguage link § calling WikiData and other wikimedia projects

 You are invited to join the discussion at Template talk:Interlanguage link § calling WikiData and other wikimedia projects. CapnZapp (talk) 21:31, 5 April 2026 (UTC)

Where to put styles.css of a template's sandbox?

There are two conventions that are in conflict when trying to decide where to put styles.css page of a template's sandbox:

1. Every sandbox of page Template:Foo is located at Template:Foo/sandbox
2. Every TemplateStyles page styles.css for a page Template:Foo is located at Template:Foo/styles.css

This means that if Template:Foo is styled with Template:Foo/styles.css, then styles.css of its sandbox Template:Foo/sandbox has two potential locations:

1. Following the first convention: sandbox of Template:Foo/styles.css is at Template:Foo/styles.css/sandbox
2. Following the second convention: styles.css of Template:Foo/sandbox is at Template:Foo/sandbox/styles.css

Which of the two options is preferable? —⁠andrybak (talk) 14:50, 18 April 2026 (UTC)

Notified: Template talk:Uses TemplateStyles, Wikipedia talk:TemplateStyles, Wikipedia:Village pump (technical). —⁠andrybak (talk) 14:57, 18 April 2026 (UTC)

According to Wikipedia:TemplateStyles, In general, this means that a style page should be a subpage of the related template, so the second convention is appropriate. If we're seeing a lot of this out in the wild, we should probably make sure everything is standardised. Primefac (talk) 14:56, 18 April 2026 (UTC)

I've been a bit confused about this myself. I think the issue here stems from a difference of interpretation of what the two copies of "styles.css" are for. There are two interpretations:

1. The "styles.css" used by the template sandbox isn't for the live template at Template:Foo, but rather for a distinct copy of the template at Template:Foo/sandbox. Each of these two templates has its own "styles.css".
2. The second copy of "styles.css" is a sandbox copy of the live version of "styles.css", not a copy of "styles.css" for use by the template at Template:Foo/sandbox. Both the live and sandbox templates should use the same "styles.css" unless testing changes to the stylesheet, with the sandbox of "styles.css" at styles.css/sandbox being used to test changes to "styles.css" rather than direct changes to the template.

If you follow the first interpretation of the purpose of the second copy of "styles.css", then logically following the first convention, that every sandbox page is located at the title of the page followed by /sandbox, agrees with using Template:Foo/sandbox/styles.css for the "styles.css" used by the sandbox copy of the template, since the second copy isn't itself a sandbox, it's just the stylesheet for the sandbox.

If you follow the second interpretation, then logically following the first convention agrees instead with using Template:Foo/styles.css/sandbox.

I think we should adopt and enforce interpretation 2, since there's no reason for Template:Foo/sandbox to have its own separate "styles.css" unless you're testing changes to to "styles.css", and the sandbox copy is logically where you would use to observe these tests. The convention then, would be that the sandbox copy of a page always consistently ends with /sandbox, regardless of whether the page is a template, a stylesheet, a module, etc. and to use the live version you would simply omit /sandbox. (Edit: I now support adopting and enforcing the /sandbox/styles.css convention, for the technical reasons highlighted below.)

Regardless of what we decide, Wikipedia:TemplateStyles § Naming convention should be updated to clearly and explicit state what editors should do. – Scyrme (talk) 15:36, 18 April 2026 (UTC)

I've always followed the second convention, because my mental model is that everything that is experimental should go into the sandbox subarticle. — hike395 (talk) 15:43, 18 April 2026 (UTC)

That's fair, but it runs up against the issue of how to interpret which page is the "parent" of its "child" subpages. Is it Template:Foo or Template:Foo/styles.css? I don't think there's a "right" answer here, but to me the latter seems much more straightforward if you think about the case where a template has another template as a subpage (Template:Foo/Bar) instead of a stylesheet as a subpage. Simply appending /sandbox is what would automatically happen if you clicked the "create" link in the documentation box of a subtemplate, for example if you were to create a sandbox for {{GHS Reference/cs1}}, which is a subpage of {{GHS Reference}}. – Scyrme (talk) 16:23, 18 April 2026 (UTC)

Another thing to consider is if we want all stylesheets to always end with .css. If that's desirable, perhaps the convention should be that we use /sandbox for the template's sandbox, and /sandbox.css for the sandbox of "styles.css"? This could also make it clearer that the second copy of the stylesheet is for testing changes to the stylesheet. – Scyrme (talk) 15:47, 18 April 2026 (UTC)

There are currently 39 pages with styles.css/sandbox. Around 34 of them were created at sandbox/styles.css but moved by Gonnym. There are 97 with sandbox/styles.css. Sampling didn't find any which had been moved so without Gonnym it would be around 5 versus 131. I also support sandbox/styles.css. It's expected that CSS pages end in .css, also by MediaWiki. If it's created at styles.css/sandbox then an administrator is required to change the content type to Sanitized CSS like in . This is impractical and likely to confuse many editors. PrimeHunter (talk) 16:19, 18 April 2026 (UTC)

Could adopting the use of /sandbox.css for stylesheet sandboxes work (as I suggested earlier)? Or would that also cause problems? – Scyrme (talk) 16:29, 18 April 2026 (UTC)

/sandbox.css would be created as Sanitized CSS and avoid the mentioned issue but I still prefer sandbox/styles.css. Template:Foo/styles.css/sandbox.css looks odd to me and editors are used to Template:Foo/sandbox/styles.css. PrimeHunter (talk) 16:47, 18 April 2026 (UTC)

To clarify, I was suggesting just using Template:Foo/sandbox.css not Template:Foo/styles.css/sandbox.css. ie. We'd be changing the guideline away from always using "styles.css", so that sandbox versions of the stylesheet are instead called "sandbox.css", and only live stylesheets are called "styles.css". Is there a technical reason why the stylesheet must be at a directory which includes "styles.css"? Or has doing so just been a convention? – Scyrme (talk) 17:02, 18 April 2026 (UTC)

TemplateStyles pages should normally be created at a ".css" title in the Template or Module namespace, to avoid having to have an administrator have to fix the content model. Even though WMF has recently changed things to allow people to create a page with a non-default content model using Special:ChangeContentModel, it's still likely that editors would create the page first, then realize it was wrong, and then have to have an admin fix it. Anomie⚔ 17:23, 18 April 2026 (UTC)

but moved by Gonnym Sadly, this does not surprise me. Anomie⚔ 17:23, 18 April 2026 (UTC)

Module namespace also has styles.css pages. When module namespace is included, first search gains 4: 39 → 43, second search gains 33: 97 → 130. —⁠andrybak (talk) 18:48, 18 April 2026 (UTC)

Looking at these examples I noticed another reason for consistently using /sandbox/styles.css, namely that {{Uses TemplateStyles}} expects and only detects the existence of a sandbox stylesheet if it's located at /sandbox/styles.css, but not if it's located at /styles.css/sandbox. If the stylesheet is located at the latter, no "(sandbox)" link is displayed.

We should probably move all the existing examples using /styles.css/sandbox to fix navigation. – Scyrme (talk) 19:31, 18 April 2026 (UTC)

Just for reference regarding {{Uses TemplateStyles}} expects and only detects the existence of a sandbox stylesheet if it's located at /sandbox/styles.css, but not if it's located at /styles.css/sandbox – this iteration of the logic in the underlying module was implemented in Special:Diff/861001237 per discussion at Wikipedia talk:TemplateStyles/Archive 1#Sandbox naming convention. —⁠andrybak (talk) 19:41, 18 April 2026 (UTC)

@Andrybak: Thank you for digging that out! I knew that it had been discussed before, I didn't think to go back almost eight years. RexxS (talk · contribs) raised some good points there. --Redrose64 🌹 (talk) 21:04, 18 April 2026 (UTC)

Template:Foo/sandbox/styles.css makes most sense to me. It's virtually certain that any real sandbox testing of the styles is going to also require use of Template:Foo/sandbox, if only to change the <templatestyles /> to point to the sandbox version, and in relation to that Template:Foo/sandbox/styles.css is more logical. Template:Foo/styles.css/sandbox lacks the ".css" extension, which is likely to cause problems and only makes sense if you're somehow trying to test changes to the styles in isolation from any changes to the parent template. Template:Foo/styles.css/sandbox.css just seems strange, and Template:Foo/sandbox.css requires editors to make assumptions as to what exactly it's the sandbox of. Anomie⚔ 17:23, 18 April 2026 (UTC)

I'm with Anomie's last paragraph entirely. --Redrose64 🌹 (talk) 17:48, 18 April 2026 (UTC)

No assumption needs to be made regarding Template:Foo/sandbox.css, as any /sandbox.css page would always been the sandbox version of the matching /styles.css page. So Template:Foo/sandbox.css is the sandbox for Template:Foo/styles.css, Template:Foo/Bar/sandbox.css is the sandbox for Template:Foo/Bar/styles.css etc. – Scyrme (talk) 18:07, 18 April 2026 (UTC)

Thinking about it more, I suppose the problem with sandbox.css is that a ".css" page doesn't necessarily have to be a stylesheet so there's nothing about that convention that implies it pairs with a styles.css page.

I now support the /sandbox/styles.css convention. – Scyrme (talk) 18:53, 18 April 2026 (UTC)

as any /sandbox.css page would always been the sandbox version of the matching /styles.css page Yes, that's the assumption that has to be made. If some template, for whatever reason, isn't following the /styles.css convention, then what? Anomie⚔ 18:59, 18 April 2026 (UTC)

I agree with Anomie that to test changes to a stylesheet, you need an accompanying sandbox template to make use of it. In cases where you're only testing changes to the template, you don't have to create a styles.css subpage; the sandbox page can continue to refer to the production styles.css page. I think it's more intuitive to keep sandbox versions of all supporting files (which could include stylesheets, utility templates, other templates within the same family, and so forth) with the same names and relative positions to the production template, just shifted below the sandbox subpage. isaacl (talk) 18:51, 18 April 2026 (UTC)

Agree with Issacl about test versions of all supporting files should be in /sandbox. The guideline should state this. — hike395 (talk) 19:01, 18 April 2026 (UTC)

Honestly kind of puzzling to be having this discussion, as it was settled in 2018. Izno (talk) 19:52, 18 April 2026 (UTC)

It was started because of the moves mentioned above by PrimeHunter. In November 2025, I tried clarifying it with Gonnym, but I wasn't convincing enough. The moves continued with the edit summary That's a local consensus for a single template that breaks every single other thing on this site: Special:Diff/1348614100, Special:Diff/1348614300.

I'd like to get a wider and clearer consensus to choose one of the conventions and discourage alternatives. —⁠andrybak (talk) 20:34, 18 April 2026 (UTC)

Why would it be puzzling? Not everyone knows that discussion occurred, it's not prominently linked to anywhere, and the guidelines were not amended to clarify the convention after that discussion so that confusion would continue doesn't surprise me. – Scyrme (talk) 21:03, 18 April 2026 (UTC)

It's the kind of thing that a cursory review of a talk page and its very short archive might have uncovered. And not all rules need to be written; I would have expected the convention to be clear. Obviously not.... Izno (talk) 21:46, 18 April 2026 (UTC)

A different kind of RouteMap

I’ve long been fascinated by the aesthetic and utility of route maps generated using the Routemap template, specifically how they provide an immediate "feel" for a journey. However, a major bottleneck in our current system is that these maps are largely static, manually coded, and disconnected from structured data.

By moving route information into a structured format integrated with wikidata we could:

• Automate rendering: Generate elevation profiles and schematic maps dynamically via templates rather than manual BSicon coding.
• Enable localization: Labels would pull automatically from Wikidata, allowing a single data set to serve all language Wikipedias.
• Cross-project synchronization: Projects like Wikivoyage would benefit immensely from shared, up-to-date route data.

As a proof of concept, I have modeled the West Highland Way using structured data and asked AI to develop a quick generator that renders this data into an accessible SVG/HTML document. It handles distances, elevations, and even "off-trail" landmarks (like Ben Nevis).

There are, of course, challenges to this approach. For example, there is currently no standard way to indicate "handedness" (e.g., rendering Ben Nevis on the correct side of the trail). I am also mindful that I may be stretching certain Wikidata properties beyond their intended use. I'd love to get some feedback!

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="https://fonts.googleapis.com/css2?family=Cormorant+Garamond:wght@300;400&family=DM+Mono:wght@300;400&display=swap" rel="stylesheet">
<style>
:root {
--ink: #1a1a1a;
--paper: #fcfcfc;
--rule: #dddddd;
--fill-gray: #f2f2f2;
--peak: #6b5a3e;
--font-d: 'Cormorant Garamond', serif;
--font-m: 'DM Mono', monospace;
}
body {
background: var(--paper); color: var(--ink); font-family: var(--font-m);
display: flex; flex-direction: column; align-items: center; padding: 40px; gap: 40px;
}
.card {
background: white; border: 1px solid var(--rule); padding: 40px;
box-shadow: 0 2px 8px rgba(0,0,0,0.05); width: 100%; max-width: 900px;
border-radius: 4px; box-sizing: border-box;
}
header h1 { font-family: var(--font-d); font-size: 2.5rem; font-weight: 300; margin: 0; }
svg { display: block; margin: 0 auto; overflow: visible; }
</style>
</head>
<body>

<header><h1 id="title"></h1></header>
<div class="card"><svg id="elev-svg" width="100%"></svg></div>
<div class="card"><svg id="route-svg" width="100%"></svg></div>

<script>
const DATA = {
label: "West Highland Way",
nodes: [
{ id: "Q1438673",   type: "human settlement", name: "Milngavie",                elev: 99  },
{ id: "Q1009428",   type: "human settlement", name: "Drymen",                   elev: 54  },
{ id: "Q3310955",   type: "human settlement", name: "Rowardennan",              elev: 10  },
{ id: "Q19462495",  type: "human settlement", name: "Inverarnan",               elev: 32  },
{ id: "Q3250464",   type: "human settlement", name: "Tyndrum",                  elev: 32  },
{ id: "Q13194707",  type: "human settlement", name: "Inveroran",                elev: 176 },
{ id: "Q6412938",   type: "hotel", name: "Kingshouse Hotel",         elev: 245 },
{ id: "Q1013614",   type: "human settlement", name: "Kinlochleven",             elev: 59  },
{ id: "Q1438830",   type: "human settlement", name: "Fort William",             elev: 9   },
{ id: "Q134230957", type: "wilderness hut",   name: "Rowchoish bothy",          elev: 69  },
{ id: "Q134231124", type: "wilderness hut",   name: "Doune Byre bothy",         elev: 33  },
{ id: "Q3310990",   type: "human settlement", name: "Inversnaid",               elev: 10  },
{ id: "Q965305",    type: "human settlement", name: "Crianlarich",              elev: 168 },
{ id: "Q913663",    type: "human settlement", name: "Bridge of Orchy",          elev: 134 },
{ id: "Q139492365", type: "mountain pass",    name: "Top of Devil's Staircase", elev: 550 },
{ id: "Q104674",    type: "mountain",         name: "Ben Nevis" }
],
sections: [
{ from: "Q1438673",  to: "Q1009428",  dist: 12 },
{ from: "Q1009428",  to: "Q3310955",  dist: 15 },
{ from: "Q3310955",  to: "Q19462495", dist: 14, via: ["Q134230957", "Q134231124", "Q3310990"] },
{ from: "Q19462495", to: "Q3250464",  dist: 12, via: ["Q965305"] },
{ from: "Q3250464",  to: "Q13194707", dist: 9,  via: ["Q913663"] },
{ from: "Q13194707", to: "Q6412938",  dist: 10 },
{ from: "Q6412938",  to: "Q1013614",  dist: 9,  via: ["Q139492365"] },
{ from: "Q1013614",  to: "Q1438830",  dist: 15, offers_view_on: "Q104674" }
]
};

document.getElementById('title').textContent = DATA.label;

const PX = 6;
const node = Object.fromEntries(DATA.nodes.map(n => [n.id, n]));

// ── Layout ──────────────────────────────────────────────────────────────────

const route = [node[DATA.sections[0].from]];
route[0].y = route[0].cumDist = 0;

DATA.sections.forEach(s => {
const from = node[s.from], to = node[s.to];
to.y = from.y + s.dist * PX;
to.cumDist = from.cumDist + s.dist;
route.push(to);

const vias = s.via ? (Array.isArray(s.via) ? s.via : [s.via]) : [];
vias.forEach((vid, i) => {
node[vid].y       = from.y       + (s.dist * PX) * (i + 1) / (vias.length + 1);
node[vid].cumDist = from.cumDist + s.dist         * (i + 1) / (vias.length + 1);
});
});

DATA.sections.forEach(s => {
if (s.offers_view_on) {
node[s.offers_view_on].y          = (node[s.from].y       + node[s.to].y)       / 2;
node[s.offers_view_on].cumDist    = (node[s.from].cumDist + node[s.to].cumDist) / 2;
node[s.offers_view_on].isOffTrail = true;
}
});

const totalDist = route[route.length - 1].cumDist;
const trailEnd  = route[route.length - 1].y;

// ── Elevation chart ─────────────────────────────────────────────────────────

function renderElevation() {
// Only nodes with elev AND cumDist (excludes Ben Nevis which has no elev)
const elevNodes = DATA.nodes
.filter(n => n.elev != null && n.cumDist != null)
.sort((a, b) => a.cumDist - b.cumDist);

const W = 900, PL = 55, PR = 30, PT = 24;
const chartW = W - PL - PR;
const chartH = 180;

const longestLabel = Math.max(...elevNodes.map(n => n.name.length));
const PB = longestLabel * 6 + 12;
const H = PT + chartH + PB;

const maxE = Math.max(...elevNodes.map(n => n.elev)) + 60;
const xe = d => PL + (d / totalDist) * chartW;
const ye = e => PT + chartH - (e / maxE) * chartH;
const baseline = PT + chartH;

const pts = elevNodes.map(n => `${xe(n.cumDist)},${ye(n.elev)}`).join(' ');

const marks = elevNodes.map(n => {
const nx = xe(n.cumDist);
const ny = ye(n.elev);
const isMain = route.includes(n);
const col = isMain ? 'var(--ink)' : '#999';
const fw  = isMain ? '600' : '400';
const fs  = isMain ? 10 : 9;

// Name label: rotated 90° upward from the baseline tick
const nameLabel = `
<line x1="${nx}" y1="${baseline}" x2="${nx}" y2="${baseline + 4}" stroke="${col}" stroke-width="0.75"/>
<g transform="translate(${nx},${baseline + 6}) rotate(-90)">
<text x="0" y="0" text-anchor="end" dominant-baseline="middle"
font-size="${fs}" font-weight="${fw}" fill="${col}"
font-family="var(--font-m)">${n.name}</text>
</g>`;

return `
<circle cx="${nx}" cy="${ny}" r="${isMain ? 3 : 2}" fill="white" stroke="${col}" stroke-width="${isMain ? 1.5 : 1}"/>
${nameLabel}`;
}).join('');

const gridSteps = [0, 100, 200, 300, 400, 500].filter(v => v < maxE);
const grid = gridSteps.map(v => {
const gy = ye(v);
return `
<line x1="${PL}" y1="${gy}" x2="${W - PR}" y2="${gy}" stroke="var(--rule)" stroke-width="0.5"/>
<text x="${PL - 6}" y="${gy + 4}" text-anchor="end" font-size="8" fill="#bbb" font-family="var(--font-m)">${v}m</text>`;
}).join('');

const svg = document.getElementById('elev-svg');
svg.setAttribute('viewBox', `0 0 ${W} ${H}`);
svg.setAttribute('height', H);
svg.innerHTML = `
${grid}
<polygon points="${xe(elevNodes[0].cumDist)},${baseline} ${pts} ${xe(elevNodes[elevNodes.length-1].cumDist)},${baseline}" fill="var(--fill-gray)"/>
<polyline points="${pts}" fill="none" stroke="var(--ink)" stroke-width="1.5"/>
<line x1="${PL}" y1="${baseline}" x2="${W - PR}" y2="${baseline}" stroke="var(--rule)" stroke-width="1"/>
${marks}`;
}

// ── Route map ───────────────────────────────────────────────────────────────

const CX  = 220;
const OFF = 80;  // horizontal offset for side features

// ── Icon library ────────────────────────────────────────────────────────────
// Each icon function returns SVG at the given (cx,cy) center.
// Colors come from var(--peak) for mountain-type, var(--ink) otherwise.

const ICONS = {
// Full triangle for summits
'mountain': (cx, cy) =>
`<path d="M ${cx - 12} ${cy + 9} L ${cx} ${cy - 9} L ${cx + 12} ${cy + 9} Z" fill="var(--peak)"/>`,

// Inverted-V (two lines meeting at a peak) for passes
'mountain pass': (cx, cy) =>
`<path d="M ${cx - 12} ${cy + 6} L ${cx - 2} ${cy - 6} L ${cx + 2} ${cy - 6} L ${cx + 12} ${cy + 6}"
fill="none" stroke="var(--peak)" stroke-width="2" stroke-linejoin="miter" stroke-linecap="round"/>`,

// House outline with pitched roof for hotels
'hotel': (cx, cy) =>
`<path d="M ${cx - 8} ${cy + 7} L ${cx - 8} ${cy - 1} L ${cx} ${cy - 8} L ${cx + 8} ${cy - 1} L ${cx + 8} ${cy + 7} Z"
fill="white" stroke="var(--ink)" stroke-width="1.75" stroke-linejoin="round"/>`,

// Small A-frame hut for bothies/wilderness huts
'wilderness hut': (cx, cy) =>
`<path d="M ${cx - 7} ${cy + 6} L ${cx} ${cy - 7} L ${cx + 7} ${cy + 6} Z"
fill="white" stroke="var(--ink)" stroke-width="1.5"/>`,
};

// Default settlement marker (filled circle)
function settlementDot(cx, cy, isMain) {
const r = isMain ? 5 : 3;
return `<circle cx="${cx}" cy="${cy}" r="${r}" fill="white" stroke="var(--ink)" stroke-width="2"/>`;
}

function renderTrailNode(n) {
const isMain = route.includes(n);
const isMountainType = n.type === 'mountain' || n.type === 'mountain pass';
const col = isMountainType ? 'var(--peak)' : 'var(--ink)';
const fw  = isMain ? '600' : '400';
const fs  = isMain ? 12 : 10;

const isOffset = n.isOffTrail === true;
const nx = isOffset ? CX + OFF : CX;

// Pick an icon, falling back to a plain circle
const iconFn = ICONS[n.type];
let marker = iconFn
? iconFn(nx, n.y)
: settlementDot(nx, n.y, isMain);

if (isOffset) {
// Dashed connector from trail line to offset icon
marker = `<line x1="${CX}" y1="${n.y}" x2="${nx - 14}" y2="${n.y}"
stroke="${col}" stroke-width="0.75" stroke-dasharray="3 2"/>` + marker;
}

let label = '';
if (n.name) {
// Labels for offset nodes go further out; inline nodes go right of trail
const lx = isOffset
? nx + 16
: CX + 16;
const anchor = 'start';
label = `<text x="${lx}" y="${n.y + 5}" text-anchor="${anchor}"
font-size="${fs}" font-weight="${fw}" fill="${col}"
font-family="var(--font-m)">${n.name}</text>`;
}

return marker + label;
}

function renderMap() {
const svg = document.getElementById('route-svg');

const trail = DATA.sections.map(s => {
const a = node[s.from], b = node[s.to];
return `
<line x1="${CX}" y1="${a.y}" x2="${CX}" y2="${b.y}" stroke="var(--ink)" stroke-width="4" stroke-linecap="round"/>
<text x="${CX - 22}" y="${(a.y + b.y) / 2 + 4}" text-anchor="end" font-size="10" fill="#bbb" font-family="var(--font-m)">${s.dist}mi</text>`;
}).join('');

const things = DATA.nodes
.filter(n => n.y !== undefined)
.map(n => renderTrailNode(n))
.join('');

const ly = trailEnd + 80;
const legend = `
<g transform="translate(40,${ly})" font-family="var(--font-m)">
<line x1="0" y1="-24" x2="460" y2="-24" stroke="var(--rule)" stroke-dasharray="4 4"/>
<g transform="translate(0,0)">
<circle cx="8" cy="0" r="5" fill="white" stroke="var(--ink)" stroke-width="2"/>
<text x="22" y="4" font-size="11">Settlement</text>
</g>
<g transform="translate(110,0)">
<path d="M 0 7 L 0 -1 L 8 -8 L 16 -1 L 16 7 Z" fill="white" stroke="var(--ink)" stroke-width="1.75" stroke-linejoin="round"/>
<text x="22" y="4" font-size="11">Hotel</text>
</g>
<g transform="translate(180,0)">
<path d="M 0 6 L 7 -7 L 14 6 Z" fill="white" stroke="var(--ink)" stroke-width="1.5"/>
<text x="22" y="4" font-size="11">Wilderness hut</text>
</g>
<g transform="translate(310,0)">
<path d="M 0 9 L 9 -9 L 18 9 Z" fill="var(--peak)"/>
<text x="26" y="4" font-size="11" fill="var(--peak)">Mountain</text>
</g>
<g transform="translate(400,0)">
<path d="M -2 6 L 8 -6 L 12 -6 L 22 6" fill="none" stroke="var(--peak)" stroke-width="2" stroke-linecap="round"/>
<text x="28" y="4" font-size="11" fill="var(--peak)">Pass</text>
</g>
</g>`;

const totalH = trailEnd + 140;
svg.setAttribute('viewBox', `0 -40 500 ${totalH}`);
svg.setAttribute('height', totalH);
svg.innerHTML = trail + things + legend;
}

renderElevation();
renderMap();
</script>
</body>
</html>

Wayfarings (talk) 16:32, 20 April 2026 (UTC)

please ensure you are familiar with WP:LLM, but you may want to test in on the testing version of wikipedia. -- Aunva6^{talk - contribs} 17:58, 20 April 2026 (UTC)

Thanks for replying! I was hoping to get some feedback on the idea itself, as well as on the general data structure. Wayfarings (talk) 20:39, 20 April 2026 (UTC)

I'm sure we discussed - and rejected - something similar a year or two back, but not on this page. It might have been at WT:RDT, perhaps Template talk:Routemap or WT:TRAINS. Bit busy now, will check later. --Redrose64 🌹 (talk) 18:06, 21 April 2026 (UTC)

So far I've turned up Wikipedia talk:WikiProject Trains/Archive: 2024#Line colors - this starts off innocuous enough (how might I change some colours?), but by 19:12, 9 September 2024 (UTC) had mutated into a proposal for a totally new syntax. There are also Template talk:Routemap/Archive 2#Routemaps accessibility and Template talk:Routemap/Archive 2#Dark mode problems. Also Template talk:Sepulveda Transit Corridor#Accessibility. --Redrose64 🌹 (talk) 21:47, 21 April 2026 (UTC)

Hey, thanks a bunch for looking!

had mutated into a proposal for a totally new syntax

That's where I'm starting out here, so no mutations required. The goal would be to be able to interoperate with structured data. I understand that this would not be a simple project though! Wayfarings (talk) 10:33, 22 April 2026 (UTC)

Redlinked terrorism categories

The latest run of Special:WantedCategories features several redlinked "Terrorism in the [Decade]" categories that were recently deleted at WP:CFD, but remain populated because the categories are being artificially autogenerated and transcluded by {{Terrorist incidents in YYYY category header}}. However, there are several other decade categories for the 1910s, 2000s, 2010s and 2020s that have not been deleted, so I can't just yank that category-generation code out of the template since that would also depopulate the undeleted categories — but every time I've ever tried to #ifexist category code in a template by myself without soliciting outside help from template experts, I've broken other things in the process.

So could somebody who's more knowledgeable than I am about template coding quickly slap an #ifexist on the "Terrorism in the [Decade]" code so that the redlinked categories go away while the bluelinked ones don't? Thanks. Bearcat (talk) 15:13, 22 April 2026 (UTC)

The CFD was Wikipedia:Categories for discussion/Log/2026 April 5#Terrorism in the 1990s and it should not have been a some-but-not-all nom. Was Fayenatic london (talk · contribs) made aware that these cats are emitted by a template? --Redrose64 🌹 (talk) 12:45, 23 April 2026 (UTC)

I was aware. Pppery seems to have fixed the template now. We could simplify it using {{Category if exists}}.

There is a full series of "Terrorism incidents in the YYY0s" categories, so there was no need for "Terrorist incidents in YYYY" to populate "Terrorism in the YYY0s" for any date. – Fayenatic London 18:00, 23 April 2026 (UTC)