Wikipedia yɛltɔɣa:WikiProject Infoboxes/Archive 11

native name parameters

According to this search, there are some 200-ish infobox templates that use |native_name=. According to this search, some 140-ish infobox templates that use |native_name= also use |native_name_lang=. Of those infoboxen, one also uses |name_native= also use |name_native_lang= (why?).

Over the weekend I modified Module:Lang. As of this writing, that modification has caused the module to add some 2300 articles to Category:Lang and lang-xx template errors (1). Cirrus searches are notoriously flaky but yesterday I was able to find that the majority of infoboxen |native_name= errors occur in these five infoboxen:

Template:Infobox river – ~1950 articles

Template:Infobox mountain – ~150 articles

Template:Infobox body of water – ~130 articles

Template:Infobox street – ~50 articles

Template:Infobox valley – ~20 articles

When introduced to these templates, multiple native names and languages were not supported:

{{Infobox river}}: 26 March 2014

{{Infobox mountain}}: 29 April 2012

{{Infobox body of water}}: 27 May 2013

{{Infobox street}}: 9 September 2008

{{Infobox valley}}: 22 October 2018

Many, but not all, of the errors in Category:Lang and lang-xx template errors are from cases where multiple names are shoehorned into a parameter originally designed for a single name. Here are examples of some of the malformed parameters that are causing the errors:

from Chinta Valley:

| native_name        = चिन्ता घाटी
| native_name_lang   = Hindi

from Alps:

| native_name= {{plainlist|
* {{native name|it|Alpi}}
* {{native name|fr|Alpes}}
* {{native name|de|Alpen}}
* {{native name|rm|Alps}}
* {{native name|sl|Alpe}}
*(not including numerous dialects)
}}

from Gulf of Alaska:

| native_name            = Land of the Frontier
| native_name_lang       = French: Golf'e d'Alaska

from Adige:

| name_native        = {{native name|de|Etsch}}<br/>{{native name|it|Adige}}<br/>{{native name|vec|Àdexe}}<br/>{{native name|rm|Adisch}}<br/>{{native name|lld|Adesc}}
| name_native_lang   =

from Crescent Street:

| native_name             = {{lang-fr|rue Crescent}}

You can see that editors are all over the place when it comes to filling |native name=. There has been some work done to 'support' multiple names so each of the five infoboxen use a variation of the same general code (though none of the five share exactly the same code). So, it occured to me that it would be better to move the native name handling out of the infoboxen so that names can be rendered properly. To that end, I created {{native name list}}. Taking the Adige example above:

{{native name|de|Etsch}}<br/>{{native name|it|Adige}}<br/>{{native name|vec|Àdexe}}<br/>{{native name|rm|Adisch}}<br/>{{native name|lld|Adesc}}

Etsch (German)
Adige (Italian)
Àdexe (Venetian)
Adisch (Romansh)
Adesc (Ladin)

and rewriting:

{{native name list |tag1=de |name1=Etsch |tag2=it |name2=Adige |tag3=vec |name3=Àdexe |tag4=rm |name4=Adisch |tag5=lld |name5=Adesc}}

Tɛmplet:Native name list

The original 'looks' correct but is a violation of MOS:NOBREAKS. {{native name list}} renders a plain unordered list. For simplicity, {{native name list}} does not support the positional parameters that are used in {{native name}}. Instead, it uses |tagn= and |namen=. Otherwise, the template uses enumerated forms of all {{native name}} parameters. It also has |postfixn= so that references and other wikitext can be appended to a list item where necessary or desireable.

So, what to do now? How to convert the mess that we have (incomplete, malformed, not compliant with MOS) to a standardized way of representing native names in infoboxen? If |native_name= is to get {{native name}} or {{native name list}} as an assigned value in an instance of an infobox template, the code that supports |native_name= (as it exists now) must go away. |native_name_lang= also must go away. But, simply deleting the code and parameter is not sufficient; the value(s) assigned to |native_name= must be reformatted to use {{native name}} or {{native name list}}. Alas, it is unlikely that this conversion can be automated; there is just too much variety in the values assigned to |native_name=.

