mic_none

Module talk:Settlement short description Source: en.wikipedia.org/wiki/Module_talk:Settlement_short_description

Dark mode problem with image_map

[edit]

Greater Toronto Area uses File:Greater Toronto Area map.svg for the image_map parameter of this template. Unfortunately, that image has a transparent background, meaning that in dark mode, the black text it uses in the outer areas is unreadable. There is no image_class parameter for this template which would allow me to set the CSS class of this map to "skin-invert-image" which would fix the problem (though it would also generate some ugly colors). -- Beland (talk) 01:22, 3 January 2025 (UTC)[reply]

Fixed with {{!}} and documented. -- Beland (talk) 10:49, 4 January 2025 (UTC)[reply]

Edit request 27 February 2025

[edit]

To change "named_for" to "named_after". Reason: while the two phrases are considered synonymous in American English, they are not in British English, where 'named after' means 'in honour of' ("I'd like to name this after Xxxx, who died last year"), and 'named for' means 'named at the request of' ("could you name this for me, please"). Having "named for" looks very ugly to UK eyes, particularly when appearing on UK-related pages. Thanks! - MPF (talk) 00:02, 28 February 2025 (UTC)[reply]

Someone, please! Additional point: at wikidata, the standard is also named after - MPF (talk) 21:17, 13 March 2025 (UTC)[reply]
 Done — hike395 (talk) 21:37, 13 March 2025 (UTC)[reply]
@Hike395 many thanks, much appreciated! - MPF (talk) 22:13, 13 March 2025 (UTC)[reply]

Overriding short description

[edit]

Is there a way to actually remove the auto-generated short description? The documentation says to add a {{short description}} template at the top of the article, but that actually gives it two short descriptions. You'll see them if you have preferences enabled to show the short desc in gray at the top of articles.

I know this isn't the biggest deal in the world, but it rubs me the wrong way; I'd really like to have just one short description, even when the auto-generated one is problematic. --Trovatore (talk) 04:03, 11 March 2025 (UTC)[reply]

Looking up higher in this talk page, I found the answer: you can add short_description = no to the parameters.
Why short_description = no instead of just short_description = ? That's a side issue; I don't want to fixate on that. But I do think that would be a better syntax.
Anyway, I think this parameter should be documented in the documentation for {{infobox settlement}}, but when I went to edit the documentation, it turns out that the banner talking about the autogenerated short description comes from another template, {{auto short description}}, and it wasn't clear to me whether the same parameter applies everywhere that that template is transcluded. Could someone look into this? --Trovatore (talk) 04:13, 11 March 2025 (UTC)[reply]

The infobox uses the Settlement short description module to create a SD based on various infobox parameters. This "auto generated" SD can sometimes produce a long or "messy" SD that triggers error reports. Adding short_description = no to the infobox instructs the module to not do this. Setting the switch does not set an alternative SD, but allows the SD in the article to be the only one. I have added a line to the documentation — GhostInTheMachine talk to me 20:14, 9 April 2025 (UTC)[reply]

@Trovatore: — GhostInTheMachine talk to me 20:15, 9 April 2025 (UTC)[reply]
Thanks, GhostInTheMachine. But I'm afraid I still think it's not very discoverable. At the top of the page there's a blue circle with a lowercase i in it that says This template adds an automatically generated short description. If the automatic short description is not optimal, replace it by adding {{Short description}} at the top of the article.. That's where I'd really like the documentation to show up, if it's possible. It seems to be a big mess to figure out how to add that, with all the transclusions and so on. --Trovatore (talk) 01:19, 10 April 2025 (UTC)[reply]
The {{auto short description}} template is a flag in the template documentation that adds the template to a category and displays that information message. The message is fixed, but it is correct for all cases – if the auto-SD from the infobox is not good enough, then override it by adding a {{short description}} template at the top of the article. The infobox auto-SD is generated with noreplace set and so any manual SD from the article would be the one that is used. In some rare occasions, the auto-SD (while not used) does trigger an error report. In this case, it can be suppressed via adding short_description = no to the article infobox.
So, the SD from the infobox is often good enough or it can be easily superseded by editing the article and adding a {{short description}} template at the top. Only very rarely is there any need to use the short_description = no trick — GhostInTheMachine talk to me 13:34, 10 April 2025 (UTC)[reply]
Well, it depends on what you mean by "need". I have a CSS setting that shows the SD on the web version, and seeing two SDs, well, let's say I find it untidy. As I said in my initial message, this isn't the biggest deal in the world, but I would prefer that the autogenerated SD were always removed whenever a local one is set. --Trovatore (talk) 18:24, 10 April 2025 (UTC)[reply]
If you really do not want to see the ghost SD, then add the line .shortdescription ~ .shortdescription { display: none !important; } to your common.css after the existing line — GhostInTheMachine talk to me 07:28, 11 April 2025 (UTC)[reply]
Well, but I still know it's "there", whatever that means. This is my aesthetic sense as a software engineer complaining. I would just prefer it weren't there. As I said not the biggest deal in the world, but it's a "code smell". --Trovatore (talk) 19:06, 11 April 2025 (UTC)[reply]
As far as I know, the shortdesc helper gadget shows only the canonical SD for a given page, properly ignoring the replaced automatic version when there is an article-local description. – Jonesey95 (talk) 02:57, 13 April 2025 (UTC)[reply]
True. Trovatore was expressing disquiet about the ghost SD displayed via the CSS override. I have offered suitable CSS that modifies the override — GhostInTheMachine talk to me 08:26, 15 April 2025 (UTC)[reply]
Apparently I didn't explain myself sufficiently. I wasn't upset about myself seeing it, exactly. I was upset that the second SD was still "there" to be seen. I haven't looked into the software sufficiently to be sure what "there" even means, but it seems like a code smell. --Trovatore (talk) 17:53, 15 April 2025 (UTC)[reply]
Items wrapped with "display:none" are still "there" also, as is a whole bunch of other stuff that is normally hidden from the typical reader. When you choose to show deliberately hidden items with custom CSS, I think that is for you to cope with. – Jonesey95 (talk) 16:33, 17 April 2025 (UTC)[reply]

