Wikipedia talk:WikiProject Infoboxes/Archive 11

Archive 5

←

Archive 9

Archive 10

Archive 11

Archive 12

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 (0). 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             = {{langx|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}}

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

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)

@Trappist the monk: - 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}}

• 有家川 (Japanese)
• Arie-gawa (Japanese)

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 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}}>)}}

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

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)

To 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 = {{langx|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 ← {{langx|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 (Uncoded languages). 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}}

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

You can do this:

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

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

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:

   Show   

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)

Engine infoboxes

Main page: Template talk:Infobox aircraft § Discussion related to Infobox aircraft engine and parameters:

Combustion engines are used in many applications - Aerospace, automotive, marine and industrial. Some articles on them have infobox templates; {{infobox aircraft engine}} (aviation), {{Infobox engine}} (automotive) and {{Infobox rocket engine}} (spaceflight). Wikipedia's wider community has a consensus to merge infobox templates where possible. Various aircraft infobox templates are being merged, and the question has arisen, should the aero engine infobox be merged in with them, or would it be better to merge and extend the existing engine infoboxes? There is an ongoing discussion here , which you are invited to join. — Cheers, Steelpillow (Talk) 05:29, 14 May 2023 (UTC)

English Variations

Anyone have an automated way to deal with WP:ENGVAR in infobox generated info (e.g. short descriptions)?

Seeing that Template:Infobox_television generates a short description that includes "TV show or program" - and was trying to come up with a way to have it pick "programme" if possible.

Thanks! SpookyTwenty (talk) 19:09, 23 February 2023 (UTC)

@SpookyTwenty I just added support code for this! There's no automated way but I have at least set it so that programmes in the UK, India, Pakistan, Nigeria, and New Zealand use "programme". (Australia uses "program".) Sammi Brie (she/her • t • c) 18:08, 16 May 2023 (UTC)

Logo/image handling

With the advent of television stations having multiple digital subchannels, it's become more common that {{Infobox television station}} has two logos in it.

There have been several ways topic editors have handled this:

• KTVQ: Two logos in the |logo= field separated by a horizontal line. This, I believe, causes accessibility issues with alt text (can't confirm).
• KHNL (my preferred method): Logos in the |logo= and |image= fields.

The only downside to the latter is that embeds on sites like Discord pull the |image= parameter instead of |logo=, and the former will not pull an image at all into the embed. Is there a better way to handle these situations? Sammi Brie (she/her • t • c) 18:19, 16 May 2023 (UTC)

Accessibility of Infobox rockunit

Notification of a discussion that may be of interest to this wikiproject - I have made a suggestion here: Template talk:Infobox rockunit#Possible change for colour accessibility, about a possible change to the infobox. Any comments on this would be helpful. EdwardUK (talk) 15:56, 3 June 2023 (UTC)

Question of birth/death locations in infobox

Please see discussion at Talk:Barry Humphries#Infobox locations of birth and death have been changed to very small communities. Thank you. Softlavender (talk) 06:42, 4 June 2023 (UTC)

Musical article infobox not embeding

I'm trying to embed the musical artist infobox with the person infobox in the Damian Lewis article. The example used here doesn't help me at all. I adds the musical artist infobox separately when I preview it. I've checked out other articles that embed person and musical artist infoboxes together and I get the same result when previewing. Or it shows it as unformatted. I published my edit as the former. Any help would be appreciated as I don't know what I'm doing wrong. Thanks. Mr. C.C.^{Hey yo!}_{I didn't do it!} 20:21, 19 June 2023 (UTC)

It may be little help that I always use infobox person. --Gerda Arendt (talk) 20:26, 19 June 2023 (UTC)

@Gerda Arendt, yeah, that wasn't helpful. I've seen musical artist infobox embedded alongside infobox person. I was hoping someone would have helped fix it since other articles use both. Mr. C.C.^{Hey yo!}_{I didn't do it!} 23:35, 19 June 2023 (UTC)

Edit: I checked out person infobox and looked at the template there to see how to embed. I figured it out. Easier than looking at other articles. Not sure why I didn't do that before. Mr. C.C.^{Hey yo!}_{I didn't do it!} 23:51, 19 June 2023 (UTC)

Congratultions! Look, where I edit, classical music, a few people try to fight any infobox ;) --Gerda Arendt (talk) 07:08, 20 June 2023 (UTC)

