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.
I think this is a pervasive issue and we have at least another couple of PRs about it in Bugzilla. Please check / commonize, thanks!
(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.
(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.
(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
(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.
(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.
never mind, you are just lazy, then say it more explicitly.
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...
I am not going to work on this. Unsubscribing.
(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
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.
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).
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?
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.
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.)
Many thanks again!
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.
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?
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?
(In reply to comment #19) > Subject: Re: String not extracted for translation > > 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? > You are right. When I ran with gettext 0.17, only the first string of conditional string can be pick up for translation. But I have run with gettext 0.14.6 before. It can extracted both the conditional expression strings for translation. So do the codes need match with the latest gettext and improve the version warning to xgettext at exgettext?
Subject: Re: String not extracted for translation On Fri, 13 Nov 2009, pearly dot zhao at oracle dot com wrote: > (In reply to comment #19) > > Subject: Re: String not extracted for translation > > > > 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? > > > You are right. When I ran with gettext 0.17, only the first string of > conditional string can be pick up for translation. But I have run with gettext > 0.14.6 before. It can extracted both the conditional expression strings for > translation. > So do the codes need match with the latest gettext and improve the version > warning to xgettext at exgettext? One possibility would certainly be to improve the current development version of gettext, get a new release out, and then require the new version (or later) in exgettext and install.texi. That supposes this was not a deliberate change in gettext but a bug that can be safely fixed there.
Mine.
Author: paolo Date: Wed Oct 19 12:46:42 2011 New Revision: 180185 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180185 Log: 2011-10-19 Paolo Carlini <paolo.carlini@oracle.com> PR c++/38761 PR c++/40872 * decl.c (duplicate_decls, make_typename_type, grokdeclarator): Use G_() in error message strings to facilitate translation. * semantics.c (finish_id_expression): Likewise. * parser.c (cp_parser_nested_name_specifier_opt, cp_parser_parameter_declaration): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c
Fixed.