Translations for Rust

I’d like to participate to the French translation. But there is a common problem with translations of documentations : keep them updated. I usually read English documentation even if a French one is available, since translated docs are usually outdated.

IMO to make the system viable :

  • When a change occurs on the original page, the translators should be warned.
  • The visitor of a outdated page should be warned too and provided a link to the original page
  • There should be a way to easily find all the changes that occurred to the original page since it was translated.

For translating content of web sites, Pontoon is the popular choice for Mozilla web properties these days. You can learn more about how it works at MDN.


Please count me in if u want any helps in translating into Chinese.

Hi guys, I’d like to be part of the Brazilian Portuguese (native) and Spanish translation too.

I think, as @steveklabnik said, we should start with the simplest one that is the Rust language site.

As that uses jekyll, there is few simple ways to do that (I’m not aware the way ruby lang is doing it). I’m, right now, doing it in my own blog which I plan to write in portuguese, spanish and english.

I’m following the simple approach from this post, and was also discussed in Jekyll forums.

I think the website will be easier to translate and keep it updated because it is just few pages.

For the book translations I agree that will have same delays between the original update and the translations but that is acceptable, and happens in other languages too.

About translating the API Docs and the compiler, I see it as maximum one “nice to have”, because even other already popular languages like Ruby and Python they don’t have API Docs translated, because generally programmers have at least a basic level of english to read the api docs.

Hi all,

I’m super late to the party, but I’m very interested in doing translation to Indonesia. How can I start to help? We are starting with the website right?

@lunchboxav The website translation PR is stalled, but there aren’t any blockers I think. Somebody just needs to push it forward. If you wanted to rebase that patch it would be a good starting point.

Yup, as the author of it, it’s just that I have not had the time.

I would recommend re-doing the work rather than literally rebasing; we’ve since added pages to the website, even…

Thanks for replying @brson and @steveklabnik

OK, just to clarify (I’m afraid to break things), what I need to do is clone the existing rust-www repo, make a new branch, do the translation and then submit a PR?

Don’t worry, you can’t break anything :smile:

You have the process exactly right.

Alright, cool. Will do it then :smiley: Any convention for the branch name then?

We don’t have any official conventions.

It’s been a while, but we just merged initial work on the infrastructure needed to translate the website:

See it live at which should redirect you to !

Hello, I’d like to localize docs in French. I am contributing to MDN for JS and other docs. In order for “API-like” pages not to stale too much, we use doc status pages for l10n and for English. I don’t know if this could work here but it’s a really helpful tool for maintenance (as pointed by @Uther).

(agreed with what has been said for both site and book, no idea for compiler though :/) Looking forward contributing to this :smiley:

1 Like

@SphinxKnight something like that looks like it would be a great resources for Rust translators. It does a common theme in this thread that everybody is afraid of translations going out of date. Do you know how to set up such a system for the website? @jdm mentioned previously a tool that can help.

Even without the change tracking, the website is ready to accept translations now AFAIK. Though I don’t personally know the process involved, I suspect it is not too difficult to work out.

cc @goyox86 @csgui @Uther @maojingkai @douglascorrea anybody interested in either getting started with translations or setting up Pontoon to work with the website?

Hey @brson!

I’m interested in translating to spanish. I can try to setup Pontoon to work with the website but I have no idea of where to start :slight_smile:

Hi @goyox86! Here are instructions for setting up a project to work with Pontoon. I haven’t looked at them in detail but it doesn’t look all that complex. The #l10n IRC channel is a good resource for getting help. Also #pontoon.

@goyox86 I’m told that Pontoon is not a suitable solution for this. It is purely for localizing small strings, more like application localization than document localization. So let’s scratch that idea. Furthermore, it seems that the Mozilla localization team doesn’t have a solution for managing changes of localized documents. So I guess we’re on our own. I do think we should not let that hold us back from getting started localizing though.

@SphinxKnight can you describe a bit about how the localization process works for that doc status page? The MDN documentation seems similar with what we’re doing - full docs, not small strings. What does it consider out-of-date?

That particular solution looks like it’s tied directly to MDN. What might we do instead?

Hi, basically the doc status page is the result of:

  • crawling the structure of the English (en-US) doc tree
  • for each page in the tree:
  • fetching the metadata of the en-US page
  • for the locale X, fetching the metadata of the locale page
  • if the English version is younger, state the X version is out of date and display the delta between both dates

This is very basic and doesn’t convey the importance of an edit (e.g. a single typofix in English cause every corresponding “locale” page to be displayed as out of date…)

And yes, this is tied to MDN tools and database… One could maybe work the same by fetching the data from a repo or a list of repo.

1 Like

I see that has been closed as it was considered too early to internationalize the compiler, yet at the same time the recent “Rust Platform” post which emphasized the need for making it easier to get into Rust made me think that the language barrier might really be a show-stopper.

I’ve worked with on a website before which had “dynamic” translated text, and I do understand the pain there is in finding a good framework for this, and the decision from Niko that it’s too early to translate “dynamic” error messages right now.

There is, however, one option we could entertain: putting in place a rudimentary system to have the translated version of the long forms of error messages (displayed by the --explain option).

Unlike the “dynamic” error messages which need to splice in multiple pieces, the --explain text is purely static. There is therefore no need for complicated scripting/formatting shenanigans.

I could imagine a rudimentary system in place with just bare text files:


where default.txt would point to either en-US or fr-FR (in this scenario) and explain.txt would contain the rudimentary format:


    Some explanation text in the appropriate format


    Some other text
    in multiple lines

(or something equally simple).

It should be (relatively) easy to put in place, and a simple tool comparing the vN and v(N+1) version in en-US (assumed to be the reference) and in xx-YY would point all missing translations, or non-updated ones.

Also, even if the format is scraped in the future once the compiler gets a “real” i18n framework, it should be relatively easy to create a script that converts the existing translations to the new format so no translator work would be lost.

Note: on top of the compiler, it should probably also require some rustup/cargo work to setup the “default.txt” file and fetch a translation from the web.

As mentioned, it would be rudimentary, but I imagine that for someone not too proficient in English who is confused by the error message having the explanation be provided in their own language might really ease their work.

What do you think?