Author: masaki
Date: 2010-03-24 18:30:54 +0100 (Wed, 24 Mar 2010)
New Revision: 28767
Modified:
doc/branches/1.4/tutorial/ja/deprecated.markdown
doc/branches/1.4/tutorial/ja/upgrade.markdown
doc/branches/1.4/tutorial/ja/whats-new.markdown
doc/branches/1.4/tutorial/ja/which-version.markdown
Log:
[doc-ja][1.4] slightly modified some sentences and adjusted punctuations.
Modified: doc/branches/1.4/tutorial/ja/deprecated.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-24 17:06:38 UTC
(rev 28766)
+++ doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-24 17:30:54 UTC
(rev 28767)
@@ -125,7 +125,7 @@
* `check_symfony_version`: この設定は symfony
のバージョンが変更される場合にキャッシュの自動消去を可能にするために数年前に導入されました。この設定は主にすべての顧客のあいだで symfony
の同じバージョンが共有される共用ホスティングのコンフィギュレーションに役立っていました。symfony 1.1
以降ではバッドプラクティスですので、設定は無効です (プロジェクトごとに symfony のバージョンを組み込む必要があります)。さらに、この設定が `on`
にセットされている場合、ファイルのコンテンツを得る必要があるときに、小さなオーバーヘッドがそれぞれのリクエストに追加されてしまいます。
- * `max_forwards`: この設定は symfony
が例外を投げる前に許容される転送の最大回数をコントロールします。これを設定可能にする値はありません。5回よりも多くの転送が必要な場合、問題の認識とパフォーマンスの両方で問題があります。
+ * `max_forwards`: この設定は symfony
が例外を投げる前に許容される転送の最大回数をコントロールします。この設定を変更しても効果はありません。5回よりも多くの転送が必要な場合、問題の認識とパフォーマンスの両方で問題があります。
* `sf_lazy_cache_key`: symfony 1.2.6
で大きなパフォーマンス改善のために導入され、この設定はビューキャッシュのために遅延キャッシュキー生成を有効にすることを許可しました。コア開発者は遅延がベストなアイディアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも
`sfViewCacheManager::isCacheable()` の呼び出しに頼るひともいました。symfony 1.3 に関して、ふるまいは
`sf_lazy_cache_key` が `true` にセットされている場合と同じになります。
@@ -140,7 +140,7 @@
* `validation_error_prefix`、`validation_error_suffix`、
`validation_error_class`、`validation_error_id_prefix`: これらの設定を使っていたのは
Validation ヘルパーグループだけなので、symfony 1.3 で廃止予定です。
- * `is_internal` (`module.yml`): `is_internal`
フラグはアクションがブラウザから呼び出されるのを防ぐために使われました。これは symfony 1.0
でメール送信を保護するために追加されました。このトリックがメールのサポートに必要なくなったので、このフラグは削除され symfony
コアではチェックされません。
+ * `is_internal` (`module.yml`): `is_internal`
フラグはアクションがブラウザから呼び出されるのを防ぐために使われました。このフラグは symfony 1.0
でメール送信を保護するために追加されました。このトリックがメールのサポートに必要なくなったので、このフラグは削除され symfony
コアではチェックされません。
タスク
------
Modified: doc/branches/1.4/tutorial/ja/upgrade.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-24 17:06:38 UTC
(rev 28766)
+++ doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-24 17:30:54 UTC
(rev 28767)
@@ -11,18 +11,18 @@
symfony 1.4 にアップグレードする
--------------------------------
-(すべての廃止予定の機能が削除されていること以外) symfony 1.4 は symfony 1.3
と同じなので、このバージョンにアップグレードするタスクはありません。1.4 にアップグレードするには、最初に 1.3 にアップグレードしてから 1.4
リリースに切り替えなければなりません。
+(すべての廃止予定の機能が削除されていること以外) symfony 1.4 は symfony 1.3
と同じなので、このバージョンにアップグレードするタスクはありません。symfony 1.4 にアップグレードするには、最初に symfony 1.3
にアップグレードしてから symfony 1.4 リリースに切り替えなければなりません。
-1.4 にアップグレードする前に、`project:validate`
タスクを実行することで廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われてないことを検証することもできます:
+symfony 1.4 にアップグレードする前に、`project:validate`
タスクを実行することで廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われてないことを検証することもできます:
$ php symfony project:validate
このタスクは symfony 1.4 に切り替える前に修正する必要のあるすべてのファイルの一覧を表示します。
-このタスクで使われている正規表現は大まかなもので多くの誤判断をしてしまう可能性があることにご注意ください。また、このタスクは起きる可能性のある問題を特定するのを手助けするためのものであり、すべてのファイルを検出できるわけではないので魔法の道具ではありません。「1.3
での廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。
+このタスクに使われている正規表現は大まかなものであり多くの誤判断をしてしまう可能性があることにご注意ください。また、このタスクは起きる可能性のある問題を特定するのを手助けするためのものであり、すべてのファイルを検出できるわけではないので魔法の道具ではありません。「1.3
での廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。
>**NOTE**
->`sfCompat10Plugin` と `sfProtoculousPlugin` は 1.4
から削除されました。`config/ProjectConfiguration.class.php`
などのプロジェクトの設定ファイルでこれらのプラグインを明示的に無効にする場合、これらのファイルからこれらのプラグインの記述をすべて削除しなければなりません。
+>`sfCompat10Plugin` と `sfProtoculousPlugin` は symfony 1.4
から削除されました。`config/ProjectConfiguration.class.php`
などのプロジェクトの設定ファイルでこれらのプラグインを明示的に無効にする場合、これらのファイルからこれらのプラグインの記述をすべて削除しなければなりません。
symfony 1.3 にアップグレードするには？
-------------------------------------
@@ -55,7 +55,7 @@
$ php symfony cache:clear
-残りのセクションは symfony 1.3 で行われなんらかのアップグレード (自動もしくはそうではない) が必要なおもな変更を説明します。
+残りのセクションは symfony 1.3 で行われなんらかのアップグレード (自動もしくはそうではない) が必要な主な変更を説明します。
廃止予定の機能
--------------
@@ -90,7 +90,7 @@
`lazy_routes_deserialize` オプションはもはや必要ないので削除されました。
-symfony 1.3
に関して、ルーティングキャッシュが無効になりました。ほとんどのプロジェクトではこれはパフォーマンスの観点からベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、このオプションはすべてのアプリケーションで自動的に無効になります。1.3
にアップグレードした後でプロジェクトの動きが遅くなる場合、役に立っていることを確認するためにルーティングキャッシュを追加するとよいでしょう。symfony
1.2 のデフォルトコンフィギュレーションに戻すには次の内容を `factories.yml` に追加します:
+symfony 1.3
に関して、ルーティングキャッシュが無効になりました。ほとんどのプロジェクトではこれはパフォーマンスの観点からベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、このオプションはすべてのアプリケーションで自動的に無効になります。symfony
1.3
にアップグレードした後でプロジェクトの動きが遅くなる場合、役に立っていることを確認するためにルーティングキャッシュを追加するとよいでしょう。symfony
1.2 のデフォルトコンフィギュレーションに戻すには次の内容を `factories.yml` に追加します:
[yml]
routing:
@@ -116,9 +116,9 @@
共通フィルタは複数の理由から削除されました:
- * すでによりすぐれた、シンプルでより柔軟な解決方法があります (`include_stylesheets()` と
`include_javascripts()` ヘルパー)。
+ * シンプルでより柔軟ですぐれた解決方法がすでにあります (`include_stylesheets()` と
`include_javascripts()` ヘルパー)。
- * フィルタを簡単に無効にできるとしても、最初に存在を知らなければならず「背後」のマジックがはたらいているのでこれは簡単なタスクではありません。
+ * 最初にフィルタの存在を知らなければならず「背後」のマジックがはたらいているので、フィルタを無効にするタスクは簡単ではないからです。
* ヘルパーを使えばいつどこでアセットがレイアウトにインクルードされるのかきめ細かくコントロールできます (たとえば `head`
タグのスタイルシート、`body` タグが終わる直前の JavaScript)
@@ -180,7 +180,7 @@
type: string(255)
>**NOTE**
->package オプションは Doctrine の機能で symfony プラグインのスキーマに使われます。このことはモデルのパッケージを作るために
package 機能を単独で使うことができることを意味しません。この機能は直接および symfony プラグインでのみ使わなければなりません。
+>package オプションは Doctrine の機能で symfony プラグインのスキーマに使われます。このことはモデルのパッケージを作るために
package 機能を単独で使うことができることを意味しません。この機能を使えるのは直接および symfony プラグインのなかだけです。
### クエリのロギング
@@ -199,14 +199,14 @@
メーラー
--------
-symfony 1.3 には新しいメーラーファクトリが用意されています。アプリケーションを作るとき、`factories.yml` には `test` と
`dev` 環境の実用的なデフォルトが収められています。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために `factories.yml`
を次のコンフィギュレーションに更新するとよいでしょう:
+symfony 1.3 には新しいメーラーファクトリが用意されています。アプリケーションが作られるとき、`factories.yml` には `test`
と `dev` 環境の実用的なデフォルトが収められています。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために
`factories.yml` のコンフィギュレーションを次のように更新するとよいでしょう:
[yml]
mailer:
param:
delivery_strategy: none
-以前のコンフィギュレーションでは、メールは送信されません。もちろん、これらのコンフィギュレーションはまだロギングされ、`mailer`
テスターは機能テストでまだ動きます。
+以前のコンフィギュレーションではメールは送信されません。もちろん、これらのコンフィギュレーションはまだロギングされ、`mailer`
テスターは機能テストでまだ動きます。
すべてのメールを1つのメールアドレスで受信したいのであれば `single_address` 配信戦略を使います (たとえば `dev` 環境):
Modified: doc/branches/1.4/tutorial/ja/whats-new.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-24 17:06:38 UTC
(rev 28766)
+++ doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-24 17:30:54 UTC
(rev 28767)
@@ -5,7 +5,7 @@
最初に、symfony 1.3/1.4 と互換性のある PHP のバージョンが 5.2.4 およびそれ以降であることにご注意ください。
-1.2 からアップグレードしたいのであれば、[「プロジェクトを 1.2 から 1.3/1.4
にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを
symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。
+symfony 1.2 からアップグレードしたいのであれば、[「プロジェクトを 1.2 から 1.3/1.4
にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを
symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。
メーラー
@@ -106,14 +106,14 @@
### `sfValidatorSchemaCompare`
-`sfValidatorSchemaCompare` クラスに新しいコンパレータが2つ用意されました:
+`sfValidatorSchemaCompare` クラスに2つの新しいコンパレータが用意されました:
* `IDENTICAL` は `===` と同等です;
* `NOT_IDENTICAL` は `!==` と同等です;
### `sfValidatorChoice`、`sfValidator(Propel|Doctrine)Choice`
-`sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice`
バリデータには `multiple` オプションが `true` の場合のみ有効になる新しいオプションが2つ用意されました:
+`sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice`
バリデータには `multiple` オプションが `true` の場合のみ有効になる2つの新しいオプションが用意されました:
* `min` 選択する必要がある最小の数
* `max` 選択する必要がある最大の数
@@ -126,7 +126,7 @@
### デフォルトのエラーメッセージ
-次のように `sfForm::setDefaultMessage()`
メソッドを使うことデフォルトのエラーメッセージをグローバルに定義できるようになりました:
+`sfForm::setDefaultMessage()`
メソッドを次のように使うことでデフォルトのエラーメッセージをグローバルに定義できるようになりました:
[php]
sfValidatorBase::setDefaultMessage('required', 'This field is required.');
@@ -158,14 +158,14 @@
### `sfValidatorFile`
-`php.ini` で `file_uploads` が無効な場合 `sfValidatorFile` のインスタンスを作る際に例外が投げられます。
+`php.ini` で `file_uploads` が無効にされている場合 `sfValidatorFile` のインスタンスを作る際に例外が投げられます。
フォーム
--------
### `sfForm::useFields()`
-新しい `sfForm::useFields()`
メソッドは引数として提供されるフィールド以外、隠しフィールドではないすべてのフィールドをフォームから削除します。ときには不要なフィールドの割り当てを解除するよりもフォームで維持したいフィールドを明示的に指示するほうが簡単です。たとえば、新しいフィールドを基底フォームに追加するとき、これらは明示的に追加されるまでフォームに自動表示されることはありません
(モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。
+新しい `sfForm::useFields()`
メソッドは引数として提供されるフィールド以外、隠しフィールドではないすべてのフィールドをフォームから削除します。ときには不要なフィールドの割り当てを解除するよりもフォームで維持したいフィールドを明示的に指示するほうが簡単です。たとえば、新しいフィールドを基底フォームに追加するとき、これらのフィールドは明示的に追加されるまでフォームに自動表示されることはありません
(モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。
[php]
class ArticleForm extends BaseArticleForm
@@ -205,7 +205,7 @@
### `BaseForm`
-Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使う `BaseForm` クラスが symfony 1.3/1.4
のすべての新しいプロジェクトに用意されます。`sfDoctrinePlugin` と `sfPropelPlugin`
によって生成されるフォームはこのクラスを自動的に継承します。追加のフォームクラスを作るのであれば継承するのは `sfForm` ではなく `BaseForm`
です。
+symfony 1.3/1.4 では Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使う `BaseForm`
クラスがすべての新しいプロジェクトに用意されます。`sfDoctrinePlugin` と `sfPropelPlugin`
によって生成されるフォームはこのクラスを自動的に継承します。追加のフォームクラスを作るのであれば継承するのは `sfForm` ではなく `BaseForm`
です。
### `sfForm::doBind()`
@@ -352,7 +352,7 @@
タスク
------
-symfony CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI
は幅をデフォルトの78カラムに合わせようとします。
+symfony CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI
はウィンドウの幅をデフォルトの78カラムに合わせようとします。
### `sfTask::askAndValidate()`
@@ -365,7 +365,7 @@
### `symfony:test`
-ときに開発者は特定のプラットフォームで symfony が正しく動くのかをチェックするために symfony
のテストスイートを実行する必要があります。従来は、この確認作業を行うために symfony に附属する `prove.php`
スクリプトの存在を知らなければなりませんでした。symfony 1.3/1.4 では組み込みのタスク、コマンドラインから symfony
のコアテストスイートを実行できる `symfony:test` タスクが用意され、ほかのタスクと同じように使うことができます:
+ときに開発者は特定のプラットフォームで symfony が正しく動くのかをチェックするために symfony
のテストスイートを実行する必要があります。従来ではこの確認作業を行うために symfony に附属する `prove.php`
スクリプトの存在を知らなければなりませんでした。symfony 1.3/1.4 では組み込みのタスク、コマンドラインから symfony
のコアテストスイートを実行できる `symfony:test` タスクが用意され、ほかのタスクと同じように使うことができます:
$ php symfony symfony:test
@@ -390,12 +390,12 @@
$ php /path/to/symfony generate:project foo --orm=none
-新しい `--installer` オプションのおかげで新たに生成されるプロジェクトをかなりカスタマイズできる PHP
スクリプトを指定することができます。スクリプトはタスクで実行され、タスクのメソッドで使うことができます。次のようなもっと便利なメソッドがあります:
+新しい `--installer` オプションのおかげで新たに生成されるプロジェクトをかなりカスタマイズできる PHP
スクリプトを指定することができます。スクリプトはタスクで実行され、タスクのメソッドのなかで使うことができます。次のようなもっと便利なメソッドがあります:
`installDir()`、`runTask()`、`ask()`、`askConfirmation()`、`askAndValidate()`、
`reloadTasks()`、`enablePlugin()` そして `disablePlugin()`
-詳しい情報は公式ブログの[記事](http://www.symfony-project.org/blog/2009/06/10/new-in-symfony-1-3-project-creation-customization)にあります。
+詳しい情報は公式ブログの[記事 (New in symfony 1.3: Project Creation
Customization)](http://www.symfony-project.org/blog/2009/06/10/new-in-symfony-1-3-project-creation-customization)に掲載されています。
プロジェクトを生成するとき、2番目の引数として著者の名前を渡すことができます。この引数は symfony が新しいクラスを生成するときに PHPDoc の
`...@author` タグに使う値を指定します。
@@ -430,14 +430,14 @@
### `sfBaseTask::setConfiguration()`
-PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run()` に `--application` と `--env`
オプションを渡す必要はもはやありません。その代わりに、`->setConfiguration()`
を呼び出すだけで設定オブジェクトを直接セットすることができます。
+PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run()` に `--application` と `--env`
オプションを渡す必要はもはやありません。その代わりに`->setConfiguration()`
を呼び出すだけで設定オブジェクトを直接セットすることができます。
[php]
$task = new sfDoctrineLoadDataTask($this->dispatcher, $this->formatter);
$task->setConfiguration($this->configuration);
$task->run();
-以前のバージョンでは、次のように書けばまだ動きます:
+以前のバージョンでは次のように書けばまだ動きます:
[php]
$task = new sfDoctrineLoadDataTask($this->dispatcher, $this->formatter);
@@ -448,7 +448,7 @@
### `project:disable` と `project:enable`
-`project:disable` と `project:enable` タスクを使うことで、環境全体を無効もしくは有効にできるようになりました:
+`project:disable` と `project:enable` タスクを使うことで環境全体を無効もしくは有効にできるようになりました:
$ php symfony project:disable prod
$ php symfony project:enable prod
@@ -506,7 +506,7 @@
Propel との統合
---------------
-Propel のバージョンは 1.4 にアップグレードされました。Propel
のアップグレードに関する詳しい情報は[公式サイト](http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4)を訪問してくださるようお願いします。
+Propel のバージョンは 1.4
にアップグレードされました。詳しいアップグレード情報に関しては[公式サイト](http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4)を訪問してくださるようお願いします。
### Propel のビヘイビア
@@ -514,7 +514,7 @@
### `propel:insert-sql`
-`propel:insert-sql`
はデータベースからすべてのデータを削除する前に確認の問い合わせを行います。このタスクは複数のデータベースからデータを削除することができるので、関連するデータベースの接続名も表示するようになりました。
+`propel:insert-sql`
はデータベースからすべてのデータを削除する前に削除してよいのか尋ねます。このタスクは複数のデータベースからデータを削除することができるので、関連するデータベースの接続名も表示するようになりました。
###
`propel:generate-module`、`propel:generate-admin`、`propel:generate-admin-for-route`
@@ -588,7 +588,7 @@
### カラー出力
-symfony の CLI を使うとき、symfony はご利用のコンソールがカラー出力をサポートしているかどうかを推測します。ただし、たとえば
Cygwin を使っている場合に推測が間違っていることがあります (Windows プラットフォームではカラー出力はつねにオフだからです)。
+symfony CLI を使うとき、symfony はご利用のコンソールがカラー出力をサポートしているかどうかを推測します。ただし、たとえば Cygwin
を使っている場合に推測が間違っていることがあります (Windows プラットフォームではカラー出力がつねにオフだからです)。
symfony 1.3/1.4 では、グローバルオプションの `--color` を渡すことでカラー出力を強制できるようになりました。
@@ -634,7 +634,7 @@
`sfProtoculousPlugin` もしくは `sfCompat10Plugin` のようなコアプラグインを使いたい場合、必要なのは対応する
`enablePlugins()` メソッドを `ProjectConfiguration` クラスに追加することだけです。
>**NOTE**
->symfony 1.2 からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが
`ProjectConfiguration` ファイルを変更しないからです。新しいふるまいの適用は symfony 1.3/1.4 の新規プロジェクトのみです。
+>symfony 1.2 からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが
`ProjectConfiguration` ファイルを変更しないからです。新しいふるまいが適用されるのは symfony 1.3/1.4
の新規プロジェクトだけです。
### `sfPluginConfiguration::connectTests()`
@@ -654,9 +654,9 @@
### `sf_file_link_format`
-symfony 1.3/1.4 は可能であればファイルパスをクリック可能なリンク (すなわちデバッグ例外のテンプレート)
にフォーマットします。`sf_file_link_format` がセットされている場合、この目的に使われ、そうでなければ、symfony は PHP
コンフィギュレーションの `xdebug.file_link_format` の値を探します。
+symfony 1.3/1.4 は可能であればファイルパスをクリック可能なリンク (すなわちデバッグ例外のテンプレート)
にフォーマットします。`sf_file_link_format` がセットされている場合、この目的に使われ、そうでなければ symfony は PHP
コンフィギュレーションの `xdebug.file_link_format` の値を探します。
-たとえば、ファイルを TextMate で開きたい場合、次のコードを `settings.yml` に追加します:
+たとえばファイルを TextMate で開きたい場合、次のコードを `settings.yml` に追加します:
[yml]
all:
@@ -674,7 +674,7 @@
Doctrine の YAML スキーマファイルのなかで symfony
の追加オプションを指定できるようになりました。そしてフォームとフィルタクラスの生成を無効にするオプションもいくつか追加されました。
-たとえば、 典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタフォームクラスを生成させる必要はありません。ですので次のようなことができます:
+たとえば典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタフォームクラスを生成させる必要はありません。ですので次のようなことができます:
UserGroup:
options:
@@ -699,7 +699,7 @@
#### モデルテーブルを作る
-指定モデルの配列のためにテーブルを個別に作ることができるようになりました。テーブルを削除するとき Doctrine
はあなたに代わってテーブルを再作成してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を一掃したくなく単にテーブル群を再構築したいときに役立ちます。
+指定モデルの配列のためにテーブルを個別に作ることができるようになりました。テーブルを削除するとき、 Doctrine
はあなたに代わってテーブルを再作成してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を一掃したくなく単にテーブル群を再構築したいときに役立ちます。
$ php symfony doctrine:create-model-tables Model1 Model2 Model3
@@ -709,7 +709,7 @@
$ php symfony doctrine:delete-model-files ModelName
-上記タスクは関連する生成ファイルを見つけ、そのファイルを削除したいかどうかあなたに報告してくれます。
+上記タスクは関連する生成ファイルを見つけ、そのファイルを削除したいかどうか尋ねます。
#### モデルファイルをきれいにする
@@ -883,7 +883,7 @@
}
}
-以前のバージョンでこれを動かすには、ウィジェットをメソッドを作ることに加えて `getFields()` を拡張する必要がありました。
+以前のバージョンでこれを動かすには、ウィジェットとメソッドを作ることに加えて `getFields()` を拡張する必要がありました。
### Doctrine を設定する
@@ -931,7 +931,7 @@
### スロットの改善
-スロットが提供されない場合、`get_slot()` と `include_slot()`
ヘルパーは戻り値として返すスロットのデフォルト内容を指定するための2番目のパラメータを受け取ります:
+スロットが提供されない場合、`get_slot()` と `include_slot()`
ヘルパーは2番目の引数として受け取ったスロットのデフォルト内容を返します:
[php]
<?php echo get_slot('foo', 'bar') // foo スロットが定義されていなければ bar が出力される ?>
@@ -955,7 +955,7 @@
ビューキャッシュ
-----------------
-ビューキャッシュマネージャは `factories.yml`
でパラメータを受け取ります。クラスを異なる方法で簡単に拡張できるようにビューのキャッシュキーの生成はリファクタリングされました。
+ビューキャッシュマネージャは `factories.yml`
のなかのパラメータを受け取ります。クラスを異なる方法で簡単に拡張できるようにビューのキャッシュキーの生成はリファクタリングされました。
`factories.yml` で2つのパラメータが利用できます:
Modified: doc/branches/1.4/tutorial/ja/which-version.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-24 17:06:38 UTC
(rev 28766)
+++ doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-24 17:30:54 UTC
(rev 28767)
@@ -3,7 +3,7 @@
symfony 1.3 と symfony 1.4
のドキュメントの内容はまったく同じです。2つの異なるバージョンに対してドキュメントが1つしかない状況はめったにないので、このドキュメントでは2つのバージョンの主な違いが何であり、あなたのプロジェクトのために最善の選択をどのようにすればよいのかを説明します。
-symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009年末)
にリリースされ、実際のところ、これらは両方とも**まったく同じ機能一式**を備えています。2つのバージョンの唯一の違いは symfony
の古いバージョンとの後方互換性のサポートです。
+symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009年末)
にリリースされ、実際のところ、これらのバージョンは両方とも**まったく同じ機能一式**を備えています。2つのバージョンの唯一の違いは symfony
の古いバージョンとの後方互換性のサポートです。
古い symfony のバージョン (1.0、1.1 もしくは 1.2) を使うレガシープロジェクトをアップグレードするのであれば symfony 1.3
を選びます。このバージョンは廃止予定であるがまだ利用可能な後方互換性レイヤーとすべての機能を備えています。このことはアップグレードが楽でシンプルであり、そして安全でもあることを意味します。
--
You received this message because you are subscribed to the Google Groups
"symfony SVN" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/symfony-svn?hl=en.
