Jump to content

Template talk:Jct/Archive/2016

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Disambiguation of routes

On A1 motorway (Netherlands), there is a link to S114, which I would like to change to [[S114 (Amsterdam)|S114]]. The current jct template is:

{{Jct|country=NLD|S|114|dir1=southeast|road|Weteringweg}} which produces: S 114 southeast / Weteringweg

I can't tell from the documentation or the LUA code what parameter I need to add to modify the link. Can anyone help? -Niceguyedc Go Huskies! 02:07, 3 July 2015 (UTC)

@TheWombatGuru: are there any S-routes that would not need disambiguation like this? –Fredddie™ 02:19, 3 July 2015 (UTC)
Looking at the category, I answered my own question. It should be updated now, Niceguyedc. –Fredddie™ 02:22, 3 July 2015 (UTC)
Excellent. Thanks! -Niceguyedc Go Huskies! 02:27, 3 July 2015 (UTC)
No, at the moment there are only pages on Amsterdam's city routes. TheWombatGuru (talk) 16:06, 3 July 2015 (UTC)

I assume some are not in Amsterdam? This is what the dab1=* parameter is for. See Module:Road data/strings/USA/MN: link = "Minnesota State Highway %route% [dab|| (%dab%)|]", --NE2 16:31, 3 July 2015 (UTC)

Yes, there are others in The Hague, Rotterdam, Zaandam and Nijmegen if I remember correctly. TheWombatGuru (talk) 16:34, 3 July 2015 (UTC)
I suppose this is  Fixed. -happy5214 10:27, 6 February 2016 (UTC)

Error checking

I don't know how easily it could be implemented, but we should implement some sort of error checking to check for duplicate parameters. Ideally, it would output something like Error: Duplicate parameters detected. at the end of the output and add an entry to Category:Jct template errors. –Fredddie™ 22:06, 1 March 2016 (UTC)

I don't think the template itself can know if it was passed duplicate parameter, i.e. {{jct |state=TN |state=NT}}. What definitely could be checked is if there is both a parameter and an alias for the parameter, ie. {{jct |state=TN |province=NT}}. If you are looking to filter Category:Pages using duplicate arguments in template calls to just show road-related pages, WP:Catscan can show the intersection between categories and/or templates:
- Evad37 [talk] 01:36, 2 March 2016 (UTC)

Substing {{jct}}

AFAICT, this is an issue with Scribunto, and ergo not within my ability to fix. -happy5214 06:13, 10 March 2016 (UTC)

Glitch with banners

Recently some changes were made to the template and now banners for special routes (alternate, business, truck, toll, etc.) are not showing up. Is there a way this can be fixed? Dough4872 02:42, 19 May 2016 (UTC)

Module:Road data/parser/sandbox has a fix that discards the second return value that was erroneously assigned as the second shield (long term), or one could remove second variable assignment in line 60 of Module:Jct (short term). @Happy5214: Chinissai (talk) 10:05, 19 May 2016 (UTC)
Thanks for the fix! Dough4872 14:44, 19 May 2016 (UTC)
@Chinissai: Deleting the second assignment entirely would break the dual shield capability in {{jct}} for the period of time before the new parser is deployed. In the interim, I added a check to discard non-string values for second. Your latest change to the sandbox should make that change moot. In any event, your "short-term" fix only matters, if I'm understanding correctly, once the sandbox parser, now with the "long-term" fix, is deployed, in which case the second value will be exploded out of the returned table. The other issue mentioned, the original post subject in fact, was the missing banners. Doesn't your patch to the sandbox correct that? Or is the issue that multiple values for banner forms are causing tables to be returned? -happy5214 22:08, 19 May 2016 (UTC)
If the current parser sandbox is deployed, the short-term fix has no effect. The change you made earlier that checks if the first result is a table and unpack to second works as expected, but the troublesome parser erroneously returns the second result from gsub (number of matches). It eventually is treated as a filename, setting the shield error, and hence disabling all banner from being displayed. The real troublesome behavior was exhibited with routelist row. So, fixing the parser will solve the problem once and for all. Chinissai (talk) 23:04, 19 May 2016 (UTC)
@Happy5214: second in line 60 was always assigned the number of matches, so if there is no dual shield, that value remains. Your latest fix would prevent that value from being used as a filename, but routelist row would still break if the troublesome parser is used again. Chinissai (talk) 23:25, 19 May 2016 (UTC)
@Chinissai: second does get an actual value from the current parser. I think the issue arose when you decided to use a tail call for the second gsub call. In any case, I copied the fixes I made to jct to routelist row. Please review. -happy5214 00:17, 20 May 2016 (UTC)
Exactly. Routelist row looks fine to me for use with the fixed parser sandbox. Chinissai (talk) 00:29, 20 May 2016 (UTC)
 Question: Have you already fixed the issue in the parser sandbox? -happy5214 00:19, 20 May 2016 (UTC)
