This template is within the scope of WikiProject Geography, a collaborative effort to improve the coverage of geography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.GeographyWikipedia:WikiProject GeographyTemplate:WikiProject Geographygeography
This template is within the scope of WikiProject Cities, a collaborative effort to improve the coverage of cities, towns and various other settlements on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CitiesWikipedia:WikiProject CitiesTemplate:WikiProject CitiesWikiProject Cities
This template is within the scope of WikiProject Infoboxes, a collaborative effort to improve the coverage of Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InfoboxesWikipedia:WikiProject InfoboxesTemplate:WikiProject InfoboxesInfoboxes
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III when more than 8 sections are present.
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:
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)[reply]
It's only a problem when using 'Automatic' (and OS is set to dark mode). The label looks as expected when the colour mode is set to 'Dark'. One would expect these two options to be the same, but no. I am seriously disappointed in the way Wikipedia is handling dark mode, everything is hacked together and there is zero guidance given to editors who run into these issues on the daily.
They ask us to report issues with dark mode to templates that have problems, but they don't tell anyone how to solve to problems. The people who make and fix templates clearly have no idea how dark mode should be implemented. -- Susko3 (talk) 03:18, 29 December 2024 (UTC)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)[reply]
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:
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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:
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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:
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
Edit request 11 October 2024
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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].
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Edit request 12 November 2024
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
As noted above in #Location labels unreadable in dark mode, the problem only occurs when the Color is set to Dark on this menu and the OS is set to dark mode. The labels look fine when Color is set to Dark on this menu. That means this problem has already been solved; the solution just needs to be duplicated for the automatic classes. -- Beland (talk) 01:03, 3 January 2025 (UTC)[reply]
Dark mode problem with image_map
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]
_-_The_Noun_Project.svg){kind=small}
