Docs: Use "js" instead of "json" and "sh" instead of "shell" for source highlighting

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
 {

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

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

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

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

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

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

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

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

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

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

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

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}

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

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

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

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
 {

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
 {

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
 --------------------------------------------------

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"
 --------------------------------------------------

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
 {

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": {

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]
 ---------------
 {
    [...]

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
 {

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
 {

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'
 ------------------------

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

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
 {

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
 -----------------------------------

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
 {

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": {

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 '
 {

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}}}}}}"
 --------------------

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
 {

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
 {

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
 -------------------------------------

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
 {