diff --git a/docs/docs/04-multiple-components.ko-KR.md b/docs/docs/04-multiple-components.ko-KR.md
index 2a27dbf3b8..d1eefc04f0 100644
--- a/docs/docs/04-multiple-components.ko-KR.md
+++ b/docs/docs/04-multiple-components.ko-KR.md
@@ -152,7 +152,8 @@ var MyComponent = React.createClass({
);
}
});
-
+```
+```javascript
// 맞음 :)
var ListItemWrapper = React.createClass({
render: function() {
diff --git a/docs/docs/07-forms.ko-KR.md b/docs/docs/07-forms.ko-KR.md
index 1cb7a37b77..1187ddabd7 100644
--- a/docs/docs/07-forms.ko-KR.md
+++ b/docs/docs/07-forms.ko-KR.md
@@ -32,6 +32,7 @@ HTML에서는 `
```
diff --git a/docs/docs/08-working-with-the-browser.ko-KR.md b/docs/docs/08-working-with-the-browser.ko-KR.md
index cbbf88268b..9f69a9d761 100644
--- a/docs/docs/08-working-with-the-browser.ko-KR.md
+++ b/docs/docs/08-working-with-the-browser.ko-KR.md
@@ -83,7 +83,7 @@ React는 이 프로세스에 훅을 지정할 수 있는 생명주기 메소드
### Updating
* `componentWillReceiveProps(object nextProps)`는 마운트된 컴포넌트가 새로운 props을 받을 때 호출됩니다. 이 메소드는 `this.props`와 `nextProps`을 비교하여 `this.setState()`를 사용해 상태 변환을 수행하는데 사용되야 합니다.
-* `shouldComponentUpdate(object nextProps, object nextState): boolean`는 컴포넌트가 어떤 변경이 DOM의 업데이트를 보증하는지 결정해야 할 때 호출됩니다. 최적화하려면, React가 업데이트를 무시해야할 때 `this.props`와 `nextProps`를, `this.state`와 `nextState`를 비교해 false를 리턴하면 됩니다.
+* `shouldComponentUpdate(object nextProps, object nextState): boolean`는 컴포넌트가 어떤 변경이 DOM의 업데이트를 보증하는지 결정해야 할 때 호출됩니다. 최적화하려면, React가 업데이트를 무시해야할 때 `this.props`와 `nextProps`를, `this.state`와 `nextState`를 비교해 `false`를 리턴하면 됩니다.
* `componentWillUpdate(object nextProps, object nextState)`는 업데이트가 발생하기 직전에 호출됩니다. 이 시점에는 `this.setState()`를 호출할 수 없습니다.
* `componentDidUpdate(object prevProps, object prevState)`는 업데이트가 발생한 후 즉시 호출됩니다.
diff --git a/docs/docs/08.1-more-about-refs.ko-KR.md b/docs/docs/08.1-more-about-refs.ko-KR.md
index 2286588bc0..9877e3d974 100644
--- a/docs/docs/08.1-more-about-refs.ko-KR.md
+++ b/docs/docs/08.1-more-about-refs.ko-KR.md
@@ -48,7 +48,7 @@ render 메소드를 통해 UI 구조를 얻은 다음, 반환된 컴포넌트
이는 `render()`에서 반환된 무언가를 "계속 유지할 수" 없으며 아무런 의미도 없을 것이라는 뜻입니다.
```javascript
- // 반례: 이렇게 하면 안됩니다!
+ // 안티패턴: 이것은 동작하지 않습니다.
render: function() {
var myInput = ; // 여기서 메소드를 호출할 겁니다.
this.rememberThisInput = myInput; // 언젠가 미래의 특정 시점에 입력할 거에요! YAY!
@@ -61,7 +61,7 @@ render 메소드를 통해 UI 구조를 얻은 다음, 반환된 컴포넌트
}
```
-이 반례에서 ``은 단지 ``의 *서술*일 뿐입니다. 이 서술은 ``에 대한 *진짜* **지원 인스턴스(backing instance)**를 생성하는 데 사용됩니다.
+이 예제에서 ``은 단지 ``의 *서술*일 뿐입니다. 이 서술은 ``에 대한 *진짜* **지원 인스턴스(backing instance)**를 생성하는 데 사용됩니다.
자 그럼 어떻게 *진짜* input의 지원 인스턴스를 다룰까요?
@@ -130,7 +130,7 @@ React는 `render()`로 출력된 컴포넌트에 추가할 수 있는 아주 특
});
```
-이 예제에서 render 함수는 `` 인스턴스의 서술을 반환했지만, 진짜 인스턴스는 `this.refs.theInput`을 통해 접근할 수 있었습니다. render에서 `ref="theInput"`을 가진 컴포넌트가 반환된 동안, `this.refs.theInput`은 적절한 인스턴스에 접근합니다. 이는 ``처럼 DOM이 아닌 고수준의 컴포넌트에서도 동작합니다.
+이 예제에서 render 함수는 `` 인스턴스의 서술을 반환했지만, 진짜 인스턴스는 `this.refs.theInput`을 통해 접근할 수 있었습니다. `render`에서 `ref="theInput"`을 가진 컴포넌트가 반환된 동안, `this.refs.theInput`은 적절한 인스턴스에 접근합니다. 이는 ``처럼 DOM이 아닌 고수준의 컴포넌트에서도 동작합니다.
## 요약
diff --git a/docs/docs/10.1-animation.ko-KR.md b/docs/docs/10.1-animation.ko-KR.md
index d55a232212..205e5bab7d 100644
--- a/docs/docs/10.1-animation.ko-KR.md
+++ b/docs/docs/10.1-animation.ko-KR.md
@@ -64,11 +64,11 @@ var TodoList = React.createClass({
```css
.example-enter {
opacity: 0.01;
- transition: opacity .5s ease-in;
}
.example-enter.example-enter-active {
opacity: 1;
+ transition: opacity .5s ease-in;
}
```
@@ -77,11 +77,11 @@ var TodoList = React.createClass({
```css
.example-leave {
opacity: 1;
- transition: opacity .5s ease-in;
}
.example-leave.example-leave-active {
opacity: 0.01;
+ transition: opacity .5s ease-in;
}
```
diff --git a/docs/docs/10.2-form-input-binding-sugar.ko-KR.md b/docs/docs/10.2-form-input-binding-sugar.ko-KR.md
index adb92d3d37..b92e6657f5 100644
--- a/docs/docs/10.2-form-input-binding-sugar.ko-KR.md
+++ b/docs/docs/10.2-form-input-binding-sugar.ko-KR.md
@@ -22,7 +22,7 @@ React에서 이는 "change" 이벤트를 감시하고 데이터 소스(보통 DO
> 주의:
>
-> ReactLink는 얇은 레퍼고 `onChange`/`setState()`패턴 부분의 관례일 뿐입니다. React 애플리케이션에서의 데이터 흐름을 근본적으로 바꾸지는 않습니다.
+> `ReactLink`는 얇은 레퍼고 `onChange`/`setState()`패턴 부분의 관례일 뿐입니다. React 애플리케이션에서의 데이터 흐름을 근본적으로 바꾸지는 않습니다.
## ReactLink: 적용 전후
diff --git a/docs/docs/11-advanced-performance.ko-KR.md b/docs/docs/11-advanced-performance.ko-KR.md
index 97b42ee79d..91da92e625 100644
--- a/docs/docs/11-advanced-performance.ko-KR.md
+++ b/docs/docs/11-advanced-performance.ko-KR.md
@@ -131,13 +131,13 @@ React.createClass({
## 구원자 Immutable-js
-[Immutable-js](https://github.com/facebook/immutable-js)는 Lee Byron이 만들고 Facebook이 오픈소스화 한 Javascript 컬렉션 라이브러리입니다. 이는 *구조의 공유(structural sharing)*를 통해 *불변의 영속적인(immutable persistent)* 컬렉션을 제공합니다. 이러한 속성이 무엇을 의미하는지 살펴보죠:
+[Immutable-js](https://github.com/facebook/immutable-js)는 Lee Byron이 만들고 Facebook이 오픈소스화 한 JavaScript 컬렉션 라이브러리입니다. 이는 *구조의 공유(structural sharing)*를 통해 *불변의 영속적인(immutable persistent)* 컬렉션을 제공합니다. 이러한 속성이 무엇을 의미하는지 살펴보죠:
* *불변성(Immutable)*: 컬렉션이 한번 생성되면, 이 후 다른 시점에 변경될 수 없습니다.
* *영속성(Persistent)*: 새로운 컬렉션이 이전의 컬렉션이나 셋(set) 같은 뮤테이션(mutation)에서 생성될 수 있습니다. 기존의 컬렉션은 새로운 컬렉션이 생성된 후에도 여전히 유효합니다.
* *구조의 공유(Structural Sharing)*: 새로운 컬렉션은 가능한 한 원래의 컬렉션과 같은 구조를 사용해 생성됩니다. 공간 효율성과 적절한 성능을 위해 복사를 최소화합니다.
-불변성은 변경의 추적을 비용을 줄여줍니다; 변경은 항상 새로운 객체에만 발생하기 때문에 객체에 대한 참조가 변경될 때만 확인하면 됩니다. 예를 들어 일반적인 JavaScript 코드에서는:
+불변성은 변경의 추적을 비용을 줄여줍니다; 변경은 항상 새로운 객체에만 발생하기 때문에 객체에 대한 참조가 변경될 때만 확인하면 됩니다. 예를 들어 일반적인 이 JavaScript 코드에서는:
```javascript
var x = { foo: "bar" };
diff --git a/docs/docs/getting-started.ko-KR.md b/docs/docs/getting-started.ko-KR.md
index 3e6ed18c76..65562c7fc5 100644
--- a/docs/docs/getting-started.ko-KR.md
+++ b/docs/docs/getting-started.ko-KR.md
@@ -65,6 +65,8 @@ React.render(
```
+크롬 같은 몇몇 브라우저에서는 HTTP을 통해 제공되는 파일이 아니면 로드에 실패하므로 주의하세요.
+
### 오프라인 변환
먼저 커맨드라인 도구를 설치합니다. ([npm](https://www.npmjs.com/) 필요):
diff --git a/docs/docs/ref-02-component-api.ko-KR.md b/docs/docs/ref-02-component-api.ko-KR.md
index 83e1702c0d..209aede64d 100644
--- a/docs/docs/ref-02-component-api.ko-KR.md
+++ b/docs/docs/ref-02-component-api.ko-KR.md
@@ -67,11 +67,11 @@ replaceState(object nextState[, function callback])
forceUpdate([function callback])
```
-`render()` 메소드가 `this.props`나 `this.state`가 아닌 다른 곳에서 데이터를 읽어오는 경우 `forceUpdate()`를 호출하여 React가 `render()`를 다시 실행하도록 만들 수 있습니다. `this.state`를 직접 변경하는 경우에도 `forceUpdate()`를 호출해야 합니다.
+기본적으로, 컴포넌트의 state나 props가 변경되면, 컴포넌트는 다시 렌더됩니다. 하지만 이런 변경이 묵시적이거나(예를들어 객체의 변경 없이 깊이 있는 데이터만 변경된 경우) `render()` 함수가 다른 값에 의존하는 경우, `forceUpdate()`를 호출해 React에게 `render()`를 다시 실행할 필요가 있다고 알릴 수 있습니다.
`forceUpdate()`를 호출하면 `shouldComponentUpdate()`를 생략하고 해당 컴포넌트 `render()` 함수가 호출됩니다. 각 자식 컴포넌트에 대해서는 `shouldComponentUpdate()`를 포함해 보통 라이프 사이클 메서드를 호출합니다. React는 마크업이 변경된 경우에만 DOM을 업데이트합니다.
-특별한 경우가 아니면 `forceUpdate()`는 되도록 피하시고 `render()`에서는 `this.props`와 `this.state`에서만 읽어오세요. 그렇게 하는 것이 애플리케이션을 훨씬 단순하고 효율적으로 만들어줍니다.
+특별한 경우가 아니면 `forceUpdate()`는 되도록 피하시고 `render()`에서는 `this.props`와 `this.state`에서만 읽어오세요. 그렇게 하는 것이 컴포넌트를 "순수"하게 하고 애플리케이션을 훨씬 단순하고 효율적으로 만들어줍니다.
### getDOMNode
@@ -110,11 +110,11 @@ setProps(object nextProps[, function callback])
외부 JavaScript 애플리케이션과 연동하는 경우 `React.render()`로 렌더링된 React 컴포넌트에 변경을 알리고 싶을 때가 있습니다.
-최상위 컴포넌트를 업데이트할 때 `React.render()`를 같은 노드에 다시 호출하는 것이 바람직한 방법이지만, `setProps()`를 호출해서 props를 바꾸고 재렌더링을 발생시킬 수 있습니다. 콜백 함수를 추가로 넘기면 `setProps`가 완료되고 컴포넌트가 다시 렌더링된 다음에 한번 호출됩니다.
+최상위 컴포넌트에서 `setProps()`를 호출하면 프로퍼티를 변경하고 렌더를 다시 발생합니다. 거기에 콜백 함수를 넘기면 `setProps`가 완료되고 컴포넌트가 다시 렌더링된 다음에 한번 호출됩니다.
> 주의:
>
-> 가능하다면 `React.render()`를 다시 호출하는 선언적인 방법이 더 바람직합니다. 그렇게 하는 편이 업데이트에 대해 생각하는 것을 쉽게 만듭니다. (두가지 방식에 눈에 띄는 성능 차이는 없습니다.)
+> 가능하다면 이것 대신 `React.render()`를 같은 노드에서 다시 호출하는 선언적인 방법이 더 바람직합니다. 그렇게 하는 편이 업데이트에 대해 생각하는 것을 쉽게 만듭니다. (두가지 방식에 눈에 띄는 성능 차이는 없습니다.)
>
> 이 메소드는 최상위 컴포넌트에만 호출 가능합니다. 다시 말해, `React.render()`에 바로 넘긴 컴포넌트에서만 사용할 수 있고 자식에서는 불가능합니다. 자식 컴포넌트에 `setProps()`를 사용하고 싶다면, 그 대신 반응적인 업데이트의 장점을 활용하여 `render()` 안에서 자식 컴포넌트를 만들 때 새로운 prop을 넘기세요.
>
diff --git a/docs/docs/tutorial.ko-KR.md b/docs/docs/tutorial.ko-KR.md
index ba940240f5..9698439572 100644
--- a/docs/docs/tutorial.ko-KR.md
+++ b/docs/docs/tutorial.ko-KR.md
@@ -54,7 +54,7 @@ next: thinking-in-react-ko-KR.html