Template talk:Adjacent stations/Archive 1

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

In the

({{rail color box/sandbox|system=RTD|line=W}})

({{rail color box/sandbox|system=RTD|line=W|inline=yes}})     W Line ({{rail color box/sandbox|system=RTD|line=W|inline=small}})  W Line

({{rail color box/sandbox|system=RTD|line=W|inline=gibberish}})

• I also added a new option, inline = box, that is simply a color box in the correct color: ({{rail color box/sandbox|system=RTD|line=W|inline=box}})    

If there aren't any objections I will merge this in with the main code. -Killian441 (talk) 17:27, 9 January 2013 (UTC)

There has been no discussion here, but I also posted this to Wikipedia talk:WikiProject Trains and the feedback there was this was good to implement. As the main code is protected, I have requested an edit here. The code in the sandbox should be copy over. Or if the page become unprotected I will do it myself. -Killian441 (talk) 19:13, 10 January 2013 (UTC)

 Done. JohnCD (talk) 14:30, 21 January 2013 (UTC)

Use of this template as {{Rail color box|system=PLR|line=Red Castle Shannon}} generates four lint errors:

• 2 Missing end tag </small>
• 2 Multiple unclosed formatting tags <small>

This is causing errors in 27 articles, which can be seen at Lint errors: Multiple unclosed formatting tags (Article).

I don't understand how this template works; I don't know where the data files are, but wherever the data is stored, just insert one or two missing </small> tags in rows associated with the Pittsburg Light Rail (PLR) system, the Red Castle Shannon line. —Anomalocaris (talk) 04:54, 16 March 2018 (UTC)

@Anomalocaris: Since it's not widespread, but the template is in wide use, it's probably a subtemplate problem. To find such subtemplates:

1. reduce the offending markup as far as possible - you've already done this with {{Rail color box|system=PLR|line=Red Castle Shannon}}
2. identify some distinct feature that will aid searching - in this case I shall use the word "Shannon"
3. go to
   WP:SANDBOX
   and click its edit tab
4. blank it out entirely (if you don't, the list we're about to generate gets way too long and complicated)
5. paste in the code that you've isolated so far
6. click Show preview
7. look near the bottom of the page, there should be a list of "Templates used in this preview" (which may need expanding using the little triangle icon); when I try this I get:
   • Template:Legend (edit) (template protected)
   • Template:PLR color (edit) (semi-protected)
   • Template:PLR lines (edit)
   • Template:Rail color box (edit) (template protected)
   • Template:Trim (edit) (protected)
8. Trying each of the listed templates one by one:
   1. using the "edit" link provided, open it for editing
   2. search for the word "Shannon"
   3. if found, examine the markup nearby, and fix it if necessary.

Using this method, I made this edit which should fix your issue. No need to add any missing </small> at all. --Redrose64 🌹 (talk) 09:26, 16 March 2018 (UTC)

Please forgive me for straying off topic but I'd appreciate a bit of technical help with WP's HTML tags please. It may even be relevant to this template!

1. Lots of templates such as {{Planetbox separation}} have small without /small. But when I look at the rendered HTML from GQ Lupi b which transcludes it, a matching /small magically appears. Does the Mediawiki software detect the imbalance and insert a closing tag? If so, do we still care about articles or templates with an imbalance?
2. The lint report shows pages such as 2002 FIFA World Cup statistics. But the wiki source has the small and /small tags nicely balanced, and so does the HTML on the rendered page. The W3C validator agrees. "Related changes" shows no recent fixes. What have I missed?

Thanks for your time, Certes (talk) 11:28, 16 March 2018 (UTC)

In HTML, elements may be nested (<b>Some <i>Text</i> marked up</b> is valid), but must not overlap (<b>Some <i>Text</b> marked up</i> is invalid). In pure HTML, with certain exceptions, every opening tag must be balanced by a matching closing tag; the small element is one of those for which there isn't an exception - its documentation says "Neither tag is omissible". Many browsers will spot that a closing tag has been omitted by pretending that it is in fact present, so when one of these browsers finds markup like this:

<a href="/wiki/Red_Line_(Pittsburgh)">Red Line<br><small>Castle Shannon<small></a>

it will treat the </a> as if it closed both of the outstanding small elements, i.e. as if the actual HTML were

<a href="/wiki/Red_Line_(Pittsburgh)">Red Line<br><small>Castle Shannon<small></small></small></a>

but such behaviour is browser-specific and so cannot be relied upon.

The MediaWiki software (which is what takes the raw source, expands templates and converts it all into HTML) leaves most HTML tags alone, that includes <small> and </small>. At present, the MediaWiki software then puts the resultant HTML through something called HTML Tidy (a.k.a. Tidy), which attempts to clean up tag imbalances. The Tidy feature is in the process of removal (see for example Wikipedia:Village pump (technical)#Tech News: 2018-11 and archives of that page going back for more than a year), which is why we now have a panic on to sort out all of those lint errors.

Regarding 2002 FIFA World Cup statistics and similar: the problem is with Template:Fb cl3 footer which for certain combinations of parameters, is not emitting sufficient </small>. This edit should fix it. --Redrose64 🌹 (talk) 13:14, 16 March 2018 (UTC)

Thank you. I've found about 100 templates like {{Planetbox separation}}. In a few cases, {{Foo start}} may legitimately put out small in the hope that {{Foo end}} will put out the matching /small. Do you think the rest need to be fixed? Certes (talk) 14:04, 16 March 2018 (UTC)

That one's a simple fix. What are these {{Foo start}} / {{Foo end}} which you mention? --Redrose64 🌹 (talk) 16:19, 16 March 2018 (UTC)

Yes, that was easy. I was just checking that it should be done. I'll press on with fixing the similar templates. Thanks for your help. ("Foo start" isn't important. I was just imagining a hypothetical example that deliberately inserted an unmatched tag and expected the caller to call "Foo end" to insert its partner. We'd want to leave such templates alone, but there is probably no such example.) Certes (talk) 19:15, 16 March 2018 (UTC)

I didn't see the notice, but it looks like {{

• News to me. Mackensen (talk) 18:17, 22 April 2018 (UTC)

  Pinging Szqecs, who created them yesterday. Is there something you might want to tell us about? Primefac (talk) 22:36, 22 April 2018 (UTC)

Yes, I mentioned that I hope to create a Lua version. However it is still quite rough now. Feedback is welcome. Szqecs (talk) 10:44, 23 April 2018 (UTC)

@Szqecs: The primary issue with this right now, I think, is that this still doesn't seem to have enough advantages over the current set of templates (the transclusions look much the same), especially since it also adds disadvantages such as the current requirement to use |rows=mid and the need for many contributors to learn or improve Lua table skills even though they already know how to use switch parser functions (as well as the feature discrepancy). The only advantage, as far as I can tell, is that the data is all in one place, and this is probably not going to be enough and would also be considered reinventing the wheel. If you can make the table one template (e.g. like Routemap vs. BS-map, or like {{Infobox}} vs. wikitable code) and make it merge table cells automatically, then it will very likely be sufficiently better than the current system. Right now, the current system is slightly more inefficient but much easier to use and extend, and probably more useful overall. Take advantage of Lua's capabilities to make using the template as efficient and as painless as possible.

It shouldn't be too hard to change L-rail into a single template, especially since the groundwork for using arbitrarily numbered named parameters already exists in Module:Infobox (I re-used the code in Module:Routemap, incidentally, to allow more than ten maps). Avoiding per-article customizations such as row merges also makes using Wikidata data – at some point in the future – much easier.

Furthermore, I notice you've put a link function at the top of every data page. I don't think it's necessary, and I think using %s for a station name will probably be more intuitive and will be easier to explain in the template documentation (you should keep as much code as possible inside the main module, and the data pages should ideally have no functions so that they're easier to write – e.g. allowing the use of _default table keys instead of needing a whole function).

Finally, I think it would be best to follow stylistic conventions such as putting commas before newlines so that it's easier for others to read your code (even though it's not strictly necessary to do so in Lua). Jc86035 (talk) 12:12, 23 April 2018 (UTC)

I'm lost. 1: What do you mean by 'merging cells' and 'arbitrarily numbered named parameters'? 2: What do you mean by using %s? Szqecs (talk) 12:58, 23 April 2018 (UTC)

@Szqecs:

1. By "merging cells" I meant usage of colspan and rowspan HTML attributes to combine table cells; an example exists at Template:S-line#One-way operation (several others further down the page). With the current {{S-line}}, |rows1= etc. and |hide1= etc. are used to manually specify cells which span more than one row. By "arbitrarily numbered parameters" (I apologize for using a vague term for something that doesn't actually have a name), I meant named parameters which are suffixed by a number which has no meaning other than to indicate the order of the data in the template; e.g. |header1=, |label2=, |data2=, etc. in {{Infobox}}.
2. I used %s in line with mw:Extension:Scribunto/Lua reference manual#string.format. For example, if local example = '%s station', then return string.format(example, 'Taipei') would produce the string Taipei station. More than one %s is supported. However, for this module I would use mw.ustring.gsub() or similar for this, since the only input to such a function would be the station name. There may be better ways to do this, but sticking a function inside the data table is probably unnecessarily complex for an editor who is never going to edit the main module itself.

