[Bug translation/65959] New: plain text incorrectly marked as format-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65959 Bug ID: 65959 Summary: plain text incorrectly marked as format-c Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From gcc/po/gcc.pot: #: params.def:417 #, c-format msgid Set the estimated probability in percentage for builtin expect. The default value is 90% probability. msgstr Wahrscheinlichkeit in Prozent für das eingebaute »expect«. Vorgabewert ist 90 % Wahrscheinlichkeit. This is not a %p format specifier.
[Bug translation/65959] plain text incorrectly marked as format-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65959 --- Comment #1 from Roland Illig roland.illig at gmx dot de --- I only noticed this because GNU gettext complains that I must not translate %p to %W. Error: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the directive number 1, the character 'W' is not a valid conversion specifier.
[Bug translation/79332] New: Several bugs related to translation in gcc 7.1-b20170101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332 Bug ID: 79332 Summary: Several bugs related to translation in gcc 7.1-b20170101 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The following are all small issues, therefore I think it is easier to address them all at once. 1. Make sure that multiline string literals always end in a space. (PARAM_MAX_STORES_TO_MERGE, PARAM_MAX_SSA_NAME_QUERY_DEPTH) 2. Remove strictly redundant comments from params.def, i.e. those comments that exactly repeat the text in the string literal. (PARAM_MAX_STORES_TO_SINK) 2a. Remove nearly strictly redundant comments from params.def. (PARAM_MAX_SLSR_CANDIDATE_SCAN) 3. Remove all instances of dot dot quote (..") from params.def. 4. Explain what "asan" in "asan-globals" means. Should I translate it in capital letters? 5. To be useful, the explanation in invoke.texi must not merely repeat the parameter description from params.def. (PARAM_MAX_FSM_THREAD_LENGTH) By the way, thank you for providing invoke.texi, which provides good explanations to the very short descriptions in params.def. To make this even more useful, the explanations from invoke.texi should be included in the gcc.pot in order to provide the translators with more context. As it is now, I have to lookup each of the parameters from params.def in invoke.texi to see what it actually means. This definition should be provided as a translator comment.
[Bug translation/79332] Several bugs related to translation in gcc 7.1-b20170101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332 --- Comment #1 from Roland Illig --- How am I supposed to translate "tid.y;" in config/nvptx/nbptx.c? I suppose it is a bug in the program that extracts translatable strings from the source code. In case it is not, there must be a translator comment nearby.
[Bug translation/79397] New: AltiVec spelled incorrectly in rs6000.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79397 Bug ID: 79397 Summary: AltiVec spelled incorrectly in rs6000.opt Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In config/rs6000/rs6000.opt, the word AltiVec is sometimes spelled "Altivec" and sometimes "AltiVec". The latter form should be used consistently.
[Bug translation/79332] Several bugs related to translation in gcc 7.1-b20170101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332 --- Comment #2 from Roland Illig --- In config/ft32/ft32.opt, the explanation for mnodiv is missing the period at the end.
[Bug c/79613] missing space in diagnostic: GLOBAL CONST-PROP: Replacing reg %d in jump_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79613 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r245409.
[Bug ipa/79616] missing space in diagnostic: Inlined into %s which now has time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79616 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r245409.
[Bug c++/79608] missing space in error message "bepositive"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79608 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r244245.
[Bug fortran/79617] missing space in diagnostic: IF clause without modifier at %L used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79617 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r244245.
[Bug driver/79637] New: missing documentation for PARAM_MAX_FSM_THREAD_LENGTH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79637 Bug ID: 79637 Summary: missing documentation for PARAM_MAX_FSM_THREAD_LENGTH Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- As a translator, I don't understand the technical babble in params.def for PARAM_MAX_FSM_THREAD_LENGTH. Therefore I look it up in invoke.texi, which is supposed to provide useful, understandable documentation. In this case, invoke.texi verbatimly repeats the one-line description from params.def, which is in no way helpful. There should be at least one paragraph explaining what a jump thread path is. As a general rule, the documentation in invoke.texi should not merely repeat what is already written in params.def.
[Bug c/79615] missing space in diagnostic: Substring out of bounds: lower bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79615 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r245409.
[Bug fortran/79603] make diagnostics more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79603 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r244245.
[Bug c/79635] New: Explain to translators what "asan" means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79635 Bug ID: 79635 Summary: Explain to translators what "asan" means Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- As a translator, I have no idea what "asan" in params.def means. It should be defined somewhere where it can easily be found by translators. If "asan" is an abbreviation, why is it not spelled in uppercase letters?
[Bug c/79632] New: params.def should not contain redundant comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79632 Bug ID: 79632 Summary: params.def should not contain redundant comments Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In params.def, PARAM_MAX_STORES_TO_SINK looks like this: /* Maximum number of conditional store pairs that can be sunk. */ DEFPARAM (PARAM_MAX_STORES_TO_SINK, "max-stores-to-sink", "Maximum number of conditional store pairs that can be sunk.", 2, 0, 0) The comment is an exact copy of the string literal. Therefore it is redundant and be removed. When fixing this, please check for similar occurrences in the same file.
[Bug translation/79332] Several bugs related to translation in gcc 7.1-b20170101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #6 from Roland Illig --- I'm splitting this PR into several ones, to let them be handled correctly. Item 1 has been fixed in r244195. Items 2 and 2a have been moved to #79632. Item 4 has been moved to #79635. Item 5 has been moved to #79637. The bad msgid from comment#1 has been moved to #79638.
[Bug translation/79638] New: Wrongly extracted source string "tid.y;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79638
Bug ID: 79638
Summary: Wrongly extracted source string "tid.y;"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
(This PR is extracted from #79332.)
Currently, the gcc.pot file contains this:
#: config/nvptx/nvptx.c:1132
msgid "tid.y;"
msgstr ""
This is nothing that should be translated.
The corresponding source code looks like this:
> #define ENTRY_TEMPLATE(PS, PS_BYTES, MAD_PS_32) "\
> (.param.u" PS " %arg, .param.u" PS " %stack, .param.u" PS " %sz)\n\
> {\n\
> .reg.u32 %r<3>;\n\
> .reg.u" PS " %R<4>;\n\
> mov.u32 %r0, %tid.y;\n\
> mov.u32 %r1, %ntid.y;\n\
> mov.u32 %r2, %ctaid.x;\n\
(the multi-line string literal continues for a few more lines).
See #79332 for more comments on this topic.
[Bug c++/79595] New: Inconsistent grammar in diagnostic "partial specialization %q+D does not specialize"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79595
Bug ID: 79595
Summary: Inconsistent grammar in diagnostic "partial
specialization %q+D does not specialize"
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Code from cp/pt.c:
if (!flag_concepts)
error ("partial specialization %q+D does not specialize "
"any template arguments", decl);
else
error ("partial specialization %q+D does not specialize any "
"template arguments and is not more constrained than", decl);
inform (DECL_SOURCE_LOCATION (maintmpl), "primary template here");
The first sentence is:
location1: partial specialization %q+D does not specialize any template
arguments
location2: primary template here
The second sentence is:
location1: partial specialization %q+D does not specialize any template
arguments and is not more constrained than
location2: primary template here
In German, it is not possible to translate both sentences to actually
understandable grammar at the same time. Even in English, the second of these
is a complete sentence (split into two parts, which is often problematic for
translators), while the first is a concatenation of two sentence fragments.
Therefore the call to inform should use different text for the two cases.
[Bug fortran/79597] New: Incomplete error message "Expecting %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79597 Bug ID: 79597 Summary: Incomplete error message "Expecting % " "at %C, ", s1); There is a trailing comma. In the corresponding "else" clause, there is a complete sentence. One of these is probably wrong.
[Bug fortran/79596] New: translation: argument to gfc_internal_error should not be translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79596 Bug ID: 79596 Summary: translation: argument to gfc_internal_error should not be translated Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Internal errors should not be translated. Their only purpose is to give information back to the developers, and this information should not be modified by any translator. It is not even necessary that the end user sees a cleartext description of the error, much less translated into any language. This would mean that the developers would have to translate back the internal error description from any of the 50+? languages to see what the exact error was. Not translating these internal errors creates less burden on the translators and helps the GCC developers to more quickly get down to the actual fixing of the bugs.
[Bug fortran/79603] New: make diagnostics more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79603 Bug ID: 79603 Summary: make diagnostics more i18n-friendly Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from fortran/options.c: Flag %<-fno-automatic%> overwrites %<-fmax-stack-var-size=%d%> Flag %<-fno-automatic%> overwrites %<-frecursive%> Flag %<-fno-automatic%> overwrites %<-frecursive%> implied by %<-fopenmp%> Flag %<-frecursive%> overwrites %<-fmax-stack-var-size=%d%> These diagnostics are boring for translators, since they all follow the very same structure, most probably in all languages of the world. Therefore, these messages should use the placeholder %qs so that the translators only have to translate it once. Flag %qs overwrites %qs This also removes the possibility of introducing wrong warnings by unintentionally sloppy translation.
[Bug fortran/79599] New: typo in diagnostic gfc_error ("DTIO dummy argument at %L be a scalar"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79599
Bug ID: 79599
Summary: typo in diagnostic gfc_error ("DTIO dummy argument at
%L be a scalar"
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
fortran/interface.c:
gfc_error ("DTIO dummy argument at %L be a scalar",
There is a "must" missing.
[Bug fortran/79601] New: Possibly wrong use of keyword "intent" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79601
Bug ID: 79601
Summary: Possibly wrong use of keyword "intent" in diagnostic
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
fortran/interface.c:
if (fsym->attr.intent != intent)
gfc_error ("DTIO dummy argument at %L must have intent %s",
>declared_at, gfc_code2string (intents, (int)intent));
Should the "intent %s" be "INTENT %s" instead?
[Bug fortran/79602] New: translation: globally replace '%s' with %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79602 Bug ID: 79602 Summary: translation: globally replace '%s' with %qs Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- There are several strings of the following form: Too few dummy arguments in DTIO procedure '%s' at %L These should be converted to the now common form using %qs: Too few dummy arguments in DTIO procedure %qs at %L When doing this, please make sure to not burden each i18n translator with the task of updating the translations themselves, but apply an automatic search-and-replace instead. If you don't have such a program available, have a look at https://github.com/rillig/translation-team-de/blob/master/autocorrect.lua, which I just used for the recent and similar \"%s\" -> %qs migration.
[Bug go/79642] New: space instead of tab in lang.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79642 Bug ID: 79642 Summary: space instead of tab in lang.opt Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: roland.illig at gmx dot de CC: cmang at google dot com Target Milestone: --- In go/lang.opt, the option fgo-relative-import-path= is defined other than all others. fgo-relative-import-path= Go Joined RejectNegative -fgo-relative-import-path= Treat a relative import as relative to path. There is a space between "" and "Treat". All entries should have a tab here, to allow for proper table formatting. This invisible typo should have been caught automatically when parsing that file.
[Bug translation/79643] New: Please define the file format of *.opt files more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79643 Bug ID: 79643 Summary: Please define the file format of *.opt files more i18n-friendly Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The nios2.opt file contains the following lines: > mno-custom-ftruncds > Target Report RejectNegative Var(nios2_custom_ftruncds, -1) > Do not use the ftruncds custom instruction. > > mcustom-ftruncds= > Target Report RejectNegative Joined UInteger Var(nios2_custom_ftruncds) > Init(-1) > Integer id (N) of ftruncds custom instruction. > > mno-custom-fextsd > Target Report RejectNegative Var(nios2_custom_fextsd, -1) > Do not use the fextsd custom instruction. > > mcustom-fextsd= > Target Report RejectNegative Joined UInteger Var(nios2_custom_fextsd) Init(-1) > Integer id (N) of fextsd custom instruction. > > mno-custom-fixdu > Target Report RejectNegative Var(nios2_custom_fixdu, -1) > Do not use the fixdu custom instruction. > > mcustom-fixdu= > Target Report RejectNegative Joined UInteger Var(nios2_custom_fixdu) Init(-1) > Integer id (N) of fixdu custom instruction. These lines are error-prone and boring for translators. Could you maybe define the file format for *.opt files so that it can use placeholders like %s? This would make the job of translators a bit easier.
[Bug fortran/79602] translation: globally replace '%s' with %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79602 --- Comment #2 from Roland Illig --- (In reply to jos...@codesourcery.com from comment #1) > We only ever download translations from the TP site and use them > unmodified; we don't make any local changes to the translations in GCC. Fine, but the first item (changing the quotes from '%s' to %qs) should still be fixed.
[Bug target/79644] New: Undocumented options in microblaze.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79644 Bug ID: 79644 Summary: Undocumented options in microblaze.opt Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- mxl-mode-executable Target Mask(XL_MODE_EXECUTABLE) Description for mxl-mode-executable. mxl-mode-xmdstub Target Mask(XL_MODE_XMDSTUB) Description for mxl-mode-xmdstub. mxl-mode-bootstrap Target Mask(XL_MODE_BOOTSTRAP) Description for mxl-mode-bootstrap. mxl-mode-novectors Target Mask(XL_MODE_NOVECTORS) Description for mxl-mode-novectors.
[Bug target/79646] New: Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 Bug ID: 79646 Summary: Typos in vax.opt Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- > md > Target RejectNegative InverseMask(G_FLOAT) > Target DFLOAT double precision code. > > md-float > Target RejectNegative InverseMask(G_FLOAT) > Target DFLOAT double precision code. > > mg > Target RejectNegative Mask(G_FLOAT) > Generate GFLOAT double precision code. > > mg-float > Target RejectNegative Mask(G_FLOAT) > Generate GFLOAT double precision code. The word "Target" in the description lines for the first two entries should probably be "Generate", as it already is in the second two entries.
[Bug c/79635] Explain to translators what "asan" means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79635 --- Comment #2 from Roland Illig --- Thanks for that info. Could you add this as a comment to the params.def file, just above the first appearance of the word "asan"?
[Bug target/79645] New: missing period in microblaze.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79645 Bug ID: 79645 Summary: missing period in microblaze.opt Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- > mxl-prefetch > Target Mask(PREFETCH) > Use hardware prefetch instruction All other descriptions (line 3) end with a period.
[Bug c/79613] New: missing space in diagnostic: GLOBAL CONST-PROP: Replacing reg %d in jump_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79613 Bug ID: 79613 Summary: missing space in diagnostic: GLOBAL CONST-PROP: Replacing reg %d in jump_insn Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From cprop.c: fprintf (dump_file, "GLOBAL CONST-PROP: Replacing reg %d in jump_insn %d with" "constant ", REGNO (from), INSN_UID (jump)); There is a space missing between "with" and "constant".
[Bug c++/79614] New: missing space in diagnostic: the mangled name of the initialization guard variable for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79614 Bug ID: 79614 Summary: missing space in diagnostic: the mangled name of the initialization guard variable for Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From mangle.c: warning_at (DECL_SOURCE_LOCATION (t), OPT_Wabi, "the mangled name of the initialization guard variable for" "%qD changes between -fabi-version=%d and -fabi-version=%d", t, flag_abi_version, warn_abi_version); There is a space missing between "for" and "%qD".
[Bug fortran/79617] New: missing space in diagnostic: IF clause without modifier at %L used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79617
Bug ID: 79617
Summary: missing space in diagnostic: IF clause without
modifier at %L used together
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From fortran/openmp.c:
gfc_error ("IF clause without modifier at %L used together with"
"IF clauses with modifiers",
_clauses->if_expr->where);
There is a space missing between "with" and "IF".
[Bug translation/79618] New: prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 Bug ID: 79618 Summary: prevent missing space in multiline string literals Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- As demonstrated in #79610, #79612, #79613, #79614, #79615, #79616, #79617, there are many chances for introducing missing spaces in multiline string literals, which can even hide test cases, like in commit 138bc75d-0d04-0410-961f-82ee72b054a4. To prevent this from ever happening again, there should be some automatic check that detects these wrong string literals. This test should currently find the word "cannot" in fortran/match.c, which is split into two lines. No problem here, but it smells like one. if (group_name->attr.flavor == FL_NAMELIST && group_name->attr.use_assoc && !gfc_notify_std (GFC_STD_GNU, "Namelist group name %qs " "at %C already is USE associated and can" "not be respecified.", group_name->name))
[Bug c/79615] New: missing space in diagnostic: Substring out of bounds: lower bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79615
Bug ID: 79615
Summary: missing space in diagnostic: Substring out of bounds:
lower bound
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From trans-expr.c:
msg = xasprintf ("Substring out of bounds: lower bound (%%ld)"
"is less than one");
There is a space missing between "(%%ld)" and "is".
[Bug ipa/79616] New: missing space in diagnostic: Inlined into %s which now has time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79616 Bug ID: 79616 Summary: missing space in diagnostic: Inlined into %s which now has time Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From ipa-inline.c: fprintf (dump_file, " Inlined into %s which now has time %i and size %i," "net change of %+i.\n", edge->caller->name (), inline_summaries->get (edge->caller)->time, inline_summaries->get (edge->caller)->size, overall_size - old_size); There is a space missing between "%i," and "net".
[Bug c++/79608] New: missing space in error message "bepositive"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79608 Bug ID: 79608 Summary: missing space in error message "bepositive" Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From cp/semantics.c: case OMP_CLAUSE_VECTOR: warning_at (OMP_CLAUSE_LOCATION (c), 0, "%<vector%> length value must be" "positive"); break; case OMP_CLAUSE_WORKER: warning_at (OMP_CLAUSE_LOCATION (c), 0, "%<worker%> num value must be" "positive"); You should check for any adjacent string literals where the first doesn't end with a space _and_ the second doesn't start with a space.
[Bug c/79610] New: missing space in diagnostic: %qD must be a global variable in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79610 Bug ID: 79610 Summary: missing space in diagnostic: %qD must be a global variable in Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From c/c-parser.c: error_at (loc, "%qD must be a global variable in" "%<#pragma acc declare link%>", decl); There is a space missing between "in" an "%<pragma".
[Bug c++/79611] New: missing space in diagnostic: placement new constructing an object of type %qT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79611 Bug ID: 79611 Summary: missing space in diagnostic: placement new constructing an object of type %qT Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From cp/init.c: warning_at (loc, OPT_Wplacement_new_, exact_size ? "placement new constructing an object of type %qT " "and size %qwu in a region of type %qT and size %qwi" : "placement new constructing an object of type %qT" "and size %qwu in a region of type %qT and size " "at most %qwu", type, bytes_need, TREE_TYPE (oper), bytes_avail); There is a space missing between "%qt" and "and".
[Bug other/79612] New: missing space in diagnostic: Incorrect rank of return array in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79612
Bug ID: 79612
Summary: missing space in diagnostic: Incorrect rank of return
array in
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From runtime/bounds.c:
runtime_error ("Incorrect rank of return array in %s intrinsic:"
"is %ld, should be 1", name, (long int) ret_rank);
There is a space missing between "intrinsic:" and "is".
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #1 from Roland Illig --- Furthermore, the space should either be always at the end of the line or always at the beginning of the next line. Currently both variants are used.
[Bug translation/79477] New: Please write code more translator-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79477
Bug ID: 79477
Summary: Please write code more translator-friendly
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
As a translator, I have to translate these strings:
-mdirect-move requires -mvsx
-mupper-regs-di requires -mvsx
-mpower9-vector requires -mpower8-vector
-mpower9-dform requires -mpower9-vector
And several more of this pattern. This is both boring and error-prone.
Instead of calling:
error ("-mpower9-dform requires -mpower9-vector");
Could you perhaps call:
error ("%s requires %s", "-mpower9-dform", "-mpower9-vector");
This would save the translators of each language a lot of work.
[Bug fortran/79475] New: Missing space in error message: SINK addend not a constant integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79475
Bug ID: 79475
Summary: Missing space in error message: SINK addend not a
constant integer
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
fortran/openmp.c:
gfc_error ("SINK addend not a constant integer"
"at %L", >where);
[Bug target/79473] New: -mload-store-pairs option is not documented in invoke.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79473 Bug ID: 79473 Summary: -mload-store-pairs option is not documented in invoke.texi Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- As a translator, I didn't know the concept before, so I had to look it up. The explanation at http://www.anandtech.com/show/8457/mips-strikes-back-64bit-warrior-i6400-architecture-arrives/3 looks short and easily understandable.
[Bug translation/80189] gimplify.c: check whether parallel/task/teams should be translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80189 --- Comment #3 from Roland Illig --- To me that would be fine since then I had not even looked at what the %qs might be. But like the code is now, I suspected the %s to be part of the grammar of the diagnostic.
[Bug c++/80191] diagnostic placeholder "new initializer" must be marked for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80191 --- Comment #2 from Roland Illig --- But then shouldn't it be spelled "new-initializer", not "new initializer"?
[Bug fortran/38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573 --- Comment #12 from Roland Illig --- (In reply to Frederic Marchal from comment #11) > I suspect a misunderstanding here. Forgive me if I state the obvious. > > The fix is not to move the translation mark around. I think moving the translation mark "_(...)" into each case of the switch statement would solve the problem, so maybe I misunderstood you here.
[Bug translation/80188] New: calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
Bug ID: 80188
Summary: calls.c: reason argument to
maybe_complain_about_tail_call must be marked for
translation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from calls.c:
static void
maybe_complain_about_tail_call (tree call_expr, const char *reason)
{
...
error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
}
The "reason" argument must be marked for translation using N_("..."), but is
not. For example:
maybe_complain_about_tail_call (exp,
"a callee-copied argument is"
" stored in the current "
" function's frame");
This means that the string "a callee-copied ..." is always given in English,
even if the rest of the diagnostic is given in German or some other language.
I don't know how to reproduce this particular diagnostic, but there should be a
test for it. When running this test in a non-English locale, the diagnostic
with mixed language will show up.
[Bug translation/80189] New: gimplify.c: check whether parallel/task/teams should be translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80189
Bug ID: 80189
Summary: gimplify.c: check whether parallel/task/teams should
be translated
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from gimplify.c, function omp_default_clause:
const char *rtype;
if (ctx->region_type & ORT_PARALLEL)
rtype = "parallel";
else if (ctx->region_type & ORT_TASK)
rtype = "task";
else if (ctx->region_type & ORT_TEAMS)
rtype = "teams";
else
gcc_unreachable ();
error ("%qE not specified in enclosing %s",
DECL_NAME (lang_hooks.decls.omp_report_decl (decl)), rtype);
error_at (ctx->location, "enclosing %s", rtype);
Should "rtype" be translated here? If so, the string literals must be inlined
into the diagnostic since they result in different grammar, at least in German.
If they should not be translated, they should be marked in the code as
intentionally not translated, since this code looks like an oversight.
[Bug c++/80191] New: diagnostic placeholder "new initializer" must be marked for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80191 Bug ID: 80191 Summary: diagnostic placeholder "new initializer" must be marked for translation Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from cp/typeck.c: permerror (input_location, "%s expression list treated as compound expression", msg); The placeholder "msg" gets the value "new initializer" in init.c, but that string literal is not enclosed in _(...), therefore it won't be translated. That call seems to be the only place where build_x_compound_expr_from_vec is actually called, so having a placeholder might be unnecessary overhead.
[Bug target/80190] New: darwin: untranslateable placeholder "non-ASCII character"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80190 Bug ID: 80190 Summary: darwin: untranslateable placeholder "non-ASCII character" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from config/darwin.c: warning (darwin_warn_nonportable_cfstrings, "%s in CFString literal", s[l] ? "non-ASCII character" : "embedded NUL"); When running GCC in a German locale, the placeholder %s will still be output in English since it is not marked for translation. Both string literals must be surrounded by _(...).
[Bug objc/80192] New: arguments to check_protocols should be marked as translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80192 Bug ID: 80192 Summary: arguments to check_protocols should be marked as translateable Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from objc-act.c: warning (0, "%s %qE does not fully implement the %qE protocol", type, name, PROTOCOL_NAME (p)); The placeholder %s either gets the string "class" or "category". These words should be marked for translation by surrounding them with _(...).
[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 Roland Illig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Roland Illig --- Thanks for fixing these.
[Bug translation/79643] Please define the file format of *.opt files more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79643 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Roland Illig --- Redefining the file format would be too much work, given that translating these messages doesn't take too long and they barely change once translated.
[Bug target/80052] New: typo in aarch64.opt: dummping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80052 Bug ID: 80052 Summary: typo in aarch64.opt: dummping Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from aarch64.opt: Enables verbose cost model dummping in the debug dump files. s/dummping/dumping/ In the same commit, a typo was introduced into ChangeLog, which is now ChangeLog-2016: the file says "PInski", "which should be "Pinski".
[Bug fortran/38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573 --- Comment #10 from Roland Illig --- (In reply to Frederic Marchal from comment #8) > Adding "is" at the end of the first part works with all the other strings > that can be inserted at the %s placeholder. > > I can make it work with the French translation too. The German translator, > Roland Illig, is very active with his translation. I'll CC him to ask his > opinion about this bug. It works for German, too. And for Spanish. And probably for many other languages, since it can be split into a sentence and a subsentence, where the subsentence does not influence the main sentence. That's seldom for a %s placeholder, since most others replace only a smaller part of the sentence. Therefore I think this particular message is no problem, as soon as the texts for the placeholder are also translated. We still have to be careful with all the other %s placeholders.
[Bug fortran/38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573 --- Comment #9 from Roland Illig --- (In reply to Jerry DeLisle from comment #7) > /* Otherwise, fail. */ > if (symstd) > *symstd = _(symstd_msg); > return false; > > Where the mark is on the symstd_msg after it is set to one of the above > cases. Are you saying this does not work? Does the translation mark need > to be on all and not in one place? Yes, the translation mark needs to be around each string literal that should be translated. xgettext (which extracts the strings from source code) only looks at the source code, but never executes the program to see what really happens. That's good enough for all practical cases.
[Bug translation/80055] New: do not mark arguments of internal_error for i18n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80055 Bug ID: 80055 Summary: do not mark arguments of internal_error for i18n Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Expanding on bug 79596 (mentions only gfc_internal_error), as well as a discussion on a mailing list. From https://gcc.gnu.org/ml/gcc/2017-03/msg00049.html: > In my opinion, there is no point in having internal error messages > translated, since their only purpose is to be sent back to the GCC > developers, instead of being interpreted and acted upon by the GCC user. > By not translating the internal errors, the necessary work for > translators can be cut down by several hundred messages.
[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 --- Comment #8 from Roland Illig --- (In reply to Martin Liška from comment #7) > I like your rules. My question was more about how practically do you > distinguish between such strings? My plan is to create a new > DK_INTERNAL_ERROR type, which I would like to ignore in the translations. I don't know what you mean by "distinguish". As I suggested in https://gcc.gnu.org/ml/gcc/2017-03/msg00049.html, I would solve this by having two separate functions for errors: error() and error_no_i18n(). Can you elaborate a bit on what you meant?
[Bug other/80058] New: fix double spaces is string literals everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80058 Bug ID: 80058 Summary: fix double spaces is string literals everywhere Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Searching the whole GCC source code for the following regular expression finds a few places in the code: [ ]"\n[ \t]+"[ ] This expression finds concatenated string literals where the first ends with a space and the second starts with a space, like these: gfc_warning_now (w, "Change of value in conversion from " " %qs to %qs at %L", gfc_typename (>ts), gfc_typename (>ts), >where); The above code and all similar places should be fixed so that they only have a single space character.
[Bug target/80057] typo in mips.opt: Virtualization Application Specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80057 --- Comment #2 from Roland Illig --- Citing from the PDF document: > The Virtualization Application-Specific Extension (Module) requires the > following base architecture support: The current GCC code split these words at the following boundaries: > The "Virtualization Application Specific" "Module" This would imply that there is a module called VAS. The usual reading is different, though: > The "Virtualization" "application-specific module" This means there is an application-specific module called "Virtualization". The words "Application-Specific Extension" are probably only capitalized because they have been defined somewhere as a concept. In GCC, these words should not be capitalized, and there should be a hyphen between "application-specific", to be consistent with the grammar in other places.
[Bug target/80057] New: typo in mips.opt: Virtualization Application Specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80057 Bug ID: 80057 Summary: typo in mips.opt: Virtualization Application Specific Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from mips.opt: mvirt Target Report Var(TARGET_VIRT) Use Virtualization Application Specific instructions. The words "Virtualization Application Specific" are not the official name of an instruction set extension, therefore they should not look like an abbreviation.
[Bug fortran/79841] New: Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
Bug ID: 79841
Summary: Inconsistent diagnostics in fortran/openmp.c, function
check_symbol_not_pointer
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
gfc_error ("POINTER object %qs of derived type in %s clause at %L",
sym->name, name, );
gfc_error ("Cray pointer object of derived type %qs in %s clause at %L",
sym->name, name, );
In the first call, the %qs appears after the word "object", in the second call
the %qs appear after the word "type".
As the German translator, I am confused now since the same expression is used
to refer to the object in one case and to the type of the object in the other
case.
All diagnostics in the check_symbol_not_pointer function should follow the same
pattern.
[Bug c/79834] New: c/c-parser.c: make code more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79834 Bug ID: 79834 Summary: c/c-parser.c: make code more i18n-friendly Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The following code pattern occurs several times: c_parser_error (parser, "%<#pragma acc update%> may only be " "used in compound statements"); Each of these occurrences has to be translated individually by a translator for each of the supported human languages. This creates unnecessary work. It would be less work (and fewer chances of introducing typos) to have only one template: c_parser_error (parser, "%<#pragma %s%> may only be " "used in compound statements", "acc update"); The code in c/c-parser.c and cp/parser.c should therefore use the second pattern consistently.
[Bug fortran/79840] New: Inconsistent exclamation mark in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840
Bug ID: 79840
Summary: Inconsistent exclamation mark in diagnostic
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/module.c:
gfc_fatal_error ("Can't USE the same %smodule we're building!", ...);
This diagnostic uses an exclamation mark, as opposed to all the others that
don't use any punctuation at all. It also talks about "we", which is different
from all other diagnostics.
The diagnostic should follow the same pattern as all the other ones.
[Bug c/79836] New: typo in c/c-parser.c: pragma omp ordered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79836 Bug ID: 79836 Summary: typo in c/c-parser.c: pragma omp ordered Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- error_at (loc, "%<#pragma omp ordered%> with % clause may " "only be used in compound statements"); It must be %<depend%> (the percent is missing for the closing quote).
[Bug fortran/79838] New: inconsistent trailing dot in diagnostic "The name %qs has already been used"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79838
Bug ID: 79838
Summary: inconsistent trailing dot in diagnostic "The name %qs
has already been used"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
gfc_error ("The name %qs at %C has already been used as "
"an external module name.", use_list->module_name);
This error message, in contrast to almost every other error message, has a
trailing period. This period should be removed.
[Bug fortran/79596] translation: argument to gfc_internal_error should not be translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79596 --- Comment #2 from Roland Illig --- (In reply to Dominique d'Humieres from comment #1) > > Internal errors should not be translated. Their only purpose is to give > > information back to the developers, and this information should not be > > modified by any translator. > > I agree, but how do achieve that? gcc/Makefile.in contains the po/gcc.pot target, which uses po/exgettext. I assume that somewhere there is some list of functions that take translatable strings, since xgettext has to decide which of these functions take printf-style arguments and which take gcc-internal-style arguments. The gfc_internal_error function should be removed from that list. I could not find this list anywhere, though.
[Bug c/79837] New: incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79837 Bug ID: 79837 Summary: incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- c_parser_error (parser, "expected %<+%>, %<*%>, %<-%>, %<&%>, " "%<^%>, %<|%>, %<&&%>, %<||%>, %<min%> or identifier"); There is a ", max" missing after "min".
[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #2 from Roland Illig --- German readers generally expect the %qs directly after the word "object". This choice should eliminate all ambiguities, since in "object of type %qs", the user no longer has to think about whether the %qs belongs to the object or the type.
[Bug target/79845] New: rs6000: make code in rd6000.c more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79845
Bug ID: 79845
Summary: rs6000: make code in rd6000.c more i18n-friendly
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from rs6000.c:
error ("Builtin function %s requires the -mhard-dfp option", name);
There are several variants of the above line. Currently one human translator
for each of the human languages has to translate all these variants one by one.
It would be much easier if the C code looked like this:
error ("Builtin function %s requires the %s option", name, "-mhard-dfp");
Not only does this reduce the work for translators, it also leads to fewer
possibilities for typos in the translations.
[Bug fortran/79842] New: i18n: subword translation in "Can't use the same %smodule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842
Bug ID: 79842
Summary: i18n: subword translation in "Can't use the same
%smodule"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
gfc_fatal_error ("Can't USE the same %smodule we're building!",
p->state == COMP_SUBMODULE ? "sub" : "");
The message is either of these:
* "Can't USE the same module we're building!"
* "Can't USE the same submodule we're building!"
As a translator, I have no chance of providing a proper translation for this,
since the word part "sub" is always introduced.
Translations should always be complete sentences. In this case, the easiest
solution is this:
for (p = gfc_state_stack; p; p = p->previous)
if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE)
&& strcmp (p->sym->name, module_name) == 0)
if (p->state == COMP_SUBMODULE)
gfc_fatal_error ("Can't USE a submodule that is currently built");
else
gfc_fatal_error ("Can't USE a module that is currently built");
This also fixes #79840 by removing the exclamation mark and rewording the
diagnostic.
[Bug fortran/79844] New: diagnostics: extra space at end of line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79844
Bug ID: 79844
Summary: diagnostics: extra space at end of line
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/trans-intrinsic.c:
gfc_error ("The event variable at %L shall not be coindexed ",
_expr->where);
The space after "coindexed" looks like a typo.
[Bug c/79847] New: diagnostics: missing space in "implicit declaration of function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79847
Bug ID: 79847
Summary: diagnostics: missing space in "implicit declaration of
function"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from c-decl.c:
G_("implicit declaration of function %qE;did you mean %qs?"),
There should be a space after the semicolon.
[Bug fortran/79843] New: diagnostics: missing word in fortran/symbol.c, conflict_std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79843
Bug ID: 79843
Summary: diagnostics: missing word in fortran/symbol.c,
conflict_std
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/symbol.c:
conflict_std:
if (name == NULL)
{
return gfc_notify_std (standard, "%s attribute "
"with %s attribute at %L", a1, a2,
where);
}
else
{
return gfc_notify_std (standard, "%s attribute "
"with %s attribute in %qs at %L",
a1, a2, name, where);
}
These diagnostic seem to be missing the word "conflicts" before the "with".
[Bug ipa/79850] New: diagnostics: typo in "fields has different layout"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79850
Bug ID: 79850
Summary: diagnostics: typo in "fields has different layout"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from ipa-devirt.c:
warn_odr (t1, t2, f1, f2, warn, warned,
G_("fields has different layout "
"in another translation unit"));
The "has" should probably be "have".
[Bug fortran/79854] New: diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79854 Bug ID: 79854 Summary: diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from fortran/trans-const.c: fatal_error (input_location, "gfc_conv_constant_to_tree(): invalid type: %s", gfc_typename (>ts)); Since the diagnostic mentions an internal function name, it must be a gfc_internal_error instead of a fatal_error.
[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #6 from Roland Illig --- Could you perhaps make all 6 messages in that function follow the same syntax?
[Bug lto/79851] New: diagnostics: replace '%s' with %qs in all diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79851 Bug ID: 79851 Summary: diagnostics: replace '%s' with %qs in all diagnostics Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from lto-streamer.c: fatal_error (input_location, "bytecode stream in file '%s' generated with LTO version " As the German translator, I currently cannot translate '%s' into %qs (which is much easier to type), since GNU Gettext is buggy (https://savannah.gnu.org/bugs/index.php?50455). Therefore, GCC should be consistent in all diagnostics and never use '%s' or "%s" or `%s' or %<%s%>, but instead only %qs. The above is only one instance. Please fix all diagnostics in all files.
[Bug fortran/79853] New: diagnostics: double space in "Assumed or deferred"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79853
Bug ID: 79853
Summary: diagnostics: double space in "Assumed or deferred"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/decl.c:
gfc_error ("Assumed or deferred character length variable %qs "
" in constant expression at %L",
There are two spaces between "%qs" and "in", there should only be one.
[Bug ipa/79849] New: diagnostics: typo in "type %qT itself violate the C++ One Definition Rule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79849 Bug ID: 79849 Summary: diagnostics: typo in "type %qT itself violate the C++ One Definition Rule" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from ipa-devirt.c: inform (loc_t1, "type %qT itself violate the C++ One Definition Rule", t1); The "violate" should probably be "violates".
[Bug ipa/79848] New: diagnostics: too complicated %<%s%>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79848 Bug ID: 79848 Summary: diagnostics: too complicated %<%s%> Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from ipa-devirt.c: inform (loc_t1, "type name %<%s%> should match type name %<%s%>", name1, name2); All instances of %<%s%> should be replaced with the much simpler %qs, in all files.
[Bug fortran/79852] New: diagnostics should not end with exclamation mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852
Bug ID: 79852
Summary: diagnostics should not end with exclamation mark
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/decl.c:
gfc_error ("%qs at %C is already defined as FINAL procedure!", name);
Having a few diagnostics end with an exclamation mark makes them stick out
although they are nothing special.
All diagnostics in all files (not only Fortran) should not end with punctuation
(except for the occasional "did you mean %qs?").
[Bug fortran/79844] diagnostics: extra space at end of line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79844
--- Comment #1 from Roland Illig ---
Same issue, in fortran/match.c:
gfc_error ("Redundant STAT tag found at %L ", >where);
gfc_error ("Redundant ERRMSG tag found at %L ", >where);
gfc_error ("Redundant UNTIL_COUNT tag found at %L ",
[Bug target/79846] New: s390: untranslatable diagnostic in s390.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79846
Bug ID: 79846
Summary: s390: untranslatable diagnostic in s390.c
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from s390.c:
error("constant argument %d for builtin %qF is out of range (0.."
HOST_WIDE_INT_PRINT_UNSIGNED ")",
This function call results in a translation request for the string "constant
argument %d for builtin %qF is out of range (0..".
No matter how I translate this string, it will never be used because the
HOST_WIDE_INT_PRINT_UNSIGNED constant will be resolved by the C compiler but
not by xgettext.
The first argument to the "error" function must always be a concatenation of
string literals, as seen by a very naive parser.
[Bug fortran/79861] New: i18n: add translator comment for "%s !$ACC LOOP loops not perfectly nested at %L"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79861
Bug ID: 79861
Summary: i18n: add translator comment for "%s !$ACC LOOP loops
not perfectly nested at %L"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/openmp.c:
gfc_error ("%s !$ACC LOOP loops not perfectly nested at %L",
clause, >loc);
As an i18n translator, I have no idea what could be inserted for the "%s".
Therefore a /* TRANSLATORS: ... */ comment should explain this by giving one or
two examples.
[Bug c/79855] New: params.def: missing period in PARAM_MAX_STORES_TO_MERGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79855 Bug ID: 79855 Summary: params.def: missing period in PARAM_MAX_STORES_TO_MERGE Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The text for PARAM_MAX_STORES_TO_MERGE is missing the final period. Most other messages have a final period. All messages in params.def should use consistent grammar. Therefore they all need a final period. It should also be trivial to write a little program that checks this automatically, to prevent future bug reports of the same kind.
[Bug fortran/79860] New: i18n: single-word translation in "Character-valued %s %qs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79860
Bug ID: 79860
Summary: i18n: single-word translation in "Character-valued %s
%qs"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/resolve.c:
gfc_error ("Character-valued %s %qs at %L must not be"
" assumed length",
module_proc ? _("module procedure") : _("internal function"),
sym->name, >declared_at);
When translating the message from the above code into languages other than
English, the adjective "character-valued" might take a different form depending
on whether the following word is a procedure or a function.
The German translation may look like this:
Die zeichenwertige Prozedur ...
Die zeichenwertige Funktion ...
Das zeichenwertige Unterprogramm ...
So depending on the inserted word the rest of the sentence may change (Die ->
Das). Therefore translations should always come in whole sentences and only use
placeholders in contexts that don't influence the outside grammar of the
sentence.
[Bug rtl-optimization/79856] New: rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 Bug ID: 79856 Summary: rtl_verify_edges: use internal_error instead of error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In cfgrtl.c, the calls to the "error" function contain a level of technical details that is not useful for the GCC user. Therefore these calls should be replaced with internal_error, and the strings should not be marked for translation.
[Bug c++/79857] New: cgraph_node::verify_node should call internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79857 Bug ID: 79857 Summary: cgraph_node::verify_node should call internal_error instead of error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In cgraph.c, the method cgraph_node::verify_node contains several calls to "error", having messages with technical detail that is not appropriate for the GCC user. These calls should be replaced with calls to internal_error, and their arguments should not be translated as part of i18n.
[Bug rtl-optimization/79858] New: Explain to translators what %smode means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79858
Bug ID: 79858
Summary: Explain to translators what %smode means
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from expmed.c:
sorry ("reverse storage order for %smode", GET_MODE_NAME (mode));
What values can the placeholder %s take in the above diagnostic? Is it even a
diagnostic? There should be a /* TRANSLATORS: ... */ comment above that line
explaining this.
Just in case that the %s placeholder can influence the grammar of the sentence
in languages other than English, this diagnostic must be rethought completely.
[Bug fortran/79859] New: diagnostics: argument quoted twice in "No initializer for allocatable compoonent"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859 Bug ID: 79859 Summary: diagnostics: argument quoted twice in "No initializer for allocatable compoonent" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from fortran/primary.c: if (!gfc_notify_std (GFC_STD_F2008, "No initializer for " "allocatable component '%qs' given in the " "structure constructor at %C", comp->name)) The single quotes around %qs are superfluous.
[Bug fortran/79866] New: diagnostics: typo in "Variable %s at %L of type EVENT_TYPE"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79866
Bug ID: 79866
Summary: diagnostics: typo in "Variable %s at %L of type
EVENT_TYPE"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
in fortran/resolve.c:
gfc_error ("Variable %s at %L of type EVENT_TYPE or with subcomponent of "
"type LOCK_TYPE must be a coarray", sym->name,
>declared_at);
The second LOCK_TYPE should probably be EVENT_TYPE, like in all other
diagnostics of that kind.
[Bug fortran/79968] New: diagnostics: merge similar diagnostics containing -fdec-structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79968
Bug ID: 79968
Summary: diagnostics: merge similar diagnostics containing
-fdec-structure
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
The file fortran/decl.c contains several of these diagnostics:
gfc_error ("STRUCTURE at %C is a DEC extension, enable with "
"-fdec-structure");
If these were written as follows, it would reduce work for the i18n
translators, as well as eliminate any chance of introducing typos.
gfc_error ("%s at %C is a DEC extension, enable with "
"%<-fdec-structure%>",
"STRUCTURE");
This should basically be a textual search-and-replace for all occurrences of
"is a DEC extension".
[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 --- Comment #6 from Roland Illig --- I would define the rules as follows, the first matching rule wins: 1. do not translate messages that contain names of GCC implementation functions 2. do not translate messages that contain the words GIMPLE, BB (meaning basic block), insn (unsuitable abbreviation for instruction), RTL, SSA 3. do not translate messages from gfc_internal_error, internal_error 4. translate messages that use only terminology from the user's programming language (C, C++, Fortran) 5. decide on your own (this should only occur rarely)
[Bug fortran/80011] New: diagnostics: trailing space in "Implicitly declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80011
Bug ID: 80011
Summary: diagnostics: trailing space in "Implicitly declared"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/openmp.c:
gfc_error ("Implicitly declared function %s used in "
"!$OMP DECLARE REDUCTION at %L ", sym->name, &(*e)->where);
The space after %L should be removed.
Please also look for similar issues in the rest of the code.
[Bug fortran/80010] New: diagnostics: typo $!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80010 Bug ID: 80010 Summary: diagnostics: typo $! Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In some few cases the Fortran diagnostics contain $! instead of !$. This looks like typos to me. fortran/openmp.c: Invalid clause in module with $!ACC DECLARE at %L Variable is USE-associated with $!ACC DECLARE at %L Assumed-size dummy array with $!ACC DECLARE at %L Invalid argument to $!ACC WAIT at %L Array sections: %qs not allowed in $!ACC DECLARE at %L fortran/trans-decl.c: Sorry, $!ACC DECLARE at %L is not allowed in BLOCK construct
[Bug fortran/80012] New: FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012
Bug ID: 80012
Summary: FIXME in diagnostic "%s procedure at %L is already
declared as %s procedure" from symbol.c
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/symbol.c:
gfc_error ("%s procedure at %L is already declared as %s "
"procedure. \nF2008: A pointer function assignment "
"is ambiguous if it is the first executable statement "
"after the specification block. Please add any other "
"kind of executable statement before it. FIXME",
As a translator, I'm not sure how to translate the FIXME here, since it looks
like something needs to be done before putting this code into release.
[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 --- Comment #4 from Roland Illig --- (In reply to Richard Biener from comment #3) > So maybe we instead want a internal_error_cont () which will not end > compilation. I would be very happy with that.
