Prepare for localization

[jeblad]

I'm a bit curious why there are no attempt on preparing the CLI11 lib for internationalization and localization (i18n/l10n)? I'm using this lib in an app that is localized, and it is slightly weird to see strings in English sprinkled in between the localized strings.

Seems like there are a number of patchwork strings, which are difficult to localize. There are also a bit messy separation between logic and messages in some parts of the code, which is a bit cumbersome, but other than that it should be possible.

If the lib is to be prepared for localization, ie internationalized, then it should be set up in such a way that the system can be replaced or simply turned off. Not all want a specific system, although I usually use GNU gettext. It is easy to turn of by setting up a simple define, and it is available on virtually every platform

[phlptp]

I think the main reason is time. I have no experience with either i18n or i10n so it would take some time to understand those and integrate them and make sure nothing conflicts with the current code.

[jeblad]

In a similar situation I would just set up gettext such that it is possible to replace it with something else. It is just a small block of calls necessary to set it up, and a few methods that are usually replaced with simple defines. The bulk of the work is the actual translations that goes in a single directory tree.

Gettext is cross-platform and available for *ux, Windows, and Mac OS X. There could be use cases that isn't covered, but it is perhaps the most used and universal ones.

[omerrbbulut]

Hi, I would like to work on this.

Before starting implementation, I’d like to propose a small, incremental approach to avoid large refactors.

My idea is:

• First step: introduce a minimal internal abstraction for messages (no public API change)
• Keep all current behavior and English strings unchanged
• Start by centralizing a small subset (e.g., usage/help labels)
• Then expand gradually in follow-up PRs if this direction is acceptable

The goal would be to:

• separate message generation from logic
• make future localization possible
• avoid introducing any dependency (e.g., gettext)

Would you be okay with starting from a small internal refactor like this?

I can start with a very small PR focusing only on usage/help labels as a proof of concept.

[phlptp]

@omerrbbulut I admit my knowledge of localization is limited but happy to review updates in this direction. That seems like a reasonable plan to me.

[jeblad]

The point “avoid introducing any dependency (e.g., gettext)” would be a major undertaking. Tried that once, believing it could be small and neat, it didn't work. The gettext library and l10n and i18n is very complex, and then there are all the tools that won't work with a new framework. Prepare for localization, and add a macro that makes it possible to turn it off. That what I would do.

If someone would make a new framework they should make it into a separate repository, and after proving its viability adding it as an optional feature. The gettext library is the major player in this field, and you should have a really good reason for not using it.

To use gettext you most of the time need one include, 3–5 lines of code, and a single macro. Exclude those lines and replace the macro and you have the English strings as they are now.

I should perhaps add that implementing any kind of "templating" as part of localization is inherently difficult, and might lead to security issues. I've used a couple of such libraries over the years, and both had critical vulnerabilities. I guess my experience with those libraries color my opinion on quick fixes on localization.

[omerrbbulut]

That makes sense, thanks. I agree that introducing a new localization framework directly in CLI11 would be too large in scope.

For the first step, I am thinking only about a small internal refactor to prepare for localization:

• no public API change
• no framework decision yet
• no gettext integration yet
• just centralizing a very small subset of user-facing strings

That should make future steps easier, whether the project eventually uses gettext, macros, or another approach.

[phlptp]

Given one of the main use cases of CLI11 is as a standalone single header library, I do not think it reasonable to require it to include anything that is not part of the standard library by default. With that said I have no issue having optional linkages to other packages for significant added capability, particularly in this case where applications that need localization are likely already including one of those packages. Seems reasonable to start making changes that would make internationalization easier to integrate.

[omerrbbulut]

Sounds good, thanks for clarifying.

I’ll start with a small internal refactor (no API changes, no new dependencies) and focus only on centralizing a few help/usage labels as a first step.

We can expand from there if the approach looks good.