Yeah, time to mess up the template for Texas routes again...

First, Putting in the Toll|49 designation links to State Highway 49, and instead should point to State Loop 49. Toll Loop 1 already is coded the way it should work, so could 49 be coded the same? Or should Toll Loops be separated out in (yet another) Texas grouping, like Toll-Loop|49?

Second, a minor issue with the Toll signs displayed for Texas in the jct template. They all display the white background with the blue numbering. But, AFAIK, all the toll routes use the blue background with white signage. Could these be switched over?

Thanks, 25or6to4 (talk) 22:04, 12 March 2013 (UTC)

 Done and  Done. –Fredddie™ 22:22, 12 March 2013 (UTC)

Thanks again! 25or6to4 (talk) 20:28, 20 March 2013 (UTC)

To whom it may modify this template,

Some, if not all the links to the Italian motorway pages are incorrect, e.g., on the infobox in this article, Süd Autobahn, is present a link to the Italian A23 which is incorrectly spelled. Someone can verify and correct this issue? ElSaxo (talk) 14:25, 2 April 2013 (UTC)

I've fixed it. -- WOSlinker (talk) 15:05, 2 April 2013 (UTC)

Thank you! ElSaxo (talk) 15:42, 2 April 2013 (UTC)

There are Mexican state highways. Could you post on this page Mexican State Highways? QM400032 (talk) 21:12, 15 May 2013 (UTC) — Preceding unsigned comment added by QM400032 (talk • contribs)

What exactly are you asking? That question is worded a bit weirdly. TCN7JM 21:15, 15 May 2013 (UTC)

I'm talking about State highways in Mexico (Example: {{jct|country=MEX|state=NLE|NLE|1}} becomes SH 1) QM400032 (talk) 21:56, 15 May 2013 (UTC)

Odd. That's some sort of bug that instead shows "none". QM400032 (talk) 21:59, 15 May 2013 (UTC)

I didn't think Mexican state abbreviations were part of the code, but I didn't design the template, so I'm not the one to ask. TCN7JM 22:21, 15 May 2013 (UTC)

That's not a bug, you just need to fill it out as follows: {{jct|state=NLE|SH|1}}, which produces SH 1. —Scott5114↗ [EXACT CHANGE ONLY] 22:25, 15 May 2013 (UTC)

We need to come up with a better way to display shields with banners above them than just placing the banner, a carriage return, and a shield on the next line. This doesn't work well with centered text (see Chickasaw Turnpike#Exit list). The existing method leaves a sorta ugly gap between the banner and the shield, too. Could we try something like putting the shield/banner pair in a <div> to see if that makes things better? —Scott5114↗ [EXACT CHANGE ONLY] 06:15, 27 April 2013 (UTC)

Getting the template to put the current contents between <div style="line-height:1;"> and </div> will fix the gap, but means that any text after the {{jct}} template will be pushed to the next line:

Using <div style="line-height:1">{{jct| ... }}</div> as a mockup results in

SH-7 Spur

continues west

If extra text such as "continues west" could be entered via a template paramter, then you could have

SH-7 Spur continues west

But this wouldn't fix the centre-aligned problem:

SH-7 Spur continues west

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

(unless its okay for the text to always be left-aligned, which could be specified in the <div>) - Evad37 (talk) 03:33, 10 May 2013 (UTC)

I think jct is using a line break after the banner to create the second line. We need to use coordinates instead. Something like this: " continues west". Unfortunately I can't yet find a solution that keeps the whole shebang inline with the text (it either overlaps with the text like that or else wants to be at the top left of the page content area). —Scott5114↗ [EXACT CHANGE ONLY] 04:32, 10 May 2013 (UTC)

I think the double span and coords only need to apply to the banner: " SH-7 continues west" filler text: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.. Though this overlaps the text above: " SH-7 continues west" - Evad37 (talk) 05:07, 10 May 2013 (UTC)

Would modifying the line height whenever there is a banner fix that? I did that to the example; it worked, but there is whitespace below the shield and text now. –Fredddie™ 05:15, 10 May 2013 (UTC)

All exits are unnumbered.

County	Location	mi[1]	km	Destinations	Notes
Murray	​	0.0	0.0	SH-7 continues west
	​	0.0	0.0	US 177 – Sulphur	Current Western terminus, Eastern terminus of SH 7 spur
	​	2.8	4.5	Toll plaza
Pontotoc	​	8.2	13.2	Dolberg Road – Roff	Eastbound exit and westbound entrance
	​	13.3	21.4	SH-1 – Ada, Mill Creek	Eastern terminus
1.000 mi = 1.609 km; 1.000 km = 0.621 mi

(edit conflict)An empty div with height:9px fixes this:

SH-7 continues west - shields would always be at the beginning of a line anyway - Evad37 (talk) 05:17, 10 May 2013 (UTC)

Excellent. Now we just need to make sure that it will handle 25px-wide shields too, and we're good to go. —Scott5114↗ [EXACT CHANGE ONLY] 05:26, 10 May 2013 (UTC)

For shields wider than 20px, the coord for left: needs to be (width - 20)/2: U.S. 271 Bus. - otherwise the plate isn't center-aligned: U.S. 271 Bus. - Evad37 (talk) 06:06, 10 May 2013 (UTC)

