[Bug c/114112] Error message is translatable but inserts untranslated substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114112 Göran Uddeborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Göran Uddeborg --- This is fixed in the 14.1.0 version of the message catalog now available for translation. Thank you!
[Bug c/114112] New: Error message is translatable but inserts untranslated substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114112 Bug ID: 114112 Summary: Error message is translatable but inserts untranslated substring Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- At https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/c-family/c-omp.cc;h=5117022e330c95592d7731eec161ab1b5c6925d9;hb=HEAD#l1810 the function check_loop_binding_expr emits an error message where it inserts a "context". This "context" comes from the call and is sent as a string not available for translation. Even if those inserted strings were marked for translation, it is in general a bad idea to compose a message from smaller strings in that way if they are to be correctly translated. (See https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html if one wants a further discussion around this.)
[Bug fortran/107122] New: Improve error message wording
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107122 Bug ID: 107122 Summary: Improve error message wording Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- At https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/fortran/openmp.cc;h=ce719bd5d92dc40185a4d0215d5db13b7956acba;hb=HEAD#l6538 there is a message ORDER clause must not be used together ORDERED at %L In my mind, that would read better by adding "with" after "together".
[Bug tree-optimization/107121] New: DEFERRED_INIT misspelled in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107121 Bug ID: 107121 Summary: DEFERRED_INIT misspelled in error message Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- At the line https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/tree-cfg.cc;h=ade66c54499ff481bb9d58fd5f3c616646514d65;hb=HEAD#l3513 (at the time of writing this message), there is an error mentioning a call of DEFFERED_INIT. Most likely, that should be DEFERRED_INIT.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 96248, which changed state. Bug 96248 Summary: Closing quote in wrong position in config/rs6000/rs6000.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96248 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/96248] Closing quote in wrong position in config/rs6000/rs6000.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96248 Göran Uddeborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Göran Uddeborg --- This has been fixed in 12.1-b20220403.
[Bug target/104818] New: Duplicate word "version" in option -mptx description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104818 Bug ID: 104818 Summary: Duplicate word "version" in option -mptx description Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- In `config/nvptx/nvptx.opt` there is an error message Specify the version of the ptx version to use. https://github.com/gcc-mirror/gcc/blob/2472dcaa8cb9e02e902f83d419c3ee7e0f3d9041/gcc/config/nvptx/nvptx.opt#L80 I guess "version of version" is not what was intended.
[Bug c++/104709] New: A translated error message will include untanslated parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104709 Bug ID: 104709 Summary: A translated error message will include untanslated parts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- In the function open_module_client in gcc/cp/mapper-client.cc there an error message failed %s mapper %qs line %u and a similar without a line. This message is properly marked for translation. The first %s in this message however will be a string which will be untranslated, resulting in a mixed language message. At the very least, the strings assigned (in various places) to "errmsg" need to be marked for translation. Composing a message in this way is however a bad idea in general, and might be hard to translate properly for some locales. If possible it would be better to have more complete messages, not inserting parts of it through a %s substitution. (See https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Decent-English-style for a longer discussion.)
[Bug fortran/99884] New: Double spaces in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884 Bug ID: 99884 Summary: Double spaces in warning message Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- At https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/io.c;h=40cd76eb5858614c81de98b59a4f6e5b814988ea;hb=HEAD#l2494 the variable "spec" is either set to a string followed by a space, or an empty string. This seems like a good way to be able to create a correct error message when there is a valid string to print but avoid an extra space when not. But when actually used in a message a few lines below, this feature is not taken advantage of, and the specifier is followed by a space regardless. That will make two spaces if there is a valid string, and one useless space when "spec" is empty. Unless I miss something the message string should begin "%sspecifier at %L not …"
[Bug other/99883] New: A couple of minor misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99883 Bug ID: 99883 Summary: A couple of minor misspellings Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- There are two misspellings Anders Jonsson found while reviewing my Swedish translation of gcc: "exclussive" rather than "exclusive at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/lto/lto-lang.c;h=8e73a11a7f6fdad1f3b69a44635d9cdf7d5466e5;hb=HEAD#l899 "corrsponding" rather than "corresponding" at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c.opt;h=64e46e7573ef58fac424bc40c7d5981fdca001c1;hb=HEAD#l803
[Bug gcov-profile/96285] The documentation of -fprofile-exclude-files is unclear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96285 --- Comment #2 from Göran Uddeborg --- Sure, I'll put it together shortly.
[Bug c/96285] New: The documentation of -fprofile-exclude-files is unclear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96285 Bug ID: 96285 Summary: The documentation of -fprofile-exclude-files is unclear Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- During the translation of the help text for -fprofile-exclude-files a discussion started what it actually meant. Does the name has to match ALL the regular expressions given, or just ANY of them, for the file to be excluded? The texinfo documentation didn't help, since it just had an example with a single expression. Checking the code I figured out it is excluded if it matches any of them. Even if the current documentation actually say this, it is easy to misunderstand. May I suggest the documentation is clarified on this point? Perhaps simply Instrument only functions from files whose name does not match any of the regular expressions (separated by semi-colons). In addition, the texinfo documentation is probably slightly wrong. It gives as the example "/usr/*". Treated as a regular expression, which indeed seems to be what the code implements, that means "/usr" followed by an arbitrary number of "/". Not what was intended, I believe. Maybe it might still work; from what I can tell the search string isn't anchored so it is ok for it to match only the beginning of the name. But if so the "/*" at the end is pointless, and the example could lead the reader to assume it is a glob expression rather than a regular expression.
[Bug c/96249] New: The string " bytes" is repeated at the end of the message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96249 Bug ID: 96249 Summary: The string " bytes" is repeated at the end of the message Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- In c-family/c.opt, line 1251 at the time of writing, the string " bytes" is repeated at the end of the description of Wvla-larger-than= Wvla-larger-than= C ObjC C++ LTO ObjC++ Var(warn_vla_limit) Warning Joined Host_Wide_Int ByteSize Init(HOST_WIDE_INT_MAX) -Wvla-larger-than= Warn on unbounded uses of variable-length arrays, and on bounded uses of variable-length arrays whose bound can be larger than bytes. bytes.
[Bug driver/96248] New: Closing quote in wrong position in config/rs6000/linux64.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96248
Bug ID: 96248
Summary: Closing quote in wrong position in
config/rs6000/linux64.h
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: goeran at uddeborg dot se
Target Milestone: ---
The closing quote in the message
error ("%<-mcmodel incompatible with other toc options%>");
in config/rs6000/linux64.h has obviously gone astray. It should have been
directly after "mcmodel", I presume.
This was mentioned in a comment of bug 90148, but since that report was
originally about a different issue, I thought I'd better make a separate report
so it won't get lost. In my experience, one problem per report is a good
strategy.
[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693 --- Comment #5 from Göran Uddeborg --- (In reply to markeggleston from comment #4) > Does this mean that this is fixed? I don't think so. The "_" define typically marks the string for translation, but it doesn't add the information this is a format string using "gcc-internal-format" rather than regular printf() style formatting. According to comment 3, that can be achieved by using the define "G_" rather than plain "_" for those strings using "%L" or any other GCC specific formatting directives..
[Bug c/95139] New: Messages using string concatenation can not be translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95139
Bug ID: 95139
Summary: Messages using string concatenation can not be
translated
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goeran at uddeborg dot se
Target Milestone: ---
In pru-pragma.c, in the function pru_pragma_ctable_entry, there are two error
messages created by concatenating string literals, where some of the literals
are preprocessor definitions. This unfortunately fails when the messages are
to be extracted for translation. Only the literals up to the first such
preprocessor symbol will be included in the message catalog, but that will
never be looked up.
else if (i >= ARRAY_SIZE (pru_ctable))
error ("% index %" HOST_WIDE_INT_PRINT "d"
" is not valid", i);
else if (pru_ctable[i].valid && pru_ctable[i].base != base)
error ("redefinition of %", i);
Only "% index %" and "redefinition of %https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/config/pru/pru-pragma.c;h=5d6cc49b71494c0a224491be40247c50a5e2cd63;hb=HEAD#l60
[Bug d/89823] Composed message only partially translatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823 Göran Uddeborg changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Göran Uddeborg --- The message is removed.
[Bug d/89823] New: Composed message only partially translatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823
Bug ID: 89823
Summary: Composed message only partially translatable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: goeran at uddeborg dot se
Target Milestone: ---
In d/dmd/expressionsem.c there is this piece of code:
> const char *s = exp->op == TOKplusplus ? "increment" : "decrement";
> exp->error("cannot post-%s array slice '%s', use pre-%s instead", s,
> exp->e1->toChars(), s);
The string "cannot post-%s …" will be extracted for translation, but the
inserted words, "increment" and "decrement", will not.
At a minimum, these words need to be marked for translation too. Better is
probably to make it two complete messages. For Swedish it would work to
compose the sentence this way, but I suspect there are languages further
removed from English where it would be hard.
[Bug other/80589] Typing mistakes in two messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80589 Göran Uddeborg changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Göran Uddeborg --- This doesn't seem completely fixed. I don't see the second mistake any more. But the first mistake still remains in param.def, while the same string in doc/invoke.texi is fixed.
[Bug tree-optimization/80760] New: Suggested clarification of an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80760 Bug ID: 80760 Summary: Suggested clarification of an error message Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- The message "%<l1-cache-size%> parameter is not a power of two %d" (from https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/tree-ssa-loop-prefetch.c?view=markup#l2038) caused a bit of confusion during our translation into Swedish. We now realise the %d will become the size which is not a power of two. But we still feel the message is a bit strange, with the word "two" directly followed by a number. Could I suggest a clarification. Perhaps "%<l1-cache-size%> parameter is %d which is not a power of two" or at least a colon to separate the size from the message proper "%<l1-cache-size%> parameter is not a power of two: %d"
[Bug other/80589] New: Typing mistakes in two messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80589 Bug ID: 80589 Summary: Typing mistakes in two messages Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- The translation reviewer Anders Jonsson pointed out two message ids with what appears to be misspellings. #: params.def:351 #, no-c-format msgid "The maximum number of insns in loop header duplicated by he copy loop headers pass." This should read "by the copy" pass, we believe. #: common.opt:2495 msgid "Detect paths that trigger erroneous or undefined behavior due a null value being used … This should read "due to a null", we believe.
[Bug target/46676] ix86_option_override_internal i18n problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46676 Göran Uddeborg changed: What|Removed |Added CC||goeran at uddeborg dot se --- Comment #1 from Göran Uddeborg --- It seems this is fixed in 7.1-b20170101. Maybe the bug can be closed?
[Bug target/34352] Multi-line descriptions are not picked up for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34352 Göran Uddeborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Göran Uddeborg --- In 7.1-b20170101 the entire message apparently is picked up, even if spanning several lines.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 34352, which changed state. Bug 34352 Summary: Multi-line descriptions are not picked up for translation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34352 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 47103, which changed state. Bug 47103 Summary: i386 options have multi-line descriptions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47103 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/47103] i386 options have multi-line descriptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47103 Göran Uddeborg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Göran Uddeborg --- This appears to have been fixed in 7.1-b20170101.
[Bug translation/60149] Message with percent character incorrectly marked c-format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60149 Göran Uddeborg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Göran Uddeborg --- In the current po file, 6.1-b20160131, this message is correctly marked no-c-format.
[Bug c/60149] New: Message with percent character incorrectly marked c-format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60149 Bug ID: 60149 Summary: Message with percent character incorrectly marked c-format Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se In the po files for gcc 4.9 distributed through the Translation Project recently there is a message like this: #: params.def:417 #, c-format msgid Set the estimated probability in percentage for builtin expect. The default value is 90% probability. The c-format annotation makes the gettext tools believe that % p is a conversion of a pointer with space as a flag. This of course breaks in translation. The correct thing would be to avoid the c-format directive, but I'm not sure how easy that is.
[Bug target/34352] Multi-line descriptions are not picked up for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34352 --- Comment #4 from Göran Uddeborg goeran at uddeborg dot se --- Created attachment 30531 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30531action=edit Merge all multi-line descriptions in .opt files That I'll do, I thought. And promptly forgot about, apparently! :-( Anyway, better late than never! I've finally made this patch, and sent it as instructed. For completeness, I'm also attaching the patch here.
[Bug target/52726] New: Composed error message will not get translated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52726 Bug #: 52726 Summary: Composed error message will not get translated Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: goe...@uddeborg.se In config/tilepro/tilepro.c there is this code output_operand_lossage (invalid %%t operand ' HOST_WIDE_INT_PRINT_DEC ', n); Normally, the first argument of output_operand_lossage is extracted for translation. When using string concatenation in this way it fails however, and only the first part, invalid %%t operand ', will get extracted. At run time however, the concatenated string would be used, which will not be available in the translation catalog. A trivial workaround would be to compose the format string at run time: sprintf (buf, gettext(invalid t operand '%s'), HOST_WIDE_INT_PRINT_DEC); output_operand_lossage (buf, n);
[Bug c/52118] New: The explanation of Wunused-local-typedefs is truncated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52118 Bug #: 52118 Summary: The explanation of Wunused-local-typedefs is truncated Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: goe...@uddeborg.se In gcc/c-family/c.opt there is this code. Wunused-local-typedefs C ObjC C++ ObjC++ Var(warn_unused_local_typedefs) Warning Warn about I would assume the intention was to explain the flag in SOME more detail. :-)
[Bug target/47103] New: i386 options have multi-line descriptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47103 Summary: i386 options have multi-line descriptions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: goe...@uddeborg.se In gcc/config/i386/i386.opt there are multi-line descriptions of the options mvzeroupper and mdispatch-scheduler. Only the first line is picked up fro translation, and according to bug 34352, comment 1, it is a bug for those files to have multi-line descriptions.
[Bug target/47105] New: Some xml-options have only placeholders as descriptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47105 Summary: Some xml-options have only placeholders as descriptions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: goe...@uddeborg.se The four options mxl-mode-executable mxl-mode-xmdstub mxl-mode-bootstrap mxl-mode-novectors have descriptions of the form Descripton for the option in gcc/config/microblaze/microblaze.opt. Obviously a placeholder to be filled in later. Maybe it is on someones to-do-list. But normally such things are fixed by the time we translators get involved, so I fear it might have been forgotten. Thus this bug report.
[Bug middle-end/47081] New: Macro usage too clever for localization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081
Summary: Macro usage too clever for localization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: goe...@uddeborg.se
In gcc/gentype-state.c there is a macro like this:
#define fatal_reading_state_printf(Tok,Fmt,...) do {\
...
fatal (%s:%d:%d: Invalid state file; Fmt,\
Normally, the first argument to fatal() is extracted for localization. But
that extraction apparently fails here. Each usage of the macro will create a
unique format string to fatal(). But the extractor for localization only
extracts the invariant part that is in the macro, %s:%d:%d: Invalid state
file; . That will never be the string looked up for translation at run time.
And the strings actually looked up are not available in the pot file.
Seen in the po file distributed for 4.6-b20101218.
[Bug middle-end/47081] Macro usage too clever for localization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081 --- Comment #2 from Göran Uddeborg goeran at uddeborg dot se 2010-12-28 19:23:57 UTC --- Oh, I see. You mean this message is never seen by an end user? In that case, maybe they could be excluded from the set of files scanned for messages to translate? Or would that be complex?
[Bug c++/46901] Error message repeats itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901 Göran Uddeborg goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Göran Uddeborg goeran at uddeborg dot se 2010-12-19 20:59:17 UTC --- Looks good in 4.6-b20101218.
[Bug c++/46901] New: Error message repeats itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901 Summary: Error message repeats itself Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: goe...@uddeborg.se In convert_for_assignment in gcc/cp/typcheck.c there is a message target of conversion might be might be a candidate for a format attribute There is one might be too many in there.
[Bug driver/46617] New: String concatenation fools extraction for translation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46617 Summary: String concatenation fools extraction for translation. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: goe...@uddeborg.se In gcc-4.6-20101113 in gcc/gcc.c in main() there is this code: fatal_error (-fuse-linker-plugin, but LTOPLUGINSONAME not found); When extracting strings for translation, the extractor doesn't see this as one long string, and does not know what to replace LTOPLUGINSONAME with. The result is that what winds up in the pot file is #: gcc.c:6830 #, gcc-internal-format msgid -fuse-linker-plugin, but Obviously incorrect. As a simple fix, may I suggest to rewrite it using a percent substitution: fatal_error (-fuse-linker-plugin, but %s not found, LTOPLUGINSONAME);
[Bug translation/43779] New: Parts of message not available for translation
In gcc/cp/typecheck.c there is this construction: error_at (input_location, too many arguments to %s %q#D, called_thing, fndecl); and an analogous message for too few arguments. Called_thing is a string like function or constructor. But this string is not available for translation. so if this message is translated, the result will be a mix of the target language and English. Marking called_thing for translation separately is a bit tricky from a translation point of view. It often breaks to build sentences from words in source in this way. The rest of the sentence might have different forms dependent on what called_thing is. That would not be a problem for Swedish in this particular case, but I would still recommend creating a couple of complete messages for translation instead of building them from parts. -- Summary: Parts of message not available for translation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43779
[Bug c++/43120] Diamond virtual inheritence with covariant return type confuses GCC
--- Comment #4 from goeran at uddeborg dot se 2010-02-24 11:02 --- Created an attachment (id=19944) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19944action=view) A different simplification, avoiding the diamond inheritance The diamond inheritance does not seem to be a requirement. Here is a case simplified in a different way, where there is no diamond inheritance any more. (This one does print 33 rather than a huge number. Still wrong, obviously.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43120
[Bug c++/43120] New: Diamond virtual inheritence with covariant return type confuses GCC
Diamond shaped class structure with a covariant return method causes GCC to fail to adjust base pointers. In the attached program, the output is a huge number instead of the expected 123. Looking at what happens in GDB, it appears that the this pointer in the call of A(const A other) gets a B reference rather than an A reference. The place where it expects to find the member A::a is actually outside of the object of type F. If I'm reading the output from GDB correctly. -- Summary: Diamond virtual inheritence with covariant return type confuses GCC Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal 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=43120
[Bug c++/43120] Diamond virtual inheritence with covariant return type confuses GCC
--- Comment #1 from goeran at uddeborg dot se 2010-02-19 14:24 --- Created an attachment (id=19921) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19921action=view) Test case No special flags, just compile with c++ thunk.cc -o thunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43120
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #18 from goeran at uddeborg dot se 2010-01-11 17:27 --- I did try it out as you suggested, and it seems to work just fine. (I.e. messages from fortran/arith.c were said to come from fortraarith.c in the pot file. But I didn't bother to investigate that, it wasn't what I was there to check.) I thought we had to wait for gettext 0.18 for this, but apparently not. One detail I happened to see: The messages defined in gfc_arith_error doesn't get any gcc-internal-format marker, though they do contain %L. Do you want a separate bugzilla about that? -- goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug fortran/42693] New: Missing gcc-internal-format on messages from gfc_arith_error
The strings returned from gfc_arith_error in gcc/fortran/arith.h contain the location marker %L. But as noticed in bug 36161, they are not marked gcc-internal-format. This marking is valuable to avoid mistakes in the translation. -- Summary: Missing gcc-internal-format on messages from gfc_arith_error Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #20 from goeran at uddeborg dot se 2010-01-11 21:02 --- (In reply to comment #19) Yes please. I've filed bug 42693 about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug middle-end/22201] Parameter description strings should all start with a capital letter
--- Comment #4 from goeran at uddeborg dot se 2009-12-06 12:43 --- Looks good in po file for 4.5-b20091203 -- goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22201
[Bug c++/29917] %s substituted with actual words can not be translated correctly (op_error)
--- Comment #4 from goeran at uddeborg dot se 2009-12-06 12:44 --- Looks good in po file for 4.5-b20091203 -- goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29917
[Bug objc/29200] %s substituted with methods/selectors can't be properly translated
--- Comment #5 from goeran at uddeborg dot se 2009-12-06 12:47 --- Looks good in po file for 4.5-b20091203 -- goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29200
[Bug c++/34836] Parts of sentences substituted for %s can not be translated
--- Comment #3 from goeran at uddeborg dot se 2009-12-06 12:52 --- Looks good in po file for 4.5-b20091203 -- goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34836
[Bug c++/38761] %s substituted with regular word can't be properly translated
--- Comment #5 from goeran at uddeborg dot se 2009-11-12 21:14 --- I took a look at the code in the web svn. The messages as such look fine now. They should be readily translatable. But I don't think xgettext will pick up both strings for translation, when the argument is a conditional expression like that. At least not in a simple test case I made. Only the first string was extracted. But maybe you run xgettext in some more advanced way in the gcc framework? Otherwise, some markers for gettext are probably also necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761
[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
[Bug translation/32637] Swedish translation error
--- Comment #3 from goeran at uddeborg dot se 2009-07-27 15:41 --- (In reply to comment #2) Translation fixes goto the translation team which is not part of the GCC team really. Indeed. In this case that would be tp...@listor.tp-sv.se. But fortunately, I happened to stumble on this bug report today, and I will fix it in the next translation. -- goeran at uddeborg dot se changed: What|Removed |Added CC||goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32637
[Bug c++/40872] String not extracted for translation
--- 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
[Bug translation/40872] String not extracted for translation
--- 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
[Bug translation/40872] String not extracted for translation
--- 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
[Bug translation/40872] String not extracted for translation
--- 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=advancedbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDemailreporter1=1emailtype1=exactemail1=goeran%40uddeborg.se -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug translation/40872] String not extracted for translation
--- 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
[Bug translation/40883] New: [meta-bug] Translation breakage with trivial fixes
Meta bug to collect cases where proper translation isn't possible, but where it would be, with fairly trivial modifications of the source code. This was requested in the discussion of bug 40872. -- Summary: [meta-bug] Translation breakage with trivial fixes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug translation/40872] String not extracted for translation
--- 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
[Bug fortran/40849] New: String extraction for translation fails when concatenating with preprocessor symbols
On lin 5257 of gcc/fortran/module.c there is this code: gfc_fatal_error (Wrong module version '%s' (expected ' MOD_VERSION ') for file '%s' opened at %C, atom_string, filename); Format strings for gfc_fatal_error are typically extracted for translation. But since we have string concatenation where one string is a preprocessor symbol here, it obviously fails, and only the initial part is included in the po file: #: fortran/module.c:5257 #, no-c-format, fuzzy msgid Wrong module version '%s' (expected ' A possible way to avoid this could be to use %s in the format string, and then have MOD_VERSION as an additional argument to the function. Maybe there are better ways. -- Summary: String extraction for translation fails when concatenating with preprocessor symbols Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40849
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #6 from goeran at uddeborg dot se 2009-03-29 16:53 --- It didn't take long for this to be added to xgettext. It's already in the development version (see https://savannah.gnu.org/bugs/?26040#comment1 for details). So then maybe I can reopen this, to have the new functionality used on the GCC side? -- goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #5 from goeran at uddeborg dot se 2009-03-28 18:27 --- I see. I've sent an enhancement suggestion to the gettext project. https://savannah.gnu.org/bugs/index.php?26040 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug c++/38761] New: %s substituted with regular word can't be properly translated
In gcc/cp/parser.c there is this code in cp_parser_parameter_declaration error (%H%sparameter pack %qD cannot have a default argument, declarator_token_start-location, kind, id_declarator-u.id.unqualified_name); else error (%H%sparameter pack cannot have a default argument, declarator_token_start-location, kind); where kind has previously been assigned either the empty string or the word template followed by a space. There is no way to translate the word template. For this to work in all languages, I suspect the two messages needs to be split up in four complete messages, with and without template, rather than composed from pieces like this. -- Summary: %s substituted with regular word can't be properly translated Product: gcc Version: 4.4.0 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=38761
[Bug c++/38761] %s substituted with regular word can't be properly translated
--- Comment #2 from goeran at uddeborg dot se 2009-01-07 21:52 --- (In reply to comment #1) Well template here might be consider the keyword template. It COULD, but I would argue that would break the style of other messages. The word template is used in many messages, sometimes in different forms like templates and templetized. The use in this particular message isn't stylistically different from any other message. Maybe more importantly, it wouldn't really help. If I were to translate this message in a way that treated template as an untranslatable keyword, I would rewrite it to something analogous to parameter pack %qD of %s ... But that only works as long as kind becomes SOME keyword. If it is empty, I do of course not want any of. (I would have to add $-directives to change the order too, but I omitted that here for simplicity.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761
[Bug fortran/38573] Missing markers for translation
--- Comment #2 from goeran at uddeborg dot se 2008-12-20 11:26 --- That's true. Simply including the is in the symstd_msg, so the entire message within the parenthesis would be translated as a unit, would be a significant improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
[Bug fortran/38573] New: Missing markers for translation
In the function gfc_check_intrinsic_standard in gcc/fortran/intrinsic.c there is a message written: gfc_warning (Intrinsic '%s' (is %s) is used at %L, isym-name, _(symstd_msg), where); The string pointed to by sysstd_msg is sent for translation. But the values this string can get are not marked for translation. It looks like this: symstd_msg = available since Fortran 77; Nothing tells xgettext to extract this to the po files so it can be translated. This needs to be changed to symstd_msg = N_(available since Fortran 77); Similarily for the other possible values of symstd_msg. -- Summary: Missing markers for translation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
[Bug target/38442] New: Multi-line description used in config/picochip/picochip.opt
According to bug 34352 comment 1, it is incorrect for descriptions in .opt files to span multiple lines. In version 4.4-20081121 there is such a case in config/picochip/picochip.opt: msymbol-as-address Target Mask(SYMBOL_AS_ADDRESS) Allow a symbol value to be used as an immediate value in an instruction. -- Summary: Multi-line description used in config/picochip/picochip.opt Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38442
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #2 from goeran at uddeborg dot se 2008-05-19 20:15 --- I'm not saying they should be marked c-format, but gcc-internal-format. That special marker is known by msgfmt for the printf inspired error messages in GCC. Tobias Burnus has pointed out in a mail, however, that %C and %L are gfortran specific, and might not be supported by msgfmt's gcc-internal-format. I am planning to investigate this, but I will not have time to do it until later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug fortran/36161] New: gfc_error formats are not marked gcc-internal-format in po file
The first argument of gfc_error seems to be a format string of the form tagged with gcc-internal-format elsewhere in the po file. But it seems gfc_error formats are instead tagged with no-c-format. This is somewhat dangerous, since msgfmt will not discover mistakes in the translation, mistakes that potentially could cause a crash. (Yes, it happened. I had done a few such mistakes in sv.po, which was just pointed out to me in a friendly letter.) -- Summary: gfc_error formats are not marked gcc-internal-format in po file Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug c/35002] New: Incorrect spelling of hottest
In gcc/params.def there is a message The threshold ratio between current and hotest structure counts Unless I'm mistaken, the correct spelling is hottest. -- Summary: Incorrect spelling of hottest Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: trivial 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=35002
[Bug c++/34836] New: Parts of sentences substituted for %s can not be translated
The messages in function readonly_error in gcc/cp/typeck2.c are not possible to translate properly. A part of the sentence, which might be assignment or increment for example is passed to the function as an argument. This argument is then composed with the error message using a %s substitution. But the incoming argument is not marked for translation. Composing sentences like this also makes translation hard, probably impossible, in some languages. Furthermore, some of the messages are assigned to a variable and then this variable is passed to the function error(). The strings in the assignments needs to be marked with the N_ macro so they are picked up by xgettext for translation. -- Summary: Parts of sentences substituted for %s can not be translated Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal 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=34836
[Bug other/34352] New: Multi-line descriptions are not picked up for translation
It appears that multi-line descriptions in *.opt files are not picked up correctly. As an example, in config/bfin/bfin.opt there are these lines: mleaf-id-shared-library Target Report Mask(LEAF_ID_SHARED_LIBRARY) Generate code that won't be linked against any other ID shared libraries, but may be used as a shared library. po/gcc.pot however, contains this: #: config/bfin/bfin.opt:52 msgid Generate code that won't be linked against any other ID shared libraries, msgstr That is, the second line of the description is missing. (Or alternatively, it is a bug in bfin.opt that more than one is used for the description. I haven't investigated what the defined format for these files are.) -- Summary: Multi-line descriptions are not picked up for translation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34352
[Bug java/32250] %s substituted with interface/array can't be properly translated
--- Comment #2 from goeran at uddeborg dot se 2007-06-08 19:25 --- Ok. I've found a few more in parse.y, but I won't bother to report them then. So far nothing outside this time around, but I have a few hundred messages to go ... :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32250
[Bug java/32249] New: %s substituted with interface/class can't be properly translated
In gcc/java/parse.y there is this code: parse_error_context (cl, Public %s %qs must be defined in a file called %%s.java%, (is_interface ? interface : class), IDENTIFIER_POINTER (qualified_name), IDENTIFIER_POINTER (raw_name)); The strings substituted for the first %s are not available for translation. But as it is written, they are the English words, not the syntactical tokens. So this can not be properly translated. Even if the words were markes for translation in isolation, composing a sentence like this is not in general possible to do for an arbitrary language. It needs to be split into two separate messages -- Summary: %s substituted with interface/class can't be properly translated Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32249
[Bug java/32250] New: %s substituted with interface/array can't be properly translated
In gcc/java/parse.y there is this code: parse_error_context (wfl, Class %qs can't subclass %s %qs, IDENTIFIER_POINTER (DECL_NAME (this_decl)), (CLASS_INTERFACE (TYPE_NAME (super_type)) ? interface : array), IDENTIFIER_POINTER (DECL_NAME (super_decl))); The strings substituted for the %s are not available for translation. So this can not be properly translated. Even if the words were markes for translation in isolation, composing a sentence like this is not in general possible to do for an arbitrary language. It needs to be split into two separate messages. -- Summary: %s substituted with interface/array can't be properly translated Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32250
[Bug c++/31665] New: %s substituted with built-in/library can't be properly translated
In cp/decl.c there is this code warning (OPT_Wshadow, shadowing %s function %q#D, DECL_BUILT_IN (olddecl) ? built-in : library, olddecl); The strings substituted for the first %s are not available for translation, so this can not be properly translated. Even if they were, composing a sentence like this is not in general possible to do for an arbitrary language. -- Summary: %s substituted with built-in/library can't be properly translated Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal 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=31665
[Bug c/29897] New: %s substituted withparts of sentence can not be translated correctly
In gcc/config/sh/symbian.c there is this code: warning (0, %s %q+D %s after being referenced with dllimport linkage, TREE_CODE (decl) == VAR_DECL ? variable : function, decl, (DECL_INITIAL (decl) || !DECL_EXTERNAL (decl)) ? defined locally : redeclared without dllimport attribute); The strings substituted for the two %s:es are not available for translation, so this can not be properly translated. And composed sentences like this is not in general possible to translate. I realise it has to be split up in four different messages, but that seems to be the only way to get proper translations. -- Summary: %s substituted withparts of sentence can not be translated correctly Product: gcc Version: 4.1.0 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=29897
[Bug objc/29200] New: %s substituted with methods/selectors can't be properly translated
In gcc/objc/objc-act.c there is this code: warning (0, multiple %s named %%c%s% found, methods ? methods : selectors, The strings substituted for the first %s are not available for translation, so this can not be properly translated. Even if they were, composing a sentence like this is not in general possible to do for an arbitrary language. -- Summary: %s substituted with methods/selectors can't be properly translated Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29200
[Bug c++/29089] New: Words substituted for %s in a sentence can not be translated
In gcc/cp/typeck.c there are these messages: pedwarn (ISO C++ forbids %sing an enum, (code == PREINCREMENT_EXPR || code == POSTINCREMENT_EXPR) ? increment : decrement); error (cannot %s a pointer to incomplete type %qT, ((code == PREINCREMENT_EXPR || code == POSTINCREMENT_EXPR) ? increment : decrement), TREE_TYPE (argtype)); pedwarn (ISO C++ forbids %sing a pointer of type %qT, ((code == PREINCREMENT_EXPR || code == POSTINCREMENT_EXPR) ? increment : decrement), argtype); Here increment and decrement will not be translated. Composing sentences like this also makes translation hard, probably impossible in some languages. Please make two complete separate messages for each case. -- Summary: Words substituted for %s in a sentence can not be translated Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal 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=29089
[Bug c/29033] New: %s substituted with left/right can't be properly translated
In gcc/cp/typeck.c there is this code. if (tree_int_cst_lt (op1, integer_zero_node)) warning (0, %s rotate count is negative, (code == LROTATE_EXPR) ? left : right); else if (compare_tree_int (op1, TYPE_PRECISION (type0)) = 0) warning (0, %s rotate count = width of type, (code == LROTATE_EXPR) ? left : right); Here left and right will not be translated. So it is not possible to do a correct translation of these messages. -- Summary: %s substituted with left/right can't be properly translated Product: gcc Version: 4.1.0 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=29033
[Bug c++/29017] New: %s substituted with different untranslated words can't be properly translated
In gcc/cp/typeck.c there is this code pedwarn (ISO C++ forbids %s between pointer of type %void *% and pointer-to-function, location); Location will be different, English and untranslated, values depending on how this code is reached. The result can not be properly translated. Even if location was translated, it surely would not work in all languages to compose a sentence like this. Please make separate and complete error messages for each case. -- Summary: %s substituted with different untranslated words can't be properly translated Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal 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=29017
[Bug c++/28704] New: %s substituted with static member/free can't be properly translated
In cp/decl.c there is this code. error (qualified function types cannot be used to declare %s functions, (staticp? static member : free)); The strings static member and free are not available for translation in the po-file. Even if they were, it surely will not work in all languages to compose a sentence like this. Please make it two separate strings with the complete sentences instead. -- Summary: %s substituted with static member/free can't be properly translated Product: gcc Version: 4.1.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=28704
[Bug c++/28669] New: %s substituted with static/non- can't be properly translated
In cp/decl.c there is this code. error (%smember function %qD cannot have cv-qualifier, (ctype ? static : non-), decl); The first string, %smember ... is available for translation in the po-file, but not the parts substituted, static and non-. And even if they were, it surely will not work in all languages to compose a sentence like this. Two complete strings should be there instead. -- Summary: %s substituted with static/non- can't be properly translated Product: gcc Version: 4.1.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=28669
[Bug c/23501] New: pp_base_format_text ought to recognise m$ directives
When translating the message %s ignored with %s and c% %s format I wanted to switch order of the arguments to get a natural message in Swedish. So I tried with %1$s ignorerad med %2$s och %4$s-format 3$c% That fails, however, with a message c.c:5: internal compiler error: in pp_base_format_text, at pretty-print.c:374 And looking at the code, it does indeed not seem to recognise the m$ construct. But I think it would be reasonable for it to do so. It will be hard to translate all messages passed through that function to all languages without changing the order of the arguments in any of them. -- Summary: pp_base_format_text ought to recognise m$ directives Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23501
[Bug c/23501] pp_base_format_text ought to recognise m$ directives
--- Additional Comments From goeran at uddeborg dot se 2005-08-20 20:52 --- Great! (That answer was quick! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23501
[Bug java/23184] New: I18n bug in gjavah.c
gcc/java/gjavah.c contains the statements fprintf (stderr, _(Try ' TOOLNAME --help' for more information.\n)); The tool extracting strings for translation is fooled by this (not surprisingly). The current po files contains the strings Try ', --help' for more information.\n, for translation. But at run-time, gettext (a.k.a. _) will of course be called with the merged string. There is one more example in the file where string concatenation with TOOLNAME breaks i18n in the same way. printf (_(Usage: TOOLNAME [OPTION]... CLASS...\n\n)); -- Summary: I18n bug in gjavah.c Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23184
[Bug middle-end/22201] New: Parameter description strings should all start with a capital letter
In the po files for version 4.0.1-b20050607 there are two strings from params.def: how much can given compilation unit grow because of the inlining (in percent) and expense of call operation relative to ordinary aritmetic operations All other description strings in this context begin with a capital letter. These two probably should too. -- Summary: Parameter description strings should all start with a capital letter Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22201
[Bug middle-end/22202] New: Superfluous space in description of max-variable-expansions-in-unroller
The description of the parameter max-variable-expansions-in-unroller in param.def contains a lot of white space between of and times and between expanded and during. It should just be a single space there I suppose. -- Summary: Superfluous space in description of max-variable- expansions-in-unroller Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22202
