Distinguish context menu commands name/label/description

[HanabishiRecca]

Description

When creating new context menu command with description field specified:

code: 'APPLICATION_COMMAND_CONTEXT_MENU_DESCRIPTION_INVALID'
message: 'Context menu commands cannot have description'

Expected Behavior

Use context menu command description to override it's system name in UI.

Current Behavior

API responding an error.

[advaith1]

this is intended functionality, logical, and documented (in danger boxes too).

[HanabishiRecca]

@advaith1, I understand. But obviously we need a feature to override a context menu entry text with human-readable description, instead of command system name.

[advaith1]

you should just make the name human-readable...

[HanabishiRecca]

you should just make the name human-readable...

This has a lot of disadvanages:

1. 32 chars is way less than desired.
2. Handling such names in code is a pain.
3. Gets even worse with UTF-8 because English is not the only language existing.

[Nihlus]

I agree with @HanabishiRecca here - having separation between the UI string and the system identifier is highly desirable, especially considering the various limitations imposed on them.

Going beyond just the menu entries themselves, a split like this would be nigh required if Discord implements a way to nest context menu options, since they'd likely be sharing groups with other command types.

[Mehgugs]

Completely agree, the fact that the names of application commands are now not unique per scope when the description tag is sat there empty feels like a major oversight. It would have been much more ergonomic if the name was used internally by us and the description was what was shown to the user. I don't understand why they went with this system.

[Nihlus]

Now that I've played with context commands, there's another caveat to this issue - casing is normalized for context command names, which is extremely undesirable if it's meant to be a UI string. What I mean by this is that if I have a name that is, say "Do thing", it becomes normalized to "do thing", which is just plainly inconsistent with Discord's own casing of other context menu items.

[advaith1]

context menu commands can have capital letters (and many do) so I'm not sure what you mean?

[devsnek]

descriptions are unlikely to happen, and even if they did, they would not replace the name in the ui.

[Nihlus]

@advaith1 Ah, my apologies, it was a bug on my end.

[Nihlus]

@devsnek The ideal API for me would be an entirely new field - title - for explicit use as a UI string.

[devsnek]

the primary key here is id, name is for the ui. you'll need to handle mapping that.

[Nihlus]

Fine. Are you planning nested context menu commands? If so, will they require entirely separate group constructs, since the existing rules for name are unlikely to cut it as a UI string? If not, why not?