1
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.
just as an example:
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.
ellie 2
I’d be super interested to have this included, but only if we have a couple of others interested in contributing translations
lilydjwg 3
I can help with zh-CN translation when needed.
I can do a sort of Cunningham’s Law translation for Dutch, i.e. Dutch that is bad enough that it will motivate others to correct my attempts.
I can also do translation to Afrikaans, a language no-one ever wants to do computer stuff in.
dai 5
I can help with ja-JP translation too, when needed.
//I am such a fan that I can always raise 10 good points about atsuin.
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!
Will ping here when updated.
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.
ellie 8
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.
lapo 9
I’d be glad to help with Italian (it_IT) translation. 
(and then, knowing myself, continue using the English one myself)
Hey all!
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,bsandhrand 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.
Implementation-wise, @philtweir originally opened a PR in the form of [Project Fluent] Basic internationalization support (would close PR #2553) by philtweir · Pull Request #2674 · atuinsh/atuin · GitHub which uses Fluent to provide localization strings. I have re-opened that PR now and I think Fluent is definitely the path forwards. I will provide implementation-specific feedback in that PR body.
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?
- We would like to open up internationalization after [Project Fluent] Basic internationalization support (would close PR #2553) by philtweir · Pull Request #2674 · atuinsh/atuin · GitHub lands.
Very open to any other feedback too!