-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support in ChatComponent API for fetching translation strings on server side #3692
Comments
It's not API, but this is what TranslationRegistry.translate does |
Oh you want Bungee to download every translation from Mojang.... |
Ah, well not exactly. Not from Mojang, but from the resource pack. The use case would be being able to add your own localizations and then asking the ChatComponent API - not for a key - but for the actual localized string on the server side. So that the localized string could then be passed on to any third party plugin which requires input. For normal chat messages you obviously don't need it because it's already supported. But one use case example could be something like a tool tip plugin, for example. So, situations where it's simply too time consuming and impractical to implement support for getting the strings from the resource pack. Instead, you would say: "Please sir, could you give me the text for my.custom.translation in Spanish, please?" And the API would be like "Aquí tienes mi buen hombre. Un placer hacer negocios con usted." If you want to do this now your pretty much only option is to hard code and support the translations yourself in code or build a whole system for them. All reducing the value and practicality of using the ChatComponent API in the first place. |
You can't get the translations from an texturepack |
I meant the server's own resource pack. If you're writing custom code for your server which requires localizations, you definitely would have access to that. So it would really only be a matter of defining where the localization files are and fetching the translations from there. But I understand it's not a simple problem to come up with a clean implementation. |
The methods I describe above already get the translations from the server. But if you are adding custom translations then I'm not sure why looking them up is something bungee needs to do |
I don't even use Bungee. I use Spigot which uses the ChatComponent API. I was just told to open a ticket here. And I have no idea what methods you're referring to. I tried to Google it, but couldn't find anything definitive. I was told getting the translations is not possible using Spigot. Perhaps I was misinformed. |
I referred to the methods in my comments above |
Feature description
Greetings.
This is probably not going to be a popular and easy as 1, 2, 3 suggestion. But here goes.
Chat Component API currently has a bunch of methods for fetching the translation key for
TranslatableComponent
- and the translation itself is handled by the client from resource pack.That's all fine for messages and such which have support directly in the server software.
But I sometimes find myself in situations where I'm dealing with a third party plugin which requires string input. My only option here with localizations is to try to manage it myself by hard coding the strings and trying to juggle localizations - or to use some third party software which bypasses the issue simply by not using TranslatableComponents.
Solution?
It would be very nice to be able to get, not the translation key, but the actual translation text on the server side from the resource pack based on the locale on the client.
Now, there are probably a ton of problems with that. Like, does the client even tell the server what locale they are using? They might not for all I know.
And then there's the issue of getting access to the resource pack on the server side and processing through the language localization files and all the different ways a resource pack may work, be located or hosted.
I guess a good starting point would be determining whether it is technically possible to begin with.
It would be a very nice feature.
I'm not super optimistic about this suggestion, but I thought I'd throw it out there.
Goal of the feature
Get translation strings on server side.
Unfitting alternatives
Third party localization addons.
Checking
The text was updated successfully, but these errors were encountered: