Wikipedia

Template talk:Infobox station/Archive 4

< Template talk:Infobox station
Latest comment: 2 years ago by John M Wolfson in topic Add "skip-stop" parameter
Archive 1Archive 2Archive 3Archive 4Archive 5

UK stations merge

Latest comment: 4 years ago189 comments14 people in discussion

Following a TfD on the merge of various UK stations templates, I've begun work on setting up wrappers for them to make sure we get everything useful in. ProcrastinatingReader (talk) 17:38, 1 August 2020 (UTC)

Wrappers:

Course, we need to make decisions on a few parameters/pieces of functionality, and some implementation details should be noted, so I figure I'll start a discussion here for continued input.

Missing parameters:

Merge notes

(for the sake of avoiding surprises and catching nitpicks)

  •   Done (using extra param for Foryd railway station) {{Infobox GB station}} supports 12 historical year/event entries, this template supports 11. No change required, since no templates are actually using the 12th.
    • {{Infobox UK disused station}} supports 16 of them, but only one uses more than 11 (it uses 12). We can move "Opened" to the proper opened param, then it'll only have 11, problem solved ;) -- so no additional history params required here either. edit: added a years12/events12 param to account for the usage at Foryd railway station
  • {{Infobox GB station}} supports an "other name". According to the documentation this is meant to be used for "Welsh/Gaelic/etc" names, these cases we can safely map to native_lang (with some format adjustments, and bot can interpret the template used to fill in native_name_lang), but de facto this param is 'abused' to use a literal other name (in English) for stations (eg at Newcastle railway station). These alternate names should probably be removed by hand, but there's no harm to just carrying them over and having them be fixed later. It would be improper use, of course.
  • {{Infobox GB station}} has two place parameters, |locale= and |borough=. The testcase merges this into borough, per documentation here. In many cases, the values are awfully similar (eg see testcase for Manchester Piccadilly), so I'm not sure why the values are duplicated. Ideally, one value should probably be trimmed, since it looks clumsy. (e:) For the sake of merge, they're just combined into |borough= as comma-separated, as is typically done in this template.
  •   Done {{Infobox GB station}} has an extra 'passengers' value for 'interchange' numbers. These rows are prefixed with "– Interchange", and often repeated per year entry. We'd need to add support to {{Rail pass box}} to retain custom labels to keep these, although it does beg the question, do we need interchange figures in the infobox?
  • The designation grade is given as a wikilink (eg [[Grade II listed]]). Bot will need to strip these into valid values for {{Infobox designation list}} - trivial find/replace.
    •   Done (in template in the meantime)
  • Usages of these templates often give the opening date as a year/event value, rather than use their own start param. Not a problem, a simple map will retain the view as exists, but for proper usage of this template those values should be remapped. A bot could do this pretty easily, by checking if |events= (ie events1) contains "Opened", but eh. Striking from merge, can be discussed later if need be.
    • Retain usage of events for disused stations, per Redrose below, but active stations should probably start using opened (eg it's confusing Google)–most don't have multiple openings.
  • These templates link to external boxes to enumerate letters for UK railway stations. We can still support this using embedding, probably, but I believe TfD consensus was going towards it not being necessary, so perhaps it should just be omitted?
  •   Done (in template) {{Infobox GB station}} has interesting functionality for tracking categories where passenger numbers aren't updated for a year. Effectively just: {{#if:{{{usage1415|}}}{{{lowusage1415|}}}||[[Category:UK stations without latest usage statistics 1415]]}}{{#if:{{{usage1516|}}}{{{lowusage1516|}}}||[[Category:UK stations without latest usage statistics 1516]]}}{{#if:{{{usage1617|}}}{{{lowusage1617|}}}||[[Category:UK stations without latest usage statistics 1617]]}} -- I'm not yet sure how/if we want to replicate this. There are a number of ways to do this, should we wish to keep it, ranging from luaification to bot runs.
  • Testcase note: Passenger lists are not complete. I haven't added every single mapping for the years yet. For a better idea of how it'll look, look at the Manchester Piccadilly testcase, which has more rows filled.
  •   Later (can be discussed after merge) Infobox structure: See testcase for GB infobox, mainly the differences between the two in terms of headers and how labels are 'categorised'. Can/should we organise the labels differently in this template? That template seems to structure better (eg into location, operated, etc)? Effects on other countries' templates should be considered.
  • Passenger values: That template manually does {{increase}}, whereas this template uses {{Rail pass box}} which prefers |pass_percent= (and calculates up/down based on if %>0). Ideally, over time and for newer years, articles supply the percentages instead.

Discussion

Regarding passenger numbers, many articles will have data going back to 04ish, but with anything before the last five years commented out. There have been discussions in the past about some sort of chart, but no one could quite work out how it should be displayed. Also of note that some stations which are now closed may have stats but for 10 years ago. -mattbuck (Talk) 19:21, 1 August 2020 (UTC)

I have some questions on the "merge notes" above.
  1. Please do not move "Opened" to 'the proper opened param', we have been trying to go the opposite way for some time - moving them to the initial year/event pair. Having a dedicated "Opened" parameter is OK if a station opened once, has stayed open ever since and kept its name throughout, but if it was ever closed and reopened, or was renamed at some point, it is desirable to have consistent presentation.
  2. On no account should locale and borough be conflated. They have different purposes, and there are comparatively few cases where they hold similar values.
  3. These templates link to external boxes to enumerate letters for UK railway stations - what external boxes are these?
--Redrose64 🌹 (talk) 23:14, 1 August 2020 (UTC)
  1. Noted
  2. I believe this template (and its usages) often combines city+province fields in |borough= with a comma (eg see example in doc). See current testcase for the quick implementation of that currently.
  3. Bottom of the infobox, the A-Z row with links to UK railway stations
ProcrastinatingReader (talk) 23:34, 1 August 2020 (UTC)
Just a comment, but I see "Operated by" in the new infobox, and that's a bit of an iffy word in UK railways as the train operator is not always the company which manages the station. -mattbuck (Talk) 10:09, 2 August 2020 (UTC)
There's a separate parameter, train_operators, that reflects that distinction. Mackensen (talk) 12:16, 2 August 2020 (UTC)
My point is that saying Network Rail "operate" a station is problematic. -mattbuck (Talk) 15:25, 2 August 2020 (UTC)
Mattbuck, what exactly do they do in their "managing a station" capacity? Do they only 'manage' some railway stations, or do they manage all UK railway stations? Reading [article] they own a number which are operated by train operators, and operate 20 directly? ProcrastinatingReader (talk) 13:08, 29 August 2020 (UTC)
ProcrastinatingReader, Network Rail own pretty much every station in the UK (excepting a few specialist ones like Heathrow Terminal 5). They manage (as in staff, let shops etc) a few specific big stations, they do not however run any trains, instead this is done by a train operating company (TOC). TOCs manage most stations, and maintain them in concert with Network Rail - I think that it's something like floor level to 8ft above is the station manager, everything else (including track, signals, bridges, etc) is Network Rail. -mattbuck (Talk) 15:45, 29 August 2020 (UTC)
Mattbuck, they only operate 20 stations though, right?[1] If so, for these 20, isn't it accurate to use "Operated by"? (for the rest, it wouldn't be of course, and I don't think it is shown on most currently, because it's a bit redundant to put "owned by" National Rail on each one). ProcrastinatingReader (talk) 15:48, 29 August 2020 (UTC)
ProcrastinatingReader, for me the problem is terminology. The "operator" of a station to me might be a train operating company which runs trains from it - one of many - while saying the station is managed by is the specific company who are responsible for that station. -mattbuck (Talk) 16:01, 29 August 2020 (UTC)
Mattbuck, that part I get. Let me try rephrase what I'm getting at: Network Rail do operate 20 stations, right? The rest are operated by the TOCs. So for those 20, is saying "Operated by: Network Rail" a problem? Seems accurate to me? For the others that aren't part of this 20, Network Rail shouldn't be in the infobox at all imo, it's redundant to say for each rail station in the UK that it's owned by Network Rail. ProcrastinatingReader (talk) 13:04, 30 August 2020 (UTC)
ProcrastinatingReader, there are some stations not owned by Network Rail, but not many. If we are using "Operated by" to mean "managed by" then we also run into places like Burton-on-Trent, where the only TOC is CrossCountry, but the station is managed by East Midlands Railway. Again, I just don't like the term "operated" as it means something specific in a UK context. -mattbuck (Talk) 21:01, 1 September 2020 (UTC)
Gotcha. Sounds good to me. I'm happy to add the parameter if no other objections. Caution should be advised, however, as whilst this usage may be more clear for UK usage, it could be misinterpreted more globally (likewise, it could have valid uses globally, too). We need clear definitions for the "Operated by" and (new) "Managed by" params to prevent misuse. ProcrastinatingReader (talk) 21:05, 1 September 2020 (UTC)
"Operated by" in a UK context is the organisation responsible for the day-to-day management of the station building and facilities (platforms, bridges, information posters, PA system, etc. not the track or signals). This is most commonly the train operating company that runs the majority of the services to the station but might also be a different TOC (e.g. Burton on Trent), Network Rail (e.g. London Paddington), London Underground (e.g. Queen's Park), a PTE, some other organisation (e.g. Heathrow Terminal 5, Corfe Castle) or multiple organisations (e.g. Liverpool Lime Street). That the term means something different elsewhere in the world is another example of the unnecessary problems caused by trying to shoehorn a template designed for the UK's idiosyncratic rail network into a generic one. Thryduulf (talk) 12:34, 3 September 2020 (UTC)
I aim to please.   Done. ProcrastinatingReader (talk) 13:04, 12 September 2020 (UTC)

Let me just say that I'm not all that satisfied with how passengers are presently implemented (see above discussion); if a wholesale refactoring is necessary to properly integrate the GB passenger data then I'm all for it. Mackensen (talk) 13:07, 2 August 2020 (UTC)

A locale is not necessarily a city, it might be a hamlet, village or town; it might be a named part of a town or city. It should be wikilinked, but need not be.
A borough is not a province. The correct use of the |borough= parameter is described at both Template:Infobox GB station#Syntax and at Template:Infobox UK disused station#Example.
Concatenating these two - even with a comma - is not helpful. --Redrose64 🌹 (talk) 08:29, 3 August 2020 (UTC)

A few thoughts from the merge notes not yet addressed - open and disused stations need to present data in the same way for consistency. Interchange numbers do need to remain in infoboxes as the entry/exit figures alone present a misleading view of the use of some stations (e.g. Clapham Junction, Dovey Junction and Birmingham New Street). Thryduulf (talk) 01:58, 1 September 2020 (UTC)

Thryduulf, does it matter that much, keeping open and disused stations consistent, when they're not even consistent amongst each other in how they show the opened date? Opened stations use events params instead of |opened=. On some articles like Haymarket railway station it just looks worse than using "Opened: 1842" (label: value) in my eyes. It's not consistent with other articles, some which have the label as the date (like Bramley railway station (Hampshire)), with a varying value. Others use "Opened" as the label. It looks like Google is actually extracting data from the infoboxes. Sometimes it can parse it, so it uses the "Opened" label in sync with its own opened val, other times it can't tell that it's the opened so it uses the date as a label (eg "Hunts Cross station"), and sometimes it can't make sense of the input at all. Admittedly, it's less work for me to keep it as-is, so I'm going to strike it from the merge and keep it as-is (noting it can still be addressed later if consensus dictates it's an issue), but I do think it's problematic. ProcrastinatingReader (talk) 19:02, 1 September 2020 (UTC)
Neither {{Infobox GB station}} nor {{Infobox UK disused station}} provide an |opened= parameter (it is tested for, in order to detect unusual parameter usage, but is not displayed). They do have |start=/|end=, but these are really only there to provide an easy change from |starting= when a proposed station gets opened for real. We have been trying to move away from start/end parameters towards |yearsn=/|eventsn= because these are much more flexible. This has been taking some time, on account of the sheer number of stations - there are 2,500 open stations and many times more that are disused, and also because in each case the data needs to be checked to ensure that it's not a rogue value. --Redrose64 🌹 (talk) 06:54, 2 September 2020 (UTC)

Native name

"Native name" is not an appropriate mapping for "other name", neither English nor Welsh names for a station in Wales are more or less "native" than the other, and using it for the Punjabi name at Southall railway station would be actively misleading. Thryduulf (talk) 10:22, 3 August 2020 (UTC)

