Enhancement: Make Cli ArgumentParsers locale configurable

[JamesBoon]

When creating a command in dropwizard, I usually add my help texts in english. This makes sense as dropwizards help texts are english too.
But argparse4j uses Locale.getDefault() and for this reason the output is in two different languages on each non-english system.

I have two different proposals:

1. Just change the creation of the ArgumentParser here to set the english locale:
   final ArgumentParser p = ArgumentParsers.newFor(usage).locale(Locale.ENGLISH).addHelp(false).build()
   This would be a breaking change though. But maybe possible for 5.0.0?

2. Or: Make it possible to somehow pass more options to the creation of the ArgumentParser. Maybe by enhancing JarLocation. It could return the locale in a function like getLocale() (default: Locale.getDefault()). Then a protected Function of Application<> like getJarLocation() could be used here:
   final Cli cli = new Cli(getJarLocation(), bootstrap, System.out, System.err);
   and the line from "1." would become:
   final ArgumentParser p = ArgumentParsers.newFor(usage).locale(location.getLocale()).addHelp(false).build()

What do you think? Is one of these ways possible?

[zUniQueX]

Hi @JamesBoon.

I don't think setting the Locale to Locale.ENGLISH would be a good idea. If someone overwrites the default locale, the messages would change after integrating this change.

Your second approach should be possible. The more flexible way in my opinion is to provide a general customizer for the ArgumentParserBuilder. This could be integrated via a ServiceLoader to allow changing e.g. the locale at deployment time.

[JamesBoon]

If you use a ServiceLoader you would of course be very flexible. However, I fear that this leads to way too much boilerplate... perhaps there could be a standard implementation that would be easily configurable. And if you really need it you could still expand it.

I don't know what would be the best approach here.
Because just passing a few variables or a variable object to the function would be significantly less flexible, but it would also be easier to implement and there would be more control over what exactly can and may be configured.

What do you think? Which way would lead to a better, more comfortable way for a developer using it?

[JamesBoon]

Hi @zUniQueX,
I finally found some time to make an example implementation of what I meant. You can see it here.
It is just a rough sketch. There is still documentation and tests missing. I just wanted to know if this way might be okay and if I should open a PR for this.

These changes will just mark the JarLocation as deprecated and will not introduce any breaking changes!