Fix format

Author: looly

402_Nested/30_Nested_objects.md

@@ -1,11 +1,9 @@
-[[巢状-对象]]
-== 巢状对象
+## 嵌套-对象
+### 嵌套对象
 
-事实上在Elasticsearch中，创建丶删除丶修改一个文档是是原子性的，因此我们可以在一个文档中储存密切关联的实体。
-((("nested objects")))((("objects", "nested")))  举例来说，我们可以在一个文档中储存一笔订单及其所有内容，或是储存一个Blog文章及其所有回应，藉由传递一个`comments`阵列：
+事实上在Elasticsearch中，创建丶删除丶修改一个文档是是原子性的，因此我们可以在一个文档中储存密切关联的实体。举例来说，我们可以在一个文档中储存一笔订单及其所有内容，或是储存一个Blog文章及其所有回应，藉由传递一个`comments`阵列：
 
-[source,json]
---------------------------
+```json
 PUT /my_index/blogpost/1
 {
   "title": "Nest eggs",
@@ -28,15 +26,14 @@ PUT /my_index/blogpost/1
     }
   ]
 }
---------------------------
-<1> 如果我们依靠动态映射 <<dynamic-mapping,dynamic mapping>>，`comments`栏位会被自动建立为一个`object`栏位。
+```
+<1> 如果我们依靠动态映射，`comments`栏位会被自动建立为一个`object`栏位。
 
 因为所有内容都在同一个文档中，使搜寻时并不需要连接(join)blog文章与回应，因此搜寻表现更加优异。
 
 问题在於以上的文档可能会如下所示的匹配一个搜寻：
 
-[source,json]
---------------------------
+```json
 GET /_search
 {
   "query": {
@@ -48,14 +45,12 @@ GET /_search
     }
   }
 }
---------------------------
+```
 <1> Alice是31岁，而不是28岁！
 
-造成跨对象配对的原因如同我们在对象阵列 <<object-arrays>>中所讨论到，在於我们优美结构的JSON文档((("documents")))((("JSON documents")))
-在索引中被扁平化为下方的 键-值形式：
+造成跨对象配对的原因如同我们在对象阵列中所讨论到，在于我们优美结构的JSON文档在索引中被扁平化为下方的 键-值 形式：
 
-[source,json]
---------------------------
+```json
 {
   "title":            [ eggs, nest ],
   "body":             [ making, money, work, your ],
@@ -66,17 +61,16 @@ GET /_search
   "comments.stars":   [ 4, 5 ],
   "comments.date":    [ 2014-09-01, 2014-10-22 ]
 }
---------------------------
+```
 
 `Alice`与`31` 以及 `John`与`2014-09-01` 之间的关联已经无法挽回的消失了。 
-当`object`类型的栏位(参考内部对象<<inner-objects>>)用於储存_单一_对象是非常有用的。
+当`object`类型的栏位用于储存_单一_对象是非常有用的。
 从搜寻的角度来看，对於排序一个对象阵列来说关联是不需要的东西。
 
-这是_巢状对象_被设计来解决的问题。 藉由映射`commments`栏位为`nested`类型而不是`object`类型，
-每个巢状对象会被索引为一个_隐藏分割文档_，例如：
+这是_嵌套对象_被设计来解决的问题。 藉由映射`commments`栏位为`nested`类型而不是`object`类型，
+每个嵌套对象会被索引为一个_隐藏分割文档_，例如：
 
-[source,json]
---------------------------
+```json
 { <1>
   "comments.name":    [ john, smith ],
   "comments.comment": [ article, great ],
@@ -96,16 +90,16 @@ GET /_search
   "body":             [ making, money, work, your ],
   "tags":             [ cash, shares ]
 }
---------------------------
-<1> 第一个`巢状`对象
-<2> 第二个`巢状`对象
-<3> _根_或是父文档
+```
+<1> 第一个`嵌套`对象
+<2> 第二个`嵌套`对象
+<3> 根或是父文档
 
-藉由分别索引每个巢状对象，对象的栏位中保持了其关联。 我们的查询可以只在同一个巢状对象都匹配时才回应。
+藉由分别索引每个嵌套对象，对象的栏位中保持了其关联。 我们的查询可以只在同一个嵌套对象都匹配时才回应。
 
-不仅如此，因巢状对象都被索引了，连接巢状对象至根文档的查询速度非常快--几乎与查询单一文档一样快。
+不仅如此，因嵌套对象都被索引了，连接嵌套对象至根文档的查询速度非常快--几乎与查询单一文档一样快。
 
-这些额外的巢状对象被隐藏起来，我们无法直接访问他们。 为了要新增丶修改或移除一个巢状对象，我们必须重新索引整个文档。
-要牢记搜寻要求的结果并不是只有巢状对象，而是整个文档。
+这些额外的嵌套对象被隐藏起来，我们无法直接访问他们。 为了要新增丶修改或移除一个嵌套对象，我们必须重新索引整个文档。
+要牢记搜寻要求的结果并不是只有嵌套对象，而是整个文档。
 
 

