This is an archive of past discussions about Template:Infobox. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Not sure if this is the right place to ask, but variants of Infobox seem to be interacting badly with subsequent tables in the markup, preventing the tables from starting until the infobox on the right has finished. It's a big problem visually. Three examples:
Bamboo Blade's infoboxes (the "Infobox animanga" template) push the episode list under the "Anime episodes" section (the "Episode table" template) way down.
Mob Psycho 100's infoboxes (also "Infobox animanga") push the contents of "Volume list" (the "Graphic novel list" template) way down.
I looked around for an example that doesn't use "Infobox animanga", and the closest I could find is ALF Tales, which uses "Infobox television": if you preview the article after deleting the "Cast" section's markup, the "Episode table" template will interact with the infobox, with the same effect.
For the first two I see the IB interacting normally with the table(s), but on ALF if I clear out the content before the table it gets pushed below the IB. Not sure this is IB-specific. Primefac (talk) 18:07, 20 September 2020 (UTC)
I thought every browser would show this issue, but your results motivated me to test in more browsers. The first two pages show the problem in Opera, Safari, Vivaldi, Edge and Firefox, but in Chrome the infobox does not block the tables that follow it. I deduce from this that you're using Chrome :-) --Iritscen (talk) 18:14, 20 September 2020 (UTC)
The first two examples are using the Episode table template with a total_width=75 parameter, so if your browser window is wide enough, you won't see the issue, but as you make the browser window narrower, you'll eventually see the issue. For the third example, the width is set to 100%. -- WOSlinker (talk) 19:38, 20 September 2020 (UTC)
Oh! Thanks, that explains it. Widening my browser window a little allowed the tables to show alongside the infobox rather than below it. I'm not sure what value is typically used for Infobox's width, but 75% seems unnecessary, so I will reduce those first two articles' table widths a little. It actually makes episode listings more readable. --Iritscen (talk) 20:20, 20 September 2020 (UTC)
In general, it's a bad idea to set widths for tables and their columns, you should let the browser handle it. Basically, you don't know the characteristics of anybody else's devices, so cannot know what width they have available. --Redrose64 🌹 (talk) 22:40, 20 September 2020 (UTC)
Thanks for the advice! I removed the width specification from the Bamboo Blade article, and the table auto-fits snugly next to the infobox. The Mob Psycho 100 table works differently and needed to have "Clear = No" added to the template call, and now it auto-fits nicely next to the infobox too. --Iritscen (talk) 00:07, 21 September 2020 (UTC)
@Redrose64: If no parameter is supplied then the Episode table template uses 100% width, so it's the template that needs fixing. If you pass over a blank total_width= parameter than the table width does not get set and everything aligns fine. -- WOSlinker (talk) 08:48, 21 September 2020 (UTC)
This is true. I didn't want to get caught up in the weeds of how the other templates work, but I had to leave a blank width specification in the template call to "Episode table" in the "Bamboo Blade" article in order to get it to produce "auto" behavior. I did the same for the "Graphic novel list" template on the "Mob Psycho 100" article, but it turns out that the template works correctly when fed "Width = auto", so I have now fixed that. I've left a message on the "Episode table" template's talk page asking for a fix, since it's clearly not correct to generate a width of "auto%" when one specifies "auto" as the width for the table. I'm not sure how "appropriate" it's considered to be on Wikipedia for these two templates to default to 100% when no width parameter is specified, because I don't often get involved with template/table markup here. --Iritscen (talk) 11:26, 21 September 2020 (UTC)
I added `total_width=` as a parameter for the episodes table at The Tourist for the same reason.
Hello. If you look at the code of almost any infobox template, you will notice the parameters are also used to trigger section headers (example: {{{aphelion|}}} is used to trigger the header Orbital characteristics in {{Infobox comet}}). This is fine in most cases. But what if you have a larger logic-based argument such as a Wikidata call? Is copying the same chunk of code to both the parameter's data field and the header field the best way to go?
Is there a template which works in two or more separate areas of the same infobox, such that we could mark a part of the code (x), and create an arguement in another part which goes as output y if x is not blank? Rehman05:28, 8 May 2020 (UTC)
Or maybe Module:Infobox could implement a way to (optionally?) enable a header if the succeeding data parameters are non-blank, until the next header? Taking {{Infobox comet}} as an example, header1 ("Discovery") will only be enabled if data2 or data3 or data4 is non-blank, ignoring everything after header5. Does this make sense? Rehman05:38, 8 May 2020 (UTC)
@Rehman: In theory this would certainly be possible in the module, and might be possible by only modifying one function (I think it would be renderRows()), but it would have to account for edge cases such as two headers being deliberately shown in a row (possibly with optional data cells between them). Considering that this could plausibly have wide-ranging effects, I think it would also be necessary to test a lot of existing infoboxes to see how they're affected by it. Jc86035 (talk) 15:34, 8 May 2020 (UTC)
Thanks for the reply, Jc86035. If we are to implement such a feature, how would you suggest we start on it? Or alternatively, can we have a separate parameter (example auto_headers=true) to opt-in this feature, if mass-enabling would be an issue? Rehman15:43, 8 May 2020 (UTC)
@Rehman: I would suggest coding the feature and testing it in the module sandbox first. I think an opt-in would be appropriate initially but it would probably be best to eventually change it to an opt-out, since theoretically it would be useful for almost every infobox. Jc86035 (talk) 15:49, 8 May 2020 (UTC)
Jc86035, Yes, I agree with you, it should be opt-out. Are you (or anyone else reading this) in a position to lead/implement this? Although I really like this feature, I'm not too familiar with this module to make changes. Rehman06:07, 9 May 2020 (UTC)
@Rehman: At the moment I would rather not, but if no one else takes it up after a while I would be fine with doing it since it seems like something that should have been implemented a long time ago. As a template editor I would also be able to make the necessary edits. Jc86035 (talk) 13:47, 9 May 2020 (UTC)
Rehman, see this thread. we almost had something, but the discussion was derailed over syntax/implementation issues. I, personally, would like to make the header conditional on a span of data parameters for template:infobox school since there may be some data that you would like to not trigger the header. Frietjes (talk) 14:18, 13 May 2020 (UTC)
Thank you for the link, Frietjes. From what I understood, this was stalled last time due to no volunteers available to code it (hopefully Jc86035 would be able to get it done once and for all this time). And the only volunteer that was there wanted to go two steps ahead into mw:Extension:Capiunto. While the latter is not necessarily a bad thing, the change is much more invasive and would probably not happen anytime soon. Hence there shouldn't be an issue with making this change, AFAICT. Rehman03:48, 15 May 2020 (UTC)
no, last time it really was derailed over syntax/implementation issues. I could program it in about an hour, but I have no desire to implement something that doesn't support template:infobox school (look at header5 in that code, for example). as far as implementation goes, we should be able to do everything in one pass. we just keep a pointer to the header and erase it if it's not needed. Frietjes (talk) 21:33, 15 May 2020 (UTC)
I'm pretty certain that the way to go is to use a blank header as a marker to terminate a block of fields that is followed by another block that has no header. Not only is that quite logical, but it keeps the implementation independent of the internal numbering of fields, improving flexibility. Personally, I'd do it in two passes: first assemble a sequential table of each row's data, and then write the wanted rows as html. I say that because the html library is not particularly fluent at removing nodes retrospectively. But that's just IMHO. I'm guessing that |header_condN= would be a little easier to implement than the |headerN-cond= suggested in the 2015 thread. --RexxS (talk) 22:14, 15 May 2020 (UTC)
RexxS, I came to the same conclusion (that two passes is better) since you can't really "erase" a node once it has been added (although there is probably an undocumented way to do it, or a way to do it with string processing on the end result). in any event, I have coded this change which does the two passes, but without any mechanism (yet) for blank headers. the easiest way to do it would be to reuse the existing numbered parameters (say |headerclass5=blank indicate a blank header). or we could have something like |emptyheader5=y, but that would require preprocessing yet another set of numbered parameters (which makes me a bit sad). Frietjes (talk) 22:47, 15 May 2020 (UTC)
Frietjes, RexxS. Maybe we could do something like this:
As default, the header would be triggered if the succeeding data parameters are non blank (as explained in my first post)
If |auto_headers=no (or whatever parameter name), the header would function as it is currently.
If |auto_headers=data1, data3, data7..., the header would be triggered only if those data parameters are non-blank.
Or, it could be the other way around for the last two:
If |no_auto_headers=all (or whatever parameter name), the header would function as it is currently.
If |no_auto_headers=data1, data3, data7..., the header would not be triggered for these data parameters.
I believe we have something that works. your idea of enumerating the data cells that are ignored is interesting, but I don't know how easily it would be to implement. if you look at the code in the sandbox, it doesn't require any text-parsing of lists, which is good. I think the only thing we are missing is syntax for a "hidden header" or a "blank header". Frietjes (talk) 14:47, 27 May 2020 (UTC)
@Rehman, Frietjes, and Jc86035: I suggest that something like |header99=BLANK would be fine to mark a new section (just as any header would), then it's simply a matter of a single test for a header with a value "BLANK" (or whatever) to suppress adding it to the rendered output. If you're going to suppress headers that would be followed by another header or the end of the list (i.e. the data fields are blank in that section), then you're already at the right point to remove blank headers from display. Hope that makes sense. --RexxS (talk) 15:08, 4 June 2020 (UTC)
RexxS, that seems to be a good way forward. I can't think of a scenario in which this is unfavourable... Frietjes, what do you think? Would there be any issue with Infobox school? Rehman08:29, 14 June 2020 (UTC)
Rehman, I implemented |header99=_BLANK_ with underscores here and I am now testing it here. as you can see, the syntax for the headers is vastly simplified. it looks pretty good in the testcases with the minor difference that a header now shows when |motto= is defined alone, where it did not trigger a header before. I can't really think of a time when you would only have the motto, with no other information, so it's probably not a big deal. if there are no other comments or objections, I will port this to the live module in the next few days. Frietjes (talk) 22:36, 14 June 2020 (UTC)
@Frietjes and Rehman: Thank you both for all the work you've put into this improvement. It will allow a sea-change in the way infoboxes can be designed once editors learn about it, especially for Wikidata-aware infoboxes. I'll ping Mike Peel who may be very interested. I have absolutely no concerns and would be happy to see the new version implemented, although you may have to spend some time writing a mini-tutorial for the documentation. Cheers --RexxS (talk) 17:42, 25 June 2020 (UTC)
So, just to clarify, if you have a template that calls {{infobox}}, and use |autoheaders=y, you won't need the #if:<param1><param2><param3><etc> code to switch the headers on/off? Primefac (talk) 18:27, 25 June 2020 (UTC)
note that if the last row in the infobox is a header, it won't show with autoheaders. this may be a problem if the "modules" or "embedded" content is being passed through a header and not a data row. for example, I had to make this change to make sure that modules were visible in infobox school. Frietjes (talk) 19:30, 25 June 2020 (UTC)
I made a first pass at the documentation, but some expansion/revision is probably needed, especially with advice on modules, etc. Frietjes (talk) 19:31, 25 June 2020 (UTC)
I see that a _BLANK_ value to a header has been added, I assume that's there to "break up" the auto headers and won't show up? Primefac (talk) 19:45, 25 June 2020 (UTC)
yes, that's correct. if you have a data field that should not trigger a header above it, then you can use a _BLANK_ header to stop that from happening. in the case of {{infobox school}}, the footnotes and the pictures at the bottom aren't supposed to trigger the "information" header above. this feature still needs to be documented. Frietjes (talk) 21:21, 25 June 2020 (UTC)
@Primefac: Perhaps the easiest way of thinking about it is that the infobox fields are now broken up into sections starting with a header and containing a number of data fields. The end of the section is marked by the header for the next section or the end of the infobox. If the section has no non-empty data fields in a given article, the header will not be displayed in that article. Sometimes when designing an infobox, we want to mark the end of a section, but not display a header for the next section, so we now have |headerN=_BLANK_ to perform that function. Is that any help? --RexxS (talk) 12:52, 27 June 2020 (UTC)
Not clear to me :-( As I understand Infobox, any headerN section ends with: |headerN+1, or |below=, or end-of-infobox. So, in what situation is _BLANK_ needed? -DePiep (talk) 21:50, 28 June 2020 (UTC)
If you look at the Infobox school diff, you'll see that following the _BLANK_ header, there are footnotes, a picture, and potential module. You might not necessarily want the | header5 = Information header showing up if the only content (after header5) is the footnote. Same thing here; if the module params or medals are provided, we don't want the "website" header to show up, so the _BLANK_ keeps that from happening. Primefac (talk) 22:00, 28 June 2020 (UTC)
OK, clear, thx. So semantically the examplary footnote not is not 'sub' to the earlier header, but is in its own, headerless section. -DePiep (talk) 15:41, 29 June 2020 (UTC)
However, I object to the wording "was derailed" used here by Frietjes twice. That is accusative (and claiming innocence, five years after), while the neutral "did derail" or "did not mature" is available. -DePiep (talk) 13:06, 27 June 2020 (UTC)
Notes after implementation
I checked that when dataN has invisible css elements, like |data=<span style="background:yellow;"></span>, this is treated as non-empty (header will show). This is common behaviour, though might be an issue sometimes (e.g., when the data is processed in a formatting template; empty value may return such empty css tags). See /testcases#autoheaders_=_yes. Mentioned in the /doc page. -DePiep (talk) 10:11, 27 June 2020 (UTC)
That's an issue in infoboxes I've come across before when fetching information from Wikidata, so I wrote a function, "emptyor" (and a wrapper {{emptyor}}), that returns blank if its argument is just punctuation, whitespace or html tags; otherwise it returns the argument unchanged. There's some documentation at Module:WikidataIB #Function emptyor and Template:Emptyor. --RexxS (talk) 13:07, 27 June 2020 (UTC)
Caveat: when |headerN= is used out of semantics, it might become hidden (not-shown) without hint or warning. For example, when headerN is used as a footer note |header123=More in Water (data page). Better: use Infobox |below=. -DePiep (talk) 21:05, 27 June 2020 (UTC)
I was about to clean up the headers on {{Infobox television channel}} when I noticed that |header40= is immediately followed by |header41=. If I set |autoheaders=yes, header40 doesn't show. Is this one of those cases where the autoheaders won't work, or is there a way it can still be displayed that way (maybe by moving header41 and its values to a child infobox as data41)? Primefac (talk) 02:16, 28 September 2020 (UTC)
@Primefac: yes that's a problem. The algorithm used assumes only one level of hierarchy in heading levels. As soon as you try to create top-level headers like "Availability" that contain sub-headers like "Terrestrial", "Cable", "IPTV", "Streaming media" and "Satellite radio", you void the assumption about the fields being broken up into (equivalent) sections, each starting with a header. That leaves two possibilities that I can see: (a) flatten the hierarchy and use headers like "Availabilty: Terrestrial", "Availabilty: Cable", etc. or (b) move all of the subsections into a child infobox as you suggest. I suspect that the former solution will prove unpopular, despite its semantic simplicity, so I expect that you'll have to switch to a child infobox for all of the sub-sections and sub-headers (remembering that it will also need |autoheaders=y to be set), which will at least preserve the hierarchy. --RexxS (talk) 12:11, 28 September 2020 (UTC)
I would think you could embed the child infobox directly into infobox TV channel itself to provide for the subsections/headers. --Izno (talk) 17:23, 28 September 2020 (UTC)
Sure, I wasn't suggesting doing it on a per-article basis. Embedding the child infobox as label-less data41 should mean header40 will show as long as there's content in the child. --RexxS (talk) 18:14, 28 September 2020 (UTC)
Lua error on Telugu wikipedia when used through Infobox company
లువా తప్పిదం:: bad argument #1 to 'gsub' (string is not UTF-8)
Backtrace:
[C]: in function "v"
mw.ustring.lua:84: in function "gsub"
మాడ్యూల్:Infobox:19: in function "fixChildBoxes"
మాడ్యూల్:Infobox:144: in function "addRow"
మాడ్యూల్:Infobox:261: in function "renderRows"
మాడ్యూల్:Infobox:353: ?
(tail call): ?
mw.lua:518: ?
[C]: ?
Request help from the experts at English wikipedia Template maintainers.
@MSGJ:, Thanks for your response. I noticed the error on this version. Then I reported it here. Afterwards, I experimented and found that when I commented the section with ref tag "6-k", the error disappeared. But today, the error is no longer present, hence reverted the changes. Sorry to have bothered you. --Arjunaraoc (talk) 05:46, 29 September 2020 (UTC)
subheader row style
I'm trying to use |subheaderrowstyle#= to add css to a subheader row. However, it seems to be adding it to the cell instead. Looking at the code, it seems that function renderSubheaders() sets the cell css with rowcellstyle = args['subheaderstyle' .. tostring(num)] at line 198 and calls addRow() and passes them. Function addRow() adds the row css with row:cssText(rowArgs.rowstyle) at line 120 and the cell css with :cssText(rowArgs.rowcellstyle) at line 128. The issue is that the subheader does not have a rowstyle. Am I misreading the code? If not, can this be added? --Gonnym (talk) 16:24, 1 October 2020 (UTC)
Gonnym, you are reading the code correctly. there is currently no method for styling the <tr> elements for subheader, but you can style the <td> elements. I don't see any problem with adding this feature. if I recall, other infoboxes that style these subheader rows have used |subheaderclassX= with predefined classes (for example for geography infoboxes with merged rows). Frietjes (talk) 16:31, 2 October 2020 (UTC)
Question on renumbering
When editing infobox templates to insert a new label part way down, is there any automatic way to do the renumbering (e.g. as here)? {{u|Sdkb}}talk01:36, 21 October 2020 (UTC)
Hmm, Frietjes, when I go to an edit window of an infobox and try to use the script, it asks for a number, when I enter, but then doesn't do anything. Am I using it wrong (is there any documentation?) or is there a bug? {{u|Sdkb}}talk04:12, 21 October 2020 (UTC)
Sdkb I just tried it on Template:Infobox newspaper/sandbox. (1) open in edit mode, (2) enter 1 to insert a gap before label1/data1, (3) press diff to see the changes. if this isn't working, and you want me to diagnose the problem, tell me your browser/os and I can try to reproduce the problem. could be a conflict with another script or some browser incompatibility. I am using Firefox on windows and linux. Frietjes (talk) 14:45, 21 October 2020 (UTC)
Btw, if you have syntax highlighting on in your editor, it won't work. I learned this the hard way. If so, I disable it, do the gap, turn it back on. Not sure if it's the same problem in your case. ProcrastinatingReader (talk) 15:50, 21 October 2020 (UTC)
Note that diff is more a concept. If we think the idea is good, it will need some slight adjustment to obey |overridechilds= properly. Because the child doesn't know if the parent has that property set, really it needs to include its CSS along with /CHILDHEADER/, and the parent needs to replace that depending on its |overridechilds= (which only it can know). But otherwise, I think the solution would work. It may well cause some invalid CSS on infoboxes embedded as "child" when they're not actually children, but that's a misuse anyway, and it shouldn't cause styling to behave differently (just an inspect element error). ProcrastinatingReader (talk) 17:21, 1 November 2020 (UTC)
Infobox galaxy
Hello, the "infobox galaxy" should have the "credit" parameter for the image, just like other astronomical infoboxes such as open cluster, globular cluster, nebula, etc. Seems like that would be a simple addition, but I've never modified a template before. Assambrew (talk) 23:56, 16 November 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This edit request to Template:Infobox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Thank you for the reply, MSGJ. Someone's code is fucked up. I was on the page in question when I clicked to make the edit request. Grr! Working backward... done.
Primefac: I was clear about the changes I want to be made, other than due to the fault of someone else's code:
{{helpme}} => figured out. I clicked on Edit request here: https://wiki.riteme.site/w/index.php?title=Template:Infobox&action=edit. (Main Infobox) You may need to visit it while logged out to see it.Primefac or someone please look into fixing whatever broken code there It wasn't broken code that sent my request here. (Yes, I did the right thing: I followed the instructions.)
But you've identified the sub-template where the fix would happen, and demand that its talk page must be where it is discussed? You like making people wrong for following instructions?
They may appear to have been unhelpful, but the editors above were giving you the correct advice. Infobox software is not a subtemplate (we call it a "wrapper" template) and it is important that requests are made on the right talk page so others can comment and see what changes are being made. — Martin (MSGJ · talk) 09:43, 8 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
While Aklapper is right to point out that it's an issue for Common.css for desktop, we basically don't do the styles for mobile (today, anyway; it's in a future, just don't know which future). I'm not really sure why he closed it, accordingly. --Izno (talk) 21:39, 7 January 2021 (UTC)
There is a related problem on Timeless: the infoboxes are taking up full width when they should only be taking part of the screen. Aasim (talk) 00:58, 10 January 2021 (UTC)
there are some text display problems in Infoboxes, within PDF files (Page Size: ISO A1 & others). namely, cropping of last letter of words on right margin. and some words appearing below bottom margin of cells.. Gfigstalk13:16, 14 January 2021 (UTC)
I am embedding two infoboxes. When I put them in the one order (first example) everything displays correctly. When I change the order (second example) the formatting of the second title goes skew. How can I fix this? Thanks — Martin (MSGJ · talk) 12:03, 17 March 2021 (UTC)
I actually think it's {{infobox lighthouse}}. I don't think I've ever seen a |headerX={{{module}}} setting before; generally the {{{module}}} parameter is passed to a |dataX= value. Primefac (talk) 12:19, 17 March 2021 (UTC)
I could be wrong, but as far as embedding goes both templates use the same |child= settings, but I'm also only looking for the big/obvious differences (i.e. I could very well be wrong). I'm curious to know if that actually is the issue, so if you sandbox any changes let me know. Primefac (talk) 12:56, 17 March 2021 (UTC)
Changed to use data on the sandbox, and the only difference is the lack of bolding ... — Martin (MSGJ · talk) 15:30, 17 March 2021 (UTC)
By the way is there any better way to achieve the styling in the subheaders? At the moment I am putting them in a divbox. — Martin (MSGJ · talk) 15:31, 17 March 2021 (UTC)
It would be nice if titlestyle would work for this, but for some reason it has no effect ... — Martin (MSGJ · talk) 20:19, 17 March 2021 (UTC)
MSGJ: When you use |title= with |child=yes the contents of |title= is passed unstyled to the parent infobox. What you can do is use |subheader= when |child=yes and |title= in other cases. The contents of |subheader= are styled when passed with |child=yes. For example, this version. Plastikspork―Œ(talk)14:39, 18 March 2021 (UTC)
Nice. I would suggest this could be made the default behaviour of |title= with |child=yes but no doubt that would have unintended consequences. — Martin (MSGJ · talk) 18:50, 18 March 2021 (UTC)
Yes, changing the functionality would require a lot of edits to templates that expect this behaviour. Other "gotcha" is that |above= is omitted when |child=yes. I believe the rationale dates back to when the child boxes were first designed (first examples was for "internet personality information) and we didn't want the person's name to appear as a heading in the middle of the infobox. Back then, most infoboxes uses |above= for the "name" and not the currently-more-common "title". In any case, it's not that hard to hack around, so probably not worth rewriting the system. Thanks! Plastikspork―Œ(talk)21:25, 18 March 2021 (UTC)
Initial TemplateStyles implementation
We're still a long way from TemplateStyles in this template for the base styles (advertisement: come help at MediaWiki talk:Common.css/to do), but there are some other classes in Common.css which I can start removing (particularly .geography) to the infoboxes using that class and then removing from here. I have made a couple changes to the sandbox to allow that more gracefully. And also moved a bunch of CSS to Common.css that was previously being loaded in the module.
Please try it out and let me know if you see any issues in the next couple of days. While I think I got everything correct, it's possible there's an error in how I framed things somewhere. --Izno (talk) 05:39, 16 February 2021 (UTC)
Question 1: @Frietjes: Do you have any memory why a child infobox3col needed auto margin and a subbox infobox3col uses a -3px margin? And/or why that same distinction never appeared in Module:Infobox (since moved to Common.css)? --Izno (talk) 18:22, 16 February 2021 (UTC)
Infobox3col looks kind of neglected TBH. There are other things that look like they have desynced from the main infobox module. --Izno (talk) 18:32, 16 February 2021 (UTC)
Izno, it's been awhile, but if I recall, the issue is how "child" boxes work. in the standard infobox they are basically a hack like </td></tr><tr><th>label1</th><td>data1</td></tr>...<tr><td> that can be inserted inside of another infobox and the end result is a single table. this works if both infoboxes are using two columns. unfortunately, people try to mix and match and infobox3cols children inside of a standard infobox, which wouldn't work if infobox3cols used the same hack. instead, infobox3cols creates an entirely new table, and the negative margin (for subbox) is used compensate for the padding in the parent cell. since we already have string processing in module:infobox a better method would be to have module:infobox detect that it is being passed a infobox3cols subbox and automatically remove the padding. if you want to play around with it, you can stuff like {{infobox|above=outer box|datastyle=background:cornsilk|labelstyle=background:wheat|label1=label1|data1=data1|data2={{infobox3cols|subbox=yes|labelstyle=background:pink|label1=second label1|datastyle=background:seagreen;|data1a=child data1a|data1b=child data2a}}|data3={{infobox|child=yes|label1=third label1|data1=third data1}}|below=below}} etc. adding coloring helps see the cell boundaries and which infobox is adding the coloring to the various cells. if you change the "subbox" to "child" you will see the difference in the label alignment. you can find child and subbox examples in Template:Infobox/testcases and Template:Infobox3cols/testcases (see football biography embedded in person). the advantage/disadvantage of the subbox approach is that you don't get a single table. this is good when you don't want the columns to stay aligned for all the content (e.g., a section with long labels), but bad when you want the columns to stay aligned for all the content. Frietjes (talk) 00:52, 19 February 2021 (UTC)
How is that "random external link spam"? We already have dozens of templates that link to other Wikimedia projects. Instead of having several, large and clumsy looking {{wikiquote}} like templates at the bottom, where it's hard for casual readers to notice, we can have a much smaller and better looking link in the infobox. Not to mention, the infobox is the perfect place for it. Sławobóg (talk) 09:34, 28 April 2021 (UTC)
What leads you to believe it's the perfect place? Seems more reasonable the perfect place is with the other external links. Nikkimaria (talk) 13:04, 28 April 2021 (UTC)
The {{{above}}} parameter was centered before but is now left-aligned. Was this a deliberate choice? There's quite a few infoboxes (e.g. settlement, building, station) that use the parameter as the title field, so now it looks quite off. SounderBruce20:17, 1 May 2021 (UTC)
Hi. I'm trying to update this module in Persian Wikipedia (rtl) where infoboxes are placed at the left side of the page. As i'm not very familiar with Lua, i need some help. When i use the enwiki version of the module, some long text like image caption don't break and make the infobox larger in width (you can see an example here and the beta module is here). I need to fix the width so it doesn't change when you enter a long caption or some other long text. Can you guys please help me doing it? Regards. Jeeputer (talk) 13:05, 11 April 2021 (UTC)
@Jeeputer: It has nothing to do with the text direction. On the English Wikipedia, MediaWiki:Common.css#L-324 sets the infobox width to 22em (22 times the width of the “m” letter). On the Persian Wikipedia, fa:MediaWiki:Common.css has no such rule, so the infobox is as wide as necessary. You could have this rule added to Common.css, but beware that it affects all infoboxes on Persian Wikipedia, not only the ones that are based on this enwiki template. A safer method is to add a new CSS class to the infoboxes at fa:پودمان:Infobox/آزمایشی#L-427 (e.g. change 'infobox' to 'infobox enwiki-infobox'), and scope the CSS rule to that, probably using TemplateStyles so that you don’t need interface administrator help. —Tacsipacsi (talk) 13:27, 11 April 2021 (UTC)
@Tacsipacsi: Thank you. It is done for now by changing the CSS class. I will consider asking interface admins to make the necessary changes. Thank you again. :) —Jeeputer (talk) 13:54, 11 April 2021 (UTC)
As a note Jeeputer, our infobox module should have no inline styles directly in it any more. All of it is in Common.css or Mobile.css now, and today you could probably take our CSS (without the lines about th and td, maybe) and put them in TemplateStyles. The infobox module does support TemplateStyles though I'm not sure if I've documented it yet. You would need to uncomment out the group at Module:Infobox#L-381 and separately L-405 and then select an appropriate page for fa.wiki, probably Module:Infobox/styles.css here. (Right now the module references a table in a configuration module that doesn't exist for infobox; that's a copy-paste I made to remind me to work on the i18n here.) We just have about 5000 pages to clean up first before we enact TemplateStyles here though.
Let me know if you need other help since I've been digging in the module recently enough. Izno (talk) 21:20, 1 May 2021 (UTC)
@Izno Thank you for your help. I'm sure i will need your help next time i try to update this module (or maybe other modules). Best. Jeeputer (talk) 01:55, 2 May 2021 (UTC)
@Tacsipacsi:: We are updating ours style based on English Wikipedia just that this line needs a @noflip so that for people who use RTL languages as interface language in English Wikipedia (the whole point of @noflip tags on the file) the infobox navbar won't get an unnecessary flip, feel free to consider that (the thing ease my work as I usually those are the one I should flip manually to update fawiki style). Thanks! −ebrahimtalk14:34, 11 April 2021 (UTC)
Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Primefac (talk) 18:56, 20 December 2020 (UTC)
Not done Duplicate request, already requested at Template talk:Infobox software. * Pppery * it has begun... 22:47, 3 January 2021 (UTC)
Done Wasn't requested at Template talk:Infobox software 'till long after request here.--50.201.195.170 (talk) 22:59, 7 January 2021 (UTC)
04:23, 28 April 2021 (UTC)