I think 'native' should be considered more loosely than that. I don't think it's inappropriate for a Welsh name of a station. For Southall railway station, yes, if that's not an official name it would probably be misleading. But in terms of visible output it looks pretty much the same, so it's mostly a semantic difference in how the parameter is named. I don't think adding a second |other_name= to show up there is a good idea - it's only going to conflate the two and cause them to be misused, as is often seen with templates. It's also feels a little vague. For Southall, I think the appropriate usage might be to move it into the infobox's "Other names", but a bot can't really tell the difference between conflated official and unofficial other names. ProcrastinatingReader (talk) 10:33, 3 August 2020 (UTC)
More parameters leading to inappropriate use, misuse and added confusion was exactly why many of us argued against this merge. To then use those same arguments as reason why the merged template cannot have the same functionality as the ones it is replacing seems rather disingenuous. Thryduulf (talk) 10:44, 3 August 2020 (UTC)
imv, I don't think it's necessarily more parameters that leads to misuse, I feel it's broadly named parameters that does. The official name of the station, and the unofficial but commonly used name by a local community, should not really be conflated into the same parameter in my view (regardless of languages or if it's just an alternate colloquial name in the same language). There's no loss of functionality indicated w.r.t. |other_name=, display output is pretty much the same. Unless having to instead use the parameter name "native_name" is a loss of functionality, but I personally feel the distinction is helpful? ProcrastinatingReader (talk) 10:55, 3 August 2020 (UTC)
We don't specify "the unofficial but commonly used name by a local community". We specify only that name (or those names) that are actually shown on the station's nameboards. In Wales, some stations (e.g. Bangor) have the same name in both English and Welsh, so their nameboards show the name once only; but most stations have two names on the same board: a green one in Welsh, and a black one in English - even if the spelling difference is slight (e.g. Treforest; nameboard). When there are two, which one is official? Answer: both of them are used by the railway, therefore both must be equally official. So we show both in the article - we have absolutely no reason to deny recognition to one of them. --Redrose64 🌹 (talk) 15:39, 3 August 2020 (UTC)
Those are mapped to native_name, which is shown at the same place as {{Infobox GB station}}. So for Treforest, for example, it would look like [2]. Obviously some work to the layout would be beneficial, but it follows the same idea. ProcrastinatingReader (talk) 16:34, 3 August 2020 (UTC)
The point here is semantic: Use of "Native name" for Welsh implies that the English name is not equally native in the same way that Qom railway station and ايستگاه راه آهن قم are not equal and as already noted it is also completely wrong for stations like Southall. Remember that our structured data will be used semantically by Wikidata and other projects (not all WMF) so its important to get it right. I also note that the important note regarding the passenger usage figures is missing and that comments about the difference between a station being managed by X and operated by X have not been addressed so far. Thryduulf (talk) 12:55, 10 August 2020 (UTC)

PTE

What's our consensus on the two extra parameters? The discussion in the TfD was headed towards implementing PTE somehow, and scrapping gridref? Ideas on implementing PTE nicely? (ping @Mackensen ProcrastinatingReader (talk) 09:33, 9 August 2020 (UTC)

I am against the removal of any existing functionality, particularly gridref. --Redrose64 🌹 (talk) 16:34, 9 August 2020 (UTC)
I'm going to restate what I said during the discussion: gridref appears to get turned into another coordinate link that gets routed through toolforge. I appreciate that Ordnance Survey National Grid is its own thing, but from the end-user's perspective the end result is the same, except the level of specificity differs. I'm not sure it makes sense to have both. Regarding PTE, I'm unsure. This sounds similar but different from Swiss Tarifverbands, which get linked in through zones or otherwise not mentioned. I don't believe anyone, pace Redrose64 (talk · contribs), proposes a loss of functionality. Infobox station already supports the display of coordinates; it's not clear why we would need two methods, with differing levels of precision. Regarding PTE, I'm unsure. What are these bodies? How do they compare to bodies in other countries? Are they like Swiss Tarifverbands? US commuter agencies? The RER networks in France? The various sub-national operators in Italy? Clarity would be helpful. Mackensen (talk) 17:24, 9 August 2020 (UTC)
I'm sure I've explained this before. A PTE (Passenger Transport Executive) is a body with responsibility for coordinating bus, rail and tram transport, as well as other functions, in seven of the larger metropolitan areas of England and Scotland, except for London (where TfL functions very much like a PTE but with extra responsibilities). They were set up between 1969 and 1974, and occasionally enlarged. --Redrose64 🌹 (talk) 20:34, 9 August 2020 (UTC)
That's pretty close to the Swiss concept of the Tarifverband. Do I understand correctly that there's no direct connection between the station and the PTE? Mackensen (talk) 22:20, 9 August 2020 (UTC)
The PTEs propose and fund new stations, and fund refurbishment of existing stations. But the day-to-day running of the stations is carried out by the train operating companies. --Redrose64 🌹 (talk) 23:01, 9 August 2020 (UTC)
PTEs can also be involved with route/network and station branding, publicity and (to a certain extent) with fares (e.g. rover tickets) so they are often visible to the passenger, especially where they also have involvement with other passenger transport (buses, trams, ferries). Its important functionality to have, but whether they are directly comparable to anything in other countries I don't know - please link to the relevant articles or other information about them so that we can actually do the research (which should have been done before a merge was proposed by the way), but most things related to public transport in the UK correlate poorly to equivalents in other countries. Certainly they are different to RER networks. As for grid references, these are only the same as coordinates from an end users point of view if 100% of their use comes from people clicking on them to be taken to mapping services via toolforge - which sounds very unlikely so unless you have evidence of this I'm going to agree with Redrose64 that removal would be a loss of functionality. Thryduulf (talk) 12:42, 10 August 2020 (UTC)
A PTE sounds a good deal like a Transit district, which is pretty close to the Swiss concept. I think a general-purpose transit district field would make sense, in the same part of the template as zone. Mackensen (talk) 16:06, 10 August 2020 (UTC)
While a PTE is similar to a transit district in some respects, the article strongly implies that the key feature of a transit district is that it controls and operates public transport. In the UK, only Transport for London (which is technically not a PTE) meets this definition. Thryduulf (talk) 22:25, 10 August 2020 (UTC)
I find Passenger_transport_executive#Similar_authorities an interesting section. With the caveat that I am not an expert on transport organization, my impression is that most countries (even us backward folk here stateside) have created something along these lines. The German article (Verkehrsverbund [de]) is much more comprehensive. Mackensen (talk) 22:34, 10 August 2020 (UTC)
Thryduulf, out of curiosity, what's the difference between TfL and the PTEs? As in, legally, why isn't TfL just a PTE? Does it have powers that PTEs don't, or is it just a legacy thing? ProcrastinatingReader (talk) 12:45, 11 August 2020 (UTC)
The simple answer is that TfL does a lot more than PTEs do. It's a sui generis organisation that's legally a special purpose local authority, meaning it operates under different legislation and has more responsibilities. It specifies and (directly or indirectly) operates almost all local public transport in the Greater London Area and has involvement (to varying degrees) with cross-border local public transport and some long distance public transport, and controls advertising on local public transport. It is also a roads authority and the licensing body for taxis, private hire and river services operators. Thryduulf (talk) 13:12, 11 August 2020 (UTC)
I see, interesting. Regarding the parameter itself, I have two ideas:
  1. Just use "transit authority". De facto, that's what the PTEs are, kinda, even if they're named somewhat differently? Obviously there's power/authority differences, but I imagine the same applies for transit authorities worldwide (some will be named slightly differently, have different scopes, etc.)
  2. Use a template check to support both. Effectively, if the country param is GB/UK, and the transit authority param value is one of the PTEs, (eg value is "Greater Manchester") it'll show the label "PTE" instead. ProcrastinatingReader (talk) 14:22, 11 August 2020 (UTC)
  1. More parameters and so more work to maintain and more complicated for users (i.e. exactly the opposite of the alleged benefits of a merge), but the only solution that I think works for all cases would be to have a "transit_authority" parameter and a "transit_authority_type" parameter, the latter accepting defined values only and defaulting to "Transit authority" if unspecified or an unrecognised value (with the latter showing an error on preview). Thryduulf (talk) 14:42, 11 August 2020 (UTC)
    It rather does the opposite. Insisting on maintaining what amounts a parallel module because of one parameter seems hard to justify on its face, especially when it would support other, similar concepts in other countries. Seems like everyone benefits. Mackensen (talk) 19:51, 11 August 2020 (UTC)
    But the point is that there would be no need for a module in the first place as a single parameter with a hardcoded label would be all that would be required - zero maintenance requirement and nice and easy for users. Thryduulf (talk) 21:08, 11 August 2020 (UTC)

PTE (2)

I'm going to split this out for readability. We've determined in the above discussion that a PTE is something of a transit district/transit authority/tarifverband, but does not fit neatly into any of those categories. Indeed, the implementation of such organizations varies from country to country. In addition, the infobox doesn't currently support that concept, though such information is often brought it via the zone parameter. Thryduulf suggested having separate parameters for the transit authority and its type (which would override the default label), and I think that makes a good deal of sense. I'm not too concerned about usability; realistically this is a parameter that is set once and never changed. A reasonable default would be Transit district, with an override available for PTE to start, and other country-specific systems as the need arises. Mackensen (talk) 22:01, 11 August 2020 (UTC)

Working example at Template:Infobox_station/testcases#Duddeston. One immediate issue: I don't know if this comes up in Great Britain, but in Switzerland overlapping zones are common. Mackensen (talk) 22:20, 11 August 2020 (UTC)

I suppose you can have a fare zone without a PTE, so I don't think using a header would work consistently? I think a label might work best.
@Thryduulf: to clarify my two suggestions above, I was going for either:
  1. One label for "transit authority". Don't use "PTE" in infobox at all. De facto, the PTEs appear to be transit authorities. If we think about this more broadly, globally, transit authorities in various countries will have different names, responsibilities and scopes. I don't really see the need to make the PTE distinction in the infobox, personally. After all, they do seem to be "transit authorities" when considered broadly. OR
  2. If we are to retain the PTE label, have the template decide when to use it automatically. i.e. if |transit_authority= = "Greater Manchester" for example, the template automatically changes the label name from "Transit authority" to "PTE". Since there are only 6 PTEs, this isn't infeasible to do in a template. I'm not a fan of making a |transit_authority_type=. Params can be misused (see the massive numbers of articles in infobox tracking categories). If something can be misused in a template, it almost certainly will be. Soon we'd be seeing Swiss railway stations as PTEs in the infobox. The template can automatically have a switch for the 6 PTEs and change the label based on that automatically.
In my view these are the two best options from a technical standpoint, and accommodate for both the "no PTE" and the "PTE" viewpoints. Again, in both cases there is just one parameter (the PTE switch is entirely behind the scenes in the case of option 2). From a reader standpoint I personally prefer option 1, but the four of you know trains far better than I do so I defer to your expertise. ProcrastinatingReader (talk) 10:57, 12 August 2020 (UTC)
A few different versions in the sandbox (edit source and preview Template:Infobox station/testcases):
Thoughts? Any of these options desirable? ProcrastinatingReader (talk) 21:58, 15 August 2020 (UTC)
I can't see any examples using the formats at those links? Thryduulf (talk) 01:48, 1 September 2020 (UTC)

Gridref

discussion on gridrefs, plus Special:Diff/972003302 and Special:Diff/972148227, split from PTE section above. ProcrastinatingReader (talk) 13:49, 22 August 2020 (UTC)

What is the point of the grid reference? I get that in principle you could look it up on an OS map, but you could do that with the coordinates. What benefit does the grid reference provide? -mattbuck (Talk) 14:56, 10 August 2020 (UTC)

I already explained this. On an OS map, gridrefs are much easier to use than lat/long. --Redrose64 🌹 (talk) 17:44, 10 August 2020 (UTC)
I just don't see why that's helpful. If we really need conversion between grid refs and lat/long, is not the solution for the geohack page to calculate the grid reference? We also don't put the station's postal address in the infobox, nor the three words reference, despite both being ways to describe a location. -mattbuck (Talk) 15:59, 11 August 2020 (UTC)
The geohack page does display a grid ref, it's to one metre accuracy (which is perhaps misleadingly accurate). Here's how I use them. Let's say I'm writing an article for a closed station. I get an old OS map which shows the station, and then I use this method for obtaining the grid ref (to 100 metre accuracy, good enough for a station). Then I put it in the |gridref= parameter - job done. It's very easy, because all I need is a map and ruler - I don't need to make any calculations, or compensate for the difference between one degree of latitude being a greater linear measure than one degree of longitude. --Redrose64 🌹 (talk) 18:33, 11 August 2020 (UTC)
I'm glad it's easy to enter, but I still don't see what benefit it gives that the latitude and longitude don't already provide. I think coordinates are a lot more comprehensible than the grid reference. -mattbuck (Talk) 20:18, 11 August 2020 (UTC)
For many people, grid references are far more comprehensible than coordinates - especially given that the latter don't appear on paper maps. "NZ 318 037" to me is much easier to remember than "54.428550 -1.5102218" and would be very significantly easier for me to use to find that point using a paper map. Thryduulf (talk) 21:06, 11 August 2020 (UTC)
This is not a paper encyclopaedia. If you want to know where something is, click the link to take you to Bing Maps. -mattbuck (Talk) 06:21, 12 August 2020 (UTC)
What is the advantage to requiring people to click a link to be taken to another page where they will find what they are looking for in a sea of information they are not looking for (and knowing that they have to do this) vs presenting the information cleanly in a logical place right where they are looking? I cannot think of a single advantage to that approach, particularly as that information has been presented in the obvious way for many years. Remember we are supposed to be serving the reader not doing things solely for the convenience of editors and especially not for the convenience of template maintainers. Also your argument would apply equally to all location information other than coordinates. Thryduulf (talk) 09:27, 12 August 2020 (UTC)
@Mattbuck: You've got me the wrong way around. I'm not some tourist who is curious about something they've stumbled across when surfing the web. I write the station articles, for which I need to enter the position of the station. Accordingly, I find the station on a map, I work out the grid ref, I enter it. I have started dozens more articles for closed stations than open stations, and Bing is useless for a closed station where the site has been redeveloped. --Redrose64 🌹 (talk) 19:53, 12 August 2020 (UTC)
Redrose64, are you able to look it up using gridref as you do currently, then use some kind of site to find the coordinates? The display of gridref should really be useful for readers to be kept. ProcrastinatingReader (talk) 15:30, 24 August 2020 (UTC)
It is useful to readers who want to look up things on paper maps they have (e.g. to visit the site) or who understand grid references more than coordinates. I dealt with grid references every day in a former job and so could place a grid reference approximately within the area I dealt with (Somerset Levels) much easier than coordinates which we didn't use. Don't conflate your lack of understanding of the utility with a lack of utility. Thryduulf (talk) 01:46, 1 September 2020 (UTC)
It is also useful to readers who want to use the National Library of Scotland's NLoS Find maps by place repository of old OS maps: a grid ref takes you to the specific location whereas finding by name is fraught at times. --John Maynard Friedman (talk) 09:08, 1 September 2020 (UTC)