402_Nested/31_Nested_mapping.md

@@ -1,10 +1,9 @@
-[[巢状-映射]]
-=== 巢状对象映射
+##嵌套-映射
+### 嵌套对象映射
 
-设定一个`nested`栏位很简单--在((("mapping (types)", "nested object")))((("nested object mapping")))你会设定为`object`类型的地方，改为`nested`类型：
+设定一个`nested`栏位很简单--在你会设定为`object`类型的地方，改为`nested`类型：
 
-[source,json]
---------------------------
+```json
 PUT /my_index
 {
   "mappings": {
@@ -24,9 +23,9 @@ PUT /my_index
     }
   }
 }
---------------------------
+```
 <1> 一个`nested`栏位接受与`object`类型相同的参数。
 
-所需仅此而已。 任何`comments`对象会被索引为分离巢状对象。
-参考更多 http://bit.ly/1KNQEP9[`nested` type reference docs]。
+所需仅此而已。 任何`comments`对象会被索引为分离嵌套对象。
+参考更多 [`nested` type reference docs](http://bit.ly/1KNQEP9)。
 

402_Nested/32_Nested_query.md

@@ -1,11 +1,9 @@
-[[巢状-查询]]
-=== 查询巢状对象
+## 嵌套-查询
+### 查询嵌套对象
 
-因巢状对象((("nested objects", "querying")))会被索引为分离隐藏文档，我们不能直接查询它们。
-((("queries", "nested"))) 而是使用 http://bit.ly/1ziFQoR[`nested`查询]或 http://bit.ly/1IOp94r[`nested` 过滤器]来存取它们：
+因嵌套对象(nested objects)会被索引为分离的隐藏文档，我们不能直接查询它们。而是使用 [`nested`查询](http://bit.ly/1ziFQoR)或 [`nested` 过滤器](http://bit.ly/1IOp94r)来存取它们：
 
-[source,json]
---------------------------
+```json
 GET /my_index/blogpost/_search
 {
   "query": {
@@ -24,27 +22,21 @@ GET /my_index/blogpost/_search
         }}}}
       ]
 }}}
---------------------------
+```
 <1> `title`条件运作在根文档上
-<2> `nested`条件``深入``巢状的`comments`栏位。
-    它不会在存取根文档的栏位，或是其他巢状文档的栏位。
-<3> `comments.name`以及`comments.age`运作在相同的巢状文档。
+<2> `nested`条件``深入``嵌套的`comments`栏位。它不会在存取根文档的栏位，或是其他嵌套文档的栏位。
+<3> `comments.name`以及`comments.age`运作在相同的嵌套文档。
 
-[TIP]
-==================================================
+>### TIP
+>一个`nested`栏位可以包含其他`nested`栏位。 相同的，一个`nested`查询可以包含其他`nested`查询。
+嵌套阶层会如同你预期的运作。
 
-一个`nested`栏位可以包含其他`nested`栏位。 相同的，一个`nested`查询可以包含其他`nested`查询。
-巢状阶层会如同你预期的运作。
-
-==================================================
-
-当然，一个`nested`查询可以匹配多个巢状文档。
+当然，一个`nested`查询可以匹配多个嵌套文档。
 每个文档的匹配会有各自的关联分数，但多个分数必须减少至单一分数才能应用至根文档。
 
-在预设中，它会平均所有巢状文档匹配的分数。这可以藉由设定`score_mode`参数为`avg`, `max`, `sum`或甚至`none`(为了防止根文档永远获得`1.0`的匹配分数时)来控制。
+在预设中，它会平均所有嵌套文档匹配的分数。这可以藉由设定`score_mode`参数为`avg`, `max`, `sum`或甚至`none`(为了防止根文档永远获得`1.0`的匹配分数时)来控制。
 
-[source,json]
---------------------------
+```json
 GET /my_index/blogpost/_search
 {
   "query": {
@@ -64,14 +56,11 @@ GET /my_index/blogpost/_search
         }}}}
       ]
 }}}
---------------------------
-<1> 从最匹配的巢状文档中给予根文档的`_score`值。
+```
+<1> 从最匹配的嵌套文档中给予根文档的`_score`值。
 
-[注意]
-====
-`nested`过滤器类似於`nested`查询，除了无法使用`score_mode`参数。 只能使用在_filter context_&#x2014;例如在`filtered`查询中--其作用类似其他的过滤器：
+>### 注意
+>`nested`过滤器类似於`nested`查询，除了无法使用`score_mode`参数。 只能使用在_filter context_&#x2014;例如在`filtered`查询中--其作用类似其他的过滤器：
 包含或不包含，但不评分。
 
-`nested`过滤器的结果本身不会缓存，通常缓存规则会被应用於`nested`过滤器_之中_的过滤器。
-====
-
+>`nested`过滤器的结果本身不会缓存，通常缓存规则会被应用於`nested`过滤器_之中_的过滤器。

402_Nested/33_Nested_sorting.md

@@ -1,11 +1,9 @@
-[[巢状排序]]
-=== 以巢状栏位排序
+## 嵌套排序
+### 以嵌套栏位排序
 
-我们可以依照巢状栏位中的值来排序，甚至藉由分离巢状文档中的值。((("nested fields, sorting by")))((("sorting", "by nested fields")))
-为了使其结果更加有趣，我们加入另一个记录：
+我们可以依照嵌套栏位中的值来排序，甚至藉由分离嵌套文档中的值。为了使其结果更加有趣，我们加入另一个记录：
 
-[source,json]
---------------------------
+```json
 PUT /my_index/blogpost/2
 {
   "title": "Investment secrets",
@@ -28,13 +26,12 @@ PUT /my_index/blogpost/2
     }
   ]
 }
---------------------------
+```
 
 想像我们要取回在十月中有收到回应的blog文章，并依照所取回的各个blog文章中最少`stars`数量的顺序作排序。
 这个搜寻请求如下：
 
-[source,json]
---------------------------
+```json
 GET /_search
 {
   "query": {
@@ -65,12 +62,11 @@ GET /_search
     }
   }
 }
---------------------------
+```
 <1> `nested`查询限制了结果为十月份收到回应的blog文章。
 <2> 结果在所有匹配的回应中依照`comment.stars`栏位的最小值(`min`)作递增(`asc`)的排序。
 <3> 排序条件中的`nested_filter`与主查询`query`条件中的`nested`查询相同。 於下一个下方解释。
 
-为什麽我们要在`nested_filter`重复写上查询条件？ 原因是排序在於执行查询後才发生。
+为什么我们要在`nested_filter`重复写上查询条件？ 原因是排序在於执行查询后才发生。
 此查询匹配了在十月中有收到回应的blog文章，回传blog文章文档作为结果。
 如果我们不加上`nested_filter`条件，我们最後会依照任何blog文章曾经收到过的回应作排序，而不是在十月份收到的。
-

SUMMARY.md

@@ -265,12 +265,12 @@
    * [Top hits](400_Relationships/22_Top_hits.md)
    * [Concurrency](400_Relationships/25_Concurrency.md)
    * [Concurrency solutions](400_Relationships/26_Concurrency_solutions.md)
-* [巢状](402_Nested/00_Intro.md)
-   * [巢状对象](402_Nested/30_Nested_objects.md)
-   * [巢状映射](402_Nested/31_Nested_mapping.md)
-   * [巢状查询](402_Nested/32_Nested_query.md)
-   * [巢状排序](402_Nested/33_Nested_sorting.md)
-   * [巢状集合](402_Nested/35_Nested_aggs.md)
+* [嵌套](402_Nested/00_Intro.md)
+   * [嵌套对象](402_Nested/30_Nested_objects.md)
+   * [嵌套映射](402_Nested/31_Nested_mapping.md)
+   * [嵌套查询](402_Nested/32_Nested_query.md)
+   * [嵌套排序](402_Nested/33_Nested_sorting.md)
+   * [嵌套集合](402_Nested/35_Nested_aggs.md)
 * [Parent Child](404_Parent_Child/00_Intro.md)
    * [Parent child](404_Parent_Child/40_Parent_child.md)
    * [Indexing parent child](404_Parent_Child/45_Indexing_parent_child.md)

TOC.md

@@ -123,9 +123,9 @@
    * [查询地理形状](340_Geoshapes/76_Querying_geo_shapes.md)
    * [在查询中使用已索引的形状](340_Geoshapes/78_Indexed_geo_shapes.md)
    * [地理形状的过滤与缓存](340_Geoshapes/80_Caching_geo_shapes.md)
-* [巢状](402_Nested/00_Intro.md)
-   * [巢状对象](402_Nested/30_Nested_objects.md)
-   * [巢状映射](402_Nested/31_Nested_mapping.md)
-   * [巢状查询](402_Nested/32_Nested_query.md)
-   * [巢状排序](402_Nested/33_Nested_sorting.md)
-   * [巢状集合](402_Nested/35_Nested_aggs.md)
+* [嵌套](402_Nested/00_Intro.md)
+   * [嵌套对象](402_Nested/30_Nested_objects.md)
+   * [嵌套映射](402_Nested/31_Nested_mapping.md)
+   * [嵌套查询](402_Nested/32_Nested_query.md)
+   * [嵌套排序](402_Nested/33_Nested_sorting.md)
+   * [嵌套集合](402_Nested/35_Nested_aggs.md)