Fix some typos and translate more files

README-ko.md

@@ -33,7 +33,7 @@ npm install electron-prebuilt --save-dev
 
 ## 참조문서
 
-[docs](https://github.com/preco21/electron/tree/master/docs) 에 프레임워크 사용 가이드와 API 레퍼런스가 있습니다.
+[docs](https://github.com/atom/electron/tree/master/docs/README-ko.md) 에 프레임워크 사용 가이드와 API 레퍼런스가 있습니다.
 또한, Electron을 빌드 하는 방법과 프로젝트에 기여하는 방법 문서에 포함되어 있으니 참고바랍니다.
 
 ## 커뮤니티

docs/README-ko.md

@@ -58,7 +58,7 @@
 ## 개발자용
 
 * [코딩 스타일](development/coding-style-ko.md)
-* [소스코드 구조](development/source-code-directory-structure-ko.md)
+* [소스 코드 디렉터리 구조](development/source-code-directory-structure-ko.md)
 * [NW.js와 기술적으로 다른점 (이전 node-webkit)](development/atom-shell-vs-node-webkit-ko.md)
 * [빌드 시스템 개요](development/build-system-overview-ko.md)
 * [빌드 설명서 (Mac)](development/build-instructions-mac-ko.md)
@@ -66,4 +66,4 @@
 * [빌드 설명서 (Linux)](development/build-instructions-linux-ko.md)
 * [디버거에서 디버그 심볼 서버 설정](development/setting-up-symbol-server-ko.md)
 
-이 문서는 (@preco21)[https://github.com/preco21]이 번역하였습니다.
+이 문서는 [@preco21](https://github.com/preco21) 이 번역하였습니다.

docs/development/atom-shell-vs-node-webkit-ko.md

@@ -0,0 +1,49 @@
+# NW.js와 기술적으로 다른점 (이전 node-webkit)
+
+__알림: Electron은 이전까지 Atom Shell로 불려졌습니다.__
+
+Like NW.js, Electron provides a platform to write desktop applications
+with JavaScript and HTML and has Node integration to grant access to low level
+system in web pages.
+
+But there are also fundamental differences between the two projects that make
+Electron a completely separate product from NW.js:
+
+__1. 어플리케이션의 엔트리 포인트__
+
+In NW.js, the main entry of an application is a web page. You specify a
+main page in the `package.json` and it is opened in a browser window as
+the application's main window.
+
+In Electron, the entry point is a JavaScript script. Instead of
+providing a URL directly, you manually create a browser window and load
+an HTML file using the API. You also need to listen to window events
+to decide when to quit the application.
+
+Electron works more like the Node.js runtime. Electron's APIs are lower level
+so you can use it for browser testing in place of [PhantomJS](http://phantomjs.org/).
+
+__2. 빌드 시스템__
+
+In order to avoid the complexity of building the whole Chromium, Electron uses
+[libchromiumcontent](https://github.com/brightray/libchromiumcontent) to access
+Chromium's Content API. libchromiumcontent is a single, shared library that
+includes the Chromium Content module and all its dependencies. Users don't
+need a powerful machine to build Electron.
+
+__3. Node 통합__
+
+In NW.js, the Node integration in web pages requires patching Chromium to
+work, while in Electron we chose a different way to integrate libuv loop with
+each platform's message loop to avoid hacking Chromium. See the
+[`node_bindings`](../../atom/common/) code for how that was done.
+
+__4. 다중 컨텍스트__
+
+If you are an experienced NW.js user, you should be familiar with the
+concept of Node context and web context. These concepts were invented because
+of how NW.js was implemented.
+
+By using the [multi-context](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)
+feature of Node, Electron doesn't introduce a new JavaScript context in web
+pages.

docs/development/build-instructions-linux-ko.md

@@ -0,0 +1,100 @@
+# 빌드 설명서 (Linux)
+
+## 빌드전 요구사양
+
+* Python 2.7.x. Some distributions like CentOS still use Python 2.6.x
+so you may need to check your Python version with `python -V`.
+* Node.js v0.12.x. There are various ways to install Node. One can download 
+source code from [Node.js] (http://nodejs.org) and compile from source. 
+Doing so permits installing Node to your own home directory as a standard user.  
+Or try repositories such as [NodeSource] (https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories)
+* Clang 3.4 or later
+* Development headers of GTK+ and libnotify
+
+On Ubuntu, install the following libraries:
+
+```bash
+$ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
+                       libnotify-dev libgnome-keyring-dev libgconf2-dev \
+                       libasound2-dev libcap-dev libcups2-dev libxtst-dev \
+                       libxss1 gcc-multilib g++-multilib
+```
+
+Other distributions may offer similar packages for installation via package 
+managers such as yum. Or one can compile from source code.
+
+
+## 가상머신을 사용하여 빌드 하는 경우
+
+If you plan to build electron on a virtual machine, you will need a fixed-size
+device container of at least 25 gigabytes in size. 
+
+
+## 코드 가져오기
+
+```bash
+$ git clone https://github.com/atom/electron.git
+```
+
+## 부트 스트랩
+
+The bootstrap script will download all necessary build dependencies and create
+build project files. You must have Python 2.7.x for the script to succeed. 
+Downloading certain files could take a long time. Notice that we are using 
+`ninja` to build Electron so there is no `Makefile` generated.
+
+```bash
+$ cd electron
+$ ./script/bootstrap.py -v
+```
+
+## 빌드 하기
+
+If you would like to build both `Release` and `Debug` targets:
+
+```bash
+$ ./script/build.py
+```
+
+This script will cause a very large Electron executable to be placed in
+the directory `out/R`. The file size is in excess of 1.3 gigabytes. This 
+happens because the Release target binary contains debugging symbols. 
+To reduce the file size, run the `create-dist.py` script:
+
+```bash
+$ ./script/create-dist.py
+```
+
+This will put a working distribution with much smaller file sizes in 
+the `dist` directory. After running the create-dist.py script, you 
+may want to remove the 1.3+ gigabyte binary which is still in out/R.
+
+You can also build the `Debug` target only:
+
+```bash
+$ ./script/build.py -c D
+```
+
+After building is done, you can find the `electron` debug binary 
+under `out/D`.
+
+
+## 정리 하기
+
+
+To clean the build files:
+
+```bash
+$ ./script/clean.py
+```
+
+
+## 문제 해결
+
+Make sure you have installed all the build dependencies. 
+
+## 테스트
+
+```bash
+$ ./script/test.py
+```

docs/development/build-instructions-mac-ko.md

@@ -0,0 +1,56 @@
+# 빌드 설명서 (Mac)
+
+## 빌드전 요구 사항
+
+* OS X >= 10.8
+* [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
+* [node.js](http://nodejs.org) (external).
+
+If you are using the python downloaded by Homebrew, you also need to install
+following python modules:
+
+* pyobjc
+
+## 코드 가져오기
+
+```bash
+$ git clone https://github.com/atom/electron.git
+```
+
+## 부트 스트랩
+
+The bootstrap script will download all necessary build dependencies and create
+build project files. Notice that we're using `ninja` to build Electron so
+there is no Xcode project generated.
+
+```bash
+$ cd electron
+$ ./script/bootstrap.py -v
+```
+
+## 빌드 하기
+
+Build both `Release` and `Debug` targets:
+
+```bash
+$ ./script/build.py
+```
+
+You can also only build the `Debug` target:
+
+```bash
+$ ./script/build.py -c D
+```
+
+After building is done, you can find `Electron.app` under `out/D`.
+
+## 32비트 지원
+
+Electron can only be built for 64bit target on OS X, and there is no plan to
+support 32bit OS X in future.
+
+## 테스트
+
+```bash
+$ ./script/test.py
+```

docs/development/build-instructions-windows-ko.md

@@ -0,0 +1,128 @@
+# 빌드 설명서 (Windows)
+
+## 빌드전 요구 사항
+
+* Windows 7 / Server 2008 R2 or higher
+* Visual Studio 2013 - [download VS 2013 Community Edition for
+  free](http://www.visualstudio.com/products/visual-studio-community-vs)
+* [Python 2.7](http://www.python.org/download/releases/2.7/)
+* [Node.js](http://nodejs.org/download/)
+* [git](http://git-scm.com)
+
+If you don't have a Windows installation at the moment,
+[modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads) has
+timebombed versions of Windows that you can use to build Electron.
+
+The building of Electron is done entirely with command-line scripts, so you
+can use any editor you like to develop Electron, but it also means you can
+not use Visual Studio for the development. Support of building with Visual
+Studio will come in the future.
+
+**Note:** Even though Visual Studio is not used for building, it's still
+**required** because we need the build toolchains it provided.
+
+## 코드 가져오기
+
+```powershell
+git clone https://github.com/atom/electron.git
+```
+
+## 부트 스트랩
+
+The bootstrap script will download all necessary build dependencies and create
+build project files. Notice that we're using `ninja` to build Electron so
+there is no Visual Studio project generated.
+
+```powershell
+cd electron
+python script\bootstrap.py -v
+```
+
+## 빌드 하기
+
+Build both Release and Debug targets:
+
+```powershell
+python script\build.py
+```
+
+You can also only build the Debug target:
+
+```powershell
+python script\build.py -c D
+```
+
+After building is done, you can find `atom.exe` under `out\D`.
+
+## 64비트 빌드
+
+To build for the 64bit target, you need to pass `--target_arch=x64` when running
+the bootstrap script:
+
+```powershell
+python script\bootstrap.py -v --target_arch=x64
+```
+
+The other building steps are exactly the same.
+
+## 테스트
+
+```powershell
+python script\test.py
+```
+
+## 문제 해결
+
+### Command xxxx not found
+
+If you encountered an error like `Command xxxx not found`, you may try to use
+the `VS2012 Command Prompt` console to execute the build scripts.
+
+### Fatal internal compiler error: C1001
+
+Make sure you have the latest Visual Studio update installed.
+
+### Assertion failed: ((handle))->activecnt >= 0
+
+If building under Cygwin, you may see `bootstrap.py` failed with following
+error:
+
+```
+Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430
+
+Traceback (most recent call last):
+  File "script/bootstrap.py", line 87, in <module>
+    sys.exit(main())
+  File "script/bootstrap.py", line 22, in main
+    update_node_modules('.')
+  File "script/bootstrap.py", line 56, in update_node_modules
+    execute([NPM, 'install'])
+  File "/home/zcbenz/codes/raven/script/lib/util.py", line 118, in execute
+    raise e
+subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
+```
+
+This is caused by a bug when using Cygwin python and Win32 node together. The
+solution is to use the Win32 python to execute the bootstrap script (supposing
+you have installed python under `C:\Python27`):
+
+```bash
+/cygdrive/c/Python27/python.exe script/bootstrap.py
+```
+
+### LNK1181: cannot open input file 'kernel32.lib'
+
+Try reinstalling 32bit node.js.
+
+### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
+
+Simply making that directory [should fix the problem](http://stackoverflow.com/a/25095327/102704):
+
+```powershell
+mkdir ~\AppData\Roaming\npm
+```
+
+### node-gyp is not recognized as an internal or external command
+
+You may get this error if you are using Git Bash for building, you should use
+PowerShell or VS2012 Command Prompt instead.

docs/development/build-system-overview-ko.md

@@ -0,0 +1,64 @@
+# 빌드 시스템 개요
+
+Electron uses `gyp` for project generation, and `ninja` for building, project
+configurations can be found in `.gyp` and `.gypi` files.
+
+## Gyp 파일들
+
+Following `gyp` files contain the main rules of building Electron:
+
+* `atom.gyp` defines how Electron itself is built.
+* `common.gypi` adjusts the build configurations of Node to make it build
+  together with Chromium.
+* `vendor/brightray/brightray.gyp` defines how `brightray` is built, and
+  includes the default configurations of linking with Chromium.
+* `vendor/brightray/brightray.gypi` includes general build configurations about
+  building.
+
+## 구성요소 빌드
+
+Since Chromium is quite a large project, the final linking stage would take
+quite a few minutes, making it hard for development. In order to solve this,
+Chromium introduced the "component build", which builds each component as a
+separate shared library, making linking very quick but sacrificing file size
+and performance.
+
+In Electron we took a very similar approach: for `Debug` builds, the binary
+will be linked to shared library version of Chromium's components to achieve
+fast linking time; for `Release` builds, the binary will be linked to the static
+library versions, so we can have the best possible binary size and performance.
+
+## 부트스트랩 최소화
+
+All of Chromium's prebuilt binaries are downloaded when running the bootstrap
+script. By default both static libraries and shared libraries will be
+downloaded and the final size should be between 800MB and 2GB according to the
+platform.
+
+If you only want to build Electron quickly for testing or development, you
+can only download the shared library versions by passing the `--dev` parameter:
+
+```bash
+$ ./script/bootstrap.py --dev
+$ ./script/build.py -c D
+```
+
+## Two-phrase 프로젝트 생성
+
+Electron links with different sets of libraries in `Release` and `Debug`
+builds, however `gyp` doesn't support configuring different link settings for
+different configurations.
+
+To work around this Electron uses a `gyp` variable
+`libchromiumcontent_component` to control which link settings to use, and only
+generates one target when running `gyp`.
+
+## 타겟 이름
+
+Unlike most projects that use `Release` and `Debug` as target names, Electron
+uses `R` and `D` instead. This is because `gyp` randomly crashes if there is
+only one `Release` or `Debug` build configuration is defined, and Electron has
+to only generate one target for one time as stated above.
+
+This only affects developers, if you are only building Electron for rebranding
+you are not affected.

docs/development/coding-style-ko.md

@@ -4,7 +4,6 @@
 
 C++과 Python스크립트는 Chromium의 [코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다.
 파이선 스크립트 `script/cpplint.py`를 사용하여 모든 파일이 해당 코딩스타일에 맞게 코딩 되었는지 확인할 수 있습니다.
-
 파이선의 버전은 2.7을 사용합니다.
 
 ## CoffeeScript

docs/development/setting-up-symbol-server-ko.md

@@ -0,0 +1,56 @@
+# 디버거에서 디버그 심볼 서버 설정
+
+Debug symbols allow you to have better debugging sessions. They have information
+about the functions contained in executables and dynamic libraries and provide
+you with information to get clean call stacks. A Symbol Server allows the
+debugger to load the correct symbols, binaries and sources automatically without
+forcing users to download large debugging files. The server functions like
+[Microsoft's symbol server](http://support.microsoft.com/kb/311503) so the
+documentation there can be useful.
+
+Note that because released Electron builds are heavily optimized, debugging is
+not always easy. The debugger will not be able to show you the content of all
+variables and the execution path can seem strange because of inlining, tail
+calls, and other compiler optimizations. The only workaround is to build an
+unoptimized local build.
+
+The official symbol server URL for Electron is
+http://54.249.141.255:8086/atom-shell/symbols.
+You cannot visit this URL directly: you must add it to the symbol path of your
+debugging tool. In the examples below, a local cache directory is used to avoid
+repeatedly fetching the PDB from the server.  Replace `c:\code\symbols` with an
+appropriate cache directory on your machine.
+
+## Windbg에서 심볼 서버 사용하기
+
+The Windbg symbol path is configured with a string value delimited with asterisk
+characters. To use only the Electron symbol server, add the following entry to
+your symbol path (__note:__ you can replace `c:\code\symbols` with any writable
+directory on your computer, if you'd prefer a different location for downloaded
+symbols):
+
+```
+SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
+```
+
+Set this string as `_NT_SYMBOL_PATH` in the environment, using the Windbg menus,
+or by typing the `.sympath` command. If you would like to get symbols from
+Microsoft's symbol server as well, you should list that first:
+
+```
+SRV*c:\code\symbols\*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
+```
+
+## Using the symbol server in Visual Studio
+
+<img src='http://mdn.mozillademos.org/files/733/symbol-server-vc8express-menu.jpg'>
+<img src='http://mdn.mozillademos.org/files/2497/2005_options.gif'>
+
+## 문제 해결: Symbols will not load
+
+Type the following commands in Windbg to print why symbols are not loading:
+
+```
+> !sym noisy
+> .reload /f chromiumcontent.dll
+```

docs/development/source-code-directory-structure-ko.md

@@ -0,0 +1,48 @@
+# 소스 코드 디렉터리 구조
+
+## 개요
+
+Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우리는 Chromium의 분리 규칙(separation conventions)을 주로 따르고 있습니다.
+
+이미 [Chromium의 멀티 프로세스 아키텍쳐](http://dev.chromium.org/developers/design-documents/multi-process-architecture)에 익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다.
+
+## 소스 코드 구조
+
+* **atom** - Electron의 소스코드.
+  * **app** - 시스템 엔트리 코드.
+  * **browser** - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들. 주 랜더러와 웹 페이지 관리관련 코드.
+    * **lib** - 메인 프로세스 초기화 코드의 자바스크립트 파트.
+    * **ui** - 크로스 플랫폼에 대응하는 UI 구현.
+      * **cocoa** - 코코아 특정 소스 코드.
+      * **gtk** - GTK+ 특정 소스 코드.
+      * **win** - Windows GUI 특정 소스 코드.
+    * **default_app** - 어플리케이션이 제공되지 않으면 기본적으로 사용될 페이지.
+    * **api** - 메인 프로세스 API들의 구현.
+       * **lib** -  API 구현의 자바스크립트 파트.
+    * **net** - 네트워크 관련 코드.
+    * **mac** - Mac 특정 Objective-C 소스 코드.
+    * **resources** - 아이콘들, 플랫폼 종속성 파일들, 기타 등등.
+  * **renderer** - 렌더러 프로세스에서 작동하는 코드들.
+    * **lib** - 렌더러 프로세스 초기화 코드의 자바스크립트 파트.
+    * **api** - 렌더러 프로세스 API들의 구현.
+       * **lib** - API 구현의 자바스크립트 파트.
+  * **common** - 메인 프로세스와 렌더러 프로세스에서 공유하는 코드. 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드가 포함.
+    * **lib** - 공통 자바스크립트 초기화 코드.
+    * **api** - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들.
+       * **lib** - API 구현의 자바스크립트 파트.
+* **chromium_src** - 복사된 Chromium 소스 코드.
+* **docs** - 참조 문서.
+* **spec** - 자동화된 테스트.
+* **atom.gyp** - Electron의 빌드 규칙.
+* **common.gypi** - 컴파일러 설정 및 `node` 와 `breakpad` 등의 구성요소를 위한 빌드 규칙.
+
+## 그외 디렉터리 구조
+
+* **script** - 개발목적으로 사용되는 빌드, 패키징, 테스트, 기타등을 실행하는 스크립트.
+* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트, `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
+* **vendor** - 소스코드의 서드파티 종속성 코드, 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에,
+  우리는 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더 이름을 사용하지 않았습니다.
+* **node_modules** - 빌드에 사용되는 node 서드파티 모듈.
+* **out** - `ninja`의 임시 출력 디렉터리.
+* **dist** - 배포용 바이너리를 빌드할 때 사용하는 `script/create-dist.py` 스크립트로부터 만들어지는 임시 디렉터리.
+* **external_binaries** - `gyp`를 통한 빌드가 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들.

docs/tutorial/application-distribution-ko.md

@@ -1,4 +1,4 @@
-# 어플리케이션 배포
+# 어플리케이션 배포
 
 Electron 어플리케이션을 배포할 때는 어플리케이션 폴더의 이름을 `app`으로 지정한 후 Electron 실행파일의 리소스 디렉터리에 집어넣어야합니다.
 리소스 디렉터리는 OS X에선 `Electron.app/Contents/Resources/` Windows와 Linux에선 `resources/` 입니다.
@@ -48,7 +48,7 @@ electron/resources/
 └── app.asar
 ```
 
-자세한 내용은 [어플리케이션 패키징](application-packaging.md)에서 찾아볼 수 있습니다.
+자세한 내용은 [어플리케이션 패키징](application-packaging-ko.md)에서 찾아볼 수 있습니다.
 
 ## 다운로드한 바이너리의 리소스를 앱에 맞게 수정하기
 
@@ -97,11 +97,11 @@ MyApp.app/Contents
 ### Linux
 
 실행파일 `electron`의 이름을 원하는 대로 바꿀 수 있습니다.
-리눅스 어플리케이션의 아이콘은 [.desktop file](https://developer.gnome.org/integration-guide/stable/desktop-files.html.en)을 사용하여 지정할 수 있습니다.
+리눅스 어플리케이션의 아이콘은 [.desktop](https://developer.gnome.org/integration-guide/stable/desktop-files.html.en) 파일을 사용하여 지정할 수 있습니다.
 
 ### 역자주-자동화 
 
-일일이 Electron의 리소스를 수정하는 것은 상당히 귀찮고 복잡합니다.
+배포시에 Electron의 리소스를 일일이 수정하는 것은 매우 귀찮고 복잡합니다.
 하지만 이 작업을 자동화 시킬 수 있는 몇가지 방법이 있습니다: 
 
 * [electron-builder](https://github.com/loopline-systems/electron-builder)
@@ -135,4 +135,4 @@ $ script/build.py -c Release -t myapp
 Electron의 소스코드를 수정하고 다시 빌드하는 작업은 상당히 복잡합니다.
 이를 해결하기 위해 [grunt-build-atom-shell](https://github.com/paulcbetts/grunt-build-atom-shell)를 사용하여 빌드를 자동화 시킬 수 있습니다.
 
-이 툴을 사용하면 자동적으로 `.gyp`파일을 수정하고 다시 빌드합니다. 그리고 어플리케이션의 네이티브 Node 모듈 또한 새로운 실행파일 이름으로 매치 시킵니다.
+이 툴을 사용하면 자동으로 `.gyp`파일을 수정하고 다시 빌드합니다. 그리고 어플리케이션의 네이티브 Node 모듈 또한 새로운 실행파일 이름으로 매치 시킵니다.

docs/tutorial/application-packaging-ko.md

@@ -1,37 +1,37 @@
-# 어플리케이션 패키징
+# 어플리케이션 패키징
 
-어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해, 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
+어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해, 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
 
-## `asar` 아카이브 생성
+## `asar` 아카이브 생성
 
-[asar][asar]아카이브는 tar과 비슷한 포맷으로 모든 리소스를 하나의 파일로 만듭니다.
+[asar][asar]아카이브는 tar과 비슷한 포맷으로 모든 리소스를 하나의 파일로 만듭니다.
-그리고 Electron은 압축해제 없이 임의로 모든 파일을 읽어들일 수 있습니다.
+그리고 Electron은 압축해제 없이 임의로 모든 파일을 읽어들일 수 있습니다.
 
-다음 몇가지 단계를 통해 어플리케이션을 `asar` 아카이브로 압축할 수 있습니다:
+다음 몇가지 단계를 통해 어플리케이션을 `asar` 아카이브로 압축할 수 있습니다:
 
-### 1. asar 유틸리티 설치
+### 1. asar 유틸리티 설치
 
 ```bash
 $ npm install -g asar
 ```
 
-### 2. `asar pack` 커맨드로 앱 패키징
+### 2. `asar pack` 커맨드로 앱 패키징
 
 ```bash
 $ asar pack your-app app.asar
 ```
 
-## `asar` 아카이브 사용하기
+## `asar` 아카이브 사용하기
 
-Electron은 두가지의 API를 가지고 있습니다: Node.js로 부터 제공된 Node API, Chromium으로부터 제공된 Web API.
+Electron은 두가지의 API를 가지고 있습니다: Node.js로 부터 제공된 Node API, Chromium으로부터 제공된 Web API.
-두 API 모두 `asar`에서 읽어들일 수 있도록 지원합니다.
+두 API 모두 `asar`에서 읽어들일 수 있도록 지원합니다.
 
 ### Node API
 
-`fs.readFile` 와 `require` 같은 Node API들을 지원하기 위해 Electron에선 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록
+`fs.readFile` 와 `require` 같은 Node API들을 지원하기 위해 Electron에선 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록
-패치했습니다. 그래서 아카이브 내부에서 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
+패치했습니다. 그래서 아카이브 내부에서 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
 
-예를들어, `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
+예를들어, `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
 
 ```bash
 $ asar list /path/to/example.asar
@@ -43,27 +43,27 @@ $ asar list /path/to/example.asar
 /static/jquery.min.js
 ```
 
-`asar` 아카이브에선 다음과 같이 파일을 읽을 수 있습니다:
+`asar` 아카이브에선 다음과 같이 파일을 읽을 수 있습니다:
 
 ```javascript
 var fs = require('fs');
 fs.readFileSync('/path/to/example.asar/file.txt');
 ```
 
-아카이브 내의 루트 디렉터리를 리스팅합니다:
+아카이브 내의 루트 디렉터리를 리스팅합니다:
 
 ```javascript
 var fs = require('fs');
 fs.readdirSync('/path/to/example.asar');
 ```
 
-아카이브 안의 모듈 사용하기:
+아카이브 안의 모듈 사용하기:
 
 ```javascript
 require('/path/to/example.asar/dir/module.js');
 ```
 
-`BrowserWindow` 클래스를 이용해 원하는 웹 페이지도 표시할 수 있습니다:
+`BrowserWindow` 클래스를 이용해 원하는 웹 페이지도 표시할 수 있습니다:
 
 ```javascript
 var BrowserWindow = require('browser-window');
@@ -73,10 +73,10 @@ win.loadUrl('file:///path/to/example.asar/static/index.html');
 
 ### Web API
 
-웹 페이지 내에선, 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
+웹 페이지 내에선, 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
-이 또한 Node API와 같이 가상 디렉터리 구조를 가집니다.
+이 또한 Node API와 같이 가상 디렉터리 구조를 가집니다.
 
-예를들어, jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
+예를들어, jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
 
 ```html
 <script>
@@ -87,67 +87,67 @@ $.get('file:///path/to/example.asar/file.txt', function(data) {
 </script>
 ```
 
-### `asar` 아카이브를 일반 파일로 취급하기
+### `asar` 아카이브를 일반 파일로 취급하기
 
-`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선, `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
+`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선, `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
-이 작업을 하기 위해 `original-fs`라고 하는 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다.
+이 작업을 하기 위해 `original-fs`라고 하는 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다.
-이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다: 
+이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다: 
 
 ```javascript
 var originalFs = require('original-fs');
 originalFs.readFileSync('/path/to/example.asar');
 ```
 
-## Node API의 한계
+## Node API의 한계
 
-`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만, 여전히 저수준(low-level) Node API 때문에 한계가 있습니다.
+`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만, 여전히 저수준(low-level) Node API 때문에 한계가 있습니다.
 
 Even though we tried hard to make `asar` archives in the Node API work like
 directories as much as possible, there are still limitations due to the
 low-level nature of the Node API.
 
-### 아카이브는 읽기 전용입니다
+### 아카이브는 읽기 전용입니다
 
-아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만, `asar` 아카이브에선 작동하지 않습니다.
+아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만, `asar` 아카이브에선 작동하지 않습니다.
 
-### 아카이브 안의 디렉터리를 작업 경로로 설정하면 안됩니다
+### 아카이브 안의 디렉터리를 작업 경로로 설정하면 안됩니다
 
-`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만, 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
+`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만, 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
-그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을 `asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
+그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을 `asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
 
-### 특정 API로 인한 예외적인 압축 해제
+### 특정 API로 인한 예외적인 압축 해제
 
-많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나, 
+많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나, 
-몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 이 API들을 사용할 땐 Electron은
+몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 이 API들을 사용할 땐 Electron은
-이 API가 원할하게 작동할 수 있도록 하기 위해 임시경로에 해당 파일들의 압축을 해제합니다. 이 작업은 약간의 오버헤드를 불러 일으킬 수 있습니다.
+이 API가 원할하게 작동할 수 있도록 하기 위해 임시경로에 해당 파일들의 압축을 해제합니다. 이 작업은 약간의 오버헤드를 불러 일으킬 수 있습니다.
 
-해당하는 API 함수는 다음과 같습니다:
+해당하는 API 함수는 다음과 같습니다:
 
 * `child_process.execFile`
 * `fs.open`
 * `fs.openSync`
 * `process.dlopen` - Used by `require` on native modules
 
-### `fs.stat`의 잘못된 스테이터스
+### `fs.stat`의 잘못된 스테이터스
 
-`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 가상의 예측된 정보를 가집니다.
+`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 가상의 예측된 정보를 가집니다.
-왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다.
+왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다.
-그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
+그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
 
 ## Adding unpacked files in `asar` archive
 
-전술한 바와 같이, 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
+전술한 바와 같이, 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
-따로 성능문제가 발생할 수 있습니다. 그리고 백신 소프트웨어의 잘못된 오진을 일으킬 수도 있습니다.
+따로 성능문제가 발생할 수 있습니다. 그리고 백신 소프트웨어의 잘못된 오진을 일으킬 수도 있습니다.
 
-이 문제를 해결하려면, `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
+이 문제를 해결하려면, `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
-다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다:
+다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다:
 
 ```bash
 $ asar pack app app.asar --unpack *.node
 ```
 
-커맨드를 실행한 후, 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가 같이 생성됩니다.
+커맨드를 실행한 후, 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가 같이 생성됩니다.
-이 폴더안에 unpack 옵션에서 설정한 파일들이 압축이 풀린 상태로 포함되어 있습니다.
+이 폴더안에 unpack 옵션에서 설정한 파일들이 압축이 풀린 상태로 포함되어 있습니다.
-유저에게 어플리케이션을 배포할 때 반드시 해당 폴더도 같이 배포하여야합니다.
+유저에게 어플리케이션을 배포할 때 반드시 해당 폴더도 같이 배포하여야합니다.
 
 [asar]: https://github.com/atom/asar

docs/tutorial/desktop-environment-integration-ko.md

@@ -1,36 +1,30 @@
 # 데스크톱 환경 통합
 
-Different operating systems provide different features on integrating desktop
+어플리케이션을 배포할 서로 다른 운영체제 시스템의 환경과 기능에 맞춰 사용 환경을 통합할 수 있습니다.
-applications into their desktop environments. For example, on Windows
+예를 들어, Windows에선 태스크바의 JumpList에 바로가기를 추가할 수 있고, Mac(OS X)에선 dock menu에 커스텀 메뉴를 추가할 수 있습니다.
-applications can put shortcuts in the JumpList of task bar, and on Mac
-applications can put a custom menu in the dock menu.
 
-This guide explains how to integrate your application into those desktop
+이 가이드는 Electron API를 이용하여 각 운영체제 시스템의 기능을 활용하는 방법을 설명합니다.
-environments with Electron APIs.
 
 ## 최근 사용한 문서 (Windows & OS X)
 
-Windows and OS X provide easy access to a list of recent documents opened by
+Windows와 OS X는 dock menu나 JumpList등을 통하여 최근 문서 리스트에 쉽게 접근할 수 있습니다.
-the application via JumpList and dock menu.
 
 __JumpList:__
 
-![JumpList Recent Files](http://i.msdn.microsoft.com/dynimg/IC420538.png)
+![JumpList 최근 문서](http://i.msdn.microsoft.com/dynimg/IC420538.png)
 
-__Application dock menu:__
+__어플리케이션 dock menu:__
 
 <img src="https://cloud.githubusercontent.com/assets/639601/5069610/2aa80758-6e97-11e4-8cfb-c1a414a10774.png" height="353" width="428" >
 
-To add a file to recent documents, you can use
+파일을 최근 문서에 추가하려면, [app.addRecentDocument][addrecentdocument] API를 사용할 수 있습니다:
-[app.addRecentDocument][addrecentdocument] API:
 
 ```javascript
 var app = require('app');
 app.addRecentDocument('/Users/USERNAME/Desktop/work.type');
 ```
 
-And you can use [app.clearRecentDocuments](clearrecentdocuments) API to empty
+그리고 [app.clearRecentDocuments](clearrecentdocuments) API로 최근 문서 리스트를 비울 수 있습니다:
-the recent documents list:
 
 ```javascript
 app.clearRecentDocuments();
@@ -38,30 +32,26 @@ app.clearRecentDocuments();
 
 ### Windows에서 주의할 점
 
-In order to be able to use this feature on Windows, your application has to be
+이 기능을 Windows에서 사용할 땐, 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다.
-registered as a handler of the file type of the document, otherwise the file
+그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지 않습니다.
-won't appear in JumpList even after you have added it. You can find everything
+어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서 찾아볼 수 있습니다.
-on registering your application in [Application Registration][app-registration].
 
-When a user clicks a file from JumpList, a new instance of your application will
+유저가 JumpList에서 파일을 클릭할 경우, 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다.
-be started with the path of the file added as a command line argument.
 
 ### OS X에서 주의할 점
 
-When a file is requested from the recent documents menu, the `open-file` event
+파일이 최근 문서 메뉴에서 요청될 경우, `app` 모듈의 `open-file` 이벤트가 호출됩니다.
-of `app` module would be emitted for it.
 
 ## 커스텀 독 메뉴 (OS X)
 
-OS X enables developers to specify a custom menu for the dock, which usually
+OS X는 개발자가 dock에 커스텀 메뉴를 만들 수 있도록 허용하고 있습니다.
-contains some shortcuts for commonly used features of your application:
+보통 어플리케이션의 특정 기능 바로가기를 만들 때 사용합니다:
 
-__Dock menu of Terminal.app:__
+__Terminal.app의 dock menu:__
 
 <img src="https://cloud.githubusercontent.com/assets/639601/5069962/6032658a-6e9c-11e4-9953-aa84006bdfff.png" height="354" width="341" >
 
-To set your custom dock menu, you can use the `app.dock.setMenu` API, which is
+커스텀 dock menu를 설정하려면, `app.dock.setMenu` API를 사용하면 됩니다. OS X에서만 사용 가능합니다:
-only available on OS X:
 
 ```javascript
 var app = require('app');
@@ -79,36 +69,29 @@ app.dock.setMenu(dockMenu);
 
 ## 사용자 작업 (Windows)
 
-On Windows you can specify custom actions in the `Tasks` category of JumpList,
+Windows에선 JumpList의 `Tasks` 카테고리에 원하는 작업을 설정할 수 있습니다.
-as quoted from MSDN:
+MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
 
-> Applications define tasks based on both the program's features and the key
+> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 예측하여 정의합니다.
-> things a user is expected to do with them. Tasks should be context-free, in
+> 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 context-free를 유지해야 합니다.
-> that the application does not need to be running for them to work. They
+> 작업은 일반 사용자가 프로그램을 실행하거나, 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고,
-> should also be the statistically most common actions that a normal user would
+> 워드 프로세서로 새 문서를 작성, 특정 모드, 부속 명령으로 프로그램을 실행하는 등의
-> perform in an application, such as compose an email message or open the
+> 통계적, 일반적으로 가장 많이 사용되는 작업인지를 고려해야 합니다.
-> calendar in a mail program, create a new document in a word processor, launch
+> 어플리케이션 작업은 일반 유저가 필요로 하지 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
-> an application in a certain mode, or launch one of its subcommands. An
+> 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다.
-> application should not clutter the menu with advanced features that standard
-> users won't need or one-time actions such as registration. Do not use tasks
-> for promotional items such as upgrades or special offers.
 >
-> It is strongly recommended that the task list be static. It should remain the
+> 작업 리스트는 가능한 한 정적으로 유지되는 것을 적극 권장합니다.
-> same regardless of the state or status of the application. While it is
+> 이것은 동일한 상태 또는 응용 프로그램의 상태에 관계없이 유지되어야 합니다.
-> possible to vary the list dynamically, you should consider that this could
+> 작업 목록은 동적으로 변경할 수 있지만, 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
-> confuse the user who does not expect that portion of the destination list to
-> change.
 
-__Tasks of Internet Explorer:__
+__Internet Explorer의 작업:__
 
 ![IE](http://i.msdn.microsoft.com/dynimg/IC420539.png)
 
-Unlike the dock menu in OS X which is a real menu, user tasks in Windows work
+OS X의 말 그대로 메뉴로 작동하는 dock menu 와는 달리, Windows의 사용자 작업은 어플리케이션 바로가기처럼 작동합니다.
-like application shortcuts that when user clicks a task, a program would be
+유저가 작업을 클릭할 시, 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
-executed with specified arguments.
 
-To set user tasks for your application, you can use
+사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] API를 사용하여 구현할 수 있습니다:
-[app.setUserTasks][setusertaskstasks] API:
 
 ```javascript
 var app = require('app');
@@ -124,66 +107,54 @@ app.setUserTasks([
 ]);
 ```
 
-To clean your tasks list, just call `app.setUserTasks` with empty array:
+작업 리스트를 비우려면, 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다:
 
 ```javascript
 app.setUserTasks([]);
 ```
 
-The user tasks will still show even after your application closes, so the icon
+사용자 작업 리스트는 어플리케이션이 종료되어도 태스크바에 여전히 보존됩니다. 그러므로 어플리케이션이 삭제되기 전까지 이 기능이 제대로 작동하도록 하기 위해 반드시 프로그램 경로와 아이콘 경로를 지정해야 합니다.
-and program path specified for a task should exist until your application is
-uninstalled.
 
 ## Unity 런처 숏컷 기능 (Linux)
 
-In Unity, you can add custom entries to its launcher via modifying `.desktop`
+Unity 환경에선, `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding shortcuts to a launcher][unity-launcher] 가이드를 참고하세요.
-file, see [Adding shortcuts to a launcher][unity-launcher].
 
-__Launcher shortcuts of Audacious:__
+__Audacious의 런처 숏컷:__
 
 ![audacious](https://help.ubuntu.com/community/UnityLaunchersAndDesktopFiles?action=AttachFile&do=get&target=shortcuts.png)
 
 ## Taskbar progress 기능 (Windows & Unity)
 
-On Windows, a taskbar button can be used to display a progress bar. This enables
+Windows에선 태스크바의 어플리케이션 버튼에 progress bar를 추가할 수 있습니다.
-a window to provide progress information to the user without the user having to
+이 기능은 사용자가 어플리케이션의 창을 열지 않고도 어플리케이션의 작업의 상태 정보를 시각적으로 보여줄 수 있도록 해줍니다.
-switch to the window itself.
 
-The Unity DE also has a similar feature that allows you to specify the progress
+또한 Unity DE도 런처에 progress bar를 부착할 수 있습니다.
-bar in the launcher.
 
-__Progress bar in taskbar button:__
+__태스크바 버튼의 progress bar:__
 
 ![Taskbar Progress Bar](https://cloud.githubusercontent.com/assets/639601/5081682/16691fda-6f0e-11e4-9676-49b6418f1264.png)
 
-__Progress bar in Unity launcher:__
+__Unity 런처의 progress bar:__
 
 ![Unity Launcher](https://cloud.githubusercontent.com/assets/639601/5081747/4a0a589e-6f0f-11e4-803f-91594716a546.png)
 
-To set the progress bar for a Window, you can use the
+이 기능은 [BrowserWindow.setProgressBar][setprogressbar] API를 사용하여 구현할 수 있습니다:
-[BrowserWindow.setProgressBar][setprogressbar] API:
 
 ```javascript
 var window = new BrowserWindow({...});
 window.setProgressBar(0.5);
 ```
 
-## 윈도우 파일 제시 (OS X)
+## 윈도우 대표 파일 제시 (OS X)
 
-On OS X a window can set its represented file, so the file's icon can show in
+OS X는 윈도우에서 대표 파일을 설정할 수 있습니다. 쉽게 말해, 타이틀바에서 파일 아이콘을 볼 수 있을 때, 사용자가 Command-Click 또는 Control-Click 할 경우 파일 경로 팝업이 보여집니다.
-the title bar, and when users Command-Click or Control-Click on the tile a path
+또한 윈도우의 상태도 지정할 수 있습니다. 쉽게 말해, 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다.
-popup will show.
 
-You can also set the edited state of a window so that the file icon can indicate
+__대표 파일 팝업 메뉴:__
-whether the document in this window has been modified.
-
-__Represented file popup menu:__
 
 <img src="https://cloud.githubusercontent.com/assets/639601/5082061/670a949a-6f14-11e4-987a-9aaa04b23c1d.png" height="232" width="663" >
 
-To set the represented file of window, you can use the
+대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과 [BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다:
-[BrowserWindow.setRepresentedFilename][setrepresentedfilename] and
-[BrowserWindow.setDocumentEdited][setdocumentedited] APIs:
 
 ```javascript
 var window = new BrowserWindow({...});

docs/tutorial/online-offline-events-ko.md

@@ -1,4 +1,4 @@
-# 온라인/오프라인 이벤트
+# 온라인/오프라인 이벤트
 
 온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여 구현할 수 있습니다.
 

docs/tutorial/quick-start-ko.md

@@ -1,4 +1,4 @@
-# 시작하기
+# 시작하기
 
 ## 소개
 

docs/tutorial/using-native-node-modules-ko.md

@@ -38,8 +38,6 @@ $ cd /path-to-module/
 $ HOME=~/.electron-gyp node-gyp rebuild --target=0.25.0 --arch=ia64 --dist-url=https://atom.io/download/atom-shell
 ```
 
-
-
 `HOME=~/.electron-gyp`은 변경할 헤더의 위치를 찾습니다. `--target=0.25.0`은 Electron의 버전입니다.
 `--dist-url=...`은 헤더를 다운로드 하는 주소입니다. `--arch=ia64`는 64비트 시스템을 타겟으로 빌드 한다는 것을 `node-gyp`에게 알려줍니다.
 

docs/tutorial/using-pepper-flash-plugin-ko.md

@@ -1,16 +1,16 @@
-# Pepper 플래시 플러그인 사용하기
+# Pepper 플래시 플러그인 사용하기
 
-필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해서는, 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
+필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해서는, 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
 
-## 플래시 플러그인 준비하기
+## 플래시 플러그인 준비하기
 
-크롬 브라우저의 `chrome://plugins` 페이지에 접속한 후 `세부정보`에서 플래시 플러그인의 위치와 버전을 찾을 수 있습니다.
+크롬 브라우저의 `chrome://plugins` 페이지에 접속한 후 `세부정보`에서 플래시 플러그인의 위치와 버전을 찾을 수 있습니다.
-Electron에서 플래시 플러그인을 지원하기 위해선 이 두 가지를 복사해 와야 합니다.
+Electron에서 플래시 플러그인을 지원하기 위해선 이 두 가지를 복사해 와야 합니다.
 
-## Electron 스위치 추가
+## Electron 스위치 추가
 
-플러그인을 사용하기 위해 직접적으로 `--ppapi-flash-path` 와 `ppapi-flash-version` 플래그를 ready 이벤트가 호출되기 전에 추가해야합니다.
+플러그인을 사용하기 위해 직접적으로 `--ppapi-flash-path` 와 `ppapi-flash-version` 플래그를 ready 이벤트가 호출되기 전에 추가해야합니다.
-그리고 `browser-window`에 `plugins` 스위치도 추가해야합니다.
+그리고 `browser-window`에 `plugins` 스위치도 추가해야합니다.
 
 ```javascript
 var app = require('app');
@@ -30,10 +30,10 @@ app.on('window-all-closed', function() {
   }
 });
 
-// 플래시 플러그인의 위치를 설정합니다.
+// 플래시 플러그인의 위치를 설정합니다.
-// Windows의 경우, /path/to/pepflashplayer.dll
+// Windows의 경우, /path/to/pepflashplayer.dll
-// Mac의 경우, /path/to/PepperFlashPlayer.plugin
+// Mac의 경우, /path/to/PepperFlashPlayer.plugin
-// Linux의 경우, /path/to/libpepflashplayer.so
+// Linux의 경우, /path/to/libpepflashplayer.so
 app.commandLine.appendSwitch('ppapi-flash-path', '/path/to/libpepflashplayer.so');
 
 // Specify flash version, for example, v17.0.0.169
@@ -52,8 +52,8 @@ app.on('ready', function() {
 });
 ```
 
-## `<webview>` 태그를 이용하여 플러그인을 활성화
+## `<webview>` 태그를 이용하여 플러그인을 활성화
-`plugins` 속성을 `<webview>` 태그에 추가합니다.
+`plugins` 속성을 `<webview>` 태그에 추가합니다.
 ```html
 <webview src="http://www.adobe.com/software/flash/about/" plugins></webview>
 ```

docs/tutorial/using-selenium-and-webdriver-ko.md

@@ -3,7 +3,7 @@
 [ChromeDriver - WebDriver for Chrome][chrome-driver]로 부터 인용:
 
 > WebDriver는 많은 브라우저에서 웹 앱을 자동적으로 테스트하는 툴입니다.
-> 이 툴은 웹 페이지를 자동으로 탐색하고, 유저 폼을 사용하거나, 자바스크립트를 실행하는 등의 작업을 수행할 수 있습니다.
+> 이 툴킷은 웹 페이지를 자동으로 탐색하고, 유저 폼을 사용하거나, 자바스크립트를 실행하는 등의 작업을 수행할 수 있습니다.
 > ChromeDriver는 Chromium의 WebDriver wire 프로토콜 스텐드얼론 서버 구현입니다.
 > Chromium 과 WebDriver 팀 멤버에 의해 개발되었습니다.