It seems a useful addition to the generic template in any case. My Garmin GPS receiver has British, Dutch, Hungarian, Estonian, Finnish, German, Icelandic, Indonesian (three), India (10), Irish, Latvian, MGRS, NZ, ONG, Swedish, SA, Swiss, Taiwan, US, UTM, Malaysian. --John Maynard Friedman (talk) 08:57, 1 September 2020 (UTC)

Thoughts Mattbuck & Mackensen? ProcrastinatingReader (talk) 18:51, 1 September 2020 (UTC)
ProcrastinatingReader, I still don't see the point personally, but if others want it then fine. -mattbuck (Talk) 20:57, 1 September 2020 (UTC)

Cleaning up GB station

I think gridref is the only remaining issue for {{Infobox GB station/sandbox}} (see testcases)? At least for a wrapper sync. May re-evaluate borough per above, but as I don't plan to make a bot run to replace yet the param isn't going anywhere. Participants: is there anything I've forgotten about?

Regarding gridref, really not sure what to do about it. My reading of the above discussion together with TfD puts it at a tossup, so I'd like more participation honestly, as I don't want to make any judgement on it myself. May ask at {{Infobox settlement}} for thoughts. ProcrastinatingReader (talk) 21:04, 19 September 2020 (UTC)

It looks like |gridref= is a "no consensus" above and at the TFD, which (I think) means that we include it in the wrapper as part of the status quo. If someone wants to start a separate discussion about it later, they can do so. – Jonesey95 (talk) 00:01, 20 September 2020 (UTC)
Implemented as params for generic regional grid references. Any remaining issues on {{Infobox GB station/sandbox}}? ProcrastinatingReader (talk) 15:55, 21 September 2020 (UTC)
{{Infobox UK heritage station}} should also be ready. ProcrastinatingReader (talk) 16:06, 21 September 2020 (UTC)
Synced {{Infobox GB station}}. Little more to do on the other two, mainly in terms of tracking categories and adding in a decade of passenger years to disused. Let me know if any issues crop up. ProcrastinatingReader (talk) 04:34, 28 September 2020 (UTC)
Where was this edit signed off as good to go? --Redrose64 🌹 (talk) 12:32, 28 September 2020 (UTC)
It obviously wasn't good to go as it removed functionality, see the template talk page. I have reverted that change until it is corrected. David Biddulph (talk) 09:17, 29 September 2020 (UTC)
To be clear, your complaint is A change on 28 September has apparently deleted some of the functionality, such as the links to "Live arrivals/departures, station information and onward connections from National Rail Enquiries"? This has been mentioned since the first of August in this discussion, Redrose requested clarification and afterwards raised no objections. It has been slated for removal since, for two months with no objections raised. When it was mentioned in the TfD, it was mentioned in the context of removal as non-infobox material. Indeed, it is not infobox material. The change made was entirely in process, with issues having been discussed for months, in the sandbox for months, and completion signalled above without response for a week. All parameter functionality has been implemented, and further functionality the WikiProject didn't even request, so I don't really know what the issue here is? ProcrastinatingReader (talk) 11:33, 29 September 2020 (UTC)
I see no mention in this discussion (between 1 August and now) of the proposed removal of that functionality. Perhaps you can give us a specific diff to the relevant part of the discussion? David Biddulph (talk) 12:19, 29 September 2020 (UTC)
I would’ve considered it part of the extra lists/text personally. If that was unclear, I did say above after signalling completion if Any remaining issues on {{Infobox GB station/sandbox}}? —- and no issues were raised. ProcrastinatingReader (talk) 14:12, 29 September 2020 (UTC)
Yes, I requested clarification, and the scanty answers that were forthcoming were in no way satisfactory.
I asked that no functionality be lost: but clearly, it has.
There are several reasons that I "raised no objections".
  • Every time that I try to do so, I start editing a post, but get so angry about what is happening here that I back out without saving.
  • Because you still have not provided satisfactory answers to my earlier questions (which I asked on at least three occasions) so I feel that until those are answered, there is little point in asking further questions.
  • Because I feel that whatever I say, you will ignore me and push through your desired changes regardless. Clearly, since nobody other than you has agreed to the proposed changes, this is exactly what you intended would happen.
There, I've written it now, and am angry again; so block me for NPA. --Redrose64 🌹 (talk) 16:29, 29 September 2020 (UTC)
I’ve listened to all your issues and took them seriously, no concerns raised were dismissed. In fact, all visible concerns were implemented, as is visible from the checklist and discussions above. Of all the discussion above, only two things have not been implemented: the concern of Thryduulf that |native_name= is semantically problematic for search engines etc, and that param |borough= and |locale= should not be merged into one. As mentioned above, as I do not plan to do the bot run to replace yet, neither is relevant at this stage, as neither is visible through the wrapper. I disagree with native name and maybe agree with borough/locale, but am giving both more thought before replacement. No visual concerns from you or anyone else have been raised above that I’ve failed to address and implement —- they were all implemented. I went further and spent time preserving eg tracking cats, something nobody else raised but I figured it’d help the WikiProject’s maintenance.
I cannot read minds, if you have further issues, say them and I will read them and respond to them. I have no issue in conversing with you. Yes, in this merge you’re both sometimes a bit difficult to work with: you both clearly strongly disagree with the merge outcome, here and elsewhere; I’ve tried to consider it as genuine concern and passion, and you cannot fault me for not trying and listening. And the pre and post merge boxes are remarkably similar, other than in ordering of labels, so I really don’t get your objections, but if you make it I’ll read it. This will be a lot more productive if you stop seeing me as the enemy of UK station info boxes and focus on achieving the best solution (which imv has been reached already, but if you disagree, say it, specifically). ProcrastinatingReader (talk) 17:05, 29 September 2020 (UTC)
You might have listed to all the issues raised, but there has been almost no evidence on this page of you responding to them or taking them into account. There are questions that have remained unanswered for nearly two months - perhaps you could start by answering them and then we can progress to other issues. I'm still not seeing any consensus among those who actually have a stake in the template (i.e. the users of the template - article writers and maintainers) that the merge is a benefit (let alone a net benefit). Thryduulf (talk) 23:00, 29 September 2020 (UTC)
I genuinely, really don't know what you want me to say or do here, Thryduulf. You already know that it isn't the place to relitigate the TfD, you know as a matter of fact the implementation is in line with the TfD nom and the close, and I've further addressed and implemented every visual concern raised here. If it were about "my desired changes" gridref would be scrapped, as I think it's extraneous, but it's implemented anyway. The current state of merge is exactly what was proposed at TfD, and also addresses the concerns here, thus this is fully supported by the large consensus at TfD. Again minus "Next station" information and A-Z station nav (which, btw, does not exist on {{Infobox London station}} either, which is claimed to be a superset below) it's near identical to the existing infobox, so I genuinely don't know what the fuss is here, and you're not clarifying your objections to help me understand.
No, I'm not going to play 'have the last word' with you on every thread when it devolves into a relitigation of the TfD - it's frankly tiring. That isn't evidence that I've failed to address concerns, but there's proof to the contrary (ref last response). Besides, if you really don't think the TfD/merge is in line with consensus, as you raised yourself 2 months ago, you could've requested review at the appropriate venue, but you haven't - and trying to bring it up countless times (above/below/elsewhere) isn't helping anyone here. So, what do you expect from me here? ProcrastinatingReader (talk) 01:33, 30 September 2020 (UTC)
Well, in trying to thinking of a way forward, since you mention consensus, and as I'm truly lost on how to proceed in this scenario, I guess it's a good idea to allow consensus to determine the best way forward... ProcrastinatingReader (talk) 02:21, 30 September 2020 (UTC)

Request for review of implementation

Pinging all involved parties at the TfD, as well as those involved in the merge discussion above:

@Jonesey95, Mackensen, Cards84664, Redrose64, The joy of all things, Soumya-8974, AlgaeGraphix, Schlosser67, Thryduulf, WT79, Tholme, Izno, Dogru144, Trialpears, Mattbuck, and John Maynard Friedman:

Due to the deadlock above, your input is requested to find a way forward. Please, if you can spare the time, could you review the discussions on this page, the sandbox with merge implementation ({{Infobox GB station/sandbox}}), or if short on time just the three testcases at Template:Infobox GB station/testcases (which show the before and after). Does this merge meet requirements and may it be finalised? If not, what issues exist which should be addressed. Thank you, ProcrastinatingReader (talk) 02:21, 30 September 2020 (UTC)

I don't have any skin in this game, but I have a couple of technical comments.
  •  YI fixed some spacing in the passenger numbering, FWIW.
  •  YI think it would look nicer if the subheading "Interchange" could be indented a bit to indicate that it is a subheading of the year above (assuming that I am reading things correctly). I don't think the live template's dash looks right, but a bit of space to the left of the word would help.
  •  YIt looks like all of the fields in the test case examples appear in both the live template and the sandbox renderings. Are all of the possible parameters being used? If not, someone familiar with the template should comment on that, and ideally provide a link to an article where said parameter(s) is/are being used so that a new test case can be created.
  •  YDo we need to keep the sourcing that is provided by the asterisked note, per WP:V? It is currently missing from the sandbox. I think that the reference could be included in this template wrapper so that it does not have to be built into Infobox station.
  •  YMy recollection from the discussions above is that the "other name" header, or whatever the culturally sensitive name for it is (e.g. "Welsh: Trefforest") is supposed to be the same size as the main name header to show that the two languages are equivalent. If so, the sandbox appears to be an improvement over the live template. If my recollection or understanding of the discussion is incorrect, disregard this comment.
  •  NIf the loss of "Live arrivals/departures, station information and onward connections from National Rail Enquiries" is a show-stopper, it can probably be inserted in this wrapper in the interest of completing this process, and then discussed at a later date. Same with the A–Z listing of stations.
That's all I can see at the moment. [Edited on 2 Oct 2020 at 01:18 UTC to add  Y/ N marks to show changes.]– Jonesey95 (talk) 03:02, 30 September 2020 (UTC)
(edit conflict)Thanks, Jonesey95, for the helpful input and fix. For the record, I should note now that this will not stay a wrapper, per the TfD discussion & in line with past merges (linked in header), so I'm not sure wrapper-specific suggestions will work (+ also cause inconsistency). And for clarity, so I don't need to ping everyone again, "finalising the merge" in this discussion should be considered to include if the IB is ready for full replacement via bot run. Regarding some specific points:
  • Good point on the spacing for interchange (I will add that).
  • Good note on if all parameters being used - I am pretty sure all are (except imagesize, which is deprecated and only used on 2-3 GB station articles, and logo with 0 usages). The coincidence that they're all used is just due to the level of overlap I think.
  • Regarding the asterisk, I'm not sure we do it for any other station infobox with passenger numbers, and I think it's distract-y in the infobox/header. If it's really required for WP:V, we should figure out a neater way to address it I think. Others will know more about this than me. WP:INFOBOXREF and WP:MINREF may also be relevant. I don't think it's required, personally, per MINREF: if an article contains none of these four types of material [...] it is not required by any policy to name any sources at all.
  • Re live arrivals/departures, and the A-Z, per TfD & Wikipedia:Manual_of_Style/Infoboxes#Consistency_between_infoboxes + Wikipedia:Manual_of_Style/Infoboxes#General_design_considerations.
