From: André Malo <nd@apache.org>
Date: Wed, 7 Sep 2005 16:14:29 +0000 (+0000)
Subject: update transformation
X-Git-Tag: 2.3.0~3019
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1769dd1e972e1f3cbf06af4162e6801bf847d719;p=thirdparty%2Fapache%2Fhttpd.git

update transformation


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@279368 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/env.html.ja.euc-jp b/docs/manual/env.html.ja.euc-jp
index 6725ef11baa..3265af2613a 100644
--- a/docs/manual/env.html.ja.euc-jp
+++ b/docs/manual/env.html.ja.euc-jp
@@ -22,6 +22,8 @@
 <a href="./ja/env.html" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="./ko/env.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">This translation may be out of date. Check the
+            English version for recent changes.</div>
 
     <p>Apache HTTP ¥µ¡¼¥Ð¤Ï<em>´Ä¶­ÊÑ¿ô</em>¤È¸Æ¤Ð¤ì¤ë¡¢Ì¾Á°¤Î¤Ä¤¤¤¿
     ÊÑ¿ô¤Ë¾ðÊó¤òµ­²±¤¹¤ë»ÅÁȤߤòÄ󶡤·¤Æ¤¤¤Þ¤¹¡£¤³¤Î¾ðÊó¤Ï¥í¥°¼ý½¸¤ä
diff --git a/docs/manual/faq/all_in_one.html.ja.euc-jp b/docs/manual/faq/all_in_one.html.ja.euc-jp
index e391387b465..c30c367df26 100644
--- a/docs/manual/faq/all_in_one.html.ja.euc-jp
+++ b/docs/manual/faq/all_in_one.html.ja.euc-jp
@@ -22,6 +22,8 @@
 <a href="../ja/faq/all_in_one.html" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/faq/all_in_one.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">This translation may be out of date. Check the
+            English version for recent changes.</div>
 
     <p>Apache ¤Î¼ç¥µ¥¤¥È¡¢&lt;<a href="http://httpd.apache.org/docs-2.1/faq/">http://httpd.apache.org/docs-2.1/faq/</a>&gt;
       ¤«¤éºÇ¿·ÈǤΠFAQ ¤ò¾ï¤Ë¼ê¤ËÆþ¤ì¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£</p>
diff --git a/docs/manual/faq/all_in_one.html.ko.euc-kr b/docs/manual/faq/all_in_one.html.ko.euc-kr
index ef735fd5e10..71eaf523417 100644
--- a/docs/manual/faq/all_in_one.html.ko.euc-kr
+++ b/docs/manual/faq/all_in_one.html.ko.euc-kr
@@ -22,6 +22,8 @@
 <a href="../ja/faq/all_in_one.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/faq/all_in_one.html" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù.
+            ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.</div>
 
     <p>FAQ ÃÖ½ÅÆÇÀº ¾ÆÆÄÄ¡ À¥»çÀÌÆ® &lt;<a href="http://httpd.apache.org/docs-2.1/faq/">http://httpd.apache.org/docs-2.1/faq/</a>&gt;¿¡¼­ º¼ ¼ö
     ÀÖ´Ù.</p>
diff --git a/docs/manual/faq/error.html.ja.euc-jp b/docs/manual/faq/error.html.ja.euc-jp
index 52d25152aeb..1a0580f0b10 100644
--- a/docs/manual/faq/error.html.ja.euc-jp
+++ b/docs/manual/faq/error.html.ja.euc-jp
@@ -22,6 +22,8 @@
 <a href="../ja/faq/error.html" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/faq/error.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">This translation may be out of date. Check the
+            English version for recent changes.</div>
 </div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
diff --git a/docs/manual/faq/error.html.ko.euc-kr b/docs/manual/faq/error.html.ko.euc-kr
index 302749d204c..7e3f6ff714a 100644
--- a/docs/manual/faq/error.html.ko.euc-kr
+++ b/docs/manual/faq/error.html.ko.euc-kr
@@ -22,6 +22,8 @@
 <a href="../ja/faq/error.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/faq/error.html" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù.
+            ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.</div>
 </div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
diff --git a/docs/manual/faq/error.xml.ja b/docs/manual/faq/error.xml.ja
index 08c6a46a026..e202d120e7d 100644
--- a/docs/manual/faq/error.xml.ja
+++ b/docs/manual/faq/error.xml.ja
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="iso-2022-jp" ?>
 <!DOCTYPE faq SYSTEM "../style/faq.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
-<!-- English Revision: 151408:240301 (outdated) -->
+<!-- English Revision: 151408:279314 (outdated) -->
 
 <!--
  Copyright 2004-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/faq/error.xml.ko b/docs/manual/faq/error.xml.ko
index 0e6236ccdd6..adfc7509b20 100644
--- a/docs/manual/faq/error.xml.ko
+++ b/docs/manual/faq/error.xml.ko
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="EUC-KR" ?>
 <!DOCTYPE faq SYSTEM "../style/faq.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 151408:240301 (outdated) -->
+<!-- English Revision: 151408:279314 (outdated) -->
 
 <!--
  Copyright 2004-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/faq/index.html.ja.euc-jp b/docs/manual/faq/index.html.ja.euc-jp
