Merge pull request webpack#4 from dear-lizhihua/cn

Entry Points

Author: dear-lizhihua

content/concepts/entry-points.md

@@ -3,11 +3,11 @@ title: 入口
 sort: 0
 ---
 
-Like we mentioned in the [introduction](./), there are multiple ways to define the `entry` property in your webpack configuration. We will show you the ways how you **can** configure the `entry` property, in addition to explaining why it may be useful to you.
+正如我们在[介绍](./)中提到的，在 webpack 配置中有多种方式定义 `entry` 属性。除了解释为什么它可能对你有用，我们还将向你展示如何**能够**配置 `entry` 属性。
 
-## Single Entry (Shorthand) Syntax
+## 单入口（简写）语法
 
-Usage: `entry: string|Array<string>`
+用法：`entry: string|Array<string>`
 
 **webpack.config.js**
 
@@ -19,7 +19,7 @@ const config = {
 module.exports = config;
 ```
 
-The single entry syntax for the `entry` property is a short hand for:
+ `entry` 属性的单入口语法是下面的简写：
 
 ```javascript
 const config = {
@@ -29,13 +29,13 @@ const config = {
 };
 ```
 
-T> **What happens when you pass an array to `entry`?** Passing an array of file paths to the `entry` property creates what is known as a **"multi-main entry"**. This is useful when you would like to inject multiple dependent files together and graph their dependencies into one "chunk".
+T> **当你向 `entry` 传入一个数组时会发生什么？**向 `entry` 属性传入 文件路径(file path)数组 将创建**“多个主入口(multi-main entry)”**。当你想要多个依赖文件一起注入，并且将它们的依赖映射到一个“块(chunk)”时，传入数组是非常有用的。
 
-This is a great choice when you are looking to quickly setup a webpack configuration for an application or tool with one entry point (IE: a library). However, there is not much flexibility in extending or scaling your configuration with this syntax.
+当你正在寻找那些快速为应用程序或只有一个入口的工具（即：一个库）设置的 webpack 配置，这会是个很不错的选择。但是，使用此语法扩展配置没有太多的灵活性。
 
-## Object Syntax
+## 对象语法
 
-Usage: `entry: {[entryChunkName: string]: string|Array<string>}`
+用法：`entry: {[entryChunkName: string]: string|Array<string>}`
 
 **webpack.config.js**
 
@@ -48,15 +48,15 @@ const config = {
 };
 ```
 
-The object syntax is more verbose. However, this is the most scalable way of defining entry/entries in your application.
+对象语法会比较繁琐。然而，这是应用程序中定义入口的最可扩展的方式。
 
-T> **"Scalable webpack configurations"** are ones that can be reused and combined with other partial configurations. This is a popular technique used to separate concerns by environment, build target and runtime. They are then merged together using specialized tools like [webpack-merge](https://github.com/survivejs/webpack-merge).
+T> **“webpack 的可扩展配置”**是可重用的，并且可以与其他配置组合使用。这是一种流行的技术，用于将关注点(concern)从环境(environment)、构建目标(build target)、运行时(runtime)中分离。然后使用专门的工具（如 [webpack-merge](https://github.com/survivejs/webpack-merge)）把它们合并在一起。
 
-## Scenarios
+## 常见场景
 
-Below is a list of entry configurations and their real-world use cases:
+以下列出入口配置和它们的实际用例：
 
-#### Separate App and Vendor Entries
+#### 入口分离 应用(app) 和 公共库(vendor)
 
 **webpack.config.js**
 
@@ -69,11 +69,11 @@ const config = {
 };
 ```
 
-**What does this do?** At face value this tells webpack to create dependency graphs starting at both `app.js` and `vendors.js`. These graphs are completely separate and independent of each other (there will be a webpack bootstrap in each bundle). This is commonly seen with single page applications which have only one entry point (excluding vendors).
+**是什么？**从表面上看，这告诉我们 webpack 从 `app.js` 和 `vendors.js` 开始创建依赖图表(dependency graph)。这些图表是完全分离、互相独立的（每个 bundle 中都有一个 webpack 引导(bootstrap)）。在只有一个入口点（不包括公共库）的单页应用中比较常见。
 
-**Why?** This setup allows you to leverage [`CommonsChunkPlugin`](../../api/plugins/commonschunkplugin) and extract any vendor references from your app bundle into your vendor bundle, replacing them with `__webpack_require__()` calls. If there is no vendor code in your application bundle, then you can achieve a common pattern in webpack known as [long-term vendor-caching.](../../how-to/cache).
+**为什么？**此设置允许你使用[`CommonsChunkPlugin`](../../api/plugins/commonschunkplugin)并从 app 包 提取 公共引用(vendor reference) 到 vendor 包，并把公共引用的部分替换为 `__webpack_require__()` 调用。如果应用包中了没有公共代码，那么你可以在 webpack 中实现被称为 [持久缓存](../../how-to/cache) 的通用模式。
 
-#### Multi Page Application
+#### 多页应用
 
 **webpack.config.js**
 
@@ -88,10 +88,10 @@ const config = {
 };
 ```
 
-**What does this do?** We are telling webpack that we would like 4 separate dependency graphs (like the above example).
+**是什么？**我们告诉 webpack 需要 4 个独立分离的依赖图表（如上面的例子）。
 
-**Why?** In a multi-page application, the server is going to fetch a new HTML document for you. The page reloads this new document and assets are redownloaded. However, this gives us the unique opportunity to do multiple things:
+**为什么？**在多页应用中，服务器将为您获取一个新的 HTML 文档。页面重新加载新文档，并且资源被重新下载。然而，这给了我们独特的机会去做很多事：
 
-- Use [`CommonsChunkPlugin`](../../api/plugins/commonschunkplugin) to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the amount of entry points increase.
+- 使用 [`CommonsChunkPlugin`](../../api/plugins/commonschunkplugin) 在每个页面间创建 应用共享代码 的 包文件(bundle)。由于入口点增多，多页应用能够在入口点重用大量代码/模块，这样可以极大的从这些新技术受益。
 
-- Set up [long-term vendor-caching.](../../how-to/cache) with the same plugin and techniques seen in the first example.
+- 使用在第一个示例中相同的插件和技术设置[持久缓存](../../how-to/cache)

content/concepts/index.md

@@ -51,8 +51,6 @@ const config = {
 
 T> 你可能看到项目 **生成(emitted 或 emit)** 贯穿我们整个文档和[插件 API](../api/plugins)。它是“生产(produced) 或 排放(discharged)”的特殊术语。
 
-T> You may see the term **emitted** or **emit** used throughout our documentation and [plugin API](../api/plugins). This is a fancy term for "produced or discharged".
-
  `output` 属性有[很多可配置的特性](../api/configuration)，让我们花费一些时间理解 `output` 属性中一些最常见的用例。
 
 [**了解更多！**](./output)