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.
I want to add a labeltext, but cannot reach that through regular |label10=... input. Is there a correct way to create it semantically correct (instead of just bolding it)?
That must be it (they did not name it "/iw"). But hey, somewhere in code that Infobox/i18n module name must have been constructed & called -DePiep (talk) 22:10, 19 October 2017 (UTC)
As I understand it, calling a separate module in addition to any internationalisation already present should help allow another language Wikipedia to make use of our modules by packaging common changes for their language. That then avoids having to make wholescale modifications to the main module, so that they can import it (and regularly re-import it in order to update). In en-wp we don't have that problem, so generally the /i18n module doesn't exist. It would, of course be simple enough to create an essentially empty module if the redlinks were to cause problems. --RexxS (talk) 22:54, 19 October 2017 (UTC)
Searching Module:Wikidata shows where it invokes Module:I18n. The latter attempts to load the /i18n submodule. If it exists, its table replaces the enwiki i18n table that is in Module:Wikidata (actually, it is merged, so where specified, /i18n values replace the corresponding English values). There are two really puzzling aspects of the code that I don't want to spend hours analyzing so I'll just mention them. First, Module:Wikidata refers to the global variable ... and (if set) that variable is used to specify the title used for the subpage (if the title were "Module:Example", the subpage would be "Module:Example/i18n"). However, ... is always nil in a module (I think) so the test is redundant. If running Lua on some other system (not a Scribunto module), the global variable ... would be nil or a table of command-line arguments passed to the Lua script. If someone wants that for an off-wiki test system, better methods are available. Second, I'm pretty sure the code would not work because it is in a separate module (Module:I18n) and its attempts to set the i18n table would not affect Module:Wikidata which would continue using the English values. Does anyone know of a place where the system has been tested? Johnuniq (talk) 03:27, 20 October 2017 (UTC)
I had a look and it was this recent edit by Ans that put i18n in another module. Prior to that (using the code by RexxS), it would have worked. Using global variables is very rarely desirable, and in this case quite unnecessary, even if it worked. I should clean it up but maybe I'll leave it for the recent editors because I'm resting after doing a bunch of module work at Commons. Johnuniq (talk) 06:30, 20 October 2017 (UTC)
Bug or incompatibility between the Monobook skin and the Infobox template
I believe that there is a bug or incompatibility between the Monobook skin and the Infobox template. When I use Monobook, it messes up Template:Infobox. When I switch to another skin, the issue disappears.
Would it be possible to add support for {{url}} to those infoboxes that don't yet have it? I came across {{Infobox stage production}}, which doesn't support it, and couldn't find any way to make it display without the initial "http" – which as I understand it should not appear in the website field of an infobox. It's kind of confusing to do stuff that works in many situations, and then find that it doesn't work in other, similar, cases. Consistency, anyone? Justlettersandnumbers (talk) 21:38, 9 January 2018 (UTC)
Sesame Street Live produces a total mess. Although removing {{Official site}} from the value in the article shows that a simple www.sesamestreetlive.com works perfectly well.
Urggh! Thanks, RexxS, for looking at this. I really don't care about this one infobox, what I was sort of hoping for was a global change so that all infoboxes would support the standard url template. I can't do template syntax, but is there any way of doing an either/or switch, such that the old syntax will still work, but {{url}} will be respected if it is present? The url for Quidam should display as cirquedusoleil.com/quidam (we drop the www bit unless the site won't work without it, right?). Anyway, if there are only 100 pages I can deal with them – that's an awful lot less than the thousands or tens (hundreds?) of thousands that have been broken by the recent changes to {{lang}}. Is there some way of easily identifying which infoboxes don't support the url template? I think that'll be a lot more than 100. Justlettersandnumbers (talk) 22:31, 9 January 2018 (UTC)
@Justlettersandnumbers: It depends on what you mean by "support". The problem is not that infoboxes don't support {{url}}, it's that {{url}} doesn't support every possible value that editors have already put into the website field. Any infobox could have {{url}} embedded in it, so that having |website=www.example.com would give consistent results. {{Url}} even copes with |website=https://www.example.com, but any such implementation would currently barf at |website={{official site|www.example.com}}. The Module:Urlcould be modified to look for a url anywhere inside whatever is used as the value for |website=, but I think it better to require at least a minimum standard of discipline from editors in how they supply values to infoboxes in articles.
As for dropping the www bit unless the site won't work without it, the only way to do that is to test it manually each time; there's no reliable programmatic way of doing it automatically that I'm aware of. --RexxS (talk) 23:09, 9 January 2018 (UTC)
Subbox classes
I have removed the infobox class when |subbox=yes to help with the rendering on mobile. as far as I can tell, the class isn't needed when the box is a subbox since the class is set by the outer box. but, please let me know if this causes a problem. Frietjes (talk) 22:41, 24 January 2018 (UTC)
Could someone code something (I would, but don't know the first thing about LUA) that would make infoboxes automatically populate Category:Infobox templates?
I suppose that's true. Seems a bit inelegant though and very enwiki specific, but I guess that could be done while someone who knows LUA develop a proper module update.
AFAIC, there's no issue with that. {{str left|{{#titleparts:Template:Ibox ₤|1}}|16}} returns Template:Ibox ₤T, which would 'fail' the test, as expected. Headbomb {t · c · p · b}23:41, 10 February 2018 (UTC)
{{#ifeq:{{#invoke:String|sub|s={{#titleparts:{{NAMESPACE}}:{{SUBPAGENAME}}|1}}|i=1|j=16<!-- the two error settings go here -->}}|Template:Infobox|[[Category:Infobox templates|{{remove first word|{{SUBPAGENAME}}}}]]}}
(error handling |ignore_errors=1 |no_category=1 to be added, for now this does test = shjo0w workings).
I've edited Template:Infobox element to make use of the /sandbox, and it works flawlessly. See Category:Infobox templates. And as a bonus, things sort nicely, and we get rid of the lot of the /sandbox /doc crap that clutters the category. Many hard-coded instances could be removed from the documentation pages. Headbomb {t · c · p · b}14:05, 10 February 2018 (UTC)
I'm confused here. We're still on the building ideas/testing phase. No one's raised any objections yet, so I'm not sure where you claim there's "no consensus". As for {{template other}}, that would not filter out /doc and /sandbox subpages. I'm also not sure what you mean by "Diffusion in the category is broken." AFAICT with my limited testing, it works exactly as intended. The infobox gets categorized, nothing else does. Lastly, PETSCAN would be useless, as the vast majority of infoboxes aren't categorized. Headbomb {t · c · p · b}18:21, 10 February 2018 (UTC)
I admit: I misunderstood your I've edited [[Template:Infobox element]] note above (looked like going all live to me - sad face here). I'm sorry.
After this, this technical topic: templates (esp. infoboxes) are supposed to go: 1-source -> 10k, 100k, 1M articles. So if one wants to check "Template:...", better check ns first (=the outside if-check), and only then check for pagename.
Using {{template other}} would either decrease the efficiency of the code, or do nothing different, since after checking for, you'd still have to check for the {{SUBPAGE}} anyway. The above code does it in one step, so is likely more efficient. I'm also unsure of what exactly would be the point of doing 'PETSCANs'/'WLH'/'Bots'/'Monthly reports'. PETSCANS of what? For what purpose? Bots of what? For what purpose? Monthly reports of what? For what purpose? Etc... Headbomb {t · c · p · b}23:22, 10 February 2018 (UTC)
what I meant to say: 1 ibox template is to be used in 100,000 articles. So if we do a cheap ns check first, those 100k article pages do not have to do any 2nd subpage name check at all. Wikiwide: more efficient. -DePiep (talk) 23:30, 10 February 2018 (UTC)
Ah I see. Still, there's no major increase in cost between 1 {{NAMESPACE}} check, and 1 {{NAMESPACE}} + 1 {{SUPPAGE}} checks. KISS might be better here. Headbomb {t · c · p · b}23:37, 10 February 2018 (UTC)
There might be advantages to doing a namespace check before doing a string check however. That would cut down on the 'costly' checks quite a bit. Headbomb {t · c · p · b}23:39, 10 February 2018 (UTC)
In general: whatever the OP wants to achieve ("list of infobox templates" we assume), this is not a smart way (nor by server/enwikiwide efficiency, nor by programming efficiency, nor by category result). As I tried to describe.
If you do not get the point of better using, for example, WP:PETSCAN for such an aim, I am not here to argue. For sure, I disadvise making some change this way anyway anyhow. - DePiep (talk) 23:52, 10 February 2018 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Given the lack of any solid reason against this, I say it's time to deploy. The edit protected request is simply to copy the sandbox version into the live version. The changes have been tested, and work.
Possible improvements to efficiency may possibly be done through LUA, but this is not something that would noticeably slow down pages as is. Headbomb {t · c · p · b}21:18, 13 February 2018 (UTC)
I object to deploying this. In the section #above, I have started thinking along but ended up finding serious objections. I'll relist them here. - DePiep (talk) 10:21, 14 February 2018 (UTC)
re Template-technically, the sandbox has these flaws: 1. The test is run for each and every transclusion (3M). That is, an infobox having 1k or 10k transclusions: all of these are evaluated to reach that one hit. That is very inefficient. 2. At least, the first (outer) test should be for namespace only. Only when this test fires (i.e., template source page), any pagename processing should be & could be done, to improve efficiency over all those transclusions. 3. It occurs to me that parsed templates could be replaced by module calling (Lua). 4. It has no override option. Best thing that can be said its that "it is working something".
re Design: Still unclear why this functionality should be added this way. Sure it would be convenient to have an all-infoboxes list. However, 1. filling Category:Infobox templates indiscriminately misses out on its --already existing-- category diffusion (even erroneously doubling templates already in there). 2. Also unclear is why this should be done through live categorisation (categorise live template source pages). 3. This is what the {{Documentation}} subpage exists for. That subpage can do all Wikipedia administration categorisation (i.e. all support & maintenance categories), including handling diffusion and incidental stand-alone subtemplates. 4. And, apart from categorising, it is possible to list all templates that are not categorised in Category:Infobox templates. That is: list the missing templates (what this edit tries to solve), then edit these templates. Likely a WP:BOTREQUEST can list these, or WP:PETSCAN. As a maintenance task, there is no problem doing this back-office style.
1a/2a) The 'test' is nested, and checks for namespace first ('cheap') before performing the str manipulation ('costly'), so I'm not sure what your objection is there. WP:PERF applies.
3a) Yes this could be done with LUA. Feel free to implement via LUA, but the code works as is.
4a) No override is needed. There is no template located at Template:Infobox Foobar that should not be in Category:Infobox templates.
1b) The purpose of the category changes to be an all-included category, rather than "diffused" one. Sub-categorization can still be done to facilitate browsing by topics, but there will now be a category containing all of them [or rather most of them, some manual categorization will still be needed, but that's fine]. Having both a master category and subcategories aren't at odds with each other, both have different purposes. The WP:DIFFUSE scheme fails when it comes to infoboxes, because most of them are not categorized, and it would take a ridiculous amount of effort to subcategorize each of them correctly.
2b) Because this is the most efficient way of getting the most infoboxes categorized with the least amount of effort. It will miss some (see 4b below), but it will catch the vast majority of them.
3b) {{documentation}} isn't used on all infoboxes, so will miss those without documentations. In particular, Special:RecentChangesLinked/Category:Infobox templates would not pick newly created infoboxes missing documentation. The further away you put the code from the live template, the more you miss. The WP:PERF tradeoff isn't worth it.
4b) "Missing templates" list are effectively useless and can't be used for WP:AALERTS and Special:RecentChanges, and need to be regularly maintained. The point is to have an existing templates category that gets updated automatically. The only point behind a 'missing templates' list would be to find corner cases where you have an infobox located at a different title than Template:Infobox Foobar, that is not picked up by automatic categorization, so it can be manually categorized. And for the 3rd or 4th time now, WP:PETSCAN is completely useless because it depends on infoboxes being categorised, which they aren't at the moment. This is what we're trying to fix. WP:PETSCAN would become useful after infoboxes are categorized.
1a/b: I replied to your earlier objections, apparenmtly you did edit. OK. The efficiency is in the number of negatives.
3a.
4a. "no override is needed" - Does not sound like an analysed check. And above, you require a rename for exceptions known.
1b: the way you describe the new "DIFFUSE" is not correct DIFFUSE, nor is it conforming parent/sub categorisation (only once ever). Altogether you are puttign aside diffused categories without long term plan (remove or complete?).
2b:
3b: "{{Documentation}} missing" -- then add it.
4b: First of all, no need to talk down on me, whether you miss my point or not (in this case you do). Your statement re PETSCAN is wrong.
Yes those "corner cases" should be added as you say. How do you provide to do that? As I suggested, PETSCAN or a bot can do that (don't forget to tell the bot: non-Lua infoboxes that do have class=infobox qualify too).
"This is what we're trying to fix" -- in a crude, incomplete way and overcomplete (redundant) way. What is missing is an overthinking of the OP request. Would help preventing the categorisation mess that is coming, for starters.
This is the missing gap: analysis of which templates to include/exclude; already jumped into some how to do it & then put exceptions out of sight. -DePiep (talk) 14:17, 14 February 2018 (UTC)
4a) I don't care how it "sounds", this remains a fact. As for renames, that's one option. The other is to add the category manually. 3b) How do you know you need to add it when you don't even know it's missing? And don't say PETSCAN because, again, PETSCAN relies on categories. Here's an easy way to put this matter to rest. Give us an example of where an override would be needed, and give us a PETSCAN listing all infoboxes. Headbomb {t · c · p · b}17:50, 14 February 2018 (UTC)
"Does not sound like" - your off the cuff remark shows that this part has not been thought through. It's just a reply you made yuo after I pointed to the issue. You have not resoned why there should be no exception. - DePiep (talk) 20:24, 14 February 2018 (UTC)
Because the code works, and there are no scenario in which exceptions would occur. You may not have thought things through, but it doesn't mean things haven't been thought through. Headbomb {t · c · p · b}20:27, 14 February 2018 (UTC)
SupportHeadbomb's reasoning and WP:DWAP (doesn't mean we can be careless, but that isn't the case here). Given the large transclusion size, though, I'd be interested to know if Lua is cheaper and by how much. Unless it's significant, just go with the working, tested sandbox. ~Tom.Reding (talk ⋅dgaf)13:01, 14 February 2018 (UTC)
LUA would be cheaper, but we're talking a few milliseconds difference at best. Wikipedia:Lua speed say #ifeq runs at 1250 calls/seconds (so most pages, we're talking about a ~0.8 ms difference), and if the second test is invokes, we add a second ifeq call of 0.8 ms + a str manipulation template at ~625/2 seconds = 3.2 ms, for a total of ~4.8 ms. Headbomb {t · c · p · b}18:05, 14 February 2018 (UTC)
Tom.Reding could you reflect on the design issues? Coming from the OP, the sandbox talkes a lot of design 'choices' (better: effects), that are not well derived from that OP. As Bombshell already described here, the category structure must change (not noted before; is a signal. Good I asked), while still breaking WP:DIFFUSE. - DePiep (talk) 13:47, 14 February 2018 (UTC)
I'm not really sure I see why there's a need for a separate category here. Why is the existing one problematic? Headbomb {t · c · p · b}18:18, 14 February 2018 (UTC)
@Tom.Reding: The hard-coded category (Category:Infobox templates) would be removed from templates following {{Infobox Foobar}} naming convention, and instead be added dynamically by the {{Infobox}}. Right now all {{Infobox element}} call {{Infobox/sandbox}}, which makes the categorization cascade down to all element infoboxes [you can tell because they are sorted correctly].
Deploying the code would let this cascade to all infoboxes that follow the {{Infobox Foobar}} naming convention. Hard-coding the category on individual templates will only be necessary for those that don't follow that naming convention (e.g. {{Obama cabinet infobox}}, although that could also be handled by moving the infobox to the standard location ({{Infobox Obama cabinet}}).
"instead" is not exactly right: it will be done anyway & independently of hardcoded category being present or not.
There are more situations where hardcoding the category is required.
This abandoning of subcategories is not part of the proposal, not even implicit. And clearly the point "drop diffused categories" is not discussed. Also, at the moment the category is a topic category, so those topical templates listed should find a new house.
Requiring infobox renamings to make this function has no consensus or any other base. BTW, as things stand this is a manual job (you'd need a list...). - DePiep (talk) 20:36, 14 February 2018 (UTC)
If you are confused about what the proposal is, you should reread what the proposal is, because you don't seem to understand anything about it. All your objections have either been addressed, or are either invalid or unsubstantiated. Headbomb {t · c · p · b}20:48, 14 February 2018 (UTC)
I believe DePiep is concerned about the fact that Category:Infobox templates will (may) simultaneously be both a diffusing category (anyone can, and should, continue to sort infoboxes into those subcats, and do so manually) and a non-diffusing category (i.e. pages should only be placed directly into the cat by the as-yet-undeployed template code). I'm fine with either scheme, as long as it's clear in the description. However, finding the appropriate templates to put at the top of the cat will be hard since they'll contradict each other, and it will be non-intuitive for many people since I don't think such an example exists at such a prominent level (not that I've noticed anyway). Making a separate non-diffusing cat resolves that. Making a new header template resolves that too. So, as long as one of those 2 things happen, I don't see a further problem. ~Tom.Reding (talk ⋅dgaf)21:09, 14 February 2018 (UTC)
Ah, great! Learn something new every day. I wrote this both for my and DePiep's benefit. It definitely helps to devil's-advocate solve the problem than to knee-jerk object. ~Tom.Reding (talk ⋅dgaf)21:53, 14 February 2018 (UTC)
Does not solve the other flaws. This is just uttering ideas while the original question has not been analysed, let alone implemented. Already I've mentioned half a dozen exceptions on the fly that are not correctly covered, and still no break mode is entered. You really think the development can continue while the format request is still open? Also, I myself am not going into someone's development track (edting a sandbox) without clear understanding of what is aimed. You seriously want to have edits going on (edit warring it could be), while any editor can come by and push an unstabilised version live in 3M pages? I'd expect some more serious template development.
Once again, please cut down on your arrogance. And once again, you are wrong in your unhelpful statement, interestingly also contradicting your own /sandbox proposal functioning. DePiep - 20:18, 14 February 2018 (UTC)
And once again you are welcomed to offer an example of an infobox template named Infobox Foobar that isn't an infobox template that should be categorized in the category for infobox templates. So again, do you have such an example? I would wager not, because no such infobox exists.Headbomb {t · c · p · b}20:30, 14 February 2018 (UTC)
That would no help you out. You are dismissing, arrogantly, each and every serious contribution. My point is, that you are strongly invited to think of tyhose examples yourself. (Enough hints already presents btw). -DePiep (talk) 20:48, 14 February 2018 (UTC)
Note to editor who considers making this edit: per WP:EDITREQ I note that this proposal now is Controversial (and possibly failing on other points too), so should not be performed. - DePiep (talk) 20:46, 14 February 2018 (UTC)
This is not controversial, only you object, for reasons that don't check out. The code works, has been tested, and you can't / straight up refused to come up with any examples of where the code doesn't work. Headbomb {t · c · p · b}20:49, 14 February 2018 (UTC)
In a quick look at this discussion, I don't see an explanation of how auto-categorization would be used. I see something about "missing templates"—what is that about? There are over 2560 templates which directly call {{infobox}}. Is the idea to have them all listed in Category:Infobox templates with a sort key based on the template's name? Am I correct in thinking the proposal would auto-categorize Template:Infobox open cluster but would ignore Template:Punctuation marks despite the latter using {{infobox}}? Johnuniq (talk) 01:05, 15 February 2018 (UTC)
@Johnuniq: You're pretty much correct. There's no real way of detecting a 'direct use' of {{Infobox}}, but this would cover the vast majority of cases. This would populate Category:Infobox templates, which could then by used by WP:AALERTS and Special:RecentChangesLinked to monitor for discussions / vandalism / recent changes, amongst other things, on top of having a category containing all infoboxes, making it easy to find something. Infobox like {{Punctuation marks}} would be ignored by the automatic categorization, but could be categorized manually if desired. However, in this case, I'd argue that {{Punctuation marks}} is functionally a navbox, rather than an infobox, and should probably be updated to reflect that. Headbomb {t · c · p · b}03:09, 15 February 2018 (UTC)
Let's define and create a new category
Please allow me to make a restart to make this fly. The two threads above introduce multiple issues and principles the earlier proposed sandbox change, possibly blocking an improvement unneccicarily. Therefor I take this approach: Let us first describe the intended Category. IMO once we have consensus on this, the "how-to" (populate the category) can be solved more gently.
The request
Headbomb proposed automated population of Category:Infobox templates[1]. However, it appears that "automated" can not be achieved without causing issues. I understand the request to be along this line: "Make the category complete, and do automatically so".
IN-1: The Category lists all templates that have class=infobox
IN-2: Only templates that appear in mainspace are listed
IN-3: The category aims to be complete
About the existing category
Current Category:Infobox templates has 15 (1-deep) subcategories, intended for WP:DIFFUSE ("Put a template in the most detailed subcategory/ies"). Would we add all infobox templates to the top category, the principle of diffusion would be broken. It would be a two-principled setup, wrong because of conflicting definitions. OTOH, simply re-defining the existing category, and removing all subcategories, would be breaking current usage and expectancies. Maybe a even a full WP:CfD would be required.
Also, the new requirement of completeness is hard to achieve when its original approach is still in place. What we need is a setup that guarantees that the category has all, and nothing more.
So I strongly propose to leave current category as it is, and create this new category.
"Category:Wikipedia infobox templates" is the working title. If follows naming convention per WP:PROJCATS (a.k.a. administrative category): everything that is not content. "content" may differ from "mainspace" though.
2. Populations rules are:
IN-1: The Category lists all templates that have class=infobox
This is the most stable and useful categorisation rule for infoboxes. The class name governs its semantics and from there the meaning & presentation of its content (information). See also WP:INFOBOX.
It would include non-{{Infobox}} infoboxes (Example: {{Chembox}}: today still a wikitable).
To keep in mind: subpages that can be used stand-alone.
IN-2: Only templates that appear in mainspace are listed
Sure, we do not want to list /sandboxes, /doc, /testcases.
Disputable, but IMO we should not list unused or non-content infoboxes. In the end, these are un-checked, un-maintained, and even could apply a different "infobox" meaning. (Example: ).
IN-3: The category aims to be complete
This is most important for the intention of automated use: single place to go for bots etc. Attention for latency (some time delay wrt new pages should be acceptable).
There's no Infobox templates are not Wikipedia infobox templates. No other kind of infobox templates exist. Additionally, keeping the current structure as is for sake of tradition should hold no weight here. There's a better more useful way to categorize things, so lets do that. You also write However, it appears that "automated" can not be achieved without causing issues.. This is simply wrong. This causes no issue, and no one is proposing to remove any subcategories from anything. However, there are many issues with your proposal, mainly that no everything that has the infobox class is an infobox, and there is no reason to exclude non-mainspace infoboxes from this categorization scheme. Headbomb {t · c · p · b}22:37, 15 February 2018 (UTC)
re There's no Infobox templates ...: Misunderstanding. The prefix "Wikipedia" does not specify the templates, as you seem to read it. It is a prefix that distinguishes administrative pages from content pages.
re for sake of tradition: no, extreme interpretation you are making here. Current structure is well established, contains extra information, and numerous (unknown) users & approaches can rely on it.
re so lets do that - Again, let's do what? This is skipping over my main point: the category has not been redefined, so filling it with "that" is working backwards.
re no issues - Yes there are, and I have pointed them out. These also include inconsistencies wrt conflating category definitions. (by claiming that no one is proposing to remove any subcategories, you show that you did miss these contradictions, up to the point of even maintaining them in the future).
re no reason to exclude - well, I did describe a reason (you did not care to refer to), and also I note that I exactly raised it as a question for consideration. Another example of blaming me for your bad reading?
1) Then I look forward to you sending Category:Infobox templates to WP:CFD, as well as each of its subcategories, given none of them start with Wikipedia. 2) Yes, and none of those uses are hampered by deploying the sandbox as it currently stands. 3) Let's deploy the code in the sandbox. 4) No there are none. You haven't pointed one single example of an infobox template that would be categorized in Category:Infobox templates by the proposed code that shouldn't be categorized in Category:Infobox templates. 5) Same as 4. Headbomb {t · c · p · b}01:21, 16 February 2018 (UTC)
UnnecessaryDePiep, please read {{All included}}. Everything else you mentioned needs to be done manually anyway, can be done right now without the need for a "proposal", and can be done using the existing category. ~Tom.Reding (talk ⋅dgaf)23:07, 15 February 2018 (UTC)
I did read {{All included}}. Its opening line is: "This template is meant to be used for content category pages." And, as I already pointed to, in administration (aka WIkipedia) categories, such disorganised approach will cause chaos (conflicting definitions for starters).
Then we can modify the wording, or make a separate template just for admin cats if one doesn't already exist, etc. The point is, this category structure already exists, is acceptable, and the reasons you think this proposal is a bad idea are unfounded. ~Tom.Reding (talk ⋅dgaf)00:55, 16 February 2018 (UTC)
Anyway, Tom.Reding, would you care to reply to the core point: First define the category (for example, as I did here), then look at how to technically fill it? Thank you. -DePiep (talk) 00:30, 16 February 2018 (UTC)
Yes, because we all know updating a documentation page and a category description after a template is updated is the most impossible thing in the world. Headbomb {t · c · p · b}14:03, 22 February 2018 (UTC)
You both @Bombhead and Tom.Reding: still not did reply to this MAIN point: what pages should be INCLUDED/EXCLUDED from the category. Not. -DePiep (talk)
Hi Headbomb. The point, you still did not reply to, is: "what is an infobox?". I maintain: the definition is not: a template that starts with "Infobox". - DePiep (talk) 23:39, 16 February 2018 (UTC)
I did not, and AGAIN stop it with your personal attacks. The code automatically categorize infoboxes named {{Infobox Foobar}} yes. But that does not mean those are the only infoboxes that exist, nor the only infoboxes that would end up in the category. So YOU stop lying. Headbomb {t · c · p · b}23:55, 16 February 2018 (UTC)
The original proposal also categorizes all infoboxes. That you refuse to understand this is beyond me. The only difference is that the majority of those cases are handled automatically. Headbomb {t · c · p · b}12:48, 21 February 2018 (UTC)
True infobox can be in a section?
Today, the 120 chemical element articles have a fine infobox that includes an "isotopes" table (e.g. uranium). Over at WikiProject talk:Elements I propose to break that table out into a new, separate infobox. That new infobox will be added into a section of the article. And also: the new infobox will be freshly added to the article isotopes of uranium.
Main question: Is it OK to use a straight infobox in an article section? What information, semantics, MOS, guidelines to keep in mind? (note: ideas are welcome, consensus forum is WT:ELEM). -DePiep (talk) 18:56, 7 January 2017 (UTC)
template help
Hello, Iam new and working on Wp/sat(incubator). I have read the template tutorials from wikipedia but when am using that template code, it doesn't shows like template. It displaying only the template title (e.g. Template:xxxx). So please help me how make infobox template like others page.
@Headbomb: This template, {{Infobox}}, as of about three weeks ago only requires template-editor rights to edit, so, since you're a Template editor, you already have the rights to deploy the version in the sandbox. —RP88(talk)02:44, 12 March 2018 (UTC)
@RP88: right you are. I don't really agree with the de-escalation of the template protection, but I'll make the changes. Headbomb {t · c · p · b}12:24, 12 March 2018 (UTC)
When I try to test the settlement infobox sandbox in my own user sandbox, I get "Lua error in Module:Infobox/sandbox at line 206: attempt to index global 'dataCell' (a nil value)." I'ld rather not try and fix this myself, so perhaps someone with more lua knowledge can take a look? Fram (talk) 11:33, 13 April 2018 (UTC)