index bdccf74a781..8e91c8de5df 100644
--- a/docs/manual/faq/index.html.ja.euc-jp
+++ b/docs/manual/faq/index.html.ja.euc-jp
@@ -22,6 +22,8 @@
 <a href="../ja/faq/" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/faq/" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">This translation may be out of date. Check the
+            English version for recent changes.</div>
 
     <p>Apache ¤Î¼ç¥µ¥¤¥È¡¢&lt;<a href="http://httpd.apache.org/docs-2.1/faq/">http://httpd.apache.org/docs-2.1/faq/</a>&gt;
       ¤«¤éºÇ¿·ÈǤΠFAQ ¤ò¾ï¤Ë¼ê¤ËÆþ¤ì¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£
diff --git a/docs/manual/faq/index.html.ko.euc-kr b/docs/manual/faq/index.html.ko.euc-kr
index 66ed4b2c94d..f5d5b9589bb 100644
--- a/docs/manual/faq/index.html.ko.euc-kr
+++ b/docs/manual/faq/index.html.ko.euc-kr
@@ -22,6 +22,8 @@
 <a href="../ja/faq/" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/faq/" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù.
+            ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.</div>
 
     <p>FAQ ÃÖ½ÅÆÇÀº ¾ÆÆÄÄ¡ À¥»çÀÌÆ® &lt;<a href="http://httpd.apache.org/docs-2.1/faq/">http://httpd.apache.org/docs-2.1/faq/</a>&gt;¿¡¼­ º¼ ¼ö
     ÀÖ´Ù. ¶Ç, °Ë»öÇÏ°í Ãâ·ÂÇϱâ ÆíÇÏ°Ô FAQ¸¦ <a href="all_in_one.html">ÇÑ ÆäÀÌÁö·Î</a> º¼ ¼ö ÀÖ´Ù.</p>
diff --git a/docs/manual/mod/mod_alias.html.ja.euc-jp b/docs/manual/mod/mod_alias.html.ja.euc-jp
index 0c3ea66a417..0ca29139b4f 100644
--- a/docs/manual/mod/mod_alias.html.ja.euc-jp
+++ b/docs/manual/mod/mod_alias.html.ja.euc-jp
@@ -25,6 +25,8 @@
 <a href="../ja/mod/mod_alias.html" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/mod/mod_alias.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">This translation may be out of date. Check the
+            English version for recent changes.</div>
 <table class="module"><tr><th><a href="module-dict.html#Description">ÀâÌÀ:</a></th><td>¥Û¥¹¥È¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¾å¤Î¤¤¤í¤¤¤í¤Ê°ã¤¦¾ì½ê¤ò
     ¥É¥­¥å¥á¥ó¥È¥Ä¥ê¡¼¤Ë¥Þ¥Ã¥×¤¹¤ëµ¡Ç½¤È¡¢
     URL ¤Î¥ê¥À¥¤¥ì¥¯¥È¤ò¹Ô¤Ê¤¦µ¡Ç½¤òÄ󶡤¹¤ë</td></tr>
diff --git a/docs/manual/mod/mod_alias.html.ko.euc-kr b/docs/manual/mod/mod_alias.html.ko.euc-kr
index e9db1ef9089..994e39a0bf2 100644
--- a/docs/manual/mod/mod_alias.html.ko.euc-kr
+++ b/docs/manual/mod/mod_alias.html.ko.euc-kr
@@ -25,6 +25,8 @@
 <a href="../ja/mod/mod_alias.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/mod/mod_alias.html" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù.
+            ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.</div>
 <table class="module"><tr><th><a href="module-dict.html#Description">¼³¸í:</a></th><td>ÆÄÀϽýºÅÛÀÇ ´Ù¸¥ ºÎºÐµéÀ» ¹®¼­ °èÃþ±¸Á¶¿¡ Æ÷ÇÔÇÏ°í,
     URL ¸®´ÙÀÌ·º¼ÇÀ» Á¦°øÇÑ´Ù</td></tr>
 <tr><th><a href="module-dict.html#Status">»óÅÂ:</a></th><td>Base</td></tr>
diff --git a/docs/manual/mod/mod_log_config.html.en b/docs/manual/mod/mod_log_config.html.en
index 53a4b8c60f4..13def9e76cf 100644
--- a/docs/manual/mod/mod_log_config.html.en
+++ b/docs/manual/mod/mod_log_config.html.en
@@ -124,7 +124,9 @@
         <td>The process ID of the child that serviced the request.</td></tr>
 <tr><td><code>%{<var>format</var>}P</code></td>
         <td>The process ID or thread id of the child that serviced the 
