i18n of egcs

i18n of egcs

[Philipp Thomas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

Jeff,
I've nearly finished translating egcs's messages into german and will send the
translation to people from the german translation team who volunteered to
proofread my work in a day or two. I *still* haven't got any answer from
François Pinoir, the maintainer for the FSF translation project, so this will
likely be the only translation for the time being.

Some points should be noted for the future though. The generation of the basic
gcc.pot needs a modified gettext 0.10.35 (patch in ABOUT-GCC-NLS).
So in order to not require that an egcs user has to patch his gettext package,
your release scripts should generate a gcc.pot for inclusion into the egcs
releases, as the modified xgettext is only need for the extraction of the
messages from the source code. Updating the translations (xx.po) and compiling
them can be done with an unmodified gettext package.

The second point is that it should be stated somewhere in the top level
documentation, that anyone who uses NLS and modifies the code needs the
patched gettext.

I think it would be a good idea to modify the top level configure to run sub
level configures when called with --help to get a list of the optional
parameters that may be passed to them. What do you think ?




Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Gabriel Dos_Reis]

Jeff --

	As a related issue, I suggested some time ago --and several
people seemed to agree with me-- that error message like:

	"ANSI C++ forbids..."

should read 

	"ISO C++ forbids..."

but EGCS still insists with "ANSI C++" :-(

I'd suggest that people involded in NLS translate "ANSI C++" to 
"ISO C++". Of course things would be less confusing if "ISO C++"
appears in EGCS' primary output...

-- Gaby

Re: i18n of egcs

[Philipp Thomas]

Gabriel,

On 27 Apr 1999 22:06:20 +0200, you wrote:

>	As a related issue, I suggested some time ago --and several
>people seemed to agree with me-- that error message like:
>
>	"ANSI C++ forbids..."
>
>should read 
>
>	"ISO C++ forbids..."
>

Thanks for bringing this up. I wanted to but totally forgot about it. I'd like
to add that this also applies to C, i.e. egcs really should say ISO C and ISO
C++ where at the moment it says ANSI C and ANSI C++.

Jeff, if it's OK with you, I'd send in the patches to change this for both C
and C++. I already did most of them and would only need to bring them up to
date.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Steinar Bang]

>>>>> kthomas@gwdg.de (Philipp Thomas):

> Gabriel,
> On 27 Apr 1999 22:06:20 +0200, you wrote:

>> As a related issue, I suggested some time ago --and several
>> people seemed to agree with me-- that error message like:
>> 
>>	"ANSI C++ forbids..."
>> 
>> should read 
>> 
>>	"ISO C++ forbids..."

> Thanks for bringing this up. I wanted to but totally forgot about
> it. I'd like to add that this also applies to C, i.e. egcs really
> should say ISO C and ISO C++ where at the moment it says ANSI C and
> ANSI C++.

Maybe the flag for strict ISO compliance should change from -ansi to
-iso as well? (should one keep the old flag for backwards
compatibility or is that just useless baggage that should be
discarded?) 

Re: i18n of egcs

[Gabriel Dos_Reis]

Steinar Bang <sb@metis.no> writes:

| >>>>> kthomas@gwdg.de (Philipp Thomas):
| 
| > Gabriel,
| > On 27 Apr 1999 22:06:20 +0200, you wrote:
| 
| >> As a related issue, I suggested some time ago --and several
| >> people seemed to agree with me-- that error message like:
| >> 
| >>	"ANSI C++ forbids..."
| >> 
| >> should read 
| >> 
| >>	"ISO C++ forbids..."
| 
| > Thanks for bringing this up. I wanted to but totally forgot about
| > it. I'd like to add that this also applies to C, i.e. egcs really
| > should say ISO C and ISO C++ where at the moment it says ANSI C and
| > ANSI C++.
| 
| Maybe the flag for strict ISO compliance should change from -ansi to
| -iso as well? (should one keep the old flag for backwards
| compatibility or is that just useless baggage that should be
| discarded?) 

It could be an alias for -iso.

-- Gaby

Re: i18n of egcs

[Gabriel Dos_Reis]

Steinar Bang <sb@metis.no> writes:

| >>>>> kthomas@gwdg.de (Philipp Thomas):
| 
| > Gabriel,
| > On 27 Apr 1999 22:06:20 +0200, you wrote:
| 
| >> As a related issue, I suggested some time ago --and several
| >> people seemed to agree with me-- that error message like:
| >> 
| >>	"ANSI C++ forbids..."
| >> 
| >> should read 
| >> 
| >>	"ISO C++ forbids..."
| 
| > Thanks for bringing this up. I wanted to but totally forgot about
| > it. I'd like to add that this also applies to C, i.e. egcs really
| > should say ISO C and ISO C++ where at the moment it says ANSI C and
| > ANSI C++.
| 
| Maybe the flag for strict ISO compliance should change from -ansi to
| -iso as well? (should one keep the old flag for backwards
| compatibility or is that just useless baggage that should be
| discarded?) 

It could be an alias for -iso.

-- Gaby

Re: i18n of egcs

[craig]

>Maybe the flag for strict ISO compliance should change from -ansi to
>-iso as well? (should one keep the old flag for backwards
>compatibility or is that just useless baggage that should be
>discarded?) 

Keep the old flag.  There *is* still an ANSI C standard that gcc
supports, I believe!

(It is one thing for a *speaker* to choose the "most appropriate" term
or phrase.  It is quite another for a *listener* to insist on only
that one most appropriate term, rejecting any other.  In this case,
plenty of people already acquainted with the ANSI C standard as such
should not be forced to learn to say "ISO C" all the time.  *We* (egcs
developers) force *ourselves* to say that, because we're essentially
in the role of "public speakers" here.  That doesn't mean we should
force *everyone* to use "ISO C", even on command-line options.)

        tq vm, (burley)

Re: i18n of egcs

[alex.buell]

On 28 Apr 1999 craig@jcb-sc.com wrote:

> (It is one thing for a *speaker* to choose the "most appropriate" term
> or phrase.  It is quite another for a *listener* to insist on only
> that one most appropriate term, rejecting any other.  In this case,
> plenty of people already acquainted with the ANSI C standard as such
> should not be forced to learn to say "ISO C" all the time.  *We* (egcs
> developers) force *ourselves* to say that, because we're essentially
> in the role of "public speakers" here.  That doesn't mean we should
> force *everyone* to use "ISO C", even on command-line options.)

May I add my 0.02 euros here. I, as an European, would much prefer to see
the -iso option included - maybe aliased to -ansi, I understand ISO and
ANSI are one and the same, are they not? The rest of the world *is* bigger
than America even if their military forces *are* bigger.  8)

Cheers,
Alex
--
"A mind opened by new ideas cannot return to its original limits"

http://www.tahallah.demon.co.uk

Re: i18n of egcs

[craig]

>On 28 Apr 1999 craig@jcb-sc.com wrote:
>
>> (It is one thing for a *speaker* to choose the "most appropriate" term
>> or phrase.  It is quite another for a *listener* to insist on only
>> that one most appropriate term, rejecting any other.  In this case,
>> plenty of people already acquainted with the ANSI C standard as such
>> should not be forced to learn to say "ISO C" all the time.  *We* (egcs
>> developers) force *ourselves* to say that, because we're essentially
>> in the role of "public speakers" here.  That doesn't mean we should
>> force *everyone* to use "ISO C", even on command-line options.)
>
>May I add my 0.02 euros here. I, as an European, would much prefer to see
>the -iso option included - maybe aliased to -ansi, I understand ISO and
>ANSI are one and the same, are they not? The rest of the world *is* bigger
>than America even if their military forces *are* bigger.  8)

That wasn't the issue.  I was responding to the issue of whether,
in introducing `-iso', the `-ansi' option should be *dropped*.

Just because ISO C == ANSI C does not mean people should be forbidden
from asking for ANSI C compliance, just as they're not forced to
invoke `gisoc' instead of `gcc' to compile their C programs.

        tq vm, (burley)

P.S. At current rates, by about mid next week, America's military
forces probably won't be bigger than the Euros', anyway.  :)

Re: i18n of egcs

[alex.buell]

On 28 Apr 1999 craig@jcb-sc.com wrote:

> That wasn't the issue.  I was responding to the issue of whether, in
> introducing `-iso', the `-ansi' option should be *dropped*.

Sorry, I must have misread it (I plead innocent on the grounds that at
time of writing I was wrestling with Microsoft Visual C++ 5.0 - there are
days where I feel like smashing that emergency cabinet and getting that
axe out and dismembering all the Microsoft CDs into tiny bits). I don't
think we should drop the -ansi option for compatibility reasons, but
rather introduce -iso as an aliased flag. Then everyone's happy, yes?
 
> Just because ISO C == ANSI C does not mean people should be forbidden
> from asking for ANSI C compliance, just as they're not forced to
> invoke `gisoc' instead of `gcc' to compile their C programs.

Ah, I most definitely did not intend to imply that.

Cheers,
Alex
--
"A mind opened by new ideas cannot return to its original limits"

http://www.tahallah.demon.co.uk

Re: i18n of egcs

[Martin v. Loewis]

> I don't think we should drop the -ansi option for compatibility
> reasons, but rather introduce -iso as an aliased flag. Then
> everyone's happy, yes?

Well, I'd like to speak against a -iso option, and no, I don't request
a -din option :-)

There are many ISO standards out there: ISO C-90 (what is the
number?), ISO 14882 'Programming Languages - C++' 1998, and soon ISO C
99. I believe ISO has standards for Pascal and Fortran as well.  There
is already a scheme how enforcing a specific standard can be requested
from the compiler.

If the option is changed, I'd rather like it to be -standard-c,
-standard-c++, or even -x iso-c, -x iso-c++.

Regards,
Martin

Re: i18n of egcs

[Zack Weinberg]

On Thu, 29 Apr 1999 00:40:48 +0200, "Martin v. Loewis" wrote:
>> I don't think we should drop the -ansi option for compatibility
>> reasons, but rather introduce -iso as an aliased flag. Then
>> everyone's happy, yes?
>
>Well, I'd like to speak against a -iso option, and no, I don't request
>a -din option :-)
[...]
>If the option is changed, I'd rather like it to be -standard-c,
>-standard-c++, or even -x iso-c, -x iso-c++.

What was wrong with -std=c89 or -std=iso9899:1990 ?

zw

Re: i18n of egcs

[Martin v. Loewis]

> What was wrong with -std=c89 or -std=iso9899:1990 ?

Nothing. I just question whether an -iso option is still justified, in
the presence of these options.

Regards,
Martin

Re: i18n of egcs

[Gabriel Dos_Reis]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

| > What was wrong with -std=c89 or -std=iso9899:1990 ?
| 
| Nothing. I just question whether an -iso option is still justified, in
| the presence of these options.

Well, we can have a -iso option that defaults to the current standard
which can be overriden by -std= option. No? 

	gcc -iso 	# same as gcc -iso -std=c90 or gcc -ansi
	gcc -iso -std=c9x

-- Gaby

Re: i18n of egcs

[Joe Buck]

> Well, we can have a -iso option that defaults to the current standard
> which can be overriden by -std= option. No? 

Certainly.  Let -iso mean "the ISO standard currently in effect for
the language in use", same for -ansi/ANSI standard.  For C and C++,
the two are the same.

> 	gcc -iso 	# same as gcc -iso -std=c90 or gcc -ansi
> 	gcc -iso -std=c9x
> 
> -- Gaby
> 

Re: i18n of egcs

[craig]

>> Well, we can have a -iso option that defaults to the current standard
>> which can be overriden by -std= option. No? 
>
>Certainly.  Let -iso mean "the ISO standard currently in effect for
>the language in use", same for -ansi/ANSI standard.  For C and C++,
>the two are the same.

And remember, we were discussing having `-iso' have the same *effect*
as `-ansi'.

So, the purpose of `-iso' would be basically the same as `-ansi', and, as
Joe rightly explains, for C/C++, it would be *exactly* the same, since
the prevailing ISO and ANSI standards are identical.

At least, it is my feeling that the purpose of `-ansi' and `-iso' are to
tell the compiler that the language is "strict" ANSI/ISO *whatever*,
depending on what is being compiled.  Specifying *whatever* is done
via the filename suffix, `-x', and `-std'.  And `-pedantic' turns on
even stricter checking than is necessary to compile ANSI/ISO-conforming
code, as explained in the gcc docs for `-ansi'.

What's unclear is how gcc is supposed to handle `-std=iso-something -ansi'.
My suggestion is, anytime the ISO standard explicitly prevails (either
via command-line option or via input language), `-ansi' has no effect
*for that source file*, but might still affect others.

(Unfortunately, I can't find `-std=' documented in egcs/gcc/invoke.texi,
so I don't know whether it's intended to just specify the standard for
files determined, by other means, to be of the pertinent language, or
to have the effect of specifying that language, like `-x'.)

        tq vm, (burley)

Re: i18n of egcs

[Joern Rennecke]

> So, the purpose of `-iso' would be basically the same as `-ansi', and, as
> Joe rightly explains, for C/C++, it would be *exactly* the same, since
> the prevailing ISO and ANSI standards are identical.

Well, if at any time in the future we add an option to give verbose
warnings / error messages that quote the appropriate section and
paragraph of the standard, these options will be different.

Re: i18n of egcs

[Philipp Thomas]

On Thu, 29 Apr 1999 16:16:54 +0100 (BST), you wrote:

>Well, if at any time in the future we add an option to give verbose
>warnings / error messages that quote the appropriate section and
>paragraph of the standard, these options will be different.

Well, I at least pray that I'll never see that day. Quite a few messages
current compilers spit out are too closely modeled after the respective
parts of the standard and thus readily understandable only by compiler
developers or language lawyers. That , IMO, is exactly the wrong direction.



Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Philipp Thomas]

On Thu, 29 Apr 1999 16:16:54 +0100 (BST), you wrote:

>Well, if at any time in the future we add an option to give verbose
>warnings / error messages that quote the appropriate section and
>paragraph of the standard, these options will be different.

Well, I at least pray that I'll never see that day. Quite a few messages
current compilers spit out are too closely modeled after the respective
parts of the standard and thus readily understandable only by compiler
developers or language lawyers. That , IMO, is exactly the wrong direction.



Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Steinar Bang]

>>>>> kthomas@gwdg.de (Philipp Thomas):

> On Thu, 29 Apr 1999 16:16:54 +0100 (BST), you wrote:
>> Well, if at any time in the future we add an option to give verbose
>> warnings / error messages that quote the appropriate section and
>> paragraph of the standard, these options will be different.

> Well, I at least pray that I'll never see that day. Quite a few
> messages current compilers spit out are too closely modeled after
> the respective parts of the standard and thus readily understandable
> only by compiler developers or language lawyers. That , IMO, is
> exactly the wrong direction.

As long as they're explicitly turned on by a command line option, I
don't see the problem.  They would be only be requested by people
wanting them, no...?

Re: i18n of egcs

[Steinar Bang]

>>>>> kthomas@gwdg.de (Philipp Thomas):

> On Thu, 29 Apr 1999 16:16:54 +0100 (BST), you wrote:
>> Well, if at any time in the future we add an option to give verbose
>> warnings / error messages that quote the appropriate section and
>> paragraph of the standard, these options will be different.

> Well, I at least pray that I'll never see that day. Quite a few
> messages current compilers spit out are too closely modeled after
> the respective parts of the standard and thus readily understandable
> only by compiler developers or language lawyers. That , IMO, is
> exactly the wrong direction.

As long as they're explicitly turned on by a command line option, I
don't see the problem.  They would be only be requested by people
wanting them, no...?

Re: i18n of egcs

[Joern Rennecke]

> So, the purpose of `-iso' would be basically the same as `-ansi', and, as
> Joe rightly explains, for C/C++, it would be *exactly* the same, since
> the prevailing ISO and ANSI standards are identical.

Well, if at any time in the future we add an option to give verbose
warnings / error messages that quote the appropriate section and
paragraph of the standard, these options will be different.

Re: i18n of egcs

[craig]

>> Well, we can have a -iso option that defaults to the current standard
>> which can be overriden by -std= option. No? 
>
>Certainly.  Let -iso mean "the ISO standard currently in effect for
>the language in use", same for -ansi/ANSI standard.  For C and C++,
>the two are the same.

And remember, we were discussing having `-iso' have the same *effect*
as `-ansi'.

So, the purpose of `-iso' would be basically the same as `-ansi', and, as
Joe rightly explains, for C/C++, it would be *exactly* the same, since
the prevailing ISO and ANSI standards are identical.

At least, it is my feeling that the purpose of `-ansi' and `-iso' are to
tell the compiler that the language is "strict" ANSI/ISO *whatever*,
depending on what is being compiled.  Specifying *whatever* is done
via the filename suffix, `-x', and `-std'.  And `-pedantic' turns on
even stricter checking than is necessary to compile ANSI/ISO-conforming
code, as explained in the gcc docs for `-ansi'.

What's unclear is how gcc is supposed to handle `-std=iso-something -ansi'.
My suggestion is, anytime the ISO standard explicitly prevails (either
via command-line option or via input language), `-ansi' has no effect
*for that source file*, but might still affect others.

(Unfortunately, I can't find `-std=' documented in egcs/gcc/invoke.texi,
so I don't know whether it's intended to just specify the standard for
files determined, by other means, to be of the pertinent language, or
to have the effect of specifying that language, like `-x'.)

        tq vm, (burley)

Re: i18n of egcs

[Joe Buck]

> Well, we can have a -iso option that defaults to the current standard
> which can be overriden by -std= option. No? 

Certainly.  Let -iso mean "the ISO standard currently in effect for
the language in use", same for -ansi/ANSI standard.  For C and C++,
the two are the same.

> 	gcc -iso 	# same as gcc -iso -std=c90 or gcc -ansi
> 	gcc -iso -std=c9x
> 
> -- Gaby
> 

Re: i18n of egcs

[Gabriel Dos_Reis]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

| > What was wrong with -std=c89 or -std=iso9899:1990 ?
| 
| Nothing. I just question whether an -iso option is still justified, in
| the presence of these options.

Well, we can have a -iso option that defaults to the current standard
which can be overriden by -std= option. No? 

	gcc -iso 	# same as gcc -iso -std=c90 or gcc -ansi
	gcc -iso -std=c9x

-- Gaby

Re: i18n of egcs

[Richard Henderson]

On Thu, Apr 29, 1999 at 08:10:42AM +0200, Martin v. Loewis wrote:
> > What was wrong with -std=c89 or -std=iso9899:1990 ?
> 
> Nothing. I just question whether an -iso option is still justified, in
> the presence of these options.

I would really really prefer that we didn't add an `-iso' option.

