[Bug c++/40872] New: String not extracted for translation

On line 9382 of gcc/cp/decl.c there is this code

                error (funcdef_flag
                       ? "%qs defined in a non-class scope"
                       : "%qs declared in a non-class scope", name);

Normally the first argument of error will be extracted for translation.
Apparently the extractor is not smart enough to extract both branches of this
conditional expression, so only the first ("defined") part is available for
translation.  The second version ("declared") is not included.


--
           Summary: String not extracted for translation
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: goeran at uddeborg dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #1 from paolo dot carlini at oracle dot com  2009-07-27 11:24 -------
I think this is a pervasive issue and we have at least another couple of PRs
about it in Bugzilla. Please check / commonize, thanks!


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #2 from goeran at uddeborg dot se  2009-07-27 16:00 -------
(In reply to comment #1)
> I think this is a pervasive issue and we have at least another couple of PRs
> about it in Bugzilla. Please check / commonize, thanks!

I'm not sure exactly what you mean with "this".  This particular error message,
calls of error() where the first argument is a conditional expression, or
problems with translating GCC in general.

I tried to look for more similar cases.  But I couldn't find anything.  Not
that it is all that easy to search for.  Neither "error" nor "?" are
particularly good search terms. :-)  So I may very well have missed something.

Previously, I have reported a couple of instances where things can't be
properly translated.  But that has mostly been cases where the code needs a
small rewrite.  I'm not sure how to "commonize" those; they typically have to
be handled case-by-case.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #3 from manu at gcc dot gnu dot org  2009-07-27 16:55 -------
(In reply to comment #2)
> I tried to look for more similar cases.  But I couldn't find anything.  Not
> that it is all that easy to search for.  Neither "error" nor "?" are
> particularly good search terms. :-)  So I may very well have missed something.

