Adding Context or Locale & Bundle to ArgumentParsingException

[Galarzaa90]

Summary

Argument parsing error messages lack information, like which argument is incorrect.

Current Behaviour

The standard way to add validation to command arguments is using the failIf function. Providing localized error is easy since this is within a ValidationContext:

validate {
    failIf(translate("some.translationkey"))
}

However, even if you provide a custom error response, you do not have access to the localized argument's name, so you're stuck with a translation key, no locale and no bundle to translate this for the user

Preferred Behaviour

Either having access to the ValidationContext in ArgumentParsingException or at least have access to the respective locale and bundle.

While it would be possible to simply pass everything as part of the error message:

validate {
	// Making it a single string would mean translating the command name twice and maintaining it in two spots.
    failIf("${translate("argument.name")}: ${translate("some.translationkey")}")
}

One way or another, this ends up adding more places to maintain, since you would have to hardcode the argument's translation key in the validate block, since you do not have access to the name in there.

Suggestions

Checking some of the places where ArgumentParsingException is thrown, passing the context or bundle and locale seems like it wouldn't be that hard. I'm guessing the context can be tricky, since these are shared with chat commands and I'm guessing those are very different (haven't worked with chat commands)

If this change is feasible, I can try it adding it myself.

Media

Default error response

Attempt at custom error response

[gdude2002]

What's your use-case for this?

[Galarzaa90]

What's your use-case for this?

If using errorResponse builder to define a custom response, there is no way to localize the response (besides the error message itself, that should already be localized from the validation context).

If you have localized argument names and descriptions, you will have access to the translation keys, but you cannot translate them because you have no access to the bundle to at least show it on the default language.

The default message is localized, but being able to customize it with information, like specifying which argument failed, and maybe providing the user with the argument's description as a reminder of what the argument is meant for can be helpful for the user to fix it.

Example

• As seen in the image: Argument Error and Argument Description would have to be in English since there is no locale available.
• The error message already comes translated, so this is fine.
• The argument's name and description are only available as translation keys, and you can't translate them because you have no bundle name nor locale.

[gdude2002]

I've pushed a commit along with version 1.6.0-SNAPSHOT, which should be released in about 15 minutes.

I've gone ahead and added the locale and bundle to the event. Adding the validation context isn't really all that feasible right now, although I'm not entirely sure that's necessary.