Template talk:Infobox station/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Discussion

Initial thoughts:

1. Looks good. Very good work.
2. Is this going to be used on LRT station articles? Some of those "stations" are in street running segments; should the platform parameter be adjusted, another optional parameter added, or can it just be reflected as is?
3. Is the plan to supplant existing infoboxes for Amtrak or NYC Subway stations?
   1. Will this handle shared stations (like Trenton) gracefully?
   2. Can it handle NYCS edge cases successfully? (think Times Square or the future Fulton Street Transit Center)
4. Still looks good. Thanks, Mackensen! —CComMack (t–c) 02:46, 8 January 2007 (UTC)

Thanks for the input! Some responses follow. It's my intention, as with s-rail/s-line, to gradually supplant existing unique infoboxes. It ought to be possible to design a single infobox flexible enough to meet all reasonable needs. As this is derived in the main from the Amtrak box, it should be easy to replace the one with the other. I don't see why Trenton or other shared railway stations would be a problem, unless you're worried about indicating somewhere whose station it actually is, and whose lines therefore go in the line parameter. It might make sense to include all lines for which there are succession boxes, or which are heavy rail, and then reserving the other field for bus service. I'm not sure what you mean an "NYCS edge case." Finally, I don't see a problem using this for LRT stations, provided we have articles on them (platform=Street-level). Mackensen (talk) 04:33, 8 January 2007 (UTC)

Thanks for the fast response! Everything looks OK now except the adaptation to complicated NYC Subway articles. If you look at Times Square–42nd Street (New York City Subway) (the most complicated station in the hemisphere), you'll notice that, while the station complex (rightly) only has one article, there is a section header for each individual station within, each with its own infobox reflecting the individual history and structure of that station. This is a good system, and I think it should be kept, and I doubt that WP:NYCPT would appreciate it if it were changed without discussion at their talk page. So until then, and possibly overall, I would like to request that New York City Subway station articles keep their current infoboxen. —CComMack (t–c) 07:07, 8 January 2007 (UTC)

In situations like that, then yes, we certainly can't meet their needs. Mackensen (talk) 11:37, 8 January 2007 (UTC)

One obvious target are articles with hand-coded templates (CTA is one such series). Mackensen (talk) 16:28, 8 January 2007 (UTC)

Okay, I've updated Trenton Rail Station (New Jersey) with an example of combining lines. Thoughts? Mackensen (talk) 16:49, 8 January 2007 (UTC)

Fare zone parameter

I had a thought, and ran with it. The template now includes a parameter for noting a station's current fare zone, for those systems with zone-based fares like SEPTA, NJT, and Caltrain. —CComMack (t–c) 07:17, 8 January 2007 (UTC)

Services

Services allows inclusion of the s-rail/s-line boxes within the template as an alternative. Just leave s-start and end off. Mackensen (talk) 21:11, 22 February 2007 (UTC)

Two logos in the same infobox

I've improved articles for BART, Muni Metro, DART and MBTA so far. Now I'm looking to include transit authority logos which I am doing right now, but I have a problem. I'm trying to put two logos in the same infobox for each station on the same line. I kind of messed up on this (examples: Richmond Station (California) and Oakland Coliseum Amtrak/BART Station), so any help on how to do this and do it right would be much appreciated. For example: if a station was served by BART and Muni Metro in San Francisco. Cheers. GETONERD84 16:01, 1 April 2007 (UTC)

• Well, one way to do it would be to change the logo handling so that the full image code is specified, not just the name. The downside is that this will break every instance currently using the logo parameter. Mackensen (talk) 20:54, 1 April 2007 (UTC)
  • It looks like this may have happened. The logo is not showing on any of the BART station pages. Example: Dublin/Pleasanton Tuyvan 04:54, 14 April 2007 (UTC)

• So what exactly is the fair use rationale for putting those fair use logos on these station articles? If they do not really identify the subject of an article, or specifically illustrate relevant points or sections within the text, how do they contribute significantly? Zzyzx11 (Talk) 04:09, 11 April 2007 (UTC)
  • I suspect there's an issue there that's insurmountable in most cases. I modeled the handling off the German infoboxes, but they've got "free" images denoting U-Bahn and S-Bahn connections. Mackensen (talk) 11:13, 11 April 2007 (UTC)
    • So, are you classifying these images as part of a wayfinding system? Zzyzx11 (Talk) 03:44, 12 April 2007 (UTC)
  • I don't understand how the image logo field in this template was itself a fair use violation. It was the use of copyrighted logos in the field that you say is the problem--so why didn't you take up the issue with the editors of the systems using the logos? Alterting the template didn't alert any of the users of the infoboxes that there was a concern and need for discussion. I only by chance noticed that the MARTA logos had disappeared from the station pages and like Tuyvan above thought the template was improperly edited. Anyway I myself don't know for sure if this is a fair use violation or not, so I welcome discussion and also am interested to know if wayfinding applies to this particular situation. Biomedeng 02:15, 16 April 2007 (UTC)

Passengers

I've modified the passenger handling so that it's possible to show multiple years and/or multiple systems. An example of this functionality is at Kalamazoo Transportation Center. The old method still works fine. Mackensen (talk) 14:36, 4 April 2007 (UTC)

• Is it possible to selectively exclude or disable pass_percent? Tuyvan 04:42, 15 April 2007 (UTC)
  • Not at the moment. If the passenger total is set, it will expect the pass_percent parameter. Mackensen (talk) 14:17, 15 April 2007 (UTC)

Riding low?

Does anyone know why the current version of this template box is causing the articles it is included in to ride several lines too low? Example: Dupont Circle (Washington Metro). SchuminWeb (Talk) 15:57, 4 April 2007 (UTC)

• Hmph. I think I've seen that before. Let me play with it in my userspace for a second. Mackensen (talk) 15:58, 4 April 2007 (UTC)
• Okay, I think I fixed it. You might need to clear your cache. Mackensen (talk) 16:05, 4 April 2007 (UTC)

Looks good! Thanks. SchuminWeb (Talk) 21:53, 4 April 2007 (UTC)

Schematic line templates in "services" section

I would like to add schematic rail line templates (ex: {{SEPTA Market-Frankford Line}}, {{PATCO Speedline}} ) into the "services" section in place of {{s-line}}, but when I do so, the template shows up with borders and looks really unattractive. How can I implement one of those templates into this one, so it does not have borders and looks organized? –Crashintome4196 19:50, 12 April 2007 (UTC)

• By and large the use of those templates on articles concerning individual stations is discouraged. For my own part I think it adds unnecessary clutter to an article and such templates belong on the article about the line itself. Mackensen (talk) 19:55, 12 April 2007 (UTC)

I'm planning on making the schematic templates collapsible before I implement them into this template. –Crashintome4196 00:44, 13 April 2007 (UTC)

If you're going to pursue these kinds of templates you might want to have a look at what the WP:TRAIL people are up to. In any event, a schematic template describes a line, but we're talking about a template that describes a station. S-line describes the location of a station within a line and integrates well with other templates without taking up inordinate amounts of space. Mackensen (talk) 01:34, 13 April 2007 (UTC)

Symbol of Access

Wikipedia's new "more free" symbol.

I feel that Wikipedia's new "more free" replacement wheelchair accessible symbol is HORRIBLE, its way too small for our purposes, and it isn't the standard symbol in the transit industry, the industry this infobox was designed for. As a matter of fact, this is not the symbol for any purpose worldwide. The International Symbol of Access is. This symbol is copyrighted solely to prevent misuse, not for profit, therefore since we are using it the way in which it was intended to be used, in this case to show that the station is indeed accessible to those with disabilities, and seeing this project (Wikipedia) is working towards the common good of all, I believe we are well within the spirit of the copyright. I am following my right as a Wikipedian to be bold WP:BOLD and I am fixing what I feel is a really bad mistake. RickyCourtney 01:10, 3 May 2007 (UTC)

Violates policy, no can do. -- Ned Scott 01:48, 3 May 2007 (UTC)

As someone who has been watching the debate unfold at the Village Pump, I am surpised that Ned you wouldn't point this user to the active disscussion. In fact it appears that this issue is far from resolved and that now a request for arbitration has been made. So it is fine with me if you want to remove the image from the infobox until this issue is resolved. But your statement "violates policy, no can do" is misleading since it failed to let the editors of this template know that there is currently a disagreement whether or not the use of this image in the rail station infobox is acceptable on wikipedia. I however do object with your use of because it appears to be a derrivative work of the ISA official image, and therefore does represent copyright infringement. Perhaps we should simply replace the ADA image in the template with the words handicapped accessible. Biomedeng 02:36, 3 May 2007 (UTC)

You are mistaken, this currently violates policy, and the editors who wish to use the image are asking for a change in policy to allow the use. Until such a change is made it does, in fact, violate policy. The only reason I didn't point him to the VP discussion was that I thought he already knew about it, given the timing of the template change with the discussion. But hey, thanks for assuming the worst of me. -- Ned Scott 03:05, 3 May 2007 (UTC)

I never disagreed with your assessment that the use of the official ISA image violates policy, so how am I mistaken? Anyway I just wanted to point out that if you are going to revert the ISA image back to the so called free derivative image then I think you should point the users to the active discussion(s) on the issue so that they can understand why you feel it violates policy. Usually when people revert something they specify which policy is violated, not just a "no can do." I think if you better explain your reasoning then you maybe could prevent an ugly edit war. I am not assuming the worst of you--sorry that you misunderstood. I do agree with you that current policy prevents the use of the official ISA image; I think maybe where we disagree is that I think we should ammend the current policy. This is why I said it was fine with me if you wanted to remove the image from the infobox until the debate is resolved. Biomedeng 03:35, 3 May 2007 (UTC)

Thank you, I had no idea of the discussion at the village pump. I appreciate the heads-up Biomedeng. I will certainly make my opinion voiced there. Im sorry that I took this as the first venue to do so, but I really feel like this new symbol was forced upon us... and I also feel that that it was not correct. RickyCourtney 03:59, 3 May 2007 (UTC)

I also must apologies, I shouldn't have just assumed you already knew about the debate based on the timing of events. I would have defiantly approached this differently had I realized you did not know about the existing debate. -- Ned Scott 03:38, 8 May 2007 (UTC)

International usage

I'm working on adding parameters for using the template for stations outside of the US (specifically Australia, which doesn't even have a uniform station template and this is the best one out there). What are your ideas on this? Geoking66 21:29, 12 May 2007 (UTC)

• Well, I suppose we'd need to see examples of the infoboxes/tables already in use on Australian articles. What needs are not presently met? Mackensen (talk) 22:00, 12 May 2007 (UTC)

Customization

User:Mackensen/Infobox Station Is it possible to customize, at least, the top of the infobox by system? At Wikipedia talk:WikiProject New York City Public Transportation#Template:Infobox Station, I want to standardize the commuter rail infoboxes, but I also hope to retain some uniqueness for individual transit systems. For example, I would like to keep the top portion of Template:Infobox LIRR while using this template. Tinlinkin 08:21, 16 May 2007 (UTC)

• That depends on how much customization we're talking about. I played with having customized heading colors a while back but never committed the changes. What needs aren't being met at present? Mackensen (talk) 10:47, 16 May 2007 (UTC)

I mean to use this infobox but to have a distinctive style for a transit system, via parameter "type" or another one, if it is appropriate. If you see Babylon (LIRR station), I hope to transfer the heading style (the "Babylon" station name and the blue bar above without the accessibility icon) to this infobox, but only enact it on LIRR articles. In other words, I want to override the default "name" style in certain conditions. Tinlinkin 11:05, 16 May 2007 (UTC)

Interesting idea. I've a notion about how to implement it–let me play around in my userspace. We should definitely tie in the type codes with what's in Template:S-rail/lines. Mackensen (talk) 11:18, 16 May 2007 (UTC)

