Template talk:Jct/Archive/2019

Separator character in location lists

Currently when listing multiple locations, they're separated by commas (,). I think this should be changed to use semicolons (;) because the individual locations could have commas within them, such as when city names are followed by state names. For example, on Massachusetts Turnpike#Exit list, exit 9 lists "I‑84 west – Hartford, CT, New York City". Because the entry is copying the sign, it includes the abbreviation for the state name for the location of "Hartford, Connecticut". In this case, an astute reader should discern that "CT" isn't the name of a separate location, but had it been spelled out: "I‑84 west – Hartford, Connecticut, New York City", it would be even less clear to readers unfamiliar with US geography.

The citation templates use semicolons to separate names of authors/editors because those entries will have internal commas: "Doe, John; Roe, Richard; Major, Mary (n.d.). Title.", etc. Perhaps we should switch to the same convention, thus resulting in "I‑84 west – Hartford, CT; New York City" or "I‑84 west – Hartford, Connecticut; New York City" in the example above? Imzadi 1979 → 05:53, 28 July 2018 (UTC)

Follow-on comment: I know that astute readers would be able to hover their cursors over the links and see that "Hartford, CT" is one link, and "New York City" is another. At the same time, a tool tip would appear with "Hartford, Connecticut" as the link (because the link was piped to the full name, a good practice to follow), but these clues don't work on tablets/phones with touch interfaces. Also, they're useless in printed versions of articles, and one of the goals of Wikipedia is to make the content reusable without format limitations. Imzadi 1979 → 06:04, 28 July 2018 (UTC)

We've been using this template for 10 years and I don't recall comma use being an issue from an MoS standpoint. That being said, I'm not opposed to what you're proposing. While we're at it, is our use of en dashes separating roads from destinations standard? –Fredddie™ 15:46, 28 July 2018 (UTC)

Banners float too high and wrap badly

Example 1	Example 2
Bus. US 79 has banner floating too high.	This sentence about Bus. US 79 should remain on one line.

Looks like this on my system: https://i.imgur.com/XpoNQUl.png

That's an effective margin of 5px whereas 0 or 1 would be ideal. Also, html output contains a <br /> element which jacks up any adjacent text. I see this was discussed above #CSS redo for banners but that was 2–3 years ago. ―cobaltcigs 06:54, 5 August 2019 (UTC)

@Chinssai, Happy5214, and Evad37: this is more for you three. I thought the image stacking code worked just fine. Can that be re-tested and applied without anything else that was being discussed above? –Fredddie™ 12:40, 5 August 2019 (UTC)

@Cobaltcigs: one thing to note, but this template shouldn't be used mid-sentence because the MOS doesn't normally allow graphics to appear that way. On that basis, the line break shouldn't be an issue because the template should never be used in a situation where it would cause an issue. Related to List of highways in Williamson County, Texas, see my recent edits there to remove the graphics from parts of the table because we typically only use them on the subject to avoid distracting the emphasis away from the subject of each line of the table.

That said, there was some work on a different method to stack graphics that would have allowed other updates, including adding additional banners (like "To" or even directional banners). Imzadi 1979 → 15:04, 5 August 2019 (UTC)

Huh, where does it say that? What is Template:Jct even for, if not for visual enhancement of junction lists (the exact context from which you removed it)? ―cobaltcigs 15:25, 5 August 2019 (UTC)

You're working on a route list, not a junction list. See other such lists like List of Interstate Highways in Texas, List of Interstate Highways in Michigan, List of U.S. Highways in Michigan, and List of County-Designated Highways in Michigan], and you'd note that we don't put the graphics in for anything but the subject of each line. Imzadi 1979 → 15:58, 5 August 2019 (UTC)

The fourth cell in each row is labeled as a list of junctions for the route indicated in the first cell of that row, in accordance with the table format that I copied almost exactly from the (pre-existing and geographically adjacent) List of highways in Travis County, Texas. I did use {{plainlist}} (invisible bullet points) instead of <br /> because it looks better and is more semantically correct. Not any of that is relevant, unless you're implying my reason for wanting this template fixed is invalid. ―cobaltcigs 16:18, 5 August 2019 (UTC)

The template should be fixed for other reasons. That said, we've moved on from creating these routes lists for counties, and we've advanced the standards for route lists in general. In other words, the example you're using is quite out of date. Imzadi 1979 → 16:48, 5 August 2019 (UTC)

