Template talk:Infobox Australian place

See also: Blank infobox page | Documentation page | Discussion page | Examples page | Testcases

Discussion at Wikipedia:Australian Wikipedians' notice board § Traditional Owners on Template:Infobox Australian place

 You are invited to join the discussion at Wikipedia:Australian Wikipedians' notice board § Traditional Owners on Template:Infobox Australian place. ClaudineChionh (she/her · talk · email · global) 01:37, 19 September 2025 (UTC)

Wrapper for Infobox Settlement

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In the sandbox I have implemented this as a Template wrapper for Infobox settlement. Below is a detailed breakdown of the how and the why. Note that this has also been nominated for merger, the discussion is avaliable here.

Arguments

1. Standardizes the infobox to look like literally every other settlement page on wikipedia. (note that {{Infobox settlement}} is used on over 576,000 pages). While other countries have their own custom infobox, Australia is the only one that does not use {{Infobox settlement}} as a base
2. Makes the code MUCH more readable
3. Cleans up the tracking of unknown parameters. Category:Australian place articles using missing parameters is not needed as there is Category:Pages using infobox Australian place with unknown parameters which is populated by Module:Check for unknown parameters
4. Standardizes the microformats and HTML classes that are applied to information
5. makes use of {{Convert}}. The current template has hardcoded {{rnd|{{{area}}}/2.589988110336|1}} to convert the area from km2 to sq mi...
6. The use of Module:Template wrapper means that all the parameters avaliable at {{Infobox settlement}} (except those already in use by the wrapper) would now be available to {{Infobox Australian place}} automatically. So while not necessarily needed, things like |module= or |native_name= would work without anything additional needing to be done.

Things removed

1. The various colors that clutter the infobox and violate MOS:COLOR

Things kept

1. ALL information. No parameters or information has been removed from the template. It just displays in a different format.
2. The logic behind how coordinates, state and city are determined.
3. The calls to {{IUCN banner}}. However per the documentation at that template, it is supposed to be used on {{Infobox protected area}} which is far better suited for those pages that are calling the IUCN banner. I would argue that the 1100 or so pages that use |iucn_category= should be converted to use {{Infobox protected area}}. Happy to add a tracking category to make that conversion easier if there is interest in perusing that...
4. None of the parameters have changed names. So while some parameters have been removed as mentioned above, none of the parameters have been renamed. This means that if this is implemented, almost zero work will be required to convert existing pages to the new format. The only issue I can foresee is with |image2= as discussed below.
5. The custom logic designed to implement {{short description}} on each page.
6. The custom tracking categories currently in place on {{Infobox Australian place}} (except for Category:Australian place articles using missing parameters per the above statement).

Disclaimer

1. As of posting this comment, no one else has reviewed the code I have written. While I have checked it many times, I almost guarantee I have a typo in it somewhere. If you find that typo, you win a cookie. No but seriously, if you find any obvious typos, links to the wrong target or anything else wrong that comes from my lack of knowledge about Australia, please {{ping|Zackmann08}} and I'll address it right away, or of course feel to simple fix it. --Zackmann (^{Talk to me}/_{What I been doing}) 18:41, 4 October 2025 (UTC)

Comments

• First impression: A number of errors are shown at Template:Infobox Australian place/testcases. Further, I find the lack of OpenStreetMap unacceptable. -- Michael Bednarek (talk) 00:49, 5 October 2025 (UTC)

• @Michael Bednarek: just looked at that. It looks like I have a bad #if: statement somewhere that is resulting in the |state= error that you are seeing. Let me fix that right now. As for the open street map, that is a result of Module:Australian place map which is in use on the current Infobox. It substitutes in the old school pushpin map. I would 100% be in favor of replacing that with the more common {{Infobox mapframe}} which is built into {{Infobox settlement}}. However, I am wary of changing too much too quickly as User:joy has already voiced. This merge attempt has failed before. Can we table that for now and agree it warrants further investigation as a future improvement? Note that I will commit to working on that next assuming this merge/conversion does happen! Zackmann (^{Talk to me}/_{What I been doing}) 00:58, 5 October 2025 (UTC)

• @Michael Bednarek:  Fixed. I did in fact have a missing #if: statement. You should see FAR fewer errors now. Note there will be preview errors still as there are parameters in {{Infobox Australian place}} that are not in {{Infobox Australian place/sandbox}}. Zackmann (^{Talk to me}/_{What I been doing}) 01:07, 5 October 2025 (UTC)

I think we just need to map local_map = 1 into mapframe = on, for Raymond Terrace and similar examples to keep the mapframe. I see you already mapped the qid parameter, so this sounds doable as well. --Joy (talk) 10:44, 5 October 2025 (UTC)

@Joy: sorry I didn't see your comments earlier. Just took care of mapping that parameter. Tested it on Raymond Terrace and it looks good now. --Zackmann (^{Talk to me}/_{What I been doing}) 05:21, 6 October 2025 (UTC)

• I've been using this infobox for many years and we've had this conversation before and people have not supported the change. As I see it, there is no problem with the existing infobox and the proposal for change identifies many things that will need fixing manually. What's the benefit in any of this? The removal of the "near" fields which have a quite compact display to be replaced by a separate box (which seems very space inefficient in the only examples of this box I can see) and appears to be put at the bottom of the article instead of "facts at a glance" which is the purpose of an infobox. Similarly I have code and AWB scripts to help write articles and check them, which are now going to break. I see no upside and plenty of downside. What's the upside here? If it ain't broke, don't fix it. Kerry (talk) 05:20, 5 October 2025 (UTC)

• @Kerry Raymond: appreciate the feedback. As a result of your comments I've made some changes... |image2= and related parameters are back and now work (see the multi image testcase). I have also restored the information about nearby places. While I personally don't think this belongs in an Infobox, that should be a separate discussion. This merge should not remove information from over 10,000 pages. You convinced me. Finally I have restored the |visitation_num= and related params. Your point that the change identifies many things that will need fixing manually is a very fair point. I hope that restoring these three groups of information will help persuade you that this is a worthwhile endeavor.

I must push back on your comment that if it ain't broke, don't fix it. I'd encourage you to spend some time looking at the source code for {{Infobox Australian place}}. It is a mess. Multiple users including Jonesey95, AussieLegend and Frietjes (among many others) have done admirable jobs keeping this template going, but it has been in desperate need of a refactor. To be clear when I say it is a mess I mean no insult to anybody! This code is just old and was written before a lot of the more modern approaches were avaliable. Happy to provide specific examples but I'm sure if you look at the source code you will find many examples of things that we would never do in code today.

With the updates that I just made, there should be ZERO information removed from the infobox if this conversion takes place. No manual checking or converting will need to be done. Let me know if you have any other questions/concerns and thanks again for the feedback! --Zackmann (^{Talk to me}/_{What I been doing}) 07:49, 5 October 2025 (UTC)

Well, I won't offer an argument in support of visitation numbers etc (not sure I've seen an Australian article that uses it but maybe some do). And I agree that at some point we want to resolve the issue of some national parks etc having infobox Australian place and other having infobox protected area and some having both. However, the "active editor" and "very active editor" community in Australia appears to be falling in numbers (I suspect this is not unique to Australia), so wearing my governance and project management hat, we need to use our resources wisely. To me, this means staying focused on what bring us readers (and hence donors to WMF which support the continued operation of our platforms). This means front-of-house activity (more topics, more content on topics) not back-of-house activity (reworking templates). I'm not saying that Infobox Australian place is a nice piece of code (I choose not to look), but, as someone who has written literally thousands of articles that use it, it does seem to work. Kerry (talk) 08:51, 5 October 2025 (UTC)

Well let me help you? The new code will be easier to maintain. It also (IMHO) looks much better. What's best of all, you don't have to do ANYTHING differently. I cannot think of any scenario where the new version would change your AWB processes at all (now that I have restored the additional params that I initially removed that is).

In short, there are those of us (like myself) who much more enjoy working on the dirty coding side of things, while diligent editors like yourself work on adding content. This will work better for all involved. Zackmann (^{Talk to me}/_{What I been doing}) 09:00, 5 October 2025 (UTC)

If we were just talking about cleaning up the code in Infobox Australian place, I would not be so worried, but basing it on Infobox settlement means that changes to that Infobox could flow through to Australian content, whether or not they were appropriate. The Australian community has lost control of many of our Australian templates because they were used on sufficiently many articles that they "had to be" protected (which generally meant the person/people who created and maintained the templates were locked out, i.e. protected against the people who best understood the role and purpose of those templates). If things go badly in the short or long term, there is a lot of risk to those of us who create and/or maintain articles that use the template. So, there is an issue of wanting to keep important Australian templates in the the control of the Australian editing community. You are seeing this as a technical problem/solution, but it's bigger than that. Kerry (talk) 20:22, 5 October 2025 (UTC)

Again I would remind you that no information is being removed from the template. It is simply being styled to look like every other settlement page on Wikipedia... Zackmann (^{Talk to me}/_{What I been doing}) 20:23, 5 October 2025 (UTC)

@Kerry Raymond could you have another look at the history of the sandbox version? In the last three weeks, we've had a number of changes done, by four other people (plus Zackmann08). This should help illustrate the level of complexity involved in modifying and maintaining the wrapper template. --Joy (talk) 07:49, 23 October 2025 (UTC)

• As with several others, "if it's not broke, don't fix it". But I also recognise that uniformity is good, and relying on a small number of experts to maintain the bespoke Australian infobox is not a good outcome. I'm shocked that one of the previous experts stopped contributing in 2022, following an explanation of "...incurable, inoperable and eventually terminal..." metastatic melanoma :-( but it highlights the necessity of multiple people with the capability, time and competence to maintain the template.

My quick comparison on a "real" page (by adding "/sandbox" to the template invocation, then previewing the page) is that the sandbox version does not display the population being pulled from Wikidata. Is this deliberate or an oversight? Population is not mentioned in either kept or removed lists. I also dislike that the line immediately below the name has changed from the state name to either "town" or "suburb" and feel the sandbox gives undue prominence to County in South Australia over LGA. As I continued to try adding /sandbox and previewing a few different pages, I found some that diplayed the preview error "Page using Template:Infobox Australian place with unknown parameter "local_map"" instead of the OSM map. It also rendered the image as "File:File:Alma farm.jpg" instead of the picture. This might be a relatively simple thing to fix in that page, but it's a change which might not generate a clue for a bot to fix promptly. I found another place that the preview showed "Preview warning: Page using Template:Infobox Australian place with unknown parameter "city"", although that parameter appeared to have been used.

In summary, I'm not completely opposed to the concept of standaridisng onto Infobox Settlement, but I don't think the replacement is ready yet, without more discussion and agreement on a few changes, and a bit more bug tracking. --Scott Davis ^Talk 11:00, 5 October 2025 (UTC)

Thanks for the practical testing! Would you be so kind to link or name some of those specific buggy examples? That way it becomes easier to track down and fix. Maybe we can even trouble you to copy&paste them verbatim into new sections of {{Infobox Australian place/testcases}}, just changing the top template name into {{testcase table}}. --Joy (talk) 12:25, 5 October 2025 (UTC)

@ScottDavis: I will second what Joy said. If you can provide a few examples or link to pages where the issue is present, I will track down the issue! That lack of pulling population data from Wikidata is NOT intentional and should definitely be resolved. - Zackmann (^{Talk to me}/_{What I been doing}) 17:23, 5 October 2025 (UTC)

Based on the mention of File:Alma farm.jpg I created Template:Infobox Australian place/testcases#Alma, South Australia to reproduce that issue. --Joy (talk) 11:56, 9 October 2025 (UTC)

@Michael Bednarek [1] isn't the point, the idea is indeed to demonstrate a bug. The solution can be to change the code or to change all such callers, but it's something to be evaluated, not worked around in the test case. --Joy (talk) 20:23, 9 October 2025 (UTC)

• The local_map_caption parameter does not seem to be working in the sandbox version. This caption is necessary to provide temporal context for embedded maps (e.g. Shire of Healesville - the boundaries changed over the years and it needs to be made clear to readers that the map depicts the final boundary of the LGA). This situation needs to be sorted out before a merge can be considered. This, that and the other (talk) 12:37, 5 October 2025 (UTC)

  @This, that and the other: Thank you for finding this. That is definitely NOT an intentional change. I'm researching it right now. It appears you may have found a bug in Module:Infobox mapframe as it seems that is not working properly anywhere! Zackmann (^{Talk to me}/_{What I been doing}) 17:40, 5 October 2025 (UTC)

  @This, that and the other:  Fixed this is now resolved. You actually found a bug in {{Infobox settlement}} that was broken on over a half million pages. Way to go! Zackmann (^{Talk to me}/_{What I been doing}) 18:14, 5 October 2025 (UTC)

  Heh glad to be of use! This, that and the other (talk) 02:43, 6 October 2025 (UTC)

• Before this discussion started, I was actually about to release a module (Lua) version of this infobox. There are some enhancements (including some additional |type= values) which need discussion, and some error-catches that were much easier to code in Lua, but generally the output is unchanged. There is a draft of the module, which has a /doc page giving details of all the proposed changes, and a testcases page comparing the existing and module-based outputs.
  Note that the module calls a modified version of PopulationFromWikidata, so population outputs are not identical - that is really a different discussion, though it should be resolved before a new version of the infobox goes 'public'.

Until there is agreement on the principle of making the current template a wrapper, there doesn't seem any point in doing a transfer of that option to a module, but I'm happy to do it if that is the consensus. I think a module will be easier to maintain in the future than template-only code. Innesw (talk) 07:32, 8 October 2025 (UTC)

Oh, that's a real pity that there's so much duplicate effort. Still, I have to say, the prospect of looking after 47 KB + 6 KB + 28 KB of custom Lua code doesn't quite spark as much joy as looking after the template wrapper which is considerably smaller at 16 KB + 2 KB of template code, plus existing 3.5 KB of Lua code (Module:Australian place map). --Joy (talk) 09:05, 8 October 2025 (UTC)

I can't say I understand why the size of a source-code file indicates anything about the ease of understanding & maintaining it, given that newlines and indents (which add size - and admittedly only when done properly) can only help humans to read the code. Also, the current sandbox code (using Template_wrapper into {{Infobox_settlement}}) has a whole lot of assistance the original template was not using - so it's a bit of an apples & oranges comparison. I'm not trying here to make any assessment about the ease-of-maintenance of the still-in-development template, just that file-size isn't a useful yardstick. Understanding of code is a matter of what language suits particular people I suppose - I much prefer Lua code to template code, as among other things I do not like having to carefully count '{' and '}' to understand or debug it, but I understand how that may not be universal. Innesw (talk) 09:28, 9 October 2025 (UTC)

@Innesw: I'm not sure what Joy was getting at with the code size either. What I will say is a couple of nice things about the wrapper solution:

1. Module:Template wrapper is well maintained and widely used (745,000+ uses). It is known to be bug free at this point.
2. Same goes for Template:Infobox settlement with its 576,000+ uses. This means less custom code to maintain, and more unification of how things are displayed, which is the ultimate goal.
3. By using this Module and Template, any future upgrades will automatically be included.

Hope that helps! - Zackmann (^{Talk to me}/_{What I been doing}) 09:34, 9 October 2025 (UTC)

I'm not necessarily arguing that Template_wrapper and Infobox_settlement are not the way to go, but they could be used with a Lua version of the custom code, and I am arguing that this may be easier to maintain, which depends somewhat, I acknowledge, on personal preference.

We can discuss luafication at a later stage. It really is a side issue at this point.

What we need to get back to is making the current sandbox version as complete & correct as possible, so its technicalities don't interfere with the in-principle discussion that is happening at the merge discussion (on which I have not decided a position).

• There are some changes made in my Lua version that could be included as we go through - or should these be left until later too?
• (particularly if including those changes now is sensible, but even if not) is it OK for others (like me) to adjust the /sandbox code as we go along, or is it etiquette to leave that to a single person?

Innesw (talk) 10:17, 9 October 2025 (UTC)

I'd say that primarily depends on whether changes would address the current phase, for which there's reason to be optimistic that it would be approved. I think whatever edits fix the final issues, e.g. those by @ScottDavis and @Kerry Raymond, should be included without delay, because we should never plan to depend on any single person anyway. --Joy (talk) 11:55, 9 October 2025 (UTC)

Have you run an analysis of how much of those 81 KB is whitespace and indentation by any chance, compared to the other 18? Even if we're being very generous and assuming your custom Lua code is uniformly better than the custom template code, there's still quite a difference there, so I wouldn't assume 81 boils down to less then 18.

But anyway, the more basic aspect is reuse - if the 18k code is really ugly, but if its e.g. 50k or 1500k of dependencies are maintained by others, then we just have to deal with the 18k, as opposed to maintaining more stuff here in perpetuity. Maybe I am biased, because I don't live in DLL hell, YMMV :) --Joy (talk) 11:49, 9 October 2025 (UTC)

• in Subdivisions, I've moved County to below City: it's much less important (in an Australian context) than City, and belongs next to Parish, which are both cadastral-only divisions Innesw (talk) 02:49, 10 October 2025 (UTC)

  @Innesw: thank you!! This is where my American lack of knowledge is an issue... --Zackmann (^{Talk to me}/_{What I been doing}) 03:57, 10 October 2025 (UTC)

