![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 |
Aesthetic:
Usability:
Route Markers:
Nbound ( talk) 10:51, 30 May 2013 (UTC)
I guess we should decide on the extra terms for "Freeway", did we want to add equivalents (with no functional template difference), for Expressway, Parkway, Motorway, etc. Or do we want to use the generic Freeway term Australia wide? -- Nbound ( talk) 11:44, 30 May 2013 (UTC)
According to the instructions, the through parameter is a list of "suburbs and other settlements". Leach Highway; for example, uses this parameter, and the infobox displays as "Major settlements". I suggest that it would be more appropriate to describe Leach Hwy as passing through suburbs, not settlements, but it's not obvious to me how to change the display label from settlement to suburb. Mitch Ames ( talk) 03:20, 3 June 2013 (UTC)
|type = highway
" to "|type = city highway
". There is a work-in-progress example of the preferred usage of this info box at
Wikiproject Australian Roads --
Nbound (
talk)
03:29, 3 June 2013 (UTC)
"If you get the type set correctly, which it wasn't ..."And that's exactly the problem. The type wasn't set correctly, but it wasn't obviously wrong - Leach Highway is a "highway" to the casual reader/editor (including someone comfortable using templates, but not familiar with the details of this specific one). I saw that the suburb/settlement display was wrong, because it was "obviously" wrong, but there's hint that the problem is the type, which does not appear to be wrong (Leach Highway is a "highway" - no apparent problem there), so there's no obvious way for me to fix the problem.
Since we're going to all this trouble, would it be a good idea to have a part of the infobox that asks how the highway is/has been funded? (ie auslink, national highway etc)
I've now been through every one of the several hundred articles that were in Category:Australian road articles using deprecated parameters and have replaced the deprecated parameters with the new parameters. The category is now empty and there should therefore be no articles using deprecated parameters. I intend waiting a few days and will then remove the deprecated parameters from the template and documentation unless anyone has any objections. -- AussieLegend ( ✉) 23:11, 7 June 2013 (UTC)
I propose that the template should automatically
except that abbreviations (NW etc) should be all upper case.
This would allow the displayed text to comply with MOS:COMPASS. Mitch Ames ( talk) 07:38, 8 June 2013 (UTC)
direction_a
and direction_b
aren't only used for "General direction", they're used elsewhere. If we decap direction_b
you'll see something like what is shown in the infobox at right. --
AussieLegend (
✉)
08:07, 8 June 2013 (UTC)The MOS does allow occasional breaches, its is a guideline. I think given the circumstances its fine to ignore it here... The only other option is to use the abbreviated points for even the standard directions.
Either we ignore (my preferred), or we abbreviate all (not preferred but better than the original proposal above IMHO). -- Nbound ( talk) 08:24, 8 June 2013 (UTC)
I find the KML feature of this template troubling. The following is an excerpt of a comment I have posted in response to an Australian ACR: I don't understand what benefit there is in eschewing {{ Attached KML}} in favor of integration with the infobox. Though it was borne out of a discussion at WT:HWY, Attached KML is no longer a template specific to roads, and it can be found on pages in many topic areas on Wikipedia. Currently, it is transcluded in 4,284 pages. (You can even find it on 2013 Moore tornado, complete with KML data provided by the National Weather Service.) Google uses data provided by Attached KML in its search results. (Google "Creek Turnpike", for instance—it displays a map with our KML overlaid on it. Googling "Kwinana Freeway" also displays a map with the KML at time of writing, but I would wager that it will disappear when Google recrawls the page, as the KML has only been moved to the infobox today.) My understanding of the way that Infobox Australian road works is that the KML data is being stored as subpages of the infobox, not Attached KML. This is a poor decision because it splits up KML data across multiple locations. Were all KML data at Attached KML, it would be trivial for a reuser of our KML data, like Google, to see if an article has a KML; all they have to do is visit "Template:Attached KML/[pagename]". If the KML data for Australian road articles is stored elsewhere, that data is "off the grid". It is not as easily discoverable. Data reusers will have to code their software to look for data at multiple locations. They might decide to not bother to use Australian KML data (or simply not know that they must take the extra step to get to it), or scrap plans to use Wikipedia's KML data over concerns that its location is unstable (especially if this opens the door to similar infobox-KML storage schemes in the future). The end result of all of this is that this article breaks compatibility with a Wikipedia-wide convention, which may ultimately detract from its chances at FAC. — Scott5114 ↗ [EXACT CHANGE ONLY] 10:22, 8 June 2013 (UTC)
|kml=yes
is useless if you don't know the file exists. There's no guarantee that the uploader has modified the article talk page, so keeping them in a smaller group makes management much easier. Effectively {{Attached KML}}
(which doesn't own the files) has 4,200 files in a single "category", which is unworkable. With any other file, we'd categorise them by country and then by state/province but, since we can't do that, we need some other option. The system implemented for this template is more easily manageable. Individual file talk pages don't need the project banner added as they're in a subpage of the main template and there are clear directions on how to find the files. So yes, there was a lot of thought for the consequences, despite your assertion. "When" KML data is migrated to Wikidata we will revisit the way we manage the files but, until then, this seems the best option.Discussion on this subject is taking place at Template talk:Attached KML; it would probably be better to continue over there where more people are involved. — Scott5114 ↗ [EXACT CHANGE ONLY] 22:23, 8 June 2013 (UTC)
I've tweaked the KML code based on comments made at Nbound's talk page.
[3] With the new code, which is only in the sandbox at present, |kml=yes
is no longer used. Instead, the template automatically detects the presence of a KML file and automatically adds the links to the infobox. In cases like
Kwinana Freeway, where the infobox links are not required due to the presence of a location map image, |kml_inline=no
suppresses the infobox links and moves them to the title bar. |kml=no
suppresses kml usage entirely, although this parameter really only applies to
Kwinana Freeway at the moment. --
AussieLegend (
✉)
20:55, 10 June 2013 (UTC)
The examples page should probably transclude the current revisions of the infoboxes. Dont need to worry about keeping them up-to-date that way. Thoughts? -- Nbound ( talk) 04:17, 12 June 2013 (UTC)
Ah fair enough... just had to clean up some shields at the top of half a dozen articles because a guy innocently got the wrong idea from the page... Hopefully though, now that the bigger changes have been done, the boxes shouldnt differ too much from reality for the short-mid term -- Nbound ( talk) 04:34, 12 June 2013 (UTC)
Ive added Motorway, Expressway, and Parkway to the sandbox template with some testing here: Template:Infobox Australian road/Testing
Ive also changed "Major suburbs" to "Major suburbs/ towns" as not all of these roads are restricted to the city areas. (eg. Federal Highway is designated a motorway under the new shielding scheme), will help with some rural motorways in Victoria too.
If people are happy, I'll merge the changes. If not Ill revert the sandbox :)
-- Nbound ( talk) 03:21, 6 June 2013 (UTC)
Use of "settlements" has always been problematic, often for the reason mentioned. Consider referring to New York (or New Yourk, New Yourk - couldn't resist that one) as a settlement. There's also the issue that some of the places aren't actually settlements at all, even though they are. For example, the Newcastle Interchange on the F3 is at Cameron Park, which is a suburb of the city of Lake Macquarie and has a population of 5,166. However, the interchange is not within an actiual settlement, it's about 2km west of it. Regarding the slash, it's important to remember that the MOS is a style guideline, not a hard and fast policy that must be followed at all costs (Even our core policies have exceptions). One of the reasons for this is that you can't cover every eventuality, so there is room for justified diversion from what the MOS says. Some parts of the MOS specifically cater for this. For example, WP:MONTH says "Months are expressed as whole words". However, it also says "abbreviations such as Feb ... are used only where space is extremely limited, such as in tables and infoboxes." There's another such example at WP:MOS which says, "Where space is limited (such as tables, infoboxes, parenthetical notes, and mathematical formulas) use unit symbols. In main text it is usually better to spell out unit names". One editor recently reminded me that WP:EL says external links are not permitted in the body of the article and said that infoboxes including external links will not pass FAC, but when I asked at FAC I was directed to articles that had passed FAC with external links in them. Infoboxes are often excluded from strict MOS compliance because of the space restriction and use of the slash is one of those cases; it is better to use the slash than have to be verbose about what is required. Remember too, that WP:SLASH only says "generally avoid joining two words by a slash". It doesn't mandate it, nor can it. If we were talking about the prose section of an article, I'd argue for full compliance, but since infoboxes are space restricted, I really don't think we have to comply with the MOS at all costs. -- AussieLegend ( ✉) 14:28, 14 June 2013 (UTC)
Test infobox | |
---|---|
Header | |
Label | Data |
Below | |
The link to the "Infobox instructions" was removed,
[4] because another editor thought it looked "goofy".
[5] This editor also argued that he hadn't seen such links in other infoboxs and "Wikipedia is written for the reader, not the editor".
Template:Infobox includes the parameter name
, which adds "view/discuss/edit" links to the bottom of the infobox (see the example) so, while the editor may think it's goofy, it is certainly a supported function in an infobox used in 1,350,505 articles. These same links are available, by default, in every navbox. However, for the reader, they're not descriptive and allow the reader to directly edit the linked file, which is highly undesirable when the linked file is the template itself. They also link the reader to the talk page, which is generally unnecessary. For this reason, a specific link to "
Infobox instructions" was used. This is of benefit to our readers because it allows them access to the documentation to so that they know why particular terminology is used or what a particular field means. This is why the "view/discuss/edit" links are included in {{
Infobox}}. It's important not to make impulsive decisions based on what one editor says, especially given that there is a group of editors who clearly don't like this infobox and seem to be ding everything they can to disrupt it. Coincidentally, the editor with the "goofy" problem is the same editor who recently told me that FAC doesn't like infoboxes that include external links.
[6] Instead of immediately removing the links from the infobox, I asked at FAC and was directed to some articles that did not agree with that editor's concern.
[7] Individual concerns need to examined, but they should not be acted on without good reason. --
AussieLegend (
✉)
05:38, 15 June 2013 (UTC)
below
field is "Infobox instructions", in a small font and taking up about 1/3 of the width, which seems a reasonably balanced size given the space available, especially for our sight impaired readers. If we made it smaller, it would be too hard to read, and if we abbreviated it the purpose would be unclear. That it is "self-referential", is pretty much the point of the link in the first place. The example for use of name
in {{
Infobox}} is that it links to the documentation page, which is what the link here did, so it's just following precedent. --
AussieLegend (
✉)
08:24, 15 June 2013 (UTC)Would there be any concerns with having a parameter along the lines of the above. basically just to list the road's internal/legal classification (which can differ from how it may be named)? It would also be good to include its applicable internal designation -- Nbound ( talk) 06:21, 2 August 2013 (UTC)
<parametername>_ref
" input, link to the default listings, otherwise use "<parametername>_ref
") - Could even do it in Lua. --
Nbound (
talk)
14:31, 2 August 2013 (UTC)
I think its time we look at the locations issue again. From the section (Motorway, etc.) above "Major suburbs/ towns" was the preferred label for freeways (and motorways etc.) as it covered both rural and urban settings. So is there any reason not to extend this logic to cover all road types? Why should we need to differentiate between a "highway" and a "city highway", but not between freeways?
A separate but related issue is whether to have a parameter, such as |urban=yes
, to take away the "/towns" when it has absolutely no business being there, such as a freeway or other road entirely within a single city.
Finally, the link for highway was recently changed to Limited-access road ( [10]). However, not every highway is limited access, so its a bit misleading to hide that link behind the word highway. Perhaps if we want to differentiate between Controlled access highways (ie freeways etc), Limited access roads, Arterial roads, Streets, and tracks, those are the labels we should use. - Evad37 ( talk) 02:55, 10 July 2013 (UTC)
urban
parameter. We just need to determine what we need to add. For example, are there any non-urban parkways? (It's not a term we really use in NSW) I do agree with the links for "highway". The Pacific Highway is a good example. Through the cities of Newcastle and Lake Macquarie, the Pacific Highway is almost exclusively not limited access. --
AussieLegend (
✉)
03:39, 10 July 2013 (UTC)A highway is any public road or other public way on land; the term exists in distinction to waterway. In North American and Australian English, the term frequently implies a major road such as a controlled-access highway or an arterial, generally under the control of a state or provincial agency instead of a local road authority.
that same lead also says they are frequently controlled access (which is largely untrue), or are arterial roads (which are described as a "high-capacity urban road."), which again is largely untrue. The ambiguity of city is only resolved if someone questions it enough to follow the link. If we did decide to drop cities, we could use LGAs... Ive not been a massive fan of that in the past but it less messy. It also leaves the ACT without a suitable equivalent (unless it had an exception and still used suburbs). -- Nbound ( talk) 14:03, 10 July 2013 (UTC)
urban
. When |urban=yes
, the label is "Major suburbs". For anything else, the labels are as they have been. --
AussieLegend (
✉)
15:47, 10 July 2013 (UTC)
loctype=urban/mixed/rural
), which is now even less of a coding leap. Assuming we dont want to take that further step, what should our our label be for non-urban (will it be a catchall, or will it be "major settlements" or similar) --
Nbound (
talk)
21:44, 10 July 2013 (UTC)
So, where are we at with this? Despite some inefficiencies with highway, I'm all for linking to this as it's more accurate than the current links. Do we need to go beyond what I've got in the sandbox regarding city/urban and, if so, what are we going to use? -- AussieLegend ( ✉) 13:02, 2 August 2013 (UTC)
I have been looking into classifications, and found this document [13] (page 18) has some relevant information:
What we should really be using for road type is a functional classification, rather than a legal/administrative (which could still be included separately)... but that's probably going to be different in each state/territory, and may or may not be easy to find out. - Evad37 ( talk) 06:54, 10 August 2013 (UTC)
The problem isnt so much the terms themselves, but instead the lack of source to back them up, its OR. As I have stated earlier, whether its the legal classification, strategic, functional, whatever else, as long as there is something to back these up (the legal classification thing is secondary to the main issue*). As long as our classifications are based on something tangible and reasonable Im all good. What happens when Kings Highway or Olympic Highway (for example [these are roads where the name and legal class dont line up]) go for ACR/FA and someone realises the roads arent actually highways and were never proclaimed as one, and we cant find a source to back up our position? It would fail. If we have to rewrite/redesign parts of the infobox then so be it :) -- Nbound ( talk) 13:32, 10 August 2013 (UTC)
Another relatively major change. The secondary names are now equal in size to the primary ones, this going to be confusing for readers, and looks extremely odd on articles like Pacific Motorway (Sydney–Newcastle) -- Nbound ( talk) 14:12, 10 August 2013 (UTC)
Quite happy to defer to the rule of the mob here but do we really need an extra line that states "Australia". None of the states have duplicates overseas and 3 of them include "Australia" or a derivative in the state name itself. I personally think it looks a little odd in its current position/style as well -- Nbound ( talk) 14:12, 10 August 2013 (UTC)
country
parameter. Because of the nature of the infobox, and the possibility of more than one state name, including Australia anywhere but on its own line can pad the infobox width unnecessarily. --
AussieLegend (
✉)
14:28, 10 August 2013 (UTC)
|State2=
used to accept plain text but now rejects it. Can we please discuss changes where the accepted inputs are changing (well any major change really, of course :D ), roads use the plain text capabilites of that section (usually to list a third state). --
Nbound (
talk)
14:04, 10 August 2013 (UTC)
direction_b
and end_b
, just as state
corresponds to direction_a
and end_a
. --
AussieLegend (
✉)
14:39, 10 August 2013 (UTC)
direction_b
and end_b
. It will automatically be converted to the full state name and wikilinked", what makes you think he'd look at AURD and make the link in a discussion that didn't even mention the codes? --
AussieLegend (
✉)
15:07, 10 August 2013 (UTC)
|state2=
. The only point im making is a headsup would have been a bit better (for this, and any other major changes [ie. not spelling or link changes]), and we can then all keep an eye out for things like this and other odd behaviours. Some roads articles are very low traffic so are unlikely to be checked often and could contain major issues for weeks or months. I think it stopped working with plaintext when the Australia link was added (I only noticed it very recently and it affects that parameter). I never checked the diff when you added the link originally (was too busy with an article), and had assumed up until tonight it was probably hardcoded in its own section. And thus my odd usage of state2 would have been unaffected. --
Nbound (
talk)
15:53, 10 August 2013 (UTC)
route_image
and its variants have been in the template for a long time, state2
has only been in since there was a major upgrade of the infobox that catered for many of the misuses that had crept in over many years. The current template is far more forgiving than the old one was in some circumstances while better highlighting some misuses. The changes that were made were not major changes, they were simply code updates to fix things like classes that shouldn't affect a properly filled out infobox. Even the font changes fall into this category. Spelling fixes are minor but link changes are not trivial, as the discussion over "highway" has revealed. That discussion, along with the others shows that most glitches are picked up fairly quickly and when they are, they are usually a simple fix. I wouldn't be too worried about errors in articles, most articles contain errors that have been around for years. We fix them when we can. I fixed one a short time ago that had been in an article for over 7 years and while fixing 1,400 outward links that were recently broken,
[14] I've found hundreds of errors that I expect will be there for some time to come. --
AussieLegend (
✉)
17:20, 10 August 2013 (UTC)
In October 2013 it was proposed that a small version of the infobox be created. The discussion, which ended with a solution, but no consensus to proceed with implementation, is now archived at
Wikipedia talk:WikiProject Australian Roads/Archive 4#infobox Australian road (small). Rather than create an entirely separate template, it was much easier to add a small
parameter to the existing infobox. Subsequent discussion has indicated that there is no desire to proceed at this time.
[15] The purpose of this thread is simply to note the changes that were required, should there be some desire to address this issue in the future. These changes may be seen
here. Testcases were removed in
this edit of
Template:Infobox Australian road/testcases. --
AussieLegend (
✉)
01:16, 3 January 2014 (UTC)
I think that the current "Allocation" label, which links to
Route number#Australia, and is set by the |route=
parameter, should be changed to "Route" (or similar, perhaps "Road route" or "Route number"). I'm not sure how the term came about, but it seems to be specific to Wikipedia. I have not seen it used in either reliable sources, or "roadgeek" sites such as OzRoads. "Route" more accurately describes the information listed there, as well as matching the parameter name and the linked article. -
Evad37 [
talk
03:41, 3 January 2014 (UTC)
route
– but a hidden note could still be added to the blank code page, ie <!-- Allocated road route, NOT the physical route -->
. "Route" also has an advantage in that "Former allocation" could become "Former route" and not need to wrap across two lines. The other options are alright, and better than "Allocation", but I prefer the plain "Route". -
Evad37 [
talk
10:47, 12 January 2014 (UTC)
As of today, there are no instances in articles where |type=
is undefined or set incorrectly. Should we make |type=
a required parameter, and display error messages if not used correctly, rather just tracking usage in the hidden
Category:Australian road articles using deprecated parameters? The logic behind this is that Undefined is not really a type of road, its actually an editor not using the template correctly - an error message with an appropriate link could get them to fix it themselves. I started coding in the sandbox, but the documentation would also need to be adjusted. -
Evad37 [
talk
05:13, 19 April 2014 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 |
Aesthetic:
Usability:
Route Markers:
Nbound ( talk) 10:51, 30 May 2013 (UTC)
I guess we should decide on the extra terms for "Freeway", did we want to add equivalents (with no functional template difference), for Expressway, Parkway, Motorway, etc. Or do we want to use the generic Freeway term Australia wide? -- Nbound ( talk) 11:44, 30 May 2013 (UTC)
According to the instructions, the through parameter is a list of "suburbs and other settlements". Leach Highway; for example, uses this parameter, and the infobox displays as "Major settlements". I suggest that it would be more appropriate to describe Leach Hwy as passing through suburbs, not settlements, but it's not obvious to me how to change the display label from settlement to suburb. Mitch Ames ( talk) 03:20, 3 June 2013 (UTC)
|type = highway
" to "|type = city highway
". There is a work-in-progress example of the preferred usage of this info box at
Wikiproject Australian Roads --
Nbound (
talk)
03:29, 3 June 2013 (UTC)
"If you get the type set correctly, which it wasn't ..."And that's exactly the problem. The type wasn't set correctly, but it wasn't obviously wrong - Leach Highway is a "highway" to the casual reader/editor (including someone comfortable using templates, but not familiar with the details of this specific one). I saw that the suburb/settlement display was wrong, because it was "obviously" wrong, but there's hint that the problem is the type, which does not appear to be wrong (Leach Highway is a "highway" - no apparent problem there), so there's no obvious way for me to fix the problem.
Since we're going to all this trouble, would it be a good idea to have a part of the infobox that asks how the highway is/has been funded? (ie auslink, national highway etc)
I've now been through every one of the several hundred articles that were in Category:Australian road articles using deprecated parameters and have replaced the deprecated parameters with the new parameters. The category is now empty and there should therefore be no articles using deprecated parameters. I intend waiting a few days and will then remove the deprecated parameters from the template and documentation unless anyone has any objections. -- AussieLegend ( ✉) 23:11, 7 June 2013 (UTC)
I propose that the template should automatically
except that abbreviations (NW etc) should be all upper case.
This would allow the displayed text to comply with MOS:COMPASS. Mitch Ames ( talk) 07:38, 8 June 2013 (UTC)
direction_a
and direction_b
aren't only used for "General direction", they're used elsewhere. If we decap direction_b
you'll see something like what is shown in the infobox at right. --
AussieLegend (
✉)
08:07, 8 June 2013 (UTC)The MOS does allow occasional breaches, its is a guideline. I think given the circumstances its fine to ignore it here... The only other option is to use the abbreviated points for even the standard directions.
Either we ignore (my preferred), or we abbreviate all (not preferred but better than the original proposal above IMHO). -- Nbound ( talk) 08:24, 8 June 2013 (UTC)
I find the KML feature of this template troubling. The following is an excerpt of a comment I have posted in response to an Australian ACR: I don't understand what benefit there is in eschewing {{ Attached KML}} in favor of integration with the infobox. Though it was borne out of a discussion at WT:HWY, Attached KML is no longer a template specific to roads, and it can be found on pages in many topic areas on Wikipedia. Currently, it is transcluded in 4,284 pages. (You can even find it on 2013 Moore tornado, complete with KML data provided by the National Weather Service.) Google uses data provided by Attached KML in its search results. (Google "Creek Turnpike", for instance—it displays a map with our KML overlaid on it. Googling "Kwinana Freeway" also displays a map with the KML at time of writing, but I would wager that it will disappear when Google recrawls the page, as the KML has only been moved to the infobox today.) My understanding of the way that Infobox Australian road works is that the KML data is being stored as subpages of the infobox, not Attached KML. This is a poor decision because it splits up KML data across multiple locations. Were all KML data at Attached KML, it would be trivial for a reuser of our KML data, like Google, to see if an article has a KML; all they have to do is visit "Template:Attached KML/[pagename]". If the KML data for Australian road articles is stored elsewhere, that data is "off the grid". It is not as easily discoverable. Data reusers will have to code their software to look for data at multiple locations. They might decide to not bother to use Australian KML data (or simply not know that they must take the extra step to get to it), or scrap plans to use Wikipedia's KML data over concerns that its location is unstable (especially if this opens the door to similar infobox-KML storage schemes in the future). The end result of all of this is that this article breaks compatibility with a Wikipedia-wide convention, which may ultimately detract from its chances at FAC. — Scott5114 ↗ [EXACT CHANGE ONLY] 10:22, 8 June 2013 (UTC)
|kml=yes
is useless if you don't know the file exists. There's no guarantee that the uploader has modified the article talk page, so keeping them in a smaller group makes management much easier. Effectively {{Attached KML}}
(which doesn't own the files) has 4,200 files in a single "category", which is unworkable. With any other file, we'd categorise them by country and then by state/province but, since we can't do that, we need some other option. The system implemented for this template is more easily manageable. Individual file talk pages don't need the project banner added as they're in a subpage of the main template and there are clear directions on how to find the files. So yes, there was a lot of thought for the consequences, despite your assertion. "When" KML data is migrated to Wikidata we will revisit the way we manage the files but, until then, this seems the best option.Discussion on this subject is taking place at Template talk:Attached KML; it would probably be better to continue over there where more people are involved. — Scott5114 ↗ [EXACT CHANGE ONLY] 22:23, 8 June 2013 (UTC)
I've tweaked the KML code based on comments made at Nbound's talk page.
[3] With the new code, which is only in the sandbox at present, |kml=yes
is no longer used. Instead, the template automatically detects the presence of a KML file and automatically adds the links to the infobox. In cases like
Kwinana Freeway, where the infobox links are not required due to the presence of a location map image, |kml_inline=no
suppresses the infobox links and moves them to the title bar. |kml=no
suppresses kml usage entirely, although this parameter really only applies to
Kwinana Freeway at the moment. --
AussieLegend (
✉)
20:55, 10 June 2013 (UTC)
The examples page should probably transclude the current revisions of the infoboxes. Dont need to worry about keeping them up-to-date that way. Thoughts? -- Nbound ( talk) 04:17, 12 June 2013 (UTC)
Ah fair enough... just had to clean up some shields at the top of half a dozen articles because a guy innocently got the wrong idea from the page... Hopefully though, now that the bigger changes have been done, the boxes shouldnt differ too much from reality for the short-mid term -- Nbound ( talk) 04:34, 12 June 2013 (UTC)
Ive added Motorway, Expressway, and Parkway to the sandbox template with some testing here: Template:Infobox Australian road/Testing
Ive also changed "Major suburbs" to "Major suburbs/ towns" as not all of these roads are restricted to the city areas. (eg. Federal Highway is designated a motorway under the new shielding scheme), will help with some rural motorways in Victoria too.
If people are happy, I'll merge the changes. If not Ill revert the sandbox :)
-- Nbound ( talk) 03:21, 6 June 2013 (UTC)
Use of "settlements" has always been problematic, often for the reason mentioned. Consider referring to New York (or New Yourk, New Yourk - couldn't resist that one) as a settlement. There's also the issue that some of the places aren't actually settlements at all, even though they are. For example, the Newcastle Interchange on the F3 is at Cameron Park, which is a suburb of the city of Lake Macquarie and has a population of 5,166. However, the interchange is not within an actiual settlement, it's about 2km west of it. Regarding the slash, it's important to remember that the MOS is a style guideline, not a hard and fast policy that must be followed at all costs (Even our core policies have exceptions). One of the reasons for this is that you can't cover every eventuality, so there is room for justified diversion from what the MOS says. Some parts of the MOS specifically cater for this. For example, WP:MONTH says "Months are expressed as whole words". However, it also says "abbreviations such as Feb ... are used only where space is extremely limited, such as in tables and infoboxes." There's another such example at WP:MOS which says, "Where space is limited (such as tables, infoboxes, parenthetical notes, and mathematical formulas) use unit symbols. In main text it is usually better to spell out unit names". One editor recently reminded me that WP:EL says external links are not permitted in the body of the article and said that infoboxes including external links will not pass FAC, but when I asked at FAC I was directed to articles that had passed FAC with external links in them. Infoboxes are often excluded from strict MOS compliance because of the space restriction and use of the slash is one of those cases; it is better to use the slash than have to be verbose about what is required. Remember too, that WP:SLASH only says "generally avoid joining two words by a slash". It doesn't mandate it, nor can it. If we were talking about the prose section of an article, I'd argue for full compliance, but since infoboxes are space restricted, I really don't think we have to comply with the MOS at all costs. -- AussieLegend ( ✉) 14:28, 14 June 2013 (UTC)
Test infobox | |
---|---|
Header | |
Label | Data |
Below | |
The link to the "Infobox instructions" was removed,
[4] because another editor thought it looked "goofy".
[5] This editor also argued that he hadn't seen such links in other infoboxs and "Wikipedia is written for the reader, not the editor".
Template:Infobox includes the parameter name
, which adds "view/discuss/edit" links to the bottom of the infobox (see the example) so, while the editor may think it's goofy, it is certainly a supported function in an infobox used in 1,350,505 articles. These same links are available, by default, in every navbox. However, for the reader, they're not descriptive and allow the reader to directly edit the linked file, which is highly undesirable when the linked file is the template itself. They also link the reader to the talk page, which is generally unnecessary. For this reason, a specific link to "
Infobox instructions" was used. This is of benefit to our readers because it allows them access to the documentation to so that they know why particular terminology is used or what a particular field means. This is why the "view/discuss/edit" links are included in {{
Infobox}}. It's important not to make impulsive decisions based on what one editor says, especially given that there is a group of editors who clearly don't like this infobox and seem to be ding everything they can to disrupt it. Coincidentally, the editor with the "goofy" problem is the same editor who recently told me that FAC doesn't like infoboxes that include external links.
[6] Instead of immediately removing the links from the infobox, I asked at FAC and was directed to some articles that did not agree with that editor's concern.
[7] Individual concerns need to examined, but they should not be acted on without good reason. --
AussieLegend (
✉)
05:38, 15 June 2013 (UTC)
below
field is "Infobox instructions", in a small font and taking up about 1/3 of the width, which seems a reasonably balanced size given the space available, especially for our sight impaired readers. If we made it smaller, it would be too hard to read, and if we abbreviated it the purpose would be unclear. That it is "self-referential", is pretty much the point of the link in the first place. The example for use of name
in {{
Infobox}} is that it links to the documentation page, which is what the link here did, so it's just following precedent. --
AussieLegend (
✉)
08:24, 15 June 2013 (UTC)Would there be any concerns with having a parameter along the lines of the above. basically just to list the road's internal/legal classification (which can differ from how it may be named)? It would also be good to include its applicable internal designation -- Nbound ( talk) 06:21, 2 August 2013 (UTC)
<parametername>_ref
" input, link to the default listings, otherwise use "<parametername>_ref
") - Could even do it in Lua. --
Nbound (
talk)
14:31, 2 August 2013 (UTC)
I think its time we look at the locations issue again. From the section (Motorway, etc.) above "Major suburbs/ towns" was the preferred label for freeways (and motorways etc.) as it covered both rural and urban settings. So is there any reason not to extend this logic to cover all road types? Why should we need to differentiate between a "highway" and a "city highway", but not between freeways?
A separate but related issue is whether to have a parameter, such as |urban=yes
, to take away the "/towns" when it has absolutely no business being there, such as a freeway or other road entirely within a single city.
Finally, the link for highway was recently changed to Limited-access road ( [10]). However, not every highway is limited access, so its a bit misleading to hide that link behind the word highway. Perhaps if we want to differentiate between Controlled access highways (ie freeways etc), Limited access roads, Arterial roads, Streets, and tracks, those are the labels we should use. - Evad37 ( talk) 02:55, 10 July 2013 (UTC)
urban
parameter. We just need to determine what we need to add. For example, are there any non-urban parkways? (It's not a term we really use in NSW) I do agree with the links for "highway". The Pacific Highway is a good example. Through the cities of Newcastle and Lake Macquarie, the Pacific Highway is almost exclusively not limited access. --
AussieLegend (
✉)
03:39, 10 July 2013 (UTC)A highway is any public road or other public way on land; the term exists in distinction to waterway. In North American and Australian English, the term frequently implies a major road such as a controlled-access highway or an arterial, generally under the control of a state or provincial agency instead of a local road authority.
that same lead also says they are frequently controlled access (which is largely untrue), or are arterial roads (which are described as a "high-capacity urban road."), which again is largely untrue. The ambiguity of city is only resolved if someone questions it enough to follow the link. If we did decide to drop cities, we could use LGAs... Ive not been a massive fan of that in the past but it less messy. It also leaves the ACT without a suitable equivalent (unless it had an exception and still used suburbs). -- Nbound ( talk) 14:03, 10 July 2013 (UTC)
urban
. When |urban=yes
, the label is "Major suburbs". For anything else, the labels are as they have been. --
AussieLegend (
✉)
15:47, 10 July 2013 (UTC)
loctype=urban/mixed/rural
), which is now even less of a coding leap. Assuming we dont want to take that further step, what should our our label be for non-urban (will it be a catchall, or will it be "major settlements" or similar) --
Nbound (
talk)
21:44, 10 July 2013 (UTC)
So, where are we at with this? Despite some inefficiencies with highway, I'm all for linking to this as it's more accurate than the current links. Do we need to go beyond what I've got in the sandbox regarding city/urban and, if so, what are we going to use? -- AussieLegend ( ✉) 13:02, 2 August 2013 (UTC)
I have been looking into classifications, and found this document [13] (page 18) has some relevant information:
What we should really be using for road type is a functional classification, rather than a legal/administrative (which could still be included separately)... but that's probably going to be different in each state/territory, and may or may not be easy to find out. - Evad37 ( talk) 06:54, 10 August 2013 (UTC)
The problem isnt so much the terms themselves, but instead the lack of source to back them up, its OR. As I have stated earlier, whether its the legal classification, strategic, functional, whatever else, as long as there is something to back these up (the legal classification thing is secondary to the main issue*). As long as our classifications are based on something tangible and reasonable Im all good. What happens when Kings Highway or Olympic Highway (for example [these are roads where the name and legal class dont line up]) go for ACR/FA and someone realises the roads arent actually highways and were never proclaimed as one, and we cant find a source to back up our position? It would fail. If we have to rewrite/redesign parts of the infobox then so be it :) -- Nbound ( talk) 13:32, 10 August 2013 (UTC)
Another relatively major change. The secondary names are now equal in size to the primary ones, this going to be confusing for readers, and looks extremely odd on articles like Pacific Motorway (Sydney–Newcastle) -- Nbound ( talk) 14:12, 10 August 2013 (UTC)
Quite happy to defer to the rule of the mob here but do we really need an extra line that states "Australia". None of the states have duplicates overseas and 3 of them include "Australia" or a derivative in the state name itself. I personally think it looks a little odd in its current position/style as well -- Nbound ( talk) 14:12, 10 August 2013 (UTC)
country
parameter. Because of the nature of the infobox, and the possibility of more than one state name, including Australia anywhere but on its own line can pad the infobox width unnecessarily. --
AussieLegend (
✉)
14:28, 10 August 2013 (UTC)
|State2=
used to accept plain text but now rejects it. Can we please discuss changes where the accepted inputs are changing (well any major change really, of course :D ), roads use the plain text capabilites of that section (usually to list a third state). --
Nbound (
talk)
14:04, 10 August 2013 (UTC)
direction_b
and end_b
, just as state
corresponds to direction_a
and end_a
. --
AussieLegend (
✉)
14:39, 10 August 2013 (UTC)
direction_b
and end_b
. It will automatically be converted to the full state name and wikilinked", what makes you think he'd look at AURD and make the link in a discussion that didn't even mention the codes? --
AussieLegend (
✉)
15:07, 10 August 2013 (UTC)
|state2=
. The only point im making is a headsup would have been a bit better (for this, and any other major changes [ie. not spelling or link changes]), and we can then all keep an eye out for things like this and other odd behaviours. Some roads articles are very low traffic so are unlikely to be checked often and could contain major issues for weeks or months. I think it stopped working with plaintext when the Australia link was added (I only noticed it very recently and it affects that parameter). I never checked the diff when you added the link originally (was too busy with an article), and had assumed up until tonight it was probably hardcoded in its own section. And thus my odd usage of state2 would have been unaffected. --
Nbound (
talk)
15:53, 10 August 2013 (UTC)
route_image
and its variants have been in the template for a long time, state2
has only been in since there was a major upgrade of the infobox that catered for many of the misuses that had crept in over many years. The current template is far more forgiving than the old one was in some circumstances while better highlighting some misuses. The changes that were made were not major changes, they were simply code updates to fix things like classes that shouldn't affect a properly filled out infobox. Even the font changes fall into this category. Spelling fixes are minor but link changes are not trivial, as the discussion over "highway" has revealed. That discussion, along with the others shows that most glitches are picked up fairly quickly and when they are, they are usually a simple fix. I wouldn't be too worried about errors in articles, most articles contain errors that have been around for years. We fix them when we can. I fixed one a short time ago that had been in an article for over 7 years and while fixing 1,400 outward links that were recently broken,
[14] I've found hundreds of errors that I expect will be there for some time to come. --
AussieLegend (
✉)
17:20, 10 August 2013 (UTC)
In October 2013 it was proposed that a small version of the infobox be created. The discussion, which ended with a solution, but no consensus to proceed with implementation, is now archived at
Wikipedia talk:WikiProject Australian Roads/Archive 4#infobox Australian road (small). Rather than create an entirely separate template, it was much easier to add a small
parameter to the existing infobox. Subsequent discussion has indicated that there is no desire to proceed at this time.
[15] The purpose of this thread is simply to note the changes that were required, should there be some desire to address this issue in the future. These changes may be seen
here. Testcases were removed in
this edit of
Template:Infobox Australian road/testcases. --
AussieLegend (
✉)
01:16, 3 January 2014 (UTC)
I think that the current "Allocation" label, which links to
Route number#Australia, and is set by the |route=
parameter, should be changed to "Route" (or similar, perhaps "Road route" or "Route number"). I'm not sure how the term came about, but it seems to be specific to Wikipedia. I have not seen it used in either reliable sources, or "roadgeek" sites such as OzRoads. "Route" more accurately describes the information listed there, as well as matching the parameter name and the linked article. -
Evad37 [
talk
03:41, 3 January 2014 (UTC)
route
– but a hidden note could still be added to the blank code page, ie <!-- Allocated road route, NOT the physical route -->
. "Route" also has an advantage in that "Former allocation" could become "Former route" and not need to wrap across two lines. The other options are alright, and better than "Allocation", but I prefer the plain "Route". -
Evad37 [
talk
10:47, 12 January 2014 (UTC)
As of today, there are no instances in articles where |type=
is undefined or set incorrectly. Should we make |type=
a required parameter, and display error messages if not used correctly, rather just tracking usage in the hidden
Category:Australian road articles using deprecated parameters? The logic behind this is that Undefined is not really a type of road, its actually an editor not using the template correctly - an error message with an appropriate link could get them to fix it themselves. I started coding in the sandbox, but the documentation would also need to be adjusted. -
Evad37 [
talk
05:13, 19 April 2014 (UTC)