Add support for translating command description and usage

[pop4959]

As the title implies, this PR allows translators and server owners to change the command description and usage messages. This avoids the need for people to maintain their own versions of Essentials with custom plugin.yml files. The implementation here uses empty values to indicate that default description or usage from plugin.yml should be used.

Example usage

config.yml

locale: de

messages_de.properties

banCommandDescription=Verbietet einen Spieler.
banCommandUsage=/verbot <spieler> [grund]

commands.yml

aliases:
  verbot: ban $1-

Closes #3376

[mdcfe]

I think the description and usage messages should be included in messages.properties by default. Otherwise, Crowdin translators won't have any reference for translating these messages (unless they go and dig through the plugin.yml themselves).

[pop4959]

I thought about that, but I also thought it would be valuable to not have the English version duplicated potentially 3 times (one in plugin.yml, one in messages.properties, and one in messages_en.properties) when we could avoid duplicating it by letting plugin.yml take control of it. I guess it's probably an inevitability though. Also, it was actually the easiest way to implement this feature (not having to copy all of the messages).

On second thought though, how about we just remove all of the messages from plugin.yml? Then, we have them consolidated solely in the message files. If I can get a thumbs up for this idea I'll go ahead and do that (this will probably be a bit of somewhat manual work).

[mbax]

plugin.yml should always be as descriptive as possible. If message duplication is a concern, add the messages to plugin.yml and messages.properties during building, pulling from messages_en.properties! :)

[pop4959]

Pulling from messages_en.properties is not an option, as that file is exposed to translators, who should not be able to directly change, for example, the syntax of commands.

plugin.yml currently houses the description and usage strings for commands, not exposed to translation.
messages.properties contains defaults.
message_<lang>.properties contains translations.

The only concern is with having to manually sync description/usage strings between plugin.yml and messages.properties. It'd probably be better to consolidate them in one place, and in which case, I'd argue it's better put in messages.properties since these are not touched by translators.

[mbax]

as that file is exposed to translators, who should not be able to directly change, for example, the syntax of commands

I don't see any syntax in messages_en?

[mdcfe]

@mbax messages_<locale>.properties files are automatically generated by Crowdin and only contains messages that have been translated on Crowdin and approved. en only exists for legacy reasons (haven't gotten around to removing it) but it's intended to be identical to messages.properties once Crowdin has updated it.

edit:

It'd probably be better to consolidate them in one place, and in which case, I'd argue it's better put in messages.properties since these are not touched by translators.

plugin.yml also isn't touched by translators. The main reason for keeping them in both is that third-party plugins might attempt to read command usages/descriptions directly from the plugin.yml or PluginDescriptionFile instead of from the command map.