Template talk:Infobox settlement

Location labels unreadable in dark mode

In dark mode, location labels on map are black text on a black background. This does not happen for me when I use {{location map}} directly, but it does happen in the examples on the {{Infobox settlement}} documentation. I'm not sure where this CSS lives, but it appears that this happens because the color is coming from this block:

@media (prefers-color-scheme: dark) {
  html.skin-theme-clientpref-os .mw-parser-output .od, html.skin-theme-clientpref-os .mw-parser-output .od .pv > div, html.skin-theme-clientpref-os .mw-parser-output .od .pl > div, html.skin-theme-clientpref-os .mw-parser-output .od .pr > div {
    background: white !important;
    color: #000 !important;
  }
}

but the background color is coming from this block:

@media screen and (prefers-color-scheme: dark) {
  html.skin-theme-clientpref-os .mw-parser-output .infobox-full-data:not(.notheme) div:not(.notheme) {
    background: #1f1f23 !important;
    color: #f8f9fa;
  }
}

The second block has higher priority, so the !important background-color there takes effect. I think the color in the second block is missing its !important; that is why it is not overriding the !important color from the first block. Though I'm not sure why the first block is trying to use black text on white background in dark mode. -- Beland (talk) 21:05, 2 August 2024 (UTC)

This seems to have been fixed, though nothing was changed at Template:Infobox settlement/styles.css or Template:Infobox settlement. Perhaps it was a problem in skin CSS? -- Beland (talk) 17:21, 12 September 2024 (UTC)

Template-protected edit request on 9 August 2024

Add a parameter for flag_type, so that other options like banners can also be added (eg. State banners, municipal banners, county banners etc). Since the infobox Indian state or territory is a customised wrapper for this infobox, and it is explicitly mentioned that Indian states use banners and not flags (since they are only used for the official purpose by the government and not as the representation for the state), I did not want to add the parameter of flag to them, but rather of banner. Pur 0 0 (talk) 15:02, 9 August 2024 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. – Jonesey95 (talk) 21:07, 10 August 2024 (UTC)

Mandatory hidden OpenStreetMap

Hi, an OSM map is required for all settlements, but nearly all the times it makes its Infobox ugly. I propose to place an OSM map for all instances of this template and then hiding that by using {{hidden begin}} and {{hidden end}} templates. But if needed, the editors can expand OSM by default by a parameter. Something like this:

Shiraz Persian: شیراز
City
Shiraz
skyline of Shiraz;
Flag
Nickname:  City of Gardens
OpenStreetMap
Shiraz Location of Shiraz within Iran
Coordinates: 29°36′36″N 52°32′33″E

Hooman Mallahzadeh (talk) 12:39, 5 September 2024 (UTC)

Sorry, why would it be required? It's optional per Wikipedia:Requests for comment/Mapframe maps in infoboxes

At the same time, what's the ugly part exactly? --Joy (talk) 22:40, 7 September 2024 (UTC)

Which reminds me, we never added the standard optional mapframe support here. I'll go check in the sandbox if I can do that now, IIRC the local code here was somewhat more convoluted than average. --Joy (talk) 19:02, 8 September 2024 (UTC)

I also do not see anything required about the mapframe map. I picked a few articles from a dab page and do not see one at Newton, Edmonton, or Newton, Surrey, or Newtown Cunningham, or Newton, Massachusetts. – Jonesey95 (talk) 11:46, 9 September 2024 (UTC)

mapframe support

Phew, [1] was annoying to do, but didn't actually seem particularly complex.

I noticed we actually have a test case already at Template:Infobox settlement/testcases2#Case 17: Chicago with mapframe

Any objections to making this go live? --Joy (talk) 19:38, 8 September 2024 (UTC)

As nobody raised any objections, it's in the template now, let's see what we find out with real-world testing. --Joy (talk) 08:31, 27 September 2024 (UTC)

There's been no feedback about this after a bit over a month?

I'll proceed to set the onByDefault parameter in case of no other maps are present, as we do elsewhere. --Joy (talk) 21:27, 2 November 2024 (UTC)

