Update ja

_po/ja/reference/plugin/handler/index.po

@@ -24,8 +24,7 @@ msgstr "## 概要 {#abstract}"
 
 msgid ""
 "Each Droonga Engine plugin can have its *handler*.\n"
-"On the handling phase, handlers can process any incoming message and output va"
-"rious messages (ex. a \"response\" for a \"request\") as you like."
+"On the handling phase, handlers can process a request and return a result."
 msgstr ""
 
 msgid "### How to define a handler? {#howto-define}"
@@ -41,18 +40,22 @@ msgstr ""
 
 msgid ""
 "module Droonga::Plugins::FooPlugin\n"
-"  Plugin.registry.register(\"foo\", self)"
+"  extend Plugin\n"
+"  register(\"foo\")"
 msgstr ""
 
 msgid ""
-"  class Handler < Droonga::Handler\n"
-"    # operations to configure this handler\n"
-"    XXXXXX = XXXXXX"
+"  define_single_step do |step|\n"
+"    step.name = \"foo\"\n"
+"    step.handler = :Handler\n"
+"    step.collector = Collectors::And\n"
+"  end"
 msgstr ""
 
 msgid ""
-"    def handle(message, messenger)\n"
-"      # operations to process incoming messages\n"
+"  class Handler < Droonga::Handler\n"
+"    def handle(message)\n"
+"      # operations to process a request\n"
 "    end\n"
 "  end\n"
 "end\n"
@@ -65,9 +68,10 @@ msgstr ""
 msgid ""
 " 1. Define a module for your plugin (ex. `Droonga::Plugins::FooPlugin`) and re"
 "gister it as a plugin. (required)\n"
+" 2. Define a \"single step\" corresponding to the Configure conditions for the h"
+"andler. (required)\n"
 " 2. Define a handler class (ex. `Droonga::Plugins::FooPlugin::Handler`) inheri"
 "ting [`Droonga::Handler`](#classes-Droonga-Handler). (required)\n"
-" 3. [Configure conditions for the handler](#howto-configure). (required)\n"
 " 4. Define handling logic for incoming messages as [`#handle`](#classes-Droong"
 "a-Handler-handle). (optional)"
 msgstr ""

_po/ja/tutorial/plugin-development/adapter/index.po

@@ -9,14 +9,11 @@ msgstr ""
 
 msgid ""
 "---\n"
-"title: \"Plugin: Modify requests and responses\"\n"
+"title: \"Plugin: Adapt requests and responses, to add a new command based on ot"
+"her existing commands\"\n"
 "layout: en\n"
 "---"
 msgstr ""
-"---\n"
-"title: \"プラグイン: リクエストとレスポンスの変更\"\n"
-"layout: ja\n"
-"---"
 
 msgid ""
 "* TOC\n"

_po/ja/tutorial/plugin-development/index.po

@@ -45,8 +45,8 @@ msgstr ""
 
 msgid ""
 "Generally, data processing tasks in the real world need custom treatments of t"
-"he data, in various stages of the data stream. This is not easy to be done in "
-"one-size-fits-all approach."
+"he data, in various stages of the data stream.\n"
+"This is not easy to be done in one-size-fits-all approach."
 msgstr ""
 
 msgid ""
@@ -104,12 +104,40 @@ msgid ""
 msgstr ""
 
 msgid ""
-"In this tutorial, we focus on the adaption phase at first.\n"
+"However, the point of view of these descriptions is based on the design of the"
+" system itself, so you're maybe confused.\n"
+"Then, let's shift our perspective on pluggable operations - what you want to d"
+"o by a plugin."
+msgstr ""
+
+msgid ""
+"Adding a new command based on another existing command.\n"
+": For example, you possibly want to define a shorthand command wrapping the co"
+"mplex `search` command.\n"
+"  *Adaption* of request and response messages makes it come true."
+msgstr ""
+
+msgid ""
+"Adding a new command working around the storage.\n"
+": For example, you possibly want to modify data stored in the storage as you l"
+"ike.\n"
+"  *Handling* of requests makes it come true."
+msgstr ""
+
+msgid ""
+"Adding a new command for a complex task\n"
+": For example, you possibly want to implement a powerful command like the buil"
+"t-in `search` command.\n"
+"  *Planning and collection* of requests make it come true."
+msgstr ""
+
+msgid ""
+"In this tutorial, we focus on the adaption at first.\n"
 "This is the most \"basic\" usecase of plugins, so it will help you to understand"
 " the overview of Droonga plugin development.\n"
-"Then, we focus an other phases in this order.\n"
-"Following this tutorial, you will learn how to write plugins. This will be the"
-" first step to create plugins fit with your own requirements."
+"Then, we focus an other cases in this order.\n"
+"Following this tutorial, you will learn how to write plugins.\n"
+"This will be the first step to create plugins fit with your own requirements."
 msgstr ""
 
 msgid "## How to develop plugins?"
@@ -119,10 +147,14 @@ msgid "For more details, let's read these sub tutorials:"
 msgstr ""
 
 msgid ""
-" 1. [Modify requests and responses][adapter]\n"
-" 2. [Handle requests on all partitions][handler]\n"
-" 3. Handle requests only on a specific partition (under construction)\n"
-" 4. Distribute requests and collect responses (under construction)"
+" 1. [Adapt requests and responses, to add a new command based on other existin"
+"g commands][adapter].\n"
+" 2. [Handle requests on all partitions, to add a new command working around th"
+"e storage][handler].\n"
+" 3. Handle requests only on a specific partition, to add a new command around "
+"the storage more smartly. (under construction)\n"
+" 4. Distribute requests and collect responses, to add a new complex command ba"
+"sed on sub tasks. (under construction)"
 msgstr ""
 
 msgid ""

ja/reference/plugin/handler/index.md

@@ -19,7 +19,7 @@ layout: en
 ## 概要 {#abstract}
 
 Each Droonga Engine plugin can have its *handler*.
-On the handling phase, handlers can process any incoming message and output various messages (ex. a "response" for a "request") as you like.
+On the handling phase, handlers can process a request and return a result.
 
 
 ### How to define a handler? {#howto-define}
@@ -30,14 +30,18 @@ For example, here is a sample plugin named "foo" with a handler:
 require "droonga/plugin"
 
 module Droonga::Plugins::FooPlugin
-  Plugin.registry.register("foo", self)
+  extend Plugin
+  register("foo")
 
-  class Handler < Droonga::Handler
-    # operations to configure this handler
-    XXXXXX = XXXXXX
+  define_single_step do |step|
+    step.name = "foo"
+    step.handler = :Handler
+    step.collector = Collectors::And
+  end
 
-    def handle(message, messenger)
-      # operations to process incoming messages
+  class Handler < Droonga::Handler
+    def handle(message)
+      # operations to process a request
     end
   end
 end
@@ -46,8 +50,8 @@ end
 Steps to define a handler:
 
  1. Define a module for your plugin (ex. `Droonga::Plugins::FooPlugin`) and register it as a plugin. (required)
+ 2. Define a "single step" corresponding to the Configure conditions for the handler. (required)
  2. Define a handler class (ex. `Droonga::Plugins::FooPlugin::Handler`) inheriting [`Droonga::Handler`](#classes-Droonga-Handler). (required)
- 3. [Configure conditions for the handler](#howto-configure). (required)
  4. Define handling logic for incoming messages as [`#handle`](#classes-Droonga-Handler-handle). (optional)
 
 See also the [plugin development tutorial](../../../tutorial/plugin-development/handler/).

ja/tutorial/plugin-development/adapter/index.md

@@ -1,6 +1,6 @@
 ---
-title: "プラグイン: リクエストとレスポンスの変更"
-layout: ja
+title: "Plugin: Adapt requests and responses, to add a new command based on other existing commands"
+layout: en
 ---
 
 {% comment %}

ja/tutorial/plugin-development/index.md

@@ -26,7 +26,8 @@ Droongaプラグインの作り方を理解します。
 プラグインはDroongaの中でもっとも重要なコンセプトの一つです。
 プラグインがDroongaを柔軟なものにしています。
 
-Generally, data processing tasks in the real world need custom treatments of the data, in various stages of the data stream. This is not easy to be done in one-size-fits-all approach.
+Generally, data processing tasks in the real world need custom treatments of the data, in various stages of the data stream.
+This is not easy to be done in one-size-fits-all approach.
 
  * One may want to modify incoming requests to work well with other systems, one may want to modify outgoing responses to help other systems understand the result.
  * One may want to do more complex data processing than that provided by Droonga as built-in, to have direct storage access for efficiency.
@@ -57,19 +58,35 @@ Planning phase
 Collection phase
 : At this phase, a plugin can merge results from steps to a unified result.
 
-In this tutorial, we focus on the adaption phase at first.
+However, the point of view of these descriptions is based on the design of the system itself, so you're maybe confused.
+Then, let's shift our perspective on pluggable operations - what you want to do by a plugin.
+
+Adding a new command based on another existing command.
+: For example, you possibly want to define a shorthand command wrapping the complex `search` command.
+  *Adaption* of request and response messages makes it come true.
+
+Adding a new command working around the storage.
+: For example, you possibly want to modify data stored in the storage as you like.
+  *Handling* of requests makes it come true.
+
+Adding a new command for a complex task
+: For example, you possibly want to implement a powerful command like the built-in `search` command.
+  *Planning and collection* of requests make it come true.
+
+In this tutorial, we focus on the adaption at first.
 This is the most "basic" usecase of plugins, so it will help you to understand the overview of Droonga plugin development.
-Then, we focus an other phases in this order.
-Following this tutorial, you will learn how to write plugins. This will be the first step to create plugins fit with your own requirements.
+Then, we focus an other cases in this order.
+Following this tutorial, you will learn how to write plugins.
+This will be the first step to create plugins fit with your own requirements.
 
 ## プラグインを開発するには
 
 For more details, let's read these sub tutorials:
 
- 1. [Modify requests and responses][adapter]
- 2. [Handle requests on all partitions][handler]
- 3. Handle requests only on a specific partition (under construction)
- 4. Distribute requests and collect responses (under construction)
+ 1. [Adapt requests and responses, to add a new command based on other existing commands][adapter].
+ 2. [Handle requests on all partitions, to add a new command working around the storage][handler].
+ 3. Handle requests only on a specific partition, to add a new command around the storage more smartly. (under construction)
+ 4. Distribute requests and collect responses, to add a new complex command based on sub tasks. (under construction)
 
 
   [basic tutorial]: ../basic/