Titles should use fully data-driven format & advancements

Right now titles are mostly supported by the API, with the data pack seemingly something of an afterthought - not supporting translation keys (and thus genders). It'd be better if the mod used a format more like the actual Minecraft data packs, which would also give space for more rich metadata associated with titles to support i.e. different name relations (prefix/suffix positions, above/below positions), localization, etc. In line with this, it makes sense to have titles driven purely by advancements, as they're robustly supported by data pack modding already, and if modders want to create custom conditions for when titles are granted or control granting specifically from code, they can create custom triggers and conditions for advancements or grant/revoke advancements from the vanilla/forge-supported advancements API.

I'm thinking of something to the effect of:

data/custom/titles/example.json:

{
    "advancement": "minecraft:adventure/root",
    "rarity": "common",
    "variants": {
        "default": {
            "translate": "titles.custom.example.neutral",
            "position": "prefix"
        },
        "male": {
            "translate": "titles.custom.example.male"
        },
        "female": {
            "translate": "titles.custom.example.female"
        }
    }
}

assets/custom/lang/en_us.json:

{
    "titles.custom.example.neutral": "there they are! it's ",
    "titles.custom.example.male": "there he is! it's ",
    "titles.custom.example.female": "there she is! it's "
}

Concerns/clarifications:

If one wanted to refer to this title ingame, they'd use a resource location custom:example to refer to this title, for commands or other purposes. A title defined by a mod might be at the datapack location of data/tetra/titles/hammerer.json instead, and thus have the resource location tetra:hammerer. Similarly, if it's in a folder it should follow the normal Minecraft conventions (data/custom/titles/sub/directory/title.json -> custom:sub/directory/title)
If you prefer not to use translation keys, you should be able to use text as the key instead of translate and write directly, which is in line with the Minecraft vanilla raw JSON text components (though a full implementation of them is both overkill and not applicable for titles).
Position can be one of "prefix", "suffix", "above", "below" - I don't think it makes sense to allow players to have multiple titles active at once, or perhaps only one prefix/suffix and one above/below title simultaneously?
Where a key for the player's chosen gender doesn't exist, the "default" key should be used instead; where a key on the object for the player's chosen gender doesn't exist (such as variants.female.position) use that value from the default variant - so in the above example, if the player has their own gender set to female, it will use the position key from the default variant, i.e. all variants here use the same position but don't actually have to
If the advancement is revoked for any reason, the title should also be revoked from the player and removed if it was currently active (I have created mutually-exclusive advancements, one which has the criteria of not having the other and which is revoked by achieving the other - frankly a ridiculous idea but something to consider)
Might it be appropriate to allow for a title to require multiple advancements, i.e. use an array of advancements? Grant the title when you gain one of its requisite advancements and have every requirement, lose title when you have a required advancement revoked

This would bring the data pack support up to being a first-class implementation, and possibly even obsolete the need for the API entirely - allowing mod authors to easily and harmlessly include these data files to add support, without having Titles or its API as an actual dependency, by tying granting/revoking of titles to the vanilla advancements system. Moreover, this would allow modpack authors to trivially remove the example titles added by the mod and control exactly what is included in their overall pack - since they could simply use OpenLoader or similar to put blank files in place of the existing titles.

Wow! Ok, you've put a lot of thought into this and I greatly appreciate such a detailed response! Making Titles as data driven as possible is a goal of mine, and there are some really good ideas here (such as having some titles require multiple advancements). As for the others, let me explain:

The lacking API and data pack support, while true, are just because this is the first time I've worked on such things. I could move most of the functions available through the API to data packs, but there would still need to be a minimum API for a few things such as getting a list of all available titles.
Making Titles exclusively advancement based would remove its use in quest mods and modpacks. The purpose of loot titles in particular is for owners to add miscellaneous titles that aren't available as a quest or advancement reward, but would still be enjoyed in-game.
Making the title display as a prefix was something I had considered early on. However, it would cause confusion in the chat window for example, if more than one player were using the same title as a prefix. Seeing a player's name first is easier and faster to process.
Having a player's title render below their name is something I am working on. Unfortunately, as with the API and data pack, it (rendering) is something I have little experience with, so it is taking a while.
Removing a title in response to its advancement being revoked is something I've wanted to do as well. However, there is currently no event in Forge that is triggered in response to that.
There is some trickiness about Titles and translation keys. Its not that I don't want to use translation keys, just not all titles use them, specifically loot and command-only titles.

Aurilux / Titles

Titles should use fully data-driven format & advancements #24