@Pppery can you give me an example so I can add a test case and fix it, please? --Joy (talk) 22:52, 3 November 2024 (UTC)

See current list of articles with Lua errors. Aïn El Hadid is one example. * Pppery * _{it has begun...} 22:53, 3 November 2024 (UTC)

I think the root cause is a coordinates value that is either malformed (like in that example) or written without using {{coord}} (like in Ipelegeng). I've seen and fixed a lot of these as various smaller-scale templates get converted to mapframe maps, but the scale (over 100 errors at once) was bigger than I was willing to tackle so I reverted. * Pppery * _{it has begun...} 22:58, 3 November 2024 (UTC)

Ah, so this is just a case of the new functionality exposing earlier issues. That's 150 errors in the list total, that's not paginated at 150, right? Given the 569K transclusions, that's not actually that bad :) --Joy (talk) 23:04, 3 November 2024 (UTC)

No, it's paginated (and entries are being removed as they were reparsed). But it's in alphabetical order and paginated more than half way through the alphabet, so the number of errors is still probably only a few hundred. The third case to handle is coordinates being missing and not on Wikidata either, like Nyongxar * Pppery * _{it has begun...} 23:07, 3 November 2024 (UTC)

Or set to unknown value, like Sink, West Virginia * Pppery * _{it has begun...} 23:07, 3 November 2024 (UTC)

Looks like other infoboxes are triggering them, too. I'm going through them one by one, it's a variety of circumstances. --Joy (talk) 23:11, 3 November 2024 (UTC)

OK so I think I went through half the list so far, confirming the extent of the issue. It's all article issues, I didn't find a single one that wasn't somehow deviating from either the infobox specification or the verifiability policy - a bunch of US ghost towns referenced to dead links. Will handle the rest later. --Joy (talk) 00:31, 4 November 2024 (UTC)

That list is dynamic, and only shows entries that displayed a Lua error the most recent time they were parsed, which happens on an edit to the page as well as by itself (that is, since your edit to the template was reverted, the errors are slowly going away). For future references, here's the list as it stands now:

Extended content

