Replies: 22 comments
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Stale who? Stale you! Zim-zalabim, unstale! ✨✨ |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
It's not stale, it's a feature request... |
Beta Was this translation helpful? Give feedback.
-
There should be a startup flag so it doesn't download/patch on every server load. |
Beta Was this translation helpful? Give feedback.
-
@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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Ooh yeah, would be nice for those Minecraft <-> Discord chat plugins. Ok, I'll keep working on it 🙂 |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Can someone do a catch up in what the actual problem is? |
Beta Was this translation helpful? Give feedback.
-
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) |
Beta Was this translation helpful? Give feedback.
-
Ok so this request wants getLocalizedName() to do the same as displayName() and cast it to a TranslatableComponent? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I tested in single player and was able to get armor stands to use translatable components for display names o.o EDIT: |
Beta Was this translation helpful? Give feedback.
-
Seems like a valid usecase to me. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions