Stairs mod does not support translation of Inner and Outer Stairs
TheOnlyJoeEnderman opened this issue · 12 comments
The English words Inner and Outer are hard-coded into the stairs mod. When the language is switched, these words are always in the same place, and always in English. I believe this is unintended behavior. Attempting to add the proper translation keys for Inner and Outer variants even crashes the game.
This is an example of code that should work but will instead crash the game:
S("Example Stair"),
S("Inner Example Stair"),
S("Outer Example Stair"),
S("Example Slab"),
This example is the only current way stairs mod accepts:
S("Example Stair"),
S("Example Slab"),
I had to use 5.3 because there is no later Debian port that supports language switching.
The culprits:
minetest_game/mods/stairs/init.lua
Line 355 in 9e77e00
minetest_game/mods/stairs/init.lua
Line 447 in 9e77e00
This is in the public API. There is a full_description
parameter documented as being useful for translation and avoiding string concatenation, which the code seems to implement correctly. The blocks you're showing seem to originate from other mods, which probably fail to utilize the API properly (arguably the API is a footgun). The stairs.register_stair_and_slab
which calls these has the same footgun.
My wild guess for the crash: It may be nesting translation strings.
The API is indeed bad but it had to be this way to preserve backwards compatibility.
It is possible to register correctly translated stairs and slabs:
stairs.register_stair_and_slab("foo", "my:foo_item", groups, {"foo.png"},
S("Foo Stair"), S("Foo Slab"), sounds, false,
S("Inner Foo Stair"), S("Outer Foo Stair")
)
I had to use 5.3 because there is no later Debian port that supports language switching.
We can't support software that is 3 years old.
@TheOnlyJoeEnderman please point out the offending mod so that a PR with fixes can be submitted. Closing this as it's not a MTG issue.
Don't worry, I am the dev of the mod in question, I will see if I can implement a fix. Thanks for the answers.
We can't support software that is 3 years old.
I am not expecting you to. I just couldn't verify my translations worked on the 5.7 Flatpak, and had to boot up my mod in 5.3 to see my translations at all.
After applying said fix, I still cannot get translations working.
too_many_stones.zip
Thank you for checking. Do you know if it is faster in game to register the code as I have done, or to use loops? My mod was made a little bit at a time. If I kmew it would be all at once, I would have created functions to register all blocks automatically.
Not that it would matter at all performance-wise, but I would expect larger files to have worse performance overall (that is, I would expect using loops or functions to marginally reduce the load time since it "compresses" the sources at an even more negligible difference to load time execution speed). Loading the file from disk and executing it takes time.
The only significant factor here is code quality, and redundant code will it make much harder for you to maintain.
Maybe, but unless there are major API changes, the mod is nearly finished. It will be so little added in future it won't be worth the major code rewrite. I guess unless I want to make it into an API that anyone can instantly add all the stone types. But that is not a current goal.