doc: Apply proper capitalization to the Wireshark name

Change-Id: I9d29cd705c9af39bae6cffdefaba0b9c8b4bb2e6
Reviewed-on: https://code.wireshark.org/review/36081
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>

11 files changed, 35 insertions, 35 deletions

diff --git a/doc/README.dissector b/doc/README.dissector
index a35089728c..8e93e9c8e9 100644
--- a/doc/README.dissector
+++ b/doc/README.dissector
@@ -2604,7 +2604,7 @@ it is wise to check the relevant header and source files for additional details.
 
 2.2 Following "conversations".
 
-In wireshark a conversation is defined as a series of data packets between two
+In Wireshark a conversation is defined as a series of data packets between two
 address:port combinations. A conversation is not sensitive to the direction of
 the packet. The same conversation will be returned for a packet bound from
 ServerA:1000 to ClientA:2000 and the packet from ClientA:2000 to ServerA:1000.
@@ -3031,7 +3031,7 @@ whether it is registered to our protocol or not.
 We should do this because it is uncommon but it does happen that multiple
 different protocols can use the same socketpair during different stages of
 an application cycle. By keeping track of the frame number a conversation
-was started in wireshark can still tell these different protocols apart.
+was started in Wireshark can still tell these different protocols apart.
 
 The second argument to conversation_set_dissector is a dissector handle,
 which is created with a call to create_dissector_handle or
@@ -3117,7 +3117,7 @@ conversation already exists or not and if it exists we also check whether the
 registered dissector_handle for that conversation is "our" dissector or not.
 If not we create a new conversation on top of the previous one and set this new
 conversation to use our protocol.
-Since wireshark keeps track of the frame number where a conversation started
+Since Wireshark keeps track of the frame number where a conversation started
 wireshark will still be able to keep the packets apart even though they do use
 the same socketpair.
         (See packet-tftp.c and packet-snmp.c for examples of this)
diff --git a/doc/README.idl2wrs b/doc/README.idl2wrs
index 9d3e612c2f..c3ee6e3913 100644
--- a/doc/README.idl2wrs
+++ b/doc/README.idl2wrs
@@ -7,7 +7,7 @@ What is it ?
 As you have probably guessed from the name, "idl2wrs" takes a
 user specified IDL file and attempts to build a dissector that
 can decode the IDL traffic over GIOP. The resulting file is
-"C" code that should compile okay as a wireshark dissector.
+"C" code that should compile okay as a Wireshark dissector.
 
 idl2wrs basically parses the data struct given to it by
 the omniidl compiler, and using the GIOP API available in packet-giop.[ch],
@@ -41,7 +41,7 @@ the case with "Wireshark" (https://www.wireshark.org)
 How to use idl2wrs
 ==================
 
-To use the idl2wrs to generate wireshark dissectors, you
+To use the idl2wrs to generate Wireshark dissectors, you
 need the following.
 
 
@@ -51,15 +51,15 @@ need the following.
 2. omniidl from the omniORB package must be available.
    http://omniorb.sourceforge.net/
 
-3. Of course you need wireshark installed to compile the
-   code and tweak it if required. idl2wrs is part of the 
+3. Of course you need Wireshark installed to compile the
+   code and tweak it if required. idl2wrs is part of the
    standard Wireshark distribution.
 
 
 Procedure
 =========
 
-1.  To write the C code to stdout.  
+1.  To write the C code to stdout.
 
     idl2wrs  <your_file.idl>
 
@@ -77,7 +77,7 @@ Procedure
 If you don't want to use the shell script wrapper, then try
 steps 3 or 4 instead.
 
-3.  To write the C code to stdout.  
+3.  To write the C code to stdout.
 
     Usage: omniidl  -p ./ -b wireshark_be <your_file.idl>
 
@@ -92,9 +92,9 @@ steps 3 or 4 instead.
    and that will leave you with heuristic dissection.
 
 
-5. Copy the resulting C code to your wireshark src directory, edit the
+5. Copy the resulting C code to your Wireshark src directory, edit the
    following files to include the packet-test-idl.c
- 
+
    cp packet-test-idl.c /dir/where/wireshark/lives/epan/dissectors/
    edit epan/dissectors/CMakeLists.txt
 
@@ -131,9 +131,9 @@ Notes
    and wireshark_gen.py are residing in the current directory. This may need
    tweaking if you place these files somewhere else.
 
-2. If it complains about being unable to find some modules (eg tempfile.py), 
+2. If it complains about being unable to find some modules (eg tempfile.py),
    you may want to check if PYTHONPATH is set correctly.
-   On my Linux box, it is  PYTHONPATH=/usr/lib/python1.5/ 
+   On my Linux box, it is  PYTHONPATH=/usr/lib/python1.5/
 
 Frank Singleton.
 
diff --git a/doc/README.plugins b/doc/README.plugins
index 0a754ed639..3acabb72de 100644
--- a/doc/README.plugins
+++ b/doc/README.plugins
@@ -149,7 +149,7 @@ One way of dealing with this problem is to set an environment variable
 when running Wireshark: WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1.
 
 Another way to deal with this problem is to set up a working root for
-wireshark, say in $HOME/build/root and build wireshark to install
+wireshark, say in $HOME/build/root and build Wireshark to install
 there
 
 cmake -D CMAKE_INSTALL_PREFIX=${HOME}/build/root && make install
diff --git a/doc/README.stats_tree b/doc/README.stats_tree
index cb276f3897..d21703f082 100644
--- a/doc/README.stats_tree
+++ b/doc/README.stats_tree
@@ -3,9 +3,9 @@ tapping with stats_tree
 Let's suppose that you want to write a tap only to keep counters, and you
 don't want to get involved with GUI programming or maybe you'd like to make
 it a plugin. A stats_tree might be the way to go. The stats_tree module takes
-care of the representation (GUI for wireshark and text for tshark) of the
+care of the representation (GUI for Wireshark and text for Tshark) of the
 tap data. So there's very little code to write to make a tap listener usable
-from both wireshark and tshark.
+from both Wireshark and Tshark.
 
 First, you should add the TAP to the dissector in question as described in
 README.tapping .
@@ -29,8 +29,8 @@ The cleanup callback:
 Other than that the stats_tree should be registered.
 
 If you want to make it a plugin, stats_tree_register() should be called by
-plugin_register_tap_listener() read README.plugin for other information
-regarding wireshark plugins.
+plugin_register_tap_listener() read README.plugins for other information
+regarding Wireshark plugins.
 
 If you want it as part of the dissector stats_tree_register() can be called
 either by proto_register_xxx() or if you prefer by proto_reg_handoff_xxx().
@@ -186,7 +186,7 @@ The difference between the above functions is whether the item count is
 increased or not. To properly compute the average you need to either call
 avg_stat_node_add_value or avg_stat_node_add_value_notick combined
 tick_stat_node. The later sequence allows for plug-ins which are compatible
-with older wireshark versions which ignores avg_stat_node_add_value because
+with older Wireshark versions which ignores avg_stat_node_add_value because
 it does not understand the command. This would result in 0 counts for all
 nodes. It is preferred to use avg_stat_node_add_value if you are not writing
 a plug-in.
diff --git a/doc/README.vagrant b/doc/README.vagrant
index 93532f13db..86e408bcf2 100644
--- a/doc/README.vagrant
+++ b/doc/README.vagrant
@@ -48,8 +48,8 @@ out-of-tree cmake build and then triggering a build.
 
 4. Usage
 
-Running `vagrant ssh ubuntu` from the wireshark source directory will log you into
-Ubuntu VM as the userid vagrant.
+Running `vagrant ssh ubuntu` from the Wireshark source directory will log you
+into Ubuntu VM as the userid vagrant.
 
 The Ubuntu VM's build folder is located in ~/build. The Ubuntu VM's source
 folder is actually the source folder from the host system mounted as
diff --git a/doc/README.xml-output b/doc/README.xml-output
index b3011ae24c..ad9c279bdb 100644
--- a/doc/README.xml-output
+++ b/doc/README.xml-output
@@ -6,7 +6,7 @@ Wireshark has the ability to export its protocol dissection in an
 XML format, tshark has similar functionality by using the "-Tpdml"
 option.
 
-The XML that wireshark produces follows the Packet Details Markup
+The XML that Wireshark produces follows the Packet Details Markup
 Language (PDML) specified by the group at the Politecnico Di Torino
 working on Analyzer. The specification was found at:
 
@@ -37,12 +37,12 @@ be ambiguous.
 
 PDML
 ====
-The PDML that wireshark produces is known not to be loadable into Analyzer.
-It causes Analyzer to crash. As such, the PDML that wireshark produces
+The PDML that Wireshark produces is known not to be loadable into Analyzer.
+It causes Analyzer to crash. As such, the PDML that Wireshark produces
 is labeled with a version number of "0", which means that the PDML does
 not fully follow the PDML spec. Furthermore, a creator attribute in the
 "<pdml>" tag gives the version number of wireshark/tshark that produced the PDML.
-In that way, as the PDML produced by wireshark matures, but still does not
+In that way, as the PDML produced by Wireshark matures, but still does not
 meet the PDML spec, scripts can make intelligent decisions about how to
 best parse the PDML, based on the "creator" attribute.
 
@@ -104,7 +104,7 @@ Many dissectors label the undissected payload of a protocol as belonging
 to a "data" protocol, and the "data" protocol usually resided inside
 that last protocol dissected. In the PDML, The "data" protocol becomes
 a "data" field, placed exactly where the "data" protocol is in wireshark's
-protocol tree. So, if wireshark would normally show:
+protocol tree. So, if Wireshark would normally show:
 
 +-- Frame
 |
diff --git a/doc/asn2deb.pod b/doc/asn2deb.pod
index 575a71c454..ab9ad3bd4f 100644
--- a/doc/asn2deb.pod
+++ b/doc/asn2deb.pod
@@ -30,7 +30,7 @@ S<[ B<--version> ]>
 
 This manual page documents briefly the B<asn2deb> command. B<asn2deb>
 takes an ASN.1 file as input and creates a Debian package from it. The package
-contains a loadable type table file for the wireshark network analyser.
+contains a loadable type table file for the Wireshark network analyser.
 The type table is generated by the ASN.1 compiler B<snacc>.
 
 =head1 OPTIONS
diff --git a/doc/extcap.pod b/doc/extcap.pod
index 171e3a6dbf..a0564a886e 100644
--- a/doc/extcap.pod
+++ b/doc/extcap.pod
@@ -11,10 +11,10 @@ extcap - The extcap interface
 =head1 DESCRIPTION
 
 The extcap interface is a versatile plugin interface that allows external binaries
-to act as capture interfaces directly in wireshark. It is used in scenarios, where
+to act as capture interfaces directly in Wireshark. It is used in scenarios, where
 the source of the capture is not a traditional capture model
 (live capture from an interface, from a pipe, from a file, etc). The typical
-example is connecting esoteric hardware of some kind to the main wireshark app.
+example is connecting esoteric hardware of some kind to the main Wireshark application.
 
 Without extcap, a capture can always be achieved by directly writing to a capture file:
 
@@ -22,7 +22,7 @@ Without extcap, a capture can always be achieved by directly writing to a captur
     wireshark dumpfile.pcap
 
 but the extcap interface allows for such a connection to be easily established and
-configured using the wireshark GUI.
+configured using the Wireshark GUI.
 
 The extcap subsystem is made of multiple extcap binaries that are automatically
 called by the GUI in a row. In the following chapters we will refer to them as
diff --git a/doc/idl2deb.pod b/doc/idl2deb.pod
index dfddca2cb2..8a0bb40846 100644
--- a/doc/idl2deb.pod
+++ b/doc/idl2deb.pod
@@ -30,7 +30,7 @@ S< [ B<--version> ]>
 
 This manual page documents briefly the B<idl2deb> command. B<idl2deb>
 takes an CORBA IDL file as input and creates a Debian package from it. The
-package contains a loadable module for the wireshark network analyser.
+package contains a loadable module for the Wireshark network analyser.
 
 =head1 OPTIONS
 
diff --git a/doc/tshark.pod b/doc/tshark.pod
index d33474e1f2..4344f625e6 100644
--- a/doc/tshark.pod
+++ b/doc/tshark.pod
@@ -801,7 +801,7 @@ Example of usage to import data into Elasticsearch:
   curl -H "Content-Type: application/x-ndjson" -XPOST http://elasticsearch:9200/_bulk --data-binary "@file.json"
 
 Elastic requires a mapping file to be loaded as template for packets-*
-index in order to convert wireshark types to elastic types. This file
+index in order to convert Wireshark types to elastic types. This file
 can be auto-generated with the command "tshark -G elastic-mapping". Since
 the mapping file can be huge, protocols can be selected by using the option
 --elastic-mapping-filter:
diff --git a/doc/wireshark.pod.template b/doc/wireshark.pod.template
index b34898f2c9..c6f2a731d1 100644
--- a/doc/wireshark.pod.template
+++ b/doc/wireshark.pod.template
@@ -1643,7 +1643,7 @@ ascending or descending order by any column.
 
 By first selecting a conversation by clicking on it and then using the
 right mouse button (on those platforms that have a right
-mouse button) wireshark will display a popup menu offering several different
+mouse button) Wireshark will display a popup menu offering several different
 filter operations to apply to the capture.
 
 These statistics windows can also be invoked from the Wireshark command
@@ -1762,7 +1762,7 @@ string is specified all request/response pairs will be used.
 
 By first selecting a conversation by clicking on it and then using the
 right mouse button (on those platforms that have a right
-mouse button) wireshark will display a popup menu offering several different
+mouse button) Wireshark will display a popup menu offering several different
 filter operations to apply to the capture.
 
 =item *
@@ -1795,7 +1795,7 @@ on those calls matching that filter.
 
 By first selecting a conversation by clicking on it and then using the
 right mouse button (on those platforms that have a right
-mouse button) wireshark will display a popup menu offering several different
+mouse button) Wireshark will display a popup menu offering several different
 filter operations to apply to the capture.
 
 =item *