Template talk:Infobox station: Difference between revisions

UK stations merge

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:

• {{Infobox GB station/sandbox}} (testcases)
• {{Infobox UK heritage station/sandbox}} (testcases)
• {{Infobox UK disused station/sandbox}} (testcases)

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:

•  Done pte: Passenger transport executive
•  Done gridref: Ordnance Survey National Grid

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) 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):

• Transit authority only: Special:Permalink/973191730
• Same as above, but as header not label: Special:Permalink/973188626
• Variable header: Special:Permalink/972406929, implementation Mackensen mentioned
• Variable label: Special:Permalink/973188540, slight adjustment of above

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):

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. (This is "item #2" in the discussion above.)
3. Nothing in the "Passengers" section makes it clear this is only related to the mainline station. (This is "item #3" in the discussion above.)
4. The "Criteria" heading is misleading - it lists what is listed not why it is listed. (This is "item #4" in the discussion above.)
5. 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)

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)

Mapframe

Following the RfC I raise the matter of opt-in mapframes in this infobox. This was previously raised in 2018. Also pinging Evad37 for thoughts and implementation. ProcrastinatingReader (talk) 17:39, 3 September 2020 (UTC)

@ProcrastinatingReader: Implementation is relatively easy, see this diff to Template:Infobox station/sandbox2 (done there since /sandbox seems to be in use for the UK merge). Placement is a matter for local consensus per the RfC – I've put it at the bottom of /sandbox2 since that's where the location map is currently positioned. Documentation can be added just be transcluding {{Infobox mapframe/doc/parameters}} on the /doc page. - Evad37 [talk] 01:34, 5 September 2020 (UTC)

@Jts1882: in case you miss this. We discussed this recently, looks like there may be momentum now. As you observed, there are many minor stations that have no maps at all and this would be an instant bonus for minimum effort. --John Maynard Friedman (talk) 10:03, 5 September 2020 (UTC)

I think there is no reason not to include mapframe maps as an option, with the default as no (don't show). An issue to discuss is whether the default should be yes (show mapfrane map) if there is no other map. —  Jts1882 | talk  10:31, 5 September 2020 (UTC)

Best take it one step at a time to avoid getting no steps at all. It should be easy to get consensus to add mapframe, initially set to off. Making it default to 'on' will take a longer discussion while editors search for special cases. So I support addition of mapframe. --John Maynard Friedman (talk) 12:52, 5 September 2020 (UTC)

I don't believe local consensus is needed to add, due to the wider consensus in the RfC. Just needs local consensus on where to place it. I'd say logically where the current map is now, at the bottom, makes sense. ProcrastinatingReader (talk) 16:02, 5 September 2020 (UTC)

Yes, I agree (to both). --John Maynard Friedman (talk) 17:07, 5 September 2020 (UTC)

Implemented at the bottom, where the current map is. Parameters added to doc. With thanks to Evad37 for implementation. ProcrastinatingReader (talk) 11:47, 10 September 2020 (UTC)

Thanks for implementing this! Can we set the default marker to be "rail"? I have it set that way at Ossining station and Scarborough station. Can always be set to "bus" for bus stations, likely a small minority. ɱ (talk) 13:56, 12 September 2020 (UTC)

Hmm. My personal thoughts: it'd be okay to do that now, since they have to be manually added, but it would create a big barrier if we wanted to enable mapframes by default. And since they have to be manually enabled currently anyway, I don't see it being too helpful to do it in the template automatically vs just adding advice on this into the docs. If we had some kind of way to tell which is bus and which isn't it (eg |station_type=) this would work better. ProcrastinatingReader (talk) 16:24, 12 September 2020 (UTC)

As far as docs go, if we go the 'not setting defaults for all stations' route, I wonder if we can create some sensible defaults, without suggesting explicit usage of mapframe params. Like, if we had |mapframe_type= (value: railway, for ex), and this implements a set of sensible defaults for mapframes. Big advantage to this over suggesting individually recommended mapframe param values is (a) less params required, (b) more friendly for most editors, (c) we can adjust defaults in template easily if need be, vs having to use a bot which wouldn't be able to tell which are 'defaults' and which are intentionally set differently. Thoughts, and ideas on how to best technically achieve this, Evad37? ProcrastinatingReader (talk) 16:28, 12 September 2020 (UTC)

On detecting station type this could be done via Wikidata, e.g. looking for instance of (p31) bus station (Q494829), railway station (Q55488), underground railway station (Q55491), London underground station (Q14562709) or combination thereof. A simple template or module could provide the symbol to pass to mapframe. There might be a case for something more general to pick symbols for buildings, stadia and other locations. —  Jts1882 | talk  16:48, 12 September 2020 (UTC)

Unless this conversation develops more (which it seems it might not?), can we go with the default for rail (likely the vast majority of uses)? It always has the option to change it out for "bus" anyhow. Unless someone can commit to some Wikidata-based solution? ɱ (talk) 02:25, 23 September 2020 (UTC)

This code should automatically pick an appropriate symbol based on the Wikidata P31 value - Evad37 [talk] 03:03, 23 September 2020 (UTC)

OK, neat. How would I utilize that in an infobox? Is it automatic? I tried at Scarborough station (Metro-North), even previewed as the "/sandbox" template and the icon won't display for me. ɱ (talk) 11:01, 23 September 2020 (UTC)

You need to preview with the /sandbox2 template. And the page's wikidata item needs to have P31 set to one of the Q values duscussed above - Evad37 [talk] 12:07, 23 September 2020 (UTC)

Right, looks good, thanks. I'm in support of implementing this solution. ɱ (talk) 13:36, 23 September 2020 (UTC)

Can we do this? No problems with Evad's solution here? ɱ (talk) 22:00, 26 September 2020 (UTC)

Looks fine to me. We may want some kind of parameter so that local articles can override, if for some reason the Wikidata value isn't correct/desired. But I suppose manually supplying |mapframe-marker= would do that, and be prioritised by the module? ProcrastinatingReader (talk) 23:03, 26 September 2020 (UTC)

Yes, mapframe-marker can work for any instance of overriding the default marker. ɱ (talk) 23:08, 26 September 2020 (UTC)

Seems fine to me then. I think this is safe to implement, with seemingly a rough consensus in favour. ProcrastinatingReader (talk) 23:57, 26 September 2020 (UTC)

 Done - Evad37 [talk] 14:00, 1 October 2020 (UTC)

Evad37, I'm not sure it's working? Or I'm doing it wrong. See Union Station (Los Angeles) (which uses |map_locator= manually). Change to |mapframe=yes and no marker shows. On Wikidata it's an instance of railway station. I'm guessing it may be due to multiple values? ProcrastinatingReader (talk) 21:10, 2 October 2020 (UTC)

(←) yeah I tested it without 'tram stop' and it works. Evad might know a way to make it work without the removal... ɱ (talk) 21:20, 2 October 2020 (UTC)

The code only shows a default value when there is a single P31 value on wikidata. Not sure what you would expect to happen when there are multiple values, other than letting editors specify which (if any) marker icon to use via the parameter - Evad37 [talk] 05:22, 3 October 2020 (UTC)

Evad37, many times the second value in 'instance of' has nothing to do with what 'type' of railway it has (eg [5]). For multiple values, I think it should match the first in the current ordering of the switch template. ProcrastinatingReader (talk) 14:48, 3 October 2020 (UTC)

Agreed that if it can be set to match the first entry in 'instance of' that should work. Even if a station is used for two or more types of transit vehicles, the first should still be the predominant usage. ɱ (talk) 14:55, 3 October 2020 (UTC)

 Done - Evad37 [talk] 08:45, 5 October 2020 (UTC)

Evad37, by the way, is there an easy way to add the stuff in {{Infobox mapframe/doc/parameters}} to the TemplateData? Like a TD version that can be transcluded/kept in sync, or something. ProcrastinatingReader (talk) 19:29, 12 October 2020 (UTC)

I'm not sure if it as actually possible to transclude bits and pieces within a templatedata block, could be something interesting to try. It's possible to keep a copy of the TD for the mapframe parameters for easy copy-paste, much like the parameters list for the Check for unknown parameters. But there's no shortcuts just yet, because for with way it would need to be set up manually initially. - Evad37 [talk] 22:33, 12 October 2020 (UTC)

Evad37, copy and paste works fine, too, if that's the best method. Is there one set up somewhere already, to paste from? ProcrastinatingReader (talk) 22:57, 12 October 2020 (UTC)

Not yet, as far as I am aware - Evad37 [talk] 00:20, 13 October 2020 (UTC)

@ProcrastinatingReader: Now done at Template:Infobox mapframe/doc/templatedata - Evad37 [talk] 01:28, 14 October 2020 (UTC)

Evad37, thanks Evad. I added it to doc. Longer term, I do slightly wonder if it can be embedded in some way, to keep them in sync. Not sure if template transclusion works in the templatedata block, but if not, I presume modules can still do something here (as I guess {{Documentation}} is doing), maybe with something slightly fancier to handle trailing commas (JSON syntax). ProcrastinatingReader (talk) 17:11, 19 October 2020 (UTC)

New(?) Passengers section

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)

