Advancement translations broken when advancement id differs from json title
DaFuqs opened this issue ยท 4 comments
Describe the bug
When hovering over an entry that is unlocked via advancement, sometimes the advancement titles fail to translate.
The translation seems to break when an advancements id differs from the title / the title localisation string not matching the advancements id.
To reproduce:
This can for example be reporoduced by putting the advancement into a subfolder.
For this example we will name the advancement spectrum:midgame/collect_neolith
in the midgame
subfolder.
The json of the advancement looks as follows:
{
"parent": "spectrum:midgame/craft_bottle_of_failing",
"display": {
"icon": {
"item": "spectrum:neolith"
},
"title": {
"translate": "advancements.spectrum.collect_neolith.title"
},
"description": {
"translate": "advancements.spectrum.collect_neolith.description"
}
},
[...]
Create a book entry with the following condition:
"condition": {
"type": "modonomicon:advancement",
"advancement_id": "spectrum:midgame/collect_neolith"
},
When hovering the advancement, a raw translation string is shown.
That string does not match the title
we set in the advancement above.
Despite the title
of the advancement being set to advancements.spectrum.collect_neolith.title
, modonimicon wants to resolve the advancements translation string including the subfolder midgame
:
Expected behavior
The tooltip being listed with the correct advancement title.
For this, the title
text of the advancement should be used.
Screenshots
A working advancement that is placed directly in spectrum/advancements/ without a subfolder for reference.
The translations works perfectly fine.
System (please complete the following information):
- Modonomicon Version: 1.62.0; Fabric
- OS: Windows
- Minecraft Version: 1.20.1
- Modpack Link and Version, or list of mods: Just Modonomicon & Spectrum
I have to investigate this because I think there was a reason why we didn't query the translation id from the advancement and instead "built" it ourselves (someone even improved that a while ago).
But I agree if possible we should just query the real one
Ah it seems advancements are only sent to the client once they are visible, otherwise they are simply not available.
I'll have to check how to work around that
Ok this was a bit of an odyssey but I think I got a working solution.
Had to manually sync the relevant advancements and cache them locally without using the vanilla advancement management, as that is allergic to not yet unlocked/visible advancements if their parents are also locked still
Closed in #192