Template talk:Infobox station

  1. Home
  2. Wiki

Merger proposal

[edit]

I propose to merge Infobox London Station into Infobox station. I think that the content in the London station template can easily be replicated in infobox station just like the move of Infobox GB station into Infobox station. Smithr32 (talk) 20:33, 26 September 2020 (UTC)[reply]

I'm not sure it should be merged. The biggest difference is the multiple sets of passenger figures under different headings. I am not sure how to smoothly implement that, whilst retaining generality for use in other stations, and also preventing misuse of the generality. Unless a good proposal to get around that is found, I do not think it's likely to be a good merge. ProcrastinatingReader (talk) 21:26, 26 September 2020 (UTC)[reply]
We should still hold on with London station, it is a situation similar to New York City Subway station. Both should be scrutinized before any mergers are put forward. Cards84664 23:45, 26 September 2020 (UTC)[reply]
It would have been better to merge {{Infobox GB station}} into {{Infobox London station}} because the latter is, by and large, a superset of the former - only a few features of GB station are not provided by London station. --Redrose64 🌹 (talk) 20:55, 27 September 2020 (UTC)[reply]
@Smithr32: looked into this more recently, this is probably more feasible than I originally imagined above. Played around with a few demo conversions in my sandbox (the first two), very roughly. I think the key here is on presentation of the passenger information. The data can be carried over given |system= in {{Rail pass box}}, but not sure on the presentation of that data atm. ProcrastinatingReader (talk) 08:48, 28 November 2020 (UTC)[reply]

Style "CTrail" should use Futura font, with Arial Bold relegated as a fallback font

[edit]
Two signs displaying the text "New Haven (dash) State St" in the Futura typeface
New Haven - State Street signage

CTrail uses Futura or a similar font for their signage. Most computers support Futura, so this font should be used to demonstrate the name of a station, as even if the font is not precisely Futura, it still is similar enough. Still, not all computers use Futura, so Arial Bold (as is currently) should be used as a fallback font instead.

As demonstrated on New Haven State Street station, this is not currently the case.Swedish Win (talk) 05:19, 15 July 2025 (UTC)[reply]

@Swedish Win: Module:Adjacent stations/CTrail is the place to set what fonts are used for CTrail stations. Pi.1415926535 (talk) 06:41, 15 July 2025 (UTC)[reply]
See MOS:FONTFAMILY. Fonts should not be specified. There is not good reason here to override those guidelines and the font specification should be removed from the templates. 10mmsocket (talk) 06:48, 15 July 2025 (UTC)[reply]

Edit request 17 September 2025

[edit]

Description of suggested change:

As discussed on my talk page, I along with @Mackensen: and @Pi.1415926535: are in favor of removing the following code and parameter from the infobox:

| subheader = {{{type|}}}
| subheaderclass = category

The type parameter is redundant to article prose and redundant to the invocations of Module:Adjacent stations. It mainly restates the operator of the station or the rail/bus system that the station serves. Cards84664 14:55, 17 September 2025 (UTC)[reply]

Support: This parameter serves no real purpose, duplicates other parameters, and has wildly inconsistent usage. It's time for it to be deprecated. Pi.1415926535 (talk) 16:29, 17 September 2025 (UTC)[reply]
Comment: What would the replacement be? For many stations, the only obviously link to the system article in the infobox is through this parameter; the adjacent stations browse box may have it as an image link, but those aren't as obvious to the reader. SounderBruce 18:10, 17 September 2025 (UTC)[reply]
|train_operators= can do that. Mackensen (talk) 20:33, 17 September 2025 (UTC)[reply]
Most adj modules use plaintext to show the system/operator. The system/operator should be in the lead anyway. Cards84664 21:11, 17 September 2025 (UTC)[reply]
Deactivating until there is a process identified to address the apparent gap noted by SounderBruce. Feel free to change |answered= to blank or no when there is consensus, and I or another template editor will stop by and make this quick change. We can also put in a tracking category if articles need to be modified. [Edited to add: There are apparently 14,000 articles using this parameter, according to the TD report.] – Jonesey95 (talk) 05:32, 18 September 2025 (UTC)[reply]

@Mackensen: How do you propose we script an automatic change from type to train_operators? Cards84664 20:33, 22 September 2025 (UTC)[reply]

I actually don't think |train_operators= is a suitable replacement... a station's system is not the same as its operators. For Vancouver SkyTrain stations, for instance, the system is SkyTrain (Vancouver), but the operator would be TransLink (British Columbia). —Joeyconnick (talk) 21:51, 22 September 2025 (UTC)[reply]
I think new |system= parameter, located above owned by, might be better solution. See Template:Infobox station/testcases for examples of this. It can take the type parameter by default. Mackensen (talk) 22:23, 22 September 2025 (UTC)[reply]
Yeah that looks much more tidy than what we currently have. Cards84664 14:23, 3 October 2025 (UTC)[reply]
@Joeyconnick your thoughts? Mackensen (talk) 15:34, 3 October 2025 (UTC)[reply]
Sure... that looks fine. Thanks for adding! —Joeyconnick (talk) 18:05, 3 October 2025 (UTC)[reply]

Updated and revised documentation. Mackensen (talk) 11:51, 4 October 2025 (UTC)[reply]

"Rebuilt" parameter inconsistency

[edit]

Should the value of the "rebuilt" parameter be a full date or just a year? The parameters section says "Date station last received a rebuild", but the TemplateData section says "Year(s) station received a rebuild". LazyCat256 (talk) 01:09, 28 October 2025 (UTC)[reply]