Discussion at Wikipedia:WikiProject Sports

 You are invited to join the discussion at Wikipedia talk:WikiProject Sports § Suggestion: Changing "Achievements and titles" order in Template:Infobox sportsperson, which may be of interest to this WikiProject. CLalgo (talk) 08:30, 21 June 2023 (UTC)

advertising sign?

Any ideas which template (if any) might work for Leaders of the World? {{Infobox advertising}} is more for film/video ads. RoySmith (talk) 15:06, 2 August 2023 (UTC)

I'm going to suggest {{infobox artwork}} as a possible contender. Obviously some of the parameters are very much non-applicable, but I think treating this sign as an art installation is probably about as appropriate a fit as we have. Maybe someone who knows how it works can take a stab at allowing infobox advertising to be used as a module to get some of its appropriate parameters included. VanIsaac, GHTV ^cont_WpWS 17:45, 2 August 2023 (UTC)

Proposal to limit "languages" in the religious group infobox

Please see the linked discussion with relevance to this WikiProject. Iskandar323 (talk) 09:18, 13 August 2023 (UTC)

How to handle multiple native languages?

I've been working on cleaning up Category:Infoboxes without native name language parameter, by taking the | native_lang = parameter, breaking up {{lang}} into the ISO 639-1 code and the text itself, and splitting it into two separate parameter, as can be seen in this diff. I've run into a number of articles that have multiple native languages listed, often separated by a line break. An example of such a page can be found here.

Is there a recommended way to handle these specific cases where there there are multiple official languages for the subject of an article? Thanks! Phuzion (talk) 02:48, 12 September 2023 (UTC)

Where do prototyped infoboxes go for proposal?

According to Help:Designing infoboxes, "Prototyped infoboxes should be placed on the Wikipedia:List of infoboxes/Proposed sub-page when proposed and added to the appropriate sub-category when implemented". However, Wikipedia:List of infoboxes/Proposed is currently inactive and is retained for historical reference. Is there a new page this has been moved to? Danidamiobi (talk) 14:42, 24 October 2023 (UTC)

Discussion at Template talk:Infobox § How can I use the English Wikipedia "infobox template" for another Wikipedia project (in the Incubator)?

 You are invited to join the discussion at Template talk:Infobox § How can I use the English Wikipedia "infobox template" for another Wikipedia project (in the Incubator)?. Anaxicrates (talk) 15:04, 11 November 2023 (UTC)

Proposal on adding a second "division" to Template:Infobox government

Please see the linked discussion with relevance to this WikiProject. 2861969nyc (talk) 19:36, 22 September 2023 (UTC)

You put "RFC" in the title of this section but What you link to is not an "RFC", so I replaced it with "Proposal". See WP:RFCBEFORE. Warmly, RudolfoMD (talk) 22:38, 26 November 2023 (UTC)

Discussion at Johann Christian Bach

 You are invited to join the discussion at Talk:Johann_Christian_Bach#Infobox_proposal, which is within the scope of this WikiProject. Cremastra (talk) 01:25, 16 December 2023 (UTC)

{{Infobox collection}}

The {{Infobox collection}} template has so few fields it's relatively useless (and probably the reason why articles such as British Library Sound Archive erroneously use the {{Infobox library}} template instead). Is there a chance more fields could be added to {{Infobox collection}} to make it useful? Established, dissolved, location, criteria, etc would make this much less useless than it is. - SchroCat (talk) 11:34, 24 February 2024 (UTC)

Replacement of signature images with svg derivations

Hello all- I'm looking for input regarding a campaign by a new user to change the signatures of historical figures from images of the original signature to stylized, "cleaner" svg derivations. I find that an original image is preferable to an artificial derivation. In the interest of keeping the discussion in one place, here is a link to a post I made on the new user's talkpage: User_talk:Tveol1091#svg_signature_campaign. We could move the discussion here if people think that would be preferable. Thanks in advance for any input. Pinging here the user in question and another who has interacted re the campaign: Tveol1091, Turkiishh. Eric ^talk 15:29, 24 February 2024 (UTC)

