[jboss-cvs] JBossAS SVN: r73192 - projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Fri May 9 02:42:44 EDT 2008


Author: khashida at redhat.com
Date: 2008-05-09 02:42:44 -0400 (Fri, 09 May 2008)
New Revision: 73192

Modified:
   projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po
Log:
several changes

Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po	2008-05-09 06:15:46 UTC (rev 73191)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/ja-JP/Clustering_Guide_HTTP.po	2008-05-09 06:42:44 UTC (rev 73192)
@@ -11,7 +11,7 @@
 "Project-Id-Version: Clustering_Guide_HTTP\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2007-12-10 22:33+0000\n"
-"PO-Revision-Date: 2008-05-07 17:27+1000\n"
+"PO-Revision-Date: 2008-05-09 16:39+1000\n"
 "Last-Translator: Kiyoto Hashida <khashida at redhat.com>\n"
 "Language-Team: Japanese <jp at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -34,7 +34,7 @@
 "crashes, another node in the cluster will be able to recover. Two distinct "
 "functions must be performed:"
 msgstr ""
-"HTTP セッションレプリケーションは、クラスターの他のノード群でユーザーが "
+"HTTP セッション複製は、クラスターの他のノード群でユーザーが "
 "使用中の web クライアントに関連した状態を複製するのに使用されます。そのため、 "
 "使用中のノードの1つがクラッシュした場合、クラスター内の別のノードが復元 "
 "することができます。以下の2つの卓越した機能を発揮する必要があります:"
@@ -113,12 +113,7 @@
 "その要求を該当するノードに配達します。これはスティッキーセッション付きロードバランシングと "
 "呼ばれ、1度セッションがノード上に作成されると全ての将来の要求はその同じノードによって処理されます。 "
 "セッション複製用に web アプリケーションを設定しないまま、スティッキーセッション付きロードバランシングを "
-"使用するとセッション状態複製のコストを回避しながら、各クエリが常に同じノードで処理されるようになります。 "
-"しかし、1つのノードが停止した場合、このノードでホストされていた全てのクライアントセッション(例えば、 "
-"ショッピングカート)は、消滅して、クライアントは多分別のノードにログインして新しいセッションを始める "
-"必要があるでしょう。多くの状況では、全ての重大状態はデータベース内に保存されるため、HTTP セッションを "
-"複製しなくても対応可能です。その他の状況では、クライアントセッションの消滅は対応できないこともあります。 "
-"この場合、セッション状態の複製は必要事項となります。"
+"使用するとセッション状態複製のコストを回避しながら、各クエリが常に同じノードで処理されるようになります。 しかし、1つのノードが停止した場合、このノードでホストされていた全てのクライアントセッション(例えば、 ショッピングカート)は、消滅して、クライアントは多分別のノードにログインして新しいセッションを始める必要があるでしょう。多くの状況では、全ての重大状態はデータベース内に保存されるため、HTTP セッションを複製しなくても対応可能です。それ以外の状況では、クライアントセッションの消滅は対応できないこともあります。この場合、セッション状態の複製は必要事項となります。"
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:26
@@ -162,10 +157,10 @@
 msgstr ""
 "まず最初に、Apache がインストールされていることを確認します。Apache は直接 "
 "Apache web サイト<literal>http://httpd.apache.org/</literal> からダウンロードできます。 "
-"このインストールは実に一本調子なため特別な設定は必要ありません。数種のバージョンの Apache が "
-"存在しますので、バージョン 2.0.x の使用をお薦めします。次のセクションになるとユーザーがもう "
-"<literal>APACHE_HOME</literal> ディレクトリに Apache をインストール終了していると "
-"想定します。"
+"このインストールは実に一本調子なため、特別な設定は必要ありません。数種のバージョンの Apache が "
+"存在しますので、バージョン 2.0.x の使用をお薦めします。次のセクションではユーザーがもう "
+"<literal>APACHE_HOME</literal> ディレクトリに Apache をインストール終了していることを "
+"想定しています。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:39
@@ -190,7 +185,7 @@
 #: Clustering_Guide_HTTP.xml:47
 #, no-c-format
 msgid "Configure Apache to load mod_jk"
-msgstr "mod_jk をロードするように Apache を設定"
+msgstr "mod_jk をロードする為に Apache を設定"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:48
@@ -572,9 +567,7 @@
 "over these workers."
 msgstr ""
 "<literal>conf/workers.properties</literal> ファイルの最後の部分はロードバランサーワーカーを "
-"定義します。ユーザーが変更すべき唯一の部分は、<literal>worker.loadbalancer.balanced_workers</literal> の行です。 "
-"これは同じファイル内で以前に定義されていた全てのワーカーを一覧する必要があります。ロードバランシングは "
-"これらのワーカー上で実行されます。"
+"定義します。ユーザーが変更すべき唯一の部分は、<literal>worker.loadbalancer.balanced_workers</literal> の行です。これは同じファイル内で以前に定義されていた全てのワーカーを一覧する必要があります。ロードバランシングはこれらのワーカー上で実行されます。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:108
@@ -598,7 +591,7 @@
 "1つのセッションを開くと、それはそのサーバーが利用できる限り、このユーザーの要求を常に "
 "同じサーバーに転送することが必要になります。これは、クライアントが常にその最初の "
 "要求で到達したものと同じサーバーを使用するため、スティッキーセッション(\"sticky session\")と "
-"呼ばれます。このセッションを sticky 状態 にするには、<literal>worker.loadbalancer."
+"呼ばれます。このセッションをスティッキー状態 にするには、<literal>worker.loadbalancer."
 "sticky_session</literal> を 1 にセットする必要があります。"
 
 #. Tag: para
@@ -969,8 +962,7 @@
 "must use the same cluster name."
 msgstr ""
 "<emphasis role=\"bold\">ClusterName</emphasis> は、その中でキャッシュが機能するクラスターの "
-"名前を指定します。デフォルトのクラスター名は、 \"Tomcat-\" と言う言葉に  現在の JBoss パーティション名を追記した"
-"名前となります。全てのノードが同じクラスター名を使用しなければなりません。"
+"名前を指定します。デフォルトのクラスター名は、 \"Tomcat-\" と言う言葉に  現在の JBoss パーティション名を追記した名前となります。全てのノードが同じクラスター名を使用しなければなりません。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:187
@@ -1148,7 +1140,7 @@
 "will mark the read attributes as needing to be replicated."
 msgstr ""
 "<emphasis role=\"bold\">SET_AND_GET</emphasis>: このポリシーでは、「get」 か 「set」の属性は "
-"「dirty 」 としてマークされることになります。あるオブジェクトがセッションから取り込まれて "
+"「dirty (不正)」 としてマークされることになります。あるオブジェクトがセッションから取り込まれて "
 "セッションの書き換えなしにオブジェクトが修正された場合、そのオブジェクトへの変更は複製されます。 "
 "SET_AND_GET の短所は、セッションからの不変のオブジェクト(文字列や数字)の読み込みでも複製を "
 "必要とする読み込み属性としてマークされるために、かなりのパフォーマンス問題を孕んでいる点です。"
@@ -1201,13 +1193,8 @@
 "アクセスされる度に「dirty」としてマークされるようにします。セッションはそれぞれの "
 "HTTP 要求の間にアクセスされるため、セッションは各要求毎に複製されます。ACCESS の "
 "目的は セッションの最終アクセスタイムスタンプがクラスター中で同期化状態に維持されていることを "
-"確実にすることです。他の複製発動オプションでは、タイムスタンプは、複製がない場合に他のクラスターノード内で "
-"更新されない可能性があるため、他のノード内のセッションは、HTTP 要求がセッション属性の取り込みや修正を "
-"しない場合は、アクティブノード以前に時間切れになる可能性があります。このオプションがセットしてある場合、 "
-"セッションタイムスタンプはクラスターノード全体に渡って同期化されます。このオプションの使用はかなりの "
-"パフォーマンス問題を持つため、注意して使用して下さい。その他の複製発動オプションでは、セッションが "
-"複製なしにその期限間隔の 80% まで来ると、安全対策としてそのタイムスタンプはどの状態でも複製されます。 "
-"その為、ACCESS は、上記の安全対策が不適切とされる特別な状況でのみで役に立つことになります。"
+"確実にすることです。他の複製発動オプションでは、タイムスタンプは、複製がない場合に他のクラスターノード内で 更新されない可能性があるため、他のノード内のセッションは、HTTP 要求がセッション属性の取り込みや修正を しない場合は、アクティブノード以前に時間切れになる可能性があります。このオプションがセットしてある場合、 セッションタイムスタンプはクラスターノード全体に渡って同期化されます。このオプションの使用はかなりのパフォーマンス問題を持つため、注意して使用して下さい。その他の複製発動オプションでは、セッションが "
+"複製なしのままにその期限間隔の 80% まで来ると、安全対策としてそのタイムスタンプはどの状態でも複製されます。 その為、ACCESS は、上記の安全対策が不適切とされる特別な状況でのみで役に立つことになります。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:230
@@ -1273,7 +1260,7 @@
 msgstr ""
 "<emphasis role=\"bold\">FIELD</emphasis>: 複製はセッション属性オブジェクトの内部の "
 "個別の変更データフィールドのためだけとなります。共有オブジェクト照合はクラスター全体に "
-"渡って保存されています。かなりのパフォーマンスの可能性がありますが、ユーザーのアプリケーション "
+"渡って保存されています。かなりのパフォーマンス潜在能力がありますが、ユーザーのアプリケーション "
 "への変更が必要になります(後で説明があります)。"
 
 #. Tag: para
@@ -1369,7 +1356,7 @@
 "annotate an interface with InstanceofAopMarker and all of its implementing "
 "classes will be annotated. For example:"
 msgstr ""
-"代わりに1つのクラスに InstanceAopMarker で注釈と付けると、そのサブクラスの全ても "
+"代わりに1つのクラスに InstanceAopMarker で注釈を付けると、そのサブクラスの全ても "
 "自動的に注釈を受けます。同様に、1つのインターフェイスに InstanceofAopMarker で "
 "注釈を付けると、その実装するクラスの全てが注釈を受けます。例えば:"
 
@@ -1716,7 +1703,7 @@
 "アプリケーションが適切に <literal>distributable</literal> としてマークされていないか、又は、 "
 "HTTP セッション内に値を配置するアプリケーションの部分にユーザーがアクセスしていないことになります。 "
 "<literal>org.jboss.cache</literal> と <literal>org.jboss.web</literal> のロギングカテゴリーは、 "
-"デバグ目的に役に立つようなセッション複製への追加の見解を与えてくれます。"
+"デバグ目的に役に立つようなセッション複製への更なるの見解を与えてくれます。"
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:338
@@ -1740,7 +1727,7 @@
 "JBoss はクラスター化した単独のサインオンをサポートして、ユーザーが JBoss サーバー上で "
 "1つの web アプリケーションに認証を受け、クラスター内の同じマシン上、あるいは同じ仮想 "
 "ホスト上に導入されている別のノードで全ての web アプリケーションでも認識されるようにします。 "
-"Authentication 複製は、HTTP セッション複製サービスで使用される同じ JBoss Cache Mbean によって "
+"Authentication 複製は、HTTP セッション複製サービスで使用されるのと同じ JBoss Cache Mbean によって "
 "処理されます。セッション複製は要点となるアプリケーション用に明示的に有効にする必要はありませんが "
 "<literal>jboss-web-cluster.sar</literal> ファイルは導入される必要があります。"
 
@@ -1815,9 +1802,9 @@
 "JBoss Application Server (AS) はユーザーがクラスター化した singleton サービスを導入できるように "
 "数多くの戦略用サポートを提供します。このセクションでは、異なる戦略を探索してみます。全ての "
 "戦略は序説で説明があるように HAPartition サービスの上に築きあげられています。これらは、 "
-"クラスター内の別々のノード群が開始したり、停止したりする時に、通知を提供する <literal>HAPartition</literal> に "
-"依存します。これらの通知を土台にしてクラスター内の各ノードは独立して(でも均一に)、それ自身が "
-"その時点でマスターノードなのか、そしてサービスを提供する必要があるのかを判定します。"
+"クラスター内の別々のノード群が開始したり、停止したりする時に、通知を提供する <literal>HAPartition</literal> に依存します。これらの通知を土台にしてクラスター内の各ノードは独立して "
+"(でも均一に)、それ自身がその時点でマスターノードなのか、そしてサービスを提供する必要があるのかを判定 "
+"します。"
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:365
@@ -1930,7 +1917,7 @@
 "そのサービスの為に自身がマスターノードかどうか判定するのは HASingletonController の仕事です。 "
 "自身がマスターノードであると判定した場合、それはサービスに1つのメソッドを呼び起こしてサービスの "
 "提供を開始するように指示します。それがもうマスターではないと判定した場合、使用しているサービスに "
-"1つのメソッドを呼び起こしてサービスの提供を停止するように指示します。以下のその状況を解説していきます。"
+"1つのメソッドを呼び起こしてサービスの提供を停止するように指示します。以下にその状況を解説していきます。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:397
@@ -1941,7 +1928,7 @@
 "method that can be called when it should begin providing service, and "
 "another that can be called when it should stop providing service:"
 msgstr ""
-"先ず、ここでは、HA singleton にしたい MBean サービスがあります。これについて "
+"先ず、ここに、HA singleton にしたい MBean サービスがあります。これについて "
 "唯一特別なことは MBean インターフェイスの中で、サービスの提供を開始すべき時に "
 "コールできて、そしてサービスの提供を停止すべき時にもコールできるメソッドを出す必要が "
 "あることです。"
@@ -2076,7 +2063,7 @@
 #: Clustering_Guide_HTTP.xml:410
 #, no-c-format
 msgid "Voila! A clustered singleton service."
-msgstr "ここにクラスター化した singleton サービスがあります。"
+msgstr "これで、クラスター化した singleton サービスができました。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:412
@@ -2178,8 +2165,7 @@
 "ここに面白いことがいくつかあります。その一つめは、制御されているサービスは <literal>MainDeployer</literal> "
 "サービスであり、これは JBoss の中核となる導入サービスです。すなわち、これは、 "
 "<literal>HASingletonController</literal> で制御されることを意図して書かれているのではないと "
-"いうことです。しかしそれでも機能します。二つめは、ターゲットの開始と停止のメソッドは「deploy(導入)」と "
-"「undeploy(導入解除)」です。それらが特定の名前を持つとか、論理的な開始と停止の機能を持つと言う "
+"いうことです。しかしそれでも機能します。二つめは、ターゲットの開始と停止のメソッドは「deploy(導入)」と 「undeploy(導入解除)」です。それらが特定の名前を持つとか、論理的な開始と停止の機能を持つと言う "
 "要求はありません。ここでは、呼び起こされるメソッドの機能は、どちらかと言うと、「実行」、「実行停止」の "
 "ようなものです。最後に “<literal>TargetStart(Stop)MethodArgument</literal>” 属性に注意して下さい。 "
 "ユーザーの singleton サービスの 開始/停止メソッドは引数を取ることができます。その場合、 "
@@ -2247,8 +2233,7 @@
 "hasingleton must be copied manually on all nodes."
 msgstr ""
 "deploy-hasingleton のコンテンツが全てのノード上でコピーされる必要があるのに対し、我々は"
-"farming を使用してサービスを分配することができます。この意味でこの方法が deploy-hasingleton アプローチへの "
-"代替を提供します。"
+"farming を使用してサービスを分配することができます。この意味でこの方法が deploy-hasingleton アプローチへの代替を提供します。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:440
@@ -2287,9 +2272,9 @@
 "literal>) will not have the desired effect."
 msgstr ""
 "Barrier は 依存しているサービスの開始/停止を制御しますが、<literal>BarrierController</"
-"literal> が破壊/導入解除する時だけに発生する、それらの破壊はしません。そのため、 "
-"<literal>Barrier</literal> を使用して、その通常の「導入解除」操作 の一部として"
-"(例、<literal>EJBContainer</literal>)「破壊」する必要のあるサービスを制御することは "
+"literal> が破壊/導入解除する時だけに発生する破壊は実行しません。そのため、 "
+"<literal>Barrier</literal> を使用して、その通常の「導入解除」操作の一部として"
+"(例、<literal>EJBContainer</literal>)「破壊」する必要のあるサービスを制御しても "
 "期待する効果を出しません。"
 
 #. Tag: title
@@ -2344,7 +2329,7 @@
 "to be the case.)"
 msgstr ""
 "例として、4ノードのクラスターがあると想定しましょう。ノード A からノード D まで、 "
-"そして現在の一覧表示は {A, B, C, D} として表現できます。一般的に言うとこの一覧内の "
+"そして現在の一覧表示は {A, B, C, D} として表現しましょう。一般的に言うとこの一覧内の "
 "ノードの順番は、それらがクラスターに参加した順番を反映していると言えます "
 "(常にこのようになるとは言えません。これが定説とは言えません)。"
 




More information about the jboss-cvs-commits mailing list