Localization in Slash Command Responses

[A5rocks]

Description

Offer a language key in the Interaction or ApplicationCommandInteractionData objects. This could be client language (please!!!) or the preferred_locale attribute on a guild.

Why This is Needed

Sure the commands and descriptions will be in English (or bot creator's language of choice). However, I'm sure there will be a way to solve this eventually (this falls under improving the UI). All the while, the outputs would be in the bot creator's language of choice, which... the guild members can't read without a translation tool.

Basically, the commands will sometimes return languages that the command runner will not understand - obviously a problem, and not the kind of seamless integration people are looking for. By providing a language flag, a bot can at least tell the user the bot has no translations, and a list of other suggestions.

Alternatives Considered

• Requiring at least 1 English (or origin language) member on a server to configure the bot response language, as most localized bots require now.
• If every command uses a string, trying to detect what language that string is. (as in a string option)
• Requiring users to use a translation tool like DeepL.
• Only emoji outcomes. This might fall victim to different cultures having different meanings for different things.

[GamingGeek]

To add to this,

Sure the commands and descriptions will be in English (or bot creator's language of choice).

Maybe also add the ability to provide localised descriptions? Would be nice to allow users to see the description in their language of choice if the bot developer adds support for it. Maybe instead of providing a string, an object could be provided like below

{
    "name": "commandname",
    "description": {
        "en-US": "english description here",
        "de-DE": "german description here"
    }
}

If a string is provided, then it will act as it currently is but if an object is provided, maybe the keys could be validated against languages currently supported in the client to ensure valid language codes are used.

[msciotti]

We should and will absolutely support localization, but @A5rocks, we wouldn't be able to do it quite in that way.

The most immediate solution is your idea--adding a language key for the user on Interaction payloads. However, this poses a fairly significant privacy concern.

We've never made an individual user's locale public information without either auth (OAuth2) or having a locally installed application via our GameSDK (implicit auth).

When we think about localization, I'll bet that most of us think about supporting languages like Spanish and French. But we support a lot of languages that are much more specific--like English UK or Taiwan. And while we'd like to imagine that everyone is a good person, people often aren't, and global politics can make people act poorly (as funny as that is to say about a developer API, it's true).

The solution would need to be something more like what @GamingGeek suggested--specifying localized objects that we map internally and display to users in their preferred language (which is basically how we handle localization internally as well). Unfortunately, that puts a bigger technical support burden on us to both support localization in this way and to make a not-awful API for you guys.

So, it'll take a bit more time for us to support than just adding a language key, but this is a thing that needs to be done right.

[A5rocks]

Got it, yeah. I was thinking maybe the fact slash commands have to be initiated would help prevent that, but I completely overlooked how certain regions might really dislike each other and whatnot.

[cptpiepmatz]

I also think that you shouldn't automatically fallback to english. Some bots may need another default language. So adding a default tag to the proposed translations would be cool. Maybe like this:

{
    "name": "commandname",
    "description": {
        "en-US": "english description here",
        "de-DE": "german description here",
        "default": "en-US"
    }
}

[Lachee]

I also think that you shouldn't automatically fallback to english. Some bots may need another default language. So adding a default tag to the proposed translations would be cool. Maybe like this:

{
    "name": "commandname",
    "description": {
        "en-US": "english description here",
        "de-DE": "german description here",
        "default": "en-US"
    }
}

but if the bot was written in another language, wouldn't it have the translation for that language anyways defeating the need for a fallback?

[cptpiepmatz]

I thought which language should be selected if your prefered language isn't available. For most it's "en-us" or so but maybe another should be used. Was just an idea.

[msciotti]

After some internal discussion, we agree that localization in responses is super important. We will support this in the future, but can't in this first iteration of Slash Commands.

Why:

• Returning you the locale of the user is currently deemed a privacy issue, as stated earlier
• If you send us a dictionary of localized strings, we don't have a way to correctly pipe that through our API
• We don't have support for pre-registering localized strings

The third option on the list is probably the right way to do it, but requires a lot of effort to build internally. We think it's valuable, but not for this release compared to other feature requests.

This request is on our internal issue tracker so we won't forget 👍

[Skillz4Killz]

@msciotti As a simple solution, could you not send the guilds locale? I don't think that's a privacy concern and that would meet I believe a vast majority of the use case. I've never personally needed the exact user's locale. If they are on a server with a XXX language locale, more than likely they will speak that locale.

[advaith1]

Bots can already see the guild's locale at preferred_locale in the guild object (but that's currently only a setting for community guilds).

[Skillz4Killz]

Bots can already see the guild's locale at preferred_locale in the guild object (but that's currently only a setting for community guilds).

@advaith1 That only works for bot accounts. For serverless Slash commands, gateway stuff isn't necessarily available. So yes although bots have it that doesn't mean slash commands do as well. Slash commands sending the guilds locale would go really far in easily determine what to reply with

[msciotti]

As a simple solution, could you not send the guilds locale?

We talked about this, yes, but that field is only set-able if you are a community so that we can help filter results in server discovery. So most guilds would not be able to choose. It also wouldn't make sense for smaller guilds to be able to enable this setting, since nothing is actually done with it.

[MinnDevelopment]

What about adding an option in the oauth settings? Similar to other dropdown menus the application could offer a choice of available locales

[castdrian]

What about adding an option in the oauth settings? Similar to other dropdown menus the application could offer a choice of available locales

That doesn't sound good. Whoever adds the bot then basically chooses the language for everyone else in the guild.

[danbulant]

Probably the best way would be to have a guild setting for language that would be used by bots (or even including channel languages), most bots won't need the exact user language as stated earlier.

[ccppoo]

dose locale needs time to update after register?

[A5rocks]

I don't think localized commands (names and descriptions) have released yet, just sending user locale in the interaction. I may have missed something though.

So I don't know what you mean by "does locale take time to update after register."

[ccppoo]

@A5rocks
using http post method with localizations returns me status code 200s

json_ = { 
        "type" : 3, 
        "name": "테스트용_커맨드2",
        "name_localizations" : {
            "ko" : "테스트용_커맨드2",
            "en-US": "command_for_test2"
        }
}
endpoint ="https://discord.com/api/v8/applications/{testapp_id}/guilds/{guildID}/commands"
requests.post(endpoint, headers, json=json_)

I sent json like above, so I thought localizations were working

[advaith1]

client support hasn't shipped yet, which is why the feature is not released or documented yet

also you shouldn't have commented your question on this old and outdated GitHub issue

[TheChilliPL]

Any updates? The localization is now a documented part of the API