Parameter deprecation

Designations

Per Template:Infobox_station#Embedding_other_infoboxes designations are meant to be embedded in |embedded=. A legacy param remains where |nrhp= is being misused in templates to replace core functionality. Page list. Examples: Washington Union Station, Philipse Manor station, Portland Union Station, South Orange station, Orange station (NJ Transit). The whole infobox is embedded to chuck in a map / extra map (rather than use this IB's map), repeat params (like address, coordinates, etc see Portland Union example). It's a mess. The param shouldn't really exist anyway, since designations are embedded into the embedded param. Proposing removal of the param, and a bot run to convert usages into proper designations, move maps / other relevant, provided non-duplicated info to this infobox, and retain only the standard set of designation parameters. ProcrastinatingReader (talk) 17:24, 12 October 2020 (UTC)

In what way is |nrhp= a "legacy" parameter? As far as I can tell, it has not been documented, but it has been in the template since 2009 and is widely used (|embedded= was added as an alias for nrhp in 2011 and then immediately separated into its own row). I don't see any discussion in the talk page archives, so there is no way to know whether one parameter is supposed to be preferred, or whether they have separate purposes. Maybe |nrhp= just needs to be documented. – Jonesey95 (talk) 19:06, 12 October 2020 (UTC)

I don't follow this at all. {{infobox NRHP}} is a whole separate infobox which is being validly embedded to include the relevant info about the property being listed on the National Register of Historic Places. This is done with many other infoboxes including {{Infobox lighthouse}}, {{building}}, etc. It includes the date added to the register, the refnum, architectural style, etc - info not included in the station infobox. I agree that duplicated info (e.g. address) should be removed. That calls for cleanup of the usage, not removal. MB 19:09, 12 October 2020 (UTC)

Removal of the parameter name, not of its value. Its supported purpose in this template, as far as I can tell, is designation, similar to {{Infobox designation list}} (which supports this exact functionality anyway...). That purpose is fine, but I can't see why it should be used as an actual embedded infobox almost the size of the main station one itself, or why it needs its own parameter rather than utilising |embedded=, like the other designations use. Aesthetically it looks weird, long & bloat-y. ProcrastinatingReader (talk) 19:31, 12 October 2020 (UTC)

Considering this a bit deeper, I think I'd like to split up |embedded= into a separate |designation= as well. It will also allow us to see non-designation usages of the parameter more clearly, and identify what non-designations are being embedded (helpful to realise if there's anything we should add as core functionality). A bot run can detect designation usages and replace parameter names (there are active 'deprecation bots', and this would be in scope I think). Both |designation= and |embedded= would be supported. Regarding |nhrp=, it should be folded into |designation=. Functionally, I think we should drop support for {{Infobox NRHP}} embedding and simply encourage {{Infobox designation list}}. It handles the same designation functionality of the former, and we don't want any of the excess fields. Noting that most usages are in excess, and either duplicate information or add bloated information, I think a bot run to trim/replace with {{Infobox designation list}} would be appropriate. No valuable information is lost, of course. Mapping will be folded into {{Infobox station}}.

See User:ProcrastinatingReader/sandbox#Re_NRHP for a preliminary demo of what I mean (before/after). Location, coordinates, area should all go. The question remains on the labels "Architect", "Architectural style" and "Built". As you can see from Template:Infobox_designation_list#Embedding, the logic is to usually have these as part of the core infobox. They have little to do with the designation, and as such aren't natively supported by {{Infobox designation list}} either. ProcrastinatingReader (talk) 12:16, 13 October 2020 (UTC)