• (in the sandbox) I've moved the call to PopulationFromWikidata so it happens whenever |pop=<blank> and there is wikidata to show. It's not good having to call the module once just to know if a section header is needed, and again to display the returned string - maybe there is another solution. I've used demographics1_* because the normal population parms in {{Infobox_settlement}} expect just a number, while the module returns a more complex string. This is not a final solution yet - pop2, rank etc. still need to show below the wikidata population(s). Maybe all the population stuff moves to demographics1_* ? Innesw (talk) 05:03, 10 October 2025 (UTC)

  @Innesw: I can investigate formatting the string better. Can you link me to an Australian place page that has wikidata that I can use for testing? --Zackmann (^{Talk to me}/_{What I been doing}) 06:17, 10 October 2025 (UTC)

  @Innesw and Joy:. Good news. Go over to Sydney's page and insert {{Infobox Australian place/sandbox}} at the top of the page. Click preview. You will see in the tiny Infobox that shows up, the pop and pop_year have been pulled from wikidata and placed in the population section. You can still override them with |pop=### and |pop_year=#### though.

  I will just say this gets to the heart of the issue that this entire merge has been about. Module:PopulationFromWikidata is not maintained nearly as well as Module:WikidataIB (for which {{Population WD}} is a customized wrapper). The later is used on 1.8 million pages and is much more powerful. In any event... Check this diff to see what I did. I did test various combinations (overriding |pop= but not |pop_year= and vise-versa), but keep me posted if you find any issues. -- Zackmann (^{Talk to me}/_{What I been doing}) 06:51, 10 October 2025 (UTC)

  I was thinking, currently the WIB wrapper has ~0.5k transclusions, while PFW has ~5.5k. Are most of the latter because of the 14.5k in this infobox, how can we count the intersection of a module and a template? I'm just trying to figure out if PFW has other users to be able to gauge which one has more potential.

  BTW you could move Sydney's infobox into a test case for this, just copy its Wikidata item into |qid=. --Joy (talk) 08:09, 10 October 2025 (UTC)

  @Joy: I think the custom wrapper ({{population WD}}) has so few transclusions because people are still calling Module:WikidataIB directly. Note that THAT module has 1.8 million transclusions. I chose to use the wrapper because the syntax was easier for me to figure out quickly. I have no objection to moving to use a call to Module:WikidataIB directly. I DO however object to using Module:PopulationFromWikidata. Zackmann (^{Talk to me}/_{What I been doing}) 08:23, 10 October 2025 (UTC)

  OK, so you're saying all of PFW usage is from here, and all of it constitutes another chunk of code (17 KB) that would become obsolete if we were to use the wrappers?

  On the other hand, how does Module:Sandbox/Innesw/PopulationFromWikidata-upgrade work into this? Is there a need for it?

  I'd appreciate a more coherent explanation, because there seems to be a lot of intricacy described in the documentation of each of those. Was it really all overkill? --Joy (talk) 09:18, 10 October 2025 (UTC)

  I have not read through the code in detail but from what I have looked at, it looks like an overly complicated attempt to do what has since become much simpler. This is a common theme. When I redid the infobox I found hardcoded {{rnd|{{{area}}}/2.589988110336|1}} to convert the area from km2 to sq mi. It was never even updated to make use of {{convert}} which has been the standard forever...

  I would be flat out SHOCKED if Module:WikidataIB the associated wrappers cannot do what we need it to do. There is simply no way that a custom Population Module is needed just for Australia... Zackmann (^{Talk to me}/_{What I been doing}) 09:27, 10 October 2025 (UTC)

  • Certainly 99%+ of the calls to PFW will be from the infobox (that is what is was designed for) - though there have been people using it in article text or for tables of populations, but in its current form it doesn't suit those.
  • {{Population_WD}} won't be sufficient, it's just way too general ('return the latest population, regardless of qualifiers').
  • My reading of WIB (correct me if I'm wrong) is that it can't limit the returned value by multiple qualifier values at once. If it can indeed return a population figure that is (a) sourced from an Australian Census, (b) from the latest census, and (c) for a specific applies_to_part value, then there may be a case.
  • But why try to achieve this with WIB (if it's even possible) when it's already there in PFW? Just think of PFW as a sub-module of the Australian infobox, and let it do its specific work. OK, tweak it a bit for its new context (maybe some new function calls, or differently formatted output), but don't throw it away for the sake of using some more general module. It is only the back-end after all - if it gets the required data for output, why re-do a lot of work that is already done?

  Innesw (talk) 22:57, 10 October 2025 (UTC)

  @Innesw: thanks for the information. I will confess, while I've done some deep dives and learning on Wikipedia, Wikidata is something I have yet to get into. So, my knowledge of it is lacking at the moment. With what you have said, I think I'll change my position. @Joy: I have no real stance on the continued use of Module:PopulationFromWikidata. Perhaps someone with more Wikidata experience can help educate me and make it play nice with the Settlement wrapper. I don't see any technical reason why we can't make them work together... Zackmann (^{Talk to me}/_{What I been doing}) 02:27, 11 October 2025 (UTC)

  I wrote the upgrade of PFW, and as for the infobox template, I was on the verge of releasing it for comment. It does fix a number of known issues, and adds some functions for in-article-text use of the same wikidata as for the infobox.

  I'd be happy to modify it to produce more structured output suitable to the wrapper-based infobox, but I'm not sure what the best solution is. Just like the original, it produces a single string with the (formatted) pop-value, the abbreviation for the census-geography it applies to, the year, and the reference(s). Possibly multiple times in a bulleted list if there are multiple census geographies. You can see a number of examples at the bottom of the testcases page. (The current version of the infobox sandbox has broken by your attempts to use {{Population_WD}}, but I think you agree that's a dead-end, and they can be reversed.)

  So what is the best solution here? Keep the single string and put it in demographics1_*? Or somehow break up the return value so it can be put into the multiple Infobox_settlement population fields - remembering that there could be 2 (even 3) different populations to show. Innesw (talk) 06:57, 11 October 2025 (UTC)

  @Innesw: Facepalm why must everything be so complicated... I do agree that's a dead-end, and they can be reversed. Will do that now. What I'm thinking (and will test out in a moment) is to move BOTH population options (the one where you supply |pop=123 and where it is pulled from Wikidata) to the demographics section you had used previously. That way, either way the population data is showing in the same spot.

  One thing of note, doing it this way we loose some of the functionality of {{Infobox settlement}}. Specifically (on that Infobox) if you have a population value and an area value (both of which are just integers) then the population density can be automatically generated. Now after all you've said above, I do NOT think the automatic density is a reason to keep the {{Population WD}} code, but did want to at least mention it.

  Standby for updates, I'll tag you in the edit summary. Zackmann (^{Talk to me}/_{What I been doing}) 07:06, 11 October 2025 (UTC)

  @Innesw: restored your version and added support for |pop2=. Also got density to play nice with the supplied values. Zackmann (^{Talk to me}/_{What I been doing}) 07:35, 11 October 2025 (UTC)

  Looks pretty good. I've moved the poprank so it shows for both |pop=something or |pop=<blank> and therefore PFW. It's not how the original template was, but it makes sense. I've also tried |pop=<blank> and |pop2*=something, and that seems to work. I think that's all the work we need to do with populations.

  We seem to have some remaining map issues:

  1. the local map should (I think) only be showing if |local_map=<not blank>, it seems to be defaulting on
  2. that map should (usually) be showing with the red outline of an area, not an icon.
  3. I think the errors shown in the Port Stephens Council and Federation Council testcases may be due to trying to find a local map when there isn't one.

  I'm thinking that |mapframe = {{if:{{{local_map|}}|yes|no}} may solve #1 & #3?

  There is something odd in the Katoomba test case image2 - it's getting [[file: at the top and |alt=]] at the bottom, and I assume this is due to image2={{maplink}}. Does the result of the {{maplink not make it through the wrapper?

  I'm continuing to look for anything else that may need fixing, but it's all progress. Innesw (talk) 12:01, 11 October 2025 (UTC)

Arbitrary break

@Innesw: looking into the JSON error. I can't figure it out but posted here to try to get some assistance. Will investigate further this afternoon. --Zackmann (^{Talk to me}/_{What I been doing}) 18:14, 11 October 2025 (UTC)

@Innesw: regarding the Katoomba test case, you hit the nail on the head. {{multiple image}} which wraps |image= & |image2= a that moment, does not play well with nested templates. It expects that |image=file_name_only & |image2=file_name_only.

I found the same thing happens on Sydney if you preview using {{Infobox Australian place/sandbox}}. The only way around this is to remove direct support for image2.

This will result in temporary loss of information when the conversion occurs. What we will have to do is manually convert the pages with a |image2= to either use {{multiple image}} or something like |image_map=. I did a quick search and it looks like we are talking about 463 pages, (the param report says 428). I will gladly commit to manually fixing those pages myself if this merge happens. I'll make note of that right now on my todo list. Zackmann (^{Talk to me}/_{What I been doing}) 19:03, 11 October 2025 (UTC)

Just so it's clear in my head, you're suggesting pages with |image2=either a normal image, or a map need to be changed to:

|image= {{Multiple image
  | layout = vertical
  | image1 = first image name
  | image2 = second image (or map) name
  }}

Note this is not criticism-by-question, it's purely clarification. Innesw (talk) 11:37, 12 October 2025 (UTC)

@Innesw: That is exactly what needs to be done. As I said, if this conversion does happen, I'll take care of making those corrections. I've already added it to my todo list. Should only take an hour or so with the help of some WP:JWB so in the end there will be no information lost. - Zackmann (^{Talk to me}/_{What I been doing}) 17:42, 12 October 2025 (UTC)

That's fine, now it's clear in my head I'll know what to put in the /doc when the time comes. Innesw (talk) 21:24, 12 October 2025 (UTC)

Re: the JSON errors, I tried setting |mapframe=yes only if |local_map=anything and a wikidata id exists in the article, otherwise =no, but it didn't fix the JSON and produced a lot of maps we probably didn't want. Reverted. Not sure I know what I'm doing here! Innesw (talk) 00:05, 12 October 2025 (UTC)

@Innesw: got some feedback here that might help. I don't have time to dive into this at the moment, but that is my project for tonight if you don't beat me to it. We will get this sorted out though. - Zackmann (^{Talk to me}/_{What I been doing}) 00:15, 12 October 2025 (UTC)

Maybe we should try explicitly unsetting local_map per Module:Template wrapper#Overriding default parameters? --Joy (talk) 01:42, 12 October 2025 (UTC)

@Joy: I'm going to dive into it in a few hours when I have my head on straight... Appreciate the tip! - Zackmann (^{Talk to me}/_{What I been doing}) 03:58, 12 October 2025 (UTC)

@Joy and Innesw: I solved the JSON errors. Those were an easy fix. The issue of the mapframe showing a point and not a boundary is perplexing and I'm lost. Posted elsewhere for help and am waiting to hear back. Will update once I know more. --Zackmann (^{Talk to me}/_{What I been doing}) 08:28, 12 October 2025 (UTC)

Are you referring to the edit about mapframe-point? If so, I'm not sure that makes sense. mapframe-point is the option that enables or disables showing the point marker, it's supposed to be orthogonal to whether the mapframe-shape is rendered? --Joy (talk) 10:36, 12 October 2025 (UTC)

Articles with |local_map=yes should all have a wikidata entry with a link to an openstreetmap object. I'd be quite happy to suppress the mapframe point in all cases. Innesw (talk) 11:48, 12 October 2025 (UTC)

As I said, the rendering of the marker is a matter orthogonal to rendering the shape. Meaning you can have a mapframe with a point marker, with a shape, and with both a point and a shape. There can be value in showing the point marker (for example to indicate the conventional center of an otherwise large area), or it can be useless on top of a shape. I don't think an infobox should be making these decisions and overriding the editors of the relevant articles. --Joy (talk) 12:20, 12 October 2025 (UTC)

So about this image2 question. I'm not sure why wouldn't we just implement an optional set of image_skyline2 parameters in Infobox settlement for this transition to complete seamlessly?

I mean in the case of Sydney we might as well just move that image2 to image_map, but for the other 400+. --Joy (talk) 07:50, 13 October 2025 (UTC)

@Joy: My reasoning is that I think the objection would be BIG at {{Infobox settlement}}. That infobox is used by over a half million pages. To modify it in order to fix just over 400 pages doesn't seem the best approach, particularly when there is an easy way to fix it on the 400 pages. I'm already ruffling a lot of feathers here... Don't want to ruffle them there as well...

You're case of Sydney is a good one though. That will def just move to {{{image_map}}} Additionally there are about 65 pages that are calling some form of {{mapframe}} which won't be needed since we get the mapframe for free... In any case, as I said shouldn't take more than an hour and I'm happy to do it. Zackmann (^{Talk to me}/_{What I been doing}) 07:56, 13 October 2025 (UTC)

Maybe it would be best if you could collate the precise statistics. Right now the raw 400+ sounds like a lot, but if we remove the Infobox protected area conversions, and remove the cases where image/2 was being used as a crutch for some of the other fields, exactly how far down does it go, is it like 300 or like 50? --Joy (talk) 07:59, 13 October 2025 (UTC)

I don't have a good answer for you on that. It would require examining each one, one by one. And at that point, you are halfway to just converting them. Plus anywhere there are 2 images where both are images of the place (i.e. one is not a map), then you can just use {{multiple image}}. If you want to propose adding an |image_skyline2= at {{Infobox settlement}} I certainly don't object to it, I just think the MUCH faster approach is to convert them manually. As I've said, I can do it in about an hour. Zackmann (^{Talk to me}/_{What I been doing}) 08:03, 13 October 2025 (UTC)

I was just thinking there could be a way to autodetect every |image{,2}={{maplink|... and |image{,2}={{infobox mapframe|... But it seems like it has to be based on parsing the code, not just search, because other templates also have the image and image2 parameters. --Joy (talk) 09:23, 13 October 2025 (UTC)

For |image2=actual file, would it be any easier to have _alias-map=image2:image_blank_emblem, caption2:blank_emblem_type and force |blank_emblem_size=250px (the full width of the infobox)? Then we only have to deal manually with the |image2={{map... cases. Innesw (talk) 10:48, 13 October 2025 (UTC)

Oh yeah, that seems workable, though we still get a Module:InfoboxImage |title=Official logo of <something>, and that div class="ib-settlement-caption-link". Can we test that this works without some unplanned breakage? --Joy (talk) 11:00, 13 October 2025 (UTC)

I only chose |image_blank_emblem= because it had a customisable caption, but didn't notice that title when I tested it directly with a preview of {{Infobox settlement}}. I think the link div doesn't matter if we don't set |blank_emblem_link=. But the hard-wired title may kill the idea. Innesw (talk) 11:55, 13 October 2025 (UTC)

If it's just mouseover, that can still be a workaround that buys us time for that estimated one hour or so to go through them and manually convert. It's not a horrible breakage, a couple hundred bad hover captions for a short period of time. --Joy (talk) 13:13, 13 October 2025 (UTC)

@Innesw and Joy: My 2 cents, there are bigger issues to face right now then the loss of a few images for an hour. The TFD is not doing well. Lots of drive by objections from people who haven't read what is being done or what the ACTUAL change is... Zackmann (^{Talk to me}/_{What I been doing}) 18:19, 13 October 2025 (UTC)

I think crossing all the t's like this is a way to build good will, to demonstrate that any bug reports will be addressed. --Joy (talk) 18:26, 13 October 2025 (UTC)

@Joy: that is a valid point. I hope that our responses (and I greatly appreciate all your help) has indicated the willingness to work with people to address concerns. Zackmann (^{Talk to me}/_{What I been doing}) 18:29, 13 October 2025 (UTC)

@Innesw could you still add the mapping of image2 to image_blank_emblem in cases where the logo parameters aren't using it? I'd still prefer this workaround over dropping those elements while we wait for a manual cleanup. It seems relatively easy to do, and to undo later. --Joy (talk) 07:56, 23 October 2025 (UTC)

Well, maybe not 400+, but I did quickly find a handful of examples where it was an actual image, not a situation where either image or image2 was obviously replaceable by image_map, mapframe or image_seal. --Joy (talk) 07:57, 13 October 2025 (UTC)

• Purely cosmetic, but I've removed the stray border lines in the nearby-places sub-table. Also removed all the empty cells if near-* are all blank. Also the ':' at the end of the sub-table heading - it's a table heading, not the start of a list. Innesw (talk) 09:48, 14 October 2025 (UTC)

  @Innesw: in a case like this, cosmetics matter! Thanks for doing that. Looks MUCH better! - Zackmann (^{Talk to me}/_{What I been doing}) 09:51, 14 October 2025 (UTC)

• Fixed the response to local_map so only if it's non-blank do we get a mapframe map. Adding |qid suppressed the JSON errors, but caused a mapframe map when one wasn't requested. Also changed |mapframe-id= to |local_map_id= for the purposes of the testcases page.
• There seems to be a problem with the mechanism for allowing editors to set the size of images. {{Infobox Australian place}} allows |image_upright=, |image2_upright= (which we are proposing to deprecate) and |logo_upright=, which use proportions as per IMAGESIZE. These can't be passed through to {{Infobox settlement}}, it uses |imagesize= and |blank_emblem_size= which insist on absolute px sizes. (Imagesize, image2size, logosize, and a couple of similar ones, even though they are still in the template code, are in fact deprecated, and I believe unused.) In the context of the Australian infobox (sandbox) I'm not sure image-resizing really means much, as all images are the full width of the infobox by default, and shouldn't (a) be enlarged, as this widens the infobox, or (b) shrunk, it only creates whitespace. By this logic we could just ignore *_upright - but is 'this logic' actually valid? But what do we do if it's not? Innesw (talk) 10:44, 16 October 2025 (UTC)

  @Innesw: thanks for the improvements! There is actually a discussion at Infobox settlement right now (here) about max sizes for these images. My gut reaction is that just ignoring the upright params is the way to go. If there are images that are drastically altered, they can easily be fixed by adding in the corresponding size parameter, but in the grand scheme of things doesn't seem like a big issue IMHO, though I do appreciate you finding it and bringing it up. Zackmann (^{Talk to me}/_{What I been doing}) 19:00, 16 October 2025 (UTC)

  I've implemented ignoring *_upright in the sandbox. Also removed *size, they shouldn't be there anyway. Therefore removed *size from the testcases. Innesw (talk) 22:57, 16 October 2025 (UTC)

  So I don't think you want to add them to the _exclude list. That implies they actually do something and won't be flagged as unknown parameters. With this implementation they become unknown parameters so don't want to list them as excluded. Zackmann (^{Talk to me}/_{What I been doing}) 23:02, 16 October 2025 (UTC)

  @Innesw I've missed this issue of not honoring frameless/upright parameters earlier. I noticed it independently now, implemented them in the Infobox settlement, and reactivated the earlier Australian logic in the sandbox. Please review. (If there's style changes to be made, they can be done after this migration, of course.) --Joy (talk) 14:05, 22 October 2025 (UTC)

  @Joy: image_upright and logo_upright seem to be working as required, thanks. The uses of image_upright in the testcases look to be justified, so it's good they now work.

  I did have the thought that a |logo_caption= may be justified in the australian case (not that I've heard any request for it, it's just my idea), but allowing for it in IS may open a can of worms better left closed. Innesw (talk) 23:31, 22 October 2025 (UTC)

  @Innesw: I would advice against opening that can... Just my 2 cents. Zackmann (^{Talk to me}/_{What I been doing}) 23:47, 22 October 2025 (UTC)

  Fair enough, forget that idea. We have enough complcations! Innesw (talk) 07:07, 23 October 2025 (UTC)

  It's kind of odd, Infobox settlement calls the parameter "blank emblem", but forces the title text (|title=) to "Official logo of |name= or |official_name= or {{PAGENAMEBASE}}". You could bring that up at Template talk:Infobox settlement if there's use cases where this phrasing doesn't work. --Joy (talk) 07:42, 23 October 2025 (UTC)

• I was intrigued to notice that native_name is being passed through the wrapper to infobox_settlement completely without a reference in our sandbox. I'd have thouight it needed to be in |_reuse=. Innesw (talk) 23:18, 16 October 2025 (UTC)

  Ah yes. See that is the beauty of the wrapper! You get most of these things for free. You only need to specify |_reuse= if you are reusing a parameter and doing something different with it. This prevents it from being overridden by the parent template's syntax. {{{coordinates}}} is a good example of this... Because in the sandbox version we are doing our own logic with |coordinates= if you don't include in the reuse list, it will skip that logic and do what {{Infobox settlement}} says to do with it. Zackmann (^{Talk to me}/_{What I been doing}) 23:23, 16 October 2025 (UTC)

  Ahah, just me getting used to the wrapper process. Innesw (talk) 23:29, 16 October 2025 (UTC)

  They ain't easy, that's for sure! I've done about a dozen or so of these so I'm just starting to get how they work. Zackmann (^{Talk to me}/_{What I been doing}) 23:34, 16 October 2025 (UTC)

  @Joy and Innesw: one other thing that can be done (either now or during implementation if the TFD ever passes) is that support for |type=protected can be removed. All those cases were converted a few weeks ago (by me) to use {{Infobox protected area}}. See this search which I used to find and convert them. This should also be indicated in the documentation. Note that {{Infobox protected area of Australia}} also points to {{Infobox protected area}} as of about 3 weeks ago (again, full disclosure, done by me). Zackmann (^{Talk to me}/_{What I been doing}) 06:06, 19 October 2025 (UTC)

  BTW, I just happened to find an interesting case in the protected area conversions - [2] dropped an image2 = manual mapframe, but didn't enable mapframe in the resulting infobox. Can you check, were there any others like that? --Joy (talk) 20:44, 19 October 2025 (UTC)

  I found the block of these edits in your user contributions and started checking the ones where there was a lot of text removed because those seem like the most likely. Found a handful so far, mostly in Tasmania it seems. --Joy (talk) 13:07, 21 October 2025 (UTC)

  @Joy: sorry I never got to this. I've got too many irons in the fire. REALLY appreciate you taking care of this. Zackmann (^{Talk to me}/_{What I been doing}) 17:36, 21 October 2025 (UTC)

  By my count, it total there were 15 of these. In a mass of 1156, that was just ~1%, so that's good. --Joy (talk) 08:03, 23 October 2025 (UTC)

  That is a relief! Zackmann (^{Talk to me}/_{What I been doing}) 08:05, 23 October 2025 (UTC)

• There has been a discussion here for a while about adding parameters to the infobox for Traditional Owners. There has not been any opposition in principle, the discussion has mostly been about guidelines for how to use the parameters. The question was raised about where to add them in the wrapper we're working on. My suggestion is to use subdivision 5 (which is currently empty in the sandbox), with 'First People(s)' in the type, and putting |first_peoples1=, |first_peoples1_footnotes=, |first_peoples2= and |first_peoples2_footnotes= into a {{plainlist}} in the name. I'll have a go at it, but it may need checking/fixing. Innesw (talk) 09:48, 23 October 2025 (UTC)

  Why would Wikipedia use 'First People(s)' in capitals? -- Michael Bednarek (talk) 10:25, 23 October 2025 (UTC)

  The infobox phrasing should probably match the best practice from the article space. First Peoples redirects to an article that has a section Indigenous peoples#Australia which doesn't quite clarify what's the most common phrasing. --Joy (talk) 10:46, 23 October 2025 (UTC)

  Why must this be SO complicated. Innesw can we possibly put that off for a bit? Full disclosure I did NOT read the discussion you linked to and as a self-proclaimed stupid American I know NOTHING about this subject as it pertains to Australia...

  That being said, my suggestion/request is to try to finally get this dang TFD closed and this conversion done. There will undoubtedly be hiccups along the way. Let's address those and make sure everything is working.

  Then, once that is done, we can work on adding new information. To be clear, I have zero problem with adding data that WP:CONSENSUS has decided is valuable for Australian places. I just worry... There is SO MUCH going on with this conversion. It has been a nearly monthlong process. I fear that if we try to lump this on top of it, the house of cards will collapse. I have no doubt that we can find a way to display this data in the wrapper. It is a question of where and how, not if. Zackmann (^{Talk to me}/_{What I been doing}) 09:55, 23 October 2025 (UTC)

  Seems fine to me, a relatively small change either way, just a matter of positioning. --Joy (talk) 10:18, 23 October 2025 (UTC)

  @Zackmann08: Apologies, I'd made the change to the sandbox before I saw your comment. If you can leave the change an hour while I test it, revert it after that if you wish. Innesw (talk) 10:25, 23 October 2025 (UTC)

  BTW, I wouldn't bother with the 1 and 2 and separate references. Just keep it simple - one parameter for values which can be a plainlist in the callers, and another for the references, however many there are. --Joy (talk) 10:25, 23 October 2025 (UTC)

Make it happen

So the TFD finally closed with a consensus to convert. Before I pull the trigger and make this happen, @Joy and Innesw: are there any remaining unresolved issues or things we need to keep an eye on when we actually convert it? Is the sandbox ready to go? --Zackmann (^{Talk to me}/_{What I been doing}) 22:27, 31 October 2025 (UTC)

In two words - not yet. My luafication of the template had a number of changes which I was about to propose when the conversion suggestion was made, so I held off until it was resolved. Some of my proposals are now irrelevent under the conversion, some I intend to withdraw for the time being (or need other discussions), others still need to happen. Give me a day or two to sort through them, and the changes I still think need to happen I will bring here. Note that I am not proposing actual luafication at this point - that's in the 'other discussions' basket. There is no great rush to get this out - we need to get it right. Innesw (talk) 23:15, 31 October 2025 (UTC)

@Innesw: there is no great rush to get this out - we need to get it right. I totally agree... That being said... The discussion has agreed to convert to use the wrapper we have mocked up in the Sandbox... Your luafication completely contradicts that, particularly the adding of color which was a big reason for this conversion in the first place. This should look just like every other settlement page on wikipedia. Not have it's own custom styling... If there are improvements to be made (which I totally agree there are) can we not finish the conversion and THEN make improvements? Zackmann (^{Talk to me}/_{What I been doing}) 23:18, 31 October 2025 (UTC)

The consensus for change was, for many users, conditional on the test cases provided. Going short of, or further than that would be to go against the community consensus. Other than any minor inconsequential technical changes, I think Zachmann's template wrapper ought to roll out as it is. Then a separate discussion can be held on any subsequent changes. Dgp4004 (talk) 23:48, 31 October 2025 (UTC)

@Innesw: I want to be clear... I am not against further improvements. What I do object to is trying to lump other things into this change. I feel very strongly we should merge what is in the Sandbox. Take a week to make sure nothing blows up.. Then you should absolutely charge ahead with making any additional improvements you can think of. But those changes are going to require a new round of discussion about whether they are wanted and approved of by consensus. They are also going to require a new round of testing. This is version 2. Let your changes be version 3. Zackmann (^{Talk to me}/_{What I been doing}) 23:51, 31 October 2025 (UTC)

I'm not advocating a lot of the things that appear in the luafication (eg: colour), they are just a legacy of the base being the old template. Please wait for my list of changes before saying they should not be in version 2. I'm working on it now. Innesw (talk) 03:57, 1 November 2025 (UTC)

I'm willing to see the list... But reserve the right to say they go in version 3. Zackmann (^{Talk to me}/_{What I been doing}) 04:26, 1 November 2025 (UTC)

My only outstanding issue is the density-calculation error shown in this testcase. I know the docs say both |pop and |area should be numbers, but if either of them are not we get this error. |pop=N/A is actually a reasonable entry if the Australian Bureau of Statistics says the population is too small to report without causing privacy concerns. So can we prevent the density calculation if |pop or |area are non-numeric?

All the other issues have either been fixed in what we've done already, or need discussion before being implemented.

Are we going to remove support for |type=protected now, or let it wait? Innesw (talk) 05:18, 1 November 2025 (UTC)

I think we addressed all of the factual issues that were brought up minus the annoying leftover with image2, and Zackmann08 committed to fixing that manually. Let's get that rolling, and see how that goes.

Whatever else needs to happen based on proposals that aren't bound by consensus at TfD can happen in subsequent discussions on the talk page.

Of course if someone identifies a specific regression, that has to be addressed. But that has to happen whether that's reported now or in two months time. I don't see what we stand to gain from an unexplained delay on top of a month-long TfD. --Joy (talk) 17:07, 1 November 2025 (UTC)

I have a busy day today but will pull the trigger on this tomorrow. I agree additional improvemeants and other issues can be addressed in the next update. Zackmann (^{Talk to me}/_{What I been doing}) 20:01, 1 November 2025 (UTC)

Joy so the only things todo that I see are:

• Fix these pages which have an |image2= value.
• Delete Category:Australian place articles using missing parameters as it is superseded by the unknown params check.
• remove support for |type=protected see this search

am i forgetting anything? Zackmann (^{Talk to me}/_{What I been doing}) 22:14, 1 November 2025 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Why so many maps?

This is related to the conversion discussed above, but why is it that {{Infobox Australian place}} uses have multiple maps? For example Adelaide or Sydney. Seems like too much going on in the Infobox. Is there some reason for all the maps? -- Zackmann (^{Talk to me}/_{What I been doing}) 22:46, 13 October 2025 (UTC)

By my reading of the /doc, there should generally only be 2 maps:

• the location map (-> pushpin_map), which uses {{coords}}, usually showing the nation or the state, but sometimes the LGA (which should have a sub-map showing the LGA withing the state). Uses Module:Australian place map to get the actual map.

• on by default, suppressed by |map_type=nomap
• using image2 for a map is supposed to be a substitute for this if the LGA map isn't in Category:Australia location map modules, so the call to Module:Australian place map doesn't work

• the local map (-> mapframe), which uses wikidata (and from there an openstreetmap object)

• off by default, turned on by |local_map=yes

In {{infobox_Australian_place}} the location map comes before the local map, in {{Infobox settlement}} this order is reversed. Innesw (talk) 02:39, 14 October 2025 (UTC)

That isn't what is happening in practice unfortunately. Oh well. --Zackmann (^{Talk to me}/_{What I been doing}) 02:41, 14 October 2025 (UTC)

Well, this is mostly a matter for the articles themselves, but I don't see it as particularly problematic. There's one map that shows it in the context of the country and the continent (for readers who don't know where it is and need general orientation), and another map that zooms in and shows the local context (for readers who want to understand more about the geographic layout of the place). For large and significant cities like the two listed, it makes sense that each contingent of readers is noticable, so it's fine for the infobox to try to provide this information. For smaller places and shorter articles, it might make sense to not overdo it, but with these it should be fine. --Joy (talk) 09:52, 14 October 2025 (UTC)

BTW we should note here that there's an easy way to reduce ostensibly excessive height in these cases: wrap additional elements into {{hidden begin}} + {{hidden end}}, like it's done at e.g. Vancouver. --Joy (talk) 08:06, 23 October 2025 (UTC)

Census data

The automated census date from Wikidata is buggy, so, while it is correct a lot of the time, there are quite a number of situations where it is wrong and, basically, unless someone actually checks against quickstats, we don't know if it is buggy or not. It is buggy for a range of reasons, places with the same name get confused (e.g. the town of Happy Valley on K'gari gets the population of the suburb of Happy Valley in Mount Isa). Particularly worrying, it cites quickstats but actually gets its data from a datapack and the two can be different, in particular, due to reidentification risk, ABS decides that quickstats says "no people or a very low population" rather than a small number, so "no people or a very low population" is what should be displayed as we are citing quickstats. Currently the population field must be numeric, so I manually set it to 0 to override the automated census dataand put the "no people or a very low population" in the article body, but it would be better to get this right, by actually drawing the data from quickstats (whether directly or via uploading the quickstats data into Wikidata). The other issue is that the ABS sometimes provides a combined population for two adjacent areas (usually one or both have a low population) listed as being the population of just one of them (it seems to be the more populous but I don't know that for certain); you figure this out either by noticing the area displayed on the map is larger than the locality named, or because you asked about the other locality and you get shown the neighbouring locality's quickstats. Again, you have to report this in the text as a combined population and it makes no sense to put anything in the population field in the infobox (yet it is impossible to suppress it). I've put a lot of effort into fixing the Queensland census data, so I don't want it to be broken by changes to this template. But we also need to go through and check and fix all the other states (as I am not aware of anyone having said they have done this). It would be better to fix the automation by doing cross-checks like matching the LGA (for places with the same name) and scraping the data from quickstats if citing quickstats and the population field needs to be allowed to be non-numeric for "no people or a very low population" (we could abbreviate to "no or low" perhaps linked to a section in the Census in Australia article which explain why this is used (to avoid reidentification risk). Kerry (talk) 21:35, 23 October 2025 (UTC)

I've been working on an uprade of {{PopulationFromWikidata}} that is here in my draft space. I was about to announce it when the discussion of the Infobox template started, so held off. I believe it fixes the known bugs (such as the double references between article text and the infobox), and also will show multiple populations (eg: UCL and SAL for a town) if they are in the Wikidata.

Re: the differences between the ABS Quickstats and datapacks, I cannot see why the ABS states "no people or a very low population" in Quickstats, but then provides an actual number (not necessarily zero) in the datapacks. As far as I can tell there is no viable way of 'scraping' Quickstats for the complete data set - it would require setting a URL for a given ABS geographic object, receiving back the whole user-friendly page (including a map and a large amount of other data), and extracting the population figure from the returned HTML of the page. Over 15000 times for the SALs. I suppose it might be viable for datapack populations below a certain threshhold.

These things have to be fixed in the Wikidata. The PopulationFromWikidata (or any other) module cannot get data from an external website on the fly - that would imply the possibility of putting data (or straight text) on a WP page from a completely unverified external source. Innesw (talk) 02:54, 24 October 2025 (UTC)

I'm not suggesting doing it on-the-fly, but scraping quickstats to find out which ones should be "no people or a very low population" and updating them accordingly in wikidata and/or wikipedia. The reason (the risk of re-identification) came from the ABS when I asked about the difference. It seems any place with a population of under 100 people is assessed for re-identification risk. I agree that ABS publishing two different sets of data seems crazy, but it's what they do and I don't think we should create re-identification risk (irresponsible of us given we know the reason). But if we provide a cite to quickstats (as we do), then we must put the value found in quickstats, not the value in the datapack. I have fixed all the Queenland entries (searched for all the places with population less than 100 and checked to see what quickstats said and updated the article accordingly. Another problem with the current Wikidata is that some towns have populations in the census, some don't, but if there is a suburb/locality with the same name, I think Wikidata may pick up that value (even though the suburb/locality may be nowhere near it). This is the big risk with MixNMatch, it is mind-numbingly boring and most of its suggestions are correct so people just starting click YES YES YES, without actually checking.

But we will have the 2026 census pretty soon, so we really need to get a solution that is efficient and accurate and appropriately cited. We also need a way to find the combined places (one population across two or more localities) so we don't misrepresent their populations by just providing a number and not explaining that it's for the combined list of localities. Kerry (talk) 04:56, 25 October 2025 (UTC)

Also the census data isn't just available in the infobox Australian place. It is often in the article in the lede (the most recent census) and/or in the history/demographics (or some other) section, showing how it is changing over time. So we do have to cater for this too, which was not done with the 2021 census, which only targetted the infobox value. I used AutoWikiBrowser to help me find and update the Queensland place articles in that regard and deal with the "no people ..." situation too. While it is not a fully-automated method, there are so many things that complicate the census that you really do need to review each semi-automated edit and see that it is sensible as the census is a complex beast. Kerry (talk) 05:02, 25 October 2025 (UTC)

And we can't use the HistoricPopulation (or whatever it's called) template as it is just a 2 column table (year and population count) without considering the need for the citation and for the people who like to add little snippets of interesting information (e.g. have the largest Macedonian population in New South Wales, or have 70% males and 30% females (which tends to occur in areas with prisons as prisoners are disproportionately male). So I think we need to make our own AustrlaianHistoricPopulation template as a 3-column table with the third for fascinating facts and citations. Kerry (talk) 05:07, 25 October 2025 (UTC)

@Kerry: The LatestPopulation function in my proposed upgrade is intended to show the latest census population in-text: Ulladulla has a population of 14,396 (2021). (Data is from Ulladulla (Q649969), as is the table below.)

The HistoricPopulations function in the upgrade has a citation for each population number.

	UCL
2006	10,298
2011	12,137
2016	13,054
2021	14,396

The table is intended to show an additional row as each census appears in the Wikidata, and could (at least in theory) have additional rows at the top if older census data is added. Adding a 'snippet' for a geven year would require eg: |snippet1_year=2016 and |snippet1_text=snippet text. Innesw (talk) 05:21, 26 October 2025 (UTC)

References

Why UCL and not SAL as used in the article on Ulladulla? -- Michael Bednarek (talk) 07:02, 26 October 2025 (UTC)

No special reason, I happened to set it to ask for the UCL populations, which are also in the Wikidata for Ulladulla. (I haven't looked at the article, Ulladulla was used in a testcases page I happened to base my tests on.) It does raise the question though, of what to do when there are both an SAL and a UCL with the same name, and therefore both sets of data in the Wikidata. The current version of PopulationFromWikidata shows (intended for the Infobox) UCL data for towns and cities, SAL data for suburbs (and localities). (Towns show SAL data only if there is no UCL data.) Only ever a single population figure. For towns, it makes more sense to me to show the latest population for both the geographies by default - which is what I have implemented in my upgrade. (The default HistoricPopulations table also shows both if they're available.) This needs discussion, as I do propose this change - but it is a change to what is shown in the Infobox. Innesw (talk) 09:42, 26 October 2025 (UTC)

See also the new Module:Settlement Wikidata. – Jonesey95 (talk) 19:25, 26 October 2025 (UTC)

There are a number of scenarios that determine which is the better to use if only one can be included. Where we have a locality with a town located entirely within it (a common rural scenario), then the SAL is better as it is the larger value. Where we have an article about a town which spans multiple suburbs/localities (which might have their own articles), then the UCL is the value to use. I say "if only one can be included". Is there a reason we cannot accommodate both where available? If we could have two population fields in the infobox, that would allow both SAL and UCL where available to be included and avoid the choice issue. But, there are a lot of tricky cases. E.g. where the name of the town and the locality that surrounds it are different. Also some towns may have started within a locality but expanded across a boundary into another locality (which might contain its own town). This tends to occur the edges of cities as part of the urban sprawl. It then becomes difficult to decide what the extent of the town is and whether UCL data is or isn't appropriate in which article. Having done all of Queensland's 2021 census manually (due to the number of errors in the automated approach -- I certain didn't want to have to do it!), I found so many complex cases that I don't believe we can have a fully-automated solution. It's just too complicated. It might be OK to have some shorthand to say "default ok here" but that needs to be decided by a person who understands exactly what area that census data represents and how that relates to the article topic. A lot of census data in complex situations requires additional text within the article to explain what's going on. The idea that "Wikidata can do it all" is simply untrue. Kerry (talk) 22:01, 31 October 2025 (UTC)

@Kerry: There is no reason why both UCL and SAL populations in the Wikidata cannot be returned. That's what my proposed upgrade does for |type=town - by default. (The other types only return a single relevent population. Ignore ILOCs at present.) But it also allows the pop for a single geography to be returned if that is desired, by setting eg: |geog=ucl - even if that is not the usual geography for the |type=. Is that the sensible default, but also meet your need for control in some circumstances? Innesw (talk) 10:29, 1 November 2025 (UTC)

Sounds reasonable. Kerry (talk) 00:46, 2 November 2025 (UTC)

The conversion

I have officially pulled the trigger and converted this template to use Template:Infobox settlement as per the lengthy discussion above & the TFD. This will take a few days to flush out any remaining issues.

IF YOU FIND ANY, please post them here so we can quickly address them. Thanks! Zackmann (^{Talk to me}/_{What I been doing}) 06:53, 2 November 2025 (UTC)

Note: I fully expect Category:Pages using infobox Australian place with unknown parameters (0) to grow over the next 12 hours as the server cache catches up. Know that I am monitoring this but I'm in the Pacific Time Zone so my editing hours are vastly different from those residing in Australia... I will be working on these over the next day. Zackmann (^{Talk to me}/_{What I been doing}) 07:04, 2 November 2025 (UTC)

Thanks for this @Zackmann08:, I think it’s going to be very worthwhile in the long run. One thing I noticed is that “X near Y” renders as “Localities near Y” regardless of the type set in the infobox (see e.g. Hume (region)). I’m not familiar enough with the module to know immediately if this is quickly fixable. Triptothecottage (talk) 09:07, 2 November 2025 (UTC)

@Triptothecottage: appreciate the feedback. What is it supposed to render as if not Localities near Y? What is it you are wanting/expecting to see? Should be fixable, just need to know what to fix... --Zackmann (^{Talk to me}/_{What I been doing}) 09:12, 2 November 2025 (UTC)

See for example Wakool Shire where it renders as LGAs around Shire of Wakool. Zackmann (^{Talk to me}/_{What I been doing}) 09:14, 2 November 2025 (UTC)

I will be completely honest, I hadn’t noticed it one way or the other previously. But intuitively I would expect it to say “regions” in this case. Triptothecottage (talk) 10:34, 2 November 2025 (UTC)

The problem is, if you look at Hume (region), the adjacent places are not all regions... Zackmann (^{Talk to me}/_{What I been doing}) 10:35, 2 November 2025 (UTC)

That seems to be a behaviour of the parameter, where if it crosses a boundary it displays the adjacent state or body of water (see Port Melbourne or Wodonga). The specific problem here is that, as has come up a few times, "locality" means something specific in the Australian context and it being the default here means some strange and inaccurate results. I have suggested a change at {{Infobox Australian place/table/sandbox}} that deals at least with the case where the type is explicitly "region". I'm not sure what to do for cases like Melbourne, where "city" is clearly the correct type but "Regions near..." would be the correct text to render. Triptothecottage (talk) 00:30, 3 November 2025 (UTC)

Thanks! I appreciate you looking into it. I am NOT Australian so these nuances are lost on me. Really appreciate the help. I have implemented the change you suggested. Let me know if you find any others! Zackmann (^{Talk to me}/_{What I been doing}) 00:34, 3 November 2025 (UTC)

Maybe you can just use the generic word "Places" instead, and be done with it? --Joy (talk) 08:19, 3 November 2025 (UTC)

Hey, just wanted to say thanks for putting in the effort to make this change. The result looks great and well worth it. Very few, including me, would've bothered to go through all the red tape, bureacracy and discussion to make it happen (not that i'm competent or experienced enough to make such a significant formatting change anyway). I've been following this for a bit and I've always thought the old Australian specific infobox looked outdated, unecessary and out of place compared to the infoboxes of literally everywhere else. Would just like to add though, is there a reason why the city boundary map and map showing the city within the rest of the country, is swapped around compared to other infoboxes? Shrubshire (talk) 11:01, 2 November 2025 (UTC)

@Shrubshire: thank you so much for the feedback! This has to do with how each transclusion is being handled. These boundary maps should be moved from |image= to |image_map=. That has to be handled on a case by case basis. You should feel free to do that work if you are so inclined! Zackmann (^{Talk to me}/_{What I been doing}) 17:41, 2 November 2025 (UTC)

• I'll start working on the /doc page. I'll add a note at the top saying it's undergoing a revision. The major work will just be a re-ordering so parameters are described in the order they show in the infobox, and adding some section sub-headings, but I'll audit the whole thing as I go. Innesw (talk) 11:17, 2 November 2025 (UTC)

  Innesw the /doc page should be fully up to date at this point, unless you found anything I overlooked... Zackmann (^{Talk to me}/_{What I been doing}) 17:29, 2 November 2025 (UTC)

@Zackmann08 can you please revert this change? It's arbitrary and it's like an intentional regression from the previous live version. --Joy (talk) 14:09, 2 November 2025 (UTC)

@Joy: can you say more? How is it an intentional regression... Those parameters should all still work (unless I made a mistake which is absolutely possible). The change I intended was to remove the defaulting to a much larger image size which goes against the consistent styling we were trying to achieve with this conversion. I.E. not using the default stylings of {{Infobox settlement}}. Zackmann (^{Talk to me}/_{What I been doing}) 17:31, 2 November 2025 (UTC)

These image sizes were reported as an issue on Talk while this was at TfD, and I fixed this while the TfD was ongoing. The final people who !voted on the TfD all saw that version, and voted in support just like those at the start when it had been different (well, maybe more of them, but anyway). At the same time, this specific layout change wasn't documented as part of the TfD rationale, only the colors were, and when I had fixed this mid-process you didn't say anything about it in the subthread about it, where Innesw said it was changed 'as required'. So I think it's fair to say that this size change deserves at least a modicum of a separate discussion. --Joy (talk) 18:07, 2 November 2025 (UTC)

Gotcha. I'll confess I haven't stayed up to date on all aspects of the discussion over the last month. If consensus was to make the images larger than others then I guess that is consensus... Zackmann (^{Talk to me}/_{What I been doing}) 18:44, 2 November 2025 (UTC)

I don't know that it is, I just think it's fair for this to be the starting point in the life of the new template :)

If you recall, in the meantime we also had a side quest of figuring out what WP:Image policy says about maximum sizes. That also didn't provide us a conclusion that would mean we have to change this.

Thank you for the revert!

If you would still want for that change to be made, please feel free to bring it up in its own thread, so more folks possibly notice, and we can see what the current consensus on that may be. --Joy (talk) 19:22, 2 November 2025 (UTC)

Ok so I think... We are done?

• Category:Pages using infobox Australian place with unknown parameters (0)
• Category:Pages using infobox Australian place with conflicting parameters (0)

are both empty at present so I think everything has been handled... If anyone finds any outstanding issues let me know!

@Joy: a bit of code you might find useful... I created {{User:Zackmann08/cc|Category Name|Display Name}} as a fork of {{clc}}. It is identical EXCEPT that if the count is greater than zero 0 (or greater than |3=), it will display in red. VERY useful for monitoring categories that should be empty. If you look at my userpage you will see it in heavy usage. Zackmann (^{Talk to me}/_{What I been doing}) 20:51, 2 November 2025 (UTC)

Awesome that you were able to attend to it that fast.

I do have to ask, what is the logic between e.g. Sydney losing the svg map in favor of mapframe[3] but Adelaide keeping it[4], or Melbourne keeping it[5]? --Joy (talk) 23:19, 2 November 2025 (UTC)

That is just an oversight. My regexes changed and improved as I went along so the edits I did early on are a little different than the later ones. In general I am MUCH more in favor of the mapframe than I am of impossible to read maps like File:Free printable and editable vector map of Melbourne Australia.svg.

So TLDR, no good logic at all. Facepalm . I've gone ahead and replaced the 2 maps you linked to... Zackmann (^{Talk to me}/_{What I been doing}) 23:23, 2 November 2025 (UTC)

I moved this topic to WP:AWNB. --Joy (talk) 08:13, 3 November 2025 (UTC)

• any output for |native_name_lang= seems to have gone missing - and I think it's a problem with {{Infobox settlement}}, not here. One solution I came across at Albany, Western Australia is to use |native_name={{Native name}}, which requires the IETF code, eg: {{Native name|nys|Kinjarling}} gives Kinjarling (Nyungar). But this is a workaround for IS not showing the language name. Innesw (talk) 06:57, 3 November 2025 (UTC)

  @Innesw: look at the source code for {{infobox settlement}}. There never was any output for |native_name_lang=. It encodes a hidden <div>...</div> that wraps |native_name=. --Zackmann (^{Talk to me}/_{What I been doing}) 07:14, 3 November 2025 (UTC)

  Yeah, in the old IAP code native_name_lang was also a lang= property of the div, not shown by itself, so there doesn't seem to be a regression.

  Innesw, if you want something changed about that property, let's do that in a separate thread. --Joy (talk) 08:17, 3 November 2025 (UTC)

  Apologies, my memory of the old infobox was that it output the name of the language next to the native name (as {{Native name}} does), but my memory was bad and I didn't check it. So there is indeed nothing missing in the new version. I agree that showing the language name is a change that would need discussion. Forget it at this time. Innesw (talk) 10:23, 3 November 2025 (UTC)

• Just noticed, can we have |gazetted= up with |established= and |abolished=. Checking the parms useage it seems it's used for LGAs rather than the cadastral divisions. I'd suggest |established_title1 = Established and |established_date1 = {{{established|{{{est|}}}}}}{{{established_footnotes|}}}. Innesw (talk) 23:17, 10 November 2025 (UTC)

  The params usage link isn't working, but it can be clicked through - let's make a note that it's 153 references. --Joy (talk) 10:03, 11 November 2025 (UTC)

  ITYM change the current:

  *:| blank5_name_sec1 = [[Gazetteer of Australia|Gazetted]] *:| blank5_info_sec1 = {{{gazetted|}}} *:

  to

  *:| established_title1 = [[Gazetteer of Australia|Gazetted]] *:| established_date1 = {{{gazetted|}}} *:

  Right? --Joy (talk) 10:06, 11 November 2025 (UTC)

  Sorry, stuffed up the suggestion. You're right, {{{gazetted}}} -> established_date1. (I do really need to look more closely at what I'm doing!) Innesw (talk) 11:05, 11 November 2025 (UTC)

"Wikipedia:IAP" listed at Redirects for discussion

The redirect Wikipedia:IAP has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2025 November 3 § Wikipedia:IAP until a consensus is reached. Joy (talk) 08:24, 3 November 2025 (UTC)

Please reinstate the bullet points for the distances to other places

Visually it seems more difficult to find anything in the infobox -- everything seems to be in a different order/grouping to before. I thought this change was promised to be merely a wrapper and that the end result would look the same, but it certainly doesn't. For example, it now is very difficult to visually separate out the distances now. We have a lot of remote places where you need a lot more distances to other places than you do in a major city. I think there was a bullet point or some other symbol in front of each entry before which improved readability enormously.

Is there a way we can see the page (before and after) so we can see the differences more precisely?

Kerry (talk) 05:50, 4 November 2025 (UTC)

Also the colours have gone. Kerry (talk) 05:57, 4 November 2025 (UTC)

That's why we had the testcases last month :) we could probably restore a copy so it could be compared again, but I'm not sure how much work it is.

The extra colors were the one thing explicitly mentioned to be removed in #Wrapper for Infobox Settlement, so that was part of the package. Would you reintroduce some of the colors, for which parts? --Joy (talk) 06:22, 4 November 2025 (UTC)

@Kerry Raymond: consensus has overwhelmingly gone against your WP:OWN mentality of (and I am quoting you from above): "wanting to keep important Australian templates in the the control of the Australian editing community". Both myself and Joy invited you multiple times to review the code and give input. By your own admission you (I am again quoting you) "chose not to look". To complain now that things happened differently than you wanted them to is just silly. Zackmann (^{Talk to me}/_{What I been doing}) 07:06, 4 November 2025 (UTC)

@Zackmann08 I don't think we need to be this combative. I don't remember Kerry saying she chose not too look at the whole thing in general, just at the code under the hood, which is a big difference. People are allowed to have opinions on the visual outcomes irrespective of code, and people are allowed to miss a change in a huge discussion, we are all fallible, it's not an inherent sign of bad faith. --Joy (talk) 08:36, 4 November 2025 (UTC)

Joy I will just say that Kerry's surprise that Also the colours have gone shows me that they didn't even read the first post about this change, look at the lengthy TFD or even glance at the testcases... They had a full month to engage in discussion about this change and chose not to look at the test cases at all (or they clearly would have seen the removal of the color). To come now and complain that things didn't go the way they wanted... That's absurd. Zackmann (^{Talk to me}/_{What I been doing}) 08:42, 4 November 2025 (UTC)

This is a standard deployment process issue - homo sapiens and happenstance. :) Some testers just will not engage until the final release to production because #reasons. It might not feel good, but it does help remind us of another fact we often miss - most of our readers aren't editors, so we don't really know how most of the affected people feel about the change before it happens anyway. You have to continue to be patient even if the bulk of the work is seemingly done. --Joy (talk) 08:45, 4 November 2025 (UTC)

So, the current formatting came about in this edit

The previous formatting is visible in e.g. this edit

It looks like the <ul ... was converted to {{ubl}}. But ul just means unordered list, not unbulleted, so we can just change that to instead. Let me try in the sandbox. --Joy (talk) 08:52, 4 November 2025 (UTC)

There we go, Template:Infobox Australian place/testcases now has the bullets in the Location fields again. Is this fine then? --Joy (talk) 08:54, 4 November 2025 (UTC)

IMHO this is not an improvement but actually a regression. Now the text has lost something like 20% of its available space and is wrapping more than before making it less readable... Zackmann (^{Talk to me}/_{What I been doing}) 08:57, 4 November 2025 (UTC)

I restored the styles, too, sorry. Now only the bullet and the space to its sides is restored. --Joy (talk) 09:07, 4 November 2025 (UTC)

Also, it varies by case. For example the wrapping on the old Location field for Perth looks much better than Perth now.

One thing that we may be missing is some consistency in the margin at the top. The old formatting had the "Location" to the left at the exact same height as the first item to the left, but that doesn't happen now. --Joy (talk) 09:11, 4 November 2025 (UTC)

@Innesw can I ask you to review the above and give a third opinion? --Joy (talk) 10:28, 5 November 2025 (UTC)

Will do - but not in detail late at night! It could take me a day or more to read the above carefully and write a considered opinion. Innesw (talk) 11:21, 5 November 2025 (UTC)

I do think the distances-from-locations list needs to look like a list. Just separating the list items with a line break doesn't look 'listy' enough. But we need to minimise the chances of the list items wrapping, and wasting space generally.

The problem is that, even in its un-bulleted form with a (perfectly reasonable) 2-digit distance and (ditto) about 12 characters in the placename, the width of the text runs very close to the width allowed for it in the infobox. We have a number of things that add to the width of a list item, potentially causing it to wrap:

1. in a bulleted list, the bullet itself (and its following space)
2. in a bulleted list, the extra padding/margin that a list gets - at left before the bullet, as Joy noted also at the top, and possibly also at the right and bottom
3. a longer place name, or, especially, more digits in the distance (which add 2x, because it adds to the converted distance as well - see Perth)

#3 we can't do much about unless we reduce the font size, and I don't think that's a good idea. If the item wraps for these reasons, it wraps.

To reduce the effect of #1, and eliminate #2, I wonder if we can make this 'look like a list' without making a WP/HTML list of it. Can we add a (smallish) bullet character and a space to the start of each line and leave it at that, without some later processing saying 'that's a list, I'll turn it into an HTML list' - with its margins etc. (And we don't want somebody coming along in the future and saying 'If you want a list, use a b... list!', so comment the code carefully.)

In the Perth example Joy points to, the old version only looks better because it consistently wraps before the direction rather than after it - maybe assisted by a clever editor using 'West' instead of 'W' to achieve this in all cases. I don't think it's an example we can use to make decisions on. Innesw (talk) 10:54, 6 November 2025 (UTC)

I added a manual bullet point in the sandbox to check that out, but then the wrapping is sort of broken further. --Joy (talk) 11:42, 6 November 2025 (UTC)

There will always be those edge cases where adding the bullet will cause a list item to wrap when it wouldn't have without the bullet - like in the Raymend Terrace testcase. I'd rather put up with that than not have the bullets. Perth is going to wrap most of its items no matter what we do. I think what you've done in the sandbox is as good as we'll get. Innesw (talk) 12:03, 6 November 2025 (UTC)

Actually, there should be another way. If we could supply a custom stylesheet, we could try something like:

ul.small-bullet-list {
  list-style-type: none;
}
ul.small-bullet-list li::before {
  content: "•";
}

--Joy (talk) 13:17, 6 November 2025 (UTC)

Looks like a complicated solution to me - but try it in the sandbox if you like. Does it eliminate the margins we don't want? Innesw (talk) 22:55, 6 November 2025 (UTC)

I managed to shrink the bullet point and remove the top margin, cf. {{Infobox Australian place/styles.css}}

I'd appreciate some help from someone who actually understands CSS :) with preserving the hanging indent. --Joy (talk) 08:33, 7 November 2025 (UTC)

I've fiddled with the css, I think it gives us the hanging indent. Innesw (talk) 00:04, 8 November 2025 (UTC)

Agreed, thanks. @Zackmann08 can you check the test cases? Is this tolerable? Now the difference is just the small bullet point and a bit of space around it and below it. --Joy (talk) 07:57, 8 November 2025 (UTC)

Personally not a huge fan but it is certainly tolerable Appreciate the hard work on it! Zackmann (^{Talk to me}/_{What I been doing}) 15:54, 8 November 2025 (UTC)

Thanks. Let's go with that, in the spirit of closing out this migration with the visual state of the template reproducing the old state as faithfully as possible. If people later speak out saying get rid of it or tune it, it's not a problem. --Joy (talk) 16:49, 8 November 2025 (UTC)

Sounds like a good solution to me! Zackmann (^{Talk to me}/_{What I been doing}) 17:01, 8 November 2025 (UTC)

Thank you all for all the bullet points, it has improved readability. No, I have not been able to fully engage in this discussion due to serious family health issues and I appreciate those who assumed good faith. Kerry (talk) 06:39, 9 November 2025 (UTC)

Canberra CS1 errors from Module:PopulationFromWikidata

Moved from Help talk:CS1 errors § Canberra

 – Trappist the monk (talk) 22:48, 4 November 2025 (UTC)

Can anyone figure out what is going on at Canberra? There is a footnote somewhere in the infobox missing a url [footnote number 7] but I cannot figure out how the footnote is being generated. Thanks. DrKay (talk) 20:29, 4 November 2025 (UTC)

This edit at {{Infobox Australian place}} by Editor Zackmann08. Previewing Canberra with this version of the infobox template does not exhibit the problem; the next and subsequent versions do exhibit the problem.

Discussion should continue at Template talk:Infobox Australian place; not here.

—Trappist the monk (talk) 21:09, 4 November 2025 (UTC)

@DrKay: what error are you seeing? We just completed an enormous overhaul of {{Infobox Australian place}}. I thought we found all the issues but def possible one slipped through... Can you give me details on what problem you are seeing/how to reproduce it? I'm not familiar with CS1 errros, but if you can help me understand the issue, happy to help solve it! Zackmann (^{Talk to me}/_{What I been doing}) 22:23, 4 November 2025 (UTC)

The error appears in ref 7 (permalink) as stated in the OP.

I'm guessing that the broken reference comes from Wikidata. If you comment-out all but the first two parameters in the infobox and then preview, the infobox includes total population: 452,670 reference linked to ref 2. But, there is also a ref 1 that does not backlink to anywhere and is (apparently) a duplicate of ref 2. The population value 452,670 matches a number given at d:Q3114#P1082.

Back to the permalinked article, there is no mention of 452,670. ref 7 appears to match the reference in wikidata for the 452,670 value. Often, when clicking a reference backlink that goes nowhere, it usually indicates that the infobox does not recognize the parameter to which the reference is attached so that parameter and its attached reference do not get rendered.

—Trappist the monk (talk) 23:06, 4 November 2025 (UTC)

By my read of it, the wikidata value is missing a URL... Zackmann (^{Talk to me}/_{What I been doing}) 23:13, 4 November 2025 (UTC)

I'm pretty sure the un-backlinked reference is caused by a double call to PopulationFromWikidata. The template calls this once just to determine if there are any populations available. This generates ref1, but there is no place for that ref to appear in the infobox. If there is no manual setting of |pop=, the module gets called again to display the wikidata population (with its citation, and generating ref2). There is an error in PopulationFromWikidata (which I have fixed in a rework draft) in that references aren't properly named, so the refs to the same location don't get combined. Innesw (talk) 23:41, 4 November 2025 (UTC)

By the way the {{cite web}} errors you may see in preview are because the reference in the wikidata does not contain a reference URL (P854). This has nothing to do with the un-backlinked reference issue. Innesw (talk) 06:01, 5 November 2025 (UTC)

It's definitely one of these two lines:

| demographics_type1 = {{#if:{{{pop|}}}{{{pop2|}}}{{#invoke:PopulationFromWikidata | ListForInfobox | type={{{type|}}} | wikidata={{{wikidata|}}} }}|Population}}

| demographics1_info1  = {{#if:{{{pop|}}}|{{formatnum:{{{pop|}}}}}{{#if:{{{pop_year|}}}|&nbsp;({{{pop_year|}}})}}{{{pop_footnotes|}}}|{{#invoke:PopulationFromWikidata | ListForInfobox | type={{{type|}}} | wikidata={{{wikidata|}}} }}}}{{#if: {{{poprank|}}}|&nbsp;([[List of cities in Australia by population|{{{poprank}}}]])}}{{#if:{{{pop2|}}}|<br>{{formatnum:{{{pop2|}}}}}{{#if:{{{pop2_year|}}}|&nbsp;({{{pop2_year|}}})}}{{{pop2_footnotes|}}}}}

The second call to Module:PopulationFromWikidata retrieves a value in order to actually make use of it, but the first merely retrieves a value in order to determine if a value is retrievable. But in both cases, a reference is generated. If that ref uses {{cite web}}, and that also lacks a value for |url=, an error is thrown.

If the first one is altered to

| demographics_type1 = {{#if:{{{pop|}}}{{{pop2|}}}|Population|{{#if:{{#invoke:PopulationFromWikidata | ListForInfobox | type={{{type|}}} | wikidata={{{wikidata|}}} }}|Population}} }}

this might fix the issue. --Redrose64 🌹 (talk) 09:13, 5 November 2025 (UTC)

@Redrose64: Your diagnosis of the problem of a reference-with-a-backlink-to-nowhere (ref1 in the simplified examples) is the same as mine. But we don't yet have a fix. If |pop= and |pop2= are both blank, there will still be two calls to PopulationFromWikidata, and the first one will still create the reference with a backlink to nowhere.

Because the template code needs one call to the population module to determine if demographics_type1 is filled, and another to potentially fill demographics_info1, I can't currently see how two calls can be avoided. I think the only solution is a |ref=no parameter to be recognised by PopulationFromWikidata, and using it to avoid creating a reference in the first call. Anybody got any other ideas?

The {{cite web}} errors are a separate issue. If you preview the simplified infobox call (leave only the type= and state= params) in Ulladulla, you still get two references. Neither will throw the {{cite web}} error, because the wikidata for Ulludulla does have a reference URL (P854) in the reference section for the 2021 census population. But the first reference will still have a backlink to nowhere. Innesw (talk) 11:10, 5 November 2025 (UTC)

Perhaps Module:PopulationFromWikidata can be modified so that it takes another parameter to specify if a full retrieval is wanted (including ref), or a true/false value indicating whether a value is available. --Redrose64 🌹 (talk) 19:04, 5 November 2025 (UTC)

City, town, suburb, LGA .etc labels

I'll try not to add too much more to the backlog of little things to fix with this new infobox but I couldn't help but notice that the designations/labels (cities, towns, LGAs) are a little simplistic. We have big important state capitals like Sydney and Melbourne as well the capital of the nation Canberra falling under the same "city" designation as places as small as Albury and Wagga. I think some more labels are warranted to really polish up this new infobox. I'd suggest labels such as "state capital", "capital city" (obviously) and "metropolitan area" for large centres that are defined by Greater City definitions. So Sydney and Melbourne could probably have "State capital and metropolitan area" for example to better differentiate them from smaller regional cities like Geelong, Ballarat, Newcastle or Wollongong which might just have the existing "City" label. Shrubshire (talk) 03:23, 5 November 2025 (UTC)

This vague categorisation was a feature of the old infobox and strikes me as something that needs some workshopping before any attempt to implement it. Is there any reliable source we might base a better set of labels on? Triptothecottage (talk) 07:09, 5 November 2025 (UTC)

The ABS is the standard I guess. I don't think there's much to dispute about potential designations like "capital city" and "state capital". Shrubshire (talk) 09:59, 5 November 2025 (UTC)

For Canberra and the state/territory capitals, the infobox could add recognising a |type=capital value, but I don't consider it worth it for 8 places - which will all state their status in the article lede anyway. And the infobox is not wrong in stating they are cities.

There are no general reliable sources for labelling Australian settled places. The ABS explicitly does not define what is a city or a town (see ABS website), for its own good technical reasons. Having stated that fact, the ABS refers readers (somewhat vaguely) 'to state and territory lists of gazetted localities', which are usually OK for the actual formal suburbs and localities, but in most cases useless for determining if a place is a city, or even a town. In most states definitive lists for these things just don't exist.

On one hand Wikipedia should not be in the business of deciding the criteria for the city/town distinction, let alone finer calls like what is a 'metropolitan area'. On the other, without definitive external lists we may not have much alternative but to write our own guidelines. Using 'city' for a possible example guideline: The lede of the article, where '... is a city in <state>' is used, should have a reference to a source for the designation as a city - except when it's actually an urban area within a larger city that happens to be the seat of an LGA named 'City of ...'. Already we have an exception to a simple rule. To this point the documentation for the Infobox has not really attempted any such guidelines: 'city' is not defined at all, 'town' is only a little better and 'suburb' is incomplete (where are the rural 'localities'?). We could use statistical structures used by the ABS as the basis for our distinctions, and as it happens I already have a draft of guidelines on that basis - but it is not a simple text. After a little more work I'll provide it here. Innesw (talk) 11:07, 7 November 2025 (UTC)

Below is a proposed revision of the documentation for the infobox |type=. It does include some new values for the parameter, namely 'settlement', 'locality' and 'townandlocality'. Some familiarity with suburbs and localities and the ABS terms UCL and SAL is assumed.

Use of the |type= parameter

Value	Description
city	To use |type=city a verifiable source that describes the place as a city is required The Australian Bureau of Statistics (ABS) is not such a source, as it explcitly does not define, or produce lists of, cities (or towns) The lede of the article, where '... is a city in <state>' is used, should have a reference to a source for the designation as a city The fact that a place is the seat of a local government authority with 'City' in its name may suggest designation of the place as a city is valid, but other sources are probably required |type=city should not be used for an urban area within a larger UCL, even if the area is the seat of an LGA with 'city' in its name - use |type=suburb instead
town	For any other settled place that has an ABS UCL.
settlement	For a settled place that has a name but a small population (insufficient for it to have a UCL), and few or no facilities.
suburb	For any urban area that has an SAL, and is within a larger UCL. Generally used within cities and large towns for postal addressing.
locality	For a rural area that has as SAL. Localities are used in rural areas for postal addressing.
townandlocality	For where a town and a locality have the same name, and the article content is about both. The UCL is generally smaller than the SAL.
lga	An Australian local government area (LGA) - a particular form of administrative region, used to create local governments. Many LGAs will use terms such as "Town of", "District Council of", "Shire of", "City of", etc., in their names. Note that the ACT does not have any system of local government, and therefore does not have LGAs.
region	A land area, smaller than a state and (usually) larger than an LGA, either defined for a particular purpose by a government or similar body (and with well-defined boundaries), or an informal area with a commonly used name. Some well-defined regions cover areas in more than one state.
cadastral	A land area defined for purposes of land ownership registration.
other	If a named place is a location in a rural area (and there is no SAL with the name), or a named neighbourhood (without defined boundaries) in an urban area, |type=other should be used. There may be other reasons to use this value.

Note that I'm not proposing that these changes are really part of the migration to Infobox settlement wrapper process. They are requsted changes to the infobox, require more discussion, and would just hold up that process concluding. Innesw (talk) 09:30, 9 November 2025 (UTC)

This overall looks logical (in fact I actually just noticed the omission of "locality"), but I have a few questions:

• When would you envisage "settlement" being used? I think "other" suffices for these places.
• I don't understand "townandlocality". Do we have any cases where the town has a separate article from the locality? I don't think this is needed. Use "town" if it has its own UCL, or "suburb" or "locality" otherwise.
• An important reason to use "other" is for islands, even if they are technically localities. We appear to already do this. To take one example, it would seem overly pedantic to me to lead the infobox at French Island with a "type" stripe declaring it a "locality"; obviously it is an island first and foremost, and that is self-evident from its name, so no "type" stripe is needed - this is exactly the behaviour of type=other. I'd want to add islands as a specific example under "other".

This, that and the other (talk) 00:53, 10 November 2025 (UTC)

The purpose of "townandlocality" seems to be to ensure that the map and categorisation (and population data? might need Innesw to confirm) reflects that the name refers to two areas which use the same name but with distinct local boundaries. It looks like a clever solution to me. Triptothecottage (talk) 02:08, 10 November 2025 (UTC)

Responses:

• Re "settlement", I envisaged it for places like Molesworth (about 8 houses in an open cluster, population 91 for the whole SAL), which is really pushing it to be described as a town, but that's the only current option. Also (it being quite specific) "settlement" could show the SAL population by default, whereas "other" would mean no Wikidata population would be shown.

We could use "locality", but only so long as the article-editor is aware this is really the larger SAL - unfortunately it's very easy for locality=SAL and locality=very-small-point-place to be confused. It's also possible (though I can't quote one) that a small named settlement does not have the same name as the surrounding SAL, so it shouldn't be labelled as a locality.

• Re "townandlocality", the intention was to emphasise to readers that there are two geographic entities with the same name - which may help explain two sets of population figures, for example. Partly it is also trying to hint to editors (readers of the Infobox template documentation) that both might exist, and they could (should?) both be covered in the article. There are articles where the lede is 'X is a town ...' (which don't seem to acknowledge that a larger area (SAL) exists) and others with 'Y is a town and locality ...' (which obviously do), and "townandlocality" would put the same in the infobox subheader. Yes "townandlocality" was intended for (a) categorisation, (b) maps (though maps of UCLs are rare - and they are not in OpenStreetMap) and (c) populations, where I would envisage both "town" and "townandlocality" showing both the UCL and SAL populations from Wikidata (which doesn't happen at the moment, but could). I agree it would be fairly rare to have separate articles for the town and its same-name locality (where 'locality' is meant in the rural-SAL sense, distinct from 'suburb').
• I must admit I hadn't really thought much about what the uses for "other" would be (apart from being a catch-all for 'everything else'). Islands: yes. Suburban neighbourhoods and chinatowns (that are not SALs): yes. I suppose any list would go on forever!

Currently |type=other is supposed to show a blank sub-header (the 'type stripe' mentioned above), and also never an automatic Wikidata population. But might there be a case for allowing over-riding the blank sub-header text with eg: "Island" if |type=other? The other |type= values should continue to have hard-wired sub-header texts.

Innesw (talk) 23:32, 10 November 2025 (UTC)

Reading your responses, I realise I was making an assumption - that is that every Australian "inhabited place"/"settlement" article is about a locality, certain exceptional cases excluded. In particular, it seems self-evident to me that an article on a town would also cover any hinterland area also within the bounded locality; after all, where else would such information go? Some of my doubts expressed above may make more sense when viewed through this possibly Victoria-centric lens. However, this is a nationwide infobox, and I notice the "...is a town and locality" lead sentence is mainly found for places outside Victoria. Perhaps it is worth including "townandlocality" on those grounds, although I must say I still find it a bit strange - at the very least, it seems to make the "town" type fundamentally redundant, except in cases where a locality hosts two towns (are there any?) or a town genuinely spans more than one locality without being a city (again, are there any? Is Torquay-Jan Juc, for instance, genuinely a single "town"?)

By the logic of "townandlocality", though, shouldn't Molesworth be classified as a "settlementandlocality"? I think that's a bit much; I'd rather stick to "locality" in these cases. Localities without a town do sometimes have a defined "centre" that you can point to, which might be a small cluster of buildings, say, a hall and a church, constituting the "village". (Glenburn - not far from Molesworth incidentally - would be another example.) I'll admit it is an interesting edge case though, and I don't have strong feelings about it.

I agree with you re UCL/SAL populations. I'm still not sure about "French Island [new line] Island" though... maybe other "other"s would have a stronger case for a custom type stripe. This, that and the other (talk) 08:39, 11 November 2025 (UTC)

I take your point about islands, use of |subheading=Island would usually be redundant - so just leave |subheading= blank. One example I can see where it might be useful is Pine Gap, where an infobox subheading of 'Military Base' could make sense. I'm sure there are others where the name in itself gives no hint of the kind of place.

There also seem to be quite a number of articles on indigenous communities where their small size means "town" makes no sense, the editors have gone with "other", and set a short description of "Community in <state>" (eg:Wakathuni Community). |subheading=Indigenous Community could make sense here, though the alternative would be to have |type=settlement.

I also take the point about "settlementandlocality" going too far, and given the reality on the ground either 'town' or 'townandlocality' are redundant. So I'm bending (slowly, maybe ...) to just using "town" and "settlement", but emphasize in the template documentation that any article using either needs to check for the existence of a surrounding locality (or, for larger towns, the included suburb) with the same name, and either talk about it in the article (at least acknowledge its population) or point to an article about it (for which the extreme case is a capital city and a separate article about the CBD suburb). Innesw (talk) 23:18, 12 November 2025 (UTC)

Williams Landing

A script error is showing in the hidden categories at Williams Landing but with no visible message in the article. Previewing an edit of the article with everything other than the infobox shows that the problem is in the infobox. I suspect it's related to population but don't know. I believe it's due to recent edits here. Johnuniq (talk) 09:14, 5 November 2025 (UTC)

The script error is:

—Trappist the monk (talk) 12:53, 5 November 2025 (UTC)

Thanks!

How did you get to that error message? I've also been noticing that article in the errors category for a while now, but the error wasn't apparent and I would just move on to others. --Joy (talk) 12:57, 5 November 2025 (UTC)

comment out everything in the infobox except the |type= and |name= parameters then Show preview.

—Trappist the monk (talk) 13:05, 5 November 2025 (UTC)

Ahh, so the static pop* fields shadow the output, but the WD lookup still happens. Maybe the ordering of these actions needs to be reversed as a start. --Joy (talk) 14:17, 5 November 2025 (UTC)

The technical reason for the error is that the Wikidata item Williams Landing (Q8021059) does not have any text in its English label, ie: item.labels.en is nil. The module assumes it is not nil (it doesn't check), and (b) attempts to use it as the default title for the reference, which aborts the module and returns the error in the returned text. So the technical fix in this instance would be to have the english label set to 'Williams Landing'. But the module really should check that it's not nil before attempting to use it. The question will then be what to use as a reference title if the label is nil and so is the title (P1476) in the WD reference (which in this case is filled). Probably it should use the page title if all else fails? Innesw (talk) 22:32, 5 November 2025 (UTC)

Cann River, Victoria

Same or related problem? See ref 1 at Cann River, Victoria. At this writing it renders summat like this:

[[]]. "Cann River (urban centre and locality)".

with an |author= has numeric name error message and the backlink carat (^) doesn't link to anything.

As at §Williams Landing above, I commented out all of the {{infobox Australian place}} parameters (except |type= and |name=) and previewed. When I did that, both ref 1 and ref 2 have the same text and error message. Backlink carat for ref 1 still links to nothing; the ref 2 backlink carat links into the infobox at Population total.

—Trappist the monk (talk) 20:25, 28 November 2025 (UTC)

The existence of the ref 1 that has the backlink to nowhere is because of the call to Module:PopulationFromWikidata used to determine if any populations exist in the wikidata. With only |type= and |name=, the second ref with a working backlink is from the call that actually puts output in the infobox. (See issue with Canberra in § Canberra CS1 errors from Module:PopulationFromWikidata above.)

The [[]] (and the {{cite web}} |author= has numeric name error you might see in preview) are because the module is returning the 2006 wikidata item, which has an inadequately detailed reference. The module should deal better with these old references. But why it's using the 2006 wikidata instead of the 2021 I haven't figured out yet. Innesw (talk) 01:24, 29 November 2025 (UTC)

I now have the reason. Because |type=town the current module uses UCL data by default, and will only use other (eg: SAL) data if there is no UCL data - for any date. UCL data exists for Cann River for (2001 and) 2006, but after that the ABS dropped the Cann River UCL. The module returns the latest of the UCL figures, and just ignores the later SAL data.

I'm still working on fixes for (a) the |author= has numeric name error in the old references, and (b) the refs with backlinks to nowhere.

mapframe-point=none

Following Template talk:Infobox mapframe, this parameter override looks like it was a bad idea.

In the old version [6], we only had:

{{#if:{{{local_map|}}}|{{Infobox mapframe|zoom={{{zoom|}}}|id={{{local_map_id|}}}}}{{{local_map_caption|}}}}}

I think it's safer to just go back to the equivalent of that then. --Joy (talk) 08:06, 8 November 2025 (UTC)

I tried this in the sandbox, but something went wrong, half the testcase table calls are now weirdly broken, I must have overdone it with [7] but I'm not sure how. --Joy (talk) 08:25, 8 November 2025 (UTC)

Figured out the rate limit, split out newer test cases to a new subpage. Will deploy the conservative version of this fix now. --Joy (talk) 13:55, 8 November 2025 (UTC)

I have got to say I am not a fan of this change. It's a particular problem for articles that use geoshape rather than OSM map data, like the former Victorian LGAs (City of Footscray for an example), because the coordinate location field in Wikidata is compulsory even when it doesn't necessarily make sense. Without a coordinate location, the geoshape simply doesn't work.

I think showing the marker in these cases is a bad idea, for several reasons:

• It's not clear to the reader what the marker represents. In fact, I think it's not even clear to editors what the coordinates on Wikidata are supposed to mean; in some cases (e.g. Shire of Kerang) it seems to just be a random location.
• The marker is quite large and uses a "building" icon for no discernable reason.
• Suppose we decided the marker should represent the council headquarters. Leaving aside that this is (to me) unnecessary detail, as well as the fact that it's sometimes extremely difficult to reconstruct where in the town the headquarters were actually located, consider the fact that the Shire of Kerang's HQ was in Kerang itself. The big blue marker, placed there, will largely cover up the "hole" in the polygon representing the Borough of Kerang enclave - arguably the most interesting part of that map...
• When you click on the marker, the label popup just repeats the article title, offering no further explanation.

I'd like to see this marker removed from geoshape maps, perhaps with an override to explicitly turn it back on if wanted (although I'm not aware of any articles requiring that). This, that and the other (talk) 02:23, 10 November 2025 (UTC)

I see it appearing even on articles about localities with OSM-based maps (Lara, Victoria). Here, the marker is nothing more than clutter. This, that and the other (talk) 02:25, 10 November 2025 (UTC)

This sort of a distinction, turning off the point marker without the risk of breaking shapeless maps, should be implemented in the code that is doing the P402/... lookup, because that's where we can prevent the awful failure from happening.

(I'd have said oh just revert to turning off the point by default, but the failure was on Brisbane. I don't think we should prioritize optimization of visual details in small places when there's a risk that a much more significant map goes to null island.) --Joy (talk) 07:54, 10 November 2025 (UTC)

@Hike395 after the latest round of fixes to Infobox mapframe argument parsing, is this edit now safe? --Joy (talk) 12:40, 10 November 2025 (UTC)

Yes, it should be safe. See Template:Infobox mapframe/testcases#Infobox tests where I explicitly test Brisbane with no marker. — hike395 (talk) 13:03, 10 November 2025 (UTC)

I see the markers have disappeared again for now, so I am happy! This, that and the other (talk) 08:53, 11 November 2025 (UTC)

Yeah, I applied the change as soon as I got the confirmation. --Joy (talk) 09:44, 11 November 2025 (UTC)

Demonym?

Have always been confused why this template doesn't have a 'demonym' parameter like the usual settlement infobox. Is there a particular reason for this or has it just not been brought up before? Loytra^✨ 16:34, 11 November 2025 (UTC)

Sydney
City
Country	Australia
Demonym	Sydneysider

These days there's no longer any technical reason at least. An example is to the right. --Joy (talk) 17:51, 11 November 2025 (UTC)

I'm pretty clueless with templates so, how does that work exactly? The parameter doesn't show up in the documentation. Loytra^✨ 10:46, 12 November 2025 (UTC)

Maybe we should make the documentation here more clearly explain that all Infobox settlement parameters that aren't documented as overridden here are actually available. --Joy (talk) 11:21, 12 November 2025 (UTC)

Or we should prevent their use completely, by putting all the unused IS fields in the wrapper _exclude. OK, the Australian infobox has had its visual layout changed by the wrapper migration, but it probably should still restrict the available fields to what make sense in Australia. Allowing previously unsupported fields really needs discussion for each case (eg:|demonym=, which started this thread), rather than allowing them carte blanche just because they are available in IS. Innesw (talk) 23:53, 12 November 2025 (UTC)

One good reason to use a wrapper is to make fields available without having to explicitly add them one at a time to the template. What fields in {{infobox settlement}} should never apply to any settlements in Australia? – Jonesey95 (talk) 02:19, 13 November 2025 (UTC)

I have no idea why we would want to be prejudiced against settlement-related information in a settlement infobox by default. --Joy (talk) 06:02, 13 November 2025 (UTC)

It's not prejudice against the information - some of the fields made available by {{Infobox settlement}} may be perfectly valid in the Australian context. But adding these new fields - and there are a significant number - has not had any discussion.

The old template had 63 unique-meaning fields. IS has about 128. (In both cases I'm filtering out multiples (xx2, xx3 etc.), footnotes, settable field or section titles and fields for alternative units.) Of this 128, 56 are in explicit use by the wrapper. This leaves 72 fields with new meanings available, simply because if IAUP does not explicitly deal with them they are passed through to IS as-is. In the TFD and discussion above the focus was on like/dislike of the new visual appearance, and whether all the information shown in the old template was still shown in the new one. In those discussions it was never made explicit that the template now has more than double the number of fields available than was the case previously. I queried what was happening with |native_name= in the above discussion, and it was explained it was passed through to IS automatically - but that didn't bring the immediate realisation that all the other IS fields would be the same. It is only with this discussion of demonym that I realised how much change this really is.

If we take demonym/population_demonym as an example, there was a discussion about whether to include this in the Australian infobox, and there were arguments against it. (I do recognise that the argument that changing the infobox template for the small number of known cases wasn't justified is now redundant, but the other arguments are still valid.) Now it is simply available, without any further discussion (let alone consensus) about whether it should be in this infobox.

That's just one example. Adding some of the other IS fields may be uncontroversial, but yet others could well be, and need consensus before being added to the Australian infobox. Innesw (talk) 11:29, 22 November 2025 (UTC)

It wasn't said explicitly because it went without saying. It's a documented feature of {{template wrapper}}.

The discussion about the demonym field from 17 years ago is long obsolete - consensus can change.

At the same time, the arguments against it back then seem entirely spurious. If someone uses the field inappropriately, the recourse is to remove that bad edit. Preventing even the concept of good edits to a field just because there's a risk of bad edits strikes me as antithetical to the WP:Five pillars of Wikipedia. --Joy (talk) 12:46, 22 November 2025 (UTC)

Request to Implement Changes

The sandbox has had the following changes made. Could somebody with the permissions move them to the live template please.

• moved |established_title1 = [[Gazetteer of Australia|Gazetted]] and established_date1 = {{{gazetted}}} as per (the bottom of) this topic
• changed TraditionalOwners* to FirstNations* as per this discussion

NB: just copy the sandbox, there were other changes in the live template I copied back to the sandbox before I made the above changes. Innesw (talk) 23:28, 8 December 2025 (UTC)

parishes are being linked automatically?

The template documentation says the parishes are plain text but can be linked. But when I look at Coochin Creek, the parish appears as a redlink with the text Beewah, but when I look at the plain text in the infobox it has Beerwah unlinked

| parish = Beerwah

so it is unclear why it is being red-linked. As far as I know, we have no articles for parishes in Queensland (we ceased using them for cadastral purposes around 1990-ish) so there's not a lot of point in trying to link to a parish article. Kerry (talk) 02:24, 13 December 2025 (UTC)

I note that there is benefit in recording counties and parishes for Qld places in the infobox for historical purposes, but I doubt anyone will be writing articles about parishes in Queensland any time soon. Kerry (talk) 02:27, 13 December 2025 (UTC)

|county= and |parish= are both enclosed in {{auto link}}, which is a redirect to {{link if exists}} and will link the text if a matching article name is found. I don't see any way to prevent a link or to stop it from linking to a disambiguation page. {{Auto link}} was recently merged with {{link if exists}}, and I suppose that the template's behavior may have changed. – Jonesey95 (talk) 05:05, 13 December 2025 (UTC)

|parish= was not linked in the version before the big migration that happened in November. – Jonesey95 (talk) 06:08, 13 December 2025 (UTC)

The redlinks for non-existent articles seem to have gone: |parish=noarticle just produces plain text. If an article with the parish name does exist, it's almost guaranteed not to be an article about the parish, but one about a town with the same name (maybe even in a completely unrelated location) or a disambiguation page (that probably won't have a link to a parish article either), both of which are unhelpful to readers who click on the parish name in the infobox.

I suggest that {{autolink}} be dropped from the infobox handling of |parish= altogether. If editors want to link the parish name to a parish article they can still do so (see City of Botany Bay linking to Botany) but linking to an article not actually about the parish is just misleading.

I would actually query whether cadastral parishes are in fact notable enough for articles anyway. Their existence in a place-names register is not enough to justify an article - appearing in the list of parishes in the parent county article is (I think) sufficient. Innesw (talk) 03:07, 17 December 2025 (UTC)

I agree that most parishes are unlikely to reach notability for an article and that appearing in the list of parishes in the parent county suffices in the absence of any notability. I agree that autolink should be dropped as it is unlikely to take the reader anywhere useful. In think in the few cases where a notable parish article does exist, it can be manually linked from the infobox or wherever (as these would be rare exceptions). Kerry (talk) 07:10, 17 December 2025 (UTC)