Template talk:Infobox station/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Optional separation of former and future services

I'd like to have two additional optional sets of services, services_collapsible, and services_state; with the headers set as "Former services" and "Future services". The intention is that for busy stations like North Station, the current services could be left expanded, but long lists of former services and/or future services could be collapsed to reduce the height of the infobox. For stations where this is not needed, the new parameters could be omitted and thus nothing would change from current usage. I am willing to sandbox this first if desired. Pi.1415926535 (talk) 00:20, 25 January 2018 (UTC)

I support this proposal as well, adding the extra parameter will significantly declutter articles like Shaker Square. Cards84664 (talk) 02:05, 25 January 2018 (UTC)

Not done for now: there are a few important stages to follow before using the edit-template protected template. Discussion -> detailed proposal -> code in sandbox -> consensus for change. — Martin (MSGJ · talk) 08:07, 25 January 2018 (UTC)

I really don't think that past or future services belong in the infobox - they should be described in prose in a section within the main article body, perhaps with an accompanying routebox in the same section. --Redrose64 🌹 (talk) 11:50, 25 January 2018 (UTC)

Oh no! The Infobox can already become overstuffed with many parameters being co-opted from their original purpose. If the information is important enough, then it should be detailed in the body of the article. Secondarywaltz (talk) 19:03, 25 January 2018 (UTC)

