vuejs · posva · Feb 11, 2017 · Jan 31, 2017 · Jan 31, 2017 · Jan 31, 2017
diff --git a/docs/de/SUMMARY.md b/docs/de/SUMMARY.md
@@ -14,13 +14,13 @@
   - [Programmatische Navigation](essentials/navigation.md)
   - [Benannte Routes](essentials/named-routes.md)
   - [Benannte Views](essentials/named-views.md)
-  - [Umleitung und Alias](essentials/redirect-and-alias.md)
+  - [Redirect und Alias](essentials/redirect-and-alias.md)
   - [HTML5-Verlaufsmodus](essentials/history-mode.md)
 - Fortgeschritten
-  - [Navigationsschutz](advanced/navigation-guards.md)
-  - [Route-Metafelder](advanced/meta.md)
-  - [Übergänge](advanced/transitions.md)
-  - [Datenbeschaffung](advanced/data-fetching.md)
+  - [Navigations-Guards](advanced/navigation-guards.md)
+  - [Route Meta-Felder](advanced/meta.md)
+  - [Transitions (Übergänge)](advanced/transitions.md)
+  - [Daten laden](advanced/data-fetching.md)
   - [Scroll-Verhalten](advanced/scroll-behavior.md)
   - [Lazy Loading](advanced/lazy-loading.md)
 - API-Referenz
@@ -29,4 +29,4 @@
   - [Das Route-Objekt](api/route-object.md)
   - [Router-Option](api/options.md)
   - [Router-Instanz](api/router-instance.md)
-  - [Injektion von Komponenten](api/component-injections.md)
+  - [Injection von Komponenten](api/component-injections.md)
diff --git a/docs/de/advanced/data-fetching.md b/docs/de/advanced/data-fetching.md
@@ -1,16 +1,16 @@
-# Datenbeschaffung
+# Daten laden
 
-Manchmal müssen Daten von einem Server geladen werden, sobald eine Route aktiviert wird. Zum Beispiel müssen die Inhalte des Nutzers vom Server übertragen werden, bevor ein Nutzerprofil angezeigt werden kann. Dies wird auf zwei Arten erledigt:
+Oftmals Müssen wir Daten von einem Server laden, sobald eine Route aktiviert wird. Zum Beispiel müssen die Daten des Users vom Server geladen werden, bevor das Userprofil angezeigt werden kann. Dies kann auf zwei Arten erreicht werden:
 
-- **Laden nach Navigation**: Navigiere zuerst und lade die Daten anschließend in der neuen Komponente. Während der Übertragung kann ein Ladebalken oder ähnliches angezeigt werden.
+- **Laden nach der Navigation**: Der Router schließt zuerst die Navigation ab und wir laden die Daten anschließend in der neuen Komponente. Während der Übertragung kann ein Ladebalken oder ähnliches angezeigt in der Komponente werden.
 
-- **Laden vor Navigation**: Lade Daten bevor die Navigation der Route durchgeführt wird und navigiere nachdem die Daten geladen wurden.
+- **Laden der Navigation**: Wir laden Daten bevor die Navigation der Route durchgeführt wird und navigieren danach erst zur neuen Route.
 
-Technisch sind beide Optionen möglich - letztendlich hängt es davon ab, welche Benutzererfahrung man erreichen möchte.
+Technisch gesehen sind beide Optionen gleich "gut" - letztendlich hängt es davon ab, welche Benutzererfahrung man erreichen möchte.
 
-## Laden nach Navigation
+## Laden nach der Navigation
 
-In diesem Fall navigieren und rendern wir die neue Komponente direkt und laden die Daten in der `created`-Funktion der Komponente. Dies ermöglicht es uns den Nutzer zu informieren, dass Daten übertragen werden, während die Inhalte über das Netzwerk nachgereicht werden. Außerdem können wir die Übertragung in jeder Komponente individuell einrichten und sind nicht an ein System gebunden.
+In diesem Fall navigieren und rendern wir die neue Komponente direkt und laden die Daten im `created`-Hook der Komponente. Das ermöglicht es uns dem Nutzer in der neuen Komponente einen Ladebalken oder ähnliches anzuzeigen während der Content vom Server geladen wird. Außerdem können wir so den Ladevorgang in jeder Komponente individuell gestalten.
 
 Im folgenden Beispiel haben wir eine `Post`-Komponente, welche Daten für einen Blog-Post basierend auf `$route.params.id` einholt:
 
