What is the best, cleanest way to create translatable texts?
For instance, if I wanted to have translatable command arguments, It needs a Text object, I can use inbuilt Minecraft translations, but how would I provide a custom translation for my plugin?
This is already something being worked on being implemented in sponge. See here for the pull request. As for currently how I would probably do it is create a languages folder in your plugins config directory with text files for each language with keys containing a translated value to that key, similar to what mods do. You could then have a config option for which language to use and add a method to your plugin for translating using said keys.
I don’t think that PR necessarily describes or solves the problem that I’m talking about. Yes it handles translations, but at a layer other then the already existing translation texts for Minecraft, It will have the same problems that TextTemplates have vs the PlaceHolders that were originally proposed.
The API would feel more unified if Text knew how to localize itself when sent to sources that have a localization set.
In my opinion translatable text needs to have two properties to “work”.
If you have Player1 and Player2 on the server at the same time, and they both use the same command, the Text they receive back should be translated based on their locale. This should hold true for all Text.
It should be easy to add another language, or modify an existing one. No, Text and TextTemplate are not easy IMO. This is the approach I went with for HomeSweetHome and ChatEditor, and it works horrible. Why? For ChatEditor, the config file is 500 lines long. For HomeSweetHome it’s even bigger. Most people just don’t want to edit 500 lines to edit 50 messages to localize stuff. They want to edit 50.
I’m definitively with @ryantheleach With this one. Localization should be easy for both the developer, and the user. It needs to work much like minecraft translatable text from the developers point of view.
@Katrix for what it’s worth, Pex uses translatable in it’s command system in place of text, which is largely what sponges commandspecs were based on.
I’m not sure if this was already in when sponges commandspecs were crafted, or if they were left out intentionally as future stuff while it was considered how to proceed, or if it was expected that Text have a serverside translation implementation as well.
Edit: If translations end up being a Function<TextReader,Text> (where TextReaders locale could be determined, or defaulted) it would also pave the way for a lazily computed placeholder, akin to the original proposal that was turned down, which would enable per receiver formatting in a way that doesn’t conflict with message channel transformers, which seem to be more suited for formatting channels, rather then per viewer display.
Another potential idea,
In order to appease people who prefer to work in code, would it be appropriate to include another annotation processor, that could execute code found in a particular annotated class, and generate the default language files from that?
e.g. in your main plugin, could we do something like,
Plugin{
@Inject TranslationSources t;
void doStuff(Player p){
p.sendMessage(T.teleporthome.fill("ryanshouse"));
}
}
import static sponge.Translate.translate
@Translations
public class T {
//at compile time translate() is used to collect and process translations,
//at run time translate() is used to fetch translation objects from the default file in the jar, possibly overridden by a file in a serverside lang directory, only problem I see is classloading / code running at static initialization time, need someway of specifying what file/plugin it's for....
public Translation teleporthome = translate(Text.of("You will be teleported to " + Text.placeholder("homeName")))
}
Is the above possible? Or even something that looks remotely like it? if so it would be nearly transparent to developers.