translations
This isn't a gnulib question, but this seems like the best set of people to ask :) -- I've recently gotten a couple new po files for Texinfo, but submitted via email instead of through the translation project. I've been telling them to go through the translation project, but now I wonder if that's the general practice, or whether you-all have accepted translations "on the fly"? (I know the turbulent history here, no need to rehash it; I'm just wondering about current procedures.) Thanks, Karl ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: config.h inclusion leftovers
Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > The following patch changes the last files over to the agreed-to style > for inclusion of `config.h'. > > * lib/mkdtemp.c, lib/setenv.c, lib/unsetenv.c: Normalize > inclusion of `config.h'. Applied. Hmm. Just noticed that those files are normally mirrored from gettext (see gnulib/config/srclist.txt). Bruno, would you accept Ralf's patch so we don't have to decouple those files? I noticed some more small differences, when comparing to coreutils copies. We include unconditionally everywhere else. Why not do so here, too? * mkdtemp.c, setenv.c, unsetenv.c: Include unconditionally. How about this additional patch? Index: setenv.c === RCS file: /sources/gnulib/gnulib/lib/setenv.c,v retrieving revision 1.14 diff -u -p -r1.14 setenv.c --- setenv.c24 Feb 2006 10:09:59 - 1.14 +++ setenv.c24 Feb 2006 10:12:13 - @@ -1,4 +1,4 @@ -/* Copyright (C) 1992,1995-1999,2000-2003 Free Software Foundation, Inc. +/* Copyright (C) 1992,1995-1999,2000-2003,2005 Free Software Foundation, Inc. This file is part of the GNU C Library. This program is free software; you can redistribute it and/or modify @@ -27,9 +27,7 @@ #include #include -#if _LIBC || HAVE_UNISTD_H -# include -#endif +#include #if !_LIBC # include "allocsa.h" Index: unsetenv.c === RCS file: /sources/gnulib/gnulib/lib/unsetenv.c,v retrieving revision 1.6 diff -u -p -r1.6 unsetenv.c --- unsetenv.c 24 Feb 2006 10:09:59 - 1.6 +++ unsetenv.c 24 Feb 2006 10:12:13 - @@ -1,4 +1,4 @@ -/* Copyright (C) 1992,1995-1999,2000-2002 Free Software Foundation, Inc. +/* Copyright (C) 1992,1995-1999,2000-2002,2005 Free Software Foundation, Inc. This file is part of the GNU C Library. This program is free software; you can redistribute it and/or modify @@ -29,9 +29,7 @@ extern int errno; #include #include -#if _LIBC || HAVE_UNISTD_H -# include -#endif +#include #if !_LIBC # define __environ environ ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: translations
[EMAIL PROTECTED] (Karl Berry) wrote: > This isn't a gnulib question, but this seems like the best set of people > to ask :) -- I've recently gotten a couple new po files for Texinfo, but > submitted via email instead of through the translation project. > > I've been telling them to go through the translation project, but now I > wonder if that's the general practice, or whether you-all have accepted > translations "on the fly"? > > (I know the turbulent history here, no need to rehash it; I'm just > wondering about current procedures.) Hi Karl, For coreutils, I request that changes/additions go through the translation project. AFAIK, that is the norm. Using the translation project helps because - it requires that they pass the automated tests of the TP robot - it makes the translations available in what may be a more central location. It's probably easier (and less work for us) for translators to update them there. - some packages get the .po files directly from the TP site. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: `illegal' vs `invalid'
> > In the files `getopt.c', `glob.c', and `regexprops-generic.texi' I > > suggest to replace the word `illegal' with `invalid'. > > Not for getopt.c, since POSIX requires the word "illegal" there; Uh, oh, thanks for the information. Werner ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: translations
Hi Karl, > I've been telling them to go through the translation project, but now I > wonder if that's the general practice, or whether you-all have accepted > translations "on the fly"? They should all go through TP, certainly. Apart from the reasons, listed by Jim, there are two more: - TP checks that the translator fills assignment papers, which is especially important for GNU programs. - Other translators from the submitter's team have a chance to revise his work and help him. Regards, Sergey ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: argp.h/argz.h and error_t
Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > The hack below fixes that, but I can imagine that it is not an > acceptable fix, given that this is libc code. Should we rather > AC_DEFINE([__error_t_defined], 1, ..)? Yes, I believe we should. Regards, Sergey ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: config.h inclusion leftovers
Hmm. Just noticed that those files are normally mirrored from gettext (see gnulib/config/srclist.txt). Yes, although I haven't "auto"updated yet because of those differences. Bruno, would you accept Ralf's patch so we don't have to decouple those files? Per Bruno, the checking/mirroring for gettext happens off the latest gettext *release*, not its development sources. So even if Bruno accepts the patches, we have to decouple those files until the next release, if we want the changes in gnulib now. (Personally I'd rather keep mirroring them.) Thanks, k ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
