Translate v2 docs in Japanese. #428

Merged
merged 83 commits into from Dec 5, 2016

Projects

None yet

8 participants

@kitak
Contributor
kitak commented Oct 29, 2016 edited

TODO

docs/ja/getting-started.md
+
+1. Vuex ストアはリアクティブです。 Vue コンポーネントがストアから状態を取り出すとき、もしストアの状態が変化したら、ストアはリアクティブかつ効率的に更新を行います。
+
+2. ストアの状態を直接変更することはできません。明示的に**ミューテーションをコミットする**ことによってのみ、ストアの状態を変更します。これによって、全ての状態の変更について追跡可能な記録を残すことが保証され、ツールでのアプリケーションの動作の理解を助けます。
@inouetakuya
inouetakuya Nov 11, 2016 edited

@kitak @tadyjp

  1. You cannot directly mutate the store's state. The only way to change a store's state is by explicitly committing mutations. This ensures every state change leaves a track-able record, and enables tooling that helps us better understand our applications.

I am not really sure about the translation of "committing mutations".

Which do you think is the best?

  • ミューテーションをコミットする
  • ミューテーションを送る
  • another idea?
@ktsn
ktsn Nov 11, 2016 Member

メソッド名と対応しているので「ミューテーションをコミットする」が良いと思います。

@inouetakuya
inouetakuya Nov 12, 2016

ありがとうございます!「ミューテーションをコミットする」でいこうと思います!

@inouetakuya

@kitak Modules(modules.md) の翻訳やりたいですー

@inouetakuya

@kitak Application Structure(structure.md) の翻訳やりたいですー

@inouetakuya

@kitak Testing(testing.md) の翻訳やりたいですー

@inouetakuya

@kitak Strict Mode(strict.md) の翻訳やりたいですー

docs/ja/actions.md
+}
+```
+
+> `store.dispatch` で異なるモジュール内の複数のアクションハンドラをトリガーすることができます。そのようなケースでは、全てのトリガーされたハンドラがリゾルブされたときにリゾルブする Promise が戻り値として返ってくることになります。
@kitak
kitak Nov 25, 2016 Contributor

「リゾルブ」でも通じると思いますが、「解決」のほうがより多く見かける気がします。

@inouetakuya
inouetakuya Nov 28, 2016

なるほど承知しました。「解決」にしますー

docs/ja/actions.md
+
+### アクションを構成する
+
+アクションはしばしば非同期処理を行いますが、アクションが完了したことをどうやって知れば良いのでしょう?そしてもっと重要なことは、もっと複雑な非同期処理を取り扱うために、どうやって複数のアクションを構成させるかということです。
@kitak
kitak Nov 25, 2016 Contributor

「もっと」が一つの文章の中で続いているので、「さらに」等を使って読みやすくできそうです。

docs/ja/actions.md
+}
+```
+
+最終的には [async / await](https://tc39.github.io/ecmascript-asyncawait/) を使うと、JavaScript はとても素早くランディングを計算でき、複数のアクションを以下のように構成できます:
@kitak
kitak Nov 25, 2016 edited Contributor

次のような翻訳はどうでしょうか?
「最終的に JavaScript の機能として近く導入される async /await を使用することで、次のようにアクションを組み合わせることができます:」

@inouetakuya
inouetakuya Nov 28, 2016

あああ、ランディングの意味を完全に間違えていました。指摘ありがとうございます。修正しますー

@kitak
Contributor
kitak commented Nov 25, 2016

Hot Reloading(hot-reload.md) やります

@kitak
Contributor
kitak commented Nov 25, 2016

Plugins(plugins.md) やります

@kitak
Contributor
kitak commented Nov 25, 2016

Form Handling(forms.md) やります

docs/ja/actions.md
+})
+```
+
+アクションハンドラはストアインスタンスのメソッドやプロパティのセットと同じものを呼び出せる、コンテキストオブジェクトを受け取ります。したがって `context.commit` を呼び出すことでミューテーションをコミットできます。あるいは `context.state` や `context.getters` で、状態やゲッターにアクセスできます。なぜコンテキストオブジェクトがストアインスタンスそのものではないのかは、後ほど [モジュール](modules.md) で説明します。
@kitak
kitak Nov 26, 2016 edited Contributor

「ストアインスタンスのメソッドやプロパティのセットと同じものを呼び出せる」はコンテキストオブジェクトを説明しているので、その後の読点を無くしたほうがいいかもしれません。

docs/ja/actions.md
+
+アクションはしばしば非同期処理を行いますが、アクションが完了したことをどうやって知れば良いのでしょう?そしてもっと重要なことは、もっと複雑な非同期処理を取り扱うために、どうやって複数のアクションを構成させるかということです。
+
+まず知っておくべきことは `store.dispatch` は、トリガーされたアクションハンドラによって返された値を、戻り値として返すということです。したがってアクションの中で Promise を返すようにできます:
@kitak
kitak Nov 26, 2016 Contributor

次のような翻訳はどうでしょうか?
「まず知っておくべきことは、store.dispatch がトリガーされたアクションハンドラによって返された Promise を処理できることと、Promise を返すことです。」

@inouetakuya
inouetakuya Nov 28, 2016

分かりやすい!そのまま採用させていただきます!

docs/ja/getting-started.md
+
+### シンプルなストア
+
+> **注意:** 私たちは、このドキュメントのコード例に ES2015 のシンタックスを利用しています。 もし触れたことがなければ、[ぜひ触れてください](https://babeljs.io/docs/learn-es2015/)!このドキュメントは、他に[大規模アプリケーションの構築](https://jp.vuejs.org/guide/application.html)に書かれたコンセプトを既に読まれていることを前提にしています。
@chi-bd
chi-bd Nov 27, 2016

https://jp.vuejs.org/guide/application.html が dead link(404)です。
v2のドキュメントには「大規模アプリケーションの構築」というセクション自体がなく、かつ原文からはこの行の後半そのものが削除されているので、原文に合わせてカットすべきと思います。

@inouetakuya
inouetakuya Nov 28, 2016

指摘ありがとうございます。カットしますー

docs/ja/intro.md
+
+Vuex は、共有状態の管理に役立ちますが、さらに概念やボイラープレートのコストがかかります。これは、短期的生産性と長期的生産性のトレードオフです。
+
+もし、あなたが大規模なSPAを構築することなく、Vuex を導入した場合、冗長で恐ろしいかんじになるかもしれません。そう感じることは全く普通です。もし、あなたのアプリがシンプルであれば、Vuex なしで問題ないでしょう。シンプルな [グローバル イベント バス](http://vuejs.org/guide/components.html#Non-Parent-Child-Communication) が必要なだけかもしれません。しかし、中規模から大規模のSPAを構築する場合は、Vue コンポーネント以外のどうやってうまく扱うか考える絶好の機会です。Vuex は自然な次のステップとなるでしょう。これは Redux の作者、Dan Abramov からの良い引用です:
@potato4d
potato4d Nov 27, 2016

細かいところなのであんまり問題ないとは思いますが、"SPA"のところ" SPA "のほうが他との統一の面で良さそうです!

docs/ja/getters.md
+
+### `mapGetters` ヘルパー
+
+The `mapGetters` helper simply maps store getters to local computed properties:
@kitak
kitak Nov 27, 2016 Contributor

英語の文章が残っていたり、この下のソースコードのコメントが翻訳されていないので、確認をお願いします。

@inouetakuya
inouetakuya Nov 28, 2016

はわわ。確認して修正しますー

docs/ja/mutations.md
+
+``` js
+store.commit('increment')
+// "increment" ミューテーションによる状態変更は、この時点で行われるすべき
@kitak
kitak Nov 27, 2016 Contributor

「行われるすべき」→「行われるべきです」

@kazupon

自分も日本語公式サイトとの観点でレビュー 👀 しました。ご確認ください!

docs/ja/actions.md
+最終的には [async / await](https://tc39.github.io/ecmascript-asyncawait/) を使うと、JavaScript はとても素早くランディングを計算でき、複数のアクションを以下のように構成できます:
+
+``` js
+// assuming getData() and getOtherData() return Promises
@kazupon
kazupon Nov 28, 2016 Member

ここのコメント翻訳漏れがあるの見つけました。 👀

@inouetakuya
inouetakuya Nov 28, 2016

おっと、修正しますー

docs/ja/intro.md
+- **ビュー**、これは**状態**のただの宣言的なマッピングです。
+- **アクション**、これは**ビュー**からのユーザー入力に反応して、状態の変更を可能にする方法です。
+
+これらは"片方向データフロー"のコンセプトの極めてシンプルな責務です:
@kazupon
kazupon Nov 28, 2016 Member

one-wayの訳ですが、片方向より単方向の方が分かりやすいのかなあと思いました。
ちなみに公式ドキュメント訳の単方向にしております。
http://jp.vuejs.org/v2/guide/components.html#単方向データフロー

docs/ja/intro.md
+- 複数のビューが同じ状態に依存することがあります。
+- 異なるビューからのアクションで、同じ状態を変更する必要があります。
+
+一つ目は、props として深く入れ子になったコンポーネントに渡すのは面倒で、兄弟コンポーネントでは単純に機能しません。二つ目は、親子のインスタンスを直接参照したり、イベントを介して複数の状態のコピーを変更、同期することを試みるソリューションに頼っていることがよくあります。これらのパターンは、いずれも脆く、すぐにメンテナンスが困難なコードに繋がります。
@kazupon
kazupon Nov 28, 2016 Member

props はコンポーネントのプロパティのことを言っているので、 公式サイトの翻訳は、プロパティに統一しました。
なので、vuex の方もプロパティ (もしくは、プロパティ (props))統一した方が混乱しないと思うので、そうして頂けると助かります!

docs/ja/intro.md
+
+Vuex は、共有状態の管理に役立ちますが、さらに概念やボイラープレートのコストがかかります。これは、短期的生産性と長期的生産性のトレードオフです。
+
+もし、あなたが大規模な SPA を構築することなく、Vuex を導入した場合、冗長で恐ろしいと感じるかもしれません。そう感じることは全く普通です。あなたのアプリがシンプルであれば、Vuex なしで問題ないでしょう。単純な [グローバル イベント バス](http://vuejs.org/guide/components.html#Non-Parent-Child-Communication) が必要なだけかもしれません。しかし、中規模から大規模の SPA を構築する場合は、Vue コンポーネント以外のどうやってうまく扱うか考える絶好の機会です。Vuex は自然な次のステップとなるでしょう。これは Redux の作者、Dan Abramov からの良い引用です:
@kazupon
kazupon Nov 28, 2016 Member

グローバル イベント バスという訳ですが、途中空白が入っていて読み手に違和感あるので、グローバルイベントバスでどうでしょうか?

@kazupon
kazupon Nov 28, 2016 Member

グローバルイベントバスのリンク先ですが日本語公式サイトのところにしておくとフレンドリーでいいですね!
http://jp.vuejs.org/v2/guide/components.html#親子間以外の通信

docs/ja/state.md
+
+Vuex は**単一ステートツリー (single state tree)**を使います。つまり、この単一なオブジェクトはアプリケーションレベルの状態が全て含まれており、"信頼できる唯一の情報源 (single source of truth)" として機能します。単一ステートツリーは状態の特定の部分を見つけること、デバッグのために現在のアプリケーションの状態のスナップショットを撮ることを容易にします。
+
+単一ステートツリーはモジュール性とコンフリクト(競合)しません。以降の章で、アプリケーションの状態とミューテーション(変更)をサブモジュールに分割する方法について説明します。
@kazupon
kazupon Nov 28, 2016 Member

コンフリクト(競合) とありますが、conflict という単語は、特に普通に使う一般的なもの単語だと思うので、カッコ付けしないで競合という訳でもいい気がします。

@inouetakuya

表記を統一する、という観点からいくつかコメントしました

docs/ja/state.md
+
+### 単一ステートツリー
+
+Vuex は**単一ステートツリー (single state tree)**を使います。つまり、この単一なオブジェクトはアプリケーションレベルの状態が全て含まれており、"信頼できる唯一の情報源 (single source of truth)" として機能します。単一ステートツリーは状態の特定の部分を見つけること、デバッグのために現在のアプリケーションの状態のスナップショットを撮ることを容易にします。
@inouetakuya
inouetakuya Nov 28, 2016

単一ステートツリー (single state tree)

細かいですが、「単一ステートツリー(single state tree)」と全角カッコを使うか、半角カッコを使うか統一したいです。

個人的には日本語の文章なので全角カッコを使いたい(&全角カッコのほうが見やすいと思う)ですが、このあたり @kitak @kazupon どうでしょう?

+}
+```
+
+同様に、モジュールのアクションの中では `context.state` はローカルステートにアクセスでき、ルートのステートは `context.rootState` でアクセスできます:
@inouetakuya
inouetakuya Nov 28, 2016 edited

私が翻訳を担当した箇所では state を「状態」と訳すことが多かったのですが、このあたりはちょっと「状態」という訳だとニュアンスが伝わりにくいかと思い「ステート」にしました。

ストアと同じく、state は「ステート」のままのほうが分かりやすい箇所、他にもあると思うので、いまからざっと見ていきますー

(基本的には「状態」の訳のままで、「ステート」のほうが分かりやすい箇所のみ変更、もしくは併記します)

docs/ja/actions.md
+store.dispatch('increment')
+```
+
+これは一見ばかげて見えるかもしれません。つまり、カウントをインクリメントしたいときに、どうして直接 `store.commit('increment')` を呼び出してミューテーションをコミットしないのか、と。**ミューテーションは同期的でなければならない** というのを覚えていますか?アクションはそうではありません。アクションの中では **非同期** の操作をおこなうことができます。
@inouetakuya
inouetakuya Nov 28, 2016

太字の前後に半角スペースを入れて見やすくしたつもりなのですが、他の方が翻訳した箇所及び Vue.js の日本語訳を見るとそのようにしていなかったので、合わせるために半角スペース削除しますー

@ktsn

ざっと見ました。

あと多分、このあたりの PR -> #470, #421, #438 は反映されていないと思うので、反映しておいていただけると、とてもありがたいです!

@@ -0,0 +1,64 @@
+Vuex は Vue.js アプリケーションのための **状態管理パターン + ライブラリ**です。
@ktsn
ktsn Nov 28, 2016 Member

原文に存在する What is Vuex? が抜けているようです。

docs/ja/intro.md
@@ -0,0 +1,64 @@
+Vuex は Vue.js アプリケーションのための **状態管理パターン + ライブラリ**です。
+これは状態の変異を予測可能な方法で確実におこなわせるルールを持っており、アプリケーション内の全てのコンポーネントのための集中型のストアとして機能します。
@ktsn
ktsn Nov 28, 2016 Member

原文は

... with rules ensuring that the state can only be mutated in a predictable fashion

なので、「状態は予測可能な方法によってのみ変異することができるというルールを保証する...」みたいな訳のほうが近いかなと思いますがいかがでしょうか? only の訳が重要だと思います。

docs/ja/intro.md
@@ -0,0 +1,64 @@
+Vuex は Vue.js アプリケーションのための **状態管理パターン + ライブラリ**です。
+これは状態の変異を予測可能な方法で確実におこなわせるルールを持っており、アプリケーション内の全てのコンポーネントのための集中型のストアとして機能します。
+また Vue 公式の[開発ツール拡張](https://github.com/vuejs/vue-devtools)と連携し、設定なしでタイムトラベルデバッギングやステートのスナップショットのエクスポートやインポートのような高度な機能を提供します。
@ktsn
ktsn Nov 28, 2016 Member

カタカナでデバッギングという表現はあまり見かけないので、デバッグでいいかなーと感じますがどうでしょう?

docs/ja/intro.md
+
+では、コンポーネントから共有している状態を抽出し、それをグローバルシングルトンで管理するのはどうでしょうか? これにより、コンポーネントツリーは大きな "ビュー" となり、どのコンポーネントもツリー内のどこにあっても状態にアクセスしたり、アクションをトリガーできます!
+
+さらに、状態管理に関わる概念を定義、分離し、特定のルールを敷くことで、コードの構造と保守性を向上させます。
@ktsn
ktsn Nov 28, 2016 Member

細かいですが、原文は「向上させることができます」というニュアンスに見えます。

docs/ja/intro.md
+
+さらに、状態管理に関わる概念を定義、分離し、特定のルールを敷くことで、コードの構造と保守性を向上させます。
+
+Vuex の背景にある基本的なアイディアは、[Flux](https://facebook.github.io/flux/docs/overview.html)、 [Redux](http://redux.js.org/) そして [The Elm Architecture](https://guide.elm-lang.org/architecture/)から影響を受けたものです。
@ktsn
ktsn Nov 28, 2016 Member

原文の意図はどちらかと言うと上の文章に対して、(1)これが Vuex の基本的な考え方であり、(2)Flux, Redux, Elm から影響を受けている、というニュアンスだと思います。
(1) が抜けているように見えます。

docs/ja/getting-started.md
+Vuex を[インストール](installation.md) してから、ストアをつくってみましょう。Vuex ストアの作成は、とても簡単です。ストアオブジェクトの初期状態と、いくつかのミューテーションを準備するだけです。
+
+``` js
+// module を利用しているときはあらかじめ Vue.use(Vuex) を呼び出していることを確認しておいてください
@ktsn
ktsn Nov 28, 2016 Member

module は Vuex module とまぎらわしいので、installation にあったようにモジュールシステムと訳すのはいかがでしょうか?

@inouetakuya
inouetakuya Nov 29, 2016

なるほど、たしかにまぎらわしいですね。モジュールシステムにしますー

docs/ja/getting-started.md
+
+そして `store.state.count` を直接変更する代わりにミューテーションをコミットする理由は、状態の変更を明確に追跡したいからです。このシンプルな規約は、あなたのコードの意図をさらに明確にし、コードを読んだ時にアプリケーションの状態の変更について、論理的に考えることができるようにします。加えて、私たちに全ての変更のログを取ったり、状態のスナップショットを取ったり、タイムトラベルデバッグを行うようなツールを実装する余地を与えてくれます。
+
+ストアオブジェクトの状態はリアクティブなので、コンポーネント内のストアの状態は、演算されたプロパティ内の状態を返します。コンポーネントメソッドでミューテーションをコミットすることによって状態の変更を行います。
@ktsn
ktsn Nov 28, 2016 Member

Vue の computed property は日本語訳だと算出プロパティなので、それに合わせるのが良いかと思います。

@ktsn
ktsn Nov 28, 2016 Member

前半に関して、「...リアクティブなので、ストアの状態をコンポーネント内で使うには算出プロパティ内でただ状態を返せば良いです」
みたいな訳はどうでしょうか?

@inouetakuya
inouetakuya Nov 29, 2016

算出プロパティに合わせますー

@inouetakuya
inouetakuya Nov 29, 2016

「...リアクティブなので、ストアの状態をコンポーネント内で使うには算出プロパティ内でただ状態を返せば良いです」

分かりやすいです!そのまま採用させていただきます!

docs/ja/state.md
+
+### 単一ステートツリー
+
+Vuex は**単一ステートツリー (single state tree)**を使います。つまり、この単一なオブジェクトはアプリケーションレベルの状態が全て含まれており、"信頼できる唯一の情報源 (single source of truth)" として機能します。単一ステートツリーは状態の特定の部分を見つけること、デバッグのために現在のアプリケーションの状態のスナップショットを撮ることを容易にします。
@ktsn
ktsn Nov 28, 2016 Member

This also means usually you will have only one store for each application

の訳が抜けてます?

docs/ja/state.md
+``` js
+// Counter コンポーネントをつくってみましょう
+const Counter = {
+ template: `<div>{{ count }}</div>`,
@ktsn
ktsn Nov 28, 2016 Member

微妙にインデント数が原文と異なっているので合わせていただけますか?

@ktsn
ktsn Nov 28, 2016 Member

このファイル全体でインデントが 2 -> 4 になってしまっていますね。

docs/ja/state.md
+const Counter = {
+ template: `<div>{{ count }}</div>`,
+ computed: {
+ count: function() {
@ktsn
ktsn Nov 28, 2016 Member

ここも原文では object literal shorthand なのですが、変わっています。

docs/ja/state.md
+
+しかし、このパターンでは、コンポーネントがグローバルストアシングルトンに依存してしまいます。 モジュールシステムを使っているとき、ストアの状態を使っているすべてのコンポーネントでインポートが必要です。また、コンポーネントのテストのときにモック化が必要となります。
+
+Vuex は、ルートコンポーネントに `store` オプションを指定することで (これは、 `Vue.use(Vuex)` で有効にできます)、すべての子コンポーネントにストアを "挿入" する機構を提供しています:
@ktsn
ktsn Nov 28, 2016 Member

DI の訳が注入で広まってるので s/挿入/注入/ でいかがでしょうか?(以降の訳も注入になってます)

docs/ja/getters.md
+}
+```
+
+もしこの関数を複数のコンポーネントで利用したくなったら、関数をコピーするか、あるいは関数を共用のヘルパーに切り出して複数の場所でインポートする必要があります。- しかし、どちらも理想的とはいえません。
@ktsn
ktsn Nov 28, 2016 Member

直前で文章が終わって句点があるので、このハイフンはなくても良いと思います。

docs/ja/getters.md
+
+もしこの関数を複数のコンポーネントで利用したくなったら、関数をコピーするか、あるいは関数を共用のヘルパーに切り出して複数の場所でインポートする必要があります。- しかし、どちらも理想的とはいえません。
+
+Vuex を利用するとストア内に "ゲッター" を定義することができます(ストアのための算出プロパティだと考えてください)。ゲッターはストアを第1引数として受け取ります:
@ktsn
ktsn Nov 28, 2016 Member

ゲッターはストアを第1引数として受け取ります:

ストアではなくステートですね。

docs/ja/getters.md
+export default {
+ // ...
+ computed: {
+ // ゲッターを computed に組み込む
@ktsn
ktsn Nov 28, 2016 Member

原文で触れられてる object spread operator についての訳が抜けてます?

@inouetakuya
inouetakuya Nov 29, 2016

すみません抜けてました。訳します!

docs/ja/mutations.md
+ },
+ mutations: {
+ increment (state) {
+ // mutate state
@ktsn
ktsn Nov 28, 2016 Member

このコメントの訳もお願いします!

docs/ja/mutations.md
+})
+```
+
+オブジェクトスタイルでコミットするとき、オブジェクト全体がペイロードとしてミューテーションハンドラに渡されます。したがってハンドラの中で同じものが利用できます:
@ktsn
ktsn Nov 28, 2016 Member

the handler remains the same:

なので、「ハンドラの例は上記と同じです」という訳が近いでしょうか?

@inouetakuya
inouetakuya Nov 29, 2016

ああ、完全に誤読していました。修正します!

docs/ja/mutations.md
+
+### Vue のリアクティブなルールに則ったミューテーション
+
+Vuex ストアの状態は Vue によってリアクティブになっているので、状態を変更すると、状態を監視している Vue コンポーネントは自動的に更新されます。これは Vuex のミューテーションは、通常の Vue で動作させているときと同じリアクティブな警告の対象となることを意味します:
@ktsn
ktsn Nov 28, 2016 Member

通常の Vue で動作させているときと同じリアクティブな警告の対象となることを意味します:

原文をみると、Vue のリアクティブシステムを扱う時と同じ注意が必要であるという意味なので、「通常の Vue と動作させているときと同じく、リアクティブな値に関する注意が必要であることを意味します」でどうでしょう?

@inouetakuya
inouetakuya Nov 29, 2016

めちゃくちゃ分かりやすい!ありがとうございます!

docs/ja/mutations.md
+
+### ミューテーション・タイプに定数を使用する
+
+いろいろな Flux 実装において、ミューテーション・タイプに定数を使用することが一般的だとされています。これはコードに対してリントツールのようなツールを利用できるという利点があり、また単一ファイルに全ての定数を設定することによって、共同で作業する人に、アプリケーション全体で何のミューテーションが可能であるかを一目見ただけで理解できるようにします:
@ktsn
ktsn Nov 28, 2016 Member

「一般的だとされています」だと原文とニュアンスが違ってくると思いますねー。そのまま「共通に見られるパターン」ではだめでしょうか?

docs/ja/mutations.md
+const store = new Vuex.Store({
+ state: { ... },
+ mutations: {
+ // 定数を関数名として使用できる ES2015 の算出プロパティ(computed property)名機能を使用できます
@ktsn
ktsn Nov 28, 2016 Member

Computed Property Name で1つの機能名なので、

算出プロパティ名 (computed property name)

が良いかと思われますー。

docs/ja/mutations.md
+
+### コンポーネント内におけるミューテーションのコミット
+
+`this.$store.commit('xxx')` と書くか、もしくはコンポーネントのメソッドを `store.commit` にマッピングする `mapMutations` ヘルパーを呼び出すこと(ルートの `store` が必要)で、コンポーネント内でミューテーションをコミットできます:
@ktsn
ktsn Nov 28, 2016 Member

(ルートの store が必要)

injection の訳が抜けていますね。ルートの store が必要、だけだと少しわかりづらいかと思います。

@inouetakuya
inouetakuya Nov 29, 2016

なるほど、(ルートの store の注入が必要) としますー

docs/ja/actions.md
+
+### コンポーネント内でのアクションのディスパッチ
+
+`this.$store.dispatch('xxx')` でコンポーネント内でアクションをディスパッチできます。あるいはコンポーネントのメソッドを `store.dispatch` にマッピングする `mapActions` ヘルパーを使うこともできます(ルートの `store` が必要です):
@ktsn
ktsn Nov 28, 2016 Member

ここもカッコ内の injection を訳したほうがわかりやすくなるかと思います。

docs/ja/actions.md
+
+### コンポーネント内でのアクションのディスパッチ
+
+`this.$store.dispatch('xxx')` でコンポーネント内でアクションをディスパッチできます。あるいはコンポーネントのメソッドを `store.dispatch` にマッピングする `mapActions` ヘルパーを使うこともできます(ルートの `store` が必要です):
@ktsn
ktsn Nov 28, 2016 Member

ここもカッコ内の injection を訳したほうがわかりやすくなるかと思います。

docs/ja/actions.md
+最終的に JavaScript の機能として近く導入される [async / await](https://tc39.github.io/ecmascript-asyncawait/) を使用することで、次のようにアクションを組み合わせることができます:
+
+``` js
+// getData() と getOtherData() を受け取って Promises を返す
@ktsn
ktsn Nov 28, 2016 Member

原文と意味が異なっています。原文はこの文で、getData() と getOtherData() が promise を返すことを仮定するという前提条件を示しています。

@inouetakuya
inouetakuya Nov 29, 2016

なるほど、誤読していました。修正します!

docs/ja/modules.md
+
+そのような場合に役立てるため Vuex ではストアを**モジュール**に分割できるようになっています。
+
+それぞれのモジュールは、状態(state)、ミューテーション、アクション、ゲッター、モジュールさえも内包できます(モジュールをネストできます)- トップからボトムまでフラクタル構造です:
@ktsn
ktsn Nov 28, 2016 Member

原文では一つ上の文と同じパラブラフなので、合わせていただけますか?

@ktsn
ktsn Nov 28, 2016 Member

また、 its own state の its own は割と重要だと思うので、訳にも含めていただけますか?

docs/ja/modules.md
+})
+
+store.state.a // -> moduleA's state
+store.state.b // -> moduleB's state
@ktsn
ktsn Nov 28, 2016 Member

ここの訳もお願いします!

docs/ja/modules.md
+
+### 名前空間
+
+モジュール内部のアクションやミューテーション、ゲッターは依然として**グローバル名前空間**の下に登録されることに注意してください。そのため、複数のモジュールが同一のミューテーションやアクションタイプに反応してしまいます。接頭語や接尾語を付けることで名前の衝突を回避できますし、再利用可能でかつどこで使われるか分からない Vuex のモジュールを書いているのならば、そうすべきです。例えば `todos` モジュールを作りたいときは以下のようにします:
@ktsn
ktsn Nov 28, 2016 Member

そのため、複数のモジュールが同一のミューテーションやアクションタイプに反応してしまいます。

原文ではポジティブな意図で書かれているかと思います(同じ名前なら複数のモジュールを反応させることができるよ、という感じ)。
なので、「これにより、複数のモジュールを同一のミューテーションやアクションタイプに反応させることができます」みたいな訳でいかがでしょうか?

@ktsn
ktsn Nov 28, 2016 Member

その前の文も、...注意してくださいというよりは、特筆すべき点は、... みたいな感じでしょうか。

@inouetakuya
inouetakuya Nov 29, 2016

Note that actions, mutations and getters inside modules are still registered under the global namespace - this allows multiple modules to react to the same mutation/action type. You can namespace the module assets yourself to avoid name clashing by prefixing or suffixing their names. And you probably should if you are writing a reusable Vuex module that will be used in unknown environments. For example, we want to create a todos module:

なるほど、そうか allow を使っていますもんね。ポジティブな感じに変更しますー

docs/ja/modules.md
+
+モジュールのステートには `store.state.myModule` でアクセスします。
+
+動的なモジュール登録があることで、他の Vue プラグインが、モジュールをアプリケーションのストアに付属させることで、状態の管理に Vuex を活用できることができます。例えば [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) ライブラリは、動的に付属させたモジュール内部でアプリケーションのルートステートを管理することで vue-router と vuex を統合しています。
@ktsn
ktsn Nov 28, 2016 Member

ルートが route と root の両方の意味で使われている?ので、route の方はルーティングにして、ルートステート→ルーティングのステートでいかがでしょうか。

docs/ja/modules.md
+
+動的なモジュール登録があることで、他の Vue プラグインが、モジュールをアプリケーションのストアに付属させることで、状態の管理に Vuex を活用できることができます。例えば [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) ライブラリは、動的に付属させたモジュール内部でアプリケーションのルートステートを管理することで vue-router と vuex を統合しています。
+
+`store.unregisterModule(moduleName)` を呼び出せば、動的に登録したモジュールを削除できます。ただしストア作成(store creation)によって宣言された、静的なモジュールはこのメソッドで削除できないことに注意してください。
@ktsn
ktsn Nov 28, 2016 Member

