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.
Shouldn't |city = be added as a secondary name for the existing borough parameter? The vast majority of places in the U.S. and Canada are organized by city or municipality rather than borough. SounderBruce03:37, 9 December 2022 (UTC)
Updating the type of input for the value "train_operators" in the infobox:
I am proposing an update to the type of input asked for the "train_operators" value in this infobox. Currently, "wiki-template-name" is required, yet the description also asks for users to use {{plainlist}} as often there is more than 1 train operator as a single station. I, therefore, believe that the "string" type of input should be used, similar to what is used for the "lines" value where users are also asked to use {{plainlist}} as there can be more than 1 lines feeding into a singular station.
Diff:
−
},
"train_operators": {
"type": "wiki-template-name",
"required": false,
"label": "Train operators",
"description": "List of train operating companies (TOCs) that serve the station. Use <div class="plainlist " >"
+
},
"train_operators": {
"type": "string",
"required": false,
"label": "Train operators",
"description": "List of train operating companies (TOCs) that serve the station. Use <div class="plainlist " >"
These are all UK-specific, and refer to the Big Four (British railway companies) and then the subsequent nationalization at the end of 1947. See the template at the top of this page, which shows that several UK-specific station infoboxes were merged into this one. It would be a good idea to add some documentation of this into the template, but I certainly don't have the permissions to do so. Trainsandotherthings (talk) 17:59, 22 January 2023 (UTC)
Ah, you've exposed my lack of familiarity with how infoboxes operate. I'm not sure I fully understand how to document those parameters as I essentially never edit British topics, so I'm going to drop a line at UK Railways. Trainsandotherthings (talk) 14:27, 25 January 2023 (UTC)
Not really anything to do with the template: [1]. Someone placed a different template (a routemap) within the infobox, not associated with a parameter. I'm guessing one of the infobox parameter checking scripts tried to process the template as though it were a parameter. Mackensen(talk)12:24, 25 January 2023 (UTC)
Could we have a couple of examples? How about these that I've just added to MKC and WOL respectively. Some LU stations have level access to trains so I've speculated on how to write that:
| accessible = Lifts to platforms, step up to trains
| accessible = No (steps to platforms, step up to trains)
| accessible = Lifts to platforms, step-free access to trains
And what about audio guidance for sight-impaired passengers? [Choosing the right platform; more than 30 seconds notice that the train is about to arrive.] Train movement displays for hearing impaired? ["next train time" displays are common but what about "the next train at platform 4 does not stop here, please stand back behind the yellow lines"] 𝕁𝕄𝔽 (talk) 19:06, 7 March 2023 (UTC)
Well, it's just a rename of long-standing existing parameter (see #Issue of word useage above). Typical usage up until now has been yes/no, with further discussion in the text as appropriate. I'm not sure how detailed you want to get in an infobox. Mackensen(talk)20:59, 7 March 2023 (UTC)
Aargh! I've just worked out what ADA means. Centre of the universe time again.
Yes, I agree that the detail belongs in the body and that the infobox should be a concise summary. I just thought that there should be some guidance in the documentation.
I don't see how yes/no is really helpful to anyone. Accessible to whom? how? where? when? which disabilities? Most people with a disability don't use a wheelchair. So it seems to me that it would be useful to show which enabling facilities are provided. --𝕁𝕄𝔽 (talk) 22:58, 7 March 2023 (UTC)
@John Maynard Friedman I'm not sure if using symbols is that accessible - given screen readers etc. I personally feel that leaving the accessible field to mean "physical accessibility" is best, and is common across transit / railway agencies and bodies.
Furthermore - finding out whether a station/stop has a lift, ramp etc can usually be verified with a good quality source, trying to verify further details (does the station/stop have a Hearing loop, does it have tactile paving, is there a Help Point etc) is probably very difficult / hard to verify without Wikipedia:OR)
Finally - people shouldn't be using wikipedia as a travel or accessibility guide - that's the job of the transit / railway agencies and bodies! Turini2 (talk) 08:23, 1 April 2023 (UTC)
[covenient edit conflict]
I agree with the principle if the icons are accessible to visitors with visual impairment, to minimise infobox clutter.
Perhaps we might aim to use the {{accessibility}} as a subtemplate so we get |accessible={{accessibility}} where {{Accessibility}} is developed to support more arguments (like |level=yes/no/part |audio=yes/no/part| visual=yes/no/part etc?). Meanwhile maybe we just have to say "see below"? --𝕁𝕄𝔽 (talk) 13:09, 9 March 2023 (UTC)
I suggest we start with what you have done and develop from there rather than wait for perfection. People with sight and hearing impairment can generally manage with assistance: mobility-impaired passengers (especially wheel-chair users) can't deal with stairs or escalators. Most metro maps (such as this one, London Underground) show the wheelchair symbol. --𝕁𝕄𝔽 (talk) 14:30, 9 March 2023 (UTC)
Hi, I have been using ADA within the script for a while now, creating railway stations in Greece; however, I have been informed I need to replace them with Disabled... I have issue with this, as while disabled is not a loaded term or indeed derogatory (in of itself), it is, in my view, the wrong usage here. First, the implication that only disabled people need this is incorrect, as station facilities are there for everyone. Moreover, the script can not be read for some literacy support software, so those visually impaired are not included in this description. I understand the D in ADA stands for disabled, and the term appears in the infobox; however, the more I edit and code, the more I have concluded it's just not an appropriate term. As a disabled person myself, we can do better, I feel... and to be more inclusive, maybe a word like facilities or station amenities would work better? This is not an attack on anyone, just a helpful request at changing part of the code in Template:Infobox station. Thank you --✠ Emperor of Byzantium ✠(talk)21:45, 22 February 2023 (UTC)
You make valid points. How about changing the parameter name to |accessible=, and the public display to "Accessible"? I think that term is well-understood now. Mackensen(talk)01:12, 23 February 2023 (UTC)
Agreed! Making a station accessible doesn't just help disabled people, it also helps older people, people with small children or heavy luggage. Accessible would also be more inclusive.
I just noticed these changes and felt the need to object to them. While almost everybody knows what "accessible" means in this context, I feel that not quite everyone knows the term and its association with the disabled. I think the previous "Disabled access" works perfectly for this, and would personally rather it be restored. (Yes, "accessible" does mean accessible to everybody, but every station is accessible to the fit and able-bodied unless otherwise stated.) If there's enough objections to the old wording, perhaps the International Symbol of Access can be used instead, maybe in a header or footer.FWIW, I do agree that "ADA" is suboptimal if only due to Americentrism, but I think |disabled= should remain supported indefinitely, regardless of the wording in the final product and even if deprecated/not preferred. – John M Wolfson (talk • contribs) 21:57, 8 March 2023 (UTC)
Disabled access redirects to accessibility, and has since 2007. Government reports that track this issue tend to talk about accessibility and not disabled access. {{Infobox London station}} has used Accessible as the public-facing text since 2009. I understand your objection, but I think it makes sense to go with more inclusive wording here. Mackensen(talk)02:27, 9 March 2023 (UTC)
The other reason I pushed for this change - is that accessible stations don't just benefit the disabled, they benefit society as a whole (older people, people with heavy luggage, people with small children / Pushchairs etc). Hence some agencies use the term "step free access" - as in, universal design that ensures things can be used by the maximum number of people possible.
Accessibility is a much more inclusive term than "disabled access".
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Description of suggested change:
Because the country entry for almost *all* stations is already available in their wd entities, I just sourced it to pass it with coord as |region: . REEDriler (talk) 13:15, 17 April 2023 (UTC)
You're right, thanks. The link is there, but quite hard to see. I amend my request: Can someone change the link color, please? Moreau1 (talk)
I see no reason to modify the infobox template when the default color scheme presents no issues; it is only because Silver Spring station has been given this black color in the infobox that the link is hard to see. Consider Union Station (New Haven) for example - the link is very easy to see on the default color scheme. Trainsandotherthings (talk) 20:47, 27 April 2023 (UTC)
I think that we can fix this for all stations by adding this CSS rule
In many cases Rail-interchange already uses data from Adjacent stations; that's less disruptive than trying to cut over the thousands of existing templates to use it directly, I think. Mackensen(talk)11:59, 25 May 2023 (UTC)
Move map
I am proposing that we move the generated map to the top of the infobox under the first image, like in many other location based infoboxes. I think this will create internal consistency in our infoboxes, will be better for inboxes without photos yet, and is more useful information to include higher up than hidden at the bottom.
Interesting. I have no objection, the test cases look fine, though you'll want more input for such a visible change. Mackensen(talk)13:31, 2 July 2023 (UTC)
I don't like this. There are other infoboxes that place them at the bottom. It balances out the infobox much better. And for articles with large headings, like Chicago Union Station and Grand Central Terminal, it would completely obscure a lot of the basic facts up-front, forcing many readers to scroll to read parameter text. And it would look terrible among the header and image/montage there. ɱ(talk)15:10, 2 July 2023 (UTC)
Also, route maps are at the bottom. It makes sense for the geographic map to be placed alongside. ɱ(talk)15:13, 2 July 2023 (UTC)
Strong oppose. The purpose of the infobox is to make the most important information easy to find at the top of the page. Putting the map near the top of the infobox pushes all the other information down in favor of location - which is already at the top of the page with the minimap link! For a typical infobox with a 4x3 image, that means you'll have to scroll to reach any of it. Per Ɱ, the bottom next to the adjacent stations is the natural map location for station infoboxes. Pi.1415926535 (talk) 19:09, 2 July 2023 (UTC)
I guess it is somewhat subjective as to which one looks better, but I was thinking that the address and Coordinate information is at the top of the infobox, so it would be more naturally to include it at the top. Visual information about its location is still information, and I would argue more important to the average reader than some of information of the infobox. Bluealbion (talk) 04:06, 3 July 2023 (UTC)
Route maps are located at the bottom, in addition to "services" which effectively is a route map as well. The image map belongs with the other maps more than a map belongs with an address. ɱ(talk)15:44, 3 July 2023 (UTC)
I am testing the use of this infobox for major tram stations/stops and bus interchanges. I have added |number for station number (not code), |tram_routes and |tram_operators for display of both bus and tram routes/operators. Example as on the right:
Using the Tram routes and Tram operators parameters will now trigger the using unknown parameter warning. How can that be fixed? Purin128AL (talk) 18:12, 22 July 2023 (UTC)
.svg){kind=link}