+```
+
+この `data-server-rendered` という特別な属性は、クライアントサイドの Vue に、これがサーバ上で描画されたことを知らせ、この要素はハイドレーションモードでマウントされるはずです。
+
+開発モードでは、Vue はクラインアントサイドで生成された仮想 DOM が、サーバで描画された DOM の構成とマッチしているか検証を行います。もしこれがマッチしていない場合、ハイドレーションを取りやめ、元の DOM を無視しスクラッチから描画を行います。**プロダクションモードでは、パフォーマンスの最大化のため、このアサーションは無効になります。**
+
+### ハイドレーション時の注意
+
+サーバサイドレンダリングとクライアントサイドでのハイドレーションを行なった場合、ある特定の HTML の構造はブラウザによって変換されるかもしれないことがわかっています。例えば、あなたが Vueのテンプレート内に、以下のような記述をした場合です。
+
+```html
+
+```
+
+ブラウザは、自動で `
` を `` に挿入します。しかし、Vue によって生成された仮想 DOM は、`` を含みません。そのため、ミスマッチが起こります。正しいマッチングを保証するために、あなたのテンプレート内では、必ず有効な HTML を記述してください。
diff --git a/ja/routing.md b/ja/routing.md
new file mode 100644
index 00000000..41c71415
--- /dev/null
+++ b/ja/routing.md
@@ -0,0 +1,136 @@
+# ルーティングとコード分割
+
+## `vue-router` によるルーティング
+
+サーバーコードが任意の URL を受け入れる `*` ハンドラを使用していることに気付いたかもしれません。これにより訪れた URL を Vue アプリケーションに渡し、クライアントとサーバーの両方に同一のルーティング設定を再利用することが可能になります！
+
+この目的のために公式の `vue-router` を使用することが推奨されています。まずはルーターを作成するファイルを作成しましょう。 `createApp` に似ていますが、 リクエストごとに新たなルーターインスタンスも必要となるため、 `createRouter` 関数をエクスポートします。
+
+```js
+// router.js
+import Vue from 'vue'
+import Router from 'vue-router'
+Vue.use(Router)
+export function createRouter () {
+ return new Router({
+ mode: 'history',
+ routes: [
+ // ...
+ ]
+ })
+}
+```
+
+そして `app.js` を更新します。
+
+```js
+// app.js
+import Vue from 'vue'
+import App from './App.vue'
+import { createRouter } from './router'
+export function createApp () {
+ // ルーターインスタンスを作成します
+ const router = createRouter()
+ const app new Vue({
+ // ルーターをルートVueインスタンスに注入します
+ router,
+ render: h => h(App)
+ })
+ // アプリケーションとルーターの両方を返します
+ return { app, router }
+}
+```
+
+`entry-server.js` にサーバー側のルーティングロジックを実装する必要があります。
+
+```js
+// entry-server.js
+import { createApp } from './app'
+export default context => {
+ // 非同期のルートフックまたはコンポーネントが存在する可能性があるため、
+ // レンダリングする前にすべての準備が整うまでサーバーが待機できるように
+ // プロミスを返します。
+ return new Promise((resolve, reject) => {
+ const { app, router } = createApp()
+ // サーバーサイドのルーターの場所を設定します
+ router.push(context.url)
+ // ルーターが非同期コンポーネントとフックを解決するまで待機します
+ router.onReady(() => {
+ const matchedComponents = router.getMatchedComponents()
+ // 一致するルートがない場合、404で拒否します
+ if (!matchedComponents.length) {
+ reject({ code: 404 })
+ }
+ // プロミスはレンダリングできるようにアプリケーションインスタンスを解決するべきです
+ resolve(app)
+ }, reject)
+ })
+}
+```
+
+サーバーバンドルがすでにビルドされていると仮定すると（再度になりますが、今はビルド設定は無視します）、サーバーでの使用方法は次のようになります。
+
+```js
+// server.js
+const createApp = require('/path/to/built-server-bundle.js')
+server.get('*', (req, res) => {
+ const context = { url: req.url }
+ createApp(context).then(app => {
+ renderer.renderToString(app, (err, html) => {
+ if (err) {
+ if (err.code === 404) {
+ res.status(404).end('Page not found')
+ } else {
+ res.status(500).end('Internal Server Error')
+ }
+ } else {
+ res.end(html)
+ }
+ })
+ })
+})
+```
+
+## コード分割
+
+コード分割やアプリケーションの部分的な遅延ローディングは初期レンダリングのためにブラウザがダウンロードする必要のあるアセットの量を減らすのに役立ち、巨大なバンドルを持つアプリケーションの TTI （操作可能になるまでの時間）を大幅に改善します。重要なことは初期画面では"必要なものだけを読み込む"ということです。
+
+Vue は非同期コンポーネントを最重要コンセプトとして提供しており、 [webpack 2の動的インポートをコード分割点として使用することへのサポート](https://webpack.js.org/guides/code-splitting-async/) と組み合わせることも可能です。そのためにすべきことは以下です。
+
+```js
+// これを...
+import Foo from './Foo.vue'
+// このように変えます。
+const Foo = () => import('./Foo.vue')
+```
+
+純粋なクライアントサイドの Vue アプリケーションを構築する場合、これはどんなシナリオでも機能するでしょう。ただし、これをサーバーサイドレンダリングで使用する場合はいくつかの制限があります。まず、レンダリングを開始する前にサーバー上のすべての非同期コンポーネントを先に解決する必要があります。そうしなければ、マークアップ内に空のプレースホルダが表示されます。クライアント側では、ハイドレーションを開始する前にこれを行う必要があります。そうしなければ、クライアントはコンテンツの不一致エラーに陥ります。
+
+アプリケーション内の任意の場所で非同期コンポーネントを使用するのは少し難解です（これは将来的に改善される可能性があります）。 ただし、**ルートレベルで行うとシームレスに動作します**（すなわち、ルート設定で非同期コンポーネントを使用する）。ルートを解決する際に、 `vue-router` は一致した非同期コンポーネントを自動的に解決するためです。 必要なことは、サーバーとクライアントの両方で `router.onReady` を使用することです。すでにサーバーのエントリーで行ったので、クライアントのエントリーを更新するだけです。
+
+```js
+// entry-client.js
+import { createApp } from './app'
+const { app, router } = createApp()
+router.onReady(() => {
+ app.$mount('#app')
+})
+```
+
+非同期ルートコンポーネントを使用したルート設定の例：
+
+```js
+// router.js
+import Vue from 'vue'
+import Router from 'vue-router'
+Vue.use(Router)
+export function createRouter () {
+ return new Router({
+ mode: 'history',
+ routes: [
+ { path: '/', component: () => import('./components/Home.vue') },
+ { path: '/item/:id', component: () => import('./components/Item.vue') }
+ ]
+ })
+}
+```
diff --git a/ja/streaming.md b/ja/streaming.md
new file mode 100644
index 00000000..91cd9354
--- /dev/null
+++ b/ja/streaming.md
@@ -0,0 +1,30 @@
+# ストリーミング
+
+`vue-server-renderer` は、基本的なレンダラーとバンドルレンダラーの両方のためにストリームレンダリングをサポートします。`renderToString` の代わりに`renderToStream`を使用するだけです：
+
+```js
+const stream = renderer.renderToStream(context)
+```
+
+返り値は [Node.js stream](https://nodejs.org/api/stream.html) です：
+
+```js
+let html = ''
+stream.on('data', data => {
+ html += data.toString()
+})
+stream.on('end', () => {
+ console.log(html) // render complete
+})
+stream.on('error', err => {
+ // handle error...
+})
+```
+
+## ストリーミングに関する注意事項
+
+ストリームレンダリングモードでは、レンダラーが仮想 DOM ツリーを横断するときに、できるだけ早くデータを出力します。つまり、より早く「最初のチャンク」を取得し、それをクライアントにすばやく出力し始めることを意味します。
+
+しかし、最初のデータチャンクが発行したときに子コンポーネントがまだインスタンス化されていないと、ライフサイクルフックが呼び出されることはありません。つまり、子コンポーネントがライフサイクルフック内のレンダリングコンテキストにデータを添付する必要がある場合、これらのデータはストリームの開始時に使用できません。アプリケーションは全体の HTML の表示の前に多くのコンテキスト情報（ヘッド情報やインラインに書かれたクリティカル CSS など）を表示する必要があるため、これらのコンテキストデータを使用する前にストリームの完了を待つ必要があります。
+
+したがって、コンポーネントライフサイクルフックによって読み込まれたコンテキストデータに依存する場合は、ストリーミングモードを使用することは**推奨されません**。
diff --git a/ja/structure.md b/ja/structure.md
new file mode 100644
index 00000000..a156b862
--- /dev/null
+++ b/ja/structure.md
@@ -0,0 +1,114 @@
+# ソースコードの構造
+
+## ステートフルなシングルトンは避ける
+
+クライアントのみのコードを書くとき、私たちはコードが毎回新しいコンテキストで評価されるという事実に慣れています。しかし、 Node.js サーバーは長時間実行されるプロセスです。私たちのコードがプロセスに要求されるとき、それは一度評価されメモリにとどまります。つまりシングルトンのオブジェクトを作成したとき、それは全ての受信リクエスト間でシェアされると言うことです。
+
+基本的な例としては、私たちは **リクエストごとに新しいルート Vue インスタンスを作成します**。それは各ユーザがそれぞれのブラウザでアプリケーションの新しいインスタンスを使用することに似ています。もし私たちが複数のリクエストをまたいでインスタンスを共有すると、それは容易にクロスリクエスト状態の汚染につながるでしょう。
+
+そのため、直接アプリケーションのインスタンスを作成するのではなく、各リクエストで繰り返し実行される新しいアプリケーションのインスタンスを作成するファクトリ関数を公開する必要があります：
+
+```js
+// app.js
+const Vue = require('vue')
+module.exports = function createApp (context) {
+ return new Vue({
+ data: {
+ url: context.url
+ },
+ template: `The visited URL is: {{ url }}
`
+ })
+}
+```
+
+そして私たちのサーバーコードはこうなります：
+
+```js
+// server.js
+const createApp = require('./app')
+server.get('*', (req, res) => {
+ const context = { url: req.url }
+ const app = createApp(context)
+ renderer.renderToString(app, (err, html) => {
+ // エラーをハンドリングします
+ res.end(html)
+ })
+})
+```
+
+同じルールがルータ、ストア、イベントバスのインスタンスに適用されます。モジュールから直接エクスポートしアプリケーションにインポートするのでは無く、 `createApp` で新しいインスタンスを作成し、ルート Vue インスタンスから注入する必要があります。
+
+> `{ runInNewContext: true }` でバンドルレンダラを使用するとき、その制約を取り除くことが可能です。しかし各リクエストに対して新しい VM コンテキストを作成する必要があるため、いくらか重大なパフォーマンスコストがかかります。
+
+## ビルドステップの紹介
+
+これまでは、同じ Vue アプリケーションをクライアントへ配信する方法を論じてはいませんでした。これを行うには、webpack を使用して Vue アプリケーションをバンドルする必要があります。実際、webpack を使用して Vue アプリケーションをサーバーにバンドルしたいと思っているのはおそらく次の理由によるものです。
+
+- 典型的な Vue アプリケーションは webpack と `vue-loader` によってビルドされ、 `file-loader` 経由でのファイルのインポートや`css-loader` 経由でCSSをインポートなどの多くの webpack 固有の機能は Node.jsで直接動作しません。
+- Node.jsの最新バージョンはES2015の機能を完全にサポートしていますが、古いブラウザに対応するためにクライアントサイドのコードをトランスパイルする必要があります。これはビルドステップにも再び関係します。
+
+従って基本的な考え方は webpack を使用してクライアントとサーバー両方をバンドルすることです。サーバーバンドルはサーバーによって SSR のために要求され、クライアントバンドルは静的なマークアップのためにブラウザに送信されます。
+
+
+
+セットアップの詳細については次のセクションで議論されます。今のところ、ビルドのセットアップが分かっていると仮定すると、webpack を有効にして Vue アプリケーションコードを書くことが可能になっています。
+
+## Webpackによるコード構造
+
+webpack を使用してサーバーとクライアントのアプリケーションを処理しているので、ソースコードの大部分はユニバーサルに書かれており、すべての webpack の機能にアクセスできます。 同時に、ユニバーサルなコードを書くときに留意すべき[いくつかあります。](./universal.md)
+
+シンプルなプロジェクトは以下のようになります：
+
+```bash
+src
+├── components
+│ ├── Foo.vue
+│ ├── Bar.vue
+│ └── Baz.vue
+├── App.vue
+├── app.js # 共通のエントリ
+├── entry-client.js # ブラウザでのみ実行されます
+└── entry-server.js # サーバでのみ実行されます
+```
+
+### `app.js`
+
+`app.js` はアプリケーションのユニバーサルエントリーです。クライアントアプリケーションでは、このファイルにルート Vue インスタンスを作成し、DOM に直接マウントします。しかし、SSRの場合は責務はクライアント専用のエントリファイルに映されます。`app.js` はシンプルに `createApp` 関数をエクスポートします:
+
+```js
+import Vue from 'vue'
+import App from './App.vue'
+// 新しいアプリケーション・ルータ・ストアを作成するためのファクトリ関数をエクスポートします
+// インスタンス
+export function createApp () {
+ const app = new Vue({
+ // ルートインスタンスは単にAppコンポーネントをレンダリングします
+ render: h => h(App)
+ })
+ return { app }
+}
+```
+
+### `entry-client.js`:
+
+クライアントエントリは単にアプリケーションを作成しそれをDOMにマウントします：
+
+```js
+import { createApp } from './app'
+// クライアント固有の初期化ロジック
+const { app } = createApp()
+// これは App.vue テンプレートのルート要素が id="app" だからです。
+app.$mount('#app')
+```
+
+### `entry-server.js`:
+
+サーバーエントリはレンダリングごとに繰り返し呼び出すことができる関数をデフォルトでエクスポートします。現時点では、アプリケーションインスタンスを作成して返す以外のことはほとんど行いませんが、後でサーバーサイドのルートマッチングとデータプリフェッチロジックを実行します。
+
+```js
+import { createApp } from './app'
+export default context => {
+ const { app } = createApp()
+ return app
+}
+```
diff --git a/ja/universal.md b/ja/universal.md
new file mode 100644
index 00000000..f2bd9713
--- /dev/null
+++ b/ja/universal.md
@@ -0,0 +1,30 @@
+# ユニバーサルなコードを書く
+
+サーバサイドレンダリングについて、さらに見ていく前に、"ユニバーサル"なコード(サーバーとクライアントの両方で動作するコード)を記述するときの制約について考えてみましょう。ユースケースとプラットフォームの API の相違により、異なる環境で実行したコードの動作は全く同じものにはなりません。ここでは、サーバーサイドレンダリングを行う上で、知っておく必要がある重要な項目について説明します。
+
+## サーバー上でのデータリアクティビテイ
+
+クライアントだけで実行するアプリでは、全てのユーザーがブラウザでアプリケーションの新しいインスタンスを使用します。サーバーサイドレンダリングでも、同じ振る舞いが必要とされます: すなわち、複数のリクエストに跨った状態の汚染がないよう各リクエストは新しく独立したアプリケーションのインスタンスが必要になります。
+
+実際のレンダリングプロセスは決定的であることが求められるので、サーバー上でデータを"プリフェッチ"することもあります。これはレンダリングを開始する時、アプリケーションの状態は既に解決済みであることを意味します。つまり、サーバー上では、データがリアクティブである必要はないので、デフォルトで無効になっています。データをリアクティブにしないことで、データをリアクティブなオブジェクトに変換する際のパフォーマンスコストを無視できます。
+
+## コンポーネントライフサイクルフック
+
+動的な更新がないので、ライフサイクルフックのうち、`beforeCreate` と `created` のみが SSR 中に呼び出されます。つまり、 `beforeMount` や `mounted` などの他のコンポーネントサイクルフックは、クライアントでのみ実行されます。
+
+## プラットフォーム固有の API にアクセスする
+
+ユニバーサルコードでは、プラットフォーム固有の API へのアクセスは想定されていないので、`window` や `document` といったブラウザ環境のグローバル変数を直接使用すると、Node.js ではエラーが発生します。
+
+サーバーとクライアントでコードを共有するものの、タスクが使用する API がプラットフォームによって異なる場合は、プラットフォーム固有の実装を ユニバーサル な API の内部でラップするか、それを行うライブラリを使用することをお勧めします。例えば、[axios](https://github.com/mzabriskie/axios) は、サーバーとクライアントの両方に同じ API を提供する HTTP クライアントです。
+
+ブラウザ API を利用する際の一般的なアプローチは、クライアントだけで実行されるライフサイクルの中で遅延的にアクセスすることです。
+
+サードパーティライブラリがユニバーサルに使用することを考慮していない場合、それをサーバーサイドレンダリングするアプリケーションに統合することは難しいので注意してください。グローバル変数のいくつかをモックすることで動かすことができるようになる *かも*しれませんが、それはハックであり、他のライブラリの環境検出のコードを妨げる恐れがあります。
+
+## カスタムディレクティブ
+
+ほとんどの カスタムディレクティブ は直接 DOM を操作するため、SSR 中にエラーが発生します。これを回避するには、2つの方法があります:
+
+1. 抽象化の仕組みとしてコンポーネントを使用し、カスタムディレクティブの代わりに仮想 DOM レベル（例えば、render 関数を使用すること)で実装することをお勧めします。
+2. コンポーネントに簡単に置き換えができないカスタムディレクティブの場合、サーバーレンダラーを生成する際の [`directives`](./api.md#directives) オプションを使用して、そのオプションの "サーバーサイドのバージョン" を用意することで回避できます。