Jump to content

Template talk:Infobox road

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Module talk:Infobox road)

Luafication

[edit]

Are there any plans to convert parts of this infobox to Lua, specifically the shield, route name, and translation? Now that we have fairly robust road data modules, I think these three items should be handled by the road data modules. Yes, I know that these will eventually be handled by Wikidata, but who knows when that will happen? We can use Lua now.

For those locations that don't yet have a road data module, we could utilize a tracking category to catch them, but I don't think there are very many. –Fredddie™ 16:01, 16 May 2015 (UTC)[reply]

There's no reason why we couldn't have the shield handled by Wikidata, similar to how the maps are now, though Happy might be waiting on other development last I heard (several months ago). --Rschen7754 16:04, 16 May 2015 (UTC)[reply]
Yes, my Summer of Code development. I have no problem with migrating the infobox shields, names, and translations over to the road data string modules. That can be done right now while we're waiting for the corresponding Lua code, since adding unused keys won't cause any errors. The only issue with using shields from Wikidata is an override for highways with non-free shields. I would also like to migrate the colors to the string modules at some point. As for the rest of the infobox, I'm still waiting for mw:Extension:Capiunto to be deployed. -happy5214 00:42, 17 May 2015 (UTC)[reply]
@Happy5214: do you have anything to report from the last four months? –Fredddie™ 01:37, 3 September 2015 (UTC)[reply]
No, nor might I have anything over the next four months. Feel free to migrate the infobox-specific data to the string modules, but module development has been stalled due to lack of progress on Capiunto and my own personal inactivity. -happy5214 07:13, 3 September 2015 (UTC)[reply]

Something that might be possible is to have Module:Infobox_road/length get the length from Wikidata, if available and not specified locally. I added length to [1] and we at least can use the same source for all US Interstate articles. Aude (talk) 09:09, 9 October 2015 (UTC)[reply]

@Aude: I have a few concerns about doing this now, although I'm sure it will be done eventually. Do you happen to know how quantities with units are handled in the Wikibase Lua library? Are unit conversions available from the library, or will client code (Infobox road/length) still be required to convert between miles and kilometers? -happy5214 11:10, 9 October 2015 (UTC)[reply]
@Happy5214: I don't think there is special handling (yet) in the Wikibase lua library for quanitites (e.g. conversion), but there is Module:Convert. What (else) do you have in mind that we need in the lua library? Suppose for now, I could help with adding this data to Wikidata and maybe experiment with lua in a sandbox module. Aude (talk) 12:29, 9 October 2015 (UTC)[reply]
Since I already have unit conversion code in my module, I guess all I would have to have is a way to determine the unit used for the statement. -happy5214 03:32, 10 October 2015 (UTC)[reply]
In the past, the only reason we never used {{Convert}} was because we wanted it to appear <length><reference> (<conversion>). So long as that's preserved, there will be no opposition from the "it's always been that way" lobby. –Fredddie™ 13:02, 10 October 2015 (UTC)[reply]
@Happy5214: now that I've thought about it for a little while, you really shouldn't need units. There are only a handful of countries (US, UK, Liberia, maybe one more?) that use miles for anything, so the country property should influence what unit is used. –Fredddie™ 14:11, 10 October 2015 (UTC)[reply]

RFC: Transitioning to Lua module

[edit]

For the past week, I have been converting this template into a Lua module. The sandbox now does not transclude templates, except for certain fallbacks where (1) arguments to the live template need to be changed (discussed in issues below), and (2) data are yet to be defined in road data modules. There was a lot of data movement, and I think I am at a point to request for comments on where I decided to put things.

The goal is to use road data modules as much as possible. For USA, the following data are to be moved to road data modules (see Module:Road data/strings/USA and Module:Road data/strings/USA/NH for examples of an updated modules):

  • shieldmain: moved from Template:Infobox road/shieldmain/USA to each state's road data module. Defaults to shield if undefined.
    • shieldmainsize: size for shieldmain if it were to be displayed in {{jct}}. Defaults to shieldsize if undefined.
  • name: moved from Template:Infobox road/name/USA to each state's road data module.
  • translation: moved from Template:Infobox road/translation/... to each country's road data module. (I have yet to test this.)
  • law: moved from Template:Infobox road/law/USA to each state's road data module, if defined.
  • maint: moved from Template:Infobox road/maint/USA to each state's road data module.
  • browse: moved from Template:Infobox road/browselinks/USA to each state's road data module. Since browse links may be associated with route types or states, these links have to be moved to two places:
    • For links associated with route types, these move to the definition of the route type, e.g., USA.I.browse.
    • For links associated with states, these move to the common section for each state, e.g., NH[" common "].browse.
    • By default, the common browse is shown, but this might be undesirable for certain route types, e.g., county routes. To disable common browse, such route types may specify nocommonbrowse = true in the definition of the route type.
  • aux: moved from part of Template:Infobox road/meta/spur of to each stata's road data module. This is the full wiki markup describing auxiliary types, e.g., [[Business route]]. Lua loops can be used to fill these out automatically without explicitly writing them down.
    • For an irregular route that is auxiliary, but their route type is not auxiliary in general, e.g., New Hampshire Route 3A, |spec_auxtype= can be specified, where spec_auxtype is auxiliary code such as Alt and Bus. The definition of these types is at USA[" aux "].aux. This can be further overridden by providing full wiki markup in |spec_aux=. Defaults to Auxiliary route if none of these is unspecified.

For other countries, the data are to be moved to road data modules in a similar way.

Some data remain in the Infobox road namespace, because they govern how data are displayed and not themselves data:

These modules are structured so that they can be fetched with mw.loadData.

Issues

  • |subtype= should be deprecated, since |type= can now include auxiliiary types directly, as in US-Alt. Moreover, certain route types have multiple subtypes, e.g., US-Truck-Alt. This change will make route types consistent with {{jct}}. Transclusions using this parameter must be modified as part of the transition. To help with this, the sandbox concatenates subtype to type before invoking the road data module.
  • Translations depend on {{lang}}, which I don't know how to replace with modules yet.

Additional features

These are incorporated from past discussions and are independent of the transition.

  • Added support for nested infobox.
  • Automatically display country and state (without wikilinks for now).

Dependencies

Extended content

Future work (we should discuss)

  • Rework the location section to allow custom labels (e.g., rural municipalities, divisions) instead of dedicated parameters. There are too many of them now, and I think these could get out of hand.
  • Rework the browse section to break things up from the current browse parameter. For example, multiple rows of previous and next routes can be specified with numbered suffixes, in the same way as multiple route sections.

Template:Infobox road/testcases and its subpages may be of your interest. Some shields therein might be incorrect because road data modules need an update. While the current sandbox is robust enough for the transition, template warnings should be inserted first so transclusions needing corrections can be readily identified. Chinissai (talk) 11:14, 6 May 2016 (UTC)[reply]

Mapframe maps

[edit]

Mapframe maps are now available on English Wikipedia, and can be inserted with template {{maplink}} (or with <mapframe>...</mapframe> and raw JSON code). This is what the New Jersey Turnpike example from the documentation would look like with a mapframe map:

Map
Map of the New Jersey Turnpike mainline and spurs in red
Route information
Maintained by the New Jersey Turnpike Authority
Location
CountryUnited States
StateNew Jersey
Highway system
{{Infobox road
|state=NJ
|type=Turnpike
|maint=the [[New Jersey Turnpike Authority]]
|map={{maplink|frame=yes|plain=yes|frame-align=center|frame-width=290|frame-lat=40.219850|frame-long=-74.699190|zoom=7|type=line|id=Q811504|title=New Jersey Turnpike}}
|map_custom=yes
|map_notes=Map of the New Jersey Turnpike mainline and spurs in red
<!-- other parameters omitted -->
}}

If OSM data is unsuitable or unwanted, mapframe maps can draw from GeoJSON data (which can be derived from KML files), either on Commons (must be CC-0) or locally (just needs to be CC-BY-SA compatible):

Map 

{{Maplink|frame=yes|plain=yes|from=Sandbox/Evad37/St Georges Terrace.map|type=data|frame-lat=-31.95|frame-long=115.86|zoom=13}}

Map 

{{maplink|frame=yes|plain=yes|raw={{Wikipedia:Map data/Main Roads Western Australia/Forrest Highway}}|title=Forrest Highway|frame-lat=-32.9|frame-long=115.7|zoom=8}}

What would be really interesting would be if the infobox template could automatically insert a mapframe map if there is no map image for the road. Which seems like it should be possible in Lua, but might be quite a bit of work. - Evad37 [talk] 06:36, 10 May 2018 (UTC)[reply]

