This is an interface that will be used to parse string from the language file.

It's okay to create separate classes for the languages, but more ideal way to do that is using enum.

Look at this example:

public enum MyPluginLanguage implements Language{
    Command_Kick_Description("Kick a player"),
    Command_Kick_Usage1("&5/mmc kick <player>&8- &7kick the player named <player>"),
    ;

    private final String[] def;
    private MyPluginLanguage(String... def){
        this.def = def;
    }

    @Override
    public String[] getEngDefault(){
        return def; 
    }
}

If you are not used to enum at all, just copy all the codes except the Command_Kick blah blah part. It will still work without problem.

But if you are experienced with enum, the example makes a enum constructor (the private one) with varargs as argument. In this way, you can put any number of Strings without creating the array every time. Then, the getEngDefault() method is implemented from the Language interface, and this method will be used when a new language file should be created.

Attention) Just like I explained it in the PluginConfig wiki, you should be careful about how you are naming the enum. the _ sign will be translate into .(dot), so you should not leave any dangling _ sign or use conflicting names.

Once everything is done, you might wonder how do you use it. It's very simple. The PluginBase contains useful instances that can help you, and one of them is called PluginLanguage. However, before even going there, you need to register your languages upon plugin enables.

public class MyPlugin extends PluginBase{
    public MyPlugin(){
        super(new MyPluginConfig(), "mymaincommand", "myadminpermission")
    }

    @Override
    public void preEnable(){
        //TODO initialize your commands, languages, managers, and APISupports
        initLanguages();
    }

    private void initLanguages(){
        for(Language lang : MyPluginLanguage.values())
            this.lang.registerLanguage(lang);
    }
}

Notice that in PluginBase (well MyPlugin in fact), there is a field called 'lang', and this is where the PluginLanguage instance is stored. The above code is registering your newly created languages one by one. This is one of the reason why we should enum instead of just class.

Then, now you have registered your language, you now may use it to send messages defined in the language file. To do so, use the sendMessage() method of PluginBase.

base.sendMessage(player, MyPluginLanguage.Command_Kick_Description);

One great thing about this method is that it will automatically search for the locale of the receiver and pick appropriate language file needed. English will be used if no such language file found, yet you can change the default language in config.yml as well. It's en.yml by default.

But in some cases, you might need to parse the string yourself without sending the message to the player; you can use parse it through parseStrings() method or parseFirstString() method. Just like the name itself suggest, it simply parse the Language and return the parsed String. You may want to take a look at the PluginLanguge

PluginLanguage also supports replacing its own placing holders.

There are five types of placeholders you can use: String, int, double, long, and boolean. To do so, there are little bit of setups.

For the language file, the language file should contain those placeholders. For example,

Command:
    Kick:
        Description:
            - '&aHello ${string} ${integer} ${string} ${integer}'

For your plugin, take a look at this example:

base.lang.addString("a string 1");
base.lang.addInteger(1);
base.lang.addInteger(2);
base.lang.addString("a string 2");
base.sendMessage(player, Some.MESSAGE);

the above code will print:

&aHello a string 1 1 a string 2 2

I randomly used addString() and addInteger() two show that as long as the types are different, the order doesn't really matter. So when you use addString(), it only matters whether you use addString() again or not. Same thing goes for addInteger() or other add methods.

There is a small enum, DefaultLanguages that contains pretty general messages like 'you don't have permission' message. Feel free to benefit from using these pre-defined messages. And if you find some language that is commonly used yet not in the DefaultLanguage, just make a pull request.