Approach for Supporting Internationalization

[toadslop]

Hey all, I'm working on an experiment to add internationlization support for Clap in a minimally invasive way. I want to describe my approach here and get a feel for whether this change would be a welcome addition to the project. Allow me to describe my understanding of the current implementation and how I would adjust to handle internationlization.

Current Implementation

Text comes in the following two forms:

• user-provided static values (static in the sense that once the user provides them, they are not modified by clap but always display as provided)
• hardcoded default text

With the above text values, Clap does the following:

1. applies styling to the text
2. interpolates into a template
3. prints to the console

Suggested Implementation

I have a prototype which demonstrates the following as a viable alternative:

1. extract all hardcoded text into external configuration files; replace removed text with translation keys to allow looking up the values either from those configuration files or user-defined alternatives
2. accept user-provided values as "transation keys" rather than the actual text
3. create a translation provider trait that allows projects using clap to provide their translated texts in any form they prefer
4. render the styled text as clap does already, but render the translation keys into the resulting output in template format (i.e. "{my-key}")
5. make a second pass over the output string to interpolate the final text values into the output
6. print to the terminal

Taking the a second pass through the string does add some performance overhead, but I believe this is the best implementation for the following reasons

• the performance overhead is negligible for command-line tools since they don't typically output enough text to matter
• the solution is minimally intrusive to how clap currently works, meaning that it does not require a much refactoring to the existing implementation to achieve

Thoughts?

[epage]

We are tracking localization in #380

[epage]

While I recommend moving the conversation to the mentioned issue, I'll at least say I hesitate in making a bespoke localization framework like I was about a bespoke terminal styling API.

[toadslop]

@epage Thanks for the suggestion. I added a comment to the issue (#380 (comment)) and also opened a draft PR with a minimal implementation of the approach to demonstrate how it would work if fully implemented in a production-ready way (#5853)