diff --git a/docs/reference/analysis/tokenfilters/stop-tokenfilter.asciidoc b/docs/reference/analysis/tokenfilters/stop-tokenfilter.asciidoc
index 5d51afb4aee..ead0e118af7 100644
--- a/docs/reference/analysis/tokenfilters/stop-tokenfilter.asciidoc
+++ b/docs/reference/analysis/tokenfilters/stop-tokenfilter.asciidoc
@@ -31,7 +31,7 @@ type:
 
 The `stopwords` parameter accepts either an array of stopwords:
 
-[source,json]
+[source,js]
 ------------------------------------
 PUT /my_index
 {
@@ -50,7 +50,7 @@ PUT /my_index
 
 or a predefined language-specific list:
 
-[source,json]
+[source,js]
 ------------------------------------
 PUT /my_index
 {
diff --git a/docs/reference/cat.asciidoc b/docs/reference/cat.asciidoc
index bc29cc92d64..e5f3d967498 100644
--- a/docs/reference/cat.asciidoc
+++ b/docs/reference/cat.asciidoc
@@ -27,7 +27,7 @@ the available commands.
 Each of the commands accepts a query string parameter `v` to turn on
 verbose output.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/master?v'
 id                     ip        node
@@ -41,7 +41,7 @@ EGtKWZlWQYWDmX29fUnp3Q 127.0.0.1 Grey, Sara
 Each of the commands accepts a query string parameter `help` which will
 output its available columns.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/master?help'
 id   | node id
@@ -56,7 +56,7 @@ node | node name
 Each of the commands accepts a query string parameter `h` which forces
 only those columns to appear.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'n1:9200/_cat/nodes?h=ip,port,heapPercent,name'
 192.168.56.40 9300 40.3 Captain Universe
@@ -87,7 +87,7 @@ off human mode.  We'll use a byte-level resolution.  Then we'll pipe
 our output into `sort` using the appropriate column, which in this
 case is the eight one.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl '192.168.56.10:9200/_cat/indices?bytes=b' | sort -rnk8
 green wiki2 3 0 10000   0 105274918 105274918
diff --git a/docs/reference/cat/alias.asciidoc b/docs/reference/cat/alias.asciidoc
index 39b94911e26..4b1cde5f472 100644
--- a/docs/reference/cat/alias.asciidoc
+++ b/docs/reference/cat/alias.asciidoc
@@ -4,7 +4,7 @@
 `aliases` shows information about currently configured aliases to indices
 including filter and routing infos.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl '192.168.56.10:9200/_cat/aliases?v'
 alias  index filter indexRouting searchRouting
diff --git a/docs/reference/cat/allocation.asciidoc b/docs/reference/cat/allocation.asciidoc
index 69eb92a9d35..6fbdd9d43cc 100644
--- a/docs/reference/cat/allocation.asciidoc
+++ b/docs/reference/cat/allocation.asciidoc
@@ -4,7 +4,7 @@
 `allocation` provides a snapshot of how many shards are allocated to each data node
 and how much disk space they are using.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl '192.168.56.10:9200/_cat/allocation?v'
 shards diskUsed diskAvail diskRatio ip            node
diff --git a/docs/reference/cat/count.asciidoc b/docs/reference/cat/count.asciidoc
index 51b246b1077..f264f825a48 100644
--- a/docs/reference/cat/count.asciidoc
+++ b/docs/reference/cat/count.asciidoc
@@ -4,7 +4,7 @@
 `count` provides quick access to the document count of the entire
 cluster, or individual indices.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 192.168.56.10:9200/_cat/indices
 green wiki1 3 0 10000 331 168.5mb 168.5mb
diff --git a/docs/reference/cat/fielddata.asciidoc b/docs/reference/cat/fielddata.asciidoc
index c3ac311a622..250d0b39eaf 100644
--- a/docs/reference/cat/fielddata.asciidoc
+++ b/docs/reference/cat/fielddata.asciidoc
@@ -4,7 +4,7 @@
 `fielddata` shows how much heap memory is currently being used by fielddata 
 on every data node in the cluster.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl '192.168.56.10:9200/_cat/fielddata?v'
 id                     host    ip            node          total   body    text
@@ -15,7 +15,7 @@ yaDkp-G3R0q1AJ-HUEvkSQ myhost3 10.20.100.202 Microchip     284.6kb 109.2kb 175.3
 
 Fields can be specified either as a query parameter, or in the URL path:
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl '192.168.56.10:9200/_cat/fielddata?v&fields=body'
 id                     host    ip            node          total   body
diff --git a/docs/reference/cat/health.asciidoc b/docs/reference/cat/health.asciidoc
index a5112031e3d..6b12a15dee2 100644
--- a/docs/reference/cat/health.asciidoc
+++ b/docs/reference/cat/health.asciidoc
@@ -5,7 +5,7 @@
 from `/_cluster/health`. It has one option `ts` to disable the
 timestamping.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 192.168.56.10:9200/_cat/health
 1384308967 18:16:07 foo green 3 3 3 3 0 0 0
@@ -17,7 +17,7 @@ foo     green          3        3      3   3    0    0        0     0
 A common use of this command is to verify the health is consistent
 across nodes:
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % pssh -i -h list.of.cluster.hosts curl -s localhost:9200/_cat/health
 [1] 20:20:52 [SUCCESS] es3.vm
@@ -33,7 +33,7 @@ time. With enough shards, starting a cluster, or even recovering after
 losing a node, can take time (depending on your network & disk). A way
 to track its progress is by using this command in a delayed loop:
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % while true; do curl 192.168.56.10:9200/_cat/health; sleep 120; done
 1384309446 18:24:06 foo red 3 3 20 20 0 0 1812 0
diff --git a/docs/reference/cat/indices.asciidoc b/docs/reference/cat/indices.asciidoc
index 5000cc19ec8..d63e55a8865 100644
--- a/docs/reference/cat/indices.asciidoc
+++ b/docs/reference/cat/indices.asciidoc
@@ -4,7 +4,7 @@
 The `indices` command provides a cross-section of each index.  This
 information *spans nodes*.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/indices/twi*?v'
 health status index    pri rep docs.count docs.deleted store.size pri.store.size
@@ -30,7 +30,7 @@ the view of relevant stats in the context of only the primaries.
 
 Which indices are yellow?
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl localhost:9200/_cat/indices | grep ^yell
 yellow open  wiki     2 1  6401 1115 151.4mb 151.4mb
@@ -39,7 +39,7 @@ yellow open  twitter  5 1 11434    0    32mb    32mb
 
 What's my largest index by disk usage not including replicas?
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/indices?bytes=b' | sort -rnk8
 green open  wiki     2 0  6401 1115 158843725 158843725
@@ -49,7 +49,7 @@ green open  twitter2 2 0  2030    0   6125085   6125085
 
 How many merge operations have the shards for the `wiki` completed?
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/indices/wiki?pri&v&h=health,index,prirep,docs.count,mt'
 health index docs.count mt pri.mt
@@ -58,7 +58,7 @@ green  wiki        9646 16     16
 
 How much memory is used per index?
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/indices?v&h=i,tm'
 i     tm
diff --git a/docs/reference/cat/master.asciidoc b/docs/reference/cat/master.asciidoc
index bd7f5b97664..6189948d912 100644
--- a/docs/reference/cat/master.asciidoc
+++ b/docs/reference/cat/master.asciidoc
@@ -4,7 +4,7 @@
 `master` doesn't have any extra options. It simply displays the
 master's node ID, bound IP address, and node name.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/master?v'
 id                     ip            node
@@ -15,7 +15,7 @@ This information is also available via the `nodes` command, but this
 is slightly shorter when all you want to do, for example, is verify
 all nodes agree on the master:
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % pssh -i -h list.of.cluster.hosts curl -s localhost:9200/_cat/master
 [1] 19:16:37 [SUCCESS] es3.vm
diff --git a/docs/reference/cat/nodes.asciidoc b/docs/reference/cat/nodes.asciidoc
index d5c6036ef35..eb7bb7c3386 100644
--- a/docs/reference/cat/nodes.asciidoc
+++ b/docs/reference/cat/nodes.asciidoc
@@ -25,7 +25,7 @@ ActN   3806 192.168.56.20 9300 {version}   {jdk}
 
 The next few give a picture of your heap, memory, and load.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 diskAvail heapPercent heapMax ramPercent  ramMax load
    72.1gb        31.3  93.9mb         81 239.1mb 0.24
@@ -39,7 +39,7 @@ ones.  How many master-eligible nodes do I have?  How many client
 nodes?  It looks like someone restarted a node recently; which one was
 it?
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 uptime data/client master name
   3.5h d           m      Boneyard
diff --git a/docs/reference/cat/pending_tasks.asciidoc b/docs/reference/cat/pending_tasks.asciidoc
index 35c3381eb94..5452052669c 100644
--- a/docs/reference/cat/pending_tasks.asciidoc
+++ b/docs/reference/cat/pending_tasks.asciidoc
@@ -5,7 +5,7 @@
 <<cluster-pending,`/_cluster/pending_tasks`>> API in a
 convenient tabular format.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/pending_tasks?v'
 insertOrder timeInQueue priority source
diff --git a/docs/reference/cat/plugins.asciidoc b/docs/reference/cat/plugins.asciidoc
index 19e597ba7c6..a970463ff11 100644
--- a/docs/reference/cat/plugins.asciidoc
+++ b/docs/reference/cat/plugins.asciidoc
@@ -3,7 +3,7 @@
 
 The `plugins` command provides a view per node of running plugins. This information *spans nodes*.
 
-[source,shell]
+[source,sh]
 ------------------------------------------------------------------------------
 % curl 'localhost:9200/_cat/plugins?v'
 name    component       version        type isolation url
diff --git a/docs/reference/cat/recovery.asciidoc b/docs/reference/cat/recovery.asciidoc
index 857e631cec2..64265677609 100644
--- a/docs/reference/cat/recovery.asciidoc
+++ b/docs/reference/cat/recovery.asciidoc
@@ -12,7 +12,7 @@ way for shards to be loaded from disk when a node starts up.
 As an example, here is what the recovery state of a cluster may look like when there
 are no shards in transit from one node to another:
 
-[source,shell]
+[source,sh]
 ----------------------------------------------------------------------------
 > curl -XGET 'localhost:9200/_cat/recovery?v'
 index shard time type    stage source target files percent bytes     percent
@@ -28,7 +28,7 @@ Now let's see what a live recovery looks like. By increasing the replica count
 of our index and bringing another node online to host the replicas, we can see
 what a live shard recovery looks like.
 
-[source,shell]
+[source,sh]
 ----------------------------------------------------------------------------
 > curl -XPUT 'localhost:9200/wiki/_settings' -d'{"number_of_replicas":1}'
 {"acknowledged":true}
@@ -51,7 +51,7 @@ Finally, let's see what a snapshot recovery looks like. Assuming I have previous
 made a backup of my index, I can restore it using the <<modules-snapshots,snapshot and restore>>
 API.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------------------------------------
 > curl -XPOST 'localhost:9200/_snapshot/imdb/snapshot_2/_restore'
 {"acknowledged":true}
diff --git a/docs/reference/cat/segments.asciidoc b/docs/reference/cat/segments.asciidoc
index 9cc5215f6b6..f4ac6a4a22a 100644
--- a/docs/reference/cat/segments.asciidoc
+++ b/docs/reference/cat/segments.asciidoc
@@ -5,7 +5,7 @@ The `segments` command provides low level information about the segments
 in the shards of an index. It provides information similar to the
 link:indices-segments.html[_segments] endpoint.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'http://localhost:9200/_cat/segments?v'
 index shard prirep ip            segment generation docs.count [...]
@@ -14,7 +14,7 @@ test1 2     p      192.168.2.105 _0               0          1
 test1 3     p      192.168.2.105 _2               2          1
 --------------------------------------------------
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 [...] docs.deleted  size size.memory committed searchable version compound
                  0 2.9kb        7818 false     true       4.10.2  true
diff --git a/docs/reference/cat/shards.asciidoc b/docs/reference/cat/shards.asciidoc
index 07662ce3cf1..a4359af258e 100644
--- a/docs/reference/cat/shards.asciidoc
+++ b/docs/reference/cat/shards.asciidoc
@@ -7,7 +7,7 @@ docs, the bytes it takes on disk, and the node where it's located.
 
 Here we see a single index, with three primary shards and no replicas:
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 192.168.56.20:9200/_cat/shards
 wiki1 0 p STARTED 3014 31.1mb 192.168.56.10 Stiletto
@@ -22,7 +22,7 @@ If you have many shards, you may wish to limit which indices show up
 in the output.  You can always do this with `grep`, but you can save
 some bandwidth by supplying an index pattern to the end.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 192.168.56.20:9200/_cat/shards/wiki2
 wiki2 0 p STARTED 197 3.2mb 192.168.56.10 Stiletto
@@ -37,7 +37,7 @@ wiki2 2 p STARTED 275 7.8mb 192.168.56.20 Commander Kraken
 Let's say you've checked your health and you see two relocating
 shards.  Where are they from and where are they going?
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 192.168.56.10:9200/_cat/health
 1384315316 20:01:56 foo green 3 3 12 6 2 0 0
@@ -52,7 +52,7 @@ wiki1 1 r RELOCATING 3013 29.6mb 192.168.56.10 Stiletto -> 192.168.56.30 Frankie
 Before a shard can be used, it goes through an `INITIALIZING` state.
 `shards` can show you which ones.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl -XPUT 192.168.56.20:9200/_settings -d'{"number_of_replicas":1}'
 {"acknowledged":true}
@@ -69,7 +69,7 @@ If a shard cannot be assigned, for example you've overallocated the
 number of replicas for the number of nodes in the cluster, they will
 remain `UNASSIGNED`.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl -XPUT 192.168.56.20:9200/_settings -d'{"number_of_replicas":3}'
 % curl 192.168.56.20:9200/_cat/health
diff --git a/docs/reference/cat/thread_pool.asciidoc b/docs/reference/cat/thread_pool.asciidoc
index 4372a761ffe..508b3ee167b 100644
--- a/docs/reference/cat/thread_pool.asciidoc
+++ b/docs/reference/cat/thread_pool.asciidoc
@@ -4,7 +4,7 @@
 The `thread_pool` command shows cluster wide thread pool statistics per node. By default the active, queue and rejected
 statistics are returned for the bulk, index and search thread pools.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 192.168.56.10:9200/_cat/thread_pool
 host1 192.168.1.35 0 0 0 0 0 0 0 0 0
@@ -13,7 +13,7 @@ host2 192.168.1.36 0 0 0 0 0 0 0 0 0
 
 The first two columns contain the host and ip of a node.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 host      ip
 host1 192.168.1.35
@@ -22,7 +22,7 @@ host2 192.168.1.36
 
 The next three columns show the active queue and rejected statistics for the bulk thread pool.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 bulk.active bulk.queue bulk.rejected
           0          0             0
@@ -32,7 +32,7 @@ The remaining columns show the active queue and rejected statistics of the index
 
 Also other statistics of different thread pools can be retrieved by using the `h` (header) parameter.
 
-[source,shell]
+[source,sh]
 --------------------------------------------------
 % curl 'localhost:9200/_cat/thread_pool?v&h=id,host,suggest.active,suggest.rejected,suggest.completed'
 host      suggest.active suggest.rejected suggest.completed
diff --git a/docs/reference/index-modules/allocation/filtering.asciidoc b/docs/reference/index-modules/allocation/filtering.asciidoc
index d5e30fb76bb..99fd1dc7e2e 100644
--- a/docs/reference/index-modules/allocation/filtering.asciidoc
+++ b/docs/reference/index-modules/allocation/filtering.asciidoc
@@ -23,7 +23,7 @@ These metadata attributes can be used with the
 group of nodes.  For instance, we can move the index `test` to either `big` or
 `medium` nodes as follows:
 
-[source,json]
+[source,js]
 ------------------------
 PUT test/_settings
 {
@@ -35,7 +35,7 @@ PUT test/_settings
 Alternatively, we can move the index `test` away from the `small` nodes with
 an `exclude` rule:
 
-[source,json]
+[source,js]
 ------------------------
 PUT test/_settings
 {
@@ -48,7 +48,7 @@ Multiple rules can be specified, in which case all conditions must be
 satisfied.  For instance, we could move the index `test` to `big` nodes in
 `rack1` with the following:
 
-[source,json]
+[source,js]
 ------------------------
 PUT test/_settings
 {
@@ -87,7 +87,7 @@ These special attributes are also supported:
 
 All attribute values can be specified with wildcards, eg:
 
-[source,json]
+[source,js]
 ------------------------
 PUT test/_settings
 {
diff --git a/docs/reference/index-modules/store.asciidoc b/docs/reference/index-modules/store.asciidoc
index c603a00d89f..79712fbc266 100644
--- a/docs/reference/index-modules/store.asciidoc
+++ b/docs/reference/index-modules/store.asciidoc
@@ -23,7 +23,7 @@ index.store.type: niofs
 It is a _static_ setting that can be set on a per-index basis at index
 creation time:
 
-[source,json]
+[source,js]
 ---------------------------------
 PUT /my_index
 {
diff --git a/docs/reference/indices/flush.asciidoc b/docs/reference/indices/flush.asciidoc
index 3ee2601bb38..ef8cd27548b 100644
--- a/docs/reference/indices/flush.asciidoc
+++ b/docs/reference/indices/flush.asciidoc
@@ -70,7 +70,7 @@ recovery without the synced flush marker would take a long time.
 To check whether a shard has a marker or not, look for the `commit` section of shard stats returned by
 the <<indices-stats,indices stats>> API:
 
-[source,bash]
+[source,sh]
 --------------------------------------------------
 GET /twitter/_stats/commit?level=shards
 --------------------------------------------------
@@ -134,7 +134,7 @@ NOTE: It is harmless to request a synced flush while there is ongoing indexing.
  that are not will fail. Any shards that succeeded will have faster recovery times.
 
 
-[source,bash]
+[source,sh]
 --------------------------------------------------
 POST /twitter/_flush/synced
 --------------------------------------------------
diff --git a/docs/reference/mapping/transform.asciidoc b/docs/reference/mapping/transform.asciidoc
index 9377336518a..0fc8aab3204 100644
--- a/docs/reference/mapping/transform.asciidoc
+++ b/docs/reference/mapping/transform.asciidoc
@@ -47,7 +47,7 @@ source filtering.  It can be highlighted if it is marked as stored.
 The get endpoint will retransform the source if the `_source_transform`
 parameter is set.  Example:
 
-[source,bash]
+[source,sh]
 --------------------------------------------------
 curl -XGET "http://localhost:9200/test/example/3?pretty&_source_transform"
 --------------------------------------------------
diff --git a/docs/reference/mapping/types/core-types.asciidoc b/docs/reference/mapping/types/core-types.asciidoc
index e1e92846bb7..f848fbd290e 100644
--- a/docs/reference/mapping/types/core-types.asciidoc
+++ b/docs/reference/mapping/types/core-types.asciidoc
@@ -189,7 +189,7 @@ for filtering or aggregations.
 In case you would like to disable norms after the fact, it is possible to do so
 by using the <<indices-put-mapping,PUT mapping API>>, like this:
 
-[source,json]
+[source,js]
 ------------
 PUT my_index/_mapping/my_type
 {
diff --git a/docs/reference/migration/migrate_1_0.asciidoc b/docs/reference/migration/migrate_1_0.asciidoc
index aa156676e85..d77d12fc00c 100644
--- a/docs/reference/migration/migrate_1_0.asciidoc
+++ b/docs/reference/migration/migrate_1_0.asciidoc
@@ -126,7 +126,7 @@ rules:
 * The response format always has the index name, then the section, then the
   element name, for instance:
 +
-[source,json]
+[source,js]
 ---------------
 {
     "my_index": {
@@ -151,7 +151,7 @@ mapping`>>, <<indices-get-field-mapping,`get-field-mapping`>>,
 Previously a document could be indexed as itself, or wrapped in an outer
 object which specified the `type` name:
 
-[source,json]
+[source,js]
 ---------------
 PUT /my_index/my_type/1
 {
@@ -173,7 +173,7 @@ While the `search` API takes a top-level `query` parameter, the
 <<search-validate,`validate-query`>> requests expected the whole body to be a
 query. These now _require_ a top-level `query` parameter:
 
-[source,json]
+[source,js]
 ---------------
 GET /_count
 {
@@ -194,7 +194,7 @@ results AFTER aggregations have been calculated.
 This example counts the top colors in all matching docs, but only returns docs
 with color `red`:
 
-[source,json]
+[source,js]
 ---------------
 GET /_search
 {
@@ -221,7 +221,7 @@ Multi-fields are dead! Long live multi-fields!  Well, the field type
 (excluding `object` and `nested`) now accept a `fields` parameter.  It's the
 same thing, but nicer. Instead of:
 
-[source,json]
+[source,js]
 ---------------
 "title": {
     "type": "multi_field",
@@ -234,7 +234,7 @@ same thing, but nicer. Instead of:
 
 you can now write:
 
-[source,json]
+[source,js]
 ---------------
 "title": {
     "type": "string",
@@ -322,7 +322,7 @@ parameters instead.
 * Settings, like `index.analysis.analyzer.default` are now returned as proper
   nested JSON objects, which makes them easier to work with programatically:
 +
-[source,json]
+[source,js]
 ---------------
 {
     "index": {
diff --git a/docs/reference/migration/migrate_2_0.asciidoc b/docs/reference/migration/migrate_2_0.asciidoc
index 25d909e0951..d96cd11d453 100644
--- a/docs/reference/migration/migrate_2_0.asciidoc
+++ b/docs/reference/migration/migrate_2_0.asciidoc
@@ -90,7 +90,7 @@ Script fields in 1.x were only returned as a single value. So even if the return
 value of a script used to be list, it would be returned as an array containing
 a single value that is a list too, such as:
 
-[source,json]
+[source,js]
 ---------------
 "fields": {
   "my_field": [
@@ -106,7 +106,7 @@ In elasticsearch 2.x, scripts that return a list of values are considered as
 multivalued fields. So the same example would return the following response,
 with values in a single array.
 
-[source,json]
+[source,js]
 ---------------
 "fields": {
   "my_field": [
@@ -200,7 +200,7 @@ Types can no longer be specified on fields within queries.  Instead, specify typ
 
 The following is an example query in 1.x over types `t1` and `t2`:
 
-[source,json]
+[source,js]
 ---------------
 curl -XGET 'localhost:9200/index/_search'
 {
@@ -217,7 +217,7 @@ curl -XGET 'localhost:9200/index/_search'
 
 In 2.0, the query should look like the following:
 
-[source,json]
+[source,js]
 ---------------
 curl -XGET 'localhost:9200/index/t1,t2/_search'
 {
@@ -240,7 +240,7 @@ The following example illustrates the difference between 1.x and 2.0.
 
 Given these mappings:
 
-[source,json]
+[source,js]
 ---------------
 curl -XPUT 'localhost:9200/index'
 {
@@ -262,7 +262,7 @@ curl -XPUT 'localhost:9200/index'
 
 The following query was possible in 1.x:
 
-[source,json]
+[source,js]
 ---------------
 curl -XGET 'localhost:9200/index/type/_search'
 {
@@ -274,7 +274,7 @@ curl -XGET 'localhost:9200/index/type/_search'
 
 In 2.0, the same query should now be:
 
-[source,json]
+[source,js]
 ---------------
 curl -XGET 'localhost:9200/index/type/_search'
 {
@@ -347,7 +347,7 @@ In addition, terms aggregations use a custom formatter for boolean (like for
 dates and ip addresses, which are also backed by numbers) in order to return
 the user-friendly representation of boolean fields: `false`/`true`:
 
-[source,json]
+[source,js]
 ---------------
 "buckets": [
   {
@@ -486,7 +486,7 @@ The `filtered` query is deprecated. Instead you should use a `bool` query with
 a `must` clause for the query and a `filter` clause for the filter. For instance
 the below query:
 
-[source,json]
+[source,js]
 ---------------
 {
   "filtered": {
@@ -500,7 +500,7 @@ the below query:
 }
 ---------------
 can be replaced with
-[source,json]
+[source,js]
 ---------------
 {
   "bool": {
@@ -707,7 +707,7 @@ put under `fields` like regular stored fields.
 curl -XGET 'localhost:9200/test/_search?fields=_timestamp,foo'
 ---------------
 
-[source,json]
+[source,js]
 ---------------
 {
    [...]
diff --git a/docs/reference/modules/cluster/allocation_filtering.asciidoc b/docs/reference/modules/cluster/allocation_filtering.asciidoc
index 6fa0343ee4c..d465de04b76 100644
--- a/docs/reference/modules/cluster/allocation_filtering.asciidoc
+++ b/docs/reference/modules/cluster/allocation_filtering.asciidoc
@@ -12,7 +12,7 @@ node to other nodes in the cluster before shutting it down.
 
 For instance, we could decomission a node using its IP address as follows:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 PUT /_cluster/settings
 {
@@ -57,7 +57,7 @@ These special attributes are also supported:
 
 All attribute values can be specified with wildcards, eg:
 
-[source,json]
+[source,js]
 ------------------------
 PUT _cluster/settings
 {
diff --git a/docs/reference/modules/cluster/misc.asciidoc b/docs/reference/modules/cluster/misc.asciidoc
index 554324df97e..b6c50f36f92 100644
--- a/docs/reference/modules/cluster/misc.asciidoc
+++ b/docs/reference/modules/cluster/misc.asciidoc
@@ -24,7 +24,7 @@ The settings which control logging can be updated dynamically with the
 `logger.` prefix.  For instance, to increase the logging level of the
 `indices.recovery` module to `DEBUG`, issue this request:
 
-[source,json]
+[source,js]
 -------------------------------
 PUT /_cluster/settings
 {
diff --git a/docs/reference/modules/indices/request_cache.asciidoc b/docs/reference/modules/indices/request_cache.asciidoc
index 1976e470ad7..ee68d71fa9c 100644
--- a/docs/reference/modules/indices/request_cache.asciidoc
+++ b/docs/reference/modules/indices/request_cache.asciidoc
@@ -40,7 +40,7 @@ evicted.
 
 The cache can be expired manually with the <<indices-clearcache,`clear-cache` API>>:
 
-[source,json]
+[source,js]
 ------------------------
 curl -XPOST 'localhost:9200/kimchy,elasticsearch/_cache/clear?request_cache=true'
 ------------------------
@@ -51,7 +51,7 @@ curl -XPOST 'localhost:9200/kimchy,elasticsearch/_cache/clear?request_cache=true
 The cache is not enabled by default, but can be enabled when creating a new
 index as follows:
 
-[source,json]
+[source,js]
 -----------------------------
 curl -XPUT localhost:9200/my_index -d'
 {
@@ -65,7 +65,7 @@ curl -XPUT localhost:9200/my_index -d'
 It can also be enabled or disabled dynamically on an existing index with the
 <<indices-update-settings,`update-settings`>> API:
 
-[source,json]
+[source,js]
 -----------------------------
 curl -XPUT localhost:9200/my_index/_settings -d'
 { "index.requests.cache.enable": true }
@@ -78,7 +78,7 @@ curl -XPUT localhost:9200/my_index/_settings -d'
 The `query_cache` query-string parameter can be used to enable or disable
 caching on a *per-request* basis.  If set, it overrides the index-level setting:
 
-[source,json]
+[source,js]
 -----------------------------
 curl 'localhost:9200/my_index/_search?request_cache=true' -d'
 {
@@ -131,14 +131,14 @@ setting is provided for completeness' sake only.
 The size of the cache (in bytes) and the number of evictions can be viewed
 by index, with the <<indices-stats,`indices-stats`>> API:
 
-[source,json]
+[source,js]
 ------------------------
 curl 'localhost:9200/_stats/request_cache?pretty&human'
 ------------------------
 
 or by node with the <<cluster-nodes-stats,`nodes-stats`>> API:
 
-[source,json]
+[source,js]
 ------------------------
 curl 'localhost:9200/_nodes/stats/indices/request_cache?pretty&human'
 ------------------------
diff --git a/docs/reference/modules/plugins.asciidoc b/docs/reference/modules/plugins.asciidoc
index 52ed8fe7abe..1798225cace 100644
--- a/docs/reference/modules/plugins.asciidoc
+++ b/docs/reference/modules/plugins.asciidoc
@@ -18,7 +18,7 @@ Installing plugins can either be done manually by placing them under the
 
 Installing plugins typically take the following form:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 bin/plugin --install plugin_name
 -----------------------------------
@@ -28,7 +28,7 @@ same version as your elasticsearch version.
 
 For older version of elasticsearch (prior to 2.0.0) or community plugins, you would use the following form:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 bin/plugin --install <org>/<user/component>/<version>
 -----------------------------------
@@ -43,7 +43,7 @@ the `artifactId`.
 A plugin can also be installed directly by specifying the URL for it,
 for example:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 bin/plugin --url file:///path/to/plugin --install plugin-name
 -----------------------------------
@@ -106,7 +106,7 @@ Removing plugins can either be done manually by removing them under the
 
 Removing plugins typically take the following form:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 plugin --remove <pluginname>
 -----------------------------------
@@ -124,7 +124,7 @@ Note that exit codes could be:
 * `74`: IO error
 * `70`: other errors
 
-[source,shell]
+[source,sh]
 -----------------------------------
 bin/plugin --install mobz/elasticsearch-head --verbose
 plugin --remove head --silent
@@ -137,7 +137,7 @@ By default, the `plugin` script will wait indefinitely when downloading before f
 The timeout parameter can be used to explicitly specify how long it waits. Here is some examples of setting it to
 different values:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 # Wait for 30 seconds before failing
 bin/plugin --install mobz/elasticsearch-head --timeout 30s
@@ -156,14 +156,14 @@ To install a plugin via a proxy, you can pass the proxy details using the enviro
 
 On Linux and Mac, here is an example of setting it:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 bin/plugin -DproxyHost=host_name -DproxyPort=port_number --install mobz/elasticsearch-head
 -----------------------------------
 
 On Windows, here is an example of setting it:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 set JAVA_OPTS="-DproxyHost=host_name -DproxyPort=port_number"
 bin/plugin --install mobz/elasticsearch-head
diff --git a/docs/reference/modules/scripting.asciidoc b/docs/reference/modules/scripting.asciidoc
index 86920d30215..69748f09ed1 100644
--- a/docs/reference/modules/scripting.asciidoc
+++ b/docs/reference/modules/scripting.asciidoc
@@ -23,7 +23,7 @@ in the `config/scripts/` directory on every node.
 To convert an inline script to a file, take this simple script
 as an example:
 
-[source,json]
+[source,js]
 -----------------------------------
 GET /_search
 {
@@ -48,7 +48,7 @@ on every data node in the cluster:
 
 Now you can access the script by file name (without the extension):
 
-[source,json]
+[source,js]
 -----------------------------------
 GET /_search
 {
diff --git a/docs/reference/modules/snapshots.asciidoc b/docs/reference/modules/snapshots.asciidoc
index ea10ae19878..9fae7b0952d 100644
--- a/docs/reference/modules/snapshots.asciidoc
+++ b/docs/reference/modules/snapshots.asciidoc
@@ -224,7 +224,7 @@ filtering settings and rebalancing algorithm) once the snapshot is finished.
 
 Once a snapshot is created information about this snapshot can be obtained using the following command:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/my_backup/snapshot_1
 -----------------------------------
@@ -232,7 +232,7 @@ GET /_snapshot/my_backup/snapshot_1
 
 All snapshots currently stored in the repository can be listed using the following command:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/my_backup/_all
 -----------------------------------
@@ -240,14 +240,14 @@ GET /_snapshot/my_backup/_all
 
 coming[2.0] A currently running snapshot can be retrieved using the following command:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 $ curl -XGET "localhost:9200/_snapshot/my_backup/_current"
 -----------------------------------
 
 A snapshot can be deleted from the repository using the following command:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 DELETE /_snapshot/my_backup/snapshot_1
 -----------------------------------
@@ -261,7 +261,7 @@ started by mistake.
 
 A repository can be deleted using the following command:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 DELETE /_snapshot/my_backup
 -----------------------------------
@@ -275,7 +275,7 @@ the snapshots. The snapshots themselves are left untouched and in place.
 
 A snapshot can be restored using the following command:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 POST /_snapshot/my_backup/snapshot_1/_restore
 -----------------------------------
@@ -368,7 +368,7 @@ index will not be successfully restored unless these index allocation settings a
 
 A list of currently running snapshots with their detailed status information can be obtained using the following command:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/_status
 -----------------------------------
@@ -377,7 +377,7 @@ GET /_snapshot/_status
 In this format, the command will return information about all currently running snapshots. By specifying a repository name, it's possible
 to limit the results to a particular repository:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/my_backup/_status
 -----------------------------------
@@ -386,7 +386,7 @@ GET /_snapshot/my_backup/_status
 If both repository name and snapshot id are specified, this command will return detailed status information for the given snapshot even
 if it's not currently running:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/my_backup/snapshot_1/_status
 -----------------------------------
@@ -394,7 +394,7 @@ GET /_snapshot/my_backup/snapshot_1/_status
 
 Multiple ids are also supported:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/my_backup/snapshot_1,snapshot_2/_status
 -----------------------------------
@@ -409,7 +409,7 @@ the simplest method that can be used to get notified about operation completion.
 
 The snapshot operation can be also monitored by periodic calls to the snapshot info:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/my_backup/snapshot_1
 -----------------------------------
@@ -421,7 +421,7 @@ for available resources before returning the result. On very large shards the wa
 
 To get more immediate and complete information about snapshots the snapshot status command can be used instead:
 
-[source,shell]
+[source,sh]
 -----------------------------------
 GET /_snapshot/my_backup/snapshot_1/_status
 -----------------------------------
diff --git a/docs/reference/query-dsl/query_filter_context.asciidoc b/docs/reference/query-dsl/query_filter_context.asciidoc
index 7ed16959056..6fadc36aa73 100644
--- a/docs/reference/query-dsl/query_filter_context.asciidoc
+++ b/docs/reference/query-dsl/query_filter_context.asciidoc
@@ -45,7 +45,7 @@ conditions are met:
 * The `status` field contains the exact word `published`.
 * The `publish_date` field contains a date from 1 Jan 2015 onwards.
 
-[source,json]
+[source,js]
 ------------------------------------
 GET _search
 {
diff --git a/docs/reference/search/field-stats.asciidoc b/docs/reference/search/field-stats.asciidoc
index bef6c45f9ef..fb29903ebeb 100644
--- a/docs/reference/search/field-stats.asciidoc
+++ b/docs/reference/search/field-stats.asciidoc
@@ -100,7 +100,7 @@ curl -XGET "http://localhost:9200/_field_stats?fields=rating,answer_count,creati
 
 Response:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 {
    "_shards": {
diff --git a/docs/reference/search/request/post-filter.asciidoc b/docs/reference/search/request/post-filter.asciidoc
index 5a937941e18..274d14bd698 100644
--- a/docs/reference/search/request/post-filter.asciidoc
+++ b/docs/reference/search/request/post-filter.asciidoc
@@ -10,7 +10,7 @@ Imagine that you are selling shirts, and the user has specified two filters:
 Gucci in the search results.  Normally you would do this with a 
 <<query-dsl-filtered-query,`filtered` query>>:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 curl -XGET localhost:9200/shirts/_search -d '
 {
@@ -38,7 +38,7 @@ that would allow the user to limit their search results to red Gucci
 This can be done with a 
 <<search-aggregations-bucket-terms-aggregation,`terms` aggregation>>:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 curl -XGET localhost:9200/shirts/_search -d '
 {
@@ -73,7 +73,7 @@ Instead, you want to include shirts of all colors during aggregation, then
 apply the `colors` filter only to the search results.  This is the purpose of
 the `post_filter`:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 curl -XGET localhost:9200/shirts/_search -d '
 {
diff --git a/docs/reference/search/search-template.asciidoc b/docs/reference/search/search-template.asciidoc
index 1b95f376f87..bce95289e8e 100644
--- a/docs/reference/search/search-template.asciidoc
+++ b/docs/reference/search/search-template.asciidoc
@@ -210,7 +210,7 @@ _section_ markers like `{{#line_no}}`.  For this reason, the template should
 either be stored in a file (see <<pre-registered-templates>>) or, when used 
 via the REST API, should be written as a string:
 
-[source,json]
+[source,js]
 --------------------
 "inline": "{\"query\":{\"filtered\":{\"query\":{\"match\":{\"line\":\"{{text}}\"}},\"filter\":{{{#line_no}}\"range\":{\"line_no\":{{{#start}}\"gte\":\"{{start}}\"{{#end}},{{/end}}{{/start}}{{#end}}\"lte\":\"{{end}}\"{{/end}}}}{{/line_no}}}}}}"
 --------------------
diff --git a/docs/reference/setup/backup.asciidoc b/docs/reference/setup/backup.asciidoc
index 11bb7d3f395..44a0a118bc0 100644
--- a/docs/reference/setup/backup.asciidoc
+++ b/docs/reference/setup/backup.asciidoc
@@ -29,7 +29,7 @@ To back up a running 0.90.x system:
 This will prevent indices from being flushed to disk while the backup is in
 process:
 
-[source,json]
+[source,js]
 -----------------------------------
 PUT /_all/_settings
 {
@@ -45,7 +45,7 @@ PUT /_all/_settings
 This will prevent the cluster from moving data files from one node to another
 while the backup is in process:
 
-[source,json]
+[source,js]
 -----------------------------------
 PUT /_cluster/settings
 {
@@ -67,7 +67,7 @@ array snapshots, backup software).
 When the backup is complete and data no longer needs to be read from the
 Elasticsearch data path, allocation and index flushing must be re-enabled:
 
-[source,json]
+[source,js]
 -----------------------------------
 PUT /_all/_settings
 {
diff --git a/docs/reference/setup/cluster_restart.asciidoc b/docs/reference/setup/cluster_restart.asciidoc
index 03c34121ee4..5e1a55eed1c 100644
--- a/docs/reference/setup/cluster_restart.asciidoc
+++ b/docs/reference/setup/cluster_restart.asciidoc
@@ -14,7 +14,7 @@ replicate the shards that were on that node to other nodes in the cluster,
 causing a lot of wasted I/O.  This can be avoided by disabling allocation
 before shutting down a node:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 PUT /_cluster/settings
 {
@@ -27,7 +27,7 @@ PUT /_cluster/settings
 
 If upgrading from 0.90.x to 1.x, then use these settings instead:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 PUT /_cluster/settings
 {
@@ -103,7 +103,7 @@ allows the master to allocate replicas to nodes which already have local shard
 copies.   At this point, with all the nodes in the cluster, it is safe to
 reenable shard allocation:
 
-[source,json]
+[source,js]
 ------------------------------------------------------
 PUT /_cluster/settings
 {
@@ -116,7 +116,7 @@ PUT /_cluster/settings
 
 If upgrading from 0.90.x to 1.x, then use these settings instead:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 PUT /_cluster/settings
 {
diff --git a/docs/reference/setup/configuration.asciidoc b/docs/reference/setup/configuration.asciidoc
index 0e08fdf83f0..0719b1c60d3 100644
--- a/docs/reference/setup/configuration.asciidoc
+++ b/docs/reference/setup/configuration.asciidoc
@@ -56,7 +56,7 @@ operating system limits on mmap counts is likely to be too low, which may
 result in out of memory exceptions.  On Linux, you can increase the limits by
 running the following command as `root`:
 
-[source,bash]
+[source,sh]
 -------------------------------------
 sysctl -w vm.max_map_count=262144
 -------------------------------------
diff --git a/docs/reference/setup/rolling_upgrade.asciidoc b/docs/reference/setup/rolling_upgrade.asciidoc
index a3e35da0ae3..5792c34cdbc 100644
--- a/docs/reference/setup/rolling_upgrade.asciidoc
+++ b/docs/reference/setup/rolling_upgrade.asciidoc
@@ -19,7 +19,7 @@ replicate the shards that were on that node to other nodes in the cluster,
 causing a lot of wasted I/O.  This can be avoided by disabling allocation
 before shutting down a node:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 PUT /_cluster/settings
 {
@@ -38,7 +38,7 @@ You may happily continue indexing during the upgrade.  However, shard recovery
 will be much faster if you temporarily stop non-essential indexing and issue a
 <<indices-synced-flush, synced-flush>> request:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 POST /_flush/synced
 --------------------------------------------------
@@ -105,7 +105,7 @@ GET _cat/nodes
 Once the node has joined the cluster, reenable shard allocation to start using
 the node:
 
-[source,json]
+[source,js]
 --------------------------------------------------
 PUT /_cluster/settings
 {