今回色々トラブったので、大きな問題がなければ、新しくリポジトリを立てて本家からのforkからやり直したいと思っています。

またmasterブランチを随時本家に追随させるために、日本語版の開発はmasterとは別のブランチにした方がいいと思います。

あるいは、昨日の放送でKatzさんから日本語版をパッケージで提供するというアイディアも出ました。この場合は、本家に修正パッチを送る用のコアのリポジトリと、日本語版パッケージの開発リポジトリ、言語ファイルのみの翻訳用リポジトリの3つをGithubで運用することになるのかな？と思います。
個人的には作業も分担できるし、このアイディアがいいなと思いますが、日本語版パッケージでオーバーライドするコアのコードの変更にどう追随するかが課題になりそうです。

夕べはすいません。寝ちゃいました。

本家がmasterならmasterブランチでやった方が良いと思います。
あと、5.5でどうなるか解りませんがパッケージで日本語版を提供する場合、オーバーライド出来ないファイルに修正を加える必要があったりする可能性があります。

でも、出来ればパッケージ化したいなー

今回どうやっても本家に戻せない修正がいくつかあったのが気になったんですよね。日本語がphpに直接書いてあるとか。そういうのをパッケージ化して逃がしてやれば、masterブランチでもいい気がします。

本家がリリースした後に開発スタートするならmasterブランチで開発
リリース前にプルリクエストするなら、master以外のブランチで開発がいいと思います。

それとテスターが足りないと思うので参加しやすいよう

・日本語化ブランチ（英語のままの表記を探しt()抜けなどを修正）
・プログラム改定ブランチ（日本語URL対応など）

など分けて開発するのはどうでしょうか？


今、調べてますが、同じリポジトリをフォークした場合、リポジトリを複数作成できるのか不明です。

> 本家がリリースした後に開発スタートするならmasterブランチで開発
> リリース前にプルリクエストするなら、master以外のブランチで開発がいいと思います。

本家のリリース前に修正してほしい点は送りたいですね。次の放送から始めたい。みなさんいかがですか？

> ・日本語化ブランチ（英語のままの表記を探しt()抜けなどを修正）
> ・プログラム改定ブランチ（日本語URL対応など）
>
> など分けて開発するのはどうでしょうか？

後者をパッケージ化するのが、Katzさんやtaoさんの意見ですね。ぼくも同意見です。異論がなければ、試してみていいんじゃないかと思います。リポジトリも普通に分けられますしね。

languages/ja_JP.UTF8/LC_MESSAGES/messages.po がインストール時に存在していたら、一番初めに言語選択画面が出てきて、インストール画面も日本語になりました（前からでしたっけ？）ので、以下2つの作業は今回は不要なんでしょうか。

http://github.com/concrete54japan/concrete5/commit/5bdda2cda2fb13bd5b79dde5c0de4183208cff87

http://github.com/concrete54japan/concrete5/commit/41bd7a19adc434c3dff0354f0c000d614c2f1a93
↑config_check_complete.php