Will these updates work in cases where the banner plate is above the second marker? Case in point, BL I-94/BUS US 131 in Kalamazoo, Michigan?

BL I-94 / Bus. US 131. Imzadi 1979 → 00:00, 11 May 2013 (UTC)

Yes, see below

BL I-94 / BUS US 131 - Evad37 (talk) 00:09, 11 May 2013 (UTC)

However, {{jct}} (and its various subtemplates) may require a substantial rewrite. From what I can tell, it currently puts in all the banners or empty spaces as required, then a linebreak, then the shields as normal. This new method needs the banner, within the double <span>s, to placed immediately prior to the shield it sits above. Plus there needs to be that empty <div> at the start - Evad37 (talk) 02:27, 11 May 2013 (UTC)

We've known Jct has needed a rewrite for years, but this at least gives us something to work with. I was thinking that this could allow us to add direction banners as well. We've never been able to successfully add them because of how the template is currently set up. –Fredddie™ 12:22, 11 May 2013 (UTC)

Is there a way we can add just a tiny bit of space back between the shield and banner? On my end, the US 271 Bus example looks like the banner is hanging over the US 271 shield. I think positioning it -17px instead of -16px would fix it.

U.S. 271 Bus. –Fredddie™ 13:21, 15 May 2013 (UTC)

It seems to depend on the browser. Chrome (v26/Win7), which is what in use most of the time, as well as Safari (iPhone), are placing the banner 1 pixel higher than Firefox (v21/Win7) and IE (10/Win7). Is having a 1px gap for Chrome and Safari users preferable to a 1px overhang for Firefox and IE users? - Evad37 (talk) 14:01, 15 May 2013 (UTC)

Hrm. I use Chrome (v26/OSX) and I don't get the gap. However, my Android phone does show a gap. I added a third one above with -16.5px spacing. Let's see how that looks. –Fredddie™ 14:19, 15 May 2013 (UTC)

Identical to the -16px version. –Fredddie™ 14:21, 15 May 2013 (UTC)

My results:

• Firefox: -16.5px == -17px (no overlap)
• IE: -16.5px == -16px (1px overlap)
• Safari: -16.5px == -16px (no gap)
• Chrome: ... is doing weird things. In Read mode, -16.5px == -17px (1px gap), whereas in Edit mode's preview, -16.5px == -16px (no gap) - Evad37 (talk) 15:01, 15 May 2013 (UTC)

Here on Linux:

Firefox 20: In Read mode -17px has gap, -16.5px == -16px with no gap. In Edit Preview mode, -17px == -16.5px with no gap, and -16px has overlap.

Chromium 25: In Read mode and Edit Preview mode -17px == -16.5px with gap, -16px no gap.

Hope that helps. -happy5214 09:05, 17 May 2013 (UTC)

Appearance based on browsers and OS

System	Browser	Positioning
		-16px	-16.5px	-17px
Win7	Chrome 26	OK	gap*	gap
	Firefox 21	overlap	OK	OK
	IE10	overlap	overlap	OK
iPhone	Safari	OK	OK	gap
OSX	Chrome 26	overlap	overlap	OK
Linux	Firefox 20	OK	OK	gap
	Chromium 25	OK	gap	gap

* OK in edit mode

It has become apparent that a major, or possibly complete, rewrite of this template is desired by the community. I have started this thread to gauge the community's wishes as it pertains to new and improved features. As the likely main writer and maintainer of the new template, I would like to use this opportunity to evaluate what is needed in the new template. This is an open discussion, and all viewpoints are welcome.

Thank you. -happy5214 07:31, 14 May 2013 (UTC)

It's overdue for a rewrite - there were plans to do it in 2010 with IBR, but they never went through. --Rschen7754 07:34, 14 May 2013 (UTC)

I think that if it can basically do everything current jct does, plus fix the display issues as shown above, it will work well. jct is versatile enough that I can't think of any features that it lacks, save for it being nice if we could raise the max junction limit to something like 10 (huge intersections with 6+ routes, often involving banners, are where this template is needed most, in my opinion). —Scott5114↗ [EXACT CHANGE ONLY] 07:46, 14 May 2013 (UTC)

Other than raising the junction limit from 4 to something higher like 10, I can't really think of much to change output wise. Now, it would be nice if the was a way to add the TO plates, maybe directional plates as well. Mostly I think it would be a matter of just overhauling the back end rather than changing the final output. Imzadi 1979 → 07:56, 14 May 2013 (UTC)

Yes! Yes! A thousand times yes! I think we need to start over and make something that doesn't require a degree in cryptography to edit. I think part of the reason it was never updated in 2010 was because of the size of the backend. Back then, IBR's backend wasn't nearly as developed as it is now, whereas Jct's backend is perplexing to even the best template maintainer. As for parameters we could add, I originally proposed |via#= in 2009. I am not necessarily against adding directional and to banners, but I'd have to see it in action. –Fredddie™ 01:29, 15 May 2013 (UTC)

+1  on making the code more easily decipherable. A set of technical notes explaining how the template and its sub-templates (or Lua modules) work would also be a good idea, so that it will easier to maintain and update in the future. - Evad37 (talk) 01:39, 15 May 2013 (UTC)

Another issue is lack of good documentation on how to edit the output (i.e. how to do things like change a link, change a shield, etc.) A good starting point would be to migrate these strings to a Lua table that would serve as a poor man's database that can be easily read and edited by anyone (since it would be just the strings, and we could include explanatory comments in a header). That way we can keep all the data, which needs to be edited somewhat frequently, separate from the template's brains, which won't need to be as often. As for adding new features, I think that's putting the cart before the horse; let's focus on doing a one-to-one rewrite now, because I don't think any of us wants this rewrite effort to get mired into a RJL debate, and I don't think any of us wants to waste our coders' time on something that might get shot down at RJL. With a clean codebase it will be easier to implement new features anyway. —Scott5114↗ [EXACT CHANGE ONLY] 08:07, 15 May 2013 (UTC)

Links are already available in Modules. As are Abbrevs, so just the shields to do and the main template. -- WOSlinker (talk) 12:30, 15 May 2013 (UTC)

Er, not that simple. I'd have to substantially rewrite those modules anyway (new syntax, merged code, etc.), so I wouldn't just jump in quite yet. -happy5214 08:58, 17 May 2013 (UTC)

Can someone help add provinces for the Peoples Republic of China so that that can be used in the state= parameter? The template is being increasingly used in Chinese road transport articles, and many provinces are building quite significant/large provincial expressway/highway network. Currently, provinces are distinguished in the type parameter, with each province's expressways a unique "type" essentially by province. This is probably not the best way to go about this, as each province in China has differing classes of roads (numbered provincial-level and county-level), which creates a problem.

The best codes to use would probably be the Guobiao or GB abbreviations as shown in the article Chinese provinces#List of provincial-level divisions. Despite its use not as widespread in China as the "abbreviation" or symbol of each province shown on license plates, the abbreviations don't work because in pinyin, without tone numbers, multiple provinces have the same abbreviation (e.g. Ji for Hebei and Jilin). I know that GB codes like SC for Sichuan might conflict with South Carolina, but hopefully there is a way to have one state code take precedence without a country tag (e.g. state=SC is South Carolina with nothing, state=SC is Sichuan with country=CHN). Thanks, Heights^{(Want to talk?)} 21:05, 18 May 2013 (UTC)

I don't think there's any barrier stopping us from doing this. You would have to specify |country=CHN and |state=, though. If you're interested, {{Jct/meta/mask/country}} exists, which would allow you to skip the country parameter. However, the provinces that overlap with US states would require the country parameter. –Fredddie™ 21:25, 18 May 2013 (UTC)

Alright, I was just wondering how I would go about doing this. Would it just be adding the appropriate codes and province names to {{Jct/statename}} or are there other steps involved? The skipping the country=CHN parameter would also be a good next step, but not essential I guess. Heights^{(Want to talk?)} 23:38, 18 May 2013 (UTC)

Heh, I didn't even know about that template. Anyway, here is what I have for the mask template:

{{#if:{{{2|}}}|{{uc:{{{2}}}}}|{{#switch:{{{1|}}}
|AL|AK|AZ|AR|CA|CO|CT|DE|FL|GA|HI|ID|IL|IN|IA|KS|KY|LA|ME|MD|MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ|NM|NY|NC|ND|OH|OK|OR|PA|RI|SC|SD|TN|TX|UT|VA|VT|WA|WV|WI|WY|DC|AS|GU|MP|PR|UM|VI=USA
|AB|BC|MB|NB|NL|NS|NT|NU|ON|PE|QC|SK|YT=CAN
|AH|BJ|CQ|FJ|GD|GS|GX|GZ|HA|HB|HE|HK|HL|JL|JS|JX|LN|MC|NX|QH|SN|SX|TJ|TW|XJ|XZ|YN|ZJ=CHN
|AGU|BCN|BCS|CAM|CHP|CHH|COA|COL|DIF|DUR|GUA|GRO|HID|JAL|MEX|MIC|MOR|NAY|NLE|OAX|PUE|QUE|ROO|SLP|SIN|SON|TAB|TAM|TLA|VER|YUC|ZAC=MEX
|#default=UNK
}}}}

I did not include the few that overlapped US states already there. I also specifically excluded Shanghai (SH) simply because SH is used so many times in the US as a type that I don't want someone to get them mixed up. I know I've erred and used {{Jct|state=SH|1}}. –Fredddie™ 23:55, 18 May 2013 (UTC)

Hey, that looks great. The exclusion of Shanghai (SH) is not a problem. Heights^{(Want to talk?)} 00:16, 19 May 2013 (UTC)

This will fix an issue with some California DABs on List of divided U.S. Routes. –Fredddie™ 16:54, 29 May 2013 (UTC)

From:

|US|US 1926|US 1948|US 1961=U.S. Route {{{route}}}{{#if:{{{state|}}}| in {{#if:{{{dab|}}}|{{{dab}}}, |}}{{StateName|{{{state}}}}}}}

To:

|US|US 1926|US 1948|US 1961={{#switch:{{{state}}}
|CA={{#switch:{{{dab|}}}
 |Northern California|Central California|Southern California=U.S. Route {{{route}}} in {{{dab}}}
 |#default=U.S. Route {{{route}}}{{#if:{{{state|}}}| in {{#if:{{{dab|}}}|{{{dab}}}, |}}{{StateName|{{{state}}}}}}}
 }}
|#default=U.S. Route {{{route}}}{{#if:{{{state|}}}| in {{#if:{{{dab|}}}|{{{dab}}}, |}}{{StateName|{{{state}}}}}}}
}}

The above has some redundancies. How about:

|US|US 1926|US 1948|US 1961={{#switch:{{{state}}}
|CA={{#switch:{{{dab|}}}
 |Northern California|Central California|Southern California=U.S. Route {{{route}}} in {{{dab}}}
 |#default=U.S. Route {{{route}}} in {{#if:{{{dab|}}}|{{{dab}}}, |}}California
 }}
|#default=U.S. Route {{{route}}}{{#if:{{{state|}}}| in {{#if:{{{dab|}}}|{{{dab}}}, |}}{{StateName|{{{state}}}}}}}
}}

California is a given based on the switch statement. Ah, it'll all be in Lua eventually. I just don't have the time right now. -happy5214 06:44, 30 May 2013 (UTC)

Will any of this help show the shields on all of the other entries (non-California) on the divided routes page? I would like to see the shields on there, but called by this template. Allen (Morriswa) (talk) 11:47, 30 May 2013 (UTC)

No, because this is the link subtemplate. The shields don't show up because they don't exist. –Fredddie™ 12:01, 30 May 2013 (UTC)

• Done. Thanks for your work. — Mr. Stradivarius ^{♪ talk ♪} 03:55, 1 June 2013 (UTC)

This edit request is to add the provinces and provincial-level administrations of the People's Republic of China to the template, so that the parameter |state= can be used without |country=CHN where no overlap occurs with another country. The codes used are the GB codes shown on the Provinces of the People's Republic of China article. (For prior discussion, please refer to a section above).

Edit request from:

{{#if:{{{2|}}}|{{uc:{{{2}}}}}|{{#switch:{{{1|}}}
|CA|TX|NY|FL|IL|PA|OH|MI|GA|NC|NJ|VA|WA|AL|AK|AZ|AR|CO|CT|DE|HI|ID|IN|IA|KS|KY|LA|ME|MD|MA|MN|MS|MO|MT|NE|NV|NH|NM|ND|OK|OR|RI|SC|SD|TN|UT|VT|WV|WI|WY|DC|AS|GU|MP|PR|UM|VI=USA
|AB|BC|MB|NB|NL|NS|NT|NU|ON|PE|QC|SK|YT=CAN
|AGU|BCN|BCS|CAM|CHP|CHH|COA|COL|DIF|DUR|GUA|GRO|HID|JAL|MEX|MIC|MOR|NAY|NLE|OAX|PUE|QUE|ROO|SLP|SIN|SON|TAB|TAM|TLA|VER|YUC|ZAC=MEX
|#default=UNK
}}}}

to

{{#if:{{{2|}}}|{{uc:{{{2}}}}}|{{#switch:{{{1|}}}
|AL|AK|AZ|AR|CA|CO|CT|DE|FL|GA|HI|ID|IL|IN|IA|KS|KY|LA|ME|MD|MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ|NM|NY|NC|ND|OH|OK|OR|PA|RI|SC|SD|TN|TX|UT|VA|VT|WA|WV|WI|WY|DC|AS|GU|MP|PR|UM|VI=USA
|AB|BC|MB|NB|NL|NS|NT|NU|ON|PE|QC|SK|YT=CAN
|AH|BJ|CQ|FJ|GD|GS|GX|GZ|HA|HB|HE|HK|HL|JL|JS|JX|LN|MC|NX|QH|SN|SX|TJ|TW|XJ|XZ|YN|ZJ=CHN
|AGU|BCN|BCS|CAM|CHP|CHH|COA|COL|DIF|DUR|GUA|GRO|HID|JAL|MEX|MIC|MOR|NAY|NLE|OAX|PUE|QUE|ROO|SLP|SIN|SON|TAB|TAM|TLA|VER|YUC|ZAC=MEX
|#default=UNK
}}}}

Essentially one line, below, is added in between the existing codes for Canada and Mexico:

|AH|BJ|CQ|FJ|GD|GS|GX|GZ|HA|HB|HE|HK|HL|JL|JS|JX|LN|MC|NX|QH|SN|SX|TJ|TW|XJ|XZ|YN|ZJ=CHN

Thanks for your help in advance (and thanks to Fredddie for writing it up). Heights^{(Want to talk?)} 22:37, 30 May 2013 (UTC)

Done. Thank you! — Mr. Stradivarius ^{♪ talk ♪} 03:58, 1 June 2013 (UTC)

A complete, Lua-based rewrite of this template is being discussed at Template talk:Infobox road/Rewrite. Your input is requested. Thank you. -happy5214 08:02, 21 June 2013 (UTC)

How can one create a subtemplate of {{Jct}} for prefectural routes of Japan? So far, as I was working on the junction list for Japan Route 1, I'm trying to produce this (I know, the image link doesn't have an image currently so it says "20px" instead):

File:Prefectural Route Sign 0030.svg Prefectural Route 30

But it requires a mouthful of text to type a prefectural route out manually, like:

[[File:Prefectural Route Sign 0030.svg|20px]] [[Osaka Prefectural Route 30|Prefectural Route 30]]

How can I create a subtemplate of Jct so I am able to say something like,

