From c3d8e15f72ec0ba541a2b6aea0b30da7d4cca75a Mon Sep 17 00:00:00 2001
From: Youngwon Seo <jazz9008@gmail.com>
Date: Mon, 10 Sep 2018 13:20:13 +0900
Subject: [PATCH 1/3] Update index.md

---
 src/v2/style-guide/index.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/v2/style-guide/index.md b/src/v2/style-guide/index.md
index dd41e0f2ce..7ec28131b2 100644
--- a/src/v2/style-guide/index.md
+++ b/src/v2/style-guide/index.md
@@ -34,7 +34,7 @@ Where multiple, equally good options exist, an arbitrary choice can be made to e
 
 ### 우선순위 D: 주의요함
 
-Some features of Vue exist to accommodate rare edge cases or smoother migrations from a legacy code base. When overused however, they can make your code more difficult to maintain or even become a source of bugs. These rules shine a light on potentially risky features, describing when and why they should be avoided.
+뷰의 몇 가지 은 특성은 드문 엣지 케이스 또는 레거시 코드로의 부터 마이크레이션을 위해 존재합니다. 그러나 그것들을 남용하면 당신의 코드를 유지보수하기 어렵게만들거나 버그를 발생시키는 원인이 될 수 있습니다. 이 규칙은 잠재적 위험요소를 인식시켜주고 언제 그리고 왜 피해야되는지 설명해 줍니다.
 
 
 
@@ -85,14 +85,14 @@ export default {
 
 ### 컴포넌트 데이터 <sup data-p="a">필수</sup>
 
-**컴포넌트의 `data` 는 반드시 함수여야 다.**
+**컴포넌트의 `data` 는 반드시 함수여야 합니다.**
 
 컴포넌트(i.e. `new Vue`를 제외한 모든곳)의 `data` 속성은 값으로 오브젝트를 반환하는 함수여야 합니다.
 
 {% raw %}
 <details>
 <summary>
-  <h4>Detailed Explanation</h4>
+  <h4>상세 설명</h4>
 </summary>
 {% endraw %}
 
@@ -178,9 +178,9 @@ new Vue({
 
 ### Props 정의 <sup data-p="a">필수</sup>
 
-**Prop definitions should be as detailed as possible.**
+**Prop은 가능한 상세하게 정의되어야 합니다.**
 
-In committed code, prop definitions should always be as detailed as possible, specifying at least type(s).
+커밋 된 코드에서, prop 정의는 적어도 타입은 명시되도록 가능한 상세하게 정의되어야 합니다.
 
 {% raw %}
 <details>
@@ -237,9 +237,9 @@ props: {
 
 ### `v-for`에 키 지정  <sup data-p="a">필수</sup>
 
-**Always use `key` with `v-for`.**
+**`v-for`는 `key`와 항상 함께 사용되어야 합니다.**
 
-`key` with `v-for` is _always_ required on components, in order to maintain internal component state down the subtree. Even for elements though, it's a good practice to maintain predictable behavior, such as [object constancy](https://bost.ocks.org/mike/constancy/) in animations.
+서브트리의 내부 컴포넌트 상태를 유지하기 위해 `v-for`는 _항상_ `key`와 함께 요구됩니다. 비록 엘리먼트이긴 하지만 에니메이션의 [객체 불변성](https://bost.ocks.org/mike/constancy/)과 같이 예측 가능한 행동을 유지하는것은 좋은 습관입니다.
 
 {% raw %}
 <details>

From e7c8fe9e621a099982e9920da475ed22893f57bb Mon Sep 17 00:00:00 2001
From: Youngwon Seo <jazz9008@gmail.com>
Date: Tue, 11 Sep 2018 08:51:38 +0900
Subject: [PATCH 2/3] Update index.md

---
 src/v2/style-guide/index.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/v2/style-guide/index.md b/src/v2/style-guide/index.md
index 7ec28131b2..70f4c65e86 100644
--- a/src/v2/style-guide/index.md
+++ b/src/v2/style-guide/index.md
@@ -26,11 +26,11 @@ type: style-guide
 
 ### 우선순위 C: 추천함
 
-Where multiple, equally good options exist, an arbitrary choice can be made to ensure consistency. In these rules, we describe each acceptable option and suggest a default choice. That means you can feel free to make a different choice in your own codebase, as long as you're consistent and have a good reason. Please do have a good reason though! By adapting to the community standard, you will:
+동일하게 좋은 여러가지 옵션이 존재하는 경우, 일관성을 보장하기 위해 임의의 선택을 할 수 있습니다. 이 규칙은 각각의 수용가능한 옵션을 설명하고 기본 선택을 제안합니다. 즉, 일관성 있고 좋은 이유가 있으면 당신의 코드베이스에서 자유롭게 다른 선택을 할 수 있습니다. 좋은 이유가 있어야 합니다! 커뮤니티 표준에 적응되기 위해서 당신은 다음과 같이 해야합니다.
 
-1. train your brain to more easily parse most of the community code you encounter
-2. be able to copy and paste most community code examples without modification
-3. often find new hires are already accustomed to your preferred coding style, at least in regards to Vue
+1. 당신이 마주하는 대부분의 커뮤니티 코드를 더 쉽게 분석할 수 있도록 훈련하세요
+2. 커뮤니티 코드 예제를 수정하기 한고 복사 그리고 붙혀넣기 할 수 있어야 합니다
+3. 적어도 뷰에 있어서는 당신이 선호하는 코딩 스타일을 수용하는 새로운 직원을 자주 찾을 것입니다
 
 ### 우선순위 D: 주의요함
 

From 03607642d092570f58c97b5a17cd77ce49ad767e Mon Sep 17 00:00:00 2001
From: Youngwon Seo <jazz9008@gmail.com>
Date: Wed, 12 Sep 2018 13:06:29 +0900
Subject: [PATCH 3/3] Update index.md

---
 src/v2/style-guide/index.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/v2/style-guide/index.md b/src/v2/style-guide/index.md
index 70f4c65e86..cc874c4c80 100644
--- a/src/v2/style-guide/index.md
+++ b/src/v2/style-guide/index.md
@@ -306,13 +306,13 @@ In our experience, it's better to _always_ add a unique key, so that you and you
 
 ### `v-if`와 `v-for`를 동시에 사용하지 마세요 <sup data-p="a">essential</sup>
 
-**Never use `v-if` on the same element as `v-for`.**
+**`v-for`가 사용된 엘리먼트에 절대 `v-if`를 사용하지 마세요.**
 
-There are two common cases where this can be tempting:
+사용 가능해 보이는 두 가지 일반적인 경우가 있습니다:
 
-- To filter items in a list (e.g. `v-for="user in users" v-if="user.isActive"`). In these cases, replace `users` with a new computed property that returns your filtered list (e.g. `activeUsers`).
+- 리스트 목록을 필터링하기 위해서 입니다 (e.g. `v-for="user in users" v-if="user.isActive"`).  이 경우 users을 새로운 computed 속성으로 필더링된 목록으로 대체하십시오(e.g. `activeUsers`).
 
-- To avoid rendering a list if it should be hidden (e.g. `v-for="user in users" v-if="shouldShowUsers"`). In these cases, move the `v-if` to a container element (e.g. `ul`, `ol`).
+- 숨기기 위해 리스트의 랜더링을 피할 때 입니다 (e.g. `v-for="user in users" v-if="shouldShowUsers"`). 이 경우 `v-if`를 컨테이너 엘리먼트로 옮기세요 (e.g. `ul`, `ol`).
 
 {% raw %}
 <details>