![]() | 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 |
@ Ythlev: Is there a significant benefit to completely rewriting the HTML generation of the module (bearing in mind that a supermajority of modules do not use the mw.html library at all)? As I understand it the output will be the same and the performance will likely be the same or slightly worse. Jc86035 ( talk) 09:51, 25 December 2018 (UTC)
@ Ythlev: If it's possible I think it would be better to move the successionBox code into the main module, since it would keep all of the code in one place (benefits for copying to other wikis, other users finding the source of script errors, possibly the revision history). Jc86035 ( talk) 03:29, 25 January 2019 (UTC)
["name format"]
as I have no idea how they work.
Ythlev (
talk)
08:28, 25 January 2019 (UTC)I gather that there's some checking taking place in Infobox station and possibly elsewhere for the existence of modules before falling back on traditional templates. I'm starting to create Module:Adjacent stations/Metra (unsaved as yet) and I see that a number of things link to it. Is this just color handling? How much of the module needs to be stable and returning reasonable values before I put it into production? Mackensen (talk) 05:11, 27 December 2018 (UTC)
Apologies if this was already answered above. It's a common pattern with s-line implementations (see e.g. "Belmont" in {{
Metra stations}}) to identify the correct station format based on passed parameters such as line and branch. I know those are available as replacements (%2
and %3
), but is it possible/desirable to replicate that concept here? Obviously in the alternative we could use explicit named keys. Thanks,
Mackensen
(talk)
16:16, 28 December 2018 (UTC)
A useful feature in the s-rail universe is {{ s-rail-next}}, which can be used to suppress the display of the redundant "preceding" and "next" headers where multiple systems are in play and span the system title instead. See Pennsylvania Station (New York City) for a prominent example: the titles headers are shown for Amtrak, but suppressed for the LIRR and NJ Transit. Besides avoiding redundancy, this can make things less cramped when there are long system titles. I would think the module could do this automatically for any systems after the first system. Mackensen (talk) 04:20, 29 December 2018 (UTC)
@ Mackensen: I personally considered it inconsistent to do so, and it makes it more difficult to distinguish between "system" headers and "other" (e.g. "Under construction") headers, especially for systems which don't use icons. Usage of {{ S-rail-next}} also seems to have significant regional variation:
Country | Pages with S-rail-next (approx.) |
---|---|
United States | 774 |
United Kingdom | 150 |
Netherlands | 52 |
Canada | 35 |
Malaysia | 31 |
Japan | 29 |
France | 19 |
South Africa | 10 |
China | 8 |
Singapore | 3 |
Australia | 2 |
Finland | 2 |
Germany | 2 |
Thailand | 2 |
Denmark | 1 |
India | 1 |
{{ S-line}} is used for station articles in about 48 countries; {{ S-rail-next}} in about 16 countries, and somewhat uniformly in only about five or six of those countries. Hong Kong and Taiwan almost exclusively use {{ Adjacent stations}}. While this isn't a very rigorous analysis, there are certainly more than two multi-modal or multi-system stations in Germany or Australia. (The queries I used exclude non-station articles, such as articles for places which use the template.) Jc86035 ( talk) 10:00, 29 December 2018 (UTC)
It would certainly be possible to add that functionality, but it would add unnecessary complexity to both the main and convert functions, and I'm not sure if it's desirable. Jc86035 ( talk) 10:39, 29 December 2018 (UTC)
|system-nextn=yes
sort of parameter be used? Would it be an editorial decision as to whether it's used, would it be set per system, ...?|system-nextn=yes
would be a good solution.
Mackensen
(talk)
15:42, 30 December 2018 (UTC)
{{ Station link}} is supposed to support line parameters but this doesn't seem to be working: Template:Station link/testcases. The second test has no default case, so it fails with a script error. The third test has a default case which it falls back to, but it's the wrong value for the passed line parameter. Mackensen (talk) 16:35, 5 January 2019 (UTC)
I'm having an issue where short name
doesn't seem to be respected with {{
rail color box}}. See
User:Mackensen/temp for examples leveraging
Module:Adjacent stations/PAAC. I did notice that the last conditional in p._box refers to line instead of lineN, but wasn't sure if this was deliberate and I'm wary of modifying the module.
Mackensen
(talk)
17:47, 15 January 2019 (UTC)
short name
is only used for the display types where the name is inside a box (route, croute and xroute). For the other styles it's ignored; this is largely deliberate, since templates like {{
RouteBox}} tend to be used side-by-side, so you would want to abbreviate them as much as possible.
Jc86035 (
talk)
15:48, 16 January 2019 (UTC)Unusual situation which I've documented at User:Mackensen/temp#Willow station (PAAC). The goal is to indicate that certain stations were closed by using the note-rightn parameter. The Blue Line - South Hills Village (via Overbrook) should be displayed as going to both Martin Villa (closed 2012) and St. Anne's. The latter box is shared with the Red Line - South Hills Village (via Beechview). The pixel height is so minimal as to be indistinguishable. In the second template I suppressed the note and it works visually, but the closure information is lost. Mackensen (talk) 02:54, 22 January 2019 (UTC)
@ Ythlev: I think it would be better to avoid moving the module to a new title again, particularly if you're not actually going to do all of the page moves in one go. Nthep has already reverted one of the page moves. Any change in the module name would be purely cosmetic, although I'm not going to stop you from making such a change. Jc86035 ( talk) 19:00, 28 January 2019 (UTC)
The result of the move request was: WITHDRAWN. This move is part of a wider move, which should be discussed together. In addition, consensus has changed. Withdrawing to make a centralised request. ( non-admin closure) Ythlev ( talk) 08:20, 10 February 2019 (UTC)
– New module name Ythlev ( talk) 15:19, 29 January 2019 (UTC) --Relisting. SITH (talk) 17:39, 8 February 2019 (UTC)
{{Module:Adjacent stations/doc}}
to
Module:Rail/doc). --
Ahecht (
TALKp.convert
function in the new code is exactly the same as the current version. I am currently concerning that the new version do not cover all the exception exist in the old version due to the lack explanation from the other. @
Ythlev:, I do suggest you to add enough comments in your code, do the same thing as the current version by creating a Internationalization table at the top for people to do easy translation and explain what you have changed or redo in detail (like I use AA than BB in the XX function of the current version. BB is CC, which is faster or better than the current version) before suggestion for edit. Also, due to the exact same function name in most of the function in both version, I would suggest you to just submit a edit request on the current version rather than asking to convert to your new version in order to preserve the current edit history in Adjacent stations. Also, I agree with
User:Jc86035 that the code in Adjacent station is not buggy, but may need a
Code refactoring in one or two function. However, I do not think the whole thing need to be redesigned, since your new code actually break everything based on the edit history suggest. I love people want to do
Code refactoring, but not without discussion. --
VulpesVulpes825 (
Talk)
02:31, 3 February 2019 (UTC)This move is part of a wider move of having Module:Adjacent stations be renamed to Module:Rail, the discussion for which is below. Ythlev ( talk) 16:17, 9 February 2019 (UTC)
Why was Template talk:Adjacent stations moved to Module talk:Rail? What about Template:Adjacent stations? I assume the move is premature or was a mistake and should be reverted? Johnuniq ( talk) 04:44, 30 January 2019 (UTC)
You said the previous section, which is about the doc. Where is the rule that all page moves must be discussed? Ythlev ( talk) 13:01, 30 January 2019 (UTC)
Module:Adjacent stations is buggy and hard to fix because of the structure, which is also hard for new editors to understand. Therefore it has been re-designed. In order to better diagnose problems, it is given a new name: Module:Rail. Code for Station link and Line link have been tested to work fine, so they invoke the new Module:Rail. Code for other templates are still under testing, after which they will also invoke Module:Rail. Module:Adjacent stations/doc has been moved to Module:Rail/doc to match the new module name. In what I thought was an obvious move, I also moved this talk page to also match the new name, but apparently some have problems with it. I am open to being convinced. Ythlev ( talk) 13:34, 30 January 2019 (UTC)
["right terminus"] = {"Chesham","Amersham"}
, I'm pretty sure I implemented that in June last year. It was also changed when the template had fewer than 500 transclusions, whereas the template now has more than 1,300.put in to the sandbox and request edit on this current moduleI did do the former. I didn't 'request edit' but I did mention the change on this talk page.
your code actually become way harder to read compare to the current version due to lack of commentsYou are the first to think that. Comments are easy to add and would be if you think they are necessary; the re-designed version is much better structured and one user has agreed with me.
and not having a internationalize tableThe table was just moved elsewhere and guess what, that change was reinstated by Pppery on the live version. Ythlev ( talk) 05:24, 3 February 2019 (UTC)
It is better for you to put into the sandbox and have a test-case to show that the external appearance is unchanged
I did exactly that.
Ythlev (
talk)
05:53, 3 February 2019 (UTC)
@ Pppery: I reverted your lasted edit. You don't get to get to pick and choose which of my edits are 'clear improvements' and which are disruptive editing. And Module:Rail is no longer used by live templates, so by deleting it before this discussion if finished, you are claiming ownership and I will also report you if you keep this up. Ythlev ( talk) 04:58, 3 February 2019 (UTC) @ Cards84664: This goes to you too. Ythlev ( talk) 05:07, 3 February 2019 (UTC)
@ Mackensen:@ Redrose64:@ Johnuniq: A month or two ago I experimented with re-designing the module at Module:Adjacent stations/sandbox. On 25 December, I explained here why I felt the module should be re-designed. On 5 January, I mentioned in the same section that the sandbox was partially complete. Some time around 28 January I moved Module:Adjacent stations/sandbox and I explained here why I felt it should be renamed. Up until this point, no one rejected my proposals, and I have been tirelessly testing the new code with the sandbox. I had {{ Line link}} and {{ Rail color}} use the new module after the tests were okay. It was not until I moved the doc and talk pages that it became contentious.
Mackensen, are the following sentences two questions of yours that you wanted answers to?
If the proposal is to retain all the same functionality in the same place but as Module:Rail instead of Module:Adjacent stations, then that's fine, but it's not clear that you're proposing that. I may also be confused by the edits you were making to Module:Adjacent stations/Amtrak.
It's unclear and you 'may' be confused, but did you wanted me to explain? It sounded like it's unclear but you understood anyways and think it's fine.
Ythlev (
talk)
15:54, 31 January 2019 (UTC)
Due to the recent controversial move from Moudle:Adjacent stations to Module:Rail, the talk page is now being to large. Is it OK for me to introduce a achieve bot so that the page can be smaller and contain relevant discussion in order to follow the guideline? Also, since there are three to four heading for the same topic, is it OK for me to combine them in to one and move to ANI in order to centeralize discussion and let people understand exactly is going on? I will indicate on ANI that this whole thread should be archived back to this talk page once this issue is resolved (This is kind of the rule on Chinese Wikipedia that talk should be archieved back to original place once it is finished)? -- VulpesVulpes825 ( Talk) 21:19, 2 February 2019 (UTC)
I looked at Special:PrefixIndex/Template:Adjacent stations and Special:PrefixIndex/Template talk:Adjacent stations. I didn't check everything but it seems to be ok except possibly for Template talk:Adjacent stations/testcases. @ Mackensen: Would you please check that last link which currently redirects to Module talk:Rail but which probably should redirect to here. Johnuniq ( talk) 01:34, 3 February 2019 (UTC)
I do understand the frustration in the current incident, but I do think Ythlev's version is a better version than the current version and here are the reasons:
Due to the reasons above, I would strongly recommend to merge
Ythlev's new version to the current version. This merge should be done by
Ythlev themselves since
Ythlev is the original author of this module. It is also maybe a good idea to change the name from Adjacent stations to Rail since the name Rail can represent things like line color, which using Adjacent station does not making any sense. I will start request to edit the Module, which is now been template editor protected, after 10 days, if a consensus is made in the discussion in this discussion or no one response, which becomes a
silent consensus. --
VulpesVulpes825 (
Talk)
06:29, 3 February 2019 (UTC)
Update As I mentioned in the discussion below, I tested the new version in the Chinese wikipedia and it break all the Infobox station template by not letting the Infobox station have the default heading color. Due to the fact that the new version will not produce the correct default color for the heading of the Infobox station, I will not recommend the merge until this problem is fixed. -- VulpesVulpes825 ( Talk) 23:10, 3 February 2019 (UTC)
![]() | This
edit request to
Module:Adjacent stations has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Request revert version back to [ Pppery's version]. It is a good idea to move the internationalization table to a separate table so that it is easier for people like me to translated it into other Language version. -- VulpesVulpes825 ( Talk) 23:15, 3 February 2019 (UTC)
Notifying Mackensen, VulpesVulpes825, Redrose64, Johnuniq and Ahecht. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)
For Module:Adjacent stations, I propose the following changes. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
As mentioned above by VulpesVulpes825, the code benefits from a better structure. The current version re-invents the wheel like the functions of mw.text.listToText and Module:TableTools. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
As above, I support the restructuring and the module rename. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)
Is the proposal that the main module be replaced with the sandbox?It is still under discussion.
(1) Use one blank line between functions; (2) Do not combine multiple variable declarations with assignment ("local p, data, ...");The code is already nearly 700 lines long. All that and it would be too long to navigate.
(4) Are the module-level globals in the first line really necessary?They are not globals, they are variables local to the entire module. They are there because they are used by more than one function. You could pack them into the args table or have the functions take those as arguments, but what does it matter? You would only be confusing editors. Ythlev ( talk) 09:59, 7 February 2019 (UTC)
Support, As I mentioned above, I do think the new version is better since the new version illuminate pure html code. I may able to do a beta testing on the Chinese wikipedia to give it a try. --
VulpesVulpes825 (
Talk) 18:13, 7 February 2019 (UTC)
Apart from the fact that this name makes more sense, the module is used by several templates. The code for each template may be dependent on each other. It is much easier to use a new module, then for each function that is tested to work properly, have the template invoke the new module. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
As above, I support the restructuring and the module rename. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)Ythlev ( talk) 08:47, 10 February 2019 (UTC)
I've made a move request below. Please comment there instead. Ythlev ( talk) 08:49, 10 February 2019 (UTC)
I propose that all colour codes be prepended with '#' since they are machine-read and need to have the symbol. The current sandbox version supports hashed and unhashed codes for backwards compatibility. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
I'm fine with the change to the colour codes, as long as you don't break anything, although this would introduce an inconsistency with S-line. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)
The HTML library supports structured CSS arguments. I propose the below structure for data modules so that barely any code is needed to process the arguments.
Current | Proposed |
---|---|
local p = {
"name format" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"header background color" = {
"00537E",
"Amtrak old" = "0078B9",
}
}
|
local p = {
"infobox station" = {
"header" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"sub-header" = {
"background-color: #00537E; color: #FFFFFF",
"Amtrak old" = "background-color: #0078B9; color: #FFFFFF",
},
},
}
|
I also propose swapping positional arguments to bring it in line with other templates.
Current | Proposed |
---|---|
{{#invoke:Adjacent stations|style|header|{{{style|}}}|{{{style2|}}}}} |
{{#invoke:Adjacent stations|infoboxStation|{{{style|}}}|{{{style2|}}}|_header}}
|
Ythlev ( talk) 07:08, 7 February 2019 (UTC)
I'm not really sure if changing the infobox function would be beneficial for users, and it would necessitate an extra step in S-line conversion, but I personally haven't used it in a while so I don't know if this would be disruptive. I think it would be better if {{
Line link}} and {{
Rail color box}} retain their current functions, at least until {{
S-line}} templates have been completely replaced, since the vast majority of {{
Rail color box}} uses are with S-line helper templates, using the original styles; furthermore, {{
Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing, especially since you would be adding at least two of the original {{
Rail color box}} functions to the template.
Jc86035 (
talk) 09:12, 7 February 2019 (UTC)
I'm not really sure if changing the infobox function would be beneficial for users, and it would necessitate an extra step in S-line conversionWell, the easiest thing to do would be to not convert at all.
lines['_default']
and treat sub-styles as lines, if it makes sense.
Ythlev (
talk)
13:16, 7 February 2019 (UTC)Notifying Jc86035. Ythlev ( talk) 18:35, 9 February 2019 (UTC)
I propose that the style setting function be extended to {{ Infobox rail line}}, as it is similar to station. Ythlev ( talk) 18:15, 9 February 2019 (UTC)
I propose merging {{ Rail color box}} (RCB) into {{ Line link}} and {{ Rail icon}}, with backwards compatibility. RCB already displays line link for four styles. Link link can just have a parameter that prepends the box. Line link should also be able to prepend icons, as this is frequently used. Rail icon currently can be set to display RCB. It should be designed to let users set which style of RCB to use and completely replace RCB.
These changes have not been coded yet. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
I think it would be better if {{
Line link}} and {{
Rail color box}} retain their current functions, at least until {{
S-line}} templates have been completely replaced, since the vast majority of {{
Rail color box}} uses are with S-line helper templates, using the original styles; furthermore, {{
Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing, especially since you would be adding at least two of the original {{
Rail color box}} functions to the template.
Jc86035 (
talk) 09:12, 7 February 2019 (UTC)
I think it would be better if {{ Line link}} and {{ Rail color box}} retain their current functions, at least until {{ S-line}} templates have been completely replacedRail color box would be just left working as it is.
{{ Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusingI think it is equally confusing that Rail icon can be set to display RCB. RCB is just a really weird template. Instead of letting users customise the output like
|linked_box=yes
or |show_text=yes
, it just has 12 pre-defined styles that seemingly come from nowhere. you would be adding at least two of the original {{ Rail color box}} functions to the template.. If you are referring to the code structure, I'm pretty sure that it can be written to be not be confusing. Ythlev ( talk) 09:49, 7 February 2019 (UTC)
|inline=yes
) if they make the template easier to use, which adding several long named parameters wouldn't do.As for {{
Rail color box}},{{
Rail icon}}, {{
Rail color}} and {{
Line link}}, I do think it a good idea to combine all into one template (with backward compatibility if possible) since all four template's function overlap with each other. However, I do think it may be a good idea to separate the merge request as a new request rather than been part of the code refactoring request, since this may need a longer discussion which may delay the code update to the main module. --
VulpesVulpes825 (
Talk) 18:13, 7 February 2019 (UTC)
![]() | This discussion was listed at Wikipedia:Move review on 4 March 2019. The result of the move review was closure endorsed. |
The result of the move request was: No consensus ( closed by non-admin page mover) SITH (talk) 15:23, 3 March 2019 (UTC)
– The module is being re-structured as discussed above. In addition to making more sense as a name, the new title allows a smoother transition by allowing templates to be tested individually. Ythlev ( talk) 08:43, 10 February 2019 (UTC)--Relisting. Warm Regards, ZI Jony (Talk) 17:49, 16 February 2019 (UTC)--Relisting. Dekimasu よ! 18:52, 23 February 2019 (UTC)
As above, I support the restructuring and the module rename. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)Ythlev ( talk) 08:48, 10 February 2019 (UTC)
ultimately those things are in service of displaying navigation between stationsDo {{ Line link}} and {{ Rail color}} do that? Ythlev ( talk) 04:16, 15 February 2019 (UTC)
In
Template:S-rail/lines, you are able to only display a picture of the system title with a clickable link, since sometime the icon of the system only contains name. In Adjacent station, I do not think it is possible without displaying the text. Could we have a new parameter name like system header format
, which can let editor put an image in without displaying the name of the system in word? --
VulpesVulpes825 (
Talk)
04:22, 15 February 2019 (UTC)
system title
empty?
Ythlev (
talk)
05:21, 15 February 2019 (UTC)
Campanelli Stadium is showing "Lua error in Module:Adjacent_stations at line 403: "title" is missing from the data page" in the infobox due to use of {{rail color box|system=MBTA|line=Middleborough/Lakeville}}
.
Module:Adjacent stations/MBTA seems to have an entry. I'm hoping someone here will fix the problem.
Johnuniq (
talk)
09:09, 8 March 2019 (UTC)
Similar at
Johnuniq ( talk) 09:15, 8 March 2019 (UTC)
Please change the code to the that in the sandbox, proposed previously, as it has been tested to work. Refer to the testcases for details. Visible changes include support for hashed colour codes, type being rendered in parentheses, and new parameters to add or modify icons and boxes. Ythlev ( talk) 10:38, 15 March 2019 (UTC)
Question: how is this going to work with background gradients? Module:Adjacent stations/SEPTA and Module:Adjacent stations/MBTA use these. They require multiple declarations of background-image to implement. Mackensen (talk) 12:11, 16 March 2019 (UTC)
Not done: please establish a
consensus for this alteration
before using the
{{
edit template-protected}}
template.. This restructure seems to be controversial, per discussion above.
{{3x|p}}ery (
talk)
18:01, 16 March 2019 (UTC)
@ Mackensen:@ Jc86035: Regarding infobox station styles I'm more inclined to agree with you now. I don't know how the current version is written, but I find it incredibly hard to write a function that is doubly backwards compatible, and the html library doesn't seem to support gradients. I think I'm just use unstructured styles. However I think the three tables should still be placed under ['infobox station'] otherwise newcomers would have no idea what they are. Ythlev ( talk) 19:50, 17 March 2019 (UTC)
Current | Proposed |
---|---|
local p = {
"name format" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"header background color" = {
"00537E",
"Amtrak old" = "0078B9",
}
}
|
local p = {
"infobox station" = {
"header" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"sub-header" = {
"background-color: #00537E; color: #FFFFFF",
"Amtrak old" = "background-color: #0078B9; color: #FFFFFF",
},
},
}
|
![]() | This
edit request to
Template:Infobox station and
Module:Adjacent stations has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please copy respective sandboxes for these two pages. In response to the issue raised by Mackensen and following the suggestion of Jc86035, I've made the infobox function work with existing formats ( testcases). Ythlev ( talk) 06:28, 19 March 2019 (UTC)
@ Ythlev: I've reverted both changes because something broke and I don't know why.
Original | Proposed change | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Jc86035 ( talk) 17:00, 19 March 2019 (UTC)
. As far as I can tell, no new consensus has developed in favor of this request since then.
{{3x|p}}ery (
talk)
22:15, 19 March 2019 (UTC)
Not done: please establish a
consensus for this alteration
before using the
{{
edit template-protected}}
template.. This restructure seems to be controversial, per discussion above.
{{3x|p}}ery (
talk) 18:01, 16 March 2019 (UTC)
It would be really cool to use adjacent station (P197) with the towards (P5051) and connecting line (P81) qualifiers. The terminus (P559) of the connecting line (P81) can be used for orientation (including, perhaps, the terminus (P559) direction (P560) to help decide which way should be left and which should be right, e.g. north/west as right and south/east as left). -- Hhm8 ( talk) 01:45, 27 March 2019 (UTC)
@ Hhm8: The data is just not mature enough yet (we haven't even figured out how to do one-way services properly yet). When planning how this template would function, I reasoned that it would be a few years until Wikidata could be used for this. Unless you want to do all of the importing work and all of the referencing and all of the vandalism reverting, I don't think this is a possibility in the short term. Maybe for a few stations, like Tsuen Wan West station (Q841883), it would be possible, but otherwise the data is far too incomplete. You'd also have to half-rewrite the module again, and that's already been done at least twice.
Also, another issue with taking all of the data is that you'd have to figure out how to present it without making it look weird; e.g. for Tsuen Wan West station, the terminus change in 2009 is not shown in the table, but nevertheless needs to be included in Wikidata in order to make the statements complete. Jc86035 ( talk) 16:42, 17 April 2019 (UTC)
Hello, I was wondering if it would be possible to have a shortcut for some subpages, e.x. "wmata" for "Washington Metro". In my editing of transit articles over the past few years, I have been quite agressive in changing traditional page links to the appropriate system template in article bodies, e.x. [[Vienna station (Washington Metro)|Vienna]]
->{{wmata|Vienna}}
({{
wmata}} is a shortcut for {{
WMATA stations}}). Changing the above example to the {{
stl}} format adds an unnecessary 15 characters. –
Daybeers (
talk)
06:00, 17 April 2019 (UTC)
Can't we just have all of the existing templates be redirects instead of the current practice of deleting them when adjacent stations is fully implemented? For example, have {{wmata|Vienna}}
redirect to {{stl|Washington Metro|Vienna}}
. –
Daybeers (
talk)
16:06, 17 April 2019 (UTC)
![]() | 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 |
@ Ythlev: Is there a significant benefit to completely rewriting the HTML generation of the module (bearing in mind that a supermajority of modules do not use the mw.html library at all)? As I understand it the output will be the same and the performance will likely be the same or slightly worse. Jc86035 ( talk) 09:51, 25 December 2018 (UTC)
@ Ythlev: If it's possible I think it would be better to move the successionBox code into the main module, since it would keep all of the code in one place (benefits for copying to other wikis, other users finding the source of script errors, possibly the revision history). Jc86035 ( talk) 03:29, 25 January 2019 (UTC)
["name format"]
as I have no idea how they work.
Ythlev (
talk)
08:28, 25 January 2019 (UTC)I gather that there's some checking taking place in Infobox station and possibly elsewhere for the existence of modules before falling back on traditional templates. I'm starting to create Module:Adjacent stations/Metra (unsaved as yet) and I see that a number of things link to it. Is this just color handling? How much of the module needs to be stable and returning reasonable values before I put it into production? Mackensen (talk) 05:11, 27 December 2018 (UTC)
Apologies if this was already answered above. It's a common pattern with s-line implementations (see e.g. "Belmont" in {{
Metra stations}}) to identify the correct station format based on passed parameters such as line and branch. I know those are available as replacements (%2
and %3
), but is it possible/desirable to replicate that concept here? Obviously in the alternative we could use explicit named keys. Thanks,
Mackensen
(talk)
16:16, 28 December 2018 (UTC)
A useful feature in the s-rail universe is {{ s-rail-next}}, which can be used to suppress the display of the redundant "preceding" and "next" headers where multiple systems are in play and span the system title instead. See Pennsylvania Station (New York City) for a prominent example: the titles headers are shown for Amtrak, but suppressed for the LIRR and NJ Transit. Besides avoiding redundancy, this can make things less cramped when there are long system titles. I would think the module could do this automatically for any systems after the first system. Mackensen (talk) 04:20, 29 December 2018 (UTC)
@ Mackensen: I personally considered it inconsistent to do so, and it makes it more difficult to distinguish between "system" headers and "other" (e.g. "Under construction") headers, especially for systems which don't use icons. Usage of {{ S-rail-next}} also seems to have significant regional variation:
Country | Pages with S-rail-next (approx.) |
---|---|
United States | 774 |
United Kingdom | 150 |
Netherlands | 52 |
Canada | 35 |
Malaysia | 31 |
Japan | 29 |
France | 19 |
South Africa | 10 |
China | 8 |
Singapore | 3 |
Australia | 2 |
Finland | 2 |
Germany | 2 |
Thailand | 2 |
Denmark | 1 |
India | 1 |
{{ S-line}} is used for station articles in about 48 countries; {{ S-rail-next}} in about 16 countries, and somewhat uniformly in only about five or six of those countries. Hong Kong and Taiwan almost exclusively use {{ Adjacent stations}}. While this isn't a very rigorous analysis, there are certainly more than two multi-modal or multi-system stations in Germany or Australia. (The queries I used exclude non-station articles, such as articles for places which use the template.) Jc86035 ( talk) 10:00, 29 December 2018 (UTC)
It would certainly be possible to add that functionality, but it would add unnecessary complexity to both the main and convert functions, and I'm not sure if it's desirable. Jc86035 ( talk) 10:39, 29 December 2018 (UTC)
|system-nextn=yes
sort of parameter be used? Would it be an editorial decision as to whether it's used, would it be set per system, ...?|system-nextn=yes
would be a good solution.
Mackensen
(talk)
15:42, 30 December 2018 (UTC)
{{ Station link}} is supposed to support line parameters but this doesn't seem to be working: Template:Station link/testcases. The second test has no default case, so it fails with a script error. The third test has a default case which it falls back to, but it's the wrong value for the passed line parameter. Mackensen (talk) 16:35, 5 January 2019 (UTC)
I'm having an issue where short name
doesn't seem to be respected with {{
rail color box}}. See
User:Mackensen/temp for examples leveraging
Module:Adjacent stations/PAAC. I did notice that the last conditional in p._box refers to line instead of lineN, but wasn't sure if this was deliberate and I'm wary of modifying the module.
Mackensen
(talk)
17:47, 15 January 2019 (UTC)
short name
is only used for the display types where the name is inside a box (route, croute and xroute). For the other styles it's ignored; this is largely deliberate, since templates like {{
RouteBox}} tend to be used side-by-side, so you would want to abbreviate them as much as possible.
Jc86035 (
talk)
15:48, 16 January 2019 (UTC)Unusual situation which I've documented at User:Mackensen/temp#Willow station (PAAC). The goal is to indicate that certain stations were closed by using the note-rightn parameter. The Blue Line - South Hills Village (via Overbrook) should be displayed as going to both Martin Villa (closed 2012) and St. Anne's. The latter box is shared with the Red Line - South Hills Village (via Beechview). The pixel height is so minimal as to be indistinguishable. In the second template I suppressed the note and it works visually, but the closure information is lost. Mackensen (talk) 02:54, 22 January 2019 (UTC)
@ Ythlev: I think it would be better to avoid moving the module to a new title again, particularly if you're not actually going to do all of the page moves in one go. Nthep has already reverted one of the page moves. Any change in the module name would be purely cosmetic, although I'm not going to stop you from making such a change. Jc86035 ( talk) 19:00, 28 January 2019 (UTC)
The result of the move request was: WITHDRAWN. This move is part of a wider move, which should be discussed together. In addition, consensus has changed. Withdrawing to make a centralised request. ( non-admin closure) Ythlev ( talk) 08:20, 10 February 2019 (UTC)
– New module name Ythlev ( talk) 15:19, 29 January 2019 (UTC) --Relisting. SITH (talk) 17:39, 8 February 2019 (UTC)
{{Module:Adjacent stations/doc}}
to
Module:Rail/doc). --
Ahecht (
TALKp.convert
function in the new code is exactly the same as the current version. I am currently concerning that the new version do not cover all the exception exist in the old version due to the lack explanation from the other. @
Ythlev:, I do suggest you to add enough comments in your code, do the same thing as the current version by creating a Internationalization table at the top for people to do easy translation and explain what you have changed or redo in detail (like I use AA than BB in the XX function of the current version. BB is CC, which is faster or better than the current version) before suggestion for edit. Also, due to the exact same function name in most of the function in both version, I would suggest you to just submit a edit request on the current version rather than asking to convert to your new version in order to preserve the current edit history in Adjacent stations. Also, I agree with
User:Jc86035 that the code in Adjacent station is not buggy, but may need a
Code refactoring in one or two function. However, I do not think the whole thing need to be redesigned, since your new code actually break everything based on the edit history suggest. I love people want to do
Code refactoring, but not without discussion. --
VulpesVulpes825 (
Talk)
02:31, 3 February 2019 (UTC)This move is part of a wider move of having Module:Adjacent stations be renamed to Module:Rail, the discussion for which is below. Ythlev ( talk) 16:17, 9 February 2019 (UTC)
Why was Template talk:Adjacent stations moved to Module talk:Rail? What about Template:Adjacent stations? I assume the move is premature or was a mistake and should be reverted? Johnuniq ( talk) 04:44, 30 January 2019 (UTC)
You said the previous section, which is about the doc. Where is the rule that all page moves must be discussed? Ythlev ( talk) 13:01, 30 January 2019 (UTC)
Module:Adjacent stations is buggy and hard to fix because of the structure, which is also hard for new editors to understand. Therefore it has been re-designed. In order to better diagnose problems, it is given a new name: Module:Rail. Code for Station link and Line link have been tested to work fine, so they invoke the new Module:Rail. Code for other templates are still under testing, after which they will also invoke Module:Rail. Module:Adjacent stations/doc has been moved to Module:Rail/doc to match the new module name. In what I thought was an obvious move, I also moved this talk page to also match the new name, but apparently some have problems with it. I am open to being convinced. Ythlev ( talk) 13:34, 30 January 2019 (UTC)
["right terminus"] = {"Chesham","Amersham"}
, I'm pretty sure I implemented that in June last year. It was also changed when the template had fewer than 500 transclusions, whereas the template now has more than 1,300.put in to the sandbox and request edit on this current moduleI did do the former. I didn't 'request edit' but I did mention the change on this talk page.
your code actually become way harder to read compare to the current version due to lack of commentsYou are the first to think that. Comments are easy to add and would be if you think they are necessary; the re-designed version is much better structured and one user has agreed with me.
and not having a internationalize tableThe table was just moved elsewhere and guess what, that change was reinstated by Pppery on the live version. Ythlev ( talk) 05:24, 3 February 2019 (UTC)
It is better for you to put into the sandbox and have a test-case to show that the external appearance is unchanged
I did exactly that.
Ythlev (
talk)
05:53, 3 February 2019 (UTC)
@ Pppery: I reverted your lasted edit. You don't get to get to pick and choose which of my edits are 'clear improvements' and which are disruptive editing. And Module:Rail is no longer used by live templates, so by deleting it before this discussion if finished, you are claiming ownership and I will also report you if you keep this up. Ythlev ( talk) 04:58, 3 February 2019 (UTC) @ Cards84664: This goes to you too. Ythlev ( talk) 05:07, 3 February 2019 (UTC)
@ Mackensen:@ Redrose64:@ Johnuniq: A month or two ago I experimented with re-designing the module at Module:Adjacent stations/sandbox. On 25 December, I explained here why I felt the module should be re-designed. On 5 January, I mentioned in the same section that the sandbox was partially complete. Some time around 28 January I moved Module:Adjacent stations/sandbox and I explained here why I felt it should be renamed. Up until this point, no one rejected my proposals, and I have been tirelessly testing the new code with the sandbox. I had {{ Line link}} and {{ Rail color}} use the new module after the tests were okay. It was not until I moved the doc and talk pages that it became contentious.
Mackensen, are the following sentences two questions of yours that you wanted answers to?
If the proposal is to retain all the same functionality in the same place but as Module:Rail instead of Module:Adjacent stations, then that's fine, but it's not clear that you're proposing that. I may also be confused by the edits you were making to Module:Adjacent stations/Amtrak.
It's unclear and you 'may' be confused, but did you wanted me to explain? It sounded like it's unclear but you understood anyways and think it's fine.
Ythlev (
talk)
15:54, 31 January 2019 (UTC)
Due to the recent controversial move from Moudle:Adjacent stations to Module:Rail, the talk page is now being to large. Is it OK for me to introduce a achieve bot so that the page can be smaller and contain relevant discussion in order to follow the guideline? Also, since there are three to four heading for the same topic, is it OK for me to combine them in to one and move to ANI in order to centeralize discussion and let people understand exactly is going on? I will indicate on ANI that this whole thread should be archived back to this talk page once this issue is resolved (This is kind of the rule on Chinese Wikipedia that talk should be archieved back to original place once it is finished)? -- VulpesVulpes825 ( Talk) 21:19, 2 February 2019 (UTC)
I looked at Special:PrefixIndex/Template:Adjacent stations and Special:PrefixIndex/Template talk:Adjacent stations. I didn't check everything but it seems to be ok except possibly for Template talk:Adjacent stations/testcases. @ Mackensen: Would you please check that last link which currently redirects to Module talk:Rail but which probably should redirect to here. Johnuniq ( talk) 01:34, 3 February 2019 (UTC)
I do understand the frustration in the current incident, but I do think Ythlev's version is a better version than the current version and here are the reasons:
Due to the reasons above, I would strongly recommend to merge
Ythlev's new version to the current version. This merge should be done by
Ythlev themselves since
Ythlev is the original author of this module. It is also maybe a good idea to change the name from Adjacent stations to Rail since the name Rail can represent things like line color, which using Adjacent station does not making any sense. I will start request to edit the Module, which is now been template editor protected, after 10 days, if a consensus is made in the discussion in this discussion or no one response, which becomes a
silent consensus. --
VulpesVulpes825 (
Talk)
06:29, 3 February 2019 (UTC)
Update As I mentioned in the discussion below, I tested the new version in the Chinese wikipedia and it break all the Infobox station template by not letting the Infobox station have the default heading color. Due to the fact that the new version will not produce the correct default color for the heading of the Infobox station, I will not recommend the merge until this problem is fixed. -- VulpesVulpes825 ( Talk) 23:10, 3 February 2019 (UTC)
![]() | This
edit request to
Module:Adjacent stations has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Request revert version back to [ Pppery's version]. It is a good idea to move the internationalization table to a separate table so that it is easier for people like me to translated it into other Language version. -- VulpesVulpes825 ( Talk) 23:15, 3 February 2019 (UTC)
Notifying Mackensen, VulpesVulpes825, Redrose64, Johnuniq and Ahecht. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)
For Module:Adjacent stations, I propose the following changes. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
As mentioned above by VulpesVulpes825, the code benefits from a better structure. The current version re-invents the wheel like the functions of mw.text.listToText and Module:TableTools. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
As above, I support the restructuring and the module rename. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)
Is the proposal that the main module be replaced with the sandbox?It is still under discussion.
(1) Use one blank line between functions; (2) Do not combine multiple variable declarations with assignment ("local p, data, ...");The code is already nearly 700 lines long. All that and it would be too long to navigate.
(4) Are the module-level globals in the first line really necessary?They are not globals, they are variables local to the entire module. They are there because they are used by more than one function. You could pack them into the args table or have the functions take those as arguments, but what does it matter? You would only be confusing editors. Ythlev ( talk) 09:59, 7 February 2019 (UTC)
Support, As I mentioned above, I do think the new version is better since the new version illuminate pure html code. I may able to do a beta testing on the Chinese wikipedia to give it a try. --
VulpesVulpes825 (
Talk) 18:13, 7 February 2019 (UTC)
Apart from the fact that this name makes more sense, the module is used by several templates. The code for each template may be dependent on each other. It is much easier to use a new module, then for each function that is tested to work properly, have the template invoke the new module. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
As above, I support the restructuring and the module rename. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)Ythlev ( talk) 08:47, 10 February 2019 (UTC)
I've made a move request below. Please comment there instead. Ythlev ( talk) 08:49, 10 February 2019 (UTC)
I propose that all colour codes be prepended with '#' since they are machine-read and need to have the symbol. The current sandbox version supports hashed and unhashed codes for backwards compatibility. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
I'm fine with the change to the colour codes, as long as you don't break anything, although this would introduce an inconsistency with S-line. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)
The HTML library supports structured CSS arguments. I propose the below structure for data modules so that barely any code is needed to process the arguments.
Current | Proposed |
---|---|
local p = {
"name format" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"header background color" = {
"00537E",
"Amtrak old" = "0078B9",
}
}
|
local p = {
"infobox station" = {
"header" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"sub-header" = {
"background-color: #00537E; color: #FFFFFF",
"Amtrak old" = "background-color: #0078B9; color: #FFFFFF",
},
},
}
|
I also propose swapping positional arguments to bring it in line with other templates.
Current | Proposed |
---|---|
{{#invoke:Adjacent stations|style|header|{{{style|}}}|{{{style2|}}}}} |
{{#invoke:Adjacent stations|infoboxStation|{{{style|}}}|{{{style2|}}}|_header}}
|
Ythlev ( talk) 07:08, 7 February 2019 (UTC)
I'm not really sure if changing the infobox function would be beneficial for users, and it would necessitate an extra step in S-line conversion, but I personally haven't used it in a while so I don't know if this would be disruptive. I think it would be better if {{
Line link}} and {{
Rail color box}} retain their current functions, at least until {{
S-line}} templates have been completely replaced, since the vast majority of {{
Rail color box}} uses are with S-line helper templates, using the original styles; furthermore, {{
Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing, especially since you would be adding at least two of the original {{
Rail color box}} functions to the template.
Jc86035 (
talk) 09:12, 7 February 2019 (UTC)
I'm not really sure if changing the infobox function would be beneficial for users, and it would necessitate an extra step in S-line conversionWell, the easiest thing to do would be to not convert at all.
lines['_default']
and treat sub-styles as lines, if it makes sense.
Ythlev (
talk)
13:16, 7 February 2019 (UTC)Notifying Jc86035. Ythlev ( talk) 18:35, 9 February 2019 (UTC)
I propose that the style setting function be extended to {{ Infobox rail line}}, as it is similar to station. Ythlev ( talk) 18:15, 9 February 2019 (UTC)
I propose merging {{ Rail color box}} (RCB) into {{ Line link}} and {{ Rail icon}}, with backwards compatibility. RCB already displays line link for four styles. Link link can just have a parameter that prepends the box. Line link should also be able to prepend icons, as this is frequently used. Rail icon currently can be set to display RCB. It should be designed to let users set which style of RCB to use and completely replace RCB.
These changes have not been coded yet. Ythlev ( talk) 07:08, 7 February 2019 (UTC)
I think it would be better if {{
Line link}} and {{
Rail color box}} retain their current functions, at least until {{
S-line}} templates have been completely replaced, since the vast majority of {{
Rail color box}} uses are with S-line helper templates, using the original styles; furthermore, {{
Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusing, especially since you would be adding at least two of the original {{
Rail color box}} functions to the template.
Jc86035 (
talk) 09:12, 7 February 2019 (UTC)
I think it would be better if {{ Line link}} and {{ Rail color box}} retain their current functions, at least until {{ S-line}} templates have been completely replacedRail color box would be just left working as it is.
{{ Line link}} has a small and specific role right now (replicating the link functionality of "system lines" templates), and expanding that role would be confusingI think it is equally confusing that Rail icon can be set to display RCB. RCB is just a really weird template. Instead of letting users customise the output like
|linked_box=yes
or |show_text=yes
, it just has 12 pre-defined styles that seemingly come from nowhere. you would be adding at least two of the original {{ Rail color box}} functions to the template.. If you are referring to the code structure, I'm pretty sure that it can be written to be not be confusing. Ythlev ( talk) 09:49, 7 February 2019 (UTC)
|inline=yes
) if they make the template easier to use, which adding several long named parameters wouldn't do.As for {{
Rail color box}},{{
Rail icon}}, {{
Rail color}} and {{
Line link}}, I do think it a good idea to combine all into one template (with backward compatibility if possible) since all four template's function overlap with each other. However, I do think it may be a good idea to separate the merge request as a new request rather than been part of the code refactoring request, since this may need a longer discussion which may delay the code update to the main module. --
VulpesVulpes825 (
Talk) 18:13, 7 February 2019 (UTC)
![]() | This discussion was listed at Wikipedia:Move review on 4 March 2019. The result of the move review was closure endorsed. |
The result of the move request was: No consensus ( closed by non-admin page mover) SITH (talk) 15:23, 3 March 2019 (UTC)
– The module is being re-structured as discussed above. In addition to making more sense as a name, the new title allows a smoother transition by allowing templates to be tested individually. Ythlev ( talk) 08:43, 10 February 2019 (UTC)--Relisting. Warm Regards, ZI Jony (Talk) 17:49, 16 February 2019 (UTC)--Relisting. Dekimasu よ! 18:52, 23 February 2019 (UTC)
As above, I support the restructuring and the module rename. Jc86035 ( talk) 09:12, 7 February 2019 (UTC)Ythlev ( talk) 08:48, 10 February 2019 (UTC)
ultimately those things are in service of displaying navigation between stationsDo {{ Line link}} and {{ Rail color}} do that? Ythlev ( talk) 04:16, 15 February 2019 (UTC)
In
Template:S-rail/lines, you are able to only display a picture of the system title with a clickable link, since sometime the icon of the system only contains name. In Adjacent station, I do not think it is possible without displaying the text. Could we have a new parameter name like system header format
, which can let editor put an image in without displaying the name of the system in word? --
VulpesVulpes825 (
Talk)
04:22, 15 February 2019 (UTC)
system title
empty?
Ythlev (
talk)
05:21, 15 February 2019 (UTC)
Campanelli Stadium is showing "Lua error in Module:Adjacent_stations at line 403: "title" is missing from the data page" in the infobox due to use of {{rail color box|system=MBTA|line=Middleborough/Lakeville}}
.
Module:Adjacent stations/MBTA seems to have an entry. I'm hoping someone here will fix the problem.
Johnuniq (
talk)
09:09, 8 March 2019 (UTC)
Similar at
Johnuniq ( talk) 09:15, 8 March 2019 (UTC)
Please change the code to the that in the sandbox, proposed previously, as it has been tested to work. Refer to the testcases for details. Visible changes include support for hashed colour codes, type being rendered in parentheses, and new parameters to add or modify icons and boxes. Ythlev ( talk) 10:38, 15 March 2019 (UTC)
Question: how is this going to work with background gradients? Module:Adjacent stations/SEPTA and Module:Adjacent stations/MBTA use these. They require multiple declarations of background-image to implement. Mackensen (talk) 12:11, 16 March 2019 (UTC)
Not done: please establish a
consensus for this alteration
before using the
{{
edit template-protected}}
template.. This restructure seems to be controversial, per discussion above.
{{3x|p}}ery (
talk)
18:01, 16 March 2019 (UTC)
@ Mackensen:@ Jc86035: Regarding infobox station styles I'm more inclined to agree with you now. I don't know how the current version is written, but I find it incredibly hard to write a function that is doubly backwards compatible, and the html library doesn't seem to support gradients. I think I'm just use unstructured styles. However I think the three tables should still be placed under ['infobox station'] otherwise newcomers would have no idea what they are. Ythlev ( talk) 19:50, 17 March 2019 (UTC)
Current | Proposed |
---|---|
local p = {
"name format" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"header background color" = {
"00537E",
"Amtrak old" = "0078B9",
}
}
|
local p = {
"infobox station" = {
"header" = {
"font-size: 160%; font-family:sans-serif; font-weight: bolder; color: #FFFFFF; background-color: #00537E; padding: 0.4em 4px;",
"Amtrak old" = "font-size: 160%; font-family:Helvetica; font-weight: bolder; color: #ffffff; background-color: #0078B9; padding: 0.4em 4px;"
},
"sub-header" = {
"background-color: #00537E; color: #FFFFFF",
"Amtrak old" = "background-color: #0078B9; color: #FFFFFF",
},
},
}
|
![]() | This
edit request to
Template:Infobox station and
Module:Adjacent stations has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please copy respective sandboxes for these two pages. In response to the issue raised by Mackensen and following the suggestion of Jc86035, I've made the infobox function work with existing formats ( testcases). Ythlev ( talk) 06:28, 19 March 2019 (UTC)
@ Ythlev: I've reverted both changes because something broke and I don't know why.
Original | Proposed change | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Jc86035 ( talk) 17:00, 19 March 2019 (UTC)
. As far as I can tell, no new consensus has developed in favor of this request since then.
{{3x|p}}ery (
talk)
22:15, 19 March 2019 (UTC)
Not done: please establish a
consensus for this alteration
before using the
{{
edit template-protected}}
template.. This restructure seems to be controversial, per discussion above.
{{3x|p}}ery (
talk) 18:01, 16 March 2019 (UTC)
It would be really cool to use adjacent station (P197) with the towards (P5051) and connecting line (P81) qualifiers. The terminus (P559) of the connecting line (P81) can be used for orientation (including, perhaps, the terminus (P559) direction (P560) to help decide which way should be left and which should be right, e.g. north/west as right and south/east as left). -- Hhm8 ( talk) 01:45, 27 March 2019 (UTC)
@ Hhm8: The data is just not mature enough yet (we haven't even figured out how to do one-way services properly yet). When planning how this template would function, I reasoned that it would be a few years until Wikidata could be used for this. Unless you want to do all of the importing work and all of the referencing and all of the vandalism reverting, I don't think this is a possibility in the short term. Maybe for a few stations, like Tsuen Wan West station (Q841883), it would be possible, but otherwise the data is far too incomplete. You'd also have to half-rewrite the module again, and that's already been done at least twice.
Also, another issue with taking all of the data is that you'd have to figure out how to present it without making it look weird; e.g. for Tsuen Wan West station, the terminus change in 2009 is not shown in the table, but nevertheless needs to be included in Wikidata in order to make the statements complete. Jc86035 ( talk) 16:42, 17 April 2019 (UTC)
Hello, I was wondering if it would be possible to have a shortcut for some subpages, e.x. "wmata" for "Washington Metro". In my editing of transit articles over the past few years, I have been quite agressive in changing traditional page links to the appropriate system template in article bodies, e.x. [[Vienna station (Washington Metro)|Vienna]]
->{{wmata|Vienna}}
({{
wmata}} is a shortcut for {{
WMATA stations}}). Changing the above example to the {{
stl}} format adds an unnecessary 15 characters. –
Daybeers (
talk)
06:00, 17 April 2019 (UTC)
Can't we just have all of the existing templates be redirects instead of the current practice of deleting them when adjacent stations is fully implemented? For example, have {{wmata|Vienna}}
redirect to {{stl|Washington Metro|Vienna}}
. –
Daybeers (
talk)
16:06, 17 April 2019 (UTC)