Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Translated of README.markdown and CONTRIBUTING.markdown into Japanese. #2081

merged 1 commit into from

6 participants


I translated README.markdown and CONTRIBUTING.markdown into Japanese.
But I didn't know the following...

  1. How to create a NEW document.
    • The rule of the filename.
      • I was named " *.ja.markdown ".
    • Where placed NEW document.
      • Same as " *.markdown " at the project root.
  2. The rule for translating text.
    • I replaced text from English to Japanese after I translated original text.

I've read CONTRIBUTING.markdown and "Updating Documentation" of .
I will follow the rules.

@parkr parkr added the Documentation label

What do you think about putting these in a folder called docs?

@kansaichris, would you be willing to read these over and advise as to organization of translated core documentation? Would be most appreciative. :heart:


I think putting these into a docs folder would be fantastic.

@parkr parkr merged commit d6c8294 into jekyll:master

1 check passed

Details default The Travis CI build passed

Thank you for merge.

Next, I'm going to translate the docs of site/docs/*.md.

Where should put translating docs ?
docs/jp or site/docs/jp ?


For the site, it may be more productive for you to do what @matheus has done with

@mattr- and I can't read or write Japanese, so we'd prefer not to have to maintain it. :smiley:


I personally think that translated versions of README and CONTRIBUTING should be placed in the root directory where they are easy to find—ruby/ruby already follows a similar convention for its README.

