Template talk:Infobox road/Archive 7

Archive 1Archive 5Archive 6Archive 7Archive 8

Modularization of the infobox

I would like to propose another backend overhaul of this template. No, not a complete overhaul like in 2010, plus I don't even have code ready to go. I would like to see some coding that's currently in the main template shifted to subtemplates.

  • Section junction lists
Currently, lines 29 through 59 (we skipped even numbers here to allow room for growth) handle junction lists for each of the four possible sections. We could move this to a subtemplate and the result would allow the same content on four lines of main template code. Then, if we wanted, we could support 8 sections as has been requested in the past and only use eight lines of template code. If we did go up to 8 sections, I would additionally propose turning off the |junction#= parameters after the fifth section appears, but that's another discussion.
  • Locations
Lines 61 through 72 (no gaps) handle locations. For this one, I was thinking we could throw every relevant parameter we can think of at a subtemplate and it would parse them all and only display the ones that are "turned on", similar to how the hide templates, {{Infobox road/hide/cities}}, for example, operate. Again, this would all be on one template line instead of 11.

These subtemplates would utilize {{Infobox}}'s |child=yes feature, which embeds secondary infoboxes into the main template. I think we have all the necessary infrastructure in place where it wouldn't take a lot to create subtemplates and get them tested and rolled out without a massive AWB spree.

The ulterior motive behind this is that with the latest edits today, I discovered that we're running out of space for new parameters. As I mentioned above, we skipped the even line numbers we would have room for growing the template. Well, we've almost exhausted the even numbers in some spots. If we go through with both subtemplates here, I will propose renumbering some of the lines to add the space that we lost back into the template. –Fredddie 05:43, 12 May 2012 (UTC)

This works for me, but at the same time, maybe we should look at some things that should come out of the template. As it stands, I personally don't think going up to 8 segments is needed. IFF we did 8 though, we'd have to suppress junctions and go to termini only to keep the overall length manageable.
On the other hand, I'm thinking that we should remove some of the location parameters. Cities, villages and towns are what I'd remove. I know that this would mean removing content internationally, but as was seen in the US, selecting which cities/villages/towns appear and which are left out is problematic. The other issue is that cities/villages/towns are on the same level essentially, and yet they're divided into separate lists which removes any geographic progression between them. All of the other location parameters (countries, states, regions, provinces, counties/parishes/municipalities/rural municipalities, districts, and destinations) can stay. That will free up some space, and simplify us to a top-level jurisdiction or the official primary destinations. Imzadi 1979  05:56, 12 May 2012 (UTC)

previous_dab and next_dab

These fields don't appear to be working. I can get previous_type and _route on the go, but the article I'm editing refers to a different road network to the default (Northern Ireland rather than Great Britain) so the links need to be disambiguated. Unfortunately whatever I put under the dab fields [full wiki link to article, or a bracketed suffix to be added to "A4 road" to make it "A4 road (Northern Ireland)" etc.] doesn't seem to have any effect on the previous and next links in the infobox.

Please see the currently commented-out section of M1 motorway (Northern Ireland) infobox. Fattonyni (talk) 13:49, 12 August 2012 (UTC)

I haven't made the dab param work but what I have done is make the links work without dabs when province=NI. I've updated Template:Infobox road/link/GBR. -- WOSlinker (talk) 14:15, 12 August 2012 (UTC)
Nice one, thanks. Fattonyni (talk) 14:28, 12 August 2012 (UTC)

Edit request on 15 August 2012

Please change the LOCATION INFORMATION section to have the following:

|header61= {{#if:{{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}{{{boroughs|}}}{{#ifeq:{{Infobox road/hide/countries|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{countries|}}}}}{{#ifeq:{{Infobox road/hide/regions|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{regions|}}}|}}{{#ifeq:{{Infobox road/hide/provinces|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{provinces|}}}|}}{{#ifeq:{{Infobox road/hide/ruralmuni|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{rural_municipalities|}}}|}}{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{cities|}}}{{{towns|}}}{{{villages|}}}}}{{#ifeq:{{Infobox road/hide/destinations|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{destinations|}}}|}}{{#ifeq:{{Infobox road/hide/states|{{{country|}}}}}|no|{{{states|}}}|}}|Location}}
|label62 = Countries:
|data62  = {{#if:{{{countries|}}}|{{#ifeq:{{Infobox road/hide/countries|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{countries|}}}|}}|}}
|label63 = Regions:
|data63  = {{#if:{{{regions|}}}|{{#ifeq:{{Infobox road/hide/regions|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{regions|}}}|}}|}}
|label64 = States:
|data64  = {{#if:{{{states|}}}|{{#ifeq:{{Infobox road/hide/states|{{{country|}}}}}|no|{{{states|}}}|}}|}}
|label65 = Provinces:
|data65  = {{#if:{{{provinces|}}}|{{#ifeq:{{Infobox road/hide/provinces|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{provinces|}}}|}}|}}
|label66 = {{#if:{{{parishes|}}}|Parishes|{{#if:{{{municipalities|}}}|Municipalities|{{#if:{{{districts|}}}|Districts|{{#if:{{{boroughs|}}}|Boroughs|Counties}}}}}}}}:
|data66  = {{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}{{{boroughs|}}}
|label67 = {{#ifeq:{{{province|}}}|AB|Specialized<br>and r|R}}ural<br>municipalities:
|data67  = {{#if:{{{rural_municipalities|}}}|{{#ifeq:{{Infobox road/hide/ruralmuni|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{rural_municipalities|}}}|}}|}}
|label68 = Divisions:
|data68  = {{#if:{{{divisions|}}}|{{#ifeq:{{Infobox road/hide/divisions|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{divisions|}}}|}}|}}
|label69 = Districts:
|data69  = {{#if:{{{districts|}}}|{{#ifeq:{{Infobox road/hide/districts|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{districts|}}}|}}|}}
|label74 = Major cities:
|data74  = {{#if:{{{cities|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{cities|}}}|}}|}}
|label75 = Towns:
|data75  = {{#if:{{{towns|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{towns|}}}|}}|}}
|label76 = Villages:
|data76  = {{#if:{{{villages|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{villages|}}}|}}|}}
|label77 = {{#ifeq:{{{country|}}}|GBR|[[Primary status|Primary<br>destinations]]:|Primary<br>destinations:}}
|data77  = {{#if:{{{destinations|}}}|{{#ifeq:{{Infobox road/hide/destinations|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{destinations|}}}|}}|}}

This will add districts for Uruguay. Imzadi 1979  14:32, 15 August 2012 (UTC)

While I support this in principle, I think we need to do something different to clean this up. We have a countries line, three lines for state-level areas, four for county-level areas, and three more for cities and equivalents. That's without counting the primary destinations line. I'd like for us to work out something where this is trimmed down to five lines at most. –Fredddie 18:20, 15 August 2012 (UTC)

Problem with conversion of miles to kilometres when page is rendered as PDF

Please see Template talk:Convert#Problems with this template in Book namespace. It is not a problem with {{convert}}, nor with Book namespace, but something inside {{Infobox road/meta/length}} when rendered as a PDF. --Redrose64 (talk) 17:02, 7 September 2012 (UTC)

Why is this template making conversions, rather than calling {{Convert}}? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:04, 7 September 2012 (UTC)
I mentioned it on the Convert talk page. It had to do with the placement of references. –Fredddie 23:44, 7 September 2012 (UTC)
That doesn't answer my question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:52, 7 September 2012 (UTC)
It could use convert with the "disp=output only" option in Infobox road/meta/length but convert still errors on pdf creation as well. -- WOSlinker (talk) 06:21, 8 September 2012 (UTC)
31.572 km
Oh dear. I had hoped, that per WP:MULTI, people would comment at Template talk:Convert#Problems with this template in Book namespace, not here. Now we have three separate discussions going. --Redrose64 (talk) 15:46, 8 September 2012 (UTC)
My comment is an aside about the workings of this template, not about the issue with {{convert}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 8 September 2012 (UTC)
Doesn't Fredddie's reply answer it? -- WOSlinker (talk) 12:14, 12 September 2012 (UTC)
No - see my response to his reply Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:43, 12 September 2012 (UTC)
Because it was programmed that way. - Floydian τ ¢ 12:51, 12 September 2012 (UTC)
this is something that should be explored, but we should check for possible transclusion depth issues. I know that, for example, if you try to use {{convert}} inside of {{infobox nrhp}}, when it is embedded in another infobox, you have to specify the precision/sigfigs or you will get red errors. I don't know the depth of this template, but it is something to watch out for. Frietjes (talk) 14:39, 12 September 2012 (UTC)
I get those errors on every Ontario road article, have for over 6 months now... but it doesn't seem to have any visual impact on the page. - Floydian τ ¢ 03:03, 13 September 2012 (UTC)
I've noticed them too, but only recently - maybe the software changed, or the fix caused those? Infobox road does support length_round=, by the way. --Rschen7754 03:09, 13 September 2012 (UTC)

I would like to request this change to the template. this does two very minor things. (1) it adds the hlist class to the below section, and (2) it removes the extra <p>...</p> from the browselinks. once this change is made, this will work, but without the extra div container. I am more than happy to check all of these templates to make sure they are all properly updated after the change. thank you. Frietjes (talk) 15:54, 11 September 2012 (UTC)

Done! Let me know if there is a problem. Thanks! Plastikspork ―Œ(talk) 04:59, 12 September 2012 (UTC)
that works great, and seems to fix the odd spacing issues. thank you. Frietjes (talk) 14:40, 12 September 2012 (UTC)
I made one more minor tweak to remove the newline after the "browselinks" and before the "browse" table. I think this is what was causing problems with the div hlist containers. The three edits I just made were to this template, Infobox road/browselinks/USA and Infobox road/browselinks/CAN (in case there is suddenly a major problem and my edits need to be reverted). Thanks for working on the hlist conversions, this will help improve the accessibility of this template. Thanks! Plastikspork ―Œ(talk)
Works good up in the true north with those changes from this morning. - Floydian τ ¢ 13:36, 14 September 2012 (UTC)
yes, it looks like the issues have been fixed. thank you very much! Frietjes (talk) 19:46, 14 September 2012 (UTC)

Having problems using the template for some chinese expressways

G15W Changshu–Taizhou Expressway and G4W Guangzhou–Macau Expressway don't seem to be working due to the 'w'.--ShakyIsles (talk) 09:20, 10 October 2012 (UTC)

Fixed with this edit. -- WOSlinker (talk) 11:31, 10 October 2012 (UTC)
Thanks! ShakyIsles (talk) 02:28, 11 October 2012 (UTC)

Redlinked images

Can the template be modified so that the articles in which it is used don't turn up in Category:Articles with missing files if there is no image? Eix Transversal is the most recent example that I have come across. Cheers. -- Alan Liefting (talk - contribs) 05:14, 14 October 2012 (UTC)

Each country's subtemplates handle that. See {{infobox road/shieldmain/USA}} (for the main shield at the top) or {{infobox road/shield/USA}} (for other uses like in the browsers at the bottom) for the US subtemplates. Some countries' subtemplates are set to skip missing markers. Imzadi 1979  05:55, 14 October 2012 (UTC)

For Pierce Stocking Scenic Drive, I was asked to add the Points of interest to the infobox. (The PSSD has numbered PoI designated by the National Park Service instead of junctions.) I used |section1=Points of interest to generate a custom header, but it would be nice to get the "Major junctions" label out of there. Thoughts? Imzadi 1979  02:53, 26 October 2012 (UTC)

Setup for Bangladesh

Just wondering if someone could set this up for Bangladesh. Hack (talk) 02:37, 12 December 2012 (UTC)

  Done Do you have a category or list of articles? It's easier to set it up when I know where it will be used. –Fredddie 03:08, 12 December 2012 (UTC)
Found them! –Fredddie 03:11, 12 December 2012 (UTC)
Just wondering if Template:Infobox road/abbrev/BGD and Template:Infobox road/link/BGD could be set up if that's not too much trouble. Hack (talk) 00:46, 14 December 2012 (UTC)
At some point, we should get the automatic translations going, but there is no rush for that. –Fredddie 00:55, 14 December 2012 (UTC)

Setup for Chile

I would appreciate if someone could set up a template for Chile. Thanks JaneWolf (talk) 23:56, 30 December 2012 (UTC)

Someone should be over to set it up soon, but in the meantime feel free to join WP:HWY/IRC! --Rschen7754 public (talk) 01:56, 31 December 2012 (UTC)
I've started something for it & added an infobox to Chile Route 68. I've set the shield code to use the PNG files from commons:Category:Road signs in Chile but there's also some svg files at commons:Category:Diagrams of road signs of Chile although some of the numbers only exist at one of the two locations. -- WOSlinker (talk) 08:17, 31 December 2012 (UTC)

Reference number for length and existence

This is a real minor and not a technical problem, but it's something that makes the infobox look weird. Length is listed first and existence second, but when the references for each are listed in the infobox, reference #1 (or the first of the two) is listed under existence and reference #2 is on the length. See example here: U.S. Route 221 in Florida

There's probably something deep in the caverns of code for the Infobox Road where existence is listed before length_ref so if someone could find that, that would make the world an ever-so-slightly better place. But again, this isn't something that's completely messing it up, so if you're prioritizing actual broken code, by all means do that first. 1980s barroom show! —Mr. Matté (Talk/Contrib) 21:42, 8 January 2013 (UTC)

yes, this is fixable. the problem is that the heading for that section contains {{#if: ...{{{established|}}} ...|Route information}}, but there is no {{{length_ref|}}} in that check. of course, there shouldn't be any length_ref in that check, but that means that your ref tag in the established field comes first, so it is numbered first. an easy way to fix this would be to stick a dummy {{#if: {{{length_ref|}}} | }} before the {{{established|}}} in the header check. Frietjes (talk) 22:18, 8 January 2013 (UTC)
note that this hack shows that a fix is possible. please, don't fix it this way, but this demonstrates that we can fix it with a dummy #if in the header check. Frietjes (talk) 22:22, 8 January 2013 (UTC)
Frietjes is right. There is no length_ref in the header check because the ref is useless if there is no length to reference. We could add {{#if:{{{length_mi|}}}{{{length_km|}}}|{{{length_ref|}}}|}}} before {{{established}}}. Another, probably more radical solution (but simpler), would be to reorder the lines so establishment comes first. –Fredddie 22:39, 8 January 2013 (UTC)
The references should not be in he infobox; they should be in the body of the article, which the infobox is intended to summarise. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:58, 8 January 2013 (UTC)
No; for example, Psittacosaurus which was TFA a few days ago. Furthermore, this could result in violations of BLP. --Rschen7754 23:05, 8 January 2013 (UTC)
Leaving aside that Psittacosaurus is not a road; and that roads are not living people, this is nonsense. There is no requirement that a fact be referenced more than once, to the same source. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:33, 8 January 2013 (UTC)
(edit conflict) BLP is kind of a red herring when it comes to roads. Both times I've been to FAC, I've never had infobox references come up as an issue and I think others who have taken a road to FAC would say the same. –Fredddie 23:35, 8 January 2013 (UTC)
My point is that if articles that are in other subject areas are not required to conform to this, there is no reason why road articles should be required to either. --Rschen7754 23:37, 8 January 2013 (UTC)
My initial comment applies to all infoboxes. Such referencing is not a BLP requirement, and the FA reviewers are not the final arbiters of how Wikipedia works; this is but one example of where their understanding is deficient or their interest lacking. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:04, 9 January 2013 (UTC)

Spain autonomous communites

I'd like to propose the following:

Replace:

|label63=Regions:

With:

|label63={{#ifeq:{{{country|}}}|ESP|Autonomous<br>communities:|Regions:}}

Autonomous communities are the official names for the regions of Spain. –Fredddie 05:49, 15 January 2013 (UTC)

The infobox in Dhaka–Chittagong Highway has a link to None. Since None is a disambiguation page, could someone with experience with this infobox please change it so it does not link to the disambiguation page? Thanks! GoingBatty (talk) 03:59, 6 February 2013 (UTC)

Generally, the next/previous links are like a big circle, so at the first article (N1) you want to link to the last article (N809). See U.S. Route 1 in Florida for an example of what I mean. It should also work the other way, too. N809 should link to N1. Since N809 doesn't exist currently, I linked it to N8, which does exist. –Fredddie 04:10, 6 February 2013 (UTC)
Thanks! GoingBatty (talk) 04:20, 6 February 2013 (UTC)

Error on Australian road

I just added a photo to the infobox on Western Freeway, Brisbane and couldn't fix a display error that creates a redlinked x70px presumably instead of a route number image. Does something need fixing or renaming? - Shiftchange (talk) 12:55, 8 February 2013 (UTC)

Fixed with this. -- WOSlinker (talk) 13:31, 8 February 2013 (UTC)

Belarusian route signs

Can someone modify this template to include Belarusian magistral routes signs?

There are currently all magistral routes signs and 20 regional routes signs (temporary, I'll upload the rest in the future) on Commons. You can find on category Diagrams of route signs of Belarus.

Mkmk101 (talk) 01:38, 2 March 2013 (UTC)

  Done by editing {{Infobox road/shieldmain/BLR}} to point to the graphics. Imzadi 1979  02:54, 2 March 2013 (UTC)

Australian States

Why are we using two letter abbreviations for Australian states? Im australian and I wouldnt know what abbreviations are to be used.

The standard abbreviations for the mainland states and territories (and Tasmania) are as follows:

  • NSW - New South Wales
  • VIC - Victoria
  • QLD - Queensland
  • SA - South Australia
  • WA - Western Australia
  • TAS - Tasmania
  • ACT - Australian Capital Territory
  • NT - Northern Territory
  • JBT - Jarvis Bay Territory


Can someone convert to 3 letter abbreviations please? - Nbound (talk) 01:25, 21 April 2013 (UTC)

Where are you seeing this? I looked through the Australian-specific subtemplates (see Template:Infobox road/doc/country) and the only one that used all of the states (browselinks) had them listed as you do above. Queensland was the most common state I found in the others, and it was abbreviated correctly as well. –Fredddie 01:30, 21 April 2013 (UTC)
Well the domcumentation for the standard template is incorrect then, see the country section: "Australian state: the two-letter abbreviation of the state. Note: |country=AUS must also be set if the state is NT or WA to avoid conflicts with other countries." - Nbound (talk) 01:49, 21 April 2013 (UTC)
  FixedFredddie 01:51, 21 April 2013 (UTC)
Thanks :) - Nbound (talk) 01:54, 21 April 2013 (UTC)

Edit request on 30 April 2013

Please synchronize Template:Infobox road/sandbox to this template per Wikipedia talk:WikiProject Australian Roads#Implementation. This will allow us to move forward with consolidation of the last stand-alone infobox template in the future.

Imzadi 1979  08:13, 30 April 2013 (UTC)

  Done --Rschen7754 08:16, 30 April 2013 (UTC)

Core template proposal

I would like to propose that we switch this infobox from its current codebase to a core/wrapper system similar to the one used by {{Jctint}} and its variants. The outward benefit is that any customization could be done at the local level (by country) instead of cramming the main template full (see Template:Infobox road/doc#Location for something that could be optimized). Labels and parameter names could be customized to suit the locality rather than shoehorning the locality to the parameter. The downside would be that we would basically undo the consolidation of templates we went through a couple years ago. –Fredddie 01:28, 19 May 2013 (UTC)

I should add that I don't wish to change the exterior appearance at all. –Fredddie 01:29, 19 May 2013 (UTC)
I can see spinning out the location stuff as subtemplate to simplify the main template, but I can't see duplicating the rest of the template that is pretty stable across national boundaries. Therefore, I oppose this concept except in a limited fashion as it relates to the location parameters only. Imzadi 1979  01:37, 19 May 2013 (UTC)
Let's wait to do anything along these lines. Infobox road is probably going to see a massive upheaval in the coming months due to Wikidata Phase Two (the beginnings of which are underway now; you're just not seeing it hit USRD yet because infobox road relies heavily on datatypes that Wikidata doesn't yet support, like numbers and dates). This may well result in being rewritten in Lua. In the meantime, jct itself is being rewritten in Lua; a lot of the type/abbreviation/text type stuff from that rewrite may be reusable in infobox road. So let's wait and see what all of that gives us, and make a decision as to the desired structure of infobox road once we know more of what it's going to look like. —Scott5114 [EXACT CHANGE ONLY] 08:52, 19 May 2013 (UTC)
I'd have to concur with Scott. I personally don't think that the benefits of such a transition would outweigh the cost of rewriting everything at this time. --Rschen7754 08:57, 19 May 2013 (UTC)

Use Wikidata for map field

I would like to propose changing the map= field to call Wikidata. Happy5214 has implemented a solution at simple:Module:Infobox road using Lua, and I think it works well. Here is how it works:

  1. If map_custom= is present, we use that code entirely.
  2. If map= is present, we use that file.
  3. If neither is present, we use the first map file that is listed on Wikidata. (The bug where we had issues with multiple maps being specified on the Wikidata item is avoided if we use Lua).

I think this would be good to see how Wikidata will work for us. We will have to remove map= from articles progressively in order to see the results, but this will be helpful for roads in countries where the native language is not English. Any thoughts? --Rschen7754 00:04, 26 May 2013 (UTC)

How confident are you that it will work? –Fredddie 00:51, 26 May 2013 (UTC)
It has worked at Simple English Wikipedia so far. --Rschen7754 01:23, 26 May 2013 (UTC)
  • I support this proposal. TCN7JM 04:59, 26 May 2013 (UTC)
  • Support. Full speed ahead. As the next step, I would also advocate implementing counties using the "is in the administrative unit" property (see Oklahoma turnpike items on Wikidata as an example). —Scott5114 [EXACT CHANGE ONLY] 06:50, 26 May 2013 (UTC)
  • Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:50, 26 May 2013 (UTC)
  • Support. If it works like you say it does, I'm all for it. Then, instead of adding WD stuff bit by bit, we can just rewrite the template for WD. –Fredddie 21:37, 26 May 2013 (UTC)
    • Yeah, we really need to rewrite the template at least in Lua rather than incrementally adding fields. We had to do some sketchy stuff on Simple when I discovered a bug, and we'd be really shooting ourselves in the foot to incrementally add fields one by one since we'd have to keep reworking the logic. We don't have to make the Lua version call Wikidata for everything right away (since there's properties missing). And I see no reason why we can't go ahead with the map= deployment since that's already coded, and because we need to get a broader sense of how this will work than our testing on Simple. --Rschen7754 10:00, 28 May 2013 (UTC)

We're scheduling the deployment for Saturday night/early Sunday morning. We've tested it on Simple, but there just aren't as many testcases out there as there are here. So we will load the code and then check as many pages as possible to make sure that nothing's broken. If something broke please report it on IRC or here ASAP, and we will try to fix the code or revert the deployment entirely and try again later. --Rschen7754 10:36, 30 May 2013 (UTC)

Deployment has now happened, please check for errors. --Rschen7754 05:45, 2 June 2013 (UTC)

Where to go next

Well, the deployment appears to be successful. But where do we go next? I assume that we will want to continue using {{Infobox}} for consistency with the other Wikipedia infoboxes, which will still allow us to add things bit by bit and not risk getting bogged down in a massive rewrite with no deliverable to motivate us until the end. But if we do this, I fear that we may hit the Lua call limit a lot sooner than we want (remember, {{Jctint}} and {{Jct}} will all be switched over soon).

I'm also not entirely sure that going ahead with "is in the administrative unit" is the best idea for a next step for 2 reasons: 1) the property isn't entirely stable and just survived a TFD, and isn't widely in use, and 2) we would need to convert "Abc County" to "Abc" for proper display in the infobox.

Thoughts? --Rschen7754 06:50, 2 June 2013 (UTC)

For now, I'd stick to implementing items that apply to the whole road, like the agency that maintains it, the length, etc. Imzadi 1979  06:54, 2 June 2013 (UTC)
I think you mean a PFD. :P I think "is in the administrative unit" is a decent choice for the next step, although we may want to wait until queries are available so we can make certain that we are only selecting administrative units that are indeed counties (in case some oaf comes through and besmirches the property with cities or states). The display issue would be a simple pattern-matching exercise—relatively straightforward if it were in Perl, but I don't know what facilities Lua provides for text processing. Unfortunately we can't do length yet because Wikidata doesn't support numeric data yet (only item links and dates for now). Maybe we should do established/decommissioned dates next? —Scott5114 [EXACT CHANGE ONLY] 07:39, 2 June 2013 (UTC)
Shields may be a possibility, though it would take a bit more coding. Unfortunately, we don't have any date properties set up yet, though we should get that going soon. --Rschen7754 07:41, 2 June 2013 (UTC)
Looks like we can use generic start date/end date. Information has been added to the typical properties page on Wikidata for those interested. —Scott5114 [EXACT CHANGE ONLY] 09:48, 2 June 2013 (UTC)

Rewrite

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:01, 21 June 2013 (UTC)

Edit request

This is an edit request in response to an issue I raised at D21 road (Croatia)'s A-Class Review.

Please replace this line:

|data3  = {{#if:{{{e-road|}}}{{{ahn|}}}{{{tahn|}}}|Part of {{{e-road|}}}{{{ahn|}}}{{{tahn|}}}|}}

with

|data3  = {{#if:{{{e-road|}}}{{{ahn|}}}{{{tahn|}}}|{{{e-road-shield|}}}{{{ahn-shield|}}}{{{tahn-shield|}}} Part of {{{e-road|}}}{{{ahn|}}}{{{tahn|}}}|}}

This will allow shields images to appear at the beginning of the line, instead of in the middle, per the principle behind Wikipedia:Manual of Style/Icons#Do_not_use_icons_in_general_article_prose: "Icons should not be used in the article body...This breaks up the continuity of the text, distracting the reader." - Evad37 (talk) 02:22, 22 June 2013 (UTC)

My only concern is that an AWB run would be in order to fix all the instances of the e-road family. Otherwise looks good. –Fredddie 02:43, 22 June 2013 (UTC)
That is true, but if I read this right it shouldn't cause problems in the meantime. Doing. --Rschen7754 03:24, 22 June 2013 (UTC)
  Done --Rschen7754 03:25, 22 June 2013 (UTC)

Transclusions of Infobox_road/translation/USA

As of June 2013, there are around 11000 articles testing for the existence of the (missing) sub-template Template:Infobox_road/translation/USA. My understanding of the code may be flawed, but I'm not sure this is by design. Can an expert confirm? If it's correct, we should probably protect the title. - TB (talk) 12:57, 26 June 2013 (UTC)

It is by design, though not a very good one. {{Infobox road/translation/...}} is designed to display the native name of a road, based on the country. Obviously, this is not needed for the U.S., or Canada, or the U.K., etc. That's something I'll look into as part of my upcoming rewrite. Thank you for bringing this to my attention. -happy5214 12:48, 27 June 2013 (UTC)
Protected per the above. --Rschen7754 16:23, 27 June 2013 (UTC)

{{{header_color}}}

The {{{header_color}}} parameter is being proposed for removal. According to Category:Infobox road temporary tracking category 1, this parameter is currently unused. Removal of this parameter is requested in order to streamline future code. If no objections are raised, this parameter will be removed 2 days after this post. Thank you. -happy5214 09:30, 1 July 2013 (UTC)

Could you briefly explain what the parameter actually does, and why it's functionality is no longer required? - Evad37 (talk) 10:19, 1 July 2013 (UTC)
It bypasses the header_type= mechanism and allows us to set the color to blue directly, for example. But it doesn't seem to be used, so we're wondering if it can be eliminated. --Rschen7754 10:20, 1 July 2013 (UTC)
Okay, thanks for that. No problem with removing it. - Evad37 (talk) 10:37, 1 July 2013 (UTC)
I think, pretty much, that it was a hold over from the days when we were initially upgrading the template and first implemented the idea of colored headers. It allowed us to test additional color combinations before we settled on the existing schemes. That said, its usefulness is pretty much gone now, so remove the parameter at the earliest convenience. Imzadi 1979  19:23, 1 July 2013 (UTC)
  Done -happy5214 08:08, 4 July 2013 (UTC)

Header colors for former routes

I've noticed on a few Nevada articles that Infobox Road is not switching the header colors to "former" status for former routes. See Nevada State Route 2B & Nevada State Route 511, among others. I thought it was set up so that if a former/decommissioned date is specified, the headers would switch to the former colors automatically without having to add |header_type=former. -- LJ  19:06, 3 July 2013 (UTC)

You're right, it was, but the headers were recently converted to Lua, so it's probably something @Happy5214: can fix. –Fredddie 22:53, 3 July 2013 (UTC)
  Fixed -happy5214 08:08, 4 July 2013 (UTC)
Thanks! -- LJ  09:19, 4 July 2013 (UTC)

Question about Templatedata

When we're all done adding all the parameters to Templatedata, are we going to get rid of the Parameters section right above it? It seems like we could merge all the relevant information from the section into the Templatedata table. –Fredddie 14:09, 18 July 2013 (UTC)

I actually prefer the Parameters section, because you can use lists, bullets, linebreaks, formatting, wikilinks, tables, etc, and it is easier to show which parameters are dependant on other parameters, and have separate sections for different use cases (eg the numbered roads section). However, TemplateData is needed to make the VisualEditor template editor work properly/more easily, and it's output on the documentation page is easy to hide with the collapse templates. (It is probably even possible to stop the output on the documentation page from displaying at all, though I think collapsing it is probably the more sensible option) - Evad37 (talk) 14:49, 18 July 2013 (UTC)
For the record, I think we have most if not all of the parameters done now. --Rschen7754 18:45, 18 July 2013 (UTC)

Mi/km issue

Noticed an issue with non-US highways such as Mexican_Federal_Highway_1. The length of the highway listed in km is being converted into miles but the conversion is going the wrong way. For instance MFH1's length of 1711 km is being converted to 2754 mi in the infobox... which is obviously wrong as it should be 1063.17 mi. I've noticed the same problem with Canadian highways. Gateman1997 (talk) 18:35, 24 August 2013 (UTC)

@Happy5214:
A fix was made a few nights ago that seems to have introduced this error as a side effect. I've reverted it on an emergency basis while this gets fixed. --Rschen7754 18:38, 24 August 2013 (UTC)
  Fixed I accidentally put * instead of / in the conversion. -happy5214 06:31, 25 August 2013 (UTC)

Additional historical designations

I was thinking about adding a parameter so we can embed a historical designation infobox like {{Designation list}}, {{Infobox World Heritage Site}} and {{Infobox NRHP}}. For examples, see the Brooklyn Bridge and Golden Gate Bridge articles, where a historical designation infobox is embedded via the "extra" parameter of {{Infobox bridge}}. The issue is that only a segment of a road may be designated as historical, so I may have to add another parameter specifying this, similar to the current "allocation" parameter here (or alternatively basically use, for example, one of the freename parameters in {{Designation list}}). Zzyzx11 (talk) 15:36, 18 August 2013 (UTC)

I'm unarchiving this, and objecting at the moment. The location chosen to embed the box breaks up the continuity by inserting it ahead of the highway system and other "closing" information in the current box. Either embed it at the end, or please don't. Imzadi 1979  10:35, 22 September 2013 (UTC)
  Done. This required converting the "below" {{Infobox}} parameter, used for the browsing and linking section and other closing information, to a normal data parameter. Zzyzx11 (talk) 16:55, 22 September 2013 (UTC)

Laos

Can someone fix Route 13 (Laos)? thank you. 174.56.57.138 (talk) 14:48, 20 October 2013 (UTC)

Nothing was set up for the country, so I created some subtemplates in a minimalist style. Imzadi 1979  15:02, 20 October 2013 (UTC)

GBR maps not working

I recently renamed "M2 motorway (Great Britain)" to "M2 motorway (England)" for some consistency since the Scottish motorways use "(Scotland)" in the article name, but this has removed the map, and there's no way for me to fix it because this template can't be edited. This also applies to motorways that have "(Scotland)" in the article name; see M8 motorway, Northern Ireland seems to work fine though. Someone fix this please. Anarchistdy (talk) 16:52, 18 December 2013 (UTC)

I'm guessing Scotland and England and Ireland each have their own numerical designations? If so then yes this should be changed.... However, if the main island, at least, share their designations across borders, then they should all be moved to MX motorway (Great Britain). - Floydian τ ¢ 16:56, 18 December 2013 (UTC)

Template-protected edit request on 18 December 2013

I recently renamed "M2 motorway (Great Britain)" to "M2 motorway (England)" for some consistency since the Scottish motorways use "(Scotland)" in the article name, but this has removed the map, and there's no way for me to fix it because this template can't be edited. This also applies to motorways that have "(Scotland)" in the article name; see M8 motorway; Northern Ireland seems to work fine though. Anarchistdy (talk) 16:57, 18 December 2013 (UTC)

This isn't an issue with Infobox road. Instead, you forgot to update the associated Wikidata item, which provides the map, to reflect the new article name. I have fixed M2 for you. -happy5214 17:03, 18 December 2013 (UTC)
And here is the diff. -- WOSlinker (talk) 17:04, 18 December 2013 (UTC)
Okay, thanks for the help. Anarchistdy (talk) 17:08, 18 December 2013 (UTC)

Just a heads up that I've reverted the move (and changed the Wikidata item back) as it's going against the established naming conventions for the UK motorways. Jeni (talk) 16:06, 19 December 2013 (UTC)

Possible missing parameter checks

I noticed while working on an unrelated task that there are 99 links to each of {{Infobox_road/maint/}} and {{Infobox_road/translation/}}. I'm pretty sure these represent both 99 instances of this template being used with a required parameter omitted, and two areas of the template that are failing to check properly for an omitted parameter. Posting here in case anyone wants to check; I got about 30 seconds into the template markup before deciding it wasn't a job for me :) - TB (talk) 16:34, 27 December 2013 (UTC)

Those links are actually the results of #ifexist tests in the code. I'll try to remember to fix those when I'm writing the new Lua versions. -happy5214 10:01, 28 December 2013 (UTC)
Cheers. I did see they were from #ifexist tests, my main concern that it was using an input value that hadn't been sufficiently sanitised. I've not ventured into the world of LUA yet, but understand it's far better at encouraging such good practice. - TB (talk) 11:47, 28 December 2013 (UTC)

Template-protected edit request on 26 December 2013

Can a collapsible option be added to the "Major Junctions" section? Thanks. Atotalstranger (talk) 07:56, 26 December 2013 (UTC)

Why? When would this be needed? If the junction list is too long, the normal solution is to cut it down to just the most important junctions for the infobox (a more complete list can/should be included in the appropriate section of the article). - Evad37 [talk] 08:04, 26 December 2013 (UTC)
Agreed, the issue isn't with the template, it's with specific usages. Imzadi 1979  08:21, 26 December 2013 (UTC)
It seems to be an issue with ALL British roads, there seems to be 20 or more junctions listed for every AXX road. And I don't have time to go through every road and find out which junctions are the most notable. Some of them aren't even junctions, look at the A1 for example, someone has all the major motorways that start at London, even if it isn't a junction of the A1. Atotalstranger (talk) 23:05, 26 December 2013 (UTC)
Just to be clear, I'm asking for an optional collapsible option that can be added. Not for all roads. Atotalstranger (talk) 23:11, 26 December 2013 (UTC)
They are not supposed to have 20 junctions in the infobox. The infobox is supposed to be a summary of the route. --Rschen7754 23:12, 26 December 2013 (UTC)
Concur with the above. Also, you need to get consensus before you make the editprotected request. --Rschen7754 14:55, 26 December 2013 (UTC)
Concur. The infobox should only list a handful of major junctions, and not appear that it is merely listing every single road that has a Wikipedia article. Zzyzx11 (talk) 21:18, 28 December 2013 (UTC)

Status parameter

I would like to propose a new "Status" parameter in the Route information section. This would be useful for routes that are not yet open or planned routes that were never built. For an article like Southern Indiana Toll Road, I think it would be nice to add "Status: Never built" beneath the length line. It could even be possible to turn off the parameter under normal circumstances; that is, only allow its use when the headers are orange or gray. –Fredddie 01:19, 12 February 2014 (UTC)

+1. Adding to the sandbox in a moment... Imzadi 1979  01:27, 12 February 2014 (UTC)
Strike that, just added it to the live template since it's relatively noncontroversial and it was an easy addition. If the |header_type= isn't set to under construction/UC/uc/const/historic/hist/historical/scenic/former/decommissioned, the parameter won't work. I will add it to the doc file in a bit. Imzadi 1979  01:33, 12 February 2014 (UTC) The orange, brown and gray colors will work since under construction, former and historical all seem appropriate to have a status indicated. Imzadi 1979  01:37, 12 February 2014 (UTC)
You forgot to add the parameter to the switch that triggers the Route information header. Easy fix, though. –Fredddie 01:59, 12 February 2014 (UTC)

Major junctions

This heading was removed from single-segment routes, but still appears on multi-segment routes (e.g. Florida State Road 2). --NE2 17:38, 18 February 2014 (UTC)

On single-segment highways, like Florida State Road 3, the wording appears in the colored header above the list. For multi-segment highways, the names of the segments appear there, so the text was moved to the side. Imzadi 1979  19:58, 18 February 2014 (UTC)

I-280 marker images

Why is the infobox for I-280 for California correctly show the marker image with the state name, but for New Jersey, the default marker image does not show the state name? This is contrary to the actual road signs in New Jersey which use the shield marker with state name on top of the number. Is there a way we can change that to default to File:I-280_(NJ).svg to reflect the reality? Z22 (talk) 21:35, 6 April 2014 (UTC)

If you can show that all or most of the interstate shields in New Jersey show the state name, I will gladly change it. –Fredddie 22:56, 6 April 2014 (UTC)
Actually, most of interstate shields in NJ are without state name. However, the shields for the following two interstates have state name:
Please note that these two interstates are the only auxiliary routes in New Jersey that are completely within New Jersey. Also note that road signs may be continuously updated. The old shields from the image captured by Google in August 2009 at the exit 1 of I-280 still uses the one without state name [7], at the same exit on the other side of the street that Google had a new drive around in August 2013, the road sign already have the shield with state name [8] Z22 (talk) 02:49, 7 April 2014 (UTC)
Since this is relatively new for the come back that the interstate shields in NJ now have state name (after the state name has been dropped since the 1980's), I think it is only fair to change the marker images only on the specific routes that have the road signs consistently use the shield with state name in most if not all exits. Here to show that I-195 and I-280 have shield with state name in most exits, not just the first three:
These references are for I-195, continued from the above: [9], [10], [11], [12], [13], [14], [15]
These references are the continuation for I-280 (exit 1, 5 and 6) that I mentioned in the above (also here is exit 4 with 2013 image date). Here are other exits: exit 7, exit 8, Google has old image date for exit 9, exit 10, exit 11, exit 12, exit 13, exit 14, exit 15, exit 16. Z22 (talk) 05:29, 7 April 2014 (UTC)
  Done for the whole state. If you see any New Jersey Interstates that do not use the state-name variant, make sure they are using |type=I instead of |type=Interstate. –Fredddie 01:32, 14 April 2014 (UTC)

Template-protected edit request on 10 April 2014

For Arab Mashreq International Road Network, please make the following edit:
|data3 =
Nima Farid (talk) 08:27, 10 April 2014 (UTC)

Done, as it is very uncontroversial Imzadi 1979  08:31, 10 April 2014 (UTC)

Displaying country and state/province by default

I'd like to propose that in the Location section, right above where we add counties/parishes/municipalities of all kinds/etc., that we automatically display the country and state/province. I will begin working on the sandbox to show what I am proposing.Fredddie 22:56, 4 May 2014 (UTC)

I did not realize how much of IBR was already on Lua, so my hands are tied. However, I can do a mockup of Iowa Highway 98.
I like the idea in general, since it globalizes things that extra little bit for our international readership. As a matter of implementing it in the US, I would then encourage our editors to make sure the list of counties/etc are added. One other implementation detail, |states= should override whatever might be automated if necessary. Imzadi 1979  23:30, 4 May 2014 (UTC)
I support this idea, but we need to find a way for it to work for multi-state routes. I would include the country, state, and counties for state routes along with state-detail pages or national-detail pages that do not have state-detail pages for Interstate and U.S. Routes. For national-detail Interstate and U.S. Route articles that are subdivided into state-detail pages I would only include the country and state as listing every county could get cumbersome, especially for a cross-country highway. Dough4872 02:12, 9 May 2014 (UTC)
Another note, in the mockup I would not include "County" after the name of each county as it is superfluous to the heading of the parameter and it takes up space. Dough4872 02:14, 9 May 2014 (UTC)
Duh. That was my error. –Fredddie 03:05, 9 May 2014 (UTC)
I'm not that big of a fan of this idea. It seems slightly redundant when the state name already appears as part of the highway name (for state route articles). This also adds more vertical length to the infobox--I typically don't even include the counties in the infobox of shorter articles for this reason (especially when the route is in only one county). I can see the case for the national articles on Interstates, U.S. Routes, auto trails, etc. and select combined routes though. Maybe if country/state wasn't turned on by default, or turning these on could be overridden? Just my thoughts. -- LJ  02:44, 9 May 2014 (UTC)
If you do do this, move the maintenance parameter. It's a little insulting to first read the road is maintained by the Iowa Department of Transportation to then 3 inches down learn the road is in (drumroll please) Iowa!. =-) 18:35, 9 May 2014 (UTC)
Interesting idea, Dave. I adjusted the mockup to put the location first, just to try it out. –Fredddie 22:03, 9 May 2014 (UTC)
I can see the sense of moving the locations up as it gives the basic geographical context of the route first before delving into the specifics. Dough4872 01:27, 10 May 2014 (UTC)
The new mockup looks reasonable and logical. I don't think it is too long. Z22 (talk) 02:10, 10 May 2014 (UTC)
Fredddie, I think the organization flows a lot better now. Dave (talk) 20:28, 12 May 2014 (UTC)

Mockup

Infobox road location mockup
Current Mockup
Iowa Highway 98
 
Route information
Maintained by Iowa DOT
Length1.814 mi[1] (2.919 km)
Existed1944[2]–present
Major junctions
South end  CR V64 in Leando
North end   Iowa 16 / CR V64 north of Douds
Location
CountryUnited States
StateIowa
CountiesVan Buren
Highway system
 
Iowa Highway 98
 
Location
Country:United States
States:Iowa
Counties:Van Buren
Route information
Maintained by Iowa DOT
Length:1.814 mi (2.919 km)
Existed:1944 – present
Major junctions
South end:  CR V64 in Leando
North end:   Iowa 16 / CR V64 north of Douds
Highway system

References

  1. ^ 2011 Volume of Traffic on the Primary Road System of Iowa (PDF) (Report). Iowa Department of Transportation. January 1, 2011. Retrieved January 24, 2013.
  2. ^ Cite error: The named reference DOT1945 was invoked but never defined (see the help page).

U.S. Bicycle Routes

I'd like to switch the articles on U.S. Bicycle Routes to use this template. USBRs are national-level, long-distance bicycle routes that commonly follow roads. For example, USBR 76 is almost entirely on-road. Some of the USBR articles are currently using {{Infobox street}}, which is meant for hyperlocal features like town squares and city streets. I think {{Infobox road}} would be a more natural fit, because these routes are intended to be analogous to U.S. Routes and are maintained by the same transportation departments. A couple helper modules would need to be modified to support USBRs: Module:Infobox road/abbrev/USA and {{Infobox road/shield/USA}} (currently using {{Infobox road/shieldmain/USA}} as a fallback). To be clear, most bike trails would continue to use {{Infobox hiking trail}}. Does this sound reasonable? – Minh Nguyễn (talk, contribs) 03:23, 9 June 2014 (UTC)

It would seem to me that they all should be using the trail infobox, not this one. Imzadi 1979  03:34, 9 June 2014 (UTC)
Well these bike routes are not necessarily trails as many of them follow regular automobile roads. In addition, the hiking trail infobox doesn't have the necessary provisions to handle numbered routes like Infobox road does. Therefore, I say the U.S. Bike Routes should use infobox road as that has the necessary provisions to handle numbered routes (even if it is a bike route and not an automobile route), unless the hiking trail infobox can be modified to properly handle the U.S. Bike Routes or even if a new infobox type modeled off Infobox road is created for the U.S. Bike Routes. Dough4872 03:55, 9 June 2014 (UTC)

Is there a way disambiguation can be added for spurs?

In adding the spur function to Interstate 676, which is a multi-state highway, the spur function links to the dab page Interstate 76. Is there a way to add a function so it can link to Interstate 76 (east) but the link can still be displayed as I-76? Dough4872 21:30, 1 January 2015 (UTC)

Not at this point, but I can add it in the rewrite. The problem is finding a parameter with which to pass it through to the parser. -happy5214 00:24, 2 January 2015 (UTC)

Wrong shield

I don't know what needs fixing, but U.S. Route 70 City (Benton, Arkansas) should have a US 70C shield. --NE2 02:50, 4 February 2015 (UTC)

  Done Imzadi 1979  06:02, 5 February 2015 (UTC)

Template {{jct}} versus "Route XX in U.S. state" article naming problem

I'm not sure where to bring this up, so I'll just bring it up here. I've noticed that the {{jct|state=XX}} syntax in this template produces a "Route XX (U.S. state)" wikilink in the infobox. Some articles, though, are using a "Route XX in U.S. state" article naming format instead. It'd be nice to be able to deal with this article naming discrepancy without resorting to redirects. Just a thought. Bumm13 (talk) 00:25, 6 February 2015 (UTC)

Why would it be nice? There's nothing wrong with redirects. --NE2 00:29, 6 February 2015 (UTC)

Mexican state highway problem

Nuevo Leon State Highway 1 Spur auto-generates "Maintained by Secretariat of Communications and Transportation". --NE2 22:33, 6 February 2015 (UTC)

I blame this edit. All Mexican instances of IBR show this now. Great. –Fredddie 00:07, 7 February 2015 (UTC)
I've blanked it for now, not knowing which if any arguments are passed through. --NE2 00:11, 7 February 2015 (UTC)

Spur/auxiliary roads for the rest of the world

Hey guys, it would be awesome if Template:Infobox road/meta/mask/country could be adapted so it doesn't disallow roads outside of the US, Canada, Mexico and Australia to be assigned as spur road of another road. In the current case, I'd like to assign Greek Motorway 581 (Greece) as a spur road, but am not able to. Same case would hold for a number of roads all over Europe and worldwide. Wherever states and provinces are irrelevant for the highway numbering plan, they shouldn't be required either. Thanks, --PanchoS (talk) 22:32, 18 February 2015 (UTC)

I understand what you're saying, but your fault in the country mask is misplaced. All that template does is allows those of us in the US, for example, to skip typing |country=USA. –Fredddie 22:38, 18 February 2015 (UTC)
It works as directed in this example –Fredddie 22:42, 18 February 2015 (UTC)
A11 motorway
Αυτοκινητόδρομος 11
Route information
Auxiliary route of A 1
Location
CountryGreece
Highway system
  • Highways in Greece
@PanchoS: you didn't add the |spur_type= parameter to the infobox on that article. I did, and the line displays correctly in the article now. Imzadi 1979  00:22, 19 February 2015 (UTC)

Reversion to the embedded parameter

I reverted the change made earlier today by Alakzi because the change to embed another infobox as a header had unintended consequences. Namely, when viewed on Arroyo Seco Parkway, the change inserted a blank header bar (in that case rendered as a thin, dark-green line) between the main infobox and the embedded content. Also, I don't think the change does what is intended as it would semantically render the entire content of the embedded infobox as a header, when the embedded box should be semantically rendering its own headers, labels and data separately. Imzadi 1979  22:07, 14 May 2015 (UTC)

(a) Do not press "vandalism" in Twinkle if you're not reverting a vandal edit. (b) You're confused about how embedding works. When embedded infoboxes begin with a new row, an empty (header) row is inserted. My edit did not change the layout of the infobox, nor did it make any semantic difference to NRHP; however, it insured that {{Infobox designation list}}'s title is rendered inside a header cell, as it should. Alakzi (talk) 22:13, 14 May 2015 (UTC)
I thought that I had clicked the "Undo" link, not a Twinkle link, so classifying it that way was not intentional. Yes, your edit did change the layout of how the infobox was presented in articles. If you look at File:Infobox road before and after 14 May 2015-01.png, you'll see a before (left) and after (right) presentation of how the infobox looked in Arroyo Seco Parkway. The version on the right reflects the infobox change you made, and it added a blank header, in this case a thin, dark-green line as I noted above. Imzadi 1979  05:04, 15 May 2015 (UTC)
I know that it changed the presentation slightly; that is because {{Infobox NRHP}} is abusing the modular design of {{Infobox}}. Whereas, previously, an empty <td> would be inserted, that was changed to a <th>. Before, we got an extra bit of spacing; now, we get a little dividing line. Is one better than the other? Debatable. ... as I noted above. You also noted a whole lot of other stuff that did not hold any ground. Alakzi (talk) 10:12, 15 May 2015 (UTC)

Any controversial change on an infobox used on over 10,000 pages must be discussed before making it. I find it concerning that a template editor made this change without discussion. --Rschen7754 05:06, 15 May 2015 (UTC)

This user has also changed several other infobox templates in a similar fashion. This has also caused a thin line in the same location when using Template:Infobox NRHP, although not as noticeable due to the color. Template:Infobox designation list is not the only one that is embedded in these templates. Zzyzx11 (talk) 09:52, 15 May 2015 (UTC)
If you'd like have me stripped of TE, begin a discussion wherever appropriate. In the meantime, do not comment on the editor. Alakzi (talk) 11:14, 15 May 2015 (UTC)
What? I would certainly hope that concerns about your use of TE could be addressed without having to resort to removal, by open conversation. --Rschen7754 14:00, 15 May 2015 (UTC)
It should be an indicator of how serious I believe this particular concern to be. Alakzi (talk) 14:08, 15 May 2015 (UTC)

Wikidata

I've just been adding a bit of wikidata and was wanted to see if there's anything more to add so just wondering if anyone minds if I add a few temporary tracking categories to the template? -- WOSlinker (talk) 21:07, 16 May 2015 (UTC)

{{#if:{{#property:P154}}|[[Category:Infobox road articles with wikidata logo image]]}}<!-- These should be highway marker instead -->
{{#ifeq:{{#property:P17}}||[[Category:Infobox road articles without wikidata country]]}}
{{#ifeq:{{#property:P31}}||[[Category:Infobox road articles without wikidata instance of]]}<!--generally these should be road, but just checking that there is something in that attribute for now -->
I added one myself the other day, so I have no issue with a few more. –Fredddie 00:10, 17 May 2015 (UTC)
We have a highway shield property, which is P14. --Rschen7754 00:14, 17 May 2015 (UTC)
@WOSlinker: --Rschen7754 05:44, 17 May 2015 (UTC)
@Rschen7754: I've aded the tracking cats now. Category:Infobox road articles with wikidata logo image will be useful to find pages that need the logo image moving to highway shield. -- WOSlinker (talk) 05:45, 17 May 2015 (UTC)
Oh, I misread it the first time... my bad. --Rschen7754 05:46, 17 May 2015 (UTC)

Very TOP sign image

Sorry to see the differences above; however I would like to know why I see a {{{1}}} in the highway sign at the TOP of this ibox in the National Highway 24 (India)(old numbering) article and its associated articles as linked to at the BOTTOM of the ibox? Is this a recent change? and please fix if you can! – Paine  15:16, 16 May 2015 (UTC)

There was a subtemplate, the entire list of which is here Template:Infobox road/doc/country, where the route number (24) was not correctly passed through. Aside from the left-alignment, it's fixed. –Fredddie 15:20, 16 May 2015 (UTC)
Ah! Fredddie, I hoped that there would be someone around who was familiar with this template and all its subs. Thank you! and Best of everything to you and yours! – Paine  15:29, 16 May 2015 (UTC)
@Paine Ellsworth: a lot of the issues related to the templates like this one for articles on India's highways stem from a simple fact. No one has bothered to create a full set of actual highway marker graphics. Instead, someone discovered the "neat" trick that you can superimpose text above a blank shield graphic. Yeah, it works, but the font is never right, and there are usually alignment issues. The best solution would be a bit time-consuming, but simple.
If someone could create a list of which numbers are, or have been, in use, and if someone could point us to a photograph or other example of how the markers look in real life, some of us could create a template for the creation of graphics. We could either have the one bot make them, or we could divvy up the work and make them ourselves. Once they were uploaded, we could switch the infobox and other templates to use the correct graphics instead of the facsimile workaround that's currently in use. That would greatly simplify the templates. Of course, if we lacked a graphic for a specific highway, one would need to be created, but that's the same situation just about every other country has. Imzadi 1979  02:11, 17 May 2015 (UTC)
Hi, Imzadi1979 – all that makes luminous sense! I do have an interim solution as shown below. Yes, it still does not address the challenges you outline above; however, it does make the top of the infoboxes more presentable for the time being. Thank you for your explanation above, and please feel free to take a look below and give your welcome opinions! – Paine  02:21, 17 May 2015 (UTC)
I wouldn't invest much more time in any interim solution, Paine Ellsworth. I have it on good authority that we've found the official documentation for the Indian highway markers, and we should be able to create proper graphics in the next few days. Once they're uploaded, the subtemplates will be switched over to call the proper graphics. Imzadi 1979  05:47, 17 May 2015 (UTC)
Thank you, Imzadi1979, for your good advice! Glad to hear you're so close to a much better solution. I'll return it all to normal and wait to see how it goes with the new graphics. Thank you! and Best of everything to you and yours! – Paine  07:54, 17 May 2015 (UTC)
Okay, Fredddie, thank you again for fixing the route number parameter earlier. I took the liberty to place some test code into this template's sandbox that uses the IND subpage code copied to my user sandbox IND subpage. Then I added the Route 24A infobox code to the top of this template's testcases page. As you can see, I think I've found a good compromise for the India infoboxes by altering the x coordinate from 0.5 to 0.37. The problem is that some route numbers are two-digit, such as "route=24", and others add a letter, such as "route=24A". If you go to the testcases page and remove the "A" of the "route=24A", you'll find that the "A" disappears from the highway sign, but the "24" stays where it is. Unless you know of a way to float that x coordinate, that is about as good as it gets. There is no "float=center" option in the {{Image label}} and {{Image label begin}} templates; our three choices are "float=none, left, or right". So I chose to use "float=none" (which didn't make any difference, by the way, the sign still defaulted to the left side of the ibox) and then use the {{Center}} template to actually center the highway sign. If after digesting all this you are agreeable, then I shall move the contents of my IND sandbox subpage to the live IND subpage. No hurry. Joys! – Paine  02:21, 17 May 2015 (UTC)
Fredddie, since as noted just above, the new graphics are nearly finished, I will go ahead and return things to their previous state. Thank you! and Best of everything to you and yours! – Paine  07:54, 17 May 2015 (UTC)
@Paine Ellsworth: commons: Category:Road signs for National Highways in India has all of the ones I've been able to create tonight using Fredddie's template. There are a couple made by German editors that use the wrong shade of yellow that I need to redo, but I won't get to those until I make the others. What's left are numbers with three or more characters where there aren't two 1s in the number. According to the Indian Roads Congress document, they're supposed to use the same typeface at the same size as the others, but that won't fit. I'll be doing the same thing the American DOTs would do, which is to drop back to a narrower series of the typeface to accommodate the wider width of the numbers without sacrificing the size. I'll get those uploaded later, and then the subtemplates will be switched to call the new graphics. National Expressway 1 (India) already uses its new graphic because there are only two NEs so it was easier to switch that type of highway over. Imzadi 1979  09:31, 17 May 2015 (UTC)
That is certainly much better, Imzadi1979! Do you know of any way to crop the two bottom corners so that the background color is the same shape as the sign? What am I saying – of course you know a way! I'll leave these highway signs in good hands. Joys! – Paine  17:38, 17 May 2015 (UTC)
I tried to make them as close to spec as I could, and the spec shows the black shield on the yellow rectangular sign, so cropping the corners would make them incorrect. –Fredddie 22:27, 17 May 2015 (UTC)
Okay, and again thank you both, Fredddie and Imzadi1979! – Paine  07:08, 18 May 2015 (UTC)

Request for comments on "edit in Wikidata" links, for templates using Wikidata

  You are invited to join the discussion at Wikipedia talk:Wikidata#Edit in Wikidata links. Thanks. Evad37 [talk] 01:38, 5 June 2015 (UTC)

e-road-shield. ahn-shield, tahn-shield

With regards to the recent edits to this template [16][17]: These parameters were added per Template_talk:Infobox_road/Archive_7#Edit_request: allow shields images to appear at the beginning of the line, instead of in the middle, per the principle behind Wikipedia:Manual of Style/Icons#Do_not_use_icons_in_general_article_prose: "Icons should not be used in the article body...This breaks up the continuity of the text, distracting the reader." - Evad37 [talk] 08:02, 28 June 2015 (UTC)

First, that isn't "general article prose" nor is it in the "article body"; it's a line in an infobox. The justification on that basis fails, period.
Second, the "Part of" text that precedes the rest of the line serves as the label for the line. We don't shove the other marker images in front of the "South end"/"North end"/etc labels in the infobox, so we shouldn't shove it left of the text that serves as the label for that line.
Third, the linked/abbreviated name serves as a caption for the marker image, but it can't handle that function when separated. The change should be restored, and the parameters officially deprecated. Imzadi 1979  02:12, 29 June 2015 (UTC)
1) Just because it isn't article prose doesn't mean that we put icons all over the place, wherever we like, in the middle of lines. That's the same justification that sees shields put to left in the junctions, so that we have
    I-95 / US 1/9 / US 46
rather than
  I‑95 /   US 1/9 /   US 46
for example.
2) At the moment, "Part of" is not really a label, either visually (its not bold or left-aligned or followed by a colon, like the other lables) or semantically in the template code (or underlying HTML). If its supposed to be a label, then maybe it should be changed to proper label, rather than being part of the text.
3) It can still serve as a label a couple of words away – we do that all the time for countries where roads are primarily identified by name rather than number, ie
  Reid Highway (State Route 3)
- Evad37 [talk] 01:42, 7 July 2015 (UTC) (sorry for the late reply, I've been away on holiday)
  1. And we don't put those icons just any place. A concurrency is a single highway with a combined name, just like "Spencer-Churchill" is a single last name, albeit a double-barelled surname.
  2. It may not have the same visual heft as the formal labels in boldface, but it has that same role.
  3. The name and number are all the same name serving as the adjacent caption to the graphic. "Part of" isn't a caption for the graphic, it's a relationship to the role of what the encompassing highway is, and that encompassing highway has both a marker and a name. Imzadi 1979  04:10, 7 July 2015 (UTC)
Ok, so "Part of" is a pseudo-label, formatted as plain text, for some reason. As for #1, perhaps I didn't choose the best example... something like
   Great Northern Highway (National Highway 1 north-east / National Highway 95 south-east)
rather than
Great Northern Highway (  National Highway 1 north-east /   National Highway 95 south-east)
better illustrates my point (note there is no concurrency between National Highways 1 and 95). MOS:ICON only applies to prose, so we could technically do it like this... and the marker images would be appropriately captioned... but we don't – the shields go at the left, not in the middle of the block of text.
As for #3, we could probably argue over the intricacies of what is or isn't actually part of the caption for these images, but I don't know how productive that would really be. - Evad37 [talk] 01:46, 8 July 2015 (UTC)
Interstate 496
Route information
Auxiliary route of I-96
Maintained by MDOT
NHSEntire route
Location
CountryUnited States
StateMichigan
Highway system
Route information
Component
highways
  I-80 from Indiana state line to near Youngstown
  I-90 from Indiana state line to near Elyria
  I-76 from Youngstown to Pennsylvania state line
Location
CountryUnited States
StateOhio
Highway system
  • Ohio State Highway System

One other consideration is whether we want these items to have a graphic at all. The |spur_of= and |spur_type= output, say on Interstate 496 that says it's an auxiliary route of Interstate 96 lacks the I-96 shield. We do use the graphics for component highways, like the I-80, I-90 and I-76 shields on Ohio Turnpike. So we're already a bit inconsistent here. I've included examples at the right, minus the other info that's not applicable to this discussion. Imzadi 1979  10:14, 9 July 2015 (UTC)

Another thing to consider is how to handle roads which are part of multiple routes, e.g. Autovía A-1 (E-5 and E-80) or Route 13 (Laos) (AH3, AH11, AH12, and AH15). If graphics are to be used, I think these would probably be better handled like the component highways (one per line with from/to locations) rather than like the spur route info. Also, there are probably other roads where only sections are part of the international route - specifying from/to locations would be good for these roads too. - Evad37 [talk] 12:05, 9 July 2015 (UTC)

Edit protected request

Please remove the TfD notice from the template page. I have closed the TfD as not merged. BethNaught (talk) 10:00, 23 August 2015 (UTC)

  Done -- John of Reading (talk) 11:23, 23 August 2015 (UTC)

No map

I see on Jalan Bakun that no map is available. As a result, the infobox displays an ugly "100px" text in red and is in Category:Articles with missing files. How can I override this? Debresser (talk) 11:35, 31 December 2015 (UTC)

@Debresser: it's not that there isn't a map available, it's that no one has made a Federal Route 803 marker graphic yet. To suppress it, you can add |marker_image=none, but the better solution is to actually create the missing marker graphic so that it would appear. Imzadi 1979  11:44, 31 December 2015 (UTC)
I wouldn't know how to do that. But in the mean time I can suppress these two issues. Thanks for your reply. Debresser (talk) 13:40, 31 December 2015 (UTC)
Done. On Louisiana Highway 817 and Louisiana Highway 824 there also is a problem, although I can't find the issue. Debresser (talk) 13:55, 31 December 2015 (UTC)

Photo parameters don't work for Canada

It seems that the photo/image related parameters don't work for a template used for a Canadian road (found source here Template:Infobox road/hide/photo). The documentation describes that they "will not work for articles in the United States per WP:USRD consensus". Is this a mistake, or does the documentation need to be amended? +mt 19:55, 10 February 2016 (UTC)

You are correct, consensus has been in the US to not use the photo parameter. However, Canada is not the US, so I enabled it. –Fredddie 21:50, 10 February 2016 (UTC)

length_km and precision

I noticed something strange with this parameter. If I set it to a whole number e.g. 40, then the resulting miles number seems off, in this case 20. An imprecise ratio of 2km:1mi. I didn't set the length_round parameter. However, if I set length_km to 40.0, then the resulting miles number is 24.9 - accurate. Just wondering if this behaviour is "by design". Thanks Declangi (talk) 10:35, 9 March 2016 (UTC)

The basic problem is that the significance of trailing zeros in a whole number is ambiguous. It seems that this template (or rather the modules behind it) assume all trailing zeroes are not significant (hence 40 km (precision -1) → 20 mi (40/1.609344 at precision -1), 400 km (precision -2) → 200 mi (400/1.609344 at precision -2). The approach taken by {{convert}} seems to treat the left-most trailing zero as significant (and the others not significant), so 40 km (precision 0) → 25 mi, 400 km (precision -1) → 250 mi. Note that whole numbers not ending in 0 have appropriate conversions:
Route information
Length39 km (24 mi)
Route information
Length40 km (25 mi)
Route information
Length41 km (25 mi)
- Evad37 [talk] 13:30, 9 March 2016 (UTC)
This template does not use the convert modules, but it probably should. Originally, it was decided that the citation for the length should be next to the number (10 mi[1] (16 km)) and not next to the conversion (10 mi (16 km)[1]). Currently, {{Convert}} does not support this convention, but it could probably be added. If that happens, we could simply replace that functionality with an instance of {{Convert}}. –Fredddie 23:17, 9 March 2016 (UTC)
That format can be done with {{convert}} right now: 10 mi<sup>[1]</sup> ({{convert|10|mi|disp=out}}) → 10 mi[1] (16 km) - Evad37 [talk] 05:16, 10 March 2016 (UTC)

Error in Spanish national road naming

National road N-634
Carretera nacional N-634
Route information
Length736 km (457 mi)
Major junctions
FromSantiago de Compostela
ToSan Sebastián
Location
CountrySpain
Highway system

Looking to the template you see, when you insert the "N" for a Spanish national road it indicates wrongly it is a "National highway". Can you change it to show it as "National road"? Thank you. Asturkian (talk) 13:34, 27 March 2016 (UTC)

The names are controlled by {{Infobox road/name/ESP}}, which I just changed, Asturkian. Imzadi 1979  14:05, 27 March 2016 (UTC)

Location redux

Almost two years ago, I suggested adding country and state/province locations to the infobox by default (thread archive). That discussion kind of fizzled out with no consensus. I'd like to restart it with the hope that Wikidata could help auto-populate that information for us. @Happy5214 and Rschen7754: what would need to happen on the Wikidata side for this to happen? –Fredddie 23:03, 16 April 2016 (UTC)

I'll let Happy comment about country, though on the Wikidata site the data is there. State could be a problem though, since right now there is a mix of counties and states in the appropriate data field. --Rschen7754 02:54, 17 April 2016 (UTC)
I'm surprised there isn't a hierarchy of regions. I know not every country is the same, but surely there could be some logical division. –Fredddie 02:59, 17 April 2016 (UTC)
That's what I proposed, but they didn't go for it when the properties were set up. Unfortunately, while the USRD standard is to use counties, people have gone ahead and done states anyway, which has made a bit of a mess. --Rschen7754 03:27, 17 April 2016 (UTC)
(edit conflict) Countries (P17) should be easy. States and counties are represented by statements of P131. By convention, states are used for national-level items (I-35, etc.), while counties are used for state routes and state-detail items (CA 1, I-35 TX). As such, nothing in those latter two items directly says "this item is in" California or Texas, though that can be inferred from other statements. -happy5214 03:29, 17 April 2016 (UTC)

A5025 road

Hi, can you tweak the infobox so the photo is smaller, has a caption and is at the top rather than underneath the map? It looks a bit scruffy like that a little too big. Can you edit the template so photos are above map and can be set to size? I think it would look better. Thanks.♦ Dr. Blofeld 16:06, 16 April 2016 (UTC)

I added |photo_width= and |image_width= so you can set width of the image as an uncontroversial change. I did not change the order of the map and the image as that is going to require consensus. –Fredddie 22:17, 16 April 2016 (UTC)
In my personal view (which other HWY editors may or may not share), the use of a photo in that space is discouraged when there is a map present, since photos can go elsewhere in the article (and there are usually multiple of them) whereas the map not being in the infobox is a bit strange. It's so much so that the use of photo= is restricted on all US road articles. --Rschen7754 03:41, 17 April 2016 (UTC)
Additionally, it's been felt that it is rare that a single photo can be used to represent a highway, yet the map does represent the full road because it's supposed to show the route of the whole thing. As such, photos normally should be down in the body of the article, not in the infobox. Imzadi 1979  05:18, 17 April 2016 (UTC)

Template-protected edit request on 1 May 2016

There is a bug in the live module regarding the map size for the United States. The map size is supposed to fit 290x172px, but the live module fails to obtain the table entry therein. The infobox for California's I-5 at the bottom of Template:Infobox road/testcases/USA illustrates the problem, and Module:Infobox road/map/sandbox contains the fix. The sandbox also has other changes and refactoring that do not result in different behaviors, with the exception of perhaps mw.wikibase.getEntityObject() that I don't quite understand what it does. Other than that line, the sandbox can be synchronized with the live module. Chinissai (talk) 17:41, 1 May 2016 (UTC)

I kinda like the longer map here, especially with a long state like California. I would say the 290px width is more important than the 172px height. –Fredddie 21:14, 1 May 2016 (UTC)

@Chinissai:   Comment: I see that there have been further changes to Module:Infobox road/sandbox since your edit request. Looking at Template:Infobox road/testcases/USA (at 00:34 UTC), some sandbox renders are not present, which I'm guessing isn't correct behavior? Looks like Fredddie has more context. Anyway, good luck with the change :) — Andy W. (talk · contrib) 00:36, 2 May 2016 (UTC)
@Andy M. Wang: I think you are talking about Rhode Island route 78 in the testcases page. The live version has another problem that this request does not address, but that problem simply pushes the sandbox rendering farther below. So, all the rendering is there but not at the right places because the live template is to blame. Note that Module:Infobox road/sandbox is not to be merged yet, and the map module being requested change does not depend on the main sandbox. Chinissai (talk) 01:20, 2 May 2016 (UTC)
@Chinissai: I'm unwilling to let the current template call Module:Infobox road/sandbox if that's what you mean. Not sure if there's a precedence for something like that. I think the first changes should be updates to the module, which you're stating is still blocked. — Andy W. ‎(talk · contrib) 15:34, 2 May 2016 (UTC)
  Done changes are live at Module:Infobox road/map. — Andy W. ‎(talk · contrib) 15:45, 2 May 2016 (UTC)
@Andy M. Wang: Thanks. I only would like the map submodule to be changed. I am guessing you figured out that I don't want the main template to be changed at this time either. Chinissai (talk) 15:54, 2 May 2016 (UTC)

Numbering

I was recently asked how one would deal with a "last" numbered road that has a previous one, but not a next one. The template doesn't seem built to handle that; omitting the "next_type" and "next_route" parameters or leaving them blank leads to error messages. Am I missing something? Huon (talk) 13:34, 7 May 2016 (UTC)

What I usually see is that the last route points to the first route in the sequence, and vice versa. In other words, the whole thing wraps around. Chinissai (talk) 14:20, 7 May 2016 (UTC)
Yep, that's typically what happens. We just put the first numbered road as the next route. Ideally, you should be able to click all the way through. –Fredddie 14:24, 7 May 2016 (UTC)

See above. --Rschen7754 00:22, 17 May 2016 (UTC)

Moved from Template talk:Infobox road/law/USA

The Utah legal links have changed. I believe the new template should read: http://le.utah.gov/xcode/Title72/Chapter4/72-4-S{{{section}}}.html -- Herrchin (talk) 20:11, 3 June 2016 (UTC)

Default section color?

There are a number of countries that do not have colors defined, which leads to calls to nonexistent templates/modules. Search User:Jonesey95/Redlinked transclusions for "color" to find examples of these, like Module:Infobox_road/color/MEX, which is called 151 times.

I looked at Module:Infobox road/color, which has a list of colors for countries that are explicitly defined. I don't know Lua programming, but how hard would it be to add a default color scheme for countries that are not yet defined in the list? In template programming, we could do this with #switch ... #default. – Jonesey95 (talk) 18:07, 15 October 2016 (UTC)

Not to difficult, but it takes a little homework. Here's the logic behind the color schemes that I try to follow:

In the US, guide signs (those that provide direction to roads and places) are green, so the default color is green. In the UK, for instance, the color of the guide sign depends on the class of road: motorways are blue, major A roads are green, and the rest are white. So I try to match that. So, that's the homework. Figure out what color(s) the road signs are and set up the color module accordingly.

I believe in Mexico, all the road signs are green like the US, so I will set that up now. –Fredddie 18:14, 15 October 2016 (UTC)

We can't know every country that people will call, however, so I am suggesting a default color, like light gray, for unspecified countries. We can then document that countries without colors are given a light gray color, and people can request colors on this talk page so that Module editors can add them. Does that make sense? Here are the countries currently showing up in the report, and this report only shows modules with 11 or more transclusions:
That is why I think we need a default color. We could add a tracking category, something like "Infobox road using default country color", so that people could work on the "homework" at their own pace. – Jonesey95 (talk) 18:23, 15 October 2016 (UTC)
There already is a default color, which is      light blue (#cedff2). That came from the template redesign in 2010. –Fredddie 18:30, 15 October 2016 (UTC)
That is good news. How can it be applied to countries that are not explicitly listed so that they do not call the nonexistent Modules above? I think it might be in or near this line: local module = require(string.format("Module:Infobox road/color/%s", name)). That line seems to ask for a submodule; can we first test to see if the submodule exists, then ask for it? – Jonesey95 (talk) 18:49, 15 October 2016 (UTC)
(edit conflict) It already works and has always worked. Here's an assortment of articles to demonstrate: Norwegian_County_Road_51, National Route 2 (Morocco), Rodovia Adhemar de Barros, Indonesian National Route 2, Highway 9 (Iraq), and Route 4 (Paraguay). Since I added Mexico to the main module, article are starting to drop out of the list of pages that link to the invalid module. –Fredddie 18:56, 15 October 2016 (UTC)
@Happy5214 and Chinissai: can one of you look into this? –Fredddie 18:56, 15 October 2016 (UTC)
I won't fix this for two reasons:
  1. Checking whether the module exists will add an expensive PF call, which I'm reluctant to add.
  2. More importantly, this module needs to be rewritten. Specifically, the colors need to me moved to the string modules. I don't think we should be working on an interim fix for an outdated module like this.
If someone could move the colors to those modules (just use the "color" key or something), I could convert the offending module to use Module:Road data/parser. -happy5214 22:10, 15 October 2016 (UTC)
Happy, do you know why the template is trying to find those modules when they should be linking to the generic color module? –Fredddie 22:23, 15 October 2016 (UTC)
Jonesey95 had it. If the country code isn't found in that module, it tries to import a submodule for that country. If that fails, it uses the default. -happy5214 22:32, 15 October 2016 (UTC)
Norwegian_County_Road_51 is a good example. If you click Edit and then expand the "Pages transcluded onto the current version of this page", you will see that Module:Infobox road/color/NOR, a nonexistent module, is being called. I'm open to any solution that eliminates these calls to nonexistent modules. Thanks for being willing to engage. – Jonesey95 (talk) 23:56, 15 October 2016 (UTC)

@Jonesey95: Is there a technical reason why transcluding these nonexistent modules is a problem, or does it just look bad? -happy5214 01:00, 16 October 2016 (UTC)

In most cases, transcluding a nonexistent template shows a redlinked template in the article, which is not good for readers. In the case of this module, that does not happen, which is good, but the unknown "Infobox road/color/XXX" modules populate any report of nonexistent transcluded templates and modules, which makes it more of a challenge for gnomes to locate other problems that can be fixed, like transclusions of {{Cite we}} and other misspellings. – Jonesey95 (talk) 03:34, 16 October 2016 (UTC)
Since there were only three submodules actually in existence (and I just merged away one of them), I decided to simply enumerate them in the module and only try to import those modules. Problem hopefully solved. -happy5214 04:48, 16 October 2016 (UTC)
Thanks, it looks like that worked. The change will need to propagate through the articles via the job queue, which usually takes a few days. I appreciate your effort to work through this change. – Jonesey95 (talk) 06:20, 16 October 2016 (UTC)

Template-protected edit request on 13 February 2017

Add a "regions" parameter for the bottom "Location" section of the infobox that would behave similar to the "counties", "cities', etc. but be used for administrative regions of Quebec, which act similar to counties in the U.S. C16SH (speak up) 19:52, 13 February 2017 (UTC)

Should be good to go. I enabled regions for all of Canada since that's how the backend was designed. –Fredddie 22:30, 13 February 2017 (UTC)

Additional sections?

When I created Mexican Federal Highway 180D, I thought four sections would be enough. Now I've found a fifth and cannot expand the infobox to include it. Mexican toll roads, by their nature, will have many segments as they are rarely long and continuous. Any idea as to what to do? Raymie (tc) 07:16, 15 February 2017 (UTC)

There is a highway in Arkansas that exists in 8 sections. When it was discussed before, the answer then was to use infobox road only for the overall summary of the highway, and then to use separate transclusions of {{infobox road}} for each segment in appropriate locations in the body of the article. At some point in the future, there may be support for additional infobox sections, but I think we're waiting on some recoding of other metatemplates in Lua, lest we complicate the existing code here further. Imzadi 1979  08:35, 15 February 2017 (UTC)
@Imzadi1979: Thank you; that's what I've done. Mexico articles are very difficult to write because numbers are not commonly used, there are often multiple segments, and the SCT plays fast and loose with designations. I'm looking at the big navbox and finding numbers that have been retired, like 126D which used to be in Michoacán but was changed to 14D. (Also the SCT's servers have been consistently unreliable, especially during evening hours.) Raymie (tc) 17:48, 15 February 2017 (UTC)

Problem?

A number of articles on Indian roads that use this template—Inner Ring Road, Hyderabad, Jaipur Ring Road, State Highway 57 (Tamil Nadu), etc.—have popped up in Category:ParserFunction errors. Clearly, something is making their infoboxes display incorrectly, but I've been unable to track down the error. (This happened a few days ago, and no edits to the infobox template itself were made at the time.) Can anyone hereabouts figure out what the problem is? Deor (talk) 21:34, 9 April 2017 (UTC)

The problem is that they are missing route numbers, as evidenced by SH 57 now rendering properly. The route number is used to determine metrics. -happy5214 22:33, 9 April 2017 (UTC)
Should be fixed now. I had done some work with {{Infobox road/shieldmain/IND}} a couple weeks ago and didn't realize I brought about any havoc. –Fredddie 01:36, 10 April 2017 (UTC)
Thanks, both of you. Deor (talk) 05:06, 10 April 2017 (UTC)
  Resolved

Set up for the Philippines

With a route numbering being implemented from 2016, having color-coded infobox headers are necessary for Philippine roads. Here is the infobox heading color by highway type, with the infobox using "PHL" in the country parameter (for Philippine highways)

  • E/Expressway - Yellow (#FC3)
  • N/National Road/Primary/Secondary/Tertiary - Green (#3BA)

--TagaSanPedroAko (talk) 12:23, 9 May 2017 (UTC)

Generally, we use the color of guide signs (examples: File:MUTCD Interchange Exit Direction Sign 1.svg and File:UK traffic sign 2906.svg) for the infobox headers. I can change the headers to these colors, but I just want to make sure that      #FC3 and      #3BA are the colors you want. –Fredddie 00:21, 10 May 2017 (UTC)
I've no idea myself, but looking at Philippine highway network, there are 3 different types of shields: E   File:E1 (Philippines).svg, AH    File:AH26 (N120) sign.svg and N   File:N11 (Philippines).svg, so there maybe we should be using:
  • E :       background:#fedd00; color:#000;
  • AH :       background:#084597; color:#fff;
  • N :       background:#000; color:#fff;
instead? -- WOSlinker (talk) 05:43, 10 May 2017 (UTC)
If the color of guide signs is used for heading colors, that means all headers in infoboxes for Philippine roads and highways (even the expressways) will be green, as guide signs in the Philippines are usually colored green, like this ones:
What I have asked for infobox road to support is based on a scheme used in Canadian roads, which use blue for controlled access roads, and green for the rest. Though they use green signs, roads classified controlled access highways are given blue headings on the infobox. It may have been the scheme because of its usage on the collector lanes of Ontario Highway 401 in Toronto, though the common standard color for guide signs in controlled access roads there in Canada is green. But now, I will agree on using the guide sign color, green (     #093, instead of my original proposal,      #3BA), as the default for headings of infoboxes in roads in the Philippines, with blue (     #039 to be set for AH/Asian Highways (i.e. AH26). I'll revise my proposed edit request with newer code.--TagaSanPedroAko (talk) 13:42, 11 May 2017 (UTC)

Independent cities under the location header

Would there be any opposition to adding independent cities under the location header? This would mainly apply to the relevant US states (Virginia, Colorado, Missouri, etc.) as most other countries allow cities in some form. –Fredddie 21:12, 16 May 2017 (UTC)

Could you clarify? For example what affect would your proposed change have on articles like Interstate 580 (Nevada) (passes through an independent city), Interstate 70 in Colorado (passes through a combined city-county) and similar. Also, please clarify how literal this is. In the US we have independent cities and combined city-counties. While they are effectively the same thing, and should probably appear similarly in an junction box list, but they are technically different. We all know how Wikipedia attracts editors who love to nit-pick. Dave (talk) 22:25, 16 May 2017 (UTC)
Infobox road location mockup
Current Mockup
U.S. Route 60
Route information
Maintained by VDOT
Location
CountryUnited States
StateVirginia
CountiesAlleghany, City of Covington, Rockbridge, City of Lexington, City of Buena Vista, Amherst, Nelson, Appomattox, Buckingham, Cumberland, Powhatan, Chesterfield, City of Richmond, Henrico, New Kent, James City, City of Williamsburg, York, City of Newport News, City of Hampton, City of Norfolk, City of Virginia Beach
Highway system
 
U.S. Route 60
Route information
Maintained by VDOT
Location
Counties:Alleghany, Rockbridge, Amherst, Nelson, Appomattox, Buckingham, Cumberland, Powhatan, Chesterfield, Henrico, New Kent, James City, York
Independent
cities:
Covington, Lexington, Buena Vista, Richmond, Williamsburg, Newport News, Hampton, Norfolk, Virginia Beach
Highway system

@Moabdave: This is what I was thinking. –Fredddie 22:40, 16 May 2017 (UTC)

Thanks, that clears it up nicely. No objection from me, but do be advised that my concern above applies, you will also have to address consolidated city-counties in a similar fashion. Dave (talk) 22:45, 16 May 2017 (UTC)
Is there a state that has both independent cities and consolidated county-cities? –Fredddie 22:53, 16 May 2017 (UTC)
To the best of my knowledge, no. Both articles have lists (Consolidated_city-county and Independent city (United States) ) and after an initial parsing I see no overlap. Dave (talk) 23:01, 16 May 2017 (UTC)
Correction, technically Alaska does, but only because it has both consolidated city-counties (like Sitka, Alaska), and cities in the unorganized borough, which we've so far treated as a county. So sortof kindof yes, but as the unorganized borough has no contiguous highways, this is unlikely to be an issue. Dave (talk) 23:05, 16 May 2017 (UTC)
Fair enough. It should be easy from a coding sense. –Fredddie 23:10, 16 May 2017 (UTC)
Some consolidated city-counties have other municipalities in them. For instance, Jefferson County, Kentucky, has many other tiny cities other than the territory of Louisville. So if we do anything with consolidated city-counties in the infobox, we need to be cognizant of that. I suggest we just treat those counties like any other county.  V 02:37, 20 May 2017 (UTC)

Philippine provinces

It looks like the provinces of the Philippines are not supported by the current module. Only Iran (IRN), Turkey (TUR), Thailand (THA), Spain (ESP), and the Netherlands (NLD) are supported. Please include the Philippines (PHL) to the current code.

local function provinces(args, country)
local data = {TUR = "no", THA = "no", IRN = "no", NLD = "no", ESP = "no", PHL = "no" default = "yes"}
local yesOrNo = data[country] or data.default
if yesOrNo == "no" then
return args.provinces
else
return nil
end
end

TagaSanPedroAko (talk) 16:43, 24 May 2017 (UTC)

  DoneFredddie 21:36, 24 May 2017 (UTC)

Canadian Provinces

Hello, I was wondering if Canadian provinces could be supported for inter-provincial highway articles? Drawing comparison from US articles, inter-provincial articles should list provinces while the province specific article would continue to list the various municipalities? For example;

United States
Interstate 5 - main inter-state article, shows states

Canada (proposed)
Yellowhead Highway - main inter-provincial article, shows provinces (new)

Any thoughts? MuzikMachine (talk) 22:55, 24 May 2017 (UTC)

Listing control cities

Though I am being only present at some times, listing control cities (other than those in the United Kingdom, Ireland, India, and Malaysia, where "primary destinations" are used instead) on the infobox looks interesting, especially on roads that pass on many municipalities where including them can be troublesome. While it will be mostly major settlements, that can be other important destinations, like major landmarks, named roads, bridges, tunnels, ferry ports, administrative boundaries (including international borders), or even named unsettled areas. But, can adding "control" cities be appropriate for most countries? TagaSanPedroAko (talk) 11:27, 21 June 2017 (UTC)

Dashes

Here's a minor thing for a clever person to fix: this template is producing "2001 – present" in the established parameter at West Side Highway. Per MOS:DATERANGE this ought to be "2001–present" (though if it were a specific date, for example "August 10, 2001 – present", then the spaced en dash would be appropriate). This was discussed in 2012 at Template talk:Infobox road/Archive 6#Edit request but as far as I can tell a change was never implemented (and as far as I can tell it hasn't been discussed since). Can something be done, if only to appease pedants like myself who might try to fix the error, only to be dismayed at finding it hard-coded? Best, – Arms & Hearts (talk) 23:38, 9 August 2017 (UTC)

@Arms & Hearts: in principle, I fully support this idea. In practice, though, we'd still need to find a way to automatically tell the difference between November 30, 2024 (2024-11-30), and 2024. As was noted in 2012, using {{Start date}} would muck up a method that was going to be put in place back then. –Fredddie 01:29, 10 August 2017 (UTC)
Done in the sandbox [18], see testcases. Plain years won't cause arithmetic errors, wheres month+year or day+month+year will. {{Start date}}/{{End date}} can be normalised by trimming to the first four characters. - Evad37 [talk] 02:26, 10 August 2017 (UTC)

Nonfree image removal

In articles such as Alberta Highway 61, Alberta Highway 501, and Alberta Highway 4, this template seems to be including a nonfree image, File:Red Coat Trail (Alberta).svg, along with the freely licensed (PD-text) images that render the nonfree image replaceable and replaced based on the "route" parameter. Would someone be able to assist in removing the nonfree image as required from this particular route, rather than needing to remove the entire infobox? Seraphimblade Talk to me 00:18, 20 August 2017 (UTC)

@Seraphimblade: there are FURs for each of those three pages, so what is the issue? Rather, what should be displayed? –Fredddie 02:13, 20 August 2017 (UTC)
A FUR doesn't allow a nonfree when it's replaceable with a free image. In this case, only the PD-textlogo highway signs should be shown, those are sufficient for visual indication. The second nonfree image is replaceable and decorative, so it fails nonfree content criteria 1 and 8 in those use cases. Seraphimblade Talk to me 17:19, 20 August 2017 (UTC)
I disagree; if the road is signed with that marker, it should appear in the infobox as a visual confirmation of the identification of the highway. Imzadi 1979  18:13, 20 August 2017 (UTC)
There's nothing to disagree about. NFCC #1 is clear that nonfree images can be used iff they serve a necessary purpose and no free image could possibly serve that purpose. In this case, the purpose is visual identification (which is an allowable reason), but the primary highway sign already serves that purpose and is free. NFCC isn't negotiable or consensus based. Seraphimblade Talk to me 18:26, 20 August 2017 (UTC)

There appears to be two images though. The svg one has a non-free logo license and the png one has a CC3 license. -- WOSlinker (talk) 22:38, 20 August 2017 (UTC)

Someone with OTRS access should review the PNG one and see if that OTRS release applies here. --Rschen7754 22:40, 20 August 2017 (UTC)
If the OTRS release was made under a free license, it automatically applies here. They could confirm the licensing, but that being the case, we can replace it with the free one and all's well. Good find WOSlinker. Seraphimblade Talk to me 22:42, 20 August 2017 (UTC)

Semi-protected edit request on 26 August 2017

Example must be a South African road 165.255.214.135 (talk) 13:42, 26 August 2017 (UTC)

Why must it be, and if it so must be, which one? Imzadi 1979  00:38, 27 August 2017 (UTC)
Please? –Fredddie 03:59, 27 August 2017 (UTC)

plainlist

I recently edited {{Infobox road/doc}}, replacing {{plainlist}} with a plain list of the items formerly in the template. I included the edit summary

{{plainlist}} and its variant {{unbulleted list}} can't go inside {{Infobox road}} ... it causes multiple missing </small> tags leading to Multiple unclosed formatting tags <small>

Here is that same edit summary, properly formatted:

{{plainlist}} and its variant {{unbulleted list}} can't go inside {{Infobox road}} ... it causes multiple missing </small> tags leading to Multiple unclosed formatting tags (</small>)

Multiple unclosed formatting tags is a high priority lint error and that should override any minor accessibility concern, but unfortunately Evad37 reverted with edit summary, suitably escaped to display the same:

Undid revision 818159130 by Anomalocaris (talk): What does {{plainlist}} have to do with <small>? Please explain on talk, because per MOS:PLIST it should be used for accessibility.

I trust that my explanation of the lint problem should be sufficient and justifies overriding of any possible application of MOS:PLIST. —Anomalocaris (talk) 01:14, 2 January 2018 (UTC)

For the luddites who watch this page, what is a lint error and why are they bad? –Fredddie 01:27, 2 January 2018 (UTC)
The parser which turns wikitext into html is being replaced, and the new one interprets some markup a bit differently. Some errors which are currently automatically fixed by the parser won't be in the future. See also Wikipedia:Wikipedia_Signpost/2016-10-14/Technology_report#New_parsing_algorithm,_server_switches and WP:LINT - Evad37 [talk] 01:38, 2 January 2018 (UTC)
(edit conflict) I still think the correct solution is to fix the code this template and its lua modules emit – i.e. solve both concerns, rather than to prioritise one over the other. Would what I proposed in the section above fix it? (since there doesn't seem to be anything intrinisic to plainlist's code that would cause unclosed small tags, except perhaps that it is a block element, and the infobox puts that block element into the inline small element)? - Evad37 [talk] 01:33, 2 January 2018 (UTC)
Evad: Thank you for explaining it for Fredddie. Just go ahead and try what you have in mind and see how it works! —Anomalocaris (talk) 01:41, 2 January 2018 (UTC)

Plainlist in length notes

The code for this section comes from Module:Infobox_road/length:

table.insert(text, "<br><small>" .. notes .. "</small>")

Wouldn't changing this to something like

table.insert(text, "<div style='font-size:90%;'>" .. notes .. "</div>")

be a better fix than trying to forbid the MOS-specified use of plainlist, @Anomalocaris:? - Evad37 [talk] 01:08, 2 January 2018 (UTC)

Evad: Make such changes as you deem desirable, but leave it free of the lint error Multiple unclosed formatting tags. To determine of you have left {{Infobox road/doc}} free of this high-priority lint error, click on "Page information" on that page and near the bottom, just above "External tools", will be a section on lint errors if there are any. Right now, there are these lint errors:
Multiple unclosed formatting tags: 1
Missing end tag: 1
Stripped tags: 1
The missing end tag and stripped tag are low-priority and not a major concern. Also, there are only a few Lint errors: Multiple unclosed formatting tags in namespace Template, so you can look there as well. Someone also reverted my similar change to {{Infobox road/testcases/USA‬}}, which can probably be addressed the same way. —Anomalocaris (talk) 01:33, 2 January 2018 (UTC)
I'll try it out in sandboxes and see what happens - Evad37 [talk] 01:42, 2 January 2018 (UTC)
It seems to work – https://en.wikipedia.org/w/index.php?title=Template:Infobox_road/doc/sandbox&action=info shows no lint errors – so I'll make the change to the live module. - Evad37 [talk] 01:55, 2 January 2018 (UTC)
  Fixed, https://en.wikipedia.org/w/index.php?title=Template:Infobox_road/doc&action=info shows no errors – Evad37 [talk] 02:04, 2 January 2018 (UTC)
Evad: Congratulations, that took care of the problem in a systematic way. —Anomalocaris (talk) 02:46, 2 January 2018 (UTC)

Template-protected edit request on 4 March 2018

Within the Infobox road/law/USA and for the state of Utah (UT) only, add a #switch, an #if, or something else similar that, for a section parameter entry of "301", will return Utah Code §72-3-301 rather than the standard Utah Code §72-4-{{{section}}}. This is needed for two very exceptional highways that are defined under a different chapter of the Utah Code. All other sections used are and will be in the format "1##" (106-137), so it should not create a conflict. (The highways are exceptional because, unlike all other highways which have the purpose of facilitating transport between Point A and Point B, these two highway were created for the express purpose of preventing transport between Point A and Point B, as will be explained in their articles.) An Errant Knight (talk) 05:00, 4 March 2018 (UTC)

@An Errant Knight: I inserted a switch. Please let me know if this has worked properly. Imzadi 1979  05:09, 4 March 2018 (UTC)
@Imzadi1979: First of all, thank you for actually understanding the intent of the somewhat poorly explained edit request. Second, much obliged for the edit, but there are still two issues:
1) A typo: The "chapter" in the url of the website for the exception (non-default) should be "3" rather than "4" (which is why the #switch was needed in the first place). Other that that, the "exceptional" link seems to be working as intended.
2) The #switch should apply to the {{{section}}} parameter, rather than the {{{route}}} parameter
The following should be probably be the correct code:
|UT={{#switch:{{{section}}}
|301=<span class="plainlinks">[http://le.utah.gov/xcode/Title72/Chapter3/72-3-S{{{section}}}.html Utah Code §72-3-{{{section}}}]</span>
|#default=<span class="plainlinks">[http://le.utah.gov/xcode/Title72/Chapter4/72-4-S{{{section}}}.html Utah Code §72-4-{{{section}}}]</span>}}
As an alternative, the second line could also, and probably should, be as follows (since there is no alternative for the section but "301"):
|301=<span class="plainlinks">[http://le.utah.gov/xcode/Title72/Chapter3/72-3-S301.html Utah Code §72-3-301]</span>
In addition, the following note added immediately after the second line might be helpful for those wondering why the #switch is necessary:
<!--This #switch is necessary for, but only applicable to, Utah State Routes 900 and 901-->
Thanks again your assistance. An Errant Knight (talk) 06:48, 4 March 2018 (UTC)
I made the suggested changes.[19] PrimeHunter (talk) 10:38, 4 March 2018 (UTC)

A little help with previous_dab= for UK motorways?

Please see this discussion if you can help get |previous_dab= working for UK motorways. – Jonesey95 (talk) 15:25, 20 July 2018 (UTC)

  Fixed I'll reply to the linked discussion with more details. -happy5214 20:27, 20 July 2018 (UTC)

Moved from Template talk:Infobox road/browselinks/USA

@Fredddie: Why is the county route article for Ohio separate from the main template? Cards84664 (talk) 15:46, 15 September 2016 (UTC)

I believe it's so state highway system links are not shown on county road articles. But I'm not certain. –Fredddie 15:53, 15 September 2016 (UTC)

Template-protected edit request on 2 July 2018

Under the Nevada section, please change [[Nevada Scenic Byways|Scenic]] to [[List of Nevada Scenic Byways|Scenic]], to avoid a redirect. Thanks. LJ  14:30, 2 July 2018 (UTC)

  DoneFredddie 01:17, 3 July 2018 (UTC)

Unknown parameter tracking added

I have added unknown parameter tracking to this template after finding |nap_notes= in a template at M7 motorway (Ireland) without it displaying an error message. Because this template invokes modules, and because the documentation examples use parameters that do not appear to exist in the template (e.g. |map-alt=), I expect that some cleanup will be needed. If legitimate parameters are flagged by the error checking, they can be added to the alphabetized parameter list at the very bottom of the template. Feel free to ping me here with questions. I will watch this page for a while.

See Category:Pages using infobox road with unknown parameters (26), which should populate over the next few days or weeks. – Jonesey95 (talk) 10:21, 22 October 2018 (UTC)

The parameter |communities= was added to the error check just now by Rschen7754, but it is not documented and appears to be used in only one article, according to the TemplateData monthly report. It does appear to work in PO-552 Road (Spain), showing a heading of "Autonomous communities:". Can someone please document which countries it applies to? – Jonesey95 (talk) 04:59, 23 October 2018 (UTC)
I see 17 articles using the uppercase Communities. --Rschen7754 06:06, 23 October 2018 (UTC)
So do I. That parameter is definitely not supported. Since the documentation does not explain the cases in which |communities= is allowable, I don't know whether the correct resolution is to delete the parameter or rename it. – Jonesey95 (talk) 06:28, 23 October 2018 (UTC)
Please don't go around deleting parameters without discussion. It is possible that the documentation is not up to date, but that doesn't mean the parameter is not important. --Rschen7754 06:31, 23 October 2018 (UTC)
I correct parameter names when the correction is clear. I delete parameters when they are clearly wrong or unsupported, or when there is evidence that the parameters were removed from the template following a discussion. If you have found an error in one of my recent contributions, feel free to let me know. Thanks. – Jonesey95 (talk) 07:37, 23 October 2018 (UTC)