@Redrose64 and Secondarywaltz: Let me clarify why I am asking for this. The purpose is absolutely ot to allow stuffing more information in infoboxes than currently exists, but to declutter the information that is already there. (Note that I've been putting in a lot of effort recently to declutter infoboxes to reduce scrolling.) I would fully support having a discussion within the project of how what former services are acceptable to include in a given infobox, in order to establish policy to prevent these parameters from being abused. I'm not sure what your objections are to future services in the infobox - if they are actually happening (i.e, in the formal design or construction phase), that's pretty important to include. Pi.1415926535 (talk) 04:11, 26 January 2018 (UTC)

I'd say remove services from the infobox and put them in the body instead. Then you can have some lovely massive succession boxes. -mattbuck (Talk) 13:07, 26 January 2018 (UTC)

(For examples of my preference, see Bedminster railway station - current services are qualitatively different to future or past services, and they should not be represented together IMO, it leads to confusion -mattbuck (Talk) 21:55, 26 January 2018 (UTC))

Based on your first comment, I figured you were being sarcastic. Having a table take up the whole screen looks cluttered to me. Cards84664 (talk) 22:10, 26 January 2018 (UTC)

It may not be ideal, but it allows you to put the boxes by the text they're illustrating. -mattbuck (Talk) 17:37, 28 January 2018 (UTC)

Template:Infobox station/sandbox

@Pi.1415926535: This is what Union Station in Pittsburgh can look like. The secondary header can be customized to read as "former", "future", or both. Does anyone else agree that this looks better than the way it is now? Cards84664 (talk) 15:02, 26 January 2018 (UTC)

Pittsburgh Union Station
Amtrak inter-city rail station
Services
{{s-rail|title=Amtrak}} {{s-line|system=Amtrak|line=Capitol Limited|previous=Alliance|next=Connellsville}} {{s-line|system=Amtrak|line=Pennsylvanian|next=Greensburg}} | other_services_header = Former services | other_services_collapsible = yes | other_services = {{S-rail|title=Amtrak}} {{S-line|system=Amtrak|line=Pennsylvanian|previous=Alliance|next=Greensburg|branch=''1998-2003''|type=Chicago|type2=Philadelphia}} {{s-line|system=Amtrak|line=Three Rivers|previous=Youngstown|next=Greensburg|branch=''1995-2005''}} {{s-line|system=Amtrak|line=Broadway Limited|previous=Canton|next=Greensburg|branch=''1971-1995''}} {{s-line|system=Amtrak|line=National Limited|previous=Columbus, OH|next=Wilkinsburg|branch=''1971-1979''}} {{s-rail-next|title=Conrail}} {{s-line|system=Conrail|line=Parkway Limited|previous=|next=Wilkinsburg}} {{s-rail-next|title=PRR}} {{s-line|system=PRR|line=Broadway Limited|previous=Crestline|next=Greensburg}} {{s-line|system=PRR|line=General|previous=Canton|next=Altoona}} {{s-line|system=PRR|line=Spirit of St. Louis|previous=Steubenville|next=Altoona}} {{s-line|system=PRR|line=Pittsburgh-Oil City|next=Shadyside|rows1=2}} {{s-line|system=PRR|line=Pittsburgh-Torrance|next=Shadyside|hide1=yes}} {{s-line|system=PRR|line=Toledo-Pittsburgh|previous=Federal Street|next=|rows2=8}} {{s-line|system=PRR|line=Erie-Pittsburgh|previous=Federal Street|hide2=yes}} {{s-line|system=PRR|line=Enon-Pittsburgh|previous=Federal Street|hide2=yes}} {{s-line|system=PRR|line=Cleveland-Pittsburgh|previous=Federal Street|hide2=yes}} {{s-line|system=PRR|line=Columbus-Pittsburgh|previous=Fourth Avenue|hide2=yes}} {{s-line|system=PRR|line=Chartiers Branch|previous=Fourth Avenue|hide2=yes}} {{s-line|system=PRR|line=Wheeling-Pittsburgh|previous=Fourth Avenue|hide2=yes}} {{s-line|system=PRR|line=Monongahela Division|previous=Fourth Avenue|hide2=yes}}

{{Infobox station/sandbox
| name          = Pittsburgh Union Station
| style         = Amtrak
| type          = [[Amtrak]] [[inter-city rail]] station
| services_collapsible =
| services = 
{{s-rail|title=Amtrak}}
{{s-line|system=Amtrak|line=Capitol Limited|previous=Alliance|next=Connellsville}}
{{s-line|system=Amtrak|line=Pennsylvanian|next=Greensburg}}
| other_services_header = Former services
| other_services_collapsible = yes
| other_services =
{{S-rail|title=Amtrak}}
{{S-line|system=Amtrak|line=Pennsylvanian|previous=Alliance|next=Greensburg|branch=''1998-2003''|type=Chicago|type2=Philadelphia}}
{{s-line|system=Amtrak|line=Three Rivers|previous=Youngstown|next=Greensburg|branch=''1995-2005''}}
{{s-line|system=Amtrak|line=Broadway Limited|previous=Canton|next=Greensburg|branch=''1971-1995''}}
{{s-line|system=Amtrak|line=National Limited|previous=Columbus, OH|next=Wilkinsburg|branch=''1971-1979''}}
<!--{{s-rail-next|title=Conrail}}
{{s-line|system=Conrail|line=Parkway Limited|previous=|next=Wilkinsburg}}-->
{{s-rail-next|title=PRR}}
{{s-line|system=PRR|line=Broadway Limited|previous=Crestline|next=Greensburg}}
{{s-line|system=PRR|line=General|previous=Canton|next=Altoona}}
{{s-line|system=PRR|line=Spirit of St. Louis|previous=Steubenville|next=Altoona}}
{{s-line|system=PRR|line=Pittsburgh-Oil City|next=Shadyside|rows1=2}}
{{s-line|system=PRR|line=Pittsburgh-Torrance|next=Shadyside|hide1=yes}}
{{s-line|system=PRR|line=Toledo-Pittsburgh|previous=Federal Street|next=|rows2=8}}
{{s-line|system=PRR|line=Erie-Pittsburgh|previous=Federal Street|hide2=yes}}
{{s-line|system=PRR|line=Enon-Pittsburgh|previous=Federal Street|hide2=yes}}
{{s-line|system=PRR|line=Cleveland-Pittsburgh|previous=Federal Street|hide2=yes}}
{{s-line|system=PRR|line=Columbus-Pittsburgh|previous=Fourth Avenue|hide2=yes}}
{{s-line|system=PRR|line=Chartiers Branch|previous=Fourth Avenue|hide2=yes}}
{{s-line|system=PRR|line=Wheeling-Pittsburgh|previous=Fourth Avenue|hide2=yes}}
{{s-line|system=PRR|line=Monongahela Division|previous=Fourth Avenue|hide2=yes}}
}}

@Cards84664: I think the parameters should have underscores instead of spaces for consistency, but aside from that, this is probably the best solution, unless the WMF decides to get someone to write JavaScript allowing parts of a table to be collapsed. Jc86035 (talk) 16:24, 27 January 2018 (UTC)

@Jc86035:  Done Added underscores. Cards84664 (talk) 17:28, 28 January 2018 (UTC)

@Pi.1415926535: What do you think of this? Cards84664 (talk) 18:28, 5 February 2018 (UTC)

The template looks great - that's exactly the functionality I'm looking for. (Even with the collapsible section, though, all the PRR routes are probably more detail than is really useful to readers. That might better belong as a collapsed box in the article text. But that's a separate discussion). Pi.1415926535 (talk) 20:36, 7 February 2018 (UTC)

@Cards84664: how did you make this edit? It's made a real mess of the table of contents; the section heading; and subsequent edit summaries. --Redrose64 🌹 (talk) 20:27, 16 February 2018 (UTC)

Finalized request

Addition of parameters other_services_header, other_services_collapsible and other_services, as shown in User:Cards84664/sandbox11 and above. Cards84664 (talk) 14:00, 16 February 2018 (UTC)

Cards84664, the {{Edit template-protected}} template contains hooks to the template's sandbox to make responding to your request straightforward. They don't connect to your sandbox, so I can't check your changes with the testcases and as a consequence -  Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES.. Cabayi (talk) 15:46, 16 February 2018 (UTC)

@Cabayi: Added. Cards84664 (talk) 17:23, 16 February 2018 (UTC)

Cards84664, I don't see any consensus to remove the embedded and nrhp parameters (have a look at the sandbox diff). Nor do I see any testcases showing the effect of the change & showing that it works. Cabayi (talk) 17:39, 16 February 2018 (UTC)

@Cabayi: Please double check. Embedded and nrhp were moved down two spaces, from 63/64 to 65/66, same for everything below it. Besides the demonstration of the Pittsburgh Union Station box above on this talk page (The collapsible former services header that is proposed is included with it), I just added the test case. Cards84664 (talk) 18:14, 16 February 2018 (UTC)

(edit conflict) Cards84664, oops, I see the embedded & nrhp - Doh! There's a page for the testcases where we can see the current template & the sandbox side-by-side rather than just one as above which gives no clue what's different between live & sandbox. Please use the standard pages rather than making out that this change is different to every other change. It's not. Cabayi (talk) 18:29, 16 February 2018 (UTC)

@Cabayi: Ok, I've added the parameters into the sandbox testcase, and in the bottom section of the sandbox itself to eliminate the "unknown parameter" preview message. Cards84664 (talk) 18:40, 16 February 2018 (UTC)

Cards84664, Sorry, I guess I'm just not making things clear here, and the template requests can be a steep learning curve. What I was after was Template:Infobox station/testcases#Pittsburgh Union Station. I'll leave the request unfinished for a while so you can see how the testcase is supposed to help. It looks good. Ping me when you've had a look and I'll make it live - at which point the testcase will show both versions of Pittsburgh Union Station as the same. Cabayi (talk) 19:09, 16 February 2018 (UTC)

@Cabayi: Oooh, ok, now I've got it down. Cards84664 (talk) 22:28, 16 February 2018 (UTC)

 Done - Cards84664, please update the documentation Cabayi (talk) 08:34, 17 February 2018 (UTC)

Depreciate or move type parameter

The type parameter is easily the most misused part of this template. Much of the time, it's used to add logos or station names, which are definitely not the "type". (Those should be incorporated into the name field if part of actual station signage, or otherwise omitted). The rest of the time, it's used to add the line or system name (duplicating the lede and the more useful s-rail templates) or the type [BRT, LRT, etc] (which duplicates the first sentence of the lede). Looking at Category:Articles using Infobox station with images inside type and Category:Articles using Infobox station with markup inside type, I see very few articles where the type parameter is actually adding anything useful with its intended purpose.

Hence, I believe that the parameter could (and should) be depreciated entirely to avoid duplicate information and to reduce clutter. The cases where it's used to add a second signage type could be converted to templates in the name field. As a distant second choice, the parameter could be moved lower in the infobox (below the image). That would at least put the image closer to the top, and discourage using the parameter for non-type information and logos. Pi.1415926535 (talk) 04:02, 24 March 2018 (UTC)

@Pi.1415926535: I think it's useful and in line with other infoboxes which have a "type" at the top, such as {{Infobox settlement}}. Someone could use AWB to go through the uses which are using it to indicate station names, etc. (perhaps moving the station name fragment into |custom_header=), although I'm inclined to leave the lines in since otherwise {{Infobox New York City Subway station}} will never get merged purely for aesthetic reasons. Jc86035 (talk) 09:58, 24 March 2018 (UTC)

Agency removed / Depot demolished

Hey. I've been testing in the sandbox, but I really would like to add the following to the template.

|header70=Agency closed |data70={{{agencyclosed|}}} |header71=Depot demolished |data71={{{depotdemolished|}}}

There is a desperate need for these in my work because |closed doesn't do the job for me in any fashion with older railroad stations. Mitch32^{(My ambition is to hit .400 and talk 1.000.)} 22:43, 31 March 2018 (UTC)

Sounds good so far. I'd list demolished and removed underneath closed in the header section, since not all stations are just demolished. Some buildings are moved around quite a bit. As for agency closed, I'll let someone else discuss that here, since I do not see any reason for it in the infobox, mentioning it in the lead works fine. Cards84664 (talk) 02:19, 1 May 2018 (UTC)

I think "agency" and "depot" are far too specific for use on this template. Couldn't you use the event parameters to list this information? Mackensen (talk) 02:42, 1 May 2018 (UTC)

Mapframe maps?

{{Infobox building}} and {{Infobox shopping mall}} have both recently been updated to automatically show dynamic mapframe maps by default. I am proposing to similarly show such maps by default for this template, with the same optional parameters to adjust the size, frame center point, initial zoom level, and marker icon; and to similarly allow the mapframe map to be turned off using |mapframe=no. See Template:Infobox building#Mapframe maps and Template talk:Infobox building#Change to the map parameter so Kartographer works for further information. (FYI: I'm making similar proposal for other buildings infobox templates) - Evad37 [talk] 15:37, 31 August 2018 (UTC)

Please, no. Station infoboxes are far too long already; the last thing we need is a giant map turned on by default. Pi.1415926535 (talk) 16:40, 31 August 2018 (UTC)

@Evad37: Maybe on three conditions: This will be used to phase out the sparsely used map_locator, map_type, and map_dot_label parameters. This will be disabled by default, and it will be collapsed by default. Cards84664 (talk) 17:27, 31 August 2018 (UTC)

Support, I agree about this update. angys (Talk Talk) 11:40, 1 September 2018 (UTC)

Wikidata

Should Wikidata be used for this template? Szqecs (talk) 16:19, 25 October 2018 (UTC)

"line" being confused with "services"

User Ɱ Has suggested that the "line" parameter should be renamed to "corridor" to prevent further confusion with "services". I suggest changing the name to "track_corridor". The main reasoning for this is that the "Hudson Line" is a service, not a physical line. I am willing to assume that this current setup was created because the New York City Subway uses "line" for its physical lines. If this is changed, the NYC station template should not be changed. Cards84664 (talk) 20:00, 7 November 2018 (UTC)

@Secondarywaltz: Cards84664 (talk) 20:15, 7 November 2018 (UTC)

My wishes are a little misconstrued here; "Hudson Line" is more important in most Metro North station article infoboxes than putting in "Empire Corridor". We can add a corridor parameter to go alongside the "line" parameter, or just put them both under "line". But not having the Hudson Line listed in a MNR Hudson Line station is a mistake. ɱ (talk) · vbm · coi) 20:54, 7 November 2018 (UTC)

Again, "line" is currently for physical track, not revenue services. This is redundant to the infobox, since the Hudson Line is already linked in the s-line template. Cards84664 (talk) 21:02, 7 November 2018 (UTC)

@Ɱ and Cards84664: I agree with Cards's reasoning, though usually (for many stations anyway), the lines and services are synonymous. How about putting a "service" parameter directly above or below the "line" parameter, for the routes that stop at the station? And then "lines" can be for the physical lines. epicgenius (talk) 21:08, 7 November 2018 (UTC)

Note that I pinged Secondarywaltz because they have said that adding the service in the line parameter is redundant, but that sounds like an ok idea so far. Cards84664 (talk) 21:21, 7 November 2018 (UTC)

If it is a service, it is obviously redundant to what is detailed under the "services" parameter. There's a lot of duplication stuffed into many of these infoboxes. Another source of duplication is "type". Some of these parameters are grandfathered from when the other options did not exist. Many editors seem to believe that if a parameter exists it must be used, which is just wrong! Secondarywaltz (talk) 00:55, 8 November 2018 (UTC)

The problem here seems to be that Hudson Line is both the name of a service and the official name of the section of track. (It's not the only place that frustrating duplication occurs.) I think the best solution for Hudson Line stations would be to have "Hudson Line (Empire Corridor)" under the line parameter. Pi.1415926535 (talk) 21:37, 8 November 2018 (UTC)

Agreed. We don't need to use all parameters in the infobox if it potentially causes confusion. It does not make the infobox incomplete to leave parameters blank. Such omissions should not be construed to mean we don't know the information and someone needs to add them. It means that we've exercised editorial judgement that only one of the closely related parameters is needed for that article. Oh, and as a side note, the Hudson Line isn't a service that runs on the Empire Corridor. The Hudson Line is the name of the physical line itself for the portion controlled by Metro-North from the Hamels Wye to Poughkeepsie. Technically they lease it and the Harlem Line from the legal successor of Penn Central, as they do Grand Central, but that doesn't change that the Hudson Linenis the actual name of the Line, which Empire Service and other Amtrak trains via Albany use. "Empire Corridor" may be Amtrak's name for the portion they control (via lease from CSX) of the Poughkeepsie–Schenectady portion, but I've also seen that still called CSX's Hudson Subdivision name. Indeed, I have never seen the term "Empire Corridor" used to refer to any physical tracks ever, just used for the service area in general. So I think the underlying disagreement here is based on a fundamental error of fact. oknazevad (talk) 21:48, 8 November 2018 (UTC) PS, Pi had many of the same ideas but beat me tonit with an edit conflict. I still see no need to mention "Empire Corridor", as that is not the name of a line.

Infobox width

Is there any particular reason why bodystyle is set to width: 25.5em; instead of the default infobox size being used? From what it seems, it won't change much to go back to the default {{Infobox}} size. – PhilipTerryGraham (talk · articles · reviews) 01:57, 9 November 2018 (UTC)

Edit request

Remove the line | bodystyle = width: 25.5em; from {{Infobox}}. There is nothing in documentation that states why the infobox width needs to deviate from the default, and there is nothing to suggest that going back to the default infobox width would cause any damage to the template in any way. – PhilipTerryGraham (talk · articles · reviews) 01:40, 19 November 2018 (UTC)

The width change was discussed in the archives of this talk page and implemented deliberately. I think this merits more discussion. Pinging Jc86035, who requested the default width. Also, Template:Infobox GB station and its siblings appear to use 265px as a default width if an image or map is supplied. It might be useful to make these infoboxes consistent. – Jonesey95 (talk) 05:52, 19 November 2018 (UTC)

@Jonesey95 and Jc86035: It would've been incredibly useful to have had this explicitly stated in the documentation rather than in reply to an edit request. – PhilipTerryGraham (talk · articles · reviews) 08:21, 19 November 2018 (UTC)

PhilipTerryGraham, perhaps. The documentation is not protected. Edit it to add the default width if you think that would improve the documentation. – Jonesey95 (talk) 11:46, 19 November 2018 (UTC)

@PhilipTerryGraham and Jonesey95: I'm not entirely sure what happened there, but I think the infobox should probably stay at its current width. Regardless of images, {{Adjacent stations}}/{{S-line}}/{{Rail line}} and {{Routemap}}/{{BS-map}}/{{BS-table}} are often used in the infobox, and making the table wider means that the child tables inside the infobox don't get squashed. Jc86035 (talk) 10:03, 26 November 2018 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. It appears the width of this template was the subject of quite some discussion in the past. We should have a discussion first. Also, what Jonesey said. Enterprisey (talk!) 07:08, 19 November 2018 (UTC)

Span tags changed to div tags to fix Linter errors

After a bunch of testing in the sandbox, I have changed some of this template's <span>...</span> tags to <div>...</div> tags in order to fix Linter div-span-flip errors (a div tag inside of a span tag, which is invalid HTML).

As far as I can tell from my testing, the infobox should look the same in all articles before and after this change. That said, WP editors are endlessly creative in their use of template parameters, and with 30,000+ transclusions, there are bound to be a few unexpected side effects. Please post here if you notice anything unusual or bad happening after this change, along with a link to an affected page. Thanks! – Jonesey95 (talk) 05:46, 28 November 2018 (UTC)

Fare zones

Hey, so fare zones are something that many travelers won't know about, unless you're a very experienced commuter. It's a back-end system, not meant for passengers to really have to understand (at least in the NY and California rail/subway systems I've traveled with). I think the term "fare zone" in this infobox at least needs a wikilink to an article or section at least explaining what a fare zone is and how they work. It appears such an article or section hasn't even been created yet! Lastly, I think the fare zone parameter should be filled with more than just one number (like "3"); it should say 3 out of 8, or some other way of displaying where in the rail system the station lies. ɱ (talk) · vbm · coi) 16:18, 16 December 2018 (UTC)

• Conversely, the absence of an article on fare zones might point toward removing the parameter altogether. Wikipedia isn't a travel guide. If we're looking to express distance from the terminus, the raw mileage is a more meaningful measure. Mackensen (talk) 16:42, 16 December 2018 (UTC)

True, I think it has unnecessary railfan nuance that the vast majority of readers won't understand or care about. ɱ (talk) · vbm · coi) 05:43, 18 December 2018 (UTC)

Template-protected edit request on 8 January 2019

Documention shows deprecated parameter image_size in an example. MB 14:49, 8 January 2019 (UTC)

 Not done: {{edit template-protected}} is usually not required for edits to the documentation, categories, or interlanguage links of templates using a documentation subpage. Use the 'edit' link at the top of the green "Template documentation" box to edit the documentation subpage. Cabayi (talk) 14:50, 8 January 2019 (UTC)

What happened with Module:Rail

This template is recently been indicated that it is part of the Module:Rail and none of the template’s code indicate that. I am the main editor for the Chinese version of the Infobox station and I am extremly concerned about this future change that there is no discussion about. Just a quick reminder to whoever is doing this, this template exists in numerous page in multiple language Wikipedia, any major change can have significant affect. -- VulpesVulpes825 (Talk) 20:27, 2 February 2019 (UTC)

• Discussion is at Template talk:Adjacent stations. Short version: this template continues to depend on Module:Adjacent stations and not Module:Rail. Mackensen (talk) 20:39, 2 February 2019 (UTC)

Use of the Services field

What action is recommended when we encounter a Services field that is used contrary to the instructions with the infobox? At Rae Bareli Junction railway station, instead of an s-line entry, I found, "services = ." Leave it in, take it out? What? Rhadow (talk) 14:35, 5 February 2019 (UTC)

@Rhadow: For the things which have parameters (e.g. parking) I would add the appropriate parameters. I would remove the other icons without replacement, or turn them into prose if sources can be found.

The icons themselves probably violate something in WP:MOSICON, and the "kiosk" and "food plaza" icons in particular are very unclear. The user who added them, Ministry Of IT, is indefinitely blocked for sockpuppetry. Jc86035 (talk) 15:26, 5 February 2019 (UTC)

I find these from time to time as well (e.g. "ticket agent" or "washroom"). They tend to be things that belong in prose, if at all, and I tend to simply remove them. Mackensen (talk) 17:12, 5 February 2019 (UTC)

I woulds like to find a developer help me make a semi-automated bot to look at the ADA field. Lots of stations are at-grade and are not well sheltered. The likelihood that they are actually equipped for disabled passengers is quite low. I suspect an editor had fun adding the wheelchair icon to lots of articles with no backup whatsoever. Rhadow (talk) 19:02, 5 February 2019 (UTC)

Category:Wikipedia page with obscure country or subdivision and this template

Hey, this template has a lot of pages listed in Category:Wikipedia page with obscure country or subdivision. Could any maintainers please see how this can be fixed? For a relevant discussion see Template talk:Infobox settlement#Category:Wikipedia page with obscure country or subdivision and this template. --Gonnym (talk) 10:04, 13 March 2019 (UTC)

• It looks as though at least one issue is that the coordinates display tries to use |country= and |borough= as part of its markup. The template documentation doesn't indicate that; folks have put whatever values there. In 2700 West Sugar Factory Road station the {{USA}} parameter was in use: [1]. I've updated the documentation to reflect that ([2]). It would be good to have a tracking category to find markup inside |country=; I'm unfamiliar with how that's accomplished. Mackensen (talk) 11:13, 13 March 2019 (UTC)
• What's to be done with Bayerisch Eisenstein railway station? Apparently it straddles the border. Mackensen (talk) 11:20, 13 March 2019 (UTC)
• Also there's Cookstown railway station, where it's unclear how to pass Northern Ireland back to the template. I think we're going to need a rethink about how this is handled, and some assistance from an expert. Mackensen (talk) 11:27, 13 March 2019 (UTC)
• The option that was chosen at Infobox settlement was to pass |nocat=true to the module that adds this category, so that this category is never applied to pages using that infobox. There is ongoing discussion about whether and how to track usage of that infobox with missing or invalid values. – Jonesey95 (talk) 11:44, 13 March 2019 (UTC)

usage questions

There are Category:Articles using Infobox station with markup inside name, Category:Articles using Infobox station with links or images inside name, and Category:Articles using Infobox station with markup inside type. In reading the template documention, it looks like |name= and |type= should be used with plain text and wikilinks such that these categories ideally should be empty.

Vidhan Sabha metro station is an example. This is my version of the infobox where I have followed the documention for these params and added |symbol=. Is this the "correct" infobox; should I make this change? Also, I see no place for the logo that was part of the name. Does that get left out? MB 05:22, 27 April 2019 (UTC)

Add a second image paramater

I think it would be nice to have a second image parameter for the purpose of including a station's logo, for example having File:Chicago Union Station logo.svg on the infobox of Chicago Union Station. funplussmart (talk) 00:25, 27 May 2019 (UTC)

Nah. A logo for a train station doesn't add any value to the infobox (compared to, say, a company) - the photograph of the station is vastly more useful and important. If there really is a compelling case to add the logo, {{photomontage}} works just fine - see Springfield Union Station (Massachusetts) for an existing use. Pi.1415926535 (talk) 01:03, 27 May 2019 (UTC)

Well we do have logos for airports on their articles, see O'Hare International Airport for one example. As long as it is just used in the infobox and only the current logo, I think its fine. funplussmart (talk) 00:45, 28 May 2019 (UTC)

That's a good point, though airports tend to universally have logos, while very few train stations do. Still, photomontage is better than adding yet another parameter to this template. Pi.1415926535 (talk) 00:49, 28 May 2019 (UTC)

Yeah that template is probably enough in this circumstance. funplussmart (talk) 15:34, 28 May 2019 (UTC)

Template-protected edit request on 24 July 2019

The proposed code is in the template sandbox. The change makes the route diagram subheader default text "Track layout" if the route diagram's "Legend" link is to Template:Railway track legend. Jc86035 (talk) 09:38, 24 July 2019 (UTC)

@Jc86035: {{sofixit}} ;) — xaosflux ^Talk 11:59, 27 July 2019 (UTC)

