Internationalization (i18n)

[Fishrock123]

We should make a setup with #22 where we can have language-specific content (markdown) files that build to /lang/ directories we can serve.

cc @laosb @snostorm

[aredridel]

Good stuff. Keep it simple: what you're doing is.

Where you'll have pain is keeping track of what needs updated translation when updating the source document. Don't go wild, keeping it to paragraph granularity is all you need.

Very few static site generators have special support for this but since you've 1:1 mapping of source to target files, you don't need support.

[italoacasas]

i am going to start translate all text to spanish version, and wait for us to have a decision like working in this

[italoacasas]

with angular is very simple this thing

[therebelrobot]

Oh, agreed on the angular part, though we most likely will be avoiding large frameworks for the frontend, the consensus currently is to keep it light and easy for new node devs to hop in for assistance without much learning curve.

Thanks for the assist on the translation. We'll be meeting as a web team sometime this or next week to discuss stuff like i18n, and once we have a better structure in place, we'll definitely need all the help we can get with stuff like that.

[Fishrock123]

I very much do not want to use angular, though what makes it easier in it than another frontend framework?

[aredridel]

Angular does have i18n not as an afterthought.

However, for writing frontend apps with i18n, react, dust and handlebars have great i18n support via yahoo's formatjs tools.

[therebelrobot]

It has a lot of the modules like i18n already built by the community, more or less just plug-n-play for language content. It's dep injection is really good, as is it's data-binding. I'd be happy to show you a good example of an angular/browserify repo if you want to take a look at the code base

[aredridel]

I think the concerns of a content site vs a web app are almost completely different though.

[Fishrock123]

Yes. I think we are going to stay away from front-end frameworks. (put any further discussion on that in #22)

[therebelrobot]

Since i18n will be handled in the build process, should we then close this issue? Or should we leave this open for future translators to see?

[Fishrock123]

Nah, let's leave it for people to volunteer (i.e. help-wanted)

[therebelrobot]

Kk. Let's talk about a CONTRIBUTING doc in the next meeting and including info about i18n in it, and we can add a link to your original post above linking to it?

[yosuke-furukawa]

+1 !!
I have a motivation to translate English to Japanese.

[italoacasas]

Spanish...

[Fishrock123]

@italoacasas is uh, that the shortest understandable word for 'docs'? That certainly won't fit on mobile. :)

Nice work though!

[italoacasas]

yea doc is a valid word in spanish :)

[julianduque]

@italoacasas spanish version is on github? would love to help on translation for both docs and website

[mikeal]

I want to unblock this.

I know that we're working on tooling to make this easier but we have people getting excited about this kind of work so I'd like to unblock them ASAP.

Current thoughts:

• Create directories for translated versions of index.html, es6.html and faq.html.
• Once completed link to each translation at the bottom of each page.

Yes, we'll have to move these to markdown later but we already have to do that for the english version anyway. At least this way we can knock out the translation work and all we have to do once the tooling lands is change the format.

Thoughts?

[we11adam]

@mikeal Just moving to markdown might not be good enough, IMHO. People can screw it up anyway, technically. How about we introducing gettext support?

[Fishrock123]

This is alive and well. \o/