Template talk:Infobox settlement

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:Infobox City)

"Show both" instead of "Show all"[edit]

When there's two maps that can be flipped between, instead of an option that says "Show all" it should say "Show both". Akeosnhaoe (talk) 10:02, 12 January 2024 (UTC)[reply]

Some articles contain more than two pushpin maps in the infobox (though I don't think I've seen more than three). Deor (talk) 12:03, 12 January 2024 (UTC)[reply]
I understand, and for those cases (3 or more) it should be "Show all". Akeosnhaoe (talk) 03:14, 20 January 2024 (UTC)[reply]
It's irrelevant - this is not the place to discuss the matter, as this infobox has no control over {{Location map}}. If you want the map to change as proposed, it should be discussed at Module talk:Location map. Primefac (talk) 13:53, 20 January 2024 (UTC)[reply]

When I set the value of child parameter of the sub-template to Yes, why doesn't it appear as intended, especially within Infobox settlement? The border still exists. Natsuikomin (talk) 11:42, 23 January 2024 (UTC)[reply]

Can you give an example? E.g. at Marrakesh this seems to work as intended. Fram (talk) 12:09, 23 January 2024 (UTC)[reply]
In George Town, Penang infobox. Can you believe what I've been going thru?
The order of paramater matters. The sub-infobox should be right below the website parameter (so the website would be the last parameter in the infobox if the sub-parameter were removed). And the infobox I edited has its website parameter in the middle of the other parameters. Moreover, the value of child parameter inside the sub-infobox should be 'yes' (not capitalised) instead of 'Yes' (capitalised).

This is the first I met a case like this. I used to think that Wikipedia server machine will not take the order into account and just rearranges the parameters order for us when we want to render the page on our browser. Hereby, I have found the solution after it took me about 1 hour. Thanks. Natsuikomin (talk) 12:54, 23 January 2024 (UTC)[reply]
Okay, I lately noticed a new thing about the order. The order is the case if I don't use the module parameter. I originally just put the Infobox UNESCO World Heritage Site at the bottom of the parent infobox because I took the infobox on Hebron as an example. Hmm.. Natsuikomin (talk) 13:26, 23 January 2024 (UTC)[reply]
The documentation for this template explains: "module: To embed infoboxes at the bottom of the infobox". You figured it out on your own. The order of parameters does not matter if they are used correctly. I have fixed Hebron. – Jonesey95 (talk) 16:51, 23 January 2024 (UTC)[reply]
I know. At first I used the module parameter, but the sub-infobox had a border around and the width didn't occupy 100% as it looks now on George Town, Penang and Hebron. It likely happened because I set the value of child parameter of the sub-infobox to 'Yes' (capitalised) instead of 'yes' (not capitalised). That's why I use Hebron infobox as an example and, as you can see from my previous comments, the second problem came. Natsuikomin (talk) 22:41, 23 January 2024 (UTC)[reply]

Default image alt text duplicates caption[edit]

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

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)[reply]
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)[reply]
What would be your proposed resolution? Nikkimaria (talk) 04:07, 5 March 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

Move some items from left side to right side[edit]

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

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

Two maps conveying the same information in infobox[edit]

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

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)[reply]
@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)[reply]
I see two switchable maps at that link. What exactly do you want to see? – Jonesey95 (talk) 00:44, 21 May 2024 (UTC)[reply]
@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)[reply]