@Xaosflux: Thanks, I'd forgotten to actually make the edit. Jc86035 (talk) 12:01, 27 July 2019 (UTC)

Deprecate and replace former

I don't have hard data on this, but I've noticed |former= used for both former names (intended) and former operators. The name is ambiguous; I propose adding a new parameter, |former_names=, and deprecating and removing |former=. Former can display for former names while cleanup takes place. Mackensen (talk) 18:20, 18 August 2019 (UTC)

• sandbox and testcases. Mackensen (talk) 18:28, 18 August 2019 (UTC)

Demolished Tag?

Example

Jersey City
Passenger railroad terminal Ferry Terminal
Pennsylvania Railroad's Jersey City Station, 1893
General information
Coordinates	40.71648°N 74.03238°W / 40.71648; -74.03238
Operated by	Pennsylvania Railroad (PRR)
Connections
History
Opened	1834 (1834)
Closed	1961 (1961)
Key dates
1963 (1963)	Demolished
Former services
Preceding station Pennsylvania Railroad Following station Terminus Jersey City Ferry Cortlandt Street Terminus Manhattan Transfer Until 1937 toward Chicago Main Line Terminus Marion toward New Brunswick New Brunswick Line Preceding station Lehigh Valley Railroad Following station Manhattan Transfer toward Buffalo Main Line Until 1913 Terminus