If you would prefer not to maintain translated versions of the entire Jekyll website (site/docs/*.md), a fork for each language sounds like a reasonable solution to me. To make it clear which forks are "official", though, might I recommend that they be owned by the Jekyll organization?


@kansaichris so they'd be and in the project root, right?


@mattr- Yeah, that sounds about right. Of course, because the original (English) files use the .markdown extension, I would vote for and You could replace jp with ja if you'd like—I'm not entirely certain which is the most appropriate (though I probably should be).


@kansaichris :heart: Thanks!


Just testing the waters, but what do people think about adding information for translators in the README? I could submit a pull request with some preliminary wording if you'd like.


@kansaichris I think that's a fantastic idea. My biggest worry is maintainability, however – I can speak German well enough to look over a PR and I could fumble through a pull request for a Welsh translation, but Japanese is well beyond my current linguistic abilities. What are your thoughts on this? Should we separate out doc translations so the onus is not on @mattr- and I to maintain docs in a language neither of us can speak, or do we keep them around here with the disclaimer that they aren't actively maintained by either of us?


@parkr That's a good question. To be clear, I only think that translations of the documents in the root directory (like README and CONTRIBUTING) would ever belong in this repository. Translations of the Jekyll site itself probably belong in forks, possibly owned by the Jekyll organization. This would really reduce the number of pull requests with non-English content that you'd have to deal with.

My only concern is that a poor translation could hurt the Jekyll name/"brand" without you or any of the other active maintainers being aware of it. I agree that a disclaimer would be really important to dispel any potential confusion about which information is canonical and which is not.


Thanks a lot.
First, I would like to translate documents on my repository.
(I would like to discuss with my friends (can read Japanese) whether or not my documents is good translation. In the range that it does not affect the Jekyll organization. )

Last, If I have finished translating overall documents, then try to mimic the repository method of @matheus.

Is it OK ?


I think that's a great solution for this.

I agree with @kansaichris. As translations mature a bit, I want to start pulling those translated sites into the Jekyll organization, similar to how Boxen does it with the various add-on repos forked from other people.

Thanks for translating! :heart:


First, I would like to translate documents on my repository.


@gosyujin For the record, that repository is, correct?


@kansaichris That's right.
However, that repository is works in progress...

  • I don't have a custom domain still.
  • Original documents has been pushed in docs/ .
  • etc.

I had been consider how managed.
Therefore, it may be a completely different repository.


I don’t want to ruin the party, but translations are a huge waste of time. Foreign coders don’t trust them, because translations are always bad maintained. Please read The Ugly American Programmer by Jeff Atwood for better understanding.


Good Post! But even Jeff Atwood translated the Stackoverflow to Portuguese
There is life and people besides English!


Thank you for important advice.
I added notes to the following in index.html.

  • It describes 'revision of the translation target'.
  • It doesn't absolutely submit issue and PR on translation to jekyll/jekyll.

I began to translate!


For those of you who don't read Japanese, this appears to be the note in question:

このページは本家プロジェクト 5daf987 時点のドキュメントを翻訳しています。最新内容を知りたい場合は を参照してください。翻訳に関する issue や pull request は本家ではなく へお願いします。

Here it is in English:

This page is a translation of its parent project at 5daf987. Refer to for the most up-to-date information. Please submit any translation-related issues or pull requests to rather than the parent project.

:v: :smile:


Thank you @kansaichris and @gosyujin! :heart:


@kansaichris That' right!
Thank you for explanation!

@melborne melborne referenced this pull request in jekyllrb-ja/

Organization化のための検討 #102

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 162 additions and 0 deletions.
  1. +93 −0 CONTRIBUTING.ja.markdown
  2. +69 −0 README.ja.markdown
93 CONTRIBUTING.ja.markdown
@@ -0,0 +1,93 @@
+あなたは Jekyll に投じるすばらしいアイディアを持っています。
+* **テストなしではコントリビュートはできません。**
+* もし、既存の機能への小さな修正やパッチを作成したなら、シンプルなテストを行います。
+ 現在のテストスイートの範囲にとどまり、そして
+ [Shoulda]( や
+ [RR]( を使用してください。
+* もし、それが新しい機能の場合は、必ず新しい
+ [Cucumber]( の機能を作成し、
+ 必要に応じて手順を再利用します。
+ また、あなたがフォークした `site`
+ 急ぎいくつかのドキュメントを用意し、一度マージを行い
+ メイン `site` の に転送していただければ幸いです。
+* あなたのコントリビュートによって Jekyll の振る舞いが変わった場合、ドキュメントを更新すべきです。
+ それは `site/docs` にあります。
+ もし、 docs に情報の誤りがあった場合、遠慮なく追加してください。
+ すばらしいドキュメントはすばらしいプロジェクトを作ります!
+* Ruby のコードを変更するときは、 [GitHub Ruby Styleguide](
+ に従ってください。
+* **小さなプルリクエスト** に最善を尽くしてください。
+ 簡単に提案された変更はレビューされ、マージされる可能性が高いです。
+* プルリクエストを送信するとき、プルリクエストのボディを賢明に使用してください。
+ 変更されたかどうかの記述、変更の背後にある動機、 [完了したかどうかのタスクリスト](
+ もレビュー時間を早めます。
+テストスイートの実行や gem のビルドのために、
+Jekyll の依存ツールをインストールする必要があります。
+Jekyll は Bundler を使用しており、 `bundle` コマンドを実行すると全ての設定が迅速に行われます!
+ $ bundle
+ $ bundle exec rake test
+ $ bundle exec rake features
+* プロジェクトをフォークします。
+* あなたのフォークプロジェクトをクローンします ( `git clone<username>/jekyll.git` )。
+* トピックブランチを作成し、あなたの変更を含んでください ( `git checkout -b my_awesome_feature` )。
+* ハックし、テストを追加します。必ずしもこの順番でなくてかまいません
+* `rake` を実行し、テストが必ず全て通ることを確認してください
+* 必要に応じて、エラーがないようにコミットを論理的な塊にリベースしてください
+* ブランチをプッシュしてください ( `git push origin my_awesome_feature` ).
+* jekyll/jekyll プロジェクトの master ブランチに対してプルリクエストを作成し、
+ あなたの変更内容と、なぜそれをマージすべきかを記述してください
+私たちは Jekyll のドキュメントについて最善を尽くしたいです。
+あなたが Jekyll に欠けているものを見つけた場合、私たちはプルリクエストを歓迎しています。
+あなたは、 上の Jekyll リポジトリの [site]({{ site.repository }}/tree/master/site) で
+全てのドキュメントのプルリクエストは `master` に向けられる必要があります。
+GitHub の [Jekyll wiki]( は、
+全ての GitHub ユーザがアクセス権を持つことができます。
+* もし、 gem のバージョンがかちあった場合、コミットを分けてください。
+ この方法だと、メンテナが gem をリリースするときに制御できます。
+* jekyll/jekyll の最新コミットに基づいて(複数の)パッチを維持してください。
+ それは適用するためのあなたの仕事で、メンテナがしなければならないことを少なくするのは
+ とてもよいことです。
+* あなたの GitHub issue で [fix], [feature] などのタグをつけないでください。
+ メンテナは積極的に issue を読み、彼らが問題に出くわしたらラベルをつけるでしょう。
+ありがとう! Jekyll のハックは楽しいものでなければなりません。
69 README.ja.markdown
@@ -0,0 +1,69 @@
+# [Jekyll](
+[![Gem Version](](
+[![Build Status](](
+[![Code Climate](](
+[![Dependency Status](](
+[![Coverage Status](](
+Tom Preston-Werner, Nick Quaranto や多くの[素晴らしいコントリビュータ](によって作成されています!
+Jekyll は個人プロジェクトや組織のサイトに最適な、シンプルで、ブログを意識した静的サイトジェネレータです。
+Jekyll はコンテンツを受け取り、 Markdown や Liquid テンプレート をレンダリングし、
+Apache や Nginx やその他の Web サーバに提供する準備ができた静的な Web サイトを完全に出力してくれます。
+Jekyll は [GitHub Pages]( の背後にあるエンジンなので、
+あなたの GitHub リポジトリからサイトをホストするために使用する事ができます。
+## 原理
+Jekyll あなたがするように伝えたことをします ― それ以上でもそれ以下でもありません。
+簡単に言えば、 Jekyll はあなたの道を開け、
+真に重要なもの: コンテンツに集中することができます。
+## 開始方法
+* gem を[インストール](します
+* [使用方法]( と [設定方法]( を読みます
+* 既存の [Jekyll で作られたサイト]( をチラッと見ます
+* Fork し、あなたの変更を [コントリビュート]( します
+* 質問があったら? の `#jekyll` チャンネルをチェックしてください
+## より深く
+* 以前のシステムからの[移行](
+* [YAML Front Matter]( がどのように働くかを学ぶ
+* [変数](を使ってサイトに情報を表示する
+* posts が生成される時の[パーマリンク](をカスタマイズ
+* 人生を容易にするために、組み込みの [Liquid 拡張](を使用する
+* あなたのサイト固有のコンテンツを生成するために、カスタム[プラグイン](を使用する
+## 実行時の依存関係
+* Commander: コマンドラインインターフェース構築 (Ruby)
+* Colorator: コマンドライン出力に色付け (Ruby)
+* Classifier: posts の関連を生成 (Ruby)
+* Directory Watcher: サイトの自動再生成 (Ruby)
+* Kramdown: デフォルトの Markdown エンジン (Ruby)
+* Liquid: テンプレートシステム (Ruby)
+* Pygments.rb: シンタックスハイライト (Ruby/Python)
+* RedCarpet: Markdown エンジン (Ruby)
+* Safe YAML: セキュリティのために構築された YAML パーサ (Ruby)
+## 開発時の依存関係
+* Launchy: クロスプラットフォーム ファイルランチャ (Ruby)
+* Maruku: Markdown スーパーセット インタプリタ (Ruby)
+* RDiscount: Discount Markdown プロセッサ (Ruby)
+* RedCloth: Textile サポート (Ruby)
+* RedGreen: よりよいテスト出力 (Ruby)
+* RR: モック (Ruby)
+* Shoulda: テストフレームワーク (Ruby)
+* SimpleCov: カバレッジフレームワーク (Ruby)
+## ライセンス
Something went wrong with that request. Please try again.