FFXIV Wiki talk:Status effect icon revamp

Semantic data strategy

There are a few different strategies that have been talked about in the Discord, so I've done my best to list them here and discuss their pros and cons a bit. Please read this through and add your opinion as a reply down below.

1. Don't add semantic data at all

• Don't add any new semantic data or fundamentally change the structure of the effect list.
• Enforce a consistent naming scheme for icons that's derived directly from the name.
• Update {{game icon}} to know about this naming scheme and use it as a fallback behavior for status effects specifically.

Pros:

• No new semantic queries. No possible performance issues.
• We're mostly there already; we've mostly settled on File:{{lc:{{{name}}}}} icon{{{n}}}.png. There are some case inconsistencies but not so many that we couldn't handle them.
  • Using a number to disambiguate different icons with the same name is simple and good enough. We can easily write logic to convert "Vulnerability Up 2" to "File:Vulnerability up icon2.png" or whatever.

Cons:

• Doesn't change anything about the list of all status effects situation.
• Doesn't allow us to have effect descriptions, if that's something we wanted.
• {{game icon}} was specifically designed to use semantic data for icon lookups; adding a special-case to do a non-semantic lookup speccifically for status effects feels bad, like we're just tacking on a sloppy fix that will be a pain to deal with later. Reducing the amount of special casing we have to do was sort of the whole reason I started rewriting icon stuff in the first place.
  • Would also mean we get no information about whether a status effect is a buff or debuff. This only has minor impact on how icons are displayed, but it would be a regression.

2. Add semantic properties on individual effect pages

• Create a page for every status effect in the game, with a proper infobox template that sets the usual semantic properties.

Pros:

• Most consistent with how we do literally everything else (actions, traits, etc).
• {{game icon}} compatibility is free.
• We can convert the list of all status effects to a semantic table, which we have plenty of experience doing.

Cons:

• Gods that's going to be a lot of pages.
• Disambiguation of page titles will happen a lot, so we'll need a well-defined strategy to deal with that. We won't get away with adding arbitrary numbers to the end of the name like we currently do in the icon filenames.
• I personally don't know a lot about the performance of tables generated by large queries but that might cause issues? Tell me if I'm wrong there

3. Add semantic properties directly to icon file pages

• File pages are still articles and can contain semantic data.
• Instead of making a new page for every status effect, contain the semantic properties for each status effect in the effect's icon file page.

Pros:

• Fewer new pages.
• All information about each status effect is in one lightweight place, which is nice when there's so many of them.
• We can set whatever semantic properties we want, so we can still make this work with {{game icon}}.

Cons:

• File pages don't usually have content other than licensing notices, so this would be breaking mediawiki conventions a bit.
• It becomes more cumbersome to disambiguate effects that share an icon but have different names. We'd need two copies of the same icon so that each could have different "Has canonical name" values.
• {{game icon}} usage would look like {{game icon|File:Vulnerability up icon1.png}} - because the semantic data lives on a File page, you have to put the File: page name in the template.
  • This is compounded by the fact that we already have some full pages for common effects like stun, heavy, vulns, etc. - so this doesn't improve the issue we currently have with {{status effect}} where some icons can be referred to by name, but most need to be referenced by icon filename.
  • {{game icon}} could be modified to work around this, maybe, but I think it would be a brittle solution.
• List of all status effects will still be a large query table, for whatever that's worth

4. Add semantic properties as subobjects of File: pages Basically the same as 3, but fixes the issue with disambiguating "same icon, different name/effect" situations. Still has all the other drawbacks. I don't think this one is worth considering.

5. Add semantic properties as subobjects on the list of status effects

• Rework the list of status effects to be a table.
• Create a special "status effect table row" template used to define properties for each effect in a subobject, which can then be queried.

Pros:

• Single source of truth for all status effect info on the wiki, which makes it intuitive for editors to add missing effects as needed.
• No new pages.
• Disambiguation rules could probably use the looser "add a number to the end" system we already kinda have now.

Cons:

• List of status effects remains manually maintained and simultaneously becomes very long, since it is now the source of truth for all status effect information for the rest of the wiki
  • May need to get more information about the performance implications of pages with lots of subobjects - potentially need to split up the list into alphabetical subpages
• {{game icon}} may need modifications to work with this
  • Subobject names look like Page#id, so the best we could do without modification would be {{game icon|Status effects#Vulnerability Up}}. We can probably do better, but it will require some tinkering.

---

So, let's figure out how we want to do this. If you have any questions or other ideas I haven't listed here, feel free to bring them up in the discussion. (If you're new to talk pages, you may want to give Wikipedia:Help:Talk pages § Replying to an existing thread a quick read too.) Erin Umbreon (she/it • talk) 18:21, 19 February 2026 (UTC)

Personally I don't like options 3 and 4. Adding semantic properties to the file namespace sounded clever to me at first, but the more I think about it the more it sounds clever (derogatory) rather than clever (endearing). I'd be mostly fine with any of the others. I don't really like 1, but if we decide that doing semantic data is more trouble than it's worth, I can pinch my nose and make it work. Erin Umbreon (she/it • talk) 18:45, 19 February 2026 (UTC)

Ideally, the final output can be something similar to https://finalfantasy.fandom.com/wiki/Final_Fantasy_XIV_statuses where you have an alphabetized list of status with the icon and description. Our table will probably exclude historical descriptions (see Acceleration) if they are have been removed from the raw data. A data processing workflow could be:

• Process the status effect table in the exd sheet.
• Remove duplicate statuses. Duplicate statuses are defined as those that share an icon, a name, and a description to another status. If a given status does not share all 3 of those, it is not considered duplicate.

Another alternative would be to not remove duplicate statuses from whichever data structure we decide go with, but that would create issues with disambigs obviously. For the sake of readability, duplicates should be removed in a comprehensive status effect table.

- Dr Agon (talk) 19:05, 19 February 2026 (UTC)

I agree that's how the table should look - I especially like the way they present statuses that share a name an icon but have different descriptions, e.g. with Kardia. I think we can make a table that looks like that regardless of how we structure the semantic data though, so I'm not sure that narrows things down much (I guess it eliminates option 1 since we'll need to have descriptions stored). Erin Umbreon (she/it • talk) 19:46, 19 February 2026 (UTC)

There's also a middle ground for #2 (call it 2.5...), which is to create or update status pages with an infobox and semantic data for a subset of statuses, meaning the ones we need to reference in multiple pages. That's essentially what we have already done with the limited set of status pages we have, but without the benefit of semantic data. Gurgum (talk) 22:40, 19 February 2026 (UTC)