You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This library has the potential to have localization built-in. Currently, all strings are hardcoded in this library, especially in the derive part, but with localized strings, they have to live in some data structure providing strings per language.
This library has the potential to have localization built-in. Currently, all strings are hardcoded in this library, especially in the derive part, but with localized strings, they have to live in some data structure providing strings per language.
The "obvious" crate for localization is fluent.
To tackle the design there are several issues that we need to address:
Markdown file
Recall that a command is documented in a markdown file, which is referenced like this:
That works great for a single file, but we might need some more flexibility.
Instead, we need some regex-like / glob-like pattern:
or
Every file with that pattern would be included in the binary and the right text would be selected at runtime.
Options
The help text for the options could be written in fluent files. Ideally, this would be parsed at compile-time, somehow.
Errors
Errors would also need to be written in fluent. This goes for all errors in the coreutils, but also for the errors produced by this library.
The text was updated successfully, but these errors were encountered: