I wrote something like that:

       source.sendFeedback(new TranslatableText("as.command.show_item",
                new TranslatableText(item.getTranslationKey()),
                itemsHelper.getCurrentCount(item),
                itemsHelper.getDefaultCount(item)), false);

But since the server doesn't have localization, it only prints translation key...

However, I found that those vanilla command like /give does use translatableText... Not sure how it works.

Recent Fabric versions now load en_us.json lang files on the server.

Anyway, it would be great if Fabric has an API or something that allows loading mods' lang file.

SSTranslatableText is for sending text to clients (where the server has the localization, but the client may not have the mod/resource pack)

If the client does not have the mod installed, then it shouldn't be translating text to begin with. Translating the text on the server is a hack and should not be a part of the fabric API. The server doesn't know how the client can handle translatable texts, if it can't then the server shouldn't be trying to guess how the client wants the text to be translated, and otherwise, the vanilla system is already good enough.

it would be great if Fabric has an API or something that allows loading mods' lang file.

There could probably just be a FabricTranslationRegistry.registerServerTranslation(new Identifier("my_mod")) to opt-in to having your TranslatableText function correctly on a dedicated server (using .minecraft/mods/${my_mod}.jar/assets/lang/en_us.json), or perhaps it could even be enabled by default, I can't think of any problems with that. In that case, there might not even need to be an API at all.

If the client does not have the mod installed, then it shouldn't be translating text to begin with. Translating the text on the server is a hack and should not be a part of the fabric API. The server doesn't know how the client can handle translatable texts, if it can't then the server shouldn't be trying to guess how the client wants the text to be translated, and otherwise, the vanilla system is already good enough.

SSTranslatableText is for mods that know they will not be installed on the client. For mods that KNOW that they need to translate on the server in order for the client to see anything useful. Look at Bukkit plugins like Essentials - they cannot send translatable texts to the client because the client will just see the translation keys. So they translate on the server, and allow the server owner to pick the language.

That said, I think the server should correctly translate modded text sent to console.

SSTranslatableText is for mods that know they will not be installed on the client

That would be a good use for that library, but for the issue discussed here it would be a hacky non-proper fix.

I think there is a reason here to implement the logic in order to load modded translations on the dedicated server.

I agree with this statement, although evidently it is worded in a confusing way, there should definitely be some built-in way to load the "en_us.json" translation resource file for mods even when on a Dedicated Server, however, there does not need to be an API built-in to fabric for translating text before sending it to the client, for something like that an external library like fabric-languagehack would be sufficient.

there should definitely be some built-in way to load the "en_us.json" translation resource file for mods even when on a Dedicated Server
yeah, but I just couldn't find an easy way to do that.

I think the server only understands English, but I am not too sure why the server is not translating text if you did have a lang file.

Yeah, I have an en_us.json.

I think I see the issue. On the server language is set by the bootstrap process, however fabric mods are loaded just after the translation checks. Fixing this global would require moving the mod entrypoint which is already on the literal edge of how far we can move forward.

If you want a hack to fix it, I would use Language#create and then set the instance field on language after your mod has finished loading. Calling the method and setting the field would require an accessor mixin.

EDIT: Ignore what I just said, it's all wrong

Okay what actually the issue is, so Minecraft when loading translations on the server only ever loads the lang file for Minecraft itself. No modded language files are loaded during this process on the server.

However the client uses TranslationStorage in order to instantiate the modded lang files, which are actually defined by loaded resource packs.

I think there is a reason here to implement the logic in order to load modded translations on the dedicated server.

@i509VCB This already exists: https://github.com/LoganDark/fabric-languagehack

@LoganDark That seems to require a subclass of TranslatableText (SSTranslatableText), unless I misunderstood.

@haykam821 SSTranslatableText is for sending text to clients (where the server has the localization, but the client may not have the mod/resource pack), and it only works because LanguageHack also loads localizations from all installed mods

@LoganDark At that point, why not embed it within TranslatableText itself? It seems a bit silly for a 3rd-party library to require explicit compatibility like that.

@haykam821 Because that would not allow the client to translate vanilla text which it already has resources for, it would take away the choice to use a different language! Even though other mods using SSTranslatableText will always obey the server's language (always en_us for now, but LanguageHack might add a choice eventually), it's not meant to replace all TranslatableText. Also it affects all serialization, not just over the network, so all TranslatableTexts would turn into LiteralTexts when saved to a file / etc. That's not expected behavior unless you opt into it by using SSTranslatableText

To clarify, LanguageHack's purpose is not to force all clients to see a particular language, it's to enable the server console to see localizations added by other mods. The fact that it includes SSTranslatableText allows mods to depend on it in order to localize their text but still allow clients without the mod to read it, and once LanguageHack has language choice, it will be a useful tool for server owners to switch the language of their server console & server-side only mods with compatibility

@LoganDark The server already has access to the vanilla lang files with the mod, so why not send TranslatableTexts to the client only if their translation key was not found in the vanilla lang files?

@i509VCB This already exists: https://github.com/LoganDark/fabric-languagehack

Love your mod!