I found this page onthis awful list of pages that use template parameters or magic words directly in articles. I think there are some false positives on the list (some of the instances of PAGENAME might be acceptable, and even helpful in the event of page moves), but there is a lot of junk to fix there. There is a lot of low-hanging fruit, likethese 29 articles (note triple braces) andthese 80 pages. –Jonesey95 (talk)20:12, 10 November 2025 (UTC)[reply]
Usages in articles of the PAGENAME magic word in an infobox is usually just a sign of either a bad design of the infobox or editors not understanding how to use the infobox correctly. In both situations it should be removed. If the infobox uses the page name of the article, then just code it to use it and only use an override if its needed. So something like:parameter ={{If empty|{{{parameter|}}}|<includeonly>{{PAGENAMEBASE}}</includeonly>}}.Gonnym (talk)11:39, 11 November 2025 (UTC)[reply]
Indeed; I have been working on batches of pages, and every once in while, there is an outlier. Manual checking is good.Here's another batch of 263 pages that needPAGENAME removed. Our work has gotten the population of that report down from about 4,500 to about 3,000 pages so far. Probably a dozen or two of the remaining ones need to be addressed carefully, using { instead of removing the third brace where it is wrapping a template,like this. –Jonesey95 (talk)19:48, 11 November 2025 (UTC)[reply]
@Jonesey95: thanks for the tips you posted below. Good to have a second set of eyes on these. Found out the hard way about subst not working in ref tags.Facepalm that is ANNOYING... Side note, is there any MOS you can point me too that explicitly says parser function logic should not be used in the article space? It seems obvious that behavior belongs in a Template, but is that actually explicitly said anywhere?Zackmann (Talk to me/What I been doing)05:37, 13 November 2025 (UTC)[reply]
Not that I know of, but[1] is marked as "high priority". For me it comes down to two main things. The first being that regular editors understand plain text much better than wikipedia template language code. The second is that fixing "small" code issues, will clear up the noise to find actual real errors (like someone copy-pasting a navbox instead of transcluding it). So in the end every fix is valid.Gonnym (talk)06:35, 13 November 2025 (UTC)[reply]
I don't know of any such guidance, but I haven't looked very hard. As for "high priority" etc., it is always valuable to remember, especially for neglected reports such as this one, that the report was created by a human at some point, and that human may or may not have understood all of the possible cases that would be surfaced by their report. They may have been basing the report on a guideline or policy that has subsequently changed. It is best not to trust such reports blindly. There are many definite errors in the report, but some of the cases seem marginally reasonable to me, like the use of PAGENAME to avoid having to edit pages that might be moved to a new name. Some of the uses of table markup templates inside templates also seem like reasonable exceptions. –Jonesey95 (talk)15:26, 13 November 2025 (UTC)[reply]
That is true, but when something has been like that for a long time, probably many years, and no one has complained with pitch forks, then that's a sign that that the WP:ONUS to change that priority is on those who are complaining. So whatever the reason behind the priority setting, it's pretty much set in stone until officially challenged, which I'll be there to oppose.Gonnym (talk)15:44, 13 November 2025 (UTC)[reply]
"It's always been like that" is a shaky justification for any practice. It's always good to do a bit of research and have a real justification. As I said, there are valid usages in that neglected report; it might be better to figure out how to adjust the report to match current (best?) practices. –Jonesey95 (talk)16:38, 13 November 2025 (UTC)[reply]
Yeah, I saw a few of those oddballs. I assume someone was trying to somehow preserve the original case of the title printed in the book, instead of just followingMOS:TITLECAPS like we are supposed to do. –Jonesey95 (talk)04:46, 14 November 2025 (UTC)[reply]
Partly done1,000+ pages with PAGENAME (or variant) (note that substing doesn't work inside<ref>...</ref> tags). Beware of pagenames like "Sümeyye Özcan (footballer)". this one didn't really work...
Done240+ instances of #ifexist - subst the result of the parserfunction (better: show red links, which are fine; most of these links are for women, and we need to create missing articles about notable women)
120+ instances of #ifeq - Check for article's transcluding section. If none, subst result of the parser function. (note that some of these are testing things like the current month to display a value like "closed" or "open" for a highway; replacing these with a template is probably the right fix)
220+ instances of #if - Check for article's transcluding section. If none, subst result of the parser function.
DoneReplace manual switch statement with new template,{{Date of next Friday}}. There is probably a better way to structure and name this new template so that it can work for any day of the week, but it looks like there are 28 articles, some with multiple #switch statements, that could use this replacement.
The following discussion is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hey, I was wondering if you can explain the need for|mapframe=yes (I browsed the code and didn't dive into so hopefully you don't mind saving me the effort). If someone uses the other mapframe parameters like|mapframe=zoom wouldn't the backend already know to use the mapframe? Or can the zoom value be for something else also?Gonnym (talk)21:23, 23 November 2025 (UTC)[reply]
@Gonnym: so full disclosure I did not designModule:infobox mapframe so I am not privy to why certain design choices were made. You could certainly make an argument that if|mapframe-zoom= is turned on it should default to turning on the mapframe itself... The issue I think is that many of those params are set in the infobox, not the transclusion. Let me try to explain...
If you look at{{Infobox settlement}} you will see that (for example)|mapframe-marker=town. Now you can always override that on a specific transclusion, but if the code for the module said"If any of themapframe-... params are set, then turn on the mapframe", the mapframe would be turned on for ALL transclusions of{{infobox settlement}}.
There is also the logic in most infoboxes turn turn on the mapframe by default if there is no pushpin map... What you are suggesting could be a useful improvement, but I think it just has other side effects that you may not realize.
Side not, is there a specific transclusion you are looking at that is concerning? Or was this more of a general attempt to understand how/why something works?
Nothing specific, I just found it strange. It's like we would add|image=yes and|image-file=example.jpg, which we obviously don't do, even though we have a similar situation there. For{{infobox settlement}}'s example, I'd add a conditional check in the template's code to only call the module if the required parameter is used (or even better, if|mapframe-marker= by itself should trigger anything, then disable it at the module level and have even cleaner code). I have no idea how map-frame works so I have no idea which parameter is the "required" one for it to display something correctly. But in general, I'm against the idea of having the end-user add redundant parameters when we, the developers, can do the work for them behind the scenes.Gonnym (talk)06:42, 24 November 2025 (UTC)[reply]
So your example of|image=yes doesn't really fit. While I get what you are saying it is a bit different here. The key difference is found if you look into|onByDefault= in the call toModule:Infobox mapframe.
Basically in{{Infobox settlement}}, if you look at the source code you will find an#if: statement that checks if a{{{pushpin_map}}},{{{image_map}}} or{{{image_map1}}} have been supplied. If they have not been, then the mapframe is turned on by default and using|mapframe=yes in that articles transclusion is, in fact, redundant and not needed. HOWEVER, if for example a pushpin_map is supplied, you must specify|mapframe=yes in the article to turn on the mapframe.
Now your argument seems to be that if any of the othermapframe-... params are supplied in the article, that should ALSO turn the mapframe on and negate the necessity for saying|mapframe=yes. That is an interesting idea. From a technical standpoint I'm not sure what that would look like though because so many of those parameters are also defined in the call to the module in{{Infobox settlement}} so I'm not even sure it would be possible. Additionally, this sort of change would likely result in suddenly turning on mapframes in a large number of articles where they previously were not onwithout any changes being made to the articles themselves. This could be very confusing for editors who have no idea why maps are suddenly showing up in an article with no recent changes.
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Remove birthdate and birth name in Tony Nardi's wikipedia page
I do not want my birthdate and birth name on the Wikipedia Page. I have asked for it to be removed in the past, and to respect my privacy, and it disappeared for awhile, but suddenly it's back. What about this message is difficult to understand? Thank you. Tony Nardi~2025-35918-69 (talk)08:12, 24 November 2025 (UTC)[reply]
Hello Zackmann08. I am just letting you know that I declined the speedy deletion ofKen Shults, a page you tagged for speedy deletion, because of the following concern: Footbag world champion is a credible claim of importance. Thank you.Whpq (talk)03:23, 25 November 2025 (UTC)[reply]
HiZackmann08, just a note on the population density calculation which I know you have automated in the settlement infobox. It may not be as straightforward as it seems. Population density should be calculated using the land area, not the total figure. Sometimes these are the same, particularly for dry inland areas. But for coastal areas or places with a lot of large inland lakes like Florida or Scotland, the total area figure and the land area figure will be very different.
The settlement infobox therefore has two relevant area fields: area_total_km2 and area_land_km2. The density figure should be calculated using the area_land_km2 figure, not total (unless the land field is empty which usually means that the land and total figures are the same). For a real life example, seeLiverpool, England.Dgp4004 (talk)12:41, 26 November 2025 (UTC)[reply]
It's also worth noting that whether the area figures are rounded or not (they usually are) will affect the density figure. For example Liverpool's land area is 111.842 km2, which gives a density of 4551. But calculated from a rounded land figure of 112 km2, the density becomes 4544. And if calculated from the total area figure, density would be the wildly inaccurate 3798.Dgp4004 (talk)12:48, 26 November 2025 (UTC)[reply]
Thanks for the message. I did see it... While thus far I like it, I think it has a LONG way to go before it can replace the mapframe and pushpin maps we currently use. But we shall see! Happy Turkey Day (if you're American)!Zackmann (Talk to me/What I been doing)16:17, 27 November 2025 (UTC)[reply]
Done Got all those taken care of plus a few other variants. If you find anymore, feel free to drop me another link!Zackmann (Talk to me/What I been doing)00:35, 11 November 2025 (UTC)[reply]
--Zackmann (Talk to me/What I been doing)22:44, 11 November 2025 (UTC)[reply]
Facepalm that is ANNOYING... Side note, is there any MOS you can point me too that explicitly says parser function logic should not be used in the article space? It seems obvious that behavior belongs in a Template, but is that actually explicitly said anywhere?Zackmann (Talk to me/What I been doing)05:37, 13 November 2025 (UTC)[reply]
Partly done1,000+ pages with PAGENAME (or variant)