This is an archive of past discussions about Template:Infobox station. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)
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)
@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)
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, 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)
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)
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.
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)
@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)
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)
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
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your 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)
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)
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)
@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
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)
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)
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? MB05:22, 27 April 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)
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)
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⋉talk22:55, 28 September 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 HornUser talk18: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 HornUser talk23: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). SounderBruce04:09, 31 January 2020 (UTC)
Center the name when logo is added
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)
@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)
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)
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)
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)
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)
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.
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)
@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)
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)
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)
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)
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)
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)
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.
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. MB19: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)
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. MB04: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, 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)
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)
@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)
@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 | talk10: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)
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 | talk16: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)
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)
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)
(←) 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)
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, 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)
_pg123_PENNSYLVANIA_RAILROAD,_JERSEY-CITY_STATION.jpg)
