Here are proposed patches to the gettext manual to address some of
the problems I ran into with coreutils (which I mentioned in the
message I sent out just a minute ago or so).
It'd be nice to have an ngettext variant that works for uintmax_t (and
even intmax_t and/or long double, so long as I'm asking for the moon
:-). Or possibly standard versions of the 'select_plural' function
mentioned below, one each for uintmax_t, intmax_t, and long double.
2006-08-16 Paul Eggert <[EMAIL PROTECTED]>
* gettext.texi (Plural forms): Mention that conversion specs
should agree with ngettext. Talk about greater plurals and
reference Wikipedia. Give suggestions for what to do with
numbers outside the range of unsigned long int.
--- gettext-0.15/gettext-tools/doc/gettext.texi 2006-06-30 07:25:39.000000000
-0700
+++ gettext-0.15-plural/gettext-tools/doc/gettext.texi 2006-08-16
12:20:25.000000000 -0700
@@ -5198,6 +5198,15 @@ printf (ngettext ("%d file removed", "%d
Please note that the numeric value @var{n} has to be passed to the
@code{printf} function as well. It is not sufficient to pass it only to
@code{ngettext}.
+
+When translating format strings, it is usually better to use the same
+conversion specifications in @var{msgid1} and @var{msgid2}, as this
+simplifies the translator's job. For example:
+
[EMAIL PROTECTED]
+/* Avoid usages like this one. */
+printf (ngettext ("one file removed", "%d files removed", n), n);
[EMAIL PROTECTED] smallexample
@end deftypefun
@deftypefun {char *} dngettext (const char [EMAIL PROTECTED], const char
[EMAIL PROTECTED], const char [EMAIL PROTECTED], unsigned long int @var{n})
@@ -5226,6 +5235,56 @@ with every language this is the only via
hardcoding the information in the code (which still would require the
possibility of extensions to not prevent the use of new languages).
+Most people use languages for which this solution is adequate. There
+may be some trouble with languages which have the notion of a greater
+plural, which refers to an abnormally large number for the object of
+discussion, but an idiomatic solution to this problem is beyond the
+current scope of the design. For more on the issue of plurals, please
+see @uref{http://en.wikipedia.org/wiki/Plural, Wikipedia's entry for
+Plural}.
+
+However, there is an implementation problem in invoking functions like
[EMAIL PROTECTED]: what should the programmer do if the number to be
+printed is not equal to an @code{unsigned long int} value? Here are
+some heuristics to address this problem:
+
[EMAIL PROTECTED] @bullet
[EMAIL PROTECTED]
+If the number is floating point, or might be negative, use generic
+wording without @code{ngettext}. One way to do this is to use SI
+symbols (e.g., @samp{gettext ("length = %g mm")}), as these are not
+supposed to use plural forms anyway. Avoid formats like @samp{"%g
+seconds"}, which might expand to ``1 seconds''.
+
[EMAIL PROTECTED]
+If a nonnegative integer argument might be too large to fit in
[EMAIL PROTECTED] long int}, reduce it to a value in range with code like
+this:
+
[EMAIL PROTECTED]
[EMAIL PROTECTED]
+unsigned long int
+select_plural (uintmax_t n)
[EMAIL PROTECTED]
+ return (n <= ULONG_MAX ? n : n % 1000 + 1000);
[EMAIL PROTECTED]
[EMAIL PROTECTED] group
+
[EMAIL PROTECTED]
+void
+print_file_size (uintmax_t bytes)
[EMAIL PROTECTED]
+ printf (ngettext ("%"PRIuMAX" byte", "%"PRIuMAX" bytes",
+ select_plural (bytes)),
+ bytes);
[EMAIL PROTECTED]
[EMAIL PROTECTED] group
[EMAIL PROTECTED] example
+
+The formula @code{n % 1000 + 1000} is a hack, but it works for all
+languages that we currently know about.
[EMAIL PROTECTED] itemize
+
@cindex specifying plural form in a PO file
@kwindex [EMAIL PROTECTED], in a PO file header}
@kwindex [EMAIL PROTECTED], in a PO file header}
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