{{Jct|prefecture=Osaka|Route|30}}

instead? Fritzzzh (talk) 20:48, 24 August 2013 (UTC)

This seems like a good idea, so let's see what we can do. Japan has three main subtemplates:

• {{Jct/shield/JPN}} (Prefectural Route Sign 0030.svg)
• {{Jct/link/JPN}} (Osaka Prefectural Route 30)
• {{Jct/abbrev/JPN}} (Prefectural Route 30)

We also need add the list of prefectures to {{Jct/meta/mask/country}} ( Done). This provides us a shorthand, of sorts, so we don't have to specify |country=JPN every time. Typically, we would use the prefecture's abbreviation, but I don't think there are Latin-alphabet abbreviations, so we can just use the full name.

Now, the "Route" type is already taken for National Routes, so we need a new one for prefectural routes (the "???" here) {{Jct|prefecture=Osaka|???|30}}. Once we decide on that, we can move forward. –Fredddie™ 21:13, 24 August 2013 (UTC)

Hmmm, for replacing the "???", here's what I have so far in mind:

• {{Jct|prefecture=Osaka|PR|30}} ... though I'm afraid "PR" is already taken by some country for "Provincial Route"
• {{Jct|prefecture=Osaka|PrefecturalRoute|30}} ... might be too long though
• {{Jct|prefecture=Osaka|PrefRoute|30}} ... although I don't think anyone would abbreviate it this way in Japan

For the purpose of concise coding, I'm partial to the third bullet. Could we use this one? Fritzzzh (talk) 21:27, 24 August 2013 (UTC)

I may be wrong, but since the template will "know" Japan is being discussed when it detects that prefecture= contains a Japanese prefecture, it is okay to use "PR". —Scott5114↗ [EXACT CHANGE ONLY] 23:40, 24 August 2013 (UTC)

Yes, Scott is correct. Every country could have a "PR" and the template could tell them apart. –Fredddie™ 23:43, 24 August 2013 (UTC)

Okay, I'll go with "PR" as well. The shorter the code, the better. :) Fritzzzh (talk) 23:49, 24 August 2013 (UTC)

Before we go much further, I think it would be a good idea to create a set of generic images, or shields, for PRs. The Japanese characters will be impossible to see, let alone read, at 20-or-so pixels, so we can omit them. Also, we could use the generic images for all prefectures, which would drastically simplify our work.

On the Japanese Wikipedia, their version of {{Infobox road}} uses a blank prefecture-specific hexagon and numbers are superimposed on top of it. I think we can work with that same model, if we aren't already. –Fredddie™ 00:01, 25 August 2013 (UTC)

To enable disambiguation for Interstates when using {{jct|country=USA| ... |dab1=}} Please change:

|#default=Interstate {{{route}}}{{#if:{{{state|}}}| ({{StateName|{{{state}}}}})}}

to:

|#default=Interstate {{{route}}}{{#if:{{{state|}}}| ({{StateName|{{{state}}}}})}}{{#if:{{{dab|}}}| ({{{dab}}})}}

Note to the admin: you'll need to copy and paste the source code as there are characters that don't display properly. Thanks, Imzadi 1979 → 18:07, 25 August 2013 (UTC)

 Done -- WOSlinker (talk) 18:34, 25 August 2013 (UTC)

I would like to begin consolidating the USA subtemplates that are under the Infobox road namespace to the Jct namespace. I know there has been talk of moving it over to Lua, but from what I know, that has yet to begin. –Fredddie™ 02:28, 3 October 2013 (UTC)

I probably won't have extra time to convert them to Lua until the December/January timeframe. It should also be mentioned that the templates are also used for the browse box in Infobox road. Accordingly, my plan is to have an entirely separate namespace for the new Lua modules. -happy5214 06:45, 3 October 2013 (UTC)

Yeah, this is just for the interim period until those can be converted. --Rschen7754 06:46, 3 October 2013 (UTC)

I'm not talking about {{Infobox road/shield/USA}} and those subtemplates per se. I'm talking about consolidating and deleting subtemplates like {{Infobox road/IA/shield IA}} of which there are three subtemplates per type. –Fredddie™ 11:31, 3 October 2013 (UTC)

• Template:Jct uses each {Infobox_road/IA/shield_IA}, {Infobox_road/IA/link_IA} and {Infobox_road/IA/abbrev_IA}, but combining them will just slow processing further. -Wikid77 (talk) 08:08, 18 October 2013 (UTC)

The design of Template:Jct has been using Template:Jct/2, Template:Jct/3 and Template:Jct/4, but {Jct} runs very slow, as only 5 junctions per second, with the 1,730 subtemplates of {Infobox_road/..}, such as Texas state roads with {Infobox_road/TX/shield_TX}, {Infobox_road/IA/link_TX} and {Infobox_road/TX/abbrev_TX}. Instead, {Jct} should be split into the 50 quick subtemplates (120 per second), for the 50 U.S. states, with each state name hard-coded, such as "California" with "CA" and then each state template can list the road-type codes for each U.S. state, and the warning messages can remind users which state name is being processed. For example, some people think "AL" is for Alaska roads (AK), rather than Alabama as "AL". I understand how the pool of 1,730 subtemplates seemed like an easy way to add more road-type entries, but users do not know which of those 1,730 can be used for each state, in such a vast list of subtemplates. -Wikid77 (talk)

