Template talk:Infobox/Archive 18

Archive 15

Archive 16

Archive 17

Archive 18

Archive 19

Default name issue

Infobox/Archive 18
Location
Birmingham

Nickname	Fred

As can be seen from the above examples ({{Infobox school}}; {{Infobox organization}}, respectvley), the expected "defaults to {{PAGENAME}}, if not provided" behaviour for |name= is not operating. I have been unable to determine the cause. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:22, 14 May 2021 (UTC)

Fixed in {{Infobox school}} with this edit. I don't know why exactly, but the fallback syntax isn't working when the parameter is defined but empty, but it seems a MediaWiki issue not a {{Infobox}} one. Swapping out the fallback syntax with {{If empty}} seems to work. ProcrastinatingReader (talk) 15:34, 14 May 2021 (UTC)

Indeed, this is how MW deals with parameters. While |name= might not have any content, the fact that it is called means that it triggers that part of

| title = {{{name|{{{organization_name|{{{Non-profit_name|{{PAGENAMEBASE}}}}}}}}}}}

and thus means that it never gets to PAGENAMEBASE. Indeed, if you want to ensure that non-blank parameters will be ignored, you do a change like the one made by PR linked above. Primefac (talk) 17:59, 14 May 2021 (UTC)

By the way, since {{PAGENAMEBASE}} is a template and not a magic word, its behavior can be changed. In its huwiki version, I introduced a |felülír= (“override”) parameter, which solves this problem with a slightly even more concise solution than {{if empty}}: instead of {{if empty|{{{param|}}}|{{PAGENAMEBASE}}}}, one can write {{PAGENAMEBASE|override={{{param|}}}}}. Feel free to adopt it if you think it’s useful on enwiki as well. —Tacsipacsi (talk) 21:07, 14 May 2021 (UTC)

Interesting idea, Tacsipacsi, however most of the templates that I know of use straight-up PAGENAME, which is a magic word and thus not able to be "hacked" like this. Primefac (talk) 10:49, 15 May 2021 (UTC)

Then probably most of them should be changed to use the template. Of course there are exceptions where the disambiguation is officially or unofficially part of the name (like Halle (Saale) or New York, New York), but usually it’s only an internal technicality of Wikipedia and should not be present in the infobox. —Tacsipacsi (talk) 11:37, 15 May 2021 (UTC)

This had not used to be an issue. Do we need a programme to apply the fix to all infoboxes (or at least, those based on {{Infobox}})? Or can the generic fix be applied, upstream? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:56, 15 May 2021 (UTC)

As far as I know, the wikitext parser has always (or at least ever since I joined Wikipedia nine years ago) worked this way. There are also many templates using this difference with codes like