I've pasted an example at right of what this might look like. The style definition is in {{Amtrak style}}. 12:33, 16 May 2007 (UTC)

I wasn't thinking about the colors, but OK. Wow. Your plan just might work. Would you be bold enough to apply the changes?

On a separate issue, I don't see "type" being used in a lot of station articles. Could it be because the appearance of "System station" on top looks unattractive? (This is my theory; I don't know if this is the case.) Tinlinkin 13:12, 16 May 2007 (UTC)

Well, part of that is that "type" was just (about a day ago) added as a parameter. I think this could be added as another parameter to the style template (e.g. "show_type"). Mackensen (talk) 13:50, 16 May 2007 (UTC)

That explains it. Lots of changes recently. :) Tinlinkin 14:11, 16 May 2007 (UTC)

Okay, new change. The style template now supports the "display_as" parameter. Mackensen (talk) 14:22, 16 May 2007 (UTC)

No problem. Tinlinkin 14:26, 16 May 2007 (UTC)

Okay, now that we've established the idea and capability of modifying the appearance of the template without changing the structure, what else should be changed? Mackensen (talk) 14:28, 16 May 2007 (UTC)

I have no other suggestions for now. I will continue to tend to Template:Infobox NYCS. I commented that that template seems to be given a free ride for the time being. Tinlinkin 14:31, 16 May 2007 (UTC)

I took initiative and added a "type" parameter to the top of the infobox, similar to what is shown on {{Infobox NYCS}}. It was altered by Mackensen, now I'm totally confused about how it works, even after reading the code. Before, you simply typed in a link to the system article and the rail type article, but now it doesn't work that way at all. For example, all SEPTA articles display "SEPTA rapid transit station" even though SEPTA operates rapid transit, light rail, and regional rail systems. I'd like to understand the usage for this parameter, otherwise I'll revert the template to the changes I recently made. –Crashintome4196 18:42, 16 May 2007 (UTC)

A couple points. First, there's a good argument to be made that rapid transit includes light rail and regional rail, but that's beside the point. The idea of "type" was extended to permit formatting changes to the infobox itself and now relies on a separate template, {{{{{SYSTEM NAME}}} style}} (e.g. {{Amtrak style}} or {{SEPTA style}}). Type should take the standard parameter for a system, as defined in S-rail. Now, what I'm going to add in just a minute is a second parameter, so that there can be variation within a system (probably type2). Mackensen (talk) 18:52, 16 May 2007 (UTC)

I think that is getting too complicated. There's no reason that another template should have to be made to go inside the template. I don't see what was wrong with the simple way it was previously done. –Crashintome4196 20:21, 17 May 2007 (UTC)

It's not a question of right and wrong but rather a question of what we're getting out of the feature. The gentleman above came asking for the ability to customize appearance based on type, about a day after typing was added to the template. It made perfect sense to me to extend existing functionality; the alternative would be duplicate type functions in one template, which wouldn't be a good implementation. It's also a situation where you can design once, then use repeatedly, much as it was with s-rail/s-line. Mackensen (talk) 20:32, 17 May 2007 (UTC)

To reiterate, my primary concern is to avoid duplicate functionality. Now, we could rename type and type2 to style and style2, and restore type to its original functionality. Mackensen (talk) 20:39, 17 May 2007 (UTC)

"type" was originally supposed to designate and provide a wikilink to a transit operator, is that correct? If a style implementation is not defined for a transit operator, "type" should not be affected. A different parameter should co-exist. I don't know why I didn't think of this issue before. I support reverting to the original functionality of "type" and the "style" parameter is what should be used to link any style information, and should be optional and independent of "type". (Unlike Infobox NYCS, I have yet to learn all the intricacies of this template, let alone implementing style info, even though that looks like it will be easy. So I don't intend to mislead either of you with my comments, as if I am throwing a curveball at you.) Tinlinkin 10:56, 18 May 2007 (UTC)

Not your fault; I got ahead of myself. I made the changes last night. Mackensen (talk) 11:12, 18 May 2007 (UTC)

Is there a way to implement the style templates without requiring all the parameters to be specified? If not, it is not a problem. Tinlinkin 08:47, 22 May 2007 (UTC)

That is, if empty, use the default? It ought to do that anyway. I'll take a look. Mackensen (talk) 11:00, 22 May 2007 (UTC)

Infobox class

The "infobox" css breaks the formatting of included s-rail templates, so it shouldn't be used in this template. Mackensen (talk) 20:14, 10 January 2008 (UTC)

Do you have an example? —Ms2ger (talk) 12:41, 13 January 2008 (UTC)

Any station article which uses the "services" parameter, and therefore includes the {{s-rail}} parameters will display improperly. I'd just as soon not re-break all the articles to demonstrate. Mackensen (talk) 15:59, 13 January 2008 (UTC)

With "breaks the formatting", I suppose you mean that the text isn't centered vertically in the cells anymore. If that is important, you could make sure it stays that way by adding vertical-align:middle; to the cells in {{s-rail}} & {{s-line}}. —Ms2ger (talk) 16:36, 13 January 2008 (UTC)

Spacing

It seems that everywhere this template is used, there is an excess space/margin at the top. I'm not sure what causes this, but my only edit to this template didn't help (just now I noticed it was under 'noinclude' anyway... figures). In any case, can anyone please fix this? It's a very annoying problem. See for example: Kfar Saba Railway Station, Binyamina Railway Station. -- Ynhockey ^(Talk) 20:26, 17 April 2008 (UTC)

The problem is not with the template. There are many pages that do not suffer from the problem. For example Farrer Park MRT Station. I can't pinpoint the problem as yet, but i suspect it might be a side-effect of proper browser rendering/wikimedia software of both ltr and rtl languages in the same page. - oahiyeel ^talk 20:49, 17 April 2008 (UTC)

• If I take the map_locator code out the problem goes away. Something in there is introducing an unnecessary break, at least when the code isn't called. I've seen that before. Mackensen (talk) 20:58, 17 April 2008 (UTC)

Thanks for the replies. Is there any way to solve the problem without hurting the template? How many pages use the map locator field anyway? -- Ynhockey ^(Talk) 21:05, 17 April 2008 (UTC)

That doesn't explains why the problem doesn't occur on Grand Central Terminal & Pennsylvania Station (New York City) and many other pages as well. I'm not trying to defend the code I added, but it is a carbon copy of the code above it for the services field, which is even more complicated since it nests a table in it. I think it is important to pinpoint the problem properly, hopefully an expert in wikicodes can take a look at it. Meanwhile, i'll carry out some tests of my own too. - oahiyeel ^talk 21:12, 17 April 2008 (UTC)

When examining the generated html codes for pages with the blank space above, the line causing the extra breaks appears immediately after the <!-- start content --> which is: <p><br /></p>, i'm now checking to see if any part of the code in the template may cause this extra line for any reason. - oahiyeel ^talk 21:28, 17 April 2008 (UTC)

Solved. It appears minor coding differences forces the "services" and "map_locator" on to new lines, causing the "spacing" problem. I've fix the coding so that the "new lines" are not required anymore. - oahiyeel ^talk 22:01, 17 April 2008 (UTC)

type not displayed

why is type no longer displayed? e.g. transportation hub or rapid transit? Sebastian scha. (talk) 20:24, 6 June 2008 (UTC)

• Forgot about it when I changed the internal code. I'm working on re-adding it. Mackensen (talk) 23:19, 6 June 2008 (UTC)
• It's back; there may be some style weirdness. Mackensen (talk) 23:49, 6 June 2008 (UTC)

Oh thanks, I use it only for general information like rapid transit and so on, but is okay for like this Sebastian scha. (talk) 23:57, 6 June 2008 (UTC)

Platforms not displaying

I've gone through the syntax of the infobox but I can't figure out why the platform parameter won't work. If you type in "platforms" as a parameter, then it displays what you write after =. Can anyone help with this? Geoking66_talk 02:20, 10 June 2008 (UTC)

• Fixed, I think. It was passing platforms as both the label and the value. Mackensen (talk) 02:29, 10 June 2008 (UTC)

Now fixed, because it was in the /doc | data9={{{platform|}}} and in the template | data9={{{platforms|}}} Sebastian scha. (talk) 02:57, 10 June 2008 (UTC)

There must be another code error because, it's still not working. sorry. I'll undo my edit. And in the comment above I meant in the doc/ is | platform= Sebastian scha. (talk) 03:02, 10 June 2008 (UTC)

I'm too fast for myself now it's working. but it was nice talking to myself ;-) Sebastian scha. (talk) 03:04, 10 June 2008 (UTC)

Add microformat

{{editprotected}}

Please add an hCard microformat, by inserting:

<code>
| bodyclass = vcard
| titleclass = fn org
| class3 = label
| class20 = nickname
| class24 = nickname
</code>

(classes 20 & 24 duplicate deliberately). Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:06, 8 September 2008 (UTC)

Sorry, I have no idea where you want this code inserted. And shouldn't it have pipes? --MZMcBride (talk) 06:03, 10 September 2008 (UTC)

It doesn't matter where the code goes, though some if the items are numbered, and numerical sorting is usual. By convetion the other values go near the start. Pipes added, though, again, there's a standard convention in use. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:35, 10 September 2008 (UTC)

Done. Cheers. --MZMcBride (talk) 09:24, 10 September 2008 (UTC)

Thank you. Unfortunately, I was in error. Please replace | titleclass = fn org with | aboveclass = fn org. Apologies for the extra work. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:35, 10 September 2008 (UTC)

 Done Stifle (talk) 11:46, 10 September 2008 (UTC)

Thank you. That's working now, I've updated the documentation accordingly. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:35, 10 September 2008 (UTC)

Statistics?

Apologies for jumping in with a question, despite being only a recent user of this infobox, but is the phrase "Station statistics" in this infobox really appropriate as a heading for information that doesn't seem to include much in the way of "statistics"? Wouldn't something like "Station information" or "Station details" be more logical? --DAJF (talk) 10:23, 19 January 2009 (UTC)

Connection intro

fr:Gare de Pessac shows a great way to do connections.

| titre corresp 1=Tramway
| corresp 1=Ligne File:Logo Ligne B.png (Pessac Centre) 
| titre corresp 2= Bus
| corresp 2= Lignes 34, 35, 45, 46, 47, 48, 81, 35Exp
| titre corresp 3=   
| corresp 3=   
| titre corresp 4=   
| corresp 4=

That's what they do on fr:Modèle:Infobox Gare and it's great, I think. Anyone think we should implement this? gren グレン 19:20, 29 January 2009 (UTC)

"Route map" request

{{editprotected}} Can somebody copy the code from {{Infobox rail line}} that allows for the route diagram template inclusion? Thanks. — Alex Khristov 07:06, 19 May 2009 (UTC)

Okay, I added the code the way it should be added. Please add it between

 | data34={{{map_locator|}}}

and

}}</includeonly><noinclude>

— Alex Khristov 06:56, 20 May 2009 (UTC)

 | belowstyle = vertical-align:middle;
 | below      = {{#if:{{{map<includeonly>|</includeonly>}}}|
<table style="width:100%; margin:0; background-color:#F9F9F9;" class="collapsible {{{map_state|}}}">
<tr><th style="background-color:#efefef; text-align:center;">{{{map_name|Route map}}}</th></tr>
<tr><td align="center">
{{{map}}}
</td></tr>
</table>
}}

 Done, please let me know if there are any problems. — Martin (MSGJ · talk) 07:30, 20 May 2009 (UTC)

Thanks, but I think all the spaces to get the HTML code to look better screwed it up a bit... it's not supposed to have the dashed box around it. :-) — Alex Khristov 08:11, 20 May 2009 (UTC)

Oops,  Fixed. — Martin (MSGJ · talk) 09:07, 20 May 2009 (UTC)

