Closed immibis closed 10 years ago
Indeed. Will deprecate for removal in 1.7..
"But there is not a reliable way to inject multiple languages into the server at the minute. I'm thinking about this."
What do servers use language data for?
Well, LP uses a language-hack to be able to provide names of items to computercraft.
Localization shouldn't be done on the server, the client will always show things in the same locale as the server which seems counter productive (could simply hardcode the names into a String
class).
Example: the dirtchest9000 guide book. It is generated on the server, not the client..
What currently loads the .lang files on the server?
@Lunatrius get the client locale when it's connecting to the server, remember which clients are in which languages, then send over the correct String from the locale files.
@luacs1998 why on earth would you do that? Just send the unlocalized string you want to display and let the client translate it. That saves you from all the hassle of patching Minecraft to load multiple languages at one, etc.
@diesieben07 What about server-only mods?
@HoBoS-TaCo ChatMessageComponent.createFromTranslationKey
or in 1.7: new ChatComponentTranslation(...)
What @luacs1998 said seems like unnecessary work. ChatComponentTranslation won't work with server only mods though. The client has no way of knowing what the translation keys are mapped to, unless you actually use a resource pack for the translations.
I'm more than aware of that hence my proposed solution. Either that or transmit the langs to the client on first login ( which is worse). If the client doesn't know what to display, you tell the client. Simple.
Perhaps things that are not translated should not use the translation system. In the case of a server-only mod, send a ChatComponentText with your message (in some default language which is probably en_US)
Using translations on the server seems like an abuse of the translation system.
Not if you need to perform operations server side on the names
It just made click in my head when I remembered about AE.
@GUIpsp: What sort of operations?
@Lunatrius: AE shouldn't need access to translated names on the server anywhere - it can send the client the untranslated names - but I can see how it would be helpful to save bandwidth, as without it, the entire list of items has to be sent to the client when you open an access terminal.
Yes, I think that I'll keep the language loading in the server. I'll probably get the client to send its localization setting to the server, so mods can use it..
I think that I'll try and make I18n available on the server somehow, or something..
There's a vanilla bug report about one of the few spots that still looks up translations by default on the server (death messages): MC-25187
Really the server should not be relying on translated names anywhere, but even Mojang hasn't gotten that right yet.
The problem is things like the dirtchest book, ae filtering. You can't sensibly make them work as intended with only client side translation.. I think making the localisation of the client available at the server so mods that want to get translated names, can, is the best solution..
Because we already have 1.7..
Is Forge/FML stable for 1.7 now?
Also if the server is going to be hardcoded to en_US, why bother with translations instead of just hardcoding strings? Never mind, misread that part of the code, sorry.
I think its/mostly stable yes.
It's not the recommended download, so I assumed it was still not officially stable. Okay.
Forge is stable, the only thing a RB is waiting on is King to get time to finish liquids. Everything else is good to go.
7c5d62704ac1d3e586f3bfe26265a534e5362c73 ?
Closing, it will be required to have the language registry in some form for the foreseeable future.
Okay. The now-deprecated methods can still be removed though?
Now that mods can easily include their own language files, and automatically support multiple languages if the user has a language pack supporting them, LanguageRegistry isn't necessary. Perhaps consider deprecating it?