public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: other/2857: i18n, translations does not work
@ 2001-05-23 10:36 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-05-23 10:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: Mark Mitchell <mark@codesourcery.com>
Cc: <zackw@Stanford.EDU>, Philipp Thomas <pthomas@suse.de>,
<Gabriel.Dos-Reis@cmla.ens-cachan.fr>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Wed, 23 May 2001 19:26:22 +0200 (CEST)
On Wed, 23 May 2001, Mark Mitchell wrote:
> I would very much prefer that *no* generated files be in CVS, but I
> don't understand internationalization at all. :-) If the pot file can
> be generated, I agree that we shouldn't have it in CVS.
I have now looked more into this. I hade trouble compiling before and that
was because I built inside the source directory, and that does not work.
(I knew that, but had forgot since the last time)
Another misstake I did was to use the HEAD branch instead of the
gcc-3_0-branch.
Now some information about the problem in gcc/po/ (gcc-3_0-branch):
1. POTFILE.in
Contains files that does not exist any more. Every
time a file gets deleted or when a file that contains
strings to be translated is added, one must update
POTFILE.in
Now I had to remove the entries:
frame-dwarf2.c
frame.c
There is probably some files missing meaning that there will
be strings in gcc not marked for translation. But we can't know
which until we have a full translation and gets output that is
not translated, or if someone goes through all gcc source files
searching for it. But I want volenter for that.
2. Makefile.in.in
The --defines flag to xgettext must be deleted since it does
not exist.
3. gcc.pot
Can be deleted from the cvs since it can be recreated with
a "make update-po" in the po directory.
Now when I do it the size of this file is comparabel with
the size of the cvs version so I guess they are almost
the same. The cvs version is 9 months old so you
can't really expect them to be exactly the same. Some
strings surely have changed during this time :-)
4. When one builds the files outside the source directory
one expects that the source directory should not be
altered. In the case of gcc.pot it's not true and this
file is created in the source directory.
The patch seems to work and now that I can compile, and when I have
checked out the right branch I can restart the work with the translation.
I've been waiting 9 months for this :-)
--
/Dennis
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-06-13 0:56 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-06-13 0:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: Zack Weinberg <zackw@Stanford.EDU>
Cc: Mark Mitchell <mark@codesourcery.com>, Philipp Thomas <pthomas@suse.de>,
<Gabriel.Dos-Reis@cmla.ens-cachan.fr>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Wed, 13 Jun 2001 09:46:08 +0200 (CEST)
On Thu, 24 May 2001, Zack Weinberg wrote:
> On the other hand, it might be more useful to have a known place to
> work from, which would argue for leaving gcc.pot in CVS and updating
> it periodically.
But you dont ever want to have a known place to start from that is not up
to date. Then you would just translate strings that would never be used
anyway since they are removed or change in the source (but still in the
gcc.pot since it's old). You always want to update your .po file when you
start translate.
And you can not have some automatic update of the .po file, since they are
checked out by the translator and if it's updated while he is translating
then there will be a conflict when he tries to commit his changes. So you
don't want to update during translation.
All other projects I've seen keep the .pot file out of the cvs and lets
the translators update their .po files themself.
I also think the fsf way of having a central place where you put .pot
files to translate is broken for big programs. Translations needs to be
tested and there is usually a lot of errors in the code that one finds
first when one do translations. The last week Zach found 1000 more strings
that where not marked for translation before. And there are a lot of
constructs in gcc where the output string is created dynamically in gcc
that only works in english. You don't see the problem until you start to
work on it. And to wait until a release and to put a .pot file on the fsf
ftp site and hope it will work is too much to hope for (at least for big
programs like gcc). Also remember that a gcc translation is a 400k file
with almost 4000 strings to translate.
I don't see why the .po files should be treated any different then other
source files. They need to be updated incrementally, and for that cvs is
usefull.
--
/Dennis
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 8:16 Zack Weinberg
0 siblings, 0 replies; 30+ messages in thread
From: Zack Weinberg @ 2001-05-25 8:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Philipp Thomas <pthomas@suse.de>, Dennis Bjorklund <db@zigo.dhs.org>,
Mark Mitchell <mark@codesourcery.com>, Gabriel.Dos-Reis@cmla.ens-cachan.fr,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 08:10:33 -0700
On Fri, May 25, 2001 at 10:51:12AM +0100, Joseph S. Myers wrote:
> On Fri, 25 May 2001, Philipp Thomas wrote:
>
> > > Question: do the release scripts need to generate the compiled .gmo files?
> > > As those are binary, we surely don't want to put them in CVS.
> >
> > Yes, they would need to do so, according to GNU standards, as the user
> > should not need to have the tools to create them.
>
> Since it looks like the Makefiles by default create catalogs in the build
> directory, could you make the necessary changes - either to the release
> script Mark posted, or to the Makefiles to build them in the source
> directory instead - for them to be included in release tarballs?
May I suggest that the Makefiles continue to drop compiled catalogs in
the build directory, and the release script move them to the source
directory? We've just been through another cycle of complaints about
all the crap that gets written into the source directory.
The changes I'm testing handle this case fine.
--
zw It may of course be possible that risks-awareness and extreme care are
developed in the course of dancing with the fuckup fairy in the pale
moonlight.
-- Anthony de Boer
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 8:06 Zack Weinberg
0 siblings, 0 replies; 30+ messages in thread
From: Zack Weinberg @ 2001-05-25 8:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Philipp Thomas <pthomas@suse.de>, Dennis Bjorklund <db@zigo.dhs.org>,
Mark Mitchell <mark@codesourcery.com>, Gabriel.Dos-Reis@cmla.ens-cachan.fr,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Cc:
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 08:03:47 -0700
On Fri, May 25, 2001 at 11:35:51AM +0200, Philipp Thomas wrote:
>
> The problem is, that you can't do the check unconditionally.
>
> As it is, POTFILES.in lists all files that contain messages, excluding only
> those files, that should not be translated because they either belong to
> tools used to create gcc (like the gen* tools) or belong to debugging
> facilities. The check as to whether POTFILES.in is current can only be made
> if you have a complete source tree. But GCC is also available in split-up
> packages, and there the check would fail.
>
> What would be needed for doing the check unconditionally is a mechanism to
> create POTFILES.in from language specific fragments. I've tried to come up
> with a solution but so far haven't succeeded.
This is a non-problem, because the only people who ever need to
regenerate gcc.pot can be expected to have the complete source tree.
Under normal conditions the shipped .po files are converted directly
to .mo files without reference to the source code.
And POTFILES has no purpose except to regenerate gcc.pot.
I'm presently testing patches which eliminate POTFILES entirely.
Considerable violence is done to the intl and po Makefiles, but the
result is *much* cleaner, IMO.
--
zw But your argument is simply post hoc ergo ante hoc.
-- Umberto Eco, _Foucault's Pendulum_
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 3:26 Joseph S. Myers
0 siblings, 0 replies; 30+ messages in thread
From: Joseph S. Myers @ 2001-05-25 3:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Philipp Thomas <pthomas@suse.de>
Cc: Dennis Bjorklund <db@zigo.dhs.org>, Zack Weinberg <zackw@Stanford.EDU>,
Mark Mitchell <mark@codesourcery.com>,
<Gabriel.Dos-Reis@cmla.ens-cachan.fr>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 11:16:42 +0100 (BST)
On Fri, 25 May 2001, Philipp Thomas wrote:
> Do you by chance have the URL to Marks post? Anyway, as I'm about to check
> in patches that bring the i18n machinery up to the gettext 0.10.37 level,
> I'll also do the changes for a correct release.
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01778.html
contrib/gcc_release on the branch (though I think that after 3.0 is
released this should go in maintainer-scripts on the mainline).
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 3:06 Philipp Thomas
0 siblings, 0 replies; 30+ messages in thread
From: Philipp Thomas @ 2001-05-25 3:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Philipp Thomas <pthomas@suse.de>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Dennis Bjorklund <db@zigo.dhs.org>,
Zack Weinberg <zackw@Stanford.EDU>,
Mark Mitchell <mark@codesourcery.com>,
Gabriel.Dos-Reis@cmla.ens-cachan.fr, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 12:00:05 +0200
* Joseph S. Myers (jsm28@cam.ac.uk) [20010525 11:51]:
> Since it looks like the Makefiles by default create catalogs in the build
> directory, could you make the necessary changes - either to the release
> script Mark posted, or to the Makefiles to build them in the source
> directory instead - for them to be included in release tarballs?
Do you by chance have the URL to Marks post? Anyway, as I'm about to check
in patches that bring the i18n machinery up to the gettext 0.10.37 level,
I'll also do the changes for a correct release.
Philipp
--
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany
Penguins shall save the dinosaurs
-- Handelsblatt about Linux on S/390
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 2:56 Joseph S. Myers
0 siblings, 0 replies; 30+ messages in thread
From: Joseph S. Myers @ 2001-05-25 2:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Philipp Thomas <pthomas@suse.de>
Cc: Dennis Bjorklund <db@zigo.dhs.org>, Zack Weinberg <zackw@Stanford.EDU>,
Mark Mitchell <mark@codesourcery.com>,
<Gabriel.Dos-Reis@cmla.ens-cachan.fr>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 10:51:12 +0100 (BST)
On Fri, 25 May 2001, Philipp Thomas wrote:
> > Question: do the release scripts need to generate the compiled .gmo files?
> > As those are binary, we surely don't want to put them in CVS.
>
> Yes, they would need to do so, according to GNU standards, as the user
> should not need to have the tools to create them.
Since it looks like the Makefiles by default create catalogs in the build
directory, could you make the necessary changes - either to the release
script Mark posted, or to the Makefiles to build them in the source
directory instead - for them to be included in release tarballs?
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 2:46 Philipp Thomas
0 siblings, 0 replies; 30+ messages in thread
From: Philipp Thomas @ 2001-05-25 2:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Philipp Thomas <pthomas@suse.de>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Dennis Bjorklund <db@zigo.dhs.org>,
Zack Weinberg <zackw@Stanford.EDU>,
Mark Mitchell <mark@codesourcery.com>,
Gabriel.Dos-Reis@cmla.ens-cachan.fr, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 11:45:33 +0200
* Joseph S. Myers (jsm28@cam.ac.uk) [20010524 14:25]:
> The first priority is presumably getting up to date translations for the
> 3.0 branch (and putting those on mainline as well, for now), before
> translating 3.1.
The correct way of doing that would be to send the current gcc.pot to the
translation robot. The robot in turn will give notice to the translation
teams that a new file is available for translation.
> Question: do the release scripts need to generate the compiled .gmo files?
> As those are binary, we surely don't want to put them in CVS.
Yes, they would need to do so, according to GNU standards, as the user
should not need to have the tools to create them.
Philipp
--
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany
Penguins shall save the dinosaurs
-- Handelsblatt about Linux on S/390
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 2:46 Philipp Thomas
0 siblings, 0 replies; 30+ messages in thread
From: Philipp Thomas @ 2001-05-25 2:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Philipp Thomas <pthomas@suse.de>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Zack Weinberg <zackw@Stanford.EDU>,
Dennis Bjorklund <db@zigo.dhs.org>,
Mark Mitchell <mark@codesourcery.com>,
Gabriel.Dos-Reis@cmla.ens-cachan.fr, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 11:40:48 +0200
* Joseph S. Myers (jsm28@cam.ac.uk) [20010524 09:48]:
> though we should, at least, have a defined tag in the repository (maybe a
> snapshot or release tag) for the sources from which a .pot was generated,
> if the .pot doesn't go in CVS.
François Pinoir and I came to an agreement how to name the file according to
the snapshot it was taken from. Now that additional volunteers help
François maintaining the translation project, I'll submit the gcc.pot from
one of the next snapshots.
Philipp
--
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany
Penguins shall save the dinosaurs
-- Handelsblatt about Linux on S/390
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-25 2:46 Philipp Thomas
0 siblings, 0 replies; 30+ messages in thread
From: Philipp Thomas @ 2001-05-25 2:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Philipp Thomas <pthomas@suse.de>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Mark Mitchell <mark@codesourcery.com>, zackw@Stanford.EDU,
Gabriel.Dos-Reis@cmla.ens-cachan.fr, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Fri, 25 May 2001 11:35:51 +0200
* Dennis Bjorklund (db@zigo.dhs.org) [20010523 19:26]:
> Contains files that does not exist any more. Every
> time a file gets deleted or when a file that contains
> strings to be translated is added, one must update
> POTFILE.in
The problem is, that you can't do the check unconditionally.
As it is, POTFILES.in lists all files that contain messages, excluding only
those files, that should not be translated because they either belong to
tools used to create gcc (like the gen* tools) or belong to debugging
facilities. The check as to whether POTFILES.in is current can only be made
if you have a complete source tree. But GCC is also available in split-up
packages, and there the check would fail.
What would be needed for doing the check unconditionally is a mechanism to
create POTFILES.in from language specific fragments. I've tried to come up
with a solution but so far haven't succeeded.
> 3. gcc.pot
>
> Can be deleted from the cvs since it can be recreated with
> a "make update-po" in the po directory.
Yes, it can, but again *only* if you have the complete source tree.
> 4. When one builds the files outside the source directory
> one expects that the source directory should not be
> altered. In the case of gcc.pot it's not true and this
> file is created in the source directory.
I'm ATM testing patches that upgrades the i18n machinery to the current
0.10.37 level. The Makefile.in.in will build gcc.pot in objdir.
Philipp
--
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany
Penguins shall save the dinosaurs
-- Handelsblatt about Linux on S/390
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 10:26 Zack Weinberg
0 siblings, 0 replies; 30+ messages in thread
From: Zack Weinberg @ 2001-05-24 10:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>, Gabriel.Dos-Reis@cmla.ens-cachan.fr,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 10:16:20 -0700
On Thu, May 24, 2001 at 06:22:09PM +0200, Dennis Bjorklund wrote:
> I found some more strings that are in the .po file that does not show up
> translated:
>
> $ gcc-3.0 --target-help
>
> Speciella flaggor f?r m?larkitektur:
> -m96bit-long-double sizeof(long double) is 12.
> -m128bit-long-double sizeof(long double) is 16.
> <...>
Patch follows. The changes to display_help won't do any good until
someone goes and puts N_() around all the strings in the various
arrays, but that's a mechanical change which would make this patch
much longer, so I'm not doing it now.
--
zw This notion of the domain specificity of information is, patently, of
no use to anybody. I mention it simply to get it out of the way.
-- Jerry Fodor, _The Mind Doesn't Work That Way_
* toplev.c (display_help, display_target_options): Run option
descriptions through gettext.
===================================================================
Index: toplev.c
--- toplev.c 2001/05/19 17:55:48 1.420.2.22
+++ toplev.c 2001/05/24 17:13:42
@@ -3828,7 +3828,7 @@ display_help ()
if (description != NULL && * description != 0)
printf (" -f%-21s %s\n",
- f_options[i].string, description);
+ f_options[i].string, _(description));
}
printf (_(" -O[number] Set optimisation level to [number]\n"));
@@ -3842,7 +3842,7 @@ display_help ()
printf (" --param %s=<value>%.*s%s\n",
compiler_params[i].option,
length > 0 ? length : 1, " ",
- description);
+ _(description));
}
printf (_(" -pedantic Issue warnings needed by strict compliance to ISO C\n"));
printf (_(" -pedantic-errors Like -pedantic except that errors are produced\n"));
@@ -3855,7 +3855,7 @@ display_help ()
if (description != NULL && * description != 0)
printf (" -W%-21s %s\n",
- W_options[i].string, description);
+ W_options[i].string, _(description));
}
printf (_(" -Wunused Enable unused warnings\n"));
@@ -3877,7 +3877,7 @@ display_help ()
{
if (debug_args[i].description != NULL)
printf (" -g%-21s %s\n",
- debug_args[i].arg, debug_args[i].description);
+ debug_args[i].arg, _(debug_args[i].description));
}
printf (_(" -aux-info <file> Emit declaration info into <file>.X\n"));
@@ -3932,7 +3932,7 @@ display_help ()
lang = description;
}
else
- printf (" %-23.23s %s\n", option, description);
+ printf (" %-23.23s %s\n", option, _(description));
}
}
@@ -3975,7 +3975,7 @@ display_target_options ()
printf (_(" -m%-23.23s [undocumented]\n"), option);
}
else if (* description != 0)
- doc += printf (" -m%-23.23s %s\n", option, description);
+ doc += printf (" -m%-23.23s %s\n", option, _(description));
}
#ifdef TARGET_OPTIONS
@@ -3994,7 +3994,7 @@ display_target_options ()
printf (_(" -m%-23.23s [undocumented]\n"), option);
}
else if (* description != 0)
- doc += printf (" -m%-23.23s %s\n", option, description);
+ doc += printf (" -m%-23.23s %s\n", option, _(description));
}
#endif
if (undoc)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 9:36 Joseph S. Myers
0 siblings, 0 replies; 30+ messages in thread
From: Joseph S. Myers @ 2001-05-24 9:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Zack Weinberg <zackw@Stanford.EDU>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>, <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
<gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 17:29:56 +0100 (BST)
On Thu, 24 May 2001, Dennis Bjorklund wrote:
> Yes. Just try to build a tar ball and see if sv.gmo is there, if it is, it
> works. It's the sv.gmo that is renamed and installed as a gcc.mo. And the
> same for other languages but there are no but swedish for now. This is how
> it works for other packages and the .gmo is created when one do the "make
> dist" if it's needed.
GCC doesn't use "make dist". This is presumably for Mark to do when
writing the release script - or, once the version being used for 3.0 is in
maintainer-scripts in CVS, for anyone to do.
> I found some more strings that are in the .po file that does not show up
> translated:
>
> $ gcc-3.0 --target-help
Someone can make the obvious fix to display_target_options in toplev.c.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 9:26 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-05-24 9:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Zack Weinberg <zackw@Stanford.EDU>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>,
<Gabriel.Dos-Reis@cmla.ens-cachan.fr>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 18:22:09 +0200 (CEST)
On Thu, 24 May 2001, Joseph S. Myers wrote:
> On Thu, 24 May 2001, Dennis Bjorklund wrote:
>
> > I don't know anything about release scripts. But a make && make install
> > installs the binary files (as gcc.mo). Maybe one have to adjust so that
>
> But doesn't this require users to have gettext installed? The normal GNU
> practice is for users to get the translations installed without needing
> gettext installed - which requires the compiled gcc.mo to be included in
> the source tarball.
Yes. Just try to build a tar ball and see if sv.gmo is there, if it is, it
works. It's the sv.gmo that is renamed and installed as a gcc.mo. And the
same for other languages but there are no but swedish for now. This is how
it works for other packages and the .gmo is created when one do the "make
dist" if it's needed.
I found some more strings that are in the .po file that does not show up
translated:
$ gcc-3.0 --target-help
Speciella flaggor för målarkitektur:
-m96bit-long-double sizeof(long double) is 12.
-m128bit-long-double sizeof(long double) is 16.
<...>
still this is in the .po file:
#: config/i386/i386.h:305
msgid "sizeof(long double) is 16."
msgstr "sizeof(long double) är 16."
#: config/i386/i386.h:307
msgid "sizeof(long double) is 12."
msgstr "sizeof(long double) är 12."
So some more of that magic that was done before is needed.
--
/Dennis
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 9:16 Joseph S. Myers
0 siblings, 0 replies; 30+ messages in thread
From: Joseph S. Myers @ 2001-05-24 9:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Zack Weinberg <zackw@Stanford.EDU>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>, <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
<gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 17:07:32 +0100 (BST)
On Thu, 24 May 2001, Dennis Bjorklund wrote:
> I don't know anything about release scripts. But a make && make install
> installs the binary files (as gcc.mo). Maybe one have to adjust so that
But doesn't this require users to have gettext installed? The normal GNU
practice is for users to get the translations installed without needing
gettext installed - which requires the compiled gcc.mo to be included in
the source tarball. Indeed, gcc/po/Makefile.in.in seems to support
installing a catalog from the source directory if one isn't present in the
build directory.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 7:16 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-05-24 7:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Zack Weinberg <zackw@Stanford.EDU>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>,
<Gabriel.Dos-Reis@cmla.ens-cachan.fr>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 16:09:44 +0200 (CEST)
On Thu, 24 May 2001, Joseph S. Myers wrote:
> Question: do the release scripts need to generate the compiled .gmo files?
> As those are binary, we surely don't want to put them in CVS.
I don't know anything about release scripts. But a make && make install
installs the binary files (as gcc.mo). Maybe one have to adjust so that
this filename is changed in the same way as the executables if someone
want's to install several versions of gcc in the same place. I would
prefer if the files were called gcc-3.0.mo, but this seems to be a problem
with most programs. I think the plan is to fix this for gnome programs i
the future so maybe that will become the standard in the future.
I really like to have several versions of programs installed without
conflicts. But maybe that is impossible with gcc anyway and that you have
to install other versions in thier own directorys (like I have now with
gcc 3.0pre)
--
/Dennis
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 5:36 Joseph S. Myers
0 siblings, 0 replies; 30+ messages in thread
From: Joseph S. Myers @ 2001-05-24 5:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Zack Weinberg <zackw@Stanford.EDU>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>, <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
<gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 13:25:44 +0100 (BST)
On Thu, 24 May 2001, Dennis Bjorklund wrote:
> I don't think that is a requirement from fsf, but if that's how you people
> want it. I talked with Philipp and last year, and then it was said that as
> long as the paperwork is okay it doesn't matter.
If we work differently from the standard FSF way - and, as long as the
disclaimers are on file with the FSF and the people involved want to work
otherwise, we can probably do so unless the FSF or SC say otherwise - then
we should get the existing .pot and translations removed from the FSF
translation system to avoid duplicated effort.
> For example gnome keeps all the .po files in cvs (and not the .pot) and
> let the translators send patches, or if they have write access to update
> the files themself. And if someone needs help there is a mailinglist for
> that. I think that is even simpler then the fsf system. One difference is
> that fsf demands that you sign one of thier disclaimers and send in
> first (i've done that).
>
> I for one would like to keep the translation synced with the development
> tree once it is complete. Even if that means I'll translate string that
> will change again before the release. It's easier to keep the translation
> up to date in that way. I don't see any use of having the .pot in the cvs
> at all.
If the people involved in translation for GCC want to work this way, then
can you sort things out with the FSF people to avoid duplication, get in
the old translations they have, and get the people who did them involved
in updating them?
The first priority is presumably getting up to date translations for the
3.0 branch (and putting those on mainline as well, for now), before
translating 3.1.
Question: do the release scripts need to generate the compiled .gmo files?
As those are binary, we surely don't want to put them in CVS.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 4:36 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-05-24 4:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Zack Weinberg <zackw@Stanford.EDU>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>,
<Gabriel.Dos-Reis@cmla.ens-cachan.fr>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 13:27:47 +0200 (CEST)
On Thu, 24 May 2001, Joseph S. Myers wrote:
> > Danish and Japanese translations (for a gcc.pot from 2000-06-07, but
> > still...) sitting there?
>
> ... and the Swedish translation should be going via the GNU translation
> project (see http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html
> for how maintainers should interact with translators).
I don't think that is a requirement from fsf, but if that's how you people
want it. I talked with Philipp and last year, and then it was said that as
long as the paperwork is okay it doesn't matter.
My guess is also that these old translations not only out of date but
missing stuff. My sv.po is 252k and there is lots of strings not
translated. The danish is just 166k so probably there is a lot of string
missing from that pot.
> the release script), so that there is a suitable distribution, containing
> an up to date .pot file, for the translators to use?
There needs to be several po files since gcc is developed in different
parts. The gcc 3.0.x might need to be updated even after 3.1 comes out and
so on. I don't know how (or even if) the fsf system handles that.
The fsf system works as it do since they think it's too hard for
translators to handle cvs and maybe to much to download. But I think
especially for gcc that should not be a problem but even for other
translations you really need to compile and run the program anyway to see
that it works. Natural language are too ambigous to just translate in the
dark and hope it works in a context. So i think you should download and
try out your translation.
For example gnome keeps all the .po files in cvs (and not the .pot) and
let the translators send patches, or if they have write access to update
the files themself. And if someone needs help there is a mailinglist for
that. I think that is even simpler then the fsf system. One difference is
that fsf demands that you sign one of thier disclaimers and send in
first (i've done that).
I for one would like to keep the translation synced with the development
tree once it is complete. Even if that means I'll translate string that
will change again before the release. It's easier to keep the translation
up to date in that way. I don't see any use of having the .pot in the cvs
at all.
--
/Dennis
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 1:36 Joseph S. Myers
0 siblings, 0 replies; 30+ messages in thread
From: Joseph S. Myers @ 2001-05-24 1:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Zack Weinberg <zackw@Stanford.EDU>
Cc: Dennis Bjorklund <db@zigo.dhs.org>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>, <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
<gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 09:28:38 +0100 (BST)
On Thu, 24 May 2001, Zack Weinberg wrote:
> We ought to be regularly uploading revised .pot files, and checking
> for completed translations. Did anyone know that there are complete
> Danish and Japanese translations (for a gcc.pot from 2000-06-07, but
> still...) sitting there?
... and the Swedish translation should be going via the GNU translation
project (see http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html
for how maintainers should interact with translators).
Perhaps the .pot file in CVS could be updated before Mark generates the
first prerelease (or, if it is removed from CVS, it could be generated in
the release script), so that there is a suitable distribution, containing
an up to date .pot file, for the translators to use?
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 1:26 Zack Weinberg
0 siblings, 0 replies; 30+ messages in thread
From: Zack Weinberg @ 2001-05-24 1:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Dennis Bjorklund <db@zigo.dhs.org>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>, Gabriel.Dos-Reis@cmla.ens-cachan.fr,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 01:16:47 -0700
On Thu, May 24, 2001 at 08:48:40AM +0100, Joseph S. Myers wrote:
> On Thu, 24 May 2001, Zack Weinberg wrote:
>
> > On the other hand, it might be more useful to have a known place to
> > work from, which would argue for leaving gcc.pot in CVS and updating
> > it periodically.
>
> But that known place for translators of GNU software is
>
> http://www.iro.umontreal.ca/contrib/po/pot/
I *thought* there was some sort of web page like that, but I couldn't
remember where it lived.
> though we should, at least, have a defined tag in the repository (maybe a
> snapshot or release tag) for the sources from which a .pot was generated,
> if the .pot doesn't go in CVS.
We ought to be regularly uploading revised .pot files, and checking
for completed translations. Did anyone know that there are complete
Danish and Japanese translations (for a gcc.pot from 2000-06-07, but
still...) sitting there?
--
zw They are calling true what their heart desires; what they would have
be true, and if the iron bones of the earth or the light in the width
of the sky say different, they will not permit these things to be
knowledge within them, nor grant regard to any who do. -- Graydon Saunders
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 0:56 Joseph S. Myers
0 siblings, 0 replies; 30+ messages in thread
From: Joseph S. Myers @ 2001-05-24 0:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Zack Weinberg <zackw@Stanford.EDU>
Cc: Dennis Bjorklund <db@zigo.dhs.org>, Mark Mitchell <mark@codesourcery.com>,
Philipp Thomas <pthomas@suse.de>, <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
<gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 08:48:40 +0100 (BST)
On Thu, 24 May 2001, Zack Weinberg wrote:
> On the other hand, it might be more useful to have a known place to
> work from, which would argue for leaving gcc.pot in CVS and updating
> it periodically.
But that known place for translators of GNU software is
http://www.iro.umontreal.ca/contrib/po/pot/
though we should, at least, have a defined tag in the repository (maybe a
snapshot or release tag) for the sources from which a .pot was generated,
if the .pot doesn't go in CVS.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-24 0:46 Zack Weinberg
0 siblings, 0 replies; 30+ messages in thread
From: Zack Weinberg @ 2001-05-24 0:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Mark Mitchell <mark@codesourcery.com>, Philipp Thomas <pthomas@suse.de>,
Gabriel.Dos-Reis@cmla.ens-cachan.fr, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Thu, 24 May 2001 00:42:08 -0700
On Wed, May 23, 2001 at 07:26:22PM +0200, Dennis Bjorklund wrote:
> 1. POTFILE.in
>
> Contains files that does not exist any more. Every
> time a file gets deleted or when a file that contains
> strings to be translated is added, one must update
> POTFILE.in
I took out the missing files. I'm thinking about a way to avoid
having to have this file at all. Stay tuned.
> 2. Makefile.in.in
>
> The --defines flag to xgettext must be deleted since it does
> not exist.
Philipp?
> 3. gcc.pot
>
> Can be deleted from the cvs since it can be recreated with
> a "make update-po" in the po directory.
>
> Now when I do it the size of this file is comparabel with
> the size of the cvs version so I guess they are almost
> the same. The cvs version is 9 months old so you
> can't really expect them to be exactly the same. Some
> strings surely have changed during this time :-)
This is a question of what would be most useful to you and other
translators. The .po files need to remain in CVS since they are
created by humans, but perhaps it would be okay to get rid of the .pot
file entirely. As you say, you can do make update-po and get the
specific .po file you care about updated, and one can always create
gcc.pot explicitly to begin a new translation with.
On the other hand, it might be more useful to have a known place to
work from, which would argue for leaving gcc.pot in CVS and updating
it periodically.
> 4. When one builds the files outside the source directory
> one expects that the source directory should not be
> altered. In the case of gcc.pot it's not true and this
> file is created in the source directory.
General problem with lots of files, not just gcc.pot. If we're taking
gcc.pot out of CVS then I don't think it needs to be in snapshots
either, so it could be moved to the build directory.
--
zw The phrase causes storage to be reserved, doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardese.
-- Mike Stump
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-23 0:56 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-05-23 0:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: Mark Mitchell <mark@codesourcery.com>
Cc: <zackw@Stanford.EDU>, <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
Philipp Thomas <pthomas@suse.de>, <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Wed, 23 May 2001 09:53:28 +0200 (CEST)
On Wed, 23 May 2001, Mark Mitchell wrote:
> >>>>> "Dennis" == Dennis Bjorklund <db@zigo.dhs.org> writes:
>
> Dennis> What about the pot file? I don't think it should be in cvs
> Dennis> at all. It should be automatically generated.
>
> I would very much prefer that *no* generated files be in CVS, but I
> don't understand internationalization at all. :-) If the pot file can
> be generated, I agree that we shouldn't have it in CVS.
In most (maybe all) other projects i've seen it is generated
automatically.
There is a strange thing in the Makefile. xgettext is called with the flag
--defines which does not exist. I just got the latest cvs of gettext and
it does not exist there either. So make update-po in the po directory does
not work.
When I remove the --defines (and use lates cvs gettext) it works, but the
gcc.pot file is smaller then the one that is in cvs 70k smaller. But the
cvs version is like a year old so maybe it's correct anyway? Or maybe
there are strings missing.
I rememeber that I talked with someone (most probably Philipp Thomas)
about it in november and I got the impression that it was going to be
fixed by then and that it was something that he had in his version of
gettext. I'm not sure, but i'll cc Philipp and maybe he remeber.
I tried to compile the cvs version of gcc with the same flags as I used
some months ago, but now it does not work. I want to get a version up and
running so I can start on the translation.
The flags I used was:
./configure --prefix=/opt/gcc --enable-nls --disable-checking
--enable-threads --host=i386-pc-linux-gnu
and after a long time it stops at:
Configuring in i386-pc-linux-gnu/boehm-gc
AmigaOS.c ..linked
BCC_MAKEFILE ..linked
<deleted>
version.h ..linked
win32_threads.c ..linked
loading cache ../config.cache
configure: error: can not find install-sh or install.sh in .. ./..
make: *** [configure-target-boehm-gc] Error 1
I can probably fix it myself but if you know about this problem directly
it would be nice. I don't even have a clue about what boehm is..
--
/Dennis
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-23 0:26 Mark Mitchell
0 siblings, 0 replies; 30+ messages in thread
From: Mark Mitchell @ 2001-05-23 0:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Mark Mitchell <mark@codesourcery.com>
To: db@zigo.dhs.org
Cc: zackw@Stanford.EDU, Gabriel.Dos-Reis@cmla.ens-cachan.fr,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Wed, 23 May 2001 00:20:52 -0700
>>>>> "Dennis" == Dennis Bjorklund <db@zigo.dhs.org> writes:
Dennis> What about the pot file? I don't think it should be in cvs
Dennis> at all. It should be automatically generated.
I would very much prefer that *no* generated files be in CVS, but I
don't understand internationalization at all. :-) If the pot file can
be generated, I agree that we shouldn't have it in CVS.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-23 0:16 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-05-23 0:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: Zack Weinberg <zackw@Stanford.EDU>
Cc: Mark Mitchell <mark@codesourcery.com>,
Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
<gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Wed, 23 May 2001 09:11:01 +0200 (CEST)
On Tue, 22 May 2001, Zack Weinberg wrote:
> A translation is something that could easily get added in a 3.0.x
> patch release
Definitely.
What about the pot file? I don't think it should be in cvs at all. It
should be automatically generated.
There is some files in POTFILES.in that does not exist. Maybe there are
also files that are not included in POTFILES.in.
Index: gcc/po/POTFILES.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/po/POTFILES.in,v
retrieving revision 1.44
diff -u -w -r1.44 POTFILES.in
--- POTFILES.in 2001/05/17 03:16:16 1.44
+++ POTFILES.in 2001/05/23 07:04:16
@@ -363,7 +363,6 @@
config/ns32k/tek6100.h
config/ns32k/tek6200.h
config/pa/elf.h
-config/pa/pa-gas.h
config/pa/pa-hiux.h
config/pa/pa-hpux.h
config/pa/pa-hpux10.h
@@ -405,7 +404,6 @@
config/rs6000/sysv4le.h
config/rs6000/vxppc.h
config/rs6000/xm-beos.h
-config/rs6000/xm-darwin.h
config/rtems.h
config/sh/elf.h
config/sh/rtems.h
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-22 23:06 Mark Mitchell
0 siblings, 0 replies; 30+ messages in thread
From: Mark Mitchell @ 2001-05-22 23:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Mark Mitchell <mark@codesourcery.com>
To: zackw@Stanford.EDU
Cc: db@zigo.dhs.org, Gabriel.Dos-Reis@cmla.ens-cachan.fr,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Tue, 22 May 2001 23:03:36 -0700
>>>>> "Zack" == Zack Weinberg <zackw@Stanford.EDU> writes:
Zack> A translation is something that could easily get added in a
Zack> 3.0.x patch release, if it isn't ready in time for 3.0.0, so
Zack> don't feel pressured. I think that independent of this the
Zack> machinery should work in 3.0.0.
Just to emphasize both of these points: adding translations is
something that I think would be perfect for a .x release. There is no
risk to anyone not using the translation, and the only real risk to
those using the translation is of wrong messages, not wrong code
generation.
I'd be much more nervous about reworking diagnostic.c for the
dot-release, so we should do that now, if we can.
My goal is for the dot releases to contain sufficiently minor tweaks
that it will be easy to have high confidence.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-22 22:56 Zack Weinberg
0 siblings, 0 replies; 30+ messages in thread
From: Zack Weinberg @ 2001-05-22 22:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Mark Mitchell <mark@codesourcery.com>,
Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Tue, 22 May 2001 22:48:57 -0700
On Wed, May 23, 2001 at 07:26:26AM +0200, Dennis Bjorklund wrote:
> On Tue, 22 May 2001, Zack Weinberg wrote:
>
> > test.c:1:16: /usr: Filen eller katalogen finns inte
> > test.c: I en funktion `main':
> > test.c:2: warning: unused variable `x'
> > test.c:2: warning: Programfl?det n?r slutet p? en icke-void funktion
> >
> > [I made up and inserted into sv.po the translation for
> > "In function `%s':" as a test; I do not speak Swedish.]
>
> I looks nice, and the string is really swedish!
It was a guess based on other strings in sv.po.
> > If we apply this patch, update gcc.pot, and freeze diagnostics on the
> > branch, will you have enough time to complete the translation to
> > Swedish?
>
> I'm not sure. It takes quite some time to translate a program like gcc.
> Programmers (like me) have been using english compilers for ever and are
> used to the english error messages, and one have to be carefull to do it
> good, the most important part is that no information is lost.
I understand.
A translation is something that could easily get added in a 3.0.x
patch release, if it isn't ready in time for 3.0.0, so don't feel
pressured. I think that independent of this the machinery should
work in 3.0.0.
--
zw If punishments don't compensate the victims and don't prevent future
crimes they seem to me to be indistinguishable from random acts of
sadism.
-- Bernard Peek
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-22 22:36 Dennis Bjorklund
0 siblings, 0 replies; 30+ messages in thread
From: Dennis Bjorklund @ 2001-05-22 22:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Dennis Bjorklund <db@zigo.dhs.org>
To: Zack Weinberg <zackw@stanford.edu>
Cc: Mark Mitchell <mark@codesourcery.com>,
Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
<gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: other/2857: i18n, translations does not work
Date: Wed, 23 May 2001 07:26:26 +0200 (CEST)
On Tue, 22 May 2001, Zack Weinberg wrote:
> test.c:1:16: /usr: Filen eller katalogen finns inte
> test.c: I en funktion `main':
> test.c:2: warning: unused variable `x'
> test.c:2: warning: Programflödet når slutet på en icke-void funktion
>
> [I made up and inserted into sv.po the translation for
> "In function `%s':" as a test; I do not speak Swedish.]
I looks nice, and the string is really swedish!
> Also note that gcc.pot has not been updated in a very long time.
Yes, I know. And lots of the strings i've translated are invalid. That's
why no one want to make a lot of work until the translation can be used.
> If we apply this patch, update gcc.pot, and freeze diagnostics on the
> branch, will you have enough time to complete the translation to
> Swedish?
I'm not sure. It takes quite some time to translate a program like gcc.
Programmers (like me) have been using english compilers for ever and are
used to the english error messages, and one have to be carefull to do it
good, the most important part is that no information is lost.
But on the other hand, if we can get most of the usual strings (for x86,
c, c++) it will be good enough. Then I have a vacation in the summer when
I can take care of the other strings.
Nothing in the translation I will do affects other parts so if we get to
the point of release and the translation is not good enough then we could
just leave it out without destroying anything.
--
/Dennis
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-22 12:56 Gabriel Dos Reis
0 siblings, 0 replies; 30+ messages in thread
From: Gabriel Dos Reis @ 2001-05-22 12:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR other/2857; it has been noted by GNATS.
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: "Zack Weinberg" <zackw@stanford.edu>
Cc: db@zigo.dhs.org, Mark Mitchell <mark@codesourcery.com>,
Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: 22 May 2001 21:49:45 +0200
"Zack Weinberg" <zackw@stanford.edu> writes:
| On Thu, May 17, 2001 at 06:17:57PM -0000, db@zigo.dhs.org wrote:
|
| > Runnig gcc --help gives the swedish translation! But all the other
| > parts that is called by gcc is not working. I have LANG set to
| > sv_SE, but it does work with gcc --help and in all other programs,
| > so the error is in gcc.
|
| Hmmmmm.
|
| $ cat test.c
| #include </usr>
| int main(void) { int x = 0; }
| $ LC_ALL=sv_FI inst-3.0/bin/gcc -Wall test.c
| test.c:1:16: /usr: Filen eller katalogen finns inte
| test.c: In function `main':
| test.c:2: warning: unused variable `x'
| test.c:2: warning: control reaches end of non-void function
|
| The complaint about /usr is coming from cpplib, the other messages aren't.
|
| So I look through diagnostic.c, and almost none of the functions that
| are supposed to run their 'msgid' argument through gettext(3) actually
| do. This is not that hard to fix, except that diagnostic.c is a mess.
Yes, diagnostic.c is a mess and plans are to clean it.
| I think the appended patch hits all the places that need to get hit,
| but maybe Gabriel could take a close look? The tweaks to argument
| names enforce the principle that a 'const char *msgid' is either run
| through gettext or passed to a function which will run it through
| gettext.
OK.
Is there a reason why vnotice should go that way (I'm not saying, that
is wrong, I'm wanting to know because the long-term plan is to have no
(or very few) functions putting text directly into stderr or variants.
They should run texts through the machinery.
-- Gaby
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: other/2857: i18n, translations does not work
@ 2001-05-22 11:06 Zack Weinberg
0 siblings, 0 replies; 30+ messages in thread
From: Zack Weinberg @ 2001-05-22 11:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 14557 bytes --]
The following reply was made to PR other/2857; it has been noted by GNATS.
From: "Zack Weinberg" <zackw@stanford.edu>
To: db@zigo.dhs.org, Mark Mitchell <mark@codesourcery.com>,
Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: other/2857: i18n, translations does not work
Date: Tue, 22 May 2001 11:00:58 -0700
On Thu, May 17, 2001 at 06:17:57PM -0000, db@zigo.dhs.org wrote:
> Runnig gcc --help gives the swedish translation! But all the other
> parts that is called by gcc is not working. I have LANG set to
> sv_SE, but it does work with gcc --help and in all other programs,
> so the error is in gcc.
Hmmmmm.
$ cat test.c
#include </usr>
int main(void) { int x = 0; }
$ LC_ALL=sv_FI inst-3.0/bin/gcc -Wall test.c
test.c:1:16: /usr: Filen eller katalogen finns inte
test.c: In function `main':
test.c:2: warning: unused variable `x'
test.c:2: warning: control reaches end of non-void function
The complaint about /usr is coming from cpplib, the other messages aren't.
So I look through diagnostic.c, and almost none of the functions that
are supposed to run their 'msgid' argument through gettext(3) actually
do. This is not that hard to fix, except that diagnostic.c is a mess.
I think the appended patch hits all the places that need to get hit,
but maybe Gabriel could take a close look? The tweaks to argument
names enforce the principle that a 'const char *msgid' is either run
through gettext or passed to a function which will run it through
gettext.
With the patch I can get
test.c:1:16: /usr: Filen eller katalogen finns inte
test.c: I en funktion `main':
test.c:2: warning: unused variable `x'
test.c:2: warning: Programflödet når slutet på en icke-void funktion
[I made up and inserted into sv.po the translation for
"In function `%s':" as a test; I do not speak Swedish.]
Also note that gcc.pot has not been updated in a very long time. If
we apply this patch, update gcc.pot, and freeze diagnostics on the
branch, will you have enough time to complete the translation to
Swedish?
--
zw But then one day I came up with a radical new paradigm for my business...
I decided that from now on I would only sell boring stuff that people
actually need.
-- Garry Trudeau, _Doonesbury_
* diagnostic.c (vnotice): Kill.
(fnotice): Call vfprintf directly.
(diagnostic_for_decl, output_do_verbatim, output_verbatim,
verbatim, set_diagnostic_context): Rename string argument to
indicate that it is run through gettext.
(vbuild_message_string, build_message_string, output_do_printf):
Rename string argument to indicate that it is NOT run through
gettext.
(output_printf, diagnostic_for_decl, fatal_io_error, sorry,
output_do_verbatim, set_diagnostic_context, fnotice, _fatal_insn):
Run msgid argument through gettext.
(default_print_error_function): Run constant strings through
gettext when nothing else will.
(fatal_error, internal_error, error_recursion): Use fnotice.
Present complete sentences to gettext.
===================================================================
Index: diagnostic.c
--- diagnostic.c 2001/05/12 20:32:26 1.51.2.3
+++ diagnostic.c 2001/05/22 17:53:08
@@ -78,10 +78,8 @@ static void format_with_decl PARAMS ((ou
static void file_and_line_for_asm PARAMS ((rtx, const char **, int *));
static void diagnostic_for_asm PARAMS ((rtx, const char *, va_list *, int));
static void diagnostic_for_decl PARAMS ((tree, const char *, va_list *, int));
-static void vnotice PARAMS ((FILE *, const char *, va_list))
- ATTRIBUTE_PRINTF (2, 0);
static void set_real_maximum_length PARAMS ((output_buffer *));
-
+
static void output_unsigned_decimal PARAMS ((output_buffer *, unsigned int));
static void output_long_decimal PARAMS ((output_buffer *, long int));
static void output_long_unsigned_decimal PARAMS ((output_buffer *,
@@ -796,35 +794,35 @@ output_format (buffer)
}
static char *
-vbuild_message_string (msgid, ap)
- const char *msgid;
+vbuild_message_string (msg, ap)
+ const char *msg;
va_list ap;
{
char *str;
- vasprintf (&str, msgid, ap);
+ vasprintf (&str, msg, ap);
return str;
}
-/* Return a malloc'd string containing MSGID formatted a la
+/* Return a malloc'd string containing MSG formatted a la
printf. The caller is reponsible for freeing the memory. */
static char *
-build_message_string VPARAMS ((const char *msgid, ...))
+build_message_string VPARAMS ((const char *msg, ...))
{
#ifndef ANSI_PROTOTYPES
- const char *msgid;
+ const char *msg;
#endif
va_list ap;
char *str;
- VA_START (ap, msgid);
+ VA_START (ap, msg);
#ifndef ANSI_PROTOTYPES
- msgid = va_arg (ap, const char *);
+ msg = va_arg (ap, const char *);
#endif
- str = vbuild_message_string (msgid, ap);
+ str = vbuild_message_string (msg, ap);
va_end (ap);
@@ -843,14 +841,14 @@ context_as_prefix (file, line, warn)
if (file)
{
if (warn)
- return build_message_string ("%s:%d: warning: ", file, line);
+ return build_message_string (_("%s:%d: warning: "), file, line);
else
return build_message_string ("%s:%d: ", file, line);
}
else
{
if (warn)
- return build_message_string ("%s: warning: ", progname);
+ return build_message_string (_("%s: warning: "), progname);
else
return build_message_string ("%s: ", progname);
}
@@ -868,11 +866,11 @@ file_name_as_prefix (f)
/* Format a MESSAGE into BUFFER. Automatically wrap lines. */
static void
-output_do_printf (buffer, msgid)
+output_do_printf (buffer, msg)
output_buffer *buffer;
- const char *msgid;
+ const char *msg;
{
- char *message = vbuild_message_string (msgid,
+ char *message = vbuild_message_string (msg,
output_buffer_format_args (buffer));
wrap_text (buffer, message, message + strlen (message));
@@ -899,22 +897,11 @@ output_printf VPARAMS ((struct output_bu
#endif
old_args = output_buffer_ptr_to_format_args (buffer);
output_buffer_ptr_to_format_args (buffer) = ≈
- output_do_printf (buffer, msgid);
+ output_do_printf (buffer, _(msgid));
output_buffer_ptr_to_format_args (buffer) = old_args;
va_end (ap);
}
-/* Print the message MSGID in FILE. */
-
-static void
-vnotice (file, msgid, ap)
- FILE *file;
- const char *msgid;
- va_list ap;
-{
- vfprintf (file, _(msgid), ap);
-}
-
/* Print a message relevant to the given DECL. */
static void
@@ -1025,9 +1012,9 @@ diagnostic_for_asm (insn, msg, args_ptr,
name; subsequent substitutions are a la output_format. */
static void
-diagnostic_for_decl (decl, msg, args_ptr, warn)
+diagnostic_for_decl (decl, msgid, args_ptr, warn)
tree decl;
- const char *msg;
+ const char *msgid;
va_list *args_ptr;
int warn;
{
@@ -1044,7 +1031,7 @@ diagnostic_for_decl (decl, msg, args_ptr
(diagnostic_buffer, context_as_prefix
(DECL_SOURCE_FILE (decl), DECL_SOURCE_LINE (decl), warn));
output_buffer_ptr_to_format_args (diagnostic_buffer) = args_ptr;
- output_buffer_text_cursor (diagnostic_buffer) = msg;
+ output_buffer_text_cursor (diagnostic_buffer) = _(msgid);
format_with_decl (diagnostic_buffer, decl);
finish_diagnostic ();
output_destroy_prefix (diagnostic_buffer);
@@ -1083,7 +1070,8 @@ count_error (warningp)
return 1;
}
-/* Print a diagnistic MSGID on FILE. */
+/* Print a diagnostic MSGID on FILE. This is just fprintf, except it
+ runs its second argument through gettext. */
void
fnotice VPARAMS ((FILE *file, const char *msgid, ...))
@@ -1101,7 +1089,7 @@ fnotice VPARAMS ((FILE *file, const char
msgid = va_arg (ap, const char *);
#endif
- vnotice (file, msgid, ap);
+ vfprintf (file, _(msgid), ap);
va_end (ap);
}
@@ -1127,7 +1115,7 @@ fatal_io_error VPARAMS ((const char *msg
output_printf (diagnostic_buffer, "%s: %s: ", progname, xstrerror (errno));
output_buffer_ptr_to_format_args (diagnostic_buffer) = ≈
- output_buffer_text_cursor (diagnostic_buffer) = msgid;
+ output_buffer_text_cursor (diagnostic_buffer) = _(msgid);
output_format (diagnostic_buffer);
finish_diagnostic ();
output_buffer_state (diagnostic_buffer) = os;
@@ -1235,7 +1223,7 @@ sorry VPARAMS ((const char *msgid, ...))
(diagnostic_buffer, context_as_prefix (input_filename, lineno, 0));
output_printf (diagnostic_buffer, "sorry, not implemented: ");
output_buffer_ptr_to_format_args (diagnostic_buffer) = ≈
- output_buffer_text_cursor (diagnostic_buffer) = msgid;
+ output_buffer_text_cursor (diagnostic_buffer) = _(msgid);
output_format (diagnostic_buffer);
finish_diagnostic ();
output_buffer_state (diagnostic_buffer) = os;
@@ -1277,7 +1265,7 @@ default_print_error_function (file)
output_set_prefix (diagnostic_buffer, prefix);
if (current_function_decl == NULL)
- output_add_string (diagnostic_buffer, "At top level:");
+ output_add_string (diagnostic_buffer, _("At top level:"));
else
{
if (TREE_CODE (TREE_TYPE (current_function_decl)) == METHOD_TYPE)
@@ -1421,7 +1409,7 @@ fatal_error VPARAMS ((const char *msgid,
report_diagnostic (&dc);
va_end (ap);
- fprintf (stderr, "compilation terminated.\n");
+ fnotice (stderr, "compilation terminated.\n");
exit (FATAL_EXIT_CODE);
}
@@ -1456,7 +1444,7 @@ internal_error VPARAMS ((const char *msg
if (errorcount > 0 || sorrycount > 0)
{
- fprintf (stderr, "%s:%d: confused by earlier errors, bailing out\n",
+ fnotice (stderr, "%s:%d: confused by earlier errors, bailing out\n",
input_filename, lineno);
exit (FATAL_EXIT_CODE);
}
@@ -1469,9 +1457,10 @@ internal_error VPARAMS ((const char *msg
report_diagnostic (&dc);
va_end (ap);
- fprintf (stderr, "Please submit a full bug report, ");
- fprintf (stderr, "with preprocessed source if appropriate.\n");
- fprintf (stderr, "See %s for instructions.\n", GCCBUGURL);
+ fnotice (stderr,
+"Please submit a full bug report,\n\
+with preprocessed source if appropriate.\n\
+See %s for instructions.\n", GCCBUGURL);
exit (FATAL_EXIT_CODE);
}
@@ -1483,7 +1472,7 @@ _fatal_insn (msgid, insn, file, line, fu
int line;
const char *function;
{
- error ("%s", msgid);
+ error ("%s", _(msgid));
/* The above incremented error_count, but isn't an error that we want to
count, so reset it here. */
@@ -1608,9 +1597,9 @@ finish_diagnostic ()
settings needed by BUFFER for a verbatim formatting. */
static void
-output_do_verbatim (buffer, msg, args_ptr)
+output_do_verbatim (buffer, msgid, args_ptr)
output_buffer *buffer;
- const char *msg;
+ const char *msgid;
va_list *args_ptr;
{
output_state os;
@@ -1618,7 +1607,7 @@ output_do_verbatim (buffer, msg, args_pt
os = output_buffer_state (buffer);
output_prefix (buffer) = NULL;
prefixing_policy (buffer) = DIAGNOSTICS_SHOW_PREFIX_NEVER;
- output_buffer_text_cursor (buffer) = msg;
+ output_buffer_text_cursor (buffer) = _(msgid);
output_buffer_ptr_to_format_args (buffer) = args_ptr;
output_set_maximum_length (buffer, 0);
output_format (buffer);
@@ -1628,38 +1617,38 @@ output_do_verbatim (buffer, msg, args_pt
/* Output MESSAGE verbatim into BUFFER. */
void
-output_verbatim VPARAMS ((output_buffer *buffer, const char *msg, ...))
+output_verbatim VPARAMS ((output_buffer *buffer, const char *msgid, ...))
{
#ifndef ANSI_PROTOTYPES
output_buffer *buffer;
- const char *msg;
+ const char *msgid;
#endif
va_list ap;
- VA_START (ap, msg);
+ VA_START (ap, msgid);
#ifndef ANSI_PROTOTYPES
buffer = va_arg (ap, output_buffer *);
- msg = va_arg (ap, const char *);
+ msgid = va_arg (ap, const char *);
#endif
- output_do_verbatim (buffer, msg, &ap);
+ output_do_verbatim (buffer, msgid, &ap);
va_end (ap);
}
/* Same as above but use diagnostic_buffer. */
void
-verbatim VPARAMS ((const char *msg, ...))
+verbatim VPARAMS ((const char *msgid, ...))
{
#ifndef ANSI_PROTOTYPES
- const char *msg;
+ const char *msgid;
#endif
va_list ap;
- VA_START (ap, msg);
+ VA_START (ap, msgid);
#ifndef ANSI_PROTOTYPES
- msg = va_arg (ap, const char *);
+ msgid = va_arg (ap, const char *);
#endif
- output_do_verbatim (diagnostic_buffer, msg, &ap);
+ output_do_verbatim (diagnostic_buffer, msgid, &ap);
output_to_stream (diagnostic_buffer, stderr);
va_end (ap);
}
@@ -1696,7 +1685,8 @@ report_diagnostic (dc)
/* Inform the user that an error occurred while trying to report some
other error. This indicates catastrophic internal inconsistencies,
- so give up now. But do try to flush out the previous error. */
+ so give up now. But do try to flush out the previous error.
+ This mustn't use internal_error, that will cause infinite recursion. */
static void
error_recursion ()
@@ -1704,8 +1694,13 @@ error_recursion ()
if (diagnostic_lock < 3)
finish_diagnostic ();
- internal_error
- ("Internal compiler error: Error reporting routines re-entered.");
+ fnotice (stderr,
+ "Internal compiler error: Error reporting routines re-entered.");
+ fnotice (stderr,
+"Please submit a full bug report,\n\
+with preprocessed source if appropriate.\n\
+See %s for instructions.\n", GCCBUGURL);
+ exit (FATAL_EXIT_CODE);
}
/* Given a partial pathname as input, return another pathname that
@@ -1771,16 +1766,16 @@ fancy_abort (file, line, function)
by FILE and LINE. */
void
-set_diagnostic_context (dc, message, args_ptr, file, line, warn)
+set_diagnostic_context (dc, msgid, args_ptr, file, line, warn)
diagnostic_context *dc;
- const char *message;
+ const char *msgid;
va_list *args_ptr;
const char *file;
int line;
int warn;
{
memset (dc, 0, sizeof (diagnostic_context));
- diagnostic_message (dc) = message;
+ diagnostic_message (dc) = _(msgid);
diagnostic_argument_list (dc) = args_ptr;
diagnostic_file_location (dc) = file;
diagnostic_line_location (dc) = line;
^ permalink raw reply [flat|nested] 30+ messages in thread
* other/2857: i18n, translations does not work
@ 2001-05-17 11:26 db
0 siblings, 0 replies; 30+ messages in thread
From: db @ 2001-05-17 11:26 UTC (permalink / raw)
To: gcc-gnats
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
>Number: 2857
>Category: other
>Synopsis: i18n, translations does not work
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu May 17 11:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: db@zigo.dhs.org
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
Runnig gcc --help gives the swedish translation! But all the other parts that is called by gcc is not working. I have LANG set to sv_SE, but it does work with gcc --help and in all other programs, so the error is in gcc.
>How-To-Repeat:
<< test.c >>
int main()
{
int x = 0;
}
$ /opt/gcc/bin/gcc -Wall -c test.c
test.c: In function `main':
test.c:3: warning: unused variable `x'
test.c:4: warning: control reaches end of non-void function
allthough this is in the sv.po file:
msgid "control reaches end of non-void function"
msgstr "Programflödet når slutet på en icke-void funktion"
(And LANG is set to sv_SE, gcc --help works)
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2001-06-13 0:56 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-23 10:36 other/2857: i18n, translations does not work Dennis Bjorklund
-- strict thread matches above, loose matches on Subject: below --
2001-06-13 0:56 Dennis Bjorklund
2001-05-25 8:16 Zack Weinberg
2001-05-25 8:06 Zack Weinberg
2001-05-25 3:26 Joseph S. Myers
2001-05-25 3:06 Philipp Thomas
2001-05-25 2:56 Joseph S. Myers
2001-05-25 2:46 Philipp Thomas
2001-05-25 2:46 Philipp Thomas
2001-05-25 2:46 Philipp Thomas
2001-05-24 10:26 Zack Weinberg
2001-05-24 9:36 Joseph S. Myers
2001-05-24 9:26 Dennis Bjorklund
2001-05-24 9:16 Joseph S. Myers
2001-05-24 7:16 Dennis Bjorklund
2001-05-24 5:36 Joseph S. Myers
2001-05-24 4:36 Dennis Bjorklund
2001-05-24 1:36 Joseph S. Myers
2001-05-24 1:26 Zack Weinberg
2001-05-24 0:56 Joseph S. Myers
2001-05-24 0:46 Zack Weinberg
2001-05-23 0:56 Dennis Bjorklund
2001-05-23 0:26 Mark Mitchell
2001-05-23 0:16 Dennis Bjorklund
2001-05-22 23:06 Mark Mitchell
2001-05-22 22:56 Zack Weinberg
2001-05-22 22:36 Dennis Bjorklund
2001-05-22 12:56 Gabriel Dos Reis
2001-05-22 11:06 Zack Weinberg
2001-05-17 11:26 db
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).