Merge pull request #2698 from fritx/docs-zh-cn

Add docs-translations for zh-CN

docs-translations/zh-CN/development/atom-shell-vs-node-webkit.md

@@ -0,0 +1,29 @@
+# Electron 和 NW.js (原名 node-webkit) 在技术上的差异
+
+__备注：Electron 的原名是 Atom Shell。__
+
+与 NW.js 相似，Electron 提供了一个能通过 JavaScript 和 HTML 创建桌面应用的平台，同时集成 Node 来授予网页访问底层系统的权限。
+
+但是这两个项目也有本质上的区别，使得 Electron 和 NW.js 成为两个相互独立的产品。
+
+__1. 应用的入口__
+
+在 NW.js 中，一个应用的主入口是一个页面。你在 `package.json` 中指定一个主页面，它会作为应用的主窗口被打开。
+
+在 Electron 中，入口是一个 JavaScript 脚本。不同于直接提供一个URL，你需要手动创建一个浏览器窗口，然后通过 API 加载 HTML 文件。你还可以监听窗口事件，决定何时让应用退出。
+
+Electron 的工作方式更像 Node.js 运行时。 Electron 的 APIs 更加底层，因此你可以它替代 [PhantomJS](http://phantomjs.org/) 做浏览器测试。
+
+__2. 构建系统__
+
+为了避免构建整个 Chromium 带来的复杂度，Electron 通过 [`libchromiumcontent`](https://github.com/brightray/libchromiumcontent) 来访问 Chromium 的 Content API。`libchromiumcontent` 是一个独立的、引入了 Chromium Content 模块及其所有依赖的共享库。用户不需要一个强劲的机器来构建 Electron。
+
+__3. Node 集成__
+
+在 NW.js，网页中的 Node 集成需要通过给 Chromium 打补丁来实现。但在 Electron 中，我们选择了另一种方式：通过各个平台的消息循环与 libuv 的循环集成，避免了直接在 Chromium 上做改动。你可以看 [`node_bindings`](../../atom/common/) 来了解这是如何完成的。
+
+__4. 多上下文__
+
+如果你是有经验的 NW.js 用户，你应该会熟悉 Node 上下文和 web 上下文的概念。这些概念的产生源于 NW.js 的实现方式。
+
+通过使用 Node 的[多上下文](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)特性，Electron不需要在网页中引入新的 JavaScript 上下文。

docs-translations/zh-CN/development/coding-style.md

@@ -0,0 +1,30 @@
+# 编码规范
+
+以下是 Electron 项目中代码书写规范的指导方针。
+
+## C++ 和 Python
+
+对于 C++ 和 Python，我们追随 Chromium 的[Coding
+Style](http://www.chromium.org/developers/coding-style)。你可以通过 `script/cpplint.py` 来检验所有文件是否符合要求。
+
+我们使用的 Pyhton 版本是 Python 2.7。
+
+其中 C++ 代码中用到了许多 Chromium 的抽象和类型，我们希望你对其有所熟悉。一个好的去处是
+Chromium 的[重要的抽象和数据结构](https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures)。这个文档提到了一些特殊的类型、域内类型（当超出作用域时会自动释放内存）、日志机制等等。
+
+## CoffeeScript
+
+对于 CoffeeScript，我们追随 GitHub 的[Style
+Guide](https://github.com/styleguide/javascript) 及如下规则:
+
+* 文件不应该以换行结尾，因为我们要匹配 Google 的规范。
+* 文件名应该以 `-` 作连接而不是 `_`，等等。
+  `file-name.coffee` 而不是 `file_name.coffee`，因为在
+  [github/atom](https://github.com/github/atom) 模块名通常都是 `module-name` 的形式。这条规则仅应用于 `.coffee` 文件。
+
+## API 名称
+
+当新建一个API时，我们应该倾向于 getters 和 setters 的方式，而不是
+jQuery 的单函数形式。例如，`.getText()` 和 `.setText(text)`
+ 优于 `.text([text])`。这里是相关的
+[讨论记录](https://github.com/atom/electron/issues/46)。