It would be a lot easier if this template (which is backed by Module:Mapframe) could be called directly from Lua, which does not appear to be possible without the use of frame:preprocess. I'd suggest that such direct calling functionality be added before we worry about writing our end of the Lua code. -happy5214 22:24, 10 May 2018 (UTC)[reply]
Green tickY Done, can now be called from other modules - Evad37 [talk] 01:40, 11 May 2018 (UTC)[reply]
I also had a go at the Lua coding, and came up with Module:Infobox mapframe / {{Infobox mapframe}} - Evad37 [talk] 07:09, 11 May 2018 (UTC)[reply]
You should consult with Dschwen, who created WikiMiniAtlas. It'd be great if the KML automatically centered the mapframe map, which is something that WMA does already. My biggest dread to deploying this is finding central coordinates for the map. –Fredddie™ 21:56, 11 May 2018 (UTC)[reply]
Tracked in Phabricator
Task T193455
If everything worked properly, it wouldn't be necessary to specify frame coordinates or zoom – mapframe maps can do automatic zooming and centering, but at the moment it only happens in preview mode or after opening the map, and not for regular page viewing. (Reported on Phabricator, but its probably not likely to be fixed any time soon since mw:Map improvements 2018 is just about over.) - Evad37 [talk] 02:37, 12 May 2018 (UTC)[reply]
@Evad37: What am I doing wrong here: Iowa Highway 192 –Fredddie™ 02:30, 15 May 2018 (UTC)[reply]
@Fredddie: The data has to exist on OSM first, and be linked to wikidata from there (and takes about 1 day to be available here after being linked); see mw:Help:Extension:Kartographer/OSM. But OSM is only really for current information, former roads should probably use geoJSON. - Evad37 [talk] 03:02, 15 May 2018 (UTC)[reply]

Conversion done at Wikipedia:Map data/Wikipedia KML/Iowa Highway 192, using a script I made: User:Evad37/kmlToJson.js

Map On the attached kml subpages, the script adds a "GeoJSON" link near the "Move" link (In the 'More' dropdown menu for Vector skin; a tab in Monobook skin) that does the conversion when clicked. I'll also look into coding something to suggest appropriate frame coordinates. A further possibility would be to automate the creation of the geoJson map data pages. - Evad37 [talk] 04:42, 15 May 2018 (UTC)[reply]

I also fixed Iowa 346 on OSM [2] – the relation existed on OSM, but was missing a fair chunk of the route, and wasn't yet linked to Wikidata. The data should be available to mapframe maps in about a day. It seems like there is likely to be a fair amount of cleanup to do on the OSM side of things. - Evad37 [talk] 05:36, 15 May 2018 (UTC)[reply]

All Indian National Highways having articles have qid linked in OSM if you want to experiment you can try in NH articles. Currently there is a limit in no of Highways displayed.

T193458 --naveenpf (talk) 05:53, 15 May 2018 (UTC)[reply]

  • @Mr. Matté: this may be relevant to your interests.

@Evad37: one problem I'm seeing is for national routes like Interstate 10. It has an OSM relation, but if you go to OSM, no line shows up at all so no line shows up on our map. The state OSM relations work just fine, see Interstate 10 in Texas. –Fredddie™ 22:34, 13 June 2018 (UTC)[reply]

Tracked in Phabricator
Task T156433
@Fredddie: The OSM relation for Interstate 10 only contains other relations. That doesn't work, only roads (and other lines/shapes) that are directly in a relation will be displayed (see phabricator task). You could create a new relation on OSM that directly contains all of Interstate 10, but the best option is probably just to display all the data from state articles together, i.e. {{maplink|type=line|id= |type2=line|id2= |...etc...}} filling in the wikidata ids for all the state articles. - Evad37 [talk] 01:08, 14 June 2018 (UTC)[reply]
Thanks, I'll give that a try. –Fredddie™ 01:26, 14 June 2018 (UTC)[reply]

Map data on Commons

[edit]

We can now store CC-BY-SA data can on Commons. We should probably migrate the Map data subpages over to Commons so that other wikis can more easily reuse the data. - Evad37 [talk] 06:24, 28 August 2018 (UTC)[reply]

