public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/18248] New: c_parse_error i18n problems
@ 2004-10-31 10:34 jsm28 at gcc dot gnu dot org
2004-10-31 10:44 ` [Bug c++/18248] " gdr at cs dot tamu dot edu
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2004-10-31 10:34 UTC (permalink / raw)
To: gcc-bugs
c_parse_error combines a string passed in with another part of a
sentence. Combining sentence fragments cannot work with i18n. The
source code must contain all the full sentences output even though this
bulks up the source by needing 8 different "expected .. before ..." in the
error function call for every parser error: only that way can all the
sentences be translated properly. Making each call pass eight arguments
rather than one is fortunately a fairly mechanical change, as the new
arguments are derived from the existing one in a fixed way.
(Formerly part of comment#7 in bug 17852.)
--
Summary: c_parse_error i18n problems
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18248
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/18248] c_parse_error i18n problems
2004-10-31 10:34 [Bug c++/18248] New: c_parse_error i18n problems jsm28 at gcc dot gnu dot org
@ 2004-10-31 10:44 ` gdr at cs dot tamu dot edu
2004-10-31 10:58 ` joseph at codesourcery dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: gdr at cs dot tamu dot edu @ 2004-10-31 10:44 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at cs dot tamu dot edu 2004-10-31 10:44 -------
Subject: Re: New: c_parse_error i18n problems
"jsm28 at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| c_parse_error combines a string passed in with another part of a
| sentence. Combining sentence fragments cannot work with i18n. The
| source code must contain all the full sentences output even though this
| bulks up the source by needing 8 different "expected .. before ..." in the
| error function call for every parser error: only that way can all the
| sentences be translated properly. Making each call pass eight arguments
| rather than one is fortunately a fairly mechanical change, as the new
| arguments are derived from the existing one in a fixed way.
Notice that in all the cases where the sentences are combined, the
parts all come from string lietrals. There ought to be a way to have
the compiler build those (kind of compile-time introspection facilities).
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18248
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/18248] c_parse_error i18n problems
2004-10-31 10:34 [Bug c++/18248] New: c_parse_error i18n problems jsm28 at gcc dot gnu dot org
2004-10-31 10:44 ` [Bug c++/18248] " gdr at cs dot tamu dot edu
@ 2004-10-31 10:58 ` joseph at codesourcery dot com
2004-10-31 14:11 ` gdr at cs dot tamu dot edu
2004-12-06 22:04 ` pinskia at gcc dot gnu dot org
3 siblings, 0 replies; 6+ messages in thread
From: joseph at codesourcery dot com @ 2004-10-31 10:58 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From joseph at codesourcery dot com 2004-10-31 10:58 -------
Subject: Re: c_parse_error i18n problems
On Sun, 31 Oct 2004, gdr at cs dot tamu dot edu wrote:
> Notice that in all the cases where the sentences are combined, the
> parts all come from string lietrals. There ought to be a way to have
> the compiler build those (kind of compile-time introspection facilities).
It's not the compiler that would need to build them, it's exgettext.
We've improved on xgettext's defaults with that wrapper which looks for
parameters called msgid, but at a certain point you reach excess
complexity and it would be better to write the source code in a more
i18n-friendly way.
One possibility I considered to avoid eight sentences everywhere is an
additional format escape, say %K, which takes a token as argument; a new
structure to store both token type and value as a single argument would be
needed. The messages would then be of the form "expected ';' before %K".
The trouble with this is that the token descriptions in c_parse_error
include pieces of English text as well as actual token text; though it
might be possible to change things so that the original token text from
cpplib is available for diagnostics and use something like "before <EOF>"
in place of "at end of input" so all the messages use a single form.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18248
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/18248] c_parse_error i18n problems
2004-10-31 10:34 [Bug c++/18248] New: c_parse_error i18n problems jsm28 at gcc dot gnu dot org
2004-10-31 10:44 ` [Bug c++/18248] " gdr at cs dot tamu dot edu
2004-10-31 10:58 ` joseph at codesourcery dot com
@ 2004-10-31 14:11 ` gdr at cs dot tamu dot edu
2004-12-06 22:04 ` pinskia at gcc dot gnu dot org
3 siblings, 0 replies; 6+ messages in thread
From: gdr at cs dot tamu dot edu @ 2004-10-31 14:11 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at cs dot tamu dot edu 2004-10-31 14:11 -------
Subject: Re: c_parse_error i18n problems
"joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| Subject: Re: c_parse_error i18n problems
|
| On Sun, 31 Oct 2004, gdr at cs dot tamu dot edu wrote:
|
| > Notice that in all the cases where the sentences are combined, the
| > parts all come from string lietrals. There ought to be a way to have
| > the compiler build those (kind of compile-time introspection facilities).
|
| It's not the compiler that would need to build them, it's exgettext.
Either of them, it depends on your perspective :-).
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18248
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/18248] c_parse_error i18n problems
2004-10-31 10:34 [Bug c++/18248] New: c_parse_error i18n problems jsm28 at gcc dot gnu dot org
` (2 preceding siblings ...)
2004-10-31 14:11 ` gdr at cs dot tamu dot edu
@ 2004-12-06 22:04 ` pinskia at gcc dot gnu dot org
3 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-12-06 22:04 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2004-12-06 22:04:21
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18248
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/18248] c_parse_error i18n problems
[not found] <bug-18248-4@http.gcc.gnu.org/bugzilla/>
@ 2011-12-14 9:45 ` manu at gcc dot gnu.org
0 siblings, 0 replies; 6+ messages in thread
From: manu at gcc dot gnu.org @ 2011-12-14 9:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18248
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |niva at niisi dot msk.ru
--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-12-14 09:44:16 UTC ---
*** Bug 51548 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-14 9:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-31 10:34 [Bug c++/18248] New: c_parse_error i18n problems jsm28 at gcc dot gnu dot org
2004-10-31 10:44 ` [Bug c++/18248] " gdr at cs dot tamu dot edu
2004-10-31 10:58 ` joseph at codesourcery dot com
2004-10-31 14:11 ` gdr at cs dot tamu dot edu
2004-12-06 22:04 ` pinskia at gcc dot gnu dot org
[not found] <bug-18248-4@http.gcc.gnu.org/bugzilla/>
2011-12-14 9:45 ` manu at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).