Jump to content

Template talk:Infobox settlement

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Location labels unreadable in dark mode

[edit]

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

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)[reply]
Unfortunately it has regressed again. The second CSS block should not apply as the parent div has class="notheme", but something is bugged.
It's a hack, but adding class="notheme" to every child div of the parent <div class="od notheme" fixes it. Would need a fix similar to what was done in Module_talk:Location_map#Edit_request_31_December_2023 -- Susko3 (talk) 02:46, 29 December 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]
There's plenty of technical advice at mw:Recommendations for night mode compatibility on Wikimedia wikis. -- Beland (talk) 22:27, 29 December 2024 (UTC)[reply]

using wikidata as fallback at least?

[edit]

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

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

[edit]

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]

Please get consensus for the change before proposing it. Sohom (talk) 04:26, 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]

Help with languages

[edit]

on the Kilacheri page the langauges (Tamil and Telugu) are not showing in the infobox. Drew Stanley (talk) 22:13, 14 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

[edit]

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]

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)[reply]
 Fixed --- I added nowrap to three infobox labels that were wrapping poorly. Now live. — hike395 (talk) 10:52, 19 November 2024 (UTC)[reply]

Labeled pushpin description unreadable on dark mode

[edit]

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

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

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]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_settlement&oldid=1286031274"