Template talk:Infobox Australian place/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Wrapper of Infobox settlement

Wrapper - proof of concept

Template:Infobox Australian place/sandbox turned into a wrapper [1].

Compare at Template:Infobox Australian place/testcases . TerraCyprus (talk) 14:38, 15 September 2020 (UTC)

Wrapper - pushpin map

Major issue: Module:Australian place map sometimes returns maps below the state level, this is not implemented in |pushpin_map= yet. I don't understand the code in the module and have no experience with lua. @Frietjes: you created that module, could you make it work that |pushpin_map= gets any sub-state-level map and while the switching between different maps is kept? TerraCyprus (talk) 14:23, 15 September 2020 (UTC)

TerraCyprus, can you point to an example? I don't know why there are duplicate maps in all the testcases, so not sure what you mean by "sometimes". if I recall, that module is used for more than one infobox, so we may need to fork it to avoid breaking the other infoboxes. Frietjes (talk) 14:30, 15 September 2020 (UTC)

Frietjes, thank you very much. On Template:Infobox Australian place/testcases it can be seen for St Kilda, Victoria, a suburb of Melbourne. In all other cases on testcase-page the Module:Australian place map is not needed. Yes, the maps are duplicated in sandbox, that is because I step by step moved code to the wrapper part, but this pushpin map stuff I could not convert properly. TerraCyprus (talk) 14:38, 15 September 2020 (UTC)

Frietjes, I think I found and solved it [2], and in the module it is near Apply legacy parameters. TerraCyprus (talk) 14:52, 15 September 2020 (UTC)

TerraCyprus, I didn't think you could put # in a parserfunction like that without it being converted to <ol> markup. also, FYI, per this thread no pushpin map when there is an LGA map. Frietjes (talk) 14:56, 15 September 2020 (UTC)

Frietjes, I don't know. But for |pushpin_map= the # is the way to enable map switching. TerraCyprus (talk) 15:03, 15 September 2020 (UTC)

Frietjes pointed to Template_talk:Infobox_Australian_place/Archive_8#Coordinates_in_infoboxes, saying "no pushpin map when there is an LGA map". The LGA map is a pushpin map too, isn't it? TerraCyprus (talk) 15:02, 15 September 2020 (UTC)

I believe the outcome was "no state or national pushpin map" when there is an LGA map, but consensus can change (for example Port Stephens Council in the test cases). in any event, the primary map should be the most specific (so national map last). Frietjes (talk) 15:08, 15 September 2020 (UTC)

Yes, maybe switching was not an option at that time. You changed the order [3] and this is fine with me and probably also with those that once opposed a higher level map - now it only appears after explicit request by the reader. Thank you for you help. TerraCyprus (talk) 15:26, 15 September 2020 (UTC)

TerraCyprus, I made some changes so "force_national_map" works and the last two cases are no longer showing duplicate maps. Frietjes (talk) 17:14, 15 September 2020 (UTC)

@Jonesey95 and Frietjes: maybe a new consensus could be to allways have a national map in the switcher, then "force_national_map" would be superfluous? TerraCyprus (talk) 17:36, 15 September 2020 (UTC)

force_national_map is for suppressing lower level maps, not for adding a national map. Frietjes (talk) 17:19, 17 September 2020 (UTC)

Wrapper - logo

@McVahl: regarding your request for the placement of the image, in the wrapper version it is a bit more to the top now. But I found no way to move it further up, should be addressed at Template_talk:Infobox settlement. One could use the shield/coatofarms image parameters, but a logo isn't any of these. TerraCyprus (talk) 15:31, 15 September 2020 (UTC)

TerraCyprus, OK to me. Better than what is on live version. Thanks. – McVahl (talk) 12:46, 5 October 2020 (UTC)

I disagree. The live version is fine. --AussieLegend (✉) 13:09, 5 October 2020 (UTC)

Is fine because..? I think there is no consensus on how such thing will be displayed. However, aesthetically speaking, why is the logo in between the data rows? And not below/above all other images, which is common among general infoboxes? – McVahl (talk) 11:48, 6 October 2020 (UTC)

McVahl, I would like to know that too. TerraCyprus (talk) 16:19, 6 October 2020 (UTC)

AussieLegend The live version is fine. why? And does that preclude the creation of something finer? TerraCyprus (talk) 16:21, 6 October 2020 (UTC)

The live version does everything that it needs to do, and more, is easy to use, is aesthetically appealing and not bloated. I don't consider Infobox settlement to be "something finer", especially when you compare it to other infoboxes. As far as the logo goes, that is only used for LGAs and generally, it's of little importance, or at least a lot lower importance than the other data in the infobox. --AussieLegend (✉) 16:25, 6 October 2020 (UTC)

Re The live version does everything that it needs to do, and more, is easy to use, is aesthetically appealing and not bloated that is equally true for the wrapper version. With the benefit on top, to have the image issue mentioned by McVahl addressed by placing the image a bit higher. TerraCyprus (talk) 19:12, 6 October 2020 (UTC)

Little importance? There are over 500 LGAs in Australia, so assume 500+ LGA articles are using |logo= parameter. Would rather consider something “low important” if there are only less than 20 articles. – McVahl (talk) 20:19, 6 October 2020 (UTC)

that is equally true for the wrapper version. No, just ... No! The wrapper version handles some data differently to the way that this infobox does. Infobox settlement is not easy to use, which is why you need to create a wrapper in the first place. It is not aesthetically appealing. There is just something wrong with the font and spacing in IS. It's like the 87-year-old whose tramp stamp doesn't look the same as it did when she was a 19-year-old hottie many years ago. By comparison look at any one of a number of other infoboxes: {{Infobox television}}, {{Infobox person}}, {{Infobox film}}, {{Infobox building}}, {{Infobox monument}}, {{Infobox protected area}}, {{Infobox school}}, {{Infobox university}} etc. They all look a lot better than IS, especially without the ridiculous horizontal lines. Note that this infobox generally mirrors the appearance of those. IS actually hurts my eyes. The others don't. As for bloating, the wrapper is based on IS. The wrapper is just under 24.6kB, IS is 59.8kB. This entire infobox is just under 22kB, which is even smaller than just the wrapper. So yes, the wrapper/IS is bloated.

With the benefit on top, to have the image issue mentioned by McVahl addressed by placing the image a bit higher. There is no rule that states all images have to be at the top of an infobox. {{Infobox university}} (used on more than 22,500 pages) has the logo at the bottom. See, for example, University of Oxford.

Little importance? - I actually said it's of little importance, or at least a lot lower importance than the other data in the infobox.. You missed the crucial second part. Infoboxes should prioritise information. Location, population, area etc are important information. The logo is less important and many LGAs regularly change theirs. That's why it's lower down than the more important information. --AussieLegend (✉) 16:56, 7 October 2020 (UTC)

Wrapper - country flag

Just a little thing, but I don't think we generally include flags in infoboxes. Looks great otherwise! ItsPugle (please ping on reply) 06:35, 17 September 2020 (UTC)

ItsPugle, thank you for the feedback. Looked at that MOS:INFOBOXFLAGS: "Human geographic articles – for example settlements and administrative subdivisions – may have flags of the country and first-level administrative subdivision in infoboxes." But I am fine without the flag. TerraCyprus (talk) 15:37, 17 September 2020 (UTC)

@Jonesey95, ItsPugle, AussieLegend, Techie3, and Frietjes: what would you prefer? country= {{AUS}} or [[Australia]]? TerraCyprus (talk) 17:14, 17 September 2020 (UTC)

• no flag for now. we can discuss adding flags later if there is desire to do so. for now, we should focus on making the new version look as similar as possible to the old version. after that, we can discuss styling improvements. Frietjes (talk) 17:18, 17 September 2020 (UTC)
• no flag for now per Frietjes. TerraCyprus (talk) 17:24, 17 September 2020 (UTC)

Wrapper - module via parameter

@Betterkeks: re your request above, now with the wrapper it could be *very* easily be coded so that a value of |module= in the Australian place template is passed to to |module= in {{Infobox settlement}}. But first it would be needed to use the new wrapper code. TerraCyprus (talk) 15:35, 15 September 2020 (UTC)

Wrapper - population density bullet point

@ItsPugle, Jonesey95, AussieLegend, and Michael Bednarek: re your discussion about the presentation of the population density. The wrapper in the sandbox implements the standard behavior of {{Infobox settlement}}, that is a bullet point before "Density", but inside a section for population, not standalone. TerraCyprus (talk) 15:40, 15 September 2020 (UTC)

Looks fine to me. – Jonesey95 (talk) 16:04, 15 September 2020 (UTC)

Ditto! ItsPugle (please ping on reply) 06:33, 17 September 2020 (UTC)

Wrapper - image size

The image at the top of the sandbox infobox is quite small. I experimented just a little bit to see if I could make it larger, but I was unsuccessful. – Jonesey95 (talk) 16:04, 15 September 2020 (UTC)

