You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@trafficserver.apache.org by jp...@apache.org on 2014/02/26 06:34:43 UTC

[11/50] [abbrv] Doc: Clean up po files

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/arch/cache/cache-arch.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/arch/cache/cache-arch.en.po b/doc/locale/ja/LC_MESSAGES/arch/cache/cache-arch.en.po
index 7223cb4..26c8cc7 100644
--- a/doc/locale/ja/LC_MESSAGES/arch/cache/cache-arch.en.po
+++ b/doc/locale/ja/LC_MESSAGES/arch/cache/cache-arch.en.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"
@@ -23,31 +23,31 @@ msgstr ""
 msgid ""
 "In addition to an HTTP proxy, |ATS| is also an HTTP cache. |TS| can cache "
 "any octet stream although it currently supports only those octet streams "
-"delivered by the HTTP protocol. When such a stream is cached (along with the"
-" HTTP protocol headers) it is termed an *object* in the cache. Each object "
-"is identified by a globally unique value called a *cache key*. By default "
-"this is generated by taking the `MD5 hash "
-"<http://www.openssl.org/docs/crypto/md5.html>`_ of the URI used to retrieve "
-"the content from the origin server."
+"delivered by the HTTP protocol. When such a stream is cached (along with "
+"the HTTP protocol headers) it is termed an *object* in the cache. Each "
+"object is identified by a globally unique value called a *cache key*. By "
+"default this is generated by taking the `MD5 hash <http://www.openssl.org/"
+"docs/crypto/md5.html>`_ of the URI used to retrieve the content from the "
+"origin server."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:32
 msgid ""
 "The purpose of this document is to describe the basic structure and "
-"implementation details of the |TS| cache. Configuration of the cache will be"
-" discussed only to the extent needed to understand the internal mechanisms. "
-"This document will be useful primarily to |TS| developers working on the "
-"|TS| codebase or plugins for |TS|. It is assumed the reader is already "
-"familiar with the :ref:`admin-guide` and specifically with :ref:`http-proxy-"
-"caching` and :ref:`configuring-the-cache` along with the associated "
-"configuration files and values."
+"implementation details of the |TS| cache. Configuration of the cache will "
+"be discussed only to the extent needed to understand the internal "
+"mechanisms. This document will be useful primarily to |TS| developers "
+"working on the |TS| codebase or plugins for |TS|. It is assumed the reader "
+"is already familiar with the :ref:`admin-guide` and specifically with :ref:"
+"`http-proxy-caching` and :ref:`configuring-the-cache` along with the "
+"associated configuration files and values."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:38
 msgid ""
 "Unfortunately the internal terminology is not particularly consistent so "
-"this document will frequently use terms in different ways than they are used"
-" in the code in an attempt to create some consistency."
+"this document will frequently use terms in different ways than they are "
+"used in the code in an attempt to create some consistency."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:42
@@ -79,11 +79,11 @@ msgstr ""
 msgid ""
 "This storage organized in to a set of :term:`cache volume`\\ s which are "
 "defined in :file:`volume.config`. Cache volumes can be defined by a "
-"percentage of the total storage or an absolute amount of storage. By default"
-" each cache volume is spread across all of the cache spans for robustness. "
-"The intersection of a cache volume and a cache span is a :term:`cache "
-"stripe`. Each cache span is divided in to cache stripes and each cache "
-"volume is a collection of those stripes."
+"percentage of the total storage or an absolute amount of storage. By "
+"default each cache volume is spread across all of the cache spans for "
+"robustness. The intersection of a cache volume and a cache span is a :term:"
+"`cache stripe`. Each cache span is divided in to cache stripes and each "
+"cache volume is a collection of those stripes."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:59
@@ -101,20 +101,20 @@ msgid ""
 "are assigned to a stripe (and hence to a cache volume) automatically based "
 "on a hash of the URI used to retrieve the object from the origin server. It "
 "is possible to configure this to a limited extent in :file:`hosting.config` "
-"which supports content from specific host or domain to be stored on specific"
-" volumes. In addition, as of version 4.0.1 it is possible to control which "
-"cache spans (and hence, which cache stripes) are contained in a specific "
-"cache volume."
+"which supports content from specific host or domain to be stored on "
+"specific volumes. In addition, as of version 4.0.1 it is possible to "
+"control which cache spans (and hence, which cache stripes) are contained in "
+"a specific cache volume."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:76
 msgid ""
 "The layout and structure of the cache spans, the cache volumes, and the "
-"cache stripes that compose them are derived entirely from the "
-":file:`storage.config` and :file:`cache.config` and is recomputed from "
-"scratch when the :process:`traffic_server` is started. Therefore any change "
-"to those files can (and almost always will) invalidate the existing cache in"
-" its entirety."
+"cache stripes that compose them are derived entirely from the :file:"
+"`storage.config` and :file:`cache.config` and is recomputed from scratch "
+"when the :process:`traffic_server` is started. Therefore any change to "
+"those files can (and almost always will) invalidate the existing cache in "
+"its entirety."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:82
@@ -126,10 +126,10 @@ msgid ""
 "|TS| treats the storage associated with a cache stripe as an "
 "undifferentiated span of bytes. Internally each stripe is treated almost "
 "entirely independently. The data structures described in this section are "
-"duplicated for each stripe. Internally the term \"volume\" is used for these"
-" stripes and implemented primarily in :cpp:class:`Vol`. What a user thinks "
-"of as a volume (what this document calls a \"cache volume\") is represented "
-"by :cpp:class:`CacheVol`."
+"duplicated for each stripe. Internally the term \"volume\" is used for "
+"these stripes and implemented primarily in :cpp:class:`Vol`. What a user "
+"thinks of as a volume (what this document calls a \"cache volume\") is "
+"represented by :cpp:class:`CacheVol`."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:91
@@ -147,34 +147,34 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:107
 msgid ""
 "Content in a stripe is tracked via a directory. We call each element of the "
-"directory a \"directory entry\" and each is represented by :cpp:class:`Dir`."
-" Each entry refers to a chunk of contiguous storage in the cache. These are "
-"referred to variously as \"fragments\", \"segments\", \"docs\" / "
+"directory a \"directory entry\" and each is represented by :cpp:class:"
+"`Dir`. Each entry refers to a chunk of contiguous storage in the cache. "
+"These are referred to variously as \"fragments\", \"segments\", \"docs\" / "
 "\"documents\", and a few other things. This document will use the term "
 "\"fragment\" as that is the most common reference in the code. The term "
 "\"Doc\" (for :cpp:class:`Doc`) will be used to refer to the header data for "
 "a fragment. Overall the directory is treated as a hash with a \"cache ID\" "
 "as the key. A cache ID is a 128 bit (16 byte) value generated in various "
-"ways depending on context. This ID is reduced and used as an index in to the"
-" directory to locate an entry in the standard way."
+"ways depending on context. This ID is reduced and used as an index in to "
+"the directory to locate an entry in the standard way."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:115
 msgid ""
-"The directory is used as a memory resident structure which means a directory"
-" entry is as small as possible (currently 10 bytes). This forces some "
-"compromises on the data that can be stored there. On the other hand this "
-"means that most cache misses do not require disk I/O which has a large "
+"The directory is used as a memory resident structure which means a "
+"directory entry is as small as possible (currently 10 bytes). This forces "
+"some compromises on the data that can be stored there. On the other hand "
+"this means that most cache misses do not require disk I/O which has a large "
 "performance benefit."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:119
 msgid ""
-"An additional point is the directory is always fully sized. Once a stripe is"
-" initialized the directory size is fixed and never changed. This size is "
+"An additional point is the directory is always fully sized. Once a stripe "
+"is initialized the directory size is fixed and never changed. This size is "
 "related (roughly linearly) to the size of the stripe. It is for this reason "
-"the memory footprint of |TS| depends strongly on the size of the disk cache."
-" Because the directory size does not change, neither does this memory "
+"the memory footprint of |TS| depends strongly on the size of the disk "
+"cache. Because the directory size does not change, neither does this memory "
 "requirement so |TS| does not consume more memory as more content is stored "
 "in the cache. If there is enough memory to run |TS| with an empty cache "
 "there is enough to run it with a full cache."
@@ -182,10 +182,10 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:128
 msgid ""
-"Each entry stores an offset in the stripe and a size. The size stored in the"
-" directory entry is an :ref:`approximate size <dir-size>` which is at least "
-"as big as the actual data. Exact size data is stored in the fragment header "
-"on disk."
+"Each entry stores an offset in the stripe and a size. The size stored in "
+"the directory entry is an :ref:`approximate size <dir-size>` which is at "
+"least as big as the actual data. Exact size data is stored in the fragment "
+"header on disk."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:133
@@ -198,13 +198,13 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:139
 msgid ""
 "The entries in a directory are grouped. The first level grouping is a "