I've noticed that Commons can handle much larger files than the raw map data pages. See U.S. Route 80 in Arizona and commons:Data:U.S. Route 80 in Arizona.map for an example. –Fredddie™ 14:04, 28 August 2018 (UTC)[reply]
@Evad37: are the data maps going to be linked on Wikidata eventually? –Fredddie™ 14:04, 28 August 2018 (UTC)[reply]
There's already a property for that: geoshape (P3896) - Evad37 [talk] 15:09, 28 August 2018 (UTC)[reply]
How are we going to move the files - Special:Import? Or just link to the original file (but that means we have to keep the JSON or the KML on enwiki around indefinitely - which could be a mess if it gets updated) --Rschen7754 14:46, 28 August 2018 (UTC)[reply]
I don't know if Special:Import would work, since the source pages would have a wikitext content model, which is not what the .map pages on Commons use. And it's probably not as simple as just changing the content model, since the software requires a very specific syntax to be used, including a properly specified licence, before allowing an edit to be saved. We probably need to do a test case to see if it's possible to do an import with Special:Import, and then change the content model, and edit the page to specify the licence and otherwise comply with the syntax requirements. - Evad37 [talk] 15:09, 28 August 2018 (UTC)[reply]
Special:Import is an admin-only tool) and I don't have the hat on Commons. I tried on test.wikipedia which doesn't have the map.json model apparently, just plain JSON. Import worked fine but it was just plain wikitext. I was able to change the content model to plain JSON but I had to remove the header template at the top. --Rschen7754 18:56, 28 August 2018 (UTC)[reply]
To clarify, Special:Import is only available to admin and importers. Special:ChangeContentModel is admin-only (perhaps it shouldn't be, but that is how the config of that wiki is set up). --Rschen7754 19:01, 28 August 2018 (UTC)[reply]
I'm an admin on Commons and would be happy to lend a hand. I see that for your test on test.WP you imported Wikipedia:Map_data/Wikipedia_KML/Iowa_Highway_192. Would you like me to import that page to commons:Data:Wikipedia KML Iowa Highway 192.map (or maybe commons:Data:Highway 192 in Iowa.map following the naming convention adopted by commons:Data:U.S. Route 80 in Arizona.map) and then change the content model of the new page to map.json? —RP88 (talk) 01:00, 29 August 2018 (UTC)[reply]
That would be appreciated (using the second name), though I don't know how we would move thousands of files if we wound up going that route. --Rschen7754 02:06, 29 August 2018 (UTC)[reply]
(edit conflict) @RP88: Yes, that would be good, to see that it does in fact work. If so, then we could perhaps start looking at a more automated or semi-automated solution, starting from the KML source files (which we have thousands of) – i.e. a tool or bot to (semi-/)automatically do some or all of the steps: import the KML, convert to GeoJSON, add licence/source info, and change content-model to map.json.
I'm not entirely sure what the naming convention should be... I think a lot of pages in the Data: namespace are in the format Data:source/filename.map so that the source acts a pseudo-namespace. Which is why the map data pages here have the /Wikipedia_KML/ in the page name, for those derived from KML files. On the other hand, it would be nice to have a consistent set of data files regardless of source. Especially since going in to the future we would likely be generating new files as GeoJSON directly, rather first publishing as a KML file. But in any case, pages can be renamed later on. - Evad37 [talk] 02:07, 29 August 2018 (UTC)[reply]
OK, I just gave the import a try. An attempt to import to the Data namespace failed with the error "Page "Data:Map data/Wikipedia KML/Iowa Highway 192" was not imported because you are not allowed to create it." (probably because of name/format issues). An import to the default location (i.e. Commons namespace) followed by a move succeeded, but then the attempt to change the content model to json/map.json failed with the error "Invalid content data". Viewing the resulting data (in both wikitext and plain text model) shows a "Fatal exception of type "Exception" error. I am going to try importing the data to a non-Data namespace, fixing the content to comply with map.json, and then moving it to Data namespace. —RP88 (talk) 02:32, 29 August 2018 (UTC)[reply]
I've created c:Data:Highway 192 in Iowa.map, but I can't seem to change the content model to the map-specific version of JSON. —RP88 (talk) 02:46, 29 August 2018 (UTC)[reply]
Maybe blanking the page would allow a successful change of content model, after which the JSON could be copied back in? - Evad37 [talk] 02:53, 29 August 2018 (UTC)[reply]

OK, a working version is now at c:Data:Highway 192 in Iowa (3).map. The procedure I used to create this map file was:

  1. Use Special:Import to import Wikipedia:Map_data/Wikipedia_KML/Iowa_Highway_192 to Commons namespace.
  2. Copy the content to a text editor and fix to match map.json format.
  3. Move the page to the Data namespace under the correct name.
  4. The content can now no longer be edited or viewed.
  5. Delete the .map page.
  6. Recreate the .map page using the fixed content from the text editor.
  7. Restore the deleted revisions.

The resulting page c:Data:Highway 192 in Iowa (3).map works a little strange (you can't diff between the older non-map revisions, but you can view them as non-maps, etc.). —RP88 (talk) 03:14, 29 August 2018 (UTC)[reply]

It works in a mapframe map:

Map 

{{Maplink|frame=yes|plain=yes|type=data|from=Highway 192 in Iowa (3).map|frame-lat=41.2609|frame-long=-95.86|zoom=11}}
- Evad37 [talk] 03:25, 29 August 2018 (UTC)[reply]
Excellent! I did try your suggestion of blanking the page, but it didn't work because the .map page couldn't be edited. I couldn't find any method other than the steps above (which was essentially a history merge). It doesn't seem like a practical process if thousands of maps need to be imported. —RP88 (talk) 03:39, 29 August 2018 (UTC)[reply]
It should be possible to automate all those steps via script, so it could be done in one click (and then just checked afterwards) - Evad37 [talk] 06:26, 29 August 2018 (UTC)[reply]
Yes, it should be possible for a script to be written that a Commons admin could use (or, alternatively, a bot with the admin bit could be written to do the task). —RP88 (talk) 07:18, 29 August 2018 (UTC)[reply]
After some more experiments, there doesn't seem to any way to correctly set the content model of a page to the map.json content model, even a page named "xxxx.map" in Data namespace, other than by directly creating the page. I tested with valid map.json contents and I couldn't get it to work with a page move, neither setting the content model before the move or after the move worked. This seems like a bug to me. —RP88 (talk) 03:59, 29 August 2018 (UTC)[reply]
Tracked in Phabricator
Task T203062
Reported as phab:T203062 - Evad37 [talk] 06:57, 29 August 2018 (UTC)[reply]

Should we change templates like Template:USRD to refer to needing JSON (and sending it to Commons) instead of KML? Should we go through and change project pages to suggest using JSON instead of KML? It seems that if we keep encouraging KML, or uploading JSON to enwiki, we'll just be stuck with more pages on enwiki that we can't delete due to our inability to import to Commons (or with KML, being stuck with it forever). --Rschen7754 18:31, 31 August 2018 (UTC)[reply]

I think the banners need to have the ability to check for the Wikidata page first. I think there is a surprising number of articles that aren't linked to WD. –Fredddie™ 21:01, 31 August 2018 (UTC)[reply]

There is some related discussion at Wikipedia:Village_pump_(proposals)#OpenStreetMap. It's not clear what most people over there are talking about, but it seems some of them are against any kind of map on road articles. Nemo 16:45, 5 August 2019 (UTC)[reply]

Updates

[edit]

Some of you have probably seen me tooling around in the Road data modules the last couple weeks and have been wondering what I'm doing. In short, I am taking it upon myself to Luafy the infobox. There are a few modules that I'm working on; here's where I'm at and how you can help:

Module:Infobox road/route
This is what will draw the shields and put the name of the highway. For this to work properly, we need to add a couple parameters for full functionality:
  1. shieldmain: For instance, this will call specific shields where we use generic shields in Jct. Think Media:I-80 (IA 1957).svg instead of Media:I-80.svg.
  2. name: This is the name of the highway without the state modifier, e.g. State Route 1 instead of California State Route 1.
At present this module works almost as intended. I have even written in the ability for names to go above shields (Australia) if desired. Earlier I had written it so it will take accept shield if shieldmain doesn't exist. I took it out, but I'm really thinking of putting it back.
Multiple shields is the one thing that still doesn't work. Currently, {{Jct}} accepts only 2 shields per route and I borrowed the code from Jct for this module. I'd like to increase that up to 4 infobox shields for Puerto Rico. In addition, shieldmain does not work with the current multiple shield code, so that needs to be addressed as well.  Fixed
NB: this will be used in {{Infobox road small}} as well when the kinks are worked out.
Module:Road data/size
This controls the size of the shields that Module:Infobox road/route uses. I wrote this with the idea that it will be used to control the shield size in this infobox, {{Infobox road small}}, {{Routelist row}}, and {{Jct}}. I added an orientation parameter to the road data string modules for files that are taller than they are wide. What this will do remove the x on the shield size. The default infobox shield size is "x70px"; with orientation = "upright", it would be "70px" instead. The module works great except for one pesky thing: the size module doesn't read orientation at all.  Reworked
So if you know of any "upright" shields, you can add orientation = "upright" to the appropriate type in its road data string module.
Module:Infobox road/sandbox and Module:Infobox road/color/sandbox
What I am doing here is migrating the original color module to Template:Infobox road/styles.css so we can utilize WP:TemplateStyles. Currently, I have am using the color sandbox to filter the types and call the correct style that way. However, if you look at Template:Infobox road/testcases, you will see that it is not working. I also added the "hard coded" |header_type= colors so they will override any module.
As I ponder how to continue with this, I'm thinking the best way is to call the color parameter in the road data string modules. It would eliminate the need for the color module entirely.

So yeah, that's what I've been doing. I really don't know what I'm doing, and I'm amazed I've gone as far as I have. I wanted to thank Happy5214 and Izno for answering my Lua questions when they arise. This has been a fun challenge and I think it'll be great for the encyclopedia when it's done. If you have any questions, comments, concerns, or requests, fire away. –Fredddie™ 23:44, 19 February 2021 (UTC)[reply]

A quick update, Module:Infobox road/route is now working great in concert with Module:Road data/size. You can see it working at Template:Infobox road/testcases. Shields are now sized independently, so if you have a taller shield and a wider shield in your shieldmain table they will be sized accordingly!
Now I turn my attention to the colored headers. –Fredddie™ 01:48, 7 March 2021 (UTC)[reply]

Size non-upright browse icons differently

[edit]

Currently, there is code in place to size non-upright browse icons differently, like how {{Jct}} does, but it is not currently being used. I want to make sure the new appearance is preferred before activating the code. I added some demos for affected browse routes below. @Vaselineeeeeeee is this size better for Italian RA highways?

Demos
Location
CountryItaly
Highway system
← RA 1→ RA 3
Location
CountryItaly
Highway system
← RA 1→ RA 3
Location
CountryItaly
Highway system
← E1→ E3
Location
CountryItaly
Highway system
← E1→ E3
Location
CountryChina
Highway system
← AH1→ AH3
Location
CountryChina
Highway system
← AH1→ AH3
Location
CountryAustralia
StateNew South Wales
Highway system
Highways in New South Wales
← State Route A1 
Location
CountryAustralia
StateNew South Wales
Highway system
Highways in New South Wales
← State Route A1 

– BrandonXLF (talk) 04:08, 22 August 2024 (UTC)[reply]

@BrandonXLF: Sorry missed this. @LukeWiller: which do you like? Vaselineeeeeeee★★★ 02:04, 2 September 2024 (UTC)[reply]
@BrandonXLF: @Vaselineeeeeeee: yes, thanks, they are perfect... :-) LukeWiller (talk) 13:23, 2 September 2024 (UTC).[reply]
@BrandonXLF: @Vaselineeeeeeee: sorry, I have a question (I think I expressed myself badly in my previous message): why didn't they also enlarge the icons at the bottom of the template rectangle? In my opinion the second demo (with the enlarged icons) is perfect. Sorry again, but I think the misunderstanding was my fault. LukeWiller (talk) 21:51, 30 September 2024 (UTC).[reply]
@LukeWiller The templates with the small icons are the current version of the template for comparison. The updated template would produce the 2nd, 4th, 6th, and 8th demos. – BrandonXLF (talk) 06:24, 1 October 2024 (UTC)[reply]
@BrandonXLF: Yes, I guessed it: in my opinion bigger icons are much better in all cases. LukeWiller (talk) 08:14, 1 October 2024 (UTC).[reply]

Edit request 16 September 2024

[edit]

Description of suggested change: Please close the bold tag on the following line in Module:Infobox road/browselinks, the missing tag is causing lint errors on Aviation Parkway (Ottawa) and a few other pages.

Diff:

−
provinces = "'''[[National Capital Commission#Ottawa_parkways|NCC parkways in Ottawa]]"
+
provinces = "'''[[National Capital Commission#Ottawa_parkways|NCC parkways in Ottawa]]'''"

- Gamapamani (talk) 03:41, 16 September 2024 (UTC)[reply]

 Done}. Imzadi 1979 → 03:46, 16 September 2024 (UTC)[reply]
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Infobox_road&oldid=1255173883"