Jonesey95, "imagesize = map_size = pushpin_mapsize = 300px // so that all images have the same size, and the box gets the maximum width via the maximum allowed image size for infoboxes". [4]. I guess it is often not set. And since at least three images are involved, I hardcoded it to ensure all three images have the same size and used the maximum allowed for infoboxes, which will make the box wider and result in more of the text be presented on each line meaning fewer lines for long text. TerraCyprus (talk) 16:52, 15 September 2020 (UTC)

That looks better, on my screen at least. – Jonesey95 (talk) 17:05, 15 September 2020 (UTC)

Jonesey95, you reduced the pushpin map to 250px. It is smaller than the current standard, which is 270px - at least for me for most, not all, of the tests at Template:Infobox Australian place/testcases. What about 270px? TerraCyprus (talk) 17:01, 16 September 2020 (UTC)

That is probably fine. It should be as close to the {{Infobox settlement}} default as possible. – Jonesey95 (talk) 17:53, 16 September 2020 (UTC)

Jonesey95, agreed. TerraCyprus (talk) 22:13, 16 September 2020 (UTC)

Has anyone actually bothered to look and see how Infobox Australian place handles image sizes? These were chosen for specific reasons after examination of hundreds of articles. --AussieLegend (✉) 06:48, 17 September 2020 (UTC)

Do you have a link to any previous discussion about this? I was unable to find any discussion about such, and would think that we would then use the default infobox image size of 220px (75% of the default image size), which is done anyways with: {{#invoke:InfoboxImage|...|upright=yes}} ItsPugle (please ping on reply) 08:10, 17 September 2020 (UTC)

There have been several discussions over time, both here and at multiple other pages as issues have arisen in different articles. You don't really need them though, just look at the sizes that the infobox has used for years. Look in the testcases at City of Mandurah for example. The sandbox version makes the image ridiculously large. For Raymond Terrace, while the image and the map are roughly the same width, the sandbox version has the image much wider, which doesn't look good at all. --AussieLegend (✉) 09:26, 17 September 2020 (UTC)

The Mandurah test case uses |image_upright=0.81, which looks like it isn't being passed to infobox settlement correctly in the sandbox (or maybe it is being overridden by the default image size?). Thanks for pointing out that problem, which someone will need to fix. – Jonesey95 (talk) 14:06, 17 September 2020 (UTC)

@Jonesey95 and ItsPugle: Template:Infobox_settlement#Images,_nickname,_motto mapsize, imagesize: "If used, px must be specified;", pushpin_mapsize: "The default value is 250."

1. imagesize || optional || Can be used to tweak the size of the image_skyline up or down. This can be helpful if an editor wants to make the infobox wider. If used, px must be specified; default size is 250px.
2. mapsize || optional || If used, px must be specified; default is 250px.
3. pushpin_mapsize || optional || Must be entered as only a number—do not use px. The default value is 250.

I did set imagesize = 300px to make the infobox wider and did set the values for the others to 300 too, since a width of 300 is there anyway and to have it look more harmonious by having all images with the same width. Feel free to revert [5] and return to per article settings, which may result in different infobox sizes even for same type of entity. TerraCyprus (talk) 15:30, 17 September 2020 (UTC)

@Jonesey95, ItsPugle, AussieLegend, and Techie3: width for imagesize, mapsize, pushpin_mapsize now 270, that seems to be the value for most of the images when using the current live box. [6]. It is also the size of the OSM map in the Raymond Terrace testcase. Any issues? TerraCyprus (talk) 17:06, 17 September 2020 (UTC)

Per WP:IMGSIZE, "Except with very good reason, do not use px (e.g. |thumb|300px), which forces a fixed image width measured in pixels, disregarding the user's image size preference setting." this infobox doesn't force image sizes, it does as WP:IMGSIZE says and uses "image_upright". "px" was removed a long time ago. The default image width for Australian articles is |image_upright=1.23. Some infoboxes have 2 images, a locator map and a suburb map and can result in the infobox taking up far more real estate than it should, especially on the many barely-a-stub articles that we have. This also ensures that all the images and maps default to a similar size. --AussieLegend (✉) 17:21, 17 September 2020 (UTC)

And there is "very good reason" and there is

• Wikipedia:Image use policy: If px is used, the resulting image should usually be no more than 500 pixels tall and no more than 400 pixels wide, for comfortable display on the smallest devices "in common use" (though this may still cause viewing difficulties on some unusual displays). To convert a px value to scaling_factor, divide it by 220 and round the result as desired.
• Wikipedia:Image use policy#Infobox and lead images: The lead image in an infobox should not impinge on the default size of the infobox. Therefore, it should be no wider than upright=1.35 (equivalent to 300px at the default preference selection of "220px").

With 270<400 and 270<300 the sandbox version does not violate the width regulation of Wikipedia:Image use policy. TerraCyprus (talk) 17:40, 17 September 2020 (UTC)

Finished emulation of Image_Upright.Techie3 (talk) 03:37, 20 October 2020 (UTC)

Wrapper - general discussion

What is this discussion aiming to achieve? --AussieLegend (✉) 15:52, 15 September 2020 (UTC)

Can't speak for Terra, but I think they may be trying to turn the template into a wrapper. ProcrastinatingReader (talk) 17:59, 17 September 2020 (UTC)

There was no consensus to do that at the recent merge discussion. --AussieLegend (✉) 13:07, 5 October 2020 (UTC)

As you know, the meaning of 'no consensus' does not prohibit renomination, or further work on achieving consensus. The close explicitly says There could be more consensus for a merge if a demonstration of the merged template were created first, which is being done here. I think we can agree that TerraCyprus is working on this in a productive manner in the sandbox first, and from the looks of it achieving great results. They're also working on it publicly, in a non-time-limited manner here. I think we should all be supporting these efforts and working with the editor, providing feedback on the matters on which they bring to our attention, to achieve a great result. It would also alleviate your concerns at the TfD, so I'd have thought you'd also be championing these efforts. ProcrastinatingReader (talk) 13:39, 6 October 2020 (UTC)

A "merge discussion", just going by the name, could be about a merge but conversion into a wrapper is not a merge. And conversion into a wrapper doesn't even require TfD, although one could have one. TerraCyprus (talk) 16:13, 6 October 2020 (UTC)

Given that the most recent merge discussion closed as no consensus, it would be highly improper to convert to a wrapper without another discussion, especially since conversion to a wrapper was discussed in that discussion. You can't just bypass the system. That's heading into WP:FAIT area and, at best, would be disruptive. --AussieLegend (✉) 16:36, 6 October 2020 (UTC)

This is another discussion. Indeed, for the benefit of those who might not realise that, this sub section is headlined Wrapper - general discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:39, 6 October 2020 (UTC)

It's a limited discussion without any attempt to involve anyone else, including the Australian project. Because this has already been to TfD, any discussion about making this a wrapper needs to go back to TfD. --AussieLegend (✉) 16:54, 6 October 2020 (UTC)

It's obviously not going to be converted into a wrapper on the live template unilaterally and without discussion. He's just working on it in the sandbox, and discussing it here to address any issues to implement in the sandbox. It's wholly proper, even if it was a strong keep close, for an editor to work on this. Just as editors can discuss and work on various changes in sandboxes which end up not being implemented. Either there's communication fuzziness here (fair enough if it's just you being concerned that this will be unilaterally synced), or you're objecting to sandbox work (latter would be bizarre).

There is no prejudice against TfD renominations on no consensus closes, especially when the reason for lack of consensus is addressed. At the same time, converting a template into a wrapper (a reversible change) is routinely done via talk page discussions - TfD is not required for that, but a discussion certainly is, especially for high visibility templates. I think it is entirely proper if that discussion is held here. For maximum chance of success at TfD, for a merge discussion, it would of course be best to (a) ensure editors' concerns are addressed; (b) have agreement amongst editors that the sandbox version is ready. If your concerns are truly about functionality, I think this is a great opportunity to hash out issues here, without any 7-day time limit, and achieve a good wrapper. As the testcases show, we are not far off, generally speaking. ProcrastinatingReader (talk) 17:35, 6 October 2020 (UTC)

Perhaps you missed below where he said I think this has been done and the wrapper could go live. There has been a lot of discussion but nothing asking where all the issues are. --AussieLegend (✉) 17:53, 6 October 2020 (UTC)

Wrapper - general quality check and adoption path

• My comments: Testcases look good! Location on St Kilda (embedded) is a bit wonky. Frankly, all that 'location' stuff should be deleted as non-infobox material, but that's unlikely to raise consensus so the current implementation is best. The 'weather' stuff should be integrated more nicely into IS directly, rather than embedded in the way that it is. In the long term, for replacement of the wrapper, the embedded stuff would need to be split into a separate component (i.e. a template), as this material would be way too extraneous to have in local articles. I think rainfall etc would look nice in settlement infoboxes in general, especially with the ideas in mw:Streamlined Infoboxes (obviously not doing that right now, but just for mental imagery). ProcrastinatingReader (talk) 13:50, 6 October 2020 (UTC)

• My question would be, is the wrapper version better than the live version? Australia is the only place to have the infoboxes on articles about places look very different from the rest in English Wikipedia. So, if it is by itself more or less as good as the live version, it would have the benefit of consistency with all non-Australia articles about places. Per Frietjes we should focus on making the new version look as similar as possible to the old version. after that, we can discuss styling improvements - I think this has been done and the wrapper could go live. TerraCyprus (talk) 16:16, 6 October 2020 (UTC)

The wrapper is not better than the live version and conversion to an IS based wrapper was opposed at the most recent discussion. Changes so far seem to have been limited to just suburbs, towns etc. there are other purposes for which this infobox is used. I've looked at some of them with the wrapper version and it fails. It most certainly is not ready to go live. You need to remember that this infobox doesn't just do what IS does, it covers other types as well. I suggest that you thoroughly read the most recent merge discussion for more information. --AussieLegend (✉) 16:43, 6 October 2020 (UTC)

Do you have examples of articles where it fails, AussieLegend, so that they may be addressed? ProcrastinatingReader (talk) 17:44, 6 October 2020 (UTC)

I am opposed to converting this infobox because I don't see any benefit. If somebody wants to change the infobox, it's really up to them to find all of the problems. Asking questions is a good start but I'm not obliged to answer unless I see improvements. What I will say is that complying with Frietjes' suggestion is paramount to proceeding. --AussieLegend (✉) 17:56, 6 October 2020 (UTC)

Well, if the wrapper is bad you could make the case that it is bad on merits. It doesn't feel helpful to the progress of the wiki to block any kind of change, and refuse to provide any assistance (or even point editors in the right direction) when people try to address them. But it is your right, I suppose. Edit: Hold up... I just saw your above comment: but nothing asking where all the issues are??

I have created Template:Infobox_Australian_place/testcases#Types_of_places -- it has examples of each |type= of this infobox. Aside from my suggestions above, the only blocker I see is that IS needs to have proper mapframe support. Ideally also proper rainfall/weather support, but embedding is not a blocker. Other than that, I think this looks fine, per Frietjes's comments. I think it contains awful non-infobox material (e.g. the "See also" in an infobox?!), but I guess if it wasn't added some would say it's "missing functionality".

Protected areas should, as I mentioned in the TfD, move to {{Infobox protected area}}. The wrapper handles them fine, but it's not the right way of doing it. We need to move away from the idea that Australia can just create its own versions of templates of each wiki-wide place template, and instead see the areas as the type of area that they are, rather than the location they are in. The status quo is filled with egregious MOS:INFOBOXES violations, likely the greatest violation to several infobox principles of any highly transcluded template. ProcrastinatingReader (talk) 18:06, 6 October 2020 (UTC)

ProcrastinatingReader, what about protected areas can IS not handle? TerraCyprus (talk) 19:01, 6 October 2020 (UTC)

TerraCyprus, if you mean in the sense of merging {{Infobox protected area}} into {{Infobox settlement}} then I think it's just worth keeping it separate. IS can support it, but it seems more proper to follow the current style, unless there's consensus to change it. If you mean that this template's protected areas should be kept as IS, sure. But in terms of design, we generally want to keep the 'IUCN category' at the top (see testcase for protected area), not at the bottom. Also perhaps moving the "Nearest city" to the top of the embedded, and adding a bottom row divider to it, would be cleaner. Other than this, I think the wrapper addresses all functionality. It is not yet ready for a merge (i.e. replacement of instances), due to design elements and pending addition of mapframe/other params into the core of IS, but since that's hidden behind the wrapper it's irrelevant currently. Presently, the sandbox seems fit-for-use as a wrapper I think -- good work! ProcrastinatingReader (talk) 19:18, 6 October 2020 (UTC)

Aside from my suggestions above, the only blocker I see is that IS needs to have proper mapframe support. - That's not the only issue. a lot is to do with the way that data is presented.

it contains awful non-infobox material (e.g. the "See also" in an infobox?!) - That is protected area related. This is not the only infobox that uses this. I checked when I had to rewrite the Australian protected area infobox.

Protected areas should, as I mentioned in the TfD, move to {{Infobox protected area}}. - I direct you back to the merge discussion where I explained in detail why protected area were eventually incorporated into this infobox.

I think the wrapper addresses all functionality - It doesn't. There are reasons why this infobox does what it does and the wrapper doesn't do it properly.

We need to move away from the idea that Australia can just create its own versions of templates of each wiki-wide place template, - This sort of arrogance is why there is animosity when somebody suggests a merge or deletion without properly preparing yourself. You've been on Wikipedia for 5 minutes and you're dictating what should or shouldn't be done when you clearly have not bothered to research what has been done and why it was done. I realise that today's "coders" don't see the need to ask the end users what they want and what they need before throwing something together, but I've been programming for 45 years and I have always found it best to consult the end users, especially to ask questions like "why do you need it done that way?" and then try to comply with the answer, rather than force some piece of crap on them that only sort of did what they wanted. There have been valid reasons for everything that has been done to this infobox. --AussieLegend (✉) 17:17, 7 October 2020 (UTC)

AussieLegend, you do not get to refuse to elaborate on any of these points, whilst simultaneously saying There has been a lot of discussion but nothing asking where all the issues are. and simultaneously badgering me whilst I speak to other editors. All you have to do, to add merit to your claims, and be helpful at the same time, is send a link to the articles where it's broken. Very simple stuff.

Here you refer editors to: direct you back to the merge discussion. In the merge discussion you vaguely refer editors to read the archives. The same pattern goes on in all Australian place merge discussions going back a decade (eg). So where's the actual root discussion? Well, nobody knows.

In past merge discussions you've vigorously defended the right for Australian places to have their own infoboxes, with one vague reason or another. It doesn't take long to catch up when there's decades of archives sitting around. Why would any end user understand what is going on with the differences of Australian places? Why should they be fundamentally different to every single other city? Why is this understandable to readers, who are not especially familiar with the Australian WikiProject or the Template talk:Infobox Australian place archives, when reading Melbourne? The simple answer is: they shouldn't, and they aren't. And the wiki would be much better off with TerraCyprus's work.

Nobody denies that you are effective (I mean that in a nice way). But I guess that's why it's so worrying when an editor creates a working sandbox version; how does one vigorously, in a wishy-washy manner, say that a merge is technically infeasible when it's already been done?! I have faith in you -- you will figure it out :) ProcrastinatingReader (talk) 10:52, 9 October 2020 (UTC)

Please do not try to dictate what other editors can and cannot do. That's more arrogance and you do not have the authority. Nobody has been badgering you. As I have previously indicated, it's not up to me to identify the specific locations of problems. That's the job of the person trying to convert the infobox. Since you don't seem to get it, instead of expecting to be spoonfed, you should be proactively looking at the testcases and, as another editor suggested, try to make the wrapper look as close to the live infobox as possible. It does not at this time. Various differences exist and they should be obvious to even a blind man. --AussieLegend (✉) 18:08, 9 October 2020 (UTC)

Correct, it should look as close as possible to the rest of the live settlement articles. The wrapper achieves that, with great effectiveness. Absolutely no reason to try retain the rainbow colour scheme, or any of those 'features', and those differences are desirable. Aside from moving the protected place banner to the top, and some mild changes to the embedded stuff, wrapper seems fine from testcases. :) And since it seems fine to everyone else but you, but even you cannot make a specific objection to any part of it, I assume it is fine to you as well. :) -- support from me to implement after the two changes mentioned ProcrastinatingReader (talk) 18:52, 9 October 2020 (UTC)

Correct, it should look as close as possible to the rest of the live settlement articles - No, and that's a silly thing to say. Any IS based wrapper is going to look like IS. This one should look as much like Infobox Australian place and it certainly comes nowhere near that. As I've said, the presentation of the data is as it is for good reasons. Some of the presentation by the wrapper just looks ridiculous from an Australian point of view.

Absolutely no reason to try retain the rainbow colour scheme, or any of those 'features', and those differences are desirable. - In your opinion only.

wrapper seems fine from testcases. - Clearly it is not and if you would only compare what the wrapper presents to what this infobox presents, it should be blatantly obvious. If you can't see that, then maybe you shouldn't be a templateeditor. Instead of asking "what are the problems?" you should be asking "why does this infobox do this in that way?"

but even you cannot make a specific objection to any part of it - I can make lots of specific objections, but I shouldn't have to and I'm not required to. You should be able to see the problems for yourself if you could objectively compare the testcases. --AussieLegend (✉) 14:15, 10 October 2020 (UTC)

A comment on the sandbox and the testcases page: A quick perusal of the testcases page showed that parameters used in Module:Australian place map, and listed in the unknown parameter check as hints to the sandbox developer, were not yet supported in the sandbox. I have added two of them, but the sandbox and the testcases page need development in order to retain support for all of those parameters. – Jonesey95 (talk) 21:34, 9 October 2020 (UTC)

• Strong oppose - I strongly oppose these changes without obtaining consensus outside the users who inhabit this talk page. This sort of change by stealth is not how Wikipedia works. Deus et lex (talk) 12:15, 10 October 2020 (UTC)

  It is an Australian template. It would be expected Australian WikiProject editors watch this more than other folks. There are 65 page watchers - barely 'stealth'. Further, there's obviously no prejudice against external advertisement. ProcrastinatingReader (talk) 13:27, 10 October 2020 (UTC)

  This sort of change by stealth is not how Wikipedia works. - Indeed that is correct but ProcrastinatingReader doesn't seem to understand that. As I have said, it's almost heading into WP:FAIT territory. A wrapper was discussed in the recent merge discussion and there was no consensus for one. One editor even withdrew his support for a wrapper. Any changes have to be addressed in another discussion at WP:TFD. That this page has 65 watchers is pretty irrelevant. Some of those watchers may be inactive, others are not Australian, so any changes have to be considered in the correct venue and that shouldn't happen until the wrapper is fixed substantially. --AussieLegend (✉) 14:15, 10 October 2020 (UTC)

  Feel free to point out any PAG that states your interpretation of consensus, wrapper discussions, or of an Australian nationality requirement to voice an opinion on the wrapper. Aside from deletion discussions and certain permission requests, there is no requirement to hold discussions on any particular page. Changes to templates, including conversions to wrappers, are most regularly held on talk pages, like this one. :) ProcrastinatingReader (talk) 15:20, 10 October 2020 (UTC)

  As has already been explained to you, once a formal discussion at WP:TFD has happened, you have to go back to TFD to discuss changes inconsistent with the outcome of the discussion. It's exactly the same as when an article has been to WP:AFD and been kept, you can't prod the article if you still think it should be deleted. You have to go back to AFD. If you try to make this poor wrapper live without doing that we'll likely end up at an administrator noticeboard. --AussieLegend (✉) 15:45, 10 October 2020 (UTC)

  Feel free to point out any PAG... The outcome to merge was no consensus not keep, literally nothing is inconsistent with it. We're not proposing deletion/merge, someone is proposing a template change, same as adding a tracking category, changing or adding a field, or something else. I'm not personally going to implement anything, I just voiced my support on the talk page. As have others voiced their openness and procedural support, who are respected long-time template editors.

  And to jog your memory a little bit {{Infobox protected area of Australia}} was discussed twice at TfD [7][8]. Yet you unilaterally replaced it to avoid a proper merge to the proposed target. Are you saying that everyone else must go to a specific venue, not supported by PAGs, but you can do whatever you want? Whilst you're explaining the PAG support of your view of consensus, you may want to also reconcile this with WP:OWNERSHIP. :) ProcrastinatingReader (talk) 15:53, 10 October 2020 (UTC)

  We're not proposing deletion/merge, someone is proposing a template change, same as adding a tracking category, changing or adding a field, or something else. - Not at all the same. A wrapper was proposed at the discussion and rejected with, as I've pointed out, one editor even removing support for a wrapper.

  to jog your memory a little bit {{Infobox protected area of Australia}} was discussed twice at TfD [9][10]. - There's no need to jog my memory as I raised this at the recent merge discussion for this template.[11] It appears that you are the one needing a memory jog so let's ignore the fantasy and discuss what actually happened. The template was discussed in 2011 with the result being "no consensus". It was again discussed in 2013, again with an outcome of no consensus. I then opened a discussion at Template talk:Infobox protected area, suggesting that changes proposed in 2011 be implemented in {{Infobox protected area}} and it then replace Template:Infobox protected area of Australia.[12] Nearly 7 years later I still haven't had a response. I then set about rewriting Infobox protected area of Australia to provide a functional infobox without all the hacks that were needed with the previous version and that was used for a year. It was at that time that I realised a lot of functionality was common with this one and so it was merged into this one. I'm sure you'll agree that when there are several templates with almost the same functionality available in each one, it's better to consolidate them.

  Yet you unilaterally replaced it to avoid a proper merge to the proposed target. - As demonstrated, this allegation is baseless fantasy, offensive, and bordering on a personal attack. --AussieLegend (✉) 16:31, 11 October 2020 (UTC)

  The gaslighting here is incredible. There is no allegation of misconduct, just laying out the series of events which are incompatible with what you are saying here: that a TfD was closed as no consensus, and you merged the template unilaterally without going to TfD. It's only an allegation if you think it's misconduct. I'm convinced that you do not, and you don't think this is either, it's just grasping at straws. Anyway, this is just boring now, as I said above: I have faith in you -- you will figure it out :). Good luck! ProcrastinatingReader (talk) 23:33, 11 October 2020 (UTC)

  The gaslighting here is incredible. - That in itself is almost a personal attack. Your accusation was you unilaterally replaced it to avoid a proper merge to the proposed target. which is not true at all, as demonstrated in my last post.

  just laying out the series of events - Except that you didn't lay out what actually happened. Instead you presented a complete misinterpretation of what actually happened, presenting it as fact. --AussieLegend (✉) 12:39, 12 October 2020 (UTC)

  @Deus et lex: Strong oppose - I strongly oppose these changes without obtaining consensus outside the users who inhabit this talk page. - whom do you refer to by "the users who inhabit this talk page"? One of the standard procedures in WP is to discuss on talk pages, gain consensus there, and implement changes after said consensus has been reached. TerraCyprus (talk) 23:29, 11 October 2020 (UTC)

  • @TerraCyprus: - what I mean is that this page seems to be limited to a small number of users (some of whom have very strong views), yet this template (and its usage by Australian editors) is in far wider use. There's no attempt to more broadly seek consensus on this issue. Hope that makes sense. Deus et lex (talk) 08:51, 12 October 2020 (UTC)

