Jump to content

Template talk:Adjacent stations/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4

renderSuccessionBox

@Ythlev: Is there a significant benefit to completely rewriting the HTML generation of the module (bearing in mind that a supermajority of modules do not use the mw.html library at all)? As I understand it the output will be the same and the performance will likely be the same or slightly worse. Jc86035 (talk) 09:51, 25 December 2018 (UTC)

Yes. For example, at line 300, with HTML you don't need to concatenate empty string if no system icon is given. You also don't need to insert a bunch of new lines, pipe symbols and apostrophes. And you said in the past that performance isn't a big concern. Ythlev (talk) 10:03, 25 December 2018 (UTC)
@Jc86035: I've finished coding the basic functionalities. What do you think? The code is a lot cleaner. Ythlev (talk) 17:40, 5 January 2019 (UTC)
@Ythlev: I can't tell very well because of how much code there is, and how different it looks, but it definitely seems better structured now. Jc86035 (talk) 18:08, 5 January 2019 (UTC)

@Ythlev: If it's possible I think it would be better to move the successionBox code into the main module, since it would keep all of the code in one place (benefits for copying to other wikis, other users finding the source of script errors, possibly the revision history). Jc86035 (talk) 03:29, 25 January 2019 (UTC)

@Jc86035: Done. I have to leave you to code the features you originally added such as ["name format"] as I have no idea how they work. Ythlev (talk) 08:28, 25 January 2019 (UTC)

Adding new modules

I gather that there's some checking taking place in Infobox station and possibly elsewhere for the existence of modules before falling back on traditional templates. I'm starting to create Module:Adjacent stations/Metra (unsaved as yet) and I see that a number of things link to it. Is this just color handling? How much of the module needs to be stable and returning reasonable values before I put it into production? Mackensen (talk) 05:11, 27 December 2018 (UTC)

@Mackensen: All of those checks are due to either {{Infobox station}}'s style insertion or {{Rail color box}} (or {{ric}}, {{lnl}}, {{stl}} or {{rcr}}), since those templates use both S-line and Adjacent stations subpages. There's not really a standard for "stable", but I would aim for no script errors and no data (e.g. termini) missing. Jc86035 (talk) 07:56, 27 December 2018 (UTC)
@Jc86035: Thanks, I experimented with the module at a different location before publishing it. It's possible there are some odd corner-cases that aren't working but in general things look good. Mackensen (talk) 20:58, 28 December 2018 (UTC)

Station format logic

Apologies if this was already answered above. It's a common pattern with s-line implementations (see e.g. "Belmont" in {{Metra stations}}) to identify the correct station format based on passed parameters such as line and branch. I know those are available as replacements (%2 and %3), but is it possible/desirable to replicate that concept here? Obviously in the alternative we could use explicit named keys. Thanks, Mackensen (talk) 16:16, 28 December 2018 (UTC)

@Mackensen: Yes, that's implemented, and I've tested that at Module:Adjacent stations/London Underground (Edgware Road / Hammersmith) and Module:Adjacent stations/New York City Subway (Broadway Junction / Halsey Street) – not sure if it's actually used anywhere yet. You can nest another table within that table but I don't think that'll be used more than once or twice. Jc86035 (talk) 17:36, 28 December 2018 (UTC)
Thanks again. I've included that mapping in Module:Adjacent stations/Metra. The code isn't live yet but will be soon; tested fine. Mackensen (talk) 20:59, 28 December 2018 (UTC)

Only showing headers once

A useful feature in the s-rail universe is {{s-rail-next}}, which can be used to suppress the display of the redundant "preceding" and "next" headers where multiple systems are in play and span the system title instead. See Pennsylvania Station (New York City) for a prominent example: the titles headers are shown for Amtrak, but suppressed for the LIRR and NJ Transit. Besides avoiding redundancy, this can make things less cramped when there are long system titles. I would think the module could do this automatically for any systems after the first system. Mackensen (talk) 04:20, 29 December 2018 (UTC)

@Mackensen: I personally considered it inconsistent to do so, and it makes it more difficult to distinguish between "system" headers and "other" (e.g. "Under construction") headers, especially for systems which don't use icons. Usage of {{S-rail-next}} also seems to have significant regional variation:

Country Pages with S-rail-next (approx.)
United States 774
United Kingdom 150
Netherlands 52
Canada 35
Malaysia 31
Japan 29
France 19
South Africa 10
China 8
Singapore 3
Australia 2
Finland 2
Germany 2
Thailand 2
Denmark 1
India 1

{{S-line}} is used for station articles in about 48 countries; {{S-rail-next}} in about 16 countries, and somewhat uniformly in only about five or six of those countries. Hong Kong and Taiwan almost exclusively use {{Adjacent stations}}. While this isn't a very rigorous analysis, there are certainly more than two multi-modal or multi-system stations in Germany or Australia. (The queries I used exclude non-station articles, such as articles for places which use the template.) Jc86035 (talk) 10:00, 29 December 2018 (UTC)

It would certainly be possible to add that functionality, but it would add unnecessary complexity to both the main and convert functions, and I'm not sure if it's desirable. Jc86035 (talk) 10:39, 29 December 2018 (UTC)