ただしストア作成(store creation)によって宣言された

「ストアの作成の際に宣言された」でどうでしょう?

docs/ja/plugins.md
+
+### プラグイン内でのミューテーションのコミット
+
+プラグインは直接、状態を変更できません。これはコンポーネントに似ています。プラグインはコンポーネント同様に、ミューテーションのコミットによる変更のトリガーで状態を変更できます。
@ktsn
ktsn Nov 28, 2016 Member

プラグインはコンポーネント同様に、ミューテーションのコミットによる変更のトリガーで状態を変更できます。

ちょっと原文と意味が違うような……?原文では they can ""only"" trigger changes by committing mutations. ともうすこし制限を強めに言ってるように見えます。

docs/ja/forms.md
@@ -0,0 +1,56 @@
+# フォームのハンドリング
@ktsn
ktsn Nov 28, 2016 Member

目次とタイトルが異なりますね。どちらかに合わせましょう。

docs/ja/testing.md
+
+### アクションのテスト
+
+アクションは外部の API を呼び出す可能性があるため、ミューテーションのテストよりも少し注意が必要です。アクションをテストするとき、通常、いくつかの段階でモックを作る必要があります。例えば API 呼び出しをサービスとして抽象化し、そしてテストの内部ではそのサービスをモックにすることができます。簡単に依存関係をモック化するために、Webpack と [inject-loader](https://github.com/plasticine/inject-loader) をテストファイルにバンドルして使用することができます。
@ktsn
ktsn Nov 28, 2016 Member

Webpack と inject-loader はテストファイルにバンドルするものではなく、テストファイルをバンドルするものですね。原文でも後者の意味です。

docs/ja/hot-reload.md
@@ -0,0 +1,44 @@
+# ホットリローディング
+
+Vuex はアプリケーションの開発を行っている間のミューテーション、モジュール、アクション、ゲッターのホットリローディングをサポートします。Webpack は [Hot Module Replacement API](https://webpack.github.io/docs/hot-module-replacement.html) を使用します。Browserify では [browserify-hmr](https://github.com/AgentME/browserify-hmr/) プラグインを使用することができます。
@ktsn
ktsn Nov 28, 2016 Member

Webpack は Hot Module Replacement API を使用します。

これは原文にならい、前の文とつなげて、「Vuex は ... Webpack の Hot Module Replacement API を使ったホットリローディングをサポートします」でどうでしょうか?

@inouetakuya

@ktsn

レビューありがとうございました!大変勉強になりました。

指摘いただいた点の反映が終わりました。また #470, #421, #438 を反映しました(#421 の api.md 変更分を除く)

@kimikimi714

翻訳しながら理解できなかった部分について自分でコメントを書きました。フィードバックよろしくお願いします。

docs/ja/api.md
+ rootState // store.state と同じ
+ ```
+
+ 登録されたゲッターは `store.getters` 上で外から見えるようになります。
@kimikimi714
kimikimi714 Nov 29, 2016

exposeをどう訳すと良いかがわからず「外から見える」と訳しています

@kitak
kitak Nov 30, 2016 Contributor

「公開されます」はどうでしょうか?

@kimikimi714
kimikimi714 Nov 30, 2016

なるほど!そのほうがしっくりきますね。修正します。

docs/ja/api.md
+
+- **`dispatch(mutationName: String, ...args) | dispatch(mutation: Object)`**
+
+アクションをディスパッチします。すべてのトリガーされたアクションハンドラを解決するプロミスを返します。[詳細](actions.md)
@kimikimi714
kimikimi714 Nov 29, 2016

上の他の方の翻訳例を見るとPromiseはPromiseのままのようなので、そちらに合わせるよう修正します。

docs/ja/api.md
+
+- **`mapActions(map: Array<string> | Object): Object`**
+
+ アクションをディスパッチするコンポーネントメソッドオプションを作成します。[詳細](actions.md#dispatching-actions-in-components)
@kimikimi714
kimikimi714 Nov 29, 2016

component methods optionsという単語ひとかたまりかと思って訳してしまっているのですが、間違っている気がしています…。

@kazupon
kazupon Nov 30, 2016 Member

コンポーネントのメソッドオプションでどうでしょうか?

@kimikimi714
kimikimi714 Nov 30, 2016

確かに、そのほうが何のことかがもう少しわかりやすくなりますね。修正します。

@kitak
kitak Nov 30, 2016 Contributor

いっそのこと、メソッドはプロパティ名のままで コンポーネントの methods オプションとかどうでしょうか。

@kimikimi714
kimikimi714 Nov 30, 2016

なるほどです。無理に全部日本語にしようとしないほうがわかりやすそうですね。
コンポーネントの methods オプション で修正します。

docs/ja/api.md
+
+- **`replaceState(state: Object)`**
+
+ストアのルートステートを置き換えます。これは、ステートの水和やタイムトラベルのためだけに利用すべきです。
@kimikimi714
kimikimi714 Nov 30, 2016

hydrationの訳もどうしていいものかわかりませんでした。
直訳だと水和であってると思うのですが、何かのジョークなのか?とも思ってよくわからないですね…。

@ktsn
ktsn Nov 30, 2016 Member

hydration はハイドレーションでいいと思います。Server Side Rendering の用語です。

docs/ja/api.md
+
+ - 型: `Object`
+
+ Vuex store のための ルートステートオブジェクトです。
@ktsn
ktsn Dec 1, 2016 Member

他の方の翻訳ではストアと書かれてるので、 s/store/ストア/ していただけますか?

@kimikimi714
kimikimi714 Dec 1, 2016

確かに。1.0のときにままにしていました。置き換えます。

docs/ja/api.md
+
+ - 型: `{ [type: string]: Function }`
+
+ Vuex storeにミューテーションを登録します。ハンドラ関数は第一引数に `state` を常に受け取り(またモジュール内で定義されていれば、ローカルステートをモジュール化し)、指定されていれば第二引数に `payload` を受け取ります。
@ktsn
ktsn Dec 1, 2016 Member

ローカルステートをモジュール化し

「モジュールのローカルステートを受け取り」が原文の意味として正しいですね。

@kimikimi714
kimikimi714 Dec 1, 2016

確かに be moduled ではないですね。修正します。

docs/ja/api.md
+
+ ``` js
+ {
+ state, // store.state と同じか, or モジュール内にあればローカルステート
@ktsn
ktsn Dec 1, 2016 Member

or はとりましょう!

@kimikimi714
kimikimi714 Dec 1, 2016

消し忘れていました…。消します。

docs/ja/api.md
+ Vuex storeにゲッターを登録します. ゲッター関数は次の引数を受け取ります:
+
+ ```
+ state, // モジュール内で定義されていればローカルステートをモジュール化します
@ktsn
ktsn Dec 1, 2016 Member

ローカルステートをモジュール化します

「モジュールのローカルステートとなります」が原文の意味として正しいですね。

docs/ja/api.md
+ }
+ ```
+
+ 各モジュールは、ルートオプションに似た `state` と `mutations` を含むことができます。モジュールの状態は、モジュールのキーを使って、ストアのルートステートにアタッチされます。モジュールのミューテーションとゲッターは、第一引数としてルートステートの代わりに、モジュールのローカルステートだけを受け取り、モジュールのアクションの `context.state` もローカルステートを指すようになります。
@ktsn
ktsn Dec 1, 2016 Member

アタッチされます

結合されます。とかでどうでしょうか?

docs/ja/api.md
+
+ - 型: `Array<Function>`
+
+ プラグイン関数の配列は、ストアに適用されます。このプラグインは、ストアだけを引数として受け取り、外部への永続化、ロギング、デバッギングのために、ミューテーションを監視するか、または、 websocket や observable のような内部のデータのためにミューテーションをディスパッチします。
@ktsn
ktsn Dec 1, 2016 Member

inbound は"内部の"ではなく、"外から中に入ってくる"と言う意味なので、

for inbound data

は外部からのデータを指します。

docs/ja/api.md
+
+ ストアのルートステートを置き換えます。これは、ステートの水和やタイムトラベルのためだけに利用すべきです。
+
+- **`watch(getter: Function, cb: Function, [options: Object])`**
@ktsn
ktsn Dec 1, 2016 Member

[options: Object]

原文と表現が変わってます?

@kimikimi714
kimikimi714 Dec 1, 2016

https://github.com/vuejs/vuex/blob/dev/docs/en/api.md
でも (state: Object) になっているように思いますが、間違っていますでしょうか?

下の options?: Object にならないといけないところですね。失礼いたしました。修正します。

docs/ja/api.md
+ store.subscribe((mutation, state) => {
+ console.log(mutation.type)
+ console.log(mutation.payload)
+ })
@ktsn
ktsn Dec 1, 2016 Member

インデントが微妙にずれてますね。

docs/ja/api.md
+ })
+ ```
+
+ もっともよく利用されるプラグインです。[詳細](plugins.md)
@ktsn
ktsn Dec 1, 2016 Member

Most commonly used in plugins
なので、プラグイン内でよく使われると言う意味になります。

docs/ja/api.md
+
+- **`hotUpdate(newOptions: Object)`**
+
+ 新しいアクションとミューテーションでホットスワップします。[詳細](hot-reload.md)
@ktsn
ktsn Dec 1, 2016 Member

こまかいですが、new actions and mutations は目的格なので で ではなく を だと思います。

@kimikimi714
kimikimi714 Dec 1, 2016

確かに で はおかしいですね。修正します。

docs/ja/api.md
+
+- **`mapState(map: Array<string> | Object): Object`**
+
+ Vuex storeのサブツリーを返すオプションを計算したコンポーネントを作成します。[詳細](state.md#the-mapstate-helper)
@ktsn
ktsn Dec 1, 2016 Member

Create component computed options

は「コンポーネントの算出プロパティオプションを作成する」で、

that return the sub tree of the Vuex store

はそのオプションが「Vuex ストアのサブツリーを返す」ことを意味しています。

docs/ja/api.md
+
+- **`mapGetters(map: Array<string> | Object): Object`**
+
+ ゲッターの評価後の値を返すオプションを計算したコンポーネントを作成します。[詳細](getters.md#the-mapgetters-helper)
@ktsn
ktsn Dec 1, 2016 Member

こちらも上記と同様に、作成するのは「コンポーネントの算出プロパティオプション」です。

@ktsn
ktsn Dec 1, 2016 Member

下の methods と合わせて computed オプションにしても良いかもしれません

@kimikimi714
kimikimi714 Dec 1, 2016

なるほど。上のコメントも合わせてありがとうございます。
computedオプションにしてしまおうと思います。

@kimikimi714

コメントをいただいた部分の修正を行いました。ご確認よろしくお願いします。

docs/ja/api.md
+
+ - 型: `Object`
+
+ Vuex store のための ルートステートオブジェクトです。
@kimikimi714
kimikimi714 Dec 1, 2016

確かに。1.0のときにままにしていました。置き換えます。

docs/ja/api.md
+
+ - 型: `{ [type: string]: Function }`
+
+ Vuex storeにミューテーションを登録します。ハンドラ関数は第一引数に `state` を常に受け取り(またモジュール内で定義されていれば、ローカルステートをモジュール化し)、指定されていれば第二引数に `payload` を受け取ります。
@kimikimi714
kimikimi714 Dec 1, 2016

確かに be moduled ではないですね。修正します。

docs/ja/api.md
+
+ ``` js
+ {
+ state, // store.state と同じか, or モジュール内にあればローカルステート
@kimikimi714
kimikimi714 Dec 1, 2016

消し忘れていました…。消します。

docs/ja/api.md
+
+ ストアのルートステートを置き換えます。これは、ステートの水和やタイムトラベルのためだけに利用すべきです。
+
+- **`watch(getter: Function, cb: Function, [options: Object])`**
@kimikimi714
kimikimi714 Dec 1, 2016

https://github.com/vuejs/vuex/blob/dev/docs/en/api.md
でも (state: Object) になっているように思いますが、間違っていますでしょうか?

下の options?: Object にならないといけないところですね。失礼いたしました。修正します。

docs/ja/api.md
+
+- **`hotUpdate(newOptions: Object)`**
+
+ 新しいアクションとミューテーションでホットスワップします。[詳細](hot-reload.md)
@kimikimi714
kimikimi714 Dec 1, 2016

確かに で はおかしいですね。修正します。

docs/ja/api.md
```
- もっともよく利用されるプラグインです。[詳細](plugins.md)
+ プラグインの中でももっともよく利用されます。[詳細](plugins.md)
@ktsn
ktsn Dec 1, 2016 Member

何度もすみません。この訳だと、 subscribe ∈ プラグイン という意味になってしまうと思います。
この文で言いたいのは、この subscribe メソッドの使い道として、それぞれの Vuex プラグインの中で使われることを想定しているということなので、中でも ではなく 中で が良いんじゃないかと思います。

@kimikimi714
kimikimi714 Dec 2, 2016

なるほど!完全に勘違いしていました!
プラグイン内で利用されることがある、ということですね…。
修正します。

@kitak kitak changed the title from [WIP] Translate v2 docs in Japanese. to Translate v2 docs in Japanese. Dec 4, 2016
@kitak
Contributor
kitak commented Dec 4, 2016

Could you please merge it?

@ktsn
ktsn approved these changes Dec 5, 2016 View changes
@ktsn
Member
ktsn commented Dec 5, 2016

@kitak @inouetakuya @tadyjp @kimikimi714
Thanks for your hard work!
Can we add README.md and book.json for Japanese docs for our final task? :)
Make sure to merge latest dev branch into yours since there are a few update for docs.

@kitak
Contributor
kitak commented Dec 5, 2016

@ktsn

OK. I've done them.

@ktsn
Member
ktsn commented Dec 5, 2016

Thanks! I'm merging this.

@ktsn ktsn merged commit 730deb7 into vuejs:dev Dec 5, 2016

1 check passed

ci/circleci Your tests passed on CircleCI!
Details
@ktsn
Member
ktsn commented Dec 5, 2016

Deployed 🎉 https://vuex.vuejs.org/ja/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment