On 12/23/11 04:09, Bruno Haible wrote:
> Personally I use single-quoting (apostrophes) when quoting identifiers
That sounds reasonable, and is less intrusive than
that what I proposed. As I understand it, the idea is to
use "X" when X should be translated, and 'X' when X should
not be translated.
I'll send a gnulib patch along these lines to bug-gnulib.
And attached is a slightly-updated proposal for standards.texi,
which uses single-quotes in the example though it also allows
double-quotes.
Index: standards.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/standards.texi,v
retrieving revision 1.210
diff -u -r1.210 standards.texi
--- standards.texi 23 Dec 2011 00:30:29 -0000 1.210
+++ standards.texi 23 Dec 2011 23:04:53 -0000
@@ -3,7 +3,7 @@
@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate December 22, 2011
+@set lastupdate December 23, 2011
@c %**end of header
@dircategory GNU organization
@@ -2374,7 +2374,7 @@
* System Functions:: Portability and ``standard'' library functions.
* Internationalization:: Techniques for internationalization.
* Character Set:: Use ASCII by default.
-* Quote Characters:: Use `...' in the C locale.
+* Quote Characters:: Use "..." or '...' in the C locale.
* Mmap:: How you can safely use @code{mmap}.
@end menu
@@ -3049,12 +3049,12 @@
around each string that might need translation---like this:
@example
-printf (gettext ("Processing file `%s'..."));
+printf (gettext ("Processing file '%s'..."), file);
@end example
@noindent
This permits GNU gettext to replace the string @code{"Processing file
-`%s'..."} with a translated version.
+'%s'..."} with a translated version.
Once a program uses gettext, please make a point of writing calls to
@code{gettext} when you add new strings that call for translation.
@@ -3130,7 +3130,7 @@
@noindent
The problem with this example is that it assumes that plurals are made
-by adding `s'. If you apply gettext to the format string, like this,
+by adding ``s''. If you apply gettext to the format string, like this,
@example
printf (gettext ("%d file%s processed"), nfiles,
@@ -3139,7 +3139,7 @@
@noindent
the message can use different words, but it will still be forced to use
-`s' for the plural. Here is a better way, with gettext being applied to
+``s'' for the plural. Here is a better way, with gettext being applied to
the two strings independently:
@example
@@ -3185,34 +3185,50 @@
@cindex quote characters
@cindex locale-specific quote characters
@cindex left quote
+@cindex right quote
+@cindex opening quote
+@cindex single quote
+@cindex double quote
@cindex grave accent
+@set txicodequoteundirected
+@set txicodequotebacktick
-In the C locale, GNU programs should stick to plain ASCII for quotation
-characters in messages to users: preferably 0x60 (@samp{`}) for left
-quotes and 0x27 (@samp{'}) for right quotes. It is ok, but not
-required, to use locale-specific quotes in other locales.
-
-The @uref{http://www.gnu.org/software/gnulib/, Gnulib} @code{quote} and
-@code{quotearg} modules provide a reasonably straightforward way to
-support locale-specific quote characters, as well as taking care of
-other issues, such as quoting a filename that itself contains a quote
-character. See the Gnulib documentation for usage details.
-
-In any case, the documentation for your program should clearly specify
-how it does quoting, if different than the preferred method of @samp{`}
-and @samp{'}. This is especially important if the output of your
-program is ever likely to be parsed by another program.
-
-Quotation characters are a difficult area in the computing world at
-this time: there are no true left or right quote characters in Latin1;
-the @samp{`} character we use was standardized there as a grave
-accent. Moreover, Latin1 is still not universally usable.
+In the C locale, the output of GNU programs should stick to plain
+ASCII for quotation characters in messages to users: preferably 0x22
+(@samp{"}) or 0x27 (@samp{'}) for both opening and closing quotes.
+Although GNU programs traditionally used 0x60 (@samp{`}) for opening
+and 0x27 (@samp{'}) for closing quotes, nowadays quotes @samp{`like
+this'} are typically rendered asymmetrically, so quoting @samp{"like
+this"} or @samp{'like this'} typically looks better.
-Unicode contains the unambiguous quote characters required. However,
-Unicode and UTF-8 are not universally well-supported, either.
+It is ok, but not required, for GNU programs to generate
+locale-specific quotes in non-C locales. For example:
-This may change over the next few years, and then we will revisit
-this.
+@example
+printf (gettext ("Processing file '%s'..."), file);
+@end example
+
+@noindent
+Here a French translation might cause @code{gettext} to return the
+string @code{"Traitement de fichier
+@guilsinglleft{}@tie{}%s@tie{}@guilsinglright{}..."}, yielding quotes
+more appropriate for a French locale.
+
+Sometimes a program may need to use opening and closing quotes
+directly. By convention, @code{gettext} translates the string
+@samp{"`"} to the opening quote and the string @samp{"'"} to the
+closing quote, and a program can use these translations. Generally,
+though, it is better to translate quote characters in the context of
+longer strings.
+
+If the output of your program is ever likely to be parsed by another
+program, it is good to provide an option that makes this parsing
+reliable. For example, you could escape special characters using
+conventions from the C language or the Bourne shell. See for example
+the option @option{--quoting-style} of GNU @code{ls}.
+
+@clear txicodequoteundirected
+@clear txicodequotebacktick
@node Mmap
@@ -3585,7 +3601,7 @@
@example
* keyboard.c (menu_bar_items, tool_bar_items)
-(Fexecute_extended_command): Deal with `keymap' property.
+(Fexecute_extended_command): Deal with keymap property.
@end example
When you install someone else's changes, put the contributor's name in
