Re: other/2857: i18n, translations does not work

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

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
 

Re: other/2857: i18n, translations does not work

[Zack Weinberg]

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

Re: other/2857: i18n, translations does not work

[Zack Weinberg]

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_

Re: other/2857: i18n, translations does not work

[Joseph S. Myers]

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
 

Re: other/2857: i18n, translations does not work

[Philipp Thomas]

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

Re: other/2857: i18n, translations does not work

[Joseph S. Myers]

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
 

Re: other/2857: i18n, translations does not work

[Philipp Thomas]

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

Re: other/2857: i18n, translations does not work

[Philipp Thomas]

[-- 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

Re: other/2857: i18n, translations does not work

[Philipp Thomas]

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

Re: other/2857: i18n, translations does not work

[Zack Weinberg]

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)

Re: other/2857: i18n, translations does not work

[Joseph S. Myers]

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
 

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

[-- 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
 

Re: other/2857: i18n, translations does not work

[Joseph S. Myers]

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
 

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

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
 

Re: other/2857: i18n, translations does not work

[Joseph S. Myers]

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
 

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

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
 

Re: other/2857: i18n, translations does not work

[Joseph S. Myers]

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
 

Re: other/2857: i18n, translations does not work

[Zack Weinberg]

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

Re: other/2857: i18n, translations does not work

[Joseph S. Myers]

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
 

Re: other/2857: i18n, translations does not work

[Zack Weinberg]

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

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

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
 

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

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
 

Re: other/2857: i18n, translations does not work

[Mark Mitchell]

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

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

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
 
 

Re: other/2857: i18n, translations does not work

[Mark Mitchell]

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

Re: other/2857: i18n, translations does not work

[Zack Weinberg]

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

Re: other/2857: i18n, translations does not work

[Dennis Bjorklund]

[-- 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
 

Re: other/2857: i18n, translations does not work

[Gabriel Dos Reis]

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

Re: other/2857: i18n, translations does not work

[Zack Weinberg]

[-- 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) = &ap;
 -  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) = &ap;
 -  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) = &ap;
 -  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;

other/2857: i18n, translations does not work

[db]

[-- 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: