* faq-using.xml (faq.using.unicode): Modernize.

(faq.api.symlinkstoppedworking): Move here from faq-api.xml.

winsup/doc/ChangeLog

@@ -1,3 +1,8 @@
+2009-03-31  Corinna Vinschen  <corinna@vinschen.de>
+
+	* faq-using.xml (faq.using.unicode): Modernize.
+	(faq.api.symlinkstoppedworking): Move here from faq-api.xml.
+
 2009-03-30  Dave Korn  <dave.korn.cygwin@gmail.com>
 
 	* faq-using.xml (faq.using.bloda):  Update with new entries.

winsup/doc/faq-api.xml

@@ -201,24 +201,6 @@ the environment variable CYGWIN.
 </para>
 </answer></qandaentry>
 
-<qandaentry id="faq.api.symlinkstoppedworking">
-<question><para>Why do some of my old symlinks don't work anymore?</para></question>
-<answer>
-
-<para>Beginning with Cygwin 1.7, Cygwin supports multiple character sets.
-Symlinks created with Cygwin 1.7 are using the UTF-16 character set, which is
-portable across all character sets.  Old symlinks were written using your
-current Windows codepage, which is not portable across all character sets.
-If the target of the symlink doesn't resolve anymore, it's very likely that
-the symlink points to a target filename using native, non-ASCII characters,
-and you're now using another character set than way back when you created
-the symlink.</para>
-
-<para>Solution: Delete the symlink and create it again under you new Cygwin.
-The new symlink will be correctly point to the target no matter what character
-set you're using in future.</para>
-</answer></qandaentry>
-
 <qandaentry id="faq.api.executables">
 <question><para>Why do some files, which are not executables have the 'x' type.</para></question>
 <answer>

winsup/doc/faq-using.xml

@@ -367,19 +367,15 @@ formfeed character to your file.
 <answer>
 
 <para>Internationalization is a complex issue. The short answer is that
-Cygwin relies on the setting of the CYGWIN environment variable as well
+Cygwin relies on the setting of the setting of LANG/LC_xxx environment
-as on the setting of LANG/LC_xxx environment variables.</para>
+variables.</para>
 
-<para>To get UTF-8 support you must set the environment variable CYGWIN
+<para>To get UTF-8 support you must set the LANG, LC_ALL, or LC_CTYPE
-so that it contains the substring "codepage:utf8".  This is required in
+environment variables.  To get UTF-8 support you can set, for instance,
-Cygwin so far to get correct translation from Windows wide character
+$LANG to "en_US.UTF-8".  This will give you support for the UTF-8 character
-filenames to their UTF-8 counterpart.  Applications on the other hand
+set.  Note that the language part has to contain a valid language specifier,
-require the setting of the LANG, LC_ALL, or LC_CTYPE environment variables.
+but is otherwise so far ignored.  There's no support for correct
-To get UTF-8 support you can set, for instance, $LANG to "en_US.UTF-8".
+language-specific collation, monetary or date/time-related
-This will give you support for the UTF-8 character set.  Note that the
-language part has to contain a valid language specifier, but is otherwise
-so far ignored by newlib, the underlying C library.  There's no support
-for correct language-specific collation, monetary or date/time-related
 string handling.  This is planned for a later release, though.</para>
 
 <para>To type international characters (&pound;&auml;&ouml;) in
@@ -391,23 +387,19 @@ string handling.  This is planned for a later release, though.</para>
         set convert-meta off 
         set output-meta on 
 	set input-meta on
-	set kanji-code sjis
 </screen>
 
 <para>These are options to the <literal>readline</literal> library, which
 you can read about in the <literal>bash(1)</literal> and
 <literal>readline(3)</literal> man pages. Other tools that do not use
 <literal>readline</literal> for display, such as <literal>less</literal>
-and <literal>ls</literal>, require additional settings, which could be put
+and <literal>ls</literal>, might require additional settings for doublebyte
-in your <literal>~/.bashrc</literal>:
+or multibyte charsets, which could be put
+in your <literal>~/.bashrc</literal>, for instance:
 <screen>
 alias less='/bin/less -r'
 alias ls='/bin/ls -F --color=tty --show-control-chars'
-export LANG="ja_JP.SJIS"
-export OUTPUT_CHARSET="sjis"
 </screen>
-These examples use the Japanese Shift-JIS character set, obviously
-you will want to change them for your own locale. 
 </para>
 </answer></qandaentry>
 
@@ -975,6 +967,24 @@ Cygwin application providing a native GUI.
 </para>
 </answer></qandaentry>
 
+<qandaentry id="faq.api.symlinkstoppedworking">
+<question><para>Why do some of my old symlinks don't work anymore?</para></question>
+<answer>
+
+<para>Beginning with Cygwin 1.7, Cygwin supports multiple character sets.
+Symlinks created with Cygwin 1.7 are using the UTF-16 character set, which is
+portable across all character sets.  Old symlinks were written using your
+current Windows codepage, which is not portable across all character sets.
+If the target of the symlink doesn't resolve anymore, it's very likely that
+the symlink points to a target filename using native, non-ASCII characters,
+and you're now using another character set than way back when you created
+the symlink.</para>
+
+<para>Solution: Delete the symlink and create it again under you new Cygwin.
+The new symlink will be correctly point to the target no matter what character
+set you're using in future.</para>
+</answer></qandaentry>
+
 <qandaentry id="faq.using.symlinks-samba">
 <question><para>Why don't symlinks work on samba-mounted filesystems?</para></question>
 <answer>