Karl Berry wrote:
Another thing worth mentioning is that it is better to limit strings
to be translated to one number argument per sentence unit (i.e.
"Searched %d directories. Found %d files" or "Searched %d
directories and found %d files" rather than "Found %d files in %d
directories") as so
[EMAIL PROTECTED] (Karl Berry) writes:
> printf ((nfiles != 1 ? "%d files processed"
> : "%d file processed"),
> nfiles);
>
> (unquote)
>
> This has the problem that not all languages treat singular and plural
> the same way as English.
It might be helpful to recom
Hi Michael,
Thanks for writing.
This has the problem that not all languages treat singular and plural
the same way as English.
I see the problem, but what is the solution? Repeating every message
containing a number to have separate cases for so many integers seems
quite impractical.
Seeking advice ... my response follows.
Date: Sun, 14 May 2006 15:47:08 +0200
From: "Michael Thayer" <[EMAIL PROTECTED]>
To: bug-standards@gnu.org
Subject: GNU Coding Standards, internatialisation and plurals
Hello,
I would like to point out a problem with your advise on writing
strings in progr
I thought this was more commonly known
Not by me.
I'm unsure if it's worth bothering.
As always, I'd rather not occupy rms' time if we can avoid it.
In the absence of any clamor to make this tiny change in the GNU
standards.texi, I'd rather skip it.
Thanks,
karl
Bruno Haible <[EMAIL PROTECTED]> writes:
>http://www.linux.com/article.pl?sid=05/12/16/2051201
>
> Nicely written article, IMO.
Yes, it's unusual to have a reporter do that good a job.
I did have a beef with the conclusion "you should not use it [gnulib]
in critical software". "cp" isn't cr
Karl Berry wrote:
> * doc/standards.texi (System Portability): Spell out `free BSD
> variants', instead of using the term `*BSD'.
>
> Before I bother rms with this, can you please explain to me the
> objection to "*BSD"? I'd never heard that before. NetBSD and OpenBSD
> do
gnulib is getting exposed to a larger audience:
http://www.linux.com/article.pl?sid=05/12/16/2051201
Nicely written article, IMO.
Bruno
>>> Would WOE32_NATIVE be a better name?
>>
>> Many people believe code should be neutral.
OK, but WIN32_NATIVE isn't neutral either; it connotes "win".
> How about W32_NATIVE then? I believe that some other GNU code
> uses w32 as a "32-bit Windows" prefix.
That'd be OK.
Hi Karl,
* Karl Berry wrote on Fri, May 19, 2006 at 07:19:41PM CEST:
>
> * doc/standards.texi (System Portability): Spell out `free BSD
> variants', instead of using the term `*BSD'.
>
> Before I bother rms with this, can you please explain to me the
> objection to "*BSD"
Bruno Haible <[EMAIL PROTECTED]> writes:
> Since gnulib's policy is to let the programs write code in POSIX
> syntax, I vote for a module that creates a file in
> the build directory.
Yes, that would make sense, to properly declare 'select'. For
nanosleep I suppose we'd also need a substitute t
Hi Ralf,
* doc/standards.texi (System Portability): Spell out `free BSD
variants', instead of using the term `*BSD'.
Before I bother rms with this, can you please explain to me the
objection to "*BSD"? I'd never heard that before. NetBSD and OpenBSD
don't like being lump
Bruno Haible <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> > In other places I used to define WIN32 as an abbreviation of
>> > defined _WIN32 || defined __WIN32__
>> > Now I'm renaming that to WIN32_NATIVE.
>>
>> Would WOE32_NATIVE be a better name?
>
> Many people believe code should b
Jim Meyering wrote:
> That is because it's looking in the wrong place.
> This patch fixes the immediate problem
Indeed, thanks. But the bug is really in the AC_FUNC_GETLOADAVG macro in
autoconf.
The macros
AC_FUNC_ERROR_AT_LINE, AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK,
AC_FUNC_MALLOC, AC_FU
* Bruno Haible wrote on Fri, May 19, 2006 at 03:07:01PM CEST:
> Paul Eggert wrote:
> >
> > Would WOE32_NATIVE be a better name?
>
> Many people believe code should be neutral.
FWIW, I agree. After all, POSIX_ME_HARDER was dropped, too.
I removed occurrences of M$VC and *BSD from the Libtool sour
Paul Eggert wrote:
> > In other places I used to define WIN32 as an abbreviation of
> > defined _WIN32 || defined __WIN32__
> > Now I'm renaming that to WIN32_NATIVE.
>
> Would WOE32_NATIVE be a better name?
I don't know. I use the term "Woe32" when I talk about the platform which is
not a wi
Jim Meyering wrote:
> It'd be great if someone would write a gnulib-style getgrouplist
> replacement function that provides a poor-man's implementation (using
> something like coreutils' existing code) for systems that lack a useful
> function by that name.
Here is an implementation of the getgrou
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This fixes an outdated comment in getugroups.c. getgrent et al. are part
> of POSIX/XSI since the Base Specifications Version 5.
Applied. Thanks.
This fixes an outdated comment in getugroups.c. getgrent et al. are part
of POSIX/XSI since the Base Specifications Version 5.
*** gnulib-20060430/lib/getugroups.c2005-09-23 06:15:13.0 +0200
--- gnulib-20060430-modified/lib/getugroups.c 2006-05-19 00:46:28.0
+0200
**
Simon Josefsson wrote:
> Wouldn't this be a good situation to have nanosleep depend on the
> unistd module, and make the replacement unistd.h include winsock2.h on
> mingw32 platforms? After all, nanosleep.c include unistd.h, and
> unistd.h define select on some platforms.
But is not supposed to
Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
> Wouldn't this be a good situation to have nanosleep depend on the
> unistd module, and make the replacement unistd.h include winsock2.h on
> mingw32 platforms? After all, nanosleep.c include unistd.h, and
> unistd.h define select on some platforms.
21 matches
Mail list logo