-        request.  Valid formats are <code>pid</code> and <code>tid</code>.
+        request.  Valid formats are <code>pid</code>, <code>tid</code>,
+        and <code>hextid</code>.  <code>hextid</code> requires APR 1.2.0 or 
+        higher.
         </td></tr>
 <tr class="odd"><td><code>%q</code></td>
         <td>The query string (prepended with a <code>?</code> if a query
diff --git a/docs/manual/mod/mod_log_config.html.ja.euc-jp b/docs/manual/mod/mod_log_config.html.ja.euc-jp
index 553fd1f953f..6921e5144b7 100644
--- a/docs/manual/mod/mod_log_config.html.ja.euc-jp
+++ b/docs/manual/mod/mod_log_config.html.ja.euc-jp
@@ -25,6 +25,8 @@
 <a href="../ja/mod/mod_log_config.html" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/mod/mod_log_config.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
 </div>
+<div class="outofdate">This translation may be out of date. Check the
+            English version for recent changes.</div>
 <table class="module"><tr><th><a href="module-dict.html#Description">ÀâÌÀ:</a></th><td>¥µ¡¼¥Ð¤Ø¤Î¥ê¥¯¥¨¥¹¥È¤Î¥í¥®¥ó¥°</td></tr>
 <tr><th><a href="module-dict.html#Status">¥¹¥Æ¡¼¥¿¥¹:</a></th><td>Base</td></tr>
 <tr><th><a href="module-dict.html#ModuleIdentifier">¥â¥¸¥å¡¼¥ë¼±ÊÌ»Ò:</a></th><td>log_config_module</td></tr>
diff --git a/docs/manual/mod/mod_log_config.xml.ja b/docs/manual/mod/mod_log_config.xml.ja
index 3fb595ff77f..bfd666bdd38 100644
--- a/docs/manual/mod/mod_log_config.xml.ja
+++ b/docs/manual/mod/mod_log_config.xml.ja
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="iso-2022-jp"?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 178530 -->
+<!-- English Revision: 178530:265033 (outdated) -->
 
 <!--
  Copyright 2002-2005 The Apache Software Foundation or its licensors, as
diff --git a/docs/manual/mod/mod_log_config.xml.ko b/docs/manual/mod/mod_log_config.xml.ko
index 1a8e2c05c2d..8eab4eb8a98 100644
--- a/docs/manual/mod/mod_log_config.xml.ko
+++ b/docs/manual/mod/mod_log_config.xml.ko
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="EUC-KR" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105989:178530 (outdated) -->
+<!-- English Revision: 105989:265033 (outdated) -->
 
 <!--
  Copyright 2004-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/mod/mod_log_config.xml.meta b/docs/manual/mod/mod_log_config.xml.meta
index 34d03d2b3e8..f9817111e81 100644
--- a/docs/manual/mod/mod_log_config.xml.meta
+++ b/docs/manual/mod/mod_log_config.xml.meta
@@ -7,7 +7,7 @@
 
   <variants>
     <variant>en</variant>
-    <variant>ja</variant>
+    <variant outdated="yes">ja</variant>
     <variant outdated="yes">ko</variant>
   </variants>
 </metafile>
diff --git a/docs/manual/mod/mod_ssl.html.en b/docs/manual/mod/mod_ssl.html.en
index 5fa606763e6..4e092037e0c 100644
--- a/docs/manual/mod/mod_ssl.html.en
+++ b/docs/manual/mod/mod_ssl.html.en
@@ -1180,14 +1180,29 @@ for additional information.
 <tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
 <tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
 </table>
-<p>
-This directive sets the Certificate verification level for the remote server
-Authentication. Notice that this directive can be used both in per-server and
-per-directory context. In per-server context it applies to the remote server
-authentication process used in the standard SSL handshake when a connection is
-established. In per-directory context it forces a SSL renegotation with the
-reconfigured remote server verification level after the HTTP request was read but
-before the HTTP response is sent.</p>
+
+<p>When a proxy is configured to forward requests to a remote SSL
+server, this directive can be used to configure certificate
+verification of the remote server.  Notice that this directive can be
+used both in per-server and per-directory context. In per-server
+context it applies to the remote server authentication process used in
+the standard SSL handshake when a connection is established by the
+proxy. In per-directory context it forces a SSL renegotation with the
+reconfigured remote server verification level after the HTTP request
+was read but before the HTTP response is sent.</p>
+
+<div class="warning">
+<p>Note that even when certificate verification is enabled,
+<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> does <strong>not</strong> check whether the
+<code>commonName</code> (hostname) attribute of the server certificate
+matches the hostname used to connect to the server.  In other words,
+the proxy does not guarantee that the SSL connection to the backend
+server is "secure" beyond the fact that the certificate is signed by
+one of the CAs configured using the
+<code class="directive">SSLProxyCACertificatePath</code> and/or
+<code class="directive">SSLProxyCACertificateFile</code> directives.</p>
+</div>
+
 <p>
 The following levels are available for <em>level</em>:</p>
 <ul>
diff --git a/docs/manual/mod/mpm_common.xml.de b/docs/manual/mod/mpm_common.xml.de
index 12c508ee808..512c8e1b62f 100644
--- a/docs/manual/mod/mpm_common.xml.de
+++ b/docs/manual/mod/mpm_common.xml.de
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?>
-<!-- English Revision: 151408:263854 (outdated) -->
+<!-- English Revision: 151408:264105 (outdated) -->
 
 <!--
  Copyright 2003-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/mod/mpm_common.xml.ja b/docs/manual/mod/mpm_common.xml.ja
index 2512d0232eb..21ec9a99014 100644
--- a/docs/manual/mod/mpm_common.xml.ja
+++ b/docs/manual/mod/mpm_common.xml.ja
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="iso-2022-jp"?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 190982:263854 (outdated) -->
+<!-- English Revision: 190982:264105 (outdated) -->
 
 <!--
  Copyright 2002-2005 The Apache Software Foundation or its licensors, as
diff --git a/docs/manual/new_features_2_2.xml.ko b/docs/manual/new_features_2_2.xml.ko
index 733323c50c8..bb5e1d75ff1 100644
--- a/docs/manual/new_features_2_2.xml.ko
+++ b/docs/manual/new_features_2_2.xml.ko
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='EUC-KR' ?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 105989:263906 (outdated) -->
+<!-- English Revision: 105989:264105 (outdated) -->
 
 <!--
  Copyright 2004-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/new_features_2_2.xml.pt-br b/docs/manual/new_features_2_2.xml.pt-br
index 10a13818a86..669de2f44e3 100644
--- a/docs/manual/new_features_2_2.xml.pt-br
+++ b/docs/manual/new_features_2_2.xml.pt-br
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' ?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.pt-br.xsl"?>
-<!-- English Revision: 151408:263906 (outdated) -->
+<!-- English Revision: 151408:264105 (outdated) -->
 
 <!--
  Copyright 2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/ssl/ssl_intro.html.en b/docs/manual/ssl/ssl_intro.html.en
index 243cf3d70da..4c3f3a9d3c7 100644
--- a/docs/manual/ssl/ssl_intro.html.en
+++ b/docs/manual/ssl/ssl_intro.html.en
@@ -36,13 +36,12 @@ with the Web, HTTP, and Apache, but are not security experts. It is not
 intended to be a definitive guide to the SSL protocol, nor does it discuss
 specific techniques for managing certificates in an organization, or the
 important legal issues of patents and import and export restrictions.
-Rather, it is intended to provide a common background to mod_ssl users by
-pulling together various concepts, definitions, and examples as a starting
-point for further exploration.</p>
+Rather, it is intended to provide a common background to <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> users by pulling together various concepts, definitions, 
+and examples as a starting point for further exploration.</p>
 
-<p>The presented content is mainly derived, with permission by the author,
-from the article <a href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/article.html">Introducing
-SSL and Certificates using SSLeay</a> from <a href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>, of The
+<p>The presented content is mainly derived, with the author's permission,
+from the article <a href="http://home.comcast.net/~fjhirsch/Papers/wwwj/">Introducing
+SSL and Certificates using SSLeay</a> by <a href="http://home.comcast.net/~fjhirsch/">Frederick J. Hirsch</a>, of The
 Open Group Research Institute, which was published in <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
 Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
 Please send any positive feedback to <a href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> (the original
@@ -70,10 +69,10 @@ integrity, and authentication.</p>
     money. Alice would like the message to be private, since it will
     include information such as her account number and transfer amount. One
     solution is to use a cryptographic algorithm, a technique that would
-    transform her message into an encrypted form, unreadable except by
-    those it is intended for. Once in this form, the message may only be
-    interpreted through the use of a secret key. Without the key the
-    message is useless: good cryptographic algorithms make it so difficult
+    transform her message into an encrypted form, unreadable until it is
+    decrypted. Once in this form, the message can only be
+    decrypted by using a secret key. Without the key the message is useless: 
+    good cryptographic algorithms make it so difficult
     for intruders to decode the original text that it isn't worth their
     effort.</p>
 
@@ -84,11 +83,12 @@ integrity, and authentication.</p>
     <dt>Conventional cryptography</dt>
     <dd>also known as symmetric cryptography, requires the sender and
     receiver to share a key: a secret piece of information that may be
-    used to encrypt or decrypt a message. If this key is secret, then
-    nobody other than the sender or receiver may read the message. If
-    Alice and the bank know a secret key, then they may send each other
-    private messages. The task of privately choosing a key before
-    communicating, however, can be problematic.</dd>
+    used to encrypt or decrypt a message. As long as this key is kept 
+    secret, nobody other than the sender or recipient can read the message. 
+    If Alice and the bank know a secret key, then they can send each other
+    private messages. The task of sharing a key between sender and recipient
+    before communicating, while also keeping it secret from others, can be 
+    problematic.</dd>
 
     <dt>Public key cryptography</dt>
     <dd>also known as asymmetric cryptography, solves the key exchange
@@ -99,9 +99,9 @@ integrity, and authentication.</p>
     (the public key) and keeping the other secret (the private key).</dd>
     </dl>
 
-    <p>Anyone may encrypt a message using the public key, but only the
+    <p>Anyone can encrypt a message using the public key, but only the
     owner of the private key will be able to read it. In this way, Alice
-    may send private messages to the owner of a key-pair (the bank), by
+    can send private messages to the owner of a key-pair (the bank), by
     encrypting it using their public key. Only the bank will be able to
     decrypt it.</p>
 
@@ -112,35 +112,42 @@ integrity, and authentication.</p>
     is still a concern that someone might modify her original message or
     substitute it with a different one, in order to transfer the money
     to themselves, for instance. One way of guaranteeing the integrity
-    of Alice's message is to create a concise summary of her message and
-    send this to the bank as well. Upon receipt of the message, the bank
-    creates its own summary and compares it with the one Alice sent. If
-    they agree then the message was received intact.</p>
+    of Alice's message is for her to create a concise summary of her 
+    message and send this to the bank as well. Upon receipt of the message, 
+    the bank creates its own summary and compares it with the one Alice 
+    sent. If the summaries are the same then the message has been received
+    intact.</p>
 
     <p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way
-function</em> or <em>hash function</em>. Message digests are used to create
-short, fixed-length representations of longer, variable-length messages.
-Digest algorithms are designed to produce unique digests for different
-messages. Message digests are designed to make it too difficult to determine
-the message from the digest, and also impossible to find two different
-messages which create the same digest -- thus eliminating the possibility of
-substituting one message for another while maintaining the same digest.</p>
-<p>Another challenge that Alice faces is finding a way to send the digest to the
-bank securely; when this is achieved, the integrity of the associated message
-is assured. One way to do this is to include the digest in a digital
-signature.</p>
+    function</em> or <em>hash function</em>. Message digests are used to create
+    a short, fixed-length representation of a longer, variable-length message.
+    Digest algorithms are designed to produce a unique digests for each
+    message. Message digests are designed to make it impractically difficult 
+    to determine the message from the digest, and (in theory) impossible to 
+    find two different messages which create the same digest -- thus 
+    eliminating the possibility of substituting one message for another while 
+    maintaining the same digest.</p>
+
+    <p>Another challenge that Alice faces is finding a way to send the digest
+    to the bank securely; if the digest is not sent securely, its integrity may
+    be compromised, and with it, the possibility for the bank to determine the
+    integrity of the original message. Only if the digest is sent securely can
+    the integrity of the associated message be determined.</p>
+    
+    <p>One way to send the digest securely is to include it in a digital 
+    signature.</p>
 
 
 <h3><a name="digitalsignatures" id="digitalsignatures">Digital Signatures</a></h3>
 <p>When Alice sends a message to the bank, the bank needs to ensure that the
-message is really from her, so an intruder does not request a transaction
+message is really from her, so an intruder cannot request a transaction
 involving her account. A <em>digital signature</em>, created by Alice and
 included with the message, serves this purpose.</p>
 
 <p>Digital signatures are created by encrypting a digest of the message,
 and other information (such as a sequence number) with the sender's
-private key. Though anyone may <em>decrypt</em> the signature using the public
-key, only the signer knows the private key. This means that only they may
+private key. Though anyone can <em>decrypt</em> the signature using the public
+key, only the sender knows the private key. This means that only they can
 have signed it. Including the digest in the signature means the signature is
 only good for that message; it also ensures the integrity of the message since
 no one can change the digest and still sign it.</p>
@@ -156,13 +163,13 @@ the bank from a fraudulent claim from Alice that she did not send the message
 <p>Although Alice could have sent a private message to the bank, signed
 it, and ensured the integrity of the message, she still needs to be sure
 that she is really communicating with the bank. This means that she needs
-to be sure that the public key she is using corresponds to the bank's
-private key. Similarly, the bank also needs to verify that the message
-signature really corresponds to Alice's signature.</p>
+to be sure that the public key she is using is part of the bank's key-pair, 
+and not an intruder's. Similarly, the bank needs to verify that the message
+signature really was signed by the private key that belongs to Alice.</p>
 
 <p>If each party has a certificate which validates the other's identity,
-confirms the public key, and is signed by a trusted agency, then they both
-will be assured that they are communicating with whom they think they are.
+confirms the public key, and is signed by a trusted agency, then both
+can be assured that they are communicating with whom they think they are.
 Such a trusted agency is called a <em>Certificate Authority</em>, and
 certificates are used for authentication.</p>
 
@@ -241,9 +248,9 @@ certificates are used for authentication.</p>
     <p>A Certificate Authority may define a policy specifying which
     distinguished field names are optional, and which are required. It
     may also place requirements upon the field contents, as may users of
-    certificates. As an example, a Netscape browser requires that the
-    Common Name for a certificate representing a server has a name which
-    matches a wildcard pattern for the domain name of that server, such
+    certificates. For example, a Netscape browser requires that the
+    Common Name for a certificate representing a server matches a wildcard 
+    pattern for the domain name of that server, such
     as <code>*.snakeoil.com</code>.</p>
 
     <p>The binary format of a certificate is defined using the ASN.1
@@ -254,10 +261,9 @@ certificates are used for authentication.</p>
     Rules (DER), which are based on the more general Basic Encoding Rules
     (BER). For those transmissions which cannot handle binary, the binary
     form may be translated into an ASCII form by using Base64 encoding
-    [<a href="#MIME">MIME</a>]. This encoded version is called PEM encoded
-    (the name comes from "Privacy Enhanced Mail"), when placed between
-    begin and end delimiter lines as illustrated in the following
-    example.</p>
+    [<a href="#MIME">MIME</a>]. When placed between begin and end delimiter
+    lines (as below), this encoded version is called a PEM ("Privacy Enhanced
+    Mail") encoded certificate.</p>
 
     <div class="example"><h3>Example of a PEM-encoded certificate (snakeoil.crt)</h3><pre>-----BEGIN CERTIFICATE-----
 MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
@@ -281,12 +287,12 @@ dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
 
 <h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3>
 
-    <p>By first verifying the information in a certificate request
+    <p>By verifying the information in a certificate request
     before granting the certificate, the Certificate Authority assures
-    the identity of the private key owner of a key-pair. For instance,
-    if Alice requests a personal certificate, the Certificate Authority
-    must first make sure that Alice really is the person the certificate
-    request claims.</p>
+    itself of the identity of the private key owner of a key-pair. 
+    For instance, if Alice requests a personal certificate, the 
+    Certificate Authority must first make sure that Alice really is the 
+    person the certificate claims she is.</p>
 
     <h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4>
     
@@ -304,15 +310,15 @@ dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
         <p>As noted earlier, each certificate requires an issuer to assert
         the validity of the identity of the certificate subject, up to
         the top-level Certificate Authority (CA). This presents a problem:
-        Since this is who vouches for the certificate of the top-level
+        who can vouch for the certificate of the top-level
         authority, which has no issuer? In this unique case, the
         certificate is "self-signed", so the issuer of the certificate is
-        the same as the subject. As a result, one must exercise extra care
-        in trusting a self-signed certificate. The wide publication of a
+        the same as the subject. Browsers are preconfigured to trust well-known
+        certificate authorities, but it is important to exercise extra care in
+        trusting a self-signed certificate. The wide publication of a
         public key by the root authority reduces the risk in trusting this
         key -- it would be obvious if someone else publicized a key
-        claiming to be the authority. Browsers are preconfigured to trust
-        well-known certificate authorities.</p>
+        claiming to be the authority.</p>
 
         <p>A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a>
         have established themselves as Certificate Authorities. These
@@ -335,21 +341,25 @@ dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
         <p>Establishing a Certificate Authority is a responsibility which
         requires a solid administrative, technical, and management
         framework. Certificate Authorities not only issue certificates,
-        they also manage them -- that is, they determine how long
-        certificates are valid, they renew them, and they keep lists of
-        certificates that have already been issued but are no longer valid
-        (Certificate Revocation Lists, or CRLs). Say Alice is entitled to
-        a certificate as an employee of a company. Say too, that the
-        certificate needs to be revoked when Alice leaves the company. Since
-        certificates are objects that get passed around, it is impossible
-        to tell from the certificate alone that it has been revoked. When
-        examining certificates for validity, therefore, it is necessary to
-        contact the issuing Certificate Authority to check CRLs -- this
-        is not usually an automated part of the process.</p>
+        they also manage them -- that is, they determine for how long
+        certificates remain valid, they renew them, and they keep lists of
+        certificates that were issued in the past but are no longer valid
+	    (Certificate Revocation Lists, or CRLs).</p> 
+
+        <p>For example, if Alice is entitled to a certificate as an 
+        employee of a company, but has now left
+        that company, her certificate may need to be revoked.
+        Because certificates are only issued after the subject's identity has
+        been verified, and can then be passed around to all those with whom 
+        the subject may communicate, it is impossible to tell from the 
+        certificate alone that it has been revoked. 
+        When examining certificates for validity, therefore, 
+        it is necessary to contact the issuing Certificate Authority to 
+        check CRLs -- this is usually not an automated part of the process.</p>
 
         <div class="note"><h3>Note</h3>
-        <p>If you use a Certificate Authority that is not configured into
-        browsers by default, it is necessary to load the Certificate
+        <p>If you use a Certificate Authority that browsers are not configured
+        to trust by default, it is necessary to load the Certificate
         Authority certificate into the browser, enabling the browser to
         validate server certificates signed by that Certificate Authority.
         Doing so may be dangerous, since once loaded, the browser will
@@ -417,23 +427,23 @@ certificate chain. SSL 3.0 is the basis for the Transport Layer Security
 [<a href="#TLS1">TLS</a>] protocol standard, currently in development by
 the Internet Engineering Task Force (IETF).</p>
 
-<h3><a name="session" id="session">Session Establishment</a></h3>
+<h3><a name="session" id="session">Establishing a Session</a></h3>
 
     <p>The SSL session is established by following a handshake sequence
     between client and server, as shown in <a href="#figure1">Figure 1</a>. This sequence may vary, depending on whether the server
     is configured to provide a server certificate or request a client
-    certificate. Though cases exist where additional handshake steps
+    certificate. Although cases exist where additional handshake steps
     are required for management of cipher information, this article
-    summarizes one common scenario: see the SSL specification for the full
+    summarizes one common scenario. See the SSL specification for the full
     range of possibilities.</p>
 
     <div class="note"><h3>Note</h3>
-    <p>Once an SSL session has been established it may be reused, thus
-    avoiding the performance penalty of repeating the many steps needed
-    to start a session. For this the server assigns each SSL session a
+    <p>Once an SSL session has been established, it may be reused. This
+    avoids the performance penalty of repeating the many steps needed
+    to start a session. To do this, the server assigns each SSL session a
     unique session identifier which is cached in the server and which the
-    client can use on forthcoming connections to reduce the handshake
-    (until the session identifer expires in the cache of the server).</p>
+    client can use in future connections to reduce the handshake time
+    (until the session identifer expires from the cache of the server).</p>
     </div>
 
     <p class="figure">
@@ -452,7 +462,7 @@ the Internet Engineering Task Force (IETF).</p>
     </ol>
 
     <p>The first step, Cipher Suite Negotiation, allows the client and
-    server to choose a Cipher Suite supportable by both of them. The SSL3.0
+    server to choose a Cipher Suite supported by both of them. The SSL3.0
     protocol specification defines 31 Cipher Suites. A Cipher Suite is
     defined by the following components:</p>
 
@@ -470,24 +480,24 @@ the Internet Engineering Task Force (IETF).</p>
     <p>The key exchange method defines how the shared secret symmetric
     cryptography key used for application data transfer will be agreed
     upon by client and server. SSL 2.0 uses RSA key exchange only, while
-    SSL 3.0 supports a choice of key exchange algorithms including the
-    RSA key exchange when certificates are used, and Diffie-Hellman key
-    exchange for exchanging keys without certificates and without prior
-    communication between client and server.</p>
+    SSL 3.0 supports a choice of key exchange algorithms including
+    RSA key exchange (when certificates are used), and Diffie-Hellman key
+    exchange (for exchanging keys without certificates, or without prior
+    communication between client and server).</p>
 
     <p>One variable in the choice of key exchange methods is digital
     signatures -- whether or not to use them, and if so, what kind of
-    signatures to use. Signing with a private key provides assurance
+    signatures to use. Signing with a private key provides protection 
     against a man-in-the-middle-attack during the information exchange
-    used in generating the shared key [<a href="#AC96">AC96</a>, p516].</p>
+    used to generating the shared key [<a href="#AC96">AC96</a>, p516].</p>
 
 
 <h3><a name="ciphertransfer" id="ciphertransfer">Cipher for Data Transfer</a></h3>
 
-    <p>SSL uses the conventional cryptography algorithm (symmetric
-    cryptography) described earlier for encrypting messages in a session.
-    There are nine choices, including the choice to perform no
-    encryption:</p>
+    <p>SSL uses conventional symmetric cryptography, as described earlier, 
+    for encrypting messages in a session.
+    There are nine choices of how to encrypt, including the option not to
+    encrypt:</p>
 
     <ul>
     <li>No encryption</li>
@@ -506,14 +516,13 @@ the Internet Engineering Task Force (IETF).</p>
         </ul></li>
     </ul>
 
-    <p>Here "CBC" refers to Cipher Block Chaining, which means that a
+    <p>"CBC" refers to Cipher Block Chaining, which means that a
     portion of the previously encrypted cipher text is used in the
     encryption of the current block. "DES" refers to the Data Encryption
     Standard [<a href="#AC96">AC96</a>, ch12], which has a number of
-    variants (including DES40 and 3DES_EDE). "Idea" is one of the best
-    and cryptographically strongest available algorithms, and "RC2" is
-    a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>,
-    ch13].</p>
+    variants (including DES40 and 3DES_EDE). "Idea" is currently one of 
+    the best and cryptographically strongest algorithms available, 
+    and "RC2" is a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>, ch13].</p>
 
 
 <h3><a name="digestfuntion" id="digestfuntion">Digest Function</a></h3>
@@ -528,8 +537,8 @@ the Internet Engineering Task Force (IETF).</p>
     </ul>
 
     <p>The message digest is used to create a Message Authentication Code
-    (MAC) which is encrypted with the message to provide integrity and to
-    prevent against replay attacks.</p>
+    (MAC) which is encrypted with the message to verify integrity and to
+    protect against replay attacks.</p>
 
 
 <h3><a name="handshake" id="handshake">Handshake Sequence Protocol</a></h3>
@@ -559,9 +568,9 @@ the Internet Engineering Task Force (IETF).</p>
 
     <p>The encapsulation of SSL control protocols by the record protocol
     means that if an active session is renegotiated the control protocols
-    will be transmitted securely. If there were no session before, then
-    the Null cipher suite is used, which means there is no encryption and
-    messages have no integrity digests until the session has been
+    will be transmitted securely. If there was no previous session,    
+    the Null cipher suite is used, which means there will be no encryption and
+    messages will have no integrity digests, until the session has been
     established.</p>
 
 
@@ -569,11 +578,11 @@ the Internet Engineering Task Force (IETF).</p>
 
     <p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,
     is used to transfer application and SSL Control data between the
-    client and server, possibly fragmenting this data into smaller units,
+    client and server, where necessary fragmenting this data into smaller units,
     or combining multiple higher level protocol data messages into single
     units. It may compress, attach digest signatures, and encrypt these
     units before transmitting them using the underlying reliable transport
-    protocol (Note: currently all major SSL implementations lack support
+    protocol (Note: currently, no major SSL implementations include support
     for compression).</p>
 
     <p class="figure">
@@ -585,11 +594,11 @@ the Internet Engineering Task Force (IETF).</p>
 <h3><a name="securehttp" id="securehttp">Securing HTTP Communication</a></h3>
 
     <p>One common use of SSL is to secure Web HTTP communication between
-    a browser and a webserver. This case does not preclude the use of
-    non-secured HTTP. The secure version is mainly plain HTTP over SSL
-    (named HTTPS), but with one major difference: it uses the URL scheme
-    <code>https</code> rather than <code>http</code> and a different
-    server port (by default 443). This mainly is what <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> provides to you for the Apache webserver...</p>
+    a browser and a webserver. This does not preclude the use of
+    non-secured HTTP - the secure version (called HTTPS) is the same as 
+    plain HTTP over SSL, but uses the URL scheme <code>https</code> 
+    rather than <code>http</code>, and a different server port (by default,
+    port 443). This functionality is a large part of what <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> provides for the Apache webserver.</p>
 
 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
diff --git a/docs/manual/ssl/ssl_intro.html.ja.euc-jp b/docs/manual/ssl/ssl_intro.html.ja.euc-jp
index d8976830213..96eaf8395f9 100644
--- a/docs/manual/ssl/ssl_intro.html.ja.euc-jp
+++ b/docs/manual/ssl/ssl_intro.html.ja.euc-jp
@@ -21,6 +21,8 @@
 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
 <a href="../ja/ssl/ssl_intro.html" title="Japanese">&nbsp;ja&nbsp;</a></p>
 </div>
+<div class="outofdate">This translation may be out of date. Check the
+            English version for recent changes.</div>
 
 <blockquote>
 <p>ɸ½àµ¬³Ê¤ÎÎɤ¤½ê¤Ï¡¢¤¿¤¯¤µ¤ó¤Îµ¬³Ê¤«¤éÁª¤Ù¤ë¤È¤¤¤¦¤³¤È¤À¡£
diff --git a/docs/manual/ssl/ssl_intro.xml.ja b/docs/manual/ssl/ssl_intro.xml.ja
index f88b2d901fa..69b92b5462e 100644
--- a/docs/manual/ssl/ssl_intro.xml.ja
+++ b/docs/manual/ssl/ssl_intro.xml.ja
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='iso-2022-jp' ?>
 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 151408 -->
+<!-- English Revision: 151408:279128 (outdated) -->
 
 <!--
  Copyright 2003-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/ssl/ssl_intro.xml.meta b/docs/manual/ssl/ssl_intro.xml.meta
index da798513f98..0f729114bbf 100644
--- a/docs/manual/ssl/ssl_intro.xml.meta
+++ b/docs/manual/ssl/ssl_intro.xml.meta
@@ -7,6 +7,6 @@
 
   <variants>
     <variant>en</variant>
-    <variant>ja</variant>
+    <variant outdated="yes">ja</variant>
   </variants>
 </metafile>
diff --git a/docs/manual/stopping.html.en b/docs/manual/stopping.html.en
index 085da7f016c..fd246ac526a 100644
--- a/docs/manual/stopping.html.en
+++ b/docs/manual/stopping.html.en
@@ -189,11 +189,13 @@ error. See above for a method of avoiding this.</div>
     <p>The <code>WINCH</code> or <code>graceful-stop</code> signal causes
     the parent process to <em>advise</em> the children to exit after
     their current request (or to exit immediately if they're not
-    serving anything). The parent will then remove it's <code class="directive"><a href="./mod/mpm_common.html#pidfile">PidFile</a></code> and cease listening on
+    serving anything). The parent will then remove its <code class="directive"><a href="./mod/mpm_common.html#pidfile">PidFile</a></code> and cease listening on
     all ports. The parent will continue to run, and monitor children
     which are handling requests. Once all children have finalised
     and exited or the timeout specified by the <code class="directive"><a href="./mod/mpm_common.html#gracefulshutdowntimeout">GracefulShutdownTimeout</a></code> has been
-    reached, the parent will also exit.</p>
+    reached, the parent will also exit.  If the timeout is reached,
+    any remaining children will be sent the <code>TERM</code> signal
+    to force them to exit.</p>
     
     <p>A <code>TERM</code> signal will immediately terminate the 
     parent process and all children when in the "graceful" state. However
diff --git a/docs/manual/stopping.xml.de b/docs/manual/stopping.xml.de
index 4efd0afe74e..adfe0ba8766 100644
--- a/docs/manual/stopping.xml.de
+++ b/docs/manual/stopping.xml.de
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' ?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.de.xsl"?>
-<!-- English Revision: 239255:263857 (outdated) -->
+<!-- English Revision: 239255:264737 (outdated) -->
 
 <!--
  Copyright 2002-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/stopping.xml.es b/docs/manual/stopping.xml.es
index 4af7943838a..89d532219d5 100644
--- a/docs/manual/stopping.xml.es
+++ b/docs/manual/stopping.xml.es
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='UTF-8' ?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.es.xsl"?>
-<!-- English Revision: 105989:263857 (outdated) -->
+<!-- English Revision: 105989:264737 (outdated) -->
 
 <!--
  Copyright 2004-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/stopping.xml.ja b/docs/manual/stopping.xml.ja
index e61e9e75bf2..b9e9498cb26 100644
--- a/docs/manual/stopping.xml.ja
+++ b/docs/manual/stopping.xml.ja
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="iso-2022-jp"?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 151408:263857 (outdated) -->
+<!-- English Revision: 151408:264737 (outdated) -->
 
 <!--
  Copyright 2002-2005 The Apache Software Foundation or its licensors,
diff --git a/docs/manual/stopping.xml.ko b/docs/manual/stopping.xml.ko
index bf26b8da17d..4519da5304e 100644
--- a/docs/manual/stopping.xml.ko
+++ b/docs/manual/stopping.xml.ko
@@ -1,7 +1,7 @@
 <?xml version='1.0' encoding='EUC-KR' ?>
 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 105989:263857 (outdated) -->
+<!-- English Revision: 105989:264737 (outdated) -->
 
 <!--
  Copyright 2003-2005 The Apache Software Foundation or its licensors,