Template talk:Infobox/Archive 14

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10 ← Archive 12 Archive 13 Archive 14 Archive 15 Archive 16 → Archive 19

Standardising map parameters in infoboxes

I'm proposing to standardise the map parameter names in infoboxes; please see, and comment at, Wikipedia:Village pump (technical)#Standardising map parameters in infoboxes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:09, 28 August 2017 (UTC)

Create label semantically

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

Issue at hand: see {{Infobox hydrogen}}, ~halfway there is Spectral lines + an image (through this subtemplate). I want the label "Spectral lines" to appear as a caption. Suggestions? (Creating an extra row with idle |data10=  is not ideal). -DePiep (talk) 11:25, 28 September 2017 (UTC)

Redlinked 'Module:Infobox/i18n'

I see redlinked Module:Infobox/i18n pop up in articles (42.000 transclusions). Is this by design (future deployment)? Anything I could learn? Of course, "i18n" stands for internationalisation. -DePiep (talk) 20:50, 19 October 2017 (UTC)

for Module:Wikidata they created Module:Wikidata/i18n to make the redlinks turn blue. figuring out where it comes from for Module:Infobox is beyond my pay grade (possibly related to the infobox using Module:Wikidata). Frietjes (talk) 21:36, 19 October 2017 (UTC)
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)
My guess based on looking at recent changes to Module:Wikidata is that modules that require Module:Wikidata have begun to call Module:XXX/i18n, even when that module does not exist. Template:Wikidata redirect, for example, calls Module:Message box/i18n, which does not exist. Perhaps the people working on it will have more insight. I will put a note on the Module:Wikidata talk page. – Jonesey95 (talk) 22:26, 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.

— goethean 19:58, 22 November 2017 (UTC)

goethean, (1) the images that you are showing are of Template:Navbox not infobox and (2) I am unable to reproduce what you are seeing, but it looks like you aren't loading MediaWiki:Common.css or MediaWiki:Common.js for some reason (e.g., the hlist and navbox class definitions). I would suggest posting your query at WP:VPT if the problem persists. Frietjes (talk) 20:10, 22 November 2017 (UTC)
goethean, another thing to try is temporarily disabling your User:Goethean/monobook.js, or any other monobook-specific stuff that you have enabled. Frietjes (talk) 20:12, 22 November 2017 (UTC)
Removing my custom monobook.js and then bypassing the cache seems to have fixed the issue. — goethean 21:42, 22 November 2017 (UTC)

Support for {{url}}

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)

@Justlettersandnumbers: I've created Template:Infobox stage production/sandbox and changed it to include {{url}}. Testing it in a few articles shows it won't be a simple change because of the vastly different values already in use in different articles:
This template is in use on 100 pages:
So there would be a fair bit of work sorting out the incompatible values in use. --RexxS (talk) 22:16, 9 January 2018 (UTC)
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:Url could 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)

Automatically populate Category:Infobox templates

Could someone code something (I would, but don't know the first thing about LUA) that would make infoboxes automatically populate Category:Infobox templates?

In wikicode, that would be something like 

{{#ifeq:{{str left|{{#titleparts:{{NAMESPACE}}:{{SUBPAGENAME}}|1}}|16}}|Template:Infobox|[[Category:Infobox templates]]}}

{{NAMESPACE}} would guarantee we're in the correct namespace, while {{SUBPAGENAME}} would guarantee we're not on a sandbox/doc page.

Headbomb {t · c · p · b} 01:54, 10 February 2018 (UTC)

No need to do in lua, could just be added after the {{#invoke}}. -- WOSlinker (talk) 09:50, 10 February 2018 (UTC)
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.
I'll sandbox things to set up an edit protect request. Headbomb {t · c · p · b} 11:34, 10 February 2018 (UTC)
Todo: check when pagename is very short, like Template:ibox ₤. -DePiep (talk) 13:34, 10 February 2018 (UTC)
The solution would likely be to move the infobox to Template:Infobox ₤ and so it categorized correctly. But if the non-standard name was preferred, manual categorization could always be done (e.g. Template:Music of sidebar and sub-templates). Headbomb {t · c · p · b} 13:39, 10 February 2018 (UTC)
??? the error would be caused by the change, so must be solved by the change. - DePiep (talk) 15:30, 10 February 2018 (UTC)
What error? Headbomb {t · c · p · b} 18:23, 10 February 2018 (UTC)
The error situation is: the way {{str left}} handles too-short strings. - DePiep (talk) 21:11, 10 February 2018 (UTC)
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)
{{#invoke:String|sub|s= target_string |i= start_index |j= end_index |ignore_errors=1 |no_category=1}}
{{#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).
For category sorting, see source code for {{Remove first word}}:
[[Category:Infobox templates|{{{{#invoke:String|replace|source={{SUBPAGENAME}}|pattern=^[^%s]*|replace=|plain=false}}|{{SUBPAGENAME}}}}]]

-DePiep (talk) 13:56, 10 February 2018 (UTC)

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)

Does not read like consensus here. - DePiep (talk) 15:30, 10 February 2018 (UTC)
  • Better use {{template other}}} first (outer) for efficiency. - DePiep (talk) 15:30, 10 February 2018 (UTC)
  • Could not a smart WP:PETSCAN be OK? (And cross-check with the category to look for uncategorised infoboxes?). -DePiep (talk) 15:38, 10 February 2018 (UTC)
  • Diffusion in the category is broken. Add option "nocat"? -DePiep (talk) 15:33, 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.
More generally, I'd say to @WOSlinker and Headbomb: when the target is getting Category:Infobox templates complete --good--, go WP:PETSCAN or WLH or bots or monthly reports. - DePiep (talk) 21:28, 10 February 2018 (UTC)
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)
The point is to have a category containing all infoboxes. WP:PETSCAN cannot achieve that. Headbomb {t · c · p · b} 23:53, 10 February 2018 (UTC)
Why does it Have to be a Live category? What is wrong with making a missing-list? -DePiep (talk) 00:37, 11 February 2018 (UTC)
Because lots of things require live categories? Special:RecentChanges, WP:AALERTS, etc... Headbomb {t · c · p · b} 01:07, 11 February 2018 (UTC)

RFC on categorization

See Wikipedia:Village pump (proposals)#RFC: Autopopulate Category:Infobox templates when we can. Headbomb {t · c · p · b} 12:45, 21 February 2018 (UTC)

Deploy auto-categorization

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.
- DePiep (talk) 10:48, 14 February 2018 (UTC)
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.
Headbomb {t · c · p · b} 12:31, 14 February 2018 (UTC)
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)
  • Support Headbomb'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)
My only suggestion would be for this to populate a different category, say Category:All infobox templates?, with {{Non-diffusing subcategory}} at the top, pointing to Category:Infobox templates as the parent diffusing cat.   ~ Tom.Reding (talk ⋅dgaf)  14: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)
I suppose that if Category:Infobox templates was ideally diffused then it wouldn't matter, yeah. Is the cat going to be removed from all the ~156 templates it's currently on (and replaced with its proper subcat, ideally)?   ~ Tom.Reding (talk ⋅dgaf)  19:04, 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)
How subcategories are handled doesn't change, since that can't be automated. Headbomb {t · c · p · b} 20:13, 14 February 2018 (UTC)
Yes, that is what I want to point to. You are mixing up two category setups that do not go together (per WP:CAT).
WP:CAT says nothing about this whatsoever. See WP:DUPCAT in particular. Headbomb {t · c · p · b} 20:43, 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)
@Tom.Reding: It's not hard at all. Put {{All included}} on Category:Infobox templates and that's pretty much all you need to do. Headbomb {t · c · p · b} 21:24, 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.
The first question is: which templates should be listed? - DePiep (talk) 17:18, 14 February 2018 (UTC)
"which templates should be listed?" All infoboxes. Next question? Headbomb {t · c · p · b} 17:45, 14 February 2018 (UTC)
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)
Exactly, you offer no example of where any of this fails. So stop holding things up for no reason. Headbomb {t · c · p · b} 20:51, 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".

I propose

1. Create new Category:Wikipedia infobox templates. It contains all infobox templates that appear in mainspace in its top level.

2. Populations rules are:

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.


Once again my proposal, now commented

1. Create new Category:Wikipedia infobox templates. It contains all infobox templates that appear in mainspace in its top level.

"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).
Numbers

Indications:

Number of infoboxes transclused on enwiki: 3M.

Number of templates that invoke Module:Infobox: 2560 (per Johnuniq).

Number of templates that invoke Module:Infobox: 1208 (per this PETSCAN).

Number of templates in Category:Infobox templates (3-deep): 13640 PETSCAN (slow). This is huge also because of category tree effects (Example: Template:PBB/2239).

How to do it

Once we agree on what to include and why, the how can follow.

Comments?

Also, proposal improvements appreciated. - DePiep (talk) 21:09, 15 February 2018 (UTC)

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?
In general, Headbomb, you have missed my main point completely: the definition of the category to be used. - DePiep (talk) 00:23, 16 February 2018 (UTC)
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)
re Headbomb Again: you did not reply to my may point. - DePiep (talk) 23:06, 16 February 2018 (UTC)
Unnecessary DePiep, 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)
Or use {{Tracking category}}, which is pretty much the same thing but for non-articles. Headbomb {t · c · p · b} 23:29, 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)
The category has already been defined above, and this edit request will facilitate its population. You're welcome.   ~ Tom.Reding (talk ⋅dgaf)  00:55, 16 February 2018 (UTC)
Tom.Reding What "above" you are talking about? -DePiep (talk) 23:08, 16 February 2018 (UTC)
Headbomb, if no other objections within, say, a week(?), I say go for it.   ~ Tom.Reding (talk ⋅dgaf)  00:55, 16 February 2018 (UTC)
It's been a week already. I don't see any reason to delay. Headbomb {t · c · p · b} 01:16, 16 February 2018 (UTC)
... you being deaf. Did you learn 'talk' at twitter? - DePiep (talk) 22:24, 16 February 2018 (UTC)
I note that, even if you push this through, no Template:Infobox/doc nor Category:infobox templates content (description) has been considered -- let alone has consensus. So far, content of /doc etcetera will be: "All pages that start with "Template:Infobox". -DePiep (talk) 23:15, 20 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)
DePiep, I think you mean Headbomb. Also, please stop your personal attacks.   ~ Tom.Reding (talk ⋅dgaf)  23:18, 16 February 2018 (UTC)
All infoboxes, as has been explained several times in the past week. That you refuse to accept this as an answer is your problem, not ours. Also, my username is Headbomb, not Bombhead or Bombshell. Headbomb {t · c · p · b} 23:22, 16 February 2018 (UTC)
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)
See WP:INFOBOX. And no one has claimed infoboxes are defined by the name of the template.Headbomb {t · c · p · b} 23:41, 16 February 2018 (UTC)
Yes someone did: you did. See your sandbox proposal. By now, you are becoming a liar. - DePiep (talk) 23:52, 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)
(ec) re Tom.Reding Thanks!, you are right. By the way, since you seem to care about personal attacks: please tell Bombhead to stop. This is not twitter. - DePiep23:26, 16 February 2018 (UTC) -DePiep (talk) 23:34, 16 February 2018 (UTC)
  • notified VP-misc. -DePiep (talk) 23:47, 16 February 2018 (UTC)
  • Can somone point me to the rationale for this. "Given the lack of any solid reason against this" is not a reason, and I don’t see a pointer to one.--JohnBlackburnewordsdeeds 00:04, 17 February 2018 (UTC)
JohnBlackburne for what exactly? The original request, or DePiep's proposal above? For the original proposal, the main reason is that lots of things require live categories. For instance Special:RecentChangesLinked/Category:Infobox templates, and WP:AALERTS would both greatly benefits from this, allowing to quickly review recent changes to infoboxes, or monitor infobox-related AfDs and discussions. Headbomb {t · c · p · b} 00:17, 17 February 2018 (UTC)
Thanks, JohnBlackburne, for asking the right question. As it is, the proposal does:
"Categorise all pages that start with 'Template:Infobox'" Red XN (really, a prefix-test only)
My proposal is:
"Categorise all pages that are an infobox" Green tickY
I also note the arrogant non-communicative attitude I received. -DePiep (talk) 22:21, 20 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.

Example: uranium. Today: Uranium, {{Infobox uranium}}, Isotopes of uranium.
New: adding {{Infobox uranium isotopes}} to section Uranium#Isotopes and to 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.

Thanks, Ramjit User:Ramjit Tudu 14:46, 4 September 2017 (UTC)

Deploy auto-categorization, take 2

Per Wikipedia:Village pump (proposals)/Archive 145#!Vote (Infobox categorization), copy the sandbox version into the live version. The changes have been tested, and work. Headbomb {t · c · p · b} 00:58, 12 March 2018 (UTC)

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

Integration of Module:Unknown parameters

Hello, would it be possible to integrate Module:Check for unknown parameters to Module:Infobox itself. That would be great upgrade in my opinion. Capankajsmilyo (talk) 19:12, 11 April 2018 (UTC)

Error in sandbox?

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)

See Template:Infobox settlement/testcases, which has the same error. The problem is not restricted to (my) user space but is more general. Fram (talk) 11:41, 13 April 2018 (UTC)

Fram probably because Galobtter is experimenting with the sandbox code. if you don't want to use {{infobox/sandbox}} then change {{infobox/sandbox}} to {{infobox}}. Frietjes (talk) 13:29, 13 April 2018 (UTC)
Thanks. The same error appears elsewhere, including in Template:Infobox/sandbox, but for now I can test it with your solution! Fram (talk) 13:42, 13 April 2018 (UTC)
Yeah it is kind of in the middle of something, so the sandbox doesn't really work Galobtter (pingó mió) 14:04, 13 April 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox/Archive_14&oldid=1116032754"