US usage is unsurprising given the higher likelihood of multiple operators at a single station and the popularity of using line templates within infobox station (as compared to the UK, for example, where that simply isn't done). I don't know if availability of this feature is a deal-breaker for US adoption of Adjacent stations, but it makes it a harder sell. Mackensen (talk) 20:36, 29 December 2018 (UTC)
@Mackensen, Cards84664, and Ythlev: I really can't see it being a deal-breaker. The s-rail header is about fifteen more pixels of vertical space, which is not exactly hard to come by (even in the infobox), and it makes the different header types easier to tell apart.
If it's genuinely essential, how would this be implemented? Would a |system-nextn=yes sort of parameter be used? Would it be an editorial decision as to whether it's used, would it be set per system, ...?
Would it be better to replace "Previous station" and "Next station" with "Last" and "Next", if it's the vertical space that's an issue? Jc86035 (talk) 08:32, 30 December 2018 (UTC)
I think something like |system-nextn=yes would be a good solution. Mackensen (talk) 15:42, 30 December 2018 (UTC)
I think it would be best to add something like that before implementing country-wide on us articles. Cards84664 (talk) 13:02, 14 January 2019 (UTC)

{{Station link}} is supposed to support line parameters but this doesn't seem to be working: Template:Station link/testcases. The second test has no default case, so it fails with a script error. The third test has a default case which it falls back to, but it's the wrong value for the passed line parameter. Mackensen (talk) 16:35, 5 January 2019 (UTC)

Short name

I'm having an issue where short name doesn't seem to be respected with {{rail color box}}. See User:Mackensen/temp for examples leveraging Module:Adjacent stations/PAAC. I did notice that the last conditional in p._box refers to line instead of lineN, but wasn't sure if this was deliberate and I'm wary of modifying the module. Mackensen (talk) 17:47, 15 January 2019 (UTC)

@Mackensen: short name is only used for the display types where the name is inside a box (route, croute and xroute). For the other styles it's ignored; this is largely deliberate, since templates like {{RouteBox}} tend to be used side-by-side, so you would want to abbreviate them as much as possible. Jc86035 (talk) 15:48, 16 January 2019 (UTC)

Cell height when using notes and merged stations

Unusual situation which I've documented at User:Mackensen/temp#Willow station (PAAC). The goal is to indicate that certain stations were closed by using the note-rightn parameter. The Blue Line - South Hills Village (via Overbrook) should be displayed as going to both Martin Villa (closed 2012) and St. Anne's. The latter box is shared with the Red Line - South Hills Village (via Beechview). The pixel height is so minimal as to be indistinguishable. In the second template I suppressed the note and it works visually, but the closure information is lost. Mackensen (talk) 02:54, 22 January 2019 (UTC)

@Mackensen: I don't really know what to do about this, other than to swap rows 3 and 4 so that the cells aren't merged. Jc86035 (talk) 03:37, 25 January 2019 (UTC)
Yeah, it's a weird corner case. I don't expect it to come up often, or at all, and I worked around it. Thanks, Mackensen (talk) 12:00, 25 January 2019 (UTC)

Module title

@Ythlev: I think it would be better to avoid moving the module to a new title again, particularly if you're not actually going to do all of the page moves in one go. Nthep has already reverted one of the page moves. Any change in the module name would be purely cosmetic, although I'm not going to stop you from making such a change. Jc86035 (talk) 19:00, 28 January 2019 (UTC)

I think it is necessary. I got absolutely confused with what p.style did because of the name. The parameters 'name format', 'header x color' don't mean anything either. It also makes no sense that a lot of templates use 'Adjacent stations' but have nothing to do with the template. All this mess is just confusing to editors. Moving subpages in one go is possible for a page mover, and I wrote it to be to work with existing titles. Ythlev (talk) 19:10, 28 January 2019 (UTC)
By the way, using a new title would allow me to publish templates individually without breaking others. Ythlev (talk) 19:13, 28 January 2019 (UTC)

Requested move 29 January 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: WITHDRAWN. This move is part of a wider move, which should be discussed together. In addition, consensus has changed. Withdrawing to make a centralised request. (non-admin closure) Ythlev (talk) 08:20, 10 February 2019 (UTC)

– New module name Ythlev (talk) 15:19, 29 January 2019 (UTC) --Relisting. SITH (talk) 17:39, 8 February 2019 (UTC)

This is a contested technical request (permalink). Ahecht (TALK
PAGE) 18:06, 29 January 2019 (UTC)
I'm confused by what you're trying to do here. Module:Rail and Module:Adjacent stations are two separate modules, and both are in use. If you just want the documentation for Module:Adjacent stations to show up at Module:Rail, then transclude it (add {{Module:Adjacent stations/doc}} to Module:Rail/doc). --Ahecht (TALK
PAGE) 18:07, 29 January 2019 (UTC)
Module:Adjacent stations is being replaced by Module:Rail, so the doc should be moved to Module:Rail/doc and Module:Adjacent stations should transclude Module:Rail/doc. Of course we could wait until the transition is complete. Ythlev (talk) 18:27, 29 January 2019 (UTC)
I'm also confused, and concerned about the instability of name as this template is being adopted. I think the current name is fine, and I don't understand what the name change would accomplish. Mackensen (talk) 18:24, 29 January 2019 (UTC)
Are you not confused that {{Infobox station}} uses Module:Adjacent stations? Because I was and I broke it because of the confusing name. Ythlev (talk) 18:33, 29 January 2019 (UTC)
I'm not, no. Infobox stations was always tied in to the line templates. Now with Adjacent stations everything's in one place, which is a major win. Mackensen (talk) 18:37, 29 January 2019 (UTC)
Well, you can't assume every editor knows these things. If having them in one place is a major win, so is having sensible names. Ythlev (talk) 19:17, 29 January 2019 (UTC)
If the proposal is to retain all the same functionality in the same place but as Module:Rail instead of Module:Adjacent stations, then that's fine, but it's not clear that you're proposing that. I may also be confused by the edits you were making to Module:Adjacent stations/Amtrak. Mackensen (talk) 20:22, 29 January 2019 (UTC)
Please sort out the nomination. The box at the top of this section says that the proposal is that Module:Rail be renamed and moved to Module:Rail/doc, whereas the first line of text implies that Module:Adjacent stations/doc should be moved to Module:Rail/doc. Which one is correct? --Redrose64 🌹 (talk) 11:26, 30 January 2019 (UTC)
As Redrose64. I'd like to see everything moved back to where it was originally and Module:Rail taken out of use, followed by a nomination explaining what's to be located where, and why. Mackensen (talk) 12:46, 30 January 2019 (UTC)
  • Oppose, because of the unhelpful if not evasive comments by Ythlev in this discussion and in the sections below. Unbelievably frustrating. Mackensen (talk) 00:03, 31 January 2019 (UTC)
  • I don't really mind how the module ends up if it continues to work. If Ythlev is willing to put in the work to make the meaningless name change (which is somewhat functionally beneficial here), I don't have a policy-based reason to oppose it, since the name doesn't matter. What Ythlev wants to do makes sense to me – create the new module's page at the new title, progressively transfer the templates over, history merge the new module with the old module. Jc86035 (talk) 17:02, 31 January 2019 (UTC)
  • Below is the same discussion I post in ANL in response to this incident. After quick examine the original code in Module:Rail that User:Ythlev propose for change, I strongly oppose the move to the new code (Abbreviation for code in Module:Rail). The new code do not have enough comments for others to understand, the definition of each word is everywhere rather than concentrate on the top like the current version. This creates difficult for people like me who love to translate module and templates to other wikipedia. This also makes it actually harder to edit compare to the current version in Adjacent station. In your December comment, you said that you would like to change in order to "benefits for copying to other wikis", but your code just prove the exact opposite of what you are doing. Also, the p.convert function in the new code is exactly the same as the current version. I am currently concerning that the new version do not cover all the exception exist in the old version due to the lack explanation from the other. @Ythlev:, I do suggest you to add enough comments in your code, do the same thing as the current version by creating a Internationalization table at the top for people to do easy translation and explain what you have changed or redo in detail (like I use AA than BB in the XX function of the current version. BB is CC, which is faster or better than the current version) before suggestion for edit. Also, due to the exact same function name in most of the function in both version, I would suggest you to just submit a edit request on the current version rather than asking to convert to your new version in order to preserve the current edit history in Adjacent stations. Also, I agree with User:Jc86035 that the code in Adjacent station is not buggy, but may need a Code refactoring in one or two function. However, I do not think the whole thing need to be redesigned, since your new code actually break everything based on the edit history suggest. I love people want to do Code refactoring, but not without discussion. -- VulpesVulpes825 (Talk) 02:31, 3 February 2019 (UTC)

This move is part of a wider move of having Module:Adjacent stations be renamed to Module:Rail, the discussion for which is below. Ythlev (talk) 16:17, 9 February 2019 (UTC)

Ythlev, if so, then there needs to be a move discussion notification at the main module page. Dekimasuよ! 04:16, 10 February 2019 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Template talk:Adjacent stations

Why was Template talk:Adjacent stations moved to Module talk:Rail? What about Template:Adjacent stations? I assume the move is premature or was a mistake and should be reverted? Johnuniq (talk) 04:44, 30 January 2019 (UTC)

Since the rail-related templates are closely related, the discussion is centralised here. Ythlev (talk) 09:39, 30 January 2019 (UTC)
Enthusiasm is good but the template is not yet using Module:Rail. Also, it is standard for module talk pages to be either kept for discussing internals of the module (not of interest to template users), or more likely to be redirected to the template's talk. If people actually use {{Adjacent stations}} they should discuss its operation at Template talk:Adjacent stations. Johnuniq (talk) 10:01, 30 January 2019 (UTC)
There is barely any discussion about any of the templates, so I don't see why they need to be scattered. But if you think what is 'standard' is so important, feel free to move it back. Ythlev (talk) 11:42, 30 January 2019 (UTC)
It appears that Ythlev (talk · contribs) has pre-empted the outcome of the previous section (which itself is unclear as to the nominator's desired outcome). All recently-moved pages should be put back where they started, and a discussion encompassing all should be held, and nothing moved until the consensus is clear. --Redrose64 🌹 (talk) 11:34, 30 January 2019 (UTC)
Actually I am not the one who moved the doc page. Ythlev (talk) 11:42, 30 January 2019 (UTC)
I'm not talking about the doc page. Like Johnuniq, I'm talking about this page, and here is the proof that you moved it. Where was that move agreed? --Redrose64 🌹 (talk) 12:11, 30 January 2019 (UTC)

You said the previous section, which is about the doc. Where is the rule that all page moves must be discussed? Ythlev (talk) 13:01, 30 January 2019 (UTC)

Uncontroversial moves need not be discussed. This talk page is full of people asking why the page moved, what the future plans are, and indeed what's going on. Why some templates are invoking Module:Rail instead of Module:Adjacent stations, if one's to be renamed to the other. By definition, moving a module with 37,000+ invocations, including on some fairly high-profile pages, is controversial and needs to be discussed. Mackensen (talk) 13:07, 30 January 2019 (UTC)

January 2019 changes

Module:Adjacent stations is buggy and hard to fix because of the structure, which is also hard for new editors to understand. Therefore it has been re-designed. In order to better diagnose problems, it is given a new name: Module:Rail. Code for Station link and Line link have been tested to work fine, so they invoke the new Module:Rail. Code for other templates are still under testing, after which they will also invoke Module:Rail. Module:Adjacent stations/doc has been moved to Module:Rail/doc to match the new module name. In what I thought was an obvious move, I also moved this talk page to also match the new name, but apparently some have problems with it. I am open to being convinced. Ythlev (talk) 13:34, 30 January 2019 (UTC)

  • The problem is that you're posting this now, after a messy and incomplete move, without telling anyone beforehand what you were planning to do. You've been asked numerous questions in the above threads and you haven't answered most of them. You need to understand that the way you've handled this has been highly disruptive. You need to stop what you're doing and answer everyone's questions. Probably everyone will be onboard with what you propose, but you need to take the time to explain yourself. Mackensen (talk) 23:40, 30 January 2019 (UTC)
    • Then how come all the recent major changes to Module:Adjacent stations can be done without discussion? Ythlev (talk) 23:58, 30 January 2019 (UTC)
      • I don't know what major changes you're referring to; I wouldn't call December recent. You're still ducking every question, and I'm tired of it. Also, your most recent change broke display everywhere by adding a superfluous "to" for every "toward X" text. Please don't reinstate this or any other change and please don't use production for testing. Mackensen (talk) 00:09, 31 January 2019 (UTC)
        • It was changed that multi station termini use single layer tables instead of double layer ones. It involved modifying every data module. I think that warrants a discussion more than my change, but was done directly. Also, what questions have I not answered yet? Ythlev (talk) 05:29, 31 January 2019 (UTC)
          @Ythlev: I don't know what table change you're referring to. If you mean ["right terminus"] = {"Chesham","Amersham"}, I'm pretty sure I implemented that in June last year. It was also changed when the template had fewer than 500 transclusions, whereas the template now has more than 1,300.
          I don't think the old version of the module is that buggy. A little hacked together, yes, but "buggy" would be the wrong way to describe it, particularly since no one has reported any bugs other than script errors and things that we can't or wouldn't want to fix. Jc86035 (talk) 16:57, 31 January 2019 (UTC)
          @Ythlev:, it is not what question you should be answer. Rather, it is your responsibility to talk about what EXACTLY did you change in your new template, just a "to better diagnose problems" is not sufficient enough, and also reveal the uselessness of the change, since it can be easily done by simply put in to the sandbox and request edit on this current module. Also, your code actually become way harder to read compare to the current version due to lack of comments and not having a internationalize table. Please stop being ignorant by saying "I thought was an obvious move" and "I am open to being convinced". This is not an obvious move and other editors for the template should be the people who needed to be convinced in order to reach consensus. -- VulpesVulpes825 (Talk) 02:41, 3 February 2019 (UTC)
          • @VulpesVulpes825: I need to write EXACTLY what I changed? BS. When I created the original module, I didn't do that. When one user made countless changes to it they didn't always write talk about them. And is it not obvious that the entire module is different? put in to the sandbox and request edit on this current module I did do the former. I didn't 'request edit' but I did mention the change on this talk page. your code actually become way harder to read compare to the current version due to lack of comments You are the first to think that. Comments are easy to add and would be if you think they are necessary; the re-designed version is much better structured and one user has agreed with me. and not having a internationalize table The table was just moved elsewhere and guess what, that change was reinstated by Pppery on the live version. Ythlev (talk) 05:24, 3 February 2019 (UTC)
            • @Ythlev: I agree that exactly what changed is too extreme, but could you please at least list the reason of the change just a little bit more detail, like "I redone the p.box function which is three times shorter than the current one. This decrease the need of having html code inside the module, which further increase code readability". As I said in my previous comments, I strong support and think all code should go through Code refactoring periodically and I really just need some explanation of what is done before supporting you. I do agree that the new code is better due to the removal of html code. It is better for you to put into the sandbox and have a test-case to show that the external appearance is unchanged. Since the template is now in high use, even you as an author should go through the sandbox and mention it and discuss in the talk page when there is a big change. Just wait for a few days after posting the notification of change and then change it is way better than this current situation. I think the reason why situation goes off track is because the unclear of your mentioning in December, if you said that you will complete redone clearly it should prevent this current situation. About the table, I just see the revert change you done, and I think separate the translation table to another template is a good idea. Also, this is the reason that changing username can cause confusion since I did not link the original author to you. It is best for you to mention that you are the original author of the code, which can certainly gain more support of your change. I am said that the whole situation went off track and I hope this can be resolved quickly. -- VulpesVulpes825 (Talk) 05:43, 3 February 2019 (UTC)

It is better for you to put into the sandbox and have a test-case to show that the external appearance is unchanged I did exactly that. Ythlev (talk) 05:53, 3 February 2019 (UTC)

  • @Ythlev:, ops, I forgot that the module's testcase should be in the template's testcase. I just put your last work in Module:Rail to the Module:Adjacent stations/testcase. The appearance is unchanged to me, which makes me support you. -- VulpesVulpes825 (Talk) 06:29, 3 February 2019 (UTC)

@Pppery: I reverted your lasted edit. You don't get to get to pick and choose which of my edits are 'clear improvements' and which are disruptive editing. And Module:Rail is no longer used by live templates, so by deleting it before this discussion if finished, you are claiming ownership and I will also report you if you keep this up. Ythlev (talk) 04:58, 3 February 2019 (UTC) @Cards84664: This goes to you too. Ythlev (talk) 05:07, 3 February 2019 (UTC)

This is classic WP:OWNership. --Redrose64 🌹 (talk) 17:18, 3 February 2019 (UTC)

Recap of development

@Mackensen:@Redrose64:@Johnuniq: A month or two ago I experimented with re-designing the module at Module:Adjacent stations/sandbox. On 25 December, I explained here why I felt the module should be re-designed. On 5 January, I mentioned in the same section that the sandbox was partially complete. Some time around 28 January I moved Module:Adjacent stations/sandbox and I explained here why I felt it should be renamed. Up until this point, no one rejected my proposals, and I have been tirelessly testing the new code with the sandbox. I had {{Line link}} and {{Rail color}} use the new module after the tests were okay. It was not until I moved the doc and talk pages that it became contentious.

Mackensen, are the following sentences two questions of yours that you wanted answers to? If the proposal is to retain all the same functionality in the same place but as Module:Rail instead of Module:Adjacent stations, then that's fine, but it's not clear that you're proposing that. I may also be confused by the edits you were making to Module:Adjacent stations/Amtrak. It's unclear and you 'may' be confused, but did you wanted me to explain? It sounded like it's unclear but you understood anyways and think it's fine. Ythlev (talk) 15:54, 31 January 2019 (UTC)

About recent development on this talk page

Due to the recent controversial move from Moudle:Adjacent stations to Module:Rail, the talk page is now being to large. Is it OK for me to introduce a achieve bot so that the page can be smaller and contain relevant discussion in order to follow the guideline? Also, since there are three to four heading for the same topic, is it OK for me to combine them in to one and move to ANI in order to centeralize discussion and let people understand exactly is going on? I will indicate on ANI that this whole thread should be archived back to this talk page once this issue is resolved (This is kind of the rule on Chinese Wikipedia that talk should be archieved back to original place once it is finished)? -- VulpesVulpes825 (Talk) 21:19, 2 February 2019 (UTC)

Due to User:Mackensen's explanation of the difference between Chinese wikipedia and English Wikipedia's guidelines on archiving the discussion, I will no longer consider archive the discussion on Module:Rail. However, I am strongly suggest of introduce a archive bot in order to archive the previous discussion before 2018 in order to comply with the guideline. -- VulpesVulpes825 (Talk) 01:02, 3 February 2019 (UTC)
I manually archived to Template talk:Adjacent stations/Archive 1. Johnuniq (talk) 01:25, 3 February 2019 (UTC)

I looked at Special:PrefixIndex/Template:Adjacent stations and Special:PrefixIndex/Template talk:Adjacent stations. I didn't check everything but it seems to be ok except possibly for Template talk:Adjacent stations/testcases. @Mackensen: Would you please check that last link which currently redirects to Module talk:Rail but which probably should redirect to here. Johnuniq (talk) 01:34, 3 February 2019 (UTC)

Update current version of Adjacent stations to Ythlev's version

I do understand the frustration in the current incident, but I do think Ythlev's version is a better version than the current version and here are the reasons:

  • The new version separate the internationalization table to a separate template, which help converting the template to the new version.
  • The new version reduce the code line to less than 700 lines, compare to the current version, which is about 1,000 line.
  • The new version remove all html code like span tag in favor of using :tag{{span}}, this is the preferred way in Javascript of generating html codes. By doing this, dramatically decrease bugginess.
  • The new version eliminate the use of Method chaining, for example, the p.style and p._style function in the current version has now combine to a single p.infobox function. This extremely decrease bugginess since chaining can cause unexpected problem and increase processing time.
  • Most importantly, the new version do not change the external appearance of what the current version would produce. Please go to here to see the test cases. Even through the test cases display yellow heading, there is no visual difference between the current and original version.

Due to the reasons above, I would strongly recommend to merge Ythlev's new version to the current version. This merge should be done by Ythlev themselves since Ythlev is the original author of this module. It is also maybe a good idea to change the name from Adjacent stations to Rail since the name Rail can represent things like line color, which using Adjacent station does not making any sense. I will start request to edit the Module, which is now been template editor protected, after 10 days, if a consensus is made in the discussion in this discussion or no one response, which becomes a silent consensus. -- VulpesVulpes825 (Talk) 06:29, 3 February 2019 (UTC)

Update As I mentioned in the discussion below, I tested the new version in the Chinese wikipedia and it break all the Infobox station template by not letting the Infobox station have the default heading color. Due to the fact that the new version will not produce the correct default color for the heading of the Infobox station, I will not recommend the merge until this problem is fixed. -- VulpesVulpes825 (Talk) 23:10, 3 February 2019 (UTC)

As mentioned below, I wrote it to be different. As far as defaults go, all instances of {{#invoke:Adjacent stations|style|subheader|{{{style|}}}|{{{style2|}}}}} and {{#invoke:Adjacent stations|style|header|{{{style|}}}|{{{style2|}}}}} need to be replaced with {{#invoke:Adjacent stations|infoboxStation|{{{style|}}}|{{{style2|}}}|_header}} and {{#invoke:Adjacent stations|infoboxStation|{{{style|}}}|{{{style2|}}}|_subheader}} respectively. The data modules have a different structure too. Again, I am not going to put in more effort unless there are is some reassurance that my hard work is not just gonna get thrown out the window. Ythlev (talk) 23:47, 3 February 2019 (UTC)
The ANI hasn't had new comments from OP for a few days. I am going to assume it is a closed case. I will post what the plans are below. Ythlev (talk) 06:04, 7 February 2019 (UTC)
First I need do deal with ANI and Wikipedia:Redirects for discussion/Log/2019 February 2#Module:Rail. I don't really care about the name anymore. Go ahead and delete Module:Rail, but save the code somewhere first if you support the refactoring. Ythlev (talk) 06:36, 3 February 2019 (UTC)
Just wait a few days when everything comes down and in order to gain silent consensus. I am neutral on the name change, but I do suggest to just push the change here, which can gain consensus easier. The code is now store in the Module:Adjacent stations testcases, which should in theory kept there forever unless this module is deleted. I understand it is extremely frustrated since I am currently trying to combine about 10-12 Rail station infobox to Infobox station in Chinese Wikipedia, and it is extremely hard to get consensus even with a discussion. I hate this kind of discussion, but the discussion still needed to happen due to the guideline. -- VulpesVulpes825 (Talk) 06:47, 3 February 2019 (UTC)
It seems by using the new version, the Infobox station will no longer display color for the headings. -- VulpesVulpes825 (Talk) 08:21, 3 February 2019 (UTC)
I plan to change how Infobox station style is used. I've tested it to work with the new method, but all the changes were reverted. As for what the change is, it is pointless to explain right now when it is unclear whether other editors approve of the idea of refactoring. Ythlev (talk) 08:32, 3 February 2019 (UTC)
I can't show you that the new method works because the even the sandbox and testcases were reverted by User:Cards84664. Ythlev (talk) 08:34, 3 February 2019 (UTC)
I asked repeatedly in the threads above what those changes were, and you never answered. You made a dozen edits to Module:Adjacent stations/Amtrak with explanation or even an edit summary. I was concerned that these changes might break the display in production and I didn't know what would use them. This isn't a great way to develop a module. I have no objection in principle to a refactoring, but we have talk pages, sandboxes, and test cases, and you should use them. Mackensen (talk) 17:11, 3 February 2019 (UTC)
And as explained in the recap above, I used all three. And why am I not allowed to experiment with Module:Adjacent stations/Amtrak? I didn't touch existing tables, only added a new one, which the live templates would just ignore. Ythlev (talk) 17:29, 3 February 2019 (UTC)
Not to mention I never finished the code for Infobox station and never published it for the live template. It was work in progress, so whatever I brought up may have become outdated anyways. Ythlev (talk) 17:34, 3 February 2019 (UTC)

Template-protected edit request on 3 February 2019

Request revert version back to [Pppery's version]. It is a good idea to move the internationalization table to a separate table so that it is easier for people like me to translated it into other Language version. -- VulpesVulpes825 (Talk) 23:15, 3 February 2019 (UTC)

@VulpesVulpes825: You're confused. Both the current version and the version you link to have the i18n in a separate table, and the only difference is whether that table is located on a separate page, which does not make localizing the module any easier. {{3x|p}}ery (talk) 00:13, 4 February 2019 (UTC)
Regardless,  Done, as removing code duplication from modules is generally considered a good thing. {{3x|p}}ery (talk) 02:54, 4 February 2019 (UTC)

February 2019 changes

Notifying Mackensen, VulpesVulpes825, Redrose64, Johnuniq and Ahecht. Jc86035 (talk) 09:12, 7 February 2019 (UTC)

For Module:Adjacent stations, I propose the following changes. Ythlev (talk) 07:08, 7 February 2019 (UTC)

  • @Ythlev: As above, I support the restructuring and the module rename. I'm fine with the change to the colour codes, as long as you don't break anything, although this would introduce an inconsistency with S-line. I'm not really sure if changing the infobox function would be beneficial for users, and it would necessitate an extra step in S-line conversion, but I personally haven't used it in a while so I don't know if this would be disruptive. I think it would be better if {{Line link}} and {{Rail color box}} retain their current functions, at least until {{S-line}} templates have been completely replaced, since the vast majority of {{Rail color box}} uses are with S-line helper templates, using the original styles; furthermore, {{Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing, especially since you would be adding at least two of the original {{Rail color box}} functions to the template. Jc86035 (talk) 09:12, 7 February 2019 (UTC)
  • Support, As I mentioned above, I do think the new version is better since the new version illuminate pure html code. I may able to do a beta testing on the Chinese wikipedia to give it a try. As for {{Rail color box}},{{Rail icon}}, {{Rail color}} and {{Line link}}, I do think it a good idea to combine all into one template (with backward compatibility if possible) since all four template's function overlap with each other. However, I do think it may be a good idea to separate the merge request as a new request rather than been part of the code refactoring request, since this may need a longer discussion which may delay the code update to the main module. -- VulpesVulpes825 (Talk) 18:13, 7 February 2019 (UTC)

Re-structure

As mentioned above by VulpesVulpes825, the code benefits from a better structure. The current version re-invents the wheel like the functions of mw.text.listToText and Module:TableTools. Ythlev (talk) 07:08, 7 February 2019 (UTC)

As above, I support the restructuring and the module rename. Jc86035 (talk) 09:12, 7 February 2019 (UTC)
  • Module:Adjacent stations/sandbox is currently different from Module:Adjacent stations (diff). Is the proposal that the main module be replaced with the sandbox? If so, I have some minor style objections. (1) Use one blank line between functions; (2) Do not combine multiple variable declarations with assignment ("local p, data, ..."); (3) Typo "typedata" should be "typeData"; (4) Are the module-level globals in the first line really necessary? What tests are available? Johnuniq (talk) 09:47, 7 February 2019 (UTC)
    • Is the proposal that the main module be replaced with the sandbox? It is still under discussion. (1) Use one blank line between functions; (2) Do not combine multiple variable declarations with assignment ("local p, data, ..."); The code is already nearly 700 lines long. All that and it would be too long to navigate. (4) Are the module-level globals in the first line really necessary? They are not globals, they are variables local to the entire module. They are there because they are used by more than one function. You could pack them into the args table or have the functions take those as arguments, but what does it matter? You would only be confusing editors. Ythlev (talk) 09:59, 7 February 2019 (UTC)
      • Support Johnuniq's comments about the space between functions, naming of parameters and the multiple declarations issues. All of these make the code easier to read for other editors and make editing it later on easier (again, for other editors). Regarding #4, this is more of a semantic issue - a local variable is local to the function it is used in, a global variable is available to the entire "class" (in this case, the module). --Gonnym (talk) 12:39, 10 February 2019 (UTC)

Support, As I mentioned above, I do think the new version is better since the new version illuminate pure html code. I may able to do a beta testing on the Chinese wikipedia to give it a try. -- VulpesVulpes825 (Talk) 18:13, 7 February 2019 (UTC)

Rename to Module:Rail

Apart from the fact that this name makes more sense, the module is used by several templates. The code for each template may be dependent on each other. It is much easier to use a new module, then for each function that is tested to work properly, have the template invoke the new module. Ythlev (talk) 07:08, 7 February 2019 (UTC)

As above, I support the restructuring and the module rename. Jc86035 (talk) 09:12, 7 February 2019 (UTC) Ythlev (talk) 08:47, 10 February 2019 (UTC)

I've made a move request below. Please comment there instead. Ythlev (talk) 08:49, 10 February 2019 (UTC)

Colour

I propose that all colour codes be prepended with '#' since they are machine-read and need to have the symbol. The current sandbox version supports hashed and unhashed codes for backwards compatibility. Ythlev (talk) 07:08, 7 February 2019 (UTC)

I'm fine with the change to the colour codes, as long as you don't break anything, although this would introduce an inconsistency with S-line. Jc86035 (talk) 09:12, 7 February 2019 (UTC)

Infobox station style

The HTML library supports structured CSS arguments. I propose the below structure for data modules so that barely any code is needed to process the arguments.

Current Proposed 
local p = {
	["name format"] = {
		"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E;  padding: 0.4em 4px;",
		["Amtrak old"] = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9;  padding: 0.4em 4px;"
	},
	["header background color"] = {
		"00537E",
		["Amtrak old"] = "0078B9",
	}
}

local p = {
	["infobox station"] = {
		["header"] = {
			"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E;  padding: 0.4em 4px;",
			["Amtrak old"] = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9;  padding: 0.4em 4px;"
		},
		["sub-header"] = {
			"background-color: #00537E; color: #FFFFFF",
			["Amtrak old"] = "background-color: #0078B9; color: #FFFFFF",
		},
	},
}

I also propose swapping positional arguments to bring it in line with other templates.

Current Proposed
{{#invoke:Adjacent stations|style|header|{{{style|}}}|{{{style2|}}}}} {{#invoke:Adjacent stations|infoboxStation|{{{style|}}}|{{{style2|}}}|_header}}

Ythlev (talk) 07:08, 7 February 2019 (UTC)

I'm not really sure if changing the infobox function would be beneficial for users, and it would necessitate an extra step in S-line conversion, but I personally haven't used it in a while so I don't know if this would be disruptive. I think it would be better if {{Line link}} and {{Rail color box}} retain their current functions, at least until {{S-line}} templates have been completely replaced, since the vast majority of {{Rail color box}} uses are with S-line helper templates, using the original styles; furthermore, {{Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing, especially since you would be adding at least two of the original {{Rail color box}} functions to the template. Jc86035 (talk) 09:12, 7 February 2019 (UTC)

I'm not really sure if changing the infobox function would be beneficial for users, and it would necessitate an extra step in S-line conversion Well, the easiest thing to do would be to not convert at all.
  • @Ythlev: What do you mean by "not convert at all"? Are you suggesting that existing CSS in {{system style}} templates should just be deleted or left in their place when those systems' templates are replaced?
I mean the module supports non-Lua {{system style}} templates, so if a user thinks the extra step of structuring the arguments is too much work, they can just not convert at all and use non-Lua. There is no point of converting to the structured Lua module if it still uses unstructured data. Ythlev (talk) 16:06, 9 February 2019 (UTC)
  • Regarding the changes for Infobox station support, a few questions:
    • In other parts of this module where there's a sub-type (for lack of a better term) keys propagate down unless specifically overridden. Will that be the case here? If I define "background color" for the root element _header, would that be re-used for the "old Amtrak" style unless I overrode it? I think that would be desirable behavior. With Module:Adjacent stations/SEPTA, there are several major name_format implementations which are identical except for background color.
I've coded this in. Ythlev (talk) 13:16, 7 February 2019 (UTC)
    • Are the supported keys for CSS styles arbitrary?
It supports whatever Scribunto supports, which I'm going to assume is every CSS property. You will need to ask the Scribunto community to be sure. Ythlev (talk) 13:16, 7 February 2019 (UTC)
    • For clarity, should the key structure be reworked so that it's similar to lines? Have a top level infobox station or whichever, then _default, with _header and _subheader beneath it, and named keys such as "Amtrak old". I think that would be clearer for people reading it, and internal symmetry is helpful when implementing.
The vast majority of systems don't even have Infobox station styles let alone sub-styles. I don't think nesting it under another table is necessarily easier. Alternatively we could nest the default CSS under lines['_default'] and treat sub-styles as lines, if it makes sense. Ythlev (talk) 13:16, 7 February 2019 (UTC)

Infobox rail line style

Notifying Jc86035. Ythlev (talk) 18:35, 9 February 2019 (UTC)

I propose that the style setting function be extended to {{Infobox rail line}}, as it is similar to station. Ythlev (talk) 18:15, 9 February 2019 (UTC)

@Ythlev: I think you should ask on that template's talk page first, since it currently has nothing to do with this module and nothing to do with the S-line templates. I don't know if this would be desirable (although if it is, it might also be useful for the other rail infoboxes). Lines would have different styles to stations, so you would need to have a way to account for that. Jc86035 (talk) 10:36, 10 February 2019 (UTC)

Merging Rail color box

I propose merging {{Rail color box}} (RCB) into {{Line link}} and {{Rail icon}}, with backwards compatibility. RCB already displays line link for four styles. Link link can just have a parameter that prepends the box. Line link should also be able to prepend icons, as this is frequently used. Rail icon currently can be set to display RCB. It should be designed to let users set which style of RCB to use and completely replace RCB.

These changes have not been coded yet. Ythlev (talk) 07:08, 7 February 2019 (UTC)

I think it would be better if {{Line link}} and {{Rail color box}} retain their current functions, at least until {{S-line}} templates have been completely replaced, since the vast majority of {{Rail color box}} uses are with S-line helper templates, using the original styles; furthermore, {{Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing, especially since you would be adding at least two of the original {{Rail color box}} functions to the template. Jc86035 (talk) 09:12, 7 February 2019 (UTC)

I think it would be better if {{Line link}} and {{Rail color box}} retain their current functions, at least until {{S-line}} templates have been completely replaced Rail color box would be just left working as it is. {{Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing I think it is equally confusing that Rail icon can be set to display RCB. RCB is just a really weird template. Instead of letting users customise the output like |linked_box=yes or |show_text=yes, it just has 12 pre-defined styles that seemingly come from nowhere. you would be adding at least two of the original {{Rail color box}} functions to the template.. If you are referring to the code structure, I'm pretty sure that it can be written to be not be confusing. Ythlev (talk) 09:49, 7 February 2019 (UTC)
  • The reason that {{Rail icon}} can display RCB is because it was originally supposed to replace {{Rail-interchange}}. I would only make breaking changes to {{rcb}} (particularly if they affect |inline=yes) if they make the template easier to use, which adding several long named parameters wouldn't do.
    The reason that these seemingly random icons are there is because the new styles are commonly used already (e.g. croute and xroute are used for S-Bahn lines and other European services; square is used for Japanese lines), and not because I thought it would be ideal or totally MOS-compliant to add them. Having them in the module makes it possible for more icon templates and copied-and-pasted symbols to be replaced. Jc86035 (talk) 15:03, 9 February 2019 (UTC)

As for {{Rail color box}},{{Rail icon}}, {{Rail color}} and {{Line link}}, I do think it a good idea to combine all into one template (with backward compatibility if possible) since all four template's function overlap with each other. However, I do think it may be a good idea to separate the merge request as a new request rather than been part of the code refactoring request, since this may need a longer discussion which may delay the code update to the main module. -- VulpesVulpes825 (Talk) 18:13, 7 February 2019 (UTC)

Requested move 10 February 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: No consensus (closed by non-admin page mover) SITH (talk) 15:23, 3 March 2019 (UTC)


– The module is being re-structured as discussed above. In addition to making more sense as a name, the new title allows a smoother transition by allowing templates to be tested individually. Ythlev (talk) 08:43, 10 February 2019 (UTC)--Relisting. Warm Regards, ZI Jony (Talk) 17:49, 16 February 2019 (UTC)--Relisting. Dekimasuよ! 18:52, 23 February 2019 (UTC)

As above, I support the restructuring and the module rename. Jc86035 (talk) 09:12, 7 February 2019 (UTC) Ythlev (talk) 08:48, 10 February 2019 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Regarding Station Header

In Template:S-rail/lines, you are able to only display a picture of the system title with a clickable link, since sometime the icon of the system only contains name. In Adjacent station, I do not think it is possible without displaying the text. Could we have a new parameter name like system header format, which can let editor put an image in without displaying the name of the system in word? -- VulpesVulpes825 (Talk) 04:22, 15 February 2019 (UTC)

I don't quite understand. If you want only the icon and not text, can you not just leave system title empty? Ythlev (talk) 05:21, 15 February 2019 (UTC)

title is missing from the data page

Campanelli Stadium is showing "Lua error in Module:Adjacent_stations at line 403: "title" is missing from the data page" in the infobox due to use of {{rail color box|system=MBTA|line=Middleborough/Lakeville}}. Module:Adjacent stations/MBTA seems to have an entry. I'm hoping someone here will fix the problem. Johnuniq (talk) 09:09, 8 March 2019 (UTC)

Similar at

Johnuniq (talk) 09:15, 8 March 2019 (UTC)

Implementing the 2019 re-structure

Please change the code to the that in the sandbox, proposed previously, as it has been tested to work. Refer to the testcases for details. Visible changes include support for hashed colour codes, type being rendered in parentheses, and new parameters to add or modify icons and boxes. Ythlev (talk) 10:38, 15 March 2019 (UTC)

Question: how is this going to work with background gradients? Module:Adjacent stations/SEPTA and Module:Adjacent stations/MBTA use these. They require multiple declarations of background-image to implement. Mackensen (talk) 12:11, 16 March 2019 (UTC)

@Mackensen and Ythlev: For what it's worth, I think it might not be necessary to use multiple declarations, since the prefixed values are no longer necessary in most browsers. {{Linear-gradient}} still outputs all the values, though. Jc86035 (talk) 16:30, 19 March 2019 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template.. This restructure seems to be controversial, per discussion above. {{3x|p}}ery (talk) 18:01, 16 March 2019 (UTC)

@Mackensen:@Jc86035: Regarding infobox station styles I'm more inclined to agree with you now. I don't know how the current version is written, but I find it incredibly hard to write a function that is doubly backwards compatible, and the html library doesn't seem to support gradients. I think I'm just use unstructured styles. However I think the three tables should still be placed under ['infobox station'] otherwise newcomers would have no idea what they are. Ythlev (talk) 19:50, 17 March 2019 (UTC)

Current Proposed 
local p = {
	["name format"] = {
		"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E;  padding: 0.4em 4px;",
		["Amtrak old"] = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9;  padding: 0.4em 4px;"
	},
	["header background color"] = {
		"00537E",
		["Amtrak old"] = "0078B9",
	}
}

local p = {
	["infobox station"] = {
		["header"] = {
			"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E;  padding: 0.4em 4px;",
			["Amtrak old"] = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9;  padding: 0.4em 4px;"
		},
		["sub-header"] = {
			"background-color: #00537E; color: #FFFFFF",
			["Amtrak old"] = "background-color: #0078B9; color: #FFFFFF",
		},
	},
}
Oppose Until above issues are settled. Cards84664 (talk) 20:06, 17 March 2019 (UTC)

Fixed Infobox station

Please copy respective sandboxes for these two pages. In response to the issue raised by Mackensen and following the suggestion of Jc86035, I've made the infobox function work with existing formats (testcases). Ythlev (talk) 06:28, 19 March 2019 (UTC)

 Done Jc86035 (talk) 16:33, 19 March 2019 (UTC)

@Ythlev: I've reverted both changes because something broke and I don't know why.

Original Proposed change
Preceding station MTR MTR Following station
Fortress Hill
towards Kennedy Town
 Island line Quarry Bay
towards Chai Wan
Terminus Tseung Kwan O line Quarry Bay
towards Po Lam
Tseung Kwan O line
Rush hours only
 Quarry Bay
towards LOHAS Park
Former
Quarry Bay
towards Yau Ma Tei
 Kwun Tong line
2001–2002
 Terminus
Planned (North Island Line extension)
Causeway Bay North
towards Tamar
 Tseung Kwan O line Quarry Bay
towards Po Lam
Tseung Kwan O line
Rush hours only
 Quarry Bay
towards LOHAS Park
Preceding stationMTR MTRFollowing station
towards Kennedy Town
Island line
towards Chai Wan
Terminus
Tseung Kwan O line
Tseung Kwan O line
Rush hours only
towards Po Lam
Former
towards Whampoa
Kwun Tong line
2001–2002
Terminus
Planned (North Island Line extension)
towards North Point
Tseung Kwan O line
towards Po Lam
Tseung Kwan O line
Rush hours only
towards Po Lam

Jc86035 (talk) 17:00, 19 March 2019 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template.. This restructure seems to be controversial, per discussion above. {{3x|p}}ery (talk) 18:01, 16 March 2019 (UTC). As far as I can tell, no new consensus has developed in favor of this request since then. {{3x|p}}ery (talk) 22:15, 19 March 2019 (UTC)

Using Wikidata for adjacent stations?

It would be really cool to use adjacent station (P197) with the towards (P5051) and connecting line (P81) qualifiers. The terminus (P559) of the connecting line (P81) can be used for orientation (including, perhaps, the terminus (P559) direction (P560) to help decide which way should be left and which should be right, e.g. north/west as right and south/east as left). --Hhm8 (talk) 01:45, 27 March 2019 (UTC)

(Module:Adjacent stations can probably have some of the Wikidata integration implemented there too). --Hhm8 (talk) 01:48, 27 March 2019 (UTC)
Please, no. We're having enough trouble with people trying to pull infobox information from Wikidata. --Redrose64 🌹 (talk) 19:40, 27 March 2019 (UTC)
Oppose all Cards84664 (talk) 21:06, 27 March 2019 (UTC)

@Hhm8: The data is just not mature enough yet (we haven't even figured out how to do one-way services properly yet). When planning how this template would function, I reasoned that it would be a few years until Wikidata could be used for this. Unless you want to do all of the importing work and all of the referencing and all of the vandalism reverting, I don't think this is a possibility in the short term. Maybe for a few stations, like Tsuen Wan West station (Q841883), it would be possible, but otherwise the data is far too incomplete. You'd also have to half-rewrite the module again, and that's already been done at least twice.

Also, another issue with taking all of the data is that you'd have to figure out how to present it without making it look weird; e.g. for Tsuen Wan West station, the terminus change in 2009 is not shown in the table, but nevertheless needs to be included in Wikidata in order to make the statements complete. Jc86035 (talk) 16:42, 17 April 2019 (UTC)

Shortcut

Hello, I was wondering if it would be possible to have a shortcut for some subpages, e.x. "wmata" for "Washington Metro". In my editing of transit articles over the past few years, I have been quite agressive in changing traditional page links to the appropriate system template in article bodies, e.x. [[Vienna station (Washington Metro)|Vienna]]->{{wmata|Vienna}} ({{wmata}} is a shortcut for {{WMATA stations}}). Changing the above example to the {{stl}} format adds an unnecessary 15 characters. –Daybeers (talk) 06:00, 17 April 2019 (UTC)

@Daybeers: I suggested something like that about three months ago but got a lot of push-back. See User talk:Mackensen#"Generic template" edits. Useddenim (talk) 11:00, 17 April 2019 (UTC)
Thanks for that reading! I think it should be a guideline when using this template in RDTs that the shorthand version of templates are used, ex. {{rcb}} for {{Rail color box}} and {{rcr}} for {{Rail color}}.

Can't we just have all of the existing templates be redirects instead of the current practice of deleting them when adjacent stations is fully implemented? For example, have {{wmata|Vienna}} redirect to {{stl|Washington Metro|Vienna}}. –Daybeers (talk) 16:06, 17 April 2019 (UTC)

As I stated in the discussion Useddenim linked (to which he never made any response, at least I now know he read my responses), there's no performance impact with using a certain number of characters. It's irrelevant. Introducing an intermediate template does probably cause a performance hit, and arguably is bad for comprehension and readability. It's pretty obvious what {{station link}} does. {{wmata}}? {{amtk}}? {{bts}}? It's non-obvious what those do and I think their usage should be discouraged. "An unnecessary 15 characters" is not a burden on anyone and does not justify creating an entire set of template redirects.
Now, all that said, I've said on multiple occasions that these templates can be changed to use this data module instead. I'd be happy to link those instances for people. No one's stopping anyone from doing that, though given that in most cases there's not a 1-1 correspondence between the old "X stations" and the new data modules I've been reluctant to do so for fear of link breakage. That's especially true from amtk/amtrak stations, given various parameter issues discussed on that template's talk page. Mackensen (talk) 16:21, 17 April 2019 (UTC)
@Mackensen: Yes, I read it; I just didn't have anything to add as it seemed that neither of us was going to change the other's opinion. Useddenim (talk) 20:34, 17 April 2019 (UTC)
@Daybeers and Mackensen: I've created Module:Adjacent stations/WMATA so fewer characters have to be used. Several other systems already have these pseudo-redirects. Jc86035 (talk) 16:35, 17 April 2019 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Adjacent_stations/Archive_2&oldid=967239663"