Jump to content

Template talk:Infobox country

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

Gini colors and accessibility

[edit]

I have two concerns with how this template uses color in the Gini section. I've added a new set of testcases so y'all can try out my changes in the sandbox or experiment with alternatives. Once there's consensus for how to address these MOS:COLOR accessibility issues, I'll make a formal edit request.

Over-reliance on color (red vs green)

[edit]
High Kingdom
GiniNegative increase 90.0
very high inequality
Lowivia
GiniPositive decrease 15.0
low inequality

Using the distinction between red and green as the sole hint that "high is bad" is... not great. Even readers with full color vision are going to miss this sometimes. Few will click through to Gini coefficient, then resume reading the infobox understanding that Gini measures inequality and high means unequal.

The solution I'm trying is to use more descriptive category names, e.g. "high" becomes "high inequality". The category name is already on its own line, so there is enough space.

Gini may be an imperfect measure of inequality, but as long as we're including it and expressing its valence in colors, we might as well explain what it's trying to measure.

Low contrast (orange)

[edit]
Mediumland
Gini35.0
medium inequality

Orange on white-ish is hard to read due to low contrast.

So, what color could be used to indicate a neutral sentiment?

  • Darker orange – reads as brown to me, losing the "okayish" connotation that yellow/orange have when near green and red
  • Azure – fits with the change-indicator color scheme (Negative increase Steady Positive decrease), but looks more like a link than a sentiment
  • Gray (AA) – fits with the other change-indicator color scheme (Neutral increase Neutral decrease), used for the population row
  • Darker gray (AAA) – not distinct enough from black to indicate anything
  • No color – normal text, close to black

I'm trying the gray, even though we usually aim for AAA-level contrast in templates. Jruderman (talk) 12:38, 20 July 2024 (UTC)[reply]

Template-protected edit request: Gini text and color changes for accessibility

[edit]

Looks like my section on Gini colors and accessibility didn't get a lot of discussion, so I'm going ahead with a formal edit request.

Please apply my changes in the sandbox (without the other sandbox differences before my changes). That is, change the orange to the shade of grey I chose, and add the word "inequality" to each descriptor.

You can apply similar changes to the "development index" row too (keeping in mind that higher is good for this one). Or we can leave that for later; IMO gini is more confusing and more important.

Thanks, Jruderman (talk) 15:08, 6 August 2024 (UTC)[reply]

I have synchronised the sandbox and reapplied your changes. Please confirm these are ready to go — Martin (MSGJ · talk) 21:14, 11 August 2024 (UTC)[reply]
Sandbox diff and testcases both look good. Thanks! Jruderman (talk) 21:34, 11 August 2024 (UTC)[reply]
 Done — Martin (MSGJ · talk) 21:48, 11 August 2024 (UTC)[reply]

Changes to formatting of info in this template

[edit]

Recently some changes to formatting were added- looking at the INDIA page there are changes such as President and whatever other data having bullet points, as well as Dominion/Republic in the Independence subsection being in their own rows in a table. The Population title is centred, but the GDP sections wouldn't fall under this Population section but it looks like it does too.


I don't know when these were added as I'm pretty sure that formatting changes are added elsewhere, but they look the data look clumpy in my opinion. I think that the format changes should be reverted, but what do you think? Karnataka 07:55, 6 August 2024 (UTC)[reply]

Param flag_border, subtemplate /imagetable, and template styles

[edit]
People's Democratic Republic of Algeria
الجمهورية الجزائرية الديمقراطية الشعبية (Arabic)
ISO 3166 codeDZ

Hi, Izno, thanks for this edit adding template styles. I have a question about how the code continues to use inline style, in particular in subtemplate {{Infobox country/imagetable}}.

This arose because I was having trouble separating out the edges of the flag image against the Infobox background at Algeria, because the flag is half white, and the Infobox bg color is #f8f9fa, near enough to white that I can't easily distinguish it (even with the faint border) especially if my laptop screen isn't perfectly oriented, as it tends to wash out faint colors.

I started to look at the code to see if I could add user-configurable flag border style, so I could darken it a bit more at Algeria, and at other country articles whose flags have some white near an edge. I discovered param |flag_border= in the code, but it's just a yes-no param, and ends up as a param to Module:InfoboxImage, and it's surrounded by a lot of squirrely code that was way more than I felt like dealing with:

Excerpt of Infobox country code snippet for param 'image1', using /imagetable:
| image1 = {{#if:{{{image_coat|}}}{{{image_symbol|}}}{{{image_flag|}}}{{{image_flag2|}}}
  |{{infobox country/imagetable
    |image1a = {{#invoke:InfoboxImage|InfoboxImage|suppressplaceholder={{main other||no}}|image={{{image_flag|}}}|sizedefault=125px|size={{{flag_width|{{{flag_size|}}}}}}|maxsize=250|border={{yesno |{{{flag_border|}}}|yes=yes|blank=yes}}|alt={{{alt_flag|{{{flag_alt|}}}}}}|title=Flag of {{{common_name|{{{name|{{{linking_name|{{PAGENAME}}}}}}}}}}}}}
    |image1b = {{#invoke:InfoboxImage|InfoboxImage|suppressplaceholder={{main other||no}}|image={{{image_flag2|}}}|sizedefault=125px|size={{{flag_width|}}}|maxsize=250|border={{yesno |{{{flag2_border|}}}|yes=yes|blank=yes}}|alt={{{alt_flag2|{{{flag_alt2|}}}}}}}}
    |caption1= {{#ifexist:{{if empty |{{{flag_type_article|}}} |{{{flag|}}} | {{if empty |{{{flag_type|}}} |Flag}} of {{if empty |{{{linking_name|}}} |{{{common_name|}}} |{{{name|}}} |{{PAGENAME}} }} }} |[[{{if empty |{{{flag_type_article|}}} |{{{flag|}}} |{{if empty |{{{flag_type|}}} |Flag}} of {{if empty |{{{linking_name|}}} |{{{common_name|}}} |{{{name|}}} |{{PAGENAME}} }} }}|{{if empty |{{{flag_caption|}}} |{{{flag_type|}}} |Flag}}]] |{{if empty |{{{flag_caption|}}} |{{{flag_type|}}} |Flag}} }}
    |image2  = {{#invoke:InfoboxImage|InfoboxImage|suppressplaceholder={{main other||no}}|image={{if empty|{{{image_coat|}}}|{{{image_symbol|}}}}} |size={{{symbol_width|{{{coa_size|}}}}}}|sizedefault=85px|alt={{#if:{{{image_coat|}}}|{{{alt_coat|{{{coat_alt|}}}}}}|{{{alt_symbol|}}}}}|title={{{symbol_type|Coat of arms}}} of {{{common_name|{{{name|{{{linking_name|{{PAGENAME}}}}}}}}}}}}}
    |caption2= {{#ifexist:{{if empty |{{{symbol_type_article|}}} |{{{symbol|}}} |{{if empty |{{{symbol_type|}}} |Coat of arms}} of {{if empty |{{{linking_name|}}} |{{{common_name|}}} |{{{name|}}} |{{PAGENAME}} }} }} |[[{{if empty |{{{symbol_type_article|}}} |{{{symbol|}}} |{{if empty |{{{symbol_type|}}} |Coat of arms}} of {{if empty |{{{linking_name|}}} |{{{common_name|}}} |{{{name|}}} |{{PAGENAME}} }} }} | {{if empty |{{{symbol_type|}}} |Coat of arms}}]] |{{if empty |{{{symbol_type|}}} |Coat of arms}} }}
    }} }}
#invoke: InfoboxImage pretty-printed
{{#invoke:InfoboxImage|InfoboxImage
  |suppressplaceholder={{main other||no}}
  |image={{{image_flag|}}}
  |sizedefault=125px
  |size={{{flag_width|{{{flag_size|}}}}}}
  |maxsize=250
  |border={{yesno |{{{flag_border|}}}|yes=yes|blank=yes}}
  |alt={{{alt_flag|{{{flag_alt|}}}}}}
  |title=Flag of {{{common_name|{{{name|{{{linking_name|{{PAGENAME}}}}}}}}}}}
}}

so I just dropped the whole idea of adding configurable flag border style, and I'm okay with that.

But I noticed that the code transcludes {{infobox country/imagetable}}, and that's where you come in (if you're willing) because that entire subtemplate is pure in-line style that probably should be using classes in the /styles page instead. If you decide to take that on, and you happen to see some kind of easy win for flag_border being more than just a yesno so I could style it, that would be nice, too, but not a must-have, so please don't lose any sleep over it. Thanks, Mathglot (talk) 03:19, 17 August 2024 (UTC)[reply]

I was having trouble separating out the edges of the flag image against the Infobox background at Algeria, because the flag is half white, and the Infobox bg color is #f8f9fa I agree, that's pretty rough (and I'd guess most white flags suffer this issue in light mode). I think this would be pretty easy to fix if you marked up the container for the flag with a class, added a one liner to override
@media screen { .mw-image-border .mw-file-element { border: 1px solid #eaecf0; }}
and then added some sort of boolean parameter to turn that class on. The issue you would run into (if you consider it one) is that you would want one such parameter per image...
As for the matter of the subpage, yeah, one could add those to that styles page without too much thought. It's used on most of the pages the root template is used on, so you're probably not spending too much budget of a sort on it without good cause. Try syncing (decide if it's worth syncing) + modifying the /imagetable sandbox and a templatestyles sandbox and I can check your work. Izno (talk) 16:32, 17 August 2024 (UTC)[reply]
Thanks; am considering all this and looking into understanding the code better. (Also, I added a rump version of the Algeria Infobox showing the flag in context; also added a pretty-printed sub-snippet to the collapsed portion.) Mathglot (talk) 18:27, 17 August 2024 (UTC)[reply]
Please specify the border-width as "thin" instead of "1px". I've found that pixel widths can become uneven or even disappear when using the zoom feature of desktop web browsers. Jruderman (talk) 21:37, 17 August 2024 (UTC)[reply]
The keywords can likewise render inconsistently between browsers (we've found this to be true for the font-size keywords, to say nothing of font-weight: bold). Someone always pays a price. Izno (talk) 21:44, 17 August 2024 (UTC)[reply]
I'll take inconsistency between browsers over inconsistency between left/right/top/bottom :) — Jruderman (talk) 21:47, 17 August 2024 (UTC)[reply]
I haven't finished my analysis yet, but I'm not sure any of these suggestions are going to work. All of them end up with a [[File:Flag of Algeria.svg|125px|border|Flag of Algeria]] (either with, or without the 'border' param, depending on the presence/absence of |flag_border= in the infobox), and that syntax does not allow any value for border. The generated html will have a <td> with class="infobox-image", and under that three nested div's, and a <span class="mw-image-border" typeof="mw:File"> in the |flag_border=yes case, and I don't see a way around this without altering the syntax of File. Unless maybe a local Template style could override the value of class mw-image-border, but even then, I don't see how it could attach border style to the image; perhaps with a before:: element, but not sure if that would work. Here's a snippet of the generated Html:
Generated Html for the flag in the Infobox_country
<tr><td colspan="2" class="infobox-image">
<div class="noresize" style="display:table; width:100%;">
  <div style="display:table-cell; vertical-align:middle; padding-left:5px;">
    <div style="padding-bottom:3px;">
      <span class="mw-image-border" typeof="mw:File">
        <a href="/https/en.wikipedia.org/wiki/File:Flag_of_Algeria.svg" class="mw-file-description" title="Flag of Algeria">
          <img alt="Flag of Algeria" src="//upload.wikimedia.org/wikipedia/commons/thumb/7/77/Flag_of_Algeria.svg/125px-Flag_of_Algeria.svg.png" decoding="async" width="125" height="83" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/7/77/Flag_of_Algeria.svg/188px-Flag_of_Algeria.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/7/77/Flag_of_Algeria.svg/250px-Flag_of_Algeria.svg.png 2x" data-file-width="900" data-file-height="600" />
        </a>
      </span>
    </div>
  <div>
    <a href="/https/en.wikipedia.org/wiki/Flag_of_Algeria" title="Flag of Algeria">Flag</a>
  </div>
</div>
The only place I could find class mw-image-border was MediaWiki:Gadget-NewImageThumb.css, but that doesn't seem like where it's getting it from. More later. Mathglot (talk) 22:25, 17 August 2024 (UTC)[reply]
Templates can add scoped CSS, right? So we should be able to keep the nice syntax. Jruderman (talk) 23:37, 17 August 2024 (UTC)[reply]
Yeah try “Wikipedia:TemplateStylesJruderman (talk) 23:41, 17 August 2024 (UTC)[reply]
This template has one (more style here) and that's been discussed above. I think we are circling back to Izno's original suggestion, and that is the first approach to try. Mathglot (talk) 00:17, 18 August 2024 (UTC)[reply]

Driving side → Drives on

[edit]

I have amended the template so it says "Drives on" instead of "Driving side". This is for clarity. "Driving side" is often understood to mean the side the driver sits in a car, while "drives on" is understood to mean the side of the road the car is driven on. I have noted, as in Talk:Sri Lanka, that using "Driving side" can lead to confusion. SilkTork (talk) 15:26, 25 August 2024 (UTC)[reply]

I object, gently. Countries don't drive, so "drives on" strikes me as wrong. I suggest restoring "Driving side" and linking it to Left- and right-hand traffic to make it clear that the words refer to the flow of traffic rather than the position of the driver. – Jonesey95 (talk) 13:28, 26 August 2024 (UTC)[reply]
I agree that there is an ambiguity as well as with your objection. Perhaps "Side of road"? Largoplazo (talk) 13:57, 26 August 2024 (UTC)[reply]

Here are four possibilities that avoid the ambiguity in various ways:

Traffic side Left
Traffic Drives on the left
Drive on Left side of the road
Driving Left side of the road

(Based on skimming the list of redirects to the article Left- and right-hand traffic)

— Jruderman (talk) 23:33, 26 August 2024 (UTC)[reply]

'Drive/s on' is a phrasal verb meaning to continue driving. The intent here is drives 'on (the left/right side of the road)', with drive not being a phrasal verb, and some words missing because most English speakers know what is meant, but not all. I think the problem is we need another word or two to make the parameter clear and unambiguousl and grammatically correct, and I think we should avoid links to show what is meant. Something like "Traffic drives on what side?" IMO, this parameter is far more useful that many of the parameters used. Roger 8 Roger (talk) 10:32, 27 August 2024 (UTC)[reply]
Good point about 'drive on' as a phrasal verb. Maybe this problem could be avoided by adding "the", as in "Drive on the ... left" or "Drive on the ... left side of the road". — Jruderman (talk) 21:37, 27 August 2024 (UTC)[reply]

Dark mode problems

[edit]

For {{infobox former country}}, the "Preceded by" and "Succeeded by" text generated from Template:Infobox country/formernext is showing up as black text on black background when I have dark mode enabled in my preferences. (By "black" I mean "rgb(32, 33, 34)".) The CSS is a bit tangled, so I'm not exactly sure how to fix this without doing a lot of research. In case it's helpful, there are recommended fixes at mw:Recommendations for night mode compatibility on Wikimedia wikis. -- Beland (talk) 17:42, 2 September 2024 (UTC)[reply]

An example article where this shows up is French Fourth Republic. -- Beland (talk) 17:43, 2 September 2024 (UTC)[reply]
Thank you for providing a link to an example article. It is always troublesome to try to track down an example. I think I have fixed this problem. Feel free to ping me if this edit broke something else. – Jonesey95 (talk) 21:53, 3 September 2024 (UTC)[reply]
Looks good from here, and hey, that was a lot simpler than I was imagining. Thanks for the quick fix! -- Beland (talk) 00:51, 4 September 2024 (UTC)[reply]

Empty rows

[edit]

Someone reported an issue, where there are additional lines below subheadings on the page United Kingdom. This is because the template adds empty rows. Empty rows are an accessibility issue and when the styling doesn't take them into account, they also cause visual effects like these. —TheDJ (talkcontribs) 10:24, 4 September 2024 (UTC)[reply]

What is |native_name= for?

[edit]

Recently, I started an RfC at Talk:Silla concerning a class of use cases for this infobox's |native_name= parameter. The current guidance is Country's name (usually full name) in its official/defacto language(s)—I think this could stand to be made significantly more clear. For the example above, Hangul has customarily been included alongside Hanja to render the native_name of Korean states, even those that existed before that writing system was invented in the mid-15th century. I think this matters: obviously the Hangul rendering is important to those articles, but I cannot help but see it as incredibly misleading to use it in this particular parameter unless its semantics are clarified. Orthography and language do not have a simple relationship in cases like these, and what script we use to render historical languages alongside romanizations matters, I think. Remsense ‥  02:31, 19 September 2024 (UTC)[reply]

Is Template:Infobox settlement#Parameter names and descriptions more clear? Moxy🍁 02:47, 19 September 2024 (UTC)[reply]
Not at all, honestly. related to de facto language that is not English helps very little. Remsense ‥  02:49, 19 September 2024 (UTC)[reply]
Perhaps we should be giving some examples here.....like .Moscow vs Москва or Egypt vs Jumhūrīyat Miṣr al-ʻArabīyah. It's not a place to spam random translations.... It's about official language usage related to the native language of the country.Moxy🍁 03:01, 19 September 2024 (UTC)[reply]
I think it's merely about official use—in this case (it's complicated) the official written language wasn't straightforwardly Korean, but Literary Chinese, though the nature of the non-phonetic script renders it identically either way and since officials didn't really speak Chinese but instead used a system of readings to "translate" written Chinese into spoken Korean...it's complicated! Hence why I think orthography can't just be considered part and parcel with language. Remsense ‥  03:06, 19 September 2024 (UTC)[reply]
If something is not straightforward it shouldn't be in the lead/infobox at all but in the Etymology or History section where we can explain to our readers... WP:COUNTRYLEAD. Moxy🍁 03:19, 19 September 2024 (UTC)[reply]
I would agree. I wouldn't categorically consider this unduly complex as such, as long as the parameter is used consistently across the site. Remsense ‥  03:20, 19 September 2024 (UTC)[reply]
I suppose the sensical standard to me would be something like the country's name as rendered in official use by said country – official/defacto makes me gag a bit, as editors continue to lack understanding of what "official" plainly means (used in official contexts, regardless of any codification or proclamation to that effect). Remsense ‥  03:03, 19 September 2024 (UTC)[reply]
That sounds like a reasonable change. Let's give it a few days... if no one else chimes in ...I will change it. Moxy🍁 03:06, 19 September 2024 (UTC)[reply]
I also agree with this change for the sake of clarity. It might not fully solve the dispute that brought it forth, but at least it will provide more guidance on future cases. Qiushufang (talk) 06:43, 19 September 2024 (UTC)[reply]
Pinging @00101984hjw, @Pathawi, @User:Sunnyediting99, and @Qiushufang as those whose opinions diverged from mine in the RfC so they can have ample opportunity to articulate any issues they see with this. Remsense ‥  03:10, 19 September 2024 (UTC)[reply]
To be clear, I don't think my opinion actually differed from yours in the specific case: Given the options, I was in favour of solely literary Chinese to the exclusion of the proposed Hangeul for Silla, as you proposed. I entertained the possibility of other Hangeul representing the pronunciation in the period in question, but this wasn't at issue in the RFC. The primary thing I suggested was a conversation at this Talk page to make sure that whatever decision was made would be consistent across instances of this Infobox. I don't really have an opinion about what the outcome should be: I'll be happy with anything that minimally includes written forms employed at the time by the state itself. Thanks for pinging me—good process. Pathawi (talk) 03:22, 19 September 2024 (UTC)[reply]
Silla Would be an example of what not to do..... that is multiple side bars... including language translation.... link spam sidebars are a scrolling nightmare on mobile view that's why they're discouraged WP:LEADSIDEBAR. Moxy🍁 03:29, 19 September 2024 (UTC)[reply]
I tend to see {{Infobox Chinese}} alongside main and topic infoboxes as "maximum acceptable clutter", though that article has more atop that. Remsense ‥  03:32, 19 September 2024 (UTC)[reply]
Those types of template are a problem across multiple articles..... should not be in the lead unless the article is about language(s). Basically useless to our English readers and if it's that important to an article it should be in prose text with pronunciations etc.....like China that does not use the template at all instead uses prose text and should be the example that sub articles use. Moxy🍁 03:44, 19 September 2024 (UTC)[reply]
I'm not sure to what extent you are familiar, but I humbly but strongly disagree in this specific case: it's genuinely of significant encyclopedic value in this specific language area (i.e. the Sinosphere); the language situation necessitates it in lieu of a horrific screen-filling etymology section having to plague many articles. I try to fold it into the primary infobox when I can.Remsense ‥  03:47, 19 September 2024 (UTC)[reply]
I don't disagree, but this is a separate issue from how the field within the infobox should be used. Pathawi (talk) 03:41, 19 September 2024 (UTC)[reply]
I think the simplest way to deal with the ibx problems highlight is to start by creating an unambiguous definition of what 'official' means in use on wikipedia (which might differ from a dictionary definition) This is because 'official' has two meanings and we should use only one for the sake of practicality. If we don't, all these other ibx problems will continue. Oh, and once that is dine we can do the same for 'national', which can also be ambiguous. Roger 8 Roger (talk) 04:51, 19 September 2024 (UTC)[reply]
"Official" has one meaning (used by officials, in the official capacity of governance), it's just that editors are perennially confused about it for some reason. Remsense ‥  04:59, 19 September 2024 (UTC)[reply]
Proposal seems reasonable to me. I'd assume here that "rendered" means "printed or written on formal documents"?
As someone of Korean ethnicity I'd admit that I have an inherent bias for the inclusion of Hangul. But I guess consensus is consensus. -- 00101984hjw (talk) 00:14, 24 September 2024 (UTC)[reply]
Agree on clarification to prevent future problems and hopefully provide clarity and precedence on future cases. To reiterate the current contention surrounding Silla and other Korean polity infoboxes, these historical polities did not use the modern phonetic Korean writing system known as Hangul, which was officially adopted in 1894. Prior to this, official Korean documents were written in Hanja, or literary Chinese, which was not a phonetic system. Users have been battling it out on these country article infoboxes on whether to use only Hanja, only Hangul, both, and in which order they should be listed in for the native name, for years now. I saw including both as the most convenient compromise and that was the version which I tried to restore to, with the Hanja listed first. Qiushufang (talk) 06:09, 19 September 2024 (UTC)[reply]
This isn't my primary concern here, but if the semantics were clarified here, would you see a change across those articles as more appropriate? Given your description, I guess it's hard not to see the situation as "compromise to stop the fighting" rather than "compromise because it's correct". It's easy for me to say, but I'm compelled to reject that reasoning. There's no reason those with weaker arguments should get to dictate content here or anywhere on the site. Remsense ‥  06:10, 19 September 2024 (UTC)[reply]
A problem is that there is no consistent template for all country infoboxes. Roman Empire has no native name in the native orthography. Macedonia (ancient kingdom) has native name in Greek. Dali Kingdom has both Chinese characters and an English transcription. Đại Việt has Chinese characters but the modern Vietnamese transcription before it. I think any clarification could be used to justify changes across all these articles. But one possibility is that users will just use the precedence of articles with no native name in the infobox to remove whatever representation of the native name is decided to be the most appropriate. Qiushufang (talk) 06:16, 19 September 2024 (UTC)[reply]
I'm not quite understanding the concern, if it's accepted that the parameter is optional and that romanizations are generally expected for non-Latin scripts like elsewhere in articles. Remsense ‥  06:19, 19 September 2024 (UTC)[reply]
@User:Remsense Dictionaries will give two versions, one being use in what is considered a formal manner, ie de facto, and another one made official by some sort of formal document, ie de jure. I prefer your interpretation which is a form of the first version, but to say the second interpretation is wrong is for me a step too far. Try telling that to the Americans who insist that the USA does not have an official language despite the widespread use of English everywhere. Roger 8 Roger (talk) 06:29, 19 September 2024 (UTC)[reply]
Because the parameter is optional, if either Hangul or Hanja become the only native name, the other side will just delete it based on the fact that it is optional. Other users can obviously just revert, and given strong enough deterrence such as page protection and whatnot, I can see it becoming a more permanent change. But the conflict is modern and political in nature, and not due mainly to the lack of clear guidance, although that plays a part, and there is no consistent precedence in country articles anyways. So whatever decision is made here should ideally provide further guidance, as that conflict is the real issue at hand, and not the lack of guidance. I think most will agree than Hanja was the official writing system, but you could also argue that did not represent the language since it wasn't spoken. Basically, there are other ways to argue for the inclusion of Hangul or exclusion of Hanja that based on the definition of "official", and as Roger points out, there is no official language in the US despite the predominance of English. Qiushufang (talk) 06:33, 19 September 2024 (UTC)[reply]
The official language in the US on the federal level and in all 50 states is English, because that's the language of governance. Some states happen to have fancy pieces of paper stating that this is the case. The colloquial "simply having the piece of paper" meaning is vapid without relation to the actual meaning. As for Silla, per Moxy I see not having the parameter to be a perfectly acceptable outcome, as explaining the language situation is non-trivial. Remsense ‥  06:58, 19 September 2024 (UTC)[reply]
All of this comes down to user maintenance. Whether the outcome is Hanja only or nothing at all, it still comes down to how many users are interested in upkeeping that state. Otherwise it'll just be some rando reinstating Hanja or Hangul two months down the line while no one is paying attention, and somebody will have to reiterate whatever the reasoning is for why things are the way they are while other articles have native name listed. The whole point of further clarity imo is so that this doesn't happen. If we're just going to have an entire section on the orthography of the name to the exclusion of a native name, that's still just a compromise, same as with listing both Hanja and Hangul as native name. Qiushufang (talk) 07:34, 19 September 2024 (UTC)[reply]
Don't I know it—Iunno, I think it matters what our baseline is too, though I fully understand the cynicism. Remsense ‥  08:12, 19 September 2024 (UTC)[reply]
I'm not really convinced on the argument that because "X was used during this time period while Y wasn't means that Y should be excluded" similar to @Roger 8 Roger's argument. Tons of Wikipedian articles (And academic perceptions of it) are guided by modern influences. A good example is how the Wikipedia page for the Byzantine Empire calls it the Byzantine Empire or Eastern Roman Empire even though it never once called itself that in any official capacity (instead calling itself the Roman Empire). Silla again is another example, it didn't officially adopt the name until much later in its existence. Modern perceptions of the state are as much a part of the infoboxes as are the perceptions of the state during the time it existed. And again, the infoboxes do mention that Hanja was the literary language of the time, while Old Korean didn't have a literary equivalent yet it was the dominant spoken language of the time. Sunnyediting99 (talk) 13:15, 19 September 2024 (UTC)[reply]
But Byzantine Empire specifically doesn't use this parameter in particular because it's too complicated an aspect of the state's history to be adequately communicated in the infobox! Remsense ‥  13:28, 19 September 2024 (UTC)[reply]
I'm interested in User:Remsense's definition of official and reconciling it with reality. To use one example, are you saying that a 1987 statute that says Maori is an official language of NZ when used in defined situations such as parliament and the courts (official sitations) - which thereby enable it to be used in those situations uncontested - is of no effect unless Maori is actually used in those situations. If so, that would explain another part of the act that compels official bodies to promote Maori by using it, which usually is done through such things as bilingual publications and randomly adding Maori words into English texts. That would mean, I think, that the 1987 NZ act and many others like it around the world that make a language 'official', are conditional on the actual use of a language in an official capacity. Sorry if this isn't directly about Korea but I think it's quite important. Roger 8 Roger (talk) 01:48, 24 September 2024 (UTC)[reply]

a 1987 statute that says Maori is an official language of NZ when used in defined situations such as parliament and the courts (official sitations) - which thereby enable it to be used in those situations uncontested - is of no effect unless Maori is actually used in those situations.

Yes. In these situations, it's usually worth noting those laws exist (people love clutter about de facto/de jure distinctions, but I think noting a de jure official status is potentially worthwhile here.) Of course, we can only dispute a language's status as being merely de jure official if there's adequate sourcing to that effect. Remsense ‥  01:52, 24 September 2024 (UTC)[reply]
The distinctions about de jure and de facto official languages that have spread through Wikipedia are not as clear as usually presented either. The Māori Language Act 1987 mentioned above takes the use of English to be the alternative default, despite there being no similar legislation for English. This situation is even more clear in UK legislation on the Welsh language, where Welsh and English "should be treated on a basis of equality"[1][2]. CMD (talk) 02:16, 24 September 2024 (UTC)[reply]
Of course. With many things, we should aim for parsimony when we can get it, but not ignoring what sources are obviously saying. Remsense ‥  02:36, 24 September 2024 (UTC)[reply]
Thank you Remsence for this interpretation and reasoning steps that clarifies the 'official language' problem that plagues many articles. It aligns with what I have always thought but never been able to express it succinctly. I will bring it up at the NZ article later and possibly elsewhere and will refer to this page. Roger 8 Roger (talk) 23:31, 24 September 2024 (UTC)[reply]
Thank you! But also, I hope I didn't sound too confident! Remsense ‥  23:55, 24 September 2024 (UTC)[reply]

Request for comment on greenhouse emissions

[edit]

Should the infobox template for countries be expanded to include greenhouse gas emissions? 20WattSphere (talk) 11:56, 27 September 2024 (UTC)[reply]

previous talk Template_talk:Infobox_country/Archive_15#Greenhouse_gas_emissionsMoxy🍁 12:00, 27 September 2024 (UTC)[reply]
Context: Editors have discussed the proposal but without forming a consensus (recent discussions are archived at the bottom of Template talk:Infobox country/Archive 15, with a discussion from 2023 at the top). There was also a question about which measure to consider (e.g. total, or per capita) - comments on this are welcome but this RfC focuses on the central question of whether to include at least one measure. 20WattSphere (talk) 12:03, 27 September 2024 (UTC)[reply]
Unless I missed it the climate change project was not notified about the previous discussions otherwise I would have commented there about which measure Chidgk1 (talk) 17:06, 3 October 2024 (UTC)[reply]
I'm conflicted: as GDP and GNI are meant to be figures of general interest regarding the economic development of a polity, I also think it's worth potentially representing other material dimensions if adequately DUE per concerns in the previous RFC—I guess we can just label this one "environment" broadly construed. The stumbling block for me is, while emissions are a major figure point for this dimension of analysis—probably easily the most frequently cited—due to the scope of "the environment" as a subject, it almost seems insufficiently narrow? Myriad other figures regarding pollution, deforestation, reclamation, and so on seem potentially more informative in many cases, this is unlikely to be a one-size-fits-all situation. Perhaps we could allocate generic "environmentN" parameters we can specify based on what is notable for each polity? Remsense ‥  12:06, 27 September 2024 (UTC)[reply]
My main problem is the articles dont cover this topic in prose (infobox should duplicate data in article)...thus is just a number out of the blue with zero context for readers. Moxy🍁 12:37, 27 September 2024 (UTC)[reply]
I agree that for many countries this is not a significant topic and the parameter need not be filled in the infobox or discussed in the article. However for some countries it is significant. For example China says “With current policies, the GHG emissions of China will probably peak in 2025, and by 2030 they will return to 2022 levels. However, such pathway still leads to three-degree temperature rise.” and United States “The U.S. ranks as the second-highest emitter of greenhouse gases.” Chidgk1 (talk) 07:26, 28 September 2024 (UTC)[reply]
But how would you design a parameter to meaningfully convey both of those approaches to data on this topic? Nikkimaria (talk) 14:42, 28 September 2024 (UTC)[reply]
@Nikkimaria Sorry I don’t quite understand your question Chidgk1 (talk) 15:18, 29 September 2024 (UTC)[reply]
You have presented two emissions-related claims in country articles. What singular parameter would reflect both of those claims? Nikkimaria (talk) 15:38, 29 September 2024 (UTC)[reply]
I understand this proposal is about the general principle rather than a specific parameter. However if this proposal is accepted then as I detailed below the CO2e annual totals estimated by the countries themselves (these are production-based and can omit the military) would be my preference. Whether the body of the article should also mention that number I don’t know - I suspect not - for example United States has the Gini coefficient in the infobox but in the body it says “Income inequality in the U.S. remains at record highs, with the top fifth of earners taking home more than half of all income and giving the U.S. one of the widest income distributions among OECD members.” rather than mentioning the number itself. I don’t know how this works procedurally in Wikipedia - perhaps we will have another discussion about the actual parameter if this proposal is accepted? Then if some people argue for a ranking parameter or a consumption based one I will consider what they say. Chidgk1 (talk) 15:28, 3 October 2024 (UTC)[reply]
The USA article is an oddball.... for example human rights is in the lead... but every G20 country exceeds them including 20 more 3rd world countries. Moxy🍁 00:16, 11 October 2024 (UTC)[reply]
This depends on the composition of a country's economy and, in my view, is not an essential part of a country. If used, both proudction and consumption based numbers should be accounted for. Senorangel (talk) 04:40, 28 September 2024 (UTC)[reply]
But if I understand right the consumption-based accounting numbers we have don’t include land use, land-use change, and forestry. So they would be misleading I think. Chidgk1 (talk) 16:40, 3 October 2024 (UTC)[reply]
They will be accounted for at the consumer end. Users of raw materials or agriculture and paper products, for example. Senorangel (talk) 05:36, 5 October 2024 (UTC)[reply]
@Senorangel I think I have a rough idea of the theory but as far as I know we don’t have a reliable source of such numbers. No doubt someone will estimate Drax https://www.edie.net/drax-labelled-uks-biggest-carbon-polluter-as-biomass-row-rages-on/ but that is just one biomass power plant. For example I doubt anyone has much clue how much lumber is being sent from Russia to China and how much is being burnt. Chidgk1 (talk) 09:32, 5 October 2024 (UTC)[reply]
  • Support Important for some countries Chidgk1 (talk) 12:34, 27 September 2024 (UTC)[reply]
  • Oppose I might be open to hearing the case from first principles on a personal basis, but there are a few issues with this. The infobox is supposed to reflect the article. Often infoboxes do not do this for various reasons, but it's worth keeping in mind. Few country articles discuss emissions (noted by Moxy). Those that do tend not to put a figure on it. The uncommon mention suggests it is not considered a key fact in country coverage. The lack of numbers speaks to a broader issue, it is difficult to measure GHG emissions. There are a few ways to do it, with different assumptions, and you can get some very defensible figures that converge on the right ballpark, but presumably the infobox figure is going to be a specific number and I'm not sure any one number is due that weight. CMD (talk) 13:10, 27 September 2024 (UTC)[reply]
    For all the countries party to the Paris Agreement the number would be their own officially calculated CO2e total in their Biennial Transparency Reports. Only a handful of countries are not parties, and as far as I remember the only significant one is Iran for which we would have to use an estimate such as from Climate Trace. Chidgk1 (talk) 05:54, 28 September 2024 (UTC)[reply]
    It's possible ETF submissions will become 'the number' for GHGs, but we can't judge that now. CMD (talk) 06:18, 28 September 2024 (UTC)[reply]
    It is true that at first there will be large error bars, perhaps from poor countries with big forests. But in principle they are the same numbers that were agreed in Paris in 2015 and have been reported by rich countries for many years. So there is no way the world would agree on a different GHG accounting method however much any of us might like it to. Chidgk1 (talk) 06:38, 28 September 2024 (UTC)[reply]
  • Oppose. There are lots of major problems that countries face -- nuclear stockpile, number of incarcerated residents, number of impoverished residents. All these things should be discussed in the article, but we should keep infoboxes concise. Indeed, we should be considering what we can remove from infoboxes which are, by necessity, redundant, as they are restating facts that should already be stated and referenced in the article. -- Ssilvers (talk) 18:31, 27 September 2024 (UTC)[reply]
    I agree that not everything in the infobox template needs to be filled in for every country. For example many countries don’t have “Coat of arms” or “national motto”, but they are available in the template in case they are important for certain countries and editors wish to fill them in. Chidgk1 (talk) 06:47, 28 September 2024 (UTC)[reply]
  • Support in principle, as it is valuable information for the reader. Per capita seems like the better option since population data is also in the Infobox. It should have a ranking as well like in the population parameters. Alternatively you could have the total figure, and something like (per capita: 6th)
Kowal2701 (talk) 14:16, 2 October 2024 (UTC)[reply]
On the point that climate change isn’t generally mentioned in articles, I’m surprised at that. I’d expect at least a few sentences in the body Kowal2701 (talk) 17:31, 3 October 2024 (UTC)[reply]
  • Procedural question Should I be arguing about the specific parameter here or are we only discussing the principle of adding GHG? Chidgk1 (talk) 15:35, 3 October 2024 (UTC)[reply]
    Sorry, I think I was wrong to open discussion to that. Kowal2701 (talk) 17:03, 3 October 2024 (UTC)[reply]
    No probs - I am happy discussing the measurements here if the proposer @20WattSphere wants to as I missed the previous discussions. Chidgk1 (talk) 17:10, 3 October 2024 (UTC)[reply]
    Previously, I was thinking it would be best to begin by deciding on the question of having any climate indicators in the infobox. Then after that decision, nail down which indicator would be best.
    However, much of the opposition has stemmed from confusion about the measurement. Because of this I think it makes sense to discuss which indicators to use, to inform the overall discussion.
    I would support total national emissions CO2e, and per capita emissions in CO2e. 20WattSphere (talk) 06:56, 5 October 2024 (UTC)[reply]
  • Comment If this proposal is accepted “year cited” is essential because countries suffering from war or extreme poverty will be allowed to report later than other countries Chidgk1 (talk) 17:00, 3 October 2024 (UTC)[reply]
  • Leaning no. While I'm open to including climate-related statistics, I'd like to see a more fleshed-out proposal with answers to questions like
  • Are we including absolute or per capita values?
  • What sources should be used? Biennial transparency reports have been mentioned, I also found EDGAR database and globalCarbon Atlas. Do they differ and which one should we prefer?
  • Production or consumption emissions?
I realise that some of these issues have been discussed and possibly resolved in this thread and I suggest opening another RfC taking into account the feedback. Alaexis¿question? 21:39, 5 October 2024 (UTC)[reply]
Re sources I am against using the Emissions Database for Global Atmospheric Research as it does not include Land Use, land Use Change and Forestry. Methodology of the second source you mention, global carbon atlas, is described in https://essd.copernicus.org/articles/15/5301/2023/. Although that and Climate Trace are more up to date I would prefer to use official figures to avoid argument. After all if a country calculated the figures themselves they cannot later argue that Wikipedia is wrong. Having said that I don’t object to using unofficial figures for those countries which have not yet published official figures. Chidgk1 (talk) 14:54, 7 October 2024 (UTC)[reply]
@Alaexis As of 2021 consumption for land don’t seem to be available https://www.oecd-ilibrary.org/docserver/b2b24307-en.pdf
therefore unless anyone can find consumption figures including land I am against including consumption Chidgk1 (talk) 08:44, 8 October 2024 (UTC)[reply]
@Chidgk1, do these sources differ a lot? If they do we can expect arguments over which data to use and it may be better to discuss these figures in the article text where they can be put in context.
Also, you haven't responded to my 1st and 3rd questions. Alaexis¿question? 19:56, 9 October 2024 (UTC)[reply]
@AlaexisI think we should have absolute production values but I don’t have an opinion on whether we should have per capita production values as well. Re your question whether those 2 sources differ a lot I don’t care as I think we should use neither. And we should not have consumption values as I think they are misleading because we have not found any which includes land. Hope that answered everything - if not please ask me or indeed on talk page of climate change project as other’s views may differ. Chidgk1 (talk) 17:12, 10 October 2024 (UTC)[reply]
  • Oppose agree with CMD. JSwift49 14:03, 8 October 2024 (UTC)[reply]
    CMD stated that “The infobox is supposed to reflect the article.” and if I understand right seems to be saying that the info should be duplicated in infobox and article. And they say that as few articles have a GHG number now that it is not important.
    However I think the infobox should have the data and in the body it may not need to be repeated but should be put into context. For example China infobox says admitted to UN on 24 October 1945 but we don’t need that exact date in the body Chidgk1 (talk) 15:05, 9 October 2024 (UTC)[reply]
  • Oppose if it's relevant and notable it should be discussed in the body of the article where context can be provided. These type of infoboxes are bloated and cluttered as is, no need to add to that bloat and clutter. Isaidnoway (talk) 05:50, 13 October 2024 (UTC)[reply]
  • Oppose - Seems trivial. The infobox should only contain the most vital statistics that people go looking for when they want information about a country. NickCT (talk) 18:47, 21 October 2024 (UTC)[reply]

Template-protected edit request on 27 September 2024

[edit]

Replace:

<nowiki>| header25 = {{#if:{{{government_type|}}} || {{#if:{{{leader_title1|}}}{{{leader_name1|}}}
        | {{#if:{{{name|}}}{{{membership|}}}
           | <!--template being used for geopolitical org:-->Leaders          
           | <!--template being used for country/territory: -->Government 
          }} 
        }} }}</nowiki>

with:

<nowiki>| header25 = {{#if:{{{government_type|}}} || {{#if:{{{leader_title1|}}}{{{leader_name1|}}}
        | {{#if:{{{name|}}}{{{membership|}}}
           | <!--template being used for geopolitical org:-->{{#if: {{{leaders_header_name|}}} |{{{leaders_header_name}}} |Leaders}}          
           | <!--template being used for country/territory: -->{{#if: {{{government_header_name|}}} | {{{government_header_name}}} |Government}}
          }} 
        }} }}</nowiki>

In order to allow the alteration of headers in cases such as proposed countries (eg. "Proposed government" instead of "Government") — IмSтevan talk 12:44, 27 September 2024 (UTC)[reply]

 Not done This template shouldn't be used for proposals. Nikkimaria (talk) 04:32, 28 September 2024 (UTC)[reply]
@Nikkimaria: This template is already used for a proposed country, Sovereign State of the Bektashi OrderIмSтevan talk 10:42, 29 September 2024 (UTC)[reply]
Fixed that. Nikkimaria (talk) 13:48, 29 September 2024 (UTC)[reply]
And your edit was reverted not an hour later — IмSтevan talk 21:49, 30 September 2024 (UTC)[reply]
I'm not sure why that was, but removal/replacement would be the appropriate outcome - this template is for countries, not ideas. Nikkimaria (talk) 02:27, 1 October 2024 (UTC)[reply]
{{Infobox micronation}} might be appropriate for that article. In fact, there is an RFC covering this exact issue. The example given in the template's documentation is of a non-country. – Jonesey95 (talk) 18:19, 1 October 2024 (UTC)[reply]
Sealand is a non-country, but it is a micronation, not a proposed country — IмSтevan talk 19:51, 2 October 2024 (UTC)[reply]
@Di (they-them): feel like pinging you here is relevant — IмSтevan talk 19:52, 2 October 2024 (UTC)[reply]
I reverted the edit because the edit summary cited this discussion as rationale, but the discussion was specifically pertaining to micronations such as Liberland or Sealand. It was my understanding that proposed countries such as East African Federation and Sovereign State of the Bektashi Order can use this template. However, I think that these two examples are probably special cases, since the EAF and the Bektashi State are both actively being worked on by heads of state. I think that caveat probably makes a difference, because the EAF and Bektashi State are much more legitimate proposals than, say, Romanistan or Siberian Republic, because the latter two are just ideas posited by activists and not states actively being created through legislation. Di (they-them) (talk) 21:31, 2 October 2024 (UTC)[reply]
Any article could use any template, but this template is designed for a specific purpose, it is not (and should not be) designed to work for everything. CMD (talk) 00:10, 3 October 2024 (UTC)[reply]
As far as I can tell from our article micronation, the micronation infobox appears to be designed for proposed states: A micronation is a political entity whose representatives claim that they belong to an independent nation or sovereign state, but which lacks legal recognition by any sovereign state. ... Micronations are aspirant states that claim independence but lack legal recognition by world governments or major international organisations. We also have an article List of states with limited recognition, which is linked from Disputed states, a redirect. We have a disambiguation page at Proposed country, and a list of links at Lists of active separatist movements. It's kind of a mess out there, but AFAICT, Infobox country is for articles about entities described in Sovereign state. I could be very wrong with this last statement, since this template has more than 6,000 transclusions. We may want to change the current documentation for this template, which uses some vague terms: This infobox template is used to generate an infobox for the right-hand side of two specific types of article: on a country or territory, or on a geopolitical organisation. Continue discussing. – Jonesey95 (talk) 17:40, 3 October 2024 (UTC)[reply]

No daylight saving time

[edit]

It would be good to be able to explicitly indicate that a country does not use daylight saving time. |DST=No does not work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:02, 3 October 2024 (UTC)[reply]

Have you tried using |DST_note=, per the documentation? See this test case, or Pakistan. – Jonesey95 (talk) 21:14, 3 October 2024 (UTC)[reply]