So, back on the original subject:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Dolor sed viverra ipsum nunc aliquet bibendum enim. In massa tempor nec feugiat. The following banner CSS seems ideal, pero no comprendo la idioma de Lua:  Bus. US 79. Nunc aliquet bibendum enim facilisis gravida. Nisl nunc mi ipsum faucibus vitae aliquet nec ullamcorper.  Bus. US 271. Amet luctus venenatis lectus magna fringilla. Volutpat maecenas volutpat blandit aliquam etiam erat velit scelerisque in.

Bus. US 79  Bus. US 271  US 1-9 Truck

The style attributes in the <span>s above should of course be replaced by equivalent class definitions (loaded from… somewhere else), with the exception of width which surely must already be calculated for shield image width. Hopefully others can confirm the result looks pretty good in a variety of browsers. ―cobaltcigs 21:08, 5 August 2019 (UTC)

Alignment errors in infobox

I've noticed that in infoboxes with bannered routes listed as junctions, there is some misalignment between linked and unlinked items. See Delaware Route 24 for an example of what I am talking about. Dough4872 04:35, 7 August 2019 (UTC)

Line breaks

@Fredddie: I don't know how this module works, but it's absolutely a bad idea to introduce line breaks in any templates related to route diagrams, because {{Routemap}} will use any line break in the input to determine where to split lines. There was only one line break in the module code, so I've removed it. Jc86035 (talk) 07:43, 7 August 2019 (UTC)

Script errors

@Fredddie: Please check my edits in Module:Jct and Module:Road data. I was trying to remove articles from Category:Pages with script errors. The edits successfully removed quite a lot, but more remain. For example, G1 Beijing–Harbin Expressway is showing "Lua error in Module:Road_data/browse at line 54: bad argument #2 to 'format' (string expected, got table)" which might be the same problem addressed in my second edit. Johnuniq (talk) 10:43, 7 August 2019 (UTC)

@Johnuniq: I think your edits have broken other articles. See the second row of the table in U.S. Route 24 in Michigan for an example. That cell is empty because it appears that jct is ignoring the intentionally blank first unnamed parameter in {{jctrdt|state=MI||Luna Pier Road|M|125|I|75|to2=yes|to3=yes}} that would have produced:

Luna Pier Road to M-125 / I-75

previously. (This uses the fact that the odd-numbered unnamed parameters are roadway types, and the evens are corresponding numbers; for plain road names, we can use a blank type to let it just display the name.)

I think that articles with transclusions that include an accidental/unintentional | at the end before the }} or an accidental/unintentional || in the middle probably should just be fixed instead of trying to make the template ignore them because now it's ignoring the intentional cases and breaking things. Imzadi 1979 → 00:49, 8 August 2019 (UTC)

Sorry but I do not know what syntax this template is supposed to support. My edits were purely to remove script errors from articles in the hope that someone who understood what the family of modules was supposed to do would provide a proper fix. There are still 119 articles in Category:Pages with script errors and if they can't be quickly fixed, it might be advisable to revert all recent changes to restore whatever the previous error-free version was. By all means revert my edits to the module if someone would like to work out what articles generate an error from a (probably) unintended blank parameter in order to repair the articles. However, that would need to be done fairly quickly which is tricky with hundreds of errors because the category can take days or weeks to catch up. Some kind of error tracking category might help. I expected that the second error I mention (string expected, got table) would be easy to fix for someone who understood the overall picture of these generally well written modules, but it's still there. Johnuniq (talk) 08:11, 8 August 2019 (UTC)

Revisions

@Fredddie and Johnuniq: You still don't have it right. Now |rdt=y stacks the route and the name, and omits the ( ) around the name. Play around in the sandbox, not with a live template.

• {{jctrdt|state=NY|I|990|name1=[[Lockport Expressway]]}} →

  I-990

  Lockport Expressway

• {{jctrdt|state=NY|I|990|name1={{BSsplit|Lockport|Expressway|Lockport Expressway}}}} →

  I-990

  Lockport Expressway

Useddenim (talk) 13:31, 7 August 2019 (UTC)

What's not correct? The examples provided display as you describe them. I'm not at all familiar with how RDT stuff should display, but I'm starting to think maybe this template isn't the way to go. –Fredddie™ 23:12, 7 August 2019 (UTC)

The solution is to ditch the if statement on line 30 and just use that else clause. Is the old version what the "correct" display should be, Useddenim?

There's also the issue of, well, a ton of issues that shouldn't have passed testing. Do we need to consider reverting everything until the new code can be more thoroughly tested? The frequent fixes to the live copy are disruptive. -happy5214 00:27, 8 August 2019 (UTC)

Some of the fixes, as noted in the section above, actually broke other things when then solution may have been to fix questionable transclusions in articles. Imzadi 1979 → 00:51, 8 August 2019 (UTC)

Please see my response in the previous section. I was merely trying to reduce the number of articles displaying errors in the expectation that a proper fix would be coming soon. Please revert my edits and if wanted all recent edits to restore something that works if there are no plans for a quick fix. If wanting to work on the module, please check Category:Pages with script errors for problems. Johnuniq (talk) 08:16, 8 August 2019 (UTC)

Apologies

I have reverted the modules that feed this template to their states before I did so. I was under the impression that the code worked since on our testcases pages, everything appeared as they should. But, there are a nearly infinite number of combinations that this template can accommodate, so I didn't anticipate rdt=y breaking, or China's instances breaking entirely. And yes, code should be tested thoroughly in sandboxes before deploying, but sometimes that's just not possible.

So I'm sorry for breaking everything. It should be "back to normal" now, or will be soon. –Fredddie™ 13:11, 8 August 2019 (UTC)

No problem, and thanks for working on the modules. I agree that a comprehensive set of testcases is not always possible, particularly when a template has been used for a while and has tricky usage combinations. The error category is cleaned out now. Johnuniq (talk) 23:35, 8 August 2019 (UTC)

Actually, two errors remain. See "Lua error: too many expensive function calls" in G4 Beijing–Hong Kong–Macau Expressway and G30 Lianyungang–Khorgas Expressway. That is probably due to an ifexist test to determine whether the icon image exists, and the articles have too many of those images. Not sure what can be done about that apart from a severe prune. Or, perhaps remove the ifexist and tolerate red links if the images do not exist. Johnuniq (talk) 23:48, 8 August 2019 (UTC)

There were about six ifexists in Module:Road data/strings/CHN and I removed four of them. If you know of a way that module can be cleaned up, have at it. Both of those articles are cleared out now. –Fredddie™ 00:44, 9 August 2019 (UTC)

Kosovo

Hi! I'm working on making new modules for different countries and was wondering what to do about Kosovo. Kosovo doesn't have an ISO-3166-1 alpha-3 code, nor is it universally recognized as a country, but it does have roads and road signs. Thoughts? Best, WMSR (talk) 22:02, 8 September 2019 (UTC)

KOS is set up as the alpha-3 code for Kosovo for now. I think once it gets wider recognition and does get its own code, we'll move everything there, but for now KOS works for our purposes. –Fredddie™ 22:19, 8 September 2019 (UTC)

Great! I think I've gotten every country with a Commons category except Iran. Can't figure out how to do side-by-side icons for one road. WMSR (talk) 03:49, 9 September 2019 (UTC)

@WMSR: Per Module:Road data/strings/doc#Other functionality, you can show multiple shields per route by using a two-item table for the shield value. Each string in the table has the same format as a single string. -happy5214 19:08, 9 September 2019 (UTC)

What's wrong ?

I used to tag higways and it was OK. But now it is not working properly. See D.400 or D.200 (older version) . Any suggestion ? Thanks Nedim Ardoğa (talk) 13:01, 10 September 2019 (UTC)

@Nedim Ardoğa: What specifically is the issue you're running into? Just saying that "it is not working properly" doesn't help us fix it. -happy5214 16:42, 10 September 2019 (UTC)

Route signs of roads in Luxembourg

I request to change signs for Luxembourg national roads – the ones already being shown are simply wrong (colour, font shape; why use French signs???). I have uploaded a few correct files on Commons (the rest will be uploaded in the near future) → check the category.

Mkmk101 (talk) 20:18, 26 November 2019 (UTC)

Hello! We can make that change once the rest are uploaded. For the convenience of future editors, can you also upload a template version of the new signs (as described in WP:USRD/S/TUT, but use the Luxembourg font and sizing standards instead of the US standards)? -happy5214 23:19, 26 November 2019 (UTC)

@Mkmk101: --Rschen7754 19:13, 27 November 2019 (UTC)

@Mkmk101: Miko, I've made the change. Be sure to watch Category:Jct template errors over the next few days to see if files are needed. –Fredddie™ 01:44, 2 December 2019 (UTC)