That's what the long-term fix is above. Chinissai (talk) 00:29, 20 May 2016 (UTC)

Just a quick comment. List of U.S. Highways in Michigan has been renominated at WP:FLC. It didn't receive a lot of commentary the first time around, and I'm hoping that it receives more this time so that it can be promoted. Having said that, while you're working on module updates, can you just double check that the list isn't broken? I don't want to stop all development of updated coding, but if a change breaks the list again, I'll summarily revert again so that reviewers aren't opposing the nomination over a temporary coding issue. Imzadi 1979 → 01:26, 20 May 2016 (UTC)

I can't seem to get the "nolink" parameter to work. I'm compiling a list of minor numbered roads in Prince Edward Island (List of Prince Edward Island provincial highways) of which very few are significant enough to expect a separate article. Eventually I plan to point redirects back to anchors in this list to enable a number of links that other editors have created. At that point the links in the table will be circular redirects, and so I had intended to only link roads which already have articles. But "nolink" doesnt' seem to be working for me.

I'm using code like {{jct|state=PE|PE|130|nolink=1}} (I've tried nolink, nolink=yes, and different order of arguments) but I get linked text no matter what. Am I doing it wrong or is there an error in the code? It's a bit too complicated for me to troubleshoot. Ivanvector (Talk/Edits) 19:13, 11 November 2016 (UTC)

The parameter name should include the number of the route within the template syntax that you don't want linked. The parameter takes any non-empty value. For example:
  • Your code above: {{jct|state=PE|PE|130|nolink=1}} produces Route 130
  • Corrected code: {{jct|state=PE|PE|130|nolink1=y}} produces Route 130
-- LJ ↗ 19:45, 11 November 2016 (UTC)
Aha! Thanks. The documentation makes it seem as though "nolink" is a valid parameter on its own, and indeed "noshield" does work without a numeral. Ivanvector (Talk/Edits) 21:09, 11 November 2016 (UTC)

Inheritance and overriding in road data modules

There are no existing module talk pages to host this discussion, so I am posting it here. Feel free to move this to a new, appropriate talk page.

I am trying out inheritance for road data modules. This means entries to be shared across multiple modules should be defined in one place. Inheriting modules have an opportunity to override values as appropriate. The rest of this post gives a tutorial of how this is done.

I have updated Module:Road data/strings/USA to act as a shared module. There is not much difference from a previous version except for additional entries that can be shared in state modules. Modules to be inherited like this one won't look that interesting.

The interesting part comes in the inheriting modules. I have updated Module:Road data/strings/USA/RI to use this pattern. I chose this module because it is small yet large enough to illustrate features. The updated module is backward compatible, except for the missing "width" key that will not be needed for the new banner display mechanism. The implication is that banner placement will be a little off in the old display mechanism; otherwise, no harm done.

The first difference is the declaration of the table to be returned. Formerly, we started with the empty table: 

local RI = {}

Instead, we import the inherited module: 

local RI = require("Module:Road data/strings/USA")

Having done this, all entries defined in the inherited module become available immediately. We need only override entries that differ from the inherited module. For example, the link for an interstate in Rhode Island should point to the state-specific article instead of the national article. Formerly, we had to define the whole entry: 

RI.I = {shield = "I-%route%.svg",
        link = "Interstate %route% (Rhode Island)",
        abbr = "I‑%route%"}

Instead, we can simply override the link field: 

RI.I.link = RI.I.base .. " (Rhode Island)" -- Use the inherited RI.I.base.

Note that we cannot write RI.I = {link = ...}, or we would be overriding the entire I table and not inheriting entries therein. Of course, if the entire table is not to be inherited, this method is appropriate.

