Translation project of Rust documents

I previously proposed adding a subrepository for translating documentation to Rust, but it was closed due to lack of capacity to maintain it on an ongoing basis.

So, my other idea is to set up a GitHub organization (e.g. rust-lang-translations) and domain (e.g. rust-lang-translations.org) for translations, and centralize all documentation translations there.
If this proves that there are sufficient translation resources, we can use that as a basis to consider merging it back into Rust itself,
but if no one joins, we can conclude that there was no demand for translations in the first place.

If you have any thoughts on this idea, please let me know.

I generally like the idea of i18n, but I am not sure how useful it is in the programming language documentation domain. My native tongue is German, and I also speak a few other languages, but I'd find a German translation of the official Rust docs not very useful to me.
In the tech and IT industry English is the established de-facto standard, so this is what I'd use.
Also Rust itself uses English keywords and naming in the standard library.

That you don't need it is not an argument against translating more of the Rust documentation. There's several translations of the book, communities all around the world that don't use English for their communication, some conferences where the talk are in not-English or provide live-translation from English. Don't take your own knowledge of English as the basis on what should exist for others.

Maintaining translations of constantly changing material is challenging, but people still do it. Because they want to and because it enables a whole other group of people to learn and participate too.

It is not, and I never suggested anything else. I merely raised the question of its usefulness from my point of view.

Any action I perform is based on my experience, my beliefs and my knowledge. Other people may have other experiences, other beliefs and other knowledge. I rest my case that a German translation is not useful to me. I said nothing more. It may be useful to somebody else, but I cannot imagine to whom. Anybody who understands the "where T: Trait" clauses and understands the English standard library trait, struct and function names, should have a sufficient amount of knowledge of the English language to also follow the documentation. But this is just from my experience and I might be wrong about that.

I have also experience of maintaining translated docs, namely the German Arch Linux wiki.
Nowadays, it is in most topics out of date and has significantly diverged from the official English Arch Linux wiki. The issue is that those people who understand English use the English wiki and are the only ones that may translate it for non-English speakers. If they get tired of it and leave, the docs get left behind and become outdated. Those who rely on the translations cannot update it by themselves due to lack of knowledge of the original language. This is my experience.

So hey, translate away. I won't stop you.

2 Likes

I think "useless for me" is reasonable response.
This is because almost all online Rust community including this forum, GitHub, Zulip, and so on is a gathering of people who can communicate throught English.
I think the actual users of translation belong each language community, and almost of them are not in this forum.

Having said that, there is not another appropriate community to discuss about this idea, so I posted in this forum.

1 Like

I think this is a very important point.
For example, TRPL in Japanese was outdated for a while, but new translatiors came last year, and updated it. If local language community grows, needs of translation increases and new translatiors come. I think a key point that makes this cycle possible is consolidated workspace.
Japanese Rust community has rust-jp GitHub organization and Japanese translators works on the organization. But depending on language, there is not such organization, each translators works individually, therefore continuous translation is difficult. Even if a language community has such organization, auxiliary works like writing automated script can't be shared through all language comminities, and we must do it repeatedly and invididually.

I think there is a possibility that centralized organization and workspace for all translations improves the current translation workflow.