Thanks, all. Excited about this discussion and the momentum here. I don’t want my 2¢ to weigh any more strongly than anyone else’s, to be clear. My goal is to:
- empower and enable those who are excited to take this on
- provide the structure and resources needed to reach the next milestone(s)
- as well as achieve long-term maintainability
- help with sanity checks and guidance, especially when it comes to scope and roadmap
- nothing is more discouraging than taking on too much, too soon.
So those are the things I’m trying to suss out. And definitely deferring to you all to tell me (us) what best will achieve each of the items on this list.
I think my primary reason for suggesting this setup is that it’s an easy way to manage the contributors who are managing a translation. Each translation repo can be assigned to a set of maintainers by using GitHub Repo User permissions. There are labels, issues, Project Boards, integrations, etc.; all of which can be fully managed by the specific team.
The intended effect --> we can scale the teams without having to add layers of “management”.
What to translate? How to Manage Translations
Again, I’m getting caught up to speed, but it seems like this conversation is seamlessly going back and forth between translating a 1) website vs. 2) a document. Regarding the former, if we want to offer true i18n for a website, we should be looking at available CMS solutions with content publishing and versioning workflows.
and that each of those is its own self-contained site
Unless I’m missing something, I strongly disagree we start with this goal of translating an entire site. RWJS.com is updated almost daily on average. So every way I’m mentally slicing how this could work feels like a lot of overhead right out of the gate. However, I have no experience with translation tools and automation. If it’s true that 90% of the work can be done by machine and automation, then that’s a different story. Although even in this case I’d still argue to start with a small scope initial milestone before taking on a whole site.
First Milestone == Translate one Document
I’m intentionally trying to force the scope to be on translating a single file, which is
- I think it’s the most bang for our buck
- I think it’s near-term achievable
- I think it’s long-term maintainable
- Provides margin for learning, mistakes, and low-cost iteration
Setting URLs and Page Meta
The site already pulls in content from the Framework repo (e.g. the introduction Readme.md). I’ll try to be more specific about what I’m suggesting:
We’ll need to handle Page Meta (React Helmet?)
We’ll need to handle a UI Language switcher. Admittedly, this could be where I’m oversimplifying things. But maybe it’s just a one-time, in-content link on the first page of the tutorial that gives you links to Tutorial introduction page for a specific language.
In the future, depending on whether or not a CMS is implemented, the subdomain option for full sites could definitely be the way to go. I just don’t think it’s the way to start.
Ah, for some reason I thought you were a French speaker as well @clairefro Not sure how that got stuck in my head.
Anyway, again I don’t have a language preference other than choosing one that the initial team is very comfortable with.