Since Rust 1.0 had been released many people translated the Book to other languages. Usually people take the original version of the book and translate page by page. When texts change translators see the difference and update previous translations if required.
The Rust community from Russia decided to find a way to improve the situation and quality of translation process. We understand that it is needed to simplify tracking changes. So we found a thread in IRLO where supposed add meta information for every paragraph of the book in order to track changes. We also have found tools that could track changes of paragraph without adding meta information to original text (in thread also supposed same tools).
All tools intended for community-drived translation, they monitors changes in git repositories, support glossaries, approval and discussions. Also they used side-by-side model for translation.
I would like it to be consistent with all of the other ways that weāre doing translations; thereās already efforts for the website, standard library docs, etc. cc @Manishearth
Ultimately, whichever path is chosen, it will need to be implemented in mdbook first, and then we can use that support.
I actually explicitly didnāt create a thread for the book because Iām not quite sure if we want to use the same tooling for it, and I donāt have the bandwidth to investigate both the infra side and the tooling side. Pontoon is great for lots of small/medium-sized strings, the book is basically one flowing document. It would be just as easy to maintain a new repo with translated markdown files. We could split it up paragraph-by-paragraph to keep track of changes better, but thatās not so great either.
There are various tools that can help with this, I donāt think Pontoon is what we want here.
GitLocalize sounds promising. Perhaps set up a test repo as a fork of the book, make it work with GitLocalize, and start work there?
FWIW ārequires serverā isnāt a big deal, if an option works I can set it up on Heroku or something, thatās what weāve done with Pontoon.
I want start adding multilanguage support to mdbook. But maybe before adding that, will be better to start refactoring.
While mdbook doesnāt have multilanguage support, we can build every book separately and then deploy all rendered books to the site.
Why we should start using translation tool now? I think because translating website was started, discussion of translation of compiler and stdlib started and book repo has 25 open issues with links to translations. With introducing translation tool for book we can collect all translations in one place and simplify track changes.
Creating a fork of the book for testing GitLocalize is good idea. I can create fork and setup GitLocalize for this repo.
About a month ago we started testing GitLocalize. We use translation tool for book "Rust by example". This book was choosed because at that moment about 50% was translated and original did not chage much (since started translation of RBE).
Over this month we talked with support and open some issues and feature requests. Most critical issues currently resolved.
What we did like in GitLocalize?
GitLocalize track source and show changed paragraph/segments.
GitLocalize can suggest translation for similar paragraph/segments.
GitLocalize allow to translation moderator change translated text (if we use only Github for translation and after translating page send PR, we are waiting for new commits to this PR, if we found typos or other comments, and author can forget this PR).
GitLocalize can synchronize with existing translation. If GitLocalize cannot compare original and translation, it offers translation moderators for mannualy link original and translated paragraphs.
What we disklike in GitLocalize?
Sometimes we found bugs.
After time we started translation of Async Book and some time ago i found issue, where asked about i18n in Async Book and told about translation to Simplified and Traditional Chinese.