Template talk:Infobox settlement

Default image alt text duplicates caption

This code for this infobox when embedding an image contains |title={{if empty|{{{image_caption|}}}|{{{caption|}}}|{{{image_alt|}}}|{{{alt|}}}}}}}. When the alt= parameter is empty or missing, this results in the image's ALT text getting set to the text of the caption. (example) This is an improper ALT text: The alt text is intended to be read out by screen readers just before the caption, so avoid having the same details in both. (MOS:ALT) This behavior is also unhelpful for sighted readers in that it repeats the caption right below the image. Opencooper (talk) 16:19, 4 March 2024 (UTC)

When I expand the infobox at Algiers using Special:ExpandTemplates, I do not see any |alt= attributes in the code for any of the images, but there is a lot of code. Can you please create a minimal example showing the problem? – Jonesey95 (talk) 18:42, 4 March 2024 (UTC)

Sorry, I should have been more clear. The alt attribute I am referring to is in the final generated HTML on the article's page. If you right click the image and use your browser's inspect element feature, you'll see <img […] alt="Clockwise, top left[…]. Opencooper (talk) 00:00, 5 March 2024 (UTC)

What would be your proposed resolution? Nikkimaria (talk) 04:07, 5 March 2024 (UTC)

Many other Infobox templates set the image title to the alt text, if there is any. So one solution would be to stop using the caption: |title={{if empty|{{{image_alt|}}}|{{{alt|}}}}}}}. Opencooper (talk) 05:34, 5 March 2024 (UTC)

Feel free to make that change in the sandbox to see if it makes a difference. When I expand the infobox at Algiers, the File call in wikitext looks like [[File:Algiers Montage.png|275px|'''Clockwise, top left''': Coast of Algiers, [[Maqam Echahid|Maqam Echahid (Martyrs' Memorial)]], [[Notre-Dame d'Afrique|Basilique Notre Dame d'Afrique]], [[Ketchaoua Mosque]], [[Kasbah of Algiers]], [[Grande Poste d'Alger|Algiers Central Post Office]], [[Ministry of Finance (Algeria)|Ministry of Finance building]]]]. I don't see an alt tag in there, which makes me think that changing this infobox will not change the rendered HTML. Something in the MediaWiki code may be generating the alt text in the rendered HTML. – Jonesey95 (talk) 19:30, 5 March 2024 (UTC)

I was operating under the assumption that these templates did not use the image linking syntax, but this proves otherwise. Therefore, your comment over at Infobox writer seems to apply: when thumb […] is not specified [and] no alt text is specifically requested, use the requested caption as alt text. So technically this is expected behavior of the image linking syntax. (though confusingly, is not seen on all Infobox templates) But this behavior is against the MoS and results in unhelpful duplication. However, I'm not sure where to get this changed and would probably need an RfC. Opencooper (talk) 16:49, 15 March 2024 (UTC)

Move some items from left side to right side

I think some items, like elevation_max_point and elevation_min_point, should be moved from the left to the right side. When there is too much text on any row on the left side (like these two parameters), the left column automatically becomes wider and the right column becomes narrower, which isn't great, because the right column generally has more text overall.

An example is Montgomery (village), New York, where you can see the wider left column and narrower right column. I prefer names, areas, and population density on a single line when possible.

I will also note that the "desktop" and mobile views look different. There is much more whitespace on the "desktop" version, and on the page I mentioned, the ratio between left and right column widths is better on the mobile version. Kk.urban (talk) 20:28, 11 March 2024 (UTC)

That page looks normal to me in both the desktop and mobile versions. I use the default Vector 2022 skin for desktop. That said, I also think those two parameters should be moved to the right side; they are values, not labels. I have modified the sandbox, and you can see a test case in my sandbox. – Jonesey95 (talk) 21:32, 11 March 2024 (UTC)

@Jonesey95 It looks different from "normal" because on most settlement articles, the right column is wider than the left. Your sandbox looks good. Kk.urban (talk) 22:20, 11 March 2024 (UTC)

Two maps conveying the same information in infobox

Resolved

Is there a way to remove the pushpin map in Milwaukee while keeping the switchable map above it? Because that's switchable, it shows the same information to readers and greatly extends the infobox. Ed ^{[talk] [OMT]} 21:23, 20 May 2024 (UTC)

Well, if you really want to do that, you can simply remove the |pushpin_map= parameter (and the two following parameters) in the infobox. You could get some pushback from other editors, though. Deor (talk) 21:33, 20 May 2024 (UTC)

@Deor: The problem is that leads to the first map showing all its parameters, instead of remaining switchable. :-) Ed ^{[talk] [OMT]} 00:18, 21 May 2024 (UTC)

I see two switchable maps at that link. What exactly do you want to see? – Jonesey95 (talk) 00:44, 21 May 2024 (UTC)