Would it be appropriate to add a "demolished" tag to the template. I noted that in the Exchange Place station (Pennsylvania Railroad), the template says it closed in 1961, but the fate of the building after that is not clear without reading the text of the article. –Zfish118^⋉talk 17:56, 18 August 2019 (UTC)

• This can be done with the numbered |events= parameters; it may a common enough use case to justify a standalone parameter. Mackensen (talk) 18:21, 18 August 2019 (UTC)

  Pretty sure this has been suggested and rejected before, one reason being that demolition can be spread over several decades. For example, Birmingham Curzon Street - demolition began in the 1890s and is still not finished: the main entrance hall still stands, but virtually all of the rest has now been cleared away, some of it in the last ten years. --Redrose64 🌹 (talk) 20:43, 18 August 2019 (UTC)

That's extraordinarily rare, and sure there will always be outliers that would make a parameter not useful. However, most stations are demolished relatively quickly. This parameter is pretty essential, as infobox building has had the parameter since its very creation. And station articles are often as much about the building as they are about the services, usually far more. ɱ (talk) 21:07, 18 August 2019 (UTC)

• I tried "events", but the placement as a "Key Event" is not seem desirable (see Example in sidebar). "Demolished" would more logically be in the "history" section, after "closed". "Demolished" and perhaps "Rebuilt" would seem to be fairly standard tags. –Zfish118^⋉talk 22:55, 28 September 2019 (UTC)

Electrified parameter

Mont-Royal station (RTM)
History
Electrified	25 kV AC 60 Hz catenary

South Amboy station
History
Electrified	1938

Stratford station (Connecticut)
History
Electrified	12.5 kV AC overhead catenary

South Amboy station
History
Electrified	12 kV 25 Hz AC or 12.5 kV AC Which one?

What is the purpose of the field "| electrified = " in Template:Infobox station? Is it to give the date (year) of electrification or the details of such? The three random samples show no consistency. Other than that, could "electrified" br linked to "Railway electrification system"? Peter Horn User talk 18:33, 22 November 2019 (UTC)

electrified: Date station was electrified, if not previously at date of opening years So the usage in two of the random samples is not the intended one. Peter Horn User talk 18:47, 22 November 2019 (UTC)

The parameter should, quite honestly, be removed entirely. Its intended use obviously is not clear, and isn't that useful anyway. Electrification is not an event that needs to be noted in the infobox - it is not on par with opening and closing. Pi.1415926535 (talk) 23:11, 22 November 2019 (UTC)

@Pi.1415926535: I would rather rename the parameter to "electrification" so that it becomes part of the station description as it now is in two of the three sample stations. In all other cases one would erase the year and replace with the actual info to be found in the description of the line(s) the station serves. See North Jersey Coast Line in the case of the South Amboy station as well as the revised sample. Peter Horn User talk 23:48, 22 November 2019 (UTC)

Electrification is a property of the line, not the individual station. In general, every station on the line will have the same electrification; thus, it belongs there rather than the individual stations. Pi.1415926535 (talk) 03:45, 23 November 2019 (UTC)

I'd also be in favor of removing it; as Pi.1415926535 notes the electrification system is a property of the line, not the station. That said, it's a somewhat popular field, with ~6400 uses (about 16% of transclusions), albeit 400 of them are simply set to "Yes." Mackensen (talk) 17:05, 1 January 2020 (UTC)

Alternate names for "platforms"

I've been looking into the re-use of this infobox for ferry terminals (something that other editors have already done), but noticed that some labels would need to have alternatives to better fit the subject (or account for WP:ENGVAR). I'd like to propose an option to change label11 to display either "Platforms", "Slips", or "Berths" (the latter two for ferries); and label15 to display either "Bus stands" or "Bus bays" (used in American and Canadian English), based on whether {{{platforms|}}}}} or {{{slips|}}} is filled (defaulting to platforms). SounderBruce 04:09, 31 January 2020 (UTC)

Center the name when logo is added

Please check Sandbox for the code. When copying, you only need to copy the code in |above = . Please check testcases for result. This is a simple CSS code fix and has been implemented in Chinese Wikipedia for a year without issue. Since this is only a small change, I do not think a consensus is necessary. --VulpesVulpes825 (talk) 00:21, 9 February 2020 (UTC)

Is it your intention to also change the former_names= parameter to former=? – Jonesey95 (talk) 03:17, 9 February 2020 (UTC)

@Jonesey95: No, it is not my intention. I only change the code in above. —VulpesVulpes825 (talk) 18:12, 9 February 2020 (UTC)

