User talk:MSGJ

From Wikipedia, the free encyclopedia

Template:Set index article section

Template:Set index article section is currently unused and undocumented. Do you have a plan for it? Unused templates are typically deleted. – Jonesey95 (talk) 15:02, 12 February 2026 (UTC)

For context, see Template talk:WikiProject banner shell/Archive 11#Set index articles. It obviously was not taken up, so I've deleted it  Martin (MSGJ · talk) 16:39, 12 February 2026 (UTC)
Thanks for that. I saw the discussion and figured as much, but for editors whose names I recognize, I like to reach out instead of just going to TFD. – Jonesey95 (talk) 16:46, 12 February 2026 (UTC)


Hyboserica vs. Hyposerica

The way the articles are now is correct. The confusion between these genera was introduces by a taxonomic database and other followed this. I have read that in a research article somewhere. I will try to find it for you (not right now though). But please don't move the articles. The systematics as presented on CoL is correct and I used that one. B33tleMania12 (talk) 15:59, 13 February 2026 (UTC)

How confusing! Please can you update their parent taxon on Wikidata when you have time  Martin (MSGJ · talk) 16:01, 13 February 2026 (UTC)
You can find it here, last paragraph: https://tb.plazi.org/GgServer/xhtml/03EA8A534926FFD7AF29F931FBEBC745 (it even mentions wikispecies!) B33tleMania12 (talk) 16:03, 13 February 2026 (UTC)
I am not to good with wikidata, but I will have a look later today (I hope) B33tleMania12 (talk) 16:03, 13 February 2026 (UTC)
I've fixed a couple but there are probably more  Martin (MSGJ · talk) 16:04, 13 February 2026 (UTC)
On wikidata you mean? I will have a look later. It should be as it is on wikipedia now. Oh, and Hyposerica laevigata is now Balbera gracilis (https://www.catalogueoflife.org/data/taxon/KGF7). We dont have that species page yet, but I will get to it one day. B33tleMania12 (talk) 16:06, 13 February 2026 (UTC)
Think I've got most of them. Do you have any reference for Hyposerica strenua or Hyboserica strenua?  Martin (MSGJ · talk) 16:20, 13 February 2026 (UTC)
Awesome, thanks! For strenua: https://www.catalogueoflife.org/data/taxon/3NYM5 and https://ia801901.us.archive.org/9/items/biostor-71020/biostor-71020.pdf (page 101 of the pdf and originally page 261 in the publication)

Duplicate WikiProject additions

Thank you for catching and undoing five instances of duplicate WikiProject additions that I inadvertantly made. The reason is that they used WP or wikiProject instead of the usual WikiProject, which I did not catch and skip. I regret the error, and have updated my settings to skip these cases. —ADavidB 01:34, 18 February 2026 (UTC)

TwoLeg start

Hello and sorry for bothering. A few days ago I opened a discussion at the TwoLeg start template talk page regarding a possible improvement related to replay matches in competitions that do not use a traditional two-legged format. I also left a ping since you have previously edited the template and seem familiar with its structure.

Since I haven't received any feedback yet, I just wanted to ask if you might have the time to take a look at the proposal when convenient. The idea is to introduce an optional parameter (for example |replay=y) so that the column headers can display "Match / Replay / Score" instead of "1st leg / 2nd leg / Agg." in cases where ties are decided by a replay match rather than a second leg.

Of course, this is only a suggestion for discussion and any feedback or guidance would be greatly appreciated. Thank you for your time! BEN917 08:13, 10 March 2026 (UTC)

Lua errors on Trinity linked to your recent changes to Template:Infobox NRHP and Module:Designation/sandbox

I noticed that Trinity (nuclear test) is displaying a Lua error when attempting to render the Infobox NRHP template. The error I'm seeing is "Lua error in Module:Designation/sandbox at line 204: attempt to concatenate field 'col' (a nil value)". The infobox still at least partially renders despite the error, but the parameters are messed up with significant visual errors (e.g. showing "{{{DESIGNATED_OTHER1_ABBR}}} No." for one parameter, and "Designated {{{DESIGNATED_OTHER1_ABBR}}}" for another parameter). I already purged the cache on that page to rule out cache issues.

When I checked the edit history of Template:Infobox NRHP, I saw that you had recently changed this template to use Module:Designation (albeit as Module:Designation/sandbox) instead of the previous method just two days ago. I don't quite understand why you'd use the module's sandbox for a live infobox instead of the base module – presumably that was human error and not intentional? It seems that you invoke the module directly in earlier edits, so I think using the sandbox instead of the module was probably a mistake here. Regardless, it appears that your change is likely the origin of this error.

I'm not quite sure if the issue is with using the sandbox instead of the base module, or if the issue lies in the module's code, or if the issue lies in the implementation of the use of said module within the infobox template.

Either way, I'm pretty sure that your edits are the cause of this issue and that you're probably also the best (if not only) candidate to debug and address this issue in a timely manner, so I figured it'd be best to raise this issue with you directly on your talk page instead of via one or more of the multiple different affected article/template/module talk pages.

Hopefully you can get a chance to take a look at this and fix it sometime in the next few days. Trinity is a fairly important FA, so it'd be ideal to fix it sooner rather than later if at all possible. I assume other articles beyond Trinity are likely also affected as well, but I don't know exactly how many. Based on the bot auto protecting the module's sandbox due to it passing the minimum transclusion count to trigger auto template protection, I assume the blast radius is up to a minimum of 7500 articles potentially affected, although I'm not sure how large of a subset is actually seeing Lua errors like this one.

Anyways, best of luck with debugging this issue, and please me know if there's anything else you need from me. Garzfoth (talk) 18:59, 15 March 2026 (UTC)

Hi Garzfoth, thanks for letting me know. I have fixed the error with the color, so the unsightly warning has gone. I did not intend to use the sandbox, so I appreciate the note about that too. Regarding the DESIGNATED_OTHER1_ABBR, I assume you can confirm this was not an issue previously? I do not think it was my edit that changed this, but I might be wrong. I will investigate further ...  Martin (MSGJ · talk) 21:58, 15 March 2026 (UTC)
Thanks for fixing the color issue!
The other issue with the two instances of "{{{DESIGNATED_OTHER1_ABBR}}}" showing appears to be a new issue that appeared at some point between February 13 2026 (wayback machine - working) and March 9 2026 (wayback machine - broken).
What should be displaying in place of "{{{DESIGNATED_OTHER1_ABBR}}}" on the Trinity article specifically is "NMSRCP". You can see this in the working wayback machine capture from Feb 13th.
It also looks like Template:Designation/color (and its replacement) is also involved. Observe the background color of the heading item "NM State Register of Cultural Properties" on the two wayback machine archive versions. You can see that it loaded the correct one originally, but fails to do so now with the new implementation.
After many hours of debugging, I think I have finally figured out the root cause for both of these issues.
In short, the "nmsr" entry in Module:Designation/list is missing the "col" and "abbr" attributes. I believe that the lack of a "col" attribute is causing the color issue, and the lack of a "abbr" attribute is causing the "{{{DESIGNATED_OTHER1_ABBR}}}" issue.
If I am correct, then should should be fixable by editing Module:Designation/list to implement the following diff:
More information Extended content ...
Close
Apologies for the awkward formatting of the "diff", but it is apparently impossible to use the text diff template for multi-line diffs, and I am not aware of any better way to format this.
If implementing this change fixes the issue (which I am pretty confident it will), then all other remaining entries in Module:Designation/list which lack a "col" and/or a "abbr" entry will likely also need to be modified to re-add those missing attributes in order to prevent this issue from affecting other pages as well.
It looks like there are a fair number of entries that lack at least one of those attributes, but many entries seem to have both of them, which is probably why it took so long for this issue to be reported.
Anyways, I think this change will probably fix the root issue for this page. Please let me know when you attempt this change and if it actually fixes the issue.
Sorry for the delay in responding, debugging this took far longer than I expected and I had to take a few breaks to work on some other stuff in between working on debugging this. Garzfoth (talk) 04:38, 16 March 2026 (UTC)
Thanks again for your time in analysing this issue. I added the abbreviation and it did indeed resolve the problem. I need to make the code more robust in case there are other designations which do not have abbreviations. What should happen in these cases, in your opinion? Should that row simply be omitted from the infobox?  Martin (MSGJ · talk) 10:15, 17 March 2026 (UTC)
I think this is a two-part answer.
There are two separate issues here.
The first issue is that there is a severe data quality issue with Module:Designation/list.
The second issue is that as a consequence of this data quality issue, some unknown but likely significant percentage of the 75,000 articles using Template:Infobox NRHP are now experiencing errors with their infoboxes.
You're focused on how to handle the error. My primary concern is addressing the data quality issues.
I think the fact that these articles are showing visual errors is actually a good thing. The only reason I caught this issue in the first place is because I saw the visual error in the infobox and decided to attempt to investigate what was causing it.
If your proposed option of "simply [silently] omitting that row from the infobox" (paraphrased) was implemented, I would never have noticed this issue in the first place. You may argue that this is a good thing, as it means we would not be showing our visitors errors. However, the content of the affected infobox fields is still displayed, and still contains useful information.
Furthermore, if we silently hide valid infobox fields, then editors will wonder why their wikitext fields in the infobox are not rendering. Even worse, editors may (and likely will) assume the affected wikitext fields in the infobox are obsolete/broken because they are not rendering, and simply outright delete them from the wikitext in order to "clean up" the infobox wikitext. This would have catastrophic effects, as perfectly valid and useful entries would start to become irrevocably lost.
Yes, in theory another editor could salvage them in the future, but I have been highly active in energy-related infobox editing for over a decade, and in that time, the number one thing I have noticed is that infobox edits tend to be very sticky but also tend to degrade significantly with time (often by editors ineptly attempting to make "helpful" "improvements" that are anything but), so any information loss is unlikely to be caught and reverted for more than a subset of affected articles.
My proposed best choice option for handling the visual display in infoboxes is to maintain the current approach for the time being while we work to correct the issues in Module:Designation/list that are the actual cause of this problem.
I considered options for changing the content of the message, however I believe that there is no change that could be made at this moment that would be worth the effort involved to implement it. The only possibly change potentially worth considering is to adjust Template:Infobox NRHP or possibly also Module:Designation to automatically place all affected articles into a tracking category in order to make it easier to identify and remediate this issue. However I don't think this is completely necessary at this time.
If you do decide that you want to go ahead with this change, please note that I only think it is a good idea to add this feature on top of the existing behavior, not to replace the existing behavior with this feature. In other words, infoboxes should continue to display the current "{{{DESIGNATED_OTHER1_ABBR}}}" messages even if you end up adding the automatic tracking category functionality.
Now that I've said my piece on the issue of how to handle display of this error, let's move on to the much more important topic of addressing the root cause of this error.
In order to better understand the exact scope of the data issues in Module:Designation/list, I downloaded the entirety of Module:Designation/list to my computer as a json file, and used jq] queries to analyze it in order to try to get an idea of the exact scope of the problem.
According to my initial analysis, of the 180 total entries in the current list, 16 of them lack a col2 attribute, 30 of them lack a col attribute, and 85 of them lack an abbr attribute.
I did not directly check the overlap between col2 and col attributes for individual entries as I did not want to spend time on constructing a jq query capable of calculating this, however if 16 entries lack a col2 attribute and 30 entries lack a col attribute, then it's probably safe-ish to assume that 16 of the 30 entries lacking col attributes are likely entries that intentionally lack color, and therefore that only 14 of the 30 entries lacking col attributes actually require remediation.
Assuming that that is correct, then we need to remediate the lack of a abbr attribute for 85 of the 180 entries in Module:Designation/list, and we also need to remediate the lack of a col attribute for 14 of the 180 entries in Module:Designation/list.
After completing this initial analysis, I wrote a new set of jq queries to drill down deeper and get an exact sample of the affected entries.
The first level of results from this second pass are:
  • There are 21 entries where col2 is defined, but col is not defined.
    • For 10 of these 21 entries, abbr is also not defined.
  • There are 85 entries where abbr is not defined.
    • For 17 of these 85 entries, col is also not defined.
      • For 10 of these 17 entries, a col2 definition is currently present.
At absolute minimum, we need to remediate any entry where either:
  • abbr is not defined
  • col2 is defined but col is not defined
Based on that criteria, I wrote a third set of jq queries in order to determine the exact numbers of articles that are affected by one or both of those two issues. I then wrote one final query that combined all of these queries together in order to get a total count of all articles affected by one or both issues.
The final query looks something like this: .abbr == null OR (.col == null AND .col2 != null) (incomplete pseudocode excerpt)
The results of that query show a total of 96 affected entries. In other words, of the 180 entries in Module:Designation/list, 96 of them exhibit one or both of these data quality issues.
I will insert the full results of said final query below:
More information Extended content ...
Close
Every single one of these entries must be corrected in order to permanently fix this issue.
I would normally offer to assist with this task to some degree (I'm not sure I'm up for fixing 100% of these, but I'd be willing to try tackling a subset of them). However unfortunately I do not have template editor permissions, so I cannot edit Module:Designation/list.
I considered creating Module:Designation/list/sandbox, making some progress in there, then submitting an edit request once I've fixed at least a dozen entries, however it's unclear if it's acceptable to create sandbox pages in the Module namespace for tasks such as this (I am only familiar with template editing, I'm still mostly new to module editing).
Also, as far as I can tell, if I created that page, there'd still be no way to attempt to preview the effects of the changes on invocations of Template:Infobox NRHP, which is quite undesirable. If you are aware of any way to make that possible, I would be VERY interested in that, as I find it to be MUCH easier to edit with confidence when I can immediately test the effects of template (or in this case module) edits against test cases.
Perhaps if Module:Designation/sandbox was modified to use Module:Designation/list/sandbox as the source, then Template:Infobox NRHP/sandbox was modified to replace all calls to Module:Designation with calls to Module:Designation/sandbox? If that is possible, I could use Template:Infobox NRHP/testcases to preview/test/verify the effects of my edits to Module:Designation/list/sandbox. Could you please comment on this to let me know if this would be allowable or not?
Given how awkward it is to try to cherry-pick individual diffs, I am unwilling to attempt to edit Module:Designation/list through edit requests using manually formatted diffs like the initial edit request I originally posted on this page. I was willing to do it for that one entry, but for changes to more than one entry, the only sane way to handle things is either to edit Module:Designation/list directly, or to edit Module:Designation/list/sandbox then submit an edit request to merge them.
If you have any ideas for how we could more easily resolve these issues, I'm all ears.
In theory it should be possible to programmatically generate the col attribute fixes, however the abbr attribute fixes will unfortunately require a 100% manual process to resolve.
Anyways, that's the results of two hours of work on this issue. Hopefully this answers your questions and helps you decide on how to address/resolve this issue moving forwards. Please do let me know about if my proposed option with Module:Designation/list/sandbox (as well as the other proposal regarding the edits to other pages to enable testing/verification of the edits) is permissible or not. If it is, I am probably willing to attempt to fix at least a small subset of the 96 affected entries, and maybe more than that.
Thank you for all of your hard work on the migration from Template:Designation to Module:Designation, it may have introduced issues, but this was still a huge task to attempt, and I'm quite impressed at how nice the new implementation is compared to the old one, especially in its maintainability (json is so much easier to work with than template syntax!). Garzfoth (talk) 18:47, 17 March 2026 (UTC)

Related Articles

Wikiwand AI