Personally, I'd say that the replacement was entirely unjustified, for the same reason that replacing monochrome images with colorised ones is: the image no longer accurately reproduces the original. And since this isn't an infobox-specific question (such images may be used elsewhere), it probably needs discussion somewhere more likely to get broad community input: maybe WP:VPP? AndyTheGrump (talk) 15:51, 24 February 2024 (UTC)

All right. I would refrain from using svg signature files if parchment signature files are being used. However, if transparent png files are being used, I think it is better to give priority to using svg files. Tveol1091 (talk) 00:29, 26 February 2024 (UTC)

I have warned Tveol1091 at their talk (diff) that they must not make any further changes without a clear consensus. To spell that out, it does not matter whether something is transparent or bad or whatever. No more changes until others agree in advance. Johnuniq (talk) 01:30, 26 February 2024 (UTC)

While I understand the point being made by Eric, I think (most of the time, as there might be exceptions) the vector/svg versions closely or exactly resemble the original signature. Also the svg versions allow editors and readers to appreciate the signature as they are better quality and most of the time make it so the signature is much easier to read. Kind regards, Robertus Pius (Talk • Contribs) 16:54, 26 February 2024 (UTC)

Hi Robertus,

I think your points about .svgs are good ones, and I agree that they are useful (see my reply to Eric below), but I think the issue being addressed here is more about the process of substituting signatures rather than svg.. I think many editors would accept .svg substitutions if they can be attributed and compared. Best... Wtfiv (talk) 18:47, 27 February 2024 (UTC)

I’d like to mention that I’m speaking more about the svg signatures I personally create as I try to make sure the svg exactly or almost exactly resembles the original signature. I cannot speak for svg’s other (possibly less experienced) editors create as they might care less about being sure the svg matches the original signature as close as possible. Just wanted to clarify that. Robertus Pius (Talk • Contribs) 17:02, 26 February 2024 (UTC)

Robert, I take your point in the case of Louis XI, and I appreciate your effort to produce good svg versions. Some of the ones used by Tveol1091 looked a little "shimmer-y" to me on my (reasonably good-quality, large LCD) monitor. As I mentioned elsewhere, I'm just partial to the more antique (organic? analog?) look of raster images when it's a signature from a historic document. I like that you can see the paper and parchment, flaws and all, in the signatures of Ludwig I and Hugues Capet, for example. Eric ^talk 19:36, 26 February 2024 (UTC)

Anyone planning changes to multiple pages must obtain prior consensus if challenged. It is very reasonable for Eric to question whether an image generated on a computer in 2024 is really the signature for someone who has been dead for over a hundred years. That needs to be decided by the community before continuing. Johnuniq (talk) 00:22, 27 February 2024 (UTC)

By checking the image source you can easily confirm if the svg is the signature of whatever individual. You can also compare the original signature to the svg to make sure the svg is accurate to the original. Robertus Pius (Talk • Contribs) 03:51, 27 February 2024 (UTC)

Let me clarify my role. Making fait accompli changes to multiple article when challenged is disruptive. Anyone doing that will be blocked. There is no need to tell me how to check a signature—that's not my department. I haven't seen anyone object to the addition of a new signature in biographies of historical figures such as diff. However, we have seen objections to changing an authentic signature to something that an individual contributor believes is good. My role is to prevent disruption by blocking anyone who does that without first gaining a positive consensus. Johnuniq (talk) 05:08, 27 February 2024 (UTC)

I was simply responded to your comment, “It is very reasonable for Eric to question whether an image generated on a computer in 2024 is really the signature for someone who has been dead for over a hundred years.” I thought this comment was odd as any editor can simply check the source and see further information about the signature. Robertus Pius (Talk • Contribs) 05:33, 27 February 2024 (UTC)

I’m not questioning your role whatsoever, just responding to your comment. Regards, Robertus Pius (Talk • Contribs) 05:34, 27 February 2024 (UTC)

Robert, experienced users here will of course know how to trace the origin of a derived signature. What I question is whether it is necessarily an improvement to replace historical signature images with vector derivations. My contention is that a reader of the Hugh Capet article, for example, is better served by an image of his actual signature on a document from the year 988 rather than a stylized glyph derived from it 1,400 years later. (Note that I had to link to an older version of Capet's article, as Tveol1091 has again changed it back to the svg, one of many such undiscussed changes he/she has made today). Eric ^talk 13:53, 27 February 2024 (UTC)

The Tveol1091 is behaving similarly on the Frederick the Great page. The editor changed the image without discussion. It has been changed back with summary comments by two editors (myself and another watcher), we are now on the third revert. At present, I've invited to discuss on the talk page. But when I discovered that the issue is more pervasive, I thought I'd weigh in here.

I'm not against adding .svg signatures to articles. I understand how this could be an improvement. But the .svg used is from a commercial fine art site without attribution, whereas the .png currently used comes from a reliable source that explains where the image came from and can be visually inspected. The two signatures have small, but notable differences (the reliably sourced one has more articulation; the unattributed one is more simplified, though they are also different in years.) I appreciate the discussion about the relative merits of .svg images. I've built .svg's for articles myself. Rather, the problem is the editor has not yet shown a willingness to achieve a consensus for such changes. Wtfiv (talk) 17:45, 27 February 2024 (UTC)

To illustrate the issue:

current signature from Gerhard Ritter

Tveol1091 version from commercial fine art website

Wtfiv (talk) 18:02, 27 February 2024 (UTC)

I do agree that the png looks better then the svg the disruptive user uploaded. Perhaps I could convert the png to an svg. It would look exactly the same only it’d be clearer and better quality. Kind regards, Robertus Pius (Talk • Contribs) 19:55, 27 February 2024 (UTC)

Robertus,

Please do convert the first to svg and then post it. That'd be great. But do you see the difference between our discussion and what we experienced? It wasn't about the svg, per se but how it was done.

For the Frederick signature, it may work out. You and I talked, we agreed and maybe something cool- Like the original being converted to svg- will happen. I'd be delighted! Wtfiv (talk) 04:41, 28 February 2024 (UTC)

Perfect. I’ll do it in the next few days. King regards, Robertus Pius (Talk • Contribs) 05:07, 28 February 2024 (UTC)

I agree with you regarding Hugh Capet’s signature, the original looks best. Robertus Pius (Talk • Contribs) 20:05, 27 February 2024 (UTC)

I have indefinitely partially blocked Tveol1091 (talk · contribs) to prevent further disruption and have reverted all their edits where they were the most recent contributor. That action followed clear warnings pointing out the obvious, namely that mass changing articles against objections from other editors is highly disruptive. Would anyone noticing further undiscussed changes of this kind please provide information here. Dispute resolution must be followed when disagreements occur. Johnuniq (talk) 01:24, 28 February 2024 (UTC)

Johnuniq, thank you for your help in this matter. Would you have access to a tool that can batch-undo a series of new, unexplained edits that revert many of yours on signature files? See Special:Contributions/Telephone_Directory. Eric ^talk 16:03, 28 February 2024 (UTC)

Hi Johnuniq Just seconding Eric. This new account seems to want the same .svg signatures on multiple files that Tveol1091 wanted. I just reverted the one on Frederick the Great. I'm not sure the best way to proceed. I invited whoever wants to make the change to discuss, and it even looks like Robertus Pius is working on a svg that may solve address the concerns of all, but I don't want to be caught up in a what seems to be a global edit war that spans many pages. Can you offer any further help or advice? Wtfiv (talk) 16:25, 28 February 2024 (UTC)

I reverted the recent edits by Telephone Directory (talk · contribs) and left a message at their talk to say consensus from a central discussion is needed before any further changes occur. Johnuniq (talk) 01:19, 29 February 2024 (UTC)

Improving Infobox Fraternity

Working with WP:FRAT to improve the use of the Template:Infobox Fraternity. I've added a tracking category for if the "type" parameter exists, it must have a value (if not, it goes into a tracking category), but I've gotten some requests for more advanced including (generalized) put into a tracking category if the value for a specific field isn't of the form {{start date and age|1956|6|7}}, with year month and day (so no value and {{start date|1956|6}} also counts as problematic. Also, if the city and state fields have value, then zip needs to exists. Each of these would be separate tracking categories. Looking for help/examples/suggestions of videos to watch.Naraht (talk) 00:46, 1 May 2024 (UTC)