Okay, architect, architectural style are supported by this template (Template:Infobox_station#Construction), so they'll be retained in the infobox properly. All params bar the "(Land) Area" param, which fails MOS:INFOBOXPURPOSE anyway imo, are supported and info retained, and the mess of this cleaned up (I will add a |built= to join |rebuilt=). See User:ProcrastinatingReader/sandbox#Re_NRHP. Any opposition to me proceeding with this, as mentioned? ProcrastinatingReader (talk) 03:49, 17 October 2020 (UTC)

I haven't had time to look into this more thoroughly, but NRHP is not just a designation type - that is why it has it's own infobox. {{infobox NRHP}} handles may more cases than the few things listed in {{Infobox designation list}}, such as being a listed building within a historic district, a non-listed building (contributing property) withing a historic district, multiple designations (such as National Historic Landmark (maybe you are handling this)). I don't know if any of the transclusions of NRHP in stations use any of these parameters, but I don't see why a NRHP property that happens to be a train station should be limited and not just use the full NRHP infobox.

I don't know the history of why there is a |NRHP=, and changing that to the standard |embed= is just cosmetic. I agree that editors are often lazy and repeat info and maps that are in the main infobox. But that can be cleaned-up by normal editing. I always remove anything redundant when I find it. There are many thousands of NRHP infoboxes - most stand-alone, but many embedded in other infoboxes (e.g. {{infobox school}}, {{infobox lighthouse}}) and I'm not sure it makes sense to treat NRHP stations differently. I'd like to get more input from other NRHP folks. MB 04:22, 17 October 2020 (UTC)

MB, there's hundreds of these cases and nobody has cleaned them up. And the issue isn't just duplicating params (see my sandbox), it's usage of params we support in this template instead in the embed. It visually looks a mess. To quote our article: is the United States federal government's official list of districts, sites, buildings, structures and objects deemed worthy of preservation for their historical significance (similar to Listed building). The IB is most appropriately used as a infobox-proper on articles like Manzanar. The purpose of the IB for embedding here is the designation status. We can do this in a neater way, without losing data, whilst improving visuals and consistency, and removing repetition, all at the same time, so why shouldn't we? To add, my experience reading archives is generally that it's a mistake to think all template usage is intentional, much is just unmaintained templates. ProcrastinatingReader (talk) 16:21, 17 October 2020 (UTC)

Korean name

It's been sitting in the deprecation / slated for removal part of the doc for a while. Meanwhile, we're suggesting/recommending its usage in the very first example. So it's not really deprecated. Do we either want to move it out of the deprecation part, or do a bot run to convert the parameters on used articles under |mlanguage= (which seems to be the 'preferred' way of doing things. Visually no difference. I personally think converting to |mlanguage= is more logical, given also that's how Chinese names / other countries are currently doing it (see eg Kam Sheung Road station). ProcrastinatingReader (talk) 17:31, 12 October 2020 (UTC)

ProcrastinatingReader, I was just looking at Korean name because of the formatting issue at Gyulhyeon station. I'd worked up a change in my userpage (User:Mackensen/Infobox station) to suppress the header on the included child infobox and have Infobox station set its own. There's a similar formatting issue visible in your example. Mackensen (talk) 11:48, 14 October 2020 (UTC)

Mackensen, good catch. Yes, I think your fix resolves the issue for Korean stations. It won't fix the issue for Kam Sheung Road station though, since that uses {{Infobox Chinese/Chinese}}. Note also that both the Chinese and Korean templates are wrappers around {{Infobox Chinese/Header}} (which may help?) ProcrastinatingReader (talk) 12:46, 14 October 2020 (UTC)

ProcrastinatingReader, yes, for that I think we need an mlanguage_header parameter for infobox station, and then encourage a default usage of the child infoboxes that suppresses the header.

On your original question, I think it would make sense to formally deprecate the Korean parameters in favor of mlanguage, once the header is available and we have better documentation. Mackensen (talk) 13:00, 14 October 2020 (UTC)

Mackensen, hmm, we also don't want local articles to have to write |mlanguage_header=Korean name (or Chinese, etc) all the time. We could perhaps add that param with fallback automatic detection by checking the parameter value for "Infobox Korean name"/"Infobox Chinese name", etc, and giving a header based on that. But it's may be a little ugly (code-wise). We could also ask that template to add in a headerstyle param, and pass through our headerstyle (this duplicates code, but achieves the same effect), assuming they think it's appropriate to add that may fix our issue also. There may be other, better ideas. ProcrastinatingReader (talk) 13:10, 14 October 2020 (UTC)

ProcrastinatingReader, I looked into passing the header style, and I don't think it's a sustainable approach. You could have a default mlanguage_header of "Native name", with the Native part overridable. Mackensen (talk) 14:27, 14 October 2020 (UTC)

Mackensen, ah. Before throwing the towel in on the automatic part, I have an idea to simplify the 1st suggestion above. See Module:Sandbox/ProcrastinatingReader/ib. Basically, using a !regex capture group (the (%a*) part), whose value will be "Chinese", "Korean", etc., and just returning that part. If it exists, great, if not, default to "native name". It would be invoked with {{#invoke:Sandbox/ProcrastinatingReader/ib|nativeName|{{{mlanguage|}}}}}. At Kam Sheung Road station for example, the value of |mlanguage= is {{Infobox Chinese/Chinese|t=錦上路|s=锦上路|l=Brocade road|y=Gámséuhnglouh|j=Gam2soeng5lou6|p=Jǐnshànglù|showflag=y|}}. So it works in the debug console with that exact string value. Issue is, and I've ran into this once before, the template code is already parsed by the time it hits the module, so the module doesn't see "Infobox Chinese/Chinese", it sees the substitution of it. The result is my code returns "" rather than "Chinese".

I've ran into this issue once before with modules, it's a slight pain... Pinging Jackmcbarn, is there any way to get the pre-parse value of the parameter? Or another way to achieve what I'm trying to do? At the same time, this may be an XY problem -- surely there's an easier way to get an embedded child infobox to obey the header style of the parent infobox? ProcrastinatingReader (talk) 14:57, 14 October 2020 (UTC)

@ProcrastinatingReader: is there any way to get the pre-parse value of the parameter? No. I submitted a PR for this functionality once, and the Parsoid team rejected it, because it would make things too confusing for people who edit with VE. Or another way to achieve what I'm trying to do? Perhaps you could instead add a marker class to something in the output of {{Infobox Chinese/Chinese}}, and search for that marker class with Lua. Your other option is to have this module call {{Infobox Chinese/Chinese}} itself (by taking its name), instead of doing so within a parameter. Jackmcbarn (talk) 19:10, 14 October 2020 (UTC)

Jackmcbarn, re the other option, we don't actually know what language template is being embedded. This template just offers |mlanguage=. There's a lot of possible templates which can be used, even if we support this set natively if there's another set it'd break support for that (if there's not, yeah, we could do this too I guess). But, shouldn't {{Infobox}} provide better support for inheriting header styling when an infobox is being embedded? Or at least add a class or something so we can force it with TemplateStyles. Or some way to do this easier, without even having to consider what particular IB is being embedded? ProcrastinatingReader (talk) 19:22, 14 October 2020 (UTC)

Re the patch, was/is there an issue ID for it that we can comment on? I've a few other use cases that would benefit from something like this. Also seems like Parsoid team has changed, so might have better luck with it now? ProcrastinatingReader (talk) 19:25, 14 October 2020 (UTC)

@ProcrastinatingReader: No, there was never an issue about it, but you could make one and then link it to my old PR. As for my alternative idea, I didn't mean hardcoding a list; I meant doing something like {{Infobox station|template name=Infobox Chinese/Chinese}}, and then inside that, doing {{ {{{template name}}}}} to use it, and then also using the name for what you wanted to use it for. Jackmcbarn (talk) 22:58, 14 October 2020 (UTC)

Jackmcbarn think I'm juggling 3 ideas at once here, so to slow myself down... On the {{Infobox}} point, isn't the issue Mackensen describes really something {{Infobox}} should be providing support for (when embedding children), rather than us having to do a template-specific hack here? To make sure we're all on the same page, if I understood Mackensen correctly, we're talking about the styling applied to the header of the embedded infobox, matching that of the parent? So this is kinda something {{Infobox}} should be providing general support for, I'd think? ProcrastinatingReader (talk) 12:22, 16 October 2020 (UTC)

Possibly related Template_talk:Infobox/Archive_7#Child_parameter_inherits_styles?. If so, is this something technically difficult to implement, since the two infoboxes are parsed separately and probably have no knowledge of one another? ProcrastinatingReader (talk) 12:25, 16 October 2020 (UTC)

@ProcrastinatingReader: Inheriting can also be solved with the {{ {{{template name}}}}} trick. By making the parent call the child, instead of calling the child in the parameter, the parent can add whatever other parameters it wants to. Jackmcbarn (talk) 16:43, 16 October 2020 (UTC)

Jackmcbarn, admittedly I don't follow what you mean. For example, at Kam Sheung Road station, are you saying instead of the current |mlanguage= value there, we can do |mlanguage_template=Infobox Chinese/Chinese and add |mlanguage_t=, _l, _j, etc.? ProcrastinatingReader (talk) 16:46, 16 October 2020 (UTC)

Jackmcbarn, thoughts of User:ProcrastinatingReader/sandbox2? Implemented using Special:Diff/981456262/983879701. ProcrastinatingReader (talk) 19:57, 16 October 2020 (UTC)

Parameter validation

Jonesey95, re Special:Diff/984867522, that module also adds deprecated and duplicate parameters (incl tracking connections/other). Its implementation was in compliance with WP:TPECON, which only adds pages to newly created tracking categories, and they are hidden. It does not modify the existing ones, ergo no disadvantages. No false positives were reported here - if they were, they could've been fixed or discussed. Please clarify how your revert complies with WP:TPEDISPUTE. ProcrastinatingReader (talk) 17:46, 22 October 2020 (UTC)

Wait... Too many false positives (e.g. symbol_location3) -- that's because the TemplateData says "symbol3_location" (which is what it should logically be named, now that I think about it). If you had raised it on the talk, that could've been mentioned. I don't understand why you'd (a) remove hidden tracking cat code (b) not just fix the TemplateData and (c) not discuss it here, (d) how this isn't a revert is [...] out of sheer reflex, (e) how good cause, careful thought were met and finally (f) why you felt a discussion was not possible per and (if possible) a prior brief discussion with the template editor whose action is challenged. Fixed in Special:Diff/984884537. Please self-revert. ProcrastinatingReader (talk) 17:51, 22 October 2020 (UTC)

I'm not sure what the Template Data section of the template documentation, which is not protected, would have to do with detection of unknown or deprecated parameters. Nothing functional, I hope. We have a battle-tested module for that work, a module that is used in templates that are transcluded in 11 million pages. If you wanted to know how to use it to detect and categorize deprecated parameters, all you had to do was ask.

The module you added led to the creation of a redundant "unknown parameter" category with a one-letter capitalization difference, which was an error. It appears that you also created a "deprecated parameter" category that is mis-documented, which does not explain which parameters are deprecated, and for which articles do not display any error message. The module was malfunctioning by putting up red error messages for parameters that were not unsupported, so I commented it out. Not out of reflex, let alone "sheer reflex", but with good cause (explained at length here) and careful thought. The module appears to have been applied without discussion, and its application was not followed up on to ensure that it was functioning properly; to avoid editors' damaging of articles, I commented out the code until you could fix all of the problems with its implementation. Now that these problems have been identified, please test changes like this in the sandbox and post on this page when you would like your changes to be reviewed.

On a more general note, I have been unimpressed by your cavalier attitude toward template editing on this widely used template and on the related {{Infobox GB station}}. I, and many other editors on this page, have tried to work with you, but you have insisted on adhering to a timeline and process of your own making, in a way that benefits neither editors nor readers. Please slow down and work collaboratively. Templates, especially those with many transclusions, should be edited carefully and deliberately, and those edits should be followed up on to ensure that they work as intended. You have failed to do so with multiple edits to this template and to Infobox GB station. Failure is acceptable, as long as it is acknowledged and corrected. – Jonesey95 (talk) 19:11, 22 October 2020 (UTC)

Jonesey95, if you don't know what it's doing, why not ask here? When I thought your edit to {{Infobox GB station}} (re coordinates), which isn't even TE protected, was mistaken, I brought it up on the talk page to discuss with you rather than revert. That discussion led to something productive. You decided to edit war on a TE protected template with another TE, which is even worse due to the mildly contentious discussion in which we're both involved above. Given this, did you seriously think reverting was good judgement? |symbol_location3= is used on 74 articles, the module adds hidden tracking cats, evidently not large-scale, and nobody else reported it; evidently was time to discuss when you know my response time is fast. You chose not to. I cannot see from any angle why you'd think reverting was the better option. Your edit was not in compliance with TPE guidelines, and it definitely wasn't the action to take if you expect deescalated and calm, productive template editing. Is that not what we both want, even though it apparently is not happening currently? Anyway, the issue is resolved per Special:Diff/984884537. Will you kindly self-revert? ProcrastinatingReader (talk) 19:30, 22 October 2020 (UTC)

When I see a template error, I generally fix it if the fix is obvious. If the error is multifaceted, as described above, and was newly introduced without discussion, it is often best to simply undo the error until it can be fixed. Before I would be open to reverting my commenting of the addition of this module, I would like to see it tested in the sandbox to see if it fixes the list of problems I described above. The category descriptions at Category:Pages using Infobox station with deprecated parameters, Category:Pages using Infobox station with unknown parameters (the new one, with the capital "I") and Category:Pages using Infobox station with duplicate parameters have not been fixed yet, for example. They contain multiple errors. – Jonesey95 (talk) 19:51, 22 October 2020 (UTC)

Jonesey95, synced my edit to sandbox. Not sure what you want to test, or how, but feel free to do it as you desire. As for the category descriptions, I assume you mean the fact that they refer to Module:Check for unknown parameters. Sure, I can create a new template to be more descriptive. ProcrastinatingReader (talk) 19:58, 22 October 2020 (UTC)

Categories updated. ProcrastinatingReader (talk) 20:03, 22 October 2020 (UTC)

Making progress. I have fixed some errors and omissions in the category page template. Is the sandbox working? Do you have test cases or temporary usages of the sandbox in articles to demonstrate the module's function? Does it / should it apply categories to non-article-space pages? (The unknown parameter check is typically configured to apply categories to article space only.) Test cases are the next step after making a change to the sandbox. When I preview Achern station, which uses the unsupported |iso_region=, I do not see an error message with the sandbox template. Should I? Will I see error messages for deprecated and duplicated parameters? If not, how is an editor supposed to know how to fix the problem? I'm happy to mentor you through this process. – Jonesey95 (talk) 21:55, 22 October 2020 (UTC)

Jonesey95: The module was not accepting sandboxes, it should work now. You can see a test at User:ProcrastinatingReader/sandbox2. It won't work in the /testcases (module ignores template-space). It does apply to some non-articlespace, (e.g. draftspace, userspace drafts). And I think it should - individual templates can override if they prefer something different, but it's useful to have the tracking on draftspace/userspace drafts. It won't work in, say, talkspace, for example. You should be able to preview Achern station and see it now. ProcrastinatingReader (talk) 22:51, 22 October 2020 (UTC)

Note, by the way, the first message you will see in preview is due to the unknown parameters module, so that message will be duplicated. The deprecated one will not. ProcrastinatingReader (talk) 22:53, 22 October 2020 (UTC)

I'm not sure why a module would ignore template space. That's where testcases live by default. That should be fixed.

Why categorize User-space pages? Should editors be messing with other editors' user-space drafts and experiments? If not, they are just clutter in the category.

At Khewra railway station, I see "Warning: Template:Infobox station/sandbox used with duplicate parameters: caption (this message is shown only in preview)." That's only one parameter; it should list both of the duplicated parameters.

At Ans railway station, it says "unknown parameters", and then only one parameter is listed.

This module is not ready for production use. Perhaps we should move this module debugging conversation to Module talk:Parameter validation. I have placed that page on my watchlist if you would like to follow up there. – Jonesey95 (talk) 23:11, 22 October 2020 (UTC)

I think that this is related to User talk:MusikAnimal#Protecting template /doc pages. --Redrose64 🌹 (talk) 22:00, 23 October 2020 (UTC)