Oops, discovered another flaw. There's another "map" parameter. Can you change the one you added to "route_map"? Thanks. — Alex Khristov 06:57, 21 May 2009 (UTC)

 Fixed — Martin (MSGJ · talk) 08:58, 21 May 2009 (UTC)

Accidents

{{editprotected}} Can we have a new area for accidents, it would be used as a digit, so lets say a station had two crashes in it before it would read Accidents 2. Its just a new field and it would be useful thanks. ZStoler (talk) 19:46, 28 May 2009 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. Amalthea 21:14, 28 May 2009 (UTC)

Comment If an accident is notable enough to be mentioned, it should have extensive coverage in the article. An Infobox is for things that usually happen - not accidents. Secondarywaltz (talk)

Comment I second the comments of Secondarywaltz above. --DAJF (talk) 23:47, 28 May 2009 (UTC)

Comment I agree completely with Secondarywaltz. Mackensen (talk) 00:37, 29 May 2009 (UTC)

Comment I agree with the other three users who believe that this would be an inappropriate use of the template. SchuminWeb (Talk) 00:47, 29 May 2009 (UTC)

Alternate text

Can we add a parameter that will pass alternate text for the image? --Admrboltz (talk) 22:00, 18 August 2009 (UTC)

Milepost

On many lines, stations and other structures are at a known distance from a fixed point; typically the main terminus. Would it be possible to have a field in the statistics section to show this?

Eg:

| milepost      = <!--{{convert|10|mi|km}}-->

Alternatively or additionally, how about some free label/text fields?

As an example, Template:Infobox school provides:

| free_label    = 
| free_text     = 
| free_label1   = 
| free_text1    = 
| free_label2   = 
| free_text2    = 
| free_label3   = 
| free_text3    = 
| free_label4   = 
| free_text4    = 
| free_label5   = 
| free_text5    = 

-Arb. (talk) 22:57, 1 September 2009 (UTC)

I second this suggestion for adding milepost.Robsavoie (talk) 17:47, 29 May 2011 (UTC)

Surely a mileage value for a station only makes sense if you know where the distance is measured from? With such a parameter, would editors be encouraged to add this information to the "milepost" parameter (e.g. milepost = 10 miles (16 km) (from Melbourne Central)) or would the origin point/station be specified in a separate parameter?

Second, is the term milepost appropriate when in many countries these days the metric system is preferred or required for "official" measurements such as these? – Matthew25187 (talk) 00:55, 30 May 2011 (UTC)

The metric equivalent is normally kp for Kilometer post. I don't see any reason why we couldn't have both parameters. Railwayfan2005 (talk) 22:10, 29 November 2011 (UTC)

Edit

Please make changes according to this diff. They put in the variables on the template page so it's clearer which parameters go where on the template itself. Thanks - oahiyeel ^talk 05:30, 10 December 2009 (UTC)

• Done. Mackensen (talk) 14:54, 10 December 2009 (UTC)

Thanks :) - oahiyeel ^talk 15:39, 10 December 2009 (UTC)

style parameter

I've noticed there's a style parameter that is not mentioned in the documentation but is used often in Amtrak station articles. How does this parameter work? --TorriTorri^{(Talk to me!)} 00:25, 3 February 2010 (UTC)

• The parameter is tied in to the {{s-rail}} series of templates; if you put in "Amtrak" it'll call up a set of values from {{Amtrak style}}. Mackensen (talk) 03:17, 3 February 2010 (UTC)

Accessible

We need a proper parameter where we can enter "accessible = yes/no" not just the current USA expression "ADA" which no matter what you enter will display a wheelchair icon. If an entry for ADA exists by all means continue to show the icon, but we also need the ability to say that the station is NOT accessible. This additional parameter would enable those who are in favour of using the image to continue to do so, but also allow a text message instead, when some other situation exists. Secondarywaltz (talk) 21:10, 4 March 2010 (UTC)

Smartcard parameters