-"*bucket*. This is a fixed number (currently 4 - defined as ``DIR_DEPTH``) of"
-" entries. The index generated from a cache ID is used as a bucket index (not"
-" an entry index). Buckets are grouped in to *segments*. All segments in a "
-"stripe have the same number of buckets. The number of segments in a stripe "
-"is chosen so that each segment has as many buckets as possible without "
-"exceeeding 65535 (2\\ :sup:`16`\\ -1) entries in a segment. Note that all "
-"segments in the same stripe will have the same number of buckets."
+"*bucket*. This is a fixed number (currently 4 - defined as ``DIR_DEPTH``) "
+"of entries. The index generated from a cache ID is used as a bucket index "
+"(not an entry index). Buckets are grouped in to *segments*. All segments in "
+"a stripe have the same number of buckets. The number of segments in a "
+"stripe is chosen so that each segment has as many buckets as possible "
+"without exceeeding 65535 (2\\ :sup:`16`\\ -1) entries in a segment. Note "
+"that all segments in the same stripe will have the same number of buckets."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:148
@@ -213,29 +213,29 @@ msgid ""
 "entries in the same segment. The index size is 16 bits which suffices to "
 "index any entry in the same segment. The stripe header contains an array of "
 "entry indices which are used as the roots of a free list. When a stripe is "
-"initialized the first entry in each bucket is zeroed (marked unused) and all"
-" other entries are put in the corresponding segment free list rooted in the "
-"stripe header. In essence the first element of each fixed bucket is used as "
-"a root for that bucket. The other entries in the fixed bucker are "
-"preferentially preferred for adding to that bucket but this is not required."
-" The segment free lists are initialized such that the extra bucket entries "
-"are added in order - all the seconds, then the thirds, then the fourths. "
-"Because the free lists are FIFOs this means extra entries will be selected "
-"from the fourth entries across all the buckets first, then the thirds, etc. "
-"This maximizes locality for bucket searching."
+"initialized the first entry in each bucket is zeroed (marked unused) and "
+"all other entries are put in the corresponding segment free list rooted in "
+"the stripe header. In essence the first element of each fixed bucket is "
+"used as a root for that bucket. The other entries in the fixed bucker are "
+"preferentially preferred for adding to that bucket but this is not "
+"required. The segment free lists are initialized such that the extra bucket "
+"entries are added in order - all the seconds, then the thirds, then the "
+"fourths. Because the free lists are FIFOs this means extra entries will be "
+"selected from the fourth entries across all the buckets first, then the "
+"thirds, etc. This maximizes locality for bucket searching."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:161
 msgid ""
-"Entries are removed from the free list when used and returned when no longer"
-" in use. When a fragment needs to be put in to the directory the cache ID is"
-" used to locate a bucket (which also determines the segment). If the first "
-"entry in the bucket is marked unused, it is used. If not then the other "
-"entries in the bucket are searched and if any are on the free list, that "
-"entry is used. If none are available then the first entry on the segment "
-"free list is used. This entry is attached to the bucket via the same next "
-"and previous indices used for the free list so that it can be found when "
-"doing a lookup of a cache ID."
+"Entries are removed from the free list when used and returned when no "
+"longer in use. When a fragment needs to be put in to the directory the "
+"cache ID is used to locate a bucket (which also determines the segment). If "
+"the first entry in the bucket is marked unused, it is used. If not then the "
+"other entries in the bucket are searched and if any are on the free list, "
+"that entry is used. If none are available then the first entry on the "
+"segment free list is used. This entry is attached to the bucket via the "
+"same next and previous indices used for the free list so that it can be "
+"found when doing a lookup of a cache ID."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:169
@@ -245,14 +245,14 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:171
 msgid ""
 "The storage layout is the stripe metadata followed by cached content. The "
-"metadata consists of three parts - the stripe header, the directory, and the"
-" stripe footer. The metadata is stored twice. The header and the footer are "
-"instances of :cpp:class:`VolHeaderFooter`. This is a stub structure which "
-"can have a trailing variable sized array. This array is used as the segment "
-"free list roots in the directory. Each contains the segment index of the "
-"first element of the free list for the segment. The footer is a copy of the "
-"header without the segment free lists. This makes the size of the header "
-"dependent on the directory but not that of the footer."
+"metadata consists of three parts - the stripe header, the directory, and "
+"the stripe footer. The metadata is stored twice. The header and the footer "
+"are instances of :cpp:class:`VolHeaderFooter`. This is a stub structure "
+"which can have a trailing variable sized array. This array is used as the "
+"segment free list roots in the directory. Each contains the segment index "
+"of the first element of the free list for the segment. The footer is a copy "
+"of the header without the segment free lists. This makes the size of the "
+"header dependent on the directory but not that of the footer."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:181
@@ -265,9 +265,10 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:184
 msgid ""
-"The start of stripe data. This represents either space reserved at the start"
-" of a physical device to avoid problems with the host operating system, or "
-"an offset representing use of space in the cache span by other stripes."
+"The start of stripe data. This represents either space reserved at the "
+"start of a physical device to avoid problems with the host operating "
+"system, or an offset representing use of space in the cache span by other "
+"stripes."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:188
@@ -292,8 +293,8 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:194
 msgid ""
-"Total number of blocks in the stripe available for content storage. "
-":cpp:member:`Vol::data_blocks`."
+"Total number of blocks in the stripe available for content storage. :cpp:"
+"member:`Vol::data_blocks`."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:196
@@ -307,13 +308,13 @@ msgstr ""
 msgid ""
 "The total size of the directory (the number of entries) is computed by "
 "taking the size of the stripe and dividing by the average object size. The "
-"directory always consumes this amount of memory which has the effect that if"
-" cache size is increased so is the memory requirement for |TS|. The average "
-"object size defaults to 8000 bytes but can be configured using "
-":ts:cv:`proxy.config.cache.min_average_object_size`. Increasing the average "
-"object size will reduce the memory footprint of the directory at the expense"
-" of reducing the number of distinct objects that can be stored in the cache "
-"[#]_."
+"directory always consumes this amount of memory which has the effect that "
+"if cache size is increased so is the memory requirement for |TS|. The "
+"average object size defaults to 8000 bytes but can be configured using :ts:"
+"cv:`proxy.config.cache.min_average_object_size`. Increasing the average "
+"object size will reduce the memory footprint of the directory at the "
+"expense of reducing the number of distinct objects that can be stored in "
+"the cache [#]_."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:208
@@ -321,11 +322,11 @@ msgid ""
 "The content area stores the actual objects and is used as a circular buffer "
 "where new objects overwrite the least recently cached objects. The location "
 "in a stripe where new cache data is written is called the *write cursor*. "
-"This means that objects can be de facto evicted from cache even if they have"
-" not expired if the data is overwritten by the write cursor. If an object is"
-" overwritten this is not detected at that time and the directory is not "
-"updated. Instead it will be noted if the object is accessed in the future "
-"and the disk read of the fragment fails."
+"This means that objects can be de facto evicted from cache even if they "
+"have not expired if the data is overwritten by the write cursor. If an "
+"object is overwritten this is not detected at that time and the directory "
+"is not updated. Instead it will be noted if the object is accessed in the "
+"future and the disk read of the fragment fails."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:217
@@ -343,10 +344,10 @@ msgid ""
 "copies of data being written at the write cursor. The originals are left as "
 "\"dead\" space which will be consumed when the write cursor arrives at that "
 "disk location. Once the stripe directory is updated (in memory!) the "
-"original fragment in the cache is effectively destroyed. This is the general"
-" space management techinque used in other cases as well. If an object needs "
-"to removed from cache, only the directory needs to be changed. No other work"
-" (and *particularly* no disk I/O) needs to be done."
+"original fragment in the cache is effectively destroyed. This is the "
+"general space management techinque used in other cases as well. If an "
+"object needs to removed from cache, only the directory needs to be changed. "
+"No other work (and *particularly* no disk I/O) needs to be done."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:229
@@ -355,49 +356,48 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:231
 msgid ""
-"Objects are stored as two types of data, metadata and content data. Metadata"
-" is all the data about the object and the content and includes the HTTP "
-"headers. The content data is the content of the object, the octet stream "
-"delivered to the client as the object."
+"Objects are stored as two types of data, metadata and content data. "
+"Metadata is all the data about the object and the content and includes the "
+"HTTP headers. The content data is the content of the object, the octet "
+"stream delivered to the client as the object."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:235
 msgid ""
-"Objects are rooted in a :cpp:class:`Doc` structure stored in the cache. "
-":cpp:class:`Doc` serves as the header data for a fragment and is contained "
+"Objects are rooted in a :cpp:class:`Doc` structure stored in the cache. :"
+"cpp:class:`Doc` serves as the header data for a fragment and is contained "
 "at the start of every fragment. The first fragment for an object is termed "
-"the \"first ``Doc``\" and always contains the object metadata. Any operation"
-" on the object will read this fragment first. The fragment is located by "
-"converting the cache key for the object to a cache ID and then doing a "
-"lookup for a directory entry with that key. The directory entry has the "
-"offset and approximate size of the first fragment which is then read from "
-"the disk. This fragment will contain the request header and response along "
-"with overall object properties (such as content length)."
+"the \"first ``Doc``\" and always contains the object metadata. Any "
+"operation on the object will read this fragment first. The fragment is "
+"located by converting the cache key for the object to a cache ID and then "
+"doing a lookup for a directory entry with that key. The directory entry has "
+"the offset and approximate size of the first fragment which is then read "
+"from the disk. This fragment will contain the request header and response "
+"along with overall object properties (such as content length)."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:245
 msgid ""
