Finish foundations for localization

[susanjrobertson]

We have the beginnings in PR #120 and need to flesh out and finish for the collection of methods.

I've talked with @leobalter so I get what needs to happen next, just waiting to decide exactly the best route to do this work.

[susanjrobertson]

So, I think we have a problem with the work that's been done and I'm not sure the best way around this. The plugin that @leobalter used for the localization is fine for pages, but there is not support for collection as this time: https://github.com/Anthony-Gaudino/jekyll-multiple-languages-plugin/issues/72

Since our main content, the methods, are all in a jekyll collection (which I think is the right thing since they aren't dependent on dates) I'm not sure the best route forward. Do we keep the plugin for the other pages and then do something else for the collection of methods? Do we not use the plugin and do the work by hand? any thoughts or ideas @leobalter or @tkellen?

[vlandham]

i think if you just had each set of localized files in their own sub-directory, then you could point to the correct set via the url...

i.e.:

http://odk.com/en/

would be for the english index.html.

so you would have to do a bit of work with the layouts, but otherwise each translation would be nicely siloed and you could (at least initially) easily deploy to gh-pages.

for layouts, one idea could be to split out the nav and footer into separate _includes and create a different one for each language... like nav.en.html. Then use front matter to indicate which language _includes should be used.

[susanjrobertson]

That's the part I'm not excited about at all. The plugin did the nav, footer, etc for us and it made it easy to do so. I'd rather not lose that portion of it and then have to essentially hand roll that for all the translations.

But would love more thoughts from anyone else who has dealt with this in the past or has ideas or knows jekyll better than I.

[vlandham]

as an alternative, you could just put the translations for the various languages for the header / footer in the front matter of those _includes. Then you could just reference the appropriate language's section (i believe) by passing a variable to the include and using that within the page

{% include footer.html param="value" variable-param=page.variable %}

from https://jekyllrb.com/docs/templates/

this would just move the translations from a standalone file (as in the plugin - right?) to being part of the front matter of the file in which they are used. Both are similar in how they would be used.

[susanjrobertson]

I want to get what we have out the door and think about this some more. Since I'm fairly sure we always want opendesignkit.org to point to the main english page, we can always make subfolders of the other languages when we are ready and deal with the templates and variables at that time. This means our current work isn't held up and it also means we won't have url issues in the future since the english urls won't change.

If there are objections to this, let me know, otherwise this will wait until after we ship the site.

[iamjessklein]

To do localization, there are three parts:

1. create a framework for localizing the site
2. localize the site
3. localize the methods

In order to successfully close this ticket we should have part 1: create a framework. Re-pinging @leobalter @isaacdurazo on this.