@VulpesVulpes825: It's been quite a while since I wrote the code for the icons (I think that's now more than five years ago), but I think the main reason that I didn't centre the text is that it's not possible to know how wide the icons (or the station name) will be in advance. Your change appears to introduce the possibility that the text and icons will collide and overlap with the icons that are currently available in {{rail-interchange}}. (For comparison, I aligned {{navbox}}'s header text some time ago by adding margin: 0 4em to the header text div, but the fixed value is mainly possible because we know approximately how wide the show/hide and V/T/E links are in typical sans-serif fonts. You could take a guess that the maximum for the icons in this template is going to be about 100px or 125px, but there are a number of unusually wide icons in {{Rail-interchange}} and so that might not always be the case.)

If you're confident that that won't be a problem I'm willing to merge the changes, but I think it's worth addressing the issue first. Jc86035 (talk) 18:52, 9 February 2020 (UTC)

That is indeed a really big problem in English. The code will fail if the station name has a long word in it. I will pull my EP, thanks for pointing the issue. --VulpesVulpes825 (talk) 19:38, 9 February 2020 (UTC)

How to find external style templates?

I am looking for the external style template for Via Rail. On Montreal Central Station I noticed that some of the text is invisible because text colour is very close to background colour, so going into the infobox template I see "| style= Via Rail". If I'm understanding the template documentation, there should be a {{Via Rail style}}, but no such template exists. Indefatigable (talk) 22:32, 2 May 2020 (UTC)

• The documentation needs to be updated; anyway you'll want to modify Module:Adjacent stations/Via Rail, probably the name_format entry. Mackensen (talk) 17:26, 5 May 2020 (UTC)

Missing field

The field "gauge" is missing and sould be added? Peter Horn User talk 15:52, 5 May 2020 (UTC)

Wouldn't that be better suited for lines instead? Cards84664 16:50, 5 May 2020 (UTC)

Precisely. Gauge is not a property of stations and should not be shown in their infoboxes. Pi.1415926535 (talk) 16:52, 5 May 2020 (UTC)

Then "electrified" should not be included either. However the track gauge is just as much a feature of the station as is the electrified. Peter Horn User talk 18:57, 5 May 2020 (UTC)

Yes, the electrified parameter should be removed as well. Pi.1415926535 (talk) 19:03, 5 May 2020 (UTC)

No, not at all, you don't get it. Track gauges need to refer to an entire line, as lines don't vary in gauge. However, some lines, including the active Hudson Line in the New York metropolitan area, have some portions of the line electrified and other portions not, and the parameter could also be used to determine the date a station was electrified, as it's often a gradual process, not happening all at once. ɱ (talk) 19:34, 5 May 2020 (UTC)

I understand that documenting the spread of electrification is useful. But that's still a property of the line, not the station. You wouldn't say that "Southeast station was electrified in 1984"; you would say that "the Harlem Line was electrified to Southeast station in 1984". While the date that electric service to a given station began is worth discussing in the prose, it's not a fundamental property of the station the way the open/close dates or number of platforms are, and it shouldn't be in the infobox. (It's very telling that usage of the parameter in articles varies between dates, type of electrification, voltage/frequency of electrification, and simply yes/no - that indicates that the purpose of the parameter is far from obvious.) Pi.1415926535 (talk) 20:35, 5 May 2020 (UTC)

Luzern
General information
Line(s)	Zürich–Lucerne 1,435 mm (4 ft 8+1⁄2 in) Gotthard (Lucerne branch) 1,435 mm (4 ft 8+1⁄2 in) Olten–Lucerne 1,435 mm (4 ft 8+1⁄2 in) Bern–Wolhusen–Lucerne 1,435 mm (4 ft 8+1⁄2 in) Brünig Railway 1,000 mm (3 ft 3+3⁄8 in)
History
Electrified	1922 (1922)

I added the partial infobox of the Lucerne railway station to show that the field electrified should stay either as yes with a start date or no. Gauge should be inserted at the individual lines as here shown. Peter Horn User talk 23:05, 5 May 2020 (UTC)  

Thank you for illustrating so well why these parameters don't belong in the infobox. MOS:INFOBOXPURPOSE states that The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance. The lines section in your example infobox has more than twice as much text as my below example, obfuscating the important information (which lines serve the station) with much less important information (the gauge of those lines). Readers are simply not coming to a station article looking for the gauge of the lines - unless you can provide some evidence otherwise, then they absolutely should not be in the infobox. Meanwhile, "Electrified: 1922" gives the reader absolutely no actual knowledge. What was electrified? Was any change made to the station? Who knows. All that tells us is that some electric service on some line first stopped at the station in 1922. That's contextless information, not a key fact. Pi.1415926535 (talk) 00:27, 6 May 2020 (UTC)

Luzern
General information
Line(s)	Zürich–Lucerne Gotthard (Lucerne branch) Olten–Lucerne Bern–Wolhusen–Lucerne Brünig Railway

It doesn't even tell us that. "Electrified: 1922" might mean that the station was provided with electric lighting in 1922 (not an unreasonable occurrence) previously having been lit by gas, or perhaps oil. --Redrose64 🌹 (talk) 06:58, 6 May 2020 (UTC)

The years parameter would do that just as effectively. -mattbuck (Talk) 07:51, 6 May 2020 (UTC)

Zip codes

Currently, the US example infobox shows the ZIP code - used primarily for postal service - in the address. This serves no use to the reader, as the purpose of the address here is to find the station, not send mail to it. I would like to remove the zip code from this example infobox, as I believe it sets a bad precedent. MOS:INFOBOXPURPOSE states that The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance which supports the removal. Pi.1415926535 (talk) 01:33, 4 June 2020 (UTC)

Support, doesn't server much of a purpose other than trivia. Cards84664 01:49, 4 June 2020 (UTC)

My weakly held view: ZIP codes are a useful disambiguator for addresses in the US and take up very little space for the value they provide, but we probably shouldn't have one on the template's documentation page. Some addresses are listed in one municipality by taxing authorities, but in other municipalities by the postal service. Some states have towns with similar names but different ZIP codes. ZIP/postal codes can help a reader zero in on the right location using mapping software.

For what it's worth, I looked at all, or almost all, of the 40+ infoboxes listed in {{Buildings and structures infobox templates}}, and it looks like {{Infobox prison}}, {{Infobox restaurant}}, {{Infobox historic site}}, {{Infobox swimming pool}}, and {{Infobox school}} mention or explicitly support postal codes. I may have missed a couple. – Jonesey95 (talk) 04:10, 4 June 2020 (UTC)

Template-protected edit request on 12 July 2020

Could you please add zh-Hans-CN, zh-Hant-TW and zh-Hant-HK to the list of languages that don't get emboldened? These are common language codes on Wikipedia and more accurate than their zh-Hans/zh-CN etc counterparts. Many thanks Danielt998 (talk) 21:54, 12 July 2020 (UTC)

 Done * Pppery * _{it has begun...} 22:18, 12 July 2020 (UTC)

Merge notice

@Pppery: Given that the proposed merge is one-way (it would not affect existing uses of this template), is having the TfD notice necessary? It's not a big deal, but it seems unnecessary especially given how widely used this template is. Pi.1415926535 (talk) 03:52, 26 July 2020 (UTC)

There's no consensus I can find about when it is appropriate to noinclude TfD tags (the instructions only mention it [f]or templates designed to be substituted, so I generally err on the side of more notification, and only do so for extremely highly-used templates like {{sidebar}}. Of course, another template editor or admin is free to noinclude the template, and you could open a {{edit template-protected}} request to do so, which I would refrain from answering. * Pppery * _{it has begun...} 04:16, 26 July 2020 (UTC)

Traffic / Passengers

The traffic section looks a bit messy to me. I had an example in my sandbox, but that's been deleted, but my point is that we only use the traffic section for passengers currently it seems (not freight), so repeating passengers for each row along with the year seems unnecessary. Perhaps change the heading to "Passengers" and omit the word on each row instead, so each row doesn't span two lines. The repetition is a bit distracting. ProcrastinatingReader (talk) 11:23, 30 July 2020 (UTC)

• I think renaming the section is fine. Changing the row display is slightly tricky because {{Rail pass box}} handles the passenger display. Mackensen (talk) 11:50, 30 July 2020 (UTC)
• See Template talk:Rail pass box#Change in passenger display. Mackensen (talk) 12:12, 30 July 2020 (UTC)

  Thanks for making that! I've responded there. On the tangent note of freight, I wonder if it would be interesting to have parameters for being able to display freight traffic, it does seem to be a thing I guess. Though the data is probably less interesting than passenger totals for many stations, I guess for some stations it could be interesting and useful. But I don't know enough about trains/stations to know, and that's beyond the scope of my passengers label request here anyway; just an interesting sidethought I had. ProcrastinatingReader (talk) 12:37, 30 July 2020 (UTC)

  It's a thing, but I don't think we generally capture that data on Wikipedia. We have very few articles about freight-only stations, and few if any operators publish freight data for individual stations/terminals. Getting passenger data is difficult enough :). Mackensen (talk) 14:17, 30 July 2020 (UTC)

• Sandbox updated to show the revised passenger handling: Template:Infobox station/testcases#Bern. Mackensen (talk) 16:54, 30 July 2020 (UTC)

  Looking at it, I feel rather indifferent about it. The issue I was trying to address (now that my sandbox is undeleted) is: Special:Permalink/968998076. Some areas report statistics as 2017/18 for example (at a quick search, I can't find a definition that would narrow this down to something shorter), so it spans two lines, and then that looks ugly. At the same time, the testcase looks slightly ambiguous at first glance. So I'm not sure? ProcrastinatingReader (talk) 17:04, 30 July 2020 (UTC)

  I've changed the example so that the benefit from wrapping is a little more obvious. Mackensen (talk) 17:38, 30 July 2020 (UTC)

  Hmm, that is exactly what I was getting at, but seeing it live I have a mixed feeling on both the before and after. Something just feels slightly off, wonder if it can be designed even better, but not sure. What are your thoughts? ProcrastinatingReader (talk) 18:40, 31 July 2020 (UTC)

  One thought that I have, though it relates to the other box, is that "rank" could perhaps be dropped altogether. It's awkward if you list multiple years, it's semantically invalid as implemented, and a lot of transit systems don't publish ranks in the first place. In the case of the current example, it's misleading at best. I think it's true to say that there are ~1700 stations in Switzerland, but the dataset in question includes numbers for about 900 of them--those owned and served by SBB, plus the Rhaetian Railway, MGB, SOB, Zentralbahn, and others. Also, the figures are rounded and averaged, and no station has a lower average daily figure than 50. Mackensen (talk) 18:56, 31 July 2020 (UTC)

  Sounds like a good idea to me (or at least a different way of displaying it, so it's not using up its own row), though I don't really know enough about the range in station articles to have the most useful opinion here. Hopefully some more editors can join in with comments. ProcrastinatingReader (talk) 17:14, 1 August 2020 (UTC)

template error?

At least on Japanese Station wikipedia pages, at least in Firefox, for example Shibuya Station have the info all jammed to the left and push all the text to the bottom. It's all whacky. Is this a common error or whats going on? Nesnad (talk) 14:03, 9 September 2020 (UTC)

Nesnad, it's not doing that for me, and I tried in a couple different browsers. Mackensen (talk) 15:25, 9 September 2020 (UTC)

Looks fine to me too (in Firefox on Windows). —  Jts1882 | talk  15:33, 9 September 2020 (UTC)

What the heck. Feel crazy. No longer a problem. Weird. I feel like the little kid calling wolf. I swear it looked like that for days. What the heck. Thanks all, Nesnad (talk) 15:47, 9 September 2020 (UTC)

Discussion at Template talk:Increase § New template available for automatically formatting a value

 You are invited to join the discussion at Template talk:Increase § New template available for automatically formatting a value. {{u|Sdkb}} ^talk 02:39, 14 September 2020 (UTC)

Parameter validation

Jonesey95, re Special:Diff/984867522, that module also adds deprecated and duplicate parameters (incl tracking connections/other). Its implementation was in compliance with WP:TPECON, which only adds pages to newly created tracking categories, and they are hidden. It does not modify the existing ones, ergo no disadvantages. No false positives were reported here - if they were, they could've been fixed or discussed. Please clarify how your revert complies with WP:TPEDISPUTE. ProcrastinatingReader (talk) 17:46, 22 October 2020 (UTC)

Wait... Too many false positives (e.g. symbol_location3) -- that's because the TemplateData says "symbol3_location" (which is what it should logically be named, now that I think about it). If you had raised it on the talk, that could've been mentioned. I don't understand why you'd (a) remove hidden tracking cat code (b) not just fix the TemplateData and (c) not discuss it here, (d) how this isn't a revert is [...] out of sheer reflex, (e) how good cause, careful thought were met and finally (f) why you felt a discussion was not possible per and (if possible) a prior brief discussion with the template editor whose action is challenged. Fixed in Special:Diff/984884537. Please self-revert. ProcrastinatingReader (talk) 17:51, 22 October 2020 (UTC)

I'm not sure what the Template Data section of the template documentation, which is not protected, would have to do with detection of unknown or deprecated parameters. Nothing functional, I hope. We have a battle-tested module for that work, a module that is used in templates that are transcluded in 11 million pages. If you wanted to know how to use it to detect and categorize deprecated parameters, all you had to do was ask.

The module you added led to the creation of a redundant "unknown parameter" category with a one-letter capitalization difference, which was an error. It appears that you also created a "deprecated parameter" category that is mis-documented, which does not explain which parameters are deprecated, and for which articles do not display any error message. The module was malfunctioning by putting up red error messages for parameters that were not unsupported, so I commented it out. Not out of reflex, let alone "sheer reflex", but with good cause (explained at length here) and careful thought. The module appears to have been applied without discussion, and its application was not followed up on to ensure that it was functioning properly; to avoid editors' damaging of articles, I commented out the code until you could fix all of the problems with its implementation. Now that these problems have been identified, please test changes like this in the sandbox and post on this page when you would like your changes to be reviewed.

On a more general note, I have been unimpressed by your cavalier attitude toward template editing on this widely used template and on the related {{Infobox GB station}}. I, and many other editors on this page, have tried to work with you, but you have insisted on adhering to a timeline and process of your own making, in a way that benefits neither editors nor readers. Please slow down and work collaboratively. Templates, especially those with many transclusions, should be edited carefully and deliberately, and those edits should be followed up on to ensure that they work as intended. You have failed to do so with multiple edits to this template and to Infobox GB station. Failure is acceptable, as long as it is acknowledged and corrected. – Jonesey95 (talk) 19:11, 22 October 2020 (UTC)

Jonesey95, if you don't know what it's doing, why not ask here? When I thought your edit to {{Infobox GB station}} (re coordinates), which isn't even TE protected, was mistaken, I brought it up on the talk page to discuss with you rather than revert. That discussion led to something productive. You decided to edit war on a TE protected template with another TE, which is even worse due to the mildly contentious discussion in which we're both involved above. Given this, did you seriously think reverting was good judgement? |symbol_location3= is used on 74 articles, the module adds hidden tracking cats, evidently not large-scale, and nobody else reported it; evidently was time to discuss when you know my response time is fast. You chose not to. I cannot see from any angle why you'd think reverting was the better option. Your edit was not in compliance with TPE guidelines, and it definitely wasn't the action to take if you expect deescalated and calm, productive template editing. Is that not what we both want, even though it apparently is not happening currently? Anyway, the issue is resolved per Special:Diff/984884537. Will you kindly self-revert? ProcrastinatingReader (talk) 19:30, 22 October 2020 (UTC)

When I see a template error, I generally fix it if the fix is obvious. If the error is multifaceted, as described above, and was newly introduced without discussion, it is often best to simply undo the error until it can be fixed. Before I would be open to reverting my commenting of the addition of this module, I would like to see it tested in the sandbox to see if it fixes the list of problems I described above. The category descriptions at Category:Pages using Infobox station with deprecated parameters, Category:Pages using Infobox station with unknown parameters (the new one, with the capital "I") and Category:Pages using Infobox station with duplicate parameters have not been fixed yet, for example. They contain multiple errors. – Jonesey95 (talk) 19:51, 22 October 2020 (UTC)

Jonesey95, synced my edit to sandbox. Not sure what you want to test, or how, but feel free to do it as you desire. As for the category descriptions, I assume you mean the fact that they refer to Module:Check for unknown parameters. Sure, I can create a new template to be more descriptive. ProcrastinatingReader (talk) 19:58, 22 October 2020 (UTC)

Categories updated. ProcrastinatingReader (talk) 20:03, 22 October 2020 (UTC)

Making progress. I have fixed some errors and omissions in the category page template. Is the sandbox working? Do you have test cases or temporary usages of the sandbox in articles to demonstrate the module's function? Does it / should it apply categories to non-article-space pages? (The unknown parameter check is typically configured to apply categories to article space only.) Test cases are the next step after making a change to the sandbox. When I preview Achern station, which uses the unsupported |iso_region=, I do not see an error message with the sandbox template. Should I? Will I see error messages for deprecated and duplicated parameters? If not, how is an editor supposed to know how to fix the problem? I'm happy to mentor you through this process. – Jonesey95 (talk) 21:55, 22 October 2020 (UTC)

Jonesey95: The module was not accepting sandboxes, it should work now. You can see a test at User:ProcrastinatingReader/sandbox2. It won't work in the /testcases (module ignores template-space). It does apply to some non-articlespace, (e.g. draftspace, userspace drafts). And I think it should - individual templates can override if they prefer something different, but it's useful to have the tracking on draftspace/userspace drafts. It won't work in, say, talkspace, for example. You should be able to preview Achern station and see it now. ProcrastinatingReader (talk) 22:51, 22 October 2020 (UTC)

Note, by the way, the first message you will see in preview is due to the unknown parameters module, so that message will be duplicated. The deprecated one will not. ProcrastinatingReader (talk) 22:53, 22 October 2020 (UTC)

I'm not sure why a module would ignore template space. That's where testcases live by default. That should be fixed.

Why categorize User-space pages? Should editors be messing with other editors' user-space drafts and experiments? If not, they are just clutter in the category.

At Khewra railway station, I see "Warning: Template:Infobox station/sandbox used with duplicate parameters: caption (this message is shown only in preview)." That's only one parameter; it should list both of the duplicated parameters.

At Ans railway station, it says "unknown parameters", and then only one parameter is listed.

This module is not ready for production use. Perhaps we should move this module debugging conversation to Module talk:Parameter validation. I have placed that page on my watchlist if you would like to follow up there. – Jonesey95 (talk) 23:11, 22 October 2020 (UTC)

I think that this is related to User talk:MusikAnimal#Protecting template /doc pages. --Redrose64 🌹 (talk) 22:00, 23 October 2020 (UTC)

Parameter deprecation

Designations

Per Template:Infobox_station#Embedding_other_infoboxes designations are meant to be embedded in |embedded=. A legacy param remains where |nrhp= is being misused in templates to replace core functionality. Page list. Examples: Washington Union Station, Philipse Manor station, Portland Union Station, South Orange station, Orange station (NJ Transit). The whole infobox is embedded to chuck in a map / extra map (rather than use this IB's map), repeat params (like address, coordinates, etc see Portland Union example). It's a mess. The param shouldn't really exist anyway, since designations are embedded into the embedded param. Proposing removal of the param, and a bot run to convert usages into proper designations, move maps / other relevant, provided non-duplicated info to this infobox, and retain only the standard set of designation parameters. ProcrastinatingReader (talk) 17:24, 12 October 2020 (UTC)

In what way is |nrhp= a "legacy" parameter? As far as I can tell, it has not been documented, but it has been in the template since 2009 and is widely used (|embedded= was added as an alias for nrhp in 2011 and then immediately separated into its own row). I don't see any discussion in the talk page archives, so there is no way to know whether one parameter is supposed to be preferred, or whether they have separate purposes. Maybe |nrhp= just needs to be documented. – Jonesey95 (talk) 19:06, 12 October 2020 (UTC)

I don't follow this at all. {{infobox NRHP}} is a whole separate infobox which is being validly embedded to include the relevant info about the property being listed on the National Register of Historic Places. This is done with many other infoboxes including {{Infobox lighthouse}}, {{building}}, etc. It includes the date added to the register, the refnum, architectural style, etc - info not included in the station infobox. I agree that duplicated info (e.g. address) should be removed. That calls for cleanup of the usage, not removal. MB 19:09, 12 October 2020 (UTC)

Removal of the parameter name, not of its value. Its supported purpose in this template, as far as I can tell, is designation, similar to {{Infobox designation list}} (which supports this exact functionality anyway...). That purpose is fine, but I can't see why it should be used as an actual embedded infobox almost the size of the main station one itself, or why it needs its own parameter rather than utilising |embedded=, like the other designations use. Aesthetically it looks weird, long & bloat-y. ProcrastinatingReader (talk) 19:31, 12 October 2020 (UTC)

Considering this a bit deeper, I think I'd like to split up |embedded= into a separate |designation= as well. It will also allow us to see non-designation usages of the parameter more clearly, and identify what non-designations are being embedded (helpful to realise if there's anything we should add as core functionality). A bot run can detect designation usages and replace parameter names (there are active 'deprecation bots', and this would be in scope I think). Both |designation= and |embedded= would be supported. Regarding |nhrp=, it should be folded into |designation=. Functionally, I think we should drop support for {{Infobox NRHP}} embedding and simply encourage {{Infobox designation list}}. It handles the same designation functionality of the former, and we don't want any of the excess fields. Noting that most usages are in excess, and either duplicate information or add bloated information, I think a bot run to trim/replace with {{Infobox designation list}} would be appropriate. No valuable information is lost, of course. Mapping will be folded into {{Infobox station}}.

See User:ProcrastinatingReader/sandbox#Re_NRHP for a preliminary demo of what I mean (before/after). Location, coordinates, area should all go. The question remains on the labels "Architect", "Architectural style" and "Built". As you can see from Template:Infobox_designation_list#Embedding, the logic is to usually have these as part of the core infobox. They have little to do with the designation, and as such aren't natively supported by {{Infobox designation list}} either. ProcrastinatingReader (talk) 12:16, 13 October 2020 (UTC)

Okay, architect, architectural style are supported by this template (Template:Infobox_station#Construction), so they'll be retained in the infobox properly. All params bar the "(Land) Area" param, which fails MOS:INFOBOXPURPOSE anyway imo, are supported and info retained, and the mess of this cleaned up (I will add a |built= to join |rebuilt=). See User:ProcrastinatingReader/sandbox#Re_NRHP. Any opposition to me proceeding with this, as mentioned? ProcrastinatingReader (talk) 03:49, 17 October 2020 (UTC)

I haven't had time to look into this more thoroughly, but NRHP is not just a designation type - that is why it has it's own infobox. {{infobox NRHP}} handles may more cases than the few things listed in {{Infobox designation list}}, such as being a listed building within a historic district, a non-listed building (contributing property) withing a historic district, multiple designations (such as National Historic Landmark (maybe you are handling this)). I don't know if any of the transclusions of NRHP in stations use any of these parameters, but I don't see why a NRHP property that happens to be a train station should be limited and not just use the full NRHP infobox.

I don't know the history of why there is a |NRHP=, and changing that to the standard |embed= is just cosmetic. I agree that editors are often lazy and repeat info and maps that are in the main infobox. But that can be cleaned-up by normal editing. I always remove anything redundant when I find it. There are many thousands of NRHP infoboxes - most stand-alone, but many embedded in other infoboxes (e.g. {{infobox school}}, {{infobox lighthouse}}) and I'm not sure it makes sense to treat NRHP stations differently. I'd like to get more input from other NRHP folks. MB 04:22, 17 October 2020 (UTC)

MB, there's hundreds of these cases and nobody has cleaned them up. And the issue isn't just duplicating params (see my sandbox), it's usage of params we support in this template instead in the embed. It visually looks a mess. To quote our article: is the United States federal government's official list of districts, sites, buildings, structures and objects deemed worthy of preservation for their historical significance (similar to Listed building). The IB is most appropriately used as a infobox-proper on articles like Manzanar. The purpose of the IB for embedding here is the designation status. We can do this in a neater way, without losing data, whilst improving visuals and consistency, and removing repetition, all at the same time, so why shouldn't we? To add, my experience reading archives is generally that it's a mistake to think all template usage is intentional, much is just unmaintained templates. ProcrastinatingReader (talk) 16:21, 17 October 2020 (UTC)

Korean name

It's been sitting in the deprecation / slated for removal part of the doc for a while. Meanwhile, we're suggesting/recommending its usage in the very first example. So it's not really deprecated. Do we either want to move it out of the deprecation part, or do a bot run to convert the parameters on used articles under |mlanguage= (which seems to be the 'preferred' way of doing things. Visually no difference. I personally think converting to |mlanguage= is more logical, given also that's how Chinese names / other countries are currently doing it (see eg Kam Sheung Road station). ProcrastinatingReader (talk) 17:31, 12 October 2020 (UTC)

ProcrastinatingReader, I was just looking at Korean name because of the formatting issue at Gyulhyeon station. I'd worked up a change in my userpage (User:Mackensen/Infobox station) to suppress the header on the included child infobox and have Infobox station set its own. There's a similar formatting issue visible in your example. Mackensen (talk) 11:48, 14 October 2020 (UTC)

Mackensen, good catch. Yes, I think your fix resolves the issue for Korean stations. It won't fix the issue for Kam Sheung Road station though, since that uses {{Infobox Chinese/Chinese}}. Note also that both the Chinese and Korean templates are wrappers around {{Infobox Chinese/Header}} (which may help?) ProcrastinatingReader (talk) 12:46, 14 October 2020 (UTC)

ProcrastinatingReader, yes, for that I think we need an mlanguage_header parameter for infobox station, and then encourage a default usage of the child infoboxes that suppresses the header.

On your original question, I think it would make sense to formally deprecate the Korean parameters in favor of mlanguage, once the header is available and we have better documentation. Mackensen (talk) 13:00, 14 October 2020 (UTC)

Mackensen, hmm, we also don't want local articles to have to write |mlanguage_header=Korean name (or Chinese, etc) all the time. We could perhaps add that param with fallback automatic detection by checking the parameter value for "Infobox Korean name"/"Infobox Chinese name", etc, and giving a header based on that. But it's may be a little ugly (code-wise). We could also ask that template to add in a headerstyle param, and pass through our headerstyle (this duplicates code, but achieves the same effect), assuming they think it's appropriate to add that may fix our issue also. There may be other, better ideas. ProcrastinatingReader (talk) 13:10, 14 October 2020 (UTC)

ProcrastinatingReader, I looked into passing the header style, and I don't think it's a sustainable approach. You could have a default mlanguage_header of "Native name", with the Native part overridable. Mackensen (talk) 14:27, 14 October 2020 (UTC)

Mackensen, ah. Before throwing the towel in on the automatic part, I have an idea to simplify the 1st suggestion above. See Module:Sandbox/ProcrastinatingReader/ib. Basically, using a !regex capture group (the (%a*) part), whose value will be "Chinese", "Korean", etc., and just returning that part. If it exists, great, if not, default to "native name". It would be invoked with {{#invoke:Sandbox/ProcrastinatingReader/ib|nativeName|{{{mlanguage|}}}}}. At Kam Sheung Road station for example, the value of |mlanguage= is {{Infobox Chinese/Chinese|t=錦上路|s=锦上路|l=Brocade road|y=Gámséuhnglouh|j=Gam2soeng5lou6|p=Jǐnshànglù|showflag=y|}}. So it works in the debug console with that exact string value. Issue is, and I've ran into this once before, the template code is already parsed by the time it hits the module, so the module doesn't see "Infobox Chinese/Chinese", it sees the substitution of it. The result is my code returns "" rather than "Chinese".

I've ran into this issue once before with modules, it's a slight pain... Pinging Jackmcbarn, is there any way to get the pre-parse value of the parameter? Or another way to achieve what I'm trying to do? At the same time, this may be an XY problem -- surely there's an easier way to get an embedded child infobox to obey the header style of the parent infobox? ProcrastinatingReader (talk) 14:57, 14 October 2020 (UTC)

@ProcrastinatingReader: is there any way to get the pre-parse value of the parameter? No. I submitted a PR for this functionality once, and the Parsoid team rejected it, because it would make things too confusing for people who edit with VE. Or another way to achieve what I'm trying to do? Perhaps you could instead add a marker class to something in the output of {{Infobox Chinese/Chinese}}, and search for that marker class with Lua. Your other option is to have this module call {{Infobox Chinese/Chinese}} itself (by taking its name), instead of doing so within a parameter. Jackmcbarn (talk) 19:10, 14 October 2020 (UTC)

Jackmcbarn, re the other option, we don't actually know what language template is being embedded. This template just offers |mlanguage=. There's a lot of possible templates which can be used, even if we support this set natively if there's another set it'd break support for that (if there's not, yeah, we could do this too I guess). But, shouldn't {{Infobox}} provide better support for inheriting header styling when an infobox is being embedded? Or at least add a class or something so we can force it with TemplateStyles. Or some way to do this easier, without even having to consider what particular IB is being embedded? ProcrastinatingReader (talk) 19:22, 14 October 2020 (UTC)

Re the patch, was/is there an issue ID for it that we can comment on? I've a few other use cases that would benefit from something like this. Also seems like Parsoid team has changed, so might have better luck with it now? ProcrastinatingReader (talk) 19:25, 14 October 2020 (UTC)

@ProcrastinatingReader: No, there was never an issue about it, but you could make one and then link it to my old PR. As for my alternative idea, I didn't mean hardcoding a list; I meant doing something like {{Infobox station|template name=Infobox Chinese/Chinese}}, and then inside that, doing {{ {{{template name}}}}} to use it, and then also using the name for what you wanted to use it for. Jackmcbarn (talk) 22:58, 14 October 2020 (UTC)

Jackmcbarn think I'm juggling 3 ideas at once here, so to slow myself down... On the {{Infobox}} point, isn't the issue Mackensen describes really something {{Infobox}} should be providing support for (when embedding children), rather than us having to do a template-specific hack here? To make sure we're all on the same page, if I understood Mackensen correctly, we're talking about the styling applied to the header of the embedded infobox, matching that of the parent? So this is kinda something {{Infobox}} should be providing general support for, I'd think? ProcrastinatingReader (talk) 12:22, 16 October 2020 (UTC)

Possibly related Template_talk:Infobox/Archive_7#Child_parameter_inherits_styles?. If so, is this something technically difficult to implement, since the two infoboxes are parsed separately and probably have no knowledge of one another? ProcrastinatingReader (talk) 12:25, 16 October 2020 (UTC)

@ProcrastinatingReader: Inheriting can also be solved with the {{ {{{template name}}}}} trick. By making the parent call the child, instead of calling the child in the parameter, the parent can add whatever other parameters it wants to. Jackmcbarn (talk) 16:43, 16 October 2020 (UTC)

Jackmcbarn, admittedly I don't follow what you mean. For example, at Kam Sheung Road station, are you saying instead of the current |mlanguage= value there, we can do |mlanguage_template=Infobox Chinese/Chinese and add |mlanguage_t=, _l, _j, etc.? ProcrastinatingReader (talk) 16:46, 16 October 2020 (UTC)

Jackmcbarn, thoughts of User:ProcrastinatingReader/sandbox2? Implemented using Special:Diff/981456262/983879701. ProcrastinatingReader (talk) 19:57, 16 October 2020 (UTC)

Mapframe

Following the RfC I raise the matter of opt-in mapframes in this infobox. This was previously raised in 2018. Also pinging Evad37 for thoughts and implementation. ProcrastinatingReader (talk) 17:39, 3 September 2020 (UTC)

@ProcrastinatingReader: Implementation is relatively easy, see this diff to Template:Infobox station/sandbox2 (done there since /sandbox seems to be in use for the UK merge). Placement is a matter for local consensus per the RfC – I've put it at the bottom of /sandbox2 since that's where the location map is currently positioned. Documentation can be added just be transcluding {{Infobox mapframe/doc/parameters}} on the /doc page. - Evad37 [talk] 01:34, 5 September 2020 (UTC)

@Jts1882: in case you miss this. We discussed this recently, looks like there may be momentum now. As you observed, there are many minor stations that have no maps at all and this would be an instant bonus for minimum effort. --John Maynard Friedman (talk) 10:03, 5 September 2020 (UTC)

I think there is no reason not to include mapframe maps as an option, with the default as no (don't show). An issue to discuss is whether the default should be yes (show mapfrane map) if there is no other map. —  Jts1882 | talk  10:31, 5 September 2020 (UTC)

Best take it one step at a time to avoid getting no steps at all. It should be easy to get consensus to add mapframe, initially set to off. Making it default to 'on' will take a longer discussion while editors search for special cases. So I support addition of mapframe. --John Maynard Friedman (talk) 12:52, 5 September 2020 (UTC)

I don't believe local consensus is needed to add, due to the wider consensus in the RfC. Just needs local consensus on where to place it. I'd say logically where the current map is now, at the bottom, makes sense. ProcrastinatingReader (talk) 16:02, 5 September 2020 (UTC)

Yes, I agree (to both). --John Maynard Friedman (talk) 17:07, 5 September 2020 (UTC)

Implemented at the bottom, where the current map is. Parameters added to doc. With thanks to Evad37 for implementation. ProcrastinatingReader (talk) 11:47, 10 September 2020 (UTC)

Thanks for implementing this! Can we set the default marker to be "rail"? I have it set that way at Ossining station and Scarborough station. Can always be set to "bus" for bus stations, likely a small minority. ɱ (talk) 13:56, 12 September 2020 (UTC)

Hmm. My personal thoughts: it'd be okay to do that now, since they have to be manually added, but it would create a big barrier if we wanted to enable mapframes by default. And since they have to be manually enabled currently anyway, I don't see it being too helpful to do it in the template automatically vs just adding advice on this into the docs. If we had some kind of way to tell which is bus and which isn't it (eg |station_type=) this would work better. ProcrastinatingReader (talk) 16:24, 12 September 2020 (UTC)

As far as docs go, if we go the 'not setting defaults for all stations' route, I wonder if we can create some sensible defaults, without suggesting explicit usage of mapframe params. Like, if we had |mapframe_type= (value: railway, for ex), and this implements a set of sensible defaults for mapframes. Big advantage to this over suggesting individually recommended mapframe param values is (a) less params required, (b) more friendly for most editors, (c) we can adjust defaults in template easily if need be, vs having to use a bot which wouldn't be able to tell which are 'defaults' and which are intentionally set differently. Thoughts, and ideas on how to best technically achieve this, Evad37? ProcrastinatingReader (talk) 16:28, 12 September 2020 (UTC)

On detecting station type this could be done via Wikidata, e.g. looking for instance of (p31) bus station (Q494829), railway station (Q55488), underground railway station (Q55491), London underground station (Q14562709) or combination thereof. A simple template or module could provide the symbol to pass to mapframe. There might be a case for something more general to pick symbols for buildings, stadia and other locations. —  Jts1882 | talk  16:48, 12 September 2020 (UTC)

Unless this conversation develops more (which it seems it might not?), can we go with the default for rail (likely the vast majority of uses)? It always has the option to change it out for "bus" anyhow. Unless someone can commit to some Wikidata-based solution? ɱ (talk) 02:25, 23 September 2020 (UTC)

This code should automatically pick an appropriate symbol based on the Wikidata P31 value - Evad37 [talk] 03:03, 23 September 2020 (UTC)

OK, neat. How would I utilize that in an infobox? Is it automatic? I tried at Scarborough station (Metro-North), even previewed as the "/sandbox" template and the icon won't display for me. ɱ (talk) 11:01, 23 September 2020 (UTC)

You need to preview with the /sandbox2 template. And the page's wikidata item needs to have P31 set to one of the Q values duscussed above - Evad37 [talk] 12:07, 23 September 2020 (UTC)

Right, looks good, thanks. I'm in support of implementing this solution. ɱ (talk) 13:36, 23 September 2020 (UTC)

Can we do this? No problems with Evad's solution here? ɱ (talk) 22:00, 26 September 2020 (UTC)

Looks fine to me. We may want some kind of parameter so that local articles can override, if for some reason the Wikidata value isn't correct/desired. But I suppose manually supplying |mapframe-marker= would do that, and be prioritised by the module? ProcrastinatingReader (talk) 23:03, 26 September 2020 (UTC)

Yes, mapframe-marker can work for any instance of overriding the default marker. ɱ (talk) 23:08, 26 September 2020 (UTC)

Seems fine to me then. I think this is safe to implement, with seemingly a rough consensus in favour. ProcrastinatingReader (talk) 23:57, 26 September 2020 (UTC)

 Done - Evad37 [talk] 14:00, 1 October 2020 (UTC)

Evad37, I'm not sure it's working? Or I'm doing it wrong. See Union Station (Los Angeles) (which uses |map_locator= manually). Change to |mapframe=yes and no marker shows. On Wikidata it's an instance of railway station. I'm guessing it may be due to multiple values? ProcrastinatingReader (talk) 21:10, 2 October 2020 (UTC)

(←) yeah I tested it without 'tram stop' and it works. Evad might know a way to make it work without the removal... ɱ (talk) 21:20, 2 October 2020 (UTC)

The code only shows a default value when there is a single P31 value on wikidata. Not sure what you would expect to happen when there are multiple values, other than letting editors specify which (if any) marker icon to use via the parameter - Evad37 [talk] 05:22, 3 October 2020 (UTC)

Evad37, many times the second value in 'instance of' has nothing to do with what 'type' of railway it has (eg [3]). For multiple values, I think it should match the first in the current ordering of the switch template. ProcrastinatingReader (talk) 14:48, 3 October 2020 (UTC)

Agreed that if it can be set to match the first entry in 'instance of' that should work. Even if a station is used for two or more types of transit vehicles, the first should still be the predominant usage. ɱ (talk) 14:55, 3 October 2020 (UTC)

 Done - Evad37 [talk] 08:45, 5 October 2020 (UTC)

Evad37, by the way, is there an easy way to add the stuff in {{Infobox mapframe/doc/parameters}} to the TemplateData? Like a TD version that can be transcluded/kept in sync, or something. ProcrastinatingReader (talk) 19:29, 12 October 2020 (UTC)

I'm not sure if it as actually possible to transclude bits and pieces within a templatedata block, could be something interesting to try. It's possible to keep a copy of the TD for the mapframe parameters for easy copy-paste, much like the parameters list for the Check for unknown parameters. But there's no shortcuts just yet, because for with way it would need to be set up manually initially. - Evad37 [talk] 22:33, 12 October 2020 (UTC)

Evad37, copy and paste works fine, too, if that's the best method. Is there one set up somewhere already, to paste from? ProcrastinatingReader (talk) 22:57, 12 October 2020 (UTC)

Not yet, as far as I am aware - Evad37 [talk] 00:20, 13 October 2020 (UTC)

@ProcrastinatingReader: Now done at Template:Infobox mapframe/doc/templatedata - Evad37 [talk] 01:28, 14 October 2020 (UTC)

Evad37, thanks Evad. I added it to doc. Longer term, I do slightly wonder if it can be embedded in some way, to keep them in sync. Not sure if template transclusion works in the templatedata block, but if not, I presume modules can still do something here (as I guess {{Documentation}} is doing), maybe with something slightly fancier to handle trailing commas (JSON syntax). ProcrastinatingReader (talk) 17:11, 19 October 2020 (UTC)