Jump to content

Template talk:Stnlnk

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:Stnlnk/doc)

Station Disambig

[edit]

Would it be possible to add a second param so stations like Sheffield Midland and Sheffield Victoria can be distinguished between? Sfan00 IMG (talk) 12:21, 13 June 2012 (UTC)[reply]

I see an optional parameter has been added, to allow for cases where the disambiguation is in brackets, e.g. Bramley (Hampshire) railway station. This won't help in the case of the Sheffield stations listed above. However, this depends on how the user wants to display the result - e.g. Sheffield Midland or Sheffield. As there are various permutations possible, it would be easier simply to use a piped link in these circumstances. It's also worth bearing in mind that the method of disambiguating stations is inconsistent - see Whitchurch railway station for example.  An optimist on the run! 12:59, 13 June 2012 (UTC)[reply]
Where would be the best place to sart a disscussion about naming consistency?
UK Approach seems to be <name> (<locality>|<operator>) for open stations and <name> (<company>) for historical.

Sfan00 IMG (talk) 13:27, 13 June 2012 (UTC)[reply]

A couple of hiccups with today's edits. Firstly, {{stnlnk|Bramley|Hampshire}} resolves to Bramley(Hampshire) railway station rather than Bramley (Hampshire) railway station. Secondly the documentation talks of [[Bramley (Hampshire) railway station|Newport]], and I assume it was intended to be [[Bramley (Hampshire) railway station|Bramley]]. - David Biddulph (talk) 13:13, 13 June 2012 (UTC)[reply]
Looks like the first hiccups been fixed - result is now Bramley. I've corrected my mistake in the documentation.  An optimist on the run! 13:49, 13 June 2012 (UTC)[reply]
I believe that the position of the disambiguator depends upon whether or not the disambiguator was part of the official name. However, the best place for discussion would be at Wikipedia talk:Naming conventions (UK stations) (where there have been inconclusive discussions in the past). If starting a new thread there, or restarting the existing one, you should also pop a note at WT:UKRAIL, WT:STATIONS and WT:RAIL pointing back to that discussion. --Redrose64 (talk) 15:54, 13 June 2012 (UTC)[reply]
You're welcome to raise this issue again on the talk page of the article which Redrose mentions. There is a discussion there from 2010 to which I contributed where much banging of heads against walls took place. Lamberhurst (talk) 19:43, 13 June 2012 (UTC)[reply]

Station Disambiguation (again)

[edit]

Would it be possible to add a (named) parameter so that a disambiguation name could be included after a separating comma, in the manner of {{StnlnkA}}? (Hopefully this would be a non-controversial addition.) Useddenim (talk) 22:05, 16 June 2013 (UTC)[reply]

Which stations use a comma instead of a parenthesis? --Redrose64 (talk) 09:21, 17 June 2013 (UTC)[reply]
I haven't figured out how to get a listing of all the articles that contain “railway station, ” in the page name, but there are many from Australia (Adelaide, Brisbane, Melbourne, New South Wales, Perth), with a number of others for Scotland, and a few from the USA (Chicago, West Virginia), and Canada (Montreal). Useddenim (talk) 13:50, 17 June 2013 (UTC)[reply]
Which ones in Scotland? --Redrose64 (talk) 18:20, 17 June 2013 (UTC)[reply]
There's probably more around and about, but these are the ones I've found so far. Useddenim (talk) 22:37, 17 June 2013 (UTC)[reply]
These are aberrations which need to be fixed rather than accommodated. The use of parentheses after the station name is the standard method of disambiguation used in railway material. Lamberhurst (talk) 07:34, 18 June 2013 (UTC)[reply]
I'm sure the Aussies appreciate being referred to as aberrations. — Preceding unsigned comment added by 128.205.249.70 (talk) 16:37, 18 June 2013 (UTC)[reply]
Since when was Scotland part of Australia? --Redrose64 (talk) 17:41, 18 June 2013 (UTC)[reply]

208 238 stations in Australia and New Zealand are of the form “Name, Place”. This is more than just “an aberration”.

Stations

Useddenim (talk) 00:07, 19 June 2013 (UTC)[reply]

Not quite sure how this helps given that Australian and New Zealand stations are covered by {{StnlnkA}} which, as is rightly mentioned above, incorporates the functionality sought here. Lamberhurst (talk) 07:39, 19 June 2013 (UTC)[reply]
I wrote {{Stnlnk2}} as a quick hack when I saw that {{Stnlnk}} was edit protected. I expanded its functionality and renamed it when all I got were snide remarks (“aberrations”, “Scotland part of Australia”) instead of help.
Nonetheless, this still doesn't address the issue noted previously of “Name (Disambig) railway stationvs.Name railway station (Disambig)”. Useddenim (talk) 00:02, 20 June 2013 (UTC)[reply]
My comment here was not directed at you but at the comment immediately above, which was itself a response to Lamberhurst. I took Lamberhurst's remark about "aberrations" as referring to the three Scottish stations which have a comma. --Redrose64 (talk) 10:04, 20 June 2013 (UTC)[reply]
I'm afraid that I don't see any snide remarks in the above discussion except perhaps that of the anonymous ip. If you feel that my remarks caused offence, please accept my apology. Lamberhurst (talk) 12:44, 20 June 2013 (UTC)[reply]

Change request

[edit]

Would it be possible to change the coding of the template
from [[{{#if:{{{2|}}}|{{{1}}} ({{{2}}})|{{{1}}}}} railway station|{{{1}}}]]
  to   [[{{#if:{{{2|}}}|{{{1}}} ({{{2}}})|{{{1}}}}} railway station|{{{alt|{{{1}}}}}}]] ?

This would allow for the use of the optional parameter alt= to change the wikilink text, but would not affect any existing usage of the template. Useddenim (talk) 00:41, 9 October 2013 (UTC)[reply]

Question: Why not just use the explicit |1= that already exists? — {{U|Technical 13}} (tec) 23:26, 28 February 2014 (UTC)[reply]
Because the template, as it currently is written, uses the same input for both the wikilink target and text. However, it is not always desirable to have both the same. For example, a local diagram would want to differentiate between say [[Exeter St Davids railway station]] and [[Exeter St Thomas railway station]], but on a cross-country RDT [[Exeter Central railway station|Exeter]] may be sufficient. Useddenim (talk) 01:18, 1 March 2014 (UTC)[reply]
Would [[{{#if:{{{2|}}}|{{{1}}} ({{{2}}})|{{{1}}}}} railway station|{{#if:{{{2|}}}|{{{1}}} ({{{2}}})|{{{1}}}}}]] resolve the problem? I really dislike the idea of adding a new parameter here if it can be avoided (makes the template more confusing and cluttered for inexperienced editors). Marking as answered since I'm now watching it while we figure what is best. :) — {{U|Technical 13}} (tec) 02:15, 1 March 2014 (UTC)[reply]
No, because that would eliminate the (internal) disambiguation (and IMHO also be more confusing to try and understand). My thinking is that making it a named parameter would make it less likely for inexperienced editors to muck around with it (because it requires slightly more thought about what they’re doing). Useddenim (talk) 15:58, 1 March 2014 (UTC)[reply]
Useddenim, do you really need this? {{stnlnk|Exeter Central|Exeter}} is not that shorter than [[Exeter Central railway station|Exeter]]. I only use such templates (and I do use them extensively, as you may know) when they really improve code readability. In this case there is not much difference, IMHO, while adding another clause for such an ubiquitous template isn't very good. YLSS (talk) 11:54, 1 March 2014 (UTC)[reply]
Perhaps Exeter isn’t the best example, though; but the London Mainline termini are variously referred to as “London”, “London Foo” or “Foo”, depending on context, but all are linked to [[London Foo railway station]]. (And after being ignored for five months, now suddenly there’s objections?) Useddenim (talk) 15:58, 1 March 2014 (UTC)[reply]
  • Don't you think that is a bit of an exaggeration? You posted this request "17:27, 28 February 2014 (UTC)" according to the page's history. That is when the request was made, not when you first posted the idea months ago and got no input (because no-one was looking until you posted the request. The fact that a tree makes a noise when it falls in the forest means nothing if no-one hears it). Anyway, I need to go right now, but there seems to be a lack of consensus at the moment. — {{U|Technical 13}} (tec) 16:31, 1 March 2014 (UTC)[reply]
Yeah, a little. Useddenim (talk) 17:03, 1 March 2014 (UTC)[reply]

Template-protected edit request on 12 August 2015

[edit]

This template would work better if there was a third parameter allowing text different from parameter 1 to be displayed within the link to ensure better MOS:LINK compliance, as demonstrated in the template sandbox here. Specifically, the contents of the template ought to be adjusted as follows:

[[{{#if:{{{2|}}}|{{{1}}} ({{{2}}})|{{{1}}}}} railway station|{{{1}}}]]

[[{{#if:{{{2|}}}|{{{1}}} ({{{2}}})|{{{1}}}}} railway station|{{#if:{{{3|}}}|{{{3}}}|{{{1}}}}}]]

This ensures that, assuming there is a third parameter, it is used and displayed, otherwise falling back on the default case. This would not affect any change in the template in its current usage.

Strzegom (talk) 05:42, 12 August 2015 (UTC)[reply]

@Strzegom: Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Also, I see that you have been altering a lot of station links to display the word "station" - where was this discussed? --Redrose64 (talk) 16:30, 12 August 2015 (UTC)[reply]
Mild weak support, although I still prefer an explicitly named parameter that clearly indicates that text has been substituted. (And where were you a year-and-a-half ago when I made that suggestion?) Useddenim (talk) 18:57, 12 August 2015 (UTC) |alt= is preferable to unnamed parameter creep. Also, citing MOS:LINK is too vague. Exactly what are you referring to, Strzegom? Useddenim (talk) 19:27, 12 August 2015 (UTC)[reply]
@Useddenim: Link clarity. For example, when referring to a station "X", it would either simply be referred to in the article as [[X railway station|X]], or alternatively, as [[X railway station|X]] station, in which case it might be more appropriate to link to the word "station" as well, as the link refers not to the location "X", but the station "X"; in other words, it would be formatted as [[X railway station|X station]], hence the necessitating a third parameter. Note that when referring to two stations, however, this is not necessary; either it is simply formatted as [[X railway station|X]] and [[Y railway station|Y]], or alternatively, as [[X railway station|X]] and [[Y railway station|Y]] station(s). See sections "Link clarity", "Link specificity", and "Piped links" for further clarification. By the way, I'd be fine with using an |alt= parameter as opposed to an unnamed third parameter; it's probably preferable in any case. Strzegom (talk) 20:28, 12 August 2015 (UTC)[reply]
Also, is there any possibility of deprecating the RWS template? It's redundant to this and MOS:ALLCAPS dictates that it's unnecessary (i.e., articles listed here with "Railway Station" capitalized should be moved). Strzegom (talk) 20:42, 12 August 2015 (UTC)[reply]
Why on earth deprecate the rws template which is shorter and easier to use than this one? MOS:ALLCAPS is of no assistance whatsoever here. Lamberhurst (talk) 21:42, 12 August 2015 (UTC)[reply]
I'm referring to this template, which is used almost nowhere and provides nearly-identical functionality. {{rws}} merely redirects here. Strzegom (talk) 21:46, 12 August 2015 (UTC)[reply]
The {{RWS}} template is not at all equivalent to {{stnlnk}}. If fed with identical values, the results are different. Consider for example {{RWS|Banbury}} and {{stnlnk|Banbury}} - these produce Banbury and Banbury; the redlink makes those obviously different, so try {{RWS|Morningside}} and {{stnlnk|Morningside}} - these produce Morningside and Morningside. --Redrose64 (talk) 22:58, 12 August 2015 (UTC)[reply]
@Strzegom: The more you refer to MOS:LINK the less inclined I become to agree with you, as {{stnlnk}}/{{rws}} et al. are primarily used in WP:Route diagram templates where the word “Station” is generally superfluous. I still agree with the idea that it should be possible to override the default text, but not for the reasons you suggest. Useddenim (talk) 01:04, 13 August 2015 (UTC)[reply]
Although that's the intended use of the template, it is also often used in articles' prose sections, hence this edit request. I personally don't see any reason that it should be used in this way and wouldn't have any objection to simply replacing usages of it in prose to normal link wiki markup, but in what cases would it be necessary to override it otherwise? Strzegom (talk) 01:15, 13 August 2015 (UTC)[reply]

New template idea?

[edit]

Hi, I was wondering whether it would be possible to create a variation of this template that would only require the station's three-letter code, rather than the full station name? For example, {{Template name|TAM}} would expand to [[Tamworth railway station|Tamworth]], and {{Template name|AFS}} would expand to [[Ashford (Surrey) railway station|Ashford]].

Any thoughts? Mvpo666 (talk) 14:09, 18 September 2016 (UTC)[reply]

@Mvpo666: Not a problem at all. Where’s the master list of codes? Useddenim (talk) 14:26, 18 September 2016 (UTC)[reply]
@Useddenim:, the list of all UK railway stations, including their codes, is here: UK railway stations (I assume that's what you mean by "master list of codes"). Mvpo666 (talk) 14:43, 18 September 2016 (UTC)[reply]
While we're at it: if the idea does go ahead, what do you propose to be the name of this template? Mvpo666 (talk) 14:59, 18 September 2016 (UTC)[reply]
{{NRrws}} for National Rail railway station. Useddenim (talk) 01:24, 19 September 2016 (UTC)[reply]
@Mvpo666: UK railway stations is not a master list, it's our list. Since the codes are decided by an organisation like Network Rail, the master list may be somewhere on their website. --Redrose64 (talk) 09:38, 19 September 2016 (UTC)[reply]
@Redrose64: it is, and that’s what I used: National Rail » ‘Station Codes’.
@Mvpo666: You didn’t mention that there’s over 2,000 stations listed! Useddenim (talk) 10:32, 19 September 2016 (UTC)[reply]
@Useddenim: Oops, sorry, I didn't realise it would be this time consuming!
Thank you both very much for your help on this, it is greatly appreciated. I have just finished looking through the whole thing and corrected a few things (changed "&" into "and" where necessary, removed brackets that created red links etc.). There may still be a few mistakes I haven't yet spotted, though. I have also removed all brackets from the second group (except at Kensington (Olympia) because I'm pretty sure (Olympia) is part of the station's actual name). I am now about to create a similar template named {{NRstn}}; it will be intended to be used for stations that do not contain the word railway in their article titles, such as Balham.
Thanks again. Mvpo666 (talk) 18:40, 19 September 2016 (UTC)[reply]

Template-protected edit request on 7 April 2017

[edit]

Please add {{subst:tfm|NRrws|type=tiny}}, and then change the |link= parameter to Wikipedia:Templates for discussion/Log/2017 April 5, per a nomination by Redrose64 Pppery 19:19, 7 April 2017 (UTC)[reply]

Done. Jo-Jo Eumerus (talk, contributions) 19:35, 7 April 2017 (UTC)[reply]
@Pppery and Jo-Jo Eumerus: I would have added it myself if I thought it would be useful. It's not. I am not proposing any changes to the heavily-used ten-year-old template {{stnlnk}}, I am proposing to get rid of two hardly-used recently-created templates that have cryptic parameters, by replacing all their usages with {{stnlnk}} having a meaningful parameter. --Redrose64 🌹 (talk) 22:48, 7 April 2017 (UTC)[reply]

Dadu

[edit]

How should I create a link to Dadu railway station (Pakistan) using {{stnlnk}}? The obvious {{rws|Dadu|Pakistan}} just creates a link to the town: Dadu. In this case I can craftily abuse the typo in redirect Dadu railway station (Sidh) to force the link using {{rws|Dadu|Sidh}}: Dadu, but is there a generic solution? Certes (talk) 13:49, 7 February 2018 (UTC)[reply]

Template has been fixed. It now looks for Xxx (Yyy) as the last alternative (so it will now find Dadu railway station (Pakistan) before Dadu (Pakistan) ). Useddenim (talk) 21:28, 7 February 2018 (UTC)[reply]
Thank you, that's much better. I suspect that will quietly fix quite a number of suboptimal links which haven't been spotted yet, by linking the station rather than the town. Certes (talk) 23:39, 7 February 2018 (UTC)[reply]

Suggested changes

[edit]

Paine Ellsworth and I have worked on some suggested changes to Stnlnk. {{Stnlnk/testcases#General cases}} shows the effects. Summary of changes:

  1. {{Stnlnk|Vizcaya}} links to Vizcaya station if that page exists but no better alternative exists. (Old behaviour: link to dab Vizcaya.)
  2. {{Stnlnk|Akazienweg|KVB}} links to Akazienweg (KVB) if that page exists but no better alternative exists. (Minor bug fix: missing space.)
  3. If no article exists in any known format, {{Stnlnk|Redsville}} creates a redlink to Redsville railway station rather than Redsville.
  4. If no article exists in any known format, {{Stnlnk|Redsville|Redland}} creates a redlink to Redsville railway station (Redland) rather than Redsville railway station, Redland.
  5. A new optional parameter stnonly=yes limits links to article titles containing "station", preventing links to Town or Town (Country). For example, {{Stnlnk|Micklethwaite|stnonly=yes}} creates a redlink to Micklethwaite railway station. (The behaviour of {{Stnlnk|Micklethwaite}} without stnonly is unchanged; it still creates a blue link to Frank W. Micklethwaite.)
  6. A new optional parameter link= forces a link to the specified article without checking the usual formats. (Parameter 2 is ignored if link= is used.)

Comments welcome please. Certes (talk) 01:04, 22 February 2018 (UTC)[reply]

@Certes and Paine Ellsworth: See the below section. This sort of template usually doesn't have any #ifexist calls, and the number of calls seems to be causing some problems, so removing some of them and otherwise making the template less complicated would be beneficial. Jc86035 (talk) 07:44, 22 February 2018 (UTC)[reply]

Performance

[edit]

With the recent changes the performance of the template seems to have gotten a little worse. I noticed this in a couple of articles which ended up in Category:Pages with script errors with too many (over 500) expensive calls errors in the last day or so. In each case the instances of {{rws}} were in large navigation templates, so I fixed the problem by replacing most of the links in the templates with direct links (in one case fixing a number of disambiguation errors too).

It is only an issue when there are literally hundreds of calls to this template, so will likely only occur in similar cases, where the template is used in large navigation templates. It’s possible I have fixed the worst edge cases already, but there may be others. Or more could easily be created or expanded. I don’t know if it’s worth adding a note to the documentation advising against such overuse. Even when there are less than 500 expensive function calls, having a few hundred in a template used across maybe a few hundred articles will have a performance cost.--JohnBlackburnewordsdeeds 02:41, 22 February 2018 (UTC)[reply]

@JohnBlackburne: The use of #ifexist is quite atypical for templates of this type; I think the problem could be avoided by renaming the remaining British railway station articles with the title format "Name (disambiguator) railway station" (and those without "railway") to "Name railway station (disambiguator)", per this RFC. This would allow elimination of a third to a half of the #ifexist calls. Jc86035 (talk) 07:39, 22 February 2018 (UTC)[reply]
I would certainly like to see fewer cases to check. A lot of work has already been done to make station article titles more consistent in those countries where the moves weren't opposed. Some editors strongly favour bulk use of this template, as I've had comments on my talk page after replacing an rws call which led to the wrong page by a simple wikilink.
I would also question whether linking to a title without the word station is useful, i.e. whether {{rws|Foo}} should ever link to Foo and {{rws|Foo|Bar}} should ever link to Foo (Bar). Is the intention to link to the town when no station article exists? Certes (talk) 10:25, 22 February 2018 (UTC)[reply]
Thinking on it using #ifexist seems wrong in templates like this. It’s a while since I last encountered this template, but I recall it being mostly a convenience template, to avoid having to type out the name twice and "railway station", while at the same time enforcing or encouraging some consistency in titles. In which case it would make sense for it to only work one way, for one set of inputs. When it produces a redlink the editor then has to decide what to do: fix the target title (by moving the article), create a redirect, or use a normal link, making a note in case this highlights a larger problem, such as a group of articles with inconsistent titles. Automatically finding the right article denies editors the chance to see there’s a problem and address it. It also has a high performance cost, and produces false results such as links to redirects (before this change there were a number of links to Wimbledon instead of the station)--JohnBlackburnewordsdeeds 11:47, 22 February 2018 (UTC)[reply]

List of closed railway stations in Britain: D-F and List of closed railway stations in Britain: W-Z are both now in the category for too many expensive function calls, as well as populated with dab links, the first enough to cause a bot to put it in another maintenance cat. Now I know the cause I won’t try fixing them in case the template is fixed instead.--JohnBlackburnewordsdeeds 20:18, 22 February 2018 (UTC)[reply]

It looks as if we need to revert to an earlier and simpler version of Stnlnk quickly, even if it breaks a few wikilinks. That will give us time to do the job properly. In case it's not obvious, I'm withdrawing my idea in Template:Stnlnk/sandbox. It would fix several problems, but would make this one even worse. Certes (talk) 21:56, 22 February 2018 (UTC)[reply]
I've made a revert with slight adjustment. We may need to revert further. --Redrose64 🌹 (talk) 23:18, 22 February 2018 (UTC)[reply]
From mid-October 2017 until mid-February there was virtually no problems with the template; then all hell broke loose. I think we can identify the correct rollback point. And if there's any workaround or alternative to #ifexist, then I'm all ears. Useddenim (talk) 04:18, 23 February 2018 (UTC)[reply]
The performance problems were likely there already, just not bad enough for Mediawiki enforce its limits on the number of expensive function calls. It is a misuse of #ifexist to use it in a template like this. A good use is e.g. in an infobox template, that’s used in lots of articles and which needs to check once in each whether a page exists it can use. But here it‘s not needed as the editor adding the template can see whether the target page exists, and can deal with a missing page in a variety of ways: use another template such as {{stn}} or a normal link, create a redirect, move the page if it is mistitled, investigate further if it is one of a group of mistitled pages. #ifexist is expensive, and unnecessarily using it in this template which can be transcluded hundreds of times via other templates, is a bad idea.--JohnBlackburnewordsdeeds 13:53, 23 February 2018 (UTC)[reply]
Agree with that. Also, automatically diverting a link because a page doesn't exist is not a good idea when redlinks are intentional - such as where there are two stations of the same name, but we've only created the article for one of them. --Redrose64 🌹 (talk) 16:29, 23 February 2018 (UTC)[reply]
[edit]

The recent changes to this template, probably this one by Paine Ellsworth (talk · contribs), have introduced a number of incorrect links into articles, with the result that people are going around making fixes that should not be necessary, such as these edits by Steamybrian2 (talk · contribs) and LordSavage1997 (talk · contribs). I'm suspecting that this notice is due to a similar cause. --Redrose64 🌹 (talk) 09:09, 22 February 2018 (UTC)[reply]

There is a further issue in that all those {{#ifexist:...|...}} calls are causing WP:TLIMIT problems, meaning that JohnBlackburne (talk · contribs) has had to make edits like this. I think that recent changes to stnlnk should be reverted. --Redrose64 🌹 (talk) 09:53, 22 February 2018 (UTC)[reply]

More: https://en.wikipedia.org/w/index.php?title=Clapham_Junction_railway_station&curid=272016&diff=826942664&oldid=826882060 https://en.wikipedia.org/w/index.php?title=St_Pancras_railway_station&curid=311178&diff=827005373&oldid=826873622 https://en.wikipedia.org/w/index.php?title=Template:Proposed_rail_infrastructure_projects_in_the_United_Kingdom&curid=25836275&diff=827019933&oldid=819292545

See also many of the recent contributions by Onel5969 (talk · contribs). --JohnBlackburnewordsdeeds 15:38, 22 February 2018 (UTC)[reply]
It's getting ridiculous now, as with this edit. --Redrose64 🌹 (talk) 21:50, 22 February 2018 (UTC)[reply]

To editors Certes, Redrose64, JohnBlackburne, Jc86035 and Useddenim: apologies if my edits caused unforeseen problems. I was working with a specific navbar to make it easier for editors to bypass redirects after page moves. Maybe the thing to do is to see that this template is deprecated and to replace instances of the deprecated template with direct links? The redirect bypass popup is unable to do its job when dealing with templates like {{Stnlnk}}.  Paine Ellsworth  put'r there  16:54, 26 February 2018 (UTC)[reply]

Stnlnk also confuses Dabsolver but I can see its benefits, especially for a long list of stations in a table or route diagram. Having worked in both areas, I'm on the fence as to its usefulness. Certes (talk) 17:03, 26 February 2018 (UTC)[reply]
No. If there are problems in {{Closed stations Cumbria}}, sort them out there, don't "fix" it by making changes to {{stnlnk}} that has a knock-on effect breaking hundreds of other pages. --Redrose64 🌹 (talk) 22:05, 26 February 2018 (UTC)[reply]
Done, my liege. Now, what can be done about the expensive "if exist" calls?  Paine Ellsworth  put'r there  02:22, 27 February 2018 (UTC)[reply]

Okay, my friends, I'm tired and in need of sleep, so if I've screwed up (again), then I did so in good faith and in full self-knowledge that I am far from expert when it comes to railway station articles. Having said that, I've (over?)simplified the template code in the sandbox, which would require standardization of the titles of railway station articles to Foo railway station (bar), as partly shown by results on the test cases page. Am I hallucinatin' due to lack of sleep? or is this a viable alternative? How much of a job would it be to standardize article titles this way, and how does this weigh against the elimination of the {{#ifexist: calls?  Paine Ellsworth  put'r there  09:07, 27 February 2018 (UTC)[reply]

What's the specification? I think the way forward is to define a limited number of valid formats, rewrite Stnlnk to handle them as simply as possible, and release it after making two types of change:
  1. In articles and templates whose country Wikiprojects opt out of the supported formats, replace Stnlnk and its aliases by another template or plain wikilinks
  2. In articles and templates whose country Wikiprojects opt into the supported formats or don't care, move pages to a supported format
Paine Ellsworth, thank you for your tireless efforts. That's a much clearer and more efficient implementation and I support it, as long as we can agree that the only supported formats are "Foo railway station" and "Foo railway station (Bar)".
Informing Amakuru, who is currently moving UK station articles to the "Foo railway station (Bar)" format to implement a recent RfC. Certes (talk) 10:53, 27 February 2018 (UTC)[reply]
Oh, thanks for the ping. I don't have too much to add to the above... in general, the vast majority of UK stations should end up (once I@ve finished the moving work) with a format of "Foo railway station (bar)", where bar might be a location (England, Scotland, Warwickshire etc), or it might be a line name or date range if it refers to a station in a location where there's already one of the exact same name. There will be a few exceptions left over by the end of it, for example London Road (Guildford) railway station, which is so named because the overwhelming majority of sources refer to it exactly that way. I imagine that those few exceptions could be handled without this tepmlate if necessary though, or just spelled out in full as {{stnlink|London Road (Guildford)}}. I was citing this template elsewhere yesterday, as it happens, as an example of one that does a good job of taking care of every possible format, but I hadn't factored in the issues with complex "ifelse" queries. Thanks  — Amakuru (talk) 11:35, 27 February 2018 (UTC)[reply]
The primary purpose of this template is to provide a means for linking the name of a railway station to the article for that station.
Now, some history. As originally written in 2007, it took just one parameter and simply appended the two words "railway station" to the input, and piped it:
  • {{stnlnk|Foo}} was exactly equivalent to [[Foo railway station|Foo]]
Later, it became apparent that this was unsuitable for disambiguation where the disambiguator should be part of the link, but not displayed. Accordingly, in 2012 it was amended to take an optional second parameter, which if present, would add a parenthetical disambiguator before the words "railway station":
  • {{stnlnk|Foo|Bar}} was exactly equivalent to [[Foo (Bar) railway station|Foo]]
if the second parameter was absent, the behaviour was as before. A third parameter was added in May 2017, which allowed the displayed link text to be altered:
  • {{stnlnk|Foo||Baz}} was exactly equivalent to [[Foo railway station|Baz]]
  • {{stnlnk|Foo|Bar|Baz}} was exactly equivalent to [[Foo (Bar) railway station|Baz]]
again, if the third parameter was absent, the behaviour was as before. So far, so good: backward compatibility is maintained, the template does not attempt to second-guess the editor, and intentional redlinks are left red. In particular, the words "railway station" are constant throughout, being present in all generated links as the last two tokens of the linked page. This all changed in October/November 2017 when the template started to use the {{#ifexist:...|...|...}} construct, at first with three instances, later with five. The behaviour of the first and third parameters was unchanged, but now the second, if present, was tried out in various positions and forms until a valid link was found - if absent, the behaviour was again as before. These trials were
  • Foo (Bar) railway station
  • Foo (Bar station)
  • Foo station (Bar)
  • Foo (Bar)
  • Foo railway station (Bar)
Notice that three of them lack the word "railway", and one even lacks the word "station", thus giving the potential for a link to an article about a place name and not the intended station. Whichever one of these five succeeded first was the link that was used. If all five failed, the link was to either [[Foo railway station, Bar|Foo]] or [[Foo railway station, Bar|Baz]] depending upon the absence or presence of the third parameter. We now had the situation that the resultant link was not predictable - if the editor worked out where it would go at the time that they used the template, the subsequent creation of a redirect could change things, not necessarily for the better. Further changes in February 2018 made it still less predictable.
What do we want? A means of linking to a station article given the minimum input that is necessary for an exact predictable match. --Redrose64 🌹 (talk) 12:03, 27 February 2018 (UTC)[reply]
I would just add that the Autumn 2017 changes were made the create a “one size fits most” template to accommodate the station (re)naming rationalisation that was occurring, and to reduce the need for single-country and system-specific templates that seemed to be proliferating. The checking order follows a Pareto distribution to be as efficient as possible. (A side question: are all the {{#ifexist:}} calls evaluated, or just as many as necessary to achieve a positive result?) Useddenim (talk) 04:01, 28 February 2018 (UTC)[reply]
Let's test it: Example exists. --Redrose64 🌹 (talk) 10:12, 28 February 2018 (UTC)[reply]
Special:WhatLinksHere/Some-made-up-page-name comes back empty, so it's outside-inward. But we must still be aware of mw:Help:Extension:ParserFunctions#ifexist limits. --Redrose64 🌹 (talk) 10:17, 28 February 2018 (UTC)[reply]
But see mw:Help:Templates#Order of evaluation. --Redrose64 🌹 (talk) 10:27, 28 February 2018 (UTC)[reply]

A proposal

[edit]

Many station articles have recently moved or are likely to move soon. In the light of those title changes, and the comments above, what should this template do? Can we pare it down to a simple, efficient design with a well understood specification?

Most countries seem to agree on the "Foo railway station" and "Foo railway station (Bar)" formats. Supporting them is obviously the main priority.

A substantial minority of countries have opted for "Foo station" and "Foo station (Bar)" instead, especially where mainline and metro stations coincide. They need support too, though not necessarily within this template.

There are many country-specific variants, mainly "Foo XYZ station" (XYZ being the local transport organisation) and "Foo Station"/"Foo Station (Bar)" (Japan is particularly fond of the capital S).

A very few stations are called "Foo (Bar)" or simply "Foo". I had to look hard to find examples such as Akazienweg (KVB) and Britomart Transport Centre.

As pointed out above, we still have many pages called "Foo (Bar) railway station", "Foo railway station, Bar", "Foo (Bar) station" or "Foo station, Bar". These titles depart from subsequently agreed conventions, so I think they can safely be moved (leaving a redirect) without upsetting anyone.

Here's a suggestion. I'm expecting plenty of valid criticism but I hope we can modify it into a working plan.

  • Clean up "Foo (Bar) railway station" and "Foo railway station, Bar" titles (and similar without "railway") by page moves or creating redirects.
  • Replace the few useful links to "Foo" by {{Stnlnk|Foo|link=Foo}} or simply [[Foo]]; similarly for "Foo (Bar)".
  • Create a new template for "Foo station" and "Foo station (Bar)", possibly reusing a title which currently redirects to Stnlnk. Either add a link= parameter for the few stations whose titles legitimately vary from the norm, or simply avoid using the template in those cases.
  • Limit Stnlnk to its original purpose of linking to "Foo railway station" and "Foo railway station (Bar)". (Just copy the new template and add "railway".)
  • Stnlnk does not currently handle the country-specific variants. They can continue to do whatever they currently do, with another template or plain wikilinks.

Courtesy pings: Useddenim, who added much of the current functionality in late 2017, and Dicklyon, who has orchestrated station page moves. Certes (talk) 16:20, 22 February 2018 (UTC)[reply]

@Certes: I think the template should leave "station" links to {{stn}} (since this is usually used as {{rws}}); I generally agree with your points. Jc86035 (talk) 17:55, 22 February 2018 (UTC)[reply]
@Jc86035: I agree about using stn. We could even make rws the main template for "railway station", assuming that everything calling it wants that format, then review uses of Stnlnk and its other aliases more carefully. Here's a count of articles using each alias. (Some use multiple templates; many use the same template many times.)
{{Cn-stalink}} 0000
{{Rly stn}} 0010
{{RWS}} 0066
{{Rws}} 7032
{{Sta}} 0000
{{Stnlink}} 0495
{{Stnlnk}} 4671
{{Sttnlnk}} 0001
On the same basis, {{Station}} ("Foo station") has 262 uses plus 1129 for its alias stn. {{STN}} ("Foo Station") is a suprise winner with 9986, plus 15 for its aliases. Certes (talk) 19:29, 22 February 2018 (UTC)[reply]
While the template is being reworked, do we want to add the two-line function of (the related) {{BSsrws}}? Useddenim (talk) 21:41, 22 February 2018 (UTC)[reply]
Short-term (by which I mean immediately), can we at least get rid of the situation where {{stnlnk|Eastgate}} is (i) a long-winded way of writing [[Eastgate]] and (ii) not the correct link, which should be equivalent to [[Eastgate railway station|Eastgate]]. --Redrose64 🌹 (talk) 21:55, 22 February 2018 (UTC)[reply]
Just as an extra comment on this - I've noticed that the format for Australian stations consistently uses the comma format at the moment. See Category:Railway stations in Melbourne for example. I'd support the idea of moving all those from Foo railway station, bar to Foo railway station (bar), but we'd probably have to formalise that as a move request or RfC on the project page first, before just going ahead with it, since it might prove controversial. As an aside, there's also a longer term debate going on surrounding disambiguation for fixed structures, buildings, statues etc. Currently the unwritten convention is to use commas for location disambiguators in Commonwealth structures and parentheses for those in the US, (see Category:Statues in London and Category:Statues in New York (state) for comparison). It's possible the station naming in Australia may be following that. Personally I've long been in favour of moving everything over to parentheses for clarity, but again, that's highly controversial! Thanks  — Amakuru (talk) 11:48, 27 February 2018 (UTC)[reply]

When not to use

[edit]

I've just changed an article which used this template in a paragraph where I think it was unhelpful:

from: {{rws|Eaglescliffe}} railway station is staffed. - appearing as: Eaglescliffe railway station is staffed.
to: [[Eaglescliffe railway station]] is staffed. - appearing as: Eaglescliffe railway station is staffed.

Because the latter makes it clearer to the reader that the link is to a station, not just to an article about the town.

Could there please be a guidance note added to the template documentation to advise against the use of this link in text where it is not immediately obvious that the railway station is being discussed? Thanks. PamD 14:53, 26 August 2021 (UTC)[reply]