Changeset 13315 for docs

Timestamp:

06/06/08 05:25:48 (5 years ago)

Author:

charsbar

Message:

finished Catalyst-Manual-ExtendingCatalyst? translation

Files:

• docs/perldoc/Catalyst/Manual/ExtendingCatalyst.pod (modified) (68 diffs, 1 prop)

docs/perldoc/Catalyst/Manual/ExtendingCatalyst.pod

@@ -1 @@
-=head1 名前(NAME)
-
-Catalyst::Manual::ExtendingCatalyst - フレームワークを拡張する
-
-=head1 概要(DESCRIPTION)
+=head1 名前
+
+Catalyst::Manual::ExtendingCatalyst - Catalystを拡張する (version 5.013)
+
+=head1 概要
 
 This document will provide you with access points, techniques and best
@@ -9 +9 @@
 ways to abstract and use your own code.
 
-このドキュメントでは Catalyst を拡張する方法やどうやってエレガントにあなたのコー
-ドを抽象化するかについて論じます。
+このドキュメントではCatalystフレームワークをどこから拡張するか、どうやって拡張するか、そしてどう拡張するのがベストなのかを紹介します。Catalystフレームワークを抽象化して自分なりのコードで差し替える方法にもいろいろありますが、なるべくエレガントなやり方を覚えていってください。
 
 The design of Catalyst is such that the framework itself should not
@@ -18 +17 @@
 and their consequences.
 
-Catalyst はいろんな方法で拡張できるので、あなたは混乱しているかもしれません。この
-ドキュメントではそのあたりの詳細を論じます。
+Catalystは「フレームワークそのものの制約でできない」ことがないように設計されています。いろいろなところでふるまいを変えたり拡張したりできるようになっている分、混乱しやすいともいえますが、このドキュメントを読めば、どのようなことができるか、いまどうしているか、そしてその結果どうなるかが理解できるはず。
 
 Please read the L<BEST PRACTICES> section before deciding on a design,
@@ -26 +24 @@
 most if we all work together and coordinate.
 
-あなたのコードを CPAN にうpするまえに、とりあえず L<BEST PRACTICES> の章をよみま
-しょう。 Catalyst の開発者とユーザコミュニティはあなたとともにあります。
+アプリやモジュールを設計する前に、ぜひL<BEST PRACTICES>の項を読んでください。CPANにアップしようと思っているならなおさらです。Catalystの開発陣にとってもユーザコミュニティ（B<みなさんもその一員ですからね！>）にとっても、全員の足並みが揃っているにこしたことはないのですから。
 
 If you are unsure on an implementation or have an idea you would like
@@ -38 +35 @@
 starting.
 
-あなたがなにか実装にまつわるアイディアをもっているのであれば、Catalyst の ML,
-IRC などで話しかけてください。
-
-=head1 ベストプラクティス(BEST PRACTICES)
+実装に悩んだり、規約（RFC）にしたいアイディアがあるなら、ぜひ質問や提案をメーリングリスト(See L<Catalyst/SUPPORT>)に流してください。C<irc.perl.org>のC<#catalyst>チャンネルに来るのもおすすめです。これから実装しようと思っているモジュールがすでに存在しないか確認したいときもそうですね。ぴったりのモジュールを教えてもらえるかもしれませんし、とっかかりくらいは得られると思いますよ。
+
+=head1 BEST PRACTICES
 
 During Catalyst's early days, it was common to write plugins to
@@ -49 +45 @@
 the scope of its influence as close as possible to where it belongs.
 
-Catalyst が若かりしころ、複数アプリにまたがる機能はプラグインにするのがよいとされ
-えいましたが、現在ではもっとフレキシブルでパワフルな方法があります。
+Catalystも当初はプラグインを書いてアプリケーションのどこからでも機能を利用できるようにするのが一般的でしたが、その後、Catalystもずいぶん柔軟・強力になったので、すぐに抽象化の仕方やインタフェースを変えて、なるべくスコープの及ぶ範囲を狭くするのがベストプラクティスになりました。
 
 For those in a hurry, here's a quick checklist of some fundamental
@@ -56 +51 @@
 forward to L</Namespaces>.
 
-もし君がめっちゃいそいでいるのなら、以下に必須のポイントに関するクイックチェック
-リストを容易したからそれだけでもよんでいきたまえ。もし君がまったりとこの文書を全
-部読むつもりなら L</Namespaces> に進む。
-
-=head2 3分間チェックリスト(Quick Checklist)
+せっかちな方は大事なポイントをまとめた早見表をどうぞ。ひととおり目を通しておこうという方は、L</Namespaces>の話からでもOKです。
+
+=head2 Quick Checklist
 
 =over
 
-=item C<CatalystX::*> というネームスペースをつかいましょう(Use the C<CatalystX::*> namespace if you can!)
+=item Use the C<CatalystX::*> namespace if you can!
+
+なるべくC<CatalystX::*>というネームスペースをつかいましょう!
 
 If your extension isn't a Model, View, Controller, Plugin, or Engine,
@@ -70 +65 @@
 <CatalystX::> instead.
 