Reducted font size

The converted farenhite temps are displayed is a small font size which goes against MOS:SMALL. Please change to normal font. MB 23:51, 21 November 2020 (UTC)

 Done. – Jonesey95 (talk) 00:30, 22 November 2020 (UTC)

TravelMate

http://www.travelmate.com.au/MapMaker/MapMaker.asp This is recommended for use for distance calculation between two locations. However this has been dead for some years. It is used in many places [13] many of which are talk pages where it is shown as being archived back in 2016. However TravelMate does not work in archived format so for all intents and purposes it is a dead link. I have flagged it as a dead link in a few locations I have encountered it in the last few days. It should at least be removed from documentation as recommended for use as a distance calculator.Fleet Lists (talk) 22:12, 12 February 2021 (UTC)

Why do we need special infobox for Australia? Also, if we need it, maybe we could consider having unified design with "infobox settlement"

Hi, I just wanted to ask, why do we need special infobox for places in Australia. I don't see any other countries getting their own infoboxes for cities, rather simply using template:Infobox settlement. I don't get why there's a need for a special infobox for cities in Australia if they could be represented by settlement infobox.

Also if we really need it, I wanted to propose unifying the design of the infobox with design of template:Infobox settlement, to make overall design on Wikipedia more unitary. Specially, that from that I see, Australian place template is the lonely example in case of infoboxes not falling into the same colour scheme and design form as other infoboxes. I propose making them look the same, while keeping special information that Australian template might contain and adding missing information from settlement infobox (like usage of flags, logos and coat of arms, etc.). TheEditMate (talk) 17:17, 18 February 2021 (UTC)

There are links to two discussions at the top of this page. – Jonesey95 (talk) 17:56, 18 February 2021 (UTC)

@TheEditMate: The sandbox has a version of the template with Infobox settlement's design that we could complete. Techie3 (talk) 02:34, 19 February 2021 (UTC)

This infobox is highly customised for Australia, with no extra, totally unnecessary fields that just have absolutely no relevance here. A lot of the terminology used in other countries, especially the US, has different meanings in Australia. For example, suburbs and localities are seen differently here, as is their perceived importance in geographical hierarchy. The sandbox version is horrible visually and does not take into account the differences between Australia and the US. This includes the layout, which assumes different priorities to those applicable to Australia. --AussieLegend (✉) 05:41, 19 February 2021 (UTC)

Sourcing information from Wikidata

At present, this template does not appear to track any fields from Wikidata. I wonder if it is time to start a conversation about the population data from the 2021 census. The 2016 census appears to have reported population using the same Bounded Locality (LOCB) boundaries as are used to delimit localities in enwiki, defined by state governments and mapped in OpenStreetMap. It seems likely that the 2021 and onwards census will use these same boundaries, making population figures more comparable in future than they have been in the past.