-"|TS| supports `varying content "
-"<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44>`_ for "
-"objects. These are called *alternates*. All metadata for all alternates is "
-"stored in the first fragment including the set of alternates and the HTTP "
-"headers for them. This enables `alternate selection "
-"<http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions"
-"/http-alternate-selection.en.html>`_ to be done after the first ``Doc`` is "
-"read from disk. An object that has more than one alternate will have the "
-"alternate content stored separately from the first fragment. For objects "
-"with only one alternate the content may or may not be in the same (first) "
-"fragment as the metadata. Each separate alternate content is allocated a "
-"directory entry and the key for that entry is stored in the first fragment "
-"metadata."
+"|TS| supports `varying content <http://www.w3.org/Protocols/rfc2616/rfc2616-"
+"sec14.html#sec14.44>`_ for objects. These are called *alternates*. All "
+"metadata for all alternates is stored in the first fragment including the "
+"set of alternates and the HTTP headers for them. This enables `alternate "
+"selection <http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-"
+"transactions/http-alternate-selection.en.html>`_ to be done after the first "
+"``Doc`` is read from disk. An object that has more than one alternate will "
+"have the alternate content stored separately from the first fragment. For "
+"objects with only one alternate the content may or may not be in the same "
+"(first) fragment as the metadata. Each separate alternate content is "
+"allocated a directory entry and the key for that entry is stored in the "
+"first fragment metadata."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:254
 msgid ""
-"Prior to version 4.0.1 the header data was stored in the "
-":cpp:class:`CacheHTTPInfoVector` class which was marshaled to a variable "
-"length area of the on disk image, followed by information about additional "
-"fragments if needed to store the object."
+"Prior to version 4.0.1 the header data was stored in the :cpp:class:"
+"`CacheHTTPInfoVector` class which was marshaled to a variable length area "
+"of the on disk image, followed by information about additional fragments if "
+"needed to store the object."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:261
@@ -408,9 +408,9 @@ msgstr ""
 msgid ""
 "This had the problem that with only one fragment table it could not be "
 "reliable for objects with more than one alternate [#]_. Therefore the "
-"fragment data was moved from being a separate variable length section of the"
-" metadata to being directly incorporated in to the "
-":cpp:class:`CacheHTTPInfoVector`, yielding a layout of the following form."
+"fragment data was moved from being a separate variable length section of "
+"the metadata to being directly incorporated in to the :cpp:class:"
+"`CacheHTTPInfoVector`, yielding a layout of the following form."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:270
@@ -421,8 +421,8 @@ msgstr ""
 msgid ""
 "Each element in the vector contains for each alternate, in addition to the "
 "HTTP headers and the fragment table (if any), a cache key. This cache key "
-"identifies a directory entry that is referred to as the \"earliest "
-"``Doc``\". This is the location where the content for the alternate begins."
+"identifies a directory entry that is referred to as the \"earliest ``Doc``"
+"\". This is the location where the content for the alternate begins."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:276
@@ -432,32 +432,32 @@ msgid ""
 "*resident alternate* in the code. This can only happen on the initial store "
 "of the object. If the metadata is updated (such as a ``304`` response to an "
 "``If-Modified-Since`` request) then unless the object is small, the object "
-"data will be left in the original fragment and a new fragment written as the"
-" first fragment, making the alternate non-resident. \"Small\" is defined as "
-"a length smaller than :ts:cv:`proxy.config.cache.alt_rewrite_max_size`."
+"data will be left in the original fragment and a new fragment written as "
+"the first fragment, making the alternate non-resident. \"Small\" is defined "
+"as a length smaller than :ts:cv:`proxy.config.cache.alt_rewrite_max_size`."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:284
 msgid ""
 "The :cpp:class:`CacheHTTPInfoVector` is stored only in the first ``Doc``. "
-"Subsequent ``Doc`` instances for the object, including the earliest ``Doc``,"
-" should have an ``hlen`` of zero and if not, it is ignored."
+"Subsequent ``Doc`` instances for the object, including the earliest "
+"``Doc``, should have an ``hlen`` of zero and if not, it is ignored."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:287
 msgid ""
 "Large objects are split in to multiple fragments when written to the cache. "
-"This is indicated by a total document length that is longer than the content"
-" in first ``Doc`` or an earliest ``Doc``. In such a case a fragment offset "
-"table is stored. This contains the byte offset in the object content of the "
-"first byte of content data for each fragment past the first (as the offset "
-"for the first is always zero). This allows range requests to be serviced "
-"much more efficiently for large objects, as intermediate fragments that do "
-"not contain data in the range can be skipped. The last fragment in the "
-"sequence is detected by the fragment size and offset reaching the end of the"
-" total size of the object, there is no explicit end mark. Each fragment is "
-"computationally chained from the previous in that the cache key for fragment"
-" N is computed by::"
+"This is indicated by a total document length that is longer than the "
+"content in first ``Doc`` or an earliest ``Doc``. In such a case a fragment "
+"offset table is stored. This contains the byte offset in the object content "
+"of the first byte of content data for each fragment past the first (as the "
+"offset for the first is always zero). This allows range requests to be "
+"serviced much more efficiently for large objects, as intermediate fragments "
+"that do not contain data in the range can be skipped. The last fragment in "
+"the sequence is detected by the fragment size and offset reaching the end "
+"of the total size of the object, there is no explicit end mark. Each "
+"fragment is computationally chained from the previous in that the cache key "
+"for fragment N is computed by::"
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:298
@@ -473,11 +473,11 @@ msgid ""
 "written last. When read from disk, both the first and earliest ``Doc`` are "
 "validated (tested to ensure that they haven't been overwritten by the write "
 "cursor) to verify that the entire document is present on disk (as they "
-"bookend the other fragments - the write cursor cannot overwrite them without"
-" overwriting at leastone of the verified ``Doc`` instances). Note that while"
-" the fragments of a single object are ordered they are not necessarily "
-"contiguous as data from different objects are interleaved as the data "
-"arrives in |TS|."
+"bookend the other fragments - the write cursor cannot overwrite them "
+"without overwriting at leastone of the verified ``Doc`` instances). Note "
+"that while the fragments of a single object are ordered they are not "
+"necessarily contiguous as data from different objects are interleaved as "
+"the data arrives in |TS|."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:310
@@ -488,21 +488,21 @@ msgstr ""
 msgid ""
 "Documents which are \"pinned\" into the cache must not be overwritten so "
 "they are \"evacuated\" from in front of the write cursor. Each fragment is "
-"read and rewritten. There is a special lookup mechanism for objects that are"
-" being evacuated so that they can be found in memory rather than the "
+"read and rewritten. There is a special lookup mechanism for objects that "
+"are being evacuated so that they can be found in memory rather than the "
 "potentially unreliable disk regions. The cache scans ahead of the write "
-"cursor to discover pinned objects as there is a dead zone immediately before"
-" the write cursor from which data cannot be evacuated. Evacuated data is "
-"read from disk and placed in the write queue and written as its turn comes "
-"up."
+"cursor to discover pinned objects as there is a dead zone immediately "
+"before the write cursor from which data cannot be evacuated. Evacuated data "
+"is read from disk and placed in the write queue and written as its turn "
+"comes up."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:320
 msgid ""
-"It appears that objects can only be pinned via the :file:`cache.config` file"
-" and if the :ts:cv:`proxy.config.cache.permit.pinning` is set to non-zero "
-"(it is zero by default). Objects which are in use when the write cursor is "
-"near use the same underlying evacuation mechanism but are handled "
+"It appears that objects can only be pinned via the :file:`cache.config` "
+"file and if the :ts:cv:`proxy.config.cache.permit.pinning` is set to non-"
+"zero (it is zero by default). Objects which are in use when the write "
+"cursor is near use the same underlying evacuation mechanism but are handled "
 "automatically and not via the explicit ``pinned`` bit in :cpp:class:`Dir`."
 msgstr ""
 
@@ -540,8 +540,8 @@ msgstr ""
 msgid ""
 "This means the purpose of expiration data on objects is simply to prevent "
 "them from being served to clients. They are not in the standard sense "
-"deleted or cleaned up. The space can't be immediately reclaimed in any event"
-" because writing only happens at the write cursor. Deleting an object "
+"deleted or cleaned up. The space can't be immediately reclaimed in any "
+"event because writing only happens at the write cursor. Deleting an object "
 "consists only of removing the directory entries in the volume directory "
 "which suffices to (eventually) free the space and render the document "
 "inaccessible."
@@ -567,20 +567,20 @@ msgid ""
 "The cache is designed to be relatively resistant to disk failures. Because "
 "each storage unit in each volume is mostly independent the loss of a disk "
 "simply means that the corresponding :cpp:class:`Vol` instances (one per "
-"cache volume that uses the storage unit) becomes unusable. The primary issue"
-" is updating the volume assignment table to both preserve assignments for "
-"objects on still operational volumes while distributing the assignments from"
-" the failed disk to those operational volumes. This mostly done in::"
+"cache volume that uses the storage unit) becomes unusable. The primary "
+"issue is updating the volume assignment table to both preserve assignments "
+"for objects on still operational volumes while distributing the assignments "
+"from the failed disk to those operational volumes. This mostly done in::"
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:358
 msgid ""
-"Restoring a disk to active duty is quite a bit more difficult task. Changing"
-" the volume assignment of a cache key renders any currently cached data "
-"inaccessible. This is obviouly not a problem when a disk has failed, but is "
-"a bit trickier to decide which cached objects are to be de facto evicted if "
-"a new storage unit is added to a running system. The mechanism for this, if "
-"any, is still under investigation."
+"Restoring a disk to active duty is quite a bit more difficult task. "
+"Changing the volume assignment of a cache key renders any currently cached "
+"data inaccessible. This is obviouly not a problem when a disk has failed, "
+"but is a bit trickier to decide which cached objects are to be de facto "
+"evicted if a new storage unit is added to a running system. The mechanism "
+"for this, if any, is still under investigation."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:361
@@ -726,9 +726,9 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:389
 msgid ""
 "The stripe directory is an array of ``Dir`` instances. Each entry refers to "
-"a span in the volume which contains a cached object. Because every object in"
-" the cache has at least one directory entry this data has been made as small"
-" as possible."
+"a span in the volume which contains a cached object. Because every object "
+"in the cache has at least one directory entry this data has been made as "
+"small as possible."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:391
@@ -840,11 +840,11 @@ msgid ""
 "This value should be chosen so that it is a multiple of a :ref:`cache entry "
 "multiplier <big-mult>`. It is not necessary to make it a power of 2 [#]_. "
 "Larger fragments increase I/O efficiency but lead to more wasted space. The "
-"default size (1M, 2^20) is a reasonable choice in most circumstances altough"
-" in very specific cases there can be benefit from tuning this parameter. "
-"|TS| imposes an internal maximum of a 4194232 bytes which is 4M (2^22) less "
-"the size of a struct :cpp:class:`Doc`. In practice then the largest "
-"reasonable target fragment size is 4M - 262144 = 3932160."
+"default size (1M, 2^20) is a reasonable choice in most circumstances "
+"altough in very specific cases there can be benefit from tuning this "
+"parameter. |TS| imposes an internal maximum of a 4194232 bytes which is 4M "
+"(2^22) less the size of a struct :cpp:class:`Doc`. In practice then the "
+"largest reasonable target fragment size is 4M - 262144 = 3932160."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:432
@@ -853,9 +853,9 @@ msgid ""
 "set to the finest granularity permitted by the size of the fragment. To "
 "determine this consult the :ref:`cache entry multipler <big-mult>` table, "
 "find the smallest maximum size that is at least as large as the fragment. "
-"That will indicate the value of *big* selected and therefore the granularity"
-" of the approximate size. That represents the largest possible amount of "
-"wasted disk I/O when the fragment is read from disk."
+"That will indicate the value of *big* selected and therefore the "
+"granularity of the approximate size. That represents the largest possible "
+"amount of wasted disk I/O when the fragment is read from disk."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:438
@@ -866,8 +866,8 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:439
 msgid ""
-"amount of cache space consumed, is the actual size of the content rounded up"
-" to the disk sector size (default 512 bytes)."
+"amount of cache space consumed, is the actual size of the content rounded "
+"up to the disk sector size (default 512 bytes)."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:444
@@ -897,8 +897,8 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:458
 msgid ""
 "Directory probing is locating a specific directory entry in the stripe "
-"directory based on a cache ID. This is handled primarily by the function "
-":cpp:func:`dir_probe()`. This is passed the cache ID (:arg:`key`), a stripe "
+"directory based on a cache ID. This is handled primarily by the function :"
+"cpp:func:`dir_probe()`. This is passed the cache ID (:arg:`key`), a stripe "
 "(:arg:`d`), and a last collision (:arg:`last_collision`). The last of these "
 "is an in and out parameter, updated as useful during the probe."
 msgstr ""
@@ -918,18 +918,18 @@ msgid ""
 "searched to find a match. In this case a match is detected by comparison of "
 "the bottom 12 bits of the cache ID (the *cache tag*). The search starts at "
 "the base entry for the bucket and then proceeds via the linked list of "
-"entries from that first entry. If a tag match is found and there is no "
-":arg:`collision` then that entry is returned and :arg:`last_collision` is "
+"entries from that first entry. If a tag match is found and there is no :arg:"
+"`collision` then that entry is returned and :arg:`last_collision` is "
 "updated to that entry. If :arg:`collision` is set, then if it isn't the "
-"current match the search continues down the linked list, otherwise "
-":arg:`collision` is cleared and the search continues. The effect of this is "
-"that matches are skipped until the last returned match "
-"(:arg:`last_collision`) is found, after which the next match (if any) is "
-"returned. If the search falls off the end of the linked list then a miss "
-"result is returned (if no last collision), otherwise the probe is restarted "
-"after clearing the collision on the presumption that the entry for the "
-"collision has been removed from the bucket. This can lead to repeats among "
-"the returned values but guarantees that no valid entry will be skipped."
+"current match the search continues down the linked list, otherwise :arg:"
+"`collision` is cleared and the search continues. The effect of this is that "
+"matches are skipped until the last returned match (:arg:`last_collision`) "
+"is found, after which the next match (if any) is returned. If the search "
+"falls off the end of the linked list then a miss result is returned (if no "
+"last collision), otherwise the probe is restarted after clearing the "
+"collision on the presumption that the entry for the collision has been "
+"removed from the bucket. This can lead to repeats among the returned values "
+"but guarantees that no valid entry will be skipped."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:478
@@ -992,11 +992,11 @@ msgid ""
 "parsing and remapping this check is done primarily to detect a negative "
 "result because if so all further cache processing is skipped -- it will not "
 "be put in to the cache nor will a cache lookup be done. There are a number "
-"of prerequisites along with configuration options to change them. Additional"
-" cacheability checks are done later in the process when more is known about "
-"the transaction (such as plugin operations and the origin server response). "
-"Those checks are described as appropriate in the sections on the relevant "
-"operations."
+"of prerequisites along with configuration options to change them. "
+"Additional cacheability checks are done later in the process when more is "
+"known about the transaction (such as plugin operations and the origin "
+"server response). Those checks are described as appropriate in the sections "
+"on the relevant operations."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:501
@@ -1084,9 +1084,9 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:534
 msgid ""
-"Cache valid only if :ts:cv:`proxy.config.http.cache.range.lookup` in "
-":file:`records.config` is non-zero. This does not mean the range request can"
-" be cached, only that it might be satisfiable from the cache."
+"Cache valid only if :ts:cv:`proxy.config.http.cache.range.lookup` in :file:"
+"`records.config` is non-zero. This does not mean the range request can be "
+"cached, only that it might be satisfiable from the cache."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:536
@@ -1127,9 +1127,9 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:549
 msgid ""
-"This is normally computed using the request URL but it can be overridden "
-":ref:`by a plugin <cache-key>` . As far as I can tell the cache index string"
-" is not stored anywhere, it presumed computable from the client request "
+"This is normally computed using the request URL but it can be overridden :"
+"ref:`by a plugin <cache-key>` . As far as I can tell the cache index string "
+"is not stored anywhere, it presumed computable from the client request "
 "header."
 msgstr ""
 
@@ -1152,8 +1152,8 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:557
 msgid ""
-"Various other lookaside directories are checked as well, such as the "
-":ref:`aggregation buffer <aggregation-buffer>`."
+"Various other lookaside directories are checked as well, such as the :ref:"
+"`aggregation buffer <aggregation-buffer>`."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:559
@@ -1164,16 +1164,15 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:561
 msgid ""
-"This is done in :cpp:func:`CacheVC::openReadStartHead()` or "
-":cpp:func:`CacheVC::openReadStartEarliest()` which are tightly coupled "
-"methods."
+"This is done in :cpp:func:`CacheVC::openReadStartHead()` or :cpp:func:"
+"`CacheVC::openReadStartEarliest()` which are tightly coupled methods."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:563
 msgid ""
-"If the lookup succeeds then a more detailed directory entry (struct "
-":cpp:class:`OpenDir`) is created. Note that the directory probe includes a "
-"check for an already extant ``OpenDir`` which if found is returned without "
+"If the lookup succeeds then a more detailed directory entry (struct :cpp:"
+"class:`OpenDir`) is created. Note that the directory probe includes a check "
+"for an already extant ``OpenDir`` which if found is returned without "
 "additional work."
 msgstr ""
 
@@ -1196,10 +1195,10 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:572
 msgid ""
 "There is provision in the code to support \"read while write\", that is "
-"serving an object from cache in one transaction while it is being written in"
-" another. It is unclear to me if this actually works. It must specifically "
-"enabled in :file:`records.config` and if not, a cache read will fail if the "
-"object is currently be written or updated."
+"serving an object from cache in one transaction while it is being written "
+"in another. It is unclear to me if this actually works. It must "
+"specifically enabled in :file:`records.config` and if not, a cache read "
+"will fail if the object is currently be written or updated."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:574
@@ -1231,9 +1230,9 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:584
 msgid ""
-"Next an internal flag (\"needs-revalidate-once\") is checked if the "
-":file:`cache.config` value \"revalidate-after\" is not set, and if set the "
-"object is marked \"stale\"."
+"Next an internal flag (\"needs-revalidate-once\") is checked if the :file:"
+"`cache.config` value \"revalidate-after\" is not set, and if set the object "
+"is marked \"stale\"."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:586
@@ -1271,15 +1270,15 @@ msgid ""
 "The request is served using a standard virtual connection tunnel "
 "(``HttpTunnel``) with the :cpp:class:`CacheVC` acting as the producer and "
 "the client ``NetVC`` acting as the sink. If the request is a range request "
-"this can be modified with a transform to select the appropriate parts of the"
-" object or, if the request contains a single range, it can use the range "
+"this can be modified with a transform to select the appropriate parts of "
+"the object or, if the request contains a single range, it can use the range "
 "acceleration."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:607
 msgid ""
-"Range acceleration is done by consulting a fragment offset table attached to"
-" the earliest ``Doc`` which contains offsets for all fragments past the "
+"Range acceleration is done by consulting a fragment offset table attached "
+"to the earliest ``Doc`` which contains offsets for all fragments past the "
 "first. This allows loading the fragment containing the first requested byte "
 "immediately rather than performing reads on the intermediate fragments."
 msgstr ""
@@ -1290,15 +1289,15 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:614
 msgid ""
-"Writing to cache is handled by an instance of the class "
-":cpp:class:`CacheVC`. This is a virtual connection which receives data and "
-"writes it to cache, acting as a sink. For a standard transaction data "
-"transfers between virtual connections (*VConns*) are handled by "
-":cpp:class:HttpTunnel. Writing to cache is done by attaching a ``CacheVC`` "
-"instance as a tunnel consumer. It therefore operates in parallel with the "
-"virtual connection that transfers data to the client. The data does not flow"
-" to the cache and then to the client, it is split and goes both directions "
-"in parallel. This avoids any data synchronization issues between the two."
+"Writing to cache is handled by an instance of the class :cpp:class:"
+"`CacheVC`. This is a virtual connection which receives data and writes it "
+"to cache, acting as a sink. For a standard transaction data transfers "
+"between virtual connections (*VConns*) are handled by :cpp:class:"
+"HttpTunnel. Writing to cache is done by attaching a ``CacheVC`` instance as "
+"a tunnel consumer. It therefore operates in parallel with the virtual "
+"connection that transfers data to the client. The data does not flow to the "
+"cache and then to the client, it is split and goes both directions in "
+"parallel. This avoids any data synchronization issues between the two."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:0
@@ -1320,8 +1319,8 @@ msgid ""
 "object to write its data to the volume content. The ``CacheVC`` accumulates "
 "data internally until either the transaction is complete or the amount of "
 "data to write exceeds the target fragment size. In the former case the "
-"entire object is submitted to the volume to be written. In the latter case a"
-" target fragment size amount of data is submitted and the ``CacheVC`` "
+"entire object is submitted to the volume to be written. In the latter case "
+"a target fragment size amount of data is submitted and the ``CacheVC`` "
 "continues to operate on subsequent data. The volume in turn places these "
 "write requests in an holding area called the `aggregation buffer`_."
 msgstr ""
@@ -1331,18 +1330,18 @@ msgid ""
 "For objects under the target fragment size there is no consideration of "
 "order, the object is simply written to the volume content. For larger "
 "objects the earliest ``Doc`` is written first and the first ``Doc`` written "
-"last. This provides some detection ability should the object be overwritten."
-" Because of the nature of the write cursor no fragment after the first "
-"fragment (in the earliest ``Doc``) can be overwritten without also "
-"overwriting that first fragment (since we know at the time the object was "
-"finalized in the cache the write cursor was at the position of the first "
-"``Doc``)."
+"last. This provides some detection ability should the object be "
+"overwritten. Because of the nature of the write cursor no fragment after "
+"the first fragment (in the earliest ``Doc``) can be overwritten without "
+"also overwriting that first fragment (since we know at the time the object "
+"was finalized in the cache the write cursor was at the position of the "
+"first ``Doc``)."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:641
 msgid ""
-"It is the responsibility of the ``CacheVC`` to not submit writes that exceed"
-" the target fragment size."
+"It is the responsibility of the ``CacheVC`` to not submit writes that "
+"exceed the target fragment size."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:646
@@ -1375,15 +1374,15 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:654
 msgid ""
 "In every case the metadata for the object must be modified. Because |TS| "
-"never updates data already in the cache this means the first ``Doc`` will be"
-" written to the cache again and the volume directory entry updated. Because "
-"a client request has already been processed the first ``Doc`` has been read "
-"from cache and is in memory. The alternate vector is updated as appropriate "
-"(an entry added or removed, or changed to contain the new HTTP headers), and"
-" then written to disk. It is possible for multiple alternates to be updated "
-"by different ``CacheVC`` instances at the same time. The only contention is "
-"the first ``Doc``, the rest of the data for each alternate is completely "
-"independent."
+"never updates data already in the cache this means the first ``Doc`` will "
+"be written to the cache again and the volume directory entry updated. "
+"Because a client request has already been processed the first ``Doc`` has "
+"been read from cache and is in memory. The alternate vector is updated as "
+"appropriate (an entry added or removed, or changed to contain the new HTTP "
+"headers), and then written to disk. It is possible for multiple alternates "
+"to be updated by different ``CacheVC`` instances at the same time. The only "
+"contention is the first ``Doc``, the rest of the data for each alternate is "
+"completely independent."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:664
@@ -1394,15 +1393,15 @@ msgstr ""
 msgid ""
 "Disk writes to cache are handled through an *aggregation buffer*. There is "
 "one for each :cpp:class:`Vol` instance. To minimize the number of system "
-"calls data is written to disk in units of roughly :ref:`target fragment size"
-" <target-fragment-size>` bytes. The algorithm used is simple - data is piled"
-" up in the aggregation buffer until no more will fit without going over the "
-"targer fragment size, at which point the buffer is written to disk and the "
-"volume directory entries for objects with data in the buffer are updated "
-"with the actual disk locations for those objects (which are determined by "
-"the write to disk action). After the buffer is written it is cleared and "
-"process repeats. There is a special lookup table for the aggregation buffer "
-"so that object lookup can find cache data in that memory."
+"calls data is written to disk in units of roughly :ref:`target fragment "
+"size <target-fragment-size>` bytes. The algorithm used is simple - data is "
+"piled up in the aggregation buffer until no more will fit without going "
+"over the targer fragment size, at which point the buffer is written to disk "
+"and the volume directory entries for objects with data in the buffer are "
+"updated with the actual disk locations for those objects (which are "
+"determined by the write to disk action). After the buffer is written it is "
+"cleared and process repeats. There is a special lookup table for the "
+"aggregation buffer so that object lookup can find cache data in that memory."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:674
@@ -1447,14 +1446,14 @@ msgid ""
 "Evacuation data structures are defined by dividing up the volume content in "
 "to a disjoint and contiguous set of regions of ``EVACUATION_BUCKET_SIZE`` "
 "bytes. The :cpp:member:`Vol::evacuate` member is an array with an element "
-"for each evacuation region. Each element is a doubly linked list of "
-":cpp:class:`EvacuationBlock` instances. Each instance contains a "
-":cpp:class:`Dir` that specifies the fragment to evacuate. It is assumed that"
-" an evacuation block is placed in the evacuation bucket (array element) that"
-" corresponds to the evacuation region in which the fragment is located "
-"although no ordering per bucket is enforced in the linked list (this sorting"
-" is handled during evacuation). Objects are evacuated by specifying the "
-"first or earliest fragment in the evactuation block. The evactuation "
+"for each evacuation region. Each element is a doubly linked list of :cpp:"
+"class:`EvacuationBlock` instances. Each instance contains a :cpp:class:"
+"`Dir` that specifies the fragment to evacuate. It is assumed that an "
+"evacuation block is placed in the evacuation bucket (array element) that "
+"corresponds to the evacuation region in which the fragment is located "
+"although no ordering per bucket is enforced in the linked list (this "
+"sorting is handled during evacuation). Objects are evacuated by specifying "
+"the first or earliest fragment in the evactuation block. The evactuation "
 "operation will then continue the evacuation for subsequent fragments in the "
 "object by adding those fragments in evacuation blocks. Note that the actual "
 "evacuation of those fragments is delayed until the write cursor reaches the "
@@ -1465,11 +1464,11 @@ msgstr ""
 #: ../../arch/cache/cache-arch.en.rst:704
 msgid ""
 "There are two types of evacuations, reader based and forced. The "
-"``EvacuationBlock`` has a reader count to track this. If the reader count is"
-" zero, then it is a forced evacuation and the the target, if it exists, will"
-" be evacuated when the write cursor gets close. If the reader value is non-"
-"zero then it is a count of entities that are currently expecting to be able "
-"to read the object. Readers increment the count when they require read "
+"``EvacuationBlock`` has a reader count to track this. If the reader count "
+"is zero, then it is a forced evacuation and the the target, if it exists, "
+"will be evacuated when the write cursor gets close. If the reader value is "
+"non-zero then it is a count of entities that are currently expecting to be "
+"able to read the object. Readers increment the count when they require read "
 "access to the object, or create the ``EvacuationBlock`` with a count of 1. "
 "When a reader is finished with the object it decrements the count and "
 "removes the ``EvacuationBlock`` if the count goes to zero. If the "
@@ -1480,40 +1479,38 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:712
 msgid ""
