x/website: add support for languages other than English

[ericlagergren]

Right now the docs are only in English. There's some support for languages other than English, but the wiki page is merely a footnote.

Other projects—like React—are attempting this as well. Not only does it give newcomers a (somewhat) easy way to contribute to Go, it also makes Go a more welcoming and inclusive place for non-English speakers. Obviously the English version would remain the "master" version of the docs.

Ideally, golang.org would respect the Accept-Language header or support some sort of en/, fr/, etc. URL path option.

I'm not sure how much of a proposal this needs to be, but it's something I'm willing to put further thought into if needed. (It's not a language change or anything, so I didn't write out a full proposal.)

Projects with their docs and/or websites in multiple languages:

• React
• Rust
• Python
• Java (sorta)
• PHP
• JavaScript (via MDN)
• Perl (third party)
• Ruby
• Babel
• LaTeX
• Scala (like how Go currently does it, but more uniform)
• ...

[cznic]

With full respect to everyone's choice of which language to use and when, in my experience using any other language than English to study programming/CS and/or learn from the documentation makes that programmer less capable on the long run - and vice versa. (I'm not a native English speaker.)

[ericlagergren]

@cznic that's a good point. As a native English speaker I don't have much experience learning to program in a non-native language. Personally, I've noticed that it can be more difficult to "concretely" learn things in a non-native language. But I've also had the luxury of having most everything I needed in my native language.

That's neither here nor there, though. I don't really believe it's Go's job to require its users to adhere to what we (general "we") believe to be best practices that are unrelated to the language itself.

[dominikh]

How will the Go team review contributions in other languages? And who guarantees that they're kept in sync with changes/additions to the standard library?

[ericlagergren]

@dominikh

How will the Go team review contributions in other languages?

In this case, unless the Go team member speaks that language, they'll have to sanity check it (Google translate, etc.) Ideally, you'd have a community member double-check the additions.

And who guarantees that they're kept in sync with changes/additions to the standard library?

IMO the best way to start would be to start on the more static parts: golang.org/, golang.org/doc/, golang.org/doc/contribute.html, etc. If that's too difficult to keep in sync or the whole thing flounders, it can be scrapped.

Alternatively (or additionally), a simple disclaimer can be put at the top of translated pages. (Like I mentioned before, English is the 'master' version.)

As an example of what the React project is doing: facebook/react#8063

[ianlancetaylor]

CC @spf13

[Sunshine40]

With full respect to everyone's choice of which language to use and when, in my experience using any other language than English to study programming/CS and/or learn from the documentation makes that programmer less capable on the long run - and vice versa. (I'm not a native English speaker.)

@cznic While I agree with you on the less capable on the long run part as a matter of fact, unfortunately acquiring adequate English proficiency for programming doc reading and writing (writing part explained in #57254) could never be a suitable choice for everyone.

Learning a programming language takes effort, but the difficulty is lowered not only by programming guides usually more interactive than conventional natural language textbooks, but also by the toolchain giving constant feedbacks whenever you make a possible mistake.

Imagine learning a programming language without the access to an IDE or even the access to the build cmd for most of the day, and try to write a program with 1000 lines of code (by no means a huge task) which only need minor fixes before it could build and run without major bugs – that would simulate learning English without a native English speaker as a teacher.

In comparison to the effort needed to require a whole dev team to be English proficient, translating documentation for a specific task is absolutely a more realistic. And more realistic tasks get higher chance to be fulfilled than those mission impossibles.

(Besides, English just happens to be the language with most speakers in the world, thus tech docs for international cooperative jobs naturally comes with an English version.
But there're far more non-English speakers than English speakers (non-native speakers counted, see: Most-spoken languages, CIA, 2020), and rendering English as an essential skill for a capable programmer is somewhat arrogant (as an English speaker, no matter native or non-native).)

If, in an alternative universe, Chinese or Hindi happens to be the default language for tech docs, while English speakers still take 10% of the world, does it make sense to all these English speakers to learn Chinese/Hindi before they are regarded as capable of participating in an international cooperative job?

[Sunshine40]

So my point is, English proficiency is surely helpful for a programmer to take part in an open source project where documentation other than the English version doesn’t exist yet, but the existence of proper translation would certainly help more.

And believe me, the reason why only a few open-source go projects have translations for documentation, is the lack of a standard paired with tools on this topic.

When creating a guide for an existing go package facing non-English speakers, individual work could be in the form of a blog post, or a separate doc repository. By such means, doc translations could be littered everywhere, and without version tracking.

I’ve used .NET and PHP, both come with a variation of translations of the official documentation.
Apparently an automated workflow is designed to keep the translations up to date and make translation jobs easy. But these languages don’t have a documentation standard when it comes to third-party package publishment.

Go, on the other hand, has the tool to standardize doc generation if one wants to publish a package.
It looks like only one step from adding translation support similar to how they make .NET/PHP official doc internationalized.
At the current state, the absence of this part just effectively chopped the non-English speaking Go community off the English-oriented Go open source community (though technically they can publish packages with non-English doc), which is a shame IMO.