There are still town/locality articles using this infobox with either no population number, or one much older than the 2016 census, yet have a link to a wikidata item that has the 2016 population. Presumably when it becomes available, the 2021 population dataset will also be uploaded to Wikidata and matched to all of those items. Could we consider the infoboxes automatically picking up the 2021 population from Wikidata once it is available and automatically including it for any place types that have corresponding population figures, rather than requiring editors to manually add it (and the reference) as we have done fro 2016 population?

What do other editors think? --Scott Davis ^Talk 13:07, 26 February 2021 (UTC)

The idea has merit in principle, but the problem that has been found previously is that the ABS data for a place doesn't necessarily correspond with the actual place. Often, suburbs are combined so the data actually represents the population for more than one suburb. Even if we were to pull the data directly from Wikidata, someone would have to manually verify that the data was correct for that suburb. --AussieLegend (✉) 17:57, 2 March 2021 (UTC)

@AussieLegend: I recall that for the 2011 census (and presumably earlier). For 2016, anywhere I have noticed (almost all in SA, so not a national check) that the area shown in Quickstats for SSC has matched the area shown in in OSM for the locality boundary.

Tracking through the proposal for Australian Statistical Geography 2016 ID (P4093) at wikidata:Wikidata:Property_proposal/Australian_Statistical_Geography_2016_ID to the definitions: State Suburbs (SSCs): An ABS approximation of gazetted localities constructed from the allocation of one or more whole Mesh Blocks. Mesh Blocks are designed taking boundaries into account. LGAs have similar definition language to State Suburbs. Perhaps @99of9 has insight into whether this is expected to be stable going forward that 2016 population could be directly imported to Wikipedia infoboxes for LGAs, suburbs and towns, then switched to or augmented with 2021 data when available? --Scott Davis ^Talk 22:15, 2 March 2021 (UTC)

@ScottDavis: Yes, I agree they match much better now, and I am not aware of any that don't match. I'm also aware of *many* manually added references that are incorrect (often the ID has been copied from a previous census, so now refers to the wrong geographic area). You can find lots of examples in this category: Category:Australian_Statistical_Geography_Standard_2016_ID_different_from_Wikidata (not all pages in that category have errors, but many do). --99of9 (talk) 23:31, 2 March 2021 (UTC)

The "manual verification" User:AussieLegend speaks of is mainly to do with matching the right ID with the right item/article. Sometimes the hard thing to decide is about which statistical level of granularity we want to refer to. But all of that can be done just as easily on WD as on enwiki. --99of9 (talk) 23:44, 2 March 2021 (UTC)

Support, and willing to work on whatever is required to achieve this including pre-processing, validation and reconciliation with existing items/articles, and importing to Wikidata. It's got to be better than editing 16,000 articles to update the pop field (and the reference) and there's still dozens of 2006 values scattered around (1,348 transculsions of the Census 2006 AUS template)! There should be little need for manual verification: the concern about State Suburbs (SSCs) being combinations of gazetted localities or not aligning to boundaries was very valid for the 2011 census data but the 2016 ASGS aligned very closely to the actual boundaries. There are some cases where they don't, but ABS publishes correspondence ratios for all SSCs, and I can also use GIS software to detect any discrepancies whether it is in the SSC ID, the boundaries or other issues. ASGS Edition 3 will be released in mid-2021 (and ABS publish correspondence tables to previous editions, so this can be mapped to the 2016 SSC assignments from Mix 'n' Match).

Other concerns I can think of: the general concerns about vandalism (intentional or accidental) on Wikidata changing the values and not appearing on Wikipedia watchlists – I'm happy to validate the whole population dataset in Wikidata regularly (and share the code so others can do it), and this probably wouldn't get picked up if the value was changed in the infobox field anyway – in fact it is much easier to bulk validate in Wikidata that in Wikipedia. The other one is, if using QuickStatements for the import, I believe QS doesn't currently handle statement ranking? (I could be wrong). If so this might make it a bit difficult to retain the historical values but uprank the 2021 value to make sure it shows up in the infobox. --Canley (talk) 01:50, 3 March 2021 (UTC)

local_map_id

@Techie3, Jonesey95, TerraCyprus, Frietjes, AussieLegend, Galobtter, WOSlinker, Fayenatic london, Plastikspork, Pppery, and ScottDavis: In Template:Infobox Australian place/testcases, the only section that uses |local_map_id= is §NSW - town - Raymond Terrace, which sets the parameter to Q595259. Using Special:ExpandTemplates on this section and the help of User:PerfektesChaos/js/lintHint, I find that this parameter and value cause five lint errors, viz:

• Missing end tag </table>
• Table tag that should be deleted <table>
• Stripped tags </td>
• Stripped tags </tr>
• Stripped tags </table>

Setting the parameter to a value of Bogusmapid removes the lint errors. I don't know what is going on and what is being tested here. If there is something intentionally wrong with Q595259, I recommend inserting comment there saying something like, "causes lint errors; do not fix". I don't think this is the case, because the lint errors seem to be associated only with {{Infobox Australian place/sandbox}}. If Q595259 is supposed to work properly, and the lint errors are associated only with the sandbox version, then no comment here, but the sandbox should be fixed to make the 5 lint errors go away, whether or not the sandbox displays as intended. Either that, or delete the sandbox altogether, so that Template:Infobox Australian place/testcases won't be the only template listed at Lint errors: Table tag that should be deleted in the template namespace. —Anomalocaris (talk) 22:01, 16 March 2021 (UTC)

Anomalocaris, the problem is with using {{Infobox|child=yes|...}} with |module= from {{Infobox settlement}}. If you check the code for {{Infobox settlement}} you will see that the "module" is wrapped inside of a table, but {{Infobox|child=yes|...}} doesn't generate an entire table, only the table rows. To see this, try {{Infobox|child=yes|data2={{Infobox mapframe|zoom=|id=Q595259}}}} in Special:ExpandTemplates and for a complete example, you can try {{Infobox settlement|module={{Infobox|child=yes|data2={{Infobox mapframe|zoom=|id=Q595259}}}}}}. Note that there is special code in Module:Infobox to fix these child boxes, it only works if they are passed directly, and not wrapped inside of another table. For now, I will switch the sandbox to use |subbox=yes instead of |child=yes since the former generates a well-formed table. Thanks! Plastikspork _―Œ^(talk) 22:40, 16 March 2021 (UTC)

I haven't looked into the details of this one, so this could be bad advice in this case, but when I find that the sandbox version of a template is causing errors and it hasn't been edited in a while, I just copy the live version of the template into the sandbox with an edit summary like "sync with live template". I can't think of a time when that action has been reverted or objected to. If the sandbox is in active development, I usually move on to some other page among the millions with Linter errors. – Jonesey95 (talk) 03:22, 17 March 2021 (UTC)

Can an alt name parameter be added?

Many Australian places now have a local Aboriginal name assigned to them, and I think it would be helpful to be able to include these in the infobox. There may be other instances where an alternative name may be appropriate too. Laterthanyouthink (talk) 06:38, 21 November 2020 (UTC)

Yeah I wanted to add that to the template but it was locked. The parameter should be nativename. Or if it’s a Chinatown, a Chinese name. — Preceding unsigned comment added by 49.180.73.243 (talk) 05:15, 25 April 2021 (UTC)

Image_upright doesn't work

When I inserted |image_upright = 0.8 in the infobox coding at Serviceton, the size of the infobox image remained unchanged. Same with |upright = 0.9. I then inserted |image_size =200px, which worked, but resulted in the appearance of "Preview warning: Page using Template:Infobox Australian place with unknown parameter "image_size"".

For information, and hopefully fixing. Cheers, SCHolar44 (talk) 11:55, 26 August 2021 (UTC)

Work for me. Setting |image_upright=0.8 it's now at 180px by 180px. -- Michael Bednarek (talk) 14:30, 26 August 2021 (UTC)

Just noting that logos belong in the |logo= field which, by default, also sets a default of |logo_upright=0.8. This field is normally only for LGAs but Serviceton is a special case. As a special note, it's also discussed in an interesting YouTube video titled The Border Mistake That Created a Disputed Territory. --AussieLegend (✉) 15:59, 26 August 2021 (UTC)

Template-protected edit request on 4 October 2021

Change "label27 = Federal Division(s)" to "label27 = Federal division(s)" because Wikipedia headings are supposed to be written in sentence-case. Woko Sapien (talk) 20:17, 4 October 2021 (UTC)

To editor Woko Sapien:  done, and be sure to purge any page where the uppercase "D" still appears. P.I. Ellsworth - ed. ^put'r there 23:55, 4 October 2021 (UTC)

Indigenous Nations/Language Groups

See discussion at Wikipedia:Australian_Wikipedians'_notice_board#Places_Infobox_and_Indigenous_Nations/Language_Groups. Mitch Ames (talk) 09:33, 19 December 2021 (UTC)

