This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Trains Trains Portal This page is within the scope of WikiProject Trains, an attempt to build a comprehensive and detailed guide to rail transport on Wikipedia. If you would like to participate, you can visit the project page, where you can join the project and/or contribute to the discussion. See also: WikiProject Trains to do list and the Trains Portal.TrainsWikipedia:WikiProject TrainsTemplate:WikiProject Trainsrail transport

	TWP discussion archives:
	2004 2005 January–June 2006 March–September 2006 June–December 2006 December 2006–March 2007 March–August 2007 August–October 2007 October 2007–January 2008 January–May 2008 May–September 2008 September–December 2008 January–July 2009 August–December 2009 January–August 2010 August–November 2010 December 2010–March 2011 April–May 2011 June–December 2011 January–August 2012 September–December 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026
This page has archives. Topics inactive for 30 days are automatically archived by Lowercase sigmabot III.

The Trains WikiProject
General information
Main project page	(WP:TWP)	talk
Portal	(P:Trains)	talk
Project navigation bar		talk
Project participants		talk
Project banner (doc)	{{TWP}}	talk
Project category		talk
Manual of style	(WP:TWP/MOS)	talk
Welcome message		talk
Departments
Assessments	(WP:TWP/A)	talk
Peer review	(WP:TWP/PR)	talk
To do list		talk
Daily new article search	search criteria	talk
Task forces
Article maintenance		talk
Assessment backlog elim. drive		talk
By country series		talk
Categories		talk
Images		talk
Locomotives		talk
Maps		talk
Rail transport in Germany		talk
Monorails		talk
Operations		talk
Passenger trains		talk
Portal		talk
Rail transport modelling		talk
Timelines		talk

Is there a function in convert for gradients, e.g. 1-in-X = y degrees or z%? I thought something like this might be useful for the article I'm currently working on, a narrow-gauge railway in Victoria, Australia - Walhalla railway line, to make the article more compatible with international readers who might be more used to expressions of slope in, say, percentage values whereas locally we almost always use "1 in X".
At the moment my edit of the article has a mix of "1:30", "1-in-30" and "1 in 30" formats; I'll do a final sweep and standardise those before I finish, but the template could deal with all those at the same time as a side-benefit. This 1927 diagram [1] shows the gradients of the railway line expressed as 1 in X, e.g. a slope marked "30" is 1 in 30.
For inputs, I think a code chain of {{convert|30|x|%dr}} might work, where the user inputs any one value, x for 1 in X, % (or pc?) for percentage, d for degrees or r for radians, and it provides outputs for all other terms, in this case %, d, and r, but fewer if not all three are specified in the final convert term. There'd also need to be something for rounding, e.g. maximum 2 decimals on percentage. A more complicated version might want to account for swapping from downhill to uphill, e.g. downhill 1 in 30 changes to uphill 1 in 30, net difference 1 in 60.
I originally asked this in the page for the {Convert}} template page, @Johnuniq (talk · contribs) recommended that I bring it over here. Anothersignalman (talk) 19:28, 13 January 2026 (UTC)[reply]

If the folks at convert sent you here I'd it's probably best as a separate template (c.f. {{rail gauge}}, but yes it absolute would be a good idea. For syntax perhaps {{gradient|x|in|y}} to output a percentage and {{gradient|x|%}} to out put 1 in x? I don't have anything approaching the ability to make this myself. Thryduulf (talk) 13:00, 14 January 2026 (UTC)[reply]

I figured no need for x in y because as far as I've seen, it's always 1 in X, not say 3 in 65 or whatever; and that could be allowed for with decimals in any case. I also wanted to cover all the other possible ways someone might try to describe a slope, hence degrees and radians as well. Anothersignalman (talk) 14:48, 14 January 2026 (UTC)[reply]

That's fair. I also now remember discussing this somewhere previously several years ago, I didn't find that in the archives of Template talk:Convert but I did find other relevant discussions of gradients and angles in several different contexts (astronomy, railways, mountaineering, Egyptian pyramids):

• Template talk:Convert/Archive 2#Proposal: Add angular units
• Template talk:Convert/Archive 2#Angle conversion
• Template talk:Convert/Archive 3#Angular Units
• Template talk:Convert/Archive September 2015#Angle conversions
• Template talk:Convert/Archive October 2015#Angles again
• Template talk:Convert/Archive August 2017#Displaying a formatted value?
• Template talk:Convert/Archive October 2019#Suggestion: Include angle conversions (NB possible conflict of symbols)

Pinging the users involved in those discussions who appear to be still active (in no particular order): @Johnuniq, Hermes Thrice Great, Sauer202, Mike Peel, Mattbuck, UnladenSwallow, Gah4, Praemonitus, RoySmith, Jc3s5h, Ashill, Slawekb, and David Eppstein:. Thryduulf (talk) Thryduulf (talk) 15:06, 14 January 2026 (UTC)[reply]

Re I figured no need for x in y because as far as I've seen, it's always 1 in X, not say 3 in 65 or whatever If you supported the more general case, this might be useful for things like Roof pitch. RoySmith (talk) 15:20, 14 January 2026 (UTC)[reply]

Yeah, OK, roof pitch is a good argument for the more complex x-in-y option. Without knowing anything about programming, I'm guessing that means we can't have a single field each for input-type, number, output types plural as I'd shown above though? Anothersignalman (talk) 16:00, 14 January 2026 (UTC)[reply]

I'm also not a programmer but given convert handles the same parameter doing different things depending on what it contains (e.g. {{convert|4|ft}}, {{convert|4|x|4|ft}}, {{convert|4|±|1|ft}} and {{convert|4|-|8|ft}} all do different things) it might be possible for "in" in the second parameter to trigger different handling. I guess it would make it a lot more complicated though. 16:13, 14 January 2026 (UTC) Thryduulf (talk) 16:13, 14 January 2026 (UTC)[reply]

The next step would be to work out what inputs should be accepted, with any wanted limit checks. Then, determine the exact wikitext wanted for the outputs. The best way to show that would be in a list of examples with actual numbers. I suggest one list which others edit until it's at an agreed state. There are a few coders who would implement it (possibly me) but a specification is needed before thinking about that. Johnuniq (talk) 01:17, 15 January 2026 (UTC)[reply]

This is what I originally envisaged, plus a few ideas from above. Open to other people adding to this list.

• Example 01: {{slope|40|x|%dr}} generates 1 in 40 (2.5%, 1.43°, 0.025 radians) - Base case
• Example 02: {{slope|40|x|dr%}} generates 1 in 40 (1.43°, 0.025 radians, 2.5%) - Note output order swap
• Example 03: {{slope|2.5|%|xdr}} generates 2.5% (1 in 40, 1.43°, 0.025 radians) - Input %, output slope
• Example 04: {{slope|40|x|%}} generates 1 in 40 (2.5%) - One calculated value only
• Example 05: {{slope|-40|x|%}} generates -1 in 40 (-2.5%) - Support for negative inputs
• Example 06: {{slope|3in8|x|%}} generates 3 in 8 (37.5%) - Any letters between two numbers in the lead term would allow a fraction other than 1 in X.
  • Auto-add spaces in this example, though per below we might standardise on dashes instead?
• Example 07: {{slope|3 i 8|x|%}} generates 3 i 8 (37.5%) - Letters copied verbatim causes this error missing the letter "n". This is intended as support for other languages.
  • Units are x, %, d, r. Are there any others we want?

Notes:

• Commas inserted between multiple output terms in brackets automatically
• Order of terms in brackets as defined by the order of letters to be converted to
• Decimal and comma numbers permitted in inputs, e.g. |1.7 or |1,700.
• |1in8|x would generate the same output as |8|x
• For the full-length gradient expression, do we want "1 in 40" without dashes, or "1-in-40" with dashes? I think I prefer the former, but open to one or the other being default with option to select.

Optional terms after the final convert-to value:

Rounding:

• |round=2u - Rounds all numbers to 2 significant digits, explicitly rounding up, e.g. 6.666...% becomes 6.7%
• |round=2d - Rounds all numbers to 2 significant digits, explicitly rounding down, e.g. 6.666...% becomes 6.6%
• |round=4 - Rounds all numbers to 4 significant digits, rounding off, e.g. 0.14285714285 becomes 0.1426 (regardless of unit). Note an input with insufficient significant digits would be expanded, e.g. 1 in 40 would become 1 in 40.00. Not sure if that's desirable?
• |round=2t - Rounds all numbers to 2 significant digits, trimming off any additional digits, e.g. 0.14285714285% becomes 0.14%
• |round=-2 - Rounds all numbers to negative 2 significant digits, e.g. 142.85% becomes 140%.
  • Round must always have a number; optional letters u, d, t.

Term styles:

• |style=: - Swaps in (with spaces) for :, e.g. 1 in 40 becomes 1:40
• |abbr=off - Swaps % to percent; ° to degrees; rad to radians - note this is the inverse of {{convert|...}}, where abbr=on has to be specified.
• Question whether this and |style=: can/should be merged; and if it should be possible to specify abbreviations for some but not all terms? e.g. |xa, |%a for abbreviated versions of those two in lieu of |abbr=off altogether.
• Need to think about how to allow 16.2 in 37.5, for example, in the output side. We'd need to specify rounding (including negative rounding) for each of the numerator and the denominator, though default would be round to integers.

Is that the sort of thing you were after, for an opening spec outline? Anothersignalman (talk) 14:27, 15 January 2026 (UTC)[reply]

A couple of thoughts based on that

• I think we should keep parameter names and operation the same as in {{convert}} where they do the same job, for ease of learning syntax and for merging if that were to ever happen in the future. For example:
  • abbr= should default to off
  • round= should work the same as in {{convert}}.
  • style= should be disp=
• There should also be support for ranges, e.g. {{slope|20-40|%|x}} → 1 in 5 – 1 in 2.5
  • ranges should use "-" (or whatever flavour of short horizontal line MOS prefers) or "to" depending on the input
• There should be support "and" and "or" in a similar way to ranges.

Thryduulf (talk) 15:10, 15 January 2026 (UTC)[reply]

Agree on all points. Do you want to edit those into the above specs, or it is fine to have it in this threaded format? Anothersignalman (talk) 15:59, 15 January 2026 (UTC)[reply]

Pinging @Johnuniq and Thryduulf:, and anyone else who might be following this, where did we land? Did we find someone who can actually program this? If not, where do we go hunting for "volunteers"? :P Anothersignalman (talk) 19:53, 7 February 2026 (UTC)[reply]

I'm about two days behind on my watchlist, so only just seen this. {{railway gradient|30}} → 1 in 30 (33.3 ‰). --Redrose64 🌹 (talk) 21:11, 15 January 2026 (UTC)[reply]

Is the per mille symbol standard in some other jurisdictions? I've only ever seen gradients expressed as 1 in x or percent e.g. 3.33%, not 33.3‰. Anothersignalman (talk) 09:42, 16 January 2026 (UTC)[reply]

Railway gradients tend to be much easier than road gradients - 1 in 30 is steep for a railway. In the UK, gradients like this are the exception rather than the rule - such as the Lickey Incline. A gradient expressed as a percentage would need to be steeper than 1 in 100 (1.0 %) in order to get a non-zero digit before the decimal point. Since many railways have a gradient easier than this, a per mil figure is used, where any gradient between 1 in 100 and 1 in 1000 (which covers most of them) will have a single non-zero digit before the point. Consider the Great Western Main Line between Paddington and Swindon, which does not exceed 1 in 660 (1.5 ‰) at any point - and that's in a distance of 77 miles. Even on this line, most of the line between Paddington and Reading (36 miles) is significantly easier: long stretches are either level or 1 in 1320 (0.8 ‰). --Redrose64 🌹 (talk) 19:49, 16 January 2026 (UTC)[reply]

Ah, you might not be familiar with Australian railways. We have gradients that have horrified UK engineers. This is the case study I'm working with - [2] - note the 26 mile line has about 16 miles of 1 in 30 to 1 in 40, and from about the 87 mile mark to the end is almost entirely curves - and the standard gauge Main West line from Sydney apparently has a net of about 9 miles of 1 in 33 which forced us to use different gearing for our HST exports. Anothersignalman (talk) 05:56, 17 January 2026 (UTC)[reply]

@Anothersignalman I've just replied in more detail in your crosspost (that I saw before I saw the question here). Per mille seems to be common in German-language sources but as far as I found not (or at least less so) in English ones. Thryduulf (talk) 20:00, 16 January 2026 (UTC)[reply]

There is a requested move discussion at Talk:Berri–UQAM station#Requested move 15 January 2026 that may be of interest to members of this WikiProject. Vestrian24Bio 09:41, 23 January 2026 (UTC)[reply]

This is a topic I see come up time and time again. It’s common for editors to change the tense of an article from present tense to past tense when a class of train is withdrawn from service, despite the vehicles still being in existence, sometimes even in operations in preservation. To me this seems incorrect - if the trains still exist, then the present tense makes more sense. For example:

The FooBar class is a class of locomotive…

makes far more sense for when this class is still in existence than

The FooBar class was a class of locomotive…

which implies that even though 20 members of the class survive in preservation, they no longer “exist as a class” - that’s just patently false.

For the sake of putting the matter to bed, what say other editors? Danners430 _{tweaks made} 09:55, 26 January 2026 (UTC)[reply]

Courtesy pinging @SCHolar44 and @Jessicapierce Danners430 _{tweaks made} 09:56, 26 January 2026 (UTC)[reply]

I typically use present tense unless every single instance of the locomotive has been scrapped (e.g. Ingalls 4-S). My standard wording is "The Article Name is a model of steam/diesel/electric locomotive produced by (manufacturer)..."

For a rather extreme example, the EMD FL9 was retired from revenue service in 2009 but more than a third of the units built survive in preservation. Using past tense clearly wouldn't be appropriate in that article. Wikipedians seem to have this instinct to immediately go change things from "is" to "was" the second any news about anything is released, to the point I had to insert an edit notice in Montana Rail Link when the merger with BNSF was announced because it wasn't approved and then made effective until two years after the first announcement.

I do want to remind Jessicapierce that rollback is meant to be used on vandalism or obviously disruptive edits, and edits like this are not an appropriate use of that tool per WP:ROLLBACKUSE. The edit that was reverted was not vandalism or obviously disruptive, and any revert should have included an edit summary. Trainsandotherthings (talk) 14:51, 26 January 2026 (UTC)[reply]

That's my thinking - we may be talking about things that are mostly historical, but they still very much exist in flesh and blood. If you were stood in front of an EMD FL9 delivering a talk, would you start the talk with "The locomotive behind me was a class of..."? If you'll excuse the extreme language, it's utter nonsense in my opinion! Danners430 _{tweaks made} 14:54, 26 January 2026 (UTC)[reply]

You're quite right, and I take your point. The first edit I reverted had wrecked the infobox, and several others changed only the first instance of the verb. I.e., the first sentence of the article said "is," and the rest of the article said "was." Since this was being done by an anonymous editor with no edit summary, I couldn't imagine it was being done constructively. I did attempt to discuss it with the editor. Jessicapierce (talk) 17:15, 26 January 2026 (UTC)[reply]

Good point - I never notified that anonymous editor about the discussion. Danners430 _{tweaks made} 17:19, 26 January 2026 (UTC)[reply]

"The X is a retired class/model/type/etc. of..." seems fine to me, just like Wikipedia doesn't switch to "was" if a living person retires from their most notable occupation. XtraJovial (talk • contribs) 15:01, 26 January 2026 (UTC)[reply]

Wouldn't at all be against this... but it does open a can of worms - how do you define "retired"? Great example being the British Rail Class 153 - when Scotrail and TfW retire them, it will be retired in passenger service, but very much active as a measurement train with Network Rail... Then you have preserved locomotives that operate on the main line for railtours... and it gets even messier when you start talking about the British Rail Class 50 which everyone would probably agree is in preservation - yet GBRf use them for freight! Danners430 _{tweaks made} 15:08, 26 January 2026 (UTC)[reply]

how do you define "retired"? When a train ceases to be used in regular service, departmental or revenue-earning. Pretty straightforward in most cases. The case with the Class 50 seems abnormal, at least within my scope of knowledge, so I don't want it to be something hard-and-fast. XtraJovial (talk • contribs) 03:02, 28 January 2026 (UTC)[reply]

That's why we use the terminology "retired from revenue service" when a locomotive is no longer used for normal operations. Trainsandotherthings (talk) 00:44, 29 January 2026 (UTC)[reply]

Modelgram railway station is a new article which I noticed because it has a script error. It has been proposed for deletion and people here might like to consider its future. Johnuniq (talk) 06:34, 27 January 2026 (UTC)[reply]

I have started a discussion at Talk:List of urban rail systems in Japan#Consistent article title disambiguation format that may be of interest to members of this WikiProject. OrdinaryScarlett (talk) 11:23, 31 January 2026 (UTC)[reply]

East London line
Legend
London Underground
to Liverpool Street Great Eastern Main Line to Norwich Shoreditch Whitechapel to District line and Hammersmith & City line St Mary's Curve Docklands Light Railway │ Shadwell Shadwell Wapping Thames Tunnel Rotherhithe Canada Water Surrey Quays to London Bridge New Cross Depot New Cross Gate New Cross South Eastern Main Line Brighton Main Line

The usage tutorial for these line diagrams is rather difficult to follow. Is there a plugin for something to make it easier? GarethBaloney (talk) 21:34, 3 February 2026 (UTC)[reply]

@GarethBaloney: - not that I'm aware of. The way I do it is to edit one line at a time, preview, amend / preview until correct, the edit next line. Mjroots (talk) 19:46, 7 February 2026 (UTC)[reply]

Same here, lots of trial and error, and copy ruthlessly from other maps that happen to have what you need. You can search for specific symbols here. Anothersignalman (talk) 19:56, 7 February 2026 (UTC)[reply]

Somehow in 4 days I have managed to get a hang of it! Perhaps it's a lot easier when you start from scratch since you know where everything is GarethBaloney (talk) 20:14, 7 February 2026 (UTC)[reply]

I find commons:Template:Bsicon to be a useful starting point to find icons — opening one subpage at a time in a new tab (it can be a little resource-heavy when using an older PC as I do). If you find yourself needing icons in other colours, outside the default / ex / u / uex sets, there is commons:User:YLSS/BSicon/navbox as a starting point, and also my own work-in-progress at commons:User:AmosWolfe/BSicon. -=# Amos E Wolfe ^talk #=- 14:09, 8 February 2026 (UTC)[reply]

@GarethBaloney - there is this tool, but I’ve only tested it very lightly so can’t vouch for its usefulness. Triptothecottage (talk) 23:34, 7 February 2026 (UTC)[reply]

I've given that tool a quick (5 minutes) tryout and it seems pretty useful because any previews are instant. The only downsides I have found so far is that it doesn't support overlays or any "other colour" icons which use the colour name as a suffix separated by a space. -=# Amos E Wolfe ^talk #=- 14:12, 8 February 2026 (UTC)[reply]

One of the biggest problems in advising users of which BSicons are available is that there are so many - far too many to show - or even list - on one page. When I started working with them way back in 2009, there was a much smaller set of shapes, and most were available in only five colours - red, blue, the light versions of those, plus green (used by the waterways people). Now, there are not only many more shapes, but many more colours too. One of the earliest icons to be created, and one of the most basic too,  (STR), now exists in over thirty different basic colours - and that's not counting the "light" colours like  (exSTR) or the "blue" set like  (uSTR).

To get some idea of how the sheer scale of the problem is difficult to grasp, go to this link on commons and keep on clicking the "Next page" link at the top or bottom. You get the somewhat strange figure of 345 entries per page, so ten pages is 3450 icons, but you run out of patience before you run out of pages. But it won't take long to realise that far from there being hundreds or thousands of BSicons, there are several tens of thousands if not hundreds of thousands. --Redrose64 🌹 (talk) 22:56, 8 February 2026 (UTC)[reply]

A visit to this link will show that there are 350,258 files at Commons where the filename starts with "BSicon_" at the time of writing, with the number increasing daily. -=# Amos E Wolfe ^talk #=- 08:03, 9 February 2026 (UTC)[reply]

Unlike my link, your link isn't exclusive to File: namespace, and it also counts redirects. --Redrose64 🌹 (talk) 08:40, 9 February 2026 (UTC)[reply]

There is a requested move discussion at Talk:Toei Asakusa Line#Requested move 1 February 2026 that may be of interest to members of this WikiProject. Vestrian24Bio 13:49, 8 February 2026 (UTC)[reply]

Template:Stouffville line detailed has been listed for discussion, which may result in the template being merged or deleted by consensus. You are invited to comment on the proposed action at the entry on the Templates for discussion page. OrdinaryScarlett (talk) 04:25, 9 February 2026 (UTC)[reply]

Dear kind people, please fix the issues tagged. Bearian (talk) 16:20, 9 February 2026 (UTC)[reply]

I've opened a discussion at Talk:ALSN#Sources. The original creator is still active. Mackensen (talk) 18:34, 9 February 2026 (UTC)[reply]

An editor has requested that Tokyo Metro Namboku Line be moved to another page, which may be of interest to this WikiProject. You are invited to participate in the move discussion. S5A-0043🚎^(Talk) 03:51, 11 February 2026 (UTC)[reply]

@S5A-0043 I presume you mean Talk:Tokyo Metro Namboku Line#Requested move 11 February 2026? Thryduulf (talk) 03:56, 11 February 2026 (UTC)[reply]

o o p s. Thanks for letting me know. S5A-0043🚎^(Talk) 04:00, 11 February 2026 (UTC)[reply]

There is a requested move discussion at Talk:Northumberland Park Metro station#Requested move 30 January 2026 that may be of interest to members of this WikiProject. TarnishedPath^talk 14:24, 11 February 2026 (UTC)[reply]

There is a requested move discussion at Talk:Sendai Subway Namboku Line#Requested move 15 February 2026 that may be of interest to members of this WikiProject. XtraJovial (talk • contribs) 19:49, 18 February 2026 (UTC)[reply]

I feel that it is fairly evident that there are two main types of route diagram templates: service descriptions and physical line descriptions. When reviewing route diagram templates for commuter services (at least in the US), these are service diagrams: they depict current, former, and future stations/stops and connecting/adjacent passenger services. The exception to this, are the RDTs in the Chicago area (Metra and the South Shore Line). I look at these templates and I find them completely bloated with every track connection, river, stream, bike path, and highway that can be crammed in there.

I confess, I may have been the one to start all of this back in November 2008 when I created the template for the Union Pacific / West Line and added unlabeled freight-only track connections as landmarks. I added more “landmarks” to these templates over the years and have even suggested that other editors do the same. Looking back, I think this was in error.

So this leaves me wondering what should and shouldn’t belong in these? Should we include landmarks (such as highways or rivers) or not? Connecting freight tracks don’t have any relevance to the passenger services, but what about bike paths that passengers might utilize? Are they relevant or does that make the RDT into a guide??

What are others’ thoughts? Lost on  Belmont  ^3200N_1000W  (talk) 02:40, 19 February 2026 (UTC)[reply]

My view is that service diagrams should be limited to the stations and plausible connections, while physical lines should include all the various current and former connecting lines. Example:

• {{Raritan Valley Line}} (physical line)
• {{Raritan Valley Line (service)}} (commuter rail service)

I think highways add clutter and I don't like including them. Rivers can be a different matter since we often have articles about the bridges. Mackensen (talk) 02:47, 19 February 2026 (UTC)[reply]

We should only include those that features that are significant in the context of the route. What this means in practice depends in large part on the scale of the route - for example significant for the Brighton Main Line is a much higher bar than for the Slough to Windsor & Eton Line. Thryduulf (talk) 04:30, 19 February 2026 (UTC)[reply]

It's a good point to raise. For my two cents, I'd note that some guidance on this question has been offered at Wikipedia:WikiProject Australian Transport, working on the approach that there should be a distinct approach for service diagrams vs physical railway line diagrams. Tomiĉo (talk) 10:15, 20 February 2026 (UTC)[reply]

An editor has requested that Conductor (rail) be moved to another page, which may be of interest to this WikiProject. You are invited to participate in the move discussion. Shhhnotsoloud (talk) 10:34, 21 February 2026 (UTC)[reply]