Template talk:Amtk

Change data source
This module should be modified to use Module:Adjacent stations/Amtrak. The data is compatible, with some caveats. First, the Adjacent stations ecosystem doesn't support, or  , or any other arbitrary parameters. Line-based disambiguation is still available. I addressed this in two ways: by carrying over a limited number of state-based station keys such as "Newark, Delaware", and implementing line-based disambiguation wherever possible (Ashland, for example). In a migration scenario the template would call instead of. That template expects the first argument to be the system (Amtrak), the second the station (the first one here), the third the line (the third one here), and the fourth the type/branch (not presently supported). State (second argument) and dab (named only) would simply be ignored. I suspect there are a limited number of station links which would break and would have to be fixed.

I would note that I'm not convinced that this template is necessary going forward. It saves approximately six characters of text ( vs  ) and creates a downstream dependency which has to be maintained. There's no performance advantage. With USSTATIONS in particular the naming conventions of the various stations, in the US anyway, have converged. Having shortnamed passthroughs to the various data modules (which effectively is/was) seems unnecessary when there's a generic template which accepts the system parameter. Mackensen (talk) 17:35, 26 January 2019 (UTC)


 * Instead of a wholesale trashing of this template, I suggest that you turn it into a redirect wrapper for &#123;&#123;stl|Amtrak}}, with a lookup table that translates $station, state → station, line$. Useddenim (talk) 22:19, 26 January 2019 (UTC)


 * As I said, redirection as a possibility. I don't see any value in attempting to translate the state parameters; it's far easier to find the few usages of state and migrate them. There's only ~438 transclusions after all. Persisting deprecated and unused parameters will only confuse people and create technical debt. My question remains; what value does this template provide going forward? Saving six characters of text inside template code has to be set against the technical cost of maintaining compatibility with station link and the benefit of using the same template to render station links regardless of the system. Mackensen (talk) 22:27, 26 January 2019 (UTC)


 * Correct me if I’m wrong, but off the top of my head I’d say that more people would know what state a station was in rathern than what Amtrak line it was on… Useddenim (talk) 23:54, 26 January 2019 (UTC)


 * That's probably true for readers, but anyone who's using a template to link to a station is probably aware of which line the station is on. I can't think of many use cases for which that wouldn't be true. state was always something of a hack, not widely used, and I probably shouldn't have added it in the first place. The only places where it was truly useful was stations with the same name on the same line. The only ones I can think of are Newark and Niagara Falls, and those can be handled with special keys. Mackensen (talk) 00:20, 27 January 2019 (UTC)
 * …and probably some instances of Union Station, too. Useddenim (talk) 06:18, 27 January 2019 (UTC)
 * I don't think any union stations are currently disambiguated by state. The names are too idiosyncratic. The closest we get is Springfield (Illinois and Massachusetts), but Amtrak never used the former. Mackensen (talk) 15:53, 27 January 2019 (UTC)
 * It was actually the International that had come to mind, between Union Station, Toronto and Chicago Union Station. Useddenim (talk) 17:39, 27 January 2019 (UTC)
 * Sure, but Chicago and Toronto aren't ambiguous with each other, and aren't ambiguous with other stations with the same name but located in a different state/province. Both names are unique, and the state parameter would be superfluous. Mackensen (talk) 19:40, 27 January 2019 (UTC)
 * Would the code of each transclusion have to be changed from amtk to stl? If so, only a redirect should be created. I would argue it should be a waste to abandon this template altogether. You can add Vancouver to the list of stations with the same name on the same line: one in Washington state and one in British Columbia on the Cascades. –Daybeers (talk) 08:05, 4 February 2019 (UTC)
 * A redirection is possible, but there's not going to be a 1-1 correspondence between the old and new data sources. For one, Module:Adjacent stations does not and will not support the state parameter. It's going away. Vancouver has to be handled with special keys. Mackensen (talk) 12:23, 4 February 2019 (UTC)
 * I see WP:OWNERSHIP creeping in here. There's no reason state can't be supported (the code already exists in this template), and since more than one other has raised the issue I suggest that you do incorporate that functionality. (Otherwise this is going to go in the same direction that has…) Useddenim (talk) 12:37, 4 February 2019 (UTC)
 * I can't find the discussion now, but it was specifically considered during development whether the state parameter should be supported (along with branch, type, through, oneway, etc). I wasn't involved in that discussion and I didn't make the decision; I've little involvement in the development of Module:Adjacent stations beyond reporting bugs, suggesting features, and implementation. I can't exercise ownership over something I don't own :). You're right, there's no reason why state can't be supported, and you're welcome to start a discussion at Template:Adjacent stations and gain consensus for that view. For my part, I see it as unnecessary. It was lightly-used within the Amtrak ecosystem, and barely used if at all outside of it. Looking at the station tables, there are three cases where state would be useful: Newark, Niagara Falls, and Vancouver. Line-based disambiguation handles or can handle everything else. Those three are handled with special keys, as indeed they are in . Mackensen (talk) 12:50, 4 February 2019 (UTC)