Country name in infobox?

Hallo, I was stub-sorting Kamarooka, Victoria , and adding some geog context to its lead, I realised that the infobox didn't tell the reader what country it's in. Yes, it says "Victoria", but that requires the international reader to recognise the name of the state as being part of Australia. I checked a place in England and one in the USA, and both of these give the country in the infobox. I suggest that the reader would be better served if this infobox displayed "Country: Australia". PamD 09:04, 27 January 2022 (UTC)

Checking a few more random places round the world: country is displayed in infobox for Casablanca, Jasper, Alberta, Ooty. Australia seems to be an exception here. PamD 09:07, 27 January 2022 (UTC)

This has been raised before; the last time, I think in 2017, and I didn't then understand the reasons for not doing it. Since then, short descriptions have marched forward, and they do display "Australia". I'm not sure that's enough. -- Michael Bednarek (talk) 11:18, 27 January 2022 (UTC)

It was raised previously and I added the country, but it was removed after quite a bit of opposition. --AussieLegend (✉) — Preceding undated comment added 14:08, 27 January 2022 (UTC)

• Searching the archive I find Template_talk:Infobox_Australian_place/Archive_6#Include_"Country"_field? Brief discussion I started in 2011 (I've been sorting stubs for a long time) and Template_talk:Infobox_Australian_place/Archive_8#Country another discussion in 2017. PamD 08:16, 28 January 2022 (UTC)

  I can see that it is probably redundant where the state is Western Australia or South Australia, which would be an argument against including it hardwired, but for other states it's a useful addition. PamD 08:18, 28 January 2022 (UTC)

Removing Map from Page Image

https://phabricator.wikimedia.org/T301588 recently allowed editors to add the parameter "class=notpageimage" to an image to prevent it from being used as the page preview image. In Perth, for example, the map generated by this template has taken precedence over the nice skyline image as the page preview image, and I am unable to add the parameter to the map on the article itself. For this reason, I am requesting that the paramenter "class=notpageimage" be added automatically to the maps generated by this template. Alternatively, if one still wants to allow maps as the page preview, (e.g. for small places with no other images), a parameter should added to the template that adds the notpageimage parameter to the map, so that this can be done by choice on articles where that is deemed necessary. Toadspike (talk) 23:39, 19 February 2022 (UTC)

This is a change that needed to be implemented at Module:Location map; I've gone ahead and changed that module. Elli (talk | contribs) 02:54, 20 February 2022 (UTC)

Traditional custodians?

I don't want to edit the page myself given the notice at the top, but this is a request for a traditional custodians/aboriginal country/ aboriginal language group or another preffered title be added as an optional section to Australian place infoboxes. — Preceding unsigned comment added by Notcharizard (talk • contribs) 05:33, 3 April 2022 (UTC) -- ☽☆ NotCharizard (talk) 05:35, 3 April 2022 (UTC)

A similar previous discussion - with no apparent outcome - is at Wikipedia:Australian Wikipedians' notice board/Archive 59 § Places Infobox and Indigenous Nations/Language Groups. Mitch Ames (talk) 06:02, 3 April 2022 (UTC)

Nearest neighbours

The template includes parameters near-n etc for "nearest neighbour". It appears that if type = suburb the infobox displays "Suburbs around suburb_name". (I presume that this applies to other types ("city" etc), but haven't checked. I'll refer to suburbs here, but it could probably be generalised to towns, LGAs etc.) However not all suburbs are completely surrounded by other suburbs - suburbs on the coast, for example, have an ocean on one side, not a suburb. So when using this infobox, an editor might put:

• Nothing at all, because there is no suburb
• The name of the ocean (which is not a suburb)
• The name of the ocean, in italics (so that the reader won't read it literally, although such usage is not covered by MOS:ITALICS)

In some cases the editor might put the name of a river or bridge (possibly in italics or brackets) - example Bowen Bridge to the NW of Risdon - although I suspect that is probably wrong. What should be listed is the suburb on the other side of the river or bridge, because the infobox displays "Suburbs around ...".

Some guidance in the template documentation - or change to the infobox - to achieve consistent usage would good. (For background on what prompted this, see User talk:Mitch Ames#says who?. You can probably safely skip the discussion prior to the first outdent, and my post of 11:40, 17 March 2022 (UTC).) Suggestions:

• Documentation should say "nearest neighbour of the same type, else leave blank". This most accurately reflects what the infobox displays, including nothing if there is no suburb to the east of this one.
• Document should say "nearest neighbour - in brackets if not of the same type, eg ocean next to suburb". (I prefer brackets to italics, so as not to overload the existing usage of italics, but concede that italics might be more common current use.)
• Change the infobox to display "places around ..." instead of "suburbs around ...". Allows for differing types, but personally I don't like this because "places" is to vague.

Mitch Ames (talk) 05:24, 19 March 2022 (UTC)

@Mitch Ames: In my opinion, those fields ought to have accurate and complete information about the nearest suburb, or suburbs, in that direction WITHIN the current town or conurbation.

If for all intents and purposes there isn’t a suburb in that direction, then it ought to say WHY. While neighbouring suburbs don’t need to share boundaries, the purpose of these fields is to facilitate easy navigation between suburbs and stopping at rivers and lakes and so on just because they aren’t in a suburb or aren’t a suburb in their own right is not helpful but, rather, narrow-minded. And the facts are that it isn’t consistent. For example, East Perth includes part of the Swan River including Heirisson Island, but Victoria Park ends at Swan River; i.e., the two don’t share a boundary. In contrast, Wilson and Ferndale do share a boundary that runs (at least in places … I didn’t check the whole boundary) in the Canning River, placing the Canning River within both suburbs, but I’d still want to know that the two are separated by the Canning River. The editor needs to be given the freedom to do the right thing for that situation by following the direction “break the rules if you must, but break them beautifully!”

So … if the current and nearest suburbs are separated, facilitate navigation to that nearest suburb(s) in that direction but also say that the two are separated by a feature and identify that feature. For example: the nearest suburb north of Shelley is Waterford across the Canning River. Now that is being helpful! Follow normal typographic conventions established over the past 700 years for communicating that clearly, accurately, concisely, easily, and unambiguously … perhaps by saying “Waterford (across Canning River)”.

If the town or conurbation ends, then leave it blank unless you know what the thing is called that is where the next suburb would be: for example, there is no suburb west of Scarborough … because Perth ends at the Indian Ocean (and saying Indian Ocean ought to be enough, especially when linking to the Wikipedia article for the ocean). Similarly, west of Naval Base is Garden Island, and west of Garden Island is the Indian Ocean, and west of Cottesloe is Rottnest, and west of that is the Indian Ocean. That is being informative and helpful to the reader (for whom we are ALL writing … to … be … read), so that must be the overarching goal of those fields. Betterkeks (talk) 09:56, 21 March 2022 (UTC)

I think there is some confusion here about "type = suburb"; we use this type in this infobox for both suburbs and localities, which are all bounded. By design, all suburbs/localities on the Australian mainland have neighbours (that is, share land boundaries) and that it is only when you reach the ocean that there may be boundaries not shared with another suburb/localities. If you aren't seeing these shared suburbs/localities boundaries, then you are not using the right map. Most state governments have some kind of online mapping service where you should be able to see them. There should not be any spot on the Australian mainland which is not in one suburb/locality (or on the shared borders between two or more). Suburb/locality boundaries are fixed and relatively stable (mostly the changes are due to suburb spread around cities, where one large rural locality gradually has suburb-sized chunks excised from it). So, we don't have to make a decision on what to put for the land-based neighbours; it is already decided for us; we just copy it off the official map. We only need to decide what to do when we hit the ocean (in the absence of a shared boundary with an island or island group locality). I am in favour of always putting something in each neighbour box, because if you leave it empty, it isn't obvious to the reader what that means. There is nothing there? Or someone hasn't bothered to fill in it? So I always put Coral Sea or (whatever waterbody is appropriate) in italics (which is what MOS:EMPHASIS suggests for indicating a contrast to alert the reader this isn't another suburb/locality name). The only choice here might be whether you use a bay or a sea or an ocean name (if you have more than one to pick from). Kerry (talk) 05:54, 30 March 2022 (UTC)

With rivers, I never put them in the neighbour fields in the infobox, but rather I talk about them in the geography section as boundaries, where I identify any significant natural or man-made feature (typically watercourses, ridgelines, major roads) that form a significant oart of the suburb/locality's boundary (sometimes with the word "loosely" when the feature is clearly influencing the boundary but with some minor deviation). E.g. "Smallplace is bounded to the north by the Big Highway and to the east loosely by the ridgeline of the Impressive Mountain Range". I find that a better way to address the presence of a physical boundary between suburbs/localities (more than just a line drawn on a map which most of them are). Kerry (talk) 06:13, 30 March 2022 (UTC)

It's important to bear in mind that the infobox is a simple structure and that not every fact about boundaries can be represented there, and that we have the whole article to explain stuff in more detail. But it's a good idea to be consistent so anyone looking at the infoboxes for a number of places can make the same assumptions as to what that neighbour information represents. Sometimes I omit the neighbours entirely (as a group, never individually); I do this when there is a very big locality which has many neighbours and instead explain the situation in the Geography section (e.g Wooroonooran which has over 20 neighbours). While you can squeeze 2 neighbours into each of the "directions", it really starts to be messy when you trying to squeeze 3 or more in; that's usually the point when I omit all neighbours thing from the infobox. So these are pragmatic choices you need to make: if I include the neighbours in the infobox, will that help the reader or be such a mess it will likely confuse the reader? Is there a better way to explain it to the reader in text? Kerry (talk) 06:26, 30 March 2022 (UTC)

in italics (which is what MOS:EMPHASIS suggests for indicating a contrast to alert the reader this isn't another suburb/locality name) — I disagree with that interpretation of MOS:EMPHASIS, which says (with my emphasis here) "to stress a contrast". I don't think we need to stress the contrast between (for example) a suburb and a body of water. Nor are we trying to "draw attention" to the not-suburb, nor make "the point or thrust of the sentence". What we are trying to do is indicate that the text denotes something that is not actually what its place (in a table of "Suburbs around X") claims it to be (a suburb).

We could use italics to denote "not actually a suburb at all", but I still think it is overloading the possible interpretations of italics.

Perhaps we should say "(none)" or "n/a" or "--", if there is no suburb there - so it's clear that it's not an accidental omission. (Admittedly they don't indicate why, but at least they are correct.)

I still prefer either leaving the entry blank (there is literally no suburb on that side) or changing the table heading to be more generic (perhaps just "Surrounds"), so that the table is literally accurate. Mitch Ames (talk) 13:35, 30 March 2022 (UTC)

I think the risk with "Surrounds" is that it such vague term that it might invite a range of content from the irregular contributor, e.g. a national park, a caravan park they run, or whatever in the mind of the contributor might be in the "surrounding area". I think "locality" would be the more general term as "suburb" is a urban locality, but I'm not overly worried either way. We've used the nomenclature of suburb for many years now and I have not been aware of anyone misunderstanding this part of the infobox. Similarly emphasis has been used in many infoboxes for years without attracting any adverse comment in terms of reader misunderstanding. Generally it's the name of an ocean, a sea or a large bay with a name that suggests it is a waterbody and has a clickable link to its article that will spell out in more detail. Look at Fremantle (suburb) as an example of this. What else is a reader likely to think with Indian Ocean in the NW, W, and SW slots other than there's an ocean in that direction? I note that the neighbours don't appear for any "type" that isn't bounded, so the neighbours don't apply to towns which aren't bounded, but do apply to LGAs (which are bounded). Again, City of Fremantle illustrates the use of the italicised link to Indian Ocean as the LGA neighbours to the NW, W, and SW. Kerry (talk) 11:30, 6 April 2022 (UTC)

Native name

Hi there, for design consistency and inclusion of important details can we please have the Native Name module that is available on Infobox: settlement? For example see https://en.wikipedia.org/wiki/Tasmania https://en.wikipedia.org/wiki/Saint_Petersburg https://en.wikipedia.org/wiki/Beijing Poketama (talk) 16:46, 23 April 2022 (UTC)

 Done User:GKFX^talk 00:46, 2 May 2022 (UTC)

Hi thankyou for your help. I have three more requests on this subject.

1. At current the documentation needs to be updated on the this template page to add 'native_name'. This can be copied from Infobox settlement.
2. The module functions but does not appear when typing in the editor as a suggested module, and so must be typed in manually (not sure if this is normal behaviour).
3. The native name is displayed below the State name which is confusing as shown on: Melbourne. Can this please be changed to show the native name below the English name (as seen on https://en.wikipedia.org/wiki/Beijing)

Poketama (talk) 04:34, 4 May 2022 (UTC)

Note: Your first request about updating the documentation is something you can do yourself, as the documentation is purposely on a different page (See here). As for the other 2, i have no comment as im not a TE. Aidan9382 _(talk) 10:31, 6 May 2022 (UTC)

Thanks for that I fixed it up. Poketama (talk) 08:43, 9 May 2022 (UTC)

Number 3 seems to have been done by User:GKFX this morning. Please explain more about number 2 - what do you mean by suggested module? &::mdash; Martin (MSGJ · talk) 19:57, 8 May 2022 (UTC)

@MSGJ @Poketama – do you mean TemplateData for number 2? That is the data source for VisualEditor and the 2017 wikitext editor, which are the only tools I am aware of which suggest template parameters. If so I did that in Special:Diff/1084365014/1086709882, along with the normal documentation. User:GKFX^talk 20:22, 8 May 2022 (UTC)

Thankyou everything is working now and looks fantastic! Poketama (talk) 08:23, 9 May 2022 (UTC)

Display all parameters for all types

It would be very useful if this template didn't restrict which parameters are displayed for each "type". I generally am not editing cities/towns, administrative divisions or IUCN protected areas, so I often end up having to mess around just a little bit with the type or with the way I'm using a parameter in order to get it to show the key points for that place. For example - I would consider native title to be protected regions, and population would be a reasonable measure there. The net of what's allowed when also makes the template code just that bit more inaccessible to read, increases risk of errors, and makes it harder to maintain accurate documentation. --Xurizuri (talk) 15:51, 3 June 2022 (UTC)

Indigenous name - display format

Currently the native_name is displayed in the infobox, but there's nothing to indicate that it is an Indigenous name (as opposed to a suburb, region, etc), even when native_name_lang is set. Example: Albany, Western Australia. (As a Western Australian, familiar with Albany, I know that in this case Kinjarling is not going to be a suburb or region, but that's not true in the general case.) I suggest that the native name should indicated somehow, either in italics or - probably better - prefixed with the language name, eg as {{lang-nys}} does, in the lead sentence of that article. Mitch Ames (talk) 02:03, 4 June 2022 (UTC)

2021 census SAL populations uploading to Wikidata

Those of you who frequent this template page may be interested to know that since we matched the ABS SSC/SAL codes to Wikidata/Wikipedia items last time, it will be fairly fast to get the populations into the right places on Wikidata this time. They are uploading as a batch now. For an example of how they will appear, see wikidata:Q50809626#P1082. --99of9 (talk) 11:57, 28 June 2022 (UTC)

Just out of curiosity, is there any way the infobox in a location article could automatically display the updated Wikidata Census information, similar to how {{Template:Official website}} draws its information automatically from Wikidata? It would eliminate the need for manual updating each location in Australia. Some of them are quite a few census out of date. Calistemon (talk) 12:10, 28 June 2022 (UTC)

@Calistemon We've just finished making such a thing! We've been working on a Lua module (with Samwilson, 99of9, Canley and Tenniscourtisland). This afternoon we added the module to the Infobox Australia place template, so now if the pop field is empty (or not there) then the module looks for a population value from the linked Wikidata item. We've built in a whole lot of filters so it chooses the most appropriate population figure (and most recent). Check out our documentation here (still a work in progress). And here's a list of all the articles that are now getting their Infobox population figures from Wikidata.

We'll start a new section on this page to talk about the module shortly. MaiaCWilliams (talk) 12:57, 29 June 2022 (UTC)

I just tried it at Rockingham, Western Australia, updated the Wikidata item and then removed the 2016 data from the infobox. Now it is displaying the 2021 value. Fantastic work! Calistemon (talk) 13:28, 29 June 2022 (UTC)

Oh great! I'm so glad it worked for you. Samwilson has started gathering some stats on a project page so we can track the changes in the number of articles with population values and how many are getting that population from Wikidata. The page is here, if you're interested. MaiaCWilliams (talk) 13:46, 29 June 2022 (UTC)

Replace parameter 'local_map_id' with 'wikidata'

I'd like to suggest this change to deprecate |local_map_id= and replace it with the more general-purpose |wikidata=. The former is for the Wikidata item to use to display a slippy map, and the latter is for the new population lookup. I can't think of a reason to use two different Wikidata items within the same infobox; it'd just be confusing. It's something of a convention for templates that use Wikidata data to have a parameter that allows overriding (by default they use whatever item is linked to the page). — Sam Wilson 08:01, 1 July 2022 (UTC)

Significance of Location in Template

Although useful, what is the significance of adding the distance to a City or Town under the Location fields? Would it make more sense to mark a distance to reflect if its under a particular metropolitan or regional area or perhaps identify its placing within the ABS Remoteness Structure? Sdinesh2222 (talk) 10:57, 21 August 2022 (UTC)

Non-numeric values for pop and pop2 (population data)

In the 2021 census, not all population counts are numeric. Probably for privacy reasons, they are reluctant to provide data for places with little or no population, describing it as "No information can be provided because the area selected had no people or a very low population in the 2021 Census.", for example [14]. So I went to put "no or low population" in the "pop" field for that locality article and of course it does a dummy spit when it tries to calculate the density because the value in "pop" is not numeric. However, that is the value provided by the ABS so we need to accommodate it. I can see two approaches:

1. allow non-numeric values in the "pop" field but make the code that calculates the density smarter to not calculate it when non-numeric data is present
2. have an alternative field (say) "pop-text" which is used for non-numeric data and display pop or pop-text (whichever is provided) and density is calculated only if there is a value in "pop". Note a "pop2-text" would also be needed.

Your thoughts? Kerry (talk) 01:56, 6 February 2023 (UTC)

I have made this change to the sandbox, which is supposed to test whether |pop= contains a number. If it does, the density calculation proceeds. If it does not, density is not displayed. I checked the testcases page (see the box for Garrawalt there), and I don't think I broke anything. – Jonesey95 (talk) 04:47, 6 February 2023 (UTC)

It looks good. There is a potential issue with Module:PopulationFromWikidata) which extracts the census population from Wikidata in the first place (when the pop field are left blank), as that module returns the numeric 2016 data rather than the non-numeric 2021 data. But I guess those who built/maintain the module are best placed to figure this out. And the number of places with these low populations are probably not so frequent that it's probably viable to do them manually if the Module won't return non-numerics. Thanks! Kerry (talk) 05:43, 6 February 2023 (UTC)

In a similar vein I've just tried to use <pop> and <pop2> at Rottnest Island, however I can't get <pop2> to trigger - is <pop2> unavailable if <pop> is left blank to trigger the autofeed from Wikidata? ITBF (talk) 15:26, 12 March 2023 (UTC)

Yes, |pop2= is displayed only if |pop= has a value. If |pop= is empty, the population is retrieved from Wikidata. Some different logic in the code could probably make pop2 work independently. – Jonesey95 (talk) 16:05, 13 March 2023 (UTC)

No mention Australia in the infobox

I would suggest making it clear in the infobox that it is about a place in Australia. Perhaps not needed by some readers but not at all obvious to those not already familiar with places in Australia. Gab4gab (talk) 16:14, 22 May 2023 (UTC)

Wikidata error

Hundred of Evan, New South Wales is showing "Lua error in Module:PopulationFromWikidata at line 150: attempt to index field 'claims' (a nil value).". That is because a dumb bot just created Evan (Q119285824) which caused Module:PopulationFromWikidata to insert junk. Writing code that interfaces with the anything-goes Wikidata is difficult and susceptible to hard-to-find vandalism so I'm sympathetic but am reporting here per "Please report any feedback". Would someone please investigate how to deal with this and perhaps ask if Module:PopulationFromWikidata can be fixed to check return values. Johnuniq (talk) 23:04, 10 June 2023 (UTC)

The error appeared because the Wikidata item created by the bot (Evan (Q119285824)) was completely blank, so I added some claims. --Canley (talk) 00:19, 11 June 2023 (UTC)

Native name parameter

The "Native name" parameter is used differently here then it's original intent. Native in the original case is not related to being indigenous it's related to the local language.... that in Australia's case may be indigenous in nature... but this parameter is mislabeled in its usage according to the usage across Wikipedia....like Template:Infobox country or Template:Infobox settlement. Moxy- 02:33, 29 January 2023 (UTC)

Related discussion (presumed to be what triggered this section): Template_talk:Infobox_river#native_name_title. Mitch Ames (talk) 03:15, 29 January 2023 (UTC)

 Fixed Moxy- 17:03, 1 February 2023 (UTC)

What exactly has been "fixed"? ({{Infobox Australian place}} has not changed.) Mitch Ames (talk) 02:24, 2 February 2023 (UTC)

Please don't change that again. I've reverted it now. We spent many months hashing this out in the Australian Wikipedian community on many different talk pages and had a massive RFC about it. It was a big hassle. Poketama (talk) 18:56, 3 July 2023 (UTC)

Strange census behaviour on Gootchie, Queensland

Having deleted the 2016 census population from the infobox of Gootchie, Queensland, I was expecting the 2021 census data to magically appear with a 2021 census citation, but it didn't. Instead, the 2016 census data appeared with not one but two 2016 census citations, identical except one had an access date and the other didn't. My first thought was that there wasn't any 2021 census data for Gootchie, but yes there is 2021 data according to Quickstats. Then I thought maybe somehow that 2021 data hadn't got into Wikidata, but yes it has and both 2016 and 2021 census URLs are in the wikidata. BUT the odd thing here is that the population in 2016 and 2021 is the same (both 96 says the ABS). So in Wikidata, Gootchie has one population value (96) with two "points in time" and 2 citations. Now, information-wise, this is correct. But my suspicion is that the module is NOT expecting this, but is expecting to see two values, each with a different "point in time" and citation as it does when the population is different (e.g. see Goomeribong, Queensland where I just removed the population data from its infobox and everything worked as expected). So I think we have a bug, either in the uploading of the 2021 census into Wikidata (when the value is the same as the previous one) OR in this module by not expecting the value to be shared between 2 censuses. Kerry (talk) 00:42, 13 September 2023 (UTC)

I have come across this many times on WA location articles, usually in cases were the population is 0 in both the 2016 and 2021 census. I don't have an answer as to why it does this but I can confirm that Gootchie, Queensland is not unique in this. Banksiadale, Western Australia is another example. Calistemon (talk) 01:26, 13 September 2023 (UTC)

(ec) Looking at the Wikidata entries for Gootchie (d:Q55453404) and Goomeribong (d:Q55453394), I notice that Gootchie has one population entry with 2 data sets, and Goomeribong has two population entries with one data set each. How to fix that, if it's possible, is above my pay grade. -- Michael Bednarek (talk) 01:30, 13 September 2023 (UTC)

@Michael Bednarek: Fixing it is basically a manual process of creating the other entry and adding all the relevant qualifiers and references, and then removing them from the first doubled-up entry. Although, it sounds like there are rather a lot of these, so it might be better of being done via QuickStatements. :) Sam Wilson 01:42, 13 September 2023 (UTC)

It looks like the issue was that there was a single population value with two 'point in time' qualifiers. This should be modeled as two separate statements, and it looks like @Canley has already updated it to such a structure. Other errors like this need similar fixes. Sam Wilson 01:34, 13 September 2023 (UTC)

I have written a query to detect these cases where the population is the same and the statements are merged: https://w.wiki/7SqG – 805 cases so will probably need to be fixed with a QuickStatements script. --Canley (talk) 01:38, 13 September 2023 (UTC)

...although QuickStatements originally caused this, so I wonder if there is a way to force QS to create a new statement rather than "helpfully" merging where the triple is the same. I will look into it and do some tests. --Canley (talk) 01:58, 13 September 2023 (UTC)

Looks like this is a known limitation of QuickStatements:

QuickStatements version 2 currently cannot:

• add a second statement with the same property and value but with different qualifiers, since additional qualifiers will be added to the first statement

--Canley (talk) 11:57, 13 September 2023 (UTC)

OK, I've done some testing and experiments and the only way I can find to automate the separation of these merged statements is to create a new Wikidata item containing the 2021 population, then merge the new item with the original item, as this does not merge the claims/statements even if the property and value is the same (as long as there is something different like the reference, the point in time, or the determination method). Only issue was that sometimes doing a MERGE in QuickStatements does not redirect the new item, and it's also a bit "wasteful" of Q-numbers but maybe 805 out of 105,000,000 is not too bad. I will also look at the Wikidata REST API and see if it's possible using that. --Canley (talk) 02:02, 15 September 2023 (UTC)

Template-protected edit request on 30 September 2023

Please change "{{{area|}}}|R}}|km2|sqmi}}}}}} {{{density_footnotes|}}}" to "{{{area|}}}|R}}|km2|sqmi}}}}}}{{{density_footnotes|}}}" (delete a space, per MOS:CITEPUNCT). —DocWatson42 (talk) 11:11, 30 September 2023 (UTC)

 Not done for now: Unfortunately, the template's documentation says "Best when used with <ref>...</ref> tags and a citation template". See Adelaide for an example where this change would result in poor formatting.

If you want this change to happen, you'll need to modify the documentation to require ref tags or their equivalent (e.g. {{efn}}), then fix all of the existing instances. Luckily, there are not that many. You can find links to them in the TemplateData section of the documentation. – Jonesey95 (talk) 13:59, 30 September 2023 (UTC)

Protected areas with multiple IUCN categories

Is there any way to allow the template to display multiple IUCN categories? In case of the Jurien Bay Marine Park, it is sub-divided into areas with multiple uses, being Ia, II and VI (see reference), with II being majority of the area of the marine park. Calistemon (talk) 03:19, 11 October 2023 (UTC)