My view is that the merge is to standardise GB stations into {{Infobox station}}, rather than giving it special exemptions and separate look/feel to everything else (maintainability, design, unnecessary inconsistency concerns). That functionality should've been removed from {{Infobox GB station}} before this merge imo, and should not be merged into here. If it really is to be merged in, it must be possible for any other world station to use it, so we'd need agreement that "infoboxes linking to timetable information on local station/government sites" is okay. ProcrastinatingReader (talk) 03:57, 30 September 2020 (UTC)
Keeping the template as a wrapper may be the best way to get most or all of the RFC consensus. Sometimes a full merge ends up being infeasible (or some editors essentially veto it, blocking all change). – Jonesey95 (talk) 16:07, 1 October 2020 (UTC)
Jonesey95, I think that view is from a diplomatic angle. In that sense I'd agree with you, if I were exploring ways to do something in a contentious area and it was my only option. But as a TfD (which listed clearly the transitioning functionality) has already found consensus to do a full merge, and as we've done this before on every other regional template (far more complex ones than this), I strongly oppose the idea. The point of merge was harmonisation, for various reasons documented at MOS:INFOBOXES, a wrapper for these points fails that totally. As you know, as you have technical experience with templates, we've encountered no technical infeasibility here - what was said in the TfD has been done with ease. I mean, honestly, we're talking about all passthru parameters here.
I remain open to discussion on whether {{Infobox station}} should start showing timetable links (I oppose personally, but as always I will go with consensus), but if it's to be done it must be supported globally, for all train stations articles. No logical reason exists why only GB ones should show timetable links. But I am strongly opposed to cancelling or altering a consensus found by a diverse group of editors to merge, if the only reason for it is because some editors remain closed to the idea of one. FWIW, (I believe, may be wrong) the only grounds to change this would be via DRV and I think solely on grounds of newly discovered technical concerns. ProcrastinatingReader (talk) 18:45, 1 October 2020 (UTC)
You're making me angry again, so I will keep this short. I cannot agree to any "full merge" outcome, it would be far too disruptive. If the process cannot be aborted, a wrapper is the only feasible way of allowing a smooth transition. Let me ask you this: when creating articles about railway stations in the UK, or amending existing ones, how often do you add an infobox, or alter the input parameters of an existing infobox? --Redrose64 🌹 (talk) 22:32, 1 October 2020 (UTC)
I don't quite follow. {{Infobox station}} allows modification of parameters in the same way? ProcrastinatingReader (talk) 22:58, 1 October 2020 (UTC)
I'm asking about you, as an individual. Have you ever edited an article about a railway station in the UK? If so, did you change something in the infobox? Please give examples. --Redrose64 🌹 (talk) 20:09, 3 October 2020 (UTC)
Redrose64, I am sorry that you are feeling anger. I know how difficult it can be when it feels like people are just not listening. I'm not saying that I agree that people are not listening, but I have been there and acknowledge your feelings.
I have updated the sandbox to include an in-line reference for the passenger data (as suggested by Cards84664 below), and I have linked the term "Grid reference" (also suggested by Cards84664). I have indented the label "Interchange" as I recommended above.
Setting aside the process for a moment if you are able, are there any specific objections that you have to the current infobox examples on the testcases page? I believe that all of the issues that have been raised have been addressed. If they have not, please be specific about what still needs to be done. If there are no further objections to the code in the sandbox, we can move it to the live template. Having this template as a wrapper of Infobox station will improve consistency and should make editing easier for editors who edit railway station articles covering multiple countries. – Jonesey95 (talk) 01:19, 2 October 2020 (UTC)

(edit conflict) As a supplement to Jonesey95's comments, I will add:

The listing of live departures, station information, and onward connections are not "functionality" in regards to regular content being hosted on Wikipedia. The current inclusion of these links acts as a travel guide that changes on a day-to-day basis, and has no necessary purpose in an encyclopedia. As such, these links would be better suited for use on WikiVoyage. The exception to this policy is the use of passenger statistics, as they are permanent statistics, they can be cited in articles reliably. Next, while Gridref acts as a redundancy to the use of coordinates, it is a unique system that holds historical significance in Great Britain. One thing I have noticed is that the instance of "Grid reference" in the sandbox parameter should have its bluelink restored. This remains necessary as to inform new readers at minimum of why Gridref remains relevant as a feature of the infobox. Third, the removal of the station lists from the footer of the infobox is justified, as the functionality has long since been redundant to the navboxes of the stations. An example of this is the template of Cardiff, Newport and the Valleys. Lastly, the caption of "Annual estimated passenger usage" should be retained as a citation, inline with the Passengers header. This way, the infobox will not be bloated with the specific explanation. With the suggestions I have made above, I will Support the implementation of the sandbox. I will also note that I previously and impulsively attempted to rush this process through, and I apologize for doing so. Cards84664 03:55, 30 September 2020 (UTC)
As far as I am concerned, it would be sufficient if there was a single infobox template for the UK railway stations. Likewise, there may be reasons for country-specific templates for other countries (one for each), as there may be some information that applies to one or a few, but not to the others. For instance, you've got the company that operates the station, or the OS grid square (rather useful in the field), which are both UK specific information and unlikely to be relevant in, say, Germany. In Germany, however, there is the station class as specified by DB AG, something that does not apply elsewhere. I'm sure there are things specific to other countries. If someone manages to herd all these cats (pun intended) into one big template, I won't complain, but I fear that it will become rather unwieldy. Let's sort it out at the country level first. - PS: I see that you've done a good job with the three test cases. There seem to be more similarities across country borders than I expected. Still, there may need to be some provision for closed and heritage stations. --Schlosser67 (talk) 05:57, 30 September 2020 (UTC)
One of my principal concerns is the problem created when someone has put incorrect information in the space dedicated to historic train companies using the station and the so-called adjacent railroad station. I have seen many instances in which incorrect info has been put in for the next station, and it's impossible to edit the box to correct the error with information from train company references. Any new format must preserve the capacity for the infobox to be edited.Dogru144 (talk) 23:45, 30 September 2020 (UTC)
Interesting comparison. I am glad that the section previously labelled Traffic has been changed to Passengers, as, I think, traffic is an awful way to describe human beings (personal opinion). I do feel that Transit Authority is clunky, but in essence, I cannot see the major difference between the two, so no objections. I do thank you for your efforts and taking everyone's opinions and thoughts with policy into account can't be easy. Regards. The joy of all things (talk) 15:52, 1 October 2020 (UTC)
Dogru144, can you please provide an example of an article that illustrates the problem you describe? Does this problem exist in the live template, or the sandbox, both, or neither? – Jonesey95 (talk) 16:05, 1 October 2020 (UTC)
Jonesey95, thank you for bringing this up. The following is the last that came to mind, in the context of an infobox that had wrong information on adjacent stations: still-surviving stations along the NYC's West Shore Railroad stations. For example, see Highland Falls station on that route. It was possible to correct the stations that are north and south of the station. However, if there was the desire to correct information about the final destination to the north or the south, or to edit the division name, that is not possible at this article. That ability is locked elsewhere from the infobox at the above cited article. An additional problem exists with one of the options for infoboxes for train route maps. On many articles it is not possible to edit the infobox to make additions or corrections to those infoboxes.Dogru144 (talk) 21:34, 6 October 2020 (UTC)
Overall, it would be of great help if there were an easy to find page giving a tutorial on how to make these sorts of edits.Dogru144 (talk) 21:37, 6 October 2020 (UTC)
Dogru144: It sounds like you have an issue with {{Infobox station}} that should be moved to a separate talk page thread. This discussion is about the in-progress merge of {{Infobox GB station}} with this one. – Jonesey95 (talk) 01:42, 7 October 2020 (UTC)

Looking at the test cases I note the following issues with the merged template:

  1. "Classification" is a less useful header than "DfT Category".
  2. "Other information" listing an unsorted mix of information about the mainline station and tram station is confusing and badly presented. This is especially the case when the fare zone is just an unlinked number. For stations like Wimbledon in multiple zones (zone 3 for rail and tram zone for trams) this is likely even worse.
  3. Nothing in the "Passengers" section makes it clear this is only related to the mainline station
  4. The "Criteria" heading is misleading - it lists what is listed not why it is listed.
  5. Why are "key dates" not part of "history"?
  6. The note for passenger usage isn't working properly - it includes the unsubstitued parameter "{{{name}}}" (although this is conceivably a test-cases only problem)

Points 2 and 3 must be corrected before this goes live (if it absolutely must go live), the others do mean the template is inferior to the existing one but are less significant. It is telling that after months of development we still have something that is inferior to the existing template and has not demonstrated any of the advantages claimed a merge would bring - indeed the "simplicity" and "ease of maintenance" claims could have been written on the side of a bus for all they relate to the real world. Thryduulf (talk) 10:33, 2 October 2020 (UTC)

