Using translation tools for TRPL

Hi all!

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.

We saw 5 tools: GitLocalize, Crowdin, POEditor, Mozilla Pontoon and Transifex.

GitlLocalize

Pros:

  1. easy Github integration (exists on Github Marketplace),
  2. completely free. Currently in active development (after changing owner)

Crowdin

Pros:

  1. easy Github integration (exists on Github Marketplace),
  2. free for open source project (with limits for commercial support for project).

POEditor

Pros:

  1. easy Github integration (exists on Github Marketplace),
  2. free for open source project (with limits for commercial support for project).

Transifex

Pros:

  1. free for open source project (with limits for commercial support for project).

Cons:

  1. require server for synchronize with Github.

Mozilla Pontoon

Pros:

  1. Completely free
  2. Used for translate website, in plan: for translate compiler and stdlib docs

Cons:

  1. Require server
  2. Don’t support Markdown

We chose Crowdin and GitLocalize and want propose this tool for translatione the Book.

How will it chang writing the book and accept PRs in original text? Nohow. This tool only track changes and save translations to different folder.

After introduction of using translation instrument (or in parallel with it), we need add multilanguage support to mdbook.

What are you think about using these tools for translation the Book?

сс @steveklabnik @carols10cents

2 Likes

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.

2 Likes

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.

2 Likes