Development

Changeset 28427

You must first sign up to be able to contribute.

Changeset 28427

Show
Ignore:
Timestamp:
03/09/10 11:39:29 (4 years ago)
Author:
masaki
Message:

[doc-ja][1.4] applied the new notation rule for katakana

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • doc/branches/1.4/tutorial/ja/deprecated.markdown

    r28384 r28427  
    1 1.3 での廃止予定および削除される機能 
    2 ==================================== 
     11.3での廃止予定および削除される機能 
     2===================================== 
    33 
    44このドキュメントでは symfony 1.3 で廃止予定もしくは削除されるすべての設定、クラス、メソッド、関数とタスクの一覧を示します。  
     
    99次のコアプラグインは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 
    1010 
    11   * `sfCompat10Plugin`: このプラグインが廃止予定になることで、動くためにこのプラグインに依存するほかのすべての要素も廃止予定になります (1.0 のアドミンジェネレーターとフォームシステム)。これらのなかには `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される 1.0 のアドミンジェネレーターのデフォルトテーマも含まれています。 
     11  * `sfCompat10Plugin`: このプラグインが廃止予定になることで、動くためにこのプラグインに依存するほかのすべての要素も廃止予定になります (1.0 のアドミンジェネレータとフォームシステム)。これらのなかには `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される1.0 アドミンジェネレータのデフォルトテーマも含まれています。 
    1212 
    1313  * `sfProtoculousPlugin`: このプラグインによって提供されるヘルパーは控えめな JavaScript をサポートしないので、今後は使うべきではありません。 
     
    3131  * `sfTestFunctionalBase` の次のメソッド: `isRedirected()`、`isStatusCode()`、`responseContains()`、 
    3232    `isRequestParameter()`、`isResponseHeader()`、 
    33     `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは 1.2 以降で廃止予定になり、テスタークラスに置き換わります。 
     33    `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは1.2以降で廃止予定になり、テスタークラスに置き換わります。 
    3434 
    35   * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは 1.2 以降で廃止予定になり、テスタークラスに置き換わります。 
     35  * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは1.2以降で廃止予定になり、テスタークラスに置き換わります。 
    3636 
    3737  * `sfFilesystem::sh()`: このメソッド呼び出しはすべて新しい `sfFilesystem::execute()` メソッド呼び出しに置き換わります。このメソッドの戻り値は `stdout` 出力と `stderr` 出力で構成される配列であることに注意してください。 
     
    8080 
    8181  * `sfCrudGenerator`、`sfAdminGenerator`、`sfPropelCrudGenerator`、 
    82     `sfPropelAdminGenerator`: これらのクラスは 1.0 のアドミンジェネレーターで使われていました。 
     82    `sfPropelAdminGenerator`: これらのクラスは1.0のアドミンジェネレータで使われていました。 
    8383 
    84   * `sfPropelUniqueValidator`、`sfDoctrineUniqueValidator`: これらのクラスは 1.0 のフォームシステムで使われていました。 
     84  * `sfPropelUniqueValidator`、`sfDoctrineUniqueValidator`: これらのクラスは1.0のフォームシステムで使われていました。 
    8585 
    8686  * `sfLoader`: 「メソッドと関数」のセクションを参照してください。 
     
    102102次のクラスは symfony 1.3 で削除されます: 
    103103 
    104   * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は「プロジェクトを 1.2 から 1.3/1.4 にアップグレードする」の「共通フィルターの削除」を参照してください。 
     104  * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は「プロジェクトを1.2から1.3/1.4にアップグレードする」の「共通フィルタの削除」を参照してください。 
    105105 
    106106ヘルパー 
     
    109109次のヘルパーグループは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 
    110110 
    111   * `sfCompat10Plugin` によって提供される 1.0 のフォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation` 
     111  * `sfCompat10Plugin` によって提供される1.0のフォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation` 
    112112 
    113113`form_tag()` ヘルパーの所属は `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 symfony 1.4 でも利用可能です。 
    114114 
    115 PHP のインクルードパスからヘルパーをロードする機能は 1.3 で廃止予定になり 1.4 で削除されます。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つに設置しなければなりません。 
     115PHP のインクルードパスからヘルパーをロードする機能は1.3で廃止予定になり1.4で削除されます。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つに設置しなければなりません。 
    116116 
    117117設定 
     
    126126  * `sf_lazy_cache_key`: symfony 1.2.6 で大きなパフォーマンス改善のために導入され、この設定はビューキャッシュのために遅延キャッシュキー生成を有効にすることを許可しました。コア開発者は遅延がベストなアイデアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも呼び出される `sfViewCacheManager::isCacheable()` に頼るひともいました。symfony 1.3 に関して、ふるまいは `sf_lazy_cache_key` が `true` にセットされる場合と同じになります。 
    127127 
    128   * `strip_comments`: `strip_comments` は PHP 5.0.x のトークナイザーのバグが原因のコメント除外機能を無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかったとき、メモリの大量消費を避けるためにも使われていました。最初の問題は PHP の最小バージョンが 5.2 になり無関係になっており2番目の問題はコメント除外機能をシミュレートした正規表現を削除することですでに修正されています。 
     128  * `strip_comments`: `strip_comments` は PHP 5.0.x のトークナイザーのバグが原因のコメント除外機能を無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかったとき、メモリの大量消費を避けるためにも使われていました。最初の問題は PHP の最小バージョンが5.2になり無関係になっており2番目の問題はコメント除外機能をシミュレートした正規表現を削除することですでに修正されています。 
    129129 
    130130  * `lazy_routes_deserialize`: このオプションはもう必要ありません。 
     
    150150  * symfony 1.0 のすべてのタスクのエイリアス 
    151151 
    152   * `propel:init-admin`: このタスクは symfony 1.0 のアドミンジェネレータモジュールを生成しました。 
     152  * `propel:init-admin`: このタスクは symfony 1.0 のアドミンジェネレータモジュールを生成しました。 
    153153 
    154154次の Doctrine タスクは `doctrine:build` にマージされ symfony 1.4 で削除されます: 
     
    170170    `sfNamespacedParameterHolder::has()` と `sfNamespacedParameterHolder::remove()` メソッドの配列表記 (`[]`) のサポートは廃止予定になり symfony 1.4 では利用できません (パフォーマンスの向上)。 
    171171 
    172 symfony CLI はグローバルな `--dry-run` オプションを受けることはありません。このオプションは symfony の組み込みタスクによって使われていなかったからです。タスクの 1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。 
     172symfony CLI はグローバルな `--dry-run` オプションを受けることはありません。このオプションは symfony の組み込みタスクによって使われていなかったからです。タスクの 1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。 
    173173 
    174 1.0 のアドミンジェネレーターの Propel テンプレートと 1.0 の CRUD は symfony 1.4 で削除されます (`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`)。 
     1741.0のアドミンジェネレータの Propel テンプレートと 1.0 の CRUD は symfony 1.4 で削除されます (`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`)。 
    175175 
    176176「Dynarch Calendar」 (`data/web/calendar/` で見つかります) は symfony 1.4 は削除されます。これは symfony 1.4 で削除される Form ヘルパーグループだけにしか使われていなかったからです。 
     
    180180プロジェクトのルートで `doc/` ディレクトリが生成されなくなりました。これは symfony 自身でも使われていないからです。そして関連する `sf_doc_dir` も削除されました。 
    181181 
    182 `sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、1.3 で廃止予定になり 1.4 で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。 
     182`sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、1.3で廃止予定になり1.4で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。 
    183183 
    184184symfony のすべての `Base*` クラスの可視性は `abstract` ではありません。 
  • doc/branches/1.4/tutorial/ja/upgrade.markdown

    r28384 r28427  
    1 プロジェクトを 1.2 から 1.3/1.4 にアップグレードする 
     1プロジェクトを1.2から1.3/1.4にアップグレードする 
    22=================================================== 
    33 
    4 このドキュメントでは symfony 1.3/1.4 で行われた変更と 1.2 のプロジェクトをアップグレードするために必要な作業を説明します。 
     4このドキュメントでは symfony 1.3/1.4 で行われた変更と1.2のプロジェクトをアップグレードするために必要な作業を説明します。 
    55 
    66symfony 1.3 で変更または追加された機能の詳細を知りたければ、[「symfony 1.3/1.4 の新しい機能」](http://www.symfony-project.org/tutorial/1_4/ja/whats-new)のチュートリアルをご覧ください。 
     
    1212-------------------------------- 
    1313 
    14 (すべての廃止予定の機能が取り除かれていること以外) symfony 1.4 は symfony 1.3 と同じなので、このバージョンにアップグレードするタスクはありません。1.4 にアップグレードするには、最初に 1.3 にアップグレードしてから 1.4 リリースに切り替えなければなりません。 
    15  
    16 1.4 にアップグレードする前に、`project:validate` タスクを実行することで廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われてないことを検証することもできます: 
     14(すべての廃止予定の機能が取り除かれていること以外) symfony 1.4 は symfony 1.3 と同じなので、このバージョンにアップグレードするタスクはありません。1.4にアップグレードするには、最初に1.3にアップグレードしてから1.4リリースに切り替えなければなりません。 
     15 
     161.4にアップグレードする前に、`project:validate` タスクを実行することで廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われてないことを検証することもできます: 
    1717 
    1818    $ php symfony project:validate 
     
    2020このタスクは symfony 1.4 に切り替える前に変更する必要のあるすべてのファイルの一覧を表示します。 
    2121 
    22 このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするものであり、魔法の道具ではありません。「1.3 の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。 
     22このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするものであり、魔法の道具ではありません。「1.3の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。 
    2323 
    2424>**NOTE** 
    25 >`sfCompat10Plugin` と `sfProtoculousPlugin` は 1.4 から削除されました。`config/ProjectConfiguration.class.php` などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。 
     25>`sfCompat10Plugin` と `sfProtoculousPlugin` は1.4から削除されました。`config/ProjectConfiguration.class.php` などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。 
    2626 
    2727symfony 1.3 にアップグレードするには? 
     
    6161-------------- 
    6262 
    63 symfony 1.3 を開発しているあいだに、いくつかの設定、クラス、メソッド、関数とタスクが廃止予定になるもしくは削除されてきました。詳細な情報は[「1.3 での廃止予定および削除される機能」](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)を参照してくださるようお願いします。 
     63symfony 1.3 を開発しているあいだに、いくつかの設定、クラス、メソッド、関数とタスクが廃止予定になるもしくは削除されてきました。詳細な情報は[「1.3での廃止予定および削除される機能」](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)を参照してくださるようお願いします。 
    6464 
    6565オートロード機能 
     
    7979  * すでにオートロードメカニズムがはたらく `lib/vendor/` ディレクトリの下でライブラリを設置する場合、symfony はファイルを再解析してキャッシュに不要なたくさんの情報を追加します (#5893 - http://trac.symfony-project.org/ticket/5893 を参照)。 
    8080 
    81   * symfony のディレクトリが `lib/vendor/symfony/` という名前でなければ、プロジェクトのオートローダは symfony ディレクトリ全体を再解析することが原因で何らかの問題が起こります (#6064 - http://trac.symfony-project.org/ticket/6064 を参照)。 
     81  * symfony のディレクトリが `lib/vendor/symfony/` という名前でなければ、プロジェクトのオートローダは symfony ディレクトリ全体を再解析することが原因で何らかの問題が起こります (#6064 - http://trac.symfony-project.org/ticket/6064 を参照)。 
    8282 
    8383symfony 1.3 のオートロード機能は大文字と小文字を区別しません。 
     
    9191`lazy_routes_deserialize` オプションはもはや必要ないので削除されました。 
    9292 
    93 symfony 1.3 に関しては、ルーティングキャッシュが無効になりました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、これはすべてのアプリケーションで自動的に無効になります。1.3 にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立っているのか確認するためにルーティングキャッシュを追加するとよいでしょう。symfony 1.2 のデフォルトコンフィギュレーションに戻すために `factories.yml` に追加する内容は次のとおりです: 
     93symfony 1.3 に関しては、ルーティングキャッシュが無効になりました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、これはすべてのアプリケーションで自動的に無効になります。1.3にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立っているのか確認するためにルーティングキャッシュを追加するとよいでしょう。symfony 1.2 のデフォルトコンフィギュレーションに戻すために `factories.yml` に追加する内容は次のとおりです: 
    9494 
    9595    [yml] 
     
    107107-------------------------- 
    108108 
    109 ### 共通フィルタの削除 
    110  
    111 `sfCommonFilter` は削除されデフォルトでは使われていません。このフィルタは自動的に JavaScript とスタイルシートのタグをレスポンスのコンテンツに注入していました。レイアウトのなかで `include_stylesheets()` と `include_javascripts()` ヘルパーを明示的に呼び出すことでこれらのアセットを手動でインクルードする必要があります: 
     109### 共通フィルタの削除 
     110 
     111`sfCommonFilter` は削除されデフォルトでは使われていません。このフィルタは自動的に JavaScript とスタイルシートのタグをレスポンスのコンテンツに注入していました。レイアウトのなかで `include_stylesheets()` と `include_javascripts()` ヘルパーを明示的に呼び出すことでこれらのアセットを手動でインクルードする必要があります: 
    112112 
    113113    [php] 
     
    119119 * すでによりすぐれた、シンプルで、より柔軟な解決方法があります (`include_stylesheets()` と `include_javascripts()` ヘルパー)。 
    120120 
    121  * フィルタが簡単に無効にできるとしても、最初に存在を知らなければならず「背後」のマジックがはたらいているのでこれは簡単なタスクではありません。 
     121 * フィルタが簡単に無効にできるとしても、最初に存在を知らなければならず「背後」のマジックがはたらいているのでこれは簡単なタスクではありません。 
    122122 
    123123 * ヘルパーを使えばいつどこでアセットがレイアウトにインクルードされるのかよりきめ細かくコントロールできます (たとえば `head` タグのスタイルシート、`body` タグが終わる直前の JavaScript) 
     
    129129アップグレードするには? 
    130130 
    131   * すべての `filters.yml` 設定ファイルから `common` フィルタを削除する必要があります (これは `project:upgrade1.3` タスクによって自動的に行われます)。 
    132  
    133   * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()` 呼び出しをレイアウトに追加する必要があります (これはアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の `project:upgrade1.3` タスクによって自動的に行われます - これらは `<head>` タグを持たなければなりません; ほかのレイアウト、もしくはレイアウトを持たないが JavaScript ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。 
     131  * すべての `filters.yml` 設定ファイルから `common` フィルタを削除する必要があります (これは `project:upgrade1.3` タスクによって自動的に行われます)。 
     132 
     133  * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()` 呼び出しをレイアウトに追加する必要があります (これはアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の `project:upgrade1.3` タスクによって自動的に行われます - これらは `<head>` タグをもたなければなりません; ほかのレイアウト、もしくはレイアウトをもたないが JavaScript ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。 
    134134 
    135135 
     
    151151  `sfPropelDumpDataTask`    | `sfPropelDataDumpTask` 
    152152 
    153 ### フォーマッタ 
    154  
    155 `sfFormatter::format()` の 3番目の引数は削除されました。 
     153### フォーマッタ 
     154 
     155`sfFormatter::format()` の3番目の引数は削除されました。 
    156156 
    157157エスケーピング 
    158158------------- 
    159159 
    160 `ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` は ANSI ではない文字を正しく処理するように更新されました。この変更の前は ANSI の値が `37` から `177` である文字のみがエスケープされませんでした。現在はバックスラッシュ (`\`)、クォート (`'` と `"`) 、そして改行 (`\n` と `\r`) のみをエスケープします。 
     160`ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` は ANSI ではない文字を正しく処理するように更新されました。この変更の前は ANSI の値が`37`から`177`である文字のみがエスケープされませんでした。現在はバックスラッシュ (`\`)、クォート (`'` と `"`) 、そして改行 (`\n` と `\r`) のみをエスケープします。 
    161161 
    162162Doctrine との統合 
     
    167167Doctrine の svn:externals は最新の Doctrine 1.2 を使うように更新されました。Doctrine 1.2 の新しい機能に関しては[公式サイトの手引き](http://www.doctrine-project.org/upgrade/1_2)をご覧ください。 
    168168 
    169 ### アドミンジェネレータの削除機能 
    170  
    171 アドミンジェネレータバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに `delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを起動させるためです。 
     169### アドミンジェネレータの削除機能 
     170 
     171アドミンジェネレータバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに `delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを起動させるためです。 
    172172 
    173173### Doctrine プラグインスキーマをオーバーライドする 
  • doc/branches/1.4/tutorial/ja/whats-new.markdown

    r28384 r28427  
    66最初に、symfony 1.3/1.4 は PHP 5.2.4 およびそれ以降のバージョンと互換性があることにご注意ください。 
    77 
    8 1.2 からアップグレードしたいのであれば、[「プロジェクトを 1.2 から 1.3/1.4 にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。 
     81.2 からアップグレードしたいのであれば、[「プロジェクトを1.2から1.3/1.4にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。 
    99 
    1010 
     
    4444### 標準のラベル 
    4545 
    46 ラベルがフィールド名で自動生成される場合、サフィックスの `_id` は削除されます: 
     46ラベルがフィールド名で自動生成される場合、接尾辞の `_id` は削除されます: 
    4747 
    4848  * `first_name` => First name (以前と同じ) 
     
    8080    `setLabels()`、`setHelps()`、`setHelp()`、`setParent()`、`setPositions()` 
    8181 
    82 バリデータ 
     82バリデータ 
    8383------------ 
    8484 
    8585### `sfValidatorRegex` 
    8686 
    87 `sfValidatorRegex` に新しい `must_match` オプションが用意されました。このオプションが `false` にセットされる場合、正規表現は渡すバリデータにマッチしません。 
     87`sfValidatorRegex` に新しい `must_match` オプションが用意されました。このオプションが `false` にセットされる場合、正規表現は渡すバリデータにマッチしません。 
    8888 
    8989`sfValidatorRegex` の `pattern` オプションは呼び出されるときに正規表現を返す `sfCallable` のインスタンスにしなければならなくなりました。 
     
    105105### `sfValidatorSchemaCompare` 
    106106 
    107 `sfValidatorSchemaCompare` クラスに2つの新しいコンパレータが用意されました: 
     107`sfValidatorSchemaCompare` クラスに2つの新しいコンパレータが用意されました: 
    108108 
    109109 * `IDENTICAL` は `===` と同等です; 
     
    112112### `sfValidatorChoice`、`sfValidator(Propel|Doctrine)Choice` 
    113113 
    114 `sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデータには `multiple` オプションが `true` の場合のみ有効になる2つの新しいオプションがあります: 
     114`sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデータには `multiple` オプションが `true` の場合のみ有効になる2つの新しいオプションがあります: 
    115115 
    116116 * `min` 選択する必要がある最小の数 
    117117 * `max` 選択する必要がある最大の数 
    118118 
    119 ### 国際化バリデータ 
    120  
    121 次のバリデータが追加されました: 
     119### 国際化バリデータ 
     120 
     121次のバリデータが追加されました: 
    122122 
    123123 * `sfValidatorI18nChoiceTimezone` 
     
    130130    sfValidatorBase::setDefaultMessage('required', 'This field is required.'); 
    131131 
    132 上記のコードはすべてのバリデーターのデフォルトメッセージである 'Required.' をオーバーライドします。デフォルトメッセージはバリデーターが作られる前に定義しておかなければならないことにご注意ください (コンフィグレーションクラスがよい場所です)。 
     132上記のコードはすべてのバリデータのデフォルトメッセージである 'Required.' をオーバーライドします。デフォルトメッセージはバリデータが作られる前に定義しておかなければならないことにご注意ください (コンフィグレーションクラスがよい場所です)。 
    133133 
    134134>**NOTE** 
     
    137137symfony がエラーを表示するとき、使われるエラーメッセージは次のように決定されます: 
    138138 
    139   * symfony はバリデーターが作られたときに渡されたメッセージを探します (バリデーターのコンストラクターの第2引数経由); 
     139  * symfony はバリデータが作られたときに渡されたメッセージを探します (バリデータのコンストラクタの第2引数経由); 
    140140 
    141141  * 定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージを探します; 
    142142 
    143   * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき) バリデータ自身で定義される初期メッセージへ戻ります。 
     143  * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき) バリデータ自身で定義される初期メッセージへ戻ります。 
    144144 
    145145### 流れるようなインターフェイス 
    146146 
    147 バリデータは次のような流れるようなインターフェイスを実装するようになりました: 
     147バリデータは次のような流れるようなインターフェイスを実装するようになりました: 
    148148 
    149149  * `sfValidatorSchema`: `setPreValidator()`、`setPostValidator()` 
     
    182182### `sfForm::renderHiddenFields()` 
    183183 
    184 `->renderHiddenFields()` メソッドは組み込みフォームからの隠しフィールドをレンダリングします。再帰処理を無効にする引数が追加されました。これはフォーマッタを使って組み込みフォームをレンダリングする場合に便利です。 
     184`->renderHiddenFields()` メソッドは組み込みフォームからの隠しフィールドをレンダリングします。再帰処理を無効にする引数が追加されました。これはフォーマッタを使って組み込みフォームをレンダリングする場合に便利です。 
    185185 
    186186    [php] 
     
    193193### `sfFormSymfony` 
    194194 
    195 新しい `sfFormSymfony` クラスはイベントディスパッチャーを symfony フォームに導入します。`self::$dispatcher` を通してフォームクラス内部のディスパッチャーにアクセスできます。次のフォームイベントが symfony によって通知されます: 
     195新しい `sfFormSymfony` クラスはイベントディスパッチャを symfony フォームに導入します。`self::$dispatcher` を通してフォームクラス内部のディスパッチャにアクセスできます。次のフォームイベントが symfony によって通知されます: 
    196196 
    197197  * `form.post_configure`:   このイベントはフォームが設定された後で通知される 
    198   * `form.filter_values`:    このイベントは、マージされ汚染されたパラメータと、バインドする直前のファイルの配列をフィルタリングする 
     198  * `form.filter_values`:    このイベントは、マージされ汚染されたパラメータと、バインドする直前のファイルの配列をフィルタリングする 
    199199  * `form.validation_error`: フォームバリデーションが通らないときこのイベントが通知される 
    200200  * `form.method_not_found`: 身元不明のメソッドが呼び出されるときにこのイベントが通知される 
     
    207207### `sfForm::doBind()` 
    208208 
    209 汚染されたパラメーターのクリーニングは開発者にわかりやすい `->doBind()` メソッドに隔離されました。このメソッドは `->bind()` からのパラメーターとファイルのマージされる配列を受けとります。 
     209汚染されたパラメータのクリーニングは開発者にわかりやすい `->doBind()` メソッドに隔離されました。このメソッドは `->bind()` からのパラメータとファイルのマージされる配列を受けとります。 
    210210 
    211211### `sfForm(Doctrine|Propel)::doUpdateObject()` 
     
    230230`setWidgetSchema()`、`setOption()`、`setDefault()`、そして `setDefaults()` 
    231231 
    232 オートローダ 
     232オートローダ 
    233233-------------- 
    234234 
    235 symfony のすべてのオートローダは大文字と小文字を区別しないようになりました。PHP が大文字と小文字を区別をしないので、symfony もそれに合わせることにしたからです。 
     235symfony のすべてのオートローダは大文字と小文字を区別しないようになりました。PHP が大文字と小文字を区別をしないので、symfony もそれに合わせることにしたからです。 
    236236 
    237237### `sfAutoloadAgain` (実験的な機能) 
    238238 
    239 デバッグモードでの用途を目的とする特殊なオートローダーが追加されました。新しい `sfAutoloadAgain` クラスは symfony の標準オートローダーをリロードし該当するクラスを求めてファイルシステムを検索します。純粋な効果は新しいクラスをプロジェクトに追加した後に `symfony cc` を実行する必要がなくなることです。 
     239デバッグモードでの用途を目的とする特殊なオートローダが追加されました。新しい `sfAutoloadAgain` クラスは symfony の標準オートローダをリロードし該当するクラスを求めてファイルシステムを検索します。純粋な効果は新しいクラスをプロジェクトに追加した後に `symfony cc` を実行する必要がなくなることです。 
    240240 
    241241テスト 
     
    277277### lime によるカラー出力 
    278278 
    279 symfony 1.3/1.4 では、lime はカラー出力を正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクタの第2引数を省略できるということです: 
     279symfony 1.3/1.4 では、lime はカラー出力を正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクタの第2引数を省略できるということです: 
    280280 
    281281    [php] 
     
    299299    end(); 
    300300 
    301 レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをきめ細かく指定する CSS セレクタを提供するオプションがあります: 
     301レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをきめ細かく指定する CSS セレクタを提供するオプションがあります: 
    302302 
    303303    [php] 
     
    339339### 改良された `->click()` 
    340340 
    341 `->click()` メソッドに CSS セレクタを渡すことが可能で、セマンティックにしたい要素をターゲットにするのがはるかに楽になりました。 
     341`->click()` メソッドに CSS セレクタを渡すことが可能で、セマンティックにしたい要素をターゲットにするのがはるかに楽になりました。 
    342342 
    343343    [php] 
     
    405405### `task.test.filter_test_files` 
    406406 
    407 `test:*` タスクはこれらのタスクが実行される前に `task.test.filter_test_files` イベントを通過するようになりました。このイベントには `arguments` と `options` パラメータが用意されています。 
     407`test:*` タスクはこれらのタスクが実行される前に `task.test.filter_test_files` イベントを通過するようになりました。このイベントには `arguments` と `options` パラメータが用意されています。 
    408408 
    409409### `sfTask::run()` の強化 
     
    505505--------------- 
    506506 
    507 Propel のバージョンは 1.4 にアップグレードされました。Propel のアップグレードに関する詳しい情報は[公式サイト](http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4)を訪問してくださるようお願いします。 
     507Propel のバージョンは1.4にアップグレードされました。Propel のアップグレードに関する詳しい情報は[公式サイト](http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4)を訪問してくださるようお願いします。 
    508508 
    509509### Propel のビヘイビア 
     
    539539### フォーム生成を無効にする 
    540540 
    541 Propel の `symfony` ビヘイビアにパラメータを渡すことで特定のモデルでのフォーム生成を無効にできます: 
     541Propel の `symfony` ビヘイビアにパラメータを渡すことで特定のモデルでのフォーム生成を無効にできます: 
    542542 
    543543    classes: 
     
    573573### `sfObjectRouteCollection` オプション 
    574574 
    575 新しい `default_params` オプションが `sfObjectRouteCollection` に追加されました。これはそれぞれの生成ルートにデフォルトパラメータを登録することを可能にします: 
     575新しい `default_params` オプションが `sfObjectRouteCollection` に追加されました。これはそれぞれの生成ルートにデフォルトパラメータを登録することを可能にします: 
    576576 
    577577    [yml] 
     
    633633 
    634634>**NOTE** 
    635 >1.2 からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが `ProjectConfiguration` ファイルを変更しないからです。このふるまいの変更は symfony 1.3/1.4 の新規プロジェクトのみです。 
     635>1.2からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが `ProjectConfiguration` ファイルを変更しないからです。このふるまいの変更は symfony 1.3/1.4 の新規プロジェクトのみです。 
    636636 
    637637### `sfPluginConfiguration::connectTests()` 
     
    662662        file_link_format: txmt://open?url=file://%f&line=%l 
    663663 
    664 `%f` プレースホルダーはファイルの絶対パスに、`%l` プレースホルダーは行数に置き換わります。 
     664`%f` プレースホルダはファイルの絶対パスに、`%l` プレースホルダは行数に置き換わります。 
    665665 
    666666Doctrine との統合 
     
    671671### フォームクラスを生成する 
    672672 
    673 Doctrine の YAML スキーマファイルのなかで symfony の追加オプションを指定できるようになりました。そしてフォームとフィルタクラスの生成を無効にするオプションもいくつか追加されました。 
    674  
    675 たとえば、 典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタフォームクラスを生成させる必要はありません。ですので次のようなことができます: 
     673Doctrine の YAML スキーマファイルのなかで symfony の追加オプションを指定できるようになりました。そしてフォームとフィルタクラスの生成を無効にするオプションもいくつか追加されました。 
     674 
     675たとえば、 典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタフォームクラスを生成させる必要はありません。ですので次のようなことができます: 
    676676 
    677677    UserGroup: 
     
    704704#### モデルファイルを削除する 
    705705 
    706 YAML スキーマファイルのなかでモデルや名前を変更したり、使われなくなったモデルを削除することがよくあるでしょう。このような作業を行うと、孤児となったモデル、フォームそしてフィルタクラスが出てきます。`doctrine:delete-model-files` タスクを使うことで、モデルに関連する生成ファイルを手作業で掃除できるようになりました。 
     706YAML スキーマファイルのなかでモデルや名前を変更したり、使われなくなったモデルを削除することがよくあるでしょう。このような作業を行うと、孤児となったモデル、フォームそしてフィルタクラスが出てきます。`doctrine:delete-model-files` タスクを使うことで、モデルに関連する生成ファイルを手作業で掃除できるようになりました。 
    707707 
    708708    $ php symfony doctrine:delete-model-files ModelName 
     
    730730    $ php symfony doctrine:build --all-classes --and-migrate 
    731731 
    732 これはモデル (`:build-model`)、フォーム (`:build-forms`)、フォームフィルタ (`:build-filters`) を生成し、保留されているマイグレーション (`:migrate`) を実行します。 
     732これはモデル (`:build-model`)、フォーム (`:build-forms`)、フォームフィルタ (`:build-filters`) を生成し、保留されているマイグレーション (`:migrate`) を実行します。 
    733733 
    734734    $ php symfony doctrine:build --model --and-migrate --and-append=data/fixtures/categories.yml 
     
    808808    (2 results) 
    809809 
    810 ### クエリパラメータを `doctrine:dql` に渡す 
    811  
    812 `doctrine:dql` タスクもクエリパラメータを引数として受け取れるよう強化されました: 
     810### クエリパラメータを `doctrine:dql` に渡す 
     811 
     812`doctrine:dql` タスクもクエリパラメータを引数として受け取れるよう強化されました: 
    813813 
    814814    $ php symfony doctrine:dql "FROM Article a WHERE name LIKE ?" John% 
     
    862862    } 
    863863 
    864 フォームフィルタのカスタマイズが簡単になりました。フィルタリングをフィールドに追加するのに必要なのはウィジェットとそれを処理するメソッドを追加することだけです。 
     864フォームフィルタのカスタマイズが簡単になりました。フィルタリングをフィールドに追加するのに必要なのはウィジェットとそれを処理するメソッドを追加することだけです。 
    865865 
    866866    [php] 
     
    909909    } 
    910910 
    911 Web デバッグツールバー 
    912 ---------------------- 
     911ウェブデバッグツールバー 
     912-------------------------- 
    913913 
    914914### `sfWebDebugPanel::setStatus()` 
    915915 
    916 Web デバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を及ぼすステータスを指定できるようになりました。たとえば、`sfLogger::INFO` よりも優先順位が高いメッセージがロギングされる場合、log パネルのタイトルの背景色は変わります。 
    917  
    918 ### `sfWebDebugPanel` リクエストパラメータ 
    919  
    920 `sfWebDebugPanel` パラメーターを URL につけ加えることでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば config パネルを開くように Web デバッグツールバーはレンダリングされます。 
    921  
    922 パネルは Web デバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメータをインスペクトします: 
     916ウェブデバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を及ぼすステータスを指定できるようになりました。たとえば、`sfLogger::INFO` よりも優先順位が高いメッセージがロギングされる場合、log パネルのタイトルの背景色は変わります。 
     917 
     918### `sfWebDebugPanel` リクエストパラメータ 
     919 
     920`sfWebDebugPanel` パラメータを URL につけ加えることでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば config パネルを開くように ウェブデバッグツールバーはレンダリングされます。 
     921 
     922パネルは Web デバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメータをインスペクトします: 
    923923 
    924924    [php] 
     
    930930### スロットの改善 
    931931 
    932 スロットが提供されない場合、`get_slot()` と `include_slot()` ヘルパーは戻り値として返すスロットのデフォルトの内容を指定するための 2番目のパラメーターを受けとります: 
     932スロットが提供されない場合、`get_slot()` と `include_slot()` ヘルパーは戻り値として返すスロットのデフォルトの内容を指定するための2番目のパラメータを受けとります: 
    933933 
    934934    [php] 
     
    952952 
    953953ビューキャッシュ 
    954 --------------- 
    955  
    956 ビューキャッシュマネージャーは `factories.yml` でパラメーターを受けとります。ビューのキャッシュキーの生成はクラスを簡単に拡張できるように異なる方法でリファクタリングされました。 
    957  
    958 `factories.yml` で2つのパラメータが利用できます: 
    959  
    960   * `cache_key_use_vary_headers` (デフォルト: true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実際には、`vary` キャッシュパラメータで指定されるので、これはページキャッシュが HTTP ヘッダーに依存するかどうかを伝えます。 
     954----------------- 
     955 
     956ビューキャッシュマネージャは `factories.yml` でパラメータを受けとります。ビューのキャッシュキーの生成はクラスを簡単に拡張できるように異なる方法でリファクタリングされました。 
     957 
     958`factories.yml` で2つのパラメータが利用できます: 
     959 
     960  * `cache_key_use_vary_headers` (デフォルト: true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実際には、`vary` キャッシュパラメータで指定されるので、これはページキャッシュが HTTP ヘッダーに依存するかどうかを伝えます。 
    961961 
    962962  * `cache_key_use_host_name` (デフォルト: true): キャッシュキーがホスト名の部分を含むか指定します。実際には、これはページキャッシュがホスト名に依存するかどうかを伝えます。 
     
    964964### キャッシュの強化 
    965965 
    966 ビューキャッシュマネージャは配列の `$_GET` もしくは `$_POST` に値が存在するのかによってキャッシュを拒否しなくなりました。ロジックは現在のリクエストが `cache.yml` をチェックする前の GET リクエストメソッドであることを確認するだけです。このことは次のページがキャッシュ可能であることを意味します: 
     966ビューキャッシュマネージャは配列の `$_GET` もしくは `$_POST` に値が存在するのかによってキャッシュを拒否しなくなりました。ロジックは現在のリクエストが `cache.yml` をチェックする前の GET リクエストメソッドであることを確認するだけです。このことは次のページがキャッシュ可能であることを意味します: 
    967967 
    968968  * `/js/my_compiled_javascript.js?cachebuster123` 
     
    976976リクエストの内容は `getContent()` メソッドを通してアクセスできるようになりました。 
    977977 
    978 ### `PUT` と `DELETE` パラメータ 
    979  
    980 Content-Type が `application/x-www-form-urlencoded` にセットされている `PUT`、`DELETE` HTTP リクエストメソッドが来る場合、symfony は生のボディを解析し、通常の `POST` パラメーターのようにアクセスできるパラメーターを作ります。 
     978### `PUT` と `DELETE` パラメータ 
     979 
     980Content-Type が `application/x-www-form-urlencoded` にセットされている `PUT`、`DELETE` HTTP リクエストメソッドが来る場合、symfony は生のボディを解析し、通常の `POST` パラメータのようにアクセスできるパラメータを作ります。 
    981981 
    982982アクション