-もしあなたの拡張が Model でも View でも Controller でも Plugin でも Engine でもな
-ければ、それは C<Catalyst::> というネームスペースにおくべきではありません。
-C<CatalystX::> をかわりにつかってください。
-
-=item プラグインはつくらない(どうしてもつくらなきゃいけない場合をのぞいて)!(Don't make it a plugin unless you have to!)
+もしあなたの拡張が Model でも View でも Controller でも Plugin でも Engine でもないなら、C<Catalyst::> というネームスペースにおくべきではありません。C<CatalystX::> をかわりにつかってください。
+
+=item Don't make it a plugin unless you have to!
+
+どうしようもないとき以外はプラグインにしないこと!
 
 A plugin should be careful since it's overriding Catalyst internals.
@@ -80 +75 @@
 base Controller or Model.
 
-プラギンは Catalyst の内部をうわがきしちゃうので、注意してね!もしチミのプラグイン
-が、内部を上書きしたいんでなければ、Controller か Model にしてね!
-
-=item コミュニティがあるから利用しちゃおう!(There's a community. Use it!)
+プラグインは Catalyst の内部を上書きしてしまうので、（書くときも使うときも）細心の注意が必要。どうしてもCatalystの内部をいじる必要があるのでなければ、ベースControllerにするか、Modelにすること。
+
+=item There's a community. Use it!
+
+コミュニティがあるんだから活用すること!
 
 There are many experienced developers in the Catalyst community,
 there's always the IRC channel and the mailing list to discuss things.
 
-Catalyst には IRC も ML もあるから、どんどん利用しちゃおう!
-
-=item テストとドキュメンテーションはしっかりね!(Add tests and documentation!)
+Catalystコミュニティにはベテランプログラマがたくさんいますし、話をしたければいつでもIRCチャンネルなりメーリングリストなりがある、ということ。
+
+=item Add tests and documentation!
+
+テストやドキュメントも忘れずに!
 
 This gives a stable basis for contribution, and even more importantly,
@@ -96 +94 @@
 L<Catalyst::Manual::Tutorial::Testing> for more information.
 
-あたりまえのことだけど、テストとドキュメンテーションをしない人はお尻ペンペンだよ!
+こういうのがあるとアプリやモジュールが安定しますし、なにより信頼感がうまれます。いちばん簡単なのはテストアプリを用意すること。詳しくはL<Catalyst::Manual::Tutorial::Testing>を読みましょう。
 
 =back
 
-=head2 ネームスペース(Namespaces)
+=head2 Namespaces
 
 While some core extensions (engines, plugins, etc.) have to be placed
@@ -106 +104 @@
 developers to use the C<CatalystX::*> namespace if possible.
 
-コアの拡張(engine や plugin とか)は、C<Catalyst::*> におくべきだけど、そういうの
-つくるときは開発者に相談してからにしよう。できることなら C<CatalystX::*> におこう。
-
-(訳注: CPAN にアップロードする場合、相談してからやらないと mst に痛烈に DIS られます)
+エンジンやプラグインのようにコアを拡張する場合はC<Catalyst::*>のネームスペース内に入れてもらうしかありませんが、Catalystのコアメンバーは、一般の開発者のみなさんにはなるべくC<CatalystX::*>のネームスペースを使ってほしいと思っています。
 
 When you try to put a base class for a C<Model>, C<View> or
@@ -119 +114 @@
 as examples.
 
-もしC<Model>, C<View>, C<Controller>のベースクラスをC<MyApp>の下、たとえばC<MyApp::Controller::Foo>、に置くとCatalystがそれをロードしようとするのでちょっとトラぶっちゃうと思います。解決方法は簡単で、C<MyApp::Base::Controller::*>::やC<MyApp::ControllerBase::*>なんかのネームスペースを使うといいでしょう。
-
-=head2 それをシンプルなモジュールにすることはできませんか?(Can it be a simple module?)
+C<MyApp::Controller::Foo>のように、C<MyApp>ディレクトリの直下にC<Model>やC<View>、C<Controller>のベースクラスを置いてしまうと、ベースクラスもアプリケーションのコンポーネントとみなされて問題が起こる可能性があるので、別のネームスペースを使いましょう。C<MyApp::Base::Controller::*>とかC<MyApp::ControllerBase::*>というのがよくある例です。
+
+=head2 Can it be a simple module?
+
+ふつうのモジュールにした方がよくないですか？
 
 Sometimes you want to use functionality in your application that
@@ -131 +128 @@
 try to load them as components.
 
-Catalyst はたんなる Perl であることを思いだしてください。C<use> でいつでもモジュー
-ルをつかえるんですよ。フレームワークと連携することが必要ないアプリケーション専用
-のコードであれば、C<MyApp::*> というネームスペースをつかってください。C<Model>,
-C<Controller>, C<View> というネームスペースにはおかないでください。このネームスペー
-スにおくと Catalyst がコンポーネントとしてロードしちゃいまっせ。
+つくっているアプリによっては、Catalystとはまったく関係ない機能を使いたくなることもあるものですが、Catalystは単なるPerlのコードでしかないということはお忘れなく。必要ならいつでもモジュールをC<use>すればいいんです。特定のアプリ専用のコードの場合、Catalystの機能が必要ないならC<MyApp::*>ネームスペースのなかに入れてしまってもかまいません。ただし、C<Model>やC<Controller>、C<View>の下には入れないこと。コンポーネントとしてロードされてしまいますから。
 
 Writing a generic component that only works with Catalyst is wasteful
@@ -147 +140 @@
 convenient.
 
-Catalyst に依存した一般的なコンポーネントをつくることは、あなたの時間を無駄に浪費
-させます。素の Perl モジュールを書くことを検討してください。そして、Catalyst とは
-ほんのちょっとの連携コードで連携させてください。このような方法論でつくられたモ
-ジュールの代表例は Catalyst::Model::DBIC::Schema ですので参考にしてください。この
-方法のよさは、DBIC のスキーマが完全に Catalyst の外でうごいているということです。
-こうすることによって、テストが楽になり、コマンドラインスクリプトも簡単に書けます。
-現実の Catalyst の Model は、ほんとにちょっとの連携コードで便利につかえるようにつ
-なぎこまれてるのだ。
+一般的なコンポーネントなのにCatalystでしか使えないようなものを書くのは時間のむだです。そういうのはプレーンなperlモジュールにしてしまいましょう。そのあとでちょっとした「つなぎ」を書いてCatalystで使えるようにすればいいんです。L<Catalyst::Model::DBIC::Schema|Catalyst::Model::DBIC::Schema>がそういうアプローチをとっています。そうしておくと、「Catalyst用の」DBICスキーマがCatalystの外でも何の問題もなく使えますから、テスト（やコマンドラインツール）を書くのが簡単になるのが長所。Catalyst用のModel本体はスキーマを使いやすくするためのつなぎを数行書くだけです。
 
 If you want the thinnest interface possible, take a look at
 L<Catalyst::Model::Adaptor|Catalyst::Model::Adaptor>.
 
-もし、薄いインターフェースで連携できるんなら Catalyst::Model::Adaptor でつなぎこ
-むのがよいです。
-
-=head2 継承とメソッドのうわがき。(Inheritance and overriding methods)
+もっとインタフェースを薄くしたいのであれば、L<Catalyst::Model::Adaptor|Catalyst::Model::Adaptor>をどうぞ。
+
+=head2 Inheritance and overriding methods
+
+継承とメソッドのオーバーライド
 
 While Catalyst itself is still based on L<NEXT> (for multiple
-inheritance), extension developers are encouraged to use L<Class::C3>,
-which is what Catalyst will be switching to in some point in the
-future.
-
-CatalystはまだNEXTベースだけど拡張モジュールを作る人はClass::C3を使うといいよ。Catalystもそのうちそうなるから。
+inheritance), extension developers are encouraged to use L<Class::C3>,which is what Catalyst will be switching to in some point in the future.
+
+Catalyst自体はまだ（多重継承できるように）L<NEXT>をベースにしていますが、拡張を開発する人はL<Class::C3>を使ってください。将来的にはCatalyst本体もこちらに切り替わる予定です。
 
 When overriding a method, keep in mind that some day additionally
@@ -177 +162 @@
 you can pass your complete arguments to the original method via C<@_>:
 
-メソッドをオーバーライドする場合は将来引数が追加されることを考慮して以下のようにするといい。
+メソッドをオーバーライドする場合は、そのメソッドにいつか新しい引数が追加されるかもしれないということを忘れずに。特に最後のパラメータがフラットなリストでない場合は要注意。メソッドをオーバーライドするときは呼び出し元をC<@_>からshiftで取り出してから、残りを割り当てるようにしましょう。こうしておけば、もとのメソッドにすべての引数を渡すときにC<@_>を使えるようになります。
 
   use Class::C3; ...
@@ -187 +172 @@
 If you would do the common
 
+よくあることですが、こんな風にしてしまうと
+
   my ($self, $foo, $bar) = @_;
 
@@ -192 +179 @@
 will be passed along and the method is future proof:
 
+かなりきたない方法を使わないと、すべての引数を次のメソッドに回して将来の変更に備えることができなくなってしまいます。
+
   $self->next::method(@_[ 1 .. $#_ ]);
 
-=head2 テストとドキュメンテーション(Tests and documentation)
+=head2 Tests and documentation
+
+テストとドキュメント
 
 When you release your module to the CPAN, proper documentation and at
@@ -203 +194 @@
 invaluable.
 
-CPAN にモジュールをリリースするにあたっては、きちんとしたドキュメンテーションと、
-テストスィーツ(use_ok してりゃいいってもんじゃないよ)を提供してくださいな。
+CPANにモジュールをアップするなら、きちんとドキュメントを書いて、最低でも基本的なテストは用意しましょう（悪いけど、PODのテストや、ただC<use_ok>するだけのものではだめですよ）。こうしておくとほかの人がパッチなどを送りやすくなりますし、作者であるあなたがユーザのことを気にかけているという証拠にもなります。ほかの人にも自分のモジュールを使ってほしいなら、こういうのはとっても大事です。
 
 If you're just getting started, try using
@@ -210 +200 @@
 tests for your module.
 
-もし君が、あたらしくつくりはじめるんなら CatalystX::Starter をつかってみてくださ
-いな。テストの例がはいっているよ。
-
-=head2 メンテナンス(Maintenance)
+これから書き始めるのであれば、L<CatalystX::Starter|CatalystX::Starter>を使うとテストのサンプルが生成されます。
+
+=head2 Maintenance
+
+メンテナンス
 
 In planning to release a module to the community (Catalyst or CPAN and
@@ -219 +210 @@
 date, including fixing bugs and accepting contributions.
 
+モジュールを（Catalyst、あるいはCPANやPerlの）コミュニティに公開するつもりがあるなら、きちんと更新できるか、バグをなおしたりパッチをあてたりできるだけのリソースがあるか、よく考えること。
+
 If you're not sure about this, you can always ask in the proper
 Catalyst or Perl channels if someone else might be interested in the
 project, and would jump in as co-maintainer.
+
+自信がないなら、いつでもCatalystやPerl向けの適切なチャンネルでたずねてみましょう。誰かが興味を持ってくれて、共同メンテナーになってくれるかもしれません。
 
 A public repository can further ease interaction with the
@@ -228 +223 @@
 are broadly preferred in the Catalyst community.
 
+公開リポジトリがあるとさらにコミュニティとのやりとりが簡単になります。たとえリードオンリーであろうと、ほかの人に現在の開発版にパッチを書いてもらえるようになるのですから。Catalystコミュニティではsubversion（SVN、SVK）が広く使われています。
+
 If you're developing a Catalyst extension, please consider asking the
 core team for space in Catalyst's own subversion repository. You can
@@ -233 +230 @@
 list.
 
-リリースしたモジュールをアップデートしたり、バグフィックスしたりしてね。
-
-みんながパッチを送れるように開発中のリポジトリを公開しておくのもいいね。
-
-とか。
-
-=head2 コンテキストオブジェクト(The context object)
+Catalystの拡張を書いているなら、ぜひIRCやCatalystの開発者向けメーリングリストでコアメンバーに声をかけて、本家のsubversionリポジトリに入れてもらうことを考えてみてください。
+
+=head2 The context object
+
+コンテキストオブジェクトについて
 
 Sometimes you want to get a hold of the context object in a component
@@ -246 +241 @@
 context information (current language, for example).
 
-起動時に作成されたコンポーネントの中でコンテキストオブジェクトを使いたい場合もあります。
+場合によっては（まだコンテキストが存在していない）起動時に作成したコンポーネントにコンテキストオブジェクトを持たせたい場合もあります。stashなどからなにか（たとえば現在の言語など）を読み込みたいモデルの場合は特にそうです。
 
 If you use the context object in your component you have tied it to an
@@ -253 +248 @@
 outside of Catalyst, for example in cronjobs.
 
-しかし、コンポーネントの中でコンテキストオブジェクトを使うということはリクエストとコンポーネントを結びつけるという意味であり、Catalystの外でそのコンポーネントを使おうとした場合に問題となります。
+ただし、コンポーネントのなかでコンテキストオブジェクトを使うと、そのコンポーネントは既存のリクエストにしばられてしまうことになります。つまり、そのコンポーネント（たいていの場合はモデル）をCatalystの外、たとえばcronjobのなかで使おうとしたときに困ることになりかねません。
 
 A stable solution to this problem is to design the Catalyst model
@@ -266 +261 @@
 directly.
 
-解決方法はCatalystのモデルはモデルロジックとは切り離して設計することです。たとえばL<Catalyst::Model::DBIC::Schema>を見るといいでしょう。スキーマはCatalystとは切り離されてます。このような設計はカプセル化を促進し、メンテナンス性もよくなります。
+確実な解決策としては、Catalystのモデルを、ベースとなるモデルのロジック層から分離してしまうという手があります。たとえばL<Catalyst::Model::DBIC::Schema>の場合、スキーマはCatalystの外に用意できます。Webのことなどいっさい知りません。このように設計しておくと、確実にカプセル化できますし、開発にしろメンテにしろ、はるかに簡単になります。で、このスキーマをアプリとつなぐときにL<Catalyst::Model::DBIC::Schema>を使うわけです。そうすると、C<MyApp::DBIC>（もちろんこの名前はサンプルですよ）というモデルのほかに、C<MyApp::DBIC::TableName>というモデルが用意されて、直接リザルトソースにアクセスできるようになります。
 
 By creating such a thin layer between the actual model and the
@@ -273 +268 @@
 information from the context object.
 
-このように薄いレイヤーを実際のモデルとCatalystの間に用意することで、モデル自身はアプリケーションに結び付けず、レイヤーの部分はコンテキストオブジェクトからの情報を使ってモデルAPIにアクセスできるようになります。
+このように実際のモデルとCatalystアプリとの間に薄いレイヤーをつくっておくと、スキーマそのものがアプリにしばられることはなくなりますし、間に入っているレイヤーのおかげでコンテキストオブジェクトの情報を利用してモデルのAPIにアクセスできるようになります。
 
 A Catalyst component accesses the context object at request time with
 L<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">.
 
-CatalystのコンポーネントはL<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">を使うことでリクエスト時にコンテキストオブジェクトにアクセスできます。
-
-=head1 設定(CONFIGURATION)
+ちなみにCatalystのコンポーネントはリクエスト時でもL<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">を使えばコンテキストオブジェクトにアクセスできます。
+
+=head1 CONFIGURATION
+
+設定について
 
 The application has to interact with the extension with some
 configuration. There is of course again more than one way to do it.
 
-アプリケーションはいくつかの設定によって拡張モジュールと協調します。もちろん、やり方は複数あります。
-
-=head2 アトリビュート(Attributes)
+アプリが拡張とやりとりする場合はなんらかの設定が必要ですが、もちろんこれにもやり方はいろいろあります。
+
+=head2 Attributes
+
+アトリビュート
 
 You can specify any valid Perl attribute on Catalyst actions you like.
@@ -295 +294 @@
 action:
 
-Perlで使える属性がすべて使えます。属性はC<Catalyst::Action>のインスタンスでC<attributes>アクセサを介して使用できます。
+Catalystのアクションには文法的に正しければどんなアトリビュートでもつけられます（有効なアトリビュートについてはL<attributes/"Syntax of Attribute Lists">をどうぞ）。これらはC<Catalyst::Action>のC<attributes>アクセサ経由で取得できます。一例をあげましょう。
 
   sub foo : Local Bar('Baz') {
@@ -311 +310 @@
 class|/"Component Base Classes">.
 
-これはレスポンスボディにBazをセットします。値は常に配列のリファレンスです。
-
-=head2 カスタムアクセサをつくる(Creating custom accessors)
+こうすると、レスポンスのbodyがC<Baz>になります。アトリビュートの値はかならず配列のリファレンスになります。わかると思いますが、アトリビュートを使ってアクションの設定をすることもできます。このアトリビュートはL<コンポーネントの設定|/"Component Configuration">でも指定・変更できますし、自前のL<コンポーネントのベースクラス|/"Component Base Classes">を用意すればCatalystがアトリビュートを見つけたときにすぐ処理をするようにもできます。
+
+=head2 Creating custom accessors
+
+カスタムアクセサをつくる
 
 L<Catalyst::Component> uses L<Class::Accessor::Fast> for accessor
@@ -319 +320 @@
 information.
 
-L<Catalyst::Component> はアクセサをつくるのに L<Class::Accessor::Fast> をつかって
-います。
-
-=head2 コンポーネントの設定(Component configuration)
+L<Catalyst::Component>はL<Class::Accessor::Fast>を使ってアクセサをつくっています。使い方についてはそれぞれのドキュメントを参照ということで。
+
+=head2 Component configuration
+
+コンポーネントの設定
 
 At creation time, the class configuration of your component (the one
@@ -330 +332 @@
 object's hash reference. So, if you read possible configurations like:
 
-作成時にコンポーネントのクラス設定（C<$self-E<gt>config>で使えるやつ）はアプリケーション設定で使用可能な設定とマージされます。で、これらはコントローラオブジェクトのハッシュリファレンスに保存されます。なので設定は以下のように読み込むことができます。
+コンポーネントのインスタンスを作成するときには、クラスの設定（C<$self-E<gt>config>でアクセスできるもの）とアプリケーションの設定（直書きしてあったり設定ファイルから読み込んだりしたもの）をマージしたものがオブジェクトのハッシュリファレンスに保存されます。だから、このようにすれば
 
   my $model_name = $controller->{model_name};
@@ -338 +340 @@
 component configuration.
 
-C<config>アクセサは常に元のクラス設定のみを含んでいて、コンポーネント設定のためには使われません。
+正しい値が得られます。C<config>にはかならずもとのクラスの設定のみが入っているようにしてください。コンポーネントの設定としては使ってはいけません。
 
 You are advised to create accessors on your component class for your
@@ -346 +348 @@
 L<Class::Accessor::Fast>:
 
-設定値用に以下のようなアクセサを用意しておくと便利です。
+コンポーネントクラスには設定用のアクセサを用意しましょう。これはグッドプラクティスですし、設定のキーに間違いがあったときにエラーを見つけやすくなります。L<Catalyst::Component>にはL<Class::Accessor::Fast>のC<mk_ro_accessors>メソッドが生えていますので、それを使えばよいでしょう。
 
   use base 'Catalyst::Controller';
@@ -353 +355 @@
   my $model_name = $controller->model_name;
 
-=head1 実装(IMPLEMENTATION)
+=head1 IMPLEMENTATION
+
+実装について
 
 This part contains the technical details of various implementation
@@ -359 +363 @@
 implementation, if you haven't already.
 
-いろんな実装方法の詳細を説明します。
-
-=head2 Actionクラス(Action classes)
+ここではいろいろな拡張の実装方法についての技術的な話をします。まだ読んでいない方は実装を始める前にL</"BEST PRACTICES">を読んでください。
+
+=head2 Action classes
+
+アクションクラス
 
 Usually, your action objects are of the class L<Catalyst::Action>.
@@ -369 +375 @@
 created Catalyst application in your root controller:
 
-アクションオブジェクトはL<Catalyst::Action>クラスのインスタンスです。C<ActionClass>属性を使うことでこの挙動に影響を与えることができます。広く使われている例ではL<Catalyst::Action::RenderView>があります。
+ふつうアクションオブジェクトはL<Catalyst::Action>クラスのものですが、C<ActionClass>アトリビュートを使うとアクションの実行やディスパッチ処理をオーバーライドできます。
 
   sub end : ActionClass('RenderView') { }
@@ -378 +384 @@
 subclass:
 
-大抵の場合、C<execute>やC<match>メソッドをオーバーライドすることになるでしょう。サブクラスでexecuteメソッドをオーバーライドすることでメソッドをラップすることができます。
+ふつうオーバーライドしたくなるのはC<execute>メソッドやC<match>メソッドでしょう。executeはもちろんメソッドのコードを実行するためのものです。このメソッドをサブクラスのなかでオーバーライドすると、前後に処理を追加できます。
 
   package Catalyst::Action::MyFoo; use strict;
@@ -397 +403 @@
 in the L<Catalyst::Action> class.
 
-L<Catalyst::Action>クラスにある元のC<execute>メソッドに再度ディスパッチするためにL<Class::C3>を使ってます。
+ここではL<Class::C3>を使って、L<Catalyst::Action>のなかにあるもとのC<execute>メソッドにディスパッチしなおしています。
 
 The Catalyst dispatcher handles an incoming request and, depending
@@ -406 +412 @@
 the action will match and add new matching criteria.
 
-C<match>メソッドをオーバーライドするとCatalystのディスパッチャの挙動を変更できます。
+Catalystのディスパッチャは受け取ったリクエストを解釈し、タイプに応じて適切なターゲットやチェーンを呼び出すわけですが、場合によってはアクションそのものに（あるいはコントローラ経由で）現在のリクエストにマッチしているか確認することもあります。このときに使われるのがC<match>メソッドです。だから、これをオーバーライドすると、どのアクションがマッチするかを変更できますし、新しいマッチングルールを追加することもできます。
 
 For example, the action class below will make the action only match on
 Mondays:
 
-たとえば以下のアクションクラスは月曜日にだけマッチします。
+たとえば、このアクションクラスは月曜日に限ってマッチします。
 
   package Catalyst::Action::OnlyMondays; use strict;
@@ -427 +433 @@
 And this is how we'd use it:
 
-こうやって使います。
+使い方はこんな感じ。
 
   sub foo: Local ActionClass('OnlyMondays') {
@@ -438 +444 @@
 a component base class providing an attribute handler.
 
+こういうアクションクラスをしょっちゅう使うとか、既存のベースクラスをもっと便利に使いたい場合は、コンポーネントのベースクラスにアトリビュートハンドラを持たせることもできます。
+
 For further information on action classes, please refer to
 L<Catalyst::Action> and L<Catalyst::Manual::Actions>.
 
-=head2 コンポーネントなクラス(Component base classes)
+アクションクラスの詳細についてはL<Catalyst::Action>やL<Catalyst::Manual::Actions>をどうぞ。
+
+=head2 Component base classes
+
+コンポーネントのベースクラス
 
 Many L<Catalyst::Plugin> that were written in Catalyst's early days
@@ -448 +460 @@
 not polluting the global namespace in the context object.
 
-Catalyst がうまれたての頃に多くの L<Catalyst::Plugin> が書かれました。
+Catalystの初期に書かれたL<Catalyst::Plugin>の多くは、本当は単なるコントローラのベースクラスにするべきものでした。そうしておけば機能をひとつのコントローラのなかに閉じこめておけますし、コンテキストオブジェクトのグローバルなネームスペースを汚すこともなかったのです。
 
 You can provide regular Perl methods in a base class as well as
 actions which will be inherited to the subclass. Please refer to
 L</Controllers> for an example of this.
+
+ベースクラスにはふつうのメソッドを書くこともできますし、アクションを書くこともできます（これらはサブクラスに継承されます）。サンプルについてはL</Controllers>をどうぞ。
 
 You can introduce your own attributes by specifying a handler method
@@ -460 +474 @@
 already provided via the C<+> prefix for action classes. A simple
 
-シンプルな
+コントローラのベースクラスにハンドラメソッドを用意すると、自前のアトリビュートを使えるようにもできます。たとえば、C<FullClass>というアトリビュートを使ってアクションクラス名の完全修飾名を指定したい場合は、こんな風に書けます（ただし、この機能はすでに本体に実装されています。使い方はアクションクラスにC<+>というプレフィックスをつけるだけ。つまり、こう書くだけで
 
   sub foo : Local ActionClass('+MyApp::Action::Bar') { ... }
@@ -466 +480 @@
 will use C<MyApp::Action::Bar> as action class.
 
-は、C<MyApp::Action::Bar> を Action クラスとしてつかいます。
+C<MyApp::Action::Bar>がアクションクラスになります）。
 
   package MyApp::Base::Controller::FullClass; use strict; use base
@@ -481 +495 @@
 Catalyst attribute:
 
+念のため、引数を省略しなかったのは単に抜けをつくりたくなかったからです。サブクラスではこのアトリビュートをほかのアトリビュートと同様に利用できます。
+
   package MyApp::Controller::Foo;
   use strict;
@@ -489 +505 @@
   1;
 
-=head2 コントローラ(Controllers)
+=head2 Controllers
+
+コントローラ
 
 Many things can happen in controllers, and it often improves
@@ -495 +513 @@
 classes.
 
+コントローラではさまざまな処理が行われるので、コードの一部を抽象化して再利用できるベースクラスにしてしまった方がメンテナンス性が向上する場合が多いです。
+
 You can provide usual Perl methods that will be available via your
 controller object, or you can even define Catalyst actions which will
 be inherited by the subclasses. Consider this controller base class:
+
+ふつうのメソッドを用意しておけばコントローラオブジェクトから利用できますし、アクションを定義してサブクラスに継承させることさえできます。たとえばこんなコントローラのベースクラスを考えてみましょう。
 
   package MyApp::Base::Controller::ModelBase;
@@ -528 +550 @@
 handling, input validation, and probably other things.
 
+この例ではシンプルなアクションをふたつ実装しています。C<list>アクションは（いまのところ存在していない）C<base>アクションにぶら下がり、設定済みのC<model_name>や検索条件、検索オプションを取り出してリザルトセットをstashに入れる役割をしています。このアクションはL<チェーン|Catalyst::DispatchType::Chained>の終端です。もう一方のC< load >アクションはチェーンの中間部分で、引数をひとつとり、その値をIDとみなして、設定済みのモデルから該当する行を読み込みます。念のため、上のコードは説明のためにあえて簡単にしていますが、ほんとうはエラー処理や入力値の検証などが必要ですよ。
+
 The class above is not very useful on its own, but we can combine it
 with some custom actions by sub-classing it:
+
+上のクラスそのものはあまり役に立ちませんが、サブクラス化すればほかのカスタムアクションも組み込めます。
 
   package MyApp::Controller::Foo;
@@ -553 +579 @@
 class. Next comes the C<base> action, where everything chains off of.
 
+このクラスはさっきつくったコントローラがベースクラスになっています。最初に親クラスで使っていた設定があって、次にすべてのチェーンの起点となるC<base>アクションが来ています。
+
 Note that inherited actions act like they were declared in your
 controller itself. You can therefor call them just by their name in
@@ -558 +586 @@
 important part of what makes this technique so useful.
 
+継承したアクションもコントローラのなかで宣言されているかのようにふるまいます。C<forward>やC<detach>、C<Chained(..)>の指定にアクション名を書くだけで呼び出せるというのが、この便利なテクニックの肝です。
+
 The new C<view> action ties itself to the C<load> action specified in
 the base class and outputs the loaded row's C<name> and C<description>
@@ -563 +593 @@
 publicly available paths:
 
+新しいC<view>というアクションは、ベースクラスで指定されているC<load>アクションにぶら下がって、読み込まれた行のC<name>とC<description>を出力します。この段階でC<MyApp::Controller::Foo>というコントローラには以下のようなパスがパブリックになっています。
+
 =over
 
@@ -569 +601 @@
 Will call the controller's C<base>, then the base classes C<list>
 action.
+
+コントローラのC<base>アクション、ベースクラスのC<list>アクションの順に呼ばれます。
 
 =item /foo/$id/view
@@ -576 +610 @@
 display some fields out of the object.
 
+まずはコントローラのC<base>が呼ばれ、次にC<load>でC<$id>に対応する行が読み込まれ、それからC<view>で行オブジェクトのフィールドが出力されます。
+
 =back
 
-=head2 モデルとビュー(Models and Views)
+=head2 Models and Views
+
+モデルとビュー
 
 If the functionality you'd like to add is really a data-set that you
@@ -584 +622 @@
 files, it might be better suited as a model.
 
+追加したい機能が実は内部文書の種類や画像、ファイルといったデータセットの操作だった場合は、モデルにした方がよいかもしれません。
+
 The same applies for views. If your code handles representation or
 deals with the applications interface and should be universally
 available, it could be a perfect candidate for a view.
+
+ビューの場合もそう。追加したいコードが表示まわりだったり、アプリケーションのインタフェースにかかわるものだったり、アプリケーションの外からも利用できないといけない場合は、ビューにするのが一番かもしれません。
 
 Please implement a C<process> method in your views. This method will
@@ -593 +635 @@
 but a simple Perl method.
 
+ビューの場合はC<process>メソッドを実装してください。このメソッドはアクションを指定せずにコンポーネントにC<forward>したときに呼ばれるものです。C<process>はB<Catalystのアクションではなく>、単なるPerlのメソッドですのでお間違えなく。
+
 You are also encouraged to implement a C<render> method corresponding
 with the one in L<Catalyst::View::TT>. This has proven invaluable,
@@ -598 +642 @@
 generation.
 
+また、L<Catalyst::View::TT>のようなC<render>メソッドも実装しましょう。このメソッドがあると、もっと細かいコンテンツ生成をしたいときにもビューを使えるようになるのでとても便利です。
+
 Here is some example code for a fictional view:
+
+これは架空のビューのコード例です。
 
   package CatalystX::View::MyView;
@@ -618 +666 @@
   1;
 
-=head2 プラグイン(Plugins)
+=head2 Plugins
+
+プラグイン
 
 The first thing to say about plugins is that if you're not sure if
@@ -626 +676 @@
 became obvious that this qualifies as bad practice.
 
-まずもって、あなたがプラグインをつくろうとおもっている場合、十中八九プラグインを
-つくるべきではありません。
+まず、プラグインにする必要があるかどうかわからないモジュールは、たぶんプラグインにするべきではありません。昔はCatalystに機能を追加したくなったらプラグインを書いて、その機能を呼び出すアクセサを用意するのが一般的でしたが、Catalystがいろいろな人に使われるようになってくると、これはバッドプラクティスであることがわかりました。
 
 By designing your module as a Catalyst plugin, every method you
@@ -634 +683 @@
 should be only doing that when you really need to.
 
-あなたのモジュールを Catalyst のプラグインとして実装した場合、あなたが実装したす
-べてのメソッドはあなたのアプリケーションの context object に継承されます。プラグ
-インはグローバルなネームスペースをけがします。あなたはほんとうにそうしたいときに
-だけそうするべきです。
+Catalystのプラグインにしてしまうと、自分で実装したり、インポートしたり継承したりしたすべてのメソッドがアプリのコンテキストオブジェクトから利用できるようになってしまいます。プラグインはグローバルなネームスペースを汚染してしまうのですが、そういうことをしてもいいのは、どうしても必要な場合のみ。
 
 Often, developers design extensions as plugins because they need to
@@ -646 +692 @@
 object via L<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">.
 
+プラグインにしてしまう理由としてよく言われるのがコンテキストオブジェクトをいじる必要がある、ということ。stashや、request/responseオブジェクトを使いたいという言い訳をよく聞きますが、こういうのはふつうのCatalystコンポーネント（つまり、モデルやビュー、コントローラ）として実装してもまったく問題ありません。現在のコンテキストオブジェクトはL<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">で受け取れます。
+
 When is a plugin suited to your task? Your code needs to be a
 plugin to act upon or alter specific parts of Catalyst's request
@@ -651 +699 @@
 C<finalize_*> stages, you won't get around a plugin.
 
+プラグインが適切な場合？　Catalystがリクエストを処理するサイクルの一部に手を入れる場合はプラグインにする必要があります。C<prepare_*>とかC<finalize_*>をラップする必要があるならプラグインにせざるをえない、ということです。
+
 Another valid target for a plugin architecture are things that
 B<really> have to be globally available, like sessions or
 authentication.
+
+もうひとつプラグインにしてもいいのは、B<本当に>どこからでも利用できないと困る、セッションとか認証など。
 
 B<Please do not> release Catalyst extensions as plugins only to
@@ -660 +712 @@
 your code only influences those parts of the application where it is
 needed, and namespace clashes and conflicts are ruled out.
+
+単になにかの機能をアプリ全体で利用したいからというだけの理由でプラグインにするのはB<やめてください>。コントローラのベースクラスのようにもっとスコープの小さなものにして影響の及ぶ範囲を必要なところのみに限り、ネームスペースの衝突などが起こらないようにしましょう。
 
 The implementation is pretty easy. Your plugin will be inserted in the
@@ -671 +725 @@
 implementation (excuse the lame class name, it's just an example):
 
-プラグインの実装は簡単なようにみえます。あなたのプラグインは Catalyst の継承ツリー
-の上にはいります。これによりあなたは、Catalyst のリクエストライフサイクルの挙動を
-変えることができます。あなたが定義したりあなたのパッケージに import したメソッド
-は、すべてアプリケーションとコンテキストオブジェクトにはえます。例としてあなたが
-Catalyst に uri_for の返り値が undef だったとき警告をだすプラグインをつくったとし
-ましょう。(中略)(アホみたいなクラス名ですいません。これは例なので勘弁してね)
+実装の仕方はとても簡単。プラグインはアプリの継承リストの、Catalyst本体より優先順位の高いところに追加されていきます（だからリクエストのライフサイクルの挙動を変更できるわけです）。プラグインで宣言したメソッド、パッケージ内にインポートしたメソッドはすべてアプリから、またコンテキストオブジェクトから利用できるようになります。たとえば、uri_forが未定義値を返すたびに警告を出させたいとしましょう（たとえばアクションチェーンのキャプチャの数が間違っていた場合などに知らせてほしいわけです）。こういうのはこんなにシンプルに実装できます（クラス名がださいのはサンプルだからということでご勘弁）
 
   package Catalyst::Plugin::UriforUndefWarning;
@@ -695 +744 @@
 value.
 
-これは Catalyst の C<uri_for> メソッドをうわがきし、undef がかえってきたら警告を
-ログに吐きだします。
-
-=head2 COMPONENT() をつかってコンポーネントを生成する(Factory components with COMPONENT())
+これで、CatalystのC<uri_for>メソッドがオーバーライドされて、未定義値を返した引数を含むC<warn>ログが出るようになります。
+
+=head2 Factory components with COMPONENT()
+
+COMPONENT() をつかってコンポーネントを生成する
 
 Every component inheriting from L<Catalyst::Component> contains a
@@ -707 +757 @@
 class' C<new> method to return the component object.
 
-L<Catalyst::Component> を継承しているすべてのコンポーネントは C<COMPONENT> メソッ
-ドをもっています。
+L<Catalyst::Component>を継承しているコンポーネントにはかならずC<COMPONENT>というメソッドがあります。これはアプリの起動時にC<setup_components>がコンポーネントオブジェクトを初期化するときに使うもの。デフォルトではコンポーネント自身のC<config>とアプリ全体のC<config>をマージして、コンポーネントクラスのC<new>を呼び、コンポーネントオブジェクトを返すようになっています。
 
 You can override this method and do and return whatever you want.
@@ -714 +763 @@
 C<COMPONENT> method to merge the configuration of your component.
 
+このメソッドも、オーバーライドすれば好きなものを返すようにできます。ただし、その場合はL<Class::C3>を使ってもとのC<COMPONENT>メソッドに処理を送り、コンポーネントの設定をマージするようにしてください。
+
 Here is a stub C<COMPONENT> method:
+
+C<COMPONENT>メソッドのスタブはこんな感じ。
 
   package CatalystX::Component::Foo;
@@ -736 +789 @@
 the controller's configuration.
 
+引数は、コンポーネントのクラス名、そのコンポーネントを使うアプリケーションのクラス名、コントローラの設定が入っているハッシュリファレンスです。
+
 You are free to re-bless the object, instantiate a whole other
 component or really do anything compatible with Catalyst's
 expectations on a component.
 
+オブジェクトをblessしなおすのでも、ほかのコンポーネントのインスタンスをつくるのでも、とにかくCatalystがコンポーネントに期待する条件を満たしているなら本当に何をしてもかまいません。
+
 For more information, please see L<Catalyst::Component/"COMPONENT($c,$arguments)">.
 
+詳しくはL<Catalyst::Component/"COMPONENT($c,$arguments)">をどうぞ。
+
 =head1 SEE ALSO
 
@@ -751 +810 @@
 
 Jonathan Rockway C<< <jrockway@cpan.org> >>
+
+=head1 TRANSLATORS
+
+tokuhirom
+
+charsbar
 
 =head1 LICENSE AND COPYRIGHT
@@ -758 +823 @@
 
 =cut
+