Translations

[BonsaiDen]

Things that need to be done before any translation can be started.

1. Finish the new design and build scripts and finish support for multiple languages
   This is now completed! Please see the wiki for translation instructions

Everyone who is interested in a translation, please leave a comment on this issue.

[bebraw]

I can translate the whole to Finnish (kind of obscure language but better than nothing I suppose :) ).

[BonsaiDen]

I'll mist likely attempt a German translation, which will suck. My English is by far better than my German...

[oozcitak]

I can do a Turkish translation. Let me know ;)

[caio]

Just let me know when and I'll gladly provide a Portuguese (from Brazil) translation.

Cheers!

[svnlto]

I can help with the German translation.

[scriptin]

I can translate this into Russian. As an option, it's possible to make a crowdsourcing translation at http://www.translated.by/ , there are some folks who's intrested in JS.

[dionyziz]

I can help with the Greek translation.

[ZhangYiJiang]

Translating instructions are now available on the Wiki - now go forth and translate!
https://github.com/BonsaiDen/JavaScript-Garden/wiki/Translating

[BonsaiDen]

It should be noted that the wiki is referencing to the not yet published version of the Garden that resides on the next branch.

[caio]

Cool. I've noticed you require two-letter-code for the localization but in several cases (mine included) the appropriate would be using pt-br (or pt_br, or a case-mix) since Brazilian Portuguese is a variation of Portugal's language.

There doesn't seem to be any limitation (code-wise) for using five-letter acronyms for the translations, can I use it?

[ZhangYiJiang]

@caio There's no technical reason why that would not work, you should be able to use it

[aishek]

Please, let me translate it into Russian! )
It's awesome!

[caarlos0]

I can help with pt-br :)

[svnlto]

let me know if anyone wants to join doing the german translation.

[caio]

Okay, I've started playing around with the translation and have some impressions to share.

Maintaining a translation up-to-date will be too hard following the current schema as there won't be a way to know if there are translations for each "paragraph" from the original source.

Also, keeping track of the changes on each file is a big burden for the translators. I mean, if someone starts a translation today, she'll need to keep track of every commit that modifies the sources and check if it applies to her ongoing translation. IMO, following this workflow quite dangerous for both sides.

My point is that the best way to do it would be following the most common form of translation backend: gettext. I'm not aware of any real-world usage of gettext and html, but it shouldn't be too hard to hack a way to use it in this project. This would allow us to:

• Have a single point of translation, instead of a whole source tree
• Easily detect (miss/un)translated phrases, as they'd fallback to the original version
• An easy starting point for an updated static site version, where languages with missing translations would end up with an "outdated" marker or something

Anyway, do you agree with me? I'll begin investigating a way to use gettext with the current structure but would like to hear your thoughts on that before really digging in.

Cheers!