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]

Worrying trend on articles about Croatian coastal cities that were under occupation by Fascist Italy

[edit]

Hello, I am not sure if this is the right place to ask this or have this discussion, but maybe you can point me in the right direction if not.

On articles about Croatian, coastal cities that were occupied by fascist Italy after WWI and during WWII the infobox shows the Italian name for the city under the Croatian name for the city, see examples: Šibenik, Zadar, Split,_Croatia, Trogir, Pula, Opatija, Rovinj, and so on. Every Croatian city that used to be under Fascist Italy occupation has the Italian name right under the Croatian name.

The addition of the Italian name is justified by a single source (always a history book in Italian). According to the census in 2021 there are some ~13.000 Italians living in Croatia; they do not make up a significant minority and Italian is not an official language in Croatia. Also important to note that the Croatian wikipedia does not have Italian names in the infobox. Furthermore, since this is English wikipedia, the vast majority of readers won't know the city by the Italian name, but the infobox can actually do damage because it can make readers think that the Italian name is an acceptable other/alternative name for the city, when it absolutely is not.

I was able to successfully argue for the removal of the name from Rijeka, but to do this for every single settlement/city where this is an issue would be too time consuming. I am hoping for a solution that would have all the Italian names removed at once, and then those who wish to add the name can argue for its addition on the article's talk page.

Pinging editors who might be interested in this discussion since they discussed it on the talk pages of cities: @Ponor @LukeWiller TurboSuperA+ (☏) 08:16, 11 March 2025 (UTC)[reply]

You're attributing this all to the Fascist occupation, but Istria and Dalmatia were part of the Republic of Venice till almost the end of the 18th century. Are you sure that's not the reason for including the Italian names? I don't have a strong opinion on whether they should be included, but it would be good not to misattribute the reasons for them being there.
That said, this talk page is for discussion of the template, not its specific uses, so I think this is the wrong place. You might try notifying some Wikiprojects, say the ones for Croatia, Italy, and Geography. --Trovatore (talk) 05:00, 12 March 2025 (UTC)[reply]
"You're attributing this all to the Fascist occupation"
I assumed good faith on the part of the editor who changed them.
"Istria and Dalmatia were part of the Republic of Venice till almost the end of the 18th century. Are you sure that's not the reason for including the Italian names?"
Including a name that was used between the 15th and 18th century as a currently used "other name" is actually a bad faith edit, so if you think that's the reason I can just change them all without the need for this discussion. TurboSuperA+ (☏) 06:11, 12 March 2025 (UTC)[reply]
The optional parameter does seem to be "for places with other commonly used names like Bombay or Saigon". On English Wikipedia the other "commonly used names" are supposed to be the names (used) in English, not Mandarin, Italian, or Russian. Ponor (talk) 16:44, 12 March 2025 (UTC)[reply]
This really isn't the right place to discuss it.
That said — I had heard of Fiume. I had never heard of Rijeka. Now, the reasons I had heard of Fiume may have had to do with the Fascist era (or more likely, D'Annunzio's proto-fascist adventure beforehand), but that's irrelevant. I suspect "Fiume" is marginally more recognizable in English than "Rijeka". --Trovatore (talk) 21:24, 12 March 2025 (UTC)[reply]
Fiume is also the Italian word for "river", while rijeka is the Croatian word for it. When I type in Fiume into Google, I get results for D'Annunzio's "Free State of Fiume". If you type in Rijeka, you get the correct city.
The section on History discusses the historical names of the city, there's no reason to have the name feature prominently as an "other name" in the infobox.
In English-language articles, the city is referred to as "Rijeka", never Fiume. This holds for every Croatian city this topic is about (every city with Italian name as the "other name".
"the citizens of Croatian city Rijeka"[1]
"What exactly will emerge on the Rijeka slipways"[2]
Weather Underground weather report has the city as "Rijeka" and the weather station is called "Rijeka station".[3]
On Google Maps and openstreetmap it is "Rijeka", and so on.
There are no contemporary English or Croatian WP:RS that call the city anything but Rijeka. TurboSuperA+ (☏) 07:57, 13 March 2025 (UTC)[reply]
  1. ^ https://variety.com/2025/film/reviews/fiume-o-morte-review-1236301450/
  2. ^ https://total-croatia-news.com/news/business/australian-businessman-rijeka-3-maj-shipyard/
  3. ^ https://www.wunderground.com/forecast/hr/rijeka
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_settlement&oldid=1284579965"