[Project Fluent] Basic internationalization support (would close PR #2553)

[philtweir]

Alternative approach to #2553. Not closing that just yet, but keen for feedback either way.

After thinking about the discussion on the Forum, the biggest challenge is that a lot of small changes brings risk. This is a suggestion:

1. finalize this PR that only adds the machinery for Fluent (and an single "canary" string)
2. this change sits on top to add give MVP coverage of translatable strings (feature/i18n-support-fluent-basic)
3. a much bigger set is here https://github.com/philtweir/fork-atuin/tree/feature/i18n-support-fluent

Suggestion: tidy-up, PR and merge this to provide i18n support. Once that is in a release and there is no negative feedback and folks confirm that the single example works OK, then PR 2., which is roughly the minimal set of common translatable strings. Less than that, and there's too much English leaking through to get buy-in, any more and the PR is oversized.

NB: there is a commit in 2. with English translations - note that it covers the full set of changes in 3. so most of them can be ignored in the near-term (happy to split it in two parts - one for 2. and one for 3.).

This PR does not add any translatable strings except one. Changes 2. and 3. only translate the crates atuin-common and atuin-client, plus inspector.rs and interactive.rs in the atuin crate.

How to test

This PR has only one translatable string, to make sure it works and breaks nothing, as the main challenge is to get the machinery in without regressions. However, using https://github.com/philtweir/fork-atuin/tree/feature/i18n-support-fluent-basic, you can build and take the interactive search as a minimal test.

In this PR, the only visible change should be:

$ LANG=en-US atuin asdf
error: unrecognized subcommand '⁨asdf⁩' and no executable named 'atuin-asdf' found in your PATH

Usage: atuin <COMMAND>

For more information, try '--help'.

vs

$ LANG=en-GB atuin search -i
error: unrecognised subcommand '⁨asdf⁩' and no executable named 'atuin-asdf' found in your PATH

Usage: atuin <COMMAND>

For more information, try '--help'.

How translatability is implemented

Adding t!(...) everywhere appropriate, in some places accounting for static return values, and then progressively adding translations to *.flt files as people wish to (separately) PR.

Notes

• 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.
• originally I leaned to rust-i18n as Project Fluent wants slug-like keys, and that would make PRs much bigger and hard to review, but this approach creates a more traditional gettext-like macro, which is less invasive (as recommended in the cargo-i18n docs) - this means a new atuin_macro package (if this is a hard no, please say and I will try new ideas!)
• I had some difficulty getting the crates to behave consistently independently (which was not previously an issue) but I have now centralized translation strings in a top-level ./i18n folder (this has a side-benefit/downside that the same string will be translated the same way in all crates)

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 an awkward example but maybe helps show where extra steps are required (e.g. a simple non-literal/const string would be wrapped by t!(..) and done)

[philtweir]

TODO: this seems to be a cargo-i18n issue that it cannot accept non-literal versions.

That said, running cargo i18n doesn't actually seem to be necessary.

[philtweir]

But might need an upstream change in cargo-i18n to fix :/

[atuin-bot]

This pull request has been mentioned on Atuin Community. There might be relevant details there:

https://forum.atuin.sh/t/internationalization/733/7

[philtweir]

(see below: if it is not easy to address the cargo-i18n issue then I'm fairly sure we can ignore it - either way will restore these before merge)

[ellie]

part of me would love to force en-GB 😏

[philtweir]

I'll be honest, it was en-GB until a commit or two ago, so ... :D

That said, it may be an gentle way to encourage a wide sample, as more people will spot that is falling back to -ise spellings instead of correctly picking up US locales, than the other way around 🤔

[ellie]

generally pretty happy with the direction here - thanks for taking it on!

[ellie]

I've generally been pretty against macros in our codebase but in this case I think it makes sense

obv this is just a draft but for the final version I'd really appreciate it if you could thoroughly document what's going on with the code here, just to make it as approachable as possible for future contributors! 🙏

[philtweir]

Of course - will do! This was the main point against fluent-rs, alongside activity, as their macro (for conceptual reasons) requires slug-strings in the codebase rather than human readable ones, so using it means one of:

1. a wrapper macro to go from human-readable to slugs
2. switching all translatable strings to slugs
3. another idea I had not thought of

2 has the downside of making things like making UI bugs harder to see in reviews, and grepping for error messages harder, as well as more visual change to existing code when making strings translatable, so I thought that was probably too much friction. On the other hand, as mentioned, 1 adds custom magical machinery, a new macro module, and somewhat undermines fluent's own differentiating motivation from gettext (although, of course, it is still possible to use it in the intended way on a case-by-case basis).

However, one other benefit of fluent is that it is a standard and seems to be supported by (for example) Weblate - it might even be possible to get a free instance on their libre-project plan, if desired.