Jump to content

Template talk:Infobox country

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

Sovereignty

[edit]

Can the parameters for |sovereignty_type= and |sovereignty_note= be expanded so that multiple ones can be added to a certain country's infobox?

For example, I should be able to add the different periods when a country was a vassal of various different empires at various points in its history. That would require the addition of a |sovereignty_date= parameter for these too. Antiquistik (talk) 09:29, 23 June 2024 (UTC)[reply]

It's meant to be for the current status, with the established dates able to handle the date or dates that sovereignty changed leading to the current status. This assumes of course that it is a political entity passing between different sovereigns or similar, the infobox format doesn't map well onto more abstract notions. CMD (talk) 13:05, 23 June 2024 (UTC)[reply]
Sovereignty as we know it today is a reasonably modern concept (began approximately in the 17th century). I think to use the term for periods before then would be anachronistic. Roger 8 Roger (talk) 00:15, 28 June 2024 (UTC)[reply]
In this case, could new parameters be created which would indicate whether an ancient or mediaeval state was a vassal or dependency of another state and the periods during which their vassaldom or dependency lasted? Antiquistik (talk) 08:16, 29 June 2024 (UTC)[reply]

Template-protected edit request on 18 July 2024

[edit]

I'd like to please request for the {{subst:tfm|type=infobox}} tag to be added so I can nominate this template for merging with {{Infobox settlement}}. PK2 (talk; contributions) 07:36, 18 July 2024 (UTC)[reply]

 Not done for now: PK2, please file the nomination first, then I will add it. Primefac (talk) 16:00, 18 July 2024 (UTC)[reply]
I've just filed the nomination now. I've also included {{Infobox political division}} in this request as well. PK2 (talk; contributions) 09:36, 19 July 2024 (UTC)[reply]
 Done Primefac (talk) 12:06, 19 July 2024 (UTC)[reply]

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]

Adding a Democracy Index

[edit]

Bringing this up once again as it seems this topic keeps occurring on many talk pages for countries such as China and Russia where people keep discussing whether or not to put "under an authoritarian dictatorship" or similar language under the Government section in the infobox. My understanding is that this section should be reserved for the form of government, rather than the character of the government. Thus, the Government section should simply list what the country officially is, while a separate section below it should list what the country actually is. Two indices for consideration would be the V-Dem Democracy Index and The Economist Democracy Index owing to their wide use among scholars and academic research journals. BootsED (talk) 01:04, 21 July 2024 (UTC)[reply]

I don't think adding indices (no matter which ones) would stop people from discussing that. Nikkimaria (talk) 01:13, 21 July 2024 (UTC)[reply]
The problem with international rankings is that there are so many to choose from.
Including Gini isn't too controversial because it has a simple definition and few degrees of freedom. Including the Human Development Index isn't too controversial because it's published by the United Nations and consists of simple measures of things (health, education, income) seen as good across ideologies.
Measuring "democracy" or "freedom" or "equality" requires a lot more judgment calls. I think that makes it less appropriate for inclusion in country infoboxes. Jruderman (talk) 07:32, 21 July 2024 (UTC)[reply]
That's a very good point and quite true. My counter-argument is that such judgement calls are already being made on numerous country pages, and that if such calls are to be made they should ideally be made based on highly-cited academic measures of "democracy" that follow Wikipedia policy on reliable and academic sources rather than news articles. I agree, adding indices would not stop people from discussing this topic, but it would help provide context for the discussion. BootsED (talk) 01:49, 23 July 2024 (UTC)[reply]
Everything you say is true. It's just... outsourcing our judgment calls exclusively to the Economist Intelligence Unit, across all country pages at once, doesn't seem like the Wikipedia thing to do. Jruderman (talk) 02:21, 23 July 2024 (UTC)[reply]
Would the conclusions of editors be different than the conclusions of the EIU or V-Dem indices? And if not, why not use these highly-cited and reputable sources by academia instead of lower-quality sources and news reports? Wikipedia itself is based on reliable sources, not the opinions of editors. So the use of the EIU or other indices would still follow Wikipedia’s policies on RS. BootsED (talk) 14:37, 23 July 2024 (UTC)[reply]
Using indices in article prose is one thing. Using them in the infobox is a statement that they are a key fact to understand a country. This is also without considering potential neutrality concerns in promoting particular viewpoints about what makes a good government, which is what both V-DEM and the EIU seek to do. CMD (talk) 15:43, 23 July 2024 (UTC)[reply]
That’s fair. However, I would argue that how democratic versus authoritarian a country is remains a key fact to understand a country. North Korea is officially a democracy, but not having a statement in the infobox somewhere stating how it is authoritarian would be misleading. There’s nothing to do with neutrality or a value judgement there. This proposal merely formalizes what is already a consensus on many pages such as the former, to include a statement such as “under an authoritarian dictatorship” or thereof in the infobox, not only in the article body. BootsED (talk) 17:27, 23 July 2024 (UTC)[reply]
None of this matters if it can't actually be represented as a straightforward numerical figure without further context. Which it cannot. Remsense诉 17:39, 23 July 2024 (UTC)[reply]
It can be represented this way. Both the V-Dem and EIU provide numerical listings of countries’ score, and further group those scores under a descriptive title. For instance, the EIU lists scores between 8.00 and 10.00 as “Full democracies” or between 4.00 and 5.99 as “Hybrid regimes.” This can easily be quantified and linked to the Wikipedia page on the topic. A similar system also exists for the V-Dem index. BootsED (talk) 17:51, 23 July 2024 (UTC)[reply]
Feel free to read my argument about why this would be immensely inappropriate earlier on this page. Remsense诉 17:56, 23 July 2024 (UTC)[reply]
I do not get from the infobox of North Korea that it is a liberal democracy in the way "democracy" is often understood by casual English readers. (The body does unhelpfully state "the elections have been described by outside observers as similar to elections in the Soviet Union" without explaining what that means, and does not note the "single list of WPK-approved candidates who stand without opposition" until the end of a very long paragraph.) I would also not feel the absence of a statement on some axis of liberal democracy to totalitarian dictatorship would imply by default one or the other. CMD (talk) 01:26, 24 July 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}} }}
    }} }}
For clarity, a copy of the invocation of the InfoboxImage module (3rd line above) with newlines added looks like this:
#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
Html snippet from Infobox_country from the Algeria article; newlines and indentation added for clarity:
<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="/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="/wiki/Flag_of_Algeria" title="Flag of Algeria">Flag</a>
  </div>
</div>
Note: 'emblem' is the next td cell (also an image) which is why there is a colspan="2 above, and then the end of the tr row.
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:TemplateStyles” Jruderman (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 (talk • contribs) 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]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_country&oldid=1247874997"