bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC] Suggesting UTF-8 instead of ASCII


From: Ludovic Courtès
Subject: [RFC] Suggesting UTF-8 instead of ASCII
Date: Sat, 05 Jul 2014 22:35:42 +0200
User-agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)

Hello,

I am submitting for discussion the change below, which makes UTF-8 the
recommended encoding instead of ASCII.

I am unsure about the wording, but the intent is to make UTF-8 more
natural, rather than a second choice when “there’s a good reason to do
[it].”

WDYT?

Ludo’.

--- standards.texi.~1.239.~     2014-07-05 22:20:37.000000000 +0200
+++ standards.texi      2014-07-05 22:29:10.000000000 +0200
@@ -3190,18 +3190,17 @@ printf (ngettext ("%d files processed",
 @cindex ASCII characters
 @cindex non-ASCII characters
 
-Sticking to the ASCII character set (plain text, 7-bit characters) is
-preferred in GNU source code comments, text documents, and other
-contexts, unless there is good reason to do something else because of
-the application domain.  For example, if source code deals with the
-French Revolutionary calendar, it is OK if its literal strings contain
-accented characters in month names like ``Flor@'eal''.  Also, it is OK
-(but not required) to use non-ASCII characters to represent proper
-names of contributors in change logs (@pxref{Change Logs}).
-
-If you need to use non-ASCII characters, you should normally stick
-with one encoding, certainly within a single file.  UTF-8 is likely to
-be the best choice.
+The UTF-8 encoding is preferred in GNU source code comments, text
+documents, and other contexts, unless there is a good reason to use
+something else because of the application domain.
+
+UTF-8 is ASCII-compatible, and ASCII has historically been the
+recommended character set in GNU packages.  Yet, UTF-8 makes it
+possible, for instance, to correctly typeset names of contributors in
+change logs, whether or not these are English names.
+
+The GNU C Library has supported UTF-8 locales for years, and most
+editors and tools, both console and graphical, support it as well.
 
 
 @node Quote Characters

reply via email to

[Prev in Thread] Current Thread [Next in Thread]