Lining up with an experimental PR for feedback, this suggestion is about adding translations to Atuin.
Right now, I am trying using rust-i18n, which is pretty simple to use and translate for, but does not support gettext, and another question is how many strings should be translatable. I assumed all, so tried it out on a subset of the sourcetree by tagging every string a user could see, but then that touches a lot of code, albeit in what should be a small way.
Not sure if this is the best place, but I guess making things translatable is only the first conceptual step to having translations So keen for feedback on how desirable this is for multilingual community members, bearing in mind that, unless people are enthusiastic to (progressively) do the translations, this feature is not that useful.
Also keen for feedback on the technical approach, but perhaps that makes most sense on the PR.
Sorry for the delay folks - ironically, I was on an extended international trip
If @ellie is happy given there is some interest at least (perhaps we can make sure there is at least one acceptable translation on the PR), then I would be keen to do this sooner rather than later to save multiple painful rebases, but I did try using fluent and I think the results are maybe a bit better for translators and maintainability, even if the code is a little more complex. Will update the PR and perhaps if someone would be willing to do a mini trial and give some translator experience feedback that would be appreciated!
This will need some refinement but it’s a far smaller i18n-tooling-only PR than the initial attempt. Suggested plan, to get thoughts from @ellie: I could tidy this PR up and once it is ready for inclusion in a release, then we can get feedback on whether there are any surprises (and no regressions) as a result of the machinery itself - it contains exactly one translatable string, so should be possible to get testing to see if it works and does not break anyone’s setup before expanding in a following release. I have a follow-up PR that adds real translatability with a bunch of strings, but maybe that two-stage approach is a lowish-risk option.
Sorry for the delay in getting back to you, was wrapping up 18.5!
yep! definitely happy with the interest here.
I just had a look through your PR, happy with the direction you’re taking
I think we could get this PR in, ship a pre-release and have a few people use it. So long as that’s OK then the follow up can be included! We have some people following main as well, so things are generally caught pretty fast.
We’re ready to proceed the internationalization effort on our end and here’s what we foresee that looking like:
We will support app-level internationalization – menus, error-messages, UI elements.
We do not plan on writing localized docs. We’ve tried really hard to make it work, but it’s unfortunately too much maintenance burden to be feasible.
Regarding the app-level internationalization policy, we think the following would work:
All localized strings are provided best-effort. At its core, the Atuin team will not support localized strings directly, as our team predominantly speaks English. I speak sr, bs and hr and can provide localized strings for those.
In the case of partial translation, Atuin will fall-back to English strings.
In the case of the original English string changing in a PR, there are two paths we can approach:
Accept a stale translation. We plan on doing this when the spirit of the original sentence hasn’t changed.
Remove the translations. Whenever the core sentence of what we write changes, we surmise that no translation is better than a wrong translation, so the policy would be to remove translations.
We shall not block features, bug-fixes nor releases for translation strings. Our goal is for internationalization to help more people engage with the terminal, and have fun in their shells, but we cannot block features, nor bug-fixes unfortunately.
We have the following questions from the community:
Do you think this plan sounds good, fair and inclusive, esp. with respect to:
The fact that we do not plan on translating docs? We want to strike a balance between quality, velocity and accessibility and we unfortunately feel that translating the docs has marginal value.
The suggested policy regarding handling translated strings in the application?
So keen for feedback on how desirable this is for multilingual community members, bearing in mind that, unless people are enthusiastic to (progressively) do the translations, this feature is not that useful.