Opinions sought: Should we go forward? If so, how?

—Trappist the monk (talk) 22:25, 27 December 2021 (UTC)

Tɛmplet:Reply-to - I have to applaud your work here; I've run across |native_name= problems myself, the main one being infoboxes where |native_name= is present, but |native_name_lang= isn't.

I wish I had a suggestion for working around the problems of large-scale edits that can't be automated - I've been pondering reworking the {{nihongo}} templates for ages, because none of the parameters are actually marked in the template, and I think it could be streamlined in the same way {{lang-zh}} was. Some fixes would be easy - {{nihongo2}} is just lang|ja in disguise - but others would not be.

In that vein, however, it's possible that some cases could be automated. For instance, instances where |native_name= is filled out with {{lang}} might be easy to convert to {{native name}}, as hopefully the correct ISO code would already be present. (I don't have much, if any, technical knowledge, so apologies if this isn't actually easy or possible.)

What I do have to ask is how transliterations would be handled. It's true that {{lang}} has a |-Latn= parameter for ISO codes, but this causes display problems for some users, so I would seriously ward against use of it, or something like it. IIRC, the CSS doesn't reach for a Latin-script font first, it reaches for a script that supports both Latin and other writing systems - it's effectively like switching to MS Mincho in the middle of a Times New Roman doc.

There's also instances, as with {{lang-zh}}, where a number of transliteration styles exist. I'm not sure how they'd be handled. However, I have to thank you for taking the initiative to sort this out - it's much appreciated.--Ineffablebookkeeper (talk) ({{ping}} me!) 12:58, 28 December 2021 (UTC)

@Trappist the monk also note that there is Template:Infobox name module which is used by {{Infobox film}} and {{Infobox television}}. Gonnym (talk) 13:35, 28 December 2021 (UTC)

There is nothing in what I described above to prevent editors from using {{infobox name module}} in an {{infobox <whatever>}} |native_name= parameter if they would prefer to do that. But, before those editors can use {{infobox name module}} in the infoboxen that I named above, the specific {{infobox <whatever>}} must have been modified so that it does not further process whatever is returned from {{native_name}}, {{native_name_list}}, {{infobox name module}}, or ... And that, the modification of the five infoboxen that I named, is the purpose of this discussion.

It appears that {{infobox name module}} is constrained to Asian names so another mechanism for listing multiple native names in a syntactically correct way is needed. An extension of the {{native_name}} template used in the five infoboxen seemed an appropriate way to solve the multiple native name problem. Is that an incorrect solution?

—Trappist the monk (talk) 14:27, 28 December 2021 (UTC)

Your solution seems good. I wish the VE would support nested templates as then it would be 100%, but since (as far as I know) it doesn't, then that means that users using it won't be able to correctly enter those values. Gonnym (talk) 15:19, 28 December 2021 (UTC)

Thanks, but, alas ... a problem with so many discussions at en.wiki is that they tend to wander off topic. If you want to talk about reengineering the {{nihongo}} templates, my talk page?

Romanizations can be listed like this, for example:

{{native name list |tag1=ja |name1=有家川 |tag2=ja-Latn |name2=Arie-gawa}}

Tɛmplet:Native name list

That some browsers do not render certain IETF language tags correctly is not something that templates and en.wiki should 'fix' – unless the templates are creating malformed markup (if you know where Module:Lang is creating malformed markup, please report it at Template talk:Lang). When given correct markup, browser rendering anomalies can be fixed only by the browser maintainers.

—Trappist the monk (talk) 14:27, 28 December 2021 (UTC)

This parameter needs a better name..... we deal with indigenous name spam constantly. Should call it auxiliary_name.--Moxy- 15:14, 28 December 2021 (UTC)

I don't know what indigenous name spam is so cannot speak to that. This discussion is not about the names of |native_name= and |name_native= so if you think those parameter names should change, please address that in a different discussion.

—Trappist the monk (talk) 15:52, 28 December 2021 (UTC)