Good note on (4). Looking at other articles with designations (eg The Cenotaph), they don't include the criteria. So, I must ask, do we really need it in the infobox? If you want it we can easily use a custom label, but just saying, it feels a bit extraneous and {{Infobox designation list}} appears not to natively support it for probably that reason. Re (6), I think is probably a bug (Jonesey95?). Re (2) I don't follow, could you link an article where this becomes a problem? ProcrastinatingReader (talk) 14:46, 2 October 2020 (UTC)
Thank you for these detailed comments! I have adjusted the display to fix item 1.
For #3 (Passengers), can you please give an example or link to an article where this concern is relevant? {{Infobox station}} appears to show only a Passengers section for thousands of stations around the world; how are UK stations different?
For #4: the sandbox uses {{Infobox designation list}}, which is missing the "Feature" label that appears in the current Infobox GB station. The sandbox has mapped the Feature to the "Criteria" label, which does not seem ideal. I don't immediately see an easy way to make a "Feature" label appear, but I recognize that "Criteria" does not seem like the right label. Infobox designation list and {{Infobox historic site}} appear to assume that the name at the very top of the parent infobox is the name of the Feature, so they omit it, but that may not be the case with railway stations. This might need some research to see how other countries' stations handle this situation.
Re #5 Key dates, see the comment Please do not move "Opened" to 'the proper opened param', we have been trying to go the opposite way for some time above, where there was a request not to move dates to the History section.
Re #6, the note showing {name}, I have fixed that. A version of the problem exists in the current template (if |name= is not provided, the note will show a blank space). [edited to add: I have fixed this problem in the live template as well.]
I think that leaves items 2, 3, and 4 unresolved; please provide examples for items 2 and 3. Thanks! – Jonesey95 (talk) 15:23, 2 October 2020 (UTC)
Thryduulf: Update: I have used a different method to address item #4, the historic listing, copied from {{Infobox historic site}}, a widely used template that applies color coding for historic buildings. Does the historic test case look more reasonable now? We can change the labels; I chose the ones used in Infobox historic site for consistency with other historic site pages. – Jonesey95 (talk) 15:48, 2 October 2020 (UTC)
Jonesey95, creating a custom nested infobox in that way is not consistent/maintainable. It's effectively creating a fork due to 1 param. |feature= can be added to {{Infobox designation list}}, or one of the blank params can be used, ie |designation1_free1name= ProcrastinatingReader (talk) 16:16, 2 October 2020 (UTC)
@Jonesey95: Responses below for ease of reference:
  1. "Classification: DfT Category A" is better than "Classification: A" but not as good as simply "DfT Category: A" would be. Not a major problem but still less good than what is there now.
  2. Examples are right there on the Manchester Piccadilly test case. The station code relates to the mainline station (tram stations may have the same code, a different code or no code - I don't know); the fare zone relates to local transport (primarily trams in these instances) and with no links or other context is meaningless; the classification relates to only the mainline rail station and takes no account of and is irrelevant to anything else. This will also be an issue at every other station served by Network Rail and some other transport (tram, heritage railway, light rail, London Underground, etc)
  3. Again see the Manchester Piccadilly test case. The existing heading "Annual rail passenger usage" makes it clear that it counts mainline passengers only, not tram passengers. The new heading "Passengers" implies that it is all passengers (rail and tram) using the station when this is not the case. Like #2 this is an issue that will apply at every station served by multiple modes.
  4. This is now resolved, at least in the test cases. There is a possibility that if the entire station is listed just by name (e.g. "Wemyss Bay railway station") that is might be slightly confusing. I don't see that as a major issue, but get other opinions before rolling it out as others may disagree.
  5. Hmm, ok.
  6. I agree this is resolved, thank you. Thryduulf (talk) 17:09, 2 October 2020 (UTC)
    Mattbuck thoughts on 2 & 3? ProcrastinatingReader (talk) 18:53, 2 October 2020 (UTC)
    I don't know about Manchester, but certainly the codes that LU uses for stations are totally unrelated to the Network Rail ones. London Bridge station is LBG in NR parlance, but to LU it's N/113 (or something, I'm not at work so don't have the map right now). Similarly the numbers of passengers would be different - while there would be crossover, a lot of people would change at London Bridge LU without ever coming above ground, and LU certainly produces different usage statistics.
    Like many others, I fail to see a benefit from this. I don't mean to impugn your work, but nothing here will actually make things better than they are right now for readers. -mattbuck (Talk) 19:44, 2 October 2020 (UTC)
    Hmm, okay. So I took a look at other train station articles (eg Union Station (Los Angeles)), looks like |system= in {{Rail pass box}} is intended for issue #3, so I think that should fix that. We can also see how Union Station splits between Amtrak/Metrolink there, for reference, and considering some other articles along these lines may help us resolve #2. Other world stations must be dealing with #2 somehow (and if they're not, that's a problem that should be fixed) ProcrastinatingReader (talk) 20:58, 2 October 2020 (UTC)
    Thryduulf isn't #2 a problem with the live template, too? e.g. the page I linked specifies "Amtrak code" to 'fix' it, but that's a per-article thing. It's a problem, but is this merge compounding it? ProcrastinatingReader (talk) 22:58, 2 October 2020 (UTC)
    @ProcrastinatingReader: #2 is not a problem with the live template because the information about the mainline station is in one part of the template where context makes it clear it's about the mainline station, and information about the trams are in a separate section where context makes clear it's about the tram station. The only exception is the number of platforms, which are explicitly annotated to make things clear. Thryduulf (talk) 14:57, 3 October 2020 (UTC)
    Thryduulf, not ignoring you btw, just thinking. It's a bit of an inferred point, in that the grouping of params would infer that it's the mainline station only, but it isn't meritless. The general way to deal with this, when one station infobox/building is housing multiple systems, is usage of the params mentioned + |type= and notes where appropriate. e.g. at Union Station (Los Angeles) (which is a textbook case on how to deal with all such issues).
    But I note that the Manchester system has a separate infobox for the Metrolink system (Manchester_Piccadilly_station#Piccadilly_tram_stop), so I think this particular issue (for both Metrolink and T&W Metro overlaps) is resolved with eg |type=National Rail station on the main infobox (see User:ProcrastinatingReader/sandbox). Do you have an example of a station where a separate infobox isn't used for the other system, so I can see what cases would remain unresolved with this method? ProcrastinatingReader (talk) 13:09, 11 October 2020 (UTC)

Have sought some advice on what to do here. Overall I think it's appropriate to reimplement the merge, noting data is carried over. I think the remaining points are ones that can be discussed post-merge, as they don't seem to be blockers to the merge or directly caused by it, as functionality to achieve that purpose is possible in the new template. I'm not convinced the ordering of labels is really making a critical functional difference here otherwise, at least one that would prevent a merge. ProcrastinatingReader (talk) 18:48, 18 October 2020 (UTC)

No. It's still not been signed off by the people who actually use {{Infobox GB station}}. Also, I am still waiting on several unanswered questions. Until and unless you answer these satisfactorily, and demonstrate that no functionality has been lost, I am requesting that you revert these edits. --Redrose64 🌹 (talk) 19:56, 18 October 2020 (UTC)
Redrose64, it does not require sign-off by any particular group of editors. Implementing the TfD requires functionality to be carried over, at least as described in the TfD. That has been done. I've solicited good advice on if concerns of label structure bar a merge, and so I am confident that such differences are best and most appropriately addressed in post-merge discussions; there's no prejudice against that. Further, there are multiple explicit supports (constituting a majority btw) for the current implementation above. I cannot see anything here which suggests, per normal TfD practices, that a TfD merge cannot be finalised. But the above discussion is ~80k chars, so forgive me if I've missed something, in which case please feel free to succinctly summarise unaddressed concerns of untransferred missing functionality. ProcrastinatingReader (talk) 20:58, 18 October 2020 (UTC)
Redrose64 No functionality has been lost, plaintext links to external sites are not functions of the infobox. Cards84664 14:40, 19 October 2020 (UTC)
I note that not even all of the problems I brought up very recently have been resolved let alone all the earlier questions and comments that remain unaddressed. Wikipedia is not a democracy, what the majority do or do not think is not relevant when there is clearly no consensus among editors actively engaged with the issue. This was also the problem with the TfD close - it completely failed to distinguish between the arguments made by those with active experience of using the template and the arguments made by those looking at it as an abstract concept, even though almost all the latter arguments are now demonstrably incorrect. Thryduulf (talk) 16:39, 19 October 2020 (UTC)
List the remaining issues, so you can make this wall of text easier for all of us. Cards84664 19:37, 19 October 2020 (UTC)

Remaining issues

Based on my reading of and participation in the long thread above, it looks like these are the remaining issues (copied from the section above; the list starts with #2 to match the list above):

  1. "Other information" listing an unsorted mix of information about the mainline station and tram station is confusing and badly presented. This is especially the case when the fare zone is just an unlinked number. For stations like Wimbledon in multiple zones (zone 3 for rail and tram zone for trams) this is likely even worse. (This is "item #2" in the discussion above.)
  2. Nothing in the "Passengers" section makes it clear this is only related to the mainline station. (This is "item #3" in the discussion above.)
  3. The "Criteria" heading is misleading - it lists what is listed not why it is listed. (This is "item #4" in the discussion above.)
  4. Tracking categories are missing from the new wrapper (as of 18 Oct 2020).

I hacked up a fix for item 4 that assuaged the concern of the person who raised it, but I believe that my hack has been removed from the sandbox. I don't think anyone has come up with solutions for items 2 and 3, possibly because they exist in {{infobox station}}. We may need to adjust/improve Infobox station in order to remedy these concerns.

Other editors are welcome to add any concerns or issues that I have missed from the above discussion or previous discussions. – Jonesey95 (talk) 21:22, 19 October 2020 (UTC)

4 is explicitly resolved, please see testcases. The others I'd note an alternative solution was given for, but in any case they are not "unaddressed concerns of untransferred missing functionality" / barriers to finalise merge. ProcrastinatingReader (talk) 21:43, 19 October 2020 (UTC)
I haven't got time right now to check #4, but note this is only my list and ignores completely the issues raised by other people such as Redrose64. Also, the undressed problems are barriers to finalising the merge because they represent a very significant reduction of quality compared to the unmerged template - it is absolutely unaccpetable that the end result be inferior to what we started with. If that means improving the main template then so be it as that will see the situation improved for everyone. Expending a lot of effort over 3+ months to make things harder for editors and producing an inferior output for readers is exactly why those involved with these templates recommended not merging. Thryduulf (talk) 12:14, 20 October 2020 (UTC)
I did not deliberately ignore the concerns of Redrose64; I attempted to parse the discussions above to see which of their concerns had been addressed, but I was unable to do so. That is why I invited other editors to add to the list above. I think gridref has been addressed, for example, but to know what has been addressed and what has not, a current list from Redrose64 will be helpful. – Jonesey95 (talk) 14:54, 20 October 2020 (UTC)
Right now, I'm trying to balance a job that involves two hours travel per day (some of us have worked throughout COVID, and not from home either), increased working hours (both at my normal workplace and at other branches due to colleagues being required to self-isolate), a mother who lives even further away who has just come out of hospital and is requesting frequent attendance, and a watchlist backlog that currently stands at 28 hours (if you care to examine my contributions, you will see that they have plummeted from May to September this year). Not to mention the fact that there seem to be several ongoing discussions on this page, that when working through my watchlist it's hard to pick out the real information (that you were going to put it live) from the things that I am totally unconcerned with (mapframes and Korean names, for example). It's as if you were trying to bury bad news. But put the new version alongside the old (oh, wait, you can't) and you would see that they are different. A number of elements are absent from the new one. So, I'll come back with a list when I have time - and as Thryduulf pointed out, this goes back several months. --Redrose64 🌹 (talk) 18:53, 21 October 2020 (UTC)
Sympathies - this is not the best year. However, we cannot delay the merge indefinitely. It is impossible to take advantage of most merge benefits until then. For transparency, please consider this message notice that I will finalise this merge not before 1 November 28 October, unless any "issues" which fall into the category I suggested above are raised. Opinions on visual preferences can always be discussed at a later date, as is regular for TfDs, although I believe we've discussed them all already. If anything, this merge & discussion is far more scrupulous/generous than what is the norm. I hope you can appreciate that, at least. ProcrastinatingReader (talk) 21:07, 21 October 2020 (UTC)
Now I am confused. Despite this ongoing discussion and the issues listed above, {{Infobox GB station}} was merged, converted it to a wrapper (on 18 October 2020), which means that the test cases, as Redrose64 indicated above, were no longer useful for showing the issues that still need to be worked out. I'm not going to edit war over the conversion to a wrapper, which seems premature to me, but I have restored the former version of Infobox GB station to the sandbox so that {{Infobox GB station/testcases}} actually works. At this point, the new wrapper is in the live template, and the version of the template that was active before the change of two days ago is in the sandbox.
Saying that there is a deadline makes no sense; that is for somewhere other than Wikipedia, and AFAIK, there has been no demonstration of the next step, if any is envisioned, in this process. Let's set that proposed deadline aside. Also, saying that this discussion was more "scrupulous/generous" than the norm holds no water here. This template merge is more complex than a typical TFD, so the discussion will naturally be more involved, and may not result in a full merge as (possibly naively) imagined in the TFD discussion. – Jonesey95 (talk) 22:50, 21 October 2020 (UTC)
I could make a longer reply on each point, then I realise I've answered each at least 6 times already. So: yes, there's no deadline, when there's something to do. There's nothing to do here. We've thoroughly discussed everything, it's implemented, and it was done quickly because there's only two functional differences. It isn't complex. If something remains which is a blocker, mention it, or do what I said and go to DRV. If nobody wants to do either, I will finalise it. We do not cancel merges because two users (incidentally prominent ones and admins in this case, not that it should matter) who opposed it then still do, and I won't be held captive by endless delaying to avoid a consensus-backed merge. If there was a smoking gun functional difference, it obviously would've been pointed out by now. It takes a sentence to write it down. Even opposers in the TfD have lended their support above. Nothing has changed; we had and have a clear mandate for it, and so it will be carried out to achieve the benefits proposed, promised, agreed to, and developed. ProcrastinatingReader (talk) 23:26, 21 October 2020 (UTC)
ProcrastinatingReader: Can you please explain what it is that you propose to do on October 28? It seems to me that the merge has already happened, or been "finalised", or however one would wish to phrase it. I do not see a proposal or test cases for any sort of next step.
Meanwhile, Thryduulf, I have made a minor adjustment to the "Passengers" footnote in an attempt to resolve item #3 above. Can you please review the change (it is in the live template, visible on the left side of {{Infobox GB station/testcases}}) to see if it allays your concerns? If not, can you please propose wording that would make it clear that the mainline station passengers are the thing being counted? The wording of the pre-merge template is in the sandbox version on the right side of the test cases page; that wording didn't really make a distinction in my mind, so perhaps I am missing a linguistic nuance.
Thryduulf, re item #2, the "Other information" section of {{Infobox station}} is indeed a mix of intercity and local/urban station information. It might be helpful to modify Infobox station to separate those two concepts. Do you have a proposal for what that might look like, given that any change will affect, and likely improve, all articles using Infobox station? – Jonesey95 (talk) 00:23, 22 October 2020 (UTC)
"Finalising" would be a bot run to convert usages to standard usages of {{Infobox station}} and ticking this off holding. It may well not be on the 28th itself, could be a few days later when I get it all worked out, but I'm giving a clear date to allow even further time for a functional complaint to be made. ProcrastinatingReader (talk) 00:31, 22 October 2020 (UTC)
I don't have time right now to review anything (and might not until the weekend, I don't know) but ProcrastinatingReader your attitude here is appalling. You should wait for consensus that there are no remaining issues before proceeding with rolling out anything. Indeed if, when I get time to do a review, I find there are still major issues then I will likely be reverting to the pre-wrapper template (i.e. the one that has consensus). If you continue to insist on arbitrary deadlines then you will very likely find yourself enjoying a trip to ANI. Thryduulf (talk) 00:58, 22 October 2020 (UTC)
I trust you will follow good practices (ie WP:TPEDISPUTE), noting discussions and consensus above, which isn't just about you, when you do so. Otherwise the same may apply to you. ProcrastinatingReader (talk) 01:20, 22 October 2020 (UTC)
I would strongly oppose a bot run at this point in the template's development. There are still issues to be worked out (case in point: I just noticed that the coordinate processing in the new wrapper was inferior to the previous template version and copied in the old code), and I don't see how some of the customized items in this wrapper would be accommodated (though I am open to a demonstration on a sandbox or Draft page). There is no rush. Let's take our time and get it right. Everyone is participating, but some people's time is limited. – Jonesey95 (talk) 01:46, 22 October 2020 (UTC)

I have added item #5 above: tracking categories, including tracking of unknown parameters, have been eliminated from the new wrapper, despite being marked as done/resolved above. I do not see any discussion above where the consensus was to remove the tracking categories; my apologies if I missed that discussion.

Was there consensus to eliminate the unknown parameter tracking? Without it, there may be no way to know if typos and misused parameters will be dropped in a bot run that replaces the templates in articles. I think that it may be time to revert this wrapper update, given the issues above and the problems I have found just in the last hour or so. – Jonesey95 (talk) 02:06, 22 October 2020 (UTC)

I'll readd parameter category tracking - that was omitted. Although it won't matter after merge finalisation, I agree it should be there in the meantime to identify issues. I don't understand what you mean by the coordinates. The links are exactly the same? Raw {{Infobox station}} embedding at User:ProcrastinatingReader/sandbox of Manchester Piccadilly station. ProcrastinatingReader (talk) 02:12, 22 October 2020 (UTC)
Added tracking cats. It's a very minor detail to copy over, not sure why we'd revert a merge over it. Still not sure what you mean by coordinates, please elaborate. Looks like it's just hardcoding the scale? Apart from that, it's identical to the pass-thru coordinate code in {{Infobox station}}. The scale is meant to be set by local articles, eg see source of Manchester Piccadilly station. Other than that, it's exactly the same code..? ProcrastinatingReader (talk) 02:16, 22 October 2020 (UTC)
My point was that with only a little bit of looking, someone who is not a regular user of this template found two items that were missed in the conversion of this template to a wrapper. It stands to reason that there are more. Edited to add: The coordinates are different in some articles; see Kintore railway station, where the scale was not set locally. The pre-merge infobox was setting it. – Jonesey95 (talk) 04:08, 22 October 2020 (UTC)
Jonesey95, forgive me, I don't work with maps much, but what's the difference? Here are the two links: [3] [4]. Further note the docs on this issue, a default is set by the "scale" param which is "railwaystation" (both in this template and in {{Infobox GB station}}). Per Template:Coord#type:T that automatically sets scale 10,000. So if I'm not mistaken, your edit pretty much only adds extra words and duplicates code, because we're already setting that exact scale by setting the type? ProcrastinatingReader (talk) 07:54, 22 October 2020 (UTC)
Follow the coord links from "Birmingham New Street railway station" on the test cases page. You will see the difference. – Jonesey95 (talk) 14:08, 22 October 2020 (UTC)
Jonesey95, please up the clarity. What exactly am I looking at? Looking at that testcase, the scale is still being set by the type (invoke coordinates sets a default type), so that can't be it. So am I correct in saying the difference you are referring is that "region": "GB" is not automatically added; the result being that the output shows the map instead of the OS details (OS details are pushed down). Is this correct? If not, can you be specific and tell me what exactly it is that you're saying is the difference... ProcrastinatingReader (talk) 14:26, 22 October 2020 (UTC)
Not sure if you mean anything else too, but I agree the region issue I notice is something worth discussion so I've asked at Template_talk:Coord#Region_parameter for clarity from the maintainers. If you were hinting at something else, please still go ahead and state. ProcrastinatingReader (talk) 14:41, 22 October 2020 (UTC)
Follow the links: pre-merge template (region defined, scale set); sandbox (region not defined, scale not set but you may be right that the current infobox station default happens to match the explicit infobox GB station scale). – Jonesey95 (talk) 14:44, 22 October 2020 (UTC)
Yes, I followed the links, but I can't know if what I see is what you're referring to. Just being explicit helps. I've asked on that template talk, will post to the WP too. Let's see if the maintainers / others have thoughts on the general issue. I'm taking a peek at the source and some implementation notes in the archives which could be relevant. It may be the region.php checking (which at a glance seems mostly a 2009 design - may be better datasets we can use now) which should improve (since it also doesn't seem to support many countries like HK). If this theory is correct, on a tangential note, fixing that may be a neat improvement for a lot of articles which don't set regions. Till a solution is found, your coordinates call setting region explicitly should resolve the issue. :) ProcrastinatingReader (talk) 15:13, 22 October 2020 (UTC)
FWIW I think the issue is likely a GeoHack one. We can get around it just by adding |region=GB to coords. ProcrastinatingReader (talk) 00:15, 24 October 2020 (UTC)

We have an issue with symbols on mobiles (not solely affecting GB stations, and it's code long-in the infobox, not something I've written, before someone jumps on me). I describe it at Module_talk:Rail-interchange_multi#Broken_on_mobiles. Basically, the symbols end up tiny or messed up in some cases (I don't know what causes the 'some cases', may be the type/size of Rail-interchange image being used?) I have a potential fix at Template:Infobox station/styles.css, embedded using TemplateStyles, which stops the problematic CSS being shown on mobiles. I'm not familiar enough with templatestyles to have confidence in this approach, though. Someone care to look it over before I sync? ProcrastinatingReader (talk) 00:15, 24 October 2020 (UTC)

It's in the sandbox btw, if you want to test. You can preview any live article with sandbox to test, or see the second infobox on User:ProcrastinatingReader/sandbox. ProcrastinatingReader (talk) 00:17, 24 October 2020 (UTC)

@Redrose64: I saw an edit from you on my watchlist. Re these, if it's the "Key dates" you're trying to get rid of, just propose scrapping it here. fwiw, |years1= actually maps to |years2= here, because that template omits |years1= in favour of just |years=. It's merely a semi-bug (not one I will fix fwiw, so as to not undo your edits) in the "Key dates" header here to omit it just because someone skipped the first header and went to the second (I guess it assumes it will always be sequential usages). But I'm not necessarily against just removing that subheader, I think removal may make sense, if that's what you're trying to achieve? ProcrastinatingReader (talk) 01:24, 24 October 2020 (UTC)

You list fifty of my edits. Which one are you referring to? --Redrose64 🌹 (talk) 20:56, 24 October 2020 (UTC)
The "history" and "tidy" ones. It looked like you were trying to get rid of the "Key dates" headers, on those? ProcrastinatingReader (talk) 21:14, 24 October 2020 (UTC)
Oh, I see what you were doing now. We're talking about two slightly separate things, but your explanation below has helped me understand your mapping better. Made a slight alteration to the infobox based on that. Still, the question I ask applies. Do you have a preference on removing the "Key dates" header? You haven't expressed it, but since {{Infobox GB station}} doesn't have one I would presume so? We can look into removing it if that'd be something you feel is an improvement? ProcrastinatingReader (talk) 21:41, 24 October 2020 (UTC)
There are still plenty of issues surfacing. For example, upright images must not be huge, see Bangor railway station (Wales). I spent ages getting consistency, culminating in this edit, and now it's been thrown out the window.
Let me explain about years/events. Originally, we had just two parameters, |years= and |events=, note the plural. A typical (fictitious) usage might be 
|years=1830<br />1914<br />1918<br />1939<br />1945<br />1968
|events=Opened<br />Temporarily closed<br />Reopened<br />Temporarily closed<br />Reopened<br />Closed
but this was bad for accessibility (there was no association between e.g. 1914 and "Temporarily closed") so the numbered pairs were added, |years1=|events1=, |years2=|events2=, etc. so that each single event would be associated with a single year (or date). The intention was that when all were converted, we would dispense with the unnumbered |years=|events= params, and we achieved this with {{infobox London station}}. It has taken longer with {{infobox GB station}} because there are many more stations to work through. But I have been doing it, as time allows.
Yearsn/eventsn pairs should permit gaps in numeric sequence, there are a number of stations where several pairs are omitted.
You are ruining a carefully-constructed infobox, for no apparent benefit whatsoever. Just revert, permanently; or if you can't bear rthat, revert so we can consider each change individually. Have you answered all of these questions yet? I thought not. --Redrose64 🌹 (talk) 20:57, 24 October 2020 (UTC)
+1 to what Redrose64 says here. There was no problem with the infobox that existed, and the only reason anyone has been able to advance for changing it is "ease of maintenance". That wasn't a problem before. If it's so easy to maintain a single infobox template, why are there hundreds of them for all the different subjects, shouldn't we just have the one? -mattbuck (Talk) 21:10, 24 October 2020 (UTC)
Well, {{Infobox person}} doesn't work for a railway station, if that's what you mean. They should be consolidated where closely related, but completely unrelated ones not. Ease of maintenance isn't the best reason, though. Visual consistency for readers, parameter consistency for editors, and bridging of functionality would be the main ones. ProcrastinatingReader (talk) 21:14, 24 October 2020 (UTC)
Why do you suppose we cannot add (for example) Special:Diff/861071932 into {{Infobox station}}? Isn't that a good thing? If it were added to this one, 48,000 other articles benefit, right? However, per WP:PICSIZE, aren't we not meant to use px image sizes? Isn't |image_upright= the correct way to address this (as I have just done)? ProcrastinatingReader (talk) 21:20, 24 October 2020 (UTC)
We should not need to do this for all of the stations that have portrait-format images. I managed to get every single GB station away from that, so that it was automatically set; and now you have broken that automation. --Redrose64 🌹 (talk) 21:03, 25 October 2020 (UTC)
Well, if the automation is desired we can add it into here. If it isn't desired, it shouldn't be used on any station (GB or not). The question is if it is desired. The tangential question to answer this is if we want to be using px sixes (noting the question I raise in my previous message re WP:PICSIZE). As a general note, for better or worse, that diff is pretty much what we do for all (non-station & station) articles currently, e.g. on person bios etc. ProcrastinatingReader (talk) 22:20, 25 October 2020 (UTC)
The px sizes were not specified in the articles, I eliminated all of them except one (Huddersfield), and that was only retained because the image was so very wide compared to its height that it meant that extra width was justified. For all other stations, the size of 265x265px was only specified in the template code, not in the individual articles, and by that means we achieved consistency.
I've found another thing. Because you have stuffed two parameter values into one row, people are now making edits like this which really should not happen. They are separate distinct items of information, not a postal address. --Redrose64 🌹 (talk) 23:25, 25 October 2020 (UTC)
I'll find a template editor to discuss this with later today. Couple of options to resolve, not sure which is best. Input from you & others also appreciated if you've any ideas on a fix. A stopgap measure would be passing param through, but that isn't really a solution that addresses the problem. ProcrastinatingReader (talk) 09:26, 26 October 2020 (UTC)

Image sizes

Splitting from discussion above. Redrose64 raised the concern of this big image. I added the sizedefault to sandbox in Special:Diff/985525355. See testcases. The image size for various images has changed. Some for better, some perhaps for worse (eg the Paso Robles testcase looks questionable). What do people think about this? Do we want to proceed with adding this to {{Infobox station}}, allow cases to be fixed manually with |image_upright=, or are there other solutions we'd like to explore? ProcrastinatingReader (talk) 13:38, 26 October 2020 (UTC)