The specs are quite ugly enough already having to handle `-ansi'
in addition to `-std=[!gnu]'.  I'd kill the `-ansi' option entirely
if I thought we could get away with it.


r~

Re: i18n of egcs

[Richard Henderson]

On Thu, Apr 29, 1999 at 08:10:42AM +0200, Martin v. Loewis wrote:
> > What was wrong with -std=c89 or -std=iso9899:1990 ?
> 
> Nothing. I just question whether an -iso option is still justified, in
> the presence of these options.

I would really really prefer that we didn't add an `-iso' option.

The specs are quite ugly enough already having to handle `-ansi'
in addition to `-std=[!gnu]'.  I'd kill the `-ansi' option entirely
if I thought we could get away with it.


r~

Re: i18n of egcs

[Martin v. Loewis]

> What was wrong with -std=c89 or -std=iso9899:1990 ?

Nothing. I just question whether an -iso option is still justified, in
the presence of these options.

Regards,
Martin

Re: i18n of egcs

[Zack Weinberg]

On Thu, 29 Apr 1999 00:40:48 +0200, "Martin v. Loewis" wrote:
>> I don't think we should drop the -ansi option for compatibility
>> reasons, but rather introduce -iso as an aliased flag. Then
>> everyone's happy, yes?
>
>Well, I'd like to speak against a -iso option, and no, I don't request
>a -din option :-)
[...]
>If the option is changed, I'd rather like it to be -standard-c,
>-standard-c++, or even -x iso-c, -x iso-c++.

What was wrong with -std=c89 or -std=iso9899:1990 ?

zw

Re: i18n of egcs

[Martin v. Loewis]

> I don't think we should drop the -ansi option for compatibility
> reasons, but rather introduce -iso as an aliased flag. Then
> everyone's happy, yes?

Well, I'd like to speak against a -iso option, and no, I don't request
a -din option :-)

There are many ISO standards out there: ISO C-90 (what is the
number?), ISO 14882 'Programming Languages - C++' 1998, and soon ISO C
99. I believe ISO has standards for Pascal and Fortran as well.  There
is already a scheme how enforcing a specific standard can be requested
from the compiler.

If the option is changed, I'd rather like it to be -standard-c,
-standard-c++, or even -x iso-c, -x iso-c++.

Regards,
Martin

Re: i18n of egcs

[alex.buell]

On 28 Apr 1999 craig@jcb-sc.com wrote:

> That wasn't the issue.  I was responding to the issue of whether, in
> introducing `-iso', the `-ansi' option should be *dropped*.

Sorry, I must have misread it (I plead innocent on the grounds that at
time of writing I was wrestling with Microsoft Visual C++ 5.0 - there are
days where I feel like smashing that emergency cabinet and getting that
axe out and dismembering all the Microsoft CDs into tiny bits). I don't
think we should drop the -ansi option for compatibility reasons, but
rather introduce -iso as an aliased flag. Then everyone's happy, yes?
 
> Just because ISO C == ANSI C does not mean people should be forbidden
> from asking for ANSI C compliance, just as they're not forced to
> invoke `gisoc' instead of `gcc' to compile their C programs.

Ah, I most definitely did not intend to imply that.

Cheers,
Alex
--
"A mind opened by new ideas cannot return to its original limits"

http://www.tahallah.demon.co.uk

Re: i18n of egcs

[craig]

>On 28 Apr 1999 craig@jcb-sc.com wrote:
>
>> (It is one thing for a *speaker* to choose the "most appropriate" term
>> or phrase.  It is quite another for a *listener* to insist on only
>> that one most appropriate term, rejecting any other.  In this case,
>> plenty of people already acquainted with the ANSI C standard as such
>> should not be forced to learn to say "ISO C" all the time.  *We* (egcs
>> developers) force *ourselves* to say that, because we're essentially
>> in the role of "public speakers" here.  That doesn't mean we should
>> force *everyone* to use "ISO C", even on command-line options.)
>
>May I add my 0.02 euros here. I, as an European, would much prefer to see
>the -iso option included - maybe aliased to -ansi, I understand ISO and
>ANSI are one and the same, are they not? The rest of the world *is* bigger
>than America even if their military forces *are* bigger.  8)

That wasn't the issue.  I was responding to the issue of whether,
in introducing `-iso', the `-ansi' option should be *dropped*.

Just because ISO C == ANSI C does not mean people should be forbidden
from asking for ANSI C compliance, just as they're not forced to
invoke `gisoc' instead of `gcc' to compile their C programs.

        tq vm, (burley)

P.S. At current rates, by about mid next week, America's military
forces probably won't be bigger than the Euros', anyway.  :)

Re: i18n of egcs

[alex.buell]

On 28 Apr 1999 craig@jcb-sc.com wrote:

> (It is one thing for a *speaker* to choose the "most appropriate" term
> or phrase.  It is quite another for a *listener* to insist on only
> that one most appropriate term, rejecting any other.  In this case,
> plenty of people already acquainted with the ANSI C standard as such
> should not be forced to learn to say "ISO C" all the time.  *We* (egcs
> developers) force *ourselves* to say that, because we're essentially
> in the role of "public speakers" here.  That doesn't mean we should
> force *everyone* to use "ISO C", even on command-line options.)

May I add my 0.02 euros here. I, as an European, would much prefer to see
the -iso option included - maybe aliased to -ansi, I understand ISO and
ANSI are one and the same, are they not? The rest of the world *is* bigger
than America even if their military forces *are* bigger.  8)

Cheers,
Alex
--
"A mind opened by new ideas cannot return to its original limits"

http://www.tahallah.demon.co.uk

Re: i18n of egcs

[Gabriel Dos_Reis]

craig@jcb-sc.com writes:

| >Maybe the flag for strict ISO compliance should change from -ansi to
| >-iso as well? (should one keep the old flag for backwards
| >compatibility or is that just useless baggage that should be
| >discarded?) 
| 
| Keep the old flag.  There *is* still an ANSI C standard that gcc
| supports, I believe!

As far as I can tell, ANSI C89 is the *same* as ISO C90 with chapters
renumbered. But I would not insist for ANSI C; my primary goal is C++
even though I'll *much* prefer EGCS be refering to ISO C.

-- Gaby

Re: i18n of egcs

[Gabriel Dos_Reis]

craig@jcb-sc.com writes:

| >Maybe the flag for strict ISO compliance should change from -ansi to
| >-iso as well? (should one keep the old flag for backwards
| >compatibility or is that just useless baggage that should be
| >discarded?) 
| 
| Keep the old flag.  There *is* still an ANSI C standard that gcc
| supports, I believe!

As far as I can tell, ANSI C89 is the *same* as ISO C90 with chapters
renumbered. But I would not insist for ANSI C; my primary goal is C++
even though I'll *much* prefer EGCS be refering to ISO C.

-- Gaby

Re: i18n of egcs

[craig]

>Maybe the flag for strict ISO compliance should change from -ansi to
>-iso as well? (should one keep the old flag for backwards
>compatibility or is that just useless baggage that should be
>discarded?) 

Keep the old flag.  There *is* still an ANSI C standard that gcc
supports, I believe!

(It is one thing for a *speaker* to choose the "most appropriate" term
or phrase.  It is quite another for a *listener* to insist on only
that one most appropriate term, rejecting any other.  In this case,
plenty of people already acquainted with the ANSI C standard as such
should not be forced to learn to say "ISO C" all the time.  *We* (egcs
developers) force *ourselves* to say that, because we're essentially
in the role of "public speakers" here.  That doesn't mean we should
force *everyone* to use "ISO C", even on command-line options.)

        tq vm, (burley)

Re: i18n of egcs

[Steinar Bang]

>>>>> kthomas@gwdg.de (Philipp Thomas):

> Gabriel,
> On 27 Apr 1999 22:06:20 +0200, you wrote:

>> As a related issue, I suggested some time ago --and several
>> people seemed to agree with me-- that error message like:
>> 
>>	"ANSI C++ forbids..."
>> 
>> should read 
>> 
>>	"ISO C++ forbids..."

> Thanks for bringing this up. I wanted to but totally forgot about
> it. I'd like to add that this also applies to C, i.e. egcs really
> should say ISO C and ISO C++ where at the moment it says ANSI C and
> ANSI C++.

Maybe the flag for strict ISO compliance should change from -ansi to
-iso as well? (should one keep the old flag for backwards
compatibility or is that just useless baggage that should be
discarded?) 

Re: i18n of egcs

[Philipp Thomas]

Gabriel,

On 27 Apr 1999 22:06:20 +0200, you wrote:

>	As a related issue, I suggested some time ago --and several
>people seemed to agree with me-- that error message like:
>
>	"ANSI C++ forbids..."
>
>should read 
>
>	"ISO C++ forbids..."
>

Thanks for bringing this up. I wanted to but totally forgot about it. I'd like
to add that this also applies to C, i.e. egcs really should say ISO C and ISO
C++ where at the moment it says ANSI C and ANSI C++.

