Infobox Australian place is within the scope ofWikiProject Australia, which aims to improve Wikipedia's coverage ofAustralia andAustralia-related topics. If you would like to participate, visit theproject page.AustraliaWikipedia:WikiProject AustraliaTemplate:WikiProject AustraliaAustralia
This template is within the scope ofWikiProject Cities, a collaborative effort to improve the coverage ofcities,towns and various othersettlements on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.CitiesWikipedia:WikiProject CitiesTemplate:WikiProject CitiesWikiProject Cities
Make sure you remember that this box is used on more than 12,900 pages, of 7 different types.[1] Whatever you do needs to be applicable to a good number of those pages.
Discussion/Community
Its very important to discuss everything that's going to change. And before you suggest something, look in the archives, it may have been suggested before.
In thesandbox I have implemented this as aTemplate wrapper forInfobox settlement. Below is a detailed breakdown of the how and the why. Note that this has also been nominated formerger, the discussion is avaliablehere.
Arguments
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
Standardizes the microformats and HTML classes that are applied to information
makes use of{{Convert}}. The current template has hardcoded{{rnd|{{{area}}}/2.589988110336|1}} to convert the area from km2 to sq mi...
The use ofModule: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
The various colors that clutter the infobox and violateMOS:COLOR
Things kept
ALL information. No parameters or information has been removed from the template. It just displays in a different format.
The logic behind how coordinates, state and city are determined.
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 the1100 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...
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.
The custom logic designed to implement{{short description}} on each page.
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 acookie. 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 simplefix it. --Zackmann (Talk to me/What I been doing)18:41, 4 October 2025 (UTC)[reply]
@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 ofModule: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 asUser: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)[reply]
I think we just need to map local_map = 1 into mapframe = on, forRaymond 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)[reply]
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)[reply]
@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 (seethe 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 fromover 10,000 pages. You convinced me. Finally I have restored the|visitation_num= and related params. Your point that thechange 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 thatif 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 includingJonesey95,AussieLegend andFrietjes (among many others) have done admirable jobs keeping this template going, but it has been in desperate need of arefactor. To be clear when I sayit 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 wouldnever 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)[reply]
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)[reply]
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 yourAWB processesat 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)[reply]
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)[reply]
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 achange 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 DavisTalk11:00, 5 October 2025 (UTC)[reply]
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)[reply]
@ScottDavis: I will second whatJoy 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 isNOT intentional and should definitely be resolved. -Zackmann (Talk to me/What I been doing)17:23, 5 October 2025 (UTC)[reply]
@Michael Bednarek[2] 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)[reply]
Thelocal_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 thefinal 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)[reply]
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 adraft of the module, which has a /doc page giving details of all the proposed changes, and atestcases page comparing the existing and module-based outputs. Note that the module calls amodified 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)[reply]
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)[reply]
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 (usingTemplate_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'mnot 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)[reply]
@Innesw: I'm not sure whatJoy was getting at with the code size either. What I will say is a couple of nice things about the wrapper solution:
Module:Template wrapper is well maintained and widely used (745,000+ uses). It is known to be bug free at this point.
Same goes forTemplate: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.
By using this Module and Template, any future upgrades will automatically be included.
I'm notnecessarily arguing thatTemplate_wrapper andInfobox_settlement are not the way to go, but they could be used with a Lua version of the custom code, and Iam arguing that thismay 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 atthe 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?
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)[reply]
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 inDLL hell, YMMV :) --Joy (talk)11:49, 9 October 2025 (UTC)[reply]
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 divisionsInnesw (talk)02:49, 10 October 2025 (UTC)[reply]
(in the sandbox) I've moved the call toPopulationFromWikidata 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 showbelow the wikidata population(s). Maybe all the population stuff moves to demographics1_* ?Innesw (talk)05:03, 10 October 2025 (UTC)[reply]
@Innesw andJoy:. Good news. Go over toSydney'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 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.
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?
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)[reply]
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 standardforever...
Certainly 99%+ of the calls to PFW will be from the infobox (that is what is was designed for) - though therehave 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 thelatest 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: 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 ofModule: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)[reply]
I wrote theupgrade 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 thetestcases 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)[reply]
@Innesw:Facepalm why must everything be so complicated... I do agreethat'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.
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:
the local map should (I think) only be showing if|local_map=<not blank>, it seems to be defaulting on
that map should (usually) be showing with the red outline of an area, not an icon.
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?
@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 onSydney if you preview using{{Infobox Australian place/sandbox}}. The only way around this is to removedirect support for image2.
This will result intemporary 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 about463 pages, (theparam 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)[reply]
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}}
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)[reply]
@Joy andInnesw: 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)[reply]
Are you referring tothe 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)[reply]
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)[reply]
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)[reply]
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?
@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 modifyit 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 ofSydney is a good one though. That will def just move to{{{image_map}}} Additionally there are about65 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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}}. Ithink 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)[reply]
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)[reply]
@Innesw andJoy: 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)[reply]
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)[reply]
@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)[reply]
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)[reply]
Purely cosmetic, but I've removed the stray border lines in the nearby-places sub-table. Also removed all the empty cells ifnear-* 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)[reply]
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 perIMAGESIZE. 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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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 atTemplate talk:Infobox settlement if there's use cases where this phrasing doesn't work. --Joy (talk)07:42, 23 October 2025 (UTC)[reply]
I was intrigued to notice that native_name is being passed through thewrapper 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)[reply]
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 theparent 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)[reply]
BTW, I just happened to find an interesting case in the protected area conversions -[3] 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)[reply]
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)[reply]
There has been a discussionhere 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 usesubdivision 5 (which is currently empty in the sandbox), with 'First People(s)' in thetype, and putting|first_peoples1=,|first_peoples1_footnotes=,|first_peoples2= and|first_peoples2_footnotes= into a{{plainlist}} in thename. I'll have a go at it, but it may need checking/fixing.Innesw (talk)09:48, 23 October 2025 (UTC)[reply]
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 thatWP: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)[reply]
@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)[reply]
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)[reply]
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). UsesModule:Australian place map to get the actual map.
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)[reply]
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)[reply]
I've been working on an uprade of{{PopulationFromWikidata}} that ishere 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: UCLand 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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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).[1] (Data is fromUlladulla(Q649969), as is the table below.)
The HistoricPopulations function in the upgrade has a citation for each population number.
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)[reply]
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)[reply]
You are invited to join the discussion atWikipedia:Australian Wikipedians' notice board § Traditional Owners on Template:Infobox Australian place.ClaudineChionh(she/her ·talk ·email ·global)01:37, 19 September 2025 (UTC)[reply]
--Zackmann (Talk to me/What I been doing)18:41, 4 October 2025 (UTC)[reply]
Fixed. I did in fact have a missing
Facepalm why must everything be so complicated... I do agree
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...