Translations for Rust


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:


@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.


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?


@matthieum I like the idea of translating those extended errors specifically.

I’m not sure what their fate is though. Part of the recent error message RFC was a mandate to start converting those to dynamic errors as well, which could complicate the picture. I suspect though that the resulting system will be relatively self-contained, in particular defined in templates instead of directly in the code. That could still be relatively easy to internationalize. cc @GuillaumeGomez @jntrnr something to think about.


@brson: I proposed translation a while ago (with @Manishearth) but rust people refused it. Is it getting back finally? :stuck_out_tongue:


I had good experience using Transifex for managing and contributing translations. It would also keep list of translators centralised.

EDIT: though, I guess, anything of similar nature works.


I’d love to help making a Danish translation.