本家サイトからenjaへリンク追加の提案
mitsuruog opened this issue · comments
Links-and-Suggested-readingのPull&Req処理しているときに気づいたのですが、Underscoreの本家ドキュメントに**語翻訳サイトへのリンクがありました。
Underscoreの翻訳が完了した段階で、本家にenjaリンク追加のPull&Reqしてみたいと思うのですが、いかがでしょうか？
そうですね。本家へのリンク追加はやりましょう。
向こうにリンクがあってこそ、だと思いますので。
そうすると、gh-pagesなど作る感じですか？
出力の形式についてはどうしたものかは要検討ですね。
折角だからgh-pagesを使って出力したらいいんじゃないかとは思ってますが、
楽な方法がほかにあるかは議論したいですね。
そうですねgh-pagesブランチを切ってGithubPageでやるのに賛成です。
個人でJasmine翻訳した時に実績あるのですが、
この時は本家をForkしてgh-pagesのindex.htmlを手で書き換えたので、.mdからビルドする方法など、もっと効率の良い方法があったらぜひ教えていただきたいです。
和訳版 http://mitsuruog.github.com/jasmine/
本家 http://pivotal.github.com/jasmine/
gh-pagesについては、色々実験していた残骸があるのですが...
https://github.com/ahomu/gh-page-test
docs以下の.mdをコンバートして、jekyllで使用可能なフォーマットに変換（Rakefile参照）すると良いかなぁと思っています。
上のリポジトリの例になりますが、submoduleとして別々に参照を持っておけば、バージョン別のドキュメントも単一のgh-pages内で管理できるかと。
- _revs
- master (安定版の参照)
- edge (最新ブランチの参照)
あとは
・プロジェクトごとにgh-pagesを持ってメンテするか
・enja-ossでgh-pages専用リポジトリを作って一括でメンテするか
についても悩み所です。個人的には後者のほうがリソース集中しやすくて良いと思いますが。
jekyllが楽そうですかね、やっぱり。
あとはプロジェクトごとにgh-pagesを持ってメンテするか、enja-ossでgh-pages専用リポジトリを作って一括でメンテするか、についても悩み所です。個人的には後者のほうがリソース集中しやすくて良いと思いますが。
これは悩ましいですよね…。enja-ossの方が情報分散しないので、良いのかなと個人的には考えてます。
そうなると
enja-oss/README#15
こちらとの兼ね合いもありそうです。
gh-pagesを使うのであればJekyllでいきましょうか。
類似の機能が少ない https://github.com/felixge/node-romulus などでもいいですけど。
Jekyllであれば私も多少は覚えがあるので。
メンテの件について
出力専用のレポジトリを作れば、
enja-oss/README#15
でやろうとしているenja-oss全体のプロジェクトホームページとの兼ね合いも解決できるかなと。
@ahomu 時間が空いたら、適当にレポジトリを作成して、テスト的にgh-pagesの作成をしちゃってください。
@studiomohawk わかりました。リポジトリを作成して、gh-pagesのスケルトンになるあたりまで準備進めますね。