Merge pull request #20 from renoiv/master

minor fixes

Author: hidenorigoto

gentle-introduction/ja/06-Inside-the-Controller-Layer.markdown

@@ -221,7 +221,7 @@ symfony の内部にご興味がなければ、フロントコントローラー
 >
 >`sfMailer`: メーラーオブジェクト (`->getMailer()`)
 >
->`sfI18N`: 国際化オブジェクト (`->getI18N()`)
+>`sfI18N`: 国際化オブジェクト (`->getI18N()`)
 >
 >`sfLogger`: loggerオブジェクト (`->getLogger()`)
 >

gentle-introduction/ja/17-Extending-Symfony.markdown

@@ -1,7 +1,7 @@
 第17章 - symfony を拡張する
 ============================
 
-結局のところ、symfony のふるまいを変える必要があります。特定のクラスのふるまいを修正するもしくは独自のカスタム機能を追加する必要があるにせよ、変更作業は必然です。フレームワークが予想できない固有の要望を顧客が持つからです。実際のところ、この状況はとてもありふれているので symfny は単純なクラスの継承を越えて、実行時に既存のクラスを拡張する方法を提供します。ファクトリ (factory) の設定を利用することで、symfony のコアクラスを独自クラスに置き換えることさえできます。いったん拡張機能 (エクステンション) を作れば、それをプラグインとして簡単にパッケージにできるので、別のアプリケーションもしくは別の symfony のユーザーが再利用できます。
+結局のところ、symfony のふるまいを変える必要があります。特定のクラスのふるまいを修正するもしくは独自のカスタム機能を追加する必要があるにせよ、変更作業は必然です。フレームワークが予想できない固有の要望を顧客が持つからです。実際のところ、この状況はとてもありふれているので symfony は単純なクラスの継承を越えて、実行時に既存のクラスを拡張する方法を提供します。ファクトリ (factory) の設定を利用することで、symfony のコアクラスを独自クラスに置き換えることさえできます。いったん拡張機能 (エクステンション) を作れば、それをプラグインとして簡単にパッケージにできるので、別のアプリケーションもしくは別の symfony のユーザーが再利用できます。
 
 イベント
 --------
@@ -696,7 +696,7 @@ PEAR プラグインをアンインストールするには、リスト17-17で
 >プラグインスキーマのカスタマイズ
 >
 >###Doctrine
->モデルをビルドするとき、Doctrineによりアプリケーションとプラグインの `config/` ディレクトリにあるすべての `*schema.yml` が検索されるので、プロジェクトのスキーまでプラグインのスキーマを上書きできます。このマージ処理で、テーブルやあkラムを追加したり変更したりできます。たとえば、以下の例ではプラグインスキーマで定義されたテーブルにカラムを追加する方法を示しています。
+>モデルをビルドするとき、Doctrineによりアプリケーションとプラグインの `config/` ディレクトリにあるすべての `*schema.yml` が検索されるので、プロジェクトのスキーマでプラグインのスキーマを上書きできます。このマージ処理で、テーブルやカラムを追加したり変更したりできます。たとえば、以下の例ではプラグインスキーマで定義されたテーブルにカラムを追加する方法を示しています。
 >
 >     #Original schema, in plugins/myPlugin/config/schema.yml
 >     Article:

gentle-introduction/ja/18-Performance.markdown

@@ -76,7 +76,7 @@ symfony において、モデルレイヤーはもっとも遅いという評価
 
 ### Joinでクエリの回数を最小にする
 
-アプリケーションの開発期間において、それぞれのリクエストによって発行されるデータベースクエリの回数を監視すべきです。Web デバッグツールバーはそれぞれのページに対してクエリの回数を示し、小さなデータベースアイコンをクリックすればこれらのクエリの SQL コードが表示されます。クエリの回数が異つねに上昇するのを見かけたら Join の利用を考えるべきです。
+アプリケーションの開発期間において、それぞれのリクエストによって発行されるデータベースクエリの回数を監視すべきです。Web デバッグツールバーはそれぞれのページに対してクエリの回数を示し、小さなデータベースアイコンをクリックすればこれらのクエリの SQL コードが表示されます。クエリの回数が異常に上昇するのを見かけたら Join の利用を考えるべきです。
 
 Join メソッドを説明するまえに、リスト18-2で示されるように、オブジェクトの配列をループしていて、関連クラスの詳細を検索するために Propel のゲッターを使うときに何が起きているのかを検討しましょう。この例ではスキーマが `author` テーブルへの外部キーを持つ `article` テーブルを記載していることを前提にしています。
 
@@ -146,7 +146,7 @@ SQLステートメントを使っているのであれば、同じクエリで `
 リスト18-5 - `ArticlePeer` クラスに対して利用可能な `doSelect` メソッド
 
     [php]
-    // Articleオ ブジェクトを検索する
+    // Article オブジェクトを検索する
     doSelect()
 
     // Article オブジェクトを検索し、関連する Author オブジェクトをハイドレイトする
@@ -293,7 +293,7 @@ Propel を利用しているとき、すでにオブジェクトはハイドレ
 
 ### データベースを高速化する
 
-symfony を利用するかかかわらず適用できるデータベース固有の最適化テクニックが多く存在します。このセクションは手短にもっとも共通のデータベース最適化戦略の要点をまとめていますが、モデルレイヤーを最大限利用するにはデータベースエンジンと管理方法に関して詳しい知識が必要です。
+symfony を利用するかにかかわらず適用できるデータベース固有の最適化テクニックが多く存在します。このセクションは手短にもっとも共通のデータベース最適化戦略の要点をまとめていますが、モデルレイヤーを最大限利用するにはデータベースエンジンと管理方法に関して詳しい知識が必要です。
 
 >**TIP**
 >Web デバッグツールバーはそれぞれのクエリのために費やされる時間をページ単位で表示し、本当にパフォーマンスが改善されたのかを判断するためにすべての調整をモニタリングされることを覚えておいてください。
@@ -341,7 +341,7 @@ symfony を利用するかかかわらず適用できるデータベース固有
           password:    password
           persistent:  true      # 永続的接続を使う
 
-これがデータベース全体のパフォーマンスを改善をするのかどうかは多くの要素によります。この主題に関するドキュメントはインターネット上で豊富にあります。利点を検証するためにこの設定を変更する前あとでアプリケーションのパフォーマンスをかならずベンチマークしてください。
+これがデータベース全体のパフォーマンスを改善をするのかどうかは多くの要素によります。この主題に関するドキュメントはインターネット上で豊富にあります。利点を検証するためにこの設定を変更する前後でアプリケーションのパフォーマンスをかならずベンチマークしてください。
 
 >**SIDEBAR**
 >MySQL 固有のティップス