[ja] update some translations.

ja/migrations.rst

@@ -373,13 +373,18 @@ fieldType の後のクエスチョンマークは、ヌルを許可するカラ
 
     class RemovePriceFromProducts extends AbstractMigration
     {
-        public function change()
+        public function up()
         {
             $table = $this->table('products');
             $table->removeColumn('price');
         }
     }
 
+.. note::
+
+    `removeColumn` は不可逆ですので、 `up` メソッドの中で呼び出してください。
+    それに対する `addColumn` の呼び出しは、 `down` メソッドに追加してください。
+
 既存のデータベースからマイグレーションファイルを作成する
 --------------------------------------------------------
 

ja/orm/saving-data.rst

@@ -209,6 +209,12 @@ Table クラスは、リクエストデータを一つまたは複数のエン
         ]
     ]);
 
+入れ子になったアソシエーションの変換を無効にする時は、次のようになります。 ::
+
+    $entity = $articles->newEntity($data, ['associated' => []]);
+    // または...
+    $entity = $articles->patchEntity($entity, $data, ['associated' => []]);
+
 上記は 'Tags' 、 'Comments' そして Comments 用の 'Users' が変換されるべきであること
 を示しています。代わりに、簡潔にするためにドット記法を使うことができます。 ::
 
@@ -235,6 +241,9 @@ Table クラスは、リクエストデータを一つまたは複数のエン
         ]
     ]);
 
+関連付けられた変換のために、異なる検証を使用する方法に関する詳しい情報は、
+:ref:`using-different-validators-per-association` の章をご覧ください。
+
 以下の図表は ``newEntity()`` または ``patchEntity()`` メソッドの内部で
 どんなことが起きるのかの概要を示しています。
 

ja/orm/validation.rst

@@ -130,6 +130,9 @@ CakePHP ではデータの検証には二つの段階があります:
 バリデーションルールセットの構築についてのより多くの情報は :doc:`バリデーション
 </core-libraries/validation>` を参照してください。
 
+
+.. _using-different-validators-per-association:
+
 アソシエーションに異なるバリデーションセットを使用
 --------------------------------------------------
 
@@ -272,8 +275,12 @@ CakePHP ではデータの検証には二つの段階があります:
 基本的なデータ検証が行われますが、多くのアプリケーションは
 基本的な検証が完了した後にのみ適用されるもっと複雑な検証も設けています。
 
-この種のルールはしばしば‘ドメインルール’や‘アプリケーションルール’と言われます。
-CakePHP は、エンティティが保存される前に適用される‘ルールチェッカー’を通して
+バリデーションはデータの形式や構文が正しいことを保証する一方、 ルールは
+あなたのアプリケーションやネットワークの既存の状態に対してデータを比較することに
+焦点を当てます。
+
+この種のルールはしばしば「ドメインルール」や「アプリケーションルール」と言われます。
+CakePHP は、エンティティが保存される前に適用される「ルールチェッカー」を通して
 これを行います。いくつかのドメインルールの例は次のようになります:
 
 * メールアドレスの一意性の保証。