Also, I notice that you haven't allowed for a link table for all lines. This capability (which is the default in the current template) would be quite useful, both for ease of use and for ease of importing existing data. Jc86035 (talk) 13:38, 23 April 2018 (UTC)

@Frietjes: This stems from Template talk:S-line#Lua version. Do you think it'd be necessary to modify the data structure to make the subpages easier to edit? Jc86035 (talk) 13:40, 23 April 2018 (UTC)

• Merging cells is a feature I have yet implemented. It seems complex though.
• My module does allow for multiple lines using arbitrarily numbered parameters, but not for multiple systems. This is because if the system parameter was treated the same way you would have to repeat it for the same system (e.g. |system1=Taipei|line1=R|system2=Taipei|line2=G).
• Actually the link function is optional, and is used to make the module shorter. You could type all the Wikitext as is, but the data module would be huge and messy like Template:LUL stations. Using string.format seems like a good idea but I have no idea how it works, specifically the 'ISO C function sprintf' thing. Szqecs (talk) 14:38, 23 April 2018 (UTC)

@Szqecs: I might work on the pseudocode (collapsed) above and see if it works. I don't think you would need to repeat the system's name: you could have it in |system1=, and then for every row thereafter until the next |systemn= parameter, the system would be assumed to be |system1= (e.g. system1, line2 (left2, right2, …), line3, line4, system5, line6, line7, …). I don't think this would be more complicated than the current system, especially since it's already been implemented in Module:Infobox.

 Done Szqecs (talk) 11:47, 24 April 2018 (UTC)

I think keeping the links as plain wikitext internally would make it simpler – editors will be more used to the wikitext, and you don't actually need to escape any of the characters that you've escaped. As mentioned, string.format() would probably be unnecessary (I don't really know completely how it works either) since you could just use the Lua regular expressions through mw.ustring.gsub() for this particular module. Jc86035 (talk) 16:20, 23 April 2018 (UTC)

@Jc86035:

1. What is args.nums for? You wrote that it's for arbitrary parameter numbering, but I thought it was already in place?
2. What is tmp?
3. I don't know if you know this but using too many '..'s for concatenation slows the module down. It's better to put code in a table and use table.concat.
4. Why do you use 'k' for ipairs? The reference manual uses 'i' since 'k' stands for 'key' and is used for pairs. Szqecs (talk) 11:05, 25 April 2018 (UTC)

@Szqecs:

1. The module now allows gaps in the numbering. For example, using only the parameters system10, line20, left20, right20, left21, and right21 is now valid (row 21 uses the same line value as row 20).
2. Temporary variable (table). The keys in tmp are transferred to the values of args.nums, since I thought this would be the easiest way to handle the same b being added more than once.
3. I was not aware of this (I had thought using table.concat() would be slower). I assumed that any performance drawbacks would be unnoticeable, but if it is slower now then it should be changed back.
4. Not sure.

Jc86035 (talk) 11:44, 25 April 2018 (UTC)

@

{{L-rail/sandbox
|system20=Taipei Metro
|line21=BL|left21=Ximen|right21=Shandao Temple
|line22=R|left22=Zhongshan|right22=NTU Hospital
}}

{{L-rail
|system20=Taipei Metro
|line21=BL|left21=Ximen|right21=Shandao Temple
|line22=R|left22=Zhongshan|right22=NTU Hospital
}}

Incidentally, should "colour" be replaced with "color"? I'm also a British English speaker but I think it would be better to be consistent with the CSS property and with the old S-line templates. Jc86035 (talk) 15:02, 26 April 2018 (UTC)

It's fine. By the way, how do you test memory and time usage? Also, regarding variable names, we ought to review all of them. The goal is to make them as self-explanatory as possible. Maybe we'll do it after we're done porting all the features. Szqecs (talk) 11:06, 27 April 2018 (UTC)

@

help

) :" below the editing area.

With regards to naming things, I think it would also help to call this module "S-line" as well, with the module being put directly into the current template, and the legacy version could be called whenever old parameters like "previous" and "next" are in use. This would avoid having a protracted

TfD discussion; and keeping S-line would be consistent with other succession templates, which are all named "S-something" (e.g. {{S-par}} for parliament seats). A tracking category could be added to show pages using the legacy wikitext-based code. Jc86035 (talk

) 12:34, 27 April 2018 (UTC)

No, I wouldn't recommend mixing this with {{S-line}}.

1. You run the risk of breaking something
2. S-line requires S-start, S-rail and S-end, and some parameters have different names. Existing transclusions won't work and we will still need to edit :::every page.
3. S-line will need to have wikicode to do some sort of check to decide whether to use the old method or new. That then defeats the purpose.
4. S stands for succession, which this module doesn't do. Szqecs (talk) 13:22, 27 April 2018 (UTC)

@Szqecs:

1. You don't run very much risk if you test your changes in {{S-line/sandbox}} (I know different module subpages have to be called but we can probably get the module name from frame:getTitle(), though I've never used this function before). Furthermore, if the switch to the module is put as a parser function dependent on whether |previous= and |next= are used (e.g. {{#if: {{{previous|}}}{{{next|}}} | [existing S-line code] | {{#invoke:S-line|main}} }} then it will probably be quite difficult for a module error to have any effect on legacy transclusions. (As a template editor I have accidentally broken big important templates before, and if you revert your edit as soon as an error pops up you shouldn't really have any issues even if you're being careless and you test things in the main/production template.)
2. If the template does something completely different depending on whether |previous= and |next= are used, then the parameters being different is a feature, not a bug. Of course we will still need to edit every page. Doing it this particular way avoids some of the bureaucracy that comes up in the process of replacing or merging a highly-used template, especially with a new template whose transclusions look radically different and which runs on Lua (again, many editors will never learn how to write Lua). I also think editors may find it more familiar than "L-rail", which has an unusual prefix and is not necessarily appropriately named (there are some ferry and bus rapid transit services that use S-line, for example).
3. How does this defeat the purpose? The transition isn't going to happen immediately.
4. The "succession" refers to there being a previous and next of something, and since roughly the same content is generated by the new template I see no reason why "succession" applies any less.

Jc86035 (talk) 14:44, 27 April 2018 (UTC)

1. Yeah but why risk it if there is little benefit? Routemap wasn't just merged into BS-map. They're totally different and best left on their own.
2. You'll need to elaborate on the 'bureaucracy that comes up in the process of replacing or merging a highly-used template'.
3. I don't think we're on the same page here. The purpose of switching to Lua:

1. The code is easier to read and modify
2. It allows for new features and conveniences, like not having to use S-start, S-rail and S-end, not having to create a bunch of pages for every line, and the auto merge cell thing you worked on etc.
3. By avoiding using any parser functions, it has better performance

What you suggest in 1 results in a template more complicated to use and edit, and certainly performs worse than both S-line and L-rail. Like who would guess that using 'previous' means old and using 'left' means new?

4. 'There being a previous and next of something'? Szqecs (talk) 15:40, 27 April 2018 (UTC)

@

WP:TFD

, although I suppose it could be avoided by only nominating it for deletion once it has been fully replaced. The single parser function would make the module half as fast but the idea would be to eventually remove the old code. I agree that having a single template for both could be a bit confusing.

The "previous" and "next" parameters come from other S-templates being for things which are in chronological order, with the older thing on the left and the newer thing on the right (e.g. the boxes at Chiang Kai-shek#External links). I wasn't around then, so I don't really know why or how this system came about, but it's still what we have today. Jc86035 (talk) 16:29, 27 April 2018 (UTC)

If that's what 'succession' means then {{S-line}} doesn't fit then. Indeed, S-line doesn't conform to the style of Wikipedia:WikiProject Succession Box Standardization and isn't listed. Nevertheless if this kind of box is known as S- something, then maybe we should use {{S-rail-lua}} or something. I think mixing up this with S-line in any way, like calling it S-lines, creates confusion and potential misuse. This is the rationale behind me using 'colour' instead of 'color'. Szqecs (talk) 00:53, 28 April 2018 (UTC)

@Szqecs: For what it's worth, {{Location map}} still uses both wikitext and Lua subpages (though the user input in articles is identical), since no one has figured out how to automatically convert all of the wikitext ones yet. I think {{S-line/Lua}} or similar might work (although "Lua" would eventually become meaningless and someone with OCD will probably try to change the template name everywhere).

Wouldn't it make more sense to use "line color" (seeing as all the other new stuff can be differentiated by having at least one space in the name)? Incidentally the module also needs to support differences in varieties of English (toward/towards) and stuff like "next stop" vs. "next station". Jc86035 (talk) 03:31, 28 April 2018 (UTC)

'S-line' by itself doesn't make sense. Were talking about rail stations, so it should be {{S-rail-lua}}. Szqecs (talk) 12:12, 28 April 2018 (UTC)

@Szqecs: While I think S-line makes about as much sense as S-rail, on second thought it might be better to drop the prefix altogether and go for something like {{Adjacent stations}} (or something shorter or abbreviated). Jc86035 (talk) 13:06, 28 April 2018 (UTC)

I like {{Adjacent stations}}. Don't worry about brevity; we can give it a shorthand using redirect. Not to mention it's rather fast to convert using AWB. Szqecs (talk) 13:10, 28 April 2018 (UTC)

As mentioned, variables names ought to be given some thought when porting from {{S-line}}. Ideally they are self explanatory. Here we review parameters first (those that are inputted on pages) since they are hardest to change.

I replaced previous and next with left and right because

1. S-line uses 'left' and 'right' for succession templates
2. The word 'next' is used in Lua

The header still says 'previous' and 'next' because there are no other sensible words.

type1 and type2 are replaced with typeL and typeR because

1. Corresponds to above parameters
2. Suffixed numbers are reserved for the multi line functionality

The same is true for through, oneway and circular, though these functionalities have yet to be tested.

I replaced notemid with just note. This one I'm not sure. I think it's a bit odd to just stick two words together, but anything else like uppercasing or underscoring seems overkill. Szqecs (talk) 13:31, 27 April 2018 (UTC)

@Szqecs: Maybe Ltype or type-left? Having L and R next to the row number might not be as desirable. If |note= is the text after the line name, then |text= could be {{S-text}} (probably below left/line/right with the same number) and |header= could be {{S-note}} (probably above the succession row). It would also be possible to have |note= change function depending on whether its row has left/right/line or not, although I'm not sure if this would be as desirable. Jc86035 (talk) 14:56, 27 April 2018 (UTC)

type-left it is. Szqecs (talk) 01:23, 28 April 2018 (UTC)

Now I'm thinking note-mid Szqecs (talk) 01:48, 28 April 2018 (UTC)

@Szqecs: I'm ambivalent about "one-way". The word itself is much more commonly used than "oneway", but in the specific context of template parameters "oneway" might make sense. See also osm:key:oneway. Jc86035 (talk) 13:40, 28 April 2018 (UTC)

Yeah okay. Szqecs (talk) 13:41, 28 April 2018 (UTC)

@Szqecs: Do you think line name input should be made case-insensitive? A lot of current templates, especially those in the "color" series, use {{lc:}} (or rarely {{uc:}}). A lot of other things could also be made case-insensitive, although I'm not sure if it would actually be useful since accepting multiple inputs might only be useful in templates which use the S-line subtemplates for other purposes where editors add the template manually. Module:MTR makes all line inputs case-insensitive, for what it's worth. Jc86035 (talk) 15:22, 27 April 2018 (UTC)

Yeah no it is probably not useful. Szqecs (talk) 01:37, 28 April 2018 (UTC)

@Szqecs: I think a nice medium could be to have lowercase aliases where necessary for a module which does process all input to make it lowercase, for example a module for {{Rail-interchange}}. Jc86035 (talk) 03:24, 28 April 2018 (UTC)

For variables in the data module, I use system title and line title because the words 'system' and 'line' are used all over the place and it can get quite confusing. The words are separated by a space because it's easier to type. Same goes for station link, though 'link' isn't necessary the best word because the station doesn't actually need a link. As for '%1', I have no idea what it is. Szqecs (talk) 12:26, 28 April 2018 (UTC). Changed station link to station format in sandbox. Szqecs (talk) 13:50, 28 April 2018 (UTC)

@Szqecs: I changed %s to %1 in case a second value is ever needed while inserting the station name into the default string. %1 is also used in Lua's string patterns, but it's actually for an unrelated purpose so maybe using something different like \1 or $1 might be better. Jc86035 (talk) 12:58, 28 April 2018 (UTC)

I find it weird that currently in the data module the system info is placed in an unnamed table alongside lines. I think lines should be placed in a table called 'lines' and system info should be moved out of the table. Szqecs (talk) 04:03, 29 April 2018 (UTC)

@Szqecs: No objection. Jc86035 (talk) 05:08, 29 April 2018 (UTC)

{{

L-rail/row}} (maybe it should be renamed /line?) will need to be updated to have extra tabs. Jc86035 (talk

) 05:14, 29 April 2018 (UTC)

@Jc86035: I propose two changes to this function. The first is the one you reverted. The routing of the current code is unnecessarily complex:

local function station(s)
	if _line['station format'] then
		return _line['station format'][s]
			or data[v][1]['station format'][s]
			or mw.ustring.gsub(_line['station format'][1] or data[v][1]['station format'][1], '%%1', s)
	else
		return data[v][1]['station format'][s] or mw.ustring.gsub(data[v][1]['station format'][1], '%%1', s)
	end
end

From what I can tell, it first checks to see if the format is under the line. If not, it is assumed to be under system info. However if format is under line, it should use the one under line, not go back to system info if no match:

if _line['station format'] then
	return subst(_line['station format'][s]	or _line['station format'][1]) or ''
elseif data[v][1]['station format'] then
	return subst(data[v][1]['station format'][s] or data[v][1]['station format'][1]) or ''
else
	return ''
end

Here subst is a function for mw.ustring.gsub() since you're repeating the same operation over and over. It should be applied to exceptions as well. As I mentioned before, many stations have the same non-default format. In fact, which format to pick as default is potentially arbitrary. By applying substitution to exceptions, one could just copy paste.

My second proposal takes this idea further. The function subst():

local function subst(s2)
	if s2 then
		if string.match(s2, '%[%[') then
			return mw.ustring.gsub(s2, '%%1', s)
		else
			return table.concat({'[[', mw.ustring.gsub(s2, '%%1', s), '|', s, ']]'})
		end
	else
		return ''
	end
end

Since we know all or most of the links conform to displaying the input and linking to something else, we can build in the format as well, while retaining the original input method. For example:

['station format'] = {
	'%1 MRT station',
	['Airport Terminal 2 or Huanbei'] = '[[Airport Terminal 2 MRT station|Airport Terminal 2]] or [[Huanbei station|Huanbei]]',
	['Taipei Main'] = '[[%1 station (Taoyuan Metro)|%1 station]]',
	['Taoyuan HSR'] = '[[Taoyuan HSR station]]',
	['Zhongli railway station'] = '[[Zhongli railway station]]',
	['Bar'] = '%1 station'
}

As a demonstration here, 'Foo' uses default format, 'Bar' uses non-default, the others use the current method:

{{L-rail/sandbox2
|system=Taoyuan Metro
|line=Airport|left=Foo|right=Bar
|line2=Airport|left2=Taoyuan HSR|right2=Zhongli railway station
}}

{{L-rail/sandbox2 |system=Taoyuan Metro |line=Airport|left=Foo|right=Bar |line2=Airport|left2=Taoyuan HSR|right2=Zhongli railway station }}

Whatcha think? Szqecs (talk) 06:31, 29 April 2018 (UTC)

@Szqecs: I like the subst function idea. It shouldn't be very taxing on performance, but you might want to check that anyway if you're going to try to optimize everything even though the module is light-years away from reaching the template limit.

The reason that the original order

• If there is a format table for this line, then
  • Use a format for this station on this line if it exists
  • Else use a format for this station if it exists
  • Else use a format for this line if it exists
  • Else use the general format
• Else,
  • Use a format for this station if it exists
  • Else use the general format

is this way is that if the line were not to have its own station format table, then the module would throw up an error by trying to index a non-existent table. With your order change, then every station format table has to have the default format (in other words, I think line 2 in the block should be return subst(_line['station format'][s] or data[v][1]['station format'][s] or _line['station format'][1] or data[v][1]['station format'][1]) or ''. Furthermore, if the line had its own table (e.g. { "%1 (BMT Myrtle Avenue Line)" }) and a particular station on that line had an entry in the main table and not the line's table (e.g. … ["Myrtle Avenue"] = "Myrtle Avenue (BMT Jamaica Line)", …, then the link would go to the wrong place (in this case, Myrtle Avenue (BMT Myrtle Avenue Line)). However, the latter problem would probably be much rarer. Jc86035 (talk) 06:53, 29 April 2018 (UTC)

Wait, are you expecting mixed use (format table for both system and line)? What I was thinking was that editors either create one for the entire system or one for every line, not both. Szqecs (talk) 08:25, 29 April 2018 (UTC)

@Szqecs: I was expecting mixed use, since e.g. on the London Underground there are two Edgware Road stations, but other than those two there are a lot of interchanges with unique names, so a module subpage with a general format table (as well as smaller line format tables for those two specific stations and possibly some closed stations) would be easier to maintain. Jc86035 (talk) 08:45, 29 April 2018 (UTC)

The way you designed it is that they both work the same way though, which is really confusing. I originally didn't intend for a system-wide format table because it's hard to understand when it would use which, and also because of the disambiguation problem you mentioned (which is everywhere in NYC for example). You probably added the system-wide table to avoid repetition. How about have a system-wide default format and line specific exceptions? Szqecs (talk) 09:48, 29 April 2018 (UTC)

@Szqecs: But then we would have to manually group stations for a lot of legacy templates like {{LUL stations}} instead of just dumping most of them in with regex find-and-replace. S-line is used on more than 40,000 pages, so that's a lot more templates which would have to be converted manually. Not allowing exceptions for the whole system also means that a lot of the exceptions have to be repeated for systems like the London Underground (although in some cases the exceptions might be repeated for different reasons, such as in {{CTA stations}} where the authors have both exploited the template for non-S-line purposes and possibly not realized that |line= is passed through to the template – for some reason the S-line documentation doesn't bother to explain how those templates work at any point). I suppose there's nothing wrong with it technically, but – again – this makes it harder to import templates and harder to maintain the subpages. It shouldn't be too hard to explain "if your system has multiple stations with the same name, then make a station format table inside the line's table for those ambiguous stations". Jc86035 (talk) 10:55, 29 April 2018 (UTC)

On second thought, the line-specific table probably isn't needed at all. For ambiguous stations, I don't know how S-line handles them, but they are exceptions anyways. Edgware road for example, could simply be transcluded as |left=Edgware Road Bakerloo|right=Edgware Road sub-surface. The format table then converts them to their respective links. Szqecs (talk) 11:21, 29 April 2018 (UTC)

@Szqecs: I think this is probably an acceptable option, although maybe %2 or something could be used in the general table as well (e.g. "%1 station (CTA %2 Line)"). Jc86035 (talk) 13:17, 29 April 2018 (UTC)

Ambiguous names are handled by a set of system-specific templates, each with numerous exceptions. It's a big job. There's something to be said for eliminating that whole setup and just going with hard-coded links, as {{rail line}} does. Side question: you folks going to loop in the various rail-transport wikiprojects at some point? Mackensen (talk) 10:54, 2 May 2018 (UTC)

@Mackensen: There are about 40,000 pages using {{S-line}} and about 10,000 using {{Rail line}}. I think it's easier for end users to put the termini in once and not worry about them again, but on the other hand, if the data is exported to Wikidata then each statement will have to have the termini added manually anyway.

It'll be years before any of the templates will be fully replaced in any way, seeing as importing to Wikidata would probably be done manually to add things like start and end dates and secondary sources (and {{Rail line}} still exists and is highly used more than a decade after it could have been superseded).

I don't know about telling the WikiProjects. This is really Szqecs's module, although I would probably only notify after all the features of S-line have been added (or possibly after someone's written a script, maybe based on mwparserfromhell, to automatically convert S-line templates into module subpages). Jc86035's alternate account (talk) 14:07, 3 May 2018 (UTC)

Szqecs, can you keep the module subpage names brief and preferably identical to the S-line/legacy template names? (My alternate account has not made ten edits yet and so cannot move pages.) The obvious reason WMATA, NYCS, etc. are currently used over Washington Metro, New York City Subway, etc. is that those commonly-used full names were already considered unnecessarily long for the template names, and there's no real need to expand the abbreviations since they're not actually displayed and they're usually unambiguous within the context. Jc86035's alternate account (talk) 16:23, 1 May 2018 (UTC)

Really? When was it decided? Precisely because it isn't displayed, there's no reason to abbreviate it; it doesn't take up extra visual space. As I was editing, I thought it was hella inconvenient and pointless to go to S-rail/lines and look for the abbreviation, especially for those that are not commonly used like TRTS or AFR. There is a reason that the articles don't use abbreviations for the titles. Szqecs (talk) 16:41, 1 May 2018 (UTC)

Some of the abbreviations are possibly made up and violate Wikipedia:No original research. Szqecs (talk) 16:48, 1 May 2018 (UTC)

@Szqecs: I don't really know if it was decided, and it would be fairly difficult to construct the history without viewing deleted pages. Mackensen seems to have created them in 2007 following the abbreviations of older templates made in the {{Rail line}} style, hence why {{LUL lines}} isn't called just "LU lines" and why {{HK-MTR stations}} (based on templates called "HK rail") isn't called "MTR stations".

If you're going to use the full titles, I think using shorter and better-known names like "Washington Metro" would be better than using longer and lesser-known names like "Washington Metropolitan Area Transit Authority"; I also think it would be seen as unnecessary to expand absolutely everything (especially with no regard to

WP:COMMONNAME etc.), and you would probably get some flak for making editors type more unnecessary characters. For instance, since "MTR" is unique and is almost always referred to in English by its acronym, I would avoid calling its subpage "/Mass Transit Railway". Jc86035's alternate account (talk

) 10:46, 2 May 2018 (UTC)

The abbreviations were kept short as a convenience for editors, nothing more. There's no question of "original research" with something that was never meant to be public-facing. Mackensen (talk) 10:49, 2 May 2018 (UTC)

No. Editing is a core feature of Wikipedia and what editors see is public. The article on Wikipedia:No original research does not say that it doesn't apply to templates. As an editor, I found using 'LUL' less convenient than 'London Underground' because I've never heard of 'LUL' before. I do agree with using something like 'Washington Metro', though it does beg the question of why the article isn't named 'Washington Metro'. Szqecs (talk) 11:33, 2 May 2018 (UTC)

I'll be sure to let the complaints department know. Mackensen (talk) 12:27, 2 May 2018 (UTC)

I assume they used the transit authority's acronym because the Washington Metro never uses an acronym? I suppose it doesn't really matter; use the full system names if you think it's better. (I think using transit agency names like WMATA should be avoided in any case, since the system header is now attached to the rest of the data, and allowing a different header per line would introduce a lot of unnecessary complexity.) Jc86035's alternate account (talk) 15:16, 2 May 2018 (UTC)

Szqecs, can you use double quotes in the module subpages? There shouldn't be any CSS in the subpages and there are far more stations with names containing apostrophes than those with names containing quotation marks, so it would probably be better for double quotes to be used throughout. Jc86035's alternate account (talk) 14:08, 3 May 2018 (UTC)

Better how? Single quotes are easier to type. Szqecs (talk) 14:13, 3 May 2018 (UTC)

@Szqecs: There are virtually no double quotes to escape. If no characters need to be escaped, then it doesn't have to be explained to non-fluent editors. It's… not difficult to type double quotes. Jc86035's alternate account (talk) 14:47, 3 May 2018 (UTC)

About the escape thing, you do realize that if you don't escape '[', then you can't use block comment? Because block comment is --[[]]. Escaping is just a feature of Lua that needs to be used. Considering there are hundreds of strings, it is a lot of extra work. Szqecs (talk) 14:52, 3 May 2018 (UTC)

@Szqecs: I'm not convinced. There are unescaped double square brackets in Module:Adjacent stations as well as a block comment, and the module works fine. I didn't learn Lua formally, but I don't think Lua's string handling could possibly be that weak – if it worked like that you wouldn't be able to put unescaped apostrophes inside double quotes. See also the string documentation for Lua, which indicates that [[...]] strings can themselves contain nested double square brackets. Jc86035's alternate account (talk) 16:23, 3 May 2018 (UTC)

Remove the escape characters here and see what happens. I can't even show you because it won't let me save. Szqecs (talk) 23:32, 3 May 2018 (UTC)

@Szqecs: Oh, that's what you meant. I don't think we'll run into that, since we can still prefix lines with --. Jc86035's alternate account (talk) 03:06, 4 May 2018 (UTC)

@Szqecs: How do you think the template should be used in {{Infobox station}}? Currently |services= of that template adds {{S-rail-start}} and {{S-end}} automatically, which is not ideal. I think it would be best to use Module:String to search for this template's header (e.g. {{#if:{{#invoke:String|match|1={{{services|}}}|2=class="wikitable adjacent-stations"|nomatch=}}|{{{services|}}}|{{S-rail-start}} {{{services|}}} {{S-end}}}} instead of requiring the use of |rows=mid. Jc86035's alternate account (talk) 10:58, 11 May 2018 (UTC)

Many systems don't have the succession box in the infobox: Tokyo Metro, Berlin U-Bahn, London Underground etc, so I don't think if it even matters. Also, I'm not really familiar with parser functions and Module:String. If you think it would work, go for it I guess. Szqecs (talk) 00:43, 12 May 2018 (UTC)

@

@Mackensen: I enabled usage in |services= a while ago using Module:String (e.g. Hong Kong station). Jc86035 (talk) 19:57, 26 December 2018 (UTC)

Thanks! When I was testing I still had the old s-line template in there for side-by-side comparison that the results were...not pretty. Mackensen (talk) 19:58, 26 December 2018 (UTC)

@Szqecs: Can you use the below transclusion on an otherwise blank page to test performance instead? The testcases page is probably not representative of most transclusions, and the precision isn't really good enough.

{{Adjacent stations/sandbox|left=Farragut North|left2=McPherson Square|left3=Banqiao|line=Red|line2=Blue|line3=BL|right=Gallery Place|right2=Federal Triangle|right3=Wende|system=Washington Metro|system3=Taipei Metro}}

Jc86035's alternate account (talk) 08:21, 12 May 2018 (UTC)

Sure. Szqecs (talk) 08:29, 12 May 2018 (UTC)

@Jc86035 (1): I'm thinking of mirroring left and right, since they have and should have identical code. I'm not sure how I would do it yet, and I've put some ideas in the sandbox. However, I think it would involve manipulating strings with 'left' and 'right' in them. It would probably be easier if 'left terminus' and 'right terminus' are renamed 'terminus-left' and 'terminus-right' to match the other parameters. Szqecs (talk) 12:56, 15 May 2018 (UTC)

@Szqecs: I don't think it's worth bothering. At this point, any performance gains in the module are going to be at least one order of magnitude smaller than the time it takes someone to request and download a page that the template sits on, even if this page were to have zero other content and the person were in the same building as some of the WMF servers. You can do whatever you want with the internal identifiers, since no one is actually going to look at them, but at this point it works fine so we should probably get on with making all of the module's features documented (i.e. making the example module, writing the documentation for people making the subpages) and converting more S-line templates. Jc86035's alternate account (talk) 13:18, 15 May 2018 (UTC)

If you do still want to optimise a module for largely superficial performance gains, you might want to look at Module:Routemap, since I grafted on a lot of stuff that works inefficiently (particularly the "icon cell parameters", which have a completely unnecessary nesting system) and sometimes would actually prevent two diagrams from being used on the same page. Performance is much more of a concern for that module, especially since the amount of content can be much larger than for this module, and I've never bothered to optimise it. It's just almost never necessary. Jc86035's alternate account (talk) 13:25, 15 May 2018 (UTC)

Actually the goal is to make the code simpler so that it is easier to modify, the very reason I started this project. Back when you were adding through, reverse, note etc, you had to do everything twice. A longer module also makes it harder to find stuff. Szqecs (talk) 14:33, 15 May 2018 (UTC)

@Szqecs: True; go ahead and change the parameter names. Jc86035's alternate account (talk) 14:49, 15 May 2018 (UTC)

@Jc86035 (1): How does circular work in S-line? I'm guessing that if circular is yes, for the terminus, the station gets replaced with something like clockwise / inner or clockwise or inner, and outputs something based on the format table. If so, the current module doesn't really do that. Szqecs (talk) 06:49, 20 May 2018 (UTC)

@Szqecs: As in {{S-line}}, the only thing that happens is the terminus labels are shown without "towards" and the default format isn't used. Jc86035's alternate account (talk) 11:33, 21 May 2018 (UTC)

{{subst:Adjacent stations|system=MTR Light Rail|line=705|left=Tin Wu|right=Tin Shui Wai|circular=1}}

Preceding stop	MTR Light Rail			Following stop
Tin Wu counter-clockwise		705		Tin Shui Wai One-way operation

If the default format isn't used, what happens if there is no corresponding entry on the format page? And is there a point to the double reference, where the terminus is something like 'clockwise' and the format table having a 'clockwise = clockwise'? Szqecs (talk) 11:50, 21 May 2018 (UTC)

@Szqecs: If there's no entry in the format table, then the text in the line's table is used. I think it might also help to make the default displayed text be "circular" or something. Jc86035's alternate account (talk) 13:45, 21 May 2018 (UTC)

@Szqecs: Did you remove the circular parameters? I think if it's module-only then "circular" in the line tables should use the same structure as "left terminus" and "right terminus" (i.e. whether the service is marked as circular changes with |type=) since some circular lines have branches and/or services which only go around part of the circle. Jc86035's alternate account (talk) 15:52, 21 May 2018 (UTC)

I'm not entirely sure how type, branch and service work (or should work). I'll get back to you after I figure it out. Szqecs (talk) 11:37, 22 May 2018 (UTC)

@Szqecs: I've already done the documentation for all of the current parameters. (If the documentation isn't clear enough for you, if that's what you meant, then it probably needs to be improved.) Jc86035's alternate account (talk) 13:55, 22 May 2018 (UTC)

I meant the following:

1. What's the difference between type, branch and service? It seems that they do the same thing, used to change termini. Is it necessary to have all three?
2. How do they work together to determine the termini? It seems type has precedence over branch, which has precedence over service.
3. It seems more reasonable that circular is an attribute of each line/type/branch/service, though how to implement it is beyond me. Maybe it would be easier if type/branch/service are just removed, and all just use separate lines. Szqecs (talk) 12:02, 23 May 2018 (UTC)

Maybe the data module should look like this:

		["second line"] = {
			["line title"] = "[[Example|Example 2]]",
			["colour"] = "e5755b",
			["left terminus"] = "Roma Termini",
			["right terminus"] = "Oslo Central",
			["other types"] = {
				["type 1"] = {
					["left terminus"] = "Penzance",
					["right terminus"] = "Aberdeen"
				},
				["type 2"] = {
					["left terminus"] = "Clockwise",
					["right terminus"] = "Anticlockwise",
					["circular"] = true
				}
			}
		}

Szqecs (talk) 14:47, 23 May 2018 (UTC)

@Szqecs:

1. The reason both branch and service exist is that some lines can have branches or alternate routes which themselves have services. I didn't plan it for this specific example, but Module:Adjacent stations/MTR uses both for the Tseung Kwan O Line because it shows the line's future routings as "branches". The reason I planned to add |service= is this feature request by KU from 2016, which was never fulfilled. (I did manage to make the sandbox work, but it was a cheap hack which is a lot less elegant than the current solution of having a table with the text and the colour.) |type= and type-left/right could be treated as an anachronism which only exists because for some reason |branch= doesn't actually do anything other than pick the text in {{S-line}} (note that in {{S-line}} there isn't even an equivalent for |type=).
2. Correct. This is definitely slightly confusing, especially since |type-left= and |type-right= have precedence over |type=, but no line should ever need to use four or five (and very few lines should have to use three).
3. I didn't consider this but it would make it more difficult to transition from S-line to the module, especially because branches already exist in S-line. I think it might be best to leave it up to other users, since I have no idea what other people might want out of this.

Merging type, branch and service into one parameter might potentially make it easier to use the template, although if the template ends up becoming an inscrutable magic box then it might be problematic. I don't know which layout will be easier for editors to use. Jc86035's alternate account (talk) 16:44, 23 May 2018 (UTC)

@Cards84664: Hi. Do you think allowing parameters |branch= and |service= to change the line termini is a good idea? Should some of the parameters be removed? Do you have any opinion on the data module structure? (For direct comparison, currently Module:Adjacent stations/Washington Metro is almost equivalent to the WMATA series. Module:Adjacent stations/MTR replaces two other module subpages, but the page has some examples of branches and services.) Jc86035's alternate account (talk) 16:44, 23 May 2018 (UTC)

Branch and service should be kept for now, service is used to depict wrong-way concurrencies, while branch is used for stuff like this:

{{s-start}}
{{s-rail|title=CTA}}
{{s-text|text=[[South Side Elevated]]}}
{{s-line|system=CTA|line=Green|previous=51st|next=Cottage Grove|branch=East 63rd|rows1=3|rowsmid=2}}
{{s-line|system=CTA|line=Green|previous=51st|next=King Drive|branch=East 63rd|hide1=yes|hidemid=yes|oneway2=yes}}
{{s-line|system=CTA|line=Green|previous=51st|next=Halsted (Green)|branch=Ashland|hide1=yes}}
{{s-end}}

I was thinking, you could probably add a |circular parameter that will automatically switch out the towards and the station termini.

Also, is it possible for these modules to effectively replace all of the templates? (i.e. color, stations, lines, and the two s-line succession templates for each line?)

I'll have more time to go over this later, but is it possible to customize the "Preceding station" and "Following station" with these modules? Cards84664 (talk) 18:18, 23 May 2018 (UTC)

@Jc86035: Can the "Preceding station" and "Following station" be customized on a station by station basis? Cards84664 (talk) 21:33, 23 May 2018 (UTC)

@Cards84664: The |circular= parameter, or similar, exists in both templates. In both templates, it removes "towards", and the data pages are supposed to contain something like "clockwise" which is displayed instead of a link. |service= is not used to depict wrong-way concurrencies in either template – you may be confusing it with |type= and |type2= of {{S-line}}.

In {{Adjacent stations}}, |service= is like |branch=, except you can also specify a colour and then the text background uses that colour. The difference between this template and {{S-line}} is that both of those parameters can be used to set the line termini.

The question I was asking was, do you think it's a good idea to allow |branch= and |service= to set the line termini along with |type=, |type-left= and |type-right=? (Only the latter two exist in S-line.)

Yes, this is supposed to replace the succession templates entirely, although another module will have to be made to support templates which currently use the line colours. Jc86035's alternate account (talk) 09:21, 24 May 2018 (UTC)

You can't change "preceding" and "following", but you can change "station". Jc86035's alternate account (talk) 09:26, 24 May 2018 (UTC)

I think that type, branch and service are only good because they all share line title and colour, so having the parameter(s) saves space. As far as I can tell, there only needs to be a type. Branches can use type too. The circular parameter I don't see the point at all. A line/service is either circular or it isn't. It should just be in the data. Szqecs (talk) 23:42, 23 May 2018 (UTC)

@Szqecs: I agree removing the parameters might be good, and it should be trivial for it to be fixed since there aren't a lot of actually circular lines to begin with. Jc86035's alternate account (talk) 09:21, 24 May 2018 (UTC)

@Szqecs: In the new data model, would the defaults be inside the types table? Jc86035's alternate account (talk) 11:36, 24 May 2018 (UTC)

You mean termini? They are not really defaults anymore. As shown above, if type = type 1, the termini will be alternative ones: Penzance and Aberdeen. This way it supports circular for individual types, as shown in type 2. Szqecs (talk) 14:12, 24 May 2018 (UTC)

@Szqecs: No, what I meant is, what happens if the line has a types table, but the type parameter is empty? Jc86035's alternate account (talk) 06:23, 25 May 2018 (UTC)

Empty or not used? If not used, the termini will be the ones under the line: Roma Termini and Oslo Central. I guess you can call them defaults. Szqecs (talk) 11:23, 25 May 2018 (UTC)

On second thought, if there are not a lot of circular lines, it's simpler to use the original structure:

			["left terminus"] = {
				"Roma Termini",
				["Lisbon"] = "Rossio"
			},
			["right terminus"] = {
				{"Stockholm Central", "Oslo Central"},
				["Stockholm"] = "Stockholm Central",
				["Oslo"] = "Oslo Central"
			}

It is shorter. Lines where some services are circular and some are not should just be split into two lines. Szqecs (talk) 13:43, 25 May 2018 (UTC)

@Szqecs: I now think it might be better to only have |type=, |type-left= and |type-right=, or even just |type=, since this is less complicated than having five parameters which override each other. However, accepting comma-separated values might be useful for lines which have multiple services and multiple branches. I don't know whether the original structure or the proposed structure (with a "types" table) would be better in this model. Jc86035's alternate account (talk) 15:19, 26 May 2018 (UTC)

Most lines don't have many types, so having a types table is overkill. As for comma-separated values, I have no idea what that is. Szqecs (talk) 15:36, 26 May 2018 (UTC)

@Szqecs: Basically how this would work is that if you were to have |type=Type1, Type2 then it could be transformed into { "Type1", "Type2" } using mw.text.split with the regular expression %s*,%s*, and values for both of those (with the first taking precedence) would be used. This would primarily be useful for systems with lots of identically-named services, although for the Tseung Kwan O Line example this would be unnecessary but potentially be useful (if the full table, or the entire value as a string, could be used as a table key in the termini table).

Most lines would not need this, but it would probably be simpler to use for the vast majority of systems while actually being a little more complicated. Jc86035's alternate account (talk) 04:41, 27 May 2018 (UTC)

@Szqecs: Similarly to the proposal above, |type-left=Edgware, Mill Hill East or High Barnet via Bank is now valid with the sandbox template for lines without the type-left table, and would return Edgware, Mill Hill East or High Barnet via Charing Cross" for the completed London Underground subpage. Do you think this is useful? Jc86035 (talk) 15:57, 16 June 2018 (UTC)

Better to make it a separate parameter. What if for e.g. 'High Barnet via Bank' happens to be a service name? Szqecs (talk) 00:06, 17 June 2018 (UTC)

@Szqecs: This auto-formatting is disabled if there is a table containing service names, so there can't be any conflict – either the side cell uses the auto formatting or it uses the terminus table (although I think there will be very few lines which actually need one). (It also automatically detects – in line 222 – if the table in left/right terminus is the group of default termini or a list of services.) Jc86035 (talk) 06:45, 17 June 2018 (UTC)

Why did you comment out the services function? It's still necessary to replace the function of the Japan-specific templates, since they can have one colour for the line and one colour for the service. Jc86035's alternate account (talk) 04:45, 27 May 2018 (UTC)

Sorry, I actually don't know how any of that works. But is there a reason Japan in particular needs this feature and not other countries? Szqecs (talk) 05:45, 27 May 2018 (UTC)

@Szqecs: It's just that {{J-route}} and {{J-rserv}} use the service colour as the banner colour, with another template providing the line colour. {{S-line}} is used in basically all other countries, although {{Rail line}} does also allow for a second colour. Since obviously we can't throw out the S-line styling, some other thing has to provide the second colour, and having the text-with-coloured-background was, I thought, the least problematic way to do it. Jc86035's alternate account (talk) 06:13, 27 May 2018 (UTC)

Can services just be different lines? As far as I can tell, different services in {{J-route}} share neither the colour nor the text in body midcell, so they can pretty much be separate lines. Szqecs (talk) 07:17, 27 May 2018 (UTC)

@Szqecs: See Tokyo Station#Adjacent stations (it's mainly {{J-rserv}}). Some of those could be separate lines, but it really depends. I don't really know which one would be better, although retaining multiple services per line would prevent termini from having to be duplicated more than 10 times for some lines with lots of service patterns. Allowing different layout options so as to preserve the original layout is also a possibility (perhaps there could be a sort of "display type" parameter to change the layout so that services are grouped together under similar headers, although we would have to figure out how to deal with links on dark backgrounds).

Regardless, allowing services to be retained alongside branches can prevent text duplication (again, as in the Tseung Kwan O Line example). Jc86035's alternate account (talk) 08:53, 27 May 2018 (UTC)

If you are going to have a bunch of rows with the same termini, does it matter that the data module also has a bunch of duplicates? You get what you pay for. Personally I wouldn't even bother with services. To me, Tokyo Station#Adjacent stations is a huge mess. Szqecs (talk) 10:37, 27 May 2018 (UTC)

@Szqecs: I randomly picked Tokyo station and one adjacent to it, but a lot of the time (especially in rural areas) the express trains skip most of the smaller stations. This is obviously useful information in many cases, and if you weren’t to bother with allowing services to be listed you’d never get anywhere with actually replacing the original templates.

Having said that, the table is very much going to look like a mess for large railway stations like Tokyo station, because that’s what the services are like in the real world, and we can’t really do anything about that if we’re choosing to show the services uniformly. (Some services have their own Wikipedia articles, so we should probably list those; but it might also be considered a distortion of reality to only mention the services with their own articles.) You can see this at major stations which use S-line, like Berlin Hauptbahnhof. Not showing the railway line probably works better for European lines because services aren’t generally labelled with generic words like “Rapid” and “Local”, and services might move between different named lines more. Jc86035's alternate account (talk) 14:48, 27 May 2018 (UTC)

Currently you can deal with services three ways:

1. Treat services as lines. They will be in separate rows. They can have different termini and/or colour.
2. Have different services in different rows, use the same line, but use type to change termini. Use note-mid to mark each service.
3. Keep all services in the same row. Use note-mid to mark all services. Use the multi-station terminus feature (left/right terminus is table).

To me, that's already a lot of options which should cover all needs. Szqecs (talk) 16:29, 27 May 2018 (UTC)

@Szqecs: I might not use note-mid – there’s |header=, which could also include {{rail color box}} (which, incidentally, needs to be updated to be able to use the module subpages over S-line subpages).

How would you deal with services with colours assigned to them, on lines which also have colours assigned to them? We could make another template for this, but I had thought it would be better to integrate it in the module. If both line and service are to be indicated in the middle cell, then keeping |service= (with no link to termini) might be useful since if we need colours for them then we're going to have to use the module subpages anyway.

If you’re removing |type=, we could also eliminate a lot of terminus tables by passing |type-left= or |type-right= through the format table. I would have preferred to keep |type=, but it’s only a few characters and some branch text so I don’t think it should matter much. Jc86035's alternate account (talk) 05:25, 28 May 2018 (UTC)

Header? You mean use header for the line title like in Tokyo Station#Adjacent stations? That's weird. I would go with option 3 mentioned above, and either add a colour boxes like you mentioned or highlight the text as you have demonstrated above.

Preceding station	Washington Metro			Following station
Huntington Terminus		Yellow Line (colour box) Standard service (colour box) Weekday rush hour service		King Street–Old Town toward Mount Vernon Square

Szqecs (talk) 14:52, 28 May 2018 (UTC)

I feel like we need to back up a little and make sure we are on the same page. The type parameter only changes the termini, not the line title, colour or adjacent station. It's a good feature because different stations on a line often have services with different termini. The service parameter you propose, I still don't get the nature of. Is it only for express/local services on the same line with same termini? Express and local services have different adjacent stations, so should different adjacent stations be displayed? If you put express and local services in separate rows, should each row display the line title over and over? If not, and if express and local services are assigned different colours, then they share nothing but the termini. Instead of just having them be separate lines, you want to add a feature just so the termini does not need to be repeated? When everything else is different? Szqecs (talk) 15:18, 28 May 2018 (UTC)

@Szqecs: Of course different adjacent stations would be displayed. (It just happens that the Keihin-Tōhoku Line only has six local stations.) I now think it would make more sense for the service name to always be the big text and the line name to be the small text (e.g. "Airport Rapid", with "Hakodate Main Line"/"Chitose Line" manually entered as note-mid or header depending on what other editors prefer), since even some services with generic names pass through different lines (e.g. Kintetsu Nara Station), so keeping the service permanently attached to a line would be impractical. In this model, note-mid might also be included in rows with |nonstop=. In the original proposal with the text highlight, the line colour would be repeated across services. Jc86035's alternate account (talk) 15:58, 28 May 2018 (UTC)

I wouldn't say that different services of course should be put in separate rows with different adjacent stations. I don't object other users from doing so, but I mostly deal with systems where services are not so distinctive or regular, so I wouldn't bother. You mentioned services with generic names passing through different lines, which raises the question of whether this template should be used for physical lines or services. If the system has regular and distinctive services, it should be used for services. Szqecs (talk) 13:32, 29 May 2018 (UTC)

What is i18n for? As far as I can tell, only towards is different for US and GB. It is used a few times before line 216 (where it is depends on data[v] and line.colour). All uses before that will just use the default. I don't really see the point of this table. Szqecs (talk) 13:24, 21 May 2018 (UTC)

@Szqecs: It has apparently been planned (since 2015, although progress seems to be stalled due to the usual WMF allocation of limited resources to other things) that there will be a central repository for templates and modules. Keeping all the stuff which needs to be translated in one table makes copying between wikis easier regardless of whether it will happen. (Furthermore, if a template is in use on the English Wikipedia, someone will probably import it to one of the smaller Wikipedias at some point.) Jc86035's alternate account (talk) 13:43, 21 May 2018 (UTC)

@Jc86035: Sorry, but I reverted your last edit because it put many articles in Category:Pages with script errors. The problem is that lower on line 485 is not defined (local lower = mw.ustring.lower is missing). I was going to fix that but I then noticed that the following variables are global, possibly due to glitches (lower is the problem I just mentioned): branch color greatercontrast line lower. When I started fixing them it seemed I would have to do quite a lot of investigation to check the affected code. I can do a bit more later to pin-down where the undefined variables are, but I thought I had better post something to start. I'm posting the above although Jc86035 has fixed the lower problem (I was notified just before saving this). Johnuniq (talk) 10:12, 30 July 2018 (UTC)

I don’t know if this is related to the above but a handful of stations are showing up in Category:Pages with script errors. In the first I checked Ambedkar Nagar monorail station though the error has no visible effects it shows in the source as

• error in Module:Adjacent_stations at line 119: attempt to index local 'title' (a nil value}

--JohnBlackburne^words_deeds 20:06, 30 July 2018 (UTC)

I edited

Plzeň hlavní nádraží. Johnuniq (talk

) 07:57, 31 July 2018 (UTC)

@Johnuniq and JohnBlackburne: Thanks; those errors were probably caused by an incorrect value in |style= of {{Infobox station}}. (I don't think it's possible to add a tracking category within that parameter, instead of emitting an error, because it's CSS.) Jc86035 (talk) 09:18, 31 July 2018 (UTC)

@Jc86035: I see you've re-implemented branches. It seems this feature is very general, as you use it for express/local in testcases. Perhaps we should make parameter names more fitting and change 'branch' to 'type' and 'type' to 'term'. The module is not widely used yet and I am willing to make necessary edits on pages. Szqecs (talk) 05:23, 2 August 2018 (UTC)

@Szqecs: Since previous/next has already been changed to left/right, I guess changing "type" to "term" (or a different word, since "term" could be confusing – maybe "end"?) would make it more obvious that the new template works slightly differently in this regard.

I chose "branch" primarily for compatibility with {{Rail color box}}, which did have a branch parameter before I converted it to Lua, but I'm guessing that it's not used anywhere because it was never added to the documentation and it took me several years to realize that it was actually there. The template report for 1 August still hasn't been generated yet. Perhaps a deliberately inserted script error could be used for tracking for now (since normal categories can take a while to update). Jc86035 (talk) 11:18, 2 August 2018 (UTC)

The branch parameter does appear to be in use on about 41 pages, although I also seem to have accidentally disabled the branch parameter for S-line-based templates without anyone noticing. A parameter rename would probably be fine. Jc86035 (talk) 11:24, 2 August 2018 (UTC)

@Szqecs: Is the sandbox module ready as it is; is there anything else you wanted to fix? Jc86035 (talk) 15:06, 2 August 2018 (UTC)

also: "end", "to" or "term"? I'm not sure "end" is the best option. Jc86035 (talk) 15:09, 2 August 2018 (UTC)

I suspect changing terminus would be one of the most commonly used feature besides basic use. 'to' is short and simple. Szqecs (talk) 16:41, 2 August 2018 (UTC)

There's a bug with using 'to' with automatic string formatting. Szqecs (talk) 05:38, 3 August 2018 (UTC)

@Szqecs: Fixed; you can't search a nil value. Jc86035 (talk) 05:49, 3 August 2018 (UTC)

I think we're good to go. Instances of 'type' should stay correct during the conversion. Instances of 'branch' will need to be changed to 'type'. Szqecs (talk) 06:44, 3 August 2018 (UTC)

@Szqecs: (You linked the article ping instead of notifying me.) I think this sort of thing would be hard to enforce and it's just not necessary for any technical reason, although perhaps the documentation could contain a recommendation to only use abbreviations as redirects to the full system name. Jc86035 (talk) 14:47, 3 August 2018 (UTC)

For stations without articles, does the station formatting still apply wikilink? If so, is there a way to remove it? Szqecs (talk) 03:41, 16 August 2018 (UTC)

@Szqecs: Not right now. I think the assumption is that every station on a line should have its own article, or at least if this station has an article then the ones next to it should as well (or the titles should exist as redirects to appropriate places). Perhaps if it comes up a "no autoformat" system table entry could be recognised by the module. Jc86035 (talk) 10:44, 16 August 2018 (UTC)

@Jc86035: One small thing: Can you edit line 181 so that instead of matching only '%[%[' it matches that and also '%]%]'? Szqecs (talk) 04:23, 17 August 2018 (UTC)

@Szqecs: Okay, I've done that. Jc86035 (talk) 14:45, 17 August 2018 (UTC)

Should there be separate documentation for the template and module? If so, the scope of the two should be defined to avoid overlaps. Szqecs (talk) 03:57, 16 August 2018 (UTC)

@Szqecs: I was thinking the module documentation would mainly be about how to read and write a subpage, and the template subpage would mainly be about how to use the template in an article. Jc86035 (talk) 10:48, 16 August 2018 (UTC)

@Szqecs: Since the template and documentation are largely finished at this point (except for some bits of the module documentation), do you think it should be advertised at the top of {{S-line}}? I think it should be (given the successful TfDs for two other modules and about 60 templates), and maybe it could be worded something like the notice at {{BS-map}}, "consider using {{Adjacent stations}} for new systems or for systems in need of maintenance" or similar. Jc86035 (talk) 10:37, 16 August 2018 (UTC)

I think it can be advertised, but I don't think the doc is finished. I think there needs to be an explanation of how the module works so that we are not the only ones able to fix bugs and add features. In fact, you've added a lot of code so I don't really understand it any more. Szqecs (talk) 03:32, 17 August 2018 (UTC)

@Szqecs: In general, everything after the main function is just things for the other five templates (generally: get parameters, get the line data, check if the type exists, get the line/station name, format output, return output) and {{Infobox station}}'s style parameters. I forgot to document p._style, so I'll need to do that at some point. Jc86035 (talk) 08:19, 17 August 2018 (UTC)

I think the documentation for the code itself should be done entirely as comments in the code, since any documentation will inevitably have to refer to specific parts of the code anyway. Jc86035 (talk) 09:08, 17 August 2018 (UTC)

I don't know if this matters but I originally named 'system title' and 'line title' so that editors would what they were titling. Now there is line 'color' and type 'color', 'icon format' and 'line icon format', but system 'icon' and line 'icon'. Seems a bit messy don't you think? Szqecs (talk) 09:18, 17 August 2018 (UTC)

@Szqecs: "line icon format" was an afterthought, but I think it makes sense to keep them as "line icon format" and "type icon format" because they are the only fallbacks which might have to be different from the value used by the system. "icon" is consistent with "color", and "icon format" is consistent with "color" except for the fallback mechanism. Jc86035 (talk) 09:55, 17 August 2018 (UTC)

What's a fallback? Szqecs (talk) 11:05, 17 August 2018 (UTC)

I should mention this in the documentation, then. A fallback is an alternative that takes the place of something else (i.e. "line icon format" is only used for a line when the line doesn't have an "icon format"). Jc86035 (talk) 14:47, 17 August 2018 (UTC)

I think in programming it is more common to talk about overrides. What is 'icon' for by the way? Is it only used for {{Rail icon}}? I thought it would be an icon added before titles in {{Adjacent stations}}. Szqecs (talk) 15:51, 17 August 2018 (UTC)

I think because the first layer is a mixed place containing things to do with the system and those that don't (e.g. lang, color), it can be confusing what parameters refer to, so parameters here should be precise. Beneath line and type tables, they are all quite clear, so can take shorter names. I propose naming this way:

• line icon format → default line icon format
• type icon format → default type icon format
• aliases → line aliases
• icon (first layer) → system icon
• icon format (first layer) → system icon format
• color (first layer) → default line color
• line title → title
• type title → title

Szqecs (talk) 16:25, 17 August 2018 (UTC)

@Szqecs:

• The icon data is only used by {{Rail icon}}. A few years ago I had wanted to replace {{Rail-interchange}} with a Lua module, but it has taken quite a while for that possibility to materialize.
• I'm fine with the "icon" and "icon format" changes.
• There isn't another "aliases" key, so I don't think changing that is necessary. The table is also used to process type inputs.
• The top-level color is supposed to be the system's color as well as the color for lines (I briefly tried to get the system to work with {{Rail color box}} but I couldn't be bothered), so I think it's more intuitive to just leave it as it is and explain it in the documentation.
• Changing "line title" and "system title" does make sense, although I assumed they would be used to quickly identify the nesting level for anyone trying to fix a terminus. I don't mind either way.

Of course, if you change any of the key names please update subpages which use them. Jc86035 (talk) 16:56, 17 August 2018 (UTC)

What is the system colour for? Szqecs (talk) 17:04, 17 August 2018 (UTC)

Presently I think it's only used in place of the line color if the latter doesn't exist, but it would make sense to allow using it through {{Rail color box}} without a line specified. Jc86035 (talk) 17:07, 17 August 2018 (UTC)

There isn't another "aliases" key, so I don't think changing that is necessary. The table is also used to process type inputs. I think it is better to have self-explanatory names so that editors won't have to rely on doc so much. As for type, isn't the feature really just an override of line?

Presently I think it's only used in place of the line color if the latter doesn't exist, but it would make sense to allow using it through {{Rail color box}} without a line specified. If so, it is a minor use. Having 'default line color' be the system color for Rail color box is not too weird either. Szqecs (talk) 18:01, 17 August 2018 (UTC)

@Szqecs: The line type's not really an override (both sets of text are displayed, and so on; see Module:Adjacent stations/New York City Subway), but "line aliases" would imply that it only works for |line= and not for |type=.

Maybe all current uses of a 'system color' could just be moved to the _default table, and then the field could be deleted so "color" in the system table doesn't do anything, and then we can worry about it when it's added to {{rail color box}}. The _default table would be quite useful for Module:Adjacent stations/China Railway and other current subpages where the line names are fairly predictable ("[[%1 railway]]"). Jc86035 (talk) 18:33, 17 August 2018 (UTC)

So these are the changes:

• icon (first layer) → system icon
• icon format (first layer) → system icon format
• color (first layer) → default color
• line title → title
• type title → title
• Type ←→ type

Also, lang = en-GB is unnecessary since it is default. Szqecs (talk) 11:27, 18 August 2018 (UTC)

Or not? color is now split into system color and _default color? Szqecs (talk) 12:38, 18 August 2018 (UTC)

@Szqecs: In some cases the default line color could be different from the system color. Jc86035 (talk) 13:30, 18 August 2018 (UTC)

@Jc86035: Then line color should only fall back on default line color and not system color. Otherwise they are basically two of the same thing. {{Adjacent stations}} does not show system color, so should not use it. Szqecs (talk) 14:53, 18 August 2018 (UTC)

@Szqecs: But {{Rail color}} uses it, and it could be used in {{Rail color box}} in the future. Jc86035 (talk) 12:21, 19 August 2018 (UTC)

Do they both use the same getColor? Because they really shouldn't. Different templates work differently. Szqecs (talk) 13:33, 19 August 2018 (UTC)

@Szqecs: I think only {{Rail color}} uses it right now, but I'm not sure. There's only one getColor function. I think for the current use cases it would be inappropriate to reuse getColor but something else might be added in the future that might need it. Jc86035 (talk) 13:37, 19 August 2018 (UTC)

I think {{Rail color}} etc. should have their own modules. This module is way too long and tangled that it is hard to modify for {{Adjacent stations}} and not break the other ones. Szqecs (talk) 13:40, 19 August 2018 (UTC)

@Szqecs: But that wouldn't have stopped you from breaking them, because you didn't actually change any of the (hardcoded) parameter names in the other functions, and that was what broke every use of those functions. If anything, if you (or I) had just replaced all instances of the parameter names at once, in all the functions, it would have taken a lot less time to figure out what to clean up.

I think it makes sense to keep them all here, because it makes the module easier to translate and transwiki, some error messages are used across different functions, and they all rely on the subpages anyway. The module isn't particularly "long and tangled" (especially compared to other modules, like Module:Convert), and there being more code at the bottom of the page doesn't really prevent you from editing the top half. There is virtually no performance benefit from splitting them out (I tested this with Module:Routemap a short time ago and I think it actually got slightly worse). Jc86035 (talk) 13:57, 19 August 2018 (UTC)

Alright then. By the way, I tested it out. System color is not used by {{Adjacent stations}}. Szqecs (talk) 14:05, 19 August 2018 (UTC)

@Szqecs: It is used, because if it didn't do anything Module:Adjacent stations/China Railway High-speed would be generating errors right now. Jc86035 (talk) 14:33, 19 August 2018 (UTC)

@Jc86035:

Preceding station	China Railway High-speed			Following station
Terminus		Shanghai–Nanjing intercity railway		Shanghai West towards Nanjing

It is ignored. Szqecs (talk) 16:43, 19 August 2018 (UTC)

@Szqecs: Oh, I didn't realise that. I'll fix it (I think it's because of the parameter rename). Jc86035 (talk) 17:38, 19 August 2018 (UTC)

I didn't realise you'd deliberately removed it. Never mind. Jc86035 (talk) 17:44, 19 August 2018 (UTC)

What's the difference between line icon format and icon format in _default? Szqecs (talk) 14:42, 18 August 2018 (UTC)

@Szqecs: "line icon format" doesn't exist in _default; it only exists in the main table. Since p._main() doesn't use getLine() (I think for some pointless efficiency thing to avoid doing something again for line types), only "title" and "color" from _default are useful right now. Logically it should be possible to put the icon format in _default but I don't really think fixing it would be necessary or very useful. Jc86035 (talk) 15:00, 18 August 2018 (UTC)

Previously, all images and template headers were routed through this protected template. How do we explain to the admins that leaving everything unlocked and spread out between transit systems will be more effective? Cards84664 (talk) 17:50, 17 August 2018 (UTC)

I don't get why this needs to be locked. Shouldn't ordinary folks be able to add new systems or change logos? Szqecs (talk) 18:06, 17 August 2018 (UTC)

@Cards84664: I don't think it'll be an important issue, and {{S-rail/lines}} has to be template-protected because it's used in every transclusion of {{S-rail}}, but I guess it's better than having the rest of the data scattered around lots of subpages of {{S-line}} and a bunch of random templates with names ending in "stations", etc., since it's much easier to get a list of pages with the prefix "Module:Adjacent stations/" (and then use Special:RecentChangesLinked on such a list). Jc86035 (talk) 18:27, 17 August 2018 (UTC)

@Jc86035: Hi. {{Rail color box}} for system is not working (Template:Adjacent stations/testcases). Szqecs (talk) 17:57, 26 August 2018 (UTC)

Oh, I realised it is not intended for systems. Would be useful though. Also, it doesn't use the default color without entering line like {{Adjacent stations}} does. Szqecs (talk) 06:39, 27 August 2018 (UTC)

@Szqecs: I think it should work for systems, but I don't really want to spend more time on it right now. It should be more feasible now that the system icon is not supposed to be in the same string as the link to the article. Jc86035 (talk) 09:04, 27 August 2018 (UTC)

@Szqecs: Is the lack of line colour for TRA deliberate? I thought you'd forgotten to add it back. Currently the second and fourth cells are empty and transparent. Jc86035 (talk) 13:14, 27 August 2018 (UTC)

No. I was merely changing it, though there aren't really line colours for TRA. Szqecs (talk) 13:34, 27 August 2018 (UTC)