Oppose. I'm not interesting in forking out templates for each state, every Canadian province and all of the other countries using it. Imzadi 1979 → 08:10, 18 October 2013 (UTC)

Oppose We have a Lua solution that will hopefully be deployed by the weekend, and then we will not be relying on said 1730 templates. Meanwhile, the system that you propose will be impossible to maintain. --Rschen7754 08:13, 18 October 2013 (UTC)

Strong oppose. We have a solution for the problem with existing jct, which has been under development for the last few months. It is being expedited and will be deployed soon. Splitting the templates is unnecessary at this time. —Scott5114↗ [EXACT CHANGE ONLY] 22:02, 18 October 2013 (UTC)

Strong oppose per the above. I would like to know where this "5 junctions per second" figure comes from. I just don't see it. –Fredddie™ 22:06, 18 October 2013 (UTC)

To get the average runtime, then repeatedly call {Jct} with various parameters, and check the page runtime for several edit-previews, then divide the average lower runtime into the count of {Jct} templates used. I was shocked it could be so slow, which is equivalent to ~200 if-structure parser functions to process each {jct}. By comparison, with 50 state {JctXX} subtemplates, many U.S. state roads could be formatted with just 10 if-functions checked per second, such as California having so many "SR" (State Road) junctions. -Wikid77 (talk) 02:42, 19 October 2013 (UTC)

Strong oppose pretty much per Rschen. A system of 1700+ templates is hard to manage, and the load times are long, but the Lua rewrite we're working on right now should reduce load times and deems this solution unnecessary. TCN7JM 02:46, 19 October 2013 (UTC)

The problem with the typical massive Lua modules is that a change to add a new road-type, for just one region, will trigger reformatting all of the road-article pages. In this case, call the behemoth, "Luasaurus giantroadus". Instead, I was thinking to start with the 50 separate state templates, to optimize each (as time permits) by re-ordering the road-types by most-used for each state, such as "SR" (or "SH") and "US" roads first. Then each state's {JctXX} would become so fast that Lua would not be needed for speed. Also, changes to {JctTX} would affect only roads connecting to Texas, rather than trigger reformatting of all articles which use {Jct}. Of course in Lua, a similar split could be made at lower levels, to only read the Texas Lua data when parameter "state=TX" made the connection, and changes to each Lua state-data module would trigger reformatting only "1/50th" of the total road-article pages. For Module:Convert planned to rework Template:Convert, there is a rare Module:Convert/extra which is linked only when a new code is added (as not found in the main /data module), and so adding a new code only reformats pages which used other recent new codes, rather than reformat all 570,000 pages which use {convert} when a new code is added to the table. -Wikid77 (talk) 22:10, 19 October 2013 (UTC)

And then, when MOS:RJL is updated (which happens quite often), instead of updating 1 template, we now have to update 100. Not good. --Rschen7754 22:13, 19 October 2013 (UTC)

I see two issues with Wikd77's comments. First is that we don't change stuff very often of that sort. It's not like there are new highway types being added very often in the US. (As long as the international types are still segregated in the modules, bringing additional countries on board won't force a reload of the US articles.) But on the other hand, when we do change things in the template because of update in MOS:RJL, it would be of a higher level that would force a reload of every article in use anyway. In those cases, we do want to force those reloads, and we would want only a single set of edits to one template to be needed rather than editing 50 state, 10 provincial and several dozen international templates over one MOS change. Imzadi 1979 → 13:21, 20 October 2013 (UTC)

I would like to propose, without prejudice, the deprecation of generic types (and their bannered subtypes) used by this template. These have to do with US state highways only.

• Hwy
• Route
• SH
• SR

In doing this, a large and unwieldy switch that exists in {{Jct/shield/USA}} would be removed. In their place, I would suggest using the state abbreviation. In many cases, this is already set up, so all we would need to do is an AWB run to clean it up. –Fredddie™ 04:34, 20 October 2013 (UTC)

Canada uses a lot of the same structure... so we could apply it there too. --Rschen7754 04:35, 20 October 2013 (UTC)

Those road types, as Hwy, Route, SH or SR, are the common terms for the roads. In fact for U.S. Route 66, there is a mass of popular culture including a famous television series, Route 66 (TV series), music, with "Route 66 (song)" and people have photos showing road signs as "Route 66". In Texas or Oklahoma, they are called "SH" State Highways, and there are over 670 articles which use Texas "SH" roads. Instead, {Jct/shield/USA} needs to be re-structured for faster processing. The common road-types should be placed near the top of the #switch:

|US=US {{{route}}} ({{{state}}}).svg

