WikiProject iconInfoboxes
WikiProject iconThis page is within the scope of WikiProject Infoboxes, a collaborative effort to improve the coverage of Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.

Wikipedia:Wikipedia Signpost/WikiProject used

Political Party infobox?

A number of US State political parties are having their infobox changed from "American State Political Party" to the (more generic) "political party" which seems contrary to the purpose of having the former. Is there a movement (by this group) to eliminate the former for the latter? Is this someone not understanding the templates? Was there something in particular that did not work about the "American State Political Party" infobox? - Mjquinn_id (talk) 13:53, 8 September 2021 (UTC)[reply]

@Mjquinn id: Could you link an example of the kind of change you're talking about? -Pete Forsyth (talk) 21:52, 15 September 2021 (UTC)[reply]
Hopefully, I copied this right: [1] Then check the user's contribs: [2] Mjquinn_id (talk) 03:02, 16 September 2021 (UTC)[reply]

Advice for cleanup of invalid params?

I see multiple templates have invalid params listed at Category:Infoboxes with unknown parameters. In the case of ((Infobox organization)) it was partly due to bad TemplateEditing structures, but generally also merges/improper file usage. Are there tools that are intelligent enough to detect per template, perhaps pulling from template data? I posted a similar question at Infobox organizations talk page. Template talk:Infobox organization#Mass cleanup of invalid parameters ~ Shushugah (he/him • talk) 15:43, 13 September 2021 (UTC)[reply]

Fixing nationality parameter

An AWB task for fixing the nationality parameter will be soon be run. See User:BattyBot/Nationality. Feel free to add to this list. ― Qwerfjkltalk 19:32, 21 September 2021 (UTC)[reply]

Unsure which Infobox template to use

Moved from Wikipedia:Teahouse § Unsure which Infobox template to use
 –  ― Qwerfjkltalk 18:46, 22 September 2021 (UTC)[reply]

I've stumbled upon the list of goldfish varieties, and having had a look at the articles for many of them, it seems someone's used a centred table/number of cells in place of an Infobox proper. I haven't checked out all of the varieties, but a sample of about four shows the same thing on each.

I'm unsure which Infobox to use in their stead; I really don't edit scientific-ish articles very often, so I don't know what justifies the use of what. I think ((Infobox species)) would be correct, but having had a look at, say, varieties of chicken - about the only comparable thing I could think of - it showed ((Infobox poultry breed)). There doesn't seem to be a comparable Infobox fish breed, so would ((Infobox animal breed)) do the job? Or are these goldfish varieties more suited with ((Subspeciesbox))?

Any help would be much appreciated; it doesn't seem like a hard edit to do, I just need to know I'm using the right template. Thanks! Ineffablebookkeeper (talk) 18:40, 22 September 2021 (UTC)[reply]

Preventing useless maps based on Wikidata in Template:Infobox public transit accident

There's already enough pictures in the infobox here that a map is not necessary (even disregarding that entirely, the map should not be placed at the top of the infobox like that). Is there a way to disable this automatic import from Wikidata beyond the crude solution currently in use there (which is adding some random filler,  , which still impacts display...)? Or maybe one should add a |nomap= parameter which would disable this if included. RandomCanadian (talk / contribs) 16:52, 6 November 2021 (UTC)[reply]

Just getting rid of Wikidata use in infoboxes entirely would also be an acceptable solution. RandomCanadian (talk / contribs) 16:57, 6 November 2021 (UTC)[reply]

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 (22). 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))

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)[reply]