Author: randy
Date: 2005-12-28 23:15:18 -0700 (Wed, 28 Dec 2005)
New Revision: 5501
Modified:
trunk/BOOK/introduction/important/locale-issues.xml
Log:
Minor fixes to the Locale Related Issues page
Modified: trunk/BOOK/introduction/important/locale-issues.xml
===================================================================
--- trunk/BOOK/introduction/important/locale-issues.xml 2005-12-29 05:52:18 UTC
(rev 5500)
+++ trunk/BOOK/introduction/important/locale-issues.xml 2005-12-29 06:15:18 UTC
(rev 5501)
@@ -66,10 +66,10 @@
<note>
<para>Use of <application>UnZip</application> in the
<application>JDK</application>, <application>Mozilla</application>,
- <application>DocBook</application> or any other BLFS installation
- instructions is not a problem, as these applications never use
+ <application>DocBook</application> or any other BLFS package
+ installation is not a problem, as BLFS instructions never use
<application>UnZip</application> to extract a file with non-ASCII
- characters in its name.</para>
+ characters in the file's name.</para>
</note>
<para>The <application>UnZip</application> package assumes that filenames
@@ -86,14 +86,13 @@
<para>When using <command>unzip</command> to unpack a ZIP archive
containing non-ASCII filenames, the filenames are damaged because
- <command>unzip</command> uses improper conversion when any of
- <replaceable>[SOMETHING NEEDS TO BE PUT HERE AS THE SENTENCE WAS
- INCOMPLETE]</replaceable>. For example, in the ru_RU.KOI8-R locale,
- conversion of filenames from CP866 to KOI8-R is required, but conversion
- from CP850 to ISO-8859-1 is done, which produces filenames consisting of
- undecipherable characters instead of words (the closest equivalent
- understandable example for English-only users is rot13). There are
- several ways around this limitation:</para>
+ <command>unzip</command> uses improper conversion when any of its
+ encoding assumptions are incorrect. For example, in the ru_RU.KOI8-R
+ locale, conversion of filenames from CP866 to KOI8-R is required, but
+ conversion from CP850 to ISO-8859-1 is done, which produces filenames
+ consisting of undecipherable characters instead of words (the closest
+ equivalent understandable example for English-only users is rot13). There
+ are several ways around this limitation:</para>
<para>1) For unpacking ZIP archives with filenames containing non-ASCII
characters, use <ulink url="http://www.winzip.com/";>WinZip</ulink> while
--
http://linuxfromscratch.org/mailman/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
