Experimental I18n Support (only client/common/inspector/interactive)

[philtweir]

Trial to see what would be involved in adding rust-i18n to support translatability. This only translates the crates atuin-common and atuin-client, plus inspector.rs and interactive.rs in the atuin crate.

I am pretty new to this, so keen for feedback from knowledgable folks. Rust internationalization does not seem to be in a greatly active state - most of the packages have long-standing issues/PRs without a lot of movement, and no one package provides a one-stop shop. sys-locale and rust-i18n are relatively well-used recently (2nd and 6th in lib.rs i18n package stats) and fairly uninvasive.

Using English & Irish and only the interactive search as a minimal test. To use:

LANG=C atuin search -i
LANG=ga atuin search -i

The main action points would be adding t!(...) everywhere appropriate, accounting for the non-static return values, and then progressively adding translations to app.yml files as people wish to PR.

Maybe overkill, but on the basis that every natural language string is a user-facing string, by the nature of a CLI tool, I have added t! basically everywhere. If a minimalist approach is better, easy to wind that back, but at least it is clear what the scale of changes is at the top end.

I have included one Chinese string (which would need confirmed by a native speaker!) to see how this works in a non-Latin charset in atuin-common but other than that, the examples are (English and) Irish.

Notes

• the biggest logic impact is that, because the strings are dynamically composed based on the active locale, the compiler cannot check format strings where the translation string is parametrized, and that must be composed at runtime - it also means that conditionally-parsed format strings (like debug!) now have t! as a parameter instead, so the bulk of the string will be built regardless (this seems not a huge issue in an atuin context, but could be an argument for leaving them out of i18n). However, anywhere the static text can be split out from any parameters, I have done so, unless it seems possible that a translator might need to reorder the phrase in some language. E.g. "Loaded at: {time}" -> whole string parameterized, "Error in data: {err}" -> split and only "Error in data" translated
• as t!(...) can take arguments (e.g. translate %{time} ago) it does not return &'static str so, for FilterMode, I used lazy_static and elsewhere, switched to String or otherwise worked-around.
• for simplicitly, mostly I used the untranslated strings as the keys, but probably it would be better to invent slug-like keys
• initialization of the locale happens in each crate, but other than pulling the macro in, only a single line is required to call atuin_common::utils::set_locale(), which consistently sets the locale for each crate
• rust-i18n has two translation string file format versions - one splitting by language, and another all combined, so all languages are keyed under a given translation string -- I have taken the second, which is recommended for ease of translation (as the original and other translations are right beside). OTOH, having separate language files would avoid merge conflicts between languages
• I didn't see much benefit having per-crate tests, especially as the logic is all in rust-i18n, but I did put a couple of sense-checking integration tests in atuin_common::utils where the set_locale and get_locale commands live
• Project Fluent looks like a solid, standardized system, and is supported (to some extent) by Weblate but does not really look active given the size of project
• the rust-i18n approach is really simple, but could be more standard to use gettext?

Checks

• I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
• I have checked that there are no existing pull requests for the same thing

[philtweir]

this is maybe excessive, as SI units are supposed to have the same representation in every language, but it gives an idea how this could work

[philtweir]

(and non-SI units like days, hours, minutes, etc. do vary)

[philtweir]

Closing for atuinsh#2553