-"Evacuation is driven by cache writes, essentially in "
-":cpp:member:`Vol::aggWrite`. This method processes the pending cache virtual"
-" connections that are trying to write to the stripe. Some of these may be "
-"evacuation virtual connections. If so then the completion callback for that "
-"virtual connection is called as the data is put in to the aggregation "
-"buffer."
+"Evacuation is driven by cache writes, essentially in :cpp:member:`Vol::"
+"aggWrite`. This method processes the pending cache virtual connections that "
+"are trying to write to the stripe. Some of these may be evacuation virtual "
+"connections. If so then the completion callback for that virtual connection "
+"is called as the data is put in to the aggregation buffer."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:717
 msgid ""
 "When no more cache virtual connections can be processed (due to an empty "
 "queue or the aggregation buffer filling) then :cpp:member:`Vol::evac_range` "
-"is called to clear the range to be overwritten plus an additional "
-":ts:const:`EVACUATION_SIZE` range. The buckets covering that range are "
-"checked. If there are any items in the buckets a new cache virtual "
-"connection (a \"doc evacuator\") is created and used to read the evacuation "
-"item closest to the write cursor (i.e. with the smallest offset in the "
-"stripe) instead of the aggregation write proceeding. When the read completes"
-" it is checked for validity and if valid, the cache virtual connection for "
-"it is placed at the front of the write queue for the stripe and the write "
-"aggregation resumed."
+"is called to clear the range to be overwritten plus an additional :ts:const:"
+"`EVACUATION_SIZE` range. The buckets covering that range are checked. If "
+"there are any items in the buckets a new cache virtual connection (a \"doc "
+"evacuator\") is created and used to read the evacuation item closest to the "
+"write cursor (i.e. with the smallest offset in the stripe) instead of the "
+"aggregation write proceeding. When the read completes it is checked for "
+"validity and if valid, the cache virtual connection for it is placed at the "
+"front of the write queue for the stripe and the write aggregation resumed."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:725
 msgid ""
 "Before doing a write, the method :cpp:func:`Vol::evac_range()` is called to "
 "start an evacuation. If any fragments are found in the buckets in the range "
-"the earliest such fragment (smallest offset, closest to the write cursor) is"
-" selected and read from disk and the aggregation buffer write is suspended. "
-"The read is done via a cache virtual connection which also effectively "
-"serves as the read buffer. Once the read is complete, that cache virtual "
-"connection instance (the \"doc evacuator\") is place at the front of the "
-"stripe write queue and written out in turn. Because the fragment data is now"
-" in memory it is acceptable to overwrite the disk image."
+"the earliest such fragment (smallest offset, closest to the write cursor) "
+"is selected and read from disk and the aggregation buffer write is "
+"suspended. The read is done via a cache virtual connection which also "
+"effectively serves as the read buffer. Once the read is complete, that "
+"cache virtual connection instance (the \"doc evacuator\") is place at the "
+"front of the stripe write queue and written out in turn. Because the "
+"fragment data is now in memory it is acceptable to overwrite the disk image."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:732
@@ -1527,10 +1524,11 @@ msgstr ""
 msgid ""
 "Updates to the directory are done when the write for the evacuated fragment "
 "completes. Multi-fragment objects are detected after the read completes for "
-"a fragment. If it is not the first fragment then the next fragment is marked"
-" for evacuation (which in turn, when it is read, will pull the subsequent "
-"fragment). The logic doesn't seem to check the length and presumes that the "
-"end of the alternate is when the next key is not in the directory."
+"a fragment. If it is not the first fragment then the next fragment is "
+"marked for evacuation (which in turn, when it is read, will pull the "
+"subsequent fragment). The logic doesn't seem to check the length and "
+"presumes that the end of the alternate is when the next key is not in the "
+"directory."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:740
@@ -1561,13 +1559,13 @@ msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:763
 msgid ""
-"Fragments can also be evacuated through *hit evacuation*. This is configured"
-" by :ts:cv:`proxy.config.cache.hit_evacuate_percent` and "
-":ts:cv:`proxy.config.cache.hit_evacuate_size_limit`. When a fragment is read"
-" it is checked to see if it is close and in front of the write cursor, close"
-" being less than the specified percent of the size of the stripe. If set at "
-"the default value of 10, then if the fragment is withing 10% of the size of "
-"the stripe it is marked for evacuation. This is cleared if the write cursor "
+"Fragments can also be evacuated through *hit evacuation*. This is "
+"configured by :ts:cv:`proxy.config.cache.hit_evacuate_percent` and :ts:cv:"
+"`proxy.config.cache.hit_evacuate_size_limit`. When a fragment is read it is "
+"checked to see if it is close and in front of the write cursor, close being "
+"less than the specified percent of the size of the stripe. If set at the "
+"default value of 10, then if the fragment is withing 10% of the size of the "
+"stripe it is marked for evacuation. This is cleared if the write cursor "
 "passes through the fragment while it remains open (as all open objects are "
 "evacuated). If when the object is closed the fragment is still marked then "
 "it is placed in the appropriate evacuation bucket."
@@ -1581,8 +1579,8 @@ msgstr ""
 msgid ""
 "Initialization starts with an instance of :cpp:class:`Store` reading the "
 "storage configuration file, by default :file:`storage.config`. For each "
-"valid element in the file an instance of :cpp:class:`Span` is created. These"
-" are of basically four types,"
+"valid element in the file an instance of :cpp:class:`Span` is created. "
+"These are of basically four types,"
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:772
@@ -1605,16 +1603,16 @@ msgstr ""
 msgid ""
 "After setting all the `Span` instances they are grouped by device id to "
 "internal linked lists attached to the :cpp:member:`Store::disk` array [#]_. "
-"Spans that refer to the same directory, disk, or raw device are coalesced in"
-" to a single span. Spans that refer to the same file with overlapping "
-"offsets are also coalesced [#]_. This is all done in "
-":c:func:`ink_cache_init()` called during startup."
+"Spans that refer to the same directory, disk, or raw device are coalesced "
+"in to a single span. Spans that refer to the same file with overlapping "
+"offsets are also coalesced [#]_. This is all done in :c:func:"
+"`ink_cache_init()` called during startup."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:781
 msgid ""
-"After configuration initialization the cache processor is started by calling"
-" :ccp:func:`CacheProcessor::start()`. This does a number of things."
+"After configuration initialization the cache processor is started by "
+"calling :ccp:func:`CacheProcessor::start()`. This does a number of things."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:784
@@ -1622,11 +1620,11 @@ msgid ""
 "For each valid span, an instance of :cpp:class:`CacheDisk` is created. This "
 "class is a continuation and so can be used to perform potentially blocking "
 "operations on the span. This what is passed to the AIO threads to be called "
-"when an I/O operation completes. These are then dispatched to AIO threads to"
-" perform storage unit initialization. After all of those have completed, the"
-" resulting storage is distributed across the volumes in "
-":c:func:`cplist_reconfigure`. The :cpp:class:`CacheVol` instances are "
-"created at this time."
+"when an I/O operation completes. These are then dispatched to AIO threads "
+"to perform storage unit initialization. After all of those have completed, "
+"the resulting storage is distributed across the volumes in :c:func:"
+"`cplist_reconfigure`. The :cpp:class:`CacheVol` instances are created at "
+"this time."
 msgstr ""
 
 #: ../../arch/cache/cache-arch.en.rst:790

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/arch/cache/cache-data-structures.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/arch/cache/cache-data-structures.en.po b/doc/locale/ja/LC_MESSAGES/arch/cache/cache-data-structures.en.po
index b00d00f..966b636 100644
--- a/doc/locale/ja/LC_MESSAGES/arch/cache/cache-data-structures.en.po
+++ b/doc/locale/ja/LC_MESSAGES/arch/cache/cache-data-structures.en.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"
@@ -17,9 +17,8 @@ msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:25
 msgid ""
-"An open directory entry. It contains all the information of a "
-":cpp:class:`Dir` plus additional information from the first "
-":cpp:class:`Doc`."
+"An open directory entry. It contains all the information of a :cpp:class:"
+"`Dir` plus additional information from the first :cpp:class:`Doc`."
 msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:29
@@ -40,8 +39,8 @@ msgid ""
 "connected to one or more *consumers*. The tunnel handles events and buffers "
 "so that data moves from producers to consumers. The data, as much as "
 "possible, is kept in reference counted buffers so that copies are done only "
-"when the data is modified or for sources (which acquire data from outside "
-"|TS|) and sinks (which move data to outside |TS|)."
+"when the data is modified or for sources (which acquire data from outside |"
+"TS|) and sinks (which move data to outside |TS|)."
 msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:45
@@ -73,8 +72,8 @@ msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:65
 msgid ""
-"This is the metadata for a single alternate for a cached object. In contains"
-" among other data"
+"This is the metadata for a single alternate for a cached object. In "
+"contains among other data"
 msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:67
@@ -104,8 +103,8 @@ msgstr ""
 #: ../../arch/cache/cache-data-structures.en.rst:82
 msgid ""
 "The number of segments in the volume. This will be roughly the total number "
-"of entries divided by the number of entries in a segment. It will be rounded"
-" up to cover all entries."
+"of entries divided by the number of entries in a segment. It will be "
+"rounded up to cover all entries."
 msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:86
@@ -159,8 +158,8 @@ msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:122
 msgid ""
