Paper
Paper copied to clipboard
PaperMC
Support changeable/loadable locales
Is your feature request related to a problem? Please describe. ItemMeta#getLocalizedName() is always the english version.
Describe the solution you'd like It would be good to have a convenient way of setting the server locale for this.
Describe alternatives you've considered Using Translatable Message Components should work.
Additional context @Phoenix616 has suggested creating this issue and has the background knowledge for this topic.
My knowledge here is that the LocaleLanguage just loads the en_us.json file from the server. As far as I can tell nothing would stop one from patching that to allow loading other language files from the server folder (maybe a dedicated languages one or via a config option/startup argument?) Currently one would have to modify the file in the server jar directly which is inconvinient.
Ideally such an addition would need to fallback to the existing json for non-existing keys to not break on updates when new keys are added.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
There should be a startup flag so it doesn't download/patch on every server load.
@promorrom I'm unsure how this relates to the server locale? Was this commented on the wrong issue or am I just not understanding what you mean by that?
If you edit the server locale (inside the jar), it will download a new jar so you did waste your time and issue is still present. Billy said this is due to "paper's new paperclip system".
paperclip has always patched modified jars, that's literally nothing new and has been the case for years
The difference in the past was that paperclip produced a singular jar which you could tweak and run standalone, that changed when mojang also stopped producing standalone jars, meaning that you can no loner just patch and run the standalone thing.
modifying the jar as a solution basically makes 0 sense, really the thing should just look on the disk or something for the file rather than tryna use a backwards ass solution, but, that API is deprecated in favor of client side translations, but, given mojang refuses to do this and the locales are used for some stuff, if somebody wants to look at dynamically loading that stuff off mojangs API or letting people just place the locales file somewhere, I'd be open for that
I started working on a PR for adding vanilla language keys from Mojang's asset API to adventure's GlobalTranslator for this issue recently, but I have to ask, is this still necessary? With the addition of support for adventure components nearly everywhere, I can't think of any text that's sent to the client as a raw string to necessitate this feature. Only one I could think of was scoreboard players, but machine maker pointed out a clever workaround of creating teams for invisible player names with prefixes set to translatable components. Does anyone have a good use case for this that's not covered by adventure components? Don't want to put a ton of work into something that'll get rejected for being deprecated/unsupported/whatever :P
I think what was brought up is outside of mc usage, IE resolving translatable components to plain text so that they can be displayed on discord
Ooh yeah, would be nice for those Minecraft <-> Discord chat plugins. Ok, I'll keep working on it 🙂
That seems like such a niche usecase, that it can be done by those plugins themselves right? Why do any changes to the paper server have to happen for that?
Well, depending on how it's implemented, this could also allow server owners to change the language of translatable components in their server log files, which alone seems pretty worth it to me as that's not something that can be easily done by a plugin.
Regarding the Discord chat use case, sure plugin developers can technically implement their own component flatteners for this, but that's a bit of a tall ask tbf
The server has no access to languages besides English (US); this is a feature request to allow the server and plugins to fetch other languages somehow (either via local file path or via Mojang's asset API)
Ok so this request wants getLocalizedName() to do the same as displayName() and cast it to a TranslatableComponent?
My usecase for this would be holograms/nametags. those can't use translatables. I ended up just ripping the translation files from the client & adding them to my plugin, but that really isn't an optimal solution.
My usecase for this would be holograms/nametags. those can't use translatables.
I tested in single player and was able to get armor stands to use translatable components for display names o.o
EDIT: /summon armor_stand ~ ~ ~ {CustomNameVisible:1b,CustomName:'{"translate":"block.minecraft.dirt","color":"green","bold":true}'}
AFAIK, the only place you can't use translatable (or components) is scoreboard entries, or game profile names, but you can do everything you want there with team prefixes/suffixes or armor stands for custom name tags.
Changing the server's locale would allow the log to be in a different language, but that still seems really unneeded, and I think that is the only possible reason Paper would want to add this functionality.
Yeah it seems like I was wrong there and that was fixed/changed. I was doing it in 1.16, and the client just displayed the translation key instead of the translation. But yeah, if that works now I also don't know any other place that doesn't support translatables.