Try grep -e ' error ([^"]' gcc/*.c -A 1

I am sure you can come up with smart regexp for warning, warning_at, error_at,
inform and the other diagnostic functions.

> Previously, I have reported a couple of instances where things can't be
> properly translated.  But that has mostly been cases where the code needs a
> small rewrite.  I'm not sure how to "commonize" those; they typically have to
> be handled case-by-case.

In this case, the string just have to be surrounded by G_() so:

                 error (funcdef_flag
                       ? G_("%qs defined in a non-class scope")
                       : G_("%qs declared in a non-class scope"), name);

Care to contribute a patch for this and other cases?

Thanks,

Manuel.


--

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |translation
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-07-27 16:55:08
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #4 from goeran at uddeborg dot se  2009-07-27 17:01 -------
(In reply to comment #3)
> Try grep -e ' error ([^"]' gcc/*.c -A 1

Ah, ok.  I tried to search for similar BUGZILLA reports.  Not for similar cases
in the code.

But sure, I can search the code instead.  BRB


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #5 from manu at gcc dot gnu dot org  2009-07-27 17:08 -------
(In reply to comment #4)
> (In reply to comment #3)
> > Try grep -e ' error ([^"]' gcc/*.c -A 1
>
> Ah, ok.  I tried to search for similar BUGZILLA reports.  Not for similar cases
> in the code.

Sorry, I didn't understand that was what you wanted. If you want to search in
bugzilla, "translated OR translation" is probably what you want.

> But sure, I can search the code instead.  BRB

I don't want you to show me something that anyone can get (up-to-date) whenever
one wants. I provided the information just in case you (or someone) wants to
find (and fix) the code.

Thanks.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #6 from goeran at uddeborg dot se  2009-07-27 17:11 -------
(In reply to comment #5)
> Sorry, I didn't understand that was what you wanted.

What I WANTED was to do what Paolo Carlini asked about in comment 1.  I'm not
sure if I understood him correctly either.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #7 from paolo dot carlini at oracle dot com  2009-07-27 17:53 -------
never mind, you are just lazy, then say it more explicitly.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #8 from paolo dot carlini at oracle dot com  2009-07-27 18:04 -------
Sorry about some harshness on my part, but in my opinion we should really have
a single PR about this issue and PR34836, PR29917, PR29017, and maybe a few
more...


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #9 from manu at gcc dot gnu dot org  2009-07-27 18:06 -------
I am not going to work on this. Unsubscribing.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #10 from goeran at uddeborg dot se  2009-07-27 18:22 -------
(In reply to comment #8)
> ... but in my opinion we should really have
> a single PR about this issue and PR34836, PR29917, PR29017

Then I did misunderstand you.

These are examples of what meant needed to be handled on a case-by-case basis.
If I was to handle this, I would definitely NOT wanted to have them merged.  In
my view one problem per report is much better than bundling a lot of bugs
together.

So I didn't think you meant reports like that.  But this is your project, not
mine, and you manage it any way you want.  If you want a list of bugzillas
about translation issues in general, you could start with all bugs I have
submitted (including the ones you mentioned above):

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailreporter1=1&emailtype1=exact&email1=goeran%40uddeborg.se


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #11 from paolo dot carlini at oracle dot com  2009-07-27 18:27 -------
Yes, in similar cases either we have a single PR or at least we have a "dummy"
Bugzilla PR bundling together related issues as blocking it. You can find many
examples.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #12 from paolo dot carlini at oracle dot com  2009-07-27 18:40 -------
Such "dummy" PRs have the summary starting with [Meta] and all the related
issues it groups are listed in the field "depends on" (sorry I confused
depends/blocks in my previous message).


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #13 from goeran at uddeborg dot se  2009-07-27 19:27 -------
If I can give any useful help, I'm certainly willing to do so.  I'll search for
bugs to add to a meta-bug if you wish.  What would the criteria for inclusion
be?  Just anything having to do with translation?  Anything with code that
needs to be changed for translation, thus excluding translation errors as such?
 Or do you mean a grouping of bugs where the code changes are similar in some
way?

This meta bug would stay open forever, I assume.  New errors of this kind turn
up in approximately the same rate old are fixed.  But that is ok then?


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #14 from paolo dot carlini at oracle dot com  2009-07-27 19:50 -------
First, thanks for your help. I went quickly through your own bugs, and indeed,
I don't think they could reasonably all belong to the same meta-bug. However, I
think a meta-bug is definitely in order grouping together all the bugs (maybe
not just yours) having to do with translation problems due to trivial issues
like use of conditionals, passing around and pasting C strings, etc.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #15 from goeran at uddeborg dot se  2009-07-27 20:43 -------
Bug 40872 created as a tracker bug, with almost all my own bugs, and a few
others that also seemed to qualify as "trivial".  I excluded bugs that referred
to errors in the actual translations (l10n rather than i18n).  (While probably
trivial, they should have been reported to the respective team instead.)


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #16 from paolo dot carlini at oracle dot com  2009-07-27 21:19 -------
Many thanks again!


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #17 from joseph at codesourcery dot com  2009-07-28 11:55 -------
Subject: Re:  String not extracted for translation

On Mon, 27 Jul 2009, manu at gcc dot gnu dot org wrote:

> ------- Comment #3 from manu at gcc dot gnu dot org  2009-07-27 16:55 -------
> (In reply to comment #2)
> > I tried to look for more similar cases.  But I couldn't find anything.  Not
> > that it is all that easy to search for.  Neither "error" nor "?" are
> > particularly good search terms. :-)  So I may very well have missed something.
>
> Try grep -e ' error ([^"]' gcc/*.c -A 1
>
> I am sure you can come up with smart regexp for warning, warning_at, error_at,
> inform and the other diagnostic functions.

My approach for finding such issues has been to search for '"' and look
(manually) in the result for any English strings that are not full
diagnostics as the *msgid operand of a diagnostic function.

> Care to contribute a patch for this and other cases?

I also encourage people wanting such issues fixed to submit patches, and
will review such patches (to any part of the compiler) if the more
specific maintainers of those parts of the compiler do not review them
first.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #18 from pearly dot zhao at oracle dot com  2009-11-12 07:54 -------
Run "make gcc.pot" in objdir/gcc/ can extract both branches of this conditional
expression. That is to say, the ("declared") line is also include at
objdir/gcc/gcc.pot.
Can this bug be closed?


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872

------- Comment #19 from joseph at codesourcery dot com  2009-11-12 17:20 -------
Subject: Re:  String not extracted for translation

On Thu, 12 Nov 2009, pearly dot zhao at oracle dot com wrote:

> Run "make gcc.pot" in objdir/gcc/ can extract both branches of this conditional
> expression. That is to say, the ("declared") line is also include at
> objdir/gcc/gcc.pot.

It didn't do so when I last ran it (gettext 0.17).  Are you using another
version?  Maybe there need to be stricter version requirements on gettext?


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872