Certain route types are shared regionally and should not be defined in the main inherited module. Still, we can "mixin" these route types. For example, New England routes are to be shared among New England states, and not others. First, we create a separate module Module:Road data/strings/USA/regional/NER that looks like one to be inherited: 

-- New England
local NER = {}

NER.NER = {
	shield = "New England %route%.svg",
	name = "New England Route %route%",
	link = "Route %route% (New England)",
	abbr = "Route %route%"
}

return NER

Then, to mixin route types defined in such modules, we simply append the existing entries: 

local util = require("Module:Road data/util")
-- Add entries in second table to first.  require here returns NER table above.
util.addAll(RI, require("Module:Road data/strings/USA/regional/NER"))

(Note that this is currently disabled in the actual module, because USA defines NER. This can be resolved after we figure out what to do within New England Interstate Route 26, perhaps by changing {{jct|country=USA|NER}} to {{jct|state=XX|NER}}.)

An obvious advantage of this approach is that we write less. The Rhode Island module is about 400 bytes (33%) less. Another advantage is that changes in the shared module propagate automatically to inheriting modules, unless they override the fields that change.

This approach comes with an issue. Unwanted route types might show up in the inheriting module. For instance, a state might not have US-Spur, but this type will be available because USA defines it. I don't believe this is undesirable. Truly unwanted route types should be defined in a mixin module, so we have a way around this.

Another issue is that overridden fields are not propagated to the inherited entries that use those fields. For example, if the inheriting module overrides RI.US.name, then any place that uses USA.US.name will remain as is unless overridden. I think redundant overriding is the only option, but it does not seem too much a burden in the modules I have converted so far.

Also, it is now more obscure of what are defined, and what their actual values are. To help with this, I created a few scripts to dump the content of a table. To inspect the value of a road data module, use Special:ExpandTemplates with the following input text: 

{{#invoke:Road data/dump|dump|module=Module:Road data/strings/USA/RI}}

Replace |module= with the module in question.

When editing a road data module, simply paste the following script into the debug console: 

local util = require("Module:Road data/util")
print(util.arrayToString(p))

I have most of the US-state modules ready to go (without width fields), but I don't want to pollute Wikipedia with them yet. Let me know if you are interested to see the new modules for other states.

Thoughts welcome. Chinissai (talk) 15:23, 30 April 2016 (UTC)

I don't know if I like this. It seems to me that this unnecessarily complicates the road data modules, which I suppose is the exact opposite of your intentions. I know some states' modules have been edited such that an Interstate or U.S. Highway will never link to a redirect, so those states will never use this setup. And if I understand it right (I might not) states like Arkansas that use suffixes instead of banners wouldn't be able to use this? –Fredddie™ 22:05, 30 April 2016 (UTC)
I can say with confidence that modules will be more compact with inheritance, as you need not redefine the same thing over and over again. It is easier to maintain. To address your concern, let's look at the override for Michigan interstates:
MI.I.link = {
	["96"] = "Interstate 96",
	["196"] = "Interstate 196",
	["296"] = "Interstate 296",
	["496"] = "Interstate 496",
	["696"] = "Interstate 696",
	["94N"] = "Interstate 94N",
	default = {
		hook = "split",
		split = 100,
		above = MI.I.base .. " (Michigan)",
		below = MI.I.base .. " in Michigan"
	}
}

It looks pretty much the same as before, but you don't need to redefine abbreviation and shield, which are already defined in USA.

For Arkansas, the entire US-Bus type is redefined like you mentioned, so we can simply fall back to the current method: 

local suffix = " ([dab||%dab%, |]Arkansas)"

-- override some entries for inherited AR.US
AR.US.shield = "US %route% (AR).svg"
AR.US.name = "U.S. Highway %route%"
AR.US.link = AR.US.base .. " [dab||(%dab%, Arkansas)|in Arkansas]"

-- override US-Bus entirely and forget what's inherited
AR["US-Bus"] = {
	shield = "US %route%B.svg",
	name = AR.US.name .. "B",
	link = AR.US.base .. "B" .. suffix,
	abbr = AR.US.abbr .. "B"
}

Still, inheritance takes advantage of AR.US.base and AR.US.abbr, which are already defined in USA.

One thing to keep in mind is that a child module can always elect not to inherit at all, which simply results in what we have now. The best use comes with overriding, like with MI interstate links above. Chinissai (talk) 01:06, 1 May 2016 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Jct/Archive/2016&oldid=1138531376"