@Jonesey95: Apologies, I meant to link to a diff.

I think I've figured out the issue–it may be something to do with article caches. When I removed pushpin second map again, I once again saw the first map go from switchable to showing four separate maps. But after purging the cache, the article appeared normal again. I tested and had the same thing happen at Detroit, including the cache purge fix. Funky. Apologies for taking up y'all's time! Ed ^{[talk] [OMT]} 03:04, 21 May 2024 (UTC)

Edit request 1 June 2024

Description of suggested change:

Would it be possible to add 'police' and 'fire' fields after the government section please? I'm sure this is a pretty universal field for most settlements and tagging it on the bottom in the blank fields with GDP etc. looks a little odd.

Dgp4004 (talk) 23:17, 1 June 2024 (UTC)

That stuff belongs in the "Government" section of the article. There is already too much infobox bloat. • Sbmeirow • Talk • 03:26, 2 June 2024 (UTC)

Please suggest the change and get consensus for it before activating an edit request. Johnuniq (talk) 03:36, 2 June 2024 (UTC)

Oversized maps

User:RAGentry has been adding oversized maps to hundreds of US city articles. My concern is that this makes the infobox unnecessarily wide (the default size is 250 px). At Berryville, Texas, for example, there are no photos in the infobox, so no need for an oversized map. The input of others would be appreciated. Magnolia677 (talk) 15:52, 2 June 2024 (UTC)

In my defense, 250 is only a default and not prescribed, and there are plenty of articles which use 280 as the size of their infobox. 280 makes the maps easier to see and understand and ensures that the entire shape fits into the map. The idea of "oversized" is subjective, considering it is only a 30 pixel difference. Is it really that big of an issue? RAGentry (talk) (contributions) 16:03, 2 June 2024 (UTC)

Also, I note that on the main page of this template, Template:Infobox settlement, one of the example infoboxes is 275px wide, while the other is 290px wide. These are both wider than the default of 250px. That both examples are wider than 250px seems to me to suggest that expanding beyond the default of 250px is definitely acceptable, especially if the circumstances support it (such as increased readability of interactive map thumbnails), and especially if they are not being increased beyond 290px wide, which is the width of one of the example infoboxes in the documentation of this template. I would suggest that the examples of an infobox in its documentation provide more weight to the acceptable widths of a template than the default width in the template parameters. RAGentry (talk) (contributions) 16:14, 2 June 2024 (UTC)

In general, the size fields shouldn't exist at all to all wikimedia to auto size the images according to user preference settings or default settings, except to shrink photos in infoboxes. Large fixed sizes are a problem on small devices such as smartphones, especially in infoboxes. Almost always, I delete those fields from the infobox, and I recommend you to do the same. • Sbmeirow • Talk • 21:35, 2 June 2024 (UTC)

That's a good point; I see how having no fixed size could be beneficial. The problem with this is that in the case of interactive maps, the infobox is ultimately going to be widened by the frame width set in the Maplink template. Removing these creates a rectangular map (300px wide by 200px high) rather than a square map, which is the norm for interactive maps on city articles. It also makes the infobox 300px wide, which might be offensive to some people. What do you think might be a good workaround for this? Also, where in preferences can the images be auto-sized? — RAGentry (talk) (contributions) 22:13, 2 June 2024 (UTC)

Where does it say square maps "is the norm for interactive maps on city articles"? At Template:Maplink, the infobox example is rectangular, and the template specifically states "additional parameters are available to customise the displayed map", such as width and height. Magnolia677 (talk) 22:43, 2 June 2024 (UTC)

Norms just refer to something that is standard, not necessarily something that is written in as policy. I mentioned it to explain why I chose to use square maps, referring to the trend seen in articles such as Erie, Pennsylvania, Harrisburg, Pennsylvania, San Francisco, and others. Of course, it is possible and likely that there are others that do not match this trend, but I was using square maps because it is what I saw in other interactive maps on city articles. The example in a template documentation is not a requirement, and that there are additional parameters available to customise the displayed map seems to suggest that it is not a requirement for it to be rectangular. — RAGentry (talk) (contributions) 23:45, 2 June 2024 (UTC)

My slight mistake, preferences has a setting for thumbnail photos in the article, it appears to not affect the infobox. In general, many infoboxes are already too dang big in community articles, and increasing the size of photos or maps makes the problem much much worse. Remember that a user can click on a photo or map to see a full size version of it, thus solving the size problem. Please do not increase the size of maps or images in infoboxes. • Sbmeirow • Talk • 22:40, 2 June 2024 (UTC)

Ok, I will not increase the size of maps or images in infoboxes. — RAGentry (talk) (contributions) 23:45, 2 June 2024 (UTC)