Template talk:Infobox station/Archive 5
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. |
Archive 1 | ← | Archive 3 | Archive 4 | Archive 5 |
Station use statistics
There has been some disagreement as to whether just boardings or boardings + interchanges should be included in railway station infoboxes. There was a discussion in 2018, but it didn't really come to a consensus. For mine Boardings only is sufficent. Colwest (talk) 21:02, 27 November 2022 (UTC)
Borough parameter
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. SounderBruce 03:37, 9 December 2022 (UTC)
Edit request 19 January 2023
This edit request to Template:Infobox station/doc has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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": | + | },
"train_operators": { "type": "string", "required": false, "label": "Train operators", "description": "List of train operating companies (TOCs) that serve the station. Use <div class="plainlist " >" |
Epluribusunumyall (talk) 03:30, 19 January 2023 (UTC)
- I believe this change can be made to Template:Infobox station/doc which is not protected — Martin (MSGJ · talk) 15:24, 19 January 2023 (UTC)
- Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details. – Jonesey95 (talk) 15:29, 19 January 2023 (UTC)
Pre-grouping, Post-grouping and Pre-nationalisation
Pre-grouping, Post-grouping, Pre-nationalization has no specific details at Template:Infobox station/doc, What does it mean? - Jjpachano (talk)
- 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)
- Template:Infobox station/doc isn't protected. Mackensen (talk) 12:26, 25 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)
Time expired
Purnia Junction railway station is showing "The time allocated for running scripts has expired." This template (Template:Infobox station) seems to be taking a lot of time on that page. I have not investigated whether the problem is due to the article or the template and am hoping that someone familiar with the template can check. Johnuniq (talk) 08:15, 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)
- Thanks for fixing the article. Johnuniq (talk) 00:18, 26 January 2023 (UTC)
Indian Railways style
The "style=Indian Railways" forces the station name into all-caps. It looks horrible and violates WP:ALLCAPS. This poor styling should be fixed. See for example: Netaji Subhas Chandra Bose Gomoh railway station. Skyerise (talk) 14:56, 12 March 2023 (UTC)
- @Skyerise the formatting is set in Module:Adjacent stations/Indian Railways. Mackensen (talk) 15:23, 12 March 2023 (UTC)
Accessible=
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)
- All fair points. I think accessibility in the context of railway stations, at least in the United States, tends to focus on physical accessibility. See for example MBTA accessibility or Accessibility of the Metropolitan Transportation Authority. Plenty of stations here are physically inaccessible. Mackensen (talk) 23:33, 7 March 2023 (UTC)
Perhaps we should change the display field (not the parameter itself) to "Accessibility", and then use the File:MUTCD D9-6.svg for the default of "Yes"/physical accesibility (maybe something like |accessible=y
), File:No Accessibility - Original Handicapped Symbol.svg for no physical accessibility (|accessible=no
), and File:Blind (CoreUI Icons v1.0.0).svg for blind people, etc. A lot of stations in the US have tactile paving but lack elevators, for example, and can maybe be |accessible=no,blind
, or could be a separate template. This dovetails a bit with my earlier comments as well. – John M Wolfson (talk • contribs) 11:57, 9 March 2023 (UTC)
- @John Maynard Friedman and Mackensen: I have created the template {{Accessibility}} for such symbols and have tested them out at Damen station (CTA Blue Line) and Western station (CTA Blue Line O'Hare branch). You are free and encouraged to leave feedback and tweak things as necessary! – John M Wolfson (talk • contribs) 12:49, 9 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)
- That's my plan in principle, perhaps better template coders can make such things possible. – John M Wolfson (talk • contribs) 14:19, 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)
- Agreed. ɱ (talk) 16:07, 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)
- That's my plan in principle, perhaps better template coders can make such things possible. – John M Wolfson (talk • contribs) 14:19, 9 March 2023 (UTC)
Issue of word useage
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.
- Support changing the parameter name to
|accessible=
, and the public display to "Accessible". Turini2 (talk) 21:30, 2 March 2023 (UTC)- As an example, Template:Infobox London station has the parameter to
|access=
, which displays as "Accessible" Yes/No. Example at Westminster tube station. - There's also a
|accessnote=
field which allows for a "description if there is not complete access" Turini2 (talk) 21:34, 2 March 2023 (UTC)- Seems like a reasonable way to deal with the issue. oknazevad (talk) 23:14, 2 March 2023 (UTC)
- As an example, Template:Infobox London station has the parameter to
Changes visible at Template:Infobox station/sandbox and Template:Infobox station/testcases. I've added |ADA=
and |disabled=
to the deprecation list. Mackensen (talk) 21:20, 5 March 2023 (UTC)
- 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)
- I think JMF's thread below has some ideas I would like to address. – John M Wolfson (talk • contribs) 11:57, 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".
- (as a sidenote, I change the term handicapped wherever I find it in transit articles e.g Grove Street station (PATH)- unfortunately some people think it's still an acceptable term to use!) Turini2 (talk) 08:33, 1 April 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)
Edit request 17 April 2023
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)
"Collapsible" feature not working
For the "other_services_collapsible" feature, the show/hide button is not displaying. (Example: Silver Spring station (Maryland) .) Can someone fix this? Thanks. Moreau1 (talk) 20:09, 27 April 2023 (UTC)
- Works for me, but the show link is blue on
blackvery dark grey (#241F20;
), so is not very easy to see. --Redrose64 🌹 (talk) 20:30, 27 April 2023 (UTC)- I can confirm it works for me as well. I am looking on desktop fwiw. Trainsandotherthings (talk) 20:44, 27 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 to Module:Infobox/styles.css. --Redrose64 🌹 (talk) 22:54, 27 April 2023 (UTC)
.infobox button.mw-collapsible-toggle { background-color: #efefef; }
- Agreed, but why was the text set to a default color in the first place? It should match the other headers. Cards84664 17:35, 29 April 2023 (UTC)
- I think that we can fix this for all stations by adding this CSS rule
- 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)
- Related: Template talk:Navbox#Colour accessibility of show/hide when using non-default background colour and Wikipedia:Village pump (technical)#I need help! --Redrose64 🌹 (talk) 17:16, 28 April 2023 (UTC)
'Symbol' parameter
What about adding an option for 'symbol' parameter to use data from Module:Adjacent stations, cause it seems like much more rail systems are covered by the module rather than the {{Rail-interchange}} subpages? — Antoni12345 (talk) 11:48, 25 May 2023 (UTC)
- 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.
I made some changes to check out in the sandbox, Any thoughts? Bluealbion (talk) 12:12, 2 July 2023 (UTC)
- 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've notified the relevant WikiProjects. {{Infobox London station}}, a separate template, already does this. Mackensen (talk) 13:58, 2 July 2023 (UTC)
- Links to examples please? Thanks. 10mmsocket (talk) 14:11, 2 July 2023 (UTC)
- Fully support. Looks much better. 10mmsocket (talk) 14:28, 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)
- The testcase for 40th Street station (Market–Frankford Line) looks absolutely abysmal. ɱ (talk) 15:12, 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 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)