<cm ns="0" title="Maya Bigha"/> <cm ns="0" title="Melakaveri"/> <cm ns="0" title="Metagama"/> <cm ns="0" title="Metikoš"/> <cm ns="0" title="Minden, Lawrence County, Missouri"/> <cm ns="0" title="Mirigama Divisional Secretariat"/> <cm ns="0" title="Misteriosa Bank"/> <cm ns="0" title="Mogullapalle"/> <cm ns="0" title="Montrose Park, Pennsylvania"/> <cm ns="0" title="Moscow Orphanage"/> <cm ns="0" title="Nexus International University"/> <cm ns="0" title="Nokhar"/> <cm ns="0" title="Nutu"/> <cm ns="0" title="Nyongxar"/> <cm ns="0" title="Old Mokotów"/> <cm ns="0" title="Olusosun landfill"/> <cm ns="0" title="Oshimili North"/> <cm ns="0" title="Palle Hapuwida"/> <cm ns="0" title="Parnaguá"/> <cm ns="0" title="Pathul"/> <cm ns="0" title="Phalasia"/> <cm ns="0" title="Pokharathok, Palpa"/> <cm ns="0" title="Ponnavarayankottai"/> <cm ns="0" title="Prang Ghar"/> <cm ns="0" title="Prek Sbauv"/> <cm ns="0" title="Punta Brava Golf Club"/> <cm ns="0" title="Pussalakandura"/> <cm ns="0" title="Qasam, Yemen"/> <cm ns="0" title="Qingniwaqiao"/> <cm ns="0" title="Radmilović"/> <cm ns="0" title="Rawat Fort"/> <cm ns="0" title="Ribnica, Croatia"/> <cm ns="0" title="River North Gallery District, Near North Side, Chicago"/> <cm ns="0" title="Rockville, Pennsylvania"/> <cm ns="0" title="Rosario Bank"/> <cm ns="0" title="Roxie, West Virginia"/> <cm ns="0" title="Sagne, Mauritania"/> <cm ns="0" title="Saint-Louis-du-Ha! Ha!"/> <cm ns="0" title="Samanabad"/> <cm ns="0" title="San Benito, Entre Ríos"/> <cm ns="0" title="San Martín Zapotitlán"/> <cm ns="0" title="Sangmai"/> <cm ns="0" title="Seh Chah, Faryab"/> <cm ns="0" title="Sekyedumase"/> <cm ns="0" title="Sêrkog"/> <cm ns="0" title="Serra Talhada"/> <cm ns="0" title="Sershul Town"/> <cm ns="0" title="Shahrak-e Saduqi"/> <cm ns="0" title="Shivalik Enclave"/> <cm ns="0" title="Šilovo (Lebane)"/> <cm ns="0" title="Sink, West Virginia"/> <cm ns="0" title="Skoura M'Daz"/> <cm ns="0" title="Skydive Chicago Airport"/> <cm ns="0" title="South Harrisburg, Pennsylvania"/> <cm ns="0" title="Stadsdriehoek"/> <cm ns="0" title="Stierjoch"/> <cm ns="0" title="Sultaniya, India"/> <cm ns="0" title="Swarth Fell"/> <cm ns="0" title="Tabory, Ukraine"/> <cm ns="0" title="Tajpur, Dildarnagar"/> <cm ns="0" title="Tanza, Navotas"/> <cm ns="0" title="Tchibanga Airport"/> <cm ns="0" title="Thayyur"/> <cm ns="0" title="Thiruppachethi"/> <cm ns="0" title="Thirupuvanam, Sivaganga"/> <cm ns="0" title="Tigrinhos"/> <cm ns="0" title="Tilaknagar"/> <cm ns="0" title="Tofkian"/> <cm ns="0" title="Tseboum Soumdo"/> <cm ns="0" title="Tsekankan, California"/> <cm ns="0" title="Tsemkhog"/> <cm ns="0" title="Tunjungan Plaza"/> <cm ns="0" title="Uddemarri"/> <cm ns="0" title="Újcsanálos"/> <cm ns="0" title="Uppariguda"/> <cm ns="0" title="Urbasa"/> <cm ns="0" title="Urdok Ridge"/> <cm ns="0" title="Ustoma, California"/> <cm ns="0" title="Valakom, Kottarakara"/> <cm ns="0" title="Valdecaballeros"/> <cm ns="0" title="Vandalia Municipal Airport"/> <cm ns="0" title="Venmankondan (East)"/> <cm ns="0" title="Waghjan"/> <cm ns="0" title="Waikkal"/> <cm ns="0" title="Walapane"/> <cm ns="0" title="Waterdown, Ontario"/> <cm ns="0" title="Wazirabad, Gurgaon"/>

But once you redeploy the edit it's possible that new articles will have errors in the same list that didn't show up before, because the parser sometimes does that. * Pppery * _{it has begun...} 00:45, 4 November 2024 (UTC)

Do you think it's acceptable that we do this in batches like that? IOW, that we clean up a bunch that we see, then enable the code again, then after e.g. one day of random cache purges we look at it again, reassess whether we need to undo the showing of the error and do more clean up, rinse and repeat? --Joy (talk) 08:56, 4 November 2024 (UTC)

Maybe there's a way to more subtly detect if the coordinates value is not wrapped in {{coord}}, and make a hidden tracking category for that? --Joy (talk) 08:57, 4 November 2024 (UTC)

@Hike395 I remember you adding some magic recently to a related template, could I trouble you to ponder if there's a way to check for bad |coordinates= formatting here? It needs to be {{coord}}, but sometimes people enter it free-form (even if there is a formatted coord at the bottom of the article, d'oh). --Joy (talk) 17:54, 4 November 2024 (UTC)

I also tried to use bambots template param tool to weed out the syntax errors, but it was only tangentially related to this issue, there must be too many distinct |coordinates= values so it doesn't render them. --Joy (talk) 10:54, 5 November 2024 (UTC)

There isn't a specific tool related to checking coordinates, but I'm experimenting with a general piece of code that catches errors in module calls and lets you put those into tracking categories. No luck yet. — hike395 (talk) 12:26, 5 November 2024 (UTC)