I have hacked a scrap of awb code to trawl Category:Lang and lang-xx template errors and add |native_name_lang=<tag> when it could extract <tag> from a {{lang}} or {{lang-??}} template that wrapped the exact text found in |native_name=. The hack fixed about 680 articles with the Tɛmplet:Error-small error. About 1450 articles with that error remain in the category.

—Trappist the monk (talk) 15:11, 29 December 2021 (UTC) 15:16, 29 December 2021 (UTC) (+search link)

Support the effort. If |native_name_lang= goes away, then Category:Infoboxes without native name language parameter won't be populated and these won't be cleaned-up, without some other mechanism. Can the infobox code for |native_name= track articles that have plain text (e.g. instead of {{native name}} or {{native name list}}) as an alternative? I believe that most of the articles in this category are from just a few infoboxes. There are many other templates that have |native_name= and |native_name_lang= but don't track if the language is not specified. I think I remember one biography infobox (maybe a sports one) that doesn't have |native_name_lang= but still flagged a missing language - it expected a template in |native_name=. Then there are the infoboxes that don't even have |native_name= and the native name is crammed into |name=. Yes, there is a lot that can be improved in this area. MB 00:38, 1 January 2022 (UTC)

Thanks for bringing this up. I was not aware of that category because Category:Infoboxes without native name language parameter is not populated by {{Infobox body of water}}, {{Infobox mountain}}, {{Infobox river}}, {{Infobox street}}, or {{Infobox valley}}. I don't imagine that it will be too difficult to determine if the value assigned to |native_name= is a good value (the return from {{native name}} has an html attribute lang= when the template has a properly formatted language tag (can't do anything about a 'wrong' language tag...); this is pretty much what the current code in these infoboxen does when it masks errors returned by Module:Lang. So we might write something like this (not tested):

|dataxx = {{#if:{{{native_name|}}}|{{#ifexpr:0<{{#invoke:String|find|source={{{native_name|}}}|target=lang="%a%a%a?[%-"]%a*|plain=false}}|{{{native_name|}}}|<span style="color:#d33">{{pipe}}native_name= requires {{tlx|native name}} or {{tlx|native name list}} or nothing</span>[[Category:Infoboxes with malformed native name parameter]]}}}}

And that got me to wondering if we should also look for obvious other stuff like <br />-separated lists (which 'lists' are part of the reason for this discussion) so I can imagine writing a checker template that would call a lua function to do all of the necessary checking. We might then write something like this in the infoboxen code (also not tested):

|dataxx = {{#if:{{{native_name|}}}|{{native name checker|{{{native_name|}}}}}}}

{{native name checker}} would return the {{native name}} or {{native name list}} rendering with appropriate (but not redundant) error messages and categories.

Along the lines of 'what-to-do-in-case-of-...', I've been wondering how {{native name}} and {{native name list}}should handle languages that don't have ISO 639 tags. Some of the errors in Category:Lang and lang-xx template errors are there because there is no language tag to go in |native_name_lang= (dialects and the like). We might then recommend something like these:

{{native name|mis|<{{var|name in an uncoded language}}>|paren=omit}} (<{{var|wikilinked uncoded language name}}>)

<name in an uncoded language> (<wikilinked uncoded language name>)

{{native name list|tag1=mis|name1=<{{var|name in an uncoded language}}>|paren1=omit |postfix1= (<{{var|wikilinked uncoded language name}}>)}}

Tɛmplet:Native name list

What other gotchas are out there?

—Trappist the monk (talk) 14:29, 1 January 2022 (UTC)

I have switched {{native name}} to use Module:native name. The module version of the template produces its own set of error messages and categorizes those articles into Category:Native name template errors (0).

—Trappist the monk (talk) 17:45, 2 January 2022 (UTC)

I'm coming here from Talk:Mount Washington#Infobox help.

The problem there was that {{native name}} wants IETF codes while parameter |native_name_lang= will accept ISO codes, some of which are not available as an IETF code (at least currently). These differences are getting way above my technical credentials, but I worry that some hasty changes are being proposed without there being a comprehensive understanding of the problem. — jmcgnh^{(talk) (contribs)} 19:42, 3 January 2022 (UTC)

The IETF tag part of the above comment is addressed at Talk:Mount Washington § Infobox help.

—Trappist the monk (talk) 23:15, 3 January 2022 (UTC)

Tɛmplet:OdTo summarize what I understand from the above discussion:

• native_name parameters as currently used in articles by editors are all over the map with many different ideas in evidence about how it should be used
• Infoboxes' documentation for this parameter is not entirely consistent either
• One problem is being able to accommodate multiple names
• One problem is which set of language indicators should be accepted
• Which leads to problems for languages not covered by that accepted set
• The coding of modules should categorize the various errors that occur when using this facility so they can be systematically fixed, though perhaps not automatically

I think this discussion is trying to resolve an important problem and I also applaud the effort put in so far. — jmcgnh^{(talk) (contribs)} 21:01, 3 January 2022 (UTC)

I think that is a fairly accurate assessment of the issues. Thank you.

—Trappist the monk (talk) 23:15, 3 January 2022 (UTC)

I have created {{native name checker}}, a template that goes inside infoboxen to handle the |native name= parameter value. I have implemented it in {{infobox valley/sandbox}}. There is a comparison on the template's testcases page at Template:Infobox valley/testcases § Coachella Valley (native name). The tested infobox has this:

| native_name = {{lang-es|Valle de Coachella}}

The tested infobox does not have |native_name_lang= so when the live infobox attempts to wrap the above in a {{native name}} template it does this:

{{native name||[[Spanish language|Spanish]]: <i lang="es">Valle de Coachella</i>[[Category:Articles containing Spanish-language text]]}}

which produces this:

Error {{native name}}: an IETF language tag as parameter {{{1}}} is required (help)

In the {{infobox valley/sandbox}}, {{native name checker}} accepts the |native_name= parameter value because {{lang-es}} properly wraps the name with the correct html markup (the checker is looking for the lang="es" html attribute). It may be that using {{lang}} and {{lang-??}} templates in |native_name= is sufficiently undesirable that {{native name checker}} should be changed to detect those templates. That is more a style issue than a technical-correctness issue:

Spanish: Valle de Coachella ← {{lang-es|Valle de Coachella}}

Valle de Coachella (Spanish) ← {{native name|es|Valle de Coachella}}

—Trappist the monk (talk) 23:15, 3 January 2022 (UTC)

The template is a great direction and saves us having to manually implement that code in each template. Template:Infobox station is another template that would need modified but its code seems a bit harder to clean. Gonnym (talk) 09:40, 5 January 2022 (UTC)

I am about to update {{infobox valley}} to use {{native name checker}}. I will then run an awb script over the articles that transclude {{infobox valley}}. The script will, when it can, create |native_name={{native name|<tag>|<name>}} and delete |native_name_lang=. |native_name_lang= will not be deleted when that would be the only change to the article.

—Trappist the monk (talk) 15:16, 7 January 2022 (UTC)

Since you've removed |native_name_lang= from the known parameter list and pages with it will now be categorized in an unknown category, removing the parameter is not a cosmetic change and is now valid, even if it is the only thing changed. Gonnym (talk) 15:25, 7 January 2022 (UTC)

Only categorized when the unused parameter has a value. Next up is {{infobox street}} with about 3000 transclusions. Of those, about 600 will be fixable by the script. I am not going to sit here and click 2400 times just to remove blank unused parameters. And, once burned three or four times shy. Purely cosmetic edits without structural or tangible benefit will not be done by me.

—Trappist the monk (talk) 13:20, 8 January 2022 (UTC)

I am about to update {{infobox street}} to use {{native name checker}}. As before I will then run the awb script over the articles that transclude {{infobox street}}.

—Trappist the monk (talk) 13:20, 8 January 2022 (UTC)

And now on to {{infobox body of water}} to use {{native name checker}}. As before I will then run the awb script over the articles that transclude {{infobox body of water}}.

—Trappist the monk (talk) 16:00, 9 January 2022 (UTC)

And next, {{infobox mountain}} to use {{native name checker}}. As before I will then run the awb script over the articles that transclude {{infobox mountain}}.

—Trappist the monk (talk) 14:10, 10 January 2022 (UTC)

Looks good, thank you for doing this - is there any support for languages which don't have an IETF tag? A lot of the articles for the Chatham Islands have Moriori names (eg. Mangere Island), which as far as I can tell wouldn't work as the Moriori language doesn't have a tag (the one listed in the infobox on that page doesn't seem to be recognised). Turnagra (talk) 21:19, 10 January 2022 (UTC)

Module:Lang isn't sophisticated enough to reach into CLDR for such esoteric IETF subtags as mi-u-sd-nzcit where:

mi → Māori

u → unicode u extension

sd → unicode subdivision identifier

nzcit → Chatham Islands

But, one might do this:

{{native name|mis|Māngere|paren=omit}}  ([[Moriori language|Moriori]]) → Māngere  (Moriori)

This uses ISO 639 tag mis (). If there is sufficient need, we might create a private use tag mi-x-moriori.

—Trappist the monk (talk) 22:12, 10 January 2022 (UTC)

Northern Yatsugatake Volcanic Group is using an incorrect language tag for the Hepburn transliteration. Is there a way to fix this or just remove that name? Gonnym (talk) 07:34, 11 January 2022 (UTC)

Before this edit, there was no indication that the romanized name is a Hepburn romanization so ja-Latn is correct. If you know that the romanization is Hepburn then you may change that tag to ja-Latn-hepburn.

—Trappist the monk (talk) 14:06, 11 January 2022 (UTC)

That's what the first sentence of the lead says. Gonnym (talk) 14:14, 11 January 2022 (UTC)

Still showing up as Japanese text though after changing it, so that didn't fix it. Gonnym (talk) 14:15, 11 January 2022 (UTC)

It shows as Japanese text because it is Japanese text; ja-Latn is correct because the Japanese text was written using Latin characters; ja-Latn is correct because browsers will render the Japanese text using an appropriate Latn-script font. These should appear different to you if your browser is operating correctly:

Kita-Yatsugatake ← {{lang|ja|Kita-Yatsugatake}}

Kita-Yatsugatake ← {{lang|ja-Latn|Kita-Yatsugatake}}

You refer to the tool-tip at the {{nihongo}} template? That is baked-in to Module:Nihongo's call to {{transl}} so no matter what romanization system created the Latn-script text provided to {{nihongo}}, it is tool-tipped as Hepburn.

The original was:

{{lang|ja|北八ヶ岳}} {{transl|ja|Kita-Yatsugatake}}

北八ヶ岳 Kita-Yatsugatake

The closest that {{native name list}} can come to that is

{{native name list |tag1=ja|name1=北八ヶ岳 |tag2=ja-Latn|name2=Kita-Yatsugatake}}

Tɛmplet:Native name list

You can do this:

{{native name list |tag1=ja|name1=北八ヶ岳 |tag2=ja-Latn|name2=Kita-Yatsugatake|paren2=omit |postfix2=  ([[Hepburn romanization]])}}

Tɛmplet:Native name list

You can do this:

{{ubl|{{native name|ja|北八ヶ岳}}|{{transl|ja|Kita-Yatsugatake}}}}

• 北八ヶ岳 (Japanese)
• Kita-Yatsugatake

—Trappist the monk (talk) 15:18, 11 January 2022 (UTC)

Do you enjoy just being plain unfriendly? You wrote If you know that the romanization is Hepburn then you may change that tag to ja-Latn-hepburn, I changed it, then you wrote ja-Latn is correct because the Japanese text was written using Latin characters. If you don't want to give advice, then just don't. I much prefer silence than your condescending text. And yes, I was looking at the lead which used {{nihongo}} and wanted to match the outputs, so people like me, who aren't fluent in the ins and outs of Japanese language, will not be confused by the same name being explained as two completely different things. Gonnym (talk) 17:39, 11 January 2022 (UTC)

And {{infobox river}} to use {{native name checker}}. As before I will then run the awb script over the articles that transclude {{infobox river}}.

—Trappist the monk (talk) 14:46, 15 January 2022 (UTC)

Template:Nom has an RFC

Template:Nom has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. The proposed change may imply a change in {{Infobox awards list}}. — Preceding unsigned comment added by Ftrebien (talk • contribs) 12:01, 24 January 2022 (UTC)

Particle Accelerator Infobox

Hi folks - I've been working to improve WPs coverage of topics related to particle accelerators. It's a niche topic, but hey - aren't they all? At any rate, we have enough pages on specific machines that I was thinking about creating a Particle Accelerator infobox. Possible facts to include:

• Type of Accelerator (synchrotron, linear accelerator, cyclotron, etc)
• Type of target (fixed target, collider)
• Type of particles (protons, electrons, heavy ions)
• Maximum energy
• Maximum current
• Maximum luminosity / brightness (for relevant accelerators)
• Location
• Sponsoring Institution / Government
• Dates of operation
• Preceded by / Succeded by (for accelerators with clear successors, such as LEP -> LHC )

First off, does this seem a reasonable thing to create? Second, are there obvious other fields I should be including? Thanks for your help. PianoDan (talk) 16:33, 7 April 2022 (UTC)

Update: I've gone ahead and created a draft. I can't quite figure out how to include "coordinates" in the draft template without setting off warnings elsewhere, so I'd appreciate a bit of help with that, in addition to any other comments folks might have. Draft: User:PianoDan/Infobox particle accelerator PianoDan (talk) 16:51, 9 April 2022 (UTC)

User script to detect unreliable sources

Main page: User:Headbomb/unreliable

I have (with the help of others) made a small user script to detect and highlight various links to unreliable sources and predatory journals. Some of you may already be familiar with it, given it is currently the 39th most imported script on Wikipedia. The idea is that it takes something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14. (John Smith "[https://www.deprecated.com/article Article of things]" ''Deprecated.com''. Accessed 2020-02-14.)

and turns it into something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14.

It will work on a variety of links, including those from {{cite web}}, {{cite journal}} and {{doi}}.

The script is mostly based on WP:RSPSOURCES, WP:NPPSG and WP:CITEWATCH and a good dose of common sense. I'm always expanding coverage and tweaking the script's logic, so general feedback and suggestions to expand coverage to other unreliable sources are always welcomed.

Do note that this is not a script to be mindlessly used, and several caveats apply. Details and instructions are available at User:Headbomb/unreliable. Questions, comments and requests can be made at User talk:Headbomb/unreliable.

- Headbomb {t · c · p · b}

This is a one time notice and can't be unsubscribed from. Delivered by: MediaWiki message delivery (talk) 16:01, 29 April 2022 (UTC)

New Infoboxes -- Protocol?

It looks like the pages referencing where to request/get feedback on new infobox templates is just kept for historical reference -- what's the protocol now/where should I go for requesting a new infobox? Thanks! 19h00s (talk) 17:55, 29 April 2022 (UTC)

19h00s maybe Wikipedia:Requested templates? What links did you find linking to historic pages? Can be useful to update those with whatever the current location is ~ 🦝 Shushugah (he/him • talk) 19:26, 29 April 2022 (UTC)

The Help:Designing infoboxes page, and a few other places, link to Wikipedia:List of infoboxes/Proposed -- there also isn't any explanation on where to put new infoboxes for feedback. The Requested templates page is definitely helpful, and probably a better link for the Designing infoboxes page. 19h00s (talk) 19:40, 29 April 2022 (UTC)

Discussion at Template talk:Infobox election § Should an election's official logo be included in the infobox?

 You are invited to join the discussion at Template talk:Infobox election § Should an election's official logo be included in the infobox?. Chlod (say hi!) 00:03, 18 April 2022 (UTC) Chlod (say hi!) 00:03, 18 April 2022 (UTC)

Hello! This discussion is still open to comments and your feedback is requested. Chlod (say hi!) 04:15, 1 May 2022 (UTC)

U.S. Cup Infoboxes

I added infoboxes to these pages: 1992 U.S. Cup ‎ 1993 U.S. Cup ‎ 1995 U.S. Cup ‎ 1996 U.S. Cup ‎ 1997 U.S. Cup ‎ ‎1999 U.S. Cup ‎ ‎2000 U.S. Cup (links here under 0-9: https://en.wikipedia.org/wiki/Category:Wikipedia_articles_with_an_infobox_request) Since this is my first time adding infoboxes, can I get confirmation to remove the "needs infobox" label on these pages? Thank you. Cioriolio (talk) 17:09, 26 May 2022 (UTC)

Medals element in infoboxes

@Pigsonthewing, Magioladitis, Redrose64, Quiddity, Vanisaac, Trappist the monk, Gyrofrog, SMcCandlish, Gonnym, Ergo Sum, Gerda Arendt, and Izno: Since you have made more than 10 edits to this talk page, I am pinging you here to help me to understand the propriety of using the medals elements in the infobox. Specifically, I have two issues detailed below: whether medals elements should be used for quickly summarizing individual sports NCAA championship accomplishments, which I see mixed usage of and whether medals elements could/should be used for National YMCA aquatics events.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:11, 25 June 2022 (UTC)

I have seen and used the medals element for infoboxes in a wide range of international and national competitions. This includes age-limited events such as Youth Olympic Games, Universiade, FIBA Under-17 Basketball World Cup and regional championships such as FIBA Under-16 Americas Championship, NCAA Division I Women's Swimming and Diving Championships. After seeing Olivia Smoliga's infobox with NCAA championships included in the medals element, I added similar content to Emma Reaney's and Randall Cunningham II's infoboxes. I am wondering about the pre-collegiate National YMCA (LC & SC) aquatics events (see here). These are for YMCA competitors who are between the age of 12 and 21 who have not represented any post high school institutions. E.g., Kelly Hecking has 3 career 1sts (LC), 4 2nds (SC) and 2 3rds (SC). Is it Kosher to include this in a medals element of an infobox. Since this is not an open national championship (age limited, pre-collegiate limited and YMCA history limited since you have to have swam in 4 prior YMCA events including a (presumably regional) championship), how much does it count. Can I stub out some related competitors who were YMCA Nationals champions. Also, any advice on the propriety of NCAA medals elements in infoboxes will impact many articles that I have primary editorial roles in, including Tora Harris, Thomas Wilcher, Donn Cabral, Matthew Busbee, Marie Roethlisberger and maybe Augie Wolf.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:17, 21 June 2022 (UTC)

I have nothing to say about medals. But, I will say that the color choice for the 'Medal record' header bar in Randall Cunningham II probably violates contrast accessibility requirements. This test result suggests that the chosen colors do violate the contrast requirements. For me, the show/hide link is unreadable without I get right up to the monitor:

Tɛmplet:Background

Fix that.

——Trappist the monk (talk) 11:39, 25 June 2022 (UTC)

Ditto. Izno (talk) 16:09, 25 June 2022 (UTC)

I'll give my standard MOS:ICONS answer: These medal icons will be clear enough in meaning to the average reader, and clearly save space over using words like "Gold", "Silver", "Bronze", so are a reasonable choice for infobox usage; they are not are primarily serving the worse-than-useless function of visual decoration. On the narrower question, NCAA championships are generally notable, so seem fair game for inclusion. National YMCA events seem pretty iffy to me, but I'm not big into amateur athletics, so maybe they are more career-important than I think they are.  — SMcCandlish ☏ ¢ 😼  16:57, 25 June 2022 (UTC)

The colors are the USC trojans colors. I guess there is a protocol in terms of whether to have colors for the most recent team/affiliation or only current team/affiliation. If it is wrong to retain colors after graduation, I am happy to remove them. I think a lot of NCAA basketball players had colors removed before the NBA draft, but others didn't. I guess I will try to remove his colors. In terms of medals, what I am hearing is that NCAA is probably an O.K. inclusion and if it is reasonable to deem YMCA national championships as career-important include those. I didn't read a lot of swimming bios of athletes below Olympic level before getting involved in Kelly Hecking and Emma Reaney earlier this month. I will bounce around to a few university published web bios and see how prominently they mention national YMCA championships. Meanwhile I will probably soon spruce up pages where I can with NCAA content in infoboxes.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:40, 26 June 2022 (UTC)

User:Sportsfan 1234, Let's keep the discussion centralized. Here is a list of places I have added the NCAA content in medals form: Molly Seidel, Tora Harris, Randall Cunningham II, Donn Cabral, Emma Reaney, & Thomas Wilcher. I feel that I am better able to understand the notability of the subject with NCAA content in medal form. I think this matters more to notable people who are not world or olympic champions where NCAA accomplishments are a more prominent part of their notability.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 06:07, 27 June 2022 (UTC)

The YMCA medals were at the high school level, aren't even notable enough for their own article, and are sourced strictly to the YMCA itself. Definitely not suitable for an infobox. Her NCAA swimming achievements are also not notable enough to warrant infobox inclusion either; someone should be able to click the event the subject medaled in and arrive at a page that contains more information on that particular competition. Since her NCAA wins appear to have been at the conference level rather than the national competition, it would be inappropriate to put them in the infobox. JoelleJay (talk) 03:10, 30 June 2022 (UTC)

Join the RfC discussion on adding parameters to Template:Infobox officeholder!

Hello all! A discussion is underway at the talk page for this template. It involves adding First Vice President and Second Vice President parameters for nations that use the system such as Peru, like here. Other countries that currently use this system include Costa Rica, Honduras, and Zimbabwe. There are also those that used the system in the past, such as Somalia in the 1970s-80s.

Please read the preceding section before commenting! We are eager to build consensus. Holidayruin (talk) 03:09, 16 December 2022 (UTC)

Tennis Elbow Infobox

Hello,

I am participating in Wikipedia to improve medical information on Wikipedia’s musculoskeletal pages. The contribution of my collaborative and is not only specialist medical expertise, but also expertise in how labels and concepts can promote healthier or less healthy mindsets(1,2). To that end, we see a few things common to the framework of medical pages that might benefit from some evolution.

Using the example of infobox on the Tennis Elbow page, there some additional categories that might increase the infobox’s accuracy and helpfulness regarding information on Tennis Elbow.

Two infobox categories that I suggest be added are “Associations” and “Natural History”.

For the healthiest possible mindset regarding tennis elbow and other musculoskeletal pains, it’s important that people distinguish activities or exposures that are associated with symptoms from activities and exposures that cause or worsen pathophysiology. In the case of tennis elbow, it is a self-limiting condition no matter what a person does(3). It seems to be one of the self-limiting enthesopathies of middle age and does not feature inflammation or repair in the histopathology(4). In other words, there is no known cause of the pathophysiology. In medical terms it is an idiopathic condition. Any activity that uses the extensor carpi radialis brevis muscle can cause pain, and painful activities can feel like harm (a common human misperception(5–8)), but best evidence suggests activities do not cause or alter the pathophysiology. Understanding this is key to a health mindset.

The addition of “Natural History” will improve the infobox because all treatment need to be judged on their ability to either 1) alleviate symptoms or 2) alter the course of the disease if it was untreated (the natural history). There are no proved disease modifying treatments of tennis elbow and people deserve a clear understanding of that. And most treatments are no more alleviating than placebo (simulated) treatments.

I believe that the addition of these two categories will improve the infobox in ways that are useful and healthful for people reading this Wikipedia page. If you have any questions or concerns, I would love to discuss these requested additions further.

-- Mitrakardes Mitrakardes (talk) 04:20, 21 January 2023 (UTC)

Template:Infobox film has an RFC

Template:Infobox film has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Krimuk2.0 (talk) 08:53, 2 February 2023 (UTC)

Template:Infobox Indian state or territory has an RFC

Template: Infobox Indian state or territory has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Tojoroy20 (talk) 22:39, 23 February 2023 (UTC)