Translations from property file not applied?

[Andre601]

Issue Checklist

• [X] I have checked for similar issues on the Issue tracker
• [X] I have updated to the latest version of JDA-Chewtils.
• [X] I have checked the branches or the maintainer's PRs for upcoming bug fixes.

Affected Modules

Command

Description

I'm unsure what exactly the issue here is, if it is an issue at all, but it seems like that translations from a properties file using the TranslateUtil are not applied?

To give some context, I have this properties file named commands_en-GB.properties:

COMMAND_BLUSH_NAME=blush
COMMAND_BLUSH_DESCRIPTION=Shows that you are blushing.

Then in my main Bot class am I doing this:

private void resolveCommandTranslations(){
    TranslateUtil.setDefaultLocale(DiscordLocale.ENGLISH_UK);
    int translations = 0;
    for(TranslationManager.Lang lang : fileManager.getLanguages()){
        if(!lang.supportedLocale())
            continue;

        try{
            Properties properties = new Properties();
            properties.load(getClass().getResourceAsStream("/lang/commands_" + lang.key() + ".properties"));
            TranslateUtil.addLocale(lang.discordLocale(), properties);

            translations++;
        }catch(IOException ex){
            logger.warn("Encountered IOException while trying to load commands_{}.properties.", lang.key(), ex);
        }
    }

    logger.info("Resolved {} Command translations.", translations);
}

Finally, I override the SlashCommand class to implement some own stuff, including a central command handling. One thing I do there too is set the nameLocalization and descriptionLocalization values like this:

/*
 * Used for commands who don't have a different name in the properties file.
 */
public BotCommand(String name){
    this(name, name);
}

/*
 * Name is used for the propertyPrefix, allowing to separate duplicate names (i.e. from sub-commands)
 * While label would be the name used for the (sub-)command.
 */
public BotCommand(String name, String label){
    String propertyPrefix = "COMMAND_" + name.toUpperCase(Locale.ROOT);

    this.name = label

    this.nameLocalization = TranslateUtil.buildLocaleMap(propertyPrefix + "_NAME");
    this.descriptionLocalization = TranslateUtil.buildLocaleMap(propertyPrefix + "_DESCRIPTION");
}

When I now run the bot does it report to have resolved 1 translation, but when typing the command - in my case /blush - does it show this:

This makes me believe that the localizations aren't applied and only the name and value are set...

[Chew]

Description definitely works and is working for me

I suppose make sure your Discord is set to Discord UK, but I haven't tested two things you're doing

1. Not setting a this.help
2. Setting a default locale, but not sure how this would affect it.

[Andre601]

Yeah, I didn't had the client on english... Tho I thought that having a default locale set would actually make it use that on any language not set, tho that was bad thinking on my end I guess...

[Chew]

Yeah I'm inclined to believe the descriptionLocalization requires this.help to be set but I'm unsure. Perhaps I can set this.help if you set a descriptionLocalization if it's blank to prevent that. I'm not sure how the fallbacks work on Discord or JDA's end.

[Andre601]

Looking a bit into this, the localization is applied within the SlashCommand class by first creating the SlashCommandData instance and then applying the map using SlashCommandData#setNameLocalizations(Map<DiscordLocale, String>) and SlashCommandData#setDescriptionLocalizatuions(Map<DiscordLocale, String>).

I believe the main problem here is, that Discord defaults to whatever text you gave for name and description when it can't find a locale entry, and since Chewtils here is creating this data using getName() and getHelp() does it result in what we encounter here.

So perhaps it would be a good idea to check at the start, if localization was set, and if yes, retrieve the default lang values for name and description. And if those aren't null, use them as the command values, else default to the getters.

I'll try and work out something here to then PR, as it doesn't seem too complicated. Tho, maybe at least for command we should force a command name to be set? Or do we really want to allow a default locale value to be used? Because iirc does the command name itself not allow non-latin characters... So we should ensure this to be the case.