I propose adding two parameters called smartcardname and smartcardstatus or similar, which would allow usersto specify whether or not the station is included in any relevant smartcard system. (I'm specfically thinking of the Presto card and TTC subway stations, because not all subway stations are planned to have card readers, and the roll-out for those that are will take place in several stages). Any thoughts/comments/suggestions?

Probably a good idea, and one that I for one never thought about. I ride the Washington Metro, and on Metro, everything takes SmarTrip (the local smart card), and so I never really gave it any thought. But I do think it's a good idea for those systems where smart card implementation is not uniform. SchuminWeb (Talk) 02:49, 25 March 2010 (UTC)

{{editprotect}}

Given the lack of objections, please add the following two lines of code to just below the fare zone part of the code, and increase the numbering on label23/data23 onwards by one:

| label23={{{smartcardname}}}

| data23={{{smartcardstatus<includeonly>|</includeonly>}}}

Tompw (talk) (review) 21:21, 2 May 2010 (UTC)

 Done  Ronhjones  ^(Talk) 22:25, 2 May 2010 (UTC)

Edit needed

{{Editprotected}} Could someone please add the copy of CTA code for MOSMETRO? Thanks. Artem Karimov (talk | edits) 13:41, 20 June 2010 (UTC)

Could you be more specific as to what you actually want changing, please? Thank you. HJ Mitchell | Penny for your thoughts? 17:26, 20 June 2010 (UTC)

above parameter. Make a copy with mosmetro_header option in if operator. Artem Karimov (talk | edits) 17:28, 20 June 2010 (UTC)

I think that you should simply create a "style" for the header. See Template:MNRR New Haven style and what it does. Secondarywaltz (talk) 17:42, 20 June 2010 (UTC)

Changes

For accessibility and Google-friendliness reasons "title" should be used instead of "above" for {{{name}}}. Also this infobox seem to overwrite the main infobox with "font-size: 90%;" over "font-size: 88%;", unless there a reason for the overwrite, the infobox shouldn't be overwritten. So with theses two reasons I suggest "title" is used and "font-size: 90%;" is removed. Thoughts? d'oh! _talk 15:19, 25 July 2010 (UTC)

That would have a major negative impact on the way that {{{name}}} and {{{type}}} currently display together to form a unified heading within the box, whereas using "title" would display the name parameter above the box. If Google searches on the article title, what would be the problem? Secondarywaltz (talk) 17:25, 25 July 2010 (UTC)

Oh! You don't seem to use the {{{type}}} or {{{style}}} parameters. Secondarywaltz (talk) 17:30, 25 July 2010 (UTC)

Yes I don't use {{{type}}}, but I fail to see how the change will negative impact {{{type}}}. The reason why "title" should be used, goes to what HTML code the infobox creates at the end. With "above" a normal row is used but with "title" the infobox uses <caption/> tag which helps accessibility software for disabled people and search engine crawlers. d'oh! _talk 04:34, 5 August 2010 (UTC)

This seems to conflict with the way {{Infobox}} itself is designed--Infobox allows either above or title to be used, without prejudice. Making the change you suggest would place the styling information for the station name outside the infobox, which is not a minor change. I agree with Secondarywaltz; surely Google searches and screen readers depend on the actual title of the article, not a parameter in the infobox? There's nothing obvious in Infobox's documentation suggesting that the one is preferable to the other. Mackensen (talk) 09:31, 9 August 2010 (UTC)

On the other hand, that's the style adopted by the most common country-specific templates, such as {{infobox UK station}}. Anyway, I've put up a sandbox and test cases which remove the width and font size overrides as a start: if there are no objections I'll sync these in a few days. Chris Cunningham (user:thumperward: not at work) - talk 11:00, 15 September 2010 (UTC)

Well, it looks mostly identical (so either I misunderstood the original proposal, this isn't that proposal, or it wasn't explained well). Dropping the image width default will have a negative impact on article formatting. Also, at least on the CTA articles (try State/Lake (CTA), it's representative) we lose the th background color for some reason. Mackensen (talk) 11:13, 15 September 2010 (UTC)

The original proposal contained two suggestions: using a proper HTML caption and not a header row for the title, and using the default {{infobox}} metrics (for font size specifically, but extrapolated to the general case). The sandbox drops the overrides of the width, font size, and header background attributes, along with using frameless (the reader's default thumbnail size) as the image size default rather than hard-coding 300px (which not only results in oversized infoboxes, but also results in images smaller than 300px being stretched). The original styling appears to have been arbitrary, whereas the {{infobox}} defaults have been repeatedly discussed and found to be suitable for most articles. Chris Cunningham (user:thumperward: not at work) - talk 11:39, 15 September 2010 (UTC)

Hold on! These poor examples do not adequately show the impact that changing the current default width has. The box should be wide enough to display information without wrapping major parameters, like coordinates. Try something that only uses this infobox and is not stuffed with things unrelated to the discussion or, as you have pointed out, falsely forces a box width with an image size. This is a hurried response, or I would have shown you what I meant. I'll be back! 74.15.65.161 (talk) 15:18, 15 September 2010 (UTC)

I agree about the image size but longer information for some parameters in thousands of articles has been formatted to suit the current box width and that will cause unusual breaks in text. Secondarywaltz (talk) 16:27, 16 September 2010 (UTC)

Architect and Artist

Its seems to me that all buildings, not just stations, should have an entry for the architect in the infobox. Many Metros, like Moscow and Paris, are famous for their art, and many new subway systems have a certain portion of their budget given over for art in the stations. I therefore propose two new parameters for "architect" and "artist" to be added after "structure". Secondarywaltz (talk) 17:24, 30 August 2010 (UTC)

Seems a good enough idea. SchuminWeb (Talk) 19:20, 30 August 2010 (UTC)

I second or third this. It's actually a stunning omission. A number of rail stations in the U.S. are historic edifices, and their architects are a matter of record. Why they would not be in the station infobox is puzzling. Jhw57 (talk) 16:23, 9 May 2011 (UTC)

Passenger numbers

It would appear that we need to modify the way the "passengers" parameter displays. Here's what happened to bring me to this request:

• Patriarca12 adds average weekly ridership figures to Addison Road – Seat Pleasant (WMATA station) (diff) using a WMATA source.

• Patriarca12 then self-reverts (diff)

• I inquire regarding the removal (diff), and Patriarca12 responds (diff).

As it turns out, according to Patriarca12, most systems that use this infobox parameter use it to display total ridership for the year, whereas the information that we have is average weekday ridership. Thus it would appear that the "passengers" parameter should be modified in order to allow for us to specify exactly what kind of ridership data we are reporting. In the case of WMATA, I don't believe that we have annual totals available to us, thus we are unable to utilize the parameter as exists.

What I'm thinking is that we add some sort of parameter that allows us to describe in the infobox, next to or nearby to the number, just what kind of information we are using to arrive at the figure that we are giving.

Thoughts? SchuminWeb (Talk) 21:56, 3 October 2010 (UTC)

I absolutely agree with SchuminWeb on this one. A separate parameter to allow for average weekday passenger loads would be helpful. This type of information I know for certain is available for both WMATA and Miami-Dade Transit and would probably be easily available for most systems. It would be nice to be able to add it to the infobox. Patriarca12 (talk) 23:45, 3 October 2010 (UTC)

Does this really require a separate parameter to accomplish? It's already possible to specify multiple passenger numbers (using mpassenger); what's wrong with passing a value like "Daily" or "Daily FY2009" in pass_year? Mackensen (talk) 02:32, 4 October 2010 (UTC)

I just want to be able to delineate it in a way that makes sense when putting it all together. That seems more like a workaround and kind of non-standard. SchuminWeb (Talk) 19:06, 5 October 2010 (UTC)

Reopened

Can we add a new parameter for "reopened"? Given that currently there are parameters for "opened" and "closed" I really believe this would be an easy way to provide noteworthy information for stations that have been reopened after a period of being closed (not for something temporary like reconstruction) without resorting to something clumsy like adding breaks and parenthetical comments underneath the "opened" parameter. Lost on Belmont (talk) 22:00, 5 January 2011 (UTC)

Maybe take inspiration from {{Infobox GB station}} which has nine pairs of |yearsn=/|eventsn= for the purpose of recording opening, renaming, closure, reopening etc. Some stations in the UK have been reopened two or even three times. --Redrose64 (talk) 22:03, 5 January 2011 (UTC)

Whatever the method, can at least something be done? Hint hint, admins. Lost on Belmont (talk) 19:27, 12 January 2011 (UTC)

There should be a little rethink to help make this Infobox become more universally available. There are a lot of custom versions out there, that only exist because of the reticence to add a couple of parameters. Infobox road, a much more complex system, was recently upgraded to accommodate complete worldwide usage. Secondarywaltz (talk) 22:18, 12 January 2011 (UTC)

Coords type parameter

{{editprotected}}I'd like request the following change to the coordinates code: type:landmark

be replaced with

type:railwaystation

per Template:Coord#type:T. Thanks. XLerate (talk) 06:49, 15 February 2011 (UTC)

Will do. Plastikspork _―Œ^(talk) 06:59, 15 February 2011 (UTC)

Rename proposal

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: no change. Kotniski (talk) 08:15, 25 February 2011 (UTC)

---

Template:Infobox station → Template:Infobox train station — Station is ambiguous per that dab page - gas/petrol station, police station, radio station etc.

• Support as nominator. XLerate (talk) 05:24, 17 February 2011 (UTC)
• Support --AdmrBoltz 05:36, 17 February 2011 (UTC)
• Comment If the page is moved, I would prefer Template:Infobox rail station. "train station" is ... well, it's been discussed before. "rail station" avoids the ugliness and is ENGVAR-neutral between "railroad station" and "railway station". --Redrose64 (talk) 12:13, 17 February 2011 (UTC) amended Redrose64 (talk) 20:58, 17 February 2011 (UTC)
• Support Train station is the name of our article, keeping the template consistent makes sense. oknazevad (talk) 13:32, 17 February 2011 (UTC)
• Oppose - I'm worried that doing so will damamge the thousands of templates that have already been added. If this isn't the case, I'll change my vote to Support. ----DanTD (talk) 13:44, 17 February 2011 (UTC)

Moving a template to a new name leaves a redirect at the old name, which makes sure the template still works. See for instance the articles transcluding {{Infobox Station}} (which is a redirect to the current {{Infobox station}}). Markussep ^Talk 14:40, 17 February 2011 (UTC)

• Comment I agree that it makes sense to have the template name in line with the article name, but I personally don't like the term train station. I'd prefer railway station, but I realise it is not ENGVAR-neutral, whilst rail station smacks too much of offical-speak. I don't see any real problems with using station as the main article name with a For other uses, see Station (disambiguation) hatnote, in which case this article could remain as is. Tim PF (talk) 15:27, 17 February 2011 (UTC)
• Oppose Although this is well intentioned, I don't think it is really necessary. The primary use of "station" is undoubtably rail/railway/railroad/train station. If any of you say "I am going to the station", we would all assume that you were probably going to catch a train, otherwise you would use a modifier. The proper names of most railway stations (in the real world) do not use any disambiguation, whereas other types of facility called 'station' require it. This template is also used as an infobox for bus station, subway station, metro station, LRT station, BRT station, Transportation Center, etc. If it is disambiguation you are concerned about here, I would suggest that limiting the new name to rail/train, would not adequately describe the full usage of the infobox. Secondarywaltz (talk) 17:00, 17 February 2011 (UTC)
• Oppose Unnecessary and, for the reasons given by Secondarywaltz, inappropriate. Skinsmoke (talk) 17:18, 17 February 2011 (UTC)
• Oppose Same as above, this change would only be neccesary if there was templats for Police, Fire, Rescue, etc.. stations. WatcherZero (talk) 17:51, 17 February 2011 (UTC)
• Oppose Any good dictionary will show that the primary meaning of "station" is "railway/railroad station" and the less we perpetuate the modern slang "train station" the better. "Station" is also the term used by the International Union of Railways. --Bermicourt (talk) 20:53, 17 February 2011 (UTC)
• Oppose We don't have infoboxes for gas, police stations etc. so the change is unnecessary. →♠Gƒoley↔Four♣← 00:26, 18 February 2011 (UTC)
• Oppose -- You now go around the world nominating region versions. See other Templates for Infobox Austria station, Infobox China station, Infobox GB station, Infobox Ireland station, Infobox Italy station, Infobox London station, Infobox Norwegian station, Infobox Slovenia station, Infobox Switzerland station, -- more. Looks like there is a long established naming convention involved. Martin Morin (talk) 06:08, 18 February 2011 (UTC)
• Oppose There's no good reason to change the name that I can see. {{Infobox building}} exists to cover many of the other types of building mentioned above. Mjroots (talk) 06:25, 18 February 2011 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Station Categories

Please can we have a field for recording the category of a stations, from Halte up to Hbf, or the local equivalents. {{Infobox Deutsche Bahn station}} has it in the Type field but {{Infobox station}} doesn't have the equivalent. (Or is this what the undocumented status parameter is for?) Railwayfan2005 (talk) 22:16, 29 November 2011 (UTC)

The parameter {{{type}}} is the second one here. You can use that. Sw2nd (talk) 01:22, 30 November 2011 (UTC)

Can or should? This is what the instructions currently have:

type – Transit system name and type of rail station (rapid transit, light rail, tram, commuter rail and/or regional rail)

   ex: SEPTA rapid transit and tram station
   ex: Metrolink commuter rail station
   ex: San Diego Transit light rail station
   ex: RTA rapid transit station

Not really the same as Cathedral, Mega, Plus, Basic and Stop as used in the Netherlands, or the Germany system.

Native name

Please can someone add |native_name= and |native_name_lang=, modelled on the code in {{Infobox settlement}}? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:48, 15 January 2012 (UTC)

I've put it in {{Infobox station/sandbox}} - please test --Redrose64 (talk) 14:59, 16 January 2012 (UTC)

I've made a tweak to the microformat; looks good, thank you, so I've flagged as {{Editprotected}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:27, 17 January 2012 (UTC)

Done --Redrose64 (talk) 19:44, 17 January 2012 (UTC)

See template:Infobox station/sandbox. We should really have "native_name" before "type". Type is the same no matter what name parameter is used! This example also shows use of the "style" parameter mentioned below. Secondarywaltz (talk) 23:41, 17 January 2012 (UTC)

Could you make the appropriate change at {{Infobox station/sandbox}} please? Since I added the native_name stuff, somebody's fiddled with the classes, and I'm not sure how these should affect the native_name --Redrose64 (talk) 23:46, 17 January 2012 (UTC)

I'll try - but don't nag if I don't get the openings and closings right. You are the expert. Secondarywaltz (talk) 23:59, 17 January 2012 (UTC)

It works -I think. Secondarywaltz (talk) 00:32, 18 January 2012 (UTC)

cta_header

Does anyone know what the undocumented |cta_header= does? Can someone add it to the documentation, please? Or should it be removed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 17 January 2012 (UTC)

See Clark/Lake (CTA station) for an example. Mackensen (talk) 12:36, 17 January 2012 (UTC)

Thank you. Given that the lines and colours are in the infobox anyway, do we need that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:32, 17 January 2012 (UTC)

I've always had the same doubts about this - but it's harmless. Secondarywaltz (talk) 18:30, 17 January 2012 (UTC)

I would say that from a WP:ACCESS point of view, white lettering on dark grey is more readable than either white or black on a stripe of any-colour-you-like. The grey bit is flanked by two areas of colour, which vary from station to station to denote the lines: but these flanking areas do not contain any lettering. This is, after all, why the colours in the s-line boxes are restricted to two narrow bands where no lettering appears. --Redrose64 (talk) 19:56, 17 January 2012 (UTC)

Are you aware of the "style" parameter? The point being made by Andy is that you could set the same white on grey using a style template (as shown above) and the colours are already included individually for each line in the infobox. The argument for retaining it is that many station signs actually look like that; with sidebars matching the lines serving that platform (also shown in the image above). Secondarywaltz (talk) 23:41, 17 January 2012 (UTC)

The background to this is that the CTA stations once had their own infobox with hard-coded support for this. Implementing this header was part of the migration process. I think it looks fine myself and isn't hurting anything. Mackensen (talk) 12:23, 19 January 2012 (UTC)

Standardize Infobox

Since we are considering changes, perhaps this is the time to review some parameters in this template that should be changed or added, to allow several regional custom versions to be converted to use this one as a station infobox. See Category:Railway station infobox templates for examples. With some relatively minor tweaking, this could be adapted to replace most, but not all, cases.

• "ADA" - only applies to USA and should be changed to match its label "accessible".
• "other" - general expression should should be changed to match its label "connections"
• "architect" - this parameter should exist for all buildings.
• "artist" - the Moscow and Paris Metros are famous for their art - and many new ones too.
• "elevation" - custom boxes in mountainous countries like Norway, Switzerland and India use this.
• There are numerous other additional parameters used in these regional versions, but most of them are expanded ways of entering "address" (state, region, canton, municipality, city, etc.) or "other" (connections, buses, trams, etc.). Custom sub-templates could be used to address local concerns. Secondarywaltz (talk) 18:28, 17 January 2012 (UTC)

I agree with the above. I'd also like to see a "reopened" parameter added, or some sort of multiple addition parameter to fulfill this role. Apparently the British one has something for this, but the primary one still doesn't. I asked for this over a year ago and was given suggestions as to what to do, but I'm not capable of doing such things. Lost on Belmont (talk) 22:17, 17 January 2012 (UTC)

The British one, {{Infobox GB station}}, doesn't have any special "reopened" parameter. Instead it has several pairs of parameters named like |yearsn=|eventsn=, with which any significant events (opening, closure, reopening, renaming, major expansion, reconstruction on new site, etc.) may be listed chronologically. See Birmingham Snow Hill station for example (the events are listed after the railway companies below the "History" header). --Redrose64 (talk) 23:29, 17 January 2012 (UTC)

Good example. People have been forced into using "rebuilt" when the station has simply "reopened". Note that Infobox GB station is one that should not be merged. It is not really comparable, with a unique set of parameters and its operation and usage is well maintained. Secondarywaltz (talk) 23:34, 17 January 2012 (UTC)

I'm aware that {{Infobox GB station}}, doesn't have a "reopened" parameter, but as I explained it has a set of special parameters (some sort of multiple addition parameter is what I said refering to |yearsn=, |eventsn=, etc.) that don't exist here. You mention these parameters here as you did in request from January 2011, but such parameters don't exist in this template (at present). Until this changes, mentioning them as a solution isn't helpful and why I've brought it up again. Lost on Belmont (talk) 00:06, 18 January 2012 (UTC)

I agree - My reply was to you. I said it was a good example! Secondarywaltz (talk)

Odd. It looks like my original reply was erased from history... I know, and I thank you for your support. I was replying to Redrose64. Lost on Belmont (talk) 02:30, 18 January 2012 (UTC)

I will add architect which will help with the merger of Template:Infobox Slovakia station. Please open an edit request if you would like to add more of these. Thanks! Plastikspork _―Œ^(talk)

I'm not sure what constitutes 'accessible' with regards to stations but in Japan it is not uncommon for rural stations to be without a ramp or lift (elevator). Can we add something like "Elevator to all platforms" or "No ramps or elevators" under the ADA listing or do we need to wait for it to be renamed? I know a few stations for which I'd like to mark as being sans lifts and ramps.1bj05hua (talk) 10:46, 3 November 2013 (UTC)

Logo

Can someone insert "|Logo" for Gare d'autocars de Montréal? Peter Horn User talk 23:32, 26 January 2012 (UTC)

There is no paramater called "logo". Please stop adding something to the documentation that does not exist. Secondarywaltz (talk) 00:11, 27 January 2012 (UTC)

Edit request on 5 March 2012

Please make the following two changes to the template (broken into two changes to make it more clear what is happening). First, renumber [1], then insert. Or, if you trust me, then just copy and paste this version of the sandbox. the reason for this change is to add a field for the operator, which may not be the same as the owner, and is necessary to merge Template:Infobox Barcelona station, which was closed as merge in the January 13 TfD. once this is done, I can complete the merger. Frietjes (talk) 21:59, 5 March 2012 (UTC)

 Done, I'll let you update the documentation. Tra (Talk) 23:01, 5 March 2012 (UTC)

QR/TransLink Long Distance Services

The code for the Long Distance services in Queensland is breaking the links on the infoboxes of the related pages. See: Roma_Street_railway_station,_Brisbane and Gympie North railway station.

All the links in Services section of Template:Infobox station work for me in those articles. Do you mean the additional Long Distance services box? I don't understand. 174.88.134.113 (talk) 06:30, 28 May 2012 (UTC)

I mean the links to the Preceding and Following stations. TravellerQLD (talk) 07:19, 28 May 2012 (UTC)

Nambour railway station is an example of where the wikilinks in the infobox template aren't working. The owner doesn't link but the rail line above does. - Shiftchange (talk) 08:18, 28 May 2012 (UTC)

The doesn't link either. But if you WP:PURGE the page, all the links work. Most likely it's a change to one of the subtemplates - even to one of the CSS class files - which hasn't propagated through to the article, and nothing to do with {{infobox station}} per se. --Redrose64 (talk) 12:36, 28 May 2012 (UTC)

Got it. The "Long Distance services" box is enclosed by a <div>...</div> construct, which is full width, but invisible. This starts immediately below the "Services by platform" box, but because the bottom of that box is above the bottom of the infobox, the <div>...</div> is in front of the infobox - and hides all the links below the bottom edge of the "Services by platform" box. The solution is to force the top edge of that <div>...</div> to below the bottom of the infobox. The styling clear: both; will do that: there is one on the table, so we merely need to move that to the <div>...</div>, like this. --Redrose64 (talk) 13:01, 28 May 2012 (UTC)

Awesome. Fixing the rest now. Thanks a lot. TravellerQLD (talk) 13:08, 28 May 2012 (UTC)

The code looks somewhat complex for general use: this is the sort of thing that's usually tucked away in a template, so I was wondering if a template had been substituted in error. But this doesn't seem to be the case: see these edits to Roma Street railway station Gympie North railway station Nambour railway station - two different editors have done this, so presumably it was a conscious edit. --Redrose64 (talk) 13:30, 28 May 2012 (UTC)

Weird... Do you think we should put it into a template? I'm fairly new around here so I'd have no idea what I'm doing but would appreciate it if you could do it. TravellerQLD (talk) 13:41, 28 May 2012 (UTC)

We already have several families of templates for rail routes: if we created yet another type, the WP:TFD crew would seize on it straightaway. I think that it would be better to use one of the existing systems. Consider Landsborough railway station: the box there could be replaced with this

which is more compact, both in the wikicode and on the rendered page. I've used {{rail line}} here, because it's easy to demonstrate with, compared to {{s-line}} which needs a whole family of subtemplates behind the scenes. --Redrose64 (talk) 17:11, 28 May 2012 (UTC)

I agree that the simplest way is to replace all the redundant code with the standard infobox as shown above and Redrose64 is the right person to advise you. Note that I have also added a link to Tilt Train, the same as other services, since I didn't know what it was. That would have been covered by the Wikipedia:WTF crew. Secondarywaltz (talk) 18:46, 28 May 2012 (UTC)

Alright, I'll replace them all now. Thanks a lot to both of you! TravellerQLD (talk) 22:36, 28 May 2012 (UTC)

If you're going to use the same technique that I demonstrated above, you might like to know about a couple of other things that {{rail line}} does. If you omit either |previous= or |next= (or leave them blank), it'll display the word Terminus, italicised; and you can put a colour in the two narrow boxes by specifying |col=, as in |col=0099CC (see hex triplet). --Redrose64 (talk) 22:51, 28 May 2012 (UTC)

Yep, I've used those for Roma Street, as it was the terminus for all its services and one service had a horrifying red block behind it so I made the columns red. I'll get around to adding infoboxes to the non-TransLink services soon. TravellerQLD (talk) 23:23, 28 May 2012 (UTC)

Infobox styles

How do I make/edit my own custom style for the infobox? I'm stumped trying to find it. TravellerQLD ^{(talk | contribs)} 06:33, 23 October 2012 (UTC)

• It's not documented all that well. Check out {{Amtrak style}} for an example. It's all tied in to the {{s-rail}} series of templates. Mackensen (talk) 12:09, 23 October 2012 (UTC)

Since I did some of this with you before, I can help again. What specifically do you want to know? Sw2nd (talk)

I wanted to be able to change the QR style of the infobox. The thing where you specify "style = QR" in the infobox. How do I edit that style? TravellerQLD ^{(talk | contribs)} 12:37, 23 October 2012 (UTC)

The template {{QR style}} is the one you want. Be careful :) Sw2nd (talk) 12:52, 23 October 2012 (UTC)

Thanks, I changed what I needed. :) TravellerQLD ^{(talk | contribs)} 13:02, 23 October 2012 (UTC)

Style tweaks

I've made some optimisations to the codebase in the sandbox to remove some unnecessary cruft, along with removing the overrides which increased the default font size and width: the result can be seen at Template:Infobox station/testcases. There's really no reason to override the {{infobox}} defaults here, especially as this is a typically data-heavy template which can be intrusively long if filled out completely. Chris Cunningham (user:thumperward) (talk) 13:38, 12 November 2012 (UTC)

• This looks fine to me. Others? Mackensen (talk) 23:14, 12 November 2012 (UTC)
  • the biggest problem that I see is that this will completely kill the optional |box_width= with no check of the articles using it. I am all for making the defaults default, but I can't support removing this parameter completely until there is a study of its usage. the other problem is that all the whitespace edits have made the diff nearly unreadable. I would suggest concentrating on a non-whitespace change first, or make a whitespace only change to the main template first so the diff will be readable. Frietjes (talk) 00:02, 13 November 2012 (UTC)
    • Other than the removal of the font-size and width overrides, the changes are primarily for code tidiness, and most of those have zero effect on transclusions (the removal of the wads of includeonly cruft, for instance). There is a slight change in the way NRHP sub-templates are included which avoids using a table-within-a-table (see the change to the test cases page for the slight syntax update). As for the width option, IMO the only way to get feedback on this without an exhaustive preemptive trawl through the transclusions is to make the change and wait to see if it causes any fallout; it shouldn't have any more adverse an effect than the odd new line break, and those can (and should) be tackled on an individual basis rather than a global option. Chris Cunningham (user:thumperward) (talk) 10:56, 13 November 2012 (UTC)

For the love of Cthulhu, don't kill the box_width parameter. For infoboxes without images, it's essential sometimes to unbreak Route Diagram Templates that get disruptive linebreaks with the default size. Otherwise, the changes look reasonable. Pi.1415926535 (talk) 15:43, 13 November 2012 (UTC)

exactly, there is a real reason why this parameter is there. I have made some minor modifications to the sandbox: (1) re-added the box_width parameter, and (2) reverted the other changes to the route_map code, and (3) modified the whitespace to make the diffs actually readable. you can now actually see the differences between the live and sandbox code here. The other notable change in the sandbox version is using a default image size of frameless, as opposed to 300px. the practical implication of this is a reduction from 300px to 220px. in the case of uses with route_map this may cause breakage, since an image would effectively set the box_width to 300px. I think we need a survey of the uses with route_map set before we can make a change to the live template. Frietjes (talk) 16:36, 13 November 2012 (UTC)

Many thanks. I've now pushed out the latest version, incorporating all of your fixes and tweaks. If this does indeed cause any general problems with width we can fix that separately. Chris Cunningham (user:thumperward) (talk) 13:59, 7 January 2013 (UTC)

The 220px default width is too narrow for a lot of infoboxes, where it forces the s-rail and similar templates onto multiple lines. The other changes are fine, but please change it back to 300px default. Pi.1415926535 (talk) 21:36, 8 January 2013 (UTC)

I agree. this is exactly why I was objecting to the change to frameless. I would support using "frameless" with "upright=1.36", which would effectively restore the width to 300px, while still supporting custom thumbnail sizing. Frietjes (talk) 22:03, 8 January 2013 (UTC)

change "frameless" back to "300px" per the thread above and undo the change to the default boxwidth. it was recently changed in this edit, and it appears there was no consensus for this change. Frietjes (talk) 22:08, 8 January 2013 (UTC)

Is it not the default box width that would cause these problems? If there is a large image size it merely forces extra width, and if there is no image the problem would still persist. Sw2nd (talk) 00:49, 9 January 2013 (UTC)

yes, there is a combination of two issues, one is that the default box width was reduced, and two that the default image size was reduced. for both changes we had requested that a list be made of the templates using both route maps and the defaults, so they could be addressed once a change was made. however, this request was ignored without consensus. Frietjes (talk) 17:24, 9 January 2013 (UTC)

 Done, though in future a friendly note will attract my attention just as quickly as an editprotected request suggesting that I've gone rouge. Chris Cunningham (user:thumperward) (talk) 14:51, 10 January 2013 (UTC)

Thanks, but now I'm seeing a weird error. Most infoboxes with the defualt size are not showing the image; see Union Station (Kansas City, Missouri) for an example. Pi.1415926535 (talk) 15:11, 10 January 2013 (UTC)

Perhaps you should be "rouge" . Secondarywaltz (talk) 15:23, 10 January 2013 (UTC)

Stupid parser nonsense when trying to implement Frietjes's upright=1.36 suggestion above. Removing that has fixed images, though they're undersized in comparison to the infobox by default now. I'm loathe to hardcode a larger default size for accessibility reasons. Chris Cunningham (user:thumperward) (talk) 15:58, 10 January 2013 (UTC)

C'mon now! Here the default image size should fit the box size, not the default thumbnail settings. It was OK a short time ago, but has been repeatedly messed with. Secondarywaltz (talk) 16:21, 10 January 2013 (UTC)

change "frameless" back to "300px" per the thread above. the image should not be by default 36 percent smaller than the box width. Frietjes (talk) 18:15, 10 January 2013 (UTC)

. . . and on and on. If the image inside the box is made the same size as the box it will stretch it. Try it! The image has to be at least 10px smaller to stop that happening. Secondarywaltz (talk) 20:09, 10 January 2013 (UTC)

Forcing 290px on the image (or indeed forcing any hard-coded size) is a bad idea accessibility-wise, and can also result in ugly upscaling if applied to an image smaller than that. Those are good reasons not to hardcode the image size. A slight padding if no size is specified is a minor price to pay in that regard IMO. Chris Cunningham (user:thumperward) (talk) 21:14, 10 January 2013 (UTC)

Although that is a valid argument, many station articles have used the default setting on the presumption that the image would fit the box width, as it had previously. Generally I will reset images within an article to the default thumbnail size, but poor quality low resolution images should never be used for the definitive view of any subject in an Infobox, except where it is for historical reasons, and then the settings allow the user to choose the appropriate size. Secondarywaltz (talk) 21:31, 10 January 2013 (UTC)

indeed, let's remember that it has been "frameless" for about 3 days, and that was changed was made without consensus. Frietjes (talk) 22:04, 10 January 2013 (UTC)

I've altered the default image size to 290px for the time being, but I'd like to continue the discussion as to why we're hard-coding this. Ideally we should only hard-code a larger default size in cases where there is demonstrable breakage, and we should work to correct articles which rely on hard-coded widths so as to remove this override in future. Chris Cunningham (user:thumperward) (talk) 11:05, 11 January 2013 (UTC)

An alternative would be to have a Bot insert "image_size = 290px" where the parameter has not a defined value, is missing completely or is larger than 290. That would create an image that fits the width of the Infobox without stretching it. This will work as long as the box width is not changed again, in which case the process would have to reset new values. The documentation should give updated information on what number creates an image that fills the Infobox and Users would then know the current "rules" here for images. Firstly confirm that the current default box width works and move forward from there. Secondarywaltz (talk) 15:08, 11 January 2013 (UTC)

Location map

Any thoughts on integrating with {{Location map}}? Ворот93 (talk) 12:37, 24 December 2012 (UTC)

• It's already supported via the map_locator field. Mackensen (talk) 21:45, 20 January 2013 (UTC)
  • yes, but how about having a |location_map= so you don't have to specify the coordinates twice (e.g., see Cotton Green railway station)? Frietjes (talk) 17:08, 4 April 2013 (UTC)
    • please make this change to the template, which will add support for |pushpin_map= to include a location map at the bottom of the template. this is superior to the current functionality, since it doesn't require specifying the coordinates twice. the syntax should be nearly identical to the syntax used by {{infobox settlement}}. Frietjes (talk) 16:30, 5 April 2013 (UTC)
      • I instead used the code and parameters used on {{Infobox building}} and other buildings and structures infobox templates. It has a different level of precision than settlements. Cheers. Zzyzx11 (talk) 10:47, 6 April 2013 (UTC)

McCune–Reischauer

Please could someone change transcription method McCune-Reischauer (with hyphen) to McCune–Reischauer (with ndash), per WP:NDASH, to match the title of the article. Colonies Chris (talk) 12:12, 7 January 2013 (UTC)

 Done, thanks. Chris Cunningham (user:thumperward) (talk) 13:55, 7 January 2013 (UTC)

Thanks. Colonies Chris (talk) 15:35, 7 January 2013 (UTC)

Station styles

How do you make it so that the red line at the bottom of the infobox at Omonoia station is under the station name and not right at the end? Thanks. --Marianian^(talk) 21:21, 2 March 2013 (UTC)

the best way to add both of these would be using a style template. however, the current style templates are not passed the line information, so in the current methodology, you would need to create a style for every combination of lines. the other problem with using this border method for indicating the lines is that you would not be able to add more than two lines for a station. what you probably want is the ability to add a list of stripes to the top or bottom of the title. I will see if I can hack something for now, but there is certainly a more elegant solution to this problem. say some sort of line1_colour =, line2_colour =, ... or similar. Frietjes (talk) 16:16, 3 March 2013 (UTC)

So now we have color stripes in {{{type}}}, color icons in {{{lines}}} and line color in {{{services}}}. In most places that is overkill, unless, as in this case, the station actually uses the stripes for line identification in its signage. The difference here is that the stripe usage is above the name - but that can be moved. I can see several places that this simple fix would be more useful and flexible than having mutiple styles, just to add stripes for different lines. It's what I have been looking for. Thanks. Secondarywaltz (talk) 19:47, 3 March 2013 (UTC)

In Athens, it's on the top for single stations and both sides for interchanges. That is quite fortunate because if Line 5 gets approved then we are then going to have a problem unless STASY S.A. (the operator) thinks about how to represent three-line interchanges! However, that's a long way off. --02:07, 4 March 2013 (UTC)

Alternate name

Is there a way for a station to have an alternate name listed? I ask specifically referring to Gare de Latour-de-Carol-Enveitg, which is in France but served by Spanish trains from Barcelona. On Spanish timetables (e.g. [2]) the Catalan name of La Tor de Querol-Enveig is used and so using this alternate name in the info box may be helpful.Travelpleb (talk) 10:31, 25 April 2013 (UTC)

This seems to be adequately explained in the article without the need for an additional parameter. Secondarywaltz (talk) 12:53, 25 April 2013 (UTC)

I notice that alternative names aren't some crazy new idea. Template:Infobox London station has them. I think alternative names would help, especially at border stations. Sometimes the names in different languages are completely different (e.g. Bayerisch Eisenstein/Železná Ruda-Alžbětín), so drawing attention to both in the infobox might be helpful. Travelpleb (talk) 14:27, 25 April 2013 (UTC)

In the |name=parameter, putting |name=NAME_A<br>NAME_B should work fine. There's no real need for an additional parameter, methinks. Pi.1415926535 (talk) 14:36, 25 April 2013 (UTC)

That does the job nicely. Thank you Pi.1415926535! Travelpleb (talk) 17:01, 25 April 2013 (UTC)

{{Infobox London station}} does indeed have the |alt_name= parameter, but that gets used very little except for cases such as Southall railway station. A better example is {{Infobox GB station}} where many stations in Wales and Scotland which have bilingual signage use the |other_name= parameter for the name in the non-English language: examples are Swansea railway station and Inverness railway station. --Redrose64 (talk) 17:05, 25 April 2013 (UTC)

I'm not sure why this template is forbidden from having alternate names. The fix suggested by Pi.1415926535 does achieve the desired effect visually, but I would have thought that a separate parameter would be tidier.Travelpleb (talk) 18:07, 25 April 2013 (UTC)

Putting two values in the |name= parameter is a horrible kludge, and corrupts the emitted metadata. A separate parameter would be far more preferable, If it must be done (or in the interim) please separate values using {{Plainlist}}, not a line break. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:37, 2 August 2013 (UTC)

The undocumented parameter {{{native_name}}} will work for most purposes. Secondarywaltz (talk) 15:46, 2 August 2013 (UTC)

Indeed, but the Spanish name of a station in France, as in this case, is not the "native" name Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:08, 3 August 2013 (UTC)

If the parameter was named {{{gobbledygook}}} would that be better? C'mon Andy! I said it "will work for most purposes". ... and talking about language, I never understood how we got four Korean specific parameters in this general infobox! Secondarywaltz (talk) 13:23, 3 August 2013 (UTC)

I agree about the Korean parameters. we should split those into an embedded {{Korean names}} template, or {{station names}}, or {{Infobox Korean name}} per {{film name}}. Frietjes (talk) 16:04, 3 August 2013 (UTC)

Adjustments requested

Label 10 shouldn't be "Lines" but should be | label10 = Line(s), not all stations have more than one line.

| label13 = Structure should be | label13 = Structure type, or create a new Station type label to remove the broad meaning (though I would prefer Station rather than Structure [since it's meaningless in Australia], since we have Ground or Underground stations).

| label28 = Code should be | label28 = Station code.

This would allow me to fix the articles using {{NSW TrainLink Station alt}} and {{Infobox Sydney Trains station}}. Bidgee (talk) 07:33, 28 July 2013 (UTC)

@Bidgee: I changed Line to Line(s) and Code to Station code. I also added |station_type=, but I am wondering isn't this redundant to |type=? Thanks! Plastikspork _―Œ^(talk) 12:29, 28 July 2013 (UTC)

• What else would "Code" be in "Infobox station" except "Station code"? That seems redundant as you would not prefix everything else in that manner, but that's OK. As used here {{{station_type}}} seems to be the same as {{{structure}}} as it refers to the type of construction of the station. Perhaps it is the label that needs to be modified. Displayed under the heading, {{{type}}} is interpreted as being the type of service and in many case is just redundant clutter. Another confusing parameter is {{{other}}} which displays with the label "Connections". Can this be changed to {{{connections}}}, with {{{other}}} being grandfathered in. The documentation will also need to be updated. Thank you for this. Sw2nd (talk) 14:30, 28 July 2013 (UTC)

  I added |connections= as an alternative to |other=, and changed the label. If |station_type= is now redundant, let me know, and I can remove that since it was very recently added. Thanks! Plastikspork _―Œ^(talk) 15:03, 28 July 2013 (UTC)

Thanks, but have to say that I simply cannot believe that Australians would not know that a "structure" is something constructed or built or in this context the type of construction or building. A general expression like that is used to allow some leeway in exactly what is entered under the parameter. The resulting display clarifies what is meant. If Australians feel more comfortable with structure being "Underground station", they can just enter that and allow others to expand the information to include things like architectural style etc. I await feedback from down under. Sw2nd (talk) 15:46, 28 July 2013 (UTC)

Location map overlay

Please make it possible to provide the overlay_image parameter of the embedded Template:Location map. It is currently used in many articles on Moscow Metro stations, and if adapting them to the new scheme, File:Moscow map MKAD metro line.svg disappears. Editing the code as follows would be enough:

 |alt     = {{{map_alt|}}}
 |overlay_image = {{{map_overlay|}}} <!-- line to be inserted -->
 |lat     = {{#if:{{{latm|}}}{{{latNS|}}}| | {{{latitude|{{{latd|}}}}}} }}

-- YLSS (talk) 11:32, 14 November 2013 (UTC)

Why not use {{Location map}} directly? See Amsterdam Centraal railway station for example. Secondarywaltz (talk) 15:31, 14 November 2013 (UTC)

Oh! I see you are trying that. Secondarywaltz (talk) 15:34, 14 November 2013 (UTC)

Nope, I don't; using map_type parameters etc. doesn't require proving coordinates twice. YLSS (talk) 16:42, 14 November 2013 (UTC)

Yes, I've always wondered about that potential conflict. Secondarywaltz (talk) 17:07, 14 November 2013 (UTC)

• Done. Cheers, LittleMountain5 17:23, 14 November 2013 (UTC)

Thanks, it works! YLSS (talk) 17:57, 14 November 2013 (UTC)

Accessible references or notes

The most important problem about the "accessible" parameter is that it just allows you to show an accessible icon but if you want to note (for example) accessible services are just available in one line, you can't. You can't also add a reference about the accessibility of the station, and it is very important to verify the information. I think a new parameter called "access_note" should be added on the template like in {{Infobox London station}}. In addition, another new parameter to note all accesses to the station should be added too because there are a lot of rapid transit systems, primarly in Europe, that doesn't have a street address like most of rapid transit systems in North America, and they have different accesses, which must be noted. For example this new parameter could be called "accesses" and you should note all accesses in a numbered list of parameters, for example: "access1", "access2", "access3", etc. Then the template would show a collapsible list with all entries to the station without have to type a street address. Mllturro (talk) 17:48, 3 February 2012 (UTC)

I would like to re-raise a question about adding notes for an "accessible" parameter. As for (at least) European subway stations it is a rather common situation when a transfer station has the same name on different lines. Usually, all of them are covered under the same Wiki article. But there can be a situation when only some of the same-name stations are accessible, while the others are not. It would be nice to reflect such facts in infobox, not only in the article. P h n (talk) 20:20, 22 January 2015 (UTC)

I would be very much in support of this as well; as many systems are upgrading for accessibility, this is a very common situation. Pi.1415926535 (talk) 22:16, 22 January 2015 (UTC)

Simple. Use the parameter {{{disabled}}} to add a note which will be displayed under the title "Disabled access". End of problem! Secondarywaltz (talk) 23:32, 22 January 2015 (UTC)

Spelling Correction Needed

• Change "Mumber of tracks at the station"
• To "Number of tracks at the station" Tabletop (talk) 11:42, 16 May 2014 (UTC)

Is there some reason that you cannot do this? --Redrose64 (talk) 18:42, 16 May 2014 (UTC)

What's the "code" parameter for?

Can I use it for the station's IATA code? If not, should there perhaps be an IATA_code parameter? TIA for reply. Jeh (talk) 08:31, 4 July 2014 (UTC)

The doc says "Agency station code (used on tickets/reservations, etc.)" --Redrose64 (talk) 11:11, 4 July 2014 (UTC)

Yes you can. There is no need for another parameter. See Union Station (Toronto) which has mutiple codes entered. The parameter is deliberately left vague to allow for some flexibility in its use. Secondarywaltz (talk) 13:52, 4 July 2014 (UTC)

Ok, thanks for the replies. Jeh (talk) 19:07, 4 July 2014 (UTC)

Former Services

Hi I'm looking at a lot of old stations in the U.S. and almost none of them have the former services listed below the current services. Even when they do they're normally not a complete list. I tried to add the former services using the tags but I can't seem to make it work. I get something like this:

{{s-start}}
{{s-note|text=Former services}}
{{s-rail-next|title=ACL}}
{{s-line|system=ACL|line=Southern Wind|previous=Candler|next=Kendrick}}
{{s-end}}

Can someone show me how to make these things? I would be very grateful. ThanksMonopoly31121993 (talk) 15:41, 5 July 2014 (UTC)

@Monopoly31121993: It depends partly on where the routebox is situated in the article, and partly upon the type of routebox. I can give a decent answer if I have examples of these stations that you're having difficulty with. --Redrose64 (talk) 16:48, 5 July 2014 (UTC)

Sure, I'm looking at Union Station (Montgomery, Alabama) which mentions in the article that it had services from the Louisville and Nashville Railroad, Atlantic Coast Line, Western Railway of Alabama, Seaboard Air Line, Central of Georgia, Gulf, Mobile and Ohio Railroad and Amtrak. The article specifically names one of the routes (the South Wind). An easier example might be Baltimore & Ohio Railroad Station, Philadelphia where I've already added one of the former services but I can't include more. E.g. I'd like to include their services like the Royal Blue (train) which continued to Jersey City Terminal Station and South to Washington D.C. Thanks for your help. I hope this is clear enough.Monopoly31121993 (talk) 16:58, 5 July 2014 (UTC)

OK, at Baltimore & Ohio Railroad Station, Philadelphia I see that there already is a routebox; it's held in the |services= parameter of the infobox - you would add the additional services immediately below - see for example Pennsylvania Station (New York City). But at Union Station (Montgomery, Alabama) I don't see any routebox at all: but in the same way, you would add it to |services= Try doing that. --Redrose64 (talk) 18:10, 5 July 2014 (UTC)

--User:Redrose64 would you mind adding the route to New York or Jersey City Terminal so I can see what you mean? Many thanksMonopoly31121993 (talk) 20:25, 5 July 2014 (UTC)

Sorry, but I don't know what you mean by "New York or Jersey City Terminal" - we don't have any articles named either New York Terminal, New York City Terminal or Jersey City Terminal or variations on that like New York Terminal railroad station. Even if I did know which article you meant, I don't know what you want adding to that. --Redrose64 (talk) 21:05, 5 July 2014 (UTC)

That's ok. Thanks for your help. I was looking for Central Railroad of New Jersey Terminal which had lots of former services for the Reading railraod, B&O Railroad and the Central Railroad of New Jersey. Currently none of them are linked there so I would like to add them but I don't know how.Monopoly31121993 (talk) 13:02, 6 July 2014 (UTC)

• None of those lines or stations or directions are defined in templates. You have to do that. Martin Morin (talk) 18:24, 5 July 2014 (UTC)

You should be asking people who edit ACL or those other former railroad articles, because it really has nothing to do with the Infobox. They will know more about succession templates for the defunct lines. Secondarywaltz (talk)

(User:Martin Morin) , I think you're correct but I have no idea how to create the templates. Are there instructions on how to create templates?Monopoly31121993 (talk) 20:21, 5 July 2014 (UTC)

That is why I suggested contacting users with knowledge of those railroads. The templates might already exist, but I don't know where, and they would be able to give you some direction. Note also that you may have the name wrong, because there is a South Wind (train) but no "Southern Wind". Try asking for help there. Secondarywaltz (talk) 21:07, 5 July 2014 (UTC)

Secondarywaltz, the problem with that is that it's not a very efficient stategy to track down a user for every railroad that existed prior to Amtrak. Do you know of any wiki pages that explain how to create a template?Monopoly31121993 (talk) 13:02, 6 July 2014 (UTC)

I said "The templates might already exist." In fact I'm sure that some of them do. The people who know will have worked on each of those railroads and will be able to guide you. Why don't you want to do one line at a time, with help from experienced editors, when you've never done this before? Secondarywaltz (talk) 16:33, 6 July 2014 (UTC)

It just seems like a lot of work checking the changes logs on pages until I find out who put those edits in there and then trying to get the editor to explain how they did it to me. I'm surprised there's no standard instructions on how to add those.Monopoly31121993 (talk) 20:02, 7 July 2014 (UTC)

You don't need to contact editors. Just leave the same messages as you put here on the talk page of the railway line and/or defunct railway company that you want to add information for. They will come. Secondarywaltz (talk) 20:09, 7 July 2014 (UTC)

Style parameter

What kind of information can be filled in this parameters?

|style =

Am asking in connection with articles related to Stations of Indian Railways, since different users/editors fill different type of information, mostly with [[Indian Railways]]. --βα£α(ᶀᶅᶖᵵᵶ) 13:47, 27 July 2014 (UTC)

@Balablitz: It's intended for the first part of the name of a template that contains CSS styling, for example, to use the styling information that is inside Template:Amtrak style, you would set |style=Amtrak. If you can give some examples of station pages, I can tell you just which template produces the styling, and what its effects are. --Redrose64 (talk) 14:20, 27 July 2014 (UTC)

@Redrose64: How about these stations: Solapur Junction railway station & Madgaon railway station. --βα£α(ᶀᶅᶖᵵᵶ) 14:31, 27 July 2014 (UTC)

Solapur Junction railway station has |style=Indian Railways, so it uses {{Indian Railways style}}. This contains code to return four different values; those used by {{infobox station}} are:

 | thbgcolor = {{Indian Railways color|}}
 | thcolor = FFFFFF

and these two values are used to set the colour of the headings in the infobox: white on blue. The blue comes from {{Indian Railways color}}, which is itself a template, containing the RGB hex triplet 191970 (red: 10%; green: 10%; blue: 44%)

Madgaon railway station has |style=Indian railways, so it uses {{Indian railways style}}, which doesn't exist, so the default colours are used for the headings in the infobox: black on pale grey. --Redrose64 (talk)

Whoa!!! I just randomly picked these stations and i saw the difference. Thanks for a very technical (for my level of knowledge) explanation, i got the point somehow. I'll deem it is a crucial info coming across, afresh, so far. I'd keep a tab on that parameter across India related station articles. --βα£α(ᶀᶅᶖᵵᵶ) 19:08, 27 July 2014 (UTC)

• The explanation of the style parameter is at Template:Infobox station#External style template. I just added a "see below" anchor link.[3] Any other suggestions to improve the documentation are welcome. Zzyzx11 (talk) 04:13, 28 July 2014 (UTC)

Thanks Zzyzx11. If possible |style=Indian Railways (Optional: {{Indian Railways style}}) may also be mentioned, since this could noticed easily while creating an station article and stressed while clean up. Because i still see that many users/editors, especially in Indian railway stations articles, skip parameters like |native_name= and |native_name_lang= despite incorporating native name in |name= parameter with break tag (<br>). Also for |type= parameter [[Indian Railways|Indian Railway]] station is used instead of rapid transit, light rail, tram, commuter rail and/or a regional rail station. --βα£α(ᶀᶅᶖᵵᵶ) 13:05, 28 July 2014 (UTC)

I think that linking to some of those for "type" is redundant because they are coverd fully in the article text. Minor terms should not be overlinked. Martin Morin (talk) 19:15, 28 July 2014 (UTC)

The skipping of other parameters reflects the larger, general problem of users/editors either not reading the template documentation entirely, or not copying every parameter from the blank template for others to see. In my experience, no additional material in the template documentation can solve that if they are not going to read it carefully in the first place. Also, the |type= parameter is suppose to list BOTH the system name and type of rail station, but I guess [[Indian Railways|Indian Railway]] railway station sounds redundant. Zzyzx11 (talk) 03:19, 29 July 2014 (UTC)

Parameters are available, depending on the situation, not mandatory. Martin Morin (talk) 12:01, 29 July 2014 (UTC)

Yes Zzyzx11, by skipping problems happens haplessly. Though i correct this infobox in station articles by mentioning in edit summary as "per template parameters", majority of the users/editors tend to ignore such things and go ahead with their own conscience.

Dear Martin Morin, i think w.r.t Indian rail and bus stations, the template parameters are more than enough and things cannot be left out as "not mandatory", because i deem this template as very encyclopedic, if not it wouldn't have been permanently protected --βα£α(ᶀᶅᶖᵵᵶ) 22:00, 29 July 2014 (UTC)

Korean names

The sub template for the Korean names is being transcluding regardless of the non-presence of the four fields related to that template. Not a huge deal but I saw somewhere the four fields had been edited out of an AU rail line because they were never needed. --Dave Rave (talk) 19:55, 9 August 2014 (UTC)

fixed. agree it's not a big deal, but I went ahead and fixed it anyway. Frietjes (talk) 15:38, 10 August 2014 (UTC)

there's two parts here, this didn't use to be a problem, but is, so something changed though not recently which is odd, so somewhere else.

Your fix refs hanga AND hangal, one or the other preferably by the coding. And there's other refs to the Korean at the top of the source, which I would think should be the transclusion point. But it IF THEN DO rather than IF THEN INCLUDE , needs re-writing, I can read the code, don't ask me to write it ;) --Dave Rave (talk) 00:28, 11 August 2014 (UTC)

@Dave Rave: I don't think I am following what you are saying. the four Korean parameters are |hangul=, |hanja=, |rr=, and |mr=. if all four are blank or not-specified, there should be nothing related to Korean name transcluded by the template. is there something I am missing? perhaps a specific example would help? Frietjes (talk) 15:06, 11 August 2014 (UTC)

I was misreading the | with the l|, and now it seems ok. I was adding a blank Infobox and the Korean was showing in the list of inclusions. Not now. O_o --Dave Rave (talk) 19:56, 11 August 2014 (UTC)

Width

Moved to Wikipedia:Village pump (technical)/Archive 131 § Coordinates display appears to be broken

 – That's where problems like this usually go --Redrose64 (talk) 15:01, 27 October 2014 (UTC)

In the sandbox I am attempting to make parameter coordinates_format refer to parameter format of {{Geobox coor}}. How can I do this? (It's not working right now) Jc86035 (talk • contributions) 05:48, 15 November 2014 (UTC)

There's something about parser functions like {{#if:}} that means that you can't pass name=value through as a pair - they need to go through separately, with the = on the outside. I made this change, based on how {{{coordinates_display|}}} is handled immediately after. --Redrose64 (talk) 14:04, 15 November 2014 (UTC)

Thanks for the help! Jc86035 (talk • contributions) 15:27, 15 November 2014 (UTC)

Edit request on 15 November 2014

Request to change

| data9 = {{#if:{{both|{{{latitude|{{{latd|}}}}}}|{{{longitude|{{{longd|}}}}}}}}| {{Geobox coor|{{{latitude|{{{latd|}}}}}}|{{{latm|}}}|{{{lats|}}}|{{{latNS|}}}|{{{longitude|{{{longd|}}}}}}|{{{longm|}}}|{{{longs|}}}|{{{longEW|}}}|type:railwaystation{{#if: {{{iso_region|}}}|_region:{{{iso_region}}}|{{#if:{{{country|}}}|_region:{{CountryAbbr|{{{country}}}|}}|}}}}|{{#if:{{{coordinates_display|}}}|title|μ}}={{{coordinates_display|}}}}}|{{{coordinates|}}}}}

to

| data9 = {{#if:{{both|{{{latitude|{{{latd|}}}}}}|{{{longitude|{{{longd|}}}}}}}}| {{Geobox coor|{{{latitude|{{{latd|}}}}}}|{{{latm|}}}|{{{lats|}}}|{{{latNS|}}}|{{{longitude|{{{longd|}}}}}}|{{{longm|}}}|{{{longs|}}}|{{{longEW|}}}|type:railwaystation{{#if: {{{iso_region|}}}|_region:{{{iso_region}}}|{{#if:{{{country|}}}|_region:{{CountryAbbr|{{{country}}}|}}|}}}}|{{#if:{{{coordinates_format|}}}|format|μ1}}={{{coordinates_format|}}}|{{#if:{{{coordinates_display|}}}|title|μ}}={{{coordinates_display|}}}}}|{{{coordinates|}}}}}

This is for using the format parameter of {{Geobox coor}} through a coordinates_format parameter. Jc86035 (talk • contributions) 15:27, 15 November 2014 (UTC)

done, although I may simplify it a bit in a moment. Frietjes (talk) 16:15, 15 November 2014 (UTC)

okay, I seem why it's somewhat complicated. the format parameter uses dec when format is missing, but may do something else if it's blank. still may be able to simplify? Frietjes (talk) 16:17, 15 November 2014 (UTC)

Thanks! Jc86035 (talk • contributions) 01:27, 16 November 2014 (UTC)

Edit request on 29 June 2014

| headerstyle = color: #{{#if:{{{style|}}}|{{{{{style|}}} style|thcolor|{{{style2|}}}}}|000000}}; background-color: #{{#if:{{{style|}}}|{{{{{style|}}} style|thbgcolor|{{{style2|}}}}}|efefef}}

Change to:
| headerstyle = color: #{{#if:{{{style|}}}|{{{{{style|}}} style|thcolor|{{{style2|}}}}}|000000}}; background-color: #{{#if:{{{style|}}}|{{{{{style|}}} style|thbgcolor|{{{style2|}}}}}|efefef}} {{#if:{{{style|}}}|{{{{{style|}}} style|thgradient|{{{style2|}}}}}|}}

This is for adding gradients to the section headers. Jc86035 (talk • contributions) 06:12, 29 June 2014 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. I would at least like to see a demonstration first, per WP:TESTCASES. Accordingly, please put your proposed change into Template:Infobox station/sandbox and demonstrate at Template:Infobox station/testcases. --Redrose64 (talk) 07:55, 29 June 2014 (UTC)

@Redrose64: I have modified the sandbox template with the suggested changes and put a different style containing the thgradient parameter into the infoboxes in testpages. Jc86035 (talk • contributions) 03:15, 30 June 2014 (UTC)

It wasn't displaying correctly in Internet Explorer 8. The style= attribute of the emitted HTML contained (newlines added after each semicolon for clarity):

text-align:center;
color: #FFFFFF; 
background-color: #AA0000 background-image: -moz-linear-gradient(top, #AA0000, #663333); 
background-image: -o-linear-gradient(top, #AA0000, #663333); 
background-image: -webkit-linear-gradient(top, #AA0000, #663333); 
background-image: linear-gradient(to bottom, #AA0000, #663333);
;

The IE 8 browser doesn't handle gradients, so it was ignoring the four declarations that include gradient information; unfortunately, a semicolon is missing, so background-color: #AA0000 background-image: -moz-linear-gradient(top, #AA0000, #663333); was being taken as a single declaration, not two. Since the background-color: property was being given an invalid value, it was ignored, with the result that the words "Other information" were appearing white on light grey: Other information - not very readable unless you drag your mouse over it. I fixed it by adding a semicolon. --Redrose64 (talk) 13:14, 30 June 2014 (UTC)

@Redrose64:, @Jc86035: This was re-activated here, presumably intentionally.

• There seems to be consensus (no one has objected in 6 months). Is the correct version in the sandbox? All the best: Rich Farmbrough, 23:50, 15 November 2014 (UTC).
  

To (partially) answer myself [4]] this diff shows the above request, and RedRose's fix have been implemented inthe [[Template:Infobox_station/sandbox|sandbox]. There is also a space removed before {{Geobox}} at line 33. All the best: Rich Farmbrough, 00:01, 16 November 2014 (UTC).

Done — Mr. Stradivarius ^{♪ talk ♪} 05:55, 17 November 2014 (UTC)

Thanks! Jc86035 (talk • contributions) 06:06, 17 November 2014 (UTC)

Edit request on 4 January 2015

| abovestyle = {{#if:{{{style|}}}|{{{{{style|}}} style|name_format}}}}

Change to:
| abovestyle = {{#if:{{{style|}}}|{{{{{style|}}} style|name_format|{{{style2|}}}}}}}

I'm not 100% sure about this, but it should enable It enables style pages that invoke or are modules (such as Template:Infobox MTR style) to work properly. Jc86035 (talk • contributions) 10:14, 4 January 2015 (UTC)

See the testcases page for an example (bottom two templates). Jc86035 (talk • contributions) 11:01, 4 January 2015 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. While it all seems to work okay, your demonstration there raises accessibility concerns for me as I can't read the text in the example with the multicolored background. I'm not convinced that adding the coloring style, which I assumes is suppose to match the stripped color pattern in the image is important enough to compromise the ability to read the words. Please discuss, if a consensus emerges that it is appropriate, then I'll happily make the change as needed. — {{U|Technical 13}} ^{(e • t • c)} 12:59, 4 January 2015 (UTC)

The main reason I requested this was because {{Infobox MTR}}, which uses {{Infobox station}}, is already using the module Module:HK-MTR stations for its styles, but through an unnecessary hack which introduces bad formatting. (This means that the header formatting has to be added three times.) It's used on, for example, Lai King Station and Fortress Hill Station. Jc86035 (talk • contributions) 13:41, 4 January 2015 (UTC)

I still oppose this change. Let's discuss it more and see if the community wants headers like this. The existing hacks that you mention might need to be removed. Either way, see WP:PER and please don't reactivate the template until discussion has concluded and a CONSENSUS is reached. Thank you. — {{U|Technical 13}} ^{(e • t • c)} 13:47, 4 January 2015 (UTC)

Note: The gradient has been removed. Jc86035 (talk • contributions) 14:38, 4 January 2015 (UTC)

• Okay, now the only difference I see between the two testcases is the choice of background color for the top, and surely this can be done already by adjusting the template call. Heck, both versions even use the same deprecated cellspacing parameter. How would this change improve the template? — {{U|Technical 13}} ^{(e • t • c)} 14:56, 4 January 2015 (UTC)

The reason that the template on the left has a yellow header is because it's the default/fallback for the module. This is because information that's supposed to be entered in the infobox so it can be passed through to the module (the station name, so the livery style of the particular station can be chosen) can't be placed without either the hack or a change in the infobox like I made this edit request for. I'm not sure what the cellspacing parameter is and I've never used a parameter named that before. Jc86035 (talk • contributions) 15:16, 4 January 2015 (UTC)

Note that the style2 parameter is already in place for the other parts of the template where information from style pages is used. Jc86035 (talk • contributions) 15:20, 4 January 2015 (UTC)

• Comment - Every station does not need an individual style. What MTR stations have is a reflection of the creator's interpretation of each station's design, rather than a corporate definition. Very much POV and OR wrapped into one. Secondarywaltz (talk) 15:27, 4 January 2015 (UTC)

Edit request on 25 January 2015

This code contains all the parameters necessary for merging {{Infobox Ireland station}}. [Edit: Merge discussion for the two affected templates is here. Jc86035 (talk • contributions) 14:52, 25 January 2015 (UTC)] However, I merged the parameters mainly from {{Infobox GB station}}, because while the two templates are very similar the UK one has been more consistently updated (the Ireland template doesn't have usage info parameters past 2006/07). (Features merged in no particular order include header symbols, external links to various UK government websites, events lists, detailed usage parameters year-over-year from 2002/03 to 2013/14, original company; pre-nationalization; pre-grouping; and post-grouping parameters, and Ordnance Survey grid reference. The tracking categories at the bottom of the templates have not been merged as I'm not really sure how that should be done.)

Please modify this if there are errors. Jc86035 (talk • contributions) 06:40, 25 January 2015 (UTC)

Note: See the examples at the testcases page. Note that the sections (and parts of sections, possibly the dates in the "Other information" section) may need to be rearranged. Jc86035 (talk • contributions) 07:39, 25 January 2015 (UTC)

Note 2: For assistance of subst:ing the template if the changes are accepted, this should replace {{Infobox Ireland station}} and {{Infobox Ireland disused station}}, and all instances should be reviewed after subst:ing. Jc86035 (talk • contributions) 10:39, 25 January 2015 (UTC)

Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Please don't paste the entire template into the talk page, it is not possible to either compare the code of the proposal with the code of the current version, nor is it possible to conduct side-by-side tests in order to demonstrate that the proposal is satisfactory: most importantly, that nothing will be lost or broken, but also that the appearance is acceptable - rows being in a suitable order, etc. --Redrose64 (talk) 14:46, 25 January 2015 (UTC)

I made the edits to the sandbox in parallel with editing the template text on the talk page, which is why I could use the testcases page to compare the templates. Sorry for putting the entire template text in the talk page; I didn't know I wasn't supposed to do that. Jc86035 (talk • contributions) 14:50, 25 January 2015 (UTC)

What you seem to be indicating here is that it would be better to merge {{Infobox Ireland station}} with {{Infobox GB station}}, as suggested in the discussion. The parameters are obviously the best match. Secondarywaltz (talk) 19:17, 25 January 2015 (UTC)

The merge discussion of the Ireland station infoboxes here indicates that the consensus is to merge them into this infobox. I see you contributed to the merge discussion but did not vote against merging Infobox Ireland station with this template. As the closing admin stated anything dealing with {{Infobox GB station}} should be dealt with in a separate TfD. Jc86035 (talk • contributions) 01:01, 26 January 2015 (UTC)

Did you read what I said? I said it was "suggested". You have said that the parameters fit better with the GB infobox, which parameters you want to use. WTF are you arguing about? You said it! Secondarywaltz (talk) 01:18, 26 January 2015 (UTC)

It was decided by consensus that the Ireland station infoboxes should be merged with this template; and unless that decision is voided somehow by another TfD someone is going to have to do that sometime, and preferably as soon as possible. The reasons I decided to import a few parameters from the GB infobox were that the GB template is kept [Edit: slightly more] updated [Edit: By this I mean that the usage parameters were updated to 2013/2014, there were more year-event pairs and other miscellany. Jc86035 (talk • contributions) 09:54, 26 January 2015 (UTC)], and some parameters are missing from the Ireland infobox that are showed as available on the infobox documentation.

I realize there are a few GB-specific features (such as the links to the UK government websites) that are also in the sandbox (which I've put in comments for now) but they can either be removed as necessary or kept to avoid having any more substantial changes if the GB infobox is merged in future (the closing admin of the merge discussion stated that "[t]he suggested alternative, merging to GB Station is in this discussion only explicitly supported by PC-XT, and only as a step on the way of doing a total merge into infobox station including the GB templates"). Also, if you don't like something I'm proposing to change you can modify the sandbox template yourself—no one's going to stop you. Jc86035 (talk • contributions) 09:50, 26 January 2015 (UTC)

@Jc86035: Please enable these GB-specific parameters in the sandbox, so that we can see - via testcases - how they would work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 26 January 2015 (UTC)

 Done @Pigsonthewing: Jc86035 (talk • contributions) 09:44, 27 January 2015 (UTC)

Thank you. As noted below, we probably don't need the navbox-style section. I'm confused buy the third option (labelled ".../sandbox2", but that's a red link) on the testcases page; where's that coming from? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:52, 27 January 2015 (UTC)

 Done @Jc86035: Thank you for your work on this; please update the documentation accordingly. This applies the consensus reached in the recent TfM discussion. There is nothing stopping the UK template from also being proposed for merger here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 26 January 2015 (UTC)

Now - that makes sense Andy! Secondarywaltz (talk) 16:53, 26 January 2015 (UTC)

• @Pigsonthewing and Jc86035: Was {{{gridref}}} rejected? It's not in the template. Alakzi (talk) 16:59, 16 March 2015 (UTC)