Sandbox
I've created a sandbox and testcases for the redirection. I think it would also be appropriate to add Module:Check for unknown parameters support for the state and dab parameters; I've left it out of the sandbox for now because it messes with the testcases for some reason. Mackensen (talk) 14:05, 11 February 2019 (UTC)

Why can't the amtk links be left in templates and articles and just be redirects to the new module? It would take forever to change them all, and there's absolutely no reason to. You're even adding characters. –Daybeers (talk) 03:27, 4 March 2019 (UTC)
 * That’s what I said a month ago. This seems to be change for change’s sake. Useddenim (talk) 04:35, 4 March 2019 (UTC)
 * I've said, repeatedly, that we can do that. I have a sandbox in place which does that very thing. I'd be grateful for your feedback on that sandbox. The only caveat, again, is that Adjacent stations doesn't support the state parameter, so any transclusions which rely on it will need to be updated. Mackensen (talk) 13:00, 4 March 2019 (UTC)
 * I added three testcases to the page. It seems the sandbox doesn't handle stations with state abbreviations, i.e. Windsor, CT or Washington, D.C. I'm not quite sure why. Also, Category:Pages using Amtk with unknown parameters isn't sorted alphabetically by the unknown parameter, but rather by the article name. Can this be fixed? Thanks! –Daybeers (talk) 19:14, 6 March 2019 (UTC)
 * Regarding state abbreviations, those were all individual exceptions in and were implemented differently, with greater consistency, in Module:Adjacent stations/Amtrak. Most of them were replaced with line-based disambiguation. It was always expected that those would need to be changed. If you look at the module you can see the full list of exceptions. There's still a couple hard-coded keys like "Richmond, California" and "Niagara Falls, New York". I've updated the sort key. Mackensen (talk) 19:23, 6 March 2019 (UTC)
 * Looks like you're heading in the right direction on this. Useddenim (talk) 19:56, 6 March 2019 (UTC)
 * ^I agree! I understand the reasons for consistency, but I feel like there would be so many that would have to change for things like being able to use "Windsor, CT" and "Windsor, Connecticut". I changed all of the "DC" abbreviations to "D.C.", which is the correct official abbreviation. –Daybeers (talk) 23:09, 6 March 2019 (UTC)
 * I'm auditing that data now; I'm thinking it should be possible to remediate them all prior to cutting over this template. Mackensen (talk) 23:23, 6 March 2019 (UTC)
 * Is this same process going to be done with all of the other rail system templates in the U.S.? –Daybeers (talk) 03:42, 10 March 2019 (UTC)
 * If you're talking about migrating to Adjacent stations, then yes. Many already have--SEPTA and Metra being the most prominent, also Via in Canada. If you're talking about the auditing process, only Amtrak (to my knowledge) has this build up of legacy keys, many of which were nonsensical. Mackensen (talk) 15:58, 10 March 2019 (UTC)

I feel pretty comfortable cutting this template over to use the Adjacent stations data module at this point. I reviewed the what links here and tranclusions for all the unusual edge cases and updated quite a few of them. Mackensen (talk) 16:04, 10 March 2019 (UTC)
 * Hi Mackensen, I've been away from Wikipedia for a while, but wanted to check in: did you cut this over yet? It doesn't seem like it, but I'd say it's a go. I've been starting to edit articles to the new stl format and I believe I understand it now. Makes a lot more sense to have a central place to do all the maintenance for all of the rail systems than for each to have its own template. –Daybeers (talk) 04:34, 17 April 2019 (UTC)

Data
I've added the tracking category to get a sense of how many transclusions use 2 (state) or dab: Category:Pages using Amtk with unknown parameters. It'll take a while to populate. Mackensen (talk) 16:30, 6 March 2019 (UTC)
 * 136 as of writing, higher than I might have expected. However, 91 of those are from (for Richmond). Mackensen (talk) 17:32, 6 March 2019 (UTC)