Jeff, if it's OK with you, I'd send in the patches to change this for both C
and C++. I already did most of them and would only need to bring them up to
date.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Jeffrey A Law]

  In message < xajvhehhlqb.fsf@korrigan.inria.fr >you write:
  > 	As a related issue, I suggested some time ago --and several
  > people seemed to agree with me-- that error message like:
  > 
  > 	"ANSI C++ forbids..."
  > 
  > should read 
  > 
  > 	"ISO C++ forbids..."
  > 
  > but EGCS still insists with "ANSI C++" :-(
  > 
  > I'd suggest that people involded in NLS translate "ANSI C++" to 
  > "ISO C++". Of course things would be less confusing if "ISO C++"
  > appears in EGCS' primary output...
You're probably correct.  A patch to fix this would be appreciated.

jeff

Re: i18n of egcs

[Jeffrey A Law]

  In message < xajvhehhlqb.fsf@korrigan.inria.fr >you write:
  > 	As a related issue, I suggested some time ago --and several
  > people seemed to agree with me-- that error message like:
  > 
  > 	"ANSI C++ forbids..."
  > 
  > should read 
  > 
  > 	"ISO C++ forbids..."
  > 
  > but EGCS still insists with "ANSI C++" :-(
  > 
  > I'd suggest that people involded in NLS translate "ANSI C++" to 
  > "ISO C++". Of course things would be less confusing if "ISO C++"
  > appears in EGCS' primary output...
You're probably correct.  A patch to fix this would be appreciated.

jeff

Re: i18n of egcs

[Gabriel Dos_Reis]

Jeff --

	As a related issue, I suggested some time ago --and several
people seemed to agree with me-- that error message like:

	"ANSI C++ forbids..."

should read 

	"ISO C++ forbids..."

but EGCS still insists with "ANSI C++" :-(

I'd suggest that people involded in NLS translate "ANSI C++" to 
"ISO C++". Of course things would be less confusing if "ISO C++"
appears in EGCS' primary output...

-- Gaby

Re: i18n of egcs

[Jeffrey A Law]

  In message < 3728dd6b.52244689@mailer.gwdg.de >you write:
  > Some points should be noted for the future though. The generation of the
  > basic gcc.pot needs a modified gettext 0.10.35 (patch in ABOUT-GCC-NLS).
  > So in order to not require that an egcs user has to patch his gettext
  > package, your release scripts should generate a gcc.pot for inclusion into
  > the egcs releases,
Err, look in the "intl" subdirectory.  Isn't that the gettext code we need?  Is
there some reason it is not being used?  I thought the whole point behind
having a copy of the intl subdirectory was to deal with this issue.


jeff

Re: i18n of egcs

[Andreas Schwab]

Jeffrey A Law <law@upchuck.cygnus.com> writes:

|>   In message < 3728dd6b.52244689@mailer.gwdg.de >you write:
|>   > Some points should be noted for the future though. The generation of the
|>   > basic gcc.pot needs a modified gettext 0.10.35 (patch in ABOUT-GCC-NLS).
|>   > So in order to not require that an egcs user has to patch his gettext
|>   > package, your release scripts should generate a gcc.pot for inclusion into
|>   > the egcs releases,
|> Err, look in the "intl" subdirectory.  Isn't that the gettext code we need?

No, it only contains the library code, but not the (modified) xgettext
program that is used to extract the strings to be translated.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: i18n of egcs

[Andreas Schwab]

Jeffrey A Law <law@upchuck.cygnus.com> writes:

|>   In message < 3728dd6b.52244689@mailer.gwdg.de >you write:
|>   > Some points should be noted for the future though. The generation of the
|>   > basic gcc.pot needs a modified gettext 0.10.35 (patch in ABOUT-GCC-NLS).
|>   > So in order to not require that an egcs user has to patch his gettext
|>   > package, your release scripts should generate a gcc.pot for inclusion into
|>   > the egcs releases,
|> Err, look in the "intl" subdirectory.  Isn't that the gettext code we need?

No, it only contains the library code, but not the (modified) xgettext
program that is used to extract the strings to be translated.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: i18n of egcs

[Philipp Thomas]

On Fri, 30 Apr 1999 01:22:57 -0600, you wrote:

>Err, look in the "intl" subdirectory.  Isn't that the gettext code we need?  Is
>there some reason it is not being used?  I thought the whole point behind
>having a copy of the intl subdirectory was to deal with this issue.

No, as Andreas already wrote, the "intl" subdirectory really should be named
libintl as it only contains the code for the libintl library, not for the
gettext tools. It *is* used if either autoconf doesn't detect system support
for i18n message catalogs or the user specifically asks for it via
--with-included-gettext.

So we have three possible ways of dealing with the problem: 

  1) convince Ulrich to make a new gettext release incorporating Pauls
     changes.
  2) add the modified gettext to the egcs package.
  3) Simply generate the necessary gcc.pot for snapshots and releases.

In my eyes, the third possibility is the easiest (short term) solution, as it
only requires that the user has a regular gettext package installed.

We will certainly have to think about a better solution once we really start
supporting NLS throughout the egcs package.

I have started an i18n todo list where I record observations made while
working on broadening the support and ideas for solutions that come up. I
intend to post it after we make the 1.2 branch.
I have also written a list of things egcs developers should be aware of as to
ease the work of translation which I'll also post after the branch.

And finally some good news. I finally got answer from the FSF translation
project maintainer on how to proceed. And if I'm convinced that I detected all
places in C,C++ and Java that need translation and if egcs still boots and
works with the changes I made to the code, I'll send my gcc.pot to the
translation robot to get the translations rolling.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Philipp Thomas]

On Fri, 30 Apr 1999 01:22:57 -0600, you wrote:

>Err, look in the "intl" subdirectory.  Isn't that the gettext code we need?  Is
>there some reason it is not being used?  I thought the whole point behind
>having a copy of the intl subdirectory was to deal with this issue.

No, as Andreas already wrote, the "intl" subdirectory really should be named
libintl as it only contains the code for the libintl library, not for the
gettext tools. It *is* used if either autoconf doesn't detect system support
for i18n message catalogs or the user specifically asks for it via
--with-included-gettext.

So we have three possible ways of dealing with the problem: 

  1) convince Ulrich to make a new gettext release incorporating Pauls
     changes.
  2) add the modified gettext to the egcs package.
  3) Simply generate the necessary gcc.pot for snapshots and releases.

In my eyes, the third possibility is the easiest (short term) solution, as it
only requires that the user has a regular gettext package installed.

We will certainly have to think about a better solution once we really start
supporting NLS throughout the egcs package.

I have started an i18n todo list where I record observations made while
working on broadening the support and ideas for solutions that come up. I
intend to post it after we make the 1.2 branch.
I have also written a list of things egcs developers should be aware of as to
ease the work of translation which I'll also post after the branch.

And finally some good news. I finally got answer from the FSF translation
project maintainer on how to proceed. And if I'm convinced that I detected all
places in C,C++ and Java that need translation and if egcs still boots and
works with the changes I made to the code, I'll send my gcc.pot to the
translation robot to get the translations rolling.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Jeffrey A Law]

  In message <373418af.55753686@mailer.gwdg.de>you write:
  > No, as Andreas already wrote, the "intl" subdirectory really should be name
  > libintl as it only contains the code for the libintl library, not for the
Bummer....


  > So we have three possible ways of dealing with the problem: 
  > 
  >   1) convince Ulrich to make a new gettext release incorporating Pauls
  >      changes.
  >   2) add the modified gettext to the egcs package.
  >   3) Simply generate the necessary gcc.pot for snapshots and releases.
I agree with you, I think #3 is the best short term...

jeff

Re: i18n of egcs

[Jeffrey A Law]

  In message <373418af.55753686@mailer.gwdg.de>you write:
  > No, as Andreas already wrote, the "intl" subdirectory really should be name
  > libintl as it only contains the code for the libintl library, not for the
Bummer....


  > So we have three possible ways of dealing with the problem: 
  > 
  >   1) convince Ulrich to make a new gettext release incorporating Pauls
  >      changes.
  >   2) add the modified gettext to the egcs package.
  >   3) Simply generate the necessary gcc.pot for snapshots and releases.
I agree with you, I think #3 is the best short term...

jeff

Re: i18n of egcs

[Jeffrey A Law]

  In message <373418af.55753686@mailer.gwdg.de>you write:

[ Problem of getting correct .pot files into the release ]
  > So we have three possible ways of dealing with the problem: 
  > 
  >   1) convince Ulrich to make a new gettext release incorporating Pauls
  >      changes.
  >   2) add the modified gettext to the egcs package.
  >   3) Simply generate the necessary gcc.pot for snapshots and releases.
So, what is the procedure for #3?  I'm not at all familiar with gettext, so
I don't know how to generate those files.

jeff

Re: i18n of egcs

[Jeffrey A Law]

  In message <373418af.55753686@mailer.gwdg.de>you write:

[ Problem of getting correct .pot files into the release ]
  > So we have three possible ways of dealing with the problem: 
  > 
  >   1) convince Ulrich to make a new gettext release incorporating Pauls
  >      changes.
  >   2) add the modified gettext to the egcs package.
  >   3) Simply generate the necessary gcc.pot for snapshots and releases.
So, what is the procedure for #3?  I'm not at all familiar with gettext, so
I don't know how to generate those files.

jeff

Re: i18n of egcs

[Jeffrey A Law]

  In message < 3728dd6b.52244689@mailer.gwdg.de >you write:
  > Some points should be noted for the future though. The generation of the
  > basic gcc.pot needs a modified gettext 0.10.35 (patch in ABOUT-GCC-NLS).
  > So in order to not require that an egcs user has to patch his gettext
  > package, your release scripts should generate a gcc.pot for inclusion into
  > the egcs releases,
Err, look in the "intl" subdirectory.  Isn't that the gettext code we need?  Is
there some reason it is not being used?  I thought the whole point behind
having a copy of the intl subdirectory was to deal with this issue.


jeff

i18n of egcs

[Philipp Thomas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

Jeff,
I've nearly finished translating egcs's messages into german and will send the
translation to people from the german translation team who volunteered to
proofread my work in a day or two. I *still* haven't got any answer from
François Pinoir, the maintainer for the FSF translation project, so this will
likely be the only translation for the time being.

Some points should be noted for the future though. The generation of the basic
gcc.pot needs a modified gettext 0.10.35 (patch in ABOUT-GCC-NLS).
So in order to not require that an egcs user has to patch his gettext package,
your release scripts should generate a gcc.pot for inclusion into the egcs
releases, as the modified xgettext is only need for the extraction of the
messages from the source code. Updating the translations (xx.po) and compiling
them can be done with an unmodified gettext package.

The second point is that it should be stated somewhere in the top level
documentation, that anyone who uses NLS and modifies the code needs the
patched gettext.

I think it would be a good idea to modify the top level configure to run sub
level configures when called with --help to get a list of the optional
parameters that may be passed to them. What do you think ?




Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Mike Stump]

> To: law@cygnus.com, egcs@egcs.cygnus.com
> Cc: kthomas@gwdg.de (Philipp Thomas)
> From: Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr>
> Date: 27 Apr 1999 22:06:20 +0200

> should read 

> 	"ISO C++ forbids..."

> I'd suggest that people involded in NLS translate "ANSI C++" to "ISO
> C++".

Sounds fine (or one can substitute the name of the National Standards
body, if one wants).

Re: i18n of egcs

[Mike Stump]

> To: law@cygnus.com, egcs@egcs.cygnus.com
> Cc: kthomas@gwdg.de (Philipp Thomas)
> From: Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr>
> Date: 27 Apr 1999 22:06:20 +0200

> should read 

> 	"ISO C++ forbids..."

> I'd suggest that people involded in NLS translate "ANSI C++" to "ISO
> C++".

Sounds fine (or one can substitute the name of the National Standards
body, if one wants).

Re: i18n of egcs

[Mike Stump]

> From: kthomas@gwdg.de (Philipp Thomas)
> Date: Mon, 05 Apr 1999 00:57:25 GMT

> > http://egcs.cygnus.com/cvs.html

> Forgive me please, but I do know how to access the cvs repository,
> what I looked for was a way to synch two repositories. Or was I
> partially blinded when looking at the page.

Oh... Got it.  What part of the cvs documentation that explains this
in complete detail was unclear?

Hint, see importing an outside source base.  Consider egcs an outside
source base.

Re: i18n of egcs

[Mike Stump]

> From: kthomas@gwdg.de (Philipp Thomas)
> Date: Mon, 05 Apr 1999 00:57:25 GMT

> > http://egcs.cygnus.com/cvs.html

> Forgive me please, but I do know how to access the cvs repository,
> what I looked for was a way to synch two repositories. Or was I
> partially blinded when looking at the page.

Oh... Got it.  What part of the cvs documentation that explains this
in complete detail was unclear?

Hint, see importing an outside source base.  Consider egcs an outside
source base.

i18n of egcs

[Philipp Thomas]

Yes, I know this is post 1.2 stuff, but as it looks like this could be
a way for me to contribute to egcs, I've started to track down all
that's necessary for complete i18n of egcs. 

Now before I go down the wrong path(s) I would like to get some input
for questions I have.

In the case of back/front ends the mechanism (as described in the
documentation) is clear: No direct calls to gettext(), the code doing
the output is responsible for getting messages translated. So xgettext
just needs to be told which keywords to look for and static strings
like help text for options marked.

But what should be done for the libraries ? As I see it, there is no
other way but to use direct gettext() calls. Or do the libraries also
have central functions for dealing with errors/warnings (haven't come
to inspecting the library code yet) ? And in order to keep the
installed stuff small, I'd say that the lang specific libraries should
have their own message catalogs, even if that gets a bit hairy wrt the
Makefile(s).

If any of you would share his/her thoughts and comments with me I'd be
very grateful.

BTW, anybody got hints/pointers for me (most probably better via
direct email) for how to setup my own cvs tree for egcs and then keep
it in sync with the cygnus tree ?

Philipp

---  caffeine low - brain halted

i18n of egcs

[Philipp Thomas]

Yes, I know this is post 1.2 stuff, but as it looks like this could be
a way for me to contribute to egcs, I've started to track down all
that's necessary for complete i18n of egcs. 

