Jump to content

Template talk:Infobox university

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Collision of Affliations and Sporting_Affiliations

[edit]

Right now, it appears that the doc for Infobox University allows for both of these, but having both causes both a note of the collision when previewing and adds to the category. There are about two dozen with the collision, Example is St. Mary's College of Maryland, contains both

I presume the athletics_affiliations is correct. What should be done with the affiliations, fix the doc, change the collision criteria, delete the field in the two dozen usages? (I'm not sure which archive discussed it).Naraht (talk) 19:30, 21 January 2026 (UTC)[reply]

Request: Parameter to change label for other_students

[edit]

Is it possible to add a parameter that allows us to customise the label for the other_students field? In New Zealand, students numbers are more commonly measured in EFTS rather than total enrolments, so it would be nice to have the option to use other_students as a way of adding EFTS to infoboxes for NZ institutions, and I'm sure there are other scenarios were a more specific label would be useful for other institutions too. Nil🥝 22:22, 25 February 2026 (UTC)[reply]

These labels are for types of students. You can specify EFTS in the value, e.g. undergrad = 10,000 EFTS. The field isn't limited to numeric values. Robminchin (talk) 04:24, 26 February 2026 (UTC)[reply]

Please remove the portion of the template code that causes affiliation and sporting_affiliation to be viewed as a conflict

[edit]

The template code marks affiliation and sporting_affiliation as a conflict but according to the doc, they should be OK if they are both in the parameters. Naraht (talk) 19:29, 30 May 2026 (UTC)[reply]

 Not done: it's not clear what changes you want made. Please detail the specific changes in a "change X to Y" format and provide a reliable source if appropriate. The parameters are, in fact, conflicting so not sure what change it is you want made. Zackmann (Talk to me/What I been doing) 22:20, 31 May 2026 (UTC)[reply]
I think the problem is that the parameters shouldn't be conflicting according to the docs, as 'affiliation' is described as "Organizations of which the institution is a member and provide essential definition of the institution's core mission and values. Academic and religious affiliations should be placed in those parameters." But if an editor follows this, they end up with the academic and religious affiliations in the affiliation field being displayed as sporting affiliations. Robminchin (talk) 01:10, 1 June 2026 (UTC)[reply]
@Naraht and Robminchin: Ah! Ok so I played around with this a bit... The issue seems to lie in the fact that there are so many different "affiliation" parameters. In the code we have:
| label50    = {{#if:{{{athletics_affiliations|}}}{{{sporting_affiliations|}}}|{{longitem|Sporting affiliations}}|Affiliations}}
| data50     = {{if empty|{{{athletics_affiliations|}}}|{{{sporting_affiliations|}}}|{{{affiliations|}}}}}
I think what we should do is separate this out so that they are 2 separate things...
| label50    = {{longitem|Sporting affiliations}}
| data50     = {{if empty|{{{athletics_affiliations|}}}|{{{sporting_affiliations|}}}}}
| label51    = {{longitem|Other affiliations}}
| data51     = {{{affiliations|}}}
Thoughts on this? --Zackmann (Talk to me/What I been doing) 03:35, 1 June 2026 (UTC)[reply]
If I'm reading this correctly, this breaks out 'affiliations' into its own 'Other affiliations' line in the infobox. That would work for me, but it would be good to get input from others who have been involved in earlier discussions. @ElKevbo:@Sdkb:@MB:@Bhockey10: I've pinged some users who were in discussions in the archives. Robminchin (talk) 18:01, 1 June 2026 (UTC)[reply]
That is correct. Will standby for other input for now. Zackmann (Talk to me/What I been doing) 18:04, 1 June 2026 (UTC)[reply]
It seems like the template should say "Other affiliations" only if there are also "Academic affiliations" or "Sports affiliations" being displayed otherwise it should render "Affiliations." But if that's not viable or others disagree then I'm okay either way. Thanks for asking! ElKevbo (talk) 21:42, 1 June 2026 (UTC)[reply]
@ElKevbo: that is totally reasonable and easy to do. Zackmann (Talk to me/What I been doing) 21:43, 1 June 2026 (UTC)[reply]
Facepalm Facepalm ok so it turns out that much further up the page there was a |affiliation= (singular) and that is where |affiliations= should have gone. This also reflects what is shown in the TemplateData and is the point that I think User:Naraht was first raising. Please see Special:Diff/1332868906/1357301695 for the fix which has been implemented. Zackmann (Talk to me/What I been doing) 21:54, 1 June 2026 (UTC)[reply]

Continued conflict

[edit]

See Category:Pages_using_infobox_university_with_conflicting_parameters. I'm gradually chipping away at the ones under L (which appear to all be using Location as well as one of State/Country etc.), but looking at those under A & S, they all appear to be some variety of issue with affiliations. Can someone please take a look to see whether these are valid, or if we need to tweek the code for conflicts among the affiliations (affiliation(s), religious_affiliation(s), sporting_affiliation(s)) Naraht (talk) 09:47, 2 June 2026 (UTC)[reply]

Deprecated parameter cleanup

[edit]

I am proposing a cleanup of the conflicting parameters of this Infobox and to ensure that all parameters conform to MOS:INFOBOXNAME. To be clear, this will not change the display on any transclusions. What I am suggesting is reducing technical debt and reducing errors caused by conflicting parameters. The replacements I plan to make are the following:

Deprecate/Remove Replace with
|image_name= |image=
|vice-president= |vice_president=
|other= |other_students=
|postalcode= |postal_code=
|postcode=
|zipcode=
|coor= |coordinates=
|campus_type= |campus=
|campus_size=
|athletics_nicknames= |sports_nicknames=
|nickname=
|athletics_nickname=
|sports_nickname=
|athletics_affiliations= |sporting_affiliations=
|mottoeng= |motto_eng=
|affiliation= |affiliations=
|other_name= |other_names=
|former_name= |former_names=
|founder= |founders=
|academic_affiliation= |academic_affiliations=
|mascot= |mascots=

Any questions or concerns about this clean up, please post below! Zackmann (Talk to me/What I been doing) 22:08, 1 June 2026 (UTC)[reply]

IIRC, nickname was deprecated in favour of the more specific alternatives due to widespread misunderstanding of the parameter. It might be best to keep these.
It looks from the docs as if zipcode and postcode both point to postalcode, so these should probably both be rolled into the generic postal_code rather than maintaining a separate alias for zip_code. Robminchin (talk) 00:07, 2 June 2026 (UTC)[reply]
@Robminchin: the reason for |nickname= is shown by the actual source code below:
| label49    = [[Athletic nickname|Nickname]]{{#if:{{{athletics_nicknames|}}}{{{sports_nicknames|}}}|s}}
| data49     = {{if empty|{{{athletics_nicknames|}}}|{{{sports_nicknames|}}}|{{{athletics_nickname|}}}|{{{sports_nickname|}}}|{{{nickname|}}}}}
The label that is actually displayed is Nickname therefore using nickname seems the most appropriate. I will also change it to use Template:Pluralize from text to make sure we get the "s" when appropriate.
As for |postal_code= vs |zip_code=, this comes down to WP:ENGVAR. I think there will be strong opposition to having US based articles using postal_code instead of zip_code...--Zackmann (Talk to me/What I been doing) 03:37, 2 June 2026 (UTC)[reply]
The discussion that led to nickname being deprecated in favour of the other parameters is at: Template talk:Infobox_university/Archive 14#Misuse of Nickname parameter. There was discussion about changing the display text at Template talk:Infobox university/Archive_22#Template-protected edit request on 19 May 2023, but this didn't go ahead because US English differs from the rest of the world. It might be better to revisit this and have the template display either 'Sports nickname(s)' or 'Athletics nickname(s)' depending on which parameter is filled in rather than revert to a situation that has caused problems in the past.
If we're having |zip_code= because of engvar, we should probably keep |postcode= for the same reason rather than privileging US English.
Engvar was, I believe, also the reason for having both |athletics_affiliations= and |sporting_affiliations=, as US English uses athletics where other forms of English use sports. Robminchin (talk) 15:06, 2 June 2026 (UTC)[reply]
@Robminchin:
  1. On the subject of zip vs post, just to be clear, I am NOT privileging US English. I am keeping both but just using the MOS:INFOBOXNAME version. So, if you consult the table above, |zipcode= will become |zip_code= while both |postcode= & |postalcode= will become |postal_code=. My understanding is that "Postal code" is the much more generic version of this term and I'm drawing from {{Infobox settlement}} (the most widely used Infobox on the wiki). I know only the US uses "Zip code" but both Post code (a redirect) & Postal code seem to me to be the same thing no?
  2. On the subject of Athletics vs Sports Nicknames this is not a topic I know enough about. My desire is to reduce the technical complexity. So from that standpoint...
    • If the value that is displayed on the Infobox is |label49=Nickname why over complicate the parameter with |athletics_nickname= OR |sports_nickname=?
    • Is there any other type of nickname that can be associated with a University? Genuine question here... By my understanding, for example, alums of UCLA call themselves Bruins whether they are talking about being a member/alum of the University OR of the sport/athletic team. So why the need to specify that this is the Sport/Athletic nickname as opposed to just the nickname?
  3. Finally on the subject of the sporting/athletic affiliations, my reasoning for deprecating |athletics_affiliations= is that even if it is used, the label that is displayed is still "Sporting affiliations". Now if you feel that is an important distinction that needs to be made, we can change the label, but that just seems an un-necessary level of specificity. To me Sporting affiliations and Athletic affiliations are the exact same thing. I don't really care which is displayed but I don't see a reason to have conflicting parameters to change the displayed label as if for some reason both parameters are used, we run into technical issues.
Let me know your thoughts! Zackmann (Talk to me/What I been doing) 23:24, 2 June 2026 (UTC)[reply]
1. Postcode (no space) is the term used in at least Australia, Britain and New Zealand – see Postcodes in Australia, Postcodes in the United Kingdom and Postcodes in New Zealand. I'm sure you don't intend to privilege US English, but if we deprecating British English, Australian English and New Zealand English while keeping American English then it's going to look like that's what is happening.
2. From the previous discussion, this parameter ended up being used for abbreviations and demonyms. E.g., "Cornellians" or "CU" rather than "Big Red" for Cornell University. While some institutions, like UCLA, have a demonym that matches their sporting nickname, this is not universal. And there are institutional nicknames like "Harvard of the South" and "Oxford of the North".
Maybe cutting the parameter down to |sports_nickname= (or possibly |sporting_nickname=, following the pattern for affiliations) and changing the display text to match would work better.
3. Fair enough. This isn't something I feel strongly about personally. Robminchin (talk) 02:58, 3 June 2026 (UTC)[reply]
@Robminchin:
  1. Totally fair point. I agree with your premiss so let's just make it |postal_code= then. If that is good enough for {{Infobox settlement}} it should be good enough for this. If this was displaying differently I would worry about WP:ENGVAR more, but these all display exactly the same. There is no corresponding label identifying it as a "Postcode" vs "Zip code" vs "Postal code". If you look at line 116 in the code, even the HTML class is "postal-code". Just simplify this custerf%$k. (Side note for transparency, I'm American so this is not about me choosing my preferred variant.)
  2. If I understand you correctly, this is what you are thinking?
    | label49    = {{#if:{{{athletics_nickname|}}}|Athletic|Sports}} nickname{{pluralize from text|{{if empty|{{{athletics_nickname|}}}|{{{sports_nickname|}}}}}|plural=s}}
    | data49     = {{if empty|{{{athletics_nickname|}}}|{{{sports_nickname|}}}}}
    
    My only concern is what do we do with the pages that are currently set to use |nickname=? Do those get sports or athletics? (Or does it really matter?) Also I maintain that we really do not need to differentiate between sports and athletics. Can we just agree that Sports and Athletics mean the same thing and simplify this further to:
    | label49    = Sports nickname{{pluralize from text|{{{sports_nickname|}}}|plural=s}}
    | data49     = {{{sports_nickname|}}}
    
-- Zackmann (Talk to me/What I been doing) 05:00, 3 June 2026 (UTC)[reply]
Thanks. On 2, I intended to accept that we don't need to differentiate between sports and athletics, sorry that that wasn't clear. So I'm fine with the further simplification. Robminchin (talk) 17:57, 3 June 2026 (UTC)[reply]
Awesome! Glad we landed on the same page. Sorry for all the back and forth but appreciate the good discussion! Zackmann (Talk to me/What I been doing) 18:04, 3 June 2026 (UTC)[reply]
@Robminchin: do we want to also clean up some of these pluralized parameters? For example, do we really need to support both |founder= & |founders=? This can easily be resolved by doing label11=Founder{{pluralize from text|{{{founder|}}}|plural=s}} and further reducing the long list of conflicting parameters? Zackmann (Talk to me/What I been doing) 18:39, 3 June 2026 (UTC)[reply]
I suspect not. Those are almost certainly legacies from before that was available. Thanks for doing this work!
There are also a bunch of different 'head' parameters that might be better split into just 'ceremonial head' and 'executive head', but disentangling those would be very tricky. My best guess is that president, vice-president, vice-chancellor, provost, superintendent, principal, officer-in-charge, director and dean are always or almost always executive positions and could be replaced by suitable use of head_label. Rector, chancellor may be executive or ceremonial positions (and some universities have both as ceremonial positions), so that would be a lot harder to sort out. Robminchin (talk) 19:57, 3 June 2026 (UTC)[reply]
I'm going to tackle the pluralized params but leave the multiple different "head" parameters as they are. No reason those cannot co-exist. Zackmann (Talk to me/What I been doing) 20:00, 3 June 2026 (UTC)[reply]
@Robminchin: does it make more sense to keep the plural version or the singular version? In the sandbox I have it setup keep the plural version of the parameters.... Zackmann (Talk to me/What I been doing) 20:11, 3 June 2026 (UTC)[reply]
That looks sensible, and makes it clear that multiple values are okay. It might be worth including 'sporting affiliation(s)' with the others as this can be singular even though it's currently only plural. Robminchin (talk) 21:07, 3 June 2026 (UTC)[reply]
 Done Zackmann (Talk to me/What I been doing) 22:43, 3 June 2026 (UTC)[reply]
Why are |campus_type= and |campus_size= seemingly being merged? They are two separate parameters, clearly documented, that we intentionally deconflated. Sdkbtalk 13:38, 5 June 2026 (UTC)[reply]
@Sdkb: both parameters currently appear under the same label of |label#=Campus so it didn't seem to make any sense to have 3 separate parameters that are displaying the same information. |campus=, |campus_type= & |campus_size= all show up under the same label so what is the point of having separate parameters? I genuinely did not realize this was intentionally done so will put a hold on any additional changes to these parameters while this is discussed but can you provide more insight. I know that at {{Infobox school}} there are 3 completely separate parameters, that do not conflict. How about we just go that route instead? That way all 3 parameters work without any issues. Thoughts? --Zackmann (Talk to me/What I been doing) 19:39, 5 June 2026 (UTC)[reply]
Due to some off-wiki things I unfortunately don't have the brainspace to remind myself exactly how defining conflicts/deprecation/etc. affects everything. The discussion linked above I think lays out the intended goals. Overall, |campus= is just too ambiguous, so I think we should be ultimately pushing toward it being deprecated in favor of the more specific parameters. Sdkbtalk 14:04, 6 June 2026 (UTC)[reply]
  • Cease and rollback the edits. I came across Special:Diff/1357988944, where your edit caused the label "Sports nickname" to be erroneously changed to "Sports nicknames". I saw that you and Robminchin were discussing something related to plurality above, so I presumed that that had been handled, but clearly it has not been. One of the major changes here seems to be changing a bunch of labels to plurals, and I'm guessing this is causing many other plurality issues elsewhere. You promised in bold at the top that this will not change the display on any transclusions. This is clearly not turning out to be true. It is incumbent on you to check before making a widescale change that it will not break existing functionality. Until that is done here, this should not proceed and the edits made so far should be rolled back. Sdkbtalk 17:30, 6 June 2026 (UTC)[reply]
    @Sdkb: can you provide an accurate diff please? The diff you linked to is from May 16th and is not one of mine... Zackmann (Talk to me/What I been doing) 17:32, 6 June 2026 (UTC)[reply]
    Sorry, I fixed it a moment ago as you were typing your reply. It should be correct now. Sdkbtalk 17:36, 6 June 2026 (UTC)[reply]
    @Sdkb: I found the issue you were referring to. There was an error in the template logic. Check the page now. There is no need to mass rollback anything. Yes I made a minor error in the template and I genuinely appreciate you pointing that out. But a label being changed from "Sports nickname" to "Sports nicknames" (emphasis added) is a pretty minor issue.
    For transparency, there is an issue with the logic while this cleanup is being done. Previously if the parameter was plural, the label would be plural. See Special:Diff/1357966960/1358115480. In short, since we are transitioning to exclusively pluralized parameter names, the logic has to change. Once the cleanup is done, the label will be properly pluralized based on whether there are multiple nicknames provided or just one. Zackmann (Talk to me/What I been doing) 17:41, 6 June 2026 (UTC)[reply]
    Follow up, if you find any other issues, don't hesitate to let me know and I will address them ASAP. Zackmann (Talk to me/What I been doing) 17:42, 6 June 2026 (UTC)[reply]
    Okay, thanks for the quick reply, and apologies if I was a little strong above. Plurality can be complicated, but having now read your exchange above, I do agree there are improvements we can make.
    To follow up to Robminchin's question, can we put a bit of further thought/search for precedents on whether it's better to have all the labels be plural or singular? That decision affects quite a lot of code. Sdkbtalk 17:51, 6 June 2026 (UTC)[reply]
    Do you mean whether all the parameters should be plural or singular? Because not all of the labels are going to be plural... Zackmann (Talk to me/What I been doing) 17:55, 6 June 2026 (UTC)[reply]
    Yes, I meant parameters. Sdkbtalk 18:20, 6 June 2026 (UTC)[reply]
    I'm happy either way. Personally I think plural makes the most sense but honestly not the hill I want to die on. If you feel strongly it should be singular I'm fine with that. My real concern is having multiple, conflicting parameters that do the same thing. THAT does cause issues. @Robminchin: any thoughts? Zackmann (Talk to me/What I been doing) 18:40, 6 June 2026 (UTC)[reply]
    Whether parameters are plural of singular isn't something I feel particularly strongly about. I think that if we're having a one parameter rather than two – which I understand its preferable for coding reasons – I would lean towards the plural for anything that can be either singular or plural. Putting a singular entry into a plural parameter just feels slightly more natural to me then putting a plural entry into a singular parameter. Robminchin (talk) 19:04, 6 June 2026 (UTC)[reply]
    It's something that applies much more widely than just this infobox, so I wonder if there are precedents or guidance at WT:WikiProject Infoboxes. Sdkbtalk 03:23, 7 June 2026 (UTC)[reply]
    @Sdkb and Robminchin: There is obviously more to discuss. I have reverted my changes to the infobox and will fix any broken pages that pop up as a result. I am monitoring for them. No need for me to rush this. Lets talk this out more.
    So, having done dozens of these types of clean ups on Infoboxes, the standard protocol here is all over the place... For example, look at {{Infobox person}} which has |other_names=, |occupation=, |monuments=, |employer=, |parents=, |spouse=, etc. We are going back and forth between plural and singular. Here is what I think is most important with what we do:
    1. Ensure that {{Pluralize from text}} is used so that the label displays correctly
    2. Document the parameter and make clear in TemplateData, documentation and examples which is the valid one.
    3. At least attempt (better than {{Infobox person}}) to stay consistent across the Infobox.
    I also would encourage us to think about which parameters are more likely to be singular vs plural and error on the side of using that, while still allowing for the outliers that fall on the other side. For example, I think |mascot= is safe as singular. IMHO most universities will only have 1 mascot. You can certainly add more and that will be supported for the cases where there are more than 1, but most will be singular. I would think the same thing for sport nicknames. Most universities would have 1 nickname, but again we still would allow for the case where more than 1 exist.
    Let me know your thoughts. Again, any further changes by me in this area are on hold until we reach a good consensus. Zackmann (Talk to me/What I been doing) 04:02, 7 June 2026 (UTC)[reply]
    Any thoughts on the above? Zackmann (Talk to me/What I been doing) 02:07, 9 June 2026 (UTC)[reply]
    @Hike395, Jonesey95, Phuzion, and Gonnym: this discussion has kinda stalled and wondering if you 4, who have been involved in these projects elsewhere, can chime in with some opinions.
    TLDR: for the sometimes plural, sometimes singular parameters (former_name, mascot, other_name, etc), should we deprecate the singular version or the plural version? Note we will be using {{Pluralize from text}}. Zackmann (Talk to me/What I been doing) 03:20, 13 June 2026 (UTC)[reply]
    I think it makes the most sense to have the plural or singular form of each parameter as the default based on whatever is the most likely to be the case for most instances. On {{Infobox person}}, you have |occupation=, |employer=, and |spouse= as singular, whereas |other_names=, |monuments=, and |parents= are plural. Most notable people do not have more than one notable employer, occupation or spouse, whereas most notable people might have more than one name they are known by, everybody has at least two parents, and if you're worthy of one monument, it's plausible that you might be worthy of more than one.
    Consider, if a newer editor comes across and wants to add an additional mascot to the infobox, and the parameter name is |mascot=, they might change it to |mascots=, thinking that they need to in order for it to display properly. My vote is for whichever is least likely to cause editors to create backlog work (such as putting articles into Category:Pages using infobox university with unknown parameters). I don't have enough familiarity with these articles to make an informed decision here, so I will defer to members of WP:HED who might be more familiar with the infoboxes here. phuzion (talk) 13:50, 13 June 2026 (UTC)[reply]

Update

[edit]

After much discussion above, here is what I'm thinking of doing:

Deprecate/Remove Replace with
|image_name= |image=
|vice-president= |vice_president=
|other= |other_students=
|postalcode= |postal_code=
|postcode=
|zipcode=
|coor= |coordinates=
|athletics_nicknames= |sports_nickname=
|nickname=
|athletics_nickname=
|sports_nicknames=
|athletics_affiliations= |sporting_affiliations=
|mottoeng= |motto_eng=
|affiliation= |affiliations=
|other_name= |other_names=
|former_name= |former_names=
|founder= |founders=
|academic_affiliation= |academic_affiliations=
|mascots= |mascot=
|enrollment= |students=

Going to mock this up in the sandbox. -Zackmann (Talk to me/What I been doing) 22:55, 13 June 2026 (UTC)[reply]

Looks good to me. Thanks. Robminchin (talk) 03:23, 14 June 2026 (UTC)[reply]
Looks pretty good to me. One risk to be aware of is that plural values encourage overuse, e.g. that someone sees |founders= and decides to list everyone associated with a university's founding rather than the one main founder who is the only person actually due. But hopefully that won't happen. Sdkbtalk 20:52, 14 June 2026 (UTC)[reply]

No more conflicting parameter category?

[edit]

I see that the conflicting parameter category for this infobox is up for deletion, why is that occuring?Naraht (talk) 04:00, 18 June 2026 (UTC)[reply]

It looks related to @Zackmann08's cleanup efforts above, which have succeeded in clearing out the conflicting parameters — congrats on that!
Before we get rid of Category:Pages using infobox university with conflicting parameters, though, we should consider whether there might be conflicting parameters that'd need cleanup in the future. For instance, I don't have capacity to do it myself at the moment, but I'd like to see us set up a maintenance category for all instances where the deprecated alias |campus= is used and convert them to either |campus_type= or |campus_size= or both. Given that, and the notice on the category that it should be kept even if empty, I'd lean toward retaining it. Cheers, Sdkbtalk 06:45, 18 June 2026 (UTC)[reply]
Infobox university
Campus
  • {{{campus_size}}}
  • {{{campus_type}}}
  • {{{campus}}}
So, to clarify, it is not just that the category is empty. It is that it is no longer needed. If you look at the actual source code of the Infobox, there are no longer any conflicting parameters. I want to be clear, I did NOT nominate for deletion because it was empty, but because it was no longer being used.
@Sdkb: If you wish to do a cleanup to convert |campus= to either |campus_type= or |campus_size= I fully support that effort, but I want to be clear that at the moment those are not conflicting parameters as shown via the example at right. Zackmann (Talk to me/What I been doing) 16:13, 18 June 2026 (UTC)[reply]
Thanks for clarifying, @Zackmann08. I'm not sure that we can know for sure that we won't decide to declare some other parameters conflicting in the future, but I guess if we do that we can just restore/recreate the category?
Regarding |campus=, what would you suggest would be the best way to indicate on all articles that use that alias that there is a problem? The history is that it once was a widely used parameter, but because it's not clear whether it refers to campus type (rural, urban, etc.) or campus size (e.g. 47 acres) or both, we want to convert all instances of it to the more specific options. (Splitting out the data like that also makes it easier to integrate with Wikidata and utilize it in other ways.)
Cheers, Sdkbtalk 22:32, 22 June 2026 (UTC)[reply]
The point is that at present there are no conflicting parameters, so the category is not being populated by anything, so WP:C4 applies. If in the future conflicting parameters are added (which they shouldn't be), the category can absolutely be recreated.
Easiest way to track all uses of |campus= would be to add the following code to the bottom of the Infobox {{#if:{{{campus|}}}|[[Category:Pages using infobox university with campus]]}}. Note that will categorize regardless of namespace. To only do articles, add {{main other}}. Zackmann (Talk to me/What I been doing) 22:36, 22 June 2026 (UTC)[reply]