Localization

[codehag]

Hey folks,

We have been running the website for about a year, and I think we are getting to the point where we should open it up, and make it more accessible internationally. That means localization. This issue will be used to track and plan that work.

[codehag]

Some people I want to get into the conversation to get it started are @chicoxyzzy @septs @hemanth and @xtuc -- any ideas here?

The first one I am thinking of, is there is the fantastic work done by JSCIG. If they are willing, I would love to work together and possibly share translations?

[littledan]

cc @pusongyang

[littledan]

I also want to suggest that we localize the TC39 Discourse, to allow discussions in non-English languages for early proposal design, to make things more comfortable initially.

[hemanth]

Sure @codehag count me in!

[septs]

https://developers.google.com/search/docs/advanced/crawling/managing-multi-regional-sites?hl=en

[septs]

The first one I am thinking of, is there is the fantastic work done by JSCIG. If they are willing, I would love to work together and possibly share translations?

Yep

[codehag]

thanks @septs! for the pointer.

Reading it, there is a distinction between language and region. Due to this being a volunteer effort, for now, I guess we will approach this with what languages we have available to us. This will unfortunately self select to current tc39 delegates, but hopefully it will encourage others to do localizations.

I can probably cover german and some russian (but I will need help). We have a strong representation of chinese speaking delegates. Do we have other languages we can cover in an MVP?

Based on those languages (I will use german as an example here), we can either do a subdomain de.tc39.es or a directory tc39.es/de (I don't have strong opinions, one or the either is fine). To complement that, we should have a clearly visible drop down for changing the language. I don't think that we need to automatically detect where the visitor is coming from (and this will be complicated with European law) but that can be a stretch goal. For this drop down, we will need a design.

With language selection in place, we can then leverage the existing infrastructure on jekyll. The goal is to keep this change as light weight for now as possible.

With this in place, the next question is data structure. I propose that we update our data ymls (https://github.com/tc39/tc39.github.io/tree/master/_data) to have the language in the name, ie stage3.de.yml, and keep localizations separate this way. Would that be reasonable? I suppose, if we are missing a language we can fall back on english?

[chicoxyzzy]

I'm willing to help with Russian localization of website and docs (I think that we should translate "TC39 process", "How we work", and maybe something else) and help supporting Russian-speaking Discourse too if we'll have it eventually 👍.

We may want to use a Unicode BCP 47 locale identifier, i.e. de-DE instead of de

[septs]

For this drop down, we will need a design.

I think we need user experience designers.

[xtuc]

I don't know how easy it would be to make subdomains work with GitHub pages. Directories seem easier to implement.

Documents like "TC39 process", "How we work", etc doesn't seem to change too much. On the other hand proposal's content could change relatively often, especially in the early stages. If the data is crawled/imported automatically i'm concerned that translation will become out of sync. Which is probably less helpful than the original english version.

[chicoxyzzy]

What do people here think will be the best approach for multi-lingual forums: should they be subforms of es.discourse.group or a separate instances?

I've just started to work on translation of the Code of Conduct to Russian and I think that it could be a good starting point for any localization =)

UPD: CoC translation is almost done in chicoxyzzy/code-of-conduct#1. There are a few complicated parts I need help with,

[ljharb]

The main concern i have is that translations stay up to date - what are the plans to ensure that’s the case?

[chicoxyzzy]

For documents on GitHub there definitely should be some automation. When original document file is changed, a new issue should be created for translated documents.

[codehag]

I think as @chicoxyzzy suggests, we can have an action to signal that a translation needs updating.

However, the biggest churn will be proposals. Since we are only interested in stage 3 proposals, and only their descriptions and titles, I don't expect much change after a translation is made.

[septs]

@codehag I think the only needs to translate the proposal title (make readers interested)