One other solution is to calculate the ratio during merge and add in |image_upright= based on that. eg File:Bangor Railway station from Bangor Mountain.jpg has ratio height/width of 1.3543. Say, anything greater than 1.25, or 1.3 or something, gets an image_upright added? ProcrastinatingReader (talk) 14:02, 26 October 2020 (UTC)
image_upright will suffice. Additionally, it is also easier to crop or replace the image entirely, rather than make all images smaller. Cards84664 14:03, 26 October 2020 (UTC)
ProcrastinatingReader, I think this is a poor change. Portrait-oriented images are a challenge for infoboxes; the real solution is not to change the infobox but to find a more appropriate image for Bangor. Most images currently in use are landscape-oriented and the default should be to support them. Mackensen (talk) 14:06, 26 October 2020 (UTC)
The default - before all this kicked off - was that {{infobox GB station}} supported both orientations, and it made the longer dimension 265px. That way, all that was necessary was to set the |image_name= parameter (optionally |caption= and |alt= as well), and you didn't need to worry about dimensions, ratios or anything else to do with sizing because it was all done for you. The |image_size=/|imagesize= parameter became virtually unused, and whilst an |image_upright= param was supported, I never once found it actually being used. A few years ago, when |imagesize= was being used (primarily in articles having portrait-format images), it was used inconsistently; and I often found that when people replaced an image having one orientation with another image having the other orientation, they simply left the |imagesize= param exactly as it was, the result being tiny landscape-format images or huge portrait-format images. --Redrose64 🌹 (talk) 23:23, 26 October 2020 (UTC)
They are in the sandboxes currently. Infobox width isn't exactly static (em), so if you see Template:Infobox GB station/testcases the change makes the Piccadilly / Birmingham testcase images shorter even though they're landscape. I think these ones make sense just being their full width (as currently in the live infobox). ProcrastinatingReader (talk) 12:58, 27 October 2020 (UTC)
In the meantime, I've replaced the image at Bangor railway station with a cropped version. Pi.1415926535 (talk) 16:09, 27 October 2020 (UTC)
Thanks, but that does not solve the basic problem: people should not be expected to set an additional parameter if they are using a portrait-format image, nor should they be expected to unset that parameter if such an image is replaced by one of landscape format. --Redrose64 🌹 (talk) 23:12, 28 October 2020 (UTC)
I think per above comments there's little we can do here. Jonesey and I implemented this in the sandbox and it didn't seem favourable there / above. I don't think there's much this template can do to address the issue in a nice way, and the GB station hack causes issues on landscape images so it's not an ideal hack. This is really a wiki-wide issue that we don't seem to have a solution for yet. Perhaps Module:InfoboxImage can do something with the ratios, or maybe a bot could do something here? Both worth exploring elsewhere, but may well be the case that there's no shortcut for this problem, and I'm not sure there's anything we can (or should) do about this global issue at a station-infobox level. ProcrastinatingReader (talk) 17:37, 1 November 2020 (UTC)
So what you're saying is that we must lose yet another feature in the interests of your desire for one-infobox-fits-all. This is not acceptable: I am afraid that I cannot sanction this, and again ask you to entirely revert your changes to Template:Infobox GB station. And you still have not answered crucial questions from early on. --Redrose64 🌹 (talk) 20:39, 2 November 2020 (UTC)
I contemplated a few different responses to this. How this as-existed appears more a bug (even on current GB template) than a feature when testcase'd side by side, that it isn't a GB/non-GB matter (ref WP:CONLEVEL), or that you can try sandbox something if you think there's a workable solution that none of us are seeing... but I realise none of these answers will get us in agreement. And I cannot think of one that will. So please help me out here, what do you realistically expect me to reply? ProcrastinatingReader (talk) 00:18, 3 November 2020 (UTC)
What really, really, make me so angry is your determination to pull Template:Infobox GB station away from Great Britain whilst leaving Template:Infobox London station alone. Unless Boris and Trump have come to some secret deal, London is part of Great Britain, and Great Britain is not in the USA. Template:Infobox GB station and Template:Infobox London station should be moving closer together, not further apart, and many of my changes to both templates over the last ten years or so have been in the interests of British harmony. But there's no point in me writing that, because It is absolutely 100% clear to me that whatever I say, you will ignore me and drive your own agenda. Have you answered my questions yet? No? So, clearly my views count for nothing, even though I am (or, if you have your way, was) one of the most active users of Template:Infobox GB station. The way it behaved before was absolutely not a "bug", it was designed that way, and nobody at WT:UKRAIL ever complained about any modification that I made. The infobox worked just fine until you stuck your claws in. Now take them out, put things right back to the way they were, and everybody will be happy (except yourself). And I don't see why your happiness should matter at all, because (a) you clearly care nothing for my happiness, and (b) you still have not told me when you have actually used Template:Infobox GB station. I don't think that you have. Ever.
So who counts here - the people who actually use the infobox, or the people who don't. I would say the former. Can you deny that? --Redrose64 🌹 (talk) 21:35, 4 November 2020 (UTC)
Well, we all determine the limits of our participation in this project. The consensus at TfD was to merge because there was no obvious reason for Great Britain to have its own station infoboxes (several actually), when the rest of the world, not just the United States, managed with one (save New York City). I don't see that the above moves us closer to a resolution, though I think at last we are all speaking plainly to one another. Mackensen (talk) 23:42, 4 November 2020 (UTC)
I still think that the wrapper was applied prematurely, and that we should go back to having the wrapper in the sandbox, work on the image and other concerns, and continue to move forward deliberately. It seems likely that we will need to apply some improvements to {{Infobox station}} itself, since the wrapper can only control so much of the formatting. – Jonesey95 (talk) 00:44, 5 November 2020 (UTC)
Unless Boris and Trump have come to some secret deal Well... there are still two months left in 2020 :)
I still don't know what to say, admittedly. Every possible response I can think of to this I've already said many times, at the TfD, above, or in my reply @ the WikiProject. None have convinced you, though, so I'll admit I'm pretty much out of ideas. But I've three thoughts: (a) about who/what counts here: I think this is about our readers. Seeing it this way also helps us stop seeing this as "me vs you". (b) regarding your happiness, well, I did try. I implemented your requests (and things you didn't request, like tracking) and spent time thinking about nuances, even beyond the 120k chars on this page. I don't expect a "thank you proc!!" - I know you'd much rather I didn't spend any time on it and never nominated it in the first place - but saying I didn't try make it work for everyone doesn't seem fair. (c) I'm not sure what to say to make you change your mind, I'm not sure if it's even possible. But I think I'd like to say it is what you make of it, at this point. We've all disagreed with a consensus before. The merge will happen; you may be able to delay it for another couple weeks or perhaps a bit longer, but it'll come to an end at some point. And this path only leads to seeing the merge in a bitter way, for everyone really but probably especially for you. Or you can accept that a merge will happen and focus on trying to make it a merge that works for everyone, by addressing everyone's primary concerns. (It may not be everything you wanted today, but it does carry over all the functionality, doesn't it?) I think one path leads to a happier outlook when this is all said and done. ProcrastinatingReader (talk) 01:10, 5 November 2020 (UTC)

The reference

The reference on {{Infobox GB station}} is repeated 5x. What do we, and Jonesey95 (as the suggestor/implementor), think about us adding a new |footnotes= into this template, and adding the ref once in there (perhaps like "Passengers: [1]" or similar)? I think it looks neater, and I know some other infoboxes do repeated refs that way (eg country/settlement ones). I certainly don't mind keeping it as it is if people want it like that, but just a suggestion. ProcrastinatingReader (talk) 17:30, 1 November 2020 (UTC)

I guess it's easier to ask if there's any objections to the change... I added it to sandbox (pretty similar to the {{Infobox person}} implementation), can be compared at Template:Infobox GB station/testcases. Both look ugly imo. BTW, the cite is an access denied page.[5] (pre and post wrapper) ProcrastinatingReader (talk) 02:04, 5 November 2020 (UTC)

Disused

Thanks everyone for the help & patience over the past few months; Infobox GB station and heritage station are done, the bot should finish up substing GB in a few hours.

{{Infobox UK disused station}} is slightly trickier due to Category:Unusual parameters of Infobox station template. I believe I've mapped this up in the sandbox, though, and it looks fine on my testcases. Just want to run it by people here first, is that handling in Template:Infobox UK disused station/sandbox okay? ProcrastinatingReader (talk) 12:16, 10 November 2020 (UTC)

No. Questions still remain unanswered. --Redrose64 🌹 (talk) 12:56, 10 November 2020 (UTC)
What concerns do you have, Redrose? ProcrastinatingReader (talk) 14:15, 10 November 2020 (UTC)
Let me try asking one of my unanswered questions again, but phrased differently. Have you ever started, or substantially expanded, any article about a UK railway station? If so, which ones? --Redrose64 🌹 (talk) 11:52, 13 November 2020 (UTC)
Which part of how Wikipedia:Administrators' noticeboard/IncidentArchive1050#User:ProcrastinatingReader turned out made you think that there was anything appropriate about this approach? Mackensen (talk) 12:01, 13 November 2020 (UTC)
I will assume that your answer is "none at all". Therefore, I ask you this: why are you concerning yourself with railway station infoboxes at all? Supplementary: why are you disrupting my workflow, and what have you got against me? --Redrose64 🌹 (talk) 18:06, 13 November 2020 (UTC)
This is highly inappropriate WP:OWNership behavior. Stop trying to win disagreements by pulling rank. Lev!vich 19:50, 13 November 2020 (UTC)
Who is pulling rank here? Have I said "I'm an admin, and because of that I forbid you from doing this"? Have I blocked anybody recently, or protected a page that I shouldn't have done? Have I even threatened to do either of those things? As for WP:OWN, who is it that is forcing through changes without letting people who just might have a genuine interest in the outcome have a say? Who is it that is refusing to answer legitimate questions, some of which have remained unanswered for months? --Redrose64 🌹 (talk) 20:28, 13 November 2020 (UTC)
Not only did you and another admin threaten another user, you actually took them to ANI, where the prompt consensus was that your complaints had no merit. The question you ask is not legitimate, and that's the lesson you should have taken away from ANI. Instead, you're now asking a different user the same inappropriate question. I'm telling you so that you will not have any confusion: how you are treating other editors in this discussion is not acceptable, and you must stop. You are not in some special category by virtue of having made a lot of edits to a particular page. That's what OWN is all about, and you've been here long enough to know it. Your options are: help, appeal, walk away. Berating our colleagues is not an option. Lev!vich 20:48, 13 November 2020 (UTC)
Have I even threatened to do either of those things? kinda. But regarding forcing things through: I believe this talk page is my most contributed to page across the entire wiki (in terms of edits); I am trying to communicate with you... ProcrastinatingReader (talk) 20:58, 13 November 2020 (UTC)
It doesn't appear so. Let's go right back to the TfD itself, where in late July I asked four questions. None of them were answered; and whenever I bring this up, I either get ignored are am brushed aside as if my questions are as trivial and irrelevant as "what colour should the bike shed be?". Since then, other relevant questions have been treated in a similar manner. How is this "trying to communicate" with me? And, Levivich, I am not somebody who has "made a lot of edits to a particular page" - I have made a number of edits to a lot of pages about British railway stations. I would say that four thousand different articles would be a low estimate. Many of them involved the infobox; of the 2,500 stations which are presently open, I have added or amended at least one infobox parameter in virtually (99%+) every one. This was my very first edit to a station article - and oh look, there's the addition of a parameter to the infobox. All of those 4,000+ articles are (or were) on my watchlist - I monitor them, not just for vandalism but factual changes, which I check. Three times in the last week my watchlist has maxed out because there have been so many edits that I can't keep up, so I've had to unwatch a number of pages just so I can see older changes. --Redrose64 🌹 (talk) 00:10, 14 November 2020 (UTC)
Let's go right back to the TfD itself, where in late July I asked four questions. None of them were answered ... After a TfD is closed, an editor's options are: appeal the TfD result, help implement the TfD result, or walk away, regardless of how many pages that editor, or other editors, have edited. Lev!vich 04:53, 14 November 2020 (UTC)
When I asked the questions, the TfD had not been closed. --Redrose64 🌹 (talk) 12:49, 14 November 2020 (UTC)

Yes, you have said many times over the past several months that the TfD was closed without your questions being answered to your satisfaction. Your options are to appeal that TfD result, help implement it, or walk away. Lev!vich 16:14, 14 November 2020 (UTC)

ProcrastinatingReader, thanks for your work on this. I see no obvious issues; the increased width of the image makes for better flow in the list of events. Mackensen (talk) 13:00, 10 November 2020 (UTC)

I've just finished up disused and added it to the subster; checked a handful again and all look good to me. Should take a little while for it to finish up. This one was a bit ugly to get into substable form (see source for what I mean ;p) but the output looks good, so it's worth it. ProcrastinatingReader (talk) 08:43, 15 November 2020 (UTC)

Merge complete! *phew* ProcrastinatingReader (talk) 15:56, 16 November 2020 (UTC)

ANI

I should have mentioned earlier, I filed a case at Wikipedia:Administrators' noticeboard/Incidents#User:ProcrastinatingReader. --Redrose64 🌹 (talk) 14:56, 7 November 2020 (UTC)

The 8 Nov closing statement of the ANI was "ProcrastinatingReader has done nothing inappropriate, and if anything (based on the few technical questions I have been asked regarding the implementation of the merge) it sounds like they have nearly bent over backwards trying to make sure all parties are satisfied with the merge itself. ANI is not the place to contest the result of a TFD, nor to railroad the person who is attempting to implement it; this should be done at WP:DRV. If there are no substantive or outcome-based objections to the merger, then those opposed to this move need to accept that and step back. If those opposed to this merger do not wish to file a DRV, then the merge can proceed, but we should give them a couple of days to file to avoid potentially having to mass-undo the substing/replacement that is required of the merge." Lev!vich 05:00, 14 November 2020 (UTC)

Notification of merge discussion

Latest comment: 4 years ago1 comment1 person in discussion

For Template:Infobox T&W Metro station and Template:Infobox Manchester Metrolink station. Please see Wikipedia:Templates_for_discussion/Log/2020_November_28#Template:Infobox_T&W_Metro_station. Thank you, ProcrastinatingReader (talk) 23:43, 28 November 2020 (UTC)

New(?) Passengers section

Latest comment: 4 years ago5 comments2 people in discussion

Could someone please fix the extra space below the header? It is particularly wider than the other ones. Thanks! --truflip99 (talk) 19:55, 10 October 2020 (UTC)

Truflip99, do you know roughly when this issue started to appear, by any chance? Technically, it's caused by a blank <tr> being dumped. I'm not entirely sure why it's being dumped. I tried show preview with old versions of Template:Infobox station and Template:Rail pass box and the issue still appears. ProcrastinatingReader (talk) 13:12, 11 October 2020 (UTC)
@ProcrastinatingReader: no clue... The last time I worked on an article with it was around August and I'm confident it wasn't an issue then. Certainly recent. truflip99 (talk) 18:06, 11 October 2020 (UTC)
@Truflip99: Looked into this again, see Template:Infobox#Embedding. I think it's this part causing the issue: Note that omitting the |title= parameter, and not including any text preceding the embedded infobox, may result in spurious blank table rows, creating gaps in the visual presentation. (the bug, technically, here is indeed a blank tr being dumped, and {{Rail pass box}} doesn't have a |title=). Seems like a bug with {{Infobox}} to me. ProcrastinatingReader (talk) 09:44, 28 November 2020 (UTC)
I've gotten around it by just pushing all the logic into the header param. Should be fixed now? ProcrastinatingReader (talk) 09:48, 28 November 2020 (UTC)

Proposed change to Template:Rail pass box

Latest comment: 3 years ago1 comment1 person in discussion

Hi, I am proposing to change the term "Interchange" to "Interchanges" over at Template:Rail pass box, which is used in conjunction with this infobox. Any comments or opinions on this are welcome at the template's talk page. Thanks, PinkPanda272 (talk/contribs) 17:32, 1 January 2021 (UTC)

other_services

Latest comment: 3 years ago11 comments4 people in discussion

I would like to implement the sandbox as it currently stands, duplicating the other_services parameter. other_services is currently used for either Former or Future train services, this edit would separate these sections when both are needed. This testcase would be useful on articles such as Los Angeles Union Station, Grand Central Terminal, Chicago Union Station, and Elgin station (Illinois), among others. Cards84664 22:45, 24 January 2021 (UTC)

Personally, as I say, I wonder if these should be in the prose in the first place, rather than the infobox. In any case, I guess it's not worth letting perfect be the enemy of the good, as it seems like some pages are just stuffing them in one parameter currently. No objections per se from me, but will give it a few more days for comments. ProcrastinatingReader (talk) 00:04, 27 January 2021 (UTC)
I would comment on the names of the params though. I think Mackensen raised this earlier, but |other_services= & |other_services2= aren't very helpful from a semantic standpoint (verses, say, former/future, or some other variation, but possibly with its own issues). Could just have them as aliases, to get the best of both worlds? As an aside, |other_services_collapsible2= should probably be |other_services2_collapsible= (as it's the collapsible of the #2 service, not the #2 collapsible of the #1 service). I can play around with both these ideas in the sandbox in the coming few days? ProcrastinatingReader (talk) 00:08, 27 January 2021 (UTC)
I kept "other" since you could have Former and Future in one article, Proposed and Suspended in another (as an example). It's easier than coming here to change it repeatedly via edit request. (other_services2_collapsible sounds better). Cards84664 07:14, 27 January 2021 (UTC)
On that I agree. Although, if former/future is to be a common use case, I would have them as aliases of the parameter name. (semantically, |former_services= is easier to parse). Technically, it would be part of the same parameter in the template, but if the alias |former_services= is used it could infer the heading automatically. ProcrastinatingReader (talk) 10:41, 27 January 2021 (UTC)
  Done ProcrastinatingReader (talk) 15:13, 2 February 2021 (UTC)

Map images

Latest comment: 3 years ago4 comments2 people in discussion

I set up some tracking for |map_locator= and after fixing some articles (with help from MB), all that remains are static images in this field. are there any objections to changing this to |map_image= to avoid confusion with |mapframe= and |map_type= maps? Frietjes (talk) 00:28, 10 February 2021 (UTC)

or maybe |image_map= used by {{infobox settlement}}? Frietjes (talk) 00:28, 10 February 2021 (UTC)
Frietjes, there has been no comment. I think we can clean this up. MB 01:50, 12 March 2021 (UTC)
MB, I added |map_image= as a replacement for |map_locator=. as before, the map_image only shows if there is no other location map. suggest migrating this way since the width is now set to match the top image. Frietjes (talk) 15:42, 15 March 2021 (UTC)

Use of plainlist

Latest comment: 3 years ago2 comments2 people in discussion

Would it be possible to automatically format the "line" parameter to avoid the need for plainlist? Or in articles like Nanning East railway station should I use two plainlist templates, one for China Railway lines and one for metro lines? If so, shall I update the template documentation to make this clearer? I've been using <br /> to separate items but now I see this is bad for accessibility. Thanks NemesisAT (talk) 14:22, 7 May 2021 (UTC)

@NemesisAT: Sorry, I think I missed this in May. There's not really a template way to avoid the need for a {{Unbulleted list}} (or other list) template, or manual formatting. Any kind of template hack to try to detect a list would be too unreliable. ProcrastinatingReader (talk) 23:16, 7 August 2021 (UTC)

Custom header

Latest comment: 3 years ago7 comments2 people in discussion

The "95th/Dan Ryan" section is the only one that uses |custom_header=, and this parameter is causing two stripped </div> tags; I know this from ExpandTemplates. Will someone who understands these things please determine if the custom header is formed properly or not. If it is formed properly, then the test case shows some sort of error that needs fixing. If it is not formed properly, please fix it and make the stripped tags go away.

Also, for what it's worth, the "Pittsburgh Union Station" section shows fostered content lint errors in ExpandTemplates, but the file information page doesn't list fostered content lint errors. —Anomalocaris (talk) 09:22, 6 September 2021 (UTC)

Anomalocaris, that particular custom header is implemented by {{Infobox station/Header CTA}}. In my browser, the tags appear balanced so I'm not sure what you're seeing. Mackensen (talk) 11:00, 6 September 2021 (UTC)
To be clear, I was talking about Template:Infobox station/testcases. Mackensen, I determine lint errors with the help of lintHint, and it isn't, or shouldn't be, browser-dependent.—Anomalocaris (talk) 17:08, 6 September 2021 (UTC)
Anomalocaris, I believe it's fixed; an unimplemented change in the sandbox caused the issue. Mackensen (talk) 17:41, 6 September 2021 (UTC)
Mackensen: The stripped tags issue is fixed. The Pittsburgh Union station section still shows fostered content lint errors in ExpandTemplates. The Information for "Template:Infobox station/testcases" page shows no fostered content errors, only a missing end tag lint error, which does not show up using ExpandTemplates and lintHint. —Anomalocaris (talk) 18:54, 6 September 2021 (UTC)
Anomalocaris, I think resolving the script error resolved the linter error as well. Mackensen (talk) 19:24, 6 September 2021 (UTC)
Mackensen Thanks! The page information page shows no lint errors and neither does ExpandTemplates with lintHint. —Anomalocaris (talk) 20:55, 6 September 2021 (UTC)

Request: Images for interior and exterior of the station

Latest comment: 3 years ago1 comment1 person in discussion

I think it would be helpful for above-ground train and intermodal station with a large building. If not what image should be prioritized? The station's interior (the train's platform for an elevated rail station) or the exterior (facade of the station as seen from a nearby road)?Hariboneagle927 (talk) 06:36, 30 October 2021 (UTC)

Request: Add parameters for railroad classification yards

Latest comment: 2 years ago7 comments5 people in discussion

I've been working on some articles on classification yards, and I've noticed there is no infobox specific to them. I have no clue how to make a new infobox, but I figured one solution could be to add some parameters to this infobox which can be used for a railroad yard. Some parameters that could be added might be:

  • The type of yard (flat vs hump yard)
  • The number of humps (for hump yards)
  • What types of cargo are handled at the yard
  • Which railroad or railroads operate freight services at the yard (some are served by more than one)
  • Intermodal cargo connections (truck, ship, plane)
  • Size of the yard, in units such as acres or square kilometers
  • Capacity of the yard (how many railroad cars it can hold at a time)
  • The number and type of sub-yards (many larger yards include receiving yards, classification yards, departure yards, etc)
  • Parameters for maintenance facilities, such as engine servicing and railroad car repair facilities, as well as maintenance of way facilities

Do other editors think this would be a good idea? Trainsandotherthings (talk) 00:00, 8 December 2021 (UTC)

IMO it seems like too much info for an infobox (c.f. MOS:INFOBOXPURPOSE: The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance.) ProcrastinatingReader (talk) 18:16, 27 December 2021 (UTC)
@ProcrastinatingReader:This was specifically spurred by my article, Cedar Hill Yard, which at the moment has no infobox, as I cannot find one suitable. Railroad infoboxes typically contain a significant amount of information, an example is GE 25-ton switcher. Adding these parameters doesn't mean they have to be used where not needed. I suppose an alternative is to make a separate infobox for railroad yards, but I do not have the technical knowhow to do so. If this is not intended, then infoboxes such as Template:Infobox locomotive will need a lot of their parameters deleted. I'll also note that INFOBOXPURPOSE also states, "As with any guideline, there will be exceptions where a piece of key specialised information is difficult to integrate into the body text, but where that information may be placed in the infobox." I believe some of my suggestions fall under this area. Trainsandotherthings (talk) 18:56, 27 December 2021 (UTC)
Might be worth asking at WP:RAIL in that case, it’s a bit more active than here. ProcrastinatingReader (talk) 23:56, 27 December 2021 (UTC)
It may be best to ask for help to create a new template because the current one is already bloated and there is little cross-over betweenh the requirements. --John Maynard Friedman (talk) 00:10, 28 December 2021 (UTC)
A point to note (if I may): should a new infobox be created, I would suggest it is titled as Infobox Rail Yard with a parameter of Type against which you could have various options such as Classification, marshalling, layover, storage, node etc. This will take into account international usage and make the infobox usable on other non-classification rail yards. Unfortunately the skill required to create said infobox is beyond me. Sorry. The joy of all things (talk) 10:20, 28 December 2021 (UTC)

Looks like we already have {{Infobox railway depot}}. Might need to be adapted for US use, but certainly better than modifying infobox station. Pi.1415926535 (talk) 00:15, 30 December 2021 (UTC)

That would definitely need a rework because it's currently U.K. exclusive, but it's doable I suppose. I know zero about creating of modifying infoboxes however.

Proposal to change symbol location

Latest comment: 2 years ago1 comment1 person in discussion

I think it would look nicer if all the symbols were in a line just below the station name, as they get kind of cramped on the same line. Any thoughts?Bluealbion (talk) 02:57, 30 January 2022 (UTC)

Auto short description

Latest comment: 2 years ago1 comment1 person in discussion

Hi, do you think it would be a good to add an automatic short description of the form Station in [borough], [country]? I've made an attempt in the sandbox. Qwerfjkltalk 08:18, 18 April 2022 (UTC)

Tracking non-child mlanguage infoboxes

Latest comment: 2 years ago1 comment1 person in discussion

any objections to adding tracking for non-child infobox being pass through the |mlanguage= parameter? I just fixed about 25 of these and thought it might be useful to find and fix more. the tracking code is in the sandbox. thank you. Frietjes (talk) 22:01, 8 June 2022 (UTC)

Enabling type to be filled in by adjacent stations

Latest comment: 2 years ago7 comments4 people in discussion

while updating a bunch of Kyiv Metro articles, I noticed that they are using |style=Kyiv Metro and |type={{METROKIEV type}}. wouldn't it would be much more efficient if Module:adjacent stations had a station type parameter that would fill this in automatically? I have implemented something in the sandboxes see here and here and here. if the |type= is filled out, it should override the value provided by the module. are there any objections to moving this to the main template and module? Frietjes (talk) 16:45, 17 June 2022 (UTC)

here is another one for replacing {{Tblisi Metro type}}. Frietjes (talk) 17:13, 17 June 2022 (UTC)
I agree with having the module handle this, but disagree with the implementation a bit. In [6] you just used the value of ["system title"] (unlinked) and the value of ["system icon"] (but a different icon). If that is the default type handling then it should use the data already present in the module and not duplicate it. Gonnym (talk) 18:19, 17 June 2022 (UTC)
the problem is that they may not be the same icon, for example, here where the "system type" icon exists but no "system icon", and if there was a "system icon" it would not be 100px. Frietjes (talk) 19:28, 17 June 2022 (UTC)
In that example, if there is the system has an icon (like it does here), then it should be added to the module at ["system icon"]. Regarding the size, that can be handled with a new override parameter ["type_icon_size"] (or something). But Mackensen below might have a point that it might be worth removing altogether. Gonnym (talk) 20:44, 17 June 2022 (UTC)
I think before considering anything like this, we need to have a much broader conversation about what the type field is for, as its usage varies widely. In the past I've been in favor of removing it altogether for that reason. If we need a narrower station classification parameter then fine, but many times "type" just restates the operator, and there's no point in that. Mackensen (talk) 19:47, 17 June 2022 (UTC)
Strongly in agreement with Mackensen here. At very least there needs to be standardization of usage of the parameter (and move it out of the header), and I am certainly in favor of removing it altogether. Pi.1415926535 (talk) 21:23, 17 June 2022 (UTC)

Template-protected edit request on 29 May 2022

Latest comment: 2 years ago7 comments7 people in discussion

I would like to add a section for whether there are PIDs at the station NotOrrio (talk) 11:55, 29 May 2022 (UTC)

  Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Also, what is a PID? Please provide a link or explanation. – Jonesey95 (talk) 13:19, 29 May 2022 (UTC)
I am assuming NotOrrio means a passenger information system, also called a "passenger information display system]] or PID system for short. Actually sounds like a good addition to me. oknazevad (talk) 14:05, 29 May 2022 (UTC)
Yes, a pax info display sounds right. Hard to envision a station without one or more of 'em, though, so I don't see the need. P.I. Ellsworth - ed. put'r there 14:08, 29 May 2022 (UTC)
Definitely not needed. Wikipedia is an encyclopedia, not a travel guide; the presence of PIDs is not nearly important enough to justify taking up space in the infobox. Pi.1415926535 (talk) 03:28, 30 May 2022 (UTC)
I agree. These displays have become routine. Stations that don't have them will be getting them. Nearly trivial info. --John Maynard Friedman (talk) 14:54, 18 June 2022 (UTC)
Joining the club of those opposed to this. This is about as necessary as a parameter identifying if there is a yellow line on the platform that passengers at the station are to stand behind when a train is arriving. Trainsandotherthings (talk) 15:17, 18 June 2022 (UTC)

“Structure type” for stations in a cutting

Latest comment: 2 years ago1 comment1 person in discussion

What is the preferred “structure type” for stations in a cutting, such as Kwinana railway station?

That article currently uses “Ground” in the infobox. As the list of structure types on the template page refer to only “underground, at-grade, or elevated”, I assume that the list is meant to be descriptive rather than prescriptive. But it doesn’t seem to describe whether a cutting should be treated as “at-grade” (which it technically is - just not at the grade of the immediate surroundings) or have a separate category.

Some other articles seem to use variations referring to cuttings, such as Kōgyōdanchi Station (“At grade (cutting)”) and Springvale railway station (“Cutting”), but others seem to use “Ground”, such as St Peters railway station or Helensburgh railway station.

Is there a consensus on preference? 203.206.107.28 (talk) 00:57, 19 August 2022 (UTC)

Add "skip-stop" parameter

Latest comment: 2 years ago1 comment1 person in discussion

Hey everyone,

I think it would be good to add a |skip-stop = parameter to the stations, especially for metro stations. Chicago especially had skip-stop on its "L" for much of the 20th century, and while I'm not overly familiar with other train systems and how they stop, I think a generalized parameter would work well to indicate whether a station is express/local/"A"/"B"/etc. Otherwise, I think the closest thing would be to use {{Adjacent stations}} and have each skip-stop be an individual "route", which while good for systems who do such things officially like New York is clunky for other systems.

Thanks,

– John M Wolfson (talk • contribs) 00:18, 11 November 2022 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_station/Archive_4&oldid=1126399702"