I'd wrap the invocation of infobox mapframe with #iferror: and add a tracking category if there's an error, at least until all the coordinates are fixed:

{{#iferror: {{#invoke:Infobox mapframe|...}}|category|{{#invoke:Infobox mapframe|...}} }}

Also, a search like this might help. Ponor (talk) 13:13, 5 November 2024 (UTC)

Because Infobox mapframe is used blindly, I think it'd be wise to add something like Special:Diff/1255559502 in the temolate. Up to you! Ponor (talk) 15:33, 5 November 2024 (UTC)

Yes, that's exactly what I had in mind. Thanks!

A few minutes ago I also realized I can search for some of the common pitfalls, like this for misplaced coord missing calls. Good thing it's not common. --Joy (talk) 18:05, 5 November 2024 (UTC)

BTW because of transclusion here, {{Ifnoerror then show}} immediately became a high risk template so I protected it. You'd have to apply for the Wikipedia:Template editor permission to continue to edit it. --Joy (talk) 18:19, 5 November 2024 (UTC)

Allow me to also ping @Qwerfjkl and @Hike395 for a review of this somewhat new code. --Joy (talk) 18:21, 5 November 2024 (UTC)

Joy, well, I have no idea what I wanted {{iferror then show}} for, but good to see it's useful for something (and more to the point, {{ifnoerror then show}} is). — Qwerfjkltalk 19:08, 5 November 2024 (UTC)

Apparently Template:United States presidential election results table row (Diff ~1080169510). — Qwerfjkltalk 19:14, 5 November 2024 (UTC)

I brought it down to 11 either unrelated ones, or nicely formatted ones - a few American ghost towns where the error is about no coordinates in Wikidata. I'll re-enable it again then, and see if and how the backlog fills up again. --Joy (talk) 10:14, 4 November 2024 (UTC)

They're trickling in rather slowly, I only got a handful in the last few hours. I suppose that's actually good - the old cached versions without visible errors generally stay up, and only rarely get rendered again with the error. --Joy (talk) 14:04, 4 November 2024 (UTC)

From the looks of it, this issue has been generally addressed by now. The last few fixes I did were mostly about recent edits. The numbers at Template:Infobox settlement#Tracking categories show this issue to be in a markedly better shape than the average :) --Joy (talk) 10:52, 8 November 2024 (UTC)

Can you added a optional parameter to collapse the map, like they did for municipalities in the Philippines? See for example Manila. Thanks. -- P 1 9 9  ✉ 14:58, 4 November 2024 (UTC)

That was apparently implemented with an image_map1 that uses {{hidden begin}} to transclude {{Infobox mapframe}} inside. Would we want to just do that kind of wrapping inside infobox dataN parameters? I don't know, it seems very intricate for something so optional. --Joy (talk) 17:42, 4 November 2024 (UTC)

I understand that it is not implemented the same, it was just an example of collapsed/hidden map. I was hoping that the Infobox mapframe already had such an option, but I see that it doesn't. This might be too complicated for now, because it would require editing Module:Infobox mapframe or even Module:Mapframe. Thanks anyway. -- P 1 9 9  ✉ 18:43, 4 November 2024 (UTC)

@P199 you can bring it up at Template talk:Infobox mapframe and see if someone can implement something to this effect. --Joy (talk) 08:18, 5 November 2024 (UTC)

And one more important thing: default width of mapframe should be 250 (not 270, as taken from Module:Infobox mapframe) to match the default widths of other maps in this infobox. Thanks. -- P 1 9 9  ✉ 15:08, 4 November 2024 (UTC)

Sure, we can synchronize that. --Joy (talk) 17:43, 4 November 2024 (UTC)

Sorry, I was asleep while this developed. What you're doing is fine with me. * Pppery * _{it has begun...} 18:03, 4 November 2024 (UTC)

Thanks. In the meantime it seems to be trickling in at a slow pace, so it seems manageable so far. --Joy (talk) 19:00, 4 November 2024 (UTC)

It seems like this sort of edit (adding mapframe=no when coordinates are not present) should not be necessary. – Jonesey95 (talk) 13:47, 6 November 2024 (UTC)

It seems to come about from being on by default when no other map is present, but then when no other coordinate sources are present it does a lookup for them into wikidata, and then in turn that generates an explicit error message in the odd cases.

Should we just preclude onByDefault if there's no value in the coordinates parameter? --Joy (talk) 17:05, 6 November 2024 (UTC)

After having said that, I realized that this relates to #using wikidata as fallback at least?. --Joy (talk) 17:12, 6 November 2024 (UTC)

I just realized there's another way to alleviate this problem - set a pushpin map parameter on those locations. The location map template won't render because its precondition is both pushpin_map and coordinates, but it will implicitly disable mapframe.

At the same time, it does make sense to at least specify a country / state in the pushpin map parameter even for ghost towns we don't know the coordinates of, that much we always have to know. --Joy (talk) 07:54, 7 November 2024 (UTC)

UK should default to metric units

Why does this template display the imperial units first for UK places? All of the official data for geographical areas and statistical data is in km². So that should be displayed first. No need for an inaccurate conversion. Craobh àrd (talk) 03:11, 9 October 2024 (UTC)

Edit request 11 October 2024

Description of suggested change: Module:Settlement short description is used by the Infobox settlement template to create a default Short description. Sometimes this default is too long and the article is flagged in the maintenance category Category:Articles with long short description. To cope with this, the module has a "kill switch" (at line 82) so that, if the infobox includes short_description = no, then the module returns an empty SD and leaves the manual SD from the article to have effect. This kill switch has been in place since the first version of the module in January 2019. Sadly, the infobox template code does not include this parameter in the Check for unknown parameters list and so, in the few(?) articles where the kill switch has to be used, the edit preview displays a Preview warning: Page using Template:Infobox settlement with unknown parameter "short_description". This means that it can "reasonably" be removed as an error. See [2].

Diff: add short_description to the Check for unknown parameters list. Please re-sort the list at the same time — GhostInTheMachine ^{talk to me} 20:24, 11 October 2024 (UTC)

 Done – Jonesey95 (talk) 13:40, 13 October 2024 (UTC)

Households and Precipitation

Please add these parameters. Lfstevens (talk) 20:53, 2 November 2024 (UTC)

No thank you. Nikkimaria (talk) 20:58, 2 November 2024 (UTC)

No, because too much stuff in the infobox already. • Sbmeirow • Talk • 09:02, 3 November 2024 (UTC)

using wikidata as fallback at least?

Is there some particular reason we're not defaulting to |coordinates={{WikidataCoord}} or something similar?

I see people have asked about this in Template talk:Infobox settlement/Archive 29#Coordinates fallback wikidata in 2019 but it was just archived. --Joy (talk) 11:59, 5 November 2024 (UTC)

This RfC set the consensus that Wikidata should only be used if it meets the reliability standards of enWP. In practice, that means data can be used in an infobox if there is adequate referencing in Wikidata. So we cannot default to Wikidata in general. — hike395 (talk) 12:26, 5 November 2024 (UTC)

Interestingly, the mapframe code does a wikidata lookup, and the (somewhat later, 2020) RFC for that resulted in Wikipedia:Mapframe maps in infoboxes which includes: If users do not specify coordinates in a parameter, coordinates from Wikidata should be used. --Joy (talk) 17:11, 6 November 2024 (UTC)

The use of Wikidata is incredibly polarizing in en WP, with strong feelings on both sides. If you're referring to this RfC, I can see not very many people participated: most of those are known pro-Wikidata people, with only one anti-Wikidata person showing up with a strong dissent. I would not rely on that local consensus overriding the well-discussed 2018 RfC.

Earlier this year, Jonesey95 fixed {{Infobox mountain}} to only rely on Wikidata entries with references. I see they have recently participated in the discussion (above). Perhaps they can chime in about what they believe the consensus is, what to do here, and whether Module:Mapframe is consistent with consensus? — hike395 (talk) 16:57, 7 November 2024 (UTC)

I didn't know about that mapframe RFC. Was it advertised at WP:CENT and other places? If not, I don't see how it could override the 2018 consensus. That said, I do know that there are some Wikidata items, like images and logos, that are pulled into infoboxes without being referenced and I haven't seen anyone complain about them. Pulling things like birth dates and other data about people is a lot more controversial. I don't have the energy to get into a big discussion about importing coordinates for use with mapframes. Just be aware that there may be objections based on the 2018 RFC; proceed with caution. – Jonesey95 (talk) 17:08, 7 November 2024 (UTC)

Isn't this like "the sky is blue"? It's pretty obvious that something is wrong if our article is for one place and the map shows some other place. Most references for coordinates on WD are from other wikis (ot this wiki) anyway. Maps using WD data are seen by many people on many wikis, it's unlikely they'd be so wrong. Ponor (talk) 17:12, 7 November 2024 (UTC)

A huge chunk of the bottom-of-the-article {{coord}} tags I ever saw have been tagged with source "kolossus-xywiki" or something like that. I never even bothered to check who that moniker referred to, because they generally passed the smell test - lookups in other crowdsourced databases yielded consistent results.

More recently as I was doing the aforementioned cleanups, I actually saw several tagged with source "wikidata", which I thought to be such a glaring WP:CIRC violation that I just removed it.

In any event, showing coordinates in mapframes would probably be generally more helpful for people to discover bad coordinate values, because that makes them more obvious.

It's also somewhat confusing that we seem to have no simple and consistent way to inline-tag unreferenced and/or suspect coordinates. --Joy (talk) 20:33, 7 November 2024 (UTC)

As it happens, today I found my first coordinate error in Wikidata :) It was at Ruby Creek (Washington) - the Wikidata item actually had pointers to GNIS etc, but the value for coordinates was broken, it was not actually cross-referenced with those linked sources. I never would have noticed this had I not happened to want to enable mapframe on that article to see a more precise location than the one provided by the pushpin map. --Joy (talk) 10:29, 18 November 2024 (UTC)

Edit request 12 November 2024

Description of suggested change: Image should be a parameter. Requiring image_skyline implies the image has to or should be a skyline, which isn't correct. Traumnovelle (talk) 04:00, 12 November 2024 (UTC)

Please get consensus for the change before proposing it. Sohom (talk) 04:26, 12 November 2024 (UTC)

The /doc does say it is "commonly" a skyline, but maybe just updating the /doc to indicate that it can be any "representative image" would fix the issue. Primefac (talk) 12:43, 12 November 2024 (UTC)

Help with languages

on the Kilacheri page the langauges (Tamil and Telugu) are not showing in the infobox. Drew Stanley (talk) 22:13, 14 November 2024 (UTC)

You have to provide the analogous _info fields for the _title fields to render. This is intended to show e.g. the percentage of people speaking each language. --Joy (talk) 10:34, 18 November 2024 (UTC)

A(n apparent) small bug

Greetings and felicitations. In Boston, the reference note for the "Population estimate" field appears in my browser under the field's label, not next to the figure. —DocWatson42 (talk) 15:20, 18 November 2024 (UTC)

Same here. In the test cases we have, it's showing on the same line, e.g. in Template:Infobox settlement/testcases#Case 7: Sequim, Washington. Something is causing the left column at Boston to be narrower - it shows as 101.5px here, while the test case has 135.45px. --Joy (talk) 08:36, 19 November 2024 (UTC)

 Fixed --- I added nowrap to three infobox labels that were wrapping poorly. Now live. — hike395 (talk) 10:52, 19 November 2024 (UTC)

Labeled pushpin description unreadable on dark mode

See for example Bir Tawil. When the dark mode in the new Vector 2022 Appearance menu (represented by an incognito icon) is enabled, the pushpin label is dark text on a dark background. Aaron Liu (talk) 23:39, 21 November 2024 (UTC)

They all look fine to me. To be clear, I am looking at the three maps, selectable with radio buttons, and I see black text on a light-gray map background or black text on a near-white background. Maybe provide a screen shot. – Jonesey95 (talk) 18:32, 22 November 2024 (UTC)