|SR={{#switch:{{{state}}}|CA=California|FL=Florida}} {{{route}}}.svg

|SH={{#switch:{{{state}}}|TX=Texas|OK=Oklahoma State Highway}} {{{route}}}.svg

Adding those lines to the top of the #switch could make many road-exit lists format 20% faster. However, the clearest solution would be to split each as {JctCA}, {JctFL}, {JctTX}, {JctOK}, etc. -Wikid77 (talk) 08:57, 20 October 2013 (UTC)

And this completely misses the point of why I would like to deprecate these terms. –Fredddie™ 11:35, 20 October 2013 (UTC)

That, and that sort of logic completely breaks a case like |state=IL|type=IN. --Rschen7754 17:56, 20 October 2013 (UTC)

The Canada highway sign seems too small in {Jct}, as with Ontario Highway 401:

• {{jct|state=QC|A|30|to2=to|A|20|ON|401|city1=Salaberry-de-Valleyfield}}
  → A-30 to A-20 / Highway 401 – Salaberry-de-Valleyfield

The highway image size has been 12x20px, while the Autoroute images are 18x24px high. Should the Canada highway signs be taller? -Wikid77 (talk) 16:18, 31 October 2013 (UTC)

I think the Quebec shields should be shrunk, as 21px seems to be the maximum height that won't break standard line height. Unfortunately some provinces have very tall shield icons, but, since they are supposed to supplement the text and not convey information on their own, I don't believe there is a huge issue and WP:ACCESSIBILITY / MOS:ICONS should be referenced. - Floydian ^τ _¢ 20:33, 31 October 2013 (UTC)

Instead of writing 50 separate Jct templates for the 50 U.S. states, I am creating a single new template (to be "Template:JctUS") as 7x-10x times faster, which can handle any US state roads but also the border roads with Mexico and Canada. JctUS handles the 31 US-highway variants (US-Alt, US-Bus, US 1948, US 1948-Truck, etc.) as a subset of "US". The road-shield banners (top line of thin plate images above road-signs) are processed quickly, and 2x fewer uses of #ifexist help to reduce the run time. Although JctUS is intended only for large articles which need faster edit-preview, the design could be considered as an alternate algorithm for the Lua-based Jct, as expanded to handle all international roads, beyond Canada and Mexico. Tests with various road pages show the performance as over 7x faster, to cut total edit-preview to half or one-fifth; 35 seconds quickens to 15 or 7-second edit-preview, and "Interstate 10 in Texas" can reformat in 22 seconds with JctUS versus 52-58 seconds with Jct. All signs/text are displaying as identical, and using the 1,730 subtemplates of {Infobox_road/*} plus {Jct/banner}.
Update: Page "Texas State Highway 6" reformats in 7 sec. as JctUS, versus 37 seconds with Jct.
Update 2: Page "Quebec Autoroute 40" reformats in 3 sec. as JctUS, versus 5 sec. with Jct. -Wikid77 (talk) 13:41, 30 October, 10:02/16:18, 31 October 2013 (UTC)

Again, this is wasted effort, because it's a fork of the existing template; besides, the original template is still designed to handle all international roads. --Rschen7754 17:38, 30 October 2013 (UTC)

Exactly. Rather than forking, we should be concerned with fixing what already works. –Fredddie™ 17:45, 30 October 2013 (UTC)

Again, I oppose creating another fork of the template. We should improve the existing template as is so all articles using it benefit, not create forks for special case situations. I don't want people to have to remember which of several essentially identical templates they're supposed to remember to use on which articles under some rubric imposed by Wikid77 based on his ideas of speed, when one template can implement all of the various improvements and benefit thousands of articles. BTW, how may forks do we have now, at least three? Imzadi 1979 → 21:02, 30 October 2013 (UTC)

• Fast-forks can be listed in doc-page: A common tactic is to list the related templates at the bottom of the doc-page. Also, because {JctUS} is amazingly faster, then a top hatnote could warn, "See JctUS to format roads 7x faster" to avoid wp:Wikimedia Foundation error during edit-preview. Please remember, the speed of {JctUS} is not a mere 40% improvement, but rather over 700% (7x-10x) faster. Also {JctUS} will handle all other roads for parameter "country=" but runs faster for the U.S. roads. Once the Lua script fork of {Jct} has been tested for months, then {JctUS} can be redirected to #invoke that Lua fork instead. This is a path for progress as implemented with other complex templates. The wp:CS1 cite templates (with {cite_web}, etc.) started as 23 forks (which was far too many), but allowed us to transition each type to Lua after each was tested separately. By having more forks, then the transition to Lua was easier, because each type was transitioned in different weeks, starting with the less-used forks, and found bugs in the Lua Scribunto interface with the 10-second timeout. (Some people even imagined Lua would not have its own problems as well.) In this case, several articles using {JctUS} could be transitioned to Lua first, on the path to full release of the Lua-based {Jct} later. It is a path both safer and easier, plus quicker in the long term. -Wikid77 (talk) 10:02, 31 October 2013 (UTC)
  • Uh, no, not until if and when there is consensus to use those forks. As it stands, they might not pass a TFD. --Rschen7754 17:27, 31 October 2013 (UTC)

Strong oppose any forks of {{jct}} or {{jctint}}. —Scott5114↗ [EXACT CHANGE ONLY] 00:01, 1 November 2013 (UTC)

We already have forks for {CAint}, {TXint}, {VTint} (etc.), allowing for optimization. The performance forks are preferable to a mega-funnel template, which is devouring the servers with unnecessary repetition to lookup "TX" as "Texas" 100-600 times per article. Anyway, the various forks can use a common "/core" template for the processing of standard options. Otherwise, the excessive funneling of templates, into gigantic mega-funnels, has produced a nightmare of performance problems. A logical system of quick fork templates is more flexible, to allow specific optimization where each is used, while providing a similar set of core options. -Wikid77 (talk) 16:55, 1 November 2013 (UTC)

I agree that we shouldn't be forking the template, but something needs to be done to fix List of state highways in Texas which crashes about 2/3 down the page. Plastikspork _―Œ^(talk) 01:58, 1 November 2013 (UTC)

Lists like that need to be converted follow WP:USRD/STDS/L, which is a new standard for route lists. If you follow that standard you can use {{routelist row}}, which is already all done in Lua and hopefully will have fewer issues. —Scott5114↗ [EXACT CHANGE ONLY] 02:06, 1 November 2013 (UTC)

Page "List of state highways in Texas" can no longer edit-preview nor Save, with 620 {Roadlink} and 358 {Jct} templates requiring over 90 seconds to reformat, but the page could be reformatted, if modified to use the performance forks to streamline the operation. Then various template forks can be changed to use Lua, as the Lua forks are expanded and tested. -Wikid77 (talk) 16:55, 1 November 2013 (UTC)

Functionally the best thing to do would be to replace {{roadlink}} with plain wikilinks, as it is merely a convenience feature that just creates links. That will knock out 620 template calls for you, which should be enough to fix the page. —Scott5114↗ [EXACT CHANGE ONLY] 18:46, 1 November 2013 (UTC)

• Large pages still slow: I have begun trimming page "List of state highways in Texas" and removed 300 of the 620 {Roadlink}, but we need some simple Lua versions of {Jct} and {Roadlink} to go 30x times faster, as 350 Lua per second, rather than 10 {Roadlink} per second. See below: #Start Lua version". -Wikid77 (talk) 21:21, 1 November 2013 (UTC)

If we start the Lua script version of Template:Jct, as a prototype (perhaps: Module:Jct_proto), then it could be used as an emergency fix for the large pages, which format over 25+ seconds as very slow during edit-preview and hit the 60-second timeout limit with "wp:Wikimedia Foundation error". Otherwise, we need a small fork of {Jct} or {Roadlink} for each special case, because only Lua could run 350 per second for all the various cases of large pages needing a quick version of {Jct}: large Texas, California, British Columbia, or U.S. Interstate lists, etc. Every time additional functionality is added to markup-based templates, then they slow even further, perhaps each 20% more, and a tiny fork which ran 25x faster would grow to a better fork but only 5x faster with more options. The current Jct-family of subtemplates are each causing part of the delay, when passing many template parameters, and transitioning just some, such as {Jct/link/USA} or {Jct/shield/CAN}, into Lua, does not gain enough speed, until the whole family of {Jct/1}, {Jct/2} and such are also replaced by a Lua version. I think the best path is to create a Lua prototype version, to support the fast emergency cases, and then replace it with the formal Lua version after the months of testing. Otherwise, people have predicted the need for many special-case forks, or else tediously remove extra templates and flood a table with an ocean of road wikilinks or omit the road signs. -Wikid77 (talk) 21:21, 1 November 2013 (UTC)

We're already working on the Lua version, and we don't need your help. And please don't go ahead and keep creating template forks despite consensus. --Rschen7754 21:29, 1 November 2013 (UTC)

This is in development. There is no deadline. Some patience would be appreciated. —Scott5114↗ [EXACT CHANGE ONLY] 22:07, 1 November 2013 (UTC)

Also note that this is not just a case of rewriting the current code in Lua, there are things to fix such as the banner-gap issue - Evad37 (talk) 02:20, 2 November 2013 (UTC)

Hope I'm asking in the right place. I am hoping to have two things done for jct coding for South Carolina highways. The first one is connector routes, they do exist though signage is limited; here's an example and another example of them in the wild. The signage SC uses is "CONN" and it is used both for US and State highways (none for interstates at this time); lettering is black, not blue (oddly). The second is the dab coding, which doesn't appear to work for South Carolina highways yet, unlike North Carolina where it does. Thank you in advance. --WashuOtaku (talk) 18:14, 27 December 2013 (UTC)

US 1 Conn. / SC 20 Conn. I set up the types, but the details are not complete yet. –Fredddie™ 23:53, 27 December 2013 (UTC)

OK, US-Conn and SC-Conn are both set up. All of the available SC banners (Alt, Bus, and Conn) should take dab now. –Fredddie™ 02:27, 28 December 2013 (UTC)

Thank you, they appear to be working. I suspect the black letters are leftover when they switched to the new shields, hopefully future signs will be blue lettering, but none found yet. --WashuOtaku (talk) 03:19, 28 December 2013 (UTC)

When that day comes, it should be as simple as uploading a shield over the image redirect (or deleting the redirect) at Commons. –Fredddie™ 04:31, 28 December 2013 (UTC)

Was the option implemented in Jct? I know it was discussed here and here. --AdmrBoltz 16:30, 31 December 2013 (UTC)

It doesn't appear so. {{jct/banner}} doesn't make any mention of toll roads. -happy5214 23:21, 31 December 2013 (UTC)

Well then, I say it should be created still. Its already being hand coded in the field in some NC articles, but we should probably start using it in {{tl|jct]} proper. --AdmrBoltz 23:29, 31 December 2013 (UTC)

I will put it on my to-do list for the rewrite. -happy5214 23:45, 31 December 2013 (UTC)