Add Language Support

[ikabod-kee]

Allow the blocks to have full names rather than displaying the internal names.

Example:

baobab_log.zig.zon

english.zig.zon

In-game display:

[IntegratedQuantum]

This is something that I would prefer to push as far into the future as possible. Supporting multiple languages is a lot of maintenance work and makes adding new things or changing things a lot more difficult. I just don't want to deal with 100 PRs each release fixing all the different languages for newly added blocks.

[ikabod-kee]

I was thinking english would be the default language and other languages could be added via add-ons and maintained by the community

[IntegratedQuantum]

Hmm, yeah that is a nice idea.

[H41ogen]

I kinda want to work on this but i feel like the review cycles would be enough to kill eight elephants

[H41ogen]

would it be useful to also have aliases for use in commands? like cubyz:ocean/temperate/base being able to also be written as cubyz:temperate_ocean or cubyz:ocean/temperate? i'm not sure, but it would allow easier use for non-english speakers if they have the addon that supports their language.

[IntegratedQuantum]

I kinda want to work on this but i feel like the review cycles would be enough to kill eight elephants

Well, that is to be expected from fixing something with outstanding design decision. But if you figure out and discuss the design ideas first then it won't be too bad.

would it be useful to also have aliases for use in commands?

Yesn't. The text should always be the same, but it might be helpful if autocomplete (which doesn't even exist yet) reacts to the language specific names. Either way: Very low priority

[Argmaster]

(which doesn't even exist yet)

Because of the eight elephants.

[H41ogen]

Example:

baobab_log.zig.zon

english.zig.zon

would this even work? are you allowed to use colons in zon fields? if so, could it be better to just have the block's current id (which can include slashes) as the field instead, so we don't have to add extra lines to every block/item file?

[IntegratedQuantum]

are you allowed to use colons in zon fields?

Yes with @"" It could also be resolved with a hierarchical approach, each addon could get a file, and each folder could get an additional layer of nesting in the file .log = .{.baobab = ..., .oak = ..., ...},

could it be better to just have the block's current id (which can include slashes) as the field instead, so we don't have to add extra lines to every block/item file?

Yes I think that would be simpler. Though I wonder if @ikabod-kee had a reason for doing it like this?

If it's about aliasing between different types (e.g. item and biome names), then that could be resolved by grouping them together like so:

.{
	.@"cubyz:log/baobab" = .{
		.itemName = "Baobab",
		.itemDescription = "whatever",
		.biomeName = "Baobab log fields idk",
	},
}

[Argmaster]

What about not having complicated logic behind translation. We just keep strings in english and provide english to x dictionaries. In code, translatable strings go through additional lookup step by indexing into a huge table.

.{
	.name = "Baobab log",
	.description = "Can be placed",
	...
}

polish.zig

.{
	.@"Baobab log" = "Kłoda baobabu",
	.@"Can be placed" = "Można umieścić",
	...
}

[IntegratedQuantum]

Such a simple system will fall apart as soon as there are any homograph, such as e.g. bat. Furthermore it would make it a lot easier for third party translation efforts if the english translation files as present in the base game can be used as a template.

[Argmaster]

Homograph issues can be addressed by as little as an arbitrary ID to X translation. Still in most cases we can just use English words, but we can disambiguate in locally appropriate way.

[SpellDigger]

wouldnt a explicit translation file be the best? no matter how hardly we would try we are translating the game to a completly new language here, languages are different especially compared to english and having things explicit just seems as the simplest and easiest solution here

english.zig.zon

probably not the best example and it could be grouped better but no matter how hard u argue having things explicit is the simplest solution

for getting a text for something we could write a language module

lang.translatedGame("ui", "buttonMultiplayer"): []u8 (everything fallbacks to "unknown" if not found for convenience) lang.translatedTag(.metal) : ?[]u8 lang.translatedProperty(.dry): ?[]u8 lang.translatedItem("cubyz:iron_ore"): ?[]u8

probably no the best example ever but the idea is here probably...

[Wunka]

I would then say we just split the hierarchy at the top into two parts game and assets. For assets I would then go by a fusion out of the hierarchical approach and the id approach. Which would mean you have two options:

.assets = .{
	.@"cubyz:log/baobab" = .{
		.itemName = "Baobab",
		.itemDescription = "can be placed",
	},
}

or

.assets = .{
	.@"cubyz:log" = .{
		.itemDecription = "can be placed"
		.baobab" = .{
			.itemName = "Baobab",
		},
	},
}

That way you can go log by log or you can place defaults. Copying for other languages would maybe involve some changes in the hierarchy but it would still be as simple system.

lang.translatedGame("ui", "buttonMultiplayer"): []u8 (everything fallbacks to "unknown" if not found for convenience)

Here I would say first we fallback to english and then to unknown. There should also probably be maybe a warning in the logs when a translation is not found for better testing of languages.

[codemob-dev]

Why do we even need cubyz:? The language files should be separate per mod.

[Argmaster]

Language files should allow cascading to allow extending incomplete translations.

[LinaPlusPlus]

Why do we even need cubyz:? The language files should be separate per mod.

we could detect the lack of a : in the item name and auto prepend a modname: to the beginning so the key .log = ... expands to the equivalent zon .@"cubyz:log" = ...