@@ -44,7 +44,7 @@ export default {
   },
   created () {
     // Lade die Daten, wenn die Komponente erstellt wurde und die
-    // Daten bereits überwacht werden.
+    // Daten bereits observed ("beobachtet") werden.
     this.fetchData()
   },
   watch: {
@@ -55,7 +55,7 @@ export default {
     fetchData () {
       this.error = this.post = null
       this.loading = true
-      // Ersetze 'getPost' mit einer beliebigen AJAX-API (zB. fetch, $.ajax).
+      // Ersetze 'getPost' mit einem beliebigen AJAX-tool / API-Wrapper
       getPost(this.$route.params.id, (err, post) => {
         this.loading = false
         if (err) {
@@ -69,9 +69,9 @@ export default {
 }
 ```
 
-## Laden vor Navigation
+## Laden vor der Navigation
 
-In diesem Fall werden die Daten geladen, bevor wir in die neue Route navigieren. Die Inhalte werden in dem `beforeRouteEnter`-Schutz der neuen Komponente eingefügt. Die `next`-Funktion wird erst aufgerufen, wenn alles komplett geladen wurde:
+In diesem Fall werden die Daten geladen, bevor wir in die neue Route navigieren. Die Inhalte werden in dem `beforeRouteEnter`-Guard der neuen Komponente geladen. Die `next`-Funktion wird erst aufgerufen, wenn der Vorgang abgeschlossen ist:
 
 ``` js
 export default {
@@ -110,4 +110,4 @@ export default {
 }
 ```
 
-Der Nutzer bleibt im aktuellen View, bis die Daten des neuen geladen wurden. Daher ist es empfehlenswert einen Ladebalken oder ähnliches anzuzeigen. Falls die Inhalte nicht komplett beschafft werden können, ist es außerdem von Vorteil, eine Fehlermeldung auszugeben.
+Der Nutzer bleibt im aktuellen View, während die Daten für den neuen View geladen werden. Daher ist es empfehlenswert, derwiel anderswo in der App einen Ladebalken oder ähnliches anzuzeigen. Wenn der Ladevorgang fehlschlägt, ist es außerdem wichtig, eine Fehlermeldung auszugeben.
diff --git a/docs/de/advanced/lazy-loading.md b/docs/de/advanced/lazy-loading.md
@@ -1,27 +1,27 @@
 # Lazy Loading
 
-Wenn Apps mit einem Bundler zusammengefügt werden, kann die Datei recht groß werden und so die Seitenladezeit beeinträchtigen. Es wäre effizienter, wenn man das Bundle in mehrere Router-Komponenten aufteilen könnte und sie nur dann lädt, wenn die Route besucht wird.
+Wenn Apps mit einem Bundler erstellt werden, kann das erzeugte "Bundle" recht groß werden und so die Seitenladezeit beeinträchtigen. Es wäre effizienter, wenn man das Bundle in die einzelnen  Router-Komponenten aufteilen könnte und sie nur dann lädt, wenn die Route besucht wird.
 
-Mit der Kombination von Vues [asynchronischem Komponenten-Feature](http://vuejs.org/guide/components.html#Async-Components) und Webpacks Feature zur [Code-Aufteilung (englisch)](https://webpack.github.io/docs/code-splitting.html) ist es einfach Lazy Loading von Route-Komponenten zu erreichen.
+Mit der Kombination von Vue's Feature für [asynchrone Komponenten](http://vuejs.org/guide/components.html#Async-Components) und Webpack's Feature ["Code-Splitting"](https://webpack.js.org/guides/code-splitting-require/) (engl. _to split_: _teilen_) ist es einfach, dieses "Lazy Loading" genannte Verhalten für Route-Komponenten zu erreichen.
 
-Alles was benötigt wird, ist die Definition der Route-Komponenten als asynchrone Komponenten:
+Dazu müssen wir nur unsere Route-Komponenten als asynchrone Komponente definieren:
 
 ``` js
 const Foo = resolve => {
-  // require.ensure ist Webpacks speziale Syntax für Code-Aufteilung.
+  // require.ensure ist Webpacks speziale Syntax für Code-Splitting.
   require.ensure(['./Foo.vue'], () => {
     resolve(require('./Foo.vue'))
   })
 }
 ```
 
-Es gibt auch eine alternative Code-Teilungssyntax mit `require` im AMD-Stil:
+Es gibt auch eine alternative Code-Splitting Syntax mit `require` im AMD-Stil, mit der das ganze Folgendermaßen vereinfacht werden kann:
 
 ``` js
 const Foo = resolve => require(['./Foo.vue'], resolve)
 ```
 
-Nichts muss geändert werden in der Route-Konfiguration - nutze `Foo` wie gewohnt:
+In der Route-Konfiguration muss nichts genändert werden - wir nutzen `Foo` wie gewohnt:
 
 ``` js
 const router = new VueRouter({
@@ -33,12 +33,12 @@ const router = new VueRouter({
 
 ### Gruppierung von Komponenten im selben Chunk
 
-Manchmal ist es gewollt, alle Komponenten unter der selben Route in den selben ansynchronen Chunk zu gruppieren. Um das zu erreichen, werden [benannte Chunks (englisch)](https://webpack.github.io/docs/code-splitting.html#named-chunks) genutzt. Hierbei wird ein Chunk-Name als drittes Argument für `require.ensure` hinzugefügt.
+Manchmal wollen wir alle Komponenten unter der selben Route in den selben ansynchronen Chunk gruppieren. Dafür benutzern wir das ["named Chunks" (englisch)](https://webpack.js.org/guides/code-splitting-require/#chunkname) Feature, indem wir einen Chunk-Namen als drittes Argument für `require.ensure` hinzugefügen.
 
 ``` js
 const Foo = r => require.ensure([], () => r(require('./Foo.vue')), 'group-foo')
 const Bar = r => require.ensure([], () => r(require('./Bar.vue')), 'group-foo')
 const Baz = r => require.ensure([], () => r(require('./Baz.vue')), 'group-foo')
 ```
 
-Webpack packt alle asynchronen Module mit dem gleichen Chunk-Namen in den selben asynchronen Chunk. Das bedeutet auch, dass keine Abhängigkeiten mehr für `require.ensure` explizit aufgelistet werden müssen - daher der leere Array als Argument.
+Webpack bündelt alle asynchronen Module mit dem gleichen Chunk-Namen in denselben asynchronen Chunk. Das bedeutet auch, dass keine Dependencies mehr für `require.ensure` explizit aufgelistet werden müssen - daher der leere Array als Argument.
diff --git a/docs/de/advanced/meta.md b/docs/de/advanced/meta.md
@@ -1,6 +1,6 @@
-# Route-Metafelder
+# Route Meta-Felder
 
-Man kann ein Metafeld einfügen, wenn die Route definiert wird:
+In der Route-Definition kann man ein Meta-Feld definieren:
 
 ``` js
 const router = new VueRouter({
@@ -21,22 +21,22 @@ const router = new VueRouter({
 })
 ```
 
-Wie greift man auf das `meta`-Feld zu?
+Und wie greifen wir auf das `meta`-Feld zu?
 
-Zunächst einmal wird jedes Route-Objekt in der `routes`-Konfiguration **Route-Eintrag** genannt. Route-Einträge können verschachtelt sein. Deswegen kann eine Route zu mehreren Einträgen passen, wenn sie besucht wird.
+Zunächst einmal: Wir nennen jedes Route-Objekt in der `routes`-Konfiguration **Route-Record**. Route-Records können verschachtelt sein, weshalb eine URL potentiell zu mehreren Route-Records passen kann.
 
-Zum Beispiel werden mit der obigen Konfiguration und der URL `/foo/bar` beide - Parent-Eintrag und Child-Eintrag - angesprochen.
+Zum Beispiel werden mit der obigen Konfiguration und der URL `/foo/bar` beide - Parent-Record und Child-Record - gematched.
 
-Alle Route-Einträge, die auf eine Route zutreffen, sind im `$route`-Objekt und in Route-Objekten im Navigationschutz als `$route.matched`-Array vorzufinden. Deswegen muss eine Schleife auf `$route.matched` angewandt werden, um alle Metafelder im Route-Eintrag zu erhalten.
+Alle Route-Records, die auf eine URL zutreffen, sind im `$route`-Objekt und in den Route-Objekten in Navigation-Guards im `$route.matched`-Array zu finden. Deswegen müssen wir mit einer Schleife das `$route.matched` Array durchlaufen, um alle Route-Records auf Metafelder zu prüfen.
 
-Ein Beispiel ist die Prüfung nach einem Metafeld im globalen Navigationsschutz:
+Ein Anwendungsfall ist die Prüfung nach einem Metafeld im globalen Before-Guard:
 
 ``` js
 router.beforeEach((to, from, next) => {
   if (to.matched.some(record => record.meta.requiresAuth)) {
     // Diese Route benötigt Authentifizierung und prüft,
     // ob man eingeloggt ist.
-    // Wenn nicht, Umleitung zur Login-Seite.
+    // Wenn nicht, Redirect zur Login-Seite.
     if (!auth.loggedIn()) {
       next({
         path: '/login',

diff --git a/docs/de/advanced/navigation-guards.md b/docs/de/advanced/navigation-guards.md
@@ -1,12 +1,12 @@
-# Navigationsschutz
+# Navigation Guards ("Navigations-Wächter")
 
-Der Navigationsschutz bereit gestellt vom `vue-router` wird primär genutzt, um Navigationen vor Umleitung oder Unterbrechung zu schützen. Es gibt eine Vielzahl an Wege: global, per-route oder in der Komponente.
+Wie der Name schon andeutet, werden "navigation guards" `vue-router` primär genutzt, um Navigationen zu "bewachen", indem diese bei Bedarf redirected oder abebrochen werden. Es gibt dabei verschiedene Möglichkeiten, sich in den Navigationsprozess einzuklinken: global, in der Route Definition oder direkt in der Komponente.
 
-Merke, dass Parameter oder Query-Abfragen den Navigationsschutz nicht auslosen. Beobachte einfach [das `$route`-Objekt](../essentials/dynamic-matching.md#reacting-to-params-changes), um auf Änderungen zu reagieren.
+Hinweis: Guards werden nicht ausgelöst, wenn du Params oder Querys änderst. Beobachte in diesen Fällen einfach [das `$route`-Objekt](../essentials/dynamic-matching.md#reacting-to-params-changes), um auf Änderungen zu reagieren.
 
-### Globaler Schutz
+### Globale Guards
 
-Man kann globalen Schutz für die Zeit direkt vor einer Navigation (globaler Vor-Schutz) mit `router.beforeEach` anwenden:
+Man kann globale Before-Guards ("davor-guards") mit `router.beforeEach` registrieren:
 
 ``` js
 const router = new VueRouter({ ... })
@@ -16,35 +16,35 @@ router.beforeEach((to, from, next) => {
 })
 ```
 
-Globale Vor-Schutze werden in Kreierungsreihenfolge aufgerufen, wenn eine Navigation ausgelöst wird. Der Schutz darf auch asynchron angewandt werden, sodass die Navigation als **unerledigt** da steht, bis alle bearbeitet wurden.
+Globale Before-Guards werden in der Reihenfolge aufgerufen, in der du sie registriert hast, wann immer eine Navigation ausgelöst wird. Der guard lann auch auch asynchron beendet werden, und die Navigation ist solange im Status **pending**, bis alle bearbeitet wurden.
 
-Jede Schutzfunktion erhält drei Argumente:
+Jede Guard Funktion erhält drei Argumente:
 
 - **`to: Route`**: das [Route-Objekt](../api/route-object.md), zu dem navigiert wird
 
 - **`from: Route`**: die aktuelle Route, von der wegnavigiert wird
 
-- **`next: Function`**: Diese Funktion muss aufgerufen werden, um den Hook aufzulösen. Die Aktion hängt von den Argumenten in `next` ab:
+- **`next: Function`**: Diese Funktion muss aufgerufen werden, um den guard zu beenden. Die daraus resultierende Aktion hängt von den Argumenten in `next` ab:
 
-  - **`next()`**: Gehe zum nächsten Hook in der Leitung. Wenn keiner vorhanden ist, ist die Navigation **bestätigt**.
+  - **`next()`**: Gehe zum nächsten guard in der Riehe. Wenn keine mehr vorhanden sind, ist die Navigation **bestätigt**.
 
-  - **`next(false)`**: Brich die aktuelle Navigation ab. Wurde die URL geändert (entweder manuell durch den Nutzer oder via Zurück-Button), wird es zurückgesetzt zu dem, was die `from`-Route wiedergab.
+  - **`next(false)`**: Brich die aktuelle Navigation ab. Wurde die URL geändert (entweder manuell durch den Nutzer oder über den Zurück-Button), wird sie zurückgesetzt auf die der `from`-Route.
 
-  - **`next('/')` or `next({ path: '/' })`**: Umleitung zu einem anderen Ort. Die aktuelle Navigation wird abgebrochen und eine neue gestartet.
+  - **`next('/')` or `next({ path: '/' })`**: Umleitung zu einer anderen Route. Die aktuelle Navigation wird abgebrochen und eine neue gestartet.
 
-**Die `next`-Funktion muss immer aufgerufen werden, sonst kann der Hook nicht aufgelöst werden.**
+**Die `next`-Funktion muss immer aufgerufen werden, sonst kann der Guard nicht aufgelöst werden.**
 
-Man kann auch globale Nach-Hooks registrieren, allerdings erhalten diese keine `next`-Funktion wie der Navigationsschutz und beeinflussen nicht die Navigation selbst:
+Man kann auch globale After-Guards ("Danach-Guards") registrieren, allerdings erhalten diese keine `next`-Funktion wie der Navigationsschutz und beeinflussen nicht die Navigation selbst:
 
 ``` js
 router.afterEach((to, from) => {
   // ...
 })
 ```
 
-### Per-Route-Schutz
+### Guards in der Route
 
-Man kann den `beforeEnter`-Schutz direkt in der Router-Konfiguration definieren:
+Man kann den `beforeEnter`-Guard direkt in der Router-Konfiguration definieren:
 
 ``` js
 const router = new VueRouter({
@@ -60,30 +60,30 @@ const router = new VueRouter({
 })
 ```
 
-Diese Schutze haben die exakt gleiche Signature als globale Vor-Schutze.
+Diese Guards haben die exakt gleiche Signatur wie globale Before-Guards.
 
-### Schutz in Komponenten
+### Guards in Komponenten
 
-Letztendlich kann man auch Navigationsschutz in den Route-Komponenten (die, die der Router-Konfiguration hinzugefügt werden) mit `beforeRouteEnter` und `beforeRouteLeave` definieren:
+Zu guter Letzt kann man Guards auch direkt in den Route-Komponenten (die, die der Router-Konfiguration hinzugefügt werden) mit `beforeRouteEnter` und `beforeRouteLeave` definieren:
 
 ``` js
 const Foo = {
   template: `...`,
   beforeRouteEnter (to, from, next) {
-    // Aufgerufen bevor die Route bestätigt wird, die die Komponenten rendert.
-    // Hat keinen Zugang zum `this`-Kontext der Komponenteninstanz,
-    // da es noch nicht erstellt wurde, wenn der Schutz aufgerufen wird.
+    // Wird aufgerufen bevor die Route bestätigt wird, die diese Komponenten rendert.
+    // Hat keinen Zugriff auf den `this`-Kontext der Komponenteninstanz,
+    // da diese noch nicht erstellt wurde, wenn die Guard-Funktion aufgerufen wird.
   },
   beforeRouteLeave (to, from, next) {
-    // Aufgerufen, wenn von der Route, die die Komponente rendert, wegnavigiert wird.
+    // Wird aufgerufen, wenn von der Route, die diese Komponente rendert, wegnavigiert wird.
     // Hat Zugriff zum `this`-Kontext.
   }
 }
 ```
 
-Der `beforeRouteEnter`-Schutz hat keinen Zugriff zum `this`-Kontext, weil der Schutz aufgerufen wird, bevor die Navigation bestätigt wurde, demnach wurde die Komponente noch gar nicht kreiert.
+Der `beforeRouteEnter`-Guard hat keinen Zugriff auf den `this`-Kontext, weil der Guard aufgerufen wird, bevor die Navigation bestätigt wurde, weshalb die Komponente noch gar nicht erzeugt wurde.
 
-Allerdings hat man Zugriff auf die Instanz, indem man einen Callback an `next` anfügt. Dieser wird aufgerufen, wenn die Navigation bestätigt wurde. Die Komponente wird im Callback als Argument hinzugefügt:
+Allerdings bekommt man Zugriff auf die Instanz, indem man einen Callback an `next` übergibt. Der Callback wird ausgeführt wenn die Navigation bestätigt wurde. Die Komponente wird im Callback als Argument übergeben:
 
 ``` js
 beforeRouteEnter (to, from, next) {
@@ -93,4 +93,4 @@ beforeRouteEnter (to, from, next) {
 }
 ```
 
-Man kann den `this`-Kontext in `beforeRouteLeave` aufrufen. Der Abgangsschutz wird normalerweise genutzt, um versehentliches Verlassen der Route mit ungesicherten Arbeiten zu verhindern. Die Navigation kann mit `next(false)` abgebrochen werden.
+In `beforeRouteLeave`-Guards kann man den `this`-Kontext aufrufen. Dieser Guard wird normalerweise verwendet, zu verhindern dass ein Benutzer die Route versehentlich verlässt, ohne ungesicherten Arbeit zu speichern. Die Navigation kann mit `next(false)` abgebrochen werden.