-"First index key in the document (the index key used to locate this object in"
-" the volume index)."
+"First index key in the document (the index key used to locate this object "
+"in the volume index)."
 msgstr ""
 
 #: ../../arch/cache/cache-data-structures.en.rst:126

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/arch/cache/cache.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/arch/cache/cache.en.po b/doc/locale/ja/LC_MESSAGES/arch/cache/cache.en.po
index 76f7809..d2baa3a 100644
--- a/doc/locale/ja/LC_MESSAGES/arch/cache/cache.en.po
+++ b/doc/locale/ja/LC_MESSAGES/arch/cache/cache.en.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/arch/cache/tier-storage.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/arch/cache/tier-storage.en.po b/doc/locale/ja/LC_MESSAGES/arch/cache/tier-storage.en.po
index 8b1d8b0..80d9f46 100644
--- a/doc/locale/ja/LC_MESSAGES/arch/cache/tier-storage.en.po
+++ b/doc/locale/ja/LC_MESSAGES/arch/cache/tier-storage.en.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"
@@ -25,23 +25,23 @@ msgid ""
 "storage with different properties. This design concerns only mechanism. "
 "Policies to take advantage of these are outside of the scope of this "
 "document. Instead we will presume an *oracle* which implements this policy "
-"and describe the queries that must be answered by the oracle and the effects"
-" of the answers."
+"and describe the queries that must be answered by the oracle and the "
+"effects of the answers."
 msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:33
 msgid ""
 "Beyond avoiding question of tier policy the design is also intended to be "
-"effectively identical to current operations for the case where there is only"
-" one tier."
+"effectively identical to current operations for the case where there is "
+"only one tier."
 msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:36
 msgid ""
 "The most common case for tiers is an ordered list of tiers, where higher "
 "tiers are presumed faster but more expensive (or more limited in capacity). "
-"This is not required. It might be that different tiers are differentiated by"
-" other properties (such as expected persistence). The design here is "
+"This is not required. It might be that different tiers are differentiated "
+"by other properties (such as expected persistence). The design here is "
 "intended to handle both cases."
 msgstr ""
 
@@ -61,15 +61,15 @@ msgstr ""
 msgid ""
 "Each storage unit in :file:`storage.config` can be marked with a *quality* "
 "value which is 32 bit number. Storage units that are not marked are all "
-"assigned the same value which is guaranteed to be distinct from all explicit"
-" values. The quality value is arbitrary from the point of view of this "
-"design, serving as a tag rather than a numeric value. The user (via the "
-"oracle) can impose what ever additional meaning is useful on this value "
+"assigned the same value which is guaranteed to be distinct from all "
+"explicit values. The quality value is arbitrary from the point of view of "
+"this design, serving as a tag rather than a numeric value. The user (via "
+"the oracle) can impose what ever additional meaning is useful on this value "
 "(rating, bit slicing, etc.). In such cases all volumes should be explicitly "
 "assigned a value, as the default / unmarked value is not guaranteed to have "
 "any relationship to explicit values. The unmarked value is intended to be "
-"useful in situations where the user has no interest in tiered storage and so"
-" wants to let Traffic Server automatically handle all volumes as a single "
+"useful in situations where the user has no interest in tiered storage and "
+"so wants to let Traffic Server automatically handle all volumes as a single "
 "tier."
 msgstr ""
 
@@ -79,8 +79,8 @@ msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:60
 msgid ""
-"After a client request is received and processed, volume assignment is done."
-" This would be changed to do volume assignment across all tiers "
+"After a client request is received and processed, volume assignment is "
+"done. This would be changed to do volume assignment across all tiers "
 "simultaneously. For each tier the oracle would return one of four values "
 "along with a volume pointer."
 msgstr ""
@@ -124,48 +124,49 @@ msgstr ""
 #: ../../arch/cache/tier-storage.en.rst:74
 msgid ""
 "The volume returned for the tier must be a volume with the corresponding "
-"tier quality value. In effect the current style of volume assignment is done"
-" for each tier, by assigning one volume out of all of the volumes of the "
-"same quality and returning one of `RW` or `WRITE` depending on whether the "
-"initial volume directory lookup succeeds. Note that as with current volume "
-"assignment it is presumed this can be done from in memory structures (no "
-"disk I/O required)."
+"tier quality value. In effect the current style of volume assignment is "
+"done for each tier, by assigning one volume out of all of the volumes of "
+"the same quality and returning one of `RW` or `WRITE` depending on whether "
+"the initial volume directory lookup succeeds. Note that as with current "
+"volume assignment it is presumed this can be done from in memory structures "
+"(no disk I/O required)."
 msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:79
 msgid ""
 "If the oracle returns `READ` or `RW` for more than one tier, it must also "
-"return an ordering for those tiers (it may return an ordering for all tiers,"
-" ones that are not readable will be ignored). For each tier, in that order, "
-"a read of cache storage is attempted for the object. A successful read locks"
-" that tier as the provider of cached content. If no tier has a successful "
-"read, or no tier is marked `READ` or `RW` then it is a cache miss. Any tier "
-"marked `RW` that fails the read test is demoted to `WRITE`."
+"return an ordering for those tiers (it may return an ordering for all "
+"tiers, ones that are not readable will be ignored). For each tier, in that "
+"order, a read of cache storage is attempted for the object. A successful "
+"read locks that tier as the provider of cached content. If no tier has a "
+"successful read, or no tier is marked `READ` or `RW` then it is a cache "
+"miss. Any tier marked `RW` that fails the read test is demoted to `WRITE`."
 msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:85
 msgid ""
 "If the object is cached every tier that returns `WRITE` receives the object "
-"to store in the selected volume (this includes `RW` returns that are demoted"
-" to `WRITE`). This is a cache to cache copy, not from the origin server. In "
-"this case tiers marked `RW` that are not tested for read will not receive "
-"any data and will not be further involved in the request processing."
+"to store in the selected volume (this includes `RW` returns that are "
+"demoted to `WRITE`). This is a cache to cache copy, not from the origin "
+"server. In this case tiers marked `RW` that are not tested for read will "
+"not receive any data and will not be further involved in the request "
+"processing."
 msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:90
 msgid ""
-"For a cache miss, all tiers marked `WRITE` will receive data from the origin"
-" server connection (if successful)."
+"For a cache miss, all tiers marked `WRITE` will receive data from the "
+"origin server connection (if successful)."
 msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:92
 msgid ""
 "This means, among other things, that if there is a tier with the object all "
-"other tiers that are written will get a local copy of the object, the origin"
-" server will not be used. In terms of implementation, currently a cache "
-"write to a volume is done via the construction of an instance of `CacheVC` "
-"which recieves the object stream. For tiered storage the same thing is done "
-"for each target volume."
+"other tiers that are written will get a local copy of the object, the "
+"origin server will not be used. In terms of implementation, currently a "
+"cache write to a volume is done via the construction of an instance of "
+"`CacheVC` which recieves the object stream. For tiered storage the same "
+"thing is done for each target volume."
 msgstr ""
 
 #: ../../arch/cache/tier-storage.en.rst:97
@@ -198,9 +199,9 @@ msgstr ""
 #: ../../arch/cache/tier-storage.en.rst:114
 msgid ""
 "As an example use, it would be possible to have only one cache volume that "
-"uses tiered storage for a particular set of domains using volume tagging. "
-":file:`hosting.config` would be used to direct those domains to the selected"
-" cache volume. The oracle would check the URL in parallel and return "
+"uses tiered storage for a particular set of domains using volume tagging. :"
+"file:`hosting.config` would be used to direct those domains to the selected "
+"cache volume. The oracle would check the URL in parallel and return "
 "`NO_SALE` for the tiers in the target cache volume for other domains. For "
 "the other tier (that of the unmarked storage units) the oracle would return "
 "`RW` for the tier in all cases as that tier would not be queried for the "

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/arch/index.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/arch/index.en.po b/doc/locale/ja/LC_MESSAGES/arch/index.en.po
index 21620a2..62bc512 100644
--- a/doc/locale/ja/LC_MESSAGES/arch/index.en.po
+++ b/doc/locale/ja/LC_MESSAGES/arch/index.en.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"
@@ -28,8 +28,8 @@ msgid ""
 "ongoing work."
 msgstr ""
 "Traffic Server のオリジナルのアーキテクチャに関するドキュメントは、オープン"
-"ソースプロジェクトへの移行時に失われました。このセクションのドキュメントは"
-"暫定的なものであり、既存のコードを元に書かれています。このドキュメントの目的は"
+"ソースプロジェクトへの移行時に失われました。このセクションのドキュメントは暫"
+"定的なものであり、既存のコードを元に書かれています。このドキュメントの目的は"
 "進行中の作業をより知らせるため、 Traffic Server の側面の高度な説明をすること"
 "です。"
 

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/arch/proposals/hostdb.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/arch/proposals/hostdb.en.po b/doc/locale/ja/LC_MESSAGES/arch/proposals/hostdb.en.po
index 9f34b1d..c9639b0 100644
--- a/doc/locale/ja/LC_MESSAGES/arch/proposals/hostdb.en.po
+++ b/doc/locale/ja/LC_MESSAGES/arch/proposals/hostdb.en.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"
@@ -29,9 +29,9 @@ msgstr ""
 #: ../../arch/proposals/hostdb.en.rst:27
 msgid ""
 "The current implementation is generally considered inadequate, both from a "
-"functionality point of view and difficulty in working with it in other parts"
-" of Traffic Server. As Traffic Server is used in more complex situtations "
-"this inadequacy presents increasing problems."
+"functionality point of view and difficulty in working with it in other "
+"parts of Traffic Server. As Traffic Server is used in more complex "
+"situtations this inadequacy presents increasing problems."
 msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:32
@@ -172,10 +172,10 @@ msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:81
 msgid ""
-"To perform a resolution, a client creates a query object (potentially on the"
-" stack), initializes it with the required data (at least the hostname) and "
-"then starts the resolution. Methods on the query object allow its state and "
-"IP address data to be accessed."
+"To perform a resolution, a client creates a query object (potentially on "
+"the stack), initializes it with the required data (at least the hostname) "
+"and then starts the resolution. Methods on the query object allow its state "
+"and IP address data to be accessed."
 msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:86
@@ -228,8 +228,8 @@ msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:104
 msgid ""
-"A resolver that also has a cache for resolution results. It requires another"
-" resolver instance to perform the actual resolution."
+"A resolver that also has a cache for resolution results. It requires "
+"another resolver instance to perform the actual resolution."
 msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:109
@@ -251,12 +251,11 @@ msgid ""
 "To configuration the resolution, each resolver would be assigned a tag. It "
 "is not, however, sufficient to simply provide the list of resolver tags "
 "because some resolvers require additional configuration. Unfortunately this "
-"will likely require a separate configuration file outside of "
-":file:`records.config`, although we would be able to remove "
-":file:`splitdns.config`. In this case we would need chain start / end "
-"markers around a list of resolver tags. Each tag would the be able to take "
-"additional resolver configuration data. For instance, for a SplitDNS "
-"resolver the nameservers."
+"will likely require a separate configuration file outside of :file:`records."
+"config`, although we would be able to remove :file:`splitdns.config`. In "
+"this case we would need chain start / end markers around a list of resolver "
+"tags. Each tag would the be able to take additional resolver configuration "
+"data. For instance, for a SplitDNS resolver the nameservers."
 msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:121
@@ -278,9 +277,9 @@ msgstr ""
 #: ../../arch/proposals/hostdb.en.rst:129
 msgid ""
 "Adding host file access would be easier as well, as it could be done in a "
-"much more modular fashion and then added to the stack at configuration time."
-" Whether such addresses were cached would be controlled by chain arrangement"
-" rather yet more configuration knobs."
+"much more modular fashion and then added to the stack at configuration "
+"time. Whether such addresses were cached would be controlled by chain "
+"arrangement rather yet more configuration knobs."
 msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:133
@@ -345,9 +344,9 @@ msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:164
 msgid ""
-"It should be possible for a client to provide feedback about addresses "
-"(e.g., the origin server at this address is not available). Not all "
-"resolvers will handle feedback but some will and that must be possible."
+"It should be possible for a client to provide feedback about addresses (e."
+"g., the origin server at this address is not available). Not all resolvers "
+"will handle feedback but some will and that must be possible."
 msgstr ""
 
 #: ../../arch/proposals/hostdb.en.rst:167

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/glossary.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/glossary.en.po b/doc/locale/ja/LC_MESSAGES/glossary.en.po
index 19432d3..a56e237 100644
--- a/doc/locale/ja/LC_MESSAGES/glossary.en.po
+++ b/doc/locale/ja/LC_MESSAGES/glossary.en.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"
@@ -42,9 +42,9 @@ msgstr ""
 #: ../../glossary.en.rst:41
 msgid ""
 "A user defined unit of persistent storage for the cache. Cache volumes are "
-"defined in :file:`volume.config`. A cache volume is by default spread across"
-" :term:`cache span`\\ s to increase robustness. Each section of a cache "
-"volume on a specific cache span is a :term:`cache stripe`."
+"defined in :file:`volume.config`. A cache volume is by default spread "
+"across :term:`cache span`\\ s to increase robustness. Each section of a "
+"cache volume on a specific cache span is a :term:`cache stripe`."
 msgstr ""
 
 #: ../../glossary.en.rst:24
@@ -58,8 +58,9 @@ msgid ""
 "computations are critical to efficient processing of traffic because by "
 "avoiding any blocking operations that wait on external events. In any such "
 "case a continuation is used so that other processing can continue until the "
-"external event occurs. At that point the continuation is invoked to continue"
-" the suspended processing. This can be considered similar to co-routines."
+"external event occurs. At that point the continuation is invoked to "
+"continue the suspended processing. This can be considered similar to co-"
+"routines."
 msgstr ""
 
 #: ../../glossary.en.rst:54
@@ -69,10 +70,9 @@ msgstr ""
 #: ../../glossary.en.rst:56
 msgid ""
 "Verifying that a currently cached object is still valid. This is usually "
-"done using an `If-Modified-Since "
-"<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25>`_ request "
-"which allows the origin server to validate the content without resending the"
-" content."
+"done using an `If-Modified-Since <http://www.w3.org/Protocols/rfc2616/"
+"rfc2616-sec14.html#sec14.25>`_ request which allows the origin server to "
+"validate the content without resending the content."
 msgstr ""
 
 #: ../../glossary.en.rst:31
@@ -101,8 +101,8 @@ msgstr ""
 #: ../../glossary.en.rst:37
 msgid ""
 "A client request and response, either from the origin server or from the "
-"cache. A transaction begins when Traffic Server receives a request, and ends"
-" when Traffic Server sends the response."
+"cache. A transaction begins when Traffic Server receives a request, and "
+"ends when Traffic Server sends the response."
 msgstr ""
 
 #: ../../glossary.en.rst:59

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/b2c6330a/doc/locale/ja/LC_MESSAGES/index.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/index.po b/doc/locale/ja/LC_MESSAGES/index.po
index 53b623f..c159279 100644
--- a/doc/locale/ja/LC_MESSAGES/index.po
+++ b/doc/locale/ja/LC_MESSAGES/index.po
@@ -1,4 +1,4 @@
-# 
+#
 msgid ""
 msgstr ""
 "Project-Id-Version: Apache Traffic Server 4.1\n"
@@ -17,10 +17,11 @@ msgstr ""
 
 #: ../../index.rst:22
 msgid ""
-"Apache Traffic Server™ speeds Internet access, enhances website performance,"
-" and delivers unprecedented web hosting capabilities."
-msgstr "Apache Traffic Server™ はインターネットアクセスを加速させ、ウェブサイトのパフォーマンスを高め、"
-"かつて無いウェブホスティング性能を提供します。"
+"Apache Traffic Server™ speeds Internet access, enhances website "
+"performance, and delivers unprecedented web hosting capabilities."
+msgstr ""
+"Apache Traffic Server™ はインターネットアクセスを加速させ、ウェブサイトのパ"
+"フォーマンスを高め、かつて無いウェブホスティング性能を提供します。"
 
 #: ../../index.rst:26
 msgid "What Is Apache Traffic Server?"
@@ -29,21 +30,20 @@ msgstr "Apache Traffic Server とは?"
 #: ../../index.rst:28
 msgid ""
 "Traffic Server is a high-performance web proxy cache that improves network "
-"efficiency and performance by caching frequently-accessed information at the"
-" edge of the network. This brings content physically closer to end users, "
-"while enabling faster delivery and reduced bandwidth use. Traffic Server is "
-"designed to improve content delivery for enterprises, Internet service "
-"providers (ISPs), backbone providers, and large intranets by maximizing "
-"existing and available bandwidth."
+"efficiency and performance by caching frequently-accessed information at "
+"the edge of the network. This brings content physically closer to end "
+"users, while enabling faster delivery and reduced bandwidth use. Traffic "
+"Server is designed to improve content delivery for enterprises, Internet "
+"service providers (ISPs), backbone providers, and large intranets by "
+"maximizing existing and available bandwidth."
 msgstr ""
-"Traffic Server はハイパフォーマンスなウェブプロキシーキャッシュであり、"
-"それはネットワークの端で頻繁にアクセスされる情報をキャッシュすることにより"
-"ネットワーク効率とパフォーマンスを改善します。これは物理的に近いエンドユーザーにコンテンツを"
-"運ぶ一方で、素早い提供と帯域使用量の削減を可能にします。"
-"Traffic Server は商用のコンテンツ配信やインターネットサービスプロバイダー( ISP )や"
-"バックボーンプロバイダーや巨大なイントラネットを"
-"現行の利用可能な帯域を最大化することで改善するようにデザイン"
-"されています。"
+"Traffic Server はハイパフォーマンスなウェブプロキシーキャッシュであり、それ"
+"はネットワークの端で頻繁にアクセスされる情報をキャッシュすることによりネット"
+"ワーク効率とパフォーマンスを改善します。これは物理的に近いエンドユーザーにコ"
+"ンテンツを運ぶ一方で、素早い提供と帯域使用量の削減を可能にします。Traffic "
+"Server は商用のコンテンツ配信やインターネットサービスプロバイダー( ISP )や"
+"バックボーンプロバイダーや巨大なイントラネットを現行の利用可能な帯域を最大化"
+"することで改善するようにデザインされています。"
 
 #: ../../index.rst:50
 msgid "Indices and tables"