Template talk:Infobox settlement/Archive 34
| This is an archive of past discussions about Template:Infobox settlement. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 30 | ← | Archive 32 | Archive 33 | Archive 34 |
Seat field
Should not the fields 'seat' and 'seat_type' sit under the government heading, rather than just above it? Dgp4004 (talk) 08:48, 29 May 2025 (UTC)
Auto population density
Perhaps a dumb question, but why does "auto" never work when I put it into infobox settlement templates? Criticalthinker (talk) 19:03, 17 June 2025 (UTC)
- Make sure to use the correct and matching parameters in the template, example below:
{{Infobox settlement |area_total_km2 = 1 |population_total = 1 |population_density_km2 = auto |area_rural_km2 = 2 |population_rural = 4 |population_density_rural_km2 = auto }}
- gives
| ||||||||||||||||||
enable mapframe wherever pushpin_map is specified, but no other map
So, currently we have mapframe enabled wherever no map is specified. The rollout went fairly well, we patched up various syntax errors, and I've seen zero reader complaints about having the mapframe enabled.
Because the pushpin maps are generally used to give a more general overview (small dot in a large area), while the mapframes by default zoom in at coordinate type level, it would make sense to try showing both.
We'd continue to skip mapframe by default if any sort of image map is specified.
I suspect we'd have to deal with a smattering of new syntax errors, but beyond that, the readers would be by and large happier to have this. --Joy (talk) 10:40, 17 June 2025 (UTC)
- Sounds good, but may want to check whether users are already adding mapframe maps manually either by placing
{{infobox mapframe}}<mapframe>code via the|image_map(which you mention),|moduleor indeed any other parameters. An insource search should find examples. Regs, The Equalizer (talk) 00:14, 18 June 2025 (UTC)
- This may be a bad idea. Infoboxes are often used on very short pages. Having a second map automatically appear can push other infobox information below the bottom of the article content, which makes the layout look bad and may lead to readers ignoring the information. We should be careful about infobox length bloat. — hike395 (talk) 03:40, 18 June 2025 (UTC)
- Any infobox content, such as a picture or a map, next to a short stub is going to make the layout look imbalanced. That is the nature of having a very small amount of content, surely?
- We're not going to affect the general concept of stub content being short by adding generally helpful information to the infoboxes. These things will remain orthogonal.
- Who are these readers who depend on information in an infobox, but can't figure out when there's a need for vertical scrolling to see more? Which part of the internet teaches them not to scroll? Honest question, because we seem to be neck deep in scrolling these days :)
- I tried to come up with an example for what you seem to be describing, so I skimmed randomly through Wales geography stubs for a while, but the best I could find was Gendros - where someone added a map manually near the bottom. D'oh.
- So I gave up on that method and tried a search like incategory:"United Kingdom geography stubs" hastemplate:"Infobox settlement" and that quickly found Walton (grounds).
- On my desktop browser, that infobox at Walton grounds gets cut off at "Region" already. Not sure how an extra map would change anything substantial here, it would just get cut off at a different visual element, but it would be equally as obvious that you have to scroll down to see more.
- I checked the same stub on my mobile browser, and most of the screen was taken up by Wiki Loves Earth already :) and the infobox only showed the title. Still, that was enough to visually indicate that there's a box there and scrolling would show more. When I pressed the (X) on the banner, it rendered up to half the existing map. It was likewise pretty obvious you have to scroll down.
- Coming back to the example of Gendros, my mobile browser, without the top banner, showed the infobox down to "Post town". After the box, there was a paragraph, and then the map, and then another bit of content. Based on that, I don't quite see what would be the downside of integrating that map into the infobox there, either.
- So I'm at a loss as to what the actual concern is here. Could you please elaborate? --Joy (talk) 15:02, 18 June 2025 (UTC)
- This may be a bad idea. Infoboxes are often used on very short pages. Having a second map automatically appear can push other infobox information below the bottom of the article content, which makes the layout look bad and may lead to readers ignoring the information. We should be careful about infobox length bloat. — hike395 (talk) 03:40, 18 June 2025 (UTC)
- We don't need more stuff added by default to infoboxes! • Sbmeirow • Talk • 06:59, 18 June 2025 (UTC)
- Could you explain why, please? --Joy (talk) 15:03, 18 June 2025 (UTC)
- Agree we definitely don't need more files... A page like New York city has 17 images in the info box we definitely do not want to force more to be open.... thus causing even more accessibility problems by sandwiching everything down to the wrong section or in between the info box and left angle files. Moxy🍁 22:21, 23 June 2025 (UTC)
- @Moxy The article New York City already has an image_map with an embedded mapframe already. There would be no change in that case. --Joy (talk) 06:52, 25 June 2025 (UTC)
- New York City is the bad example in my view. I prefer Toronto format .....still mass minni image spam....but only one map with option for someone interested to see others with click. City infoboxes are the examples people use when talking about infobox bloat. Moxy🍁 06:19, 27 June 2025 (UTC)
- @Moxy The article New York City already has an image_map with an embedded mapframe already. There would be no change in that case. --Joy (talk) 06:52, 25 June 2025 (UTC)
- We don't need more stuff added by default to infoboxes! • Sbmeirow • Talk • 06:59, 18 June 2025 (UTC)
- Toronto has a image_map with an embedded mapframe made collapsible, behind a {{hidden begin}}. That is doable in the defaults as well. --Joy (talk) 07:37, 27 June 2025 (UTC)
Change to display of native_name
So I’m testing out a change to how |native_name= is displayed. If both {{{native_name}}} and {{{native_name_lang}}} are defined, my thinking is to call {{native name}}. This template wraps it in the proper span tags but also outputs a helpful link to the language in question. IMHO this is a much nicer user experience than just displaying the name in some unknown language. I have setup a couple of testcases and would love some feedback… —Zackmann (Talk to me/What I been doing) 05:42, 19 September 2025 (UTC)
- I don't have time to look right now, but poke around other infobox templates to see what they do. I am almost sure that there is code that you could copy from somewhere, which will prevent a later editor, or maybe you, from coming back later to say "why can't we standardize how this works?" – Jonesey95 (talk) 23:12, 21 September 2025 (UTC)
wikidata data
hello
please why the infobox not take the information automaticlly from the wikidata sources like the french infobox
thanks Othman.ifni (talk) 19:34, 22 September 2025 (UTC)
- This template does retrieve some information from Wikidata, including coordinates that generate a mapframe map. You can see a list of retrieved items in the box labeled "This template uses the Wikidata properties". This 2018 RFC limits what can be pulled from Wikidata. – Jonesey95 (talk) 12:55, 25 September 2025 (UTC)
Nomination for merger of Template:Infobox Australian place
Template:Infobox Australian place has been nominated for merging with Template:Infobox settlement. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. Zackmann (Talk to me/What I been doing) 19:48, 4 October 2025 (UTC)