Now before I go down the wrong path(s) I would like to get some input
for questions I have.

In the case of back/front ends the mechanism (as described in the
documentation) is clear: No direct calls to gettext(), the code doing
the output is responsible for getting messages translated. So xgettext
just needs to be told which keywords to look for and static strings
like help text for options marked.

But what should be done for the libraries ? As I see it, there is no
other way but to use direct gettext() calls. Or do the libraries also
have central functions for dealing with errors/warnings (haven't come
to inspecting the library code yet) ? And in order to keep the
installed stuff small, I'd say that the lang specific libraries should
have their own message catalogs, even if that gets a bit hairy wrt the
Makefile(s).

If any of you would share his/her thoughts and comments with me I'd be
very grateful.

BTW, anybody got hints/pointers for me (most probably better via
direct email) for how to setup my own cvs tree for egcs and then keep
it in sync with the cygnus tree ?

Philipp

---  caffeine low - brain halted

Re: i18n of egcs

[Jeffrey A Law]

  In message <36fd0b95.68382744@mailer.gwdg.de>you write:
  > In the case of back/front ends the mechanism (as described in the
  > documentation) is clear: No direct calls to gettext(), the code doing
  > the output is responsible for getting messages translated. So xgettext
  > just needs to be told which keywords to look for and static strings
  > like help text for options marked.
So presumably the backends should call one of the basic error handling routines
in toplev.c to output error messages without the '_' magic and let the basic
error handling routines handle translation.

  > But what should be done for the libraries ? As I see it, there is no
  > other way but to use direct gettext() calls. Or do the libraries also
  > have central functions for dealing with errors/warnings (haven't come
  > to inspecting the library code yet) ?
I'm willing to punt the library issue temporarily and instead concentrate on
gcc itself.  At some point we'll need a good way to make libiberty i18n
aware.

  > And in order to keep the
  > installed stuff small, I'd say that the lang specific libraries should
  > have their own message catalogs, even if that gets a bit hairy wrt the
  > Makefile(s).
Hmmm.  This is a good issue to think about.  I suspect our desire to allow
folks to pick up just the compilers they need will probably mandate this kind
of a scheme anyway. 


  > BTW, anybody got hints/pointers for me (most probably better via
  > direct email) for how to setup my own cvs tree for egcs and then keep
  > it in sync with the cygnus tree ?
There's a link to the CVS stuff from the egcs home page.  But I'll save
you the trouble and give you the direct URL:

http://egcs.cygnus.com/cvs.html

jeff

Re: i18n of egcs

[Philipp Thomas]

On Sat, 03 Apr 1999 22:17:55 -0700, you wrote:

>So presumably the backends should call one of the basic error handling routines
>in toplev.c to output error messages without the '_' magic and let the basic
>error handling routines handle translation.

Exactly so :) If the backends don't output the help (-v --help)
themselves, then no marking is necessary, even for the static strings.

>I'm willing to punt the library issue temporarily and instead concentrate on
>gcc itself.  At some point we'll need a good way to make libiberty i18n
>aware.

Given that making the libs i18n aware would be quite a job, I think it
is best to leave the libs for post 1.2 times.

>I suspect our desire to allow folks to pick up just the compilers they
>need will probably mandate this kind of a scheme anyway. 

That's why I brought it up. It wouldn't make much sense (besides
making our job quite a bit easier ;) otherwise.

> http://egcs.cygnus.com/cvs.html

Forgive me please, but I do know how to access the cvs repository,
what I looked for was a way to synch two repositories. Or was I
partially blinded when looking at the page.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Philipp Thomas]

On Sat, 03 Apr 1999 22:17:55 -0700, you wrote:

>So presumably the backends should call one of the basic error handling routines
>in toplev.c to output error messages without the '_' magic and let the basic
>error handling routines handle translation.

Exactly so :) If the backends don't output the help (-v --help)
themselves, then no marking is necessary, even for the static strings.

>I'm willing to punt the library issue temporarily and instead concentrate on
>gcc itself.  At some point we'll need a good way to make libiberty i18n
>aware.

Given that making the libs i18n aware would be quite a job, I think it
is best to leave the libs for post 1.2 times.

>I suspect our desire to allow folks to pick up just the compilers they
>need will probably mandate this kind of a scheme anyway. 

That's why I brought it up. It wouldn't make much sense (besides
making our job quite a bit easier ;) otherwise.

> http://egcs.cygnus.com/cvs.html

Forgive me please, but I do know how to access the cvs repository,
what I looked for was a way to synch two repositories. Or was I
partially blinded when looking at the page.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: i18n of egcs

[Jeffrey A Law]

  In message <36fd0b95.68382744@mailer.gwdg.de>you write:
  > In the case of back/front ends the mechanism (as described in the
  > documentation) is clear: No direct calls to gettext(), the code doing
  > the output is responsible for getting messages translated. So xgettext
  > just needs to be told which keywords to look for and static strings
  > like help text for options marked.
So presumably the backends should call one of the basic error handling routines
in toplev.c to output error messages without the '_' magic and let the basic
error handling routines handle translation.

  > But what should be done for the libraries ? As I see it, there is no
  > other way but to use direct gettext() calls. Or do the libraries also
  > have central functions for dealing with errors/warnings (haven't come
  > to inspecting the library code yet) ?
I'm willing to punt the library issue temporarily and instead concentrate on
gcc itself.  At some point we'll need a good way to make libiberty i18n
aware.

  > And in order to keep the
  > installed stuff small, I'd say that the lang specific libraries should
  > have their own message catalogs, even if that gets a bit hairy wrt the
  > Makefile(s).
Hmmm.  This is a good issue to think about.  I suspect our desire to allow
folks to pick up just the compilers they need will probably mandate this kind
of a scheme anyway. 


  > BTW, anybody got hints/pointers for me (most probably better via
  > direct email) for how to setup my own cvs tree for egcs and then keep
  > it in sync with the cygnus tree ?
There's a link to the CVS stuff from the egcs home page.  But I'll save
you the trouble and give you the direct URL:

http://egcs.cygnus.com/cvs.html

jeff