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. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 |
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
In the the sandbox I have added code that takes a new parameter: inline. The purpose of this code is to utilize Rail color box for boxes that can fit inline rather than just in lists and infoboxes. Inline has 2 valid states and a default state: yes, small, and default. Yes uses template:color box rather than the default template:legend and small uses template:bg. For example:
({{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}})
If there aren't any objections I will merge this in with the main code. - Killian441 ( talk) 17:27, 9 January 2013 (UTC)
Use of this template as {{Rail color box|system=PLR|line=Red Castle Shannon}}
generates four lint errors:
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)
{{Rail color box|system=PLR|line=Red Castle Shannon}}
</small>
at all. --
Redrose64 🌹 (
talk)
09:26, 16 March 2018 (UTC)
<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>
</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>
<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.</small>
.
This edit should fix it. --
Redrose64 🌹 (
talk)
13:14, 16 March 2018 (UTC)
I didn't see the notice, but it looks like {{ l-rail}} replaced {{ s-rail}}? Frietjes ( talk) 18:16, 22 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.
Thoughts on merging table cells
|
---|
|
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)
|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}}.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.|system1=Taipei
|line1=R
|system2=Taipei
|line2=G
).|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.
@ Jc86035:
@
Szqecs: Are you fine with my implementation of the station links (current version of
Module:Sandbox/Szqecs/L-rail); are there any outstanding technical issues or inefficiencies? This change is backwards-incompatible so all the subpages would need to be manually updated at the same time as the main module. Testing it with the below sets of code, I get about 7.5% less Lua memory usage and about 8.3% less real time usage for {{
L-rail/sandbox}} slightly better Lua memory usage and Lua time usage (the latter of which may not be statistically significant) compared to {{
L-rail}}. It also makes conversion from the old format slightly easier since it's relatively trivial to do regex find-and-replace operations with e.g. BBEdit (which is what I did for
Module:Sandbox/Szqecs/L-rail/Taipei Metro).
Jc86035 (
talk)
15:01, 26 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)
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.)|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).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
The header still says 'previous' and 'next' because there are no other sensible words.
type1
and type2
are replaced with typeL
and typeR
because
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)
|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)
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)
@ 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)
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)
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)
@ 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)
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)
|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)
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)
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)
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)
[[...]]
strings can themselves contain nested double square brackets.
Jc86035's alternate account (
talk)
16:23, 3 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)
@ Jc86035 and Szqecs: The existing embedded parameter for Infobox station can handle this use case. See Riverfront Station for an example. The absence of an explanatory header is a little awkward. This pattern is pretty common in some systems so we do need a solution. Mackensen (talk) 19:55, 26 December 2018 (UTC)
|services=
a while ago using
Module:String (e.g.
Hong Kong station).
Jc86035 (
talk)
19:57, 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)
@ 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)
@ 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)
{{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
|
@
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)
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:
|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=
).|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).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)
{{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}}
|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}}.|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.|branch=
and |service=
to set the line termini along with |type=
, |type-left=
and |type-right=
? (Only the latter two exist in S-line.)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)
"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)
|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)
|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).@
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)
@ 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).
Preceding station | JR East | Following station | ||
---|---|---|---|---|
Tokyo toward
Ōfuna
|
Keihin-Tōhoku–Negishi Line Rapid
|
Akihabara toward
Ōmiya
| ||
Keihin-Tōhoku–Negishi Line Local
|
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)
|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).|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.|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)
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)
|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)
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)
@
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
-- JohnBlackburne words deeds 20:06, 30 July 2018 (UTC)
|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)
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)
Jc86035: I mentioned this before. Per
WP:TITLEFORMAT: Abbreviations and acronyms are often ambiguous and thus should be avoided unless the subject is known primarily by its abbreviation
.
United States is not titled 'US' or 'USA' despite being common. 'MTR' is acceptable because its article is titled
MTR. KCR is not.
KCR does not even redirect to the correct page like
USA.
Szqecs (
talk)
09:20, 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)
@ 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)
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: 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 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)
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:
Szqecs ( talk) 16:25, 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)
|line=
and not for |type=
.So these are the changes:
Also, lang = en-GB is unnecessary since it is default. Szqecs ( talk) 11:27, 18 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)
Preceding station | China Railway High-speed | Following station | ||
---|---|---|---|---|
Terminus | Shanghai–Nanjing intercity railway |
Shanghai West towards
Nanjing
|
What's the difference between line icon format and icon format in _default? Szqecs ( talk) 14:42, 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)
@ Jc86035: Hi. {{ Rail color box}} for system is not working ( Template:Adjacent stations/testcases). Szqecs ( talk) 17:57, 26 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)
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. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 |
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
In the the sandbox I have added code that takes a new parameter: inline. The purpose of this code is to utilize Rail color box for boxes that can fit inline rather than just in lists and infoboxes. Inline has 2 valid states and a default state: yes, small, and default. Yes uses template:color box rather than the default template:legend and small uses template:bg. For example:
({{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}})
If there aren't any objections I will merge this in with the main code. - Killian441 ( talk) 17:27, 9 January 2013 (UTC)
Use of this template as {{Rail color box|system=PLR|line=Red Castle Shannon}}
generates four lint errors:
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)
{{Rail color box|system=PLR|line=Red Castle Shannon}}
</small>
at all. --
Redrose64 🌹 (
talk)
09:26, 16 March 2018 (UTC)
<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>
</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>
<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.</small>
.
This edit should fix it. --
Redrose64 🌹 (
talk)
13:14, 16 March 2018 (UTC)
I didn't see the notice, but it looks like {{ l-rail}} replaced {{ s-rail}}? Frietjes ( talk) 18:16, 22 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.
Thoughts on merging table cells
|
---|
|
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)
|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}}.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.|system1=Taipei
|line1=R
|system2=Taipei
|line2=G
).|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.
@ Jc86035:
@
Szqecs: Are you fine with my implementation of the station links (current version of
Module:Sandbox/Szqecs/L-rail); are there any outstanding technical issues or inefficiencies? This change is backwards-incompatible so all the subpages would need to be manually updated at the same time as the main module. Testing it with the below sets of code, I get about 7.5% less Lua memory usage and about 8.3% less real time usage for {{
L-rail/sandbox}} slightly better Lua memory usage and Lua time usage (the latter of which may not be statistically significant) compared to {{
L-rail}}. It also makes conversion from the old format slightly easier since it's relatively trivial to do regex find-and-replace operations with e.g. BBEdit (which is what I did for
Module:Sandbox/Szqecs/L-rail/Taipei Metro).
Jc86035 (
talk)
15:01, 26 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)
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.)|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).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
The header still says 'previous' and 'next' because there are no other sensible words.
type1
and type2
are replaced with typeL
and typeR
because
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)
|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)
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)
@ 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)
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)
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)
@ 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)
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)
|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)
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)
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)
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)
[[...]]
strings can themselves contain nested double square brackets.
Jc86035's alternate account (
talk)
16:23, 3 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)
@ Jc86035 and Szqecs: The existing embedded parameter for Infobox station can handle this use case. See Riverfront Station for an example. The absence of an explanatory header is a little awkward. This pattern is pretty common in some systems so we do need a solution. Mackensen (talk) 19:55, 26 December 2018 (UTC)
|services=
a while ago using
Module:String (e.g.
Hong Kong station).
Jc86035 (
talk)
19:57, 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)
@ 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)
@ 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)
{{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
|
@
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)
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:
|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=
).|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).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)
{{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}}
|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}}.|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.|branch=
and |service=
to set the line termini along with |type=
, |type-left=
and |type-right=
? (Only the latter two exist in S-line.)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)
"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)
|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)
|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).@
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)
@ 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).
Preceding station | JR East | Following station | ||
---|---|---|---|---|
Tokyo toward
Ōfuna
|
Keihin-Tōhoku–Negishi Line Rapid
|
Akihabara toward
Ōmiya
| ||
Keihin-Tōhoku–Negishi Line Local
|
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)
|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).|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.|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)
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)
|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)
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)
@
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
-- JohnBlackburne words deeds 20:06, 30 July 2018 (UTC)
|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)
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)
Jc86035: I mentioned this before. Per
WP:TITLEFORMAT: Abbreviations and acronyms are often ambiguous and thus should be avoided unless the subject is known primarily by its abbreviation
.
United States is not titled 'US' or 'USA' despite being common. 'MTR' is acceptable because its article is titled
MTR. KCR is not.
KCR does not even redirect to the correct page like
USA.
Szqecs (
talk)
09:20, 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)
@ 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)
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: 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 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)
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:
Szqecs ( talk) 16:25, 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)
|line=
and not for |type=
.So these are the changes:
Also, lang = en-GB is unnecessary since it is default. Szqecs ( talk) 11:27, 18 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)
Preceding station | China Railway High-speed | Following station | ||
---|---|---|---|---|
Terminus | Shanghai–Nanjing intercity railway |
Shanghai West towards
Nanjing
|
What's the difference between line icon format and icon format in _default? Szqecs ( talk) 14:42, 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)
@ Jc86035: Hi. {{ Rail color box}} for system is not working ( Template:Adjacent stations/testcases). Szqecs ( talk) 17:57, 26 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)