Long Term Goal: Translate docs into multiple languages

[StabbyCutyou]

To best support the Gommunity of golang gophers using package generics, I need to provide documentation in multiple languages.

To that end, I'd like to solicit feedback on how best to provide an i18n integration with my documentation. Ideas may include something that automatically translates the documents from a source english file, or individuals who agree to be the maintainers of a given language or set of languages.

Ideally, a single source of truth where other languages are generated from would be best, but machine translations can lack subtlety and nuance, and so I'd like to gather opinions on the matter before moving forward.

[fortytw2]

What if you subdivided the import paths, i.e.

import "github.com/stabbybuttyou/generics/de/generisch"

then generisch.G works OK, but you can also import plain ole github.com/stabbybuttyou/generics and use generics.G as to not break backwards compatibility.

[StabbyCutyou]

At this time, the i18n effort would strictly be for documentation purposes.

Releasing a new set of language-specific sub-packages, without the community-driven alias feature, would result in a post-babels-tower-esque fracturing of the theoretically millions of gophers using G under the division of language.

Sadly, as the steward of package generics, I cannot embrace the idea at this time.

However, once alias is delivered, I am happy to revisit this for a generics v2 discussion.

[mrxinu]

I nominate @ellenkorbes for the Portuguese translation.

[vkorbes]

Bring it. How do we do this?

[StabbyCutyou]

I would defer to the wisdom of the crowd on this one! I've never supported multiple languages in a project before - what are the best practices?

For example, a README_X.md, where X is an abbreviation of the language? Is there a way to get github to default to the "native" language based on it's ability to detect via the browser, perhaps?

Let me know what the right move here is, and I'll gladly accept translation PRs!