{{#ifeq:{{{1|a}}}|{{{1|b}}}|<!-- parameter 1 is specified, empty or not empty -->|<!-- parameter 1 is not specified at all -->}}

—breaking these would be unfortunate. —Tacsipacsi (talk) 11:37, 15 May 2021 (UTC)

Consider optimize the view of subboxes in infobox

The MinervaNeue skin usually used display:block; property for <table> and <caption> elements while you see them on smaller screens (i.e. screen narrower than 720 px), but this may cause problems in infobox, numerous infobox usually used a table (by wiki markup or HTML code) to add a sub table in there, but this property making sub table narrower and shift to left even if you set width:100% property. To fix this problem, I suggest adding following rules for fix:

body.skin-minerva .infobox table {
	display: table;
}
body.skin-minerva .infobox caption {
	display: table-caption;
}

This could be either add in Template:Infobox/styles.css or report to Phabricator. -- Great Brightstar (talk) 14:17, 18 May 2021 (UTC)

Please don't start the exact same discussion as you started at MediaWiki talk:Common.css#Consider optimize the view of subboxes in infobox. See WP:MULTI. Izno (talk) 23:19, 18 May 2021 (UTC)

Also, since the thread mentioned by Izno was marked {{not done}}, WP:OTHERPARENT applies as well as WP:MULTI. --Redrose64 🌹 (talk) 07:00, 19 May 2021 (UTC)

Above/title font-size in mobile Minerva infoboxes

I've made a handful of changes today locally in infoboxes to rectify a lack of font-size styling applied by default to the above/title on mobile Minerva (such as [1] and [2]). I chatted with User:Jonesey95 about this on my talk page (see here), and they advised me that there may be an easier way of setting a default for this using TemplateStyles here, so I wanted to start a discussion. — Goszei (talk) 05:47, 26 May 2021 (UTC)

Please stop. These will need to be reversed when we get around to TemplateStyles. I told you that this was something we should live with already offwiki. Izno (talk) 06:42, 26 May 2021 (UTC)

Semi-serious question about deprecation

In the past few weeks I have noticed a heavy editing volume by GKFX replacing {{Infobox calls with {{#invoke:infobox|infoboxTemplate calls in the name of WP:PEIS. I am not necessarily here to litigate their past changes, but it has got me to thinking: this template is pretty much only used directly by wrapper templates; would it be reasonable to deprecate {{infobox}} and require users creating new {{infobox X}} templates to directly call the module? This would save editors like GKFX the necessity of potentially having to change thousands of infobox templates as they get created and heavily used. On the downside, of course, we would lose the rather valuable /doc at this template, and we'd likely have to move it to somewhere prominent enough that it would still be useful (maybe even just turn Template:Infobox into a redirect to a WP: help page?).

As I said, this is only a semi-serious question, but if I've learned anything from being an educator, if one person has a question there are at least two others who have the same one. Primefac (talk) 14:00, 1 June 2021 (UTC)

This reminds me of the recent discussion regarding where template versions should be used, which I guess is why GKFX is doing so.

That said, indeed templates become more efficient with the skipped call (PEIS is one, rendering speed another) and that the original intent (at least out of Time S's mouth) was that the meta templates be entirely replaced, at least in their uses as meta templates. There is "raw" use in the article space and elsewhere outside template space, which should still be supported by this template barring cleanup to use some Infobox X template. (That's not a use I'm going to clean up, I have bigger fish.)

In such a world, documentation should live here given that secondary use. Module:Infobox's documentation should expand to point out how to call it as a template and a module and then point here for the documentation of the parameters/arguments.

We do have at least one loss, which is that the template provides a convenient point of abstraction in case we should ever want to change the underlying name of the function (Lua supports refactoring easily with a certain idiom that you can see in the CS1 submodules).

I'd personally prefer a more wiki-idiomatic name for the function call e.g. require:Infobox|infobox.

All this if indeed we want to go down this road. (I have been thinking of late that we should consider it.) Izno (talk) 14:16, 1 June 2021 (UTC)

In terms of nice function naming, what I did at Module:Infobox3cols is set the function name to the empty string. That means you can call it concisely from wikitext as {{#invoke:infobox3cols||args...}} which looks reasonably nice and avoids having to remember a proper name. User:GKFX^talk 17:49, 1 June 2021 (UTC)

That... no, that makes it impossible to find uses. Please undo your change. GKFX Izno (talk) 17:52, 1 June 2021 (UTC)

Are you sure? In what way is it impossible to find uses? You can search for insource:"invoke:infobox3cols" quite easily. User:GKFX^talk 18:14, 1 June 2021 (UTC)

Yeah, and then you introduce a new function and then bad happens.

Please fix it. It's a basic tenant of good software engineering that your APIs should have a name. Izno (talk) 18:51, 1 June 2021 (UTC)

Izno, I'm going to treat this as a valid contest to a BOLD change. Unfortunately GKFX that means I need to hit you with a few dozen rollback notices because that's the only way to make sure nothing gets broken while we sort this out, apologies for the mess in your notifications. Primefac (talk) 12:40, 2 June 2021 (UTC)

My poor notifications! Anyway, there are three main options here considering established usage:

• #invoke:infobox3cols|infobox3cols|...
• #invoke:infobox3cols|main|...
• #invoke:infobox3cols||...

The first of these seems like we're repeating ourselves for no particular reason. The second is OK but rather generic; why specify a function name to call the only useful function exported by a module? (As is the case here.) The third, to answer Izno's follow-up, can be found unambiguously in search with insource:/infobox3cols\| *\|/. While names are certainly important, I think saying "infobox3cols" once is sufficient; the word "main" contains no more useful information than the empty string. User:GKFX^talk 12:59, 2 June 2021 (UTC)

Why do we need to change what already exists? {{infobox3cols}} already has {{#invoke:Infobox3cols|infobox}}, which means that we already have a working name.

As a minor note, if we move away from calling the template, we lose its parameter checking. Primefac (talk) 13:04, 2 June 2021 (UTC)

Seems like a major and not minor note :^). What exactly do you mean? Izno (talk) 16:10, 2 June 2021 (UTC)

{{infobox3cols}} (i3c) has the main module call but also has a Check for unknown parameters call to make sure there are no invalid parameters used. I do suppose we could incorporate that into the i3c module itself, but that seems like it might actually be more expensive. Primefac (talk) 16:19, 2 June 2021 (UTC)

I think I might consider it an antipattern to do parameter checking in a meta template using the module rather than rolling its own (if in fact needed at all)? That said, you just call _check in the module instead of calling check in the template. Izno (talk) 16:47, 2 June 2021 (UTC)

Good point (and it is the only meta template I've seen that has a parameter check). Primefac (talk) 17:16, 2 June 2021 (UTC)

It was my intention to move that check into the module exactly as described by Primefac above. I just hadn't got around to it yet. User:GKFX^talk 17:47, 2 June 2021 (UTC)

Whether you or I can find it unambiguously is not really the point. It harms new contributors when they don't understand what is going and it's just magically rendering. Heck, I didn't even know you could use the empty string as a valid function name and I've got half a mind to walk over to Phab and ban the practice on the tech side, that's how annoyed I am with the idea.

Either the function name infobox or the function name main are appropriate to me, and if the name is currently working with infobox, that's fine with me.

Please be a sight less bold in the future. You are already a (welcome) positive contributor in the template space and doing dumb things like removing a function name totally just leaves me flabbergasted. Izno (talk) 16:06, 2 June 2021 (UTC)

A slight misunderstanding seems to have crept into the above. It was never possible to call {{#invoke:infobox3cols|infobox|args...}}, so I didn't remove or rename any functionality that existed already. It is only possible to use that function with parent arguments. I created a new, useful function and called it "", which you evidently think is appalling, but that is your opinion not something which I could have known in advance. As a parallel from a different technology, git stash is in principle called as git stash <subcommand> args..., but the subcommand is allowed to be omitted in the most common case. I am doing the same thing here, IMO.

Relatively few contributors will care how modules work; if you write a doc page (and I did!) where {{#invoke:infobox3cols||args...}} is demonstrated to be working, I am sure that people will just copy-paste it and not worry what the extra vertical bar means. Contributors who want to contribute to the Lua space may be a little surprised to see the empty string used as a function name, but it is not incomprehensible to such people as they will presumably have at least skimmed the Lua documentation and know what should go in that slot of an #invoke call. User:GKFX^talk 17:46, 2 June 2021 (UTC)

Italics and Chinese in infoboxes

Many infoboxes have bits that are automatically displayed in italics or in boldface, for example italics for titles of fictional works. For titles that are in non-Latin scripts, that is wrong per MOS:BADITALICS (it can also make the text very hard to read even if you know the script). I've been going around trying to fix some Chinese in incorrect MOS:NOBOLD or italics, which either has to be done using a language code parameter or in the more pedestrian way of using {{noitalic}} or {{nobold}}, but I don't have a good way of finding all these violations. GKFX suggested that this could be done using appropriate Lua coding.

Should/Could infoboxes either

• (a) automagically display Chinese in nobold/noitalic
• (b) have a tracking category for Chinese text that lacks a "language code" parameter or {{lang}} wrapper
• (c) do both? so they display correctly and attract gnome edits to ensure everything is tagged correctly?

Of course this issue affects other scripts, but for Chinese it is especially noticeable, and some manual work may be required to notice whether text is simplified or traditional Chinese or actually Japanese or even Korean. —Kusma (talk) 12:58, 2 June 2021 (UTC)

{{infobox book}} does (a) – italics only – for the value in |title_orig= as long as there is |orig_lang_code=.

—Trappist the monk (talk) 13:23, 2 June 2021 (UTC)

What I want to do is detect infoboxes where something like |orig_lang_code= is missing. "Automagically" would be "based on the unicode block used, do not use italics". —Kusma (talk) 14:39, 2 June 2021 (UTC)

You would need to scan through the text, testing each character individually against values for the lower and upper bounds of the relevant Unicode block; if a match is found, terminate the loop and prevent bold/italics, otherwise, cycle to the next char. This sounds both slow and expensive.

Non-automagic methods are much better: if the text is enclosed in, for example, <span lang="zh">...</span> it is possible to constuct a CSS rule that uses the :lang pseudo-class to detect that and force the b element to use the declaration font-weight:normal; and the i element to use the declaration font-style:normal;. --Redrose64 🌹 (talk) 12:08, 3 June 2021 (UTC)

Now I just need a way to find text that should be enclosed in such a span but isn't... —Kusma (talk) 21:24, 3 June 2021 (UTC)

Here is Category:Infobox templates. Here is a cirrus search that looks for {{Infobox book}} templates that have parameters with values that contain CJK Unified Ideographs (U+4E00–U+9FFF). For each likely template in the category, redo the search for each template.

Here is an alternate search that is not constrained to {{Infobox book}}. But, it times out ...

These searches are cirrus searches so they are limited. If you are dedicated, you can use the first search to work through the category to determine which infoxen are likely to have parameters with CJK Unified Ideographs. You can then, perhaps, modify those infoboxen to emit a category.

—Trappist the monk (talk) 22:14, 3 June 2021 (UTC)

Thank you, this is great! I should really learn what our search function can do these days. The books search only has 127 entries in it, I can go through these on a rainy day. —Kusma (talk) 09:47, 4 June 2021 (UTC)

Both are possible is possible. I think I would much prefer just the tracking category. I am not sure I'd put the related function in this module though rather than in templates that support moving the language information to a lang code. Not all infoboxes today have or care about a language. (I am not sure if that is a good or bad thing.) Izno (talk) 16:10, 2 June 2021 (UTC)

I'd be happy with a tracking category, as there will often need to be other gnoming edits made while fixing this. I've found examples using {{Infobox book}}, {{Infobox military installation}}, {{Infobox music festival}}, some of which care and some of which don't care about the language. So just having a tracking category for "has |title_orig= but no |orig_lang_code=" wouldn't be enough to fix this. An alternative might be a massive bot run to look through the HTML of all articles and make a list of all those that have any bold or italics on anything in the Chinese unicode blocks, but I don't know how to do that either, and so I would appreciate any help by more qualified people in getting this fixed. —Kusma (talk) 10:24, 3 June 2021 (UTC)

Not-table infoboxes

I'm doing some other-wiki work and got to a point where I'm considering the correct way to produce an infobox rather than the HTML table it is today. I put together User:Izno/Sandbox/Infobox to document some of the basics of what an infobox should look like because I don't know the exact way I think it should go. Izno (talk) 23:56, 2 July 2021 (UTC)

Issue with decat of subbox prevent parent from adding tracking categories

I've ran into an issue I'm not sure how to fix. I have an infobox with a nested subbox which has 1 data row. That row can be empty, which is valid. However, if that row is empty the page is added to Category:Articles which use infobox templates with no data rows. The docs say to fix that, I should add |decat=yes. That indeed fixes that, however, if the parent template is empty, it now never gets added to that tracking category.

I've created 3 test infobox to show that it fails:

1. User:Gonnym/sandbox/infobox - regular infobox
2. User:Gonnym/sandbox/infobox subbox - infobox with subbox with no decat
3. User:Gonnym/sandbox/infobox subbox decat - infobox with subbox and decat

This can only be tested on mainspace entries so I have no tests setup. Easiest way to check, create a page with random letters (don't publish, just edit it) and add the following:

{{User:Gonnym/sandbox/infobox subbox decat
|image = Placeholder.pdf
}}

Any ideas on how to fix this? Gonnym (talk) 11:29, 6 July 2021 (UTC)

Gonnym, I believe this template returns <table></table> when there are no rows, which is not "nothing" from the view of the parent infobox. one solution would be to tweak the code so it never returns table tags with nothing inside. the most efficient solution could be to have some flag that keeps track if any content is added and then not return the table if there is nothing inside. Frietjes (talk) 14:57, 7 July 2021 (UTC)

this change should be the most efficient since the string processing only happens when there are no table rows, but if we aren't worried about that, we could just process all of them and remove empty table tags. Frietjes (talk) 15:31, 12 July 2021 (UTC)

Nice work @Frietjes! Module:Infobox/sandbox#L-245 might be redundant as Module:Infobox/sandbox#L-270 already checks the image args and addImageRow() is called at Module:Infobox/sandbox#L-281. Gonnym (talk) 16:15, 12 July 2021 (UTC)

Just noticed that currently only the dataN values are checked for emptiness (#(getArgNums('data'))), but in your code you also check headers and titles. As I'm not the one who created this tracking category, I have no idea what is more correct, but just pointing this out. Gonnym (talk) 16:29, 12 July 2021 (UTC)

Gonnym, the idea was to prevent the module from generating an empty <table>...</table> without a lot of extra string processing, so empty wouldn't apply if there is anything else in there. the tracking for no data rows was added a long time ago, see this thread. I believe the concern was the use of an "infobox" where it was just a wrapper for an image. How useful this tracking category is today, I don't know. but, the empty <table>...</table> can cause issues as you have identified above. Frietjes (talk) 21:54, 12 July 2021 (UTC)

Ok, so just so I understand, the fix done was to prevent empty tables being generated, but the tracking category for false positives will still happen? Gonnym (talk) 22:29, 12 July 2021 (UTC)

Gonnym, yes the fix was to prevent {{infobox|subbox=yes}} with no other non-blank inputs from generating a blank table tag, which then caused {{infobox|data1={{Infobox|subbox=yes}}}} to generate an infobox with a blank row (and possibly trigger ghost headers). I didn't do anything to the "no data rows" tracking category, which may or may not be a useful tracking category. but, I suppose there may be more now in that category since the subbox won't generate a blank table tag in the parent's infobox. Frietjes (talk) 14:26, 13 July 2021 (UTC)

Weird advice about images in the documentation

This is a non-standard use of infoboxes, and looks like ass. Yet the documentation page says: image(n) images to display at the top of the template. Use full image syntax, for example [[File:example.png|200px|alt=Example alt text]]. Image is centered by default. See WP:ALT for more on alt text.

What's up with that? jp×g 20:11, 2 September 2021 (UTC)

The article uses {{infobox islands}}; the documentation for that template says image = locator/satellite/other map image (without the prefix "File:" or "Image:") MB 20:31, 2 September 2021 (UTC)

@JPxG: It looks like ass because it uses the |thumb parameter. This should never be used for infobox images; if that is omitted, the image is much more presentable. WP:INFOBOXIMAGE is explicit: When adding an image to an infobox, thumbnails should NOT be used. See also Help:Infobox picture#My image is displayed, but is inside an extra frame. --Redrose64 🌹 (talk) 23:00, 2 September 2021 (UTC)

@Redrose64: Right, I never use the thumb parameter for infoboxes -- why does the documentation say to do that, then? jp×g 23:04, 2 September 2021 (UTC)

Do you mean Template:Infobox/doc or Template:Infobox islands/doc? The word "thumb" doesn't occur in either. Are you looking at a different template? --Redrose64 🌹 (talk) 23:39, 2 September 2021 (UTC)

The "module" system

Your feedback is requested at Template talk:Infobox settlement#TemplateStyles. Izno (talk) 18:05, 8 September 2021 (UTC)

Fix for empty cells with child boxes

I made a couple changes in the module sandbox which addresses a couple problems. (1) generate templatestyles in both the child and non-child cases, (2) move tracking categories and templatestyles between table rows to inside the table rows. as far as I can tell, this fixes the blank cells that are being generated when the module "fixes" child boxes. for example, see case 16 mentioned in the thread above. please let me know if you see a problem with the changes. if there are no objections, I plan to roll this out into the main module. thank you. Frietjes (talk) 19:45, 27 September 2021 (UTC)

Thanks for looking into this. It may fix the two empty rows on Belas, Luanda too. — Martin (MSGJ · talk) 20:58, 27 September 2021 (UTC)

Looks good to me! Thanks! Plastikspork _―Œ^(talk) 22:54, 27 September 2021 (UTC)

now implemented, please revert and/or let me know if there is a problem. it looks like it fixed some of the empty cells, but not all. when I have more time, I will see if I can figure out what is generating the other empty cells. Frietjes (talk) 14:06, 29 September 2021 (UTC)

Frietjes, after some testing it looks like you need to use this pattern instead because the templatestyles will be replaced by a strip-marker at this point. It looks like this fixes the extra newline in Case 16. Thanks! Plastikspork _―Œ^(talk) 17:02, 10 October 2021 (UTC)

Plastikspork, awesome! I was wondering why the other match wasn't working. thank you. Frietjes (talk) 22:51, 10 October 2021 (UTC)

@Izno: this quite likely fixed the issue pointed out in this revert of your changes. Before this change, child boxes that added templatestyles were generating blank rows. I updated the sandbox of {{Infobox officeholder}} to use the sandbox module if anyone wants to do more testing. Thanks! Plastikspork _―Œ^(talk) 17:10, 10 October 2021 (UTC)

I hadn't had a chance to take a look at the revert, but strip markers makes sense as the cause. Izno (talk) 17:13, 10 October 2021 (UTC)

(Good thing it was with such a small bit of styles. :^) Izno (talk) 20:36, 10 October 2021 (UTC)

Discussion on an automatic short description

You are invited to join a discussion at Template talk:Infobox writer § Proposed short description.
The following is another user's helpful summary of the long discussion:

There is a question as to whether the short description for a page that contains the "writer" infobox should include the subject person's nationality as given by the "nationality" field in that infobox. (The infobox does not generate any short description today, but it is proposed that it do so). One editor believes it would improve the quality of the short description if it did; another believes this would encourage people to fill in "nationality" just for this effect, in cases where it should not be filled in. WP:INFONAT says not to fill in "nationality" when it's redundant with birthplace. There is some disagreement over whether this can be resolved with documentation.

There was a request for a WP:Third opinion, which was erroneously rejected because the 3O volunteer thought there were more than two disputants. This was because the same talk page section contained contributions by others on other matters.

Qwerfjkltalk 10:32, 27 October 2021 (UTC)

Edit request to complete TfD nomination

Template:Infobox/styles.css has been listed at Templates for discussion (nomination), but it was protected, so it could not be tagged. Please add:

/* {{subst:template for discussion|help=off}} */

to the top of the page to complete the nomination. Thank you. Q28 hope you pay attention to TFD 01:55, 27 November 2021 (UTC)

@Q28: you can't SUBST on css content models, please put the expanded version of what you want added in to the edit request. — xaosflux ^Talk 02:23, 27 November 2021 (UTC)

 Not done: The page's protection level has changed since this request was placed. You should now be able to edit the page yourself. If you still seem to be unable to, please reopen the request with further details. Izno (talk) 17:41, 27 November 2021 (UTC)

Creating an embedded infobox with Lua

Are there instructions somewhere for creating an embedded infobox with Lua? I've been working on {{Infobox road}} for a while and the examples that are there already aren't necessarily the direction I want to go. –Fredddie™ 22:28, 30 November 2021 (UTC)

Help - class parameter

Hello!

Kind of a newbie question: Can someone help me by explaining what the "class" parameter serves for used in most infoboxes, beside "label" and "data"? I've imported some of EnWiki's infoboxes to my homewiki (SqWiki) and I was taking care with the needed localization but I wasn't sure if I should be translating the class values or not.

Also, staying on the same topic, if someone can help me understand how the "Parent(s)" parameter works in the {{Infobox person}}, I'd be grateful. I got confused by its multinested structure.

Thanks in advance! :) - Klein Muçi (talk) 22:33, 4 December 2021 (UTC)

@Klein Muçi: See Template:Infobox#HTML classes and microformats, under class ― Qwerfjkltalk 22:47, 4 December 2021 (UTC)

@Qwerfjkl, uhm, so... They shouldn't be translated? I read that and some information about microformats in general but I'm still not sure how they are utilized by various software. I'm new to the topic. (Maybe I should have read the article until the end. :P ) - Klein Muçi (talk) 23:20, 4 December 2021 (UTC)

Explanation of the parameter 'name'

I just tried to find out what the parameter 'name' exactly does. The description say's that the Navbar will link to the given page name, but when I give it a name it will link to a Template page called like that. Am I doing something wrong or is it like the Documentation of Template:Navbar say's that is used to link directly to the template to edit it's content? If that's the case the documentation here would need some optimization. --DesignerThan (talk) 23:29, 12 January 2022 (UTC)

@DesignerThan: It links to a template page if no namespace is specified. I have updated the documentation.[3] I don't think there is ever reason to link to mainspace but you can do it by starting the value with a colon. PrimeHunter (talk) 01:40, 13 January 2022 (UTC)

@DesignerThan: The sole purpose of the |name= parameter is to add three links (v-t-e) at the bottom-right corner. These are for giving access to the underlying infobox code and its talk page, and when used the |name= parameter must be set to the name of the infobox. Thus, if Template:Infobox person had theis parameter (it doesn't), it would be set as |name=Infobox person. The feature is rarely necessary and indeed the "e" link can be harmful, and so is hardly ever used. --Redrose64 🌹 (talk) 17:05, 13 January 2022 (UTC)

@Redrose64:@PrimeHunter: Thank's for the explanation. That help's me. Wish you a happy new year! --DesignerThan (talk) 22:46, 13 January 2022 (UTC)

autoheaders=no

§ Hiding headers when all its data fields are empty Documentation says |autoheaders=y = don't show header when its section is empty. All fine.

But the same effect is reached when one enters |autoheaders=no??? This is caused by code

if not args.autoheaders then return end

Of course, this is bad coding practice and non-intuitive. I propose to adjust the logic. First suggestion would be to apply Module:Yesno here. -DePiep (talk) 12:09, 21 January 2022 (UTC)

While I do agree that it's not strictly intuitive, the documentation does state If this is set to any non-blank value..., as well as an entire section describing it. Also, the default is always to have headers, so having an |autoheaders=no is like saying "don't avoid the car in front of you" - it makes no sense. In other words, it's not a binary "headers yes/no" type of check, more of an "#ifexists" check. Primefac (talk) 12:51, 21 January 2022 (UTC)

Well, I wanted to use |autoheaders=no to mark explicitly to fellow-coders that that y-option should not be used (for good reason).

I get the (coder's) background reasoning, as in 'it works, so.', but non-intuitive it is. "yeah it's stupid, but its documented". I do not get the programmers choice to do it this way; there is no need but carelessness. (Same or worse: {{slink}} has |nopage=yes??; {{collapse top}} has |expand=noN). How did this became a programmers accepted habit? -DePiep (talk) 13:06, 21 January 2022 (UTC)

I'm not saying it can't be changed, mind you, I'm just saying that at the moment there is nothing implying that "no" is a valid option for not having it. I'm rather apathetic about the matter myself, to be honest, so as usual I will await further discussion. Primefac (talk) 13:34, 21 January 2022 (UTC)

Sure, got that. My wondering is left, trying to learn something from BigCoding. -DePiep (talk) 14:41, 21 January 2022 (UTC)

If I had a choice, it would be auto-headers for everyone without any opt out (because I cannot conceive of a reason for otherwise), though as with when it was first implemented, that would require adjustment for the 1500 templates using the infobox template. Izno (talk) 18:30, 21 January 2022 (UTC)

@Izno: obvious, because those if-clauses are a nuisance (and ofter hard to do right). But the question is:

Why do |autoheaders=yes and |autoheaders=no have the same effect (namely "true")? I cannot see any reason but sloppyness in coding (eg not minding users like template editors). Unless there is a higher level explanation I do not see yet, I propose to change it. -DePiep (talk) 05:56, 22 January 2022 (UTC)

As I said above, the parameter autoheaders is not a "yes/no" parameter; the specific module line is if not args.autoheaders then return end, which in wiki-template language is basically {{#if:{{{autoheaders|}}}...}} We use this sort of coding all over the place (i.e. not every #if: is an #ifeq:). Primefac (talk) 14:53, 22 January 2022 (UTC)

Indeed, this pattern is all over the place if we do not think we need a strict test, and in this case, we don't. Izno (talk) 17:56, 22 January 2022 (UTC)

template for idioms?

Is there a template for idioms?

Is there a template for spy operations, such as MKUltra? Quiet2 (talk) 04:20, 30 January 2022 (UTC)

https://wiki.riteme.site/wiki/Wikipedia:List_of_infoboxes — Preceding unsigned comment added by Quiet2 (talk • contribs) 04:21, 30 January 2022 (UTC)

Image handling

Shouldn't this include a |credit= (or |credit#= for each image), to add a line beneath the caption to indicate image credit, as is required by some imagery? -- 65.92.246.142 (talk) 21:30, 31 January 2022 (UTC)

If that's necessary, then |caption= suffices. Izno (talk) 22:07, 31 January 2022 (UTC)

It would be useful if it were a standardized format, such as commonly found elsewhere, a right-aligned text entry; instead of the centre-aligned caption text. If it isn't a feature of infobox, perhaps a supplementary template, that is called with |caption= like {{credit line}} which creates a div to insert into the |caption= after the caption text?

{{infobox (or derivation xyz)
|image=imagexyz
|caption=caption text {{credit line|required sourcing credit}}
|other params
}}

with {{credit line}} being:

<div style="text-align:{{{alignment|right}}};"><small>{{{credits}}}</small></div>

-- 65.92.246.142 (talk) 12:51, 1 February 2022 (UTC)

First off, <small>...</small> is forbidden inside infoboxes. Apart from that, MOS:CREDITS applies - if you want to know the name of the photographer, click the image. --Redrose64 🌹 (talk) 16:00, 1 February 2022 (UTC)

Ah, I was pretty sure there was something in the MOS about it. Izno (talk) 18:08, 1 February 2022 (UTC)

extra hidden or invisible space

What am I doing wrong?

In my sandbox (permalink) are comparisons of a new version of ship infobox that uses Module:Infobox in place of a wikitable. Individual sections of the infobox are implemented as |section<n>={{#invoke:Infobox ship|<section function>|...}} where |section<n>= is an alias of (and internally translated to) |data<n>=. This mechanism is taken from the examples at Template:Infobox § Embedding.

Note the space between the infobox top border and the top of the image in the side-by-side comparisons. The gap is larger in the right (new) infobox. Hover your mouse over the image in the right infobox and right-click → inspect. Between the <tbody> tag and the image's <tr>...</tr> tag is another <tr>...</tr> tag which holds something that looks more-or-less like this:

<tr><td colspan="2" class="infobox-full-data"><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r1066479718"></td></tr>

Should that be there? If not, what am I doing wrong?

—Trappist the monk (talk) 15:38, 21 May 2022 (UTC)

Probably shouldn't be there, but you're probably not doing anything wrong. That TemplateStyles corresponds to Module:Infobox/styles.css (note that mw-data:TemplateStyles:r1066479718 indicates the page revision of the TemplateStyles page injected). Since the row exists, it's getting the associated padding from the CSS being applied to infobox-full-data which is why there is more.

The specific issue relates to Template talk:Infobox/Archive 18#Fix for empty cells with child boxes. Izno (talk) 17:25, 21 May 2022 (UTC)

Add a section "Discuss editing/improving an infobox template"

Let's take the infobox on the president of your country, the USA, European Commission, whatever. They contain more or less the same kind of quick overview data, but there are slight differences for example in some the start of the term is mentioned but not the end of the term of their presidency. Imagine you want to discuss to add that or anything else in an infobox. Isn't it worth adding a section with good practices on how to proceed? To me it is not clear what consequences adding that end of term for example. It reads that templates contain "repetitive material that may need to show up on multiple articles or pages, often with customizable input. Most templates are scripts using MediaWiki parser functions, nicknamed "magic words", a simple scripting language." So the start of the term date, is that extracted from a dedicated article; idem the ending date of the president's term? And are those then taken along into other articles using magic words? Thy, SvenAERTS (talk) 12:12, 12 June 2022 (UTC)

I'm a little unsure of what you're asking, but the place to discuss editing or updating any infobox is either the article's talk page (if it's missing information) or the template talk page (if the template itself needs extra/new fields).

So the start of the term date, is that extracted from a dedicated article - no, it is a parameter in the template, something like |start_date=YYYY, which is generally located at the top of the article.

And are those then taken along into other articles using magic words - no, the Magic words in question are things like #if, {{PAGENAME}}, and other "equation-like" things that make the information appear with the same formatting on every page. Primefac (talk) 16:01, 12 June 2022 (UTC)

The issue of interpuncts on mobile

Apologies if this has been raised elsewhere before, but last month a user raised a concern that interpuncts, the separations between list items, do not display at all on mobile in Template:Infobox album. However, it looks like this is a mobile issue in all infoboxes and perhaps Wikipedia at large. Is this just something that can't be helped, like (some) mobile devices cannot display interpuncts correctly, or is there a kind of formatting workaround that could be implemented to make them display on mobile devices when not using flatlists in an infobox? I'm raising this here in the hopes of users not needing to keep implementing local workarounds like restoring/adding flatlists back to infoboxes to make list items display. Ss112 10:26, 8 July 2022 (UTC)

I've fixed it for this one. This issue should be fixed naturally when MediaWiki talk:Common.css/to do#Hlist is done. Izno (talk) 17:35, 8 July 2022 (UTC)

@Izno: Thanks very much for doing this. Ss112 17:25, 9 July 2022 (UTC)

New line in label

I have been trying to add a new line in | label but it won't work. I decided to make some more labels to make it go underneath but it doesn't look natural. It is kind of alligned to the center in the parameters of the infobox label space. So, I am here to ask if there is any solution possible or whatsoever regarding to this concern of mine. Thanks in advance. FusionStyleFX (talk) 17:34, 10 August 2022 (UTC)

FusionStyleFX, could you give a little more information please? Where have you been trying this? Primefac (talk) 19:38, 10 August 2022 (UTC)

I actually mistook the conceptions. Data won't work with a new line/row on:

{{Infobox

| title = Example

| headerstyle = background:lightgrey

| header1 = Header1 with empty section

| label4 = label4 text

| data4 = Example (I want a new line here)

When I click enter, visually nothing happens and it reamains the same.

}}

I have been trying this in a wikipage of mine (which is not released yet) FusionStyleFX (talk) 21:33, 10 August 2022 (UTC)

If you want to add a line break in a label or data field, you should use either a <br/>, {{pb}}, or {{plainlist}} to do so. Primefac (talk) 07:52, 11 August 2022 (UTC)

Require a 'new' parameter to the Sports infobox

Would someone add a "host state" to Template:Infobox games, as the 2026 Commonwealth Games have chosen a host state, rather then a host city. GoodDay (talk) 03:21, 15 August 2022 (UTC)

Please do not multi-post. For others, see that template's version of this request. Izno (talk) 04:33, 15 August 2022 (UTC)

Had to, as the Infobox games template, gets little attention. GoodDay (talk) 06:56, 15 August 2022 (UTC)

Advertisement is reasonable. Making the same post without reference to the earlier is not. Izno (talk) 14:56, 15 August 2022 (UTC)

Maximum number

This produces no output:

{{infobox
| label95  = [[Water turbine|Turbines]]
| data95   = 6x 45.0 MW
}}

I thought there was no maximum number of rows that were recognised? — Martin (MSGJ · talk) 13:37, 14 October 2022 (UTC)

There isn't a max, but I do feel like there is a minimum, or potentially a maximum gap size; I feel like I've seen similar issues where I jumped too many numbers and the bottom stuff didn't show. Primefac (talk) 13:50, 14 October 2022 (UTC)

Maybe something to do with the step parameter which is set at 50? — Martin (MSGJ · talk) 13:52, 14 October 2022 (UTC)

Yes, it searches 50 numbers ahead each time it finds numbered parameters. Do you have a real use case where 50 is too little and the code couldn't easily be changed to work with 50? PrimeHunter (talk) 13:58, 14 October 2022 (UTC)

Not really. I copied some code into a child subbox and it was more convenient to leave the numbers as they were! But I can renumber them, no problem. Just wondered and it was hard to track down the problem. — Martin (MSGJ · talk) 14:01, 14 October 2022 (UTC)

If I had to guess, it's not stated in the documentation because the folks who wrote it weren't thinking about anyone skipping 50+ numbers in their labelling. Primefac (talk) 14:06, 14 October 2022 (UTC)

Yes, it's rather an extreme case! — Martin (MSGJ · talk) 14:14, 14 October 2022 (UTC)

I have added this: "There is no upper limit on numbers but there must be at most 50 between each used number."[4] PrimeHunter (talk) 14:16, 14 October 2022 (UTC)

Well, everything in computers has an upper limit somewhere but it may be really big. I wondered whether it would be the 2 MB page size limit but it's much smaller. This works: {{Infobox|data50=|data100=|data150=|...|data80900=|data80950=data80950!}} With data81000 it gives "Lua error: not enough memory." I'm not going to mention that as a number limit. PrimeHunter (talk) 14:36, 14 October 2022 (UTC)

You were obviously having a slow day ;) — Martin (MSGJ · talk) 07:37, 16 October 2022 (UTC)

box-wide data field

What would be a good option to present |datan= in box-wide column instead of regular columnwide (righthand side)? Could be some css form, could be a child-infobox. Preferably, left-align should be possible too. DePiep (talk) 14:44, 28 November 2022 (UTC)

I don't understand what you are asking for. If you use e.g. |data1= without also using |label1=, it occupies the full width. --Redrose64 🌹 (talk) 18:43, 28 November 2022 (UTC)

TemplateStyles for plainlist

I've made a change in the sandbox which allows for automatic detection of plainlist class (today) to insert the relevant styles as TemplateStyles. This is essentially as described at Template talk:Navbox#TemplateStyles for plainlist part 1. If you have questions, please feel free to inquire over there.

I also noticed that the module was calling {{italic title}} rather than its module interface, and so there is a change queued for that as well. I noticed a discussion in the archives about accessing the full function of that module, but I leave others to work on that in the arbitrary future. Izno (talk) 00:17, 17 December 2022 (UTC)