Use client-side translation strings

[YouHaveTrouble]

Current dictionary system has you choose 1 language to use for the items.

I propose using resource pack .lang files and item.getItemMeta().setLocalizedName("path.from.lang.file") to allow automatic translations for all custom items, fully client side.

You can literally just copy over dictionary entries to the json file, seems easy enough to do. If you worry about losing compatibility how about making it a optional config setting where you would put "auto" instead of language code in config?

[LoneDev6]

I just found out a big disadvantage of client translations. Basically you can't use JSON in there. You're limited to the old color logic using § character.

This makes using HEX colors impossible, people will surely complain about this limitation.

[YouHaveTrouble]

Yeah, this is a very old issue. I would suggest testing adventure translatable system that supposedly can swap sent components on packet level to insert translations based on client language

[Andre601]

This makes using HEX colors impossible, people will surely complain about this limitation.

Then you can just forward the following message to them: Send this complain to Mojang, as they made that system.

[LoneDev6]

sent components on packet level to insert translations based on client language

This is an idea I had to maintain a lot of other data change (durability lore and other stuff too) but I'd avoid having to intercept ALL packets related to items to change them each time. I think it's a bit overkill.

First idea

An idea is to provide a way to allow itemsadder to use the Mojang automatic clientside translations, then also allow the old "permanent" text method too for some particular names. But I think it will cause a lot of confusion.

Note: I know only a few little servers who have multi-language users. Most of the communities out there have a single-language experience so I don't really see an advantage of introducing this kind of feature other than confusion.

Second idea

Another approach which is the cleanest to me: Basically add a new per-item property client_translation_display which translates name and lore lines applying the new logic which has the already explained limitations. Some people already are doing it manually using the inject NBT property: https://github.com/PluginBugs/Issues-ItemsAdder/issues/2243 nbt: "{display:{Name:'{\"italic\":false,\"translate\":\"item.testserv.transparent_test\"}'}}" This idea gives full freedom to the admin to decide which item can be translated automatically by the client using the (limited) Mojang way and which not.

Second idea bonus

Client translations support "args". For example the vanilla durability translation is like that: "item.durability": "Durability xx: %s / %s",. This supports replacing %s with an argument or multiple arguments if more %s are specified. So I think something like that must be better to be implemented:

items:
  my_item:
    display_name: # Will allow more properties other than plan text.
      component_translate: 
        key: "custom.translation.entry"
        args: # Optional property
         - "{player}"
         - "%vault_eco_balance%"
minecraft_lang_overwrite: # Already implemented
  change_me:
    enabled: true
    entries:
      "custom.translation.entry": "Custom Translation~ Player: %s Money: %s"

(args would support PlaceholderAPI and some internal ItemsAdder placeholders like {player})

[Abwasserrohr]

I think another option would be to implement translatable texts like text effects or how hex colors are implemented.

Usage example

The translatable placeholder could inherit all the effects like usual text too, this could work with both Spigot TextComponents and Adventure Components, I think:

%#FE5A00%%tr item.testserv.hello% %#0ad111%%tr item.testserv.world%
converts into: [{"translate":"item.testserv.hello","color":"#FE5A00"},{"text":" "},{"translate":"item.testserv.world","color":"#0ad111"}]

tr = translatable

[LoneDev6]

Itemsadder already offers a translation system but it's not clientside. https://itemsadder.devs.beer/plugin-usage/adding-content/translation

We were discussing about implementing compatibility for Minecraft built-in clientside translation feature, but it lacks some features.

[Andre601]

We were discussing about implementing compatibility for Minecraft built-in clientside translation feature, but it lacks some features.

I feel like client-side translations should be implemented, even if there are downsides. From what I recall were downsides that (hex) colouring wasn't doable? Because if it was only that would it imo be a minimal loss for the greater good here (Also, has anyone tried that ugly §x§1§2§3§a§b§c pattern to see if that would work?).

[LoneDev6]

The suggested placeholder doesn't work.

Tested with "options.skinCustomisation": "§x§F§F§F§F§F§ESkin Customization...", and (without §x) "options.skinCustomisation": "§F§F§F§F§F§ESkin Customization...", and doesn't work sadly. It seems to set it as the nearest valid color in the Minecraft classic § chat colors.

References: https://gaming.stackexchange.com/questions/372708/how-do-you-use-minecraft-1-16s-hex-color-codes-in-a-lang-file-for-resourcepacks#comment523798_372753 https://bugs.mojang.com/browse/MC-195666 https://feedback.minecraft.net/hc/en-us/community/posts/360071740551-Add-Color-Code-for-Hex-Colors

[LoneDev6]

Added a new section "Second idea bonus" https://github.com/PluginBugs/Issues-ItemsAdder/issues/591#issuecomment-1397752189

Let me know what you think