Worrying trend on articles about Croatian coastal cities that were under occupation by Fascist Italy

[edit]

Moved to WT:HRV. --Joy (talk) 08:23, 17 April 2025 (UTC)[reply]

on rendering wikidata

[edit]

Following up on Template talk:Infobox settlement/Archive 33#using wikidata as fallback at least?...

Today I found an apparent error by looking at the newly rendered map on Popovska reka. The Wikidata entry actually references a database for that value, and the value is clearly at odds with the description in the article.

I think this is another example where we'd benefit from rendering the coordinates more, not less, because this gives visibility to issues. Most editors won't recognize errors just from looking at the numbers.

Obviously both of my recent controversial examples have been about {{infobox river}}, but I figured there's more readership here. --Joy (talk) 08:53, 15 May 2025 (UTC)[reply]

Seat field

[edit]

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)[reply]

enable mapframe wherever pushpin_map is specified, but no other map

[edit]

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)[reply]

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), |module or indeed any other parameters. An insource search should find examples. Regs, The Equalizer (talk) 00:14, 18 June 2025 (UTC)[reply]
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)[reply]
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)[reply]
We don't need more stuff added by default to infoboxes! • Sbmeirow • Talk • 06:59, 18 June 2025 (UTC)[reply]
Could you explain why, please? --Joy (talk) 15:03, 18 June 2025 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
Toronto has a image_map with an embedded mapframe made , behind a {{hidden begin}}. That is doable in the defaults as well. --Joy (talk) 07:37, 27 June 2025 (UTC)[reply]

Auto population density

[edit]

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)[reply]

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
Infobox settlement
Area
 • City
1 km2 (0.4 sq mi)
 • Rural
2 km2 (0.8 sq mi)
Population
 • City
1
 • Density1.0/km2 (2.6/sq mi)
 • Rural
4
 • Rural density2.0/km2 (5.2/sq mi)
Regs, The Equalizer (talk) 23:47, 17 June 2025 (UTC)[reply]
Just as an example, I was trying to do this on the Belgrade article, where I have to move around some of the area, population and density figures, and simply could not get the density figures to work with "auto." Criticalthinker (talk) 00:13, 18 June 2025 (UTC)[reply]
Fixed. The population numbers contained refs, which means auto could not calculate correctly. Those cites have been moved to the correct parameters. Beware of some new caveats:
  • The densities are auto rounded to the nearest tens or hundreds, you will have to readd the exact numbers if you prefer those;
  • The citations are not on the ends of the numbers but on the ends of the parameter titles, which is tidier and an ideal format.
Regs, The Equalizer (talk) 00:50, 18 June 2025 (UTC)[reply]
Thanks, though I was not wanting to actually do it that way, was just testing to see if it works. I understand now that it can't do it to numbers with citations on the end of them. Though, it seems to have been pretty standard around here for many years to place citations on the numbers. And, yeah, that rounding is not helpful. I'd understanding rounding after the deciminal, but before is not helpful for when you want to represent accurate population densities. Criticalthinker (talk) 16:55, 18 June 2025 (UTC)[reply]