clean up blog for i18n

[chadwhitacre]

I merged the i18n work #52, but it causes problems with the blog. Any chance you can take a look at that, @kyzh?

[kyzh]

Sure, let me get the latest code and see what is the problem you see. Give me 15-20 minutes to do so.

[chadwhitacre]

@kyzh I've added you as a collaborator on the repo. Please feel free to work directly on master for now. While we're starting out I think low-friction is the way to go. We'll get into a more solid PR rhythm down the road.

[kyzh]

Thanks, makes it a lot easier.

[kyzh]

@whit537 was the issue Included file 'pledge.md' not found when you use jekyll serve ?

[kyzh]

I fixed that problem. I'm now looking at what else needs a bit of love to work wit the translation plugin.

[kyzh]

@whit537 let me know if it is indeed fixed for you.

[kyzh]

I fixed the code: it now works locally :tada: But the github pages don't understand the plugin :frowning:

Github report the problem via email like so:

The page build failed with the following error:

The tag `translate_file` in `join/index.md` is not a recognized Liquid tag.

For information on troubleshooting Jekyll see:

  https://help.github.com/articles/using-jekyll-with-pages#troubleshooting

If you have any questions please contact us at https://github.com/contact.

Will try to see if i can get traction on this.

[kyzh]

It is written on jekyll's doc that gh-pages wll not make use of the plugins: http://jekyllrb.com/docs/plugins/

Plugins on GitHub Pages

GitHub Pages is powered by Jekyll, however all Pages sites are generated using
the --safe option to disable custom plugins for security reasons. 
Unfortunately, this means your plugins won’t work if you’re deploying to GitHub Pages.

You can still use GitHub Pages to publish your site, 
but you’ll need to convert the site locally and push the generated static files
 to your GitHub repository instead of the Jekyll source files.

Should we publish the generated content only to gh-pages ?

[chadwhitacre]

That is super sad. :-(

[chadwhitacre]

@kyzh How about we store the built site in this repo?

[kyzh]

I was thinking, use a branch for jekyll and the master branch for the built site. That might work as only master is used by the gh-page. I cannot try today, will try tomorrow. How does that sound @whit537 ?

[chadwhitacre]

@kyzh What's the value of having the built site on a separate branch? My understanding is that we can simply commit the _site directory (and take it out of .gitignore) and GitHub pages will serve it. No?

[kyzh]

I think the gh-pages will still block on the plugins I need to do some test.

How about two repo, one for jekyll and one for the generated code. It is easy as setting another remote to push code to.

[chadwhitacre]

@kyzh Welp, looks like you're right. Sorry for doubting you. :-)

I pushed the built _site directory, and GitHub didn't pick it up. How about we rename this repo to www.opencompany.org, and then we create a new opencompany.github.io repo for the built site?

[chadwhitacre]

I've taken _site back out of this repo.

[chadwhitacre]

@kyzh Actually, I just force-pushed master to back out the ill-advised _site maneuver. Sorry for the hiccup.

[kyzh]

@whit537 I like what you said in https://github.com/opencompany/opencompany.github.io/issues/60#issuecomment-32555027 I think that is the right answer. It is a nice and simple workflow to understand.

[chadwhitacre]

@kyzh Done!

[chadwhitacre]

Over here I have this directory layout:

opencompany/
opencompany/opencompany.github.io/
opencompany/www.opencompany.org/
opencompany/www.opencompany.org/_site -> ../opencompany/opencompany.github.io

That is, I have the deployment repo symlinked at _site in the source repo clone, so I can use jekyll locally and end up with files in the right place, ready for deployment.

[kyzh]

:clap:

[kyzh]

I did a quick "how to": https://github.com/opencompany/www.opencompany.org/wiki/How-to:-Setup-for-Contributors

[chadwhitacre]

!m @kyzh