Minecraftforge: Enhanced language loading does not support colons in unlocalized names

Created on 13 Oct 2017  路  7Comments  路  Source: MinecraftForge/MinecraftForge

A lot of mods use un-localized names that look something like this
tile.draconicevolution:draconium_ore_normal.name=Draconium Ore
With modid: as part of the name to avoid any possible conflicts with other mods.
This works fine with vanilla's language loading but forge uses java Properties to pars the lang file instead of the regex minecraft uses.
This completely breaks when you introduce colon's because java Properties also use colon's to as well as = to define the split between a key and value.

Stale

Most helpful comment

I am going to mention that mods can easily just use a period instead of a colon there, like how Tinkers items follow the form of item.tconstruct.slime_boots.name, so I would argue it is a break of convention to use a colon even if it "works" (like camel case item and block IDs before that was disallowed).

Using vanilla-like naming is always safer in case it is changed to only support that style.

All 7 comments

I am going to mention that mods can easily just use a period instead of a colon there, like how Tinkers items follow the form of item.tconstruct.slime_boots.name, so I would argue it is a break of convention to use a colon even if it "works" (like camel case item and block IDs before that was disallowed).

Using vanilla-like naming is always safer in case it is changed to only support that style.

It is safer to use a period rather than a colon, but significantly easier to use the ResourceLocation (i.e. a colon).
As forge behaves differently to vanilla I believe this should be classed as a bug.

Considering the relative complexity of the Java properties format and the fact that it has to be explicitly enabled for lang files, I don't think this is to be considered a bug. Others who use properties parsing might in fact rely on the colon as a separator, so keeping backwards compatibility is hard (bar introducing versioning to the PARSE_ESCAPES comment).
The complexity of the format comes into play when you do try to "fix" this, since the entire parser would have to be reproduced in Forge, which obviously incurs the burden of maintenance.
As a matter of fact, this doesn't require any effort on Forge's side, as the properties format supports escaping the separator in keys with a backslash (i.e. \:).

Vanilla 's parser is actually very simple. I don't think it would take much work to implement it in forge. Also I have not tested this so it may not be an issue but I noticed vanilla has special handling for things like death message formatting and as far as I could tell forge does not.

Forge doesn't change the parsing at all unless you specifically request the properties syntax with the PARSE_ESCAPES comment. See https://github.com/MinecraftForge/MinecraftForge/blob/f2adf0100c016213ed7d570db56420c7685637db/src/main/java/net/minecraftforge/fml/common/FMLCommonHandler.java#L716

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.

Was this page helpful?
0 / 5 - 0 ratings