How to preserve i18n with shared resource bundles while overriding command name?

[vanitasvitae]

Hey!
First of all thank you for developing picocli! It is very useful to create CLI applications.

Now I have a rather specific question:

I'm developing a command line application which implements a standardized command line interface which acts as a front-end for an API.
The idea is to support multiple backends of said API eventually. The backend implementations are supposed to be injected into the CLI frontend. The injector should also be able to modify the main command name, to read e.g. "backendXY".

Now my issue is: I internationalized the CLI frontend with the help of a shared resource bundle. There I have strings like "parent.subcommand.usage.header".
Now when I change the parent command name programmatically using

CommandLine cmd = new CommandLine(MyCli.class);
cmd.setCommandName("backendXY");

from inside the backend, "parent.subcommand.usage.header" can no longer be resolved (it would need to read "backendXY.subcommand.usage.header" now).

This coupling of user-facing command name and internal resolution of i18n resources is unfortunate.

What is the best way to work around this?

[vanitasvitae]

I suppose one solution would be to switch from shared resource bundles to individual resource bundles for each (sub-)command.
This is not ideal in my case though, since I have a lot of strings that are shared across commands.

[remkop]

Hi @vanitasvitae, can I ask you a favor?
Can you check out the project and build it and try with that version of picocli?
The reason I ask is that this would allow you to use some recent changes (#1710 and #1706):
That would allow you to have separate resource bundles for each subcommand, while still have shared entries in the root command for strings that are common across commands.

git clone https://github.com/remkop/picocli.git
cd picocli
gradlew publishToMavenLocal

That should publish picocli-4.7.0-SNAPSHOT to your local .m2 Maven cache. You can then try this in a project that uses the info.picocli:picocli:4.7.0-SNAPSHOT dependency.

[remkop]

Unfortunately though, for now I'm bound to using 4.6.3

I totally understand that. It would be great if you could give it a try and confirm that this new functionality works and solves your use case.

[vanitasvitae]

I will do that :)

[vanitasvitae]

I can confirm that I can easily work around my issue with 4.7.0-SNAPSHOT and shared resources :)
Great work!

[vanitasvitae]

One followup: Is it possible to set a dedicated resource bundle for picocli's built-in CommandLine.HelpCommand command?
Internationalizing the help command via the parent bundle still requires knowledge of the parent command name (e.g. parent.help.usage.header).

Being able to set a resource bundle would fix this I suppose.

[remkop]

Yes, you can find the CommandSpec of the help subcommand, and then call CommandSpec.resourceBundle(bundle) on it.